Cascade, iterative and spiral models for implementing corporate information systems
The life cycle (hereinafter referred to as the life cycle) of software (hereinafter referred to as the software) consists of a number of stages, beginning with the inception stage and ending with the termination of use (Fig. 1). Any information system (hereinafter referred to as IS) is represented by a set of software products or software, thereby defining the life cycle of software and IS are identical. Due to the fact that modern corporate information systems (hereinafter referred to as CIS) consist of many information systems, the latter also applies to CIS.
Rice. 1. Software life cycle
The process of implementing a CIS is an integral part of the life cycle. In progress [1] a typification of the stages of implementation of CIS is provided, including the stages of preparation, design, implementation, pilot and productive operation. The stages of CIS implementation set the sequence of operations necessary for the successful use of a software solution at the customer’s enterprise. Thus, we can talk about two life cycles: the life cycle of a corporate information system and the life cycle of the process of its implementation. Following the data in Fig. 2, the stages of the cycles are often comparable, but in the first case the emphasis is on the software product, and in the second – on the progress of its implementation. The process of implementing a CIS is often called an implementation model, which specifies the order of operations for implementing the system, and the sequence and content of activities varies from model to model. There are three basic models of CIS implementation, all others are considered as their derivatives [2]:
The purpose of this work is to analyze models for implementing corporate information systems to ensure an effective implementation process. Realization of the goal will require a separate detailed consideration of each of the models.
Rice. 2. Comparison of the system life cycle and stages of CIS implementation
Cascade model for implementing corporate information systems
Let's use the standard life cycle stages of an implementation project (Fig. 2). Let us transform the linear sequence as follows: each previous stage is shifted upward to the left, and each subsequent stage is shifted to the right downward, thereby obtaining a diagram that follows from left to right and from top to bottom. The cascade model of CIS implementation is formed by connecting the resulting stages to each other (Fig. 3). This model, or, as it is often called, the Waterfall model, was proposed in 1970 by W. Royce. The implementation of the project, according to this model, is carried out by strictly fulfilling the tasks of each stage (typical stages of CIS implementation), with the transition to the next stage is possible only if the previous stage is successfully completed [3]. Skipping any of the stages, returning to previous stages and repeating stages is prohibited, which is why the model is often called sequential or single-pass. Following Fig. 3, the advantages and disadvantages of the waterfall model are obvious. The advantages include:
transparency in determining deadlines, work and costs;
existence of an agreed procedure for transition between stages;
independence of stages execution,
the disadvantages are:
Rice. 3. Transition from standard stages to a cascade model of CIS implementation
The CIS implementation project based on this model consists of the following activities:
project preparation, which consists in the formation of basic concepts, strategies and approaches to the implementation of CIS functionality;
identification and analysis of requirements for CIS and their prioritization;
formation of design solutions and specifications describing the method of implementing previously formed requirements for CIS;
customization and refinement of the CIS based on previously prepared solutions and specifications describing the implementation of requirements;
functional-modular, integration and acceptance testing of completed configurations and modifications of the CIS;
transition to productive operation and support.
In addition, each stage ends with validation and approval of the activities of the next stage, as well as confirmation of the possibility of moving on to the next stage. The above list demonstrates a pattern: the design, implementation and testing of CIS are carried out on the basis of requirements identified in the early stages. Thus, if the initial requirements were formed incorrectly, the entire information system will be prepared incorrectly (the previously noted minus about the impossibility of eliminating errors from previous stages), which will most likely require completion of the CIS. The lack of flexibility of the model can be attributed to both a minus and a plus: if a partial implementation of a CIS of insignificant functionality is being carried out, it is advisable to include possible changes in requirements compared to the initial ones in the project. However, when a multifunctional CIS is implemented, integrated with many external and internal subsystems, a minor adjustment of the requirements can lead to significant changes in terms, work and costs.
That is why the cascade model is often used in projects for implementing CIS “from scratch” and “replication”, when the volume of work performed and their labor costs reach impressive values. On such projects, a conflict of interests arises between various stakeholders, so the results of each stage are carefully documented and agreed upon in order to avoid discrepancies and increase the amount of work. It is impossible to launch a CIS on an enterprise scale, taking into account the requirements and wishes of each employee. Therefore, the scope of tasks is fixed by a list of the most important and confirmed requirements by key, but not by end users. If new requirements appear or existing requirements change, it is proposed to register a change request. The essence of the latter is as follows: the necessary improvements to the CIS will be carried out outside the project within a separate time frame and budget.
Iterative model of information systems implementation
Let's try to eliminate the shortcoming of the one-pass model. To do this, each of the stages of the diagram in Fig. 3 we will add a feedback loop, thereby adding the possibility of returning to previous stages. If you carefully analyze the result obtained, it turns out that each of the stages can be performed several times. That is why the resulting model (Fig. 4) is called iterative. First used in the USA back in 1957, the multi-pass iterative model is based on the IID (Iterative and Incremental Development) concept, which includes the principles of iterativity (refining and detailing the software being developed step by step), incrementality (increasing the functionality of the software for each iteration) and evolutionary ( maximum use of the developments of previous iterations for subsequent ones) [4].
Fig.4. Transition from the cascade and iterative model of CIS implementation
Software development according to the IDD concept comes down to breaking the implementation stage into a series of fast, easy and adaptive iterations that quickly produce results. Each iteration is based on the Deming PDCA cycle (Plan-Do-Check-Act) and ends with a demonstration of the resulting intermediate product to the consumer in order to quickly identify potential errors. Moreover, as iterations progress, the view of the final product changes, so new functionality is added. The duration of each iteration varies from 1-6 weeks, and there may be no initial list of software requirements at all.
Let us note the advantages of the iterative model:
prompt development and demonstration of software to eliminate errors;
no software requirements are allowed,
as well as disadvantages:
lack of understanding of the scope of work to complete the project;
focus on development, but not software customization.
Let's consider the project for implementing the CIS according to the proposed model:
identification and analysis of requirements for CIS, as well as prioritization of found requirements (optional);
determining the number and duration of CIS development iterations, if there are prioritized requirements, their distribution among development iterations;
finalization and customization of the CIS, functional and integration testing, followed by demonstration of the resulting product to the customer to clarify the requirements (for all iterations);
conducting acceptance testing;
documentation of the implemented software solution;
transition to productive operation and support.
Performing iterations involves demonstrating the product to the customer, as a result of which defects are identified and new software requirements are identified. The first disadvantage of the multi-pass model is formulated quite simply: newly emerging requirements and wishes of the client may go beyond the time frame of the initially discussed iterations. Thus, a certain measure of requirements is needed to cut off unimportant ones, which, in principle, contradicts the very concept of IID.
The second disadvantage looks much more serious: previously it was exclusively about improving the CIS, but now it is not clear what to do with customization and integration. First, let's deal with customization. Levels of data and business processes are subject to configuration in the CIS: organizational structure, processes, master and variable data. It is impossible to configure, for example, a business process in a corporate information system, following the iterative principle. It makes the most sense to take an incremental approach: break the process into parts and configure one part of the business process in a given iteration, and the rest in the next. This approach is also applicable to organizational structure and data. As a result, a certain analogue of requirements is obtained: processes, organizational structure and data must be decomposed into objects and distributed over iterations. Next, you need to understand whether the resulting objects should be included in the initial or final iterations? The answer has to do with the issue of integration.
CIS integration can be divided into internal and external. Internal integration means the interaction of CIS objects and modules with each other, for example, the arrival of goods at a warehouse should generate accounting entries. In this example, there are two entities of different modules: receipt and posting, related to the functionality of procurement logistics and finance, respectively. The second type of integration involves the interaction of the CIS with external subsystems, for example, SRM, CRM, WMS, etc. If internal integration can be attributed to a greater extent to the customization of the CIS, then external integration can be attributed to customization and modification. No modification of the CIS can be carried out without the presence of basic system components, which are mainly installed through configuration. Thus, it is logical to include CIS customization and integration in the initial iterations, and only then refinement. Therefore, each iteration should include both functional unit and integration testing. Summarizing, the following picture of the implementation of iterations appears:
initial iterations should include system customization and internal integration on an incremental basis in order to prepare the fundamental core of the CIS;
subsequent iterations contain improvements to the CIS that use previously prepared CIS functions through customization.
Summarizing the above, the use of an iterative model is quite logical for finalizing the CIS, but setting it up will require additional manipulations. Despite the statistics [5], which states that about 70% of the functionality of foreign CIS requires improvement, while the multi-pass model is used quite rarely in Russia. Perhaps the reason lies in the fact that preference is given to maximizing the use of standard CIS functionality, that is, customization, versus its modification.
Literary source:
Gudkov E.A., Derevnina A.M., Katasonova N.S. Analysis of cascade, iterative and spiral models of implementation of corporate information systems // Corporate information systems. – 2018. – No. 1. – pp. 18-29. – URL: http://corpinfosys.ru/archive/issue-1/48-2018-1-models.
