Report on System Development Methodologies

System development techniques, according to Wynekoop and Russo (1997), are frameworks used for designing, planning, and regulating the processes of constructing information systems. A variety of different frameworks have evolved over time, each with its own set of flaws and benefits. As a result, one system development process may not be suitable for all client enterprises. This involves the identification of criteria that may affect the suitability of a given development method for various client firms, such as their line of business, size, financial resources, IT infrastructure, and organizational culture. In this regard, this paper presents a business report on system development methodologies highlighting the guidelines that employees should use when selecting the optimal approach for clients.

The size of organization

The size of an organization may determine the knowledge base available in the organization regarding the user requirements for what the system should do. In this regard, where the size of a client organization is small, the consultants should consider using system development methodologies. These methodologies would enable members of the client organization to interact with the technology and get a first-hand understanding of what the new system can do and how to apply it in solving their needs (Spichkova & Campetelli, 2014). As such, the most appropriate system development methodologies in small-sized organizations would be the Prototyping Methodology or the Rapid Application Development (RAD) Methodology (Avison & Fitzgerald, 2003). On the other hand, in comparatively bigger organizations, it is more likely that the user requirements for the work of the system are clear, hence, the consultants would only need to talk about the methodologies and explain them in written reports.

Familiarity with Technology

In instances when the required system will use new technology with which the client organization is not familiar with, early application of the new technology in the system development methodology will improve the chances the effectiveness of the system in the organization. If the system is developed with little or no familiarity with the new technology by members of the client organization, there are higher risks because the system may fail to do what is required (Yaghini, et al., 2009). As such, to avoid the risk, consultants should consider recommending the use system development methodologies that encourage developing design prototypes for areas with high risks. Such approaches may include throwaway prototyping- based methodologies. According to Avison & Fitzgerald (2003), Phased development- based methodologies would also be appropriate in circumstances where the client organizations are unfamiliar with the new technology. This is because the methodologies create opportunities for investigating the technology before completing the design.

Complexity of the required system by the organization

The wide variety of client organizations will also mean a significant variation regarding the complexity of the system they will need to develop. As such, while recommending the appropriate system development methodologies, the consultants should put into consideration the system complexity. Complex systems would require detailed and careful analysis and design. In this regard, the consultants should recommend approaches such as throwaway prototyping- based methodologies rather than prototyping-based methodologies (Fitzgerald, 1996). The former are suited to detailed analysis and design. In some circumstances, the consultants may prefer recommending phased development-based methodologies because of their ability to enable interaction between the client organizations with the system early in the process. However, the use of these methodologies in client organizations with complex system requirement would make the organizations commit less attention to the analysis of the entire problem domain (Baskerville, & Wood-Harper, 2016).

System reliability

The reliability of a system is crucial for every organization. Any organization would need a reliable system. As such, any process of system development would need to factor in the reliability of the complete system. However, for some client organizations, reliability will be significantly critical. For instance, client organizations which deal with missile control systems or medical equipment with need system development methodologies that are likely to lead to very reliable systems. For other client organizations that deal with products such as Internet vides or games, reliability may just be an important aspect but not a crucial factor. In circumstances where system reliability is of high priority in a client organization, the consultant should recommend throwaway prototyping methodologies as opposed to evolutionary prototyping methodologies Schwaber & Beedle (2002). This is because the throwaway prototyping methodologies combine detailed analysis in designing phases with the ability for the organization to test different approaches through design prototypes before it completes the design. On the other hand, evolutionary prototyping methodologies are not appropriate where reliability is of crucial importance because the methodologies lack the careful analysis in designing phases that are essential for critical systems (Palvia, et al., 1990).

Time-span needed

Some client organizations may need systems that run for a long-term basis while others may need systems whose usefulness is short-term. As such, time-schedules are important for consultants when recommending the most appropriate system development methodologies for client organizations. In this regard, Rapid Application Development (RAD) methodologies are the most appropriate approaches in client organizations whose system requirement has short-time schedules (Sabas, et al., 2002). This is because the RAD-based methodologies are well designed to increase the speed of system development. Phased development-based methodologies could also be a good choice in organizations whose system need is for short-run. Waterfall-based methodologies should not be recommended for short-term system projects because they do not allow for easy schedule changes (Henderson-Sellers, 2005).

Rapid Application Development (RAD) Methodology

Rapid Application Development is associated with programming languages that offer faster implementation than traditional third-generation languages such as FORTRAN, Pascal, or C/C++. (Nerur, et al., 2005) This approach is object-oriented and includes methods of system development as well as software tools. The primary purpose of the RAD methodology is to speed up the systems development process. Rapid Application Development Methodology has the following characteristics:

The primary aim of this methodology is for speedier development and delivery of high-quality systems at relatively low investment costs.

This methodology allows the fitting of standard systems analysis and design techniques.

This methodology needs active user involvement.

Reduces project risks by breaking projects into smaller segments making it easier to change during the development project.

The methodology emphasizes on satisfying the organization’s needs, with little regard to engineering and technological excellence.

Benefits of the Rapid Application Development Methodology

With its characteristic of enabling faster development of systems, it allows the faster availability of the operational version of applications.

By producing systems more quickly, the methodology tends to be less costly in the business context.

It enables users to rapidly change system design to their wish.

It gives particular emphasis to the essential system elements from the perspective of the user.

The methodology produces a tighter fit between system specifications and user requirements.

In general terms, it enables the economical use of money, time, and human effort.

Drawbacks of the Rapid Application Development Methodology

By putting in more speed and lower cost, the methodology may compromise the overall quality of the system.

Projects implemented from the RAD Methodology may end up having more requirements than needed (gold-plating).

This methodology is prone to missing information, which may misalign the business with the developed system.

The nature of this methodology may lead to inconsistencies in designs across and within systems.

There is a high likelihood that systems designed from this methodology may lack scalability.

Requires well-defined interfaces because some modules will be completed much earlier than others, owing to the high speed of the methodology.

Waterfall Methodology

This methodology describes a development method that is linear and rigid. The methodology has clear objectives for each phase of development where each phase needs to be completed for the next one to start, and there is no turning back. Waterfall Methodology has the following characteristics:

A project under this methodology is divided into sequential phases.

There is a need for maintaining tight control over the life of a project under this methodology through the use of formal reviews, extensive written documents, and approvals.

At one time of a project under this methodology, the emphasis is placed on time schedules, planning, budgets, target dates, and implementation of the entire system.

Benefits of the Waterfall Methodology

The sequential phases of development and strict control and maintenance help in ensuring the reliability, quality, and the maintainability of the developed system.

Conserves economical resources.

The progress of the system development can be measured.

It is most appropriate for supporting less experienced project managers and teams.

Drawbacks of the Waterfall Methodology

The tight controls and vital structures may make the methodology cumbersome, costly, slow, and inflexible.

Unexpected development needs, missing system components, and requirements inconsistencies are often discovered during coding and designing.

Problems in the systems may not be discovered during the development, and may only come to light when testing the systems.

It is difficult to respond to changes.

Prototyping

This methodology requires software developers to construct an effective representation of the system. It is associated with the following features:

Reduces project risks by breaking projects into smaller segments and making it easy to change during the development processes.

The methodology allows user involvement throughout the process, increasing the likelihood of acceptance of the final system implementation.

In some circumstances, it is possible to evolve from prototype to working systems.

Organizations need to have a basic comprehensive understanding of the business problem to avoid solving the wrong problem.

Benefits of the Prototyping Methodology

The program improves both communications among project stakeholders and user participation in system development.

Can enable quick implementation of an incomplete, but functional application.

Encourages flexible designs and innovation.

May help in the identification of difficult and confusing functions and missing functionality.

Drawbacks of the Prototyping Methodology

There is less strictness in the control and approval process which may compromise reliability, quality, and maintainability.

Documenting the identification of non-functional elements may be difficult.

Project designers may disregard the documentation, leading to the insufficient justification for the final product and insufficient records for the future.

Some prototypes may lack the sufficient incorporation of checks and balances.

Rapid Application Development (RAD) Methodology

This methodology is most suitable in the following circumstances.

Where the project is of a short duration and small-to-medium scale.

Where the application highly involves the users, has a clearly defined user group, and not complex computations are involved.

Where one can clearly see the functionality of the system from the viewpoint of the user.

Appropriate where the requirements of the system are uncertain or unknown.

Where team members have adequate skills in both social and business aspects

Where the technical architecture is clearly defined.

Where developers have adequate skills in using advanced tools.

Waterfall Methodology

Waterfall methodology is highly suitable in the following events.

Where the project is large, complicated and expensive.

Where the project has distinct objectives and solutions.

Where the team members may lack adequate experience.

Where the conservation of resources is needed.

Where the project managers may not be adequately experienced.

Prototyping Methodology

The following are the events under which prototyping methodology is mostly suitable.

Where the project manager is experienced.

Where there is no necessity of conservation of resources.

The composition of the team is stable.

Where there is no strict requirement for approval of the projects.

Where the objectives of the project are unclear.

Where the user is not fully knowledgeable.

Proposed guidelines in selecting appropriate methodologies

Where the project is of a short duration and small- to- medium scale, select the Rapid Application Development (RAD) Methodology.

Where the application highly involves the users, has a clearly defined user group, and not complex computations are involved, select the Rapid Application Development (RAD) Methodology.

Where the requirements of the system are uncertain or unknown, select the Rapid Application Development (RAD) Methodology.

Where developers have adequate skills in using advanced tools, select the Rapid Application Development (RAD) Methodology.

Where the project is large, complicated and expensive, select the Waterfall Methodology.

Where the project has distinct objectives and solutions, select the Waterfall Methodology

Where the team members may lack adequate experience, select the Waterfall Methodology.

Where the project manager is experienced, select the Prototyping Methodology.

Where there is no necessity of conservation of resources, select the Prototyping Methodology.

Where there is no strict requirement for approval of the projects, select the Prototyping Methodology.

Where the objectives of the project are unclear, select the Prototyping Methodology.

Conclusion

A system development methodology is used to structure, plan, and control the process of developing and information system. As discussed in this paper, there is a wide variety of these methodologies, each with unique characteristics and appropriateness in developing systems. Given the uniqueness of these approaches, the factors that determine the choice of a methodology include the size of the client organization, familiarity with technology, the complexity of the system, system reliability, and the time-span needed.

References

Avison, D., & Fitzgerald, G. (2003). Information systems development: methodologies, techniques and tools. McGraw Hill.

Avison, D. E., & Fitzgerald, G. (2003). Where now for development methodologies?. Communications of the ACM, 46(1), 78-82.

Baskerville, R. L., & Wood-Harper, A. T. (2016). A critical perspective on action research as a method for information systems research. In Enacting Research Methods in Information Systems: Volume 2. 169-190. Springer International Publishing.

Fitzgerald, B. (1996). Formalized systems development methodologies: a critical perspective. Information systems journal, 6(1), 3-23.

Henderson-Sellers, B. (Ed.). (2005). Agent-oriented methodologies. IGI Global.

Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), 72-78.

Palvia, P., Nosek, J. T., Palvia, P., & Nosek, J. T. (1990, May). An empirical evaluation of system development methodologies. In Managing information resources in the 1990s: proceedings of 1990 Information Resources Management Association international conference, 72-73.

Sabas, A., Delisle, S., & Badri, M. (2002). A comparative analysis of multiagent system development methodologies: Towards a unified approach.

Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall, 13-15.

Spichkova, M., & Campetelli, A. (2014). Towards system development methodologies: From software to cyber-physical domain. arXiv preprint arXiv:1403.2819, 5.

Wynekoop, J. L., & Russo, N. L. (1997). Studying system development methodologies: an examination of research methods. Information systems journal, 7(1), 47-65.

Yaghini, M., Bourouni, A., & Amiri, R. H. (2009). A framework for selection of information systems development methodologies. Computer and information science, 2(1), 3.