Introduction to Software Engineering

• Layered Technology
•Process

•Process Models
 Software
(1) instructions (programs) that when executed
provide desired function and performance,
(2) data structures that enable the programs to
adequately manipulate information,
(3) documents that describe the operation and use of
the programs.

Computer software is developed by applying a process that leads to a

high quality result that meets the needs of the people who will use the
product and the approach is called software engineering .
Software Characteristics
1. Software is developed or engineered, it is not
manufactured in the classical sense.
Quality in both is achieved through good design, but the
manufacturing phase for hardware can introduce quality
problems that are nonexistent (or easily corrected) for software.

2. Software doesn't "wear out.“

Failure Curve for Hardware
Hardware exhibits relatively high failure
rates early in its life (these failures are
often attributable to design or
manufacturing defects); defects are
corrected and the failure rate drops to a
steady-state level (ideally, quite low) for
some period of time.
As time passes, however, the failure rate
rises again as hardware components
suffer from the cumulative affects of dust,
vibration, abuse, temperature extremes,
and many other environmental maladies.
And the hardware begins to wear out.
Failure Curve for Software
Undiscovered defects will cause high
failure rates early in the life of a
program. However, these are
corrected and the curve flattens as
shown.
During its life, software will undergo
change (maintenance). As changes are
made, it is likely that some new defects
will be introduced, causing the failure
rate curve to spike. Before the curve
can return to the original steady-state
failure rate, another change is
requested, causing the curve to spike
again.
 Contd..
When a hardware component wears out, it is
replaced by a spare part.
There are no software spare parts. Every
software failure indicates an error in design or in
the process through which design was translated
into machine executable code.
3. Although the industry is moving toward
component-based assembly, most software
continues to be custom built.
The Changing Nature of Software
1. System software: os, drivers,n/w s/w,
compilers, editors etc.
2. Application S/w: Data Processing , real time
manufacturing control etc
3. Engineering/scientific S/w: Astronomy, CAD,
system simulation etc.
4. Embedded S/w: Digital functions in fuel
control, dashboard displays etc.
The Changing Nature of S/w
5. Product Line S/w: Inventory control / word
processing., multimedia etc.
6. Web Applications: e-commerce and B2B etc.
7. AI s/w: Robotics, expert systems, pattern
recognition etc.
8.Ubiquitous Computing: Distributed computing
allows the enterprise system to communicate
across vast n/w
Engineering
Engineering is the
1.analysis,

2.design,

3.construction,

4.verification, and

5.management of technical (or social) entities

Software Engineering
(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software;

(2) the application of engineering to software.

Software Engg: A Layered Technology
Software Engg: A Layered Tech.
1. Quality: Any engineering approach must rest
on commitment to quality. A continuous
process improvement fosters quality in a
product.

2. Process: defines a framework that establishes

the context in which technical methods are
applied, work products are produced,
milestones are established, quality is ensured.
Methods
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.
Tools
Software engineering tools provide automated
or semi-automated support for the process
and the methods.
CASE combines software, hardware, and a
software engineering database (a repository
containing important information about
analysis, design, program construction, and
testing) to create a software engineering
environment.
Process Framework
● A process framework establishes the foundation for a
complete software engineering process by identifying a
small number of framework activities that are applicable
to all software projects, regardless of their size or
complexity.
● Each framework activity is populated by a set of SE
actions- a collection of related tasks that produces a
major SE work product.
● In addition, the process framework encompasses a set of
umbrella activities that are applicable across the entire
software process.
Process Framework
 Elements of a Software Process
● A process is a collection of activities, actions, and tasks
that are performed when some work product is to be
created.
● An activity strives to achieve a broad objective (e.g.,
communication with stakeholders) and is applied
regardless of the application domain, size of the project,
complexity of the effort.
● An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an
architectural model).
● A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
Activity, Action and Task Set
TaskSet: Defines actual work to be done to accomplish the
objective of a SE action.
e.g. Requirement Gathering is a SE action that occurs
during Communication (Activity).
Task set: 1. Make a list of stakeholders
2. Discuss the requirements with them
3. Prioritize the requirements
4. Note areas of Uncertainty
 Generic Framework Activities
1. Communication: The intent is to understand stakeholders’
objectives for the project and to gather requirements that help defi
ne software features and functions
2. Planning: A software project plan—defines the software
engineering work by describing the technical tasks to be conducted,
the risks that are likely, the resources that will be required, the work
products to be produced, and a work schedule.
3. Modeling: A software engineer creates models to understand
software requirements and the design that will achieve those
requirements.
4. Construction: This activity combines code generation and the
testing that is required to uncover errors in the code.
5. Deployment: The software is delivered to the customer who
evaluates the delivered product and provides feedback based on the
evaluation.
 Umbrella Activities
Umbrella activities are applied throughout a software project and help a
software team manage and control progress, quality, change, and risk.

Typical umbrella activities include are:

•Software project tracking and control: allows the software team to
assess progress against the project plan and take any necessary action
to maintain the schedule.
•Risk management—assesses risks that may affect the outcome of the
project or the quality of the product.
•Software quality assurance—defines and conducts the activities
required to ensure software quality.
•Technical reviews—assess software engineering work products in an
effort to uncover and remove errors before they are propagated to the
next activity.
 Umbrella Activities Contd.

• Measurement—defines and collects process, project, and product

measures that assist the team in delivering software that meets
stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.
• Software configuration management—manages the effects of
change throughout the software process.
• Reusability management—defines criteria for work product reuse
(including software components) and establishes mechanisms to
achieve reusable components.
• Work product preparation and production—encompass the
activities required to create work products such as models,
documents, logs, forms, and lists.
 Process Flow
Process flow describes how the framework activities and the actions
and tasks that occur within each framework activity are organized
with respect to sequence and time.
1.A linear process flow executes each of the five framework activities
in sequence, beginning with communication and culminating with
deployment.
2.An iterative process flow repeats one or more of the activities before
proceeding to the next.
3. An evolutionary process flow executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more
complete version of the software.
4.A parallel process flow executes one or more activities in parallel
with other activities (e.g., modeling for one aspect of the software
might be executed in parallel with construction of another aspect of
the software)
Process Flows
How does a framework activity change as the nature of
the project changes?

For a small software project requested by one person (at a remote

location) with simple, straightforward requirements, the
communication activity might encompass little more than a
phone call or email with the appropriate stakeholder. Therefore,
the only necessary action is phone conversation, and the work
tasks (the task set) that this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and develop notes.
3. Organize notes into a brief written statement of requirements.
4. Email to stakeholder for review and approval.
 How does a framework activity change as the nature of
the project changes? Contd.

If the project was considerably more complex with many

stakeholders, each with a different set of (sometime
conflicting) requirements, the communication activity
might have six distinct actions :
●inception,

●elicitation,

●elaboration,

●negotiation, specification, and

●validation.

Each of these software engineering actions would have

many work tasks and a number of distinct work products.
 CMMI
Is a process meta model defined in 2 ways:
1. Staged Model: is used to assess the maturity of
an organization. It defines the maturity levels.
To achieve a maturity level, the specific goals
and practices associated with a set of process
areas must be achieved.
2. Continuous Model: Is more applicable to
assessment and improvement of process. Each
process area is formally assessed against
specific goals and specific practices. Generic
goals and practices are also achieved. I
 The CMMI
● Level 0 - Incomplete - process area is either not performed
or does not achieve all specified goals.
● Level 1 - Performed - All specific CMMI defined goals of
the process area have been satisfied
● Level 2-Managed - All work conforms to an organizationally
defined policy; all people doing the work have access to
adequate resources to get the job done; work tasks are
monitored, controlled and reviewed, evaluated for adherence
to the process description
● Level 3-Defined - process is tailored according to
organization’s tailoring guidelines. Work products,
measurements, etc… are contributed to the organizational
process assets
CMMI
● Level 4-Quantitatively managed - Process area uses
quantitative measurement to control and improve the process
area. Quantitative objectives for quality and performance are
established and used.

● Level 5 - Optimized - Process area adapted and optimized to

meet changing customer’s needs and continually improve the
process area
 The CMMI

The CMMI defines each process area in terms of

“specific goals” and the “specific practices” required
to achieve these goals.
● Specific goals establish the characteristics that must
exist if the activities implied by a process area are to
be effective. E.g. Establish Estimate
● Specific practices refine a goal into a set of
process-related activities.
● E.g. Estimate the scope of the project
● Establish the work products and task attributes
● Determine estimates of effort and cost
CMMI
Generic Goal1: Achieve specific goals
perform base practices
GG2: Institutionalize a managed process
Establish an organizational policy
Plan the process
Provide resources
Assign Responsibility
Train people
Identify stakeholders
 CMMI
GG3: Institutionalize a defined process
Establish a defined process
Collect improvement information
GG4:Institution quantitatively Managed process
Establish quantitative objectives for process
Stabilize sub-process improvement
GG5: Institutionalize an optimized process
Ensure Continuous process improvement
Correct root causes of problem
Software Process Maturity: CMM
Level 1: Initial. The software process is characterized as ad hoc
and occasionally even chaotic. Few processes are defined, and
success depends on individual effort.

Level 2: Repeatable. Basic project management processes are

established to track cost, schedule, and functionality. The
necessary process discipline is in place to repeat earlier successes
on projects with similar applications.

•Software configuration management

• Software quality assurance
• Software project tracking and oversight
• Software project planning
• Requirements management
CMM..

Level 3: Defined. The software process for both management &

engineering activities is documented, standardized, and
integrated into an organization wide software process. All
projects use a documented and approved version of the
organization's process for developing and supporting software.

• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
CMM..
Level 4: Managed. Detailed measures of the software process
and product quality are collected. Both the software process
and products are quantitatively understood and controlled
using detailed measures.
•Software quality management
• Quantitative process management

Level 5: Optimizing. Continuous process improvement is

enabled by quantitative feedback from the process and from
testing innovative ideas and technologies.
•Process change management
• Technology change management
• Defect prevention
KPA’s Characteristics
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization)
that must be met to achieve the goals or provide proof of intent
to comply with the goals.
• Abilities—those things that must be in place (organizationally
and technically) to enable the organization to meet the
commitments.
• Activities—the specific tasks required to achieve the KPA
function.
• Methods for monitoring implementation—the manner in
which the activities are monitored as they are put into place.
• Methods for verifying implementation—the manner in which
proper practice for the KPA can be verified.
Prescriptive Process model
● The prescriptive process models prescribe a
set of process elements—framework
activities, software engineering actions, tasks,
work products, quality assurance, and change
control mechanisms for each project.
● Each process model also prescribes a process
flow (also called a work flow)—that is, the
manner in which the process elements are
interrelated to one another.
Waterfall/Sequential model

The waterfall model, sometimes called the classic life cycle,

suggests a systematic, sequential approach to software development
that begins with customer specification of requirements and
progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed
software.
 Why does the waterfall model sometimes fail?
1.Real projects rarely follow the sequential flow that the model
proposes. Although the linear model can accommodate iteration, it
does so indirectly. As a result, changes can cause confusion as the
project team proceeds.
2. It is often difficult for the customer to state all requirements
explicitly. The waterfall model requires this and has difficulty
accommodating the natural uncertainty that exists at the beginning of
many projects.
3.The customer must have patience. A working version of the
program(s) will not be available until late in the project time span. A
major blunder, if undetected until the working program is reviewed,
can be disastrous.
4.Linear nature of the classic life cycle leads to “blocking states” in
which some project team members must wait for other members of
the team to complete dependent tasks.
V-Model
The Incremental Model
Incremental Model

● 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 though requirements
for later increments can continue to evolve.
Incremental Model
● 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
● The highest priority system services tend to receive the most
testing
 Evolutionary Process Models
● Evolutionary process models produce an increasingly more
complete version of the software with each iteration.
● Business and product requirements often change as development
proceeds, making a straight line path to an end product unrealistic.
● Process model that has been explicitly designed to accommodate a
product that grows and changes, is needed.
● Evolutionary models are iterative.
• Prototyping Model
• Spiral Model
Prototyping
 Prototyping
● The prototyping paradigm begins with communication. You meet
with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline
areas where further definition is mandatory.
● A prototyping iteration is planned quickly, and modeling (in the
form of a “quick design”) occurs.
● A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface
layout or output display formats).
● The quick design leads to the construction of a prototype.
● The prototype is deployed and evaluated by stakeholders, who
provide feedback that is used to further refine requirements.
 Prototyping

● Gather requirements
● Developer & customer define overall
objectives, identify areas needing more
investigation – risky requirements
● Quick design focusing on what will be visible
to user – input & output formats
● Use existing program fragments, program
generators to throw together working
version
● Prototype evaluated and requirements refined
 Prototyping

● Iteration occurs as the prototype is tuned to satisfy

the needs of various stakeholders, while at the same
time enabling you to better understand what needs
to be done.
● The process is iterated until customer & developer
satisfied
• then throw away prototype and rebuild system
to high quality
• alternatively can have evolutionary prototyping
– start with well understood requirements
 Prototyping Drawbacks

● Customer may want to hang onto first version, may

want a few fixes rather than rebuild. First version
will have compromises
● Developer may make implementation compromises
to get prototype working quickly. Later on
developer may become comfortable with
compromises and forget why they are inappropriate
RAD Model
 RAD Model
● Business modeling. What information drives the business
process? What information is generated? Who generates it?
Where does the information go? Who processes it?
● Data modeling identifies set of data objects that are needed to
support the business. The characteristics (called attributes) of
each object are identified and the relationships between these
objects defined.
● Process modeling. The data objects are transformed to achieve
the information flow necessary to implement a business function.
Processing descriptions are created for adding, modifying,
deleting, or retrieving a data object.
 RAD Model
● Application generation. RAD assumes the use of fourth
generation techniques. Rather than creating software.
● Testing and turnover. AS RAD emphasizes reuse, many of
the program components have already been tested. This
reduces overall testing time.
Spiral development
 Spiral Model
● The spiral model uses prototyping as a risk reduction mechanism
but, enables to apply the prototyping approach at any stage in the
evolution of the product. It maintains the systematic stepwise
approach suggested by the classic life cycle
● The spiral model demands a direct consideration of technical risks
at all stages of the project and, if properly applied, should reduce
risks before they become problem.
● Process is represented as a spiral rather than as a sequence of
activities with backtracking.
● The spiral model is a realistic approach to the development of
large-scale systems and software.
 Spiral Model
● Customer Communication – tasks required to establish
effective communication between developer and customer
● Planning – tasks required to define resources, timelines and
other project related information
● Risk Analysis – tasks required to assess both technical and
management risks
● Engineering – tasks required to build one or more
representations of the application
● Construction and Release – tasks required to construct, test,
install and provide user support (e.g. documentation & training)
● Deployment/customer evaluation – tasks required to get
customer feedback on evaluation of the software representations
created during the engineering stage and implemented during the
installation stage
Spirals in Model
● The first circuit around the spiral might result in the
development of a product specification;
● Subsequent passes around the spiral might be used to
develop a prototype and then progressively more
sophisticated versions of the software.
● Each pass through the planning region results in adjustments
to the project plan. Cost and schedule are adjusted based on
feedback derived from the customer after delivery.
● In addition, the project manager adjusts the planned number
of iterations required to complete the software.
Concurrent Development Model
Component based development Model
 Agile Process
Agility means quick to respond.
Agility is dynamic, content specific, aggressively change embracing,
and growth oriented.”
Agile process should respond to followings:
1. It is difficult to predict in advance which software requirements will
persist and which will change. It is equally difficult to predict how
customer priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved.
It is difficult to predict how much design is necessary before
construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable.
 Characteristics of an Agile Process
1. Unpredictability can be resolved by adaptability (to rapidly changing
project and technical conditions). An agile process, must be
adaptable.
2. An agile software process must adapt incrementally. An agile team
requires customer feedback so that the appropriate adaptations can
be made. An effective catalyst for customer feedback is an
operational prototype or a portion of an operational system.
3. Hence, an incremental development strategy should be instituted.
Software increments must be delivered in short time periods so that
adaptation keeps pace with change (unpredictability).
4. This iterative approach enables the customer to evaluate the
software increment regularly, provide necessary feedback to the
software team, and influence the process adaptations that are made
to accommodate the feedback.
 12 Agility Principles
1.Highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6.The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation.
 Agility Principles
7.Working software is the primary measure of progress.
8.Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity—the art of maximizing the amount of work, not
done—is essential.
11. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Scrum
● Scrum is an agile software development method
● Framework activities include:
● Requirements analysis, design, evolution, and delivery.
● Work tasks is called a sprint. The work conducted within a
sprint and the number of sprints required for each framework
activity will vary depending on product complexity and size.
● Scrum incorporates a set of process patterns that emphasize
project priorities, compartmentalized work units,
communication, and frequent customer feedback.
Scrum Process Flow
 Scrum Process Flow
Scrum incorporates a set of process patterns that emphasize project
priorities, compartmentalized work units, communication, and
frequent customer feedback.
●Backlog—a prioritized list of project requirements or features that

provide business value for the customer. Items can be added to the
backlog at any time (this is how changes are introduced). The
product manager assesses the backlog and updates priorities as
required.
●Sprints—consist of work units that are required to achieve a

requirement defined in the backlog that must be fit into a predefi ned
time-box 10 (typically 30 days). Changes (e.g., backlog work items)
are not introduced during the sprint. Hence, the sprint allows team
members to work in a short-term, but stable environment.
●
 Scrum Process Flow
Scrum meetings—are short (typically 15-minute) meetings held
daily by the Scrum team. Three key questions are asked and
answered by all team members
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and
assesses the responses from each person. The Scrum meeting helps
the team to uncover potential problems as early as possible.
Demos—deliver the software increment to the customer so that
implemented functionality can be demonstrated and evaluated by
the customer.