NSV DEGREE COLLEGES - JAGTIAL

SOFTWARE ENGINEERING
UNIT – I
Software Engineering: The Nature of Software, Changing Nature of Software, Defining the Discipline,
Software Process, Software Engineering Practice. The Software Engineering Practice: A Generic Process
Model, Defining a Framework Activity, Process Assessment and Improvement, Prescriptive Process Models,
Specialized Process Models, Unified Process, Defining Agility, Agile Process, Extreme Programming.
----------------------------------------------------------------------------------
Software:Software is a Collection of Computer Programs and related documents that are intended to
provide desired features, functionalities and better performance. Software products may be
Generic: That means developed to be sold to a range of different customers.
Custom: That means developed for a single customer according to their specification.
The Evolving Role of Software
The evolving role of software means changing role of software. Basically any software appears in two roles
Software as a Product:Being a product the role of software can be recognised by its computing potentials,
hardware capabilities and accessibility of network computers by the local hardware. Being a product it also
acts as an information transformeri.e producing, managing, modifying and conveying the source of
information.
Software as a Process:Being a Process the software act as a vehicle for driving the product. In this role the
duty of the software is to Control the computer or to establish Communications between the computers.
Thus software plays dual role. It is both a product and a vehicle for delivering a product.
The role of software is significantly changing over the past decade. There are many factors affecting the
role of software and those are
 Changes in Computer architectures
 Improvement in hardware performance
 Vast increase in amount of memory
 Wide variety of input and outputs
Software Engineering
“Software Engineering is a discipline in which theories, methods and tools are applied to develop
professional software “. In software engineering a systematic and organized approach is adopted. Based on
the nature of problem and development constraints various tools and techniques are applied in order to
develop quality software.
Software Characteristics
Software development is a logical activity and therefore it is important to understand basic characteristics
of software. Some important characteristics of software are
Software is engineered, not manufactured:
Software development and hardware development are two different activities. A good design is a
backbone for both the activities. Quality problems that occur in hardware manufacturing phase cannot be
removed easily. On the other hand, during software development process such problems can be rectified.
In both the activities, developers are responsible for producing qualitative product.
Software does not ware out:
There is a well-known “bath tub curve” in reliability studies for hardware products. The shape of the curve
is like “bath tub” and is known as bath tub curve.

Prepared by: Ch. RajKumar 1

* There are three phases for the life of a hardware product. Initial phase in burn-in phase, where failure
intensity is high.it is expected to test the product in the industry before delivery. Due to testing and fixing
faults, failure intensity will come down initially and may stabilise after certain time.
* The second phase is the useful life phase where failure intensity is approximately constant and is called
useful life of a product. After few years, again failure intensity will increase due to wearing out of
components.
* This phase is called wear out phase. We do not have this phase for the software as it does not wear out.
The curve for software is given below.

Important point is software becomes reliable overtime instead of wearing out. It becomes obsolete, if the
environment for which it was developed, changes. Hence software may be retired due to environmental
changes, new requirements, new expectations etc.
Most software is custom built rather than being assembled from components:
->While developing any hardware product firstly the circuit design with desired functioning properties is
created. Then required hardware components such as ICs, capacitors and registers are assembled
according to the design but this is not done while developing software product.
->Most of the software is custom built. However, now the software development approach is getting
changed and we look for reusability of software components. It is practiced to reuse algorithms and data
structures.
A Comparison of constructing a bridge and writing a program

Prepared by: Ch. RajKumar 2

 THE CHANGING NATURE OF SOFTWARE
Software can be applied in a situation for which a predefined set of procedural steps exists. Based on a
complex growth of software it can be classified into following categories.
System Software: It is a collection of programs written to service other programs. Typical programs in this
category are compiler, editors, and assemblers. The purpose of the system software is to establish a
communication with the hardware.
Application Software: It consists of standalone programs that are developed for specific business need.
This software may be supported by database systems.
Real time Software: These software are used to monitor, control and analyse real world events as they
occur.
Embedded Software: This type of software is placed in “Read Only Memory” of the product and control
the various functions of the product. The product could be an aircraft, automobile, security system,
signalling system etc.
Business Software:This is the largest application area. The software designed to process business
applications is called business software. Business software could be payroll, file monitoring system,
employee management, and account management. It may also be a data warehousing tool which helps us
to take decisions based on available data.
Personal computer software: The software used in personal computers are covered in this category.
Examples are word processors, computer graphics, multimedia and animating tools, database
management etc.
Web based Software: The software related to web applications come under this category. Examples are
CGI, HTML, java, Perl, DHTML etc.
Engineering and Scientific software: Scientific and engineering application software are grouped in this
category. Huge computing is normally required to process data. Examples are CAD/CAM package, SPSS,
MATLAB, Engineering Pro etc.
Artificial Engineering Software: The kind of software is based on knowledge based expert systems.
Typically the software is useful in robotics, expert systems, image and voice recognition, artificial neural
networks.
Legacy Software

Prepared by: Ch. RajKumar 3

* The Legacy systems are the older, large complex computer based systems which may be using the
obsolete technology.
* These systems may include the older hardware, software, process and procedures. The legacy systems
are business critical systems and are used for a long period because it is too risky to replace them.
For Example: Air Traffic Control System which may be used from a long period.
* The legacy software is known for its – poor quality.
* That means legacy systems have poor designs, highly complex code, poor documentation, no use of test
cases at all, or it may have poorly managed change history.
* As time passes the legacy systems has no undergo some changes. Following are the types of changes that
legacy systems must make
1. For meeting the need of new computing environment or technologies the existing legacy systems
need to be changed.
2. Sometimes there is a requirement to the use of modern systems or databases. To accommodate
this requirement the legacy system must be changed.
3. The software needs to be enhanced for implementing new business requirements.
4. The software architectures need to be re-designed in order to make it work within networking
environment.
* When such type of changes are required the legacy systems has to be reengineered.
THE 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 and is applied regardless of the application domain, size of
the project, complexity of the effort with which software engineering is to be applied.
* An action encompasses a set of tasks that produce a major work product.
* A task focuses on small but well defined objective that produces a tangible outcome.
* 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.
* In addition the process framework encompasses a set of umbrella activities that are applicable across the
entire software process.
* A generic process framework for software engineering encompasses five activities.
Communication: Involvesheavy communication with the customer (and other stakeholders) and
encompasses requirements gathering.
Planning: Describes the technical tasks to be conducted, the risks that are likely, resources that will be
required, the work products to be produced and a work schedule.
Modelling: Encompasses the creation of models that allow the developer and customer to better
understand S/W req. and the design that will achieve those req.
Construction: Combines code generation and the testing required uncovering errors in the code.
Deployment: Deliver the product to the customer who evaluates the delivered product and provides
feedback.
Each Software engineering action is represented by a number of different task sets
The task set that best accommodates the needs of the project and the characteristics of the team is
chosen.
The framework described in the generic view of Software engineering is complemented by a number of
umbrella activities. Typical activities include:
S/W project tracking and control: allows the team to assess progress against the project plan and take
necessary action to maintain schedule.
Risk Management: Assesses the risks that may affect the outcome of the project or the quality.
Software quality assurance: defines and conducts the activities required to ensure software quality.
Formal Technical Review: uncover and remove errors before they propagate to the next action.
Prepared by: Ch. RajKumar 4
Measurement: defines and collects process, project, and product measures that assist the team in
delivering S/W that meets customers’ needs.
Software configuration management: Manages the effect of change throughout the S/W process
Reusability management: defines criteria for work product reuse.
Work product preparation and production: encompasses the activities required to create work products
such as models, documents, etc.
SOFTWARE ENGINEERING PRACTICE
Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is
planned and developed.
1. The Essence of Practice
This section lists the generic framework (communication, planning, modeling, construction, and
deployment) and umbrella (tracking, risk management, reviews, measurement, configuration
management, reusability management, work product creation, and product) activities found in all software
process models. George Polya, in a book written in 1945 (!), describes the essence of software engineering
practice …
1. Understand the problem (communication and analysis).
2. Plan a solution (modelling and software design)
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
In the context of software engineering, these common sense steps lead to a series of essential questions
Understand the problem.
• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, and features are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier
to understand?
• Can the problem be represented graphically? Can an analysis model be created?

Plan the solution.

• Have you seen similar problems before? Are there patterns that are recognizable in a potential solution?
Is there existing software that implements the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can sub problems be defined? If so, are solutions readily apparent for the sub problems?
• Can you represent a solution in a manner that leads to effective implementation? Can a design model be
created?
Carry out the plan.
• Does the solution conform to the plan? Is source code traceable to the design model?
• Is each component part of the solution provably correct? Have the design and code been reviewed, or
better, have correctness proofs been applied to the algorithm?
Examine the result.
• Is it possible to test each component part of the solution? Has a reasonable testing strategy been
implemented?
• Does the solution produce results that conform to the data, functions, and features that are required?
Has the software been validated against all stakeholder requirements?
2. General Principles
The Reason It All Exists: Provide value to the customer and the user. If you can’t provide value, then don’t
do it.
KISS—Keep It Simple, Stupid! All design should be as simple as possible, but no simpler. This facilitates
having a more easily understood and easily maintained system.
Maintain the product and project “vision.” A clear vision is essential to the success of ansoftware project.
Prepared by: Ch. RajKumar 5
What you produce, others will consume. Always specify, design, and implement knowing someone else
have to understand what you are doing.
Be open to the Future. Never design yourself into a corner. Always ask “what if,” and prepare yourself for
all possible answers by creating systems that solve the general problem, not just the specific one.
Plan Ahead for Reuse. Planning ahead for reuse reduces the cost and increases the value of both the
reusable components and the systems into which they are incorporated.
Think! Placing clear, complete thought before action almost always produces better results.
A GENERIC PROCESS MODEL
* 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 reside within a framework or model that defines their
relationship with the process and with one another.
* 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 produced, the quality assurance points that will be required, and the milestones that will be
used to indicate progress.
*A generic process framework for software engineering defines five framework activities—communication,
planning, modelling, construction, and deployment. In addition, a set of umbrella activities—project
tracking and control, risk management, quality assurance, configuration management, 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 framework activities and the actions and tasks that occur
within each framework activity are organized with respect to sequence and time
* A linear process flow executes each of the five framework activities in sequence, beginning with
communication and culminating with deployment
* An iterative process flow repeats one or more of the activities before proceeding to the next
* 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
* A parallel process flowexecutes one or more activities in parallel with other activities (e.g., modelling for
one aspect of the software might be executed in parallel with construction of another aspect of the
software).

Prepared by: Ch. RajKumar 6

 DEFINING A FRAMEWORK ACTIVITY
* A software team would need significantly more information before it could properly execute any one of
these activities as part of the software process.
* Therefore, you are faced with a key question: What actions are appropriate for a framework activity,
given the nature of the problem to be solved, the characteristics of the people doing the work, and the
stakeholders who are sponsoring the project?
* 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 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 take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail 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,
elicitation, elaboration, negotiation, specification, and validation. Each of these software engineering
actions would have many work tasks and a number of distinct work products.

Prepared by: Ch. RajKumar 7

 PROCESS ASSESMENT AND IMPROVEMENT
* The existence of a software process is no guarantee that software will be delivered on time, that it will
meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term
quality characteristics.
* Process patterns must be coupled with solid software engineering practice.
* In addition, the process itself can be assessed 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 and improvement have been
proposed over the past few decades:
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a five-step process
assessment model that incorporates five phases: initiating, diagnosing, establishing, acting, and learning.
The SCAMPI method uses the SEI CMMI as the basis for assessment.
CMM-Based Appraisal for Internal Process Improvement (CBA IPI) — provides a diagnostic technique for
assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the
assessment SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in developing an objective evaluation of
the efficacy of any defined software process.
ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve
the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies.
PRESCRIPTIVE PROCESS MODELS
Prescriptive process models were originally proposed to bring order to the chaos of software development.
History has indicated that these traditional models have brought a certain amount of useful structure to
software engineering work and have provided a reasonably effective road map for software teams.
Prepared by: Ch. RajKumar 8
The Waterfall Model:
* The Waterfall model is also called as “linear sequential model” or “classic life cycle model”. It is the
oldest software paradigm. This model suggest a systematic sequential approach to software development
* The software development starts with the requirements gathering phase then progresses through
analysis, design, coding, testing and maintenance.
* The requirement gathering and analysis phase the basic requirements of the system must be understood
by software engineer, who is also called and the Analyst. The information domain, function behavioural
requirements of the system are understood. All these requirements are then well-documented and
discuss further with the customer for reviewing.
* The design is an intermediate step between requirement analysis and coding.Design focuses on program
attributes such as
 Data Structure
 Software Architecture
 Interface representation
 Algorithmic details
The requirements are translated in some easy to represent to form using which coding can be done
effectively and efficiently.The Design needs to be documented for further use.
* Coding is a step in which season is translated into machine readable form. If design is done insufficient
detail then coding can be done effectively. programs are created in the space
* Testing begins when coding is done.While performing testing the major focus is on logical internals of
the software. The testing ensures execution of all the paths functional behaviours. the purpose of testing is
to uncover errors, fix the bugs and meet the customer requirements.
* Maintenance is the longest life cycle phase. when the system is installed and put in practical use then
error make its introduced, correcting errors and putting it in use is the major purpose of maintenance
activity.Similarly enhancing systems services as a new requirements are discovered is again maintenance of
the system.

Benefits of water model:

* The Waterfall model is simple to implements
* For implementation of small systems Waterfall model is useful
Drawbacks of water model:
There are some problems that are encountered if we apply the Waterfall model and those are
* It is difficult to follow the sequential flow in software development process. if some changes are made at
some phases then it may cause some confusion.
* The requirement analysis is done initially and sometimes it is not possible to States all the requirements
explicitly in the beginning.This causes difficulty in the project.

Prepared by: Ch. RajKumar 9

* The customer can see the working model of the project only at the end of the reviewing of the working
model, if the customer gets this dissatisfied then it causes serious problems.
* Linear nature of waterfall model includes blocking States because certain tasks may be dependent on
some previous tasks hence it is necessary to accomplish all the dependent task first it may cause long
waiting time
INCREMENTAL MODEL:
* The increment model has same phases that are in waterfall model. But it is iterative in nature. The
increment model has following phases.
* Analysis * Design *Code *Test
* The incremental model delivers series of releases to the customer. These releases are called increments.
More and more functionality is associated with each increment.
* The first increment is called core product. In this release the basic requirements are implemented and
then in subsequent increments new requirements are added.
* The word processing software package can be considered as an example of increment model. In the first
increment only the document processing facilities are available. In thesecond increments more
sophisticated documents producing and processing facilities file management functionalities are given. In
the next increment spelling and grammar checking facilities can be given. Thus in incremental model
progressive functionalities are updated with each release.
When to choose it?
* When requirements are reasonably well defined
* When overall scope of the development effort suggest a purely linear effect
* When Limited set of software functionality needed quickly?

Merits of incremental model:

* The incremental model can be adopted when there are less number of people involved in the project.
*Technical risks can be managed with each increment.
*For a very small time span, at leastcore product can be delivered to the customer.
Evolutionary Process Models
While developing the software systems it is often needed to make modifications in earlier development
phases or the task sets. If the development process is linear or in a straight line then the end product will
be unrealistic. In such cases the iterative approach needs to be adopted. The evolution re process model is
iterative model.
PROTOTYPING
* In Prototyping model initially requirement gathering is done.
* Developer and customer define overall objectives identify areas needing more requirement gathering.

Prepared by: Ch. RajKumar 10

* Then a quick design is prepared. This Design resents what will be visible to user in input and output
format.
* From the Quick design prototype is prepared. Customer or user evaluates the prototype in order to
refine the requirements.Iteratively prototype is tuned for satisfying customer requirements.Thus
prototype is important to identify the software requirements.
* When working prototype is built developer use existing program fragments or program generators to
throw away the prototype and rebuild the system to high quality.
* Certain classes of mathematical algorithms subset of command driven systems and other applications
where result can be easily examined without real time interaction can be developed using prototype
paradigm.

When to choose it?

* Software applications that are relatively easy to prototype almost always involve human mission
interaction the photo typing model is suggested.
* A general objective of software is defined but not detailed input processing or output requirements.Then
in such a case prototyping model is useful.
* When the developer is unsure of the efficiency of an algorithm or the adaptability of an operating system
then prototype serves as a better choice.
Drawbacks of prototyping
* In the first version itself, customer often wants few fixes rather than rebuilding of the system whereas
rebuilding of new system maintains high level of quality.
* The first version may have some compromises.
* Sometimes developer may make implementation compromises to get prototype working quickly.Later on
developer maybecome comfortable with compromises and forget to why they are inappropriate.
SPIRAL MODEL:
* This Model possess the iterative nature of prototyping model and controlled and systematic approaches
of the linear sequential model.
* This model gives efficient development of incremental versions of software. In this model the software is
developed in series of increments.
* The spiral model is divided into a number of framework activities. These framework activities are
denoted by task regions.
* Usually there are six tasks regions. Spiral model is a realistic approach to development of large scale
systems and software. Because customer and developer better understand the problem statement at each
evolutionary level. Also risks can be identified or rectified each such level.

Prepared by: Ch. RajKumar 11

* In the initial pass, product specification is built and in subsequent passes around the spiral the prototype
gets developed and then more improved versions of software gets developed.
* During planning phase, the cost and schedule of software can be planned and adjusted based on
feedback obtained from customer evaluation.
* In spiral model, project entry point axis is defined. This axis represents starting point for different types
of projects.
* The development of the project can be carried out in iterations. The task regions can be described as
Customer Communication: In this region, it is suggested to establish customer communication.
Planning: All planning activities are carried out in order to define resources time line and other project
related activities.
Risk Analysis: The tasks required to calculate technical and management risks are carried out.
Engineering: In this task region tasks required to build one or more representations of applications are
carried out.
Construct and release:All the necessary tasks required to construct, test, and install the application are
conducted. Some tasks that are required to provide user support are also carried out in this task region.
Customer Evaluation: Customers feedback is obtained and based on customer evaluation required tasks
are performed and implemented at installation stage.
In spiral model, the software engineering team moves around the spiral in a clockwise direction beginning
at the core.
Advantages:
* Requirements changes can be made at every stage.
* Risks can be identified and rectified before they get problematic.
Drawbacks:
* It is based on customer communication. If the communication is not proper then the software product
that gets developed will not be up to the mark.
* It demands considerable risk assessment. If the risk assessment is done properly then only the successful
product can be obtained.
CONCURRENT DEVELOPMENT MODEL:
* The concurrent development model, sometimes called concurrent engineering, allows a software team to
represent iterative and concurrent elements of any of the process models
* Concurrent modelling defines a series of events that will trigger transitions from state to state for each of the
software engineering activities, actions, or tasks.
* Concurrent modelling is applicable to all types of software development and provides an accurate picture of the
current state of a project. Rather than confining software engineering activities, actions, and tasks to a sequence of
events, it defines a process network.
* Each activity, action, or task on the network exists simultaneously with other activities, actions, or tasks. Events
generated at one point in the process network trigger transitions among the states

Prepared by: Ch. RajKumar 12

 SPECIALIZED PROCESS MODELS
Specialized process models take on many of the characteristics of one or more of the traditional models.
These models tend to be applied when a specialized or narrowly defined software engineering approach is
chosen.
Component-Based Development:
* Commercial off-the-shelf (COTS) software components, developed by vendors who offer them as products, provide
targeted functionality with well-defined interfaces that enable the component to be integrated into the software
that is to be built.
* The component-based development model incorporates many of the characteristics of the spiral model. It is
evolutionary in nature, demanding an iterative approach to the creation of software.
* However, the component-based development model constructs applications from pre-packaged software
components.
* Modelling 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 model
incorporates the following steps (implemented using an evolutionary approach):
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. Your software engineering team can achieve a reduction in development
cycle time as well as a reduction in project cost if component reuse becomes part of your culture.
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 cleanroom software engineering, is currently applied by some software
development organizations.
* 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—not through ad hoc
review, 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.
• 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.
ASPECT ORIENTED SOFTWARE DEVELOPMENT:
* In traditional software development process the system is decomposed into multiple units of primary
functionality but there are other issues of concern that do not fit into these primary functionalities.
* Later on this becomes programmer’s duty to code modules corresponding to the primary functionality
and to incorporate all other concerned issues wherever appropriate.
* Programs need to keep in mind all the things that need to be done, how to deal with each issue, the
problems associated with them and the correct execution.
* Due to these concerns there are chances of appearing serious problems during application development
and maintenance.The coding process for realizing a concern becomes very critical.

Prepared by: Ch. RajKumar 13

* Aspect oriented software development focuses on the identification, specification and representation of
cross cutting concerns and their modularization into separate functional units as well as their automated
composition into a working system.
* Aspectual requirements define these cross cutting concerns that have impact on the software
architecture.
* Aspect software development is often referred as aspect oriental programming.
* It is a relatively new software engineering paradigm and it is not matured enough. But is likely that it will
adopt the characteristics of both the spiral and the concurrent process models.
THE UNIFIED PROCESS
The unified process is a framework for object oriented models. This model is also called as rational unified
process model. It is proposed by IVAR JACOBSON, GRADY BOOTCH, and JAMES RAMBAUGH. This model is
Iterative and incremental by nature. let us discussed various phases of unified process.
These are five phases of unified process model and those are
o Inception
o Elaboration
o Construction
o Transition
o Production.
Inception:
In this phase there are two major activities that are conducted communication and planning.By having
customer communication business requirementscan be identified. Then a rough architecture of the system
is proposed. Using this rough architecture it then becomes easy to make a plan for the project.Use cases
are created which elaborates the user scenario.Using use cases the sequence of actions can be identified.
Thus use cases help to identify the scope of the project which ultimately proves to be the basis for the
plan.
Elaboration:
Elaboration can be done using two activities planning and modelling.In thisphase the use cases are re
defined.Andan architectural representation is created using 5 models.Such as use case model, analysis
model, design model, implementation model and deployment model.Thusexecutive baseline gets
created.Then a plan is created carefully to check whether scope risksand the delivery date are reasonable.
Construction:
The main activity in the phase is to make the use cases operational.The analysis and design activities that
and started in elaboration phase are completed in this phase and a source code is developed which
implements all desired functionality.Then Unit testing is conducted and acceptance testing is carried out
on the use cases
Transition:
It the transition phase all the activities that are required at the time of deployment of the software product
are carried out.Beta testing is conducted when software is delivered to the end user.User feedback report
is used to remove defects from the creator systems.Finally software team prepare User manuals,
installation guides and troubleshooting procedures.This makes the software more usable at the time of
release.
Production:
This is the final phase of this model. In this phase mainly the maintenance activities are conducted in order
to support the user in operational environment.

Prepared by: Ch. RajKumar 14

AGILITY:
Agile Software development is a group of software development methodologies based on iterative and
incremental development, where requirements and solutions evolve through collaboration between self-
organizing, cross functional teams.
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.
Agility Principles:
1. Our 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.
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
behaviour accordingly.
Human Factors:
Proponents of agile software development take great pains to emphasize the importance of “people
factors.” As Cockburn and Highsmith state, “Agile development focuses on the talents and skills of
individuals, molding the process to specific people and teams.” The key point in this statement is that the
process molds to the needs of the people and team, not the other way around.
Prepared by: Ch. RajKumar 15
 o Competence.
o Common focus.
o Collaboration.
o Decision-making ability.
o Fuzzy problem-solving ability.
o Mutual trust and respect.
o Self-organization.
Extreme Programming:
The Extreme Programming is commonly used agile process model.It uses the concept of object-oriented
programming. A developer focuses on the framework activities like planning, design, coding and testing. XP
has a set of rules and practices.
XP values
Following are the values for extreme programming:
1. Communication
Building software development process needs communication between the developer and the customer.
Communication is important for requirement gathering and discussing the concept.
2. Simplicity
The simple design is easy to implement in code.
3. Feedback
Feedback guides the development process in the right direction.
4. Courage
In every development process there will always be a pressure situation. The courage or the discipline to
deal with it surely makes the task easy.
5. Respect
Agile process should inculcate the habit to respect all team members, other stake holders and customer.
XP Process:
The XP process comprises four framework activities:
1. Planning
Planning starts with the requirements gathering which enables XP team to understand the rules for the
software.
The customer and developer work together for the final requirements.
2. Design
The XP design follows the 'keep it simple' principle. A simple design always prefers the more difficult
representation.
3. Coding
The coding is started after the initial design work is over. After the initial design work is done, the team
creates a set of unit tests which can test each situation that should be a part of the release. The developer
is focused on what must be implemented to pass the test. Two people are assigned to create the code. It
is an important concept in coding activity.
4. Testing
Validation testing of the system occurs on a daily basis. It gives the XP team a regular indication of the
progress.'XP acceptance tests' are known as the customer test.
Industrial XP:
Joshua Kerievsky describes Industrial Extreme Programming (IXP) in the following manner: “IXP is an
organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven spirit. IXP differs
most from the original XP in its greater inclusion of management, its expanded role for customers, and its
upgraded technical practices.” IXP incorporates six new practices that are designed to help ensure that an
XP project works successfully for significant projects within a large organization.
Readiness assessment.
* Readiness assessment is the act of measuring howprepared your organization is for a major change.

Prepared by: Ch. RajKumar 16

* In order to conduct a thorough readiness assessment, you need to evaluate the culture; leadership
styles;performance; processes; and, resources of yourorganization.
*As a result of readiness assessment, you can identifyorganizational needs and develop a plan to
introducequality improvement goals to staff.
The assessment ascertains whether:
(1) An appropriate development environment exists tosupport IXP,
(2) The team will be populated by the proper set ofstakeholders,
(3) The organization has a distinct quality program andsupports continuous improvement,
(4) The organizational culture will support the newvalues of an agile team,
(5) The broader project community will be populatedappropriately.
Project community.
XP suggests that the right people be used to populatethe agile team to ensure success.
*People on the team must be well-trained, adaptableand skilled, and have the proper temperament to
Contribute to a self-organizing team.
Project chartering.
Project Charter refers to a statement of objectives ina project.
* This statement also sets out detailed project goals,roles and responsibilities, identifies the
mainstakeholders, and the level of authority of a projectmanager.
Test-driven management.
Test-driven management establishes a series ofmeasurable “destinations” and then definesmechanisms
for determining whether or not thesedestinations have been reached.
Retrospectives.
An IXP team conducts a specialized technical reviewafter a software increment is delivered called
aretrospective.
*The review examines “issues, events, and lessons learned”across a software increment and/or the entire
Software release.
Continuous learning.
Because learning is a vital part of continuous processimprovement.Members of the XP team are
encouraged to learnnew methods and techniques that can lead to a higherquality product.
The XP Debate
 Requirements volatility
 Conflicting customer needs.
 Requirements are expressed informally.
 Lack of formal design.

Prepared by: Ch. RajKumar 17

Prepared by: Ch. RajKumar 18