Software Development Methodologies Lecturer: Raman Ramsin Lecture 6 - - PowerPoint PPT Presentation

software development methodologies
SMART_READER_LITE
LIVE PREVIEW

Software Development Methodologies Lecturer: Raman Ramsin Lecture 6 - - PowerPoint PPT Presentation

Software Development Methodologies Lecturer: Raman Ramsin Lecture 6 Integrated Object-Oriented Methodologies: RUP/USDP and EUP Sharif University of Technology Department of Computer Engineering 1 Software Development Methodologies


slide-1
SLIDE 1

Software Development Methodologies

Lecturer: Raman Ramsin Lecture 6

Integrated Object-Oriented Methodologies: RUP/USDP and EUP

Department of Computer Engineering

1

Sharif University of Technology

slide-2
SLIDE 2

Software Development Methodologies – Lecture 6

Rational Unified Process (RUP) Rational Unified Process (RUP)

Initial version officially released in 1998

R i d i i t d d i 2000 d 2003

Revised versions introduced in 2000 and 2003 Developed

at Rational Corporation by the three principal

Developed at Rational Corporation by the three principal

developers of the OMT, Booch and OOSE (Objectory) methodologies: Rumbaugh, Booch and Jacobson

A non-proprietary, somewhat less complex variant called USDP

(Unified Software Development Process) was introduced in ( p ) 1999

Department of Computer Engineering

2

Sharif University of Technology

slide-3
SLIDE 3

Software Development Methodologies – Lecture 6

Rational Unified Process (RUP) Rational Unified Process (RUP)

UML-based Use case driven, a feature inherited from OOSE Iterative incremental with the overall process resembling the Iterative-incremental, with the overall process resembling the

Micro-in-Macro process of the Booch methodology

Covering the full generic lifecycle

Department of Computer Engineering

3

Sharif University of Technology

slide-4
SLIDE 4

Software Development Methodologies – Lecture 6

RUP: Process – Phases

  • Overall development cycle consists of four phases:
  • Inception: defining the scope and objectives of the project, as

well as the business case

  • Elaboration: capturing the crucial requirements, developing and

validating the architecture of the software system and planning validating the architecture of the software system, and planning the remaining phases of the project

  • Construction: implementing the system in an iterative and

incremental fashion based on the architecture developed in the previous phase p p

  • Transition: testing and releasing the system

Department of Computer Engineering

4

Sharif University of Technology

slide-5
SLIDE 5

Software Development Methodologies – Lecture 6

RUP: Process – Iterations and Disciplines p

  • Each phase can be further broken down into iterations
  • An iteration is a complete development loop resulting in a

l f t bl i t t th t release of an executable increment to the system E h it ti i t f i k (di i li )

  • Each iteration consists of nine work areas (disciplines)

performed during the iteration

  • For each discipline, RUP defines sets of:
  • artefacts (work products)
  • artefacts (work products)
  • activities (units of work on the artefacts)
  • roles (responsibilities taken on by development team members)

Department of Computer Engineering

5

Sharif University of Technology

( p y p )

slide-6
SLIDE 6

Software Development Methodologies – Lecture 6

RUP: Process – Disciplines p

1.

Business Modeling: concerned with describing business processes and the i l f b i A B i U C M d l d B i internal structure of a business. A Business Use Case Model and a Business Object Model are developed. R i t M t d ith li iti i i d

2.

Requirements Management: concerned with eliciting, organizing, and documenting requirements. The Use Case Model is produced. A l i d D i d ith ti th hit t d th

3.

Analysis and Design: concerned with creating the architecture and the design of the software system; results in a Design Model and optionally an Analysis Model.

4.

Implementation: concerned with writing and debugging source code, unit testing, and build management. Source code files, executables, and supportive files are produced supportive files are produced.

5.

Test: concerned with integration-, system- and acceptance testing.

Department of Computer Engineering

6

Sharif University of Technology

slide-7
SLIDE 7

Software Development Methodologies – Lecture 6

RUP: Process – Disciplines (Contd.) p ( )

6.

Deployment: concerned with packaging the software, creating installation i t iti d d t ti d th t k d d t k scripts, writing end-user documentation and other tasks needed to make the software available to its end-users. P oject Management conce ned ith p oject planning sched ling and

7.

Project Management: concerned with project planning, scheduling and control.

8

Configuration and Change Management: concerned with version and

8.

Configuration and Change Management: concerned with version- and release management and change-request management.

9

Environment: concerned with adapting the process to the needs of a

9.

Environment: concerned with adapting the process to the needs of a project or an organization, and selecting, introducing and supporting development tools.

Department of Computer Engineering

7

Sharif University of Technology

slide-8
SLIDE 8

Software Development Methodologies – Lecture 6

RUP: Process – Disciplines in Iterations p

Department of Computer Engineering

8

Sharif University of Technology

[Kruchten 2003]

slide-9
SLIDE 9

Software Development Methodologies – Lecture 6

RUP: Process – Disciplines in Iterations and Phases p

Department of Computer Engineering

9

Sharif University of Technology

[Kruchten 2003]

slide-10
SLIDE 10

Software Development Methodologies – Lecture 6

RUP: Process – Inception Phase p

  • Tasks include:

1.

Describe the initial requirements.

2.

Develop and justify the business case for the system.

3.

Determine the scope of the system.

4

Identify the people organizations and external systems that will

4.

Identify the people, organizations, and external systems that will interact with the system.

5

Develop initial risk assessment schedule and estimates

5.

Develop initial risk assessment, schedule, and estimates.

6.

Configure the initial system architecture.

Department of Computer Engineering

10

Sharif University of Technology

slide-11
SLIDE 11

Software Development Methodologies – Lecture 6

RUP: Process – Elaboration Phase

  • Tasks include:

1.

Produce an architectural baseline for the system.

2.

Evolve the requirements model to 80% completion.

3.

Draft a coarse-grained project plan for the construction phase.

4.

Ensure that critical tools, processes, standards, and guidelines have been put in place for the construction phase.

5.

Understand and eliminate high-priority risks of the project.

Department of Computer Engineering

11

Sharif University of Technology

slide-12
SLIDE 12

Software Development Methodologies – Lecture 6

RUP: Process – Construction Phase

  • Tasks include:

1.

Describe the remaining requirements.

2.

Develop the design of the system. p g y

3.

Ensure that the system meets the needs of its users and fits into the organization’s overall system configuration. g y g

4.

Complete component development and testing, including both the software product and its documentation. p

5.

Minimize development costs by optimizing resources.

6.

Achieve adequate quality.

7

Develop useful versions of the system

Department of Computer Engineering

12

Sharif University of Technology

7.

Develop useful versions of the system.

slide-13
SLIDE 13

Software Development Methodologies – Lecture 6

RUP: Process – Transition Phase

  • Tasks include:

1.

Test and validate the complete system.

2.

Integrate the system with existing systems.

3.

Convert legacy databases and systems to support the new release.

4.

Train the users of the new system.

5.

Deploy the new system into production.

Department of Computer Engineering

13

Sharif University of Technology

slide-14
SLIDE 14

Software Development Methodologies – Lecture 6

RUP: Strengths and Weaknesses

  • Strengths
  • Iterative-incremental process

W ll d d

  • Well-documented process
  • Based on functional, behavioural, and structural modeling
  • f the problem domain and the system
  • f the problem domain and the system
  • Traceability supported through use cases

S l (th h ith hi t f i

  • Seamlessness (though with hiccups, e.g. transforming use

cases to sequence diagrams)

  • Architecture centric process (which necessitates early
  • Architecture-centric process (which necessitates early

specification of an architectural blueprint)

Department of Computer Engineering

14

Sharif University of Technology

slide-15
SLIDE 15

Software Development Methodologies – Lecture 6

RUP: Strengths and Weaknesses

  • Strengths (Contd.)
  • Customizability addressed

Ri k b d d l t i d t iti ti th i k

  • Risk-based development, aimed at mitigating the risks

before undertaking the tasks

  • Support for structural behavioural and functional
  • Support for structural, behavioural and functional

modeling at all levels (problem domain to objects; logical to physical) to physical)

  • Rich modeling language (UML), especially in structural

and behavioural modeling features g

  • Support for formalism (through UML/OCL)

Department of Computer Engineering

15

Sharif University of Technology

slide-16
SLIDE 16

Software Development Methodologies – Lecture 6

RUP: Strengths and Weaknesses

  • Weaknesses
  • Very complex process
  • The process is confusing to those involved. The iterative-

p g incremental nature of the process further complicates the issue.

  • Although advertised as customizable, configuring the process is a

formidable task in itself. formidable task in itself.

  • Since the process is very complex, not having a maintenance

phase, on the grounds that it can be performed by iterating the whole process as a cycle is not convincing whole process as a cycle, is not convincing.

  • Prohibitive number of models
  • Strict adherence to UML, which is not necessarily constructive,

especially since UML is not perfect and can exacerbate the model especially since UML is not perfect and can exacerbate the model inconsistency problem.

Department of Computer Engineering

16

Sharif University of Technology

slide-17
SLIDE 17

Software Development Methodologies – Lecture 6

Enterprise Unified Process (EUP) Enterprise Unified Process (EUP)

Introduced by Ambler and Constantine in 2000 as an extended

variant of RUP variant of RUP

A revised and refactored version was introduced in 2005 A revised and refactored version was introduced in 2005 Motivated by the belief that RUP suffers from serious

d b k drawbacks:

RUP does not cover system support and eventual retirement. RUP does not explicitly support organization-wide infrastructure

p y pp g development.

The iterative nature of RUP is both a strength and a weakness, since

the iterative nature of the lifecycle is hard to grasp for many e pe ien ed de elope s experienced developers.

Rational’s approach to developing RUP was initially tools-driven; hence

the resulting process is not sufficient for the needs of developers.

Department of Computer Engineering

17

Sharif University of Technology

slide-18
SLIDE 18

Software Development Methodologies – Lecture 6

Enterprise Unified Process (EUP) Enterprise Unified Process (EUP)

Extends RUP by adding two new phases and two new

di i li f hi h f th b k d i t disciplines, one of which was further broken down into seven disciplines in the 2005 version of the methodology

Extends the activities in some of the old disciplines of RUP Whereas RUP advocates adherence to UML, EUP makes use of

some older modeling notations too; e.g. the use of Data Flow Diagrams for business modeling. g g

EUP stresses that use cases are not enough for modeling the

requirements; consequently use cases in EUP do not have the requirements; consequently, use cases in EUP do not have the pivotal role they have in RUP.

Department of Computer Engineering

18

Sharif University of Technology

slide-19
SLIDE 19

Software Development Methodologies – Lecture 6

EUP: Process – Disciplines in Iterations and Phases p

Department of Computer Engineering

19

Sharif University of Technology

[Ambler et al. 2005]

slide-20
SLIDE 20

Software Development Methodologies – Lecture 6

EUP: Process – Production Phase EUP: Process Production Phase

  • Focus is on keeping the software in production until it is

ith l d ith i (b ti th lif l either replaced with a new version (by executing the lifecycle all over again), or retired and removed.

  • There are no iterations during this phase.
  • Somewhat similar to the maintenance phase in the generic

lifecycle, in that it is mainly concerned with the operation and f h support of the system. Unlike classic maintenance an need fo changing the

  • Unlike classic maintenance, any need for changing the

system (even a bug fix) will result in the reinitiation of the development cycle.

Department of Computer Engineering

20

Sharif University of Technology

p y

slide-21
SLIDE 21

Software Development Methodologies – Lecture 6

EUP: Process – Retirement Phase EUP: Process Retirement Phase

  • Added in 2002 as the sixth phase
  • Focus is on the careful removal of a system from production,

either because it is no longer needed or is being replaced either because it is no longer needed or is being replaced. This typically includes:

  • Identification of the existing system’s coupling to other systems.
  • Redesign and rework of other systems so that they no longer rely on

the system being retired.

  • Transformation of existing legacy data.

g g y

  • Archival of data previously maintained by the system that is no

longer needed by other systems.

  • System integration testing of the remaining systems to ensure that
  • System integration testing of the remaining systems to ensure that

they have not been broken via the retirement of the system in question.

Department of Computer Engineering

21

Sharif University of Technology

slide-22
SLIDE 22

Software Development Methodologies – Lecture 6

EUP: Process – Operations and Support Discipline p pp p

  • Concerned with issues related to operating and supporting
  • Concerned with issues related to operating and supporting

the system

  • Spans several phases, not only the production phase:
  • During the construction phase, and perhaps as early as the

g p , p p y elaboration phase, the development of operations and support plans, documents, and training manuals is initiated.

  • Artefacts are enhanced and perfected during the transition phase
  • Artefacts are enhanced and perfected during the transition phase,

where the discipline will also include the training of the operations and support staff.

  • During the production and retirement phases, the discipline covers

classic maintenance activities.

Department of Computer Engineering

22

Sharif University of Technology

slide-23
SLIDE 23

Software Development Methodologies – Lecture 6

EUP: Process – Enterprise Management Discipline p g p

  • Concerned with the activities required to create, evolve, and

maintain the organization’s cross system artefacts such as: maintain the organization’s cross-system artefacts, such as:

Organization-wide models (requirements and

architecture) architecture)

Software process Standards Guidelines Reusable artefacts

  • Broken down into seven disciplines in the 2005 version of the

th d l methodology

Department of Computer Engineering

23

Sharif University of Technology

slide-24
SLIDE 24

Software Development Methodologies – Lecture 6

EUP: Strengths and Weaknesses

  • Strengths
  • Same benefits as RUP

Add i l l i

  • Addresses enterprise-level issues
  • Maintenance is a phase in its own right.
  • Attention is given to post-mortem activities when retiring

the project (in the form of a new Retirement phase). N t t i tl dh t t UML th d li l

  • Not strictly adherent to UML; other modeling languages

such as DFDs are also used.

Department of Computer Engineering

24

Sharif University of Technology

slide-25
SLIDE 25

Software Development Methodologies – Lecture 6

EUP: Strengths and Weaknesses

  • Weaknesses
  • Like RUP, EUP is
  • very complex
  • very complex
  • encumbered with a prohibitive number of models
  • suffering high potential for model inconsistency
  • confusing as to the process used
  • hard to customize
  • EUP has added further complexity to RUP by adding two
  • EUP has added further complexity to RUP by adding two

new phases and two new disciplines.

  • Adding the maintenance phase is not sufficient, since any

g p , y change needed will result in a restart of the development process.

Department of Computer Engineering

25

Sharif University of Technology

slide-26
SLIDE 26

Software Development Methodologies – Lecture 6

R f References

Kruchten, P., Rational Unified Process: An Introduction, 3rd

ed Addison Wesley 2003

  • ed. Addison-Wesley, 2003.

Ambler, S. W., Nalbone, J., Vizdos, M. J., The Enterprise Ambler, S. W., Nalbone, J., Vizdos, M. J., The Enterprise

Unified Process: Extending the Rational Unified Process. Prentice-Hall, 2005.

Department of Computer Engineering

26

Sharif University of Technology