Unit 1 OOSE

MRS.D.SARAL JEEVA JOTHI
ASST. PROFESSOR
DEPT OF CSE
VELAMMAL ENGINEERING COLLEGE

OBJECTIVES
 To understand the phases in a software project
 To understand fundamental concepts of requirements engineering and Analysis
Modeling.
 To understand the basics of object oriented concept
 To understand the major considerations for enterprise integration and deployment.
 To learn various testing and project management techniques

COURSE OUTCOMES
CO. NO. COURSE OUTCOME
BLOOM
S LEVEL
At the end of the course students will be able to
CO 1 Compare different process models. C4
CO 2
Formulate Concepts of requirements engineering
and Analysis Modeling.
C4
CO 3
To understand the fundamentals of object
oriented concept
C3
CO 4 Apply systematic procedure for software design C4
CO 5 Find errors with various testing techniques C4
CO6 Evaluate project schedule, estimate project cost
and effort required
C5

SYLLABUS
UNIT-I Software Process and Agile Development 9
Introduction to Software Engineering, Software Process, Perspective and Specialized
Process Models – Introduction to Agility – Agile process – Extreme programming – XP
process - Estimation-FP,LOC and COCOMO I and II,Risk Management, Project
Scheduling.
UNIT-II Requirements Analysis and Specification 9
Software Requirements: Functional and Non-Functional, User requirements, Software
Requirements Document – Requirement Engineering Process: Feasibility Studies,
Requirements elicitation and analysis, requirements validation, requirements management-
Classical analysis: Structured system Analysis, Petri Nets
UNIT III- Object Oriented Concepts 9
Introduction to OO concepts, UML Use case Diagram,Class Diagram-Object Diagram-
Component Diagram-Sequence and Collaboration-Deployment-Activity Diagram-Package
Diagram

UNIT-IV Software Design 9
Design Concepts- Design Heuristic – Architectural Design –Architectural styles,
Architectural Design, Architectural Mapping using Data Flow- User Interface
Design: Interface analysis, Interface Design –Component level Design: Designing
Class based components.
UNIT-V Testing and Management 9
Software testing fundamentals- white box testing- basis path testing-control
structure testing-black box testing- Regression Testing – Unit Testing – Integration
Testing – Validation Testing – System Testing And Debugging –Reengineering
process model – Reverse and Forward Engineering.
Total: 45 Periods

LEARNING RESOURCES:
TEXT BOOKS
1.Roger S. Pressman, “Software Engineering – A Practitioner’s Approach”, Eighth Edition, McGraw-Hill
International Edition, 2019.(Unit I,II,IV,V)
2. Ian Sommerville, “Software Engineering”, Global Edition, Pearson Education Asia, 2015.(Unit I,II,III)
3.Bernd Bruegge& Allen H. Dutoit Object-oriented software engineering using UML, patterns, and Java
,Prentice hall ,3rd Edition 2010.(Unit III)
REFERENCES
4.Titus Winters,Tom Manshreck& Hyrum Wright, Software Engineering at Google,lessons learned from
programming over time, O’ REILLY publications,2020. (Unit I,II,IV,V)
5.Rajib Mall, “Fundamentals of Software Engineering”, Third Edition, PHI Learning Private Limited, 2009.
(Unit I,II,IV,V)
6.PankajJalote, “Software Engineering, A Precise Approach”, Wiley India, 2010 (Unit I,II,IV,V)
ONLINE LINKS
1.http://www.nptelvideos.in/2012/11/software-engineering.html
2. https://nptel.ac.in/courses/106/101/106101061/

Introduction to Software Engineering

A software is a computer programs along with the associated documents and the configuration data that
make these programs operate correctly.
A program is a set of instructions (written in form of human-readable code) that performs a specific task.
Engineering is the application of scientific and practical knowledge to invent, design, build, maintain,
and improve frameworks, processes, etc.
Software encompasses: (1) instructions (computer programs) that when executed provide desired features,
function, and performance; (2) data structures that enable the programs to adequately store and manipulate
information and (3) documentation that describes the operation and use of the programs.

Software Engineering
• Software engineering is an engineering discipline that’s applied to the
development of software in a systematic approach (called a software process).
• It’s the application of theories, methods, and tools to design build a software that
meets the specifications efficiently, cost-effectively, and ensuring quality.
• It’s not only concerned with the technical process of building a software, it also
includes activities to manage the project, develop tools, methods and theories that
support the software production.
The IEEE definition:
The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software.

Computer Science Vs Software Engineering
Computer science focuses on the theory and fundamentals, like algorithms,
programming languages, theories of computing, artificial intelligence, and hardware
design
Software Engineering is concerned with the activities of developing and managing
a software.

11
Hardware vs. Software
Hardware Software
 Manufactured
 Wears out
 Built using
components
 Relatively
simple
Developed/Engineered
 Deteriorates
 Custom built
 Complex

Why is Software Engineering required?
Software Engineering is required due to the following reasons:
• To manage Large software
• For more Scalability
• To minimize software cost
• To make reliable software
• For better quality Management

Software Engineers
The job of a software engineer is difficult. It has to balance between different people
involved, such as:
• Dealing with users: User don’t know what to expect exactly from the software.
The concern is always about the ease of use and response time.
• Dealing with technical people: Developers are more technically inclined people
so they think more of database terms, functionality, etc.
• Dealing with management: They are concerned with return on their investment,
and meeting the schedule.

Characteristics of a good software engineer
The features that good software engineers should possess are as follows:
• Exposure to systematic methods, i.e., familiarity with software engineering
principles.
• Good technical knowledge of the project (Domain knowledge).
• Good programming abilities.
• Good communication skills. These skills comprise of oral, written, and
interpersonal skills.
• High motivation.
• Ability to work in a team, etc.,

A Layered Technology
15
a “quality” focus
process model
methods
tools

1. Process layer :
• The foundation for software engineering is the process layer.
• Provides the glue that holds the layers together
• enables balanced and timely development
• It defines a framework that must be established for effective delivery of software
engineering technology.
2. Method:
• It provides technical how-to for building software.
• It encompasses many tasks including communication, requirement analysis,
design modeling, program construction, testing and support.

3. Tools:
• It provide automated or semi-automated support for the process and methods.
• When tools are integrated the information created by one tool can be used by
another for software development.
Example: Rational Rose, CASE tools
4. Quality Focus:
• Quality Focus Engineering approach must rely on quality, Total Quality
Management (TQM), six sigma leads to continuous improvement in culture.
• This culture ultimately helps to develop more effective approaches to SE.

TYPES OF SOFTWARE PRODUCTS:
1. 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.
2. 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 costs
• Software costs often dominate computer system costs. The costs of software on a
PC are often greater than the hardware cost.
• Software costs more to maintain than it does to develop. For systems with a long
life, maintenance costs may be several times development costs.
• Software engineering is concerned with cost-effective software development.

Types of software :
Software is a set of programs, which is designed to perform a well-defined function.
A program is a sequence of instructions written to solve a particular problem.
1. System Software
2. Application Software

1.System Software
• The system software is a collection of programs designed to operate, control, and
extend the processing capabilities of the computer itself.
• System software is generally prepared by the computer manufacturers. These
software products comprise of programs written in low-level languages, which
interact with the hardware at a very basic level.
• System software serves as the interface between the hardware and the end users.
Examples :
Operating System
Compilers
Interpreter
Assemblers, etc.

2. Application Software
• Application software products are designed to satisfy a particular need of a
particular environment.
• Application software may consist of a single program, such as Microsoft's notepad
for writing and editing a simple text.
• It may also consist of a collection of programs, often called a software package,
which work together to accomplish a task, such as a spreadsheet package.
Examples :
Student Record Software
Railways Reservation Software
Microsoft Office Suite Software
Microsoft Word
Microsoft Excel
Microsoft PowerPoint

However, there also exists another classification of the software. They can easily be
classified on the basis of their availability as well as sharability.
1. Freeware
• Software are available free of cost.
• A user can easily download them from the internet and can easily use them without
paying any charges or fees.
examples :
Adobe Reader
Skype
Team Viewer
Yahoo Messenger

2. Shareware
• This software is distributed freely to users on a fixed trial basis.
• It generally comes with a set time limit, and on the expiration of the time limit,
the user is finally asked to pay a fixed fee for the continued services.
Example:
Adobe
PHP Debugger
WinZip
Getright

3. Open-source
• Such types of software are usually available to users along with their source code
which means that the user can easily modify and distribute the software as well as
add additional features to them.
• They can either be chargeable or free.
examples :
Mozilla Firefox
Apache Web Server

Types of Software Applications
1.Real time software:
-It interacts with the user.
Eg: video conferencing
2.Business System software:
-It users one or more database for business information storage
Eg: library management, HR management
3.System software:
-It interacts with hardware components so t hat other application software can run
on it
Eg: compilers, editors, file management utilities
4. Embedded software:
-resides within a product or system. (key pad control of a microwave oven, digital
function of dashboard display in a car).

5.Personal computer software:
-This includes database management,entertainment,computer graphics, multimedia and so
on.
Eg: CAD programs
6.Web based software:
-These are applications that executes on a remote computer and that are accessed by users
from their own PC’s
Eg: e-commerce application
7.AI software:
-It uses algorithms to solve problems that are not open to simple computing and analysis.
Eg: pattern matching(voice or image)
8.Engineering/scientific software:
-Characterized by “number crunching”algorithms. such as automotive stress analysis,
molecular biology, orbital dynamics etc

Program vs. Software
Software is more than programs. Any program is a subset of software, and it
becomes software only if documentation & operating procedures manuals are
prepared.
There are three components of the software:

1. Program: Program is a combination of source code & object code.
2. Documentation: Documentation consists of different types of manuals.
Examples of documentation manuals are: Data Flow Diagram, Flow Charts, ER
diagrams, etc.

3. Operating Procedures: Operating Procedures consist of instructions to set up
and use the software system and instructions on how react to the system failure.
Example of operating system procedures manuals is: installation guide, Beginner's
guide, reference guide, system administration guide, etc.

Software Process
The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program and how
they are to be used.
A software process (also knows as software methodology) is a set of related
activities that leads to the production of the software. These activities may involve
the development of the software from the scratch, or, modifying an existing system.
Any software process must include the following four activities:
1.Software specification
2.Software development
3.Software verification and validation
4.Software evolution

1.Software specification (requirements analysis/planning):
-Where the customers and engineers define the software that is to be produced and the
constraints on its operation
-Define the main functionalities of the software and the constrains around them.
2.Software development (design and implementation/coding):
-Where the software is designed and programmed.
-The software to meet the requirement must be produced.
3.Software verification and validation (testing):
-Where the software is checked to ensure that it is what the customer required.
(The software must be validated to ensure that it does what the customer wants)
4.Software evolution (software maintenance):
-Where the software is being modified to meet changing customer and market requirements.
In practice, they include sub-activities such as requirements validation, architectural
design, unit testing, …etc.

Improvement of software development processes:
• ISO 9000
• Software Process Improvement and Capability Determination(SPICE)
• Capability Maturity Model(CMM)
• Personal Software Process(PSP)
• Team Software Process(TSP)

GENERIC PROCESS MODEL
• A process was defined as a collection of work activities, actions and tasks that are
performed when some work product is to be created.
• Each of this activities, action, tasks resides within a “framework or model” that
defines their relationship with the process and with one another.

Five Activities of a Generic Process Framework
1) Communication: communicate with customer to understand objectives and
gather requirements
2) Planning: creates a “map” defines the work by describing the tasks, risks and
resources, work products and work schedule.
3) Modeling: Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
4) Construction: code generation and the testing.
5) Deployment: Delivered to the customer who evaluates the products and provides
feedback based on the evaluation.
In addition a set of “umbrella activities” for project tracking and control, quality
assurance are applied through out the process.

PROCESS FLOW
1.Linear process flow
It executes each of the five framework activities in sequence beginning with
the communication and ends with deployment.
2.Iterative process flow
Repeats one or more of the activities before proceeding to the next level.
3.Evolutionary process flow
It executes the activities in a circular manner.
4.Parallel process flow
Executes one or more activities in parallel with other activities.

Each phase has three components:
1.Set of activities - This is what you do
2.Set of deliverables - This is what you produce.
3.Quality Control Measures - This is what you use to evaluate the deliverables.
Com m unic at ion
Planning
Modeling
Const r uc t ion
Deploy m ent
analysis
design
code
t est
projec t init iat ion
requirem e
nt gat hering estimating
scheduling
tracking
deliv ery
s upport
f eedbac k

Software Development Life Cycle (SDLC)
• A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software process.
• It describes entry and exit criteria for each phase.
• Without SDLC it becomes tough for software project managers to monitor the
progress of the project.
• It aims to produce successful software products.
• Each process model follows a series of phase unique to its type to ensure success
in the steps of software development.

Need of SDLC
• When a team is developing a software product, there must be a clear
understanding among team representative about when and what to do. Otherwise,
it would point to chaos and project failure.
• Software life cycle model describes entry and exit criteria for each phase.
• A phase can begin only if its stage-entry criteria have been fulfilled. So without a
software life cycle model, the entry and exit criteria for a stage cannot be
recognized.
• Without software life cycle models, it becomes tough for software project
managers to monitor the progress of the project.

SIX PHASES IN SOFTWARE DEVELOPMENT LIFE
CYCLE MODEL
There are following six phases in every Software development life cycle model
1. Requirement gathering and analysis
2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance

Stage1: Requirement gathering and analysis
• Requirement Analysis is the most important and necessary stage in SDLC.
• Business requirements are gathered in this phase.
• This phase is the main focus of the project managers and stake holders.
• Meetings with managers, stake holders and users are held in order to determine the
requirements like
 Who is going to use the system?
 How will they use the system?
 What data should be input into the system?
 What data should be output by the system?
• These are general questions that get answered during a requirements gathering phase.
• After requirement gathering these requirements are analyzed for their validity
• Finally, a Software Requirement Specification (SRS) document is created which serves
the purpose of guideline for the next phase of the model.

Stage2: Design
• In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase.
• System Design helps in specifying
hardware and system requirements
helps in defining overall system architecture.
• The system design specifications serve as input for the next phase of the model.

Stage 3: Implementation / Coding
• On receiving system design documents, the work is divided in modules/units and
actual coding is started.
• In this phase the code is produced so it is the main focus for the developer.
• This is the longest phase of the software development life cycle.

Stage 4: Testing
• After the code is developed it is tested against the requirements to make sure that
the product is actually solving the needs addressed and gathered during the
requirements phase.
• During this phase
unit testing,
integration testing,
system testing,
acceptance testing are done.

Stage 5: Deployment
• After successful testing the product is delivered / deployed to the customer for
their use.
Stage 6 : Maintenance
• Once when the customers starts using the developed system then the actual
problems comes up and needs to be solved from time to time.
• This process where the care is taken for the developed product is known as
maintenance.

SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project
management that defines the stages include in an information system development
project, from an initial feasibility study, to the maintenance of the completed
application.
There are different software development life cycle models specify and design,
which are followed during the software development phase. These models are also
called "Software Development Process Models." Each process model follows a
series of phase unique to its type to ensure success in the step of software
development.

PRESCRIPTIVE AND SPECIALIZED PROCESS
MODELS

PRESCRIPTIVE PROCESS MODELS
• A process model provides a specific roadmap for software engineering work. It
defines the flow of all activities, actions and tasks, the degree of iteration, the
work products, and the organization of the work that must be done.
• The purpose of process models is to try to reduce the chaos present in developing
new software products.
• Prescriptive process model prescribe a set of process elements—framework
activities, software engineering actions, tasks, work products, quality assurance,
and change control mechanisms for each project.
• Each process model also prescribes a process flow (also called a work flow )—
that is, the manner in which the process elements are interrelated to one another.
• Defines a distinct set of activities, actions, tasks, milestones, and work products
that are required to engineer high-quality software
• The activities may be linear, incremental, or evolutionary
• Prescriptive process models define a prescribed set of process elements and a
predictable process work flow.

PRESCRIPTIVE PROCESS MODEL types
1. Waterfall/linear sequential/classic life cycle model
-V-model
2. Incremental model
-RAD model
3. Evolutionary model
-Prototyping model
-Spiral model/Risk driven process model
4. Concurrent Development model

1. Waterfall process model
• Oldest software lifecycle model and best understood by upper management
• Used when requirements are well understood and risk is low
• Work flow is in a linear (i.e., sequential) fashion
• Used often with well-defined adaptations or enhancements to current software
The waterfall model, sometimes called the classic life cycle , suggests a systematic,
sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modeling,
construction, and deployment

Advantage
• Disciplined approach
• Simple and easy to understand and use
• Easy to manage
• Requirements are very well understood
• Clearly defined stages
• Phases are processed and computed one at a time
• Testing in each phase.
• Documentation available at the end of each phase.
• Careful checking by the Software Quality Assurance (SQA) Group at the end of
each phase.

Disadvantage
• The main drawback of the waterfall model is the difficulty of accommodating
change after the process is underway. One phase has to be complete before
moving onto the next phase.
• Each phase terminates only when the documents are complete and approved by
the SQA group.
• Maintenance begins when the client reports an error after having accepted the
product. It could also begin due to a change in requirements after the client has
accepted the product
• Doesn't support iteration, so changes can cause confusion.
• Requires customer patience because a working version of the program doesn't
occur until the final phase
Note: linear nature of the classic life cycle leads to “blocking states” in which some
project team members must wait for other members of the team to complete
dependent tasks. In fact, the time spent waiting can exceed the time spent on
productive work! The blocking state tends to be more prevalent at the beginning and
end of a linear sequential process.

Waterfall model problems:
It is difficult to respond to changing customer requirements.
• This model is only appropriate when the requirements are well understood
and changes will be fairly limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where
a system is developed at several sites.
• The customer must have patience. A working version of the program will not be
available until late in the project time-span
• Feedback from one phase to another might be too late and hence expensive.

V-model
• A variation in the representation of the waterfall model is called the V-model
• V-model describes the relationship of quality assurance actions to the actions
associated with communication, modeling, and early construction activities.
• As a software team moves down the left side of the V, basic problem requirements
are refined into progressively more detailed and technical representations of the
problem and its solution.
• Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that validate
each of the models created as the team moves down the left side.
• In reality, there is no fundamental difference between the classic life cycle and
the V-model.
• The V-model provides a way of visualizing how verification and validation actions
are applied to earlier engineering work.

• Verification: It involves a static analysis method (review) done without executing
code. It is the process of evaluation of the product development process to find
whether specified requirements meet.
• Validation: It involves dynamic analysis method (functional, non-functional),
testing is done by executing code. Validation is the process to classify the software
after the completion of the development process to determine whether the software
meets the customer expectations and requirements.

There are the various phases of Validation Phase of V-model:
• Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors at code level or unit level. A
unit is the smallest entity which can independently exist, e.g., a program module. Unit
testing verifies that the smallest entity can function correctly when isolated from the rest
of the codes/ units.
• Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.
• System Testing: System Tests Plans are developed during System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client?s business
team. System Test ensures that expectations from an application developer are met.
• Acceptance Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal
the compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and
performance defects within the real user atmosphere.

2. Incremental Process Models
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow in a linear (i.e., sequential) and increment fashion
• Iterative in nature and focuses on an operational product with each increment
• It combines linear and parallel process flow
• Each linear sequence produces deliverable increments of the software

• The incremental model combines the linear and parallel process flows
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
advanced page layout capability in the fourth increment
It should be noted that the process flow for any increment can incorporate the
prototyping paradigm

When we use the Incremental Model?
• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.
Advantage of Incremental Model
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
Disadvantage of Incremental Model
• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.

RAD model
• RAPID APPLICATION DEVELOPMENT
• It is the extension of incremental model that emphasizes on extremely short
development cycle (ie., 60 to 90 days)
Phases in RAD model:
Communication
Planning
Modeling
Business modeling
Data modeling
Process modeling
Construction
Deployment

• Any one modelling techniques can be used or all the techniques can be used.
• Uses multiple teams on scalable projects
• It requires heavy resources
• Requires developers and customers who are heavily committed
• Performance can be a problem

Waterfall Model Incremental Model
Need of Detailed Documentation in waterfall model is Necessary.
Need of Detailed Documentation in incremental model is Necessary but
not too much.
In waterfall model early stage planning is necessary. In incremental model early stage planning is also necessary.
There is high amount risk in waterfall model. There is low amount risk in incremental model.
There is long waiting time for running software in waterfall model. There is short waiting time for running software in incremental model.
Waterfall model can’t handle large project. Incremental model also can’t handle large project.
Flexibility to change in waterfall model is Difficult. Flexibility to change in incremental model is Easy.
Cost of Waterfall model is Low. Cost of incremental model is also Low.
Testing is done in waterfall model after completion of all coding
phase.
Testing is done in incremental model after every iteration of phase.
Returning to previous stage/phase in waterfall model is not possible. Returning to previous stage/phase in incremental model is possible.
In waterfall model large team is required. In incremental model large team is not required.
In waterfall model overlapping of phases is not possible. In incremental model overlapping of phases is possible.
There is only one cycle in waterfall model. There is multiple development cycles take place in incremental model.

3. Evolutionary Process Models
• Evolutionary process models produce an increasingly more complete version of
the software with each iteration.
• Evolutionary models are iterative.
• It is used when Business and product requirements often change as development
proceeds.
• To deliver a working system to end users the development starts with those
requirements which are best understood
Types:
1. Prototyping model
2. Spiral model

(i) Prototyping Model
• Multiple iterations are used
• After each iteration the result is evaluated by the customer
• The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built.
• In many instances, the client only has a general view of what is expected from the
software product. In such a scenario where there is an absence of detailed
information regarding the input to the system, the processing needs, and the output
requirement, the prototyping model may be employed.

Steps of Prototype Model
• Requirement Gathering and Analyst
• Quick Decision
• Build a Prototype
• Assessment or User Evaluation
• Prototype Refinement
• Engineer Product

ADVANTAGES:
• Customer can see steady progress
• This is useful when requirements are changing rapidly
• Reduce the risk of incorrect user requirement
• Good where requirement are changing/uncommitted
• Support early product marketing
• Reduce Maintenance cost.
• Errors can be detected much earlier as the system is made side by side.

DISADVANTAGES:
• It is impossible to know how long it will take to produce software (Difficult to
know how long the project will last)
• There is no way to know the number of iterations will be required
• An unstable/badly implemented prototype often becomes the final product.
• Require extensive customer collaboration
• Costs customer money
• Needs committed customer
• Difficult to finish if customer withdraw
• May be too customer specific, no broad market
• Prototyping tools are expensive.(Special tools & techniques are required to build a
prototype)
• It is a time-consuming process.

(II) The Spiral Model
• The spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
• The spiral model can be adapted to apply throughout the entire life cycle of an
application, from concept development to maintenance.
• The spiral development model is also called as risk -driven process model
• Each phase in spiral model begins with design goal and ends with client
reviewing
• Software is developed in a series of incremental releases.
• It has two main distinguishing features.
1. A CYCLIC APPROACH
The software team performs activities that are implied by a circuit/loop/task region
around the spiral in a clockwise direction, beginning at the centre.

2. A SET OF ANCHOR POINT MILESTONES
A combination of work products and conditions that are attained along the path of
the spiral— are noted for each evolutionary pass.
• the first circuit around the spiral might represent a concept of developing
product specification” that starts at the core of the spiral and continues for
multiple iterations until concept development is complete.
• Second circuit around the spiral might represent a product development
• Third circuit around the spiral might represent a product enhancement
• Fourth circuit around the spiral might represent a System maintenance

When to use spiral model?
• When project is large
• When releases are required to be frequent
• When risk and cost estimation is important
• When changes may required at any time
• For medium to high risk projects

Advantages
• The spiral model is a realistic approach to the development of large-scale systems
and software. Because software evolves as the process progresses, the developer
and customer better understand and react to risks at each evolutionary level.
• The spiral model uses prototyping as a risk reduction mechanism
• The spiral model demands a direct consideration of technical risks at all stages of
the project and, if properly applied, should reduce risks before they become
problematic.

Disadvantages
• It may be difficult to convince customers (particularly in contract situations) that
the evolutionary approach is controllable.
• It demands considerable risk assessment expertise and relies on this expertise for
success.
• If a major risk is not uncovered and managed, problems will undoubtedly occur.
• If your management demands fixed-budget development (generally a bad idea),
the spiral can be a problem. As each circuit is completed, project cost is revisited
and revised.

4. CONCURRENT MODELS
• It allows a software team to represent iterative and concurrent elements of any of
the process models
• For example,
the modeling activity defined for the spiral model is accomplished by invoking one
or more of the following software engineering actions: prototyping, analysis, and
design.
• Concurrent modeling defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks.

SPECIALIZED PROCESS MODEL
• Take on many of the characteristics of one or more of the conventional models
• Tend to be applied when a narrowly defined software engineering approach is
chosen
SPECIALIZED PROCESS MODEL TYPES:
1. Components based development(Promotes reusable components)
2. The Formal Methods Model(Mathematical formal methods are backbone here)
3. Aspect oriented software development(AOSD) (Uses crosscutting technology)

1. Component based development
• The component based development model incorporates many of the characteristics
of the spiral model.
• It is evolutionary in nature, demanding an iterative approach to the creation of
software.
• The process to apply when reuse is a development object.
• The model focuses on pre-packaged software components.
• It promotes software reusability.

• Modeling and construction activities begin with the identification of candidate
components. Candidate components can be designed as either conventional
software modules or object oriented packages.
• Component based development has the following steps:
1. Available component based products are researched and evaluated for the
application domain.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.

ADVANTAGES:
- Leads to software reuse
-70% reduction in development cycle
DISADVANTAGES:
-Components library must be robust
-performance may be degrade

Problems in Component based development
• Component trustworthiness - how can a component with no available source code
be trusted?
• Component certification - who will certify the quality of components?
• Requirements trade-offs - how do we do trade-off analysis between the features of
one component and another?

2. The formal methods model
• Formal methods provide a basis for software verification and therefore enable software
engineer to discover and correct errors that might otherwise go undetected.
• Encompasses a set of activities that leads to formal mathematical specification of
computer software
• Enables a software engineer to specify, develop, and verify a computer-based system by
applying a rigorous mathematical notation
ADVANTAGES:
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily through mathematical analysis
• When mathematical methods are used during software development, they provide a
mechanism for eliminating many of the problems that are difficult to overcome using
other software engineering paradigms.
• Offers the promise of defect-free software
• Used often when building safety-critical systems

Problems/Challenges/Disadvantages:
• The development of formal models is currently time-consuming and expensive.
• Because few developers have the necessary background knowledge to apply
formal methods, extensive training is required to others.
• It is difficult to use this model as a communication mechanism for technically
unsophisticated people.

3. Aspect oriented Software Development
• Aspect Oriented Software Development (AOSD) often referred to as aspect
oriented programming (AOP), a relatively new paradigm that provides process
and methodology for defining, specifying designing and constructing aspects.
• It addresses limitations inherent in other approaches, including object-oriented
programming. AOSD aims to address crosscutting concerns by providing means
for systematic identification, separation, representation and composition.
• This results in better support for modularization hence reducing development,
maintenance and evolution costs.
• Example “concerns”: Security, Fault Tolerance, Task synchronization, Memory
Management.
• When concerns cut across multiple system functions, features, and information,
they are often referred to as crosscutting concerns

Advantages
-increases modularity and reusability
-increases maintainability
Disadvantage
-reduce efficiency due to increase overhead aspects
-security risks involving aspects

The Unified Process
• The Unified Process (UP) is an attempt to draw on the best features and
characteristics of conventional software process models, but characterize them in a
way that implements many of the best principles of agile software development.
• The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system.
• It helps the architect to focus on the right goals, such as understand ability,
reliance to future changes, and reuse.
• It is completely a diagrammatic representation . Some UML ( unified modelling
language) modelling approaches are used.

Phases of the Unified Process
Consists of five phases: inception, elaboration, construction, transition, and
production
1. Inception phase: encompasses both customer communication and planning
activities.
2. Elaboration phase: encompasses planning and modeling activities.
3. Construction phase: is identical to the construction activity.
4. Transition phase: encompasses latter stages of construction activity and first
part of the generic deployment activity.
5. Production phase: coincides with the deployment activity of the generic
process.

1. Inception Phase
• Encompasses both customer communication and planning activities of the generic process
• Business requirements for the software are identified
Fundamental business requirements are described through preliminary use cases
– A use case describes a sequence of actions that are performed by a user
• A rough architecture for the system is proposed
• A plan is created for an incremental, iterative development
• 2. Elaboration Phase
• Encompasses both customer planning and modelling activities of the generic process
• Here the UML diagram will be generated
• Elaboration for the usecase to analyse, design, implement, development in UML
• Architectural model is created in this phase

3. Construction Phase
• Encompasses the construction activity of the generic process
• Uses the architectural model from the elaboration phase as input
• Develops or acquires the software components that make each use-case operational
• Analysis and design models from the previous phase are completed to reflect the
final version of the increment
• Use cases are used to derive a set of acceptance tests that are executed prior to the
next phase

4. Transition Phase
• Encompasses the last part of the construction activity and the first part of the deployment
activity of the generic process
• Software is given to end users for beta testing and user feedback reports on defects and
necessary changes
• The software teams create necessary support documentation (user manuals,
troubleshooting guides, installation procedures)
• At the conclusion of this phase, the software increment becomes a usable software release
5. Production Phase
• Encompasses the last part of the deployment activity of the generic process
• On-going use of the software is monitored
• Support for the operating environment (infrastructure) is provided
• Defect reports and requests for changes are submitted and evaluated

Major Workflow Produced for Unified Process

Advantages:
-It covers the complete s/w development life cycle
-The best practise foe s/w development are supported by UP model
-It encourages designing in UML
Disadvantages:
-Could be complex to implement
-Experts are need for it

PERSONAL PROCESS MODELS (PPM)
AND
TEAM PROCESS MODELS (TPM)

PERSONAL PROCESS MODELS (PPM)
What Is Personal Software Process (PSP)?
The Personal Software Process (PSP) is a structured software
development process that is intended to help software engineers understand and
improve their performance, by using a "disciplined, data-driven procedure“
The PSP was created by Watts Humphrey to apply the underlying principles of
the Software Engineering Institute’s (SEI) ,Capability Maturity Model (CMM) to
the software development practices of a single developer.
It claims to give software engineers the process skills necessary to work on a Team
Software Process (TSP) team.
• The Personal Software Process (PSP) shows engineers how to
- manage the quality of their projects
- make commitments they can meet
- improve estimating and planning
- reduce defects in their products

• PSP emphasizes the need to record and analyse the types of errors you make,
so you can develop strategies to eliminate them.
• Because personnel costs constitute 70 percent of the cost of software development,
the skills and work habits of engineers largely determine the results of the
software development process.
• Based on practices found in the CMMI, the PSP can be used by engineers as a
guide to a disciplined and structured approach to developing software. The PSP is a
prerequisite for an organization planning to introduce the TSP.
What is the need/use for PSP?
• Improve their estimating and planning skills.
• Make commitments they can keep.
• Manage the quality of their projects.
• Reduce the number of defects in their work.

PSP Framework Activities
1. Planning
2. High level Design
3. High level Design Review
4. Development
5. Postmortem

PSP strucure
• PSP training follows an evolutionary improvement approach: an engineer learning
to integrate the PSP into his or her process begins at the first level - PSP0 - and
progresses in process maturity to the final level - PSP2.1.
• Each Level has detailed
o scripts,
o Checklists
o Templates
to guide the engineer through required steps and helps the engineer improve his own
personal software process.
• Humphrey encourages proficient engineers to customize these scripts and
templates as they gain an understanding of their own strengths and weaknesses.

PSP0,PSP 0.1
-Introduces process discipline and measurement
PSP 1,PSP 1.1
-Introduces process estimation and planning
PSP 2,PSP 2.1
-Introduces process quality management and design

TEAM PROCESS MODELS (TPM)
What Is Team Software Process (TSP)?
• In combination with the Personal Software Process (PSP), the Team Software
Process (TSP) provides a defined operational process framework that is designed
to help teams of managers and engineers organize projects and produce
software products that range in size from small projects of several thousand lines
of code (KLOC) to very large projects greater than half a million lines of code.
• The TSP is intended to improve the levels of quality and productivity of a team's
software development project
• The Team Software Process (TSP), along with the Personal Software Process,
helps the high performance engineer to
- ensure quality software products
- create secure software products
- improve process management in an organization

How TSP Works
• Before engineers can participate in the TSP, it is required that they have already learned
about the PSP, so that the TSP can work effectively.
• Training is also required for other team members, the team lead, and management.
• The coach role focuses on supporting the team and the individuals on the team
• The team leader role is different from the coach role in that,
-team leader are responsible to management for products and project outcomes
-coach is responsible for developing individual and team performance
TSP Framework Activities
• Launch high level design
• Implementation
• Integration
• Test
• Postmortem

PSP Framework Activities TSP Framework Activities
Planning Launch high level design
High level Design Implementation
High level Design Review Integration
Development Test
Postmortem Postmortem

Agile Software Development
• "Agile process model" refers to a software development approach based on iterative
development. Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning. The project scope and requirements are laid down
at the beginning of the development process. Plans regarding the number of iterations, the
duration and the scope of each iteration are clearly defined in advance.
• Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller
parts helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis, design, coding, and
testing before a working product is demonstrated to the client.
AGILE methodology is a practice that promotes continuous iteration of development and
testing throughout the software development lifecycle of the project. In the Agile model,
both development and testing activities are concurrent, unlike the Waterfall model.

Phases of Agile Model:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build
the project. Based on this information, you can evaluate technical and economic
feasibility.
2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the
high-level UML diagram to show the work of new features and show how it will
apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product. The product will undergo various stages of improvement,
so it includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work
environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

Agile Testing Methods:
1. Scrum
2. Crystal Methodologies
3. Dynamic Software Development Method(DSDM)
4. Feature Driven Development(FDD)
5. Lean Software Development
6. eXtreme Programming(XP)
• XP process

1. SCRUM
SCRUM is an agile development process focused primarily on ways to manage
tasks in team-based development conditions.
There are three roles in it, and their responsibilities are:
Scrum Master: The scrum can set up the master team, arrange the meeting and
remove obstacles for the process
Product owner: The product owner makes the product backlog, prioritizes the
delay and is responsible for the distribution of functionality on each repetition.
Scrum Team: The team manages its work and organizes the work to complete the
sprint or cycle.

Product Backlog
• This is a repository where requirements are tracked with details on the number of
requirements(user stories) to be completed for each release.
• It should be maintained and prioritized by Product Owner, and it should be
distributed to the scrum team.
• Team can also request for a new requirement addition or modification or deletion

Process flow of Scrum Methodologies:
Process flow of scrum testing is as follows:
• Each iteration of a scrum is known as Sprint
• Product backlog is a list where all details are entered to get the end-product
• During each Sprint, top user stories of Product backlog are selected and turned
into Sprint backlog
• Team works on the defined sprint backlog
• Team checks for the daily work
• At the end of the sprint, team delivers product functionality

2. eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing demands
or requirements, or when they are not sure about the system's performance.
The XP develops software keeping customer in the target.

• Business requirements are gathered in terms of stories. All those stories are stored
in a place called the parking lot.
• In this type of methodology, releases are based on the shorter cycles called
Iterations with span of 14 days time period. Each iteration includes phases like
coding, unit testing and system testing where at each phase some minor or major
functionality will be built in the application.

Phases of eXtreme programming:
There are 6 phases available in Agile XP method, and those are explained as follows:
1.Planning
Identification of stakeholders and sponsors
Infrastructure Requirements
Security related information and gathering
Service Level Agreements and its conditions
2.Analysis
Capturing of Stories in Parking lot
Prioritize stories in Parking lot
Scrubbing of stories for estimation
Define Iteration SPAN(Time)
Resource planning for both Development and QA teams

3.Design
Break down of tasks
Test Scenario preparation for each task
Regression Automation Framework
4.Execution
Coding
Unit Testing
Execution of Manual test scenarios
Defect Report generation
Conversion of Manual to Automation regression test cases
Mid Iteration review
End of Iteration review

5.Wrapping
• Small Releases
• Regression Testing
• Demos and reviews
• Develop new stories based on the need
• Process Improvements based on end of iteration review comments
6.Closure
• Pilot Launch
• Training
• Production Launch
• SLA Guarantee assurance
• Review SOA strategy
• Production Support

There are two storyboards available to track the work on a daily basis, and those are
listed below for reference.
• Story Cardboard
• This is a traditional way of collecting all the stories in a board in the form of
stick notes to track daily XP activities. As this manual activity involves more
effort and time, it is better to switch to an online form.
• Online Storyboard
• Online tool Storyboard can be used to store the stories. Several teams can use
it for different purposes.

3. Crystal Methodologies:
There are three concepts of this method-
a. Chartering: Multi activities are involved in this phase such as making a
development team, performing feasibility analysis, developing plans, etc.
b. Cyclic delivery: under this, two more cycles consist, these are:
-Team updates the release plan.
-Integrated product delivers to the users.
c. Wrap up: According to the user environment, this phase performs deployment,
post-deployment.

4. Dynamic Software Development Method(DSDM):
DSDM is a rapid application development strategy for software development and gives an agile
project distribution structure. The essential features of DSDM are that users must be actively
connected, and teams have been given the right to make decisions.
The techniques used in DSDM are:
1.Time Boxing
2.MoSCoW Rules
3.Prototyping
The DSDM project contains seven stages:
1.Pre-project
2.Feasibility Study
3.Business Study
4.Functional Model Iteration
5.Design and build Iteration
6.Implementation
7.Post-project

5. Feature Driven Development(FDD)
• This method focuses on "Designing and Building" features.
• In contrast to other smart methods, FDD describes the small steps of the work that should
be obtained separately per function.
• It includes domain walkthrough, design inspection, promote to build, code inspection and
design. FDD develops product keeping following things in the target
1. Domain object Modeling
2. Development by feature
3. Component/ Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
7. Regular Builds
8. Visibility of progress and results

6. Lean Software Development:
• Lean software development methodology follows the principle "just in time
production.“
• The lean method indicates the increasing speed of software development and
reducing costs.
Lean development can be summarized in seven phases
1.Eliminating Waste
2.Amplifying learning
3.Defer commitment (deciding as late as possible)
4.Early delivery
5.Empowering the team
6.Building Integrity
7.Optimize the whole

When to use the Agile Model?
• When frequent changes are required.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with a software team all the time.
• When project size is small.

Agile Model Waterfall Model
•Agile method proposes incremental and iterative approach to software design •Development of the software flows sequentially from start point to end point.
•The agile process is broken into individual models that designers work on •The design process is not broken into an individual models
•The customer has early and frequent opportunities to look at the product and make decision and changes to the project •The customer can only see the product at the end of the project
•Agile model is considered unstructured compared to the waterfall model •Waterfall model are more secure because they are so plan oriented
•Small projects can be implemented very quickly. For large projects, it is difficult to estimate the development time. •All sorts of project can be estimated and completed.
•Error can be fixed in the middle of the project. •Only at the end, the whole product is tested. If the requirement error is found or any changes have to be made, the project has to start from the beginning
•Development process is iterative, and the project is executed in short (2-4) weeks iterations. Planning is very less. •The development process is phased, and the phase is much bigger than iteration. Every phase ends with the detailed description of the next phase.
•Documentation attends less priority than software development •Documentation is a top priority and can even use for training staff and upgrade the software with another team
•Every iteration has its own testing phase. It allows implementing regression testing every time new functions or logic are released. •Only after the development phase, the testing phase is executed because separate parts are not fully functional.
•In agile testing when an iteration end, shippable features of the product is delivered to the customer. New features are usable right after shipment. It is
useful when you have good contact with customers.
•All features developed are delivered at once after the long implementation phase.
•Testers and developers work together •Testers work separately from developers
•At the end of every sprint, user acceptance is performed •User acceptance is performed at the end of the project.
•It requires close communication with developers and together analyze requirements and planning •Developer does not involve in requirement and planning process. Usually, time delays between tests and coding

Advantage(Pros) of Agile Method:
• Frequent Delivery
• Face-to-Face Communication with clients.
• Efficient design and fulfils the business requirement.
• Anytime changes are acceptable.
• It reduces total development time.

Disadvantages(Cons) of Agile Model:
• Due to the shortage of formal documents, it creates confusion and crucial
decisions taken throughout various phases can be misinterpreted at any time by
different team members.
• Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can
become a difficulty.

Software Cost Estimation
For any new software project, it is necessary to know how much it will cost to
develop and how much development time will it take. These estimates are needed
before development is initiated, but how is this done? Several estimation procedures
have been developed and are having the following attributes in common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small pieces which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Acquire one or more automated estimation tools.

Uses of Cost Estimation
• During the planning stage, one needs to choose how many engineers are required
for the project and to develop a schedule.
• In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.

Cost Estimation Models
A model may be static or dynamic.
• In a static model, a single variable is taken as a key element for calculating cost
and time.
• In a dynamic model, all variable are interdependent, and there is no basic
variable.

• Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model. The
most common equation is:
C=aLb
Where C = Costs
L= size
a and b are constants
The Software Engineering Laboratory established a model called SEL model, for estimating
its software production. This model is an example of the static, single variable model.
E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26
Where E= Efforts (Person Per Month)
DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code

Static, Multivariable Models: These models are based on method (1), they depend
on several variables describing various aspects of the software development
environment. In some model, several variables are needed to describe the software
development process, and selected equation combined these variables to give the
estimate of time & cost. These models are called multivariable models.
WALSTON and FELIX develop the models at IBM provide the following equation
gives a relationship between lines of source code and effort:
E=5.2L0.91
In the same manner duration of development is given by
D=4.1L0.36

The productivity index uses 29 variables which are found to be highly correlated
productivity as follows
Where,
Wi is the weight factor for the ithvariable and
Xi={-1,0,+1} the estimator gives Xione of the values -1, 0 or +1 depending on the
variable decreases, has no effect or increases the productivity.

Example: Compare the Walston-Felix Model with the SEL model on a software
development expected to involve 8 person-years of effort.
• Calculate the number of lines of source code that can be produced.
• Calculate the duration of the development.
• Calculate the productivity in LOC/PY
• Calculate the average manning

Solution:
The amount of manpower involved = 8PY=96persons-months
(a)Number of lines of source code can be obtained by reversing equation to give:
Then
L (SEL) = (96/1.4)1⁄0.93=94264 LOC
L (SEL) = (96/5.2)1⁄0.91=24632 LOC
(b)Duration in months can be calculated by means of equation
D (SEL) = 4.6 (L) 0.26
= 4.6 (94.264)0.26 = 15 months
D (W-F) = 4.1 L0.36
= 4.1 (24.632)0.36 = 13 months

(c) Productivity is the lines of code produced per persons/month (year)
(d)Average manning is the average number of persons required per month in the
project

Currently three metrics are popularly being used widely to estimate size:
1. LINES OF CODE (LOC)
2. FUNCTION POINT (FP)
3. CONSTRUCTIVE COST ESTIMATION MODEL (COCOMO 1 AND 2)
The usage of each of these metrics in project size estimation has its own advantages
and disadvantages.

1. Lines of Code (LOC)
• LOC is the simplest among all metrics available to estimate project size.
• This metric is very popular because it is simplest to use.
• Using this metric, the project size is estimated by counting the number of source
instructions in the developed program.
• Obviously, while counting the number of source instructions, lines used for commenting
the code and the header lines should be ignored.
• Determining the LOC count at the end of a project is a very simple job.
• However, accurate estimation of the LOC count at the beginning of a project is very
difficult.
• In order to estimate the LOC count at the beginning of a project, project managers
usually divide the problem into modules, and each module into submodules and so on,
until the sizes of the different leaf-level modules can be approximately predicted.
• To be able to do this, past experience in developing similar products is helpful. By using
the estimation of the lowest level modules, project managers arrive at the total size
estimation.

Program to Add Two Integers
1. #include <stdio.h>
2. int main()
3. {
4. int number1, number2, sum;
5. printf("Enter two integers: ");
6. scanf("%d %d", &number1, &number2);
7. // calculating sum
8. sum = number1 + number2;
9. printf("%d + %d = %d", number1, number2, sum);
10. return 0;
11. }
Total 11 lines 11-2=9 loc

2. Functional Point (FP) Analysis
Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it
has been further modified by the International Function Point Users Group
(IFPUG).
FPA is used to make estimate of the software project, including its testing in terms
of functionality or function size of the software product.
However, functional point analysis may be used for the test estimation of the
product.
The functional size of the product is measured in terms of the function point, which
is a standard of measurement to measure the software application.

Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and
provide the software application functional size to the client, customer, and the
stakeholder on their request.
Further, it is used to measure the software project development along with its
maintenance, consistently throughout the project irrespective of the tools and the
technologies.
One of the important advantages of using the function point metric is that it can be
used to easily estimate the size of a software product directly from the problem
specification. This is in contrast to the LOC metric, where the size can be accurately
determined only after the product has fully been developed.

Various functions used in an application can be put under five types, as shown in
Table:
Types of FPAttribute
Measurements Parameters Examples
1.Number of External Inputs(EI) Input screen and tables
2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries
(EQ)
Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces
(EIF)
Shared databases and shared
routines.

The FPA functional units are shown in Fig:

Following are the points regarding FPs
1. FPs of an application is found out by counting the number and types of functions
used in the applications
2. FP characterizes the complexity of the software system and hence can be used to
depict the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information
systems.
6. The five parameters mentioned above are also known as information domain
characteristics.
7. All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table

Weights of 5-FPAttributes
Measurement Parameter Low Average High
1. Number of
external inputs (EI)
7 10 15
2. Number of
external outputs (EO)
5 7 10
3. Number of
external inquiries
(EQ)
3 4 6
4. Number of internal
files (ILF)
4 5 7
5. Number of
external interfaces
(EIF)
3 4 6

• The functional complexities are multiplied with the corresponding weights against
each function, and the values are added up to determine the UFP (Unadjusted
Function Point) of the subsystem.

The Function Point (FP) is thus calculated with the following formula.
FP = Count-total * [0.65 + 0.01 * ∑(fi)]
w.k.t CAF = [0.65 + 0.01 *∑(fi)]
FP = Count-total * CAF
where Count-total is obtained from the above Table.

9. FP metrics is used mostly for measuring the size of Management Information
System (MIS) software.
10. But the function points obtained above are unadjusted function points (UFPs).
These (UFPs) of a subsystem are further adjusted by considering some more
General System Characteristics (GSCs). It is a set of 14 GSCs that need to be
considered. The procedure for adjusting UFPs is as follows:
(a)Degree of Influence(DI)for each of these 14 GSCs is assessed on a scale of 0 to 5.
(b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a
strong influence then its weight is 5.
(b)The score of all 14 GSCs is totalled to determine Total Degree of Influence
(TDI).
(c)Then Value Adjustment Factor (VAF) is computed from TDI by using the
formula: VAF = (TDI * 0.01) + 0.65

Differentiate between FP and LOC
FP LOC
1. FP is specification based. 1. LOC is an analogy based.
2. FP is language independent. 2. LOC is language dependent.
3. FP is user-oriented. 3. LOC is design-oriented.
4. It is extendible to LOC. 4. It is convertible to FP
(backfiring)

3. COCOMO MODEL
Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is
one of the most generally used software estimation models in the world. COCOMO predicts
the efforts and schedule of a software product based on the size of the software.
The necessary steps in this model are:
1. Get an initial estimate of the development effort from evaluation of thousands of
delivered lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the
multiplying factors i.e., multiply the values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form
used in the static single variable models, using KDLOC as the measure of the size.
To determine the initial effort Ei in person-months the equation used is of the type is shown
below
Ei=a*(KDLOC)b
The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:
1. Organic
2. Semidetached
3. Embedded
1.Organic: A development project can be treated of the organic type, if the project deals
with developing a well-understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar methods of
projects. Examples of this type of projects are simple business systems, simple
inventory management systems, and data processing systems.
2. Semidetached: A development project can be treated with semidetached type if the
development consists of a mixture of experienced and inexperienced staff. Team members
may have finite experience in related systems but may be unfamiliar with some aspects of
the order being developed. Example of Semidetached system includes developing a new
operating system (OS), a Database Management System (DBMS), and complex
inventory management system.
3. Embedded: A development project is treated to be of an embedded type, if the software
being developed is strongly coupled to complex hardware, or if the stringent regulations on
the operational method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict
effort (in a unit of person month)and development time from the size of estimation
in KLOC(Kilo Line of code) efforts estimation takes into account the productivity
loss due to holidays, weekly off, coffee breaks, etc.
According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project
parameters. The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months
(PMs).
Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on the code
size are shown below:
Organic: Effort = 2.4(KLOC) 1.05 PM
Semi-detached: Effort = 3.0(KLOC) 1.12 PM
Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time
For the three classes of software products, the formulas for estimating the
development time based on the effort are given below:
Organic: Tdev = 2.5(Effort) 0.38 Months
Semi-detached: Tdev = 2.5(Effort) 0.35 Months
Embedded: Tdev = 2.5(Effort) 0.32 Months
Some insight into the basic COCOMO model can be obtained by plotting the
estimated characteristics for different software sizes. Fig shows a plot of estimated
effort versus product size. From fig, we can observe that the effort is somewhat
superliner in the size of the software product. Thus, the effort required to develop
a product increases very rapidly with project size.

The development time versus the product size in KLOC is plotted in fig. From fig it
can be observed that the development time is a sub linear function of the size of
the product, i.e. when the size of the product increases by two times, the time to
develop the product does not double but rises moderately. This can be explained
by the fact that for larger products, a larger number of activities which can be
carried out concurrently can be identified. The parallel activities can be carried out
simultaneously by the engineers. This reduces the time to complete the project.
Further, from fig, it can be observed that the development time is roughly the same
for all three categories of products. For example, a 60 KLOC program can be
developed in approximately 18 months, regardless of whether it is of organic,
semidetached, or embedded type.
•

From the effort estimation, the project cost can be obtained by multiplying the
required effort by the manpower cost per month. But, implicit in this project cost
computation is the assumption that the entire project cost is incurred on account of
the manpower cost alone. In addition to manpower cost, a project would incur costs
due to hardware and software required for the project and the company overheads
for administration, office space, etc.
It is important to note that the effort and the duration estimations obtained using the
COCOMO model are called a nominal effort estimate and nominal duration
estimate. The term nominal implies that if anyone tries to complete the project in a
time shorter than the estimated duration, then the cost will increase drastically. But,
if anyone completes the project over a longer period of time than the estimated, then
there is almost no decrease in the estimated cost value.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & embedded.
Solution: The basic COCOMO equation takes the form:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM

2. Intermediate Model:
The basic Cocomo model considers that the effort is only a function of the number
of lines of code and some constants calculated according to the various software
systems.
The intermediate COCOMO model recognizes these facts and refines the initial
estimates obtained through the basic COCOMO model by using a set of 15 cost
drivers based on various attributes of software engineering.
- It is an extension of basic cocomo
- It contains a set of 15 cost drivers/predictors/multipliers
- Boehm requires the project manager to rate these 15 different parameters for a
particular project on a scale of one to three.
- Then, depending on these ratings, he suggests appropriate cost driver values which
should be multiplied with the initial estimate obtained using the basic COCOMO.

Classification of Cost Drivers and their attributes:
In general, the cost drivers can be classified as being attributes of the following items:
(i) Product attributes –
The characteristics of the product that are considered include the inherent complexity of the
product, reliability requirements of the product, etc.
• Required software reliability extent (RELY)
• Size of the application database
• The complexity of the product (CPLX)
(ii) Hardware/computer attributes –
Characteristics of the computer that are considered include the execution speed required,
storage space required etc.
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turn around time (TURN)

(iii)Personnel attributes –
The attributes of development personnel that are considered include the experience level of
personnel, programming capability, analysis capability, etc.
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
(iv)Project/development environment attributes –
Development environment attributes capture the development facilities available to the
developers. An important parameter that is considered is the sophistication of the
automation (CASE) tools used for software development.
• Use of software tools
• Application of software engineering methods
• Required development schedule

The cost drivers are divided into four categories:

Intermediate COCOMO equation:
E=ai (KLOC) bi*EAF
D=ci (E)di
Coefficients for intermediate COCOMO
Project ai bi ci di
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model:
• In detailed cocomo, the whole software is differentiated into multiple
modules, and then we apply COCOMO in various modules to estimate effort
and then sum the effort.
• The complete COCOMO model considers differences in characteristics of the
subsystems and estimates the effort and development time as the sum of the
estimates for the individual subsystems.
• The cost of each subsystem is estimated separately.
• This approach reduces the margin of error in the final estimate.

EXAMPLE
The following development project can be considered as an example application of
the complete COCOMO model. A distributed Management Information System
(MIS) product for an organization having offices at several places across the
country can have the following sub-components:
• Database part
• Graphical User Interface (GUI) part
• Communication part
Of these,
the communication part can be considered as embedded software.
The database part could be semi-detached software, and
the GUI part organic software.
The costs for these three components can be estimated separately, and summed up to
give the overall cost of the system.

The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model
The effort is determined as a function of program estimate, and a set of cost drivers
are given according to every phase of the software lifecycle.

COCOMO-II
• It is the revised version of the original Cocomo (Constructive Cost Model) and is
developed at University of Southern California.
• It is the model that allows one to estimate the cost, effort and schedule when
planning a new software development activity.
It consists of three sub-models:

1. End User Programming:
Application generators are used in this sub-model. End user write the code by
using these application generators.
Example – Spreadsheets, report generator, etc.
2. Intermediate Sector:

(a). Application Generators and Composition Aids –
This category will create largely pre packaged capabilities for user programming.
Their product will have many reusable components. Typical firms operating in
this sector are Microsoft, Lotus,Oracle, IBM, Borland, Novell.
(b). Application Composition Sector –
This category is too diversified and to be handled by pre packaged solutions. It
includes GUI, Databases, domain specific components such as financial, medical
or industrial process control packages.
(c). System Integration –
This category deals with large scale and highly embedded systems.

3. Infrastructure Sector:
This category provides infrastructure for the software development like Operating
System, Database Management System, User Interface Management System,
Networking System, etc.
Stages of COCOMO II:

Stage-I:
It supports estimation of prototyping. For this it uses Application Composition
Estimation Model. This model is used for the prototyping stage of application
generator and system integration.
Stage-II:
It supports estimation in the early design stage of the project, when we less
know about it. For this it uses Early Design Estimation Model. This model is used
in early design stage of application generators, infrastructure, system integration.
Stage-III:
It supports estimation in the post architecture stage of a project. For this it
uses Post Architecture Estimation Model. This model is used after the completion of
the detailed architecture of application generator, infrastructure, system integration.

Difference between COCOMO 1 and COCOMO 2
COCOMO 1 Model:
• The Constructive Cost Model was first developed by Barry W. Boehm. The model
is for estimating effort, cost, and schedule for software projects. It is also called as
Basic COCOMO. This model is used to give an approximate estimate of the
various parameters of the project. Example of projects based on this model is
business system, payroll management system and inventory management systems.
COCOMO 2 Model:
• The COCOMO-II is the revised version of the original Cocomo (Constructive
Cost Model) and is developed at the University of Southern California. This model
calculates the development time and effort taken as the total of the estimates of all
the individual subsystems. In this model, whole software is divided into different
modules. Example of projects based on this model is Spreadsheets and report
generator.

COCOMO I COCOMO II
COCOMO I is useful in the waterfall models of the software
development cycle.
COCOMO II is useful in non-sequential, rapid development and reuse
models of software.
It provides estimates pf effort and schedule.
It provides estimates that represent one standard deviation around the
most likely estimate.
This model is based upon the linear reuse formula. This model is based upon the non linear reuse formula
This model is also based upon the assumption of reasonably stable
requirements.
This model is also based upon reuse model which looks at effort
needed to understand and estimate.
Effort equation’s exponent is determined by 3 development modes. Effort equation’s exponent is determined by 5 scale factors.
Development begins with the requirements assigned to the software. It follows a spiral type of development.
Number of submodels in COCOMO I is 3 and 15 cost drivers are
assigned
In COCOMO II, Number of submodel are 4 and 17 cost drivers are
assigned
Size of software stated in terms of Lines of code
Size of software stated in terms of Object points, function points and
lines of code

What is Risk?
• Risk Management is the system of identifying addressing and eliminating
problems before they can damage the project.
• We need to differentiate risks, as potential issues, from the current problems of the
project.

Risk Management
A software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is essential to
classify risks into different classes. The project manager can then check which risks from each class
are relevant to the project.
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource,
and customer-related problems. A vital project risk is schedule slippage. Since the software is
intangible, it is very tough to monitor and control a software project. It is very tough to control
something which cannot be identified.
2. Technical risks: Technical risks concern potential method, implementation, interfacing,
testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks appear due to the development team's insufficient knowledge about the project.
3. Business risks: This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.

Other risk categories
1. Known risks: Those risks that can be uncovered after careful assessment of the
project program, the business and technical environment in which the plan is being
developed, and more reliable data sources (e.g., unrealistic delivery date)
2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. Unpredictable risks: Those risks that can and do occur, but are extremely tough
to identify in advance.

Principle of Risk Management
1. Global Perspective: In this, we review the bigger system description, design,
and implementation. We look at the chance and the impact the risk is going to
have.
2. Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
3. Open Communication: This is to allow the free flow of communications
between the client and the team members so that they have certainty about the
risks.
4. Integrated management: In this method risk management is made an integral
part of project management.
5. Continuous process: In this phase, the risks are tracked continuously
throughout the risk management paradigm.

Risk Assessment
• The objective of risk assessment is to division the risks in the condition of their
loss, causing potential. For risk assessment, first, every risk should be rated in two
methods:
The possibility of a risk coming true (denoted as r).
The consequence of the issues relates to that risk (denoted as s).
• Based on these two methods, the priority of each risk can be estimated:
p = r * s
Where p is the priority with which the risk must be controlled, r is the probability of
the risk becoming true, and s is the severity of loss caused due to the risk becoming
true. If all identified risks are set up, then the most likely and damaging risks can be
controlled first, and more comprehensive risk abatement methods can be designed
for these risks.

1. Risk Identification:
The project organizer needs to anticipate the risk in the project as early as possible so that
the impact of risk can be reduced by making effective risk management planning.
A project can be of use by a large variety of risk. To identify the significant risk, this might
affect a project. It is necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:
1. Technology risks: Risks that assume from the software or hardware technologies that
are used to develop the system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment where
the software is being developed.
4. Tools risks: Risks that assume from the software tools and other support software used
to create the system.
5. Requirement risks: Risks that assume from the changes to the customer requirement
and the process of managing the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the resources
required to build the system

2. Risk Analysis:
During the risk analysis process, you have to consider every identified risk and
make a perception of the probability and seriousness of that risk.
There is no simple way to do this. You have to rely on your perception and
experience of previous projects and the problems that arise in them.
It is not possible to make an exact, the numerical estimate of the probability and
seriousness of each risk. Instead, you should authorize the risk to one of several
bands:
1. The probability of the risk might be determined as very low (0-10%), low (10-
25%), moderate (25-50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival
of the plan), serious (would cause significant delays), tolerable (delays are
within allowed contingency), or insignificant.

Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the
identified risks of a plan are determined; the project must be made to include the
most harmful and the most likely risks. Different risks need different containment
methods. In fact, most risks need ingenuity on the part of the project manager in
tackling the risk.
There are three main methods to plan for risk management:
1. Avoid the risk: This may take several ways such as discussing with the client to
change the requirements to decrease the scope of the work, giving incentives to
the engineers to avoid the risk of human resources turnover, etc.
2. Transfer the risk: This method involves getting the risky element developed by
a third party, buying insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For
instance, if there is a risk that some key personnel might leave, new recruitment
can be planned.

Risk Leverage:
To choose between the various methods of handling risk, the project plan must
consider the amount of controlling the risk and the corresponding reduction of risk.
For this, the risk leverage of the various risks can be estimated.
Risk leverage is the variation in risk exposure divided by the amount of reducing the
risk.
Risk leverage = (risk exposure before reduction - risk exposure after reduction)
/ (cost of reduction)

1. Risk planning:
The risk planning method considers each of the key risks that have been identified
and develop ways to maintain these risks.
For each of the risks, you have to think of the behavior that you may take to
minimize the disruption to the plan if the issue identified in the risk occurs.
You also should think about data that you might need to collect while monitoring the
plan so that issues can be anticipated.
Again, there is no easy process that can be followed for contingency planning. It
rely on the judgment and experience of the project manager.
2. Risk Monitoring: Risk monitoring is the method king that your assumption
about the product, process, and business risks has not changed.

Project Scheduling
Project-task scheduling is a significant project planning activity. It comprises
deciding which functions would be taken up when. To schedule the project plan, a
software project manager wants to do the following:
1. Identify all the functions required to complete the project.
2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the
activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide
the duration of the project.

• The work breakdown structure formalism helps the manager to breakdown the tasks
systematically after the project manager has broken down the tasks
• The dependency among the activities is represented in the form of an activity network.
• Resource allocation is typically done using a Gantt chart.
• The PERT chart representation is suitable for program monitoring and control.
• The end of each activity is called milestone
The scheduling can be represented using
1. Work Breakdown Structure (WBS)
2. Activity networks
3. critical path method ( CPM)
4. Gantt chart
5. PERT chart

1. Work Breakdown Structure
• Work Breakdown Structure (WBS) is used to decompose a given task set
recursively into small activities.
• The root of the tree is labelled by the problem name.
• Each node of the tree is broken down into smaller activities that are made the
children of the node.
• Each activity is recursively decomposed into smaller sub-activities until at the leaf
level, the activities requires approximately two weeks to develop.

Activity networks
• Each activity is represented by a rectangular node
• Managers can estimate the time durations for the different tasks in several ways.
One possibility is that they can empirically assign durations to different tasks. This
however is not a good idea, because software engineers often resent such
unilateral decisions.
• A possible alternative is to let engineer himself estimate the time for an activity he
can assigned to. However, some managers prefer to estimate the time for various
activities themselves.
• A good way to achieve accurately in estimation of the task durations without
creating undue schedule pressures is to have people set their own schedules.

Critical Path Method (CPM)
• From the activity network representation following analysis can be made.
• This tools is useful in recognizing interdependent tasks in the project.
• It also helps to find out the shortest path or critical path to complete the
project successfully.
• Like PERT diagram, each event is allotted a specific time frame.
• This tool shows dependency of event assuming an event can proceed to next only
if the previous one is completed.
• The events are arranged according to their earliest possible start time.
• Path between start and end node is critical path which cannot be further reduced
and all events require to be executed in same order.

ACTIVITY DURATION DEPENDENCIES
T1 8 -
T2 15 -
T3 15 T1(M1)
T4 10 -
T5 10 T2,T4(M2)

Gantt Chart
Gantt charts was devised by Henry Gantt (1917).
It represents project schedule with respect to time periods.
It is a horizontal bar chart with bars representing activities and time scheduled
for the project activities.

PERT Chart
• PERT (Program Evaluation & Review Technique) chart is a tool that depicts
project as network diagram.
• It is capable of graphically representing main events of project in both parallel and
consecutive way.
• Events, which occur one after another, show dependency of the later event over
the previous one.
• Events are shown as numbered nodes. They are connected by labeled arrows
depicting sequence of tasks in the project.

Unit 1 OOSE

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Unit 1 OOSE

Ähnlich wie Unit 1 OOSE (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Unit 1 OOSE

Hinweis der Redaktion