Проектная команда со стороны заказчика



Техническое задание(Лк5)

 

ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы"

ТЗ наАС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

Можно сказать, что ТЗ ГОСТ34 определяет следующие процессы:

1. Определение требований к системе;

2. Проектирование системы;

3. Ввод в действие системы.

Здесь, как можно заметить, отсутствует цикличность в процессах проектирования, ввода в действие (внутренние циклы) и возврат в начало перед утилизацией и списанием (относится к ЖЦ системы в целом и обычно не рассматривается в ТЗ на конкретный вариант). Как уже было отмечено, эти пробелы восполняются стандартом ИСО/МЭК 15288. Это важно понимать, потому что одним из разделов ТЗ, как правило, определяется план работ, который по существу есть проекция ЖЦ системы.

Ролевые функции членов проектных команд

 

Реализация ТЗ БС - труд коллективный. В нём участвуют, как проектная команда со стороны исполнителя, так и со стороны заказчика (правообладателя). Чтобы понять, кто отвечает за производство конкретного пункта ТЗ, необходимо рассмотреть состав того и другого коллектива более подробно.

Проектная команда со стороны исполнителя

 

Руководитель программы.

Отвечает за реализацию блока проектов по направлению. Имеет статус линейного менеджера, т.е. имеет реальных подчинённых. Обычно возглавляет подразделение Delivery. В его подчинении находятся руководители проектов, системные архитекторы, инженеры, аналитики, технические писатели. Отвечает за реализацию программы на верхнем уровне. Контактирует с заказчиком на уровне дирекции. Решает организационные и политические вопросы. Формирует проектные команды в рамках т.н. матричной структуры. Координирует деятельность т.н. FixedCost&VariableCost…

Проектный менеджер (PM).

Не имеет реальных подчинённых. Члены проектной команды выполняют его указания в рамках работ по конкретному проекту. Однако, имея достаточно ограниченные властные полномочия, PM отвечает за всё:

­ Сроки реализации проекта;

­ Качество реализации;

­ Взаимодействие с командой заказчика;

­ Успешное подписание актов завершения этапов плана работ;

­ Координацию в рамках проекта и т.д.

Главный системный архитектор (Chief/SeniorSystemArchitect) или главный инженер отвечает за техническую реализацию проекта в целом. Он ставит задачи системным архитекторам, инженерам, программистам, проектирует архитектуру решения.

Системный архитектор отвечает за архитектуру решения конкретного направления (подсистемы) в рамках всего решения. Согласовывает свои действия с главным архитектором.

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

Системные аналитики несут ответственность за сбор информации об объекте автоматизации, структурирование этой информации, реализацию пунктов ТЗ, рабочей документации, отработку документов по troublerequest&changerequest в ходе опытной эксплуатации.

Технические писатели несут ответственность за грамотное оформление технической документации и не только…

Тестеры осуществляют тестирование модулей иногда средствами инструментального тестирования, например, IBM RationalTestManager. Часто в работу по тестированию включаются аналитики, т.к. именно они готовят troublereport&changerequest. Используются также средства bagtracking, позволяющие автоматизировать процесс устранения ошибок и траблов методом централизованного хранения истории и автоматического оповещения ответственных лиц.   

Также к проекту привлекаются исполнители из т.н. FixedCost подразделений: финансовый менеджер (FM), риск менеджер (RM), менеджер по качеству (QM), юрист. Роль последних весьма иллюзорна, однако без их визы невозможен ряд шагов. Тем не менее, расчёты трудозатрат, для чего собственно и нужна эта команда, готовятся чаще всего на уровне системных архитекторов и руководителя проекта, все остальные «манагеры» лишь вносят в эти таблицы небольшие корректировки (% риска и т.п.).

Проектная команда со стороны заказчика

 

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

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

Например, на базе ФГУП НИИ ГО ЧС существует структура, которая помогает качественно оформить ТЗ по всем нормативам этого непростого ведомства, что обеспечивает относительно беспрепятственное согласование документа с этим институтом. Следует добавить, что все проекты регионального масштаба должны проходить согласование в НИИ ГО ЧС. Подобные механизмы не только увеличивают бюрократическую нагрузку с одной стороны, но и позволяют сохранять определённый уровень стандартизации, унификации и безопасности решения.

Роль и значение ТЗ в ЖЦ АС

 

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

Тем не менее, следует различать ТЗ на тендер (этого нет в ГОСТ) и ТЗ на АС. ТЗ на тендер может разрабатываться самим заказчиком, но чаще всего этот процесс осуществляется разработчиком Концепции. Не редко при разработке ТЗ на тендер участвует потенциальный исполнитель не явно, чтобы обеспечить необходимые условия для выигрыша конкурса. Это объяснимо:

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

2. Не так много в России исполнителей, которые способны заниматься подобными проблемами. Это «штучный» товар. И чаще всего подобные организации существуют в единственном экземпляре, следовательно, надо отсечь недобросовестных участников. Например, понятно, что разработкой АСУ НАКУ занимается только РНИИ КП, как головная организация, поэтому необходимо создать такие условия, чтобы именно этот претендент выиграл, и не пришлось отменять результаты конкурса, что влечёт потерю времени и средств.

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

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

После определения исполнителя по результатам конкурса, он приступает к разработке ТЗ на АС. Этот документ утверждается автором концепции, а если система несёт в себе нагрузку по государственной безопасности, то и представителями НИИ ФСБ, МВД, МО и т.п. Взаимодействие с этими организациями берёт на себя директор программы и/или специальный руководитель, который является бывшим или действующим сотрудником высокого ранга (генерал). Иначе результат далеко не гарантирован.

ТЗ несёт как техническую, так и юридическую нагрузку, т.к. оно включается в качестве приложения в договор. ТЗ может содержать план выполнения работ, который практически представляет собой ЖЦ системы. Этот план отдельно или в составе ТЗ включается в юридический документ – договор заказчика и поставщика решения. Практически пункты этого плана ассоциируются с подписанием юридически обязывающих актов выполнения работ, в соответствии с которыми идёт перечисление денег исполнителю (Пример: разработка ERP для Госдумы). Поэтому менеджер проекта со стороны исполнителя должен естественно стремиться, как можно дороже оценить те этапы, которые не связаны с какой-либо неопределённостью и потенциально наименее рискованы с т.з. возникновения противоречий между заказчиком и поставщиком решения. Естественно, что наиболее «опасным» с этой точки зрения являются стадия ввода в действие на этапе опытной эксплуатации и приёмочных испытаний. Часто бывает, что заказчик воспринимает функционал, работоспособность, эксплуатационные качества и т.п. системы как неудовлетворительные, абсолютно игнорируя сложность поставленной задачи и соответственно количество отпущенных средств и ресурсов на её выполнение. Понятно, что большая сложная система, как это было рассмотрено в первой лекции, тем и характерна, что присутствует нечёткость целей, большое количество компонентов, сложность этих компонентов, недостаточное или вообще невозможное описание связей и структуры компонентов, их зависимость от внешних по отношении к системе факторов. Эти проблемы, как раз и выявляются во время опытной эксплуатации. Т.о. для того, чтобы создать работоспособный экземпляр часто необходим возврат на стадию проектирования или даже ТЗ на АС с целью доработки или существенной переработки системы, особенно если проектирование проводится, что называется с «0» (циклическое, а не каскадное проектирование - waterflow). Однако это стоит за пределами понимания большинства крупных руководителей, особенно, если в их образовательномbackground отсутствует инженерная составляющая. А это в наше время не редкость. Возникает конфликт, который часто приводит к разрыву отношений, поэтому большинство IT проектов заканчиваются как у нас, так и на Западе неуспехом. Поэтому финансовое обеспечение деятельности компании, связанное с выполнением дорогостоящих этапов вплоть до проектирования следует стремиться переложить на плечи заказчика. Это же служит гарантией дополнительного выделения средств для решения проблем.

Пример: проектирование Siemens системы класса OSS/BSS для ОАО «Северо-Западный Телеком».

ТЗ – это, по сути, документ, формализующий и структурирующий весь процесс ЖЦ изделия, документ, который служит своеобразным договором между заказчиком и исполнителем по всему циклу работ. Оно позволяет установить необходимый порядок взаимоотношений между командами и должностными лицами как с той, так и с другой стороны. Если в процессе проектирования выясняется, что ТЗ не удовлетворяет по каким-либо причинам, как разработчика, так и заказчика, то по взаимной договорённости разрабатывается новое ТЗ или дополнение к существующему ТЗ. Обычно такая возможность отдельно прописывается либо в контракте, либо непосредственно в тексте ТЗ.

ТЗ является проекцией системного подхода на методологию проектирования АСУ согласно ГОСТ 34, практически основные разделы документа соответствуют идеям системного анализа (цель системы, декомпозиция по структуре и функциям, синтез).

 


Дата добавления: 2018-04-15; просмотров: 1346; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!