System Development Methodology Selection Criteria
Six Criteria for Selecting a System Development Methodology
Clarity of User Requirements
When user requirements for what the system should do are unclear, it is difficult to understand them by talking about them and explaining them with written reports. Users normally need to interact with technology to truly understand what the new system can do and how to best apply it to their needs. Prototyping and throwaway prototyping-based RAD methodologies are usually more appropriate when user requirements are unclear because they provide prototypes for users to interact with early in the SDLC.
Familiarity with Technology
When the system will use new technology with which the analysts and programmers are not familiar (e.g., the first web development project with Java), early application of the new technology in the methodology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks increase because the tools might not be capable of doing what is needed. Throwaway prototyping-based methodologies are particularly appropriate for a lack of familiarity with technology because they explicitly encourage developers to develop design prototypes for areas with high risks. Phased development-based methodologies are also effective, as they create opportunities to investigate the technology in depth before the design is complete. While one might think prototyping-based methodologies would also be appropriate, they are much less so, since the early prototypes built usually only scratch the surface of the new technology. Usually, it is only after several prototypes and months that developers discover weaknesses or problems in the new technology.
System Complexity
Complex systems require careful and detailed analysis and design. Throwaway prototyping-based methodologies are particularly well suited to such detailed analysis and design, as opposed to prototyping-based methodologies, which are not. The traditional structured design-based methodologies can handle complex systems, but without the ability to get the system or prototypes into the users’ hands early on, some key issues may be overlooked. Although phased development-based methodologies enable users to interact with the system early in the process, project teams following these tend to devote less attention to the analysis of the complete problem domain than they might with other approaches.
System Reliability
System reliability is usually an important factor in system development—after all, who wants an unreliable system? However, reliability is just one factor among several. For some applications, reliability is truly critical (e.g., medical equipment, missile control systems), while for other applications, it is merely important (e.g., games, internet video). Throwaway prototyping methodologies are most appropriate when system reliability is a high priority, as they combine detailed analysis and design phases with the ability for the project team to test many different approaches through design prototypes before completing the design. Prototyping methodologies are generally not a good choice when reliability is critical because they lack the careful analysis and design phases essential for dependable systems.
Short Time Schedules
Projects with short time schedules are well suited for RAD-based methodologies, as they are designed to increase development speed. Prototyping and phased development-based methodologies are excellent choices when timelines are short because they enable the project team to adjust system functionality based on a specific delivery date. If the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under development. Waterfall-based methodologies are the worst choice when time is at a premium because they do not allow for easy schedule changes.