Науково-навчальний комплекс «Інститут прикладного системного аналізу»

Національний технічний університет України «КПІ»

Кафедра математичних методів системного аналізу

ЗВІТ

по переддипломній практиці

	Виконала студентка ІV курсу
	Групи КА-85
	Шоботенко Наталія
	Номер залікової книжки КА-8520

Київ 2012

ЗМІСТ

ВСТУП

[1] Сьогодні , як ніколи, проектам по розробці систем потрібно слідувати за тенденціями. Технології швидко змінюються, конкуренція збільшується, і це сильно давить на процес розробки. Ефективне управління вимогами лежить в основі властивості організації утримувати в руках штурвал і утримувати корабель на плаву в потоці зростаючої складності.

В наш час тенденція, пов’язана з програмним забезпеченням, обумовлена трьома основними факторами:

• Можливість побудови надскладних систем.

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

• Швидке розповсюдження

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

• Готові («Off-the-shelf») модулі

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

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

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

Вимоги, являються базою для :

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

• Управління ризиками;

• Приймального тестування;

• Компромісів;

• Управління змінами.

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

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

Саме тому для підтримки процесу управління вимогами аналітикам і керівникам необхідний хороший інструментарій, до якого відносять різноманітні системи управління вимогами. [1]

1. ВИМОГИ

   1. ЙМОВІРНІСТЬ ПОМИЛКИ В ПРОЦЕСІ РОЗРОБКИ ПЗ

За даними дослідницької організації Standish Group, найбільша кількість помилок відбувається на етапі збору, аналізу та документації вимог. Доля помилок в різних артефактах при розробці ПЗ представлена на рис.1:

Рис.1. Доля помилок в різних артефактах при розробці ПЗ

Внаслідок помилок на різних етапах розробки ПЗ приходиться витрачати 30-50 % коштів від загального бюджету проекту на їх виправлення. Причому 70-85% від загального числа виправлень пов’язане саме з помилками, допущеними на етапі збору, аналізу та документації вимог.

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

• Невиявлені вимоги – 12,8%;

• Не чітко сформульовані вимоги – 12,3%;

• Зміна вимог – 11,8.

Підсумовуючи усе вище, можна зробити висновок, що помилка, допущена на етапі збору, аналізу і документації вимог, обходиться в 200 разів дорожче при впровадженні і здачі ПЗ. Відповідно до цього, керівники організацій повинні дуже ретельно підходити до одного з основних процесів розробки ПЗ – збору, аналізу і документації вимог, удосконалюючи даний процес всередині організації.

2. ПЯТЬ РІВНІВ МОДЕЛІ ЗРІЛОСТІ ДЛЯ УПРАВЛІННЯ ВИМОГАМИ

   1. РІВЕНЬ 0. ХАОС, НЕМАЄ ВИМОГ

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

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

• Продукт з пропущеним функціоналом;

• Продукт з непотрібним функціоналом;

• Продукт низької якості;

• Проекти ніколи не здаються в термін.

2. Рівень 1.Документація вимог

При збереженні і записі вимог, отримуємо беззаперечні переваги.

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

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

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

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

3. Рівень 2. Організація вимог

Даний рівень говорить про якість вимог – їх форматі, збереженні і версіях. Якісні вимоги зрозумілі як замовнику, що формує їх, так і всіх учасникам проектної команди, що розробляють ПЗ, що відповідає потребам замовника.

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

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

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

4. Рівень 3. Структуризація вимог

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

По-перше, потрібно виділити вимоги як атомарні одиниці для того, щоб було легше:

• Зрозуміти, що описує дана вимога;

• Посилатися на конкретну вимогу, а не на сторінку суцільного тексту;

• Сприймати зміну вимог;

• Розробляти та тестувати конкретну функціональність;

• Надавати атрибути вимогам.

По-друге, відрізняти різні типи вимог.

По-третє, потрібно додавати атрибути до атомарних вимог, показуючи, що вимоги не рівні між собою, це дозволяє легше управляти ними:

• Виставити пріоритети;

• Розуміти, які розроблені, які описані, які протестовані;

• Розуміти в якій версії ПЗ вони реалізовані

На даному рівні буде важко управляти вимогами з допомогою лише текстового редактора, краще використовувати спеціалізовані інструменти – система управління вимогами.

5. Рівень 4. Трасування вимог

Реалізація трьох попередніх рівнів управління вимогами не дозволяє можливості визначати та простежити взаємозв’язок між вимогами. Система будь-якої складності повинна мати ієрархію вимог. Трасування дає можливість простежити вплив вимог один на одного і провести аналіз покриття вимог.

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

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