Документирование информационных систем.Формирование требований к документации ИС. Состав документов, соответствующих этапам жизненного цикла ИС.

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

В части оформления проектной документации автоматизированных систем на сегодняшний день существует достаточно приемлемая, хотя и нуждающаяся в совершенствовании регламентация, а именно группа ГОСТов, относящихся к 34 серии, в частности:

ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем.

· ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

· ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

· ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем

· РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

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

Аналогичная проблема возникает в связи с тем, что состав документов, предусмотренный ГОСТ 34.201-89, является в значительной степени избыточным, а часть из них либо утратила смысл в силу развития технологий, либо не применима к большинству информационных систем (например, «Схема соединений» для проектов, в рамках которых не производится поставка технических средств, или «Пакеты входных/выходных данных» для систем, реализующих взаимодействие). С другой стороны, документация стадий эскизного и технического проектировании имеет каскадную структуру – большинство документов соответствуют определенным разделам общей пояснительной записке, дополняя или уточняя их.

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

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

Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС.	2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе.
3. Техническое задание.	Разработка и утверждение технического задания на создание АС.
4. Эскизный проект.	4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части.
5. Технический проект.	5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. Рабочая документация.	6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ.
7. Ввод в действие.	7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний.
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание.

 

Управление проектом. Методы планирования и управления проектами и ресурсами.

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

УП необходимо, потому что:

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

2. достижение определенных целей требует ресурсов, которые необходимо обеспечить, скоординировать и использовать;

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

"Управление проектами", его методология, обширный организационный инструментарий и специальные средствапозволяют:

1. Инициировать осуществление, как проекта, так и его отдельных фаз.

2. Разработать научно-обоснованную концепцию проекта.

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

4. Разработать комплексный проект и систему управления им, включая:

1. цели и результаты

2. календарный план

3. смету и бюджет

4. организационное моделирование

5. формирование команды

6. коммуникации в проекте

7. риски в проекте

8. контракты и поставки

5. Организовать эффективное выполнение проекта, включая:

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

2. организацию поставок и закупок различных ресурсов

3. распределение трудовых и материальных ресурсов для выполнения плана проекта

4. организацию процесса реализации проекта

6. Обеспечить эффективный контроль и оперативное регулирование хода работ:

1. по результатам

2. по срокам

3. по расходам

4. по качеству

5. по рискам

6. по контрактам и пр.

7. Организовать эффективное завершение и закрытие проекта.

23. Организация работ по проектированию ИС. Формы управления проектированием ИС. Планирование и контроль проектных работ.

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

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

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

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

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

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

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

- потенциал коллектива разработчиков;

- объем и сложность разрабатываемых проектов;

- технология проектирования системы;

- модель жизненного цикла системы.