Цель - инженерия программ

Качество процесса

Факторы процесса оценивают качество механизмов, применяемых для создания ПО. Они включают:

• скорость разработки: способность поставлять продукт в сжатые сроки. Каждый проект должен заботиться об этом, клиенты ждут, конкуренты не дремлют, акционеры размышляют;
• эффективность стоимости. Об этом также заботятся почти все проекты. В инженерии программ (в отличие от некоторых других видов инженерии) стоимость готового продукта незначительна. Над всем доминирует стоимость разработки (за исключением, возможно, расходов на маркетинг, которые могут быть существенными, особенно для продуктов, ориентированных на массовый рынок). Стоимость разработки определяют затраты на персонал, оборудование, офис. По этой причине стандартной мерой стоимости является человеко-месяц: средняя стоимость расходов на одного работника в месяц (все включено);
• эффективность сотрудничества: эффективность процедур, обеспечивающих наилучшее взаимодействие всех членов команды, работающей над проектом. Серьезные проекты могут включать большое число участников. Требуется уделять особое внимание механизмам координации. Коммуникация участников — довольно деликатная проблема, которая для команд большого размера может перевесить все остальные аспекты разработки. Экстремальная форма этого феномена известна как закон Брукса (по имени проектировщика операционной системы IBM OS/360), который говорит, что "добавление людей в проект, не укладывающийся в сроки, удлиняет время разработки". Хотя можно считать, что этот закон верен только для плохо управляемых проектов, но он ясно характеризует суть проблемы коммуникации;
• вовлеченность сопричастников: степень учета в проекте всех релевантных потребностей и точек зрения людей, так или иначе вовлеченных в проект;
• встроенное оценивание: включение в процесс механизмов и процедур, измеряющих факторы качества на хорошо определенных этапах. Качество не должно только декларироваться, но его нужно проверять и принуждать к его соблюдению. Хорошо организованный процесс интегрирует эту задачу как один из своих компонентов;
• предсказуемость: включение в процесс надежных методов оценивания других факторов качества — в частности, скорости и стоимости разработки. Предсказуемость — одна из наиболее важных характеристик хорошего процесса. Иногда гарантированная дата так же важна, как и ранняя дата. В ИТ-индустрии нет достаточной статистики в этой области, мы не знаем, сколь много проектов не выдерживали сроков и выходили за рамки отведённого бюджета. Ситуация с годами улучшается благодаря применению принципов и методов инженерии программ;
• измеримость: пригодность количественных критериев для определения достижимости других факторов качества, как процесса, так и продукта, например, методы измерения уровня ошибок. Эффективное управление нуждается в точных измерениях развития проекта. Этот критерий тесно связан с двумя предшествующими, так как, чтобы делать предсказания и давать оценки, требуется возможность проведения измерений;
• воспроизводимость: независимость разработки, методов управления и предсказания от несущественных атрибутов конкретных проектов. В большинстве случаев индустриальная разработка проекта не ведется изолировано. Крайне важно достигнутые успешные результаты в одном проекте воспроизводить в других проектах (ошибки в проектах также заслуживают тщательного анализа);
• самосовершенствование: включение в саму спецификацию процесса механизмов, квалифицирующих и улучшающих этот процесс. Организации, подобно людям, могут обучаться на собственном опыте. Критерий самосовершенствования оценивает, в какой степени процесс, определённый в организации, отвечает этому феномену, за счет включения встроенных механизмов оценки, которые могут служить обратной связью для процесса, адаптируя его в соответствии с уроками обучения.

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

Компромиссы

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

• Компромисс между факторами процесса и продукта: совершенствование продукта может отрицательно воздействовать на фактор "скорость разработки".
• Компромисс между факторами продукта: простота использования не всегда сочетается с безопасностью, так как мы хотим сделать продукт простым для законных пользователей. Пароли плохи с позиций простоты, но хороши для безопасности. Оптимизация в интересах эффективности может конфликтовать с простотой исправлений (так как может приводить к хитро закрученному коду). Эффективность, учитывающая особенности конкретной платформы и контекста, конфликтует с расширяемостью, переносимостью и повторным использованием.

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

Главные виды деятельности в процессе разработки ПО

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

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

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

• Функциональные требования, описывающие результаты или действия системы: "Если телефон пользователя переходит из одной области покрытия в другую, то соединение автоматически должно переключаться на точку доступа в новой области".
• Нефункциональные требования, специфицирующие ограничения на операции системы. Они включают требования к производительности, например, временные ("Для точки доступа, отстоящей менее чем на два километра, время переключения должно занимать не более одной секунды"). Здесь же задаются ограничения на память, безопасность ("все сообщения, передаваемые через точку доступа, должны быть зашифрованы"), пропускную способность. Они также покрывают воздействие на системное окружение и людей, таких как служащие: влияние на практику их работы.

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

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

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

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

Создание документации представляет задачу описания различных аспектов системы, чтобы помочь ее пользователям и другим сопричастникам, в частности, разработчикам. Помимо документов, создаваемых для пользователей, она может включать планы проекта (для менеджеров), документы требований, спецификации, планы проектирования. Слово "документ" заменило более традиционное слово "отчет", представляемый обычно как бумажный документ. Сегодняшняя документация представляется в электронном виде, как Web-страницы, онлайновая справка, регулярно обновляемая. Документация является частью программного текста в виде заголовочных комментариев — специальных документируемых комментариев, которые есть в таких языках, как Eiffel, Java и C#.

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

• Верификация является внутренней оценкой согласованности продукта, рассматриваемого сам по себе. Типичный пример: на уровне реализации проверка типов позволяет предотвратить использование переменной, объявленной REAL , как если бы она имела тип INTEGER .
• Проверка правильности дает оценку продукта по отношению свойств, которые должны выполняться: код сравнивается с проектом, проект — со спецификациями, спецификации — с требованиями, документация — со стандартами, применяемые практики — с правилами компании, даты поставки — с намеченными сроками, обнаруженные уровни дефектов — с заявленными целями, набор тестов — со сферой действия метрик. Популярная версия, характеризующая разницу между верификацией и проверкой правильности, утверждает, что верификация проверяет, "делаются ли вещи правильно", в то время как проверка правильности проверяет, "делаются ли правильные вещи".

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

Модели жизненного цикла и разработка в стиле AGILE

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

Модель водопада

Рис. 9.3. Модель водопада

Начальной точкой всех обсуждений моделей жизненного цикла являлась статья 1970 года, посвященная модели водопада (которая фактически была написана ради критики модели, но служит теперь как ссылка на определение этого понятия). Идея "водопада" проста — задачи выполняются в определенном порядке.

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

Этот и некоторые другие элементы этого раздела являются адаптированными материалами главы 28 из моей книги "Объектно-ориентированное конструирование программных систем", 2006 г., которая содержит более детальное обсуждение моделей процесса.

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