Белорусский государственный экономический университет
Булова А.Д.
Управление проектами разработки
компьютерных информационных технологий и систем
(практическое пособие)
Минск
УДК 004.7
ББК 32.973.202
К68
А в т о р: кандидат технических наук, доцент А. Д. Булова
Рецензент ы:
Мамоненко И.В. – генеральный директор ЗАО «Белхард Групп»;
Минченко Л. И. — доктор физико-математических наук, профессор
Р е к о м е н д о в а н о: кафедрой экономической информатики БГЭУ
У т в е р ж д е н о: Редакционно-издательским советом БГЭУ
Управление проектами разработки компьютерных информационных технологий и систем, учебник для студентов, магистрантов и аспирантов / А. Д. Булова, под редакцией к.т.н., доцента А.М.Седуна. — Минск, Издательство, 2016. — 190 с.
ISBN 985-985-484-678-1
Учебник состоит из 6 глав, охватывающих основные процессы управления разработкой проектов в областиИТ. К каждой главе прилагается список контрольных вопросов, главы снабжены кейсами, освещающими прикладные аспекты изучаемого материала. Содержание учебника соответствует Республиканскому государственному образовательному стандарту высшего профессионального образования третьего поколения и методическим требованиям, предъявляемым к учебным изданиям. Рекомендуется к использованию в курсах: «Компьютерные информационные технологии», «Компьютерные информационные системы», «Реинжиниринг бизнес процессов», «Управление проектами в сфере информатизации» для студентов, магистрантов, аспирантов и преподавателей экономических, технических вузов и факультетов, а также всех, кто интересуется управлением ИТ-проектами с теоретической и практической точки зрения и изучает данную дисциплину самостоятельно.
УДК 004.7
ББК 32.973.202
© УО «Белорусский государственный»
ISBN 985-985-484-678-1 экономический университет, 2016
Содержание:
Предисловие
1. Цель, назначение проекта
1.1. Понятие, типы и виды ИТ-проектов. Подписание протокола о намерениях (сотрудничестве)
1.2. Примеры документов
2. Методы оценки проекта
2.1. Разработка и согласование технического задания
2.2. Техническое задание
2.3. Пользовательские сценарии (UseCases)
2.4. Agile-методы – Пользовательские истории (Storymapping)
2.5. Концептуальное единство
2.6. Оценка трудоемкости
2.7. Типовые причины оптимистических планов
2.8. Оценка объема работ по функциональным баллам
2.9. Оценка длительности проекта по трудоемкости
2.10. Оценка, основанная на рисках
2.11. Оценка рисков по возможным сценариям
2.12. Оценка по вероятности
2.13. Общие рекомендации по оценке сроков
2.14. Практические советы
2.15. Правило корректировки графиков
2.16. Как вести исторические записи
2.17. Разработка, ориентированная на заказчика
2.18.. Планирование быстрой разработки
3. Стейкхолдеры проекта
3.1. Спонсор проекта
3.2. Заказчик проекта
3.3. Руководитель проекта
3.4. Команда проекта
3.5. Участники проекта (должности, сферы ответственности)
3.6. Мотивация персонала, управление конфликтами
4. Планирование рисков
4.1. Ошибки управления проектами – результат недостаточного учёта и реагирования на риски
4.2. Управление рисками ИТ-проекта
4.3. Некоторые несоответствия «общепризнанных» утверждений
4.4. Анализ риска (RiskAnalysis)
4.5. Управление выявленными рисками проекта (ManagingProjectRisks)
4.6. Управление проблемами проекта
5. Реализация проекта
5.1. Администрирование проекта
5.2. Аутсорсинг процессов разработки ИТ
5.3. Некоторые сущностные особенностиИТ-проектов
5.3.1. Характер процесса разработки ПО
5.3.2. Модель технологической зрелости
5.3.3. Стандарт ISO 9000
5.3.4. Язык и средства моделирования
5.3.5. Язык UML
5.3.6. CASE средства и совершенствование процесса
5.3.7. Полезные инструменты (VMware, Nagios, GUI)
5.3.8. Эффективный поиск информации посредством Google
5.3.9. Планирование разработки системы (SWOT, VCM)
5.3.10. BPR. Сущность и методология. Связь с ИТ-проектами
5.3.11. Подход ISA (Information Systems Architecture)
5.3.12. Этапы жизненного цикла программного обеспечения
5.3.13. Планирование проекта в течение жизненного цикла ПО
5.3.14. Подходы к разработке программного обеспечения
6. Закрытие проекта, выводы на будущее
6.1. Закрытие проекта
6.2. И все-таки – выводы. Как будем жить дальше…
Список литературы
ПРЕДИСЛОВИЕ
Управление проектами, методы которого стали формироваться в середине прошлого века, за прошедшее с тех пор время сложилось в специфическую область знаний и практическую методологию, широко применяемую в самых разных областях человеческой деятельности. Разработаны международные стандарты управления проектами, в соответствии с которыми строятся процессы управления самыми различными проектами — от научно-исследовательских до строительных и космических, а также любыми изменениями в компаниях. Особенно актуальной в условиях Беларуси является проблема подготовки управленческих кадров для софтверных компаний. По данным Парка высоких технологий в 2015 г. более 140 компаний резидентов ПВТ выполняют свыше 8500 ИТ-проектов силами более 12.5 тысяч специалистов (в основном - программистов). Потребителями, разработанного резидентами ПВТ программного обеспечения, являются компании из 55 стран мира, среди которых такие мировые корпорации, формирующие облик современной мировой экономики, как Google, Microsoft, Лондонская фондовая биржа, BritishTelecom, Coca-Cola, Samsung и др. Пять из десяти крупнейших мировых компаний (рейтинг авторитетного издания Forbes) являются клиентами белорусского Парка высоких технологий. Все эти работы выполняются здесь и сейчас силами наших белорусских программистов. Если с подготовкой программистов в Республике Беларусь в целом дело поставлено весьма неплохо (наши ребята регулярно занимают призовые места чемпионата мира по программированию среди студентов –ACM***), то подготовка управленческих кадров среднего звена (прожект - менеджеров) находится в зачаточном состоянии. Даже в наших общепризнанных кузницах программистов (БГУ, БГУИР) курс управления ИТ-проектами читается на уровне спецкурсов с явно недостаточным количеством часов и практическим отсутствием учебной литературы. Между тем на сегодняшний день все софтверные компании испытывают острый кадровый голод именно в специалистах данного профиля и, ввиду имеющегося явного дефицита на рынке труда, вынуждены готовить их самостоятельно.
Несмотря на большое количество литературных источников, появившихся в последнее время в области управления проектами, большинство из них имеют чересчур общий, не нацеленный непосредственно на разработку софтверных проектов, характер. В данном пособии автор целенаправленно сосредоточил внимание на основных аспектах управления именно ИТ-проектами, как теоретических, так и практических. Книга состоит из 6 глав, охватывающих основные процессы управления ИТ-проектами. К каждой главе прилагается список контрольных вопросов, позволяющих осмыслить и закрепить изученный материал. Главы снабжены кейсами, освещающими прикладные аспекты изучаемого материала. Практические задания и кейсы могут использоваться в заданиях промежуточного учебного контроля по дисциплине «Управление ИТ-проектами». Приведён список литературы в количестве 98 наименований и, кроме этого, по тексту проставлены ссылки на соответствующие интернет-источники.
***В чемпионате ACM(AssociationforComputingMachinery) в 2009 году приняло участие 7109 команд из 88 стран, 100 из которых сошлись в борьбе за главный трофей в финальном турнире. Ежегодно количество команд увеличивается на 10-20 %.Вот результаты представителей Беларуси: команда БГУ ФПМИ - золотая медаль (2004 г., Прага, Чехия), «бронза» (2008 г., Банф, Канада) и два «серебряных» выступления (2012 г., Варшава и 2013 г., Санкт-Петербург).
Управление проектами - это философия
управления, а не инструмент или техника
1. Цель, назначение проекта
1.1. Понятие, типы и виды ИТ-проектов. Подписание протокола о намерениях (сотрудничестве)
1.1.1. Понятие, типы и виды ИТ-проектов
Сразу хочу отметить, что в данном курсе речь будет идти о проектах, связанных с программированием и сопутствующим им работах. Никоим образом не будут рассматриваться вопросы по проектированию и изготовлению hardware, хотя общие положения в области управления проектами имеют универсальный характер. Достаточно подробный перечень литературы представлен источниками [1-89].
Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Данное определение(Whitty, S.J. andSchulz, M.F. THEPM_BOKCODE. — 20thIPMAWorldCongressonProjectManagement, 1, 466-472, 2006)полностью соответствует специфике ИТ-проектов. Рассмотрим основные его составляющие:
Термин "временное" означает, что у любого проекта есть начало и есть завершение. Завершение наступает, когда достигнуты цели проекта; или в ходе выполнения проекта стало понятно, что заявленные цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается. "Временный" не обязательно предполагает краткую длительность проекта: многие проекты могут длиться в течение нескольких лет, но во всех случаях проект конечен. Проекты не являются постоянно продолжающейся деятельностью.Кроме того, термин "временный" не относится к создаваемым в ходе проекта продуктам, услугам или результатам. Большинство проектов предпринимается для достижения устойчивого, длительного результата.
Следует четко понимать, что:
-благоприятная возможность, или рыночное окно, может продолжаться весьма ограниченное время – некоторые проекты ограничены временными рамками для создания нового продукта или услуги;
-команда проекта как рабочая единица редко переживает проект, так как команда, созданная исключительно для выполнения проекта, по завершении проекта будет распущена, и члены команды получат новые назначения.
В качестве уникальных продуктов в сфере ИТ можно привести, в первую очередь (1), примеры универсальных (или специализированных) программных «коробочных» софтверных систем. Эти продукты Microsoft, Oracle, SAP и т.п. хорошо известные в мире. Крайне важными характеристиками полученных продуктов являются их надежность, дизайн, качество сопроводительной документации.
Второе (2) – это разработка специализированных программных продуктов по заказу конкретных компаний.
Услуги. Здесь в первую очередь речь идет о выполнении работ в области аутсорсинга, т.е. оказанию услуг по выполнению части, или проекта в целом по заказу других компаний. Это могут быть как проекты, связанные с программированием, так и проекты по управлению качеством программных продуктов (QA – qualityassurance), работы по ИТ-аудиту, ИТ-консалтингу, реинжинирингу как бизнес процессов, так и соответствующих программных продуктов, консультационные услуги по внедрению имеющихся сложных программных систем и многое другое.
Кроме этого, не следует забывать о сопровождении переданных Заказчику программных продуктов. Есть еще немалая часть в сфере услуг ИТ – это работы, связанные с Hardware (не связанные с их производством) – конфигурирование и настройка сетей, апгрейд оборудования, консультационные услуги.
Результаты. Следует отдавать себе отчет, что как продукты, так и услуги в ИТ не являются вещами в себе – конечный их результат, это повышение экономической эффективности компаний, для которых это все предназначено.
В соответствии с описанием продуктов и услуг в сфере ИТ можно выделить следующие типы и виды ИТ проектов:
- разработка универсальных или специализированных программных «коробочных» софтверных систем;
- разработка специализированных программных продуктов по заказу конкретных компаний
- аутсорсинг проектов, связанных с программированием;
- аутсорсинг проектов, связанных с управлением качеством программных продуктов;
- работы по ИТ-аудиту, ИТ-консалтингу, реинжинирингу как бизнес процессов, так и соответствующих программных продуктов;
- консультационные услуги по внедрению имеющихся сложных программных систем;
- конфигурирование и настройка сетей, апгрейд оборудования, консультационные услуги в данной области.
Н А Ч А Л О
После проведения переговоров с потенциальным Заказчиком, после того, как стороны убедились в том, что они имеют одинаковое понимание проблем, подлежащих решению, обе стороны подписывают протокол о намерениях.
Протокол составляется в произвольной форме. В обязательном порядке в протоколе должны присутствовать основные показатели проекта (пока приблизительные), а именно:
- сроки (начало, конец проекта);
- качественные (функциональные) показатели выполненной разработки;
- финансовые затраты.
До подписания договора на выполнение проекта, все эти показатели должны быть уточнены.
1.2. Примеры документов:
Договор (контракт) с зарубежной компанией:
Contract No 002/34
Minsk January 02, 20XX
This is a software development contract (“CONTRACT”) between RsX, INC. (“RRR") having a legal place of business at 1710, 542 - 6th Avenue S.W., Calgary, Canada, and EsX LLC (“EEE”), having a legal place of business at 12 Kolasa St., Minsk, 220090, Belarus.
1. EEE will provide development and manufacturing of products (FFF) according to specifications supplied by RRR and EEE. EEE will also provide technical and warranty support, consulting and upgrades according to specifications and additional agreements with RRR. EEE shall use its best efforts to create a commercial package of FFF as specified by RRR and EEE
2. RRR and EEE will provide preparation of the concepts, technical requirements and specifications of FFF. RRR will also provide invitations, accommodation, technical and other facilities for EEE representatives coming to the United States of America (“USA”), Canada, or other countries necessary, according to this contract for technical support, consulting, deliveries, warranty support and upgrades, unless this is provided by RRR and EEE customers.
3. This contract includes the following joint developments:
3.1 Development of software system for logistics and optimization of processes in the petroleum industry (FFF).
3.2 This contract allows for other developments that can be added to the list in future. The future developments require additional agreements and specifications as amendments to this contract unless the conditions of the developments will comply with this contract.
4. This contract is valid until December 31st, 20XX. This contract will automatically extend to December 31st, 20YY if no party cancels or changes the conditions of the contract.
5. The development according to this contract may need visits of EEE specialists to other countries. If immediate technical support or urgent testing is required, the appropriate expert should be available to travel to another country in no more than ten working days. EEE should have all the necessary papers prepared beforehand for a minimum of two professionals for such an eventuality. During the visits of EEE specialists, RRR will provide round trip transportation and accommodation. RRR and EEE customers could provide the conditions listed above subject to RRR and EEE approval. Daily payment (Per Diem) of expenses of EEE specialists working for RRR in other countries will be provided by EEE unless otherwise agreed with RRR.
6. Payment conditions:
6.1 As volume of development work and consulting jobs are not entirely determined beforehand for long-term projects, the parties of the contract agree to negotiate conditions of development and level of payment depending on prospective and actual expenses of working hours and material resources. The contract price consists of the sum of the invoice volumes.
6.2 RRR will make monthly payments against EEE invoices approved by RRR. An acceptance of the delivered job is a fact of the payment. Payments are made in USD.
6.3 Subject to RRR approval, payments could be provided by RRR customers directly to EEE. The terms and amount of the payments should correspond to section 6.2 of this contract.
6.4 Payments made by ZZZ or MMM to EEE will be considered as payments from RRR for this contract.
6.5 Due payments are executed within 30 days. In case of a backlog of payment a fine of 0.1% of the backlog is setting.
6.6 EEE USD account No. 3012-1 in ОАО «DJAM-BANK» SWIFT: DJAMBY22, MINSK, BELARUS.RRR account No. 110967 Citizens Bank, Massachusetts, USA.
7. Delivery terms and conditions.
7.1 Each stage should be completed and documents drawn up confirming completion of the work presented by EEE to RRR
7.2 RRR will endeavor to return to EEE signed documents accepting completion of work by EEE within fifteen working days.
7.3 Each stage is considered complete only after the work completion document has been signed by RRR and EEE.
8. RRR and EEE shall have the right to terminate this contract at any time by giving the other party fifteen (15) days prior written notice.
9. EEE and RRR shall hold in confidence and shall not publish, disseminate or otherwise use any confidential information it receives from RRR or EEE or any other source by virtue of this contract. All data, including computer programs, computations, records, books, photographs and documentation shall become the property of RRR - 50% and EEE- 50%.
10. All rights of licenses under any patent, invention, copyright or any other intellectual property right shall exclusively belong to RRR and EEE. Nothing in this contract, including any affiliates RRR and EEE shall be construed, by implication or otherwise, to grant any right or license to any third party, under any patent, invention, copyright or any other intellectual property right, now or hereafter owned or controlled by RRR and/or EEE
The laws of Canada and Republic of Belarus shall govern this Agreement. Court of jurisdiction is Calgary, Alberta, Canada or/and Minsk, Republic of Belarus. This agreement constitutes the entire agreement between the parties hereto and supersedes all previous agreements and understandings, whether oral or written, express or implied, with respect to the subject matter contained in this agreement. This contract may not be altered, amended or modified except by written instrument signed by duly authorized representatives of both parties. This contract will be translated into Russian. Both texts must be identical originals in order for either to be valid.
RRR Inc. EEELLC
Zzy, President Aab, Director
Договор с отечественной компанией:
Договор
на разработку Программного обеспечения «____________________»
г. Минск "___" ____________ 20__ г.
___________________________________________, именуемое в дальнейшем Заказчик, в лице директора ________________________________, действующего на основании Устава, с одной стороны, и Общество с ограниченной ответственностью «ИНЖЕНЕРНЫЕ СИСТЕМЫ», именуемое в дальнейшем Исполнитель в лице директора _________________________________, действующего на основании Устава, с другой стороны, а вместе именуемые стороны, заключили настоящий договор о нижеследующем:
1. ПРЕДМЕТ ДОГОВОРА
1.1. Заказчик поручает, а Исполнитель принимает на себя обязательства по разработке и передаче Заказчику программного обеспечения «____________» (далее – Программное обеспечение), а Заказчик обязуется принять и оплатить его в соответствии с условиями настоящего Договора.
1.2. Требования к разрабатываемому Программному обеспечению указаны в Приложении №1, являющемся неотъемлемой частью настоящего Договора.
1.3. Правообладателем на разработанное по настоящему Договору Программное обеспечение становится Заказчик, авторские права остаются за исполнителем.
2. ПРАВА И ОБЯЗАННОСТИ СТОРОН
2.1. Заказчик обязуется:
2.1.1. Предоставить Исполнителю Техническое задание на разработку Программного обеспечения (Приложение №1 настоящего Договора)
2.1.2.Выплачивать Исполнителю вознаграждение в соответствии с условиями настоящего Договора
2.2. Исполнитель обязуется:
2.2.1. Выполнить работы, указанные в Техническом задании (Приложение №1), в сроки, установленные в п. 4.2. настоящего Договором.
2.2.2. Устранить недостатки и дефекты, выявленные при приемке работ.
2.3. Заказчик имеет право менять по своему усмотрению программный код разработанного программного обеспечения.
2.4. Заказчик имеет право на тиражирование, распространение в т.ч. в коммерческих целях разработанного Программного обеспечения
2.5. По окончании работ Исполнитель передает программный код разработанного программного обеспечения Заказчику в полном объеме, а также предоставляет скомпилированный исполняемый файл программы и в случае необходимости инсталляционный пакет для установки программы.
2.6. Право выбора технологии программирования и алгоритмов работы остается за Исполнителем.
3. СТОИМОСТЬ РАБОТ И ПОРЯДОК ОПЛАТЫ
3.1. Общий размер вознаграждения Исполнителя за выполнение услуг, указанных в п. 1.1. настоящего Договора, составляет __________ .
3.2. Оплата услуг осуществляется тремя платежами:
3.2.1. Первый (авансовый) платеж в размере __________ осуществляется в течение 3 (трех) рабочих дней с момента подписания настоящего Договора.
3.2.2. Второй платеж в размере _____________ производится в течение 3 (трех) рабочих рабочей дней после подписания акта приема-сдачи работ(Приложение №2) на выполнения работ в объема половины Технического задания (Приложение №1).
3.2.3. Третий платеж в размере _______________ производится в течение 3 (трех) рабочих дней после подписания акта приема-сдачи работ на выполнения всех работ по Техническому заданию (Приложение №1).
3.3. Оплата стоимости услуг по настоящему Договору может производиться в ином порядке по письменному согласованию Сторон.
3.4. Расходы на оборудования, требуемые для выполнения работ по данному договору, оплачивает заказчик в размере _________________ в течение 3 (трех) рабочих дней после подписания настоящего договора.
4. СРОК ИСПОЛНЕНИЯ ДОГОВОРА
4.1. Настоящий Договор вступает в силу со дня подписания и действует до исполнения Сторонами своих обязательств, вытекающих из существа настоящего Договора.
4.2. Исполнитель обязуется разработать и передать Заказчику Программное обеспечение, указанное в п. 1.1. настоящего договора, в срок в 3(три) календарных месяца с момента подписания настоящего Договора.
5. ПОРЯДОК ПРИЕМКИ РАБОТ
5.1. Исполнитель по результатам оказания услуг направляет заказчику Акт сдачи-приемки оказанных услуг, подписанный со своей стороны. В течение пяти рабочих дней после получения Акта от Исполнителя Заказчик обязан либо подписать Акт и направить Исполнителю подписанный экземпляр Акта, либо предоставить мотивированный отказ от приемки с приложением подписанного со стороны заказчика скорректированного Акта.
6. ОТВЕТСТВЕННОСТЬ СТОРОН И ПОРЯДОК РАЗРЕШЕНИЯ СПОРОВ
6.1. В случае просрочки оплаты работ Исполнителю против сроков, указанных в условиях настоящего Договора, Исполнитель имеет право потребовать неустойку в размере 0,1% (ноль целых одна десятая процента) за каждый день просрочки, но не более чем 10% от суммы вознаграждения за подлежащие оплате услуги.
6.2. В случае несоблюдения Исполнителем срока оказания услуг, установленного в п. 4.2 настоящего Договора, Заказчик имеет право потребовать неустойку в размере 0.1% (ноль целых одна десятая процента) за каждый день просрочки, но не более чем 10% от суммы вознаграждения за подлежащие оплате услуги.
6.3. Неустойка полагается к уплате в случае выставления соответствующего счета и считается признанной с момента оплаты такого счета.
6.4. Штрафы и неустойки выплачиваются стороной, нарушившей обязательства, в течение 5 (пяти) банковских дней с момента выставления соответствующего требования.
6.5. Споры и разногласия между Сторонами по данному Договору разрешаются путем переговоров и соглашений, а в случае невозможности достижения взаимоприемлемого решения в соответствии с действующим законодательством Республики Беларусь.
7. НЕПРЕОДОЛИМАЯ СИЛА (ФОРС-МАЖОРНЫЕ ОБСТОЯТЕЛЬСТВА)
7.1. Стороны освобождаются от ответственности за частичное или полное неисполнение обязательств по настоящему Договору, если неисполнение явилось следствием природных явлений, действий внешних объективных факторов и прочих обстоятельств непреодолимой силы, за которые Стороны не отвечают и предотвратить неблагоприятное воздействие которых, они не имеют возможности.
7.2. Стороны несут ответственность за частичное или полное неисполнение обязательств по настоящему Договору при наличии вины только в случаях, предусмотренных законом или настоящим Договором.
8. ПРОЧИЕ УСЛОВИЯ
8.1. Настоящий Договор составлен в двух экземплярах, имеющих равную юридическую силу, по одному для каждой из сторон.
8.2. Ни одна из Сторон не вправе передавать свои права и обязанности по настоящему договору третьим лицам без письменного согласия на то другой Стороны.
8.3. Вся корреспонденция, включая необходимые письменные уведомления, претензии и заявления, по настоящему Договору будет считаться доставленной Стороне Договора, если они будут доставлены в письменном виде любым способом, предусмотренным Белорусским законодательством по следующему адресу:
Для Заказчика: адрес для почтовой корреспонденции совпадает с адресом проживания.
Для Исполнителя: адрес для почтовой корреспонденции совпадает с адресом проживания.
8.4. Исполнитель гарантирует, что:
8.5.1. результаты оказания услуг, передаваемые им Заказчику по настоящему Договору, свободны от любых прав третьих лиц;
8.5.2. при оказании услуг по настоящему Договору Исполнитель не нарушает авторских и смежных прав третьих лиц;
8.5.3. Исполнитель обладает всеми необходимыми правомочиями для передачи их Заказчику на условиях настоящего Договора.
8.6. Исполнитель обязуется возместить Заказчику убытки в полном объеме, в том случае, если к Заказчику будут предъявлен третьими лицами иск(и) в любой судебной инстанции, связанный с нарушением авторских или иных прав третьих лиц в связи с исполнением настоящего Договора, и решение судебной инстанции, вступившее в законную силу, удовлетворит вышеуказанный иск. В свою очередь Заказчик обязуется информировать Исполнителя о любых исках третьих лиц, предъявленных к нему в связи или на основании настоящего Договора.
8.7. В случае неисполнения Исполнителем своих обязательств по Договору, Заказчик оставляет за собой право организовать судебное разбирательство по данному вопросу. При этом данное судебное разбирательство должно происходить по месту жительства Заказчика.
8.8. Все изменения и дополнения к настоящему Договору производятся путем составления дополнительных двусторонних соглашений, которые подписываются Сторонами и являются неотъемлемыми частями настоящего Договора.
8.9. Каждая из Сторон обязуется письменно уведомить другую сторону об изменении своего местонахождения или банковских реквизитов не позднее 3-х дней после наступления изменений.
8.10. Исполнитель гарантирует работу программного обеспечения в соответствии с требованиями, изложенными в техническом задании (Приложение №1). Дальнейшая модификация и добавление функций и возможностей, не предусмотренных в техническом задании, являются предметом отдельного Договора.
9. РЕКВИЗИТЫ И ПОДПИСИ СТОРОН
ЗАКАЗЧИК ИСПОЛНИТЕЛЬ
_____________________
М.П.
___________________________
М.П.
Приложение 1. Техническое задание
на разработку программного средства «Программа контроля персонала»
1. Описание
2. Функции программного обеспечения
Приложение 1. Акт приема-передачи
Акт приема-передачи
(образец)
_______________________________________________________, именуемый в дальнейшем "Заказчик", с одной стороны действующего на основании Устава, с одной стороны, и Общество с ограниченной ответственностью «ИНЖЕНЕРНЫЕ СИСТЕМЫ», именуемое в дальнейшем Исполнитель в лице директора _________________________________, действующего на основании Устава, с другой стороны, а вместе именуемые "Стороны", составили настоящий Акт приема-передачи о нижеследующем:
I. … (Указывается вид работ)
1. Исполнитель передал … (указывается вид работ).
2. Заказчик принял … (указывается вид работ).
II. Работы по … (указывается вид работ) переданы Исполнителем Заказчику
1. В срок до «___» ____________ 2014 г. включительно.
2. Недостатков при приеме работ не выявлено.
III. Выявленные недостатки и сроки устранения
1. ________________________________________ – устранить в срок до«__»______2014г.
2. ________________________________________– устранить в срок до«__»______2014г.
3. ________________________________________– устранить в срок до«__»______2014г.
IV. Прочее
1. Заказчик принял работы по Этапу №… полностью, в объеме и качестве, оговоренном в Техническом задании к Договору.
2. Заказчик на основании Договора на разработку Программного обеспечения «Программа контроля персонала» от _______ обязуется оплатить стоимость работ Этапа №… в размере … рублей 00 коп (… рублей 00 коп.), в течение 3 (трех) рабочих дней с момента подписания данного Акта.
3. Стороны согласились, что после поступления денежных средств от Заказчика на расчетный счет Исполнителя все материальные и финансовые обязательства друг перед другом считаются выполненными и претензий по выполнению данного Этапа договора стороны не имеют.
Заказчик
Исполнитель
_____________________//
______________________/Рапан А.Н./
— С чего начинать, Ваше Величество? — спросил он.
— Начни с начала, — важно ответил Король,
— продолжай, пока не дойдешь до конца.
Как дойдешь — кончай!
(Льюис Кэрол.«Алиса в Стране чудес»)
2. Методы оценки проекта
Стандартные вопросы со стороны Заказчика:
- Что мы получим в результате?
- Сколько это будет стоить?
- Как быстро это будет сделано?
Согласитесь, вполне законныеи вполне резонныевопросы. Но вот дать ответы на эти вопросы… Это не так то просто, поскольку в каждом конкретном случае -C’estdepends, как говорят французы. Это зависит… от многих причин и обстоятельств. По сути дела, это ни что иное, как метрики данного конкретного проекта. Кто наперед может сказать нечто определённое? Для получения ответов на эти и сопряжённые с ними вопросы, к счастью, на основе существующего практического опыта выработан вполне определённый алгоритм последовательного приближения к решению этой непростой задачи.Эта последовательность разбивается на ряд формальных процедур. Итак, первая процедура – Техническое Задание.
2.1. Разработка и согласование технического задания (ТЗ)
ТЗ в основном выполняется совместно с Заказчиком, с учетом его требований и представляет собой набор функциональных и временных требований по выполнению проекта.
Как правило, выполняется Исполнителем и в обязательном порядке согласовывается и утверждается Заказчиком. См. п.2.2.
2.2. Техническое задание (ТЗ)
ТЗ это формальный документ,представляющий собой структурированный набор требований заказчика. Наиболее распространенная форма фиксации требований в СНГ – Техническое Задание (ТЗ). Этот термин в ИТ задан стандартом ГОСТ 34.602-89. Современным аналогом является стандарт IEEE Std 830 (http://shikardos.ru/text/standart-ieee-830-1998/).
Профессиональный термин – SRS – SoftwareRequirementSpecification, на нашем программистском сленге – просто «спецификации» или «спеки».
Основные характеристики ТЗ:
2
2.2. Техническое задание (ТЗ)
ТЗ это формальный документ,представляющий собой структурированный набор требований заказчика. Наиболее распространенная форма фиксации требований в СНГ – Техническое Задание (ТЗ). Этот термин в ИТ задан стандартом ГОСТ 34.602-89. Современным аналогом является стандарт IEEE Std 830 (http://shikardos.ru/text/standart-ieee-830-1998/).
Профессиональный термин – SRS – SoftwareRequirementSpecification, на нашем программистском сленге – просто «спецификации» или «спеки».
Основные характеристики ТЗ:
- текст структурирован и разбит на главы;
- все разделы пронумерованы – это дает возможность сослаться не только на конкретное требование, но и на каждый конкретный раздел в документе;
- не допускается использование фраз содержащих неточности или неоднозначное толкование;
- имеет графический контент - модели, рисунки, графики, схемы;
- имеет внутренние ссылки на другие разделы (например, см. п.2.6.);
- имеет раздел «История изменений»;
- имеет оглавление.
Для написания ТЗ рекомендуется использовать стандарт IEEE 830, раздел «Структура SRS» (Software Requirement Specification), включающий в себя (http://school.system-analysis.ru/wp-content/uploads/2014/09/IEEE-830-1998):
- введение;
- цели;
- соглашения о терминах;
- предполагаемая аудитория и последовательность восприятия;
- масштаб проекта;
- ссылки на источники;
- общее описание;
- видение продукта;
- функциональность продукта;
- классы и характеристики пользователей;
- среда функционирования продукта (операционная среда);
- ограничения, правила и стандарты;
- документация для пользователей;
- допущения и зависимости;
- функциональность системы;
- функциональный блок X (таких блоков может быть несколько);
- описание и приоритет;
- причинно-следственные связи, алгоритмы (движение процессов, workflows);
- функциональные требования;
- требования к внешним интерфейсам;
- интерфейсы пользователя (UX);
- программные интерфейсы;
- интерфейсы оборудования;
- интерфейсы связи и коммуникации;
- нефункциональные требования;
- требования к производительности;
- требования к сохранности (данных);
- критерии качества программного обеспечения;
- требования к безопасности системы;
- прочие требования;
Приложение 1. Глоссарий
Приложение 2. Модели процессов и предметной области и другие диаграммы
Приложение 3. Список ключевых задач
В настоящее время стало популярным фиксировать требования в виде wiki-сайтов, т.е. веб-сайта, структуру и содержимое которого пользователи могут самостоятельно изменять с помощью инструментов, предоставляемых самим сайтом. Форматирование текста и вставка различных объектов в текст производится с использованием вики-разметки. На базе этой технологии построена Википедия. На сегодняшний день самым популярным инструментом ведения документации в стиле wikiявляется Google Sites (https://sites.google.com/).
Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
Начинаем разбираться с метриками проекта.
- Во что это выльется по времени?
Некоторые инструменты:
2.3. Пользовательские сценарии (Use Cases)
Пользовательские сценарии построены на основе использования пользовательских историй (Story mapping), см. п.2.4.
2.4. Agile-методы или Пользовательские истории(Story mapping)
В современных подходах к управлению программными проектами – Agile/Scrum [98] – применяется развитие идеи пользовательских сценариев т.н. пользовательские истории (User Story). Пользовательские истории собираются в бэклог – Backlog.
User Stories
Суть записи пользовательских историй проста [98]. Вся функциональность программного продукта разбивается на отдельные (максимально независимые) кусочки. В Scrum их называют «кусочки требований» - piece of requirement. И каждый такой «кусочек» записывается в формате:
Я как [пользователь] хочу [действие], чтобы была [польза].
Пользователь – любой пользователь в системе. В несложных системах обычно вводят 3-5 типов пользователей.
Действие – описание функциональности.
Польза – что получает пользователь в результате этого действия. Здесь фиксируется некая бизнес-ценность – ради чего это действие требуется делать.
Примеры:
Описание функциональности
Пользовательские истории
Электронная библиотека
Я как читатель хочу видеть перечень книг упорядоченных по авторам, разделам
Система управления обучением.
Информирование участника тренинга о месте, дате и стоимости обучения.
Я как участник тренинга хочу получить письмо с расписанием занятий и банковские реквизиты на оплату обучения.
Подобный подход понятен бизнес-пользователям и может его структурировать в смысле управления требованиями со стороны пользователей. Пользовательские истории традиционно фиксировались в Scrum в виде карточек или стикеров. Такие карточки называются «пользовательские карточки» – User Card.
Однако такой формат хоть и удобен для команд, которые находятся в одном помещении,он не применим для распределенных команд. В этом случае используются online инструменты.
Самые популярные:
- Jira&Confluence – от компании Attlassian.
- Google Docs + Spreedsheet
- MS Excel
- Backlog
Все пользовательские истории собираются в бэклог.
Примеры бэклога:
Каждая пользовательская история в бэклоге должна содержать:
- описание
- приоритет – обычно, чем выше висит карточка с историей – тем выше приоритет
- объем – оценка этого требования
- релиз/итерация – когда по плану предполагается разработка истории
Последние два требования появляются после планирования проекта.
После того как в проекте получено структурированное дерево работ (СДР, WBS – work break downstructure), следует перейти к оценке пакетов работ.
При этом разделяют оценку:
- требований;
- трудозатрат;
- ресурсов;
- бюджета.
Оценка проекта проходит в следующем порядке:
↓
↓
↓
↓
↓
Различные методы и подходы используются для оценки: объема функциональности, размера проекта, сроков, объема работ. При этом некоторые подходы лучше применимы к большим (Б) проектам, а некоторые только к средним (С) и малым (М).
В таблице ниже представлены методы оценки, используемые в программных проектах, и их применимость:
Функциональные точки
Story Points
Метод футболки
Метод аналогий
Экспертная оценка
Метод Дельфи
Что оценивается
Размер, объем работ, сроки, функциональность
Размер, объем работ, сроки, функциональность
Размер проекта
М С Б
- С Б
Стадия разработки
Ранняя-средняя
Ранняя
Итеративный или последовательный подход
Оба
Оба
Возможная точность
Средняя-высокая
-
Метод функциональных точек
Метод функциональных точек (Functional Points),с одной стороны, очень прост; с другой стороны, его сложно применить в современных проектах.
(http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml)
Function Points – это единица измерения размера программных систем.FunctionPointAnalysis (FPA) – метод определения размера программных систем (приложений) и проектов по их разработке. Размер приложения определяется с точки зрения функциональности, т.е. с точки зрения пользователя. Данный метод используется довольно редко ввиду того, что для его использования требуется полностью разработанный пользовательский интерфейс системы еще до начала разработки. С появлением Agile-подходов полная проработка интерфейсов и дизайна системы до начала разработки не делается – в результате этот метод используется редко.
Метод Story Points
Точного перевода StoryPoint до сих пор не предложено. У Стива Макконелла(SteveMcConnell - CodeComplete, SecondEdition,2004) данный метод называется "метод абстрактных рейтингов".
Впервые этот метод оценки применялся в экстремальном программировании, но позже нашел широкое применение в оценке пользовательских историй в Scrum.
При использовании метода абстрактных рейтингов группа оценщиков просматривает список пользовательских историй (или требований), которые они предполагают реализовать. При этом присваивает каждой истории некоторый размер, измеряемый в пунктах (points), или единицах сложности. При этом историям назначаются значения по одной из числовых последовательностей, представленных в таблице:
Шкала
Степени 2
1, 2, 4, 8, 16
Числа Фибоначчи
1, 2, 3, 5, 8, 13, 21
Шкала М.Конна
0, ½, 1, 2, 3, 5, 10, 20, 40, 100,
Процесс оценки проходит следующим образом:
- Все требования записываются в виде функционального листа (Feature List);
- Выбирается самая малая история за эталон единицы сложности – один пункт;
-Все истории сравниваются с эталоном и друг с другом;
- Все оценки историй складываются.
В результате получается оценка проекта в абстрактных единицах сложности.
История
Пункты
История 1
История 2
История 3
…
История 50
2
1
4
16
Итого:
180
На этой стадии пункты не принесут никакой информации, потому как являются абстрактными единицами сложности – они не преобразуются в человеко-часы, календарное время и т.д. Т.е. не дают никакой информации для принятия решений менеджером проекта.
Почему такой формат используется?:
Оценивать требования в часах (или, иначе говоря, в трудозатратах) не совсем верно. Трудозатраты могут меняться исходя из производительности программиста, который будет выполнять задачу.
Этот метод довольно прост и он не дает грубых ошибок.
После проведения первичных оценок команда планирует первую итерацию, включая в нее ряд историй, т.е. планируя завершить некоторое количество абстрактных пунктов. В основу этого плана может быть заложено предположение, что один пункт равен восьми или шести человеко-часам трудозатрат, но на этом этапе это всего лишь предположение.
После завершения первой итерации у команды появляется возможность более определенно составлять дальнейшую оценку проекта. Команда видит, какие истории были завершены, сколько пунктов было выполнено, и на основе полученной информации может строить дальнейшую оценку.
Данные итерации №1
Реализовано историй на 27 SP (StoryPoint)
Затрачено 12 человеко-недель
Затрачено 3 календарные недели
Предварительная калибровка
Объем работ = 27 SP / 12 человеко-недель = 2,25 SP/человеко-неделю
Сроки = 27 SP / 3 календарные недели = 9 SP/календарную неделю
На основе этой калибровки руководитель проекта составляет оценку оставшейся части проекта. Пример – в следующей таблице.
Данные итерации №1
Предположения (из предварительной калибровки)
Объем работ = 2,25 SP/человеко-неделя
Сроки = 9 SP/календарную неделю
Размер проекта = 180 SP
Предварительная оценка для всего проекта
Объем работ = 180 SP / 2,25 SP/человеко-неделя = 80 человеко-недель
Сроки = 180 SP / 9 SP/календарную неделю = 20 календарных недель
Исходная оценка будет уточняться по данным из следующих итераций и обычно находят какое-то среднее значение производительности команды. При этом, чем короче итерации, тем быстрее у вас будут появляться данные для оценки и тем точнее будет становиться оценка проекта.
Метод футболки
Часто на ранних этапах проекта участникам проекта требуется решить, какую функциональность предстоит делать в проекте (http://cribs.me/upravlenie-proektami/metody-upravleniya-proektami).И при этом бизнес-заказчикам требуется принять решения, не обладая информацией о реальной сложности той или иной функциональности продукта. Действительно, они задаются вопросом: - "Как я могу понять, нужна мне эта функциональность или нет, если я не знаю, сколько она будет стоить?!" На что разработчик возразит: "Я не могу оценить стоимость, пока не получу более подробные требования". Ситуация заходит в тупик.Вспомним, что хорошая оценка – это та оценка, которая позволяет принимать решения для управления проектом. Для этого используется так называемый метод футболки.(см. также: А.Полковников, М.Дубовик. Управление проектами. Полный курс МВА).
В этом методе разработчики классифицируют все отдельные функции по отношению к другим как малые (S), средние (M), большие (L) и очень большие (XL). Параллельно бизнес-заказчики классифицируют бизнес-ценность данной функциональности, пользуясь такой же шкалой. Затем два набора оценок объединяются и сравниваются.
Именно за размеры S, M, L, XL данный метод и называется методом футболки – используются размеры футболок.
Функция
Коммерческая ценность
Затраты на разработку
Функция 1
X
M
Функция 2
S
X
Функция 3
X
X
Функция 4
XL
M
Функция 5
M
XL
…
Функция 60
M
S
Для принятия решения достаточно сравнить два столбца. Даже в таком виде таблица позволяет принимать решения: "Данная функция требует больших затрат на разработку, но обладает низкой ценностью для бизнеса – от нее лучше отказаться". Если вы исключаете работу над функцией уже на этом этапе, вы экономите не только на разработке, но и на выявлении требований, постановке задачи, управлении проектом и т.д.
Что стоит сохранить, а что выбросить? Обсуждать эту тему будет проще, если задать для размеров футболки веса и проанализировать данные по соотношению затраты/выигрыш, используя следующую таблицу.
Коммерческая ценность
Затраты на разработку
XL
X
M
S
XL
0
4
6
7
X
-4
0
2
3
M
-6
-2
0
1
S
-7
-3
-1
0
Наличие подобной таблицы дает возможность добавить 3-й столбец в изначальную оценку и показать соотношение затрат/выгоды в числовом выражении и поставить разумный приоритет.
Функция
Коммерческая ценность
Затраты на разработку
Решение
Функция 1
X
M
2
Функция 2
S
X
-3
Функция 3
X
X
0
Функция 4
XL
M
6
Функция 5
M
XL
-6
…
Функция 60
M
S
1
Данную цифру не стоит воспринимать слишком серьезно и проводить черту, ниже которой функциональность не будет даже обсуждаться. Данный метод, прежде всего, позволяет расставить приоритеты и дать определенное "да" для функций в верхней части списка.
Этот метод обычно используется для обсуждения функциональности с заказчиком проекта.
Несколько советов оценщикам:
- Всегда давайте оценку с адекватным уровнем точности. Используйте вилку оценок (от – до).
- Оценивайте не объем документации, а реальную функциональность. Сведите документацию в FeatureList.
- Фильтруйте информацию, не допускайте к оценке слишком много информации.
- Не сообщайте экспертам ваши соображения насчет размера и длительности оцениваемого проекта. Не влияйте на их ход рассуждений.
- Никогда не давайте спонтанных оценок. Возьмите 15 минут на "подумать".
- Даже 15 минут хватает, чтобы дать более детальную оценку.
Сбор метрических данных
Определяйте размер каждого проекта.
Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
2.5. Концептуальное единство
– Ты что, не знаешь, что такое «это»?
– Я прекрасно знаю, что такое «это»,
когда я его нахожу.
(Льюис Кэрол.«Алиса в Стране чудес»)
Концептуальное единство либо разобщенность лучше всего просматривается в архитектуре [10].(См. также: http://webkomora.com.ua/ru/articles/web/management/man-month/145.html).
У большинства европейских соборов части, построенные разными поколениями строителей, имеют различия в планировке и архитектурном стиле, пишет Брукс. Более поздние строители испытывали соблазн «улучшить» проект своих предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В результате общий вид собора создает впечатление перегруженности и неискренности. Архитектурное единство Рейнского собора находится в прямой противоположности с таким смешением стилей. Его гармоничность и чистота стиля явились результатом того, что восемь поколений строителей смиряли свою гордыню в пользу сохранения концепции собора.
Хотя программные системы не создают восемь поколений разработчиков, в большинстве своем они демонстрируют меньшую согласованность концепций, чем в любом соборе. Обычно это происходит не оттого, что главные проектировщики сменяют друг друга, а потому, что проект расщепляется на ряд задач, выполняемых разными разработчиками.
Концептуальная целостность является важнейшей характеристикой большого системного проекта. Концептуально целостная система быстрее разрабатывается и быстрее отлаживается. Поэтому, если есть важная идея, не вписывающаяся в основные концепции, то ее лучше оставить в стороне, полагает Брукс [10].
Поскольку целью проектирования является простота использования, окончательную оценку проекта дает достигнутое отношение функциональности к сложности концепций. Ни функциональность, ни простота в отдельности не являются признаками хорошего проекта. Важна простота и непосредственность.И то, и другое вытекает из концептуальной целостности.
Архитектура – это полная и подробная спецификация интерфейса пользователя. Архитектор является представителем пользователя, а не продавца или разработчика. Для того чтобы добиться концептуальной целостности, архитектура и разработка должны быть разделены. Архитектура говорит, что должно произойти, а разработка – как сделать, чтобы это произошло, т.е. предусматривает реализацию.
Второй закон Брукса[10]: Архитектура системы должна исходить из одной головы.
Естественно, эта голова должна прислушиваться ко всем мнениям, но оставлять только то, что вписывается в первоначальную концепцию, уверен Брукс (Frederick P.Brooks, TheMythicalMan-Month). Могут возникнуть возражения: не захватят ли архитекторы всю творческую деятельность, сделав исполнителей лишь зубчиками в механизме? Не окажется ли, что более совершенный продукт можно получить, используя идеи всей бригады?
В действительности, разработка проекта требует не меньше творчества, новых идей, изобретательности, чем создание архитектуры. Это просто другая работа.
Практический опыт говорит о том, что дисциплина идет на пользу. В проектах, где проектирование архитектуры и разработка тщательно разделены, исполнители сразу сосредотачиваются на своей части задачи, в результате чего изобретательность бьет ключом. В ничем не ограничиваемой группе большая часть обдумывания и обсуждения посвящена архитектурным решениям в ущерб реализации. «Форма освобождает» – говорят художники.
Если Вы хотите, чтобы система обладала концептуальной целостностью, то управлением концепциями должен заниматься кто-то один.
Примеры концептуально целостных систем: UNIX, APL, Pascal, Modula, SmallTalk, Fortran, Microsoft Windows NT, Microsoft Excel, Apple iOS.
Отрицательные примеры: Cobol, PL/I, Algol, MVS/370, MS-DOS, Microsoft Windows 95, Microsoft Word.
3
Когда руководитель проекта делает свою первую систему, проект стремится к скромности и ясности, продолжает Брукс. При работе ему постоянно приходят в голову то одни, то другие «украшения». Они откладываются в сторону для использования «в следующий раз». После того, как система закончена, архитектор с твердой уверенностью в себе готов к созданию нового проекта.
Эта вторая система является наиболее опасной для проектировщика. При работе над третьей и последующими системами он уже приобретет необходимый опыт. Разрабатывая вторую систему, проектировщик стремится реализовать все идеи и украшательства, отложенные в сторону при работе над первым проектом, свидетельствует Брукс. В результате получается «большая куча», из которой используется едва ли половина возможностей. Примерами могут служить Windows 95 и MS Exchange.
Третий закон Брукса: для руководителя проекта система не должна быть «второй», а если это случилось, то и ему самому, и его окружению необходимо максимально снизить соответствующие риски.
Упрощение концептуальной сложности
До самого красивого никогда не дотянешься.
(Льюис Кэрол.«Алиса в Стране чудес»)
Всемирно известный специалист в области программирования Э.Дейкстра как-то заметил (Edsger Dijkstra, «A discipline of programming», 1-е изд. — М.: Мир, 1978), что «программирование сложно не только из-за больших задач, но и из-за наших маленьких голов».
Как определить, сколько времени потребует задача системного программирования? Прежде всего, нужно учесть, что оценки, полученные при создании отдельных небольших программ, нельзя применять для больших системных продуктов. Даже для небольших программ увеличение размера программы вдвое приводит к увеличению затрат и времени в четыре, а то и в шесть раз. А ведь для больших проектов нужно еще добавить затраты на планирование, составление документации, тестирование, системную интеграцию и обучение. Линейная экстраполяция бессмысленна. Это все равно, что экстраполировать время, за которое возможно пробежать стометровку, и получить, что можно пробежать три километра за пять с половиной минут.
Исследования показывают, что объем работы в больших проектах растет как степенная функция с показателем степени приблизительно 1,5:
Объем работы = (константа) ´ (число командных строк)1,5
Из этой формулы следует, что производительность программиста, измеренная в элементарных операциях, постоянна. Известно также, что число ошибок прямо пропорционально числу командных строк. Следовательно, необходимо выбирать язык программирования как можно более высокого уровня. Статистические данные говорят о том, что при использовании подходящего языка высокого уровня производительность кодирования можно повысить в пять раз.
Программа не перестает изменяться после своей поставки клиенту. Сопровождение и развитие программных систем состоит главным образом из изменений, исправляющих конструктивные дефекты. Очень часто эти изменения включают в себя дополнительные функции, которые видны пользователю.
Общая стоимость сопровождения широко используемой программы, даже если она достаточно стабильна (как, например, системные программы), обычно составляет 40 и более процентов стоимости ее разработки. В случае ПО для бизнеса стоимость сопровождения и развития ПО близка к 100%. На стоимость сопровождения сильно влияет число пользователей, чем больше пользователей, тем больше ошибок они находят.
Главная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, шаг назад».
Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. С течением времени все меньше сил тратится на исправление ошибок исходного проекта и все больше – на ликвидацию последствий предыдущих исправлений. Исследования показали, что начиная с какого-то момента, число ошибок в программе перестает снижаться. Кроме того, меняются машины, конфигурации, требования пользователя, так что фактически ни одна система не может оставаться вечной. Становится необходим новый проект, выполненный с нуля.
Правила системной отладки:
Используйте отлаженные компоненты.
Создайте и используйте больше инструментов среды разработки: отладочных тестов, программ, заглушек, генераторов тестовых данных.
Ведите жесткий контроль над изменениями.
При сборке добавляйте компоненты по одному.
При сопровождении уже установленного продукта делайте изменения большими порциями, чтобы периоды стабильности продолжались дольше.
«Серебряной пули» нет
План, что и говорить, был превосходный:
простой и ясный, лучше не придумать.
Недостаток у него был только один:
было совершенно неизвестно,
как привести его в исполнение.
(Льюис Кэрол.«Алиса в Стране чудес»)
Этот доклад Ф. Брукса на конференции 1986 г. в Дублине вызвал большой резонанс(Frederick P.Brooks, TheMythicalMan-Month). Речь идет о методах борьбы с концептуальной сложностью.
Хорошо знакомый программный проект весьма напоминает оборотней из фильма ужасов, считает Брукс. Будучи простым и невинным на вид, он может стать чудищем проваленных графиков работы, раздувшихся бюджетов и неработающих продуктов. Мы ищем серебряную пулю, которая могла бы волшебным образом уложить оборотней наповал. Нечто, способное снизить стоимость программных продуктов так же резко, как снизилась стоимость компьютеров.
Брукс утверждал, что в ближайшее десятилетие после этого доклада (1986 г.) не будет сделано открытий ни в технологии, ни в методах управления, использование которых обещало бы хоть на порядок повысить производительность, надежность и простоту программного обеспечения.
С тех пор прошло почти 30 лет, а его предсказание все еще остается в силе. Панацеи вроде объектно-ориентированного программирования, систем искусственного интеллекта и экспертных систем себя не оправдали. «Серебряной пули» нет, и она вряд ли скоро появится. В качестве панацеи сейчас продвигается идея «облака», однако и она ликвидирует концептуальную сложность лишь частично.
Впрочем, скептицизм – не пессимизм! И хотя Брукс совершенно справедливо считает ошеломляющие прорывы не свойственными самой природе программирования, он указывает на многие перспективные нововведения, дисциплинированное и последовательное внедрение которых действительно может дать многократный рост:
Покупать, а не создавать.
Развитие массового рынка позволяет избежать создания того, что можно купить. Любой «коробочный» продукт намного дешевле купить, чем создавать заново. Кроме того, массовый рынок и распространение программных пакетов привели к появлению метапрограммирования – создания нового слоя ПО, приспосабливающего функции к нуждам определенной группы пользователей пакета (например, внутренний язык программирования в 1С Предприятие). Метапрограммирование значительно повышает производительность программиста.
Уточнение требований и быстрое прототипирование
- как часть запланированных итераций для установления требований к ПО. Это направление предусматривает быстрое создание макета системы, который моделирует главные интерфейсы и выполняет основные функции предполагаемой системы. Назначение макета – показать, как воплощается выбранная концептуальная структура, чтобы клиент мог проверить ее пригодность к использованию и непротиворечивость.
Пошаговая разработка.
Следует органично наращивать (выращивать) программы, а не строить сразу. Сначала систему надо заставить просто выполняться, даже если при этом она не делает ничего полезного, кроме вызова некоторых фиктивных подпрограмм. Затем нужно добавлять к системе все большую функциональность по ходу ее разработки, внедрения и эксплуатации, причем делать это параллельно с тестированием.
Выращивание выдающихся проектировщиков.
Хорошим практическим приемом можно обучить, однако создание программ является творческим процессом. Выдающиеся проекты создаются выдающимися проектировщиками. Поэтому каждая организация, занятая в программировании, должна как можно раньше выявлять и растить выдающихся разработчиков концепций нового поколения.
Стратегия открытых исходных текстов как альтернатива концепции Брукса
Э. Раймонд в своей статье «Собор и базар» (http://project.dovidnyk.info/index.php/programnye- proekty/upravlenieproektamiposozdaniyuprogrammnogoobespecheniya) попытался опровергнуть Брукса, утверждая, якобы стратегия открытых исходных текстов OpenSource, при помощи которой был разработан Linux, полностью опровергает основные положения книги Брукса.
Однако профессор университета в Нью-Джерси Николай Безруков (автор некогда знаменитой «Вирусологии» – первой книги о вирусах на русском языке) в своей статье http://www.linux.org.ru/books/GNU/misc/second-look-at-CatB.htmlойопроверг Э.Раймонда по всем пунктам.
Во-первых, в случае Linux речь идет о переписывании уже существующей системы, когда всем известно, что в точности система делает и из каких модулей должна состоять, отмечает Безруков. При ее разработке не требовалось вырабатывать концепции, создавать спецификации и заниматься проектированием.
Во-вторых, никакой демократии в OpenSource нет и в помине. Дисциплина там очень жесткая. Ее осуществляют высшие модераторы по своему произволу, давая дорогу модулям, разработанным одними разработчиками, и отбрасывая модули, разработанные другими. Занимался этим и Линус Торвальдс – главный модератор проекта Linux.
Лучшее качество программ OpenSource или GNU из-за их всеобщей доступности – это тоже миф, ибо никто не ставит цель выявить в них ошибки. Кроме того, пока еще никем не доказано, что самодеятельное тестирование лучше профессионального. На самом деле серьезных ошибок в Linux и «дыр» в ее безопасности предостаточно, просто никто не пытается их искать с той же тщательностью, с какой их ищут в продуктах корпорации Microsoft, Apple или Google.
2.6. Оценка трудоемкости
Планирование – это самый ответственный для менеджера момент. По Ф.Бруксу, неумение правильно оценить объем проекта является главной причиной срыва сроков разработки.
Для оценки трудоемкости необходимо:
Оценить объем продукта.
Оценить усилия разработчиков, необходимые для создания продукта.
Оценить график работ по проекту.
Оценить финансовые затраты.
Пример истории создания Microsoft Word 1.0 – отличная иллюстрация классической ошибки надежды на то, что все пойдет хорошо (wishfulthinking). Эта ошибка характерна как для тех заказчиков и руководителей разработчиков высшего уровня, которые свято верят, что любая работа может быть выполнена за любое время, стоит только того пожелать.
В 1984 году Билл Гейтс, впечатленный успехами первых текстовых редакторов, приказал дословно «создать лучший в мире текстовый редактор за 12 месяцев». Как выяснилось впоследствии, для подобного проекта, который в результате занял 250000 строк, по нормам необходимо 26 месяцев. Даже если сильно сжать сроки, все равно проект никак нельзя было сделать менее чем за 22 месяца. В результате вышло следующее.
Изотчета Microsoft Corporation: Office Business Unit, 1994
Месяц составления плана
Планируемый срок поставки
Планируемое число дней до поставки
Фактическое число дней до поставки
Относительная ошибка планирования
09.84
09.85
365
1887
81%
06.85
07.86
395
1614
76%
01.86
11.86
304
1400
78%
06.86
05.87
334
1245
73%
01.87
12.87
334
1035
68%
06.87
02.88
245
884
72%
01.88
06.88
152
670
77%
06.88
10.88
122
518
76%
08.88
01.89
153
457
67%
10.88
02.89
123
396
69%
01.89
05.89
120
304
61%
06.89
09.89
92
153
40%
07.89
10.89
92
123
25%
08.89
11.89
92
92
0%
Дело не только в том, что из-за неправильного планирования первая версия текстового редактора Microsoft Word создавалась 5 лет. Именно неверное планирование работ и попытки выполнить работу в нереальный срок привели к тому, что MS Word до сих пор является чрезвычайно громоздким продуктом со значительным количеством ошибок. Он потребляет для своей работы значительные ресурсы компьютера и резко замедляет работу при редактировании даже не очень длинных документов. Его менее именитые конкуренты куда изящнее, компактнее, мощнее и эффективнее, как, впрочем, и другие продукты, входящие в Microsoft Office. Например, Microsoft Excel является весьма удачным продуктом.
2.7. Типовые причины оптимистических планов
Существуют внешние причины, определяющие срок выполнения проекта: компьютерные выставки, изменения в законодательстве, распродажи.
Менеджеры или заказчики строят планы для случая, если все пойдет хорошо.
Необходимо заключить важный договор с заказчиком.
Разработчики хотят поучаствовать в интересном для них проекте.
Менеджер проекта считает, что под прессингом программисты будут работать лучше.
Давление внешнего заказчика, руководства или службы маркетинга.
Плохая оценка сроков.
Удивительно, что реалистические оценки сроков вообще появляются. Обычно программисты недооценивают свои проекты на 20-30%.
Как же ускорить разработку? Оказывается, чаще всего для быстрой разработки достаточно лишь правильно организовать работу. Быстрая разработка и эффективная разработка – это синонимы.
2.8. Оценка объема работ по функциональным баллам
Функциональные баллы – это специальная величина, которая используется для оценки размера программы. Функциональные баллы легче использовать, чем количество строк или слов программы, и они дают более точную оценку размера программы.
Количество функциональных баллов зависит от следующих величин:
- число входных форм. Сюда входят диалоги, формы, сообщения, посредством которых конечный пользователь или другие программы могут добавлять, удалять или изменять данные программы.
- число выходных форм – экраны, отчеты, графики или сообщения, которые генерирует программа для использования конечным пользователем или другими программами.
- число запросов. Количество комбинаций «ввод/вывод», когда ввод имеет своим результатом немедленный вывод.
- логические внутренние файлы – логические группы данных, которые полностью контролируются программой. Это может быть простой файл или таблица в реляционной базе данных.
- внешние файлы – данные, контролируемые другими программами. Включают любые логические группы данных, которые вводятся или выводятся из программы.
В табл. 2.1. приведено, каким образом может быть подсчитано количество функциональных баллов в программе. Множители взяты на основе данных нескольких тысяч проектов.
Характеристика программы
Низкая сложность
Средняя сложность
Высокая сложность
Число входных форм
´3
´4
´6
Число выходных форм
´4
´5
´7
Число запросов
´3
´4
´6
Логические внутренние файлы
´7
´10
´15
Внешние файлы (интерфейс)
´5
´7
´10
2.6. Оценка трудоемкости
Планирование – это самый ответственный для менеджера момент. По Ф.Бруксу, неумение правильно оценить объем проекта является главной причиной срыва сроков разработки.
Для оценки трудоемкости необходимо:
1. Оценить объем продукта.
2. Оценить усилия разработчиков, необходимые для создания продукта.
3. Оценить график работ по проекту.
4. Оценить финансовые затраты.
Пример истории создания Microsoft Word 1.0 – отличная иллюстрация классической ошибки надежды на то, что все пойдет хорошо (wishfulthinking). Эта ошибка характерна как для тех заказчиков и руководителей разработчиков высшего уровня, которые свято верят, что любая работа может быть выполнена за любое время, стоит только того пожелать.
В 1984 году Билл Гейтс, впечатленный успехами первых текстовых редакторов, приказал дословно «создать лучший в мире текстовый редактор за 12 месяцев». Как выяснилось впоследствии, для подобного проекта, который в результате занял 250000 строк, по нормам необходимо 26 месяцев. Даже если сильно сжать сроки, все равно проект никак нельзя было сделать менее чем за 22 месяца. В результате вышло следующее.
Из отчета Microsoft Corporation: Office Business Unit, 1994
Месяц составления плана
Планируемый срок поставки
Планируемое число дней до поставки
Фактическое число дней до поставки
Относительная ошибка планирования
09.84
09.85
365
1887
81%
06.85
07.86
395
1614
76%
01.86
11.86
304
1400
78%
06.86
05.87
334
1245
73%
01.87
12.87
334
1035
68%
06.87
02.88
245
884
72%
01.88
06.88
152
670
77%
06.88
10.88
122
518
76%
08.88
01.89
153
457
67%
10.88
02.89
123
396
69%
01.89
05.89
120
304
61%
06.89
09.89
92
153
40%
07.89
10.89
92
123
25%
08.89
11.89
92
92
0%
Дело не только в том, что из-за неправильного планирования первая версия текстового редактора Microsoft Word создавалась 5 лет. Именно неверное планирование работ и попытки выполнить работу в нереальный срок привели к тому, что MS Word до сих пор является чрезвычайно громоздким продуктом со значительным количеством ошибок. Он потребляет для своей работы значительные ресурсы компьютера и резко замедляет работу при редактировании даже не очень длинных документов. Его менее именитые конкуренты куда изящнее, компактнее, мощнее и эффективнее, как, впрочем, и другие продукты, входящие в Microsoft Office. Например, Microsoft Excel является весьма удачным продуктом.
2.7. Типовые причины оптимистических планов
1. Существуют внешние причины, определяющие срок выполнения проекта: компьютерные выставки, изменения в законодательстве, распродажи.
2. Менеджеры или заказчики строят планы для случая, если все пойдет хорошо.
3. Необходимо заключить важный договор с заказчиком.
4. Разработчики хотят поучаствовать в интересном для них проекте.
5. Менеджер проекта считает, что под прессингом программисты будут работать лучше.
6. Давление внешнего заказчика, руководства или службы маркетинга.
7. Плохая оценка сроков.
Удивительно, что реалистические оценки сроков вообще появляются. Обычно программисты недооценивают свои проекты на 20-30%.
Как же ускорить разработку? Оказывается, чаще всего для быстрой разработки достаточно лишь правильно организовать работу. Быстрая разработка и эффективная разработка – это синонимы.
2.8. Оценка объема работ по функциональным баллам
Функциональные баллы – это специальная величина, которая используется для оценки размера программы. Функциональные баллы легче использовать, чем количество строк или слов программы, и они дают более точную оценку размера программы.
Количество функциональных баллов зависит от следующих величин:
- число входных форм. Сюда входят диалоги, формы, сообщения, посредством которых конечный пользователь или другие программы могут добавлять, удалять или изменять данные программы.
- число выходных форм – экраны, отчеты, графики или сообщения, которые генерирует программа для использования конечным пользователем или другими программами.
- число запросов. Количество комбинаций «ввод/вывод», когда ввод имеет своим результатом немедленный вывод.
- логические внутренние файлы – логические группы данных, которые полностью контролируются программой. Это может быть простой файл или таблица в реляционной базе данных.
- внешние файлы – данные, контролируемые другими программами. Включают любые логические группы данных, которые вводятся или выводятся из программы.
В табл. 2.1. приведено, каким образом может быть подсчитано количество функциональных баллов в программе. Множители взяты на основе данных нескольких тысяч проектов.
Характеристика программы
Низкая сложность
Средняя сложность
Высокая сложность
Число входных форм
´3
´4
´6
Число выходных форм
´4
´5
´7
Число запросов
´3
´4
´6
Логические внутренние файлы
´7
´10
´15
Внешние файлы (интерфейс)
´5
´7
´10
Таблица 2.1. Множители для вычисления функциональных баллов
После умножения числа входных и выходных форм, запросов, внутренних и внешних файлов на соответствующие коэффициенты и суммирования этих чисел мы получим количество функциональных баллов. Однако для получения окончательного ответа это число необходимо умножить на дополнительный коэффициент сложности (передача данных, сложность обработки и внедрения), колеблющийся от 0,65 до 1,35.
Пример. Небольшой проект в средней организации: число входных форм – 6, выходных форм – 7, запросов – 0, внутренних файлов – 5, внешних файлов – 9 оценивается в 304 балла. Дополнительный коэффициент примем равным 1.15, тогда окончательное количество баллов – 350.
Срок выполнения проекта в месяцах определяется по формуле
Срок = Баллы 0.44
0.44 – это усредненный показатель. На практике он может колебаться в пределах 0.39–0.48.
Уточнение показателей степеней CapersJones для оценки сроков выполнения проекта, исходя из функциональных баллов, приведено в следующей таблице.
Уточнение показателей степеней CapersJones
Тип программного обеспечения
Характеристика организации в своем классе
Лучшая
Средняя
Худшая
Системное
0.43
0.45
0.48
Бизнес-приложения, программы для использования внутри организации
0.41
0.43
0.46
Коробочный тиражируемый продукт
0.39
0.42
0.45
Пример. Если проект оценивается в 350 баллов и речь идет о разработке коробочного продукта в средней организации своего класса, то проект займет 350 0,42 = 12 календарных месяцев. Если такой же продукт разрабатывается в лучшей в своем классе организации, то сроки оцениваются в 350 0,39 = 10 месяцев.
2.9. Оценка длительности проекта по трудоемкости
Зависимость длительности проекта от его трудоемкости определяется следующим соотношением:
(Длительность проекта в месяцах) = 3.0 * (Человеко-месяцы)1/3
Опытные специалисты рекомендуют прибавлять к этой оценке еще 30 процентов, а также использовать коэффициенты от 2.5 до 4.0 вместо 3.0. Для правильного подбора коэффициентов необходимо использовать исторические данные организации.
Исходя из этих данных, можно определить число разработчиков:
(Число разработчиков) = (Человеко-месяцы) / (Длительность проекта в месяцах).
Пример. Если известна трудоемкость проекта – 64 человека-месяца, то срок разработки составит 12–16 месяцев и для нее необходимо привлечь 5–6 разработчиков.
2.10. Оценка, основанная на рисках
Пример. Допустим, рассчитанная продолжительность проекта составляет 6 месяцев.
Рассмотрим возможные риски и оценим их влияние на срок выполнения проекта.
Отрицательные факторы:
+1 месяц из-за запоздания поставки графического интерфейса;
+1 месяц из-за неработоспособности средства разработки;
+0,5 месяца по болезни персонала;
+0,5 месяца из-за недооценки размеров проекта;
Итого: +3 месяца.
Положительные факторы:
–1 месяц из-за меньшей, чем ожидалось, задержки найма новых работников;
–1 месяц из-за того, что новые средства разработки работают лучше, чем ожидалось;
Итого: –2 месяца.
Итоговая оценка: 6 месяцев +3/-2 месяцев.
Подобная оценка дает заказчику конкретную информацию о возможных рисках, а также позволяет управлять ими на ранних стадиях проекта.
2.11. Оценка рисков по возможным сценариям
Вариант оценки, основанной на рисках.
Согласно этому методу необходимо оценить сроки проекта для наилучшего, наихудшего, запланированного и текущего сценариев. Представляют интерес взаимозависимости между этими оценками. Если, к примеру, сроки для запланированного и наилучшего сценариев совпадают, а также совпадают сроки для текущего и наихудшего сценариев, то проект в опасности. Следующая таблица показывает пример оценок для проекта, у которого пока нет серьезных проблем.
Не самый худший проект:
Тип сценария
Оценка
Лучший
1 апреля
Плановый
15 мая
Текущий
30 мая
Худший
15 июля
2.12. Оценка по вероятности
Один из вопросов, которые часто задают люди о рабочем графике, звучит примерно так: «Какова вероятность, что проект будет завершен к этой дате?» Используя оценку сроков проекта, основанную на вероятности, разработчики могут ответить на этот вопрос на основе взвешенных оценок, см. на примере данных, представленных в таблице:
Вероятностная оценка даты завершения проекта
Дата готовности
Вероятность завершения до указанной даты
1 апреля
5%
1 мая
50%
1 июня
95%
2.13. Общие рекомендации по оценке сроков
1. Указанные измерения по мере разработки проекта необходимо периодически повторять с целью уточнения.
2. Найдите время для оценки сроков проекта, запланируйте его. Используйте данные из предыдущих проектов. Пусть оценивают не те, кто будет делать работу, а другие программисты. И учтите, что их оценка занижена на 20–30%.
3. Чтобы оценка получилась объективной, она должна быть коллективной. Оценивайте проект по деталям, а затем суммируйте полученное время. При суммировании ошибки взаимно гасятся, и суммарная оценка погрешности уменьшается.
4. Функциональность системного продукта и время его разработки зависят от числа входных и выходных форм, запросов, внутренних и внешних файлов.
5. Не забывайте, что обычные рутинные задачи – конвертирование данных, инсталляция, настройка, управление бета-тестированием, создание демо-версии, необходимость присутствия на совещаниях, сопровождение старого ПО, контроль качества, исправления, оформление документации, отпуска, праздники, болезни, производственные мероприятия, обучение – также требуют времени.
6. Ведите исторические записи. Приобретите и используйте специализированное программное обеспечение для оценки объема работ.
7. Для получения более точных оценок необходимо использовать несколько различных способов, чтобы вывести усредненный результат. Усреднять можно способами, известными из статистики: получение среднего, среднегеометрического, среднего с отбрасыванием крайних значений-выбросов, без него и т.п.
8. При согласовании графика постарайтесь найти возможность, чтобы все участники проекта были довольны. Не становитесь в позу.
9. Не пытайтесь выжать из людей больше чем можно. Существует определенный уровень стресса, при превышении которого положительное влияние стресса сменяется отрицательным. Чем сильнее давление графика, тем больше стресс, тем больше допускается ошибок и тем больше приходится исправлять работу. Это, в свою очередь, ведет к еще большему стрессу. Возникает опасная положительная обратная связь, неизбежно ведущая к срыву графика.
2.14. Практические советы
1. Отделяйте людей от проблемы. Менеджеры часто вынуждены давать нереальные сроки из-за внешнего давления или по незнанию. Не реагируйте на эмоции, выработайте совместное решение.
2. Сосредоточьтесь на интересах, а не на позициях. Ссылайтесь на объективные обстоятельства, увеличение шансов на успех, привлеките истории других проектов.
3. Каждому проекту нужна какая-то церемония или ритуал.
4. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
5. Придумайте общую цель. Торг – это не игра с нулевой суммой, когда один выигрывает за счет другого, а упражнение в творческом решении задачи по нахождению пути, при котором выигрывают обе стороны.
6. Настаивайте на объективных критериях.
7. Люди не начнут быстрее соображать, если руководство будет давить на них.
8. Чем больше сверхурочной работы, тем ниже производительность.
9. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
10. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
11. Давление и сверхурочная работа призваны решить только одну проблему - сохранить хорошую мину при плохой игре.
12. Нельзя заставить людей делать что-то по-другому, если вы о них не заботитесь, если вы ими не интересуетесь. Чтобы они изменились, вы должны понимать (и ценить) их самих, что они делают и к чему стремятся.
13. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня (с указанием временного регламента на каждый вопрос), а потом всегда строго ее придерживаться.
14. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
15. Защищайте людей от оскорблений и ругани начальства.
16. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.
2.15. Правило корректировки графиков
Если проект опаздывает, то необходимо растянуть график, экстраполировав его пропорционально коэффициенту отставания (сжатия).
Просто отодвинуть дату окончания на число дней опоздания – это классическая ошибка. И уж, во всяком случае, не пытайтесь догнать график!
Еще никому в истории программирования не удавалось сжать сроки более чем на 20–25%.
Статья Барри Боэма («Industrial Software Metrics Top 10 List», «Список 10 главных правил промышленного создания ПО», Boehm, 1987) дает объективную характеристику положению дел с разработкой ПО. Существует мало свидетельств того, чтобы за последнее время произошли какие-либо значительные изменения. Хотя многие из этих правил являются довольно общими, они точно описывают некоторые фундаментальные экономические отношения, сложившиеся при использовании традиционного процесса создания ПО за последние 30 лет. Вот этот список:
1. Поиск и обнаружение ошибки в ПО после его сдачи обходится в 100 раз дороже, чем поиск и обнаружение ошибки на ранних стадиях разработки.
Эта оценка является главным обоснованием для изменения процесса практически любого направления. Она не является уникальной для разработки ПО. Если, например, некая крупная автомобильная компания исправляет дефект, обнаруженный после продажи, стоимость ремонта может быть на много порядков выше, чем стоимость выявления дефекта на стадии разработки или производства.
2. Можно сократить срок разработки ПО на 25 % от номинального, но не более.
Одной из причин такого положения вещей является то, что для сокращения времени разработки на N% требуется увеличить количество персонала на М% (в предположении, что другие параметры остаются неизменными). Любой рост числа работников требует увеличения затрат на управление. Вообще говоря, допустимые отклонения для этих затрат с учетом графика выполнения параллельных работ, замораживания последующих работ и других ресурсных ограничений составляют около 25%. Оптимальным для работы, требующей 100 человеко-месяцев, может быть выполнение ее за 10 месяцев 10-ю работниками. Смогут ли такую работу выполнить 100 человек за один месяц? 50 человек за два месяца? А может быть, 20 человек за 5 месяцев? Понятно, что это все нереальные варианты. Правило 25%-ного сокращения гласит, что в этом случае допустимое предельное значение — 7.5 месяцев (хотя существует вероятность того, что потребуются дополнительные человеко-месяцы, возможно, около 20). Любое дальнейшее сокращение сроков работ обречено на неудачу. С другой стороны, оптимальный график работ может растягиваться почти произвольно и в зависимости от сотрудников может выполняться за существенно большее время при меньшем штате. Например, если отводится 25 месяцев на выполнение работ, то вполне можно уложиться в 75 человеко-месяцев при использовании трех человек.
3. На каждый доллар, вложенный в разработку, приходится тратить два доллара на сопровождение.
Боэм называет это правило «железным законом разработки ПО». Независимо от того, создается ли продукт долговременного использования, у которого выходят по две коммерческие версии в год, или единственное в своем роде ПОдля конкретного заказчика, количество денег, затрачиваемых на весь цикл сопровождения, будет с некоторой вероятностью в два раза больше суммы, истраченной за весь цикл разработки. На первый взгляд трудно понять, хорошее это соотношение или плохое. Для сектора коммерческих продуктов оно определяется, прежде всего, коммерческим успехом на рынке. Успешные программные продукты (такие, как Oracle, приложения Microsoft, RationalRose и операционная система UNIX) существуют в течение очень долгого времени, что может приводить к более высокому значению отношения стоимости сопровождения к стоимости разработки. С другой стороны, менеджеры проектов по созданию «одноразового» ПО редко планируют большие затраты на его сопровождение. В любом случае каждому, кто был занят в индустрии ПО в течение последних 10 - 20 лет, известно, что ПО всегда трудно сопровождать.
4. Стоимость разработки и сопровождения ПО является, прежде всего, функцией числа строк исходного кода.
Это правило является следствием: а) преобладание разработки ПО на заказ; б) отсутствие коммерчески используемых компонентов; в) отсутствие повторного применения.
5. Различия в уровне разработчиков приводят к огромной разнице в продуктивности при создании ПО.
Это самая главная мудрость традиционного процесса - нанимайте хороших работников. Данному правилу зачастую придается как недостаточное, так и чрезмерное значение. Когда отсутствуют объективные сведения относительно причин успеха или неудачи, очевидным козлом отпущения становится квалификация персонала. Это суждение субъективно, и его трудно оспаривать.
6. Общее отношение стоимости ПО к стоимости аппаратуры продолжает расти. В 1955 г. оно составляло 15:85; в 1985 г. - 85:15.
Тот факт, что на ПО приходится 85% стоимости большинства систем, является не столько следствием продуктивности создания ПО (которое к тому же оказывается не столь хорошим, как хотелось бы), сколько следствием того уровня функциональных задач, выполнение которых возлагается на ПО при принятии решений о системе в целом. Нужда в программном обеспечении, широта его использования и его сложность продолжают безгранично расти.
7. При создании ПО всего лишь около 15% усилий затрачивается собственно на программирование.
Это весьма важный показатель необходимого равновесия. Для успешного осуществления проекта приходится помимо кодирования выполнять много других задач. Управление требованиями, проектирование, тестирование, планирование, контроль за ходом проекта, управление изменениями и подготовка инструментария — одинаково важные задачи, на которые тратится приблизительно 85% ресурсов.
8. Программные системы и продукты обычно стоят в три раза дороже в пересчете на одну строку исходного кода, чем отдельные программы. Продукты, состоящие из программных систем (т.е. системы систем), дороже в девять раз. Эта экспоненциальная зависимость лежит в основе того, что называют платой за масштаб (diseconomy of scale). В отличие от других товаров, чем больше объем создаваемого ПО, тем дороже оно обходится в пересчете на строку исходного кода.
9. Сквозной контроль позволяет обнаружить 60% ошибок.
Возможно, это и так. Однако с учетом правила 1 сквозной контроль не позволяет обнаруживать значимые ошибки, особенно на ранних стадиях жизненного цикла. Дефект дефекту рознь. Вообще говоря, сквозной контроль и другие формы контроля, производимого человеком, хороши для обнаружения ошибок, лежащих на поверхности, и проблем, касающихся стиля. При использовании для разработки специальной системы записи просмотр человеком может служить первичным механизмом гарантии качества, но он не позволяет обнаруживать проблемы второго, третьего, N-oro порядка, такие как конфликты ресурсов, узкие места, связанные с производительностью, конфликты управления и т.п. Более того, очень немногие люди способны находить даже семантические ошибки первого порядка в тексте программы. Скольким программистам удается компилировать свою собственную программу с первого раза?.
10. 80% работы выполняют 20% работающих. (Известное соотношение Парето).
11. Формальные программы, направленные на улучшение существующего процесса разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
12. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
13. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего, приведут к тому, что сроки только увеличатся.
14. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
15. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).
2.16. Как вести исторические записи
Пример.
Проект Х.
Затраты на проект по этапам (чел. дней)
Кроме того, необходимо вести записи следующих типов:
1. Менеджеры должны составлять следующие планы: развития отношений с заказчиком или конечным пользователем, управления разработчиками, управления качеством и управления изменениями.
2. Учесть время, необходимое для формирования группы разработчиков и их введения в курс дела.
3. Руководители и специалисты на каждом этапе должны обеспечить документацию по разработке программного обеспечения, пересмотре или исправлению модулей и обучению персонала.
В задачу тестировщиков [9] входит планирование, создание руководств по тестированию, создание автоматических тестов, прогоны ручных и автоматических тестов, отчетность о выявленных дефектах.
Сроки выпуска продукта, создания альфа- и бета-версии, окончательной версии должны также обязательно фиксироваться в исторических записях, которые позволяют на порядок повысить точность планирования. По данным К. Джонса (Дж. К. Джонс, Методы проектирования, Москва «Мир», 1986), такие измерения повышают качество на 40%, а производительность – на 15%. Эти исследования показали, что компании, которые практикуют измерения, являются лидерами в своей отрасли.
Стоимость измерений составляет всего 4–5% от стоимости проекта. Остается только сожалеть, что ведение исторических записей, систематических измерений и оценок на их основе пока еще не стало привычкой у многих наших программистов и менеджеров.
2.17. Разработка, ориентированная на заказчика
Распознайте заказчика – «держателя акций», определите заказчика правильно! Заказчик – это не обязательно (и далеко не всегда!) тот, кто будет пользоваться программой, а тот, от кого зависит ее приемка и оплата. Это может быть группа маркетинга, начальник отдела информационных технологий, хотя иногда заказчиком может быть и конечный пользователь.
Фактор успеха № 1 – это участие в проекте конечных пользователей. В обзоре Standish Group на опыте 8000 проектов приведены три основные причины провала проектов (т.е. нарушение графика, бюджета или функциональности):
1. Недостаточное участие пользователей.
2. Неполная постановка задачи.
3. Изменение требований в процессе разработки.
Иначе говоря, следует стремиться к ситуации, где ответственность за выполнение проекта лежит не только на Исполнителе, но и разделяется с Заказчиком (конечным пользователем).
2.18. Планирование быстрой разработки
Большинство сегодняшних проектов планируется окончить в сроки, которые не могут быть достигнуты ни при каких обстоятельствах. Менеджеры проектов часто даже не представляют всей амбициозности своих планов и обычно реализуют их гораздо позже запланированных сроков.
Основной причиной медленной разработки является надежда на то, что все пойдет хорошо. График работ должен быть реалистичным, чтобы между планируемой и реальной датой завершения проекта не образовывался временной зазор. Полезно использовать методы, позволяющие визуально отслеживать продвижение в выполнении проекта (MSProject и подобные продукты). Часто заказчики не столько заинтересованы в высокой скорости разработки, сколько просто хотят быть в курсе дел.
Трудоемкость проекта по этапам
Чем больше сразу учишься, тем меньше после мучишься.
(Льюис Кэрол.«Алиса в Стране чудес»)
Следующая таблица показывает, как обычно расходуется время при выполнении больших и малых программных проектов. Еще Ф.Брукс заметил, что кодирование занимает не более 1/6 части проекта, в то время как обыденное сознание программиста подсказывает обратное соотношение, и к нему опасно прислушиваться.
Этап работы
Малый проект
(2500 строк)
Большой проект
(500000 строк)
Проектирование архитектуры
10%
30%
Подробный проект
20%
20%
Кодирование и отладка
25%
10%
Тестирование модулей
20%
5%
Объединение
15%
20%
Тестирование системы
10%
15%
В малых проектах основное время занимают этапы разработки подробного проекта, кодирования и отладки и тестирование модулей. Если бы можно было волшебным образом исключить все эти этапы из проекта, то мы сократили бы его на целых 65%. Для больших проектов все иначе. Исключение этих этапов снизит трудоемкость всего на 35%, так как основные усилия разработчиков направлены на разработку архитектуры, проектирование и системную интеграцию.
Для успеха проекта необходимо держать в равновесии три характеристики: график проекта, бюджет проекта и его функциональность (сам продукт). Последнее включает в себя, помимо функциональности, качество программного продукта, его полноту, пригодность для использования, модифицируемость, надежность и т.п.
Чтобы при разрастании проекта треугольник оставался в равновесии, необходимо, «растягивая» вершину «продукт», также «растянуть» «затраты» или «график», а чаще всего и то, и другое вместе. Стив Макконнелл говорил (Steve McConnell – Code Complete, SecondEdition,2004), что во время обсуждения с заказчиками графика работ по проекту ему очень помогал большой треугольник, сделанный из картона. Когда заказчики показывали на вершину «График» или «Продукт» и говорили о своих дополнительных требованиях, он указывал им на оставшиеся вершины и говорил, что необходимо сделать, чтобы треугольник оставался в равновесии. Если заказчик не хочет отдать Вам ни одной вершины треугольника, считает Макконнелл, проект не может быть выполнен.
Существует два способа составления графика работ: максимальное ускорение и минимизация рисков. Возможности и недостатки этих методов иллюстрирует следующий рисунок.
Опыт показывает, что при разработке программного обеспечения возврат к предыдущим этапам и переделывание работы неизбежен. Лучше сразу учитывать это при планировании, т.е. спланировать график работ так, чтобы возврат на предыдущие этапы было легко осуществить.
Типичные модели:
Метод «Code-and-Fix».
Программист, который использует этот метод, изначально имеет только общее представление о программе, которую он хочет написать. У него могут быть формальные спецификации, а могут и не быть. Затем он использует любые подходящие ему средства проектирования, кодирования, отладки и тестирования, пока не получает готовый продукт (или не получает).
Пожалуй, единственным достоинством данного метода является отсутствие накладных расходов. Не нужно тратить время на планирование, документацию, контроль за выполнением требований и т.п. Поэтому этот метод иногда используется для разработки коротких модулей одним программистом. Для любых других проектов эта модель просто опасна, т.к. она не позволяет оценивать качество работ и уровень риска. Метод Code-and-Fix не подходит для проектов быстрой разработки.
Спиральная модель.Спиральная модель – это ориентированная на риски модель жизненного цикла, которая позволяет разбить большой программный проект на минипроекты. В каждом таком минипроекте устанавливаются один или более главных рисков (непонятные требования, плохо разработанная архитектура, потенциальные проблемы в исполнении и т.п.). После того, как риски определены и намечены пути их снижения, минипроект выполняется по обычной схеме «чистого водопада». Затем следует переход на следующую итерацию, которая перемещает проект в больший масштаб. Вы заканчиваете один уровень, проверяете – то ли это, что Вы хотели получить, и начинаете работу над следующим уровнем.
Каждая итерация включает 5 этапов:
1. Определение объектов, альтернатив и ограничений.
2. Определение и снижение рисков.
3. Оценка альтернатив.
4. Разработка продукта для данной итерации, проверка его корректности.
5. Планирование и переход к следующей итерации.
Преимущество спиральной модели заключается в том, что она позволяет снижать риски по мере возрастания стоимости разработки. После каждой итерации есть контрольная точка, позволяющая определить, соответствует ли разработка ожиданиям заказчика. Если проект не может быть выполнен по техническим или каким-либо другим причинам, использование спиральной модели позволит узнать об этом достаточно рано, пока в разработку еще не вложены большие средства.
Для того чтобы спиральная модель разработки принесла пользу, необходимо тщательное, сложное и точное управление.
Спиральная модель разработки ПО
На сегодняшний день наиболее перспективными считаются эволюционные модели.
Эволюционная поставка по версиям.
В первой версии реализуются самые важные функции, во вторую очередь – менее важные и т.д. Данный подход особенно эффективен при быстром изменении постановки задачи. Модель отлично работает при организации подряда, поскольку хорошо ложится на договорные отношения и понятна заказчику, который платит только за те функции, которые относятся к задачам соответствующей версии.
Эволюционная поставка, исходя из имеющихся ресурсов.
Характеризуется разработкой максимального набора функций, укладывающегося в установленные ресурсы, сроки или деньги. Разработка идет до тех пор, пока указанный ресурс не исчерпается. Такая модель характерна для проектов, предназначенных для собственного использования либо для продажи «коробочных» решений на рынке.
Эволюционное прототипирование.
Данный подход подразумевает создание прототипа и его длительную доводку до рабочей программы. Разработку следует начинать с наиболее существенных, видимых аспектов системы. Эта часть демонстрируется заказчику, корректируется, после чего разработка прототипа продолжается. Когда и разработчики, и заказчик соглашаются с тем, что прототип «достаточно хорош», работы завершаются, и прототип выпускается как готовый продукт.
Эволюционное прототипирование [3] особенно полезно, когда требования к проекту постоянно изменяются, или когда и вы, и заказчик не владеете предметной областью достаточно хорошо.
Этот метод обычно используется Microsoft – обратите внимание на номера выпусков (build) любой выпускаемой ими программы, которые всегда можно найти в разделе «О программе» пункта «Справка».
И последний, ныне ведущий метод: внедрение готового ПО. Опыт показывает, что заказчик, который еще недавно так настаивал на собственной разработке, после внедрения готового продукта очень скоро об этом забывает. Горячее желание пользоваться собственной разработкой исходит из его нереалистических ожиданий, которые на практике никогда не оправдываются. Речь идет, конечно же, о якобы повышенных характеристиках функциональности, надежности, качестве собственной разработки по отношению к типовой. Опыт показывает, что дело обстоит с точностью до наоборот. Качество стандартной разработки всегда выше доморощенной, а попытки догнать и перегнать типовую разработку заведомо обречены. Ведь разработчик типового проекта тоже не стоит на месте и непрерывно работает над улучшением своей продукции. Ошибочно и мнение заказчика о том, что ему большой стандартный перегруженный якобы ненужными функциями сложный в освоении продукт не нужен. Наоборот, после внедрения «малой» системы заказчик тут же захочет большего, и в конечном итоге собственная разработка будет все более усложняться и походить на стандартную, ввиду схожих бизнес-требований. Притом качество собственной разработки не будет идти ни в какое сравнение с качеством готового ПО.
Руководству непрограммистской организации (или его подразделения, занимающегося эксплуатацией), следует строжайшим образом следить за тем, чтобы это подразделение не начало выполнять несвойственные ему функции. Превращаясь в центр разработки программ для собственной организации, оно «проедает» прибыль предприятия и снижает его эффективность. Так, крупные западные банки, которые традиционно чаще используют собственные разработки, тратят до 10% прибыли на компьютеризацию, в то время как для небольших банков и предприятий, использующих типовые проекты и типовые разработки эта цифра снижается в разы.
Четыре основных правила менеджмента
Если бы каждый человек занимался своим делом,
Земля вертелась быстрее.
(Льюис Кэрол.«Алиса в Стране чудес»)
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
(Все остальное — административная ерундистика.Том Демарко. Роман об управлении проектами).
3. Стейкхолдеры проекта
Стейкхолдерыпроекта это источники влияния. Лица или группы, которые напрямую могут быть не связаны с получением или использованием продукта проекта, но которые, в связи с их положением в организации-заказчике или исполняющей организации, могут положительно или отрицательно повлиять на ход выполнения проекта.
3.1. Спонсор проекта
Спонсор проекта это лицо или группа лиц, предоставляющая финансовые ресурсы – деньгами или в натуральном выражении (техническое обеспечение, предоставление команды исполнителей, помещений, средств связи и т.д.) для выполнения проекта.
3.2. Заказчик проекта
Заказчик проекта это лицо или группа лиц, которые финансируют проект или приобретают продукт для решения своих бизнес-задач.
3.3. Руководитель проекта
Руководитель проекта (Менеджер проекта, ProjectManager). Лицо, ответственное за управление проектом.
3.4. Команда проекта
Команда проекта это участники проекта, см.п.3.5.
3.5. Участники проекта (должности, сферы ответственности)
Участники проекта – это лица или организации, либо активно участвующие в проекте, либо те, на чьи интересы могут повлиять результаты исполнения или завершения проекта. Участники также могут влиять на цели и результаты проекта. Команда управления проектом должна выявить участников проекта, определить их требования и ожидания и, насколько это возможно, управлять ихвлиянием в отношении требований, чтобы обеспечить успешное завершение проекта. На рис.3.5.1. показаны отношения между участниками проекта и командой проекта.
2
Рисунок 3.5.1. Отношения между участниками проекта и проектом
Участники проекта имеют различные уровни ответственности и полномочий при участии в проекте, причем ответственность и полномочия могут меняться на разных этапах жизненного цикла проекта. Их ответственность и полномочия варьируются от случайного участия в обзорах и фокус-группах до полного обеспечения нужд проекта, в том числе финансовой и политической поддержки. Участники проекта, игнорирующие свои обязательства, могут вызвать непоправимые последствия для целей проекта.
Аналогично, менеджерам проекта, не учитывающим влияние участников проекта, следует ожидать тяжелых последствий для результатов проекта. Иногда выявить участника проекта довольно сложно. Например, рабочий сборочной линии, чей профессиональный рост на предприятии зависит от результата проекта разработки нового продукта, тоже является участникомпроекта. Незнание ключевых участников проекта может привести к большим сложностям при исполнении проекта. Например, к требованиям проекта по обновлению программного обеспечения в связи с проблемой 2000 года (Y2K) пришлось добавить много дополнительных задач по документации из-за того, что слишком поздно было обнаружено, что юридический отдел являлся важным участником проекта.
Участники могут оказывать положительное или отрицательное влияние на проект. Положительно влияющие участники – это обычно те, кому выгодно успешное завершение проекта, тогда как отрицательно влияющим участникам успешное завершение проекта представляется нежелательным. Например, деловые круги общества, которое выиграет от проекта индустриального развития, могут быть положительно влияющими участниками, так как они видят экономическую пользу успешного проекта для общества. Наоборот, группы по защите окружающей среды могут быть отрицательными участниками, если они считают, что проект вредит природе. В интересах положительно влияющих участников будет помощь осуществлению проекта,например, в получении необходимых разрешений. Действия отрицательно влияющих участников могут заключаться в препятствовании осуществлению проекта путем требования более тщательных экологических инспекций.
Менеджер проекта, не обращающий внимания на отрицательно влияющих участников, рискует провалить проект.
Конфликты
1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
2. Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.
3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.
7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: все мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
Ключевыми участниками любого проекта являются:
Менеджер проекта
Лицо, ответственное за управление проектом и его выполнение.
Заказчик/пользователь
Лицо или организация, которые будут использовать продукт проекта. Может существовать множество уровней заказчиков. Например, к числу заказчиков нового фармацевтического препарата могут относиться врачи, назначающие данный препарат, пациенты, которые его принимают, страховщики, которые его оплачивают. В некоторых областях приложения заказчик и пользователь совпадают, в то время как в других под потребителем подразумевается юридическое лицо, получающее продукты проекта, а под пользователями – тех, кто будет непосредственно использовать продукт проекта.
Исполняющая организация
Предприятие, чьи сотрудники непосредственно участвуют в исполнении проекта.
Члены команды проекта
Группа, которая выполняет работы по проекту.
Команда управления проектом
Члены команды проекта, непосредственно занятые в управлении его операциями.
Спонсор
Лицо или группа лиц, предоставляющая финансовые ресурсы – деньгами или в натуральном выражении для проекта.
Источники влияния
Лица или группы, которые напрямую не связаны с получением или использованием продукта проекта, но которые, в связи с их положением в организации-заказчике или в исполняющей организации, могут положительно или отрицательно повлиять на ход выполнения проекта.
Офис управления проектом (PMO).
Если в исполняющей организации имеется этот офис, он может быть участником проекта, если он несет прямую или непрямую ответственность за результаты проекта.
Помимо вышеперечисленных ключевых участников проекта существует множество различных наименований и категорий участников проекта, в том числе внутренние и внешние, владельцы и инвесторы, продавцы и подрядчики, члены команд и их семей, правительственные учреждения и средства массовой информации, отдельные граждане, временные или постоянные лоббистские организации и общество в целом. Перечисление или классификация участников – это, главным образом, способ выявить тех лиц и те организации, которые рассматривают себя в качестве участников проекта. Роли и ответственности участников могут перекрываться, например, в том случае, когда проектная организация обеспечивает финансирование завода, который сама же и проектирует.
Менеджеры проекта должны управлять ожиданиями участников проекта, что может быть достаточно сложно, так как у участников проекта могут быть разные или противоположные цели.
Например:
Руководитель отдела, который потребовал установить новую информационную систему управления, может быть заинтересован в ее низкой стоимости, специалист по созданию системы может сделать акцент на техническом совершенстве системы (надежности), а подрядчик, получивший заказ на программирование, может быть заинтересован в получении максимальной прибыли.
Вице-президент по разработкам в компании электронного оборудования может определять успех нового продукта как совершенство технологии, вице-президент по производству – по применению передовых производственных технологий, а вице-президент по маркетингу – по количеству реализованных новых возможностей продукта.
Владелец проекта по сооружению объекта недвижимости может в первую очередь быть заинтересован в своевременном завершении строительства, местные органы власти – в получении максимальных налогов, группа защитников окружающей среды – в минимизации негативного воздействия на окружающую среду, а живущие поблизости местные жители могут надеяться на переносе строительства в другое место.
Способность участников проекта повлиять на конечные характеристики продукта проекта и окончательную стоимость проекта максимальны в начале проекта и уменьшаются по ходу выполнения проекта. Это показано на рис.3.5.2. Главная причина этого состоит в том, что стоимость внесения изменений в проект и исправления ошибок в общем случае возрастает по ходу выполнения проекта.
Рисунок 3.5.2. Влияние участников проекта в течение проекта
