Lecture
"If you can’t swallow an elephant entirely, then it should be cut into chops." Mankind has not yet invented anything more effective for solving a complex task than analysis and its decomposition into Bole simple subtasks, which, in turn, can be divided into even simpler subtasks and so on. It turns out a certain hierarchical structure, the tree at the root of which the project is located, and on the leaves there are elementary tasks or work that must be done to complete the project under the conditions of specified constraints. According to [1]:
Hierarchical Work Structure (WBS) (Work / Breakdown Structure, WBS) is a result-oriented hierarchical decomposition of work performed by a project team to achieve project goals and desired results. With its help, the entire content of the project is structured and determined. Each next level of hierarchy reflects a more detailed definition of project elements.
The basis for the development of the IMR is the project concept, which defines the project products and their main characteristics. JRI provides identification of all work required to achieve the objectives of the project. Many projects fail not because they do not have a plan, but because important projects are forgotten in this plan, such as testing and correcting errors, and project products, such as user documentation. Therefore, if the SRI is compiled correctly, then any work that is not included in it cannot be considered work on the project.
ISR divides the project into subprojects, work packages, subpackages. Each next level of decomposition provides a consistent detail of the content of the project, which allows for an assessment of the timing and amount of work. The SRI should include all intermediate and final products.
To decompose the project works can be different. For example, GOST 19.102-77 provides a cascade approach and defines the following stages of the development of a software system:
If you follow this standard, then on the first level of the ISR should be exactly these project products. If we had to develop an automated control system for controlling a nuclear reactor or a manned spacecraft, then that is exactly what should have been done. However, in commercial software development, this approach is not effective. As we have said, the modern process of developing commercial software should be incremental. This means that at the top level of the decomposition of our project should be the products of the project, and at the next level - the components of which these products consist. Components can then be decomposed into features — functions that they must implement.
Isolation of the components that make up the software product is an element of high-level design, which we must perform during the project planning phase, without waiting for all the functional requirements for the software being developed. Components can be both application subsystems, and infrastructure or nuclear, for example, logging, security subsystem, GUI component library.
When drawing up a basic work plan, you should not strive to maximally detail all the work. An SRI should not contain too many levels, 3-5 is enough. For example, the SRI of our sample project for the development of the “Automated System for the sale of documentation” might look like this (Figure 17).
1. The project of development of the “Automated system for the sale of documentation”
1.1. Preparation of technical specifications for automation
1.1.1.1. Conducting an analytical survey
1.1.1.2. Development of functional requirements
1.1.1.3. Development of basic software requirements
1.1.1.4. Development of requirements for hardware and operating system software
1.1.1.5. Approval and approval of TK
1.1.1.6. TK approved
1.2. Supply and installation of equipment
1.2.1. Development of equipment specifications 1.2.2. Purchase and supply of equipment
1.2.3. Installation of equipment
1.2.4. Installation and configuration of operating system software
1.2.5. Installation completed
1.3. Delivery and installation of basic software
1.3.1. Development of specifications for basic software 1.3.2. Purchase of basic software
1.3.3. Deploy and configure basic software
1.3.4. Basic software installed at customer
1.4. Application Software Development and Testing
1.4.1. Development of specifications for applied software
1.4.2. Install and configure the working environment
1.4.3. Software design and development
1.4.3.1. Authorization and user authentication.
1.4.3.2. Development of the documentation ordering subsystem
1.4.3.2.1. View the product catalog.
1.4.3.2.2. Search for products in the catalog.
1.4.3.2.3. Order selected products.
1.4.3.2.4. View order status information.
1.4.3.2.5. Informing the client about the change in the status of the order.
1.4.3.2.6. The documentation ordering subsystem has been transferred to test operation (on the developer’s servers).
1.4.3.3. Development of an order processing subsystem
1.4.3.3.1. View and order processing by executors from the sales service.
1.4.3.3.2. View statistics on receipt and processing of orders for the period.
1.4.3.3.3. The order processing subsystem has been transferred to test operation on the Customer’s equipment.
1.4.3.4. Development of the catalog maintenance subsystem 1.4.3.4.1. Preparation and maintenance of product catalog.
1.4.3.5. Error correction
1.4.4. Software Testing
1.4.4.1. Round 1
1.4.4.2. Round 2
1.4.4.3. Round 3
1.4.4.4. Output testing
1.4.5. Documenting Application Software
1.5. User training
1.5.1. Preparation of training courses 1.5.2. Training department employees 123 1.5.3. Training of the management of OJSC XYZ 1.5.4. Training of system administrators
1.6. Commissioning in trial operation
1.6.1. Deploying and Configuring Application Software
1.6.2. Acceptance tests
1.6.3. The act of transferring the system to trial operation has been approved
1.7. System maintenance during the trial operation
1.8. The system is transferred to commercial operation.
Figure 17. The hierarchical structure of the project activities of the “Automated system for the sale of documentation” project (project control points are in italics)
Personal responsibility for all parts of the project (subprojects and work packages) must be established. For each work package, the output result must be clearly defined. Work and project evaluations should be coordinated with the key team members, the executive company’s management and, if necessary, with the customer. As a result of the coordination, the team members assume the obligations to implement the project, and the management assumes the obligations to provide the project with the necessary resources.
The SRI is one of the main tools (means) in the project management mechanism, which is used to measure the degree of achievement of project results. Its most important function is to provide a consistent presentation of all of the project’s private owners regarding how the project will be done. In the future, the base plan will serve as a reference for comparing with the current project execution and identifying deviations for management purposes.
One of the common "diseases" of software projects is called "creeping ficherism." This is when a small shed for storing garden equipment and then a house of several floors for its owner are first attached to the originally designed booth for a beloved dog. And they are trying to build all this on the same foundation and from the same materials. This disease has caused many software development projects to be fatal.
Therefore, as soon as it was possible to stabilize and coordinate the SRI, it is necessary to develop a project content management plan. To do this:
The first task that needs to be solved when analyzing a change request is to identify the objects of change: requirements, architecture, data structures, source codes, test scripts, user documentation, etc. Then you need to design and describe in detail the changes in all identified objects. Finally, the costs of making changes, testing changes and regression testing of the product and their impact on the project timeline should be assessed.
This work, which will require the cost of working time and sometimes significant different specialists: analysts, designers, developers, testers, and finally, a project manager. Therefore, this work must necessarily be taken into account in the plan.
The organizational structure is a coordinated and approved distribution of the roles, responsibilities and goals of the activities of the key project participants. It must necessarily include a system of working relationships between project working groups, a reporting system, assessments of project progress and a decision-making system. It should be remembered that the organizational structure of the project is a “living” organism. It begins to take shape at the planning stage and should change as the project progresses.
And further. The instability of the organizational structure - the frequent change of executors - can become a serious problem in managing the project, since there is a replacement price, which is determined by the time the new participant enters the project context.
Configuration management is one of the important software production processes. Not one book has been written about this area of knowledge. We will only talk about the fact that this work should be planned.
The project plan should include work on ensuring a single repository of all project documentation and program code being developed, ensuring the safety and restoration of project information after a failure. Works on setting up workstations and servers used by members of the project team should also be included in the plan. In addition, the plan should contain the work required to organize the assembly of intermediate releases of the system, as well as its final version.
These jobs are usually performed by one person, a configuration engineer. If the project is small, then this role may be additional for one of the programmers. I once saw that this role was performed by the project manager. “Smearing” this work on all project participants is, firstly, ineffective. Installing and configuring a development environment, for example, databases and application servers, requires certain competencies and knowledge of the features of specific product versions. If these skills have to be mastered by all developers, then it will take too much working time. Secondly, “smearing” of work on configuration management can lead to collective irresponsibility, when no one knows what the project is not going to do and how to roll back to a consistent version.
Configuration management can become more complicated if the project team, in parallel with the development of new product functionality, has to maintain several releases of this product that were previously installed with different clients. All these works should be taken into account in the project plan.
Quality assurance is another of the basic areas of knowledge in software engineering. Regarding what is software quality and how to effectively provide it, you can argue for a very, very long time. In our course, we will limit ourselves to the statement that quality assurance is an important work that must be planned in advance and carried out throughout the entire software project, and not only during the acceptance tests.
When planning this work, it is necessary to understand that the product of the project should not have the highest possible quality that is unattainable in a finite time. The required quality of the product is determined by its requirements. And further. The main task of quality assurance is not the search for errors in the finished product (output control), but their prevention during the production process. For example, the smoothness of machining a part on a lathe can only accidentally meet the required quality of 1 micron, if the spindle in which the part is attached is poorly centered.
The quality management plan should include the following work:
In addition to these sections, the project plan should also include:
These questions will be discussed further in special lectures.
After determining the complexity of the work, it is necessary to determine the schedule for their implementation and the general terms of the project implementation - to schedule the project. The basic schedule is the approved schedule with the specified time phases of the project, control points and elements of the hierarchical structure of work.
The basic schedule can be most clearly represented by the Gantt chart. In this diagram, planned operations or elements of the work hierarchy are listed on the left side, dates are displayed on top, and the duration of operations is shown in horizontal bars from the start date to the completion date.
The basic schedule is, as a rule, an element of the contract with the customer. The control points (milestones) should serve as the points for analyzing the state of the project and making the decision “GO / NOT GO”, therefore they should visually demonstrate the status of the project. The “Design completed” checkpoint is bad. The most effective approach is the sequential delivery method: reference point “Completed testing of requirements 1, 3, 5, 7”
If the works are not related to each other, then we can begin and complete any of them when it is convenient for us. All work can be done in parallel, and in this case the minimum project duration is equal to the duration of the longest work. However, in practice, there are dependencies between jobs that can be “hard”, for example, analysis — design — coding — testing and documenting a particular function; or “non-rigid”, which may be revised or mitigated. For example, the sequential execution of tasks by a specific executor (can be rescheduled for another executor) or the development of basic software, which must precede the development of application software. In this case, you can create a "stub" emulating the work of the basic software. Thus, the Gantt chart for the project schedule looks like a hammock made up of a set of chains of interrelated works with a single point of beginning and end.
Critical path of the project (Critical path) - the longest chain of works in the project. The increase in the duration of any work in this chain leads to an increase in the duration of the entire project.
There is always at least one critical path in a project, but there may be several of them. The critical path may change during project execution. When executing a project, the manager should pay attention to the execution of tasks on the critical path in the first place and follow the emergence of other critical paths. Practical recommendation: on the critical path should work with non-rigid connections, which can always be rescheduled, if there is a threat of failure to meet deadlines.
To illustrate the notion of a critical path, consider an example of a “super-project” 5 . The concept of the project is as follows.
Objective of the project. Make breakfast in bed
Project results. Breakfast in a bed of boiled eggs, toast and orange juice.
Resources. There is one operator and the usual kitchen equipment.
Timing. The project begins in the kitchen at 8:00 and ends in the bedroom.
Acceptance criterion. The minimum labor resources and term are used. The final product is of high quality: the egg is freshly cooked, the toast is warm, the juice is cold.
Justification utility. The project serves to achieve strategic goals.
The hierarchical structure of the works, focused on the final product, with an assessment of their duration is presented in Figure 18.
Figure 18. The hierarchical structure of the "super-project"
In the next step, we must take into account the dependencies between the works, for example, you cannot fry bread until we cut it.
Given the dependencies, we get the following diagram of the schedule of our project (Figure 19)
Figure 19. Schedule diagram "superproject" taking into account the dependencies between the works.
As a result, we determined that the minimum duration of our project is 10 minutes. However, we cannot stop this, because we must also take into account the resource constraint. We have only one operator.If we look at the resource utilization chart (Figure 20), we will see that our critical resource is 400% loaded in the first minute. which is unacceptable.
Figure 20. Resource load diagram in the “super-project”
Therefore, we have to perform the alignment of resources. Since one of the criteria for the success of a project is its minimum duration, then if we do not want to increase it, we must identify a critical path in the project (Figure 21) and not shift the work that is on it.
Figure 21. The critical path in the “super project”
Therefore, after alignment of resources, the schedule of our project will look as follows (Figure 22).
Figure 22. Schedule "superproject" after the alignment of resources
Теперь диаграмма загруженности ресурсов (Рисунок 23) выглядит приемлемо и у оператора даже появилось три минуты свободного времени на перекур. При этом общая длительность реализации проекта по-прежнему составляет 10 минут.
Рисунок 23. Диаграмма загруженности ресурсов после выравнивания
На верхнем уровне ИСР должны находиться не процессы, а продукты проекта, на следующем уровне — компоненты из которых эти продукты состоят. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО.
Помимо работ, непосредственно направленных на создание программного обеспечения, в плане проекта должны быть предусмотрены необходимые ресурсы для обеспечения работ по следующим процессам:
В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей.
5 Интернет-источник идеи, к сожалению, восстановить не удалось.
Comments
To leave a comment
software project management
Terms: software project management