2.2 Методичні вказівки до заняття

CRC-карти [3] допомагають визначити сутність призначення класу та сприяють пошуку методів реалізації варіанта використання. Їх слід вживати при виникненні проблем з деталями реалізації.

Опис класу (class) складається на окремій картці розміром 46 (96144 мм) та складається з двох частин.

Ім’я класу
Відповідальності …	Кооперації …

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

Кооперації (cooperation) класу показують, з якими іншими класами необхідно кооперуватися для реалізації відповідальності. Це надає уяву про зв’язки між класами, але на достатньо високому рівні.

Для того, щоб формалізувати результати моделювання з застосуванням CRC-карт в нотації UML, можна використовувати діаграми класів та діаграми взаємодій.

3 Модель процесу розробки програмної системи

3.1 Ситуаційна вправа

Вона не знала, що сказати. Вона вдруге не змогла бути до кінця чесною, а він все ще вірить їй і чекає, що вона скаже... Що? «Завжди знайдеться щось важливе для такої хвилини», – говорить він. Вона говорить якісь банальні речі. «Ні, не те», – уже кричить він. І мимо волі в неї виривається: «Вони поклали сирий порох, Карл! Вони хочуть перешкодити тобі, Карл!» Вона кидається до нього, але раптом лунає оглушливий дзвінок.

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

Процес прояснення затягувався, Сергій ходив щось уточнювати, потім ще чаклував над своїми магічними картами. Але нарешті прийняв рішення, підкотив на своєму стільці до її стола і запропонував пошептатися. «Почалося», – подумала Наталка, відклала папери і прийнялася вникати в завдання.

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

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

Завдання

1. За допомогою матриці вибору життєвого циклу (таблиця 3) визначити найкращу модель процесу розробки CRM-системи.

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

• дослідження (формування бачення продукту і визначення області дії проекту) – 10%;

• уточнення плану (планування необхідних дій і визначення необхідних ресурсів; проектування архітектури) – 30%;

• побудова (розвиток архітектури, проектування, програмна реалізація, тестування) – 50%;

• розгортання (передача продукту користувачам) – 10%.

При цьому необхідно було отримати такі продукти:

• план виконання проекту;

• вимоги у формі запитів зацікавлених осіб;

• моделі прецедентів і додаткові специфікації;

• опис архітектури;

• моделі проектування;

• моделі тестування;

• вихідний код і виконувана програма, а також інформаційні файли, які її супроводжують;

• документацію по виявленим під час тестування дефектам;

• документацію користувача.

До робіт планувалося залучити 6 осіб: Сергій вже на повний хід займався системним аналізом, сама Наталка теж трудилася, ще їм знадобиться Маричка для формалізації вимог, Андрій з Романом на розробці, а також Павло, який займатиметься питаннями якості.

Завдання

2. Побудувати структурну декомпозицію робіт проекту.

3. Скласти попередній план виконання проекту.