Кто не делится найденным, подобен свету в дупле секвойи (древняя индейская пословица)
Версия для печати
Библиографическая запись:
Information systems design concept: software lifecycle, models and stages of the lifecycle, software lifecycle processes. — Текст : электронный // Myfilology.ru – информационный филологический ресурс : [сайт]. – URL: https://myfilology.ru//165/informaczionnye-sistemy-i-texnologii/information-systems-design-concept-software-lifecycle-models-and-stages-of-the-lifecycle-software-lifecycle-processes/ (дата обращения: 27.04.2024)
Information systems design concept: software lifecycle, models and stages of the lifecycle, software lifecycle processes
Содержание
Information systems design concept
The methodology of designing information systems describes the process of creating and maintaining systems in the form of a life cycle (LC) of an IC, presenting it as a sequence of stages and processes performed on them. For each stage, the composition and sequence of the work performed, the results obtained, the methods and means necessary to perform the work, the roles and responsibilities of the participants, etc. are determined. Such a formal description of the LC IP allows you to plan and organize the process of collective development and ensure the management of this process.
Software lifecycle
The life cycle of an IP can be represented as a series of events that occur with the system in the process of its creation and use.
The life cycle model reflects the various states of the system, starting from the moment of the need for this IP and ending with the moment of its complete disuse. A life cycle model is a structure containing processes, actions and tasks that are carried out during the development, operation and maintenance of a software product throughout the life of the system, from the definition of requirements to the completion of its use.
Software life cycle models and stages
Currently , the following life cycle models are known and used:
- The cascade model provides for the sequential execution of all stages of the project in a strictly fixed order. The transition to the next stage means the complete completion of the work at the previous stage.
- A step-by-step model with intermediate control. Development IC is conducted in iterations with feedback loops between stages. Inter-stage adjustments allow us to take into account the actual mutual influence of development results at various stages; the lifetime of each of the stages stretches over the entire development period.
- Spiral model. At each turn of the spiral, the next version of the product is created, the requirements of the project are clarified, its quality is determined and the work of the next turn is planned. Special attention is paid to the initial stages of development — analysis and design, where the feasibility of certain technical solutions is checked and justified through prototyping (prototyping).
In practice, two main life cycle models have become the most widespread:
cascade model (typical for the period 1970-1985);
spiral model (typical for the period after 1986)
Cascade model
In the early projects of fairly simple ICS, each application was a single, functionally and informationally independent unit. The cascade method proved to be effective for developing this type of application. Each stage was completed after full completion and documentation of all the work provided.
The following positive aspects of the cascade approach can be identified:
at each stage, a complete set of project documentation is formed that meets the criteria of completeness and consistency;
the stages of work performed in a logical sequence allow you to plan the completion dates of all work and the corresponding costs.
The cascade approach has proven itself well in the construction of relatively simple ICS, when at the very beginning of development it is possible to formulate all the requirements for the system accurately and completely. The main disadvantage of this approach is that the real process of creating a system never fully fits into such a rigid scheme, there is a constant need to return to previous stages and clarify or revise previously made decisions. As a result, the actual process of creating an IP turns out to correspond to a step-by-step model with intermediate control.
However, this scheme does not allow for the rapid consideration of emerging changes and clarifications of the requirements for the system. Coordination of the development results with users is carried out only at the points planned after the completion of each stage of work, and the general requirements for the IP are fixed in the form of a technical specification for the entire time of its creation. Thus, users often get a system that does not meet their real needs.
Despite the persistent recommendations of vendor companies and experts in the field of IP design and development, many companies continue to use the cascade model instead of any variant of the iterative model. The main reasons why the cascade model retains its popularity are the following:
1. Habit — many IT specialists were educated at a time when only the cascade model was studied, so it is still used by them today.
2. The illusion of reducing the risks of project participants (customer and contractor).
The cascade model involves the development of finished products at each stage: technical specifications, technical design, software product and user documentation. The developed documentation allows not only to determine the requirements for the product of the next stage, but also to determine the responsibilities of the parties, the scope of work and deadlines, while the final assessment of the timing and cost of the project is made at the initial stages, after the completion of the survey. It is obvious that if the requirements for the information system change during the implementation of the project, and the quality of the documents turns out to be low (the requirements are incomplete and/or contradictory), then in reality the use of the cascade model creates only the illusion of certainty and in fact increases the risks, reducing only the responsibility of the project participants. With a formal approach, the project manager implements only those requirements that are contained in the specification, relies on the document, and not on the real needs of the business.
Spiral model
The spiral LC model was proposed to overcome these problems. At the stages of analysis and design, the feasibility of technical solutions and the degree of satisfaction of the customer's needs are checked by creating prototypes. Each turn of the spiral corresponds to the creation of a workable fragment or version of the system. This allows you to clarify the requirements, goals and characteristics of the project, determine the quality of development, plan the work of the next spiral. In this way, the details of the project are deepened and consistently specified, and as a result, a reasonable option is chosen that meets the actual requirements of the customer and is brought to implementation.
Iterative development reflects the objectively existing spiral cycle of creating complex systems. It allows you to move on to the next stage without waiting for the complete completion of work on the current one and solve the main task — to show the system users a workable product as soon as possible, thereby activating the process of clarifying and supplementing requirements.
The main problem of the spiral cycle is determining the moment of transition to the next stage. To solve it, time limits are introduced for each of the stages of the life cycle, and the transition is carried out in accordance with the plan, even if not all the planned work is completed. Planning is based on statistical data obtained in previous projects and personal experience of developers.
Stages of LC
1 Formation of the concept - Needs analysis, selection of the concept and design solutions
2 Development -Design of the system
3 Implementation -Manufacturing of the system
4 Operation -Commissioning and use of the system
5 Support -Ensuring the functioning of the system
6 Decommissioning - Termination of use, dismantling, archiving of the system
Software lifecycle processes
Each of the stages of the system creation provides for the performance of a certain amount of work, which are presented in the form of processes G11. The process is defined as a set of interrelated actions that transform input data into output. The description of each process includes a list of tasks to be solved, initial data and results.
There are a number of standards that regulate software utilities, and in some cases, development processes.
IBM made a significant contribution to the theory of design and development of information systems by proposing the BSP methodology (Business System Planning - organizational planning methodology) back in the mid—1970s. The method of structuring information using matrices of intersection of business processes, functional divisions, functions of data processing systems (information systems), information objects, documents and databases, proposed in BSP, is used today not only in IT projects, but also projects for reengineering business processes, changing the organizational structure. The most important steps of the BSP process, their sequence (to get the support of senior management, to define the processes of the enterprise, to define data classes, to conduct interviews, to process and organize interview data) can be found in almost all formal methods, as well as in projects implemented in practice.
In accordance with the basic international standard ISO/IEC 12207, all LC software processes are divided into three groups:
1. Basic processes
acquisition;
shipment;
development;
exploitation;
escort.
2. Auxiliary processes:
documentation;
configuration management;
quality assurance;
problem resolution;
audit;
certification;
joint assessment;
verification.
3. Organizational processes:
creating infrastructure;
management;
training;
improvement.
According to the ISO/IEC 15288 series standard [2.5] the following process groups should be included in the LC structure:
1. Contractual processes.
acquisition (internal solutions or solutions of an external supplier);
delivery (internal solutions or solutions of an external supplier).
2. Enterprise processes.
enterprise environmental management;
investment management;
management of housing and communal services;
resource management;
quality management.
3. Project processes:
project planning;
project evaluation;
project control;
risk management;
configuration management;
information flow management;
decision-making.
4. Technical processes:
definition of requirements;
requirements analysis;
architecture development;
integration;
integration;
verification;
transition;
certification.
12.09.2022, 331 просмотр.