SEC 308 Yazlm Mhendislii

Software Process Models

A Layered Technology
tools
methods process model a quality focus

Software Engineering
2

Definition
0 Process
0 Defines who is doing what, when, and how to reach a certain goal. 0 Forms the basis for management control of software projects.

0 Methods
0 technical how to for building software 0 Broad array of tasks: communication, requirements analysis, design

modeling, program construction, testing, and support

0 Tools
0 Automated support for process and methods

A Process Model
0 A structured set of activities required to develop a

software system 0 Prescribe a set of process elements

0 0 0 0 0 0

Framework activities Software engineering actions Tasks Work products Quality assurance and Change control mechanisms for each project

0 Each process model also prescribes a workflow

Plan-driven and agile processes

0 Plan-driven processes are processes where all of the process

activities are planned in advance and progress is measured against this plan. 0 In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. 0 In practice, most practical processes include elements of both plan-driven and agile approaches. 0 There are no right or wrong software processes
5

A Process Framework
Software Process Process framework Process framework
Modeling activity Software Engineering action: Analysis work tasks: requirements gathering, elaboration, negotiation, specification, validation work products: analysis model and/or requirements spec milestones & deliverables QA checkpoints Software Engineering action: Design work tasks: data design, architectural, interface design, component design work products: design model and/or design specification

Framework activity 1 work tasks work products milestones & deliverables QA checkpoints

Framework activity n

Umbrella Activities

Umbrella Activities

Process Flow

Executes each of the framework activities in sequence, beginning with communication and culminating with deployment

Repeats one or more of the activities before proceeding to the next

Process Flow (cont.)

Executes the activities in a circular manner, each circuit through the five activities leading to a more complete version of the software

Executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software in parallel with construction of another aspect of the software
8

Key Question
0 What actions are appropriate for a framework activity, 0 given the nature of the problem to be solved, 0 the characteristics of the people doing the work, and 0 the stakeholders who are sponsoring the project?

0 Different project demand different task sets

0 Software team chooses the task set based on 0 Problem and project characteristics

0 Characteristics of the project team

9

Example I
0 For a small, relatively simple project, task set for

requirements gathering

1. Make a list of stakeholders for the project 2. Invite all stakeholders to an informal meeting 3. Ask each stakeholder to make a list of features and

functions required 4. Discuss requirements and build a final list 5. Prioritize requirement 6. Note areas of uncertainty

10

Example II
0 For a larger, more complex software project,

Make a list of stakeholders for the project 2. Interview each stakeholder separately to determine overall wants and needs 3. Build a preliminary list of functions and features based on stakeholder input 4. Schedule a series of facilitated application specification meetings 5. Conduct meetings 6. Produce informal user scenarios as part of each meeting 7. Refine user scenarios based on stakeholder feedback 8. Build a revised list of stakeholder requirements 9. Use quality function deployment techniques to prioritize requirements 10. Package requirements so that they can be delivered incrementally 11. Note constraints and restrictions that will be placed on the system 12. Discuss methods for validating the system
1.
11

Build & Fix Model

0 Product is constructed without specifications or any attempt at design 0 Ad-hoc approach and not welldefined 0 Simple two phase model

12

Build & Fix Model - Drawbacks

0 Suitable for small programming exercises of

100 or 200 lines 0 Unsatisfactory for software for any reasonable size 0 Code soon becomes unfixable & not enhanceable 0 No room for structured design 0 Maintenance is practically not possible

13

The Waterfall Model (Classic Life Cycle)

0 Suggests a systematic, sequential approach to software development
0 It reinforces the notion of define before design and

design before code.

0 Works best when

0 Requirements of a problem are reasonably well

understood 0 Well-defined adaptations or enhancements to an existing system must be made 0 Requirements are well-defined and reasonably stable
14

The Waterfall Model

15

V-Model

16

The Waterfall Model - Drawbacks

0 It is difficult to define all requirements at the beginning of a project 0 This model is not suitable for accommodating any change 0 A working version of the system is not seen until

late in the projects life 0 It does not scale up well to large projects. 0 Real projects are rarely sequential.

17

The Incremental Model

0 It combines elements of the waterfall model applied in

an iterative fashion 0 It delivers a series of releases, called increments, that provide progressively more functionality for customer as each increment is delivered 0 When it is used, the first increment is often a core product; basic requirements are addressed, but many supplementary features remain undelivered 0 The core product is used by customer. As a result, a plan is developed for next increment

18

The Incremental Model

19

The Incremental Model

0 This model focuses on the delivery of an operational product with each increment
0 Incremental development is particularly useful

when staffing is unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people, and additional staff can be added to later increments 0 Increments can be planned to manage technical risks 20

The RAD Model

0 RAD (Rapid Application Development) is an incremental SW process model that emphasizes a short development cycle 0 RAD model is a high-speed adaptation of the waterfall model, achieved by using a componentbased construction approach 0 If a business application modularized in a way that enables each major function to be completed in less

than 3 months, it is a candidate for RAD

21

The RAD Model

22

The RAD Model

0 Build a rapid prototype 0 Give it to user for evaluation & obtain feedback 0 Prototype is refined with active participation of users

23

The RAD Model - Drawbacks

0 Not an appropriate model in the absence of user

participation. 0 For large, but scalable projects, RAD requires sufficient human resources to create right number of RAD teams
0 If a system cannot be properly modularized, building
0 Reusable components are required to reduce development 0 Highly specialized & skilled developers are not easily available.

the components necessary or RAD will be problematic

time.

0 RAD may not be appropriate when technical risks are

high

24

Evolutionary Process Models

0 Evolutionary models are iterative

0 They are characterized in a manner that enables SW engineers to develop increasingly more complete versions of the software 0 Example models
0 Prototyping model 0 The Spiral model 0 Concurrent model
25

Evolutionary Models: Prototyping

0 The prototype may be a usable program but is not suitable as the final software product.

0 The code for the prototype is thrown away. However, experience gathered helps in developing the actual system. 0 The development of a prototype might involve extra cost, but overall cost might turnout to be lower than that of an equivalent system developed using the waterfall model.
26

Evolutionary Models: Prototyping

27

Evolutionary Models: Prototyping Drawbacks

0 The customer sees what appears to be a working version of SW, unaware that in the rush to get it working we havent considered overall quality or long-term maintainability 0 The developer often makes implementation compromises in order to get prototype working quickly
28

Evolutionary Models: Spiral

0 Couples the iterative nature of prototyping with the

controlled and systematic aspects of the waterfall model 0 Provides the potential for rapid development of increasingly more complete versions of the software 0 A risk-driven process model generator 0 It has two main distinguishing features 0 Cyclic approach - Incrementally growing a systems degree of definition and implementation while decreasing its degree of risk 0 A set of anchor point milestones - A combination of work products and conditions that are attained along the path of the spiral
29

Evolutionary Models: Spiral

30

Evolutionary Models: Spiral

0 Unlike other process models that end when software is delivered, the spiral model can be

adapted to apply throughout the life of the computer software 0 The circuits around the spiral might represent 0 Concept development project 0 New Product development project 0 Product enhancement project 0 The spiral model demands a direct consideration of technical risks at all stages of the project
31

Evolutionary Models: Spiral Drawbacks

0 Difficult to convince customers that evolutionary approach is controllable 0 Demands considerable risk assessment expertise and relies on this expertise for success 0 If major risks are uncovered and managed, problems will occur

32

Evolutionary Models: Concurrent

0 Sometimes called concurrent engineering 0 Can be represented schematically as a series of framework

activities, software engineering actions and tasks, and their associated states 0 Defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks 0 Defines a network of activities
0 E. g. The modeling activity which existed in none state while initial

communication was completed, now makes a transition into under development state. If customer indicates that changes in requirements must be made, modeling activity moves from under development state into awaiting changes state 33

Evolutionary Models: Concurrent

34

Evolutionary Models: Concurrent

0 Is applicable to all types of software development and provides an accurate picture of the current state of project 0 All activities exist concurrently but reside in

different states 0 Events generated at one point in the process network trigger transitions among the states
35

Other Process Models

0 Component-based developmentthe process to apply

when reuse is a development objective 0 Formal methodsemphasizes the mathematical specification of requirements 0 AOSDprovides a process and methodological approach for defining, specifying, designing, and constructing aspects 0 Unified Processa use-case driven, architecturecentric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)

36

The Unified Process (UP)

0 It is a use-case driven, architecture-centric, iterative and incremental software process 0 UP is an attempt to draw on the best features and characteristics of conventional s/w process models 0 Also implements many of the best principles of agile software development 0 UP is a framework for object-oriented software

engineering using UML (Unified Modeling Language)

37

Phases of The Unified Process

38

Phases of UP - Inception
0 Defines scope of the project 0 Encompasses both customer communication and planning activities 0 Fundamental business requirements are described

through a set of preliminary use-cases

0 A use-case describes a sequence of actions that are

performed by an actor (e.g., a person, a machine, another system) as the actor interacts with the software

0 A rough architecture for the system is also proposed

39

Phases of UP - Elaboration
0 Encompasses customer communication and modeling

activities 0 Refines and expands the preliminary use-cases 0 Expands the architectural representation to include five different views of the software
0 0 0 0 0

The use-case model The analysis model The design model The implementation model The deployment model

0 In some cases, elaboration creates an executable

architectural baseline that represents a first cut executable system

40

Phases of UP - Construction
0 Makes each use-case operational for end-users 0 As components are being implemented, unit tests are designed and executed for each 0 Integration activities (component assembly and integration testing) are conducted 0 Use-cases are used to derive a suite of acceptance tests

41

Phases of UP - Transition
0 Involves many activities like delivering, training,

supporting, and maintaining the product. 0 Software is given to end-users for beta testing 0 The software team creates the necessary support information
0 User manuals 0 Trouble-shooting guides 0 Installation procedures

0 At the conclusion of the transition phase, the software

increment becomes a usable software release

42

Phases of UP - Production
0 Coincides with the deployment activity of the generic process 0 The on-going use of the software is monitored 0 Support for the operating environment (infrastructure) is provided 0 Defect reports and requests for changes are submitted and evaluated

43

Unified Process Work Products

0 Inception
0 Vision document 0 Initial use-case model 0 Analysis model, design model 0 Implementation model, deployment model, test model 0 Delivered software, beta test reports, general user

0 Elaboration

0 Construction

0 Transition
feedback

44

Initial Development & Evolution Cycles

45

Iterations & Workflow of Unified Process

46

Selection of a Process Model

Selection of a model is based on: 0 Requirements 0 Development team 0 Users 0 Project type and associated risk

47

Based On Characteristics Of Requirements

48

Based On Status Of Development Team

49

Based On Users Participation

50

Based On Type Of Project With Associated Risk

51

52

The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck et al

53

What is Agility?
0 Effective (rapid and adaptive) response to change 0 Effective communication among all stakeholders 0 Drawing the customer onto the team 0 Organizing a team so that it is in control of the work performed Yielding 0 Rapid, incremental delivery of software

54

Agility and the Cost of Change

55

An Agile Process
0 Is driven by customer descriptions of what is required (scenarios) 0 Recognizes that plans are short-lived 0 Develops software iteratively with a heavy

emphasis on construction activities 0 Delivers multiple software increments 0 Adapts as changes occur

56

Agility Principles - I
1. Our highest priority is to satisfy the customer through early 2.

3. 4. 5.

6.

and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is facetoface57 conversation.

Agility Principles - II
7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements, and designs emerge from selforganizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 58

Extreme Programming (XP)

0 The most widely used agile process, originally proposed by

Kent Beck 0 XP Planning

0 Begins with the creation of user stories by listening 0 Customer assigns a value to the story. 0 Agile team assesses each story and assigns a cost 0 Stories are grouped to for a deliverable increment 0 A commitment is made on delivery date 0 After the first increment project velocity is used to help

define subsequent delivery dates for other increments

59

Extreme Programming (XP)

0 XP Design 0 Follows the KIS principle 0 Encourage the use of CRC cards 0 For difficult design problems, suggests the creation of spike solutionsa design prototype 0 Encourages refactoringan iterative refinement of the internal program design 0 XP Coding 0 Recommends the construction of a unit test for a story before coding commences 0 Encourages pair programming 0 XP Testing 0 All unit tests are executed daily (whenever code is modified) 0 Acceptance tests are defined by the customer and executed to assess customer visible functionality
60

Extreme Programming (XP)

simple design CRC cards user st ories values accept ance t est crit eria it erat ion plan spike solut ions prot ot ypes

ref act oring pair programming

Release
sof t ware increment project v elocit y comput ed

unit t est cont inuous int egrat ion accept ance t est ing

61

Adaptive Software Development

0 Originally proposed by Jim Highsmith 0 ASD distinguishing features
0 Mission-driven planning 0 Component-based focus 0 Uses time-boxing 0 Explicit consideration of risks

0 Emphasizes collaboration for requirements

gathering 0 Emphasizes learning throughout the process

62

Adaptive Software Development

adapt ive cycle planning
uses mission st at ement project const raint s basic requirement s

Requirement s gat hering JAD mini-specs

t ime-boxed release plan

Release
sof t ware increment adjust ment s f or subsequent cycles

component s implement ed/ t est ed f ocus groups f or f eedback f ormal t echnical reviews post mort ems

63

Dynamic Systems Development Method

0 Promoted by the DSDM Consortium 0 DSDMdistinguishing features
0 Similar in most respects to XP and/or ASD 0 Nine guiding principles
0 Active user involvement is imperative. 0 DSDM teams must be empowered to make decisions.

0 The focus is on frequent delivery of products.

0 Fitness for business purpose is the essential criterion for acceptance of deliverables. 0 Iterative and incremental development is necessary to converge on an accurate business solution. 0 All changes during development are reversible. 0 Requirements are baselined at a high level 0 Testing is integrated throughout the life-cycle.
64

Dynamic Systems Development Method

65

Scrum
0 Originally proposed by Schwaber and Beedle 0 Scrumdistinguishing features
0 Development work is partitioned into packets 0 Testing and documentation are on-going as the product

is constructed 0 Work occurs in sprints and is derived from a backlog of existing requirements 0 Meetings are very short and sometimes conducted without chairs 0 Demos are delivered to the customer with the timebox allocated
66

Scrum

67

Crystal
0 Proposed by Cockburn and Highsmith
0 Crystaldistinguishing features
0 Actually a family of process models that allow

maneuverability based on problem characteristics 0 Face-to-face communication is emphasized 0 Suggests the use of reflection workshops to review the work habits of the team

68

Feature Driven Development

0 Originally proposed by Peter Coad et al 0 FDDdistinguishing features
0 Emphasis is on defining features 0 a feature is a client-valued function that can be

implemented in two weeks or less. 0 Uses a feature template

0 <action> the <result> <by | for | of | to> a(n) <object>

0 A features list is created and plan by feature is

conducted 0 Design and construction merge in FDD

69

Feature Driven Development

70

Agile Modeling
0 Originally proposed by Scott Ambler

0 Suggests a set of agile modeling principles

0 Model with a purpose 0 Use multiple models

0 Travel light
0 Content is more important than representation 0 Know the models and the tools you use to create

them 0 Adapt locally

71

72

73