Activities across the lifecycle:
To build e-business applications means building Internet solutions to implement business processes. This includes
e-commerce, but extends to all business processes throughout an organization.
E-business systems can be divided into:
-
first generation systems that simply use the web to publish information
-
second generation systems that implement e-commerce and simple transactional models
-
third generation systems that completely re-engineer a process to provide highly personalized (business-to-consumer
or business-to-business) solutions that are adaptive and automate the complete business process, often integrating
with legacy systems and internet devices
The further along the systems are in the generations, the more complex their development.
The basic workflow for the Inception Phase
applies, with the following extensions or variations.
Environment
The importance of the Task: Prepare Guidelines for the Project is amplified and focuses
on what Web developers call the 'Creative Design Brief', which is a set of guidelines that describe (at a high
level)
-
The mood of the site; for example, does the site convey authority, playfulness, or service? Is it
conservative or provocative?
-
How users will be accessing the site; for example, what's their connection speed? Is there a minimum
speed specified or assumed in the design?
-
The degree of user-interaction; for example, should we only inform the user or should we try to
communicate with the actor (two-way communication)? Should the design of the application be different
depending on which user is accessing the application?
-
The browsers that users will be using, including differences across operating systems
-
Whether the site will use frames
-
Any color limitations the site will have
-
If applicable, a graphics standards guide (including standards on logos and all corporate colors)
-
The usage of specific web techniques; for example, mouse-overs, animation, news feeds, multimedia,
and so forth
The 'Creative Design Brief' evolves into the user interface guidelines documented in the Work Product: Project-Specific Guidelines; it is essentially an
early version of the user-interface guidelines.
Requirements
There is an assumption that some of the following activities are using the results of a business modeling exercise
which is outside of the scope of this guideline.
This has less emphasis. Most of the problems should already have been found during business modeling.
This requires less emphasis. Most of the stakeholder needs should have been found during business modeling. You
will, however, need to do some exercises that focus on finding non-functional requirements on the system.
This requires less emphasis. The system boundary is defined by the boundary of the business, since the system
more closely mirrors the business than in traditional applications (in some respects, the system is
the business).
Analysis and Design
The Task: Design the User Interface produces a Navigation Map. A Navigation Map is a view of the Web solution
that shows how users of the site will navigate it, possibly represented in a hierarchical "tree" diagram. Each
level of the diagram shows the number of clicks it takes to get to that screen or page. Generally, you want to have
the most important areas of the Web site only one click away from the first page (commonly known as the "home
page"). The Navigation Map is effectively a summary of the Storyboards, which starts by identifying the major windows or Web
pages for each of the Use Cases and considers how the user navigates between these elements.
The basic workflow for the Elaboration Phase
applies, with the following extensions or variations.
-
Activity: Define a Candidate Architecture
The Task: Architectural Analysis takes advantage of the knowledge
that a Web application has a relatively well-defined architecture, including a set of well-defined mechanisms
(Web browsers, Java applets and servlets, ASPs and JSPs, and the like). Usually a simple layering structure as
described in Concept: Layering is sufficient unless the Web application development
framework is more specific. In many cases, there may be predefined, off-the-shelf architectures that can be
purchased or re-used from prior Web development projects. Web application frameworks, such as IBM's WebSphere
or Microsoft's Windows DNA, provide just this sort of architectural template.
Web applications typically do not have scheduled downtime. The architecture may (and typically does) need to
provide for upgrading the system while it's running, and switching to standby servers during primary server
failure or when maintenance or server upgrades occur. Some Web application frameworks provide tools for
production support. Regardless, if your application has high-availability requirements, you will need to plan
to buy or build the infrastructure necessary to support this requirement, and to integrate the support for this
capability into the architecture.
-
Activity: Analyze Behavior
The Task: Design the User Interface is performed iteratively
within the Elaboration iterations. The early executions of this activity focus on producing 'creative design
comps', which are mocked-up representations of the design of key Web pages in the site. These 'comps' are
typically "flat" pictures framed with browser window graphics to give a look of a browser window. The main
benefit of 'comps' is to postpone the investment of more elaborate and costly HTML prototypes until there is
consensus on the specific graphical direction for the site.
'Creative Design Comps' are created by looking at the interface requirements of the most important Use Cases
and developing many alternative designs (perhaps 10 or more) for its look and feel. From this set, the three
most promising options are chosen to present to the stakeholders. This is done iteratively until there is
agreement on the final Web design, resulting in a set of Storyboards and a Navigational Map.
Once there is agreement and sign-off, the creative design comps evolve into a functional User-Interface Prototype through repetition of the Task: Prototype the User Interface. The Initial Web UI
Prototype typically supports only portions of the system-the most important and architecturally significant use
cases. It's important to have a good structure in the Use Case flow-of-events before developing prototypes to
ensure that functionality drives the layout of the user interface and not the reverse.
In subsequent iterations, the Web prototype is expanded, gradually adding broader coverage of the use cases and
deeper exercise of the architecture.
The Task: Use-Case Analysis is relatively unchanged, except that
it's important to focus on not only the behavior of the GUI, but also the underlying business logic - the part
that will typically run on either the Web server or the application server. If this is forgotten, the most
significant portion of the system behavior will be overlooked. Web pages themselves are represented as
'boundary' classes, data elements are represented as 'entity' classes, and server-side behavior (for example,
active server pages, servlets, and such) is represented through 'control' objects.
Immediately following use-case analysis, the Task: Identify Design Elements refines the Work Product: Analysis Classes, mapping them onto existing
mechanisms in the web development framework, reusing existing design elements from prior projects or iteration
where possible. This often requires readjusting the scope and definition of the identified analysis classes to
achieve the desired degree of reuse.
A more detailed description of the use of UML to describe Web applications is described in Whitepaper: Modeling Web Application Architectures with UML.
-
Activity: Prepare Environment.
In addition to developing user interface guidelines, Web design elements-the discrete graphical images
that are assembled to build the Web pages for a site-are created. Consistency of the user interface across a
Web site is essential to usability; the Web site should provide a consistent user experience. To ensure this,
the project must consistently use a set of standard graphical elements across the whole site.
The development of these elements s an extension of the Task: Prepare Guidelines for the Project and includes the
creation of guidelines for their use. Ensure that all team members understand when and how to use these
elements. Examples of Web design elements include graphical elements such as navigational devices and page
backgrounds. Reusing high quality, standard, graphical elements across the entire site ensures consistency,
reduces time to market, and reduces development cost as well as increases quality by deploying a smaller set of
higher quality elements.
The preparation of guidelines is done in conjunction with the development of the initial Web User-Interface Prototype to produce the style guide for the
site. This style guide will, among other things, specify how and when Web design elements should be used, color
schemes, fonts, cascading style sheets, and details on how navigational elements should function and be
positioned.
-
Activity: Refine the Architecture
The Task: Identify Design Mechanisms becomes more focused on
mapping the non-functional requirements of the system onto the mechanisms provided by the Web development
framework; mechanisms not provided by the framework (if it exists) will need to be identified and alternative
solutions found.
The Task: Describe the Run-time Architecture becomes focused
mostly on the Web server and application server tiers (see Concept: Distribution Patterns), and the processes and threads used there to
manage concurrency in the application. Typically there is little or no control over processing on the
client-side machines.
The Task: Describe Distribution changes focus from one of
deciding 'what kinds of server nodes to have' to 'how many of each kind of server node to have'. Typically, the
Web development framework will provide a fixed number of server types (for example, web servers, application
servers, mail servers, communication gateway servers) with relatively well-defined functional boundaries. The
software architect's skill, as a result, becomes focused on determining how to deal with scalability and fault
tolerance requirements using the available server types, usually by determining how many of each kind of server
are needed. In addition, measurement plans need to be made to determine how to know when additional servers are
needed.
-
Activity: Define Evaluation Mission
Planning focuses, to a great degree, on performance testing to ensure that the Web application can support
significant increases in the number of concurrent users. As a result, the Test Activities Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets will also focus more on performance
testing to ensure that the architecture is scalable.
Other important Types of Test are Usability Testing and Structure Testing. It's necessary to test user-interaction to verify that the structure of the Web application
is appropriate to its users. In some cases, you are forced to have the application on the Internet so that you
can monitor how the users are using the application.
Another type of test that consumes a lot of time are browser tests, since compatibility between browsers and
browser versions often limits the design options in the user interface.
-
Activities: Implement Components, Integrate each Subsystem, and Integrate the System
In order to validate the architectural decisions made so far on the project, one or more architectural
prototypes are developed and tested, involving successive execution of Activity: Implement Components, Activity: Integrate each Subsystem, and Activity: Integrate the System. Testing, as mentioned above,
should especially focus on the scalability of the application to unpredictable increases in system load.
The basic workflow for the Construction Phase
applies, with the following extensions or variations.
-
Activity: Plan the Integration
Task: Plan Subsystem Integration and Task: Plan System Integration need to address the different
kinds of implementation elements created in the construction phase.
-
Activity: Implement Components
The Task: Implement Design Elements focuses on several different
kinds of elements:
-
Web pages, applets, scripts, graphics, and other elements that "execute" in the browser environment
-
Server-side pages, scripts, servlets, and other elements which "execute" in the Web server environment
-
Executable code enhancements to legacy applications
-
Database tables, triggers, stored procedures, and other elements that execute in the database
management system
The differences in the tools, and the deployment technologies between these different kinds of elements, means
there will be a number of similar variations on the Task: Implement Design Elements. There will be similar
adaptations in the Activity: Integrate each Subsystem and Activity: Integrate the System.
-
Activity: Define Evaluation Mission
Test planning continues to focus on performance testing, but increasingly focuses on functional testing. A
slightly different testing approach is required for each of the different kinds of elements that comprise a web
application. There will be similar adaptations in the Test Activities Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets, in which the focus increasingly shifts
from architectural performance-focused testing to functional testing, ensuring the details of the system
behavior are correct.
-
Product release in the Web environment tends to be incremental and continuous, and less focused on the
traditional distribution of media. Release planning must be adjusted accordingly.
-
User education in the Web environment tends to be integrated into the design of the Web site itself, so that
the use of the site is intuitive. Creation of traditional education and user manuals or documentation is reduced,
with increased emphasis on graphic and content design at the front-end of the process.
-
Production application support in the Web environment must focus on maintaining high availability under
unpredictable load. It may also need to be able to provide the ability to continue running when primary servers
fail, and to allow for server upgrades while the system is running.
-
Knowledge transfer from the development team to the production support team must occur, so that the
production support staff is capable of running the system and performing routine maintenance.
-
Follow up how the users are using the application. This information is valuable for learning who is using
the application and how it's being used. These observations can assist in developing further releases to improve
user interaction.
Portions of this page are developed in cooperation with Context Integration.
|
|
|