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 user’s viewpoint, the
work product is the resultant information that somehow makes the user’s world better.

Characteristics of Software Engineering:

 Software is developed or engineered. It is not manufactured in the classical sense.
 Software doesn’t 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 customer’s problem by the systematic
development and evolution of large, high quality software systems within cost, time and
other constraints.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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 – Software’s 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!)

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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
 Practitioner’s 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.

Practitioner’s 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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

Software Engineering – A Layered Approach

 Quality focus - Bedrock that supports software Engineering.
 Process - Foundation for software Engineering
 Methods - Provide technical how-to’s 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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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).

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

Process Areas Required to achieve a Maturity Model

LEVELS DESSCRIPTION PROCESSAREAS / ACTIVITIES

Figure: Process areas required to achieve a Maturity Level.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

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.

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

EID 303: Software Engineering LECTURE NOTES | UNIT I

 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

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