Preparatory stage of software development

If you do not know in which direction to develop the project, it is unlikely that he will choose the right path on his own.
Steve mcconnell

Introduction

In the previous article “Review of the software development process” [1] I talked about the very “top level” of the development process that has developed in my practice at the moment. In the introduction to the “Review” I tried to formulate the terms used and gave examples of some projects that used the process in question.

Today I will tell you how we conduct the preparatory stage of software development. The preparatory stage has two collective actors: the customer and the performer. Each side has its own interests and goals within the stage. Describing the preparatory stage, I will try to present both points of view, their interrelations and possible conflicts of interests.

The preparatory stage of the software development process has a very simple goal for the contractor - to decide whether to take on the implementation of a software product. From the point of view of the customer of the system, the goal of this stage is to decide whether the performer can be trusted. In case of successful development of events, the natural outcome of the preparatory stage should be the conclusion of a contract (or other agreement, as appropriate) on the creation or modification of the system required by the customer.
')
To achieve these goals, the customer and the contractor together need to solve a number of well-defined tasks:

1. On the basis of the initial idea, formulate the goals and objectives of the future project.
2. Develop some initial vision - the concept of the project.
3. To analyze the demand for the future product.
4. Conduct a preliminary risk assessment of the future project.
5. Based on the concept and list of preliminary risks, prepare a preliminary technical solution.
6. Select a development methodology and prepare a preliminary work plan.
7. Conduct a preliminary assessment of labor costs and required resources.
8. To analyze the feasibility of the product.
9. To conduct an independent review of the technical solution.
10. Decide whether to continue working.

I emphasize that we are not talking here about the requirements for the system being developed. Development of requirements can only be done when the contractor decides that the project is interesting to him, and the customer is ready to entrust the contractor with the implementation of the ordered system.

Background information is very scarce. Most often, this is just some idea that came to mind to the customer, your manager or someone from your team (maybe even you). Whether this idea turns into a real product is largely decided during the preparatory stage.

The diagram of activities at the preparatory stage of software development is presented in Figure 1. It looks a bit scary, especially in the context that funding for this stage does not always come at the expense of the customer. But sometimes almost all these tasks are solved by one experienced eye of the system architect, and after an hour and a half he is ready to give his reasonable estimates. And sometimes the preparatory stage may take several weeks, especially when the customer cannot articulate his idea in any way, and it is difficult to abandon the project for political reasons.


Figure 1. The activities of the project participants at the preliminary stage.

The nature of the project, of course, also contributes to the duration of the stage. If work is to be done on the order of state structures or a company with state participation, then most likely at the preparatory stage we will be talking about preparing for the tender. In this case, at all stages it is necessary to act with the maximum degree of formalization, which, of course, does not speed up the work. If a future project is made on the request of an internal customer, then more often, on the contrary, it is necessary to extinguish the ardor of overly impatient managers in order to enable the performers to give realistic estimates.

In my opinion, the most comfortable for the performers is to work on an investment product, where it is somewhat easier to keep a balance between the necessary process activities and design constraints.

It is important that you should solve all the tasks indicated here and not continue the project until you are sure that the time and budget spent on it will not be wasted and will bring tangible benefits. Whatever methodology you use when developing software, you must solve all the tasks of the preparatory stage. Practice shows that the choice of methodology for the development of a specific product should be made during the preparatory stage, and not before it. I know teams that abandoned the project as unrealizable just because they did not want to change their approach to development and refuse, for example, from scrum. The flexibility of the team in the choice of methodology is an essential factor in assessing the feasibility of the project.

Below, I will try to reveal the features of each of the tasks of the preparatory stage and tell how we solve them in practice.

Formulation of the goals and objectives of the future project

I am convinced that the formulation of the goals and objectives of the project is one of the most important stages of a software development project. Its importance lies in the fact that at this stage the customer of the software product acquaints the contractor with his idea, sets the direction for the development of the future project and defines the maximum permissible framework beyond which the project should not go. If the customer does not tell the performer about his idea in a form accessible to the performer, then the performer will not be able to do the work. If the customer incorrectly or incorrectly defines the goal of the future project, the contractor will not have a guideline for his activities and is unlikely to be able to carry out the customer’s intention. Even if the error is detected at later stages, changing the direction of the project’s development will be costly. Finally, the project’s maximum limits allow the customer and the contractor to prevent unacceptable losses in the event that the project is not implemented.

When formulating the project’s goals and objectives, a document should be created that answers the following questions:

1. How is the subject area determined for this project? What terms are used in the subject area? What business processes affected by the project take place in the subject area?
2. What is the purpose of the project? What effect should the developed system have on business processes of the subject area?
3. What tasks need to be solved to achieve the goal? By what criteria will the quality of the solution of the tasks be assessed? What are the functional and non-functional indicators of the quality of the developed system?
4. What are the limitations on the deadlines, resources, budget imposed on the project?

Answers to these questions should allow the performers to formulate the concept of the project and assess its relevance and feasibility. For the customer, the correctness of the answers to these questions is important, because this information sets the criteria by which the customer can decide whether to trust the work of one or another performer.

As a rule, the customer, as the carrier of the project idea, formulates the goal and objectives. But in my practice there was a case when we, the performers, had to perform this work. We had to tender for the development of one very specific system for a certain government service. Such projects have a peculiarity: the service “from above” is instructed to develop some system and accompany it, but the service itself, as a rule, is not a user of the system. Naturally, the leadership of the service takes the visor and announces a competition. But no one in the service itself knows for what purpose and how the developed product will be used. And worst of all, no one wants to know that. In such circumstances, the initial vision of the system at the customer (government service) is almost completely absent. The customer cannot formulate any goals or objectives of the project. We had to climb all the equipment of the customer, find the necessary technical documentation and reach the end users in various government departments. In the end, we successfully completed the project, made a profit, good experience and, importantly, the recommendations of the customer. However, such a situation, however, is an exception. The goals and objectives of the project should formulate exactly the carrier of the idea.

The goals and objectives for developing software for an external customer often come to the contractor when a competition is announced in the form of a document called “Technical Requirements”. It is important to understand, despite the name, that these are not yet system requirements, but, rather, a statement of the vision of the system through the eyes of the customer.

Why are the above questions important to solve at the very beginning?

Everything is simple with the subject area : the customer and the contractor will not be able to understand each other until the customer tells about the terms and business processes that are relevant to the work ahead. I highly recommend to be formal. Remember that a domain description is one of the simplest activities in a project, but it lays the foundation for a project. If the programmer misunderstands the business process of the customer, he can make an incorrect implementation of the function, and it will be impossible to establish the discrepancy until the customer starts using this function. But by that moment more than one layer of application code will have been written over the function, and correcting the error, which could have simply been avoided, would turn into a very expensive business.

The description of the subject area for orders of the same customer often wanders from the documentation of one tender to the documentation of another. This is due to the rules of paperwork. If work is carried out on projects of an internal customer or on investment software, sometimes the description of the subject area is displayed in a separate document. In one of the investment projects, we simultaneously worked on three versions of our product. One was on escort, the other was in development, and the third was entering the preparatory stage. Since this was our own project, we had the privilege to independently determine the goals of its development, based on the priorities of our development strategy. Since the team members changed from time to time, it was important that the description of the subject area was always available to everyone. And once the domain from version to version has changed slightly, we have highlighted its description in a separate document, common to all versions, and, if necessary, supplemented it.

The purpose of the project sets the direction of the project. It should briefly and clearly indicate the effect that the created or upgraded system will have on the customer's business processes. If the goal is not specified accurately, the project will develop in the wrong direction. It is very difficult to expand the project in another direction, and the more work is done within the project, the more difficult it will be to correct the direction of its development. Very soon the project will reach a state where it will be impossible to correct an error in setting a goal, and then you have to start everything all over again, or completely abandon the project.

In fact, it is extremely difficult to determine the exact direction for a project due to the considerable degree of uncertainty present at the very beginning of the project. Therefore, instead of a narrow vector in practice, a kind of “cone” with an axis coinciding with the intended vector of the project’s development is obtained. In the process of developing the project will deviate from a given direction, and the wider the cone of uncertainty of the target, the more the project will “hang out” in this cone. If the goal is not clear, then the project may deviate from the intended vector very far, and as a result, the developed system may not be applicable to solving the real tasks set for it.

To achieve the goal may require the work of not only one performer. For example, the creation of a system may require the development of special equipment or the revision of some third-party software. Therefore, the formulation of tasks that need to be performed by a specific executor in a project is also important, as is the formulation of a goal. The contractor must understand his role in the project, the limits of interaction with the customer and other performers and other nuances important for the project.

When setting tasks, special attention should be paid to the formulation of criteria according to which work will be accepted. System quality indicators can be set only by the customer, and they are important in assessing the feasibility of the project. The main indicators of quality, both functional and non-functional, should be indicated. For example, you should specify how many users can simultaneously work with the system, for what maximum time should the computed data be calculated, whether the user interface should be maintained in the corporate style of the customer, etc.

In some cases, the customer prescribes the procedure for acceptance of work, as well as the possibility of attracting an independent auditor.

Already at the stage of formulating goals and objectives, it is important to set the scope of the project , beyond which means that the project should be stopped. Constraints, together with the stated goal, reduce uncertainty and increase project controllability. In a negative scenario, the project will go beyond the delineated framework and will be stopped before too much time and money is spent on it. The definition of restrictions allows the customer and the contractor to protect their business from the consequences of a possible failure of the project.

The second positive side of the restrictions is that they allow you to explicitly set the boundaries of what the project will not do exactly. Such restrictions can significantly save developers time and save the future program from unnecessary, complex and useless functions that would otherwise have to be accompanied for a long time.

Constraints can be divided into three types: time constraints, budget constraints, and resource constraints.

Time limits at the stage of formulating goals should define two dates: the planned date and the deadline for putting the developed system into commercial operation.

Planned date provides a guide for developers. At the same time, it is necessary to remember the uncertainty of the project, which can both reduce the time spent on the project, and significantly increase it, with the latter being much more likely than the former. The target date should be updated as the project progresses.

The deadline for system commissioning is a red line that the project should under no circumstances pass. This period is used by the customer and the contractor to plan work in case the project fails. If the planned time exceeds this limit value, the project must be stopped.

Budget constraints also contain two values: the planned budget of the project, which is subject to constant monitoring and refinement, and the budget limit value, which the project should not exceed.

Restrictions on the resources used depend on the system being developed. In particular, it is necessary to limit the choice of hardware and software platform on which the program should work, mode of operation indicators, choice of technologies for developing documentation and program code. For custom software, requirements may be introduced to support the hardware virtualization environment, compatibility with anti-virus protection tools or other data protection tools, other restrictions that are significant for the customer. Where possible, the planned and maximum allowable limits should be determined.

Answers to all four questions should be recorded in the form of a document, entered into the version control system (this is especially true for the contractor who sets the task as a subcontractor) and made publicly available. Need to adhere to a reasonable level of formalism. If you are responsible for this work, do not spare time on formulating the project’s goals and objectives, and as the project progresses, constantly monitor whether the project is developing, whether the goal is clear enough, and whether the objectives are fully defined. Periodically review the goals and objectives, clarifying them and squeezing the cone of project uncertainty.

If you plan to develop a system for internal use, which will have a significant impact on your own business, you should treat it as an investment project with all rigor, including a high level of task formalization. The stability of your business will never exceed the stability of the system you use, and you will pay for every mistake in it.

In fact, you can abandon the formal approach in formulating a project goal in only one case. Only in one! This is a case of developing a small utility that solves minor tasks, the damage from the failures of which you will not be able to see amidst the average expenditure on office supplies and toilet paper.

Project concept development

Before you start the story about the creation of the concept of the system, let me tell you about one story.

Two years ago, one of the department’s teams, where I worked at the time, had to prepare for a tender to develop a very large and complex system for one of the leading transport companies in Russia. I was working on other projects at the time. However, after some quite a long time after the start of work, the project manager turned to me for help. The problem of the project was that none of the participants understood how the system should work. Perhaps this is the fault of the scale of the system and the lack of experience of the team to work with such complex projects. But the first thing I found when I started to dive into the subject was the complete lack of confidence in the team’s success. And the second is the lack of understanding how to take up the project at all. Despite the fact that more than a month had passed, the main question remained the same: what to ask the customer in order to at least get started?

There is nothing funny about it. Each specialist is most often an expert in his field. It also required a person who could absorb the entire gigantic amount of customer expectations and at the same time had enough experience in developing complex information systems to express the idea of ​​a customer in the form of a realistic solution. The larger the volume of the future system, the more skills and knowledge are required from the concept developer. If the team does not have such a specialist, the project is stalled. In our projects, the system architect is responsible for the development and further support of the concept. He is responsible for ensuring that the product is implemented in strict accordance with the concept. And I do not advise to involve developers, even experienced ones, to this position: very rarely the talent of writing quality code is combined with the ability to engage in dialogue with the customer, and even less often the programmer wants to obey the concept.

The big problem for us was that the customer defined the project goal in the most general terms, and the tasks, one might say, were not formulated by him at all. Everything that I mentioned in the previous section, we had to do ourselves, repeatedly meeting with representatives of the customer. But the mode, when the customer answers only specific questions - this is the worst mode of interaction between the performer and the customer. And now it depended on me what questions we would ask.

I had to invest all my experience in order to set the right priorities and formulate a list of the most important questions to the customer. Over the next few weeks, all the information flowed continuously to me, and I tried to systematize it, folding, like a puzzle, a complete picture of the customer's expectations and its possible embodiment.

And there was a day when we gathered in the negotiation team with the whole team. And I told you how I see the system being developed. I had to defend my vision by answering a large number of questions. But the more questions received answers, the more confidence the team became. They believed that they could make this huge system. They were free again and could creatively solve their complex tasks.

This is not the only example of how the concept has a vivid effect on project participants. And the same reaction is observed at the customer, especially when he himself does not understand how to embody his idea. Several schemes and a short presentation can sometimes completely melt the ice of distrust between the customer and the performer.

Concept is magic. If architecture is the skeleton of a project, then the concept is its spirit. There is no concept, and the project remains a breathless body, from which soon begins to stink. But when it is, the project develops, and the better the concept is implemented, the more healthy the project will be, and the more confident and successful the project team members will be.

But it is not enough to create a concept and coordinate it with the customer. It is necessary that the entire development of the software system be carried out in full accordance with the accepted concept. No one should be allowed to violate it. Yes, it can and should be corrected if there are serious reasons. But the reasons must be serious. And the decision must be made at the highest level and always be consistent with the customer.

Remember: if there is no concept - the project is dead. If some part of the project is not supported by the concept, this part of the project either dies or infects other parts of the project, and then the whole project dies. If there is a concept, but it is not fully respected, the project will continually slip and eventually go beyond the acceptable time frame and budget. If the team concept is different from the vision agreed with the customer, then you are not doing the system you were asked to do. Compromise in these statements, I have never seen.

If you are working on an investment project, then the concept of your product allows you to build a business development strategy. It allows you to find new customers for your product or service. No top manager in his right mind will dig into the code or system architecture. You will not acquire a single customer with stories about clean code or the development methodology used by your team. But if you show a colorful picture of your concept, everything starts moving in the right direction. Your product vision becomes the vision of your partners, consumers and even competitors. But this will only work when the concept is strictly adhered to when designing your system.

Breathe the spirit of the concept into your project, take care of its health and never lose it.

The project team is very rarely involved by the customer at the stage of formulating goals and objectives. More often, the performer receives the wording just before the contest itself, which does not allow much time for maneuvering. At the same time, as can be seen from the above example, the customer does not always show sufficient attention to the correctness of the wording of the goals and objectives of the project. Therefore, starting to develop a concept, the performer must, voluntarily or involuntarily, review the picture of the future product that the customer is trying to show. At least in order to meet with the expectations of the customer.

The purpose of the review is to check how well the wording is executed and, if possible, to clarify it. Most likely, if the goal and objectives are expressed as requirements for participation in the tender, the contractor will not be able to change the document itself. But you can try to enter into a dialogue with the customer, which will allow to clarify the direction of the project, to narrow the cone of uncertainty and to negotiate more specific restrictions. Moreover, it is almost always possible to better understand the subject area.

, , . -, . -, . , . , , . , . , . And nothing more.

, . , . .

, – . , -, , . : – , , , . .

, - , , , .

:

1. ? , / ? / ? , ? , ? : ?
2. ? ?
3. ? , ?
4. ? ? ?
5. ? ? ?
6. , : ?

, , , , . . , .

, – , . , -, , .

- , . , .

UML-, : , . . : , .

, , . – , , .

, «» , , - . , . . , – .

, . . , . .

, , , .

, ? , . , , , .

– . , , . , , , .

, , . , 2008- «», «» . , . : , . , , . . , , . .

, , . , , , « ». , , .

, , . , , , .

, , . , , , . , , .

, , , . , , , . , , , , .

. , , – . . .

. , , , . , .

, . , . – , .

, , . , . , .

In essence, when developing a technical solution, the performer must show, without going into details, that the adopted product concept is in principle realizable (not taking into account the limitations on time and budget). It is necessary to indicate on which technological basis it is possible (it is the possibility, not the requirement, that is emphasized) to implement this or that system functionality. It is also necessary to indicate how non-functional system quality indicators can be provided.

When preparing a solution, one should avoid the temptation to introduce into it a functional that is not directly related to the solution of problems formulated by the customer. This greatly inflates the project and causes a lot of questions to the customer. Of course, no one will interfere with the performer who decides to make a more or less useful additional function at his own expense. But the performer must have good reasons for such a step. In all other cases, you should follow the path of minimizing the time and budget costs while observing the product quality acceptable for the customer.

, . , 34.10/34.11-2001, , , . , . – . . .

, . . , , , . , , , .

, .

. , . , , , , , « agile » [2]. , , , , .

The purpose of the preliminary work plan is to provide an opportunity to estimate the labor costs, the composition of the project team, the necessary software and hardware for the development and testing environment, the timing of the involvement of specialists and resources.

The plan is based on the concept of the project, the technical solution and the chosen methodology. If several technical solutions are prepared, then a plan must be prepared for each solution separately.

The plan should be prepared by a specialist or a group of specialists who understand well the team’s activities at each stage of the development process within the framework of the methodology adopted for the project.

, , , , , , , , , , . , , . . , , , , . .

, , , .

, , «» . - . - agile, «» , , , [3]. , 4 , , - 0,55, 7,5 . , .

, - 0,7 , , . 0,6 , , . 0,55 .

It is convenient to express the duration and dependencies of tasks using the Gantt chart [4]. This will give an idea of ​​which tasks can or should be carried out in parallel (and, accordingly, they need different performers), and which - consistently. It will be possible to identify critical chains of tasks and try to optimize them. Also, this presentation will give the timeline to which to recruit staff or deploy / update / release project infrastructure components.

– . , , . 4-6 .

,

, . – , .

, , . , (50% ), (25%), , (10%) . 6 (30 ), 15 , – 7, – 3, – 30 . . 30 , , , - , . , , , .

, , , / , ..

. , , , , , . 100% 50% [5].

, . , , .

, , :

1. , ?
2. ?
3. ?
4. ?
5. , ?
6. ?
7. , ?

, . : , , , . . ? ? ? ? ? ?

, . , . . , , .

, . . . , ( , , , ). , , . , , . .

. , :

1. , ?
2. , ?
3. ?
4. , ?

. , IT-, . , . .

–

If the decision suits the customer, the customer and the contractor enter into an agreement to develop (or modify) the software product. The contractor receives a source of funding for work and can officially start the project. As a rule, the customer becomes more accessible to the contractor, and the development process moves to the requirements development stage.

The contractor must fix and place under the control of the versions the technical solution agreed with the customer, which, along with the concept, must be a publicly available document, which can only be changed for substantial reasons.
My experience says that you should not combine a concept and a preliminary technical solution. The concept is not intended for technical specialists, and the technical solution is focused on experts. In addition, as I indicated above, the concept may have several technical solutions. And at the subsequent stages of the development process it may happen that you will have to reconsider the technical solution within the framework of the current concept. No need to knock out from under a point of support, they are never superfluous.

A preliminary work plan, risk assessment, a list of outstanding issues should be brought under version control. At subsequent stages, these documents will be supplemented and refined.

Total

The preparatory stage of the software development process is important: it is at this stage that the idea of ​​a software product gets its first incarnation as a concept of a demand-based and implementable system.

It is imperative from the first steps to treat work with due responsibility. An error in formulating a goal or objectives can lead to a deliberately incorrect and highly unstable development of the project. Error in the formation of the concept and technical solution can make the system inapplicable in the customer's subject area. An error in the assessment of feasibility will result in a violation of the terms and budget of the project.

However, if both the customer and the contractor approached the project with due attention and laid a qualitative foundation, at the design stage of requirements, the project begins to quickly pick up the pace. The clear concept allows to reduce the cost of interaction with the customer, subcontractors and members of the project team. The achievements made by the executor at the preparatory stage greatly facilitate the work at the subsequent stages and, moreover, can be used in the future when working on the next versions of the product or on other projects.

Be attentive and responsible when laying the cornerstone of your project. You will be proud of him!

Bibliography

1. Maxim Kuznetsov. An overview of the software development process - habrahabr.ru, 2015 ( http://habrahabr.ru/post/255991/ ).
2. Maxim Kuznetsov. The use of agile in the development of a project for a state customer - megamozg.ru, 2015 ( http://megamozg.ru/post/14554/ ).
3. Vishal Prasad. Agile Forecasting with Focus Factor - scrumalliance.org, 2014 ( https://www.scrumalliance.org/community/articles/2014/july/agile-forecasting-with-focus-factor ).
4. Sergey Rogachev. Planning and tracking iterative development using Microsoft Project - agilerussia.ru, 2012 ( http://agilerussia.ru/practices/planning-ms-project/ ).
5. Steve McConnell. Stay alive. Guide for managers of software projects - SPb .: Peter, 2006.