Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

e) сопровождение программной системы;

f) утилизация программной системы.

Используя указанные этапы и процессы, поставщик совместно с заказчиком должны создать модель жизненного цикла конкретной программной системы.

Начало и конец каждого этапа и процесса должны быть документально оформлены в установленном в организации порядке.

3.1 Этап предпроектных работ

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

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

Выходными элементами этапа предпроектных работ являются следующие основные артефакты:

— концепция системы;

— бизнес–предложение.

На этом этапе принимается решение: продолжать реализацию программной системы или прекратить дальнейшую работу.

3.2 Этап разработки

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

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

Результатом выполнения этапа являются разработка программного продукта, работоспособность и функциональность которого подтверждена квалификационными испытаниями, необходимой документацией, а также проведение других необходимых разработок.

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

Выходными элементами этапа разработки являются следующие основные артефакты:

— техническое задание;

— технический проект;

— версия программной системы;

— техническая документация;

— протокол квалификационного тестирования;

— акт передачи в опытную эксплуатацию.

В случае объявления тендера на разработку программной системы техническое задание должно являться составной частью тендерного предложения.

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

3.3 Процессы жизненного цикла программной системы

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

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

Любой процесс, применяемый в жизненном цикле программной системы, продолжителен во времени. Структурно он может состоять из трех фаз, как показано на рисунке 3.

Структура выполнения процессов

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

Во время активной фазы происходит непосредственное выполнение процесса. В настоящем техническом регламенте при описании процессов освещаются действия только активной фазы.

Во время фазы завершения могут выполняться действия по анализу результатов, завершаться деятельности, начатые во время активной фазы, продолжаться работы, не ограниченные сроком окончания.

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

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

3.4 Перечень процессов

Процессы жизненного цикла программной системы объединяются в четыре группы, согласно таблице 1.

Процессы жизненного цикла программной системы

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

Технические процессы и основные деятельности, заканчивающиеся созданием артефактов, распределяются по этапам жизненного цикла программной системы, как указано на рисунке 5.

Этапы	Процессы или основные деятельности	Временные диаграммы выполнения процессов и основных деятельностей	Основные артефакты
Предпроектные работы	Концептуальное моделирование		Концепция
	Прикладное моделирование		Бизнес-предложение
Разработка	Определение требований		Техническое задание
	Анализ требований		Техническое задание
	Структурное проектирование		Технический проект
	Воплощение		Программный продукт Документация

3.5 Цель процесса концептуального моделирования

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

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

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

За действия в рамках этого процесса отвечает поставщик. Ему необходимо оформить проект концепции и подготовить документы, необходимые для ее согласования. Структура концепции системы - согласно приложению 3.

Оформление, согласование и утверждение концепции осуществляются в соответствии с:

a) законом Республики Молдова о нормативных актах Правительства и других органов центрального и местного публичного управления № 317-XV от 18.07.2003 г. („Monitorul Oficial al Republicii Moldova” № 208-210/783 от 03.10.2003 г.);

b) Постановлением Правительства о порядке проведения юридической экспертизы и государственной регистрации ведомственных нормативных актов №1104 от 28.11.1997 г. („Monitorul Oficial al Republicii Moldova” № 6-7/10 от 21.01.1998 г.).

3.6 Результаты процесса концептуального моделирования

В результате успешной реализации процесса концептуального моделирования:

a) определены цель и назначение моделируемой АИС;

b) изучены нормативно-правовая база, организационная структура управления и разработаны предложения по их актуализации;

c) определены функциональность, информационные объекты и потоки, пути интеграции с другими системами;

d) концепция оформлена, согласована и утверждена заказчиком.

3.7 Цель процесса прикладного моделирования

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

Описанный вариант программного продукта поставщик предлагает заказчику в виде бизнес–предложения, краткое содержание которого определено в приложении 1.

Заказчик анализирует предложенный вариант программного продукта, утверждает бизнес–предложения и передает их поставщику для дальнейшей работы по сбору требований и анализу.

3.8 Результаты процесса прикладного моделирования

В результате успешной реализации процесса прикладного моделирования:

Характеристики

Список файлов реферата