Chapter 3 Section 5
Software Development Methodologies
Ada 83 has always supported software development using object-oriented
analysis (OOA) and object-oriented design (OOD) methods. In addition, many
projects have used Ada 83 in combination with functional decomposition methods
(e.g., Structured Analysis and Structured Design or Information Engineering).
Ada 95 adds new support for object-oriented programming, further
encouraging the use of object-oriented methods.
As an important early risk assessment step, PEO and PM Offices
should require an assessment of the impact of using various software
development methods in combination with Ada 95 on each project. The
use of object-oriented methods provides technical advantages when used with an
OOPL such as Ada 95. However, if the contractor is not experienced in object-oriented technology, then its use may increase project risk.
When a group is unfamiliar with one or more technologies, such as Ada 95
and OOA, then trying to apply both simultaneously on a project will increase
the level of risk. Therefore, it is very important that the
contractor be fully trained in the selected methodology and have a well-
defined process and tools to support the methodology. With Ada 95, several
options might be considered for a project:
- The Use of Object-Oriented Methods - A very positive selection
for an Ada 95 project. There is a distinct trend toward using object-oriented
technology (OOT), and Ada has had a 10-year history of successful OOT use. Ada
95, with its support for OOP, will make this an even more positive selection.
However, a set of risks accompanies this choice. An informal effort with no
well-defined method is a high-risk solution, even though it is object
oriented. The use of objects simply as an acknowledgment of a
"trend" is not likely to lead to well-engineered software. In
addition, further risk can be experienced if the OO method is not tailored to
Ada, because the details mean different things in different languages although
basic OOP concepts are the same.
- The Use of Functional Decomposition Methods - This can be done in
Ada 95, although it is likely that the full power of the language will
not be exploited. However, many projects have used methods such as
Structured Analysis and Structured Design or Information Engineering with Ada
83, and projects may continue to use these methods equally well with Ada
95.
- The Use of Mixed Methods - Almost always a high-risk approach.
Historically, attempting to use two diverse approaches has proved difficult
for projects. The PEO and PM must look very carefully at any project that
suggests such technology for Ada 95 use.
Simultaneously changing two technologies on a project is not only a
common event, but is often necessary for the new language's benefits to
emerge. However, this will increase the risks associated with the development
effort. Therefore, management must take active steps to mitigate the increased
risk. These steps fall into four categories:
- Information Buying Action:PEO and PM staff and the
contractor/developer should procure training that emphasizes not only the
methodology and language, but also the interactions between them. PEOs and PMs
should then hire an experienced consultant to help mentor the development team
and lower the risk. The consultant should focus on the effect that the changes
will have on other software development processes and products such as
documentation or testing. It is especially important that the consultant focus
on those areas where the language and the methodology suggest conflicting
changes. The PM staff should make use of the Internet, which provides
mechanisms such as electronic mailing lists, retrieval of files via ftp and
gopher, newsgroups and discussion forums such as comp.lang.ada, and
information browsers such as World Wide Web (WWW) and Mosaic. The Program
Office and contractor/developer will find Internet a cost-effective source of
information.
- Risk Avoidance Actions: To avoid risk, change only a single variable
(either method or language) and keep the other constant. Since this may not be
practical and may, in fact, eliminate other benefits of Ada 95 adoption, a
good alternative is to initiate pilot projects that explore the impact of one
of the two changes. These pilot projects will provide information about the
adoption of each new technology in "relative" isolation. Then, the
technologies may be combined for the development effort. This will minimize
the risk, even if it does not entirely avoid it.
- Risk Transfer Actions: Program Managers may transfer the transition
risk to the contractor by offering certain incentives in compensation or
training for the increased risk.
- Risk Reduction Actions: PEOs and PMs may reduce the risk of
unmanageable technical complexity (from changing both method and language)
through the use of additional experts. An Independent Verification and
Validation (IV& V) organization may be used to evaluate the project's
progress during development.
In the 1990s, the use of Computer Aided Software Engineering
(CASE) tools on projects has become more common. Recently the DOD has
sponsored a CASE technology adoption project called I-CASE. However,
CASE has been recognized as a supporting technology and not as a silver
bullet.
PEOs and PMs should ensure that the tools contractors use on the
project support the software engineering methods and training that the project
has received. To avoid schedule risk, PM Offices and contractors/developers
must work with CASE vendors to ensure that Ada 95-support versions of their
tool will be available in concert with project schedules.
As of this writing [Spring 1995] CASE tool support for Ada 95 has been
announced. Upper CASE tools (which cover the early phases of the software
life-cycle) are typically not language-dependent. Lower CASE tools (which
cover the later phases of the software life-cycle) are language-dependent and
need to be upgraded to support Ada 95 effectively. Many of these kinds of CASE
tools will either be bundled with the compilers or sold as a part of vendor-sponsored Software Engineering Environments (SEEs). Of these vendor-supplied
tools, some (e.g., class browsers) are already available for Ada 95. Third-
party tools are also becoming available. Table 5
(in the Tools and Environments subsection) shows the projected
availability for some kinds of tools. There are many CASE tools that work with
Ada 83. These tools can continue to be used with Ada 95; they simply won't
take advantage of the new features of the language. Several Lower CASE tool
vendors have announced plans to have their tools generate Ada 95 code from
diagrams.
To assess the risk to a project, PEOs and PMs should talk to the vendors
of CASE tools - to tell the vendors the kinds of applications and platforms
that they are using and provide a schedule indicating when they will be
needing these tools to support Ada 95. The sooner the vendors hear
from their customers, the sooner they will be able to determine which
platforms and tools should be upgraded first. By taking a proactive approach,
PEOs and PMs help to lower the risk that a tool will not be in place when
needed.
Previous Section - Technology Transfer Related Risks
Next Section - COTS, Legacy Software, and Multi-Language Software Development
Table of Contents