Принципы составления технического задания (стр. 3 из 4)
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 Результаты процесса прикладного моделирования
В результате успешной реализации процесса прикладного моделирования:
a) изучена предметная область;
b) определены и согласованы цели, назначение и основная функциональность программной системы;
c) разработан единый словарь терминов;
d) определены заинтересованные стороны, а также взаимодействующие организации и сторонние АИС;
e) определены бизнес-процессы и бизнес–роли программной системы;
f) разработаны предварительная архитектура программной системы и схема движения информации;
g) утверждены артефакты и передаются для дальнейшей работы.
3.9 Цель процесса определения требований заинтересованного лица
Цель процесса определения требований заинтересованного лица заключается в определении требований к программной системе, которая должна предоставлять услуги, требуемые заказчиком.
Этим процессом определяются требования заказчика, которые анализируются и преобразуются в приемлемые требования к программной системе. Требования заказчика должны включать потребности и желания всех сторон, заинтересованных в жизненном цикле программной системы. Требования заказчика выражают предполагаемое взаимодействие программной системы с заинтересованными лицами и являются эталоном, по которому проверяется функциональность программного продукта и его способность предоставлять услуги.
Для этих целей заказчик выделяет в проект своего полномочного представителя и наделяет его функциями принятия решения. Степень участия заказчика в разработке может оговариваться в договоре или плане руководства проектом.
Также этим процессом уточняются заинтересованные лица или группы заинтересованных лиц, причастных к программной системе в течение ее жизненного цикла и выражаются потребности, желания и ожидания заинтересованных лиц вместе с ограничениями, накладываемыми этими лицами и условиями эксплуатации.
3.10 Результаты процесса определения требований заинтересованного лица
В результате успешной реализации процесса определения требований заинтересованного лица:
a) детализированы бизнес-процессы, определены бизнес-функции процессов и создана модель артефактов;
b) оговорены требуемые характеристики программной системы и инфраструктура пользователя, в которой она будет использоваться;
c) определены ограничения программной системы и ее элементов;
d) достигнута постоянная отслеживаемость требований заинтересованного лица;
e) определена основа для анализа требований к программной системе;
f) обеспечена основа для ведения переговоров и согласования поставки услуг или продукта.
3.11 Цель процесса анализа требований
Цель процесса анализа требований к программному обеспечению заключается в преобразовании требований заинтересованного лица в техническое видение требуемого программного продукта. Этим процессом создается представление о будущей программной системе, которая должна удовлетворять потребностям заинтересованного лица без описания какого-либо конкретного воплощения.
В требованиях к программной системе или услугам, с точки зрения разработчика, оговаривается, что должна делать программная система (услуга), чтобы удовлетворить требованиям заинтересованного лица. Эти требования могут быть функциональными, количественными или качественными.
На основании анализа требований заинтересованного лица разработчик с участием заказчика разрабатывает техническое задание.
В техническом задании разработчик обязан установить оговоренные требования к разрабатываемой программной системе, включая спецификации качественных характеристик. Требования, задаваемые в техническом задании, не должны ограничивать разработчика в поиске и реализации наиболее эффективных решений, но могут оговаривать применяемые технологии и методологии разработки. Структура технического задания указана в приложении 4.