Lecture
Effective processes of initiating a software project at least half determine its future success. Lack of attention to this particular phase of the project inevitably leads to significant problems in the planning, implementation and completion of the project.
Initiation consists of processes that facilitate the formal authorization of the start of a new project or project phase. Initiation processes are often performed outside the project and are associated with organizational, program, or portfolio processes. During the initiation process, the initial description of the content and resources that the organization plans to invest are clarified. At this stage, the project manager is also selected, if he has not yet been assigned, and the initial assumptions and limitations are documented. This information is entered into the project charter and, if approved, the project is officially authorized.
Project Charter [1] is a document issued by the project initiator or sponsor, which formally legitimizes the existence of the project and gives the project manager the authority to use organizational resources in project operations.
In Russian practice, this document is more often called the Project Concept. The concept (from lat. Conceptio - understanding, system), a certain way of understanding, interpreting any object, phenomenon, process, the main point of view on the subject, etc., is a guiding idea for their systematic coverage.
In a company that decides on the start of a software development project, there should be a unified system of criteria for assessing its significance. The system of criteria should allow choosing from the set of possible projects for realization the most priority ones for the company.
The priority of any project should be determined on the basis of an assessment of its three characteristics:
The scale for assessing the financial value of the project may look as follows:
For example. The financial value of software development projects, implementation or maintenance projects that are carried out in accordance with concluded commercial contracts can be assessed as high. A project to develop product functionality in line with market requirements, initiated by a product manager based on an analysis of marketing, consulting, sales and technical support offers, can get a higher-than-average financial value estimate, and technological process change projects or internal automation projects can have average financial value. .
Financial value alone is not enough to determine the priority of a project. For example, no software company will undertake to automate illegal drug trafficking if it does not fit its business strategy. Therefore, an important indicator of the priority of the project is its compliance with the strategic goals of the company.
The scale of assessment of the strategic value of the project may be as follows:
The third mandatory indicator of a project’s priority should be its risk assessment. No project that has even the highest rating of financial profitability will not be put into production if the achievement of this super-profit has minimal chances.
An approximate scale for assessing the risk level of a project may be as follows:
If a company pays little attention to managing the priorities of its projects, then this leads to an overabundance of ongoing projects, overworking performers, constant work-outs and overtime, and, consequently, to low production efficiency. When starting a new project with high priority, the company must stop or close less significant projects to provide the new project with the necessary resources, and not try to do everything at once due to the intensification of work, as a rule, this does not work.
Every project should have a concept. If the project is small, then a few paragraphs are often enough to present the concept. However, launching a project without a concept is the same as sending a ship to the sea without defining a destination for it.
The concept of the project is developed on the basis of the analysis of business needs. The main function of the document is the confirmation and coordination of a common vision of goals, objectives and results by all project participants. The concept determines what and why is being done in the project.
The project concept is the key document that is used to make decisions throughout the project, as well as during the acceptance phase, to confirm the result. It contains, as a rule, the following sections:
As an example, which will illustrate the theoretical presentation of the fundamentals of project management, let’s take a real-life software development project to automate one of the divisions of a large manufacturing company. Let's call it "Automated system for the sale of documentation."
Brief legend of the project. The customer of XYZ OJSC is one of the leading manufacturers of complex technical products. Department "123", part of JSC "XYZ", is responsible for the sale of additional supporting documentation for JSC clients.
Additional documentation is not included in the standard delivery, since the owner of this technical product does not always operate it himself, but puts it into operation by another company, which becomes a client of XYZ, and buys operational documentation from it. Repair and maintenance of a specific product can be performed by a third company, which already needs detailed technical documentation on repair and maintenance. She also becomes an XYZ customer and buys the required products from her.
The main function of the “123” department is to receive and process orders for additional documentation, according to the catalog sent annually. In connection with the relocation of the “123” department to the new building, the task was set to develop and supply a system that automates the main activity of the “123” department.
The text of the document Concept of the project, which will be cited as an example, we will highlight the background color.
Project goals should answer the question why this project is needed. The objectives of the project should describe the business needs and objectives that are solved as a result of project execution. Project goals can be:
Objectives should be significant (aimed at achieving the strategic goals of the Company), specific (specific to this project), measurable (ie, have verifiable quantitative estimates), real (achievable). A clear definition of business goals is important because it significantly affects all processes and decisions in a project. The project should be closed if it is recognized that the achievement of the goal is impossible or has become inappropriate. For example, if the real costs of the project will exceed the future revenues from its implementation.
Project results answer the question of what should be obtained after its completion. Project results should determine:
It should be remembered that the results of the project should be measurable. This means that when evaluating the results of a project, it should be possible to conclude that the results specified in the concept are achieved or not.
The relevant section of the document is the concept of a project for creating an “Automated System for the sale of documentation” as follows.
1.1. The aim of the project is to increase the efficiency of the main production activities of the “123” department.
1.2. Additional objectives of the project are:
1.2.1. Establishing long-term relationships with an important customer of XYZ OJSC.
1.2.2. Entry into a new promising market for modern B2C systems.
2.1. Reducing the cost of processing applications.
2.2. Reducing the processing time of applications.
2.3. Improving the efficiency of access to information on product availability.
2.4. Improving the efficiency of access to information about the passage of applications.
2.5. Improving the reliability and completeness of storing information about applications received and the results of their processing.
3.1. Application software and user documentation.
3.2. Basic software.
3.3. LAN equipment, workstations, servers and operating system software.
3.4. Pre-commissioning and commissioning.
3.5. Training users and system administrators.
3.6. Maintenance of the system at the stage of trial operation.
3.7. Transfer of the system to industrial operation.
4.1. Authorization and user authentication.
4.2. View the product catalog.
4.3. Search for products in the catalog.
4.4. Order selected products.
4.5. View order status information.
4.6. Informing the customer about changing the status of the order.
4.7. View and order processing by executors from the sales service.
4.8. View statistics on receipt and processing of orders for the period.
4.9. Preparation and maintenance of product catalog.
This section describes the initial assumptions and limitations. Assumptions are usually closely related to risk management, which we will discuss below. In software development, it is often necessary to formulate risks in the form of assumptions, thereby transferring it to the customer. For example, when evaluating a design and implementation project under a fixed-price scheme, we must write down the assumptions that the cost of licenses for third-party software will not change before the project is completed.
Restrictions, as a rule, reduce the ability of the project team to choose solutions. In particular, they may contain:
In this section, it is also appropriate to formulate those system requirements that can be expected by the customer by default, but are not included in the scope of this project. For example, a clause may be included in this section that the development of a software interface (API) for future integration with other customer systems is not part of the project’s objectives.
The content of this section for our sample project is as follows.
5.1. Application software engineering is performed using UML 1 .
5.2. Software development tool is Symantec Visual Cafe for Java 2 .
5.3. As an intermediate software for maintenance and support of the catalog, OO DB Poet 3 is used .
5.4. The load on the system should not be more than 100 concurrent users.
5.5. The scope of the project does not include:
5.5.1. Protecting the system from deliberate hacking.
5.5.2. Development of B2B API and integration with other systems.
One of the tasks of the project initiation phase is to identify and describe all of its participants. According to [1], project participants include all stakeholders (stakeholders), individuals and organizations, such as customers, sponsors, a performing organization, who are actively involved in a project or whose interests may be affected during the execution or completion of a project. Participants can also influence the project and its delivery results.
As a rule, key participants of a software project include:
The content of this section in the concept-example will have the form.
6.1. The project sponsor is V. Vasiliev, Director of the Information Department of XYZ OJSC.
6.2. Customer - Head of the Department "123" F. Fedotov
6.3. Automated system users:
6.4. Clients of OJSC "XYZ" (search and order documentation).
6.5. Management of JSC "XYZ" (analysis of the activities of the Department "123").
6.6. Employees of the production departments of JSC "XYZ" (catalog maintenance).
6.7. Employees of the Department "123" (processing applications and supplying documentation).
6.8. Employees of the Department of Informatization of JSC "XYZ" (system administration).
6.9. The curator of the project is the head of the custom development department I. Ivanov.
6.10. Project Manager - Leading Specialist of the Department of Custom Development of MP P.Petrov.
7.1. The supplier of equipment and operating system software is Alpha LLC.
7.2. The basic software provider is Beta LLC.
In order to understand how much the implementation of a software project will cost, it is necessary to identify and evaluate the resources necessary for its implementation:
The specifics of a software project is that human resources make a major contribution to its cost. All other costs are usually insignificant compared to these costs. We will talk in detail in the following lectures on how to approach the estimated labor costs for the implementation of a software development project. At the initiation phase, a labor cost estimate with an accuracy of -50% to + 100% is considered good [2].
Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом:
Рисунок 14.Распределение трудозатрат по основным производственным процессам при разработке ПО
Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы.
Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час. Исходя из эмпирической кривой Б. Боэма (Рисунок 15), численность команды, близкая к оптимальной, составила 10 человек, из них
8.1. Требования к персоналу
8.1.1. 1 — руководитель проекта,
8.1.2. 1 — технический лидер (архитектура, проектирование),
8.1.3. 1 — системный аналитик (требования, тест-дизайн, документирование),
8.1.4. 4 — программисты (с учетом работ по конфигурационному управлению),
8.1.5. 3 — тестировщика.
8.2. Материальные и другие ресурсы
8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий
8.2.2. 2 серверных комплекса (для разработки и тестирования):
8.2.3. Сервер приложений с установленным BEA Weblogic AS
8.2.4. Сервер оперативной БД с установленной Oracle RDBMS
8.2.5. Сервер каталога с установленной OODB "Poet"
8.3. Лицензии на средства разработки и тестирования:
8.3.1. Oracle Designer — 1 лицензия
8.3.2. Symantec Visual Cafe for Java — 5 лицензий.
8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия на клиент).
8.4. Расходная часть бюджета проекта 4
8.4.1. Разработка и сопровождение прикладного ПО:
8.4.1.1. 9000 чел.*час. * $40 = $360 000
8.4.2. Поставка оборудования и операционно-системного ПО:
8.4.2.1. 3 сервера * $10 000 = $30 000
8.4.3. Поставка базового ПО:
8.4.3.1. BEA Weblogic AS $20 000
8.4.3.2. Oracle RDBMS $20 000
Итого: $430 000
1 Проект стартовал в 2000 году, тема UML тогда была на слуху и даже оставались те, кто верил, что из модели на UML можно будет генерировать исходный код.
2 Таково было требование Заказчика, поскольку этот инструмент использовали его программисты, которым предполагалось передавать систему на сопровождение.
3 Еще один пример горячей темы и не оправдавшихся надежд — это объектно-ориентированные базы данных. У заказчика проекта уже были закуплены лицензии на эту базу данных и он очень хотел получить возврат от этих инвестиций. Поэтому ее использование в проекте стало одним из требований. К счастью, нам удалось быть достаточно убедительными и обосновать необходимость дополнительно использовать RDBMS Oracle для решения транзакционных задач. О том, к чему это привело, я подробно рассказал в своей книге: С. Архипенков, "Руководство командой разработчиков программного обеспечения. Прикладные мысли", Москва, 2008.
4 Мы в данном разделе оцениваем себестоимость проекта. Определение продажной цены проекта не входит в рамки данного курса.
Comments
To leave a comment
software project management
Terms: software project management