selecting development approach

SELECTING A DEVELOPMENT APPROACH Original Issuance: February 17, 2005 Revalidated: March 27, 2008 Introduction A system development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations. CMS has considered each of the major prescribed methodologies in context with CMS’ business, applications, organization, and technical environments. As a result, CMS requires the use of any of the following linear and iterative methodologies for CMS systems development, as appropriate. Acceptable System Development Methodologies Waterfall

Initial InvestigationRequirementsDefinition

System Design

Coding, testing,...

ImplementationOperation &Support

Framework Type: Linear Basic Principles:

1. Project is divided into sequential phases, with some overlap and splashback acceptable between phases.

2. Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.

3. Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the

_____________________________________________________________________________________________ Office of Information Services 1

user and information technology management occurring at the end of most phases before beginning the next phase.

Strengths:

1. Ideal for supporting less experienced project teams and project managers, or project teams whose composition fluctuates.

2. The orderly sequence of development steps and strict controls for ensuring the adequacy of documentation and design reviews helps ensure the quality, reliability, and maintainability of the developed software.

3. Progress of system development is measurable. 4. Conserves resources.

Weaknesses:

1. Inflexible, slow, costly and cumbersome due to significant structure and tight controls. 2. Project progresses forward, with only slight movement backward. 3. Little room for use of iteration, which can reduce manageability if used. 4. Depends upon early identification and specification of requirements, yet users may not be

able to clearly define what they need early in the project. 5. Requirements inconsistencies, missing system components, and unexpected development

needs are often discovered during design and coding. 6. Problems are often not discovered until system testing. 7. System performance cannot be tested until the system is almost fully coded, and under-

capacity may be difficult to correct. 8. Difficult to respond to changes. Changes that occur later in the life cycle are more costly

and are thus discouraged. 9. Produces excessive documentation and keeping it updated as the project progresses is

time-consuming. 10. Written specifications are often difficult for users to read and thoroughly appreciate. 11. Promotes the gap between users and developers with clear division of responsibility.

Situations where most appropriate:

1. Project is for development of a mainframe-based or transaction-oriented batch system. 2. Project is large, expensive, and complicated. 3. Project has clear objectives and solution. 4. Pressure does not exist for immediate implementation. 5. Project requirements can be stated unambiguously and comprehensively. 6. Project requirements are stable or unchanging during the system development life cycle. 7. User community is fully knowledgeable in the business and application. 8. Team members may be inexperienced. 9. Team composition is unstable and expected to fluctuate. 10. Project manager may not be fully experienced. 11. Resources need to be conserved. 12. Strict requirement exists for formal approvals at designated milestones.

Situations where least appropriate:

1. Large projects where the requirements are not well understood or are changing for any reasons such as external changes, changing expectations, budget changes or rapidly changing technology.


2. Web Information Systems (WIS) primarily due to the pressure of implementing a WIS project quickly; the continual evolution of the project requirements; the need for experienced, flexible team members drawn from multiple disciplines; and the inability to make assumptions regarding the users’ knowledge level.

3. Real-time systems. 4. Event-driven systems. 5. Leading-edge applications.

Prototyping

ramework Type: Iterative

asic Principles: alone, complete development methodology, but rather an approach to

(i.e.,

2. smaller segments and

3. ihood of user

4. developed following an iterative modification

5. ill be discarded, it

6. y to avoid solving

trengths:

resses the inability of many users to specify their information needs, and the e user

2. alistically model important aspects of a system during each phase of

3. velopment and communication among project stakeholders.

Initial Investigation

RequirementsDefinition

System Design

Coding, testing,...

Implementation Maintenance

F B

1. Not a standhandling selected portions of a larger, more traditional development methodologyIncremental, Spiral, or Rapid Application Development (RAD)). Attempts to reduce inherent project risk by breaking a project into providing more ease-of-change during the development process. User is involved throughout the process, which increases the likelacceptance of the final implementation. Small-scale mock-ups of the system are process until the prototype evolves to meet the users’ requirements. While most prototypes are developed with the expectation that they wis possible in some cases to evolve from prototype to working system. A basic understanding of the fundamental business problem is necessarthe wrong problem.

S1. “Add

difficulty of systems analysts to understand the user’s environment, by providing thwith a tentative system for experimental purposes at the earliest possible time.” (Janson and Smith, 1985) “Can be used to rethe traditional life cycle.” (Huffaker, 1986) Improves both user participation in system de


4. Especially useful for resolving unclear objectives; developing and validating user requirements; experimenting with or comparing various design solutions; or investigating

5.

7. e specifications for a production application.

tional, application. We

1. Approval process and control is not strict. lete or inadequate problem analysis may occur whereby only the most obvious

ulting in current inefficient practices being

3. 4. lements is difficult to document.

ient up-front user needs analysis, system potential.

l

irty system” without global consideration

8. t; the system looks good and has adequate user interfaces,

9. mall projects may not be able to justify the added

10. Sit

both performance and the human computer interface. Potential exists for exploiting knowledge gained in an early iteration as later iterations are developed.

6. Helps to easily identify confusing or difficult functions and missing functionality. May generat

8. Encourages innovation and flexible designs. 9. Provides quick implementation of an incomplete, but func

aknesses:

2. Incompand superficial needs will be addressed, reseasily built into the new system. Requirements may frequently change significantly. Identification of non-functional e

5. Designers may prototype too quickly, without sufficresulting in an inflexible design with narrow focus that limits future

6. Designers may neglect documentation, resulting in insufficient justification for the finaproduct and inadequate records for the future.

7. Can lead to poorly designed systems. Unskilled designers may substitute prototyping for sound design, which can lead to a “quick and dof the integration of all other components. While initial software development is often built to be a “throwaway”, attempting to retroactively produce a solid system design can sometimes be problematic. Can lead to false expectations, where the customer mistakenly believes that the system is “finished” when in fact it is nobut is not truly functional. Iterations add to project budgets and schedules, thus the added costs must be weighed against the potential benefits. Very stime and money, while only the high-risk portions of very large, complex projects maygain benefit from prototyping. Prototype may not have sufficient checks and balances incorporated.

uations where most appropriate: 1. Project is for development of an online system requiring extensive user dialog, or for a

ision support system.

.

4. ing. ange frequently and significantly.

a throw-away).

inimize resource consumption.

less well-defined expert and dec2. Project is large with many users, interrelationships, and functions, where project risk

relating to requirements definition needs to be reduced3. Project objectives are unclear.

Pressure exists for immediate implementation of someth5. Functional requirements may ch6. User is not fully knowledgeable. 7. Team members are experienced (particularly if the prototype is not8. Team composition is stable. 9. Project manager is experienced. 10. No need exists to absolutely m


11. No strict requirement exists for approvals at designated milestones. re they begin the project.

e not critical. Sit

12. Analysts/users appreciate the business problems involved, befo13. Innovative, flexible designs that will accommodate future changes ar

uations where least appropriate: 1. Mainframe-based or transaction-oriented batch systems.

s.

al. ct risk regarding requirements definition is low.

ncremental

e: Combination Linear and Iterative

arious methods are acceptable for combining linear and iterative system development h the primary objective of each being to reduce inherent project risk by

lopment leted for a small part of the system, before proceeding to the next

2. ll individual increments of the system, OR

stem y iterative Prototyping, which

Streng

1. Potential exists for exploiting knowledge gained in an early increment as later increments eveloped.

nd the formal review and approval/signoff by the user and information

3. 4. in the project.

n is negatively impacted.

Weakn

1. When utilizing a series of mini-Waterfalls for a small part of the system before moving e next increment, there is usually a lack of overall consideration of the business

problem and technical requirements for the overall system.

2. Web-enabled e-business system3. Project team composition is unstable. 4. Future scalability of design is critic5. Project objectives are very clear; proje

I Framework Typ Basic Principles: Vmethodologies, witbreaking a project into smaller segments and providing more ease-of-change during the development process:

1. A series of mini-Waterfalls are performed, where all phases of the Waterfall devemodel are compincrement; OR Overall requirements are defined before proceeding to evolutionary, mini-Waterfadevelopment of

3. The initial software concept, requirements analysis, and design of architecture and sycore are defined using the Waterfall approach, followed bculminates in installation of the final prototype (i.e., working system).

ths:

are d2. Moderate control is maintained over the life of the project through the use of written

documentation atechnology management at designated major milestones. Stakeholders can be given concrete evidence of project status throughout the life cycle. Helps to mitigate integration and architectural risks earlier

5. Allows delivery of a series of implementations that are gradually more complete and cango into production more quickly as incremental releases.

6. Gradual implementation provides the ability to monitor the effect of incremental changes,isolate issues and make adjustments before the organizatio

esses:

on to th


2. Since some modules will be completed much earlier than others, well-defined interfacesare required. Difficult problems tend to be pushed to the future to demons

3. trate early success to

Sit

management.

uations where most appropriate: Large projects1. where requirements are not well understood or are changing due to external changes, changing expectations, budget changes or rapidly changing technology.

) and event-driven systems.

Situ

2. Web Information Systems (WIS3. Leading-edge applications.

ations where least appropriate: 1. Very small projects of very short duration. 2. Integration and architectural risks are very low.

where the data for the project already exists (completely analysis or reporting of the data.

Spiral

asic Principles: 1. Focus is on risk assessment and on minimizing project risk by breaking a project into

hange during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project

n throughout the life cycle. n

3. r basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; identify and resolve

3. Highly interactive applications or in part), and the project largely comprises

Evaluate AlternativesIdentify, Resolve Risks

Develop, VerifyNext Level Product

Plan Next Phases

Determine Objectives,Alternatives, Constraints

Framework Type: Combination Linear and Iterative B

smaller segments and providing more ease-of-c

continuatio2. “Each cycle involves a progression through the same sequence of steps, for each portio

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.” (Boehm, 1986) Each trip around the spiral traverses fou


risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration. (Boehm, 1986 and 1988) Begin each cycle with an identification of stakeholders and their win conditions, and en4. d

Streng

1.

3. Can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases framework, and provide guidance as to which combination of these models best fits

based upon the type of project risk. For example, a project

linear Waterfall approach for a given software

Weakn

1.

2. us is quite complex, limiting reusability. 3. A skilled and experienced project manager is required to determine how to apply it to any

roject.

more work for the next cycle. o

6. ts that project ends up implemented following a Waterfall framework. Situati

each cycle with review and commitment. (Boehm, 2000)

ths: Enhances risk avoidance.

2. Useful in helping to select the best methodology to follow for development of a given software iteration, based on project risk.

in thea given software iteration, with low risk of not meeting user requirements, but high risk of missing budget or schedule targets would essentially follow aiteration. Conversely, if the risk factors were reversed, the Spiral methodology could yield an iterative Prototyping approach.

esses: Challenging to determine the exact composition of development methodologies to use for each iteration around the Spiral. Highly customized to each project, and th

given p4. There are no established controls for moving from one cycle to another cycle. Without

controls, each cycle may generate5. There are no firm deadlines. Cycles continue with no clear termination condition, s

there is an inherent risk of not meeting budget or schedule. Possibility exis

ons where most appropriate: 1. Real-time or safety-critical systems.

Risk avoidance is a high priority. 2.

4. Project manager is highly skilled and experienced. pproval and documentation control.

ther development methodologies. tial.

dded in later versions. Situ

3. Minimizing resource consumption is not an absolute priority.

5. Requirement exists for strong a6. Project might benefit from a mix of o7. A high degree of accuracy is essen8. Implementation has priority over functionality, which can be a

ations where least appropriate: 1. Risk avoidance is a low priority. 2. A high degree of accuracy is not essential.

4. Minimizing resource consumption is an absolute priority.

3. Functionality has priority over implementation.


Ra

ramework Type: Iterative

asic Principles: st development and delivery of a high quality system at a relatively

low investment cost. reduce inherent project risk by breaking a project into smaller segments and

3. quality systems quickly, primarily through the use of iterative

face (GUI) builders, s

ed

4.

5. ol involves prioritizing development and defining delivery deadlines or the

ine.

on.

8. 9. ent and maintenance.

chniques can be fitted into this framework. Str

all, Incremental, or Spiral frameworks.

use RAD produces systems more quickly and to a business focus, this approach

3. ment from stakeholders, both business and technical, a

elopers are seen as gaining more satisfaction

4. 5. 6. nts and system specifications.

n effort. We

2. Danger of misalignment of developed system with the business due to missing

).

pid Application Development (RAD) F B

1. Key objective is for fa

2. Attempts toproviding more ease-of-change during the development process. Aims to produce highPrototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User InterComputer Aided Software Engineering (CASE) tools, Database Management System(DBMS), fourth-generation programming languages, code generators, and object-orienttechniques. Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance. Project contr“timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fittimebox, not in increasing the deadl

6. Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interacti

7. Active user involvement is imperative. Iteratively produces production software, as opposed to a throwaway prototype. Produces documentation necessary to facilitate future developm

10. Standard systems analysis and design te

engths: 1. The operational version of an application is available much earlier than with Waterf

2. Becatends to produce systems at a lower cost. Engenders a greater level of committhan Waterfall, Incremental, or Spiral frameworks. Users are seen as gaining more ofsense of ownership of a system, while devfrom producing successful systems quickly. Concentrates on essential system elements from user viewpoint. Provides the ability to rapidly change system design as demanded by users. Produces a tighter fit between user requireme

7. Generally produces a dramatic savings in time, money, and huma

aknesses: 1. More speed and lower cost may lead to lower overall system quality.

information. 3. Project may end up with more requirements than needed (gold-plating


4. Potential for feature creep where more and more features are added to the systemcourse of dev

over the elopment.

tent documentation.

9. dministration needs built into system. personnel. plement than for a complete system.

ss to

Sit

5. Potential for inconsistent designs within and across systems. 6. Potential for violation of programming standards related to inconsistent naming

conventions and inconsis7. Difficulty with module reuse for future systems. 8. Potential for designed system to lack scalability.

Potential for lack of attention to later system a10. High cost of commitment on the part of key user 11. Formal reviews and audits are more difficult to im12. Tendency for difficult problems to be pushed to the future to demonstrate early succe

management. 13. Since some modules will be completed much earlier than others, well-defined interfaces

are required.

uations where most appropriate: Project is of s1. mall-to-medium scale and of short duration (no more than 6 man-years of development effort).

hat the business objectives are well defined and narrow.

lex.

6. ment exists to ensure end-user involvement.

f time because the situation is

business.

11.

16. , throughput, database sizes, etc.) are of the technology being used. Targeted

ed limits of the technology. ithout

Situati

2. Project scope is focused, such t3. Application is highly interactive, has a clearly defined user group, and is not

computationally comp4. Functionality of the system is clearly visible at the user interface. 5. Users possess detailed knowledge of the application area.

Senior management commit7. Requirements of the system are unknown or uncertain. 8. It is not possible to define requirements accurately ahead o

new or the system being employed is highly innovative. 9. Team members are skilled both socially and in terms of 10. Team composition is stable; continuity of core development team can be maintained.

Effective project control is definitely available. 12. Developers are skilled in the use of advanced tools. 13. Data for the project already exists (completely or in part), and the project largely

comprises analysis or reporting of the data. 14. Technical architecture is clearly defined. 15. Key technical components are in place and tested.

Technical requirements (e.g., response timesreasonable and well within the capabilitiesperformance should be less than 70% of the publish

17. Development team is empowered to make design decisions on a day-to-day basis wthe need for consultation with their superiors, and decisions can be made by a small number of people who are available and preferably co-located.

ons where least appropriate: Very large, infrastructure projects; particularly large, distributed1. information systems such as corporate-wide databases.

ems.

thin the scope of the project.

2. Real-time or safety-critical syst3. Computationally complex systems, where complex and voluminous data must be

analyzed, designed, and created wi


4. Project scope is broad and the business objectives are obscure. any

nd the decision makers

7. e or there are multiple teams whose work needs to be coordinated.

9. .

hnology will be used for the first time

ght

Refer

ent Methodologies for Web Enabled E-Business: A Customization Night, Theresa Steinbach, and Vince Kellen; November 2001;

ysDev.htm

5. Applications in which the functional requirements have to be fully specified beforeprograms are written.

6. Many people must be involved in the decisions on the project, aare not available on a timely basis or they are geographically dispersed. The project team is larg

8. When user resource and/or commitment is lacking. There is no project champion at the required level to make things happen

10. Many new technologies are to be introduced within the scope of the project, or the technical architecture is unclear and much of the tecwithin the project.

11. Technical requirements (e.g., response times, throughput, database sizes, etc.) are tifor the equipment that is to be used.

ences: “System DevelopmParadigm”; Linda (http://www.kellen.net/S )

terino; t; February 1998;

tions/reports/survey_of_sysdev

“A Survey of System Development Process Models”; Darryl Green and Ann DiCaCenter for Technology in Governmen(http://www.ctg.albany.edu/publica )

ogies”; Paul Fisher, James McDaniel, ate Course in Health

formation Systems, Module 3: System Analysis & Database Development, Part 3: Life Cycle

“System Development Life Cycle Models and Methodoland Peter Hughes; Canadian Society for International Health CertificInModels and Methodologies; (http://famed.ufrgs.br/pdf/csih/mod3/Mod_3_3.htm) “Rapid Application Development: A Review and Case Study”; Paul Beynon-Davies; Kane Thompson Centre; December 1998; (http://www.comp.glam.ac.uk/SOC_Server/research/gisc/RADbrf1.htm)

opic 19, Rapid Application Development”; J. R. McBride; 5t19.pdf

“Introduction to Systems Analysis, TCopyright 2002 Prentice-Hall, Inc.;(http://www.csc.uvic.ca/~jmcbride/c37 )


http://famed.ufrgs.br/pdf/csih/mod3/Mod_3_3.htm

http://www.comp.glam.ac.uk/SOC_Server/research/gisc/RADbrf1.htm

selecting development approach

Documents