Методичні вказівки до виконання самостійних робіт з дисципліни: «проектний практикум»



Сторінка4/5
Дата конвертації16.03.2017
Розмір3.38 Mb.
ТипМетодичні вказівки
1   2   3   4   5

РЕКОМЕНДОВАНА ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

6. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом
Змістовий модуль 2. Специфікація та документування вимог

Специфікація вимог до програмного забезпечення. Специфікація вимог до тестування програмного забезпечення
1. Введення

Даний документ проектується групою розробників Team1 для опису програмного продукту «Lunch Manager». А так же системних, функціональних і не функціональних вимог до даного продукту.

1.1 Призначення

• Розробка для практичного освоєння предмета "Програмна інженерія".

• Фіксування всіх вимог до продукту.

• Опис поведінки майбутньої системи.

• Створення продукту, наближеного до промислових корпоративних продуктів

1.2 Область застосування

Область застосування системи - сфера обслуговування.

2 . Загальний опис

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

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

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

Користувачі: Офіс менеджер , співробітники фірми .

вимоги :

• Система являє собою веб- орієнтований додаток , написаний на мові Java з використанням технології JSP . Як СУБД обрана MySQL. Т.к. продукт є кросплатформним рішенням , його використання не прив'язується до конкретної операційної системи . Требуется налаштована локальна мережа в офісі підприємства і налаштована віртуальна машина JAVA і контейнер сервдетов Apache Tomcat 6 .

3. Специфікація вимог

Вимоги для розробки цього продукту:

• середовища: Idea, NetBeans і Eclipse і сервер Apache Tomcat .

• Потрібно встановлена СУБД - MYSQL;

• бездротова, локальна або інші мережі

3.1 Функціональні вимоги

Робота системи :

1 . Програмний продукт повинен забезпечувати роботу двом категоріям користувачів : адміністратори та користувачі.

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

1.2 . При коректному введенні логіна і пароля повинен здійснюватися перехід на робочу сторінку користувача або адміністратора відповідно в залежності від введених даних.

1.2.1 . При невірному вводі з'являється повідомлення про прохання перевірити правильність введення логіна і пароля.

2 . Користувач повинен сформувати необхідний йому на дані добу список страв до обіду.

2.1. Користувач повинен мати можливість ознайомитися з усім меню на поточний день

2.1.1 Користувач повинен мати можливість ознайомитися з калорійністю страв з меню.

2.1.2. Користувач повинен мати можливість перегляду ціни

2.2. Користувач повинен мати можливість формувати свій список страв.

2.2.1. Користувач повинен мати можливість додавати блюдо в свій список замовлень.

2.2.2. Користувач повинен мати можливість видаляти блюдо зі свого сформованого списку замовлень.

2.2.3. Користувач повинен мати можливість відправляти список замовлень менеджеру.

3.1. Менеджер повинен мати можливість реєструвати користувача.

3.2. Менеджер повинен мати можливість заповнити меню на поточний день.

3.2.1. Менеджер повинен мати можливість скопіювати деякі страви з попередніх меню. (опція)

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

3.2.3 Менеджер повинен мати можливість додавати блюдо в загальний список страв для замовлення (список наявних блюд).

3.2.4 Менеджер повинен мати можливість видаляти блюдо з загального списку страв.

3.2.5. Менеджер повинен мати можливість згенерувати загальний звіт і звіт по кожному користувачеві.

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

3.3 Кількісні показники для нефункціональних вимог.

• Простота експлуатації: Час навчання персоналу: 2ч.

• Устойівость до збоїв: Час відновлення системи після збою: 1ч.

Відсоток подій, що призводять до збоїв: 1.

Імовірність зміни даних при збоях: 0,1

3.4 Зручність використання

Системна мета: Система повинна бути простою в експлуатації для досвідченого оператора.

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

3.5 Вимоги надійності

1. Середня тривалість часу між двома послідовними проявами помилок у системі має становити п'ять годин.

2. Ймовірність виходу системи з ладу повинна становити 2-3 відсотки .

3. Коефіцієнт готовності системи - 98 з 100.

4. Час відновлення системи - 1 годину.

5. Кількість помилок на функцію ( в середнім) - 0,1 багів.

6. Доступність системи : годин безперервної роботи , підтримка на 2 -х останніх етапах розробки ( "Завершення " , "Здача проекту" ) .

3.6 Вимоги продуктивності

швидкість: Кількість виконуваних транзакцій в секунду ( в середньому): 5 тис.

Вимоги до RAM: 100 Mb

Вимоги до вільного місця на жорсткому диску: 200Мб ( server side )

3.7 Вимоги до документації користувача

Вимоги на даному етапі відсутня.

3.8 Запозичені компоненти

Запозичені компоненти на даному етапі відсутня.

3.9 Вимоги до ліцензування

Платне програмне забезпечення .

3.10 Вимоги поширення

На замовлення , розгортається версія.


РЕКОМЕНДОВАНА ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

6. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом
Змістовий модуль 3. Технології розробки програмного забезпечення

Технологія SCRUM
Розглянемо Scrum в порівнянні з іншими методологіями, і таким чином пояснимо, чому для розроблюваної системи була обрана саме вона.

 Візьмемо такий критерій, як легкість впровадження методики в процес розробки. XP містить в собі достатньо жорсткі правила ведення проекту, які не всі розробники можуть прийняти, або просто може знадобитися тривалий час, щоб отримати від них гарну віддачу. А це ризиковано, якщо проекти не дуже великі і не розраховані хоча б на рік. Але в компанії-замовнику справи йдуть саме таким чином. Якщо впровадження методології йде важко, то велика ймовірність не вкластися в терміни і втратити великий прибуток. Природно, це неприпустимо.

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

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

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

Scrum


Для того щоб мати повне уявлення про обраній для компанії-замовника методології розробки, наведемо найбільш докладний її опис.

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

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

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

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

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

Девіз Scrum - «аналізуй й адаптуються»: аналізуй те, що отримав, Адаптуй те, що є, до реальної ситуації, а потім аналізуй знову. Чим менше формалізму, тим більш гнучко і ефективно можна працювати, - це основний принцип даної методології. Але це не означає, що формальних процесів не повинно бути зовсім, їх повинно бути досить для організації ефективної взаємодії та управління проектом. Формальна частина Scrum складається з трьох ролей, трьох практик і трьох основних документів.

Ролі


Власник продукту (Product Owner) - людина, що поставляє вимоги програмістам. Від того, як чітко написані вимоги, залежить, наскільки часто команді доведеться перемикатися з задачі на задачу у зв'язку з відсутністю потрібної інформації, як багато потрібно ставити запитань, на які йде додатковий час, як сильно доведеться змінювати вже написану функціональність від ітерації до ітерації і, відповідно, ефективність розробки в цілому. Звичайно власник продукту є представником або довіреною особою замовника, а для компаній, що випускають коробкові продукти, він представляє ринок, на якому реалізується продукт. Власник продукту повинен скласти бізнес план, що показує очікувану прибутковість і план розвитку з вимогами, відсортованими за коефіцієнтом окупності інвестицій. Виходячи з наявної інформації, власник продукту готує список вимог, відсортований за значущості. Чим краще власник продукту описує вимоги, управляє пріоритетами і чим швидше видає інформацію, тим більший фінансовий ефект отримає компанія від методології. В обов'язки цього співробітника входить своєчасне надання вимог до продукту, визначення дат і змісту релізів, ефективне управління пріоритетами і коректування вимог для досягнення максимальної окупності інвестицій в продукт.

Від людини, виконуючого роль Scrum-майстра (Scrum Master), багато в чому залежить самостійність, ініціативність програмістів, задоволеність зробленої роботою, атмосфера в команді і результат всієї роботи. Ця людина має бути одним з членів команди розробки і брати участь у проекті як розробник. Він відповідає за своєчасне вирішення поточних проблем, від ремонту зламаного стільця до забезпечення необхідною інформацією членів команди для продовження їх роботи і завантаженості, за підтримку потрібних технічних практик, використовуваних на проекті. В обов'язки Scrum-майстра входить забезпечення максимальної працездатності і продуктивності команди, чіткої взаємодії між усіма учасниками проекту, своєчасне вирішення всіх проблем, що гальмують або зупиняють роботу будь-якого члена команди, огорожу команди від усіх впливів ззовні під час ітерації і забезпечення проходження процесу всіх учасників проекту.

Scrum-команда (Scrum Team) - група, що складається з п'яти-дев'яти самостійних, ініціативних програмістів. Перше завдання цієї команди - поставити реально досяжну, прогнозовану, цікаву і значущу мету для ітерації. Друге завдання - зробити все для того, щоб ця мета була досягнута у відведені терміни і з заявленим якістю. Мета ітерації вважається досягнутою тільки в тому випадку, якщо всі поставлені завдання реалізовані, весь код написаний за певними проектом «Стандартам кодування» (coding guidelines), програма протестована повністю, а всі знайдені дефекти усунені. Програмісти цієї команди повинні вміти оцінювати і планувати свою роботу, працювати в команді, постійно аналізувати і покращувати якість взаємодії та роботи. В обов'язки всіх членів Scrum-команди входить участь у виборі мети ітерації і визначення результату роботи. Вони повинні робити все можливе і неможливе для досягнення мети ітерації в рамках, визначених проектом, ефективно взаємодіяти з усіма учасниками команди, самостійно організовувати свою роботу, надавати власнику робочий продукт в кінці кожного циклу.

Практики

Підготовка до першого ітерації, званої спринт (Sprint), починається після того, як власник продукту розробив план проекту, визначив вимоги і відсортував їх в кількості, достатній для наповнення однієї ітерації. Такий список вимог називається журналом продукту (Product Backlog). При плануванні ітерації відбувається детальна розробка сесій планування спринту (Sprint Planning Meeting), який починається з того, що власник продукту, Scrum-команда і Scrum-майстер перевіряють план розвитку продукту, план релізів і список вимог. Scrum-команда перевіряє оцінки вимог, переконується, що вони досить точні, щоб почати працювати, вирішує, який обсяг роботи вона може успішно виконати за спринт, грунтуючись на розмірі команди, доступному часу і продуктивності. Важливо, щоб Scrum-команда вибирала перші за пріоритетом вимоги з журналу продукту. Після того як Scrum-команда зобов'язується реалізувати вибрані вимоги, Scrum-майстер починає планування спринту. Scrum-команда розбиває вибрані вимоги на завдання, необхідні для його реалізації. Ця активність в ідеалі не повинна займати більше чотирьох годин, і її результатом служить список вимог, розбитий на завдання, - журнал спринту (Sprint Backlog). Необхідно, щоб всі учасники команди взяли на себе зобов'язання по реалізації обраної мети.

Після закінчення планування починається ітерація. Кожен день Scrum-майстер проводить «скрам» (Daily Scrum Meeting) - п'ятнадцятихвилинне нараду, мета якого - досягти розуміння того, що сталося з часу попередньої наради, скорегувати робочий план до реалій сьогодення і позначити шляхи вирішення існуючих проблем. Кожен учасник Scrum-команди відповідає на три питання: що я зробив з часу попереднього скрам, що мене гальмує або зупиняє в роботі, що я буду робити до наступного скрам? У цьому мітингу може брати участь будь-яка зацікавлена ​​особа, але тільки учасники Scrum-команди мають право приймати рішення. Правило обгрунтовано тим, що вони давали зобов'язання реалізувати мету ітерації, і лише це дає впевненість у тому, що вона буде досягнута. На них лежить відповідальність за їх власні слова, і, якщо хтось зі боку втручається і приймає рішення за них, тим самим він знімає відповідальність за результат з учасників команди.

Наприкінці кожного спринту проводиться демонстраційний мітинг (Sprint Review Meeting) тривалістю не більше чотирьох годин. Спочатку Scrum-команда демонструє власнику продукту зроблену протягом спринту роботу, а той у свою чергу веде цю частину мітингу і може запросити до участі всіх зацікавлених замовників. Власник продукту визначає, які вимоги з журналу спринту були виконані, і обговорює з командою і замовниками, як краще розставити пріоритети в журналі продукту для наступної ітерації. У другій частині мітингу проводиться аналіз минулого спринту, який веде Scrum-майстер. Scrum-команда шукає використані у тому спринті позитивні і негативні способи спільної роботи, аналізує їх, робить висновки і приймає важливі для подальшої роботи рішення. Scrum-команда також визначає програми, які можуть працювати краще, і шукає шляхи для збільшення ефективності подальшої роботи. Потім цикл замикається, і починається планування наступного спринту.

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

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

Графік спринту (Burndown Chart) показує щоденне зміна загального обсягу робіт, що залишився до закінчення ітерації. Це графік дозволяє команді розробників робити аналіз поточної ситуації та своєчасно реагувати на відхилення. Графік спринту дозволяє також власнику продукту спостерігати за ходом ітерації - якщо загальний обсяг робіт не зменшується щодня, значить, щось іде не так. Під час сесії планування команда знаходить і оцінює завдання, які треба виконати для успішного завершення ітерації. Сума оцінок всіх завдань у журналі спринту є загальним обсягом роботи, який треба виконати за ітерацію. Після завершення кожного завдання Scrum-майстер перераховує обсяг залишилася роботи і відзначає це на графіку спринту. Тільки в тому випадку, якщо обсяг робіт по закінченні ітерації закінчився (у журналі спринту не залишилося незавершених завдань), ітерація вважається успішною. Графік спринту використовується як допоміжний інструмент, що дозволяє коректувати роботу для завершення ітерації вчасно, з працюючим кодом і необхідною якістю.

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

Scrum-команда протягом ітерації отримала краще представлення про вимоги і потребує додаткових завданнях для успішного завершення ітерації;

знайдені дефекти, які потрібно обов'язково виправити для успішного завершення ітерації;

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

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

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

Для розробки програмних продуктів, заснованої на Scrum, вже існує принаймні одна система, яка називається Agilo for Scrum. Вона також розроблена мовою Python. Є розширенням відомої системи Trac, і відповідно має аналогічний інтерфейс по роботі із завданнями та помилками. Для тих, хто є шанувальником Trac або звик ним користуватися, перехід на Agilo не викличе особливих проблем. Однак багатьом ця система здається незручною, принаймні, в якості повноцінного ведення процесу розробки, тому що створена більшою мірою для відслідковування помилок програмістів.

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



Технологія RAD
1. Програмне забезпечення за методологією RAD

Життєвий цикл програмного забезпечення за методологією RAD складається з чотирьох фаз:

• фаза аналізу і планування вимог;

• фаза проектування;

• фаза побудови;

• фаза впровадження.

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

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

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи і приймається рішення про розділення інформаційних систем на підсистеми, піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час - близько 60 - 90 днів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

• загальна інформаційна модель системи;

• функціональні моделі системи в цілому і підсистем, що реалізуються окремими командами;

• точно визначені за допомогою CASE-засоби інтерфейси між автономно розробляються підсистемами;

• побудовані прототипи екранів, звітів, діалогів.

Всі моделі і прототипи повинні бути отримані із застосуванням тих CASE-засобів, які будуть використовуватися надалі при побудові системи.

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

1.2. Методологія RAD

Один з підходів до розробки ПЗ в рамках спіральної моделі ЖЦ - одержала широке поширення методологія швидкої розробки додатків RAD (Rapid Application Development), вона включає в себе три складові:

• невелику команду програмістів (від 2 до 10 осіб);

• короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);

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

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

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

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

На фазі проектування частина користувачів бере участь в технічному проектуванні системи під керівництвом фахівців-розробників. CASE-засоби використовуються для швидкого отримання працюючих прототипів додатків. Користувачі, безпосередньо взаємодіючи з ними, уточнюють і доповнюють вимоги до системи, що не були виявлені на попередній фазі. Більш докладно розглядаються процеси системи. Аналізується і при необхідності коригується функціональна модель. Кожен процес розглядається детально. Якщо потрібно, для кожного елементарного процесу створюється частковий прототип: екран, діалог, звіт, що усуває неясності або неоднозначності. Встановлюються вимоги розмежування доступу до даних. На цій же фазі відбувається визначення необхідної документації.

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи і приймається рішення про поділ ІС на підсистеми, піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час (60 - 90 днів). З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

• загальна інформаційна модель системи;

• функціональні моделі системи в цілому і підсистем, що реалізуються окремими командами;

• точно визначені за допомогою CASE-засобів інтерфейси між автономно розробляються підсистемами;

• побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

• визначається необхідність розподілу даних;

• здійснюється аналіз використання даних;

• виробляється фізичне проектування бази даних;

• визначаються вимоги до апаратних ресурсів;

• визначаються способи збільшення продуктивності;

• завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім узгодженим вимогам.

На фазі впровадження виробляються навчання користувачів, організаційні зміни і паралельно з впровадженням нової системи здійснюється робота з існуючою системою (до повного впровадження нової). Так як фаза побудови достатньо нетривала, планування та підготовка до впровадження повинні починатися заздалегідь, як правило, на етапі проектування системи. Наведена схема розробки ІС не є абсолютною. Можливі різні варіанти, залежні, наприклад, від початкових умов, в яких ведеться розробка: розробляється зовсім нова система; вже було проведено обстеження підприємства й існує модель його діяльності; на підприємстві вже існує деяка ІС, яка може бути використана в якості початкового прототипу або повинна бути інтегрована з розробляється.

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

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

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

Оцінка розміру додатків виробляється на основі так званих функціональних елементів (екрани, повідомлення, звіти, файли і т.п.). Подібна метрика не залежить від мови програмування, на якому ведеться розробка. Розмір програми, яке може бути виконане за методологією RAD, для добре налагодженої середовища розробки ІС з максимальним повторним використанням програмних компонентів визначається наступним чином:

• менше 1000 функціональних елементів - одна людина;

• 1000 - 4000 функціональних елементів - одна команда розробників;

• більше 4000 функціональних елементів - 4000 функціональних елементів на одну команду розробників.

• Отже, перерахуємо основні принципи методології RAD:

• розробка додатків итерациями;

• необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

• обов'язковість залучення користувачів в процес розробки ІС;

• необхідність застосування CASE-засобів, що забезпечують цілісність проекту;

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

• необхідність використання генераторів коду;

• використання прототипування, що дозволяє повніше з'ясувати і задовольнити потреби кінцевого користувача;

• тестування і розвиток проекту, здійснювані одночасно з розробкою;

• ведення розробки нечисленної добре керованої командою професіоналів;

• грамотне керівництво розробкою системи, чітке планування і контроль виконання робіт.



2. Застосування підходу RAD. Його відмінність

2.1 Відмінність підходу RAD від традиційного

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

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

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

• визначається необхідність розподілу даних;

• проводиться аналіз використання даних;

• виробляється фізичне проектування бази даних;

• визначаються вимоги до апаратних ресурсів;

• визначаються способи збільшення продуктивності;

• завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім узгодженим вимогам.

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


2.2. Досвід застосування методологій RAD в конкретних проектах (на прикладі Національного Банку)

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

  • Використання сучасних технологій розробки і супроводу програмного забезпечення (зокрема підхід RAD) дало нові можливості:

  • Гнучкість орієнтації на "рольові" функції

  • Переносимість ПЗ на інші платформи без перепрограмування

  • Більш висока продуктивність у розробці та супроводі

  • Спрощення реалізації нових функціональних завдань без перепрограмування



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

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

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

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

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

Таблица 1. таблица характеристик проекта



Объекты проекта

Общее количество

Файлы экранов

217

Файлы отчетов

74

Файлы меню

33

Файлы моделей архитектуры

41

Файлы моделей данных

18

Характеристики проекту при традиційному підході: Складність проекту ~ 1850 Ф.Т. Типова норма виробітку - 18 Ф.Т. на людино-місяць Проект потребуватиме - 103 людино-місяці 5 осіб - більше 20 місяців при спіральної моделі життєвого циклу: Складність проекту ~ 1850 Ф.Т. Проект зажадав - 38 людино-місяців Норма вироблення - 48,5 Ф.Т. на людино-місяць.



Технологія RUP
RUP - Rational Unified Process (Унікальний процес розробки ПЗ).

Призначення:

1. Розробка ПЗ.

2. База знань з програмної інженерії в різних галузях виробництва.

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

Основні визначення:



Цикл розробки - період часу від початку розробки до випуску продукту або відмови від випуску (цикл первісної розробки), до випуску нової версії (цикл розвитку), до виправлення помилки (цикл підтримки).

Життєвий цикл продукту - час від початку проекту до завершення проекту.

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

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

Ітерація - чітка послідовність завдань з планом і критерієм оцінки, що призводить до випуску релізу.

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

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

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

Завдання - одиниця роботи в RUP, яка може бути запропонована ролі для виконання.

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

Компонент - нетривіальна, практично незалежна (та, яка може бути заміненою) частина системи, що виконує конкретну функцію в контексті точно визначеної архітектури.

Цикл - повне проходження всіх 4-х фаз, що призводить до випуску продукту.

Роль - область функціональних обов'язків компетенції та відповідальності, які повинна мати людина або група людей.

Властивості RUP як ітеративного процесу
1. Розробка пристосована до вимог, які можуть змінюватись.

2. Рання інтеграція.

3. Раннє виявлення ризиків.

4. Полегшується повторне використання коду.

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

6. Навчання «на ходу»

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

1. Вибір структурних елементів.

2. Поведінка (функціональний елемент), обумовлена взаємодією цих елементів.

3. Об'єднання елементів в більш великі підсистеми.



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

Прецедент використання - послідовність дій, що виконує система, які призводять до видимого цінного результату для конкретної дійової особи. Також прецедент використання містить всі головні, додаткові та виняткові послідовності подій, пов'язаних з отриманням видимого корисного результату.
3. RUP. Динамічна структура. Фази життєвого циклу, цілі, віхи.
Каталог: download -> version
version -> Захист навколишнього середовища від забруднення мийними засобами
version -> «Валеологічне виховання дітей дошкільного віку, як фактор формування здорового способу життя»
version -> Виписка з навчального плану
version -> Методичні рекомендації щодо викладання уроків для стійкого розвитку «Моя щаслива планета» розділ Система уроків-зустрічей для 3 класу курсу за вибором «Моя щаслива планета»
version -> Затверджую директор Зіньківської спеціалізованої школи І-ІІІ ст.№2 Л. В. Литус
version -> Наказ №526 " Про затвердження Науково-методичних рекомендацій щодо оцінювання навчальних досягнень учнів та оформлення сторінок класних журналів загальноосвітніх
version -> Методичні рекомендації Донецьк  2006 ббк 64. 9 (ІІ) 722 ш 30
version -> Вимоги до оформлення посібника
version -> Програма бібліотечно-бібліографічних знань для учнів 1-11 класів


Поділіться з Вашими друзьями:
1   2   3   4   5




База даних захищена авторським правом ©uchika.in.ua 2020
звернутися до адміністрації

    Головна сторінка