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 recent newsletters,
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
Last month, we focused on the Planning
(Analysis) Phase. This month, we will focus on the
Design
Phase,
the second phase of the Iterative Software Lifecycle.
Since the design phase has many deliverables, we will focus
this month on the detailed design deliverables. In the
coming months, we will explain the other deliverables of the
Design Phase as well as the remaining 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).
Design
Phase
The Design Phase is used to determine the
technical solution and to provide preliminary estimates for
delivering the solution. For the project manager to
provide correct estimates, the development team must spend
time architecting a technical solution that meet the demands
of the functional specification. Additionally, the
testing team must develop a Master Test Plan as to allow them
to estimate their effort.
Upon completion of this
phase, a project plan may be developed which details the
costs, effort and timeframes in which the solution may be
delivered. As a final step, the client may decide to
add, omit or delay functionality to fit within their timeframe
and budget.
Deliverables
Below
are the deliverables for the Planning Phase:
This month, we will discuss the Detailed
Design. In coming months, we will explain the other
deliverables in detail.
Detailed Design
Document
Once all the functional specification items
have been defined, it is imperative to understand the effort
needed to deliver each functional specification item.
The most reliable way to do this is to create a "Detailed
Design".
The detailed design document allows your
development team to thoroughly think through the development
approach, and to determine the effort involved in delivering
each functional specification item. The detailed design
document should contain the following sections (you may
consider skipping some of these sections for smaller
projects):
-
Architectural Design
- In our experience, the most re-usable design is a 3
tier solution:
1. Presentation Layer – User
interface, such as a Windows User interface or Web Browser
interface. No business rules appear in this
layer.
2. Business Layer – Business rules that
are called from the presentation layer. These are normally
compiled into DLL(s) that encapsulate all the business
rules.
3. Database Layer – Layer to talk to
the database. Putting this in it's own DLL allows you to
easily change it later if you need to support different
database
formats.
Hardware
Requirements - It should list the hardware requirements,
both for client machines as well as servers. This will
allow the project manager to budget the purchase of
hardware.
Software
Requirements - List all software used to develop the
system (Visual Basic, C++, Java, Visual Interdev, SQL
Server, Oracle, etc) along with any software necessary for
the system to function (MS Excel, Third Party Controls and
Java Applets, Internet Explorer, etc).
Presentation Layer -
This section describes all the screens and reports needed to
deliver all the functional requirements. Include screen
descriptions, screen shots, report descriptions and report
shots. The client should understand that the final product
may not be exactly as listed here but the functionality will
stay the same. During coding, you may merge or separate
screens to achieve a nicer user interface and to promote
reusability of components.
Business Layer -
Define all of the objects necessary to support the
presentation layer. You may consider displaying the objects
in a hierarchy, showing state diagrams, and/or other object
related information.
Database Layer -
Define all of the tables/columns/views/stored procedures
necessary to support the business layer along with an
Entity-To-Relationship diagram.
Other Design
Considerations - Each project may have one or more of
these special design considerations that must be
described:
1. Conversion Modules -
Describe any programs that are used to import, convert or
munge data.
2. Archive and Purge
Modules - Describe any programs that are used to
perform special functions like purging and
archiving.
3. Backup and Recovery
Design - Describe the process for backing up and
recovering lost data.
4. Security
Architecture - Describe how security will be
enforced and at what level (or groups). If using NT, address
the NT security model, IIS security, Secure Socket Layers,
etc. if applicable.
5. System
Interfaces - Describe how you will feed or receive
feeds from other systems. This may be via replication, XML,
EDI, BCP, SQL Loader, etc. Describe the data that will flow
between the systems, how often it will be updated, and who
the system owners for each system are.
6. Batch
Jobs - Describe any jobs that will run regularly to
perform batch based commands.
7. Performance
and Response Time Considerations - Explain how you
will design for quickest response time. This includes the
use of Stored Procedures, de-normalized data (if
applicable), server configuration (size, memory, etc),
programming techniques, and the use of database tools such
as Oracle’s Explain Plan or SQL Server’s Show
Plan.
8. Platform Dependence and
Installation - Explain the installation (or setup)
process in which the client must use to get the system up
and running along with our plan for ensuring it will run on
all the platforms requested by the client (Windows 95, 98,
NT 4, 2000, XP, etc).
9. Localization
Considerations - Explain your design for handling
issues specific to localization (European date and postal
code format, language, etc.), if any.
Detailed Design to
Functional Specifications Cross Reference Matrix - You
will show how each detailed design item ties back to a
functional specification item. That way you can ensure
that you are getting great design coverage for your
functional specifications.
Once you have defined the
items above, the development team must estimate each item so
that you can get an idea of the cost of development.
Next month, we will discuss the formulation of the test
plan. Once that is done, you can estimate the testing
effort. Upon completion of the detailed design and test
plan, your project manager can estimate the other project
related activities so that you have a fully estimated
project.
Summary
During the Design Phase, the project manager
works with the development team to create detailed
designs. Detailed Designs explain the technical approach
and estimated effort for delivering each functional
specification item. Once this is done, the project manager
works with the testing team to create the Test Plan. The
Test Plan details the testing approach and estimated
effort. Once this is done, the project manager can fully
estimate the entire project.
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
detailed design template at that site.
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 store detailed design documents in a central
location for your entire team to review. To learn more
about Software Planner, click the link
below.
Software
Planner