UNIT-1

INTRODUCTION TO SOFTWARE ENGINEERING

The term is made of two words, software and engineering.

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

Engineering on the other hand, is all about developing products, using well -defined, scientific
principles and methods.

IEEE defines software engineering as:

The application of a systematic, disciplined, quantifiable approach to the development operation, and
maintenance of software that is, the application of engineering to software

Why software engineering term came into existence? (History)

The discipline of software engineering was created to address poor quality of software, get projects
exceeding time and budget under control, and ensure that software is built systematically, rigorously,
measurably, on time, on budget, and within specification. Engineering already addresses all these
issues, hence the same principles used in engineering can be applied to software. The widespread lack
of best practices for software at the time was perceived as a "software crisis".

Computer science versus software engineering

Scientists build things to learn something Engineers learn things to design and
new build quality products

Scientists want to achieve scientific break Engineers want to avoid engineering

through failures

Computer scientists want to understand Software engineers want to learn the

the algorithms, and the foundations of design principles and best practices for
computing theory building quality software systems

Computer scientists want to know how Software engineers want to know the
the basic technology works and where characteristics of the technologies so
to improve it they can design the most appropriate
technology into their software systems
 • Computer Science is about understanding natural laws of how computation behaves (e.g. Turing
machines and theory of computation; Big-oh, algorithms, and computational complexity;
computer architecture, etc.) You can be an excellent computer scientist without having any
ability or skill to write production-quality software

• Software engineering is partially about understanding how to apply the knowledge gained from
studying Computer Science to building products. It's also about understanding how to design,
maintain, and manage large pieces of software, how to properly manage a release cycle,
knowing the relevant tool chain (from shell commands down to programming languages and
operating systems), etc. All of these issues are very important for building quality software, but
are often of no interest to Computer Scientists.

NEED OF SOFTWARE ENGINEERING

The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working. Following are some of the needs stated:

• Large software - It is easier to build a wall than a house or building, likewise, as the size of the
software becomes large, engineering has to step to give it a scientific process.

• Scalability- If the software process were not based on scientific and engineering concepts, it
would be easier to re-create new software than to scale an existing one.

• Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price
of computer and electronic hardware. But, cost of the software remains high if proper process
is not adapted.

• Dynamic Nature- Always growing and adapting nature of the software hugely depends upon the
environment in which the user works. If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where the software engineering
plays a good role.

• Quality Management- Better process of software development provides better and quality
software product.

CHARACTERISTICS OF GOOD SOFTWARE

A software product can be judged by what it offers and how well it can be used. This software must
satisfy on the following grounds:
• Operational
• Transitional
• Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

Operational
This tells us how well the software works in operations. It can be measured on:
 • Budget
• Usability
• Efficiency
• Correctness
• Functionality
• Dependability
• Security
• Safety

Transitional
This aspect is important when the software is moved from one platform to another:
• Portability
• Interoperability
• Reusability
• Adaptability

Maintenance
This aspect briefs about how well the software has the capabilities to maintain itself in the ever
changing environment:
• Modularity
• Maintainability
• Flexibility
• Scalability
In short, Software engineering is a branch of computer science, which uses well-defined engineering
concepts required to produce efficient, durable, scalable, in-budget, and on-time software products.

1.1 THE EVOLVING ROLE OF SOFTWARE

Dual role of Software

• A Product

Information transformer producing, managing and displaying

• A Vehicle for delivering a product

Control of computer (operating system), the communication of information (networks) and the
creation of other programs

Software is defined as
1. Instructions

Programs that when executed provide desired function

 2. Data structures

Enable the programs to adequately manipulate information

3. Documents

Describe the operation and use of the programs.

Questions about Software Haven't Changed Over the Decades

• Why does it take so long to get software finished?

• Why are development costs so high?
• Why can't we find all errors before we give the software to our customers?
• Why do we spend so much time and effort maintaining existing programs?
• Why do we continue to have difficulty in measuring progress as software is being developed and
maintained?

Software Characteristics

For a better understanding of the software, it is important to examine the characteristics of software
that make it different from other things that human beings build. When hardware is built, the human
creative process (analysis, design, construction, testing) is ultimately translated into a physical form. If
we build a new computer, our initial sketches, formal design drawings, and bread boarded prototype
evolve into a physical product (chips, circuit boards, power supplies, etc.). Since software is purely
logical rather than a physical system element, it therefore, has characteristics that are entirely
different than those of hardware:

1. Software is developed or engineered but it is not manufactured in the classical sense

Although some similarities exist between software development and hardware manufacture, the two
activities are fundamentally different. In both activities, high quality is achieved through good design,
but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or
easily corrected) for software. Both activities depend on people, but the relationship between people
applied and work accomplished is entirely different. Both activities require the construction of a
“Product”, but the approach is different.

2. Software doesn't wear out:

Figure below shows the failure rate as a function of time for hardware.
The relationship, often called the "bathtub curve," indicates that hardware exhibits relatively high
failure rates early in its life (these failures are often attributable to design or manufacturing defects);
defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some
period of time. As time passes, however, the failure rate rises again as hardware components suffer
from the cumulative effects of just, vibration, abuse, temperature extremes, and many other
environmental changes. The hardware begins to wear out. Software is not susceptible to the
environmental changes that cause the hardware to wear out. Theoretically the failure rate curve for
the software should take the form shown below

Undiscovered defects will cause high failure rates early in the life of a program. They are corrected and
the curve flattens. So, the implications are software doesn't wear out but it does deteriorate

Practically, during its life, software will undergo change. As changes are made, it is likely that some
new defects will be introduced, causing the failure rate curve to spike as shown below

Before the curve can return to the original steady -state, another change is requested, causing the
curve to spike out. Slowly, the minimum failure rate level begins to rise the software is deteriorating
due to change.

3. Most software is custom -built, rather than being assembled from existing components:

Consider the manner in which the control hardware for a computer-based product is designed and
built: The design engineer draws a simple schematic of the digital circuitry, does some fundamental
analysis to ensure that proper function will be achieved, and then refers to the catalog of digital
components Each IC has a part number, a defined and validated function, a well -defined interface,
and a set of integration guidelines. After each component is selected, the circuit is implemented.

A software component should be designed and implemented so that it can be reused in different
programs since it is a better approach, according to finance and manpower. In the 1960s, we built
scientific subroutine libraries that were reusable in a broad array of engineering and scientific
applications. These subroutine libraries reused well-defined algorithms in an effective manner but had
a limited domain of application. Today, we have extended our view of reuse to encompass not only
algorithms but also data structure. Modern reusable components encapsulate both data and the
processing applied to the data, enabling the software engineer to create new applications from
reusable parts.

1.2 THE CHANGING NATURE OF SOFTWARE

Today seven broad categories of computer software present continuing challenges for software
engineers

➢ System software

• System software is a collection of programs written to service other programs

Or
• System software (systems software) is computer software designed to operate and control the
computer hardware and to provide a platform for running application software.

• System software can be separated into two different categories:

▪ Operating systems
▪ Utility software

Examples of system software and what each does:

• The operating system (prominent examples being z/OS, Microsoft Windows, Mac OS X and
Linux), allows the parts of a computer to work together by performing tasks like transferring
data between memory and disks or rendering output onto a display device. It also provides a
platform to run high-level system software and application software.
• The BIOS (basic input/output system) gets the computer system started after you turn it on and
 manages the data flow between the operating system and attached devices such as the hard
disk, video adapter, keyboard, mouse, and printer.
• The boot program loads the operating system into the computer's main memory or random
access memory (RAM).
• An assembler takes basic computer instructions and converts them into a pattern of bits that the
computer's processor can use to perform its basic operations.
• A device driver controls a particular type of device that is attached to your computer, such as a
keyboard or a mouse. The driver program converts the more general input/output instructions
of the operating system to messages that the device type can understand.
• According to some definitions, system software also includes system utilities, such as the disk
defragmenter and System Restore, and development tools such as compilers and debuggers. •
Utility software helps to analyze, configure, optimize and maintain the computer, such as virus
protection.

Or

In computers, a utility is a small program that provides an addition to the capabilities provided
by the operating system. In some usages, a utility is a special and nonessential part of the
operating system. The print "utility" that comes with the operating system is an example. It's
not absolutely required to run programs and, if it didn't come with the operating system, you
could perhaps add it. In other usages, a utility is an application that is very specialized and
relatively limited in capability. A good example is a search-and-replace utility. Some operating
systems provide a limited capability to do a search-and-replace for given character strings. You
can add a much more capable search-and-replace utility that runs as an application program.

Other examples of utility software:

• Antivirus software: Norton antivirus, McAfee virus scan, Avast

• File conversion (e.g. convert a sound file to MP3)
• For example, you may want to compress a file to let you save it on to a flash drive. For this
task you would choose to use a file compression utility program

Quite often, a utility program is built right in the operating system. For example
windows has a built in ‘zip’ compression utility you can use to compress a file or folder

(In windows Explorer Right click over the file so a menu pops up, the select “send to”
and you should see “compressed (zipped) folder” as an option

➢ Application software

• Application software (an application) is a set of computer programs designed to permit the
user to perform a group of coordinated functions, tasks, or activities. Application software
cannot run on itself but is dependent on system software to execute. Examples of an
application include a word processor, a spreadsheet design and management system, an
aeronautical flight simulator, a console game, a drawing, painting, and illustrating system, or a
 library management system

Or

• Application software run under System Software, and are made to do a specific task i.e. (Word
Processing etc), which have indirect access to the hardware (i.e. Behind System Software).

• Examples:

Web browser, word processing software, spreadsheet software, database software,

presentation graphics software.

1) Opera (Web Browser)

2) Microsoft Word (Word Processing)
3) Microsoft Excel (Spreadsheet software)
5) MySQL (Database Software)
6) Microsoft PowerPoint (Presentation Software)
7) iTunes (Music / Sound Software)
8) VLC Media Player (Audio / Video Software)
9) World of Warcraft (Game Software)
10) Adobe Photoshop (Graphics Software)

➢ Engineering/scientific software

Formerly characterized by “number crunching” algorithms, engineering and scientific software

applications ranging from astronomy to volcanology(is the study of volcanoes, lava, magma, and
related geological, geophysical and geochemical phenomena.).From automotive stress analysis to
space shuttle orbital dynamics and from molecular biology to automated manufacturing

Examples:

• CAD/CAM, CAE, CFD are different engineering and scientific software’s used in different
engineering branches
• CAD/CAM

✓ CAD/CAM (computer-aided design and computer-aided manufacturing) refers to

computer software that is used to both design and manufacture products.
✓ CAD is the use of computer technology for design and design documentation. ✓
CAD/CAM applications are used to both design a product and program manufacturing
processes, specifically, CNC machining. CAM software uses the models and assemblies
created in CAD software to generate tool paths that drive the machines that turn the
designs into physical parts. CAD/CAM software is most often used for machining of
prototypes and finished parts.
 • Computer-Aided Engineering (CAE)

✓ A CAE program is a mathematical model written in a programming language using a set

of algorithms that define the manufacturing processes.

✓ The process starts by first defining the analysis of the mathematical phenomenon. Next,
the equations have to be defined. Finally, a model of physical configuration is created.
This model may consist of 2-D or 3-D figures/shapes/curves/surfaces. This model is than
applied to an actual production mechanism to design and develop the product

✓ Computer aided engineering is complemented by computer-aided design and

computer-aided manufacturing.

“The technological challenge of the different scientific and engineering subjects has evolved from
the need of improving the detection instruments (to produce better CCDs in Astronomy, better
sequencing methods in Biotechnology, better particle detectors in High Energy Physics, etc.) to the
current status, in which the most critical issue is the management of the large amount of data
produced by the faster, more powerful and more capable instruments.”

➢ Embedded software

• Embedded software is a type of software that is built into hardware systems. This software
is typically designed to perform one specific function, although a single piece of
hardware may contain multiple pieces of software embedded in it. Any piece of
technology that has circuit boards and computer chips will likely have embedded
software within it, from digital clocks to cell phones to calculators. These systems allow
many of the advanced functions that are common in modern devices.
Or
• Software embedded in non-computer devices (e.g. cars, planes, cell phones, home
apliances such as refrigerators) through special-purpose processors

Examples:

• Typical examples of systems and applications that use embedded software include
home appliances, cell phones, traffic control systems, utility control systems,
automotive components and satellites.

➢ Product line software

• Designed to provide a specific capability for use by many different customers, product line
software can focus on a limited and esoteric market place(e.g., inventory control products)
or address mass consumer markets(e.g., word processing, spread sheets, computer
graphics, multimedia, entertainment, database management, personal and business
 financial applications

➢ WebApps (Web applications)

• “WebApps” span a wide array of applications. In their simplest form, web apps can be little
more than a set of linked hypertext files that present information using text and limited
graphics
Or

• A web application or web app is any program that runs in a web browser. It is created in a
browser-supported programming language (such as the combination of JavaScript, HTML and
CSS) and relies on a web browser to render the application

Examples:

• Google Docs - it lets you create your documents (like Word), spreadsheets, presentations
and more. It also allows you to collaborate and share documents.

• TokBox a great online video chatting applications. For free users, you can chat up to 20
people. Just simply sign up, invite your friends and start video chatting.

• icloud - web operating system over the web. It is like bringing your own desktop and files
running in your web browser that includes an office suite, media player, chat client,
games, productivity tool, utility applications and more. Now you won’t worry that you
are working in a different PC.

➢ Artificial intelligence:

• Artificial Intelligence is a way of making a computer, a computer-controlled robot, or a

software think intelligently, in the similar manner the intelligent humans think.

• AI is accomplished by studying how human brain thinks and how humans learn, decide,
and work while trying to solve a problem, and then using the outcomes of this study as
a basis of developing intelligent software and systems.

• Applications with this area includes robotics, expert system, pattern recognisation,
artificial neutral networks, theorem proving, and game playing

Hundreds of thousands of computer programs fall into one of the seven broad application domains
➢ Legacy software:

• Legacy software are older programs that are developed decades ago.

• The quality of legacy software is poor because it has inextensible design, convoluted code, poor
 and nonexistent documentation, test cases and results that are not achieved

• As time passes legacy systems evolve due to following reasons:

✓ The software must be adapted to meet the needs of new computing environment or
technology.

✓ The software must be enhanced to implement new business requirements.

✓ The software must be extended to make it interoperable with more modern systems or
database

✓ The software must be rearchitected to make it viable within a network environment

A GENERIC VIEW OF PROCESS

1.3 SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY

Although hundreds of authors have developed personal definitions of software engineering, a

definition proposed by Fritz Bauer 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. “

Almost every reader will be tempted to add to this definition. It says little about the technical
aspects of software quality; it does not directly address the need for customer satisfaction or timely
product delivery; it omits mention of the importance of measurement and metrics; it does not state
the importance of a mature process. And yet, Bauer’s definition provides us with a baseline. What are
the “sound engineering principles” that can be applied to computer software development? How do
we “economically” build software so that it is “reliable”? What is required to create computer
programs that work “efficiently” on not one but many different “real machines”? These are the
questions that continue to challenge software engineers.

The IEEE [IEE93] has developed a more comprehensive definition when it states;

“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) “.

1.4.1 Process, Methods, and Tools

Software engineering is a layered technology. Most engineering approaches (including software
engineering) must rest on an organizational commitment to quality. The bedrock that supports
software engineering is a quality focus layer.
Quality: a product should meet its specification. This is problematical for software systems. There is a
tension between customer quality requirements (efficiency, reliability, etc.), developer quality
requirements (maintainability, reusability, etc.), users (usability, efficiency, etc.), and etc. But note:
✓ Some quality requirements are difficult to specify in an unambiguous way.
✓ Software specifications are usually incomplete and often inconsistent.
Process: The foundation for software engineering is the process layer. Software engineering
process is the glue that holds the technology together and enables rational and timely development of
computer software. The work products are produced, milestones are established, quality is ensured,
and changes are properly managed.
Methods: Software engineering methods provides the technical how-to‘s for building
software. Methods encompass a broad array of tasks that include the requirements analysis, design,
program construction, testing, and support.
Tools: Software engineering tools provide automated or semi-automated supports for the
process and the methods. When the tools are integrated so that the information created by one tool
can be used by another, a system for the support of software development, called computer-aided
software engineering (CASE). CASE combine software, hardware, and software engineering database.

1.4 A PROCESS FRAMEWORK

software process: a hierarchical collection of process steps hierarchical means that a process step
can in turn have sub-steps

Generic Process Framework activities

• Communication (customer collaboration and requirement gathering)

• Planning (establishes engineering work plan, describes technical risks, lists resource requirements,
work products produced, and defines work schedule)
• Modeling (creation of models to help developers and customers understand the requires and
software design)
• Construction (code generation and testing)
• Deployment (software delivered for customer evaluation and feedback)

These five generic framework activities can be used during the development of small programs the
creation of large web applications, and for the engineering of large, complex computer-based systems.
The detail of software process will be quite different in each case, but the framework activities remain
same

Ex: modeling activity is composed of two engineering actions: analysis and design analysis
encompasses a set of work tasks (eg., requirement gathering,elaboration,specification, and
validation)the lead to the creation analysis model encompasses of data models, architectural design
and component-level design

Umbrella activities

The phases and related steps described in our generic view of software Engineering are
complemented by a number of umbrella activities. Typical activities in this category include:

• Software project tracking and control (allows team to assess progress and take corrective action to
maintain schedule)
• Risk management (assess risks that may affect project outcomes or quality)
• Software quality assurance (activities required to maintain software quality) • Formal technical
reviews (assess engineering work products to uncover and remove errors before they propagate to
next activity)
• Measurement (define and collect process, project, and product measures to assist the software
team in delivering software meeting customer needs)
• Software configuration management (manage effects of change)
• Reusability management (defines criteria for work product reuse and establishes mechanisms to
achieve component reuse)
• Work product preparation and production (activities to create models, documents, logs, forms, lists,
etc.)
Attributes for Comparing Process Models

• Overall flow and level of interdependencies among tasks

• Degree to which work tasks are defined within each framework activity
• Degree to which work products are identified and required
• Manner in which quality assurance activities are applied
• Manner in which project tracking and control activities are applied
• Overall degree of detail and rigor of process description
• Degree to which stakeholders are involved in the project
• Level of autonomy given to project team
• Degree to which team organization and roles are prescribed

1.5 CMMI (CAPABILITY MATURITY MODEL INTEGRATION)

• Level 0: Incomplete (process is not performed)

• Level 1: Performed (tasks are being conducted)
• Level 2: Managed (tasks and products are monitored, reviewed, and evaluated for
conformance to process description)
• Level 3: Defined (processes documented, standardized, and integrated into
organization-wide software process)
• Level 4: Quantitatively Managed (software process and products are quantitatively
understood and controlled using detailed measures)
• Level 5: Optimizing (continuous process improvement is enabled by quantitative
feedback from the process and testing innovative ideas)

A maturity level is a well-defined evolutionary plateau toward achieving a mature software process.
Each maturity level provides a layer in the foundation for continuous process improvement. In CMMI
models with a staged representation, there are five maturity levels designated by the numbers 1
through 5
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
 List of CMMI level companies:

• Cognizant Technology Solutions

• Hewlett Packard India Software Operations Limited
• Hexaware Technologies Limited
• Honeywell India S/w Operations IBM Global Services
• Infosys Technologies Limited
• InfoTech Enterprises Limited
• Intergraph Consulting Pvt. Ltd
• Philips Software Centre Private
• Tata Consultancy Services
• Wipro Technologies
• LG Soft India Pvt. Ltd
• Larsen & Turbo InfoTech Limited,
• Sonata Software Limited
• Robert Bosch India Limited

1.6 PROCESS PATTERNS

• A process pattern is

• describes a process-related problem that is encountered during software engineering

work

• identifies the environment in which the problem has been encountered, and •

Suggests one or more proven solutions to the problem.

• Stated in more general terms, a process pattern provides you with a template [Amb98]—a
consistent method for describing problem solutions within the context of the software process.

(Defined at different levels of abstraction)

✓ Problems and solutions associated with a complete process model (e.g. prototyping).
 ✓ Problems and solutions associated with a framework activity (e.g. planning) or ✓ An

action with a framework activity (e.g. project estimating).

Template of a process pattern

Pattern name: Pattern given a meaningful name that describes its function within the process

Intent: The objective of the pattern is described briefly

Types of patterns

Task patterns—defines a problem associated with a software engineering action or work task and
relevant to successful software engineering practice

Stage patterns—defines a problem associated with a framework activity for the process. It includes
multiple task patterns as well. For example, establishing Communication would incorporate the task
pattern Requirements Gathering and others.

Phase patterns—define the sequence of framework activities that occur with the process, even when
the overall flow of activities is iterative in nature. Example includes Spiral Model or Prototyping

Initial context: the conditions under which the pattern applies are described prior to the initiation of
the pattern we ask (1) what organizational or team related activities have already occurred (2) what is
entry state for the process and (3)what software engineering information or project information
already exists

Problem: The problem to be solved

Solution: The implementation of the pattern is described. How the initial state of the process(that
exists before the pattern is implemented)is modified as a consequence the initiation of the pattern.

Resulting context: the conditions that will result once are the pattern has been successfully
implemented are. Upon completion of the pattern we ask (1) what organizational or team related
activities have occurred (2) what is exit state for the process and (3)what software engineering
information or project information has been developed

Related patterns: A list of all process patterns that are directly related to this one are provided-as a
hierarchy or in some other diagrammatic form

Known uses/examples: the specific instances in which the pattern is applicable are indicated

Example of Process pattern:

Describes an approach that may be applicable when stakeholders have a general idea of what must be
done but are unsure of specific software requirements.

• Pattern name: Requirements Unclear

• Intent: This pattern describes an approach for building a model that can be assessed iteratively
 by stakeholders in an effort to identify or solidify software requirements.

• Type: Phase pattern

• Initial context. Conditions must be met (1) stakeholders have been identified; (2) a mode of
communication between stakeholders and the software team has been established; (3) the
overriding software problem to be solved has been identified by stakeholders ; (4) an initial
understanding of project scope, basic business requirements and project constraints has been
developed.

• Problem: Requirements are hazy or nonexistent. stakeholders are unsure of what they want. •

Solution: A description of the prototyping process would be presented here.

• Resulting context: A software prototype that identifies basic requirements. (Modes of

interaction, computational features, processing functions) is approved by stakeholders.
Following this, 1. This prototype may evolve through a series of increments to become the
production software or 2. The prototype may be discarded.

• Related patterns: Customer Communication, Iterative Design, Iterative Development, Customer

Assessment, Requirement Extraction.

1.7 PROCESS ASSESSMENT

• The existence of software process does not guarantee the timely delivery of the software and its
ability to meet the user's expectations. The process needs to be assessed in order to ensure
that it meets a set of basic process criteria, which is essential for implementing the principles
of software engineering in an efficient manner. The process is assessed to evaluate methods,
tools, and practices, which are used to develop and test the software. The aim of process
assessment is to identify the areas for improvement and suggest a plan for making that
improvement. The main focus areas of process assessment are listed below.
✓ Obtaining guidance for improving software development and test processes
✓ Obtaining an independent and unbiased review of the process
✓ Obtaining a baseline (defined as a set of software components and documents
that have been formerly reviewed and accepted; that serves as the basis for
further development) for improving quality and productivity of processes.
• Software process assessment examines whether the software processes are effective and
efficient in accomplishing the goals. This is determined by the capability of selected software
processes. The capability of a process determines whether a process with some variations is
capable of meeting user's requirements. In addition, it measures the extent to which the
software process meets the user's requirements. Process assessment is useful to the
organization as it helps in improving the existing processes. In addition, it determines the
strengths, weaknesses and the risks involved in the processes.
 • The
process assessment leads to process capability determination and process improvement. Process
capability determination is an organized assessment, which analyzes the software processes in an
organization. In addition, process capability determination identifies the capabilities of a process
and the risks involved in it. The process improvement identifies the changes to be made in the
software processes. The software capability determination motivates the organization to perform
software process improvement.
Different approaches are used for assessing software process. These approaches are

• SPICE (ISO/IEC15504)
• ISO 9001:2000
• Standard CMMI assessment method for process improvement (SCAMPI)
• CMM-based appraisal for internal process improvement (CBA-IPI)

• SPICE (Software Process Improvement and Capability Determination) is a standard used for
both process improvement and process capability determination. SPICE provides a
framework for assessing the software process and is used by the organizations involved in
planning, monitoring, developing, managing, and improving acquisitions. It is carried out in
accordance with the International Organization for Standardization (ISO) and International
Electro-technical Committee (IEC), which are used together and known as ISO/IEC 15504.
The functions of SPICE (ISO/IEC 15504) are listed below.

✓ To develop process-rating profiles instead of pass or fail criteria

✓ To consider the environment in which the assessed process operates
✓ To facilitate self assessment
✓ To ensure suitability for all applications and all sizes of organizations.

This model is known as SPICE reference model. It is applicable for all processes and comprises
following six levels.

✓ Not performed: At this level, the processes are unable to accomplish the required
outcomes. Thus, no identifiable products are created.
✓ Performed informally: At this level, the implemented process accomplishes the defined
outcomes. It is not planned and tracked; rather it depends on individual knowledge and
identifiable products.
 ✓ Planned and tracked: At this level, the defined process delivers products according to
quality requirements within a specified time. The processes and products are verified
according to the procedures, standards, and requirements.
✓ Well-defined: At this level, the processes based on software engineering principles
which are capable of achieving defined outcomes are used.
✓ Quantitatively controlled: At this level, the performance measures, prediction
capability and objective management are evaluated quantitatively. In addition, existing
processes perform consistently within the defined limits to accomplish the desired outputs.
✓ Continuously improved: At this level, the existing processes adapt to meet future
business goals. For continuous improvement, various kinds of statistical methods are used.

• ISO (International Organization for Standardization) established a standard known as ISO

9001:2000 to determine the requirements of quality management systems. A quality
management system refers to the activities within an organization, which satisfies the quality
related expectations of customers. Organizations ensure that they have a quality management
system by demonstrating their conformance to the ISO 9001:2000 standard. The major
advantage of this standard is that it achieves a better understanding and consistency of all
quality practices throughout the organization. In addition, it strengthens the customer's
confidence in the product. This standard follows a plan-do-check-act (PDCA) cycle, which
includes a set of activities that are listed below.

✓ Plan: Determines the processes and resources which are required to develop a quality
product according to the user's satisfaction.
✓ Do: Performs activities according to the plan to create the desired product. ✓ Check:
Measures whether the activities for establishing quality management according to the
requirements are accomplished. In addition, it monitors the processes and takes corrective
actions to improve them.
✓ Act: Initiates activities which constantly improve processes in the organization.

Note: The standard ISO 9001:2000 enhances the quality of a product by utilizing the processes for
continual improvement of the system.
 • CBA-IPI tool is used in an organization to gain insight into the software development capability.
For this, the strengths and weaknesses of the existing process are identified in order to
prioritize software improvement plans and focus on software improvements, which are
beneficial to the organization. The organization's software process capability is assessed by a
group of individuals known as the assessment team, which generates findings and provides
ratings according to the CMM (Capability Maturity Model). These findings are collected from
questionnaires, document reviews and interviews with the managers of the organization. Thus,
the primary goal of CBA IPI is to provide an actual picture of the existing processes in an
organization. To achieve this, the assessment team performs the following functions.

1. Provides data as a baseline to the organization in order to check its software capability
2. Identifies issues that have an impact on the process improvement
3. Provides sufficiently complete findings to the organization. These are used to guide the
organization in planning .and prioritizing future process improvement activities.

• SCAMPI: An appraisal examines processes to determine their strengths and weaknesses in an

organization. The appraisal used in an organization evaluates the internal processes (series of
procedures occurring in the organization) for establishing or updating process improvement. In
addition, appraisal includes measuring the process improvement progress by conducting audits
of the processes. To conduct an appraisal, a scheme known as SCAMPI was developed by the
Software Engineering Institute (SEI). Capability Maturity Model Integration (CMMI) as an
improved framework. The objectives of SCAMPI are listed below.
1. To identify strengths and weaknesses of existing processes in the organization 2. To
specify an integrated appraisal method for internal process improvement 3. To act as a
motivation for initiating and focusing on software process improvement.
PROCESS MODELS

The Waterfall model, Incremental model, RAD model, Prototyping, Spiral

model, Concurrent Development model, The Unified process, Agile process
models.(scrum, agile modeling)

Process model(definition):

Process Model describes the sequence of phases for the entire lifetime of a product. Therefore it is
sometimes also called Product Life Cycle. This covers everything from the initial commercial idea until
the final de-installation or disassembling of the product after its use.

Usually there are three main phases:

• concept phase
• implementation phase
 • maintenance phase

Each of these main phases usually has some sub-phases, like a requirements engineering phase, a
design phase, a build phase and a testing phase. The sub-phases may occur in more than one main
phase each of them with a specific peculiarity depending on the main phase.

Besides the phases a Process Model shall also define at least:

• The activities that have to be carried out in each of the sub-phases, including the sequence in
which these activities have to be carried out.
• The roles of the executors that have to carry out the activities, including a description of their
responsibilities and required skills.
• The work products that have to be established or updated in each of the activities. Besides the
final product there are usually several other items that have to be generated during the
development of a product. These are for example requirements and design document, test
specifications and test reports, etc.

Therefore, a Process Model provides a fixed framework that guides a project in:

• Development of the product

• Planning and organizing the project
• Tracking and running the project

• A software development process is carried out as a series of certain activities, referred as a

phase.
• Each phase in the process again acts as a process for performing activities includes feasibility
study, analysis, design, coding, testing, implementation, and maintenance.
• These activities are called the Software Development Life Cycle (SDLC) or simply software life
cycle and each of these activities is called life cycle phase.
• The activities involved in Software Development Life Cycle(SDLC) are
o Project initiation(feasibility study)
o Requirement analysis
o Software design
o Coding
o Testing
o Deployment
o Maintenance
 Software Development Life Cycle Phases

Project initiation / Feasibility Study

• The aim of project initiation is to study the existing system; determine the feasibility of a new
system; and define the scope, key elements, and a plan for the successful completion of the
project.
• Preliminary Investigation (PI) is the initial step that gives a clear picture of what actually the
physical system is.
• PI goes through the problem identification, background of physical system, and the system
proposal for a candidate system. On the basis of this study, a feasibility study is performed
• The purpose of feasibility study is to determine whether the implementation of the proposed
system will support the mission and objectives of the organization.
• Feasibility study ensures that the candidate system is able to satisfy the user needs; promotes
operational, effective use of resources; and is cost effective.
• There are various types of feasibility study performed, such as technical, economical, operational
and so on.
o Technical feasibility refers to the availability of and expertise on technology in terms
of hardware and software for the successful completion of a project.
o Economic feasibility is used to evaluate effectiveness of the system in terms of
benefits and cost saving in a candidate system. Cost benefit analysis is carried out to
determine economic feasibility.
o Operational feasibility states the system will meet the scope and problems of the
users.

Requirement analysis
 • Requirement analysis is the process of collecting factual data, understanding the process
involved, defining the problem, and providing a document for further software development.
• It is a systematic approach to elicit, organize, and document the requirements of a system.
• Requirements engineering is the process for identification and the translation of the
stakeholder's needs to the system requirement.
• The Requirement analysis phase consists of three main activities such as Requirements
elicitation, Requirements specification, Requirements verification and validation.
• Requirement elicitation is about understanding the problem. Once the problem has been
understood, it is described in the requirement specification document, which is referred to as
software requirements specification (SRS).
• This document describes the product to be delivered, not the process of how it to be developed.
• Requirements verification and validation ascertain that correct requirements are stated
(validation) and that these requirements are stated correctly (verification).

Software design

• Software design is the process of transforming the collected requirements into a structure that is
suitable for implementation in programming languages.
• It focuses on the solution domain of the project on the basis of the requirements document
prepared during the analysis phase.
• It places stress on how to develop the product.
• The Software designer begins with making architectures, outlining the hierarchical structure and
writing algorithms for each component in the system.
• The Software designer uses some design methodology to produce a design structure using
defined rules and techniques.
• The design phase has two aspects: physical design and logic design.
o Physical design is also called high-level design. A high level design concentrates on
identifying the different modules or components in a system that interacts with each
other to create the architecture of the system. Thereafter, file design, I/O design, data
structure design, interface design and procedural design are performed.
o In logical design, which is also known as detailed design, the internal logic of a module or
component is described in a pseudo code or algorithm manner.

Coding

• The coding phase is concerned with the development of the source code that will implement the
design.
• This code is written in a formal language called a programming language, such as assembly
language, C++, Java, etc.
• While programming, good coding efforts can reduce texting and maintenance tasks.
• Programs can be modular so that they can help in rapid development, maintenance and
 enhancements of the system.

Testing

• Testing is performed to remove defects in the developed system.

• Testing is an important technique of software quality assurance.
• After the coding phase, a test of system is developed and run on the specified test data.
• Test plan can be refined during test specification and a test report is prepared in each module,
which helps to find initial flaws in design and development.
• Testing covers various errors at requirement, design and coding phases.
• Requirement errors may arise due to improper understanding of customer needs. •
Design errors occur if algorithms are not properly implemented during coding. •
Coding errors are mainly logical and syntactical errors.
• Testing is performed at different levels: unit testing, integration testing, system testing, and
accepting testing.
• Unit testing is carried out for individual modules at the code level.
• After testing each module, interfaces among various modules are checked with integration
testing.
• System test ensures that system satisfies the requirements specified by the customer. •
Acceptance test is done for the customer satisfaction.
• Various special tests are also performed to check functionality of system, such as recovery
testing, load testing, security testing and so on.
Deployment
• Deployment is the process of loading all the programs files onto user’s computer. •
The purpose of deployment is to make the software available for operational use.
• It includes various activities to make a system available for assembly and to transfer it to the
customer site.
• Required resources are procured to operate at the customer site and important information is
collected for the deployment process.
• Documentation of the system is also an important activity in software development. •
Documentation is in the form of a user manual.
• User documentation is the description of the system from the user’s point of view, detailing how
to use or operate the system.
• System documentation contains the details of architectures, programs, system flow, data
dictionary, process description.

Maintenance

• Software maintenance is performed to adapt to changes in a new environment, correct bugs and
 enhance performance by adding new features.
• The maintenance process may be performed in any work product or documentation.
• The maintenance activities can be classified as adaptive (changes in the software environment),
perfective (new user requirements), corrective (fixing errors), preventive (prevent problems in
the future).

2.1 WATERFALL MODEL

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each
phase must be completed fully before the next phase can begin. This type of model is basically used
for the for the project which is small and there are no uncertain requirements. At the end of each
phase, a review takes place to determine if the project is on the right path and whether or not to
continue or discard the project. In this model the testing starts only after the development is
complete. In waterfall model phases do not overlap.

Diagram of Waterfall-model:

A variation in the representation of the waterfall model is called the V-model. Represented in
below Figure the V-model [Buc99] depicts the relationship of quality assurance actions to the actions
associated with communication, modeling, and early construction activities. As a software team
moves down the left side of the V, basic problem requirements are refined into progressively more
detailed and technical representations of the problem and its solution. Once code has been generated,
the team moves up the right side of the V, essentially performing a series of tests (quality assurance
actions) that validate each of the models created as the team moved down the left side.7 In reality,
there is no fundamental difference between the classic life cycle and the V-model. The V model
provides a way of visualizing how verification and validation actions are applied to earlier engineering
work.
Advantages of waterfall model:
• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a
review process.
• In this model phases are processed and completed one at a time. Phases do not overlap. •
Waterfall model works well for smaller projects where requirements are very well understood.

Disadvantages of waterfall model:

• Once an application is in the testing stage, it is very difficult to go back and change something
that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

• This model is used only when the requirements are very well known, clear and fixed. •
Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.

Very less customer enter action is involved during the development of the product. Once the product
is ready then only it can be demoed to the end users. Once the product is developed and if any failure
occurs then the cost of fixing such issues are very high, because we need to update everywhere from
document till the logic.

Verification is the process of checking that a software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have. Verification is static testing. Verification
means Are we building the product right?

Validation is the process of checking whether the software product is up to the mark or in other words
product has high level requirements. It is the process of checking the validation of product i.e. it
checks what we are developing is the right product. it is validation of actual and expected product.
Validation is the dynamic testing.
Validation means Are we building the right product?

2.2 INCREMENTAL MODEL

In incremental model the whole requirement is divided into various builds. Multiple development
cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed modules. Each module passes through the requirements, design,
implementation and testing phases. A working version of software is produced during the first
module, so you have working software early on during the software life cycle. Each subsequent release
of the module adds function to the previous release. The process continues till the complete system is
achieved.
Diagram of Incremental model:

The first increment is often a core product where the basic requirements are addressed and the
supplementary features are added in the next increments. The core product is used and evaluated by
the client. Once the core product is evaluated by the client there is plan development for the next
increment. Thus in every increment the needs of the client are kept in mind and more features and
functions are added and the core product is updated. This process continues till the complete product
is produced.

The increments earlier to the main increment are called as “stripped down” versions of the final
product. These increments form a base for customer evaluation. On this basis client can suggest new
requirements if required.

For example:
In the diagram above when we work incrementally we are adding piece by piece but expect that each
piece is fully finished. Thus keep on adding the pieces until it’s complete. As in the image above a
person has thought of the application. Then he started building it and in the first iteration the first
module of the application or product is totally ready and can be demoed to the customers. Likewise in
the second iteration the other module is ready and integrated with the first module. Similarly, in the
third iteration the whole product is ready and integrated. Hence, the product got ready step by step.

Advantages of Incremental model:

• Generates working software quickly and early during the software life cycle. •
This model is more flexible – less costly to change scope and requirements. • It
is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled during it’d iteration.

Disadvantages of Incremental model:

• Needs good planning and design.

• Needs a clear and complete definition of the whole system before it can be broken down and
built incrementally.
• Total cost is higher than waterfall.

When to use the Incremental model:

• This model can be used when the requirements of the complete system are clearly defined and
understood.
• Major requirements must be defined; however, some details can evolve with time. •
There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.

Evolutionary Process Models

Software, like all complex systems, evolves over a period of time. Business and product requirements
often change as development proceeds, making a straight line path to an end product unrealistic; tight
market deadlines make completion of a comprehensive software product impossible, but a limited
version must be introduced to meet competitive or business pressure; a set of core product or system
requirements is well understood, but the details of product or system extensions have yet to be
defined. In these and similar situations, you need a process model that has been explicitly designed to
accommodate a product that evolves over time. Evolutionary models are iterative.Evolutionary models
are iterative.

Prototyping model of SDLC:-

Often, a customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features. In other cases, the developer may be unsure of the efficiency
of an algorithm, the adaptability of an operating system, or the form that human-machine interaction
should take.

The basic idea here is that instead of freezing the requirements before a design or coding can
proceed, a throwaway prototype is built to understand the requirements. This prototype is developed
based on the currently known requirements. By using this prototype, the client can get an “actual feel”
of the system, since the interactions with prototype 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 determining the
requirements.

The prototype are usually not complete systems and many of the details are not built in the
prototype. The goal is to provide a system with overall functionality.
Diagram of Prototype model:

Advantages of Prototype model:

• Users are actively involved in the development
• Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
 • Requirements validation, Quick implementation of, incomplete, but functional, application.

Disadvantages of Prototype model:

• Leads to implementing and then repairing way of building systems.

• Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
• Incomplete application may cause application not to be used as thefull system was designed •
Incomplete or inadequate problem analysis.

When to use Prototype model:

• Prototype model should be used when the desired system needs to have a lot of interaction with
the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end users,
are best suited for Prototype model. It might take a while for a system to be built that allows
ease of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.

2.5 Spiral model:

• The spiral model is an evolutionary Software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the waterfall model. • It has two
distinguishing features:

a. A cyclic approach for incrementally growing a system’s degree of definition and

implementation while decreasing its degree of risk.
b. A set of anchor point milestones for ensuring stakeholder commitment to
feasible and mutually satisfactory solutions.
• Using the spiral model, Software is developed in a series of evolutionary releases. •
During early stages, the release might be a paper model or prototype.
• During later iterations, increasingly more complete versions of the engineered system are
produced.
• A spiral model is divided into a set of framework activities divided by the Software engineering
team.
• As this evolutionary process begins, the Software team performs activities that are implied by a
circuit around the spiral in a clockwise direction, beginning at the center.

Risk is considered as each revolution is made.

1. Anchor-point milestones – a combination of work products and conditions that are

attained along the path of the spiral- are noted for each evolutionary pass.
2. The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the Software.
 3. Each pass through the planning region results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback derived from the customer after delivery. 4.
Unlike other process models that end when Software is delivered, the spiral model can be
adapted to apply throughout the life of the Software.
Diagram of Spiral model:

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral model:

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

When to use Spiral model:

• When costs and risk evaluation is important

• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic priorities •
Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)
2.6 CONCURRENT DEVELOPMENT MODEL
 The concurrent development model, sometimes called concurrent engineering, can be
represented schematically as a series of framework activities, Software engineering actions of
tasks, and their associated states.

The concurrent model is often more appropriate for system engineering projects where
different engineering teams are involved.

none

Modeling act ivit y

represents the state
of a software engineering
Under activity or task
development

Await ing
changes

Under review

Under

revision

Baselined

Done

Figure above provides a schematic representation of one Software engineering task within the
modeling activity for the concurrent process model. The activity – modeling- may be in any one of the
states noted at any given time.

All activities exist concurrently but reside in different states.

For example, early in the project the communication activity has completed its first iteration
and exists in the awaiting changes state. The modeling activity which existed in the none state while
initial communication was completed now makes a transition into underdevelopment state.

If, however, the customer indicates the changes in requirements must be made, the modeling
activity moves from the under development state into the awaiting changes state.

The concurrent process model defines a series of events that will trigger transitions from state
to state for each of the Software engineering activities, actions, or tasks.

2.7 UNIFIED PROCESS

A “use-case driven, architecture-centric, iterative and incremental” software process closely

aligned with the Unified Modeling Language (UML).

The UP is an attempt to draw on the best features and characteristics of conventional software
process models, but characterize them in a way that implements many of the best principles of agile
software development.

The UP recognizes the importance of customer communication and streamlined methods for
describing the customer’s view of a system.
It emphasizes the important role of software architecture and “helps the architect focus on the
right goals, such as understandability, reliance to future changes, and reuse.”

UML provides the necessary technology to support Object Oriented Software Engineering
practice, but it doesn’t provide the process framework to guide project teams in their application of
the technology.

The UML developers developed the Unified Process, a framework Object Oriented Software
Engineering using UML.

2.7.1 Phases of the Unified Process

The figure below depicts the phases of the UP and relates them to the generic activities.

The Inception phase of the UP encompasses both customer communication and planning
activities.

By collaborating with the customer and end-users, business requirements for the software are
identified, a rough architecture for the system is proposed, and a plan for the iterative, incremental
nature of the ensuing project is developed.

Elaborat ion

Incept ion

construct ion
Release transit ion
soft ware increment

product ion

A use-case describes a sequence of actions that are performed by an actor (person, machine, another
system) as the actor interacts with the Software.

The elaboration phase encompasses the customer communication and modeling activities of
the generic process model. Elaboration refines and expands the preliminary use-cases that were
developed as part of the inception phase and expands the architectural representation to include five
different views of the software - the use-case model, the analysis model, the design model, the
implementation model, and the deployment model.

The construction phase of the UP is identical to the construction activity defined for the
generic software process.
 Using the architectural model as input, the construction phase develops or acquires the
software components that will make each use-case operational for end-users.
The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment activity.

Software is given to end-users for beta testing, and user feedback reports both defects and
necessary changes.

At the conclusion of the transition phase, the software increment becomes a usable software
release “user manuals, trouble-shooting guides, and installation procedures.)

The production phase of the UP coincides with the development activity of the generic
process.

The on-going use of the software is monitored, support for the operating environment is
provided and defect reports and requests for changes are submitted and evaluated.

2.8 AGILE PROCESS MODELS

Agile =able to move quickly and easily.

Agile manifesto:

By "uncovering better ways of developing software by doing it and helping others do it," they have
come to value Individuals and interactions over Processes and tools, Working software over
Comprehensive documentation, Customer collaboration over Contract negotiation, and Responding to
change over Following a plan.

• Individuals and interactions: self-organization and motivation are important, as are interactions
like co-location and pair programming.
• Working software: working software is more useful and welcome than just presenting documents
to clients in meetings.
• Customer collaboration: requirements cannot be fully collected at the beginning of the software
development cycle, therefore continuous customer or stakeholder involvement is very
important.
• Responding to change: agile methods are focused on quick responses to change and continuous
development.

What is agility

• Effective (rapid and adaptive) response to change (team members, new technology,
requirements)!
• Effective communication in structure and attitudes among all team members, technological and
business people, software engineers and managers
 • Drawing the customer into the team. Eliminate “us and them” attitude. Planning in an
uncertain world has its limits and plan must be flexible.
• Organizing a team so that it is in control of the work performed! Eliminate all but the
most essential work products and keep them lean.
• Emphasize an incremental delivery strategy as opposed to intermediate products that gets
working software to the customer as rapidly as feasible.
• Rapid, incremental delivery of software
• The development guidelines stress delivery over analysis and design although these activates are
not discouraged, and active and continuous communication between developers and
customers.

An agile process

• Is driven by customer descriptions of what is required (scenarios). Some assumptions:

➢ Recognizes that plans are short-lived (some requirements will persist, some will
Change. Customer priorities will change)
➢ Develops software iteratively with a heavy emphasis on construction activities
(Design and construction are interleaved, hardto say how much design is
Necessary before construction. Design models are proven as they are created. )
➢ Analysis, design, construction and testing are not predictable.
• Thus has to Adapt as changes occur due to unpredictability
• Delivers multiple ‘software increments’, deliver an operational prototype or portion of an OS to
collect customer feedback for adaption

Agile principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
• Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
• Business people and developers must work together daily throughout the project. • Build
projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development
team is face–to–face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility. • Simplicity – the
art of maximizing the amount of work not done – is essential. • The best architectures,
 requirements, and designs emerge from self–organizing teams. • At regular intervals, the team
reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Human factors

• The process molds to the needs of the peopleand team,not theother way around •
key traits must exist among the people on an agile team andthe team itself o
competence(( talent, skills, knowledge)
o Common focus. ( deliver a working software)
o Collaboration. ( peers and stakeholders)
o Decision-making ability. ( freedom to control its own destiny)
o Fuzzy problem-solving ability.(ambiguity and constant changes, today problem may not
be tomorrow’s problem)
o Mutual trust and respect
o Self-organization. ( themselves for the work done, process for its local environment, the
work schedule)

Types in agile model

The various agile Scrum methodologies share much of the same philosophy, as well as many of the
same characteristics and practices. But from an implementation standpoint, each has its own recipe of
practices, terminology, and tactics. Here we have summarized a few of the main agile software
development methodology contenders:

Agile methodologies do not refer to one specific approach but are a group of individual methodology
that implement agile principles. Several agile methods that have been developed are:

• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal Methods
• Feature Driven Development
• Agile Modeling
• Extreme Programming (XP)
• Adaptive Software Development

SCRUM:
 • Scrum is another popular agile framework with a set of roles and practices.
• In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with
each other to get a job done. In software development, the job is to put out a release.
• Scrum for software development came out of the rapid prototyping community because
prototypers wanted a methodology that would support an environment in which the
requirements were not only incomplete at the start, but also could change rapidly during
development. Unlike XP, Scrum methodology includes both managerial and development
processes.
Scrum Management
• At the center of each Scrum project is a backlog of work to be done. This backlog is populated
during the planning phase of a release and defines the scope of the release.
• After the team completes the project scope and high-level designs, it divides the development
process into a series of short iterations called sprints.
• Each sprint aims to implement a fixed number of backlog items. Before each sprint, the team
members identify the backlog items for the sprint. At the end of a sprint, the team reviews the
sprint to articulate lessons learned and check progress.
• During a sprint, the team has a daily meeting called a scrum. Each team member describes the
work to be done that day, progress from the day before, and any blocks that must be cleared.
To keep the meetings short, the scrum is supposed to be conducted with everyone in the same
room—standing up for the whole meeting.
• When enough of the backlog has been implemented so that the end users believe the release is
worth putting into production, management closes development.
• The team then performs integration testing, training, and documentation as necessary for
product release.
Scrum development
• The Scrum development process concentrates on managing sprints. Before each sprint begins,
the team plans the sprint, identifying the backlog items and assigning teams to these items.
Teams develop, wrap, review, and adjust each of the backlog items.
• During development, the team determines the changes necessary to implement a backlog item.
The team then writes the code, tests it, and documents the changes.
• During wrap, the team creates the executable necessary to demonstrate the changes.
• In review, the team demonstrates the new features, adds new backlog items, and assesses risk.
Finally, the team consolidates data from the review to update the changes as necessary.
• Following each sprint, the entire team including management, users, and other interested parties
demonstrates progress from the sprint and reviews the backlog progress.
• The team then reviews the remaining backlog and adds, removes, or reprioritizes items as
necessary to account for new information and understanding gathered during the sprint.
The Scrum process
Scrum Process
• There are two roles in the scrum process: pigs and chickens.
 • Pigs group includes product owner, scrum master, and a scrum team.
• The product owner represents the voice of the customer.
• The Scrum master is the enforcer of the Scrum process and he facilitates the team to reach the
sprint goal.
• Scrum is a cross functional team, which includes all the expertise necessary to deliver a quality
product.
• The group “chickens” involves users, stakeholders, and managers.
• In the Scrum process, product backlog describes “what” will be built, which is managed by the
product owner.
Scrum concepts
Here are a few of the most important concepts:
• Burn down cart. This chart, updated every day, shows the work remaining within the sprint. The
burn down chart is used both to track sprint progress and to decide when items must be
removed from the sprint backlog and deferred to the next sprint.
• Product backlog. Product backlog is the complete list of requirements—including bugs,
enhancement requests, and usability and performance improvements—that are not currently
in the product release.
• Scrum Master. The Scrum Master is the person responsible for managing the Scrum project.
Sometimes it refers to a person who has become certified as a Scrum Master by taking Scrum
Master training.
• Sprint backlog. Sprint backlog is the list of backlog items assigned to a sprint, but not yet
completed. In common practice, no sprint backlog item should take more than two days to
complete. The sprint backlog helps the team predict the level of effort required to complete a
sprint.
Advantages
• It is completely developed and tested feature in short iterations.
• It is a simple process with clearly defined rules.
• It increases productivity and the self-organizing team member carries a lot of responsibility. •
It improves communication and combination with extreme programming.
Disadvantage
• It has no written documentation
• There is a violation of responsibilities.

XP Process(Extreme Programming)

• XP stands for extreme programming. It concentrates on the development rather than managerial
aspects of software projects.
• XP was designed so that organizations would be free to adopt all or part of the methodology. It is
one of the popular agile technique.
 • This method is intially formulated by Kent Beck.
• It focuses mostly on customer satisfaction by communicating with the customers on a regular
basis.
• It improves software development through communication, simplicity, feedback, respect, and
courage.
• XP projects start with a release planning phase, followed by several iterations, each of which
concludes with user acceptance testing. When the product has enough features to satisfy
users, the team terminates iteration and releases the software.
• Users write “user stories” to describe the need the software should fulfill. User stories help the
team to estimate the time and resources necessary to build the release and to define user
acceptance tests.
• A user or a representative is part of the XP team, so he or she can add detail to requirements as
the software is being built. This allows requirements to evolve as both users and developers
define what the product will look like.
• To create a release plan, the team breaks up the development tasks into iterations. The release
plan defines each iteration plan, which drives the development for that iteration.
• At the end of an iteration, users perform acceptance tests against the user stories. If they find
bugs, fixing the bugs becomes a step in the next iteration.
• Iterative user acceptance testing, in theory, can result in release of the software. If users decide
that enough user stories have been delivered, the team can choose to terminate the project
before all of the originally planned user stories have been implemented.
A simplified XP process
XP rules and concepts
Here are the most important concepts:

• Integrate often. Development teams must integrate changes into the development baseline at
least once a day. This concept is also called continuous integration.

• Project velocity. Velocity is a measure of how much work is getting done on the project. This
important metric drives release planning and schedule updates.

• Pair programming. All code for a production release is created by two people working together at
a single computer. XP proposes that two coders working together will satisfy user stories at the
same rate as two coders working alone, but with much higher quality.

• User story. A user story describes problems to be solved by the system being built. These stories
must be written by the user and should be about three sentences long. User stories do not
describe a solution, use technical language, or contain traditional requirements-speak, such as
“shall” statements. Instead, a sample user story might go like this: Search for customers. The
user tells the application to search for customers. The application asks the user to specify
which customers. After the user specifies the search criteria, the application returns a list of
customers meeting those criteria.
Advantages

• The XP process is the most suitable practice for dynamically changing requirements, project
having risks, small developer groups, and non-fixed scope or price contract.

Disadvantage

• It is difficult to get representatives of customers who can sit with the team and work with them
daily.

There is a problem of architectural design because the incremental style of development means that
inappropriate architectural decisions are made at an early stage of the process.
RUP(Rational Unified Process):

• The Rational Unified Process (RUP) is a use-case driven, architecture-centric, iterative, and
incremental process model.
• It is a process, product, developed and maintained by Rational Software.
• The RUP focuses on creating and maintaining models rather than documentation.
• The RUP divides the development cycle into four consecutive phases namely inception,
elaboration, construction and transition, as shown below figure.
• It is derived from Unified Modeling Language (UML), which is an industry-standard language that
helps to clearly communicate requirements, architectures, and designs.
Inception phase:
• The goal of this phase is to establish the business case for the system and delimit the project
scope.
• For that, all external entities with which the system will interact (actors) are defined and they
define the interaction at a high level.
• The business case includes success criteria, risk assessment, and estimate of the resources
needed; and a phase plan showing dates of major milestones.
• This phase produces vision document of the project, initial use-case model, initial risk
assessment, business model, and a project plan showing the phases and iterations.
• At this stage, customers will be clear with their requirement and life cycle objectives milestone
will be produced
Elaboration phase:
• The purpose of the elaboration phase is to analyze the problem domain, establish an
architectural framework, develop the project plan, and eliminate the highest risk elements of
the project.
• It is the most critical phases that help to decide whether or not to proceed to the construction
and transition phases
• In the Elaboration phase, an executable architecture prototype is built in one or more iterations,
depending on the scope, size, risk, and novelty of the project.
 • At the end of the elaboration phase, the second important project milestone will be the life cycle
architecture milestone.
Construction phase:
• During the construction phase all application features are developed, integrated, and thoroughly
tested.
• This phase also focuses on the user manuals and the current release details. • At
the end of this phase, a beta release becomes operational for the customers.
Transition phase:
• The purpose of the transition phase is to move the software product to the user community for
working.
• This phase includes several iterations, including beta releases, general availability releases as well
as bug -fix and enhancement releases
• Each phase in the RUP can be further broken down into iterations. Each iteration in the RUP mitigates
risks, manages changes, provides reuse, and produces better quality products as compared to the
traditional waterfall process.
• Workflow represents the sequence of activities that produces a result of the observable value.
Workflows are divided into 6 core workflows(business modeling workflow, requirements workflow,
analysis and design workflow, implementation workflow, test workflow, deployment workflow) and
three supporting workflows ( project management workflow, configuration and change
management workflow and environment workflow).
o Business modeling focuses on documenting business processes using business use
cases.
o Requirements workflow describes what the system should do and allows the developers
and the customer to agree upon the document.
o Analysis and design workflow is used to show how the system will be realized in the
implementation phase.
o The purpose of implementation is to produce code, objects and classes that can be
implemented.
o Testing workflow focuses on the verification of codes and integration of various
components.
o The product is released and delivered to the end users in deployment stage.
Advantages
• It is a complete methodology in itself that emphasizes documentation.
• It helps to resolve project risks related with changing requirements.
• This process is openly published, distributed, and supported for operation.
• It requires less time for integration of reusable components as the process of integration goes on
throughout the software development life cycle.
Disadvantages
• The development process is very complex and not well organized.