Evolutionary Development Model

 

OVERVIEW
E-enablement is the transformation of a business system or process to make it streamlined and render it accessible via the Internet.  This case study will try and asses the best possible course for enablement.

CHALLENGE
A system is defined as “A group of related elements or activities which are organised for a specific purpose.”  (British Computer Society)

Figure 1, IPO Model

(M. A. Rob, 2005)

A system can be modelled using the basic IPO model.  Figure 1 illustrates the three fundamental component parts: Input, Process and Output.  The IPO model describes how a process can transform and input to give a desired output.

The closed feedback loop element ensures that the system has the ability to measure its outputs by quantitative or qualitative methods.  This analysis can allow the powers to adjust the input and or the process to obtain the desired output.  “This closed loop feedback process ensures the quality of, not only evaluation results, but also current and future science and technology support programmes.” (John Barber [1], 1999).
Software Development

This chapter investigates into various software process models and when they may be used.

A software process model [2] is a structured set of activities required to develop a software system.  The following are the generic parts:

• Specification – this is the stage at which requirements are drawn up.
• Design – at this stage the specification is coded into a either a prototype or the finished product.
• Validation – at this stage the client is given his or her acceptance to the software development.
• Evolution – the client may decide to make minor or major changes or further the existing specification to improve the software being developed. 

Generic Software Process Models

• The waterfall model – Separate and distinct phases of specification and development.
• Evolutionary development – Specification and development are interleaved.
• Reuse-based development – The system is assembled from existing components.

The Waterfall model

The Waterfall method is expensive and is very time consuming because it was designed to minimize the use of very expensive computing resources.  (Pete McBreen, 2002)  The Waterfall model describes a process of stepwise refinement.  It is widely used in military and aerospace industries.

Phases of the Waterfall model are as follows (Figure 8 illustrates this):

1. Requirements analysis and definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance

Fig 2 Waterfall Model

(Royce, 1970)

 Evolutionary development
Many different models have been put forward since the much cited Waterfall model emerged over 30 years ago. There have been few studies that have confirmed empirically the virtues of the newer models such as the Evolutionary development. The most widely quoted references report lessons from only a few successful projects. (Alan D. MacCormack, 2001) [3].  Alan D. MacCormack and his colleagues; Marco Iansiti and Roberto Verganti, completed a two-year empirical study last year, revealing thought-provoking information from the Internet-software industry.

They found that the need for responsive development in the Internet-software industry has never been greater. They analyzed data from 29 completed projects and identified the characteristics most associated with the best outcomes.

They found that Companies would first release a low-functionality version of a product to selected customers at a very early stage of development. Work would then proceed in an ad-hoc fashion, with the development of the design evolving in response to the feedback from customers’. This approach contrasts with traditional models of software development such as the Waterfall method and their more sequential processes. For example, the Waterfall method evolutionary model has been around for several years (35 years to be exact); this is the first time the connection has been demonstrated between the practices that support the model and the quality of the resulting product.

One of the questions that MacCormack’s researchers were trying to answer was “Does a more evolutionary development process result in better performance?”  (Alan D. MacCormack, 2001).  Their finding was that getting a low-functionality version of the product into customer’s hands at the earliest opportunity improves quality dramatically.

Summary of key Exploratory Development characteristics:

• The objective is to work with client and to evolve a final system from an initial outline specification.
• Should start with well-understood requirements.
• The system evolves by adding new features as they are proposed by client.

Fig 3 Exploratory Development Model

(National Physical Laboratory, 2005)

 Reuse-based development

The Reuse-based development is based on the systematic reuse of systems where they are integrated from existing components or COTS (Commercial-off-the-shelf) systems.  Therefore the final product is assembled using existing components

Figure 4 illustrates the process stages for Reuse-based development. These are as follows:

• Component analysis
• Requirements modification
• System design with reuse
• Development and integration

Fig 4 Reuse-Based Development Model

(National Physical Laboratory, 2005)

Incremental Development

Incremental development deals with delivering the system broken down into increments with each increment delivering part of the required functionality, rather than a single delivery date.  User requirements are prioritised and the highest priority requirements are included in early increments.

Once the development of an increment is underway, the requirements are frozen though requirements so that later increments can continue to evolve.

Fig 5 Incremental Development

(National Physical Laboratory, 2005)

Customer value can be delivered with each increment so system functionality is available earlier in the development process.  Early increments act as a prototype to help draw out requirements for later increments.  This therefore results in a lower risk of overall project failure.
SOLUTIONS

 Justifying the Chosen Software Development Method

The waterfall model – The main disadvantage of the Waterfall method is that it is slow and uneconomical; the model has the difficulty of accommodating change after development is underway.  Furthermore, the Waterfall model has an unrealistic separation of specification and design it does not accommodate prototyping.

The Waterfall model takes a static view of requirements which makes it difficult to respond to changing customer requirements.  This is a deliberate act as change equals cost.  Therefore, this model is only appropriate when the requirements are well-understood or can be frozen.

Reuse-based development – No matter which method is used, COTS (Commercial-off-the-shelf) or components will be used during the development process. Without getting technical for example, if the chosen software model is the Evolutionary development method.  Some of the requirements specification may well be satisfied by using existing components.  The ability to upload an updated application document to the website can be achieved much faster by purchasing a component that allows a file to be uploaded to a designated server.

Evolutionary development – Although this model lacks process visibility and offers poor structure to the project because of the ad-hoc manner of development, the Author would recommend this model over the Waterfall method.  The Author prefers this model because of the “Throw-away prototyping” feature of this model.

 Throw-away prototyping – The objective of throw-away prototyping is to validate or determine the system requirements. The prototyping process starts with those requirements which are poorly understood and eventually end up with a set of system requirements:

• Objective is to understand the system requirements. Should start with poorly understood requirements
• Develop “quick and dirty” system quickly;
• Expose to client comment;
• Refine until adequate system developed.

It is a wise choice to use the Throw-away prototyping method to refine the requirements for your system.  I use the term ‘refine’ very loosely I have found in the real world Clients are constantly changing their mind.  This is fairly typical of inexperienced computer users and they learn as they go along.  This leads to changes.

E. M. Bennatan explains in his book On Time Within Budget, Software Project Management Practices and Techniques that software development is “specifying software requirements”  (E. M. Bennatan, 2000).  He identifies the following 5 steps for the evolutionary introduction of orderly process:

1. Requirements Specification
2. Project Development Plan
3. Change Control
4. Test Plans
5. Improve-constantly

 Project Development Plan

The purpose of Project Planning includes the development of the overall project structure, the activities and timeline /work plan that will form the foundation of the project management processes used throughout the project lifecycle.

Careful Project Planning provides the structure and procedures to make sure that adequate time and effort is put into identifying the project scope, deliverables, resource requirements, and risks. The Planning Process also sets out measures that will be used within the project for tracking development.

James Chapman a Project Management Consultant has more than 30 years of experience in project management.  Currently he is responsible for providing program management mentoring and training to the National Nuclear Security Administration to develop project charters, program plans, cost estimates, budgets and resource-loaded schedules. James Chapman (2001) says that “project management principles are most often learned from experience, and they have universal validity for all projects.  It is up to you to apply them intelligently to your project.”  The Principle Based Project Management begins with these principles:

Rule 1- Figure out what business you are in, and then mind your own business.   Understand the business value in your project and watch for changes.  Be diligent in your chosen business, learning and applying best practices.  Define what is inside and outside your area of responsibility.  50% of Project Management is simply paying attention.

Rule 2 – Thoroughly understand and document the customer’s requirements, obtain customer agreement in writing and put requirement documents under version identification and change control.  Requirements management is the leading success factor for systems development projects.

Rule 3 – Prepare a reasonable plan.  Prepare a plan that defines the scope, schedule, cost, and approach for a reasonable project.  Involve task owners in developing plans and estimates, to ensure feasibility and buy-in.  If your plan is just barely possible at the outset, you do not have a reasonable plan.  Use a work breakdown structure to provide coherence and completeness to minimize unplanned work.

Rule 4 – Build a good team with clear ownership.  Get good people and trust them.  Establish clear ownership of well-defined tasks; ensure they have tools and training needed and provide timely feedback.  Track against a staffing plan.  Emphasise open communications.  Create an environment in which team dynamics can gel.  Move misfits out.  Lead the team.

Rule 5 – Track project status and give it wide visibility.   Track progress and conduct frequent reviews.  Provide wide visibility and communications of team progress, assumptions, and issues.  Conduct methodical reviews of management and technical topics to help manage customer expectations, improve quality and identify problems before they get out of hand.  Trust your indicators.  This is part of paying attention.

Rule 6 – Write Important Stuff Down, Share it and Save it.  If it hasn’t been written down, it didn’t happen.  Document requirements, plans, procedures, and evolving designs.  Documenting thoughts allows them to evolve and improve.  Without documentation it is impossible to have baseline controls, reliable communications, or a repeatable process.  Record all important agreements and decisions, along with supporting rationale, as they may resurface later.

Rule 7 – If it hasn’t been tested, it doesn’t work.  If this isn’t absolutely true, it is certainly a good working assumption for project work.  Develop test cases early to help with understanding and verification of the requirements.  Use early testing to verify critical items and reduce technical risks.  Testing is a profession; take it seriously.

Rule 8 – Be relentlessly pro-active.  Take initiative and be relentlessly proactive in applying these principles and identifying and solving problems as they arise.  Project problems usually get worse over time.  Periodically address project risks and confront them openly.  Attack problems and leave no stone unturned.

James Chapman (2001)

Change Control

It is debatable whether change control is more or less important than a project plan.  The need for a product schedule is crucial but uncontrolled change “is one of the most common reasons for project failure” (E. M. Bennatan, 2000).

 Rob Thomsett (2002) has operated the Thomsett Company; offering workshops over the past 22 years to more than 22,000 business and information technology professionals on the subject of Project Management.  He argues that the recent surveys by The Yankee Group and Deloittes and Touche (Johnson, 1995) on the high failure rate of business process reengineering projects, report that poor change control a major factor in the project failure.

Jason Charvat, CBM, is an accomplished Project Management Consultant, with extensive international experience in information technology projects. Jay Charvat is a Senior Manager for RCG Information Technology which is a national IT professional services company based in Edison . The company specialises in IT design, development, integration, and project management. He is the author of Project Management Nation and Project Management Methodologies.  In his article published 15^th November 2002 he states that; ‘projects tend to fail when they exceed their budget and deadlines are missed’.   He attributes this to projects having “no change control procedure in place” and not being “staffed very well“.

Jason Charvat (2002) says that user requirements should be documented and approved to establish a plan for the necessary change controls to support any future changes as a means to control the changes made.  He goes on to say that “I don’t know of too many project managers who can handle too many changes all at once. An even more difficult situation for a project manager surfaces when new changes are introduced after the project has been launched. This usually drives up the cost, resource requirements, deliverables, and completion time. Change needs to be managed and the project manager needs to have a change control process in place to assess the impact and cost of the change and, possibly, negotiate the change for a future release.”

Test Plans

Raymond Rivest (2004) says that Black-box and White-box are test design methods.  The Black-box test design method treats the system as a “black-box”, so it doesn’t explicitly use knowledge of the internal structure.  Black-box test design is described as focusing on testing functional requirements.  Synonyms for black-box include:  behavioural, functional, opaque-box, and closed-box.  However the White-box test design allows one to peek inside the “box”, and focus specifically on using internal knowledge of the software to guide the selection of test data.  Synonyms for white-box include: structural, glass-box and clear-box.  It is important to understand that these methods are used during the test design phase, and their influence is hard to see in the tests once they’re implemented.  Note that any level of testing (unit testing, system testing, etc.) can use any test design method.

Testing can be an ongoing process during the software development cycle. Undoubtedly the most rigorous testing occurs during the end.    Partial testing deals with testing a part of the system only.  If the partial testing results in a success, then it is presumed that the entire project is ready for deployment.

In software development, user acceptance testing (UAT) – is also known as beta testing, application testing, and end user testing.  UAT is a phase of software development in which the software is tested in the “real world” by the intended audience. In context to BSCCP, it would transpose as demonstrating a prototype version of the new system to the Society’s employees to evaluate.  The feedback from this evaluation is forwarded to the developers who can make final changes before releasing the software.

 Improve-constantly

To improve constantly it is important to be willing to abandon old methods and adopt better ones (E. M. Bennatan, 2000). 

Fig 6 Rapid prototyping followed by the phased method

(E. M. Bennatan, 2000)

Figure 6 illustrates the rapid prototyping cycle. To prototype is basically to demonstrate a quickly put to gather (rapid) version of the Information Management System so that the Society’s requirements can be revised.

[1] John Barber Director Technology Economics, Statistics and Evaluation, UK Department of Trade and Industry 1999.

[2] A software process model is an abstract representation of a process

[3] Alan D. MacCormack is an assistant professor in the Technology and Operations Management area at Harvard Business School