Материал: Автоматизация процесса систематизации документации архива организации ООО «Мэйджор карго сервис»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
31
целом зависит от точности и корректности формулировки требований к
программному продукту.
Правила работы с требованиями к программному обеспечению
рассматриваются в стандарте IEEE 830-1998 «Recommended practice for software
requirements specifications» [2]. Стандарт регламентирует состав документации для
фиксирования требований к ПО, а также дает определение характеристикам,
которыми должен обладать правильно составленный набор требований.
Стандарт IEEE 1233-1998 «Guide for developing system requirements
specifications» дает описание правилам построения требований для программно-
аппаратных систем в целом, а также определяет необходимые свойства и атрибуты
набора требований [4]. Согласно стандарту, процесс разработки требований
включает определение, организацию, представление и модификацию требований.
Один из важных этапов в разработке программного обеспечения – это
процесс проектирования архитектуры ИС. Архитектура системы позволяет
определить большинство характеристик АИС и служит основным средством
общения между разработчиками, а также между разработчиками и всеми
остальными лицами, заинтересованными в данном ПО.
Рассмотрим стандарты, которые регламентируют процесс проектирования
архитектуры АИС. Стандарт IEEE 1016-1998 «Recommended Practice for Software
Design Descriptions» описывает принципы разработки непосредственно
архитектуры АИС, а не ее компонентов [3].
Стандарт ISO/IEC 42010 IEEE Std 1471-2011 «System and software engineering
– Recommended practice for architectural description of software-intensive systems»
представляет архитектуру системы в виде комплекса представлений, которые
отражают структуру ПО с разных точек зрения [5]. В соответствии со стандартом
каждое представление архитектуры должно учитывать отраженные в нем взгляды и
интересы, причины, обуславливающие необходимость такого рассмотрения
системы, несоответствия между элементами одного представления или между
различными представлениями, а также различную служебную информацию.
Стандарт ISO 9001:2015 «Quality management systems – Requirements»
определяет требования к качеству программного продукта, а также правила его
обеспечения [1]. Стандарт ISO/IEC 90003:2004 «Software engineering – Guide lines
32
for the application of ISO 9001:2000 to computer software» описывает положения по
применению стандарта ISO 9001:2000 к программному обеспечению [7]. Также
этот стандарт помогает определить набор техник и процедур, которые будут
применяться для осуществления контроля и обеспечения качества
разрабатываемых программ.
Так же существуют следующие стандарты разработки программного
обеспечения, которые были разработаны вендорами программного обеспечения:
«Custom Development Method» методика компании «Oracle»,
применяемая для разработки прикладных информационных систем [19]. Этот
метод является технологическим материалом, детализированным до уровня
шаблонов проектной документации, рассчитанной на применение в проектах
компании. Согласно этому стандарту при разработке программного обеспечения
применяется классическая модель жизненного цикла программного продукта.
Стандарт «Rational Unified Process» (RUP) представляет разработку
программного обеспечения в виде итеративной модели жизненного цикла, который
включает следующие фазы: начало, исследование, построение и внедрение [18].
Каждая фаза жизненного цикла АИС может разбиваться на этапы, называемые
итерациями. В результате осуществления этих этапов происходит выпуск версий
программного продукта для внутреннего или внешнего использования.
Прохождение процесса разработки через четыре этапа называют циклом
разработки. Каждый цикл разработки завершается генерацией версии системы.
Если после версия системы не удовлетворяет требованиям пользователя, то
разработанный продукт продолжает свое развитие и проходит те же этапы
разработки.
Стандарт «Microsoft Solution Framework» (MSF) похож на стандарт
«RUP» тем, что делит разработку программного обеспечения на четыре фазы:
анализ, проектирование, разработка, стабилизация [18]. Эта модель является
итерационной, что предполагает использование объектно-ориентированного
подхода при моделировании системы. Стандарт «MSF» в сравнении со стандартом
«RUP» больше ориентирован для разработки бизнес- приложений.
Стандарт «Extreme Programming» (XP) был создан в 1996 году и
является самым новым среди рассмотренных стандартов [12]. Основу этого
33
стандарта составляет командная работа, с организацией эффективной
коммуникацией между заказчиком и разработчиков во время всей разработки АИС.
При этом разработка АИС проводится с использованием последовательно
разрабатываемых прототипов АИС.
На основании вышеперечисленного можно заключить, что для разработки
системы учета посещений фитнес-центра был выбран стандарт ГОСТ Р ИСО/МЭК
12207-2010, поскольку в его основе лежит классическая модель разработки ПО и
все процессы являются детализированными до уровня шаблонов проектной
документации.
Рассмотрим модели жизненного цикла программного продукта. Когда
программные продукты только начали разрабатываться, они имели однородную
структуру и каждое приложение являлось единым целым. Поэтому для разработки
программных продуктов такого типа применялась каскадная модель жизненного
цикла программного обеспечения.
Основной характеристикой этой модели является деление всего процесса
разработки программного обеспечения на ряд этапов. При этом переходы между
этапами осуществлялись только после полного завершения работ на текущем
этапе. Каждый этап каскадной модели завершался выпуском полного пакета
проектной документации, которой достаточно для продолжения процесса
разработки другой командой разработчиков.
Каскадная модель была разработана в 1970 году, и она являлась первой
моделью, которая формализовала структуру этапов разработки ПО, что придавало
особое значение исходным требованиям к программному обеспечению и этапу
проектирования системы, а также созданию документации на ранних этапах
процесса разработки. Структура каскадной модели представлена на рисунке 7.
34
Рисунок 7. Каскадная модель жизненного цикла
На схеме этапов каскадной модели жизненного цикла программного
обеспечения видно, что процесс разработки осуществляется при помощи
упорядоченной последовательности шагов. Каскадная модель предусматривает
начало каждой фазы только тогда, когда полностью завершается выполнение
предыдущей фазы. При этом у каждой фазы есть определенные критерии входа и
выхода: входные и выходные данные.
Требования к проектируемой АИС определяются на стадии анализа и затем
документируются в техническом задании, которое является опорным документом
при создании АИС. Каждая стадия каскадной модели должна завершаться
выпуском полного комплекта проектной документации, которая включает в себя:
1. Техническое задание.
2. Эскизный проект.
3. Технический проект.
4. Рабочую программу.
Перечисленный пакет документов является достаточным для продолжения
процесса разработки другой командой разработчиков. Критерий качества при
использовании каскадной модели жизненного цикла программного обеспечения –
точное соответствие спецификациям технического задания на разработку АИС.
При этом особое внимание разработчики уделяют достижению оптимального
значения технических характеристик разрабатываемой АИС: производительности,
объема занимаемой памяти и т.д.
Переход от одного этапа проекта к другому осуществляется с помощью
формального обзора проекта. При этом клиент получает общее представление о
35
процессе разработки, а также происходит проверка качества программного
продукта. Окончание каждого этапа разработки АИС удобно принимать за стадию
в процессе выполнения проекта.
С ростом объема коммерческих проектов разработки программных
продуктов было установлено, что детальная проработка проекта разрабатываемой
системы не всегда удается на этапе анализа, потому что многие аспекты
функционирования АИС в динамических сферах деятельности меняются во время
создания информационной системы. В связи с этим потребовалось внесение
изменений в процесс разработки АИС таким образом, чтобы гарантировалось
внесение необходимых исправлений после завершения какого-либо этапа
разработки. Это послужило созданию итерационной модели жизненного цикла
программного продукта.
Каскадная модель жизненного цикла разработки АИС являлась идеальной,
поскольку только очень простые проекты проходили все этапы создания ПО без
участия в каких-либо итерациях — возвратов на предыдущие этапы разработки
программных средств. Например, на этапе программирования могло быть
обнаружено, что реализация некоторой функции является очень громоздкой,
неэффективной и вступает в противоречие с требуемой от системы
производительностью. В таких случаях может потребоваться перепроектирование
или переделка спецификаций требований к АИС. При разработке больших АИС
необходимость в итерациях может возникать регулярно на любой стадии
жизненного цикла как из-за допущенных на предыдущих шагах ошибок и
неточностей, так и из-за изменений внешних требований к условиям эксплуатации
системы.
Итерационную модель также называют моделью с промежуточным
контролем или моделью с циклическим повторением фаз. Структура итерационной
модели представлена на рисунке 8.
Источник: https://baza.diplomsite.ru/previewfile/2138