Лабораторна робота №2,3 Використання прогнозованих моделей на практиці. Вивчення технології red.

Мета роботи:

Порівняти прогнозовані та адаптивні моделі створення ПЗ.

Теоретичні відомості:

Модель життєвого циклу проекту (Software life cycle model (SLM) – це структура, що визначає послідовність виконання та взаємозв’язку процесів, дій та задач на протязі виконання проекту. Модель ЖЦ залежить від специфіки програмного продукту, а також від специфіки умов, в яких даний продукт створюється та функціонує.

Існує два основних типи моделей ЖЦ:

1. Прогнозовані моделі ЖЦ – в основі цих моделей лежить чітке планування усіх стадій процесу розробки ПЗ;

2. Адаптивні моделі ЖЦ (так звані гнучкі технології) – особливістю цих моделей є сприйняття та адаптація процесів розробки під потребу замовника та ринку.

На сьогоднішній момент найбільшого поширення серед прогнозованих набули такі моделі:

• каскадна;

• V-подібна модель;

• модель еволюційного прототипування;

• модель швидкої розробки;

• інкрементна модель;

• спіральна модель.

Адаптивні моделі ЖЦ з’явилися недавно, але здобули вже досить широке поширення особливо серед західних компаній. Найвідомішими є:

• Scrum;

• Extreme programming, XP;

• Adaptive Software development, ASD;

• Dynamic System Development Model, DSDM;

• Feature Driven Development, FDD.

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

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

Хід роботи:

1.Вивчити моделі, вміти порівнювати і вибирати потрібну, відповідно до завдання.

2. Технологія RAD – основні складові, принципи, стадії, використання на практиці.

Контрольні питання:

1. Що таке модуль життєвого циклу ПЗ? Які є типи моделей?

2. Порівняйте прогнозовані моделі і адаптивні. Коли вони приміняються?

3. Що таке прототип? В яких моделях він присутній?

4. Що таке CASE-технології? Що лежить в основі будь-якої CASE-технології?

5. Поясніть терміни: методологія, метод, нотація, засіб.

6. Поясніть якісні зміни процесу розробки ПЗ при переході до використання CASE-засобів.

Лабораторна робота №4,5 Побудова опорних точок зору на основі методу vord для формування аналізу вимог. Складання сценаріїв основних подій. Розробка технічного завдання на створення пз.

Мета роботи:

Скласти і проаналізувати вимоги до майбутнього ПЗ, оформити технічне завдання на розроблення програмного забезпечення.

Теоретичні відомості:

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

Вимоги до результатів виконання лабораторної роботи:

• наявність діаграми ідентифікації точок зору і діаграми ієрархії точок зору;

• наявність сценаріїв подій (послідовність дій);

• наявність вимог користувачів, які чітко описують майбутнє функціонування системи;

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

Хід роботи:

1. Вивчити теоретичний матеріал по темі (конспект лекцій).

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

3. Скласти сценарії основних подій.

4. Скласти інформаційну модель майбутньої системи, що включає в себе опис основних об’єктів системи і взаємодію між ними. На основі отриманої інформаційної моделі і діаграм ідентифікації точок зору, діаграми ієрархії точок зору, а також сценарію подій сформувати вимоги користувача і системні вимоги.

5. Скласти звіт, що містить всі отримані рівні моделі, опис функціональних блоків, потоків даних, сховищ і зовнішніх об’єктів.

Варіанти завдань

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

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

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

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

Контрольні питання:

1. Поясніть, чому, як правило, вимоги, сформовані різними особами, будуть суперечливими.

2. Хто повинен проводити огляд вимог? Намалюйте модель процесу огляду вимог.

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