Day 5


Published on

software planning and requirement workshop

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Day 5

  1. 1. Software Project Management Planning Technical planning Day 5
  2. 2. Recap• Control plan• Risk management plan – Requirement control plan – Schedule control plan – Budget control plan – Quality control plan – Reporting plan – Metric collection plan• Project closeout plan11/11/2011 2
  3. 3. Today• Technical plan – Process Model – Methods, tools, and techniques – Infrastructure plan – Product acceptance plan• Lab sheet 111/11/2011 3
  4. 4. Technical process plans• This clause of the SPMP shall specify the development process model, the technical methods, tools, and techniques to be used to develop the various work products: – plans for establishing and maintaining the project infrastructure – the product acceptance plan11/11/2011 4
  5. 5. Technical process - Process model• Define the relationships among major project work activities and supporting processes by specifying – the flow of information and work products among activities and functions – the timing of work products to be generated – reviews to be conducted – major milestones to be achieved – baselines to be established – project deliverables to be completed – required approvals that span the duration of the project.11/11/2011 5
  6. 6. Technical process - Process model• The process model for the project shall include project initiation and project termination activities.• To describe the process model, a combination of graphical and textual notations may be used. Any tailoring of an organization’s standard process model for a project shall be indicated in this sub-clause.11/11/2011 6
  7. 7. Software development models• Waterfall model• Spiral model• Iterative and incremental development• Agile development11/11/2011 7
  8. 8. Software development methods• Evolutionary Development model• Model driven development• User experience• Top-down and bottom-up design• Chaos model• Evolutionary prototyping• Prototyping• ICONIX Process (UML-based object modeling with use cases)• Unified Process• V-model• Extreme Programming• Software Development Rhythms• Specification and Description Language• Incremental funding methodology• Verification and Validation (software)• Service-Oriented Modeling Framework11/11/2011 8
  9. 9. Rational Unified Process (RUP)11/11/2011 9
  10. 10. What is RUP?• An underlying set of principles for successful software development. – These principles are the foundation on which the RUP has been developed.• A framework of reusable method content and process building blocks. – A family of method plug-ins defines a method framework from which you create your own method configurations and tailored processes.• The underlying method and process definition language. – A unified method architecture meta-model that provides a language for describing method content and processes.11/11/2011 10
  11. 11. RUP history• Software process product that was produced by IBM in Feb 2003• Included in the IBM Rational Method Composer (RMC) product which allows customization of the process11/11/2011 11
  12. 12. Poor software development• User or business needs not met• Requirements churn• Modules do not integrate• Hard to maintain• Late discovery of flaws• Poor quality or end-user experience• Poor performance under load• No coordinated team effort• Build-and-release issues11/11/2011 12
  13. 13. Tracing the root cause11/11/2011 13
  14. 14. Enable Feedback by Delivering Incremental User Value• Divide the project into a set of iterations – In each iteration, we perform some requirements, design, implementation, and testing of the application, producing a deliverable that is one step closer to the solution.• Obtain feedback from stakeholders to find out: – Are we moving in the right direction? – Are stakeholders satisfied so far? – Do we need to change the features implemented so far? – What additional features need to be implemented to add business value?11/11/2011 14
  15. 15. Iterative Development Characteristics• Resolves major risks before P P P Iterative 1 Iterative 2 Iterative 3 making large investments.• Enables early user feedback. A A A• Makes testing and integration continuous. D D D• Focuses project short-term objective milestones. T T T• Makes possible deployment of partial implementations. M M M 11/11/2011 15
  16. 16. Iterative Development Produce an Executable11/11/2011 16
  17. 17. Elements of RUP11/11/2011 17
  18. 18. Process Structure• Two dimensions.• Horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds.• Vertical axis represents core process workflows, which group activities logically by nature.11/11/2011 18
  19. 19. The Development Phases• Inception Phase• Elaboration Phase• Construction Phase• Transition Phase11/11/2011 19
  20. 20. Inception objectives• Establish project scope and boundary conditions• Determine the use cases and primary scenarios that will drive the major design trade-offs• Demonstrate a candidate architecture against some of the primary scenarios• Estimate the overall cost and schedule• Identify potential risks (the sources of unpredictability)• Prepare the supporting environment for the project11/11/2011 20
  21. 21. Inception activities• Formulate scope of project• Plan and prepare a business case and evaluate alternatives for risk management, staffing, project plan• Synthesise a candidate architecture.11/11/2011 21
  22. 22. Outcome of inception• A ‘vision’ document, i.e., a general vision of the core projects requirements, key features and main constraints.• A Use-Case model survey – all Use Cases and Actors that can be identified so far.• An initial project glossary.• An initial business case including business context, success criteria and financial forecast.• Initial risk assessment.• Project plan, with phases and iterations.11/11/2011 22
  23. 23. Evaluation criteria at end • Agreement on scope definition and cost and schedule estimates • Requirements understanding as shown by the correctness of the primary Use Cases. • Credibility of the cost and schedule estimates, priorities, risks and development process. • Depth and breadth of any architectural prototype that was developed. • Actual expenditure v planned expenditure.11/11/2011 23
  24. 24. Elaboration objectives• Define, validate, and baseline the architecture as rapidly as is practical• Address architectural significant risks• Baseline the vision• Baseline a detailed plan for the Construction phase• Demonstrate that the baseline architecture will support the vision at a reasonable cost in a reasonable period of time• Refine support environment11/11/2011 24
  25. 25. Elaboration objectives• Define, validate and agree the architecture as quickly as possible.• Agree the vision that came from the inception phase.• Agree a plan for the construction phase.• Demonstrate that the architecture will support this vision for a reasonable cost in a reasonable time.11/11/2011 25
  26. 26. Elaboration activities• The vision is elaborated and a solid understanding is established of the most critical Use Cases that drive the architectural and planning decisions.• The Process, the infrastructure and the development environment are elaborated, and the process, tools and automation support are put into place.11/11/2011 26
  27. 27. Elaboration activities• The architecture is elaborated and components are selected. – Potential components are evaluated. – make / buy / reuse decisions determine the construction phase cost and schedule. – Architectural components integrated and assessed against primary scenarios. – This is done iteratively.11/11/2011 27
  28. 28. Outcome of elaboration• Executable architectural prototype.• Revised risk list and revised business case.• Development plan for overall project. – coarse grained project plan, with iterations and evaluation criteria for each iteration.• Updated development case that specifies process to be used.• Preliminary user manual (optional).11/11/2011 28
  29. 29. Evaluation criteria at end • Is the vision of the product stable? • Is the architecture stable? • Does the executable demonstration show that major risk elements are addressed? • Is construction phase sufficiently planned? • Do all stakeholders agree that current vision is achievable, using current plan with current architecture? • Is the cost acceptable?11/11/2011 29
  30. 30. Construction • Complete the software product for transition to production • Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework • Achieve adequate quality as rapidly as is practical • Achieve useful versions (alpha, beta, and other test releases) as rapidly as possible11/11/2011 30
  31. 31. Construction objectives• Minimise development costs by optimising resources and avoiding unnecessary scrap and rework.• Achieve adequate quality as rapidly as possible.• Achieve useful versions (alpha, beta or other test releases) as rapidly as practical.11/11/2011 31
  32. 32. Construction activities• Resource management, resource control, process optimisation.• Complete component development and testing against the defined evaluation criteria.• Assessment of product releases against acceptance criteria for the vision.11/11/2011 32
  33. 33. Outcome of construction• A product ready to put into the hands of end users.• The software product integrated on the adequate platforms.• The user manuals.• A description of the current release.11/11/2011 33
  34. 34. Evaluation criteria at end• Often called the beta release, is it ready? – Is the product release stable and mature enough to be deployed in the user community? – Are all stakeholders ready for the transition into the use community? – Are the actual resource expenditures v planned expenditures still acceptable?• Transition may have to be postponed by one release if the project fails to reach this milestone.11/11/2011 34
  35. 35. Transition• This moves the software project to the user community.• After release, issues usually arise that require new releases, either to correct problems or finish features that were postponed.• This phase is entered when a baseline is mature enough to be deployed in the end-user domain.• This means that some usable subset of the system has beem completed to an acceptable level of quality and that user documentation is available.11/11/2011 35
  36. 36. Transition phase includes• Beta testing to validate the new system against use expectations.• Parallel operation with the legacy system that the project is replacing• Conversion of operational databases.• Training of users and maintainers.• Rollout of the product to the marketing, distribution and sales teams.• It concludes when the deployment baseline has achieved the completed vision.11/11/2011 36
  37. 37. Transition objectives• Achieve user self-supportability.• Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision.• Achieve final product baseline as rapidly and cost-effectively as practical.11/11/2011 37
  38. 38. Transition activities• Deployment-specific engineering, i.e. cutover, commercial packaging and production, sales rollout, and field personnel training.• Tuning activities, including bug fixing and enhancement for performance and usability.• Assessing the deployment baselines against the vision and the acceptance criteria for the product.• The activities depend on the goal – For fixing bugs, implementation and testing are usually enough. – For new features, iteration is similar to construction phase.11/11/2011 38
  39. 39. Evaluation criteria at end• Is user satisfied?• Are the actual resources expenditures vs planned expenditures still acceptable?11/11/2011 39
  40. 40. Technical process - Methods, tools, and techniques• Specifies the following items: – development methodologies – programming languages and other notations – the tools and techniques to be used to • specify • document • design • deliver • build • modify • test • maintain • integrate the project deliverable and non deliverable work products.• In addition, the technical standards, policies, and procedures governing development and/or modification of the work products shall be specified.11/11/2011 40
  41. 41. Methods• What are the methods you are going to use in your software development phases• For example – REQUIREMENT AND DESIGN: the project will be using UML – TESTING: will be done through white box testing and black box testing – SW TOOLS: Java, MS Office, MS Project, GPS Track Maker 13.5.409, Internet Explorer, – HW TOOLS: PC and Peripherals – PERSONAL SKILLS: Communication skills, XML, Java, SW Engineering Processes, Review and Testing Techniques, User Manual, Planning and Coordination.11/11/2011 41