process-driven software development: an approach for the capstone sequence
DESCRIPTION
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 [email protected]. Presentation Outline. Introduction. - PowerPoint PPT PresentationTRANSCRIPT
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 [email protected]
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
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
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.
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.’)
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
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
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 [email protected])