Recommended
More Related Content
What's hot
What's hot (20)
Similar to Unified process
Similar to Unified process (20)
More from Jean Pаoli
More from Jean Pаoli (16)
Recently uploaded
Recently uploaded (20)
Unified process
- 1. Unified Process Introduction to Rational Unified process Martin Terreni
- 2. Agenda • What is a software engineering process? • Waterfall model • What is RUP? • Why RUP? • RUP workflows and phases • RUP BKP • Summary • Bibliography
- 3. What is a software engineering process? • First –what is not? – It is not UML! (it is not any modeling or coding language at all!) – It is not planning MPOR Items and there schedule (though it is related…). – It is not writing lot of IPS, EPS and other over head docs (and if it is all you are doing something wrong).
- 4. What is a software engineering process? • Then what IS IT? – Who is doing what, when and how (and WHY!!)
- 5. Waterfall model Completely understand requirements, finish design, code, test and only then implement.
- 6. Waterfall Process Assumptions • Requirements are known up front before design • Requirements rarely change • Users know what they want, and rarely need visualization • Design can be conducted in a purely abstract space, or trial rarely leads to error • The technology will all fit nicely into place when the time comes (the apocalypse) • The system is not so complex. (Drawings are for wimps)
- 7. What is RUP? “a web-enabled software engineering process that enhances team productivity and delivers software best practices to all team members” The Rational Unified Process, 2nd Edition
- 8. What is RUP? • RUP is a method of managing OO Software Development • It can be viewed as a Software Development Framework which is extensible .
- 9. What is RUP? The Spirit of RUP: • Attack major risks early and continuously…or they will attack you. • Ensure that you deliver value to your customer. • Stay focused on executable software. • Accommodate change early in the project. • Baseline an executable architecture early on. • Build your system with components. • Work together as one team. • Make quality a way of life, not an afterthought.
- 10. Why RUP? 1. It accommodates changing requirements 2. Integration is not one "big bang" at the end of a project 3. Risks are usually discovered or addressed during early integrations 4. Reuse is facilitated 5. Defects can be found and corrected over several iterations 6. The development process itself is improved and refined along the way
- 11. Workflows and phases Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements Elaboration TransitionInception Construction time conten t
- 12. Workflows and phases Major Milestones
- 13. Workflows and phases Phases and iterations
- 14. Workflows and phases Three Types of Projects • Project Ganymede, a green-field development of a small application. The initial development cycle of a brand-new application where everything, including the requirements, have to be designed from scratch. • Project Mars, a green-field development of a larger system so that we can articulate the major difference with the first example. • Project Jupiter, an evolution cycle of an existing large application (the "version 2.0"); this is more representative of a large number of RUP projects, which only evolve existing systems and do not create them from scratch.
- 15. Our project Lets take an existing project that needs a new improved version. We have a simulation system for logic circuits and a test plan DB. The customer wants them to communicate and work atumaticaly.
- 16. The Inception Phase • In this phase a business case which includes: Business context, Success factors such as (expected revenue, market recognition, etc), and Financial forecast are established. Besides a business case a basic use case model, project plan, initial risk assessment and a document that generally describes the project (the core project requirements, constraints and key features) are realized.
- 17. The Inception Phase Objectives of the Inception Phase: 1. Understand what to build. Determine the vision, the scope of the system, and its boundaries, that is, what is inside the system and what is outside. Identify who wants this system and what it is worth to them. 2. Identify key system functionality. Decide which use cases (which ways of using the system) are most critical. 3. Determine at least one possible solution. Identify at least one candidate architecture. 4. Understand the costs, schedule, and risks associated with the project. 5. Decide what process to follow and what tools to use.
- 18. The Inception Phase Lifecycle Objective Milestone • Stakeholder concurrence on scope definition and an initial cost/schedule estimate (which will be refined in later phases) • Agreement that the right set of requirements has been captured and that there is a shared understanding of these requirements • Agreement that the cost/schedule estimate, priorities, risks, and development process are appropriate • Agreement that initial risks have been identified and a mitigation strategy exists for each
- 19. The Elaboration Phase • Elaboration is the second of the four phases in the RUP approach. The goal of the Elaboration phase is to define and baseline the architecture of the system in order to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risks.
- 20. The Elaboration Phase Objectives of the Elaboration Phase: 1. Get a more detailed understanding of the requirements. 2. Design, implement, validate, and baseline the architecture. 3. Mitigate essential risks, and produce more accurate schedule and cost estimates. 4. Refine the development case and put the development environment in place.
- 21. The Elaboration Phase Lifecycle Architecture Milestone • Are the product Vision and requirements stable? • Is the architecture stable? • Are the key approaches to be used in testing and evaluation proven? • Have testing and evaluation of executable prototypes demonstrated that the major risk elements have been addressed and resolved? • Are the iteration plans for Construction of sufficient detail and fidelity to allow the work to proceed? • Are the iteration plans for the Construction phase supported by credible estimates? • Do all stakeholders agree that the current Vision, as defined in the Vision Document, can be met if the current plan is executed to develop the complete system in the context of the current architecture? • Are actual resource expenditures versus planned expenditures acceptable?
- 22. The Construction Phase In this phase the main focus goes to the development of components and other features of the system that is being developed. This is the phase when coding takes place. At the end of this phase the first release of the software product is expected and this is a major criterion of its milestone.
- 23. The Construction Phase Objectives of the Construction Phase 1. Minimize development costs and achieve some degree of parallelism. 2. Iteratively develop a complete product that is ready to transition to its user community.
- 24. The Construction Phase Initial Operational Capability Milestone: 1. Is this product release stable and mature enough to be deployed in the user community? 2. Are all the stakeholders ready for the transition into the user community? 3. Are actual resource expenditures versus planned expenditures still acceptable?
- 25. The Transition Phase The focus of the Transition phase is to ensure that the software fully addresses the needs of its users. The Transition phase normally spans one or two iterations that include testing the product in preparation for release and making minor adjustments based on user feedback.
- 26. The Transition Phase Objectives of the Transition Phase 1. Beta test to validate that user expectations are met. 2. Train users and maintainers to achieve user self- reliability. 3. Prepare deployment site and convert operational databases. 4. Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision. 5. Improve future project performance through lessons learned.
- 27. The Transition Phase Product Release Milestone • Are the users satisfied? • Are actual resource expenditures versus planned expenditures acceptable, and, if not, what actions can be taken in future projects to address this issue?
- 28. RUP BKP 1. Develop software iteratively 2. Manage requirements 3. Use component based architecture 4. Visually model software 5. Verify software quality 6. Control changes to software
- 29. Summary The RUP is a software development approach that is iterative, architecture-centric, and use- case-driven. It is actually a framework to be tailored to create a suitable process for a specific project. The transition between phases is done by mile stones reached during iterations. It has 6 main BKPs to follow.
- 30. Summary
- 31. Questions?
- 32. Bibliography The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. By Per Kroll, Philippe Kruchten
Editor's Notes
- We are going to walk to RUP basics, specially what may be useful for as in DT. Lat time we learn the words, UML (how to say things) now we will learn the syntax (What to say and how to say it).
- This means that also just coding is a kind of process, the secret is to define it and control it to get the best of it. Otherwise your just flowing through it not taking all advantages you could.
- It is the classic development model. The most easy to implement. 1) First you make ALL requirements (which means there can be no more!) 2) Then you make ALL design (If any design problems are found later “coders will have to deal with it”) 3) Make all Code (no integration testing!) 3) Test all ( BOOM!!!)
- Mainly (and for our interest) process. Though it does have a tool related to it, which can makes it even better, it is not necessary.
- A FRAMEWORK!!! NOT A PROCESS!!! The specific development process for each team and each project is to be tailored from RUP bricks to suite the specific needs.
- A FRAMEWORK!!! NOT A PROCESS!!! The specific development process for each team and each project is to be tailored from RUP bricks to suite the specific needs. Why it is bricks? Because you decide how it actually will look and what output artifacts are needed.
- Of course all advantages of iterative development. 1 – to certain level, since requirements are taken and refined on the run. 2 – ongoing integration/ testing, allows solving problems while they are relatively minor. 3 – biggest risks are faced earlier (first reqs., then design etc.) 4 – component architecture driven process. 5 – avoiding a BOOM of bugs. 6 – iterations model might be changed during the iterations.
- Dynamic structure. The horizontal dimension represents the dynamic structure or time dimension of the process. It shows how the process, expressed in terms of cycles, phases, iterations, and milestones, unfolds over the lifecycle of a project Static structure. The vertical dimension represents the static structure of the process. It describes how process elements—activities, disciplines, artifacts, and roles—are logically grouped into core process disciplines (or workflows).
- There is no chronological or end of artifact that represents end of phase, but rather the achievement of certain maturity level in each phase. This allows iterative work and continuation of workflows avoiding big-bans.
- Every phase might include a number of iterations until the maturity level needed for millstone is reached. Each iteration virtually includes all phases by it self.
- We are going to seek all three projects but mainly Jupiter.
- Mainly – what does the client expect? Is it worth it? Does every body else agree on this points? Maybe also build some kind of ad-hock visualization (GUI, or in our case a “clandestine connection” and some running scripts). It might have nothing to do with actual implementation of solution but it will get you and your costumer a more “eye to eye” vision of project.
- 1 – High level EPS 2 – Actual Use Cases 3 – Mostly though high level modules and lairs. 4 – Make all scheduling and financing plan (at least accurate enough to get going). 5 – configure your process with RUP bricks (dynamic –might change).
- Get main architecture designed and basic parts running so you can check with stake holders you know what they want, you can recheck your plans and you have a design and code skeleton for project base line.
- 1 – We want a detail understanding of most of use cases. 2 – Specially your main skeleton structure. Build main interfaces and infrastructure to a level you can compile run and test main functionalities. 3 – By doing 1 and 2 you can refine planning and mitigate technological risks. 4 – Refine the process you will use for further iterations.
- This is the main coding/design phase. The skeleton done in elaboration phase will be use as base line for all the rest of the system. Also taking care of finishing requirements for all left use cases. This development is done iteratively. Also it is the most time/resources consuming phase. It is also advised to do a beta deployment.
- 1 – Develop in components (plug ins) so you can develop in parallel. 2 - You design a little, code a little test a little. Some claim design should be done from skeleton out in iterations.
- 1 – How did the testing (beta testing?) go? Does it cover all requirements 2 – Did they get any training? Are sites physically ready for deployment? DBs? 3 – just checking.
- 1 – Some bug fixes and usability. 2 – To prevent “not a defect” bugs, High support load and customer miss conform. 3 – Prepare HW, libs. OS, DBs etc. 4 – Make sure customer agrees you cover all vision and requirements! Else you might do it all again… 5 – Postmortem, documentation and process tuning.
- And I would add –is it buggy?
- 1 – Design a little, code a little and test a little. 2 – Be sure you understand what you are supposed to do. Identify, communicate, track and manage changes in requirements. 3 – Parallel developing, reduces spreading bugs and big bans. It is also more scalable, understandable and its basic OO developing. 4 – UML. Faster understanding, trouble shooting and better desing. 5 – Unit test, flow test, regressions and….TESTING! 6 – Configuration Management.