Lightweight processes are beginning to replace more formal methods. The motivation for this transition is based on many factors. The Internet, time to market, cost reduction, quality increases, market pressures, as well as the popularization of these programming methods. This series of articles will investigate the various lightweight methods, their impact on the management of software development projects and the processes by which managers can determine the appropriateness and usefulness of the various processes. The definition of a lightweight Process is more difficult than it would first appear. This article outlines the foundations of a heavyweight process and describes the appropriate pieces that can be converted to lightweight.

1. Lightweight Processes
Definition of a Lightweight Process
Lightweight processes are beginning to replace more formal methods. The motivation for this transition is based on many factors.
The Internet, time to market, cost reduction, quality increases, market pressures, as well as the popularization of these
programming methods. This series of articles will investigate the various lightweight methods, their impact on the management of
software development projects and the processes by which managers can determine the appropriateness and usefulness of the
various processes.
The definition of a lightweight Process is more difficult than it would first appear. This article outlines the foundations of a
heavyweight process and describes the appropriate pieces that can be converted to lightweight.
 1

2. Some Sobering Facts
Numerous reports have analyzed the difference between successful and challenged software projects. Here’s a
summary of the findings, ranked by importance from high to low
Successful Projects Challenged Projects
User Involvement Lack of user input
Executive sponsorship and support Incomplete requirements
Clear statement of the requirements Changing requirements
Proper planning Lack of executive sponsorship
Realistic expectations from the stakeholders Technology incompetence
Small project milestones Lack of resources
Competent staff Unrealistic expectations
Stakeholder ownership Unclear objectives
Clear vision and objectives Unrealistic time frames
Focused staff New technologies
Figure 1: Factors Affecting Successful and Unsuccessful Projects
Before we get too far along in the discussion of software processes, it would be good to recap what the data in
Figure 1 means.
The majority of the items associated with both the success and failure of projects are related to management of
the software process. This includes stakeholder participation, clear requirements from the stakeholders, and
stabilizing these requirements.
One of the tenets of lightweight process, especially eXtreme Programming, is that the requirements will become
clear as the project evolves and that changes in these requirements can be absorbed by the development team,
since they are continually redacting the code anyway.
This is the challenge of discussing lightweight processes − are they appropriate for the general population of
software development projects and products, or are they suited for specialized environments in which the
requirements can be discovered during the development process?
The Taxonomy of Software Development Methods
The definition of a software process is embodied in how a software organization does business, that is, how management and
engineering practices are implemented to support software development and its maintenance. This view of software process
assumes that an organization has a set of building blocks that define the general way it does business and that some subset of
those building blocks is implemented for each software project.
— Software Technology Support Center, Hill Air Force Base, Ogden Utah
A software process is a set of activities, methods, practices, and transformations that people use to develop and maintain software
and associated products. Process technologies are defined as those technologies that can be applied to support an organization's
software process.

3. — Software Technology Support Center, Hill Air Force Base, Ogden Utah (can you add this to the above
blockquote?) (I’d suggest using either one of the above quotes to define a software process or combine
them into one quote.)
Attributes of a Methodology
According to “Software Development Taxonomy,” by SEI, a methodology must posses certain attributes in order
to meet the requirements is being called a methodology. Figure 2 describes the engineering and development
attributes of a methodology as well as the constraints placed on those attributes. An alternative is SEI’s Software
Engineering Body of Knowledge that contains yet another set of attributes for development methods to be used
by any professional software engineer.
Figure 2 is an organization of the attributes of a methodology that can be used to clarify the various approaches.
There are others, but this is a good place to start.
Engineering Attributes Development Attributes Development Constraints
Requirements
Describe the stability,
completeness, clarity, validity,
feasibility, precedent, and scale of
the system requirements.
Development Processes
Including formality, suitability,
process control, familiarity, and
product control.
Resources
Including schedule, staff, budget,
and facilities.
Design
Describes the functionality,
difficulty, interfaces, performance,
testability, physical constraints, and
non–functional aspects of the
system.
Development System
Including capacity, suitability,
usability, familiarity, reliability,
system support, deliverability.
Contract(s)
Including type of contract,
restrictions stated in the contract,
and dependencies defined by the
contract.
Code and Testing
Describes the programming
artifacts and their testability.
Management Processes
Including planning, project
organization, management
experience, and program
management.
Interfaces
Including the customer, associate
contractors and subcontractors,
corporate management
relationships, vendors, and the all–
powerful political influences.
Integration and Test
Describes the environment,
product, and system behaviors
aspects of the product when it is in
use.
Management Methods
Including monitoring, personnel
management, quality assurance,
and configuration management.
Specialties
Describes the various abilities of
the system, including
maintainability, reliability, safety,
security, usability, and other non–
functional specifications.
Work Environment
Including quality attitudes,
cooperation, communication, and
morale.

4. Figure 2: A software development taxonomy framework
Figure 3 outlines the activities of six different software development methods and their relation to a generic set of
activities. This comparison will be used to isolate the lightweight components from the traditional development
activities. In the end, any successful project must provide a set of artifacts that can be used to verify whether the
deliverables met the requirements. This is the challenge of a lightweight process.

5. A “Top 6” List of Methods
Generic SCRUM eXtreme Programming Scott Ambler’s Pattern
Based Development
Walker Royce RUP Adaptive Software
Development
These generic project
phases follow the
steps developed in the
previous sections
SCRUM is an iterative
and adaptable method
based on organizational
patterns [Beedle 98],
[SCRUM 95]
XP is a lightweight
programming
methodology. [Beck 00]
Ambler’s methodology is
a stage based set of
activities arranged in a
logical sequence
[Ambler 99], [Ambler 00]
Royce’s Software
Project Management is
a unified process for
managing development
projects [Royce 98]
RUP is an iterative /
phased methodology
based on 4 major
phases.
ASD [Highsmith 99]
Initiate Pre–Game The Planning Game Initiate Inception Business Modeling Project Initiation
Plan Planning Short Releases Define and Validate Formulate Scope Requirements Conduct Project
Initiation Phase
Execute System Architecture Simple Design Initial Management
Documents
Build Architecture Analysis and Design Adaptive Cycle Planning
Control System Design Testing Justify Prepare Business
Case
Implementation Determine Project
Time Box
Close Game Refactoring Define Infrastructure Elaboration Test Determine optimal
number of cycles and
time box for each cycle
Sprints – concurrent
engineering
Pair Programming Construct Elaborate Vision Deployment Object statement for
each cycle
Develop – analysis,
design, develop
Collective Ownership Model Elaborate Process
and Infrastructure
Configuration & Change
Management
Assign primary
component to cycles
Wrap Continuous Integration Program Elaborate Architecture Project Management Assign technology
Review 40–Hour Week Generalize Construction Environment Develop project task
list
Adjust On–Site Customer Test in the Small Resource
management, control
and process
optimization
Concurrent
Component
Engineering
Post–Game Coding Standards Deliver Component
development
Quality Review
Closure Test in the Large Assessment of
product releases
against acceptance
criteria
Rework Transition Final Quality
Assurance and
Release
Release Synchronize and
integrate construction
elements
Assess Deployment specific
engineering
Maintain and Support Assessment of
deployment baselines
Support
Identify Defects and
Enhancements
 5

6. Figure 3: Table of Contents Summaries of Some Popular Methods

7. Common Threads of These Methods
In an attempt to simplify the many attributes of the methods shown in Figure 3, a list of
common threads could be built, using Figure 4 as a framework.
Thread Compliance
Requirements gathering
Some method of gathering requirements is needed. This ranges
from User Stories, Use Cases, state diagrams, requirements
languages and other formal methods
Code development
Code must meet the requirements. These methods each have
some technique to construct the code in a methodological manner.
Code testing Unit and System testing are performed in some structured manner.
Personnel management
The management of personnel is provided in some methods, but
not all. The XP method makes some broad assumptions about the
skills of the staff, while other, more formal methods address the staff
management and training issues directly.
Project management
Not all methods have techniques for managing the project in a
traditional manner. The non-traditional approaches may be
interesting but are of little comfort to management unfamiliar with the
metrics of lightweight processes.
Figure 4: Common aspects of all methods
What Type of Methodology?
The development methodology lives within a greater context of project management. The
concepts of generic project management are usually lost in this modern age of the Internet
and lightweight process. If we look back to the origins of successful high-technology
organizations, one primary source is The Management of Innovative Technological
Organizations, by Simon Ramo (the R in TRW). The processes in this book are the
antithesis of lightweight, but the principles are timeless.
 Initiate through some official recognition that a project has been formed.
 Plan by creating and maintaining a scheme to accomplish the work at hand.
 Execute through people and resources.
 Control through a means that assures the project objectives are being met.
 Close the project through some formal acceptance process.
Figure 5 describes how these steps are related to each other. Any process, lightweight or
traditional, must provide these steps in some form.
Initiating
Planning
Controlling Executing
Closing
 7
 7

8. Figure 5: Generic Project Management Activities
Within the steps shown in Figure 5, there are several subclasses of methodologies that
can be formed, such as:
 System development methods – which are used to define the end-to-end set of
activities for a software project
 Programming methods – which define the processes used to develop software.
These may include requirements, coding, testing, and support, but target self-
contained projects.
 Design methodologies – which define how software (specifically, object oriented
software) is designed and developed.
No matter what method is named, what the method claims to contribute to the field, and
especially what special powers are attributed to the methodology, there are a small
number of essential attributes of any software development method must posses in order
to deliver value to the stakeholders [Blum 94].
 An application domain – in which the problem exists. The generalization of a
development process must take into account the business domain. Applying a
specific methodology to the wrong domain can result in some type of failure for the
project.
 A conceptual model – that references formalism in the domain of interest. These
models are descriptive in nature and provide guidelines for making decisions about
the problems encountered in the application domain.
 A formal model of some kind – establishes the rules for the acceptance and
correctness of the methodology. These models are prescriptive in nature and describe
the steps, actions, outcomes, and relationships between each of them.
 An implementation domain – which provides the means of solving the problems
encountered in the application domain using a conceptual or formal model of a
method.
All this formality is meant to bring light on the fact that the methodology discussion is
complex and fraught with confusing and sometimes contradicting terms, concepts and
claims. While the confusion is brought to light with the formality, project management is
intended to resolve some of the confusion and organize your project.
Project Management Drivers
The popular discussion of methodologies focuses on requirements, design, coding, and
testing. The management of a development project is focused on controlling the scope,
deliverables, and expectations of the various participants and stakeholders. There are
primary business drivers for the stakeholders as well as the participants in the system
development. The project manager for a software project or product is pulled in many
directions by the participant’s stakeholders. Figure 6 shows some of the tensions placed
on the project manager.

9. Boss
Ambitious Goals
No Over Runs
No Surprises
Finance
Low Budget
Fast Schedule
No Surprises
Users
Lots of functions
User friendly
Fast
Robust
No Surprises
Subordinates
Fast career path
Preference for creative work
Defer documentation
No Surprises
Maintainers / Support Staff
No Bugs
Well Documented
No SurprisesProject
Manager
Figure 6: Tensions on The Software Development Project Manager
The Nine Best Practices
Now that the attributes of a methodology have been expanded to include the management
and stewardships of the project, it is appropriate to look at a completely different approach
to describing how the methodologies fit into a business.
The question to be asked of any development method (especially a lightweight method) is:
What are the attributes of a well–run project, independent of any specific
methodology?
One answer to this is to look at a much higher level at software development processes,
through the eyes of a program manager, a project manager, or a business stakeholder.
The Nine Best Practices constitute a management control system that provides a
disciplined set of processes for containing and directing the complexity of a software
development project — independent of the development methodology [Brown 96].

10. Agreement on
Interfaces
Risk
Management
Formal
Inspections
Metrics Based
Schedule and
Management
Configuration
Management
Project-wide
Visibility of
Progress vs.
Plan
People-Aware
Management
Accountability
Binary Quality
Gates at the
Inch Pebble
Level
Defect
Tracking of
Quality
Targets
Identify and
Correct Defects
Planning and
Tracking
Minimize rework
caused by
uncontrolled
changes
Effective use of
personnel
resources
Figure 7: The Software Program Manager’s Network Nine Best Practices
The Best Practices can be fit into four major categories:
 Identify and correct defects and potential problems as early as possible
 Plan and estimate all project activities and deliverables
 Minimize rework caused by uncontrolled change
 Make effective use of the resources
The reader’s first reaction to these statements may be “aren’t you restating the obvious?”
The Nine Best Practices are, in fact, obvious. The problem comes when it is time to deploy
them into the project environment and attempt to reap the rewards. What seems obvious
is actually difficult. It is this framework that will allow us to discuss lightweight processes
and how they fulfill the higher-level needs of a project and its sponsoring organization.
Software Systems Taxonomy
Before selecting a software development method, some understanding of what type of
software is going to be developed may be appropriate [Jones 00].
Software Type Attributes
Management Information Systems
Software that enterprises use to support their
own business and administrative operations.
The traditional payroll, sales support, and
financial systems are examples

11. Software Type Attributes
Outsourced systems
Software projects that are built for a client
organization. This could include contracted
software development or commercial systems
tailored to meet the needs of the organization.
Systems software
Software that controls a physical device such
as a computer or a telephone switch.
Embedded systems are part of this group,
which includes nearly every modern device that
is microprocessor controlled.
Commercial software
Software applications that are marketed to
hundreds or even millions of clients. Word
processors, spreadsheets, ERP applications,
and Java applets are examples.
Military software
Software produced for the uniformed services.
This includes commercial applications such as
payroll and logistics as well as weapon system
software.
End-User Software
Small applications written for personal use.
This could include spreadsheet programs,
database programming, or even actual
programming language applications.
Web Application and e–Projects
Small-, medium-, and large-scale projects with
legacy system integration, transaction
processing, multimedia delivery, and Web
browser based user interfaces
Figure 8: Software Systems Taxonomy
The search for the one methodology that can solve any problem leads to the conclusion
that there are not only many methodologies, but also many methodologies suiting your
project. The specific methodology depends on the project size, criticality of the system
being built, the scope of the project, the quality demands of the project, and the personal
anchors of the stakeholders and participants [Cockburn 97].
The following selection criteria can be used to decide if a specific process, or for that
matter, which group of processes is right for a project [Glass 00]:
 Size of the Project − larger projects would seem to need larger methods. The
lightweight advocates contend that the lightweight methods scale, but the true
scalability of the lightweight methods are limited by:
 The number of people on the project
 The number of different locations of these people
 The physical environment of the development process. This could be a radar
control system that requires that the development staff be physically co–
located with the equipment.
 The Project Domain − in what business or technical domain does this project live?
 Business applications are distinctly different from real-time control systems.
 Customer relationship management is distinctly different from the shop-floor
control systems
 Embedded software systems are different from Web-based, user interaction
systems.
 The consequences of a product or project malfunction − what is the impact of a
system failure?
 Flight control systems are different than library book check-out systems

12.  Telephones switches are different than telephone billing systems
 Technical innovation level of the project [1]
− does this project make use of beyond the
state of the art technology? This does not have to be some science fiction technology
either. A simple lack of bandwidth can hamstring the most robust online offering.
What’s Coming Next
With this introduction to lightweight processes and their place in the taxonomy of software
development methodologies, the next step is to define the specifics of deploying a
lightweight method on a real project. This will include:
 The mandatory steps for any process, whether lightweight or not
 The time allocation percentages for typical stages of a project
 The tools needed to help the process along
 The show stopper activities that must be avoided
About the Author:
Glen Alleman has more than 22 years experience in the development of mission critical
software systems. As a graduate student at the University of California, Irvine, Glen
developed real time control and data processing systems for various high energy laser
experiments. These experiences lead to positions with aerospace and commercial
vendors, designing and developing digital signal processing algorithms, guidance and
control systems, and information and intelligence management systems.
In 1994, Glen founded Niwot Ridge Consulting to provide mission critical system
architecture services to industrial and commercial clients, including Chevron, Exxon,
Monsanto, Boise Cascade, Kimball Furniture, and Coors Brewing.
1
An old joke in the weapons systems business was to ask the bid manager if the project required
the invention of new physics to meet the specifications. If so, we had better put in some extra time and
money in the proposal to cover this hard stuff.

13. Bibliography
[Ambler 00] The Unified Process: Elaboration, Scott Ambler, RD Books, 2000
[Ambler 99] More Process Patterns: Delivering Large Scale Systems Using
Object Technology, Scott Ambler, Cambridge University Press, 1999.
[Beck 00] eXtreme Programming Explained: Embrace Change, Kent Beck,
Addison Wesley, 2000.
[Beedle 98] “SCRUM: An Extension Pattern Language for Hyperproductive
Software Development,” Mike Beedle, Martine Devos, Yonat Sharon,
Ken Weber, and Jeff Sutherland, PloP 98.
[Blum 94] “A Taxonomy of Software Development Methods,” Bruce I. Blum,
Communications of the ACM, 37(11), November 1994, pp. 82–86.
[Brown 96] “Industrial–Strength Management Strategies,” Norm Brown, IEEE
Software, July 1996, pp. 94–102.
[Cockburn 97] “The Methodology Space,” Alistair Cockburn,
http://members.aol.com/acockburn/papers/methyspace/methyspace.ht
m.
[Glass 00] “Process Diversity and a Computing old Wives/Husbands Tale,”
Robert Glass, IEEE Software, July/August, 2000, pp. 128–129.
[Highsmith 99] Adaptive Software Development: A Collaborative Approach to
Management Complex Systems, Jim Highsmith, Dorset House,
1999.
[Jones 00] Software Assessments, Benchmarks, and Best Practices, Capers
Jones, Addison Wesley, 2000.
[Royce 98] Software Project Management: A Unified Framework, Walker Royce,
Addison Wesley, 1998.
[SCRUM 95] “SCRUM Software Development: Building The Best Possible
Software,” Advanced Development Methods,
www.controlchaos.com/scrumwp.htm.