Chapter 1

Introduction to Software Engineering








Software Characteristics
Components
Applications
Layered Technologies
Processes
Methods And Tools
Generic View Of Software Engineering
Process Models- Waterfall model,
Incremental, Evolutionary process modelsPrototype, Spiral And Concurrent
Development Model
Software:
== Program +good user interface + operating
procedures+ documentation


1.
2.
3.
Software is a logical rather than a physical
system element. Therefore, software has
characteristics that are considerably different
than those of hardware
Software is developed or engineered, it is not
manufactured in the classical sense.
Software doesn't "wear out.“
Although the industry is moving toward
component-based assembly, most software
continues to be custom built. (reusability of
components)
 Poor
quality s/w produced
 Development team exceeds the
budget
 Late delivery of s/w
 User requirement not completely
supported
 Difficult to maintain.








System software.
Real-time software.
Business software
Engineering and scientific software
Embedded software.
Personal computer software.
Web-based software.
Artificial intelligence software.
1.
[Software engineering is] the establishment and
use of sound engineering principles in order to
obtain economically software that is reliable and
works efficiently on real machines
2.[IEEE] The application of a systematic,
disciplined, quantifiable approach to the
development, operation, and maintenance of
software; that is, the application of engineering
to software.







Improved requirement specification
Improved cost and scheduled estimates
Improved quality
Better use of automated tools
Less defects in final products
Better maintenance of delivered s/w
Well defined processes

The bedrock that supports software
engineering is a quality focus.


The foundation for software engineering is
the process layer.
Process defines a framework for a set of key
process areas (KPAs) that must be
established for effective delivery of software
engineering technology.



Software engineering methods provide the
technical how-to's for building software.
Methods encompass a broad array of tasks
that include requirements analysis,
design, program construction, testing, and
support.


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.

1.
2.
The work associated with software engineering
can be categorized into three generic phases,
regardless of application area, project size, or
complexity.
The definition phase focuses on what.
The development phase focuses on how.
support phase focuses on change
associated with error correction, adaptations
3.The
required as the software's environment evolves,
and changes due to enhancements brought
about by changing customer requirements.
1.
2.
3.
4.
Correction: corrective maintenance changes
the s/w to correct defects
Adaption: Adaptive maintenance in
modification of external environment
Enhancement: Perfective Maintenance
beyond to its original functions
Prevention: Preventive Maintenance, s/w
reengineering- makes changes for more
easiness of above 3 changes
The phases and related steps described in our
generic view of software engineering are
complemented by a number of umbrella activities.
 Typical activities in this category include:
• Software project tracking and control
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management


A common process framework is established

projects, regardless of their size or
complexity.
A number of task sets—each a collection of
by defining a small number of framework
activities that are applicable to all software
software engineering work tasks,
milestones, work products, and
project
quality
framework
assurance points—enable the
activities to be
adapted to the characteristics of the software
project and the requirements of the project
team




umbrella activities—such as software quality
assurance, software
configuration
management,
and
measurement2—overlay the process model.
Umbrella activities are independent of any
one framework activity and occur throughout
the process.




Linear.
Iterative.
Evolutionary.
Parallel.

When we provide a service or create a product we
always follow a sequence of steps to accomplish a
set of tasks
◦ You do not usually
 bake a cake before all the ingredients are mixed together

We can think of a series of activities as a process
The software process is the way we produce
software.

Any process has the following characteristics

◦ It prescribes all of the major activities
◦ It uses resources and produces intermediate and final
products
◦ It may include sub-processes and has entry and exit criteria
◦ The activities are organized in a sequence
◦ Constrains or control may apply to activities
(budget control, availability of resources )

For a single project
◦ planning􀂃(time, resources, assignments)
◦ tracking and measuring

Across multiple projects
◦ organizational planning (time, resources, etc.)
◦ hiring, training, tool acquisition, etc.
◦ process assessment and improvement

For software engineering in general
◦ helps organize the field
◦ it is a topic of its own right (process models)



When the process involves the building of some
product we refer to the process as a life cycle
Software development process – software life cycle
A software process model is an abstract
representation of a process
Informal
Requirements
Process
Product
Uncertain /
Incomplete
requirement
In the beginning
Quality?


The assumption is that requirements can be
fully understood prior to development
Interaction with the customer occurs only at
the beginning (requirements) and end (after
delivery)
Informal
Requirements
Process
Product
feedback


Reduce risks by improving visibility
Allow project changes as the project
progresses
◦ based on feedback from the customer


A process model for software engineering is
chosen based on the nature of the project
and application, the methods and tools to be
used, and the controls and deliverables that
are required.
Process model also known as software life
cycle models
Generic Framework




Requirements – defines needed information, function,
behavior, performance and interfaces.
Design – data structures, software architecture,
interface representations, algorithmic details.
Implementation – source code, database, user
documentation, testing.
Waterfall Strengths
◦
◦
◦
◦
◦
Easy to understand, easy to use
Each phase has well defined inputs & outputs
Each stage has well defined deliverable & Milestones.
Good for management control (plan, staff, track)
Works well when quality is more important than cost
or schedule.


Once the phase x is over then next phase y started. Model is
always sequential in nature.
Users have little interaction with the project team. Their feedback
is not taken during development.

After the development starts changes cannot be possible easily.

Model do not support delivery of system in pieces.


Working version is available very late so review of software
product from customers is also late.
Model is very rigid because output of each phases is depend on
their successive stages.




The requirements are knowable well in advance of implementation.
The requirements have to resolved. (related to cost, schedule,
performance, safety, security, user interfaces, organizational
impacts).
The nature of the requirements will not change very much
◦ During development; during evolution
The requirements are compatible with all the key system
stakeholders’ expectations
◦ e.g., users, customer, developers, maintainers, investors

The right architecture for implementing the requirements is well
understood.

There is enough calendar time to proceed sequentially and also
cost of development.

Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required
functionality

User requirements are prioritised and the highest priority
requirements are included in early increments

Once the development of an increment is started, the
requirements are frozen.

it combines elements of the waterfall model applied in
iterative fashion. (iterative process model).

Example: word processing software
C-Communication
P-Planning
M-Modeling
C-Construction
D-Deployment








Limited number of persons can be put on project because
work is to be delivered in parts.
Customer value can be delivered with each increment so
system functionality is available earlier
Early increments act as a prototype to help elicit requirements
for later increments
Lower risk of overall project failure
Total cost of project is distributed.
End user’s feedback requirements for successive releases
become more clear.
Testing become more easily.
Risk of failure is decrease.

Model required well defined project planning schedule to
distribute the work properly.

Testing of modules result into overhead and increased cost.

Product is delivered in parts, total development cost is higher.

Well define interfaces are required to connect modules.

If requirements are well understood and project scope is well
defined then this model is very useful.

It is high speed model to develop the project.

It is incremental model.

Important feature of RAD model is customer/user involve in
all stages of development.

The process start with building rapid prototype (in 60 days)
and delivered to customer for use and feedback.

Final shape of project is started after positive feedback.

Customer involved in all stages so software achieving
customer satisfaction.

Feedback from the customer is available at the initial stages.

Development time of the product may be reduced due to use
of powerful tools.

In order to increase productivity, case tools and framework
are used.

Quick initial view of the product are possible.

Involvement of the users may increase the acceptability of the
product.





Highly specialized and skilled developers are required.
Model is ineffective if system can not be properly
modularized.
If user cannot be involved throughout the life cycle, this
model is not suitable.
Absence of reusable components can lead to failure of the
project.
It may be hardNote:
to use
a legacy
when
to use systems.
the RAD model
First, on systems that may be modularized and that are scalable
Second, on systems with reasonably well known requirements




This model is also known as the successive versions model.
System is first broken down into several modules or
functional units that can be incrementally implemented and
delivered.
The developers first develop the core modules of the system.
Next refine the modules as another incremental level by
adding new functionalities.
A
A
B
A
B
A,B,C are modules of a software product that are incrementally
developed and delivered
C





Customer knows all general objectives of software but does not
define input, output and functionality very clearly then this…..
In other case developer does not sure of different algorithms
then…
Before developing actual software, a working prototype of the
system should be built.
It is partial developed product. It has limited functional
capabilities, low reliability and inefficient performance.
The prototype may be useable program but is not suitable as the
final software product.

Advantages of Prototype model
◦ A partial product is built in the initial stages therefore
customer get a chance to see the product early in the life
cycle so give the necessary feedback.
◦ Flexibility in design and development is also supported by
the model.
◦ Customer may be more satisfied because he is involved
from starting phase.

Disadvantages of prototype model
◦ After seeing an early prototype the users may demand the
actual system to be delivered soon.
◦ End user may not be understand the prototype model.
◦ Poor documentation.
◦ If user not satisfied then he may be loose the interest in the
project.

Process is represented as a spiral rather than as a
sequence of activities with backtracking

Each loop in the spiral represents a phase in the
process.


No fixed phases such as specification or design loops in the spiral are chosen depending on what is
required
Risks are explicitly assessed
throughout the process
and
resolved

If risks cannot be
resolved, project is
immediately
terminated
Determine objectives
And identify alternative
solutions
Review and plan for
The next phase
Identify and
Resolve the risks
Develop the next
Level of the product

Spiral Model – risk driven rather than document
driven

The "risk" inherent in an activity is a measure of the
uncertainty of the outcome of that activity

High-risk activities cause schedule and cost
overruns

Risk is related to the amount and quality of
available information. The less information, the
higher the risk


Strengths
◦
◦
◦
◦
◦
Introduces risk management
Prototyping controls costs
Evolutionary development
Release builds for beta testing
Marketing advantage
◦
◦
◦
◦
Lack of risk management experience
Lack of milestones
Management is unsure of spiral process
Model is not suitable for small project
Weaknesses