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

Процес попередньої оцінки витрат із 10 кроків


В даний час велика частина організацій, що займаються розробкою програмного забезпечення, для оцінки програмних проектів застосовує один або більше наступних методів: 1) приблизна / за орієнтовними даними / SWAG (super wild ass guess, дуже приблизна) попередня оцінка, 2) попередня оцінка зверху вниз / з урахуванням обмежень та / або 3) попередня оцінка знизу вгору / з урахуванням проектних даних. Незважаючи на відмінності в методологіях планування, в принципі всі ці підходи мають спільну особливість – існує тенденція їх виконання як одноразових методів, що залежать від доступності дефіцитних ресурсів, надмірного навантаження фахівців і неавтоматизованих або мінімально автоматизованих процесів, таких, як електронні таблиці та інші доморощені інструменти. Такі одноразові методи, за визначенням, є неузгодженими, непрогнозованими і в значній мірі схильні до помилок, обумовленим людським фактором. Окремі планувальники володіють різними здібностями і різної архівної проектною документацією, вони можуть бути занадто оптимістичними або песимістичними, на них може впливати внутрішній розпорядок організації або інші фактори, що не мають відношення до проекту; вони можуть просто не помітити не дуже впадають в очі елементи проекту.


Застосування визнаного, перевіреного на практиці процесу оцінки, який добре інтегрується з процесом розробки, допомагає гарантувати, що плани проекту будуть обгрунтованими і досяжними, відповідними або навіть переважаючими очікування клієнта і будуть підтримувати інші управлінські діяльності шляхом надання точної та своєчасної інформації про планування. Пропонований процес попередньої оцінки витрат, що складається з 10 кроків і запропонований Деніелом Галоратом (Daniel Galorath) і Майклом Евансом (Michael Evans) в книзі (Software Sizing, Estimation, and Risk Management (Визначення масштабу проекту, попередня оцінка витрат і управління ризиками) , Видавництво Auerbach Publishing, 2006 р.), побудований на більш ніж двадцяти дослідженнях передових методів попередньої оцінки витрат, застосовуваних при розробці програмного забезпечення.


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


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


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


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


Крок 5: підготуйте базову попередню оцінку витрат
Не слід думати, що попередня оцінка витрат для проекту – це разова діяльність. По мірі виконання проекту невідоме стає відомим, і з’являються нові і непередбачувані проблеми і можливості. Життя триває .. Оновлення попередніх оцінок і документування змін в оцінках протягом усього процесу розробки гарантує, що 1) аналіз компромісних рішень буде будуватися на все більш надійних даних, 2) організація буде мати “найточнішу оцінку” в будь-який даний момент часу і 3) точність оцінки буде підвищуватися з часом.


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


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


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


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


Крок 10: Відстежуйте ефективність робіт (кількісна оцінка і зворотній зв’язок)
Інформація по процесу повинна безперервно збиратися і порівнюватися з початковим планом і лінією відліку. Якщо ефективність постійно або суттєво змінюється, скорегуйте підлягають попередньої оцінки та реалізації параметри, щоб повернути проект в потрібне русло. Для уточнення самого процесу попередньої оцінки необхідно переглядати інформацію зворотного зв’язку з питань ефективності та збирати дані по проекту.


Параметричне / предиктивное моделювання програмного забезпечення


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


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


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


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


Механізм імітації / моделювання: Складні, специфічні для конкретної галузі математичні моделі отримані на основі розширеної архівної документації проектів, поведінкових моделей і показників.


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


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


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


Screen shot of parameter input

Малюнок 1. Вхідна інформація SEER


Screen shot showing graphical output

Малюнок 2. Вихідна інформація SEER


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


Можна використовувати наступні додаткові параметри:



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


Адміністрація соціального забезпечення – нестандартна організація з нестандартним колом обов’язків. У 2007 році Адміністрація соціального забезпечення перевела понад 585 мільярдів доларів на пенсії 50 мільйонам громадян США. Головний офіс Адміністрації соціального забезпечення знаходиться в м. Балтімор, штат Меріленд; крім того, Адміністрація має 10 регіональних відділень, в яких працює приблизно 62000 співробітників, шість процесингових центрів і 1300 локальних відділень. У міру того, як мільйони дітей, народжених в період різкого підвищення народжуваності, досягають пенсійного віку, вимоги до Адміністрації соціального забезпечення стають все більш відчутними. Щоб іти в ногу зі зростаючою кількістю одержувачів соціальних допомог, необхідні численні складні комп’ютерні системи та спеціально розроблене програмне забезпечення, здатне відстежувати доходи і посібники більше ста мільйонів чоловік. Ці системи створюються і тестуються спеціальним підрозділом Адміністрації – Відділом інформаційних систем (Office of System).


У серпні 2007 року відділ інформаційних систем прийняв рішення про впровадження рішення параметричного моделювання. До справжнього моменту Адміністрація соціального забезпечення використовує приблизно 100 програм, і ще 30 – 40 програм знаходяться у стадії розробки. Майже всі програми написані на мові COBOL, який в даний час використовує 80 відсотків підприємств і компаній у всьому світі. Адміністрація соціального забезпечення прагнула досягти повної відповідності новому стандарту на процеси, Capability Maturity Model, CMM (Модель розвитку функціональних можливостей) і централізації своїх коштів попередньої оцінки витрат на розробку програмного забезпечення.


Робочу групу по оцінці програмного забезпечення, яка відповідала за попередню оцінку витрат на потенційні проекти програмного забезпечення і відстеження робіт за наявними проектами, очолював Денніс О “Мейл (Dennis O” Mailey) (зараз він вийшов у відставку). “У нас працюють більше 600 програмістів, які розробляють та обслуговують безліч систем, тому нам необхідний точний програмний інструмент попередньої оцінки витрат “, – пояснив він.” Ми відчували, що попередні оцінки витрат, які ми виконуємо, недостатньо точні “.


У той час за виконання попередньої оцінки витрат відповідали керівники окремих проектів. За словами О “Мейл,” Якість оцінки залежало від знань і досвіду керівника проекту “.” Керівники проекту, які працювали над проектом багато років, були більш точні в оцінці, ніж новачки. Але у багатьох проектах ми упускали деякі моменти при оцінці порядку затрат “.


Спочатку Адміністрація соціального забезпечення впровадила параметричне моделювання тільки в декількох десятках проектів, причому інструменти використовувалися для того, щоб визначити експлуатаційні витрати і вирішити питання про можливість продовження розробки. Але, крім цього, Адміністрація соціального забезпечення працювала над тим, щоб перевести свою організацію на більш високий рівень (2 і 3) відповідності CMM. “Стандарт CMM був для нас важливим тому, що він підтверджує зрілість операцій розробки програмного забезпечення і наявність стандартної методології для розробки систем”, – заявив О “Мейл. CMM вимагає, щоб оцінки трудових і фінансових витрат за проектом розроблялися відповідно до документованої процедурою. Впровадження SEER дозволило Адміністрації соціального забезпечення домогтися відповідності цим вимогам.


В даний час група розробки програмного забезпечення Відділу інформаційних систем використовує працю більше 3 200 аналітиків, розробників, фахівців зі створення моделей баз даних та інших фахівців по системам, які, крім виробництва програмного забезпечення для соцзабезпечення також проектують і створюють додатки для інших федеральних відомств. “Це все ті ж проекти на мові COBOL, – додає Джим Денні (Jim Denney), який змінив Про “Мейли в Адміністрації соціального забезпечення, – але зараз проекти виглядають так, як ніби написані на якій-небудь мові програмування для Web. Ми освоїли Java і JavaScript, HTML, Visual Basic і Cold Fusion “. Нещодавно ввірена йому організація отримала контракт на розробку програмного забезпечення, необхідного для реалізації ініціативи Medicare Part D Prescription Drug Coverage (правила виписки наркотичних і сильнодіючих медикаментів в рамках федеральної програми безкоштовної медичної допомоги престарілим, частина D). “Замість того, щоб залучити до їх створення приватного виробника ПО, – пояснив Денні, – був укладений контракт з Адміністрацією соціального забезпечення. Згідно міжвідомчому угодою, ми компенсували кожну годину, витрачений на розробку програмного забезпечення для програми Medicare, за принципом долар за долар. Зрештою нам довелося прийняти на роботу ще близько 600 фахівців “.


Прийнявши справи у О “Мейл, Джим Денні побачив додаткові можливості для цього рішення:” Ми запитали себе, чи слід довіряти виконання попередньої оцінки витрат сотні різних керівників проекту або краще сформувати групу фахівців за попередньою оцінкою витрат, які могли б отримати важливий досвід, відстежуючи загальні моменти в змінюють один одного проектах. Сьогодні виконанням попередньої оцінки витрат займається централізований сервіс, що надається робочою групою Software Measurement “.


За типовий рік попередня оцінка витрат за допомогою рішень параметричного моделювання SEER була виконана приблизно для 90 або 100 найбільш критично важливих проектів Адміністрації соцзабезпечення. Процес починається з попереднього аналізу за принципом “знизу вгору” з використанням продукту Microsoft Project. Колектив, очолюваний Денні, застосовує підхід “зверху вниз”, використовуючи наявні функціональні бали для повторної оцінки. “Нашим стандартом встановлено, що керівник проекту повинен мати у розпорядженні дві попередніх оцінки, одну знизу вгору, а іншу – зверху вниз; їх відмінність можна порівняти з відмінністю між індуктивними і дедуктивними умовиводами “, – пояснив Денні. -” Отримавши ці оцінки, керівник проекту зобов’язаний виконати їх порівняння і зіставлення. Ми прагнемо, щоб різниця між ними була зовсім невелика. Саме це дозволяє керівнику проекту стверджувати, що він на правильному шляху “. SEER також грає роль в управлінні ресурсами.” Ми намагаємося виявити надлишок і брак уваги до окремих аспектів проекту і використовуємо для цього концепцію, яку називаємо взаємозамінністю. Якщо ресурси, виділені якого проекту, використовуються недостатньо інтенсивно, то вони можуть бути перенаправлені проектом, який в них більше потребує “, – розповідає Денні. -” Це одна з переваг попередньої оцінки витрат: параметричне моделювання відкриває нам справжню картину використання ресурсів, дозволяючи виконувати роботу швидше, ефективніше й точніше “.


Завдяки відкритій програмній архітектурі, SEER дозволяє окремим організаціям уточнити свої інструменти попереднього аналізу шляхом розширення вбудованих Баз знань шляхом додавання специфічних для даного проекту даних організації. “Приблизно 5 років тому ми надали розробникам компанії Galorath інформацію по 50 виконаними проектами, яку вони змогли згодом включити в базу знань SEER. Тепер у нас є дуже надійна система відстеження проекту, тому що всі фахівці повинні були щотижня записувати, над якими проектами вони працювали і які завдання виконували “.


“Справжнє перевага параметричного моделювання полягає в тому, що воно допомагає керівникам проектів виконати кількісну оцінку трудових витрат і скласти календарні плани на ранніх етапах проекту, “- сказав О” Мейл. – “Головне – знати на самому початку робіт і протягом усього життєвого циклу проекту, скільки часу піде на виконання проекту і які ресурси будуть потрібні .. Якщо ви управляєте проектом на основі добре продуманого плану – а інтегрованою частиною цього плану є якісний попередній аналіз – то ви зможете заощадити фінансові, трудові та часові ресурси в значному обсязі.


Rational-SEER-Rational: інтеграція життєвого циклу розробки програмного забезпечення


У стандартному процесі життєвого циклу розробки програмного забезпечення передбачена автоматизація розробки, попередньої оцінки витрат, виділення ресурсів і відстеження проекту. Органічна інтеграція між програмними продуктами IBM Rational Software Modeler, SEER for Software і IBM Rational Portfolio Manager підтримує цей процес на всьому протязі:


Крок 1: оціните попередню концепцію – прийнятна вона чи ні?


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


Крок 2: розробіть проект ПО


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


Крок 3: виконайте деталізовані попередні оцінки витрат


Експортуйте проекти Rational Software Modeler, Rational Software Architect або Rational Software Developer в SEER для уточнення вашої первісної попередньої оцінки витрат та виконання розширеного аналізу з метою вибору компромісного рішення, зміни змінних проекту – окремо або в поєднанні – щоб визначити, як краще виконати проект (див. малюнок 3). Надайте керівництву показники ймовірності досягнення цілей проекту в процентному вираженні і можливі способи підвищення цих показників за допомогою невеликих змін в обмеженнях і припущеннях, які лежать в їх основі.


SEER product
Rational Software Modeler product.

Малюнок 3. Сканування за допомогою інструментів SEER for Software (вгорі) і IBM Rational Development (внизу) допоможе вам виконати попередню оцінку витрат за кількома варіантами, що дозволить уточнити і оптимізувати програмний проект.


Крок 4: розподіліть ресурси і керуйте портфелем


Експортуйте вашу остаточну попередню оцінку витрат з SEER в IBM Rational RPM, щоб зібрати в одному місці дані програми і проекту і гарантувати, що управління ресурсами і пріоритетами здійснюється оптимальним способом у всій організації і постійно, причому жоден ресурс не затребуваний двічі і не використовується в недостатній мірі, а також з’ясувати, де виникають конфлікти ресурсів при порушенні термінів проекту (див. малюнок 4).


input to SEER portfolio management
output from Rational portfolio tool

Малюнок 4. Функції моніторингу та контролю SEER for Software Project (вгорі) і Rational Portfolio Manager (внизу) дозволяють централізовано керувати програмними та проектними даними та відслідковувати виконання проекту, що дозволяє гарантувати оптимальне управління ресурсами і пріоритетами.


Крок 5: призначте строки здачі проекту


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

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*