The software production process - PowerPoint PPT Presentation

Loading...

PPT – The software production process PowerPoint presentation | free to view - id: 64c48f-NWZiM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The software production process

Description:

The software production process Ch. 7 * CSC 3910 Software Engineering Time: 1:30 to 2:20 Meeting Days: MWF Location: Oxendine 1256 Spring 2011 Textbook: Fundamentals ... – PowerPoint PPT presentation

Number of Views:51
Avg rating:3.0/5.0
Slides: 82
Provided by: Carlo292
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The software production process


1
The software production process
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?

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

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

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

6
CodeFix
  • 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

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"

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?"
9
Process as a "black box"
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

11
Process as a "white box"
12
Advantages
  • Reduce risks by improving visibility
  • Allow project changes as the project progresses
  • based on feedback from the customer

13
The main activities
  • They must be performed independently of the model
  • The model simply affects the flow among activities

14
Feasibility study
  • Why a new project?
  • cost/benefits tradeoffs
  • buy vs make
  • Requires to perform preliminary requirements
    analysis
  • Produces a Feasibility Study Document
  • Definition of the problem
  • Alternative solutions and their expected benefits
  • Required resources, costs, and delivery dates in
    each proposed alternative solution

15
Requirements engineering activities
16
Requirements engineering
  • Involves
  • eliciting
  • understanding
  • analyzing
  • specifying
  • Focus on
  • what qualities are needed, NOT on
  • how to achieve them

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

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

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

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

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

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

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

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

25
Coding and module testing activity
  • Company wide standards often followed for coding
    style
  • Module testing
  • based on black box/white box criteria

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

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

28
Maintenance
  • Requirements errors are main cause of maintenance
    activities
  • Late discovery of requirements errors causes
    increased costs

29
Other software activities
  • Documentation
  • Verification
  • Management
  • They can be considered as parts of any kind of
    software related activity

30
Overview of software process models
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

32
A waterfall model
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)

34
Critical evaluation of the waterfall model
  • sw process subject to discipline, planning, and
    management
  • postpone implementation to after understanding
    objectives
  • linear, rigid, monolithic
  • no feedback
  • no parallelism
  • a single delivery date

35
Waterfall with feedback
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

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"

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

39
Transformation model
  • Guided by formal methods
  • Specifications transformed into implementations
    via transformations
  • Still a theoretical reference model

40
Transformation model
41
Spiral model B. Boehm, 1989
42
A final model assessment(1)
  • Waterfall
  • document driven
  • Transformational
  • specification driven
  • Spiral
  • risk driven

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)

44
Legacy software
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

46
Case study
  • SynchronizeStabilize
  • (The Microsoft Software Process)

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

48
Case study
  • The Open Source Approach

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.)

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

51
Methodologies to organize the process
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

53
DFDs a reminder
54
Analysis of office work
55
Automated portion
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

57
SD
  • A Directed Acyclic Graph (DAG) of functional
    modules
  • (direction of arrow is implicitly downward)

58
Decorated SDs
selection loop data flow
M
X
B
C
A
M
M
1
2
59
Decorated SDs
M1 abstract input M2 transformation M3 abstract
output
60
SD for the "order" DFD
T type of letter Q quantity AE addresses L
letter form A address
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 processessystem specification
    network (SSN)
  • implementation stage

62
  • PSD
  • sequence
  • selection
  • iteration

63
Network stage (SSNs)
Q
P
A
(a) Processes connected by data structure
P'
A'
Q'
(b) Connection by state vector
64
Implementation stage (JSP)
Input and output data structures Correspondence
between nodes
Program structure
65
The resulting program structure
66
Annotated program structure Trivially
translatable into a program
67
Unified Software Development Process(UP)
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)

69
Cycles and phases of a cycle

product

Inception Elaboration Construction
Transition

release


milestone
70
Distribution of workflows over phases
71
Organizing artifactsConfiguration management
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

73
Key CM issues
  • Multiple access to shared repository
  • Handling product families
  • different members of the family comprise
    components which may have different versions

74
Component database

Member 1

A

1

B

C1

Member 2

A

2

Member 3

B

A

3

C2

D

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

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

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

78
Software standards
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

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

81
Issues with standards
  • Freezing premature standards
  • can inhibit acceptance of new ideas
  • Standards proliferation
  • De-facto standards vs. official standards
About PowerShow.com