Нормативные документы и жизненный цикл ПО. Стандарты ЕСПД

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

Теоретический материал

После системного анализа предметной области и построения концептуальной модели, содержащей описание основных компонентов и функций (Лабораторная работа № 1-3), выполняется проектирование структуры приложения. Результатом на этапе проектирования структуры приложения становится детализированная схема программы, на которой указываются все классы и взаимосвязи между ними. Оформление результатов системного анализа предметной области и проектирования структуры приложения должно выполняться единообразно. Существует не одна группа документов рекомендательного характера, позволяющих придерживаться общих принципов.

Для выполнения практических заданий необходимо предварительно ознакомится с [9, 10].

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

Стандарт – (от англ. standard – норма, образец), в широком смысле слова образец, эталон, модель, принимаемые за исходные для сопоставления с ними др. подобных объектов. Стандарт как нормативно-технический документ устанавливает комплекс норм, правил, требований к объекту стандартизации. Стандарт может быть разработан как на материальные предметы (продукцию, эталоны, образцы веществ), так и на нормы, правила, требования в различных областях [9]. Стандарт также может содержать требования к терминологии, символике, упаковке, маркировке или этикеткам и правилам их нанесения.

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт по ISO/IEC 12207:1995.

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

Состав процессов жизненного цикла регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technology – Software Life Cycle Processes» («Информационные технологии – Процессы жизненного цикла программного обеспечения»). ISO – International Organization for Standardization – Международная организация по стандартизации. IEC (International Electrotechnical Commission) – Международная комиссия по электротехнике.

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

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

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

Рисунок 5.1 - Относительная стоимость исправлений ошибок в требованиях в зависимости от того, когда они обнаружены [24]

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

Рисунок 5.2 - Взаимоотношения требований и других процессов проекта

Что называть «требованием к ПО»? Одна из проблем индустрии программного обеспечения — отсутствие общепринятых определений терминов, используемых для описания работы.

IEEE Standard Glossary of Software Engineering Terminology (1990) содержит следующее определение термина «требования»:

– условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

– документированное представление условий или возможностей для пунктов 1 и 2.

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

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

Процесс создания требований состоит из выявления, анализа, спецификации и проверки требований (рисунок 5.3), и он не выполняется последовательно и за один проход.

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

Рисунок 5.3 - Компоненты области разработки технических условий

На практике эти действия выполняются попеременно, поэтапно и повторяются (рисунок 5.4). Процесс формулирования требований очень важен, и все участники проекта должны понимать концепцию и приемы формулирования требований [24]. Пример разработки требований к системе представлен в Приложении А.

Во время работы с проектом разработчик ПО сталкивается с тремя уровнями требований: бизнес-уровень, пользовательский уровень и функциональный.

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

Составлению технического задания предшествует составление «Спецификаций требований».

Спецификация – достаточно точное и полное описание задачи, доступное для понимания всех заинтересованных лиц.

Спецификация требований (specification, requirements) – процесс документирования системы в структурированном, доступном всем и управляемом формате [24].

Рисунок 5.4 - Итеративный процесс формирования требований

 

Спецификация требований к продукту (software requirements specification) – набор функциональных и нефункциональных требований к продукту ПО.

Анализ включает создание прототипов, анализ осуществимости и согласованности приоритетов.

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

Виды прототипов: эволюционные, одноразовые, бумажные, горизонтальные и вертикальные.

Модели прецедентов описывает способ взаимодействия пользователя с системой.

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

Любое техническое задание должно содержать разделы, отражающие сведения:

– что надо сделать;

– для чего, с какой целью надо создать продукт;

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

– какие требования будут предъявлены к продукту;

– какие работы потребуется выполнить, чтобы создать продукт;

– каков порядок приемки-сдачи работ Заказчику;

– как должно быть задокументировано проведение работ;

– на основании каких нормативно-технических документов должны проводиться работы.

При разработке технического задания на автоматизированную систему используется ГОСТ 34.602-89, при разработке ТЗ на программу - ГОСТ 19.201-78.

В основе методов управления проектами [34] лежат методики сетевого планирования:

– заблаговременное планирование работ над проектом;

– планирование завершения работ в нужные сроки;

– координирование и контролирование выполнения работ для соблюдения календарного графика и завершение работ в срок.

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

Существует несколько методик оценок времени и затрат.

Вопросы для самоконтроля

1. Дать определения:

– программа;

– программный продукт;

– программное средство;

– ПО;

– жизненный цикл ПО;

– качество ПО.

2. Дать определение терминов: «требования», «спецификация».

3. Что подразумевается под «успех проекта»?

4. Характеристики превосходных требований.

5. Какой стандарт ЕСПД определяет содержание Технического задания? Назначение документа и его обязательные разделы.

6. Характеристика основных уровней стандартизации.

7. Стандарты документирования ПО. Перечислите основные виды нормативных документов.

8. Какие проблемы сопровождают внутрифирменные стандарты?

9. Схема классификации стандартов в области ИТ.

10. Эволюция стандартов ПО.

11. ЖЦ ПО. Эволюция ЖЦ ПО (по ISO/IEC 12207:1995). Процессы ЖЦ, регламентируемые стандартом ISO/IEC 12207.

12. Содержание государственного стандарта «Единая система программной документации».

13. Критерии качества ПО, факторы влияющие на качество ПО.

14. Уровни требований к ПО.

Практическая работа

Цели: закрепление основных понятий, связанных с жизненным циклом программного обеспечения.

Средства выполнения задания: средства пакета MS Office.

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

Практическое задание

1. Описать требования в контексте модели прецедентов (Приложение Б).

2. Создать одностраничный проект на разработку автоматизированной системы (Приложение В).

3. Создать шаблон технического задания на разработку ИС. Создать техническое задание на разработку ИС Вашего варианта.

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

Лабораторная работа № 6