software process l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Process PowerPoint Presentation
Download Presentation
Software Process

Loading in 2 Seconds...

play fullscreen
1 / 50

Software Process - PowerPoint PPT Presentation


  • 1495 Views
  • Uploaded on

Software Process Engineering Activities SW Development Process Process Tailoring Process Improvement Tools Life-Cycle vs. Process

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Process' - Sophia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software process
Software Process
  • Engineering Activities
  • SW Development Process
  • Process Tailoring
  • Process Improvement
  • Tools
life cycle vs process
Life-Cycle vs. Process
  • Recall: The evolution of an item is referred to as the item’s life cycle. It is usually conceived as starting with the initial conception of the product to its removal from service.
  • Each of the tasks within a life cycle is accomplished by means of one or more processes. The combination of all relevant processes within the life cycle is called the software life cycle process.
processes
Processes
  • As per IEEE/EIA Standard 12207-1996
    • Primary processes:
      • Acquisition, supply, and development process
    • Supporting processes:
      • Documentation, Config Mgmt, QA, V&V, Joint review, Audits, etc.
    • Institutional processes:
      • Management, Infrastructure, improvement, training
development process
Development Process
  • Do all the engineering activities have to be performed in the linear sequence proposed by previous slide?
  • What are development processes (or process models) about?
    • Try to model in a specific process how to sequence engineering activities in order to develop software.
    • Try to identify the key engineering activities in the development of software and their relationships to one another.
high level process
High Level Process
  • Processes are made of two majors blocks:
    • Transformation activities
    • Control activities
  • Transformation and control blocks may also themselves incorporate micro processes.

Process

Engineering

transformation

activities

Working software

Requirements

Control activities

Analyzing, designing, coding, documenting

Remarks: this high level process does not prescribe how to sequence the activities.

Audit/review, inspection, compiler check, testing, debugging

methodology method vs process model
Methodology/Method vs. Process Model
  • Process Models: key activities and their relationships
  • Methodologies:prescribes how these activities are supposed to be carried out: when, what, who, and precisely how some tasks have to be performed. Methodologies are specific implementations of a process model.
development process models
Development Process Models
  • There are different software development process models that propose different sequences of engineering activities:
    • Waterfall Model
    • Evolutionary
    • Incremental
    • Spiral
    • Rational Unified Process (RUP)*
    • Rapid Application Development (RAD)**
    • Agile Development
      • XP, Scrum, Crystal, Feature Driven, Adaptive
    • Etc.

* result from previous models (unified) ** gave birth to Agile

classifying development process
Classifying Development Process
  • Prescriptive Process Models
    • Waterfall model
    • Incremental & Evolutionary models
    • Spiral model
    • Rational Unified Process (RUP)
  • Agile Methods
    • eXtreme Programming (XP) (method)
    • Scrum
    • Crystal
    • etc.
  • We will have a quick look at waterfall, incremental and spiral to better understand RUP.
  • We will have a closer look at: RUP and XP
lifecycle models
Lifecycle Models
  • Most Primitive: Code-and-Fix ->good for small projects where the solution is obvious
waterfall model

Software

requirements

Analysis

Design

Coding

Testing

Maintenance

Waterfall Model
waterfall model characteristics
Waterfall Model – Characteristics
  • Place considerable emphasis on a careful analysis before the system is actually built.
  • Try to identify and tie down the user’s requirements as early as possible
  • Transition from one activity to the next typically requires:
    • completion of a defined work product
    • formal evaluation and acceptance of the work product
  • Tends to be a document-driven process.
strengths of waterfall
Strengths of Waterfall
  • Encourages periodic review, validation and verification, results in higher performance product, more closely matches the requirements
  • Each phase results in document, helps clarify decisions, provides an audit trail, serves as concrete milestone.
  • Formal transition from phase to phase results in a progressive “setting” of the product; reduces unnecessary changes.
  • Because the above items, this model is appealing to
    • project managers since it provides them a “sense of control”, easy flow to understand;
    • to contractors since often they get paid for document delivery (low risk to make considerable money without building the actual product)
weaknesses of waterfall
Weaknesses of Waterfall
  • inherent assumption: possible to get requirements, design complete and correct on first pass
    • true for some projects
    • for most projects, difficult to correctly state or visualize requirements before system designed or implemented
    • first designs almost always sub-optimal
  • when necessary to revisit completed phases, normally large administrative overhead, inertia
    • reduces “recursive engineering”
    • also reduces ability to make course corrections when early decisions turn out to be inappropriate
  • Does not respect the transformation-control loop of generic process.
revised waterfall model
Revised Waterfall Model

need

Analysing & documenting

Statement of

requirements

Reviewing, auditing

Designing & documenting

Reviewing, auditing

Design Spec

Coding and commenting

code

inspecting, compiler checking, testing, debugging

deploying

Software in operation

maintaining

disposing

Work product

waste bin

modified waterfall characteristics
Modified Waterfall – Characteristics
  • Work product flows down the primary, stepwise path of normal development.
  • The reverse flow represents iterative changes applied to a prior deliverable, the need for which has been only recognized in the next phase or even later.
  • Such iteration implies rework which requires that work from prior phases is to be repeated (not efficient).
waterfall premise 2

Relative cost to fix or change software

throughout the life cycle

200

100

50

20

10

5

2

1

larger projects

smaller projects

Requirements

Design

Code

Development

Test

Acceptance

Test

Operation

Waterfall: Premise 2
waterfall does it work
Waterfall, does it work?
  • For very small projects the waterfall is sometimes adequate.
    • Because it is easy to get all the requirements correct the first time for small and not complex projects.
  • For large production projects, it may also be adequate.
    • Because knowledge acquired during previous similar projects allows us to properly gather and identify all the user and design requirements, and where little new development is required.
  • For large development projects, it is NOT adequate.
    • Because it is almost impossible to properly identify all the user and design requirements; many changes to the product are then required.
waterfall conclusion
Waterfall : Conclusion
  • First formally defined
  • First widely accepted
  • Still the most widely used
  • Simple
  • Flexible : many variants overcome weaknesses (prototyping inside requirements phase, feedback loops allow iteration)
  • Highly refined standards (e.g. 2167A)
waterfall vs life cycle
Waterfall vs Life-Cycle
  • Recall:
    • First formally defined
    • First widely accepted
  • Old Life-Cycle terminology
    • Requirement Analysis
    • Design
    • Implementation
    • Testing
    • Integrating
    • Maintenance
classifying development process22
Classifying Development Process
  • Prescriptive Process Models
    • Waterfall
    • Incremental & Evolutionary models
    • Spiral
    • Rational Unified Process (RUP)
  • Agile Methods
    • eXtreme Programming (XP)
    • Scrum
    • Crystal
    • etc.
  • We will have a quick look at waterfall, incremental and spiral to better understand RUP.
  • We will have a closer look at: RUP and XP
incremental development process model

Increment

Design

Product

Requirements

Coding

Testing

Increment

Design

Coding

Testing

Increment

Design

Coding

Testing

Incremental Development Process Model
revised incremental model
Revised Incremental Model

need

Work product

Designing & documenting

Statement of

requirements

Design Spec

Coding commenting

Design Spec

Source code

Design Spec

Source code

integrating

integration testing

Source code

inspecting, compiler checking, testing, debugging

Integrated source code

incremental characteristics
Incremental Characteristics
  • Same as Waterfall, except
    • Overall product functionality is delivered in small increments.
    • Each increment uses the waterfall.
  • Advantages over Waterfall
    • Improvement over the Waterfall in getting user to better define essential requirements.
      • focused on essential features, therefore reduces the amount of unnecessary functionality;
      • User involved in selecting which features will be implemented in the next increment.
    • May reduce the number of developers.
  • Does it work?
    • Still falls short of providing developers with iterative engineering process.
waterfall vs incremental version
Waterfall vs. Incremental Version

Comparative staffing curves

strict waterfall

Required personnel

incremental

Development timeline

classifying development process27
Classifying Development Process
  • Prescriptive Process Models
    • Waterfall
    • Incremental& Evolutionary models
    • Spiral
    • Rational Unified Process (RUP)
  • Agile Methods
    • eXtreme Programming (XP)
    • Scrum
    • Crystal
    • etc.
  • We will have a quick look at waterfall, incremental and spiral to better understand RUP.
  • We will have a closer look at: RUP and XP
evolutionary model
Evolutionary Model

Work product

need

SOR for build 1

SOR for build 2

SOR for build 3

Design &Spec

Design &Spec

Design &Spec

Source Code

Source Code

Source Code

evolutionary characteristics
Evolutionary Characteristics
  • Model can be used when the requirements cannot or will not be specified.
  • User can experiment with the system to improve the requirements
  • Greater user involvement is required than in the waterfall method.
dangers of evolutionary
Dangers of Evolutionary
  • This model is used as an excuse for hacking or to avoid proper requirements analysis and design, including their documentation even if the requirements are well understood.
    • may be impossible to adequately tune performance once system is complete
  • Use of this model is exploratory in nature and therefore constitutes a high-risk endeavour. Strong management is required.
    • without strong management control, possible to iterate endlessly; difficult to schedule
prototyping
Prototyping
  • This is not a engineering process. It is an engineering activity. Prototyping by itself is insufficient to develop a product to production stage. Consequently to correct this lacuna , the “evolutionary prototype process” was invented. This consists of taking a prototype and making it evolve into the final product. This implies that the prototype will be using the same technology as the final product, therefore taking has much time to build. Consequently it ends up more like an incremental or an iterative development process. So it is not significantly different enough to be worth specially naming the process as “ prototyping”.
  • Prototyping is an engineering activity. A prototype is something that you build and that you will eventually throw away. A prototype does not encompass all the functionality of the final product, nor its robustness, etc. A prototype should be relatively quick and cheap to build so special technology has to be used to that effect (wood instead of steel, scripting language instead of strong typed language, etc.).
  • Prototyping is not always a required engineering activity for product development. It is something use to help define user requirements. Consequently, users should be involved in this activity. It may also be useful to evaluate different design architectures.
  • In regard to software development, this requires the use of high-level languages (e.g. script language), and often developing a quick and dirty GUI, so users can review and provide clarification on the product requirements.
prototyping approaches
Prototyping Approaches
  • Key feature of prototyping is to rapidly develop simple models of the system to either
    • get rapid customer feedback and clarify requirements; or
    • reduce uncertainty about design aspects that are poorly understood; or
    • evaluate the use of specific technologies.
  • Key question in prototyping:
    • What do you prototype first?
prototyping requirements
Prototyping (Requirements)
  • problem
    • customer defines general objectives but is unable to identify detailed input, processing, or output requirements
  • solution:

Gather requirements from customer

Build

prototype

Quick

design

Customer

evaluates

prototype

Refine

prototype

requirements prototyping

Gather requirements from customer

Build

prototype

Quick

design

Customer

evaluates

prototype

Refine

prototype

Requirements Prototyping

Aim: by prototyping and refining the requirements during the analysis stage, we reduce the risk of designing from incorrect or incomplete software requirements.

System

requirements

Software

requirements

Analysis

Design

danger of requirements prototyping
Danger of Requirements Prototyping
  • customer sees “working system” and is not aware that the system
    • is unlikely to be maintainable
    • is almost certainly of low quality

then demands that prototype be “fixed up” and delivered rather than thrown away

  • solutions
    • ensure customer understands reason for prototype and “buys into” process before beginning
    • build prototype using technologies (hardware, OS, programming language, etc.) that make it obviously unsuitable for delivery
prototyping design

Identify critical design criteria

Build

prototype

Quick

design

Review against critical design criteria

Refine

prototype

Prototyping (Design)
  • problem
    • some aspects of the design are poorly understood and are therefore high risk
  • solution:
design prototyping

Identify critical design criteria

Build

prototype

System

requirements

Quick

design

Review critical design criteria

Refine

prototype

Software

requirements

Analysis

Design

Coding

Design Prototyping

Aim: by prototyping and refining the design until it meets the key design criteria, we reduce the risk that we will implement an inadequate or flawed design.

danger of design prototyping
Danger of Design Prototyping
  • in order to get a prototype working quickly, developers make implementation compromises
    • inappropriate programming language, library, algorithms, database, user-interface toolkit, etc.

then forget why compromises were inappropriate and reuse them in actual system design

  • solutions
    • document design compromises as they are made
    • insist on full validation of final design, explicitly guarding against inappropriate carry-over from the prototype
observation
Observation
  • For some applications, a prototype may be sufficient to meet end user’s needs. These applications are characterised by:
    • low technical risk
    • immediate requirement
    • possibility of close user involvement
    • availability of a development environment
      • in which developers can work fast enough to support prototyping
      • but which is small/efficient/robust enough to be suitable for the deployment environment
  • Often can make use of fourth-generation languages (4GL), off-the-shelf components or tuneable application frameworks (e.g., SAP, Peoplesoft)
plan to throw one away
Plan to Throw One Away…

In most projects, the first system built is barely usable. It may be to slow, too big, awkward in use or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved… When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers…

— Fred Brooks, The Mythical Man-Month

boehm s observation 1988
Boehm’s Observation (1988)
  • both the waterfall model and evolutionary prototyping models are aimed at reducing risk
    • waterfall reduces risk of requirements/design thrashing by insisting they are finalized and signed off early
    • evolutionary prototyping model reduces risk of misunderstanding user needs by giving user constant feedback while system evolves
  • relative risks vary by project, change through project life span
  • so, develop a software process model that explicitly recognizes risk as key driver
classifying development process43
Classifying Development Process
  • Prescriptive Process Models
    • Waterfall
    • Incremental& Evolutionary models
    • Spiral
    • Rational Unified Process (RUP)
  • Agile Methods
    • eXtreme Programming (XP)
    • Scrum
    • Crystal
    • etc.
  • We will have a quick look at waterfall, incremental and spiral to better understand RUP.
  • We will have a closer look at: RUP and XP
spiral model

1. Establish next-level objectives, constraints, alternatives

2. Evaluate product and process alternatives, identify and resolve risks

5. Review progress,

confirm commitment to continue

3. Develop, verify next-level product

4. Plan next phases

Spiral Model
starting and stopping
Starting and Stopping
  • start with a hypothesis
    • a particular user need can be met cost-effectively by the development of a software system
  • stop when either
    • system complete and fielded
      • must test hypothesis by determining whether software system actually meets need
    • hypothesis demonstrated to be false
      • system determined to be too expensive, unnecessary; alternative becomes available; etc.
key features
Key features
  • Development of documentation and other work products non-uniform
    • highest risk items addressed first, more heavily documented
  • Includes the waterfall process
  • Incorporates prototyping as a risk-reduction activity
  • Provides an integral framework for rework by allowing previous decisions to be revisited in a principled manner
difficulties
Difficulties
  • Contracting
    • the Spiral model is difficult (but not impossible) to use in a contracting situation, both for the contractor and for the customer
      • difficult to accommodate the required flexibility
      • difficult to contract without specifying deliverables in advance
  • Risk assessment expertise
    • successful use of the model requires the effective identification and resolution of risks, something many managers and developers are poorly trained in
  • Need for further elaboration
    • as defined, the model is quite general and is difficult to effectively apply without significant expertise
classifying development process49
Classifying Development Process
  • Prescriptive Models
    • Waterfall, Incremental, Evolutionary, Spiral, etc.
    • Rational Unified Process (RUP)
  • Agile Methods
    • eXtreme Programming (XP)
    • Scrum, Crystal, Open, etc.
references
References
  • The Project Manager’s Guide to Software Engineering’s Best Practices
    • M.J. Christensen, R.H. Thayer, IEEE, 2001, ISBN 0-7695-1199-6
  • Software Project Management - A Unified Framework
    • Walker Royce, Addison-Wesley, 1998, ISBN 0-201-30958-0
  • Software Engineering - A Practitioner’s Approach
    • fifth edition, Roger S. Pressman, McGraw-Hill, 2001, ISBN 0-07-052182-4