Software Engineering

Software
Engineering
CS3201 [3 1 0 4]
Contents
• Software Engineering: Introduction, Importance, Evaluation, Characteristics, Components.

Software Application; Software Development Process Models: Waterfall Model, Prototyping
Model, Spiral Model, RAD Model, etc., Agile Modelling; Requirement Engineering: Problem
Analysis, Requirement Verification, Requirement Validation Modularity; Software Project
Management: Cost Estimation Project Scheduling, Risk Management, Quality Assurance,
Project Monitoring; Estimation Techniques: Size estimation- LOC Estimation, Function Count,
Cost Estimation, Halstead Size Estimation, Software Design: Analysis Modeling, Functional
modeling, Behavioral Modeling; Unified modeling language; Software Architecture: Data
Design: Data modeling, data structures; Software Maintenance: Maintenances Characteristics,
Maintainability, Maintenances Tasks, Maintenances Side Effects, Current trends- DevOps.
Books to refer
Text Book
• R. Mall, “Fundamental of Software Engineering”, 4th Edition, PHI, 2014
• Ian Summerville, “Software Engineering”, 9th Edition, Addition Wesley,
2002.
Reference Books
• Pankaj Jalote, “Software Engineering a Precise Approach”, Wiley, 2010.
• Roger S. Pressman, “Software Engineering: A Practitioners Approach”,
7th Edition, TMH, 2016.
What is Software Engineering?
• Engineering approach to develop software.
• Building Construction Analogy.
• Systematic collection of past experience:
• techniques,
• methodologies,
• Software engineering is the application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of
software. (Definition by IEEE) That is the application of engineering to software.
•The term software engineering first appeared in the 1968 NATO Software
Engineering Conference, and was meant to provoke thought regarding the
perceived "software crisis" at the time.
Software Engineering
• Software engineering is:
• An engineering discipline that provides knowledge, tools, and
methods for:
• Defining software requirements
• Performing software design
• Software construction
• Software testing
• Software maintenance tasks
• Software project management
Introduction: Software is Complex
• Complex  complicated
• Complex = composed of many simple parts

related to one another
• Complicated = not well understood, or explained

The Frog in Boiling Water
• Small problems tolerate complacency—
lack of immediate penalty leads to
inaction
• Negative feedback accumulates subtly
and by the time it becomes painful, the
problem is too big to address
• Frog in gradually heated water analogy:
• The problem with little things is that none of
them is big enough to scare you into action,
but they keep creeping up and by the time
you get alarmed the problem is too difficult
to handle
• Consequently, “design smells” accumulate,
“technical debt” grows, and the result is
“software rot” https://en.wikipedia.org/wiki/Design_smell
https://en.wikipedia.org/wiki/Technical_debt
https://en.wikipedia.org/wiki/Software_rot
8
The Role of Software Engg. (1)
A bridge from customer needs to programming implementation
Customer
Programmer
First law of software engineering

Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first) 9
The Role of Software Engg. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction w ith the problem domain
in a specified manner
System-to-be
(includes hardware)
Problem Domain
Software-to-be
User
Software Engineer’s task:

To understand how the system-to-be needs to interact w ith
the user or the problem domain so that customer’s requirement is met
and design the software-to-be
May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer
10
Example: ATM Machine
Understanding the money-machine problem:
Communication link
1
4 2
7 5 3
8 6
0 9
Bank’s
remote
ATM machine
datacenter
Bank
customer
11
Problem-solving Strategy
Divide-and-conquer:
• Identify logical parts of the system that each
solves a part of the problem
• Easiest done with the help of a domain expert
who already knows the steps in the process (“how
it is currently done”)
• Result:
A Model of the Problem Domain
(or “domain model”)
12
How ATM Machine Might Work Domain Model
Transaction
How may I record
help you? Cash
Bookkeeper
Speakerphone Safe
Safe keeper
Phone
Window clerk
Datacenter
liaison
Dispenser
Bank’s
remote
datacenter 13
Customer
Cartoon Strip : How ATM Machine Works
A Enter B C Verify
account
D
your PIN
XYZ
Verify
this
account
Typing in XYZ valid. Account

PIN number Balance: valid.
… $100 Balance:
$100
E How may F Release

G Record
I help $60 $60 less
you?
Withdraw Dispense
H Dispensing!
$60 $60
Please take
your cash
14
Sub-disciplines of Software Engineering
• Software engineering can be divided into 11 sub disciplines. They are:
• Software requirements: The elicitation, analysis, specification, and validation of
requirements for software.
• Software architecture: The elicitation, analysis, specification, definition and design, and
validation and control of software architecture requirements.
• Software design: The design of software is usually done with Computer-Aided Software
Engineering (CASE) tools and use standards for the format, such as the Unified Modeling
Language (UML).
• Software development: The construction of software through the use of programming
languages.
• Software testing
• Software maintenance: Software systems often have problems and need enhancements for
a long time after they are first completed. This subfield deals with those problems.
16
Why is Software Engineering important?
Complex systems need a disciplined approach for designing,

developing and managing them.
17
Software Development Crises
Projects were:
• Late.
• Over budget.
• Unreliable.
• Difficult to maintain.
• Performed poorly.
18
Software errors….the cost
Errors in computer software can

have devastating effects.
19
Software Crisis
Example 1: 2009,Computer glitch delays flights
Saturday 3rd October 2009-London, England (CNN)
• Dozens of flights from the UK were delayed Saturday after a

glitch in an air traffic control system in Scotland, but the
problem was fixed a few hours later.
• The agency said it reverted to backup equipment as

engineering worked on the system.
• The problem did not create a safety issue but could cause
delays in flights.
• Read more at:

http://edition.cnn.com/2009/WORLD/europe/10/03/uk.flights.
delayed
20
Software Crisis
Example 2: Ariane 5 Explosion
• European Space Agency spent 10 years and $7 billion to

produce Ariane 5.
• Crash after 36.7 seconds.
• Caused by an overflow error. Trying to store a 64-bit

number into a 16-bit space.
• Watch the video: http://www.youtube.com/watch?v=z-

r9cYp3tTE
21
Software Crisis
Example 3: 1992, London Ambulance Service
• Considered the largest ambulance service in the world.
• Overloaded problem.
• It was unable to keep track of the ambulances and their

statuses. Sending multiple units to some locations and
no units to other locations.
• Generates many exceptions messages.
• 46 deaths.
22
Therefore…
A well-disciplined approach to
software development and
management is necessary. This is
called engineering.
23
Software Engineering
 The term software engineering first appeared in the 1968 NATO

Software Engineering Conference and was meant to provoke
thought regarding what was then called the “software crisis”..
 “.. An engineering discipline that is concerned with all aspects

of software production from the early stages of system
specification to maintaining the system after it has gone into
use.” Sommerville, pg.7
24
What is Software?
Programs
Software
System
Documentation
Documentati
Data on
User
Documentation
25
Types of Software
• Generic products.
• Stand-alone systems that are marketed and sold to any customer who wishes to buy
them.
• Examples – PC software such as graphics programs, project management tools; CAD
software; software for specific markets such as appointments systems for dentists.
• The specification of what the software should do is owned by the software developer
and decisions on software change are made by the developer.
• Customized or bespoke products.

• Software that is commissioned by a specific customer to meet their own needs.
• Examples – embedded control systems, air traffic control software, traffic monitoring
systems.
• The specification of what the software should do is owned by the customer for the
software and they make decisions on software changes that are required.
26
Software Engineering vs. Computer Science
“Computer science is no more about computers than

astronomy is about telescopes.” Edsger Dijkstra
Computer Science Software Engineering
• Theory. • Practicalities of software

• Fundamentals. design, development and
delivery.
27
Software Engineering vs. Systems Engineering
Systems Engineering:
 Interdisciplinary engineering field (computer, software, and process eng.).
 Focuses on how complex engineering projects should be designed and managed.
Systems Engineering Software Engineering
• All aspects of computer- • Deals with the design,

based systems development and
development: HW + SW delivery of SW.
+ Process. • Is part of Systems
• Older than SWE. Engineering.
Sub-disciplines of Software Engineering
• Software configuration management: Since software systems are very complex, their
configuration (such as versioning and source control) have to be managed in a
standardized and structured method.
• Software engineering management: The management of software systems borrows
heavily from project management, but there are nuances encountered in software not
seen in other management disciplines.
• Software development process: The process of building software is hotly debated
among practitioners; some of the better-known processes are the Waterfall Model, the
Spiral Model, Iterative and Incremental Development, and Agile Development.
• Software engineering tools
• Software quality
Software products
• Generic products
• Stand-alone systems that are marketed and sold to any customer
who wishes to buy them.
• Examples – PC software such as editing, graphics programs, project
management tools; CAD software; software for specific markets such
as appointments systems for dentists.
• Customized products
• Software that is commissioned by a specific customer to meet their
own needs.
• Examples – embedded control systems, air traffic control software,
traffic monitoring systems.
Software Applications
1. System software: such as compilers, editors, file management utilities
2. Application software: stand-alone programs for specific needs.
3.Engineering/scientific software: Characterized by “number crunching”algorithms. such
as automotive stress analysis, molecular biology, orbital dynamics etc
4. Embedded software resides within a product or system. (keypad control of a microwave
oven, digital function of dashboard display in a car)
5. Product-line software focus on a limited marketplace to address mass consumer
market. (word processing, graphics, database management)
6. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database
and business applications.
7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert
system, pattern recognition game playing.
Need for Software Engineering
• The Five Drivers of Software Engineering

• Manage complexity of large programs
• Reduce time and cost of development
• Reduce maintenance cost
• Address “Software crisis” (Unacceptable low quality of software,
exceeds deadline and budget.)
• Produce quality software
Software Characteristics
• Its characteristics that make it different from other things human being build.
Features of such logical system:

• Software is developed or engineered; it is not manufactured in the classical
sense which has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change). Hardware has
bathtub curve of failure rate ( high failure rate in the beginning, then drop to
steady state, then cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward component-based construction (e.g.
standard screws and off-the-shelf integrated circuits), most software continues
to be custom-built. Modern reusable components encapsulate data and
processing into software parts to be reused by different programs. E.g.
graphical user interface, window, pull-down menus in library etc.
FAQ about software engineering
Question Answer
What is software? Computer programs, data structures and associated documentation. Software
products may be developed for a particular customer or may be developed for a
general market.
What are the attributes of good Good software should deliver the required functionality and performance to the
software? user and should be maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is concerned with all
aspects of software production.
What is the difference between Computer science focuses on theory and fundamentals; software engineering
software engineering and is concerned with the practicalities of developing and delivering useful software.
computer science?
What is the difference between System engineering is concerned with all aspects of computer-based systems
software engineering and system development including hardware, software and process engineering. Software
engineering? engineering is part of this more general process.
Essential attributes of good software
Product Description
characteristic
Maintainability Software should be written in such a way so that it can evolve to meet the changing needs
of customers. This is a critical attribute because software change is an inevitable
requirement of a changing business environment.
Dependability and Software dependability includes a range of characteristics including reliability, security and
security safety. Dependable software should not cause physical or economic damage in the event
of system failure. Malicious users should not be able to access or damage the system.
Efficiency Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time, memory
utilisation, etc.
Acceptability Software must be acceptable to the type of users for which it is designed. This means that
it must be understandable, usable and compatible with other systems that they use.
Software Qualities
Pressman's definition of “Software Quality”
1.explicitly stated functional and performance requirements,
2.explicitly documented development standards, and
3.implicit characteristics that are expected of all professionally developed
software.
IEEE Definition of “Software Quality”
1.The degree to which a system, component, or process meets specified
requirements.
2.The degree to which a system, component, or process meets customer
or user needs or expectations.
Software Qualities
• Software quality:
• Conformance to explicitly stated requirements and
standards
• Quality assurance:
• is the activity that leads to “fitness of purpose”.
• Quality product:
• is the one that does what the customer expects it to do.
User satisfaction = compliant product + good quality + delivery within
budget and schedule
Software Qualities
Quality criteria include but are not limited to:
• Correctness • Evolvability
• Reliability • Reusability
• Robustness • Portability
• Performance • Understandability
• User friendliness • Productivity
• Verifiability
• Size
• Maintainability
• Timeliness
• Reparability
• Safety • Visibility
Select the critical attributes and plan how to achieve them

Software Quality Factors
• Low defects level when deployed
• Zero defect most preferably
• High reliability
• Capability of running without crashes
• Majority of the user satisfy with software when conducted the
survey
• Effective customer support
• Rapid defect repair
Benefits Of Software Quality
• Reduced maintenance cost
• Stable and useful product
• Satisfy customer needs
• Better chances for continuing releases
• Build corporate culture and identity
• Better chances for software and design reuse
McCall’s Quality Factors
• McCall’s quality factors were proposed in the early 1970s. They are as valid today as they
were in that time. It’s likely that software built to conform to these factors will exhibit high
quality well into the 21st century, even if there are dramatic changes in technology.
M a in t a in a b ilit y P o r ta b ility
F le x ib ility
R e u s a b ility
T e s ta b ility
I n te r o p e r a b ility
P R O D U C T R E V IS IO N P R O D U C T T R A N S IT IO N
P R O D U C T O P E R A T IO N
C o rre c tn e s s U s a b ility E f f ic ie n c y
R e lia b ility I n te g r it y
McCall’s Software Quality Factors
• Product Operations
• Operational characteristics
• Product Revision
• Ability to undergo changes
• Product Transition
• Adaptability to new environments
McCall’s Quality Factors Model Tree
McCall’s Software Quality Factors
Factor Criteria Description
Product Maintainability Can I fix it?
Revision Flexibility Can I change it?
Testability Can I test it?
Product Portability Will I be able to use it on another machine?
Transition Reusability Will I be able to reuse some of the other
software in other application?
Interoperability Will I be able to interface it with another
system?
Product Correctness Does it do what I want?
Operation Reliability Does it do it accurately all the time?
Efficiency Will it run as well as it can?
Integrity Is it secure?
Usability Is it easy to use?
McCall Quality Model and Alternative Models
Alternative factor models
No. Software quality McCall’s classic Evans and Deutsch and
factor model Marciniak model Willis model
1 Correctness + + +
2 Reliability + + +
3 Efficiency + + +
4 Integrity + + +
5 Usability + + +
6 Maintainability + + +
7 Flexibility + + +
8 Testability +
9 Portability + + +
10 Reusability + + +
11 Interoperability + + +
12 Verifiability + +
13 Expandability + +
14 Safety +
15 Manageability +
16 Survivability +
45
What is a Software Process?
 Activities and results that produce a software product:
SW Process Activity What is going on there?
What does the customer need?

Specification
What are the constraints?
Development Design & programming.
Validation Checking whether it meets requirements.
Evolution Modifications (e.g. customer/market).

46
What is a Software Process Model?
 Description of the software process that represents one view, such as the
activities, data or roles of people involved.
Examples of views Focus on…
Activities = human actions.

Workflow
What is input, output, and dependencies.
Activities = transformations of information.

Dataflow
How the input is transformed into output.
What is the role of people involved in each step of the
Role/Action
process?
47
Software Process Models
Component-Based Software
Waterfall approach Iterative development
Engineering CBSE
assembled form existing

components
48
The Cost of Software Engineering
 Depends on:
 The process used, and
 The type of software being developed.
 Each generic approach has a different profile of cost distribution.
 Roughly 60% of costs are development costs, 40% are testing costs.
 For custom software, evolution costs often exceed development costs.

49
Cost distribution
Custom software development (Bespoke)
Software Model Waterfall Model
Cost units 0 25 50 75 100
Cost distribution
Software development activity Specification Design Development Integration and testing
Iterative Development
0 25 50 75 100
Specification Iterative Development System testing
Component-based Software Engineering

0 25 50 75 100
Specificatio Development Integration and testing

n
Development and evolution costs for long-lifetime systems
0 100 200 300 400
System development System evolution

50
Cost distribution
Generic software development
0 25 50 75 100
Specification Development System testing
Product development costs

51
What is CASE?
 Computer Aided Software Engineering.
 Programs that support:

 Requirements analysis.
 System modeling.
 Debugging.
 Testing.
52
Attributes of good software
 Functional attributes (performance; what the system does).

 Non-functional attributes (quality; how the system does it).
Product Characteristic Description

Maintainability Evolution qualities such as Testability, extensibility.
Dependability Reliability, security, safety.
Efficiency Response time, processing time, memory utilization.
Usability Easy to learn how to use the system by target users.
Efficient to use the system by users to accomplish a task.
Satisfying to use by intended users.
53
Activity
 What are the key attributes for..
Interactive game Banking system Cardiac monitor in an ICU unit
Players, score, scenes, theme. Client accounts, stocks bonds, heart rate, temperature, blood
money transfers. pressure.
54
Challenges facing software engineering
Challenge Why? Software needs to ..
Different computers, different platforms,

Heterogeneity Cope with this variability.
different support systems.
Businesses are more responsive →

Be delivered in shorter time
Delivery supporting software needs to evolve as
without compromising quality.
rapidly.
Software is a part of many aspects of our

Demonstrate that it can be trusted
Trust lives (work, study, leisure).
by users.
Objects, Calling & Answering Calls
elmer.areCoprimes( Prime factorization:

905, 1988 905 = 5  181
) 1988 = 2  2  7  71
Result:
YES!
Stu Elmer
Prime factorization of 905:

5181 (2 distinct factors)
Prime factorization of 1988:
22771 (4 factors, 3 distinct)
Two integers are said to be coprime or relatively prime if they have no common
factor other than 1 or, equivalently, if their greatest common divisor is 1.
Objects Don’t Accept Arbitrary Calls
Acceptable calls are defined by object “methods”
(a.k.a. Operations, Procedures, Subroutines, Functions)
Object:
method-1: method-2: method-3:
ATM machine
Accept card Read code Take selection
1234
5678
12345
1
4 2
7 5 3
8 6
0 9
Object Interface
Interface defines method “signatures”
Method signature: name, parameters, parameter types, return type
Interface
method-1 Object hides its
state (attributes).
method-2 The attributes
are accessible
only through the
method-3 interface.
Clients, Servers, Messages
Client
Client Object
Object Server
Server
Object
Object
Message
• Objects send messages by calling methods
• Client object: sends message and asks for service
• Server object: provides service” and returns result

Interfaces
• An interface is a set of functional properties (services) that a

software object provides or requires.
• Methods define the “services” the server object implementing the
interface will offer
• The methods (services) should be created and named based on
the needs of client objects that will use the services
• “On-demand” design—we “pull” interfaces and their implementations into existence
from the needs of the client, rather than “pushing” out the features that we think a
class should provide
Objects are Modules
Software Module
Inputs State Outputs

(e.g., force) (represented by (e.g., force)
state variables,
e.g.,
momentum,
mass, size, …)
Modules versus Objects
Modules are loose groupings of subprograms and data
“Promiscuous”
access to data often
Subprograms results in misuse
(behavior)
Data
(state)
Software Module 1 Software Module 2 Software Module 3
Objects encapsulate data

Attributes
/data
Methods (state)
(behavior)
Software Object 1 Software Object 2 Software Object 3

Software Development
Methodologies
Software Development Life Cycle
(SDLC)
• A (software/system) lifecycle model is a description of the sequence of
activities carried out in an SE project, and the relative order of these
activities.
• Software Development Life Cycle (SDLC) is a process used by a
systems analyst to develop an information system, including
requirements, validation, training, and user (stakeholder) ownership.
• Any SDLC should result in a high quality software that meets or
exceeds customer expectations, reaches completion within time and
cost estimates, works effectively and efficiently in the current and
planned Information Technology infrastructure, and is inexpensive to
maintain and cost-effective to enhance.
• It provides a sequence of activities for system designers and
developers to follow.
• It consists of a set of steps or phases in which each phase of the SDLC
uses the results of the previous one.
Strength and Weaknesses of SDLC
Software Development Process Model
• A software development process model is an abstract
representation of a software process.
• The development process is the sequence of activities
that will produce high quality software.
• A software development process model is broken down
into distinct activities.
• A software development process model specifies how
these activities are organized in the entire software
development effort.
Types of Software Development Process
Model
• A software development process model is either a descriptive or
prescriptive characterization of how software is or should be
developed.
• A descriptive model describes the history of how a particular
software system was developed. Descriptive models may be used
as the basis for understanding and improving software
development processes or for building empirically grounded
prescriptive models.
• A prescriptive model prescribes how a new software system
should be developed. Prescriptive models are used as guidelines or
frameworks to organize and structure how software development
activities should be performed, and in what order. Typically, it is
easier and more common to articulate a prescriptive life cycle
model for how software systems should be developed.
Waterfall Model
• Sometimes called the classic life cycle or the linear sequential
model.
• It suggests a systematic, sequential approach to software
development that begins at the system level and progresses
through analysis, design, coding, testing, and support.
• Waterfall model is the simplest & oldest prescriptive process
model.
• It is a rigid and linear process model.
• Although the original waterfall model proposed by Winston
Royce made provision for “feedback loops,” the vast majority
of organizations that apply this process model treat it as if it
were strictly linear.
Stages of Waterfall Model
Waterfall Model
• In theory:
• Each phase produces documents that are:
• Verified and validated.
• Assumed to be complete.
• Each phase depends on the documents of the
previous stage to proceed → it has to wait for the
completion of previous stage.
• In practice:
• The phases overlap and feedback to each other (see
the feedback arrow in the diagram).
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.
Advantages & Disadvantages
Advantages of the Waterfall Model:
• Easy to explain to the user.
• Stages and activities are well defined.
• Helps to plan and schedule the project.
Disadvantages of the Waterfall Model:

• Real projects rarely follow sequential flow.
• Difficult to state all requirements explicitly.
• The customer must have patience.
• Blocking states.
• Developers have very little interaction with the users.
• The project is not partitioned in phases in flexible way.
Incremental Process Model
• The incremental model combines elements of the linear sequential
model (applied repetitively) with the iterative philosophy of
prototyping.
• Each linear sequence produces a deliverable “increment” of the
software.
• For example, word-processing software developed using the
incremental paradigm might deliver basic file management, editing,
and document production functions in the first increment; more
sophisticated editing and document production capabilities in the
second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth
increment.
Incremental Process Model
• Construct a partial implementation of a total system
• Then slowly add increased functionality
• The incremental model prioritizes requirements of the system and then
implements them in groups.
• Each subsequent release of the system adds function to the previous
release, until all designed functionality has been implemented.
• It combines the advantages of Waterfall and Evolutionary Model.
• Each increment is a mini-waterfall.
Stages of Incremental Model
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.
Advantages & Disadvantages
• Advantages of Incremental Model:
• Less Human Resources.
• Manage Technologies.
• Customer Evaluation and Satisfaction
• Customer gains experience.
• Low Project Failure Risk.
•
• Disadvantages of Incremental Model:
• Increments size should be neither too small nor too large.
• It is very difficult to categorize requirements as most important and least
important.
Prototyping Model
• Prototyping is a technique for providing a reduced functionality or a limited
performance version of a software system early in its development.
• Prototyping can more directly accommodate early user participation in
determining, shaping, or evaluating emerging system functionality.
• Prototyping is the practice of building an early version of software.
• This model is built at the early stages of the software development. It is built
very rapidly and fast, so that it can be checked time-to-time by the customer.
That is why, it is also called as the “Rapid Prototyping”.
• Prototyping is well suited for projects where requirements are hard to determine
and the confidence in the stated requirements is low.
Prototyping Model
Steps of Prototyping Model
• 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 builds
• the database
• user interface
• algorithmic functions
• The designer demonstrates the prototype, the user evaluates for
problems and suggests improvements.
• This loop continues until the user is satisfied
When to use Prototyping Model
• 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.
Advantages of Prototyping Model
• Misunderstandings between software developer and users may be
identified.
• Missing facilities and features may be found out.
• Any non-conform, hard or confusing facilities or characteristics may be
identified.
• Software developer may be found the incomplete or inconsistent
requirements as the prototype is developed.
• Development effort is reduced because the resultant system is the right
system.
• User-developer communication is enhanced.
Disadvantages of Prototyping Model
• The customer will want the early version of the model which may not have
good quality concerns and maintainability.
• The developer often makes implementation compromises in order to get
a prototype working quickly. An inappropriate operating system or
programming language may be used simply because it is available and
known; an inefficient algorithm may be implemented simply to
demonstrate capability. After a time, the developer may become familiar
with these choices and forget all the reasons why they were
inappropriate. The less-than-ideal choice has now become an integral
part of the system.
Spiral Model
• The spiral model, originally proposed by Barry W. Boehm in his 1986
article "A Spiral Model of Software Development and Enhancement“.
• It is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the
linear sequential model.
• It provides the potential for rapid development of incremental versions
of the software.
• Using the spiral model, software is developed in a series of incremental
releases.
Stages of Spiral Model
Spiral Model
• Process is represented as a spiral rather than as a sequence of activities with
backtracking.
• Each loop = One Iteration = A process phase.
• Each Loop passes through 4 quadrants (90°):
• Objective Setting.
• Risk Assessment and Reduction.
• Development and Validation.
• Planning.
• As loops move away from center → Time and Cost increase.
• Adds risk analysis, and RAD prototyping to the waterfall model.
• Each cycle involves the same sequence of steps as the waterfall process
model.
When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to
economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)
Advantages of Spiral Model
• The software development indicates that the software remain active till it is
retired.
• It is a realistic approach to be used.
• If the process is going to be old, and requires some type of change, then
maintenance or some enhancements can be done in the project.
• The main and most important feature of this model is risk analysis. The risk
analyst will try to reduce the risks arise. Prototyping can be used as risk
reduction mechanism.
Disadvantages of Spiral Model
• It is very hard to satisfy the customer.
• If the risks are not covered initially then they may arise at any time in later
stages.
• This model can’t be used so frequently so the results are not available soon.
• It requires a large sum of money to be completed.
• Very difficult to implement.
Rapid Application Development Model
• RAD model is Rapid Application Development model.
• It is an adoption of the waterfall model.
• It targets at developing software in a short span of time.
• It is a type of incremental model.
• In RAD model, the components or functions are developed in
parallel as if they were mini projects.
• The developments are time boxed, delivered and then assembled
into a working prototype.
• RAD model has following phases
1. Business Modeling
4. Application Generation
2. Data Modeling
5. Testing and Turnover
3. Process Modeling
RAD Model
Different phases of RAD model
Phases of RAD Activities performed in RAD Model
model
Business •On basis of the flow of information and distribution between various business
Modeling channels, the product is designed
Data Modeling •The information collected from business modeling is refined into a set of data
objects that are significant for the business
Process Modeling •The data object that is declared in the data modeling phase is transformed to
achieve the information flow necessary to implement a business function
Application •Automated tools are used for the construction of the software, to convert
Generation process and data models into prototypes
Testing and •As prototypes are individually tested during every iteration, the overall testing
Turnover time is reduced in RAD.
When to use RAD Methodology?
• When a system needs to be produced in a short span of time (2-3
months)
• When the requirements are known
• When the user will be involved all through the life cycle
• When technical risk is less
• When there is a necessity to create a system that can be modularized in
2-3 months of time
• When a budget is high enough to afford designers for modeling along
with the cost of automated tools for code generation
RAD Examples
• Purchase Order
• Gather all the people who know the process best, starting with the procurement team.
Bring together current forms and a complete understanding of the workflow. Discuss
how you want the app to function. With purchase orders, it’s often helpful to also have a
vendor database for quick reference to call up information in the form.
• Employee Resignation
• Travel Request
RAD Model Vs Traditional SDLC
• The traditional SDLC follows a rigid process models with high emphasis on
requirement analysis and gathering before the coding starts. It puts pressure
on the customer to sign off the requirements before the project starts and the
customer doesn’t get the feel of the product as there is no working solution
available for a long time.
• The customer may need some changes after he gets to see the software.
However, the change process is quite rigid and it may not be feasible to
incorporate major changes in the product in the traditional SDLC.
• The RAD model focuses on iterative and incremental delivery of working
models to the customer. This results in rapid delivery to the customer and
customer involvement during the complete development cycle of product
reducing the risk of non-conformance with the actual user requirements.
Advantages of the RAD Model
• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
Disadvantages of the RAD Model
• Dependency on technically strong team members for identifying business requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on modeling skills.
• Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.
Agile Modeling
• Rapid development and delivery is now often the most important
requirement for software systems
• Businesses operate in a fast –changing requirement and it is practically impossible
to produce a set of stable software requirements
• Software has to evolve quickly to reflect changing business needs.
• Plan-driven development is essential for some types of system but does

not meet these business needs.
• Dissatisfaction with the overheads involved in software design methods
of the 1980s and 1990s led to the creation of agile methods.
• Agile development methods emerged in the late 1990s whose aim was
to radically reduce the delivery time for working software systems.
Dynamic System Development Method
• The Dynamic Systems Development technique (DSDM) is an associate
degree agile code development approach that provides a framework for
building and maintaining systems.
• The DSDM philosophy is borrowed from a modified version of the sociologist
principle—80% of An application is often delivered in twenty percent of the time
it’d desire deliver the entire (100 percent) application.
• DSDM is a Rapid Application Development (RAD) approach to software
development and provides an agile project delivery framework.
• The important aspect of DSDM is that the users are required to be involved
actively, and the teams are given the power to make decisions.
• Frequent delivery of product becomes the active focus with DSDM.
DSDM Life Cycle
• DSDM life cycle that defines 3 different unvarying cycles, preceded by 2 further life
cycle activities:
• Feasibility Study: It establishes the essential business necessities and constraints
related to the applying to be designed then assesses whether or not the application
could be a viable candidate for the DSDM method.
• Business Study: It establishes the use and knowledge necessities that may permit the
applying to supply business value; additionally, it is the essential application design
and identifies the maintainability necessities for the applying.
• Functional Model Iteration: It produces a collection of progressive prototypes that
demonstrate practicality for the client. The intent throughout this unvarying cycle is to
collect further necessities by eliciting feedback from users as they exercise the
paradigm.
DSDM Life Cycle
• Design and Build Iteration: It revisits prototypes designed throughout
useful model iteration to make sure that everyone has been designed
during a manner that may alter it to supply operational business price for
finish users. In some cases, useful model iteration and style and build
iteration occur at the same time.
• Implementation: It places the newest code increment (an
“operationalized” prototype) into the operational surroundings. It ought to
be noted that:
(a) the increment might not 100% complete or,
(b) changes are also requested because the increment is placed into place.
• In either case, DSDM development work continues by returning to the
useful model iteration activity.
Requirement Engineering
Requirement Engineering
• The process of establishing the services the system should provide and the
constraints under which it must operate’ - Roger S. Pressman Software Engineering
– A practitioner’s Approach European Adaptation, fifth edition
• The appropriate mechanism for understanding what the customer wants, analyzing
need, assessing feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the requirements as they
are transformed into an operational system.
- Thayer, R.H. and M. Dorfman, Software requirements engineering.
Requirements Engineering
• The process of establishing the services that a customer requires from a
system and the constraints under which it operates and is developed.
• Begins during the communication activity and continues into the
modeling activity
• Builds a bridge from the system requirements into software design and
construction
• Allows the requirements engineer to examine
• the context of the software work to be performed
• the specific needs that design and construction must address
• the priorities that guide the order in which work is to be completed
• the information, function, and behavior that will have a profound impact on the
resultant design
Requirements Engineering Tasks
• Seven distinct tasks
• Inception
• Elicitation (Induction)
• Elaboration
• Negotiation
• Specification
• Validation
• Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the
needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction
of the software
Inception Task
• During inception, the requirements engineer asks a set of questions to
establish…
• A basic understanding of the problem
• The people who want a solution
• The nature of the solution that is desired
• The effectiveness of preliminary communication and collaboration between the
customer and the developer
• Through these questions, the requirements engineer needs to…
• Identify the stakeholders
• Recognize multiple viewpoints
• Work toward collaboration
• Break the ice and initiate the communication
Elicitation Task
• Elicitation may be accomplished through two activities
• Collaborative requirements gathering
• Quality function deployment
• Eliciting requirements is difficult because of
• Problems of scope in identifying the boundaries of the system or
specifying too much technical detail rather than overall system
objectives
• Problems of understanding what is wanted, what the problem
domain is, and what the computing environment can handle
(Information that is believed to be "obvious" is often omitted)
• Problems of volatility because the requirements change over time
Collaborative Requirements Gathering
• Meetings are conducted and attended by both software engineers,
customers, and other interested stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls the meeting
• A "definition mechanism" is used such as work sheets, flip charts, wall
stickers, electronic bulletin board, chat room, or some other virtual
forum
• The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of solution
requirements
Quality Function Deployment
• This is a technique that translates the needs of the customer into
technical requirements for software.
• It emphasizes an understanding of what is valuable to the customer
and then deploys these values throughout the engineering process
through functions, information, and tasks.
• It identifies three types of requirements
• Normal requirements: These requirements are the objectives and goals stated for
a product or system during meetings with the customer.
• Expected requirements: These requirements are implicit to the product or system
and may be so fundamental that the customer does not explicitly state them.
• Exciting requirements: These requirements are for features that go beyond the
customer's expectations and prove to be very satisfying when present.
Elicitation Work Products
The work products will vary depending on the system, but should include one or
more of the following items:
1. A statement of need and feasibility
2. A bounded statement of scope for the system or product
3. A list of customers, users, and other stakeholders who participated in
requirements elicitation
4. A description of the system's technical environment
5. A list of requirements (organized by function) and the domain constraints
that apply to each
6. A set of preliminary usage scenarios (in the form of use cases) that provide
insight into the use of the system or product under different operating
conditions
7. Any prototypes developed to better define requirements
Elaboration Task
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand and
refine it.
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints.
• It is an analysis modeling task
• Use cases are developed.
• Domain classes are identified along with their attributes and relationships.
• State machine diagrams are used to capture the life on an object.
• The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem.
Negotiation Task
• During negotiation, the software engineer reconciles the conflicts
between what the customer wants and what can be achieved given
limited business resources.
• Requirements are ranked (i.e., prioritized) by the customers, users, and
other stakeholders.
• Risks associated with each requirement are identified and analyzed.
• Rough guesses of development effort are made and used to assess the
impact of each requirement on project cost and delivery time.
• Using an iterative approach, requirements are eliminated, combined
and/or modified so that each party achieves some measure of
satisfaction.
The Art of Negotiation
• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit
Specification Task
• A specification is the final work product produced by the requirements

engineer.
• It is normally in the form of a software requirements specification.
• It serves as the foundation for subsequent software engineering
activities.
• It describes the function and performance of a computer-based system
and the constraints that will govern its development.
• It formalizes the informational, functional, and behavioral requirements
of the proposed software in both a graphical and textual format.
Validation Task
• During validation, the work products produced as a result of
requirements engineering are assessed for quality.
• The specification is examined to ensure that
• all software requirements have been stated unambiguously
• inconsistencies, omissions, and errors have been detected and corrected
• the work products conform to the standards established for the process, the
project, and the product
• The formal technical review serves as the primary requirements
validation mechanism.
• Members include software engineers, customers, users, and other stakeholders.
Questions to ask when Validating Requirements
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of abstraction?
That is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will
house the system or product?
Requirements Management Task
• During requirements management, the project team performs
a set of activities to identify, control, and track requirements
and changes to the requirements at any time as the project
proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more
traceability tables
• These tables may be stored in a database that relate features,
sources, dependencies, subsystems, and interfaces to the
requirements
• A requirements traceability table is also placed at the end of
the software requirements specification
Software Requirement Specification (SRS)
Software Requirement Specification (SRS)
• A software requirements specification (SRS) is a complete description of the
behavior of the system to be developed.
• It may include a set of use cases that describe interactions the users will have
with the software.
• A document that clearly and precisely describes, each of the essential
requirements of the software and the external interfaces.
• (functions, performance, design constraint, and quality attributes)
• Each requirement is defined in such a way that its achievement is capable of
being objectively verified by a prescribed method; for example inspection,
demonstration, analysis, or test.
• Software requirements specification establishes the basis for agreement
between customers and contractors or suppliers on what the software
product is to do as well as what it is not expected to do.
An example organization of an SRS
• Introduction  Specific requirements
• Purpose  External interface requirements
• Definitions  Functional requirements
• System overview
 Introduction
• References  Inputs
• Overall description  Processing
• Product perspective  Outputs
• System Interfaces  Performance requirements
• User Interfaces
 Design constraints
• Hardware interfaces
• Software interfaces  Standards Compliance
• Communication Interfaces  Logical database requirement
• Memory Constraints  Software System attributes
• Operations
 Reliability
• Site Adaptation Requirements
 Availability
• Product functions
 Security
• User characteristics
 Maintainability
• Constraints, assumptions and dependencies
 Portability
 Other requirements
Characteristics of a Good SRS (IEEE 830)
1. Unambiguous
2. Complete
3. Verifiable
4. Consistent
5. Modifiable
6. Traceable
7. Usable during the Operation and Maintenance Phase
IEEE Software Document Definitions
• SQAP – Software Quality Assurance Plan (IEEE 730)
• SCMP – Software Configuration Management Plan (IEEE 828)
• STD – Software Test Documentation (IEEE 829)
• SRS – Software requirements specification (IEEE 830)
• SVVP – Software Validation & Verification Plan IEEE 1012
• SDD – Software Design Description IEEE 1016
• SPMP – Software Project Management Plan IEEE 1058
• SUD – Software User Documentation IEEE 1063
Requirements vs. Design
Requirements Design
Describe what will be delivered Describe how it will be done
Primary goal of analysis: Primary goal of design:

UNDERSTANDING OPTIMIZATION
There is more than one solution There is only one (final) solution
Customer interested Customer not interested (Most of

the time) except for external
Types of Requirement
• User requirements
• Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
• System requirements
• A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract between
client and contractor.
User and System Requirements
Functional and Non-functional Requirements
• Functional requirements
• Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process,
standards, etc.
• Often apply to the system as a whole rather than individual features
or services.
• Domain requirements
• Constraints on the system from the domain of operation
Functional Requirements
• Describe functionality or system services.
• Depend on the type of software, expected users and
the type of system where the software is used.
• Functional user requirements may be high-level
statements of what the system should do.
• Functional system requirements should describe the
system services in detail.
Non-functional Requirements
• These define system properties and constraints e.g. reliability, response
time and storage requirements. Constraints are I/O device capability,
system representations, etc.
• Process requirements may also be specified mandating a particular IDE,
programming language or development method.
• Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless.
Types of Non-functional Requirement
Users of a requirements document
Types of Requirements
• Functional requirements
• Performance requirements
• Speed, accuracy, frequency, throughput
• External interface requirements
• Design constraints
• Requirements are usually about “what”, this is a
“how”.
• Quality attributes
• i.e. reliability, portability, maintainability,
supportability
System Analyst
• A systems analyst is an IT professional who specializes in analyzing, designing
and implementing software systems.
• System analysts assess the suitability of information systems in terms of their

intended outcomes and liaise with end users, software vendors and
programmers in order to achieve these outcomes.
• Requirements analysis allows the software engineer (called an analyst or

modeler in this role) to:
• elaborate on basic requirements established during earlier requirement
engineering tasks
• build models that depict user scenarios, functional activities, problem
classes and their relationships, system and class behavior, and the flow of
data as it is transformed.
System Analyst
A systems analyst may:
• Identify, understand and plan for organizational and human impacts of planned systems, and ensure
that new technical requirements are properly integrated with existing processes and skill sets.
• Plan a system flow from the ground up.
• Interact with internal users and customers to learn and document requirements that are then used to
produce business requirements documents.
• Write technical requirements from a critical phase.
• Interact with designers to understand software limitations.
• Help programmers during system development, ex: provide use cases, flowcharts or even database
design.
• Perform system testing.
• Deploy the completed system.
• Document requirements or contribute to user manuals.
• Whenever a development process is conducted, the system analyst is responsible for designing
components and providing that information to the developer.
Knowledge and Qualities of System Analyst
• An analyst must process various skills to effectively carry out the job.
Specifically, they must be divided into two categories:
• Interpersonal skill: This skills deal with relationships and the interface of
the analyst with people in business. They are useful in establishing trust,
resolving conflict, and communicating information.
• Technical skills: On other hand, focus on procedures and techniques for

operations analysis, systems analysis ,and computer science.
The Interpersonal skills include: -
• Communication: Communication is not just reports, telephone conversations,
and interviews. It is people talking, listening, feeling and reacting to one
another, their experience and reactions.
• Understanding: Identifying problems and assessing their ramifications, having
a grasp of company goals and objectives, and showing sensitivity to the impact
of the system on people at work.
• Teaching: Educating people in use of computer system, selling the system to
user, and giving support when needed.
• Selling: Selling ideas and promoting innovations in problem solving using
computers.
The technical skills include: -
• Creativity: Helping users model ideas into concrete plans and developing candidate
systems to match user requirements.
• Problem solving: Reducing problems to their elemental levels for analysis, developing
alternative solutions to a given problem, and delineating the pros and cons of
candidate system.
• Project management: Scheduling, performing well under time constraints, coordinating
team efforts, and managing costs and expenditures.
• Dynamic interface: Blending technical and nontechnical consideration in functional
specifications and general design.
• Questioning attitude and inquiring mind: Knowing the what, when, why, where, who
and how a system works.
• Knowledge of the basics of the computer and the business function.
Role of a System Analyst
• The primary role of a systems analyst is to study the problems and needs
of an organization in order to determine how people, methods, and
information technology can best be combined to bring about
improvements in the organization. (Hoffer, George & Valachich, 1999).
• The systems analyst is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to
implement these ideas (Dennis, Wixom & Tegarden, 2002).
• Systems analysts are key to the systems development process. The
analyst's primary focus is on what not how. What data does the system
produce and consume, what functions must the system perform, what
interfaces are defined and what constrains apply?" (Pressman, 1997).
Role of a System Analyst
• The systems analyst must understand both the business requirements of an
organization and the workings of the various technologies - the systems analyst
builds the bridges between organizational needs and technology solutions.
• “When a system developer walks away from the successful implementation of a
good system, what has been achieved is the acceptance and efficient operation
of a technical computer system by a human community.
• The system has both a technical and a social dimension - it is a socio-technical
system .
• The project plan will have allowed for the evolution of the technical aspects of
the system with the active involvement of the human community that will
operate it" (Lejk and Deeks, 1998).
Feasibility Study and It’s Types
• The feasibility study is an evaluation and analysis of the potential of a proposed project
which is based on extensive investigation and research to support the process of
decision making.
• It is quantifying benefits and costs
• Payback analysis
• Net Present Value Analysis
• Return on Investment Analysis
Following are different components of the feasibility study:
• Operational feasibility
• Economic feasibility
• Technical feasibility
• Human factors feasibility
• Legal/Political feasibility
Feasibility Study Contents
1. Purpose & scope of the study 5. Possible alternatives
 Objectives (of the study)  …including ‘do nothing’.
 who commissioned it & who did it, 6. Criteria for comparison
 sources of information,  definition of the criteria
 process used for the study,
7. Analysis of alternatives
 how long did it take,…
 description of each alternative
2. Description of present situation  evaluation with respect to criteria
 organizational setting, current system(s).  cost/benefit analysis and special
 Related factors and constraints. implications.
3. Problems and requirements 8. Recommendations
 What’s wrong with the present situation?  what is recommended and implications
 What changes are needed?  what to do next;
4. Objectives of the new system.  E.g. may recommend an interim solution
and a permanent solution
 Goals and relationships between them
9. Appendices
 to include any supporting material.
User Transaction Requirement
• Each user view will involve certain transactions, stipulating
how the data is to be used
• There are three broad categories:
• Data entry: every data item needs to be created somewhere
• Data update and deletion
• Data queries
• Transactions should be related to the user view to ensure all
functions are supported
• Do transactions needed to be atomic
User Design Requirements
• There are tools for guiding the user design process and for
discussing user design requirements with users.
• Mostly, Use Cases are used for this.
• A design specification provides explicit information about the
requirements for a product and how the product is to be put together.
Structure Model / Class Model
Different Views of a System
• A view is a projection into the organization and structure of a
system’s model, focused on one aspect of a system.
• Five most important views :
• Use case view.
• Design view.
• Process view.
• Implementation view.
• Deployment view.
Diagrams
• A diagram is a graphical projection into the
elements that make up a system.
• Each diagram provides a view into the elements
that make up the system.
• Structural diagrams to view the static parts and
Behavioral diagrams to view the dynamic parts of
a system.
Structural Diagrams
• Structure models emphasize the things that must be present in the system
being modeled.
• Since structure diagrams represent the structure, they are used extensively in
documenting the software architecture of software systems.
• The UML’s structural diagrams are used to visualize, specify, construct, and
document the static aspects of a system.
• Static aspects: represent system’s relatively stable skeleton and scaffolding.
• UML’s four/six structural diagrams:
• Class diagrams
• Object diagrams
• Component diagrams
• Deployment diagrams • Composite Structure
• Package
Types of Structural Diagrams
• Class diagram: describes the structure of a system by showing the system's classes,
their attributes, and the relationships among the classes.
• Object diagram: shows a complete or partial view of the structure of a modeled
system at a specific time.
• Component diagram: describes how a software system is split up into components
and shows the dependencies among these components.
• Deployment diagram: describes the hardware used in system implementations and
the execution environments and artifacts deployed on the hardware.
• Composite structure diagram: describes the internal structure of a class and the
collaborations that this structure makes possible.
• Package diagram: describes how a system is split up into logical groupings by
showing the dependencies among these groupings.
Behavioral Model /
State Model
Behavioral Model
• Behavioral models describe the internal dynamic aspects of a system
that supports the business processes in an organization.
• Dynamic aspects: represent a system’s changing parts.
• Behavior diagrams emphasize what must happen in the system being
modeled.
• Since behavior diagrams illustrate the behavior of a system, they are
used extensively to describe the functionality of software systems.
• Diagrams interact by passing events and through side effects of guard
conditions.
• Events and guard conditions must match across diagrams in the model.
• During the analysis phase, analysts use behavioral models to capture a
basic understanding of the dynamic aspects of the underlying business
process.
• During the analysis phase, the structural model presents the logical
organization of data without indicating how the data are stored, created,
or manipulated so that analysts can focus on the business without being
distracted by technical details.
• Later, during the design phase, the structural model is updated to reflect
exactly how the data will be stored in databases and files.
• Traditionally, behavioral models have been used primarily during the
design phase where analysts refine the behavioral models to include
implementation details.
• Behavioral models that are used to represent the underlying details of a
business process portrayed by a use case model.
• In UML, interaction diagrams (sequence and communication) are used for
this type of behavioral model.
• Behavioral model that is used to represent the changes that occur in the
underlying data.
• UML uses behavioral state machines for this.
Types of Behavioural Diagrams
• UML’s three behavioural diagrams:
• Use case diagrams
• State Machine diagrams
• Activity diagrams
• Use case diagram: describes the functionality provided by a system in terms of
actors, their goals represented as use cases, and any dependencies among
those use cases.
• State Machine diagram: describes the states and state transitions of the
system.
• Activity diagram: describes the business and operational step-by-step
workflows of components in a system. An activity diagram shows the overall
flow of control.
Creating Behavioral Model
• An iterative process
• iterating over the individual behavioral models (e.g., interaction
(sequence and communication) diagrams and behavioral state
machines)
• iterating over the functional and structural models.
• As the behavioral models are created, making changes to the structural
models may be required.
Interaction Model
Interaction Diagram
• Interaction diagrams, a subset of behaviour diagrams, emphasize the
flow of control and data among the things in the system being
modeled.
• Used to describe some type of interactions among the different
elements in the model. So this interaction is a part of dynamic
behaviour of the system.
• Purposes of interaction diagram:
• To capture dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe structural organization of the objects.
• To describe interaction among objects.
Types of Interaction Models
• Sequence diagram: shows how objects communicate with each other
in terms of a sequence of messages. Also indicates the lifespans of
objects relative to those messages.
• Communication diagram: shows the interactions between objects or
parts in terms of sequenced messages. They represent a combination of
information taken from Class, Sequence, and Use Case Diagrams
describing both the static structure and dynamic behavior of a system.
• Interaction overview diagram: provides an overview in which the
nodes represent interaction diagrams.
• Timing diagram: are a specific type of interaction diagram, where the
focus is on timing constraints.
Some Extra Points
• Primary purposes of behavioral models
• to show how the underlying objects in the problem domain will collaborate to
support each of the use cases.
• Structural models
• represent the objects and the relationships between them,
• Behavioral models
• depict the internal view of the business process that a use case describes.
• The process can be shown by the interaction
• taking place between the objects that collaborate to support a use case through
the use of interaction diagrams.
• It is also possible to show the effect that the set of use cases that make up the system
has on the objects in the system through the use of behavioral state machines.
Class Modelling
Class Modeling
• Class Modeling : - The process to visualize, specify, construct,
and document the static aspects of a system.
• Static View = Structure = Objects by which system is made
of.
• That’s why, the purpose of class modeling is to describe
objects.
• To complete the class modelling, you have to describe class
diagram and then object diagrams.
Steps during class modeling
• Steps during class modeling
• 1. Class identification
• Based on the fundamental assumption that we can find
abstractions
• 2. Find the attributes
• 3. Find the methods
• 4. Find the associations between classes
Class Identification
1) Perform a grammatical parse of the problem statement or use cases
2) Classes are determined by underlining each noun or noun clause
3) A class should NOT have an imperative procedural name (i.e., a verb)
4) List the potential class names in a table and "classify" each class
according to some taxonomy and class selection characteristics
Potential classes General classification Selection Characteristics
162
• General classifications for a potential class
• External entity (e.g., another system, a device, a person)
• Thing (e.g., report, screen display)
• Occurrence or event (e.g., movement, completion)
• Role (e.g., manager, engineer, salesperson)
• Organizational unit (e.g., division, group, team)
• Place (e.g., manufacturing floor, loading dock)
• Structure (e.g., sensor, vehicle, computer)
163
• Six class selection characteristics
1) Retained information
– Information must be remembered about the system over time
2) Needed services
– Set of operations that can change the attributes of a class
3) Multiple attributes
– Whereas, a single attribute may denote an atomic variable rather
than a class
4) Common attributes
– A set of attributes apply to all instances of a class
5) Common operations
– A set of operations apply to all instances of a class
6) Essential requirements
– Entities that produce or consume information
164
Class Identification - Example
• Manipal University Jaipur wants to make a library management
system for its library.
• Library has 10000 books.
• For memberships of library, there are 2 types : - Faculty &
Students.
• Librarian should issue books.
• There should be functionality to deposit books.
• There are four types of books.
• Magazine
• E-Books
• Journals
• Text Books.
165
Class Identification - Example
Potential classes General classification Selection Characteristics
MUJ External Entity
Library Management Structure
System
Library Organizational Unit
Book External Entity
Membership Role
Faculty External Entity
Student External Entity
Librarian Role
Magazine External Entity
E-Books External Entity
Journals External Entity
Text Books External Entity 166
Defining Attributes of a Class
• Attributes of a class are those nouns from the grammatical parse that
reasonably belong to a class
• Attributes hold the values that describe the current properties or state of
a class
• An attribute may also appear initially as a potential class that is later
rejected because of the class selection criteria
• In identifying attributes, the following question should be answered
• What data items (composite and/or elementary) will fully define a specific
class in the context of the problem at hand?
• Usually an item is not an attribute if more than one of them is to be
associated with a class
167
Defining Operations of a Class
• Operations define the behavior of an object
• Four categories of operations
• Operations that manipulate data in some way to change the state of an object (e.g.,
add, delete, modify)
• Operations that perform a computation
• Operations that inquire about the state of an object
• Operations that monitor an object for the occurrence of a controlling event
• An operation has knowledge about the state of a class and the nature of
its associations
• The action performed by an operation is based on the current values of
the attributes of a class
• Using a grammatical parse again, circle the verbs; then select the verbs
that relate to the problem domain classes that were previously identified.
168
Class Diagram
• Recall: A class is a collection of objects with common structure,
common behavior, common relationships and common semantics
• A class diagram
• expresses class definitions to be implemented
• lists name, attributes, and methods for each class
• shows relationships between classes
• describes the structure of a system.
• Most common diagram.
• The main building block in object oriented modeling.
Where do we use class diagrams
Class diagrams are used in:
• Analysis To build a conceptual domain model with semantic
associations between concepts
• Design Structural model of a design in terms of class interfaces
• Implementation Source code documentation, exposing the
implementation
Class Diagram - Notation
• A class with three
sections. Produt
• The upper part holds serialNumber
the name of the class name
• The middle part price
contains the attributes Class Name
buy()
of the class display()
• The bottom part gives Attributes
the methods or
operations the class Operations
can take or undertake
Class Name - Signature
• Name should start with capital letter.
• It should be noun.
Attributes - Signature
[visibility] name [[multiplicity]] [: type] [=initial value] [{property}]
• First word of the name should start with small letter followed by
capital letter for next words.
• visibility: the access rights to the attribute
- multiplicity: how many instances of the attribute are they:
- middleName [0..1] : String, phoneNumber [1..*]
- Type: the type of the attribute (integer, String, Person, Course)
- initial value: a default value of the attribute
- salary : Real = 10000, position : Point = (0,0)
- property: predefined properties of the attribute
- Changeable, readOnly, addOnly, frozen (C++: const, Java: final)
Attributes - Examples
+ isLightOn : boolean = false
- numOfPeople : int
mySport
+ passengers : Customer[0..10]
- id : long {readOnly}
Operations - Signature
[visibility] name ([parameter-list]) [: return-type] [{property}]
• An operation can have zero or more parameters, each has the

syntax:
• [direction] name : type [=default-value]
• Direction can be: in (input paremter - can’t be modified), out (output
parameter - may be modified), inout (both, may be modified)
• Property:
• {leaf} – concrete operation
• {abstract} – cannot be called directly
• {isQuery} – operation leaves the state of the operation unchanged
• …
• Omit return_type on constructors and when return type is
void
Operations - Examples
What’s the
difference?
+ isLightOn() : boolean
+ addColor(newColor : Color)
+ addColor(newColor : Color) : void
# convertToPoint(x : int, y : int) : Point
- changeItem([in] key : string, [out] newItem :
Item) : int
Class Diagram - Example
Scope & Visibility
• Instance Scope — each instance of the class holds its own value.
• Class Scope — one value is held for all instances of the class (underlined).
Instance scope
Frame
class scope
header : FrameHeader
uniqueID : Long
+ addMessage( m : Message ) : Status

public # setCheckSum()
- encrypt()
protected
- getClassName()
private
• visibility: + public; # protected; - private;

~ package; / derived
• Underline static attributes and methods
• By default, attributes are hidden and operations are visible.
Responsibilities
• Anything that a class knows or does (Contract or
obligation)
• An optional 4th item carried out by attributes and
operations.
• Free-form text.
• One phrase per responsibility.
Account
Responsibilities
-- handles deposits
-- reports fraud to managers
Multiplicity
• It specifies the number of instances of one class that
may relate to a single instance of the associated
class.
• UML diagrams explicitly list multiplicity at the end of
association lines.
• Intervals are used to express multiplicity:
• 1 (exactly one)
• 0..1 (zero or one)
• 1..* (one or more)
• 0..* (zero or more)
• 3..5 (three to five inclusive)
Different levels of detail
 Tips for modeling
 Express as much or as little detail as needed
 Often, a rectangle with a name is enough
 write <<interface>> on top of interfaces'
names
 use italics for an abstract class name
 Perhaps a method or an attribute clarifies
 Simple is good
 Sketches on paper or white board are
effective 10
UML
The main purpose of UML is to

− support communication about the analysis and design of the system
being developed
− support the movement from the problem domain in the "world" to
the solution domain in the machine
 Two views of the same system
•one view has diagrams
•source code is another view
Sometimes it's nice to look at the overview
•Reverse engineer your code with a UML tool to see how your code looks
in UML
6-182 182
UML is a Modeling Language
 UML
− graphical notation to describe software design
− has rules on how to draw models of
classes
associations between classes
message sends between objects
− has become the de facto industry standard
Not official, but everyone uses it
− like a blueprint to show what is going on during analysis, design
and implementation
Some Projects require UML documentation
6-183 183
UML Defined by the Authors
The Unified Modeling Language User Guide, Booch,

Rumbaugh, Jacobson states:
The UML is a language for
▪ visualizing
▪ specifying
▪ constructing
▪ documenting
the artifacts of a software intensive system
6-184 184
First up: Class Diagrams
A class diagram
− expresses class definitions to be implemented
− lists name, attributes, and methods for each class
− shows relationships between classes
UML allows different levels of detail on both the attributes
and the methods of one class
− could be just the the class name in a rectangle
− or like the general form shown on the next slide
6-185 185
Software Specification (Class Name)
attribute
attribute : type
attribute : type = initial value
classAttribute
derivedAttribute
...
method1()
method2(parameter : Type) : return type
abstractMethod()
+publicMethod()
-privateMethod()
#protectedMethod()
classMethod()
...
6-186 186
AccountCollection
- allAccounts : HashMap
+AccountCollection ()
+getAccountWithID (ID: String) : Account
+add(accountToAdd: Account) : boolean
+iterator() : Iterator
Note: iterator is needed by the

bank manager
6-187 187
Sterotypes
Stereotype is a UML element that allows

designers to extend the UML vocabulary
− Often used to distinguish an abstract class name
from an interface, both of which are written in
italic
<<interface>>
Iterator
+hasNext(): boolean
+next(): Object
+remove(): void
6-188 188
Different levels of detail
Tips for modeling

− Express as much or as little detail as needed
− Often, a rectangle with a name is enough
perhaps a method or an attribute clarifies
− Simple is good
− Sketches on paper or white board are effective
6-189 189
Relationships
Three Relationships in UML

1) Dependency
2) Association
3) Generalization
6-190 190
1) Dependency: A Uses Relationship
Dependencies
− occurs when one object depends on another
− if you change one object's interface, you need to
change the dependent object
− arrows point from dependent to needed objects
CardReader
Jukebox
CDCollection
SongSelector
6-191 191
2) Association: Structural Relationship
Association
− a relationship between classes indicates some meaningful or
interesting connection
− Associations can be labeled getAccountWithID for example
− BTW: The box with association is an official UML comment, must have that fold ☺
association
getAccountWithID
Jukebox JukeboxAccountCollection
1 1
6-192 192
Associations
Associations imply
− our knowledge that a relationship must be preserved for some
time (0.01 ms to forever)
Between what objects do we need to remember a relationship?
•Does a Transaction need to remember Account?
•Would AccountCollection need to remember Accounts?
Stores
AccountCollection Account
1 0..*
6-193 193
Notation and Multiplicity Adornments
UML Association:
− a line between two concepts and a name
− they are bi-directional * T
zero or more;
"many"
− can have a multiplicity
− exist in class diagrams 1..*
T one or more
1..52
T one to fifty two
5
Multiplicity T exactly five
adornments
6-194 194
Association
Names • Read these Type-VerbPhrase-Type
• POST is a Point of Sale Terminal)
Store • Not shown here: Attributes and Methods
1
• This just shows associations between objects
Contains
1..*
POST Captures Sale Paid-by Payment

1 1..* 1 1
Airline
1
Employs
1..*
Assigned-to Assigned-to
Person Flight Plane
1 * * 1
1 *
6-195 195
Supervises
Aggregation: A Special Association
Aggregation: whole/part relationships

− An association that models HAS-A relationships
− The objects can exist independently of each other
− No one object is more important than the other
− Place an open diamond on the whole
− School contains a collection of Student objects
School Student
1..* *
− In Java, this is the same as an association, an instance variable,

6-196 no special syntax 196
Composition: A Special Association
Composition: Stronger relationship
− One can not exist without the other
− If the school folds, students live on
but the departments go away with the school
− If a department closes, the school can go on AIC* e.g.
School Department
1 1..*
1..*
*
Student
− Model aggregation or composition? When in doubt, use association (just a
simple line) don't sweat the diff in 335
6-197 197
Sequence Diagrams
 Interaction diagrams describe how groups of objects
collaborate in some behavior
 The UML defines several forms of interaction
diagram, the most common is the sequence diagram
 A class diagram shows a fixed view of a system
 A sequence diagram represents a dynamic view of a
system by capturing message sends over time
− Can document a scenario such as
Dealer deals cards to all players
Withdraw Money when there is enough balance
Withdraw Money when there is not enough balance
6-198 198
Sequence Diagrams
Not good at showing details of algorithms

such as loops and conditional
Good at showing the calls between
participants
Gives a good picture about which participants
are doing which processing
6-199 199
Syntax
Objects are lined up on top in rectangles
Object names :CardReader
Dashed lines represent lifetime of objects
Rectangles are activation lines
− When the object is "alive"
− Activation bar of the receivers of the message is
smaller than the sender's activation bar
Not much detail written
6-200 200
Example
Scenario: The user tries to use an ATM, but the account is not known
6-201 201
Scenario: The user
successfully withdraws
money from an ATM
6-202 202
Software
Engineering
CS3201 [3 1 0 4]
Contents
• Software Engineering: Introduction, Importance, Evaluation, Characteristics, Components.

Software Application; Software Development Process Models: Waterfall Model, Prototyping
Model, Spiral Model, RAD Model, etc., Agile Modelling; Requirement Engineering: Problem
Analysis, Requirement Verification, Requirement Validation Modularity; Software Project
Management: Cost Estimation Project Scheduling, Risk Management, Quality Assurance,
Project Monitoring; Estimation Techniques: Size estimation- LOC Estimation, Function Count,
Cost Estimation, Halstead Size Estimation, Software Design: Analysis Modeling, Functional
modeling, Behavioral Modeling; Unified modeling language; Software Architecture: Data
Design: Data modeling, data structures; Software Maintenance: Maintenances Characteristics,
Maintainability, Maintenances Tasks, Maintenances Side Effects, Current trends- DevOps.
Books to refer
Text Book
• R. Mall, “Fundamental of Software Engineering”, 4th Edition, PHI, 2014
• Ian Summerville, “Software Engineering”, 9th Edition, Addition Wesley,
2002.
Reference Books
• Pankaj Jalote, “Software Engineering a Precise Approach”, Wiley, 2010.
• Roger S. Pressman, “Software Engineering: A Practitioners Approach”,
7th Edition, TMH, 2016.
Estimation Techniques
Software Project Planning
• Before starting to build software, it is essential to plan the entire development
effort in detail
• Software project planning encompasses five major activities
• Estimation, scheduling, risk analysis, quality management planning, and change
management planning
• Estimation determines how much money, effort, resources, and time it will take to
build a specific system or product
• The software team first estimates
• The work to be done
• The resources required
• The time that will elapse from start to finish
• Then they establish a project schedule that
• Defines tasks and milestones
• Identifies who is responsible for conducting each task
• Specifies the inter-task dependencies
What is an estimate?
• According to Webster,
• “the act of appraising or valuing something”
• “a statement of the cost of work to be done”
• PMO defines an estimate as,
• a rough calculation of the costs and the amount of work
prior to the commencement of work.
• When estimating for a project cost we can also
estimate ongoing costs.
• Outputs of an estimation exercise are:
• Project Costs Estimate
• Ongoing Costs Estimate
What are IT costs?
What are IT costs?
Why do we need to estimate?
• To get an idea of the costs of a project.
• To get an idea of the time needed to complete
the project.
• Very important from a scheduling and project
planning standpoint.
• To identify resource needs.
• To identify ongoing costs and resource needs.
Importance of Estimations
• During the planning phase of a project, a first
guess about cost and time is necessary.
• Estimations are often the basis for the decision
to start a project or not.
• Estimations are the foundation for project
planning and for further actions .
→ Estimating is one of the core tasks of project

management, but still considered as black magic !
Software Cost Estimation
• Determine size of the product.
• From the size estimate,
• determine the effort needed.
• From the effort estimate,
• determine project duration, and cost.
Software Cost Estimation
• Three main approaches to estimation:
• Empirical techniques:
• an educated guess based on past experience.
• Heuristic techniques:
• assume that the characteristics to be estimated can
be expressed in terms of some mathematical
expression.
• Analytical techniques:
• derive the required results starting from certain
simple assumptions.
Estimation Techniques
• Expert estimates
• Lines of code
• Function point analysis
• Halstead Size Estimation
• COCOMO Model
Expert Estimates
• = Guess from experienced people
• It is subjective. (consensus is difficult to achieve)
• No better than the participants
• Suitable for a typical projects
• Result justification difficult
• Important when no detailed estimation can be done (due to lacking
information about scope)
• Delphi
• Developed by Rand Corporation in 1940 where participants are involved in two
assessment rounds.
• Work Breakdown Structure (WBS)
• A way of organizing project element into a hierarchy that simplifies the task of
budget estimation and control.
Expert Estimates
• Advantages
• Useful in the absence of quantified, empirical data.
• Can factor in differences between past project experiences
and requirements of the proposed project
• Can factor in impacts caused by new technologies,
applications and languages.
• Disadvantages
• Estimate is only as good expert’s opinion
• Hard to document the factors used by the experts
Size Estimation/Problem Based Estimation
• Here, we subdivide the problem into small problems. When all
the small problems are solved the main problem is solved.
• Lines of Code
• Function Point
• LOC (Lines of Code), FP(Function Point) estimation methods
consider the size as the measure.
• In LOC the cost is calculated based on the number of lines.
• In FP the cost is calculated based on the number of various
functions in the program.
Problem Based Estimation
• For both approaches, the planner uses lessons learned to estimate an
optimistic, most likely, and pessimistic size value for each function or
count (for each information domain value)
• Then the expected size value S is computed as follows:
Optimistic Value,
Most Likely Value
Pessimistic Value
• Once the Expected Value has been determined, Historical (LOC) and
(FP) Productivity data are applied.
Lines of Code Estimation
• The measure was first proposed when programs were typed on
cards with one line per card.
• Traditional way for estimating application size.
• Advantage: Easy to do.
• Disadvantages:
• Focus on developer’s point of view.
• No standard definition for “Line of Code”.
• “You get what you measure”: If the number of lines of code is the primary
measure of productivity, programmers ignore opportunities of reuse.
• Multi-language environments: Hard to compare mixed language projects with
single language projects.
Example - Statement of Scope
• The mechanical CAD software will accept two- and three-dimensional
geometric data from an engineer. The engineer will interact and control
the CAD system through a user interface that will exhibit characteristics of
good human/machine interface design. All geometric data and other
supporting information will be maintained in a CAD database. Design
analysis modules will be developed to produce the required output,
which will be displayed on a variety of graphics devices. The software will
be designed to control and interact with peripheral devices that include a
mouse, digitizer, laser printer.
EXAMPLE OF (LOC) BASED ESTIMATION
FUNCTIONS ESTIMATED LOC
- User Interface and Control Facilities (UICF) 2,300

- Two Dimensional Analysis (2DGA) 5,300
- 3D Geometric Analysis Function (3DGA) 6,800 ***
- Database Management (DBM) 3,350
- Computer Graphic Display facility (CGDF) 4,950
- Peripheral Control Function (PCF) 2,100
- Design Analysis Modules (DAM) 8,400
_____________________________________________________________
TOTAL ESTIMATED LOC (∑ LOC) 33,200
=========================================================
For Example:- Using the Expected Value Equation we can calculate the Estimated Value for
(3DGA) Function as follows:-
Optimistic Estimation = 5,000 LOC

Most Likely Estimation = 6,700 LOC
Pessimistic Estimation = 9,000 LOC
Historical data obtained from the Metrics indicates the following Organizational
Averages:
Average Productivity is 620 LOC / Pm (Lines of Code Per Month)
Average Labor Cost is $8,000 Per month.
Cost for a Line of Code can be calculated as follows (COST / LOC)
COST / LOC = (8000 / 620) = $13
Total Estimated Project Cost and Project Effort can be calculated as: follows-
Considering that the Total LOC ( ∑ LOC) for the System is 33,200
➢ Total Estimated Project Cost = (33200 * 13 ) = $431,600
➢ Total Estimated Project Effort = (33200 / 620) = ~ 54 Man Months

Problems with lines of code estimation
• Creating source code is only a small part of the total software
development effort.
• Programming languages produce the same result with different
lines of code.
• How do you count the lines of code?
• Only executable lines? or include data definitions?
• Include comments?
• What if you use inheritance? Recount inherited lines?
• Not all code written is delivered to the client.
• A code generator can produce thousands of lines of code in a
few minutes.
• Only at when product is final do you know the actual lines of
code.
• LOC is not defined for nonprocedural languages (like LISP).
Function Point Analysis
• Developed by Allen Albrecht, IBM Research, 1979.
• Technique to determine size of software projects.
• Size is measured from a functional point of view.
• Estimates are based on functional requirements.
• Albrecht originally used the technique to predict effort.
• Size is usually the primary driver of development effort.
• Independent of:
• Implementation language and technology
• Development methodology
• Capability of the project team
• A top-down approach based on function types
• Three steps: Plan the count, perform the count, estimate the effort.
How to count functions
• There are two ways to count functions.
• The first way is the traditional Albrecht approach based on the analysis of transactions.
• The second way is based on the data modeling approach (E/R model).
• To do the count, the FP counter has to do the following three steps:
1. Count data function types.
2. Count the transaction function types.
3. Estimate the effort.
• Compute the unadjusted function points (UFP)
• Compute the Value Added Factor (VAF)
• Compute the adjusted Function Points (FA)
• Compute the performance factor
• Calculate the effort in person days
Count data function types
• Data functions are either accessing Internal Logical Files (Maf) or External
Interfaces Files (Inf).
• The count of the MAfs and Infs is done by examining the data model (E/R
model or the attributes of the persistent objects in the object model) or
by asking the system designer for the application’s main categories of
persistent data.
• This count must be done before the transactions function types are
counted, because the complexity of the transactions is dependent on
the way the data access functions are identified.
Count the transaction function types
• Transaction function types are External Inputs (Inp), External Outputs
(Out) or External Queries (Inq).
• This is typically the longest part of the count, and the part where the
system expert's assistance really saves time.
• Complexity of each transaction is based, in part, on the number of data
types it references.
• The system expert can usually make this determination without consulting
any documentation.
Function Points Estimation
• Based on the number of External inputs (Inp), external outputs (Out), external
inquiries (Inq), internal logical files (Maf), external interface files (Inf)
• Input: A set of related inputs is counted as one input.
• Output: A set of related outputs is counted as one output.
• Inquiries: Each user query type is counted.
• Files: Files are logically related data and thus can be data structures or
physical files.
• Interface: Data transfer to other systems.
• For any product, the size in “function points” is given by
FP = 4  Inp + 5  Out + 4  Inq + 10  Maf + 7  Inf
• This is an oversimplification of a 3-step process.

• Step 1. Classify each component of the product (Inp,
Out, Inq, Maf, Inf) as simple, average, or complex
• Assign the appropriate number of function points
• The sum gives UFP (unadjusted function points)
• Step 2. Compute the technical
complexity factor (TCF)
• Assign a value from 0 (“not present”) to 5
(“strong influence throughout”) to each of
14 factors such as transaction rates,
portability
• Add the 14 numbers
• This gives the total degree of influence (DI)
TCF = 0.65 + 0.01  DI
• The technical complexity factor (TCF)

lies between 0.65 and 1.35
• Step 3. The number of function points (FP) is then given by
FP = UFP  TCF
Advantages of Function Point Estimation
• Independent of implementation language and technology
• Estimates are based on design specification
• Usually known before implementation tasks are known
• Users without technical knowledge can be integrated into the
estimation process
• Incorporation of experiences from different organizations
• Easy to learn
• Limited time effort
Disadvantages of Function Point Estimation
• Complete description of functions necessary
• Often not the case in early project stages -> especially in iterative
software processes
• Only complexity of specification is estimated
• Implementation is often more relevant for estimation
• High uncertainty in calculating function points:
• Weight factors are usually deducted from past experiences
(environment, used technology and tools may be out-of-date in the
current project)
• Does not measure the performance of people
Example : Function Point Analysis
Assuming
 Estimated FP = 400
 Organisation average productivity (similar project type) = 6.5
FP/p-m (person-month)
 Burdened labour rate = 8000 $/p-m
Then
 Estimated effort = 400/6.5 = (61.54) = 62 p-m
 Cost per FP = 8000/6.5 = 1231 $/FP
 Project cost = 8000 * 62 = 496000 $
COCOMO (COnstructive COst MOdel)
• Developed by Barry Boehm in 1981.
• Also called COCOMO I or Basic COCOMO or COCOMO’81.
• COCOMO’81 is derived from the analysis of 63 software projects.
• Top-down approach to estimate cost, effort and schedule of software
projects, based on size and complexity of projects.
• Assumptions:
• Derivability of effort by comparing finished projects (“COCOMO database”).
• System requirements do not change during development.
• Exclusion of some efforts (for example administration, training, rollout,
integration).
• Divides software product developments into three (3)
categories:
• Organic : If the team size required is adequately small, the problem is
well understood and has been solved in the past and also the team
members have a nominal experience regarding the problem.
• Semidetached
• Project team consists of a mixture of experienced and inexperienced staff.
• Embedded
• The software is strongly coupled to complex hardware, or real-time systems.
• For each of the three product categories:
• From size estimation (in KLOC), Boehm provides equations to predict:
• project duration in months
• effort in programmer-months
• Boehm obtained these equations by examined historical data

collected from a large number of actual projects.
• Software cost estimation is done through three stages:
• Basic COCOMO,
• Intermediate COCOMO,
• Complete COCOMO.
Basic COCOMO Model
• Gives only an approximate estimation:
• Effort = a1 (KLOC)a2
• Tdev = b1 (Effort)b2
• KLOC is the estimated kilo lines of source code.
• a1,a2,b1,b2 are constants for different categories of software
products.
• Tdev is the estimated time to develop the software in months.
• Effort estimation is obtained in terms of person months (PMs).
Effort Estimation Time Estimation
• Organic :  Organic:
• Effort = 2.4 (KLOC)1.05 PM
 Tdev = 2.5 (Effort)0.38
• Semi-detached: Months
• Effort = 3.0(KLOC)1.12 PM
 Semi-detached:
• Embedded:
• Effort = 3.6 (KLOC)1.20PM
Months
 Embedded:
Months
Basic COCOMO Model
• Effort is somewhat super-linear in problem size.
• Development time sublinear function of product size.
• When product size increases two times, development time
does not double.
• Time taken is almost same for all the three product types.
Dev. Time
Effort 18 Months
14 Months
30K 60K
Size Size
Basic COCOMO Model
• Development time does not increase linearly with product size:
• For larger products more parallel activities can be identified:
• can be carried out simultaneously by a number of engineers.
• Development time is roughly the same for all the three categories
of products:
• For example, a 60 KLOC program can be developed in approximately 18
months
• regardless of whether it is of organic, semi-detached, or embedded type.
• There is more scope for parallel activities for system and application
programs,
• than utility programs.
Example
• The size of an organic software product has been estimated to
be 32,000 lines of source code.
• Effort = 2.4*(32)1.05 = 91 PM
• Nominal development time = 2.5*(91)0.38 = 14 months
Intermediate COCOMO
• Basic COCOMO model assumes
• effort and development time depend on product size alone.
• However, several parameters affect effort and development time:
• Reliability requirements
• Availability of CASE tools and modern facilities to the developers
• Size of data to be handled
• For accurate estimation, the effect of all relevant parameters must be

considered.
• Intermediate COCOMO model recognizes this fact:
• refines the initial estimate obtained by the basic COCOMO by using a set of 15
cost drivers (multipliers).
Intermediate COCOMO
• If modern programming practices are used,
• initial estimates are scaled downwards.
• If there are stringent reliability requirements on the product :
• initial estimate is scaled upwards.
• Rate different parameters on a scale of one to five:
• Depending on these ratings,
• multiply cost driver values with the estimate obtained using the basic
COCOMO.
Cost Drivers Classes
Intermediate COCOMO -Effort Estimation
Effort = a *(KLOC)b * m(x)
 Organic :
 a = 3.2 || b= m(x) = multiply of all
1.05
 Semi-detached: cost drivers factors
 a = 3.0 || b=
1.12
 Embedded:
 a = 2.8 || b=
1.20
Shortcomings of both models
• Both models:
• consider a software product as a single homogeneous entity:
• However, most large systems are made up of several smaller sub-
systems.
• Some sub-systems may be considered as organic type, some may be
considered embedded, etc.
• for some the reliability requirements may be high, and so on.
Complete COCOMO
• Cost of each sub-system is estimated separately.
• Costs of the sub-systems are added to obtain total cost.
• Reduces the margin of error in the final estimate.
• For Example:
• A Management Information System (MIS) for an organization having offices at several
places across the country:
• Database part (semi-detached)
• Graphical User Interface (GUI) part (organic)
• Communication part (embedded)
• Costs of the components are estimated separately:
• summed up to give the overall cost of the system.
COCOMO II
• Revision of COCOMO I in 1997
• Provides three models of increasing detail
• Application Composition Model
• Estimates for prototypes based on GUI builder tools and existing components
• Similar goal as for Function Point analysis
• Based on counting Object Points (instead of function points)
• Early Design Model
• Estimates before software architecture is defined
• For system design phase, closest to original COCOMO, uses function points as size
estimation
• Post Architecture Model
• Estimates once architecture is defined ; Most detailed
• For actual development phase and maintenance; Uses FPs or SLOC as size measure
• Estimator selects one of the three models based on current state of the project.
COCOMO II
• Targeted for iterative software lifecycle models
• Boehm’s spiral model
• COCOMO I assumed a waterfall model
• 30% design; 30% coding; 40% integration and test
• COCOMO II includes new costs drivers to deal with

• Team experience
• Developer skills
• Distributed development
• COCOMO II includes new equations for reuse

• Enables build vs. buy trade-offs
• COCOMO II has 17 multiplicative cost drivers (7 are new).

Application Composition Model
• Supports prototyping projects and projects where there is
extensive reuse.
• Based on standard estimates of developer productivity in
object points/month.
• Takes CASE tool use into account.
• Formula is
• Effort (PM)= ( NOP ´ (1 - %reuse/100 ) ) / PROD
• PM is the effort in person-months, NOP is the number of object
points and PROD is the productivity
Object point productivity
Advantages of COCOMO
• Appropriate for a quick, high-level estimation of project costs.
• Fair results with smaller projects in a well known development
environment.
• Assumes comparison with past projects is possible.
• Covers all development activities (from analysis to testing).
• Intermediate COCOMO yields good results for projects on
which the model is based.
• Tool that automate intermediate COCOMO and COCOMO II
are available.
Problems with COCOMO
• Judgment requirement to determine the influencing factors
and their values.
• Experience shows that estimation results can deviate from
actual effort by a factor of 4.
• Some important factors are not considered:
• Skills of team members, travel, environmental factors, user interface
quality, overhead cost.
Design Concepts
260
Design
• Dr. Dobbs Journal said:
• Good software design should exhibit:
• Firmness: A program should not have any bugs that inhibit
its function.
• Commodity: A program should be suitable for the purposes
for which it was intended.
• Delight: The experience of using the program should be
pleasurable one.
261
Analysis Model -> Design Model
Co m p o n e n t -
sc e na r i o- ba se d f l ow- or i e nt e d L e v e l D e sig n
e l e m e nt s e l e m e nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
In t e r f a c e D e sig n
Analysis Model
A r c h it e c t u r a l D e sig n
c l a ss- ba se d be ha v i or a l
e l e m e nt s e l e m e nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cla ss D e sig n
collaboration diagrams
Design Model
262
Design and Quality
the design must implement all of the explicit requirements
contained in the analysis model, and it must accommodate all
of the implicit requirements desired by the customer.
the design must be a readable, understandable guide for those

who generate code and for those who test and subsequently
support the software.
the design should provide a complete picture of the software,

addressing the data, functional, and behavioral domains from
an implementation perspective.
263
Quality Guidelines
• A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics and (3) can be implemented in an evolutionary fashion
• For smaller systems, design can sometimes be developed linearly.
• A design should be modular; that is, the software should be logically partitioned into
elements or subsystems
• A design should contain distinct representations of data, architecture, interfaces, and
components.
• A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
• A design should lead to components that exhibit independent functional characteristics.
• A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
• A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
• A design should be represented using a notation that effectively communicates its meaning.
264
Design Principles
• The design process should not suffer from ‘tunnel vision.’
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should “minimize the intellectual distance” [DAV95] between the
software and the problem as it exists in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently, even when aberrant
data, events, or operating conditions are encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being created, not after the
fact.
• The design should be reviewed to minimize conceptual (semantic) errors.
265
Fundamental Concepts
• Abstraction—data, procedure, control
• Architecture—the overall structure of the software
• Patterns—”conveys the essence” of a proven design solution
• Separation of concerns—any complex problem can be more easily
handled if it is subdivided into pieces
• Modularity—compartmentalization of data and function
• Hiding—controlled interfaces
• Functional independence—single-minded function and low coupling
• Refinement—elaboration of detail for all abstractions
• Aspects—a mechanism for understanding how global requirements
affect design
• Refactoring—a reorganization technique that simplifies the design
• OO design concepts—Appendix II
• Design Classes—provide design detail that will enable analysis classes
to be implemented
266
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
267
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the

object that is associated with enter
268
Architecture
“The overall structure of the software and the ways in which that structure
provides conceptual integrity for a system.”
Structural properties. This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the manner in which those
components are packaged and interact with one another. For example, objects are
packaged to encapsulate both data and the processing that manipulates the data and
interact via the invocation of methods.
Extra-functional properties. The architectural design description should address how

the design architecture achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon repeatable
patterns that are commonly encountered in the design of families of similar systems. In
essence, the design should have the ability to reuse architectural building blocks.
269
Patterns
Design Pattern Template
Pattern name—describes the essence of the pattern in a short but expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to
implement the pattern
Collaborations—describes how the participants collaborate to carry out their
responsibilities
Consequences—describes the “design forces” that affect the pattern and the potential
trade-offs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns
270
Modularity
• "Modularity is the single attribute of software that allows a
program to be intellectually manageable" [Mye78].
• Monolithic software (i.e., a large program composed of a
single module) cannot be easily grasped by a software
engineer.
• The number of control paths, span of reference, number of variables,
and overall complexity would make understanding close to
impossible.
• In almost all instances, you should break the design into
many modules, hoping to make understanding easier and as a
consequence, reduce the cost required to build the software.
271
Modularity: Trade-offs
What is the "right" number of modules

for a specific software design?
module development cost
cost of
software
module
integration
cost
optimal number number of modules

of modules
272
Information Hiding
module
• algorithm
controlled
interface • data structure
• details of external interface

• resource allocation policy
clients
"secret"
a specific design decision
273
Why Information Hiding?
• reduces the likelihood of “side effects”

• limits the global impact of local design decisions
• emphasizes communication through controlled interfaces
• discourages the use of global data
• leads to encapsulation—an attribute of high quality design
• results in higher quality software
274
Stepwise Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens

turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
275
Sizing Modules: Two Views
What's How big

inside?? is it??
MODULE
276
Functional Independence
Functional independence is achieved by developing modules with "single-

minded" function and an "aversion" to excessive interaction with other
modules.
Cohesion is an indication of the relative functional strength of a

module.
A cohesive module performs a single task, requiring little interaction with
other components in other parts of a program. Stated simply, a cohesive
module should (ideally) do just one thing.
Coupling is an indication of the relative interdependence among

modules.
Coupling depends on the interface complexity between modules, the point
at which entry or reference is made to a module, and what data pass across
the interface.
277
Aspects
• Consider two requirements, A and B. Requirement A crosscuts
requirement B “if a software decomposition [refinement] has been
chosen in which B cannot be satisfied without taking A into account.
• An aspect is a representation of a cross-cutting concern.
278
Aspects—An Example
• Consider two requirements for the SafeHomeAssured.com WebApp.

Requirement A is described via the use-case Access camera surveillance via
the Internet. A design refinement would focus on those modules that would
enable a registered user to access video from cameras placed throughout a space.
Requirement B is a generic security requirement that states that a registered user
must be validated prior to using SafeHomeAssured.com. This requirement is
applicable for all functions that are available to registered SafeHome users. As
design refinement occurs, A* is a design representation for requirement A and B*
is a design representation for requirement B. Therefore, A* and B* are
representations of concerns, and B* cross-cuts A*.
• An aspect is a representation of a cross-cutting concern. Therefore, the design

representation, B*, of the requirement, a registered user must be validated prior to
using SafeHomeAssured.com, is an aspect of the SafeHome WebApp.
279
Refactoring
Fowler defines refactoring in the following manner:
"Refactoring is the process of changing a software system in such a way
that it does not alter the external behavior of the code [design] yet
improves its internal structure.”
When software is refactored, the existing design is examined for

redundancy
unused design elements
inefficient or unnecessary algorithms
poorly constructed or inappropriate data structures
or any other design failure that can be corrected to yield a better
design.
280
OO Design Concepts
• Design classes
• Entity classes
• Boundary classes
• Controller classes
• Inheritance—all responsibilities of a superclass is
immediately inherited by all subclasses
• Messages—stimulate some behavior to occur in the
receiving object
• Polymorphism—a characteristic that greatly reduces the
effort required to extend the design
281
Design Classes
• Analysis classes are refined during design to become entity
classes
• Boundary classes are developed during design to create
the interface (e.g., interactive screen or printed reports)
that the user sees and interacts with as the software is
used.
• Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
• Controller classes are designed to manage
• the creation or update of entity objects;
• the instantiation of boundary objects as they obtain
information from entity objects;
• complex communication between sets of objects;
• validation of data communicated between objects or
between the user and the application.
282
The Design Model
high
a na ly sis m ode l
class diagrams
analysis packages
use-cases - t ext class diagrams
Requirement s:
CRC models use-case diagrams const raint s
analysis packages
collaborat ion diagrams
act ivit y diagrams CRC models int eroperabilit y
dat a f low diagrams sw im lane diagrams collaborat ion diagrams t arget s and
cont rol-f low diagrams collaborat ion diagrams dat a f low diagrams
processing narrat ives st at e diagrams cont rol-f low diagrams
conf igurat ion
sequence diagrams processing narrat ives
st at e diagrams
sequence diagrams
design class realizat ions

subsyst ems
collaborat ion diagrams t echnical int erf ace component diagrams
design class realizat ions
design design classes
subsyst ems
Navigat ion design act ivit y diagrams
collaborat ion diagrams
GUI design sequence diagrams
component diagrams
de sign m ode l design classes
ref inement s t o: act ivit y diagrams
ref inement s t o: sequence diagrams
component diagrams
design class realizat ions design classes
subsyst ems act ivit y diagrams
low collaborat ion diagrams sequence diagrams deployment diagrams
archit ect ure int erface component -level deployment -level

element s element s element s element s
process dimension
283
Design Model Elements
• Data elements
• Data model --> data structures
• Data model --> database architecture
• Architectural elements
• Application domain
• Analysis classes, their relationships, collaborations and
behaviors are transformed into design realizations
• Patterns and “styles”
• Interface elements
• the user interface (UI)
• external interfaces to other systems, devices, networks
or other producers or consumers of information
• internal interfaces between various design components.
• Component elements
• Deployment elements
284
Architectural Elements
• The architectural model is derived from

three sources:
• information about the application domain for the
software to be built;
• specific requirements model elements such as data
flow diagrams or analysis classes, their
relationships and collaborations for the problem at
hand, and
• the availability of architectural patterns and styles
.
285
Interface Elements
Mo b ile Ph o n e
W ire le ssPDA
Co n t ro lPa n e l
LCDdi s pl ay
LEDi ndi c at or s
k ey PadChar ac t er i s t i c s K e y Pa d
s peak er
wi r el es s Int er f ac e
r eadK ey St r ok e( )
dec odeK ey ( )
di s pl ay St at us ( )
l i ght LEDs ( )
s endCont r ol Ms g( )
< < in t e rf a c e > >

K e y Pa d
r eadKey s t r ok e( )
dec odeK ey ( )
Fig u re 9 . 6 UML in t e rf a c e re p re se n t a t io n f o r Co n t r o l P a n e l
286
Component Elements
SensorManagement
Sensor
287
Deployment Elements
Cont rol Panel CPI serv er
Security homeownerAccess
Per sonal comput er
externalAccess
Security Surveillance
homeManagement communication
Figure 9 . 8 UML deploy m ent diagram f or Saf eHom e
288
Why Architecture?
The architecture is not the operational software. Rather, it is a

representation that enables a software engineer to:
(1) analyze the effectiveness of the design in meeting its
stated requirements,
(2) consider architectural alternatives at a stage when making
design changes is still relatively easy, and
(3) reduce the risks associated with the construction of the
software.
289
Why is Architecture Important?
• Representations of software architecture are an enabler for communication between all
parties (stakeholders) interested in the development of a computer-based system.
• The architecture highlights early design decisions that will have a profound impact on all
software engineering work that follows and, as important, on the ultimate success of the
system as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable mode of how the system is
structured and how its components work together” [BAS03].
290
Architectural Descriptions
• The IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended Practice for
Architectural Description of Software-Intensive System, [IEE00]
• to establish a conceptual framework and vocabulary for use during the design of software architecture,
• to provide detailed guidelines for representing an architectural description, and
• to encourage sound architectural design practices.
• The IEEE Standard defines an architectural description (AD) as a “a collection of products to document
an architecture.”
• The description itself is represented using multiple views, where each view is “a representation of a whole system
from the perspective of a related set of [stakeholder] concerns.”
291
Architectural Genres
• Genre implies a specific category within the overall software domain.

• Within each category, you encounter a number of subcategories.
• For example, within the genre of buildings, you would encounter the
following general styles: houses, condos, apartment buildings, office
buildings, industrial building, warehouses, and so on.
• Within each general style, more specific styles might apply. Each style would
have a structure that can be described using a set of predictable patterns.
292
Architectural Styles
Each style describes a system category that encompasses: (1) a
set of components (e.g., a database, computational modules)
that perform a function required by a system, (2) a set of
connectors that enable “communication, coordination and
cooperation” among components, (3) constraints that define
how components can be integrated to form the system, and
(4) semantic models that enable a designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts.
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures
293
Data-Centered Architecture
294
Data Flow Architecture
295
Call and Return Architecture
296
Layered Architecture
297
Architectural Patterns
• Concurrency—applications must handle multiple tasks in a
manner that simulates parallelism
• operating system process management pattern
• task scheduler pattern
• Persistence—Data persists if it survives past the execution of the
process that created it. Two patterns are common:
• a database management system pattern that applies the storage
and retrieval capability of a DBMS to the application architecture
• an application level persistence pattern that builds persistence
features into the application architecture
• Distribution— the manner in which systems or components
within systems communicate with one another in a distributed
environment
• A broker acts as a ‘middle-man’ between the client component and
a server component.
298
Architectural Design
• The software must be placed into context
• the design should define the external entities (other systems, devices,
people) that the software interacts with and the nature of the interaction
• A set of architectural archetypes should be identified
• An archetype is an abstraction (similar to a class) that represents one
element of system behavior
• The designer specifies the structure of the system by defining and
refining software components that implement each archetype
299
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
300
Archetypes
Cont roller
communicat es wit h
Node
Det ect or Indicat or
Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
(adapt ed f rom [ BOS00] ) 301
Component Structure
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Securit y Surveillance Home

management
GUI Int ernet

Int erface
Cont rol det ect or alarm

panel management processing
processing
302
Refined Component Structure
SafeHome
Executive
Ext ernal
Communicat ion
Management
Security
GUI Internet
Interface
Cont rol det ect or alarm

panel m anagem ent processing
processing
Key pad
processing phone
scheduler
com m unicat ion
CP display
funct ions
alarm
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
303
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen
to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis conducted in step 5.
304
Architectural Complexity
• the overall complexity of a proposed architecture is assessed by
considering the dependencies between components within the
architecture [Zha98]
• Sharing dependencies represent dependence relationships among consumers
who use the same resource or producers who produce for the same
consumers.
• Flow dependencies represent dependence relationships between producers
and consumers of resources.
• Constrained dependencies represent constraints on the relative flow of control
among a set of activities.
305
ADL
• Architectural description language (ADL) provides a semantics and syntax

for describing a software architecture
• Provide the designer with the ability to:
• decompose architectural components
• compose individual components into larger architectural blocks and
• represent interfaces (connection mechanisms) between components.
306
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
307
Deriving Program Architecture
Program
Architecture
308
Partitioning the Architecture
• “horizontal” and “vertical”
partitioning are required
309
Horizontal Partitioning
• define separate branches of the module
hierarchy for each major function
• use control modules to coordinate
communication
function 1 betweenfunction
functions
3
function 2
310
Vertical Partitioning: Factoring
• design so that decision making and
work are stratified
• decision making modules should
reside at the top of the architecture
decision-makers
workers
311
Why Partitioned Architecture?
• results in software that is easier to test

• leads to software that is easier to maintain
• results in propagation of fewer side effects
• results in software that is easier to extend
312
Structured Design
• objective: to derive a program
architecture that is partitioned
• approach:
• a DFD is mapped into a program
architecture
• the PSPEC and STD are used to
indicate the content of each module
• notation: structure chart
313
Flow Characteristics
Transform flow
This edition of
SEPA does not
cover transaction
mapping. For a
detailed
discussion see the
SEPA website
Transaction
flow
314
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map

DFD transforms into corresponding modules
add control modules as required
refine the resultant program structure

using effective modularity concepts
315
Software Quality
• In 2005, ComputerWorld [Hil05] lamented that
• “bad software plagues nearly every organization that uses computers, causing lost work hours during computer
downtime, lost or corrupted data, missed sales opportunities, high IT support and maintenance costs, and low
customer satisfaction.
• A year later, InfoWorld [Fos06] wrote about the
• “the sorry state of software quality” reporting that the quality problem had not gotten any better.
• Today, software quality remains an issue, but who is to blame?

• Customers blame developers, arguing that sloppy practices lead to low-quality software.
• Developers blame customers (and other stakeholders), arguing that irrational delivery dates and a continuing
stream of changes force them to deliver software before it has been fully validated.
Quality
• The American Heritage Dictionary defines quality as

• “a characteristic or attribute of something.”
• For software, two kinds of quality may be encountered:
• Quality of design encompasses requirements, specifications, and the
design of the system.
• Quality of conformance is an issue focused primarily on implementation.
• User satisfaction = compliant product + good quality + delivery within
budget and schedule
Quality—A Pragmatic View
• The transcendental view argues (like Persig) that quality is something that you immediately
recognize, but cannot explicitly define.
• The user view sees quality in terms of an end-user’s specific goals. If a product meets those goals,
it exhibits quality.
• The manufacturer’s view defines quality in terms of the original specification of the product. If the
product conforms to the spec, it exhibits quality.
• The product view suggests that quality can be tied to inherent characteristics (e.g., functions and
features) of a product.
• Finally, the value-based view measures quality based on how much a customer is willing to pay
for a product. In reality, quality encompasses all of these views and more.
Software Quality
• Software quality can be defined as:

• An effective software process applied in a manner that creates a useful product that
provides measurable value for those who produce it and those who use it.
• This definition has been adapted from [Bes04] and replaces a more
manufacturing-oriented view presented in earlier editions of this book.
Effective Software Process
• An effective software process establishes the infrastructure that supports any effort at building a
high quality software product.
• The management aspects of process create the checks and balances that help avoid project
chaos—a key contributor to poor quality.
• Software engineering practices allow the developer to analyze the problem and design a solid
solution—both critical to building high quality software.
• Finally, umbrella activities such as change management and technical reviews have as much to
do with quality as any other part of software engineering practice.
Useful Product
• A useful product delivers the content, functions, and features that the
end-user desires
• But as important, it delivers these assets in a reliable, error free way.
• A useful product always satisfies those requirements that have been
explicitly stated by stakeholders.
• In addition, it satisfies a set of implicit requirements (e.g., ease of
use) that are expected of all high quality software.
Adding Value
• By adding value for both the producer and user of a software product, high quality
software provides benefits for the software organization and the end-user
community.
• The software organization gains added value because high quality software
requires less maintenance effort, fewer bug fixes, and reduced customer
support.
• The user community gains added value because the application provides a
useful capability in a way that expedites some business process.
• The end result is:
• (1) greater software product revenue,
• (2) better profitability when an application supports a business process, and/or
• (3) improved availability of information that is crucial for the business.
Quality Dimensions
• David Garvin [Gar87]:
• Performance Quality. Does the software deliver all content, functions, and features
that are specified as part of the requirements model in a way that provides value to
the end-user?
• Feature quality. Does the software provide features that surprise and delight first-
time end-users?
• Reliability. Does the software deliver all features and capability without failure? Is
it available when it is needed? Does it deliver functionality that is error free?
• Conformance. Does the software conform to local and external software standards
that are relevant to the application? Does it conform to de facto design and coding
conventions? For example, does the user interface conform to accepted design rules
for menu selection or data input?
Quality Dimensions
• Durability. Can the software be maintained (changed) or corrected (debugged)
without the inadvertent generation of unintended side effects? Will changes cause
the error rate or reliability to degrade with time?
• Serviceability. Can the software be maintained (changed) or corrected (debugged)
in an acceptably short time period. Can support staff acquire all information they
need to make changes or correct defects?
• Aesthetics. Most of us would agree that an aesthetic entity has a certain elegance, a unique
flow, and an obvious “presence” that are hard to quantify but evident nonetheless.
• Perception. In some situations, you have a set of prejudices that will influence your
perception of quality.
Other Views
• McCall’s Quality Factors (SEPA, Section 14.2.2)

• ISO 9126 Quality Factors (SEPA, Section 14.2.3)
• Targeted Factors (SEPA, Section 14.2.4)
The Software Quality Dilemma
• If you produce a software system that has terrible quality, you lose because no
one will want to buy it.
• If on the other hand you spend infinite time, extremely large effort, and huge
sums of money to build the absolutely perfect piece of software, then it's going
to take so long to complete and it will be so expensive to produce that you'll be
out of business anyway.
• Either you missed the market window, or you simply exhausted all your
resources.
• So people in industry try to get to that magical middle ground where the
product is good enough not to be rejected right away, such as during evaluation,
but also not the object of so much perfectionism and so much work that it would
take too long or cost too much to complete. [Ven03]
“Good Enough” Software
• Good enough software delivers high quality functions and features that
end-users desire, but at the same time it delivers other more obscure or
specialized functions and features that contain known bugs.
• Arguments against “good enough.”
• It is true that “good enough” may work in some application domains and for a few
major software companies. After all, if a company has a large marketing budget and
can convince enough people to buy version 1.0, it has succeeded in locking them in.
• If you work for a small company be wary of this philosophy. If you deliver a “good
enough” (buggy) product, you risk permanent damage to your company’s
reputation.
• You may never get a chance to deliver version 2.0 because bad buzz may cause your
sales to plummet and your company to fold.
• If you work in certain application domains (e.g., real time embedded software,
application software that is integrated with hardware can be negligent and open
your company to expensive litigation.
Cost of Quality
• Prevention costs include
• quality planning
• formal technical reviews
• test equipment
• Training
• Internal failure costs include
• rework
• repair
• failure mode analysis
• External failure costs are
• complaint resolution
• product return and replacement
• help line support
• warranty work
Cost
• The relative costs to find and repair an error or defect increase dramatically as
we go from prevention to detection to internal failure to external failure costs.
Quality and Risk
• “People bet their jobs, their comforts, their safety, their entertainment, their
decisions, and their very lives on computer software. It better be right.” SEPA,
Chapter 1
• Example:
• Throughout the month of November, 2000 at a hospital in Panama, 28 patients received
massive overdoses of gamma rays during treatment for a variety of cancers. In the months
that followed, five of these patients died from radiation poisoning and 15 others developed
serious complications. What caused this tragedy? A software package, developed by a U.S.
company, was modified by hospital technicians to compute modified doses of radiation for
each patient.
Negligence and Liability
• The story is all too common. A governmental or corporate entity hires a
major software developer or consulting company to analyze requirements
and then design and construct a software-based “system” to support
some major activity.
• The system might support a major corporate function (e.g., pension management)
or some governmental function (e.g., healthcare administration or homeland
security).
• Work begins with the best of intentions on both sides, but by the time the
system is delivered, things have gone bad.
• The system is late, fails to deliver desired features and functions, is error-
prone, and does not meet with customer approval.
• Litigation ensues.
Quality and Security
• Gary McGraw comments [Wil05]:
• “Software security relates entirely and completely to quality. You must think
about security, reliability, availability, dependability—at the beginning, in the
design, architecture, test, and coding phases, all through the software life cycle
[process]. Even people aware of the software security problem have focused on
late life-cycle stuff. The earlier you find the software problem, the better. And
there are two kinds of software problems. One is bugs, which are
implementation problems. The other is software flaws—architectural problems
in the design. People pay too much attention to bugs and not enough on flaws.”
Achieving Software Quality
• Critical success factors:

• Software Engineering Methods
• Project Management Techniques
• Quality Control
• Quality Assurance
Thank You

Software Engineering

Uploaded by

Copyright:

Available Formats

You might also like

Software Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

Software

• Software Engineering: Introduction, Importance, Evaluation, Characteristics, Components.

• Software engineering is the application of a systematic, disciplined,

• Complex = composed of many simple parts

• Complicated = not well understood, or explained

First law of software engineering

Software Engineer’s task:

May be the Programmer’s task:

Typing in XYZ valid. Account

E How may F Release

Why is Software Engineering important?

Complex systems need a disciplined approach for designing,

Software Development Crises

Software errors….the cost

Errors in computer software can

Saturday 3rd October 2009-London, England (CNN)

• Dozens of flights from the UK were delayed Saturday after a

• The agency said it reverted to backup equipment as

• Read more at:

• European Space Agency spent 10 years and $7 billion to

• Crash after 36.7 seconds.

• Caused by an overflow error. Trying to store a 64-bit

• Watch the video: http://www.youtube.com/watch?v=z-

• Considered the largest ambulance service in the world.

• It was unable to keep track of the ambulances and their

• Generates many exceptions messages.

 The term software engineering first appeared in the 1968 NATO

 “.. An engineering discipline that is concerned with all aspects

• Customized or bespoke products.

Software Engineering vs. Computer Science

“Computer science is no more about computers than

Computer Science Software Engineering

• Theory. • Practicalities of software

Software Engineering vs. Systems Engineering

Systems Engineering Software Engineering

• All aspects of computer- • Deals with the design,

• The Five Drivers of Software Engineering

Features of such logical system:

Select the critical attributes and plan how to achieve them

What is a Software Process?

 Activities and results that produce a software product:

SW Process Activity What is going on there?

What does the customer need?

Development Design & programming.

Validation Checking whether it meets requirements.

Evolution Modifications (e.g. customer/market).

What is a Software Process Model?

Examples of views Focus on…

Activities = human actions.

Activities = transformations of information.

Software Process Models

assembled form existing

The Cost of Software Engineering

 Each generic approach has a different profile of cost distribution.

 For custom software, evolution costs often exceed development costs.

Specification Iterative Development System testing

Component-based Software Engineering