Управление процессом разработки программного обеспечения

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

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

7. Определите список заинтересованных лиц для каждого проекта 
   Важно как можно раньше выяснить, кем представлен каждый из классов пользователей при сборе требований, кто назначает приоритеты требованиям и т.д.

Очень важно выяснить, кто  должен быть оповещен при выпуске  версий!

Если версии не доходят до заинтересованных лиц, нет смысла в их частом выпуске

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

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

9. Приоритетами должен управлять 1 человек, и этот процесс должен быть максимально формализован! 
   По опыту общения с людьми, заинтересованными в проекте, я могу сказать, что у каждого из них, скорее всего, будет свое видение важности реализации каждого из требований. Часто эти люди не могут договориться между собой. Не берите на себя ответственность за то, чтобы решать, чье мнение важнее: это не ваша забота. Пусть руководитель определит, что наиболее приоритетно в его бизнесе
10. Планируйте изменения в итерации 
    В вышеуказанной инструкции опишите, что должно выполняться в следующих случаях:
1. Сокращено время проектной занятости группы разработки на текущую итерацию
2. Заказчик изменяет приоритет требований
3. Заказчик изменяет состав требований

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

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

Направления улучшения данного  процесса:

1. Ввести более или менее формальную процедуру оценивания заказчиком продукта.
2. Фиксировать отзывы заказчика о продукте
3. Определить, как будет учитываться время на организацию работы, выяснение деталей реализации, совещания и т.д.

5. Сопровождение  программного обеспечения 
(Software Maintenance по SWEBOK)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. 
Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с замечаниями и комментариями.

Сопровождение программного обеспечения (Software Maintenance)  
1. Основы сопровождения программного обеспечения (Software Maintenance Fundamentals)  
1.1 Определения и терминология (Definitions and Terminology)  
1.2 Природа сопровождения (Nature of Maintenance)  
1.3 Потребность в сопровождении (Need for Maintenance)  
1.4 Приоритет стоимости сопровождения (Majority of Maintenance Costs)  
1.5 Эволюция программного обеспечения (Evolution of Software)  
1.6 Категории сопровождения (Categories of Maintenance)  
2. Ключевые вопросы сопровождения программного обеспечения (Key Issues in Software Maintenance)  
2.1 Технические вопросы (Technical Issues)  
2.2 Управленческие вопросы (Management Issues)  
2.3 Оценка стоимости сопровождения (Maintenance Cost Estimation)  
2.4 Измерения в сопровождении программного обеспечения (Software Maintenance Measurement)  
3. Процесс сопровождения (Maintenance Process)  
3.1 Процессы сопровождения (Maintenance Processes)  
3.2 Работы по сопровождению (Maintenance Activities)  
4. Техники сопровождения (Techniques for Maintenance)  
4.1 Понимание программных систем (Program Comprehension)  
4.2 Реинжиниринг* (Reengineering)  
4.3 Обратный инжиниринг* (Reverse engineering)

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

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

Сопровождение программного обеспечения  является составной частью жизненного цикла. К сожалению, так сложилось, что вопросам сопровождения уделяется  существенно меньше внимания, чем  другим фазам жизненного цикла. Исторически, в большинстве организаций, разработка программных систем явно в фаворе, по сравнению с деятельностью  по сопровождению. Однако, такая ситуация постепенно начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний ITIL* – IT Infrastructure Library, уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения сроков использования  уже существующего и применяемого ПО. Конечно, с точки зрения автора, это не единственная причина. Скорее вопросы постоянно изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения программного обеспечения и естественной интеграции такой деятельности в бизнес-процессы подразделений информационных технологий.

* ITIL, в частности, определяет  три аспекта управления жизненным  циклом приложений – определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями – Application Management в ITIL ICT Infrastructure Management (ICT - Information and Communications Technology).

Если проблема 2000 года, в  свое время, оказала особое влияние  на изменение отношения к сопровождению  на Западе, то расширение применения продуктов  Open Source во всем мире и связанная с ним волна надежд на получение дешевого решения существующих задач привела к тому, что вопросы сопровождения вышли для многих организаций на первый план. Ситуация во многих ИТ-подразделениях показывает, что такие надежды оправдались только частично. Использование продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело даже к бОльшим проектным затратам именно в силу недостаточно проработанной политики эксплуатации и сопровождения построенных на их основе прикладных решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости сопровождения привело к превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу инициатив по использованию таких продуктов в корпоративной среде.  Неготовность рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в эксплуатацию, непроработанность соответствующих процедур корректировки продукта после его выпуска – основная беда и в бизнесе-среде, для которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, “забывающих” о необходимости развития успеха после внедрения системы у заказчика, и у независимых поставщиков программных продуктов, которые, выпуская новую версию лучшего в своем классе продукта, начинают работать над новой версией, уделяя недостаточное внимание поддержке и обновлению уже существующих версий.

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

Область знаний “Сопровождение программного обеспечения” связана с другими  аспектами программной инженерии. По-сути, описание этой области знаний непосредственно пересекается со всеми  другими дисциплинами.

Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1]

1. Основы сопровождения  программного обеспечения (Software Maintenance Fundamentals)

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

1.1 Определения  и терминология (Definitions and Terminology)

Сопровождение программного обеспечения  определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении. Интересно, что данный стандарт также касается вопросов подготовки к сопровождению до передачи системы в эксплуатацию, однако, структурно это сделано на уровне соответствующего информационного приложения, включенного в стандарт.

В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного продукта в части его кода и документации для решения возникающих проблем <при эксплуатации> или реализации потребностей в улучшениях <тех или иных характеристик продукта>. Задача состоит в модификации продукта при условии сохранения его целостности. Международный стандарт ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по сопровождению.

1.2 Природа сопровождения (Nature of Maintenance)

Сопровождение поддерживает функционирование программного продукта на протяжении всего операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения фиксируются  и отслеживаются запросы на модификацию (также называемые “запросами на изменения” – change requests, в частности, в контексте конфигурационного управления), оценивается влияние предлагаемых изменений, модифицируется код и другие активы (артефакты) продукта, проводится необходимое тестирование и, наконец, выпускается обновленная версия продукта. Кроме того, проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей версией продукта. В SWEBOK отмечается, что сопровождение, с точки зрения операций отслеживания и контроля, обладает большим содержанием, чем разработка (в общем понимании). Объем и активность операций по контролю разработки в большой степени зависит от сложившихся практик, внутрикорпоративных регламентов и требований, а также применяемых методологий и концепции управления (в частности – проектного менеджмента). Так или иначе, отслеживание и контроль – ключевые элементы деятельности по сопровождению программного обеспечения (как и других ИТ-активов предприятия).

Стандарт 12207 определяет понятие “maintainer” - в соответствующем ГОСТ он именуется как “персонал сопровождения”, подразумевая организацию, выполняющая работы по сопровождению. SWEBOK использует данный термин, также, и в отношении лиц (individuals), проводящих определенные работы по сопровождению, в отличие, например, от разработчиков, занимающихся реализацией системы в программном коде.

Стандарт жизненного цикла 12207 также  идентифицирует основные работы по сопровождению: реализация процесса <сопровождения>, анализ проблем и модификаций (изменений), реализаций модификаций, обзор (оценка)/принятие <решений> по сопровождению, миграция (с одной версии программного продукта на другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти работы описываются далее  в теме 3.2 “Работы по сопровождению” (Maintenance Activities).

Специалисты по сопровождению (персонал сопровождения) могут получать знания о программном продукте непосредственно  от разработчиков. Взаимодействие с  разработчиками и раннее привлечение  этих специалистов помогает уменьшить  усилия, необходимые для адекватного  сопровождения программной системы. По мнению автора, передача знаний персоналу  сопровождения, его обучение, должно начинаться не позднее начала опытной  эксплуатации продукта. В противном  случае, усилия на одновременную поддержку  прикладной системы и обучение соответствующих  специалистов не только превысит реально  допустимые нормы загрузки персонала (как группы или службы сопровождения  и техподдержки, так и разработчиков системы), но снизит эффективность поддержки пользователей на критически важном этапе первоначального использования новой системы. По опыту автора и результатам обсуждения этого вопроса с сотрудниками внутрикорпоративных ИТ-департаментов, обычно, в зависимости от сложности системы, пик нагрузки на службу сопровождения приходится в течении первых 2 - 6 недель, с момента передачи системы в реальную эксплуатацию, тем более, при отказе от использования старой системы или ее предыдущей версии. SWEBOK отмечает, что, в некоторых случаях, инженеры (создававшие систему) не могут быть привлечены к обучению и поддержке персонала сопровождения. Особенно часто это касается тиражируемых или “коробочных” систем. Это создает дополнительные трудности для специалистов, обеспечивающих сопровождение. В то же время, инженеры, занимающиеся технической поддержкой (несколько боле узкий круг в команде сопровождения, включающей менеджеров, администраторов и других специалистов), должны (в зависимости от типа продукта) иметь доступ к активам проекта (например, описанию его внутренней архитектуры), включая код, документацию и т.п. Именно таким образом начинает формироваться информационная инфраструктура службы технической поддержки и сопровождения у производителей программных продуктов.