1 / 27

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

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. Presentation Outline. Introduction.

Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related