Використання частих білдів і швидких тестів
Регулярне створення білдів рішення – найбільш надійний з доступних способів перевірки ходу розробки проекту і ефективності колективної діяльності проектної групи. Під час фази впровадження аналогічної мети служать цикли тестування пілотної версії.
76
Часті ітерації розробки і впровадження
Рішення, використовувані у виробничій сфері, повинні враховувати мінливість бізнес- процесів. Для цього вирішення повинні пристосовуватися до безперервних змін потреб замовника. Часті ітерації розробки і впровадження полегшують створення версіонованих випусків і дозволяють отримати еволюціонуюче рішення, що відповідає потребам, що змінюються, і вимогам.
Уникання розповзання рамок проекту
Використовуйте опис концепції і специфікації проекту для того, щоб зосередиться на заявлених бізнес-цілях і початкових вимогах. Ці документи повинні служити фільтром для всіх додаткових можливостей, які інакше могли б бути введені у вирішення без належного аналізу їх необхідності.
Оцінка з низу до верху
У IT-проектах попередні оцінки тривалості завдань, їх вартості і тому подібне повинні виходити від тих, хто потім виконуватиме оцінювану роботу. Підхід "від низу до верху" (bottom-up estimating) дає наступні переваги:
Велика точність. Оцінки,зроблені безпосередніми виконавцями,є точнішими,оскільки у цих людей є досвід аналогічної діяльності.
|
|
|
Відповідальність. Ті,хто використовує в роботі власні оцінки,відчувають великувідповідальність, як за свою роботу, так і за адекватність зроблених оцінок.
Уповноваженість (empowerment) проектної групи. Календарний графік,складенийсамою проектною групою, а не продиктований зверху керівництвом, надихає проектну групу, оскільки він складений на основі тих оцінок, які самі члени проектної групи вважають реалістичними.
Інтеграція представлених проектною групою оцінок
Кожен лідер ролевого кластера відповідальний за оцінку необхідного своєму відділу часу. Наприклад, лідер команди розробників готує оцінки часу розробки.
Ролевий кластер " Управління програмою" координує процес підготовки оцінок трудовитрат і проводить їх інтеграцію в звідний календарний графік і бюджет проекту.
Застосування A
Зміни в порівнянні з попередньою версією MSF
Попередня версія MSF включала дві моделі процесів, кожна з яких складалася з чотирьох фаз і чотирьох головних віх. Назви і визначення фаз і віх розрізнялися залежно від того, чи є метою проекту розробка застосування (створення) або розгортання інфраструктури (впровадження). У MSF версії 3.0 ці два доповнюючі одна одну моделі були об'єднані в одну загальну модель процесів MSF. Злиття двох моделей привело до появи додаткової фази в моделі процесів розробки застосувань. Ця фаза вбирає в себе діяльність, що знаменує кінець розробки і початок впровадження.
|
|
|
Спершу була розроблена модель процесів для розробки застосувань (Application Development - AD). Її метою була консолідація всього кращого з культури і процесів, продуктів майкрософту, що використовуються командами, для створення програмного забезпечення і його розповсюдження серед замовників і партнерів.
Пізніше клієнти майкрософту почали потребувати аналогічного керівництва для великомасштабного впровадження програмних продуктів і апаратного забезпечення на своїх підприємствах. Щоб задовольнити цю потребу, модель розробки застосувань була адаптована до моделі процесів впровадження інфраструктури (Infrastructure Deployment - ID).
77
І хоча обидві моделі продемонстрували впродовж ряду років свою високу ефективність, виникла необхідність створення єдиної, цілісної моделі процесів. Основною мотивацією цього послужило:
• Забезпечення взаємодії моделей AD і ID.
• Краща підтримка проектних груп, що працюють над рішеннями, спеціалізованими для конкретного підприємства, і розробкою веб-приложений, оскільки в обох випадках розробка і впровадження звичайне невіддільні один від одного.
|
|
|
• Краща підтримка тих, що активно розвивають сьогодні веб-сервісів і стратегії майкрософту .NET. Оскільки веб-сервіси все частіше стають основними каналами постачання програмного забезпечення, розробники комерційного програмного забезпечення знаходять необхідним включення процесу установки в життєвий цикл продукту.
• Полегшення передачі рішення від команди розробки до команди супроводу, особливо у разі використання MOF.
Висновок
Інформація, що міститься в цьому документі, представляє поточну точку зору корпорації майкрософт по обговорюваних питаннях на момент публікації. В умовах змінної ринкової кон'юнктури, що вимагає відповідного коректування розробок, що ведуться, дану інформацію не слід розглядати як якого б то не було зобов'язання з боку майкрософту; корпорація не може гарантувати точність інформації, представленої після дати публікації.
Даний огляд носить чисто інформативний характер. КОРПОРАЦІЯ МАЙКРОСОФТ НЕ НАДАЄ НІЯКИХ ГАРАНТІЙ, НІ ЯВНО ВИРАЖЕНИХ, НІ що МАЮТЬСЯ на увазі У зв'язку з ДАНИМ ДОКУМЕНТОМ.
Література
1. Royce, Winston W., "Managing the Development of Large Software Systems", Proceedings of IEEE Wescon (August 1970): pp 1-9.
2. Barry Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol.21, No. 5 (May 1988): pp 61-72.
78
Дата добавления: 2018-05-09; просмотров: 250; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!