Software Engineering (R18CP3408) :

Introduction to Software Engineering

 What is Software Engineering ?

• Software
– programs that provide function & performance
– data structures for information manipulation
– documents that describe the operations and use of
the programs
• Engineering
– A discipline that applies scientific and technical
methods in the design and production of a product
 IEEE Definition of Software
Engineering

The application of a systematic, disciplines,

quantifiable approach to the development,
operation, and maintenance of software; that is
the application of engineering to software.
Definition of Software Engineering

Software engineering is defined as a

process of analyzing user requirements
and then designing, building, and testing
software application which will satisfy
those requirements.
Why is Software Engineering required?

• For managing large software.

• To improve scalability.
• To control the software’s dynamic nature.
• For better management of performance
• To develop cost effective and better quality products.
Objectives of Software Engineering

• To improve quality of software products

• To increase customer satisfaction
• To increase productivity
 The evolving role of software

Powerful Desktop
Multi user Distributed System OOP technology
Batch Oriented Real Time Embedded Intelligence Expert System
Limited Distribution Database Low Cost Software Neural network
Custom Software Product Software Consumer Impact Parallel Computing

1950 1960 1970 1980 1990 2000

 Batch Oriented
Limited Distribution
Custom Software

1ST Era :
-Software was custom designed and had a relatively limited
distribution.
-Job mobility was low
-Design and documentation was often non- existent.
 Multi user
Real Time
Database
Product Software

2nd Era:
-Multiprogramming and multiuser systems
-Various interactive technologies were developed
-Introduction of database management system
-Real time systems
-All these leads to Software Maintenance
 Distributed System
Embedded Intelligence
Low Cost Software
Consumer Impact

3rd Era
-The distributed system
-Global and Local area networks, high bandwidth digital
communications
-Embedded systems
 Powerful Desktop
OOP technology
Expert System
Neural network
Parallel Computing

4th Era –
-Powerful desktop machines
-Object – Oriented technologies were developed
-Expert system and artificial intelligence software have been developed
-Artificial neural network software coupled with the application fuzzy
logic for pattern recognition
-Virtual reality programming and multimedia system also developed
 Software Characteristics

Software is developed or engineered, it is not

manufactured in classical sense
Most software is custom-built, rather than being
assembled from existing components.
Software doesn’t “wear-out”. It does deteriorate due to
change.
Failure Failure
Rate Rate
Instant
“Wear
Mortality
Out”
Continue at same rate

Time
Time

( Failure Curve for Hardware ( Failure Curve for Software

Software does deteriorate due to change

 Software Applications
• System software: A collection of programs written to service other programs are
called system software. E.g. Compiler, Editor etc processes complex but
determinate information structure. Operating Systems, drivers, networking
software processes indeterminate data.
• Application Software's: Processes business or technical data in a way that
facilitates business operations or technical decision making. Application software
is used to process data in real time.
• Design, Engineering and scientific software: These software deal with processing
requirements in their specific fields. They are written for specific applications
using the principles and formulae of each field.
Examples: Astronomy, Volcano logy, automotive stress analysis, molecular
biology, Space shutter orbital dynamics, molecular biology, Automated
manufacturing, CAD
• Embedded Software: Software, when written to perform certain function under
control conditions and further embedded into hardware as a part of larger
systems, is called embedded software
Examples: Keypad control for Microwave oven, Digital functions in an automobile
s.a. Fuel Control
 Continued……………..

• Product Line Software: These software use Personnel use software like
Word processing, spreadsheet, computer graphics, multimedia,
entertainment, database management, Personnel and financial applications
etc.
• Artificial Intelligence Software:
 These related to specific analysis and interpretation of problem to
solve it.
 Another application areas for AI software are pattern recognition,
theorem proving and game playing.
 Neural network simulates the structure of brain process and can
recognize complex patterns and learn from past experience.
 Generic View of Software
Engineering

• Definition Phase (What?)

• Development Phase (How?)
• Maintenance Phase
• Prevention
• Correction
• Adaptation
• Enhancement
Generic View of Software Engineering
- Definition Phase
Definition Phase: Focuses on what?
• Information to be processed
• Function & performance are desired
• Expected system behavior
• Interfaces to be established
• Design constraints exist
• Validation criteria

There are three specific steps

• System or Information Engineering
• Software Project Planning
• Requirement Analysis
Generic View of Software Engineering
- Development Phase
Development Phase: Focuses on How?
• How data is to be structured
• How function is to be implemented
• How Procedural details to be implemented
• How design is translated into programming language
• How testing is to be performed

Design, code generation and testing part will occur in this phase
 Generic View of Software Engineering

- Maintenance Phase

Maintenance Phase
◦ Correction: Correct Uncovered defects
◦ Adaptation: Adapt due to environmental changes
◦ Enhancement: To extend software Functionality
◦ Prevention: To enable the software to serve needs of end user.
Preventive maintenance makes changes to computer programs so
that they can be more easily corrected, adapted, and enhanced.
 The Software Process
The term software specifies to the set of computer programs, procedures and associated
documents (Flowcharts, manuals, etc.) that describe the program and how they are to be
used.
A software process is the set of activities that are applied to design and build a software
product.
There are some fundamental activities that are common to all software processes:
Software specification. In this activity the functionality of the software and constraints on
its operation must be defined.
Software design and implementation. The software that meets the specification is
produced.
Software validation. The software must be validated to ensure that it has all the
functionalities what the customer needs.
Software evolution. The software must evolve to meet changing customer needs.
 Software Myths

Software Myths:

Most, experienced experts have seen myths or

superstitions (false beliefs or interpretations) or
misleading attitudes (naked users) which creates
major problems for management and technical
people. The types of software-related myths are listed
below.
Software Myths
 Software Myths
(i) Management Myths:

Myth 1: We have all the standards and procedures available for software development.
Fact: Software experts do not know all the requirements for the software development.
And all existing processes are incomplete as new software development is based on new and
different problem. Myth 2:
The addition of the latest hardware programs will improve the software development.

Myth 2: The addition of the latest hardware programs will improve the software development.
Fact: The role of the latest hardware is not very high on standard software development; instead
(CASE) Engineering tools help the computer, they are more important than hardware to produce
quality and productivity.
•Hence, the hardware resources are misused.

Myth 3: With the addition of more people and program planners to Software development can help
meet project deadlines (If lagging behind).
Fact: If software is late, adding more people will merely make the problem worse. This is because
the people already working on the project now need to spend time educating the newcomers, and are
thus taken away from their work. The newcomers are also far less productive than the existing
software engineers, and so the work put into training them to work on the software does not
immediately meet with an appropriate reduction in work.
 Software Myths
(ii)Customer Myths:

The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) & that’s
why you create dissatisfaction with the developer.
Myth 1: A general statement of intent is enough to start writing plans (software development) and
details of objectives can be done over time.
Fact: Official and detailed description of the database function, ethical performance,
communication, structural issues and the verification process are important.
•Unambiguous requirements (usually derived iteratively) are developed only through effective and
continuous
communication between customer and developer.
Myth 2: Software requirements continually change, but change can be easily accommodated
because software is flexible
Fact: It is true that software requirements change, but the impact of change varies with the time at
which it is introduced. When requirements changes are requested early (before design or code has
been started), the cost impact is relatively small. However, as time passes, the cost impact grows
rapidly—resources have been committed, a design framework has been established, and change can
cause upheaval that requires additional resources and major design modification.
 Software Myths

(iii)Practitioner’s Myths:

Myths 1: They believe that their work has been completed with the writing of the plan.
Fact: It is true that every 60-80% effort goes into the maintenance phase (as of the latter software
release). Efforts are required, where the product is available first delivered to customers.
Myths 2: There is no other way to achieve system quality, until it is “running”.
Fact: Systematic review of project technology is the quality of effective software verification
method. These updates are quality filters and more accessible than test.
Myth 3: An operating system is the only product that can be successfully exported project.
Fact: A working system is not enough, the right document brochures and booklets are also required
to provide guidance & software support.
Myth 4: Engineering software will enable us to build powerful and unnecessary document & always
delay us.
Fact: Software engineering is not about creating documents. It is about creating a quality product.
Better quality leads to reduced rework. And reduced rework results in faster delivery times
 The Software Process Models

To solve actual problems in an industry, a software

engineer or a team of engineers must incorporate a
development strategy that consists of the process,
methods, tools.
This strategy is often referred to as a process model or a
software engineering paradigm.
A process model for software engineering is chosen based
on the nature of the project and application, the methods
and tools to be used, and the controls and deliverables
that are required.
 SDLC

Software Development Life Cycle (SDLC) is a process used by

the software industry to design, develop and test high quality
software. The SDLC aims to produce a high-quality software
that meets or exceeds customer expectations, reaches
completion within times and cost estimates.
It is also called as Software Development Process.
SDLC is a framework defining tasks performed at each step in
the software development process.
SDLC
 Process Model Types

The following are the types of Process Models :

• Waterfall model
• Incremental process model
• RAD model
 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 before the next
phase can begin and there is no overlapping in the phases.
• The Waterfall model is the earliest SDLC approach that was used for
software development.
• The waterfall Model illustrates the software development process in a
linear sequential flow.
• This means that any phase in the development process begins only if
the previous phase is complete.
• In this waterfall model, the phases do not overlap.
 Waterfall Model
System
Analysis

Requirement
Analysis

Design

Coding

Testing

Maintenance
 Waterfall Model
The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is develop
and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some better versions
are released. Maintenance is done to deliver these changes in the customer
environment.
 Advantages of Waterfall Model
Some of the major advantages of the Waterfall Model are as
follows −

• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well
understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
 Disadvantages of Waterfall Model

The major disadvantages of the Waterfall Model are as follows −

• No working software is produced until late during the life cycle.

• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk
of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
 Incremental Model

• Incremental Model is a process of software development

where requirements divided into multiple standalone
modules of the software development cycle.
• In this model, each module goes through the
requirements, design, implementation and testing phases.
• Every subsequent release of the module adds function to
the previous release.
• The process continues until the complete system
achieved.
Incremental Model
 Incremental Model
1. Requirement analysis: In the first phase of the incremental model, the product
analysis expertise identifies the requirements. And the system functional requirements
are understood by the requirement analysis team. To develop the software under the
incremental model, this phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of
the system functionality and the development method are finished with success. When
software develops new practicality, the incremental model uses style and development
phase.
3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various
methods are used to test the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the development
system. It involves the final coding that design in the designing and development phase
and tests the functionality in the testing phase. After completion of this phase, the
number of the product working is enhanced and upgraded up to the final system product
 Advantages of Incremental Model

Advantage of Incremental Model

• Errors are easy to be recognized.

• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its
iteration.
• The Client gets important functionality early.
 Incremental Model

Disadvantage of Incremental Model

• Need for good planning.

• Total Cost is high.
• Well defined module interfaces are needed.
 The RAD Model

• The RAD (Rapid Application Development) model is based on

prototyping and iterative development with no specific planning
involved.
• The process of writing the software itself involves the planning
required for developing the product.
• Rapid Application Development focuses on gathering customer
requirements through workshops or focus groups, early testing of
the prototypes by the customer using iterative concept, reuse of the
existing prototypes (components), continuous integration and rapid
delivery.
The RAD Model
The RAD Model
 The RAD Model
Following are the various phases of the RAD Model −
Business Modelling : The business model for the product under development is designed in terms of
flow of information and the distribution of information between various business channels. A
complete business analysis is performed to find the vital information for business, how it can be
obtained, how and when is the information processed and what are the factors driving successful flow
of information.
Data Modelling : The information gathered in the Business Modelling phase is reviewed and analyzed
to form sets of data objects vital for the business. The attributes of all data sets is identified and
defined. The relation between these data objects are established and defined in detail in relevance to
the business model.
Process Modelling : The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business objectives as per the
business model. The process model for any changes or enhancements to the data object sets is
defined in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object
are given.
Application Generation : The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.
Testing and Turnover : The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration. However, the data flow and the interfaces between all
the components need to be thoroughly tested with complete test coverage. Since most of the
programming components have already been tested, it reduces the risk of any major issues.
 Advantages of RAD Model

Advantages of the RAD model:

• Reduced development time.

• Increases reusability of components.
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration
issues.
 Disadvantages of RAD Model

Disadvantages of RAD model:

•Depends on strong team and individual performances for

identifying business requirements.
•Only system that can be modularized can be built using RAD
•Requires highly skilled developers/designers.
•High dependency on modeling skills
•Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
 Evolutionary Process Models

Software 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.

Software Engineering needs a process model that has been

explicitly designed to accommodate a product that evolves
over time.

Evolutionary process models are iterative. They produce

increasingly more complete versions of the Software with each
iteration.
 Evolutionary Process Model Types

The following are the Evolutionary Process Model types :

• Prototyping
• Spiral Model
• Concurrent Development Model
 Prototype Model

The Software Prototyping refers to building software application

prototypes which displays the functionality of the product under
development, but may not actually hold the exact logic of the
original software.
Software prototyping is becoming very popular as a software
development model, as it enables to understand customer
requirements at an early stage of development.
It helps get valuable feedback from the customer and helps
software designers and developers understand about what
exactly is expected from the product under development.
 The Prototype Model

Requirement
Build prototype
analysis

Revise if not satisfied

Analyze the result Testing by customer

Satisfied
Firm up the requirement

Final requirement & Solution Code solution

Test for quality
specification design design
 Prototype Model
Following is a stepwise approach explained to design a software prototype :

Basic Requirement Identification : This step involves understanding the very basics
product requirements especially in terms of user interface. The more intricate details of
the internal design and external aspects like performance and security can be ignored at
this stage.
Developing the initial Prototype : The initial Prototype is developed in this stage, where
the very basic requirements are showcased and user interfaces are provided. While, the
workarounds are used to give the same look and feel to the customer in the prototype
developed.
Review of the Prototype : The prototype developed is then presented to the customer
and the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under development.
Revise and Enhance the Prototype : The feedback and the review comments are
discussed during this stage and some negotiations happen with the customer based on
factors like – time and budget constraints and technical feasibility of the actual
implementation. Prototypes can have horizontal or vertical dimensions.
 Advantages of Prototype Model

The advantages of the Prototyping Model are as follows −

• Increased user involvement in the product even before its

implementation.
• Since a working model of the system is displayed, the users get a
better understanding of the system being developed.
• Reduces time and cost as the defects 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.
 Disadvantages of Prototype Model
The Disadvantages of the Prototyping Model are as follows −

• Risk of insufficient requirement analysis owing to too much

dependency on the prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of
the system as scope of the system may expand beyond original
plans.
• Developers may try to reuse the existing prototypes to build
the actual system, even when it is not technically feasible.
• The effort invested in building prototypes may be too much if it
is not monitored properly.
 Spiral Model

•The spiral model combines the idea of iterative development with

the systematic, controlled aspects of the waterfall model.
•This Spiral model is a combination of iterative development process
model and sequential linear development model i.e. the waterfall
model with a very high emphasis on risk analysis.
•It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.
Spiral Model
Spiral Model
 Spiral Model
The spiral model has four phases :

Identification : This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.
At the end of the spiral, the product is deployed in the identified market.
Design : The Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and the
final design in the subsequent spirals.
Construct or Build : The Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral, when the product is just thought of and the
design is being developed a POC (Proof of Concept) is developed in this phase to get
customer feedback.
Evaluation and Risk Analysis : Risk Analysis includes identifying, estimating and
monitoring the technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.
 Advantages of Spiral Model

The advantages of the Spiral SDLC Model are as follows −

• Changing requirements can be accommodated.

• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky
parts can be developed earlier which helps in better risk
management.
 Disadvantages of Spiral Model

The disadvantages of the Spiral SDLC Model are as follows −

• Management is more complex.

• End of the project may not be known early.
• Not suitable for small or low risk projects and could be
expensive for small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive
documentation.
 Concurrent Development Model

• The concurrent development model is called as concurrent

model.
• The communication activity has completed in the first iteration
and exits in the awaiting changes state.
• The modeling activity completed its initial communication and
then go to the under development state.
• If the customer specifies the change in the requirement, then
the modeling activity moves from the under development state
into the awaiting change state.
• The concurrent process model activities moving from one state
to another state.
Concurrent Development Model
none

Mode ling a c t ivit y

rep res ent s t he s t at e

Unde r o f a s o ft ware eng ineering
act ivit y o r t as k
de ve lopm e nt

Awa it ing
c ha nge s

Unde r re vie w

Unde r
re vis ion

Ba s e line d

Done
Concurrent Development Model
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.
Advantages of Concurrent Development
Model

Advantages of the concurrent development model :

This model is applicable to all types of software

development processes.

• It is easy for understanding and use.

• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of
a project.
Disadvantages of Concurrent Development
Model

Disadvantages of the concurrent development model :

• It needs better communication between the team

members. This may not be achieved all the time.
• It requires to remember the status of the different
activities.
 Specialized Process model

Special process models take many features from one or

more conventional models.
However these special models tend to be applied when a
narrowly defined software engineering approach is
chosen.
 Specialized Process Model Types :

The following are the types of Specialized Process Models :

• Component based Development

• Formal Methods Model
• Aspect-Oriented Software Development
 The Component Based Model
Object-oriented technologies provide the technical framework for a component-based
process model for software engineering.
If properly designed and implemented, object-oriented classes are reusable across
different applications and computer-based system architectures.
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 Model
The model works in following manner:
Step-1: First identify all the required candidate components, i.e., classes with the help of
application data and algorithms.
Step-2: If these candidate components are used in previous software projects then they
must be present in the library.
Step-3: Such preexisting components can be excited from the library and used for further
development.
Step-4: But if the required component is not present in the library then build or create the
component as per requirement.
Step-5: Place this newly created component in the library. This makes one iteration of the
system.
Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of
iterations required to develop the complete application.
Component Based Model
 Advantages of Component Based
Model

Advantages of the component-based software engineering (CBSE)

process model:

• Reduces considerably the amount of software to be developed and

so reducing cost and risks
• It usually allows for faster delivery of software
• In principle, more reliable systems, due to using previously tested
components
• Management of complexity
• Reduced development time
 Disadvantages of Component
Based Model

Disadvantages component-based software engineering (CBSE) process

model:

• Compromises in requirements needed and this may lead to a system

that does not meet the real needs of the users
• Less control over the system’s evolution as new versions of the reusable
components are not under the control of the organisation using them.
• Components maintenance may be another issue
 Personnel and Team Process Models
The best software process is one that is close to the people who will be doing the work.
Each software engineer would create a process that best fits his or her needs, and at the
same time meets the broader needs of the team and the organization.
Alternatively, the team itself would create its own process, and at the same time meet the
narrower needs of individuals and the broader needs of the organization.
The quality of a software system is determined by the quality of its worst components.
The quality of a software component is governed by the individual who developed it.
The quality of a software component is governed by the quality of the process used to
develop it.
The key to quality is the individual developer’s skill, commitment, and Personnel process
discipline.
As a software professional, you are responsible for your Personnel process.
You should measure, track, and analyze your work.
You should learn from your performance variations.
You should incorporate lessons learned into your Personnel practices.
 Personnel Software Process (PSP)

The Personnel software process (PSP) emphasizes Personnel

measurement of both the work product that is produced and the
resultant quality of the work product.
The PSP process model defines five framework activities:
◦ planning,
◦ high-level design,
◦ high level design review,
◦ Development and
◦ postmortem.
 Personnel Software Process (PSP)
Planning: This activity isolates requirements and, base on these develops both size and
resource estimates.
In addition, a defect estimate is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule is created.
High level design: External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
High level design review: Formal verification methods are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
Development: The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important task and work
results.
Postmortem: Using the measures and metrics collected the effectiveness of the process is
determined. Measures and metrics should provide guidance for modifying the process to
improve its effectiveness.
PSP stresses the software engineer to identify errors early and, as important, to
understand the types of errors that he is likely to make.
 Team Software Process (TSP)
The goal of TSP is to build a “self-directed project team” to produce high-quality software.
The following are the objectives for TSP:
◦ Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product
teams(IPT) of 3 to about 20 engineers.
◦ Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
◦ Accelerate software process
◦ Provide improvement guidance to high-maturity organizations.
A self-directed team defines
- roles and responsibilities for each team member
- tracks quantitative project data
- identifies a team process appropriate for project
- a strategy for implementing the process
- defines local standards that are applicable to the teams software engineering work;
- continually assesses risk and reacts to it
- Tracks, manages, and reports project status.
 Team Software Process (TSP)
TSP defines the following framework activities:
◦ Project launch,
◦ high-level design,
◦ implementation,
◦ integration and test,
◦ and postmortem.
TSP makes use of a wide variety of scripts, forms, and standards that
serve to guide team members in their work.
Scripts define specific process activities and other more detailed work
functions that are part of the team process.
 Team Software Process (TSP)

Each project is “launched” using a sequence of tasks.

The following launch script is recommended
◦ Review project objectives with management and agree on and
document team goals.
◦ Establish team roles
◦ Define the teams development process
◦ Make a quality plan and set quality targets
◦ Plan for the needed support facilities
 Agile Process Models
The meaning of Agile is swift or versatile. "Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope
and requirements are laid down at the beginning of the development process. Plans
regarding the number of iterations, the duration and the scope of each iteration are
clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller
parts helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis, design, coding, and
testing before a working product is demonstrated to the client.
Agile Process Models
 Agile Process Models
1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project.
Based on this information, you can evaluate technical and economic feasibility.
2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-level
UML diagram to show the work of new features and show how it will apply to your
existing system.
3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's performance
and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.
 Agile Process Model Types

The following are the types of Agile Process Models :

•Extreme Programming (XP)

•Adaptive Software Development (ASD)
•Dynamic Systems Development Method (DSDM)
•Scrum.
•Crystal.
•Feature Driven Development (FDD)
•Agile Modeling (AM)
 Extreme Programming (XP)
•The most widely used agile process, originally proposed
by Kent Beck
•XP Planning
– Begins with the creation of user stories
– Agile team assesses each story and assigns a cost
– Stories are grouped to for a deliverable increment
– A commitment is made on delivery date
– After the first increment project velocity is used to help
define subsequent delivery dates for other increments

82
 Extreme Programming (XP)
•XP Design
– Follows the KIS principle
– Encourage the use of CRC cards
– For difficult design problems, suggests the creation of
spike solutions — a design prototype
– Encourages refactoring — an iterative refinement of the
internal program design
•XP Coding
– Recommends the construction of a unit test for a store
before coding commences
– Encourages pair programming
•XP Testing
– All unit tests are executed daily
– Acceptance tests are defined by the customer and
executed to assess customer visible functionality

83
Extreme Programming (XP)

84
THANK YOU