**3. Mini-cycles of iterations and the life cycle of project development**

Typical for any reasonable methodology, a cycle of project development with an iteratively repetitive sequence of overlapping stages of work, we present as follows (see **Figure 1**). Here and later, we use the notation of the life cycle diagrams proposed in [9]. In this notation, vertical

**Figure 1.** Life cycle of project iterative development.

• There is a lack of qualification of the employees of the first two groups for the implementation of the project, and as a result, it is necessary to search on the side of either the executors

• Simultaneous execution of several projects, because of which key and constantly working

• The need to recruit new constantly working developers, which can be met through well-

The style of work of the project manager of the unstable team assumes a permanent search of outside employees involved to perform autonomous tasks. It is necessary to distinguish tasks that involve obtaining the results needed for the development of the project environment and such tasks, the implementation of which should contribute to the success (in all senses) of project development. The latter may be loosely associated with the project, and decisions about their announcement made, for example, for checking the employee. In any case, the autonomous task should be precise and contain an awareness of when, for what, and how the results obtained would be used in the project. In accordance with the answers to these questions, the project manager should formulate regulations of work both for the performance of autonomous tasks and for products received from third-party developers. It should be noted that the autonomous task must be precise formulated. It should contain pointing of when, for what, and how the results obtained are used in the improvement of project activities. When the formulation of the task assumes repeatable using of its fulfillment results, in addition to the usual work acceptance, a special analysis is required *before* and *after* its setting and execution. The first is planning reusing, and the second is the decision of adaptation the result to the project environment evolution. Instability of the team most often leads to the fact that it is necessary to allocate resources to adapt the skills of employees to the requirements of the project. Primarily, this concerns constantly working developers who have proved themselves in the performance of assignments as potentially effective participants of the project. Do not neglect the need for training and optional developers involved. Even in cases when they have the skills and experience necessary for the project, the autonomy of their work does not promote the growth of their status to constantly working developer and even more so to a key developer. Activities aimed at, on the one hand, the study of the feature of the project being developed, and on the other hand, the acquisition of common skills and experience, needed to support the process of stabilizing the team. These activities must necessarily be provided for when the project developers seek to become a mature and stable team. At the same time, one cannot ignore that training, as a rule, is very expensive and therefore

of the tasks or for consultations, possibly for training.

168 Management of Information Systems

developers concentrate only on the most important projects.

established optional developers involved when they performed tasks.

• There is no need to hire employees for full working hours.

may not be profitable in the current project situation.

**3. Mini-cycles of iterations and the life cycle of project development**

Typical for any reasonable methodology, a cycle of project development with an iteratively repetitive sequence of overlapping stages of work, we present as follows (see **Figure 1**). Here and later, we use the notation of the life cycle diagrams proposed in [9]. In this notation, vertical columns provided with captions show the project phases. The inequality of columns height shows the possibility of overlapping phases: the joint performance of works on a common area of neighboring phases. The bold horizontal arrows present the lifetime of the project iterations. Breaks of arrows indicate that the use of the iteration results continues beyond the development cycle. Crossing the boundaries of phases with lifetime lines are control points and milestones of the project. The colored circles mark them. We display the lifetime of the first iteration with more details than of the second one since their structures are the same. The arrow from the end of the deployment phase of the first iteration leads to the next iteration, possibly with overlapping them. The images of iterations with a shift relative to each other reflect the character of the project development as an ongoing process, during which new tools offered to the user take into account the experience of applying the results of the already passed iterations.

For definiteness, we use the following general breakdown of the process of developing software systems into phases that corresponds to the generally accepted structure of projects (we will use this decomposition later in the discussion of the proposed methodology in Section 5):


This standard life cycle schema for the iterative development process is not entirely suitable for cases where optional developers involved perform some autonomous tasks. Each such task requires the organization of a special process, which we call a mini-cycle, nested in the main iteration of the project to complete the task. The mini-cycle is associated with the splitting of the main process into two branches, performed simultaneously: the continuation of the project and the identification of the task. Splitting can occur at any point in the life cycle of a project when key employees are aware of the need to solve an autonomous task and formulate it for an optional developer involved.

In a mini-cycle (see diagram in **Figure 2**), key developers identify the task for outsourcing, and optional developers involved carry it out. It is clear that for the correct statement of the task, its analysis is necessary, and at the end of the mini-cycle, key developers should make a decision about future using of obtaining results. The latter includes a decision about when the splitting should end, that is, the definition of the latest point in the lifetime line of the iteration, when the results obtained remain useful for the project. The diagram indicates this point as *F*.

Consider the performance of splitting and mini-cycle details as follows:


**Figure 2.** Splitting of the life cycle.

this appointment. In particular, the team can choose an optional developer involved. We are now discussing this case.

	- The required results do not match the expected from the optional developer's involved work. The diagram indicates this as **X**. Key developers in this situation must make a decision regarding the executor of the assignment. In particular, is it worth continuing cooperation with this optional developer involved.
	- The work done needs to be improved. The diagram indicates this as the arrow leading to point *B*. Key developers in this situation must repeat analysis to set updated task and, possibly, to provide assistance to the performer.
	- The results obtained can be used in the further development of the project beyond the current iteration. The diagram indicates this as cloud with "…" text. This situation requires a special evaluation of the developer's activity, on the one hand, and on the other hand, work on drawing up specifications for the product to use. At the same time, key developers should determine whether the interaction with the optional developer involved was productive and comfortable and give recommendations on how to continue cooperation in the future.
	- The results obtained satisfy the requirements, which are necessary for their use in the current iteration both in quality and in terms of execution time. The activity of key developers is the same as in the previous case.

From the suggested discussion of the mini-cycle of implementation of the task by the optional developer involved follows that the analytical work ceases to be a separate stage in the project development life cycle. It becomes a constantly performed production function of the project, the content of which at the beginning of the cycle is the formulation of tasks. When the task is completed, the content of this function (at the evaluation stage) is to prove the feasibility and appropriateness of using the results of the task in the project.
