- •VIII. Розробка інтернет-програм
- •IX. БдБ і БдС системи
- •X. Реалізація
- •XI. Тестування
- •Введення в розробку програмного забезпечення
- •1. Складність інформаційних систем
- •2. Розробка програмного забезпечення
- •Криза програмного забезпечення
- •4.Концептуальне моделювання
- •Життєві цикли програмного забезпечення
- •Модель водоспаду
- •2. Модель водоспаду із зворотнім зв'язком
- •Документоване виконання
- •Прототипування
- •Покрокова розробка
- •7.Модель спіралі
- •III. Етапи розробки програмного забезпечення
- •1. Стратегічний етап
- •Етап визначення вимог
- •2.2. Нефункціональні вимоги
- •4. Етап проектування
- •5. Етап реалізації
- •6. Етап тестування
- •7. Етап установки
- •8. Етап підтримки
- •IV. Стратегічний етап
- •1. Дії на стратегічному етапі
- •2. Співпраця з клієнтом
- •3. Область дії і контекст проекту
- •4. Стратегічні рішення
- •5. Оцінка різних варіантів рішеннь
- •6. Оцінка вартості рішень
- •7. Чинники успіху
- •8. Результати стратегічного етапу
- •9. Короткий звіт
- •V. Розпізнавання вимог і документація
- •1. Складнощі у формулюванні вимог
- •2. Методи ідентифікації вимог
- •3. Методи опису вимог
- •4. Типи вимог
- •5. Перевірка вимог
- •6. Документ з вимогами
- •2. Аналітична модель
- •3. Дії на етапі аналізу
- •4. Функціональна декомпозиція
- •5. Методологія, що використовується в створенні аналітичної моделі
- •6. Документація вимог
- •7. Аналіз чинників успіху
- •8. Короткий звіт
- •VII. Етап проектування
- •1. Цілі проектування
- •Малюнок 7.2.1. Етап проектування.
- •2. Специфікація результатів аналізу
- •3. Дизайн інтерфейсу
- •4. Структуровані схеми/діаграми
- •5. Складова організації даних
- •6. Оптимізація проекту
- •7. Фізична структура системи
- •8. Правильність і якість проекту
- •9. Нефункціональні вимоги на етапі проектування
- •10. Результати етапу проектування
- •11. Детальний документ проекту
- •2. Стандарти, правила і порядок здійснення дій проекту:
- •12. Короткий звіт
- •VIII. Розробка інтернет-програм
- •1. Специфікація інтернет-програми
- •2. Методи розробки інтернет-програм
- •3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)
- •4. Метод розробки веб-сторінок (wsdm)
- •5. Мова веб-моделювання (WebMl)
- •Формулювання вимог
- •Проект структури даних
- •Гіпертекстовий проект
- •IX. Бдб і бдс системи
- •1. Електронний бізнес
- •2. Інтернет-бізнес і електронний ринок.
- •3. Інтернет-магазин
- •4. Модель електронного бізнесу
- •1.Модель брокера
- •2.Модель, яка задовольняє індивідуальним потребам
- •3.Модель контактів
- •5. Платежі
- •6. Безпека
- •8. Моделювання систем бдб і бдс
- •9. Багатошарова архітектура програм
- •9. Cервіс-орієнтована архітектура (соа)
- •10. Короткий звіт
- •X. Реалізація
- •1. Характеристики етапу реалізації
- •2. Надійність програмного забезпечення
- •3. Похибка
- •4. Транзакції
- •5. Середовище реалізації
- •6. Чинники успіху і результати етапу реалізації
- •7. Короткий звіт
- •XI. Тестування
- •1. Етап тестування
- •2. Перевірка
- •Малюнок 11.3.1. Модель V-тестування.
- •3. Перегляди
- •4. Аудит
- •5. Інспекції
- •6. Види тестів
- •7. Процес тестування
- •8. Тестування надійності
- •9. Типи тестів на знаходження помилок
- •10. Програми-інструменти
- •11. Статичні тести
- •12. Підрахунок кількості помилок
- •13. Чинники успіху, успіх тестування
- •14. Короткий звіт
- •XII. Оцінка програмного забезпечення
- •1. Простановка розмірів проекту
- •2. Оцінка складності в проектах
- •3. Ефекти масштабування
- •4. Оцінка вартості програмного забезпечення
- •5. Конструктивна вартісна модель (cocomo)
- •6. Балова функціональна оцінка
- •7. Метод випадкового використання
- •8. Короткий звіт
- •XIII. Управління конфігурацією пз і версіями
- •1. Управління конфігурацією пз
- •2. Елементи конфігурації пз
- •3. Угода позначень
- •4. Зберігання елементів конфігурації
- •5. Перегляди
- •7. План управління конфігурації пз
- •I Вступ
- •II Управління
- •III Визначення конфігурації
- •IV Управління конфігурацією
- •4. Модель якості iso-9126
- •5. Управління якістю
- •6. Стандарти якості
- •7. Незрілість і зрілість виробництва
- •8. План гарантії якості пз (sqap)
- •9. Короткий звіт
- •XV. Управління проектом програмного забезпечення
- •1. Завдання управління проектом
- •2. Працівники виробництва програмного забезпечення
- •3. Характеристика хорошого розробника програмного забезпечення
- •4. Робота в команді
- •5. Управління підприємством по виробництву програмного забезпечення
- •6. Розвиток компанії по розробці програмного забезпечення
- •7. Документація проекту
- •8. Визначення продуктивності
- •9. Складання графіків проекту
- •10. Завдання управління проектом
- •11. Інтерфейс проекту
- •12. Планування проекту
- •13. Управління ризиком
- •14. Вимірювання процесів і продуктів
- •15. Короткий звіт
13. Управління ризиком
Ризик - це вірогідність невдачі. У всіх проектах існує ризик. Чинники ризику повинні бути визначені і відстежені.
Під управлінням ризиком ми розуміємо зменшення загрози і мінімізацію можливих негативних результатів цих загроз. Менеджер по проектах повинен вивчити ті місця, що можуть стати загрозою і зробити дії із запобігання цього, якщо буде потрібно.
Менеджер управління ризиком повинен поставити собі питання: "що може піти не так", забувши про "все буде так, як повинно бути".
Найважливішими чинниками рзику є:
Чинники досвіду: нестача досвіду в управлінні проектом, в команді, відсутність перевірки кваліфікації членів команди, недолік стандартів.
Чинники планування: помилки оцінки часу, ресурсів, ціни, вандалізм, саботаж, незручні умови зв'язку, неправильний розподіл відповідальності, часті кадрові зміни.
Технологічні чинники: нова технологія, незрілість, помилково застосовані методи, необхідний досвід для застосування нових методів, низька якість використання комерційного продукту.
Зовнішні чинники: низька якість нестабільних або погано визначених вимог користувача, неправильний доступ зовнішніх систем.
Таблица ризику
Приклад такої таблиці приведений нижче. Вона містить перелік всіх загроз, вірогідність їх виникнення, дії для їх запобігання, дати і загрози цілям проекту.
Ризик |
Опис |
Вірогідність |
Дія |
Дата рішення |
Вплив |
1 |
нові вимоги |
висока |
зміна циклу ПЗ |
24.10.2005 |
великий |
T |
установка AC |
середня |
розподіл персоналу |
21.01.2006 |
средній |
Матриця ризику
Ще однією формою управління ризику є матриця ризику. Ризик відображається в наочній формі. Приписується вірогідність ризику.
Малюнок 15.14.1. Матриця ризику.
14. Вимірювання процесів і продуктів
Вимірювання інших продуктів і процесів необхідне для хорошого управління проектом. Вимірювання повинне бути застосоване скрізь, де це можливо. Вимірювання відбувається таким чином:
-
Оцінка середовища проекту і визначення головних цілей: фінансових, якісних, надійності,
-
Аналіз основних завдань. Це дає можливість визначити завдання і необхідні заходи,
-
Підведення підсумків вимірювань і їх оцінка,
-
Удосконалення дій шляхом зменшення безладу,
-
Зростання всієї організації шляхом посилання даних відповідним командам, відповідальним за стандарти.
Об'єктивний аналіз і визначення метрик
Протягом оцінювання повинні бути застосовані декілька метрик, а саме:
-
кількість використаних ресурсів,
-
кількість не використаних ресурсів,
-
тривалість дій в днях або місяцях,
-
кількість завершених завдань,
-
кількість розв'язаних проблем.
Подібну метрику слід застосувати до оцінки ПЗ:
-
кількість рядків коду,
-
кількість написаних і протестованих програм,
-
кількість реалізованих функціональних місць,
-
кількість написаних документів,
-
відсоток протестованих рядків коду,
-
складність циклів,
-
складність інтеграції програми,
-
кількість розв'язаних критичних проблем,
-
кількість змін з часу випуску першої версії програми.
Методи оцінки
Методи оцінки можуть бути наступними:
Історичне порівняння: порівняння поточного проекту із старими проектами, оцінювання ціни/часу/робочого навантаження, використання нових технологій (але не слід брати до уваги досвід їх використання - існує ризик інституціоналізації неправильної роботи).
Метод конструктивної вартісною моделі: заснований на взаємовідношенні між кількістю рядків коду і значенням ціни/часу. Метод не застосовується до нової техніки програмування.
Функціональний аналіз: метод зовнішніх значень функцій.
Метод розділення діяльності: частина зробленої роботи порівнюється з аналогічною, зробленою раніше. Недоліки такі ж, як і в методі історичного порівняння.
Метод Delphi: використання експертів, поєднання їх зусиль оцінки.
Робоче навантаження, потрібне для системної інтеграції.
Робоче навантаження, необхідне для документування.
Ведення звітності
Ретельне і своєчасне ведення звітності критично важливе для управління проектом. Члени команди передають звіти начальникам. Звіти повинні містити дані:
-
технічний стан,
-
стан ресурсів,
-
стан проходження графіку роботи,
-
виявлені проблеми,
-
фінансовий стан.
Методи створення звітів
Один з методів створення звітів - таблиця звіту про виконану роботу. Приклад наводиться нижче. У таблиці присутні такі пункти:
-
попередня оцінка даних (POSZ),
-
попередня вартість (WwO),
-
залишкова вартість (DoKo),
-
повна вартість (SumW).
Діаграма - ще одна форма звіту про виконану роботу. Приклад зображений на малюнку 15.15.1.
Малюнок 15.15.1 Діаграма виконання робіт.
Існує багато методів і інструментів, що підтримують управління проекту. Можна виділити наступне:
-
визначення пакету робіт,
-
ресурси і визначення їх доступності,
-
розподіл ресурсів по пакетах,
-
необхідний час виконання пакетів робіт,
-
визначення критичного шляху,
-
визначення графіка робіт за допомогою діаграми Grantt'а,
-
сума потрібних ресурсів,
-
необхідний час для виконання конкретних дій,
-
декомпозиція проекту в підпроекти,
-
модель процесу,
-
оцінки необхідної вартості, часу, робочого навантаження.