Download Software Process and Requirements Analysis: A University Perspective - Prof. Doug Niehaus and more Study notes Software Engineering in PDF only on Docsity!
EECS 448 1 Dr. Douglas Niehaus © 2009
The Software Process
Chapter 3
EECS 448
Dr. Douglas Niehaus
EECS 448 2 Dr. Douglas Niehaus © 2009
Overview
The term “software process” refers to the way
software is produced by an organization
Different organizations have different processes
All incorporate basic components of software
development
SW life-cycle model, specific methods for
analysis, design and implementation, tools, and
individual roles in building software
Level of effort can vary widely
Documentation: self-documenting code to
extensive volumes describing all aspects
Testing: ½ of budget to relying on customers
Post-delivery: 20 year contract (DoD) to none
(research labs)
Overview
Software process must adapt to the specifics of the
situation
Nature of the application
Individuals involved
Development period available
Client characteristics
Target platform constriants
Unified Process
Currently dominant object-oriented methodology
Collaborative effort of
Rumbaugh: object modelling technique (OMT,
1991) GE research and Development Center
Booch: Booch Method, 1994, Rational, Inc
Jacobson: Objectory Methodology
Called “The Three Amigos”
Yet Another Stupid Programmer Joke
Developed Unified Modelling Language (UML)
Notation for describing an OO SW product
Version 1.0 published in 1997
International standards
EECS 448 5 Dr. Douglas Niehaus © 2009
Unified Process
Initially called Rational Unified Process
Unified Process is not a specific set of steps
Adaptable
Modified to match the specific product
Some features inapplicable to small and medium
projects
Much of it is used for products of all sizes
Iteration and Incrementation within the Object-
oriented paradigm
OO used throughout process: modelling, design,
implementation
EECS 448 6 Dr. Douglas Niehaus © 2009
Unified Process
A model is a set of UML diagrams describing
elements or aspects of the product
UML provide software professionals a common
vocabulary within which to communicate
OO Paradigm is incremental and iterative
Each work-flow consists of a number of steps
Steps of each work-flow are repeated as required
for refinement as more knowledge is gained
Goal is a UML diagram that all parties find
satisfactory
UML diagrams are made more accurate(iteration)
and extended (incrementation)
Unified Process
Unified Process recognises five work-flows
Requirements
Analysis
Design
Implementation
Testing
Proficiency with UP requires considerable study and
experience
Model was developed primarily for large complex
products so application to smaller products requires
experienced-based adaptation
We will make some arbitrary choices for the
project
Requirements Work-Flow
Development process usually begins with a customer
approaching a development organization
Requirements WF concentrates on determining the
client's needs
Clients do not always know what they need
First step of the SWE is to acquire basic
understanding of the application domain
SWE must keep the client informed and demonstrate
to the client that the SW will be cost-effective
Or, development will stop
Business model makes this case
We will assume the semester project is a brilliant
idea with respect to cost-effectiveness
EECS 448 13 Dr. Douglas Niehaus © 2009
Analysis Work-Flow
Acceptance criteria should be complete
Client should be satisfied with a product that
satisfies the criteria
Specifications should avoid terms that are imprecise
Un-testable and non-operational
E.g. suitable, ample, convenient
When noted they must be refined by defining
what is suitable to a situation, what file capacity
is ample, and what response time is convenient
Specifications should be written as if they will be
used in a lawsuit – ideally, in theory
Specifications are essential for both testing and
maintenance
EECS 448 14 Dr. Douglas Niehaus © 2009
Analysis Work-Flow
Under the Unified Process there is no specification
document
Set of UML models is supposed to be sufficient
However, this does not mean that the presentation
of the analysis is without explanation and narration
Narrative helps the reader interpret the UML and
other diagrams
Issues with classical analysis
Ambiguity: some sections could have more than
one valid interpretation
Incompleteness: some vital component may be
missing
Contradictions
Analysis Work-Flow
UML diagrams combined with narrative descriptions
are less likely to contain such ambiguities, omissions,
and contradictions
Still possible, however
Once the client approves the specifications, detailed
planning and estimation begins
Duration and cost of the project
Clients require estimates and schedules with
milestones that can be checked against reality
Assigning personnel to various work-flows
Software management plan presents these issues to
both client and developers
Analysis Work-Flow
Software Product Management Plan (SPMP)
Describes the separate work-flows of product
Shows members involved with each task
Deadlines for each task
Major components of SPMP
Deliverables: what the client will receive
Milestones: when the client receives incrementally
improved versions of the product
Budget: how much is it all going to cost
Time is the biggest component of money
EECS 448 17 Dr. Douglas Niehaus © 2009
Design Work-Flow
Goal of design work-flow is to refine analysis
components until the description of the problem
solution is in a form that can be implemented as
software by programmers
A design shows how a product is going to satisfy
constraints and provide capabilities extracted by the
requirements work-flow and described operationally
by the analysis work-flow
Classical Design Phase
Determine the internal structure of the product
Decompose the product into modules
Independent code with well-defined interfaces
Detailed Design: select algorithms and data
structures for each module
EECS 448 18 Dr. Douglas Niehaus © 2009
Design Work-Flow
Object-Oriented Design Phase
Describe product components as objects, which
are a kind of module
Some code is more easily described as
procedures, so not all designs are purely OO
Strong correspondence among components
extracted during analysis work-flow and objects
designed in design work-flow as both are OO
Design teams should keep a log/diary of design
options and decisions to aid in
Backtracking in case of dead-ends or contradiction
Maintenance and future enhancements
Implementation Work-Flow
Goal of implementation work-flow is to implement the
designed target software product
In the chosen language(s)
Large products may involve several commands or
components implemented in parallel by separate
teams
Subsystems are generally implemented by
individuals or small groups (2-3)
Operational code artifacts
Usually programmers are only given the design
artifacts, as this should provide enough information
for implementation
Rarely shown architectural level design
Implementation Work-Flow
This can be a mistake, however, as analysis and
requirements level information can be helpful in
understanding the goals and context of a design
Mistakes can be at the design level or earlier
These mistakes sometimes are first observed as
difficulties or contradictions in implementation
Obviously, however, the broader view can be too
large and far-removed from the implementation
problem to be helpful
Can be a distraction, certainly
The larger the product, the more likely looking at
only the design is to be necessary
EECS 448 25 Dr. Douglas Niehaus © 2009
Test Work-Flow
Design Artifacts
Every design component should be traceable, i.e.
cross-referenced, to analysis artifact(s)
Major component of testing is determining if each
part of the design is consistent with the
specifications
Also is every part of the specifications reflected in
some part of the design
Design reviews are similar to Analysis/Specification
reviews in that a diverse group consider the issues
However, clients are not usually present
Faults to look for, include: logic, interface,lack of
exception handling, inconsistency with specs
EECS 448 26 Dr. Douglas Niehaus © 2009
Test Work-Flow
Implementation Artifacts
Informal testing by implementer as they are
implemented
Desk Testing
Tested as components after completion
Against defined test cases
Unit Testing by SQA tests the components
methodically
Code review is powerful and successful technique
Programmer guides review off their code
Must include SQA representative
Scary, but always reveals new ideas
Test Work-Flow
How components are integrated influences success
As ready or all at once
Top-down or Bottom-up
Incremental model strongly indicates that
components and capabilities should be integrated as
available and as continuously as possible
Use-case driven development
Thin vs. Thick development model
SQA determines if combined components integrate
and collaborate correctly in service of product
Developers should be trying a lot of this
SQA is official sign-off, not first discovery, as
possible
Test Work-Flow
SQA has primary responsibility to show that a
product satisfies its specifications and all acceptance
criteria
Product Testing
Listed constraints must be satisfied
Functionality must be complete
Robustness of product should be evaluated
Scaling of data sets
Unexpected input
Effects of new product on existing SW
Completeness of source code and documentation
EECS 448 29 Dr. Douglas Niehaus © 2009
Test Work-Flow
Acceptance Testing
Checking satisfaction of client constraints and
capabilities by software delivered to client
Should (must) include client hardware and client
environment
COTS SW
Alpha: versions of complete product provided to
select clients for realistic testing
Testers expect some problems and have
positive view of finding them
Beta: larger set of users, fewer faults expected
Sometimes called Release Candidates (RCx)
Not a substitute for SQA
EECS 448 30 Dr. Douglas Niehaus © 2009
Post-Delivery Maintenance
An integral part of the process for real software
Not feasible for classroom projects as the software
is not used for long enough
Is part of software for many research projects
Must be part of original planning
Design should take future enhancements and
mechanism changes into account
Strong encapsulation a major advantage of OO
Largest part of development monetarily
Currency (existence) of documentation is often
biggest maintenance challenge
Often have tight deadlines, or are crisis driven
Post-Delivery Maintenance
Large turn-over is common
Not the easiest or most fulfilling job
Often stressful
Testing in this context has two major components
Checking correctness of specific changes
Checking that changes have not caused
regression faults
Automation of test cases is key so they can be
used to check wide range of previous behaviour
after all changes
Log of all changes made is VITAL
Often in Comments in source code
Retirement Maintenance
Final stage of the life cycle
Often after many years of service
Reasons
Proposed changes are sometimes so drastic that
starting over at an earlier phase – design,
analysis, even requirements, makes more sense
Cumulative entropy from many years of
maintenance can create module
interdependencies that a new implementation is
required
Lack of documentation increases chance of
regression faults
Hardware replacement may force
reimplementation
EECS 448 37 Dr. Douglas Niehaus © 2009
Inception Phase
Analysis Work-Flow
Collecting information relevant to product design
Consider how requirements imply existence of
certain product components and their properties
Implementation Work-Flow
Sometimes no coding
Often proof-of-concept for assumed
implementation methods to test assumption
validity and product feature feasibility
Test Work-Flow
Review of requirements for correctness and
completeness
EECS 448 38 Dr. Douglas Niehaus © 2009
Inception Phase
Planning is important in every phase
Insufficient information at beginning of inception
phase to plan the whole project
Assertions and constraints can still be
generated
Planning for inception phase itself is important
Documentation at every phase
Inception Phase deliverables
Initial versions of: domain model, business plan,
set of requirements artifacts, tentative set of
analysis artifacts, tentative architecture, list of
risks, set of use cases, elaboration phase plan,
initial version of business case
Inception Phase
Initial business case is overall aim of inception phase
Assessment of whether building the product is a
good idea
Revenue projections, market estimates, initial
cost estimates
For in-house software this can also include an
initial cost-benefit analysis
Many projects are assessed too optimistically at this
phase, but given all the unknowns, excessive
pessimism is also a significant risk
You are often forced to make decisions with
insufficient data
Experience helps develop intuition
Elaboration Phase
Aim of Elaboration Phase is to
Refine requirements
Refine analysis and corresponding architecture
Complete proof-of-concept implementations
“Rapid Prototype” for customer review
Feedback on feature integration, look-an-feel
Guide modification of design for construction
Monitor risks
If greater understanding generally reduces
perceived risk, that is a good sign
Refine business case
Per feature/component as well as for product
as a whole
Produce a Software Project Management Plan
SPMP
EECS 448 41 Dr. Douglas Niehaus © 2009
Elaboration Phase
Deliverables include:
Completed domain model
Completed business model
Completed requirements artifacts
Completed analysis artifacts
Updated architecture
Updated list of risks
Software Project Management Plan (SPMP)
Completed business case
Rapid Prototype may come during or at end of this
phase, but earlier feedback is easier to integrate
EECS 448 42 Dr. Douglas Niehaus © 2009
Construction Phase
Aim of the Construction Phase is produce the first
operational quality version of the software
So-called Beta release
Deliverables include:
Initial User's Manual
All product components (Beta version)
Completed architecture
Updated risk list
SPMP
Updates to business plan, if necessary
Transition Phase
Aim of Transition Phase is to ensure the client's
needs have been met
Phase driven by feedback from beta testing
Faults in software are corrected
Manuals are completed
Deliverables
All product components
Completed documents, including product user and
architecture manuals
Semester Project Phases
As with all class assignments, the semester project in
this class is an approximation of reality for
educational purposes
Compromises and omissions made to
Simplify details to make principles clearer
Simplify implementation to fit within semester
time constraints
Semester project will use Inception, Elaboration, and
Construction phases
No time for Beta-testing and no beta testers
Minimal business plan
Limited to simple cost/benefit debate about
difficulty of implementing some features vs. their
perceived utility
EECS 448 49 Dr. Douglas Niehaus © 2009
Improving Software Process
One major SEI success
Capability Maturity Model (CMM) initiative
Related software process improvement efforts
ISO 9000-series standards
ISO/IEC 15504 international initiative
Involves more than 40 countries
Capability Maturity Models
Related group of strategies for improving process
Regardless of life-cycle model used
Maturity is a measure of how well the process being
used works – a meta-measure
CMMs: software, human management,system
engineering, integrated product development
EECS 448 50 Dr. Douglas Niehaus © 2009
Improving Software Process
Software CMM incorporates both technical and
managerial aspect of process
Assumes
New techniques not enough to improve process
Management must be excellent as well
Improvements will have to be made long-term and
thus incrementally
Five maturity levels defined
ML1: initial level, no sound SWE management, ad
hoc methods, most actions in response to crisis
Many of world SWE groups are at this level
Improving Software Process
ML2: repeatable process level
Basic SW project management practices
Planning and management based on experience
with similar projects
Measures of some kind are taken
Problems identified and addressed
ML3: Defined Level
SW production process “fully” documented
Managerial and technical aspects clearly defined
Reviews used to improve SW quality
CASE tools to support process
Many organizations have reached ML2 and ML
Improving Software Process
ML4: Managed Level
Quality and productivity goals for projects
Compliance continuously measured
Corrective actions taken for deviations
Statistical controls in place
ML5: Optimizing Level
Goal is continuous improvement of process
Statistical quality and process control techniques
Experience from one project used in future
projects to support continuous improvement
To improve, organizations must first understand their
current level and then identify desired new process
EECS 448 53 Dr. Douglas Niehaus © 2009
Improving Software Process
EECS 448 54 Dr. Douglas Niehaus © 2009
Improving Software Process
Long hard process to improve
Advancing a level can take 1.5 3 years
Advancing from ML1 to ML2 can take 3 to 5 years
Often difficult to instill a methodological
approach and mindset
Romance of independent software developer
can be strong
EECS 448 and classes like it are designed to
make students more receptive
Requiring fewer hard lessons to dedicate
themselves to an improving process
A wide range of other improvement initiatives exist
Improving Software Process
Huge amounts of money are involved in large
organizations and so even modest improvements in
the process can reap large rewards
Hughes Aircraft SWE Division estimated savings of
$2 Million in moving from ML2 to ML
Other positive experiences
ML1 to ML3 doubled productivity, returned $7.
for every $1.00 invested in improvement
Company using ISO 9000 and CMM
Errors in effort estimation decreased from 50%
to 15%
Effectiveness of reviews 40% 80%
Project reworking effort 12% 6%
Software Process Difficulties
Many aspects of software development are hard in
their essence
High level of inherent complexity in many products
Need to make some decisions with incomplete
information and improvement them later
Changing nature of many target environments
Imprecision of many clients
Accidental complexity are those aspects added by
current methods, and which can thus, in theory, be
eliminated by improved processes
Complexity, conformity, changeability, invisibility
