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@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-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 variationscan 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… • EmphasisonProcess 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 asneeded 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 • Notionofa 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. RUP[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 originalintent. • 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 arepartners 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)