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.
Unified ProcessIntroduction to Rational Unified processMartin Terreni
Agenda• What is a software engineering process?• Waterfall model• What is RUP?• Why RUP?• RUP workflows and phases• RUP BKP• Summary• Bibliography
What is a software engineeringprocess?• First –what is not?– It is not UML! (it is not any modeling or codinglanguage at all!)– It is not planning MPOR Items and thereschedule (though it is related…).– It is not writing lot of IPS, EPS and other overhead docs (and if it is all you are doingsomething wrong).
What is a software engineeringprocess?• Then what IS IT?– Who is doing what, when and how (andWHY!!)
Waterfall modelCompletely understand requirements, finishdesign, code, testand only then implement.
Waterfall Process Assumptions• Requirements are known up front beforedesign• Requirements rarely change• Users know what they want, and rarely needvisualization• Design can be conducted in a purely abstractspace, or trial rarely leads to error• The technology will all fit nicely into place whenthe time comes (the apocalypse)• The system is not so complex. (Drawings arefor wimps)
What is RUP?“a web-enabled software engineeringprocess that enhances team productivityand delivers software best practices to allteam members”The Rational Unified Process, 2nd Edition
What is RUP?• RUP is a method of managing OO SoftwareDevelopment• It can be viewed as a Software DevelopmentFramework which is extensible .
What is RUP?The Spirit of RUP:• Attack major risks early and continuously…orthey will attack you.• Ensure that you deliver value to yourcustomer.• 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 anafterthought.
Why RUP?1. It accommodates changing requirements2. Integration is not one "big bang" at the end of aproject3. Risks are usually discovered or addressedduring early integrations4. Reuse is facilitated5. Defects can be found and corrected overseveral iterations6. The development process itself is improvedand refined along the way
Workflows and phasesThree Types of Projects• Project Ganymede, a green-field development of a smallapplication. The initial development cycle of a brand-newapplication where everything, including the requirements,have to be designed from scratch.• Project Mars, a green-field development of a largersystem so that we can articulate the major difference withthe first example.• Project Jupiter, an evolution cycle of an existing largeapplication (the "version 2.0"); this is more representative ofa large number of RUP projects, which only evolve existingsystems and do not create them from scratch.
Our projectLets take an existing project that needs anew improved version.We have a simulation system for logiccircuits and a test plan DB.The customer wants them to communicateand work atumaticaly.
The Inception Phase• In this phase a business case which includes: Businesscontext, Success factors such as (expected revenue,market recognition, etc), and Financial forecast areestablished. Besides a business case a basic use casemodel, project plan, initial risk assessment and adocument that generally describes the project (the coreproject requirements, constraints and key features) arerealized.
The Inception PhaseObjectives of the Inception Phase:1. Understand what to build. Determine the vision, the scope of thesystem, and its boundaries, that is, what is inside the system andwhat is outside. Identify who wants this system and what it is worthto them.2. Identify key system functionality. Decide which use cases (whichways of using the system) are most critical.3. Determine at least one possible solution. Identify at least onecandidate architecture.4. Understand the costs, schedule, and risks associated with theproject.5. Decide what process to follow and what tools to use.
The Inception PhaseLifecycle Objective Milestone• Stakeholder concurrence on scope definition and aninitial cost/schedule estimate (which will be refined inlater phases)• Agreement that the right set of requirements has beencaptured and that there is a shared understanding ofthese requirements• Agreement that the cost/schedule estimate, priorities,risks, and development process are appropriate• Agreement that initial risks have been identified and amitigation strategy exists for each
The Elaboration Phase• Elaboration is the second of the four phases in the RUPapproach. The goal of the Elaboration phase is to define andbaseline the architecture of the system in order to provide astable basis for the bulk of the design and implementationeffort in the Construction phase. The architecture evolves outof a consideration of the most significant requirements (thosethat have a great impact on the architecture of the system) andan assessment of risks.
The Elaboration PhaseObjectives of the Elaboration Phase:1. Get a more detailed understanding of therequirements.2. Design, implement, validate, and baselinethe architecture.3. Mitigate essential risks, and produce moreaccurate schedule and cost estimates.4. Refine the development case and put thedevelopment environment in place.
The Elaboration PhaseLifecycle Architecture Milestone• Are the product Vision and requirements stable?• Is the architecture stable?• Are the key approaches to be used in testing and evaluationproven?• Have testing and evaluation of executable prototypes demonstratedthat the major risk elements have been addressed and resolved?• Are the iteration plans for Construction of sufficient detail andfidelity to allow the work to proceed?• Are the iteration plans for the Construction phase supported bycredible estimates?• Do all stakeholders agree that the current Vision, as defined in theVision Document, can be met if the current plan is executed todevelop the complete system in the context of the currentarchitecture?• Are actual resource expenditures versus planned expendituresacceptable?
The Construction PhaseIn this phase the main focus goes to the development ofcomponents and other features of the system that isbeing developed. This is the phase when coding takesplace.At the end of this phase the first release of the softwareproduct is expected and this is a major criterion of itsmilestone.
The Construction PhaseObjectives of the Construction Phase1. Minimize development costs and achievesome degree of parallelism.2. Iteratively develop a complete product thatis ready to transition to its user community.
The Construction PhaseInitial Operational Capability Milestone:1. Is this product release stable and matureenough to be deployed in the usercommunity?2. Are all the stakeholders ready for thetransition into the user community?3. Are actual resource expenditures versusplanned expenditures still acceptable?
The Transition PhaseThe focus of the Transition phase is to ensurethat the software fully addresses the needs of itsusers. The Transition phase normally spans oneor two iterations that include testing the productin preparation for release and making minoradjustments based on user feedback.
The Transition PhaseObjectives of the Transition Phase1. 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 operationaldatabases.4. Achieve stakeholder concurrence that deploymentbaselines are complete and consistent with theevaluation criteria of the vision.5. Improve future project performance through lessonslearned.
The Transition PhaseProduct Release Milestone• Are the users satisfied?• Are actual resource expenditures versusplanned expenditures acceptable, and, ifnot, what actions can be taken in futureprojects to address this issue?
RUP BKP1. Develop software iteratively2. Manage requirements3. Use component based architecture4. Visually model software5. Verify software quality6. Control changes to software
SummaryThe RUP is a software development approachthat is iterative, architecture-centric, and use-case-driven.It is actually a framework to be tailored to createa suitable process for a specific project.The transition between phases is done by milestones reached during iterations.It has 6 main BKPs to follow.