Етапи прийняття критеріїв значимості

Питання на модульний контроль №1 з дисципліни “Менеджмент проектів ПЗ” ТУРКО 1. Програмне забезпечення для управління проектами Microsoft Project. 2. Програмне забезпечення для управління проектами Oracle Primavera. 3. Програмне забезпечення для управління проектами Spider Project. 4. Наведіть програмне забезпечення для управління проектами і дайте опис деякого з них. 5. Суть методу мережевого планування проектів. 6. Структурне планування. 7. Що таке критичний шлях. Зобразіть його графічно на графі. 1.Microsoft Project — система управління проектами, розроблена корпорацією Microsoft. Microsoft Project створений, щоб допомогти менеджерові проекту в розробці планів, розподілі ресурсів за завданнями, відстежуванні прогресу і аналізі обсягів робіт. Microsoft Project створює розклади критичного шляху. Розклади можуть бути складені з урахуванням використовуваних ресурсів. Ланцюжок візуалізується в діаграмі Ганта. Для користувачів Microsoft Project в СНД компанія Microsoft за підтримки своїх партнерів створила портал MicrosoftProject.ru на якому публікуються останні матеріали щодо продукту і рейтинг розробників. Восени очікується вихід нової версії Microsoft Project 2013 та Microsoft Project Server 2013. Також на ринку з'явиться новий продукт Microsoft Project Online, який буде представлено у пакеті Office 365. В Microsoft Office 2007 можливості Microsoft Project були розширені введенням Microsoft Office Project Server та Microsoft Project Web Access. Project Server зберігає дані Project в центральній SQL-базі даних, і дозволяє користувачам переглядати та оновлювати черезінтернет. Web Access дозволяє авторизованим користувачам мати доступ до бази даних Project Server через інтернет, і включає розклади, графічні аналізи зайнятості ресурсів, і адміністративні інструменти. Microsoft Office Project Server 2007 тісно інтегрований з Windows SharePoint Services, для кожного проекту створюється Project Workspace, де команда розробників може спільно ділити інформацію з Project. Застосунок функціонує як частина пакету Microsoft Office, останні версії також забезпечують взаємодію з застосунками типу PowerPoint таVisio. 7. Критичний шлях управління проектом (англ. Critical Chain Project Management - CCPM) — це метод планування та управління проектами, який на перше місце ставить управління ресурсами (фізичними та людськими), необхідними для виконання завдань проекту. Фактично це доповнення Теорії обмежень (англ. Theory of Constraints - TOC) для проектів. Головним завданням є підвищення продуктивності (або збільшення відсотку завершених завдань) проектів в організації. Застосовуючи перші три з п'яти основних кроків TOC, системні обмеження для всіх проектів визначаються як ресурси. Щоб використовувати обмеження, завдання на критичному шляху отримують пріоритет вищий ніж інші активності. Загалом, проекти плануються та управляються таким чином, щоб ресурси були доступні, коли завдання критичного шляху мають розпочатися, підпорядковуючи усі інші ресурси завданням критичного шляху. Незважаючи на тип проекту, план проекту має визначати розподілення ресурсів на рівні (англ. Resource Leveling). Найдовша послідовність ресурсно-обмежених завдань має бути визначена, як критичний шлях. В середовищах, що мають декілька проектів, розподілення ресурсів на рівні використовується в усіх проектах. Часто, досить визначити (чи просто обрати) один наскрізний ресурс — ресурс, що виступає як обмеження в усіх проектах та послідовно розташувати проекти відповідно до доступності цього ресурсу.   Метод критичного шляху є основним для розрахунку ранніх та пізніх початків та закінчень робіт та резервів часу. Календарний план як перелік тільки планових параметрів проектних робіт втрачає свій сенс без порівняння з фактичними термінами виконання, тому частіше говорять про календарний графік. Він відбиває планові та фактичні дані про початок, кінець і тривалість кожного робочого елементу. 6. Структурне планування – розбиття програми на чітко визначені операції, визначення оцінки тривалості операцій та взаємозв’язок між операціями. В результаті структурного планування будується мережевий графік (мережева модель). 5. Мережеве планування - це одна з форм графічного відображення змісту робіт і тривалості виконання стратегічних планів і довгострокових комплексів проектних, планових, організаційних та інших видів діяльності підприємства. Поряд з лінійними графіками та табличними розрахунками мережеві методи планування знаходять широке застосування при розробці перспективних планів та моделей створення складних виробничих систем та інших об'єктів довгострокового використання. Мережеві плани робіт підприємств по створенню нової конкурентноздатної продукції містять не тільки загальну тривалість всього комплексу проектно-виробничої та фінансово-економічної діяльності, але й тривалість та послідовність здійснення окремих процесів чи етапів, а також потреба необхідних економічних ресурсів. Вперше плани-графіки виконання виробничих процесів були застосовані на американських фірмах . На лінійних або стрічкових графіках по горизонтальній осі в обраному масштабі часу відкладається тривалість робіт за всіма стадіями, етапами виробництва. Зміст циклів робіт зображується по вертикальній осі з необхідним ступенем їх розчленування на окремі частини або елементи. циклові або лінійні графіки звичайно застосовуються на вітчизняних підприємствах у процесі короткострокового чи оперативного планування виробничої діяльності. Основним недоліком таких планів-графіків є відсутність можливості тісної взаємоув'язки окремих робіт в єдину виробничу систему або загальний процес досягнення запланованих кінцевих цілей підприємства (фірми).Мережеві графіки служать не тільки для планування різноманітних довгострокових робіт, але і їх координації між керівниками та виконавцями проектів, а також для визначення необхідних виробничих ресурсів та їх раціонального використання.

Spider Project (Спайдер Проджект) — пакет з управління проектами, спроектований та розроблений російським розробником компанією «Спайдер Проджект» Технічні характеристики Spider Project

§ Необмежена кількість операцій;

§ Необмежена кількість ресурсів;

§ Необмежена кількість календарів;

§ Будь-яка кількість ієрархічних структур робіт в кожному проекті;

§ Будь-яка кількість ієрархічних структур ресурсів в кожному проекті;

§ Будь-яка кількість ієрархічних рівнів в кожній з ієрархічних структур;

§ Будь-яка кількість статей прибутків і видатків;

§ Будь-яка кількість центрів витрат і матеріалів;

§ Будь-яка кількість версій проекту і можливість порівнювати поточну версію проекту з будь-якою іншою версією і проектом;

§ Оптимізація розкладу виконання робіт за обмежених ресурсів, за заданих графіках постачань і фінансування;

§ Мультіпроектне управління;

§ Вартісний аналіз за методикою NASA (Earned Value Analysis);

§ Можливість порівняння між собою будь-яких двох версій проекту;

§ Будь-яка кількість базових версій;

§ Діаграми Гантта для робіт і ресурсів;

§ Гістограми завантаження ресурсів;

§ Графіки витрат і потреби в матеріалах;

§ Побудова графіків і гістограм за будь-якими показниками звітів;

§ Моделювання як видатків, так і прибутків;

§ Моделювання постачань і витрат матеріалів;

§ Моделювання виробництва ресурсів;

§ Складання розкладу виходячи з обсягів робіт, кваліфікації та продуктивності ресурсів;

§ Три види мережевих діаграм;

§ Організаційні діаграми для представлення ієрархій робіт і ресурсів;

§ Плавне масштабування діаграм;

§ Табличні та графічні звіти;

§ Вбудована система обліку.

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

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

Primavera предоставляет своим пользователям следующие возможности:

§ Выбор нужного сочетания стратегических проектов.

§ Обеспечение корпоративного управления проекта.

§ Улучшение процессов и методов.

§ Улучшение совместной работы проекта.

§ Измерение прогресса в достижении целей.

§ Связь проектов со стратегией.

Spider Project – нацеленность на успех

 

В.И.Либерзон, PMP

 

 

Система управления проектами Spider Project разрабатывалась на основании богатого опыта управления проектами в России и отличается от всего, что предлагается западными поставщиками. Система поддерживает традиционные подходы к управлению проектами, описанные в PMBOK Guideâ и реализованные в большинстве западных пакетов, но при этом предлагает и много такого, что не имеет аналогов ни в теории, ни в практике управления проектами на Западе. Поэтому голое описание технических характеристик не будет достаточным для понимания отличий этого пакета от конкурентов, и мы остановимся особо на тех особенностях пакета, которые имеют отношение к предлагаемой методологии управления проектами с использованием Spider Project. Отличительной чертой этой методологии является управление вероятностью успешной реализации проектов с учетом всех ограничений, рисков и неопределенностей, с которыми приходится сталкиваться менеджерам проектов. Особое внимание в пакете уделяется моделированию работы и управлению ресурсами проекта

 

Технические характеристики

 

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

·      Неограниченное количество операций,

·      Неограниченное количество ресурсов,

·      Неограниченное количество календарей,

·      Неограниченное количество иерархических структур работ в каждом проекте,

·      Неограниченное количество иерархических структур ресурсов в каждом проекте,

·      Неограниченное количество иерархических уровней в каждой из иерархических структур,

·      Неограниченное количество статей затрат,

·      Неограниченное количество центров затрат, ресурсов и материалов,

·      Моделирование как расходов, так и доходов,

·      Моделирование как расхода, так и производства ресурсов,

·      Корректное моделирование неполной загрузки ресурсов,

·      Моделирование независимых назначений ресурсов и сменной работы,

·      Моделирование переменной загрузки ресурсов на работах проекта,

·      Составление расписания исходя из объемов работ, квалификации и производительности ресурсов,

·      Оптимизация расписания исполнения работ при ограниченных ресурсах с учетом графиков производства, поставок и финансирования,

·      Средства для стабилизации расписания,

·      Определение ресурсного критического пути (Critical Chain),

·      Определение резервов времени на исполнение операций с учетом ограниченности ресурсов проекта,

·      Неограниченное количество проектных баз данных (справочников),

·      Использование библиотеки типовых фрагментов,

·      Встроенный анализ рисков,

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

·      Подсчет текущей вероятности успешного исполнения директивных параметров проекта,

·      Стоимостной анализ по методике Earned Value Analysis,

·      Неограниченное количество версий проекта,

·      Ведение архивов проектов,

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

·      Встроенная система учета,

·      Мультипроектное управление и групповая работа с проектами,

·      Неограниченное количество пользовательских полей,

·      Пользовательские формулы, связывающие показатели проекта,

·      Произвольные фильтры,

·      Диаграммы Гантта для работ и ресурсов,

·      Гистограммы загрузки ресурсов,

·      Графики затрат, cash flow и движения материалов,

·      Три вида сетевых диаграмм,

·      Организационные диаграммы для представления иерархий работ и ресурсов,

·      Линейные диаграммы,

·      Плавное масштабирование диаграмм,

·      Табличные и графические отчеты как по плану, так и по исполнению проекта,

·      Экспорт и импорт информации в SQL базы (Oracle, Access и т.п.), Lotus Notes, программы MS Office, Html и текст,

·      Импорт проектов и информации из сметных строительных программ,

·      Групповая работа через Интернет.

Как видите, жирным шрифтом выделено довольно много, поэтому обо всем придется упомянуть очень коротко.

 

2. Особенности пакета

 

2.1. Множественные иерархические структуры работ.

 

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

ИСР по объектам получается, если результат проекта на верхнем уровне иерархии разбивается на результаты по отдельным объектам проекта, а затем по процессам (например, проектирование, реализация, и т.д.).

ИСР по процессам на верхнем уровне использует процессы, а на более низких – объекты проекта.

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

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

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

 

2.1. Множественные иерархические структуры ресурсов.

 

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

 

2.3. Статьи затрат и центры стоимостей, ресурсов и материалов

 

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

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

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

 

2.3. Моделирование доходов и производства

 

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

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

 

2.4. Моделирование работы ресурсов

 

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

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

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

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

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

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

       Удобные инструменты для управления назначениями ресурсов открывают имеющиеся в пакете возможности назначения на операции мультиресурсов. Мультиресурс – это устойчивая группа вместе работающих ресурсов (например, бригада). Во-первых, назначая мультиресурс, пользователь назначает все входящие в него ресурсы, то есть облегчает свою работу. Но более интересно то, что в любой момент можно изменить состав мультиресурса и распространить эти изменения на все его назначения. Такая возможность облегчает анализ «что если», позволяя эффективно подбирать и изменять составы назначенных бригад.

 

2.5. Особенности расчета расписания исполнения проекта

 

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

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

 

2.6. Ресурсный критический путь

 

       Важной особенностью пакета является вычисление ресурсного критического пути, то есть тех операций проекта, задержка исполнения которых приводит к задержке завершения проекта с учетом имеющихся ограничений на ресурсы проекта. Ресурсный критический путь пакет вычисляет с самой первой своей версии, которая была выпущена еще в конце 1992 года. Теперь и мир пришел к тому, что это важно, но тем не менее Spider Project пока остается единственным пакетом, который умеет это делать. Нашумевшая Критическая цепь (Critical Chain), о которой написал Голдратт в одноименной книге и которая сейчас широко обсуждается мировым сообществом менеджеров проекта, есть не что иное, как ресурсный критический путь. Практически все, что предлагается в теории Критической цепи, давно реализовано в пакете Spider Project.

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

       На рис. 1 проиллюстрировано понятие ресурсного критического пути и резервов времени на исполнение операций. В проекте РКП на операции 2 и 4 назначен ресурс А, который имеется в одном экземпляре, а потому они не могут исполняться параллельно. Исполнение операций 1 и 5 может быть отложено до моментов, показанных на диаграмме полыми полосками.

       Ресурсный критический путь – операции 3, 4 и 2.

 

2.7. Поддержка корпоративных стандартов

 

       Spider Project изначально спроектирован таким образом, чтобы поддерживать корпоративные стандарты управления проектами. Для этого в пакете предусмотрена возможность создания непосредственно в пакете библиотек типовых фрагментов проектов, а также всевозможных баз данных, включая производительности ресурсов на типовых назначениях, объемы и длительности типовых операций, расход материалов и расценки на единичных объемах типовых операций и назначений и т.д. Пользователи могут создать (или импортировать из стандартных SQL баз, таких как Oracle, Access и т.д.) и любые другие базы данных и использовать их во всех проектах компании.

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

 

2.8. Анализ рисков и технология управления Spider Project

 

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

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

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

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

Нацеленность на успех – отличительная черта методологии управления Spider Project.

 

2.9. Ведение архивов проекта, анализ отклонений

 

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

 

2.10. Система учета

 

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

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

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

 

2.11. Особенности групповой работы

 

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

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

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

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

 

2.12. Отчетность

 

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

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

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

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

           

Рис.2. Линейная диаграмма для некоторых работ строительства Каспийского трубопровода.

 

Пример линейной диаграммы (4-й поток строительства Каспийского трубопровода) представлен на рис.2.

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

 

3. Историческая справка

 

       Первая версия пакета Spider Project была выпущена в конце 1992 года. Поскольку в тот момент в нашей стране мало кто знал о том, что такое Управление проектами, версия была англоязычной. В 1993 году она демонстрировалась на выставках в Лейпциге и Мюнхене и заслужила весьма лестные отзывы благодаря алгоритмам оптимизации расписаний при ограниченных ресурсах проекта. Первыми пользователями пакета были немцы, финны и англичане.

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

       Большую роль в распространении информации о пакете и росте его популярности сыграло его успешное использование для управления строительством Олимпийской деревни для Всемирных Юношеских Игр 1998 года. Стройка была очень крупной, была провозглашена важнейшей стройкой года Московским Правительством, и соблюдение сроков строительства и координация работы многочисленных подрядчиков было очень важной задачей. На стройке преимущества использования пакета были столь наглядно продемонстрированы, что Spider Project стал быстро распространяться по строительным организациям и даже заслужил репутацию пакета для управления строительством, несмотря на свою универсальность. До сих пор разработчики пакета получают заявки на «пакет управления монолитным домостроением», хотя пакет с успехом применяется не только в строительстве, но и в оборонных, информационных, телекоммуникационных, нефтегазовых, судостроительных, консалтинговых и иных проектах. На ряде предприятий Spider Project используется в качестве корпоративной системы управления проектами.

       Для удовлетворения спроса на систему со стороны различных групп пользователей кроме профессиональной системы предлагаются более дешевые версии Desktop и Lite. Версия Desktop – однопользовательский вариант профессиональной системы, а в версии Lite функциональные возможности пакета ограничены, и пакет более напоминает западные системы управления проектами. Подробнее об особенностях различных версий пакета и их стоимости вы можете узнать на сайте www.spiderproject.ru. Там же можно скачать рабочие Демо версии Spider Project Professional и Spider Project Lite, Руководство по работе с пакетом, а также различные статьи и презентации на тему управления проектами.

 

ВАСИЛЬКОВ

8. Суть прямого проходу при плануванні проекту.

Прямий прохід

а рекурсивно розраховується наступним чином:

Початкова умова: якщо на кожному кроці не проводилася

нормалізація, буде розраховуватися Втім, ця спільна

ймовірність стрімко зменшується із ростом і. Одним із рішень може стати
логарифмування. Іншим - нормалізація, тобто розрахунок

сума яких завжди дорівнює одиниці. Це не лише

запобігає появі занадто малих значень, а і дає можливість отримати набагато більш значуще число (наближення фільтрованого стану). Відслідковуються нормалізовані константи і таким чином можна обчислити ймовірність послідовності:

9. Суть зворотного проходу при плануванні проекту.

 обчислюються рекурсивно наступним чином. Початкова умова

Рекурсивний крок має вигляд

 

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

10. Ролі в колективі розробників.

Для цілеспрямованого виконання проекту працівниками має бути виконаний ряд робіт, різних як по своєму призначенню, так і по кваліфікаційних вимогах, що

пред'являються до розробників. Іншими словами, в ході розвитку проекту командою розробників виконуються ті або інші функції. Розподіл функцій між виконавцями є нічим іншим як розподілом ролей в команді, що виконує проект.  Зрозуміло, що значущість ролей розробників і тих, хто з ними пов'язаний,

розрізняється залежно від того, який проект виконує команда програміста. Проте, можна вказати на ряд найбільш типових ролей, ігнорування яких приводить кращому випадку до втрат продуктивності праці команди в цілому, а в найгіршому - до краху проекту. Як досить повний перелік ролей можна вказати на наступний список, запропонований в рамках підходу Центру об'єктно-орієнтованої технології фірми IBM

11. Функціональна роль Замовника (Customer) в колективі розробників.

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

результати (як поточні, так і остаточні) розробки, виконаної роботи;

 

12. Функціональна роль Планувальника ресурсів (Planner) в колективі розробників.

.Планувальник ресурсів (Planner) - висуває і координує вимоги до проектів в організації,  що здійснює цю розробку, а також розвиває і направляє план виконання проекту з точки зору організації;

13. Функціональна роль Менеджера проекту (Project Manager) в колективі розробників.

Менеджер проекту (Project Manager) - відповідає за розвиток проекту загалом,  гарантує, що розподіл завдань і ресурсів дозволяє виконати проект, що роботи і

пред’явлення результатів йдуть за графіком, що результати відповідають вимогам. В рамках цих функцій менеджер проекту взаємодіє із замовником і планувальником

ресурсів;

 

14. Функціональна роль керівника команди (Team Leader) в колективі розробників.

Керівник команди (Team Leader) – виконує технічне керівництво командою в процесі виконання проекту. Для великих проектів можливе залучення декількох керівників підкоманд, що відповідають за рішення окремих задач;

ГОС

15. Функціональна роль архітектора (Architect) в колективі розробників.

. Архітектор (Architect) - відповідає за проектування архітектури системи, погоджує розвиток робіт, пов'язаних з проектом;

16. Функціональна роль проектувальника підсистеми (Designer) в колективі розробникі

Проектувальник підсистеми (Designer) - відповідає за проектування підсистеми або категорії класів, визначає реалізацію і інтерфейси з іншими підсистемами;

 

17. Функціональна роль експерта предметної області (Domain Expert) в колективі розробників.

Експерт предметної області (Domain Expert) - вивчає сферу програмного продукту, що розробляється, (розроблювального ПЗ), підтримує спрямованість проекту на рішення задач цієї області;

18. Функціональна роль розробника (Developer) в колективі розробників.

Розробник (Developer) - реалізує проектовані компоненти, розробляє специфічні класи і методи, здійснює кодування і автономне тестування, створює програмний продукт. Це широкий термін, який може підрозділятися на вужчі ролі (наприклад, розробник класів). Залежно від складності проекту команда може включати різну кількість розробників;

 

19. Функціональна роль розробника інформаційної підтримки (Information Developer) в колективі розробників.

 Розробник інформаційної підтримки (Information Developer) - створює документацію, супроводжуючу продукт, коли випускається його версія. Інсталяційні матеріали, що включаються в неї, як зсилки так навчальну літературу, а також матеріали допомоги, які надаються на паперових і електронних носіях. Для складних проектів можливий розподіл цих завдань між декількома розробниками інформаційної підтримки;

20. Функціональна роль спеціаліста по користувацькому інтерфейсу (Human Factors Engineer) в колективі розробників.

. Фахівець з призначеного для користувача інтерфейсу (Human Factors Engineer) - відповідає за зручність застосування системи. Працює із замовником, щоб упевнитися, що призначений для користувача інтерфейс задовольняє вимогам;

 

21. Функціональна роль тестувальника (Tester) в колективі розробників.

Тестувальник (Tester) - перевіряє функціональність, якість і ефективність продукту. Будує і виконує тести для кожної фази розвитку проекту;

 

Я

22. Функціональна роль біблотекаря (Librarian) в колективі розробників.

Для цілеспрямованого виконання проекту працівниками має бути виконаний ряд робіт, різних як по своєму призначенню, так і по кваліфікаційних вимогах, що пред'являються до розробників. Іншими словами, в ході розвитку проекту командою розробників виконуються ті або інші функції. Розподіл функцій між виконавцями є нічим іншим як розподілом ролей в команді, що виконує проект. Бібліотекар (Librarian) - відповідає за створення і ведення загальної бібліотеки проекту, яка містить усі проектні робочі продукти. Він також відповідає за відповідність робочих продуктів стандартам.

 

23. Життєвий цикл програмного продукту.

    Функції, що виконуються розробниками проекту, в ході його розвитку зазнають зміни, як, в іншому, і сам проект. Спочатку він існує у вигляді заявки на розробку, потім - як функціональні і технічні вимоги, далі - як специфікації виробу, що розробляється, набір програмних модулів, скомпонованная з модулів система і так далі. Цей перелік можна розглядати як один з прикладів моделі життєвого циклу програмного виробу, тобто

представлення еволюції розробки і наступного використання програмної системи. Поняття життєвого циклу займає центральне місце в технології програмування, утворюючи базу для природної систематизації інструментів і методів, ресурсів і результатів на різних етапах розробки і використання програмних систем. Поняття це не є специфічним для програмування. Воно виникло і розвивалося спочатку стосовно технічних систем.      Зокрема, ще нещодавно наші економісти виражали своє занепокоєння з приводу того, що зарубіжний споживач порівняно дешевими радянськими тракторами віддає перевагу над канадським, ціна яких у декілька разів більше. Виявилось, що повна вартість останніх з урахуванням витрат усього "життєвого циклу існування машин" (включаючи їх технічне обслуговування і ремонт) виходить кінець кінцем у декілька разів менше. Не випадково питання  технологічності не лише з точки зору виготовлення, але і наступній експлуатації, має в техніці первинне значення. Потреба в цьому понятті виникла у зв'язку з перетворенням технології програмування на інженерну дисципліну, спочатку у вигляді поняття цикл розробки. Проте зростання розуміння, що вартість програмного забезпечення включає витрати протягом усього часу життя системи, а не тільки витрати на розробку або виконання програм  привів до природної трансформації початкового поняття циклу розробки.

Життєвий цикл - це проекція призначеного для користувача поняття “Час життя” на поняття розробника  технологічний цикл (цикл розробки)”. Комбінацією цих термінів пояснюється, мабуть, походження самого терміну “життєвий цикл програмного забезпечення”.

24. Життєвий цикл в об’єктно-орієнтованому проектуванні.

 

    Існують різні підходи до моделювання життєвого циклу програмного виробу, що відбивають ті або інші аспекти розробки програм і пов'язаної з нею діяльності. При об'єктно-орієнтованому підході до проектування проголошується принцип зворотно-поступального розвитку, або ітеративного нарощування системи, суть якого

полягає в наступному. На кожній фазі проекту будуються працездатні продукти, що розвиваються надалі шляхом збагачення функціональності і інтерфейсу, а не в жорстких рамках попереднього технічного опису в цілому, яке будується в ході спеціального етапу конструювання, що передбачається в традиційних схемах. Як наслідок, традиційні фази розвитку проекту в ході окремої ітерації виявляються незавершеними, вони доповнюються (нарощуються) на наступних ітераціях. Цей принцип багато в чому трансформує поняття життєвого циклу : якщо раніше продукт-виріб вироблявся лише до кінця періоду розробки, то тепер на кожній ітерації з'являються відносно закінчені робочі продукти. Також трансформується поняття документації : замість Технічного опису, що з'являється як підсумок конструювання, розробляється Робочий опис, що доповнюється на кожній ітерації. В таблиці. 1.1 приводиться зіставлення особливостей традиційних і об'єктно-орієнтованих схем життєвого циклу.

    Поза сумнівом, об'єктно-орієнтований підхід представляється привабливішим, ніж традиційні технології. Виражена эволюционность розвитку проекту, коли кожна фаза сама по собі дає корисні результати, хороші можливості для використання програмного забезпечення, відчутний прогрес в частині підтримки узгодженого розподілу робіт виконавців - ось явні переваги цього підходу. Проте, новий підхід не позбавляє розробників від рішення традиційних завдань, сформульованих в ході розвитку технологій послідовного проектування. Він лише полегшує їх рішення за рахунок розподілу в часі. Тому доцільно приділити систематичному вивченню моделей життєвого циклу особливу увагу. Це наступна тема справжнього курсу. Особливості традиційних і об'єктно-орієнтованих схем життєвого циклу розробки програмного виробу.

Традиційні схеми	Об 'єктно-орієнтована схема
Повністю завершені фази проектування і програмування	Ітеративно нарощувані можливості Традиційні фази розподіляються по ітераціях
Продукт у кінці періоду розробки	Робочі продукти на кожній ітерації
Технічний опис як підсумок конструювання	Робочий опис, що доповнюється на кожній ітерації
Послідовна розробка	Зворотно-поступальна розробка
Модулі дій, операцій	Ієрархії класів об'єктів
Структурна, покрокова деталізація!	С’падковістьо, перевизначення. поліморфізм

 

25. Заявка на проект.

Для освітлення вказаних тільки що аспектів перед замовником доцільно розробити

спеціальний документ, що іменується надалі як "Заявка на проект". Залежно від ситуації

назва документу може бути іншою ("Пропозиція розробки", "Заявка на грант" та ін.), але у

будь-якому випадку від менеджера вимагається скласти документ, який:

точно визначає, що ви маєте намір зробити для замовника. Зокрема, повинно бути

чітко виділено, що конкретно ви збираєтеся виробляти для нього;

переконує замовника, що ваша пропозиція розробки задовольнить його потреби

краще, ніж те, що в змозі запропонувати інші компанії;

описує для замовника, як ви маєте намір здійснювати свій задум, включаючи ті деталі,

які доводять, що ви добре розумієте проблеми проекту;

створює у замовника абсолютну впевненість в тому, що ви маєте достатні можливості

для отримання заявлених результатів;

включає повну інформацію, яка потрібна для фінансування проекту, запропонованого

вам.

Інша сторона обговорення документу - це те, якою мірою він повинен відповідати реальності. Слід сказати, що отримання замовлення завжди демонструє унікальність ситуації. Проте, може бути виділені декілька типів замовлень виходячи з процедури їх отримання. В першу чергу, слід вказати на підрозділ

замовлень на конкурсні і цільові замовлення. Для замовлень першого виду характерною є конкретність постановки завдання розробки і вибір виконавців проекту серед конкуруючих претендентів. Для цільового замовлення завдання розробки може варіюватися в певних межах, а місце вільної конкуренції виконавців займає робота по уточненню проекту з однією фірмою або послідовна взаємодія з рядом виконавців з відмовою від тих, хто по певних або невідомих критеріях не підходить для співпраці. Залежно від форми, в якій слід представляти заявку на участь в конкурсі, конкурсні замовлення доцільно підрозділяти на дві групи. До першої відносяться замовлення, конкурс на отримання яких наказує заповнення фіксованої

форми заявки. Призначення виконавця на замовлення другої групи робиться на підставі оцінки заявок, представлених у вільній формі. У таблиці 3.1 приведена класифікація можливих замовлень, представлена разом з цілями, які переслідує потенційний замовник, оголошуючи конкурс на виконання проекту або пропонуючи цільове замовлення. Вказані цілі зумовлюють ті моменти, на які менеджерові слід звертати увагу при складанні "Заявки на проект". Представлена класифікація є такою, що ідеалізується. У реальній практиці можливі змішані форми, зокрема, багаторівневе отримання замовлення, коли спочатку виробляється попередній відбір претендентів (як правило, це конкурс з фіксованою формою заявки), потім - додатковий відбір (наприклад, з використанням вільної форми). Зрештою замовлення такого роду виявляються цільовими для тих виконавців, які виявляються переможцями. Класифікація замовлень з точки зору документу "Заявка на проект"

Таблиця 3.1

Конкурсне замовлення Цільове замовлення

Особливості:

конкретний проект

конкурентний вибір виконавця

Особливості:

завдання може варіюватися

послідовний вибір виконавця

фіксована форма

заявки

вільна форма

заявки

Мета: підвищити

об'єктивність при

виборі виконавця

Мета: розширити круг

відомостей, що оціню-

ються при виборі

виконавця

Мета: точніше встановити відповідність

Проект-Виконавці

Взагалі, отримання конкурсного замовлення завжди призводить або до відмови від

послуг претендента, або до переходу до цільового замовлення з одним або декількома

виконавцями. У останньому випадку можливо, що одне замовлення розміщують у

невеликого числа виконавців з наступною відмовою від послуг тих з них, у кого результати

(поточні або остаточні) виявляються гірше, ніж у конкурентів. Працюючи із заявкою у

фіксованій формі, менеджер повинен добре собі представляти можливі і найпривабливіші

для замовника відповіді. Не варто зловживати невизначеними відповідями (типу ”Важко

відповісти”). Тим самим вказується на обмеженість круга питань компетентності

претендента.

Особливу увагу слід приділяти позиціям документу, які відбивають кваліфікацію і

потенційні можливості виконавця. Тут завжди є місце свавіллю. Ви можете не вказати,

приміром, що ваш колектив брав участь в розробці тієї або іншої відомої системи, з різних

причин: через те, що цей досвід виявився невдалим, що основні працівники команди

перестали співробітничати з вами, нарешті, ви могли просто забути зафіксувати цей факт.

Яка буде реакція на це з боку потенційного замовника? Відповідь неоднозначна. Він може

просто не помітити, що у вас є досвід, не відбитий в заявці, і це мінус з точки зору оцінки

ваших можливостей. Якщо замовник виявився обізнаним про ваш, приміром, невдалий

досвід і помітив це, то результат оцінки залежить від критеріїв (що більше важливе для

замовника: ваша самооцінка або ваше прагнення приховати небажане). Проте, в більшості

випадків не варто упускати з виду те, що, можливо, на перший погляд здається незначним.

Але з іншого боку, не слід перебільшувати свій досвід і компетентність. Навіть якщо

представлену інформацію важко перевірити, можна потрапити в ситуацію, коли

недобросовісні дані зроблять вам ведмедячу послугу (наприклад, вказавши, що колектив

володіє досвідом програмування на деякій мові, ви ризикуєте отримати додаткові витрати на

навчання).__

26. Уточнення замовлення на проект.

 

Одним з найбільш тонких моментів передпроектної діяльності менеджера є робота з потенційним замовником, спрямована на отримання інформації про те, що повинно бути

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

можливостей продукту, що замовляється, друга - для замовника, щоб він міг орієнтуватися в тому, які витрати його чекають, якщо він скористається послугами цієї організації, компанії

(цього менеджера). Треба відмітити, що ситуація, коли замовник по-справжньому не уявляє собі відповіді на поставлені питання, - цілком типова, а тому в більшості реальних випадків

потрібний діалог між менеджером і потенційним замовником, уточнююче замовлення.

Найправильніше вести цей діалог так, щоб:

· спочатку зрозуміти, які завдання бажає вирішувати замовник за допомогою засобів,

що замовляються,

· потім запропонувати йому найбільш раціональний шлях рішення, здійсненний при

розміщенні замовлення у вашій організації.

 

В рамках цього діалогу головне, що треба зробити, - добитися однозначного розуміння використовуваних понять. Прямо заявити замовникові, що він в чому-небудь не правий, не

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

початкової інформації для проектування. Не менш важливо, щоб до моменту отримання замовлення у замовника і виконавця склалося загальне розуміння постановок завдань, досягнення якого можна розглядати як

складову частину процесу ліквідацією двозначностей. Але тут є особливість, яка пов'язана з тим, що рішення завдань проекту має бути впорядковане в часі, і, як наслідок, необхідно

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

замовник не структурує завдання зовсім, і тоді запропонувати відповідну структуру завдань проекту - справа менеджера, одержуючого замовлення.

Для аналізу відомостей про завдання проекту корисно виписати їх в порядку спадання пріоритетів у вигляді таблиці, що містить наступні поля:

· Найменування призначеного для користувача завдання;

· Які вимоги до виробу, що замовляється, забезпечують рішення цієї задачі (перерахування

або позначка про те, що рішення цієї задачі засобами виробу, що замовляється, фактично

не підтримується);

· Чого не вистачає для підтримки вирішення цієї задачі (зустрічні пропозиції, доповнення,

які доцільно включити в проект);

· Реалізаційні зв'язки між завданнями (реалізація засобів підтримки рішення одного із

завдань тягне реалізацію підтримки рішення іншій, засоби підтримки рішення обох

завдань мають загальні компоненти, завдання не пов'язані);

· Можливість локальної демонстрації рішення задачі (тобто такій демонстрації, яка не

залежить від рішення інших завдань). Якщо за цією ознакою завдання диференціюються

слабо, то корисно сконструювати демонстраційні завдання, рішення яких можна показати

замовникові найскоріше. Доповните ними таблицю;

· Оцінка можливості використання доступного програмного забезпечення, зокрема,

напрацювань фірми, яка береться за виконання замовлення (корисно супроводжувати

таку оцінку вказівкою того, що саме передбачається використовувати). Якщо на те є

достатні підстави, то ці відомості можна не показувати замовникові;

· Оцінка вимог до кваліфікації розробників (порівняльна характеристика завдань);

· Попередній розподіл вартості розробки. Слід оцінити співвідношення трудомісткості

виписаних завдань і зразкові терміни їх рішення. У таблиці вказуються експертні оцінки

менеджера безвідносно вартості замовлення і обліком пропонованого фінансування

(друга позиція виставляється в ході аналізу таблиці). Процес заповнення цього поля може

викликати коригування переліку і змісту завдань проекту;

· Оцінка пріоритетності завдань. Вона виставляється в ході аналізу цієї таблиці.

 

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

критеріям відбору :

· мінімізація термінів демонстраційного рішення;

· переиспользуемость компонентів (колишніх розробок, наявних стандартизованных

модулів, а також що з'являються в ході розвитку проекту);

· істотність реалізаційних зв'язків;

· актуальність для користувача.

 

Вибір переваг між цими критеріями у кожному конкретному випадку свій, але зазвичай компроміс знайти вдається. Компромісну послідовність вирішуваних завдань, заздалегідь

розбиту на дві частини, : найближчі завдання і перспектива, слід пред'явити замовникові. Було б непогано, переконати замовника, що додаткові завдання, що потрапляють в розряд

найближчих, корисні (з тієї або іншої точки зору). На жаль, далеко не завжди таке можливе. Реалістичніше і цілком досить показати замовникові, що його завдання будуть вирішені.

Результати аналізу в сукупності з їх мотивуваннями доцільно показати замовникові для досягнення угоди про проект. Зрозуміло, не слід вносити до документу, що пред'являється,

проміжні відомості (рішення, знехтувані самим менеджером, як неперспективні). Крім того, документ має бути максимально близький до пропозицій замовника. Пам'ятайте, що статус

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

найближчі завдання. Це пов'язано з двома обставинами. По-перше, час, який витрачається в передпроектний період, - це завжди витрати вашої фірми, а не замовника, а тому затягування

його просто невигідно. По-друге, тривала утруска спірних питань може натомити замовника, і тоді цілком реально говорити про те, що він віддасть перевагу над вами кому-небудь

іншого.

 Уточнення замовлення до його отримання не слід змішувати з фазою дослідження, яка виконується, коли основні позиції замовлення фіксовані. Для менеджера завдання уточнення

в тому і полягає, щоб фіксувати найбільш прийнятні умови виконання фази дослідження і проекту в цілому.

 Частиним, але дуже важливим для діяльності фірми є уточнення перспективного замовлення. Суть його в тому, що або із самого початку, або в ході діалогу з потенційним

замовником з'ясовується, що запропоноване завдання може і за логікою речей повинно мати продовження. Це продовження не сформульоване явно і зовсім не обов'язково усвідомлено

замовником - він хоче вирішити конкретне завдання і тільки. Але менеджер розуміє, що:

· розумніше вирішувати загальнішу задачу і отримати що замовляється як один з

корисних наслідків;

· у замовника неминуче з'являться нові завдання, тісно пов'язані з першим замовленням;

· незалежно від фінансової привабливості замовлення можливе продовження обіцяє

відчутні вигоди (фінансування продовження цим замовником, накопичення досвіду,

можливість розвитку замовлення силами компанії та ін.);

· первинне замовлення дається, щоб випробувати майбутнього виконавця для перевірки

його потенційних можливостей.

 Таким чином, перспективне замовлення - це та ситуація, коли розумно планувати комплекс робіт для послідовних завдань, готувати універсальні засоби підтримки, пропонувати замовникові

рішення, зручне з точки зору цієї підтримки. Це реальна економія зусиль розробників, яка на перших етапах, можливо, зажадає додаткових коштів організації середовища розробки. Але

було б грубою помилкою менеджера до виконання першого завдання пропонувати замовникові фінансувати створення такого середовища. Єдина можливість отримати потрібні додатково ресурси -

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

· Перше завдання виконується паралельно з визначенням вимог до операційного середовища, що забезпечує продовження замовлення необхідними засобами. Це завдання

розглядається як прототип відробітку технології використання цього середовища;

· Розробка операційного середовища виділяється як самостійний проект, що виконується незалежно від першого завдання і паралельно з ним;

· Усі аспекти першого завдання і завдань, що продовжують замовлення, пов'язані з операційним середовищем, узгоджуються з нею по требумой функціональності і

інтерфейсам. Тобто демонструється здійсненність підходу, що розвивається;

· Завдання замовлення, що триває, виконуються в контексті використання результатів побудови операційного середовища.

 

Формування перспективного замовлення не обов'язкове в усьому дотримується представленої схеми. Цілком можливо, що замовлення усвідомлене як перспективний не

відразу, а в ході виконання першого завдання (на етапі оцінки) або після одного з наступних завдань. Це сигнал, що варто виробити ревізію напрацьованого і вирішити, доцільно або

немає розробляти спеціальне операційне середовище для цього замовлення, коли і за чий рахунок виконувати допонительный проект, чи треба переробляти старе і яка вартість

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

інструментарій як власний (внутрішнього) продукт, іншими словами, не переносити його вартість на це замовлення. Це означає, що перспективність замовлення усвідомлена не з

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

 

27. Класифікація замовлень з точки зору документу “Заявка на проект”.

Конкурсне замовлення		Цільове замовлення
Особливості: •  конкретний проект •  конкурентний вибір виконавця		Особливості: •  завдання може варіюватися •  послідовний вибір виконавця
• фіксована форма заявки	• вільна форма заявки
Мета: підвищити	Мета: розширити круг	Мета: точніше встановити відповідність
об'єктивність при	відомостей, що оціню-	Проект-Внконавці
виборі виконавця	ються при виоорі
	виконавця

 

 

28. Функції менеджменту.

У широкому розумінні смислове навантаження терміну функція (від лат. Functio - виконання, здійснення, роль, обов'язок) укладає в собі діяльність, обов'язок, роботу; зовнішні прояви властивостей якого-небудь об'єкта в даній системі відносин. Будь організаційна система, проект не є винятком, являє собою складну систему обов'язків у процесі творчої діяльності. Управління проектом, саме по собі, є основною функцією проекту, як динамічної системи. Однак ця основна функція може бути представлена ​​деякими її складовими, інакше кажучи, підфункції. Можна виявити найбільш загальні підфункції УП, що відносяться до будь-якого проекту.

У процесі здійснення проекту і управління їм у всіх підсистемах і на всіх фазах життєвого циклу виконуються певні системні функції, такі як:

 

Рис. 2.9. Загальні функції менеджменту

 

Рис. 2.9. Загальні функції менеджменту проекту

Планування - діяльність, спрямована на розробку плану.

Планування - приведення проекту як системи від бажаного

стану до можливого.

План - заздалегідь намічений порядок, комплекс завдань, послідовність здійснення якоїсь програми, робіт, заходів об'єднаних спільною метою).

План - сценарій майбутніх дій.

 

Планування як функція управління включає визначення стратегій, політики, процедур для реалізації проекту. Планування в проектній середовищі можна визначити як попередню опрацювання і вибір прогнозних рішень по реалізації проекту в умовах різних альтернатив, що базуються на знанні предметної області та можливих невизначеностей (ризиків) реалізації проекту. При цьому, в контексті УП планування включає також процеси організації здійснення планів, коректування планів і контролю за їх виконанням. В УП планування втілює в собі організуючий початок всього процесу реалізації проекту. Планування охоплює всі фази проектного циклу і є безперервним процесом. Вона починається з участі проект-менеджера в процесі розробки концепції проекту, продовжується при виборі стратегічних рішень виконання проекту і розробці його деталей, включаючи складання конкретних пропозицій, укладання контрактів, виконання робіт, і закінчується лише при завершенні проекту. Прийняті в процесі планування рішення повинні забезпечити реалізованість проекту в задані терміни і мінімальною вартістю і витратами ресурсів і при високій якості виконання робіт. Одна з основних цілей планування - інтеграція учасників проекту для виконання комплексу робіт, що забезпечують досягнення кінцевих результатів проекту. Планування є основою контролю, обліку та оперативного управління.

 

Організація (як процес) - структурування процесів і делегування повноважень.

 

У широкому сенсі організація розуміється як сукупність структури системи і способів функціонування її елементів. Стосовно до УП організація розглядається як одна з основних функцій УП і як організаційна форма діяльності. Організація як функція являє собою процес упорядкування, узгодження взаємодії більш-менш диференційованих частин цілого. Іншими словами, це сукупність процесів або дій, що ведуть до утворення і вдосконалення взаємозв'язків між елементами проекту.

 

Мотивація - процес спонукання в особистості бажання працювати для досягнення цілей проекту при одночасній реалізації його власних цілей.

 

Слід розрізняти мотивацію, як дослідження спонукальних причин дій людини, і мотивацію, як спосіб впливу на поведінку людини. Раніше дослідження цієї проблеми була долею переважно фахівців, проте, у зв'язку з бурхливим розвитком і ускладненням соціальних і економічних відносин, радикальним ускладненням комунікацій, виникла нагальна необхідність створення таких технологій мотивації, які були б досить ефективні, в той же час, застосовні в повсякденній практиці ділових відносин. За останні 40 років мотивація як прикладна галузь знань розвивалася особливо активно і, як наслідок цього, з'явився цілий ряд спрощених теоретичних моделей, заснованих на результатах психологічних досліджень.Контроль життєдіяльності проекту - процес встановлення відповідності плану і факту, виявлення ступеня відхилень, обгрунтування коригувальних рішень.

 

Контроль життєдіяльності проекту (control) - функція управління проектом, що включає процеси спостереження за ходом реалізації проекту з метою перевірки відповідності фактичного виконання запланованим показникам, передбаченим планами, контрактами, угодами і т.д. Функція контролю проекту виконується на всіх фазах і у всіх його підсистемах і включають: контроль витрат, контроль термінів і тривалості робіт, контроль якості, контроль ризиків, контроль бюджет проекту, контроль виконання рішень, контроль матеріально-технічних запасів за проектом і т.д.

Оперативне управління (operating management). Процес практичного втілення програм і проектів у кожній з областей діяльності, зміни та оцінки результатів, а також порівняння досягнутих результатів з поставленими цілями. Оперативне управління можна розглядати і як самостійну підсистему управління, і як одну з основних функцій управління проектом. У цьому зв'язку доцільно позначити підсистему як «управління змінами», а функцію як «оперативне управління».

Докладна інформація про зміст цих функціях наведена в наступних розділах.

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

 

БАЗАР

29. Наведіть схеми організації менеджменту проектів.

Поняття «менеджер проекту» не обов'язково співвідноситься з конкретною персоною, яка відповідає за управління виробництвом програмної системи в цілому. У невеликому проекті таке єдиноначальність найчастіше виправдано: воно дозволяє концентрувати всі нитки управління, виключає проблеми внутрішнього для проекту погодження суперечностей, забезпечує централізовану відповідальність за проект перед тими, хто зацікавлений у його виконанні. Однак у міру переходу до більш масштабних проектів менеджерські обов'язки стає неможливо концентрувати в одних руках. Зазвичай в таких випадках надходять відповідно до однієї з двох схем організації виробництва.

Перша схема - це утворення служби менеджера, що складається з його помічників, яким він може доручати різні завдання, звільняючи себе від рутини постійного контролю. Цей шлях, по суті, є лише паліативом.

Для ще більш складних проектів з'являється необхідність слідувати другою схемою, тобто утворювати групу менеджерів, відповідальних за різні розмежовані сфери проекту.

 

30. Функції, які виконуються розробниками програмного проекту.

Функції, які виконуються розробниками програмного проекту.

Розробник (Developer) - реалізує проектовані компоненти, розробляє специфічні класи і

методи, здійснює кодування і автономне тестування, створює програмний продукт. Це

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

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

 

31. Рольові кластери моделі проектної групи MSF.

MSF засновано на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту. Ці цілі зумовлюють модель проектної групи. У той час як за успіх проекту відповідальна вся команда, кожен з її рольових кластерів, що визначаються моделлю, асоційований з однією зі згаданих шести цілей і працює над її досягненням.

Шість рольових кластерів моделі проектної групи (рис. 11) - це "Управління продуктом" (product management), "Управління програмою" (program management), "Розробка" (development), "Тестування" (test), "Задоволення споживача" (user experience) і " Управління випуском "(release management). Вони відповідальні за різні області компетенції (functional areas) та пов'язані з ними цілі й завдання. Іноді рольові кластери називаються просто ролями. Але в будь-якому разі суть концепції залишається тією ж - побудувати основу виробничих відносин і пов'язану з нею модель команди такими, щоб вони були пристосованими (масштабованими) для задоволення потреб будь-якого проекту. Одна роль (або один кластер) може бути представлена однією або кількома співробітниками, в залежності від розміру проекту, його складності та професійних навичок, необхідних для реалізації всіх областей компетенції кластеру.

32. Принципи, які визначають регламент суміщення ролей.

 

 

33. Суміщення ролей.

В більшості випадків замовник і планувальник ресурсів є дійсно зовнішніми по

відношенню до проекту дійовими особами, а тому поєднання цих ролей з іншими - щось екзотичне. Змістовніше говорити про поєднання ролей в команді. В зв'язку з цим доречні рекомендації, засновані на досвіді успішного і невдалого менеджменту програмних проектів. Менеджер проекту по своєму призначенню є виділеним обличчям команди. Він концентрує в собі взаємодію із замовником і планувальником ресурсів, з одного боку, а з іншої - розподіляє роботи серед членів команди. Останнє означає, що він повинен мати повну інформацію про декомпозицію проекту. Як наслідок, поєднання його ролі з роллю архітектора проекту є дуже бажаним, а тому досить частим. Єдиною умовою для такого поєднання є вимога чітко знать, коли і чиї функції виконує ця дійова особа. Втім, це універсальна вимога для будь-якого поєднання ролей. 

Цілком можливо продуктивне поєднання ролей керівника команди і архітектора - це дає відчутні результати, коли команда досить міцно пов'язана зі своїм керівником, наприклад, по попередніх роботах, але за умови не занадто високої складності завдань декомпозиції для цього проекту. Поєднання ролей керівника команди і менеджера допустимо, але лише тоді, коли усвідомлюється і враховується суперечність цільових установок цих ролей : керівник команди діє в умовах, які формуються менеджером. Вкрай небажане поєднання ролей  керівника команди і проектувальника якої-небудь підсистеми. В цьому випадку у керівника можуть скластися переваги на користь "свого" компонента, і, як наслідок, можливий дисбаланс проекту в цілому на користь виділених його складових, який доведеться компенсувати додатковими зусиллями менеджера. З тих же причин не допускається поєднання ролей менеджера і розробника. Тут заборона жорсткіша, оскільки контрольні функції менеджера несумісні з виконавськими завданнями розробника. Навіть у тих випадках, коли у менеджера залишається вільний час після виконання своїх прямих обов'язків, йому не слід "допомагати" розробникам. Краще зайняти себе іншою справою, зокрема виступити в ролі розробника іншого проекту. В той же час, поєднання ролей різних розробників - звичайна справа для великих проектів. Воно є частиною розподілу робіт по виконавцях. Вирішують цю задачу спільно керівник команди і менеджер, коли основні архітектурні положення затверджені. Способи рішення залежать від того, як формується команда. Якщо розробка доручається готовій команді, то зростає роль керівника, а менеджер лише затверджує його пропозицію. Коли команда створюється для проекту, росте питома вага менеджерських функцій в підборі кадрів для робіт. Але у будь-якому випадку при поєднанні ролей різних розробників треба враховувати рівень кваліфікації працівників, їх переваги і інші індивідуальні особливості. Необхідно знати, що, виділяючи одній дійовій особі декілька робіт, слід прагнути до однорідності завдань, вказувати їх порівняльні пріоритети. Допустимі і інші поєднання ролей. Так, досить часто створення документації

розподіляється між усіма виконавцями проекту, а на керівника команди і менеджера покладається інтеграції документів. Для осяжних проектів функції бібліотекаря можна доручити одному з розробників, відповідно скоректувавши його індивідуальне завдання. Фахівцем з призначеного для користувача інтерфейсу цілком може бути, наприклад, менеджер, оскільки саме він здійснює контакти із замовником (у цій ситуації замовник або сам є користувачем, або виступає як представник користувача програмного виробу). Бажано, щоб ролі тестувальників доручалися незалежним фахівцям в предметній області, а не членам команди. Проте, і тут можливі варіанти поєднання. Зокрема, у багатьох випадках прийнятне так зване "перехресне" поєднання ролей розробників і тестувальників, коли розробники незалежних компонентів проекту тестують функціональність один одного.

 

34. Ключові ролі колективу розробників.

 

Зрозуміло, що значущість ролей розробників і тих, хто з ними пов'язаний, розрізняється залежно від того, який проект виконує команда програміста. Проте, можна вказати на ряд найбільш типових ролей, ігнорування яких приводить кращому випадку до втрат продуктивності праці команди в цілому, а в найгіршому - до краху проекту. Як досить повний перелік ролей можна вказати на наступний список, запропонований в рамках підходу Центру об'єктно-орієнтованої технології фірми IBM :

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

результати (як поточні, так і остаточні) розробки, виконаної роботи;

2. Планувальник ресурсів (Planner) - висуває і координує вимоги до проектів в організації, що здійснює цю розробку, а також розвиває і направляє план виконання проекту з точки зору організації;3. Менеджер проекту (Project Manager) - відповідає за розвиток проекту загалом, гарантує, що розподіл завдань і ресурсів дозволяє виконати проект, що роботи і пред’явлення результатів йдуть за графіком, що результати відповідають вимогам. В рамках цих функцій менеджер проекту взаємодіє із замовником і планувальником

ресурсів;

4. Керівник команди (Team Leader) – виконує технічне керівництво командою в процесі

виконання проекту. Для великих проектів можливе залучення декількох керівників підкоманд, що відповідають за рішення окремих задач;

5. Архітектор (Architect) - відповідає за проектування архітектури системи, погоджує розвиток робіт, пов'язаних з проектом;

6. Проектувальник підсистеми (Designer) - відповідає за проектування підсистеми або категорії класів, визначає реалізацію і інтерфейси з іншими підсистемами;

7. Експерт предметної області (Domain Expert) - вивчає сферу програмного продукту, що розробляється, (розроблювального ПЗ), підтримує спрямованість проекту на рішення задач цієї області;

8. Розробник (Developer) - реалізує проектовані компоненти, розробляє специфічні класи і методи, здійснює кодування і автономне тестування, створює програмний продукт. Це широкий термін, який може підрозділятися на вужчі ролі (наприклад, розробник класів). Залежно від складності проекту команда може включати різну кількість розробників;

9. Розробник інформаційної підтримки (Information Developer) - створює документацію, супроводжуючу продукт, коли випускається його версія. Інсталяційні матеріали, що включаються в неї, як зсилки так навчальну літературу, а також матеріали допомоги, які надаються на паперових і електронних носіях. Для складних проектів можливий розподіл цих завдань між декількома розробниками інформаційної підтримки;

10. Фахівець з призначеного для користувача інтерфейсу (Human Factors Engineer) - відповідає за зручність застосування системи. Працює із замовником, щоб упевнитися, що призначений для користувача інтерфейс задовольняє вимогам;

11. Тестувальник (Tester) - перевіряє функціональність, якість і ефективність продукту. Будує і виконує тести для кожної фази розвитку проекту;

12. Бібліотекар (Librarian) - відповідає за створення і ведення загальної бібліотеки проекту, яка містить усі проектні робочі продукти. Він також відповідає за відповідність робочих продуктів стандартам.

 

35. Ситуації, в яких діє менеджер при відборі кадрів.

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

враховувати рівень кваліфікації працівників, їх переваги і інші індивідуальні особливості

ДУДА

36. Вирішення задач визначення кадрових ресурсів проекту.

В ході апріорного розподілу ресурсів менеджерові корисно визначити можливі

кандидатури на ключові ролі колективу розробників з урахуванням можливості

персоналіями поєднувати ролі або займати їх частково (протягом робочого дня або протягом

певного календарного періоду розвитку проекту).

До ключових ролей відносяться:

архітектор проекту,

проектувальники підсистем,

керівники команд розробки підсистем,

фахівець з призначеного для користувача інтерфейсу і

експерт предметної області

Кандидати на ключові ролі - основа колективу. Заповнення інших вакансій визначається,

коли така основа є, частенько навіть в ході розвитку проекту і в міру необхідності. Оскільки

перші учасники проекту відповідають тільки за фазу дослідження, для початку проекту

мінімально необхідними персоналіями є ті, хто виконуватиме ролі архітектора і експерта

предметної області. Але це не означає, що відкладання питання про інші персоналії -

правильне рішення. Саме до початку проекту потрібно визначити у загальних рисах, з ким

надалі належить мати справу менеджерові.

 

37. Цілі розробки проірамного забезпечення.

Першорядні цілі включають в себе:

визначення того, яке програмне забезпечення створюється в рамках даного проекту

і обмежують цю область умов, які включають операційний контекст і критерії,

що розмежовують, що може, і що не може розглядатися для проекту як його

робочий продукт;

первинні сценарії роботи з системою, які прямо випливають з прийнятих угод про

замовляється програмному забезпеченні;

обгрунтування і, можливо, демонстрація, принаймні, одного архітектурного

рішення для реалізації деяких з первинних сценаріїв;

попередня оцінка фінансової потреби проекту в цілому, його календарний план і

сітьовий графік (мінімальна і раціональна схеми);

деталізовані ресурсна потреба, календарний план і сітковий графік для робіт

першої ітерації, яка починається відразу після затвердження результатів аналізу (на

початку проекту попередній та поточний аналізи перекриваються);

оцінка потенційних прогнозованих ризиків.

 

38. Поняття діяльності в менеджменті програмних проектів.

Стосовно до менеджерської діяльності, цикл

управління - це заходи в контрольних точках, мета яких в тому, щоб впевнитися, що

виконання завдання йде за планом. Якщо з'ясовується, що це не так, надається допомога:

перерозподіляються технічні та кадрові ресурси на користь відстає роботи,

встановлюються додаткові контрольні терміни і т.п. Як небажаних, але іноді необхідних

заходів слід вказати на зміну виконавців та/або зсув призначених термінів закінчення

роботи. Це загальні положення, що стосуються циклу управління всіх стадій розвитку

проекту.

 

39. Задачі менеджменту програмних проектів.

В цій темі задачі менеджменту обговорюються в контексті робіт, які повинні

завершувати попередній аналіз і починати итеративное нарощування можливостей

програмного виробу. У традиційній послідовній схемі явно виділяється період, коли

аналіз закінчується і починається конструювання; повернення до аналізу - це виправлення

помилки (з усіма наслідками, що випливають з неї наслідками). В об'єктно-орієнтованої

схемою аналіз ніколи не закінчується, він відновлюється щоразу після оцінки ітерації.

Можна сказати, що оцінка ітерації є основою для аналізу наступної ітерації. Але для

першої ітерації такої основи не існує. Звідси випливають особливості переходу від етапу

аналізу до конструювання першій ітерації, пов'язані з тим, що це час, коли змінюється

точка зору на ітерацію і на проектований виріб в цілому:

замість проблемно-орієнтованих об'єктів розглядаються реалізаційні об'єкти;

моделі рівня аналізу замінюються моделями, що представляють реалізаційну

декомпозицію системи;

деякі класи, що виникають в ході аналізу, зникають, з'являються класи, специфічні

для реалізаційної середовища (наприклад, специфицируются інтерфейсні класи

звернення до баз даних);

конкретизуються і уточнюються стратегії і методики, намічені для виконання тих

чи інших робіт.

 

40. Модель Гантера.

У найбільш послідовному виді таке доповнення класичної схеми реалізоване в моделі

Гантера у вигляді матриці “фази – функції”. Вже з цього виходить, що модель Гантера має

два виміри: фазове, відбиваюче етапи виконання проекту і супутні ним події, і

функціональне, показуюче, які організаційні функції виконуються в ході розвитку проекту, і

яка їх інтенсивність на кожному етапів.

У моделі Гантера відбите те, що виконання функції на одному етапі може тривати на

наступному. На Рис. 2.5 представлений фазовий вимір моделі. Жирною рисою (з розривом і

стрілкою, що означає тимчасовий напрям) зображений процес розробки. Контрольні точки і

найменування подій вказані під цією рисою. Вони помічені числами. Увесь розвиток проекту

в моделі прив'язується до цих контрольних точок і подій.

 

 

41. Моделі життєвого циклу програмного забезпечення.

Аналогія життєвого циклу програмного забезпечення з технічними системами має

глибше коріння, ніж це може здатися на перший погляд. Програми не схильні до фізичного

зносу, але в ході їх експлуатації виявляються помилки (недоліки), що вимагають

виправлення. Помилки виникають також від зміни умов використання програми. Останнє ж є

принциповою властивістю програмного забезпечення, інакше воно втрачає свій сенс. Тому

правомірно говорити про старіння програм, хоча не про фізичне старіння, а про моральне.

Необхідність внесення змін в діючі програми є по сутті справи продовження розробки

програмного забезпечення після передачі його користувачеві і протягом усього часу життя

програм. Діяльність, пов'язана з рішенням досить численних задач, такої розробки, що

триває, отримала назва супроводу програмного забезпечення

Історично розвиток концепцій життєвого циклу пов'язаний з пошуком для нього

адекватних моделей. Як і будь-яка інша, модель життєвого циклу є абстракцією реального

процесу, в якій опущені деталі, несуттєві з точки зору призначення моделі. Різноманітність

призначень визначає різноманітність моделей.

 

42. Класична ітераційна модель.

Загальноприйнята модель життєвого циклу є ідеальною, оскільки тільки дуже прості

завдання проходять усі етапи без яких або ітерацій - повернень на попередні кроки

технологічного процесу. При програмуванні, наприклад, може виявитися, що реалізація

деякої функції дуже громіздка, не ефективна і вступає в протиріччя з потрібною від системи

продуктивністю. В цьому випадку вимагається те, що перепроектувало, а може бути і

переробка специфікацій. При розробці великих нетрадиційних систем необхідність в

ітераціях виникає регулярно на будь-якому етапі життєвого циклу як із-за допущених на

попередніх кроках помилок і неточностей, так і із-за змін зовнішніх вимог до умов

експлуатації системи. Такі мотиви класичної ітераційної моделі життєвого циклу (див. рис.

2.3). Класична ітераційна модель абсолютизує можливість повернень на попередні етапи.

Проте ця обставина відбиває істотний непереборний аспект програмних розробок, що не

спираються на объектно-ориенти-ро-ван-ное проектування. Всі традиційні технології

програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не

міняється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося

готовим. Інше положення з об'єктно-орієнтованими технологіями. Як вже відзначалося,

відмова від завершеності фаз і етапів, замість чого пропонується розподіляти нарощування

функціональності і інтерфейсних можливостей по ітераціях, дозволяє ослабити вимогу

переробки старого при поверненнях. По суті, класична схема залишається вірною, але тільки

у рамках однієї ітерації і з однією важливою поправкою: усе корисне, що було зроблено

раніше, зберігається. Зрозуміло, що для програмної системи в цілому новий підхід вимагає і

нових моделей життєвого циклу, що відбивають його особливості, відмічені раніше.

 

 

КОСЯК

43. Каскадна модель.

Каскадна модель - реалізує принцип однократного виконання кожного виду діяльності у вигляді заздалегідь обмежених і однозначно упорядкованих у часі стадій і етапів, здійснюваних як би в їх природних межах. В узагальненій каскадної моделі виділяють 8 етапів:

На першому етапі шляхом консультацій із замовником визначаються цілі та функції, а також обмеження на створюване ПС.

На етапі попереднього (ескізного) проектування виробляються вимоги до апаратних засобів і програмного забезпечення, розробляється архітектура програми.

При детальному проектуванні докладно описуються компоненти ПС і їх взаємозв'язку.

На наступній стадії архітектура ПС реалізується у вигляді безлічі розроблених і налагоджених програмних одиниць.

Далі окремі програми інтегруються і тестуються у вигляді цілісної системи.

Потім ПС супроводжується документами і передається в експлуатацію.

Супровід ПС включає виправлення помилок, які не були виявлені на більш ранніх етапах ЖЦ, вдосконалення програмних компонентів і модифікацію функціональних можливостей програми до нових вимог.

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

До недоліків каскадної моделі можна віднести негнучке розбивка процесу створення ПС на окремі фіксовані етапи. У цій моделі визначають ПС рішення приймаються на ранніх етапах і потім їх важко скасувати або змінити. Тому каскадна модель застосовується тоді, коли вимоги формалізовані досить чітко і коректно.

44. Модель фази - функції.

Мотивується необхідність відображення в моделях життєвого циклу виробничих функцій, виконуваних розробниками. Ці функції повинні зв'язуватися з контрольними елементами управління проектами, тобто етапами життєвого циклу, але тим не менше вони виконуються протягом усього періоду розвитку проекту з різною інтенсивністю. Описується модель Гантера фази-функції як основа побудови розвинених схем життєвого циклу, що включає відображення організаційних і технічних виробничих функцій. Показується, як в моделі фази-функції можна враховувати ітеративний (в традиційному розумінні).

Надзвичайно важливим мотивом розвитку моделей життєвого циклу програмного забезпечення є потреба у відповідному засобі для комплексного управління проектом. По суті, це твердження вказує на те, що модель повинна служити основою організації взаємовідносин між розробниками, і, таким чином, однією з її цілей є підтримка функцій менеджера. Це призводить до необхідності накладення на модель контрольних точок, що задають організаційно-часові рамки проекту, і організаційно-технічних, так званих виробничих функцій, які виконуються при розвитку проекту.

Найбільш послідовно таке доповнення класичної схеми реалізовано в моделі Гантера у вигляді матриці "фази - функції" [11]. Вже з згадки про матрицю випливає, що модель Гантера має два виміри:

фазовий, що відображає етапи виконання проекту і супутні їм собитія1);

функціональне, що показує, які виробничі функції виконуються в ході розвитку проекту, і яка їхня інтенсивність на кожному з етапів.

Фазовий вимір

У моделі Гантера відображено те, що виконання функції на одному етапі може продовжуватися на наступному. На рис. 8.1 представлено фазовий вимір моделі. Жирною рисою (з розривом і стрілкою, що позначає тимчасове напрямок) зображено процес разработкі2). Контрольні точки та найменування подій вказані під цією межею. Вони пронумеровані. Все розвиток проекту в моделі прив'язується до цих контрольних точках і подіям.

Рис. 8.1. Фазовий вимір моделі фази - функції

У даній моделі життєвий цикл розпадається на наступні перекривають один одного фази (етапи):

 

Етап дослідження - починається, коли необхідність розробки визнана керівництвом проекту (контрольна точка 0), і полягає в тому, що для проекту обгрунтовуються необхідні ресурси (контрольна точка 1) і формулюються вимоги до розробляється виробі (контрольна точка 2).

Аналіз здійсненності - починається на етапі дослідження, коли визначені виконавці проекту (контрольна точка 1), і завершується твердженням вимог (контрольна точка 3). Мета етапу - визначити можливість конструювання вироби з технічної точки зору (чи достатньо ресурсів, кваліфікації і т.п.), чи буде виріб зручно для практичного використання; вирішення питань економічної і комерційної ефективності.

Конструювання - починається зазвичай на етапі аналізу здійсненності, як тільки документально зафіксовані попередні цілі проекту (контрольна точка 2), і закінчується затвердженням проектних рішень у вигляді офіційної специфікації на розробку (контрольна точка 5).

Програмування - починається на етапі конструювання, коли стають доступними основні специфікації на окремі компоненти вироби (контрольна точка 4), але не раніше затвердження угоди про вимоги (контрольна точка 3). Поєднання даної фази з заключним етапом конструювання забезпечує оперативну перевірку проектних рішень та деяких ключових питань розробки. Мета етапу - реалізація програм компонентів з наступною зборкою вироби. Він завершується, коли розробники закінчують документування, налагодження та компонування і передають виріб службі, яка виконує незалежну оцінку результатів роботи (незалежні випробування почалися - контрольна точка 7).

Оцінка - є буферною зоною між початком випробувань і практичним використанням виробу. Етап починається, як тільки проведені внутрішні (силами розробників) випробування вироби (контрольна точка 6) і закінчується, коли підтверджується готовність виробу до експлуатації (контрольна точка 9).

Використання - починається ближче до кінця етапу оцінки, коли готовність виробу до експлуатації перевірена і може організовуватися передача вироби на розповсюдження (контрольна точка 8). Етап триває, поки виріб знаходиться в дії і інтенсивно експлуатується. Він пов'язаний з впровадженням, навчанням, налаштуванням та супроводженням, можливо, з модернізацією вироби. Етап закінчується, коли розробники припиняють систематичну діяльність по супроводженню та підтримці даного програмного виробу (контрольна точка 10).

45. Об'єктио-орієнтовані моделі життєвого циклу.

Будь-який метод програмування будується, дере за все, на вікорістанні відповідніх механізмів мови програмування. ООП - ції методологія, Яка поєднує в собі Як процес об'єктної декомпозіції, так и прійоми представлені логічної та фізічної Моделі проектуємо програмної системи. У цьому означенні є Дві складові частин:

1. ООП - ції є Отримання об'єктно-орієнтованої декомпозіції.

2. Існують засоби різноманітного відображення логічної структури моделей системи, а кож різноманітність моделей, які відображають фізічну структуру програмної системи (архітектуру модулів и процесу).

З точки зору формального програмування, основна відміна ООП від структурного заключається в підтрімці об'єктно - орієнтованої декомпозіції.

До об'єктно-орієнтованих мов програмування належать: Visual C + +, Delphi, Java, Visual Basic

46. Передпроектна діяльність менеджера і початок фази дослідження.

Початкова фаза проекту розпочинається з процесу Формування Його Концепції та її обгрунтування. Розробка Концепції проекту передбачає виконан Наступний основних робіт:

Ø обгрунтування цілей проекту на Основі Вивчення Ринку та аналізу виробничих можливости;

Ø Попередня оцінку капітальніх витрат на проект та прогноз оборотного капіталу;

Ø оцінку трівалості проекту;

Ø прогноз збільшення Капіталу від реалізації проекту;

Ø визначення джерел та розмірів фінансування;

Ø визачення основних характеристик проекту ТОЩО.

Стадія підготовкі проекту поділяється на два етапи: попередня Оцінка та Додаткові Дослідження.

Ідея проекту винна буті детально розроблено на стадії ретельного Дослідження. Ідея проекту Може буті обумовлена:

Ø Прагнення віконаті Завдання, Що стояти перед країною;

Ø незадоволенімі потребами й Поиск можливости Шляхів їх задоволення;

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

Ø труднощамі або обмеження в перебігу Розробка, вікліканімі шлюбом Важливим виробничих потужностей, нерозвіненістю сервісу, нестачею матеріальних и людських ресурсів або адміністратівнімі чі іншімі перешкод;

Ø наявністю невикористаних або недовикористання матеріальних чі людських ресурсів та можлівістю їх застосування в продуктівнішіх галузях;

Ø необхідністю Зробити Додаткові капіталовкладення;

Ø Прагнення Створити спріятліві умов для Формування відповідної інфраструктурі виробництва й Управління;

Ø стіхійнімхамі (по сухому, повені та Землетрус). Ідеї ​​Щодо проекту надходять кож з-за кордону в результаті:

Ø пропозіцій іноземніх громадян або фірм про інвестиції;

Ø інвестіційніх стратегій, розроблення іншімі країнамі, а кож можливости, Що вінікають у зв'язку з міжнароднімі угодами;

Ø домінуючіх поглядів фахівців або ж консенсусу в рамках міжнародної спільноті з таких харчування, Як народонаселення, стан НАВКОЛИШНЬОГО природного середовища та боротьба Із зубожінням;

Ø діяльності організацій по Надання двосторонньої допомог и потокової проектів ціх організацій у даній Країні .

Ідея проекту піддається попередній перевірці в дослідженнях можливости. Попередні Дослідження грунтуються здебільшого на загально оцінках, Ніж на детальному аналізі, тому їх можна проводитись у трьох напрямком:

Ø Дослідження регіонів (Виявлення можливіть у даного регіоні);

Ø виробничі Дослідження (Виявлення можливіть у даній Галузі промісловості);

Ø Дослідження природніх ресурсів, сільськогосподарської та ПРОМИСЛОВОЇ продукції ТОЩО.

Інколи добро віконані Дослідження Щодо підготовкі проекту можут служити достатнім Його обгрунтуванням, протікають ЯКЩО економічна сторона проекту віклікає сумніві, слід неодмінно провести Додаткові Дослідження за проектом.

Додаткові Дослідження включаються:

Ø Вивчення Ринку за конкретними групами товарів (Попит, Його стійкість та ціна);

Ø Оцінка конкретних сировина и матеріальних ресурсів за щаблем доступності існуючіх та призначення ЦІН на ці ресурси;

Ø відбір можливости для Використання технологій;

Ø визначення та уточнення масштабів проекту, можліві транспортні Втрати;

Ø уточнення екологічної допустімості, тобто чіткій план впливим на Довкілля;

Ø визначення потенційніх джерел фінансування, порівняння альтернатив;

Ø визначення годин між альтернативних проектів.

Колі проектна Ідея конкретізована, то вон піддається поточній перевірці на можлівість виконан, проводитися Дослідження ціх можливости. Попередній аналіз винен підтвердіті возможности технічної реалізації у відповідній Країні або регіоні чі місті та віявіті ВСІ Шансі економічного Впровадження.

Передпроектні Дослідження повинності дати відповіді на наступні питання:

1. Технічна можлівість виконан проекту:

Ø особливі вимоги до Місця реалізації та порівняння з потенційнімі місцямі проекту (Клімат, власність на землю и т. ін.);

Ø Наявність або можлівість забезпечення машинами та обладнанням, виробнича потужність;

Ø гнучкість обладнання в розрахунку на діверсіфікацію виробництва;

Ø Наявність необхідної інфраструктурі;

Ø кваліфікаційні вимоги до управлінського апарату та обслуговуючого персоналу;

Ø вимоги до інших ресурсів;

Ø планові Терміни.

2. Економічна можлівість виконан проекту:

Ø очікуваній збут, поділеній на найважлівіші групи продуктів та Регіональні Рінк (експорт або внутрішній ринок);

Ø витрати на Створення підпріємства, очікувані річні Поточні витрати, в тому чіслі умовно-постійні адміністративно-управлінські витрати и т.д.;

Ø Розвиток Ринку робочої с та рінків сировини, основних та Додатковий матеріалів;

Ø можліві інвесторі (Власний капітал, кредити банків и т.д.);

Ø фінансовий результат проекту.

3. Обов'язково потрібно візначіті кож джерело ризиків.

У заключний проектних дослідженнях, на Основі якіх пріймаються інвестиційні Рішення, вікорістовують Елементи попередніх етапів аналізу. При проведені техніко-економічного аналізу розглядаються питання технічних можливости, питання Ринку збуту та закупівель, потреб матеріалів Із врахування вікорістовуваної технікі ТОЩО, при цьому враховуються потреба в додатковій інформації Зі Сторони потенційніх партнерів та інвесторів.

Взагалі, техніко-економічний аналіз розбівають на Такі пункти:

1. Передісторія та Зародження проекту. Зазначається Ім'я та адреси ініціатора проекту, Галузь и ціль підпріємніцької діяльності, орієнтація проекту (Наприклад, на збут чі на сировину базу), орієнтація проекту на внутрішній ринок або на експорт, політико-економічна Підтримка проекту;

2. Ринок збуту та виробничі потужності. Аналізується Річний Попит для всієї економікі та регіону, досліджується тенденція роз витку на ринку збуту, виробнича програма, експорт та імпорт продукції Галузі, абсолютна виробнича потужність та порівняння з обсягах Всього Ринку;

3. Рінк матеріалів та інших ресурсів. Розглядаються питання наявності сировини, основних та допоміжніх виробничих матеріалів, комплектуючих ВИРОБІВ, Наявність комунікацій, Тенденції розвітку на ринках закупівель (ціні та обсягах), конкретізується необхідність у ресурсах ТОЩО;

4. Місцезнаходження. Необхідно представіті точні дані про Місцезнаходження, Клімат, возможности забезпечення землею, відстань до рінків сировини та інших закупівельніх рінків, відстань до рінків збуту, Потенціал робочої с в регіоні, транспортну систему;

5. Техніка проекту. Вибране спосіб виробництва, необхідне обладнання, Інженерне забезпечення;

6. Юридична форма та Організаційна структура, а кож Інші витрати на організацію;

7. Потреба в робочій сілі для проекту, при цьому віділяють кваліфікованіх та некваліфікованіх робочих та менеджерів;

8. Визначення термінів реалізації проекту. Візначається трівалість різніх етапів проекту та трівалість можливости випробувань.

Фінансовий аналіз Може складатіся з таких етапів:

1. Спільне представлення грошових потоків надходження та виплат проекту;

2. Представлення джерел фінансування (Власний та позіковій капітал);

3. Складання планових балансів для зовнішнього представлення, планування ліквідності;

4. Розрахунок економічної ефектівності;

5. Оцінка проекту за допомог стандартних крітеріїв інвестіційніх розрахунків.

Загальноекономічній аналіз включає опис Загальної економічної сітуації, Спільне представлення витрат та вігід проекту, які торкаються національніх Економічних суб'єктів, переоцінку витрат та результатів за національно-економічних крітеріях ТОЩО.

Необхідно здійсніті екологічну та соціальну експертизу майбутнього проекту та Зробити Загальні Висновки.

Екологічна експертиза дозволяє оцініті Вплив проекту на навколішнє середовище в таких напряму:

Ø забруднення повітряного басейнів, грунтів та водойомів;

Ø зниженя біологічної різноманітності;

Ø перевезення, використання або віддалення небезпечних чи токсичних відходів;

Ø засоленість та заболоченість земель.

Соціальна експертизи дозволяє візначіті масштаби впливим проекту на соціальне середовище, вигоди, які отримуються мешканці регіону реалізації проекту, а кож можливости негативний Вплив проекту на населення.

Проект Може вважатіся вівіренім и готуємо для передачі на стадію детальної Розробка та реалізації за дотримання таких умов:

Ø проведено відбір альтернативних варіантів проекту, визначена Основні Переваги та недолікі;

Ø ідентіфіковано Основні організаційні ї Політичні внесок, які можут вплінуті на частку проекту, и Визначіть, Як смороду можут буті розв'язані;

Ø Визначіть очікувані вигоди й витрати, можливости ризиків та Шансі реалізації;

Ø існує цілковіта Підтримка Як влади, так и інших учасніків проекту

47. Підтримка репутації компанії і менеджера.

Відповідальність менеджера в області ціх технологій - володіння технікою особістої роботи в інформаційному середовіщі ї уміння прійматі правильні стратегічні Рішення по розвітку інформаційніх систем організацій. Потрібно вміті управляти інформацією й поліпшуваті своя справа за допомог правильного її Використання для підвіщення ефектівності роботи й для підвіщення ЯКОСТІ Керування. Більшість процвітаючіх організацій Це робіть за допомог автоматизованих інформаційніх технологій.

Вплив інформаційніх систем на організацію (Зміна структури організації Під впливим інформаційної системи, Інший Розподіл влади в організації, формування там іншої політики й культури, Зміни у формалізації, зайнятості, характері праці, вінікненні спожи в навчанні, і т.п.). Вплив організації на інформаційну систему (Місце інформаційної системи у організаційній структурі, володіння данімі, хто и Як буде управляти інформаційною системою, Як інформаційна система буде впліваті на Рішення, и т.д.). Інформаційні системи стають усе Більше дорогими й вплівовімі Щодо своїх спеціфічніх умів до правил ведення бизнеса, Що приводити до нових проблем, які необхідно вірішуваті, щоб вікорістаті потенційні Переваги інформаційніх технологій.

Всі ці Тенденції проявляються в різніх процесах и формах. Годиною їх Досить Важко зрозуміті, коли ми перебуваємо в середовіщі бизнеса, працюємо в компанії. Погляд з боку Трохи полегшує їхнє Виявлення. Того важліві консалтингові ї дослідніцькі проекти. Крім цього, ці Тенденції призводять до Формування спожи в навчанні. Причому не в дискретному, а постійному, Протяг Всього жіття

Вплив змін на представніків загально менеджменту організацій

Отже, ми можемо Погодитись, Що середовище бизнеса міняється. Що міняється для загально менеджменту компанії у зв'язку Зі зміною середовища бизнеса? На мій погляд, можна вказаті на ряд аспектів:

Доводитись жити в умів більшої невізначеності, чім раніше. Работа в принципова нових СЕРЕДОВИЩА.

В області стратегії доводитися стікатіся Із труднощамі. Раніше кращє можна Було представіті, у Чому полягають рінкові Тенденції.

Необхідне Створення мереж, об'єднання компаний. Управлінські функції поєднуються в одну модель, тепер смороду можут розкідатіся по Багата компаніям. Здійснення змін в організаційніх структурах. Необхідне вміння працюваті в інтернаціональному середовіщі, на стіки технологій. Робота з більшім числом підрядніків. Особливо в логістіці, Що ВСІ частіше стали передаватися іншім компаніям.

Внаслідок вісокої швідкості змін, компанія зіштовхується з тім, Що керівнікі віщої ланки ї заради діректорів одержують інформацію, коли вон Вже застаріває. У результаті Прийняття стратегічніх рішень делегується менеджерам середньої ланки. Як наслідок, міняються вимоги до їхньої підготовкі, ці менеджери по-іншому взаємодіють Із інформаційною системою.

У результаті роль менеджерів віщої ланки Складається не в прійнятті "Важливим" рішень, а в створенні культури організації. Їхні Завдання полягають у тому, щоб гарантуваті Формування тихий знань, які повінні існуваті усередіні компанії, и які булі б доступні для працюючих у ній.

Необхідно вкладаті велічезні гроші в Розвиток інформаційної системи організації, в Інформаційні технології, причому в умів невізначеності ї ризик. Найбільші витрати, найскладніші Рішення доводитися здійснюваті після того, Як вже вітрачені гроші на програмно-апаратного Частину інформаційної системи.

48. Підготовка і початок проекту.

Група адміністрування – група користувачів, які:

§ беруть на себе повноваження координувати роботу в рамках проекту

§ стежать за дотриманням процедур обговорення попередніх проектів критеріїв значимості

§ ведуть реєстр всіх активних користувачів, які є:

§ фахівцями з даної теми (за даними юзербоксів)

§ цікавляться певною темою (за даними юзербоксів)

§ активно створюють статті з цієї теми (за власними спостереженнями на протязі всього періоду роботи вікіпедії, але не менше ніж за 2 тижні від початку роботи вікіпроекту Критерії значимості)

§ повідомляють ці групи користувачів у випадку початку обговорення теми, до якої вони так чи інакше причетні.

Кваліфікаційні вимоги для входження до групи адміністрування

§ будь який користувач, який має більше 100 редагувань в просторі статей та 30 днів стажу в роботі в вікіпедії

§ готовий взяти на себе вищезазначені функції та координувати свої дії у роботі вікіпроекту з іншими членами адміністративної групи за допомогою особистих зв'язків (СО, електронна пошта, ICQ, skype, ФБ, ВК).

Процедура позбалення статусу члена групи адміністрування

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

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

Редакційна комісія – комісія, яка має підготувати остаточний текст проекту критеріїв значимості, врахувати всі пропозиції та зауваження учасників підготовчого етапу, редакційно оформити текст шляхом досягнення консенсусу серед її членів. Комісія формується з числа учасників підготовчого етапу за результатами висунення кандидатів, обговорення та голосування. Кількість учасників комісії визначають учасники підготовчого етапу.

Етапи прийняття критеріїв значимості

Пропонується чотирьохступеневий принцип прийняття критеріїв значимості, який включає в себе такі етпаи:

§ Нульовий етап — визначення загального напрямку з якого необхідно підготувати проект критеріїв значимості (Географія, Спорт, Мистецтво тощо) та визначення окремих тем цього напрямку, з яких необхідно готувати проект критеріїв значимості

§ Попередній етап — обговорення та прийняття учасниками підготовчого етапу підготовки проекту критеріїв значимості проекту критеріїв значимості з кожної окремої теми.

§ Обговорення спільнотою — етап обговорення спільнотою проекту критеріїв значимості з кожної окремої теми

§ Голосування щодо критеріїв значимості — етап голосування та прийняття рішення щодо проекту критеріїв значимості з кожної окремої теми

Механізм роботи проекту

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

49. Загальна характеристика підготовчих робіт.

У разі, якщо будь-який користувач ініціюватиме створення нових чи доповнення вже існуючих критеріїв значимості, він зобов’язаний повідомити про це всіх учасників групи адміністрування, зазначивши тему критеріїв значимості з обґрунтування необхідності її обговорення.

Група адміністрування:

• визначає день початку обговорення для підготовки проекту критеріїв значимості. Цей день має визначений бути таким чином, аби обговорення почалось на наступний день, після того, як останній користувач з реєстру розсилки отримав повідомлення про його початок.
• проводить розсилку повідомлень на сторінки обговорень користувачів, які є фахівцями в цій темою, цікавляться або є іншими зацікавленими особами (створюють статті на цю тематику)
• створює сторінки проектів критеріїв значимості.

День початку відбувається підготовка проекту критеріїв значимості. Учасники підгттовки проекту критеріїв значимості:

• повинні визначити термін підготовки проекту критеріїв значимості (процедурні питання). У разі, якщо за цей час, до консенсусного рішення учасниками не прийнято, вони можуть продовжити обговорення на 1 тиждень;
• на будь-якому етапі підготовки критеріїв значимості учасники попереднього етапу підготовки проекту критеріїв значимості можуть обрати редакційну комісію, яка має підготувати остаточний текст проекту критеріїв значимості відповідно до часових проміжків, визначених учасниками попереднього етапу підготовки проекту критеріїв значимості, але не більше 2-х тижнів. У випадку порушення часового регламенту роботи редакційної комісії вона переобирається з лімітом часу в 1 тиждень для підготовки проекту критеріїв значимості.

 

МАЗУР

50. Визначення технічних ресурсів.

Технічні ресурси проекту включають 

• обладнання, яке постачаєтья користувачам;

• обладнання для розробників, 

• зовнішнє (а не що розробляється, тобто стандартне) програмне забезпечення, яке

постачається;

• використовуване інструментальне (також стандартне) програмне забезпечення.

Як правило, потреба проекту в усіх цих видах ресурсів цілком визначена. Проте є моменти, на які варто звернути увагу. Розрахунок того, яке  устаткування повинне поставлятися, залежить від умов виконання проекту. Зокрема, якась частина устаткування, наявного у користувача, може застосовуватися і для цього проекту; розробники теж використовують наявні у них технічні ресурси. Можливо, замість купівлі нового устаткування досить його оновлення (upgrade). Все те ж торкається стандартного програмного забезпечення. Чи являється інструментарій розробників предметом економії ресурсів (використовується власний) або його вартість, можливо, часткова включається у витрати на проект, також повинно враховуватися при з'ясуванні технічних потреб проекту. До усього цього варто додати варіантність технічних рішень, від якої залежить як результат виконання проекту, так

і його вартість.

Складаючи схеми мінімальних і раціональних потреб технічних ресурсів, слід чітко

пов'язувати їх з отримуваними результатами. Цю інформацію буде потрібно як для

відстоювання своєї точки зору на  проект, так і для складання звітного документу про розподіл ресурсів. На передпроектній стадії вона залишається лише в особистому розпорядженні менеджера.

Мінімальна і раціональна схеми потреб технічних ресурсів повинні враховувати розподіл

постачань устаткування і стандартного програмного забезпечення за часом розвитку

проекту. Зокрема, повинні передбачатися час пошуку і придбання запрошуваних ресурсів, час, необхідний для установки і наладки, для попереднього  налаштування устаткування і програм у розробників з наступною передачею споживачеві. Результатом складання схем є два графіки постачання технічних ресурсів в сукупності з відомостями про витрати, пов'язані з постачаннями. Вони передаються керівництву компанії для ухвалення рішення про проект. Якщо в цьому є необхідність, то узгоджений графік пред'являється замовникові для затвердження.

 

51. Визначення кадрових ресурсів.

В ході апріорного розподілу ресурсів менеджерові корисно визначити можливі

кандидатури на ключові ролі колективу розробників з урахуванням можливості

персоналіями поєднувати ролі або займати їх частково (протягом робочого дня або протягом певного календарного періоду розвитку проекту). 

До ключових ролей відносяться 

• архітектор проекту, 

• проектувальники підсистем, 

• керівники команд розробки підсистем, 

• фахівець з призначеного для користувача інтерфейсу і 

• експерт предметної області 

Кандидати на ключові ролі - основа колективу. Заповнення інших вакансій визначається,

коли така основа є, частенько навіть в ході розвитку проекту і в міру необхідності. Оскільки перші учасники проекту відповідають тільки за фазу дослідження, для початку проекту мінімально необхідними персоналіями є ті, хто виконуватиме ролі архітектора і експерта предметної області. Але це не означає, що відкладання питання про інші персоналії - правильне рішення. Саме до початку проекту потрібно визначити у загальних рисах, з ким надалі належить мати справу менеджерові.

Перше питання розподілу ресурсів де підбирати фахівців на проект. Варіантів відповіді на нього небагато. 

По-перше, менеджер може заздалегідь знати можливих кандидатів (добре себе працівників, що зарекомендували, фірми, з якими  менеджер вже мав справу, або знає по чужих попередніх роботах). Це найкомфортніший варіант для менеджера, який цілком може використовувати особисті, іноді лише інтуїтивні уявлення про персоналії для вибору кандидатів. Слідує, проте, застерегти про те, що ні в якому разі не можна підміняти знання про людину як про працівника відомостями особистого характеру (приятельські стосунки, комунікабельність та ін.).

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

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

Підбір кандидатур на ключові ролі в проекті повинен закінчитися досягши контрольної точки 1 життєвого циклу проекту Ресурси розподілені. До цього моменту необхідно скласти графік залучення співробітників  до проекту з вказівкою початку робіт і оцінки їх тривалості. Зрозуміло, що в ході наступної розробки цей графік коригуватиметься, але початкові установки важливі як для керівництва, так і для співробітників, що притягаються. Конкретні персоналії в графіці встановлюються для ключових ролей, але оцінка кадрової потреби має бути виконана заздалегідь і по інших ролях. 

Складаючи графік в ході передпроектної діяльності, менеджер не повинен припускати, що

усі займані вакансії жорстко фіксовані (працівник може отримати вигіднішу пропозицію, захворіти та ін.). Вже з цієї причини доцільно, формуючи графік залучення співробітників до проекту, заздалегідь включати в нього усіх можливих кандидатів на ролі. Це дозволить вибирати, а згодом навіть міняти персоналії ролей.

Слід зазначити, що, притягаючи працівників на ключові ролі, менеджер дуже часто

потрапляє в ситуацію, сприятливу для проекту, коли кандидат, що притягається, вказує на інші можливі кандидатури. Було б безрозсудно ігнорувати подібні пропозиції. Єдине обмеження, яке варто встановлювати в таких випадках, - це вимога надати резюме. Втім, це вимога взагалі для кожного працівника незалежно від того, на яку роль він запрошується.

Склад відомостей резюме тут не обговорюється, але у зв'язку з підготовкою менеджера на

початок проекту слід сказати, що з резюме має бути прямо або побічно доступна інформація 

• про рівень кваліфікації працівника як претендента на ту або іншу роль;

• про умови роботи, які можна запропонувати працівникові, залучаючи його до проекту

(зайнятість повна або часткова, вимоги до заробітної плати та ін.).

Якщо цієї інформації отримати не вдається, то перед тим, як зробити конкретну

пропозицію, менеджерові треба провести співбесіди, на підставі яких він коригує свої апріорні оцінки. Виставляння апріорних оцінок може бути зроблене на підставі послужного списку працівника, опитування тих, з ким він працював і так далі. Важливо підкреслити, що відомості з резюме, а також збирані при опитуваннях і шляхом співбесід найчастіше не носять абсолютний характер, а тому при визначенні кадрових ресурсів проекту менеджер повинен провести нормування наявних даних. Зручно виражати оцінки в бальній системі.

 

 

52. Стратегії розподілу часу.

Замовлення на розробку програмної продукції, як правило, установлює строки

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

 Доти, поки розподіл ресурсів для проекту не затверджене, нема рації говорити про

розподіл часу виконання окремих видів робіт (це завдання заключного етапу фази

дослідження й початку етапу аналізу здійсненності проекту, коли конкретизуються всі умови розвитку проекту – контрольна точка 2 “Загальні вимоги складені, загальний план складений” життєвого циклу). Проте, дуже корисно зафіксувати те, яким образом менеджер буде контролювати проектний розвиток, як буде направляти його. Іншими словами, потрібно зафіксувати стратегію планування. Відомості про неї потрібні, у першу чергу, для розроблювачів. Але вони можуть зацікавити й замовника.

Наступні загальновизнані й взаємодоповнюючі  методи, застосовувані для

розподілу тимчасового ресурсу й контролю використання часу, можна рекомендувати

менеджерові для організації планування й контролю ходу розвитку проекту:

• складання календарних планів і

• ведення графіків сіткового планування.

 

 

53. Календарні плани.

Календарний план – це поетапно розбита і впорядкована за часом виконання

послідовність робіт проекту. Його зміст дозволяє керівництву планувати діяльність

колективу розробників проекту як підрозділу фірми в цілому. Як правило, календарний план пред'являється замовникові для того, щоб замовник орієнтувався в строках поетапного виконання завдання. Це зовнішні функції календарного плану.

Внутрішнпроектні функції календарного плану описуються нижче.

Звичайний календарний план представляється у вигляді таблиці з наступною

структурою:

Стовпець 1 заповнюється відповідно до розбивки замовленого проекту на складові.

Звичайно глибина рубрикації розбивки залежить від рівня пропрацьованості того або

іншого фрагмента проекту. У міру поглиблення декомпозиції й уточнення завдань

уводяться нові рядки таблиці, які повинні вписуватися в раніше складену структуру й не

суперечити обмеженням, що накладають раніше (строки, виконавці, ресурси).

Розподіл часу й контроль над ним — призначення стовпців 2 і 3. У них вказуються

календарні дати планованого (стовпець 2) і фактичного (стовпець 3) строків виконання

роботи, завдання або завдання. Планований початок роботи — це сама рання дата, після

якої можна приступати до виконання; кінець — це граничний строк звіту виконавців

перед менеджером. Іноді графа планованих строків доповнюється критичними й

доцільними строками початку/кінця роботи. Це дозволяє менеджерові більш точно

стежити за розподілом тимчасових ресурсів. 

Стовпець 4 «Відповідальний виконавець і виконавці, ролі» задає інформацію про

те, хто працює над даним завданням, і яка кваліфікація від виконавців потрібно. Можливе

доповнення цього стовпця відомостями про те, на які періоди виділений той або інший виконавець для виконання завдання, чи передбачається підміна виконавців і т.п. В іншому, необхідність подібних доповнень свідчить про неякісний розв'язок завдання розподілу кадрових ресурсів. А от ще одне доповнення стовпця виконавців, яке часто практикують у керуванні, навпаки, досить корисно. Є через підпис усіх згаданих виконавців, що засвідчує знайомство зі змістом, строками й умовами виконання завдання.

Розподіл технічних ресурсів і завдання строків їх надання — зміст стовпця 5. Тут

вказується необхідна для виконання завдань технічна, а в ряді випадків, і програмна база.

Іноді цей розділ доповнюється відомостями про осіб, відповідальних за виконання вимог,

що вказуються. Це зручно як для менеджера, так і для відповідальних виконавців: наочно

видні порушення поставок (невідповідності між плановими й фактичними строками).

Корисним розширенням складу відомостей стовпця 5 є включення в нього інформації про

залежність робіт усередині проекту, тобто перерахування завдань (в тому числі,

посилання на інші рядки даного календарного плану), без виконання яких здійсненності

планованих робіт порушується. Відстеження залежностей робіт — це більш змістовне

завдання виконання проекту в порівнянні з тим, що можна одержати через тільки що зазначене розширення календарного плану, і їй надалі буде приділена увага. 

Схема календарного плану намагається охопити всі аспекти, які потрібно

враховувати при виділенні робіт і відстеженні строків їх виконання. Однак абсолютної точності тут добитися не вдається. Розглянуті й інші подібні розширення схеми покликано компенсувати відсутні елементи технології керування. Зокрема, вони ілюструють можливість винесення на рівень роботи з календарним планом елементи сіткового планування й оперативно використовувати їх в управлінській діяльності. Але передбачити розширення схеми так, щоб повністю задовольнити всі потреби керування в статичній картині календарного плану просто неможливо. Тому таблиця плану передбачає стовпець приміток, який заповнюється в міру необхідності у вільній формі.

Календарний план зручний у трьох відносинах. По-перше, його верхній рівень рубрикації майже в точності збігається (повинен збігатися) з тим, що становить предмет

розгляду технічного завдання на проектування. По-друге, доповнення календарного плану

новими рубриками (рядками таблиці), у тому числі, у процесі виконання проекту не

викликає труднощів. Нарешті, по-третє, він досить наочний.

У той же час, в міру поглиблення декомпозиції, календарний план має тенденцію до розростання, а, отже, обдивлятися роботи проекту в цілому стає усе сутужніше. У

результаті доводиться дублювати логічно єдиний документ, розбивати його на частині відповідно до рівнів відповідальності ієрархії працівників проекту. Інший недолік календарного плану — його непристосованість до розв'язку такого важливого завдання планування, як облік завантаженості працівників і визначення поточних потреб у перерозподілі виконавців. 

Найбільш вузьким місцем календарного плану є те, що його рубрикація найчастіше

суперечить розпараллелюванню робіт, прив'язки паралельних робіт і поставок до строків.

Важко побачити всі потрібні показники на певний момент часу, важко вирішувати інші

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

54. Мережеве планування.

Ідея всіх численних варіантів сіткового планування полягає у вибудовуванні робіт

проекту у вигляді спеціальних розмічених графів. Існує два види таких графів:

• графи, орієнтовані на події, вершини яких представляють події, що відбуваються в ході розвитку проекту (що таке “подія” визначається автором графа). Кожна дуга графа задає роботу, початок якої можливо в результаті настання події, представленого початковою вершиною дуги, а виконання якої є необхідною умовою настання події, представленого кінцевою вершиною дуги.

Сукупність усіх вхідних у вершину дуг задає необхідна й достатня умова

настання події, представленого вершиною: завершення виконання всіх робіт,

що визначають дане подію;

• графи залежностей робіт, вершини яких представляють усі роботи проекту, а

дуги – залежності робіт, обумовлені в такий спосіб. Уважається, що, якщо з

однієї вершини в іншу веде дуга, то робота, відповідна до другої вершини,

може початися тільки після завершення першої роботи, або друга робота

залежить від першої. Змістовний зміст, вкладений у поняття залежності, може

бути різним: від фактичної залежності, коли одна робота використовує

результати інший і саме тому не може початися до того, як ці результати не

будуть отримані, до примусового впорядкування робіт, наприклад, для обліку

ресурсних обмежень.

Графи першого виду зручні для всіляких розрахунків забезпеченості робіт

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

Графи другого виду спеціально пристосовані для планування часу й у цій якості

вони більш універсально застосовні. Для сіткового планування дуже більших проектів застосовують комбінація подійно-орієнтованих графових описів проекту й графів залежностей робіт. Маючи через проекти, життєві цикли яких пропонуються технологією досить строго, найбільш характерні для програмістської області, надалі обговорюються лише графи залежностей робіт, які безпосередньо пов'язані з темою даного розділу. 

Описувана далі техніка застосування графів залежностей відповідає методам, що

базуються на використанні так званих діаграм Ганта, які зображують залежності у

вигляді, добре пристосованому для планування й відстеження виконання робіт проекту.

Деяке розширення цих діаграм робиться з метою пристосувати їх до специфіки

менеджменту програмних проектів.

Граф залежностей робіт звичайно доповнюють початковою вершиною, у яку не

веде жодна дуга, і кінцевою вершиною, досяжної з будь-якої іншої вершини. чи

Приписуються конкретні роботи цим двом виділеним вершинам, не має значення,

важливо тільки те, що шляхи, що ведуть із початкової в кінцеву вершину, відбивають ті й

тільки ті послідовності робіт, які потрібно пройти при розвитку проекту. Кожний з таких

шляхів називається операційним маршрутом. З точністю до визначення відносини

залежності робіт інші припустимі послідовності робіт неможливі.

 

 

55. Визначення фінансових ресурсів.

Серед менеджерських обов'язків у підготовці до початку проекту розв'язок

фінансових завдань займає істотне місце. Коло цих завдань розпадається на три частини:

• визначення фінансових потреб,

• розподіл надаваних фінансових коштів і

• оцінка ймовірних доходів від розробки проекту.

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

фінансових потреб прямо випливає з оцінки технічних і кадрових ресурсів. 

Друга частина фінансових завдань пов'язана з визначенням пріоритетів напрямків,

по яких можуть витрачатися засобу, а також з пошуком компромісів між бажаним і

можливим (тут мова йде не про розподіл засобів у ході виконання проекту — це зовсім

інше завдання, а про планування розподілу, який повинний здійснитися, коли проект буде

розроблятися). Для розв'язку другої частини фінансових завдань знання фінансових

потреб (перша частина) використовується в якості вихідною інформацією, що дозволяє судити про гідності й недоліки проектних розв'язків для наступної розробки.

Третя частина фінансових завдань, тобто оцінка ймовірних доходів від реалізації

проекту, обов'язково виникає, коли замовника потрібно переконати в тому, що

пропонована схема розвитку проекту вигідна з фінансової точки зору (наприклад, при одержанні конкурсного замовлення). Проте, така оцінка корисна й для інших цілей, у першу чергу, для внутрішнфірмового планування. Розраховуючи ймовірні доходи, потрібно враховувати, що далеко не завжди вони є безпосередніми ( від продажу програмного виробу). У багатьох випадках доцільно планувати навіть збитковий проект (негативна безпосередня оцінка ймовірних доходів) для того, щоб замовник і/або компанія могли одержати непряму вигоду. Далеко не завжди така вигода буде виражатися в грошовому вирахуванні (відповідні приклади: підвищення кваліфікації кадрів і нагромадження досвіду, поповнення базових бібліотек компанії й ін.). Завдання обліку непрямої вигоди від реалізації проекту в загальному випадку нерозв'язна, але для деяких конкретних ситуацій можна вказати на певні підходи до проблеми.

Перш ніж перейти до більш докладного розгляду зазначених фінансових завдань

передпроектного періоду, слід зупинитися на розмежуванні обов'язків менеджера й інших

осіб компанії, що брав участь у керуванні фінансами. Є два типи фінансових питань, розв'язуваних в  компанії. Перший – це напрямку витрати й приходу засобів, які безпосередньо пов'язані з діяльністю фірми по виконанню проектів, другий — витрати, що забезпечують життєдіяльність фірми незалежно від її спеціалізації. У компетенцію менеджера входять питання тільки першого типу, а розв'язок інших питань — функція бухгалтера фірми й тих служб, які призначені для підтримки. Таким чином, формування документів із пропозиціями по фінансовій діяльності, які пропонують, регламентують або

вказують варіанти, проходить наступний цикл:

• Менеджер (або інший співробітник фірми, якщо мова йде про заходи, не

пов'язані із проектом) становить основу документа, що включає ті аспекти, які

торкаються виконання проекту (або інших заходів);

• Основа документа узгоджується зі співробітниками фірми, зацікавленими

змістом документа (зокрема, з керівництвом);

• Бухгалтер розглядає основу й при необхідності доповнює її інформацією

загального характеру ( зокрема, у його функції входить розписування засобів по

балансових статтях приходу/витрати фірми, вказівка додаткових витрат

(накладні витрати, відрахування, орендні платежі, витрата на транспорт і

зв'язок, обслуговування кредитів і т.д.);

• Результуючий документ затверджується, відкидається або відправляється на

доробку до менеджера (або іншому співробітникові), який його ініціював (на

цьому кроці можлива передача документа іншим особам).

Із цього циклу випливає, що менеджер не зобов'язано знати, які додаткові статті

витрати з'являються у зв'язку з його пропозиціями, як вони впливають на підсумкові рішення. У той же час, кошториси по договорах і рахунку, пропоновані замовникам, повинні враховувати всі види витрат. Про деяких з них менеджер може мати лише приблизна вистава. Із цієї причини будь-який документ, що зачіпає розв'язок фінансових завдань, повинен бути пред'явлений бухгалтерові компанії, який у стані визначити, як слід доповнити зміст документа. Виключення із цього правила, в іншому рідке, — внутрішнфірмові документи, які торкаються лише перерозподілу засобів, заздалегідь виділених на те або інший напрямок. Проте, навіть такі документи повинні узгоджуватися з фінансовими службами компанії, зокрема, для того, щоб вони змогли становити правильну звітність про діяльність фірми.

 

56. Фінансові потреби проекту.

При визначенні фінансових потреб показники, що задаються в ході з'ясування

технічних і кадрових ресурсів, переводяться в грошове вираження. Для кожного з таких

показників повинні бути відомі нормативи перекладу. Це або стандартизовані (зовнішні й

внутрішнфірмові) коефіцієнти, або просто ціни використовуваних у проекті товарів і

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

кваліфікаційній сітці ставок, прийнятої в компанії. Для такого співробітника доводиться вводити індивідуальний норматив перекладу погодинної зайнятості в грошове вираження.

Ціни на товари й послуги також можуть варіюватися. У цьому зв'язку

використання їх як нормативів перекладу означає не точне визначення фінансових потреб,

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

верхньої границь необхідних коштів. У практиці оцінки фінансових ресурсів  для

програмних проектів застосовуються розрахунки наступних видів:

• по мінімальній границі цін,

• по максимальній границі цін,

• по середній величині між максимальною й мінімальною ціною або 

• по середньозваженій величині.

Останній варіант використовується для більш точного обчислення, коли вдається

оцінити розподіл імовірності придбання товару або послуги залежно від рівня цін.

Становлячи мінімальну й раціональну схеми розподілу потреб, не слід уважатися,

що в мінімальній схемі витратні характеристики обов'язково повинні будуватися виходячи

з мінімальних цін (хоча й це можливо). Поняття мінімальної схеми відбиває, насамперед,

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

передбачається одержати, а з фінансовими витратами воно зв'язане вже в другу чергу.

Корисно для мінімальної й для раціональної схем визначати як верхню, так і нижню границі фінансових потреб проекту. При використанні цін, як нормативів, не можна плутати варіантність вартості однорідної продукції в різних продавців і ситуації, коли рівень ціни відбиває рівень якість товару або послуги. Приміром, більш досконале обчислювальне встаткування робить поставку дорожче, чим при використанні побутових аналогів, програмна система може працювати як у полегшеної, так і в повній конфігурації встаткування. Усі подібні якісні варіації проекту слід відзначати в документах, відбиваючи їх вплив на обсяг і якість результатів, на строки розробки.

Фінансові потреби проекту розраховуються по-різному для короткострокових і

довгострокових проектів. Це пов'язане з тим, що для тривалих проектів починає

відігравати роль інфляційний фактор, і, як наслідок, доводиться враховувати

дисконтіювання. Іншими словами, обговорюючи проектні розв'язки, необхідно оперувати

інформацією, вираженої в порівнянних цінах.

Приведення пізніх витрат до цін початкового періоду розвитку проекту

здійснюється шляхом уведення поправочного коефіцієнта дисконтіювання:

Дt = (1 + б)t,

де б – дисконт (число з інтервалу 0…1),

t – час платежу, що вказується від початку проекту.

Цей коефіцієнт показує, що сьогоднішня покупка товару за p одиниць еквівалентна

покупці його за (1 + б)t

 

* p через t років за умови збереження сьогоднішніх грошей у банку з банківським відсотком б протягом t років. Приблизно в такому співвідношенні й відбуваються інфляційні процеси. Величина коефіцієнта дисконтіювання залежить від економічної ситуації, а не умов висновку контракту. Зокрема, із цієї причини неможливо точно сказати, які строки проекту характеризують його як тривалий.

Визначаючи фінансові потреби проекту, треба чітко розмежовувати ситуації, коли

документ пред'являється замовникові й коли він залишається у внутрішнфірмовому

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

 

 

57. Розподіл фінансових ресурсів.

Як би точно не була розрахована фінансова потреба проекту, реальне життя

вносить свої корективи в апріорний план. У цьому зв'язку завдання розподілу фінансових

коштів виникає незалежно від того, якого типу проект виконується.

Як і для розподілу часу на стадії підготовки до проекту можна говорити не про

конкретний розподіл фінансових коштів, а лише про стратегію. Основне завдання тут полягає в тому, щоб забезпечити максимально швидке одержання перших результатів, тобто, маючи у виді об'єктно-орієнтований підхід, необхідно прикласти зусилля для якнайшвидшого виконання першої ітерації. Причина тут у тому, що тільки розв'язок конкретних завдань проекту ( зокрема, найближчих завдань, що є першими з них) дає підставу для пред'явлення замовникові рахунку на проведені роботи. Доти всі витрати, пов'язані із проектом носять авансовий характер.

Основою стратегії розподілу фінансових коштів служать календарний план,

сітковий графік і розраховані фінансові потреби проекту. По них менеджер становить кошторис проекту із прив'язкою витрат до строків їх проведення. Затверджений кошторис — є фіксований розподіл фінансових ресурсів. Незатверджений кошторис вимагає свого перегляду, іншими словами, перерозподілу фінансових ресурсів.

Незатвердження кошторису можливо в трьох випадках:

1. При виявленні в ній різного роду помилок;

2. При порушенні загального балансу: сумарні витрати перевищують сумарні

планові доходи;

3. При локальному (у які-небудь періоди) розбіжності надаваних засобів з

оголошеної в кошторисі потребою.

Перший випадок нецікавий для розгляду: помилки повинні бути виправлені й

процедура твердження кошторису повторений. У якості типової помилки менеджера

можна вказати на порушення нормативів витрат. Іноді таке порушення можна

обґрунтувати (наприклад, у випадку зміни цін на ринку товарів і послуг), і тоді розгляд представленої менеджером кошторису стає виправданим. А якщо ні, то менеджерові пропонується привести кошторис у відповідності прийнятими показниками.

Якщо по кошторису виходить, що сумарні витрати перевищують сумарні планові

витрати (випадок 2), то менеджер повинен спробувати пояснити керівництву причини розбіжностей і спробувати обґрунтувати запропонований варіант витрат. Якщо

обґрунтування менеджера ухвалюється, то керівництво вирішує, фірма або замовник

повинні нести додаткові (надкошторисні) витрати. Варіанти розподілу додаткових витрат,

пропонованих замовникові, можуть бути різними: оплата рахунків, включення в

підсумкові розрахунки й т.п. Коли замовник не погоджується ні на один з варіантів, те або

контракт розриває, або додаткові витрати несе фірма, або замовлення виконується в

скороченому обсязі. Якщо передбачається продовження робіт, то від менеджера потрібно

ідентифікації ситуацій, у яких проявляється розбіжність між оголошеною в новому

кошторисі потребою і спочатку виділюваних засобів. Таким чином, у зазначених умовах

випадок 2 зводиться до випадку 3 або до твердження нового кошторису.

У третьому випадку ставиться хворобливе завдання перерозподілу ресурсів, знайти

розв'язок якої необхідно менеджерові. Нижче пропонується один з можливих підходів до

перерозподілу, згідно з яким виконуються наступні кроки:

1. Виділити роботи, які можна відкласти, не порушуючи сіткового графіка

проекту (можливі зрушення часу планованого початку роботи, зміна

фактичної тривалості роботи, коли це скорочує ресурсну потребу роботи).

2. Виділити роботи, які можна відкласти, c порушенням часу виконання

проекту й за рахунок цього скоротити ресурсну потребу, як це робиться на

кроці 1. Погодити із замовником перенос строків.

3. Виділити частини операційних маршрутів сіткового графіка, що

відповідають роботи яких відносно замкнені й допускають незалежну

розробку, і оцінити їхню фінансову потребу. Визначити найбільш

ресурсномісткі з таких приватних маршрутів і результуючі роботи,

виконання яких не може бути здійснене без проходження кожного з них.

Установити й погодити із замовником, якими із цих робіт можна

пожертвувати з незначною втратою цілей, що досягаються, проекту.

4. Окремий випадок попереднього: зробити переоцінку значимості цілей, що

досягаються, і відповідають їм робіт. Можливо, у проекті надмірна увага

приділена демонстраційним завданням, підвищенню ефективності.

Можливо, що проект перевантажений за рахунок робіт, орієнтованих на

перевикористання в майбутньому. Цей список легко продовжити.

5. Виділити максимально більшу частину робіт проекту, яка здійсненна при

заданому фінансуванні.

Загальний принцип будь-якої стратегії розподілу фінансів полягає в тому, щоб

максимально повно забезпечити фінансову потребу розв'язку найближчих завдань

проекту.

 

ОКСАНА

58. Оцінка ймовірних прибутків від реалізації проекту.

Для комерційних програмних продуктів оцінка величини доходів від вкладених у розробку засобів будується на основі ряду припущень про проект, які складаються виходячи з аналізу передбачуваних ситуацій використання (Business Cases) проектованого

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

Інший аспект оцінки ймовірних доходів від реалізації проекту — це підрахунок витрат на розробку і їх рознесення на продукцію при тиражуванні. Іншими словами, виходячи з фінансової потреби самого проекту визначається, яка вартість продукту може забезпечити компенсацію витрат. Важливим моментом тут є розмежування проплат, які зобов'язується зробити замовник, і витрат, забезпечення яких бере на себе фірма. Відповідно до цієї пропорції розподіляється й майбутній дохід від реалізації. Угода про розділ продукції є однієї зі складових договори між замовником і розроблювачами. У принципі, ця угода може стати одним із критеріїв при розв'язку

питання про розміщення замовлення. Варіанти розподілу майбутнього доходу можуть бути різними: від угоди про пряме й повне фінансування й, відповідно, одержання всього доходу замовником до таких випадків, коли зовнішній замовник відсутній і фірма виконує

проект винятково для продажу. Припущення про доходи від реалізації проекту робляться на базі складання кошторису проекту, з одного боку, а з іншого — виходять із прогнозу фінансової й ринкової ситуації (який сектор ринку може зайняти розроблювальний виріб, які ціни на нього доцільно встановити і т.д.). Вони формулюються в ході передпроектной діяльності, а потім перевіряються при виконанні фази оцінки (після проходження контрольної крапки 7 «Тестування завершилося, почата підготовка нової ітерації» життєвого циклу), тобто

коли плани й досягнення можуть бути зіставлені більш точно. Кошторис і оцінка кон'юнктури ринку робляться на кожній ітерації процесу розвитку проекту. Загалом кажучи, припущення про дохід — предмет турботи замовника, але це не означає, що менеджера не повинне цікавити, яким образом вертаються інвестиції, вкладені в проект. Напроти, навіть у випадку повного фінансування, коли, видалося б,

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

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

продажів, одержуваний виготовлювачами.

 

59. Концепції розвитку проекту.

 

Головною роботою менеджера в ході підготовки до виконання проекту є вироблення концепцій його розвитку. Як правило, її результати являють собою документ, що описує загальний погляд на виконуване замовлення з погляду реалізації вимог до даного програмного виробу. Але це не план реалізації, хоча деякі розділи даного документа мають пряме відношення до планів ведення робіт, поставляють інформацію для них (наприклад, концепції можуть установити, що проект буде розбудовуватися як ітеративно нарощувана розробка протягом приблизно шести тижнів, а це — інформація для планування розподілу часу). Концепції розвитку проекту — це рамки проекту,

шаблон для побудови всіх його робочих продуктів. Вони виходять із уточненого замовлення на розробку й апріорного розподілу ресурсів. Даний документ не торкається розвитку проекту в глибину, а дає максимально широке охоплення проблем, угод і інших положень, які дозволяють розглядати його матеріали як основу критеріїв прийняття розв'язків. Так, представляючи найвищий рівень життєвого циклу розробки, він залишає осторонь питання, що стосуються декомпозиції проектних робіт. Концепції розвитку проекту природно розбиваються на дві частини:

· загальні принципи й положення — угоди, які залежать від проектного завдання лише побічно (визначають прийняту стратегію розвитку проекту);

· спеціальні принципи й положення — угоди, які визначаються специфікою проектного завдання (предметна область розробки, характер використання результатів проектування й т.п.).

Перша частина є проектно-незалежною й у принципі можливо її пере використання (включення її матеріалів у концепції різних проектів). Друга частина відбиває загальні аспекти процесу розвитку проекту, які застосовні до розв'язку завдань даної предметної області.

 

60. Загальні принципи і положення.

Дана частина Концепції розвитку проекту визначає профіль проекту — великомасштабний опис підходу до проектування: чи буде він розбудовуватися як ітеративний, послідовний або поєднувати в собі обоє підходу, і які параметри процесу проектування повинні відслідковуватися й вимірятися, як вони зв'язуються з фазами й етапами життєвого циклу. Ці загальні характеристики не залежать від специфіки проекту. Хоча конкретні значення параметрів визначаються умовами виконання завдання (наприклад, залежать від рівня кваліфікації розроблювачів) їх «ідеальні» значення можна одержати, наприклад, з попереднього досвіду. При описі профілю проекту визначаються такі параметри, як оптимальна тривалість ітерації, а також ця ж величина, скоректована для конкретних умов, етапи ітерації і їх розклад, рекомендований розподіл ресурсів по етапах. При описі загальних принципів для всіх етапів вказується наступне:

· як перевіряється коректність одержуваних результатів ( робочих продуктів етапу);

· як формуються версії робочих продуктів, яка дисципліна внесення змін у робочі продукти рекомендується, як вона контролюється;

· способи оцінки продуктивності діяльності й просування до мети етапу, а також процедура моніторингу якості робочих продуктів;

· приймання, методи, технології, а також прототипи, які використовуються в роботах етапу.

Для етапів, пов'язаних із плануванням, описується структура одержуваних робочих продуктів (планів), інструменти, застосування яких корисно для підтримки складання плану й відстеження планованих робіт. Для етапів, пов'язаних з визначенням вимог і з оперуванням на рівні специфікацій, описуються формати документальної вистави вимог, а також інструменти, що допомагають працювати з ними: витягати із проектного завдання, з аналізу предметної області й ін., сортувати, виставляючи пріоритети за різними критеріями. Крім того,

визначається, як замовник і кінцеві користувачі зможуть впливати на розвиток вимог до програмного виробу. Для етапів аналізу й конструювання специфікується нотація, застосовувана для моделювання (використовуваних ситуацій і сценаріїв, ієрархій класів і системи взаємодій і т.д.). Загалом кажучи, така нотація нейтральна стосовно проекту, але вона впливає на вибір підтримуючого інструментарію й, можливо, на навчання персоналу. Бажане, щоб для проекту використовувалася єдина нотація й загальний інструментарій, а не спеціальні

засоби на різних етапах. Обговорення впливу вибору інструментарію й, отже, методів роботи й нотації на процес проектування також корисно представити в Концепціях розвитку проекту, але воно не повинне виходити за рамки мети даного документа. Для етапу програмування специфікується використовуваний і цільовий мови. Якщо це зізнається доцільним, то описуються вимоги до генерації об'єктного коду й система інструментальної підтримки програмування. Принципи інтеграції кода також повинні бути представлені. Для етапу оцінки в Концепціях розвитку проекту передбачається опис принципів тестування й засобів підтримки тестування (генерація тестів і база даних тестів), принципів оцінки якості програмних продуктів і засобів підтримки керування якістю.

 

61. Спеціальні принципи і положення.

Ця частина Концепцій розвитку проекту представляє проект із погляду предметної області й організації ведення робіт. Вона включає опис специфічних для проекту етапів життєвого циклу, їх місце серед загальних фаз і етапів. Нові етапи можуть бути введені як

розбивка якого-небудь із існуючих етапів, наприклад, для більш якісного керування. Додаткові етапи, що поєднують інші етапи, корисні для визначення особливих контрольних крапок. Можливе виділення у вигляді етапу спеціальної роботи (наприклад, створення макетного зразка). Реорганізація життєвого циклу повинна сприяти цілеспрямованості розвитку проекту. Важливим завданням частини Концепцій розвитку проекту, що описує спеціальні принципи, є фіксація понять, позначень і термінів, загальних для проекту. При розробці

даного документа ця діяльність має на меті створення основи глосарія проекту — спеціального робочого продукту, який у міру розвитку розробки постійно поповнюється. Менеджер у праві включити в дану частину Концепцій додаткові відомості за своїм розсудом. Таке розширення змісту документа спрямоване на більш точний облік специфіки проекту при керуванні. Наприклад, деяке замовлення припускає роботи, зв'язані навчанням персоналу в замовника. Щоб організувати навчання, потрібно проведення додаткової роботи, визначення якої неможливо без відомостей про персонал (рівень кваліфікації, можливості вчитися з відривом і без відриву від роботи й ін.). Відповідно, Концепції повинні визначити принципи організаційної діяльності, її можливі варіанти.

 

 

62. Переваги розподілу принципів.

Концепції розвитку проекту — це, насамперед, звід принципів і угод, прийнятих для даного проекту. Вони розділяють загальні положення й інформацію про проект, яка ставиться до прикладної області. Користь від такого поділу зводиться до наступного:

· Документальний поділ принципів допомагає менеджерові відокремлювати загальні відомості від специфічних питань і надалі розвитку проекту;

· Загальні принципи представляють основу менеджментської методики керування проектом, і, будучи відділеними від частковостей проекту, ця методика може бути ефективно перевикористана, збагачуючись додатковими прийманнями при переході від проекту до проекту ( зрозуміло, з виправленнями на нові прикладні області). Набагато сутужніше використовувати повторно що-небудь, поки це документально не розділене;

· Концепції розвитку проекту корисно переглянути наприкінці проекту, щоб виділити те, що «працювало», а що ні, і чому. Документ, у якому загальне відділене від частки, допускає набагато більш результативне вивчення, ніж різного роду проектно-орієнтовані документи. Добре складені Концепції розвитку проекту здатні надалі охоронити від недорозуміння й пошуків обговорень, як проект повинен розбудовуватися. Документально зафіксоване продумування процесу розвитку проекту на самій ранній стадії полегшує завдання вивчення вимог до програмного виробу й приведення його засобів у відповідність реальним користувацьким потребам. Однак Концепції розвитку проекту — досить важкий документ для складання, особливо для недосвідченого менеджера. Зокрема, нелегко збалансувати угоди про користувацькі засоби з необхідною гнучкістю

розробки з погляду колективу виконавців.

63. Планування релізів.

Реліз – це варіант виробленого програмного виробу, надаваний для використання. План випуску релізів відображає вимоги до розробки в цілому в послідовність релізів,

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

Навіщо потрібний план випуску релізів? Найбільше суттєво в ньому те, що він розбиває всю сукупну роботу над проектом на групи, які реально піддаються керуванню.

Якщо не виділяти такі групи, то проект може зайти в глухий кут у зв'язку з лавиноподібним характером розвитку вимог. Наприклад, у ході аналізу прикладної

області на тому або іншому ітеративному витку може бути з'ясовано, що потрібні додаткові функції, яким у первісному плані не було приділене місце. Наявність

заздалегідь спланованих релізів може чітко вказати, до яких з них раціонально віднести ці функції. Випливає, однак, відзначити, що функції більш високих пріоритетів ( з погляду замовника) потрібно намагатися визначати до реалізації на більш ранні ітерації проекту. Таким чином, план релізів будуватися, виходячи із двох, можливо, суперечливих устремлінь:

· логіки поступального розвитку і

· важливості поступового надання засобів замовникові, якому план дає представлення про послідовність виконання вимог до продукту.

Отже, план випуску релізів повинен складатися менеджером при тісному контакті із системним архітектором, з одного боку, а з іншого - в ході змістовних консультацій із замовником. Зокрема, виділення найближчих завдань проекту, про яких уже йшла мова, - це ніщо інше, як перший реліз розроблювальної системи. І цей реліз не повинен

суперечити логіці розвитку проекту. Спільна робота менеджера, архітектора й замовника над планом релізів особливо важлива для більших проектів, коли тільки за рахунок поступовості нарощування надаваних користувачеві засобів можна добитися діючого зворотного зв'язку для коректування апріорних розв'язків. У той же час, і не дуже більші проекти, навіть такі, які передбачають лише один реліз, потребують аналітичного дослідження, що визначає угруповання й диференціацію ітерацій, інші елементи декомпозиції. По суті, незалежно від масштабів проекту план релізів задає основу загального плану проекту, погодженого з користувацькою потребою.

Із цього випливає, що план випуску релізів повинен складатися й затверджуватися якомога раніше. Фактично всі обов'язкові передпроектні роботи (складання документів

про концепції розвитку проекту й розподіл ресурсів, побудова план-графіка робіт) виходять із користувацької вистави процесу розробки як послідовності поставок — релізів

проектованого виробу. Зокрема, при складанні плану випуску релізів і його узгодженні з'ясовується, які розв'язки неприйнятні для компанії, для замовника. Якщо проблеми

виявляться нерозв'язними, то це свідчить про те, що від замовлення прийде відмовлятися, і чому раніше з'ясуються подібні обставини, тем менш хворобливим буде розрив відносин із усіх точок зору. Загалом кажучи, робота над планом випуску релізів — це відбір варіантів на основі аналізу найбільш загальних вимог, що враховує, що з того, що хочеться одержати замовникові, можна зробити найбільше скоро. Але без деталізації вимог найчастіше неможливо віддати перевагу тому або іншому варіанту. Тому план випуску релізів повинен бути відкритий для включення альтернативних варіантів, які відсіваються при деталізації на основі досвіду розвитку проекту. Доцільно робити ревізію плану релізів після завершення робіт кожної ітерації, тобто на її етапі оцінки. У цей час проводяться комплексні виміри проекту, які уточнюють попередню оцінку продуктивності виконання робіт і корисності одержуваних робочих продуктів. Отримана інформація дозволяє коректувати план релізів і зробити його більш реалістичним. Нова версія плану затверджується після появи чергового релізу. При первісному складанні плану релізів не варто намагатися занадто деталізувати його етапи, якщо немає чітких критеріїв, коли повинен минутися один етап і початися іншої. Замість цього проект просто розбивається на 8-тижневі ітерації кожного релізу, виходячи з можливостей реалізації необхідних функцій. Питання про те, які функції до якої ітерації повинні бути віднесені, зважується на основі принципу: ближче до початку проекту відносять, у першу чергу, найбільш пріоритетні функції, у другу чергу більш прості для реалізації функції. Останнє робиться з метою залишити розроблювачам час для

більш повного вивчення предметної області в ході підготовки першого релізу, а також для розв'язку організаційних питань. Щоб уникнути збоїв порушення плану випуску релізів при виконанні ітерації, не слід завершувати роботу із цим планом у ході конструювання. Якщо стає ясно, що по тем або іншим причинам робочі продукти, заплановані до випуску на даній ітерації, не можуть бути зроблені вчасно, рекомендується скористатися наступними прийманнями коректування плану:

1. Розбивка етапу – виділення в ньому тієї частини, яка може бути виконана на даній ітерації, і перенесення іншого на інші ітерації. Це робиться, коли труднощі виникають із реалізацією вісокорівневих вимог, від яких багато чого залежить;

2. Зрушення робіт – перенос запізнілого робочого продукту на наступну ітерацію зі збереженням дати закінчення ітерації. Це приймання застосовується для вимог з низьким пріоритетом, а також на ранніх ітераціях, розвантаження яких дозволяє витратити вивільнюване в розроблювачів час на додаткове вивчення предметної області;

3. Перерозподіл робіт – прискорення робіт за рахунок залучення до проекту

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

64. Управління ризиками.

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

позначає можливість ситуацій, коли проект може бути перерваний всупереч бажанню менеджера продовжувати проект. Ситуації, коли проект припиняється для менеджера, але, можливо, триває з іншим менеджером або завершується у зв'язку із причинами, на які не можна вплинути, тут не розглядаються, оскільки розумна цільова настанова менеджера — подолання ризикованої ситуації з мінімальними втратами і продовження проекту. Відповідно до цієї установки менеджер повинен ще до початку основних робіт проаналізувати, через що даний проект може бути зірваний, і зрозуміти, як він і його фірма можуть і повинні надходити, щоб виключити або хоча б мінімізувати ризики.

Зокрема, результатом такого аналізу може стати відмова від проекту. З іншого боку, ризик невиконання проекту є однією із причин, через які замовлення на розробку може бути не отриманий. Причини можливого зриву робіт досить різноманітні, вони залежать від конкретних умов і не зводяться лише до технічних аспектів. Розроблювачі повинні враховувати такі особливості ведення проекту, як технічна політика керівництв фірми й замовника, їх компетентність, їх розрахунки на удачу, з одного боку, а з іншого — кредитоспроможність, репутацію тих, хто пропонує замовлення. Ризик невиконання проекту може бути зв'язаний і зі зміною ринкової кон'юнктури. Нарешті, є чисто внутрішні причини ризиків: збої у використовуваному оточенні (програмному й технічному), неточність пропонованих вимог, ненадійність підрядників та ін. і, можливо, кадрів (не можна виключати, що прийнятий на ключову роль працівник відмовиться від контракту в самий невідповідний момент). Щоб знизити вплив ризиків на розвиток проекту, менеджер повинен розробити спеціальний план, називаний далі планом керування ризиками. Зміст цього плану — ідентифікація ризиків для даного проекту й заходу, що знижують залежність проекту від ризиків. Подолання ризиків може здійснюватися на декількох рівнях:

1. Виключення ризику. Деякі ризиковані ситуації можуть бути виключені повністю. Наприклад, щоб звільнення працівника із ключовою роллю не дуже позначилося на продовженні розвитку проекту, доцільно із самого почала запропонувати для заняття цієї ролі двох людей порівнянної кваліфікації. На початку проекту їх дискусії корисні для вироблення об'єктивних розв'язків, а якщо один з них відмовиться від контракту, другий усе ще зможе продовжувати справа. Корисні дискусії — ця та жертва, яку в ряді випадків можлива для виключення ризику. На жаль, дублювання не може бути рекомендоване для виключення всіх ризикованих ситуацій. Окремий випадок виключення ризику — перемикання його із проекту на оточення. Приміром, якщо ринкова цінність створюваного виробу видасться сумнівної, для його розробки комфортніше домовитися із замовником про авансові платежі, тим самим, змусивши його самого вирішувати завдання подолання ризику і звільнивши від цього розробників (можливо, за рахунок

зниження оплати проекту). На жаль, ця стратегія є виключенням ризику тільки для розроблювачів, але не для проекту в цілому.

2. Зменшення ризику. Якщо ризик не може бути виключений, можна постаратися зменшити його поява на практиці. Продовжуючи приклад зі звільненням працівника, для зниження ймовірності цього слід угадати причини вчинку й постаратися створити для працівника більш комфортні умови (підвищити заробітну плату, створити пільги і т.п.). Потрібно, щоб подібні розв'язки робилися не у відповідь на заяву про звільнення, а заздалегідь. Це збереже певну стабільність у колективі, яка сама по собі є методом зменшення ризику. Інший приклад зменшення ризику – оголошення ( для замовника, керівництва й колективу) про перегляд вимог, коли стає зрозумілим, що графік

виконання робіт може бути зірваний. Як і в попередньому випадку, важливим моментом тут є попередження, тобто перегляд вимог не у відповідь на

порушення графіка, а в якості превентивного заходу.

3. Попередження збитку від ризику. Коли не виходить задовільно зменшити ризик, слід підготуватися до зустрічі неприємності так, щоб мінімізувати втрати. Якщо це вдається, то продовження проекту в багатьох випадках виявляється успішним. У прикладі зі звільненням випливає якомога швидше знайти заміну даному працівникові. Природно, час виконання проекту збільшиться ( зокрема, тому що новому працівникові прийде входити в курс справи), але робота все-таки буде продовжена. Це так, але при одному умові: на всіх рівнях проектування закладена можливість відчуження результатів праці від розроблювачів. Якщо результати персоніфіковані, то труднощі підміни для деяких ролей можуть виявитися непереборними. Прикладів подібного контролю з області техніки можна привести безліч (бампери й двірники автомашин, плавкі  побіжники, що дублюють і мережі т.д.). У практиці конструювання програмного забезпечення для попередження наслідків ризику використовуються строго регламентовані технологічні приймання й методи розробки.

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

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

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

плану є резервування в основному графіку робіт часу, необхідної для входження в курс справи нового виконавця.

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

забезпечення — засобу відкоту й архівування. Для всіх ризикованих ситуацій планом керування ризиками передбачаються заходи

на зазначених рівнях у різній комбінації, можливо, доповнені більш тонкою реакцією на виникнення ризику. Деталізація такого плану може бути різної, вона залежить від

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

Дуже важливо, щоб виконавці проекту були інформовані про можливі ризики й про план керування ними. Це створює впевненість в успіху й підготовляє працівників до

подолання труднощів. Для менеджера при складанні плану найважливіше — не упустити всі можливі ризиковані ситуації.

Проект із великою часткою новацій є ризикованим підприємством завжди. Із цієї причини для нього план керування ризиками є обов'язковим і повинен бути максимально

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

організації справ і підготовленості виконавців. Аналіз ризиків у такій ситуації має на меті компенсації зовнішньої залежності за рахунок внутрішніх ресурсів. І тут план керування ризиками обов'язковий при підготовці до проекту, але в порівнянні з попереднім випадком у ньому трохи зміщаються акценти. Так, менеджер повинен передбачити дії розроблювачів, коли встаткування або зовнішнє програмне забезпечення поставляються із затримкою, коли виникають збої у фінансуванні, в інших випадках негативного зовнішнього впливу. У порівнянні із традиційним послідовним розвитком орієнтація проекту на ітеративний розвиток робить його більш стійким до ризиків, оскільки робочий продукт кожної ітерації планується не тоді, коли контекст його розробки передбачити можна лише загалом, а коли він повністю визначений. Проте, план керування ризиками доречний і тут. Очевидно, при ітеративному розвитку найбільш важливим для нього є розподіл реалізованих у проекті вимог по ітераціях так, щоб мінімізувався ризик проекту в цілому. Складання плану керування ризиками — це необхідна частина підготовки до початку проекту хоча б з тієї причини, що він впливає на розподіл ресурсів. Воно починається з фіксації й ранжирування всіх можливих ризикованих ситуацій і планованих реакцій на них. Крім того, визначаються тимчасові витрати й ціна заходів, які планується виконувати, коли ризики проявляють себе. Таким чином, план керування ризиками являє собою перелік ризикових ситуацій із планованими реакціями на них, тимчасовими витратами й витратами на їхнє проведення. Ці відомості доповнюють витратні характеристики проекту і його план-графік, тим самим, розширюючи схему фінансових і тимчасових потреб проекту. Як і в інших випадках, при плануванні керування ризиками детально розписуються ризикові ситуації початку проекту, у тому числі, для першої ітерації. Грубі оцінки й екстраполяції ризиків наступних періодів коректуються перед кожною черговою ітерацією. Інший час, коли доцільне переглянути план керування ризиками, — після виникнення ризикованої ситуації і її подолання. Як приклад того, що повинне бути передбачене, можна вказати на перерозподіл ресурсів, спочатку виділених на підтримку заходів у ризикових ситуаціях. Корисно перед коректуванням планів керування ризиками у випадку виникнення й

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

організоване, перевірити якість попередніх оцінок. Досвід, отриманий при такому аналізі, застосовується безпосередньо: при перегляді плану. Це досить важливо, оскільки ситуації, подібні тієї, яка переборена, цілком імовірно можуть повторитися в ході подальшого розвитку проекту.

Нижче приводиться перелік (далеко неповний) ситуацій, яких повинен уникати менеджер, і які він повинен ураховувати, становлячи план керування ризиками:

· затримка початку проекту ніколи не компенсується; · якщо сітковий графік виконується з більшими порушеннями строків, важко очікувати створення гарного продукту;

· якщо користувацький інтерфейс не є інтуїтивно зрозумілим і перевищує рівень компетенції споживача виробу, продукт буде погано поширюватися;

· упущені можливості вимагають додаткових зусиль при них більш пізній реалізації й збільшують витрати;

· не протестований продукт знижує репутацію розроблювачів;

· не варто розраховувати на сталість користувацьких намірів, ніколи не можна знати, що хочеться користувачеві й чого насправді йому потрібно. Як наслідок, необхідно планувати час на переробку того, що на початку проекту видалося прийнятним.

ПОНЧИК

65. Управління якістю проекту.

66. Додаткова інформація про підхід до розробки.

67. Тестування.

в якому порядку. Якщо проект вимагає спеціальних видів перевірок (наприклад, використовуваних програмно-технічних ресурсів), це також відбивається в плані.

  План тестування відповідає на запитання хто,   коли, що і як тестує в даному  проекті. Він специфікує, якого виду тести потрібно проводити для перевірки результатів, і

  Тут термін «тестування» позначає перевірку тих робочих продуктів, які визначають  код, розроблювальних (і/або використовуваних)  у проекті програм. Усі інші види

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

Для робочих продуктів, одержуваних на різних етапах життєвого циклу мети й  Роль тестування різні:

  • робочі продукти аналізу бідують твердженні замовником, щоб упевнитися в             коректності вистави про приклад ну область і про користувачів, а також утому,

      що всі вимоги враховані;

  • робочі продукти конструювання потребують перевірки їх відповідності             результатам аналізу, щоб упевнитися в тому, що обрані проектні розв'язки    забезпечують виконання всіх вимог;

• робочі продукти програмування потребують перевірки того, що  розроблювальне програмне забезпечення відповідає його проектним  специфікаціям з необхідним рівнем якості.  Навіщо потрібно тестувати проміжні робочі продукти? Відповідь на це питання  полягає у двох положеннях:

• по-перше, виявлення помилок якомога раніше дозволяє позбутися даремної  реалізації неправильних розв'язків, від використання неправильних ( а тому  перероблюваних надалі) компонентів, від обтяжних повернень до вже  пройденого;

• по-друге, легше виявити й виправити помилку не в результаті наслідків з неї, які зробили протиріччя явним, а під час її появи, коли помилка не «обростила»  багатьма зв'язками й впливами на інші компоненти програмної системи.

Конкретний план тестування може бути складений, коли готовий план ітерацій  проекту, тобто після проходження контрольної крапки 2 життєвого циклу проекту  «Загальні вимоги й загальний план складені». До цього моменту доцільно розробити  загальні положення про тестування, які служать технологічним регламентом надалі. Ці  положення фіксують наступне. Для кожної діяльності, певної в плані ітерацій, для кожної  ітерації й для проекту в цілому вказується:

• Які результати  тестуються, яким методом і як визначається, що тестування  виконане;

• Як для діяльності даного виду визначається період тестування — час, що  приділяється для тестування в плані ітерації (резиза, проекту);

• Які кадрові і технічні ресурси потрібні для кожного з періодів тестування;

• Які інструменти використовуються при тестуванні даного виду діяльності;

• Що слід вважати якістю тестування.

При плануванні тестування для проекту в цілому й для кожної ітерації  встановлюється необхідний рівень якості тестування: високий, середній і низький

(можлива та інша градація). Для його завдання використовуються відомості уточненого  замовлення і угоди з Концепцій розвитку проекту. Рівень якості тестування

неформальний показник, що відбиває яку кількість помилок, що залишилися після  проведення тестування, уважається припустимим (ураховується, що одні помилки

виправляються на поточній ітерації, а інші — у ході наступних ітерацій, можливо, у  наступних релізах). Цей показник прямо зв'язується з виділенням часу й інших ресурсів,  для проведення тестування, виконання діагностики й виправлення помилок:

• високий — вимагає виділення для тестування часу 95% і більш із сумарного  часу, відведеного для робіт даної ітерації;

• середній — для тестування потрібно від 20% до 50% із сумарного часу робіт  даної ітерації;

• низький — для тестування приділяється порядку 5% сумарного часу робіт даної  ітерації.

План тестування, що регламентує діяльність розроблювачів проекту на етапі  програмування ітерації, просто розширює тимчасові рамки робіт даного етапу — для

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

може бути проведене або в рамках поточної ітерації, або на наступних ітераціях. Який із  цих варіантів для конкретної помилки повинен бути прийнятий, визначається в рамках  спеціальної діяльності, називаною діагностикою помилки. Мети діагностики:

• указати причину помилки; 

• визначити, що треба виправити й оцінити ресурси, які необхідно виділити на  виправлення;

• установити коли виправлення буде зроблено.  З погляду розподілу ролей виконавців проекту тестувальник вирішує тільки  завдання фіксації помилок, і, загалом кажучи, залишає осторонь завдання діагностики,  розв'язок якої – функція проектувальника підсистеми й розроблювачів

68. ВИМІРЮВАННЯ.

Для розуміння ходу виконання проекту і досягнення необхідного рівня якості необхідно знати фактори, що впливають на цей процес. Ці фактори повинні бути виражені

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

успішного розвитку проекту. Вимірювані показники підрозділяються на чотири категорії:

• показники розміру — характеристики об'ємні параметри, що відбивають, проекту, його складність, а також кількісні дані про виконавців, зайнятих у

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

різні відносини: числа циклічних конструкцій, що й розгалужують, числа описів до операторів. До них відносять глибину і розгалуженість ієрархії класів середній розмір коду (число класів, модулів) на елемент функціональності або інтерфейсу та ін. Дані про виконавців – це число працівників колективу, груп, число і їх кваліфікаційний склад;

• показники продуктивності — характеристики, що відбивають продуктивність праці по категоріях працівників і індивідуальну продуктивність праці. Для кожного виконавця з урахуванням його кваліфікації, а також для кожної групи визначаються об'ємні показники й показники складності, обчислені виходячи з фактично виконаної роботи, і час розробки відповідної до частини робочого продукту ітерації, а також число порушень план-графіка, інші  подібні характеристики. Облік кваліфікації ведеться за допомогою поправочних оефіцієнтів, прийнятих для проекту в цілому;

• показники якості — характеристики, пов'язані з якістю конструювання й реалізації робочого продукту. Вони включають як традиційні показники ефективності (швидкість і вимоги до пам'ятей), так і такі показники, які відбивають якість процесу розробки: кількість зафіксовані при тестуванні помилок і трудомісткість їх виправлення, обсяг коду, що листується при налагодженні, співвідношення часів написання й налагодження, інтенсивність використання бібліотек і т.д.;

• показники перевикористання — характеристики, що відбивають можливість незалежного від даної роботи використання її результатів. До них ставляться рівень універсальності надаваних засобів

69. ЗВ'ЯЗКИ ПРОЕКТУ.

Зв'язки в проекті існують завжди. Вони підрозділяються на зовнішні (залежність  проекту від поставок, фінансування, використовуваних розробок та ін.), внутрішні  (залежність робочих продуктів проекту друг від друга). Обоє виду зв'язків є постійною  турботою менеджера, поділюваної з керівництвом фірми, лідером колективу й іншими  відповідальними працівниками. Завдання менеджера в частині відстеження зв'язків —  вказівка на реально існуючі залежності й використання їх для спрямованого розвитку  проекту, своєчасна нейтралізація небажаних впливів і впливів. Для її розв'язку необхідно  максимально повно уявляти собі взаємозв'язок процесів проекту, що розбудовується.  Найбільш простими з погляду відстеження є зовнішні зв'язки. Вони досить повно  визначаються в ході розподілу ресурсів проекту. Щоб якісно відслідковувати їх досить  явно фіксувати зв'язки, відбиваючи їх документально в якості матеріалів, що  супроводжують сітковому графіку проекту.  Здебільшого менеджер не в змозі впливати на матеріальні та  інформаційні потоки  зовнішніх зв'язків проекту. Це означає, що для критичних ситуацій залежності від  зовнішніх зв'язків менеджер повинен передбачати альтернативні шляхи розвитку проекту. Внутрішнпроектні зв'язки можна типізувати в такий спосіб: 

• залежності робіт, відбиті в сітковому графіку;

• використання загальних поділюваних ресурсів;

• зв'язки за результатами, одержуваним у ході розвитку проекту. 

Це зв'язки робочих продуктів проектування. Слід підрозділяти їх на діючі в межах  виконання однієї ітерації, що й поширюються між ітераціями зв'язки.

 

70. ПЛАНУВАННЯ ПОВТОРНОГО ВИКОРИСТАННЯ ПРОГРАМНИХ КОМПОНЕНТІВ.

Працезатрати на розробку, її вартість, час виконання й інші економічні показники  проекту дуже залежать від того, наскільки широко використані в ньому результати інших  проектів. Вони залежать також від того, наскільки широко його результати можуть бути  використані в інших проектах. Ці дві сторони перевикористання маються на увазі, коли  мова йде про планування перевикористання.   Таким чином, план перевикористання робочих продуктів описує дії  розроблювачів, які спрямовані на те, щоб у поточному проекті використовувалися  результати зовнішніх розробок, і щоб робочі продукти даного проекту можна було  використовувати максимально широко.  Для перевикористання існуючих компонентів, як зовнішніх стосовно проекту, так і  робочих продуктів, отриманих у ході проектування раніше, необхідно мати на увазі  наступне:

• Перевикористання не є вільним. Якщо розроблювачі недостатньо добре знайомі  з потенційно придатними для перевикористання компонентами, необхідно виділити час для вивчення, для оцінки трудомісткості і доцільності перенесення  наявного досвіду на поточну роботу;

• Слід планувати витрати, що виникають через перевикористання компонентів,  і зіставляти їх з вигодою для проекту. Витрати, можливо, перенесені з іншого  проекту (або ітерації) пов'язані з розробкою, розвитком, тестуванням і  підтримкою застосування перевикористовуваних компонентів.

• Потрібно розуміти, які компоненти потенційно придатні для перевикористання;

• Потрібно усвідомлювати потреби проекту. Для деяких проектів це легко: «ми  потребуємо точності в тому, що було зроблено раніше», для інших — складно:

“ми ніколи не працювали в даній області, отже, не можемо знати, у чому  реально бідуємо”;

• Перш ніж включати перевикористовуваний компонент у розробку, слід  відповісти на запитання про відповідність його поточним вимогам;  

• Включення перевикористовуваного компонента в розробку спричиняє поява  додаткової залежності проекту, яка повинна відслідковуватися. Таким чином,  необхідно поповнити документ, що відбиває проектні зв'язки, або розв'язати,  що перевикористання недоцільне (можливо, відслідковувати зв'язок сутужніше,  чим побудувати компонент заново);

• Слід виділяти розроблювачам час для вивчення можливого перевикористання.

Швидше за все, це зажадає більше часу, чим витрачається на проектування

аналогічного компонента з порівнянною трудомісткістю.

При розробці компонента, що претендує на своє перевикористання, необхідно мати  на увазі наступне:

• Не обов'язково розбудовувати перевикористовувані компоненти (класи,  бібліотеки та ін.) у рамках поточного проекту. Більше того, це може привести  до обмеження сфери застосування поточними потребами. Найкраще провести  комплексний і незалежний від проекту аналіз потенційних можливостей  компонента, очистивши його від особливостей конкретного застосування;

  • Після аналізу і конструювання може знадобитися доробка джерела  перевикористовуваного компонента, яка була б не потрібна без побудови  незалежного робочого продукту. Додаткові витрати на адаптацію його до  конкретних потреб виправдані із двох причин. По-перше, адаптація може  суттєво послабити залежність двох частин проекту й, тим самим, заощадити

зусилля на відстеження зв'язків. По-друге, вона може розглядатися як зразок,  приклад для наступних перевикористань;  

• Якщо немає часу для незалежної розробки реально перевикористовуваного  компонента, випливає, принаймні, прикласти зусилля на спеціальне оформлення  його з метою допомогти майбутнім проектам зробити це;

• Побудова перевикористовуваних компонентів збільшує вартість. Як правило,  вартість програмного забезпечення, що передбачає пері використання в три  рази більше, чим для специфічних компонентів. Хоча ця вартість може  розподілятися між декількома проектами або ітераціями, реальна вигода від  пері використання з'являється тільки після троєкратного застосування  компонента.

71. САМООРГАНІЗАЦІЯ ДІЯЛЬНОСТІ МЕНЕДЖЕРА.

Протягом розвитку програмного проекту часто трапляються неузгодженості,  упущення, несвоєчасне вирішення питань та інші промахи менеджера, дезорганізують  процес. Для скорочення подібних витрат корисно розробити систему заходів організації  праці та неухильно слідувати їй в ході всієї управлінської діяльності. Зрозуміло, що як за  формою, так і за змістом така системи завжди буде індивідуальна, і немає потреби  нав'язувати ту чи іншу схему роботи конкретній людині. Хотілося б, щоб кошти  самоорганізації діяльності менеджера відповідали його звичкам і нахилам. У той же час,  застосування їх для конкретного проекту завжди привносить свої особливості, розставляє  відповідним чином пріоритети.Отже, приступаючи до роботи над проектом, менеджер  повинен зробити ревізію використовуваної ним системи організаційної підтримки.  Нижче обговорюються специфічні моменти організації менеджерської діяльності, які  сприяють підвищенню якості управління програмним проектом. Дане обговорення не  можна розглядати як посібник з загальним методам і прийомам організації управлінської  праці - це предмет особливого вивчення. Тим не менш, представлені рекомендації можуть  виявитися корисними і в більш широкій сфері, ніж менеджмент програмних проектів.   Пропонована система заходів виходить з того, що менеджерскладає для себе список  невідкладних справ і неухильнодотримується його в роботі. Він грає роль  мережевогографіка для проекту в цілому, пристосованого до потреборганізаційної  діяльності. У список включаються роботи, що виконуються менеджером індивідуально, і  завдання, які вінповинен вирішувати, взаємодіючи з іншими розробниками, із  замовником, керівництвом, постачальниками і т.п. У нього також включаються плановані  до виконання заходи (зустрічі, переговори, оголошення та ін.) Елементи такого списку,  об'єднані спільною метою, далі називаються справою. Кожна справа має бути чітко і ясно позначено (описано). Зокрема, для всіх робіт (заходів,  зустрічей, обговорень), пов'язаних справою, вказуються необхідні в даному  проектіатрибути. Деякі корисні атрибути такого роду представлені таким переліком

  • приналежність до справи,

• розв'язувана задача або мета обговорення,

• варіанти рішень (пропозиції),

• залежність від інших робіт і справ,

• передбачуване (можливе) місце в послідовності виконуванихзаходів (до якого  моменту приступати до даної роботи(проводити захід) недоцільно, після якого -  безглуздо),

• пріоритетність в рамках даної справи (висока, середня,низька),

• запрошувані (відвідувані) для індивідуального обговоренняособи,

• особи, запрошувані для колективного обговорення,

• особи, які слід поставити до відома про прийняті рішення, і способи їх оповіщення,

• плановане і фактичний час виконання роботи (проведення заходу),

• альтернативні рішення (пропозиції),

• прийняте рішення і його відповідність завданню або мети.

 

ЩЕРБА

72. Початок проекту.

Початок проекту - це фази дослідження та аналізу здійсненності проекту. Вони

розмежовуються, насамперед, у зв'язку з тим, що при їх виконанні ставляться різні цілі,для досягнення якихзалучаються різні ресурси. У фазі дослідження увага фокусується на розумінні призначення проекту. Виконувана на цій фазі робота полягає вплануванні та координації, необхідних для підготовки вимог для керівництва. Вимоги формулюються в такому вигляді, в якому вонидоступні для загальної оцінки проекту та стратегії виконання замовлення. Зокрема,визначається, чи повинен проект бути послідовним або ітеративно нарощуємо, доцільначидля нього комбінація цих підходів. У той же час, вже ця далеко не точне формулюваннявимог повинна давати уявлення про основні моменти проектованого вироби, щодозволяють намітити план для фази конструювання.

Фаза аналізу здійсненності - це робота, пов'язана з прийняттям загальних

проектних рішень, зокрема, із затвердженням вимог.

 

73. Перехід від попереднього аналізу до першої ітерації.

В цій темі задачі менеджменту обговорюються в контексті робіт, які повинні завершувати попередній аналіз і починати итеративное нарощування можливостей програмного виробу. У традиційній послідовній схемі явно виділяється період, коли аналіз закінчується і починається конструювання; повернення до аналізу - це виправленняпомилки (з усіма наслідками, що випливають з неї наслідками). В об'єктно-орієнтованоїсхемою аналіз ніколи не закінчується, він відновлюється щоразу після оцінки ітерації.Можна сказати, що оцінка ітерації є основою для аналізу наступної ітерації. Але дляпершої ітерації такої основи не існує. Звідси випливають особливості переходу від етапуаналізу до конструювання першій ітерації, пов'язані з тим, що це час, коли змінюєтьсяточка зору на ітерацію і на проектований виріб в цілому:

замість проблемно-орієнтованих об'єктів розглядаються реалізаційні об'єкти;

моделі рівня аналізу замінюються моделями, що представляють реалізаційну

декомпозицію системи;

деякі класи, що виникають в ході аналізу, зникають, з'являються класи, специфічні

для реалізаційної середовища (наприклад, специфицируются інтерфейсні класи

звернення до баз даних);

конкретизуються і уточнюються стратегії і методики, намічені для виконання тих

чи інших робіт.

 

74. Організація колективної роботи.

Численні методи організації праці колективу, пов'язаного загальною роботою надпрограмним проектом, можна поділити на три категорії:

схеми з поділом відповідальності;

деперсоніфікованих схеми;

змішані схеми.

 

75. Схеми з розподілом відповідальності.

 

Методи першої категорії припускають, що для членів колективу виділені сфери відповідальності, які в сукупності охоплюютьвсі завдання проекту. Вони визначаються відповідно до уточненими замовленням і попереднім планом робіт. Кожна зі сфер включає завдання, тематично пов'язані з методом рішення (в якості рішень продукуютьсяоднотипні робочіпродукти), або завдання, що охоплюють розробку відособлених одиницьдекомпозиції (ітерація, програмний модуль та ін.).Часто при обговоренні організаціїколективної діяльності поняття сфери відповідальності замінюється більш змістовним дляпрограмного проекту розбивкою робіт: розробка програмного компонента, виконанняорганізаційної функції (по Гантер це планування, розробка, обслуговування, випускдокументації, випробування, підтримка та супровід).

       Для реального проекту конкретизація розподілу обов'язків, відповідна

розбиття проектних робіт в колективі (з урахуванням можливого суміщення ролей) - одназ основних задач менеджера.

 

76. Схеми з розподілом відповідальності, орієнтовані на зменшення ризику проекту.

Схеми з розділенням відповідальності не припускають від відповідальних

виконавців знання завдань суміжних сфер відповідальності, тим більше методів їх

вирішення в даному проекті за винятком випадків, коли залежності між сферами цьоговимагають (наприклад, якщо результати рішення однієї задачі використовуються длявирішення інших завдань).Знання такого роду розглядаються як порушення проектногорозподілу праці. Зрозуміло, що, якщо слідувати схемі розподілу відповідальності вчистому вигляді, то ступінь ризику проекту зростає. Тому звичайною справою при такійорганізації колективної праці є заходи, спрямовані на зниження ризиків. Досить часто дляцього застосовується так званий перехресний контроль, коли відповідальні виконавцірізних сфер перевіряють рішення один одного, досить глибоко вникаючи в завданнякожної сфери. Популярний метод підвищення надійності схем поділу відповідальності -призначення двох керівних працівників, один з яких стає головним відповідальнимвиконавцем, а інший - дублюючим експертом.

 

77. Деперсоніфікована схема.

Організація колективу за схемою з поділом відповідальності найкраще показує

себе, коли проект не несе дослідницького характеру, тобто коли на питання що і як

робити, даний конкретний менеджер може отримати відповіді досить простоі однозначно.Це й зрозуміло, оскільки такі випадки легше планувати. Високі або експериментальніпроекти вимагають,перш за все, концентрації «розумових ресурсів», а тому для них більшкращими є деперсоніфікованих схеми. Суть організації колективної праці подеперсоніфікована схемою в тому, що проектні рішення приймаються колективно(звичайно, не шляхом голосування!), Кожен учасник колективувникає в усі ключовізавдання проекту і може кваліфіковано аргументувати вибір прийнятих проектних рішень.В результаті, відповідальність за компоненти проекту поширюється на всі колективнезалежно від авторства компонентів. Зрозуміло, відповідальність за проект в цілому як іраніше лежить на менеджері. Цілком очевидно, що деперсоніфікованих схеми застосовні лише при дотриманні умов спрацьованості колективу, психологічної сумісності працівників, наявності у них загального інтересу і єдиної цільової установки на виконання

проекту з максимально високою якістю. Потрібно, щоб кожен працівник повною мірою

міг розраховувати на всіх інших. Як наслідок, дана схема застосовується тільки для дуже обмежених колективів однодумців, число членів яких дуже невелика (як правило, до десяти осіб).

 

 

78. Змішані схеми і планування організації колективної роботи.

Коли умови деперсоніфікована схеми перестають виконуватися, а таке цілком можливо, особливо якщо виникають збої в проекті, вона перестає працювати. Від

менеджера вимагається, по-перше, вчасно встановити наступ цій ситуації, а по-друге, негайно структурувати взаємини в колективі, наприклад, перейти до схеми з розділяється відповідальністю (можливо, не в такій жорсткій формі, як вона була представлена вище). Частіше за все, тут виникає змішана схема організації колективної праці, коли виділяється ядро колективу, що працює деперсоніфікованого, а в підпорядкуванні у цих працівників виявляються групи з будь-якою схемою організацією. Працівник ядра може займати будь-яку з керівних ролей в проекті, але якщо у нього в підпорядкуванні є група, то по відношенню до неї він виступає в ролі менеджера явного чи неявного (неоформленого офіційно) проекта. Взагалі, змішана схема - це ієрархічний розподіл менеджерських завдань за групами виконавців, у яких складається самостійна організація колективної діяльності. З даного визначення випливає, що можливі різні змішані схеми, будь-яка з них відображає деяку ієрархію взаємин в колективі. На рис. 5.4 зображений один з прикладів розподілу відповідальності за змішаною схемою, що відображає дворівневу ієрархію.

 

ЯЦКІВ

79. Локальні взаємодії в колективі і ухвалення рішень.

Тип організації колективу - це форма роботи зі співробітниками для проекту в

цілому. Інша сторона колективної діяльності - локальні взаємодії працівників.Попросту

кажучи, локальні взаємодії - це спілкування співробітників, цілі якого пов'язані із

з'ясуванням того, що і як треба робити, що і як з результатів колег треба використовувати,

які зв'язки в проекті впливають на роботу, а також багато чого іншого, без чого проект не

міг б розвиватися. Більшість відомостей такого роду з'ясовується з документів, одна з

Всі задачі проекту

Рис. 5.4. Приклад розподілу відповідальності за змішаною схемою

Сфера відп. 1 Сфера відп. 2 Сфера відп. n

головних функцій яких - мінімізація неформальних і не протоколюються контактів. Проте

абсолютно очевидно, що зовсім без контактів між розробниками не обійтися. Стосовно до

діяльності менеджера корисно обговорити контакти, які націлені на прийняття проектних

рішень та доведення їх до відомостей співробітників. Іншими словами, потрібно

представити рекомендації, що відповідають на наступне питання: як повинні бути

організовані контакти в колективі розробників, щоб проектні рішення приймалися точно,

коректно розумілися розробниками і виконувалися з максимальним ефектом. Решта

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

їх в змістовному плані не слід применшувати.

 

80. Принципи контактних заходів.

Мозковий штурм - лише одне із застосовуваних у практиці управління

організаційних заходів, пов'язаних з контактами розробником, правда, дуже специфічне, а

тому потребує жорсткого регламенту проведення. Інші заходи: наради,колективні та

індивідуальні обговорення, бесіди, звіти виконавців робіт та їх обговорення і т.п. -

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

використання необхідно керуватися загальними іспеціальними принципами. До загальних,

незалежних від контактного заходи принципам, відносяться:

цілеспрямованість

планування

упорядкованість

стислість

переконливість

результативність

ставлення до традицій і стереотипів

дотримання етичних норм поведінки

81. Непланові взаємини в колективі.

До цих пір розглядалися відносини в колективі, які складалися в зв'язку проектом. Ці відносини направляються діяльністю менеджера, плануються так, щоб сприяти успішному розвитку проекту. На жаль, далеко не всі контакти в групі виконавців проекту

зводяться до таких відносин. Колектив - відкрита система, зовнішні впливи на яку відірають набагато більшу роль у формуванні взаємовідносин, ніж спрямовані зусилля керівництва фірми, менеджера. Якщо взаємини, що формуються під впливом зовнішніх

впливів, не суперечать цілям розвитку проекту, то є велика спокуса не помічати їх і не враховувати при організації робіт. Однак час і умови роботи, індивідуальні цілі працівника і індивідуальні вимоги до організації робочого місця, інші зовнішні по відношенню до проекту обставини не тільки ставлять рамки, в межах яких можна ефективно використовувати людини, але і безпосередньо впливають на те, що і як в змозі робити даний виконавець. І якщо менеджер при організації колективної роботи ігнорує обставини, які неможливо планувати, то ймовірність ризику невиконання проекту підвищується. Непланові взаємини проявляють себе як для нового колективу, так і для усталених груп. У першому випадку вони стихійно формуються в колективі, у другому - згладжуються за рахунок усвідомленого чи ні обліку індивідуальності працівників.Якщо в колективі визначено лідер, то саме на нього лягає весь тягар відповідальності за мінімізацію небажаних і підтримку корисних непланових взаємин. Останнє істотно, тому що відсутність уваги до корисних зв'язків між співробітниками дискомфортно і, в кінцевому підсумку, може призвести до появи небажаних взаємин.

 

 

82. Перша ітерація: метод "Спочатку в глибину".

Типові особливості першої ітерації полягають у тому, що вона починає розробку нового проекту силами колективу, який часто також є новим, далеко не завжди володіє навичками об'єктно-орієнтованого підходу і не в повній мірі володіють інформацією про прикладну області. Отже, як правило, розвиток проекту в цей період вимагає особливого підходу. У даному розділі описується метод розробки програмних проектів, рекомендований для застосування на перших ітераціях. Він представлений як сукупність відповідних робіт, виконання яких має організувати менеджер, але без явного виділення менеджерських функцій. Завдання менеджера в зв'язку із застосуванням даного методу розглядаються в рамках обговорення підходу в спеціальному розділі

 

83. Мотивація особливого підходу до виконання першої ітерації.

Ітеративний нарощування як технологічний підхід до розробки програмних проектів має ряд переваг у порівнянні зі строго послідовним розвитком. Ці переваги вже не раз відзначалися і обговорювалися. Але в рамках даного підходу в межах однієї ітерації процес розвитку проекту залишається послідовним і зберігає недоліки традиційних технологій, нехай навіть редуковані. Планування, визначення вимог і аналіз, конструювання, програмування, тестування і оцінка слідують один за одним протягом

ітерації, яка може тривати, приміром, п'ять або шість місяців. Ризик проектів зростає, якщо багато хто з розробників використовують об'єктно-оріен ти ро ван ву технологію вперше. Ці недоліки в більшій мірі проявляють себе на початкових ітераціях,

коли дуже велика невизначеність проекту, коли не вистачає критеріїв переваги одних рішень перед іншими. Таким чином, для початкового періоду розвитку проекту потрібна спеціальна методика, що дозволяє мінімізувати ризики проекту в умовах невизначеності. Нижче розвивається підхід, повчитися назву “Спочатку в глибину” (Depth-First), суть якого в заміні початкового ітеративного нарощування серією коротких міні-циклів, можливо, не в повній мірі забезпечують необхідну користувачам закінчену

функціональність.Ці міні-цикли складаються так, щоб забезпечувався візуальний контроль отриманих результатів. При такому підході досить швидко накопичується досвід розробки. «Спочатку в глибину» - це всього лише різновид нормального ітеративного

нарощування, характерним властивістю якого є швидке отримання відчутних результатів нехай навіть на шкоду функціональності. Протилежний підхід, надалі званий “Спочатку в ширину” (Depth-First), характеризується спрямованістю на побудову закінченою

функціональності на ітерації. Якщо вимоги до проекту визначені точно і розробники володіють методами об'єктно-орієнтованого проектування досить добре, прикладна область відома, то немає потреби вдаватися до підходу “Спочатку в глибину”. Однак в

іншому випадку можливі серйозні проблеми розвитку проекту. Ілюстрацією цього є наступні два приклади. Перший з них пов'язаний з труднощами переходу від аналізу до конструювання, другий - з конструюванням. Якщо предметна область недостатньо

вивчена, то рішення про те, які з ситуацій використання повинні бути автоматизовані на даній ітерації, які з відкладені до наступних ітерацій або зовсім не вимагають підтримки, не може бути точно обгрунтованим. Коли у розробників немає критерію, закінчити аналіз

або продовжити його, виникає ситуація глухого кута аналізу. Можлива аналогічна ситуація глухого кута конструювання, коли у розробників немає критерію, що дозволяє питання про необхідний і достатній рівні деталізації опису декомпозиції

 

84. Етап І: початкове моделювання.

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

розглядаються в якості базових класів для даної області для всього проекту.Найчастіше базові класи безпосередньо виводяться з ключових сценаріїв, які направляють подальший розвиток проекту. Підкласи цих базових класів, можуть включатися в початкову модель, але зовсім не обов'язково це робити для всіх з них. Приміром, у реалізації електронного магазину ключовим класом є Баланс, тоді як такі його підкласу, як Поточний рахунок, Залишок на рахунку та інше, не є ключовими, хоча, можливо, деякі з них включаються в початкову модель. Основні роботи етапу:

Стратегія

Моделювання ситуацій використання

Динамічне моделювання для аналізу взаємодій об'єктів

Об'єктне моделювання

Огляд результатів аналізу

Особливості управління проектом на етапі початкового моделювання.

 

85. Етап II: моделювання рівня об'єктно-орієнтованого конструювання.

Отримане на попередньому етапі розуміння обмеженого числа класів і взаємодій об'єктів цих класів дозволяє перейти до конструювання точних визначень взаємодій об'єктів у системі. Завдання конструювання, пов'язані з чергового етапу, зводяться до

наступного. Основні роботи етапу:

Стратегія: на базі проведеного аналізу зробити виділення основних компонентів системи для конструювання та програмування. Ці компоненти будуть визначати проект в цілому;

Розробка архітектури. Структурні компоненти системи, конструкторські заготовки, шаблони, процеси та алгоритми готуються з тим розрахунком, щоб вони реалізовували кошти, необхідні для реалізації виділених на попередньому етапі моделей. Структура системи, конструюється на даному етапі, є лише попереднє архітектурне рішення. Надалі вона буде розвиватися в ході нарощування надаються системою засобів. Тут же важливо виключити надмірне конструювання Учасників більше з тим, щоб можна було просуватися до наступних етапів;

Об'єктне моделювання. Об'єктна модель рівня аналізу перетвориться в об'єктну модель рівня конструювання шляхом завдання зв'язків між об'єктами і явних спрямованих асоціацій. Необхідно простежити всі можливі взаємодії об'єктів. На цьому рівні породжуються:

- діаграми класів,

- специфікації класів, які в подальших роботах даного етапу уточнюються;

Динамічне моделювання. Діаграми, побудовані на попередньому етапі, перетворюються в діаграми рівня конструювання. Зазвичай це перетворення полягає в доповненні набору класів і інших сутностей відповідно до об'єктно моделлю. В ході перетворення проявляють себе багато деталей рівня конструювання, які повинні бути відображені на діаграмах класів і в їх специфікаціях;

Опис методів і класів. В ході динамічного моделювання специфікації методів можуть бути безпосередньо виведені з OID-діаграм. Ця інформація документується у вигляді мовних описів класів. Створювані опису доповнюються новими атрибутами і

зв'язками. Якщо передбачено використання відповідного інструментарію, то на цьому рівні можуть породжуватися заготовки програмних компонентів (так звані default-реалізації); Затвердження моделі та міні-нарощування. Об'єктна модель рівня конструювання обговорюється з метою з'ясування її відповідності OID-діаграм. Розбіжності ліквідуються шляхом доповнення об'єктної моделі. Тим самим, відбувається міні- нарощування засобів системи на рівні конструювання, спрямоване на узгодження

майбутньої реалізації вимогам, пов'язаним з виділеною для першої ітерації частиною системи;

Ітеративне повернення до аналізу. В ході утвердження моделі саме час для перевірки коректності розмежування аналізу та конструювання. Зокрема, робочі продукти періоду аналізу не повинні стосуватися конструкторських рішень. Якщо

при перевірці подібні порушення виявляються, вони повинні бути відразу ж ліквідовані;

Огляд результатів конструювання. Результати конструювання відображаються в огляді, основне призначення якого - перевірка адекватності обраної стратегії завдань, що вирішуються на першій ітерації;

Особливості управління проектом на етапі початкового конструювання. Час, який слід виділити на проведення етапу, становить приблизно сімдесять відсотків від терміну виконання всієї ітерації.

 

 

ГОЛОВАТИЙ

86. Етап III: швидке програмування.

Використання моделей, побудованих на попередньому етапі, дозволяє безпосередньо перейти до програмування класів системних об'єктів.

Основні роботи етапу:          

 Побудова коду. Код, який повинен бути побудований, є вихідною точкою зростання системи в цілому. Остаточний продукт - його розширення. Код, що створюється на даному етапі, - переробляється результат, тому що не виключається його переробка, коли будуть отримані більш повні відомості про прикладну області і додатковий досвід. При побудові коду на даному етапі розробники освоюють кошти оточення створюваного програмного вироби, засоби підтримки конструювання користувальницького інтерфейсу, програмні інтерфейси застосовуються систем. Відповідно до підходом ”Спочатку в глибину” час, що відводиться для початкового кодування, не дуже велике. Тому можна опустити реалізацію непринципових аспектів поведінки деяких об'єктів або зробити їх спрощені версії (наприклад, залишити їх у вигляді default-реалізації);

 Збірка та тестування. Збірка запрограмованих компонентів дає можливість побачити, якою мірою розвивається система задовольняє реалізованої частини

вимог. Тестування зачіпає перевірку тільки тих сценаріїв, які були обрані для реалізації;

 Запобігання від ризиків. Швидке кодування само по собі є одним з методів управління ризиками. На додаток до цього - особлива увага до реалізації  зуалізації результатів виконання програми, щоб помітити порушення можна було б безпосередньо;

 Демонстрація системи та встановлення зворотного зв'язку. Рання зворотній зв'язок може встановлюватися при експериментальному використанні напрацьованої частини системи. За рахунок неї перевіряється, з одного боку, як використовуються оточення і бібліотеки, а з іншого – на скільки даний код може задовольнити очікування користувачів. Інформація такого роду виходить при демонстрації роботи системи;

 Огляд написаного коду. Якщо в ході реалізації програмних компонентів передбачається складання опису того, що зроблено, то це сприяє накопиченню

колективного досвіду розробників. Користь від таких описів особливо помітна для початківців працівників;

Особливості управління проектом на етапі швидкого програмування. Час виконанняцього етапу становить від десяти до п'ятнадцяти відсотків від часу

побудови першої ітерації.

 

87. Етап IV : ітеративне нарощування можливостей.

Коли виконується код для підтримки ключових сценаріїв готовий, можна переходити до розгляду нарощування можливостей першій ітерації до рівня робочого продукту. Етап ітеративного нарощування має дві особливості. По-перше, він може розщеплюватися на  кілька підетапів з подібним змістом робіт. Ця ситуація виникає, коли проходження одного міні-циклу не дає підстав для повної впевненості, що метод освоєний і/або прикладна область достатньо вивчена. Розщеплення закінчується, коли розробка чергового міні циклу в своєму розвитку приходить до цього етапу, і є можливість отримати повнокомплектних робочий продукт ітерації в цілому. По-друге, етап включає роботи, які можна охарактеризувати як ревізію результатів міні-циклів. Це означає додаток етапу оціночними роботами.  Основні роботи етапу:

 Розробка та переробка архітектури. В рамках даного етапу доцільно зайнятися архітектурою системи в цілому. Спочатку слід визначити правила та угоди

архітектурного характеру. Потім визначається структура системи на основі головного архітектурного рішення, обраних конструкторських заготовок і шаблонів

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

зокрема, з використанням результатів статичного і динамічного моделювання;  

 Додавання вимог. За допомогою аналізу вимог, запропонованих для реалізації в даному проекті, з'ясовується, які ситуації використання і сценарії можна додати в якості реалізації нарощування можливостей ітерації. Для них проводиться OIDаналіз і, коли досягається відповідне розуміння, розробляється рівень

конструювання;

Виконання ітерації. Отримавши досвід швидкого просування від аналізу до конструювання і кодування, колектив розробників відчуває себе впевненіше, ніж на

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

розділяються. Після цього можна додавати чергову порцію нових класів і сценаріїв і продовжити динамічне моделювання на рівнях аналізу та конструювання. Кожне таке розширення вимагає коригування діаграм взаємодії об'єктів;

Робочі продукти. В кінці цього етапу інтерфейси класів виявляються певними досить точно. Це дозволяє побудувати програми для всіх робочих продуктів,

намічених до реалізації на даному етапі;

   Огляд конструювання. Основне призначення огляду на цьому етапі – узгодження   відомостей, що надаються клієнтам, і оцінок першої ітерації аналітиками, проектувальниками та розробниками. При складанні огляду стає остаточно зрозумілим доцільне розподіл ролей в колективі, і якщо воно відрізняється від фактичного розподілу, то менеджеру належить виконати відповідні перестановки;

 Особливості управління проектом. Зазвичай закінчення даного етапу відзначається в

плані проекту як завершення конструювання засобів першої ітерації. Отже, все розщеплення до цього терміну повинні бути завершені. Фактично етап повинен

займати від десяти до п'ятнадцяти відсотків часу виконання першої ітерації. Якщо спостерігається розбіжність фактичних і планових термінів, то це свідчить про

доцільність коригування попередньо складених планів.

88. Етап V : низькорівневе проектування.

Цей етап особливий в процесі розвитку проекту, що відрізняється від конструювання своєю спрямованістю на вивчення засобів оточення і мови реалізації з точки зору використання їх в розробці. Роботи етапу виходять як з конструкторських потреб, заданих попереднім етапом, так і з досвіду початкового програмування, отриманого на етапі швидкого програмування. Зміст робіт етапу - визначення і терфейсів класів для всіх головних областей проекту, особливо для тих областей, які надають спільні кошти нижнього рівня. Четвертий і п'ятий етапи можуть розроблятися паралельно, оскільки чітку межу між ними провести важко. 

Основні роботи етапу:

 Задачі низькорівневого проектування. Маючи результати всебічного проектування  високого рівня, можна приступати до розробки основних низькорівневих проектних рішень. Це завдання всіх розробників, які відповідають за ті чи інші програмні компоненти системи. Кожен з них вирішує задачу проектування нижнього рівня для своїх модулів. Протягом усього етапу запропоновані рішення обговорюються в тій мірі, в якій це сприяє повної ясності порушених проблем;

 Робочі продукти даного етапу ті ж, що і для четвертого етапу за винятком класів, що відносяться до областей високого рівня;

 Виконання ітерацій. Можливо багаторазове повторення конструювання та програмування з метою виявлення варіантів проектних рішень і вибору кращого з

них;

 

 

89. Етап VI: програмування і зборка першої ітерації.

 Тестування програмних компонентів. Обговорюваний етап не може бути завершений без тестування і, зокрема, без тестування програмних

компонентів.Розумно пов'язувати цю роботу з класами. Тестування компонентів передує складанню огляду кодування, а також перевірці функціональності;

 Зборка. В ході виконання попередніх робіт створюване програмне забезпечення виявляється представленим набором пов'язаних один з одним компонентів. Ряд реалізацій класів буде існувати в декількох варіантах; варіантність реалізацій обумовлена різними режимами можливого використання компонентів

(налагоджувальний і кінцевий варіанти, варіанти з різними рівнями ефективності та ін.). Працездатна система - це одна з можливих конфігурацій, що збираються для тих чи інших цілей. Змістом даної роботи є реалізація засобів управління збіркою системи. При її виконанні необхідно контролювати, що управління ніколи не порушує базову архітектуру системи, побудовану відповідно до OID-аналізом. Результати цієї роботи використовуються в ході виконання перевірок та тестування;

 Перевірка функціональності (FVT - від Function Validation Testing). Корисно передбачити час для попередньої перевірки розробляється програмного вироби (так

зване, альфа-тестування). На даному етапі метою перевірки є не тільки отримання думок про систему (якість, працездатність тощо), але і як можна більш раннє

встановлення зворотного зв'язку з користувачами;  

 Особливості управління проектом. Етап займає від п'ятдесяти до шістдесяти відсотків часу розробки першої ітерації. Відведений час поділяється наступним

чином: сорок відсотків відводиться для робіт, пов'язаних з програмуванням і тестуванням компонентів, і до двадцяти відсотків - для реалізації настроюваної

збірки і проведення перевірки функціональності.

 

90. Етап VII: оцінка ітерації.

 

 Призначення робіт етапу - розглядом отримання результатів в контексті проекту в цілому. Оцінюються як робочі продукти ітерації, так і процес розробки. З'ясовується, як відповідають отримані результати цілям ітерації, як вирішується завдання перевикористання.   При оцінці програмних робочих продуктів перевіряється їх коректність і задовільному з точки зору вимог, визначається якість реалізації сценаріїв, з'ясовується відповідність побудованої (або добудованій) системи класів моделям, аналізується інформація про ефективність. Оцінка документних робочих продуктів полягає в з'ясуванні того, якою мірою вони сприяють якісному виконанню проекту.Оцінка процесу розробки полягає у виявленні та аналізі всіх випадків відхилення від планів робіт: порушення строків, перевитрата ресурсів та інші, а також у зіставленні вимірюваних показників з їх очікуваними значеннями. Оціночні роботи проводяться узгоджено з планом управління якістю.

Основні роботи етапу:

 Випробування системи та аналіз використання. Оцінюються результати перевірки функціональності з точки зору майбутніх робіт. Виявляються помилки, які повинні бути виправлені в рамках даної ітерації, ситуації використання і сценарії, які плануються для реалізації на наступних ітераціях;

 Проведення експертизи. Збираються відомості про використання робочих продуктів, отриманих на даній ітерації і про процес виконання ітерації;

 Вимірювання. Визначаються заплановані для вимірювання показники розміру, продуктивності, якості та переіспользуемості. Отримані значення зіставляються з апріорними значеннями;  

 Коректування робочих продуктів. Виправляються помилки програмних компонентів, модифікуються плани та інші документальні робочі продукти на основі інформації, отриманої в ході проведення робіт, зазначених вище;

 Організація перевикористання. Отримані робочі продукти вивчаються з точки зору можливості їх повторного використання в цьому проекті і в інших розробках. Якщо для перевикористання потрібно спеціальне оформлення матеріалів і інші модифікації робочих продуктів, то ці дії виконуються або плануються для виконання на наступних ітераціях;

 Реорганізаційні заходи. Якщо виявлені помилкові рішення в розподілі ролей виконавців, в організації робіт та інших аспектах виконання ітерації, то виробляються заходи, що виправляють ці рішення;

 Огляд виконання ітерації. Етап оцінки супроводжується складанням документа, в якому підбиваються підсумки: фіксуються результати і намічаються перспективи подальшого розвитку проекту;  

 Особливості управління проектом. Етап займає до п'яти відсотків часу розробки першої ітерації. Якщо фактично потрібно більше часу, то це означає помилки в плануванні більш ранніх робіт, які необхідно виявити і усунути.

 

 

91. Обговорення методу.

Підхід “Спочатку в глибину” є різновидом звичайного ітеративного нарощування, застосовуваного, коли потрібно швидше зануритися в проект. В цьому полягає основне його гідність. Коли немає потреби спеціально вивчати область додатка системи і методи об'єктно-орієнтованого програмування, протилежний підхід “Спочатку в ширину” (DepthFirst), спрямований на побудову закінченою функціональності на кожній ітерації виявляється переважніше, оскільки комплексний аналіз і повне моделювання використання системи дають можливість побудуватипрацездатну архітектуру системи без переробок і дублювання. Найефективніше при використанні методу “Спочатку в глибину” колективну роботу організовувати спочатку по деперсоніфікована схемою (див. п. 5.1.3), а

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

 колективне обговорення результатів виконання індивідуальних завдань, доручених розробникам;

 затвердження ключових проектних рішень менеджером тільки за результатами їх колективних обговорень;

 виділення коротких строків для контролю виконуваних завдань;

 регулярна звітність та оповіщення групи про виконані роботи.

 

В ході колективних обговорень кожен з розробників отримує можливість дізнатися всі аспекти робіт міні-циклів, впливати на них, поправляючи і доповнюючи колег по проекту. Саме такі обговорення дають менеджеру об'єктивну інформацію для розподілу ролей між розробниками. Той, у кого краще виходить певний тип роботи (більше швидке виконання, менше коректив вимагають одержувані результати і т.п.) поступово починає виконувати всі або більшість робіт даного типу. У міру переходу до такої спеціалізації цей працівник отримує більше свободи, відповідно знижується необхідність детального контролю.

 Найбільш відчутним прогрес спеціалізації розробників виявляється на етапах аналізу і моделювання та при підготовці оглядових матеріалів. Для етапів, пов'язаних з програмуванням, ефективність колективних обговорень як засобу отримання відомостей про працівників значно нижче. Тут більш доречна оцінка отриманих результатів по їх використанню, і, як наслідок, програмістську спеціалізацію працівників найкраще

визначати при переході на новий міні-цикл. Дуже важлива для продуктивної роботи особливість деперсоніфікована схеми - це можливість неформальних контактів працівників, які не потребують спеціального введення в курс справи один одного. Одні працівники вступають у такі контакти епізодично, для інших вони стають невід'ємною становить виконання завдань. В одних контактах працівники виступають рівноправно, в

інших - явно виділяються ведучі та ведені. Варто відстежувати такі контакти для

розмежування працівників-виконавців і потенційних керівників, для визначення

сумісності та несумісності працівників, а також для направлення неформальних

обговорень в конструктивне русло. В цьому відношенні як не можна краще підходить

лідер колективу, якому і легше, і природніше спостерігати за неформальними

контактами.Але й тоді, коли менеджеру доводиться брати на себе функції лідера, не варто

забувати про контакти, оскільки в умовах деперсоніфікованих схем саме вони багато в

чому визначають ефективність роботи колективу.

 Положення про неформальні контакті є загальними для деперсоніфікована схеми -

вони безпосередньо не пов'язані з методом “Спочатку в глибину”. Але і тут

продуктивність методу багато в чому визначається тим, на скільки добре використовувати

неформальні контакти. Переваги обговорюваного методу для розробки не дуже чітко

визначених проектів досить очевидні. Однак є суттєве обмеження на його застосування.

Метод “Спочатку в глибину” виявляється ефективним лише для невеликих робочих груп.

Мабуть, великі проекти, які вимагають залучення великих колективів, виявляються

здійсненними лише за умови достатньо високого рівня кваліфікації працівників. Тим не

менш, якщо вдається виділити відносно незалежні та відокремлені завдання великого

проекту, то для таких підсистем метод “Спочатку в глибину” цілком можна

рекомендувати.

Запропонований метод не є жорстко регламентованим. Як вибір сценаріїв для мініциклів,

так і кількість міні-циклів, прохідних в рамках реалізації першої ітерації

практично не обмежені. Єдина умова успішного застосування підходу “Спочатку в

глибину” - це наочність отриманих результатів. Якщо воно порушене, то переваги підходу

зникають.

 

З самого призначення методу “Спочатку в глибину” випливає, що його використання

як прототипу виконання ітеративного нарощування надалі, відрізняється від загального

випадку лише кількісно. Мається на увазі, по-перше, обмеження на обсяг реалізованих

вимог на міні-циклах, а по-друге, збільшена у порівнянні з наступним періодом роль

аналітичних та оціночних робіт.

 

92. Менеджмент в ході виконання першої ітерації.

У період, що передує виконанню першої ітерації, діяльність менеджера переважно

пов'язана з плануванням. Подальша його робота - це, в основному, реалізація планів.

Зрозуміло, поточне планування, а також планування подальших ітерацій не повинні

випадати з поля зору менеджера і тоді, коли колектив приступає до роботи над итерацией,

але тепер ця діяльність набуває два нових якості. Тепер планування:

 виконується на тлі управління колективною роботою і

 починає залежати від додаткового параметра: від інформації про перебіг виконання

робіт.

Постійний зворотний зв'язок змушує коригувати не тільки поточні рішення і

розпорядження, а також і майбутні плани. Для менеджера важливо своєчасно вловлювати

мінливу обстановку і реагувати на зміни. Це один з елементів управління. Але, аналізуючи

зміни потрібно робити висновки, спрямовані в майбутнє: що з неврахованого при

виробленні стратегічних планів є минущим і суб'єктивним, а що залишається в якості

постійно діючих факторів, що впливають на виробництво системи. Ця інформація -

джерело корекції планів. Цикл управління при розробці проекту досить очевидний. Він

включає постановку задачі (видачу завдання), виділення ресурсів і вказівка контрольних

термінів (проміжних і остаточних). Стосовно до менеджерської діяльності, цикл

управління - це заходи в контрольних точках, мета яких в тому, щоб впевнитися, що

виконання завдання йде за планом. Якщо з'ясовується, що це не так, надається допомога:

перерозподіляються технічні та кадрові ресурси на користь відстає роботи,

встановлюються додаткові контрольні терміни і т.п. Як небажаних, але іноді необхідних

заходів слід вказати на зміну виконавців та/або зсув призначених термінів закінчення

роботи. Це загальні положення, що стосуються циклу управління всіх стадій розвитку

проекту.

Відмінною особливістю циклу управління в ході робіт над першою итерацией є

можливість розглядати зміну виконавців та/або зсув термінів не як небажані заходи, а в

якості виправданих дій для визначення оптимальної розстановки кадрів і для коригування

апріорних рішень і планів. Швидке отримання результатів дає підставу вважати, що така

мобільність управління буде в кінцевому підсумку виправданою.

 

ЛЮДКЕВИЧ

93. Особливості планування і управління.

Управління проектами — область знань з планування, організації та управління ресурсами з метою успішного досягнення цілей та завершення завдань проекту. Іноді ототожнюється з управлінням програмами, але програма — це фактично більший високий рівень: група пов'язаних та взаємозалежних проектів.

Проект — це обмежений часовими рамками процес, що має визначений початок та кінець, зазвичай обмежений датою, але також може обмежуватися фінансуванням або досягненням результатів[1], який здійснюється для реалізації унікальних цілей та завдань[2], зазвичай, щоб призвести до вигідних змін або створення доданої вартості. Тимчасова природа проектів контрастує з бізнесом (процесами) [3], які є повторюваною, постійною або частково постійною діяльністю з виробництва продуктів або послуг. На практиці, управління вищезазначеними двома системами часто різниться і таким чином вимагає розвитку окремих технічних навичок та використання розподіленого управління ними.

Головним завданням проектного управління є досягнення всіх цілей[4] та виконання завдань проекту, одночасно виконуючи зобов'язання щодо наперед визначених обмежень проекту.[5] Типовими обмеженнями є межі та зміст проекту, час, бюджет.[1] Другорядним завданням, але амбіційнішим, є оптимізація, розподілення та інтеграція завдань, необхідних для досягнення наперед визначених цілей.

94. Взаємини із замовником, листування.

Управління та планування - це діяльність менеджера, з виконання його внутрішніх

функцій. На першій ітерації розвиваються і зовнішні функції менеджера, тобто

взаємовідносини із замовником. Вони набувають нову якість в порівнянні з попереднім

періодом. Раніше менеджер вступав в контакти з замовником одноосібно (епізодичні

зовнішні контакти керівництва фірми, як правило, впливають на зміст проекту і лише

трохи на методи його розробки). Він вирішував задачі уточнення замовлення. Тепер же

зовнішня задача змінюється. Менеджер повинен:

· добиватися максимально швидкого подолання розбіжностей, протиріч та інших

перешкод на шляху розвитку проекту, які виявляються по ходу справи;

· забезпечувати отримання всієї необхідної для ведення проекту інформації;

· організовувати приймально-здавальні заходи тих робочих продуктів, які вимагають

цього;

· добиватися максимально швидкого і повного відшкодування витрачених ресурсів

(необхідно знати, коли і за що слід виставляти рахунки для оплати).

Цілком можливо передати частину повноважень по контактах із замовником

деяким виконавцям. Це розвантажує менеджера, позбавляє його від необхідності

вирішувати окремі поточні питання, які потребують спеціального погодження. Але в

такому випадку необхідно встановити сувору дисципліну контактів із замовником.

Зокрема, і менеджер, і виконавці повинні знати, хто і з яких приводів має право звертатися

до замовника, повідомляти йому щось чи питати про що-небудь. Якщо у виконавця

виникає потреба вийти за межі свого регламенту, він зобов'язаний діяти через менеджера,

який вирішує, розширити права виконавця, призначити посередника або самому

виступити посередником.

Навіть при неформальних контактах із замовником, таких як спільний відпочинок,

неділові зустрічі тощо, працівники проекту не повинні виходити за рамки регламенту, не

кажучи вже про порушення конфіденційності. Ця вимога ділового етикету. Зокрема,

абсолютно неприпустимо займатися критикою замовлення або проекту з замовником.

Втім, цього взагалі не слід робити поза колективом виконавців проекту. Особливо варто

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

підлягають розголошенню, потрапляють до замовника через треті особи. Це погано як

само по собі, так і в зв'язку з тим, що при подібному поширенні інформації досить

імовірно її спотворення.

Найбільш істотна частина контактів із замовником здійснюється за допомогою

ділових листів. Їх переваги перед іншими контактами полягають у наступному:

· для з'ясування питань не потрібно здійснювати спеціальні заходи (призначати

зустрічі, вести протоколи тощо);

· можна складати лист докладно, не упускаючи те, про що в «швидких» контактах

легко забути;

· відправлення листа не вимагає очікування часу, коли кореспондент готовий

вступити в контакт;

· на відміну від інших видів контактів переписка сама себе протоколює;

· переписка - досить дешевий спосіб спілкування.

Ці переваги у багатьох випадках компенсують головний недолік переписки:

відсутність оперативності спілкування, а тому, коли очікування відповіді допустимо,

використання листів для ділових контактів виправдано. Нижче наводиться далеко не

повний список дій замовника і розробників, які здійснюються за допомогою листування

95. Приймання робочих продуктів.

Приймання робочих продуктів

Взаємовідносини менеджера і інших виконавців проекту з замовником спрямовані

на підвищення продуктивності розвитку проекту в усіх відношеннях. Зокрема, в рамках

цих взаємовідносин будується поетапна звітність перед замовником про поточні

результати виконання завдання. Для різних контрольних точок передбачається різна

звітність, яка фіксується в проектному (технічному) завданні (див. п. 4.1).

Обов'язковим видом звітності є передача виконаної продукції майбутнім

користувачам. З цією метою часто застосовується організаційна процедура приймально-

здавальних випробувань, найбільш важливим моментом якої, з точки зору звітності, є

випуск юридичного документа, іменованого Акт приймально-здавальних випробувань.

Серед інших відомостей Акт містить мотивований висновок про передачу продукції

користувачам (в дослідну або виробничу експлуатацію), рекомендації для

розповсюдження продукції (на ринку) або ж про недоцільність подібних дій. Останнє

означає, що продукт не витримав випробувань. Акт розглядається в якості підсумкового

документа етапу чи проекту в цілому. Якщо подібна процедура не планується, менеджер

все одно повинен домовитися із замовником та керівництвом фірми про те, як буде

оформлятися факт передачі продукції, як буде вказуватися її якість (зауважень,

рекламацій та ін.)

Приймально-здавальні випробування як організаційна процедура зручні у зв'язку з

визначеністю порядку їх проведення. Призначається дата випробувань, до якої

пристосовується підготовка переданих програм і комплекту документації, а також відгуки

про результати експериментів із застосування продукції (якщо ця діяльність передбачена в

замовленні на розробку - розгорнута в часі приймання).

До цього ж терміну складається методика проведення випробувань та перевірки

властивостей продукту, фіксованих технічним (проектним) завданням. Методика

визначає, хто бере участь у випробуваннях, в якій формі (очною, заочною та ін..) і в якій

якості (відповідальні представники замовника, розробників, експерти та ін..) –

приймально-здавальна комісія, а також порядок випробувань і спосіб з'ясування

відповідності продукту вимогам. Зокрема, заздалегідь обговорюється тестовий матеріал:

хто і як його готує, як тести узгоджуються беруть участь у випробуваннях сторонами.

Дуже часто при підготовці методики з'ясовується, що в технічному завданні

сформульовані вимоги, які неможливо перевірити (наприклад, «дана функція повинна

виконуватися максимально ефективно»). Це прорахунок при складанні завдання, який для

розробників загрожує неприємностями: приймаюча сторона може на повному підставі

стверджувати, що вимоги такого роду не виконані (в даному прикладі, слід було б явно

вказати, що «час виконання даної функції з даними аргументами не повинно

перевищувати такого-то значення »). Прорахунок неустраним, якщо він не був помічений

при затвердження уточненого замовлення. Як наслідок, розробникам (менеджеру)

доведеться про подібні ситуації домовлятися із замовником спеціально.

Проведення приймально-здавальних випробувань строго відповідає методиці. По

ходу випробувань складається протокол, що фіксує виконувані дії і спостережуваний

ефект, з одного боку, а з іншого - думки учасників. За цим протоколом сторони складають

Акт з висновком про передачу продукції, в якому перераховуються отримані результати і

констатується рівень відповідності вимогам, на підставі чого робиться висновок про

виконання (невиконання) завдання. Важливою частиною висновку є перелік:

· помилок - підлягають усуненню до передачі продукту у виробничу експлуатацію

або в ході дослідної експлуатації;

· зауважень - усуваються із залученням додаткових ресурсів у строки, що

визначаються сторонами, і

· побажань - залишається для виконання в нових релізах і версіях.

Якщо помилки не виявлені, зауваження і побажання не висловлені, то про це явно

йдеться у висновку.

Коли члени приймально-здавальної комісії розходяться в оцінках, на закінчення

треба вказувати особливі думки.

Це загальна схема процедури приймально-здавальних випробувань. Стосовно

конкретних умов проекту вона може змінюватись, але факт виконання (невиконання

завдання) та перелік виявлених помилок, зауважень і побажань, а також особливі думки є

обов'язковими атрибутами документованого приймання програмного продукту.

Для здачі проміжних робочих продуктів немає сенсу вдаватися до повної схеми

приймально-здавальних випробувань. Досить того, що замовник погоджується з оцінкою

значимості виконаної на етапі роботи. Конкретні заходи, внаслідок яких досягається така

згода, можна вважати організаційною процедурою приймання. Варіанти поетапної

процедури приймання, рівень її строгості проведення дуже варіюються в залежності від

рівня відповідальності роботи в цілому і даного етапу, від ставлення замовника до

проекту, від його довіри виконавцям. Зокрема, для особливо важливих робіт, етапів

виправдане застосування загальної схеми приймально-здавальних випробувань, а при

особливому довірі замовника до колективу розробників можлива гранично проста

поетапна перевірка (наприклад, повідомлення менеджера про закінчення проміжного

етапу).

З точки зору розробників проекту згоду замовника з оцінкою значимості виконаної

на етапі роботи виражається в тому, що він оплачує виставлені менеджером рахунки.

Раніше зазначалося, що планування запропонованих замовнику робочих продуктів

визначається суперечливими прагненнями максимально скоротити період від отримання

замовлення до виставлення рахунку, з одного боку, а з іншого - пред'являти замовнику ті

результати, завдяки яким складається хороше враження про розробників. Стосовно

першої ітерації, що розробляється методом «Спочатку в глибину», це визначає дилему:

пред'являти чи ні результати міні-циклів замовнику. Більш точно: результати всієї ітерації

96. Управління проектом після виконання першої ітерації.

Завершення першої ітерації - важливий рубіж проекту. В цей момент доречно

підвести підсумки того, що зроблено, що ще належить зробити. Досягнення проекту

поділяються на змістовні результати, пов'язані з виконанням замовлення, і організаційні,

відносяться до колективу, до освоєння методів розробки. Серед організаційних

результатів, які необхідно отримати в ході виконання першої ітерації, є рольова

спеціалізація співробітників. Це необов'язково означає, що змінюється організація

колективної діяльності, переходячи від де персоніфікована схеми до розподілу

відповідальності. Просто певним співробітникам виявляється краще доручати певні види

робіт. Ідеально було б, якщо б така спеціалізація в точності відповідала планам розподілу

робіт в проекті. Це дозволило б менеджеру делегувати повноваження управління за

напрямами і піклуватися лише про координацію виконуваних завдань. На жаль, реальна

практика вимагає від менеджера більшого: йому доводиться заглиблюватися в завдання,

для вирішення яких не вистачає забезпеченості кадрами, розподіляти завдання між

виконавцями, що володіють недостатньо високою кваліфікацією. Вже з цієї причини

вимоги до кваліфікації менеджера включають в себе достатньо високий рівень знань в

областях діяльності, що відносяться до всіх ключових ролей. Інша причина, що спонукає

менеджера бути універсальним фахівцем, і також пов'язана з раціональною організацією

робіт в колективі, - це суміщення ролей. Нарешті, є ще одна суттєва причина для

різнобічної кваліфікації менеджерів: для більшості проектів неминучим є організація

навчання працівників, а це прямий обов'язок менеджера як відповідального за кадрове

забезпечення проекту.

Велика частина робіт, прямо пов'язаних з менеджерськими обов'язками, тобто з

плануванням і управлінням, вже розглядалася. До них відносяться: традиційні та об'єктно-

орієнтовані схеми життєвого циклу, оперування з технічними фінансовими та кадровими

ресурсами, управління якістю, ризиками і вимірювання, поточне і перспективне

планування, організація тестування, організація колективної діяльності і самоорганізація.

В рамках опису методу «Спочатку в глибину» роботи, пов'язані з етапами ітеративного

нарощування, представлені як організаційні завдання. Найбільш загальні з них, що

вимагають залучення спеціальних методів та інструментарію, обговорюються в цьому

розділі більш детально. Цей виклад зв'язується з технологічною послідовністю дій, яка

приводить до мети використання методів, а тому виходить за рамки окремої ітерації,

повертаючись до завдань, що вирішуються в процесі виконання, як першої ітерації, так і

попереднього аналізу і досліджень

97. Аналіз вимог.

Аналіз вимог полягає в визначенні потреб та умов які висуваються щодо нового, чи зміненого продукту, враховуючи можливо конфліктні вимоги різних замовників, таких як користувачі чи бенефіціари.

Аналіз вимог є критичним для успішної розробки проекту.[2] Вимоги мають бути задокументованими, вимірними, тестовними, пов'язаними з бізнес-потребами, і описаними з рівнем деталізації достатнім для конструювання системи. Вимоги можуть бути архітектурними, структурними, поведінковими, функціональними, та не функціональними.

У найбільш загальному вигляді

поняття вимог зводиться до наступних двох аспектів, фіксованих для виконання

конструкторських робіт:

засоби програмного продукту, яких потребує користувач для вирішення своїх

проблем або досягнення певних цілей;

характеристики програмного продукту, яким повинна володіти система в цілому

або її компонент, щоб задовольняти угодами, специфікаціям, стандартам або інший

формально встановленої документації.

Навіть це не дуже точне визначення неформального поняття вимог вказує на те, що

в реальному житті дуже важко, виходячи з аморфних і суперечливих побажань, виявити,

що конкретно й у якому вигляді повинно бути втілено в програмному продукті. Проблеми,

пов'язані з визначенням вимог, зводяться до наступних положень:

Вимоги не завжди очевидні і мають багато джерел. Зміст затвердження в тому,

що майбутні користувачі, замовник, консультанти з предметної області далеко не

завжди знають, якими засобами доцільно забезпечити підтримку автоматизованої

діяльності, в яких інтерфейсних формах ця підтримка повинна бути виражена;

Вимоги не завжди легко висловити словами. Інтуїтивне уявлення про те, які засоби

повинні надаватися, частіше за все не формулюються явно. Наводиться безліч

суперечливих прикладів, навідних міркувань, але не опис цих засобів. У зв'язку з

цим одна з головних задач аналізу - представити вимоги у вигляді узгоджених між

замовником і розробниками (однаково зрозумілих) тверджень, схем, діаграм,

моделей і т.п.;

Існує безліч різних типів вимог і різних рівнів їх деталізації. Сукупність вимог

досить багатопланова і співвідноситься з різними аспектами проекту. Отже, одним

із завдань аналізу є типізація наявних відомостей про вимоги і розподіл їх по

етапах і ітерація розробки;

Вимоги найчастіше взаємопов'язані і взаємозалежні, іноді суперечливі. Зв'язки між

вимогами обумовлені, в першу чергу, тому, що побажання до розробки даються в

системі понять, яка виходить з предметної області та поведінки користувача,

вирішального завдання з цієї області. Звідси, не слід очікувати, що зв'язки між

вимогами будуть добре відстеженні, що заздалегідь буде сформульована система

об'єктів, які втілюються в програмному продукті. Все, на що можна розраховувати,

отримуючи відомості про вимоги, - це неформальне уявлення про те, хто буде

працювати з системою, і навіщо йому це потрібно. Як наслідок, до завдань аналізу

входить виявлення взаємозв'язків і взаємозалежносте, усунення протиріч шляхом

вироблення раціональних компромісів;

Вимоги завжди унікальні, тобто завжди знайдуться властивості або значення

властивостей, за якими вони розрізняються: не існує двох одно значущих вимог. Це

твердження не настільки очевидно, якщо розглядати вихідний матеріал для вимог.

По суті, воно означає, що в результаті аналізу вимоги повинні бути сформульовані

з урахуванням даної умови (вимога до вимог);

Набір вимог найчастіше є компромісом між побажаннями майбутніх користувачів,

спрямованим на максимально можливе розширення сфери застосування системи.

Існує багато зацікавлених (майбутніх користувачів), чиї усереднені вимоги повинні

бути задоволені в рамках виконуваних ними функцій у прикладній області;

Вимоги змінюються. Фіксуються в уточненому замовленні на розробку вимоги для

системи, що претендує на широку сферу застосування і довге життя, не є

застиглими і непорушними. Вони змінюються, як через врахування нових факторів

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

Отже, необхідно так будувати аналітичну роботу, щоб мати можливість оперативно

змінювати одержувані результати, враховувати в них зміни і доповнення

початкової інформації;

Вимоги залежать від часу. Це положення вказує на те, що пробне та

експериментальне знайомство з першими одержуваними результатами

(програмними і документними) ймовірно спричинить за собою коригування вимог.

Як наслідок, потрібно мати на увазі, що при випуску чергової версії проміжних

робочих продуктів, при переході від релізу до релізу цілком реальна ситуація

проведення аналізу вимог знову, а тому аналіз і наступні за ним етапи повинні бути

організовані так, щоб мінімізувалися переробки програм і документів .

Щоб подолати зазначені проблеми пропонується ряд прийомів. Використання

деяких з них доцільно на початку проекту, інших - в ході аналітичної роботи, що

виконується на кожній ітерації.__

---

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

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

---

---

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