CC BY
245
ДОКУМЕНТИРОВАНИЕ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННЫХ СИСТЕМ А.А Зарафьянц
Создание информационных систем - один из самых сложных видов совместной деятельности человека в группе, и для улучшения понимания процесса, координации действий команды и заказчика, фиксирования промежуточных результатов, управления качеством и устранения дефектов необходимо надлежащее документирование жизненного цикла проекта.
Проект - это комплекс взаимосвязанных мероприятий, предназначенных для достижения поставленных задач в течение заданного периода времени и при установленном бюджете с четко определенными целями. Как и любой проект, создание информационной системы проходит через определенные этапы в своем развитии. Под жизненным циклом обычно понимают процесс, который начинается с момента принятия решения о начале проекта и заканчивается лишь в момент полного изъятия информационной системы из эксплуатации [5].
У каждого проекта можно выделить начальную (предынвестиционную) стадию, стадию реализации проекта и стадию завершения работ по проекту. Это может показаться очевидным, но понятие жизненного цикла проекта является одним из важнейших для руководителя (менеджера) проекта, поскольку именно текущая стадия определяет задачи и виды деятельности, используемые методики и инструментальные средства.
Для любого проекта жизненный цикл сильно зависит от производимого продукта. Система - это комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям. Информационная система [6] - это система, предназначенная для сбора, передачи, обработки, хранения и выдачи информации потребителям и состоящая из следующих основных компонентов:
- программное обеспечение,
- информационное обеспечение,
- технические средства,
- обслуживающий персонал
Простейшая модель жизненного цикла системы - водопадная или каскадная модель, где каждый следующий этап начинается после предыдущего. Этапами водопадной модели могут быть анализ, проектирование, реализация, внедрение, сопровождение.
Более сложная модель жизненного цикла программной системы - спиралевидная модель Боэма, приведенная на рис. 1. Модель Боэма [2] итеративна - разработка ведется в несколько этапов, и на каждом новом этапе используются сделанные ранее наработки. На первом этапе определяются цели задачи проекта, формулируются требования. Концепции оцениваются, формулируется план по требованиям и жизненному циклу. На втором витке проектирования составляются и проверяются детальные спецификации, создается прототип и проводится анализ рисков, проект проверяется, утверждается и разрабатывается детальный план. Анализ рисков и построение прототипа на следующем витке предвосхищают процесс непосредственной реализации системы.
В ходе разработки ведется работа над рядом документов. В первую очередь создается общее описание проекта, концепции разработки. Далее появляются спецификации и детальное техническое задание. Спецификации - один из наиболее важных документов [3]. Он представляет собой пронумерованный список требований, минимально зависимых друг
от друга. Качество реализации каждого из сформулированных пунктов-требований к системе будет проверяться на завершающих стадиях проекта. Спецификации - продукт переговоров заказчика и разработчика, этот документ должен быть понят и заверен обеими сторонами.
Рис. 1. Спиральная модель Боэма
Дизайн системы должен быть подробно задокументирован и понят разработчиками. Обычно он создается с помощью CASE-средств разработки. Он может содержать диаграммы Entity-relationship логической структуры базы данных, различные UML диаграммы, например диаграммы основных классов, диаграммы взаимосвязи объектов, модульные диаграммы. Обязательный этап при завершении дизайна системы - его презентация, проверка и утверждение.
Рис. 2. V- образная модель
Существуют и другие модели жизненного цикла, более подробно рассмотренные в [4]. Например, У-образная модель, отображенная на рис. 2, часто важна для понимания сути процесса разработки ПО. Этапы расположены на теле английской буквы У, и каждый последующий этап находится правее предыдущего, но в У-образной модели возможно горизонтальное возвращение - возврат к предыдущим стадиям соответствующего уровня. Так, если на этапе интеграции модулей найдена какая-либо ошибка, то происходит возврат к рассмотрению общего дизайна системы, после чего происходит последовательный спуск по У-модели, изменяется дизайн и реализация каждого из модулей, затем модули тестируются в отдельности, и затем происходит общая интеграция модулей.
Выбор модели жизненного цикла зависит от многих факторов, и в первую очередь от специфики и сложности проекта, от стандартов, принятых в организации, от выбранных средств дизайна и разработки. На рис. 3 отражено то общее, что объединяет все модели жизненного цикла [1]. Каждая фаза проекта обязательно должна сопровождаться документацией
проект
Фазы
Деятельности
Поставляемые продукты
Документы
Документы Документы
Рис. 3. Фазы проекта сопровождаются документами.
Важность документирования трудно переоценить. Для чего нужно документирование? Приведем пример, скажем, фирме-разработчику интернет-сайтов поступил заказ на создание типового сайта, предъявлены жесткие требования по срокам выполнения. Фирма небольшая, состоит всего из нескольких человек, процесс разработки давно известен всем разработчикам, излишнее документирование может отвлечь ресурсы и задержать проект. С другой стороны, необходимое условие зрелости фирмы разработчика - документирование каждого шага. Но что произойдет, если ведущий разработчик покинет фирму? Останется ли процесс понятным для остальных членов команды?
На заре существования программирования успешными оказывалось крайне мало проектов. Большая их часть просто не доводилась до конца. В США в 1984 г в университете Карнеги - Меллона осознали эту проблему, и был создан Институт технологии программирования. Через несколько лет работы института в его недрах создали модель зрелости и способности (СММ), в рамках которой процесс разработки ПО был формализован, определены основные виды деятельности. Теперь при использовании модели зрелости и способности мы можем существенно увеличить вероятность успешного выполнения проекта.
Так, на третьем уровне зрелости в модели СММ появляется так называемая «книга процесса». В книге процесса описан процесс создания типовых проектов, в ней отражены детали процесса, что позволяет надеяться на то, что фирма сможет повторить типовой проект, если будет следовать описанному процессу.
Стандарты модели CMM предъявляют жесткие требования к документированию процесса разработки программного обеспечения. Например, если организация отвечает 3-му уровню зрелости модели CMM, с уверенностью можно сказать, что процесс в ней управляемый и повторяемый, и данная организация выполнит заказ, если он аналогичен уже выполненным проектам. Напомним, что критерий успеха - в срок, уложившись в бюджет, выполнить проект с достаточным качеством.
Зачастую стандарты CMM излишне сложны, а клиенту, заказывающему уникальный проект, в первую очередь важно качество выполненных работ. Система управления качеством, налаженная у производителя, может отвечать стандартам серии ISO 9000. В случае, если разработчик сертифицирован по стандартам качества ISO, заказчик может быть уверен, что информационная система пройдет проверку качества.
Стандарты качества ISO 9000 предъявляют общие требования к наличию и структуре документов, управлению документацией, отслеживанию дефектов.
Международный стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, которые должны быть выполнены во время создания программного обеспечения информационной системы. Эти процессы подразделяются на три группы: основные (приобретение, поставка, разработка, эксплуатация и сопровождение), вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит и решение проблем) и организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение). Стандарт ISO/IEC 12207 не предлагает конкретной модели жизненного цикла и методов разработки, его рекомендации являются общими для любых моделей жизненного цикла.
Следующим шагом в вопросе документальной поддержки жизненного цикла информационной системы является его автоматизация. Однако автоматизация различных процессов, связанных с разработкой, производством и эксплуатацией как изделий промышленности, так и информационных систем наиболее эффективна в том случае, когда она охватывает все этапы жизненного цикла изделия. При этом необходимо преодоление следующих проблем: наличие множества различных систем, ориентированных на решение конкретных задач, относящихся к разным этапам жизненного цикла, приводит к трудностям обмена данными между смежными системами; участие в поддержке жизненного цикла изделия нескольких предприятий требует эффективного обмена информацией об изделии между партнерами; сложность изделия, наличие множества его модификаций, заимствование, стандартизация, унификация требуют поддержки многоуровневых многовариантных сборочных моделей. Эти проблемы могут быть преодолены путем реализации концепции CALS.
Аббревиатура CALS расшифровывается как Continuous Acquisition and Life cycle Support - непрерывная информационная поддержка жизненного цикла продукта. Встречается также другой перевод, менее схожий с исходным названием, но более близкий по смыслу: обеспечение неразрывной связи между производством и прочими этапами жизненного цикла изделия. Данная технология, разработанная в 80-х годах в Министерстве обороны США, распространилась по всему миру и охватила практически все сферы мировой экономики. Она предназначена для повышения эффективности и качества бизнес-процессов, выполняемых на протяжении всего жизненного цикла продукта, за счет применения безбумажных технологий. Началом создания системы CALS-технологий явилась разработка системы стандартов описания процессов на всех этапах жизненного цикла продукции.
Стандарты, разработанные ISO для CALS-технологий, можно разбить на три группы: представление информации о продукте, представление текстовой и графической информа-
ции и общего назначения. К первой группе относятся: ISO/IEC 10303 Standard for the Exchange of Product Model Data (STEP) и ISO 13584 Industrial Automation -- Parts Library.
Во вторую группу входят: ISO 8879 Information Processing -- Text and Office System -Standard Generalised Markup Language (SGML); ISO/IEC 10179 Document Style Semantics and Specification Language (DSSSL); ISO/IEC IS 10744 Information Technology -Hypermedia/Time Based Document Structuring Language (HyTime); ISO/IEC 8632 Information Processing Systems -- Computer Graphics - Metafile; ISO/IEC 10918 Coding of Digital Continuous Tone Still Picture Images (JPEG); ISO 11172 MPEG2 Motion Picture Experts Group (MPEG); Coding of Motion Pictures and associated Audio for Digital Storage Media и ISO/IECS 13522 Information Technology -- Coding of Multimedia and Hypermedia Information (MHEG).
Третья группа: ISO 11179 Information Technology -- Basic Data Element Attributes; ISO 3166 Information Processing -- Country Name Representations; ISO 31 Information Processing Representation of Quantities and Units; ISO 4217 Information Processing -- Currencies and Funds; ISO 639 Information Processing Coded Representation of Names of Languages и ISO 8601 Information Processing -- Date/Time Representations.
Кроме международных стандартов, разработанных ISO, стандарты CALS широко представлены стандартами с индексами MIL и FIPS, которые лишний раз подчеркивают приоритетность разработки технологии CALS Соединенными Штатами и их военным ведомством изначально (самая многочисленная группа стандартов CALS имеет индекс MIL -стандартный индекс для документов, разработанных в МО США). Аббревиатура FIPS означает Федеральный стандарт обработки информации (Federal Information Processing Standard).
Стандарты CALS военного ведомства США, имеющие индекс MIL, также можно разбить на три группы: общих принципов электронного обмена и управления данными; представления текстовой и графической информации; электронных технических руководств.
Стандарты FIPS не так многочисленны, как ISO и MIL, и делятся всего на две группы: описания процессов и безопасности информации.
В заключение следует отметить, что надлежащее документирование создания информационных систем трудно переоценить. Особенности выбранного жизненного цикла во многом определяют состав документации. Адаптация модели CMM, стандартов ISO 9000, следование стандартам CALS и применение систем автоматизации проектирования позволят наладить эффективный безбумажный документооборот и сделать жизненный цикл более прозрачным, понятным и управляемым, помогут обеспечить заданное качество и, уложившись в отведенный бюджет, выполнить проект в срок.
Литература
1. New York State office for technology.The New York State Project Management Guide Book, 2001.
2. Bohem B.W. A Spiral Model of Software Development and Enhancement». // Computer, May 1988. P. 61-72.
3. Boehm B., Horowitz L. Software Requirements As Negotiated Win Conditions» // Computer, April 1994.
4. Баранов C.H. Конспект лекций по курсу «Управление программным проектом». СПбГИТМО(ТУ), 1998.
5. Ефимов Г. Жизненный цикл информационных систем // Сетевой жрнал. 2001. №2.
6. Зиндер Е. Что такое информационная система // ОС.Директор ИС. 2002. №6.
