Learning Material

UNIT –I

Syllabus:
Introduction
The Evolving role of software, s/w Engineering, s/w Characteristics ,The changing nature of software, s/w
Myths.
Software Lifecycle Models
Basic Concepts, Process Models- waterfall model and its extensions, Prototyping model, Iterative
Development Model, RUP Model, Extreme Programming & Agile Development Models.

1. The Evolving role of software

 Software takes on a dual role - It is a product and, at the same time, the vehicle for delivering a
product.
 As a product, it delivers the computing potential embodied by computer hardware or, more
broadly, a network of computers that are accessible by local hardware.
 Software is an Information Transformer - producing, managing, acquiring, modifying, displaying,
or transmitting information that can be as simple as a single bit or as complex as a multimedia
presentation.
 As the vehicle used to deliver the product, software acts as the basis for the control of the
computer (operating systems), the communication of information (networks), and the creation
and control of other programs (software tools and environments).
 Software delivers the most important product of our time—information. It transforms data into
more useful information to enhance competitiveness; it provides a gateway to worldwide
information networks (e.g., Internet) and provides the means for acquiring information in all of its
forms.
 The role of computer software has undergone significant change over a time span of little more
than 50 years.
 Dramatic improvements in hardware performance, profound changes in computing architectures,
vast increases in memory and storage capacity, and a wide variety of exotic input and output
options have all precipitated more sophisticated and complex computer-based systems.
 Sophistication and complexity can produce dazzling results when a system succeeds, but they can
also pose huge problems for those who must build complex systems.
 As the Internet grew in importance, Software’s role continues to expand.
 Software is a logical rather than a physical system element.
 Today, a huge s/w industry has become a dominant factor in the economies of the industrialized
world.
 Teams of s/w specialists, each focusing on one part of the technology required to deliver a
complex application instead of the lone programmer of an earlier era.

Questions to be Answered
  The questions that were asked of the lone programmer are the same questions that are
asked when modern computer based systems are built:
 Why does it take so long to get s/w finished?
 Why are development costs so high?
 Why can’t we find all errors before we give the s/w to our customers?
 Why do we spend so much time & effort maintaining existing programs?
 Why do we continue to have difficulty in measuring progress as s/w is being developed &
maintained?
 These, and so many other questions, are a manifestation of the concern about s/w and the
manner in which it is developed-
 A concern that has lead to the adoption of Software Engineering practice.
 Software Engineering practice is a broad array of concepts, principles, methods, and tools that
are used when software is planned and developed.

2. Software Engineering
In order to build s/w that is ready to meet the challenges of the twenty-first century, you must
recognize a few simple realities:

- A concerted effort should be made to understand the problem

before a software solution is developed
- Design becomes a pivotal activity
- Software should exhibit high quality
- Software should be maintainable

Simple realities lead to one conclusion:

• s/w in all of its forms & across all of its application domains should be engineered And that
leads us to the topic of – software Engineering.

Software Engineering as Layered Technology

Seminal Definition

software engineering, a definition proposed by Fritz Bauer [NAU69] at the seminal conference
on the subject still serves as a basis for discussion:

[Software engineering is] the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines

IEEE Definition

Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).

• Software engineering is the discipline that aims to provide methods and procedures for
systematically developing industrial strength software.
• The fundamental approach of software engineering is to separate the development process from
the products.
• Software engineering focuses on process since the quality of products developed and the
productivity achieved are heavily influenced by the process used.
 Figure: Software Engineering as Layered Technology
Quality Focus
 Any engineering approach must rest on an quality.
 The "Bed Rock" that supports software Engineering is Quality Focus.
Process
 Foundation for SE is the Process Layer
 SE process is the glue that holds all the technology layers together and enables the timely
development of computer software.
 It forms the base for management control of software project.
Methods
 SE methods provide the "Technical Questions" for building Software.
 Methods contain a broad array of tasks that include communication requirement analysis, design
modeling, program construction testing and support.
Tools
 SE tools provide automated or semi-automated support for the "Process" and the "Methods".
 Tools are integrated so that information created by one tool can be used by another.

3. Software Characteristics
Software
 Software is a set of
1. Instructions that when executed provide desired function and performance,
2. Data Structures that enable the programs to adequately manipulate information,
3. Documents that describe the operation and use of the programs.
 To gain an understanding of software (how it is different from hardware and ultimately an
understanding of software engineering), it is important to examine the characteristics of
software.
1. Software is developed or engineered, it is not manufactured.
 Hardware is manufactured, but software is developed.
 The manufacturing phase for hardware can introduce quality problems that are
nonexistent or easily corrected for software.
 Both activities are dependent on people, but the relationship between people applied
and work accomplished is entirely different.
 Both activities require the construction of a "product" but the approaches are
different.
 Software costs are concentrated in engineering. This means that software projects
cannot be managed as if they were manufacturing projects.
2. Software doesn't "wear out"
 Figure 1.1 depicts failure rate as a function of time for hardware. The relationship is
often called the "bathtub curve".
 It indicates that hardware exhibits relatively high failure rates early in its life
 These failures are often attributable to design or manufacturing defects.
  These defects can be corrected and the failure rate drops to a steady-state level
(ideally, quite low) for some period of time.
 As time passes, however, the failure rate rises again as hardware components suffer
from the cumulative effects of dust, vibration, abuse, temperature extremes, and
many other environmental maladies, which means that the hardware begins to wear
out.
 Software is not susceptible to the environmental maladies that cause hardware to
wear out.

 In theory, therefore, the failure rate curve for software should take the form of the
“idealized curve” shown in Figure 1.2.
 Undiscovered defects will cause high failure rates early in the life of a program.
 However, these are corrected (ideally, without introducing other errors) and the curve
flattens as shown.
 The idealized curve is a gross oversimplification of actual failure models for
software.
 However, the implication is clear—software doesn't wear out. But it does deteriorate!
 This seeming contradiction can best be explained by considering the “actual curve”
shown in Figure 1.2.
 During its life, software will undergo change (maintenance).
 As changes are made, it is likely that some new defects will be introduced, causing
the failure rate curve to spike as shown in Figure 1.2.
 Before the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again. Slowly, the minimum failure rate level
begins to rise—the software is deteriorating due to change.
 Another aspect of wear illustrates the difference between hardware and software.
 When a hardware component wears out, it is replaced by a spare part. There are no
software spare parts.
 Every software failure indicates an error in design or in the process through which
design was translated into machine executable code.
 Therefore, software maintenance involves considerably more complexity than
hardware maintenance.
3. Although the industry is moving toward component-based assembly, most software
continues to be custom built.
  A software component should be designed and implemented so that it can be reused
in many different programs.
 For example, today's graphical user interfaces are built using reusable components
that enable the creation of graphics windows, pull-down menus, and a wide variety of
interaction mechanisms.
 The data structure and processing detail required to build the interface are contained
with a library of reusable components for interface construction.

4. The changing nature of software

 The nature of software has changed a lot over the years. It has changed from writing programs by
individuals for their personal use to writing very complex software to run a nuclear power plant.
 Its nature mainly depends on the type of software used. Given below are the different types of
software being used in different applications.
System Software
 System Software is a collection of programs written to provide service to other programs.
 It needs heavy interaction with computer hardware.
 It contains complex data structures and multiple external interfaces
Examples: Compilers, Editors, File Management Utilities, other System Applications Drivers
and Networking Software.

Application Software
 Application Software consists of standalone programs that are used to solve specific business
needs.
 It is used to process technical data/technical decisions and control business functions in real time.
Examples: Conventional Data Processing Applications, Real-Time Manufacturing Process
Control, point-of-sale etc.

Engineering/Scientific Software
 It is characterized by conventional numerical algorithms.
 It is used to create interactive applications to take on real time.
Examples: Computer Aided Design(CAD/CAM), System Simulation, Weather prediction
system, Interactive Applications in Educational Field.

Embedded Software
 Software that resides within a product or system is called as Embedded Software.
Examples: Keypad control for a Microwave Oven, Smart dustbins etc.

Product-line Software
 This type of software provides specific capability for use by many different customers.
Examples: Word Processing, Spreadsheets, Computer Graphics, Database Management,
Multimedia & Entertainment and Business Financial Applications.
Web Applications
 It can be considered as a set of linked hypertext files.
 Web Application Software has grown relevant as E-Commerce & B2B applications grow in
importance.
Examples: E-commerce sites, Air line reservation system, IRCTC etc.
 Artificial Intelligence Software
 This type of software uses Non-Numerical Algorithms to solve complex problems.
Examples: Robotics, Expert Systems, Pattern Recognition(image and voice), Artificial Neural
Networks, Theorem Proving, Game Playing.

Open Source
 Open Source Software refers to the software whose source code is public to everyone to develop,
test or improve.
Examples: Linux Operating System, Apache Web Server Application, LibreOffice Application,
GNU Image Manipulation Application.

5. Software Myths
 Are the false beliefs that managers, customers, and developers have on the software development.

5.1 Management myths

Myth1: Development problems can be solved by developing and documenting standards.
Reality: Standards have been developed by companies and standards organizations. They can be very
useful. However, they are frequently ignored by developers because they think that they are irrelevant
and sometimes incomprehensible.

Myth2: Development problems can be solved by using state-of-the art tools.

Reality: Tools may help, but there is no magic. Problem solving requires more than tools. It requires
great understanding.

Myth3: If we fall behind schedule in developing software, we can just put more people on it.
Reality: If software is late, adding more people will merely make the problem worse. This is because
the people already working on the project need to educate the newcomers. So, this does not
immediately reduce the work.

Myth4: If I decide to outsource the software project to a third party, I can just relax and let that firm
build it.
Reality: If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsources software projects.

5.2 Customer myths

Customers often underestimate the difficulty of developing software. Sometimes marketing people
encourage customers in their misbeliefs.
Myth1: A general statement of objectives is sufficient to begin writing programs— we can fill in the
details later.
Reality: A poor definition of the problem is the major cause of failed software. A detailed description
of the information domain, functions, behavior, performance, interfaces, design constraints, and
validation criteria is essential before writing the programs. These can be determined only after
thorough communication between customer and developer.

Myth2: Project requirements continuously change, but change can be easily accommodated because
software is flexible.
Reality: It is true that software requirements change, but the impact of change varies with the time at
which it is introduced. If change is requested in design, then it costs 5 times more as if it is done in
analysis. If it is requested in coding, then it costs 10 more, in testing it is 50 times more and if it is
requested after delivery, then its cost increases enormously.
5.3 Developer’s (Practitioner's) myths
Practitioner's often want to be artists, but the software development craft is becoming an engineering
discipline. However myths remain:
Myth1: Once we write the program and get it to work, our job is done.
Reality: Commercially successful software may be used for decades. Developers must continually
maintain such software: they add features and repair bugs. Maintenance costs predominate over all
other costs; maintenance may be 60% of the development costs. This myth is true only for shelfware -
-- software that is never used.

Myth2: Until I get the program "running" I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms is formal technical review.
Software reviews can effectively detect the problems in requirements documents, design documents,
test plans, and code.

Myth3: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software delivery. Apart from this several other
documents such as analysis, design and testing documents, user manuals etc. may also be created
during software development.

Myth4: Software engineering will make us create voluminous and unnecessary documentation and
will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating quality. Better
quality leads to reduced rework. And reduced rework results in faster delivery times.
6. Basic Concepts
Software Processes

 Process means a particular method of doing something, generally involving number of

steps of operations.
 It is a set of activities with ordering constraints to produce desired outcomes.
 The desired result should produce high quality & productivity.
 Software development includes man process executing simultaneously.
 Non Software Engineering processes like business processes, social processes and
training processes have impact on software development.
 The process that deals with technical and management issues of software development is
called a Software Process.
 Many different types of activities need to be performed to develop software.
Project:

 A successful project should satisfy all the user three goals of software. (Cost, Schedule
and Quality)
 Software projects utilize the process to organize the execution of tasks.
 A projects’ process specification defines the tasks to be perfomed and their order.
 A process model specifies a general process usually as a set of stages in which a project
should be divided in which order these stages should be executed and other constraints.
 It helps to achieve low cost, high quality and less cycle time.
  Process models provide generic guidelines for developing a suitable process for a project.
 A process specifies steps, the project executes these steps and products are produced
during the course of execution.
Process Model  Projects’ Process  Actual Process
 Process limits the degree of freedom for a project but this leads to shortest path to satisfy
user needs.
Component Software Processes

 As a software project will have to engineer a solution and properly manage the project,
there are clearly two major components in a software process are
1. development process
2. project management process.

Figure: Software Process Components

 The development process specifies all the engineering activities that need to be
performed
 The management process specifies how to plan and control these activities so that cost,
schedule, quality, and other objectives are met.
 Effective development and project management processes are the key to achieving the
objectives of delivering the desired software satisfying the user needs, while ensuring
high productivity and quality.
 The basic objective of the process management process is to improve the software
process.
 By this, the capability of the process to produce quality goods at low cost is improved.
 For this, the current software process is studied, frequently by studying the projects that
have been done using the process.
 The whole process of understanding the current process, analyzing its properties,
determining how to improve, and then affecting the improvement is dealt with by the
process management process.
 These component processes are distinct not only in the type of activities performed in
them, but typically also in the people who perform the activities specified by the process.
  In a typical project, development activities are performed by programmers, designers,
testers, etc.,
 The project management process activities are performed by the project management and
software engineering process group (SEPG).
 Configuration control process activities are performed by a group generally called the
configuration controller.
7. Software Development Process Models
1. Classical waterfall model
2. Prototyping model
3. Iterative Development model
4. Incremental Model
5. RUP process model
6. Extreme Programming (XP) and Agile process model

7.1 Classical Waterfall Model

 The waterfall model is a classical development process model proposed by R. W. Royce

in 1970.
 The simplest process model is the waterfall model, which states that the phases are linear
order.
 In this model, a project begins with feasibility analysis. Upon successfully demonstrating
the feasibility ofa project, the requirements analysis and project planning begins.
 Design starts after the requirements analysis is complete, and coding begins after the
design is complete.
 Once the programming is completed, the code is integrated and testing is done.
 Upon successful completion of testing, the system is installed.
 After this, the regular operation and maintenance of the system takes place.
 The basic idea behind the phases is separation of concerns.
 Each phase deals with a distinct and separate set of concerns.
 By doing this, the large and complex task of building the software is broken into smaller
tasks of specifying requirements, doing design, etc.
 The requirements analysis phase is mentioned as “analysis and planning.”
 Planning is a critical activity in software development. A good plan is based on the
requirements of the system and should be done before later phases begin.
 In practice, detailed requirements are not necessary for planning.
 Planning usually overlaps with the requirements analysis, and a plan is ready before the
later phases begin.
 This plan is an additional input to all the later phases.
 Figure: Waterfall Model

 Linear ordering of activities has some important consequences.

o First, to clearly identify the end of a phase and the beginning of the next, some
certification mechanism has to be employed at the end of each phase.
o This is usually done by some verification and validation means that will ensure
that the output of a phase is consistent with its input (which is the output of the
previous phase), and that the output of the phase is consistent with the overall
requirements of the system.
 The consequence of the need for certification is that each phase must have some defined
output that can be evaluated and certified.
o That is, when the activities of a phase are completed, there should be some
product that is producedby that phase.
 The outputs of the earlier phases are often called work products and are usually in the
form of documents like the requirements document or design document.
 For the coding phase, the output is the code.
 Though the set of documents that should be produced in a project is dependent on how
the process is implemented, the following documents generally form a reasonable set that
should be produced in each project:
– Requirements document
– Project plan
– Design documents (architecture, system, detailed)
– Test plan and test reports
 – Final code
– Software manuals (e.g., user, installation, etc.)
Limitations of waterfall model
 It assumes that the requirements of a system can be frozen (i.e., baselined) before the
design begins. But determining the requirements is difficult as the user does not even
know the requirements. Hence, having unchanging requirements is unrealistic.
 Freezing the requirements usually requires choosing the hardware. A large project might
take a few years to complete. If the hardware is selected early, then due to the speed at
which hardware technology is changing, it is likely that the final software will use a
hardware technology on the verge of becoming obsolete.
 It follows the “big bang” approach—the entire software is delivered in one shot at the
end. This entails heavy risks, as the user does not know until the very end what they are
getting. That is, it has the “all or nothing” value proposition.
 It encourages “requirements bloating”. Since all requirements must be specified at the
start and only what is specified will be delivered, it encourages the users and other
stakeholders to add even those features which they think might be needed.
 It is a document-driven process that requires formal documents at the end of each phase.

7.2 Prototyping Model

 The goal of a prototyping-based development process is to counter the first limitation of
the waterfall model.
 The basic idea here is that instead of freezing the requirements before any design or
coding can proceed, a throwaway prototype is built to help understand the requirements.
 This prototype is developed based on the currently known requirements.
 Development of the prototype obviously undergoes design, coding, and testing, but each
of these phases is not done very formally or thoroughly.
 By using this prototype, the client can get an actual feel of the system, which can enable
the client to better understand the requirements of the desired system.
 Prototyping is an attractive idea for complicated and large systems for which there is no
manual process or existing system to help determine the requirements.
 Letting the client “play” with the prototype provides valuable inputs that help determine
the requirements for the system.
 It is also an effective method of demonstrating the feasibility of a certain approach.
 In both situations, the risks associated with the projects are being reduced through the use
of prototyping.
 The development of the prototype typically starts when the preliminary version of the
requirements specification document has been developed.
 At this stage, there is a reasonable understanding of the system and its needs and which
needs are unclear or likely to change.
 After the prototype has been developed, the end users and clients are given an
opportunity to use and explore the prototype.
 Based on their experience, they provide feedback to the developers.
 Figure: Prototyping Model

 Based on the feedback, the prototype is modified to incorporate some of the suggested
changes that can be done easily, and then the users and the clients are again allowed to
use the system.
 This cycle repeats until, in the judgment of the prototype developers and analysts, the
benefit from further changing the system and obtaining feedback is outweighed by the
cost and time involved in making the changes and obtaining the feedback.
 Based on the feedback, the initial requirements are modified to produce the final
requirements specification, which is then used to develop the system.
 For prototyping for the purposes of requirement analysis to be feasible, its cost must be
kept low production quality system.
 Exception handling, recovery, and conformance to some standards and formats are
typically not included in prototypes.
 The development approach is “quick and dirty” with the focus on quick development
rather than quality.
Advantages of Prototyping
 It is cost-cutting measure by reducing testing.
 The experience of developing the prototype will reduce the cost of the actual software
development.
 As requirements will be more stable now due to the feedback from the prototype, there
will be fewer changes in the requirements. Consequently the costs incurred due to
changes in the requirements will be substantially reduced.
 The quality of final software is likely to be far superior, as the experience engineers have
obtained while developing the prototype will enable them to create a better design, write
better code, and do better testing.
 Developing a prototype mitigates many risks that exist in a project where requirements
are not well known.
  Overall, prototyping is well suited for projects where requirements are hard to determine
and the confidence in the stated requirements is low.
 In such projects where requirements are not properly understood in the beginning, using
the prototyping process model can be the most effective method for developing the
software.
 It is also an excellent technique for reducing some types of risks associated with a
project.
7.3 Iterative Development
 The iterative development process model counters the third and fourth limitations of the
waterfall model.
 It combines the benefits of both prototypingand the waterfall model.
 The basic idea is that the software should be developed in iterations, each iteration adding
some functional capability to the system until the full system is implemented.
 In the first step of this model, a simple initial implementation is done for a subset of the
overall problem.
 This subset is one that contains some of the key aspects of the problem that are easy to
understand and implement and which form a useful and usable system.
 A project control list is created that contains, in order, all the tasks that must be
performed to obtain the final implementation.
 This project control list gives an idea of how far along the project is at any given step
from the final system.
 Each step consists of
o removing the next task from the list,
o designing the implementation for the selected task,
o coding and testing the implementation,
o performing an analysis of the partial system obtained after this step, and
o updating the list as a result of the analysis.

Figure: Iterative Enhancement Model

 These three phases are called

1. the design phase,
2. implementation phase, and
 3. analysis phase.
 The process is iterated until the project control list is empty, at which time the final
implementation of the system will be available.
 The project control list guides the iteration steps and keeps track of all tasks that must be
done.
 Based on the analysis, one of the tasks in the list can include redesign of defective
components or redesign of the entire system.
 In the later steps, the design would have stabilized and there is less chance of redesign.
 Each entry in the list is a task that should be performed in one step of the iterative
enhancement process and should be simple enough to be completely understood.
 The design and implementation phases of each step can be performed in a top-down
manner or by using some other technique.
 There are clear benefits of iterative development, particularly in allowing changing
requirements, not having the all-or-nothing risk, etc.,

Figure: Iterative
delivery approach.

 Another common approach for iterative development is to do the requirements and the
architecture design in a standard waterfall or prototyping approach, but deliver the
software iteratively
 We can view this approach as having one iteration delivering the requirements and the
architecture plan, and then further iterations delivering the software in increments.
 At the start of each delivery iteration, which requirements will be implemented in this
release are decided, and then the design is enhanced and code developed to implement
the requirements.
 The iteration ends with delivery of a working software system providing some value to
the end user.
 Selecting of requirements for an iteration is done primarily based on the value the
requirement provides to the end users and how critical they are for supporting other
requirements.
Advantage of Iterative Delivery Approach
  The requirements are mostly known upfront, an overall view of the system is available
and a proper architecture can be designed which can remain relatively stable. With this,
hopefully rework in development iterations will diminish.
 At the same time, the value to the end customer is delivered iteratively so it does not have
the all-or-nothing risk.
 Also, since the delivery is being done incrementally, and planning and execution of each
iteration is done separately, feedback from an iteration can be incorporated in the next
iteration.
 Even new requirements that may get uncovered can also be incorporated.
Reasons for Popularity of Iterative Development Process:

 First and foremost, in today’s world clients do not want to invest too much without seeing
returns. The iterative model permits this after each iteration some working software is
delivered, and the risk to the client is therefore limited.
 Second, as businesses are changing rapidly today, they never really know the “complete”
requirements for the software, and there is a need to constantly add new capabilities to
the software to adapt the business to changing situations. Iterative process allows this.
 Third, each iteration provides a working system for feedback, which helps in developing
stable requirements for the next iteration.

7.4 Rational Unified Process

 Rational Unified Process (RUP) is another iterative process model that was designed by
Rational, now part of IBM.
 Though it is a general process model, it was designed for object-oriented development
using the UnifiedModeling Language (UML).
 It proposes that development of software be divided into cycles, each cycle delivering a
fully working system.
 Each cycle is executed as a separate project whose goal is to deliver some additional
capability to an existing system (built by the previous cycle).
 Hence, for a project, the process for a cycle forms the overall process.
 Each cycle itself is broken into four consecutive phases:
– Inception phase
– Elaboration phase
– Construction phase
– Transition phase
 Each phase has a distinct purpose, and completion of each phase is a well defined
milestone in the project with some clearly defined outputs.
 Figure: RUP Model

Inception Phase
 The purpose of the inception phase is to establish the goals and scope of the project, and
completion of this phase is the lifecycle objectives milestone.
 This milestone should specify
– the vision and high-level capability of the eventual system,
– what business benefits it is expected to provide,
– some key illustrative use cases of the system,
– key risks of the project, and
– a basic plan of the project regarding the cost and schedule.
 Based on the output of this phase, a go/no-go decision may be taken.
 And if the project is to proceed, then this milestone represents that there is a shared vision
among the stakeholders and they agree to the project, its vision, benefits, cost, usage, etc.
Elaboration Phase
 In the elaboration phase, the architecture of the system is designed, based on the detailed
requirements analysis.
 The completion of this phase is the lifecycle architecture milestone.
 At the end of this phase, it is expected that mostof the requirements have been identified
and specified, and the architecture of the system has been designed in a manner that it
addresses the technical risks identified in the earlier phase.
 A high-level project plan for the project has been prepared showing the remaining phases
and iterations in those, and the current perception of risks.
 By the end of this phase
– the critical engineering decisions regarding the choice of technologies,
architecture etc. have been taken, and
– a detailed understanding of the project exists.
 Outputs of this milestone allows
– technical evaluation of the proposed solution,
– a better-informed decision about cost-benefit analysis of the project.
Construction Phase
  In the construction phase, the software is built and tested. This phase results in the
software product to be delivered, along with associated user and other manuals, and
successfully completing this phase results in the initial operational capability milestone
being achieved.
Transition Phase
 The purpose of the transition phase is to move the software from the development
environment to the client’s environment, where it is to be hosted.
 This is a complex task which can require additional testing, conversion of old datafor this
software to work, training of personnel, etc.
 The successful executionof this phase results in achieving the milestone product release.

 Though these phases are consecutive, each phase itself may have multiple iterations.
 Each iteration delivers some well-defined output which is often a part of the final
deliverable of that phase’s milestone.
 The construction phase will be broken into multiple iterations, each iteration producing a
working system which can be used for feedback, evaluation, beta-testing, etc.
 RUP groups the activities into different subprocesses which it calls core process
workflows.
 These sub processes correspond to the tasks of performing requirements analysis, doing
design, implementing the design, testing, project management, etc.

Figure: Activity level of subprocesses in different phases of RUP

 One key difference of RUP from other models is that it has separated the phases from the
tasks and allows multiple of these subprocesses to function within a phase.
 In waterfall (or waterfall-based iterative model), a phase within a process was linked to a
particular task performed by some process like requirements, design, etc.
 RUP provides a flexible process model, which follows an iterative approach not only at a
top level (through cycles), but also encourages iterative approach during each of the
phases in a cycle.

7.5 Extreme Programming and Agile Processes

Agile development approaches
  Agile development approaches evolved in the 1990s as a reaction to documentation and
bureaucracy-based processes, particularly the waterfall approach.
 Common principles Agile approaches are:
o Working software is the key measure of progress in a project.
o For progress in a project, therefore, software should be developed and delivered
rapidly in small increments.
o Even late changes in the requirements should be entertained (small-increment
model of development helps in accommodating them).
o Face-to-face communication is preferred over documentation.
o Continuous feedback and involvement of customer is necessary for developing
good-quality software.
o Simple design which evolves and improves with time is a better approach than
doing an elaborate design up front for handling all possible scenarios.
o The delivery dates are decided by empowered teams of talented individuals.

 Extreme programming (XP) is one of the most popular and well-known approaches in the
family of agile methods.
 It believes that changes are inevitable and rather than treating changes as undesirable,
development should embrace change.
 To accommodate change, the development process has to be lightweight and quick to
respond.
 For this, it develops software iteratively, and avoids reliance on detailed and multiple
documents which are hard to maintain.
 It relies on face-to-face communication, simplicity, and feedback to ensure that the
desired changes are quickly and correctly reflected in the programs.
Extreme Programming

 An extreme programming project starts with user stories which are short descriptions of
what scenarios the customers and users would like the system to support.
 They are different from traditional requirements specification primarily in details - user
stories do not contain detailed requirements which are to be uncovered only when the
story is to be implemented, therefore allowing the details to be decided as late as
possible.
 Each story is written on a separate card, so they can be flexibly grouped.
 The empowered development team estimates how long it will take to implement a user
story.
 The estimates are rough, generally stated in weeks.
 Acceptance tests are also built from the stories, which are used to test the software before
the release.
 Bugs found during the acceptance testing for an iteration can form work items for the
next iteration.
 Figure: Overall process in XP.

 Development is done in iterations, each iteration lasting no more than a few weeks.
 An iteration starts with iteration planning in which the stories to be implemented in this
iteration are selected.
 High-value and high-risk stories are considered as higher priority and implemented in
early iterations.
 Failed acceptance tests in previous iteration also have to be handled.
 It expects that development is done by pairs of programmers, instead of individual
programmers.
 It suggests that for building a code unit, automated unit tests be written first before the
actual code is written, and then the code should be written to pass the tests.
 This approach is referred to as test-driven development, in contrast to regular code-first
development inwhich programmers first write code and then think of how to test it.

Figure: An iteration in XP

 As functionality of the unit increases, the unit tests are enhanced first, and then the code
is enhancedto pass the new set of unit tests.
 It encourages simple solutions as well as change.
o To handle this situation, it suggests that refactoring be done to improve the
design, and then use the refactored code for further development.
 It encourages frequent integration of different units.
 There are many other rules in XP relating to issues like rights of programmers and
customers, communication between the team members and use of metaphors, trust and
visibility to all stakeholders, collective ownership of code in which any pair can change
any code, team management, building quick spike solutions to resolve difficult technical
and architectural issues.
 XP, and other agile methods, are suitable for situations where the volume and pace of
requirements change is high, and where requirement risks are considerable.
  All the team members, it is effective when teams are collocated and of modest size, of up
to about 20 members.

Assignment-Cum-Tutorial Questions

A. Questions testing the remembering / understanding level of students

I) Objective Questions

1) Software is a set of ————————— that when executed provide desired function and
performance.
2) Software is a process and ——————————.
3) Software engineering is a ——————————.
4) The fundamental reason why the software cannot be engineered__________________________
5) Software deteriorates rather than wears out because________________
6) The aim of software engineering is to produce software that is [ ]
a) Fault-free
b) Delivered on time
c) Delivered within budget
d) Satisfies users' needs
e) All of these are the aims of software engineering.
7) Design phase is followed by _____________________.
8) Requirements can be refined using _____________________.
9) For a well understood data processing application it is best to use
_____________________.
10) RUP stands for _____________________.
11) Prototyping Process Model follows _____________________ approach.
12) Which of the following is a characteristic of Agile development? [ ]
a) Shared code ownership
b) Implement the simplest solution to meet today's problem
c) Continual feedback from customer
d) test-driven development
e) All of the above
13) In waterfall model, output of one phase is input to next phase. [ ]
a) True b) False
14) If requirements are easily understandable and defined then which model is best suited?
[ ]
a) Waterfall Model b) Iterative Development Model

c) Prototyping d) Extreme Programming

15) Which of the following are advantages of iterative model? [ ]

a) Early revenue generation

b) Simpler to manage

c) Divided workload
 d) Early feedback

e) All the above

II) Descriptive Questions

1) What do you mean by Software and Software Engineering? List out the important characteristics
of software.
2) Explain the importance and role of software in modern world.
3) Discuss the changing nature of the software.
4) What are the management myths and practitioner's myths and realities?.
5) What is a process model? How do process models differ from one another?
6) Write about the Rational Unified Process models in detail.
7) Briefly explain about Iterative Development Process model.
8) Compare the waterfall model with the Rational Unified Process model.
9) Compare the Prototyping model with the Rational Unified Process model.
10) Explain about agile methodology & extreme programming as software development
process models.
B. Question testing the ability of students in applying the concepts.

I) Multiple Choice Questions:

1) What is Software? [ ]
a) Software is set of programs.
b) Software is documentation and configuration of data.
c) Both a and b
d) None of the mentioned
2) Compilers, Editors software come under which type of software? [ ]
a) System software b) Application software
c) Scientific software d) None of the above
3) Computer software is a complete package, which includes software program, its
documentation and user guide on how to use the software. [ ]
a) True b) False
4) What are the characteristics of software? [ ]
a) Software is developed or engineered; it is not manufactured in the classical sense.
b) Software doesn’t “wear out”.
c) Software can be custom built or custom build.
d) All mentioned above
5) Which of the following cannot be applied with the software according to Software
Engineering Layers? [ ]
a) Process b) Methods
c) Manufacturing d) None of the above.
6) Which of the following provides semi-automatic and automatic support to methods in a
layered technology? [ ]
a) Methods b) Tools
 c) Process d) Quality Focus
7) The process of developing a software product using software engineering principles and
methods is referred to as, ______________. [ ]
a) Software myths b) Scientific Product
c) Software Evolution d) None of the above
8) Choose the correct option according to the given statement. [ ]
Statement 1: Software is a physical rather than a logical system element.
Statement 2: Computer software is the product that software engineers design and build.
Statement 3: Software is a logical rather than a physical system element.
Statement 4: Software is a set of application programs that are built by software
engineers.
a) Statement 1 and 2 are correct.
b) Only Statements 2 and 3 are correct.
c) Statements 2, 3 and 4 are correct.

9) Software consists of __________. [ ]

a) Set of instructions + operating procedures
b) Programs + documentation + operating procedures
c) Programs + hardware manuals
d) Set of program
10) In a college, students are asked to develop a software. Which model would be preferable?
[ ]
a) Waterfall model
b) Spiral model
c) Agile model
d) Code and fix model
11) Sometimes called the ......, the linear sequential model suggests a systematic, sequential
approach to software development that begins at the system level and progresses through
analysis, design, coding, testing, and support. [ ]
a) classic life cycle
b) the waterfall model
c) Incremental
d) Both A & B
12) Which two models doesn’t allow defining requirements early in the cycle? [ ]

a) Waterfall & RAD

b) Prototyping & Spiral
c) Prototyping & RAD
d) Waterfall & Spiral
13) Which of the following life cycle model can be chosen if the development team has less
experience on similar projects? [ ]
a) Spiral
b) Waterfall
c) RAD
d) Iterative Enhancement Model
 14) Agile Software Development is based on [ ]
a) Incremental Development
b) Iterative Development
c) Linear Development
d) Waterfall Model
e) Both a and b
15) In XP Increments are delivered to customers every _______ weeks. [ ]
a) One
b) Two
c) Three
d) Four
16) Which four framework activities are found in the Extreme Programming(XP)? [ ]
a) analysis, design, coding, testing
b) planning, analysis, design, coding
c) planning, design, coding, testing
d) planning, analysis, coding, testing
17) Which phase of the RUP is used to establish a business case for the system [ ]
a) Transition
b) Elaboration
c) Construction
d) Inception

II) Problems:

1) Justify the term “Software is engineered”.

2) How the Failure Curve of Hardware and Software can be differentiated?
3) Justify the statement “Software Maintenance is costlier”.
4) Justify the statement “Software Engineering is a Layered Technology”.
5) Justify the statement “Software is easy to change, because Software is flexible”
6) Explain why is it hard to keep the Software Development Schedule.
7) What is the relationship between process model, process specification and process of the
project?
8) Which model couples the iterative nature of prototyping with the controlled and
systematic aspect of the waterfall model? Explain its key features.
9) What is the oldest paradigm for software engineering? Why does the waterfall model
sometimes fail?
10) Compare the prototyping model with the Iterative development model. Discuss how
to select a particular process model based on characteristics of a project.
11) List out the strengths and weaknesses of waterfall, iterative development and prototyping.
12) Why does iterative process makes it easier to manage change?
13) Is it possible to combine the process models? If so explain with an example.

C. Gate Previous Questions

1) Match the following: [ ]
1. Waterfall Model a) Specifications can be developed
incrementally
2. Evolutionary Model b) Requiremetns compromises are
inevitable
3. Component-based Software c) Explicit recognition of risk
Engineering
4. Spiral Development d) Inflexible partitioning of the project
into stages
(Gate CS 2015)

(a) 1-a, 2-b, 3-c, 4-d (b) 1-d, 2-a, 3-b, 4-c
(c) 1-d, 2-b, 3-a, 4-c (d) 1-c, 2-a, 3-b, 4-d

2) Which one of the following is TRUE? [ ]

(a) The requirements document also describes how the requirements that are listed in the
document are implemented efficiently.
(b) Consistency and completeness of functional requirements are always achieved in
practice.
(c) Prototyping is a method of requirements validation.
(d) Requirements review is carried out to find the errors in system design
(GATE CS 2014)

3) What is the appropriate pairing of items in the two columns listing various activities
encountered in a software life cycle? [ ]
P. Requirements Capture 1. Module Development and Integration
Q. Design 2. Domain Analysis
R. Implementation 3. Structural and Behavioral Modeling
S. Maintenance 4. Performance Tuning
( GATE CS 2010)
(a) P-3, Q-2, R-4, S-1 (b) P-2, Q-3, R-1, S-4
(c) P-3, Q-2, R-1, S-4 (d) P-2, Q-3, R-4, S-1