• Like
SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf

  • 2,019 views
Published

 

Published in Education , Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,019
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
168
Comments
0
Likes
2

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. Leiden Institute of Advanced Computer Science Software development Selecting an appropriate software development approach Prof. Dr. Thomas BäckSystem‘s Development and Project Management - Prof. Dr. Thomas Bäck 1
  • 2. Leiden Institute of Advanced Computer Science DatesFeb. 1 14:45 – 17:30 Introduction, Project DescriptionFeb. 2 13:45 – 16:30 STEP WISE Approach to Project PlanningFeb. 9 13:10 – 15:45 Selecting an Appropriate Software Dev. ApproachFeb. 15 14:45 – 17:30 Activity Planning and Resource AllocationFeb. 16 13:45 – 16:30 Software Effort EstimationFeb. 22 14:45 – 17:30 Risk management, project escalationFeb. 23 13:45 – 16:30 Project monitoring and controlMar. 1 14:45 – 17:00 ExamMar. 2 13:45 – 16:30 Software Quality AssuranceMar. 8 14:45 – 17:30 Managing People; Contract ManagementMar. 9 13:45 – 16:30 VariousMar. 15 14:45 – 17:30 Trade Fair 2
  • 3. Leiden Institute of Advanced Computer Science3. Analyze project characteristics 1. Identify project objectives 0. Select Project 2. Identify project infrastructure 3. Analyze pr. characteristics 4. Identify products and activities Review lower level detail 5. Estimate effort for activity For each activity 6. Identify activity risks 10. Lower level planning 7. Allocate resources 9. Execute plan 8. Review / publicize plan 3
  • 4. Leiden Institute of Advanced Computer ScienceOutcome !   Selection of most appropriate methodologies & technologies !   Impacts on !  Training requirements for development staff !  Types of staff to be recruited !  Development environment (HW & SW) !  System maintenance arrangements !   E.g. SSADM (Structured Systems Analysis and Design Methodology), UK standard. 4
  • 5. Leiden Institute of Advanced Computer ScienceSelection of software developmentapproaches !   In-house development: most of these issues resolved by IT planning and standards !   Software houses: more applicable as different customers have different needs !   Selection of approach governed by: !  Uncertainties of the project !  Properties of application to be buildt 5
  • 6. Leiden Institute of Advanced Computer ScienceAnalyse project characteristics !   Data-oriented or process-oriented ? !   General tool or application specific software to be developed ? !   Particular type for which specific tools have been developed ? !  Concurrent processing ? !  Knowledge based ? !  Heavy use of computer graphics ? !   Safety critical ? !   Nature of HW/SW environment in which system will operate ? 6
  • 7. Leiden Institute of Advanced Computer ScienceTechnical plan (part of the project plan) 1. Introduction and summary constraints •  Character of the system to be developed •  Risks and uncertainties of project •  User requirements concerning implementation 2. Recommended approach •  Selected methodology / process model •  Development methods •  Required software tools •  Target HW/SW environment 3. Implementation •  Required development environment •  Required maintenance environment •  Required training 4. Implications •  Project products and activities •  Financial 7
  • 8. Leiden Institute of Advanced Computer ScienceGeneral approach !   Look at risks and uncertainties, e.g. !  Are requirements well understood ? !  Are technologies to be used well understood ? !   Look at the type of application being built, e.g. !  Information system ? Embedded system ? !  Criticality ? Differences between target and development environment ? !   Client‘s own requirements !  Need to use a particular model 8
  • 9. Leiden Institute of Advanced Computer ScienceSDLC Model: General approach Right Lifecycle Model Wrong Lifecycle Model •  Improve •  Slow, repeated work development speed •  Unnecessary work •  Improve quality •  Frustration •  Improve project tracking and control •  Minimize overhead •  Minimize risk exposure •  Improve client relationship
  • 10. Leiden Institute of Advanced Computer ScienceChoice of process models One-Shot Incremental Evolutionary Agile •  Whole •  Application is •  System is •  Many application is implemented implemented intermediary implemented in steps via a number prototypes in one go •  Each step of versions •  Very frequent •  Also known as delivers a •  Each version user „waterfall“, subset of is „exercised“ interaction „once- functionality by users •  No upfront through“, etc. •  Functions in •  Suggestions specifications the subset are for •  Focus on fully improvement coding implemented, are made •  Small projects i.e., can be only used by client •  Waterfall •  Spiral •  Prototyping •  Extreme •  V-Model •  Staged- •  SCRUM Programming Delivery •  DSDM •  RUP One-Shot Incremental Evolutionary Agile 10
  • 11. Leiden Institute of Advanced Computer Science„Rules of thumb“ IF Uncertainty high •  Evolutionary Approach IF Complexity high AND •  Incremental Approach Uncertainty low IF Complexity low AND Uncertainty •  One-shot Approach low •  Evolutionary Approach or IF Schedule tight •  Incremental Approach
  • 12. Leiden Institute of Advanced Computer ScienceLifecycle ModelsONE-SHOT APPROACHES
  • 13. Leiden Institute of Advanced Computer ScienceOne-shot: The waterfall model Feasibility study User Requirements Analysis System Design Program Design Coding Testing Operation
  • 14. Leiden Institute of Advanced Computer ScienceOne-shot: The waterfall model (cont‘d) Pros Cons •  Imposes structure on •  Limited scope for complex projects flexibility/iterations •  Every stage needs to be •  Full requirements checked and signed off specification at the •  Eliminates midstream beginning changes •  User specifications •  Good when quality •  No tangible product until requirements dominate the end cost and schedule requirements
  • 15. Leiden Institute of Advanced Computer Science One-shot: The V-process model Validation process Feasibility study Review Corrections User requirements User acceptance System design System test Program design Program testingAnother way of looking at Codethe waterfall model
  • 16. Leiden Institute of Advanced Computer ScienceLifecycle ModelsINCREMENTAL APPROACHES
  • 17. Leiden Institute of Advanced Computer ScienceIncremental delivery delivered system design build install evaluate increment 1 first incremental delivery design build install evaluate increment 2 second incremental delivery increment design build install evaluate 3 third incremental delivery 17
  • 18. The incremental plan outline Leiden Institute of Advanced Computer Science Characteristics of Increments !   Some steps will be pre-requisite because of physical dependencies•  Steps ideally 1% to 5% of the total project !   Others may be in any order•  Non-computer steps should be included !   Value to cost ratios may be used•  Ideal if a step takes one !  Fraction V/C where month or less: •  Not more than three •  V is a score 1-10 representing value to months customer (rated by customer)•  Each step should deliver •  C is a score 0-10 representing cost for some benefit to the user developers (rated by developers)•  Some steps will be physically !  Rather crude, but helpful and easy to dependent on others do Step   Value   C ost   Ratio   Rank   Profit  reports   9   1   9   2nd   Online  database   1   9   0.11   5th   Ad  hoc  enquiry   5   5   1   4th   Purchasing  plans   9   4   2.25   3rd   Profit-­‐based  pay  for   9   0   inf   1st   managers  
  • 19. Leiden Institute of Advanced Computer ScienceIncremental delivery Pros Cons •  Feedback from earlier •  Loss of economy of scale stages used in later ones (some costs will be •  Shorter development repeated) thresholds (important •  „Software breakage“ (later when requirements are increments might change likely to change) earlier increments) •  User gets some benefits earlier •  Project may be put aside temporarily •  Reduces „gold- plating“ (features requested but not used)
  • 20. Leiden Institute of Advanced Computer ScienceThe spiral model Spiral Model •  Risk-oriented lifecycle model •  Breaks project into miniprojects •  Start on small scale in the middle •  Explore risks •  Make plan to handle risks •  Commit to approach for next iteration •  Terminates as a waterfall-model would
  • 21. Leiden Institute of Advanced Computer ScienceThe spiral model (cont d) Each Iteration: •  Determine objectives, alternatives, constraints •  Identify and resolve risks •  Evaluate alternatives •  Develop deliverables, verify correctness •  Plan next iteration •  Commit to approach for next iteration •  Each stage of development considers a greater level of detail !   Early iterations are the cheapest !   Can incorporate other lifecycle models as iterations !   See Boehm s A spiral model of software development and enhancement
  • 22. Leiden Institute of Advanced Computer ScienceThe spiral model (cont‘d) Pros Cons •  As costs increase, •  Complicated risks decrease •  Requires •  At least as much conscentious, management control attentive as waterfall management (checkpoints) •  Early indications of insurmountable risks
  • 23. Leiden Institute of Advanced Computer ScienceRational Unified Process Macrocycle Microcycle Image Source: Wikimedia •  Serial in the large •  Iterative in the small •  Delivering incremental releases over time •  Following proven best practices
  • 24. Leiden Institute of Advanced Computer ScienceRUP: Macrocycle Macrocycle Inception Phase Elaboration Construction Transition Phase Phase Phase • Business Case • Analysis of problem • Iterative, incremental • Deployment at • Project Boundaries domain development of customer • Success Criteria • Baseline architecture complete, executable • Add-ons, bug fixes, • Project plan product … • Risk Analysis • Elimination of largest • Remaining • Check, whether • Resource Estimation risks requirements and project goals have • Working plan and acceptance criteria • Global architecture been achieved milestones decisions • Implementation • Evaluation of work; • Executable prototype • Testing process as proof-of-concept • Prototype • Check, whether system improvements • Decision about • Analysis of detailed system requirements, and users are fit for continuation of architecture, risk „going life“ project, based on life- cycle project goals management as decision point for transfer to next phase
  • 25. Leiden Institute of Advanced Computer ScienceRUP: Iterations Iteration: •  Steps within a single phase •  Results in release of a Image Source: Wikimedia subset of total product Microcycle •  Runs through all work steps (with varying weights)
  • 26. Leiden Institute of Advanced Computer ScienceRUP: Roles & Activities Activities: •  Responsibility of a staff member •  Defined Inputs and Outputs •  Can be split up into single steps •  About 30 role models •  Can shift/change over time •  Single staff member can play different roles
  • 27. Leiden Institute of Advanced Computer ScienceBenefits of incremental delivery !   Feedback from early stages used in developing later stages !   Shorter development thresholds !  Important when requirements are likely to change !   User gets some benefits earlier !  May assist cash flow !   Project may be put aside temporarily !  More urgent jobs may emerge !   Reduces gold-plating i.e. features requested but not used 27
  • 28. Leiden Institute of Advanced Computer SciencePossible disadvantages of incrementaldelivery !   Loss of economy of scale !  Some costs will be repeated !   Software breakage !  Later increments might change earlier increments 28
  • 29. Leiden Institute of Advanced Computer ScienceLifecycle ModelsEVOLUTIONARY APPROACHES
  • 30. Leiden Institute of Advanced Computer ScienceMotivation Perceived disadvantages of structure methods •  Large amounts of documentation, largely unread •  Documentation has to be kept up-to-date •  Division into specialist groups and need to follow procedures stifles communication •  Users can be excluded from decision process •  Long lead times to deliver anything The Answer: Evolutionary Methods?
  • 31. Leiden Institute of Advanced Computer ScienceEvolutionary prototyping Refine Design and Complete prototype Initial implement and until concept initial release acceptable: prototpye prototype Iterations An iterative process of creating quickly and •  Very useful when requirements are changing rapidly •  Or when customer is reluctant to commit to a set of inexpensively live and working models to requirements test out requirements and assumptions •  Or when neither you or your customer understands the application area well Sprague and McNurlin •  Or when developers are unsure of optimal architecture/ algorithm to use
  • 32. Leiden Institute of Advanced Computer ScienceEvolutionary prototyping •  Throw-away Types •  Evolutionary •  Human-computer interface What? •  Functionality What is being •  Organizational prototype •  Hardware/software prototype („experimental“) learnt? •  Application prototype („exploratory“) •  Mockups To what extent? •  Simulated Interaction •  Partial working models: Vertical vs. horizontal 32
  • 33. Leiden Institute of Advanced Computer ScienceEvolutionary prototyping Pros Cons •  Learning by doing •  Users may misunderstand •  Improved communication the role of the prototype •  Improved user involvement •  Lack of project control and •  Feedback loop is standards possible established •  Additional expense for •  Reduces the need for building prototype (throw- documentation away) •  Reduces maintenance •  Focus on user-friendly costs interface could be at expense of machine •  Prototype can be used for efficiency producing expected results
  • 34. Leiden Institute of Advanced Computer ScienceDSDM: Dynamic systems development method !   UK-based consortium !   Arguably DSDM can be seen as replacement for SSADM (Structured Systems Analysis and Design Methodology) !   DSDM is more a project management approach than a development approach Nine core principles feasibility business study•  1. Active user involvement agree schedule implement•  2. Teams empowered to make decisions create functional model identify review implementation train functional functional•  3. Frequent delivery of products prototype iteration prototype business users user approval and user•  4. Fitness for business purpose review prototype guidelines•  5. Iterative and incremental delivery•  6. Changes are reversible identify design prototype•  7. Requirements base-lined at a high level agree design/build review design schedule iteration•  8. Testing integrated with development prototype create design prototype•  9. Collaborative and co-operative stakeholder approach 34
  • 35. Leiden Institute of Advanced Computer ScienceDSDM Key indicators•  Visibility of functionality at user interface•  Clear identification of all classes of users•  Not too much complexity•  Not large applications - split into components•  Need for time constraints•  Flexible high-level requirementsTime-Boxing:!   Time-box fixed deadline by which something has to be delivered!   Typically two to six weeks!   MoSCoW priorities !  Must have - essential !  Should have - very important, but system could operate without !  Could have !  Want (won t have) - but probably won t get!
  • 36. Leiden Institute of Advanced Computer Science !"#$%&$()*+,,$-$!"#".$/+)01$234$5167)7+28$()*+,,$9SCRUM !   Also, an agile approach !"#"$%&()*%+,-%.*/0(0+1%2(3455%63,7(31 /+)01$&2,$373$6),+)7;4$)*8,$234$6)2+:7+,$6)*<7473=$:&$;2,7+$,:06"$%&*,$2)$:&$4>73 !   Based on Sprints >*)$:&$%21?$:&$/+)01@2,:)$234$()*40+:$AB3)?$:&$:&)$+3:)28$1:73=$:C6,$2,$:& 6823373=$1:73=?$:&$D278C$/+)01$234$:&$/6)73:$)<7B?$2,$B88$2,$:&$)E07)4$;2,7+$2 3218C$:&$()*40+:$F2+G8*=?$:&$/6)73:$F2+G8*=$234$:&$F0)34*B3$+&2):$HI37;)=?$!JJKL" Rugby term: Close-knit, shoulder-to-shoulder formation Image Source: Stettina.org !""#$%&%()*+,-+./0+12&#3+4&)20$$ 36
  • 37. Leiden Institute of Advanced Computer ScienceSCRUM Sprint: Rugby term: Close-knit, shoulder-to-shoulder formation!   Creating a backlog (product owner) •  Daily Scrum!   Sprint phase –  Brief meeting every day !  Create sprint backlog –  What have you done since the last meeting? –  What will you do between now and the next meeting? !  Work on spring backlog –  Is there anything preventing you from doing what you have planned? •  Demonstration and Evaluation (Sprint finish) –  Functioning software is demonstrated to a larger group –  Basis for an evaluation meeting à start of next sprint
  • 38. Leiden Institute of Advanced Computer ScienceSCRUM Product Product Owner Sprint Backlog SCRUM team SCRUM Master Backlog•  Compiles all •  To-do-list •  Highest •  5-9 people •  Coaches team changes •  Constantly prioritized list •  Self-organized •  Removes•  Prioritizes reprioritized for sprint •  Joint impediments functionalities responsibility •  Constantly•  Voice of the •  No fixed works to customer project roles provide best possible circumstances for the team •  Runs brief meeting with team every day
  • 39. Leiden Institute of Advanced Computer ScienceGrady Booch s concern !   Booch, an OO authority, is concerned that with requirements driven projects: Conceptual integrity sometimes suffers because this is little motivation to deal with scalability, extensibility, portability, or reusability beyond what any vague requirement might imply !   Tendency towards a large number of discrete functions with little common infrastructure? 39
  • 40. Leiden Institute of Advanced Computer SciencePrototyping as evolutionary delivery An iterative process of creating quickly and inexpensively live and working models to test out requirements and assumptions -- Sprague and McNurlin Main types: •  Throw away prototypes •  Evolutionary prototypes What is being prototyped? •  Human-computer interface •  Functionality 40
  • 41. Leiden Institute of Advanced Computer ScienceReasons for prototyping !   Learning by doing !  Useful where requirements are only partially known !   Improved communication !  Users reluctant to read massive documents !  When system is live you get a better feeling for it !   Improved user involvement !  User ideas and requests are quickly implemented 41
  • 42. Leiden Institute of Advanced Computer ScienceReasons for prototyping (cont d) !   Feedback loop is established !  Ensures that the specification is correct !   Reduces the need for documentation !  Debatable? !   Reduces maintenance costs i.e. changes after the application goes live !   Prototype can be used for producing expected results 42
  • 43. Leiden Institute of Advanced Computer ScienceDangers of prototyping !   Users may misunderstand the role of the prototype !   Lack of project control and standards possible !   Additional expense of building prototype !   Focus on user-friendly interface could be at expense of machine efficiency 43
  • 44. Leiden Institute of Advanced Computer ScienceOther ways of categorizing prototyping !   What is being learnt? !  Organizational prototype !  Hardware/software prototype ( experimental ) !  Application prototype ( exploratory ) !   To what extent? !  Mock-ups !  Simulated interaction !  Partial working models: vertical versus horizontal 44
  • 45. Leiden Institute of Advanced Computer ScienceLifecycle ModelsAGILE APPROACHES
  • 46. Leiden Institute of Advanced Computer ScienceAgile methods !   Structured development methods have some perceived disadvantages !  Produce large amounts of documentation which is largely unread !  Documentation has to be kept up to date !  Division into specialist groups and need to follow procedures stifles communication !  Users can be excluded from decision process !  Long lead times to deliver anything, etc. !   The answer? Agile methods? 46
  • 47. Leiden Institute of Advanced Computer ScienceAgile methods Examples •  Extreme Programming
  • 48. Leiden Institute of Advanced Computer ScienceExtreme programming !   Associated with Kent Beck - see Extreme programming explained !   Developed originally on Chrysler C3 payroll (Smalltalk) project !   Agile methods include !  Jim Highsmith s Adaptive Software Development and !  Alistair Cocburn s Chrystal Lite methods 48
  • 49. Leiden Institute of Advanced Computer ScienceExtreme programming Characteristics •  Argues: Disctinction between design and building of software is artificial •  Code to be developed to meet current needs only •  Frequent re-factoring to keep code structured •  Increments of one to three weeks •  Customer can suggest improvement at any point •  Developers work in pairs •  Test cases and expected results devised before software design •  After testing of increment, test cases added to a consolidated set of test case !   Associated with Kent Beck - see Extreme programming explained !  Jim Highsmith s Adaptive Software Development and !  Alistair Cocburn s Chrystal Lite
  • 50. Leiden Institute of Advanced Computer ScienceLifecycle Models Overview Capability Pure Waterfall Spiral RUP, Evolutionary Increments Works with poorly understood Poor Excellent Fair to Excellent Excellent requirements Works with poorly understood Poor Excellent Fair to Excellent Poor to Fair architecture Produces highly reliable system Excellent Excellent Excellent Fair Produces system with large Excellent Excellent Excellent Excellent growth envelope Manages risk Poor Excellent Fair Fair Can be constrained by a Fair Fair Fair Poor predefined schedule Has low overhead Poor Fair Excellent Fair Allows for midcourse corrections Poor Fair Fair Excellent Provides customer with progress Poor Excellent Fair Excellent visibility Provides management with Fair Excellent Fair to Excellent Fair progress visibility Requires little manager or Fair Poor Poor to Fair Poor developer sophistication
  • 51. Leiden Institute of Advanced Computer ScienceLifecycle ModelsA FEW FINAL REMARKS
  • 52. Leiden Institute of Advanced Computer ScienceConstruction vs Installation installation one-shot incremental evolutionary construction one-shot yes yes no incremental yes yes no evolutionary yes yes yes !   One-shot or incremental installation – any construction approach possible !   Evolutionary installation implies evolutionary construction 52
  • 53. Leiden Institute of Advanced Computer ScienceIterative process management Closely related macro-process to waterfall model micro- stop/check- point process Iterate as required macro-process stop/check- micro- point process Iterate as required macro-process stop/check- micro- point process Iterate as required 53
  • 54. Leiden Institute of Advanced Computer Science„Rules of thumb“ IF Uncertainty high •  Evolutionary Approach IF Complexity high AND •  Incremental Approach Uncertainty low IF Complexity low AND Uncertainty •  One-shot Approach low •  Evolutionary Approach or IF Schedule tight •  Incremental Approach Students, be aware of this in student projects !
  • 55. Leiden Institute of Advanced Computer ScienceConclusions 55