І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 14

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

типи вимог (Requirements Types): бізнес-вимоги, функціональні, нефункціональні вимоги і т. д.;

види типів вимог (ієрархічні: батько - нащадок);

атрибути (Attributes) типів вимог і їх значення (Values per Attributes). За замовчуванням у RequisitePro для вимог встановлюються наступні атрибути: пріоритет (Priority), стан (Status), вартість (Cost), складність при реалізації (Difficulty), стабільність (Stability), призначений (Assigned to), джерело (Origin);

залежності між вимогами (trace to, trace from).

На рис. 33 наведена структура програмного продукту RequisitePro. Інформація про всі вимоги зберігається в БД незалежно від того, в якому вигляді вона відображається: перегляди (View) RequisitePro, документи RequisitePro або MS Word Document.

У методику управління вимогами в RequisitePro в процесі розробки програмних систем входить:

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

розробка корпоративного стандарту;

реалізація проекту.Планування проекту включає виконання наступних робіт: вибір методики розробки ПЗ, визначення документів і вимог тощо; вибір призначеного для користувача середовища (автономного, багатокористувальницького режиму);

вибір СУБД (Access, SQL Server, Oracle);

визначення способу створення вимог (лише у БД, лише в документах, в БД і документах);

визначення місця розташування проекту;


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

У розробку корпоративного стандарту роботи в середовищі IBM Rational RequisitePro входить:вибір життєвого циклу програмних засобів;

визначення складу документів, підтримуваних в IBM Rational RequisitePro; розробка   шаблонів   (template)   документів   з   подальшим їх розміщенням у папці шаблонів Outline;

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

Реалізація проекту в IBM Rational RequisitePro передбачає:

створення проекту;

створення шаблонів документів;

задавання типів вимог;

задавання атрибутів типів вимог;

задавання типів документів;

створення документів;

створення вимог у документах і (або) в БД і їх атрибутів;

створення переглядів вимог, сортування вимог, фільтрація вимог, задавання запитів до БД вимог, метрики;

задавання зв'язків між вимогами, підозрілих зв'язків, різних можливостей під час перегляду зв'язків;

стеження за змінами вимог;

створення списку змін вимог;

забезпечення безпеки проекту;

розробка специфікації вимог до ПЗ.

Вимоги до програмного забезпечення оформляються відповідно до стандартів, що діють:

у вигляді документа ТЗ - "Технічне завдання", на основі вітчизняного стандарту ГОСТ 34.602 - 90;

у вигляді документа SRS - "Специфікація вимог до системи", на основі стандарту IEEE 830 -1993.

Який із типів документів ТЗ або SRS використовувати для документування вимог, залежить від корпоративного стандарту і від вимог замовника.

У процесі створення ПЗ RequisitePro взаємодіє з іншими інструментами RUP, як це показано на рис. 34.

 

 

 

 

 

 

 

 

 

 

 

 

 

0

ю


Відстеження

варіантів використання


Моделювання вимогКоманда

Контроль версійАдміністратор проекту

 

Рис. 34. Зв'язок Rational RequisitePro з іншими інструментами RUPВимоги повинні бути інтегровані з іншими процесами життєвого циклу розробки ПЗ, що забезпечує чіткі комунікації в проекті. Це економить ресурси за рахунок мінімізації змін уже готових матеріалів. Rational RequisitePro дозволяє використовувати вимоги (зі свого репозиторію) в інших інструментах Rational Software.

Вимоги є вхідною інформацією для проектування ПЗ. Інтеграція RequisitePro з Rational Software Modeler пов'язує вимоги з моделями варіантів використання в Modeler. Розробники і проектувальники можуть безпосередньо мати доступ до специфікацій варіантів використання, атрибутів RequisitePro безпосередньо зі звичного середовища Modeler.

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

Інтеграція з Rational ClearCase дозволяє контролювати версії вимог нарівні з іншими артефактами проекту і створювати базові версії вимог.

Інтеграція з Rational TestManager гарантує, що вимоги використовуються як вхідна інформація для створення сценарію тестування тестером і фахівцем з контролю якості.

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

1.  Охарактеризуйте стани життєвого циклу продукту.

2.  Дайте визначення програмної інженерії.

3.  Що таке життєвий цикл програмного продукту?

4.  Які основні риси ЖЦ ПЗ?

5.  Що таке стандарт?

6.  Що таке заява постачальника про відповідність, сертифікація відповідності?

7.  Які види стандартів існують? Наведіть приклади кожного з видів стандартів.

8.  Охарактеризуйте основні організації-розробники стандартів в галузі програмної інженерії.

9.  Перерахуєте найбільш відомі стандарти в галузі програмної інженерії.

 

10.   Що таке процес, дія, завдання?

11.   Які типи процесів і конкретні процеси виділяють в ЖЦ ПЗ?

12.   Що таке верифікація? З яких дій і завдань складається цей процес?

13.   Що таке валідація? З яких дій і завдань складається цей процес?

14.   Що таке модель життєвого циклу ПЗ?

15.   Що таке фаза проекту, чим вона відрізняється від процесу?

16.   Які існують типи традиційних моделей ЖЦ ПЗ? У чому суть цих моделей, які їх переваги, недоліки, область застосування?У чому основна відмінність "живих" технологій проектування ПЗ від "важких"?

17.   Які основні характеристики, підхід до розробки та принципи методології RUP?

19.     Охарактеризуйте модель ЖЦ RUP. Що таке динамічна і
статична структури моделі ЖЦ
RUP?

20.   Охарактеризуйте основні концепції і принципи методології MSF.

21.   Які фази і віхи включає модель ЖЦ MSF?

22.       Які особливості, переваги і недоліки екстремального
програмування? Де його застосовують?

23.  Охарактеризуйте модель ЖЦ XP.

24.  Що таке програмна вимога? Як вимога визначається в стандарті IEEE?

25.  Наведіть рівні вимог і відповідні їм проектні документи.

26.  Чим обумовлена складність аналізу вимог?

27.  Назвіть складові процесу створення вимог згідно SWEBOK?

28.  Яка структура програмного продукту RequisitePro?

29.  Які характеристики вимог підтримуються RequisitePro?

30.  Яка послідовність дій управління вимогами під час планування проекту в IBM Rational RequisitePro?

31.      Яка послідовність дій управління вимогами в процесі
розроблення корпоративного стандарту в
IBM Rational RequisitePro?

32.   У яких документах відбиваються вимоги до проектованого ПЗ?

33.   З якими інструментами RUP взаємодіє RequisitePro під час проектування ПЗ?

10. Канонічне проектування ІС 10.1. Технологія передпроектного обстеження 10.1.1. Склад стадій і етапів канонічного проектування ІС

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

Процес каскадного проектування в життєвому циклі ІС відповідно до використовуваного в наший країні ГОСТ 34.601-90 "Автоматизовані системи. Стадії створення" включає наступні стадії та етапи проектування (табл. 6).

Допускається виключати стадію "Ескізний проект" і окремі етапи робіт на всіх стадіях, об'єднувати стадії "Технічний проект" і "Робоча документація" в одну стадію "Техноробоче проектування". Залежно від специфіки створюваних ІС і умов їх створення дозволяється виконувати окремі етапи робіт до завершення попередніх стадій, паралельне в часі виконання етапів робіт, включення нових етапів робіт.З метою вивчення взаємозалежних прийомів і методів канонічного проектування   ІС  перераховані  стадії  можна  згрупувати   в часто використовувані на практиці чотири стадії процесу розробки ІС (рис. 35).

Таблиця 6

Стадії та етапи створення ІС

 

Стадії

Етапи робіт

1. Формування вимог до ІС

1.1.   Обстеження об'єкта і обґрунтування необхідності створення ІС.

1.2.   Формування вимог користувача до ІС.

1.3.   Оформлення звіту про виконану роботу і заявки на розробку ІС
(тактико-технічного завдання)

2. Розроблення концепції ІС

2.1.   Вивчення об'єкта.

2.2.   Проведення необхідних науково-дослідних робіт.

2.3.   Розроблення варіантів концепції ІС і вибір варіанта концепції
ІС, що задовольняє вимоги користувача.

2.4.   Оформлення звіту про виконану роботу

3. Технічне зав­дання

3.1. Розроблення і затвердження технічного завдання на створення ІС

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки