ID: 4700

Название работы: Дослідження методик розробки ІС на основі IBM Rational Method Composer

Категория: Практическая работа

Предметная область: Информатика, кибернетика и программирование

Описание: Дослідження методик розробки ІС на основі IBM Rational Method Composer Мета виконання роботи – ознайомитись з кращими практиками розробки інформаційних систем з використанням бази знань IBM Rational Method Composer, навчитись роз...

Язык: Украинкский

Дата добавления: 2012-11-24

Размер файла: 400 KB

Работу скачали: 11 чел.

Дослідження методик розробки ІС на основі IBM Rational Method Composer

Мета виконання роботи – ознайомитись з кращими практиками розробки інформаційних систем з використанням бази знань IBM Rational Method Composer, навчитись розробляти додатки до бібліотеки методик системи.

IBM Rational Method Composer - гнучка платформа для управління процесами, що містить інструменти настройки процесів і бібліотеку процесів, щоб допомогти компаніям підвищувати ефективність розробки програмного забезпечення і реалізації інших ІТ-ПРОЕКТІВ.

IBM Rational Method Composer включає бібліотеку процесів RUP (IBM Rational Unified Process) і дозволяє не тільки проглядати пропоновані моделі процесів, але і адаптувати їх з урахуванням специфіки роботи організації, представляючи вміст процесів у формі, прийнятій в існуючій групі розробників.

У IBM Rational Method Composer входять наступні компоненти:

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

Конфігурація – RUP для середніх проектів. Дисципліна – тестування (Test).

1.  Опис дисципліни (Discipline) – призначення, цілі, зв’язки з іншими дисциплінами (Brief description, Main description)

Дисципліна Тестування діє як постачальник послуг для решти дисциплін у багатьох відношеннях. Тестування фокусується перш за все на оцінці якості продукту, яке реалізоване через наступне:

· знаходження дефектів в якості програмного забезпечення;

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

· затвердження і доведення припущень, які були зроблені в специфікаціях проекту;

· затвердження, що програмний продукт працює як передбачалося в документах розробки; 

· затвердження, що вимоги виконуються відповідно.

Цікава різниця існує між Тестуванням і рештою дисциплін в RUP. По суті Тестуванню дається завдання пошуку і висвітлення слабких сторін в програмному продукті. Це цікаво, тому що, щоб отримати найбільшу вигоду, вам потрібна інша загальна філософія, ніж та, що використовується у Requirements, Analysis & Design і Implementation disciplines. Ці три дисципліни зосереджуються на завершеності, тоді як Тестування зосереджується на неповноті.

Тестуванням управляють питання, як наприклад:

· За яких умов певне програмне забезпечення може зламатися?

· При яких можливих ситуаціях певне програмне забезпечення буде не в змозі працювати так, як прогнозувалося?

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

· підхід, який вимагає дієвого програмного забезпечення і виставляє властиві проблеми або слабкі сторони;

· підхід, який є негативним або руйнівним.

Інформація, представлена в різних оглядах і нарисах, заявляє, що програмне забезпечення перевіряє рахунки на 30 - 50 відсотків від повної вартості розробки програмного забезпечення. Цей контраст має місце в декількох ключових проблемах:

· Тестування програмного забезпечення дуже важке. Як ви визначаєте кількість різних способів, в яких дана програма може поводитися?

· Звичайно перевірка, зроблена без ясної методології, дає результати, які варіюють від проекту до проекту і від організації до організації. Успіх – це, перш за все, коефіцієнт якості і кваліфікація індивідуумів.

· Інструменти продуктивності використовуються недостатньо, що робить копіткі аспекти перевірки непокірними. На додаток до відсутності автоматизованого тестового виконання, багато тестових зусиль проводяться без інструментів, які дозволяють дієво управляти обширними тестовими даними і перевіряти результати. Гнучкість використання і складність програмного забезпечення роблять повну перевірку неможливою. Використовування сучасних методологій і інструментів може поліпшити як продуктивність, так і ефективність перевірки програмного забезпечення.

Високоякісне програмне забезпечення вельми важливе для успіху критичних систем безпеки. Із збільшенням вимог до надання електронним способом послуг через Інтернет, багато систем MIS зараз вважаються критичними; є компанії, які не можуть виконувати їх функції, і вони несуть значні втрати, коли відмови відбуваються.

Безперервний підхід до якості, ініційованої в lifecycle програмного забезпечення, може істотно знизити вартість завершення і підтримки вашого програмного забезпечення. Це дуже зменшує ризик недоброякісності, пов'язаний з розвертанням програмного забезпечення.

Зв’язки з іншими дисциплінами:

- дисципліна Requirements охоплює вимоги до програмного продукту, які є одним з первинних входів для ідентифікації того, які випробування треба виконувати;

- дисципліна Analysis & Design визначає відповідний проект для програмного продукту, який є іншим важливим входом для ідентифікації того, які випробування треба виконувати;

- дисципліна Implementation будує програмний продукт, який затверджується дисципліною Тестування;

- дисципліна Deployment доставляє завершений програмний продукт кінцевому користувачу;

- дисципліна Environment розвивається і підтримує артифакти, які використовуються під час Перевірки, як, наприклад, Тестові Директиви і Тестове Оточення;  

- дисципліна Project Management планує проект і необхідну роботу в кожному повторенні. Описаний в Плані Повторення artifact є важливим входом, що використовується, коли ви визначаєте правильну місію оцінки для тестового зусилля;

- дисципліна Configuration & Change Management контролює змінюються в межах команди проекту. Тестове зусилля перевіряє, що кожна зміна завершена відповідно.

1.  Опис шаблону спроможності (Capability Pattern, Main description)

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

Властивості:

•  Керований перериваннями
•  Багаторазові випадки
•  Продовження
•  Необов'язковість
•  Планується
•  Повторювання

Використання:

 Вирішіть, як виконувати технологічний процес

Наступні рішення потрібно зробити щодо технологічного процесу дисципліни Тестування:

• Вирішіть, як виконувати технологічний процес, проглядаючи дії в цьому технологічному процесі. Вивчайте діаграму з його сторожовими умовами і директивами нижче.

• Вирішіть, які частини тестових дій треба виконувати. Одна ключова проблема для Тестового технологічного процесу - вирішити, що якісні вимірювання цікаві для проекту взагалі, і найбільш важливо, для кожного повторення (подивіться Поняття: Види Тестування). Вирішіть, що відповідні комбінації видів випробувань, на яких ви повинні зосередитися для поточного повторення.

1.  Схема (Actitvity Diagram) базового потоку робіт (Reference Workflow)

1.  Структуру робіт (Work Breakdown Structure) базового потоку (Reference Workflow) у табличній формі

Робочі продукти

• Архітектура Випробувальної Автоматизації

• Тестовий Випадок

• Тестування Даних

• Тестування Проекту

• Тестування Конфігурації навколишнього Середовища

• Тестування Випробувальної Оцінки

• Тестування головного списку

• Тестування Інтерфейсної специфікації

• Тестування Колоди

• Тестування Плану

• Тестування   Результатів

• Тестування Сценарію

• Тестування Стратегії

• Тестовий Набір

• Модель Аналізу робочого Навантаження

5. Опис робіт, що досліджуються, у табличній формі з таким змістом:

№	Роботи (Activitiy Task)	Номер попередньої роботи (Prede-cessor)	Вико-навці (Role)	Робочі продукти (Work Product)
								Вхідні (Input)		Вихідні (Output)
								Назва	Обов-сть	Назва	Обов-сть
1	Identify Test Ideas (task)		Test Analyst	Iteration Plan Test Strategy Data Model Deployment Model Implementation Model, Interface Project – Specific Guidelines, Software Architecture Document, Software Requirements Specification, Storyboard, Test-Ideas List, Test Plan, Use-Case Model, User-Interface Prototype, Vision	М М О О О О О О О О О О О О О О	Test-Ideas List	М
2	Define Test Approach (task):		Test Designer	Iteration Plan Software Architecture Document, Vision, Project – Specific Guidelines, Software Architecture Document, Software Requirements Specification, Test Plan, Vision	М M M О О О О О О O	Test Strategy	М
3	Implement Test (task)		Tester	Test Strategy Build Test Suite  Implementation Model Development Infrastructure	М М О О О	Test Script	М
4	Execute Test Suite (task):		Tester	Build, Test Suite Development Infrastructure, Iteration Plan,	М M О О	Test Log	М
5	Determine Test Results (task):		Test Analyst	Test Ideas-List, Test Log, Test Strategy	М М M	Test Evaluation Summary, Test Results	М
6	Assess and Advocate Quality (task):		Test Manager	Iteration Plan, Test Evaluation Summary Risk List, Test Results	М М О О	Test Evaluation Summary	М
7	Implement Test Suite		Tester	Test Strategy Build Test Suite Implementation Model,Development Infrastructure	M M O O O	Test Suite	M
8	Execute Test Suite (task):		Tester	Build, Test Suite Development Infrastructure, Iteration Plan,	M M O O	Test Log	M
9	Structure the Test Implementation		Test Designer	Test Strategy Test Suite Development Infrastructure	M M O	Test Suite	M
10	Determine Test Results		Test Analyst	Test Ideas-List, Test Log, Test Strategy	М М M	Test Evaluation Summary, Test ResultsM	M

1.  Діаграму Гантта (таблицю і графік), що відображає підготовлений  за допомогою Microsoft Project календарний план виконання робіт.

Висновки: Виконавши лабораторну роботу, я ознайомився розробкою інформаційних систем з використанням бази знань IBM Rational Method Composer, навчився розробляти додатки до бібліотеки методик системи, а також детально проаналізував таку дисципліну, як Тестування.