UNIT-I

Software Definition

Software is a set of programs, which is designed to perform a well defined function. Software can be
difficult to describe because it is virtual, or not physical like computer hardware. Instead, software consists
of lines of code written by computer programmers.

Software Characteristics

Software has characteristics that are considerably different than those of hardware:

1. Software is engineered, not manufactured like hardware.

 Software development is same as hardware manufacturing but it is fundamentally different activity.

In hardware manufacturing it introduce quality problem but it can easily corrected in software
development.

 Once a product is manufactured it is not possible or not easy to correct it, change it, enhance it,
remove error from it without temper product or it is costly. But software can easily.

 So the approach of construction of product is different. In case of hardware product numbers of

copies generate a cost due to raw material and other manufacturing processing expenses but in case
of software it is not the issue. You can create number of copies of software.

2. Software does not wear out.

 First we understand the characteristic of hardware. Hardware can damaged after running
time. As time passes hardware component suffer from effects of dust, vibration, misuse,
temperature and many other environmental effects. So the failure rate rises. This is the wear
out of hardware.

 The "bathtub curve" shown in Figure 1 depicts failure rate of hardware as a function of
time. Hardware suffers high failure rate early in its life. There are three phases in
hardware life.
 In first phase failure rate is much more. But after testing and fixing bugs failure rate will
come down and may stabilize after certain time. Second phase is useful life phase of
1
 hardware component where failure rate is approximately low and constant. And after
few years it comes in last stage where failure rate is high and product will wear out.
 But software is not highly affected by environmental effects which cause hardware to
wear out. The failure rate graph for software component is "Idealized curve" shown in
Figure 2.
 Undiscovered errors will cause high failure rates early in the life of a program. However,
these are corrected and the curve becomes flat as shown. The "actual curve" is shown in
Figure 2.
 During its life, software will undergo change or maintenance. As changes are made,
some new defects will be introduced, causing the failure rate curve to spike.
 When hardware component wears out, it is just replaced by spare parts. There is no spare
part to replace in software component. It requires further changes in existing product or
component. So it is more complex than hardware.

3. Software gives component-based construction, it gives reusability of components.

 Now a day’s industry is moving towards component based construction. Efforts have
been made to design standard components that may be used in new project. Software
reusability has introduced another area which is known as component based software
engineering.
 A software component should be designed and implemented so that it can be reused in
many different programs.
 Once different components are created and tested separately, at final product each
componentseparately not needed to be checked or tested. Integration of components and
final product should be tested. Graphical User Interfaces are built using reusable
components that enables the creation of graphics window and animated menus.

4. Software is flexible for custom built.

 A program can be developed to do anything. Sometimes, this characteristic may be the
best and may help us to accommodate any kind of change. However, most of the times,
this "almost anything" characteristic has made software development difficult to plan,
monitor and control. This unpredictability is the beginning of software crisis.

Components of Software

I. Functionality
Functionality refers to the degree of performance of the software against its intended purpose. It

2
 refers to the set of features and capabilities that a software program or system provides to its users. It is
one of the most important characteristics of software, as it determines the usefulness of the software for
the intended purpose.
Examples of functionality in software include:
1. Data storage and retrieval
2. Data processing and manipulation
3. User interface and navigation
4. Communication and networking
5. Security and access control
6. Reporting and visualization
7. Automation and scripting

Required functions are:

II. Reliability
A set of attributes that bears on the capability of software to maintain its level of performance
under the given condition for a stated period of time.
Reliability is a characteristic of software that refers to its ability to perform its intended functions
correctly and consistently over time. Reliability is an important aspect of software quality, as it helps
ensure that the software will work correctly and not fail unexpectedly.
Examples of factors that can affect the reliability of software include:
1. Bugs and errors in the code
2. Lack of testing and validation
3. Poorly designed algorithms and data structures
4. Inadequate error handling and recovery
5. Incompatibilities with other software or hardware

To improve the reliability of software, various techniques and methodologies can be used, such as
testing and validation, formal verification, and fault tolerance.
Software is considered reliable when the probability of it failing is low and it is able to recover from the
failure quickly, if any.
Required functions are:

III. Efficiency
It refers to the ability of the software to use system resources in the most effective and efficient
manner. The software should make effective use of storage space and executive command as per desired
timing requirements.

3
 Efficiency is a characteristic of software that refers to its ability to use resources such as memory,
processing power, and network bandwidth in an optimal way. High efficiency means that a software
program can perform its intended functions quickly and with minimal use of resources, while low
efficiency means that a software program may be slow or consume excessive resources.
Examples of factors that can affect the efficiency of software include:
1. Poorly designed algorithms and data structures
2. Inefficient use of memory and processing power
3. High network latency or bandwidth usage
4. Unnecessary processing or computation
5. Un optimized code

To improve the efficiency of software, various techniques and methodologies can be used, such as
performance analysis, optimization, and profiling.
Efficiency is important in software systems that are resource-constrained, high-performance, and real-
time systems. It is also important in systems that need to handle a large number of users or transactions
simultaneously.

Required functions are:

IV. Usability
It refers to the extent to which the software can be used with ease. The amount of effort or time
required to learn how to use the software.
Required functions are:

V. Maintainability
It refers to the ease with which the modifications can be made in a software system to extend its
functionality, improve its performance, or correct errors.
Required functions are:

VI. Portability
A set of attributes that bears on the ability of software to be transferred from one environment to
another, without or minimum changes.
Required functions are:

4
Software Applications
The 7 categories of computer software are:
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software
 Web-applications
 Artificial intelligence software
1. System Software
System software is a collection of programs written to service other programs. The system
software is characterized by,
 heavy interaction with computer hardware
 heavy usage by multiple users
 concurrent operation that requires scheduling, resource sharing, and sophisticated process
management
 complex data structures and
 multiple external interfaces
E.g. compilers, editors and file management utilities.
2. Application/Real Time Software
 Application software consists of standalone programs that solve a specific business need.
 It facilitates business operations or management/technical decision making.
 It is used to control business functions in real-time.
E.g. point-of-sale transaction processing, real-time manufacturing process control.
3. Engineering/Scientific Software
Engineering and scientific applications ranges
 from astronomy to volcanology.
 from automotive stress analysis to space shuttle orbital dynamics.
 from molecular biology to automated manufacturing.
E.g. Computer aided design, system simulation and other interactive applications.
4. Embedded Software
 Embedded software resides within a product or system and is used to implement and control
features and functions for the end-user and for the system itself.
 It can perform limited and esoteric functions or provide significant function and control capability.
E.g. Digital functions in automobile, dashboard displays, braking systems etc.

5
 5. Product-line/Business Software
 Designed to provide a specific capability for use by many different customers, product-line
software can focus on a limited and esoteric market place or address mass consumer markets
E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment,
Database management, personal and business financial applications.
6. Web-applications
 Web Apps are evolving into sophisticated computing environments that not only provide
standalone features, computing functions, and content to the end user, but also are integrated
with corporate databases and business applications.
7. Artificial intelligence Software
 AI software makes use of non-numerical algorithms to solve complex problems that are not
amenable to computation or straightforward analysis.
 Application within this area includes robotics, expert systems, pattern recognition, artificial
neural networks, theorem proving, and game playing.
Definition
Software Engineering is the process of designing, developing, testing, and maintaining
software. It is a systematic and disciplined approach to software development that aims to create high-
quality, reliable, and maintainable software.
Software engineering includes a variety of techniques, tools, and methodologies, including
requirements analysis, design, testing, and maintenance.
Software Engineering is mainly used for large projects based on software systems rather than
single programs or applications.
The main goal of software Engineering is to develop software application for improving the
quality, budget and time efficiency. Software Engineering ensures that the software that has to built
should be consistent, correct, also on budget, on time and within the required requirements.
Attributes of Software Engineering
 Efficiency
 Reliability
 Robustness
 Maintainability

Software Engineering is a systematic, disciplined, quantifiable study and approach to the design,
development, operation, and maintenance of a software system.

NEED OF SOFTWARE ENGINEERING

 Software engineering is methodology provides the framework that guides engineers to
developing the software.
 This framework defines different phases of software development such as requirements
analysis, designing, testing, implementation, maintenance etc.
 The hard part of building software is the specification, designing and testing, not the
representation and implementation.
 Software engineering describes how the software is designed, what types of their
6
 requirements and what types of different phases are needed to complete the software
product.
 The main goal of software engineering is to provide models and processes that produce
well- documented, maintainable software.
 Using process model we can determine in advance how much time, cost and efforts are
required to produce the final complete product.
 Main important point of any software development process is the life cycle on which
flow of process is based. This is called software development life cycle (SDLC).
 SDLC includes requirement phase, design phase, implementation phase, testing phase,
installation phase, maintenance phase.

SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY

 Software engineering is a layered technology. Software engineering includes process,
methods and tools that enable complex computer system to be built in a timely manner
with quality. To build any software product engineer should use and aware of these four
layers: Quality, Process, Methods and Tools.

Quality
 The main focus of software engineering is to develop quality product.
 Quality of product refers to the characteristics that engineer specify for the product.
 In software development, quality of product refers to the output meets the
functions andfeatures specified in the requirement model.

Process
 The foundation layer is process layer. It is the heart of the software engineering approach.
 Software process is a set of activities together if ordered and performed properly the
desiredresult would be produced.
 It defines framework activity.
 Main objective of this layer is to deliver software in time.

Method
 The layer after process is method. It describes how to build the software product.
 Method includes different tasks such as user communication, requirement analysis,
designmodeling, coding, testing and maintenance.
 Method gives the exact way to build the software. Method is a way to execute
processes inproper manner.

7
 Tools
 Software engineering tools provide automated and semi-automated support to
method and process. Any information created by one tool can be used by
another, when tools are integrated.
 Computer aided software engineering (CASE) combines software, hardware,
and software engineering database (a repository containing important
information about analysis, design, program construction and testing) to
create a software engineering environment.

PROJECT SIZE CATEGORIES:

Project size is a major factor that determines the level of management control and the types of
tools and techniques required on a software project.

Trivial Project:
No.of programmers :1
Duration :for a few days, few weeks
Product Size :500 source line
Packaged in :10 to 20 subroutines These Programs are often personal software Developed
exclusively for the use of the programmer
Small amount of formal analysis,elaborate design documentation, extensive test planning or
supporting documents are needed.

Small Project:
No.of programmers : 1
Duration : 1 to 6 months
Product Size : 1000 to 2000 source lines Packaged in 25 to 50 subroutines
Small Programs usually have no interactions with other programs.
Example, Scientific applications written by engineers to solve numerical problems.
Students Projects written in compiler and Operating System.
Small Project requires little interactions between programmers and customers.
Standardized techniques and notations, standardized documents and systematic project
reviews should be used in small projects.

Medium Size Projects:

No.of Programmers : 2 to 5
Duration : 1 to 2 years
Product Size : 10,000 to 15,000 source lines Packaged in 250 to 1000 routines.
Examples
Medium size projects includes assesmblers,Compilers,Small management information 8
system,inventory system and Process control applications.
To develop such programs, interaction among programmers and Customers is required.
A certain degree of formality is required in planning, documents and project reviews.
Most application programs,System programs are developed in 2 years or
less by 5.

Larger Size Projects:

o No.of Programmers : 5 to 20
o Duration : 2 to 3years
o Product Size :50,000 to 1 lakhs source lines.
o Packaged in several sub systems.
o Large programs has significant interactions with other programs and sub
systems.
o Examples, Compilers,Small time sharing systems, database packages,graphic
packages and real time control systems.
o Communication among programmers,managers,customers are needed.
o The larger projects requires more than 1 programming team.
o Example, three teams of 5 persons each.
o It involves more than 1 level of management.
o Systamatic process standardized documents and formal reviews are essential.

Very Large Projects:

o No.of Programmers : 100 to 1000
o Duration : 4 to 5 years
o Product Size : 1 million source lines
o It consists of several major subsystem each of which forms a large system.
o The subsystem have complex,interactions with one another and with other
separate we developed system.
o Tele communication and multi tasking.
o It includes large OS, large database system and military commandor and
control system.
Extremely large Projects:
o No.of Programmers : 2000 to 5000
o Duration : 5 to 10 years
o Product Size : 1 million to 10 million source lines
o It consist of several very large subsystem.
o It involves real time processing,tele communications,multi tasking and
distributed processing.
o Example,Air traffic control,military commandor control system.

Quality and Productivity Factors:

 Development and maintenance of software product are complex task.
9
 There is a fundamental difference between writing a small programs for PC
and developing or modifying a software product.
 Software Quality and programmer productivity can be improved by
improving the process used to develop and maintain software products.
Individual Ability:
 Production and maintenance of software products are labour intensive
activities.
 Productivity and Quality are direct functions of individual ability and effort.
 There are two aspects of ability

 General competition of the individual

 Familiarity of the individual with the particular application area.

 Lack of familiarity with the application area can research in low

productivity and poor quality.
 On very large and extremely large projects no of programmers so
large.
 The individual differences in programmer productivity will tend to
average out.
 Modules developed by weaker programmers may show poor quality
and may lag in delivery time.
 Small and medium size projects (5-fewer programmers)are extremely
sensitive to the ability of the individual programmer.
 Individual ability is a primary factor in quality and productivity.

Team communication:
 Programming has regarded as an individual and private activity.
 Programmers are rarely preced as public documents and they rarely discuss
the exact details of the work in a systematic manner.
 So as a result ,the programmers may mis understand the role of their modules
in an evolving system.
 This mades mistake that may not be detected until some time later. Many of
the recent innovations in software Engineering such as design,reviews and
code reading exercise have the goals of making software more visible and
improving communications among programmers.
 Increasing product size results in decreasing programmer productivity due to
the increased complexity of interactions among program components.
 Due to this increased communication is required among
programmers,managers and customers.

From Brooks observation:

No of communication path among programmers = n(n-1)/2 Where,n=no of programmers.

Increasing the number of team members from 3 to 4 to 5 increases the no of communication 10

path from 3 to 6 to 10.

Brooks law:“Adding more programmers to a late project may make it later”

Product complexity:

There are 3 levels of product complexity.

1. Application Programs
2. Utility Programs. 3.System level Programs.

Application Program
It includes scientific and data processing routines written in a high level language such as
COBOL,FORTRAN,C,C++.

Utility Program

It includes compilers,Assemblers,linkage Editors and loaders.

They may be written in high level language or Assembly language.

System Level Programs:

It includes data communication packages real time process control system, OS routines in any
kanguages.(i.e)high level or assembly.

 Application programs have the highest productivity and the system programs the
lowest productivity.
 Utility programs can be produced at a rate of 5-10 times of system programs.
 Application programs at a rate of 25-100 times of system programs.
 A product that is twice as large or twice as complex as a known product,by
whatever measure other than effort may require 10 times or even 100 times the
amount of effort required for the known product.

Appropriate Notations:

 In software engineer the representation schemes have fundamental

importance, programming languages provides compact notations for the
implementation phase of software development.
 But there are no widely accepted notations for stating functional
requirements ,design specifications,test plans are performance criteria.
 There are no universely accepted notation in software Engineering.
 Appropriate notations provide vehicles of communication among project
personnel.
 It introduces the possibility of using automated software tools to
manipulate the notations and verify proper usage.
11

Systamatic Approaches:
  In every field there are certain accepted procedures and techniques
 A Single approach to software development and maintenance will not be
adequate to cover all situations.
 In the evaluation of software engineering it is not clear which of the
various approaches to software development should be used in which
situation.

Change Control:
 The flexibility of software is a great strength and also a great source of
difficulty in software engineering.
 Requirements can also change due to poor understanding of the problem
are external economic and political factors beyond the control of the
customers or developers.
 Notations and procedures provide the ability to trace and access the
impact of proposed changes are necessary to make visible the true cost of
apparently small changes to source code.
 Use of appropriate notations and techniques makes control change
possible without degrading the quality of work products.
 Planning for software project must include plans for change control.

Level of Technology:
It include factors such as programming language.
Machine Environment
The Programming Practices. Software tools
Modern Programming languages provide improved facilities for data definition and data
usage.
Improve Constructs for specifying control flow,better modularization facilities, user defined
exception Handling and facilities for concurrent programming.
The machine environment includes a set of hardware and software facilities for developing,
using and maintaining a software product.
Modern programming practices include use of systematic Analysis and design
techniques,notations,structure coding,systematic techniques for designing and documenting
and testing.

Level of Reliability:
Every software product must possess basic level of reliability.
Extreme reliability is gained only with great care in analysis,design,design
implementation,system testing and maintenance of software product.
Both human and machine resources are required to obtained increased
reliability.
12
Problem Understanding:
 Failures to understand the true nature of the problem to be solved is a
common and difficult issue.
  Often the customer does not truly understand nature of the problem.
 Often the software engineering does not understand the application
area and has trouble communicating with the customer because of
differences in educational backgrounds view the points and
technology.
 Careful planning customer interviews,task observations and
prototyping, a preliminary version of the user’s manual and precise
product specification can increase both customer and developer
understanding of the problem to be solved.
Available Time:
A software project requiring 6 programmer-months of effort can be completed by 1
programmer in 6 months or by 6 programmers in 1 month.
Software projects are sensitive not only to total effort but also to ellapse time and the no.of
people involved.
Utilising 6 programmers for 1 month will be less effective than using 1 programmer for 6
months.
This is because the learning curve for 6 programmers on an 1 month schedule will occupy a
large percentage of the elapsed time and because the effort required for co-ordination and
communication among 6 programmers.
Programmer Productivity is also sensitive to the calendar time available for project
completion.
Determining optimum staff in levels and proper elapsed times for various activities in
software product development is an important and difficult aspects of cost and resource
estimation.

Required Skill:
o Software Engineering requires a vast range of skills.
o Good Communications
o Knowledge of application area
o Requirement definition and design
o Problem solving skills
o Implementation of software (i.e)Good programming knowledge,no syntax
error
o Debugging and test plans
o Inter personnel communication skill.

Facilities and Resources:

 Work related factors such as
 Good machine access and quiet place to work are more important.
 Software project managers must be effective in dealing with the
factors that motivate the programmers to maintain high product 13
quality,high programmer productivity and high job satisfaction.

Adequacy of Training:
  Express oneself clearly in English
 Develop and Validate software requirements and design specifications.
 Work within application area
 Perform software maintenance
 Perform economic analysis.
 Work with project management techniques
 Work in groups
Management Skills:
o Many of the problems in software project management are unique.
o Managers experienced in management of computer hardware projects find software
project management to be difficult.
o This is due to the differences in design methods,notations and development tools.
o Many Organisations offer project management training to software engineers to prepare
them for project management task.
Appropriate Goals:
Primary Goal of software engineering is to development of software products for their intended use.
Every software product must provide optimal level of

1. Generality 2.Reliability 3.Efficiency

Raising Expectations:
There are two interrelated aspects of raising expectations
1. How much functionality,reliability and performance can be provided by a given amount of
development effort.
2. Issues of fundamental limitations of software technology.

Managerial Issues:

 Success of Software project involves

Technical Activities Managerial Activities

 Managers Control
1. Resources 2.Environment
 Important managers responsibility
Software product delivered on time
Software working according to customer’s wish Software within cost estimates
Other managerial responsibility:
Business Plans Recruiting customers
Developing Marketing Strategies Recruiting and training employees

Important Problems:
 Planning is poor
14
  Selection for project managers are poor (i.e) Procedures and Techniques
 Description of project is poor
 Estimation of resources for software project is poor
 Success criteria is inappropriate
 Decisions rules are poor(for selecting the proper organizational structure,correct
management techniques )
 Procedures ,methods and techniques are not readily available.

Methods for solving these peoblems:

 Educate and Train
Top management Project
Software developers
 Analyze the data from previous software project to find effective methods
 Define objectives,quality
 Establish success priority criteria
 Develop accurate cost and schedult that are accepted by management and
customer
 Selection of project managers
 Specific work assignments to software developers
Planning a software product:
 Goals can be formulated using concise statement,constraints.
 Goal apply to both development process and work product.
 It can be either qualitative or quantitative.
 Every development process
 Should provide product on time.
 Within cost estimates .
 Opportunities for project personnel to learn new skill.

Requirements includes:
 Functional requirements
 Performance
 Requirements for hardware,software and firmware.

Qualified requirements
 Response to external interrupts shall we 25 second maximum
 50KB of primary memory.
 Full operation 95% of each 24 hour period.

Quanlitative requirements
 Accuracy
 Efficient use of primary memory.
 95% relaiable
15
planning the development process:
1. software life cycle activities
2. define
3. develop
4. test
5. deliver
6. operate
7. maintain.

 lifecycle activities are given above. These activities are change

 no single life cycle models is used.
 Different models are used for various software product.
 A life cycle model that is understood and accepted by all concerned parties improves
project communications and project manageability , resource allocations, cost control
and product quality.

The phased lifecycle model:

 Series of successive activities.
 Requires well defined input, process and results in well defined output.
 Resources is required to complete each phase.
 Application of explicit methods, tools and techniques.

Analysis consist of two sub phases

 Planning
 Requirements definition.

This phase includes

 Understanding the customer problem.
 Performing a feasibility study.
 Developing solution stragedy
 Acceptance criteria
 Planning the development process.

The products of planning are

 System definitions.
 Project plan.

System definitions:
 Expressed in English or some other language.
 It includes charts, figures, graphs, tables, and equations.

16
Project plan:

 Contains lifecycle model to be used.

 Organitational structure.
 Basic development schedule, resource estimate, staffing requirements, tools and techniques to
be used.
 Time and cost are basically calculated because it is not possible to estimate exactly without
doing basic design.
Requirements definitions:
 It includes basic functions of software components in hardware, software, and people
subsystem.

The product of requirements definition:

 The product of requirements definition is a specification that describes
 The processing environment
 The required software functions.
 Performance constraints on the software.
 Exception handling
 Acceptance criteria.

Design phase:
 In the phased model, software design follows analysis
 Design phase identified software components
1. Functions.
2. Data streams
3. Data stores
 It specifies relationship among components.
 It specifies software structures.
 Maintaines a record of design decision.
 Blueprint for the implementation phase.
 Design phase consist of
1. Architectural design
2. Detailed design
Architectural design:
It involves identifying the software components dividing them into software modules and conceptual
data structures, specifying interconnection among components.

Detailed design
It is concerned with the details of “how to”
 Package the processing modules.
 Implement the processing, algorithm, data structures and interconnection among modules.
17
Implemention phase:
It involves translation of design specification into source code and debugging, documentation and unit
testing of source code.

SOFTWARE PROCESS
 Software process means methods of developing software.
 A software process is a set of activities, together with ordering among them, such that if
the activities are performed properly, the desired result is produced.
Generic View /Phases of Software Engineering
The work associated with software engineering can be categorized into three generic phases.

Definition Phase
 The definition phase focuses on “what”.
 During definition, the software engineer identify what information is to be processed,
what function and performance are desired, what system behavior can be expected, what
interfaces are to be established, what design constraints exist, and what validation
criteria are required to define a successful system.

Development Phase
 The development phase focuses on “how”.
 During development a software engineer define how data are to be structured, how
function is to be implemented, how interfaces are to be characterized, how the design
will be translated into a programming language, and how testing will be performed.

18
Support Phase
 The support phase focuses on “change” associated with error correction.
 Four types of change are associated with support phase:
Correction: Corrective maintenance changes the software to correct defects.
Adaptation: Adaptive maintenance results in modification to the software to
accommodate changes to its external environment.
Enhancement/Perfection: Perfective maintenance extends the software beyond its
original functional requirements.
Prevention: Computer software deteriorates due to change, and because of this,
preventive maintenance, often called software reengineering and must be conducted
to enable the software to serve the needs of its end users.
Generic Framework Activities
 In software engineering an effective process model should define a small set of
frameworkactivities that are always applicable regardless of project type.
 There are five process framework activities:
Communication: This activity involves communication with customers
and otherstakeholders in order to gather requirements and other
related activities.
Planning: it requires defining resources, timelines and other project related
information anddescribe technical and management risks.
Modeling: A model will be created to better understand the requirements and
design toachieve these requirements.
Construction: Here the code will be generated and tested.
Deployment: Here, a complete or partially complete version of the software is
representedto the customers to evaluate and they give feedbacks based on the
evaluation.
 These above described five activities can be used in any kind of software development.
 Each framework activity populated by number of task set that identifies work task that
are tobe completed, milestones that will be used to indicate progress,

deliverables that will be produced and quality assurance points that will be required
to get quality product at eachstage.

19
 Umbrella Activities
 Umbrella activities are independent of anyone framework activity.
 Typical activities in this category include:
Project tracking and control: allows the team to track progress against the project
plan andtake necessary action to maintain schedule.

Risk Management: Identify the risks that may affect the outcome of the project
or thequality.
Software quality assurance: It defines and conducts the activities to ensure the
softwarequality.
Formal Technical Review: It is necessary to uncover or remove errors before they
arepropagated to the next action or activity.
Software configuration management: Manages the effect of change throughout
theSoftware process
Reusability management: It defines criteria for work product reuse and establishes
mechanism to achieve reusable components.
Work product preparation and production: It create work products such as
models,documents, etc.
Measurement: defines and collects process, project, and product measures that
assist theteam in delivering Software that meets customers’ needs.

CMMI (The Capability Maturity Model Integration):

The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set
of software engineering capabilities that should be present as organizations reach different levels of process
maturity.

CMMI are used in two ways,

(i) Continuous model and

(ii) Staged model.

CMMI Continuous model

In the case of a continuous model each process area is rated according to the following capability
levels.

CMMI Staged model

The staged CMMI model defines the same process areas, goals and practices as the continuous
model. The primary difference is that the staged model defines five maturity levels rather than five
capability levels.

20
 Maturity levels consist of a predefined set of process areas. The maturity levels are measured by the
achievement of the specific and generic goals that apply to each predefined set of process areas.

1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing

CMMI Staged Representation- Maturity Levels

Level 1: Initial

Adhoc activities characterize a software development organization at this level. Very few or no
processes are described and followed. Since software production processes are not limited, different
engineers follow their process and as a result, development efforts become chaotic. Therefore, it is also
called a chaotic level.

Level 2: Repeatable

At this level, the fundamental project management practices like tracking cost and schedule are
established. Size and cost estimation methods, like function point analysis, COCOMO, etc. are used.

Level 3: Defined

At this level, the methods for both management and development activities are defined and
documented. There is a common organization-wide understanding of operations, roles, and responsibilities.
21
The ways through defined, the process and product qualities are not measured. ISO 9000 goals at achieving
this level.

Level 4: Managed

At this level, the focus is on software metrics. Two kinds of metrics are composed.

Product metrics measure the features of the product being developed, such as its size, reliability, time
complexity, understandability, etc.

Process metrics follow the effectiveness of the process being used, such as average defect correction time,
productivity, the average number of defects found per hour inspection, the average number of failures
detected during testing per LOC, etc.

The software process and product quality are measured, and quantitative quality requirements for the
product are met. Various tools like Pareto charts, fishbone diagrams, etc. are used to measure the product
and process quality.

The process metrics are used to analyze if a project performed satisfactorily. Thus, the outcome of
process measurements is used to calculate project performance rather than improve the process.

Level 5: Optimizing

At this phase, process and product metrics are collected. Process and product measurement data are
evaluated for continuous process improvement.

Key Process Areas (KPA) of a software organization

Except for SEI CMM level 1, each maturity level is featured by several Key Process Areas (KPAs)
that contains the areas an organization should focus on improving its software process to the next level. The
focus of each level and the corresponding key process areas are shown in the fig.

22
 SEI CMM provides a series of key areas on which to focus to take an organization from one level of
maturity to the next. Thus, it provides a method for gradual quality improvement over various stages.

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) MODELS

 A Software Development Life Cycle Model (also called process model) is a
descriptive and diagrammaticrepresentation of the software life cycle.
 A life cycle model represents all the activities required to make a software product
transit through its life cycle phases.
 A 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.

SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes
the following steps:

Stage 1: Planning and requirement analysis

 Requirement Analysis is the most important and necessary stage in SDLC.
 The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.
 Planning for the quality assurance requirements and identifications of the risks associated with
the projects is also done at this stage.
 Business analyst and Project organizer set up a meeting with the client to gather all the data
like what the customer wants to build, who will be the end user, what is the objective of the
product.

 Before creating a product, a core understanding or knowledge of the product is very necessary.

 For Example, A client wants to have an application which concerns money transactions. In this

23
 method, the requirement has to be precise like what kind of operations will be done, how it
will be done, in which currency it will be done, etc.

 Once the required function is done, an analysis is complete with auditing the feasibility of the
growth of a product. In case of any ambiguity, a signal is set up for further discussion.

 Once the requirement is understood, the SRS (Software Requirement Specification) document
is created. The developers should thoroughly follow this document and also should be
reviewed by the customer for future reference.

Stage 2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and document the
software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

contains all the product requirements to be constructed and developed during the project life cycle.

Stage 3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and design of
the software project.

This phase is the product of the last two, like inputs from the customer and requirement gathering.

Stage 4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built.

The implementation of design begins concerning writing code. Developers have to follow the
coding guidelines described by their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and implement the code.

Stage 5: Testing

After the code is generated, it is tested against the requirements to make sure that the products are
solving the needs addressed and gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance testing are done.

Stage 6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed. Then based on
the assessment, the software may be released as it is or with suggested enhancement in the object
segment.

24
 After the software is deployed, then its maintenance begins.

Stage 7: Maintenance

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time. This procedure where the care is taken for the
developed product is known as maintenance.

Software Development Life Cycle (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.

I. Classical Waterfall Model

 The waterfall model is the classic model or oldest model and is known as mother of all the models.
 It is widely used in government projects and many vital projects in company.
 The waterfall model is also called as 'Linear sequential model' or 'Classic life cycle model'.
 In this model, each phase is executed completely before the beginning of the next phase. Hence the
phases do not overlap in waterfall model.
 This model is used for small projects.
 In this model, feedback is taken after each phase to ensure that the project is on the right path.
 Testing part starts only after the development is completed.
 The stages in this model are as follows,
1. Feasibility study

 The main aim of feasibility study is to determine whether it would be financially and
technically feasible to develop the product.
 At first project managers or team leaders study different input data to the system and
output data to be produced by the system.
 The feasibility study concentrates on the following area.

 Operational Feasibility: Operational feasibility study tests the operational scope of the
software to be developed. The proposed software must have high operational feasibility.
The usability will be high.

 Technical Feasibility: The technical feasibility study compares the level of technology

25
 available in the software development area and the level of technology required for the
development of the product. Here the level of technology consists of the programming
language, the hardware resources, other software tools etc.

 Economic Feasibility: The economic feasibility study evaluates the cost of the software
development against the income or benefits gets from the developed system. There must be
scopes for profit after the successful Completion of the project.
Feasibility study

Requirement analysis
and specification

Design

Coding and unit

testing

Integration and
system testing

Maintenance

2. Requirements analysis and specification

 The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of two distinct
activities, namely
Requirements gathering and analysis, and
Requirements specification
 Requirements gathering: The goal of the requirements gathering activity is to collect all
relevant information from the customer regarding the product to be developed. This is done to
clearly understand the customer requirements so that incompleteness and inconsistencies are
removed.
 Requirements analysis: This activity is begun by collecting all relevant data regarding the
product to be developed from the users of the product and from the customer through interviews
and discussions.
 Requirements specification: The aim of this phase is to understand the exact requirements of

26
 the customer and to document them properly. Both the customer and the software developer
work together so as to document all the functions, performance, and interfacing requirement of
the software. It describes the "what" of the system to be produced and not "how." Then the user
requirements are systematically organized into a Software Requirements Specification (SRS)
document.
3. Design
 During the design phase the software architecture is derived from the SRS document. Two
distinctly different approaches are available.
 Traditional design consists of two different activities; first a structured analysis of the
requirements specification is carried out where the detailed structure of the problem is examined.
During structured design, the results of structured analysis are transformed into the software
design.

4. Coding and unit testing (Implementation)

 The purpose of the coding and unit testing phase of software development is to translate the
software design into source code.
 Each component of the design is implemented as a program module. The end-product of this
phase is a set of program modules that have been individually tested.
 Each module is unit tested for determine the correct working of all the individual modules.

5. Integration and system testing

 Integration of different modules is done once they have been coded and unit tested. During the
integration and system testing phase, the modules are integrated.
 Finally, when all the modules have been successfully integrated and tested, system testing is
carried out. The goal of system testing is to ensure that the developed system conforms to its
requirements specifies in the SRS document.
 System testing usually consists of three different kinds of testing activities.
 α – testing: It is the system testing performed by the development team.
 β – Testing: It is the system testing performed by a friendly set of customers.
 Acceptance testing: It is the system testing performed by the customer himself after theproduct
delivery to determine whether to accept or reject the delivered product.

6. Maintenance
 Maintenance involves performing any one or more of the following three kinds of activities:
 Correcting errors that were not discovered during the product development phase. This is called
corrective maintenance.
 Improving and enhancing the functionalities of the system according to the customer’s
requirements. This is called perfective maintenance.
 Porting the software to work in a new environment. For example, porting may be required to get
27
 the software to work on a new computer platform or with a new operating system. This is called
adaptive maintenance.

Advantages of Waterfall model

 The waterfall model is simple and easy to understand, to implement, and use.
 All the requirements are known at the beginning of the project, hence it is easy to manage.
 It avoids overlapping of phases because each phase is completed at once.
 This model works for small projects where the requirements are easily understood.

Disadvantages of the Waterfall model

 This model is not good for complex and object oriented projects.
 In this model, the changes are not permitted so it is not fit for moderate to high risk changes in project.
 It is a poor model for long duration projects.
 The problems with this model are uncovered, until the software testing.
 The amount of risk is high.

II. Prototype Model

 A prototype is the sample implementation of the real system.
 A prototype is a toy implementation of the system.
 A prototype includes limited functional capabilities, low reliability, and inefficient performance
compared to the actual software.
 Prototype is defined as first or preliminary form using which other forms are copied or derived.
 Prototype model is a set of general objectives for software.
 It does not identify the requirements like detailed input, output.
 It is software working model of limited functionality.
 In this model, working programs are quickly produced.

The different phases of Prototyping model are:

1) Communication
2) Quick design
3) Modeling and quick design
4) Construction of prototype
5) Deployment, delivery, feedback

28
 1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the software.

2. Quick design
 Quick design is implemented when requirements are known.
 It includes only the important aspects i.e input and output format of the software.
 It focuses on those aspects which are visible to the user rather than the detailed plan.
 It helps to construct a prototype.
3. Modeling quick design
 This phase gives the clear idea about the development of software as the software is now constructed.
 It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.
5. Deployment, delivery, feedback
 If the user is not satisfied with current prototype then it is refined according to the requirements of the user.
 The process of refining the prototype is repeated till all the requirements of users are met.
 When the users are satisfied with the developed prototype then the system is developed on the basis of final
prototype.
Advantages of Prototyping Model
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system by the user.
 Earlier error detection takes place in this model.
 It gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the confusing or difficult functions.
Disadvantages of Prototyping Model
29
 The client involvement is more and it is not always considered by the developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a throw away prototype when the users are confused with it.

III. RAD Model

 RAD is a Rapid Application Development model.

 Using the RAD model, software product is developed in a short period of time (e.g. 60 to 90 days).

 The initial activity starts with the communication between customer and developer.
 Planning depends upon the initial requirements and then the requirements are divided into groups.
 Planning is more important to work together on different modules.
Phases of RAD Model
1) Business Modeling
2) Data modeling
3) Process modeling
4) Application generation
5) Testing and turnover

1) Business Modeling

 Business modeling consists of the flow of information between various functions in the project.
For example, what type of information is produced by every function and which are the functions to
30
 handle that information.
 It is necessary to perform complete business analysis to get the essential business information.
2) Data modeling

 The information in the business modeling phase is refined into the set of objects and it is essential for the
business.
 The attributes of each object are identified and defined the relationship between objects.
3) Process modeling

 The data objects defined in the data modeling phase are changed to fulfill the information flow to implement
the business model.
 The process description is created for adding, modifying, deleting or retrieving a data object.
4) Application generation

 In the application generation phase, the actual system is built.

 To construct the software the automated tools are used.
5) Testing and turnover

 The prototypes are independently tested after each iteration so that the overall testing time is reduced.
 The data flow and the interfaces between all the components are fully tested. Hence, most of the
programming components are already tested.
Advantages of RAD Model

 The process of application development and delivery are fast.

 This model is flexible, if any changes are required.
 Reviews are taken from the clients at the staring of the development hence there are lesser chances to
miss the requirements.
Disadvantages of RAD Model

 The feedback from the user is required at every development phase.

 This model is not a good choice for long term and large projects.

IV. Evolutionary Model

 In the evolutionary life cycle model the software requirement is first broken down into several
modules (functional units) that can be constructed and delivered.

31
 Rough requirement specification

Identify the core and other parts to be

developed incrementally

Develop the core part using an iterative

waterfall model
Collect customer feedback and modify
requirement All features complete

Develop the next identified features using an

iterative waterfall model

Maintenance
 The development team first develops the core modules of the system.
 The core modules are those that do not need services from core modules.
 Non-core modules need services from the core modules.
 This initial product is refined into increasing levels of capability by adding new functionalities
insuccessive version.
 Each evolutionary version may be developed using an iterative waterfall model of
development.
 Each successive version of the product is fully functioning software capable of performing more
work than the previous version.

1. Incremental Model

 The incremental model combines the elements of waterfall model and they are applied in an iterative fashion.
 The first increment in this model is generally a core product.
 Each increment builds the product and submits it to the customer for suggesting any modifications.
 The next increment implements the customer's suggestions and add additional requirements in the previous
increment.
 This process is repeated until the product is completed.
For example, the word-processing software is developed using the incremental model.

32
Following are the phases of Incremental model:

i) Communication - The software development starts with the communication between customer and developer.

ii) Planning - It consists of complete estimation, scheduling for project development.

iii) Modeling - Modeling consists of complete requirement analysis and the design of the project like algorithm,
flowchart etc.
The algorithm is a step-by-step solution of the problem and the flow chart shows a complete flow diagram of a
program.
iv) Construction- Construction consists of code generation and the testing part. Coding part implements the design
details using an appropriate programming language.
Testing is to check whether the flow of coding is correct or not. Testing also checks that the program provides
desired output.
v) Deployment -Deployment step consists of delivering the product to the customer and taking feedback from them.
If the customer wants some corrections or demands for the additional capabilities, then the change is required for
improvement in the quality of the software.

Advantages of Incremental model

 This model is flexible because the cost of development is low and initial product delivery is faster.
 It is easier to test and debug in the smaller iteration.
33
  The working software is generated quickly in the software life cycle.
 The customers can respond to its functionalities after every increment.

Disadvantages of the incremental model

 The cost of the final product may cross the cost initially estimated.
 This model requires a very clear and complete planning.
 The planning of design is required before the whole system is broken into smaller increments.
 The demands of customer for the additional functionalities after every increment causes problem in the
system architecture.

2. Spiral model

 It is a combination of prototype and sequential or waterfall model.

 This model was developed by Boehm.
 It is used for generating the software projects. This model is a risk driven process model.
 Every phase in the Spiral model is start with a design goal and ends with the client review.
 The development team in this model begins with a small set of requirements and for the set of
requirements team goes through each development phase.
 The development team adds the functionality in every spiral till the application is ready.
Following are the steps involved in spiral model

Phases of Spiral model

1) Planning
2) Risk Analysis
3) Engineering
4) Evaluation
34
1) Planning

 This phase studies and collects the requirements for continuous communication between the customer and
system analyst.
 It involves estimating the cost and resources for the iteration.
2) Risk Analysis
This phase, identifies the risk and provides the alternate solutions if the risk is found.

3) Engineering
In this phase, actual development i.e coding of the software is completed. Testing is completed at the end of
the phase.

4) Evaluation
Get the software evaluated by the customers. They provide the feedback before the project continues to the next
spiral.

Advantages of Spiral Model

 It reduces high amount of risk.

 It is good for large and critical projects.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.

Disadvantages of Spiral Model

 It can be costly to develop a software model.

 It is not used for small projects.

35
3. WIN-WIN Spiral Model
The spiral model suggests a framework activity that addresses customer communication. The objective of this
activity is to elicit project requirements from the customer. In an ideal context, the developer simply asks the
customer what is required and the customer provides sufficient detail to proceed. In reality, the customer and the
developer enter into a process of negotiation, where the customer may be asked to balance functionality,
performance, and other product or system characteristics against cost and time to market.

The best negotiations strive for a “win-win” result. That is, the customer wins by getting the system or product
that satisfies the majority of the customer’s needs and the developer wins by working to realistic and achievable
budgets and deadlines.

Boehm’s WIN-WIN spiral model defines a set of negotiation activities at the beginning of each pass around
the spiral. Rather than a single customer communication activity, the following activities are defined:

1. Identification of the system or subsystem’s key “stakeholders.”

2. Determination of the stakeholders’ “win conditions.”

3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all
concerned (including the software project team).

Successful completion of these initial steps achieves a win-win result, which becomes the key criterion for
proceeding to software and system definition. The WIN-WIN spiral model is illustrated in Figure 2.9.

WINWIN spiral model introduces three process milestones, called anchor points that help establish the
completion of one cycle around the spiral and provide decision milestones before the software project proceeds.

36
 Three anchor points are available that can be defined in the WIN-WIN spiral model that
are given below:

Concurrent Development Model

 The concurrent development model is called as concurrent model.
 Concurrent Process model is an evolutionary process model in software engineering. The term
concurrent mean “done at the same time”.
 The communication activity has completed in the first iteration and exits in the awaiting
changes state.
 The modeling activity completed its initial communication and then go to the
underdevelopment state.
 If the customer specifies the change in the requirement, then the modeling activity moves from
the under development state into the awaiting change state.
 The concurrent process model activities moving from one state to another state.
 The concurrent process model shows the current state of activities, tasks and their associated
states that remain in different phases.

 Design Phase’ may be at an ‘awaiting state’ and ‘customer communication’ is in ‘under

revision’ state.

 The customer wants some changes to the design, then ‘communication’ goes to ‘awaiting
changes’ and ‘design’ goes to the under-development stage again.

 The benefit of this model is that project managers know each phase is what state and why.
37
 It maintains information about each phase at the activity level..
Advantages of the concurrent development model
 This model is applicable to all types of software development processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.
 Disadvantages of the concurrent development model
 It needs better communication between the team members. This may not be achieved all the
time.
 It requires to remember the status of the different activities

Agile Model
The meaning of Agile is swift or versatile."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.

Phases of Agile Model:

Following are the phases in the Agile model are as follows: 38

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:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

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: 39

o Scrum Master: The scrum can set up the master team, arrange the meeting and
remove obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the delay
and is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the
sprint or cycle.
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.

Crystal:

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development
team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
Wrap up: According to the user environment, this phase performs deployment, post-
deployment.

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

Feature Driven Development (FDD):

40
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.

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?

o When frequent changes are required.

o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages(Cons) of Agile Model:

1. 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.
2. 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.

Problem Definition

After gathering requirements and analyzing them, problem statement must be stated
clearly. Problem definition should unambiguously state what problem or problems need to 41
be solved. Having a clear problem statement is necessary to −

 Define project scope

 Keep the team focused
 Keep the project on track
 Validate that desired outcome was achieved at the end of project
Developing a Solution Strategy:

A good system design is to organize the program modules in such a way that are easy to
develop and change. Structured design techniques help developers to deal with the size and
complexity of programs. Analysts create instructions for the developers about how code
should be written and how pieces of code should fit together to form a program.

Software Engineering is the process of designing, building, testing, and maintaining

software. The goal of software engineering is to create software that is reliable, efficient, and
easy to maintain. System design is a critical component of software engineering and
involves making decisions about the architecture, components, modules, interfaces, and
data for a software system.

System Design Strategy refers to the approach that is taken to design a software system.
There are several strategies that can be used to design software systems, including the
following:

1. Top-Down Design: This strategy starts with a high-level view of the system and
gradually breaks it down into smaller, more manageable components.

2. Bottom-Up Design: This strategy starts with individual components and builds the
system up, piece by piece.

3. Iterative Design: This strategy involves designing and implementing the system in
stages, with each stage building on the results of the previous stage.

4. Incremental Design: This strategy involves designing and implementing a small part
of the system at a time, adding more functionality with each iteration.

5. Agile Design: This strategy involves a flexible, iterative approach to design, where
requirements and design evolve through collaboration between self-organizing and
cross-functional teams.

The design of a system is essentially a blueprint or a plan for a solution for the system. The
design process for software systems often has two levels. At the first level the focus is on
deciding which modules are needed for the system, the specifications of these modules and
how the modules should be interconnected. The design of a system is correct if a system
built precisely according to the design satisfies the requirements of that system. The goal of
the design process is not simply to produce a design for the system. Instead, the goal is to
find the best possible design within the limitations imposed by the requirements and the 42
physical and social environment in which the system will operate.

The choice of system design strategy will depend on the particular requirements of the
software system, the size and complexity of the system, and the development methodology
being used. A well-designed system can simplify the development process, improve the
quality of the software, and make the software easier to maintain.
Importance of System Design Strategy:

1. If any pre-existing code needs to be understood, organized, and pieced together.

2. It is common for the project team to have to write some code and produce original
programs that support the application logic of the system.

There are many strategies or techniques for performing system design. They are:

Bottom-up approach:

The design starts with the lowest level components and subsystems. By using these
components, the next immediate higher-level components and subsystems are created or
composed. The process is continued till all the components and subsystems are composed
into a single component, which is considered as the complete system. The amount of
abstraction grows high as the design moves to more high levels.

By using the basic information existing system, when a new system needs to be created, the
bottom-up strategy suits the purpose.

Bottom-up approach

Advantages of Bottom-up approach:

 The economics can result when general solutions can be reused.

 It can be used to hide the low-level details of implementation and be merged with
the top-down technique.
43
Disadvantages of Bottom-up approach:

 It is not so closely related to the structure of the problem.

 High-quality bottom-up solutions are very hard to construct.

  It leads to the proliferation of ‘potentially useful’ functions rather than the most
appropriate ones.

Top-down approach:

Each system is divided into several subsystems and components. Each of the subsystems is
further divided into a set of subsystems and components. This process of division facilitates
forming a system hierarchy structure. The complete software system is considered a single
entity and in relation to the characteristics, the system is split into sub-systems and
components. The same is done with each of the sub-systems.

This process is continued until the lowest level of the system is reached. The design is
started initially by defining the system as a whole and then keeps on adding definitions of
the subsystems and components. When all the definitions are combined, it turns out to be a
complete system.

For the solutions of the software that need to be developed from the ground level, a top-
down design best suits the purpose.

Top-down approach

Advantages of Top-down approach:

 The main advantage of the top-down approach is that its strong focus on
requirements helps to make a design responsive according to its requirements. 44

Disadvantages of Top-down approach:

 Project and system boundaries tend to be application specification-oriented. Thus, it

is more likely that the advantages of component reuse will be missed.
  The system is likely to miss, the benefits of a well-structured, simple architecture.

 Hybrid Design:
It is a combination of both top-down and bottom-up design strategies. In this, we
can reuse the modules.

Advantages of using a System Design Strategy:

1. Improved quality: A well-designed system can improve the overall quality of the
software, as it provides a clear and organized structure for the software.

2. Ease of maintenance: A well-designed system can make it easier to maintain and

update the software, as the design provides a clear and organized structure for the
software.

3. Improved efficiency: A well-designed system can make the software more efficient, as
it provides a clear and organized structure for the software that reduces the
complexity of the code.

4. Better communication: A well-designed system can improve communication between

stakeholders, as it provides a clear and organized structure for the software that
makes it easier for stakeholders to understand and agree on the design of the
software.

5. Faster development: A well-designed system can speed up the development process,

as it provides a clear and organized structure for the software that makes it easier for
developers to understand the requirements and implement the software.

Disadvantages of using a System Design Strategy:

1. Time-consuming: Designing a system can be time-consuming, especially for large

and complex systems, as it requires a significant amount of documentation and
analysis.

2. Inflexibility: Once a system has been designed, it can be difficult to make changes to
the design, as the process is often highly structured and documentation-intensive.

Planning the Development process:

The software development process is nothing but the process of developing software. This 45
process might include improving design and product management by splitting the work
into smaller steps or processes.

Software is nothing but a set of programs having specific functions that are designed to
work according to human needs. The Software Development Process includes different
steps in an organized way to form a software product. In this article, we are going to learn
about Software Development Process, their needs, the purpose of the software
development process, steps of the software development process, approaches of Software
Development, and types of software development process.

Planning an Organization Structure –Other Planning Activities:

Planning an organizational structure:

 Contains various task

 The task include

1. Planning
2. Product development
3. Services
4. Publications
5. Quality assurance
6. Support and maintenance

Planning task identifiers:

 External customers
 Internal product needs
 Conducts feasibility study.

Development Task Identifiers:

 design
 implements
 debugs
 test and integrate the product

service task provides:

 Automated tools and computer resources for all other task.

 Performs configuration.
 Product distribution
46
Publication task develops:

 Users manual
 Initialization instruction
 Principles of operation
 Supporting documents
Quality assurance task provides:

 Independent evaluation of source code.

 Publications prior to releasing them to customer.

Support task:

 Promotes the product.

 Trainers user.
 Installs the product.

Maintenance task provides:

 Error connection
 Enhancement

Methods for organizing these task include:

1. Project format
2. Functional format
3. Matrix format

Project structures Project format

 It involves assuming a team of programmers.

 Project team members do

1. Product definition
2. Design the product
3. Implement it
4. Test it
5. Conducts Project review
6. Preparing supporting document.

Functional format:

 In this approach a different team of programmers perform each phase of the

Project
 The work products pass from team to team as they evolved
 Functional format involves 3 teams 47

1. An analysis team.
2. A design team and implementation team.
3. test formatting and maintenance team.

Matrix format
  In this format eac of the functions has its own management team.
 This format involves a group of specialist personnel concerned only with that
function.
 Each development project has a project manager concerned only with that
Project
 The Project manager generates and reviews documents.
 Each functional group participate in each Project
 Ex: software development team members belongs to the development
function similarly testing belong the testing function.

Programming team structure:

 Every programming team must have an internal structure.

 Team structure depends on the nature of the Project and the product
 Basic team structure includes
 Demacratic team
 All team members participate in all decisions.

The chief programmer team:

 chief programmer is assited and supported by other team members.

 Ex: doctors, surgeon

Hierarchical team:

 In combines the aspects of the democratic team and chief programmer team.
 Each team should be limited to not more than 5 or 17 members for effective
coordination and communication.

Democratic team

 this teams was first described as egoless team.

 Group leadership rotates from member to member based on the task to be
performed and the differing abilities of the team members.
 A Democratic team differs from an egoless team is that one team members is
designsted as team leader and occupies the position of first among equals.
 This is because a team fuctions best when one individual is responsible for
coordinationg team activities and for making final decision.

Advantages: 48

 Opptunities for each team members to contribute to decision.

 To learn from one another
 Increased job satisfaction
 Non threatening work environment.
Disadvantages:

 Weeknening of individual and authority.

Chief programmer teams:

 this teams are highly structured.

 the chief programmer
 design the product.
 Implement critical parts of the product
 Makes all the major technical decision.
 Work is allocated to the individual programmer by the chief programmers.
 A program librarian maintains program listing, design documents, test plans etc in
a central location.
 The chief programmer is assited by an administrative program manager.

Advantages:

 Centralized decision making.

 Reduced communication paths.

Hierarchical team structure:

 This structure occupies a middle position between the extremes of Democratic

teams and chief programmer teams.
 The Project needed assigns, task, attends, reviews,detects problem areas, balances
the word load the participate in technical activities.
 This structure limits the number of communication paths in the Project

Disadvantages:

 The most technical competetant programmer tend to be promoted in to

management positions.
 Promotion of the best programmer have the two negative effects.
 Losing a good programmer.
 Creating a poor manager.

Other planning activities: 49

 Planning for configuration management and quality assurance.

Configuration management:

 Modeof arrangement
 Concerned witj controlling changes in the work products.
  Accounting for the status of the work products
 Mainteaning the program support library

Quality assurance:

Develops and monitors the Project standars.

 Performs audits.
 Develop and perfoms acceptance test.

During planning phase:

 The two activities are specified.

 Tools are identified an acquired.

During design phase:

 Requriments and design specification are performed.

 Adherence to project standard is monitor.

During implementation phase:

 Requirements, design specification and source code are perfomed .

During testing phase:

 Acceptance and preparation of test results are performed.

Planning for independent verification and validation:

 An independent organization may provide verification of work products for some

critical software Project
 Veification makes sure that various work products are complete and consistence.
 An external organization may verify that the design specification are complete and
cosistance.
 Source code is complete.
 Validation involves.
 Planning and execution of text cases.
 Independent verification and validation results in high quality software product.
50
Planning phase-dependent tools and technique:

 Automated tools,specialized notation and modern techniques are used to develop

software requriments specification, architectural and detailed design and the source
code.
 Management tools such as structures, charts, are used to track and control
progress.
Other planning activities:

 It includes:

1. primilinary cost estimate.

2. primilinary development schedule
3. primilinary staffing levels.
4. primilinary estimates of the computing resources and personnel require to operate
and maintain the system.

51
 UNIT-II

Software Project Management

 Software project management is an art and discipline of planning and supervising
softwareprojects.
 It is a sub-discipline of software project management in which software projects
planned,implemented, monitored and controlled.
 It is a procedure of managing, allocating and timing resources to develop computer
softwarethat fulfills requirements.
 In software Project Management, the client and the developers need to know the length,
periodand cost of the project.

Three needs for software project management

1. Time
2. Cost
3. Quality

It is an essential part of the software organization to deliver a quality product, keeping the
costwithin the client’s budget and deliver the project as per schedule.

Project Manager

 A project manager is a character who has the overall responsibility for the planning,
design,execution, monitoring, controlling and closure of a project.
 A project manager represents an essential role in the achievement of the projects.
 A project manager is a character who is responsible for giving decisions, both large and
smallprojects.
 The project manager is used to manage the risk and minimize uncertainty. Every decision
theproject manager makes must directly profit their project.

Role of a Project Manager

1. Leader

A project manager must lead his team and should provide them direction to make them
understand what is expected from all of them.

2. Medium

The Project manager is a medium between his clients and his team. He must coordinate and
transfer all the appropriate information from the clients to his team and report to the senior
management.

3. Mentor

He should be there to guide his team at each step and make sure that the team has an
attachment. He provides a recommendation to his team and points them in the right direction.

1
 Responsibilities of a Project Manager
1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.

Management Spectrum

 In software engineering, the management spectrum describes the management of a

softwareproject.
 The management of a software project starts from requirement analysis and finishes
based onthe nature of the product.
 The manager of the project has to control all these P’s to have a smooth flow in the
progress ofthe project and to reach the goal.

The four P’s of management spectrum

1. People
2. Product
3. Process
4. Project

People

 People of a project includes from manager to developer, from customer to end user.
 But mainly people of a project highlight the developers.
 Highly skilled and motivated developers that the SoftwareEngineering Institute has
developed a People Management Capability Maturity Model (PM-CMM).
 Organizations that achieve high levels of maturity in the people management area have
a higherlikelihood of implementing effective software engineering practices.

Product

 The product is the ultimate goal of the project.

 This is any types of software product that has to be developed.
 To develop a software product successfully, all the product objectives and scopes
should be established, alternative solutions should be considered, technical and
management constraints should be identified beforehand.

2
  Lack of these information, it is impossible to define reasonable and accurate
estimation of the cost, an effective assessment of risks, a realistic breakdown of
project tasks or a manageable project schedule that provides a meaningful
indication of progress.

Process

 A software process provides the framework from which a comprehensive plan for
software development can be established.
 A number of different tasks, milestones, work products, and quality assurance points
enable the framework activities to be adapted to the characteristics of the software
project and the requirements of the project team.
 Finally, umbrella activities overlay the software process model.
 Umbrella activities are independent of any one framework activity and occur throughout
the process.

Project

 The project is the complete software project that includes requirement analysis,
development,delivery, maintenance and updates.
 The project manager of a project or sub-project is responsible for managing the people,
productand process.
 The responsibilities or activities of software project manager would be a long list but that
has tobe followed to avoid project failure.
 A software project could be extremely complex and as per the industry data the failure
rate ishigh.
 It is merely due to the development but mostly due to the steps before development and
sometimes due to the lack of maintenance.

Software Project Planning

 A Software Project is the complete methodology of programming advancement

from requirement gathering to testing and support, completed by the execution
procedures, in aspecified period to achieve intended software product.
 Software Project planning starts before technical work start.

3
 The various steps of planning activities

 The size is the crucial parameter for the estimation of other activities.
Resources requirementare required based on cost and development time.
 Project schedule may prove to be very useful for controlling and monitoring the
progress of theproject. This is dependent on resources & development time.

Objective

The objective of software project planning is to provide a framework that enables the manager to
make reasonable estimates of

 Resources
 Cost
 Schedule

These estimates are made within a limited time at the beginning of a software project and
shouldbe updated regularly as the project progresses.

Software Scope

 Historical aspects
 Economical aspects
 Maintenance aspects
 Requirements, analysis and design aspects
 Team development aspects

Resources

 Resources those are required for successful development and completion of project.
 There are three types of resources that are considered and are very essential for
execution ofproject and completion of project on time and on budget.
 These resources can be denoted by pyramid which is also known as Resource Pyramid.

4
Each resources is specified with four characteristics
 Description of resource
 Resource availability
 Time of resource when it will be available
 Duration of resource availability

Human Resources / People

 The planner begins by evaluating scope and selecting the skills required to complete
development.
 Both organizational position (e.g., manager, senior software engineer) and
specialty(e.g., telecommunications, database, client/server) are specified.
 For relatively small projects (one person-year or less), a single individual may
perform allsoftware engineering tasks, consulting with specialists as required.
 The number of people required for a software project can be determined only after an
estimateof development effort (e.g., person-months) is made.

o Product owner is a person responsible for project outcome. Product owner translates
the visionof what the end product should look like into the project backlog. This role
includes streamlining the execution of project’s priorities and maintaining technical
and conceptual integrity of the product.
o Project manager knows how to manage a team of software developers and how to
optimize itsfunctioning.
o A project manager is responsible for daily functioning of the team, meeting the
client’srequirements and deadlines, and keeping the needs of a team in sight.
o Software architect is a highly-skilled and experienced developer who makes high-
level decisions, mostly throughout the discovery phase. Software architect
determines an optimal tech stack, the right tools, and coding standards for the
project.

5
 o Developers and software engineers are programming experts who leverage their
knowledge ofrelevant programming languages and frameworks.
o Designers make sure the product is appealing to the eye and is easy to use. They
conductmarket research and collect the users’ feedback to make the product as
user-friendly as possible.
o Quality assurance experts test the product for any flaws or bugs to make sure it is
ready formarket launch and use.
o Business analysts are responsible for discovering, synthesizing, and analyzing the
informationpertaining to the project. They align strategic vision and business needs
with the technical details and delivery of the software.

Reusable Software Resources

• Component-based software engineering (CBSE) emphasizes reusability, the creation

and reuse of software building blocks. Such building blocks, often called components,
must be cataloged for easy reference, standardized for easy application, and validated
for easy integration.

Bennatan suggests four software resource categories that should be considered as planning

Off-the-shelf components

Existing software that can be acquired from a third party or that has been developed
internally for a past project. COTS (commercial off-the-shelf) components are
purchased from a third party, are ready for use on the current project, and have been
fully validated.

Full-experience components

Existing specifications, designs, code, or test data developed for past projects that are
similar to the software to be built for the current project. Members of the current
software team have had full experience in the application area represented by these
components. Therefore, modifications required for full-experience components will be
relatively low-risk.

Partial-experience components

Existing specifications, designs, code, or test data developed for past projects that are
related to the software to be built for the current project but will require substantial
modification. Members of the current software team have only limited experience in the
application area represented by these components. Therefore, modifications required for
partial-experience components have a fair degree of risk.

New components

Software components that must be built by the software team specifically for the needs
of the current project.

6
Environmental Resources

 The environment that supports the software project, often called the software
engineering environment (SEE), incorporates hardware and software.
 Hardware provides a platform that supports the tools (software) required to produce the
work products that are an outcome of good software engineering practice.
 Because most software organizations have multiple constituencies that require access to
the SEE, a project planner must prescribe the time window required for hardware and
software andverify that these resources will be available.
 When a computer-based system (incorporating specialized hardware and software) is to
be engineered, the software team may require access to hardware elements being
developed by other engineering teams.
 For example, software for a numerical control (NC) used on a class of machine tools
may require a specific machine tool as part of the validation test step; a software project
for advanced page layout may need a digital-typesetting system at some point during
development.Each hardware element must be specified by the software project planner.

Software Project Estimation

 Software project estimation is a complex process that revolved around predicting the
time, cost,and scope that a project requires to be deemed finished.
 But in terms of software development or software engineering, it also takes the
experience of the software development company, the technique they have to utilize,
and the process they need tofollow in order to finish the project (Software Development
Life Cycle).
 Project Estimation requires the use of complex tools and good mathematical as well as
knowledge about planning this will act as the stepping stone to make the final result
morecredible, realistic, and customer-satisfying.
There are six critical elements of a project that benefit from the use of project estimating techniques

 Cost
 Time
 Size or Scope
 Risk
7
  Resources
 Quality

In project management, the two most common types of projects

 Waterfall
 Agile

Project Estimation Techniques in Software Engineering

Top-down Estimate

 Top-down estimating assigns an overall time for the project and then breaks it down
into individual phases, work, and tasks based on the Work Breakdown Structure(WBS)
of the project.
 If a client specifies that the project must be completed in six months, a top-down
approach allows you to take that overall timeline and estimate how much time you can
commit to each project activity while still meeting the deadline that has been given by
the client.
Bottom-up Estimate
 A bottom-up estimate is the polar opposite of a top-down estimate.
 By estimating each individual task or aspect of the project using this method. Then
add all ofthe individual estimates together to create the overall project estimate.
 This type of estimate is more accurate than the top-down approach because each
activity isassessed individually.
 However, it takes longer to have completed software estimation and requires more
effortfrom the project manager as well as business analyst.
Expert Judgment
 Expert judgment is one of the most widely used estimation techniques because it is
quick andsimple.

 To estimate projects, this method relies on the expertise and intuition of experts.
 It’s most useful when you are planning a standard project that your team has
previously completed or has knowledge about. Top-down and bottom-up estimates
can both be madeusing expert judgment.

Comparative or Analogous Estimation

 To estimate project duration, comparative estimation employs past project data and a
top-downapproach.
 If similar projects took an average of eight months to complete, expect the current one
to takethe same amount of time. Then, to get your lower-level work estimates, divide
those eight months into tasks and activities.

8
Parametric Model Estimation

 Parametric modeling makes use of previous project data as well, but it tries to adjust
the dataeach time to reflect the differences between each project.
 This method estimates the current project by pro-rating the details of previous
completed projects.

Three-point Estimation

 Three-point estimation is a technique for generating bottom-up estimates that are

sometimes used.
 Assign three durations to a task instead of one; it may look like these: optimistic,
pessimistic, and most likely. Actual estimate is calculated by averaging these three
numbers.

PERT
PERT (Program Evaluation and Review Technique) method employs three-point estimating,
but it uses a weighted average of the three, with the “most likely” guess receiving the most weight.

Estimation = (p + 4m + o) / 6

P – pessimistic
O – optimistic
PERT Distribution
M – most likely

Estimation = (p + m + o) / 3

P – pessimistic
Triangular O – optimistic
Distribution
M – most likely

Step by Step to a Successful Software Project Estimation

 Define Project Type and Environment

 Understanding the Scope of Work
 Prioritizing Tasks in the Project
 Choosing Estimation Techniques
 Write Down Every Possibilities
 Revising Your Estimation
 Use Software Estimation Tools
 Special Request from Client

9
Structure of 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.

Static, Multivariable Models

These models are based 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 and cost. These models are called multivariable models.

Cost estimation simply means a technique that is used to find out the cost estimates. The cost
estimate is the financial spend that is done on the efforts to develop and test software in
Software Engineering.

Cost estimation models are some mathematical algorithms or parametric equations that
areused to estimate the cost of a product or a project.

Cost Estimation Models

Empirical Estimation Technique

o Empirical estimation is a technique or model in which empirically derived
formulas are used for predicting the data that are a required and essential part of
the software project planning step.
o These techniques are usually based on the data that is collected previously from
a project and also based on some guesses, prior experience with the
development of similar types of projects, and assumptions.
10
 o It uses the size of the software to estimate the effort.
o In this technique, an educated guess of project parameters is made. Hence, these
models are based on common sense. However, as there are many activities
involved inempirical estimation techniques, this technique is formalized.
o For example Delphi technique and Expert Judgment technique.

Heuristic Technique
o Heuristic word is derived from a Greek word that means “to discover”.
o The heuristic technique is a technique or model that is used for solving
problems, learning, or discovery in the practical methods which are used for
achieving immediate goals.
o These techniques are flexible and simple for taking quick decisions through
shortcuts and good enough calculations, most probably when working with
complex data. But the decisions that are made using this technique are necessary
to be optima l.
o In this technique, the relationship among different project parameters is
expressedusing mathematical equations.
o The popular heuristic technique is given by Constructive Cost Model
(COCOMO). This technique is also used to increase or speed up the analysis
and investment decisions.

Analytical Estimation Technique

o Analytical estimation is a type of technique that is used to measure work.
o In this technique, firstly the task is divided or broken down into its basic
component operations or elements for analyzing.
o Second, if the standard time is available from some other source, then these
sources are applied to each element or component of work.
o Third, if there is no such time available, then the work is estimated based on
the experience of the work.
o In this technique, results are derived by making certain basic assumptions about
the project. Hence, the analytical estimation technique has some scientific basis.
Halstead’s software science is based on an analytical estimation model.

COCOMO Model
COCOMO (Constructive Cost Model) is a regression model based on LOC (number of
Lines Of Code).
It is a procedural cost estimate model for software projects and is 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 1981 and is based on the study of 63 projects,
which makes 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.
o Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.

o Schedule: Simply means the amount of time required for the completion of the
job. It is measured in the units of time such as weeks, months.

Different models of COCOMO have been proposed to predict the cost estimation at
differentlevels, based on the amount of accuracy and correctness required.
All of these models can be applied to a variety of projects, whose characteristics
determinethe value of constant to be used in subsequent calculations.

11
In COCOMO, projects are categorized into three types

1. Organic
2. Semidetached
3. Embedded

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.

Semidetached

A development project can be treated with semidetached type if the development consists
of amixture 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.
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 methodexist.
For Example: ATM, Air Traffic control.

For three product categories, Boehm 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 Lines 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

Basic Model

The basic COCOMO model provides an accurate size of the project parameters.

Effort (E) = a*(KLOC)b PM

Time (D) = c*(E)d Months(M)

Persons required = Effort / time

Where,

12
 E = Total effort required for the project in Person-Months (PM).

D = Total time required for project development in Months (M).

KLOC = the size of the code for the project in Kilo lines of code.

a, b, c, d = The constant parameters for a software project.

Software Projects a b c d
Organic 2.4 1.05 2.5 0.38
Semi Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Example:
For a given project was estimated with a size of 300 KLOC. Calculate the Effort,
Scheduledtime for development. Also, calculate the Average resource size and Productivity of
the software forOrganic project type.

Solution

Given estimated size of project is: 300 KLOC

For Organic

Effort (E) = a*(KLOC)b

= 2.4*(300)1.05 = 957.61 MM

Scheduled Time (D) = c*(E)d

= 2.5*(957.61)0.38 = 33.95 Months (M)

Avg. Resource Size = E/D

= 957.61/33.95 = 28.21 Mens

Productivity of Software = KLOC/E = 300/957.61

= 0.3132 KLOC/MM = 313 LOC/MM

For Semidetached
Effort (E) = a*(KLOC)b
= 3.0*(300)1.12 = 1784.42 MM

Scheduled Time (D) = c*(E)d

= 2.5*(1784.42)0.35 = 34.35 Months(M)

For Embedded
Effort (E) = a*(KLOC)b
= 3.6*(300)1.2 = 3379.46 MM
Scheduled Time (D) = c*(E)d
= 2.5*(3379.46)0.32 = 33.66 Months(M)

13
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.

Classification of Cost Drivers and their attributes

Product attributes

Required software reliability extent

Size of the application database
The complexity of the product

Hardware attributes

Run-time performance constraints

Memory constraints
The volatility of the virtual machine environment
Required turnabout time

Personnel attributes

Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience

Project attributes

Use of software tools

Application of software engineering methods
Required development schedule

Effort (E) = a*(KLOC)b *EAF PM

Scheduled Time (D) = c*(E)d Months(M)

E = Total effort required for the project in Person-Months (PM).

D = Total time required for project development in Months (M).

KLOC = The size of the code for the project in Kilo lines of code.
a, b, c, d = The constant parameters for the software project.

EAF = It is an Effort Adjustment Factor, which is calculated by multiplying the parameter values

of different cost driver parameters. For ideal, the value is 1.

14
 COST DRIVERS VERY LOW NOMINAL HIGH VERY

PARAMETERS LOW HIGH

Product Parameter
Required Software 0.75 0.88 1 1.15 1.4
Size of Project Database NA 0.94 1.08 1.16
Complexity of The Project 0.7 0.85 1.15 1.3

Hardware Parameter
Performance Restriction NA NA 1 1.11 1.3
Memory Restriction NA NA 1.06 1.21
virtual Machine Environment NA 0.87 1.15 1.3
Required Turnabout Time NA 0.94 1.07 1.15
Personnel Parameter
Analysis Capability 1.46 1.19 1 0.86 0.71

Application Experience 1.29 1.13 0.91 0.82

Software Engineer Capability 1.42 1.17 0.86 0.7

Virtual Machine Experience 1.21 1.1 0.9 NA
Programming Experience 1.14 1.07 0.95 NA
Project Parameter

Software Engineering Methods 1.24 1.1 1 0.91 0.82

Use of Software Tools 1.24 1.1 0.91 0.83
Development Time 1.23 1.08 1.04 1.1

Example:
For a given project was estimated with a size of 300 KLOC. Calculate the Effort,
Scheduledtime for development by considering developer having high application experience and
very low experience in programming.

Solution

Given the estimated size of the project is: 300 KLOC

Developer having highly application experience: 0.82 (as per above table)
Developer having very low experience in programming: 1.14(as per above table)

EAF = 0.82*1.14= 0.9348

Effort (E) = a*(KLOC)b *EAF

= 3.0*(300)1.12 *0.9348 = 1668.07 MM

Scheduled Time (D) = c*(E)d

= 2.5*(1668.07)0.35 = 33.55 Months(M)

15
 Detailed COCOMO Model

Detailed COCOMO incorporates all qualities of the standard version with an assessment of
thecost driver’s effect on each method of the software engineering process.
The detailed model uses various effort multipliers for each cost driver property.
In this, the whole software is differentiated into multiple modules, and then applies
COCOMO in various modules to estimate effort and then sum the effort.

The Six phases of detailed COCOMO

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
givenaccording to every phase of the software lifecycle.

Advantages

Easy to estimate the total cost of the project.

Easy to implement with various factors.
Provide ideas about historical projects.

Disadvantages

It ignores requirements, customer skills, and hardware issues.

It limits the accuracy of the software costs.
It mostly depends on time factors.

Software Maintenance Cost Factors

o Non-Technical Factors
o Technical Factors
Non-Technical Factors

16
1. Application Domain
o If the application of the program is defined and well understood, the system requirements may be
definitive and maintenance due to changing needs minimized.
o If the form is entirely new, it is likely that the initial conditions will be modified frequently, as
user gain experience with the system.
2. Staff Stability
o It is simple for the original writer of a program to understand and change an application rather
than some other person who must understand the program by the study of the reports and code
listing.
o If the implementation of a system also maintains that systems, maintenance costs will reduce.
o In practice, the feature of the programming profession is such that persons change jobs regularly.
It is unusual for one user to develop and maintain an application throughout its useful life.
3. Program Lifetime
o Programs become obsolete when the program becomes obsolete, or their original hardware is
replaced, and conversion costs exceed rewriting costs.
4. Dependence on External Environment
o If an application is dependent on its external environment, it must be modified as the climate
changes.
o For example:
o Changes in a taxation system might need payroll, accounting, and stock control programs to be
modified.
o Taxation changes are nearly frequent, and maintenance costs for these programs are associated
with the frequency of these changes.
o A program used in mathematical applications does not typically depend on humans changing the
assumptions on which the program is based.
5. Hardware Stability
o If an application is designed to operate on a specific hardware configuration and that
configuration does not changes during the program's lifetime, no maintenance costs due to
hardware changes will be incurred.
o Hardware developments are so increased that this situation is rare.
o The application must be changed to use new hardware that replaces obsolete equipment.
Technical Factors
Technical Factors include the following:

17
Module Independence
It should be possible to change one program unit of a system without affecting any other unit.
Programming Language
Programs written in a high-level programming language are generally easier to understand than
programs written in a low-level language.
Programming Style
The method in which a program is written contributes to its understandability and hence, the ease with
which it can be modified.
Program Validation and Testing
o Generally, more the time and effort are spent on design validation and program testing, the fewer
bugs in the program and, consequently, maintenance costs resulting from bugs correction are
lower.
o Maintenance costs due to bug's correction are governed by the type of fault to be repaired.
o Coding errors are generally relatively cheap to correct, design errors are more expensive as they
may include the rewriting of one or more program units.
o Bugs in the software requirements are usually the most expensive to correct because of the drastic
design which is generally involved.
Documentation
o If a program is supported by clear, complete yet concise documentation, the functions of
understanding the application can be associatively straight-forward.
18
 o Program maintenance costs tends to be less for well-reported systems than for the system supplied
with inadequate or incomplete documentation.
Configuration Management Techniques
o One of the essential costs of maintenance is keeping track of all system documents and ensuring
that these are kept consistent.
o Effective configuration management can help control these costs.
Software Requirement Specification (SRS) Format
in order to form a good SRS, here you will see some points that can be used and should be considered to
form a structure of good Software Requirements Specification (SRS). These are below mentioned in the
table of contents and are well explained below.
Software Requirement Specification (SRS) Format as the name suggests, is a complete specification and
description of requirements of the software that need to be fulfilled for the successful development of the
software system. These requirements can be functional as well as non-functional depending upon the
type of requirement. The interaction between different customers and contractors is done because it is

necessary to fully understand the needs of customers. Depending

upon information gathered after interaction, SRS is developed which describes requirements of software
that may include changes and modifications that is needed to be done to increase quality of product and
to satisfy customer’s demand.
Introduction
 Purpose of this Document – At first, main aim of why this document is necessary and what’s
purpose of document is explained and described.
 Scope of this document – In this, overall working and main objective of document and what value
it will provide to customer is described and explained. It also includes a description of
development cost and time required.
 Overview – In this, description of product is explained. It’s simply summary or overall review of
product.
General description
In this, general functions of product which includes objective of user, a user characteristic, features,
benefits, about why its importance is mentioned. It also describes features of user community.
Functional Requirements
In this, possible outcome of software system which includes effects due to operation of program is fully
explained. All functional requirements which may include calculations, data processing, etc. are placed in
a ranked order. Functional requirements specify the expected behavior of the system-which outputs
should be produced from the given inputs. They describe the relationship between the input and output
of the system. For each functional requirement, detailed description all the data inputs and their source,
the units of measure, and the range of valid inputs must be specified.
Interface Requirements
19
In this, software interfaces which mean how software program communicates with each other or users
either in form of any language, code, or message are fully described and explained. Examples can be
shared memory, data streams, etc.
Performance Requirements
In this, how a software system performs desired functions under specific condition is explained. It also
explains required time, required memory, maximum error rate, etc. The performance requirements part
of an SRS specifies the performance constraints on the software system. All the requirements relating to
the performance characteristics of the system must be clearly specified. There are two types of
performance requirements: static and dynamic. Static requirements are those that do not impose
constraint on the execution characteristics of the system. Dynamic requirements specify constraints on
the execution behaviour of the system.
Design Constraints
In this, constraints which simply means limitation or restriction are specified and explained for design
team. Examples may include use of a particular algorithm, hardware and software limitations, etc. There
are a number of factors in the client’s environment that may restrict the choices of a designer leading to
design constraints such factors include standards that must be followed resource limits, operating
environment, reliability and security requirements and policies that may have an impact on the design of
the system. An SRS should identify and specify all such constraints.
Non-Functional Attributes
In this, non-functional attributes are explained that are required by software system for better
performance. An example may include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which include overall time duration
required and overall cost required for development of project.
Appendices
In this, additional information like references from where information is gathered, definitions of some
specific terms, acronyms, abbreviations, etc. are given and explained.
Uses of SRS document
 Development team require it for developing product according to the need.
 Test plans are generated by testing group based on the describe external behaviour.
 Maintenance and support staff need it to understand what the software product is supposed to do.
 Project manager base their plans and estimates of schedule, effort and resources on it.
 customer rely on it to know that product they can expect.
 As a contract between developer and customer.
 in documentation purpose.

Software Technical Reviews in Software Testing

A software technical review is examined by a team of qualified software engineers for the suitability of
the software product. This process can also be defined as a critical evaluation of an object in the
software. Through the software technical review process, we can identify the errors or defects in the
software product in the early phase itself.

20
What is a Software Technical Review?
A software technical review is a formal process where software artifacts such as requirements, design
documents, source code, test plans, and other related documents are examined by a team of peers to
identify defects and improvement opportunities. The primary goal is to ensure that the software meets its
specified requirements and is free from defects before moving on to the next phase of development.
Objectives of Software Technical Reviews
Here are The objectives of Software Technical Reviews are as follows:

Objectives of Software Technical Reviews

1. Defect Identification: To detect defects and issues early in the software development lifecycle.
2. Quality Assurance: To ensure that the software meets the quality standards and requirements.
3. Improvement: To suggest improvements in design, code, and documentation.
4. Knowledge Sharing: To facilitate the exchange of ideas and knowledge among team members.
5. Compliance: To ensure that the software adheres to regulatory and compliance standards.
Types Software Technical Review
The intent of this section is for the students to realize that the types of reviews that must be performed on
a project are dependent upon the specific intermediate deliverables that are produced. Various
application areas should also be described in the context of their review processes.

21
Types Software Technical Review
1. Peer Reviews
Informal reviews conducted by colleagues to provide quick feedback and suggestions.
 Description: Informal reviews conducted by colleagues, peers, or teammates to provide quick
feedback and suggestions. These reviews focus on improving the quality of the work product
through collaborative discussion and immediate corrective action.
 Purpose: To identify defects early, share knowledge, and improve the quality of the software
product.
 Process: Usually unstructured and does not follow a formal process. Can occur spontaneously,
often during pair programming or code sharing sessions.
 Example: A developer asks a teammate to review a piece of code they just wrote.
2. Walkthroughs
Semi-formal reviews where the author of the document or code explains the content to a group of
reviewers.
 Description: Semi-formal reviews where the author of the document or code explains the content
to a group of reviewers. The focus is on understanding the material and gathering feedback
rather than on finding defects.
 Purpose: To ensure that the content is clear, logical, and meets the requirements. Walkthroughs
also serve as a knowledge-sharing mechanism.
 Process: The author presents the material, often using slides or documents, and reviewers ask
questions and provide feedback. No formal defect logging is usually done.
 Example: A project manager walks the team through a new project plan to gather feedback and
ensure everyone understands the upcoming tasks.
3. Inspections
Formal reviews with a structured process and predefined roles, focusing on defect detection and
correction.
 Description: Formal reviews with a structured process and predefined roles, focusing on defect
detection and correction. Inspections are systematic and thorough, with the goal of identifying as
many defects as possible.
 Purpose: To detect and correct defects early in the development process, ensuring high-quality
deliverables.
 Process: Involves planning, preparation, inspection meeting, rework, and follow-up. Specific roles
such as moderator, author, scribe, and reviewers are assigned.
 Example: A software development team conducts a formal code inspection meeting to review the
latest module of the application.
4. Audits
Reviews conducted to ensure compliance with standards, regulations, and contractual agreements.
 Description: Reviews conducted to ensure compliance with standards, regulations, and
contractual agreements. Audits are typically performed by external parties or specialized internal
teams.
 Purpose: To verify that processes and products comply with specified requirements, ensuring
legal and contractual obligations are met.
22
  Process: Involves reviewing documentation, processes, and products against a predefined set of
criteria. Findings are documented, and non-compliances are reported.
 Example: An external auditor reviews a company’s software development processes to ensure
they meet ISO standards.
Difference between Formal and Informal Reviews
Furthermore, the reviews are classified into two types: Formal and Informal reviews.
Informal reviews are meant to describe the type of review that typically occurs spontaneously among
peers and in which the reviewers have any work and also not create a review report. Formal reviews are
characterized by carefully planned meetings in which reviewers are held accountable for their
participation in the review and in which a review report containing action items is generated and acted
upon.

Aspects Formal reviews Informal reviews

– Detect defects<br> – Ensure compliance – Provide quick feedback<br> –

Purpose and with standards<br> – Verify software Catch obvious defects<br> – Share
Objectives requirements knowledge

Follows a structured process<br> – Flexible and unstructured

Process and Includes planning, preparation, review process<br> – May involve ad-hoc or
Structure meeting, rework, and follow-up impromptu reviews

Extensive documentation<br> – Formal Minimal to no documentation<br> –

records of defects and issues<br> – Meeting May rely on verbal feedback or brief
Documentation minutes and action items notes

Includes specific roles such as moderator, Can include any relevant

author, reviewers, and scribe<br> – stakeholders<br> – Participants are
Participants Participants are pre-selected usually chosen informally

Importance of Software Technical Review

Some of the reasons behind the importance of STRs are as follows:
1. It also impacts employee morale. For some employees, such as maintenance personnel, the reviews
may provide an opportunity to gain visibility of their work and, thus, will be viewed positively.
2. It helps in software maintainability as it improves the developer’s general understanding of the
whole system, which further facilitates error diagnosis during maintenance.
3. It helps in the tracking of a project for both project management and customers. With this, we
can track management, customers, and also developers’ projects.
4. They provide feedback about the software and its development process. Examples of how review
processes can impact the existing software development such as by identifying weaknesses in the
software that will require additional validation effort in the future must also be provided.
Review Methodologies
There are many variations to performing technical reviews. Most of these approaches involve a group
meeting to assess a work product; however, variations of reviews exist that do not require a review group
23
meeting. The three major approaches for performing the software technical review are given as follows:
 Walk-through – Walk-throughs are a formal and very systematic type of verification method as
compared to peer review. In a walkthrough, the author of the software document presents the
document to other persons which can range from 2 to 7.
 Inspections – Inspections are the most structured and formal type of verification method and are
commonly known as inspections. It requires detailed preparation for the reviewing team members
and it includes a very high systematic review of the software product.
 Audits – It can also be described as an external type of review process as it serves to ensure that
the software is correctly verified and working as per the requirement.

LANGUAGE AND PROCESSORS FOR REQUIREMENTS SPECIFICATION

 A number of special purpose languages and processors have been developed to permit concise
statement and automated analysis of requirements specification for software.
 our purpose is to provide a brief introduction to requirements specification languages and
processors
PSL/PSA
 Problem statement language(PSL) was
Developed by professor Daniel teich row at
the university on Michigan
 The problem statement analyzer is the PSL processor
 PSL and PSA system is sometimes referred to as components of the ISDOS project
 PSL/PSA system is sometimes referred to as
the ISDOS system

 PSL system descriptions can be divided into eight major aspects:

 system input/output flow

 System structure
 Data structure
 Data derivation
 System size and volume
 System dynamics
 System properties
 project management
System input/output flow
 The system I/o flow aspect deals with the interaction between a system
and its environment.

24
 System structure
 system structure is concerned with the hierarchies among objects in a
system.
Data structure
 data structure aspect includes all the relationships that exist among
data used and/or manipulated by a system as seen by the users of the
system.
Data derivation
 The data derivation aspect of the system description specifies
which data object are involved in particular processes in the system.
 System size and volume
 The system size and volume aspect is concerned with the size of the system and
those factors the volume of processing required.
 System dynamic
Aspect of a system description presents the manner in which
the system” behaves” over time.
 project management requires that project related information.

25
 Commands in commends language

Operating system

PSL Problem
statement
Reports and messages
analyzer
(PSA)

Analyzer
database

26