Unit I

Introduction:
Software Engineering Discipline – Evolution and Impact

Software is defined as a collection of programs, procedures, rules, data and associated

documentation. The s/w is developed keeping in mind certain h/w and operating system
consideration commonly known as platform. And engineering means systematic procedure to
develop software. Some of the software characteristics are, it can be engineer or developed
and second thing is software is complex in nature.
Important of software are due to much reason as it is used in:
i)Business decision making
Ex- accounting s/w, billing s/w
ii)For scientific research & engineering problem solving.
Ex-weather forecasting system, space research s/w

iii)It is embedded in multifunctional systems such as medical,

telecom entertainment etc.
Ex-s/w for medical patient automation, s/w of GSM/CDMA service provides.
Software Quality

Several quality factors associated with software quality are as following:

· Portability: A software product is said to be portable, if it can be easily made to work
in different operating system environments, in different machines, with other software
products, etc.
· Usability: A software product has good usability, if different categories of users (i.e.
both expert and novice users) can easily invoke the functions of the product.
· Reusability: A software product has good reusability, if different modules of the
product can easily be reused to develop new products.
· Correctness: A software product is correct, if different requirements as specified in the
SRS document have been correctly implemented.
· Maintainability: A software product is maintainable, if errors can be easily corrected,
new functions can be easily added to the product, and the functionalities of the product
can be easily modified, etc.

Types of software:-
Computer s/w is mainly divided into two types.

a)system s/w
Application s/w consists of programs to perform user oriented tasks. System s/w
includes the operating system & all the utilities to enable the computer to run. Ex-window
operating system
b)application s/w
Application s/w consists of programs to perform user oriented tasks. Ex-word processor,
database management. Application s/w sits about the system s/w because it needs help of
the system s/w to run.
Program vs Software product

PROGRAMS PRODUCTS

Set of instruction related each other Collection of program designed for specific
task.

Programs are defined by individuals for A sum product is usually developed by a

their personal use. group of engineers working as a team.

Usually small size. Usually large size.

Single user. Large no of users.
Single developer. Team of developer.
Lack proper documentation. Good documentation support.
ADHOC development. Systematic development.

Lack of UI. Good UI.

Have limited functionality. Exhibit more functionality.

programs
Source
Object
code
code
documenta
Operating tion
procedure
 Types of software products:

-Generic products: [This type of software product are developed by a organization

and sold on open market to any customer], (System software,, application software
)
-Customized (or bespoke) products: This type of software products are developed by a
software contractor and especially for a customer.

-Embedded Product: Combination of both hardware and software

Software Engineering Discipline

Application of engineering for development of software is known as software engineering.

It is the systematic, innovative technique and cost effective approach to develop software. And
person involved in developing product is called software engineer. S/w engineer is a licensed
professional engineer who is skilled in engineering discipline.

Qualities / Skills possessed by a good software engineer:

1. General Skill (Analytical skill, Problem solving skill, Group work skill)
2. Programming Skill (Programming language , Data structure , Algorithm , Tools(
Compiler, Debugger))
3. Communication skill (Verbal , Written, Presentation)
4. Design Skill (s/w engineer must be familiar with several application domain)

Definition

IEEE definition of Software engineering: A systematic, disciplined and quantifiable

approach to the development, operation, maintenance and refinement of software.

Emergence of software engineering:

1. People who are developing software were consistently wrong in their estimation of
time, effort and cost.
2. Reliability and maintainability was difficult of achieved
3. Fixing bug in a delivered software was difficult
4. Delivered software frequently didn’t work
5. Changes in ration of hw to s/w cost
6. Increased cost of software maintenance
7. Increased demand of software
8. Increased demand for large and more complex software system
9. Increasing size of software

S/W ENGINEERING PRINCIPLES:-

 Software engineering is a layered technology. The bedrock that supports software
engineering is a quality focus. The foundation for software engineering is the process layer.
Software engineering process is the glue that holds the technology layers together and enables
rational and timely development of computer software. Process defines a framework for a set
of key process areas that must be established for effective delivery of software engineering
technology. The key process areas form the basis for management control of software projects
and establish the context in which technical methods are applied, work product (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.

Software engineering methods provide the technical how-to's for building software. That
encompass requirements analysis, design, program construction, testing, and support.

Software engineering methods rely on a set of basic principles that govern each area of the
technology and include modeling activities and other descriptive techniques.

Software engineering tools provide automated or semi-automated support for the process and
the methods. When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering(CASE), is established. CASE combines software, hardware, and a software
engineering database (a repository containing important information about analysis, design,
program construction, and testing) to create a software engineering environment analogous to
CAD/CAE (computer-aided design/engineering) for hardware.

S/W CHARACTERISICS:-
Characteristics of a s/w can be easily distinguished as of from the h/w.
 The change of failure rate over the product lifetime for a typical hardware and a software
product are sketched in above fig.
For hardware products, it can be observed that failure rate is initially high but decreases as the
faulty components are identified and removed. The system then enters its useful life.
After some time (called product life time) the components wear out, and the failure rate
increases. This gives the plot of hardware reliability over time its characteristics is like “bath
tub” shape.

On the other hand, for software the failure rate is at its highest during integration and test. As
the system is tested, more and more errors are identified and removed resulting in reduced
failure rate. This error removal continues at a slower pace during the useful life of the product.
As the software becomes obsolete no error corrections occurs and the failure rate remains
unchanged.
Therefore after analyzing the facts we can write the key characteristics as follows:-
a)Most s/w s are custom built rather than assembled from existing components.
b)s/w is developed or engineered not manufactured.
c)s/w is flexible.
 d)s/w does not wear out.

The s/w that mixes the specification must be produced.

iii)s/w validation
The s/w must be validated to ensure that it performs desired customer activities. iv)s/w
evolution:-
The s/w must evolve to meet changing customer needs with time.
The scenario of s/w process & its sub process are shown below:-

The s/w industry considers the entire s/w development task as a process according to Booch &
Rumbaugh. According to them a process defines who is doing what, when & how to reach a
certain goal.

Generic attributes in a software process:

1. Understandability
2. Visibility
3. Reliability
4. Robustness
5. Adaptability
6. Rapidity
7. Maintainability
8. Supportability

Characteristic of a software process:

1. Understandability
2. Visibility
3. Reliability
4. Robustness
5. Adaptability
6. Rapidity
7. Maintainability
8. Supportability

Software Project:
1. A project is a temporary endeavor undertaken to create a unique product.
2. Temporary means every project has a definite beginning and a definite end.
3. Unique means the product must be different in some ways from all similar product

Software Product:
Outcome of software project is known as software product.

Software process vs software project vs software product

Software Process

Software Project- Software Project- Software Project-

1 2 n
 Software Product-1 Software Product-2 Software Product-n

S/W LIFE CYCLE METHOD:-

Introduction:-
A software life cycle model (also called process model) is a descriptive and diagrammatic
representation 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. It also captures the
order in which these activities are to be undertaken.

In other words, a life cycle model maps the different activities performed to develop software
product from its inception to retirement. Different life cycle models may map the basic
development activities to phases in different ways.

Use of a Life Cycle Models /The need for s/w life cycle model:-
-The development team must identify a suitable life cycle model for the particular project
and then adhere to it.
-Without using of a particular life cycle model the development of a software product would
not be in a systematic and disciplined manner. So when a software product is being developed
by a team there must be a clear understanding among team members about when and what to
do, Otherwise it would lead to chaos and project failure.

-A software life cycle model defines entry and exit criteria for every phase. A phase can start
only if its phase-entry criteria have been satisfied. So without software life cycle model the
entry and exit criteria for a phase cannot be recognized. Without software life cycle models
(such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary
model, spiral model etc.) it becomes difficult for software project managers to monitor the
progress of the project.

Different s/w life cycle model:-

Many life cycle models have been proposed so far. Each of them has some advantages as well
as some disadvantages. A few important and commonly used life cycle models are as follows:

a.Classical Waterfall Model

b. Iterative Waterfall Model
c. Prototyping Model
d. Evolutionary Model
e. Spiral Model
a. Classical Waterfall Model:

Different phases of the classic waterfall model:-

The classical waterfall model is intuitively the most obvious way to develop software.
Though the classical waterfall model is elegant and intuitively obvious, it is not a practical
model in the sense that it cannot be used in actual software development projects. Thus, this
model can be considered to be a theoretical way of developing software.

Classical waterfall model divides the life cycle into the following phases as shown in fig.2.1:

-Feasibility Study
-Requirements Analysis and Specification
-Design
-Coding and Unit Testing
-Integration and System Testing
-Maintenance

Activities in each phase of the life cycle:

• Activities undertaken during feasibility study: -

The main aim of feasibility study is to determine whether it would be financially and
technically feasible to develop the product. Rough understanding between the team members
about estimate based on the client side requirement. After over all discussion they search for
variety of solution on the basis of kind of resources and time requirement etc.

Activities undertaken during 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

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.
-After all ambiguities, inconsistencies, and incompleteness have been resolved and all the
requirements properly understood, the requirements specification activity can start. -During
this activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document.

Activities undertaken during design: -

The goal of the design phase is to transform the requirements specified in the SRS document
into a structure that is suitable for implementation in some programming language. During the
design phase the software architecture is derived from the SRS document. Two distinctly
different approaches are available:
-the traditional design approach and
- the object-oriented design approach.

Activities undertaken during coding and unit testing:-

The purpose of the coding and unit testing phase (sometimes called the implementation
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 then proceeds for next stage.
During this phase, each module is unit tested to determine the correct working of all the
individual modules. It involves testing each module in isolation way as this is the most
efficient way to debug the errors identified at this stage.

Activities undertaken during integration and system testing: -

Integration of different modules is undertaken once they have been coded and unit tested.
During the integration and system testing phase, the modules are integrated in a planned
manner. Integration is normally carried out incrementally over a number of steps. During each
integration step, the partially integrated system is tested and a set of previously planned
modules are added to it. 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 laid out 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 the
product delivery to decide whether to accept or reject the delivered product.

Activities undertaken during maintenance: -

Maintenance of a typical software product requires much more effort than the effort necessary
to develop the product itself. 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 the implementation of the system, and enhancing the functionalities of the system
according to the customer’s requirements. It is called perfective maintenance.

- Porting the software to work in a new environment. For example, porting may be required to
get the software to work on a new computer platform or with a new operating system. It is
called adaptive maintenance.

Disadvantages of waterfall model:-

i)It can not handle satisfactorily different types of risks associated with real time s/w project,
because, the requirements have to be pre decided by the client.
ii)Most real life project can’t follow the exact frame sequence of the waterfall model.

b. ITERATIVE WATERFALL LIFE CYCLE MODEL:-

This waterfall model allows us to correct the error committed during the developmental
phase.
The principle of detecting errors as close to their point of introduction as possible is known as
phase containment of errors. These errors are not possible to be always detected at their point
of occurrence. But, they must be detected as they are possible, because finding the errors at
higher stage causes entire system testing hence cost is increased/high.

c. PROTYPING/RAPID PROTOTYPING MODEL:-

This model specify that before the actual system is being built the working model or the
prototype system should be built in. Prototype means dummy, it is a modern and advance
implementation system with limited functional capabilities & is comparatively inefficient with
the actual system.

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs. The possibilities may
be:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs

This is something similar to what the architectural designers of a building do; they
show a prototype of the building to their customer. The customer can evaluate whether he
likes it or not and the changes that he would need in the actual product. A similar thing
happens in the case of a software product and its prototyping model.
Another reason for developing a prototype is that it is impossible to get the perfect product in
the first attempt. Many researchers and engineers advocate that if you want to develop a good
product you must plan to throw away the first version. The experience gained in developing
the prototype can be used to develop the final product. A prototyping model can be used when
technical solutions are unclear to the development team. A developed prototype can help
engineers to critically examine the

technical issues associated with the product development. Often, major design decisions
depend on issues like the response time of a hardware controller, or the efficiency of a sorting
algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve
the technical issues.

Examples for prototype model

A prototype of the actual product is preferred in situations such as:
• user requirements are not complete
• technical issues are not clear

ADVANTAGES:-
i)The prototype which is developed is generally discarded after the system is being built but
the experience gain during the development of prototype helps the design issue as expected
from the customer.

ii)Developing a prototype in place of actual system & putting it for customer reference
resolves different technical & design issue as expected from the customer.

d. EVOLUTIONARY/INCREMENTAL LIFE CYCLE MODEL:-

Evolutionary model is based upon principle of incremented developments of the functional

unit & then integrating it for visible. Each incremental version of the product is a fully
functional s/w product providing more features than its previous version. Each incremental
version is tested individually before being integrated into the system. Development of
incremental module do not need large amount of resources for project development as in the
later case. This incremental model, they are developed in different phases can be useful to the
customers as they can be used as standalone units when they are treated independently.

This evolutionary model can be described as follows:-

C
B
A B
A
A

[A, B, C: Incremental modules developed & developed together]

This life cycle model can be defined as follows:

 Rough requirements specific

Identification of modules to be developed incrementally

Develop the incremental by iterative waterfall model

Here customer feedback & modify requirements

Develop the modified model

Maintenance
ADVANTAGES:-
i)Exact destination of customer requirements can be known.

ii)It is also reduces the maintenance tasks duration because before delivery of a module, the
customers are consulted.

iii)As the individual module takes place, so final product will contain limited amount of errors.

iii)It can be built upon object oriented platform which promotes modular s/w development.
DISADVANTAGES:-

i)It is only helpful for large s/w products because we can find individual modules for
incremental implementation.
ii)It is also used when the customer is ready to receive the product.
e. SPIRAL MODEL/RISK MANAGEMENT MODEL:-
This model of s/w development can be described as follows:

RA

Rapid prototype RA

RA Changed requirements

Specification

RA

Design

RA

Implementation

RA

Post delivery maintenance

Retirement

[ RA-Risk analysis ]
------------>maintenance
Development
 This model contains the elements from all the other life cycle model along with the necessary
risks involves in each of the developmental phase. So it is called as meta model.

The Spiral model of software development is shown in below fig. 2.2. The diagrammatic
representation of this model appears like a spiral with many loops. The exact number of loops in
the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For
example, the innermost loop might be concerned with feasibility study. The next loop with be
requirements specification, the next one with design, and so on. Each phase in this model is split
into four sectors (or quadrants)

as shown in fig. The activities are carried out during each phase of a spiral model are described
below.
The radial dimension of the full spiral model provided by Bohem in 1988 to represent the
cumulating cost along with the triangular dimension.

-First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.
- Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.

• Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.
-Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks.

- Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration
around the spiral.
• Progressively more complete version of the software gets built with each iteration around
the spiral.

Comparison of different life-cycle models:

The classical waterfall model can be considered as the basic model and all other life cycle
models as embellishments of this model. However, the classical waterfall model cannot be used
in practical development projects, since this model supports no mechanism to handle the errors
committed during any of the phases. This problem may be overcome in the iterative waterfall
model. The iterative waterfall model is probably the most widely used software development
model evolved so far. This model is simple to understand and use. However, this model is
suitable only for well-understood problems; it is not suitable for very large projects and for
projects that are subject to many risks.

The prototyping model is suitable for projects for which either the user requirements or the
underlying technical aspects are not well understood. It is especially popular for development of
the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed into a set of
different modules for incremental development and delivery of the product. This model is also
widely used for object-oriented development projects. Of course, this model can only be used if
the incremental delivery of the system is acceptable to the customer.

The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However, this
model is much more complex than the other models

Another important advantage of the incremental model is that it reduces the customer’s trauma
of getting used to an entirely new system. The gradual introduction of the product via
incremental phases provides time to the customer to adjust to the new product. Also, from the
customer’s financial viewpoint, incremental development does not require a large upfront capital
outlay. The customer can order the incremental versions as and when he can afford them.
Metrics for Project Size Estimation – Project Estimation Techniques –Risk Management –
Software Configuration Management.
 Software Project Management
 Introduction
 Many software projects fail:
o due to faulty project management practices:
 It is important to learn different aspects of software project management.
o Goal:
 To enable a group of developers to work efficiently towards successful
completion of the project
 Responsibilities of a S/W project managers
 Job responsibilities of a Project Manager
o Skills necessary for Project Manager
 1) Job responsibilities of a Project Manager
 2 responsibilities
o Project Planning
 Estimating the several aspects of the project and then planning the project
activities
 It starts from feasibility study, which receives from the customer
o Project Monitoring and Control activities
 This is to ensure that the development proceeds as per plan
 2) Skills necessary for Project Manager
 PROJECT PLANNING
 Project Planning
 Once a project is found to be feasible,
o project managers undertake project planning.
 Project Planning Activities
 Estimation:
o Effort
o Cost
o Duration
 Scheduling
o Schedules for man power and other resources are estimated
 Staffing
o Staff organizations and staffing plans have estimated
 Risk Management
o identification, analysis, and abatement procedures of risk
 Miscellaneous plans:
o quality assurance plan, configuration management plan, etc.
 Project planning
 Requires utmost care and attention --- commitments to unrealistic time and resource
estimates result in:
o irritating delays.
 o customer dissatisfaction
o adverse affect on team morale
 poor quality work
o project failure.
 SPMP Document
 Once the project planning is complete, project manager document their plans in a
Software Project Management Plan (SPMP)
Organization of SPMP Document
1. Introduction
a) Objectives
b) Major Functions
c) Performance Issues
d) Management and Technical Constraints)
2. Project Estimates
a) Historical Data
b) Estimation Techniques
c) Effort ,Cost, and Project Duration Estimates)
3. Project Resources Plan
a) People
b) Hardware and Software
c) Special Resources
4. Schedules
a) Work Breakdown Structure
b) Task Network
c) Gantt Chart Representation
d) PERT Chart Representation)
5. Risk Management Plan
a) Risk Analysis
b) Risk Identification
c) Risk Estimation
d) Abatement Procedures
6. Project Tracking and Control Plan
7. Miscellaneous Plans
a) Process Tailoring
b) Quality Assurance
METRICS FOR PROJECT SIZE ESTIMATION
Size is not in number of bytes
Size measure in terms of
y The effort and time required to develop the product
2 types
Lines of Code(LOC)
Function Point (FP)
1) LOC (Lines of Code)
Simplest and most widely used metric.
Size of a project by counting the number of source instructions in the developed
program
 Comment lines and header sections are ignored
LOC count at the end of a project is very simple
LOC count at the beginning of a project is very difficult
Some times it uses, past experiences
Disadvantages of Using LOC
Size can vary with coding style of different developers
 Focuses on coding activity alone and not including design, test ,...
 Correlates poorly with quality and efficiency of code
 Penalizes higher level programming languages, code reuse, etc.
 Measures textual complexity only.
o does not address the issues of structural or logical complexity.
 Difficult to estimate LOC from problem description
o So not useful for project planning
 2) Function Point Metric
 Overcomes some of the shortcomings of the LOC metric
 It depends on numbers of function or features it supports
 Proposed by Albrecht in early 80's
 (Add diagram : library system)
 FP is computed in 3 steps
 Step 1: Compute Unadjusted Function Point (UFP)
 Step 2: Refine with different parameters for UFP computations
 Step 3: Compute FP by using UFP with TCF (Technical complexity Factor)
 Step 1: Compute Unadjusted Function Point (UFP)
 Compute UFP as follows:
 UFP=(No.of I/P*4) +(No.of O/P*5)+(No.of Inquiries *4)+(No.of Files*10)+(No.of
Interfaces*10)
 Different Parameters are
 Input:
o A set of related inputs is counted as one input.
 Output:
o A set of related outputs is counted as one output.
 Inquiries:
o Each user query type is counted.
 Files:
o Files are logically related data and thus can be data structures or physical files.
 Interface:
o Data transfer to other systems.
o Step 2: : Refine with different parameters for UFP computations
 Complexity level of each of the parameters are graded as simple, average or complex
o (Add the table: refinement of FP)
 Step 3: Compute FP by using UFP with TCF (Technical complexity Factor)
 TCF expresses the influence of the development effort
o Ex
 Response time
 Scope of reuse
  High transaction rate
 It has values from 0(no influence) to 6 (strong influence)
 Then compute
o FP=UFP*TCF

Drawbacks of FP Metric (C
 Suffers from a major drawback:
o the size of a function is considered to be independent of its complexity.
 Extend function point metric:
o Feature Point metric:
o considers an extra parameter:
 Algorithm Complexity.