CS 451 Software Engineering Winter Term Yuanfang Cai Room 104, - - PowerPoint PPT Presentation

Drexel University

1

CS 451 Software Engineering Winter Term

Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu

Drexel University

PROCESS MODEL

 A structured collection of practices  Describe characteristics of effective process  CMMI is not a process  CMMI describes the characteristics of effective

processes

2

Drexel University

Prescriptive Models

3

Drexel University

PRESCRIPTIVE MODELS

 Regardless of the model, all models contain the following

components:

 communication  planning  modeling  construction  deployment  Which of these phases do you think is most difficult and

in what situations?

4

Drexel University

PROCESS MODELS

 What do you think the most popular process

model is?

 Waterfall  Incremental  Evolutionary  Formal

5

Drexel University

PROCESS MODELS – WATERFALL

 The “Classic Life Cycle”, The “Textbook Cycle”  A systematic, sequential approach with the following

steps:

 Customer Specification of Requirements (Communication)  Planning (Estimating, Scheduling, Tracking)  Modeling (Analysis and Design)  Construction (Code and Test)  Deployment (Delivery, Support, and Feedback)

6

Drexel University

PROCESS MODELS – WATERFALL

 The book calls the first phase communication. I do not

like this definition as communication must occur at all stages.

7

Drexel University

PROCESS MODELS – WATERFALL

 When is the waterfall process model appropriate?  In a purest sense, probably never. I have never worked

• n a project that follows a completely linear progression.

 However, the waterfall process is appropriate if followed

in spirit if not the letter of the model in some situations:

 Well defined projects  Projects with no technology risks  Well defined domains  Stable requirements

8

Drexel University

PROCESS MODELS – WATERFALL

 Why is it difficult to follow?

 Hard to follow a strictly sequential path.  Customers have difficulty stating ALL the requirements

explicitly

 Customers business model changes during the course

• f developing the application

 Customers are required to have patience, since a

working program is not available until very late in the process.

9

Drexel University

PROCESS MODELS – INCREMENTAL PROCESS MODEL

 Even with well defined projects, a linear approach is

• ften difficult.

 Additionally, sometimes a portion of the software needs

to be delivered early.

 The incremental model combines elements of the

waterfall model applied in an iterative fashion.

 Incremental model delivers an operational product with

each increment.

 Works well for project resource management (staffing).

10

Drexel University

PROCESS MODELS – INCREMENTAL PROCESS MODEL

11

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL - PROTOTYPING

 Customers define general objectives, but does

not identify the details.

 Often, the customer doesn’t know what they

want the system to look like.

 A repeating cycle of the following steps include:

 Communication  Quick Plan  Modeling Quick Design  Construction of Prototype  Deployment & Feedback

12

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL - PROTOTYPING

 Depending upon the complexity I recommend a first pass

with “Paper Prototypes”.

 “Paper” can be virtual with mockups of the application

being developed in either a development environment like Visual Studio or even HTML.

 Second pass could be a semi functional application with

no data connectivity.

13

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL - PROTOTYPING

 Third pass for the developers to try any unknown

technical issues.

 Often good for these prototypes to be used for

requirements gathering and to reduce technology risks. Best if the prototype is a throw-away. One good reason to develop your prototype in a different language/system than the final project

14

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL - PROTOTYPING

 Drawbacks:

 Customers like the prototype and want to place it in

production.

 Developers forget the design decisions and their

mistakes leak into the production system.

15

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL – SPRIAL MODEL

 An evolutionary software model that couples the

iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.

 This is true, but with one addition: risk analysis.  At each cycle through the spiral, milestones are

achieved and risk is reevaluated.

16

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL – SPRIAL MODEL

17

Drexel University

PROCESS MODELS – EVOLUTIONARY PROCESS MODEL – SPRIAL MODEL

 Most developers lean towards evolutionary process

models.

 They have inherent problems:

 Prototyping and similar evolutionary models are hard to plan,

thus hard to estimate, thus hard to contract. How many cycles will there be?

 Speed of evolution is difficult to dictate

 Is the third statement true? Why is this a goal?

18

Drexel University

PROCESS MODELS – SPECIALIZED PROCESS MODEL FORMAL METHODS MODEL

 The Formal Methods Model encompasses a set of

activities that leads to formal mathematical specification

• f computer software.

 In theory, the following is reduced when using formal

methods:

 Ambiguity  Incompleteness  Inconsistency

 Do you agree?

19

Drexel University

PROCESS MODELS – SPECIALIZED PROCESS MODEL FORMAL METHODS MODEL

 Drawbacks:

 The development of formal models is currently quite time

consuming and expensive

 Few software developers have the background, thus extensive

training is required. (is training viable? COBOL -> OOP)

 Difficult to use formal model to communicate with a non-

technical customer.

 Forest and Trees.

 Useful for safety critical application or anywhere failure is

highly costly.

20

Drexel University

Agile Development

21

Drexel University

Manifesto

 Value individuals and interactions over

processes and tools

 Value working software over comprehensive

documentation

 Value customer collaboration over contract

negotiation

 Value responding to changes over following a

plan

22

Drexel University

AGILE ≠ HACK OUT SOLUTONS!

 A process is required  Discipline is essential  12 principles

23

Drexel University

Agile Principles

1.

Our highest priority is to satisfy the customer through early and continues delivery of valuable software.

2.

Welcome changing requirements, even late in

• development. Agile processes harness change

for the customer’s competitive advantage.

3.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

24

Drexel University

Agile Principles

4.

Business people and developers must work together daily throughout the project.

5.

Build projects around motivated individuals. Given them the environment and support they need, and trust them to get the job done.

6.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7.

Working software is the primary measure of progress.

25

Drexel University

Agile Principles

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 self-organizing teams

26

Drexel University

Agile Principles

• 12. At regular intervals, the team reflects on how to

become more effective, then tunes and adjusts its behavior accordingly.

27

Drexel University

AGILE PROCESS MODELS

 Each has a set of “ideas” that represent a

significant departure from conventional software engineering.

 Are the agility ideas really new?

28

Drexel University

Agile Process Models

 Agile Unified Process (AUP)  Dynamic Systems Development

Method (DSDM)

 Essential Unified Process (EssUP)  Extreme Programming (XP)  Feature Driven Development (FDD)  Open Unified Process (OpenUP)  Scrum  Velocity tracking

29

Drexel University

EXTREME PROGRAMMING

 Planning

 User stories

 Values  Acceptance test criteria

 Iteration plan

 Design

 Simple design

 CRC cards

 Spike solutions

 prototypes

30

Drexel University

EXTREME PROGRAMMING

 Coding

 Pair programming  Refactoring

 Test

 Unit test

 Continuous integration

 Acceptance testing

 Release

 Software increment

31

Drexel University

32

EXTREME PROGRAMMING

Drexel University

33

EXTREME PROGRAMMING

Drexel University

34

EXTREME PROGRAMMING

Drexel University

35

EXTREME PROGRAMMING

Drexel University

Summary

 Prescriptive Models

 Waterfall  Incremental  Evolutionary  Agile

36