Organization of processes for the production of information systems. Part 2. Formation of a design solution

    V Development of a schedule of design work

    To do a great and important work, two things are necessary: ​​a
    clear plan and a limited time.
    Albert Hubbard
    And so the customer and the executor shook hands, deciding what they would produce, determining the approximate terms and cost. The second stage of production of the software product begins.

    The moment comes when the project manager is actively involved in the whirlpool of processes. No, he could participate in events before. For example, related to the assessment of labor input, determination of terms, etc., but right now he gets the opportunity to fully demonstrate all his mastery of planning and management.

    At the current step, the detailed requirements for the target system are not yet clear, they just have to be identified in the framework of the current activity, so planning is conveniently divided into parts. The timetable for the formation of the design solution of the developed system can already be worked out in detail, but the plan for its implementation and implementation can be detailed a bit later after the completion of the second stage.

    The first thing the project manager should include in the plan is his own work. Some other line can hardly compete with the length of this track in the Gantt chart. Under it are the tracks of employees of the design and analytical department, interrupted in some places.



    Work on drawing up a schedule while moving forward without much hassle. Competing processes and pending activities have not yet been observed. The main tangle of tracks will appear on the Gantt chart later, when the design decision is formed, and there will be a motive for setting tasks to the development and implementation stage. Well, we’ll talk more about this in our turn.


    Figure 6. - Development of a project schedule

    VI Formation of a design solution for an information system

    The solution of design problems often ends with a compromise: if you want to have advantages - pay with disadvantages. Almost without it.
    Konstantin Feoktistov.
    Let me remind you that at the first stage only the Product Concept was developed, a conceptual solution that determined the direction - where to move. Now it is necessary to design in detail the software package and the hardware that can support its normal functioning, as well as predetermine the resources for the implementation of the plan.

    1. Clarification and detailing of requirements


    The painstaking work begins on translating the chaos of information from the ordinary civil language into an ascetic and coherent syllable: models, diagrams, and template descriptions.

    Gradually looming chains of business processes that need to be automated. According to them, system functions and data streams flowing between components take shape.

    Models of storages are built, in which information will be flocked, logical connections are determined that reflect the mutual influence of real entities of the subject area on each other.
    Next, the behavior of system objects is modeled, causing their reaction to various events occurring both in the system itself and outside it.

    Details of my recommendations for carrying out these works can be found in the publicationThe practice of creating requirements in IT projects from A to Z. Part 3 - Part 6 .

    And now, when the data structure is clear, the user’s interaction with this data has been worked out, and the system’s response to these influences is known, you can come close to the external design of the product.


    Figure 7. - Preparation of technical specifications and other documentation for the production of an information system

    It is still necessary to describe the requirements for system security, reporting forms and other nuances, depending on the automated subject area.

    Meanwhile ...



    Ideally, all design decisions should be brought to the attention of the customer in an understandable and accessible way for him. And in response from him, approvals were received that he, as a result of production, expects to receive exactly the information system that corresponds to the parameters and functional capabilities described in the documentation. But in practice, achieving this is quite difficult. This complexity is caused by a number of reasons:

    • The customer’s lack of a clear and precise understanding of what is described in the documentation;
    • Fear of the customer’s representatives to take responsibility for agreeing on a solution in which they doubt, despite the fact that they don’t see any other way to solve problems;
    • The likelihood of changes in requirements during the production of a product that could entail a significant, critical rise in the cost of the approved project estimate;

    The team of performers must be aware that the lack of coordination of the design decision with the customer entrusts them with all the financial risks of increasing the resource consumption of the project. Let's take a closer look at what this may be related to.

    In agile methodologies (Agile) (1), one of the most important principles is: “We accept changes in requirements, even at the late stages of the project” and “We no longer force the customer to sign blood, limiting them to harsh and uncomfortable contract terms.” In contrast to these principles, the “cruel” Waterfall model is usually immediately brought in, which provides for detailed design and detailed documentation of the solution, which is mandatory before starting the production of an information system. Let's discuss this point.

    In my opinion, Scrum propagandists are clearly cunning. After all, no one has been practicing the use of the Waterfall in its pure form for a long time. Probably since the carriers of information - punched cards - disappeared. Nevertheless, modern modeling tools allow without any complications and quite effectively redesign any solutions, and all kinds of platforms and frameworks, also effectively implement them into a finished product. That is, there are no fundamental difficulties regarding the introduction of changes to the product, even in the late stages of development in modern projects. The only question is, who will pay for all these degenerations of an almost finished product? There are two possible basic options:

    1. The customer has an unlimited financial loan, and the total amount of the project, when planning product development, does not matter to him. And with each new change in the previously agreed decision, for example, he takes out a thick checkbook and writes out a new check.
    2. The customer, having concluded a contract for a certain amount, can sculpt the product by trial and error, trying to find the best solution for himself and forcing the performers to throw out and re-create modules and subsystems until he gets tired or the performer goes broke.

    Maybe I was terribly unlucky, but I did not meet the first scenario in my practice. He was a hostage of the second. The impressions were the most terrible, I do not advise anyone to encounter this. I told about my experience of being in similar situations in the publication History - one project on Trust. Or how big little ones offend .

    I would reformulate the principles of Scrum for myself like this: “We are ready for changes in requirements, even at the later stages of the project, but this is likely to entail either significant financial costs to the customer or significant losses to the contractor.” In accordance with this, you should make a choice:

    1. try at the design stage to develop the most suitable model of the product being created and with a high degree of probability meet the more or less predictable estimate;
    2. try at your own risk and risk to design and seek solutions already during the implementation of the product, not understanding exactly what it can cost in terms and finances.

    In the first case, the Customer may suffer, at the risk of receiving a product that does not fully satisfy his needs. In the second, everything may suffer, mainly because of the difficulty in predicting the time and cost required to create a product. The customer runs the risk of going beyond his financial capabilities, which will force him to freeze the development of the product, and the performers risk not getting paid for the work performed and losing their reputation.

    Another principle of flexible methodologies, which I can’t agree with regarding large-scale projects is: “We began to concentrate on the product, instead of writing sophisticated project documentation that no one reads.” Well, for small projects, let's say. Again, and those who document the product development process, are they not focused on the product? In fact, they model and document the product. And what to do when a system is built, consisting of dozens of subsystems and modules, developed by different teams at different times, and besides, interacting with third-party systems? How to coordinate all this interactive communication between various components? For example, variants of sequences of execution of chains of events and variants of responses to them? Really by the comments in the code, written in different languages? And we add here the willingness to change requirements at any stage, and what do we get? While your team was implementing the interface for the interaction of your module with another, the team of the other has already changed the requirements and is now not ready to interact with you in the old format. It’s hard to find out which format is now relevant because of the team’s “concentration” on the product and the lack of documentation, which Agile promotes no one reads anyway. Looking ahead, for Agile lovers, I’ll clarify that this technique, in my opinion, can also be effectively used in large projects, but a little later. the team of the other has already changed the requirements and is now not ready to interact with you in the old format. It’s hard to find out which format is now relevant because of the team’s “concentration” on the product and the lack of documentation, which Agile promotes no one reads anyway. Looking ahead, for Agile lovers, I’ll clarify that this technique, in my opinion, can also be effectively used in large projects, but a little later. the team of the other has already changed the requirements and is now not ready to interact with you in the old format. It’s hard to find out which format is now relevant because of the team’s “concentration” on the product and the lack of documentation, which Agile promotes no one reads anyway. Looking ahead, for Agile lovers, I’ll clarify that this technique, in my opinion, can also be effectively used in large projects, but a little later.

    2. Formation of requirements specifications


    When all models and schemes are developed, a technical description is generated, a complete set of artifacts of the design stage is assembled, you can proceed to the formation of requirements specifications for transferring them to the implementation stage. What is it for?

    The technical documentation contains a lot of supporting information: diagrams, models, tables, etc., which were needed only at the design stage and will only burden developers and project managers in the process of working with the requirements. Indeed, for the productive work of the development team, it is important for them to get a set of tasks, the consistent implementation of which will lead to the appearance of the target product.


    Figure 8. - Formation of requirements specification

    In the RUP (2) methodology, for example, the requirements analysis workflow is separate from the design process. At the stage of analysis, a deeper formalization is performed, which makes it possible to approximate the requirements for the language of the programmer environment. A clearer structuring of requirements is also provided, providing a clear and unambiguous understanding of the design decision.

    Thus, before transferring the requirements to the implementation stage, it is advisable to go through an additional step, converting the project documentation into specification of requirements - a structured set of descriptions of the target system, in terms close to the development environment. For example, database tables, procedures, forms, buttons, menus, input fields, etc. A similar set can then be easily converted into a set of related tasks collected in the implementation stages for transmission to the production of programmers. The same set can serve as the basis for creating test cases, as well as other activities in the framework of quality management. In detail, I disclosed this topic in my article On the quality of requirements in IT projects, honestly (from the position of the development team)

    And what does our countdown counter show? ...



    3. Section Summary


    Full-fledged design is one of the key factors that significantly affect the quality, timing and cost of implementing large information systems.

    1. All design work must be clearly planned. If there is not enough information for detailed planning, you can divide the process into parts and draw up a detailed schedule in stages;
    2. When forming a design solution, the concept of building a system developed at the first stage of production is taken as a basis. Information should be clarified, analyzed and structured;
    3. Based on the information collected, system models, descriptions, algorithms and other project artifacts should be developed, in the amount and form accepted at the enterprise;
    4. Based on the design decision, the Terms of Reference (TOR) should be formed, which must be agreed with the customer;
    5. For the effective work of the team embodying the requirements in program code, it is desirable to formulate requirements specifications for technical requirements for transferring them to the software product implementation stage.


    Figure 9. - Artifacts generated by the design solution development phase

    Content
    Часть 1. Отправная точка

    Часть 2. Формирование проектного решения

    Часть 3. Реализация проектного решения

    1. Уточнение и детализация плана-графика проекта
    2. Уточнение оценки затрат на производство информационной системы
    3. Процессы в итерациях по созданию программного продукта
    4. Подведение итогов итерации
    5. Передача финального релиза заказчику

    Часть 4. Внедрение информационной системы

    1. Развертывание системы на площадке опытной эксплуатации
    2. Обучение персонала заказчика работе с информационной системой
    3. Выявление недостатков и дефектов информационной системы
    4. Согласование изменений в процессе внедрения информационной системы
    5. Доработка информационной системы по итогам опытной эксплуатации
    6. Передача информационной системы в промышленную эксплуатацию


    Bibliography
    1. Вольфсон Борис- «Гибкие методологии разработки»
    2. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
    системы»

    Also popular now: