Skip to main content
LibreTexts - Ukrayinska

1.9: Планування сфери

  1. Last updated
  2. Save as PDF
  • Page ID
    16995

    • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

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

    Визначення сфери

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

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

    • Двомісний літак двигуна проти одного літака двигуна
    • Червоний маркер проти зеленого маркера
    • Щоденний звіт проти щотижневого звіту
    • Відомче рішення в порівнянні з корпоративним рішенням

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

    Вимоги до проекту

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

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

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

    функціональні вимоги

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

    Приклад транспортного засобу

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

    Приклад комп'ютерної системи

    Для комп'ютерної системи ви можете визначити, що система повинна робити: «Система повинна зберігати всі деталі замовлення клієнта».

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

    Нефункціональні вимоги

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

    Щоб обмежити типи рішень, ви можете включити такі обмеження продуктивності:

    • Придбані вантажівки повинні бути вантажівками американського виробництва через державні стимули.
    • Зона навантаження повинна бути покрита.
    • Зона навантаження повинна мати висоту не менше 10 футів.

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

    • Час відгуку на інформацію відображається на екрані для користувача.
    • Кількість годин, яку система повинна бути доступною.
    • Кількість записів, які система повинна вміти утримувати.
    • Ємність для зростання системи повинна бути вбудована.
    • Тривалість часу запису повинна проводитися для цілей аудиту.

    Для прикладу записів клієнтів обмеження можуть бути такими:

    • Система повинна бути доступна з 9:00 до 17:00 з понеділка по п'ятницю.
    • Система повинна мати можливість зберігати 100 000 записів клієнтів спочатку.
    • Система повинна мати можливість додавати 10 000 записів на рік протягом 10 років.
    • Запис повинен бути повністю доступний в системі не менше семи років.

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

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

    • Час: Коли повинен бути доставлений товар
    • Ресурс: Скільки грошей доступно для розробки результату
    • Якість: Будь-які стандарти, які використовуються для розробки результату, методів розробки тощо.

    Технічні вимоги

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

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

    Вимоги до бізнесу

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

    Вимоги користувача

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

    Нормативні вимоги

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

    Приклад вимог

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

    Малюнок 9.1 Автоматизована касова машина.

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

    • Функціональна вимога банкомату: Система дозволить користувачеві вибрати, чи потрібно видавати друковану квитанцію про транзакцію перед завершенням транзакції.
    • Банкомат нефункціональний вимога: Всі дисплеї будуть білим, 14-точковий Arial текст на чорному тлі.
    • Технічні вимоги банкомату: Система банкоматів буде безперешкодно підключатися до існуючої бази даних клієнта.
    • Вимога користувача банкомату: система завершить стандартне зняття коштів з особистого кабінету, від входу до готівки, менш ніж за дві хвилини.
    • Вимоги до бізнесу банкоматів: Надаючи чудові послуги нашим роздрібним клієнтам, мережа банкоматів Monumental Bank дозволить нам постійно збільшувати дохід від зборів за послуги на 10% щорічно.
    • Нормативні вимоги банкоматів: Усі банкомати підключатимуться до стандартних комунальних джерел живлення в межах своєї громадянської юрисдикції та забезпечуватимуться джерелом безперебійного живлення, затвердженим компанією.

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

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

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

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

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

    Основи вимог до програмного забезпечення

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

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

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

    Вимірювальні вимоги

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

    Таблиця 9.1: Вимірювальні вимоги
    Нерухомість Вимірювати
    Швидкість
    • Оброблені транзакції/секунду
    • Час відгуку користувача/події
    • Час оновлення екрана
    Розмір
    • 4 тис. Байтів
    • Кількість мікросхем оперативної пам'яті
    Зручність використання
    • Тренувальний час
    • Кількість рамок довідки
    Надійність
    • Середній час виходу з ладу
    • Імовірність недоступності
    • Швидкість виникнення відмов
    • Наявність
    Надійність
    • Час перезавантаження після збою
    • Відсоток подій, що викликають збій
    • Імовірність пошкодження даних при збої
    Переносимість
    • Відсоток цільових залежних тверджень
    • Кількість цільових систем

    Сфера входів

    Менеджер проекту збирає початкові факти проекту зі статуту проекту. Крім того, довідкова інформація про робоче місце зацікавленої сторони, існуюча бізнес-модель та правила тощо допомагають у створенні бачення кінцевого продукту/послуги, а отже, обсягу проекту (див. Рис.

    Малюнок 9.2: Область введення-виведення. [Опис зображення]

    прийоми

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

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

    • Інтерв'ю
    • Фокус-групи
    • Сприяння групам, таким як JAD (спільна розробка додатків)
    • Техніки групової творчості: мозковий штурм, номінальні групи, дельфи, карта розуму, діагностика спорідненості
    • Прототипування
    • Спостереження
    • Питання та опитування
    • Групові прийоми прийняття рішень: одностайність, більшість, множинність, диктатура

    Матриця простежуваності вимог

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

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

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

    Поля матриці

    Це лише пропозиції і залежатимуть від організаційних та проектних вимог.

    • Унікальний ідентифікаційний номер, що містить загальну категорію вимоги (наприклад, SYSADM) та номер, присвоєний у порядку зростання (наприклад, 1.0, 1.1, 1.2)
    • Заява про вимогу
    • Джерело вимог (конференція, плата управління конфігурацією, завдання і т.д.)
    • Вимоги до програмного забезпечення/функціональні вимоги номер абзацу документа, що містить вимогу
    • Номер абзацу специфікації конструкції, що містить вимогу
    • Програмний модуль, що містить вимогу
    • Специфікація випробувань, що містить тест на вимогу
    • Номер (и) тесту, де потрібно перевірити вимогу (необов'язково)
    • Перевірка успішного тестування вимог
    • Поле модифікації (Якщо вимога була змінена, усунена або замінена, вкажіть розпорядження та повноваження щодо модифікації.)
    • Зауваження

    Структура розбивки робіт

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

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

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

    Огляд

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

    Створення WBS передбачає:

    • Перерахування всіх результатів проекту (результати та інші прямі результати)
    • Визначення всіх заходів, необхідних для забезпечення результатів
    • Поділ цих видів діяльності на підвиди діяльності та завдання
    • Визначення результату та етапу (етапів) кожного завдання
    • Визначення часу використання всіх ресурсів (персоналу та матеріалів), необхідних для виконання кожного завдання

    Мета розробки СБС полягає в тому, щоб:

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

    Приклад СБС

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

    Малюнок 9.3: СБС для прибирання приміщення. [Опис зображення]

    Дуже важливо відзначити, що ми не турбуємося про послідовність, в якій виконується робота, або будь-які залежності між завданнями, коли ми робимо WBS. Це буде відпрацьовано, коли ми розробимо графік. Наприклад, під 3.0 Vacuum було б очевидно, що 3.3 Вакуумний килим буде виконуватися після 3.4 Підключіть шланг і вилку! Тим не менш, ви, ймовірно, знайдете себе мислення послідовно, як здається, людська природа робити це. Основна ідея створення WBS полягає в тому, щоб відобразити всі завдання, незалежно від їх порядку. Тому, якщо ви виявите себе та інших членів вашої команди, думаючи послідовно, не будьте занадто стурбовані, але не зациклюйтеся на спробі діаграми послідовності, або ви сповільните процес ідентифікації завдання. WBS можна структурувати будь-яким способом, який має сенс для вас і вашого проекту. На практиці структура діаграми використовується досить часто, але вона може бути складена і в контурному вигляді (рис. 9.4).

    Малюнок 9.4: Чиста кімната у вигляді контуру.

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

    Існує також багато способів організації СБС. Наприклад, він може бути організований як за результатом, так і за фазою. Основні результати проекту використовуються в якості першого рівня в WBS. Наприклад, якщо ви виконуєте мультимедійний проект, результати можуть включати створення книги, компакт-диска та DVD (рис. 9.5).

    Малюнок 9.5: WBS для мультимедійного проекту

    Багато проектів структуровані або організовані за фазами проекту (рис. 9.6). Кожен етап представляв би перший рівень WBS, і їх результати будуть наступним рівнем тощо.

    Малюнок 9.6: Фази проекту WBS

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

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

    100 Відсоток Правило

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

    Заява про сферу

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

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

    Як базова область дії заяви повинні містити:

    • Назва проекту
    • Статут проекту
    • Власник проекту, спонсори та зацікавлені сторони
    • Постановка проблеми
    • Цілі та завдання проекту
    • Вимоги до проекту
    • Результати проекту
    • Нецілі проекту (що виходить за рамки)
    • Віхи
    • Кошторис витрат

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

    • План управління обсягом проекту
    • Затверджені запити на зміни
    • Припущення та ризики проекту
    • Критерії прийняття проекту

    Описи зображень

    Рисунок 9.2 Опис зображення: Менеджер проекту розробляє план управління сферою, беручи статут проекту, організаційну пам'ять та план проекту та застосовуючи такі методи та інструменти:

    • Заклики на минулий досвід проекту
    • Використовує шаблони управління областю (SOS, WBS, план управління областю)
    • Використовує комунікативні навички (для ведення переговорів з клієнтами та навчання)

    [Повернутися до малюнка 9.2]

    Малюнок 9.3 Опис зображення:

    0.0 Чиста кімната

    • 1.0 Швабра підлога.
      • 1.1 Отримати швабру і відро.
      • 1.2 Змішайте очищувач з водою у відрі.
      • 1.3 Промити відро і швабру.
    • 2.0 Пил
      • 2.1 Журнальний столик
      • 2.2 Жалюзі
    • 3.0 Вакуум
      • 3.1 Вийміть вакуум з шафи
      • 3.2 Вакуумний килим
      • 3.3 Порожній мішок
      • 3.4 Підключіть шланг і заглушку
    • 4.0 Підібрати підлогу
      • 4.1 Іграшки
        • 4.1.1 Покладіть іграшки в коробку
      • 4.2 Одяг
        • 4.2.1 Повісьте трубку в шафі
    • 5.0 Чисті штори
      • 5.1 Зняти штори
      • 5.2 Візьміть до прибиральників
      • 5.3 Повісьте штори

    [Повернутися до малюнка 9.3]

    Текстові атрибуції

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

    Атрибуції ЗМІ