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

1
Process-Driven Software Development An Approach
for the Capstone Sequence
2007 Information Systems Education
Conference Pittsburgh, PA Nov 1-3, 2007
by Bob Roggio, Professor School of
Computing University of North Florida broggio_at_unf.
edu
2
Presentation Outline
Introduction

• Introduction
• 1. Product or Process?
• Methodology Overview
• 1. Heavy-Weight Methodologies
• 2. Light-Weight Methodologies
• III. Software Methodology Analysis
• Waterfall
• Spiral
• RUP
• FDD
• Scrum
• XP
• IV. Conclusion

Methodologies
Models for Consideration
Conclusions
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-su
  ggested 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
Methodology Overview (1 of 3)

• Heavy Weight Methodology
• Heavy documentation requirements
• Plan-Driven
• Exacting, prescribed Activities
• Formal communications
• Often highly structured
• Big Bank Approach

9
Methodology Overview (2 of 3)

• Light Weight Methodology
• Emphasis on people and working software
• Document artifacts as needed to provide value
• Highly 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 / availability
• Continuous 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
III. Sample Software Methodologies
Waterfall
H E A V Y
Spiral
RUP
FDD
L I G H T
Scrum
XP
12
Waterfall Model 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
Spiral 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
RUP3
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 4
Model Driven Short iterations Design 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
Scrum 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) 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_at_unf.edu)

27
(No Transcript)