Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;

необходимость выполнения ещё одной итерации;

степень полноты и точности понимания требований к системе;

целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID[3].

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

Дефицит специалистов.

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

Перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

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

Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

Недостаточная производительность получаемой системы.

Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек:

Concept of Operations (COO) — концепция (использования) системы;

Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

Initial Operational Capability (ioc) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Схема процесса создания загрузочного модуля программы

Трансляция может выполняться с использованием средств компиляторов (compiler) или интерпретаторов (interpreter). Компиляторы транслируют всю программу, но без ее выполнения. Интерпретаторы, в отличие от компиляторов, выполняют пооператорную обработку и выполнение программы.

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

Более мощным средством разработки программ являются системы программирования.

Системы программирования (programming system) включают:

§ компилятор;

§ интегрированную среду разработчика программ;

§ отладчик;

§ средства оптимизации кода программ;

§ набор библиотек (возможно с исходными текстами программ);

§ редактор связей;

§ сервисные средства (утилиты) для работы с библиотеками текстовыми и двоичными файлами;

§ справочные системы;

§ документатор исходного кода программы;

§ систему поддержки и управления проектом программного комплекса.

Средства поддержки проектов - новый класс средств разработки программного обеспечения, предназначенный для:

§ отслеживания изменений, выполненных разработчиками программ;

§ поддержки версий программы с автоматической разноской изменений;

§ получения статистики о ходе работ проекта.

Инструментальная среда пользователя представлена

специальными средствами, встроенными в пакеты прикладных программ, такими, как:

§ библиотека функций, процедур, объектов и методов обработки;

§ макрокоманды;

§ клавишные макросы; языковые макросы;

§ программные модули-вставки; конструкторы экранных форм и отчетов;

§ генераторы приложений; языки запросов высокого уровня;

§ языки манипулирования данными; конструкторы меню и многое другое.

Средства отладки и тестирования программ предназначены для подготовки разработанной программы к промышленной эксплуатации.

Интегрированные среды разработки программ

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

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

Документирование программного обеспечения

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы: что должно быть сделано, кроме собственно программы? что и как должно быть оформлено в виде документации? что передавать пользователям, а что — службе сопровождения? как управлять всем этим процессом? Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование? Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текст своих программ. Это не значит, что исчезла необходимость в их документировании. Более того, вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств, продолжают задавать постоянно. Спрашивают и о том, есть ли обязательные для применения стандарты (особенно остро стоит этот вопрос, когда разработка выполняется по заказу государственной организации или предприятия). Интересуются и тем, где можно купить имеющиеся стандарты.

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

Техническое задание

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

Техническое задание на разработку ПО должно включать следующие разделы:

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

Эксплуатационные документы

ГОСТ 2.601-2006 ЕСКД. Эксплуатационные документы.

ГОСТ 2.602-95 ЕСКД. Ремонтные документы.

ГОСТ 2.603-68 ЕСКД. Внесение изменений в эксплуатационную и ремонтную документацию.

ГОСТ 2.604-2000 ЕСКД. Чертежи ремонтные. Общие требования.

ГОСТ 2.605-68 ЕСКД. Плакаты учебно-технические. Общие технические требования.

ГОСТ 2.608-78 ЕСКД. Порядок записи сведений о драгоценных материалах в эксплуатационных документах.

ГОСТ 2.610-2006 ЕСКД. Правила выполнения эксплуатационных документов.

Источники:

1. Модели ЖЦ

http://ru.wikipedia.org/wiki/Жизненный_цикл_программного_обеспечения

2. Схема процесса создания загрузочного модуля

http://vmg.pp.ua/books/КопьютерыИсети/_ПРОЧЕЕ/metodFromInet/Информатика%20и%20программирование%20ПИвЭ/Consp%20I/23/inf23lec.htm

3. Документация ПП

http://ru.wikipedia.org/wiki

4. Техническое задание

http://ru.wikipedia.org/wiki/%D2%E5%F5%ED%E8%F7%E5%F1%EA%EE%E5_%E7%E0%E4%E0%ED%E8%E5

5. Эксплуатационная документация

http://instrukcii-dokumenty.ru/index/ehkspluatacionnaja_dokumentacija_ehd/0-5