Lec 2 SE1

SE-2223
Software Engineering-1
(SE-1)
Lecture: 02
Sequence [Todays Agenda]
Content of Lecture
• Software Myths
• Program vs Software Product
• Programming vs Software Engineering
• Software Engineering Frameworks
• Process Model
Software Myths
Software Myths
(Developers Perspective)
Software Myths
(Developers Perspective - 2)
Software Myths
(Developers Perspective - 3)
Software Myths
(Management Perspective)
Software Myths
(Management Perspective - 2)
Software Myths
(Management Perspective - 3)
Program v/s Software Product
Software Programming ≠ Software Engineering
Software Programming ≠ Software Engineering
Software is Complex
The Role of Software Engineering
Software Engineering Framework
Any Engineering approach must be founded on

organizational commitment to quality.
That means the software development organization must
have special focus on quality while performing the software
engineering activities.
Based on this commitment to quality by the organization, a
software engineering framework is proposed
Software Engineering Framework
The Software Process
Phases of a Life-Cycle
• Requirements
• System Design
• Detailed Design
• Implementation
• Testing & Installation
• Operations & Maintenance
• Retirement
Phases of a Life-Cycle
A phase is a
–period of time within a life-cycle
–that has a defined goal and
–is based on result(s) of earlier phases.
Different Life Cycle Models
• Build-and-fix model
• Waterfall model
• Rapid prototyping model
• Incremental model
• Spiral model
• Extreme programming
• Synchronize-and-stabilize model
• Component Based Software Engineering
• Object-Oriented life-cycle models
Generic Waterfall Model
Documentation
• Internal technical documentation

• External technical documentation
• End-user documentation
• for each version and release
Documentation
• • internal technical documentation:

– the results of each phase.
– the rationale and assumptions behind the decisions made in
each phase.
– layouts and results of tests.
– error & fixes log.
Documentation
• external technical documentation:

• – system structure
• – required environment
• – instructions for installation
• – maintenance & operation
• – guidelines for trouble shooting
Documentation
• • end-user documentation:
• – user handbook
• – quick reference
• – guided tour
• – standard set-up
Waterfall Model Strengths
• Easy to understand, easy to use.

• Provides structure to inexperienced staff.
• Milestones are well understood.
• Good for management control (plan, staff, track).
• Works well when quality is more important than:
• Cost
• Schedule.
Waterfall Model Deficiencies
• All requirements must be known upfront.

• Deliverables created for each phase are considered frozen.
• Can give a false impression of progress.
• Not reflecting problem-solving nature of software development
• Iterations of phases
• Little opportunity for customer to preview the system.
Waterfall model Deficiencies (2)
• Accommodating change after the process is underway.

• – One phase has to be complete before moving onto the next
phase.
• – Difficult to respond to changing customer requirements
• – few business systems have stable requirements.
• When the requirements are "change proof".
• – Large, multi-site engineering projects.
Waterfall Model: When to Use
• Requirements are very well known.
• Product definition is stable.
• Technology is understood.
• New version of an existing product.
• Porting an existing product to a new platform.
• High risk for new systems:
• Due to specification and design problems
Iterative Waterfall Model
In practice, it is not possible to strictly follow the classical
waterfall model for software development work.
In this context, we can view the iterative waterfall model as
making necessary changes to the classical waterfall model so
that it becomes applicable to practical software
development projects.
In Iterative waterfall model, the feedback paths are
provided from every phase to its preceding phase.
The feedback paths allow for correction of the errors
committed during a phase, as and when these are detected
in a later phase.
For example, if during a testing a design error is identified,
then the feedback path allows the design to be reworked
and the changes to be reflected in the design documents.
However, observe that there is no feedback path to the
feasibility stage. This means that the feasibility study errors
cannot be corrected.
When to use iterative waterfall model
The requirement is not defined and clearly understood.
New technology is being learned by the development team.
There are some high risk features and goals which might in
the future.
Application of Iterative Waterfall Model
• Major requirements are defined but the minor details might

involve when time goes.
• New technologies are being used and there is a learning
curve for the programmers to learn.
• Resource are limited to do a huge project.
• Very high risk as a goal of the project might change from
time to time.
Advantages of Iterative Waterfall Model
• Feedback Path: iterative waterfall allows the mechanism of

error connection because there is a feedback path from one
phase to its preceding phase which it lacks in the Waterfall
Model.
• Simple: iterative waterfall model is simple to understand and
use. It is the most widely used software development model
evolved so far.
• Parallel development: can be done.
Disadvantage of Iterative Waterfall Model
• More resource: may be required to implement the iterative waterfall model.

• Difficult to include change requests: In the iterative waterfall model, all the
requirements must be clearly defined before starting of the development
phase but sometimes customer requirement changes which is difficult
to incorporate change requests that are made after development phase starts.
• Not support Intermediate delivery: Project has to be fully completed before it
delivered to the customer.
• Risk handling: Project is prone to many types of risk but there is no risk
handling mechanism.
• Not suitable for a small project.
The Incremental Model
OR Iterative Enhancement Model
1. Basic idea: software should be developed in:

Increments; each increment adding some
functionality until the full system is implemented.
2. At each step, extensions and design modifications can be made .

The Incremental Model
Advantages of incremental model
1. Major advantage: it can result in better testing since testing

each increment is likely to be easier than testing the entire
system.
2. Similar to prototype each increment provides feed back
which is useful for determining further/final requirements of
the system.
3. Model proceeds in steps starting from the simple and key
aspects of the system.
4. A project control list is prepared that contains, in order, all
the tasks to be implemented in the final system; provides a
better control and progress monitoring of development.
Incremental development benefits
• The cost of accommodating changing customer

requirements is reduced.
• It is easier to get customer feedback on the
development work that has been done.
• More rapid delivery and deployment of useful software
to the customer is possible.
Incremental development problems
• The process is not visible.

• – Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
• • System structure tends to degrade as new increments are
added.
• – Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.
Incremental development and delivery
• Incremental development
• – Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment;
• – Normal approach used in agile methods;
• – Evaluation done by user/customer proxy.
• • Incremental delivery
• – Deploy an increment for use by end-users;
• – More realistic evaluation about practical use of software;
• – Difficult to implement for replacement systems as increments
have less functionality than the system being replaced.
48

Lec 2 SE1

Uploaded by

Copyright:

Available Formats

Lec 2 SE1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lec 2 SE1

Uploaded by

Copyright:

Available Formats

SE-2223

Any Engineering approach must be founded on

• Internal technical documentation

• • internal technical documentation:

• external technical documentation:

• Easy to understand, easy to use.

• All requirements must be known upfront.

• Accommodating change after the process is underway.

• Major requirements are defined but the minor details might

• Feedback Path: iterative waterfall allows the mechanism of

• More resource: may be required to implement the iterative waterfall model.

OR Iterative Enhancement Model

1. Basic idea: software should be developed in:

2. At each step, extensions and design modifications can be made .

1. Major advantage: it can result in better testing since testing

• The cost of accommodating changing customer

• The process is not visible.

You might also like