Effective Software Development Process
There is never a guarantee of project success when endeavoring
to build a sophisticated application. However, there are
established steps to follow that will ensure a clear, concise
scope, support for the team involved, and a solid opportunity
for successful deployment. Previous experience has shown many
project and technical teams that the keys to failure can be as
follows: * Lack of senior management support and business
planning. * Lack of clear and detailed design specifications. *
Lack of functional specifications which read as a handbook
reference for the technical team involved to start writing code.
Writing Your Declaration of Dependence A project always starts
as an idea which generally provides a solution. Often these are
drummed up in brainstorming sessions and scratched out onto
legal pads or napkins. It is this step which leads to your
project charter, or your declaration of dependence. The key in
this phase is to include, from the start, all parties involved,
including the most senior managers impacted by this effort. This
means the technical team, development manager, project manager,
business representatives from the impacted departments, and
preferably, the CIO and a non-technical senior management
representative. By utilizing this group in developing the
charter, there is unity in the business plan mission for the
project from the beginning. This is also the opportunity to
better understand the lifecycle on the business side for the
developers and for the developers to articulate the process they
go through to build the solution. This provides a forum for
business users to discuss the processes they use or would use in
this application, giving some insight, perhaps, into interface
design and application flow. Additionally, the technical team
can present the process for moving from design specification to
functional specifications to a test-ready application. A process
should also be agreed upon for ongoing status reporting and
future resources which will be needed, such as quality assurance
staff and alpha/beta testers. Depending upon the timeline, these
resources may need to be identified and notified at this stage
for budgeting and scheduling purposes. This completed document
defines the entire scope of your project, its mission statement,
supporters, reporting processes and the ultimate end result with
broad timelines. It also clearly reflects the interdependencies
required to successfully complete the initiative. Business
Requirements This standard accepted process needs little
explanation. However, it is the step which will enable the
technical team to develop the design and functional
specifications we will discuss later. Most important is to
ensure this document is written in user-friendly language and
format. This is also the document to build your projects
glossary and definitions document. It enables a final review of
the scope by the team that built the Declaration of Dependence
to ensure all aspects are covered before the process moves
forward to design specifications. It is also important to avoid
including design elements in this document. For example, if a
data mart will be built and accessed via this application, it is
important to define the definitions of a record, but not to
define field structures, data types and naming conventions. This
document will produce the necessary definitions of business
processes and needs to identify hardware and software specs, as
well as components and elements needed inside of the design
specification. Design Specifications Design specifications are
the "meat and potatoes" of the project for the technical team.
This is where the major system goals will be established and
will very likely sound similar to the mission statement
implemented in the Declaration of Dependence or the charter.
Several reviews of the charter and business requirements by the
technical team will lead to an introductory high-level technical
document which ties systems, components and modules, and
database needs to business processes and tasks in the proposed
application. Top Level Design This should be capable of
technically describing and defining the application without
necessarily specifying underlying language to be used.
Additionally, this is where all challenges should be identified:
* How is the overall application to be organized? * Are all
systems and sub-systems clearly noted and defined? * Have all
functions been defined for component development? * Have all
data definitions been converted into data structures and types?
* Are there existing systems which can be leveraged for some of
this application, or is it 100 percent original development? *
What will be built and what will be bought? Cost analysis of
components required versus available commercial components. *
Limitations of internal resources. * Interfaces and systems
outside of internal control, which impacts future change
management and application updates. * Does the architecture meet
the standards of the organization and industry standards? *
Scale of the system to handle the level of use and growth of
systems such as data storage, new interfaces, future
improvements and modules. User Interface Design This can be a
web browser based GUI or a software GUI. Either way,
consideration should be given to both design of the interface
and discussion of how to handle changes to the interface so as
not to disrupt underlying application development. Database
Design This is the place to architect the top-level view of the
database for this application. Depending upon the scale, perhaps
some ETL (extraction, transformation and load) tools may be used
for design purposes. This is an area where challenges and risks
can be identified further, as mentioned earlier. This would
include reliance upon data sources or interfaces outside of the
control of the technical team. Roles and Responsibilities A
final step is to assign resources to the varying sections of the
whole application. This is where expertise and experience are
married to the components and systems required to complete the
project. The completed design specifications will naturally lead
to a functional specification. This makes it important to take
an additional step prior to moving forward. This is a good time
to bring the original charter group back together with a
presentation that shows how the design of the system answers the
business requirements and meets the overall scope of the
charter. This discussion will most likely bring about some
changes to the design, and the previously agreed upon change
management process should be used to update the design
specification and move on to the final stage prior to getting
the programming started. Functional Specification The goal of a
functional specification is to achieve a handbook reference for
the technical team to develop, integrate, test and finally
release a completed application. This document is much easier to
complete with the previous road map documents in hand. The
technical team will never lose sight of the business goals
through the charter and requirements, and the design document
has set the parameters through which the project will be
accomplished. Also, the repeated steps of communicating back to
the original group keeps the flow of information on status and
issues between business and technical teams and support does not
waver for the project. Now is the time to address language
specifics and how issues such as hardware and software
dependencies and limitations will be addressed, performance
requirements, security requirements, error handling and overall
logging requirements. The applications varying sections are
addressed with the resource(s) in mind. This will enable a very
clear timeline to be drawn and matched against the original
timeline from the charter and updates may need to be provided to
the original group (keep in mind those QA and testers we
mentioned) for scheduling. Again, be sure to use the change
management process. The completed functional specification will
read like a technical reference guide for the resources to
construct the application. It will provide a timeline to be
followed and reported upon. And ultimately, it should lead to
successful testing and completion of the project. Conclusion
Critical to the success of any endeavor is communicating issues
and solutions, and the steps to achieve results. In application
development, communication is very critical, not just between
technical team members, but also between senior management and
business users involved in the project, as well as your QA and
testers who will sign-off prior to deployment. The steps of any
application project use the business charter, business
requirements, design and functional specification to ensure
scope management and that goals are met with the end result.
However, there can be a disconnect between these parties as the
project is underway and the coding begins. This can lead to loss
of momentum and support from non-technical staff and managers,
scope creep and/or misunderstandings, which may lead to failure.
To avoid this, consider setting broad parameters for reporting
status and general communications when building the charter at
the inception of the project. These can be scheduled meetings,
e-mail updates and even presentations as needed. Also ensure
your change management process is in the charter, and that it
entails communicating change requests to this group with a
clearly defined process for approvals and comments. While some
of the project will seem technical and difficult to follow by
non-technical team members, the group remains informed, can feel
they are invested in the success of the project, and can be your
biggest cheerleaders when obstacles arise.