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

V Development of the schedule of design work

To accomplish a large and important work, two things are necessary:
clear plan and limited time.
Elbert hubbard

And here the customer and the performer shook hands, deciding what they will produce, determining the approximate dates and cost. The second stage of the software product production begins.

There comes a time when the project manager is actively drawn into the whirlpool of processes. No, he could have participated in events before. For example, associated with the assessment of labor intensity, timing, etc., but right now he gets the opportunity to fully show all his planning and management skills.

At the current step, the detailed requirements for the target system are not yet clear, they are just to be identified as part of the current activity, so planning is conveniently divided into parts. The schedule of work on 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 later on following the completion of the second stage.
')
The first thing the project manager should include in the plan is their own work. With the length of this route on the Gantt chart, it is unlikely that any other line can compete. Under it are located, interrupted in some places, the rut of employees of the design and analytical department.



Work on 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 a design solution is formed, and there will be a motive for assigning tasks to the design and implementation phase. Well, we'll talk more about this in our turn.


Figure 6. - Development of the project schedule

VI Formation of the design solution of the information system

Solving project problems often ends in a compromise: if you want advantages, pay for disadvantages. Without this, there is practically no.
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 go. Now it is necessary to design the software complex and the hardware that can support its normal operation, as well as to predetermine the resources for the implementation of the plan.

1. Clarification and specification of requirements

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

Gradually loom chains of business processes that need to be automated. According to them, system functions and data flows scurrying between components take shape.

The models of repositories are built, into which information will flow, logical connections are defined that reflect the mutual influence of real entities of the domain on each other.
Next, the behavior of the objects of the system is modeled, causing their reaction to various events occurring both in the system and outside it.

In detail with my recommendations for carrying out these works can be found in the publication Practice of formation of requirements in IT projects from A to Z. Part 3 - Part 6 .

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


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

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

In the meantime ...



Ideally, all design solutions should be communicated to the customer in an understandable and accessible form. And in response, he received agreement that he, as a result of production, expects to receive exactly the information system that corresponds to the parameters and functionality described in the documentation. But in practice this is quite difficult to achieve. The complexity of this is due to a number of reasons:

• The absence of a customer clear and precise understanding of what is described in the documentation;
• Fearing representatives of the customer, to assume responsibility for agreeing on a decision in which they doubt, while not seeing any other way of resolving problems;
• The likelihood of changes in requirements during the production of a product that could entail a significant, critical appreciation of the approved project estimates;

The team of contractors needs to be aware that the lack of coordination of the design solution with the customer places all financial risks on their shoulders to increase the resource intensity of the project. Let's take a closer look at what this may be connected with.

In agile methodologies (1), one of the most important principles says: “We accept changes to requirements, even in the later stages of project implementation” and “We no longer force the client to sign with blood, limiting it to strict and inconvenient contract terms”. In contrast to these principles, the “cruel” Waterfall model is usually immediately given, which provides for detailed design and detailed documentation of the solution, which is mandatory before the production of the information system begins. Let's discuss this point.

In my opinion, Scrum propagandists are obviously cunning. After all, the use of the Falls in its pure form has not been practiced for a long time. Probably since the disappeared storage media - punch cards. Nevertheless, modern modeling tools allow, without any particular complications, to completely redesign any solutions, and all kinds of platforms and frameworks, also effectively implement them into a finished product. That is, there are no particular difficulties in introducing changes in the product, even in the later stages of development in modern projects. The only question is who will pay for all these rebirths of an almost finished product? There may be two basic options:

1. The customer has an unlimited financial loan, and the total amount of the project, when planning product development, does not matter for him. And with each new change in a previously agreed decision, for example, he pulls out a thick checkbook and writes out a new check.
2. The customer, having entered into 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 bankrupt.

Perhaps I was terribly unlucky, but I did not meet the first course of events in my practice. Hostage of the second - was. The impressions were the most terrible, I do not advise anyone to face with such. I told about my experience of being in such situations in the publication of History - one project on “Trust”. Or how big the little ones get hurt .

I would reformulate the principles of Scrum to suit myself: “We are ready for changes in requirements, even in the later stages of project implementation, but this is likely to entail either significant financial costs for the customer or significant losses for the contractor.” Accordingly, a choice should be made:

1. to try at the design stage to develop the most appropriate model of the product being created and with a high degree of probability to meet the more or less predictable estimate;
2. try to design and search for solutions at your own risk already in the course of product realization, without understanding exactly what it can do for the terms and finances.

In the first case, the Customer may suffer, risking to obtain a product that does not fully meet its needs. In the second, all may suffer, mainly due to the difficulty of predicting the timing 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 receiving payment for the work performed and losing their reputation.

Another principle of flexible methodologies that I cannot agree with on 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, aren't they focused on the product? In fact, they model and document the product. And what to do when a system is built that consists of dozens of subsystems and modules developed by different teams at different times, and besides, interacting with third-party systems? How to reconcile all this interactive communication between various components? For example, variants of sequences of execution of chains of events and variants of response reactions to them? Is it possible to comment in the code written in different languages? And here we add the willingness to change the requirements at any stage, and what do we get? While your team implemented the interface of interaction of its module with another, the team of that other has already changed requirements and is not ready to interact with you in the old format now. What kind of format is now relevant, it’s hard to find out, because the team’s “concentration” on the product and the lack of documentation that no one reads, as Agile promotes. Looking ahead, for Agile connoisseurs I will clarify that this method, 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 have been developed, a technical description has been formed, a complete set of design stage artifacts has been assembled, it is possible to proceed to the formation of requirements specifications for transferring them to the implementation stage. What is it for?

In the technical documentation there is a lot of supporting information: diagrams, models, tables, etc., which were needed only at the design stage and will only developers and project managers in the process of working with the requirements. After all, 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 separated from the design process. At the analysis stage, a deeper formalization is performed, which allows us to approximate the requirements for the language of the programmer’s environment. A clearer structuring of requirements is also performed, providing a clear and unambiguous understanding of the design decision.

Thus, before transferring the requirements to the implementation phase, it is desirable to go through an additional step by converting the project documentation into the requirements specification — a structured set of descriptions of the target system, in terms of approximate developers. For example, database tables, procedures, forms, buttons, menus, input fields, etc. Such a set can then be easily converted into a set of related tasks, assembled into implementation steps, for transfer to production for programmers. The same set can serve as a basis for creating test cases, as well as other activities within the framework of quality management. In detail, I covered this topic in my article about the quality of requirements in IT projects, and frankness (from the standpoint 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, it is possible to split the process into parts and make 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 must be clarified, analyzed and structured;
3. Based on the information collected, system models, descriptions, algorithms and other design artifacts should be developed, in the amount and form adopted at the enterprise;
4. On the basis of the design decision, a technical assignment (TOR) must be formed, which must be agreed with the customer;
5. For effective work of the team embodying the requirements in the program code, according to the TOR, it is desirable to form requirements specifications for transferring them to the implementation stage of the software product.

Figure 9. - Artifacts generated by the design decision development stage