NOTES

ON

SOFTWARE ENGINEERING AND PROJECT

MANAGEMENT

B.E - III YEAR – SEM 6

(2023-24)

DEPARTMENT OF

ARTIFICIAL INTELLIGENCE & DATA SCIENCE

 Module-I
Introduction of Software Engineering

INTRODUCTION:
Software Engineering is a framework for building software and is an engineering approach to software
development. Software programs can be developed without S/E principles and methodologies but they
are indispensable if we want to achieve good quality software in a cost effective manner.
Software is defined as:
Instructions + Data Structures + Documents
Engineering is the branch of science and technology concerned with the design, building, and use of
engines, machines, and structures. It is the application of science, tools and methods to find cost effective
solution to simple and complex problems.
SOFTWARE ENGINEERING is defined as a systematic, disciplined and quantifiable approach for the
development, operation and maintenance of software.
The Evolving role of software:
The dual role of Software is as follows:
1. A Product- Information transformer producing, managing and displaying information.
2. A Vehicle for delivering a product- Control of computer (operating system) the communication of
information(networks) and the creation of other programs.
Characteristics of software
• Software is developed or engineered, but it is not manufactured in the classical sense.
• Software does not wear out, but it deteriorates due to change.
• Software is custom built rather than assembling existing components.

THE CHANGING NATURE OF SOFTWARE

The various categories of software are
1. System software
2. Application software
3. Engineering and scientific software
4. Embedded software
5. Product-line software
6. Web-applications
7. Artificial intelligence software

SOFTWARE APPLICATION DOMAIN

System Software –
System Software is necessary to manage the computer resources and support the execution of
application programs. Software like operating systems, compilers, editors and drivers, etc., come
under this category. A computer cannot function without the presence of these. Operating systems are
needed to link the machine-dependent needs of a program with the capabilities of the machine on
which it runs. Compilers translate programs from high-level language to machine language.
Application Software –
Application software is designed to fulfill the user’s requirement by interacting with the user directly. It
could be classified into two major categories: - generic or customized. Generic Software is the software
that is open to all and behaves the same for all of its users. Its function is limited and not customized as
per the changing requirements of the user. However, on the other hand, Customized software the
software products which are designed as per the client’s requirement, and are not available for all.
Networking and Web Applications Software –
Networking Software provides the required support necessary for computers to interact with each other
and with data storage facilities. The networking software is also used when software is running on a
network of computers (such as the World Wide Web). It includes all network management software,
server software, security and encryption software, and software to develop web-based applications like
HTML, PHP, XML, etc.
Embedded Software –
This type of software is embedded into the hardware normally in the Read-Only Memory (ROM) as a
part of a large system and is used to support certain functionality under the control conditions. Examples
are software used in instrumentation and control applications like washing machines, satellites,
microwaves, etc.
Reservation Software –
A Reservation system is primarily used to store and retrieve information and perform transactions related
to air travel, car rental, hotels, or other activities. They also provide access to bus and railway
reservations, although these are not always integrated with the main system. These are also used to relay
computerized information for users in the hotel industry, making a reservation and ensuring that the
hotel is not overbooked.
Business Software –
This category of software is used to support business applications and is the most widely used category
of software. Examples are software for inventory management, accounts, banking, hospitals, schools,
stock markets, etc.
Entertainment Software –
Education and entertainment software provides a powerful tool for educational agencies, especially
those that deal with educating young children. There is a wide range of entertainment software such as
computer games, educational games, translation software, mapping software, etc.
Artificial Intelligence Software –
Software like expert systems, decision support systems, pattern recognition software, artificial neural
networks, etc. come under this category. They involve complex problems which are not affected by
complex computations using non-numerical algorithms.
Scientific Software –
Scientific and engineering software satisfies the needs of a scientific or engineering user to perform
enterprise-specific tasks. Such software is written for specific applications using principles, techniques,
and formulae specific to that field. Examples are software like MATLAB, AUTOCAD, PSPICE,
ORCAD, etc.
Utilities Software –
The programs coming under this category perform specific tasks and are different from other software
in terms of size, cost, and complexity. Examples are anti-virus software, voice recognition software,
compression programs, etc.
Document Management Software –
Document Management Software is used to track, manage and store documents in order to reduce the
paperwork. Such systems are capable of keeping a record of the various versions created and modified
by different users (history tracking). They commonly provide storage, versioning, metadata, security, as
well as indexing and retrieval capabilities.

A GENERIC VIEW OF PROCESS SOFTWARE ENGINEERING-A LAYERED

TECHNOLOGY

Fig: Software Engineering-A layered technology

Software engineering is a layered technology. Referring to Fig. above any engineering approach
(including software engineering) must rest on an organizational commitment to quality.
1. Total quality management and similar philosophies foster a continuous process improvement
culture, and this culture ultimately leads to the development of increasingly more mature
approaches to software engineering.
2. The foundation for software engineering is the process layer. Software engineering process is
the glue that holds the technology layers together and enables rational and timely development
of computer software. Process defines a framework for a set of key process areas that must be
established for effective delivery of software engineering technology. The key process areas
form the basis for management control of software projects and establish the context in which
technical methods are applied, work products are produced, milestones are established, quality
is ensured, and change is properly managed.
3. Software engineering methods provide the technical how-to's for building software. Methods
encompass a broad array of tasks that include requirements analysis, design, program
construction, testing, and support. Software engineering methods rely on a set of basic principles
that govern each area of the technology and include modeling activities and other descriptive
techniques.
4. Software engineering tools provide automated or semi-automated support for the process and
the methods. When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering, is established. CASE combines software, hardware, and a software engineering
database (a repository containing important information about analysis, design, program
construction, and testing) to create a software engineering environment analogous to CAD for
hardware.
GENERIC VIEW OF PROCESS
A software engineering process is the model selected for managing the creation of software from
customer initiation to the release of the finished product. The selected process typically involves
methods such as the software life cycle follows the sequential flow in order to develop software.
We will see each and every stage of this life cycle in detail in subsequent points:
1. Requirement gathering and analysis
In this phase stakeholders communicate with customer and system users to gather the business
requirements like who will use the system? How user will interact with the system? What should be the
system input and output? etc. Depending on these requirements, Requirement Specification Document
(SRS) is prepared.
2. Design
This phase makes use of output of requirement gathering phase.Based on requirement specifications
software design is prepared. Output of this phase is design specification which specifies hardware and
software requirements of system. Data Flow Diagram, flowcharts etc. are included by design
specification document. Design specification acts as an input for implementation phase.
3. Implementation phase
Implementation phase of development process decomposes the system work into various smaller parts
called modules. These modules are assigned to development team members and actual coding is started.
This is longest phase of system development. Output of this phase is actual code using specific
programming language.
4. Testing
Testing phase involves testing of actual code of system against requirements of user in order to ensure
that system will satisfy all needs of users. Various testing strategies used are unit testing, system testing,
integration testing etc. Output of testing phase is corrected and modified software code.
5. Deployment
In this phase the system is deployed at users' site for their use.In this phase customer uses the software
and give feedback to development team for any changes or modifications in system if any.
6. Maintenance
Once the software is deployed actual problems from user's perspective will come up. It is responsibility
of development team to solve user's problems time to time. This process is called as maintenance of
system. In this phase some additional functionality may need to add in the application as per user's
requirement.
CAPABILITY MATURITY MODEL (CMM)
In recent years, there has been a significant emphasis on “process maturity.” The Software Engineering
Institute (SEI) has developed a comprehensive model predicated on a set of software engineering
capabilities that should be present as organizations reach different levels of process maturity. To
determine an organization’s current state of process maturity, the SEI uses an assessment that results in
a five point grading scheme. The grading scheme determines compliance with a capability maturity
model (CMM)that defines key activities required at different levels of process maturity. The SEI
approach provides a measure of the global effectiveness of a company's software engineering practices
and establishes five process maturity levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic. Few
processes are defined, and success depends on individual effort.
Level 2: Repeatable. Basic project management processes are established to track cost, schedule, and
functionality. The necessary process discipline is in place to repeat earlier successes on projects with
similar applications.
Level 3: Defined. The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process. All projects use a documented
and approved version of the organization's process for developing and supporting software. This level
includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product quality are collected. Both
the software process and products are quantitatively understood and controlled using detailed measures.
This level includes all characteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the
process and from testing innovative ideas and technologies. This level includes all characteristics
defined for level 4.
CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

Capability Maturity Model Integration is a framework for process improvement and is developed by
Software Engineering Institute for Software Development, Service Providers and Organization involved
with Acquisitions. Currently, there are three models that address the following:
> The development of Software Products and Services i.e. CMMI-DEV
> The acquisition of Products and Services i.e. CMMI-ACQ
> The establishment, management, and delivery of services i.e. CMMI-SVC
Every CMMI model is a process improvement approach that provides organizations with the essential
elements of effective processes can be used to guide improvement across a team, project, division, or
entire organization, and helps to set process improvement goals and priorities, provide guidance for
quality processes, and provide a point of reference for appraising current processes.

Fig. CMM Framework Group

 WATERFALL MODEL
Because software is always part of a larger system (or business), work begins by establishing
requirements for all system elements and then allocating some subset of these requirements to software.
This system view is essential when software must interact with other elements such as hardware, people,
and databases. System engineering and analysis encompass requirements gathering at the system level
with a small amount of top level design and analysis. Information engineering encompasses
requirements gathering at the strategic business level and at the business area level.

1. Software requirements analysis. The requirements gathering process is intensified and focused
specifically on software. To understand the nature of the program(s) to be built, the software
engineer ("analyst") must understand the information domain (described in Chapter 11) for the
software, as well as required function, behavior, performance, and interface. Requirements for
both the system and the software are documented and reviewed with the customer.
2. Design. Software design is actually a multistep process that focuses on four distinct attributes of
a program: data structure, software architecture, interface representations, and procedural
(algorithmic) detail. The design process translates requirements into a representation of the
 software that can be assessed for quality before coding begins. Like requirements, the design is
documented and becomes part of the software configuration.
3. Code generation. The design must be translated into a machine-readable form. The code
generation step performs this task. If design is performed in a detailed manner, code generation
can be accomplished mechanistically.
4. Testing. Once code has been generated, program testing begins. The testing process focuses on
the logical internals of the software, ensuring that all statements have been tested, and on the
functional externals; that is, conducting tests to uncover errors and ensure that defined input will
produce actual results that agree with required results. Support. Software will undoubtedly
undergo change after it is delivered to the customer. Change will occur because errors have been
encountered, because the software must be adapted to accommodate changes in its external
environment (e.g., a change required because of a new operating system or peripheral device),
or because the customer requires functional or performance enhancements. Software
support/maintenance reapplies each of the preceding phases to an existing program rather than a
new one.
 INCREMENTAL PROCESS MODEL
The incremental model combines elements of the linear sequential model (applied repetitively) with the
iterative philosophy of prototyping. Referring to Figure, the incremental model applies linear sequences
in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable
“increment” of the software. For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production functions in the first
increment; more sophisticated editing and document production capabilities in the second increment;
spelling and grammar checking in the third increment; and advanced page layout capability in the fourth
increment. It should be noted that the process flow for any increment can incorporate the prototyping
paradigm.

When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed, but many supplementary features (some known, others unknown) remain
undelivered. The core product is used by the customer as a result of use and/or evaluation, a plan is
developed for the next increment. The plan addresses the modification of the core product to better meet
the needs of the customer and the delivery of additional features and functionality. This process is
repeated following the delivery of each increment, until the complete product is produced. The
incremental process model and other evolutionary approaches, is iterative in nature. The incremental
model focuses on the delivery of an operational product with each increment.
Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early increments can
be implemented with fewer people. If the core product is well received, then additional staff (if required)
can be added to implement the next increment. In addition, increments can be planned to manage
technical risks.

 RAD MODEL
Rapid application development (RAD) is an incremental software development process model that
emphasizes an extremely short development cycle. The RAD model is a “high-speed” adaptation of the
linear sequential model in which rapid development is achieved by using component-based construction.
If requirements are well understood and project scope is constrained, the RAD process enables a
development team to create a “fully functional system” within very short time periods.

1. Business modeling. The information flow among business functions is modeled in a way that
answers the following questions: What information drives the business process? What
information is generated? Who generates it? Where does the information go? Who processes it?
2. Data modeling. The information flow defined as part of the business modeling phase is refined
into a set of data objects that are needed to support the business. The characteristics (called
attributes) of each object are identified and the relationships between these objects defined. Data
modeling is considered in Chapter 12.
3. Process modeling. The data objects defined in the data modeling phase are transformed to
achieve the information flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting, or retrieving a data object.
4. Application generation. RAD assumes the use of fourth generation techniques Rather than
creating software using conventional third generation programming languages the RAD process
 works to reuse existing program components (when possible) or create reusable components
(when necessary). In all cases, automated tools are used to facilitate construction of the software.
5. Testing and turnover. Since the RAD process emphasizes reuse, many of the program
components have already been tested. This reduces overall testing time. However, new
components must be tested and all interfaces must be fully exercised.
Like all process models, the RAD approach has drawbacks
a. For large but scalable projects, RAD requires sufficient human resources tO create the right
number of RAD teams.
b. RAD requires developers and customers who are committed to the rapid-fire activities necessary
to get a system complete in a much abbreviated time frame. If commitment is lacking from either
constituency, RAD projects will fail.
c. Not all types of applications are appropriate for RAD. If a system cannot be properly
modularized, building the components necessary for RAD will be problematic. If high
performance is an issue and performance is to be achieved through tuning the interfaces to system
components, the RAD approach may not work.
d. RAD is not appropriate when technical risks are high. This occurs when a new application makes
heavy use of new technology or when the new software requires a high degree of interoperability
with existing computer programs.

 EVOLUTIONARY SOFTWARE PROCESS MODELS

Evolutionary models are iterative. They are characterized in a manner that enables software
engineers to develop increasingly more complete versions of the software.

1. SPIRAL MODEL
The spiral model, originally proposed by Boehm, is an evolutionary software process model that couples
the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential
model. It provides the potential for rapid development of incremental versions of the software. Using
the spiral model, software is developed in a series of incremental releases. During early iterations, the
incremental 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 number of
framework activities, also called task regions. Typically, there are between three and six task regions.
Figure depicts a spiral model that contains six task regions:
• Customer communication—tasks required to establish effective communication between developer
and customer.
• Planning—tasks required to define resources, timelines, and other project related information.
• Risk analysis—tasks required to assess both technical and management risks.
• Engineering—tasks required to build one or more representations of the application.
• Construction and release—tasks required to construct, test, install, and provide user support (e.g.,
documentation and training).
  Customer evaluation—tasks required to obtain customer feedback based on evaluation of the
software representations created during the engineering stage and implemented during the
installation stage.
The software engineering team moves around the spiral in a clockwise direction, beginning at the center.
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. Each pass through the planning region results in adjustments to the project
plan. Cost and schedule are adjusted based on feedback derived from customer evaluation.
 THE PROTOTYPING MODEL
The prototyping paradigm begins with requirements gathering. Developer and customer meet and
define the overall objectives for the software, identify whatever requirements are known, and outline
areas where further definition is mandatory. A "quick design" then occurs. The quick design focuses
on a representation of those aspects of the software that will be visible to the customer/user (e.g., input
approaches and output formats). The quick design leads to the construction of a prototype. The
prototype is evaluated by the customer/user and used to refine requirements for the software to be
developed. Iteration occurs as the prototype it is tuned to satisfy the needs of the customer, while at the
same time enabling the developer to better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a working
prototype is built, the developer attempts to use existing program fragments or applies tools (e.g.,
report generators, window managers) that enable working programs to be generated quickly.
Yet, prototyping can also be problematic for the following reasons:
1. The customer sees what appears to be a working version of the software, unaware that the
prototype is held together “with chewing gum and baling wire,” unaware that in the rush to get it
working no one has considered overall software quality or long-term maintainability. When
informed that the product must be rebuilt so that high levels of quality can be maintained, the
customer cries foul and demands that "a few fixes" be applied to make the prototype a working
product. Too often, software development management relents.
2. The developer often makes implementation compromises in order to get a prototype working
quickly. An inappropriate operating system or programming language may be used simply because
it is available and known; an inefficient algorithm may be implemented simply to demonstrate
capability. After a time, the developer may become familiar with these choices and forget all the
reasons why they were inappropriate. The less-than-ideal choice has now become an integral part
of the system.

 CONCURRENT DEVELOPMENT MODEL

Figure provides a schematic representation of one activity with the concurrent process model. The
activity—analysis—may be in any one of the states10 noted at any given time. Similarly, other activities
(e.g., design or customer communication) can be represented in an analogous manner. All activities exist
concurrently but reside in different states. For example, early in a project the customer communication
activity (not shown in the figure) has completed its first iteration and exists in the
awaiting changes state. The analysis activity (which existed in the none state while initial customer
communication was completed) now makes a transition into the under development state. If, however,
the customer indicates that changes in requirements must be made, the analysis 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. For example, during early stages of design, an
inconsistency in the analysis model is uncovered. This generates the event analysis model correction
which will trigger the analysis activity from the done state into the awaiting changes state. In reality, the
concurrent process model is applicable to all types of software development and provides an accurate
picture of the current state of a project. Rather than confining software engineering activities to a
sequence of events, it defines a network of activities. Each activity on the network exists simultaneously
with other activities. Events generated within a given activity or at some other place in the activity
network trigger transitions among the states of an activity.
  COMPONENT-BASED DEVELOPMENT
The component-based development (CBD) model incorporates many of the characteristics of the spiral
model. It is evolutionary in nature, demanding an iterative approach to the creation of software.
However, the component-based development model composes applications from prepackaged software
components (called classes). The engineering activity begins with the identification of candidate classes.
This is accomplished by examining the data to be manipulated by the application and the algorithms that
will be applied to accomplish the manipulation. Corresponding data and algorithms are packaged into a
class.
The component-based development model leads to software reuse, and reusability provides software
engineers with a number of measurable benefits. Based on studies of reusability, QSM Associates, Inc.,
reports component assembly leads to a 70 percent reduction in development cycle time; an 84 percent
reduction in project cost, and a productivity index of 26.2, compared to an industry norm. Although
these results are a function of the robustness of the component library, there is little question that the
component-based development model provides significant advantages for software engineers.
 THE FORMAL METHODS MODEL
The formal methods model encompasses a set of activities that leads to formal mathematicalspecification of
computer software. Formal methods enable a software engineer to specify, develop, and verify a computer-based
system by applying a rigorous, mathematical notation. A variation on this approach, called cleanroom software
engineering is currently applied by some software development organizations. When formal methods) are used
during development, they provide a mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms. Ambiguity, incompleteness, and inconsistency can be
discovered and corrected more easily, not through ad hoc review but through the application of mathematical
analysis. When formal methods are used during design, they serve as a basis for program verification and therefore
enable the software engineer to discover and correct errors that might go undetected.
Although it is not destined to become a mainstream approach, the formal methods model offers the promise of
defect-free software. Yet, the following concerns about its applicability in a business environment have been
voiced:
1. The development of formal models is currently quite time consuming and expensive.
2. Because few software developers have the necessary background to apply formal methods, extensive training
is required.
3. It is difficult to use the models as a communication mechanism for technically unsophisticated customers.

These concerns notwithstanding, it is likely that the formal methods approach will gain adherents among software
developers who must build safety-critical software (e.g., developers of aircraft avionics and medical devices) and
among developers that would suffer severe economic hardship should software errors occur.

 THE AGILE PROCESS

Agility Principles
1. highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
 4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
If members of the software team are to drive the characteristics of the process that is applied to build
software, a number of key traits must exist among the people on an agile team and the team itself:
Competence. In an agile development (as well as software engineering) context, “competence”
encompasses innate talent, specific software-related skills, and overall knowledge of the process that the
team has chosen to apply. Skill and knowledge of process can and should be taught to all people who
serve as agile team members.
Common focus. Although members of the agile team may perform different tasks and bring different
skills to the project, all should be focused on one goal—to deliver a working software increment to the
customer within the time promised. To achieve this goal, the team will also focus on continual
adaptations (small and large) that will make the process fit the needs of the team.
Collaboration. Software engineering (regardless of process) is about assessing, analyzing, and using
information that is communicated to the software team; creating information that will help all
stakeholders understand the work of the team; and building information (computer software and relevant
databases) that provides business value for the customer. To accomplish these tasks, team members must
collaborate—with one another and all other stakeholders.
Decision-making ability. Any good software team (including agile teams) must be allowed the freedom
to control its own destiny. This implies that the team is given autonomy—decision-making authority for
both technical and project issues.
Fuzzy problem-solving ability. Software managers must recognize that the agile team will continually
have to deal with ambiguity and will continually be buffeted by change. In some cases, the team must
accept the fact that the problem they are solving today may not be the problem that needs to be solved
tomorrow. However, lessons learned from any problem-solving activity (including those that solve the
wrong problem) may be of benefit to the team later in the project.
Mutual trust and respect. The agile team must become what DeMarco and Lister [DeM98] call a
“jelled” team. A jelled team exhibits the trust and respect that are necessary to make them “so strongly
knit that the whole is greater than the sum of the parts.”
Self-organization. In the context of agile development, self-organization implies three things: (1) the
agile team organizes itself for the work to be done, (2) the team organizes the process to best
accommodate its local environment, (3) the team organizes the work schedule to best achieve delivery
of the software increment. Self-organization has a number of technical benefits, but more importantly,
it serves to improve collaboration and boost team morale. In essence, the team serves as its own
management.
 EXTREME PROGRAMMING (XP)
XP Values
In order to achieve effective communication between software engineers and other stakeholders (e.g.,
to establish required features and functions for the software), XP emphasizes close, yet informal (verbal)
collaboration between customers and developers, the establishment of effective metaphors3 for
communicating important concepts, continuous feedback, and the avoidance of voluminous
documentation as a communication medium. To achieve simplicity, XP restricts developers to design
only for immediate needs, rather than consider future needs. The intent is to create a simple design that
can be easily implemented in code). If the design must be improved, it can be refactored4 at a later time.
Feedback is derived from three sources: the implemented software itself, the customer, and other
software team members. By designing and implementing an effective testing strategy, the software (via
test results) provides the agile team with feedback. XP makes use of the unit test as its primary testing
tactic. As each class is developed, the team develops a unit test to exercise each operation according to
its specified functionality. As an increment is delivered to a customer, the user stories or use cases that
are implemented by the increment are used as a basis for acceptance tests. The degree to which the
software implements the output, function, and behavior of the use case is a form of feedback.
Finally, as new requirements are derived as part of iterative planning, the team provides the customer
with rapid feedback regarding cost and schedule impact. Beck [Bec04a] argues that strict adherence to
certain XP practices demands courage. A better word might be discipline. For example, there is often
significant pressure to design for future requirements. Most software teams succumb, arguing that
“designing for tomorrow” will save time and effort in the long run. An agile XP team must have the
discipline (courage) to design for today, recognizing that future requirements may change dramatically,
thereby demanding substantial rework of the design and implemented code.
By following each of these values, the agile team inculcates respect among it members, between other
stakeholders and team members, and indirectly, for the software itself. As they achieve successful
delivery of software increments, the team develops growing respect for the XP process.
The XP Process
Extreme Programming uses an object-oriented approach as its preferred development paradigm and
encompasses a set of rules and practices that occur within the context of four framework activities:
planning, design, coding, and testing.
Key XP activities are summarized in the paragraphs that follow.
Planning. The planning activity (also called the planning game) begins with listening—a requirements
gathering activity that enables the technical members of the XP team to understand the business context
for the software and to get a broad feel for required output and major features and functionality.
Design. XP design rigorously follows the KIS (keep it simple) principle. A simple design is always
preferred over a more complex representation. In addition, the design provides implementation guidance
for a story as it is written—nothing less, nothing more. The design of extra functionality (because the
developer assumes it will be required later) is discouraged.
Coding. After stories are developed and preliminary design work is done, the team does not move to
code, but rather develops a series of unit tests that will exercise each of the stories that is to be included
in the current release (software increment).8 Once the unit test9 has been created, the developer is better
able to focus on what must be implemented to pass the test. Nothing extraneous is added (KIS). Once
the,code is complete, it can be unit-tested immediately, thereby providing instantaneous
feedback to the developers.
XP acceptance tests, also called customer tests, are specified by the customer and focus on overall
system features and functionality that are visible and reviewable by the customer. Acceptance tests are
derived from user stories that have been implemented as part of a software release.

 SCRUM
Scrum (the name is derived from an activity that occurs during a rugby match13) is an agile software
development method that was conceived by Jeff Sutherland and his development team in the early
1990s. In recent years, further development on the Scrum methods has been performed by Schwaber
and Beedle [Sch01a]. Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following framework
activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work
tasks occur within a process pattern (discussed in the following paragraph) called a sprint. The work
conducted within a sprint (the number of sprints required for each framework activity will vary
depending on product complexity
and size) is adapted to the problem at hand and is defined and often modified
in real time by the Scrum team. The overall flow of the Scrum process is illustrated
in Figure 3.4.
Scrum emphasizes the use of a set of software process patterns that have proven effective for projects
with tight timelines, changing requirements, and business criticality. Each of these process patterns
defines a set of development actions: Backlog—a prioritized list of project requirements or features that
provide business value for the customer. Items can be added to the backlog at any time (this is
how changes are introduced). The product manager assesses the backlog and updates priorities as
required. Sprints—consist of work units that are required to achieve a requirement defined
in the backlog that must be fit into a predefined time-box14 (typically 30 days). Changes (e.g., backlog
work items) are not introduced during the sprint. Hence, the sprint allows team members to work in a
short-term, but stable environment.
Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team.
Three key questions are asked and answered by all team members :
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and assesses the responses from each person.
The Scrum meeting helps the team to uncover potential problems as early as possible. Also, these daily
meetings lead to “knowledge socialization” and thereby promote a self-organizing team structure.
Demos—deliver the software increment to the customer so that functionality that has been implemented
can be demonstrated and evaluated by the customer. It is important to note that the demo may not contain
all planned functionality, but rather those functions that can be delivered within the time-box that was
established.
Beedle and his colleaguespresent a comprehensive discussion of these patterns in which they state:
“Scrum assumes up-front the existence of chaos. ” The Scrum process patterns enable a software team
to work successfully in a world where the elimination of uncertainty is impossible.
KANBAN : FROM LOCAL PUBLICATION