INTRODUCTION:

Software is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be a collection of executable programming code,
associated libraries and documentations. Software, when made for a specific requirement is called
software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific
principles and methods.

Software Engineering is a framework for building software and is an engineering approach to

software development. Software programs can be developed without S/E principles and
methodologies but they are indispensable if we want to achieve good quality software in a cost
effective manner. Software is defined as:

Instructions + Data Structures + Documents

Engineering is the branch of science and technology concerned with the design, building, and use
of engines, machines, and structures. It is the application of science, tools and methods to find cost
effective solution to simple and complex problems.

SOFTWARE ENGINEERING is defined as a systematic, disciplined and quantifiable approach

for the development, operation and maintenance of software

The Evolving role of software

The dual role of Software is as follows:

1. A Product- Information transformer producing, managing and displaying information.

2. A Vehicle for delivering a product- Control of computer(operating system),the
communication of information(networks) and the creation of other programs.

Characteristics of software

Software Characteristics are classified into six major components:

 These components are described below:

Functionality:
It refers to the degree of performance of the software against its intended purpose.
Required functions are:

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.
Required functions are:
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.
Required functions are:

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:

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

Emergence of Software Engineering

History and Need of Software Engineering:

More focus on Hardware:- In early days of computing the primary concern was that building
or acquiring the hardware. If the software did not work, people thought, it would be easy enough
to change it until it did work. In that case, why make the effort to plan?

Software cost consideration: The cost of software amounted to such a small fraction of the
cost of the hardware that no one considered it very important to manage it development. People
time was assumde to save machine time. Making the people process efficient received little
priority.

Meeting people expectation:- when computing matured, programs become more Complex
and larger. A team effort is required for program to be routinely specified, written, operated,
and maintained so people's expectations would be fulfilled.
Exceeded cost: As program become large and complex and the time required to write program
and their costs began to exceed to all estimates.

Time development: Programmer started to take weeks, months or years longer than expected
to complete. The systems turned over the client frequently did not work correctly because the
money or time had run out before the program could be made to work as originally intended.

Us military, several million dollar project was abandoned due to it could never be made
to work properly.

Quality concern: As computers and their programs were used for more vital tasks like
monitoring life support equipment, program quality also become new concern.

Change- expensive: Making a change within a complex program turned out to be very
expensive. It was quite easier to throw a program then to expect from program to do thing
different slightly.

Fast and Rapid change in hardware and software:As tubes were replaced by transistors->
integrated circuits. The cost of hardware which had to be increased was getting low. The time
and cost to develop the software were no longer so small, compared to hardware, that they could
be ignored.

Wrong analysis of client requirements:Programmers were often thought they had understood
the client requirement. Once the program has been written, the client begin to express distract
dissatisfaction.

No satisfactory system: Unfortunately, until several years ago no good method of

representation existed to describe satisfactorily systems as complex as those that are being
developed today.
 Software Crisis

Software Crisis is a term used in computer science for the difficulty of writing useful
and efficient computer programs in the required time .software crisis was due to using
same workforce, same methods, same tools even though rapidly increasing in software
demand, complexity of software and software challenges. With increase in the
complexity of software, many software problems arise because existing methods were
insufficient.
If we will use same workforce, same methods and same tools after fast increasing in
software demand, software complexity and software challenges, then there arise some
problems like software budget problem, software efficiency problem, software quality
problem, software managing and delivering problem etc. This condition is called
software crisis.

Causes of Software Crisis:

• The cost of owning and maintaining software was as expensive as developing the software
• At that time Projects was running over-time
• At that time Software was very inefficient
• The quality of software was low quality
• Software often did not meet requirements
• The average software project overshoots its schedule by half
• At that time Software was never delivered
Solution of Software Crisis:
There is no single solution to the crisis. One possible solution of software crisis is Software
Engineering because software engineering is a systematic, disciplined and quantifiable
approach. For preventing software crisis, there are some guidelines:

• Reduction in software over-budget

• The quality of software must be high
• Less time needed for software project
• Experience working team member on software project
• Software must be delivered

Software myths

All people who come into contact with software may suffer from various myths associated with
developing and using software. Here are a few common ones.

Management myths

Our company has books full of standards, procedures, protocol, and so on, related to
programming software. This provides everything that our programmers and managers need
to know. While company standards may exist, one must ask if the standards are complete, reflect
modern software practice, and are — importantly — actually used.

If we fall behind schedule in developing software, we can just put more people on it. If
software is late, adding more people will merely make the problem worse. This is because the
people already working on the project now need to spend time educating the newcomers, and are
thus taken away from their work. The newcomers are also far less productive than the existing
software engineers, and so the work put into training them to work on the software does not
immediately meet with an appropriate reduction in work.

Customer / end-user myths

A vague collection of software objectives is all that is required to begin programming.

Further details can be added later. If the goals / objectives for a piece of software are vague
enough to become ambiguous, then the software will almost certainly not do what the customer
requires.

Changing requirements can be easily taken care of because software is so flexible. This is not
true: the longer that development on the software has proceeded for, the more work is required to
incorporate any changes to the software requirements.
Programmer myths

Once the software is written, and works, our job is done. A large portion of software
engineering occurs after the customer has the software, since bugs will be discovered, missing
requirements uncovered, and so on.

The only deliverable for a project is the working program. At the very least there should also
be documentation, which provides support to both the software maintainers, and to the end-users.

Software engineering will make us create a lot of unnecessary documentation, and will slow
us down. Software engineering is not about producing documents. Software engineering increases
the quality of the software. Better quality reduces work load and speeds up software delivery times.

Software Processes

The term software specifies to the set of computer programs, procedures and associated
documents (Flowcharts, manuals, etc.) that describe the program and how they are to be used.

A software process is the set of activities and associated outcome that produce a software product.
Software engineers mostly carry out these activities. These are four key process activities, which
are common to all software processes. These activities are:

1. Software specifications: The functionality of the software and constraints on its operation
must be defined.
2. Software development: The software to meet the requirement must be produced.
3. Software validation: The software must be validated to ensure that it does what the
customer wants.
4. Software evolution: The software must evolve to meet changing client needs.

Personal Software Process (PSP)

The Personal Software Process (PSP) emphasizes personal measurement of both the work product
that is produced and the resultant quality of the work product. In addition PSP makes the
practitioner responsible for project planning and empowers the practitioner to control the quality
of all software work products that are developed. The PSP model defines five framework activities:

• Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, defects estimate (the number of defects projected for the work) is
 made. All metrics are recorded on worksheets or templates. Finally, development tasks are
identified and a project schedule is created.
• High level design. External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty exists.
All issues are recorded and tracked.
• High level design review. Formal verification methods are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
• Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
• Postmortem. Using the measures and metrics collected, the effectiveness of the process is
determined. Measures and metrics should provide guidance for modifying the process to
improve its effectiveness.

Team Software Process (TSP)

Watts Humphrey extended the lessons learned from the introduction of PSP and proposed a Team
Software Process (TSP). The goal of TSP is to build a “self directed” project team that organizes
itself to produce high quality software.

Humphrey defines the following objectives for TSP:

▪ Build self directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPTs)
of 3 to about 20 engineers.
▪ Show managers how to coach and motivate their teams and how to help them sustain peak
performance
▪ Accelerate software process improvement by making CMM23 Level 5 behavior normal
and expected.
▪ Provide improvement guidance to high-maturity organizations.
▪ Facilitate university teaching of industrial-grade team skills.

A self directed team has a consistent understanding of its overall goals and objectives; defines
roles and responsibilities for each team member; tracks quantitative project data (about
productivity and quality); identifies a team process that is appropriate for the project and a strategy
for implementing the process; defines local standards that are applicable to the team’s software
engineering work; continually assesses risk and reacts to it; and tracks, manages, and reports
project status.