Table Of ContentNASA/TM-l999-208898 AIAA-99-0248
Software Development Processes Applied to
Computational Icing Simulation
Laurie H. Levinson, Mark G. Potapczuk, and Pamela A. Mellor
Lewis Research Center, Cleveland, Ohio
Prepared for the
37th Aerospace Sciences Meeting & Exhibit
sponsored by the American Institute of Aeronautics and Astronautics
Reno, Nevada, January 11-14,1999
National Aeronautics and
Space Administration
Lewis Research Center
January 1999
Trade names or manufacturers’ names are used in this report for
identification only. This usage does not constitute an official
endorsement, either expressed or implied, by the National
Aeronautics and Space Administration.
Available from
NASA Center for Aerospace Information National Technical Information Service
7121 Standard Drive 5285 Port Royal Road
Hanover, MD 21076 Springfield, VA 22100
Price Code: A03 Price Code: A03
AIAA-99-0248
SOFTWARE DEVELOPMENT PROCESSES APPLIED To
COMPUTATIONAL ICING SIMULATION
Lcrirrie H. Levinsoti
Mii rk G. Potapcziik
Pcmretrt A. Mellor
NASA Lewis Resectrch Center
Clet&rid, Ohio
The development of computatioiral icing simulation methods is making the transition from the research realm to
commonplace use in design and certification efforts. As such, standards of code management, design, validation,
and documentation must be adjusted to accommodate the increased expectations of the user community wich
respect to accuracy, reliability, capability, and usability. This paper discusses these concepts with regard to
current and future icing simuiaiiorr code development efsorts as implemented by the Icing Branch of the NASA
Lewis Research Center iir collaboraiiori with the NASA Lewis Engineering Design and Analysis Division. With
the applkation of the techrriqircs oirtiirted in this paper, the LE WICE ice accretion code has become a more
stable and reliable software product.
Introduction In order to advance the code along the path toward
acceptance, the Icing Branch of the NASA Lewis
The LEWICE ice accretion c.idc ha\ hecn supported Research Center has emharked upon a rigorous
and maintained hy thc lc.ing I3r;incti of the NASA program of software re-engineering. This effort is
Lewis Research Center sincc ilic 1980's. The original designed to make the code more .robust and more easily
code comhined already cxkting clcnicnts. such as flow managed. and to more quantitatively identify its
field and trajectory calcul;ition\. H ith new elements capahilities over the range of operating conditions it is
modeling the physics 01' ICC growth to create an designed to simulate. In order to accomplish this task.
updated system capahlc 01. prcxlic.ting the evolution of however, it has been necessary to move beyond the
ice shapes on surfaces cxpo\ed 11) icing conditions. icing research domain itself and to incorporate. in
addition, software engineering knowledge and
Since this original icing 4iiiiulaliiiri code was created
expertise, as provided by the NASA Lewis Engineering
almost twenty years ago. ttrc \! \~eiiih as undergone
Design and Analysis Division.
many changes.'.'.' Feature4 tiat c hcen added, "bugs"
have been fixed. and aii;ipt;ition\ to various hardware The first step in this collahorative effort has heen to
platforms have been incluclcd. hluch ol' this evolution gain an understanding of standard software
has been in response to rcquc4ls from the user development processes and techniques, and to,carefully
community for enhanced t'c;Iiure\. greater reliability. consider the implications of these processes and
increased accuracy, and impro\ CLIu 4ahiliry. techniques relative to the icing research development
environment.
As the development of this code has become more
user-oriented, however. the use 01' the code hy the icing A standard software development process. as used
community has increased. and demands for even higher within many software-intensive disciplines. provides a
levels of reliability and accuracy have also increased. structured approach to the creation of computer codes.
Most notahly. the use of LEWICE as a substitute for or This typically begins with the specification of the
augmentation to experimental testing continues to he a planned system capabilities - or "requirements" - and
desired goal of both the user community and the leads all the way through distribution and support of
regulatory authorities. the final software product. This type of approach is
generally more traceable than that used in a research
environment, and leads to better documented code.
Copyright 0 1998 by the American Institute of
However. it also requires a greater degree of oversight
Aeronautics and Astronautics. Inc. No copyright is
and record keeping during the development effort.
asserted in the United States under Title 17, US. Code.
Traditional methods for the development of research
The U.S. Government has a royalty-free license to
codes have generally followed a more unstructured.
exercise all rights under the copyright claimed herein
for Governmental Purposes. All other rights are less formal process in order to allow maximum
llexihility to the developer. In this more informal
reserved by the copyright owner.
1
American Institute of Aeronautics and Astronautics
AIAA-99-0248
environment, frequently recommended software
development strategies for planning, documentation,
version control, and distribution of the final product
have not commonly been put into practice.
In the more formal environments established outside
the research realm. the development process, although
normally tailored to the specific needs of an individual
prqject, generally takes the form illustrated in Figure
I.' The process begins with a basic description and MPlEMENTAWN
evaluation of user needs, then moves to a definition of
the planned system capabilities, specification of the
system structure, implementation into code, testing of
the code on several levels and, finally, distribution of
the final product and associated documentation.
Throughout the process, configuration management
techniques are applied to ensure traceability of all
changes that may be made over the course of the
development effort.
When considering the implications of this more
Figure 1. Typical Software Development Life Cycle
rigorous approach relative to the development of icing
simulation software, one of the outcomes is to highlight
the need for the specification of requirements. This is
The Software DeveloDment Process
especially true with respect to the ability of the code to
accurately predict the ice shape geometry being
In order to better understand the issues involved in this
simulated. The ability to define requirements such as
type of software process improvement initiative, it is
this clearly relies upon the existence of some
first necessary to understand the elements of a typical
measurable standard relative to which the requirements
software development process. In general, when
can be specified. At the present time, however, there
production software is created - where production
are no well-established acceptance criteria for ice shape
software is software one might purchase and assume to
modeling. While several researchers have suggested
be of high quality - the development process is
methods of comparing computed ice shapes to
commonly broken down into a sequence of stages
measured ice there is as yet no agreement on
through which the software progresses. Because these
the best approach to use in order to perform this
stages cover the entire range of activities that are to
comparison. Additionally, in none of these cases has
take place over the lifetime of the software system,
there been a determination of how these comparisons
they are, together, referred to as the software
should be assessed.
development life cycle. Within the software
Furthermore, ice shape is just one characteristic that community, there are a variety of accepted ways to
could be evaluated with respect to an ice accretion specify this life cycle. One typical formulation, the
code. Other outputs that could be evaluated include waterfall life cycle as defined by the Institute of
droplet impingement limits, collection efficiencies, and Electrical and Electronics Engineers (IEEE), is shown
heat transfer distributions. Acceptance of the software in Figure 1. This basic life cycle serves to illustrate the
is based, in part, upon satisfaction of requirements for process of creating a software system from its initial
parameters such as these, and it is not entirely clear, at conception on. It is often referred to as an ideal life
this time, precisely how to define such requirements. cycle since, in reality, there is rarely a clean
Similarly, it is not clear what additional requirements demarcation between the various stages, or a purely
are necessary in order to adequately specify the sequential process, as is implied by the waterfall chart.
essential characteristics of the system. Instead, the software system is frequently built in
pieces, each of which follows the sequence of steps
This paper will outline some suggestions for addressing
defined, although not all at the same time. Some
these and other issues through the use of standard
portions may be better understood or may be
software engineering principles as applied to the
considered more critical than others. and so may be
development and maintenance of the LEWICE
built sooner. This incremental approach does not
software system.
invalidate the waterfall model, but rather implies that
there are many little waterfalls used instead.
2
American Institute of Aeronautics and Astronautics
AIAA-99-0248
To explain the various phases of the waterfall, the important step in the engineering of reliable, high
process begins with an examination and determination quality software systems.
of what to do (concept exploration), followed by a
In the next phase of the waterfall model. the design
further refining of those ideas into specific capabilities
phase, the primary output is a Design Document. The
that are to be implemented (requirements). After these
purpose of this document is to specify the intended
capabilities have been identified. the next step involves
software system structure and the associated relevant
defining exactly how the required capabilities should
design information. The information provided can take
be implemented (design). This design is then used to
the form of flowcharts or other pictorial representations
create the actual code for the system (implementation),
of the system structure. and may also include items
which is suhscquently checked for proper operation
such as Program Design Language (PDL)
and corrected if and when errors are found (test). Once
specifications, which provide an English language
this activity has been successfully completed, the
description of an individual software module's logic.
software is then placed in its normal operating
Whatever the form of the documentation. the activities
environment and checked again for proper execution
performed and decisions made during this phase
(installation and checkout). After this, the software is
provide the foundation for the coding effort that is to
considered to he an operational system which may.
take place during thc implementation phase.
over timc, have a need for additional or revised
Neglecting to perform the necessary activities and to
capabilities, resulting in changes to the existing system
properly address design issues generally results in code
(operation and maintenance). This operation and
which is put together in an ad hoc fashion. and a
maintenance phase continues for the remaining time
system which is difficult to understand. test, and
that the system is in use until, at the point where the
maintain.
softwarc is deemed to be outdated or its function no
longer needed. it is finally retired (retirement). As a consequence. any attempt to bypass this part of
the development process will ultimately prove
A more detailed view of this waterfall model is
detrimental to both project schedule and product
provided in Figure 2, below. As indicated in the figure.
quality, although this fact may not be fully appreciated
one of the artifacts produced during the requirements
by those without the requisite software systems
phase is referred to as a Requirements Specification.
experience. The additional time required to code and
The purpose of this Specification is to document
test a poorly designed system. however. will quickly
detailed information about all required sofiware system
cancel out any short-term gains that may have been
capabilities. As such. it may well be the single most
achieved by minimizing or eliminating the design
critical document produced over the entire course of a
phase. In addition, the generally lower quality of such
software project. as all downstream activities and
a system will also have a significant impact during the
decisions ultimately flow out of the information
operation and maintenance phase, which past
contained in this document. Among other things. the
experience indicates is where the majority of project
determination that must be made at the end of a project
time and money is typically spent. During that phase.
as to whether the completed system performs its
the added cost incurred when required to implement
intended function can only be made in reference to the
changes to a poorly designed system will further
system's specified requirements. Whilc this may seem
diminish any temporary gains that may have heen
self-evident. it is nevertheless a ma.ior weakness of
achieved by overlooking design in the early stages of
many software development projects.
the project.
Defining good requirements is actually quite difficult
Once the design phase has been completed, the code is
and time-consuming. According to the IEEE.
then generated during the implementation phase. and
requirements should be correct. unambiguous,
subsequently checked for correctness during the test
complete, consistent, verifiable, modifiable. traceable,
phase. At this point in the process. a common
and ranked for importance and/or stability. They must
approach is to build small pieces of code. test these
address functionality. external interfaces. performance.
pieces individually, then gradually aggregate them into
desired quality attributes, and any mandated design
larger and larger pieces. which are each tested
constraints.' More often than not. however. vague
individually before being combined with other pieces
desires of what the software might do are all that a
and tested. Throughout the enfirc process. test plans.
programmer actually has to depend upon. and these
procedures, and results are documented and controlled.
may not even he documented. Frequently. the
thereby providing not only a record of the verification
developer must make many design decisions based
process itself. hut also providing the requisite
upon faulty information and assumptions and, as a
traceability and repeatability in the event that errors arc
result. may end up developing software that doesn't do
found and modifications to the modules become
what its users want at all. For these reasons. properly
necessary.
addressing the specification of requirements is an
3
American Institute of Aeronautics and Astronautics
.
AIAA-99-0248
Project Phase Artifacts/Outputs Purpose
CONCEPT User needs described and evaluated
*
EXPLORATION ,
j Statement of Needs, ,
Feasibility Studies,
System Delintion,
Procedure and Policies
.
Required system capabilities defined
and documented
Designs for architecture (structure),
software components, interfaces, and
DESIGN 1 data are created, documented, and
Design Document, verified
I l Component and Integration I
- Test Plans
7-- -
... . -_ ~
* Using design documentation,
IMPLEMENTATION software system created and
1
Source Code and Doc,
dew9d
Cwnponent. lntegrahon and
System Test Procedures,
Cwnponent Test Reports.
User Documents, Test C-a s_es -
--
Software product integrated and
TEST evaluated to determine whether or
Acceptance Test Procedure, not requirements have been satisfied
Verslon Descnptm Document,
Integrahm. System. and
Acceptance Test Reports,
Release Swrce Code and Doc
r
,
-
Software product integrated into
its operational environment and
tested in this environment to
CHECKOUT Audit, Verdication and ensure it pertons as required
Validation Final Repoll,
Anomaly Reports
1
t Software product employed in its
+
L - - - operational environment, monitored
OPERATION
for satisfactory performance, and
- AND modified as necessary to correct
MAINTENANCE Anomaly Reports, problems or respond to changing
Change Requests requirements
.
Support for software product
RETIREMENT
terminated
Figure 2. An "Ideal"S oftware Development Process
4
American Institute of Aeronautics and Astronautics
AIAA-99-0248
The need for such a high degree of rigor at this stage formalized procedures. As with any improvement
of the process can best be understood by activity, therefore, when attempting to apply standard
consideration of the concept of repression testing. techniques to a specific environment in an effort to
The IEEE defines regression testing as "selective re- evolve toward a more disciplined approach. it is
testing of a system or component to verify that important to factor in both the distinguishing
modifications have not caused unintended effects and characteristics of the environment and their
that the system or component still complies with its consequences for software development. If careful
specified requirements."' This definition helps to consideration is not given to the unique qualities and
point out an unfortunate, and often overlooked, standard operating procedures of the organization. it
characteristic of software development: it is quite is likely that the changes made either will not address
easy and, in fact. quite common to make an the most critical concerns or will not prove to be a
ostensibly simple change to a software module, and good fit for the organization. If this occurs, new
have that change cause unintended side effects approaches implemented will be unlikely lo produce
(a.k.a., bugs) - sometimes in parts of the system far the desired results. as they will most likely either be
removed from the original location of the change. unrelated to the main issues of the organization or so
Therefore, in order to ensure that tale changes do not foreign as to eventually be discarded in favor of the
adversely impact either the modified or the original. more familiar. practices. In either case. the
urinzodifed portions 01' a system. it is essential to improvement initiative will have failed.
have both a well thought-out approach to regression
The Research DeveloDment Environment
testing and the ability repcat prior tests and
10
reproduce prior results. The rcgrcxsion testing In many research-oriented organizations, an emphasis
philosophy on a projccl. and the process established is placed on individuality, creativity, and flexibility in
to implement this philosopti!. arc thus important order to provide an environment where new ideas
elements of the software de\ clopiiicnt process, and will flourish and unique approaches can easily be
necessitate a certain Ie\cl 01' planning and pursued. In this type of environment. an individual
documentation for proper iiiiplcnicnliil ion. researcher often works independently, pursuing a
particular area of interest at the exclusion of other
With the testing phase coiiiplcic. and the software
areas. Frequently. the researcher's reputation and
successfully delivered and iii~1;iIlcd. the system is
perceived value to the organization are based
then considered to be in 11ic operalion and
exclusively on the unique knowledge and expertise
maintenance phase. During 11ii\ phase. an existing that he possesses.
system is modified either corrccl prohlems that
IO
have been uncovered a1.w tlcli\c.r\ 01. the software or When the work performed in an environment such as
to make changes in rcspoiw to ncu requirements. this includes the development of analytical software
The desired changes arc t! pic;iIl! docuiiicnbxl using for an external user community, however. the
anomaly reports and/or c.h:ingc rc'iluesl~.a nd these emphasis on individuality. creativity. and flexibility,
are then carefully rcvicwctl prior to making any which is so beneficial from a purely scientific stand-
actual changes to thc s! 4tcii1'4 tlocumcnlation or point, has some distinct drawbacks. The reasons have
code. Although all chanFc4 iiiadc a1 this point are to do. in large part, with the basic nature of software.
considered to be part 01 [tic operation and
Software systems are among the most complex
maintenance phase. the proc.c\\ uxxl to implement
systems ever conceived, based upon principles of
these changes consists 01' cs\cn~idlyt hc same set of
human logic rather than on the natural sciences.
steps described above and u\cd Juring the original
Because of this. the results obtained when building a
development effort. Thcrcl'orc. the operation and
software system are especially dependent upon the
maintenance phase can actually be viewed as
skills of those doing the development. If, as is often
consisting of repeated implciiicn~alionso f the various
the case in a research environment. only one
stages of the waterfall model.
individual is responsible for and knowledgeable
about this development, then the quality and
Software Process as Applied to Icing
functionality of the system will be based entirely
Simulation Development upon the capabilities and knowledge of that
individual. This would represent a significant risk
Although the standard development process
even in the best of circumstances; however. in the
described above can be adapted for use in a variety of
research development environment. where "research"
situations, there are certain characteristics of the
is generally the first concern, and "development" a
general research environment that are not entirely
distant second. software systems are likely to be
consistent with this more rigorous approach.
regarded as simply a tool of the researcher. and the
Likewise, there are also aspects of the icing
methods used to develop them given little
simulation development domain that are not
consideration. Non-software products (consider. for
altogether compatible with the use of more
5
American Institute of Aeronautics and Astronautics
AIAA-99-0248
example, a bridge or a car) developed without system are necessarily tied to that individual's
concern for the process used would commonly be schedule. Therefore, in contrast to a well-managed
expected to be of poor quality, and a similar production software project, which has pre-
expectation in the case of software is certainly not established deliverables and milestones and uses an
without justification. In fact, on the contrary, the appropriately-sized team to meet those objectives. the
inherent complexity and logic-based nature of typical analytical software system produced in a
software suggest the likelihood of even more serious research environment has deliverables and milestones
consequences in that event. that are based on the individual developer's schedule.
In this situation, common practice is to simply release
The potential risk relative to both software system
system updates as they are completed - although
content and quality, however, is further exacerbated
without associated documentation or controls in place
by the fact that, in this environment, very little about
to clearly distinguish between different versions, it is
the software tends to be documented. This is most
not possible to know with absolute certainty which
likely a consequence of both the lack of emphasis
updates are contained in which version. This can
placed on standard software development methods, as
quickly lead to confusion within the user community,
described above, and the generally individualistic
and potentially even for the researcher himself.
nature of the research environment. In this type of
resulting in the classic "quality control problem."
environment, where one individual is solely
responsible for a system and has the freedom to make The Icing Simulation Development Environment
all decisions unilaterally, the need to document
Although the issues associated with the general
information in order to communicate it to others is
research environment described above apply to the
minimized. With this being the case, critical
icing simulation environment as well, there are
information about the system is often contained only
additional issues specific to the icing domain that
in the mind of the developer. This not only puts the
must also be considered. These issues essentially
organization at risk in the event that this uniquely
reflect the state-of-the-art of icing simulation code
informed individual should happen to leave the
development which, at the present time. is
organization - taking all of his knowledge and
particularly lacking in two fundamental,
expertise with him - but it also has other less drastic,
interconnected areas - determination of system
although nevertheless significant, implications.
requirements and specification of system acceptance
One such implication is that, when basic information criteria. The deficiencies in these areas of the icing
about the system is not documented - e.g.. system simulation development process are, at least in part,
capabilities, specific approaches selected or rejected, due to three basic difficulties associated with the
the rationale for various decisions, etc. - it becomes modeling process for icing phenomena:
very difficult, if not impossible, for other members of
(I) Uncertainty in understanding of the physical
the staff or the general user community to review this
processes
information. Furthermore, without a structured
process for critically reviewing implementation Although this is not an area of difficulty that is
decisions and providing feedback to the developer, unique to the modeling of icing phenomena, it
any external input that is provided will necessarily be nevertheless has significant consequences with
provided in an informal, after-the-fact fashion. respect to both determining system requirements
Often, this will be after the completed system has and establishing system acceptance criteria. The
already been delivered to the users. Any changes reason for this is straightforward. Logically, if
made at that point will then most likely be one does not understand the basic phenomena
incorporated into the system using the same being modeled, it will be difficult to develop an
unstructured process. This is especially true in a accurate model; and if a detailed, accurate model
research environment, where the developer is cannot be developed, implementing the model in
unlikely to be particularly familiar with or concerned code such that it accurately reflects reality will
about software system design concepts. Although a be even more difficult.
system developed using this type of undocumented,
An example of this situation in the area of icing
patchwork approach may well have certain good
simulation code development is the coefficient
features, it is not likely to be a cohesive, high quality
for convective heat transfer over a rough surface.
system - and whatever qualities it does have, "only which plays a critical role in the determination of
the developer knows for sure!"
the amount of incoming supercooled water that
Another inevitable consequence of this changes to ice during a given time increment.
individualistic, informal approach to software Unfortunately, information indicating precisely
development is that. when only one individual has the what this coefficient should be is limited, and
appropriate knowledge to be able to work on a thus the determination of requirements and the
system. the timing and content of any release of that creation of appropriate testing proccdures to
6
American Institute of Aeronautics and Astronautics
AI AA-99-0248
verify this aspect of the code are especially Depending on the nature of the numerical
difficult. equations and on the methods used to solve
them, more problems of the type described above
(2) Innhilit! to ohtairr ittjornintioti ,for testitrg of in item (2)c an arise due to a lack of knowledge
~irmiericalm odels ofthe physicnl processes
with respect to intermediate results ohtained
In addition to uncertainties in the creation of during the course of the overall calculation
physical models, there can arise difficulties procedure.
associated with testing the accuracy of those
models resulting from a lack of available data. It is the goal of the research effort to address these
This can be due to deficiencies in measurement three problems while creating a software system that
capabilities or to a lack of resources necessary to is usable, reliable. and accurate. Unfortunately. the
obtain the appropriate information. aspects of ice accretion computational simulation
described above can lead to difficulty in utilizing
If data is unavailable for evaluation of a software ideal software development techniques to produce a
system or its subsystems, then the acceptability system with these desired qualities. Given this. the
of the software is based on the judgement of the inherent deficiencies in our understanding of icing
developer. This tends to make that element of phenomena can be addressed in two ways. The firs1
the software only as good as the experience of is to factor these elements into the specification of
the developer. Additionally, there is then no way appropriate requirements, and the second is to
to assess the impact of that software element on develop a process for continual improvement of the
the accuracy of the overall system. The software in a controlled manner. With this in mind,
developer is left to examine influences of the LEWICE development team has identified
subsystems on the overall product by running several goals for process improvement that will lead
parametric studies. If the number of such to a more managed software development
subsystems is small, then there is a chance of environment and to a LEWICE code that has the
determining how any given intermediate result desired quality attributes.
should behave in a system that is operating
correctly. If however, as is more commonly the ImDrovement Initiative Goals
case, the number of such unverified subsystems As previously indicated, in an effort to address the
is large. then attempting to understand what issues discussed above, the NASA Lewis Icing
result any one subsystem should be producing Branch in collahoration with the Engineering Design
becomes impractical. and Analysis Division has recently begun a software
process improvement initiative. The intent of this
(3) Conrplexities itr the iiuniericnl represeritatiori of
the physiccil processes initiative is to improve code quality. as well as the
overall software development environment. by
Finally, even if the physical process being
incorporating appropriate new approaches into the
modeled is well understood and there is
icing simulation development process. To that end.
sufficient information available for
specific "process goals" have been established to
comprehensive testing, there can arise
guide the improvement effort. These process goals
difficulties associated with the transformation of
represent the means by which the ultimate end goal
the defining equations of the process into the
of high quality software produced within a
numerical algorithm required to solve those
controlled, predictable environment will be achieved.
equations. This is the typical focus of much of
the work in the field of computational simulation For the reasons mentioned earlier. the process goals
of the field equations of continuum dynamics. for this activity are based both on the unique
attributes and priorities of the organization and on the
Typically. an equation is developed that
standard recommendations of software process
represents the physical process of interest and
improvement practitioners. In the latter case. the
this equation, or set of equations, cannot be
primary source of information and guidance is the
solved through means of mathematical analysis.
Capability Maturity Model for Software (CMM). a
As such, numerical representations of the
detailed roadmap for software process improvement
governing equations are developed which allow
developed by the Software Engineering Institute
approximations of the solutions to he calculated.
(SEI) at Carnegie Mellon University.h
The accuracy of the approximations are
dependent on the methods used to develop the Process God I: "ltistitutioiinl Kiiowvledge
"
numerical representations of the original
One of the fundamental concepts expressed in the
equations. the terms in the equations that are
CMM is the idea that. only with appropriate
neglected. and the methods used to solve the new
documentation. is it possible for an organization to
numerical representations of the governing
repeat or improve upon past successes. Otherwise.
equations.
7
American Institute of Aeroni autics and Astronautics
AI A A-99-0248
the success or failure of any particular project is Process Goal 4: Preparatioii of a Flexible, Well
based entirely upon the individual skills and Thought-Out. Well-Structured
dedication of those who happen to be involved in the Design
project. This latter situation represents "individual
Although a good design is a basic requirement of any
know 1e dge, as contrasted w i t h institutiona I
" " high quality software system, the uncertainties that
knowledge." which is knowledge that is available to
currently exist in the icing simulation modeling
any member of an organization and which outlives
process, as well as the overall complexity of the
any given individual's association with that
process, make a well-planned, flexible design all the
organization. The required documentation is
more critical. Given the continually changing state of
twofold: first is the technical information such as
knowledge within the icing research field, it is not
system requirements and design, and second is the
sufficient to simply build a system that incorporates
documentation of project plans and procedures.
well-understood features currently desired by the user
Explicitly defining both types of documentation not
community. Instead. it is important to build a system
only provides the basis for process improvement, but
that can also be easily updated to incorporate new
is also a key element of any leani-based activity,
capabilities and techniques without compromising the
since these documents specify the information
existing system. This is accomplished by taking the
necessary for coordination amongst team members.
time to prepare a carefully thought-out. well-
It is imperative, however. not IO neglect any facet of
structured, flexible design, which allows for
this documentation. as to do 40 would ultimately modifications to the system with a minimum of
impair the organization's ahilily to repcat successful
impact .
practices or implement relevant iiiiprovcnients.
Process Goal 5: Applicntioti of Rigorous Software
Process Goal 2: Use qf (1 Tiwtrr-Htr.\id Appromh
Mririagenient Practices
The use of a team-based approach for software
In addition to the critical importance of
development providcs sc\ era1 ad\ anlages over the
documentation, another fundamental principle
typical individualistic approach ol'tcn used in a
expressed in the CMM is the concept that, without
research environment. Sonic 01 tlicw advantages are
management discipline on a project, any engineering
simply a consequence ol' ~lic\I iaring ol' knowledge
improvements will likely be sacrificed to schedule
and workload that occurs u 1111 tlic uw of a team. For
and/or cost pressures at the first sign of trouble. For
example, from an organi/;ilion;il pcr\pcctive. a team-
this reason, it is important to tackle management
based approach spares tlic cirg;ini/aiion the risk of
issues early in a process improvement initiative if
relying on a single individu;il'\ ;ihilil! and availability
other changes are to endure.
in order to complete a prciicC*t. On thc orher hand.
from the individual de\ cltipk-r'N perspective, this The types of activities that must occur in order to
approach helps to prwcni ~hc\I res\ and schedule bring management discipline to a project are
pressure that result from h;ii ins \ole responsibility described in the CMM as follows:
for the release of a sottwarc \>dciii.
. software managers for a project track software
'I..
An additional advantage of approach is that, by costs, schedules, and functionality; problems in
having multiple individual4 H it11 ili! crsc backgrounds meeting commitments are identified when they arise.
and capabilities working on Ihc same project, the Software requirements and the work products
overall system quality ciili hc greatly enhanced, as developed to satisfy them are baselined, and their
each team member can bring unique knowledge and integrity is controlled. Software project standards are
skills to the project. defined, and the organization ensures they are
faithfully followed. The software project works with
Process Goal3: Use oj' Sojtbt,trre Formal
its subcontractors, if any, to establish a strong
Inspectior is
customer-supplier relationship."8
Software Formal Inspections are essentially well
Process Goal 6: Iniplenieritutiori of Pilot Activities
defined, structured meetings where project work
products are reviewed in an effort to remove defects. citid Application of Lessons
Learned to Future lcirrg Brarich
They have, without exception, been found to enhance
Projects
software system quality and reduce costs - especially
when used often and early in a project. If handled During the first phase of this initiative, establishing
appropriately. inspections can also help to ensure that appropriate processes for use during the development
desired capabilities are incorporated into a system, of the LEWICE software. and improving the
and that the best approaches for implementing and LEWICE code quality. are without question
verifying those capabilities are used. important objectives with intrinsic value of their own.
However, from the standpoint of the process
improvement initiative, these activities are also being
8
American Institute of Aeronautics and Astronautics
