
- •Кризис программирования и способ выхода из него
- •Модель cmm-sei
- •Управление качеством разработки программного продукта с помощью системы стандартов iso 9001
- •Примерная структура процесса и организации, занимающейся разработкой программных продуктов
- •Контрольные вопросы
- •Оценка технических, нетехнических и финансовых ресурсов для выполнения программного проекта
- •Оценка возможных рисков при выполнении программного проекта
- •6.5. Составление временного графика выполнения программного проекта
- •Собираемые метрики, используемые методы, стандарты и шаблоны
- •Контрольные вопросы
- •Конструирование прототипа
- •Составление спецификаций по требованиям заказчика
- •Собираемые метрики, используемые методы, стандарты и шаблоны
- •Контрольные вопросы
- •Эволюция разработки программного продукта
- •Структурное программирование
- •Объектно-ориентированное проектирование
- •Собираемые метрики, используемые методы, стандарты и шаблоны
- •Контрольные вопросы
- •Тестирование
- •Разработка справочной системы программного продукта. Создание документации пользователя
- •Создание версии и инсталляции программного продукта
- •Собираемые метрики, используемые методы, стандарты и шаблоны
- •Контрольные вопросы
- •Виды тестирования
- •Программные ошибки
- •Тестирование документации
- •Разработка и выполнение тестов
- •Требования к хорошему тесту
- •Классы эквивалентности и граничные условия
- •Тестирование переходов между состояниями
- •Условия гонок и другие временные зависимости
- •Нагрузочные испытания
- •Прогнозирование ошибок
- •Тестирование функциональной эквивалентности
- •Регрессионное тестирование
- •Собираемые метрики, используемые методы, стандарты и шаблоны
- •Контрольные вопросы
- •1. Подготовительная работа, предусматривающая:
- •Контрольные вопросы
- •Классификация поставляемых программных продуктов
- •Действия, выполняемые при поставке программного продукта
- •Контрольные вопросы
- •Основные понятия о надежности программных продуктов и методах ее обеспечения
- •Методы обеспечения надежности на различных этапах жизненного цикла разработки программного продукта
- •Прогнозирование ошибок
- •Шаблон для учета итоговых сведений об ошибках
- •Предотвращение ошибок
- •Шаблон для учета действий по предотвращению ошибок на этапах составления требований, проектирования и разработки
- •Устранение ошибок
- •Обеспечение отказоустойчивости
- •Инструменты, обеспечивающие надежность программных продуктов. План обеспечения надежности
- •Контрольные вопросы
ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ПРОДУКТА
Кризис программирования и способ выхода из него
Программы не появляются сами по себе, даже основываясь на самых лучших методологиях и образцах. Программа — это результат деятельности людей, и от того, как организован труд этих людей, в огромной степени зависит качество разрабатываемого
ПП.
В начале 1970-х годов в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный ПП не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Аналитические исследования и обзоры, выполнявшиеся в последние годы ведущими зарубежными аналитиками, дают не слишком обнадеживающие результаты. Например, в 1995 г. компания Standish Group проанализировала работу 364 американских корпораций, а также итоги выполнения более 23 тыс. проектов, связанных с разработкой ПП, и сделала следующие выводы:
только 16,2 % проектов завершились в срок, не превысили запланированный бюджет и обеспечили реализацию всех требуемых функций и возможностей;
52,7 % проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
31,1 % проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет в среднем оказался превышен на 89 %, а срок выполнения — на 122 %.
В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую сторону (26, 46 и 28 % соответственно).
В числе причин возможных неудач фигурируют: нечеткая и неполная формулировка требований к ПП, недостаточное вовлечение пользователей в работу над проектом, отсутствие необходимых ресурсов, неудовлетворительное планирование, частое изменение требований и спецификаций, новизна используемой технологии для организации, отсутствие грамотного управления проектом, недостаточная поддержка со стороны высшего руководства.
В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что большое число проектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Иордана, одного из ведущих мировых специалистов в области программной инженерии, утвердилось выражение «death march» — буквально «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50 %. По отношению к проектам создания ПП это означает наличие, как минимум, одного из следующих ограничений:
план проекта сжат более чем на половину по сравнению с нормальным расчетным планом, т.е. работа, требующая в нормальных условиях 12 мес, должна быть выполнена за 6 мес или менее. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной;
число разработчиков уменьшено более чем на половину по сравнению с действительно необходимым для проекта данного масштаба, как правило, по причине сокращения штатов компании в результате кризиса, реорганизации и т.д.;
бюджет и связанные с ним ресурсы урезаны наполовину (результат сокращения компании и других противозатратных мер или конкурентной борьбы за выгодный контракт), что влечет за собой уменьшение числа нанимаемых разработчиков или привлечение малооплачиваемых неопытных молодых работников;
требования к функциям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях.
Потребность контролировать процесс разработки ПП, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 1970-х годов к необходимости перехода от кустарных к индустриальным способам создания ПП и появлению совокупности инженерных методов и средств создания ПП, объединенных общим названием «программная инженерия» (software engineering). Впервые этот термин прозвучал в качестве названия темы конференции, проводившейся под эгидой НАТО в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция по программной инженерии. Тогда же появилось первое издание, посвященное программной инженерии, — «IEEE. Transactions on Software Engineering» («IEEE. Труды по программной инженерии»).
В процессе становления и развития программной инженерии можно выделить два этапа: 1970-е и 1980-е годы — систематизация и стандартизация процессов создания ПП (на основе структурного подхода); 1990-е годы — начало перехода к сборочному, индустриальному способу создания ПП (на основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея: проектирование ПП является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПП позволяют повысить его качество, обеспечивают управляемость процесса проектирования ПП и увеличивают срок его жизни.
При любых изменениях в процессе разработки ПП необходимо иметь критерии, позволяющие оценить эффект от проведенных изменений. Другими словами, необходимы методы, позволяющие измерять качество и эффективность работы организации. Под организацией понимается совокупность всех групп разработчиков проектов (каждый проект направлен на создание своего ПП) и администрации, связанных одним процессом.
В настоящее время существуют две общепринятые методики оценки состояния процесса разработки программного обеспечения: международный стандарт ISO 9001 и модель CMM-SEI — Capability Maturity Model (модель оценки зрелости технологических процессов в организации), разработанная в Software Engineering Institute (Институт программной инженерии).