Информационные технологии и информационные системы. Этапы жизненного цикла технической системы
ЛЕКЦИЯ 10
ЖИЗНЕННЫЙ ЦИКЛ СИСТЕМЫ
Модели ЖЦ и его основные этапы
При описании жизненного цикла системы используются следующие понятия:
процесс - цепочка последовательно выполняемых работ;
этапы - последовательные отрезки времени, в течение которого выполняются работы . В течение этапа могут выполняться работы, относящиеся к разным процессам. В основе деятельности по созданию и использованию автоматизированной системы управления предприятием (АСУП) лежит понятие ее жизненного цикла (ЖЦ). ЖЦ является моделью создания и использования АСУП, отражающей ее различные состояния, начиная с момента возникновения необходимости в данном изделии и заканчивая моментом его полного выхода из употребления у всех без исключения пользователей.
Традиционно выделяются следующие основные этапы ЖЦ АСУП:
анализ требований;
проектирование;
программирование/внедрение;
тестирование и отладка;
эксплуатация и сопровождение.
ЖЦ образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т. п. На каждом этапе ЖЦ порождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки их соответствия исходным.
Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:
1. Каскадная модель (в 70-80-е годы) - предполагает переход на следующий этап после полного окончания работ по предыдущему этапу и характеризуется четким разделением данных и процессов их обработки.
2. Поэтапная модель с промежуточным контролем (в 80-85-е годы) - итерационная модель разработки с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки.
3. Спиральная модель (в 86-90-е годы) - делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Специалистами отмечаются следующие преимущества спиральной модели:
накопление и повторное использование программных средств, моделей и прототипов;
ориентация на развитие и модификацию системы в процессе ее проектирования;
анализ риска и издержек в процессе проектирования
. Отметим, что главная особенность индустрии АСУП состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, могут лишить успеха.
Анализ требований
Анализ требований является первой фазой разработки АСУП, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.
Список требований к АСУП должен включать:
Совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение);
Описание выполняемых системой функций;
Ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. Результатом этапа должна являться модель требований к системе (по другому - системный проект) , определяющая:
Архитектуру системы, ее функции, внешние условия, распределение функций между аппаратной и программной частями (ПЧ);
Интерфейсы и распределение функций между человеком и системой;
Требования к программным и информационным компонентам ПЧ, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент ПЧ, их интерфейсы. Модель требований должна включать:
Полную функциональную модель требований к будущей системе с глубиной проработки до уровня каждой операции каждого должностного лица;
Спецификации операций нижнего уровня;
Пакет отчетов и документов по функциональной модели, включающий характеристику объекта моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;
Концептуальную информационную модель требований;
Пакет отчетов и документов по информационной модели;
Архитектуру системы с привязкой к концептуальной информационной модели;
Предложения по оргштатной структуре для поддержки системы.
Таким образом, модель требований содержит функциональную, информационную и, возможно, событийную (в случае если целевая система является системой реального времени) модели, обеспечивающие ряд преимуществ по сравнению с традиционной моделью:
1. Для традиционной разработки характерно осуществление начальных этапов кустарными неформализованными способами. В результате заказчики и пользователи впервые могут увидеть систему после того, как она уже в большей степени реализована. Естественно, эта система будет отличаться от того, что они ожидали увидеть. Поэтому далее последует еще несколько итераций ее разработки или модификации, что требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает модель требований, позволяющая:
Описать, «увидеть» и скорректировать будущую систему до того, как она будет реализована физически;
Уменьшить затраты на разработку и внедрение системы;
Оценить разработку по времени и результатам;
Достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т. д.);
Улучшить качество разрабатываемой системы, а именно выполнить ее функциональную декомпозицию и спроектировать оптимальную структуру интегрированной базы данных.
2. Модель требований полностью независима и отделяема от конкретных разработчиков, не требует сопровождения ее создателями и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации системы на основе модели требований, она может быть положена «на полку» до тех пор, пока в ней не возникнет необходимость.
3. Модель требований может быть использована для самостоятельной разработки или корректировки уже реализованных на ее основе программных средств силами программистов отдела автоматизации предприятия.
4. Модель требований может использоваться для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности предприятия, поскольку ее технология содержится в модели.
Этап анализа требований является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понятным процессом. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать это, так как если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.
С другой стороны, рассматриваемый этап ЖЦ является наиболее трудной частью разработки. Нижеследующие проблемы, с которыми сталкивается системный аналитик, взаимосвязаны (и это является одной из главных причин сложности их разрешения):
Аналитик не всегда располагает исчерпывающей информацией для оценки требований к системе с точки зрения заказчика;
Заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных для того, чтобы судить, что выполнимо, а что нет;
Аналитик сталкивается с чрезмерным количеством подробных сведений как о предметной области, так и о новой системе;
Традиционная (текстовая) спецификация системы из-за объема технических терминов часто непонятна заказчику;
Если такая спецификация понятна заказчику, она будет недостаточной для проектировщиков и программистов, создающих или адаптирующих систему.
Конечно, применение известных аналитических методов снимает отдельные проблемы анализа, однако приемлемое решение совокупности этих проблем может быть найдено только путем применения современных методик системной и программной инженерии, ключевое место среди которых занимают методологии структурного и объектно-ориентированного анализа.
Структурные методы анализа
Структурным анализом принято называть метод исследования системы, который начинается с общего обзора ее и затем детализируется, приобретая иерархическую структуру со все большим числом уровней . Для таких методов характерно:
Разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 7, при этом верхняя граница соответствует возможностям человеческого мозга воспринимать определенное количество взаимоувязанных объектов, а нижняя выбрана из соображений здравого смысла);
Ограниченный контекст, включающий лишь существенные на каждом уровне детали;
Использование строгих формальных правил записи;
Последовательное приближение к конечному результату.
Методы структурного анализа позволяют преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих черных ящиков . Преимущество использования черных ящиков заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь его входы и выходы, а также его назначение (т. е. функцию, которую он выполняет). В окружающем нас мире черные ящики встречаются в большом количестве: магнитофон и телевизор на бытовом уровне, предприятие с позиций клиента и т. п. Проиллюстрируем преимущества систем, составленных из них, на примере музыкального центра.
Конструирование системы черных ящиков существенно упрощается. Намного легче разработать магнитофон или проигрыватель, если не беспокоиться о создании встроенного усилительного блока.
Облегчается тестирование таких систем. Если появляется плохой звук одной из колонок, можно поменять колонки местами. Если неисправность переместилась с колонкой, то именно она подлежит ремонту; если нет, тогда проблема в усилителе, магнитофоне или местах их соединения.
Имеется возможность простого реконфигурирования системы черных ящиков. Если колонка неисправна, то можно отдать ее в ремонтную мастерскую и продолжать слушать записи в монорежиме.
Облегчается доступность для понимания и освоения. Можно стать специалистом по магнитофонам без углубленных знаний о колонках.
Повышается удобство при модификации. Можно приобрести колонки более высокого качества и более мощный усилитель, но это совсем не означает, что необходим проигрыватель больших размеров.
Таким образом, первым шагом упрощения сложной системы является ее разбиение на черные ящики (принцип «разделяй и властвуй» - принцип решения трудных проблем путем разбиения их на множество независимых задач, легких для понимания и решения), при этом такое разбиение должно удовлетворять следующим критериям:
Каждый черный ящик должен реализовывать единственную функцию системы;
Функция каждого черного ящика должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна - расчет точки приземления);
Связь между черными ящиками должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой - для расчета налогов необходима связь между этими черными ящиками: размер заработанной платы требуется для расчета налогов);
Связи между черными ящиками должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов," является идея иерархии. Для понимаемости сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Все сложные системы Вселенной организованы в иерархии. Да и сама она включает галактики, звездные системы, планеты, молекулы, атомы, элементарные частицы. Человек при создании сложных систем также подражает природе. Любая организация имеет директора, заместителей по направлениям, иерархию руководителей подразделений, рядовых служащих. Таким образом, второй принцип структурного анализа (принцип иерархического упорядочения) в дополнение к тому, что легче понимать проблему, если она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимаемость проблемы резко повышается при организации ее частей в древовидные иерархические структуры, т. е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Наконец, третий принцип: структурные методы широко используют графические нотации, также служащие для облегчения понимания сложных систем. Известно, что «одна картинка стоит тысячи слов».
Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независимо от типа разрабатываемой системы и используемых при этом методологий. Руководство всеми принципами в комплексе позволяет на более ранних стадиях разработки понять, что будет представлять собой создаваемая система, обнаружить промахи и недоработки, что, в свою очередь, облегчит работы на последующих этапах ЖЦ и понизит стоимость разработки.
Для целей структурного анализа традиционно используются три группы средств, иллюстрирующих:
функции, которые система должна выполнять,
отношения между данными,
зависящее от времени поведение системы (аспекты реальноговремени).
Среди многообразия графических нотаций, используемых для решения перечисленных задач, в методологиях структурного анализа наиболее часто и эффективно применяются следующие:
DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов (мини-спецификациями);
ERD (Entity-Relationship Diagrams) -диаграммы «сущность -связь »;
STD (State Transition Diagrams) - диаграммы переходов состояний.
Классическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающимися с помощью STD. Эти взаимосвязи показаны на рис. 20.
Необходимо отметить, что для функционального моделирования наряду с DFD достаточно часто применяется и другая нотация - SADT (точнее, ее стандартизованное подмножество IDEFO). Сравнительный анализ этих двух подходов к моделированию функций системы будет приведен ниже.
Таким образом, перечисленные выше средства позволяют сделать полное описание системы независимо от того, является ли она существующей или разрабатываемой с нуля. Такое подробное описание того, что должна делать система, освобожденное насколько это возможно от рассмотрения путей реализации, получило название спецификации требований, дающей проектировщику, реализующему следующий этап ЖЦ, четкое представление о конечных результатах, которые должны быть достигнуты.
Перечисленные выше графические нотации используются (в том или ином наборе) практически во всех современных методологиях структурного системного анализа. Роль этих методологий заключается в регламентации основ разработки сложных систем. Они описывают последовательность шагов, модели и
Рис. 20
подходы, тщательное следование которым приведет к хорошо работающим системам. Хотя методологии, вообще говоря, не гарантируют качества построенных систем, тем не менее они помогают охватить и учесть все важные этапы, шаги и моменты разработки, помогают справиться с проблемами размерности и, в конечном итоге, оценить продвижение вперед. Более того, методологии обеспечивают организационную поддержку, позволяющую большим коллективам разработчиков функционировать скоординированным образом.
Другими словами, методология структурного анализа определяет руководящие указания для построения и оценки модели требований разрабатываемой системы, шаги работы, которые должны быть выполнены, их последовательность, а также правила распределения и назначения применяемых при этом операций и методов.
В настоящее время успешно используются практически все известные методологии структурного анализа, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна-Сарсона (Gane-Sarson), структурного анализа и проектирования Йодана-Де Марко (Yourdon-DeMarko), развития систем Джексона (Jackson), развития структурных систем Варнье-Орра (Warmer- Orr), анализа и проектирования систем реального времени Уорда- Меллора (Ward-Mellor) и Хатли (Hatley), информационного моделирования Мартина (Martin).
Перечисленные структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций и отражают подход к системной разработке с позиций рецептов «кулинарной книги». Спецификации требований включают особенности целевой системы и ее прогнозируемые характеристики, проекты пользовательских интерфейсов (меню, экраны и формы), критерии работоспособности системы, программное и аппаратное окружение. Полученный документ спецификации требований в дальнейшем преобразуется в проектные спецификации, детализирующие предполагаемую реализацию ПЧ. Проектные спецификации идентифицируют главные модули, маршруты связи поданным и управлению между модулями, основные подпрограммы внутри каждого модуля, структуры данных, спецификации форматов входных и выходных файлов. Для ключевых процессов проектные спецификации часто включают детали алгоритмов на языке проектирования мини-спецификаций. В дальнейшем структурные методологии предлагают методику трансляции проектных спецификаций в программные коды. Кодогенерация предполагает наличие кодовых стандартов, специфицирующих формат заголовков подпрограмм, ступенчатый вид вложенных блоков, номенклатуру для спецификации переменных и имен подпрограмм и т. п.
Современные структурные методологии классифицируются по трем следующим признакам:
по отношению к школам - Software Engineering (SE) и Information Engineering (IE);
по порядку построения модели - процедурно-ориентированные и информационно-ориентированные;
по типу целевых систем - для систем реального времени (СРВ) и информационных систем (ИС).
SE является универсальной дисциплиной разработки программных систем всех типов (ИС, СРВ). IE является дисциплиной построения ИС вообще, а не только их программной компоненты и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе анализа требований к программной части эти дисциплины аналогичны.
Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При информационно-ориентированном подходе вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными отданных.
Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени - главная и первоочередная функция таких систем. Принципиальные отличия информационных систем от систем реального времени приведены в табл. 2;
Таблица 2
Средствами поддержки этих особенностей и различаются соответствующие структурные методологии. Необходимо отметить, что для целей анализа требований к системам реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, матрицы состояний/ событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для анализа требований к информационным системам. Более того, известные методологии анализа и проектирования СРВ (в частности, методологии Хатли и Уор-да-Меллора) базируются на перечисленных методологиях анализа и проектирования ИС, расширяя их соответствующими диаграммными техниками.
В табл. 3 приведена классификация наиболее часто используемых методологий в соответствии с вышеперечисленными признаками (данные по частоте использования получены на основе анализа информации по 127 CASE-пакетам).
Как уже отмечалось, наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. С этой точки зрения все разновидности структурного системного анализа могут быть разбиты на две группы: применяющие методы и технологию DFD (в различных нотациях) и использующие SADT-методологию. По материалам наиболее авторитетной в рассматриваемой области исследовательской компании CASE Consulting Group соотношение применения этих двух разновидностей структурного анализа на практике составляет 90% для DFD и 10% для SADT.
Таблица 3
Методологии | Частота использования | Школа | Порядок построения | Тип целевых систем |
Йодан- Де Марко | процедурно-ориентированная | |||
Гейн- Сарсон | процедурно-ориентированная | |||
Константайн | процедурно-ориентированная | |||
информационно-ориентированная | ||||
Варнье-Орр | информационно-ориентированная | |||
информационно-ориентированная | ||||
процедурно-ориентированная |
Предваряя сравнительный анализ DFD- и SADT-подходов , в качестве примера рассмотрим верхний уровень модели требований к системе автоматизации управления компанией, занимающейся распределением товаров по заказам (рис. 21 и рис. 22 соответственно). Заказы подвергаются входному контролю и сортировке. Если заказ не отвечает номенклатуре товаров или оформлен неправильно, то он аннулируется с соответствующим уведомлением заказчика. Если заказ не аннулирован, то определяется, имеется ли на складе соответствующий товар. В случае положительного ответа выписывается счет к оплате и предъявляется заказчику, при поступлении платежа товар отправляется заказчику. Если заказ не обеспечен складскими запасами, то отправляется заявка на товар производителю. После поступления требуемого товара на склад компании заказ становится обеспеченным и повторяет вышеописанный маршрут.
Сравнительный анализ этих двух разновидностей методологий проводится по следующим параметрам:
адекватность средств рассматриваемой проблеме;
согласованность с другими средствами структурного анализа;
интеграция с последующими этапами разработки (и прежде всего с этапом проектирования).
1) Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. В нашем случае методологии применяются к автоматизированным системам управления предприятием, а не к системам вообще, как это предполагается в SADT. Для рассматриваемых задач DFD вне конкуренции.
Во-первых, SADT-диаграммы значительно менее выразительны и удобны для моделирования АСУП (сравните рис. 21 и рис. 22). Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к АСУП стирается смысловое различие между входами и выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы, механизмы и управления являются потоками данных и/или управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
ких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
Во-вторых, в SADT вообще отсутствуют выразительные средства для моделирования особенностей АСУП. DFD с самого начала создавались как средство проектирования информационных систем, являющихся ядром АСУП, и имеют более богатый набор элементов, адекватно отражающих специфику та третьих, наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT (а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.
2) Согласованность. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моделирования. Согласование SADT-модели с ERD и/или STD практически невозможно или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являются согласованными представлениями различных аспектов одной и той же модели (см. рис. 20). В табл. 4 отражена возможность такой интеграции для DFD- и SADT-моделей.
Таблица 4
Название | Структурные карты |
||
Отметим, что интеграция DFD-STD осуществляется за счет расширения классической DFD специальными средствами проектирования систем реального времени (управляющими процессами, потоками, хранилищами данных), и STD является детализацией управляющего процесса, согласованной по управляющим потокам и хранилищам. Интеграция DFD-ERD осуществляется с использованием отсутствующего в SADT объекта - хранилища данных, структура которого описывается с помощью ERD и согласуется по соответствующим потокам и другим хранилищам на DFD.
3) Интеграция с последующими этапами. Важная характеристика методологии - ее совместимость с последующими этапами применения результатов анализа (и прежде всего с этапом проектирования, непосредственно следующим за анализом и опирающимся на его результаты). DFD могут быть легко преобразованы в модели проектирования (структурные карты) - это близкие модели. Более того, известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логичный и безболезненный переход от этапа анализа требований к проектированию системы. С другой стороны, неизвестны формальные методы преобразования SADT-диаграмм в проектные решения АСУП.
Тем не менее необходимо отметить, что рассмотренные разновидности структурного анализа по сути - два приблизительно одинаковых по мощности языка для передачи понимания. И одним из основных критериев выбора является следующий: насколько хорошо каждым из этих языков владеет консультант или аналитик, насколько грамотно он может на этом языке выражать свои мысли.
Таблица 2.1
Определения.
1. Определение стандарта ISO/IEC 15288:2008 (Определение: life cycle -- evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO 15288, 4.11):
жизненный цикл (ЖЦ) – это эволюция системы, продукции, услуги, проекта или иного рукотворного объекта от замысла до прекращения использования.
2. Определение стандарта ISO 15704 (Industrial automation systems - Requirements for enterprise-reference architectures and methodologies Системы промышленной автоматизации. Требования к архитектуре эталонных предприятий и методологии. Описывает эталонную архитектуру предприятия и средства реализации проектов в рамках полнрго жизненного цикла предприятия):
жизненный цикл (ЖЦ) – это конечный набор основных фаз и шагов, которые система проходит на протяжении всей истории существования.
Каждая система, вне зависимости от ее вида и масштаба, проходит весь свой жизненный цикл согласно некоторому описанию. Продвижение системы по частям этого описания и есть жизненный цикл системы. Описание жизненного цикла, таким образом, - это концептуальная сегментация по стадиям , способствующим планированию, разворачиванию, эксплуатации и поддержке целевой системы.
Стадии (табл. 2.1) представляют наиболее крупные периоды жизненного цикла, ассоциируемые с системой, и соотносятся с состояниями описания системы или реализацией системы как набора продуктов или услуг. Стадии описывают основные контрольные точки продвижения и успехов системы по ходу жизненного цикла. Такие сегменты дают упорядоченное продвижение системы через установленные пересмотры выделения ресурсов, что снижает риски и обеспечивает удовлетворительное продвижение. Основной причиной применения описаний жизненного цикла является потребность в принятии решений по определенным критериям до продвижения системы на следующую стадию.
Комментарий: жизненный цикл – всегда жизненный цикл конкретной системы. Не бывает «жизненного цикла» кроме как в текстах стандартов, в жизни всегда «жизненный цикл X», где X – название целевой системы. Процессы жизненного цикла – это те процессы, которые акторы выполняют над/с системой, и которые меняют состояние системы, заставляя ее эволюционировать в ходе её жизненного цикла. «Управление жизненным циклом» -- общепринятое название подхода к описанию процессов жизненного цикла (а часто и название самой группы процессов жизненного цикла, описанных с использованием такого подхода).
У системы есть два основных представления: целевое (архитектурное, чаще всего структурное в своей основе, плюс процессы времени эксплуатации системы) и жизненного цикла (развертка во времени жизненного цикла - процессы обеспечивающих систем). Можно обсуждать, насколько каждое из этих представлений является частью другого, но для надлежащего описания системы всегда нужно использовать какое-то представление жизненного цикла.
Прежде всего, нужно различить жизненный цикл (иногда, ограничиваясь только инженерией, но не полным ЖЦ говорят также delivery process, изредка для софта -- software process) и другие "процессные представления" -- трансакции DEMO, логические "бизнес-процессы" (практики), workflows, проектные представления (подробнее -- http://ailev.livejournal.com/904643.html). Хотя есть множество подходов, при которых все эти разные аспекты описаний организации и методов ее работы смешиваются.
Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
Языков представления жизненного цикла и текстовых и графических нотаций для этих языков много, ограничимся для примера лишь следующими:\
· «Нарезанная колбаска»
· V-диаграмма
Нарезанная колбаска".
Просто перечисление стадий жизненного цикла их названиями, для выразительности названия упакованы в отрезки "колбаски" (рис.2.1)
Рисунок 2.1. Традиционное представление жизненного цикла
Вокруг традиционной «колбаски» могут указываться еще две дополнительных: как ЖЦ видят менеджеры (лица, управляющие проектом), и как ЖЦ видят инженеры(лица, реализующие проект) (рис.2.2)
Рисунок 2.2. Пример представления жизненного цикла
Жизненные циклы наблюдаются в историях отдельных товаров и потребностей, торговых марок, предприятий, целых индустрий и рынков. Жизненный цикл неотделим от конкретной системы, поэтому особенности разных систем порождают большое разнообразие экземпляров «колбасок» жизненных циклов (рис.2.3) .
Рис.2.3. Разнообразие жизненных циклов
Лабораторная работа №1
Выделение жизненных циклов проектирования компьютерных систем
Цель работы : ознакомиться с моделями жизненного цикла информационных систем, определить достоинства и недостатки моделей, выбрать модель построения информационной системы индивидуального проектного задания и программные средства, составить план реализации индивидуального проектного задания.
Краткие теоретические сведения.
Жизненный цикл информационной системы
Разработка сложных информационных систем (ИС) невозможна без тщательно обдуманного методологического подхода. Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.
Жизненный цикл ИС –это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.
Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):
· ГОСТ 34.601-90. Введен в действие 01.01.1992. Устанавливает стадии и этапы создания автоматизированных систем и дает содержание работ на каждой стадии. Стадии и этапы работы, закрепленные в стандарте, соответствуют каскадной модели жизненного цикла.
· ISO/IEC 12207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:
o Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);
o Вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация);
o Организационные процессы (создание инфраструктуры, управление, обучение, усовершенствование).
Для реализации положений стандарта должны быть выбраны инструментальные средства, совместно образующие взаимосвязанный комплекс технологической поддержки и автоматизации жизненного цикла программного обеспечения и не противоречащие предварительно скомпонованному набору нормативных документов. Чтобы облегчить практическое применение стандарта, международной организацией по стандартизации были разработаны и утверждены следующие документы:
o ISO/IEC TR 15271:1998 – руководство по применению ISO/IEC 12207;
o ISO/IEC TR 16326:1999 – руководство по управлению проектами при использовании ISO/IEC 12207.
· ISO/IEC 15288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т.д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества – среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15288.
· Rational Unified Process (RUP) – концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне – подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом – его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).
· Microsoft Solution Framework (MSF). Итерационная методология разработки приложений, аналогичная RUP. Так же включает четыре фазы: анализ, проектирование, разработка, стабилизация и предполагает использование объектно-ориентированного моделирования. По сравнению с RUP в большей степени ориентирована на разработку ИС для бизнеса.
· Extreme Programming (XP). Экстремальное программирование – это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990-ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).
Модели ЖЦ ИС.
Под моделью ЖЦ ИС понимается структура определяющая последовательность выполнения и взаимосвязи процессов действий и задач на протяжении жизненного цикла.
Модель жизненного цикла ИС - это структура, описывающая процессы, действия и задачи, которые осуществляются и ходе разработки, функционирования и сопровождения в течение всего жизненного цикла системы.
Выбор модели жизненного цикла зависит от специфики, масштаба, сложности проекта и набора условий, в которых АИС создается и функционирует.
В соответствии с известными моделями ЖЦ программного обеспечения определяют модели ЖЦ ИС -каскадную, итерационную, спиральную.
I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.
Каскадная модель предусматривает последовательную организацию работ, причем основной особенностью модели является разбиение всей работы на этапы. Переход от предыдущего этапа к последующему происходит только после полного завершения всех работ предыдущего.
Выделяют пять устойчивых этапов разработки, практически не зависящих от предметной области:
На первом этапе проводится исследование проблемной области, формулируются требования заказчика. Результатом данного этапа является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.
В ходе второго этапа, согласно требованиям технического задания, разрабатываются те или иные проектные решения. В результате появляется комплект проектной документации.
Третий этап - реализация проекта; по существу, разработка программного обеспечения (кодирование) в соответствии с проектными решениями предыдущего этапа. Методы реализации при этом принципиального значения не имеют. Результатом выполнения этапа является готовый программный продукт.
На четвертомэтапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы ИС.
Последний этап - сдача готового проекта.
На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения АИС (организационное, информационное, программное, техническое и т. д.). Последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.
При этом для каскадной модели необходимо отметить существенную задержки в получении результатов, сложность параллельного ведения работ по проекту и сложность управления проектом, и как следствие, высокий уровень риска и ненадежность вложений в ИС. Кроме того, ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата.
II. Итерационная модель заключается в серии коротких циклов (шагов) по планированию, реализации, изучению, действию. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Создание сложных ИС предполагает проведение согласований проектных решений, полученных при реализации отдельных задач. Подход к проектированию «снизу - вверх» обусловливает необходимость таких итераций возвратов, когда проектные решения по отдельным задачам объединяются в общие системные. При этом возникает потребность в пересмотре ранее сформировавшихся требований.
В итерационной модели межэтапные корректировки обеспечивают меньшую трудоемкость разработки по сравнению с каскадной моделью.
При этом, время жизни каждого этапа растягивается на весь период работки, вследствие большого числа итераций возникают рассогласования выполнения проектных решений и документации, возможно появление на стадии внедрения необходимости перепроектирования всей системы.
III . Спиральная модель , в отличие от каскадной, но аналогично предыдущей предполагает итерационный процесс разработки ИС. При этом возрастает значение начальных этапов, таких как анализ и проектирование, на которых проверяется и обосновывается реализуемость технических решений путем создания прототипов.
Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой:
Таким образом, каждый виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы на следующем витке спирали. Каждая итерация служит для углубления и последовательной конкретизации деталей проекта, в результате этого выбирается обоснованный вариант окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения текущего, - недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации - как можно быстрее создать работоспособный продукт для демонстрации пользователям. Таким образом, существенно упрощается процесс внесения уточнений и дополнений проект.
Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс разработки более гибким. При использовании спиральной модели существенно упрощается внесение изменений в проект при изменении требований заказчика, происходит снижение уровня рисков (уровень рисков максимален в начале разработки проекта, по мере продвижения разработки он снижается), обеспечивается большая гибкость в управлении проектом за счет возможности внесения тактических изменений в разрабатываемое изделие, возможность совершенствовать процесс разработки - в результате анализа в конце каждой итерации проводится оценка изменений в организации разработки; на следующей итерации она улучшается, упрощается повторное использование компонентов, поскольку гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно корректируются критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы. Вовлечение пользователей в процесс проектирования и копирования приложения позволяет получать замечания и дополнения к требованиям непосредственно в процессе проектирования приложения, сокращая время разработки. Представители заказчика получают возможность контролировать процесс создания системы и влиять на ее функциональное наполнение. Результатом является сдача в эксплуатацию системы, учитывающей большинство потребностей заказчиков.
Однако, организация проектирования ИС по спиральной модели обычно имеет высокую стоимость (поэтому ее имеет смысл использовать для сложных и дорогостоящих систем). Модель имеет сложную структуру, что может затруднить ее применение на практике неподготовленными специалистами и заказчиками. Спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл работ. Большое количество промежуточных стадий усложняет ведение документации проекта. Возможны затруднения в определении момента перехода на следующую итерацию цикла. Обычно вводят временные ограничения на выполнение итерации и каждого из ее этапов.
В некоторых ситуациях применение спиральной модели невозможно или ограничено, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение корпоративных информационных систем обычно сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а неграмотное управление процессом внедрения может свести на нет все полученные результаты. По этой причине на этапе внедрения часто обходятся без итерационных моделей, внедряя систему «раз и навсегда».
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27
Подобно живому организму, всякий продукт (товар или услуга) имеет свой жизненный цикл , который начинается с момента его «рождения» (или, возможно, с момента зарождения идеи) и заканчивается его «смертью», или изъятием из употребления.
Жизненный цикл ЭИС – совокупность этапов, которые проходит ЭИС в своем развитии от момента принятия решения о ее создании до прекращения функционирования.
Жизненный цикл экономической информационной системы включает следующие этапы:
1) предпроектный;
2) проектирование логическое и техническое;
3) проектирование рабочее (физическое);
4) внедрение;
5) эксплуатацию;
6) изъятие.
Предпроектный этап включает в себя исследование и анализ системы управления компанией, выявляющие имеющихся информационных потребителей. Целью данного этапа является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие будущей ИС целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки.
Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этом этапе должны решаться проблемы, связанные с разработкой технического задания, плана мероприятий по подготовке объекта, включая подготовку персонала и финансирования. На данном этапе также осуществляется анализ осуществимости ИС, а именно рассматривается:
· эксплуатационная осуществимость – возможно ли создание данной ИС, насколько она будет удобно в эксплуатации и отвечать заданным требованиям;
· экономическая осуществимость – стоимость, эффективность с точки зрения пользователя;
Проектирование логическое и техническое – это разработка в соответствии со сформулированными требованиями и выявленными информационными потребностями системной и функциональной архитектуры ЭИС.
На этапе проектирования, прежде всего, формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем.
Кроме выбора платформы, на этапе проектирования определяются виды архитектуры:
· архитектура «файл-сервер» или «клиент-сервер»;
· база данных централизованная или распределенная. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
· серверы, параллельные или одиночные для баз данных (в целях достижения необходимой производительности) и т.д.
Этап проектирования завершается разработкой технического проекта ИС.
Проектирование рабочее (физическое) включает создание и настройку программ, наполнение баз данных, создание рабочих инструкций для персонала. Проектирование заканчивается созданием рабочего проекта.
Рабочий проект – это техническая документация, утвержденная в установленном порядке, содержащая уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности автоматизированной системы управления и уточненный перечень мероприятий по подготовке объекта к внедрению.
В ходе опытного и промышленного внедрения
осуществляется комплексная отводка системы и обучение персонала.
Внедрение системы – это процесс постепенного перехода от существующей ЭИС к новой, предусмотренной документацией рабочего проекта на всю систему. Внедрение отдельных задач и подсистем может проводиться параллельно с разработкой рабочего проекта на всю систему.
Основными этапами внедрения системы являются:
· подготовка объекта к внедрению системы;
· сдача задач и подсистем в опытную эксплуатацию;
· проведение опытной эксплуатации;
· сдача задач, подсистем, системы в целом в промышленную эксплуатацию.
Опытная эксплуатация ИС заключается в проверке алгоритмов, программ и звеньев технологического процесса обработки данных в реальных условиях. Она проводится для следующего:
· окончательной отладки программ и отработки технологического процесса решения задач;
· проверки подготовленности информационной базы;
· отработки взаимосвязи задач системы;
· приобретения навыков работы персоналом предприятия;
· настройки всей системы в целом и устранения выявленных недочетов.
После окончания опытной эксплуатации системы составляется отчет о внедрении. При положительных результатах опытной эксплуатации система сдается в промышленную эксплуатацию.
Эксплуатация ЭИС – ее использование в реальных условиях. В ходе эксплуатации также осуществляется сопровождение, анализ работы системы, исправление ошибок и недоработок, оформление требований и разработка планов по модернизации и расширению системы.
Изъятием ЭИС из эксплуатации называется полное изъятие ЭИС из эксплуатации или существенная модернизация, позволяющая говорить о создании принципиально новой информационной системы.
Существующие модели жизненного цикла определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели жизненного цикла:
1) каскадная модель, предполагающая переход на следующий этап после полного окончания работ по предыдущему этапу;
2) поэтапная модель с промежуточным контролем, т.е. итерационная модель разработки с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью, однако время жизни каждого из этапов растягивается на весь период разработки;
3) спиральная модель делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
На всех этапах жизненного цикла ЭИС большую роль играют специалисты экономического профиля, которые:
· формируют требования к будущей информационной системе или плану ее модернизации;
· осуществляют обоснование и расчет экономической эффективности отдельных решений, используемых в составе ИС и системы в целом;
· участвуют непосредственно в процессе создания ЭИС, помогая моделировать бизнес-процессы и соответствующие им информационные процессы, в том числе и работники предприятия, для которого создается ИС, в соответствии с одним из принципов создания ИС.
· участвуют в отладке системы при передаче ее в эксплуатацию;
· (эксперты) используют свои знания и опыт для наполнения баз данных и знаний;
· на этапе внедрения разрабатывают инструкции и обучают персонал, применяя свои знания и практический опыт.
Исследования последних лет показали, что повышение производительности за счет использования информационных технологий достигается очень редко. Главная причина в том, что новые информационные технологии часто являются зеркальным отображением предыдущих методов и процессов. Осознание этого привело к
появлению нового направления в области управления – реинжиниринга бизнес-процессов, под которым понимается улучшение или совершенствование уже существующего бизнес-процесса за счет использования информационных технологий с параллельным фундаментальным переосмыслением и радикальной переориентацией деловых процессов для достижения резких улучшений важных показателей (повышения производительности, улучшения качества, снижения себестоимости).
по электротехнике). Этот стандарт определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПС.В данном стандарте ПС (или программный продукт ) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документацией и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные (Г. Майерс называет это трансляцией данных ). Каждый процесс характеризуется определенными задачами и методами их решения. В свою очередь , каждый процесс разделен на набор действий, а каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).
Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.
Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.
В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).
Рис.
5.1.
В группах определено пять основных процессов: приобретение, поставка, разработка, эксплуатация и сопровождение. Восемь вспомогательных процессов обеспечивают выполнение основных процессов, а именно документирование , управление конфигурацией , обеспечение качества, верификация , аттестация , совместная оценка, аудит , разрешение проблем. Четыре организационных процесса обеспечивают управление, создание инфраструктуры, усовершенствование и обучение.
5.2. Основные процессы ЖЦ ПС
Процесс приобретения состоит из действий и задач заказчика, приобретающего ПС. Данный процесс охватывает следующие действия :
- инициирование приобретения;
- подготовку заявочных предложений;
- подготовку и корректировку договора;
- надзор за деятельностью поставщика;
- приемку и завершение работ.
Инициирование приобретения включает следующие задачи:
- определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, программных продуктов или услуг;
- принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;
- проверку наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения программного продукта;
- подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон и т.д.
Заявочные предложения должны содержать:
- требования, предъявляемые к системе;
- перечень программных продуктов;
- условия приобретения и соглашения;
- технические ограничения (например, по среде функционирования системы).
Заявочные предложения направляются к выбранному поставщику или нескольким поставщикам в случае тендера. Поставщик – это организация, которая заключает договор с заказчиком на поставку системы, ПО или программной услуги на условиях, оговоренных в договоре.
Подготовка и корректировка договора включает следующие задачи:
- определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков;
- выбор конкретного поставщика на основе анализа предложений;
- подготовку и заключение договора с поставщиком ;
- внесение изменений (при необходимости) в договор в процессе его выполнения.
Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита. В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.
Процесс поставки охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой. Данный процесс включает следующие действия:
- инициирование поставки;
- подготовку ответа на заявочные предложения;
- подготовку договора;
- планирование работ по договору;
- выполнение и контроль договорных работ и их оценку;
- поставку и завершение работ.
Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения, соглашаться ли с выставленными требованиями и условиями или предложить свои (согласовать). Планирование включает следующие задачи:
- принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
- разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и др.
Процесс разработки предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО и его компонентов в соответствии с заданными требованиями. Сюда включается оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности, и качества программных продуктов , материалов, необходимых для организации обучения персонала и др.
Процесс разработки включает следующие действия:
- подготовительную работу;
- анализ требований, предъявляемых к системе;
- проектирование архитектуры системы;
- анализ требований, предъявляемых к программному обеспечению;
- проектирование архитектуры программного обеспечения;
- детальное проектирование программного обеспечения;
- кодирование и тестирование программного обеспечения;
- интеграцию программного обеспечения;
- квалификационное тестирование программного обеспечения;
- интеграцию системы;
- квалификационное тестирование системы;
- установку программного обеспечения;
- приемку программного обеспечения.
Подготовительная работа начинается с выбора модели ЖЦ ПО , соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбирать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки , а также составить план выполнения работ .
Анализ требований, предъявляемых к системе, подразумевает определение ее функциональных возможностей, пользовательских требований , требований к надежности, безопасности, требований к внешним интерфейсам, производительности и т.д. Требования к системе оцениваются, исходя из критериев реализуемости и возможности проверки при тестировании.
Проектирование архитектуры системы заключается в определении компонентов ее оборудования (аппаратуры), программного обеспечения и операций, выполняемых эксплуатирующим систему персоналом. Архитектура системы должна соответствовать требованиям, предъявляемым к системе, а также принятым проектным стандартам и методам.
Анализ требований к программному обеспечению предполагает определение следующих характеристик для каждого компонента ПО :
- функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
- внешних интерфейсов;
- спецификаций надежности и безопасности;
- эргономических требований;
- требований к используемым данным;
- требований к установке и приемке;
- требований к пользовательской документации;
- требований к эксплуатации и сопровождению.
Требования к программному обеспечению оцениваются, исходя из критериев соответствия требованиям, предъявляемым к системе в целом, реализуемости и возможности проверки при тестировании.
Проектирование архитектуры ПО включает следующие задачи для каждого компонента ПО :
- трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
- разработку и документирование программных интерфейсов ПО и баз данных (БД);
- разработку предварительной версии пользовательской документации;
- разработку и документирование предварительных требований к тестам и плана интеграции ПО.
Детальное проектирование ПО включает следующие задачи:
- описание компонентов ПО и интерфейсов между ними на более низком уровне, достаточном для последующего кодирования и тестирования;
- разработку и документирование детального проекта базы данных;
- обновление (при необходимости) пользовательской документации;
- разработку и документирование требований к тестам и плана тестирования компонентов ПО;
Кодирование и тестирование ПО включает следующие задачи:
- кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
- тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
- обновление документации (при необходимости);
- обновление плана интеграции ПО.
Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирования агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование – это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации.
Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (
Процесс эксплуатации охватывает действия и задачи организации оператора, эксплуатирующего систему. Процесс эксплуатации включает следующие действия.
Подготовительная работа, которая включает проведение оператором следующих задач:
- планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
- определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
- Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
- Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
- анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
- модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
- проверку и приемку (в части целостности модифицируемой системы);
- перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
- снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.