Roadmap:
Developing e-business Solutions
Topics
Activities across the lifecycle:
|
Concepts:
White papers:
|
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.
The basic concepts and technologies used in an e-business solution are described in Concepts:
e-business Development.
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.
Business Modeling
In general, there is a much higher focus on business modeling
compared to other types of development efforts. To develop an e-business
application generally means to develop a new way of doing business; it's an
integral part of the way you run your business.
The focus here is to understand the
problems the new business should solve, and also the effects of not developing the
new business.
Building e-business solutions involves a
greater variety of stakeholders than other software application development
projects. These stakeholders will usually include business executives,
marketing, creative design, customer support, and the technology development
team, among others.
The Activity: Set
and Adjust Goals focuses on ensuring that the new business
will meet the needs of this varied group of stakeholders. The primary artifact
where these needs are expressed is the Business
Vision. Given the diverse backgrounds of the stakeholders, a facilitated
workshop, like the one described in Work
Guidelines: Requirements Workshop, is often needed to bring the group
together. Extensive use of storyboards to describe the desired customer
experience tend to be useful in eliciting feedback (see Work
Guidelines: Storyboarding).
Sometimes the stakeholders are not available because they
are only on the Internet. In these cases an important role of the Business
Vision document is to describe how the stakeholders or customers should find
the Web site and how user feedback is going to be collected. As well, in these cases
you can develop prototypes to learn how customers find the Web site and how
they are using it. The need to obtain this kind of feedback may affect the
length of the iterations and the product lifecycle.
Describe in detail enough about the current business in order to
determine where any issues are and where you have the best potential
for improvement.
Focus on understanding the scope—limit the organization to
be modeled to your area of influence. Within in those boundaries,
prioritize only the business use cases that will be automated.
Detail prioritized business use cases.
Even though you may be aiming at completely automating your
business processes, a business worker concept is useful. In the final
business object model, you will have two types of business workers—automated and non-automated.
Business workers' responsibilities are described to a level of detail
necessary to make decisions on what to automate.
Focus on understanding what level of automation is realistic
to achieve, and what limitations any legacy systems have on what can be done.
This is not performed separately. The information normally captured in
a domain model is already part of the business object model.
Requirements
This has less emphasis.
Most of the problems should already
have been found in Workflow
Detail:
Assess Business Status and Workflow
Detail:
Describe Current Business from the business modeling discipline.
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).
The Activity:
Model the User Interface summarizes the use cases and the 'Creative
Design Brief', and produces a navigation map. A
navigation map is a view of the Web solution that shows how users of
the site will navigate it, 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 Artifact:
Use-Case 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.
Environment
The importance of the Activity:
Develop User-Interface Guidelines 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 Artifact:
User-Interface Guidelines; it is essentially an early version of the
user-interface guidelines.
The basic workflow for the Elaboration
Phase applies, with the following extensions or variations.
- Workflow
Detail: Define a Candidate Architecture
The Activity:
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 Concepts:
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.
- Workflow
Detail: Analyze Behavior
The Activity:
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 Activity:
Identify Design Elements refines the Artifact:
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 Modeling
Web Application Architectures with UML.
- Workflow
Detail: Refine the System Definition
The Activity:
Prototype 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 an early, non-functional version of the Artifact:
User-Interface Prototype.
Once there is agreement and sign-off, the
creative design comps evolve into a functional user interface prototype
through repetition of the Activity:
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.
- Workflow Detail:
Prepare Guidelines for an Iteration
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
components across the whole site.
The development of these elements is an extension
of the Activity: Develop
User-Interface Guidelines and includes the creation of guidelines
for their use. Ensure that all team members understand when and how to use
these components. 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 components.
The Activity:
Develop User-Interface Guidelines is performed in conjunction
with the development of the Initial Web UI Prototype. 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.
- Workflow Detail:
Refine the Architecture
The Activity: 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 Activity: Describe
the Run-time Architecture becomes focused mostly on the Web server and
application server tiers (see Concepts:
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 Activity: 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.
- Workflow Detail:
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 Workflow Details 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.
- Workflow Details: 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 Workflow
Detail: Implement Components, Workflow
Detail: Integrate Each Subsystem, and Workflow
Detail: 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.
- Workflow Detail:
Plan the Integration
Activity: Plan
Subsystem Integration and Activity:
Plan System Integration need to address the different kinds of components
created in the construction phase.
- Workflow Detail:
Implement Components
The Activity: Implement
Component focuses on several different kinds of components:
- 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 components, means there will be a number
of similar variations on the Activity:
Implement Component. There will be similar adaptations in the Workflow
Detail: Integrate Each Subsystem and Workflow
Detail: Integrate the System.
- Workflow Detail:
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 components that
comprise a web application. There will be similar adaptations in the Test
Workflow Details 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 roadmap are developed in cooperation with
Context Integration. |
 |
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Overview >
Roadmaps >
