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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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