Software Engineering

Chapter 1: Introduction
 What is Software Engineering?
 Software engineering an engineering approach to develop a
quality software
 Software engineering is technological and managerial discipline
concerned with systematic production and maintenance of
software
 Software engineering is a discipline which can be described as the
combination of techniques of engineering and all aspects of
software development.
 Software engineering is an engineering discipline whose focus is
the cost effective development of high-quality software system
 Two Orthogonal view of software.
A software development methodology is a series of
processes like System Analysis, Modeling, Design,
Implementation, Testing and Maintenance that leads to
the development of an application.

There are two different, yet complementary ways to

view software construction:
• We can focus primarily on Functions Or primarily on
the data
 Introduction Cont.
1) Traditional Technique – focuses on data or functions.

2) Object Oriented methodologies – focuses on objects that combines

data and functionality. Object oriented systems development develop

software by building objects that can be easily replaced, modified and

reused.

Objects has attribute (data) and methods (functions). Object Oriented systems
are

• Easier to adapt to changes,

• Easier to maintain ,

• Promote greater design and code reuse

 Software Process
 A software process is a set of activities, methods, practices, and
transformations that people use to develop a software product
and maintain software and the associated products (e.g., project
plans, design documents, code, test cases, and user manuals)

 These activities may involve the development of software from

scratch or New business software is now often developed by
extending and modifying existing systems or by configuring and
integrating off-the-shelf software or system components.

 There are many different types of software systems, and there is

no universal software engineering method that is applicable to all
of them.
 Software Process
The process used in different companies depends on the type of
software being developed, the requirements of the software
customer, and the skills of the people writing the software.

Fig: Simple Process

 Process activities
 A structured set of activities required to develop a software system.
Software Development Life Cycle (SDLC) is a process used by the
software industry to design, develop and test high quality
software.
 It consists of a detailed plan describing how to develop, maintain,
replace and alter or enhance specific software.
 The four basic process activities, they are organized differently in
all different development processes.
1. Software specification:
2. Software design and implementation
3. Software validation
4. Software evolution
 The SDLC aims to produce a high-quality software that meets or
exceeds customer expectations, reaches completion within times
Software Development Life
Cycle (SDLC)
Software Development Life Cycle
(SDLC)
◦ It is a systematic approach to develop software.
◦ It creates a structure for the developer to design, create and
deliver high quality software according to the requirements of
customer or end user.
◦ It also provides a methodology for improving the quality of the
desired product.
◦ The purpose of SDLC is to provide help in producing a product
that is cost efficient and of high quality.
 1. Planning

SDLC 7. Maintenance 2. Analysis

6. Deployment 3. Design

5. Testing 4. Implementation
 1. P lanning
• ◦ During the planning phase, the objective of the project is
determined and the requirements to produce the product are
considered.
• ◦ An estimate of resources, such as personnel and costs, is prepared,
along with a concept for the new product.
• ◦ All of the information is analyzed to see if there is an alternative
solution to creating a new product.
• ◦ If there is no other viable alternative, the information is assembled
into a project plan and presented to management for approval.
 2. Analysis
• ◦ During the analysis stage the project team determines the end-user
requirements.
• ◦ Often this is done with the assistance of client focus groups, which provide an
explanation of their needs and what their expectations are for the finished
product and how it will perform.
• ◦ The project team documents all of the user requirements and gets a sign-off
from the client and management to move forward with system design.
•◦ The specific requirements of the program are defined.
 …Analysis
◦ This step includes collecting maximum information from the client about the
desired product.

◦ All details and specifications of the product must be discussed with the
customer.

◦ The development team analyses the requirements keeping in view the design
and coding of the software.
◦ The requirements so gathered are then analyzed for their validity and
possibility of incorporating them into the software system.

◦ The aim of requirement analysis is to capture the detail of each requirement so

that everyone understands how each requirement is to be worked.
 3. Design

◦ In this phase, program developer analyses whether software

can be prepared to fulfill all the requirements of the end user.

◦ After that best design approach is selected for the product.

The how …
◦ The developer selects the program language like Java, Oracle etc.
which will be best suited for the software.

◦ It is also like the engineering representation of the product to be

built.
 4. Implementation
◦ It means translating the design into a computer readable language.

◦ Development team does the actual coding based on designed

software and writes unit tests for each component to test the
new codes written by them.
◦ The developer may show the work done to the business
analysts and the modification or enhancements may be
required.

◦ This is the longest phase of SDLC.

 5. Testing

This is the last phase of SDLC before the software is delivered to the
customer.

The job of test team is to test the system against the requirements.

The aim of tester is to find out the gaps or defects within the system
and also to verify that the software works as expected according to
the requirements.

It includes Unit testing, Integration testing and System testing.

 6. Deployment
Once the product is tested and ready to deploy, it is released to consumers to
use.

The size of the project will determine the complexity of the deployment.

The users can be trained on, or aided with the documentation on how to
operate the software.

A small round of testing is also performed on production to make sure of

any environmental issues and any impact of new release.

Once the functional and non-functional testing is done, the product is

deployed in the customer environment or released into the market.
 7. Maintenance
This step occurs after installation, and involves making modifications to the
system or an individual component to alter attributes or improve performance.

These modifications arise either due to change requests initiated by the

customer, or defects uncovered during live use of the system.

It is required for the following thee reasons:

◦ Bug fixing – bugs arrived due to some untested scenarios.
◦ Upgrade – upgrading the application to the newer versions of the software.
◦ Enhancement - adding some new features into the existing software.

Client is provided with regular maintenance and support for the

developed software.
Characteristics of a good process
 Should be precisely defined- no ambiguity about what
is to be done, when, how, etc
 It must be predictable- can be repeated in other project
with confidence about its outcome.
 Expectable with respect to effort, cost

 It support testing and maintainability

 Ensure early detection of and removal of faults
 It should facilitate monitoring and improvement
Software Process Models
 What is a Software Process Model?
 A software or system process model is a description of the
sequence of activities carried out in SE project, and the relative
order of these activities.
 Process models prescribe a distinct set of activities, actions, tasks,
milestones, and work products required to engineer high quality
software.
 Process models are not perfect, but provide roadmap for software
engineering work.
 Software models provide stability, control, and organization to a
process that if not managed can easily get out of control
 Software process models are adapted to meet the needs of
software engineers and managers for a specific project.
 Why model software?
 Software is getting larger, not smaller 5.0 ~ 40 million lines of code,
a single programmer cannot manage this amount of code in its
entirety.
 Codes are often not directly understandable by developers who did
not participate in the development.
 The development team must identify a suitable life cycle model for the
particular project and then adhere to it. Without using of a particular life
cycle model the development of a software product would not be in a
systematic and disciplined manner.
 When a software product is being developed by a team there must be a
clear understanding among team members about when and what to do.
Otherwise it would lead to chaos and project failure.
 Without software life cycle models it becomes difficult for software
project managers to monitor the progress of the project.
 We need simpler representations for complex systems,
Modelling is a mean for dealing with complexity.
 SDLCs
 A Software Process Model (also called SDLC) is a
descriptive
and diagrammatic representation of the software life cycle.

 Software Development Life Cycle, SDLC for short, is a well-

defined, structured sequence of stages in software engineering to
develop the intended software product.

 A life cycle model represents all the activities required to make a

software product transit through its life cycle phases. It also
captures the order in which these activities are to be undertaken.

 SDLC provides set of activities and their relationships to each other

to support the development of a software system efficiently.
 Types of Software Process Models
A software development methodology or system development
methodology in software engineering is a framework that is used to
structure, plan, and control the process of developing an
information system. Every software development methodology
framework acts as a basis for applying specific approaches to
develop and maintain software.

A software development paradigm has its own set of tools,

methods, and procedures, which are expressed clearly and defines
software development life cycle.
 A software development paradigms or process models or
framework are defined as follows: concentrate on different aspects
of the lifecycle.
 Types of Software Process Models
Several software development approaches have been used since the
origin of information technology. These are
1. Traditional Process Model
Waterfall model
V-model
2. Evolutionary model
Prototyping model
Spiral model
3. Incremental Model
 Iterative model
 RAD model
4. Object Oriented Process Model
Unified process (UP) model
5. Agile methods and others
 Waterfall Model
 The waterfall model is a sequential design process, used in
software development processes, in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases.
 In a Waterfall model, each phase must be completed before the
next phase can begin and there is no overlapping in the phases.
 It is applicable for well-defined requirements.
 Waterfall Model

• Requirements – defines needed

information, function, behavior,
performance and interfaces.

• Design – data structures, software

architecture, interface
representations, algorithmic details.

• Implementation – source code,

database, user documentation,
testing.
Waterfall Strengths

Easy to understand, easy to use

Provides structure to inexperienced staff

Milestones are well understood

Sets requirements stability

Good for management control (plan, staff, track)

Works well when quality is more important than cost or

schedule
 Waterfall Deficiencies

All requirements must be known upfront

Deliverables created for each phase are considered frozen –

inhibits flexibility
Can give a false impression of progress

Does not reflect problem-solving nature of software

development – iterations of phases
Little opportunity for customer to preview the system (until it
may be too late)
When to use the Waterfall Model

Requirements are very well known

Product definition is stable

Technology is understood

New version of an existing product

Porting an existing product to a new platform.

V-Shaped SDLC Model

A variant of the Waterfall that

emphasizes the verification and
validation of the product.
Testing of the product is planned in
parallel with a corresponding phase
of development
This means that for every single
phase in the development cycle
there is a directly associated testing
phase.
V-Shaped Steps

• Project and Requirements Planning – • Production, operation and maintenance –

allocate resources provide for enhancement and corrections

• Product Requirements and • System and acceptance testing – check the

Specification Analysis – complete entire software system in its environment

specification of the software system • Integration and Testing – check that modules

interconnect correctly
• Architecture or High-Level Design –
• Unit testing – check that each module acts as
defines how software functions fulfill
expected
the design

• Detailed Design – develop algorithms

• Coding – transform algorithms into software
for each architectural component
V-Shaped Strengths

Emphasize planning for verification and validation of the product in early stages
of product development

Each deliverable must be testable

Project management can track progress by milestones

Easy to use

Higher chance of success over the waterfall model due to the early
development of test plans during the life cycle.

Works well forsmall projects where requirements are easily

understood.
V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in requirements
• Does not contain risk analysis activities
When to use the V-Shaped Model
• Excellent choice for systems requiring high reliability – hospital
patient control applications
• All requirements are known up-front
• When it can be modified to handle changing requirements beyond
analysis phase
• Solution and technology are known
 Evolutionary Models
 Evolutionary model is suitable for large problems:
 Can be decomposed into a set of
modulesthat can be incrementally implemented,
 Incremental delivery of the system is
acceptable to the customer.

 There are two types are introduced, namely

 Prototyping model
 Spiral model
2.1. Evolutionary Models: The
Prototyping
Software prototyping typically simulates only a few aspects of the features of
the eventual program
Prototyping is used to allow the users evaluate developer proposals and try
them out before implementation.
A preliminary project plan is developed

An partial high-level paper model is created

The model is source for a partial requirements specification

A prototype is built with basic and critical attributes

The designer demonstrates the prototype, the user evaluates for problems and
suggests improvements.
This loop continues until the user is satisfied
Evolutionary Models: The Prototyping
Evolutionary Models: The Prototyping
Strengths
Customers can “see” the system requirements as they are being gathered

Developers learn from customers

A more accurate end product

Allows for flexible design and development

Steady, visible signs of progress produced

Interaction with the prototype stimulates awareness of additional needed

functionality
Reduces time and cost as the defects can be detected much earlier.

Quicker user feedback is available leading to better solutions.

Missing functionality can be identified easily.

Evolutionary: Prototyping Weaknesses

• Bad reputation for “quick-and-dirty” methods

• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
When to use Evolutionary: Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-
oriented development.
Evolutionary Model: Spiral Model
Evolutionary Model: Spiral Model
•It is a combination of Iterative Model and Waterfall Model with very high emphasis
on risk analysis.
Couples iterative nature of prototyping with the controlled and systematic aspects of the linear
sequential model

It provide potential for rapid development of increasingly more complete version of the software.

Using spiral, software developed in as series of evolutionary release.

Early iteration, release might be on paper or prototype.
Later iteration, more complete version of software.

Divided into framework activities (C,P,M,C,D). Each activity represent one segment.

Evolutionary process begins in a clockwise direction, beginning at the center risk.

First circuit around the spiral might result in development of a product specification. Subsequently,
develop a prototype and then progressively more sophisticated version of software.

Unlike other process models that end when software is delivered.

It can be adapted to apply throughout the life of software.

Evolutionary Model: Spiral Model
 Evolutionary Model: Spiral Model
Concept Development Project:
• Start at the core and continues for multiple iterations until it is
complete.
• If concept is developed into an actual product, the process
proceeds outward on the spiral.
New Product Development Project:
• New product will evolve through a number of iterations around
the spiral.
• Later, a circuit around spiral might be used to represent a
“Product Enhancement Project”
Product Enhancement Project:
• There are times when process is dormant or software team not
developing new things but change is initiated, process start at
appropriate entry point.
 Spiral Model - Pros and Cons
 The advantages of the Spiral SDLC Model are as follows −
 Allows elements of the product to be added in, when they
become available or known
 Takes a very strict management to complete
 Schedule and cost is more realistic.
 Changing requirements can be accommodated.
 Suitable for very high risk.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky
parts can be developed earlier which helps in better risk
management.
 Spiral Model - Pros and Cons
 The disadvantages of the Spiral SDLC Model are as follows −
 Time spent for evaluating risks too large, for small or low-
risk projects
 Management is more complex.
 End of the project may not be known early.
 Not suitable for small or low risk projects and
could be expensive for small projects.
 Process is complex
 Spiral may go on indefinitely.
 Time spent planning, resetting objectives,
doing risk analysis and prototyping may be
excessive/unnecessary
 Large number of intermediate stages requires
excessive documentation.
 Developers must be reassigned during non-
development phase activities
 3. Incremental Model
 The following are models used in Incremental model
1. Iterative model
2. RAD model
 Iterative or Incremental Model
 It is a method of software development where the product is designed,
implemented and tested incrementally. Little more is added each time
until the product is finished.
 It involves both development and maintenance
 Cycles are divided up into smaller, more easily managed modules.
 The incremental model prioritizes requirements of the system and then
implements them in groups.
 The first module is often a core product where the basic requirements
are addressed, and supplementary features are added in the next
increments.
 It is a “multi-waterfall” model.
Iterative or Incremental Model
Incremental Model Strengths
Develop high-risk or major functions first

Each release delivers an operational product

Customer can respond to each build

Uses “divide and conquer” breakdown of tasks

Lowers initial delivery cost

Initial product delivery is faster

Customers get important functionality early

Risk of changing requirements is reduced

Incremental Model Weaknesses

Requires good planning and design

Requires early definition of a complete and fully functional system to
allow for the definition of increments
Well-defined module interfaces are required (some will be developed
long before others)
Total cost of the complete system is not lower
 When to use the Incremental Model
Risk, funding, schedule, program complexity, or need
for early realization of benefits.
Most of the requirements are known up-front but are
expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development
schedules
On a project with new technology
 3.2. RAD Model
 It uses minimal planning in favor of rapid prototyping.

 The functional modules are developed simultaneously as

prototypes and are integrated to make the complete product for
faster product delivery.
 The developments are time boxed, delivered and then
assembled into a working prototype.

 The customer gets early visibility in the software and can provide
feedback on design, delivery, and other requirements.
RAD Model
 RAD Model - Pros and Cons
 RAD model enables rapid delivery as it reduces the overall
development time due to the reusability of the components and
parallel development.
 The advantages of the RAD Model are as follows −
 Reusability of components makes or speeds up the development and
reduces the time that it needs for developing a product.
The modularized way of crafting each function within the system
makes the development task easier.
 Large projects can be done easily through the RAD model
 RAD Model - Pros and Cons
 The disadvantages of the RAD Model are as follows −
A proper time-frame should have to be maintained for both end
customer as well as developers for completing the system.
 RAD model-based software development fails because of a lack
of commitment and dedication.
 A slight complexity in the modularizing in RAD model can lead to
failure of the entire project.
 RAD is based on Object oriented approach and if it is difficult to
modularize the project the RAD may not work well.
5. Agile methods
 Businesses now operate in a global, rapidly changing environment.
Change in technologies, markets undergo radical shifts, users
discover new things to do with their money and time.
 To survive in these uncertain times, developers, as well as business
owners, needed a more flexible approach to building software.
 They have to respond to new opportunities and markets, changing
economic conditions and the emergence of competing products and
services.
 Rapid software development and delivery is therefore the most
critical requirement for most business systems.
 Rapid software development became known as agile development
or agile methods. The Agile software development model was
mainly intended for helping developers build a project which can
adapt to transforming requests quickly.
Agile methods
Agile methods
 An agile philosophy for software engineering stresses four
key issues:
1. The importance of self-organizing teams that have control over the
work they perform:
2. Communication and collaboration between team members and
between practitioners and their customers,
3. A recognition that change represents an opportunity; and
4. An emphasis on rapid delivery of software that satisfies the
customer (an iterative approach) .
 These method allows the development team to focus on the software
itself rather than on its design and documentation.
 Developers start off with a simplistic project design, and then begin to
work on small modules.
 Agile development Techniques
1. User stories
 Software requirements always handle these
change. Toagile methods do not have a separate
changes,
requirements engineering activity. Rather, they integrate
requirements elicitation with development. To make this
easier, the idea of “user stories” was developed where a
user story is a scenario of use that might be experienced
by a system user.
2. Refactoring
 Refactoring means that the programming team look for
possible improvements to the software and implements
them immediately.
 Agile development techniques
3. Test-first development
 Testing is automated and is central to the development
process, and development cannot proceed until all tests
have been successfully executed.

4. Pair programming
 It supports the idea of collective ownership and responsibility
for the system. The team has collective responsibility for
resolving these problems.
 It encourages refactoring to improve the software structure.
 Agile method applicability
 Agile methods have been particularly successful for two
kinds of system development.

1. Product development where a software company is developing

a small or medium-sized product for sale. Virtually all
software products and apps are now developed using an agile
approach.

2. Custom system development within an organization, where

there is a clear commitment from the customer to become
involved in the development process and where there are few
external stakeholders and regulations that affect the software.
 Agile methods benefits
 Involves pair programming which reduces the number of errors in the
development or coding phase and is better than a single programmer
doing all the hard part.
 This model trims down the entire development time of any project.
 Frequent releases and feedback collection.
 After each iteration, customers and stakeholders of the project can
get a fair idea the updated software that is being developed by the
agile model. So, any change in the system can be addressed at any
iteration.
 Agile methods problems
 Agile methods are designed for small co-located teams, yet
much
software development now involves worldwide distributed teams.
 Agile methods are most appropriate for new software development
rather than for software maintenance.
 It can be difficult to keep the interest of customers who are involved
in the process.
 Team members may be unsuited to the intense involvement
that characterizes agile methods.
 Prioritizing changes can be difficult where there are
multiple
stakeholders.
 Maintaining simplicity requires extra work.
 The informality of agile development is incompatible with the legal
approach to contract definition that is commonly used in large
 Object oriented system development methodology
89

 System development methodology is a series of processes leads to the

development of an application.
 The software processes describe how the work is to be carried out to achieve
the original goal based on the system requirements.
 Systems development activities consists of systems analysis modeling,
design && implementation, testing, and maintenance.
 Object-oriented development offers a different model from the traditional
software development approach, which is based on functions and
procedures.
 Cont’d
90
 Object oriented development is a way to develop software by building self-contained
modules or objects that can be easily replaced, modified, and reused.
 In an object-oriented environment,
 Software is a collection of discrete objects that encapsulate their data as well as the
functionality to model real-world "objects.“
 An object orientation yields important benefits to the practice of software
construction
 Each object has attributes (data) and methods (functions).
 Objects are grouped into classes; in object-oriented terms, we discover
and describe
the classes involved in the problem domain.
 Everything is an object and each object is responsible for itself.
 Why an object orientation?
 Object oriented systems are
 Easier to adapt to changes
 Easier to maintain
 Promote greater design and code reuse
 Creates modules of functionality
 Reasons for working of object oriented systems:
 Higher level of abstraction
 Seamless transition among different phases of software development
 Encouragement of good programming techniques
 Promotion of reusability
 Cont..
 Higher level of abstraction
 Object orientation approach support abstraction at object level.
 Object encapsulates both data and functions. So they work at higher level
of abstraction.
 So designing, coding, testing and maintaining the system are much simpler.
 Encouragement of good programming techniques
 Changing one class has no impact on other classes
 But there is communication between classes through interface
 Promote clear design
 Implementation is easy
 Provides for better overall communication
 Cont.
93
.
 Promotion of reusability
 Objects are reusable because they are modeled directly out of real world
problem. The object orientation adds inheritance, which is a powerful
technique that allows classes to built from each other. The only different and
enhancements between the classes need to be designed and coded. All the
previous functionality remains and can be reused without change.
 Cont..
 Seamless transition among different phases of software development
 Traditional Approach:
 The software development using this approach requires different
styles and methodologies for each step of the process. So moving
from one phase to another requires more complex transition.
 Object-oriented approach:
 We use the same language to talk about analysis, design,
programming and database design. It returns the level of complexity
and reboundary, which makes clearer and robust system development.
 Basic concept of object
95

 An object is simply a tangible entity in the real world (at the requirement
analysis phase) or represents a system entity (at the design stage).
 Objects are responsible for managing their own private states, and for
offering services to other objects when is it requested. Thus, data and
functions are encapsulated within an object.
 A compound data type that is often used to model a thing or concept in the
real world.
 Cont.
.
96
 E.g. A car is an object a real-world entity, identifiably separate from its
surroundings. A car has a well-defined set of attributes in relation to other
object.
 Cont.
97
.
 Each object is an instance of a class
 Objects are classified into classes, and objects belonging to the same class
have common properties, such as attributes and operations.
 Main role of a class is to define the properties and procedures (the state &
behavior) and applicability of its instances
 Each object is an instance of a class
 ATTRIBUTES AND METHODS
98

 Objects can be described by their properties (attributes ) and

• methods (operations)
Cat

• Class Color
Food preference
Size
Weigh
Attribute Class
t
Diagra
m
Catch mouse
Metho Eat
d miaow
 Cont.
99
.
 Attributes:
 Data of an object.
 Properties of an object.
 in an object model, all data is stored as attributes of some
object
 the attributes of an object are manipulated by the operations
 Methods:
 Procedures of an object. Or
 Behavior of an object.
 Object behavior is described in methods or procedures
 Cont.
100
.
 The term object means a combination or data and logic that represent some
real-world entity.
 When developing an object oriented applications, two basic questions arise
 What objects does the application need?
 What functionality should those objects have?
 Cont’
101
d
 A Class defines a template for all objects of class

 Objects are instances of a class

 Customer object is an instance of a Customer class

 Objects interact through messages

 Objects have identity based on value of attributes

 Operations are methods or services

 Each of the operations that is encapsulated by an object provides a

representation of one of the behaviors of the object.

 Cont.
102
.
 CONCEPT OF MESSAGES
 Objects interact with each other by sending and receiving messages
 Messages are similar or procedure calls in traditional programming languages
 Objects perform operations in response to messages
 Ex: when you press on the brake pedal of a car, you send a STOP message to the
car
 Object. The car object knows how to respond to the STOP message
 Cont’
103
d

Attributes

Operations
 Cont’d
104
 Using classes and objects
105

public class SimpleApplication

SimpleApplication{ public static
void main(String[] args){ Welcomer
welcome=new Welcomer(); main():void
Welcomer.sayhello();
}}

Public class welcome{ Welcome

Privete string welcome=“hello”;
Public void sayHello() welcome
{ System.out.println(welcome);
}} sayHello():void
 The unified approach
106

 Unified approach (UP) is an object-oriented system development methodology

 A system development process is the set of activities needed to transform a
user„s requirements into a software system
 Basic properties:
 use case driven: Use case driven design uses use case as a tool to discover the
entity, interface, interaction message and the workflow on how certain business
operation is being conducted. This is used often in more analysis or design
stage to gather or understand the requirements and establish some initial
designs
 Architecture centric

 Cont.
107
.
 Project use in this approach will be use case driven/focused
 Use case
 Activity or process that the system carries out
 Basis for defining requirements and designs
 A use case constitutes complete course of events initiated by actor
 Defines interaction between actor and system
 Is a member of the set of all use cases which together define all existing
ways of using the system
 An actor is: anything external to the system, human or otherwise – a user type
or category
 Cont.
108
.
 Unified Process (UP) development methodology

 Consists of phases, iterations, and disciplines

 Provides framework for project definition and execution

 UP defines disciplines within each phase
 Discipline: set of functionally related activities
 Iterations concatenate activities from all disciplines
 Activities in each discipline produce artifacts; models, documents,
source
code, and executables
 UP
Phases
109

 The Unified Process divides the project into four phases:

 Inception
 Elaboration (milestone)
 Construction (release)
 Transition (final production release)
 Cont..
110

 Typical goals for the Inception phase.

 Establish a justification or business case for the project
 Establish the project scope and boundary conditions
 Outline one or more candidate architectures
 Identify risks
 Prepare a preliminary project schedule and cos estimate
 Feasibility
 buy or develop it
 The UP
Disciplines
 Six main UP development disciplines
 Business modeling, requirements, design, implementation, testing, and
deployment
 Each iteration
 Similar to a mini-project
 Results in a completed portion of the system
 Three additional support disciplines
 Project management, configuration and change management, and
environment
UP Life Cycle with Phases, Iterations, and Disciplines
Business Modeling

 Purpose: understand business environment

 Three major activities part of business modeling

 Understand surroundings

 Create the system vision

 Create business models

 Requirements

 Objective: document business requirements

 Key drivers of activities: detection and understanding
 Requirements discipline and business modeling map to traditional systems
analysis
 Activities list
 Gather detailed information
 Define functional and nonfunctional requirements
 Develop user interface prototype/model
 Evaluate requirements with users
Design

 Objective: design system based on requirements

 Six major activities in the design discipline
 Design support services architecture and deployment environment
 Design the software architecture
 Design use case realizations
 Design the database
 Design the system and user interfaces
 Design the system security and controls
Implementation

 Objective: build or acquire needed system components

 Implementation activities

 Build software components

 Acquire software components

 Integrate software components

Testin
g
 Testing is critical discipline
 Testing activities
 Define and conduct unit testing
 Define and conduct integration testing
 Define and conduct system testing
 Define and conduct usability testing
 Define and conduct user acceptance testing
 In UP, acceptance testing occurs throughout the building
phase
 Cont.
118
.
 Cont.
119
.
 Unit Testing
 Unit testing is the practice of testing small pieces of code, typically
individual functions, alone and isolated. isolated
 just give the function inputs, and then check what the function
outputs is correct.
 helps you write better code
 in integration testing the idea is to test how parts of the system work
together – the integration of the parts
 E.g a database and your app – work together correctly
 Cont.
.
120

 Functional Testing: Testing of complete functionality of some

application.
 E.g. You might use a unit test to test an individual function and an
integration test to check that two parts of the play nice. Functional tests
are on a whole another level.
 Usability testing is a way to see how easy to use something is by
testing
it with real users.
 See where users encounter problems and experience confusion.
 Cont.
.
121

 User Acceptance Tests consist of a set of test steps, which verify if specific
requirements are working for the user. If the customer and the supplier agree
on the product, the software development is done. Legally. And practically
 is test against certain criteria and specifications which are predefined and
agreed upon in a contract
 Test against governmental and legal regulations.
 It also includes operational tests: workflows in place to allow the software or
system to be used. This should include workflows for backup plans, user
training, and various maintenance processes and security checks.
 Deploymen
t
 Goal: conduct activities to make system operational
 Deployment activities
 Acquire hardware and system software
 Package and install components
 Train users
 Convert and initialize data
 Deployment activities prominent in transition phase
 Managing Software Development
123

 Management activities focus on planning the project, monitoring its status,

tracking changes, and coordinating resources such that a high-quality
product is delivered on time and within budget.
 Management activities include:
 Communication
 Rationale Management
 Software Configuration Management
 Project Management
 Communication
124

 Communication is the most critical and time-consuming activity in software

engineering.
 Misunderstandings and omissions often lead to faults and delays that
are expensive to correct later in the development.
 Communication includes:
 The exchange of models and documents about the system and its application
domain,
 Reporting the status of work products,
 Providing feedback on the quality of work products,
 Raising and negotiating issues, and communicating decisions.
 Rationale Management
125

 Rationale is the justification or explanation of decisions.

 Given a decision, its rationale or basis includes the problem that it addresses,
the alternatives that developers considered, the criteria that developers used
to evaluate the alternatives, the debate developers went through to achieve
consensus, and the Decision.
 Project Management

 Most important support discipline

 Project management does not produce any artifact of its own.
 Instead, project management includes the oversight activities that ensure
the delivery of a high-quality system on time and within budget.
 This includes planning and budgeting the project during negotiations with
the client, hiring developers and organizing them into teams, monitoring the
status of the project, and intervening when deviations occur.
 Cont.
127
.
 Project management activities
 Finalize the system and project scope
 Develop the project and iteration schedule
 Identify project risks and confirm feasibility
 Monitor and control the project’s plan
 Monitor and control communications
 Monitor and control risks and outstanding
issues
 Configuration and Change Management

 Configuration and change discipline apply to: Requirements, Design, Source code,
Executables.
 Software configuration management is the process that monitors and controls
changes in work products. Requirements change as the client requests new features
and as developers improve their understanding of the application domain. The
hardware/software platform on which the system is built changes as new
technology becomes available.
 The two activities in this discipline
 Develop change control procedures
 Manage models and software components
Environment

 Development environment includes

 Available facilities
 Design of the workspace
 Forums for team communication and
interaction
 Environment discipline activities
 Select and configure the development tools
 Tailor the UP development process
 Provide technical support services
The end!