Page 1 of 10

A Streamlined Project Life Cycle for Delivering Web

Applications
Author: Aaron Griggs
Date: October 2004

Table of Contents
Table of Contents ............................................................................... 1
Overview ............................................................................................ 1
IT Organization .................................................................................. 2
Web Architecture ............................................................................... 2
Software Engineering ......................................................................... 3
Project Lifecycle ................................................................................. 3
Project Stages .......................................................................... 3
Elaboration ........................................................................ 4
Requirements .................................................................... 5
Design .............................................................................. 5
Implementation ................................................................. 6
Testing ............................................................................. 6
Deployment ....................................................................... 7
Process Improvement ......................................................... 7
Project Roles ............................................................................ 7
Program Manager ............................................................... 8
Project Manager ................................................................. 8
Business Analyst ................................................................ 8
Systems Engineer .............................................................. 8
Software Engineer .............................................................. 8
Tester ............................................................................... 9
Release Manager ................................................................ 9
System Architect ................................................................ 9
Process in Action ...................................................................... 9
Conclusion........................................................................................ 10

Overview
On December 17, 2002, President Bush signed the “E-Government Act of 2002”1. While many
Federal agencies were proactively pursuing more innovative information technology (IT)
initiatives, the E-Gov act mandated a way of doing IT business. With more rigid oversight by
the Office of Management and Budget (OMB), the Department of Commerce (DOC) International
Trade Administration (ITA)2 had to change the way IT projects were managed.

This paper discusses the organization at the DOC/ITA. Then a brief description of software
engineering and web architectures are addresses. The bulk of the work is focused on definition
of a project life cycle to efficiently move IT initiatives to working products.

An example business process document is included as part of the submission: New Contacts
Mass Mailing Business Requirements. One of the biggest shortcomings in the previous project
management was the inability to capture the customer‟s requirements in a persistent form. As
with any customer engineering interaction, the document must be useful to both parties. The

1
http://www.whitehouse.gov/omb/egov/index.html
2
http://www.ita.doc.gov
Page 1 of 10
 Page 2 of 10
use cases illustrated in the example specification provide both the stakeholder and engineers
with appropriate information.

IT Organization
One of the key aspects of E-Gov is making information readily available. The stovepipe
organizational structure of most Federal agencies is a direct deterrent to sharing information.
Thus, the DOC reorganized the IT departments into centralized Chief Information Offices that
aligned with the key business areas

For example, the ITA department which is mainly responsible for promotion of trade exports
centralized approximately fifteen separate IT departments. While the reorganization was far
from painless, slowly but surely the IT responsibilities came to reside under one group located in
Washington, DC. The resultant IT department has many roles and responsibilities. But perhaps
the most difficult tasking is that of the software engineering group.

The software development group evolved from the IT support staff that was already located at
the Washington site. The software group matured from managing the Lotus Notes email system
to writing Domino applications to delving into web applications. Extendable web architecture
was built with the latest technologies to leverage distributed applications.

Web Architecture
The Internet revolution first began as a common network communication mechanism known as
protocols. The Internet Protocol (IP) allowed sending information from one computer to
another. The computers implemented a protocol stack that understood how to construct and
deconstruct network packets. The Internet has become standardized on the Hypertext
Transport Protocol (HTTP) which runs over TCP/IP. In conjunction with HTTP, the Secure
Sockets Layer (SSL) provides secure communications. Another recent addition is Web Services
which commonly use the Simple Object Access Protocol (SOAP). While all this may sound like
techno-babble to those not intimately familiar with the Internet, the point is there are standards
which allow communications between network devices. Device is a more appropriate term than
computer since the type of devices that communicate over the Internet is truly incredible. A
refrigerator can now allow a homeowner to control the temperature from a cell phone.

Like the protocols that allow communication, applications developed into common components.
The two prevailing technologies are Sun‟s Java 2 Platform, Enterprise Edition (J2EE) and
Microsoft‟s .NET. Both relatively new technologies with many similarities, J2EE and .NET provide
a framework for running web applications. Running on top of the HTTP, the application servers
process network requests and produce responses. Abstracting the work of how to send and
receive the requests and responses, the engineer can focus on the actual business processing.
Of course, there are persistent data stores like relational databases that the applications
communicate with in a standard form.

The common components mean less time and money are spent on the engineering of how
systems interact. As any system‟s engineer knows, one of the first concerns in building a
system is how the systems communicate. A benefit of the common web architectures is
performance is scalable. Since the various applications use the same protocols, a load balancer
may be used to delegate requests. As long as the web application is built within the proper
domain, scalability is obtained.

Successfully executing projects is not just about strong technologies, a sound systems
engineering discipline is required. If the customer is not involved and requirements understood,
no matter what technology is employed: the project is a failure.

Page 2 of 10
 Page 3 of 10
Software Engineering
What is software engineering? Carnegie Mellon University‟s Software Engineering Institute
(SEI)3 has gone a long way to define the discipline. Successful corporations are also at the
forefront of defining best practices that make their way into a common model such as the SEI‟s
Capability Maturing Model Integration (CMMI)4. The DOC was not ready for a Software
Engineering Process Group (SEPG) or an attempt at CMMI certification. However, it was primed
for a streamlined process.

In the past, many of the projects were internal IT business re-engineering. The stakeholders
were not involved but provided the end product shown that it saved time and money. Once the
stakeholders understood that there were areas where IT innovation could improve the way they
did business, the requests came in waves.

The performance of the software group was fairly good in that projects were turned around quite
quickly. Yet since there was such a large customer base, certain customers were given
preferential treatment at the expense of drastically delaying other customer‟s projects. The
communications of delays or even project delivery dates was quite poor and the software
development group became regarded as unreliable.

A project lifecycle was required that aided in successfully managing many small deliverables to a
diverse customer base.

Project Lifecycle
The success of a project is probably best qualified as meeting the customer‟s expectations.
Expectations are set through various interactions during the project lifecycle. Utilizing a process
that involves the customer over the different phases is important. The customer should see the
progress of the project and provide feedback. Basically, building something the customer does
not want or need is a useless exercise.

A streamlined process that sets and meets customer‟s expectations is composed of the following
stages:
 Elaboration – Document the business process and requirements.
 Requirements – Document the system requirements from the elaboration stage.
 Design – Design the system that meets the requirements.
 Implementation – Build the product from the design.
 Testing – Test that the implementation meets the requirements.
 Deployment – Release the product.
 Process Improvement – Institute lessons learned and best practices.

The next section lists the detail of each stage.

Project Stages
A project is broken into discrete phases that act as gates to prevent moving to the next phase
with incomplete or incorrect information, commonly called the waterfall approach. Most projects
incorporate a combination of waterfall and spiral approaches that allows proceeding through
various stages yet maintaining enough checks that the product is what the customer desires.
Prototyping key areas are an example where a spiral approach is instituted. Figure 1 illustrates
the process.

3
http://www.sei.cmu.edu
4
http://www.sei.cmu.edu/cmmi
Page 3 of 10
 Page 4 of 10

Figure 1 - Project Lifecycle

Elaboration
Description:
Through use cases, describe the business process. Use cases illustrate the flow of the user
interaction. Properly written use cases may serve as the test plan and user documentation with
minor updates.

Project team:
Business analysts, domain experts

Artifacts:
Business process document (use cases)

Customer input:
The customer must agree to the artifacts since it is the foundation of all future work.

Output:
After agreement on business process, the requirements stage is pursued.

Timeframe:
Since this stage requires feedback from the customer and usually several rounds, the time from
start to finish may elapse over the entire project. Customers always have new and improved
ways of doing things. To limit schedule impact, new customer requirements should be scoped
into future releases.

Page 4 of 10
 Page 5 of 10
Requirements
Description:
The business process is grouped to form system level requirements. Usually, system
requirements are more detailed and specific to the system being built. Well-defined use cases
may serve as the requirements as well.

A very important aspect of the requirements stage is to scope. Most successful projects
eliminate requirements to produce a more focused product. Many requirements are absolute
must haves however there are many instances of requirements that are not necessary to meet
the customer‟s business process.

Project team:
Systems engineers, software engineers, developers, business analysts

Artifacts:
System requirements specification (SRS)

Customer input:
The customer must agree that the requirements meet the business process.

Output:
After agreement on requirements, the design phase and possibly prototyping is pursued.

Timeframe:
Depending on how focused the use cases are this stage may drag on for quite a while. A proper
requirements specification covers everything that impacts design. Upfront analysis and
elaboration are keys to delivering a project on time. However, no project avoids requirements
creep and the project manager and engineers must accommodate some variances.

Design
Description:
Depending on the project size, the design may be nothing more than documenting the system
interactions. The design phase is usually broken into high and detailed levels. The high level
design requires an engineer to think about what is being built. A useful design technique is the
use of sequence diagrams to elaborate the system components and their interactions. The
detail of how a component implements the interaction is left to the detailed level. Detailed
design is quite varied from listing the various software modules to using class diagrams to
completely describe the system.

Project team:
Systems engineers, software engineers, developers

Artifacts:
System design specification (sequence diagrams)
Detailed design specification (class diagrams)

Customer input:
The customer may want to view the high level design but usually it stays within the project
team.

Output:
After agreement on design, the implementation phase and possibly prototyping is pursued.

Timeframe:

Page 5 of 10
 Page 6 of 10
The design depending on the detail may be short or long. The key is elaborating enough of the
system to understand how it will be built.

Implementation
Description:
Implementation involves actually building the product. If the previous stages are done
thoroughly, the implementation should move quickly and smoothly. The use of architectural
frameworks is helpful in reducing the amount of work that must be done during this phase.

Test plans are usually written during this phase. Depending on the use case detail, most of the
information regarding user interaction and such is already completed.

Project team:
Software engineers, developers, QA team

Artifacts:
Product
Test plans

Customer input:
No customer input besides possible demonstrations.

Output:
After implementation of components and unit testing, the system is tested in the next phase.

Timeframe:
With proper upfront requirements and design, this phase moves smoothly. However depending
on the size of the product, it may take a long time to completely implement.

Testing
Description:
The testing phase is often the most neglected of the stages. Usually simple unit testing and
some semblance of integration testing are done. But, regression testing and proper production
configurations are not completed and deployment fails.

Test plans that outline all user interaction (use cases) are ideal to prove the product does fulfill
the requirements. Also, use of automated testing tools and defect-tracking products greatly aid
in discovering and fixing issues.

Project team:
Software engineers, developers, QA team, business analyst, beta customers

Artifacts:
Test results

Customer input:
Beta testers representing the customer should provide feedback.

Output:
After proof that the product works as required, the deployment is done.

Timeframe:
Testing should be done concurrently with implementation. As components are completed,
further testing is possible and may find issues inherent to the system. Proper staging
environments are also required that represent the production environments.

Page 6 of 10
 Page 7 of 10
Deployment
Description:
Deployment should be a quick process of switching over to a new release. Yet, rarely is moving
a product to production straightforward. A common issue is new features breaking previous
versions of the product.

Project team:
Release manager

Artifacts:
New product

Customer input:
Customer should just say it works or some higher praise.

Output:
Product is released to production.

Timeframe:
If proper testing was done, deployment is a very quick switch to the new version.

Process Improvement
Description:
A hallmark of useful processes is constant improvements. An organization must be committed
to building upon the past. Poor performance should be analyzed and the weaknesses
discovered. A process should not be in place just to act as checkboxes.

Project team:
Entire team including customers

Artifacts:
Evaluations, post-mortems, metrics

Customer input:
Customer should be involved in the process and provide feedback to improvements.

Output:
Better process leading to better project execution and delivery.

Timeframe:
Forever

Project Roles
A successful project requires team members to fill specific roles. Roles of individuals may
change during the project with a single person filling many roles. The roles are listed below:
 Program Manager
 Project Manager
 Business Analyst (Customer Liaison)
 Systems Engineer
 Software Engineer
 Tester
 Release Manager
 System Architect

Page 7 of 10
 Page 8 of 10
Program Manager
Responsibilities:
The program manager is critical to maintaining and growing a group. A steady flow of projects
is the goal. Working with customers and other team members, a process to elaborate
opportunities into use cases that can be mapped to projects allows building of the project
pipeline.

Work items:
Project pipeline

Project Manager
Responsibilities:
One person must take ownership to guide the project through the various stages. The
ownership role may change during the phases yet someone must be responsible for successful
delivery. That person is the project manager (PM).

The PM is responsible for overall scheduling and execution of a project. Using the phase
approach and measurable results through the artifacts, the PM can gauge the progress and
impacts. Before scheduling a project, the requirements should be elaborated and scoped as
completely as possible. An understanding of what is being built is required to determine how
long it will take. Therefore, the PM is usually someone that has worked many projects through
all the different phases.

The PM must also understand the skill sets and abilities of the various resources. One software
engineer may work much faster than another for example. The PM must also help in motivating
the other team members to tap their full potential.

Work items:
Project schedule and resource allocation

Business Analyst
Responsibilities:
Business analysts are domain experts in the project areas. They know or work with the
customer to understand the business process. The analysts should also know what the existing
systems do.

Work items:
Business process (use cases)

Systems Engineer
Responsibilities:
Systems engineers take business process and map to system requirements. System engineers
are experts in component level interactions and functionality.

Work items:
System requirements

Software Engineer
Responsibilities:
Software engineers take the system requirements and map to software components.

Work items:
Product

Page 8 of 10
 Page 9 of 10
Tester
Responsibilities:
Tester builds test plans and tests the product.

Work items:
Test plans

Release Manager
Responsibilities:
Release manager (RM) maintains the work item repository including:
 Source code repository
 Requirements, design documentation
 Test plans
 Production environment

For example, CVS is maintained and run by the RM. The RM is responsible for versioning the
releases and deploying to the production environment. Concurrent projects may require
branching of the source repository and then later merging the branches back to the main
release.

Work items:
Configuration management

System Architect
Responsibilities:
An often-overlooked role, the system architect is responsible for evolving the system through
new practices and frameworks. Usually the guru of the system, the architect takes ownership of
how the product is constructed. An architect leverages the latest architectures and
methodologies to ensure streamlined maintenance and functionality. Note the entire system
from front-end interfaces to backend database schema is under the architect‟s control.

Work items:
A better system

Process in Action
Now that the process and roles are defined, how does this provide successful delivery? First,
the process is the mechanism for repeatable and measurable results. After completion of
projects, post-mortems are done to constantly improve the process. Next, the clear definition of
the roles keeps division of labor and focus clear. Finally, the different stages produce concrete
artifacts that gauge the projects scope and issues.

To improve upon a process, the process must be documented with measurable results. Just as
the source code is under version control, the documentation must be accessible and controlled.
The program manager maintains a project pipeline of all available work items. The pipeline
should constantly grow with input from many different sources. As project plans (specifications)
are matured, the project is grouped into a release. The release schedule is documented and
maintained.

Table 1 illustrates a project repository (pipeline) composed of links to the specifications that
document the project. A specification is the business process (use cases), requirements, design
and other information. A project may contain more than one specification depending on who
documents and size of the tasking. For multiple documents, the various specifications link to
each other to maintain the relationships. The main specification will always be the one

Page 9 of 10
 Page 10 of 10
containing the business process since the use cases are more readable than system
requirements.

Project CSR Current Stage Contact Customer

QAS Dissatisfied 364 Testing Jane TD
Products/Services redesign 375 Released Finance
NAFTA Export.gov Integration 376 Released John OCIO
Single Sign-On 378 Implementation John OCIO
Marketing New Contacts 380 Elaboration George Marketing
CS Trade Leads 382 Implementation George CS
Congressional CMS Contacts 385 Requirements Jane CS
Report
One-Stop Admin 388 Elaboration George OCIO
Business Process 1 Elaboration CS
Business Process 2 Elaboration CS

Table 1 - Project Repository

Table 2 lists the release schedule. A release is a collection of projects as well as minor bug fixes
and enhancements. Every release is documented with release notes detailing the changes.

Release Project Technical Lead Est. Date Actual Date

2.0 06/30/2004 06/30/2004
Products/Services redesign Chris 06/15/2004 06/10/2004
NAFTA Export.gov Integration Tim 06/15/2004 06/01/2004
2.1 07/30/2004
CS Trade Leads Jim 07/15/2004
2.2 08/30/2004
Marketing New Contacts Tim 08/15/2004
Single Sign-On Tim 08/15/2004
2.3 09/30/2004

Table 2 – Releases

Use of a project repository and release schedules open up the process to others. For example,
the CIO can look at recently complete or upcoming releases. By clicking on the „Release‟ or
„Project‟ the information about the specific release is available. Since multiple people modify the
specifications during a project, a content management system (ex: Share Point) would aid in the
project repository and release schedule maintenance.

Conclusion
The process discussed in this document is a starting point to better project management.
Managing customer expectations through iterative artifacts and measurable results goes a long
way to ensuring success. When the customer sees a process that works, the customer works
with the process.

Here at the DOC, the development team has begun instituting the outlined process in
incremental steps. Customer feedback has been good and team members seem to embrace it.
One of the major benefits of such process is the removal of the stopgaps and heroes from the
development team. As a team, it is great to have motivated, bright people. However, no one
person should prevent a project from succeeding. The process facilitates information sharing
and distributes the knowledge. In combination with good architectural frameworks, projects will
complete faster with fewer issues and delighted customers.

As with any project, success is ultimately determined by the people. The project team must
work together understand and accept their roles. A team with members that strive to improve
their skill sets and embrace more responsibility ultimately decides the outcome.

Page 10 of 10