Professor Michael Shoukat
Course MSIT650 Section 9040
Design Web Applications
the Systems Engineering Way
July 08, 2001
Robert D. Betterton
Many web applications have been
deployed to the Internet since it went public back in 1994. Many
of these applications have been developed by nothing more then fly by
the seat of your pants, usually put together with cowboy heroics. It
is very clear that the development of many of these web applications
did not make use of CASE tools and/or even use the SDLC (System Development
Life Cycle) System Engineering methods for bringing about a web application
system to the Internet/intranet. This paper will show the role that
CASE tools play in ensuring the success of a web application system
that uses the proper systems engineering methodologies in the design
and implementation of web applications.
This will be accomplished by showing
how a web application will start with a vision, with this vision translated
into requirements with the help of a CASE tool to capture the upper-CASE Tool events
of the SDLC for this web application system. Remembering that a "system"
is a purposeful collection of interrelated components that work together
to achieve some objective (Sommerville 2000).
Why do we need Systems Engineering
to help with Web application development? Because there is a "need"
for a structured approach to everything from Human factors to a Web
application that does what it is suppose/advertised to do, and does
this function reliably, with ease, and user understanding. Elimination
of the causes of web application systems failure lie in the application
of system engineering methodologies, modeling tools, and techniques to
design web application systems development and build web application
systems that not only meet the needs of users but also are delivered
on time and within budget.
Consumers, or end users as we more
commonly refer to them, want to find information quickly and easily.
Contrary to what you might conclude from observing the architectures
of many large, corporate web sites and/or applications, users do not
like to get lost in chaotic hypertextual web [applications]. Poor information
architectures make busy users confused, frustrated, and angry (Rosenfeld
As Powell states "Web site [application]
design is not graphic design. Far too many books treat Web site [application]
development as simply the choice of a usable interface and an appropriate
market identity, or the production of correct HTML. This is a simplistic
way to describe Web development. Certain classes of sites certainly
fall into such generalizations, but what about intranets? What about
Web-based applications? What about transactional systems? The list goes
on." (Powell 1998)
Many web applications fall into
the categories listed below and their complexity just demands a Systems
Engineering approach to their development and success. A "Web Systems
Engineering Principle" is needed.
Here are the some of fields in
which Web Applications have been developed:
- Business-to-business E-Commerce<,/LI>
- XML Interfaces,
- Catalogs and Multi-vendor catalogs,
- Data Warehousing and Archiving,
- Data Migration,
- Content Management,
- Corporate Portals,
- Application Integration,
- Meta Searching.
Below is a diagram of the basic
"Web Application Infrastructure Model":
As shown above, as a web application
is delivered from a server to a an end user, client issues, server issues,
database issues, and network issues will influence the user's perception
of the Web Application. In short, things can go wrong everywhere. The
problems are distinct, and yet part of the whole that the user sees. Thus,
to minimize the possibility of failure, a rigorous approach to web
application development should be adopted. The methodology defines the whole
web delivery process.
A LITTLE WEB HISTORY:
When the Web first started out
in 1989, and then organized in 1994 to the W3C, by the inventor Tim
Berners-Lee (Berners-Lee 2002), I believe Tim didn't envision its rapid
growth to what is today. That is, an Internet WWW system that has grown
exponentially (Carpenter 1996) and is now the life blood of may companies
world wide. With this activity has come rapid web application growth.
This growth has brought with it may applications and/or Web system problems.
These problems stem from poor user interfaces to poorly designed web
applications that users have difficulty using.
Tim (Berners-Lee 1998) even states
on the W3.org web site: "Again and again we fall back on the folklore
of the principles of good design. Sometimes I need a URI for them so
this is started as collection of them. I have written about some in
many places. Principles such as simplicity and modularity
are the stuff of software engineering"...
Tim further states "Keep it simple,
stupid"... I believe with system engineering concepts, that simple to
complex web applications can be kept simple and clean, well organized
and maintainable with systems engineering principles and CASE tools.
Systems Engineering gives us the methodologies and discipline to bring
about a web application and CASE Tools give us a way to keep it all
organized, tied together, and documented.
- WEB APPLICATION DEVELOPMENT NEEDS A SYSTEMS ENGINEERING STRUCTURE
Of course the answer to structured
Web Site Application design is the Systems Engineering approach along
with a CASE Tool to help design and document the entire process.
Regardless of an applications purpose,
as described in the above web application list, all well-implemented
web applications exhibit similar characteristics, just as good software
does. Quality software should be maintainable, reliable, efficient,
and provide the appropriate user interface (Sommerville 1992). Web applications
are no different, they should also function properly and reliably, download
or execute efficiently, and provide the appropriate presentation. There
are numerous aspects to the well-engineered Web application; and developers
should always strive to meet the following goals:
- Portable and Scalable,
- Robust and Reliable,
- Well Documented,
- Appropriately Presented.
THE SOLUTION - SDLC
USING THE WATERFALL MODEL WITH FEEDBACK AND PROTOTYPING
Below is an overall diagram of
the SDLC using the waterfall model with feedback and Prototyping. Of
course there are other SDLC process models that can be used to guide
us, such as:
- Waterfall Model
- Modified Waterfall Model
- Evolutionary Model
- Incremental Model
- Spiral Model
- Vee Model
However, experience has shown that
the waterfall model with feedback and prototyping works best for developing
web applications. Using a CASE tool with the waterfall model aids in
the documentation and construction of the web application as well. The
SDLC phases will provide a general framework for our web applications
business life cycle.
THE WEB SYSTEMS PLANNING
Before any coding is even considered
for a Web Application. It is very important to figure out what the system
is suppose to do, what problem is it trying to fix, or solve. Can it
be done another way, besides using the web infrastructure? Basically
what is the "vision" for the new web application, who needs it, why
do they need it? This is the problem definition and explanation phase.
It has been shown that software developers who spend more time planning
and less time writing code finish their projects faster (Card, McGarry,
and Page 1987; Card 1987).
Before deciding which technology,
design, and content will be used in a web application, the purposes
and goals for the application must be clearly established. Without a
clear idea of the web applications purpose, the project may never get
started. Even if it does, it may be working toward the wrong goals (Powell
Planning becomes the fact-finding
part for the web application system, in which:
- We need to understand the problem or opportunity,
- What is the motivation for the web application,
- Define the web application project scope and its constraints,
- Perform fact-finding, where we would conduct interviews to elicit
end users, managers, stakeholders, and the application owner. Remember,
we just want to uncover facts,
- Review any documentation about the desired web application, perhaps
conduct a survey of individuals currently using a system that is being
replaced by the new web application,
- Confirm project feasibility,
- Estimate the web applications benefits,
- Estimate the web applications development time and cost,
- Presents results to management,
- Staff the project,
- Launch the project.
Developing a problem definition
doesn't need to be difficult as shown in the diagram above. There are a
variety of general questions
that can help elicit and stimulate ideas and help develop a problem
definition. If the upcoming project is a modification to or upgrade
of an existing application, consider the history of the web application.
Consider who has been involved in creating and maintaining this application,
and its original purpose. Very important, don't confuse looking at the
old web application for ideas with blame placement and criticism of
previous work. Web applications evolve, problems change. What appears
to be nonsense now may have been appropriate in the past. Pointing out
individual's past failures during the problem definition phase is guaranteed
to create ill will within the project team.
We need to confirm that the web
project is feasible. Many web projects are initiated as part of an enterprisewide
strategic plan. Within the overall plan, each web project must stand
on its own merit. Feasibility analysis investigates financial, operational,
technical, and schedule feasibility. All of these areas need to bo applied
to a web application regardless of its complexity.
The total plan for the web project
is reviewed with upper management or directors and the web project is
initiated. Initiation of the web project entails allocating funds, assigning
project members, and obtaining other necessary resources such as office
and development tools. An official announcement often communicates the
web application project launch.
WEB SYSTEMS ANALYSIS
Here we are concerned about gathering
the requirements for the new web application system. We need to elicit
management, end users, and other stakeholders who have an interest in
making the application come to life. Requirements analysis is what I
like to call requirements engineering and it is a very important part
of the life cycle of a web application. This is due in part because
if we don't gather what an end user wants are needs for the application,
it will most likely not meet the end users needs.
Thus the primary activities for
this part of the Web Application System will be:
- Gather information about the needed Web Application,
- Define the web applications systems requirements,
- Build prototypes for discovery of the requirements,
- Prioritized the requirements,
- Generate and evaluate alternatives,
- Review the recommendations with management.
Thus, we need to learn as much
as possible about the web applications problem domain -- this is usually
the area of concern for the "user's business". It is the area which
needs an information system solution (the web application). It is the
area that is being researched. We need to state and understand the requirement
characteristics, they must be:
Requirements Engineering lie at the heart of
a well-run Web Application project, supporting many of the other technical
and management activities. Changes you make in your requirements development
and management approaches, will affect these other web application processes,
and vice versa. The diagram below illustrates some of the connections
between requirements and the other processes. (Wiegers 1999)
The diagram above shows the process
of how requirements are related to other Web Application projects.
As Young States "Dealing effectively with requirements tops the list of the
chanllenges to managers and practitioners developing systems and
software (Young 2001)."
THE PROTOTYPE PROCESS TO
GATHER/ELICITE USER REQUIREMENTS
In the above diagram is shown
a typical web application requirements elicitation process which is
transferred to prototyping as the requirements are defined and allows
for the construction of web prototypes. The object of creating prototypes
is to assist, in some way, the development of target or delivered web
Below is another point of view
regarding the requirements engineering process for generating web applications:
The importance of
A software prototype is a preliminary
version or a model of all or part of a system before full commitment
is made to develop it (IT-STARTS, 1989). A software prototype can also
be part or all of a system that is developed and delivered using an
iterative approach in which users are involved. Prototyping is the process
creating a prototype (Smith 1991).
The objective of creating prototypes
is to assist, in some way, the development of target or delivered systems,
in this case a web application system. Major issues of web application
development as shown in the diagram below can be addressed by prototyping
are elicitation, demonstration, and evaluation of the following:
- Data requirements and structure,
- Function requirements,
- Operation and performance, and
- Organizational needs and issues.
In normal usage, a prototype
is a trial model or a preliminary version of a product. In conventional
engineering projects, prototyping at reduced scale, with simplified
versions of products or with a pre-production product, is long-established
tradition. The idea of producing a building, a bridge, an automobile,
or an aeroplane without a prototype or model is almost inconceivable.
Prototyping at an early stage in the development of a product allows
evaluation and adjustment before the design is finalized (Smith 1991).
Caveat about Prototyping -- don't
let end user's or management think that because they have experienced
a web prototype that the design of the web application system is finished
and deployment can proceed to the Internet/intranet. A prototype is
just what the word implies and described above -- it is an example of
what the web application can be like, to help elicit end user's and
managers input. To help gather requirements on how they want the web
application system to take shape and/or function. It is an evolutionary
Below are some web application
THE USE OF DFD, AND
ERD DIAGRAMS, DICTIONARY AND REQUIREMENTS DICTIONARY FOR REQUIREMENTS
GATHERING -- GETTING IT DOWN ON PAPER OR IN THIS CASE INTO A CASE TOOL
The CASE Tool of choice is MacA&D
or WinA&D from Excel Software. For this paper the diagrams were produced
from MacA&D. This CASE Tool is used to show examples of how a Web
Application can be created and stored for documentation purposes. This tool
is used because it is robust enough with the required models needed to show how
a web application can come together. Excel's CASE Tool suite is known as an upper-
CASE Tool because it supports analysis and design and supports early phases
of the software process.
The tool is capable of producing
many modeling alternatives that fit both the standard structure to object
oriented forms of information and system engineering modeling. Below is an
example of Excel's capabilities:
- UML Modeling,
- Data, Process and State Modeling<,/LI>
- Real-Time, Multi-Task Design,
- Requirements Management,
- Code Generation and Reengineering,
- Bug Tracking,
- Help Authoring,
Supported methods and notations include UML, OMT, Booch, Shlaer/Mellor,
Yourdon/DeMarco, Gane & Sarson, Hatley/Pirbhai, CRC cards and Martin's
Information Engineering. These tools promote an engineered approach to
software development with integrated models, requirements traceability,
code generation and reengineering of code to design.
Below are examples of some web application
DFD, ERD, Dictionary, and Requirements diagrams:
Above is an example of the DFD of the Application Tracking System.
Above is an example of the Top level (Context) ERD of the Application Tracking System.
Above is an example of the DFD Dictionary entry for the Application Tracking System.
Above is an example of the ERC Dictionary entry for the Application Tracking System.
GENERAL WEB SYSTEM DESIGN
The phase describes in board and conceptual terms the web application
system design components of several design alternatives that aim to
fulfill user requirements. These alternatives can be made up of
prototypes constructed during the requirements gathering phase of the
Why do we produce several general systems design alternatives? Constraints
imposed on the project and an array of user requirements may interact in
complex ways such that a number of designs are needed rather than a single
design. The results of the general systems design phase are several
plausible conceptual systems design deliverables compiled in the general
system design report. These general systems design alternatives are ready
for evaluation and selection of the optimum one for the detailed systems
Facts gathered, analyzed, and modeled during web systems analysis provide
the basis on which general systems design alternatives are created.
The web system analysis phase was investigative and discovery-oriented. Now
new or different features of the basic models need to be considered. The
key in general web systems design is to produce updates in the CASE Tool
without trying to refine the web systems design too early. The game plan:
Interact with users, check with team members, check with technicians;
redesign, check, check, and recheck, but don't try to develop low-level
detail or mini-specs during this phase. This will come later after a
general web systems design alternative has been chosen for implementation.
WEB APPLICATION SYSTEM
EVALUATION AND SELECTION
The evaluation and selection phase entails a process by which systems
value and costs and benefits of alternative general web system designs
are compared, and one is chosen for the detailed design phase. The
evaluation and selection phase is an optimizing process that seeks not
only a workable design, but also the best possible design for meeting
the user requirements.
Decisions to replace current systems with one of the general web systems
design alternatives are difficult. This phase provides a means by which
management can make informed decisions during this critical point in the
WEB APPLICATION DETAILED
The objective of the design phase
is to design a solution for the web application system. The design phase
uses the information obtained during the analysis and prototyping phases
as its input. High-level design consists of developing, an architectural
structure for software programs, databases, the user interface, and
the operating environment. Low-level design entails
developing the detailed web application algorithms and data structures
that are required for program development. At this phase there are seven
major activities that must be done during the design phase:
- Design and integrate the network,
- Design the application architecture,
- Design the user interfaces from the Prototypes,
- Design the system interfaces,
- Design and integrate the databases,
- Prototype for design details,
- Design and integrate the system controls.
Design activities are closely interrelated and generally are all done
with substantial overlap.
The network consists of the computer platforms and associated equipment
such tape backup, the network, and operating systems platforms that
will house the new web application system. Because a web application is
a network entity, design also includes configuring networking items such
ODBC, security, data source connections, etc.
The web application is now a portion of the new information system that
satisfies user needs with regard to the problem domain in which it was
defined. The web application provides the processing functions for the
business requirements. Designing the web application consists of using
the model diagrams of the requirements that were developed during the
analysis to design the appropriate web application.
Like with any software package,
a web application is no different when it comes to the user interface.
It is a critical component of any new web application. During the analysis
as we discovered above, prototyping was used to define the elements
and fields of the user interface. During design, these prototype elements
and fields are all combined to yield an integrated user interface consisting
of form, reports, screens, and sequences of interactions.
Most new web application systems
must also communicate with other, existing systems elements and web
applications, so the design of the method and details of these communication
links must also be precisely defined.
Databases and information files
are an integral part of web application systems for business. The model
diagrams (ERD, Class, dictionary, etc.) that make up the new web application,
came from the requirements developed during analysis. They are now going
to be used to design the database that will support the new web application.
At times, the database for the specific system must also be integrated with
information databases of other systems already in place. A lot of times,
many web applications are just front ends to existing or legacy database
During design, it is often necessary
to verify the correctness or workability of the proposed web design.
One important verification method is to build and improve the prototypes
that were created during the analysis phase of the project. Here you
can also verify alternative design strategies by building additional
prototypes of the new web application system. Sometimes, if the prototypes
are built correctly, they can be saved and used as part of the final
Final thoughts on the design of
the web application system is that the application must have sufficient
controls to protect the integrity of the database and the web application
program. This is largely due to the highly competitive nature of the
global economy and the risks associated with the technology and security,
every new web application system must include adequate architecture
to protect the information assets of the organization. All web application
must pass through an authorization, authentication system if the web
application is communicating directly with the Internet.
WEB APPLICATION SYSTEM STARTUP, IMPLIMINTATION, AND TESTING
During the implementation phase,
the final web application is built, tested, and installed. The objective
of the activities of this phase is not only to have a reliable, well-working
web application but also to ensure that the users are all trained and
that the organization is benefiting as expected from use of the new
web application. All the prior activities must come together during
this phase to culminate into an operational web application. Basically
there are five major actives that make up the implementation phase:
- Construct all web application modules,
- Verify and test the web application in a testing environment,
- Convert data (if it applies),
- Train users and document the system from the CASE Tool and other
sources of info,
- Move the web application to production,
The web application can be constructed through various techniques. The
conventional approach is to write code using languages such as Visual
techniques, based on development tools and components, such as BBEdit,
Dreamweaver, UltraDev, Coldfusion Studio, etc., are becoming popular today.
The web application must also be tested, and the fires kind of testing
verifies that the web system meets the needs of the system's users.
WEB APPLICATION SYSTEM
The objective of the support/maintenance
phase is to keep the system functioning productively during the years
(in the web world this can be months) following its initial installation.
The support phase is normally not included as part of the SDLC since
it begins only after the system has been installed and placed into production.
However, maintenance needs to be part of the SDLC even if this part
of the phase is very long, lasting throughout the productive life of
the new web system. The expectation for most web business systems
is that the system will last for years, but in reality they may only
last months due to changes made to the web system.
I believe it has been shown that
the proper process's and procedures to designing Web Applications is
to use the Systems Engineering approach using a CASE Tool and Prototyping.
Systems Engineering gives us the SDLC that allows us to follow a process
to bring order to web application development, prototyping allows and
helps us in the elicitation of web application and system requirements,
and the CASE Tool allows us to document the process as well as aid in
the requirements gathering.
Bottom line, all of the above steps allow the other phases of the SDLC to complete with
Card D.N., (July/August, 1987). "A Software Technology Evaluation
(pp 291 - 300), Information and Software Technology
29, No 6.
Card D.N., McGarry F.E., and Page G.T.
(July, 1987). "Evaluating Software Engineering Technologies."
(pp 845 -- 851), IEEE Transactions on Software Engineering SE-13, No 7.
Carpenter B. (June, 1996). Architectural Principles
of the Internet
Excel Software -- Developers of Extensive CASE Modeling Tools
Ince D., (September, 1989).
"The software prototype", EXE Magazine. Web page Design
(pp. 61-62) IT-STARTS, Developers' Guide, National Computing Center, Manchester.
Powell T.A. with Jones D.L, and Cutts D.C., (1998).
Web Site Engineering, beyond Web page Design (pp ix,
93-94. ) Upper Saddle River, NJ: Prentice-Hall, Inc. ISBN 0-13-650920-7
Rosenfeld L. & Morville R. (February, 1998).
Information Architecture, for the World Wide Web; Designing Large-Scale
Web Sites (pp 12. ). Sebastopol, CA: O'Reilly & Associates,
Inc. ISBN 1-56592-282-4
Smith, M.F., (1991).
Software Prototyping, Adoption, Practice and Management,
(pp 42-45. ) Shoppenhangers Road, Berkshire, England: McGraw-Hill Book
Company (UK) Limited. ISBN 0-07-707241-3
Sommerville, I., (1992). Software Engineering, 4th Edition (p4. )
Upper Saddle River, NJ: Addison-Wesley ISBN 0-20-139815-X
Sommerville, I., (2000). Software Engineering, 6th Edition
(p13, 21.) Upper Saddle River, NJ: Addison-Wesley ISBN 0-20-139815-X
Young R.R. (March, 2001). Effective Requirements Practices
(pp xxiii. ). Upper Saddle River, NJ: Addison-Wesley
Wiegers K.E. (1999). Software Requirements
(pp 56-57. ). Redmond, WA: Microsoft Press
Wide Web Consortium (W3C, 2001). http://www.w3.org/
The World Wide Web Consortium (May, 2001). [System
Engineering Mark Up Schema] http://www.w3.org/Archives/Public/xmlschema-dev/2001May/0032.html
Berners-Lee T. Tim Berners-Lee (Personal Web
Site, 2002). http://www.w3.org/People/Berners-Lee
Berners-Lee T. Principles of Design (W3C, 1998).