the software production process
DESCRIPTION
CSC 3910 Software Engineering. Spring 2011. Time: 1:30 to 2:20. Meeting Days: MWF. Location: Oxendine 1256. Textbook: Fundamentals of Software Engineering , Author: Carlo Ghezzi, et al , 2003, Pearson. The software production process. Questions. - PowerPoint PPT PresentationTRANSCRIPT
Ch. 7 1
The software production process
CSC 3910 Software Engineering
Time: 1:30 to 2:20 Meeting Days: MWF Location: Oxendine 1256
Textbook: Fundamentals of Software Engineering, Author: Carlo Ghezzi, et al, 2003, Pearson
Spring 2011
Ch. 7 2
Questions
• What is the life cycle of a software product?
• Why do we need software process models?
• What are the goals of a software process and what makes it different from other industrial processes?
Ch. 7 3
Outline• Traditional answer: "waterfall" lifecycles• Flexible, incremental processes• Case studies
– "synchronize-and-stabilize" (Microsoft)– the "open source" development model
• Organizing the process– software methodologies– the "Unified Process"
• Organizing artifacts: configuration management
• Standards
Ch. 7 4
Life cycle
• The life cycle of a software product– from inception of an idea for a
product through• requirements gathering and analysis• architecture design and specification• coding and testing• delivery and deployment• maintenance and evolution• retirement
Ch. 7 5
Software process model
• Attempt to organize the software life cycle by
• defining activities involved in software production
• order of activities and their relationships
• Goals of a software process– standardization, predictability,
productivity, high product quality, ability to plan time and budget requirements
Ch. 7 6
Code&Fix
The earliest approach • Write code• Fix it to eliminate any errors that
have been detected, to enhance existing functionality, or to add new features
• Source of difficulties and deficiencies– impossible to predict– impossible to manage
Ch. 7 7
Models are needed
• Symptoms of inadequacy: the software crisis– scheduled time and cost exceeded– user expectations not met– poor quality
• The size and economic value of software applications required appropriate "process models"
Ch. 7 8
Process model goals (B. Boehm 1988)
"determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions:
What shall we do next?How long shall we continue to do it?"
Ch. 7 9
Process as a "black box"
Product
Process
Informal Requirements
Ch. 7 10
Problems
• The assumption is that requirements can be fully understood prior to development
• Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
• Unfortunately the assumption almost never holds
Ch. 7 11
Process as a "white box"
Product
Process
Informal Requirements
feedback
Ch. 7 12
Advantages
• Reduce risks by improving visibility• Allow project changes as the
project progresses– based on feedback from the customer
Ch. 7 13
The main activities
• They must be performed independently of the model
• The model simply affects the flow among activities
Ch. 7 14
Feasibility study
• Why a new project?– cost/benefits tradeoffs– buy vs make
• Requires to perform preliminary requirements analysis
• Produces a Feasibility Study Document1. Definition of the problem2. Alternative solutions and their expected
benefits3. Required resources, costs, and delivery dates
in each proposed alternative solution
Ch. 7 15
Requirements engineering activities
Ch. 7 16
Requirements engineering
• Involves – eliciting– understanding– analyzing– specifying
• Focus on– what qualities are needed, NOT on– how to achieve them
Ch. 7 17
What is needed
• Understand interface between the application and the external world
• Understand the application domain• Identify the main stakeholders and
understand expectations– different stakeholders have different
viewpoints– software engineer must integrate and
reconcile them
Ch. 7 18
The requirements specification document (1)• Provides a specification for the
interface between the application and the external world– defines the qualities to be met
• Has its own qualities– understandable, precise, complete,
consistent, unambiguous, easily modifiable
Ch. 7 19
The requirements specification document (2)• Must be analyzed and confirmed
by the stakeholders– may even include version 0 of user
manual
• May be accompanied by the system test plan document
Ch. 7 20
The requirements specification document (3)• As any large document, it must be
modular– "vertical" modularity
• the usual decomposition, which may be hierarchical
– "horizontal" modularity• different viewpoints
• Defines both functional and non functional requirements
Ch. 7 21
A case study railway automation
• Who are the stakeholders?– management of the train company– train drivers and their unions– passengers (customers)– contractors
• Each has different goals
Ch. 7 22
Case studyhow to classify requirements
• Safety requirements– the probability of accidents should be
less than 10-9 per year
• Utility requirements– level of usefulness of the system as
perceived by the various stakeholders
Ch. 7 23
Case studythe produced document
• Introduction: the “mission” of the system
• Architecture: the main structure of the system
• Specific requirements associated with each subsystem– discussion of how the subsystems’
requirements guarantee that the overall goals are indeed achieved
Ch. 7 24
Software architecture and detailed design activity
• The result of this activity is a Design Specification Document
• Usually follows a company standard, which may include a standard notation, such as UML
Ch. 7 25
Coding and module testing activity
• Company wide standards often followed for coding style
• Module testing– based on black box/white box criteria
Ch. 7 26
Integration and system test activity
• These activities may be integrated with coding and module testing
• Integration may be done incrementally through subsystems– top down vs. bottom up
• The last step is system test– may be followed by alpha testing
Ch. 7 27
Delivery, deployment, and maintenance activities
• Delivery– real delivery may be preceded by
beta testing• Deployment
– components allocated on physical architecture
• Maintenance– corrective, adaptive, perfective
Ch. 7 28
Maintenance
• Requirements errors are main cause of maintenance activities
• Late discovery of requirements errors causes increased costs
Ch. 7 29
Other software activities
• Documentation• Verification• Management
They can be considered as parts of any kind of software related activity
Ch. 7 30
Overview of software process models
Ch. 7 31
Waterfall models (1)
• Invented in the late 1950s for large air defense systems, popularized in the 1970s
• They organize activities in a sequential flow
• Exist in many variants, all sharing sequential flow style
Ch. 7 32
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
A waterfall model
Ch. 7 33
Waterfall models (2)• Organizations adopting them
standardize the outputs of the various phases (deliverables)
• May also prescribe methods to follow in each phase– organization of methods in
frameworks often called methodology
• Example: Military Standard (MIL-STD-2167)
Ch. 7 34
Critical evaluation of the waterfall model
+sw process subject to discipline, planning, and management
+postpone implementation to after understanding objectives
– linear, rigid, monolithicno feedbackno parallelisma single delivery date
Ch. 7 35
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
Waterfall with feedback
Ch. 7 36
Problems with waterfall
• Estimates made when limited knowledge available
• Difficult to gather all requirements once and for all– users may not know what they want– requirements cannot be frozen
Ch. 7 37
Evolutionary models• Many variants available• Product development evolves through
increments– "do it twice" (F. Brooks, 1995)– evolutionary prototype
• Evolutionary process model (B. Boehm, 1988)"model whose stages consist of expanding
increments of an operational software product, with the direction of evolution being determined by operational experience"
Ch. 7 38
Incremental delivery
• Identify self-contained functional units that may be delivered to customers
• To get early feedback– According to T. Gilb, 1988:
• Deliver something to the real user• Measure the added value to the user in all
critical dimensions• Adjust design and objectives
Ch. 7 39
Transformation model
• Guided by formal methods• Specifications transformed into
implementations via transformations
• Still a theoretical reference model
Ch. 7 40
Requirements analysis and specification
OptimizationRequirements
Formal specifications
Verification Tuning
Lower level specifications
Recording of developmental history
Reusable components
Decisions & rationale
Transformation model
Ch. 7 41
Spiral modelB. Boehm, 1989
Ch. 7 42
A final model assessment(1)
• Waterfall– document driven
• Transformational– specification driven
• Spiral– risk driven
Ch. 7 43
A final model assessment(2)
• Flexibility needed to reduce risks– misunderstandings in requirements– unacceptable time to market
• Waterfall may be useful as a reference structure for documentation– describes the "rationale" a posteriori
(Parnas and Clements, 1989)
Ch. 7 44
Legacy software
Ch. 7 45
Software evolution• Existing software must evolve because
requirements change• Re-engineering
– process through which an existing system undergoes an alteration, to be reconstituted in a new form
• Reverse engineering– from an existing system to its
documentation, which may not exist, or may be incomplete
– includes program understanding– preventive maintenance
Ch. 7 46
Case study
Synchronize&Stabilize(The Microsoft Software
Process)
Ch. 7 47
The process
• Planning phase– vision of the product, specification,
schedule
• Development – team composed of 2 groups
• developers and testers (continuous testing)
– process prescribes• daily synchronization• product stabilization
Ch. 7 48
Case study
The Open Source Approach
Ch. 7 49
Open source
• Regulates licensed software, specifying its use, copy, modification, and distribution rights
• Business does not derive from selling software, but rather from other, indirect activities (services, accessories, advertisement, etc.)
Ch. 7 50
The process• Highly distributed process
characterized by frequent iterations– wide availability of source code– openness to contributions from a large
community of developers
• Enabling technology– Internet (large scale and fast
collaborations)– repositories with version control and
configuration management
Ch. 7 51
Methodologies to organize the process
Ch. 7 52
SA/SD
• Structured Analysis/Structured Design• 3 major conceptual tools for modeling
– data flow diagrams• functional specifications
– data dictionaries• centralized definitions
– Structured English• to describe transformation of terminal
bubbles
Ch. 7 53
DFDs: a reminder
A file
Adata
transformer
An output deviceAn input
device
Ch. 7 54
Employee_1
Registration
Employee_2
Authorization
Employee_3
Response
Request
Request
Result
Authorized_requests
Employee_4Employee_6
Employee_5
Process ProcessProcess
Order_request
Complete_order
Analysis ofoffice work
Ch. 7 55
Extract order data
Get letter form
Order request
Letter form
Letter forms
Quantity to order
Type of letter
Compose order
Get address
Addresses
Address
Addressee
AddressComplete order
Authorized requests
Automatedportion
Ch. 7 56
From analysis to design
• Use of Structured Diagrams (SDs)• A "method" is provided to
transform DFDs into SDs; tries to– minimize coupling– maximize cohesion
Ch. 7 57
SD
• A Directed Acyclic Graph (DAG) of functional modules (direction of arrow is implicitly downward)
M
MMM 1 32
Ch. 7 58
Decorated SDs
M
MM1 2
A
B
C
selection loopdata flow X
Ch. 7 59
Decorated SDs
M
MMM 1 32
M 1,1 M 1,2
XX Y
Y
X XX
11
M1 abstract inputM2 transformationM3 abstract output
Ch. 7 60
SD for the "order" DFD
Order main
Get data
Produce data for order form
Print order form
T
Q
AE
AE
T
A
L
A
L
Q
T = type of letterQ = quantityAE = addressesL = letter formA = address
Ch. 7 61
JSD and JSP
• Jackson's System Development– modeling stage
• analysis and modeling of the external world– entities– actions (described by process structure diagram)
– network stage• system modeled as a network of
interconnected and communicating processes—system specification network (SSN)
– implementation stage
Ch. 7 62
A
DCB
(a)X
Y*
(c)
H
L M
o o
(b)
PSD(a) sequence(b) selection(c) iteration
Ch. 7 63
(a) Processes connected by data structure
P Q
Q'P'
(b) Connection by state vector
A
A'
Network stage (SSNs)
Ch. 7 64
Implementation stage (JSP)Transfer
order file
Item group
Transfer record
Receipt Delivery
*
*
o o
Output report
Header Body
Net item transfer
*
Input and output data structuresCorrespondence between nodes
Program structure
Ch. 7 65
Program
Generate
headerGenerate
body
Generate *
line by
item group
Process
item
group
Output net
movement
line
Process
record
*
Process
receipt
oProcess
delivery
o
1. open files
2. close files
3. read (item_id, movement)
4. net_item_movement := 0
5. net_movement_item := net_movement_item + movement
6. net_movement_item := net_movement_item - movement
7. write (header)
8. write (net_item_movement_line)
The resulting programstructure
Ch. 7 66
Program
Generate header
Generate body
Generate * line by item group
Process item group
Process record
*
Process receipt
oProcess delivery
o
1, 3, 7 2
4 8
3
5 6
Output net transfer line
(c)
Annotated programstructureTrivially translatableinto a program
Ch. 7 67
Unified Software Development Process
(UP)
Ch. 7 68
Principles
• Development of an OO system• Uses the UML notation throughout
the process• Supports an iterative and
incremental process• Decomposes a large process into
controlled iterations (mini projects)
Ch. 7 69
Cycles and phases of a cycle
time
death
cycle1 ... cycle2 cycle n
product releases
milestone
product release Inception Elaboration Construction Transition
Ch. 7 70
Distribution of workflows over phases
inception elaboration construction transition
Iter1 Iter2 ... ... ... ... ... ... ... ... Iter n
Requirements
Analysis
Design
Implementation
Testing
Ch. 7 71
Organizing artifactsConfiguration management
Ch. 7 72
CM concepts
• Configuration– identifies components and their
versions
• Configuration management– discipline of coordinating software
development and controlling the change and evolution of software products and components
Ch. 7 73
Key CM issues
• Multiple access to shared repository
• Handling product families– different members of the family
comprise components which may have different versions
Ch. 7 74
Member 1
A
B
C1
Member 2
A
B
C2
Member 3
A
D
1
2
3
A
A
B
D
E
A
C C
1
1
2
2
3
Component database
Ch. 7 75
Baseline and private workspaces
• Project baseline– central repository of reviewed and
approved artifacts that represent a given stable point in system development
• Private workspaces– private and intermediate versions of
components
Ch. 7 76
Versions
• Can be refined into– revisions
• new version supersedes the previous• define a linear order
– variants• e.g., alternative implementations of the
same specification for different machines, or access to different I/O devices
Ch. 7 77
Derived versions
• Further logical relations may exist among versions of components
• A component may be derived from another– object code component is a derived
version of a source code component
Ch. 7 78
Software standards
Ch. 7 79
Why standards?
• They are needed to achieve quality in both software products and processes
• They may be imposed internally or externally – e.g., MIL-STD 2167A imposed to
contractors for military applications
• Other examples: ISO series, IEEE
Ch. 7 80
Main benefits
• From the developers' viewpoint– standards enforce a uniform behavior within
an organization– they facilitate communication among people,
stabilizes the production process, and makes it easier to add new people to ongoing projects
• From the customers' viewpoint– they make it easier to assess the progress and
quality of results– they reduce the strict dependency of
customers on specific contractors
Ch. 7 81
Issues with standards
• Freezing premature standards– can inhibit acceptance of new ideas
• Standards proliferation• De-facto standards vs. official
standards