• Передача (Transition): контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей
• Редакторы (program editors). Эти инструменты используются для создания и модификации <исходного кода> программ и, возможно, ассоциированной с ними документации. Это могут быть как редакторы “общего назначения” (что на протяжении многих лет наблюдается в UNIX и unix-подобных средах) или специализированные редакторы с поддержкой специфики целевого языка программирования (что является, в большинстве случаев, прерогативой интегрированных сред разработки - IDE). В то же время,
• Средства выполнения тестов (test execution frameworks). Эти средства обеспечивают среду исполнения тестовых сценариев в контролируемом окружении, позволяющем отслеживать поведение объекта, подвергаемого тестированию.
• Цели прототипирования. Примерами таких целей служат требования, архитектурный дизайн или пользовательский интерфейс.
[1] IEEE - Computer Society of the Institute for Electrical and Electronic Engineers, IEEE Computer Society - IEEE-CS (Компьютерное Общество) или просто IEEE. http://www.ieee.org
[2] ISO - International Organization for Standardization. http://www.iso.ch ; IEC - International Electrotechnical Commission; JTC 1 -
Joint Technical Committee 1, Information technology
[4] ITIL, в частности, определяет три аспекта управления жизненным циклом приложений - определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями - Application Management в ITIL ICT Infrastructure Management (ICT - Information and Communications Technology).
[5] 4.1.5 Создание новой системы: рассматривает текущую версию и систему в целом, как устаревшую - legacy.
[6] * например, на практике просто невозможно добиться статуса PMP - Project Management Professional по версии Project Management Institute (PMI), если претендент не обладает
[7] Здесь нельзя не сделать замечание, связанное со структурированием этой области знаний. Обсуждаемая область знаний, действительно, тесно связана с дисциплиной управления проектами. Более того, речь идет о приложении управления проектами к программной инженерии. В этом контексте кажется уместным сопоставить предлагаемый в SWEBOK цикл “Initiation & scope definition - Planning - Enactment - Review & evaluation - Closure" с процессными группами PMBOK “Initiation - Planning - Execution - Monitoring & Controlling - Closing'. Как мы видим, в PMBOK роль работ SWEBOK “Обзор и оценка” (Review and evaluation) играют действия по мониторингу и контролю процессов - “Monitoring & Controlling Processes”. Таким образом, с учетом реального содержания секции “Software project enactment”, ее название и переведено автором как “Выполнение программного проекта”, хотя “enactment” в большей степени подразумевает формальный “запуск” работ. Конечно, перевод мог звучать и как “исполнение” (например, следуя PMBOK), однако, такой перевод, по мнению автора, все же несет слишком формальный оттенок, что, субъективно, не соответствует ряду методологических подходов (в первую очередь agile) и культурных “ограничений”.
[8] Крайне необходимо выделить как самостоятельную тему данной секции вопросы управления персоналом - people management, уделив особое внимание аспектам экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в проектной команде. К этой же теме, также стоит отнести вопросы обучения, прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов имеет непосредственное отношение и определение необходимости и объема привлечения внешних консультантов (не являющихся сотрудниками ни исполнителя, ни заказчика), к сожалению, не упоминаемое здесь в SWEBOK, но крайне важное, по опыту автора, для успешности проекта, обладающего высокой степенью новизны (например, в терминах используемых технологий и, особенно, применения тех или иных архитектурных решений).
2.5 Управление рисками (Risk Management)
В части управления рисками должны проводиться:
• идентификация и анализ рисков - что, когда и почему может быть сделано неверно и к чему это может привести;
• оценка критических рисков - какие из рисков наиболее значительны (если им не уделять должного внимания) и что необходимо сделать, чтобы их избежать;
[9] Хотелось бы обратить внимание на то, что современная практика управления проектами, в частности, разработки и сопровождения программного обеспечения, требует обеспечения возможности доступна к актуальным данным по проекту в любой момент времени. По-сути в настоящее время возникает целый класс интегрированных инструментов и специализированных продуктов, часто называемый project dashboard (наиболее близкий перевод этого понятия на русский язык может звучать как “панель управления проектом”). Обычно, такие инструменты не только работают со “снимками” данных, сводя их воедино, но обращаются непосредственно к данным в системах конфигурационного управления, управления требованиями, сценариями тестирования, аудита кода, расписания проекта в соответствующих средствах управления проектами и т.п.
3.5 Процесс контроля (Control Process)
Выходы (результаты) процесса мониторинга обеспечивают базис, на основе которого принимаются те или иные решения. Изменения в проект вносятся там, где это необходимо, и где ассоциированные риски и их влияние смоделированы и могут быть управляемы (контролируемы).
Эти изменения могут проводиться в форме корректирующих действий (например, повторного
[10] Формулируются требования в отношении измерений. Каждая попытка измерения должна руководствоваться организационными целями и следовать набору измерений, выполняемых в отношении требований, в соответствии с принятыми организационными или проектными стандартами. Например, в качестве организационной цели может выступать “выпуск на рынок новых продуктов первыми”. Это, в свою очередь, может порождать требование того,
[11] Определение наборов <собираемых> данных, а также процедур анализа и ведения отчетности. Это включает в себя коллекцию процедур и расписаний, хранение, проверку,
[12] Сбор данных. Данные должны собираться, верифицироваться и сохраняться <для дальнейшего использованиям (см. стандарт ISO 15939-02, раздел 5.3.2).
[13] Определение потенциальных возможностей улучшения/усовершенствований (improvements) <процесса проведения измерений>. Такие рекомендации по улучшению могут заключаться в изменении формата используемых количественных индикаторов, единиц измерения или изменений в их классификации (категориях метрик). Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и отобрать те из них, которые соответствуют целям и критериям измерений, после чего сформулировать действия, необходимые для внедрения выбранных улучшений. Предполагаемые улучшения должны быть обсуждены и утверждены заинтересованными лицами. Отсутствие потенциальных улучшений (если они не были идентифицированы в результате проведенного анализа) также должно быть обсуждено с заинтересованными лицами.
[14] Наконец, третье понимание данного термина может означать реальный набор действий, предпринимаемых в данной организации и рассматриваемый как единый процесс на
[15] SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment - внутренняя деятельность в организации, направленная на оценку и совершенствование собственного процесса в рамках всей организации. Evaluation подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя) со стороны заказчика, в первую очередь, в процессе самого выполнения работ, т.е. уже после заключения контракта/договора подряда. CBA-IPI относится к общей категории методов Software Process Assessment (SPA) как части работ по
[16] данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке оригинального варианте SWEBOK 2004, поэтому, далее, нумерация тем смещена.
