Материал: DO178 Учебное пособие_в183

Табл. 3. Уровни сигма и оценка числа остаточных дефектов

Если объем кода программного продукта в KLOC или KAELOC легко измерить или подсчитать, то как быть с плотностью совершения ошибок? На практике она определяется постепенно, путем фиксирования в БД проектов и подсчета всех найденных ошибок. Если таких проектов выполнено достаточно много для статистически значимой выборки, то по ним можно вычислить среднее значение этой величины, с определенной поправкой на ошибки, оставшиеся не найденными (эта поправка определяется экспертным путем). Интересно отметить, что это значение меняется достаточно медленно и является индивидуальным для данного разработчика или группы разработчиков на протяжении длительного периода времени.

Кроме того, из практики замечено, что плотность ошибок при внесении изменений в код (в частности, при исправлении уже найденных ошибок) в 3 раза выше, чем обычная плотность совершения ошибок при написании кода заново. Это означает, что при внесении изменений в код надо быть предельно внимательным и учитывать это отличие при планировании таких деятельностей.

5. Экран проекта и сводка о подходе

Для программного проекта очень полезно уже в начале работы создать его аннотацию (annotation) и одностраничную сводку (executive summary) по применяемым в нем решениям. Аннотация – это 2-3 предложения, определяющих суть проекта, его важность и место среди других аналогичных разработок. Примеры:

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

Рис. 5. Пример формы для одностраничной сводки о подходе (решении)

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

2. Критерий smart для формулирования целей

Формулирование целей (целеполагание) в производственном процессе является очень важным шагом для дальнейшего успеха проекта. Большую проблему в практической работе представляет неумение разработчиков четко формулировать поставленные цели и критерии их достижения в объективно измеряемых показателях.

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

Specific – конкретна в своей формулировке;

Measurable – измеряема в каких-либо единицах объективным образом;

Achievable – достижима (реалистична) в данных условиях;

Result-focused – нацелена на ощутимый и очевидный результат;

Time-framed – должна быть достигнута к определенному сроку.

Например, если целью разработки программной системы X является переход организации-заказчика на эту систему, то очевидно несоответствие данной формулировки критерию SMART. Другой формулировкой той же цели, но уже удовлетворяющей критерию SMART, могла бы быть такая: «За счет внедрения системы Х к 1 мая сократить среднее время обслуживания клиента на 15%». В такой формулировке цели видны конкретность (внедрение системы X), ожидаемый результат (сокращение среднего времени обслуживания клиентов) и его объективная измеряемость (15% от известного текущего значения), достижимость (за счет внедрения системы X) и конкретный срок (1 мая).

В искусстве целеполагания применяется иерархия целей: каждая цель может быть рассмотрена как средство для достижения еще более высокой цели. Такая лестница целей, аналогичная иерархии (пирамиде) потребностей по Маслоу (Abraham H. Maslow) [16], помогает лучше оценить и понять место каждой частной цели в общей структуре деятельностей по достижению «главных целей» данного программного проекта.

3. Критерии успешности программного проекта

Все закончившиеся программные проекты можно разделить на две группы: успешные и неуспешные (неудачные), причем успех или неудача проекта должны быть понятны уже в момент его завершения. Для этого необходимы четкие и объективные критерии успешности, согласованные с заказчиком, поскольку решение об успешности или неудаче проекта в модели «Заказчик-исполнитель» принимается обеими сторонами согласно во время приемки-сдачи программного продукта – в конце заключительного этапа его разработки; в случае их разногласия окончательное решение может быть вынесено незаинтересованной третьей стороной (арбитром), в достаточной степени объективной, на основании представленных документов о проекте, включающих эти самые критерии успешности.

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

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

4. Модели жизненного цикла

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

Рис. 6. Обобщенная схема повторяемого процесса разработки

Общая схема модель жизненного цикла представлена на Рис. 6. Модель структурирует процесс разработки, выделяя в нем отдельные фазы (phases) или этапы (milestones), исполнение которых может совмещаться во времени и состоять из нескольких более мелких этапов. На каждом этапе исполняются определенные для этапа деятельности (activities), результатом которых являются рабочие продукты (work products) в виде некоторых документов (documents), создаваемых в ходе их исполнения. Примером таких документов являются исходный код, отчет о тестировании, отчет об исправлении дефектов. Рабочие продукты, поставляемые заказчику в ходе проекта, называются поставками (deliverables), и для них определяются сроки, формы и способы поставок (в электронном виде, на магнитном или ином носителе или еще как-нибудь), причем датой поставки считается не дата отправки исполнителем данного рабочего продукта заказчику, а подтвержденная дата получения этой поставки заказчиком.

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

Типичными деятельностями в этой обобщенной схеме являются:

• на фазе анализа –

• планирование проекта (project planning)

• сбор и анализ требований (requirements gathering and analysis);

• на фазе проектирования –

• предварительное или высокоуровневое проектирование (preliminary / high-level design)

• подробное или низкоуровневое проектирование (detailed / low-level design);

• на фазе реализации –

• кодирование модульное тестирование (coding and unit testing);

• на фазе обозрения –

• интеграционное тестирование (integration testing);

• системное тестирование (system testing).

Для малых проектов данная схема сводится к следующим основным фазам:

1. Спланировать (plan) – определить функциональные требования, привязав их к ПО и к аппаратуре, и по ним создать план разработки, включающий перечень поставляемых рабочих продуктов, оценку ресурсов и определение процессов поддержки;

2. Специфицировать (specify) – точно определить внешние характеристики будущей программы с точки зрения пользователя (например, через прототипирование и предъявление пользователям); провести обзор спецификаций как минимум с участием инженера-проектировщика, основных пользователей и заказчика;

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

4. После завершения (post-mortem) – проанализировать проделанную работу, проверив, что все плановые поставки завершены; сравнить результаты работ с требованиями пользователя по качеству; сравнить фактические результаты с первоначальными оценками, объяснив все расхождения.

Наличие проговоренной и понятной модели ЖЦ и следование ей в процессе разработки имеет следующие положительные следствия для хода проекта:

1. Модель способствует определению требований до проектирования системы – надо определить, что система должна делать ДО ее создания;

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

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

4. Модель дает возможность руководству проектом тщательно отслеживать его продвижение – руководство должно располагать базовыми стандартами для измерения качества продукта и производительности, как самого процесса разработки, так и разработчиков;

5. Модель снижает затраты на разработку и сопровождение – все предыдущее этому способствует;

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

Благодаря следованию какой-либо известной модели ЖЦ, организация-разработчик получает следующие преимущества:

1. Улучшается качество продукта через согласованность в его разработке – продукт определяется как состоящий из всех поставляемых рабочих продуктов его жизненного цикла;

2. Облегчается управление проектами – сравнение с известными стандартами выявляет проблемы, требующие решения;

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

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

5. По мере исправления организационных слабостей растет уровень зрелости организации-разработчика – когда недостатки процесса исправляются, организация переходит на более высокий уровень зрелости, как это определяется моделями зрелости CMM/CMMI.

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