SYSTEMS ANALYSIS AND DESIGN KP/PC

SYSTEMS ANALYSIS AND DESIGN KP/PC

Introduction

Systems analysis entails studying how parts of a system work and interact. Systems design is the definition of the architecture, modules, components, data, and interfaces of a system that meet specified needs or requirements (Ruparelia, 2010). Systems analysis and design refers to the process of examining problems within computerized environments with the goal of implementing the most effective solutions. Through systems analysis and design, all aspects of identified problems are examined, reviewed, and addressed (Ragunath, Velmourougan, Davachelvan, Kayalvizhi and Ravimohan, 2010). This essay presents a discussion of system analysis and design processes, including models used, stages, feasibility, investigation, meeting requirements, and documentation.

Evaluation of Systems Life Cycle Models

Systems Development Life Cycle (SDLC) refers to a software development framework that describes activities that occur in each stage of the software lifecycle. The SDLC describes specific processes in software engineering, information systems development, and systems engineering, such as the planning, creation, development, and testing of computer systems (Gotterbam, 2002). In the application of the general SDLC model, each phase of software development results in specific deliverables that are applied in subsequent stages (Massey and Satao, 2012). The general SDLC model provides that system requirements are presented as system design, which is used to produce a code in the implementation stage. System testing is used to verify the outcomes of the implementation phase. The system being implemented is tested against original requirements (Gotterbam, 2002). 

The Waterfall Model

The waterfall model is the commonly used lifecycle model. Its simplicity makes it simple to use or apply in system development processes. The main characteristic of the waterfall fall model is that activities of each stage must be finished before subsequent stages are initiated. A review is conducted to ensure that the system development project is going as planned (Balaji and Murugaiyan, 2012). The findings of reviews are used to determine whether or not a project should go to subsequent stages. The waterfall model is rigid as it provides that specific outcomes should be realized in each stage for project implementation to continue. It is easy to manage the waterfall model because of its rigidity. The model is appropriate for small system development projects whose requirements are clear and easy to comprehend (Bassil, 2012). The waterfall model is disadvantageous because if the scope of the project is changed at one stage, the chances of project failure increase. Therefore, it is not appropriate for projects whose requirements are likely to change. In addition, the waterfall model is associated with a high level of uncertainty and risk. This is because a working software or system is produced during the final phases of implementation. It is also not suitable for complex, long, or ongoing projects (Balaji and Murugaiyan, 2012).

Figure 1: Phases of the Waterfall Model

The Fountain Model

The fountain model is an improvement of the logical aspects of the waterfall model. Notably, the phases of the waterfall model are retained in the fountain model. However, the fountain model provides for fallback to one or more of the previous phases of system development (Pillai, 1996). The fallbacks of the fountain model can occur several times until system requirements are met at each stage. The fountain model is advantageous because of its flexibility (Massey and Satao, 2012). Unlike the waterfall model, the fountain model eliminates the possibility of freezing system requirements early in the project. In addition, the fountain model provides for more interactions between requirements and design phases. Furthermore, the fountain model allows system developers to begin coding earlier in the system development process (Mishra and Dubey, 2013). However, the fountain model is limited by the fact that it is hard to delineate some phases from others. In addition, the fountain model does not replicate object orientation in software development. It is also difficult to commit to the outcomes or deliverables of each of the phases of the fountain model (Pillai, 1996).

Figure 2: The Fountain Model

V-Shaped Model

The V-shaped model refers to the Verification and Validation model of the system development lifecycle. Execution is sequential and takes a V-shape. It is an extension of the stages of the waterfall model. The testing phases of the V-shaped model are aligned with matching development phases (Balaji and Murugaiyan, 2012). The V-shaped model requires a high level of discipline in system development. This is because a phase must be completed before the subsequent phase is initiated. The V-shaped model is beneficial for its simplicity. Therefore it is understandable and easy to use (Massey and Satao, 2012). It ensures that defects in software do not flow into subsequent stages. Like the waterfall model, the V-shaped model is appropriate for small system development projects. However, the model is less flexible. It is also associated with a high level of risk since prototypes are not produced. Furthermore, the V-shaped model is not useful in implementing complex or large projects (Balaji and Murugaiyan, 2012).

Figure 3: The V-Shaped Model

The Spiral Model

The spiral model has some similarities with incremental models. However, there are additional phases in the risk analysis of the spiral model. The four stages of the spiral model are Planning, Risk Analysis, Engineering, and Evaluation (Munassar and Govardhan, 2010). The spiral model is characterized by iterations, which are repetitive spirals that allow the software to go through phases of development many times. The iterations of the spiral model provide an opportunity for adequate risk analysis. The model is appropriate for mission-critical and large projects (Gotterbam, 2002). The spiral model is advantageous since the software is developed early in the project. However, the spiral model is relatively costly to implement. In addition, it requires skilled experts to conduct risk assessments. Notably, the success of a project using the spiral model depends on risk analysis (Munassar and Govardhan, 2010). Therefore, problems in the risk analysis phase are likely to result in the failure of a project. Furthermore, the spiral model is not appropriate for small software development projects. Notably, once software enters the testing stage, it cannot go back. Therefore, the functionality of applications being tested cannot be changed with the V-shaped model (Mishra and Dubey, 2013).

Figure 4: The Spiral Model

Importance of Staged Lifecycle

A staged lifecycle is beneficial to system developers because it provides them with a specific structure to work within the design, development, and implementation of information systems (Balaji and Murugaiyan, 2012). It also enables developers to focus on the big picture while implementing activities in each of the phases of system development. The main goal of developing systems is achieved without deficiencies when the development process is staged (Munassar and Govardhan, 2010). Therefore, a staged lifecycle enables system developers to make decisions in each phase of software development that are directed at collective goals. Furthermore, the management of software or system development processes is effectively formalized through the application of staged lifecycle models (Bassil, 2012). For instance, a staged lifecycle enables developers to create formal reviews at each phase, which contributes to the achievement of maximum control of the system development processes. It is through the application of a staged lifecycle model that system developers ascertain that relevant documents are created (Munassar and Govardhan, 2010). These documents are used to aid management or decision-making processes. In addition, documentation of activities at each stage of system development enables the tracking of system requirements and ensures that they are aligned with business needs (Balaji and Murugaiyan, 2012).

A staged lifecycle is important as provides for the creation of intermediate products for effective review (Bassil, 2012). For example, the products created during the implementation of each of the stages of SDLC are reviewed with the purpose of ascertaining that they conform to predefined standards, such as quality and interoperability (Ruparelia, 2010). In addition, the review of products within each stage of system development guarantees that the needs of users or clients are met before products move to subsequent stages. Problems with products are effectively corrected when system developers apply staged lifecycle models. For example, necessary tweaks to a system are made at a specific stage of development to ensure that errors are not carried to subsequent stages (Balaji and Murugaiyan, 2012). Therefore, staged lifecycle models enable businesses to get systems or information systems that meet their needs in the most precise manner.

Importance of Feasibility Study

A feasibility study is an important aspect of the system development process. It allows businesses and developers to establish costs related to the design, development, and implementation of systems (Bowen et al., 2009). Analysis of costs is vital in system development as it provides for the allocation of adequate financial resources to minimize the risk of project failure. A feasibility study also provides for the analysis of system requirements with a view to ensuring that customers and developers agree on the conditions of developing an acceptable information system (Willcocks, 2013). Problems related to system development are effectively reported through a feasibility study. Reported problems form a basis for taking corrective actions meant to promote the success of a project. A feasibility study is also important to companies as it provides them with information on training needs after the development and implementation of systems (Bowen et al., 2009). Therefore, feasibility studies enable organizations to design training programs and activities that are congruent with the training needs of employees for the effective use of installed informational systems.

The scope of an information system is determined through a feasibility study. Therefore, a business uses the findings of a feasibility study to determine the ease of expanding the scope of new systems later if necessary (Kingston, 2004). In addition, a feasibility study enables an organization to determine the ease of changing to new innovative technologies in the future. Therefore, it is through a feasibility study that an organization is able to establish the portability of new systems in the future (Willcocks, 2013). The cost-benefit analyses that are conducted during feasibility studies enable firms to determine whether or not they will meet the costs associated with the execution of systems. Additionally, a feasibility study enables developers and organizations to establish the best model for developing and implementing an information system (Bowen et al., 2009). Issues related to installation and scalability systems are effectively determined through feasibility studies. Notably, the efficiency of organizational systems is enhanced when feasibility studies are conducted. A feasibility study enables developers to integrate correct technologies into systems, which contributes to improving their efficiency (Willcocks, 2013).

The maintenance stage is also analyzed during a feasibility study. Therefore, a feasibility study allows organizations to determine risks related to the maintenance of a system (Kingston, 2004). For example, the methods and costs of maintenance are determined during feasibility studies. Feasibility studies are conducted during the initial stages of system development to ensure that all requirements are analyzed and risks identified. Therefore, risk analysis processes are effectively planned after feasibility studies are carried out. Additionally, plans for the actual implementation of an information system within an organization are made on the basis of the findings of a feasibility study (Willcocks, 2013). Top executives rely on reports of the findings of feasibility studies to make informed choices pertaining to the implementation of change within their organizations (Bowen et al., 2009). Therefore, all areas that require feasibility studies should be analyzed to ensure that problems that are likely to cause project failure are identified and mitigated on time. Effective feasibility studies are both specific and focused. Feasibility studies are also successful when they focus on the mission of an organization. More importantly, alternative solutions should be considered and effectively applied in addressing problems that are identified during a feasibility study (Kingston, 2004).

Components of Feasibility Report

A good feasibility study report should have the following components: project scope, requirements, current analysis, requirement, approach, and review (Willcocks, 2013). A feasibility study report is a formal document on a project that presents findings of research, analysis, and evaluation. The feasibility report reports on the technical feasibility of a project (Bowen et al., 2009). It also reports on the cost-effectiveness and profitability of a project. It is used to aid strategic decision-making related to the initiation and execution of a project. Investors also need a feasibility report to make decisions on whether or not investing in the project is worthwhile (Willcocks, 2013).

Project Scope

The project scope specifies the business opportunity or problem to be addressed through the project. An effective report provides a clear or definitive definition of the business issue warranting the implementation of the project. The project scope also indicates the business functions that the project will affect. End-users, participants, and sponsors of the project are also indicated on the project scope. Notably, the accuracy of the feasibility test depends on the precision of the project scope (Bowen et al., 2009).

Requirements

The requirements aspect of a feasibility report presents both organizational and technical requirements of an information system. When an information system is to be put on the market, resource requirements are highlighted within a feasibility report. The requirements of a system have to be aligned with the objectives and goals of the system development project. Fiscal and physical resources must be stated accurately to prevent project failure (Blumenthal, 2009).

Current Analysis

The current analysis is part of a feasibility report that presents findings of an evaluation of the business or market environment that influences the implementation of an information system. The analysis of the market environment includes the strengths, threats, opportunities, and weaknesses of the system in the context of the current business environment. The current analysis provides top executives with information that aids strategic decision-making processes. The role of an information system implementation project in supporting the strategic goals of an organization, such as competitiveness, is defined in the current analysis section of a feasibility report (Kingston, 2004).

Approach

The approach refers to the method that is used to implement the most effective solution. It includes the actions that must be taken in order to meet organizational or user requirements. An effective feasibility report presents an approach that is most appropriate for achieving preferred solutions to an organizational problem. The approach that is recommended in a feasibility report should be both viable and practical. This means that the approach should be applicable in solving organizational problems that warrant the implementation of an information system (Blumenthal, 2009).

Evaluation

The evaluation aspect of a feasibility report presents findings related to the cost-effectiveness of the project and solution, such as an integrated information system. In addition, the effectiveness of the approach used to implement the recommended solution is evaluated for viability and practicality. The cost of the change project should be estimated and presented in the evaluation component of a feasibility report to inform the allocation of financial resources for project activities. Alternative solutions should also be evaluated to demonstrate that the recommended approach is most suited for meeting organizational requirements and needs (Bowen et al., 2009).

Review

Review is a component of a feasibility report that examines the whole study with the goal of determining its effectiveness, accuracy, and alignment with user requirements. The review is used to support final decisions regarding the initiation of a change project within an organization. The correctness of a feasibility study is depicted in the review. Therefore, the top management team of a company relies on the review component of a feasibility study to approve a change project (Kingston, 2004).

Impact of Different Feasibility Criteria

Functional, technical, and human resource feasibility criteria are conducted to achieve a comprehensive study on the practicality and viability of a change project. Functionality feasibility criteria allow an organization to determine the core and auxiliary functions that will be served by a new information system. Through functional feasibility criteria, an organization determined whether it will achieve critical support or full automation after the integration of an information system into its operations (Bowen et al., 2009). On the other hand, the technical feasibility criterion is used to determine the availability of proposed technologies in the market. Technical feasibility criterion is also important in determining the know-how or skills required for the successful implementation of a system within an organization. The human feasibility criterion determines the HR needs in both the implementation and operational phases (Blumenthal, 2009). Therefore, the human resource feasibility criteria provide for the design and implementation of effective training programs for employees for the development of skills required in the application of new information systems in the execution of work activities.

Systems Investigation, Documentation, and Addressing Systems Requirements

System investigation is the determination of the feasibility of an information system being developed, implemented, or integrated into organizational functions. System investigation is carried out through a feasibility study as described in the previous sections of this paper. The findings of the system investigation should be documented and presented in the form of a feasibility study report (Kingston, 2004). Each of the components of a feasibility report should be included in the feasibility study document. The system requirements should be investigated or addressed during the feasibility study. For example, technical, financial, and human requirements that need to be met must be addressed during the system investigation process and presented accurately in the feasibility study document (Bowen et al., 2009).

Conclusion

Developers of information systems effectively meet organizational and user requirements by applying lifecycle models during system development and implementation processes. Lifecycle models enable developers to address all problems associated with a specific phase of system development to ensure that errors are not carried to subsequent stages. The SDLC framework provides for the formalization of system development processes and the minimization of the risk of failure in the implementation and integration of information systems into the operational areas of an organization. A feasibility study should be conducted to determine the viability and practicality of a system. Financial feasibility is specially conducted to determine whether or not the proposed information system is aligned with the financial arrangements and capabilities of a firm. Functional feasibility is also carried out to determine the level of automation an organization will achieve after the implementation of a new information system into its functional areas. The system investigations that are carried out during a feasibility study should be effectively documented to demonstrate whether or not organizational requirements or needs are addressed.

References

Balaji, S. and Murugaiyan, M.S., 2012. Waterfall vs. V-Model vs. Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), pp.26-30.

Bassil, Y., 2012. A simulation model for the waterfall software development life cycle. arXiv preprint arXiv:1205.6904.

Blumenthal, D., 2009. Stimulating the adoption of health information technology. New England journal of medicine, 360(15), pp.1477-1479.

Bowen, D.J., Kreuter, M., Spring, B., Cofta-Woerpel, L., Linnan, L., Weiner, D., Bakken, S., Kaplan, C.P., Squiers, L., Fabrizio, C. and Fernandez, M., 2009. How we design feasibility studies. American journal of preventive medicine, 36(5), pp.452-457.

Gotterbam, D., 2002. Reducing software failures: Addressing the ethical risks of the software development lifecycle. Australasian Journal of Information Systems, 9(2).

Kingston, J., 2004. Conducting feasibility studies for knowledge based systems. Knowledge-Based Systems, 17(2), pp.157-164.

Massey, V. and Satao, K.J., 2012. Evolving a New Software Development Life Cycle Model (SDLC) incorporated with Release Management. International Journal of Engineering and Advanced Technology (IJEAT), 1(4), pp.25-31.

Mishra, A. and Dubey, D., 2013. A comparative study of different software development life cycle models in different scenarios. International Journal of Advance research in computer science and management studies.

Munassar, N.M.A. and Govardhan, A., 2010. A comparison between five models of software engineering. IJCSI, 5, pp.95-101.

Pillai, K., 1996. The fountain model and its impact on project schedule. ACM SIGSOFT Software Engineering Notes, 21(2), pp.32-38.

Ragunath, P.K., Velmourougan, S., Davachelvan, P., Kayalvizhi, S. and Ravimohan, R., 2010. Evolving a new model (SDLC Model-2010) for software development life cycle (SDLC). International Journal of Computer Science and Network Security, 10(1), pp.112-119.

Ruparelia, N.B., 2010. Software development lifecycle models. ACM SIGSOFT Software Engineering Notes, 35(3), pp.8-13.

Willcocks, L., 2013. Information management: the evaluation of information systems investments. Springer.