Модуль III. Виды обеспечения АСОИУ

12. Программное обеспечение АСОИУ. Структура программного обеспечения. Управление требованиями к ПО АСОИУ

 

Программное обеспечение АСОИУ.

Под программным обеспечением автоматизированной системы понимается совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АСОИУ [1]. Программное изделие в АСОИУ – это программное средство, изготовленное, прошедшее испытания установленного вида и поставляемое как продукция производственно-технического назначения для применения в АСОИУ.

Программно-технический комплекс автоматизированной системы (ПТК АС) - продукция, представляющая собой совокупность средств вычислительной техники, программного обеспечения и средств создания и заполнения машинной информационной базы при вводе системы в действие достаточных для выполнения одной или более задач АСОИУ. При реализации нескольких программ в рамках одной системы необходимо говорить о программной совместимости автоматизированных систем, характеризуемой возможностью работы программ одной системы в другой и обмена программами, необходимыми при взаимодействии АСОИУ.

Комплект стандартов, регламентирующих создание ПО АСОИУ – стандарты ГОСТ группы 19 и ИСО/МЭК. Ниже приведен перечень основных стандартов:

1) ГОСТ 19.701-90 (ИСО 5807-85) Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения

2) ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

3) ГОСТ Р ИСО/МЭК 12207-99 Информационная технология Процессы жизненного цикла программных средств.

4) ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.

5) ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология Пакеты программ. Требования к качеству и тестирование.

6) ГОСТ Р ИСО/МЭК 14764-2001 Информационная технология Сопровождение программных средств.

7) ГОСТ Р ИСО/МЭК ТО 15271-2001 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

8) Жизненный цикл программного обеспечения и их процессы регламентируется ГОСТ Р ИСО/МЭК 12207-99.

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

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

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

 

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

Структура программного обеспечения – совокупность программных компонент, образующих единый программный комплекс в составе АСОИУ (рисунок 12.1). Среди компонент можно выделить приобретаемые и разрабатываемые группы программного обеспечения.

 

Рисунок 12.1 Пример структуры программного обеспечения.

 

Структура разрабатываемого ПО формируется в соответствии с той технологией проектирования ПО, которая выбрана разработчиком АСОИУ.

 

Управление требованиями к ПО АСОИУ.

Требования к ПО состоят из трех уровней: бизнес-требования, требования пользователей, функциональные требования (или требования поведения), нефункциональные требования [17].

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

Документ «Требования пользователей» описывает цели и задачи, которые пользователям позволит решить система. Способы представления этого вида требований: варианты использования; сценарии; таблицы «событие — отклик». В документе должна быть указано, что клиенты смогут делать с помощью системы.

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

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

Системные требования - высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Система - программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

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

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

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

 

⇐ Предыдущая567891011121314Следующая ⇒

Поделиться: