Introduction to Software

Engineering/Process/Methodology
A software development methodology or system development
methodology in software engineering is a framework that is used to structure,
plan, and control the process of developing an information system.
As a noun

As a noun, a software development methodology is a framework that is used to structure, plan,

and control the process of developing an information system - this includes the pre-definition of
specific deliverables and artifacts that are created and completed by a project team to develop or
maintain an application.[2]

The three basic approaches applied to software development methodology

frameworks.

A wide variety of such frameworks have evolved over the years, each with its own recognized
strengths and weaknesses. One software development methodology framework is not necessarily
suitable for use by all projects. Each of the available methodology frameworks are best suited to

specific kinds of projects, based on various technical, organizational, project and team
considerations.[2]
These software development frameworks are often bound to some kind of organization, which
further develops, supports the use, and promotes the methodology framework. The methodology
framework is often defined in some kind of formal documentation. Specific software
development methodology frameworks (noun) include

Rational Unified Process (RUP, IBM) since 1998.

Agile Unified Process (AUP) since 2005 by Scott Ambler

Verb approaches
Every software development methodology framework acts as a basis for applying specific
approaches to develop and maintain software. Several software development approaches have
been used since the origin of information technology. These are:[2]

Waterfall: a linear framework

Prototyping: an iterative framework

Incremental: a combined linear-iterative framework

Spiral: a combined linear-iterative framework

Rapid application development (RAD): an iterative framework

Extreme Programming

Waterfall development

The Waterfall model is a sequential development approach, in which development is seen as

flowing steadily downwards (like a waterfall) through the phases of requirements analysis,
design, implementation, testing (validation), integration, and maintenance. The first formal
description of the method is often cited as an article published by Winston W. Royce[3] in 1970
although Royce did not use the term "waterfall" in this article.
The basic principles are:[2]

Project is divided into sequential phases, with some overlap and splashback
acceptable between phases.
Emphasis is on planning, time schedules, target dates, budgets and
implementation of an entire system at one time.
Tight control is maintained over the life of the project via extensive written
documentation, formal reviews, and approval/signoff by the user and
information technology management occurring at the end of most phases
before beginning the next phase.

Prototyping

Software prototyping, is the development approach of activities during software development,

the creation of prototypes, i.e., incomplete versions of the software program being developed.
The basic principles are:[2]

Not a standalone, complete development methodology, but rather an

approach to handling selected parts of a larger, more traditional development
methodology (i.e. incremental, spiral, or rapid application development
(RAD)).
Attempts to reduce inherent project risk by breaking a project into smaller
segments and providing more ease-of-change during the development
process.

User is involved throughout the development process, which increases the

likelihood of user acceptance of the final implementation.

Small-scale mock-ups of the system are developed following an iterative

modification process until the prototype evolves to meet the users
requirements.

While most prototypes are developed with the expectation that they will be
discarded, it is possible in some cases to evolve from prototype to working
system.

A basic understanding of the fundamental business problem is necessary to

avoid solving the wrong problem.

Incremental development

Various methods are acceptable for combining linear and iterative systems development
methodologies, with the primary objective of each being to reduce inherent project risk by
breaking a project into smaller segments and providing more ease-of-change during the
development process.
The basic principles are:[2]

A series of mini-Waterfalls are performed, where all phases of the Waterfall

are completed for a small part of a system, before proceeding to the next
increment, or
Overall requirements are defined before proceeding to evolutionary, miniWaterfall development of individual increments of a system, or
The initial software concept, requirements analysis, and design of
architecture and system core are defined via Waterfall, followed by iterative
Prototyping, which culminates in installing the final prototype, a working
system.

Spiral development

The spiral model.

The spiral model is a software development process combining elements of both design and
prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.
The basic principles are:[2]

Focus is on risk assessment and on minimizing project risk by breaking a

project into smaller segments and providing more ease-of-change during the
development process, as well as providing the opportunity to evaluate risks
and weigh consideration of project continuation throughout the life cycle.
"Each cycle involves a progression through the same sequence of steps, for
each part of the product and for each of its levels of elaboration, from an
overall concept-of-operation document down to the coding of each individual
program."[4]

Each trip around the spiral traverses four basic quadrants: (1) determine
objectives, alternatives, and constraints of the iteration; (2) evaluate
alternatives; Identify and resolve risks; (3) develop and verify deliverables
from the iteration; and (4) plan the next iteration. [4][5]

Begin each cycle with an identification of stakeholders and their win

conditions, and end each cycle with review and commitment. [6]

Rapid application development

Rapid application development (RAD) is a software development methodology, which involves

iterative development and the construction of prototypes. Rapid application development is a
term originally used to describe a software development process introduced by James Martin in
1991.

The basic principles are:[2]

Key objective is for fast development and delivery of a high quality system at
a relatively low investment cost.
Attempts to reduce inherent project risk by breaking a project into smaller
segments and providing more ease-of-change during the development
process.

Aims to produce high quality systems quickly, primarily via iterative

Prototyping (at any stage of development), active user involvement, and
computerized development tools. These tools may include Graphical User
Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools,
Database Management Systems (DBMS), fourth-generation programming
languages, code generators, and object-oriented techniques.

Key emphasis is on fulfilling the business need, while technological or

engineering excellence is of lesser importance.

Project control involves prioritizing development and defining delivery

deadlines or timeboxes. If the project starts to slip, emphasis is on reducing
requirements to fit the timebox, not in increasing the deadline.

Generally includes joint application design (JAD), where users are intensely
involved in system design, via consensus building in either structured
workshops, or electronically facilitated interaction.

Active user involvement is imperative.

Iteratively produces production software, as opposed to a throwaway

prototype.

Produces documentation necessary to facilitate future development and

maintenance.

Standard systems analysis and design methods can be fitted into this
framework.

Team software process

In combination with the Personal Software Process (PSP), the Team Software Process (TSP)
provides a defined operational process framework that is designed to help teams of managers and
engineers organize projects and produce software products that range in size from small projects
of several thousand lines of code (KLOC) to very large projects greater than half a million lines
of code.[1] The TSP is intended to improve the levels of quality and productivity of a team's
software development project, in order to help them better meet the cost and schedule
commitments of developing a software system.

The initial version of the TSP was developed and piloted by Watts Humphrey in the late 1990s[2]
and the Technical Report[3] for TSP sponsored by the U.S. Department of Defense was published
in November 2000. The book by Watts Humphrey,[4] Introduction to the Team Software Process,
presents a view the TSP intended for use in academic settings, that focuses on the process of
building a software production team, establishing team goals, distributing team roles, and other
teamwork-related activities.

How TSP Works

Before engineers can participate in the TSP, it is required that they have already learned about the
PSP, so that the TSP can work effectively. Training is also required for other team members, the
team lead, and management.
The TSP software development cycle begins with a planning process called the launch, led by a
coach who has been specially trained, and is either certified or provisional.[5][6] The launch is
designed to begin the team building process, and during this time teams and managers establish
goals, define team roles, assess risks, estimate effort, allocate tasks, and produce a team plan.
During an execution phase, developers track planned and actual effort, schedule, and defects,
meeting regularly (usually weekly) to report status and revise plans. A development cycle ends
with a Post Mortem to assess performance, revise planning parameters, and capture lessons
learned for process improvement.
The coach role focuses on supporting the team and the individuals on the team as the process
expert while being independent of direct project management responsibility.[7][8] The team leader
role is different from the coach role in that, team leaders are responsible to management for
products and project outcomes while the coach is responsible for developing individual and team
performance

What Is Team Software Process (TSP)?

Team Software Process (TSP) guides engineering teams that are developing software-intensive
products. Using TSP helps organizations establish a mature and disciplined engineering practice
that produces secure, reliable software in less time and at lower costs.
The yearly TSP Symposium provides a forum for the exchange of ideas and implementation
methodologies for TSP. Visit the symposium website to learn more about the upcoming session
or browse past proceedings.
TSP has been applied in small and large organizations in a variety of domains with similar
results on first use, including

productivity improvements of 25% or more

reductions in cost and schedule variance to less than +/- 10%

testing costs and schedule reductions of up to 80%

The Team Software ProcessSM (TSP) developed by the Software Engineering Institute has helped
software development teams around the world to improve their quality and productivity. In the
past years, Softtek has implemented the TSP for several outsourced software development
projects and service contracts.
Agustin De La Maza, director of the Global Application Development Practice at
Softtek, provides an overview of the Personal Software ProcessSM and the Team Software
ProcessSM, describing the benefits that can be achieved by software development organizations
and providing advice about the implementation strategy.
Key Topics

Introduction to the PSP and TSP

Benefits of using the TSP providing value to business

How does the TSP work?

Relationship between the TSP and other software process and quality models (CMMi, Six
Sigma)

Softteks experience using the TSP for outsourced application development contracts

Personal software process

he Personal Software Process (PSP) is a structured software development process that is
intended to help software engineers understand and improve their performance, by using a
"disciplined, data-driven procedure".[citation needed] The PSP was created by Watts Humphrey to
apply the underlying principles of the Software Engineering Institutes (SEI) Capability Maturity
Model (CMM) to the software development practices of a single developer. It claims to give
software engineers the process skills necessary to work on a Team Software Process (TSP) team.
"Personal Software Process" and "PSP" are registered service marks of the Carnegie Mellon
University.[1]
PSP has been likened to applying Six Sigma toward Software Development. Mukesh Jain led
large scale deployment of PSP/TSP in Microsoft India. Within six months, reportedly more than
2/3 of the projects shipped were without any defects and 94% of the projects were delivered on
time
The PSP aims to provide software engineers with disciplined methods for improving personal
software development processes. The PSP helps software engineers to:

Improve their estimating and planning skills.

Make commitments they can keep.

Manage the quality of their projects.

Reduce the number of defects in their work.

The goal of the PSP is to help developers produce zero-defect, quality products on schedule.
Low-defect and zero defect products have become the reality for some developers and TSP
teams, such as the Motorola division in Florida that achieved zero defects in over 18 projects
through implementing PSP techniques.[3]

PSP structure
PSP training follows an evolutionary improvement approach: an engineer learning to integrate
the PSP into his or her process begins at the first level - PSP0 - and progresses in process
maturity to the final level - PSP2.1. Each Level has detailed scripts, checklists and templates to
guide the engineer through required steps and helps the engineer improve his own personal
software process. Humphrey encourages proficient engineers to customise these scripts and
templates as they gain an understanding of their own strengths and weaknesses.
Process

The input to PSP is the requirements; requirements document is completed and delivered to the
engineer.
PSP0, PSP0.1 (Introduces process discipline and measurement)

PSP0 has 3 phases: planning, development (design, coding, test) and a post mortem. A baseline is
established of current process measuring: time spent on programming, faults injected/removed,
size of a program. In a post mortem, the engineer ensures all data for the projects has been
properly recorded and analysed. PSP0.1 advances the process by adding a coding standard, a size
measurement and the development of a personal process improvement plan (PIP). In the PIP, the
engineer records ideas for improving his own process.
PSP1, PSP1.1 (Introduces estimating and planning)

Based upon the baseline data collected in PSP0 and PSP0.1, the engineer estimates how large a
new program will be and prepares a test report (PSP1). Accumulated data from previous projects
is used to estimate the total time. Each new project will record the actual time spent. This
information is used for task and schedule planning and estimation (PSP1.1).
PSP2, PSP2.1 (Introduces quality management and design)

PSP2 adds two new phases: design review and code review. Defect prevention and removal are
the focus at the PSP2. Engineers learn to evaluate and improve their process by measuring how
long tasks take and the number of defects they inject and remove in each phase of development.
Engineers construct and use checklists for design and code reviews. PSP2.1 introduces design
specification and analysis techniques

(PSP3 is a legacy level that has been superseded by TSP.)

The importance of data

One of the core aspects of the PSP is using historical data to analyze and improve process
performance. PSP data collection is supported by four main elements:

Scripts
Measures

Standards

Forms

The PSP scripts provide expert-level guidance to following the process steps and they provide a
framework for applying the PSP measures. The PSP has four core measures:

Size the size measure for a product part, such as lines of code (LOC).
Effort the time required to complete a task, usually recorded in minutes.

Quality the number of defects in the product.

Schedule a measure of project progression, tracked against planned and

actual completion dates.

Applying standards to the process can ensure the data is precise and consistent. Data is logged in
forms, normally using a PSP software tool. The SEI has developed a PSP tool and there are also
open source options available, such as Process Dashboard.
The key data collected in the PSP tool are time, defect, and size data the time spent in each
phase; when and where defects were injected, found, and fixed; and the size of the product parts.
Software developers use many other measures that are derived from these three basic measures
to understand and improve their performance. Derived measures include:

estimation accuracy (size/time)

prediction intervals (size/time)

time in phase distribution

defect injection distribution

defect removal distribution

productivity

reuse percentage

cost performance index

planned value

earned value

predicted earned value

defect density

defect density by phase

defect removal rate by phase

defect removal leverage

review rates

process yield

phase yield

failure cost of quality (COQ)

appraisal COQ

appraisal/failure COQ ratio

Planning and tracking

Logging time, defect, and size data is an essential part of planning and tracking PSP projects, as
historical data is used to improve estimating accuracy.
The PSP uses the PROxy-Based Estimation (PROBE) method to improve a developers
estimating skills for more accurate project planning. For project tracking, the PSP uses the
earned value method.
The PSP also uses statistical techniques, such as correlation, linear regression, and standard
deviation, to translate data into useful information for improving estimating, planning and
quality. These statistical formulas are calculated by the PSP tool.

Using the PSP

The PSP is intended to help a developer improve their personal process; therefore PSP
developers are expected to continue adapting the process to ensure it meets their personal needs.
PSP and the TSP

In practice, PSP skills are used in a TSP team environment. TSP teams consist of PSP-trained
developers who volunteer for areas of project responsibility, so the project is managed by the
team itself. Using personal data gathered using their PSP skills; the team makes the plans, the
estimates, and controls the quality.

Using PSP process methods can help TSP teams to meet their schedule commitments and
produce high quality software. For example, according to research by Watts Humphrey, a third of
all software projects fail,[4] but an SEI study on 20 TSP projects in 13 different organizations
found that TSP teams missed their target schedules by an average of only six percent.[5]
Successfully meeting schedule commitments can be attributed to using historical data to make
more accurate estimates, so projects are based on realistic plans and by using PSP quality
methods, they produce low-defect software, which reduces time spent on removing defects in
later phases, such as integration and acceptance testing.
PSP and other methodologies

The PSP is a personal process that can be adapted to suit the needs of the individual developer. It
is not specific to any programming or design methodology; therefore it can be used with different
methodologies, including Agile software development.
Software engineering methods can be considered to vary from predictive through adaptive. The
PSP is a predictive methodology, and Agile is considered adaptive, but despite their differences,
the TSP/PSP and Agile share several concepts and approaches particularly in regard to team
organization. They both enable the team to:

Define their goals and standards.

Estimate and schedule the work.

Determine realistic and attainable schedules.

Make plans and process improvements.

Both Agile and the TSP/PSP share the idea of team members taking responsibility for their own
work and working together to agree a realistic plan, creating an environment of trust and
accountability. However, the TSP/PSP differs from Agile in its emphasis on documenting the
process and its use of data for predicting and defining project schedules.
Quality

High-quality software is the goal of the PSP, and quality is measured in terms of defects. For the
PSP, a quality process should produce low-defect software that meets the user needs.
The PSP phase structure enables PSP developers to catch defects early. By catching defects early,
the PSP can reduce the amount of time spent in later phases, such as Test.
The PSP theory is that it is more economical and effective to remove defects as close as possible
to where and when they were injected, so software engineers are encouraged to conduct personal
reviews for each phase of development. Therefore the PSP phase structure includes two review
phases:

Design Review

Code Review

To do an effective review, you need to follow a structured review process. The PSP recommends
using checklists to help developers to consistently follow an orderly procedure.
The PSP follows the premise that when people make mistakes, their errors are usually
predictable, so PSP developers can personalize their checklists to target their own common
errors. Software engineers are also expected to complete process improvement proposals, to
identify areas of weakness in their current performance that they should target for improvement.
Historical project data, which exposes where time is spent and defects introduced, help
developers to identify areas to improve.
PSP developers are also expected to conduct personal reviews before their work undergoes a peer
or team review.