UNIT–II

Theoldwayandthenew:TheprinciplesofconventionalsoftwareEngineering,principlesofmodern
software management, transitioning to an iterative process.
Life cycle phases: Engineering and production stages, inception, Elaboration, construction,
transition phases.
Artifacts of the process: The artifact sets, Management artifacts, Engineering artifacts,
programmatic artifacts.

THE OLD WAY AND THE NEW

THE PRINCIPLES OF CONVENTIONAL SOFTWARE ENGINEERING
1.Make quality #1. Quality must be quantified and mechanisms put into place to motivate its
achievement
2. High-quality software is possible. Techniques that have been demonstrated to increase
quality in clued involving the customer, prototyping, simplifying design, conducting
inspections, and hiring the best people
3. Give products to customers early. No matter how hard you try to learn users' needs during
the requirements phase, the most effective way to determine real needs is to give users a
product and let them play with it
4. Determine the problem before writing the requirements. When faced with what they
believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem,
be sure to explore all the alternatives and don't be blinded by the obvious solution
5. Evaluate design alternatives. After the requirements are agreed upon, you must examine a
variety of architectures and algorithms. You certainly do not want to use” architecture" simply
because it was used in the requirements specification.
6. Use an appropriate process model. Each project must select a process that makes ·the
most sense for that project on the basis of corporate culture, willingness to take risks,
application area, volatility of requirements, and the extent to which requirements are well
understood.
7. Use different languages for different phases. Our industry's eternal thirst for simple
solutions to complex problems has driven many to declare that the best development method is
one that uses the same notation throughout the life cycle.
8. Minimize intellectual distance. To minimize intellectual distance, the software's structure
should be as close as possible to the real-world structure
9. Put techniques before tools. An undisciplined software engineer with a tool becomes a
dangerous, undisciplined software engineer
10. Get it right before you make it faster. It is far easier to make a working program run
faster than it is to make a fast program work. Don't worry about optimization during initial
coding
11. Inspect code. Inspecting the detailed design and code is a much better way to find errors
than testing
12. Good management is more important than good technology. Good management
motivates people to do their best, but there are no universal "right" styles of management.
13. People are the key to success. Highly skilled people with appropriate experience, talent,
and training are key.
14. Followwithcare.Justbecauseeverybodyisdoingsomethingdoesnotmakeitrightforyou.Itmayb
e right, but you must carefully assess its applicability to your environment.
15. Take responsibility. When a bridge collapses we ask, "What did the engineers do wrong?"
Even when software fails, we rarely ask this. The fact is that in any engineering discipline, the
best methods can be used to produce awful designs, and the most antiquated methods to
produce elegant designs.
16. Understand the customer's priorities. It is possible the customer would tolerate 90% of
the functionality delivered late if they could have 10% of it on time.
17. The more they see, the more they need. The more functionality (or performance) you
provide a user, the more functionality (or performance) the user wants.
18. Plan to throw one away. One of the most important critical success factors is whether or
not a product is entirely new. Such brand-new applications, architectures, interfaces, or
algorithms rarely work the first time.
19. Design for change. The architectures, components, and specification techniques you use
must accommodate change.
20. Design without documentation is not design. I have often heard software engineers say, "I
have finished the design. All that is left is the documentation. "
21. Use tools, but be realistic. Software tools make their users more efficient.
22. Avoid tricks. Many programmers love to create programs with tricks constructs that perform
a function correctly, but in an obscure way. Show the world how smart you are by avoiding tricky
code
23. Encapsulate. Information-hiding is a simple, proven concept that results in software that is
easier to test and much easier to maintain.
24. Use coupling and cohesion. Coupling and cohesion are the best ways to measure software's
inherent maintainability and adaptability
25. Use the McCabe complexity measure. Although there are many metrics available to report the
inherent complexity of software, none is as intuitive and easy to use as Tom McCabe's
26.Don't test your own software. Software developers should never be the primary testers of their
own software.
27.Analyze causes for errors. It is far more cost-effective to reduce the effect of an error by
preventing it than it is to find and fix it. One way to do this is to analyze the causes of errors as
they are detected
28.Realize that software's entropy increases. Any software system that undergoes continuous
change will grow in complexity and will become more and more disorganized
29.People and time are not interchangeable. Measuring a project solely by person-months makes
little sense 30.Expect excellence. Your employees will do much better if you have high
expectations for them.

THE PRINCIPLES OF MODERN SOFTWARE MANAGEMENT

Top 10 principles of modern software management are. (The first five, which are the main
themes of my definition of an iterative process, are summarized in Figure 4-1.)
1. Base the process on an architecture-first approach. This requires that a demonstrable
balance be achieved among the driving requirements, the architecturally significant design
decisions, and the lifecycle plans before the resources are committed for full-scale development.
2. Establish an iterative life-cycle process that confronts risk early. With today's
sophisticated software systems, it is not possible to define the entire problem, design the entire
solution, build the software, and then test the end product in sequence. Instead, an iterative
process that refines the problem understanding, an effective solution, and an effective plan over
several iterations encourages a balanced treatment of all stake holder objectives. Major risks
must be addressed early to increase predictability and avoid expensive downstream scrap and
rework.
3. Transition design methods to emphasize component-based development. Moving from a
line-of-code mentality to a component-based mentality is necessary to reduce the amount of
human-generated source code and custom development.
4. Establish a change management environment. The dynamics of iterative development,
including concurrent work flows by different teams working on shared artifacts, necessitates
objectively controlled baselines.
5. Enhance change freedom through tools that support round-trip engineering. Round-trip
engineering is the environment support necessary to automate and synchronize engineering
information in different formats(such as requirements specifications, design models, source
code, executable code, test cases).
6. Capture design artifacts in rigorous, model-based notation. A model based approach
(such as UML) supports the evolution of semantically rich graphical and textual design
notations.
7. Instrument the process for objective quality control and progress assessment. Life-cycle
assessment of the progress and the quality of all intermediate products must be integrated into
the process.
8. Use a demonstration-based approach to assess intermediate artifacts.
9. Plan intermediate releases in groups of usage scenarios with evolving levels of detail. It
is essential that the software management process drive toward early and continuous
demonstrations within the operational context of the system, namely its use cases.
10. Establish a configurable process that is economically scalable. No single process is
suitable for all software developments.

Table 4-1 maps top 10 risks of the conventional process to the key attributes and principles of a
modern process
TRANSITIONING TO AN ITERATIVE PROCESS

Modern software development processes have moved away from the conventional waterfall
model, in which each stage of the development process is dependent on completion of the
previous stage.
The economic benefits inherent in transitioning from the conventional waterfall model to an
iterative development process are significant but difficult to quantify. As one benchmark of the
expected economic impact of process improvement, consider the process exponent parameters
of the COCOMO II model. (Appendix B provides more detail on the COCOMO model) This
exponent can range from 1.01 (virtually no diseconomy of scale) to 1.26 (significant
diseconomy of scale). The parameters that govern the value of the process exponent are
application precedentedness, process flexibility, architecture risk resolution, team cohesion, and
software process maturity.
The following paragraphs map the process exponent parameters of COCOMO II to mytop10
principles of a modern process.

* Application precedentedness. Domain experience is a critical factor in understanding how to

plan and execute a software development project. For unprecedented systems, one of the key
goals is to confront risks and establish early precedents, even if they are incomplete or
experimental. This is one of the primary reasons that the software industry has moved to an
iterative life-cycle process. Early iterations in the life cycle establish precedents from which the
product, the process, and the plans can be elaborated in evolving levels of detail.
* Process flexibility. Development of modern software is characterized by such a broad
solution space and so many interrelated concerns that there is a paramount need for continuous
incorporation of changes. These changes may be inherent in the problem understanding, the
solution space, or the plans. Project artifacts must be supported by efficient change
management commensurate with project needs. A configurable process that allows a common
frame work to be adapted across arrange of projects is necessary to achieve a software return on
investment.
* Architecture risk resolution. Architecture-first development is a crucial theme underlying a
successful iterative development process. A project team develops and stabilizes architecture
before developing all the components that make up the entire suite of applications components. An
architecture-first and component-based development approach forces the infrastructure, common
mechanisms, and control mechanisms to be elaborated early in the life cycle and drives all
component make/buy decisions into the architecture process.
* Team cohesion. Successful teams are cohesive, and cohesive teams are successful. Successful
teams and cohesive teams share common objectives and priorities. Advances in technology
(such as programming languages, UML, and visual modeling) have enabled more rigorous and
understandable notations for communicating software engineering information, particularly in
the requirements and design artifacts that previously were ad hoc and based completely on
paper exchange. These model- based formats have also enabled the round-trip engineering
support needed to establish change freedom sufficient for evolving design representations.
* Software process maturity. The Software Engineering Institute's Capability Maturity Model
(CMM) is a well-accepted benchmark for software process assessment. One of key themes is
that truly mature processes are enabled through an integrated environment that provides the
appropriate level of automation to instrument the process for objective quality control.
Important questions

Explain briefly Waterfall model. Also explain Conventional s/w management performance?
1.
Define Software Economics. Also explain Pragmatic s/w cost estimation?
2.

3. Explain Important trends in improving Software economics?

4. Explain five staffing principal offered by Boehm. Also explain Peer Inspections?
Explain principles of conventional software engineering?
5..
Explain briefly principles of modern software management
6.

LIFECYCLE PHASES
Characteristic of a successful software development process is the well-defined separation
between "research and development" activities and "production" activities. Most unsuccessful
projects exhibit one of the following characteristics:
 An overemphasis on research and development
 An overemphasis on production.
Successful modern projects-and even successful projects developed under the conventional
process-tend to have a very well-defined project milestone when there is a noticeable transition
from a research attitude to a production attitude. Earlier phases focus on achieving functionality.
Later phases revolve around achieving a product that can be shipped to a customer, with explicit
attention to robustness, performance, and finish.
Amodernsoftwaredevelopmentprocessmustbedefinedtosupportthefollowing:
 Evolution of the plans, requirements, and architecture, together with well
defined synchronization points
 Risk management and objective measures of progress and quality
 Evolutionofsystemcapabilitiesthroughdemonstrationsofincreasingfunctionality

ENGINEERINGANDPRODUCTIONSTAGES

To achieve economies of scale and higher returns on investment, we must move toward a
software manufacturing process driven by technological improvements in process automation
and component-based development. Two stages of the life cycle are:

1. The engineering stage, driven by less predictable but smaller teams doing
design and synthesis activities
2. The production stage, driven by more predictable but larger teams doing
construction, test, and deployment activities

The transition between engineering and production is a crucial event for the various
stakeholders. The production plan has been agreed upon, and there is a good enough
understanding of the problem and the solution that all stakeholders can make a firm
commitment to go ahead with production.
Engineeringstageisdecomposedintotwodistinctphases,inceptionandelaboration,andtheproduction
stage into construction and transition. These four phases of the life-cycle process are loosely
mapped to the conceptual framework of the spiral model as shown in Figure 5-1

INCEPTIONPHASE
The overriding goal of the inception phase is to achieve concurrence among stakeholders on the
life-cycle objectives for the project.

PRIMARYOBJECTIVES
 Establishing the project's software scope and boundary conditions, including an
operational concept, acceptance criteria, and a clear understanding of what is and is not
intended to be in the product
 Discriminating the critical use cases of the system and the primary scenarios of
operation that will drive the major design trade-offs
 Demonstratingatleastonecandidatearchitectureagainstsomeoftheprimary scenanos
 Estimating the cost and schedule for the entire project (including
detailed estimates for the elaboration phase)
 Estimating potential risks(sources of unpredictability)

ESSENTIALACTMTIES
 Formulating the scope of the project. The information repository should be
sufficient to define the problem space and derive the acceptance criteria for the end
product.
 Synthesizing the architecture. An information repository is created that is
sufficient to demonstrate the feasibility of at least one candidate architecture and an, initial
baseline of make/buy decisions so that the cost, schedule, and resource estimates can be
derived.
 Planning and preparing a business case. Alternatives for risk management,
staffing, iteration plans, and cost/schedule/profitability trade-offs are evaluated.
PRIMARYEVALUATIONCRITERIA
 Do all stakeholders concur on the scope definition and cost and schedule estimates?
 Are requirements understood, as evidenced by the fidelity of the critical use cases?
 Are the cost and schedule estimates, priorities, risks, and development processes
credible?
 Do the depth and breadth of an architecture prototype demonstrate the preceding
criteria? (The primary value of prototyping candidate architecture is to provide a vehicle
for understanding the scope and assessing the credibility of the development group in
solving the particular technical problem.)
 Are actual resource expenditures versus planned expenditures acceptable

ELABORATIONPHASE

At the end of this phase, the "engineering" is considered complete. The elaboration phase
activities must ensure that the architecture, requirements, and plans are stable enough, and the
risks sufficiently mitigated, that the cost and schedule for the completion of the development
can be predicted with in an acceptable range. During the elaboration phase, an executable
architecture prototype is built in one or more iterations, depending on the scope, size, & risk.
PRIMARYOBJECTIVES
 Base lining the architecture as rapidly as practical (establishing a configuration-
managed snapshot in which all changes are rationalized, tracked, and maintained)
 Base lining the vision
 Base lining a high-fidelity plan for the construction phase
 Demonstrating that the baseline architecture will support the vision at a reasonable
cost in a reasonable time

ESSENTIALACTIVITIES
 Elaborating the vision.
 Elaborating the process and infrastructure.
 Elaborating the architecture and selecting components.

PRIMARYEVALUATIONCRITERIA
 Is the vision stable?
 Is the architectures table?
 Does the executable demonstration show that the major risk elements have been
addressed and credibly resolved?
 Is the construction phase plan of sufficient fidelity, and is it backed up with a credible
basis of estimate?
 Do all stake holders agree that the current vision can be met if the current plan is
executed to develop the complete system in the context of the current architecture?
 Are actual resource expenditures versus planned expenditures acceptable?

CONSTRUCTIONPHASE
During the construction phase, all remaining components and application features are integrated into the
application, and all features are thoroughly tested. Newly developed software is integrated where required.
The construction phase represents a production process, in which emphasis is placed on managing resources
and controlling operations to optimize costs, schedules, and quality.

PRIMARYOBJECTIVES
 Minimizing development costs by optimizing resources and avoiding
unnecessary scrap and rework
 Achieving adequate quality as rapidly as practical
 Achieving useful versions (alpha, beta, and other test releases) as rapidly as practical
ESSENTIAL ACTIVITIES
 Resource management, control, and process optimization
 Complete component development and testing against evaluation criteria
 Assessment of product releases against acceptance criteria of the vision

PRIMARYEVALUATIONCRITERIA
 Is this product baseline mature enough to be deployed in the user community?
(Existing defects are not obstacles to achieving the purpose of the next release.)
 Is this product baseline stable enough to be deployed in the user community?
(Pending changes are not obstacles to achieving the purpose of the next release.)
 Are the stakeholders ready for transition to the user community?
 Are actual resource expenditures versus planned expenditures acceptable?

TRANSITIONPHASE
The transition phase is entered when a base line is mature enough to be deployed in the end-user
domain. This typically requires that a usable subset of the system has been achieved with
acceptable quality levels and user documentation so that transition to the user will provide
positive results. This phase could include any of the following activities:

1. Beta testing to validate the new system against user expectations

2. Beta testing and parallel operation relative to a legacy system it is replacing
3. Conversion of operational databases
4. Training of users and maintainers
The transition phase concludes when the deployment base line has achieved the complete vision.

PRIMARYOBJECTIVES
 Achieving user self-supportability
 Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision
 Achieving final product base lines as rapidly and cost-effectively as practical

ESSENTIALACTIVITIES
 Synchronization and integration of concurrent construction increments into
consistent deployment baselines
 Deployment-specific engineering (cutover, commercial packaging and
production, sales rollout kit development, field personnel training)
 Assessment of deployment baselines against the complete vision and
acceptance criteria in the requirements set

EVALUATIONCRITERIA
 Is the user satisfied?
 Are actual resource expenditures versus planned expenditures acceptable?

ARTIFACTS OF THE PROCESS

THE ARTIFACT SETS
To make the development of a complete software system manageable, distinct collections of
information are organized into artifact sets. Artifact represents cohesive information that
typically is developed and reviewed as a single entity.
Life-cycle software artifacts are organized into five distinct sets that are roughly partitioned by
the underlying language of the set: management (ad hoc textual formats), requirements
(organized text and models of the problem space), design (models of the solution space),
implementation (human-readable programming language and associated source files), and
deployment (machine-process able languages and associated files). The artifact sets are shown
in Figure 6-1.
 THE MANAGEMENT SET
The management set captures the artifacts associated with process planning and execution.
These artifacts use ad hoc notations, including text, graphics, or whatever representation is
required to capture the "contracts" among project personnel (project management,
architects, developers, testers, marketers, administrators), among stakeholders (funding
authority, user, software project manager, organization manager, regulatory agency),and
between project personnel and stake holders. Specific artifacts included in this set are the
work breakdown structure (activity breakdown and financial tracking mechanism), the
business case (cost, schedule, profit expectations), the release specifications (scope, plan,
objectives for release baselines), the software development plan (project process instance),
the release descriptions (results of release baselines), the status assessments (periodic
snapshots of project progress), the software change orders (descriptions of discrete baseline
changes), the deployment documents(cutover plan, training course, sales rollout kit), and
the environment (hardware and software tools, process automation,& documentation).
Management set artifacts are evaluated, assessed, and measured through a combination of the
following:
 Relevant stakeholder review
 Analysis of changes between the current version of the artifact and previous versions
 Major milestone demonstrations of the balance among all artifacts and, in
particular, the accuracy of the business case and vision artifacts

THE ENGINEERING SETS

The engineering sets consist of the requirements set, the design set, the
implementation set, and the deployment set.

Requirements Set
Requirements artifacts are evaluated, assessed, and measured through a combination of the
following:

 Analysis of consistency with the release specifications of the management set

 Analysis of consistency between the vision and the requirements models
 Mapping against the design, implementation, and deployment sets to evaluate the
consistency and completeness and the semantic balance between information in the
different sets
 Analysis of changes between the current version of requirements artifacts and
previous versions (scrap, rework, and defect elimination trends)
 Subjective review of other dimensions of quality

Design Set
UML notation is used to engineer the design models for the solution. The design set contains
varying levels of abstraction that represent the components of the solution space (their
identities, attributes, static relationships, dynamic interactions). The design set is evaluated,
assessed, and measured through a combination of the following:
 Analysis of the internal consistency and quality of the design model
 Analysis of consistency with the requirements models
 Translation into implementation and deployment sets and notations (for example,
traceability, source code generation, compilation, linking) to evaluate the consistency and
completeness and the semantic balance between information in the sets
 Analysis of changes between the current version of the design model and
previous versions (scrap, rework, and defect elimination trends)
 Subjective review of other dimensions of quality
Implementation set
The implementation set includes source code (programming language notations) that represents
the tangible implementations of components (their form, interface, and dependency relationships)
implementation sets are human-readable formats that are evaluated, assessed, and measured
through a combination of the following:
 Analysis of consistency with the design models
 Translation into deployment set notations (for example, compilation and linking) to
evaluate the consistency and completeness among artifact sets
 Assessment of component source or executable files against relevant evaluation criteria
through inspection, analysis, demonstration, or testing
 Execution of stand-alone component test cases that automatically compare expected
results with actual results
 Analysis of changes between the current version of the implementation set and previous
versions (scrap, rework, and defect elimination trends)
 Subjective review of other dimensions of quality
Deployment Set
The deployment set includes user deliverables and machine language notations, executable
software, and the
build scripts, installation scripts, and executable target specific data necessary to use the product
in its target
environment.
Deployment sets are evaluated, assessed, and measured through a combination of the following:
 Testing against the usage scenarios and quality attributes defined in the requirements set
to evaluate the consistency and completeness and the~ semantic balance between information in
the two sets
 Testing the partitioning, replication, and allocation strategies in mapping components of
the implementation set to physical resources of the deployment system (platform type, number,
network topology)
 Testing against the defined usage scenarios in the user manual such as installation, user-
orient dynamic reconfiguration, mainstream usage, and anomaly management
 Analysis of changes between the current version of the deployment set and previous versions
(defect elimination trends, performance changes)
 Subjective review of other dimensions of quality
Each artifact set is the predominant development focus of one phase of the life cycle; the other
sets take on check and balance roles. As illustrated in Figure 6-2, each phase has a predominant
focus: Requirements are the focus of the inception phase; design, the elaboration phase;
implementation, the construction phase; and deployment, the transition phase. The management
artifacts also evolve, butat a fairly constant level across the life cycle.
Most of today's software development tools map closely to one of the five artifact sets.
1. Management: scheduling, workflow, defect tracking, change management,
documentation, spreadsheet, resource management, and presentation tools
2. Requirements: requirements management tools
3. Design: visual modeling tools
4. Implementation: compiler/debugger tools, code analysis tools, test coverage analysis tools, and
test
management tools
5. Deployment: test coverage and test automation tools, network management tools, commercial
components (operating systems, GUIs, RDBMS, networks, middleware), and installation tools.

Implementation Set versus Deployment Set

The separation of the implementation set (source code) from the deployment set (executable
code) is important because there are very different concerns with each set. The structure of the
information delivered to the user (and typically the test organization) is very different from the
structure of the source code information. Engineering decisions that have an impact on the quality
of the deployment set but are relatively incomprehensible in the design and implementation sets
include the following:
 Dynamically reconfigurable parameters (buffer sizes, color palettes, number of servers,
number of simultaneous clients, data files, run-time parameters)
 Effects of compiler/link optimizations (such as space optimization versus speed
optimization)
 Performance under certain allocation strategies (centralized versus distributed, primary
and shadow threads, dynamic load balancing, hot backup versus checkpoint/rollback)
 Virtual machine constraints (file descriptors, garbage collection, heap size, maximum
record size, disk file rotations)
 Process-level concurrency issues (deadlock and race conditions)
 Platform-specific differences in performance or behavior
ARTIFACT EVOLUTION OVER THE LIFE CYCLE
Each state of development represents a certain amount of precision in the final system
description. Early in the life cycle, precision is low and the representation is generally high.
Eventually, the precision of representation is high and everything is specified in full detail. Each
phase of development focuses on a particular artifact set. At the end of each phase, the overall
system state will have progressed on all sets, as illustrated in Figure 6-3.

The inception phase focuses mainly on critical requirements usually with a secondary focus on
an initial deployment view. During the elaboration phase, there is much greater depth in
requirements, much more breadth in the design set, and further work on implementation and
deployment issues. The main focus of the construction phase is design and implementation.
The main focus of the transition phase is on achieving consistency and completeness of the
deployment set in the context of the other sets.

6.1.4 TEST ARTIFACTS

The test artifacts must be developed concurrently with the product from inception through
deployment. Thus, testing is a full-life-cycle activity, not a late life-cycle activity.
 The test artifacts are communicated, engineered, and developed within the same artifact
sets as the
developed product.
 The test artifacts are implemented in programmable and repeatable formats (as software
programs).
 The test artifacts are documented in the same way that the product is documented.
 Developers of the test artifacts use the same tools, techniques, and training as the software
engineers developing the product.
Test artifact subsets are highly project-specific, the following example clarifies the relationship
between test artifacts and the other artifact sets. Consider a project to perform seismic data
processing for the purpose of oil exploration.
This system has three fundamental subsystems: (1) a sensor subsystem that captures raw seismic
data in real time and delivers these data to (2) a technical operations subsystem that converts raw
data into an organized database and manages queries to this database from (3) a display
subsystem that allows workstation operators to examine seismic data in human-readable form.
Such a system would result in the following test artifacts:
 Management set. The release specifications and release descriptions capture the
objectives, evaluation criteria, and results of an intermediate milestone. These artifacts are the test
plans and test results negotiated among internal project teams. The software change orders
capture test results (defects, testability changes, requirements ambiguities, enhancements) and the
closure criteria associated with making a discrete change to a baseline.
 Requirements set. The system-level use cases capture the operational concept for the
system and the acceptance test case descriptions, including the expected behavior of the system
and its quality attributes. The entire requirement set is a test artifact because it is the basis of all
assessment activities across the life cycle.
 Design set. A test model for non deliverable components needed to test the product
baselines is captured in the design set. These components include such design set artifacts as a
seismic event simulation for creating realistic sensor data; a "virtual operator" that can support
unattended, afterhours test cases; specific instrumentation suites for early demonstration of
resource usage; transaction rates or response times; and use case test drivers and component
stand-alone test drivers.
 Implementation set. Self-documenting source code representations for test components
and test drivers provide the equivalent of test procedures and test scripts. These source files may
also include human-readable data files representing certain statically defined data sets that are
explicit test source files. Output files from test drivers provide the equivalent of test reports.
 Deployment set. Executable versions of test components, test drivers, and data files are
provided.

MANAGEMENTARTIFACTS
Themanagementsetincludesseveralartifactsthatcaptureintermediateresultsandancillary
information necessary to document the product/process legacy, maintain the product,
improve the product, and improve the process.

Business Case
The business case artifact provides all the information necessary to determine whether the
project is worth investing in. It details the expected revenue, expected cost, technical and
management plans, and backup data necessary to demonstrate the risks and realism of the
plans. The main purpose is to transform the vision into economic terms so that an
organization can make an accurate ROI assessment. The financial forecasts are
evolutionary, updated with more accurate forecasts as the life cycle progresses. Figure 6-4
provides a default outline for a business case.

Software Development Plan

The software development plan (SDP) elaborates the process framework into a fully
detailed plan. Two indications of a useful SDP are periodic updating (it is not stagnant
shelfware) and understanding and acceptance by managers and practitioners alike. Figure
6-5 provides a default outline for a software development plan.
Work Break down Structure
Work breakdown structure (WBS) is the vehicle for budgeting and collecting costs. To monitor
and control a project's financial performance, the software project man1ger must have insight
into project costs and how they are expended. The structure of cost accountability is a serious
project planning constraint.
Software Change Order Database
Managing change is one of the fundamental primitives of an iterative development process.
With greater change freedom, a project can iterate more productively. This flexibility increases
the content, quality, and number of iterations that a project can achieve within a given schedule.
Change freedom has been achieved in practice through automation, and today's iterative
development environments carry the burden of change management. Organizational processes
that depend on manual change management techniques have encountered major inefficiencies.

Release Specifications
The scope, plan, and objective evaluation criteria for each baseline release are derived from the
vision statement as well as many other sources (make/buy analyses, risk management concerns,
architectural considerations, shots in the dark, implementation constraints, quality thresholds).
These artifacts are intended to evolve along with the process, achieving greater fidelity as the
life cycle progresses and requirements understanding matures. Figure 6-6 provides a default
outline for a release specification
Release Descriptions
Releasedescriptiondocumentsdescribetheresultsofeachrelease,includingperformanceagainsteach
of
theevaluationcriteriainthecorrespondingreleasespecification.Releasebaselinesshouldbeaccompan
ied by a release description document that describes the evaluation criteria for that configuration
baseline and provides substantiation (through demonstration, testing, inspection, or analysis)
that each criterion has been addressed in an acceptable manner. Figure 6-7 provides a default
outline for a release description.
Status Assessments
Status assessments provide periodic snapshots of project health and status, including the
software project manager's risk assessment, quality indicators, and management indicators.
Typical status assessments should include a review of resources, personnel staffing, financial
data (cost and revenue), top 10 risks, technical progress (metrics snapshots), major milestone
plans and results, total project or product scope & action items

Environment
An important emphasis of a modern approach is to define the development and maintenance
environment as a first-class artifact of the process. A robust, integrated development environment
must support automation of the development process. This environment should include requirements
management, visual modeling, document automation, host and target programming tools, automated
regression testing, and continuous and integrated change management, and feature and defect
tracking.
Deployment
A deployment document can take many forms. Depending on the project, it could include several
document subsets for transitioning the product into operational status. In big contractual efforts in
which the system is delivered to a separate maintenance organization, deployment artifacts may
include computer system operations manuals, software installation manuals, plans and procedures for
cutover (from a legacy system), site surveys, and so forth. For commercial software products,
deployment artifacts may include marketing plans, sales rollout kits, and training courses.
Management Artifact Sequences
In each phase of the life cycle, new artifacts are produced and previously developed artifacts are
updated to incorporate lessons learned and to capture further depth and breadth of the solution. Figure
6-8 identifies a typical sequence of artifacts across the life-cycle phases.
6.3 ENGINEERING ARTIFACTS
Most of the engineering artifacts are captured in rigorous engineering notations such as UML, programming
languages, or executable machine codes. Three engineering artifacts are explicitly intended for more general
review, and they deserve further elaboration.
Vision Document
The vision document provides a complete vision for the software system under development and. Supports the
contract between the funding authority and the development organization. A project vision is meant to be
changeable as understanding evolves of the requirements, architecture, plans, and technology. A good vision
document should change slowly. Figure 6-9 provides a default outline for a vision document.

Architecture Description
The architecture description provides an organized view of the software architecture under
development. It is extracted largely from the design model and includes views of the design,
implementation, and deployment sets sufficient to understand how the operational concept of
the requirements set will be achieved. The breadth of the architecture description will vary from
project to project depending on many factors. Figure 6-10 provides a default outline for an
architecture description.

The software user manual provides the user with the reference documentation necessary to support the
delivered software. Although content is highly variable across application domains, the user manual
should include installation procedures, usage procedures and guidance, operational constraints, and a
user interface description, at a minimum. For software products with a user interface, this manual
should be developed early in the life cycle because it is a necessary mechanism for communicating
and stabilizing an important subset of requirements. The user manual should be written by members
of the test team, who are more likely to understand the user's perspective than the development team.
6.4 PRAGMATIC ARTIFACTS
 People want to review information but don't understand the language of the artifact.
Many interested reviewers of a particular artifact will resist having to learn the engineering language
in which the artifact is written. It is not uncommon to find people (such as veteran software managers,
veteran quality assurance specialists, or an auditing authority from a regulatory agency) who react as
follows: "I'm not going to learn UML, but I want to review the design of this software, so give me a
separate description such as some flowcharts and text that I can understand."
 People want to review the information but don't have access to the tools. It is not very
common for the development organization to be fully tooled; it is extremely rare that the/other
stakeholders have any capability to review the engineering artifacts on-line. Consequently,
organizations are forced to exchange paper documents. Standardized formats (such as UML,
spreadsheets, Visual Basic, C++, and Ada 95), visualization tools, and the Web are rapidly making it
economically feasible for all stakeholders to exchange information electronically.
 Human-readable engineering artifacts should use rigorous notations that are complete,
consistent, and used in a self-documenting manner. Properly spelled English words should be used
for all identifiers and descriptions. Acronyms and abbreviations should be used only where they are
well accepted jargon in the context of the component's usage. Readability should be emphasized and
the use of proper English words should be required in all engineering artifacts. This practice enables
understandable representations, browse able formats (paperless review), more-rigorous notations, and
reduced error rates.
 Useful documentation is self-defining: It is documentation that gets used.
 Paper is tangible; electronic artifacts are too easy to change. On-line and Web-based
artifacts can be changed easily and are viewed with more skepticism because of their inherent
volatility.