Жизненный цикл, процессы и модели жизненного цикла программного продукта
Проектирование и реализация АИС – трудоемкий, длительный и динамический процесс. Технологии проектирования, применяемые сегодня, предполагают поэтапную разработку системы. Этапы по общности целей могут объединяться в стадии.
Под стадиейпрограммногопроекта понимается часть процесса создания системы, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов и программ, документации и т.д.).
Совокупность стадий и этапов, которые проходит АИС в своем развитии от момента принятия решения о создании системы(создания технико – экономического обоснования (ТЭО) или бизнес – плана, после рассмотрения которого принимается решение о создании системы)до момента прекращения функционирования системы(т.е. утилизации системы), называется жизненным циклом АИС (ЖЦ АИС).
Под моделью ЖЦсистемы понимается структура, определяющая последовательность и упорядоченность во времени выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий создания и функционирования системы.
В соответствии с международным стандартом ISO (International Organization for Standardization) все процессы, выполняемые для создания программного проекта делятся на основные, вспомогательные и организационные (см. рис.4).
Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые необходимые входные данные в конкретные (заданные) выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Рисунок 4. Процессы жизненного цикла программного обеспечения
Каждый процесс разделен на набор действий, каждое действие – на набор задач.Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным). Состав и последовательности выполнения действий и задач определяется выбранной моделью ЖЦ и используемой технологией.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки, а описывает структуру процессов, не конкретизируя в деталях, как реализовывать или выполнять действия и задачи, включенные в эти процессы.
Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Регламенты ЖЦ являются общими для любых моделей ЖЦ, методологий и технологий разработки.
Процессы ЖЦ, регламентируемые стандартом ISO, могут использоваться различными организациями в конкретных проектах самым различным образом, Стандарт предлагает некоторый базовый набор взаимосвязей,который показан на рис. 5, между процессами с различных точек зрения или в различных аспектах.
Рисунок 5. Связи между процессами жизненного цикла
программного обеспечения
Такими аспектами являются:
· Договорной аспект;
· Аспект управления;
· Аспект эксплуатации;
· Инженерный аспект;
· Аспект поддержки (более подробно смотри - Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник\ М.: Финансы и статистика, 2002)
Отечественный стандарт на производство ИС отличается от международного стандарта. В Российском стандарте предусмотрена стадия проектирования и реализации (разработки информационной системы и написания ее программного продукта), тогда как в международном предполагается выбор готового программного продукта и адаптация его под конкретные условия предприятия (поставка и разработка).
Условно ЖЦ, в соответствии с Российским стандартом, состоит из следующих стадий (стадии приведены в соответствии с отечественным стандартом ГОСТ 34.003-90):
· планирование и анализ требований;
· проектирование;
· реализация;
· внедрение;
· эксплуатация и сопровождение;
· модернизация или снятие с эксплуатации.
Следует отметить, что проектирование и создание информационной системы можно проводить, используя две схемы проектирования - «снизу-вверх» и «сверху-вниз».
Схема «снизу – вверх» (микроанализ) предполагает автоматизацию отдельных наиболее необходимых по трудоемкости и интенсивности потоков задач или отдельных участков работы специалиста, с последующим объединением (интеграцией) этих участков в единую систему для достижения какой-либо цели.
При микроанализе изучается структура объекта, анализируются ее составляющие элементы с точки зрения их функциональных характеристик, проявляющихся через связи с другими элементами и внешней средой
Например, можно автоматизировать отдельные участки бухгалтерского учета с целью дальнейшего построения системы автоматизации бухгалтерского учета, т.е. создание системы, которая автоматически (при наличии исходных данных) решает определенный перечень задач по всем участкам бухгалтерского учета с одновременным формированием всех соответствующих форм отчетности по каждому участку. В дальнейшем эта система может быть агрегирована с системой автоматизированного управления складом, чтобы избежать повторного (и вносящего дополнительные ошибки) ввода исходных документов, во многом пересекающихся с исходными бухгалтерскими документами.
Схема «сверху - вниз» (макроанализ) предполагает использование системного подхода к построению информационной системы, т.е. рассматривается деятельность предприятия как деятельность единой системы производящей определенную продукцию.
При макроанализе система или ее элемент рассматриваются как часть системы более высокого порядка. Особое внимание уделяется информационным связям: устанавливается их число, выделяются и анализируются те связи, которые обусловлены целью изучения системы, а затем выбирают наиболее предпочтительные, реализующие данную целевую функцию.
В соответствии с методологией системного анализа изучение любой системы начинают с выявления глобальной или общей цели исследуемой системы.
Общая цель системы определяется ее назначением (миссией). Для промышленного предприятия - это производство продукции определенной номенклатуры, для транспортной организации – перемещение грузов заданного характера, для высшего учебного заведения – выпуск специалистов установленного профиля и т.п. Назначение определяет основную функцию системы. Возможно наличие у системы нескольких функций, причем некоторые из них по значению близки к основной. Например, транспортная организация наряду с перевозкой грузов может перевозить людей, как для собственных нужд, так и для других организаций. При изучении системы следует выявить все выполняемые ею функции, расположить их по приоритету и установить взаимосвязи между ними.
Деятельность системы (как любой сложной системы) детализируется, (разбивается на составные части и анализируется деятельность отдельно каждой части и взаимодействие этой части с другими частями) на отдельные виды деятельности в зависимости от стратегии управления предприятием. Выделенную по определенному признаку часть системы называют подсистемой. Это может быть, функциональное разбиение - рассмотрение деятельности предприятии как совокупности функций (учет, планирование, контроль, анализ и т.д.). Также это может быть разбиение по бизнес- процессам, когда бизнес- процесс рассматривается как цепочка всех необходимых действий приводящих к получению определенного продукта (производство видео кассет, пошив верхней одежды, печать фотографий и т.д.), внутри которых рассматривается деятельность по планированию, учету, контролю и анализу этого действия. Каждая единица детализации (вне зависимости от принципа детализации) в свою очередь разбивается на более мелкие, которые иерархически упорядочиваются и выстраиваются в структуры, заканчивающиеся описанием элементарного алгоритма с помощью миниспефицификации, т.е. далее не разбиваемым однозначно описанным действием. Для каждого элемента структуры определяется вид и форма представления входной и выходной информации, наличие или возможность создания формального (однозначного) алгоритма (возможность программирования этого алгоритма) преобразования входной информации в выходную, интенсивность обмена информацией с другими операциями или процедурами, требуемые для автоматизации ресурсы и средства. Определяя для каждого элемента входные/выходные потоки, форму их представления и требуемые для обработки ресурсы, разработчик этим формирует предпосылки и требования к интеграции отдельных операций и процедур между собой. В данном случае можно начинать автоматизацию с любой задачи и проводить в любой последовательности, т.к. точки интеграции (места, формы и форматы представления информации) определены для всего предприятия (всей системы) в целом.
В процессе проектирования АИС системный подход позволяет использовать математическое описание функционирования, исследование различных свойств отдельных объектов и системы в целом, моделировать изучаемые процессы для анализа работы вновь создаваемых систем.
Практическое значение системного подхода и моделирования состоит в том, что они позволяют в доступной форме не только отразить все существенное, но и использовать ЭВМ для исследования поведения системы в конкретных, заданных экспериментальных условиях.
В начале эпохи построения автоматизированных систем управления (70 годы прошлого столетия) использовался подход «снизу- вверх», т.е. проводили автоматизацию по мере возникновения потребности. В настоящее время переходят к использованию системного подхода, т.к. все большее распространение получают интегрированные корпоративные системы, обеспечивающие автоматизацию функций на всех уровнях управления.
Одновременно с развитием компьютерной техники и информационных систем модели ЖЦ системы, определяющие порядок выполнения стадий и этапов проекта, претерпевали различные изменения.
Каскадная модель
Каскадная модель (или водопадная) (до 70-х годов прошлого столетия), основанная на проектировании «снизу-вверх», представляет собой последовательный переход на следующий этап после завершения предыдущего (см. рис. 6). Каждый следующий этап начинается только после полного завершения предыдущего.
Используя эту модель проектирования, автоматизировались отдельные не связанные между собой задачи. Интеграция и совместимость этих задач рассматривалась конкретно в каждом отдельном случае и для ее реализации создавались отдельные процедуры. Поэтому при определении очередности проведения автоматизации на предприятии рекомендовалось автоматизировать последовательно рядом расположенные (с сильным взаимодействием) задачи.
С помощью каскадной модели очень хорошо строить маленькие локальные системы, но плохо – большие, т.к. процесс проектирования достаточно велик.
Положительные стороны применения каскадного подхода заключаются в следующем:
· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. Следует отметить, что создание документации сложный и очень трудоемкий процесс, крайне необходимый для успешного использования системы;
Рисунок 6. Каскадная схема разработки ПО
· выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
В чистом виде каскадный процесс применяется в настоящее время достаточно редко, разве что в случае небольших проектов или когда команда реализует проект, очень похожий на один из тех, что были осуществлены ею ранее.
Основная причина неприменимости каскадного процесса - сложность большинства приложений и существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Если мы говорим о системе управления, то она подвержена изменениям также как внешняя среда, поэтому модели управления предприятием (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
Тем не менее, каскадный процесс является основой для большинства других разновидностей процесса. Процессы, в которых каскадная схема применяется многократно, называются итеративными. Сразу оговоримся, что в итеративных процессах не обязательно все шаги каскадной схемы должны выполняться на каждой итерации.
Итерационная модель
Итерационная модель (70 – 80 годы прошлого столетия) предполагает итерационный возврат на предыдущий этап после выполнения очередного этапа. При проектировании «снизу – вверх», т.е. от решения отдельных задач к комплексной интегрированной системе, для комплектации проектных решений по отдельным задачам в общие системные решения или при недостаточной проработке первоначальных требований в процессе проектирования возникает потребность в пересмотре ранее сформулированных требований. Это может быть следствием запутанности функциональной структуры, рассогласованием и трудностью использования документации и т.д. Модель изображенную на рис. 7 называют моделью с промежуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя и увеличивают весь процесс разработки.
После завершения каждой стадии, возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании. В случае неточного изложения требований или их изменения в течение длительного периода создания проекта пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постичь та же участь.
Ниже мы рассмотрим две разновидности итеративных процессов – спиральные (спиральная модель ЖЦ) и инкрементальные (инкрементальная модель ЖЦ) процессы.
Для преодоления вышеперечисленных проблем была предложена спиральная модель.
Рисунок 7. Реальный процесс разработки ПО
Спиральная модель
Спиральная модель (80 – 90 годы), прототипная модель, предполагающая постепенное расширение прототипа АИС.
Проектирование в данном случае ведется «сверху – вниз», когда определяется состав функциональных подсистем, общие системные проектные решения (например, организация интегрированной (единой для всего предприятия) Базы Данных (БД), разработка технологии сбора, регистрации, накопления и передачи информации), а затем проводится постановка отдельных задач.
Программирование в данном случае ведется от головных модулей к модулям, выполняющим отдельные функции.
Мощность системы может наращиваться сразу по всей спирали или по секторам.
Согласно этой технологии АИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода.
Рисунок 8. Спиральная модель жизненного цикла
Версии программного продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.
Таким образом,. углубляются и последовательно конкретизируются детали проекта. В результате выбирается обоснованный вариант, который доводится до реализации.
При использовании спиральной модели на первый план выходят вопросы взаимодействия интерфейсов программных модулей между собой и с БД. На втором плане – реализация алгоритмов решения задач.
Основное желание заказчика АИС – получить готовое приложение высокого качества быстро при минимальных затратах на его разработку. Кроме того, вкладывая деньги в создание системы, заказчики желают контролировать процесс создания системы. Критерием качества должно быть наиболее полное удовлетворение требований заказчика на момент введения системы в эксплуатацию
Одним из условий обеспечения высокого качества является активное вовлечение заказчика в процесс разработки, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является совокупность приемов для быстрой разработки приложений RAD (Rapid Application Development) – RAD – технологии.
Данная технология обеспечивает создание на ранней стадии реализации действующей интерактивной модели системы, так называемой системы – прототипа, позволяющей наглядно продемонстрировать пользователю будущую систему (в других моделях он ее видит только на этапе внедрения), уточнить его требования, оперативно модифицировать интерфейсные элементы: формы ввода сообщений, выходные документы, структуру диалога, состав реализуемых функций. Этим реализуется возможность получать замечания и дополнения в процессе проектирования, снижая стоимость (исправление ошибки, совершенной на предыдущем этапе, стоит в 10 раз дороже ошибки текущей) и время разработки и повышая качество системы.
В случае спирального процесса (автор Барри Боэм, 1988) последовательность анализ требований - проектирование - реализация - тестирование выполняется более одного раза.
Для этого может быть несколько причин:
- необходимость предупреждения рисков;
- необходимость предоставить заказчику частичную версию проекта для получения отзывов и пожеланий.
Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность). Таким образом, уточняется план-график дальнейшей работы.
Минусы использования спиральной модели:
1. Требуется более искусное управление;
2. Необходимость поддержки целостности документации, которая должна быть полностью сформирована к концу каждой версии;
3. Трудность в определении момента перехода на следующий этап;
4. Переход осуществляется в соответствии с планом, даже если не все работы выполнены;
5. Слишком большое количество витков потребует увеличения затрат;
Типичный проект, трудоемкость которого оценивается в три человеко-месяца, а продолжительность - в четыре месяца, вероятнее всего, потребует две-три итерации. Затраты на проведение большего числа итераций могут просто перевесить выгоду от дополнительных итераций.
Жизненный цикл при использовании RAD – технологии предполагает активное участие на всех этапах разработки конечных пользователей будущей системы и включает 4 основных стадии информационного инжиниринга:
- анализ и планирование информационной стратегии. Пользователи вместе со специалистами – разработчиками участвуют в идентификации проблемной области (детализации функциональности, анализе, определении видов деятельности, активных субъектов, входных/выходных точек, и т.д.);
- проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов – разработчиков;
- реализация. Специалисты – разработчики разрабатывают рабочую версию АИС с использование современных языков программирования;
- внедрение. Специалисты – разработчики обучают пользователей работе в среде новой АИС.
Все приемы для быстрой разработки приложений RAD служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся:
· разработка приложений итерациями;
· необязательность полного завершения работ на каждом из этапов ЖЦ для начала работ на следующем;
· обязательное вовлечение пользователей в процесс проектирования и построения системы;
· высокая параллельность работ (чем выше параллельность работ, тем меньше длительность проекта);
· повторное использование частей проекта;
· необходимое применение CASE (Computer- Aided (помощник) Software/System Engineering) – средств, обеспечивающих техническую целостность на этапах анализа и проектирования;
· применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы;
· использование автоматических генераторов (мастеров);
· использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;
· тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа.