Organization of information systems production processes. Part 3. Implementation of the project solution

VII Development of a plan for the implementation and implementation of the project solution

Brilliant plans lucky on the designers.
Bad plans lucky on performers.
Weslav Brudzinsky.

At this stage, the process begins again to revolve around the project manager. Again, the assessment of the complexity, the timing, the coordination of volumes, the approval of the execution procedure, etc.

Since we are talking about large projects, then with a high degree of probability for the implementation of a design solution, the entire process of producing an information system will be broken into separate components, services, modules, etc. Different teams may be involved in the implementation of these parts, including those using different technologies and tools. The production cycle of each part of the system is subject to certain rules and regulations. For example, it may depend on the readiness of other parts, on the results of certain routine maintenance, the purchase of equipment, etc. In order to save teams developing various components of the system from occasional downtime in idle waiting for the moment, when the queue finally reaches them, it is necessary to carefully plan the stages and processes of product production.

To solve these problems, a schedule is most often developed, which allows organizing and streamlining the interaction of teams and individual performers throughout the project.

1. Refinement and specification of the project schedule

If the requirements specifications are developed with sufficient detail and correspond to the recommendations indicated in the previous section, based on them, the project manager, together with the technical leaders of the development teams, can easily form a detailed project schedule with sufficient realism. Let me remind you that earlier we said that the specifications should be a description of the system in the form of an ordered, structured set of atomic tasks for implementing some functionality in the system. For an example, the contents of the requirements specification, see fig.10.
')

Figure 10. - Example requirements specification sections

As you can see in the picture, section headers are most suitable for using them in the project plan and setting tasks for developers in the tracker. By specification identifier (for example, [FR02.2]), the performer can easily find a detailed description of the requirement in the text.

Thus, the project manager gets the opportunity to split the entire pool of work into many manageable zones, each of which allows you to provide tasks for developers of different teams implementing their fragments, both in parallel and in sequence.

The project plan may look as shown in Figure 11. In this case, the task headers are simply copied from the requirements specification headers.


Figure 11. - Example of the project schedule

According to such detailed requirements, it is possible with high precision to plan the timing of the implementation of the entire product, as well as coordinate with all the performers the periods in which they undertake to meet the requirements, performing their segment of work.

It is convenient to include milestones in the project plan - significant intermediate results by which it will be possible to assess at a certain point the state of both the project itself and its product. Milestones make it possible to outline events when it is time to “touch with your hands” something real that can be used somehow, albeit with disabilities, but already something. For example, milestones may be designated releases of the product being created, with a pre-planned functionality. And the requirements for this functionality itself can serve as a criterion for assessing the success of passing a stage and achieving a result. It is the combination of documentation in the form of requirements and intermediate releases that satisfy these requirements, which allows a business to feel the volume of work produced. After all, how not cool, but in fact, the new release is an intangible asset that in the literal sense of the word neither touch, nor look to the business is not possible. But to contemplate the results of its operation and to compare them with the documented counterparts in the requirements is quite realistic.

Naturally, in large projects that implement very complex requirements, with the involvement of a large number of performers, something can go wrong, overlays and failures in meeting deadlines are inevitable. To combat such risks, the project manager, together with the teams, lay a lag in the plan for connecting additional resources to eliminate possible problems, as well as work out measures to level them. This will allow, in which case, the project team of the project executives will not fall into the financial hole, using extra-standard resources, and not expose the success of the entire project.

The plan is sure to add work on testing components or releases. It lays time to correct possible errors and redesign, with possible modifications. Planned activity on the deployment of the working environment on the test stands and other activities that ensure the quality of the product. Most often, these works are estimated as a percentage of the total labor costs of the development process, taking into account the coefficients, depending on the complexity of the project.

Further, the plan adds work on the deployment and configuration of stands with the developed software and hardware, allowing to organize trial operation at the customer sites.

Following are added work on the implementation of the system, including user training. It is worth mentioning that user training in large projects is a very expensive article, and it is extremely important at the early stages to think about how to minimize it. For example, to unify the work of different user groups, to reduce the number of actions performed by the user due to the robotization of processes, etc.

All these activities must be laid out in the plan, so as not to miss them in the assessment of costs and ensure full funding of the project.


Figure 12. - Formation of the plan - the project schedule

2. Refinement of the cost estimate for the production of an information system

According to the detailed plan-schedule of the project, when the full list of works is available, their scope and performers are determined, you can pretty accurately calculate their cost.

In the case of a fixed amount for the production of a software product in the contract, this possibility leaves a loophole to adjust the work in the direction of reducing them, if the production cost covers the amount of the contract. For example, slightly change the implementation, simplifying it, imperceptibly narrowing the functionality of the system, etc.

In the case, if the contract is concluded with the possibility of phased implementation, then you can prepare and enter into additional agreements that stipulate: the scope of work, the timing of their implementation and the amount of remuneration for their successful implementation.


Figure 13. - Assessment of compliance of the project plan with the contract

3. Section Summary

The planning and evaluation stage of the implementation of the project solution includes the following activities:

1. Based on the requirements specification, a project schedule is developed;
2. Based on the schedule of the project, the necessary resources are estimated for the implementation and implementation of the project solution;
3. Based on the assessment, an additional contract is concluded (additional agreement) for the implementation of the selected project solution.

Figure 14. - Artifacts generated by the third stage of production of a software product

So far and so, and half the time has already flown by, and in time it is already beginning to strain about this ...

VIII Implementation of the information system

It’s not the one who came up with the battle plan that wins the battle, but the one who took responsibility for its execution.
Napoleon

When the plan schedule is established and agreed with all interested parties, you can proceed directly to implement it.

There are many methodologies that describe and regulate the process of creating software products. We will not be limited to adherence to any one method, but we will use different approaches. Although the process described in the previous stages is more to the RUP (2) methodology, with the exception of refusing to build Use Cases, to the rank of messiah in the design process.

Most modern software development techniques suggest an iterative approach.

Iterative approach (eng. Iteration - “repetition”) in software development is the performance of work in parallel with the continuous analysis of the results obtained and the adjustment of previous stages of work. The project with this approach in each phase of development passes the recurring PDCA cycle: Planning - Implementation - Verification - Evaluation (eng. Plan-do-check-act cycle).

That is, each iteration covers a whole set of workflows, the execution of which is repeated cyclically, time after time, in each subsequent iteration. At the same time, in each cycle only selected, limited functionality of the target product is developed. Thus, with each successful iteration, the functionality of the product (semi-finished product) is increased, gradually pulling it towards the target.

1. Processes in software development iterations

The starting phase of the iteration begins with the selection of tasks that need to be implemented in the process of its implementation. Naturally, coordinated with the schedule of the project. Moreover, the casting of tasks should be carried out in such a way that, as a result of their execution, a noticeable increment of functionality can be obtained, which can be assessed in an intermediate release of the product. In most methodologies, at this stage, practice meetings are conducted, aimed at discussing the composition of the work of the iteration and the problems associated with their implementation. And also, importantly, to maintain team spirit, harmony and teamwork of the team. In the Scrum methodology (1), for example, it is recommended to hold Scrum meetings every day.

In the next phase, these tasks are transferred to the development. That is, developers are set tasks for the implementation of the above functional.

Since we have already divided the product into modules, contours, subsystems, etc., a separate unit in the form of a development team (some monolithic lump in the overall project team) is responsible for developing each of them, most of the interaction problems in this process have been resolved. Rather transposed on their shoulders. But let's touch on the organization of the effective work of the development team. In my opinion, some of the principles of Agile (1) in this case are the best fit:

1. Successful projects are built by motivated people. Give them a suitable environment, provide everything you need and trust them to do their work;
2. The most effective method of interaction and information exchange is a personal conversation;
3. Flexible processes contribute to continuous development. All project participants should be able to withstand such a constant pace;
4. Constant attention to technical excellence and high-quality architecture promotes flexibility;
5. Simplicity is needed as the art of maximizing work that should not be done;
6. The team is constantly looking for ways to become more efficient by customizing and adapting their processes.

Yes, and the general scheme of work of the Scrum team fits perfectly into the format of work organization we are discussing at this stage of the project.

In parallel, the quality service can prepare tests covering the functionality approved for implementation in the current iteration. At the completion of the main development phase, this will enable us to move quickly to the next phase - detection of implementation defects and, if they are opened, pass on their description to developers for correction.

After correcting the errors and confirming this fact by the quality service, an intermediate release of the product appears.


Figure 15. - Performing the main body of the software development iteration

2. Summing up the iteration

The iteration should end with an assessment of its implementation, in terms of the quality of both the intermediate product received and the process of its creation itself. Remember, at the stage of the formation of the project schedule, we laid milestones corresponding to the releases being released? Accordingly, each successful iteration must end with a prototype of the target product, with limited functionality. Success can be assessed by the criteria for compliance with the characteristics of the release described in the ToR. It is desirable that representatives of the customer participate in the assessment. For example, potential users of the developed functionality.

Based on the results of the evaluation of each iteration, it may be necessary to make changes to the project schedule, and possibly to the requirements.


Figure 16. - Summary of software development iterations

As mentioned above, the processes themselves performed in the iteration are subject to analysis. Difficulties of communication, miscalculations in the organization of technical process, in interaction of performers, etc. are revealed. Based on the analysis, adjustments are made to the organization of the processes in the iteration, data about this is entered into the knowledge system of the enterprise. Changes, for example, can be made to the document - “Configuration Management Plan” of the project, recommended in the RUP methodology (2).

Further, the iteration processes are repeated rhythmically. And it is important that this monotony does not hit the beat of the whole process. In this case, the inexorable counter reads well ...

3. Transfer of the final release to the customer

As a result of a certain number of repetitions, an official version of the software appears, which can be transferred to the customer to evaluate it in terms of meeting the needs of the business.

The customer, together with the contractor’s specialists, analyzes the result obtained for compliance with the parameters stated in the contract. According to the results of the assessment, shortcomings, inconveniences of implementation, deviations from the agreed requirements, etc., are recorded. At the end of the stage you may need to make changes to the requirements and the schedule of the project.


Figure 17. - Transfer of the official release to the customer

This stage is very interesting and has different solutions.

In the Scrum (1) methodology, for example, more frequent team meetings with the customer and frequent, continuous deliveries of the product are promoted. But in large and complex projects that integrate many components developed by different teams, fixed in different branches of the project, the assembly of which requires the merging of these branches, etc. - this practice is very time consuming. It is desirable to strive for this, but the possibilities for this are likely to be limited in large-scale projects. In addition, customer employees in large enterprises with a florid organizational structure and complex business processes are hardly ready to constantly spend time on additional meetings and discussions. Another factor not favorable to the use of this approach is associated with the presence in the team of complex, large projects - a separate role of an analyst (or architect), who actually interacts with the customer, obtaining and refining information in the most convenient, agreed time. And yet, it is the architect who makes the decisions and takes responsibility for them, and accordingly the team’s role is significantly reduced. In addition, teams often act as subcontractors and do not have access to the customer at all. Therefore, the collective influence on the decision made in large projects at the stage of active product development is much weaker than that advocated by the Scrum team for the methodology.

Total, 5 more days off.

4. Section Summary

The project implementation stage has the following features:

1. The implementation of a design solution in large projects occurs most often iteratively. The following processes are carried out cyclically: Planning - Implementation - Verification - Evaluation;
2. Each iteration ends with a release release, which itself is a prototype of the target product with limited functionality. With each successful iteration, the functionality is increased, approaching the target (specified in the contract);
3. According to the results of each iteration, an analysis of its success should be performed, with an assessment of both the product itself and the process of its implementation. It is desirable that the evaluation of the product iteration is done, together with representatives of the customer.

Figure 18. - Artifacts generated by the implementation phase of the software product