The document discusses object oriented analysis and design using the iterative development approach. It describes the iterative development process, which involves short, fixed-length iterations to incrementally develop a software system. Each iteration includes requirements analysis, design, implementation, and testing activities. The Rational Unified Process (RUP) framework is discussed as an example of an iterative development methodology. RUP includes phases like inception, elaboration, construction, and transition with iterations conducted within each phase. The benefits of the iterative approach over the traditional sequential waterfall model are highlighted.

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

6. ITERATIVE DEVELOPMENT PROCESS

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

12. ITERATIONS AND CHANGE

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

20. DISCIPLINES AND PHASES

21. INCREMENTAL OOA/OOD

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