CC BY
27
9) Отслеживаются ли на протяжении всего времени разработки технические риски, риски по стоимости, ресурсам и графику?
10) Ведутся ли записи фактических данных измерений и данных по перепланированию деятельно-стей по отслеживанию проекта для использования разработчиками и руководителями?
11) Совершают ли разработчики и руководители регулярные обзоры для отслеживания продвижения в технических вопросах, планировании, исполнении и в решении проблем и для их соотнесения с планом разработки?
12) Проводятся ли официальные обзоры на определенных этапах, а также при начале и при завершении определенных стадий для выявления достигнутых результатов разработки?
В заключение отметим, что же дает модель СММ? Ошибаются те, кто думает, что, зная только модель, сразу станут замечательными разработчиками. Модель рассматривает как свой предмет сам процесс производства ПО и дает как результат только некую схему, некоторую линию поведения для улучшения этого процесса производства ПО с тем, чтобы разработчики могли после принятия решения работать по такой модели. Модель выявляет, что надо улучшать, но "не говорит", как надо улучшать. Она задает базовые технологические действия, те умения, которые надо иметь для того, чтобы процесс производства ПО стал управляемым, предсказуемым и постоянно совершенствуемым.
Данная модель на сегодняшний день прошла практическую проверку во множестве организаций. Она построена на проверенных принципах [1-8].
Принципиальная разница между начальным и последующими уровнями в том, что для процесса
первого уровня можно сказать что-либо о результате разработки только после того, как работа закончена, а ресурсы и время потрачены; в то время как для всех остальных еще до начала работы можно сделать предварительный расчет временных и прочих затрат, точность которого тем выше, чем выше уровень зрелости процесса. Однако это не значит, что в процессе первого уровня нельзя сделать хороший проект. Существуют хорошие результаты, но их особенность в том, что они непредсказуемы. До момента, пока проект не закончился, неизвестно, закончится он или нет, а если и закончится, то с каким результатом.
Список литературы
1. Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.
2. Boehm B.W. Software Engineering Economics. -Englewood Cliffs: Prentice Hall, 1981. - 767 p. - Русс. пер.: Боэм Б.У. Инженерное проектирование программного обеспечения/ Пер. с англ. - М.: Радио и связь, 1985. - 512 с.
3. Brooks F.P.Jr. The Mythical Man-Month. - S.L.: Addison-Wesley, 1975. - Русс. пер.: Брукс Ф.П.мл. Как проектируются и создаются программные комплексы. Сер. Библиотечка программиста. - М.: Наука, 1979. - 152 с.
4. DeMarco T. Controlling Software Projects. - Englewood Cliffs: Prentice Hall, 1982.- 284 p.
5. Grady R.B. Practical Software Metrics for Project Management and Process Improvement. - Englewood Cliffs: Prentice Hall, 1992. - 270 p.
6. Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.
7. IEEE Standards Collection. Software Engineering, 1993 Edition. - New York: IEEE, 1993. - 952 p.
8. Myers G.J. The Art of Software Testing. - New York: John Wiley & Sons, 1979. - 177 p.
ПРАКТИЧЕСКАЯ МОДЕЛЬ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Институт технологии программирования при университете Карнеги-Меллон (США) для производящих программные изделия (ПИ) организаций разработал модель совершенствования потенциальных возможностей - модель СММ (Capability Maturity Model) [1,2].
Модель CMM является иерархической (пятиуровневой). На каждом иерархическом уровне модели установлено множество общих правил, необходимых условий и обязательных деятельностей, выполнение которых важно для создания в организации инфраструктуры, обеспечивающей определение, поддержку, развитие и улучшение технологии проектирования и производства ПИ. В [1] эта технология названа процессом проектирования и производства ПИ.
Для каждого уровня модели определены области основной деятельности (ключевые области - KPA -
Key Process Area) по становлению процесса. Все уровни модели CMM определяются своими ключевыми областями и имеют, кроме номера, свое название, которое отражает главную особенность процесса на них. В соответствии с этой моделью каждая производящая ПИ организация должна определить и установить собственный процесс, который принято называть стандартным процессом (СП) организации.
Уровень зрелости считается достигнутым, если в результате оценивания данной организации дипломированными внешними экспертами окажется, что все ключевые области данного уровня СП организации (включая и все ключевые области предшествующих уровней) получили экспертную оценку не ниже 7 баллов по десятибалльной шкале. Для подтверждения или повышения своего уровня зрелости
Литературные источники, серверы г Оперативные ^ Internet долгосрочные планы
Правила, проце-^. дуры, программыу
Информационное обеспечение
Структура
°рганиза- / Механизм ции / организационной ^ деятельности
Организационное обеспечение
Повышение квалификации
/ Базы данных / процесса ^г^ Условия и порядок Прочее
Проект ПИ ПИ обеспечение
Инструментальные средства вания и J дства j /Автоматизирован-И ные рабочие места разработчиков
Редакторы, текстоХ вые процессоры
Программное обеспечение
Средства планирования и уп- / равления НИР /
Техническое обеспечение
Локальная вычислительная сеть
Другие средства
ВспомогательноеХ оборудование
Рис. 1. Структура практической модели СП
организация должна проводить такие оценивания, как правило, раз в два года.
Главное достоинство организации, находящейся на высоком уровне зрелости - это предсказуемость завершения ею разработки в срок и поставка заказчику ПИ с заданным качеством.
Структура практической модели СП в ИДУ с точки зрения разработчика представлена на рисунке 1.
Как видно из рисунка, модель СП состоит из четырех основных частей - организационного, технического, программного и информационного обеспечения. До сих пор не существует приемлемых методов их формального описания, которые бы облегчали создание, поддержку, развитие и постоянное улучшение инфраструктуры организации, условий и порядка проведения разработки и производства ПИ.
Описание модели СММ представляет собой развернутый перечень рекомендаций по определению, составлению и способам реализации содержания каждой представленной на рисунке части структуры модели СП.
Задача разработки и внедрения СП в производящей ПИ организации должна быть разбита на несколько этапов.
На первом этапе перед организацией должны быть поставлены реальные цели по достижению в хронологическом порядке уровней зрелости модели СММ. Опыт показывает, что при целеустремленной, интенсивной работе с соблюдением строгой дисциплины выполнения всех предписанных процедур, правил, программ и остальных составляющих СП организация может достичь третьего уровня зрелости за 1,5-2 года с начала работы, четвертого - за 3-4 года, пятого - за 4-5 лет.
На втором этапе необходимо выбрать из множества описаний (с учетом всех пяти уровней зрелости) наиболее подходящее подмножество для данной организации, выделить из них наиболее актуальные для реализации в первую очередь (реально начинать с достижения сразу третьего уровня), осуществить для этого разработку, внедрение, поддержку и постоян-
ное улучшение всех четырех видов обеспечения СП. При этом для повышения эффективности продвижения вверх по уровням зрелости целесообразно вводить элементы четвертого и пятого уровней модели СММ даже при целевом достижении третьего уровня зрелости.
На последующих этапах можно приступить к разработке и внедрению недостающих для достижения последующих уровней, составляющих СП.
Для успешного выполнения проекта ПИ без превышения установленного бюджета в плановый срок, получения качественных и конкурентоспособных ПИ, приобретения организацией авторитета в своем классе и успешной работы с заказчиками необходимо планировать и выполнять при проведении проекта ПИ некоторые дополнительные предписанные моделью СММ деятельности, кроме непосредственно относящихся именно к разработке ПИ.
"Выполнение работ на фазах жизненного цикла" в этой деятельности занимает четверть объема. Однако это не означает, что трудоемкость подобной деятельности составляет четверть трудоемкости всего проекта ПИ. Следует стремиться к тому, чтобы в проекте ПИ все остальные деятельности, кроме деятельности "Выполнение работ на фазах жизненного цикла", имела в начале работы по правилам СП трудоемкость, не превышающую 15 % от общей трудоемкости проекта ПИ. В противном случае будет наблюдаться снижение эффективности работы исполнителей проекта и постепенное отторжение всеми сотрудниками организации установленного в ней СП.
В организации с хорошо организованным СП эта трудоемкость лежит в пределах 10-12 % от общей трудоемкости проекта ПИ (в ИДУ она составляет 12 %).
Кажущаяся дополнительная трудоемкость не является бесполезными накладными расходами на проект, она вполне допустима и оправдана, так как сторицей окупится теми достижениями организации, которые благодаря этому приобретает (повышение эффективности проектов, улучшение качества выпускаемых продуктов, достижение лучших показателей в своем классе и т.п.).
Из сказанного следует, что кажущаяся дополнительная трудоемкость в действительности является трудоемкостью, затрачиваемой на обеспечение надлежащего выполнения деятельностей на всех фазах жизненного цикла (ЖЦ) ПИ, поддержания целостности и высокого качества создаваемых продуктов, благодаря чему организация получает возможность добиться поставленной перед ней стратегической цели - стать лучшей в своем классе.
Структура практической модели СП с точки зрения разработчика, определяющего необходимое подмножество условий, правил и деятельностей СП, обеспечивает возможность наглядного представления перечня всех основных деятельностей технологии разработки ПИ для включения их в СП конкрет-
ной организации. Заметим, что для каждой организации должен создаваться собственный СП, который в своем роде является уникальным и наилучшим образом приспособлен (подогнан) именно к данной организации.
На рисунке 2 представлено графическое изображение еще одного представления практической модели СП, которое можно назвать представлением
модели СП с точки зрения исполнителя работ по проекту ПИ.
Конечно, существуют представления модели СП и с других точек зрения (администрации, бухгалтера, секретаря, технического работника, посетителя и т.д.), что несомненно может расширить и детализировать представление о технологии разработки ПИ и несколько улучшить определение СП. Однако приведенных на рисунках 1 и 2 описаний с практической точки зрения вполне достаточно для удовлетворительного определения СП.
Модель жизненного цикла ПИ СП
Как известно, любая разработка имеет свой ЖЦ, который определяет ее начало и конец. В [1] нет указаний на предпочтительную модель ЖЦ ПИ, в этом документе сказано только, что любая разработка ПИ должна иметь свою документированную и утвержденную модель ЖЦ ПИ.
Характерным свойством любого проекта ПИ является изменение представления о ПИ на всем протяжении разработки [3, 4]. Это свойство проекта ПИ является объективной реальностью, поскольку представления о ПИ изменяются в результате накопления новых знаний о нем в процессе выполнения разработки по мере приближения к ее завершению. Исходя из этого, в ИДУ в качестве модели ЖЦ ПИ была выбрана спираль, представленная на рисунке 3, которая включала семь фаз.
Фаза {1} - "Концептуализация проекта" ПИ (определение целей и задач проекта).
Фаза {2} - "Планирование и составление требований" (составление планов, требований заказчика к ПИ).
Фаза {3} - "Проектирование" ПИ (высокоуровневое проектирование, низкоуровневое (детальное) проектирование).
Фаза {4} - "Кодирование и отладка" (создание кодов ПИ, модульное и интеграционное тестирование, тестирование работоспособности).
Фаза {5} - "Системное тестирование" (подтверждение соответствия ПИ требованиям заказчика, подтверждение работоспособности ПИ, определение качества ПИ).
Фаза {6} - "Заключительная" (сдача ПИ заказчику, ретроспективный отчет о проекте).
Фаза {7} - "Сопровождение" (изменения ПИ, связанные с изменениями среды окружения и условий использования).
Первые пять фаз могут начинаться одновременно. Кроме того, первые две или три фазы могут быть охвачены обратной связью для уточнения результата работы на любой из них с разным числом итераций.
Фазы {4}, {5}, {6} и {7} выходят за границу спирали, а фаза {6} является заключительной при выполнении проекта ПИ. На этой фазе осуществляется сдача заказчику всех установленных контрактом продуктов и составление ретроспективного отчета о проекте с целью накопления и сохранения приобретенных знаний.
На фазе сопровождения основной является работа по выполнению изменений в ПИ, которые могут быть связаны с устранением обнаруженных дефектов при повседневной эксплуатации ПИ, с выполнением
дополнительных пожеланий заказчика и т.п.
Организации-субподрядчики, как правило, фазу {7} не включают в ЖЦ выпускаемых ПИ и сопровождением ПИ не занимаются.
Отметим, что существуют и другие модели ЖЦ ПИ (водопадная и др.). Мы ограничимся лишь подробным описанием спиралевидной модели (рис. 3).
Концептуализация проекта ПИ
Фаза концептуализации (Concept Exploration) является ключевой в НИР [4]. На ней выясняется степень актуальности проводимого исследования, точно формулируются цели, уточняются основные задачи
^Г Прямой поток данных при выполнении проекта ПИ
Поток данных при возврате на предшествующие фазы для уточнения результатов некоторых из них
Рис. 3. Спиральная модель ЖЦ ПИ, принятая в ИДУ
НИР и подходы к их решению. Именно здесь важную роль играют исследование состояния проблемы по литературе и быстрое прототипирование для уяснения важных частей предстоящей работы, для уточнения требований к новой НИР и расширения знаний о некоторых свойствах предметной области исследований для принятия обоснованных решений.
Как видно из рисунка 4, отдельные работы на фазе {1} могут уточняться в результате нескольких итераций, то есть модель структуры работ на фазе можно представить так же, как и модель ЖЦ, в виде спирали. Причем разные смежные работы могут
уточняться за различное число итераций.
Почти все работы, представленные на рисунке 4, не требуют комментариев.
Обратим внимание, что работа "Исследование состояния проблемы" заключается в исследовании литературных источников, поиске информации в Internet, изучении и обобщении существующих или близких решений, в рассмотрении альтернатив, ограничений, предположений, в формулировании целей проекта и т.п.
Важной работой на фазе является проведение семинаров с обзорами созданных продуктов и документов. Такие семинары являются активным средством обнаружения допущенных ошибок, повышения уровня обоснованности и достоверности полученных на фазе результатов.
Для обеспечения возможности оперативной оценки прогресса в выполнении проекта ПИ, оценки точности планирования и сроков выполнения, анализа метрических данных и выработки управляющих действий по управлению проектом, оценки качества выполненных работ и оценки других свойств проекта ПИ в организации должна существовать метрическая программа, определяющая перечень, порядок сбора, обработки, анализа и хранения метрик.
На протяжении фазы {1} обычно собираются метрики по трудоемкости всех выполняемых работ в часах (трудоемкости посещения библиотек, поиска информации в Internet, согласования с заказчиком и т.п. - по каждой работе в отдельности), по трудоемкости составления (или корректировки) документов (по каждому документу в отдельности). Все метрики должны сохраняться в метрической базе данных и
использоваться для анализа состояния проекта и управления им.
Документирование результатов плановых работ
С целью обеспечения возможности оперативного отслеживания выполнения и контроля за выполнением любой плановой работы целесообразно, чтобы каждый результат выполнения работы подлежал обязательному документированию, то есть документированный результат стал бы вехой окончания плановой работы. При этом условии не прошедший документирование результат выполнения работы не является вехой окончания работы, поэтому работа не может считаться выполненной.
Документированный результат выполнения любой плановой работы принято называть продуктом. Продукт может быть представлен в виде документа или программного кода.
Документирование продукта должно осуществляться по единым для организации шаблонам, в произвольной форме, быть в виде твердых бумажных копий и(или) в виде электронного файла. Для каждого продукта следует установить обязательную форму его представления.
Для всех видов документирования результатов плановых работ (исключая произвольный) должны быть разработаны шаблоны для обеспечения единообразия представления и облегчения выполнения предписанных СП действий по документированию. Такие шаблоны должны представлять собой электронные формы, которые следует только наполнить по определенным правилам конкретным содержанием (в соответствии с выполненной работой).
Следует стремиться к тому, чтобы шаблоны были легко читаемы и понятны для сотрудников управления, несложными в заполнении для исполнителей.
Планирование и составление требований
В действительности фаза {2} начинается практически одновременно с фазой {1} [3]. Результаты работ на фазах {1} и {2} могут оказывать взаимное влияние друг на друга, приводящее к их уточнению или корректировке. Такое взаимное влияние является характерным фактом для выполнения любого проекта ПИ и свидетельствует о верности пути его проведения.
На фазе {2} в обязательном порядке осуществляются работы по уточнению оценки общей трудоемкости проекта ПИ, возможных рисков и срока выполнения, по составлению требований заказчика к ПИ (спецификации функционального проектирования - СФП), по согласованию с заказчиком всех возникающих на фазе изменений.
На этой фазе также осуществляется планирование всех работ по контракту.
Рис. 4. Структура характерных работ на фазе _"Концептуализация проекта"_
Для повышения точности планирования целесообразно по каждому проекту ПИ иметь иерархию планов.
Сначала подробно планируются работы первого квартала, детально - только работы текущего (первого) месяца и подробно - работы только первых двух недель для каждого сотрудника проектной группы, а планы работ остальных месяцев и кварталов планируются укрупненно.
В конце каждой текущей недели осуществляется уточнение и детальное планирование работ на последующие две недели. При этом детальный план на следующий месяц должен быть готов к окончанию текущего месяца.
Процесс планирования является циклическим и начинается с изучения положения о работе (ПОР). Далее осуществляется структурирование предстоящей работы, в результате чего создается структура разделения работ (СРР) по созданию ПИ. По каждому элементу СРР производится оценка трудоемкости его выполнения. Далее определяется суммарная трудоемкость проекта и сравнивается с исходной. Если суммарная трудоемкость проекта превышает исходную, то необходимо повторять работу по структурированию для получения новой СРР до тех пор, пока не удастся уложиться в отведенные контрактом величины.
Конечно, могут быть случаи, когда не удастся привести в соответствие суммарную и исходную трудоемкость. Тогда необходимо отказаться от некоторых видов работ СРР или снова начать работу по согласованию трудоемкости проекта с заказчиком. Хороший проект ПИ отличается тем, что его руководитель никогда не доводит согласование трудоемкости проекта с заказчиком до фазы {2}.
По уточненной трудоемкости отдельных работ определяются необходимые людские ресурсы (ко всем работам приписываются исполнители) и строится график выполнения работ. Если по каким-либо причинам получается неудовлетворительный график, то цикл планирования повторяется. При этом не всегда обязательно повторять цикл планирования с начала.
Удачное планирование является залогом успеха проведения проекта в намеченные сроки без превышения установленного бюджета. Опыт выполнения программных проектов в организации ИДУ показывает, что подавляющее большинство руководителей проектов недооценивало важности планирования отдельных работ на фазах. Это регулярно приводило к возникновению критических ситуаций, разрешение которых требовало незапланированных дополнительных усилий.
На фазе {2} также составляются, согласовываются и утверждаются требования заказчика к ПИ.
Составление однозначных, хорошо понятных и тестируемых требований заказчика к ПИ является непростой задачей. Поэтому в организации должна быть разработана как один из компонентов СП специальная процедура для их составления, согласования и утверждения заказчиком и администрацией.
Большую пользу при составлении требований приносит конструирование прототипов, которое является эффективным механизмом анализа требований. Кроме того, прототипирование уменьшает риск выпуска некачественного ПИ, усиливает взаимодействие и взаимопонимание заказчика и разработчика. В практике составления требований существуют два вида прототипов: быстрый - прототип на выброс, эволюционный - прототип для последующей разработки.
Первый вид прототипа разрабатывается быстро (не более 2-3 дней). Как правило, программирование такого прототипа осуществляется на каком-либо языке высокого уровня. Этот вид прототипа создается для прототипирования только тех частей ПИ, которые менее всего понятны. Он используется для понимания или проверки некоторых требований, для тестирования отдельных требований на предмет возможности проектирования и т.п. Быстрый прототип строится без учета его качества, не документируется, не поставляется заказчику и после использования подлежит уничтожению.
Эволюционный прототип строится с теми же требованиями по качеству, как и само ПИ, по той же методологии проектирования и с тем же стилем кодирования, которые приняты в организации в качестве стандартов. Он применяется для прототипирова-ния только хорошо понятных частей ПИ. Каждый последующий прототип строится с учетом предыдущего. Все прототипы для разработки документируются, тестируются, сохраняются и поставляются заказчику.
На фазе {2} в обязательном порядке должны осуществляться обзоры проектного плана, требований заказчика к ПИ и других разработанных на фазе продуктов и документов. После обзоров продукты и документы фазы, поставляемые заказчику, должны пройти согласование и утверждение заказчиком и администрацией организации.
Все поставляемые заказчику продукты и документы помещаются в систему конфигурационного управления.
На протяжении фазы {2} собираются метрики по трудоемкости всех выполняемых работ в часах (по каждой работе в отдельности), метрики составления (или корректировки) документов (по каждому документу в отдельности). Кроме того, на фазе {2} собираются установленные в метрической программе метрики, по которым отслеживается точность планирования по различным показателям проекта ПИ (срокам выполнения отдельных работ на фазе и фазы в целом, точности оценок трудоемкости отдельных работ на фазе и фазы в целом). Все метрики должны сохраняться в метрических базах данных.
Проектирование ПИ
Фаза {3} обычно начинается практически одновременно с фазой {1}. Она предназначена для разработки высокоуровневой (высокоуровневое проектирование) и детализированной (детальное или низкоуровневое проектирование) модели заказанного ПИ.
Эти модели строятся в соответствии с проектным планом на основе декомпозиции требований заказчика к ПИ и определяют структуру ПИ (из каких компонентов ПИ состоит), организацию его компонентов, интерфейсов и структур данных для объединения компонент в единую систему, определяют алгоритмы реализации предписанных функций и т.п.
Модели ПИ, как правило, представляются совокупностью описаний компонентов проектирования (спецификаций проектирования). Например, в спецификациях детального проектирования для каждого компонента модели ПИ должны быть определены и описаны набор структур данных, перечень свойств ПИ и реализующих эти свойства алгоритмов, а также связей с другими компонентами и т.п.
Известно несколько способов построения моделей ПИ, приводящих к желаемому результату. Кроме того, у каждого высококвалифицированного программиста имеются свои секреты проектирования. Поэтому конкретный способ построения моделей ПИ не обязательно должен быть регламентирован СП.
Важно, чтобы в СП был определен обязательный к применению, необходимый для качественного и успешного построения моделей ПИ набор процедур, регламентирующих порядок выполнения проектирования, документирования, согласования и утверждения результатов проектирования администрацией.
Большую пользу для дальнейшего контроля правильности реализации требований заказчика в разрабатываемом ПИ приносит создание матрицы отслеживания (МО), заполнение которой начинается на фазе {3} и продолжается в течение {4}, {5} фаз ЖЦ. В МО каждому требованию заказчика к ПИ на фазе {3} ставятся в соответствие компоненты высокоуровневого и детального проектирования.
В процессе высокоуровневого и детального проектирования на фазе {3} отдельные работы так же, как и на фазе {2}, могут уточняться после обзоров результатов работы, то есть модель структуры работ на фазе тоже является циклической. Причем разные работы могут уточняться за различное число итераций.
Отметим, что обзоры продуктов и документов на фазе должны быть учтены в составленных на фазе {2} укрупненных планах. А на фазе {3} каждую неделю необходимо включать предстоящие обзоры в подробные планы последующей недели. Все обнаруженные на фазе в результате обзоров (в том числе заказчиком и администрацией) ошибки и дефекты должны в обязательном порядке помещаться в базу данных ошибок и дефектов.
Поставляемые заказчику продукты и документы фазы {3} в обязательном порядке должны быть помещены в систему конфигурационного управления.
На протяжении фазы собираются метрики по трудоемкости всех выполняемых работ в часах (по каждой работе на фазе в отдельности). Кроме того, на фазе {3} собираются установленные в метрической программе метрики, по которым отслеживается точность планирования по различным показателям фазы (срокам выполнения отдельных работ на фазе и
фазы в целом, по точности оценок трудоемкости отдельных работ на фазе и фазы в целом).
Все метрики должны сохраняться в метрических базах данных, обрабатываться и анализироваться с целью создания возможности улучшения количественных целей по качеству ПИ, производительности и сокращению длительности ЖЦ.
Кодирование и отладка
На фазе {4} осуществляется преобразование спецификаций высокоуровневого и низкоуровневого проектирования (результатов работ на предыдущей фазе ЖЦ) в коды программ на определенных в СП инструментальных средствах и языке программирования в соответствии с принятыми в организации стандартами и стилем кодирования.
Иными словами, на фазе {4} каждому компоненту спецификаций проектирования ставится в соответствие один программный модуль или совокупность модулей, реализованных по правилам СП.
Процесс кодирования и отладки следующий. Вначале создается базовая версия ПИ, заполняется матрица отслеживания, в которую заносятся имена программных модулей в соответствии с теми компонентами спецификаций проектирования, функции и задачи которых они выполняют.
После этого начинается кодирование программных модулей. По мере готовности кодов программных модулей (все программные модули должны быть помещены в систему управления кофигурацией ПИ) проводятся их обзоры. Далее осуществляется модульное тестирование [5], после чего определяется и создается сборка базовой версии ПИ. Начальная сборка базовой версии ПИ, как правило, реализует не все требования заказчика. Однако функциональное наполнение начальной сборки не выбирается произвольно, оно должно быть согласовано с заказчиком, потому что любая сборка версии ПИ является поставляемым продуктом. Каждая последующая сборка базовой версии ПИ должна отличаться от предыдущей более высокой степенью выполнения требований заказчика.
Отладка сборки базовой версии ПИ начинается с интеграционного тестирования [5], на котором проверяются прежде всего межмодульные интерфейсы. После успешного завершения интеграционного тестирования собранная версия ПИ должна подвергаться тестированию работоспособности.
После завершения тестирования работоспособности сборки необходимо провести ее обзор и определить готовность ее для передачи в группу системного тестирования. При успешном прохождении обзора сборки при необходимости проводится корректировка матрицы отслеживания. Матрица отслеживания должна передаваться в группу системного тестирования вместе с подлежащей системному тестированию сборкой базовой версии ПИ.
Совокупность модульного, интеграционного тестирования и тестирования работоспособности сборки базовой версии ПИ - это процесс выявления того,
насколько тестируемая сборка выполняет все предписанные для нее спецификациями проектирования функции и задачи (в литературе этот процесс часто называют верификацией сборки версии ПИ).
Обратим внимание на то, что все обнаруженные на фазе {4} ошибки и дефекты должны быть занесены в базу данных ошибок и дефектов, а все продукты и документы фазы должны проходить плановые обзоры и помещаться в систему управления конфигурацией ПИ.
На протяжении фазы также в обязательном порядке собираются метрики, которые должны сохраняться в метрической базе данных.
Системное тестирование
Фаза {5} заключается в выполнении системного тестирования [5] поступившей в группу системного тестирования сборки базовой версии ПИ.
Системное тестирование проводится с целью выявления надежности защиты версии ПИ от неумелых действий пользователя, выявления степени соответствия работы ПИ утвержденным требованиям заказчика и сопроводительным документам. Такое подтверждение в литературе называется валидацией ПИ.
Удачное выполнение работ по системному тестированию во многом зависит от срока начала фазы тестирования. Чем раньше начинается фаза системного тестирования, тем больше вероятность окончательного успеха. Лучшим началом для фазы {5} считается срок, в который один из тестировщиков (или руководитель группы системного тестирования) принимает участие в обсуждении планов по проекту ПИ и в составлении требований заказчика.
В начале фазы {5} должен создаваться план системного тестирования (ПСТ), согласованный с основными вехами проектного плана. ПСТ должен составлять назначаемый руководителем группы тестирования ответственный тестировщик. В ПСТ должна быть учтена трудоемкость на ознакомление с ПИ, на разработку процедуры системного тестирования, тестов, разработку автоматизированного тестового комплекта, на выполнение циклов и видов системного тестирования, на составление соответствующей отчетной документации.
Процедура системного тестирования - это документ, определяющий критерии успешного завершения всех видов системного тестирования и последовательность шагов, обеспечивающих запуск ручных тестов и автоматизированных тестовых комплектов.
Цикл системного тестирования - отрезок времени между моментом поступления сборки базовой версии ПИ для системного тестирования и моментом сдачи отчета о завершении одного выполнения всех предусмотренных ПСТ тестов и тестовых комплектов системного тестирования этой версии. Продолжительность цикла тестирования не должна превышать, как правило, одного месяца, а по каждой сборке базовой версии ПИ должно планироваться не менее трех циклов системного тестирования.
Системное тестирование заканчивается при удовлетворении определенных в СП критериев за-
вершения системного тестирования, после чего все полученные документы (включая матрицу отслеживания, в которой каждому требованию заказчика ставятся в соответствие имена тестов или тестовых комплектов) вместе с отчетом о системном тестировании должны быть переданы разработчикам ПИ.
Матрица отслеживания является эффективным средством контроля корректности реализации требований заказчика на фазах {3} и {4}. Использование матрицы создает удобства прослеживания правильности отображения требований заказчика в компоненты спецификаций проектирования и программные модули. Кроме того, матрица отслеживания создает возможность быстрой установки однозначного соответствия требований заказчика и программных модулей тестам и тестовым комплектам, для тестирования которых они предназначены.
Системное тестирование включает в себя несколько видов тестирования.
Инсталляционное тестирование позволяет подтвердить корректность работы средств установки ПИ на машине пользователя. При этом проверяются все возможности пользователя по инсталляции ПИ, правильность установки во всех указанных операционных средах, повторная инсталляция и прочее.
Функциональное тестирование обеспечивает выявление степени соответствия ПИ требованиям заказчика. Комплект функциональных тестов должен быть автоматизированным для обеспечения повышения эффективности выполнения операций регрессионного тестирования. Функциональные тесты должны покрывать 100 % требований заказчика к ПИ и, как правило, не менее 75 % требований операторов в программном коде ПИ.
Сценарное тестирование дает возможность проверить работу ПИ в условиях его эксплуатации. Тесты этой разновидности должны разрабатываться таким образом, чтобы их структура и порядок их выполнения (сценарий) соответствовали структуре пользовательских приложений и обычному порядку работы (сценарию) пользователя с данным ПИ.
Тестирование производительности, граничное тестирование проводятся для измерения характеристик быстродействия ПИ и проверки граничных условий его работы.
Тестирование взаимодействия со средой проверяет, что функционирование ПИ не сопровождается такими вредными эффектами, как утечка памяти, некорректная работа с файлами (например, файлы остаются открытыми после завершения работы с ними), некорректная работа с буферами (например, буферы не освобождаются после завершения работы приложения) и т.п.
Другие виды системного тестирования. К ним относятся тестирование на различных платформах, тестирование документации, соответствия условиям контракта, соответствия принятым стандартам и т.п.
На протяжении фазы {5} в обязательном порядке собираются метрики по трудоемкости всех выполняемых работ в часах (по каждой работе на фазе в отдельности, в том числе метрики составления плана
системного тестирования), а также метрики, специально установленные для фазы тестирования. Все метрики должны сохраняться в метрической базе данных группы тестирования.
Фаза {6} является заключительной в разработке программного изделия, на ней заканчиваются все работы по проекту ПИ. На этой фазе осуществляется сдача разработанного ПИ заказчику и проводится ретроспективный обзор проекта в целом.
Для корректного выполнения поставок заказчику в организации должен быть разработан и строго соблюдаться документ, который определяет классификацию поставок продуктов, обязательный для каждой поставки набор требований, процедуру формирования и передачи поставки заказчику.
Следует помнить, что даты поставок определяются на фазе планирования, утверждаются заказчиком и руководством компании. Как правило, на протяжении проекта планируется не менее трех поставок. К первой поставке обычно предъявляется минимальный из имеющихся набор требований, к завершающей - максимальный.
Отправка поставки ПИ должна предваряться обзором поставки, проводимым с участием группы, ответственной за СП, ответственного системного тес-тировщика по ПИ и представителя руководства компании. Для проведения обзора поставки назначается руководитель обзора, который отвечает за его подготовку и проведение в соответствии с процедурой, определенной в СП. В ходе обзора проверяется полнота поставляемого продукта, наличие необходимых документов, рассматривается содержание документов и качество поставляемого ПИ.
Еще одним обязательным создаваемым на фазе {6} документом является ретроспективный отчет по проекту ПИ. На протяжении фазы {6} также собираются установленные метрики, которые должны сохраняться в метрической базе данных.
Сопровождение
Сопровождение ПИ - это процесс адаптации поставленного ПИ к новым условиям использования при сохранении неизменными основных функций.
При сопровождении ПИ обычно производится его исправление, не затрагивающее функционального назначения ПИ и включающее в себя локализацию и устранение обнаруженных дефектов в программных
модулях ПИ, переработку интерфейсных программных модулей, модификацию кодов, документации или структуры баз данных ПИ и т.п.
В результате сопровождения может возникнуть необходимость обновления ПИ, приводящего к изменениям функциональных возможностей. В этом случае следует подавать в поставляющую ПИ организацию заявки на его обновление, которое осуществляется по специальной процедуре, определенной в СП.
В организации должна быть установлена постоянно обновляемая база данных сопровождения, в которую следует заносить выявленные на фазе сопровождения дефекты, результаты анализа причин возникновения дефектов, метрики фазы, предложения по улучшению некоторых характеристик ПИ и т.п.
В настоящей статье приведен пример некоторых составляющих реального СП организации ИДУ, строгое соблюдение всех компонент которого позволило ИДУ за полтора года успешно пройти оценивание внешней компетентной комиссией на соответствие третьему уровню зрелости по модели СММ. К этому времени в ИДУ было выпущено несколько ПИ по требованиям заказчика для различных предметных областей с качеством пять сигма.
Авторы статьи надеются, что описанный опыт поможет руководителям предприятий, специализирующихся на выпуске ПИ для рынка программного обеспечения, и отдельным программистам правильно сориентироваться и сократить время при переходе на работу в соответствии с СП по модели СММ.
Список литературы
1. Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.
2. Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.
3. Boehm B.W. Software Engineering Economics. -Englewood Cliffs: Prentice Hall, 1981. - 767 p. - Русс. пер.: Боэм Б.У. Инженерное проектирование программного обеспечения /Пер. с англ. - М.: Радио и связь, 1985. - 512 с.
4. Ruskin A.M., Estes W.E. What Every Engineer Should Know about Project Management. - New York: Marcel Dekker, Inc., 1994. - 276 p.
5. Myers G.J. The Art of Software Testing. - New York: John Wiley & Sons, 1979, 177p.
ПАСПОРТ СТАНДАРТНОГО ПРОЦЕССА
А.Н. Домарацкий, В.П. Морозов
Паспорт стандартного процесса (СП) является документом, разработанным в АОЗТ "Информационные деловые услуги" (ИДУ), содержащим основные характеристики статуса СП в соответствии с моде-
лью СММ.* Он используется в ИДУ для самооценивания степени достижения отдельными проектными
* Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software
