Software Engineering

1
 Contents
 Basic System Development Life Cycle
 Different approaches and models for System Development:
 Waterfall
 Prototyping
 Spiral
 WIN-WIN Spiral
 Rapid Application Development
 Group Based Approach: Joint Application Development
 Object Oriented methodology

2
 What is a Software?
 Computer programs and associated documentation together
constitute the software.
 A software may be developed for
 A single customer according to his/her specification
 General market i.e generic in nature and to be sold to a range of
different customers through different channels.

3
 Nature of Software Systems
Used in variety of application
 Business domain
 Scientific domain
 Engineering domain
Categories
 Simple or complex
 Internal use within the organization or for public use( railway
reservation system)
 For a single well defined task or for the entire business functions
of an organization (enterprise wide application)
 One location or distributed

4
 Characteristics of a good software
 Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be reliable
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 It should be usable by the user for whom it was designed

5
 Challenges in developing Software
 Effort intensive
 High cost involved (if soln. not successful then entire
investment go waste)
 Long development time
 Changing requirements of the user
 High risk of failure- user acceptance, performance &
maintainability
 Developing a software is quite different from the one-time
programs which we develop, try and throw way.

6
 Successful Software Systems
 Development should be completed
 It should be useful
 It should be usable and
 It must be used

User would find attracted to the solution developed and they

would be keen to use it for the day to day functioning
Cost effective and maintainable (correction, enhancement).
Only those software solutions which are usable, cost effective and
maintainable would be considered successful by the user
7
 What leads to failure
 Ad-hoc approach to software development results in failure
 No planning for development work (milestones are not
defined)
 Poor understanding of user requirements
 Deliverables to users not identified
 No control or review
 Technical incompetency of the developers
 Poor understanding of cost & efforts involved in projects by
the developers & the users (poor project management)

8
 Reasons for failure
 Schedule slippage
 Cost over-runs
 Does not solve the user’s problem
 Poor quality
 Not maintainable

9
 Software Engineering

The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software, that is, the
application of engineering to software.

10
 Applying engineering approach: Process

 Attempting to estimate cost & effort

 Plan & schedule the work
 Involve user in defining the requirements
 Define clear milestones so that once those milestone are
achieved we know how far we have reached and how
much further we have to go.
 Schedule reviews : for control and quality
 Define deliverables
 Plan extensive testing
Put all these in a form of a proper process and use that process as
an engineering approach for software development.
11
  Process: is a collection of activities, actions and tasks that are performed
when some work product is to be created.
 Activity-communication with the stake holders
 Action-architectural design
 Task-unit test
 In SE, a process is not a rigid prescription for how to build computer
s/w.
 It help people to choose the appropriate set of work actions and tasks.

Aim: To deliver the system in time & with sufficient quality.

A process defines who is doing what when and how to reach a certain goal.

12
 Software Process
 While building a software or a system it is important
to go through a series of predictable steps – a road
map that helps you create a timely, high quality
result. The road map that we follow, is called a
‘software process’.
Software Process can be defined as a framework for
the tasks that are required to build high- quality
software.

13
 Software Process is a set of activities and associated results
which lead to the production of a software product.
The total set of activities needed to transform a user’s
requirements into software is termed a software
engineering process.

14
 Software Process
Fundamental Assumption:
Good processes lead to good software
Good processes reduce risk
Good processes enhance visibility

15
 Variety of Software Processes
Software products are very varied...
Therefore, there is no standard process
for all software engineering projects
BUT successful software development
projects all need to address similar issues.
This creates a number of process steps that
must be part of all software projects
16
 System/ Software Development
Life Cycle(SDLC)
SDLC is a framework composed of a sequence of
distinct steps or phases in the development of a
system.

Basic Process Steps in all Software

Development

17
 Preliminary Investigation

Implementation Determination of
& Evaluation System Requirements
SDLC

System Testing Design of system

Development of software

18
 Preliminary Investigation
Request Clarification

Feasibility Study: Studies to determine the advantages or disadvantages,

practicability, or capability of accomplishing a projected plan, study, or
project is known as Feasibility Study.

 Technical : implemented with the available hardware, software and

technical resources
 Economic: benefits of a proposed solution out-weight the cost
 Operational : the proposed solution is desirable within the existing
managerial and organizational framework.

Request Approval

19
 A feasibility study precedes the decision to begin a
project.
What is the scope of the proposed project?
Is the project technically feasible?
What are the projected benefits?
What are the costs, timetable?

A feasibility study leads to a decision: go or no-go.

20
 Feasibility Report: A written document

•For a general audience: client, financial

management,
technical management, etc.
• Short enough that everybody reads it.
• Long enough that no important topics are skipped.
• Details are often included in supporting
documents.
It should be a well written, well presented document.
21
 Determination of System Requirements
Studies the existing system, so that the functionality, procedures, data to be
captured, output reports to be generated can be identified.

Analysts study the requirements and identify

 the features the new system should have,
 information the then system should produce,
 and the operational features such as response time and input and output
methods
 Fact finding techniques
 Questionnaire
 Observation
 Record review
 Sampling
 Interview

22
 The requirements analysis and definition establish the
system's services, constraints and goals by consultation
with users. They are then defined in a manner that is
understandable by both users and development staff.
This phase can be divided into:
 Requirements analysis
 Requirements definition
 Requirements specification
Requirements define the function of the system FROM THE
CLIENT'S VIEWPOINT.

23
 Design of System
 Describes the final system and the process by which it is to be
developed.
 High level design- architectural design ( identifying the modules
and the interfaces)
 Low level design –detailed design ( data structures & algorithms
of the each moddule)
 It is a technical specification which describes
 The output
 The input and
 Processes
 The inter relationship between them with the help of designing
tools

24
 Development of Software (Coding)
Programming
The software design is realized as a set of programs or program
units. (Written specifically, acquired from elsewhere, or
modified.)
 Software acquisition
 The choice depends on -The cost of each option, The time
available

 Documentation of procedures as it is essential to test the

program and carry on maintenance once the application has
been installed

25
 System Testing
 Individual components are tested against specifications.
 The individual program units are integrated and tested
against the design as a complete system.
 System is used experimentally –alpha testing, beta
testing
 Test data are input
 Limited no. of users
 Testing is performed by persons other than those who wrote the
original programs to ensure more complete & unbiased testing
26
and more reliable software
 Acceptance
 The complete system is tested against the
requirements by the client.
 Delivery and release
 The complete system is delivered to the client
and released into production.

27
 Implementation & Evaluation
Theory is turned into practice
 Operation: The system is put into practical use.
 Install the software
 Train users

 Maintenance: Errors and problems are identified and fixed.

 Evolution: The system evolves over time as requirements change, to add
new functions or adapt the technical environment.

 Required since both the organization & the users change and the
environment will be different over weeks and months

28
 Implementation & Evaluation
 Evaluation of the system is performed to identify the
strengths and weakness
 Operational evaluation
 Manner in which the system functions
 Ease of use
 Response time
 Overall reliability
 Level of utilization
 Organizational impact
 Measurement of benefits of the organization
 Financial concerns
 Operational efficiency
 Competitive impact

29
 A Generic Process Framework for SE
Communication
Planning
Modeling
Construction
Deployment

33
 Process Flow
 Describes how the framework activities, and the actions and
the tasks that occur within the framework activity are
organized with respect to sequence and time.

34
 Linear Process Flow

Communication Planning Modeling Construction Deployment

35
 Iterative Process Flow

Communication Planning Modeling Construction Deployment

36
 The feasibility
Iterative Refinement study is
continuous
Concurrent
Activities
Initial
Requirements Version

Outline Intermediate
Design
Description Versions

Implementation Final
Version

37
 Planning Modeling

Communication

Increment
released
Deployment Construction

Evolutionary Process flow

38
 Phased Development
Concept
A simple system with basic functionality is brought quickly
into production (Phase 1).
Subsequent phases are based on experience gained from
users of each previous phase.
Advantages
• Pay-back on investment begins soon.
• Requirement are more clearly understood in developing
subsequent phases

39
 Communication Planning

Time
Modeling

Construction Deployment

Parallel Process flow

40
 SOFTWARE PROCESS MODELS

 A simplified description of a software process

 A development strategy that encompasses the process,

methods and tools to solve actual problems is referred to as a
process model or s/w engineering paradigm

41
 How a process model is chosen?
 Based on
 Nature of the project and application
 Methods and tools to be used
 Controls and deliverables that are required
 Level of customer interaction
 Risk perception
 Understanding & application skill of the s/w engineer
 (Domain knowledge of the s/w developer)

42
 Different Approaches & Models for
System Development
 Waterfall
 Prototyping
 RAD
 Spiral
 WIN –WIN Spiral
 Rational Unified Process

43
 Waterfall Model
 This model is used when the requirements of a problem are
reasonably well understood.
 The waterfall model derives its name due to the cascading effect
from one phase to the other
 This model is sometimes referred to as the linear sequential model
or the classic life cycle
 Is the oldest paradigm for SE.
 It has a systematic, sequential approach to s/w development that
begins with customer specification of requirements and progress
through planning, modelling, construction and deployment
culminating in on-going support for the completed s/w.

44
 Requirements analysis
& definition

System Specification

System & Software Design

Implementation
& Unit testing

Integration
& System testing

Operation
& Maintenance

45
 Phases of Waterfall Model
 The model consist of six distinct stages, namely:
1.In the requirements analysis phase
 (a) The problem is specified along with the desired service
objectives (goals)
 (b) The constraints are identified

2. In the system specification phase the system specification

is produced from the detailed definitions of (a) and (b) above.
 This document should clearly define the product function.

46
 3. In the system and software design phase, the system
specifications are translated into a software representation.
The software engineer at this stage is concerned with:
 The overall system architecture
 Data structure
 Algorithmic detail and
 Interface representations
 The hardware requirements are determined at this stage
along with a picture of the overall system architecture.
 By the end of this stage the software engineer should be
able to identify the relationship between the hardware,
software and the associated interfaces.

47
 4. In the implementation and unit testing
phase the software design is realised as a set of
programs or program units. Unit testing involves
verifying that each unit meets its specifications.
 Testing at this stage focuses on making sure that
errors are identified and that the software meets
its required specification.

48
 5. In the integration and system-testing
phase all the program units are integrated and
tested as a complete system to ensure that the
software requirements have been met. After this
stage the software is delivered to the customer
 Deliverable – project result delivered to the
client for acceptance testing.

49
 6. The maintenance phase is usually the longest stage of
the software. In this phase the software is updated to:
 Meet the changing customer needs
 Adapted to accommodate changes in the external
environment
 Correct errors and oversights previously undetected in
the testing phases
 Enhancing the efficiency of the software
 The feed back loops allow for corrections to be
incorporated into the model.
 For example a problem/update in the design phase
requires a ‘revisit’ to the specifications phase.
Note: When changes are made at any phase, the relevant
documentation should be updated to reflect that change.
50
 When should one choose Waterfall
model?
 Requirement analysis & definition is stable, and unlikely to change
in a significant way during development and in post –
implementation period.

 Software system design is not likely to undergo a change due to

changes in technology, platform and language considered in the
system.

 The system is so well understood by the user that changes are not
expected during the operations and maintenance.

 Examples: Accounting, Payroll

51
 Advantages
 Testing is inherent to every phase of the waterfall model
 It is an enforced disciplined approach
 The process is well- documented (It is documentation driven,
that is, documentation is produced at every stage)
Disadvantages
 Many projects rarely follow its sequential flow.
 This is due to the inherent problems associated with its rigid
format. Namely:
 As the client usually only has a vague idea of exactly what is
required from the software product, this WM has difficulty
accommodating the natural uncertainty that exists at the
beginning of the project.
 The customer only sees a working version of the product after it
has been coded. This may result in disaster if any undetected
problems are precipitated at this stage.

52
 Incremental Model
 Used in situations in which initial software
requirements are reasonably well defined, but
the overall scope of the development effort
prevent a purely linear process.
 Used when there is a compelling need to provide a
limited set of s/w functionality to users quickly and then
refine and expand on that functionality in later software
release.
 Incremental model delivers software in small but usable
pieces called increments.

53
 Incremental development
 System is developed and delivered in increments
after establishing an overall architecture
 Requirements and specifications for each
increment may be developed
 Users may experiment with delivered
increments while others are being developed.
therefore, these serve as a form of prototype
system
54
 Incremental development process

Define system
deliverables

Design system Specify system Build system Validate

architectur e increment increment increment

NO

Deliver final System Validate Integrate

system complete? system increment
YES

55
  The first increment is often called as the
core product.
 Is proposed when requirements and
solutions can be modularized as
independent s/w components, each of
which can be developed by different teams.
 These components are later integrated to
produce the larger s/w system solution.

56
 Rapid Application Development
(RAD) Model

57
 Team 3
Team 2

Team 1

58
 RAD Model

 Rapid Application Development (RAD) is

an incremental software development
process model that emphasises a very short
development cycle [typically 60-90 days].

 The RAD model is a high-speed adaptation

of the waterfall model, where the result of
each cycle a fully functional system.

59
  RAD is used primarily for information systems
applications; the RAD approach encompasses the
following phases:
Business modelling :The Information flow is modeled
The information flow among business functions is modeled
in a way that answers the following questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?

60
 Data modelling
The information flow defined as part of the business-
modeling phase is refined into a set of data objects that
are needed to support the business.
The characteristics (called attributes) of each object are
identified and the relationships between these objects
are defined.
Process modelling
The data objects defined in the data-modeling phase are
transformed to achieve the information flow necessary
to implement a business function.

Processing descriptions are created for adding,

modifying, deleting, or retrieving a data object.

61
 Application generation
Uses fourth generation techniques and tools like VB, VC++ etc rather
than creating software using conventional third generation
programming languages.
The RAD works to reuse existing program components (when
possible) or create reusable components (when necessary).
In all cases, automated tools are used to facilitate construction of the
software.
Testing and turnover
Since the RAD process emphasizes reuse, many of the program
components have already been tested. This minimizes the testing
and development time.
When RAD can be employed?
If a business application can be modularized so that each major
function can be completed within the development cycle.
In this case, each team can be assigned a model, which is then
integrated to form a whole.

62
 Disadvantages
 For Large (but scalable) projects, RAD requires sufficient
resources to create the right number of RAD teams.
 RAD projects will fail if there is no commitment by the
developers or the clients to ‘rapid-fire’ activities necessary to
get a system complete in a much-abbreviated time frame.
 If a system cannot be properly modularized, building
components for RAD will be problematic
 RAD is not appropriate when technical risks are high, e.g.
this occurs when a new application makes heavy use of new
technology, interface to other systems are an issue.
 Difficult to scale to large projects.

63
 Prototyping
 Prototyping is an engineering inspired approach to systems
development.
 Is a process model that is explicitly designed to accommodate a
product that evolves over time.
 Emphasis on constructing a working model of the system as
quickly as possible.
 The model is called ‘prototype’
 Information gained through its use by user can be given as
feedback immediately and a new prototype can be prepared to get
still more information. This process can be iterated many times
until satisfactory design is evolved.

64
 Prototyping process

Establish Define
Develop Evaluate
prototype prototype
prototype prototype
objectives functionality

Prototyping Outline Executable Evaluation

plan definition prototype report

65
 Characteristics of a prototype

 The prototype is a live, working application

 The purpose of prototyping is to test out
assumptions made by analysts and users about
required system features
 Prototypes are created quickly
 Prototypes evolve through an iterative process
 Prototypes are relatively inexpensive to build

66
 Approaches to prototyping

Evolutionary Delivered
prototyping system
Outline
Requirements
Throw-away Executable Prototype +
Prototyping System Specification

67
 Prototyping in the software process
 Evolutionary prototyping
 An approach to system development where an initial prototype is
produced and refined through a number of stages to the final system

 Throw-away prototyping
 A prototype which is usually a practical implementation of the
system is produced to help discover requirements problems and
then discarded. The system is then developed using some other
development process

68
 Evolutionary prototyping
 Must be used for systems where the specification cannot be
developed in advance e.g. AI systems

 Based on techniques which allow rapid system iterations

 Verification is impossible as there is no specification.
Validation means demonstrating the adequacy of the system

69
 Evolutionary prototyping

Develop abstract Build prototype Use prototype

specification system system

Deliver YES System

system adequate?

70
 Evolutionary prototyping advantages
 Accelerated delivery of the system
 Rapid delivery and deployment are sometimes
more important than functionality or long-term
software maintainability
 User engagement with the system
 Not only is the system more likely to meet user
requirements, they are more likely to commit
to the use of the system

71
 Evolutionary prototyping
 The system is developed as a series of
increments that are delivered to the
customer
 Techniques for rapid system development
are used such as CASE tools and 4GLs
 User interfaces are usually developed using
a GUI development toolkit

72
 Throw-away prototyping
 Used to reduce requirements risk
 The prototype is developed from an initial
specification, delivered for experiment then discarded
 The throw-away prototype should NOT be considered
as a final system
 Some system characteristics may have been left out
 There is no specification for long-term maintenance
 The system will be poorly structured and difficult to
maintain
73
 Throw-away prototyping

Outline Develop Evaluate Specify

requirements prototype prototype system

Reusable
components

Delivered
Develop Validate software
software system system

74
 Prototyping languages

Language Type Appl ication do main

Smalltalk Object-oriented Interactive systems
Java Object-oriented Interactive systems
Prolog Logic Symb olic processing
Lisp List-based Symb olic processing

75
 When is Prototype useful?

 The requirements are difficult to specify in advance

 The requirements may change significantly during development.
 A totally novel system is proposed (it is impossible to get it right
the first time)
 The ideas and assumptions about a new system are to be
experimented quickly by the user at least cost.
 When
 Exact technical solution is unclear to the development team (the
efficiency of an algorithm, adaptability of an OS)
 Unsure about the form that human-machine interaction should take
(to illustrate the input data formats, reports, and the interactive
dialogues tot the customer)

76
 Advantages
 Faster development
 Easier for end users to learn/use
 Fewer changes needed after implementation
 End-user involvement
 Users know what to expect at implementation
 User/analyst communication enhanced
 User requirements easier to determine
 Development costs reduced

77
 Spiral Model or Boehm’s Model
 The spiral model, combines the iterative nature of
prototyping with the controlled and systematic aspects of the
waterfall model, therein providing the potential for rapid
development of incremental versions of the software.

 Is a risk driven process model

 The diagrammatic representation of this model looks like a
spiral with many loops
 The exact number of loops is not fixed and varies from
project to project.

78
79
  Distinguishing Features
 Cyclic approach ( for incrementally growing system’s degree
of definition & implementation while decreasing its degree of
risk)
 Anchor point milestones (for ensuring stakeholder’s
commitment to feasible & mutually satisfactory system
solutions)
 In this model the software is developed in a series of
incremental releases with the early stages being either paper
models or prototypes. Later iterations become increasingly
more complete versions of the product.

80
 Initial project RA based on initial req.
planning

Prdt.
Initial req. Specification
gathering

Engineered
system

Radius
81
  The‘6-task region’ model.
 These regions are:
1.The customer communication task – to establish effective
communication between developer and customer.
2. The planning task – to define resources, time lines and other
project related information.( it determines the objectives)
3.The risk analysis task – to assess both technical and management
risks. (alternatives are evaluated)
 The main purpose of risk management is to identify and handle
the uncommon causes of project variation.
 examples: diminished quality of the end product, increased costs,
delayed completion, or outright project failure.
 Risk can be
 Internal, within the control of project manager, and
 External, outside the control of project manager.

82
 4.The engineering task – to build one or
more representations of the application.
5. The construction and release task – to
construct, test, install and provide user
support (e.g., documentation and training).
6. The customer evaluation task – to obtain
customer feedback based on the evaluation
of the software representation created
during the engineering stage and
implemented during the install stage.

83
  The evolutionary process begins at the
centre position and moves in a clockwise
direction. Each traversal of the spiral
typically results in a deliverable. For
example, the first and second spiral
traversals may result in the production of a
product specification and a prototype,
respectively. Subsequent traversals may then
produce more sophisticated versions of the
software.
84
  An important distinction between the spiral model and other
software models is the explicit consideration of risk.
 There are no fixed phases such as specification or design
phases in the model and it encompasses other process
models. For example, prototyping may be used in one spiral
to resolve requirement uncertainties and hence reduce risks.
This may then be followed by a conventional waterfall
development
 Other process models end when software is delivered but the
spiral model can be adapted to apply throughout the life of
the computer software

85
 Advantages of the Spiral Model
 The spiral model is a realistic approach to the development of large-
scale software products because the software evolves as the process
progresses. In addition, the developer and the client better understand
and react to risks at each evolutionary level.
 The model uses prototyping as a risk reduction mechanism and allows
for the development of prototypes at any stage of the evolutionary
development.
 It maintains a systematic stepwise approach, like the classic life cycle
model, but incorporates it into an iterative framework that more
reflect the real world.
 If employed correctly, this model should reduce risks before they
become problematic, as consideration of technical risks are considered
at all stages.

86
 Disadvantages of the Spiral
Model
 Demands considerable risk-assessment
expertise
 it is time-consuming

87
88
 The WINWIN Spiral Model

 This is an adaptation of the spiral model

 Emphasis :on the involvement of the client in a negotiation
process at the genesis of the product development.
 In ideal situation, the developer would simply ask the
customer what is required and the customer would provide
sufficient detail to proceed.
 Unfortunately this rarely happens and significant negotiations
between both parties are required to balance functionality,
performance, etc… with cost and time-to-market
considerations.

89
  The model, derives its name from the objective of these
negotiations, i.e. “win-win”.
 The client gets the product that satisfies majority of his/her
needs, and the developer wins by working to realistic and
achievable budgets and deadlines.
 To achieve this objective the model defines a set of
negotiation activities at the beginning of each pass around the
spiral.

90
  Rather than a single customer communication activity the
following activities are defined:
 Identification of the system stakeholders. That is the people in
the organisation that have direct business interest in the product
to be built and will be rewarded for a successful outcome or
criticised if the effort fails (e.g. user, customer, developer,
maintainer, interfacer, etc.).
 Determination of the stake holder's “win conditions”
 Negotiations of the stake holder's win conditions to reconcile
them into a set of win-win conditions for all concerned
(including the software project team).

91
92
 Typical Cycle of the Win- Win Spiral

 Identify the system or subsystem's key stakeholders.

 Identify the stakeholders' win conditions for the system or subsystem.

 Negotiate win-win reconciliations of the stakeholders' win conditions.

 Elaborate the system or subsystem's product and process objectives, constraints, and
alternatives.

 Evaluate the alternatives with respect to the objectives and constraints. Identify an
resolve major sources of product and process risk.

 Elaborate the definition of the product and process.

 Plan the next cycle, and update the life-cycle plan, including partition of the system into
subsystems to be addressed in parallel cycles. This can include a plan to terminate the
project if it is too risky or infeasible. Secure the management's commitment to proceed
as planned.

93
  In addition to the early emphasis placed on the win-win condition, the
model also introduces three process milestones (anchor points),
which help establish the completion of one cycle around the spiral and
provide the decision milestones before the software project proceeds.
These are,
 1. Life Cycle Objectives (LCO) – Defines a set of objectives for each
major software activity (e.g. a set of objectives associated with the
definition of top level product requirements)
 2. Life Cycle Architecture (LCA) – Establishes the objectives that
must be met as the as the software architecture is defined.
 3. Initial Operational Capability (IOC) – represents a set of
objectives associated with the preparation of the software for installation
/ distribution, site preparations prior to installations, and assistance
required by all parties that will use or support the software.

94
 Advantages:
 Faster software production facilitated through
collaborative involvement of the relevant
stakeholders.

95
 Rational Unified Process
(RUP)

96
 Rational Unified Process (RUP)

 The Rational Unified Process (RUP) is a Software

Engineering Process.
 RUP is one such life cycle approach that is especially
well suited to the UML.
 Goal of RUP:
 Is to enable the production of highest quality s/w that
meet end-users needs within predictable schedules
and budgets.
 RUP is an Iterative Process.

97
 History of RUP
 The Rational Unified Process (RUP) is a software
process product, originally developed by Rational
Software, which was acquired by IBM in February
2003.

Best practices for the development of Rational’s

Product :
 Develop iteratively, with risk as the primary iteration
driver
 Manage requirements
 Use a component-based architecture
 Model software visually
 Continuously verify quality
98  Control changes
 Rational Unified Process

Manage Requirements

Develop Verify Use

Model Component
Iteratively Visually Quality
Architectures

Control Changes

99
 Characteristics of RUP
 Give emphasize on Models rather than Paper
documents:
RUP emphasize on Models rather than Paper
documents Because to minimize the overhead
associated with generating and maintaining
documents and to maximize the relevant information
content.

100
 WHY Modeling?
 Why Modeling?
 To analyze the desired structure and behavior.
 To visualize and control the system architecture.
 To better understand the system for simplification
and reuse.
 To manage the risks.

101
 Characteristics of RUP
(Continued…)
 Architecture-centric:
Development under the RUP is Architecture-Centric.
 The process focuses on the early development and
baselining of a s/w architecture. It also minimizes
work and increases the probability of component
reuse.

 Use case driven:

 Development activities under the RUP are Use case
driven. The notions of Use case are used to align the
process from requirements captured or gathered.

102
 Characteristics of RUP (Continued…)
Supports Object oriented techniques:
 RUP are based on the concepts of objects and classes and
relationships among them.

It is Configurable process:
 Contained in the RUP is guidance about how to configure
the process to suit the needs of the organization.

Risk Management and Quality Control

 An iterative process lets developers moderate risks earlier
than a sequential process where the final integration is the
only time that risks are discovered or addressed
 The system has been tested several times, improving the
quality of testing.
103
 Development Cycle
 Development Cycle
 Each cycle results in a new release of the system, and
each is a product ready for delivery. This product has
to accommodate the specified needs.
I E C T
10% 30% 50% 10%

 Typical time line for initial development cycles

 Initial development cycle – a software product is
created
 Evolution cycles – a product evolves into its next
generation by repetition of the sequences of inception,
elaboration, construction, and transition phases.

104
 Phases of RUP

106
 Phases of RUP
1. Inception:
 Establish the business case for the project and delimit
the project’s scope.
 Business Case includes-
 Success Criteria
 Risk Assessment
 Estimates of resources needed
 (Focus is on Requirements gathering)
 At the end of the inception phase, you examine the
life cycle objectives of the project.

107
 Phases of RUP
 2.Elaboration:
 Establish a project plan and sound architecture.
 The goals of the elaboration are to analyze the
problem domain, develop the project plan, and
eliminate the highest risk elements of the project.
 At the end of the elaboration phase, you examine the
detailed system objectives, scope and the resolution of
major risks, and decide whether to proceed with
construction.
 (Focus is on Analysis and design)

108
 Phases of RUP
3.Construction: Grow the System.
 This implies describing the remaining requirements
and completing the implementation and test of s/w.
 At the end of the construction phase, you decide if the
software and users are all ready to go operational.
 (Implementation is the central activity)

109
 Phases of RUP
4.Transition: Supply the system to its end users.
 Here, The software is deploy to the user community.
 At the end of the transition, you decide whether the
life cycle objectives of the project have been met and if
you should start another development cycle.
 (Focus is on Deployment)

 Inception and Elaboration encompasses the

engineering activities of the development life
cycle.
 Construction and Transition constitute its
production.
110
 In Short…
 The first stage or inception centers on assessing
needs, requirements, feasibility of the project.
 The second step or elaboration measures the
architecture of the system's appropriateness
based on the project needs.
 The third stage is the construction phase, wherein the
actual software system is made, by developing
components and features. This phase also
includes the first release of the developed
software.
 The final stage is that of transition, and marks the
end of the development cycle, if all objectives
111
are met.
 Process Workflows
 Consist of Nine Workflows
 1. Business Modeling: Describe the
structures and dynamics of the organization.
 2. Requirements: Describe the use-case
based method for elicitation requirements.
 3. Analysis and design: Describe the multiple
architecture views.
 4. Implementation: Takes into account
software development , unit test and
integration.
 5. Test: Describe the test cases, procedures
and defect-tracking metrics.

112
 Process Workflows
 Development: Covers the deliverable system
configuration.
 Configuration Managements: Control changes to
and maintains the integrity of a project’s
artifacts.
 Project Management: Describe the various
strategies of working with an iterative
process.

113
 Artifacts
 Each process workflow is a set of correlated artifacts
and activities.
 An Artifact is some document, report or executable
that is produces or manipulated.
 Each RUP has associated artifacts, either required as
input or generated as an output.
 Artifacts are associated with certain of these
workflows.
 Eg. The Use case model generated during
requirements capture is realized by the
design model from analysis and design
process, implemented by implementation model
from implementation process and verified by
the test model from test process.
114
 Model
 Models are the most important kind of artifact in the
RUP.
 A Model is a simplification of reality created to better
understand the system being created.
 A large part of RUP focuses on modeling. Models
help developers understand and shape both the
problem and the solution.
 The model is not the reality, but the best models are
the ones that stick very close to reality.

115
 Model
 There are nine models that used for visualizing,
specifying, constructing and documenting software
system.
 1. Business Model: Establish an abstraction of the
organization.
 2. Domain model: Establish the context of the system.
 3. Use case model: Establishes the system’s functional
requirements.
 4. Analysis model (optional): Establishes an idea
design.
 5. Design model: Establishes the vocabulary of the
problem and its solution.

116
 Model
 6. Process model (optional): Establish the system’s
concurrency and synchronization mechanism.
 7. Deployment model: Establishes the hardware
topology on which the system is executed.
 8. Implementation model: Establishes the part used
to assemble and release the physical system.
 9. Test model: Establishes the path by which the
system is validated and verified.

117