Software Process Models

43
Software Process Models

description

Software Process Models. Development Phase Techniques. Team creation - PowerPoint PPT Presentation

Transcript of Software Process Models

Page 1: Software Process Models

Software Process Models

Page 2: Software Process Models
Page 3: Software Process Models
Page 4: Software Process Models
Page 5: Software Process Models
Page 6: Software Process Models
Page 7: Software Process Models
Page 8: Software Process Models
Page 9: Software Process Models
Page 10: Software Process Models
Page 11: Software Process Models
Page 12: Software Process Models
Page 13: Software Process Models
Page 14: Software Process Models
Page 15: Software Process Models

15

Page 16: Software Process Models

Development Phase Techniques

O 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. 16

Page 17: Software Process Models

Development Phase Techniques

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

O Scrum masters serve a facilitator role and their authority is mostly indirect.

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

17

Page 18: Software Process Models

Development Phase Techniques

OBacklog creationThere are 3 types of backlogs:O Product - Acts as a repository for requirements

targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders.

O 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

18

Page 19: Software Process Models

Development Phase Techniques

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

19

Page 20: Software Process Models

Development Phase Techniques

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

20

Page 21: Software Process Models

Development Phase Techniques

Scrum meetingsO During the sprint, the team conducts daily scrum

meetings.O The meetings are held in the same place at the

same time every work day.O The meetings don’t last for more than 30

minutes.A scrum master is appointed.

O The scrum master is responsible for asking every team member the following three questions:

21

Page 22: Software Process Models

Development Phase Techniques

O What have you done since the last scrum meeting?O What has impeded your work?O What do you plan on doing between now and the

next scrum meeting?O Conversation is restricted to the team members answering

the above questions.O 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.

O The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.

22

Page 23: Software Process Models

Development Phase Techniques

O 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”.

23

Page 24: Software Process Models

Development Phase Techniques

O Sprint The Sprint phase is where the software

development takes place. A Sprint consists of the following sub-activities: 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

24

Page 25: Software Process Models

Development Phase Techniques

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

25

Page 26: Software Process Models

Development Phase Techniques

O 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 it’s 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.

26

Page 27: Software Process Models
Page 28: Software Process Models
Page 29: Software Process Models
Page 30: Software Process Models
Page 31: Software Process Models
Page 32: Software Process Models
Page 33: Software Process Models

The Unified Process (UP)

33

inception

software incrementRelease

Inception

Elaboration

construction

transition

production

Page 34: Software Process Models

The Unified Process (UP)O A framework for OO SE using UMLO Has its roots in the industrial experience within

Ericsson O Successor methodologies led by Rational and

ObjectoryO Status: a widely adopted industrial standardO Uses the Unified Modeling Language

(UML)O Several OOA and OOD methods were proposed

during the 80’s and early 90’sO UP combine the best features of each individual

method.O Rational Corporation developed automated

tools to support UML methods.

34

Page 35: Software Process Models

The Unified Process (UP) - Phases

1. Inception (feasibility study) O Document a vision of the productO Who are the expected users of the systemO What is the preliminary high-level architecture of the

systemO What is the development plan and what are the

development costs?2. Elaboration

O Use cases are specified in detailO Software architecture is developed and specified

3. Construction – developing and testing code4. Transition – corresponds to beta testing.5. Production – deployment, monitored use of software

35

Page 36: Software Process Models

UP Phases

36

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

Page 37: Software Process Models

UP Work Products

37

Inception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installation manuals descript ion of current increment

Delivered software increment Beta test reports General user feedback

Page 38: Software Process Models

Personal Software Process (PSP)

O The Personal Software Process (PSP) is a structured software development process that is intended to help software engineers understand and improve their performance, by using a "disciplined, data-driven procedure"

Page 39: Software Process Models

Personal Software Process (PSP)

The PSP aims to provide software engineers with disciplined methods for improving personal software development processes. The PSP helps software engineers to:

O Improve their estimating and planning skills.

O Make commitments they can keep.

O Manage the quality of their projects.

O Reduce the number of defects in their work.

The goal of the PSP is to help developers produce zero-defect, quality products on schedule. Low-defect and zero defect products have become the reality for some developers and TSP teams, such as the Motorola division in Florida that achieved zero defects in over 18 projects through implementing PSP techniques.

Page 40: Software Process Models

Personal Software Process (PSP)

Recommends five framework activities:O PlanningO High-level designO High-level design reviewO DevelopmentO Postmortem

Stresses the need for each software engineer to identify errors early and as important, to understand the types of errors

40

Page 41: Software Process Models

Team Software Process (TSP)

O In combination with the Personal Software Process (PSP), the Team

Software Process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software products that range in size of sizes beyond from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code.

O The TSP is intended to improve the levels of quality and productivity of a team's software development project, in order to help them better meet the cost and schedule commitments of developing a software system.

Page 42: Software Process Models

Team Software Process (TSP)O Each project is “launched” using a “script”

that defines the tasks to be accomplishedO Teams are self-directedO Measurement is encouragedO Measures are analyzed with the intent of

improving the team process

42

Page 43: Software Process Models

The Primary Goal of Any Software Process: High Quality

43

Remember:

High quality = project timeliness

Why?

Less rework!