Unit 1

Software Engineering Lecture notes
UNIT -1
Unit 1
Introduction to Software Engineering: A generic view of Process: Software Engineering,
Process Framework, CMM Process Pattern, and Process Assessment.
Process Models: Perspective Models, Waterfall Model, Incremental Process Models, Evolutionary
Process Models, Specialized Process Model, the Unified Models.
An Agile view of Process: Introduction to Agility and Agile Process, Agile Process Model
INTRODUCTION TO SOFTWARE ENGINEERING
1.1 Software Engineering:

Software engineering is an engineering-style system of software development. A software
engineer is a person who applies the principles of software engineering to design, develop,
maintain, test, and evaluate computer software.
Software is a program or set of programs containing instructions that provide desired
functionality. And Engineering is the process of designing and building something that
serves a particular purpose and finds a cost-effective solution to problems.
LIET, Department of CSE | 1
Software engineering is the process of designing, developing, testing, and maintaining

software. It is a systematic and disciplined approach to software development that aims to
create high-quality, reliable, and maintainable software. Software engineering includes a
variety of techniques, tools, and methodologies, including requirements analysis, design,
testing, and maintenance.
1.2 Software Process Framework

It is an abstraction of the software development process. It details the steps and
chronological order of a process. Since it serves as a foundation for them, it is utilized in
most applications. Task sets, umbrella activities, and process framework activities all
define the characteristics of the software development process.
Software process includes:
 Tasks – focus on a small, specific objective.
 Action – set of tasks that produce a major work product.
 Activities – group of related tasks and actions for a major objective.

Software Process Framework
Process Framework Activities:
The process framework is required for representing common process activities. Five
framework activities are described in a process framework for software engineering.
Communication, planning, modeling, construction, and deployment are all examples of
framework activities. Each engineering action defined by a framework activity comprises a
list of needed work outputs, project milestones, and software quality assurance (SQA)
points.
Process framework activities are
 Communication: By communication, customer requirement gathering is done.
Communication with consumers and stakeholders to determine the system’s
objectives and the software’s requirements.
 Planning: Establish engineering work plan, describes technical risk, lists
resources requirements, work produced and defines work schedule.
 Modeling: Architectural models and design to better understand the problem and
for work towards the best solution. The software model is prepared by:
Analysis of requirements
Design
 Construction: Creating code, testing the system, fixing bugs, and confirming that
all criteria are met. The software design is mapped into a code by:
Code generation
Testing
 Deployment: In this activity, a complete or non-complete product or software is
represented to the customers to evaluate and give feedback. On the basis of their
feedback, we modify the product for the supply of better products.
Task Sets:
The task set defines the actual work done in order to achieve the software objective. The
task set is used to adopt the framework activities and project team requirements using
 Collection of software engineering work tasks.
 Project milestones.
 Software quality assurance points.
Umbrella activities:
Umbrella Activities are that take place during a software development process for improved
project management and tracking

1. Software project tracking and control: This is an activity in which the team can
assess progress and take corrective action to maintain the schedule. Take action to
keep the project on time by comparing the project’s progress against the plan.
2. Risk management: The risks that may affect project outcomes or quality can be
analyzed. Analyze potential risks that may have an impact on the software
product’s quality and outcome.
3. Software quality assurance: These are activities required to maintain software
quality. Perform actions to ensure the product’s quality.
4. Formal technical reviews: It is required to assess engineering work products to
uncover and remove errors before they propagate to the next activity. At each
level of the process, errors are evaluated and fixed.
5. Software configuration management: Managing of configuration process when
any change in the software occurs.
6. Work product preparation and production: The activities to create models,
documents, logs, forms, and lists are carried out.
7. Reusability management: It defines criteria for work product reuse. Reusable
work items should be backed up, and reusable software components should be
achieved.
8. Measurement: In this activity, the process can be defined and collected. Also,
project and product measures are used to assist the software team in delivering the
required software.
1.3 Capability maturity model (CMM)
The CMMI The original Capability Maturity Model (CMM) was developed and upgraded
by the Software Engineering Institute throughout the 1990s as a complete SPI framework.
Today, it has evolved into the Capability Maturity Model Integration (CMMI) [CMM18], 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.
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 as illustrated in Figure .
Each process area (e.g., project planning or requirements management) 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 1
capability for the process area.
Level 1: Performed. All 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 capability level 1 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 capability 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 capability 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.
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. Specific practices refine a goal into
a set of process-related activities. 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 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 in Figure .
A software process, no matter how well conceived, will not succeed without talented,
motivated software people. The People CMM suggests practices that improve the workforce
competence and culture [CMM18a]. The goal of the People CMM is to encourage continuous
improvement of generic workforce knowledge (called “core competencies”), specific
software engineering and project management skills (called “workforce competencies”), and
process-related abilities. Like the CMMI, the People CMM defines a set of five
organizational maturity levels that provide an indication of the relative sophistication of
workforce practices and processes
1.4 Software Process Assessment

Software Process Assessment is a disciplined and organized examination of the software

process which is being used by any organization bases the on the process model. The
Software Process Assessment includes many fields and parts like identification and
characterization of current practices, the ability of current practices to control or avoid
significant causes of poor (software) quality, cost, schedule and identifying areas of strengths
and weaknesses of the software.
Types of Software Assessment :
 Self-Assessment : This is conducted internally by the people of their own organization.

 Second Party assessment: This is conducted by an external team or people of the own
organization are supervised by an external team.
 Third Party assessment:
In an ideal case Software Process Assessment should be performed in a transparent, open
and collaborative environment. This is very important for the improvement of the software
and the development of the product. The results of the Software Process Assessment are
confidential and are only accessible to the company. The assessment team must contain at
least one person from the organization that is being assessed.
Software Process Maturity Assessment:
The scope of Software Process Assessment includes many components like it should cover
all the processes in the organization, a selected subset of the software process or a specific
project. The idea of process maturity serves as the foundation for the majority of standard-
based process evaluation methodologies.
Though an organization is the assessment objective, even when the same approach is applied
again, the outcomes of a process evaluation may vary. The different results are mainly due to
two reasons. The reasons are that the organization that is being investigated must be
determined. When the company is very large it is possible for the company to have different
definitions due to which the actual scope of appraisal may be different in successive
assessments. Even if it is the same organization the sample of projects selected to represent
the organization may affect the scope and result. Process maturity is important when the
organization intended to embark on an long term improvement strategy.
Software Process Cycle:
Generally there are six different steps in the complete cycle:
 Selecting a team: The first step is to select all the team members. Everyone must be
software professionals with sound knowledge in software engineering.
 The standard process maturity questionnaire is filled out by the representatives of the site
that will be evaluated.
 In accordance with the CMM core process areas, the assessment team analyses the
questionnaire results to determine the areas that call for additional investigation.

 The evaluation team visits the location to learn more about the software procedures used
there.
 The evaluation team compiles a set of results outlining the organization’s software
process’s advantages and disadvantages.
 In order to deliver the findings to the right audience, the assessment team creates a Key
Process Area (KPA) profile analysis.
SCAMPI;
SCAMPI stands for Standard CMMI Assessment Method for Process Improvement. To fulfil
the demands of the CMMI paradigm, the Standard CMMI Assessment Method for Process
Improvement (SCAMPI) was created (Software Engineering Institute, 2000). Moreover, it is
based on the CBA IPI. The CBA IPI and SCAMPI both have three steps.
1. Plan and become ready
2. Carry out the evaluation on-site
3. Report findings
The planning and preparation phase includes the following activities:
 Describe the scope of the evaluation.
 Create the assessment strategy.
 Get the evaluation crew ready and trained.
 Make a quick evaluation of the participants.
 CMMI Appraisal Questionnaire distribution
 Look at the survey results.
 Perform a preliminary document evaluation.
The onsite evaluation phase includes the following activities:
 Display the results.
 Execute the findings.
 Complete / end the assessment.
PROCESS MODELS
A software process model is an abstraction of the software development process. The models
specify the stages and order of a process. So, think of this as a representation of the order of
activities of the process and the sequence in which they are performed.
A model will define the following:
 The tasks to be performed

 The input and output of each task
 The pre and post-conditions for each task

 The flow and sequence of each task
The goal of a software process model is to provide guidance for controlling and coordinating
the tasks to achieve the end product and objectives as effectively as possible.
There are many kinds of process models for meeting different requirements. We refer to these
as SDLC models (Software Development Life Cycle models).
1.5 Prescriptive Process Models

Prescriptive process models define a predefined set of process elements and a predictable
process work flow. Prescriptive process models strive for structure and order in software
development. Activities and tasks occur sequentially with defined guidelines for progress.
But are prescriptive models appropriate for a software world that thrives on change? If we
reject traditional process models (and the order they imply) and replace them with something
less structured, do we make it impossible to achieve coordination and coherence in software
work?
There are no easy answers to these questions, but there are alternatives available to software
engineers. In the sections that follow, we provide an overview of the prescriptive process
approach in which order and project consistency are dominant issues. We call them
“prescriptive” because they 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.
All software process models can accommodate the generic framework activities described
in Chapter 1, but each applies a different emphasis to these activities and defines a process
flow that invokes each framework activity (as well as software engineering actions and tasks)
in a different manner. In Chapters 3 and 4 we will discuss software engineering practices that
strive to accommodate the changes that are inevitable during the development of many
software projects.
1.5.1 The Waterfall Model

There are times when the requirements for a problem are well understood—when work
flows from communication through deployment in a reasonably linear fashion. This situation
is sometimes encountered when well-defined adaptations or enhancements to an existing
system must be made (e.g., an adaptation to accounting software because it needs to
accommodate changes to mandated government regulations). It may also occur in a limited

number of new development efforts, but only when requirements are well defined and
reasonably stable.
The waterfall model, sometimes called the linear sequential model, suggests a systematic,
sequential approach3 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 (Figure).
Figure Waterfall Model
The waterfall model is the oldest paradigm for software engineering. However, over the
past five decades, criticism of this process model has caused even ardent supporters to
question its efficacy. Among the problems that are sometimes encountered when the waterfall
model is applied are:
1. Real projects rarely follow the sequential work flow that the model proposes.
2. It is often difficult for the customer to state all requirements explicitly at the
beginning of most projects.
3. The customer must have patience because a working version of the program(s) will
not be available until late in the project time span.
4. Major blunders may not be detected until the working program is reviewed. Today,
software work is fast paced and subject to a never-ending stream of changes (to
features, functions, and information content). The waterfall model is often
inappropriate for such work.
Some of the major advantages of the Waterfall Model are as follows −

 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
Waterfall Model - Disadvantages
The disadvantage of waterfall development is that it does not allow much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.
1.5.2 Incremental Process Model

Incremental Model is a process of software development where requirements divided into
multiple standalone modules of the software development cycle. In this model, each module
goes through the requirements, design, implementation and testing phases. Every subsequent
release of the module adds function to the previous release. The process continues until the
complete system achieved.

The various phases of incremental model are as follows:
1. Requirement analysis: In the first phase of the incremental model, the product analysis
expertise identifies the requirements. And the system functional requirements are understood
by the requirement analysis team. To develop the software under the incremental model, this
phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of
the system functionality and the development method are finished with success. When
software develops new practicality, the incremental model uses style and development phase.
3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various methods
are used to test the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the development

system. It involves the final coding that design in the designing and development phase and
tests the functionality in the testing phase. After completion of this phase, the number of the
product working is enhanced and upgraded up to the final system product

When we use the Incremental Model?

o When the requirements are superior.
o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
o You can develop prioritized requirements first.
Advantage of Incremental Model

o Errors are easy to be recognized.
o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.
Disadvantage of Incremental Model

o Need for good planning
o Total Cost is high.
o Well defined module interfaces are needed.
1.5.3 Evolutionary Process Model

Software, like all complex systems, evolves over time. Business and product
requirements often change as development proceeds, making a straight-line path to an end
product unrealistic. Tight market deadlines may make completion of a comprehensive
software product impossible. It might be possible to create a limited version of a product to
meet competitive or business pressure and release a refined version once all system features
are better understood. In a situation like this you need a process model that has been
explicitly designed to accommodate a product that grows and changes.
Originally proposed by Barry Boehm , the spiral model is an evolutionary software process
model that couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model. It provides the potential for rapid development of increasingly
more complete versions of the software.

Using the spiral model, software is developed in a series of evolutionary releases. During
early iterations, the release might be a model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.
A spiral model is divided into a set of framework activities defined by the software
engineering team. For illustrative purposes, we use the generic framework activities
discussed earlier. Each of the framework activities represent one segment of the spiral path
illustrated in Figure. As this evolutionary process begins, the software team performs
activities that are implied by a circuit around the spiral in a clockwise direction, beginning at
the center. Risk is considered as each revolution is made. Anchor point milestones—a
combination of work products and conditions that are attained along the path of the spiral—
are noted for each evolutionary pass.
The first circuit around the spiral (beginning at the inside streamline nearest the center, as
shown in Figure 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.
Unlike other process models that end when software is delivered, the spiral model can be
adapted to apply throughout the life of the computer software. The spiral model is a realistic
approach to the development of large-scale systems and software. It uses prototyping as a
risk reduction mechanism. 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
problematic. But like other paradigms, the spiral model is not a panacea. It may be difficult to
convince customers (particularly in contract situations) that the evolutionary approach is
controllable. It demands considerable risk assessment expertise and relies on this expertise
for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.
We have already noted that modern computer software is characterized by continual

change, by very tight time lines, and by an emphatic need for customer-user satisfaction. In
many cases, time to market is the most important management requirement. If a market
window is missed, the software project itself may be meaningless.
The intent of evolutionary models is to develop high-quality software6 in an iterative or

incremental manner. However, it is possible to use an evolutionary process to emphasize
flexibility, extensibility, and speed of development. The challenge for software teams and
their managers is to establish a proper balance between these critical project and product
parameters and customer satisfaction (the ultimate arbiter of software quality).
OR
Evolutionary model is a combination of Iterative and Incremental model of software

development life cycle. Delivering your system in a big bang release, delivering it in
incremental process over time is the action done in this model. Some initial requirements and
architecture envisioning need to be done. It is better for software products that have their
feature sets redefined during development because of user feedback and other factors. The
Evolutionary development model divides the development cycle into smaller, incremental
waterfall models in which users are able to get access to the product at the end of each cycle.
Feedback is provided by the users on the product for the planning stage of the next cycle and
the development team responds, often by changing the product, plan or process. Therefore,
the software product evolves with time. All the models have the disadvantage that the
duration of time from start of the project to the delivery time of a solution is very high.

Evolutionary model solves this problem in a different approach.

Evolutionary model suggests breaking down of work into smaller chunks, prioritizing them
and then delivering those chunks to the customer one by one. The number of chunks is huge
and is the number of deliveries made to the customer. The main advantage is that the
customer’s confidence increases as he constantly gets quantifiable goods or services from the
beginning of the project to verify and validate his requirements. The model allows for
changing requirements as well as all work in broken down into maintainable work
chunks. Application of Evolutionary Model:
1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants to start
using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because the
system can be easily portioned into units in terms of objects.
Necessary conditions for implementing this model:-
 Customer needs are clear and been explained in deep to the developer team.
 There might be small changes required in separate parts but not a major change.
 As it requires time, so there must be some time left for the market constraints.
 Risk is high and continuous targets to achieve and report to customer repeatedly.
 It is used when working on a technology is new and requires time to learn.
Advantages:
 In evolutionary model, a user gets a chance to experiment partially developed system.
 It reduces the error because the core modules get tested thoroughly.
Disadvantages:

 Sometimes it is hard to divide the problem into several versions that would be acceptable
to the customer which can be incrementally implemented and delivered.
1.5.4 Specialized Process Model in Software Engineering
1.5.4.1 Component Based Development

The component based development model incorporates many of the characteristics of the
spiral model. It is evolutionary in nature, specialized process model demanding an iterative
approach to the creation of software.
However, the component based development model constructs applications from

prepackaged software components.
Modeling and construction activities begin with the identification of candidate components.
These components can be designed as either conventional software modules or object
oriented classes or packages of classes.
Regardless of the technology that is used to create the components, the component based
development specialized process model incorporates the following steps.
1. Available component based products are researched and evaluated for the application
domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
The component based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits.
1.5.4.2 The Formal Methods Model

The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software.
Formal methods enable you to specify, develop, and verify a computer based system by
applying a rigorous, mathematical notation.
A variation on this approach, called clean room software engineering. When formal methods
are used during development, they provide a mechanism for eliminating many of the
problems that are difficult to overcome using other software engineering paradigms.
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily, but through the application of mathematical analysis.
When formal methods are used during design, they serve as a basis for program verification
and therefore enable you to discover and correct errors that might otherwise go undetected.
Although not a mainstream approach, the formal methods model offers the promise of defect
free software.
Draw Backs:
 The development of formal models is currently quite time consuming and expensive.
 Because few software developers have the necessary background to apply formal
methods, extensive training is required.
 It is difficult to use the models as a communication mechanism for Technically
unsophisticated customers.
1.5.4.3 Aspect Oriented Software Development

AOSD defines “aspects” that express customer concerns that cut across multiple system
functions, features, and information.
When concerns cut across multiple system functions, features, and information, they are
often referred to as crosscutting concerns. Aspectual requirements define those crosscutting
concerns that have an impact across the software architecture.
Aspect oriented software development (AOSD), often referred to as aspect oriented

programming (AOP), is a relatively new software engineering paradigm that provides a
process and methodological approach for defining, specifying, designing, and constructing
aspects.”
Grundy provides further discussion of aspects in the context of what he calls aspect oriented
component engineering (AOCE):

AOCE uses a concept of horizontal slices through vertically decomposed software

components, called “aspects,” to characterize cross-cutting functional and non-functional
properties of components.
1.5.5 Unified Process Model

In some ways the Unified Process (UP) is an attempt to draw on the best features and
characteristics of traditional software process models but characterize them in a way that
implements many of the best principles of agile software development . The Unified Process
recognizes the importance of customer communication and streamlined methods for
describing the customer’s view of a system (the use case).7 It emphasizes the important role
of software architecture and “helps the architect focus on the right goals, such as
understandability, reliance to future changes, and reuse” . It suggests a process flow that is
iterative and incremental, providing the evolutionary feel that is essential in modern software
development.
UML, the unified modeling language, was developed to support their work. UML contains a
robust notation for the modeling and development of object-oriented systems and has became
a de facto industry standard for modeling software of all types. UML is used throughout Part
Two of this book to represent both requirements and design models. Appendix 1 presents an
introductory tutorial and a list of recommended books for those who are unfamiliar with basic
UML notation and modeling rules.

 The inception phase of the UP is where customer communication and planning takes
place. Fundamental business requirements are described through a set of preliminary
use cases (Chapter 7) that describe which features and functions each major class of
users desires that will become realized in the software architecture. Planning identifies
resources, assesses major risks, and defines a preliminary schedule for the software
increments.
 The elaboration phase encompasses the planning and modeling activities of the generic
process model. Elaboration refines and expands the preliminary use cases and creates
an architectural baseline that includes five different views of the software—the use
case model, the analysis model, the design model, the implementation model, and the
deployment model. Modifications to the plan are often made at this time.
 The construction phase of the UP is identical to the construction activity defined for
the generic software process. All necessary and required features and functions for the
software increment (i.e., the release) are then implemented in source code. As
components are being implemented, unit tests9 are designed and executed for each. In
addition, integration activities (component assembly and integration testing) are

conducted. Use cases are used to derive a suite of acceptance tests that are executed
prior to the initiation of the next UP phase.
 The transition phase of the UP encompasses the latter stages of the generic
construction activity and the first part of the generic deployment (delivery and
feedback) activity. Software and supporting documentation is given to end users for
beta testing, and user feedback reports both defects and necessary changes. At the
conclusion of the transition phase, the software increment becomes a usable software
release.
 The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for
the operating environment (infrastructure) is provided, and defect reports and requests
for changes are submitted and evaluated.

Comparing Process Models

AN AGILE VIEW AND AGILE PROCESS
1.6 What Is Agility?

Just what is agility in the context of software engineering work? Ivar Jacobson [Jac02a]
argues that the pervasiveness of change is the primary driver for agility. Software
engineers must be quick on their feet if they are to accommodate the rapid changes that
Jacobson describes. But agility is more than an effective response to change. It also
encompasses the philosophy espoused in the manifesto noted at the beginning of this
chapter. It encourages team structures and attitudes that make communication (among
team members, between technologists and business people, and between software
engineers and their managers) more facile. It emphasizes rapid delivery of operational
software and deemphasizes the importance of intermediate work products (not always a
good thing); it adopts the customer as a part of the development team and works to
eliminate the “us and them” attitude that continues to pervade many software projects; it
recognizes that planning in an uncertain world has its limits and that a project plan must
be flexible. Agility can be applied to any software process. However, to accomplish this, it
is essential that the process be designed in a way that allows the project team to adapt
tasks and to streamline them, conduct planning in a way that understands the fluidity of an
agile development approach, eliminate all but the most essential work products and keep
them lean, and emphasize an incremental delivery strategy that gets working software to
the customer as rapidly as feasible for the product type and operational environment.
Agile is an iterative approach to project management and software development that helps
teams deliver value to their customers faster and with fewer headaches. Instead of betting
everything on a "big bang" launch, an agile team delivers work in small, but consumable,
increments. Requirements, plans, and results are evaluated continuously so teams have a
natural mechanism for responding to change quickly.
Whereas the traditional "waterfall" approach has one discipline contribute to the project, then
"throw it over the wall" to the next contributor, agile calls for collaborative cross-functional
teams. Open communication, collaboration, adaptation, and trust amongst team members are
at the heart of agile. Although the project lead or product owner typically prioritizes the work
to be delivered, the team takes the lead on deciding how the work will get done, self-
organizing around granular tasks and assignments.
Agile isn't defined by a set of ceremonies or specific development techniques. Rather, agile is
a group of methodologies that demonstrate a commitment to tight feedback cycles and
continuous improvement.
The original Agile Manifesto didn't prescribe two-week iterations or an ideal team size. It
simply laid out a set of core values that put people first. The way you and your team live
those values today – whether you do scrum by the book, or blend elements of Kanban and XP
– is entirely up to you.
Agile yesterday, today, and tomorrow
The publication of the Agile Manifesto in 2001 marks the birth of agile as a methodology.
Since then, many agile frameworks have emerged such as scrum, kanban, lean, and Extreme
Programming (XP). Each embodies the core principles of frequent iteration, continuous
learning, and high quality in its own way. Scrum and XP are favored by software
development teams, while kanban is a darling among service-oriented teams like IT or human
resources.

Today, many agile teams combine practices from a few different frameworks, spiced up with
practices unique to the team. Some teams adopt some agile rituals (like regular stand-ups,
retros, backlogs, etc.), while others created a new agile practice (agile marketing teams who
adhere to the Agile Marketing Manifesto).
The agile teams of tomorrow will value their own effectiveness over adherence to doctrine.
Openness, trust, and autonomy are emerging as the cultural currency for companies who want
to attract the best people and get the most out of them. Such companies are already proving
that practices can vary across teams, as long as they're guided by the right principles.
1.7 What Is an Agile Process?

Any agile software process is characterized in a manner that addresses a number of
key assumptions about the majority of software projects:
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. That is, both
activities should be performed in tandem so that design models are proven as they are
created. 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 (from a planning point
of view) as we might like.
Given these three assumptions, an important question arises: How do we create a

process that can manage unpredictability? The answer, as we have already noted, lies in
process adaptability (to rapidly changing project and technical conditions). An agile process,
therefore, must be adaptable. But continual adaptation without forward progress
accomplishes little. Therefore, an agile software process must adapt incrementally. To
accomplish incremental adaptation, 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. Hence, an incremental
development strategy should be instituted. Software increments (executable prototypes or
portions of an operational system) must be delivered in short time periods so that adaptation
keeps pace with change (unpredictability). 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.
1.7.1 Agility Principles

The Agile Alliance defines 12 principles for those software organizations that want to
achieve agility. These principles are summarized in the paragraphs that follow.
Customer satisfaction is achieved by providing value through software that is delivered
to the customer as rapidly as possible. To achieve this, agile developers recognize that
requirements will change. They deliver software increments frequently and work together
with all stakeholders so that feedback on their deliveries is rapid and meaningful.
An agile team is populated by motivated individuals, who communicate face-to face and
work in an environment that is conducive to high quality software development. The team
follows a process that encourages technical excellence and good design, emphasizing
simplicity—“the art of maximized the amount of work not done”. Working software that
meets customer needs is their primary goal, and the pace and direction of the team’s work
must be “sustainable,” enabling them to work effectively for long periods of time.
An agile team is a “self-organizing team”—one that can develop well-structured
architectures that lead to solid designs and customer satisfaction. Part of the team culture is to
consider its work introspectively, always with the intent of improving the manner in which it
addresses its primary goal.
Not every agile process model applies characteristics described in this section with equal
weight, and some models choose to ignore (or at least downplay) the importance of one or
more agile principles. However, these principles define an agile spirit that is maintained in
each of the process models presented in this chapter.
1.7.2 The Politics of Agile Development

There is considerable debate (sometimes strident) about the benefits and applicability of
agile software development as opposed to more conventional software engineering processes.
Jim Highsmith (facetiously) states the extremes when he characterizes the feeling of the pro-
agility camp (“agilists”): “Traditional methodologists are a bunch of stick-in-the-muds who’d
rather produce flawless documentation than a working system that meets business needs.” As
a counterpoint, he states (again, facetiously) the position of the traditional software
engineering camp: “Lightweight, er, ‘agile’ methodologists are a bunch of glorified hackers
who are going to be in for a heck of a surprise when they try to scale up their toys into
enterprise-wide software.”
Like all software technology arguments, this methodology debate risks degenerating
into a religious war. If warfare breaks out, rational thought disappears and beliefs rather than
facts guide decision making.
No one is against agility. The real question is: What is the best way to achieve it? Keep
in mind that working software is important, but don’t forget that it must also exhibit a variety
of quality attributes including reliability, usability, and maintainability. How do you build
software that meets customers’ needs today and exhibits the quality characteristics that will
enable it to be extended and scaled to meet customers’ needs over the long term?
There are no absolute answers to either of these questions. Even within the agile school
itself, there are many proposed framework models (Sections 3.4 and 3.5), each with a subtly
different approach to the agility problem. Within each model there is a set of “ideas” (agilists
are loath to call them “work tasks”) that represent a significant departure from traditional
software engineering. And yet, many agile concepts are simply adaptations of good software
engineering concepts. The bottom line is there is much that can be gained by considering the
best of both schools and virtually nothing to be gained by denigrating either approach.
1.8 Agile Process Model

The meaning of Agile is swift or versatile. “Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in
advance.
Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller parts
helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software development
life cycle including planning, requirements analysis, design, coding, and testing before a
working product is demonstrated to the client.

Phases of Agile Model:
Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback
1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic feasibility.
2. Design the requirements: When you have identified the project, work with stakeholders
to define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's performance
and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.
When to use the Agile Model?

o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.
Advantages (Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.
Disadvantages (Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions
taken throughout various phases can be misinterpreted at any time by different team
members.
2. Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can become
a difficulty.

Unit 1

Uploaded by

Copyright:

Available Formats

Unit 1

Uploaded by

Document Information

Original Description:

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

Unit 1

Uploaded by

Copyright:

Available Formats

Software Engineering Lecture notes

INTRODUCTION TO SOFTWARE ENGINEERING

1.1 Software Engineering:

Software engineering is the process of designing, developing, testing, and maintaining

1.2 Software Process Framework

LIET, Department of CSE | 2

Software Process Framework

Process Framework Activities:

LIET, Department of CSE | 3

1.3 Capability maturity model (CMM)

1.4 Software Process Assessment

LIET, Department of CSE | 6

Software Process Assessment is a disciplined and organized examination of the software

 Self-Assessment : This is conducted internally by the people of their own organization.

LIET, Department of CSE | 7

A model will define the following:

 The tasks to be performed

 The pre and post-conditions for each task

1.5 Prescriptive Process Models

1.5.1 The Waterfall Model

accommodate changes to mandated government regulations). It may also occur in a limited

Figure Waterfall Model

Some of the major advantages of the Waterfall Model are as follows −

1.5.2 Incremental Process Model

LIET, Department of CSE | 11

The various phases of incremental model are as follows:

4. Implementation: Implementation phase enables the coding phase of the development

LIET, Department of CSE | 12

When we use the Incremental Model?

Advantage of Incremental Model

Disadvantage of Incremental Model

1.5.3 Evolutionary Process Model

LIET, Department of CSE | 13

We have already noted that modern computer software is characterized by continual

The intent of evolutionary models is to develop high-quality software6 in an iterative or

Evolutionary model is a combination of Iterative and Incremental model of software

LIET, Department of CSE | 15

Evolutionary model solves this problem in a different approach.

LIET, Department of CSE | 16

1.5.4 Specialized Process Model in Software Engineering

1.5.4.1 Component Based Development

However, the component based development model constructs applications from

1.5.4.2 The Formal Methods Model

1.5.4.3 Aspect Oriented Software Development

Aspect oriented software development (AOSD), often referred to as aspect oriented

LIET, Department of CSE | 18

AOCE uses a concept of horizontal slices through vertically decomposed software

1.5.5 Unified Process Model

LIET, Department of CSE | 19

addition, integration activities (component assembly and integration testing) are

LIET, Department of CSE | 21

Comparing Process Models

LIET, Department of CSE | 22

AN AGILE VIEW AND AGILE PROCESS

1.6 What Is Agility?

Agile yesterday, today, and tomorrow

LIET, Department of CSE | 24

1.7 What Is an Agile Process?

Given these three assumptions, an important question arises: How do we create a