EID303 SE UNIT I Lecture Notes 3B5

LECTURE
NOTES UNIT I
EID303
SOFTWARE
ENGINEERING
3/4 B.Tech B5
PRANEEL ANKIREDDY
ASSISTANT PROFESSOR,
DEPARTMENT OF
CSE,GIT,GU
EID 303: Software Engineering LECTURE NOTES | UNIT I
Syllabus included in UNIT I:
Introduction to Software Engineering: Software, software engineering, the changing nature of

software, software myths. A Generic view of process: Software engineering, a layered
technology, a process framework, CMMI. Process models: The waterfall model, incremental
process models, evolutionary process models.
Software: It is the product that software engineers design and build then support over the long
term. It encompasses programs that execute within a computer of any size and architecture,
documents that encompass hard-copy and virtual forms, and data that combine numbers and text
but also includes representations of pictorial, video, and audio information.
Who builds / uses software? Software engineers build and support it, and virtually everyone in
the industrialized world uses it either directly or indirectly.
Why software? Because it affects nearly every aspect of our lives and has become pervasive in
our commerce, our culture, and our everyday activities.
What is software? From the point of view of a software engineer, the work product is the
programs, documents, and data that are computer software. But from the users viewpoint, the
work product is the resultant information that somehow makes the users world better.
Characteristics of Software Engineering:

Software is developed or engineered. It is not manufactured in the classical sense.
Software doesnt wear out
The industry is moving toward component-based construction, most software continues
to be custom built.
Different Definitions of Software Engineering:

Software Engineering is the process of solving customers problem by the systematic
development and evolution of large, high quality software systems within cost, time and
other constraints.
3/4 B.Tech B5, Department of Computer Science, GU Page 2 of 26

Software Engineering is a systematic approach to development, operation, maintenance

and retirement of software.
Software Engineering is the application of science and mathematics by which the
capabilities of computer equipment are made useful to man via computer programs,
procedures and associated with documentation.
The Evolving Role of the Software Softwares Dual Role
Software is a product.
Delivers computing potential.
Produces, manages, acquires, modifies, displays, or transmits information.
Software is a vehicle for delivering a product.
Supports or directly provides system functionality.
Controls other programs (e.g., an operating system).
Effects communications (e.g., networking software).
Helps build other software (e.g., software tools).
Software Applications
System software.
Application software application.
Engineering/scientific software.
Embedded software.
Product line software.
WebApps (Web applications).
AI software.
Software - New Categories

Ubiquitous computing - wireless networks
Net sourcing - the Web as a computing engine
Open source free source code open to the computing community (a blessing, but also
a potential curse!)

Data mining
Grid computing
Cognitive machines
Software for nanotechnologies
Software Myths
Widely held but false view
Propagate misinformation and confusion
Three types of myth
Management myth
Customer myth
Practitioners myth
Management myth
Myth (1) - The available standards and procedures for software are enough.
Myth (2) - Each organization feel that they have state-of-art software development tools
since they have latest computer.
Myth (3) - Adding more programmers when the work is behind schedule can catch up.
Myth (4) - Outsourcing the software project to third party, we can relax and let that party
build it.
Customer myth
Myth (1) - General statement of objective is enough to begin writing programs, the
details can be filled in later.
Myth (2) - Software is easy to change because software is flexible.
Practitioners myth
Myth (1) - Once the program is written, the job has been done.
Myth (2) - Until the program is running, there is no way of assessing the quality.
Myth (3) - The only deliverable work product is the working program
Myth (4) - Software Engineering creates voluminous and unnecessary documentation and
invariably slows down software development.

Software Engineering A Layered Approach

Quality focus - Bedrock that supports software Engineering.
Process - Foundation for software Engineering
Methods - Provide technical how-tos for building software
Tools - Provide semi-automatic and automatic support to methods. [ i.e., CAD /CAM ]
Figure: Layers of Software.
A PROCESS FRAMEWORK
Establishes the foundation for a complete software process
Identifies a number of framework activities applicable to all software projects
Also include a set of umbrella activities that are applicable across the entire software
process.
Figure: The Process Framework

Used as a basis for the description of process models.

Generic process activities
Communication
Planning
Modeling
Construction
Deployment
Generic view of engineering complimented by a number of umbrella activities
Software project tracking and control
Risk management
Software quality assurance
Formal technical reviews
Measurement
Software configuration management
Reusability management
Document preparation and production
Risk management
CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

Developed by SEI(Software Engineering institute)
Assess the process model followed by an organization and rate the organization with
different levels.
A set of software engineering capabilities should be present as organizations reach
different levels of process capability and maturity.
CMMI process Meta model can be represented in different ways:
A Continuous Model.
A Staged Model.
Continuous Model
Lets organization select specific improvement that best meet its business objectives and
minimize risk

Levels are called capability levels.

Describes a process in 2 dimensions.
Each process area is assessed against specific goals and practices and is rated according
to the following capability levels.
Levels of CMMI
Level 0: Incomplete: Process is adhoc .Objective and goal of process areas are not
known.
Level 1: Performed: Goal, objective, work tasks, work products and other activities of
software process are carried out.
Level 2: Managed: Activities are monitored, reviewed, evaluated and controlled.
Level 3: Defined: Activities are standardized, integrated and documented.
Level 4: Quantitatively Managed: Metrics and indicators are available to measure the
process and quality.
Level 5: Optimized: Continuous process improvement based on quantitative feedback
from the user. Use of innovative ideas and techniques, statistical quality control and other
methods for process improvement.
Staged Model:
This model is used if you have no clue of how to improve the process for quality
software.
It gives a suggestion of what things other organizations have found helpful to work first.
Levels are called maturity levels.
CMMI currently addresses three areas of interest:
Product and service development CMMI for Development (CMMI-DEV),

Service establishment, management, CMMI for Services (CMMI-SVC), and
Product and service acquisition CMMI for Acquisition (CMMI-ACQ).
Process Areas required to achieve a Maturity Model

LEVELS DESSCRIPTION PROCESSAREAS / ACTIVITIES
Figure: Process areas required to achieve a Maturity Level.
Figure: Levels of CMMI Model with Umbrella Activities [Process Areas]

Level5-Optimized
Level4 Quantitatively
Managed
Level 3 - Defined
Level 2 - Managed
Level 1 - Performed
Level 0 - Incomplete
Process Patterns

Software Process is defined as collection of Patterns.

Process pattern provides a template.
Process Template
Pattern Name
Intent
Type Three types
Task pattern
Stage pattern
Phase Pattern
Initial Context
Problem
Solution
Resulting Context
Related Patterns
Process Assessment
Does not specify the quality of the software or whether the software will be delivered on
time or will it stand up to the user requirements.
It attempts to keep a check on the current state of the software process with the intention
of improving it.

Figure: The Process Assessment
Approaches to Software Process Assessments.

Standard CMMI assessment (SCAMPI).
CMM based appraisal for internal process improvement.
SPICE (ISO/IEC 15504).
ISO 9001:2000 for software.
Personal and Team Software Process

Personal software process
Planning
High level design
High level design review
Development
Postmortem

Team software process

Goals of TSP
Build self-directed teams.
Motivate the teams.
Acceptance of CMM level 5 behavior as normal to accelerate software process
improvement.
Provide improvement guidance to high maturity organization.
Stages of TSP
Launch
High-level design
Implementation
Integration and test
Postmortem
Process Models:
Various software development life cycle [SDLC] models are suitable for specific project related
conditions which include organization, requirements stability, risks, budget, and duration of
project. One life cycle model theoretical may suite particular conditions and at the same time
other model may also looks fitting into the requirements but one should consider trade-off while
deciding which model to choose. Here I am summarizing advantages and disadvantages of
various life cycle models.
Help in the software development.

Guide the software team through a set of framework activities
Process Models may be linear, incremental or evolutionary.
The Classic Model / The Linear Model / the Waterfall Model

Used when requirements are well understood in the beginning.
Also called classic life cycle.
A systematic, sequential approach to Software development.

Begins with customer specification of Requirements and progresses through planning,

modeling, construction and deployment.
This Model suggests a systematic, sequential approach to SW development that begins at
the system level and progresses through analysis, design, code and testing.
Advantages
Simple goal.
Simple to understand and use.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.
Easy to manage. Each phase has specific deliverable and a review.
Works well for projects where requirements are well understood.
Works well when quality is more important than cost/schedule.
Customers/End users already know about it.

Figure: The Waterfall Model.
Disadvantages
It is difficult to measure progress within stages.

Cannot accommodate changing requirements.
No working software is produced until late in the life cycle.
Risk and uncertainty is high with this process model.
Adjusting scope during the life cycle can end a project
Not suitable for complex projects
Not suitable for projects of long duration because in long running projects requirements
are likely to change.
Integration is done as a "big-bang at the very end [Single shot], which doesn't allow
identifying any technological or business bottleneck or challenges early.
Users can only judge quality at the end.

Attempt to go back 2 or more phases is very costly.

Percentage completion of functionality cannot be determined in middle of the project
development because functionality will be undergoing some phase.
Very risky, since one process can not start before finishing the other.
Problems
Real projects rarely follow the sequential flow since they are always iterative
The model requires requirements to be explicitly spelled out in the beginning, which is
often difficult.
A working model is not available until late in the project time plan.
The customer must have patience.
The Incremental Process Model

Linear sequential model is not suited for projects which are iterative in nature,
Incremental model suits such projects.
Used when initial requirements are reasonably well-defined and compelling needs to
provide limited functionality quickly.
Functionality expanded further in later releases.
Software is developed in increments.
Software releases in increments.
1st increment constitutes Core product.
Basic requirements are addressed.
Core product undergoes detailed evaluation by the customer.
As a result, plan is developed for the next increment.
Plan addresses the modification of core product to better meet the needs of customer.
Process is repeated until the complete product is produced.

Figure: The incremental Model
Advantages
Some working functionality can be developed quickly and early in the life cycle.
Results are obtained early and periodically.
Parallel development can be planned.
Progress can be measured.
Less costly to change the scope/requirements.
Testing and debugging during smaller iteration is easy.
Risks are identified and resolved during iteration; and each iteration is an easily managed
milestone.
Easier to manage risk - High risk part is done first.
With every increment operational product is delivered.

Issues, challenges & risks identified from each increment can be utilized / applied to the
next increment.
Disadvantages
More resources may be required.

Although cost of change is lesser but it is not very suitable for changing requirements.
More management attention is required.
Each phase of iteration is rigid with no overlaps.
System architecture or design issues may arise because not all requirements are gathered
upfront for the entire life cycle.
Does not allow iterations within an increment.
Defining increments may require definition of the complete system.
The RAD Model (Rapid Application Development)

An incremental software process model.
Having a short development cycle.
High-speed adoption of the waterfall model using a component based construction
approach.
Creates a fully functional system within a very short span time of 60 to 90 days.
Multiple software teams work in parallel on different functions.
Modeling encompasses three major phases: Business modeling, Data modeling and
process modeling.
Construction uses reusable components, automatic code generation and testing.

Figure: The RAD Model
Advantages
Time to deliver is less.

Changing requirements can be accommodated.
Progress can be measured.
Cycle time can be short with use of powerful RAD tools.
Productivity with fewer people in short time.
Use of tools and frameworks.
Disadvantages
Management complexity is more.

Resource requirements may be more.
Suitable for systems that are component based and scalable.
Suitable only when requirements are well known.

Requires user involvement throughout the life cycle.

Suitable for project requiring shorter development times.
Problems in RAD
Requires a number of RAD teams
Requires commitment from both developer and customer for rapid-fire completion of
activities.
Requires modularity.
Not suited when technical risks are high.
For large, but scalable projects, RAD requires sufficient human resources to create right
number of RAD teams.
If developers and customers are not committed to the rapid-fire activities necessary, RAD
projects will fail.
If a system cannot be properly modularized, building the components necessary for RAD
will be problematic.
RAD may not be appropriate when technical risks are high.
Evolutionary Process Models

Software evolves over a period of time
Business and product requirements often change as development proceeds making a
straight-line path to an end product unrealistic
Evolutionary models are iterative and as such are applicable to modern day applications
Types of evolutionary models
Prototyping
Spiral model
Prototyping
The Prototyping Model is a systems development method (SDM) in which a prototype (an early
approximation of a final system or product) is built, tested, and then reworked as necessary until

an acceptable prototype is finally achieved from which the complete system or product can now
be developed. This model works best in scenarios where not all of the project requirements are
known in detail ahead of time. It is an iterative, trial-and-error process that takes place between
the developers and the users.
Mock up or model (throw away version) of a software product.
Used when customer defines a set of objective but does not identify input, output, or
processing requirements.
Developer is not sure of:

Efficiency of an algorithm.
Adaptability of an operating system.
Human/machine interaction.
Steps in Prototyping
The new system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the departments or aspects of the
existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics of
the final product.
The users thoroughly evaluate the first prototype, noting its strengths and weaknesses,
what needs to be added, and what should to be removed. The developer collects and
analyzes the remarks from the users.
The first prototype is modified, based on the comments supplied by the users, and a
second prototype of the new system is constructed.
The second prototype is evaluated in the same manner as was the first prototype.
The preceding steps are iterated as many times as necessary, until the users are satisfied
that the prototype represents the final product desired.
The final system is constructed, based on the final prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried out
on a continuing basis to prevent large-scale failures and to minimize downtime.

Figure: The Prototype Model

Steps in Prototyping In Short
Begins with requirement gathering.
Identify whatever requirements are known.
Outline areas where further definition is mandatory.
Quick designs occur.
Quick design leads to the construction of prototype.
Prototype is evaluated by the customer.
Requirements are refined.
Prototype is turned to satisfy the needs of customer.
Advantages
Reduced time and costs.
Improved and increased user involvement.
Disadvantages
Insufficient analysis.

User confusion of prototype and finished system.

Developer misunderstanding of user objectives.
Developer attachment to prototype.
Excessive development time of the prototype.
Expense of implementing prototyping.
Limitation of Prototyping
In a rush to get it working, overall software quality or long term maintainability are
generally overlooked.
Use of inappropriate OS or PL.
Use of inefficient algorithm.
The Spiral Model

An evolutionary model which combines the best feature of the classical life cycle and the
iterative nature of prototype model
Include new element : Risk element
Starts in middle and continually visits the basic tasks of communication, planning,
modeling, construction and deployment
Realistic approach to the development of large scale system and software
Software evolves as process progresses
Better understanding between developer and customer
The first circuit might result in the development of a product specification
Subsequent circuits develop a prototype
And sophisticated version of software

Figure: The Spiral Model
Advantages
Changing requirements can be accommodated.

Allows for extensive use of prototypes.
Requirements can be captured more accurately.
Users see the system early.
Development can be divided into smaller parts and more risky parts can be developed
earlier which helps better risk management.
Disadvantages

Management is more complex.

End of project may not be known early.
Not suitable for small or low risk projects (expensive for small projects).
Process is complex.
Spiral may go indefinitely.
Large number of intermediate stages requires excessive documentation.
Problems in Evolutionary Process

Difficult in project planning.
Speed of evolution is not known.
Does not focus on flexibility and extensibility (more emphasis on high quality).
Requirement is balance between high quality and flexibility and extensibility.
The Unified Process

Evolved by Rumbaugh, Booch, and Jacobson.
Combines the best features of their Object Oriented models.
Adopts additional features proposed by other experts.
Resulted in Unified Modeling Language (UML).
Unified process developed Rumbaugh and Booch.
A framework for Object-Oriented Software Engineering using UML.
Phases of Unified Process

Inception phase
Elaboration phase
Construction phase
Transition phase

Figure: The Unified Process Model
Tasks which are required to be completed during different phases

Inception Phase
Vision Document.
Initial Use-Case Model.
Initial Project Glossary.
Initial Business Case.
Initial Risk Assessment.
Project Plan with phases and Iterations.
Business Model.
Elaboration Phase
Use-Case model.
Supplementary Requirements [Including non functional].
Analysis model.

Software Architecture Description.

Executable Architectural Prototype.
Preliminary Design Model.
Revised Risk List.
Preliminary User Manual
Project Plan [Iteration plan, Workflows, Milestones, Technical Work
Products]
Construction Phase
Design Model.
System Components.
Integrated Software Increment.
Test plan and procedure.
Test cases.
Manuals [User, Installation, Current Increment].
Transition Phase
Delivered software increment
Beta test results
General user feedback

EID303 SE UNIT I Lecture Notes 3B5

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

EID303 SE UNIT I Lecture Notes 3B5

Uploaded by

Copyright:

Available Formats

LECTURE

Syllabus included in UNIT I:

Introduction to Software Engineering: Software, software engineering, the changing nature of

Characteristics of Software Engineering:

Different Definitions of Software Engineering:

3/4 B.Tech B5, Department of Computer Science, GU Page 2 of 26

Software Engineering is a systematic approach to development, operation, maintenance

The Evolving Role of the Software Softwares Dual Role

Software - New Categories

3/4 B.Tech B5, Department of Computer Science, GU Page 3 of 26

3/4 B.Tech B5, Department of Computer Science, GU Page 4 of 26

Software Engineering A Layered Approach

Figure: Layers of Software.

Figure: The Process Framework

3/4 B.Tech B5, Department of Computer Science, GU Page 5 of 26

Used as a basis for the description of process models.

CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

3/4 B.Tech B5, Department of Computer Science, GU Page 6 of 26

Levels are called capability levels.

CMMI currently addresses three areas of interest:

Product and service development CMMI for Development (CMMI-DEV),

Process Areas required to achieve a Maturity Model

3/4 B.Tech B5, Department of Computer Science, GU Page 7 of 26

LEVELS DESSCRIPTION PROCESSAREAS / ACTIVITIES

Figure: Process areas required to achieve a Maturity Level.

Figure: Levels of CMMI Model with Umbrella Activities [Process Areas]

3/4 B.Tech B5, Department of Computer Science, GU Page 8 of 26

3/4 B.Tech B5, Department of Computer Science, GU Page 9 of 26

Software Process is defined as collection of Patterns.

3/4 B.Tech B5, Department of Computer Science, GU Page 10 of 26

Figure: The Process Assessment

Approaches to Software Process Assessments.

Personal and Team Software Process

3/4 B.Tech B5, Department of Computer Science, GU Page 11 of 26

Team software process

Help in the software development.

The Classic Model / The Linear Model / the Waterfall Model

3/4 B.Tech B5, Department of Computer Science, GU Page 12 of 26

Begins with customer specification of Requirements and progresses through planning,

3/4 B.Tech B5, Department of Computer Science, GU Page 13 of 26

Figure: The Waterfall Model.

It is difficult to measure progress within stages.

3/4 B.Tech B5, Department of Computer Science, GU Page 14 of 26

Attempt to go back 2 or more phases is very costly.

The Incremental Process Model

3/4 B.Tech B5, Department of Computer Science, GU Page 15 of 26

Figure: The incremental Model

3/4 B.Tech B5, Department of Computer Science, GU Page 16 of 26

More resources may be required.

The RAD Model (Rapid Application Development)

3/4 B.Tech B5, Department of Computer Science, GU Page 17 of 26

Figure: The RAD Model

Time to deliver is less.

Management complexity is more.

3/4 B.Tech B5, Department of Computer Science, GU Page 18 of 26

Requires user involvement throughout the life cycle.

Evolutionary Process Models

3/4 B.Tech B5, Department of Computer Science, GU Page 19 of 26

Developer is not sure of:

3/4 B.Tech B5, Department of Computer Science, GU Page 20 of 26

Figure: The Prototype Model

3/4 B.Tech B5, Department of Computer Science, GU Page 21 of 26

User confusion of prototype and finished system.