Software Engineering

The term is made of two words, software and engineering.

“Software” is more than just a program code. A program is an

executable code, which serves some computational purpose.
Software is considered to be 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.

1
2
Well defined Definition : Software engineering is an engineering branch
associated with development of software product using well-defined scientific
principles, methods and procedures.

Note : The outcome of software engineering is an efficient and reliable

software product.

THE EVOLVING ROLE OF SOFTWARE

1.Today, software takes on a dual role. It is a product and, at the same time,
the vehicle for delivering a product.

2. As a product, it delivers the computing potential embodied by computer

hardware or, more broadly, a network of computers that are accessible by
local hardware. Whether it resides within a cellular phone or operates inside
a mainframe computer,

3. software is an information transformer—producing, managing, acquiring,

modifying, displaying, or transmitting information that can be as simple as a
single bit or as complex as a multimedia presentation. 3
4. As the vehicle used to deliver the product, software acts as the basis for
the control of the computer (operating systems), the communication of
information (networks), and the creation and control of other programs
(software tools and environments).

5.Software transforms personal data (e.g., an individual’s financial

transactions) so that the data can be more useful in a local context; it
manages business information to enhance competitiveness; it provides a
gateway to worldwide information networks (e.g., Internet) and provides
the means for acquiring information in all of its forms.

6. The role of computer software has undergone significant change

over a time span of little more than 50 years. Dramatic improvements
in hardware performance, profound changes in computing architectures,
vast increases in memory and storage capacity, and a wide variety of
exotic input and output options have all precipitated more sophisticated
and complex computer-based systems.

4
Note :

The lone programmer of an earlier era has been replaced by a team of

software specialists, each focusing on one part of the technology required
to deliver a complex application.

Importance of evolution

* Organizations have huge investments in their software systems - they are

critical business assets.
* To maintain the value of these assets to the business, they must be
changed and updated.
* The majority of the software budget in large companies is devoted to
changing and evolving existing software rather than developing new
software.

5
A spiral model of development and evolution

6
software characteristics

To gain an understanding of software it is important to examine the

characteristics of software that make it different from other things that
human build.

The Following are the few characteristics of Software

1. Software is engineered or developed, not manufactured in the

traditional sense.
2. Software does not wear out in the same sense as hardware

7
3. In theory, software does not wear out at all

4. But what happens when changes are requested in the software

5. Most software is custom built, rather being assembled from

existing components 8
What is software myth in software engineering?

* The development of software requires dedication and understanding on the

developers’ part.

* Many software problems arise due to myths that are formed during the initial
stages of software development. Unlike ancient folklore that often provides
valuable lessons, software myths propagate false beliefs and confusion in the
minds of management, users and developers.

* Managers, who own software development responsibility, are often under

strain and pressure to maintain a software budget, time constraints, improved
quality, and many other considerations.

9
Management Myths
The members of an organization can acquire all-the
information, they require from a manual, which contains
standards, procedures, and principles;
If the project is behind schedule, increasing the number
of programmers can reduce the time gap.
If the project is outsourced to a third party, the
management can relax and let the other firm develop
software for them.
Standards are often incomplete, in adaptable, and
outdated.
Developers are often unaware of all the established
standards.
Developers rarely follow all the known standards because
not all the standards tend to decrease the delivery time of
software while maintaining its quality.
Adding more manpower to the project, which is already
behind schedule, further delays the project.
New workers take longer to learn about the project as
compared to those already working on the project.
Outsourcing software to a third party does not help the
organization, which is incompetent in managing and
controlling the software project internally. The
organization invariably suffers when it out sources the
software project.
10
In most cases, users tend to believe myths about the software because software managers and developers do not try to
correct the false beliefs. These myths lead to false expectations and ultimately develop dissatisfaction among the users.
Common user myths are listed in the below.

User Myths :

Brief requirement stated in the initial process is Starting development with incomplete and ambiguous
enough to start development; detailed requirements requirements often lead to software failure. Instead, a
can be added at the later stages. complete and formal description of requirements is essential
before starting development.

Adding requirements at a later stage often requires

repeating the entire development process.

Software is flexible; hence software requirement changes Incorporating change requests earlier in the development
can be added during any phase of the development process costs lesser than those that occurs at later stages.
process. This is because incorporating changes later may require
redesigning and extra resources

11
In the early days of software development, programming was viewed as an art, but now software development has
gradually become an engineering discipline. However, developers still believe in some myths-. Some of the common
developer myths are mentioned below.
Software development is considered complete when the
code is delivered.
The success of a software project depends on the quality of
the product produced.
Software engineering requires unnecessary documentation,
which slows down the project.
The only product that is delivered after the completion of a
project is the working program(s).
Software quality can be assessed only after the program is
executed.
50% to 70% of all the efforts are expended after the software is
delivered to the user.
The quality of programs is not the only factor that makes the
project successful instead the documentation and software
configuration also play a crucial role.
Software engineering is about creating quality at every level of
the software project. Proper documentation enhances quality
which results in reducing the amount of rework.
The deliverables of a successful project includes not only the
working program but also the documentation to guide the users
for using the software.
The quality of software can be measured during any phase of
development process by applying some quality assurance
mechanism. One such mechanism is formal technical review
that can be effectively used during each phase of development
to uncover certain errors
12
Software Crisis is a term used in the early days of computing science for
difficulty of writing useful and efficient computer programs in the required
time.

Causes of Software Crisis

* Project running over budget

* Project running over time
* Software was very inefficient
* Software was of low Quality
* Software often didn’t meet requirement
* Project were unmanageable and code difficult to maintain
* Software was never delivered

Important Note : Edsger Dijkstra's 1972 “Turing Award Lecture” makes

reference to this same problem: The major cause of the software crisis is
that the machines have become several orders of magnitude more
powerful. Software often did not meet requirements. Projects were
unmanageable and code difficult to maintain.
13
By the end of the 1960s, hardware costs had fallen exponentially, and were
continuing to do so, while the cost of software development was rising at a
similar rate. (See below Figure)

14
15
Important Note : Solution of Software Crisis is Software Engineering

IEEE definition of software engineering is “the systematic application of

scientific and technological knowledge,methods, and experience to the
design, implementation, testing, and documentation of software”

* As a solution to software crisis , we must apply a disciplinary art; using

tools that help us manage this complexity.

* It is believed that the only satisfactory solution to the present software

crisis can possibly come from a spread of software engineering practices
among the engineers, coupled with further advancements to the software
engineering discipline itself.

16
Software Development is a Layered Technology

Software development is totally a layered technology. Therefore, to develop

software one will have to go from one layer to another. The layers are
related and each layer demands the fulfilment of the previous layer.

Layers of Software Development

1. Quality Focus
2. Process
3. Methods
4. Tools

17
Quality Focus

1. Software engineering must part of organizational commitment to

Quality.

2. Total quality management and similar philosophies foster a continuous

process improvement culture, and this culture ultimately leads to the
development of increasingly more mature approaches to software
engineering.

3. The bedrock that supports software engineering is a quality focus.

18
Process

1. The foundation for software engineering is the process layer.

2. Process defines a framework for a set of Key Process Areas (KPAs) that
must be established for effective delivery of software engineering technology.

3. Consequently, this establishes the context in which technical methods are

applied, work products such as models, documents, data, reports, forms, etc.
are produced, milestones are established, quality is ensured, and change is
properly managed.

19
Methods :

Software engineering methods provide the technical idea for building software.
Methods will include requirements analysis, design, program construction,
testing, and support.

This relies on a set of basic principles that govern each area of the technology
and include modelling activities and other descriptive techniques.

Tools :

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 is established.

20
Software process
Software Process is a set of required activities and the outcome of the activities with a target to produce a
software product.

A software process is a flowchart of developing a software product, which includes gathering requirements,
analysing those requirements, scheduling development phases, checking the developments, implementing
changes etc. and this can be till the delivery of the final software product.

21
An SRS should have enough information for developers to complete
the software described. It not only lays out the description of the
software under development but also the purpose it will serve: what
the software is supposed to do and how it should perform.

SRS document typically includes these elements:

* The purpose of the software being developed

* An overall description of the software
* The functionality of the software or what it is supposed to do
* Performance of the software in a production situation
* Non-functional requirements
* External interfaces or how the software will interact with hardware or other
software it must connect to
* Design constraints or the limitations of the environment that the software
will run in

22
 Linear Sequential Model

* The waterfall model is a linear, sequential approach to the software

development life cycle (SDLC).

* It is popular in software engineering and product development.

* The waterfall model emphasizes a logical progression of steps. Similar to

the direction water flows over the edge of a drop, distinct endpoints or goals
are set for each phase of development and cannot be revisited after
completion.

The waterfall methodology is composed of seven non-overlapping stages

23
24
Requirements: Potential requirements, deadlines and guidelines for the
project are analysed and placed into a functional specification. This stage
handles the defining and planning of the project without mentioning specific
processes.

Analysis: The system specifications are analyzed to generate product models

and business logic that will guide production. This is also when financial and
technical resources are audited for feasibility.

Design: A design specification document is created to outline technical design

requirements such as programming language, hardware, data sources,
architecture and services.

Coding/Implementation: The source code is developed using the models,

logic and requirements designated in the prior stages. Typically, the system is
designed in smaller components, or units, before being implemented together.

Testing: This is when quality assurance, unit, system and beta tests take
place to report issues that may need to be resolved. This may cause a forced
repeat of the coding stage for debugging. If the system passes the tests, the
waterfall continues forward. 25
Operation/Deployment: The product or application is deemed fully
functional and is deployed to a live environment.

Maintenance: Corrective, adaptive and perfective maintenance is carried

out indefinitely to improve, update and enhance the final product. This could
include releasing patch updates or releasing new versions.

Important Note :

The waterfall approach is ideal for projects that have specific

documentation, fixed requirements, ample resources, an established
timeline and well-understood technology.

Alternatives to the waterfall model include joint application development

(JAD), rapid application development (RAD), sync-and-stabilize, Agile
project management (APM) and the spiral model.

26
Advantages of the waterfall model

* Is simple to understand, follow and arrange tasks.

* Clearly defines milestones and deadlines.

Disadvantages of the waterfall model

* Design is not adaptive; often when a defect is found, the entire process
needs to start over.

* Ignores the potential to receive mid-process user or client feedback and

make changes based on results.

* Delays testing until the end of the development life cycle.

* Not ideal for complex, high risk, ongoing or object-oriented projects

27
Prototyping model

The prototyping model is a systems development method in which a prototype is built, tested and then reworked as
necessary until an acceptable outcome is achieved from which the complete system or product can be developed.

Purpose of Prototype Model :

A prototype is an early sample, model, or release of a product built to test a concept or process.

What is Prototype Model ?

Ans: Prototyping is an experimental process where design teams implement ideas into tangible forms from paper to
digital. Teams build prototypes of varying degrees of quality to capture design concepts and test on users. With
prototypes, you can refine and validate your designs so your brand can release the right products.

28
Steps of Prototype Model :

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

29
Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Support early product marketing
4. Reduce Maintenance cost.
5. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. Prototyping tools are expensive.

2. Special tools & techniques are required to build a prototype.
3. It is a time-consuming process.
4. Require extensive customer collaboration

30
Spiral Model

The spiral model is a systems development lifecycle (SDLC) method used

for risk management that combines the iterative development process
model with elements of the Waterfall model.

The spiral model is used by software engineers and is favored for

large, expensive and complicated projects.
1. The new system requirements are
defined in as much detail as possible.

2.A preliminary design is created for the

new system.

3. A first prototype of the new system is

constructed from the preliminary design.

4. Second prototype build based on

previous one with addition of new
requirements.

5.The entire project can be aborted if the

risk is deemed too great. Risk factors
might involve development cost overruns,
operating-cost miscalculation and other 31
factors that could result in a less-than-
satisfactory final product.
1. The spiral model looks like a coil with many loops.

2. The number of loops varies based on each project and is often

designated by the project manager.

3. Each loop of the spiral is a phase in the software development

Process.

4. The spiral model enables gradual releases and refinement of a

product through each phase of the spiral as well as the ability to build
prototypes at each phase.

5. The most important feature of the model is its ability to manage

unknown risks after the project has commenced; creating a prototype
makes this feasible.

32
Uses of the spiral model

1. The spiral model is best used in large, expensive and complicated projects

2. Projects in which frequent releases are necessary

3. Projects in which changes may be required at any time

4. Long term projects that are not feasible due to altered economic priorities

5. Medium to high risk projects

6. Projects in which cost and risk analysis is important

7. Projects that would benefit from the creation of a prototype

8. Projects with unclear or complex requirements.

9. The Flexibility, Customer satisfaction and Risk handling are other benefits of
Spiral Model
33
Important Note : The progressive nature of the model allows developers to
break a big project into smaller pieces and tackle one feature at a time,
ensuring nothing is missed. Furthermore, since the prototype building is done
progressively, the cost estimation of the whole project can sometimes be
easier.

Limitations :

1. High cost - The spiral model is expensive and, therefore, is not suitable for small
projects.

2. Dependence on risk analysis - Since successful completion of the project

depends on effective risk handling, then it is necessary for involved personnel to
have expertise in risk assessment.

3. Complexity - The spiral model is more complex than other SDLC options. For it to
operate efficiently, protocols must be followed closely. Furthermore, there is
increased documentation since the model involves intermediate phases.

4. Hard to manage time - Going into the project, the number of required phases is
often unknown, making time management almost impossible. Therefore, there is
always a risk for falling behind schedule or going over budget. 34
RAD Model [Rapid Application Development]

* RAD Model or Rapid Application Development model is a software

development process based on prototyping without any specific planning.

* In RAD model, there is less attention paid to the planning and more priority
is given to the development tasks.

* It targets at developing software in a short span of time.

SDLC RAD modelling has following phases

1. Business Modelling
2. Data Modelling
3. Process Modelling
4. Application Generation
5. Testing and Turnover

35
Business Modelling :

The business model for the product

under development is designed in terms
of flow of information and the distribution
of information between various business
channels.

Data Modelling :

The information gathered in the

Business Modelling phase is reviewed
and analysed to form sets of data
objects vital for the business.

The attributes of all data sets is identified

and defined. The relation between these
data objects are established and defined
in detail in relevance to the business
model. 36
Process Modelling :

The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model.

The process model for any changes or enhancements to the data object
sets is defined in this phase.

Process descriptions for adding, deleting, retrieving or modifying a data

object are given.

Application Generation :

The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.

37
Testing and Turnover :

The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration.

However, the data flow and the interfaces between all the components need to
be thoroughly tested with complete test coverage.

Since most of the programming components have already been tested, it

reduces the risk of any major issues.

38
When to use RAD Methodology?

* When a system needs to be produced in a short span of time (2-3 months)

* When the requirements are known
* When the user will be involved all through the life cycle
* When technical risk is less
* When there is a necessity to create a system that can be modularized in 2-3
months of time
* When a budget is high enough to afford designers for modelling along with the
cost of automated tools for code generation

39
Advantages and Disadvantages
Advantages Disadvantages

Flexible and adaptable to changes It can’t be used for smaller projects

It is useful when you have to reduce Not all application is compatible with
the overall project risk RAD

It is easier to transfer deliverables as If developers are not committed to

scripts, high-level abstractions and delivering software on time, RAD
intermediate codes are used projects can fail
Due to prototyping in nature, there is Reduced scalability occurs because
a possibility of lesser defects a RAD developed application begins
as a prototype and evolves into a
finished application
With less people, productivity can be Requires highly skilled designers or
increased in short time developers 40