Руководство программным проектом это

Соседние файлы в папке Лекции

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

From Wikipedia, the free encyclopedia

Software project management is the process of planning and leading software projects.^[1] It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

History[edit]

In the 1970s and 1980s, the software industry grew very quickly, as computer companies quickly recognized the relatively low cost of software production compared to hardware production and circuitry. To manage new development efforts, companies applied the established project management methods, but project schedules slipped during test runs, especially when confusion occurred in the gray zone between the user specifications and the delivered software. To be able to avoid these problems, software project management methods focused on matching user requirements to delivered products, in a method known now as the waterfall model.

As the industry has matured, analysis of software project management failures has shown that the following are the most common causes:^[2][3][4]

1. Insufficient end-user involvement
2. Poor communication among customers, developers, users and project managers
3. Unrealistic or unarticulated project goals
4. Inaccurate estimates of needed resources
5. Badly defined or incomplete system requirements and specifications
6. Poor reporting of the project’s status
7. Poorly managed risks
8. Use of immature technology
9. Inability to handle the project’s complexity
10. Sloppy development practices
11. Stakeholder politics (e.g. absence of executive support, or politics between the customer and end-users)
12. Commercial pressures

The first five items in the list above show the difficulties articulating the needs of the client in such a way that proper resources can deliver the proper project goals. Specific software project management tools are useful and often necessary, but the true art in software project management is applying the correct method and then using tools to support the method. Without a method, tools are worthless. Since the 1960s, several proprietary software project management methods have been developed by software manufacturers for their own use, while computer consulting firms have also developed similar methods for their clients. Today software project management methods are still evolving, but the current trend leads away from the waterfall model to a more cyclic project delivery model that imitates a software development process.

Software development process[edit]

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:

• Interpersonal communication and conflict management and resolution. Active, frequent and honest communication is the most important factor in increasing the likelihood of project success and mitigating problematic projects. The development team should seek end-user involvement and encourage user input in the development process. Not having users involved can lead to misinterpretation of requirements, insensitivity to changing customer needs, and unrealistic expectations on the part of the client. Software developers, users, project managers, customers and project sponsors need to communicate regularly and frequently. The information gained from these discussions allows the project team to analyze the strengths, weaknesses, opportunities and threats (SWOT) and to act on that information to benefit from opportunities and to minimize threats. Even bad news may be good if it is communicated relatively early, because problems can be mitigated if they are not discovered too late. For example, casual conversation with users, team members, and other stakeholders may often surface potential problems sooner than formal meetings. All communications need to be intellectually honest and authentic, and regular, frequent, high quality criticism of development work is necessary, as long as it is provided in a calm, respectful, constructive, non-accusatory, non-angry fashion. Frequent casual communications between developers and end-users, and between project managers and clients, are necessary to keep the project relevant, useful and effective for the end-users, and within the bounds of what can be completed. Effective interpersonal communication and conflict management and resolution are the key to software project management. No methodology or process improvement strategy can overcome serious problems in communication or mismanagement of interpersonal conflict. Moreover, outcomes associated with such methodologies and process improvement strategies are enhanced with better communication. The communication must focus on whether the team understands the project charter and whether the team is making progress towards that goal. End-users, software developers and project managers must frequently ask the elementary, simple questions that help identify problems before they fester into near-disasters. While end-user participation, effective communication and teamwork are not sufficient, they are necessary to ensure a good outcome, and their absence will almost surely lead to a bad outcome.^[3][4][5]
• Risk management is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost-benefit analysis as well as a list of fallback options for project failure, called a contingency plan.
  • A subset of risk management is Opportunity Management, which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact. Though theoretically handled in the same way, using the term «opportunity» rather than the somewhat negative term «risk» helps to keep a team focused on possible positive outcomes of any given risk register in their projects, such as spin-off projects, windfalls, and free extra resources.
• Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system^[1] Requirements management, which includes Requirements analysis, is an important part of the software engineering process; whereby business analysts or software developers identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.
• Change management is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to scope (project management) and then controlling changes and communicating to relevant stakeholders. Change impact analysis of new or altered scope, which includes Requirements analysis at the change level, is an important part of the software engineering process; whereby business analysts or software developers identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include risk-benefit analysis before approval.
• Software configuration management is the process of identifying, and documenting the scope itself, which is the software product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include version control, naming convention (programming), and software archival agreements.
• Release management is the process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before releasing to users, there will often be more environments for testing, called unit testing, system testing, or integration testing, before release to User acceptance testing (UAT).
  • A subset of release management that is gaining attention is Data Management, as obviously the users can only test based on data that they know, and «real» data is only in the software environment called «production». In order to test their work, programmers must therefore also often create «dummy data» or «data stubs». Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule.
• Maintenance and update is the process where Requirements and customer needs are always involving. They will undoubtedly find bugs, may request new features and ask for different functionality and more updates. So, all of these requests need to check and fulfill the customer’s requirements and satisfaction.

Project planning, execution, monitoring and control[edit]

The purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion. The project execution is the process of completing the tasks defined in the project plan.

The purpose of project monitoring and control is to keep the team and management up to date on the project’s progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, change control is used to keep the products up to date.

Issue[edit]

In computing, the term «issue» is a unit of work to accomplish an improvement in a system.^{[citation needed]} An issue could be a bug, a requested feature, task, missing documentation, and so forth.

For example, OpenOffice.org used to call their modified version of Bugzilla IssueZilla. As of September 2010, they call their system Issue Tracker.^{[needs update]}

Severity levels[edit]

Issues are often categorized in terms of severity levels. Different companies have different definitions of severities, but some of the most common ones are:

High

The bug or issue affects a crucial part of a system, and must be fixed in order for it to resume normal operation.

Medium

The bug or issue affects a minor part of a system, but has some impact on its operation. This severity level is assigned when a non-central requirement of a system is affected.

Low / Fixed

The bug or issue affects a minor part of a system, and has very little impact on its operation. This severity level is assigned when a non-central requirement of a system (and with lower importance) is affected.

Trivial (cosmetic, aesthetic)

The system works correctly, but the appearance does not match the expected one. For example: wrong colors, too much or too little spacing between contents, incorrect font sizes, typos, etc. This is the lowest severity issue.

Issue management[edit]

In many software companies,^[which?] issues are often investigated by quality assurance analysts when they verify a system for correctness, and then assigned to the developer(s) that are responsible for resolving them. They can also be assigned by system users during the User Acceptance Testing (UAT) phase.

Issues are communicated using Issue or Defect Tracking Systems. In some other cases,^{[example needed]} emails or instant messengers are used.

Philosophy[edit]

As a subdiscipline of project management, some regard the management of software development akin to the management of manufacturing, which can be performed by someone with management skills, but no programming skills. John C. Reynolds rebuts this view, and argues that software development is entirely design work, and compares a manager who cannot program to the managing editor of a newspaper who cannot write.^[6]

References[edit]

General

• 16326:2019(E) — ISO/IEC/IEEE International Standard — Systems and software engineering — Life cycle processes — Project management. 2019. doi:10.1109/IEEESTD.2019.8932690. ISBN 978-1-5044-6299-0.
• 1058-1998 — IEEE Standard for Software Project Management Plans. 1998. doi:10.1109/IEEESTD.1998.88822. ISBN 978-0-7381-1448-4.
• Jalote, Pankaj (2002). Software project management in practice. Addison-Wesley. ISBN 0-201-73721-3.
• Murali Chemuturi, Thomas M. Cagley Jr. & (2010). Software Project Management: Best Practices, Tools and Techniques. J.Ross Publishing. ISBN 978-1-60427-034-1.

External links[edit]

• Media related to Software project management at Wikimedia Commons

Project failure[edit]

• Robert Frese (2003-12-16). «PROJECT SUCCESS AND FAILURE: WHAT IS SUCCESS, WHAT IS FAILURE, AND HOW CAN YOU IMPROVE YOUR ODDS FOR SUCCESS?». University of Missouri-St. Louis. Retrieved 2015-05-13.

Управление программными проектами: процессы, инструменты, методики

Существуют разные представления о том, как ведётся творческая работа. Для многих людей творец – это личность (поэт, художник, изобретатель), которая создаёт своё творение в момент озарения. Управлять озарением? О, нет! Это невозможно!

Тем не менее, задача управления творчеством во все времена была актуальна. Инвесторам, менеджерам, государству хотелось бы иметь предсказуемость на счёт того, когда будет выпущен разрабатываемый творческий продукт (будь это книга, самолёт, компьютерная программа или кинофильм).

Творческая работа может вестись как индивидуально (одним творцом – учёным, художником, композитором или поэтом), так и коллективно (когда над созданием произведения работают коллективы людей разных специальностей). В данной статье мне бы хотелось сконцентрироваться на вопросах управления творческими коллективами на примере распределённого коллектива программистов, художников и дизайнеров из трёх стран, который выпускает приложение, продаваемое во всём мире. Каждый год продаётся более 10 миллионов экземпляров. Годовая выручка – 1 миллиард долларов.

Предположим, мы захотели открыть ресторан. По каким критериям Клиент будет оценивать его? Конечно, это кухня, дизайн и обслуживание. Обычно, наибольшее количество «глюков» происходит в процессе обслуживания, т.е. там, где велик человеческий фактор. Красивенькая молоденькая официантка вроде бы привлекает Клиентов. Но у неё испортилось настроение, и вместо доброжелательного отношения, она начинает хамить. В результате, вместо привлечения происходит отваживание Клиентов. В индустрии разработки ПО такое просто недопустимо. Необходимо, чтобы специалисты разных специальностей взаимодействовали друг с другом, а барьеры в коммуникациях и всякие субъективные вещи сводились бы к нулю. Поэтому при работе в большой интернациональной команде неформальные связи между людьми заменяются формализованными бизнес-процессами, а вместо субъективных оценок (хороший, прикольный, клёвый) используются метрики и показатели качества.

В больших проектах выгоднее купить нужного специалиста на рынке, даже если его зарплата кажется чрезмерной. При съёмках кинофильма, продюсер не учит своего сценариста писать диалоги, если тот не умеет этого делать, а просто покупает сценариста для написания диалогов на рынке. Аналогичным образом поступают при разработке приложений. Если возникает недопонимание между командами из разных стран, то одну команду отправляют в длительную командировку. При миллиардной выручке затраты на командировку не имеют значения: главное – выпустить продукт в срок.

Параметры управления

Процесс управления реальным проектом всегда основан на контроле группы параметров. Это только в школе приучают мыслить функцией от одной переменной. К сожалению, некоторые руководители перенимают школьные привычки и пытаются найти универсальное средство от управленческих проблем – этакую таблетку от всех болезней.

Пример. В одной компании, занимающейся разработкой мобильных игр, было принято выписывать задачу на карточку и помещать эту карточку на доску. Доска была разлинована несколькими вертикальными полосами. Каждая полоса соответствовала определённому состоянию задачи. Новые задачи помещались в крайне левую полосу. Затем – по мере выполнения – постепенно перемещались вправо. Главным критерием успеха руководство считало перемещение карточки на доске слева направо. Один из недостатков такого подхода – это отсутствие учёта того, что работа над задачей может быть приостановлена по ряду причин, а исполнитель может временно переключиться на другую задачу. Другой недостаток – это количество задач, над которыми ведётся работа. В нашем проекте в течение 1-го месяца нужно было выполнить 200 задач. Понятно, что разместить на доске такое количество карточек было физически невозможно.

Приведу список параметров, которые должен контролировать менеджер проекта:

1. Сроки.
2. Объём (количество полезных функций).
3. Объём работы.
4. Полезность (ценность для Потребителя).
5. Техническая и технологическая сложность.
6. Внешнее качество (с точки зрения Потребителя).
7. Внутреннее качество (с точки зрения специалиста, инженера, конструктора).
8. Риски.
9. Психологическое состояние команды.

Процессы управления

Для контроля параметров используются процессы, каждый из которых сводится к определённому набору инструментов и процедур их применения. Перечислим некоторые из процессов, которые будут рассмотрены ниже:

1. Управление задачами.
2. Управление сроками.
3. Управление качеством.
4. Управление рисками.

Управление задачами

Назначение

Оценка объёма работы и распределение задач между сотрудниками.

Система контроля задач

Цели

1. Оценить и зафиксировать объём работы.

Примечание. Сотрудники не должны выдумывать себе занятия, а заниматься задачами из заранее утверждённого списка.

Пример. На одной работе у меня был начальник, который на вопрос «К какому сроку нужно выполнить эту задачу?» — всегда давал одинаковый ответ: «Вчера». Позднее, став начальником, я убедился в том, что с программистами происходит зеркальная ситуация. Спросишь кого-нибудь: «Когда ты закончишь эту работу?» — и получаешь ответ: «Завтра к обеду. В худшем случае – к вечеру». Но проходит день, другой, а задача всё ещё не сделана. Чтобы как можно реже попадать в подобные ситуации и нужен инструмент, который подсказывает регулярно оставшийся объём работы.

2. Распределить задачи между работниками. Убедиться, что у каждого работника имеется задача, и ни один из них не простаивает.

Примечание: По данным министра экономического развития России (21.05.2012 – 24.06.2013) Андрея Белоусова производительность труда в нашей стране в 2-3 раз ниже, чем в развитых странах в зависимости от методики подсчёта (http://www.forbes.ru/kompanii/245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompanii).

Пример. Если вы когда-нибудь наблюдали, как происходит починка аварии на теплотрассе, то наверняка замечали, что копает яму один рабочий, а вокруг него 10 человек стоят и смотрят, как он работает.

Следует также убедиться, что сотрудники не пренебрегают одними задачами в ущерб другим.

Пример. В одном из петербургских гипермаркетов продавцы отдела сантехники предпочитают находиться рядом с итальянскими унитазами и гидромассажными ваннами, потому что премия за продажу дорогого сантехнического оборудования получается выше. Как результат, если Покупатель хочет приобрести муфту или обжим, то ему не с кем проконсультироваться. Вот так продавцы выполняют одни задачи и игнорируют другие. Получается, что сотрудники сами себе ставят или выбирают задачи, которые «вкуснее».

3. Найти зависимости между различными задачами.

Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Задача обязательно должна быть согласована с задачами других сотрудников, всего проекта или его части. Потому что, продолжая пример с рабочим, может оказаться так, что рабочий выкопал яму, получил деньги, все 10 «начальников» отчитались, а на другой день пришёл приказ яму срочно закопать, потому что именно по этой дороге поедет, например, президент. Об этом знали давно, просто «забыли» предупредить. А те, кто «копал», как обычно не уточнили параметры своей задачи… Или рабочий вырыл яму, а надо было оказывается рыть чуть шире или чуть глубже… Т.е. задача, может, и актуальна, но, при этом, не согласована или не точна.

4. Определить, какие задачи заблокированы по тем или иным причинам.

Пример. По стандартам газеты «Коммерсант» одно время материалы журналистов, рисунки художников и фотографии фотокорреспондентов нужно было сдать к 6-ти часам вечера. В редакции также присутствует специальный человек – рерайтер, задача которого заключается в том, чтобы привести все тексты под единую стилистику.

Описание

Система контроля задач может быть представлена в виде электронной таблицы.

Таблица 1. Список задач для мобильной навигационной системы GPS

Название	Статус	Ответственный	Область	Остаточная трудоемкость (часы)
Добавить экран поиска перекрёстков	Новая	Иванов И.И.	Поиск адреса	24
Добавить парикмахерские в базу данных для карты России	Выполняется	Петров П.П.	Поиск мест	8
Добавить новые стили оформления карты	Завершена	Сидоров С.С.	Карта	0
Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге	Заблокирована	Дмитриев Д.Д.	Построение маршрута	12

Параметры

Название описывает в краткой форме суть вносимых изменений. В идеальном случае оно должно содержать проверяемый критерий, по которому можно судить о том, выполнена задача или нет.

Примеры:

• Добавить экран поиска перекрёстков. (Примечание: Проверяемый критерий – экран. Он либо есть, либо его нет.)
• Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге. (Примечание: Проверяемый критерий – построение маршрута через кольцевую дорогу.)

Название задачи может включать в себя и название области программы (подсистемы), к которой относится задача. Это помогает при беглом взгляде на задачу понять, какому специалисту её следует поручить.

Примеры:

• База данных – Поиск мест – Добавить парикмахерские в базу данных для России. (Примечание: Задача относится сразу к двум областям: с технической точки зрения – к базе данных, потому что в неё надо внести изменения; с пользовательской точки зрения – к поиску мест, потому что в этом разделе навигационной системы можно проверить вносимое изменение.)
• Интерфейс – Карты – Добавить новые стили оформления карт. (Примечание: Эту задачу тоже можно отнести сразу к двум разделам навигационной системы: к интерфейсу пользователя, где можно выбирать стиль оформления карт, и к подсистеме визуализации карты.)

Подсистему можно указывать не только в названии задачи, но и в отдельной графе. Это позволит «подбить статистику» и оценить объём работы, относящийся к той или иной части программы.

Если различные подсистемы программы предъявляют разные требования к квалификации, знаниям и опыту работников, то такая статистика позволяет оценить потребность в соответствующих специалистах.

Для визуального представления статистики лучше всего подходит круговая диаграмма:

Рисунок 1. Объём работы над мобильной навигационной системой GPS

Статус задачи позволяет определить, какие задачи уже выполнены, какие – выполняются, и над какими задачами работа ещё не начиналась. Рекомендуется завести специальный статус, который сигнализирует о том, что задача заблокирована. Если работник устанавливает такой статус, то это означает, что выполнение задачи невозможно по тем или иным причинам.

Пример. Задача «Заменить иконки» не может быть выполнена, если художник не успел эти иконки нарисовать.

Остаточная трудоёмкость содержит актуальную оценку задачи – сколько времени ещё осталось до завершении задачи. Она даётся исполнителем в конце каждого рабочего дня. Таким образом, задача регулярно переоценивается. Это позволяет следить за прогрессом и вовремя предпринять определённые меры, если команда не поспевает к заданному сроку.

Использование

Первоначально задачи вносятся в систему контроля задач на этапе планирования проекта. Основная трудность заключается в том, что достаточно сложно предусмотреть все задачи и точно оценить время, которое займёт их выполнение.

Работу над проектом рекомендуется вести итеративно – двухнедельными или недельными итерациями. (Итеративность помогает быстро сделать некоторый законченный кусок работы и оперативно получить обратную связь.) В начале каждой итерации выполняется детальное планирование, в результате которого осуществляется выбор задач на итерацию. Если необходимо, то задачи детализируются, а их формулировки и оценки – уточняются.

ПО

Для управления задачами можно использовать готовые бесплатные или недорогие системы контроля задач:

• Электронные таблицы Excel или Google Docs
• Redmine – http://www.redmine.org
• Jira – https://www.atlassian.com/software/jira
• BugZilla — http://www.bugzilla.org
• DropTask – http://www.droptask.com
• Hansoft – http://www.hansoft.com

Сложная, «навороченная» и дорогая система управления проектом может быть заменена симбиозом Redmine и Excel.

Управление сроками

Назначение

Оценка и контроль сроков реализации проекта.

Диаграмма сгорания задач

Цели

Позволяет:

1. Оценить текущий остаточный объём работы.

Пример. Наиболее распространённый подход к управлению сроками – это контроль на глазок: «Мол, успеешь выполнить задачу к пятнице?» В наиболее яркой форме я столкнулся с таким подходом в одной российско-немецкой компании. В первый мой рабочий день владелец-немец подошёл ко мне и спросил: «У меня день рождения через три месяца. Успеете ли выпустить игру к моему дню рождения?»

2. Определить величину отставания от плана.

3. Оценить прогресс каждого сотрудника и всей команды.

Примечание. В этом случае будет семейство диаграмм.

Диаграмма

Рисунок 2. Прогресс работы сотрудника (реальный и прогнозируемый)

Описание

Для создания кривой строится вспомогательная таблица, в которой в первой графе перечисляются имена сотрудников, а в остальных графах содержится остаточный объём работы сотрудника в часах на конкретную дату.

Вместо одной цифры указываются две – сколько осталось времени реально и сколько должно было остаться по плану.

Таблица 2. Прогресс работы сотрудников

Ф.И.О.	31.08.14	01.09.14	02.09.14	03.09.14	04.09.14	05.09.14
Иванов И.И.	Реально	38	32	28	20	14	8
План	38	30	22	14	6	0
Петров П.П.	Реально	40	32	26	18	11	0
План	40	32	24	16	8	0

Примечание (Антон Яковлев, программист): Описан подход, очевидно, удобный в случае использования Excel. С другими системами подход может быть другой – Hansoft такие диаграммы может генерировать самостоятельно.

Параметры

Диаграмма представляет собой две кривые. Одна из них (нарисованная пунктиром) показывает запланированное уменьшение объёма работы, т.е. то, как должно быть. Вторая кривая (нарисованная сплошной линией) представляет собой реальное изменение объёма работы. Каждая точка на этих кривых – это запланированный либо реальный объём работы, который остался на конец дня.

Использование

Кривые строятся как для каждого работника индивидуально, так и для всей команды в целом.

В конце каждого рабочего дня данные – объём оставшейся работы в часах – заносятся в таблицу. Данные берутся из графы «Остаточная трудоёмкость» таблицы задач.

Причины увеличения сроков задач анализируются и впоследствии заносятся в специальную базу знаний компании.

Управление качеством

Назначение

Обеспечение надлежащего качества продукта.

Пример. В 2013 году в России количество разводов составило 54,5% от числа зарегистрированных браков (http://womanadvice.ru/statistika-razvodov-v-rossii). Такое количество «браков» в индустрии разработки ПО просто недопустимо. Не смотря на то, что государство является заинтересованной стороной, в том, чтобы количество разводов уменьшалось, причины столь печальной статистики государством не собираются и не анализируются. А вот при разработке ПО это делается.

Крупные корпорации планируют качество продукта до начала разработки. Они не только прогнозируют количество дефектов, которое будет найдено в процессе работы над проектом, но и количество дефектов, которое так и не будет исправлено.

Пример. В одном из проектов было найдено 30 тысяч (!) дефектов. Из них 15% так и не было исправлено. Не смотря на то, что это некритические или очень редко встречающиеся ошибки, тем не менее, можно сказать, что приложение было выпущено с 4 500 ошибками.

Прогноз количества дефектов

Цели

1. Оценить сложность проекта.
2. Оценить ресурсы, необходимые на доводку качества.

Описание

Если приложение выпускается на регулярной основе (например, каждый год – новая версия), то прогноз разумно основывать на исторических данных. Его можно представить в виде таблицы, в которой приводится статистика по предыдущим версиям и прогнозные показатели для новой версии.

Таблица 3. Прогноз количества дефектов для мобильной навигационной системы GPS

Область	2013 год (реальность)	2014 год (прогноз)
Пользовательский интерфейс	243	250
Построение маршрута	113	100
Поиск адреса	53	50
Поиск мест	17	20
Карта	194	200
Навигация	89	100
Аудио	67	50
Итого	776	770

Параметры

В графе «Область» перечисляются подсистемы программы. Они могут быть получены путём логического деления по разным основаниям. Иногда программа делится на части с точки зрения пользователя (как в приведённой таблице). В других случаях используются технические критерии.

В среднем столбце приводятся реальные исторические данные – количество дефектов, которое было найдено в различных частях программы в предыдущей версии программы.

В последнем столбце указываются прогнозные данные – сколько дефектов будет найдено в той или иной части программы при разработке её следующей версии.

Использование

При старте проекта отдел контроля качества создаёт прогноз по багам. Во внимание принимаются исторические данные, прогнозируемый объём работы, сложность требований к новой версии приложения, а также опытность самой команды.

Прогноз даётся с разбивкой по подсистемам. Для увеличения точности используются две разные модели. Первая модель предусматривает дробление программы на подсистемы на основании различных технических критериев.

Например:

• Пользовательский интерфейс
• База данных
• Аудио
• Алгоритмы

Вторая модель предусматривает деление программы на подсистемы по пользовательским функциям.

Например:

• Рисование карты
• Построение маршрута
• Навигация
• Поиск адреса

Разные модели прогноза дополняют и проверяют друг друга.

Прогноз количества дефектов – не простая формальность, а серьёзный инструмент для планирования работы. Он помогает определить количество инженеров по качеству, которое собираются привлечь на проект. Прогноз также позволяет подсчитать время, необходимое для стабилизации программы.

Прогноз количества дефектов – достаточно консервативный инструмент. Менеджмент пересматривает его очень неохотно, потому что любой его пересмотр в сторону снижения может привести к тому, что трудновоспроизводимые ошибки не будут искаться. Предполагается, что в отсутствии надлежащего эталона, инженеры по качеству просто расслабятся и будут выполнять свою работу хуже, чем могли бы это делать.

Пример. В одном из проектов реальное количество дефектов было ниже прогнозируемого значения. Согласно статистике, инженеры по качеству не справлялись со своей работой, т.к. находили меньше ошибок, чем вытекало из прогноза. Не смотря на то, что отсутствие значительного числа дефектов было объективно обусловлено небольшим количеством реализованных требований, менеджеры опасались, что в программе имеются скрытые ошибки и поэтому долгое время не пересматривали прогноз, а предпочитали устраивать переработки в выходные дни.

План поиска дефектов

Представляет собой детальный прогноз количества дефектов с разбивкой по подсистемам и времени. Как правило, за единицу времени выбирается неделя.

Цели

1. Распределить ресурсы, ответственные за контроль качества, во времени.
2. Получить механизм контроля за работой инженеров по качеству.

Примечание: План поиска дефектов задаёт нормативы для всех инженеров по качеству. Он основывается на ранее сделанном прогнозе путём распределения общего числа дефектов по неделям проекта. Команда инженеров по качеству получает недельные задания – сколько дефектов в программе она должна найти в течение той или иной недели. Недельные задания можно детализировать дальше – по дням и сотрудникам. В результате, будут получены задания для каждого инженера на каждый день.

Описание

План поиска дефектов представляет собой таблицу, в которую заносят желаемые показатели результативности всей команды инженеров по качеству на каждую неделю проекта.

Таблица 4. Понедельный план поиска дефектов для мобильной навигационной системы GPS

Область	01.09.14	08.09.14	15.09.14	22.09.14
Пользовательский интерфейс	5	5	10	12
Построение маршрута	3	3	5	7
Поиск адреса	5	5	5	8
Поиск мест	0	1	2	3
Карта	3	5	7	8
Навигация	8	10	10	12
Аудио	0	1	2	3
Итого	24	30	41	53

Параметры

В каждой ячейке напротив названия подсистемы указывается
количество дефектов, которое будет найдено в ней в течение определённой недели.
Даты окончания недель задаются в заголовках столбцов.

Диаграмма

На основании плана строится график поиска дефектов, который представляет собой S-образную кривую.

По вертикальной оси откладывается общее количество найденных дефектов «в процентах», а по горизонтальной оси – время.

На графике также откладываются ключевые даты проекта: альфа-версия, бета-версия и финальная версия.

Рисунок 3. Графическое представление плана поиска дефектов за всё время работы над проектом

Использование

Визуально, на кривой можно выделить три этапа.

Первый этап начинается с момента старта проекта и заканчивается выпуском альфа-версии. В это время кривая растёт не так интенсивно, потому что до альфа-версии приоритет отдаётся разработке программы, а не поиску дефектов. Ещё не все требования реализованы, а то, что сделано, может быть реализовано не в полном объёме.

На втором этапе, между альфа и бета-версиями, кривая растёт весьма интенсивно. Это происходит потому, что к этому моменту практически все запланированные требования уже реализованы, и к тестированию программы подключаются дополнительные инженеры по качеству, а программисты переключаются с реализации требований на исправление дефектов.

Незадолго до бета-версии, остаётся не так много дефектов. Наиболее очевидные из них уже найдены и исправлены. Начинают проявляться неочевидные ошибки, которые сложнее находить и исправлять. Кривая замедляет свой рост. А ещё через какое-то время неочевидные ошибки тоже оказываются исправленными, и кривая перестаёт расти. В этот момент выпускается бета-версия программы. А затем – если новых ошибок не обнаруживается – выпускается финальная версия.

К моменту альфа-версии отделом тестирования должно быть найдено 30% всех дефектов. К бета-версии должно быть найдено 98% всех дефектов.

Управление рисками

Назначение

Предусмотреть риски, которые могут осложнить или сорвать проект, разработать план действий на случай срабатывания риска для нейтрализации его последствий.

Примечание: В системной инженерии существует методология «анализ видов и последствий отказов» (англ. – Failure Modes and Effects Analysis, https://ru.wikipedia.org/wiki/FMEA). Согласно стандарту министерства обороны США эта процедура проводит анализ потенциальных ошибок системы, определяет результаты их влияния как на систему в целом, так и на различные подсистемы, производит классификацию ошибок относительно их критичности.

Управление рисками похоже на анализ видов и последствий отказов: выявляются риски, оценивается их негативное влияние на проект, находятся решения для нейтрализации негативных последствий.

Реестр рисков

Цели

1. Описать выявленные риски.

Примечание: Одна из характерных проблем в ряде компаний (которые даже не распределённые, а сотрудники находятся в одном офисе) – люди не делятся опытом. Не происходит обмен информации по поводу типовых ошибок, рисков, решений. Надо вытаскивать всё это на белый свет и делать доступным для всей компании.

Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Тут даже больше: нужно описывать решение сразу (по-возможности, следует находить идеальные решения). Т.е. выявить риск мало – надо сразу думать о том, как его предотвратить. Иначе риски так и остаются «граблями».

Пример (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Перед нашим Клиентом стояла задача – разморозить оборотные средства в размере 25 млн. рублей за 1 месяц. Казалось, мы учли все риски, кроме налогов, потому что финансовый директор был в отпуске, и зная, что эта задача будет решаться, ничего не сказал. Сделали отличный план по размораживанию средств и реализовали его. В результате, налетели на налог на прибыль. Если бы данный риск был учтён, то можно было бы вырученные средства потратить для приобретения недвижимости, и, тем самым, избежать уплаты налога.

2. Оценить важность каждого риска и вероятность его срабатывания.

Пример. Риск того, что проект закроется из-за попадания метеорита в офис компании, обладает высокой важностью. Тем не менее, вероятность его срабатывания настолько низка, что безболезненно позволяет этот риск игнорировать.

Пример. Одна компания, разрабатывающая GPS-навигатор, решила сменить поставщика карт. Причина смены проста – стоимость лицензии в 2 раза ниже, а формат описания карт – тот же. Тем не менее, цена перехода на карты нового поставщика обошлась компании в 2 – 3 человека-года. Именно столько усилий было затрачено на решение возникших технических проблем.

3. Предложить план действия на случай того, если риск сработает.

Пример. При создании одной игры для маленьких девочек был серьёзный риск не уложиться в отведённые сроки. Было несколько причин у этого риска: новая команда, незнакомая платформа, для которой велась разработка, отсутствие отлаженной технологической инфраструктуры. Чтобы снизить риск, было принято решение организовать игру в виде последовательности мини-игр. Каждая такая игра была достаточно простой, не слишком сильно насыщенной графикой и другими персонажами. Кроме того, игрок был лишён свободы передвижения, т.е. мог двигаться только в заранее определённых направлениях. Это настолько упростило процесс разработки, что одна мини-игра в финальном качестве создавалась за 5 человеко-дней (имеется в виду работа инженера без учёта работы художника).

4. Распределить риски между ответственными за их устранение.

Описание

Все выявленные риски заносят в специальную таблицу, как в примере ниже.

Таблица 5. Таблица рисков для мобильной навигационной системы GPS

Риск	Важность	Вероятность	Вес	Что делать?	Ответственный	Состояние
Если программисты не получат новые карты от поставщика до 15 октября, то они не будут включены в релиз	Средняя	Низкая	2	Связаться с поставщиком по телефону и послать напоминание по email	Сергеев А.Д.	Нужно напомнить ещё пару раз
Если отдел маркетинга не предоставит отзывы покупателей до 1-го сентября, то команда не сможет учесть их в очередном релизе	Высокая	Высокая	9	Запросить отдел маркетинга	Владимиров К.П.	Получены, находятся на сервере в папке ‘Отзывы’

Параметры

Каждый риск записывается по формуле:

Если не <будет сделано что-то> до <определённой даты>, то <произойдёт нечто негативное>.

Каждый риск следует оценить с точки зрения его важности, т.е. негативных последствий для проекта при его срабатывании. Обычно ограничиваются шкалой из трёх оценок: низкая, средняя и высокая.

Также следует оценить вероятность срабатывания риска. Для оценки тоже можно ограничиться тремя значениями: низкая, средняя и высокая.

Вес риска рассчитывается автоматически, исходя из его важности и вероятности. Для этого оценочные значения преобразуются в числовые следующим образом: значение «низкая» становится равной 1, «средняя» — 2, а «высокая» — 3. Вес рассчитывается, как произведение двух оценок. Например, если важность риска высокая и вероятность его срабатывания тоже высокая, то риск получает вес равный 9.

Использование

При ограниченных ресурсах в первую очередь следует уделять внимание рискам с наибольшим весом.
При описании риска также следует добавить план действий на случай его срабатывания или для уменьшения вероятности его срабатывания и/или его важности. Для каждого риска назначается ответственный, который отвечает за его нейтрализацию.

Заключение

1. Проекты по разработке программного обеспечения бывают как индивидуальными, так и коллективными.
2. Коллективные программные проекты требуют координации усилий многих людей. Нередко эти люди обладают разными специальностями, находятся в разных странах и на разных континентах и разговаривают на разных языках.
3. Крупные корпорации имеют опыт по управлению достаточно большими (100 – 200 человек), интернациональными и распределёнными творческими коллективами. Этот опыт можно переосмыслить и использовать.
4. Процесс управления реальным проектом основан на контроле целой группы параметров. Это только в школе учат мыслить функцией от одной переменной.
5. Для контроля параметров управления рекомендуется использовать процессы управления, среди которых есть: управление задачами, управление сроками, управление качеством, управление рисками и т.д.
6. Каждый из процессов управления сводится к одному или нескольким инструментам и методикам их применения. Среди инструментов есть такие: система контроля задач, диаграмма сгорания задач, прогноз количества дефектов, план поиска дефектов, реестр рисков.

Автор благодарит Василину Абу-Навас (Объединение «Практик»), И.Л. Викентьева (Система «ТРИЗ-ШАНС»), Эдуарда Галиаскарова и Антона Яковлева за помощь в подготовке статьи.

Статья: Руководство программным проектом

Содержание

1. Введение

2. Руководство программным проектом

3. Планирование проектных задач

4. Конструктивная модель стоимости

5. Заключение

6. Список литературы

Введение

Руководство программным проектом — первый слой процесса конструирования ПО. Термин «слой» подчеркивает, что руководство определяет сущность процесса разработки от его начала до конца. Принцип руководства иллюстрирует рис. 2.1.

Рис. 2.1. Руководство в процессе конструирования ПО

На этом рисунке прямоугольник обозначает процесс конструирования, в нем выделены этапы, а вверху, над каждым из этапов, размещен слой деятельности «руководство программным проектом».

Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ [32], [64], [69].

2. Руководство программным проектом

Начало проекта

Перед планированием проекта следует:

· установить цели и проблемную область проекта;

· обсудить альтернативные решения;

· выявить технические и управленческие ограничения.

Измерения, меры и метрики

Измерения помогают понять как процесс разработки продукта, так и сам продукт. Измерения процесса производятся в целях его улучшения, измерения продукта — для повышения его качества. В результате измерения определяется мера — количественная характеристика какого-либо свойства объекта. Путем непосредственных измерений могут определяться только опорные свойства объекта. Все остальные свойства оцениваются в результате вычисления тех или иных функций от значений опорных характеристик. Вычисления этих функций проводятся по формулам, дающим числовые значения и называемым метриками.

В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы.

Процесс оценки

При планировании программного проекта надо оценить людские ресурсы (в человеко-месяцах), продолжительность (в календарных датах), стоимость (в тысячах долларов). Обычно исходят из прошлого опыта. Если новый проект по размеру и функциям похож на предыдущий проект, вполне вероятно, что потребуются такие же ресурсы, время и деньги.

Анализ риска

На этой стадии исследуется область неопределенности, имеющаяся в наличии перед созданием программного продукта. Анализируется ее влияние на проект. Нет ли скрытых от внимания трудных технических проблем? Не станут ли изменения, проявившиеся в ходе проектирования, причиной недопустимого отставания по срокам? В результате принимается решение — выполнять проект или нет.

Планирование

Определяется набор проектных задач. Устанавливаются связи между задачами, оценивается сложность каждой задачи. Определяются людские и другие ресурсы. Создается сетевой график задач, проводится его временная разметка.

Трассировка и контроль

Каждая задача, помеченная в плане, отслеживается руководителем проекта. При отставании в решении задачи применяются утилиты повторного планирования. С помощью утилит определяется влияние этого отставания на промежуточную веху и общее время конструирования. Под вехой понимается временная метка, к которой привязано подведение промежуточных итогов.

В результате повторного планирования:

· могут быть перераспределены ресурсы;

· могут быть реорганизованы задачи;

· могут быть пересмотрены выходные обязательства.

3. Планирование проектных задач

Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для последующих параллельных задач.

Системный анализ проводится с целью:

1. выяснения потребностей заказчика;

2. оценки выполнимости системы;

3. выполнения экономического и технического анализа;

4. распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);

5. определения стоимости и ограничений планирования;

6. создания системной спецификации.

В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация.

Анализ требований дает возможность:

1. определить функции и характеристики Программного продукта;

2. обозначить интерфейс продукта с другими системными элементами;

3. определить проектные ограничения программного продукта;

4. построить модели: процесса, данных, режимов функционирования продукта;

5. создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

Рис. 2.2. Типовая структура распределения проектных работ

Результаты анализа сводятся в спецификацию требований к программному продукту.

Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования. После получения всех модулей ПО решается задача тестирования интеграции — объединения элементов в единое целое. Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика.

Ромбиками на рис. 2.2 обозначены вехи — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи.

Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.

Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи.

Обычно используют следующие оценки:

1. Раннее время начала решения задачи Tinmin (при условии, что все предыдущие задачи решены в кратчайшее время).

2. Позднее время начала решения задачи Tinmax (еще не вызывает общую задержку проекта).

3. Раннее время конца решения задачи Toutmin

Toutmin = Tinmin + Tреш

4. Позднее время конца решения задачи Toutmax

Toutmax = Tinmax + Tреш.

5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Tк.п.

Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач.

Рекомендуемое правило распределения затрат проекта — 40-20-40:

· на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ — 5%);

· на кодирование — 20%;

· на тестирование и отладку — 40%.

Выполнение в ходе руководства проектом

Процесс руководства программным проектом начинается с множества действий, объединяемых общим названием планирование проекта. Первое из этих действий — выполнение оценки. Оно закладывает фундамент для других действий по планированию проекта. При оценке проекта чрезвычайно высока цена ошибок. Очень важно провести оценку с минимальным риском.

Выполнение оценки проекта на основе LOC- и FP-метрик

Цель этой деятельности — сформировать предварительные оценки, которые позволят:

· предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;

· составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

· в качестве оценочных переменных, определяющих размер каждого элемента продукта;

· в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы.

Обсудим шаги процесса оценки.

· Шаг 1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально:

f1 ,f2, …,fn.

· Шаг 2. Для каждой функции f1 планировщик формирует лучшую LОСлучшi (FРлучшi ), худшую LOСХУДШi (FРХУДШi ) и вероятную оценку LOСвероятнi (FРвероятнi ). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

· Шаг 3. Для каждой функции fi в соответствии с β-распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:

LOCожi = LOCлучшi + LOCхудшi + 4 x LOCвероятнi ) / 6.

· Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.

Используется один из трех подходов:

1. для всех функций принимается одна и та же метрика средней производительности ПРОИЗВср, взятая из метрического базиса;

2. для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ПРОИЗВi = ПРОИЗВср х (LOСср / LOСожi ),

где LOCcp — средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

4. Конструктивная модель стоимости

В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) — дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели [1].

Иерархию подмоделей Боэма (версии 1981 года) образуют:

· базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;

· промежуточная СОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;

· усовершенствованная СОСОМО — объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).

Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

· распространенный тип — небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту;

· полунезависимый тип — средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

· встроенный тип — программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.

Уравнения базовой подмодели имеют вид

Е = ab x (KLOCbb [чел-мес];

D = cb x (E)db [Mec],

где Е- затраты в человеко-месяцах, D — время разработки, KLOC — количество строк в программном продукте.

Заключение

СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.

Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.

Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.

В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.

Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

Из таблицы следует, что увеличение затрат в 1,3 раза из-за очень высокой сложности продукта уравновешивается их уменьшением вследствие высокой квалификации аналитика и программиста, а также активного использования программных утилит.

Список литературы

1. Боэм Б. У. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. 511 с.

2. Липаев В. В. Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993. 384 с.

3. Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.

4. Орлов С. А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, 2001. 327 с.

5. Чеппел Д. Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.

6. Abreu, F. В., Esteves, R., Goulao, M. The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics. Proceedings of the TOOLS’96. Santa Barbara, California 20 pp. July 1996.