1

Process-Driven Software Development: An Approach for the Capstone Sequence

2007 Information Systems Education ConferencePittsburgh, PA

Nov 1-3, 2007

by

Bob Roggio, ProfessorSchool of Computing

University of North Floridabroggio@unf.edu

2

Presentation OutlinePresentation OutlineI. Introduction

1. Product or Process?

II. Methodology Overview

1. Heavy-Weight Methodologies

2. Light-Weight Methodologies

III. Software Methodology Analysis

1. Waterfall

2. Spiral

3. RUP

4. FDD

5. Scrum

6. XP

IV. Conclusion

Introduction

Methodologies

Conclusions

Models for Consideration

3

I. Introduction Team Projects – Complicated process; many constraints

Academic Constraints and Desired Emphases Where housed? College/School of Business, Arts and Sciences;

School of Computing; College of Engineering One semester / two semesters? Team size? Team composition – how determined? (random; self-selection;

combination; instructor-decided? Sponsored projects, instructor-provided/student-suggested projects? How evaluated? Acceptance Testing? Presentations /

Demonstrations? Common feature: does culminate the undergraduate

educational experience. Many very effective ways to obtain desired outcomes

4

Project or Process? If Emphasis on ‘Project:’ Traditionally:

Select a ‘neat’ project (or assigned / sponsored) Team members ‘must’ work together Must capture / model requirements, develop a design

solution (architectural and detailed); implement the solution in code; test, deliver/deploy, and ‘present.’

Design and develop a viable user interface, functional logic, persistent database and appropriate documentation

All worthwhile activities and present considerable value to the student.

5

Projects: Limited, Sustained Value

But Projects: Not likely (in general) to be a marketable application

How much can be done especially in one semester?

Project knowledge is often not persistent / extensible, although the experience is excellent:

Taking a project from cradle to implementation Working with team members; perhaps real customers Employing soft skills in writing and presentations, etc.

Process is often dictated by instructor or Process is often left to the students. No real

discussion of alternatives.

6

Consider ‘Process’ Emphasis Emphasis on ‘Process’

provides learning outcomes that are more persistent Learning ‘Process’ is repeatable

Studying process with myriad variations can be daunting Heavy-weight versus light-weight approaches; Some processes emphasize risk Some processes embrace change Some processes require close customer involvement Some are considered ‘plan-driven’ or ‘documentation-intensive…

Emphasis on Process requires all that a project emphasizes plus students learn alternative ways to effect a project.

Learning ‘process’ can be ‘taken to the bank.’

7

One might say:

Requirements are the ‘whats’ What is it that the application must do? Problem Space

Design is the ‘hows’ How do we design and develop a solution. Solution Space

Process is the ‘whys’ Why did we design and develop the solution the way we did? Decision Space or Rationale Space

8

II. Methodology Overview (1 of 3)

Heavy Weight MethodologyHeavy documentation requirementsPlan-DrivenExacting, prescribed Activities Formal communicationsOften highly structuredBig Bank Approach

9

Methodology Overview (2 of 3)

Light Weight MethodologyEmphasis on people and working software Document artifacts as needed to provide valueHighly iterative; Very responsive to change; risk Design, code, test, verify as needed

Perhaps ‘design by test’; develop ‘by feature.’ Limited traceability

Very close customer communications / availabilityContinuous integration; rapid development.

10

Methodology Overview (3 of 3)

Heavy Weight Notes: Often the methodology of choice for safety- critical, health-critical

systems; government, scientific systems especially those requiring significant traceability, formal documentation, etc.

Light Weight Clearly the industry trend especially in IT and IS systems Can certainly develop and deploy systems sooner still subscribing to

delivering systems ‘on time, within budget, and meets/exceeds users’ requirements.’

Debates range long and loud on maintenance and documentation and lack of formal / rigid procedures

But no ‘one size fits all.’

11

Scrum

FDD

RUP

Spiral

Waterfall

III. Sample Software III. Sample Software MethodologiesMethodologies

XP

HEAVY

LIGHT

12

Waterfall Model Waterfall Model [1][1]

13

Some Waterfall Model Features Process is Good for

Well defined applications; Team familiar with similar applications Requirements not expected to change and can be acquired up front Development environment stable…. Critical for applications requiring formal documentation, testing, communications, …

Process has Shortcomings: Activities nearly sequential (nearly) in nature Does not embrace change Risk often addressed late (often breakage is severe) Applications delivered – big bang

Team may include less experienced team members; fewer roles

14

SpiralSpiral [2][2]

15

Some Spiral Model Features Very similar to Waterfall in many areas. Addresses / Introduces:

Risk per cycle Notion of a cycle or iteration Project can be re-evaluated / killed once per cycle Planning / assessment is iterative Skewed spiral implies amount of effort expended

Still very formal, plan-driven, documentation intensive Still considered a heavy-weight process – but not

quite as heavy.

16

RUPRUP[3[3]]

17

Some RUP Features Humpback whale RUP architectural life-cycle model

Amplitude of model level of effort Major activities divided into Core Disciplines and Supporting Disciplines

Really pushes the iterative concept – much more than Spiral.

Time-boxed iterations; milestone phases; Risk addressed in early iterations.

RUP workflows appear to be prescriptive RUP Workflows have roles, activities, artifacts all defined Considered a lighter heavy-weight Process Often ends up a heavy-weight process, although not its original intent.

The RUP: defined as a use-case driven, architecture-centric, iterative development process.

Claimed that of the ‘lighter’ heavier process models, great attention is going to the UP. (While still largely formal, does embrace change, address risk, iterative, etc.)

18

Agile Methodologies More emphasis on

people, interactions, shorter cycle (executable) deliveries working software over documentation, Heavy customer collaboration; customer availability High team skills needed Team members play multiple roles

A mix of accepted and controversial software engineering practices.

A significant movement toward agile, more flexible methods (no common definition of ‘agile.’)

19

FDD FDD [4][4]

Model Driven; Short iterationsDesign by Feature; Build by Feature

20

Some FDD Features Series of two-week design by feature/build by feature iterations.

Method produces frequent and tangible results.

Focuses on small blocks of (delivered) user-valued functionality.

Still a ‘good bit’ of Planning: does include planning strategies and precision progress tracking. Progress monitored according to serious planning

A ‘heavier’ light-weight process

21

ScrumScrum [5][5]

Built around notion of a Scrum Process – a 30 day mini-cycle

22

Some Scrum Features Product Backlog developed from list of requirements

Product owner prioritizes this backlog

Sprint Backlog is created – a list of product items transferred from the Product Backlog assigned to a ‘sprint’ (a 30-day mini cycle)

Sprint Backlog updated every day via daily scrum meeting Where are we in the sprint? Any problems? Needs?

Every 30 days, a Sprint Review Meeting is held to allow developers to demonstrate their results to product owner

23

Some Scrum Features – A Bit More Perhaps the most popular agile process

Good for small teams that can work independently.

Planning: Only what is necessary and that provides definite value.

Constantly addresses change, risk and uncertainty

More features: Heavy user interaction, availability; Sprint cycles – develop a rhythm in development. Eschew unnecessary documentation; look for value-added activity

24

Extreme Programming (XP) Extreme Programming (XP) [6][6]

25

A Few XP Features Generally considered the most agile of processes.

Twelve principles: See previous slide. simple design, small releases, aggressive testing, collective code

ownership, pair programming, and several more. “Purists” advocate synergy among the twelve

Based on principles of communications, feedback, and simplicity.

Requires / advocates customer face-to-face meetings

Customers are partners in the software development process.

Emphasizes producing releasable software components in a very short timeframe.

26

IV. Conclusions Emphasis on Process rather than Project

Outcome is sustained, repeatable knowledge and experience

Addressing ‘process’ is the ‘why’ of development.

No ‘one size fits all’

(If you should want a copy of these slides, email broggio@unf.edu)

27