Prescriptive Process Models

Prescriptive Models
Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions If prescriptive process models strive for structure and order, are they inappropriate for a software world that increases on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

The Waterfall Model

Com m unic a t ion

proje c t init ia t ion re quire m e nt ga t he ring

Planning
es timating sc heduling tra cking

Mode ling
analysis design

Const r uc t ion
code t est

De ploy m e nt
de liv e ry s upport f e e dba c k

The Waterfall Model

The Waterfall Model

Problems:

Sequential flow. Real projects rarely follow the sequential flow that the model proposes. Requirements. It is often difficult for the customer to state all requirements explicitly. It has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. Patience. The customer must have patience. A working version of the programs will not be available until late in the project timespan.

Evolutionary Models: Prototyping

QuQuick ick p lan

Com m unicat ion

plan Modeling Mo d e lin g Quick Qu ick d e sig n design

communication

Deployment Deployment De live r y& delivery & Fe e dback feedback

Construction of of ot ot ype prototype pr

Const r uct ion

10

Evolutionary Models

Prototyping

Customer is not clear about detailed input, output requirements Developer is unsure of a particular aspect of the design Allows better understanding of what is to be built when requirements are fuzzy It can be treated as a standalone process model or within the context of any one of the process models Serves as a mechanism for identifying software requirements.
11

Evolutionary Models: Prototyping

12

Evolutionary Models: Prototyping

13

Evolutionary Models: Prototyping

14

15

Incremental Models

The RAD Model

Team # n
M o d e lin g
business m odeling dat a m odeling process m odeling

C o n s t r u c t io n

Com m unicat ion

Team # 2
Mo d eling
b u si n e ss m o d e l i n g dat a m odeling p ro ce ss m o d e l i n g

com ponent reuse aut om at ic code generat ion t est ing

Planning
Co nst r uct io n

De ploym e nt
int egrat ion deliv ery feedback

Team # 1 Mode ling

business modeling dat a modeling process modeling

co m p o n e n t re u se a u t o m a t i c co d e g e n e ra t i o n t e st i n g

Const r uct ion

component reuse aut omat ic code generat ion t est ing

6 0 - 9 0 days

16

17

18

19

Incremental Models

The RAD Model

Short development cycle High-speed adaptation of the waterfall model Uses a component-based construction approach Uses the generic framework activities Multiple software teams work in parallel on different functions Drawbacks: May not be appropriate if:

System cannot be properly modularized Technical risks are high High performance is an issue

20

21

22

23

Incremental Models

The Incremental Model

increment # n
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign

Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k

increment # 2
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign

deliv ery of nt h increment

Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k

increment # 1
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k

deliv ery of 2nd increment

deliv ery of 1st increment

project calendar t ime

24

25

Incremental Models

The Incremental Model

Waterfall model applied in an iterative manner Delivery of an operational product with each increment Linear sequences in a staggered fashion. Each linear sequence produces deliverable increments of the software (e.g. word processing software)

Increment 1: file management, editing and document production Increment 2: More sophisticated editing and production Increment 3: Spelling and grammar checking Increment 4: Advanced page layout capability

The first increment is the core product

26

27

28

Evolutionary Models: The Spiral

planning
estimation sch eduling risk analysis

communication modeling
analysis design start

deployment
delivery feedback

construction
code test

29

Evolutionary Models

The Spiral

Software is developed in a series of evolutionary releases First circuit around the spiral: product specification The project manager adjusts the number of iterations required to complete the software Circuit 1: Product specification Circuit 2: Prototype Circuit n: More sophisticated versions of the software Each pass through the planning region result in adjustments to the project plan
30

Evolutionary Models

The Spiral

It can be adapted to apply throughout the life of software Iterations around the spiral may be used to represent:

Concept development project Product development Product enhancement

Is a realistic approach to the development of large-scale systems. It is not a solution: it may be difficult to convince customers that the approach is controllable
31

The Spiral

32

The Spiral

33

Evolutionary Models

Concurrent Model
none Modeling act ivit y

Under development

represent s t he st at e of a sof t ware engineering act ivit y or t ask

A wait ing changes

Under review Under revision Baselined

Done

34

Evolutionary Models

Concurrent Model

Also known as concurrent engineering Consist of framework activities, SE actions and tasks, and associated states. The activity can be in one of the states at a time All activities exist concurrently but reside in different states.

Communication activity: awaiting changes state Modeling activity: under development

Appropriate for system engineering projects where different teams are involved
35

Evolutionary Models

Final Comment

A problem to project planning:

uncertain number of cycles required Most project management and estimation techniques are based on linear layouts

Undefined maximum speed:

If evolution is too fast, the process will fall into chaos If evolution is too slow, then productivity could be affected

36

Evolutionary Models

Final Comment

Excessive focus on high quality:

We should prioritize the speed of the development over zero defects Extending the development in order to reach high quality could result in late delivery of the product.

It is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development. The challenge is to establish a proper balance between product parameters and customer satisfaction.
37

Still Other Process Models

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

The Unified Process (UP)

Elab o r at io n

elaboration

inception n Incep t io

inception
co nst r uct io n
Release
soft ware increment

t r ansit io n

p r o d uct io n
39

The Unified Process (UP)

A framework for OO SE using UML Has its roots in the industrial experience within Ericsson Successor methodologies led by Rational and Objectory Status: a widely adopted industrial standard Uses the Unified Modeling Language (UML) Several OOA and OOD methods were proposed during the 80s and early 90s UP combine the best features of each individual method. Rational Corporation developed automated tools to support UML methods
40

The Unified Process (UP)

A modern process model derived from the work on the UML and associated process. Normally described from 3 perspectives

A dynamic perspective that shows phases over time; A static perspective that shows process activities; A proactive perspective that suggests good practice.

41

The Unified Process (UP) - Phases

1.

Inception (feasibility study)

Document a vision of the product Who are the expected users of the system What is the preliminary high-level architecture of the system What is the development plan and what are the development costs? Use cases are specified in detail Software architecture is developed and specified

2.

Elaboration

3.
4. 5.

Construction developing and testing code Transition corresponds to beta testing. Production deployment, monitored use of software
42

UP Phases
UP Phase s
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Wor kflows Requirements Analysis Design

Implementation Test Support Iterations #1 #2 #n-1 #n

43

UP Work Products
Incept ion phase
Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary . One or more prot ot y pes
I nc e pt i o n

Elaborat ion phase

Use-case model Supplement ary requirement s including non-funct ional Analy sis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot y pe. Preliminary design model Rev ised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual

Const ruct ion phase

Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment

Transit ion phase

Deliv ered soft ware increment Bet a t est report s General user feedback

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

Development Phase Techniques

Team creation Scrum believes that a development team should perform as a sport team, every team member working independently but towards the same goal. Scrum suggests that a team has a maximum of 6 - 7 members. The team facilitator is called the Scrum master. His/her job is to implement and manage the Scrum process in the project.

60

Development Phase Techniques

The Scrum team as a whole defines the practices, meetings, artifact and terminology of SCRUM for the team, and the Scrum Master ensures adherence to these "norms" identified. Scrum masters serve a facilitator role and their authority is mostly indirect. Scrum masters focus most of their time in managing outside interference for the Scrum team and solving outside impediments or Blockers that cannot be solved by the Scrum team.
61

Development Phase Techniques

Backlog creation

There are 3 types of backlogs: Product - Acts as a reposititory for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders. Release - Requirements pulled from the product backlog and identified and prioritized for an upcoming release. The release backlog contains more details about the requirement and low level estimate which are usually estimated by the team performing the work 62

Development Phase Techniques

Sprint - At the beginning of each sprint, the team has sprint planning with an end result being a backlog of requirements/sub-requirements that the team anticipates completing at the end of the sprint. By completing, that means fully coded, tested and documented. These are the items that the team will "Burndown" against throughout the duration of the sprint. The sprint backlog breaks the release backlog requirement into manageable chunks that can be accomplished typically in 8 - 16 hrs.
63

Development Phase Techniques

Project segmentation The whole project gets divided into periods of time with a maximum duration of 4 weeks. One period is called a Sprint and every team gets a backlog to execute within the given Sprint.

64

Development Phase Techniques

Scrum meetings During the sprint, the team conducts daily scrum meetings. The meetings are held in the same place at the same time every work day. The meetings dont last for more than 30 minutes. A scrum master is appointed. The scrum master is responsible for asking every team member the following three questions:
65

Development Phase Techniques

What have you done since the last scrum meeting? What has impeded your work? What do you plan on doing between now and the next scrum meeting? Conversation is restricted to the team members answering the above questions. Meetings can be established for immediately after the scrum meeting based on answers to the above questions. The scrum master is responsible for making decisions immediately, if required to remove impediments to progress. The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.

66

Development Phase Techniques

Phases The Scrum development process consists of 5 major activities Review release plans, Distribution, review and adjustment of product standards, Sprint, Sprint review and Closure.

67

Development Phase Techniques

Sprint The Sprint phase is where the software development takes place. A Sprint consists of the following subactivities: Develop, Wrap, Review and Adjust. This phase has no sequence. Sometimes a backlog item must be developed, wrapped and reviewed and sometimes a backlog item must be only reviewed or adjusted. It totally depends on the backlog item

68

Development Phase Techniques

Sprint review Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added. The reviewers consist of project stakeholder, managers, developers and sometimes customers, sales and marketing. The activities, Sprint and Sprint review are repeated until the product is deemed ready for distribution by the project stakeholders. Then the project goes into the closure phase where the product is made ready for release and distribution. 69

Development Phase Techniques

Closure In this stage activities like last debugging, marketing and promotion take place. By finishing this activity the project is closed. Because of the unpredictability of the software development process its not possible to define exactly when this activity will take place and so the project may take shorter or longer than planned. But by using the controls given by Scrum one can make calculations on the duration of the project.

70

71

72

73

74

75

76