Планирование и проектирование информационных систем

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

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

Виды деятельности при управлении проектами информационных Систем

Основные виды деятельности при  управлении проектом:

1. Измерение характеристик программной части системы и, не только характеристик средств, но и процессов их создания (процесс производства). Мы измеряем характеристики программного продукта, а, кроме того, параметры процессов разработки продуктов, при этом предполагается выбор определенной совокупности мер и метрик, состав которых становится стандартным для вставки в разные проекты и накапливания сведений из них.
2. Оценка трудоемкости и стоимости проекта, сбор и анализ данных о созданном проекте.
3. Анализ рисков, которые оказывают влияние на выполнение проекта и разработка комплекса мероприятий по их уменьшению и преодолению.
4. Планирования работ
5. Контроль за выполнением работ и документирование случаев нарушения планов.
1. Измерение характеристик программной части системы – дает возможность управленцу и практическому работнику лучше понять процесс разработки систем и сам продукт, который он создает. При этом используются прямые и косвенные метрики, которые позволяют охарактеризовать качество создаваемых продуктов, производительность труда, т.е. получить данные необходимые для планирования проекта и контроля за его выполнением. Для целей планирования и получения оценок для нового проекта, как мы знаем, нужны исторические данные по разработке прошлого проекта. На основе этих данных формируется т.н. базовая линия, относительно которой ведется потом оценка того – происходит ли уменьшение качества, повышается ли производительность.

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

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

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

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

3. Анализ рисков - это главное в хорошем управлении. Многие проекты информационных систем гибнут, если не учитывались все аспекты риска (технический, экономический, социальный, коммерческий, выборочный и т.д. мы будем их потом рассматривать) и если небело уделено внимание анализу возможных источников риска. Анализ риска – серия шагов, направленных на уменьшение и «разрушение» риска. Эти шаги:

1. идентификация риска, т.е. составление списка возможных рисков.
2. оценка каждого риска, его вероятности, области воздействия, времени проявления и т.д.
3. установление приоритетов во всем этом списке рисков.
4. выбор стратегии управления рисками. Это целый перечень мероприятий – составляется список борьбы с риском. Под одним из серьезнейших рисков при выполнении проектов раньше на него обращали внимание, включали партийные организации, подключали райкомы партий, это текучесть кадров. Риск «уход ведущего сотрудника» - это скандал, может провалиться проект, т.к. человек владеет информацией, основными идеями разработки системы и т.д.
5. Разрешение проблемы риска. С примером текучести кадров – надо ему либо зарплату повышать, либо иметь всегда резервных сотрудников… это палка о двух концах – на ликвидацию того или иного риска затрачиваются средства, и спрашивается что лучше – затратить средства или остановить проект.
6. мониторинг риска – постоянное слежение за состоянием тех рискованных моментов, которые могут где-то проявиться.

4. Составление графика работ – ключевой момент управления в управленческой деятельности (оценка ресурсов, времени необходимых для выполнения работ). Основным подходом и к оценке трудоемкости сроков выполнения и к процессу планирования является представления проекта в виде отдельных задач или работ. Это составление последовательности и взаимосвязи работ – главное в составлении плана. Эта последовательность и взаимосвязи начинаются с самого крупного, т.е. с жизненного цикла. Чем хороши стандарты – они уже определяют состав и последовательность основных фаз, этапов работ, содержание этих работ, чем каждая работа должна заканчиваться… по каждой работ есть какие-то оценки, мы можем исходя из аналогии, экспертно оценивать, сколько, что потребует времени, кому это можно поручить, в какой последовательности это должно выполняться. При этом используют методы аналогии экспертных оценок и функциональной декомпозиции.  Кстати, очень сложна эта функциональная декомпозиция в курсовом проекте, как это ни странно, т.к. просто выделение отдельных функциональных подсистем в вашей системе всегда вызывает сложность.

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

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

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

5. Контроль за выполнением плана – после того как план разработан, имеется сетевой график, который потом будет является основой, начинается деятельность по слежению и контролем за выполнением каждой задачи проекта. При нарушении графика производится перераспределение ресурса. Наличие такого графика позволяет эффективно контролировать работу исполнителей, но опять же, вы должны иметь в виду, вот промежуточные цепи задачи … всегда можно сказать, что задача уже выполнена и произведено тестирование, но насколько оно качественно, насколько всеобъемлюще, на сколько оно действительно завершено…. Во всех этих работах очень сложно говорить о завершении той или иной задачи. Вот «он» говорит – «да, алгоритм я уже разработал», а программист садится и начинает программировать, и оказывается алгоритм в самых узких места совсем не продуман и не известно как решать. А там вроде и блок-схема нарисована и описано все и задание на программирование уже дано. Это особенности этой нашей такой работы…  да.. все сделано, начинает работать, а какие-то запросы, какого-то типа справки не могут быть получены т.к. что-то не учтено и приходится рутинно заново возвращаться к началу – не учтены такие-то требования пользователя, ему нужны такие-то такие-то материалы получать, а их нельзя получить на этой базе, хотя все уже создано.

Аналитик  как менеджер проекта информационной системы.

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

1. пользователи уже не удовлетворены с предыдущими разработками и с этим приходится считаться, т.е. они «обжигались» на чем-то предыдущем и работать с ними довольно сложно.
2. при разработке новой информационной системы методы управления проектом организационная структура, которая уже существует, может оказаться не адекватной. Может потребоваться другая организация и другие способы управления.
3. Менеджер сталкивается с тем, что штат разработчиков не обладает соответствующим профессиональным уровнем. Это самое трудное, казалось бы, у людей есть профессиональные знания и опыт работы, но есть способные, талантливые, которые могут заменить десяток хороших работников. Талантливый этот тот, который может из ряда альтернатив найти наилучшее решение. Это как в стрельбе – обычный человек долго тренируется, но все равно выбивает 80 из 100, а талантливый всегда выбивает в десятку! А гений стреляет в такие цели, которые другим не видны J )). В общем, штат работников может оказаться не с соответствующим профессиональным уровнем.
4. механизмы планирования могут быть неудовлетворительными. С этим многие сталкиваются, но кроме этого существуют проблемы более серьезные стратегического уровня, прежде всего это проблемы обусловленные появлением новых информационных технологий. Их возможно, будущим влиянием на разработку проекта. Слишком динамична наша область, и нужно чувствовать, что если проект разрабатывается достаточно долго, то может оказаться что он не очень уж отвечает современному состоянию. Нужно всегда быть на уровне самых передовых идей и технологических достижений. У менеджера появляется необходимость оценки возможного применения и внедрения новых технологий – это всегда чревато большим риском. Ну, как вы видите, много говорят о базах знаний, интеллектуальных системах, системах принятия решений а, в общем-то, мы всегда сталкиваемся пока с информационными системами, называемыми АСУ. Как правило, они оказываются достаточно мало функциональными системами, т.е. это локальные системами и автоматизируют какие-то отдельные функции, хотя мы говорили о корпоративных интегрированных системах, но, в общем-то, существуют международные стандарты таких систем (мы о них говорили ERP.. и др.) но примеров таких систем вы особенно не найдете. Такого всеобъемлющего грамотного комплексного построения таких систем, т.е. если менеджер возьмет на себя смелость сделать такую систему он возьмет на себя большой риск.

Рекомендации  для менеджера по вводу в организацию  новых информационных систем и технологий (что надо учитывать):

1. планирование разработки новой системы – вновь разрабатываемые информационные системы оказывают влияние на людей не только после их разработки, но даже во время их создания. Чтобы к этим новым системам люди относились положительно и вложили в создание усилия необходимо:
1. установить коммуникационные каналы, т.е. четко идентифицировать какие люди будут затронуты изменениями в организации, которые связаны с внедрением новой системы и, решить, какая информация нужна этим людям и как ее представить.
2. Решить (спланировать) стратегию проектирования, т.е. установить пользователей которые должны вносить вклад в разработку проекта и определить степень этого вклада. А также установить каналы обеспечения этого вклада.
3. Необходимо планировать переход к новой информационной системе, чтобы потом минимизировать все возможные отклонения от плана. Установить, для этого, как много времени будет затрачено на управленческую деятельность, связанную с контролем, т.е. когда планирует – он планирует не управленческую свою деятельность, а сколько потребуется на установку оборудования, обучение персонала, консультации, запуск новой системы параллельно со старой. Это планирование разработки новой системы и много можно пропустить, а менеджер должен всесторонне рассматривать эту проблему.
2. Анализ системы – при создании новой системы надо исследовать потенциальных пользователей, перечислить всех пользователей системы, включая неявных (например, аудиторы). Этот список необходим, чтобы учесть все их требования к новой системе. Также надо предусмотреть непривлекательные виды работ.  Рассмотреть все случаи неформальной деятельности. Кроме того, должен быть учтен даже жаргон, которым пользуются разработчики.

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

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