Plan-driven software development

Overview of Plan-driven software development

Plan-driven software development is a more formal specific approach to creating an application. Plan-driven methodologies all incorporate: repeatability and predictability, a defined incremental process, extensive documentation, up-front system architecture, detailed plans, process monitoring, controlling and education, risk management, verification and validation.

Plans are typically generated by the following:

• Project broken down into stages/tasks
• Each task broken into its composite activities
• Each individual task estimated (perhaps using metrics)
• Estimates aggregated to give total effort
• Task list analysed for concurrencies and dependencies to provide schedule
• Schedule and delivery date help provide team size and team composition
• Team assembled and project commences
• Monitoring and control throughout development
• Delivery!

[Source: Coleman, Gerry. Software Process Management, Dundalk IT / IT Tralee(2008)]

Overview of Plan-driven methodologies

The Plan-driven methodologies are known as "Heavy-weight" methodologies or "Traditional" methodologies.

Three of the most prominent plan-driven methodologies are the Personal Software Process (PSP), Team Software Process (TSP), and Rational Unified Process (RUP).

[Source: OpenSeminar]

A software development process is the process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes installing and checking out the software for operational use. Note: these activities might overlap or be performed iteratively.

[Source: IEEE, 1990]

Personal Software Process (PSP), Team Software Process (TSP), and Rational Unified Process (RUP), all of which use the incremental model, are described below.

Models

Incremental model

With the Incremental Model, the system is analysed, designed, developed, and tested in increments which are clearly defined. In other words the project is broken down into a series of builds. The core functionality is dealt with in the first increment and with the final increment the complete project is released. It emphasises a building block approach which means that an operational system is produced more quickly.

Complete requirements may be gathered up front or the project may begin with general objectives which are refined with each iteration. The requirements are prioritised, the higher a requirements 's priority the earlier it is to be included in an increment. Thus, new functionality added should not be more important than that which exists in the current build

The process can be illustrated as in figure 1.

..

Iteration

Each iteration can be seen as a mini project with its own lifecycle (this could be waterfall, for example). The end product of each iteration is an executable system which is integrated and tested. An iteration usually lasts for a predefined, relatively short period of time (generally a number of weeks.

Advantages

• Operational portion ready early in project.

Rapid return on investment

• Allows for gradual introduction of new product to client.
• Early and regular feedback from clients.
• Early discovery of high risks
• Accommodates changes

Disadvantages

• Each new build has to be incorporated into the existing build without breaking it.
• Clients have more opportunity to attempt to change requirements than with, for example, the waterfall method.
• Has the potential to degenerate into a build and fix model.

Waterfall model

Successful software project rate has increased considerably since 70’s. This is explainable by standard and accepted methods of process management in companies. Lifecycle model development began in 70’s with suggested waterfall lifecycle model as a pioneer in software development. This model was proposed by Winston W. Royce and was successfully employed in the industry during these years.

Waterfall model has a linear structure characteristic. This linear structure defines the sequentially of tasks where task should be completed before the next task can be started, thus following non-iterative principle. Plan driven development mirrors the approach by waterfall model where steps in the development are planned out from the beginning until the project completion. Waterfall lifecycle model development is broken down into five steps:

• Requirement analysis: development team meets project stakeholders to identify needs and establish requirements to satisfy project goals. Requirement analysis initially is a feasibility study that identifies functional and non-functional requirements with its constraints. Documentation is generated.

• Design: development team converts requirements into representation of architectural model. Prototypes are created with functional algorithms and data structures. Creating accurate design in this stage is vital because after completing design stage, development team doesn’t go back to the design previous stage. Design is finalised and overall of the project outcome depends on it.

• Coding and implementation: design is transformed into software.

• Testing: software domain is tested for bugs. Different sets of tools are available for testers and developers to detect and fix defects in the software.

• Maintenance: stage where product is updated (patched), to meet changing needs and environments. Fixing undetected bugs during testing stage and defects that might arise during updates.

Prior phases must be completed as accurate as possible. This model is structured the way that there is no return to previous phase. Any mistakes made in any of the phases would result in increased costs, time of the project and effort of the team.

The main disadvantage is the static lifecycle structure where this method can’t be employed in dynamic environment which requires an iterative approach. Waterfall lifecycle model is used in big government, military and other projects that utilise previous experience, estimation of time, costs and complexity is foreseen.

---

Spiral Model

Source: http://www.elanman.org/teaching/gmu/swe620-infs622/Graphics/spiral_model.gif

Spiral lifecycle model is a software development process associated with components design and prototyping. It inherits the concept of waterfall model, and involves risk analysis and iteration in each development phase.

Spiral lifecycle model follows the waterfall lifecycle model of software development, requirements analysis, design, coding, testing, and maintenance. The great distribution would be that it changed the phases of waterfall model into many pieces of iteration processes, to reduce the risk of project.

In each iteration, people should do:

1. Determine objectives, alternatives and constrains.
2. Evaluate alternatives.
3. Identify and resolve risks.
4. Develop product.
5. Verify next-level product.
6. Plan next phases (iteration).

People would be focusing on software management, establish the explicitly objective, and analyse the key risk.

---

V-Model

The V-Model (sometimes referred to as Vee Model) can be seen as a refinement of the waterfall method, with a focus on testing. It was developed for the German Military in the 1980s, and is a standard for all software development projects in the public sector in Germany.

The model derives its name from the fact that it can be represented as a v-shaped flow chart.

The V-Model as shown in the above diagram has the same sequence as the Waterfall Method. Each subsequent phase is begun upon the completion of the preceding one. The analytical and design phases precede coding and the testing phases follow but the relationship between each analytical/design phase and the corresponding testing phase is indicated by the horizontal arrows. So for example unit test phase is concerned with the implementation phase.

Phases in the V-Model

Requirements planning Determine system requirements and how the organisation's resources are to be used to meet those requirements. Create specification detailing the expected behavior of the software.

Design Includes both a high level and detailed design. High level design defines how the functions of the software will implement the specifications while detailed design is concerned with specific algorithms.

Implementation The coding phase where the algorithms from the design phase are turned into code.

Unit testing Each module is tested for errors.

Integration Testing Once each module is tested and known to be error free, they are integrated. This phase tests that the integrated modules maintain correct behaviour.

System testing The, now integrated, software system is tested in its intended hardware environment. At stage acceptance testing could also be included, here the user tests the system against the original requirements specification. Checks whether the entire software

Submodels

The V-Model is structured into submodels of which there are four; Project Management, System Development, Quality Assurance and Configuration Management.

Project Management (PM)

The PM submodel is concerned with the initiation, planning and monitoring of the project. It consists of fourteen activities.

Placement/Procurement Sending out request of proposal to possible sub-contractors. Determining best offer.

Contractor Management Ensuring that terms and conditions of contract are fulfilled. Both with customers and subcontractors.

Detailed Planning Establish a detailed plan for the project.

Cost Benefit analysis Evaluate the profitability of each of the planned solutions.

Phase Review The project status is checked at the end of each phase.

Risk Management Early prevention of risks

Project Control Ensure that the project is going according to plan. If not, take action to bring it back on course.

Information Service/Reporting Provide information to stakeholders.

Training/Instruction. Train project team members to ensure that each is aware of and able to perform their role.

Supplying resources The supply of the resources necessary for the completion of the project

Allocation of Work Orders The initiation of job sections as allocated by work orders

Staff Training The introduction of project members to their particular job section. Each member has his/her task explained to them.

Project completion Completion of the project including a final report.

System Development (SD)

The SD sub-model is concerned with the regulation of the actual development of the system. It consists of nine activities.

• System Requirements Analysis
• System Design
• Software/Hardware Requirements analysis
• Preliminary Software Design
• Detailed Software Design
• Software Implementation
• Software Integration
• System Integration
• Transition to Utilisation

Quality Assurance (QA)

The QA sub-model specifies quality requirements for the activities and products of the other submodes. It consists of five activities.

• QA Initialisation
• Assessment Preparation
• Process Assessment of Activities
• Product Assessment
• QA Reporting

The Configuration Management (CM)

The CM sub-model ensures that products can be identified unambiguously and that changes to products are made only in a controlled way. It consists of four main activities.

• CM Planning
• Product and Configuration Management
• Change Management
• CM Services.

Advantages/Disadvantages

Advantages

• Strong emphasis on testing
• Validation of internal and external deliverables not just the product.
• Definition of requirements before designing the system.
• Enable project management to track the progress very accurately. The completion of each phase is a milestone in the project plan.

Disadvantages

• Does not handle concurrent events.
• Does not handle iterations.
• Can't handle the dynamic changing of requirements during the lifecycle.

Methodologies

Note that the methodologies below all use the incremental model.

Personal Software Process

Personal Software Process (PSP) was described by Watts Humphrey in 1994. PSP is based on Capability Maturity Model (CMM) operations. PSP has an iterative structure which defines tasks for improvement of personal development. Definition of processes in each iteration stage are measured and analysed.

Development of software begins from defining a pseudo code, following steps codes is written compiled, possible errors that might occur are reviewed. Reviewed code is tested. Personal techniques for progress measurement are developed; personal metrics allow measuring the success of the progress.

All collected information is assessed for strength and weaknesses; this allows producing personal improvements at the later stages. There are seven key models that software engineer has to pursue for PSP, these knowledge areas are:

1. Foundational Knowledge – software engineers are practising defined processes which allow them to fulfil the scope with high-quality product on time.
2. Basic PSP Concepts – are process fidelity, data collection, data analysis, and process improvement.
3. Size Measuring and Estimating – definition of size measurement from previous, personal experience.
4. Making and Tracking Project Plans – this involves the skill and tools to schedule and plan project duration for successful completion on time.
5. Planning and Tracking Software Quality – creation of high-quality product that meets the scope that satisfies the customer.
6. Software Design – capability for design integration into PSP.
7. Process Extensions – flexibility moving from one environment to another.

---

Team Software Process

The Team Software Process (TSP) was developed in 1996 by Watts S. Humphrey and refined over a number of releases in the following years. There is an emphasis on advance planning and communication and an underlying goal of guiding team building and team working.

Goals

The goals of the TSP are to deliver high quality secure software and to build effective, highly motivated teams that can consistently deliver on time and within schedule and budget constraints.

Overview

Software projects often fail because teams fail to work together efficiently. TSP provides a framework that teams can follow to increase their success as well as improving the overall software development process.

TSP was devised by Watts S. Humphrey as a complementary process to Personal Software Process (PSP) and is based on practices expressed in the Capability and Maturity Model (CMM).

When Humphrey devised the PSP as an application of CMM to an individual developer, it became clear that a PSP developer could not function in a team that did not have the necessary structures in place to support PSP practices. The TSP was devised to address these problems. So where PSP is CMM for the individual, TSP is CMM for teams.

TSP is described as a CMM level 5 process, meaning that it is aimed at organisations that are at , or very close to the Optimising level in CMM and are focusing on continuous process improvement. However, TSP has been proven to be successful for organisations at CMM Level 2 (Repeatable) and has been shown to be a suitable vehicle for introducing process improvement within and organisation.

TSP teams relaunch periodically to accommodate changing requirements and issues that arise during the development process.

The Launch Meeting

The TSP Launch meeting is the key step in any TSP projects. It establishes the overall plan for the project and sets out key measurements and deadlines.

A TSP launch meeting lasts over four days and consists of nine separate meetings, the end result of which is a plan that all the team has committed to and agrees upon. It is important to note that team in this context refers to senior managers and marketing personnel as well as team leaders and developers. The TSP launch meeting should be chaired by a trained TSP launch coach.

In the first of the nine meetings, senior management and marketing establish the need for the product and the opportunity it represents. The seven interim meetings are with the team and team leader, where they break down the project into constituent parts and establish responsibilities and measures before finalising a plan (or alternative plan if the original senior management and marketing cannot be satisfied) . In the last meeting, this plan is presented to senior management and either accepted or revised to meet any additional criteria. As well as having a trained coach to guide the launch process, TSP provides a launch script template to follow.

Benefits

• Projects that do succeed in using TSP have a low risk of failure.

• TSP projects have been proven to succeed in building highly effective motivated teams. The built-in process improvement aspect of TSP ensure that data gathered feeds back into team activities, helping to highlight issues and leading to resolutions.

• TSP can be used as a vehicle for process improvement within an organisation. Teams can adopt TSP and use it to identify and implement process improvement.

• TSP is scalable from single teams of between two and twenty people up to multiple teams totally 100 to 150 people.

Drawbacks

• TSP inherits the many drawbacks of PSP, namely the bureaucratic nature of the process, a lack of tools that support the measurement aspect of the process and the difficulties associated with the significant training required.

• TSP requires all team members to be trained in PSP. Given the problems associated with PSP training and dropout rates, TSP is almost automatically unsuitable in many cases.

• TSP is highly customisable and while this can be of benefit in certain circumstances, the workload involved in trimming down the volume of documentation to suit the needs of a specific team and project can be daunting

• There is disagreement as to whether TSP is an agile methodology or not. TSP advocates state that TSP is frequently accepted as being an agile methodology. This is because the process provides for periodic relaunch every three to four months. Postmortems are carried out on the current body of work and this data feeds into the next launch meeting. The principle is to discover integration and other issues early in the process and take corrective action where necessary. Critics argue that TSP is too process-heavy to be categorised as agile and the durations of iterations are too long to be truly effective.

• A common criticism of TSP is that it is an academic process that has rarely been implemented outside of academia or a select few military and government projects. This would seem to be borne out in the types of projects cited by the Software Engineering Institute for TSP.

Additional Reading

• The TSP Web Site

• The Team Software Process

• Why Big Software Projects Fail: The 12 Key Questions

• CMMI Level 5 and the Team Software Process

---

Rational Unified Process

Introduction

The Rational Unified Process (RUP) was developed in the late 90’s. Three prominent software experts known as the “Three Amigos” [Grady Booch, Ivar Jacobson and Jim Rumbaugh], each of whom had their own software companies and methodologies on software development and modelling, merged their ideas together to form the Unified Process, Unified Modelling Language (UML) and the Rational Software Corporation (Rational). The RUP came about when the Rational Software Corporation created its own version of the Unified Process, the Rational Unified Process.

[Source: http://en.wikipedia.org/wiki/Image:RationalUnifiedProcess.png]

Phases

A project that uses the RUP has iterations which are divided into four phases:

1. Inception

Here the goals, broad scope, initial architecture, project planning, start-up activities and initial process configuration of the project are defined.

2. Elaboration

Here the scope is redefined to include more specific project details such as the features to be included in the project. The architecture is developed in a greater detail to ensure the new features will be functional and also that performance and security are taken into account. A prototype can be developed to practice any new technologies that will be used in the project.

3. Construction

In the construction phase, each iteration provides for new sections of the program/feature to be designed, constructed and tested. At the end of the construction phase the software element of the project should be just about complete.

4. Transition

In the transition phase the software is gradually taken by the customer/user. This is done after user acceptance testing, beta testing and a deployment stage. If issues/bugs are found at this stage they can be fixed in a new release during this stage. Once everything is satisfactory, the software gets handed over to the client, documentation is finalised and training and support is given to the users if necessary.

Iterations

There can be any number of iterations in each phase. RUP does not set the limit but does recommend that there should only be 3 to 9 iterations per project with a duration of 2 to 6 weeks for the iterations. Iterations can be up to 8 months for very large projects using RUP.

Roles

Roles define the responsibilities within each of the 9 workflows in RUP. There are over 40 roles defined by the RUP. Each role is specific which one of the team takes on. Examples of roles are Database Designer, Software Architect, Test Designer, Process Engineer, etc. Every person in the team takes on one or more roles. Each role can have more than one person assigned to it. It is the Project Manager’s responsibility to decide who takes on what roles.

Examples of roles and responsibilities [taken from Williams, L "A Survey of Plan-Driven Development Methodologies" (2004)]:

• Analyst, who is responsible for eliciting the needs from the stakeholders, and communicating the needs to the development team.
• Designer, who identifies and defines the design and makes sure it is consistent with the system architecture.
• Implementer, who is responsible for developing and testing software components.
• Reviewer, who reviews the software product or development activities.
• Test Designer, who defines the test approach to make sure the test is successfully implemented.
• Tester, who implements and runs the test suites.
• Integrator, who is responsible for planning and performing integration tasks.
• Project manager, who manages the resource and activities of the project to ensure the success of the outcome.
• Technical writer, who composes the communications from the developer for the product stakeholder.
• Software architect, who is responsible for the system architecture.
• User interface designer, who works with the developers to produce desired user interface.

RUP Artefacts [Artifacts in American-English]

These are mostly either documents or else collection of documents. The people assigned to certain roles created and update the artefacts for that role. Examples are Vision, Use Case Model, Software Architecture Document, etc. There are more than 100 different artefacts defined by the RUP.

Disciplines and Workflows

Activities link the roles and the artefacts together by having the person in a role create or update the artefacts during a specific activity. There are over 60 workflow details defined in the RUP between the 9 disciplines, each of which are broken down into more steps.

Use Case Driven Development

The idea of a “use case” comes from the RUP. It conveys the steps required in order for a task to be completed and does so in a non-technical manner so that anybody would be able to understand it. This makes is much easer for the system developers to work with the customers and helps in finding out what the actual requirements of the customer are.

Benefits/Disadvantages of Plan-driven software development

Comparing of the agile software development, the Plan-driven development is a traditional development method, it does more emphasise particularly on plan and architecture. Plan-driven development methods’ attention is quality of software and predictability of process. The first rank paradigm of Plan-driven methods is related with capability maturity model (CMM).

Plan-driven software development is come from system engineering and the criterion of quality, builds up the principle of system engineering, coordinates lots of components which need work together accurately.

In order to push the process of software development, the Plan-driven development precisely depends on clear procedures.

Typically, the waterfall lifecycle model starts with some requirements analysis, moves into design, then coding, then implementation, testing, and finally maintenance. Every phase all need its former correct specific requirements, then can continue.

Note however that the example plan-driven methodologies above all use the incremental model, none use the waterfall model

So the key point of plan-driven software development is definition of the process and management. The advantage is its comparability and repeatability in association with the improvement of the procedure.

The main flaws of some plan-driven software development are that requirements change over time, as businesses and the environment in which they operate change rapidly. So it could not suitable for rapid development. Furthermore, the Plan-driven software development advocates predicting change using the framework. The framework will affect some waste of the resource in this rapid development environment. At last, from the culture aspect, plan-driven development could not let people feel comfortable, authorised, and more freedom under development.

Incremental model, such as the example methodologies above, and spiral model plan-driven software development better accommodate change through the use of iterations than the waterfall model.

Prevalence of Plan Driven Development

Introduction

With the hype surrounding Agile methods, there is a temptation to believe that plan driven development is effectively defunct and is only used in very specific circumstances on very specialised projects.

While it is difficult to get exact data on the popularity of various software development methodologies there are a few surveys which provide some level of information. All of these suggest that Waterfall development is still widely used, even though that is declining as agile methods like XP become better understood.

Another indicator of the persisting use of waterfall style development is the body of work being produced that addresses ways of transitioning from waterfall and other non-iterative plan-driven processes to iterative development processes (such as the three example methdologies above), and also techniques for mixing both types of processes.

These factors suggest that waterfall style development is alive and well in many organisations.

Use in Open Source Projects

Open source projects are effectively incompatible with most forms of plan driven development. In most cases it is impractical to apply the level of process and documentation to open source projects.

The team membership grows and shrinks through the lifetime of an open source project. Contributors often only engage in the parts of the project in which they have an interest or even appropriate expertise. Participation is often voluntary. It would be impossible to ensure that contributors were trained in or complied with a process-heavy development process.

Also, the consensus based philosophy of the open source development process is effectively incompatible with the bureaucratic, top-down organisational structures that are characteristic of most plan driven development processes.

Use in Industry

Within the software industry, plan driven development is still widely used on military and government projects, particularly many that mandate the incremental model. It also prevails in many large financial institutions. There is plenty of evidence to suggest that even these organisations are transitioning to other iterative and especially agile processes and methodologies. Whether these organisations will eventually transition completely away from the 'old-style' processes remains to be seen but for now it is likely that the two approaches to software development must co-exist.

For example, an "early and striking example of a major IID success is the very heart of NASA’s space shuttle software—the primary avionics software system, which FSD built from 1977 to 1980. The team applied IID in a series of 17 iterations over 31 months, averaging around eight weeks per iteration. Their motivation for avoiding the waterfall life cycle was that the shuttle program’s requirements changed during the software development process". ["Iterative and Incremental Development: A Brief History", Craig Larman and Victor Basili, IEEE Computer, June 2003]

Why does Plan Driven Development persist

There are many reasons why organisations persist with plan driven development processes like the incremental methodologies above and Waterfall.

Standards

Requirements of suppliers to meet standards set by customers may dictate the development process that is used in a given organisation. Aspects of iterative development may be incompatible with the standards set by customers.

For example the US Department of Defense standard 5000.2 (like Mil-Std-498 before it) has planning requirements with a strong preference for evolutionary (incremental and iterative, such as the example methodologies above) over single step (waterfall):

"There are two approaches, evolutionary and single step, to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability...software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development."

Expertise

May organisations have teams that are well versed in existing plan driven development processes. Many of these will be highly skilled professionals with a track record of delivering software using a plan driven process. Abandoning these proven processes and embarking on retraining is often difficult to justify

Dependencies

In many cases the software development process is part of a larger process within the business. Changing the development process without disrupting other processes and keeping to required standards is not an easy thing to do and may be obstacle to adoption of different (e.g. one of the iterative methodologies above, if currently waterfall) development processes.

Documentation

There are issues around documentation that arise when using iterative development. In it's first form, more bureaucratic organisations that value project documentation will have difficulties adapting to certain aspects of the iterative process where standard design, architecture and other planning documents are not as prevalent. This is also another area where iterative development processes can come into conflict with meeting required standards.

Planning

For a project manager versed in waterfall plan driven development, iterative development projects (such as the incremental plan-driven methdologies above) are initially daunting. There is a lesser degree of predictability with iterative development which is a natural consequence of increased flexibility.

Culture

Cross all of the issues above is the culture within a company. Iterative development can be a huge upheaval both personal and professional within an organisation. Often iterative development can pose such a radical change in work practices as to appear unworkable in organisations well versed in Waterfall style development.

Future

The transition to iterative development, such as the three methodologies above, is ongoing, and the benefits that waterfall style development bring to many organisations will ensure it remains in use until iterative and/or agile methods can address the concerns of these organisations in the same way that plan driven has done in the past.

Additional Reading and References

Requirements Engineering: The state of the practice

Survey says... Agile has crossed the chasm

Converting a project from a waterfall to an iterative approach

Turning Waterfall Contracts into Scrum Contracts

MIL-STD-498

Iterative and Incremental Development: A Brief History, IEEE Computer June 2003

Comparison of Plan-Driven and Agile Development

Software Development Methods

With every endeavour taken it is proven by experience that a methodological approach saves times and provide better quality results. This also applies to software development. All methodologies that are used by software developing organisations can be categorised into two main streams namely Plan-Driven Development and Agile Development. Both these methodologies include components such as defined processes, procedures and documentation. However it is the approach in utilising these components to successfully complete a software development project.

Plan-driven development may be broken up into waterfall development and plan-driven incremental development, as detailed above.

In order to understand the different approaches that define either Plan-Driven or Agile development in software engineering, it is important to identify the general phases that occurs in nearly any software project. The International Organisation for Standardisation (ISO) conducted research that led to the establishment of a standard (ISO 12207) that describes a set of processes and tasks that defines the lifecycle for software. While some methodologies might work with different phases in a particular project domain, the following phases are repeatedly apparent in software development cycles.

• Requirements: In the requirements phase the project team needs to capture what the client needs are in relation to a software product. The requirements are always documented in some format and signing the document of makes the requirements official. Requirements can change during a project therefore it is important to state the boundaries of a product.

• Design: The design phase allows the project team to reflect proposals for the implementation of the software product and highlight boundaries and needed interfaces in the existing environment. When stakeholders agree on these proposals a detailed design is established which encompasses coding specifications

• Coding: This phase involves the actual development of the core product based on the designs agreed on. The project team uses coding standards and reviews. Also developers use comments in the code and test driven development can be applied to save debugging time afterwards.

• Testing: When the application is coded test plans are executed to determine a working product in the client’s environment. This is followed by the actual system test to ensure that all features are working. It is important to include end users in the testing process in order to tackle any other problems prior to release of the system.

• Integration and implementation: This involves the roll-out of the system in the client’s environment.

• Documentation & Maintenance: The documentation produced at each phase of the project is categorised in two sections: Internal & External. Internal documentation is project plans, specifications, designs and test plans. These are useful should the client need additional features to the system in the future. External documentation include user, operational, technical and training guides. These are important documents to sustain the system

• Upgrade & Retirement: Should the requirements of the business change, the current system could undergo certain upgrades to support the business. Or requirements could have changed in such a drastic manner that a new system is needed in this case it could be more cost effective to replace the system instead of upgrading it.

Foundation of Plan-Driven & Agile Development

There is one major fundamental difference between Plan-Driven and Agile development. Plan-Driven development tends to be successful in an environment where all properties of the end product are specified in detail and provides a clear model of a fixed end result. It assumes that a project is predictable and therefore it is possible to plan and design the whole from beginning to end form the start. An example of a Plan-Driven Development in practice can be the construction of a large building. In this an architect designs the building completely based on the requirements of the customer before the first brick is laid. A software example could be an application that allows remote workers to connect to the office and access company specific resources.

In contrast Agile development is a much better approach when the properties of the final product cannot be determined on beforehand. The projects requires a basic part of the project to be built in order to determine what is needed in order for the product to evolve. To give an example of Agile development in the same context as the remote workplace, a client could need a portal that includes intranet, extranet and online collaboration for internal and external workers that are based locally or remote. Since the requirements are somewhat unclear it impossible to design the whole system upfront prior to implementation. It requires exploration of requirements for certain deliverables in every separate component.

Plan-Driven vs. Agile Development

For making a fundamental comparison between Plan-Driven & Agile development, Michael Hirsh has clearly described how the general software development phases described above are approached in each development process. The following table provides examples and descriptions of each software development phase applied in either Plan-Drive or Agile software development.