Проект. Обсуждение целей и миссии

⇐ ПредыдущаяСтр 3 из 4Следующая ⇒

Что же такое проект? Все мы постоянно осуществляем проекты в своей повседневной жизни. Вот простые примеры: ремонт в квартире, стройка на даче, проведение исследований, написание книги. Само слово проект имеет греческие корни и означает — брошенный вперёд, выдающийся вперёд. В настоящее время проект определяется следующим образом:

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

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

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

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

Сущность миссии состоит в том, что она:

– отражает общие ценности и взгляды членов коллектива;

– связана с культурой организации;

– определяет направленность процесса принятия решений и работы;

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

Миссия отвечает на вопросы: кто?, что?, для кого? и как (каким образом)?

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

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

Методические рекомендации

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

После прохождения процедуры утверждения темы курсовой работы требуется провести следующие проектные мероприятия:

– разработать формулировку миссии;

– сформулировать главные цели проекта;

– зафиксировать границы проекта (что должно быть сделано, а чего делать не надо);

– произвести декомпозицию работ;

– оценить сроки деятельности, необходимые ресурсы.

– завести рабочую тетрадь проекта;

Выбор модели ЖЦ ПО

Жизненный цикл программного обеспечения — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

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

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

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

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

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

Каскадная модель характеризуется следующими основными особенностями:

– последовательным выполнением этапов проекта в строгом фиксированном порядке;

– началом последующего этапа только после завершения предыдущего;

– отсутствием обратных связей между этапами;

– получением результата только в конце разработки.

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

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

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

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

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

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

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

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

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

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

1. анализ отличительных категорий проекта, помещенных в таблицах ниже;

2. ответьте на вопросы, приведённые для каждой категории, обведя кружочком слова «да» или «нет»;

3. Расположите по степени важности категории или вопросы, относящиеся к каждой категории, относительно выбранного проекта;

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

Таблица 2 – Выбор модели жизненного цикла на основе характеристик требований

Требования	Каскадная	Прототипирование	Спиральная	Инкрементная
Являются ли требования легко определимыми и хорошо известными	Да	Нет	Нет	нет
Могут ли требования заранее определяться в цикле	Да	Нет	Нет	да
Часто ли будут изменяться требования в цикле	Нет	Да	Да	нет
Нужно ли демонстрировать требования с целью определения	Нет	Да	Да	нет
Требуется ли для демонстрации возможностей проверка концепции	Нет	Да	Да	нет
Будут ли требования отражать сложность системы	Нет	Да	Да	Да
Обладает ли требование функциональными свойствами на раннем этапе	Нет	Да	Да	Да

Таблица 3 – Выбор модели жизненного цикла на основе характеристик участников команды разработчиков

Команда разработчиков проекта	Каскадная	Прототипирование	Спиральная	Инкрементная
Являются ли проблемы предметной области проекта новыми для большинства разработчиков	Нет	Да	Да	Нет
Является ли технология предметной области проекта новой для большинства разработчиков	Да	Нет	Да	Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков	Да	Нет	Да	Нет
Изменяются ли роли участников проекта во время жизненного цикла	Нет	Да	Да	Да
Могут ли разработчики проекта пройти обучение	Нет	Нет	Нет	Да
Является ли структура более значимой для разработчиков чем гибкость	Да	Нет	Нет	Да
Будет ли менеджер проекта строго отслеживать прогресс команды	Да	Нет	Да	Да
Важна ли лёгкость распределения ресурсов	Да	Нет	Нет	Да
Приемлет ли команда равноправные обзоры и инспекции, менеджмент/обзоры заказчиков, а также стадии	Да	Да	Да	Да

Таблица 4 – Выбор модели жизненного цикла на основе характеристик коллектива пользователей

Коллектив	Каскадная	Прототипирование	Спиральная	Инкрементная
Будет ли присутствие пользователей ограничено в жизненном цикле	Да	Нет	Да	Да
Будут ли пользователи знакомы с определением системы	Нет	Да	Да	Да
Будут ли пользователи ознакомлены с проблемами предметной области	Нет	Да	Нет	Да
Будут ли пользователи вовлечены во все фазы жизненного цикла	Нет	Да	Нет	Нет
Будет ли заказчик отслеживать ход выполнения проекта	Нет	Да	Да	Нет

Таблица 5 – Выбор модели жизненного цикла но основе характеристик типа проектов и рисков

Тип проекта и риски	Каскадная	Прототипирование	Спиральная	Инкрементная
Будет ли проект идентифицировать новое направление продукта для организации	Нет	Да	Да	Да
Будет ли проект иметь тип системной интеграции	Нет	Да	Да	Да
Будет ли проект являться расширением существующей системы	Нет	Нет	Нет	Да
Будет ли финансирование проекта стабильным на всём протяжении жизненного цикла	Да	Да	Нет	Нет
Ожидается ли длительная эксплуатация продукта в организации	Да	Нет	Да	Да
Должна ли быть высокая степень надёжности	Нет	Нет	Да	Да
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения	Нет	Да	Да	Да
Является ли график ограниченным	Нет	Да	Да	Да
Являются ли «прозрачными» интерфейсные модули	Да	Нет	Нет	Да
Доступны ли повторно используемые компоненты	Нет	Да	Да	Нет
Являются ли достаточными ресурсы (время инструменты, персонал)	Нет	Да	Да	Нет

Методические рекомендации

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

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

2.5 Анализ требований и определение спецификаций ПО

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

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

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

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

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

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

Атрибуты качества при исполнении приложения:

– Доступность - требования ко времени непрерывной работы приложения, например, 24x7, минимальное время простоя и т.п.

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

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

– Масштабируемость - требования к горизонтальному или вертикальному масштабированию приложения.

– Требования к удобству использования приложения с точки зрения использования, поддержки.

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

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

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

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

Атрибуты качества при проектировании приложения:

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

– Требования к расширяемости приложения в связи с появлением новых функциональных требований.

– Требования к портируемости (переносимости) приложения на различные платформы.

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

– Требования к различным аспектам поддержки приложения, таким как дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе

– Требования к разделению приложения на модули.

– Требования к возможности автоматического и ручного тестирования приложения, наличие необходимого инструментария.

– Требования к возможности и простоте локализации приложения, перечень языков, на которые предполагается локализация приложения.

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

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

Процесс формирования и анализа требований проходит через ряд этапов:

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

2. Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

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

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

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

6. Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Когда группа разработчиков начинает анализировать требования, заказчик обычно всё ещё формирует концепции того, что он хочет и что ему нужно. Это аналогично этапу уточнения требований при взаимодействии архитектора и клиента. Например, клиент может захотеть дом с четырьмя спальнями и большой гостиной. Но при уточнении требований клиент вынужден полагаться на архитектора, который должен помочь клиенту понять, чего последний хочет (например, просторную гостиную, в которой можно разместить 10 человек). Нужды заказчика несколько труднее определить, чем его желания. Например, заказчик может захотеть, чтобы музыкальное приложение позволяло компьютерным новичкам гарантированно записывать музыку, но ему также может быть нужна периодическая функция автосохранения для избегания потери работы. Являются ли последняя характеристика требованием, или это часть проектирования? Это зависит от соглашения между разработчиком и заказчиком. Если заказчик, осознав смысл автосохранения, принимает решения, что он действительно хочет иметь такую функцию, автосохранение становится требованием.

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

– интервью, опросы, анкетирование;

– мозговой штурм, семинар;

– наблюдение за производственной деятельностью;

– анализ нормативной документации;

– анализ моделей деятельности;

– анализ конкурентных продуктов;

– анализ статистики использования предыдущих версий системы;

Рассмотрим один из способов проведения опроса заказчика

Перед интервью:

1. Перечислите и расставьте приоритеты в списке интервьюируемых.

2. Спланируйте интервью с фиксированным временем начала и конца;

– должны присутствовать как минимум два члена команды разработчиков;

– приготовьтесь записывать видео или аудио файлы.

Во время интервью:

1. Сконцентрируйтесь на слушании:

– не будьте пассивны: исследуйте сами и побуждайте собеседника;

– настаивайте на понимании желаний и изучении нужд;

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

– делайте подробные заметки;

Спланируйте следующую встречу

После интервью:

1. составить черновик требований;

2. связаться с заказчиком для получения его замечаний по документу;

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

Методические рекомендации

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

1. Введение

1.1 Цель (Цель документа в целом, а не цель ПО)

1.2 Область применения (Какие аспекты программы этот документ должен охватить)

1.3 Определения, термины и сокращения

1.4. Ссылки (исходные документы)

1.5 Обзор

2. Общее описание

2.1 Перспективы продукта

2.1.1 Концепции операций

2.1.2 Концепции пользовательского интерфейса

2.1.3 Аппаратные интерфейсы

2.1.4 Программные интерфейсы

2.1.5 Коммуникационные интерфейсы

2.1.6 Ограничения по памяти

2.1.7 Операции

2.1.8 Требования по адаптации

2.2 Функции продукта

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

2.4 Ограничения (все условия, которые могут ограничить возможности разработчика. Могут исходить из разных источников)

2.5 Предположения и зависимости (могут быть сделаны любые допущения)

2.6 Распределение требований

3 Детальные требования

3.1 Требования к внешнему интерфейсу

3.2 Детальные требования

3.3 Требования к производительности

3.4 Ограничения проектирования

3.5 Атрибуты программной среды

3.5.1 Надёжность

3.5.2 Доступность

3.5.3 Защита

3.5.4 Поддержка

3.6 Дополнительные требования

4 Дополнительная информация

4.1 Оглавление и индекс

4.2 Приложение

Планирование проекта

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

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

– Что должно быть сделано?

– Кто сделает?

– Как они это сделают?

– Как долго будут это делать? И т.д.

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

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

Календарный план – это план, в котором объёмы работы разбиты по срокам. Календарный план призван обеспечить осуществление проекта в рамках намеченного времени.

Обычный календарный план представляется в виде таблицы со следующей структурой:

Таблица 6 – Календарный план

Наименование работ (тема, работа, задача, задание)	Сроки выполнения начало/конец	Ответственный исполнитель и исполнители, роли	Требуемые ресурсы и сроки их предоставления план/факт	Примечания
план	факт

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

Сетевое планирование – набор методов, который предназначен для управления расписанием проекта. Его основной инструмент – сетевой график.Сетевой график – это ориентированный граф, в котором вершинами обозначены работы проекта, а дугами – временные взаимосвязи работ. Сетевой график позволяет:

– выявить перечень работ вашего проекта;

– наглядно представить порядок их следования;

– определить длительности каждой работы и всего проекта;

– определить критические работы проекта и его критический путь;

– определить резервы времени по каждой работе;

– и т.д.

В качестве примера рассмотрим проект " Разработка программного комплекса". Предположим, что проект состоит из работ, характеристики которых приведены в таблице 7.

Таблица 7 – Характеристики проекта

Номер работы	Название работы	Длительность	Зависимость
	Начало реализации проекта
	Постановка задачи
	Разработка интерфейса
	Разработка модулей обработки данных
	Разработка структуры базы данных
	Заполнение базы данных
	Отладка программного комплекса
	Тестирование и исправление ошибок
	Составление программной документации
	Завершение проекта

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

Нахождение критического пути сводится к нахождению критических работ и выполняется в два этапа.

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

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

Критические работы имеют одинаковое значение раннего и позднего времени начала.

Диаграмма Ганта – это инструмент иллюстрации календарного плана. Представляет собой столбчатые диаграммы, вписанные в календарную шкалу. Длина диаграммы соответствует отрезку времени, отведенному на выполнение той или иной задачи.

Рисунок 2 – Диаграмма Ганта

Впервые методика была представлена в 1910 году американским инженером Генри Гантом. В последствии диаграмма Ганта стала главным инструментом, применяемым при календарном планировании и контроле. В 1990-х годах методика была усовершенствована – для описания зависимостей между задачами были добавлены связи.

Типы связей:

– Финиш-Старт – операция B не может начаться до завершения операции А;

– Финиш-Финиш – операция B должна окончиться не раньше операции А;

– Старт-Старт – операция В начинается не раньше операции А;

– Старт-Финиш – операция В не может окончиться пока не начнется операция А.

Рисунок 3 – Типы связей

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

Таблица 8 – Исполнители этапов

Этап	Исполнитель
Т1 Т2 Т3 Т4 Т5 Т6 Т7 Т8 Т9 Т10 Т11 Т12	Джейн Анна Джейн Фред Мэри Анна Джим Фред Джейн Анна Фред Фред

Временная диаграмма распределения работников по этапам

⇐ Предыдущая 1 234 Следующая ⇒