1 / 78

Altran CIS O bject- O riented A nalysis and D esign

Trainers: Pierre LE FEVERE DE TEN HOVE Richard WALKER. Altran CIS O bject- O riented A nalysis and D esign. Session 1 – Introduction Software Development Processes. Objectives and Agenda. Objectives Overview of the software development evolution

dalit
Download Presentation

Altran CIS O bject- O riented A nalysis and D esign

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. Trainers: Pierre LE FEVERE DE TEN HOVE Richard WALKER Altran CISObject-Oriented Analysis and Design Session 1 – Introduction Software Development Processes OOAD Training

  2. Objectives and Agenda Objectives Overview of the software development evolution Detailed presentation of the Unified Process Agenda Software development evolution Facts Conventional development Iterative development Agile Unified Process Introduction Rational Unified Process Phases and Iterations Risk Management Course structure (Kick off inception phase)

  3. Software engineering evolutionWhy? OOAD Training

  4. Impaired: 24% Successful: 32% Challenged: 44% Software development evolutionFACTS Standish Group International • Analyse the application development projects in government and commercial organisations (no vendors, no suppliers, no consultants) • Analysis of over 50,000 IT projects in 12 years Current situation (2009) • US annual expenditure for software development: $255 Billions • Successful:on budget, on time, with all requirements fulfilled • Challenged:over budget, delayed, with fewer requirements fulfilled • Impaired: cancelled in development or finished but not used OOAD Training

  5. Software development evolutionFACTS Reasons of success (from 2006 report) OOAD Training

  6. Software development evolutionFACTS Reasons of failure (from 2006 report) ~ 50% due to requirements OOAD Training

  7. Requirements: 56 % Other: 10% Code: 7% Design: 27% Software development evolutionFACTS Distribution of defects in the Software engineering lifecycle OOAD Training

  8. Software development evolutionFACTS • Average percentage ofcost overrun • Average percentage oftime overrun Evolution since 1994 • Successful: on budget, on time, with all requirements fulfilled • Challenged: over budget, delayed, with fewer requirements fulfilled • Impaired: cancelled development or finished but not used • Reasons of improvement: • Better project management • Iterative development • Emerging Web infrastructure OOAD Training

  9. Software development evolutionFACTS • Most popular programming language by TIOBE index October 2009 • Ratings based on world-wide availability of skilled engineers, courses and third party vendors (using Google, MSN and Yahoo! search engines) OOAD Training

  10. Software development evolutionConventional Development • Winston W. Royce (1970) • Big design up-front • Coding = little fraction of the overall process (<15%) OOAD Training

  11. Software development evolutionV-Model Requirements Acceptance tests prepare   validate Analysis System tests Design Integration tests Coding Unit tests OOAD Training Project time line

  12. Software development evolutionV-Model – Test categories Unit Testing Make sure all tests are fully automatic and that they check there own results A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs Run your tests frequently. Every test at least everyday When you get a bug report, start by writing a unit test that exposes the bug It is better to write and run incomplete tests than not to run tests Integration Testing To ensure that all parts developed separately fit together Interfaces System Testing The system as a whole Features Developer focused Acceptance Testing The system as a whole also Requirements Customer focused Non-regression Testing Before migration to operation, verify that previously delivered software still works OOAD Training 12

  13. Software development evolutionConventional Development Advantages • Easy to understand • Big effort up front minimizes risk of discovering problems later • Emphasis on documentation => easier take over for a new member • Possibility to manage independant & specialised teams Issues • Plan & estimate too much in advance is difficult • Impossible to go back • No continuous process improvement (during the project) • No intermediate validation => late risk resolution • No requirements rework nor customer feedback • Close to change  Great when requirements are stable OOAD Training

  14. 100% Development progress (% coded) Time Original target date Production Project Start Integration Software development evolutionConventional Development OOAD Training

  15. Software development evolutionConventional Development Risk curve Risk Waterfall process Requirements Analysis Design Coding Testing Time OOAD Training

  16. Software development evolutionIterative development Evolutions • Requirements are more and more complex • System and technologies complexity increasing • Business is evolving faster Consequences • Requirements are never frozen and may evolve during the project • Change is inevitable • Changes to the makeup of the project team or in stakeholders • Changes in the technology being used • Changes to any external systems with which the new software must interact • More and more interfaces between systems have to be defined OOAD Training

  17. Software development evolutionIterative Development Need of an "evolutionary" model • Open to change • Progressive resolution of risks • Architecture centric • Continuous integration Iterative models: • Iterative (repetitions on the V-model) • Incremental • Assess highest risks in first iterations • Requirements driven: • Req. are elements of planning • Customer is regularly involved • Multi-views architecture OOAD Training

  18. Risk Waterfall development Time Software development evolutionIterative Development Risk curve Iterative development OOAD Training

  19. Objectives and Agenda Objectives Overview of the software development evolution Detailed presentation of the Unified Process Agenda Software development evolution Facts Conventional development Iterative development Agile Unified Process Introduction Rational Unified Process Phases and Iterations Risk Management Course structure

  20. Agile Agile is a philosophy: “Agile is an iterative software development style centered on the stakeholders and focusing on customer satisfaction through a continuous software integration.” Agile principles from the Manifesto (http://agilemanifesto.org/) • Customer satisfaction first • All change requests are welcomed • Frequent software delivery (in weeks rather than in months) • Business and software engineers working together • Working software is the primary measure of progress • Technical excellence and good design • and six others ... OOAD Training

  21. Agile A matter of tipping the balance on the good side… OOAD Training

  22. Agile A question of commitment… "Pigs" and "chickens" are the two types of roles in the Scrum method ... or a question of fun? OOAD Training

  23. Agile Scrum (www.controlchaos.com) • By Ken Schwaber (inspired by Japanese emergency plans) • Rugby Strategy for HR • Iterative process • No development practice • Management process for software engineering • Self organized team • 30-days iterations • Daily meetings • Transparency at all levels: • High level burndown (Backlog) • Iteration burndown (Sprint) • Daily meeting • Less formalized than UP • To be used in conjunction with XP OOAD Training

  24. Software development approachesSCRUM OOAD Training

  25. Software development approachesSCRUM OOAD Training

  26. Software development approachesSCRUM facilitates Scrum process, insures Scrum best practices usage is committed to perform a sprint (without any defined sub-roles) describes and prioritizes the items of the Product Backlog master list of all functionality desired in the product list of tasks that has to be completed in the current sprint team progress vs release plan updated at the end of each sprint OOAD Training

  27. Agile Agile methodologies: • Scrum (www.controlchaos.com) • X-Treme Programming (http://www.extremeprogramming.org/) • Feature-Driven Development (www.featuredrivendevelopment.com) • Unified Process • Rational Unified Process? OOAD Training

  28. Agile Daily Scrum meeting • Max 15 minutes • Stand-up meeting • Only pigs allowed to speak • 3 questions: • What did you do yesterday? • What will you do today? • Are there any impediments in your way? (ex: I can't get the ____ group to give me any time and I need to meet with them.) • The Scrum Master role is to help resolve impediments offline. • Transparency is key in order to: • Maintain quality(developers usually tend to drop quality without telling when asked to do more) • Help management take appropriate decision early(managers usually believe in magic: they just have to ask for more it and it will be done) OOAD Training

  29. Objectives and Agenda Objectives Overview of the software development evolution Detailed presentation of the Unified Process Agenda Software development evolution Facts Conventional development Iterative development Agile Unified Process Introduction Rational Unified Process Phases and Iterations Risk Management Course structure

  30. Unified ProcessIntroduction a Software Engineering Process • Defining tasks & responsibilities • Ensuring high-quality within schedule & budget • Focused on content a Software Development Method • Iterative • Incremental • Use case driven • Focused on architecture <> project management methodology OOAD Training

  31. Unified ProcessRational Unified Process Iterative software development process • Created by Rational Software corp. (now IBM) • Based on Unified Process Software process product: Rational Method Composer • Customizable process framework • Knowledgebase • Template and artifacts library • Published on the web OOAD Training

  32. Unified ProcessRational Unified Process Iterative software development process OOAD Training

  33. Unified ProcessRational Unified Process RUP and PM (1/2) Prince2 & PMI • Broad Project Management usage • Main deliverables are business case, project plans, changes requests, corrective actions, lessons learned, risk plan… • Project management disciplines • Integration and Scope management • Risk and Quality management • HR and Communication management (hiring, training, coaching…) • Time and Cost management • Procurement management (with suppliers, sponsors, ...) • Do not contain development method best practices RUP • Limited to software engineering • Focus on content: main deliverables are business case, iteration plans, SRS, SAD, implemented components, iteration evaluations… • Project management is a discipline of RUP • Planning (iterations & phases) • In terms of risk, time and people (tasks & responsibilities allocation) • Contain development method best practices OOAD Training

  34. In RUP all disciplines are expressed in terms of roles, activities and artifacts A unit of work with a clear purpose that a worker will perform Activity = element of planning & progress The behaviour and responsibilities of a (group of) individual(s). An individual can have many hats Worker = role A piece of information produced, modified or used by a process Artifact = Input & Output of activities Unified ProcessRational Unified Process Static aspect OOAD Training

  35. Unified ProcessRational Unified ProcessDynamic aspect A project is broken into 4 phases Each phase can have several iterations Major Milestones Inception Elaboration Construction Transition time OOAD Training

  36. Unified ProcessRational Unified ProcessRational Method Composer First aim of RMC: • Content management system providing a common management structure for all of content development practitioners. OOAD Training

  37. Requirements workflow in RUP Unified ProcessRational Unified ProcessRational Method Composer Second aim of RMC: • Provide process engineering capabilities for supporting process engineers and project managers for their development projects. OOAD Training

  38. Unified ProcessRational Unified ProcessRational Method Composer Illustration: • Requirements workflow with RUP OOAD Training

  39. Unified ProcessPhases and IterationsSequential Phases (1/2) 4 sequential phases • Inception • Approximate the vision • Define the scope of the project • Build the business case (Go – No-Go ?) • Capture high-level requirements • 1st bid (rough planning estimates) • Usually last a few days for small projects or a week for medium projects • Elaboration • Refine the vision • Iterative implementation of core architecture • High risks resolution • Use cases description • Development plan and realistic estimates • Construction • Transition OOAD Training

  40. Resources Inception Elaboration Construction Transition Effort 65% Lifecycle Objectives Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Project Release Milestone 10% 20% 5% Time Inception Elaboration Construction Transition Time 10% 30% 50% 10% Unified ProcessPhases and IterationsSequential Phases (2/2) 4 sequential phases • Inception • Elaboration • Construction • Iterative implementation of software components • Internal releases • First external release • Transition • Beta-tests • Performance tuning • End-user training and appropriation OOAD Training

  41. Inception Elaboration Construction Transition Preliminary IT_1 IT_2 IT_m IT_m+1 IT_m+2 IT_n-1 IT_n Iteration(s) First internal release (Conceptual prototype) Internal Release First external release (beta) Final Release (Delivery) Internal release (Architecture baseline) 4% 5% 20% 35% 20% 4% 5% 5% 3% Unified ProcessPhases and Iterationsn iterations n Iterations • Each iteration is a complete development process resulting in an executable but incomplete system • Iterations could exist in each phase • 2 to 8 weeks duration • In each iteration  a V-schema OOAD Training

  42. Unified ProcessPhases and Iterations Approach Iterative development • Quick-wins with lessons-learned of each iteration • Review the scheduling strategy to review and revise parts of the system • Early feedbacks • Early risks handling Incremental development • Development and delivery in stage • Divide complexity to conquer • More and more functionalities from iterations to iterations OOAD Training

  43. Unified ProcessPhases and Iterations Approach Types of feedback • In early developments • From programmers trying to read specifications • From clients using the demos  refine requirements • In project progress • From team workers to refine schedule and estimates • From clients to re-prioritize the features to be tackled in next iteration • In late developments and tests • From developers and testers to refine designs or models OOAD Training

  44. Unified ProcessPhases and Iterationsn iterations Number of iterations • Depends on the phase • Depends on the project size • Generally from 1 to 4 for one phase Duration of an iteration • Depends on the project size • Generally from 2 to 8 weeks Time-boxing • Deadlines fixed  length-fixed • Date slippage is forbidden • If needed: reduce scope (but not quality!) OOAD Training

  45. Unified ProcessPhases and Iterationsn iterations Time-boxing or content-boxing? • Aim: reduce risks & keep meeting reservations • Not able to do scope during time frame? too many issues? each iteration aims to reduce risks do not face too many risks at once reduce scope • It’s fine to not release the software at the end of an iteration (YAGRI principle) • You can increase the number of iterations OOAD Training

  46. Unified ProcessPhases and Iterationsn iterations Tip Workload = Productivity (1,5 or 2) Project iterations illustrations + 1 = OOAD Training

  47. Inception Elaboration Construction Transition IT_1 IT_2 IT_3 IT_4 IT_5 IT_6 IT_7 First internal release (Conceptual prototype) Internal Release First external release (beta) Final Release (Delivery) Internal release (Architecture baseline) Inception Elaboration Construction Transition IT_1 IT_2 IT_3 IT_4 IT_5 IT_6 IT_7 IT_8 IT_9 IT_10 First internal release (Conceptual prototype) Internal Release First external release (beta) Final Release (Delivery) Internal release (Architecture baseline) Unified ProcessPhases and Iterationsn iterations Small project Large project OOAD Training

  48. Inception Elaboration Construction Transition Phases Plan Preliminary IT_1 IT_2 IT_m IT_m+1 IT_m+2 IT_n-1 IT_n Iteration(s) Iterations Plan Unified ProcessPhases and Iterationsn iterations Rolling wave OOAD Training

  49. Unified ProcessPhases and IterationsIn practice (1/3) Inception 1 Iteration – 2 days • Requirements workshop (Chief architect, business and analysts) • Day 1 a.m.: high level requirements analysis  set of high level UC • Day 1 a.m.: pick 10% from those high level UC. • Day 1 p.m and Day 2 a.m. : do intensive detailed analysis of the functional and non functional requirements for these UC. • Planning meeting (Chief architect, analysts and development people) • Day 2 p.m.: hold an iteration planning meeting for the first iteration on a subset of detailed use cases. Break them down to detailed iteration tasks. • Validate business case OOAD Training

  50. Unified ProcessPlanning What is the main challenge of planning?  Estimations Study by the Simular Research Group on Factors that influence estimation • Effect of irrelevant information

More Related