Rational unified process
- 1. OBJECT ORIENTED ANALYSIS AND DESIGN BY USMAN RAFI
- 2. OBJECTIVES • ITERATIVE DEVELOPMENT • RATIONAL UNIFIED PROCESS • SEQUENTIAL WATERFALL MODEL
- 3. ITERATIVE DEVELOPMENT • SKILLFUL DEVELOPMENT APPROACH LIKE UNIFIED PROCESS FOR SOFTWARE DEVELOPMENT • SOFTWARE DEVELOPMENT PROCESS DESCRIBES AN APPROACH FOR DEVELOPING, MAINTAINING AND REPLACING A SOFTWARE SYSTEM • UNIFIED PROCESS ESPECIALLY RATIONAL UNIFIED PROCESS (RUP) CONTRIBUTED A LOT IN ITERATIVE SOFTWARE DEVELOPMENT • UNIFIED PROCESS COMBINES COMMONLY ACCEPTED BEST PRACTICES, SUCH AS AN ITERATIVE LIFECYCLE AND RISK-DRIVEN DEVELOPMENT, INTO A COHESIVE AND WELL-DOCUMENTED DESCRIPTION
- 4. UNIFIED PROCESS • MOTIVATION: ITERATIVE DEVELOPMENT • WORK PROCEEDS THROUGH A SERIES OF STRUCTURED BUILD-FEEDBACK- ADAPT CYCLES
- 5. ITERATIVE DEVELOPMENT APPROACH • IN THIS APPROACH, DEVELOPMENT IS ORGANIZED INTO A SERIES OF SHORT, FIXED- LENGTH (FOR EXAMPLE, FOUR WEEK) MINI-PROJECTS CALLED ITERATIONS • THE OUTCOME OF EACH IS A TESTED, INTEGRATED, AND EXECUTABLE SYSTEM • EACH ITERATION INCLUDES ITS OWN REQUIREMENTS ANALYSIS, DESIGN, IMPLEMENTATION, AND TESTING ACTIVITIES • THE ITERATIVE LIFECYCLE IS BASED ON THE SUCCESSIVE ENLARGEMENT AND REFINEMENT OF A SYSTEM THROUGH MULTIPLE ITERATIONS, WITH CYCLIC FEEDBACK AND ADAPTATION AS CORE DRIVERS TO CONVERGE UPON A SUITABLE SYSTEM • THE SYSTEM GROWS INCREMENTALLY OVER TIME, ITERATION BY ITERATION, AND THUS THIS APPROACH IS ALSO KNOWN AS ITERATIVE AND INCREMENTAL DEVELOPMENT
- 7. EXAMPLE
- 8. EXAMPLE – DISCUSSION • NOTICE IN THIS EXAMPLE THAT THERE IS NEITHER A RUSH TO CODE, NOR A LONG DRAWN-OUT DESIGN STEP THAT ATTEMPTS TO PERFECT ALL DETAILS OF THE DESIGN BEFORE PROGRAMMING • A "LITTLE" FORETHOUGHT REGARDING THE DESIGN WITH VISUAL MODELING USING ROUGH AND FAST UML DRAWINGS IS DONE; PERHAPS A HALF OR FULL DAY BY DEVELOPERS DOING DESIGN WORK IN PAIRS
- 9. ITERATIVE DEVELOPMENT APPROACH • THE RESULT OF EACH ITERATION IS AN EXECUTABLE BUT INCOMPLETE SYSTEM; IT IS NOT READY TO DELIVER INTO PRODUCTION • THE SYSTEM MAY NOT BE ELIGIBLE FOR PRODUCTION DEPLOYMENT UNTIL AFTER MANY ITERATIONS • THE OUTPUT OF AN ITERATION IS NOT AN EXPERIMENTAL OR THROW-AWAY PROTOTYPE • ITERATIVE DEVELOPMENT IS NOT PROTOTYPING RATHER THE OUTPUT IS A PRODUCTION-GRADE SUBSET OF THE FINAL SYSTEM • IN GENERAL, EACH ITERATION TACKLES NEW REQUIREMENTS AND INCREMENTALLY EXTENDS THE SYSTEM, AN ITERATION MAY OCCASIONALLY REVISIT EXISTING SOFTWARE AND IMPROVE IT
- 10. ITERATIVE DEVELOPMENT APPROACH • EACH ITERATION INVOLVES CHOOSING A SMALL SUBSET OF THE REQUIREMENTS, AND QUICKLY DESIGNING, IMPLEMENTING, AND TESTING • IN EARLY ITERATIONS THE CHOICE OF REQUIREMENTS AND DESIGN MAY NOT BE EXACTLY WHAT IS ULTIMATELY DESIRED • BUT THE ACT OF SWIFTLY TAKING A SMALL STEP, BEFORE ALL REQUIREMENTS ARE FINALIZED, OR THE ENTIRE DESIGN IS SPECULATIVELY DEFINED, LEADS TO RAPID FEEDBACK FROM THE USERS, DEVELOPERS, AND TESTS • THE FEEDBACK FROM REALISTIC BUILDING AND TESTING SOMETHING PROVIDES CRUCIAL PRACTICAL INSIGHT AND AN OPPORTUNITY TO MODIFY OR ADAPT UNDERSTANDING OF THE REQUIREMENTS OR DESIGN
- 11. WHY THIS APPROACH? • EMBRACING CHANGE: FEEDBACK AND ADAPTATION • RATHER THAN FIGHTING THE INEVITABLE CHANGE THAT OCCURS IN SOFTWARE DEVELOPMENT BY TRYING (USUALLY UNSUCCESSFULLY) TO FULLY AND CORRECTLY SPECIFY, FREEZE, AND "SIGN OFF" ON A FROZEN REQUIREMENT SET AND DESIGN BEFORE IMPLEMENTATION • ITERATIVE DEVELOPMENT IS BASED ON AN ATTITUDE OF EMBRACING CHANGE AND ADAPTATION AS UNAVOIDABLE AND INDEED ESSENTIAL DRIVERS
- 13. BENEFITS OF ITERATIVE DEVELOPMENT • EARLY RATHER THAN LATE MITIGATION OF HIGH RISKS (TECHNICAL, REQUIREMENTS, OBJECTIVES, USABILITY) • EARLY VISIBLE PROGRESS • EARLY FEEDBACK, USER ENGAGEMENT, AND ADAPTATION, LEADING TO A REFINED SYSTEM THAT MORE CLOSELY MEETS THE REAL NEEDS OF THE STAKEHOLDERS • MANAGED COMPLEXITY; THE TEAM IS NOT OVERWHELMED BY "ANALYSIS PARALYSIS" OR VERY LONG AND COMPLEX STEPS • THE LEARNING WITHIN AN ITERATION CAN BE METHODICALLY USED TO IMPROVE THE DEVELOPMENT PROCESS ITSELF, ITERATION BY ITERATION
- 14. ITERATION LENGTH • THE UP (AND EXPERIENCED ITERATIVE DEVELOPERS) RECOMMENDS AN ITERATION LENGTH BETWEEN TWO AND SIX WEEKS • SMALL STEPS, RAPID FEEDBACK, AND ADAPTATION ARE CENTRAL IDEAS IN ITERATIVE DEVELOPMENT • A VERY LONG ITERATION MISSES THE POINT OF ITERATIVE DEVELOPMENT
- 15. TIME-BOXING • A KEY IDEA IS THAT ITERATIONS ARE TIMEBOXED, OR FIXED IN LENGTH • FOR EXAMPLE, IF THE NEXT ITERATION IS CHOSEN TO BE FOUR WEEKS LONG, THEN THE PARTIAL SYSTEM SHOULD BE INTEGRATED, TESTED, AND STABILIZED BY THE SCHEDULED DATE • DATE SLIPPAGE IS DISCOURAGE • IF IT SEEMS THAT IT WILL BE DIFFICULT TO MEET THE DEADLINE, THE RECOM- MENDED RESPONSE IS TO REMOVE TASKS OR REQUIREMENTS FROM THE ITERATION, AND INCLUDE THEM IN A FUTURE ITERATION, RATHER THAN SLIP THE COMPLETION DATE
- 16. UNIFIED PROCESS – BEST PRACTICES AND CONCEPTS • ITERATIVE DEVELOPMENT • TIME-BOXED ITERATIONS • USE OF OBJECT-ORIENTED TECHNOLOGIES • TACKLE HIGH-RISK AND HIGH-VALUE ISSUES IN EARLY ITERATIONS • CONTINUOUSLY ENGAGE USERS FOR EVALUATION, FEEDBACK, AND REQUIREMENTS • CONTINUOUSLY VERIFY QUALITY; TEST EARLY, OFTEN, AND REALISTICALLY • APPLY USE CASES • MODEL SOFTWARE VISUALLY USING UML • CAREFULLY MANAGE REQUIREMENTS • PRACTICE CHANGE REQUEST AND CONFIGURATION MANAGEMENT
- 17. DISCIPLINE, ARTIFACT AND WORKFLOWS • DISCIPLINE IS A SET OF ACTIVITIES (AND RELATED ARTIFACTS) IN ONE SUBJECT AREA • REQUIREMENT ANALYSIS ACTIVITY • ARTIFACT IS THE GENERAL TERM FOR ANY WORK PRODUCT • CODE, WEB GRAPHICS, DATABASE SCHEMA, TEXT DOCUMENTS, DIAGRAMS, MODELS • WORKFLOWS ARE WORK ACTIVITIES WITHIN A DISCIPLINE • WRITING A USE CASE
- 18. DISCIPLINES IN UNIFIED PROCESS • BUSINESS MODELING—WHEN DEVELOPING A SINGLE APPLICATION, THIS INCLUDES DOMAIN OBJECT MODELING. WHEN ENGAGED IN LARGE-SCALE BUSINESS ANALYSIS OR BUSINESS PROCESS REENGINEERING, THIS INCLUDES DYNAMIC MODELING OF THE BUSINESS PROCESSES ACROSS THE ENTIRE ENTERPRISE • REQUIREMENTS—REQUIREMENTS ANALYSIS FOR AN APPLICATION, SUCH AS WRITING USE CASES AND IDENTIFYING NON-FUNCTIONAL REQUIREMENTS • DESIGN—ALL ASPECTS OF DESIGN, INCLUDING THE OVERALL ARCHITECTURE, OBJECTS, DATABASES, NETWORKING, AND THE LIKE • IMPLEMENTATION—PROGRAMMING AND BUILDING THE SYSTEM, NOT DEPLOYMENT
- 19. DISCIPLINES IN UNIFIED PROCESS
- 22. THE DEVELOPMENT CASE • THE CHOICE OF UP ARTIFACTS FOR A PROJECT MAY BE WRITTEN UP IN A SHORT DOCUMENT CALLED THE DEVELOPMENT CASE • EXAMPLE: • A WEB-BASED E-COMMERCE SYSTEM MAY REQUIRE A FOCUS ON USER INTERFACE PROTOTYPES • A MACHINE CONTROL SYSTEM MAY BENEFIT FROM DOING MANY STATE DIAGRAMS
- 23. ARTIFACTS
- 24. RATIONAL UNIFIED PROCESS (RUP) • RUP IS A COMPLETE SOFTWARE-DEVELOPMENT PROCESS FRAMEWORK , DEVELOPED BY RATIONAL CORPORATION • IT’S AN ITERATIVE DEVELOPMENT METHODOLOGY BASED UPON SIX INDUSTRY-PROVEN BEST PRACTICES • PROCESSES DERIVED FROM RUP VARY FROM LIGHTWEIGHT—ADDRESSING THE NEEDS OF SMALL PROJECTS —TO MORE COMPREHENSIVE PROCESSES ADDRESSING THE NEEDS OF LARGE, POSSIBLY DISTRIBUTED PROJECT TEAMS
- 25. PHASES OF RUP • INCEPTION • ELABORATION • CONSTRUCTION • TRANSITION
- 26. PHASES OF RUP
- 27. ITERATIONS • EACH PHASE HAS ITERATIONS, EACH HAVING THE PURPOSE OF PRODUCING A DEMONSTRABLE PIECE OF SOFTWARE • THE DURATION OF ITERATION MAY VARY FROM TWO WEEKS OR LESS UP TO SIX MONTHS Inception Elaboration Construction Transition Iterations Iterations IterationsIterations
- 28. INCEPTION • THE LIFE-CYCLE OBJECTIVES OF THE PROJECT ARE STATED, SO THAT THE NEEDS OF EVERY STAKEHOLDER ARE CONSIDERED • SCOPE AND BOUNDARY CONDITIONS, ACCEPTANCE CRITERIA AND SOME REQUIREMENTS ARE ESTABLISHED
- 29. INCEPTION - ACTIVITIES • FORMULATE THE SCOPE OF THE PROJECT • NEEDS OF EVERY STAKEHOLDER, SCOPE, BOUNDARY CONDITIONS AND ACCEPTANCE CRITERIA ESTABLISHED. • PLAN AND PREPARE THE BUSINESS CASE • DEFINE RISK MITIGATION STRATEGY, DEVELOP AN INITIAL PROJECT PLAN AND IDENTIFY KNOWN COST, SCHEDULE, AND PROFITABILITY TRADE-OFFS. • SYNTHESIZE CANDIDATE ARCHITECTURE • CANDIDATE ARCHITECTURE IS PICKED FROM VARIOUS POTENTIAL ARCHITECTURES • PREPARE THE PROJECT ENVIRONMENT • INVOLVES SETTING UP DEVELOPMENT ENVIRONMENT AND SETTING UP THE PROCESS
- 30. ELABORATION • AN ANALYSIS IS DONE TO DETERMINE THE RISKS, STABILITY OF VISION OF WHAT THE PRODUCT IS TO BECOME, STABILITY OF ARCHITECTURE AND EXPENDITURE OF RESOURCES
- 31. ELABORATION – ACTIVITIES • DEFINE THE ARCHITECTURE • PROJECT PLAN IS DEFINED. THE PROCESS, INFRASTRUCTURE AND DEVELOPMENT ENVIRONMENT ARE DESCRIBED • VALIDATE THE ARCHITECTURE • ENSURE THAT THE DEVELOPED ARCHITECTURE WILL FULFILL THE REQUIREMENTS • BASELINE THE ARCHITECTURE • TO PROVIDE A STABLE BASIS FOR THE BULK OF THE DESIGN AND IMPLEMENTATION EFFORT IN THE CONSTRUCTION PHASE
- 32. CONSTRUCTION • THE CONSTRUCTION PHASE IS A MANUFACTURING PROCESS • IT EMPHASIZES MANAGING RESOURCES AND CONTROLLING OPERATIONS TO OPTIMIZE COSTS, SCHEDULES AND QUALITY • THIS PHASE IS BROKEN INTO SEVERAL ITERATIONS
- 33. CONSTRUCTION – ACTIVITIES • DEVELOP AND TEST COMPONENTS • COMPONENTS REQUIRED SATISFYING THE USE CASES, SCENARIOS, AND OTHER FUNCTIONALITY FOR THE ITERATION ARE BUILT • UNIT AND INTEGRATION TESTS ARE DONE ON COMPONENTS • MANAGE RESOURCES AND CONTROL PROCESS • ASSESS THE ITERATION • SATISFACTION OF THE GOAL OF ITERATION IS DETERMINED.
- 34. TRANSITION • THE TRANSITION PHASE IS THE PHASE WHERE THE PRODUCT IS PUT IN THE HANDS OF ITS END USERS • IT INVOLVES ISSUES OF MARKETING, PACKAGING, INSTALLING, CONFIGURING, SUPPORTING THE USER-COMMUNITY, MAKING CORRECTIONS, ETC
- 35. TRANSITION – ACTIVITIES • TEST THE PRODUCT DELIVERABLE IN A CUSTOMER ENVIRONMENT • FINE TUNE THE PRODUCT BASED UPON CUSTOMER FEEDBACK • DELIVER THE FINAL PRODUCT TO THE END USER • FINALIZE END-USER SUPPORT MATERIAL
- 36. ADVANTAGES OF RUP • THE RUP PUTS AN EMPHASIS ON ADDRESSING VERY EARLY HIGH RISKS AREAS • IT DOES NOT ASSUME A FIXED SET OF FIRM REQUIREMENTS AT THE INCEPTION OF THE PROJECT, BUT ALLOWS TO REFINE THE REQUIREMENTS AS THE PROJECT EVOLVES • IT DOES NOT PUT EITHER A STRONG FOCUS ON DOCUMENTS • THE MAIN FOCUS REMAINS THE SOFTWARE PRODUCT ITSELF, AND ITS QUALITY
- 37. THE SEQUENTIAL WATERFALL MODEL • IN CONTRAST TO THE ITERATIVE LIFECYCLE OF THE UP, AN OLD ALTERNATIVE WAS THE SEQUENTIAL, LINEAR, OR "WATERFALL" LIFECYCLE • IT DEFINED STEPS SIMILAR TO THE FOLLOWING • CLARIFY, RECORD, AND COMMIT TO A SET OF COMPLETE AND FROZEN REQUIREMENTS • DESIGN A SYSTEM BASED ON THESE REQUIREMENTS • IMPLEMENT, BASED ON THE DESIGN