 |
| |
|
|
Delivering Software Solutions On-Time and
On-Budget
According to the Standish Group, only
16% of all software development projects are delivered on-time
and on-budget. A staggering 31% of projects are cancelled
before they ever get completed.
In this last month's
newsletter, we introduced the Iterative Software Lifecycle and
explained how it can help you consistently deliver software
solutions on-time and on-budget. The phases of this
lifecycle are:
- Planning (Analysis)
Phase
- Design
Phase
- Iterative
Code/Test/Release
Phases
- Production
Phase
This month, we will focus on the
Planning (Analysis) Phase, the first phase of the
Iterative Software Lifecycle. In the coming months, we will
explain the other phases of the Iterative Software Lifecycle
and provide you with step-by-step instructions on implementing
it. To see newsletters from prior months, click here.
This newsletter is
sponsored by Software Planner (http://www.SoftwarePlanner.com).
Planning (Analysis)
Phase
The
Planning phase is one of the most important phases of the life
cycle, as it is where the customer and the technical team
agree on a solution designed to meet the goals and objectives
of the project.
The
meetings between the customer and development team is
sometimes called Joint Application-Development (JAD)
sessions. Prior to a JAD session, the customer should
establish a clear goal for the project along with success
criteria for the project.
The
success criteria should be objective and measurable. For
example, "Customers will enter their loan application over the
web and it must be fast." is not a valid success
criteria. A better success criteria might be
"Performance must average 5 seconds or less when a visitor
submits their loan application from the web. Response
times will be recorded upon each application submission and
the average will be reported on a weekly basis."
Functional
Specifications
During the JAD session, the
project manager is responsible for recording the business
objectives and features derived from those objectives.
The features are referred to as "functional
specifications". These specifications must be
specific enough to allow the customer and technical team to
agree on what the feature is, how it will behave and the
business rules associated with the feature. A good
approach is to provide a prototype for each feature as to
ensure that the customer and technical team fully understand
and agree on the specification.
Each project will have a
number of features. These features are called functional
specification items. A small project may have less than
20 functional specification items while a large project may
have hundreds. For each functional specification item,
record these elements (at a minimum):
-
Title - Short
description of the feature.
-
Description -
Detailed description of the feature including feature
behavior.
-
Business Rules -
This specifies constraints and rules for the feature (e.g.
Loan application date must be a valid date and can not
be a future date).
-
Requester - The
person that requested the feature. This can be used
later to get more information from the person, if
needed.
-
Status - This is the
status of the feature. For example, it could start out
in a status of New, move to Awaiting
Approval status, then either moved to
Approved or Rejected status.
-
Priority - This is
how important the feature is to the client (could be high,
medium or low).
Once all the functional
specification items have been defined, it is wise to put them
into a single document called a "functional specifications"
document. This allows the JAD team to review all the
specifications in a central place and can be used later by the
technical team to create detailed designs and estimates.
The functional specifications document should contain the
following sections (you may consider skipping some of these
sections for smaller projects):
-
Summary
- An executive summary describing the project. This
section is designed for new project members to quickly
understand why the project is being
undertaken.
-
Project Goals -
Describes the project goals, justification and success
criteria. This is a very important section of the
document. Once the project is completed, it should be
measured back to the success criteria to evaluate the
success of the project.
-
Features
- A list of functional specification items (numbered
hierarchically). This is best done in "use case"
format, where you describe the feature, list constraints,
actors and security issues.
-
Security Requirements -
Explains the security
requirements of the system. If needed, assign user
groups and define what those groups have access to.
Data
Conversion Requirements -
Explains any requirements in which
your technical team must convert data to import into the
system. This section is not needed if this new system
is not replacing an existing system. If it is
replacing an existing system and the customer would like
data to be migrated from their existing system to this new
system, detail the mapping needed from their old system to
the new system.
Performance and Response
Time Requirements - Explains how many concurrent
users will be using the system and the expected response
time.
Platform
Dependence and Implementation Requirements -
Explains what platforms the
client presentation layer must run on (Windows 95, 98, NT 4,
XP, 2000, Internet Explorer, Netscape, etc.) and describes
the installation process.
Localization
Requirements - Explain any requirements that are
specific to localization (European date and postal code
format, etc.)
Parallel
Testing Requirements - Explains the areas of the system
(if any) that must be run parallel to an existing production
system and compared for consistency.
Cross
System Interface Requirements -
Explains the systems this system
interact with and detail any requirements for testing with
that system to ensure integrity.
Data
Backup, Recovery and Archival Requirements -
Explains the purge, archival,
backup and recovery requirements of the system.
Reporting
Requirements - Describes the reports (if any)
are required for the system. Are they to be online or
run in batch and must they be exportable to other formats
such as MS Word, MS Excel or HTML.
Project Flexibility
Matrix - For a project to be successful, one of these 3
items must be flexible: resources, schedule or
features. This section describes the customer's
choice.
Stack Ranking of
Features - To ensure that items are worked on in order
of importance, features are stack ranked with the lowest
stack rank being most important and the highest stack rank
being least important. This will allow the development
team to focus on the important items and to manage
risk.
Roles and
Responsibilities - Describe the individual(s) that are
responsible for each area of the
project.
Risk Assessment
After the
functional specifications are created, it is time to begin
managing project risk. Risk management simply involves
listing all risks that you know about. For example,
maybe your project will require you to hire additional
people. Your risk may be that you can not hire these
people in time, or that you may hire people without the proper
skill set. It is important to build time into your
project schedule for mitigating your risks. For each
risk, list the following items:
·
Risk – This explains what the risk
is. For example, your risk may be that you will not be
able to hire an engineer by the time they are needed in the
project.
·
Probability of Loss – Estimate the
probability of the risk actually becoming reality. For
example, you estimate that a 50% probability that you will not
be able to hire the engineer by the time he/she is needed in
the project.
·
Size of Loss– If the risk becomes
reality, this is the number of days impact on the project
timeline. For example, you may estimate that you will be
2 weeks late hiring the engineer. The size of loss would
be 2 weeks of work.
·
Risk Exposure – This is the Probability
of Loss * Size of Loss. This gives you an estimated
duration in days that you can build into the project schedule
to hedge your risk. In the example above, you would
build 1 extra week into the project schedule to hedge your
employee hiring risk (50% * 2 weeks = 1 week).
·
Contingency Plan – This is the plan of
handling the circumstances of the risk. In the employee
example, your contingency may be to find more recruiting firms
or to launch an internal campaign to compensate your existing
employees for recommending new talent to your
team.
Summary
The Planning (Analysis) Phase
of the Iterative Software Lifecycle is one of the most important
phases of the life cycle, as it is where the customer and the
technical team agree on a solution designed to meet the goals
and objectives of the
project.
The solution is described in
a "functional specifications" document, allowing the customer
and technical team to agree upon the project scope, goals,
success criteria and features. Once the functional
specifications document is created, it should be signed off by
the customer.
Finally, the Planning phase
is the time to begin project risk assessment. The
project manager should begin listing all risks associated with
the project, complete with contingency plans. As the
project evolves, risks will change and the risk assessment
plan must be updated.
Free
Templates
Click the
link below for some free templates to get you started with the
Iterative Software Lifecycle. These templates cover all areas
of the lifecycle, from the planning to production
phases. You will also find the functional specifications
and risk assessment templates from the location
below.
Templates for the Iterative Software
Lifecycle
Software
Planner
Software
Planner is a web-based software lifecycle management tool that
fully supports the Iterative Software Lifecycle. It
allows you to record functional specification items and store
the functional specification and risk assessment documents in
a central location for your entire team to review. To
learn more about Software Planner, click the link
below.
Software
Planner
| | |