Жизненный цикл, процессы и модели жизненного цикла программного продукта

Проектирование и реализация АИС – трудоемкий, длительный и динамический процесс. Технологии проектирования, применяемые сегодня, предполагают поэтапную разработку системы. Этапы по общности целей могут объединяться в стадии.

Под стадией программногопроекта понимается часть процесса создания системы, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов и программ, документации и т.д.).

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

Под моделью ЖЦ системы понимается структура, определяющая последовательность и упорядоченность во времени выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий создания и функционирования системы.

В соответствии с международным стандартом ISO (International Organization for Standardization) все процессы, выполняемые для создания программного проекта делятся на основные, вспомогательные и организационные (см. рис.4).

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

Рисунок 4. Процессы жизненного цикла программного обеспечения

Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным). Состав и последовательности выполнения действий и задач определяется выбранной моделью ЖЦ и используемой технологией.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки, а описывает структуру процессов, не конкретизируя в деталях, как реализовывать или выполнять действия и задачи, включенные в эти процессы.

Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Регламенты ЖЦ являются общими для любых моделей ЖЦ, методологий и технологий разработки.

Процессы ЖЦ, регламентируемые стандартом ISO, могут использоваться различными организациями в конкретных проектах самым различным образом, Стандарт предлагает некоторый базовый набор взаимосвязей, который показан на рис. 5, между процессами с различных точек зрения или в различных аспектах.

Рисунок 5. Связи между процессами жизненного цикла

программного обеспечения

Такими аспектами являются:

· Договорной аспект;

· Аспект управления;

· Аспект эксплуатации;

· Инженерный аспект;

· Аспект поддержки (более подробно смотри - Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник М.: Финансы и статистика, 2002)

Отечественный стандарт на производство ИС отличается от международного стандарта. В Российском стандарте предусмотрена стадия проектирования и реализации (разработки информационной системы и написания ее программного продукта), тогда как в международном предполагается выбор готового программного продукта и адаптация его под конкретные условия предприятия (поставка и разработка).

Условно ЖЦ, в соответствии с Российским стандартом, состоит из следующих стадий (стадии приведены в соответствии с отечественным стандартом ГОСТ 34.003-90):

· планирование и анализ требований;

· проектирование;

· реализация;

· внедрение;

· эксплуатация и сопровождение;

· модернизация или снятие с эксплуатации.

Следует отметить, что проектирование и создание информационной системы можно проводить, используя две схемы проектирования - «снизу-вверх» и «сверху-вниз».

Схема «снизу – вверх» (микроанализ) предполагает автоматизацию отдельных наиболее необходимых по трудоемкости и интенсивности потоков задач или отдельных участков работы специалиста, с последующим объединением (интеграцией) этих участков в единую систему для достижения какой-либо цели.

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

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

Схема «сверху - вниз» (макроанализ) предполагает использование системного подхода к построению информационной системы, т.е. рассматривается деятельность предприятия как деятельность единой системы производящей определенную продукцию.

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

В соответствии с методологией системного анализа изучение любой системы начинают с выявления глобальной или общей цели исследуемой системы.

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

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

В процессе проектирования АИС системный подход позволяет использовать математическое описание функционирования, исследование различных свойств отдельных объектов и системы в целом, моделировать изучаемые процессы для анализа работы вновь создаваемых систем.

Практическое значение системного подхода и моделирования состоит в том, что они позволяют в доступной форме не только отразить все существенное, но и использовать ЭВМ для исследования поведения системы в конкретных, заданных экспериментальных условиях.

В начале эпохи построения автоматизированных систем управления (70 годы прошлого столетия) использовался подход «снизу- вверх», т.е. проводили автоматизацию по мере возникновения потребности. В настоящее время переходят к использованию системного подхода, т.к. все большее распространение получают интегрированные корпоративные системы, обеспечивающие автоматизацию функций на всех уровнях управления.

Одновременно с развитием компьютерной техники и информационных систем модели ЖЦ системы, определяющие порядок выполнения стадий и этапов проекта, претерпевали различные изменения.

Дата добавления: 2014-01-13