Transcript Software Process - Bethune

Introduction
to
Software Process
Software Engineering
January 9, 2007
Software Lifecycle
•
Definition
The complete history of a software system from concept formation through
decommission broken down into the following “maturation” phases:
– Requirements elicitation and definition
– Requirements elaboration and specification
– Design
• Architectural Design
• Detailed Design
– Implementation
• Coding
• Unit Testing
– Integration
Construction
• Subsystem testing
• System testing (acceptance testing)
– Operation & Maintenance
• Corrective : removing bugs ( 17.5% )
• Enhancement: improving exiting capability = perfective ( 60.5%) + adaptive ( 18% )
• Reengineering (includes adaptive and perfective maintenance)
– Retirement
7/18/2015
2
Life Cycle Costs
Requirements = 6%
Integration = 24%
Specification = 15%
Unit Testing = 21%
Design = 19%
Coding = 15%
(Schach - Classical and Object-Oriented Software Engineering)
7/18/2015
3
Process Models
•
Definition
Process models are “algorithms for developing software.” Software process is the
execution of a process model.
Data = development artifacts; Processors = people; Algorithms = methods + tools
•
Popular Models
–
–
–
–
–
Water Fall
Rapid Prototyping (throwaway & evolutionary)
Incremental Development
Reengineering
Spiral Model
7/18/2015
4
Water Fall Model
Features & Contributions
–
–
–
–
–
–
Author: Winston Royce 1970
First formal software development method (1950-70).
Encouraged specification of what the system is supposed to do before building it.
Encouraged planning and management monitoring and control.
Each development phase was completed before the next could begin.
Documents produced as the output of one phase become inputs to the next phase.
These documents provided a basis for verification and validation.
– Did not allow for changing requirements. Frequently, the user was not happy
with the delivered system.
Code & Unit
Test
System
Requirements
rework
Software
Requirements
rework
rework
7/18/2015
rework
Architectural
Design
Detailed
Design
Integration
& Test
Installation
& Maintenance
rework
5
Water Fall Model
1. System Requirements: The system concept is defined, customer and client
requirements are captured, hardware and software components defined and
mapped.
2. Software Requirements: a formal (complete, precise, consistent, and
unambiguous) description of “what” each software component must do is
prepared by the developer and reviewed by the customer (software specification
document); a software project plan is produced at the end of this phase.
3. Design phase: The specification is elaborated in two steps that define “how” the
product will work: Architectural Design breaks down the whole system into
component parts (modules) and the interactions between them (interfaces);
Detailed Design involves elaborating the design of individual components by
specifying data structures and algorithms.
4. Code & Unit: Software module designs are translated to code and then unit tested.
5. Integration & Test: Software modules are integrated into larger functional
aggregates (subsystems) and tested in the operational environment. The final step
tests the complete system (acceptance testing or validation – customer agrees that
the system meets the specification).
6. Installation & Maintenance: The completed system is installed in the operational
environment and maintained (error correction and enhancement) for the
remainder of the system lifetime.
7/18/2015
6
Water Fall Model
Errors Detected
Errors Introduced
Requirements
Specification
Design
Code
Unit
Test
Integration
& Test
System
Acceptance
Tests
Ref: The Impact of Prototyping on Software System Engineering, by Hassan Gomaa,
George Mason University, IEEE System and Software Requirements Engineering, 1990.
7/18/2015
7
Prototyping
•
Prototyping
The rapid and (relatively) inexpensive development of an operating model of
the desired system (or a subset) developed only for the purpose of defining or
elaborating requirements, and/or resolving unknown performance issues
before a full commitment of resources is made to produce the final system.
•
Benefits
– Water Fall models limit the amount of iteration among phases – a key feature of
prototyping is iterating rapidly through early phases of development.
– Water Fall models tend to produce a working system very late in the development
cycle – thus major problems may go undetected until the system is almost
complete. Prototyping focuses on identifying major technical problems as early
as possible.
– System requirements cannot be properly validated without a working version –
prototyping focuses on understanding and elaborating requirements through
demonstration.
Ref: The Impact of Prototyping on Software System Engineering, by Hassan Gomaa,
George Mason University, IEEE System and Software Requirements Engineering, 1990.
7/18/2015
8
Prototyping
Requirements for a Prototype
1. It must be an actual working system with which one can experiment and from
which lessons can be learned to revise the requirements specification.
2. It must be comparatively cheap to develop – approximately 10% of the total
estimated cost of the complete system.
3. Must be developed quickly so that it may be evaluated early in the development
cycle; it should be used to collect early feedback from system users.
Phases of Development
1. Preliminary analysis and specification of user requirements. (understand user's
problem)
2. Design and implementation of a prototype. (emphasize user interface, small
development team, development language, use prototyping development tools)
3. Exercise the prototype. (preliminary user training, user feedback)
4. Iterative refinement of the prototype.
5. Refinement of the requirements specification.
See Notes
6. Design and implementation of the production system.
7/18/2015
9
Prototyping
•
Throwaway Prototypes are constructed as part of the problem
understanding or analysis activity. Their purpose is to gain a deeper
understanding of the problem and its feasible solutions. It is a learning
device never intended for use - it is “thrown away” after it has served its
purpose.
– Because the prototype will be discarded, the time and effort spent on satisfying nonfunctional requirements and formal documentation can almost be eliminated. This
reduces development time.
– This approach should focus on understanding of requirements from the user's
perspective and to obtain early user feedback.
•
Evolutionary Prototypes are constructed to satisfy a subset of the system
requirements - as refinements are made or layers of functionality are added,
they “evolve” into the final system.
– Because each increment or prototype version is to be of production quality, nonfunctional requirements must be considered and some formal documentation must
be part of the prototyping process.
– The incremental nature of evolutionary prototyping ensures that a useful version of
the system is produced earlier that water fall methods.
See Notes
7/18/2015
10
Reengineering Process Model
Legacy Test Procedures,
Test Data & Results
Establish
Baseline
Legacy
System
Legacy
Baseline
Reuse &
Modify
Legacy
Units
Legacy
Requirements
Proposed
New
Capability
New
Requirements
Extract
Requirements
Modified
Requirements
Extract
Design
Legacy
Design
Test
Changes
Design
Changes
Identifiy
off-the-shelf
Units
For reuse
Without
modification
7/18/2015
Modify &
Enhance
Design
Set of Test-ready
Legacy Units
Re-Test
Legacy Units
Re-test
Procedures
Requirements
Analysis
Reuse
Libraries
Identified
Legacy Units
for Reuse &
Modification
New
Design
New
Design
Produce
New Test
Plan
Integration test
Procedures
New Unit test
Procedures
Construct & Test
new Units
Tested
Legacy Units
Integrate & Test
All
Units
Tested
new Units
Target
System
Off-the-shelf Units
ready for Integration
11
Spiral Model
A cyclic approach to software development marked by four basic stages that
are repeated on each cycle until the target system is delivered.
A risk-driven meta model.
Developed by Barry Boehm, “A Spiral Model of Software Development and
Enhancement”, IEEE Computer, Vol 21, No 5, May 1988.
Stage 1: Identify objectives, alternative solutions, and constraints for the
part of the system currently under consideration.
Stage 2: Evaluate alternatives and identify associated risks using
prototyping and simulation.
Stage 3: Develop and verify the next system increment.
Stage 4: Review outcome of earlier stages and plan the next cycle.
7/18/2015
12
Spiral Model
See Notes
2: Evaluate alternatives and
their risks
1: Determine objectives,
alternative solutions, &
constraints.
risk analysis
prototyping
Acceptance
&
Installation
Design
Planning
Implementation
Review
4: Review outcome and
Plan next cycle.
7/18/2015
Test
3: Develop, verify next
system increment.
13
Measurement and Control
Nominal Process Flow or Execution
See Notes
Process Quality Assessment and Control
Product Quality Assessment and Control
(Project Mangement)
Process Change
Directives
Progress & Quality
Assessment
Progress & Quality
Data
Effort and Size
Metrics
Product
Specifications
Development
Activity or
Procedure
Raw
Products
Product Change
Quality Metrics
Quality
Review
Metrics
Repository
Quality
Products
(and specification for
next Activity)
Directives
7/18/2015
14
Unified Software Process
Software Phases & Artifacts
Overview of USP
Requirements
Elicitation
(Definition)
Use Case
Model
Requirements
Elaboaration
(OO-Analysis)
Analysis
Model
The process of defining
and modeling the
Problem Space
Object-Oriented
Design
Design &
Deployment
Models
7/18/2015
Problem Statement
& User Needs
The process of defining
and modeling the
Solution Space
Object-Oriented
Implementation
(Programming)
Mapping design to
Implementation
Space
Code in an
OOPL (Ada95)
(C++)(Java)
Component
Model
16
Overview of USP
Birth
Death
Inception
Itera- Iteration tion
•
Elaboration
Iteration
Iteration
Construction
Iteration
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Inception (focus on “Feasibility”)
Develop a vision of the end product and prepare a business case. Answers the
questions:
• What is the system boundary? Begin to identify interfaces with systems outside the
boundary.
• What is the system going to do? What are the major classes of users? (Develop
Initial Use Case Model )( Identify and describe only a small % of use cases )
• What is a possible system architecture? ( Identify most critical subsystems )
• What is the project plan? What will the system cost? ( Identify critical risks )
(Develop a Project Management Plan)
• Demonstrate feasibility by building a prototype.
•
•
•
Elaboration
Construction
Transition
7/18/2015
17
Overview of USP
Birth
Death
Inception
Itera- Iteration tion
Elaboration
Iteration
Iteration
Construction
Iteration
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Arch. Design Detailed Design
•
•
Inception
Elaboration ( focus on “Do-Ability” )(Architecture + high-fidelity cost est.)
– Develop detailed use cases (80% of use cases).
– Develop a stable architectural view of the system using the Analysis Model, Design
Model, Implementation Model, and Deployment Model.
– Create a baseline system specification (SRS).
– Produce the Software Development Plan (SDP) which describes the next phase.
•
•
Construction
Transition
7/18/2015
18
Overview of USP
Birth
Inception
Itera- Iteration tion
•
•
•
Death
Elaboration
Iteration
Iteration
Construction
Iteration
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Inception
Elaboration
Construction (focus on building an operational capability)
Build the system (usually in increments defined by releases ). Each release
encapsulates defined use cases. Releases are ordered by priority determined by
customer needs and project risks.
•
Transition (focus on producing a formal release )
Product (release) enters beta testing and then distribution. This phase involves
manufacturing, training, and providing customer support infrastructure.
Transition ends with maintenance: corrective, adaptive, perfective.
7/18/2015
19
Overview of USP
USDP Models
Use Case Model
verified
by
test2
OK
specified
by
realized
by
implemented
by
Implementation
Model
7/18/2015
test1
OK
Test Model
distributed
by
Analysis Model
Design Model
Deployment
Model
20
Overview of USP
Core Work
Flows
Inception
Elaboration
Construction
Transition
Elicitation
Analysis
Design
Implementation
Test
Distribution of Core Activities Across Phases
7/18/2015
21
Use Case Modeling
September 18, 2002
Requirements Capture
•
Input
Client approaches Developer with a problem and or product concept. This may be
expressed verbally or in the form of a document (Statement of Work (SOW))
(Request for Proposal (RFP))
•
Activities
Developer interacts with Client and Users to elicit product requirements. This
involves face-to-face meetings and possibly the exchange of technical documents.
The Developer must determine as completely and precisely as possible the
following information:
– cost and time constraints
– target system platform and operational environment
– user groups
– functional capabilities
– non-functional constraints: quality and performance
– Client and User's needs (as opposed to "wants")
•
Outputs
A complete understanding of the problem the Client and Users need to have solved.
Client should be in agreement with the Developer’s assessment of the problem. This
shared view of the system is captured in the form of a UML Use Case Model.
7/18/2015
23
Use Case Model
•
Definitions1
A Use Case is a sequence of actions that the system performs to offer some
results of value to a User.
– Use cases drive the whole development process. “They offer a systematic and
intuitive means of capturing functional requirements from the user’s perspective.”
– A system has many types of users. Each type of user is define by an actor. Actors
may be people or external systems. Actors interact with the product via one or
more Use Cases. An actor role is defined by a particular set of use cases performed
by that actor to accomplish a particular goal or objective.
– “All actors and uses cases make up a Use Case Model.”
– A good collection of use cases is central to understanding what your users want.
Use Cases also present a good vehicle for project planning, because they control
iterative development, … it gives regular feedback to users about where the
software is going.
– Use cases provide the basis of communication between the client and the
developers in planning the project.
1The
Unified Software Development Process, by Rumbaugh, Jacobson, and Booch,
Addison-Wesley, 1999, 0-201-57169-2.
7/18/2015
24
Use Case Model
•
Definition2 (Fowler)
A Use Case captures a typical interaction between a user and a computer system.
– A use case captures some user-visible function.
– A use case may be small or large.
– A use case achieves a discrete objective for the user.
In its simplest usage, you capture a use case by talking to typical users and
discussing the various things they might want to do with the system.
Take each discrete task or action they want to do, give it a name, and
write up a short description.
During the Elaboration phase, this is all you need to do to get started.
2UML
Distilled, by Scott & Fowler
7/18/2015
25
Use Case Model Outline
•
Title (System Name, Author Name, Assignment, Course, Pub. Date)
–
–
TOC
List of Figures (optional for small documents)
1. System Summary
–
–
–
Overview of System Purpose and Context
Business Case ( business need and how this system will address this need )
System Operation
•
•
–
Use Case Diagram
Supporting Narrative (explains diagram: operational flow, actor roles )
System Interfaces ( External Interfaces with Actors )
2. Use Case Specifications
1. Purpose ( function from user’s perspective )
•
•
2.
3.
4.
5.
6.
Collaboration diagram (flow of interactions between actors and interface objects )
Narrative summary of use case purpose or function
Precondition (system states & triggering events )
Flow of Events (nominal flow of interaction events between actor and interface objects)
Alternative Paths (error processing flows; special case flows )
Post Condition (system states & completion events )
Special Requirements (non-functional : performance and quality )
3. Requirements Traceability
4. Glossary
7/18/2015
26
Requirements Elicitation Work Flow
System
Analyst
System
Architect
Use Case
Specialist
User Interface
Designer
7/18/2015
Structure
Use Case
Model
Find Actors
& Use Cases
Prioritize
Use Cases
Detail
Use Cases
Prototype
User Interface
27
Requirements Elaboration
•
Purpose
"To achieve a more precise understanding of requirements and to achieve a description of
requirements that is easy to maintain and that helps give structure to the whole system including the architecture."
•
Inputs
–
–
–
•
Outputs from Requirements Elicitation ( Use Case Model ).
Technical documents or expertise relevant to problem domain, in general, and to the Client's
problem, in particular.
Legacy System (optional)
Activities
Refine requirements by eliminating inconsistencies and ambiguities. Formalize requirements by
preparing a System/Software Requirements Specification. Develop an initial Software
Development Plan.
•
Outputs
–
System/Software Requirements Specification (SRS)
•
•
•
•
•
•
–
7/18/2015
UML Use Case Model and Scenarios
UML Class Model
UML Collaboration Model
UML Sequence Diagrams
Problem Glossary
Other info.
Software Development Plan (SDP)
28
Software Requirements Specification (SRS)1
• Title
• TOC
1. Introduction
1.1
1.2
1.3
1.4
1.5
1
IEEE Std 830-1998
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview
2. Overall Description
2.1
2.2
2.3
2.4
2.5
Product Perspective
Product Functions
User Characteristics
Constraints
Assumptions and Dependencies
3.0 Specific Requirements
… next slide
7/18/2015
29
Software Requirements Specification (SRS)
3.0 Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.6 Software System Quality Attributes
3.7 Object Oriented Models
3.7.1 Analysis Class Model
3.7.2 Analysis Collaboration Model
3.8 Additional Comments
•
Index
•
Appendices
7/18/2015
30
Software Development Plan (SDP)2
• Front Matter (Title, Toc, Lof, Lot)
1. Overview
2
IEEE Std 1058-1998
1.1 Project Summary
1.2 Evolution of Plan
2.
3.
4.
5.
References
Definitions
Project Organization
Managerial Process Plans
5.1
5.2
5.3
5.4
5.5
Start-up Plan
Work Plan
Control Plan
Risk Management Plan
Closeout Plan
6. Technical Process Plan
7. Supporting Plans
7/18/2015
31
Requirements Elicitation vs Elaboration (USP)
Use-case Model
Described using the language of the
customer.
External view of the system.
Analysis Model
Described using the language of the
developer.
Internal view of the system.
Structured by Use cases; gives
structure to external view
Structured by sterotypical classes and
packages; gives structure to internal
view
Used primarily as a contract
Used primarily by developers to
between client and developer as to
understand how the system should be
what the system should do.
shaped; that is, designed and
implemented.
May contain redundancies and
Should be complete, precise,
inconsistencies among requirements consistent, and testable.
Captures functionality of the system Outlines how to realize functionality
including architecturally significant within the system; works as the first
functionality.
cut at design.
Defines use cases further analyzed in Defines Use-case realizations, each
the analysis model.
one representing the analysis of a use
case from the Use Case model.
7/18/2015
32
Design (USP)
•
Purpose
The system is shaped to accommodate all functional and non-functional
requirements. It contributes to a sound and stable architecture and creates a
blueprint for the implementation model.
– Acquire an in-depth understanding of non-functional requirements and
constraints related to: programming languages, component reuse, operating
systems, distribution topology, network and database technologies, user-interface
technology, etc.
– Define and harden the boundaries between subsystems.
•
Artifacts
– Design Model
An object model that describes the physical realization of use cases by focusing on how
functional and non-functional requirements, together with other constraints related
to the implementation environment, impact the system architecture and structure.
• Design classes
• Use-case realizations (design)
• Detailed Interfaces
7/18/2015
33
Design (USP)
•
Artifacts
– Architecture Description
A view of the design model focusing on the following architecturally significant
artifacts:
• Subsystems, interfaces, and their dependencies
• Key classes that trace to key analysis and active classes
• Key use case realizations that are functionally critical and need to be developed early
in the lifecycle. Ones that have coverage across subsystems are particularly
important.
– Deployment Model
An object model that describes the physical distribution of the system in terms of how
functionality is distributed among computational nodes. An essential input to the
activities in design and implementation. It is a manifestation of the mapping
between software architecture and system architecture.
• Nodes that denote computational resources
• Node processes and corresponding functional allocation
• Node relationships and their types (internet, shared memory, ATM link, etc.)
• Network topology(ies)
7/18/2015
34
Analysis vs Design (USP)
Analysis Model
A conceptual model, because it is an
abstraction of the system and avoids
implementation issues.
Design-generic (applicable to several
possible designs).
Based on three stereotyped classes
that are conceptual in nature: Entity,
Boundary, and Control.
Less formal.
A physical model, because it is a
blueprint for implementation.
Less effort to develop (1:5 ratio)
More effort to develop
Few layers
Many layers
Dynamic, but not much focus on
sequence.
Dynamic with much more emphasis
on sequence, concurrency, and
distribution.
Manifests or realizes the design (an
instantiation of the Analysis Model).
Should be maintained throughout the
lifecycle.
Defines the structure of the system
wrt both functional and nonfunctional requirements.
Outlines the design and architecture
of the system.
May not be maintained throughout
the lifecycle.
Defines a structure that is an
essential input to shaping the system
including the Design Model.
7/18/2015
Design Model
Specific for an implementation.
Any number of physical class
stereotypes and modules that may be
implementation language dependent.
More formal.
35
Implementation (USP)
•
Purpose
To translate the design into machine-readable and executable form. Specifically to:
– Plan system integrations required in each implementation increment or iteration
– Distribute the system by mapping executable components to nodes in the
deployment model.
– Implement design classes and subsystems found in the Design Model.
– Unit test the components, and integrate them by compiling and linking them
together into one or more executables, before they are sent to integration and
system tests.
•
Artifacts
– Implementation Model
• Components: <executable>, <file>, <library>, <Dbtable>, <document>
• Interfaces
• Implementation subsystems
–
–
–
–
7/18/2015
Components
Implementation Subsystems
Interfaces
Build Plan
36
Integration & Test (USP)
•
Purpose
To verify the result of each build and to validate the complete system via acceptance
tests.
– Plan tests required in each iteration, including integration and system tests.
Integration tests are required after each build, while system tests are done as part
of client acceptance and system delivery.
– Design and implement test plans by creating test cases. Test cases specify what to
test and define procedures and programs for conducting test exercises.
– Perform various test cases to capture and verify test results. Defects are formally
captured, tracked and removed before delivery.
7/18/2015
37
Integration & Test (USP)
•
Artifacts
– Test Plan
Describes testing strategies, resources, and schedule for each build and for the system.
– Test Model
• Test Case
• Test Component
• Test Procedure
– Test Cases
Designed to verify certain requirements and use cases, or use case scenarios.
Demonstrates that pre- and post-conditions of use cases are satisfied. Predicts or
describes expected component output and behavior.
– Test Components
The implementation artifacts to be tested.
– Test Procedures
Specifies how to perform one or several test cases. Test programs (or "harnesses")(or
"benches") and shell scripts may have to be executed as part of a test procedure.
– Test Evaluations
Capture results of test cases; declares whether or not test case was successful; generates
defect or anomaly reports for tracking.
– Defect or Anomaly Reports
7/18/2015
38
IEEE Std (829) for Software Testing
•
Test Plan
To prescribe the scope, approach, resources, and schedule of testing activities. To
identify items to be tested, the features to be tested, the testing tasks to be
performed, the personnel responsible for each task, and the risks associated with
the plan.
•
•
•
•
•
•
•
Test Design Spec
Test Case Spec
Test Procedure Spec
Test Item Transmittal Report
Test Log
Test Incident Report
Test Summary Report
7/18/2015
39