Question 1 Compare and Contrast Waterfall Model with Spiral Model.

Definition of Waterfall Model

The waterfall model is a classical software life cycle model.

The model’s flow is sequential as the suggests similar to a
waterfall in a top-down fashion, that is the reason it is also
known as the linear sequential model. It has various phases
such as requirement analysis, design, coding, testing,
integration, implementation and maintenance.

Phases of the Waterfall Model

 Feasibility Study – In this stage, the cost and benefits are evaluated of
the proposed application. The feasibility analysis should produce a
document containing – definition of the problem, discovering the
technical and economic viability, alternate solutions, needed resources,
cost and delivery dates.

 Requirement Analysis and specifications – This helps in finding

gathering the requirements of the project what the project is needed. It
determines the quality of the project such as functionality, ease of use,
performance, portability, etc. The Software Requirement Specification
(SRS) document contains – thorough statement of the problem,
probable alternate solution to the problem, functional requirement of the
software system, constraints on the software system.

 Design – This phase is a multistep process concentrates on four

different attributes of a program: data structure, software architecture,
interface representations and algorithmic details. The design phase
converts the requirement specification into the representation of the
software that can be evaluated before the coding phase.

 Coding and Module Testing – The design must be converted into a

machine-readable form in order to produce software so in this step we
actually write programs with the help of programming languages. While
the module testing involves the definition of a test plan, the definition of
the testing criteria to be followed (such as black-box or white-box or
 combination of the two), the definition of completion criteria (when to
cease it) and at last management of test cases.

 Integration and System Testing – This phase combines the modules

of the software in a systematic and planned manner. The integration of
the modules can no be conducted in one go but require several
iterations. Furthermore, system testing is carried out to check whether
the software system works as described in the SRS document. The
three phases of system testing are- alpha, beta and acceptance testing.

 Delivery and Maintenance – After delivering the product it is analysed

for some period to detect and correct the errors which don’t show up in
early stages of software, and this is known as maintenance.

Definition of Spiral Model

The spiral model is an evolutionary type of software life cycle model which
merges the features of the prototype model and waterfall model. It has the
potential for developing the incremental versions of the softwares by
implementing the iterativeness of the prototype model and controlled
methodical of the linear segmental model. The outcome of the spiral model is
the series of the incremental releases of the software.

It is a realistic approach to develop large-scale systems and software. In the

core or initial pass of the process, the product specification is constructed and
in subsequent passes around the spiral the prototype gets developed and
then more improved versions of the software get developed. These prototypes
are evaluated and validated by customers. It also analyses risk at each pass.
The project starts by defining the entry axis points in the spiral model.

It works by dividing the model into framework activities, which are known as
task regions. Basically, there are three to six task regions could present such
as customer communication, planning, risk analysis, engineering and so on
which are described below.

Task regions of Spiral Model

 Customer communication – It must enable effective communication

between the various tasks.
  Planning – This region involves all project related activities such as
defining resources, timelines, etcetera.

 Risk analysis – The technical and management risks are evaluated in

this task.

 Engineering – This task region is modelled for constructing one or

more representations of applications executing.

 Construct and release – It carries out all the important tasks needed to
build, test, install the application and also provides user support.

 Customer evaluation – This task region obtain customer’s feedback on

the basis of customer evaluation and implement it at the installation
stage.

Key Differences –

1. The waterfall model is analogous to a waterfall which follows a

sequential approach for its stages while developing a product. On the
contrary, the spiral model is founded on an evolutionary strategy where
a spiral is subdivided into several task regions.

2. Requirement gathering in both of the models is completely different

where waterfall do it once in the whole process. As against, in a spiral
model, the requirement can be gathered after each iteration.

3. Risks to the product can only be identified at the end of the process in
the waterfall model. Conversely, the spiral model recognizes risk at
earlier phases of the process which is revised at each iteration too.

4. The waterfall model produces the single final product at the end of the
process. In contrast, the spiral model generates a rough working
product at each iteration.

5. Waterfall model is suitable for small systems while spiral is preferred

when the large system is developed.
The spiral model is different from waterfall model due to the feature of definite
identification of the risk which reduces the chances of failure of the project. On
the other hand, the waterfall is quite risky as there are no iterations everything
have to be done at once meaning the requirements are gathered, planned,
designed, coded, integrated at one time for a software product.

Question 2 What do you mean by SRS and why is it important. Give suitable
example? Explain Software Design Principles in detail.

A software requirements specification (SRS) is a comprehensive description

of the intended purpose and environment for software under development.
The SRS fully describes what the software will do and how it will be expected
to perform.

An SRS minimizes the time and effort required by developers to achieve

desired goals and also minimizes the development cost. A good SRS defines
how an application will interact with system hardware, other programs and
human users in a wide variety of real-world situations. Parameters such as
operating speed, response time, availability, portability,
maintainability, footprint, security and speed of recovery from adverse events
are evaluated. Methods of defining an SRS are described by
the IEEE (Institute of Electrical and Electronics Engineers) specification 830-
1998.

Key components of an SRS

The main sections of a software requirements specification are:

 Business drivers – this section describes the reasons the customer is

looking to build the system, including problems with the currently system
and opportunities the new system will provide.

 Business model – this section describes the business model of the

customer that the system has to support, including organizational,
business context, main business functions and process flow diagrams.

 Business/functional and system requirements -- this section typically

consists of requirements that are organized in a hierarchical structure.
 The business/functional requirements are at the top level and the
detailed system requirements are listed as child items.

 Business and system use cases -- this section consists of a Unified

Modeling Language (UML) use case diagram depicting the key external
entities that will be interacting with the system and the different use
cases that they’ll have to perform.

 Technical requirements -- this section lists the non-functional

requirements that make up the technical environment where software
needs to operate and the technical restrictions under which it needs to
operate.

 System qualities -- this section is used to describe the non-functional

requirements that define the quality attributes of the system, such as
reliability, serviceability, security, scalability, availability and
maintainability.

 Constraints and assumptions -- this section includes any constraints

that the customer has imposed on the system design. It also includes
the requirements engineering team’s assumptions about what is
expected to happen during the project.

 Acceptance criteria -- this section details the conditions that must be

met for the customer to accept the final system.

Purpose of an SRS

An SRS forms the basis of an organization’s entire project. It

sets out the framework that all the development teams will
follow. It provides critical information to all the teams,
including development, operations, quality assurance (QA)
and maintenance, ensuring the teams are in agreement.

Using the SRS helps an enterprise confirm that the

requirements are fulfilled and helps business leaders make
decisions about the lifecycle of their product, such as when to
retire a feature.

In addition, writing an SRS can help developers reduce the

time and effort necessary to meet their goals as well as save
money on the cost of development.

SRS Example

The following is a simple SRS template:

Table of Contents

1. Introduction

1.1 Purpose of this document

1.2 Scope of this document

1.3 Overview

1.4 Business Context

2. General Description

2.1 Product Functions

2.2 Similar System Information

2.3 User Characteristics

2.4 User Problem Statement

2.5 User Objectives

2.6 General Constraints

3. Functional Requirements

4. Interface Requirements

4.1 User Interfaces

4.2 Hardware Interfaces

4.3 Communications Interfaces

4.4 Software Interfaces

5. Performance Requirements

6. Other non-functional attributes

6.1 Security

6.3 Reliability

6.4 Maintainability

6.5 Portability

6.6 Extensibility

6.7 Reusability

6.8 Application Affinity/Compatibility

7. Operational Scenarios

8. Preliminary Use Case Models and Sequence Diagrams

8.1 Use Case Model

8.2 Sequence Diagrams

9. Updated Schedule

10. Appendices

10.1 Definitions, Acronyms, Abbreviations

10.2 References

Question 4 What is WBS and Rayleigh Curve in detail with

diagram, explain by giving suitable example.

A Work Breakdown Structure includes dividing a large and complex

project into simpler, manageable and independent tasks. The root of
this tree (structure) is labelled by the Project name itself. For
constructing a work breakdown structure, each node is recursively
decomposed into smaller sub-activities, until at the leaf level, the
activities becomes undividable and independent. It follows a Top-
Down approach.
Steps:
 Step-1: Identify the major activities of the project.
 Step-2: Identify the sub-activities of the major activities.
 Step-3: Repeat till undividable, simple and independent activities
are created.
Construction of Work Breakdown Structure:
Firstly, the project managers and top level management identifies the
main deliverables of the project. After this important step, these main
deliverables are broke down into smaller higher-level tasks and this
complete process is done recursively to produce much smaller
independent tasks. It depends on the project manager and team that
upto which level of detail they want to break down their project.
Generally the lowest level tasks are the most simplest and
independent tasks and takes less than two weeks worth of work.
Hence, there is no rule for upto which level we may build the work
breakdown structure of the project as it totally depends upon the type
of project we are working on and the management of the company.
The efficiency and success of the whole project majorly depends on
the quality of the Work Breakdown Structure of the project and hence,
it implies its importance.
Uses:
 It allows to do a precise cost estimation of each activity.
 It allows to estimate the time that each activity will take more
precisely.
 It allows easy management of the project.
 It helps in proper organisation of the project by the top
management.

Rayleigh Curve –

Example ?

Question 5 What are the different methods of Software Cost

Estimation? Explain COCOMO model in detail.

Cost estimation is a set of techniques and procedures

used to arrive at a cost estimate. These techniques are
utilised by the process of cost estimation to compute the
output from the given set of inputs. The inputs to the
process of cost estimation are also called as cost drivers
and the outputs are expressed in the form of efforts,
duration, loading, or modified requirements to name a
few.

Algorithmic (parametric) model:
This model takes the aid of mathematical equations to
calculate cost estimation. The mathematics involved in this
model is based on historical cost data and theory. The cost
drivers or the inputs to this model comprise of function points
and SLOC (source line of code). Examples of function points
include user interactions, external inputs and outputs, as well
as the files utilised by the system. The cost is estimated as a
function of the software product, project and process attributes
such as the size of the code. Example utilising this model is
the COCMO.
Cost estimate = a x (size^b) x M
Where,
a=organisation depending constant
b=factor for effort spent in projects
m=factor reflecting the people/project/process attribute
 Expert Judgement:This method of cost estimation makes use of the tenure based project
experience gained by the estimator. All the domain based knowledge achieved by working in
similar projects is brought to the fore in arriving at an estimated figure. Examples using this
concept are Delphi & WBS (Work breakdown structure). This technique has been found to be
very useful where there is a lack of quantifiable data. However the approach suffers from
difficulty in documenting the factors incorporated by the estimator.
 Estimation by analogy :Similar in content to the expert judgement approach, this method
merely uses information and experience gained by a previously executed project. Using the tool
of extrapolation, this data is compared with the information derived from the proposed project
with similar area of expertise, to conclusively arrive at a rough cost estimate.
 Top down approach: Also called as the Macro model, the top down approach initiates with
coming down to every major detail related to the software product or project. Thereafter, the
product/project is divided into components belonging to lower levels. Following this, distinct
labour categories are created relevant for each segregated task. The product of the costs incurred
and the number of tasks involved is calculated to get to the final figure for the total labour costs
incurred in the project. The approach requires a thorough knowledge of the project pricing
mechanism for computation of accurate estimates. The approach has appeal limited to small
scale installations.

 Bottom up approach:In this method, the project managers add on to their costs upwards
initiating from the lowermost levels. The process is time consuming as every possible expense be
it labour related or equipment based is added up starting from the foundation levels. This
approach is well suited to large multi faceted projects.
Cocomo (Constructive Cost Model) is a regression model based on
LOC, i.e number of Lines of Code. It is a procedural cost estimate
model for software projects and often used as a process of reliably
predicting the various parameters associated with making a project
such as size, effort, cost, time and quality. It was proposed by Barry
Boehm in 1970 and is based on the study of 63 projects, which make
it one of the best-documented models.
The key parameters which define the quality of any software products,
which are also an outcome of the Cocomo are primarily Effort &
Schedule:
 Effort: Amount of labor that will be required to complete a task. It
is measured in person-months units.
 Schedule: Simply means the amount of time required for the
completion of the job, which is, of course, proportional to the
effort put. It is measured in the units of time such as weeks,
months.
Types of Models: COCOMO consists of a hierarchy of three
increasingly detailed and accurate forms. Any of the three forms can
be adopted according to our requirements. These are types of
COCOMO model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
The first level, Basic COCOMO can be used for quick and slightly
rough calculations of Software Costs. Its accuracy is somewhat
restricted due to the absence of sufficient factor considerations.
Intermediate COCOMO takes these Cost Drivers into account
and Detailed COCOMO additionally accounts for the influence of
individual project phases, i.e in case of Detailed it accounts for both
these cost drivers and also calculations are performed phase wise
henceforth producing a more accurate result. These two models are
further discussed below.
1. Basic Model –
E=a(KLOC)^b
 The above formula is used for the cost estimation of for the basic
COCOMO model, and also is used in the subsequent models.
The constant values a and b for the Basic Model for the different
categories of system:
SOFTWARE PROJECTS A B

Organic 2.4 1.05

Semi Detached 3.0 1.12

Embedded 3.6 1.20

The effort is measured in Person-Months and as evident from the

formula is dependent on Kilo-Lines of code. These formulas are
used as such in the Basic Model calculations, as not much
consideration of different factors such as reliability, expertise is
taken into account, henceforth the estimate is rough.
2. Intermediate Model –
The basic Cocomo model assumes that the effort is only a
function of the number of lines of code and some constants
evaluated according to the different software system. However,
in reality, no system’s effort and schedule can be solely
calculated on the basis of Lines of Code. For that, various other
factors such as reliability, experience, Capability. These factors
are known as Cost Drivers and the Intermediate Model utilizes 15
such drivers for cost estimation.
Classification of Cost Drivers and their attributes:

(i) Product attributes –

 Required software reliability extent
 Size of the application database
 The complexity of the product
(ii) Hardware attributes –
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
(iii) Personnel attributes –
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
(iv) Project attributes –
 Use of software tools
 Application of software engineering methods
 Required development schedule
;
VERY VERY

COST DRIVERS LOW LOW NOMINAL HIGH HIGH

Product Attributes

Required Software

Reliability 0.75 0.88 1.00 1.15 1.40

Size of Application

Database 0.94 1.00 1.08 1.16

Complexity of The

Product 0.70 0.85 1.00 1.15 1.30

 VERY VERY

COST DRIVERS LOW LOW NOMINAL HIGH HIGH

Hardware Attributes

Runtime Performance

Constraints 1.00 1.11 1.30

Memory Constraints 1.00 1.06 1.21

Volatility of the virtual

machine environment 0.87 1.00 1.15 1.30

Required turnabout time 0.94 1.00 1.07 1.15

Personnel attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71

Applications experience 1.29 1.13 1.00 0.91 0.82

Software engineer

capability 1.42 1.17 1.00 0.86 0.70

 VERY VERY

COST DRIVERS LOW LOW NOMINAL HIGH HIGH

Virtual machine

experience 1.21 1.10 1.00 0.90

Programming language

experience 1.14 1.07 1.00 0.95

Project Attributes

Application of software

engineering methods 1.24 1.10 1.00 0.91 0.82

Use of software tools 1.24 1.10 1.00 0.91 0.83

Required development

schedule 1.23 1.08 1.00 1.04 1.10

The project manager is to rate these 15 different parameters for

a particular project on a scale of one to three. Then, depending
on these ratings, appropriate cost driver values are taken from
the above table. These 15 values are then multiplied to calculate
the EAF (Effort Adjustment Factor). The Intermediate COCOMO
formula now takes the form:
 The values of a and b in case of the intermediate model are as
follows:
SOFTWARE PROJECTS A B

Organic 3.2 1.05

Semi Detached 3.0 1.12

Embeddedc 2.8 1.20

3. Detailed Model –
Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s
impact on each step of the software engineering process. The
detailed model uses different effort multipliers for each cost driver
attribute. In detailed cocomo, the whole software is divided into
different modules and then we apply COCOMO in different
modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
The effort is calculated as a function of program size and a set of
cost drivers are given according to each phase of the software
lifecycle.
 Question 6 What do you mean by the risk in a project? What
are the different approaches towards risk management? What
is Risk Matrix and Risk Mitigation?

The exposure to a company that arises from taking on a particular task. A project
risk can be internal to the business, it can involve external events or it can stem
from any other circumstances that can hamper the project's overall success and
result in loss or embarrassment to the firm undertaking it.

Three kinds of approach can be followed for involving management and

stakeholders in identifying risks:

 Top down-approach: the decision-making process is centralized at governance

level. This approach can show two modes: a) Full top-down mode, where the
business units’ risks are listed at department level, meaning that heads of unit
cannot add risks themselves at unit level. There is no need of risk escalation,
except at departmental level. b) Prevailing top-down mode, where a corporate
risk register is directly created from a detailed operational risk register.
 Bottom-up approach: the decision-making process is done at management
level. Operational risks are identified by any staff member while performing his or
her daily work (e.g., in order to encourage the staff to be more active in defining
non-conformities, an opportunity to register them online has been provided).
 Mixed approach: the board entity states the criteria (top-down) by which the
heads of unit identify and manage risks (bottom-up). Risks may be viewed and
assessed throughout the organization at any level (e.g., group, program, office,
project, etc.). In order to set the framework, the hierarchy of risks on which
attention is focused corresponds to the enterprise, operational and project levels.
Risk Mitigation

The objective of risk mitigation is to reduce the probability

and/or consequences of a risk event to an acceptable
threshold and define appropriate response. Questions To
Ask:

 What are the available options?

 Tradeoffs (cost / benefit) of each option?

 Impacts of current decisions on options?

Risk mitigation actions may be costly and time consuming;
actions taken are balanced against priority level of the
risk. Organizations typically transfer risk where possible, for
example through product warranty.

Low-risk factors may be recognized by the Organization but

absorbed as a matter of policy.

Risk Matrix-

A risk matrix are probably the inter-industry safety standard

for the tool used in risk evaluation. In aviation SMS
programs they are ubiquitous. They use “probability” and
“severity” to quantify the scope of a real or hypothetical safety
scenario. The quantification is generally broken into 3
categories:

 Acceptable risk (green);

 Unacceptable risk (red); and
 Ideally risk that is as low as reasonably possible
(ALARP) (yellow), though risk in this middle section
should be monitored carefully to ensure that reasonable
controls are in place.

Some organizations use more colors, such as light green

and/or orange. Extra colors only provide further “aesthetic”
rather than quantification. Risk matrix are ultimately used risk
management tools used to rank risks with the risk grid.

Question 7
Software Quality Assurance (SQA) is simply a way to
assure quality in the software. It is the set of activities which
ensure processes, procedures as well as standards suitable
for the project and implemented correctly.

Software Quality Assurance is a process which works parallel

to development of a software. It focuses on improving the
process of development of software so that problems can be
prevented before they become a major issue. Software
Quality Assurance is a kind of an Umbrella activity that is
applied throughout the software process.
Software Quality Assurance have:

1. A quality management approach

2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism
Major Software Quality Assurance Activities:

1. SQA Management Plan:

Make a plan how you will carry out the sqa through out
the project. Think which set of software engineering
activities are the best for project.check level of sqa team
skills.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the
 performance of the project on the basis of collected data
on different check points.
3. Multi testing Strategy:
Do not depend on single testing approach. When you
have lot of testing approaches available use them.
4. Measure Change Impact:
The changes for making the correction of an error
sometimes re introduces more errors keep the measure
of impact of change on project. Reset the new change to
change check the compatibility of this fix with whole
project.
5. Manage Good Relations:
In the working environment managing the good relation
with other teams involved in the project development is
mandatory. Bad relation of sqa team with programmers
team will impact directly and badly on project. Don’t play
politics.
Benefits of Software Quality Assurance (SQA):

1. SQA produce high quality software.

2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for
long time.
5. High quality commercial software increase market share
of company.
6. Improving the process of creating software.
7. Improves the quality of the software.
Disadvantage of SQA:
There are a number of disadvantages of quality assurance.
Some of them include adding more resources, employing
more workers to help maintain quality and so much more.

Question 8

project management ensures the successful completion of a

number of different processes, while project control makes sure
those processes actually head in the right direction (to be classed
as “successful”). It ensures projects are done correctly and the
“right” projects are chosen in the first place.

Project control exists to answer three vital questions

 how much the project will cost

 how long the project will take
 what value or quality the project will deliver

In practical project management terms, these translate into

controlling project scope, meeting quality requirements, keeping
projects to schedule and budget, managing risks, identifying
issues, and ensuring projects benefit the company.

A lot of that comes down to collecting and managing data,

finding trends, forecasting outcomes, reporting on progress and
actually actively putting learnings into practice. Without
controlling for these, projects quickly become wildly ineffective
and expensive.
orting on progress and actually actively putting learnings into
practice. Without controlling for these, projects quickly become
wildly ineffective and expensive.

How project control fits into project management

Now we know what we’re dealing with, let’s see how to practically
apply project control throughout the project management cycle.

The planning phase

The first stage of project management is planning and outlining

your fundamentals: the issues you need to solve, the people who
need to be involved, the actual work you’ll do. You need to
identify stakeholders and define project objectives that set the
boundaries for project success.

Part of that success depends on providing realistic cost and

time estimations, both of which form part of project control. So
many projects fail simply because they underestimate time or
money constraints, so you need to forecast these variables as
tightly as possible. And the best way to do that is by analyzing
performance data from similar past projects. In particular, take
note of:

 All the tasks involved in the project

 How long each project phase took
 Budget spend per individual task
  How project activity was spread across your team
 The billable to non-billable ratio of project work

But the whole endeavor doesn’t have to mean a load of extra

work – project time tracking tools can now automatically collect
and digest your project data for you.
Improve the accuracy of your project esitmates

The development phase

The build-up or development phase of project management is all

about getting the ball rolling. This is where the team assembles,
stakeholders meet and assignments are planned. And once again,
project control is key to success. Your cost estimates become
budgets and time estimates become schedules, and project
control is responsible for four important aspects:

Planning/Scheduling: the beginning of a project plan and

schedule, the accurate monitoring and reporting of scheduled
work, and the rapid detection and correction of any “deviations”
to bring your schedule back on-course.

Cost Control: monitoring expenses and performance, monitoring

budget spend, and taking action to hit minimum costs

Cost Estimation: the foundation of cost control and cost

management, predicting the quantities and prices for the
resources required.

Cost and schedule risk analysis: an assessment of risk on the

project’s schedule and cost. Analysis takes into account the
predicted delivery date, the likelihood of meeting deadlines, and
the recognition of risks to the project’s cost.
Make workplace communication more effective

The implementation phase

On to putting your plan into action! While super rewarding, this

stage comes with a lot of frustrations. You need to keep your
team focused with clear agendas to make sure no one gets
sidetracked. A lot of that depends on being able to accurately
diagnose your team’s progress and activity.

Invest in a team management tool that lets you quickly identify

time drains, quality issues and team allocation problems. In
particular, make sure it shows you:

 Individual and total employee capacity

 Activity breakdown per employee
 How long employees spend on each task
 Hours worked per employee
 Budget spend per employee
This information can help you pinpoint broken processes,
overloaded employees and disruptive tasks. By monitoring this
data, you can balance workloads, allocate project resources
effectively and keep your team aligned with project priorities.

Track team performance across your projects automatically

The closeout phase

You’ve finished the project! Surely that means the project control
element is over? Not quite. You need to be able to review its total
performance, understanding trends and processes that led to
success so you can repeat them for future projects.

Did your team meet their objectives? Did they progress at the
expected rate? Did you deliver a quality product and still stick to
budget? Is there still work to do? Good project control allows you
to appraise these points. So do a thorough debrief – compile
performance data and break it down to the project task level to
uncover new learnings.
You should charter exactly how your project transpired –
where time was spent, where activity veered off course, and what
limited productivity – and build effective measures into your new
projects to control for them further.