SYSTEM DEVELOPMENT METHODOLOGIESIntroduction A system development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system. Awide 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 y methodologies is best suited to specific kinds of projects, ba: on various technical, organizational, project and team considerations.Types of System Development Methodologies: ea elcarel 2 — Prototyping 3 — Incremental eet) eal 5 — Rapid Application Development (RAD) Ya4 — Waterfall =e, Strengths: sr GF) Ideal for supporting less experienced project teams and project managers, or project teams whose composition fluctuates. . 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. . Progress of system development is measurable. 4. Conserves resources. y1 — Waterfall ArT ot sr . Requirements inconsistencies, missing system components, and . Problems are often not discovered until system testing. Inflexible, slow, costly and cumbersome due to significant structure and tight controls. . Project progresses forward, with only slight movement backward. . Little room for use of iteration, which can reduce manageability if used. . Depends upon early identification and specification of requirements, yet ITM Wael e-1e( CoML Leta Uae 1° rd a, unexpected development needs are often discovered during design and coding.1 — Waterfall ArT ot 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 Vy Ele) eicler\ cm 11. Promotes the gap between users and developers with clear division 0} cele a Tela1 — Waterfall Situations where most appropriate: sr fo Od . Project requirements can be stated unambiguously and comprehensively. . Project requirements are stable or unchanging during the system Vy . User community is fully knowledgeable in the business and applicatio) PeeWee MW LN eel ene Project is for development of a mainframe-based or transaction-oriented fee . Project is large, expensive, and complicated. . Project has clear objectives and solution. . Pressure does not exist for immediate implementation. development life cycle.1 — Waterfall Situations where least appropriate: sr . Real-time systems. ae Se llU Ce . Leading-edge applications. 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. . 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 VY users’ knowledge level.2 — Prototyping Framework Type: Iterative Basic Principles: is . Attempts to reduce inherent project risk by breaking a project into smaller y . User is involved throughout the process, which increases the aay 7 Not a standalone, complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology (i, e Incremental, Spiral, or Rapid Application Development (RAD)). segments and providing more ease-of-change during the development process. user acceptance of the final implementation.2 — Prototyping Basic Principles: cm Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users’ requirements. . While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system. . Abasic understanding of the fundamental business problem is necessary y avoid solving the wrong problem.2 — Prototyping Strengths: 1. “Addresses the inability of many users to specify their information needs, ETT RU Re Lien Rem MEU CR OM ae CUM MOSS UNCON UNIL by providing the user with a tentative system for experimental purposes at the earliest possible time.” (Janson and Smith, 1985) 2. “Can be used to realistically model important aspects of a system during each phase of the traditional life cycle.” (Huffaker, 1986) 3. Improves both user participation in system development and ey among project stakeholders. 4. Especially useful for resolving unclear objectives; developing and vali user requirements; experimenting with or comparing various desi solutions; or investigating2 — Prototyping Strengths: cm . May generate specifications for a production application. . Encourages innovation and flexible designs. Especially useful for resolving unclear objectives; developing and validating user requirements; experimenting with or comparing various design solutions; or investigating both performance and the human computer interface. . Potential exists for exploiting knowledge gained in an early iteration as later iterations are developed. . Helps to easily identify confusing or difficult functions and missing Vy functionality. . Provides quick implementation of an incomplete, but functional2 — Prototyping ArT ot sr eh, . Designers may neglect documentation, resulting in insufficient justi Approval process and control is not strict. Incomplete or inadequate problem analysis may occur whereby only the most obvious and superficial needs will be addressed, resulting in current inefficient practices being easily built into the new system. . Requirements may frequently change significantly. . Identification of non-functional elements is difficult to document. Pan PY (e ne MUNN RON Lom eKe (etn Tiale ect iiice- nl ae mice 1m wv, analysis, resulting in an inflexible design with narrow focus that limits futur system potential. for the finaproduct and inadequate records for the future.2 — Prototyping ArT ot 7. . Can lead to false expectations, where the customer mistakenly believes ay , . Iterations add to project budgets and schedules, thus the added costs, 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. the system is “finished” when in fact it is not; the system looks good and has adequate user interfaces, but is not truly functional. be weighed against the potential benefits. Very2 — Prototyping ArT ot 9. Iterations add to project budgets and schedules, thus the added costs must be weighed against the potential benefits. Very small projects may not be able to justify the added time and money, while only the high-risk portions of yy very large, complex projects maygain benefit from prototyping. 10. Prototype may not have sufficient checks and balances incorporated.2 — Prototyping Situations where most appropriate: sr a) . User is not fully knowledgeable. 7. Team members are experienced . Team composition is stable. Project is for development of an online system requiring extensive user dialog, or for a less well-defined expert and decision support system. . Project is large with many users, interrelationships, and functions, where project risk relating to requirements definition needs to be reduced. . Project objectives are unclear. eC aod MOM elf CM) Tal Lele ela UU e . Functional requirements may change frequently and significantly. (particularly if the prototype is not a throw-away). yy2 — Prototyping Situations where most appropriate: 9. Project manager is experienced. BOM NoMa -lero osc ste oN lek=ol N1AMUMEAMooU ceMecolat OTT oot 11.No strict requirement exists for approvals at designated milestones. 12. Analysts/users appreciate the business problems involved, before they begin the project. 13. Innovative, flexible designs that will accommodate future changes are not ford(er- Vyos EMO iT: ead lb cB-vor-ll-10)/ satel mel-1-1(e mele or- Us 5. Project objectives are very clear; project risk regarding reece definition is low.3— Incremental Seats Poel Ke orem exe ed ar 1 Celt Mi - LeeLee: 11 (= else ied ie Basic Principles: Various methods are acceptable for combining linear and iterative system development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process: 1. Aseries of mini-Waterfalls are performed, where all phases of the Waterfall development model are completed for a small part of the system, before VY proceeding to the next increment; OR 2. Overall requirements are defined before proceeding to evolutionary, Waterfall development of individual increments of the system, OR3 — Incremental Strengths : sr . Helps to mitigate integration and architectural risks earlier in the projer Potential exists for exploiting knowledge gained in an early increment as later increments are developed. . Moderate control is maintained over the life of the project through the use of written documentation and the formal review and approval/signoff by the user and information technology management at designated major milestones. . Stakeholders can be given concrete evidence of project status throughout Vy the life cycle.3 — Incremental er et sr When utilizing a series of mini-Waterfalls for a small part of the system before moving on to the next increment, there is usually a lack of overall consideration of the business problem and technical requirements for the (ey -Te- SC . Since some modules will be completed much earlier than others, well- defined interfaces are required. . Difficult problems tend to be pushed to the future to demonstrate early Vy success to management.Fa oy - Web information systems (WIS) and event-driven systems. 3. Leading-edge applications. Ye(completely or in part), reporting of the data.4— Spiral Framework Type: Combination Linear and Iterative Basic Principles: is . "Each cycle involves a progression through the same sequence of steps, for Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle. each portion of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individ program.” (Boehm, 1986)4— Spiral Basic Principles: 3. Each trip around the spiral traverses four basic quadrants: GD MelstulluMol)(otel mec N eae Reco SCCM MON UM CLE OLR (EU recital orale SU are Ree (3) develop and verify deliverables from the iteration; and (4) plan the next iteration. (Boehm, 1986 and 1988) 4. Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment. (Boehm, oY4— Spiral Strengths: 1. 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. 3. Can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases in the framework, and provide guidance as to which the type of project risk. For example, a project with low risk of not meeting combination of these models best fits a given software iteration, based wy, user requirements, but high risk of missing budget or schedule targets wo! essentially follow a linear Waterfall approach for a given software iteray Conversely, if the risk factors were reversed, the Spiral methodolo: yield an iterative Prototyping approach.4— Spiral ArT ot sr . There are no firm deadlines. Cycles continue with no clear termin; Challenging to determine the exact composition of development methodologies to use for each iteration around the Spiral. . Highly customized to each project, and thus is quite complex, limiting reusability. . Askilled and experienced project manager is required to determine how to apply it to any given project. . There are no established controls for moving from one cycle to another Vy cycle. Without controls, each cycle may generate more work for the next oVelce condition, so there is an inherent risk of not meeting budget or schedule.4— Spiral Situations where most appropriate: : . Real-time or safety-critical systems. . Risk avoidance is a high priority. . Minimizing resource consumption is not an absolute priority. . Project manager is highly skilled and experienced. . Requirement exists for strong approval and documentation control. . Project might benefit from a mix of other development methodologies. . Ahigh degree of accuracy is essential. VY [No eS . Implementation has priority over functionality, which can be added in later NES]ea EM a aigteRcctell ge Merolu uo (OLA)5 — Rapid) Application Development eu eae Cc Basic Principles: 1. Key objective is for fast development and delivery of a high quality system at a relatively low investment cost. 2. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development loleeler= 3. Aims to produce high quality systems quickly, primarily through the use of y and computerized development tools. These tools may include Grap! User Interface (GUI) builders, Computer Aided Software Engineeri (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques.5 — Rapid) Application Development Basic Principles: 3. Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques. 4. Key emphasis is on fulfilling the business need, while technological or y engineering excellence is of lesser importance.5 — Rapid) Application Development Basic Principles: 5: Project control involves prioritizing development and defining delivery deadlines or “time boxes”. If the project starts to slip, emphasis is on reducing requirements to fit the time box, not in increasing the deadline. . 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 interaction. . Active user involvement is imperative. . lteratively produces production software, as opposed to a throwaway prototype.5 — Rapid) Application Development Strengths: sr . Concentrates on essential system elements from user viewpoint. The operational version of an application is available much earlier than with Waterfall, Incremental, or Spiral frameworks. . Because RAD produces systems more quickly and to a business focus, this approach tends to produce systems at a lower cost. . Engenders a greater level of commitment from stakeholders, both business seen as gaining more of a sense of ownership of a system, while developers, and technical, than Waterfall, Incremental, or Spiral frameworks. Users wy, are seen as gaining more satisfaction from producing successful systems quickly. . Provides the ability to rapidly change system design as demanded by users.5 — Rapid) Application Development ArT ot sr eh, . Difficulty with module reuse for future systems. . Potential for designed system to lack scalability. More speed and lower cost may lead to lower overall system quality. Danger of misalignment of developed system with the business due to missing information. . Project may end up with more requirements than needed (gold-plating). . Potential for feature creep where more and more features are added to the system course of dev over the development. . Potential for inconsistent designs within and across systems. Vy . Potential for violation of programming standards related to inconsistent naming conventions and inconsistent documentation.5 — Rapid) Application Development ArT ot 9. Potential for lack of attention to later system administration needs built into El 10. High cost of commitment on the part of key user personnel. 11. Formal reviews and audits are more difficult to implement than for a eevee So 12. Tendency for difficult problems to be pushed to the future to demonstrate early success to management. 13. Since some modules will be completed much earlier than others, well- defined interfaces are required.5 — Rapid) Application Development Situations where most appropriate: sr None . Senior management commitment exists to ensure end-user involvem: ato ic nul Mola UL) ) CUA LaL Cues OL eae -10C- LA Project is of small-to-medium scale and of short duration (no more than 6 man-years of development effort). . Project scope is focused, such that the business objectives are well defined and narrow. . Application is highly interactive, has a clearly defined user group, and is not computationally complex. . Functionality of the system is clearly visible at the user interface. Vy . Users possess detailed knowledge of the application area.5 — Rapid) Application Development Situations where most appropriate: 8. Itis not possible to define requirements accurately ahead of time because the situation is new or the system being employed is highly innovative. 9. Team members are skilled both socially and in terms of business. 10. Team composition is stable; continuity of core development team can be Tilia Un=se 11. Effective project control is definitely available. 12. Developers are skilled in the use of advanced tools. Vy 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.5 — Rapid) Application Development Situations where most appropriate: 16. Technical requirements (e.g., response times, throughput, database sizes, CORE UM corolla are Vel ULL weMe-ox-L eM Leen aT m CconATe) (ole) Yex-lg1e) used. Targeted performance should be less than 70% of the published limits of the technology. 17.Development team is empowered to make design decisions on a day-to-day basis without the need for consultation with their superiors, and decisions can be made by a small number of people who are available and wy, co-located.5 — Rapid) Application Development Situations where least appropriate: sr . Many people must be involved in the decisions on the project, a nd ths Very large, infrastructure projects; particularly large, distributed1. information systems such as corporate-wide databases. . Real-time or safety-critical systems. . Computationally complex systems, where complex and voluminous data must be analyzed, designed, and created without the scope of the project. . Project scope is broad and the business objectives are obscure. . Applications in which the functional requirements have to be fully specified before any programs are written. fol Tel ola U mae) a N-ClL-MoL nea ero Lal) AUK} geographically dispersed. yy5 — Rapid) Application Development Situations where least appropriate: 7. The project team is large or there are multiple teams whose work needs to be coordinated. 8. When user resource and/or commitment is lacking. 9. 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 technology will be used for the first time within the project. VY 11. Technical requirements (e.g., response times, throughput, database sizes, etc.) are tight for the equipment that is to be used.ptevic) aval =o 1. “System Development Methodologies for Web Enabled E-Business: A Customization Paradigm”; Linda Night, Theresa Steinbach, and Vince Kellen; November 2001; \ ) 2. “A Survey of System Development Process Models”; Darryl Green and Ann DiCaterino; Center for Technology in Government; February 1998; ( ) 3. “Rapid Application Development: A Review and Case Study”; Paul ow Davies; Kane Thompson Centre; December 1998; (ptevic) aval =o 4. “Introduction to Systems Analysis, Topic 19, Rapid Application Development”; J. R. McBride; Copyright 2002 Prentice-Hall, Inc.; \ y 5. “System Development Life Cycle Models and Methodologies”; Paul Fisher, James McDaniel, and Peter Hughes; Canadian Society for International Health Certificate Course in Health Information Systems, Module 3: System Analysis & Database Development, Part 3: Life Cycle Models and Methodologies; Vy ( L