Course material from my Object-Oriented Development course. This presentation discusses methodologies, development processes, the waterfall model and interative development.

1. DEVELOPMENT
2 METHODOLOGIES
Development processes and methodologies

2. 1 INTRODUCTION
2 METHODOLOGIES
3 MODELS AND UML
4 OBJECT CONCEPTS
5 ANALYSIS
2
6 SOFTWARE DESIGN

3. Goal of Presentation
3
 This presentation will
 Review software processes and methodologies
 Overview the System Development Life Cycles process

4. Addressing Complexity
4
 The complexity of creating software was identified as
perhaps the most important cause of software problems.
 The solution to this problem, like to the solution to any
problem, is to break up the process of solving it into
stages.
 A process is a set of activities and associated results which
produce a product.
Problem
definition
Data
gathering
Problem
redefinition
Finding
ideas
Finding
solutions
Implementation
General problem solving process
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 46.

5. Advantages of Subdivision
5
 Subdividing the development process results in
smaller tasks that can be more easily managed.
 Subdividing the development process allows
techniques and skills specific to different phases to
be developed and used.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 46.

6. Project Lifecycles
6
 Subdividing the process of software development
produces a life cycle model.
 A lifecycle identifies the phases along which a software
product moves, from inception to shipping.
 The traditional lifecycle for information systems is also
known as the waterfall life cycle model.
System Planning
Requirements Analysis
System Design
Implementation
Testing
Maintenance

7. System Development Life Cycle
7
 Although there are numerous variations, the basic SDLC
phases include:
 System planning - defines what the new system is intended
to accomplish and how the project will be organized.
 Requirements analysis - investigating and documenting in
detail what the system actually should do to accomplish
what is intended.
 System design - specifying in detail how to implement the
system using specific technology.
 Implementation - creating the actual system.
 Testing - ensuring the implemented system meets all of the
specified requirements.
 Maintenance - providing needed improvements or fixes.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 101-2

8. Waterfall SDLC
8
 Advantages
 Better than ad-hoc, code-and-fix approach.
 It enforces planning before coding.
 "plan the work, work the plan"
 Provides management with predictability and a
foundation for measuring progress.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 102

9. Waterfall SDLC
9
 Disadvantages
 there are few visible results (other than documents) until
near the end of the lifecycle.
 higher risk and failure, and all-around lower productivity.
 It requires a low-change, low-novelty, and low-complexity
problem.
 pushes many high-risk and difficult elements toward the end
of a project.
Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

10. Waterfall SDLC
10
 Disadvantages
 The waterfall also aggravates complexity overload
and analysis paralysis.
 Large steps with overwhelming degrees of complexity are
attempted.
 Difficult to plan accurate schedules
Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

11. Waterfall SDLC
11
 Disadvantages
 Difficult to fully specifying the requirements at the beginning
of the project.
 A great deal of time can take place between requirements phases
and the implementation phase.
 The more complex the project, the more requirements change
 Research shows that a typical software project experiences a 25%
change in requirements
Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

12. Waterfall SDLC
12
 In 1994, the DOD dropped their waterfall 2167A
specification, because of abysmal failure.
 They now encourage an iterative process.
Source: Craig Larman, “Software Economics” presentation.

13. Iterative Development
13
 The iterative or incremental approach recognizes that users
and developers learn about the requirements as they
progress through the development process.
 Development is thus organized into a series of short, fixed-
length mini-projects called iterations.
 Each iteration includes its own analysis, design, implementation,
and testing phases.
Iteration Iteration
...
1 2
Code, Test, Code, Test,
Analyze Design Analyze Design
Integrate Integrate
4 weeks (for example) 4 weeks
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 102
Source: Craig Larman, Applying UML and Patterns, 2nd Ed (Prentice Hall, 2001), p. 14-5.

14. 14
Iterative Development
 Each iteration is thus a self-contained mini-
project containing multiple activities
(requirements, analysis, etc)
 The goal for the end of an iteration is an
iteration release, a stable, integrated and
tested partially complete system.
Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

15. Iterative Development
15
 The Iterative SDLC is based on the successive
enlargement and refinement of a system through
multiple iterations/releases.
 The result of each iteration is an executable but
incomplete system.
 The system will not be ready for delivery into production
after many iterations (say 5 to 15 iterations).
 Each iteration should be a production-grade subset of the
final system.
 i.e., each iteration is not a prototype or proof of concept, but a
subset of the final system.
Source: Craig Larman, Applying UML and Patterns, 2nd Ed (Prentice Hall, 2001), p. 14-6.

16. Iterative Development
16
 The system thus grows incrementally over time,
iteration by iteration, with each new
iteration/release embodying incremental
improvements over the other.
 Each iteration generally tackles new requirements and
incrementally extends the systems.
 Sometimes, however, an iteration may focus on
improving the performance or integration of existing
increments.

17. Iterative Development
17
 Advantages
 Users do not have to wait until system is delivered before they can gain
value from it.
 Early risk mitigation and discovery
 Higher priority services added first and thus receive the most testing.
 More adaptive to changing requirements
 is used by current agile methods, including Scrum and XP.
 Disadvantages
 Sometimes difficult to map user’s requirements into increments.
 Most systems require basic set of facilities which are used by all parts
of a system; these basic facilities may not map well into increments.
 May require paradigm change for some developers
Source: Ian Sommerville, Software Engineering, 6th Edition (Addison-Wesley, 2001), p. 52-3

18. Managing Iterative Development
18
Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

19. Which Iterations First?
19
 Two strategies:
 Risk-driven
 Choose the riskiest, most difficult elements for the early
iterations
 Client-driven
 Client prioritizes the iterations based on whatever they
perceive to have the highest business value to them.

20. System Development
20
Methodologies
 A lifecycle gives a general understanding of what
system development is about but it does not give
guidance on how to carry out system development.
 To help develop quality information systems in a
timely and manageable way, we may need a
complete system development methodology.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

21. Method and Methodology
21
 Method
 Step-by-step description of the steps involved in doing
a job
 Methodology
A set of general principles that guide a practitioner to
the choice of a particular method suited to a specific
task or project.
 defines the process and sequence of tasks that need to
be completed when developing a system, along with
recommended techniques for completing the tasks.
 Defines a series of methods to be used.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 555.

22. Methodologies
22
 A methodology generally has two components,
related to what and how:
 Process component - explains what tasks to do and
when to do them, spelling out the life cycle to follow
and the general project management approaches to
be used.
 Techniques component - describes the techniques and
tools that could or should be used for the tasks at hand.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

23. Methodology Details
23
 What is needed in a methodology varies widely with
the projects undertaken.
 A decisive factor is the number of people involved.
 In small projects, the main modeling techniques to be used
are the most important aspect of the method.
 As the number of people increases, a comprehensive
methodology with a clearly defined process increases
rapidly.
 Another decisive factor is the use of the system:
 If the system being development is life critical or mission
critical then a well-defined process is necessary.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

24. Comprehensive Methodologies
24
 A comprehensive methodology should provide a clear work
breakdown structure that divides the development effort into
phases, steps, and tasks.
 The methodology should indicate the sequence of tasks:
which can be done in parallel, which can be skipped under
certain circumstances, and so on.
 The methodology should indicate inputs and outputs to the
phases, steps, and tasks.
 It should indicate the techniques and tools that should or
could be used.
 It should also be flexible and adaptable to the project at
hand by allowing for the deleting, rearranging, and
combining of steps and tasks.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

25. Trends in Methodologies
25
 There are two opposing trends in methodology
development:
 Methodologically Substantial
 advocates a clearly defined and tightly managed process,
emphasizing rigor, predictability, and engineering-like
development.
 e.g., Capability Maturity Model (CMM) and ISO 9000.
 Methodological Minimalism
 advocates a minimal methodology with maximum freedom on the
part of the developers to adapt their approaches according to
the needs of the project.
 e.g., Extreme Programming, Agile Development

26. Methodologies and Process
26
 Object-oriented development should also follow a
well-defined software process.
 Remember, process is a more general term, while
methodology the more specific.

27. Unified Software Development
27
Process
 Developed (1999) by the team that created UML.
 Embodies best practice in system development.
 Uses iterative and incremental life cycles.
 Adopts an iterative approach with four main
phases.
 Different tasks are captured in a series of
workflows.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 109-110.

28. Unified Software Development
28
Process
 Has four main phases:
 Inception (determining scope and purpose of project)
 Elaboration (requirements capturing and determining structure of system)
 Construction (build the system)
 Transition (product installation and rollout)
 Each phases has a workflow or lifecycle:
 Requirements
 Analysis
 Design
 Implementation
 Test
 The balance of effort spent in each workflow varies from phase to phase.
 Within phases there may be more than one iteration.

29. The Unified Software Development Process
Project Phases
Inception Elaboration Construction Transition
1 2 3 4 5 6 7 8 Iteration #
Requirements
Analysis
Size of square
indicates
relative time
Design spent on
workflow in
that iteration
Implementation
Test
Workflows Iterations within
Time each phase
29
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 111.

30. Waterfall Life Cycle
30
Requirements Design Test
Analysis Implementation
Requirements
Analysis
Design
Implementation
Test
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 111.

31. UP Phases: Inception
31
 Goal
 is to get the project off the ground by establishing
feasibility, creating a business case of benefits of project,
capturing essential requirements and identifying critical
risks.
 Focus
 on requirements and analysis workflows.
 Deliverables
 are a problem/vision statement document, initial use case
model (10% complete), business case document, initial
architecture, simple prototypes, project plan.
Inception is about
initiating the project
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 33-4.

32. UP Phases: Elaboration
32
 Goal
 is to capture up to 80% of the functional requirements in use cases, create
detailed plan for construction phase, create initial executable architectural
baseline (i.e., initial system) that will evolve and grow in next phase.
 Focus
 on requirements, analysis, and design workflows.
 Implementation and test workflows also become important toward the end of the
phase on in so far that one constructs and tests the initial baseline.
 Deliverables
 are Use Case model, UML static model, UML dynamic model, updated project
plan, and executable architectural baseline.
Elaboration is
perhaps the most
Elaboration is about
critical phase, and for
creating a partial but
this reason, most of
working version of the
this course is
system (the executable
focused on it.
architectural baseline)
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 34-5.

33. UP Phases: Construction
33
 Goal
 is to complete all requirements, analysis, and design, and to evolve the
architectural baseline into the final system.
 Key issue is maintaining the integrity of the system architecture (i.e., not
to cut corners, but maintain proper design).
 Focus
 on implementation and testing workflows, with secondary effort made
on completing requirements, analysis and design.
 Deliverables
 The software product, the completed UML model, a test suite, and user
manuals.
Construction evolves
the executable
architectural baseline
into a complete
working system.
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 36.

34. UP Phases: Transition
34
 Goal
 Starts when beta testing is complete and the system is
deployed. Goal is thus to fix bugs and prepare for the
rollout.
 Focus
 on testing workflows (as well on implementation in that bugs
have to be fixed).
 Deliverables
 The software product, user manuals, and user support plan.
Transition is about
deploying the
completed system into
the user community
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 37-8.

35. Workflows: Requirements
35 Workflow Techniques Key Deliverables
Requirements Requirements Elicitation Use Case Model
Use Case Modelling Requirements List
Prototyping Prototypes
Glossary
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112.

36. Workflows: Analysis
Workflow Techniques Key Deliverables
36
Analysis Collaboration Diagrams Analysis Models
Class and Object Models
Analysis Modelling
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112.

37. Workflows: Design
37
Workflow Techniques Key Deliverables
Design Class and Object Modelling Design Models
Interaction Modelling
State Modelling
Design Patterns
Deployment Modelling Overview Design and
Implementation Architecture
Component Modelling
Package Modelling
Architectural Modelling
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112.

38. Workflows: Implementation
38
Workflow Techniques Key Deliverables
Implementation Programming Executable System
Component Re-use Documentation
Database DDL
Programming Idioms
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112.

39. Workflows: Testing
39
Workflow Techniques Key Deliverables
Testing Programming Tested System
Test Procedures
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112.

40. O-O Methodologies
40
 The previous process is not a complete methodology.
 Most larger software companies have their own methodology that you
must work within and follow.
 Most current methodologies are based upon the Unified Software
Development Process.
 In this course, we will not be following a specific methodology.
 We will try to follow, in spirit, the Unified Software Development
Process.
 Due to time-constraints, we will not be able to realistically follow all the
phases and increments.
Inc eption Elaboration Construction Transi tion
1 2 3 4 5 6 7 8
Requirem ents
Anal ys is
Des i gn
Implementation
Tes t