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
![Page 1: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/1.jpg)
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
![Page 2: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/2.jpg)
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?
![Page 3: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/3.jpg)
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
![Page 4: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/4.jpg)
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
![Page 5: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/5.jpg)
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
![Page 6: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/6.jpg)
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
![Page 7: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/7.jpg)
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"
![Page 8: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/8.jpg)
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?"
![Page 9: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/9.jpg)
Ch. 7 9
Process as a "black box"
Product
Process
Informal Requirements
![Page 10: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/10.jpg)
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
![Page 11: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/11.jpg)
Ch. 7 11
Process as a "white box"
Product
Process
Informal Requirements
feedback
![Page 12: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/12.jpg)
Ch. 7 12
Advantages
• Reduce risks by improving visibility• Allow project changes as the
project progresses– based on feedback from the customer
![Page 13: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/13.jpg)
Ch. 7 13
The main activities
• They must be performed independently of the model
• The model simply affects the flow among activities
![Page 14: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/14.jpg)
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
![Page 15: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/15.jpg)
Ch. 7 15
Requirements engineering activities
![Page 16: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/16.jpg)
Ch. 7 16
Requirements engineering
• Involves – eliciting– understanding– analyzing– specifying
• Focus on– what qualities are needed, NOT on– how to achieve them
![Page 17: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/17.jpg)
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
![Page 18: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/18.jpg)
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
![Page 19: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/19.jpg)
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
![Page 20: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/20.jpg)
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
![Page 21: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/21.jpg)
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
![Page 22: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/22.jpg)
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
![Page 23: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/23.jpg)
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
![Page 24: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/24.jpg)
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
![Page 25: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/25.jpg)
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
![Page 26: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/26.jpg)
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
![Page 27: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/27.jpg)
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
![Page 28: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/28.jpg)
Ch. 7 28
Maintenance
• Requirements errors are main cause of maintenance activities
• Late discovery of requirements errors causes increased costs
![Page 29: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/29.jpg)
Ch. 7 29
Other software activities
• Documentation• Verification• Management
They can be considered as parts of any kind of software related activity
![Page 30: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/30.jpg)
Ch. 7 30
Overview of software process models
![Page 31: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/31.jpg)
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
![Page 32: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/32.jpg)
Ch. 7 32
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
A waterfall model
![Page 33: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/33.jpg)
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)
![Page 34: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/34.jpg)
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
![Page 35: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/35.jpg)
Ch. 7 35
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
Waterfall with feedback
![Page 36: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/36.jpg)
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
![Page 37: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/37.jpg)
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"
![Page 38: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/38.jpg)
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
![Page 39: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/39.jpg)
Ch. 7 39
Transformation model
• Guided by formal methods• Specifications transformed into
implementations via transformations
• Still a theoretical reference model
![Page 40: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/40.jpg)
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
![Page 41: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/41.jpg)
Ch. 7 41
Spiral modelB. Boehm, 1989
![Page 42: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/42.jpg)
Ch. 7 42
A final model assessment(1)
• Waterfall– document driven
• Transformational– specification driven
• Spiral– risk driven
![Page 43: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/43.jpg)
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)
![Page 44: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/44.jpg)
Ch. 7 44
Legacy software
![Page 45: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/45.jpg)
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
![Page 46: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/46.jpg)
Ch. 7 46
Case study
Synchronize&Stabilize(The Microsoft Software
Process)
![Page 47: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/47.jpg)
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
![Page 48: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/48.jpg)
Ch. 7 48
Case study
The Open Source Approach
![Page 49: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/49.jpg)
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.)
![Page 50: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/50.jpg)
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
![Page 51: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/51.jpg)
Ch. 7 51
Methodologies to organize the process
![Page 52: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/52.jpg)
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
![Page 53: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/53.jpg)
Ch. 7 53
DFDs: a reminder
A file
Adata
transformer
An output deviceAn input
device
![Page 54: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/54.jpg)
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
![Page 55: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/55.jpg)
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
![Page 56: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/56.jpg)
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
![Page 57: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/57.jpg)
Ch. 7 57
SD
• A Directed Acyclic Graph (DAG) of functional modules (direction of arrow is implicitly downward)
M
MMM 1 32
![Page 58: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/58.jpg)
Ch. 7 58
Decorated SDs
M
MM1 2
A
B
C
selection loopdata flow X
![Page 59: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/59.jpg)
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
![Page 60: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/60.jpg)
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
![Page 61: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/61.jpg)
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
![Page 62: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/62.jpg)
Ch. 7 62
A
DCB
(a)X
Y*
(c)
H
L M
o o
(b)
PSD(a) sequence(b) selection(c) iteration
![Page 63: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/63.jpg)
Ch. 7 63
(a) Processes connected by data structure
P Q
Q'P'
(b) Connection by state vector
A
A'
Network stage (SSNs)
![Page 64: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/64.jpg)
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
![Page 65: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/65.jpg)
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
![Page 66: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/66.jpg)
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
![Page 67: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/67.jpg)
Ch. 7 67
Unified Software Development Process
(UP)
![Page 68: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/68.jpg)
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)
![Page 69: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/69.jpg)
Ch. 7 69
Cycles and phases of a cycle
time
death
cycle1 ... cycle2 cycle n
product releases
milestone
product release Inception Elaboration Construction Transition
![Page 70: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/70.jpg)
Ch. 7 70
Distribution of workflows over phases
inception elaboration construction transition
Iter1 Iter2 ... ... ... ... ... ... ... ... Iter n
Requirements
Analysis
Design
Implementation
Testing
![Page 71: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/71.jpg)
Ch. 7 71
Organizing artifactsConfiguration management
![Page 72: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/72.jpg)
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
![Page 73: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/73.jpg)
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
![Page 74: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/74.jpg)
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
![Page 75: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/75.jpg)
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
![Page 76: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/76.jpg)
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
![Page 77: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/77.jpg)
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
![Page 78: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/78.jpg)
Ch. 7 78
Software standards
![Page 79: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/79.jpg)
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
![Page 80: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/80.jpg)
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
![Page 81: The software production process](https://reader030.vdocument.in/reader030/viewer/2022012914/56815031550346895dbe2a80/html5/thumbnails/81.jpg)
Ch. 7 81
Issues with standards
• Freezing premature standards– can inhibit acceptance of new ideas
• Standards proliferation• De-facto standards vs. official
standards