Successfully
Managing the Software Development Lifecycle
by
Martin
Rudy
How can you ensure a software project is successful? How do you manage the
development lifecycle to prevent the project from not being completed? There
are many project management techniques and software options to use as a set of
tools for managing software projects.
This session is not a text book presentation but a collection of items from
experience that can improve the success of a software project. Tips are shared
showing how to improve successes for software projects and how to avoid some of
the common mistakes that too often prevent completion of a project. Topics
range from all aspects of the project lifecycle. For the most part, they are
not software product specific, but techniques that can be used for software
development with one or more members on the team.
The major topics covered are:
What
is a successful software project?
Contents
How do you measure the success of a software project? The answer: It
Depends! There are many viewpoints from which to measure success. A common
measurement of on time, on budget and great quality is one yardstick but there
are different angles from which to determine success. Some say you can only
achieve two of the three. Management, developers, and end-users have a
different perspective to success. It also depends on the target audience of
the software.
As you start any project, this is an essential question to answer upfront.
Define the answer from each perspective and look to include the answer in the
lifecycle from the start to final delivery.
Contents
An application lifecycle is essentially the womb to tomb journey of a
software project. Definitions of what constitute a software lifecycle vary but
to set a base for this session the major components of a lifecycle are as
follows:
7
Define what has to be automated requirements gathering
7
Design logical and physical models, forms, classes, flow
7
Develop the application write the code
7
System Testing unit-level, beta, gamma, production
7
Documentation technical, system, user
7
Implementation production release
The application lifecycle components are not necessarily sequential tasks.
Some components can be performed simultaneously. Depending upon the user's
needs and deadlines, one task might be performed before another. The details of
each component and the management of all the components determine the success
of the project and how smoothly the lifecycle flows.
There is constant interaction between user and developer during the
application lifecycle. In many cases, you can build a prototype of a portion of
the application to help determine the best solution. The application lifecycle
for any product starts when a client wants to automate a process or needs to
update an existing automated application. To determine what type of technology
should be used you must collect the user's requirements. From there you
determine if and how to proceed.
Define what has to be automated requirements gathering
Requirements gathering rounds up information and determines the purpose and
scope of the application. You must literally ask the user, "What do you
want this system to do? What problem do you want the application to
solve?" Start your information gathering with the existing system, whether
it is manual or automated. Interview users (not just specifiers) of the current
system and find out what is working and what isn't. How do they really use
their current system? What work-arounds have they created to make it function?
What pieces of information and methods have they added to accomplish their
business tasks? This interview process gives insight into the real, especially
the hidden, requirements of the application. Is the current system adequate, and
if not, what changes need to be included in the new application?
The requirements gathering process can be either a one-on-one interview or a
survey exercise. The interview/survey assists you in finding the requirements
of the application. Following is a partial list of questions.
7
What is the major purpose of the system? (What is the driving
question or need that must be fulfilled?)
7
Is the application used by more than one person at a time? (Is it
a single or multi-user system?)
o If
multi-user, how many concurrent users?
o What
type of concurrent processing will be done?
o Does
it need to be a two-tier or multi-tier application?
o Is
it a web-only application
7
To what level will there be insertions, updates, and queries?
7
What type and level of security is needed?
7
If this is a database application, has the DBMS already been
determined or can there be a selection process?
7
What are the users' interface requirements? How do they want the
system to look?
7
What level of Help is required, and how should it be made available?
7
What are the priorities of the application? What information and
processes are crucial to the system's success?
7
What kind of performance/response time does the user require?
7
What kind of ad-hoc query and reporting are required? Does the
user want the ability to modify the programs?
7
Must the proposed system be integrated with other systems?
7
What kind of data validation and integrity is required? How
should validation and integrity be applied?
7
How large is the system? How much data will be stored? For how
long will it be maintained? What is the volume of activity? How big are the
records, and how many are anticipated at any given time?
7
How is the data input? Data entry? Downloaded from a mini or
mainframe system?
7
Does the output need to be sent to other automated systems?
7
Will the system be accessed seven days a week, twenty-four hours
a day? Five days a week, eight hours a day?
Whether the current system is manual or automated, you should diagram its
sources of input, manipulation of data, and output of information. The diagram
provides a great picture of the business, and is very beneficial in analyzing
the activities the application must perform. Look at the current input and
update forms (or screens), inspect reports, analyze the data interchange
occurring with other systems, and dig out current system documentation if it
exists. Look for special processing requirements. It is crucial that the
developer understand the flows and processing necessary to the business. To
implement the system a user wants, you must understand what things are not
being addressed in the current process and include those missing items in the
new system. You should also ask the users what they don't like about the
current system and correct them in the new/updated application. Once you have
the system's information requirements (the requirements specification or
requirements document), you are ready to create the logical and physical
design of the system.
Borlands CaliberRM provides a requirements management system that
facilitates the requirement gathering process and communication between team
members. Figure 1 shows the CaliberRM user interface.
Figure 1: CaliberRM user
interface
Design logical and physical models, forms, classes, flow
The goal in this component of the application lifecycle is to provide logical
and physical designs. For database applications you identify the types of data
the user needs and how it is to be grouped. Time should be taken to carefully
design a logical model of the data. A good logical database design can save
hours of rework later in the development process.
In designing a logical database model there are many design techniques --
entity/relationship models, extended relational analysis, normalization, or
other design technique. No matter which technique you choose, the result you
want is to create the logical design of the database.
Creating a database's physical design is the beginning of the real hands-on
work in the database selected. Tables are created from your logical data model.
As with many of today's relational databases, the physical databases may not
exactly match the logical model. This is usually due to an absence of certain
relational features or known performance enhancements that are gained through a
change in the physical design. If limitations are known up front, fewer changes
will be required later.
While analyzing the program design, the system is broken up into modules.
Identifying the major processes in an application determines the number of
modules in a system. Typically, application modules include:
- Data input
- Data
modification (changes and deletions)
- Data output
(reports, graphs, ad-hoc queries, data export, email)
- Logging
- Data backup
and recovery
- Maintenance
and/or administrative tasks
Now define the common processes used by each, and decide whether multiple
modules can be consolidated. This helps eliminate coding separate modules and
duplicate procedures that perform basically the same tasks. In so doing, you
decrease the size of code to be created and maintained.
Next, decide on how you plan to handle errors that occur during processing.
What do you want to centralize and what error handling is done at the point of
execution. Also, determine the type of error recording and presentation to
users will be incorporated. You may also want to think about using a standard
set of error and informational messages which have a unique id number, standard
text message, and description of the potential cause of the error.
Documentation of these should be included in the documentation phase.
Form prototypes paper or electronic greatly remove ambiguity for the
developers. If possible, one of the two should be done, or at least include
time for screen development, review and approval in the schedule, budget and
cycle.
Tools such and ModelMaker and Bold assist in class definitions and make
development and maintenance easier.
Report prototypes can be done on paper or mockups electronically. Getting
some basic standards or templates up front and inherit from the templates
provide consistency. If ad-hoc reporting is required, the tool selected should
have some base template reports.
Once the design phase is complete the coding begins. Depending on the size
of the project, there may be multiple design and coding phases. While the
coding is being done on the first phase, part of the team can be designing the
second phase.
Develop the application write the code
Developing the application is where the design comes to life. The
development team takes the design package and methodically turns it into a
product. Here the skills of each developer are fully utilized as they create
their portion of the executable. Integrating the smaller segments into the
various modules becomes higher in the process as more of the foundation is
built. Eventually the unit-level testing is complete and the module is ready
for the testing phase.
System Testing unit-level, beta, gamma, production
Testing a system is crucial to a successful implementation of an
application. Test plans start with creating good test data. Multiple test
scenarios must be created and run. Network applications must test and solve
resource contentions. The key to any test plan is knowing what data to test and
knowing how to identify when a process is not working correctly. You need a set
of tools to assist in determining when results are not correct or are
unacceptable.
Creating good test data is an art. You cannot simply take a subset of actual
data and use it‑you must ensure that you have anticipated all the
situations the data and user will be facing. Create your test scenarios with
the user. It is not important or necessary to have large volumes of data in
fact, keep the number of records small. Know the expected results of performing
each module in the application, then check and recheck your data after each
phase of your application testing. Large sets of data can be reserved for
performance testing. Testing also verifies your design and determines whether
you have included all the features the user requested.
Including the users in the testing phase is highly recommended. Waiting
until the product is complete before showing the user can be white knuckle
time. You dont want to find out if you did or didn't give your
users/customers what they requested at final delivery. This phase of testing
shakes out any oversights in the initial system testing and prevents unwanted
surprises showing up when the application is put into production. Depending on
the size of the project, include multiple beta test cycles where additional
modules are added then have a final test phase where all completed modules are
tested end-to-end. If replacing an existing automated system, parallel testing
may also be warranted.
Documentation technical, system, user
Documenting an application is often the most overlooked piece of the application
lifecycle‑or at the very least, the component that is put off until the
last moment. Create the appropriate documentation as pieces of the system are
being designed and coded. The major types of documentation are:
7
System documentation
7
Application documentation
7
User documentation
Implementation production release
The final component of the application lifecycle is implementation. Install
the system in the users' actual environment and begin production use of the
application.
Part of implementation is training the users to use all aspects of the
system. This is where your user documentation is put to use. Training is
minimized if your application design includes an interface that is intuitive,
complete with a help system that answers most of the users' most common
questions. Some of the training should occur during the beta testing phase for
testing team members. Full training may also occur before the production
switch is turned on.
Once the user accepts the application and the system is put into production,
the project becomes one of maintenance, performance tuning, and enhancements.
Rules
of engagement setting expectations
Contents
Independent of the number of steps you define for your lifecycle and what
management methodologies you employ, unless you clearly and concisely define
how you interact with the client and ensure both sides understand each other,
expectations will not be met. Defining these rules of engagement upfront in
a manner that is proactive to the project will go a long way in making the
process smother and more successful.
These rules are not hard and fast must-do items, but a well-communicated
approach so the decision-makers and those in the information exchange side of
the project understand how to share knowledge and expectations so progress is
not impeded. Some of the critical items to define are:
7
How to communicate with clients and keep them informed
7
A single point of contact
7
Setting up realistic expectations and how to meet them
7
Define project risks and contingencies
7
Include rework as part of the plan
7
Dealing with scope expansion
How to communicate is critical. The point here is to define the type of
communication, how formal and what frequency. If the team is centrally
located, face-to-face meetings facilitate status and information exchange.
Geographically dispersed team members can use phone, email or video
teleconferencing technology. The type and frequency may be dependent on the
clients comfort zone. Formal reports and email usage should be defined
up-front as potential tools.
A single point-of-contact is critical to ensure the flow of information is
maintained, and nothing is lost. This also reduces the confusion when trying
to determine who is the contact person and the decision maker. Having a focal
point on the user side and the development side allows all communication to
funnel between the two parties to eliminate miscommunication and eliminates
potential confusion on who to contact.
The design/specification document should not be relied upon as the single
communication of what clients should expect from the development team. It is
beneficial to clearly communicate with the client before the project begins how
you manage projects and what you feel are the key elements to a successful
project.
In the book, Software Project Survival Guide by Steve McConnell, there is
a set of questions that he includes to test the potential success of a
project. There are five major areas:
7
Requirements
7
Planning
7
Project Control
7
Risk Management
7
Personnel
In each of these sections the questions provide an excellent set of ideas
that can assist you in defining your own rules of engagement. It is a great
checklist for you to incorporate into your software project management. The following
are samples of the types of questions in the list.
7
Does the project have a clear, unambiguous vision statement or
mission statement?
7
Does the project have a detailed, written specification of
what the software is supposed to do?
7
Did the project team interview people who will actually use
the software (end users) early in the project and continue to involve them
throughout the project?
7
Does the project have a detailed, written Quality Assurance
Plan that requires design and code reviews in addition to system testing?
7
Was the project plan, including the schedule, approved by the
development team, the quality assurance team, and the technical writing teamin
other words, the people responsible for doing the work?
7
Has a single key executive who has decision-making authority
been made responsible for the project, and does the project have that persons
active support?
7
Does the project have well-defined, detailed milestones
("binary milestones") that are considered to be either 100 percent
done or 100 percent not done?
7
Does the project have a written plan for controlling changes
to the softwares specification?
7
Does the project have a Change Control Board that has final
authority to accept or reject proposed changes?
7
Does the project environment include the basic tools needed to
complete the project, including defect tracking software, source code control,
and project management software?
7
Does the project team have all the technical expertise needed
to complete the project?
7
Does the project have a technical leader capable of leading
the project successfully?
7
Does everyone work well together?
7
Is each person committed to the project?
McConnell uses the set of questions as a test on how well a project will
succeed. He titles the questions Software Project Survival Test. For each
question you rate the project from 0 3. The final score is a measurement
baseline on the probability for success.
The list is also a good tool to use at the start of a project with a new
client. In order for them to get an understanding how a software project
should be done successfully, it is critical for them to know about areas such
as risk management and change control. You can use this list or something
similar to review with clients the critical areas of a successful software
project and it communicates how you intend to work and what you feel are the
critical areas that need to be implement be ensure success. Too many times
clients believe software development is creating the requirements and coding to
create the expected results.
The full set of questions and other good software project management
suggestions can be found at www.construx.com/survivalguide.
Contents
This seems like a simple question what should the final delivery look
like? You can start a project by defining all the requirement details which
collectively define the end result, but the granularity of the requirements may
not give an easy, compact, executive summary type statement of what the client
wants.
An alternative approach is to ask the client what done means to them, what
should it look like and contain. This could be considered an interviewing
technique. By asking this question at the start, you will get the picture from
their viewpoint, from which you can start to determine what they believe is
critical and what the high-level expectations they have for the project. The
hot-spots from their perspective are identified and from there you can
drill-down into lower detail. Identifying these items critical to them allows
you to build a better foundation to get the project on the right track from the
beginning.
Contents
In any software project there are changes. Changes can be due to many
factors: varying markets, different technology, shift in budget, government
regulations, new and modified user requirements, plus many more. One of the
keys in this area of the project lifecycle is to manage the requested changes
and dont let scope expansion take over the project. A common approach to
managing this aspect of a project is to define a change control process. This
process consists of a change board and a set of procedures to review requested
modifications and add or reject the proposed change to the project schedule.
A change board consists of a number of people from the management, user and
development groups associated with the project. The number should be limited
to keep the group small enough to get the work done. The mission of a change
board is to be the clearing house for changes to the project. They review
requests made to the application design, determine if the change replaces an
existing design item, adds to the design, the need for additional budget and
what impact does the change have on the schedule.
The actual request for a change should be submitted in some form of a change
request. The content of a change request consists of the following basic
information:
7
Description of the change
7
Name of person or dept making the request
7
Estimate on effort required (time and costs)
7
Impact on schedule
7
Modifications to testing, test procedures and test data
7
Benefit of the change
7
Resource impact
7
Budget impact
7
Risk factors to add the change
Some of the areas need to be written by the requestor and others can only be
done by one or more members of the team. The person or organization making the
request should be able to clearly state the requirements and how they see this
change improving the application and its use. If they cannot clearly state the
expected benefits of the change then the change is not critical. The estimate,
budget and schedule impact, and risks will need to be addressed by the change
board or someone they designate.
Each change request should be estimated as to the effort required to
complete the task. Some items can be estimated without too much effort to get
a ball-park effort assessment. For larger change, you may need to approve some
amount of time to investigate the item and create a more informed estimate. At
a minimum, the change board approves the initial investigation to get an idea
on the time and resource requirements. From these results the schedule, budget
and risks are completed. At any stage during this process the change request
can be rejected, postponed, or put on hold until the next phase of the
project. Once approved, the project manager has to add the change into the
schedule, update the project plan and assign resources.
You also dont want to stifle creativity. You also promote requests which
should be turned into a wish list which will be considered for future
releases. At a minimum, capturing the suggestion will prevent the idea from
being lost.
Like most of the areas in managing the application lifecycle, there are
commercial products available to assist in controlling the record keeping and
status of changes. Borlands StarTeam contains a module for change request
management.
Figure 2: StarTeam change request
form
Figure 2 shows the change request form in StarTeam. The Synopsis tab is
where the Status, Priority, Type, Synopsis (short explanation of the problem)
and other primary fields are located. Figure 3 shows the Description tab where
a more detailed explanation is entered.
Figure 3: StarTeam Description
tab for a change request
StarTeam provides a complete tracking model for change requests. Figure 4 is
a copy of the diagram from the StarTeam documentation showing the change
request process. After a change request is submitted and assigned, it
continues to cycle through the development and testing until the item is
closed.
Figure 4: StarTeam change request
tracking process
Application requirements are not the only portions of a project that
can/should be put under the change control process. The following should be
minimally considered as additional items that the change board or some subset
of the board be responsible for managing changes:
7
The change control process itself
7
All documentation and style guides
7
Test scripts, test data, QA procedures
7
Change request forms, defect forms, signature document forms
To make a change control process successful, you need commitment from the
entire team to change control at the start of the project and a defined,
agreeable process that provides tracking and visibility of requested changes
and their status.
Contents
Testing is done throughout the project. Developers perform their unit-level
testing as coding is worked. Modules are tested as portions are completed then
moved into beta testing. The primary purpose of testing is to ensure the
quality of the deliverable is as high as possible.
It is highly recommended that the testing topic be included at the beginning
of the project. It is important to determine who is responsible for the test
plan and the data to be used during the testing phase. Milestones need to be
added to create the test plans and good test data. The plans and data need to
be updated as change requests are approved and inserted into the project.
The test plans should be a series of tasks that verify the completed module
comply with the specification document. Both manual and automated testing
should be considered. With automated testing, modifications to a module can
quickly be validated with the same suite of test each time they are run. It
also reduces the time required to perform the validation. Manual test suites
increase the testing timeframe while at the same time they allow for testers to
see possible anomalies that automated testing will not find.
In the initial project plan stages, if clients do not want to pay for you to
create test plans and test data, you need to force the issue or require that
all testing has to be their responsibility. Once the client signs the
acceptance document for the module or completed project, they agree that it
works correctly. This may also be a decision point for you to reject working
with a client that does not believe in this portion of a software lifecycle.
If the client is not willing to create or assist in creating test plans/data or
willing to add it as a milestone for the development team to create, you still
need some type of plan and data to test what you build. If data migration is
part of the project, at least there is some live data to use. If the
application is automating an existing manual process, you can take copies of the
paper system to create a minimum set of data for development testing.
Signature
documents are they really necessary?
Contents
As you deliver milestones for the project it is a good idea to use signature
documents. These documents consist of a written acknowledgement of the item or
work package delivered. It provides both a communication tool that the
milestone/delivery is complete and a written record of acceptance by the user
team.
Signature authority needs to be established at start of project. Both sides
need to agree to this process, define who is responsible for signatures and
what requires signature acceptance. A review of the major areas requiring
signatures should be done and insert the signature documents milestones into
the project plan.
Signature documents become part of the project audit trail. It ensures both
sides that the item was completed, delivered, tested and accepted. This
process may add additional tasks and paperwork, but it is a solid part of a
sound, methodical software project.
Contents
Independent of who writes the test plans, the client needs to be responsible
for testing the builds during the beta process. Without the clients
involvement in testing, you dont get the validation you need that the
delivered product meets the users expected solution.
During the testing phase, you will not only get feedback on defects, but the
test users may find ways to improve the product. Even if they were part of the
design team they may see the process differently when they touch the product
and try to perform their daily tasks. Including users during the testing also
gets key employees familiar with the system and trained to assist other
employees when full production is started.
An important part of including users is the acceptance document. The intent
here is to get the user to accept the modules tested and agree they work as
designed. There will be a repetitive process as the defects are corrected but
once fixed to the users satisfaction; the acceptance of the test module should
be complete. During a multi-module test cycle, testing and accepting a module
before including additional modules reduces the final acceptance testing
timeframe.
The goal of users testing is to prevent getting to the production release
and having the client state the product does not work. The major defects that
prevent the product from working should have been found during testing. This
is not to say there wont be any defects, but the users should believe, based
on their testing, the product works as they expect and have minimal fears about
moving into production. The signature document of acceptance is your evidence
of that belief.
Defects tracking, reporting and resolution
Contents
Unless you are writing a simple program such as Hello World, there will be
some level of defects during the life of a project. These defects can be
design errors, program errors, and problems with components, operating system
or some other unexpected problem. Tracking, reporting and resolving the
defects is necessary to improve the quality of the final delivery.
Defects should be recorded throughout the lifecycle. Some of the defects
will be worked as part of the development rework cycle. This includes typical
coding errors that get corrected as unit-level testing is done by the
developer. When design defects are encountered during development, they need
to be documented and added to the defect list. Defects discovered during the
testing phase also need to be recorded and returned to the development team for
correction.
Typical items included in a defect report include:
7
Description of the defect
7
Module/form/report that has the defect
7
How to reproduce the problem what steps can be repeated
7
Build defect found in
7
What is the machine type, OS, memory
7
Who reported defect and on what date
7
Severity of the error (range from crashes machine to spelling
error for a label)
7
Screen shot of the defect if applicable
The defect also needs the following information included to track the item:
7
Defect number
7
Status
7
Who defect assigned to
7
Estimate on time to correct
7
Date corrected
7
Developer notes
7
Link to change request as a result of defect
Not all defects are immediately returned to the development team. Any defect
which is the result of a coding error or incorrect implementation of the design
should go back to the developer for correction. Some defects can be caused by
the OS, DBMS, third-party components, etc. These types of defects may require
design changes or communication with the vendor for a product update. Other
defects may be actual change requests. These items need to be sent to the change
board for evaluation and a determination that the reported item is not a defect
and is placed into the change order process.
Classifying the severity of a defect is something that is also good to
establish upfront with the client. Create a rating system of the severity
level and assign the level appropriate for the defect. Determine which levels
have to be corrected before shipping the product. Here the review process with
the user determines which defects the will live with, if any, before moving to
production.
The change request form shown earlier in StarTeam doubles as a defect
report. The Type field supports both change requests (Suggestion) and defects
(value of Defect). Figure 5 shows the StarTeam Change Request tab where you
can see the mixture of change requests and defects.
Figure 5: StarTeam Change Request
tab
When the project is delivered,
you are done, right?
Contents
Once the team agrees to turn on the production switch and the installation
is up and running, it doesnt mean the work is over. There will always be
additional defects and changes for the product delivered. If you are an
external developer you have to fulfill the warranty and other contractual
arrangement you agreed to with the client. You will hopefully be getting
additional work from the client and you will be able to start another project.
Internal developers get ready for the maintenance release and product
enhancements.
Part of the post-implementation is to review the entire project lifecycle.
This could be called a post-mortem. Here you want to review the different
aspects of the project, learn what worked and what didnt work, what not to do
again, how to fine-tune your project plans, how the tools and products you used
to code the application worked, team-member perspective, and the interchange
with the client. Have a meeting with the development team to share these areas
and allow time for free discussion on the project. The results of this review
will assist you by sharpening your software project skills and improve your
success in managing your next software project lifecycle.
Contents
There are many aspects of ensuring the success of a software project
lifecycle; however you define the major components of the process. You can
glean from each technique described in a multitude of books and classes how to
improve your success. The key points to the technique you employ are:
7
have a clearly defined written plan
7
communicate to the client your methodology for managing software
projects
7
set expectations and risks, get agreement on those expectations
and risk contingencies
7
agree to signature documents and what requires signatures
7
a single point of contact
7
solid test plans and test data where the client is participating
7
a change control process
7
a defect tracking, reporting and resolution process
7
get it in writing definitions, expectations, and acceptance of
completed work
7
learn as the project moves through the lifecycle
