UNIT-I

INTRODUCTION OF SOFTWARE ENGINEERING

Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific
principles and methods.
Software engineering is an engineering branch associated with development of software
product using well-defined scientific principles, methods and procedures. The outcome of
software engineering is an efficient and reliable software product.

Defination: The application of a systematic,disciplined,quantifiable approach to the

development,operation and maintenance of software; that is, the application of engineering to
software.

Software Evolution The process of developing a software product using software engineering
principles and methods is referred to as software evolution. This includes the initial
development of software and its maintenance and updates, till desired software product is
developed, which satisfies the expected requirements.
Evolution starts from the requirement gathering process. After which developers create a
prototype of the intended software and show it to the users to get their feedback at the early
stage of software product development. The users suggest changes, on which several
consecutive updates and maintenance keep on changing too. This process changes to the
original software, till the desired software is accomplished.

Even after the user has desired software in hand, the advancing technology and the changing
requirements force the software product to change accordingly. Re-creating software from
scratch and to go one-on-one with requirement is not feasible. The only feasible and economical
solution is to update the existing software so that it matches the latest requirements.
The Process Framework

A process was defined as a collection of work activities, actions, and tasks that are performed
when some work product is to be created. Each of these activities, actions, and tasks resides
within a framework or model that defines their relationship with the process and with one
another. The software process is represented schematically in Figure
.Referring to the figure, each framework activity is populated by a set of software engineering
actions. Each software engineering action is defined by a task set that identifies the work tasks
that are to be completed, the work products that will be pro-duced, the quality assurance points
that will be required, and the milestones that will be used to indicate progress

A generic process framework for software engi-neering defines five framework activities—
communication, planning, modeling, construction,and deployment.In addition, a set of umbrella
activities—project tracking and control, risk management, quality assurance, configuration man-
agement, technical reviews, and others—are applied throughout the process. You should note
that one important aspect of the software process has not yet been discussed. This aspect—called
process flow—describes how the frame-work activities and the actions and tasks that occur
within each framework ac-tivity are organized with respect to sequence and time and is
illustrated in Figure a
A linear process flow executes each of the five framework activities in se-quence, beginning
with communication and culminating with deployment .Shown in the fig b

An iterative process flow repeats one or more of the activities before proceeding to the next. The
fig is shown
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 . Shown in Fig c

A parallel process flow( Figure d is shown) 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 con-
struction of another aspect of the software).
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 stake-holder. 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.
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, elici-tation, elaboration, negotiation, specification, and validation. Each of
these soft-ware engineering actions would have many work tasks and a number of distinct work
products.

Every software team encounters problems as it moves through the software pro-cess. It would be
useful if proven solutions to these problems were readily avail-able to the team so that the
problems could be addressed and resolved quickly. A process pattern1describes a process-related
problem that is encountered during software engineering work, identifies the environment in
which the problem has been encountered, and suggests one or more proven solutions to the
problem. Stated in more general terms, a process pattern provides you with a template a
consistent method for describing problem solutions within the con-text of the software process.
By combining patterns, a software team can solve problems and construct a process that best
meets the needs of a project. Patterns can be defined at any level of abstraction. In some cases, a
pattern might be used to describe a problem (and solution) associated with a complete process
model (e.g., prototyping). In other situations, patterns can be used to describe a problem (and
solution) associated with a framework activity (e.g.,planning) or an action within a framework
activity (e.g., project estimating). Ambler has proposed a template for describing a process
pattern:

Pattern Name.The pattern is given a meaningful name describing it within the context of the
software process (e.g., Technical Reviews).
Forces the environment in which the pattern is encountered and the issues that make the
problem visible and may affect its solution.
Type.The pattern type is specified. Ambler suggests three types:
1.Stage pattern—defines a problem associated with a framework activity for the process. Since
a framework activity encompasses multiple actions and work tasks, a stage pattern incorporates
mul-tiple task patterns (see the following) that are relevant to the stage (framework activity). An
example of a stage pattern might be Establishing Communication. This pattern would
incorporate the task pattern Requirements Gathering and others.
2. Task pattern—defines a problem associated with a software engineer-ing action or work task
and relevant to successful software engineering practice (e.g., Requirements Gathering is a task
pattern).

3. Phase pattern—define the sequence of framework activities that occurs within the process,
even when the overall flow of activities is iterative in nature. An example of a phase pattern
might be Spiral Modeler Prototyping

Initial Context. Describes the conditions under which the pattern applies. Prior to the initiation
of the pattern: (1) What organizational or team-related activities have already occurred? (2) What
is the entry state for the process? (3) What software engineering information or project
information already exists?
For example, the Planning pattern (a stage pattern) requires that (1) custom-ers and software
engineers have established a collaborative communication; (2) successful completion of a
number of task patterns [specified] for the Communication pattern has occurred; and (3) the
project scope, basic business requirements, and project constraints are known

Problem.The specific problem to be solved by the pattern.

Solution. Describes how to implement the pattern successfully. This section describes how the
initial state of the process (that exists before the pattern is implemented) is modified as a
consequence of the initiation of the pattern. It also describes how software engineering
information or project informa-tion that is available before the initiation of the pattern is
transformed as a consequence of the successful execution of the pattern.

Resulting Context. Describes the conditions that will result once the pattern has been
successfully implemented. Upon completion of the pattern: (1) What organizational or team-
related activities must have occurred? (2) What is the exit state for the process? (3) What
software engineering information or project information has been developed?

Related Patterns. Provide a list of all process patterns that are directly related to this one. This
may be represented as a hierarchy or in some other diagrammatic form. For example, the stage
pattern Communication encom-passes the task patterns: Project Team, Collaborative Guidelines
,Scope Isolation, Requirements Gathering, Constraint Description, and Scenario Creation

.Known Uses and Examples.

Indicate the specific instances in which the pattern is applicable. For example, Communications
mandatory at the beginning of every software project, is recommended throughout the software
project, and is mandatory once the Deployment activity is under way.

Process patterns provide an effective mechanism for addressing problems associated with any
software process. The patterns enable you to develop a hier-archical process description that
begins at a high level of abstraction (a phase pattern). The description is then refined into a set of
stage patterns that describe framework activities and are further refined in a hierarchical fashion
into more detailed task patterns for each stage pattern. Once process patterns have been
developed, they can be reused for the definition of process variants—that is, a customized
process model can be defined by a software team using the patterns as building blocks for the
process model.

PROCESS ASSESSMENT AND IMPROVEMENT

The process assessment is to ensure that it meets a set of basic process criteria that have been
shown to be essential for a successful software engineering. A number of different approaches to
software process assessment have been proposed over the past few decades:

1. Standard CMMI Assessment Method for Process Improvement (SCAMPI) provides a

five—step process assessment model that incorporates initiating, diagnosing, establishing,
acting, and learning. The SCAMPI methods use the SEI CMMI as the basis for assessment.

i. SPICE (ISO/IEC 15504) Standard defines a set of requirements for software process
assessment. The intent of the standard is to assist organization in developing an objective
evaluation of the efficacy of any defined software process.

ii. ISO9001: 2000 for Software is a generic standard that applies to any organization that wants
to improve overall quality of the products, systems, or services that it provides. Therefore, the
standard is directly applicable to software organizations and companies.

The Capability Maturity Model Integration (CMMI)

The Software Engineering Institute (SEI) has developed a comprehensive process meta-model
that is predicated on a set of system and software engineering capabilities that should be present
as organizations reach different levels of process capability and maturity. To achieve these
capabilities, the SEI contends that an organization should develop a process model that confirms
to The Capability Maturity Model Integration (CMMI) guidelines.

The CMMI represents a process meta-model in two different ways: (1) as a Continuous model
and (2) as a staged model. The continuous CMMI meta- model describes a process in two
dimensions. Each process area (e.g., project planning or requirement) is formally assessed
against specific goals and practices and is rated according to the following capability levels:

Level 0: Incomplete. The process area (e.g., requirements management) is either not performed
or does not achieve all goals and objectives defined by the CMMI for level capability.

Level 1: Performed. All of the specific goals of the process area (as defined by the CMMI) have
been satisfied. Work tasks required to produce defined work products are being conducted.

Level 2: Managed. All level I criteria have been satisfied. In addition, all work associated with
the process area conforms to an organizationally defined policy; all people doing the work have
access to adequate resources to get the job done; stakeholders are actively involved in the
process area as required; all work tasks and work products are “monitored, controlled, and
reviewed; and are evaluated for adherence to the process description”.

Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is “tailored
from the organization’s set of standard processes according to the organization’s tailoring
guidelines, and contributes work products, measures, and other process-improvement
information to the organizational process assets.”

Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, the
process area is controlled and improved using measurement and quantitative assessment.
“Quantitative objectives for quality and process performance are established and used as criteria
in managing the process.”

Level 5: Optimized. All capability level 4 criteria have been achieved. In addition the process
area is adapted and optimized using quantitative (statistical) means to meet changing customer
needs and to continually improve the efficacy of the process area under consideration.”
Mark Paulk: “Much of the software crisis is self- inflicted, as when a C10 says, I’d rather it
wrong than have it late. We can always fix it later.”

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 to be effective. Specific practices refine a goal into a set of
process- related activities.

For example, project planning is one of eight process areas defined by the CMMI for the “project
management” category. The specific goal (SG) and the associated specific practices ( SP)
defined for project planning are:

SG 1 Establish estimates

SP 1, 1-1 Estimate the scope of the project

SP 1, 2-1 Establish estimates of work product and task attributes
SP 1, 3-1 Define project life cycle
SP 1, 4-1 Determine estimates of effort and cost

SG 2 Develop a Project Plan

SP 2, 1-1 Establish the budget and schedule

SP 2, 2-1 Identify project risks
SP 2, 3-1 Plan for data management
SP 2, 4-1 Plan for project resources
SP 2, 5-1 Plan for needed knowledge and skills
SP 2, 6-1 Plan stakeholder involvement
SP 2, 7-1 Establish the project plan

SG 3 Obtain commitment to the plan

SP 3, 1-1 Review plans that affect the project

SP 3, 2-1 Reconcile work and resource levels
SP 3, 3-1 Obtain plan commitment

In addition to specific goals and practices, the CMMI also defines a set of five generic goals and
related practices for each process area. Each of the five generic goals corresponds to one of the
five capability level, the generic goal for that level and the generic practices that correspond to
that goal must be achieved. To illustrate, the generic goals (SG) and practices (GP) for the
project planning process area are:

GG 1 Achieve specific goals

GP 1.1 perform base practices

GG 2 Institutionalize a managed process

GP 2.1 Establish an organizational policy

GP 2.2 Plan the process
GP 2.3 Provide resources
GP 2.4 Assign responsibility
GP 2.5 Train people
GP 2.6 Manage configurations
GP 2.7 Identify and involve relevant stakeholders
GP 2.8 Monitor and control the process
GP 2.9 Objectively evaluate adherence
GP 2.10 Review status with higher level management

GG 3 Institutionalize a defined process

GP 3.1 Establish a defined process

GP 3.2 Collect improvement information

GG 4 Institutionalize a quantitatively managed process

GP 4.1 Establish quantitative objectives for the process

GP 4.2 Stabilize sub-process performance

GP 5 institutionalize an optimizing process

GP 5.1 Ensure continuous process improvement

GP 5.2 Correct root causes of problems

The staged CMMI model defines the same process areas, goals, and practices as the continuous
model. The primary difference is that the staged model defines five maturity levels, rather than
five capability levels. To achieve a maturity level, the specific goals and practices associated
with a set of process areas must be achieved. The relationship between maturity levels and
process areas is shown.
PROCESS MODELS

A prescriptive process model strives for structure and order in software devel-opment. Activities
and tasks occur sequentially with defined guidelines for progress. We call them “prescriptive”
because they prescribe a set of process elements—framework activities, software engineering
actions, tasks, work prod-ucts, 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.

The Waterfall Model

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed before the next phase can begin and there is no overlapping in the
phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts
as the input for the next phase sequentially.

The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are −

 Requirement Gathering and analysis − All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification
document.
 System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying hardware
and system requirements and helps in defining the overall system architecture.
 Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model, phases do not overlap.
Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are −

 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
Evolutionary Process Models

 Evolutionary models are iterative type models.

 They allow to develop more complete versions of the software.

Following are the evolutionary process models.

1. The prototyping model

2. The spiral model
3. Concurrent development model

1. The Prototyping model

 Prototype is defined as first or preliminary form using which other forms are copied or
derived.
 Prototype model is a set of general objectives for software.
 It does not identify the requirements like detailed input, output.
 It is software working model of limited functionality.
 In this model, working programs are quickly produced.

The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the software.
2. Quick design

 Quick design is implemented when requirements are known.

 It includes only the important aspects like input and output format of the software.
 It focuses on those aspects which are visible to the user rather than the detailed plan.
 It helps to construct a prototype.

3. Modeling quick design

 This phase gives the clear idea about the development of software because the software is
now built.
 It allows the developer to better understand the exact requirements.

4. Construction of prototype
The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedback

 If the user is not satisfied with current prototype then it refines according to the
requirements of the user.
 The process of refining the prototype is repeated until all the requirements of users are
met.
 When the users are satisfied with the developed prototype then the system is developed
on the basis of final prototype.

Advantages of Prototyping Model

 Prototype model need not know the detailed input, output, processes, adaptability of
operating system and full machine interaction.
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system by the user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the confusing or difficult
functions.

Disadvantages of Prototyping Model:

 The client involvement is more and it is not always considered by the developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a thrown away prototype when the users are confused with it.
2. The Spiral model

 Spiral model is a risk driven process model.

 It is used for generating the software projects.
 In spiral model, an alternate solution is provided if the risk is found in the risk analysis,
then alternate solutions are suggested and implemented.
 It is a combination of prototype and sequential model or waterfall model.
 In one iteration all activities are done, for large project's the output is small.

The framework activities of the spiral model are as shown in the following figure.

NOTE: The description of the phases of the spiral model is same as that of the process model.

Advantages of Spiral Model

 It reduces high amount of risk.

 It is good for large and critical projects.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.

Disadvantages of Spiral Model

 It can be costly to develop a software model.

 It is not used for small projects.
3. The concurrent development model

 The concurrent development model is called as concurrent model.

 The communication activity has completed in the first iteration and exits in the awaiting
changes state.
 The modeling activity completed its initial communication and then go to the
underdevelopment state.
 If the customer specifies the change in the requirement, then the modeling activity moves
from the under development state into the awaiting change state.
 The concurrent process model activities moving from one state to another state.

Advantages of the concurrent development model

 This model is applicable to all types of software development processes.

 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.

Disadvantages of the concurrent development model

 It needs better communication between the team members. This may not be achieved all
the time.
 It requires to remember the status of the different activities.
Agile View of Process

Agility:

Agility has become today’s buzzword when describing a modern software process. Everyone is
agile. An agile team is a nimble team able to appropriately respond to changes. Change is what
software development is very much about. Changes in the software being built, changes to the
team members, changes because of new technol-ogy, changes of all kinds that may have an
impact on the product they build or the project that creates the product. Support for changes
should be built-in everything we do in software, something we embrace because it is the heart
and soul of software. An agile team recognizes that software is developed by individuals
working in teams and that the skills of these people, their ability to collaborate is at the core for
the success of the project.

Agile process:

Agile is a software development methodology to build a software incrementally using short

iterations of 1 to 4 weeks so that the development process is aligned with the changing business
needs. Instead of a single-pass development of 6 to 18 months where all the requirements and
risks are predicted upfront, Agile adopts a process of frequent feedback where a workable
product is delivered after 1 to 4 week iteration.
Agility Principles

The Agile Alliance defines 12 agility principles for those who want to achieve agility:
1.Our highest priority is to satisfy the customer through early and continu-ous delivery of
valuable software.
2.Welcome changing requirements, even late in development. Agile pro-cesses 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.
7.Working software is the primary measure of progress.
8.Agile processes promote sustainable development. The sponsors, devel-opers, 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.

Agile Process Models:

Scrum is a framework for developing and sustaining complex products. Ken Schwaber and Jeff
Sutherland developed Scrum. Together, they stand behind the Scrum Rules.

Scrum Definition

Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.

Scrum is a process framework that has been used to manage complex product development since
the early 1990s. Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and development practices so that you can
improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to
Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and
interaction between them. The rules of Scrum are described throughout this tutorial.

Note - Across the industry, there are misconceptions that Scrum means no documentation, scrum
team consists of only developers, and so on. It is not entirely so; we will give clarifications on
these in later sections.

Scrum Process Framework

Sprint

The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially
releasable product increment is created. A new Sprint starts immediately after the conclusion of
the previous Sprint. Sprints consist of the Sprint planning, daily scrums, the development work,
the Sprint review, and the Sprint retrospective.
  In Sprint planning, the work to be performed in the Sprint is planned collaboratively by
the Scrum Team.
 The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to
synchronize the activities and create a plan for that day.
 A Sprint Review is held at the end of the Sprint to inspect the Increment and make
changes to the Product Backlog, if needed.
 The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for
improvements to be enacted during the subsequent Sprint.

Conclusion

Scrum is a process framework that defines certain rules, events, and roles to bring in regularity.
However, it can be adapted to any organization, based on needs, provided the basic scrum rules
are not violated.

Extreme Programming (XP)

It is a type of agile software development. It advocates frequent releases in short development

cycles, which is intended to improve productivity and introduce checkpoints where new
customer requirements can be adopted. The methodology takes its name from the idea that the
beneficial elements of traditional software engineering practices are taken to extreme levels.
(Extreme Programming is a software-development discipline that organizes people to produce
higher-quality software more productively.) XP addresses the analysis, development, and test
phases with novel approaches that make a substantial difference to the quality of the end-
product.

Dynamic Systems Development Method (DSDM)

DSDM is an agile software development methodology. It is an iterative, incremental approach

that is largely based on the Rapid Application Development (RAD ) methodology. The method
provides a four-phase framework consisting of:

 Feasibility and business study

 Functional model / prototype iteration
 Design and build iteration
 Implementation

Within each phase, DSDM relies on several different activities and techniques based on these
principles:

 Projects evolve best through direct and co-located collaboration between the developers
and the users.
 Self-managed and empowered teams must have the authority to make time sensitive and
critical project-level decisions.
 Design and development is incremental and evolutionary in nature and is largely driven
by regular, iterative user feedback.
 Working software deliverables are defined as systems that address the critical, current
business needs versus systems that address less critical future needs.
 Frequent and incremental delivery of working software is valued over infrequent delivery
of perfectly working software.
 All changes introduced during development must be reversible.