Software Process Models

  • 110 views
Uploaded on

Lecture notes about picking the right (combination) of software process models.

Lecture notes about picking the right (combination) of software process models.

More in: Software , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
110
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The software production process Projectmanagement or software proces models?
  • 2. Goal • Choose the best process (or combination of processes) for your project.
  • 3. What is Project Management? • Project management encompasses all the activities needed to plan and execute a project: – Deciding what needs to be done – Estimating costs – Ensuring there are suitable people to undertake the project – Defining responsibilities – Scheduling – Making arrangements for the work – Describe and handle risks – continued ...
  • 4. Software Process Models • Software process models are general approaches for organizing a project into activities. – Helps to decide: • What work should be done; • In what sequence to perform the work. – The models should be seen as aids to thinking, not rigid prescriptions of the way to do things. – Each project ends up with its own unique plan.
  • 5. Analysis 2% Specification 5% Module Testing 7% Integration 8% Maintenance 67% Cost of making software? Module Coding 5% Design 6% [Schach]
  • 6. Life cycle • The life cycle of a software product – from inception of an idea for a product through • requirements gathering and analysis • architecture design and specification • coding and testing • delivery and deployment • maintenance and evolution • retirement
  • 7. Software process model • Attempt to organize the software life cycle by • defining activities involved in software production • order of activities and their relationships • Goals of a software process – standardization, predictability, productivity, high product quality, ability to plan time and budget requirements
  • 8. Level 1 – Ad Hoc
  • 9. Code&Fix • The earliest approach • Write code • Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features • Source of difficulties and deficiencies – impossible to predict – impossible to manage • JBF 
  • 10. Models are needed • Symptoms of inadequacy: the software crisis – scheduled time and cost exceeded – user expectations not met – poor quality • The size and economic value of software applications required appropriate "process models"
  • 11. Models are needed
  • 12. Process model goals (B. Boehm 1988) “Determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. …. Thus a process model addresses the following software project questions: – What shall we do next? – How long shall we continue to do it?"
  • 13. Process as a "black box" Product Process Informal Requirements
  • 14. Process as a "white box" Product Process Informal Requirements feedback
  • 15. Overview of software process models
  • 16. Level 2 - Repeatable
  • 17. Waterfall models (1) • Invented in the late 1950s for large air defense systems, popularized in the 1970s • They organize activities in a sequential flow • Exist in many variants, all sharing sequential flow style
  • 18. Waterfall models (2) • Organizations adopting them standardize the outputs of the various phases (deliverables) • May also prescribe methods to follow in each phase – organization of methods in frameworks often called methodology • Example: Military Standard (MIL-STD-2167) “If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer is actually the second version.”
  • 19. Critical evaluation of the waterfall model + software process subject to discipline, planning, and management + postpone implementation to after understanding objectives – linear, rigid, monolithic – no feedback – no parallelism – a single delivery date
  • 20. Problems with waterfall • Estimates made when limited knowledge available • Difficult to gather all requirements once and for all – users may not know what they want – requirements cannot be frozen
  • 21. Waterfall?
  • 22. Example of list of documentation in a waterfall project (DeGrace and Stahl) • Original Problem Statement • Options Analysis Document • Cost-Benefit Analysis Document • Requirements document • Preliminary Program Plan: • Alternatives Analysis Document • Functional Specification Document • Preliminary Design Document • User's Guide • Programmer's Guide • User Test Plan • User Training Plan • Test Plan Outlines • Test Reports • Installation Plan • ….
  • 23. Alternatives – Sashimi
  • 24. Alternatives – Staged Delivery
  • 25. Level 3 - Defined
  • 26. Evolutionary models • Many variants available • Product development evolves through increments – Evolutionary prototyping (McConnell) – Evolutionary process model (B. Boehm, 1988)
  • 27. Spiral Model (Boehm)
  • 28. Incremental development • Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality • User requirements are prioritised and the highest priority requirements are included in early increments • Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve
  • 29. Level 4 - Managed
  • 30. Unified Process • Development of an OO system • Uses the UML notation throughout the process • Supports an iterative and incremental process • Decomposes a large process into controlled iterations (mini projects) • Different flavours available: UP, RUP, AUP, UPEDU, EUP
  • 31. Increment? • Increment refers to the quantifiable outcome of each iteration • Increment has the obvious implication that there should be more of something at the end of an iteration than there was at the start. • Incremental development is a staging and scheduling strategy ‘’in which the various parts of the system are developed at different times or rates, and integrated as they are completed.’’
  • 32. Iteration? • Iteration refers to the cyclic nature of a process in which activities are repeated in a structured manner. • Iterative development is a rework scheduling strategy ‘’in which time is set aside to revise and improve parts of the system.’’
  • 33. RUP Inception Elaboration ConstructionTransition
  • 34. Iteration CYCLE REQUIREMENTS DESIGN DEVELOPMENT TESTING PREPARATION RELEASE OnetoFour Weeks
  • 35. Iterative and incremental Product vs Process: • Incremental fundamentally means add onto. Incremental development helps you improve your process. • Iterative fundamentally means re-do. Iterative development helps you improve your product. In Code: while ( project.isRunning() ) { project.bugsFixed++; project.featuresComplete++; }
  • 36. Distribution of workflows over phases
  • 37. Level 5 - Optimized
  • 38. Remember waterfall?
  • 39. Work together!
  • 40. Agile methodologies • A group of methodologies developed in the 90ties • Addresses changes in industry: SE processes to sluggish for quickly developing business processes • Examples: Evo, Extreme Programming, Feature Driven Development, Scrum, Smart • Common features: – Avoid big upfront design, requirements will change anyway – Only address some priority features at a time – Automate standard routines, in particular build and deployment – Validate results automatically (automated testing) – Design evolves, tool supported refactoring is used
  • 41. Scrum • Focus on softwaredevelopment without defining phases and workproducts, only focus on increments through sprints • “Getting things done” • Roles: – Scrum Master – Product Owner – Teammember • Ceremonies • Especially useful for experienced developers
  • 42. Scrum
  • 43. Agile & UX CYCLE INTERFACEDESIGN VISUALDESIGN DEVELOPMENT BUILD-OUT TWOWEEKS CYCLE INTERFACEDESIGN VISUALDESIGN DEVELOPMENT BUILD-OUT TWOWEEKS USER RESEARCH? USER TESTING? ORIGINAL THOUGHT?
  • 44. Agile & UX CYCLE INTERFACEDESIGN VISUALDESIGN/ BUILD-OUT DEVELOPMENT TWOWEEKS
  • 45. Extreme programming • Approach to development based on the development and delivery of very small increments of functionality • Relies on constant code improvement, user involvement in the development team and pairwise programming
  • 46. Extreme Programming
  • 47. Extreme Programming
  • 48. Smart • Collection of lots of agile best practices – Stand-ups – Iterative and Incremental – Describes workproducts and phases – Planning poker – Smart use cases and smart estimation – On-site customer
  • 49. Selection criteria for lifecycle models
  • 50. Conclusion
  • 51. Resources • http://computerworld.nl/article/11491/wat-is-sdm.html • http://www.infoq.com/news/2010/02/flavors-of-unified-process • http://www.extremeprogramming.org/ • http://www.scrumalliance.org/learn_about_scrum • http://www.accelerateddeliveryplatform.com/SmartIterationCycle. ashx • http://alistair.cockburn.us/Incremental+versus+iterative+developm ent • http://www.slideshare.net/whafro/design-and-ux-in-an-agile- process-presentation • McConnell, S. (1996). Rapid Development, Redmond: Microsoft Press. ISBN 1-55615-900-5