Ada: The cheapest way to build a line of business
James Sutton, Bernard Carre
Lockheed Aeronautical Systems Company, Marietta, GA
Praxis PVL, Bath, England
Software has become the "squeaky wheel" for most commercial product
developments.
Software is involved in most products either as a product component, as a
production
tool, or as an enabling agent (if the product is a service).
Unfortunately,
there is a fundamental incompatibility between the needs of business and
the
paradigm by which software is developed. Business is concerned with
"Lines
of Business"; software is still, despite its advances, rooted in uniqueproduct
development. It is no wonder that the main product-development worry of
many
business managers is "how is the software getting along?"
Changing the paradigm for software development to match the nature of
business
can reduce this problem to manageable proportions. The result can be
called
the Line Of Business (LOB) development paradigm. Other benefits of the
LOB
paradigm are that both development and maintenance costs are reduced,
customer
satisfaction rises, and targeted levels of correctness, assurance and/or
safety
are easier to achieve and verify. The LOB paradigm utilizes existing
tools
and techniques, but places them in a process context that leads to a very
different
software development lifecycle. And Ada is one of the most important
enablers
for the LOB paradigm: no other current language supports all the needed
process
characteristics to handle the general case. "SPARK", a system of
annotations
and restrictions[1] that is applied to Ada to simplify demonstrating
program
correctness, provides an exceptionally strong means of implementing the
LOB
paradigm.
Lockheed Aeronautical Systems Company (LASC) recently initiated
development
of an all-encompassing, internally-funded reinvention of the C-130
Hercules
airlifter and its avionics systems. Tight schedule and cost constraints
made
it unacceptably risky to develop the software using the traditional
paradigm.
This, plus future market opportunities in the same line of business, plus
LASC's
unique perspective and experience as a large-system integrator, led LASC
to
aggressively further the LOB paradigm and process described herein. The
LOB
approach is not totally new, however; it began evolving at LASC ten years
ago.
The LOB paradigm, despite its avionics roots, is domain-independent and
widely
applicable to other businesses and products. The LOB paradigm has proven
highly
successful, and there are many useful lessons at this point in the C-130J
program.
BUSINESS AND SOFTWARE:
OIL AND WATER?
It is fairly simple to describe the demands of business that naturally
apply
to software. Some of the most important of these are that software should
be
easily extensible, portable, virtually error-free (and remain so
throughout
its life), quickly re-verifiable following changes, safe (in the broadest
sense
of the term), precisely and efficiently matched to the business' customer
base,
and less expensive to develop, maintain and modify than traditionallydeveloped
software. Simple!
The definitions of these characteristics provide no relief.
"Extensibility"
means not only that the software must be expandable far beyond its
original
scope, but also that it must be relatively easy to do so for people other
than
the original software developers. "Virtually error-free" must be
thoroughly
quantifiable, to provide the developers with protection in the litigious
environment
of modern business. Quantifiable lack of errors can also be used for
marketing
purposes and to obtain a competitive edge. And the software must remain
virtually
error-free throughout its entire lifecycle: it is, after all, much more
difficult
to build a reputation for quality than to lose one. "Safety" is becoming
a
concern of regulators and consumers in growing numbers of product areas,
many
of which have never before experienced safety-oriented developmental
restrictions
or requirements. More restrictions are being added all the time, in
fields
such as automobiles, electrical power utilities, telecommunications, and
banking.
And losses other than of life or health, such as financial loss or loss
of
customer good will, are increasingly being viewed in ways similarly to
safety.
"Affordability" is in many ways the most important requirement: any new
software
approach that fails to decrease the costs of software development is dead
on
arrival.
All these requirements put stringent and seemingly conflicting demands on
the
software development process. These demands cannot be resolved by simply
reorganizing
typical existing activities. It requires looking at the nature of
extensibility,
at the nature of being "error-free", at the nature of safety, and so
forth.
The results of these examinations leads one to solutions that, in many
cases,
simultaneously achieve what were previously thought of as conflicting
goals.
These solutions have been captured in the "Line of Business" (LOB)
software
development paradigm.
WHY LASC CHOSE AN LOB APPROACH
LASC is reinventing its venerable C-130 airlifter in a project called the
C-130J
program. The C-130J avionics system is a completely new development,
based
on concepts that are at the least at the state of the practise, and in
many
cases are the first of their kind in any aircraft. The most challenging
software
that LASC is developing on the C-130J are the Operational Flight
Programs
(OFPs) for the main and backup Mission Computers (the central integrating
software
and hardware in the aircraft). A number of project considerations led
LASC
to use an LOB process to develop this software.
The first consideration was concurrent engineering. The baseline C-130J
program
is company-financed. Competition and economics are requiring the program
to
meet tight schedules and minimize development cost. Concurrent
engineering
has been adopted by many companies for its development efficiency and for
the
improvements it brings to many product attributes, such as producibility
and
supportability. Therefore, the project decided to base its overall
product
development process on concurrent engineering within Integrated Product
development
Teams (IPTs). LASC has been utilizing IPTs on other aircraft programs,
with
good results. The degree of concurrency on the C-130J, however, exceeds
that
of previous LASC developments.
A challenging effect of concurrent engineering is that it increases the
likelihood
of the software requirements changing or not becoming fully known until
later
in the project (and software) lifecycle. While a Line Of Business
requires
software to be applicable to numbers of possible systems within a product
domain,
the C-130J engineering concurrency in effect has created the same need.
At
project onset, there were numbers of potential final C-130J OFP software
systems,
of which one would actually be implemented by project end (which one not
being
known until quite late in the software development). Choosing an LOBoriented
software approach would make this resolution much simpler and less risky.
Secondly, LASC builds or has built a number of products within the same
general
product domain of "airlifter"; from C-130s (high-wing, four-engined
propeller-based
aircraft), to C-5s (extremely large four-engined jet aircraft), to P-3s
(propeller-based
anti-submarine warfare, electronic warfare, anti-drug, and other
applications
aircraft). Future opportunities within any of these systems in this
domain
are always a possibility: LASC wanted its investment in an extremely
competitive
avionics system concept on the C-130J to be adaptable or tailorable to
allow
similar applications in the other aircraft, at a fraction of the already
aggressive
costs of doing so on the C-130J.
Finally, the C-130 aircraft has, in its many forms, been in continuous
production
for over 40 years. It is a product whose characteristics are well-matched
to
certain basic military and humanitarian activities, such as delivery of
cargo
and search and rescue. LASC expects the C-130J and its descendants to
have
a similarly long life. Over such a long life, significant variations are
certain
to be needed. The C-130J software must support this evolution, which
again,
can be viewed as an LOB situation.
AN LOB SOFTWARE DEVELOPMENT PROCESS
LOB software development at LASC involves several key elements: a
modified
"spiral" lifecycle, a basis in formal (mathematical) methods and
techniques
throughout the lifecycle, domain engineering throughout the lifecycle,
pragmatism
(!), reusability obtained via process rather than via finding and
utilizing
existing artifacts, automation, and the constraint that all process
elements
must "pay as they go"--that is, they must reduce development costs or at
the
worst leave them unchanged. (Note: this constraint concerns development
costs;
it differs from the prevalent rationalization that one should allow
development
costs to increase if they provide decreased lifecycle costs. Of course,
lifecycle
costs were expected to decrease on the C-130J, as this was a major reason
for
undertaking an LOB approach in the first place; however, decreased
lifecycle
costs at the expense of increased development costs is unacceptable to
most
companies from a business perspective.)
These process elements are synergistic: Their net combined effect is to
produce
software that satisfies the LOB software requirements mentioned at the
beginning
of this paper. The means to implement these process elements are varied.
Most
of the means will be discussed herein. In general, each means contributes
to
attaining multiple LOB requirements, either directly or by providing a
basis
on which other means can more effectively support the LOB goals.
The overall process model is called the V Lifecycle, and is based on
experience
as well as aspects of the Software Productivity Consortium's
"Evolutionary
Spiral Process" (ESP)[2]. The V Lifecycle is a practical means of
obtaining
the benefits of a Spiral model within the characteristics and constraints
of
the typical business development project, with additional benefits to
testing
and integration activities.
The V lifecycle has three dimensions. In the first two dimensions, work
in
any given development phase (e.g., requirements, design, coding) is
always
looking towards the needs of the next chronological phase, and also
towards
the needs of the build/verification phase at the corresponding level of
abstraction
(e.g., "software requirements analysis" must consider the needs of both
"software
architectural design" and "software acceptance testing"). These
dimensions
are illustrated in the figure 1. In the third dimension, the tasks
associated
with the following lifecycle phase are executed at a much shallower level
during
the current lifecycle phase. This could be called "phase validation."
A complementary approach called "narrow-slice development" is also being
used.
During each lifecycle phase an example of the products of the next
lifecycle
phase are developed using the primary development process (not via an adhoc
"prototype" approach). The difference between narrow-slice development
and
phase validation is that the narrow-slice development takes a "trial run"
at
the development process, and works out its problems "before the herd
arrives."
Phase validation evaluates the work being done by the primary tasks in
the
current phase by examining its broad implications to the tasks of the
next
phase.
Thus, phase validation is broad and shallow, while the narrow-slice work
is
narrow and deep. Phase validation is primarily "this-phase" product
related
(verification/validation of the current phase direction and results),
while
narrow-slice work is both process and "next-phase" product related
(developmental
emphasis).
The V and the narrow slice, together, provide an optimal balance of
scouting
and adjusting the project's direction of progress (and avoiding costly
missteps),
at the least cost. Indeed, much of the phase validation and narrow-slice
costs
in a given phase are recovered when the phase-validation and narrow-slice
results
become the basis of next-phase development.
The V and narrow-slice approaches also directly decrease development
costs
by reducing rework and helping the system under development to converge
on
a domain-oriented solution earlier in the project.
REQUIREMENTS ENGINEERING
An LOB approach demands that software requirements first be verifiable,
and
secondly be in a form that is useful to other, later-lifecycle methods.
Several
requirements engineering methods are being used on the C-130J to obtain
requirements
with these characteristics.
One method is a domain-analysis approach that identifies, among other
things,
repetitive "structures" or elements in the problem and solution domains,
and
the likelihood of specific requirements or groups of requirements
changing.
The problem domain is analyzed at the beginning of the requirements
analysis
phase (actually, during the system design phase prior to the usual
starting
point for the software requirements phase); the solution domain at the
very
end. The C-130J domain analysis approach incorporates elements of the
SPC's
"Synthesis" approach[3] for defining and producing domain-oriented
systems.
The project is also using a variation on Dr. Paul Ward's Object-Oriented
Analysis
(OOA) methodology. OOA is well-suited for an LOB approach, as it
complements
domain engineering. Domain analysis and OOA contribute to the LOB goals
of
extensibility and portability.
Another requirements method is an expansion on the Software Productivity
Consortium's
(SPC) "CoRE" (Consortium Requirements Engineering)[4,5,6], a formal
requirements
modeling method based on the work of Dr. David Parnas and the experience
on
the Naval Research Laboratory's A-7E Operational Flight Program "Software
Cost
Reduction" (SCR) program[7]. LASC also studied the SCR program
separately,
and utilized certain aspects not currently incorporated in CoRE.
"Extended
CoRE" was automated by mapping its semantics onto the syntax of Yourdon
Data-Flow
Diagramms or "DFDs" (while the result is nothing like a DFD, it is
checkable
according to DFD rules), and using a CASE (Computer-Aided Software
Engineering)
tool to maintain the Data Dictionary and perform the automatic syntax
checking
of the CoRE model.
An example CoRE requirement is shown in figure 2. The table defines an
equation.
The heading of the rightmost column would normally be the name of a
specific
abstracted output (the equation's "dependent variable"); the names of all
other
columns would be the names of specific abstracted inputs (the
"independent
variables"). The cells below the headings in all but the rightmost column
define
subranges of the independent variables. The cells in the rightmost column
define
the function used to derive the output given the combination of subranges
in
the cells to its left in its row. This approach makes it possible to
positively
verify coverage of the entire ranges of the inputs used to derive the
output
(and all the combinations of subranges). This format highlights boundary
values
at the "lines" between the rows.
CoRE and SCR provided a formal basis for requirements, which contributed
to
the goal of error-free software by providing verifiably correct,
consistent,
unambiguous and non-redundant requirements on which to base the system.
The
CoRE requirements also provided the opportunity to generate formal test
cases
and to directly implement requirements in code: CoRE therefore supports
techniques
mentioned under those lifecycle phases below, techniques which directly
contribute
to achieving other LOB software goals.
Yet another requirements method used is Quality Function Deployment
(QFD)[8].
While CoRE provides internally-consistent requirements, it does not
guarantee
that the requirements are what the customer wants. QFD is a mathematical
approach
to directing the development effort based on customer preferences
("market
in"), rather than just on the intuition or experience of the developers
("product
out").
While QFD is in general a lifecycle method, on the C-130J program LASC is
using
a subset of QFD to validate its requirements emphase. QFD has proven
quite
useful for this purpose, and LASC is considering a more comprehensive
role
for QFD in future software programs.
A final method automated requirements engineering through the creation of
an
"interface database." This database has allowed interface correctness and
consistency
to be checked automatically. It also supported automated generation of a
testing
environment used later in the development lifecycle. The interface
database
supports the LOB goals of quick re-verifiability, and reduction of
errors.
DESIGN
For architectural design, an LASC-developed method named "Domain-Specific
Design
Language (DSDL)" development has been used. DSDL development can be
considered
a semi-formal design approach, since the syntax produced is defined,
constrained,
and verifiable in principle by automatic means (though this has not been
implemented
on the C-130J program). Among its direct influences are the Software
Productivity
Consortium's "ADARTS" (Ada-based Design Analysis for Real Time
Systems)[9]
methodology, and a domain-level expansion on the notion of generics.
DSDL development has an object-oriented flavor, but is actually a hybrid
method
that allows functional orientation where it seems advantageous to the
project
(OO is treated as "just another tool in the toolbox"). The DSDL was
developed
based on the repeated structures in the solution domain that were
discovered
by domain analysis earlier in the lifecycle. Indeed, developing a design
syntax
only has value if there are repeated structures in the domain (if there
was
only one sentence in the English language, there would be no value in
defining
what a verb was, what a subject noun was, and so on...you would just
learn
the sentence and use it). However, real-world domains have repeated
structures
that will often justify developing a syntax. The "productivity
multiplication"
of a DSDL is what makes it imperative in an LOB approach to devote enough
effort
to domain analysis to identify the domain's repetitive structures.
Shown in figure 3 is a greatly simplified and abstracted version of the
portion
of the DSDL for the devices that are attached to the data buses on the C130J.
It is recorded in something similar to Buhr notation, as the CASE tool
that
was used implemented a variation of Buhr; however, other notations would
have
been just as suitable. Underlying textual definitions were also developed
for
the classes (outer boxes) and their methods (inner boxes). The dashed
boxes
in the illustration are syntactic elements that must be "instantiated" by
the
detailed designers with the relevant details of each specific device in
the
device category covered by the DSDL. Thus, the detailed design is simply
the
set of instantiations of the DSDL.
A number of process heuristics were applied in developing the DSDL,
including
one that there should be a specific place in the architecture to capture
the
software requirements. These requirements would later be nearly
automatically
inserted into the software at those locations (see figure 4). Obeying the
latter
rule allows for easy traceability from requirements to code, and more
stringent
testing of the code at less cost by isolating semantic testing to limited
portions
of the software system. The DSDL supports the LOB goals of extensibility,
portability
and affordability.
For detailed design, the primary techniques were design in compilable Ada
PDL,
and templates based on the domain structures captured in the DSDL.
Compilable
PDL contributes to the LOB goal of reducing errors. Templates contribute
to
the LOB goals of extensibility, portability, reduction of errors, safety
and
affordability.
CODING
For coding, the main requirement was for a deterministic, statically
analyzable
language. This would permit efficient analysis, testing and regression
testing
of the software. Ada provides the strongest practical basis for
addressing
this requirement, via the "restrictions" mechanism discussed in the Ada
95
Reference Manual (Annex H)[1]. Approaches that leverage Ada in this area
include
"C-SMART" (Thomson software) and "SPARK" (Praxis PVL). C-SMART is a
safety-related
run-time system, and additional automated diagnostics for source code. CSMART
is delivered with certain verification evidences required by the FAA
towards
safety-critical aircraft certification. SPARK is more ambitious and
rigorous,
with more centrality to the LOB process, and is discussed in greater
detail
below.
SPARK[10,11] provides an extremely robust and efficient basis for formal
verification.
SPARK includes a toolset and a method; it is built on a formal
(mathematical)
specification[12] which includes a self-consistent definition of how to
use
Ada to enhance software verifiability. SPARK has support tools for proof
of
correctness and proof of absence of run-time errors. SPARK is being used
on
several European software projects requiring software assurance and/or
safety.
SPARK is a product of Praxis PVL of Bath, England. Praxis PVL is also
participating
in the Independent Verification and Validation (IV&V) of the LASC OFP
software.
When use of SPARK is planned from the project onset, the coding activity
itself
occurs at or near typical Ada rates (especially as experience is gained).
There
are additional benefits in that the coded product allows accelerated (and
automated)
verification, accelerated code correction, and provides provability in
the
end of the complete absence of many important categories of errors,
including
those related to control flow (e.g., multiple loop entries), data flow
(e.g.,
inadvertent use of a random value), information flow (e.g., an output not
derived
from the appropriate inputs), and semantic correctness (e.g., the code
doesn't
do what the requirement says it should).
All portions of the C-130J OFPs where semantics (essentially,
requirements)
reside are implemented using SPARK. This closes the cycle from formal
requirements
to formal programming language, as the requirements are expressed in the
formal
CoRE model. SPARK supports the LOB goals of extensiblity, portability,
error-reduction,
re-verifiability, safety and affordability: in short, almost every LOB
goal
is directly supported by the use of SPARK.
The prevailing coding method was an extension of the template approach.
The
coder of each detailed-design template would add the lowest-level design
(i.e.,
coding) information. Extensive EMACS-editor scripts were also used to
automate
much of the template population. The benefits of using templates during
coding
parallel the benefits of templates during detailed design.
VERIFICATION
For verification, the guiding philosophy is "correctness by
construction,"
i.e., software correctness by preventing the possibility of doing things
incorrectly,
rather than by after-the-fact error detection and correction. This
philosophy
is implemented across the entire development lifecycle. Retrospective
verification
remains in the process, but its main purpose is to provide hard evidence
of
the results produced by the construction techniques. Nevertheless, the
retrospective
verification is extremely rigorous, and if any software errors are found
they
are corrected. In that event, the process is also analyzed to determine
what
allowed the error to occur. If possible, the process is then corrected to
prevent
recurrences of similar errors in the current or future projects.
"Correctness by construction" is "synthetic": it is semi-formal
development
using a combination of formulation rules and constraints whose imposition
ensures
the correctness of the system in the areas of the applicable products and
the
products derived from them.
Retrospective verification leverages the formal requirements throughout
the
lifecycle to verify correctness. This breaks down into two subcategories:
static
and dynamic. Static verification involves placing formal proofs of
correctness
in the code based on verification conditions generated directly from the
formal
requirements. Dynamic verification involves generating execution
"scripts"
directly from the formal requirements, and driving execution of the
system
in the target environment to confirm that the system behaves as expected.
U.K.
and European regulators favor static verification; American regulators
(e.g.,
FAA) favor dynamic verification.
These three elements can be called formal development, formal static
program
analysis, and formal dynamic testing; and interract with the formal
requirements
as shown in figure 5.
In formal development, the rigorously-defined syntax and process of the
DSDL
and templates ensures that the software code is correct by construction
in
both static syntax and static semantics. Confidence in the correctness of
dynamic
syntax and semantics is also high, due largely to the protections
provided
by the restrictions of CoRE and SPARK syntax and semantics. Formal
development
supports the LOB goals of error reduction, re-verifiability, safety, and
affordability.
In formal static program analysis, the SPARK-based Ada implementation and
its
associated formal annotations (proof contexts derived directly from the
original
CoRE specifications) are used to evaluate the internal and formal
correctness
of each unit that contains program semantics. The LOB benefits of static
verification
are largely the same as those for using SPARK during coding.
In formal dynamic testing, a set of formal test cases are developed from
the
formal requirements. These test cases are implemented as "scripts", to be
run
in a tool that simulates the environment surrounding the computer that
executes
the product software. This tool directly utilizes the "interface
database"
created during requirements engineering. These scripts and the
environment
in effect constitute a "product validation suite" analogous to the "Ada
validation
suite": At any point in the product's life, this suite can be easily reexecuted
to confirm that the product requirements are still being correctly
fulfilled
by the implemented product. This suite of techniques and tools supports
the
LOB goals of error reduction, re-verifiability, safety, and
affordability.
A more detailed picture of the interraction of these process elements is
shown
in figure 6.
LESSONS LEARNED
As this paper is being written, the C-130J program is simultaneously in
the
software development, software integration, and systems integration
phases.
Requirements continue to be modified at a high rate as the concurrent
systems
engineering tasks are conducted in an environment of very dynamic ongoing
negotiations with potential customers and with regulators. The LOB
approach
is paying off by facilitating continued rapid modifications and reverification
of the OFP software in its target environment.
Due to the mixed stages of software development, and due to the high
degree
of concurrency of the C-130J program, numeric results metrics are as yet
sparse
and preliminary. However, high-level results concerning measurables such
as
schedule are discussed here. The C-130J program has also provided a
number
of valuable qualitative "lessons learned" about LOB software development.
The first lesson is that the C-130J MC and BIU OFP software development
effort
continues to keep pace with all systems-engineering additions and
modifications,
and with the program schedule. This is in stark contrast to the "software
crisis"
experience of many if not most aerospace projects at this point in their
lifecycles,
where software becomes the "long pole in the tent" that is attributed as
the
cause of overall project delays. Aerospace is not unique in this regard:
Other
categories of software development, for instance MIS (Management
Information
Systems), report similar difficulties.
If software delays are a symptom of a project's (or company's) perpetual
inability
to stabilize system requirements, the business should recognize and
address
its problem with system, as opposed to software, engineering.
Nevertheless,
instability is a way of life in commercial software development. Any
software
development approach that is effective from a business perspective must
handle
this reality within at least reasonable limits if the business is to
succeed
in the long term. We software developers must recognize that the
definition
of "reasonable limits" goes far beyond the coping capacity of the current
software
"state of the practice." The LOB approach performs very well in an
aggressive
change environment. This is perhaps the most important lesson to date
from
the C-130J.
The second lesson is that the LOB approach is practical in a normal
business
environment. This process has proven effective with typical software
developers,
and did not necessitate an inordinate amount of additional training. The
LASC
software staff, while talented and motivated, is representative of
industry.
It is by no means "stacked" with special categories of people such as
Ph.D.'s,
researchers, or mathematicians.
Thirdly, a more leveled staffing curve would be preferable for producing
timely
narrow slices. LASC used a COCOMO-based costing model, which followed a
traditional
staffing curve. Applying traditional staffing curves to LOB development
makes
relatively fewer resources available in the crucial early phases for
domain
engineering, formal requirements definition, "V" validation development,
and
narrow-slice development, the most important elements in LOB development.
Traditional
curves make more resources available in the later phases when the early
efforts
will be yielding higher productivity and lower personnel need. While the
general
desirability of "front-end loading" has been discussed in the software
community
for many years, the LOB model requires such a curve to function at its
full
potential. LASC experienced noticeable bottlenecks (especially in missing
timely
completion of narrow slices) due to the traditional curve, bottlenecks
that
obviously would not have been present with more up-front resource
loading.
The staffing curves didn't eliminate the LOB benefits, but they did, in
the
authors' judgement, hold them below their full potential. The desired
flattened
curve should be somewhat higher on the "forward" or "left" side of the
curve
maximum, as LASC experience has shown that the integration activity
benefits
disproportionately from the LOB approach.
Another lesson is that timely information dissemination is one of the
greatest
needs: In a development that is highly leveraged on efficient domain
engineering
and "domain generics," it is crucial that all developers are provided
with
well-digested (not raw) product and process data as quickly as it becomes
known.
Any delay in dissemination tends to lead to rework of many instances of
parallel
artifacts.
Yet another lesson is that the use of a "template-driven" coding approach
can
inadvertently convey the impression that the coder is being relieved of
all
creative opportunity and responsibility. Not only is such an impression
demoralizing,
LASC experience has shown that creativity and coder initiative are the
key
ingredients to producing working code in this approach! The inherent
limitations
of templates and narrow slices, and the creative aspects of the coding
activity,
must be explicitely communicated to the coders. This message must be
accompanied
by empowerment and process support for the coders to do whatever it
takes,
within the context of the overall architecture, to make their software
work.
This includes the opportunity for direct contact with the systems
engineers
whose requirements generated the need for the coder's software. In this
context,
the templates can fully reach their potential as the facilitators and
productivity
enhancers that they were intended to be. LASC detected this problem
starting
during detailed design, and implemented these adjustments to largely
eliminate
it.
A sixth lesson is that a self-conscious effort should be made to spread
key
technical expertise and design decisions across many program personnel.
This
is especially important from the detailed design phase onward. This
action
will prevent bottlenecks caused by many developers of parallel template
instances,
of each of many different template types, needing access to the same
"guru"
at same time (typically late in the program, just when an important
project
milestone is due!).
A lesson that some people find an irritant, but most agree is a positive
one,
is that the LOB approach involves the entire software development team
more
deeply with systems engineering. For software developers accustomed to
being
handed requirements, "quickly throwing something together", experiencing
some
agony in the integration lab, and then releasing the software to users so
they
can discover the flaws in the system definition, having to resolve system
requirements
and design issues in concert with systems engineers can be infuriating!
Of
course, this is a consequence of the formal methods and the constructive
approach:
they simply won't allow systems-level inadequacies to propagate into the
software
product. While this cost some extra time in the short term, it always
more
than gained it back later.
Another lesson was that, given the nature of Ada, the domainoriented/template-based
design approach, and the narrow-slice development, detailed design should
have
focused more on detailed interface design and deferred most of the body
details
until the coding phase. The DSDL and narrow slices so constrain the roles
of
the Ada packages that this is a relatively low-risk strategy. However,
finalizing
the lowest interface levels at the earliest possible point would have
reduced
work iterations as the bodies were detailed.
The final lesson relates to software changes. When the need for domainlevel
requirements changes is identified, the amount of affected software can
be
large. Yet, because of the domain analysis and DSDL/template-driven
implementation,
C-130J experience has shown that the locations where the changes must go
in
the code is obvious by examining the design template(s) relevant to the
affected
structures in the solution domain. Comprehensive changes can rapidly be
effected
by changing the appropriate section of code in each of the implementation
instances
of the affected template(s). Unlike with non-domain-oriented
architectures,
where functionality is distributed in software in an irregular way, there
is
objective confidence that the software changes will completely implement
the
requirements changes.
CONCLUSION
We began by discussing what "Business" needs from "Software":
extensibility,
freedom for errors, re-verifiability, safety, and inexpensiveness, to
name
just a few. Unfortunately, each of the major current software development
methods
and practices have significant weaknesses in one or more of these areas.
The
recent emphasis on software process has improved the overall efficiency
of
software development somewhat, but has not eliminated or even strongly
mitigated
the deficiencies most relevant to the business community.
While there is no "silver bullet" for putting software out of its misery,
and
never will be, an effective way to address business concerns is to
combine
elements of the best resources now available to software developers--such
as
ways of using Ada that simplify proof of correctness (currently the most
viable
language option), semi-formal processes, domain engineering, practical
formal
methods, progressive management practices, and automation. The goal is to
achieve
a synergy where the business-area strengths of the selected process
elements
at least cover each others' weaknesses, and wherever possible, multiply
their
strengths.
Thus, the key to developing an effective LOB software approach is not in
developing
new and ever more powerful methods, useful as they may be. It is not even
in
improving the consistency of the software development process (e.g., via
climbing
the Carnegie-Mellon Capability Maturity Model), though that too is a
laudable
goal.
The key to developing an effective LOB software approach is to understand
the
needs of business, and the strengths and weaknesses of the softwaredevelopment
resources available, and then create a kind of "chemistry" that will
"react"
the available elements together to produce a "compound" process with the
desired
characteristics. As with chemistry, this is more than simple mixing;
complex
mutation occurs as the elements combine. The properties of the resulting
process
may significantly differ (for better or worse) from what one would expect
by
their simple combination.
However, by discovering which "reactions" are useful to business goals
and
which are not, one can begin converging on a truly "Line Of Business"
(LOB)
software approach. The LASC LOB software approach has spent ten years in
a
crucible simmering over the flames of company and customer demands. It is
presented
here as a model for an effective LOB approach. It is also presented as a
concrete
example of the values and decisions that must be considered in crafting a
truly
business-responsive software development process.
REFERENCES
1.
Ada 95 Reference Manual, ISO/IEC 8652:1995(E)- RM95; version 6.0, 21
December
1994. (See especially Annex H "Safety and Security.")
2.
Process Engineering with the Evolutionary Spiral Process Model, SPC93098-CMC
version 01.00.06; Software Productivity Consortium; Herndon, VA, U.S..
January
1994
3.
Reuse-Driven Software Processes Guidebook, SPC-92019- CMC version
02.00.03;
Software Productivity Consortium; Herndon, VA, U.S. November 1993.
4.
Consortium Requirements Engineering Guidebook, SPC- 92060-CMC version
01.00.09;
Software Productivity Consortium; Herndon, VA, U.S.. December 1993
5.
The CoRE Method for Real-Time Requirements. S. Faulk, J. Brackett, P.
Ward,
and J. Kirby. IEEE Software, 9(5). September 1992.
6.
Experience Applying the CoRE Method to the Lockheed C-130J Software
Requirements.
S. Faulk, L. Finneran, J. Kirby, Jr., S. Shah, J. Sutton. Proceedings of
the
Ninth Annual Conference on Computer Assurance, Gaithersburg, MD, pp. 3-8.
June
1994.
7.
Software Requirements for the A-7E Aircraft, NRL/FR/5530-92-9194. T.
Alspaugh,
S. Faulk, K. Heninger Britton, R. Parker, D. Parnas, J. Shore;
Washington,
D.C.: Naval Research Laboratory. 1992.
8.
Quality Function Deployment (QFD) for Software. R. Zultner (in G.
Schulmeyer,
J. McManusm (ed.s) "Total Quality Management for Software", ISBN 0-44200794-9,
New York: Van Nostrand Reinhold. pp.s 297-319). 1992.
9.
ADARTS Guidebook, SPC-94107-N, version 02.01.00; Software Productivity
Consortium;
Herndon, VA, U.S. September 1991.
10.
SPARK - An Annotated Ada Subset for Safety-Critical Programming, Bernard
Carre,
Jonathan Garnsworthy. Proceedings of Tri-Ada Conference, Baltimore,
December
1990.
11.
Automatic Proof of the Absence of Run-Time Errors. J. Garnsworthy, I.
O'Neill,
B. Carre. Proceedings of the Ada UK Conference, London Docklands. October
1993.
12.
The Formal Semantics of SPARK (Volume 1: Static Semantics; Volume 2:
Dynamic
Semantics). Program Validation Limited; Praxis PVL, 20 Manvers Street,
Bath,
BA1 1PX, UK, (created under contract to DRA Malvern). October 1994.
BIOGRAPHICAL
James Sutton is a long-term devotee of improving software development. He
serves
in several roles on the C-130J program: software process engineer,
software
methodologist, software architect, and interface for software process
issues
with regulatory agencies. Major previous roles have included similar
responsibilities
on the C-5 aircraft ground processing software, being the "reuse lead"
for
the F-22 fighter, being the Principal Investigator of Lockheed's reuse
R&D
program, and being the technical lead of the Trident II missile flight
control
firmware development.
Bernard Carre pursued an academic career for many years (he is still
visiting
professor at the University of Southampton), and then in 1983 created
Program
Validation Limited (PVL), a UK consultancy specializing in languages,
techniques
and tools for high-integrity programming. He and his team at Southampton
pioneered
the industrial use of rigorous static code analysis and formal code
verification,
and he is one of the original authors of SPARK, which is now used
extensively
in safety-critical applications. PVL has recently been incorporated into
Praxis
Critical Systems, Bath, England.