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



Сторінка1/5
Дата конвертації08.03.2016
Розмір0.86 Mb.
  1   2   3   4   5
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

МАРІУПОЛЬСЬКИЙ МАШИНОБУДІВНИЙ КОЛЕДЖ

ДЕРЖАВНОГО ВИЩОГО НАВЧАЛЬНОГО ЗАКЛАДУ

"ПРИАЗОВСЬКИЙ ДЕРЖАВНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ"



МЕТОДИЧНІ ВКАЗІВКИ

до виконання лабораторних робіт

з дисципліни:
«КОНСТРУЮВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ»
Для студентів спеціальності:

5.05010301«Розробка програмного забезпечення»

Розробив викладач

ММК ДВНЗ "ПДТУ" ___________ В.В.Горобей
Розглянуто та схвалено

на засіданні циклової комісії

ММК ДВНЗ ПДТУ Протокол № ____

від ___________20____ р.


Голова циклової комісії

з напряму 6.050103 «Програмна

інженерія» ММК ДВНЗ "ПДТУ" __________ О.О.Тузенко

Відповідно до навчального плану на вивчення курсу предмета «Конструювання програмного забезпечення» студентами спеціальності 5.05010301«Розробка програмного забезпечення» призначено 84 години на аудиторні заняття, з яких 40 годин призначені на лабораторні роботи.

Лабораторні роботи призначені для закріплення лекційного матеріалу, конкретизації отриманих знань у процесі самостійного вивчення визначених розділів курсу й одержання практичних навичок роботи із моделями конструювання, зі спеціалізованим програмним забезпеченням (будова таблиць «зв'язок-сутність», діаграм на мові UML, тощо). Перед початком лабораторної роботи студенти зобов'язані вивчити конкретний матеріал відповідних лекцій, ознайомитися з указівками для лабораторної роботи і технічною літературою по зазначеній темі, відповісти на питання, що містяться в методичних указівках.

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

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

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



Звіт з лабораторної роботі повинний мати наступні розділи:

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

  • Ціль проведення лабораторної роботи

  • Порядок виконання роботи

  • Результати виконаної роботи

  • Висновки про створену роботу

Таблиця 1 Тематика лабораторних робіт для підготовки молодших спеціалістів

Назва теми

Назва лабораторно-практичної роботи

Кількість годин

1

2

3

Змістовий модуль 1. Моделі конструювання

Лабораторна робота № 1. «Проектування ПЗ за допомогою каскадної моделі»

4/5

Лабораторна робота № 2. «Проектування ПЗ за допомогою спіральної моделі»

4

Змістовий модуль 2. Планування конструювання

Лабораторна робота № 3. «Вступ до екстремального програмування»

4/5

Лабораторна робота № 4. «Основи керування конструюванням ПЗ»

2

Змістовий модуль 3. Мови конструювання

Лабораторна робота № 5. «Робота із програмним продуктом Rational Rose»

4/5

Лабораторна робота № 6. «Робота із програмним продуктів ErWin»

2

Змістовий модуль 4. Інтеграція

Лабораторна робота № 7. «Введення до інтеграції програмних засобів»

2

Лабораторна робота № 8. «Порядок безперервної інтеграції ПЗ»

4/5

Змістовий модуль 5. Якість конструювання

Лабораторна робота № 9. «Особливості тестування ПЗ»

2/2

Лабораторна робота № 10. «Особливості модульного та інтеграційного тестування ПЗ»

2/3

Лабораторна робота № 11. «Стандарти як засіб керування якістю ПЗ»

2

Змістовий модуль 6. Шаблони проектування

Лабораторна робота № 12. «Робота із шаблонами проектування»

2/2

Лабораторна робота № 13. «Конструювання ПЗ за допомогою шаблонів делегування»

4/3

Лабораторна робота № 14. «Конструювання ПЗ за допомогою шаблонів функціонального дизайну»

2




Разом:

40/30


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

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

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

Входы



Кодирование и тестирование




Делать, пока не будет сделано



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

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

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

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


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

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



Короткий опис фаз каскадної моделі

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

• дослідження концепції - відбувається дослідження вимог на системному рівні з метою визначення можливості реалізації концепції;

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

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

• процес розробки проекту - розробляється і формулюється логічно послідовна технічна характеристика програмної системи, включаючи структури даних, архітектуру ПО, інтерфейсні уявлення і процесуальну (алгоритмічну) деталізацію;

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

• процес установки - включає установку ПО, його перевірку і офіційну приймання замовником для операційного середовища;

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

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

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

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



Методичні вказівки до виконання роботи:

  1. Робота повинна бути виконана згідно критеріїв оформлення документації на аркушах формату А4. У виняткових випадках допускається написання роботи в зошиті.

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

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

  4. Якщо потрібні пояснення – можна звернутись до викладача. Викладач сам вирішує відповідати на питання чи надати підказки, де можна знайти відповідь.

  5. Студенти можуть згрупуватись по дві-три людини та виконувати одне загальне завдання.

  6. Протягом виконання лабораторної роботи студенти можуть використовувати конспекти або інші джерела інформації.

  7. Роботу потрібно набирати на комп’ютері, що розташований в аудиторії або на власному ноутбукові, назвавши документ «Лабораторна робота № ».

  8. Лабораторну роботу обов’язково потрібно оформлювати рамками, що передбачені ЄГР.

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


КОНТРОЛЬНІ ПИТАННЯ:

  1. Що таке модель конструювання?

  2. Коли вперше виникла концепція каскадної моделі?

  3. Назвіть основні переваги каскадної моделі?

  4. Назвіть основні недоліки каскадної моделі?



Лабораторна робота № 2
Тема: Проектування ПЗ за допомогою спіральної моделі
Мета: Навчитись проектувати гіпотетичне програмне забезпечення, спираючись на принципи, що закладені в спіральній моделі.
Завдання: Ознайомтесь з основними принципами спіральної моделі, оберіть будь-яку тему та спроектуйте гіпотетичне програмне забезпечення згідно етапів спіральної моделі. Кожний етап повинен бути супроводжений документацією.
untitled1
Згідно Джону Коннеллу (Connell) і Лінде Шафер (Shafer), еволюційним прискореним прототипом є «дуже піддатлива модифікації та розширенню робоча модель передбачуваної системи, не обов’язково представляє собою всі властивості системи, завдяки якій користувачі даного додатка отримують фізичне уявлення про ключові частинах системи до її безпосередньої реалізації; це – легко створювана, без праці піддатлива модифікації, максимально розширювана, частково задана робоча модель основних аспектів передбачуваної системи «.

Бернард Боаріо (Bernard Boar) визначив прототип як «метод, призначений для визначення вимог, при якому потреби користувача витягуються, представляються і розробляються за допомогою побудови робочої моделі кінцевої системи – швидко і в необхідному контексті».

Стало класикою твір Фреда Брукса (Fred Brook) під назвою «Легендарний людина-місяць» (The Mythical Man-Month) сьогодні настільки ж актуально, як і в 1975 році. Технології радикально змінили світ, але багато недоліків менеджменту програмних проектів як і раніше ті ж. Десятки років тому Брукс сказав: «У більшості проектів перша побудована система навряд чи придатна до вживання. Вона може бути занадто повільної, дуже об’ємною, незручною у використанні або володіти всіма трьома перерахованими недоліками. Немає іншого вибору, окрім як почати з самого початку, приклавши всі зусилля, і побудувати модернізовану версію, в якій вирішувалися б всі три проблеми …

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

Отже, питання менеджменту полягає не в тому, створювати чи ні експериментальну систему, якої потім не скористаються. Ви в будь-якому випадку так і зробите. Єдине питання в тому, чи потрібно планувати створення продукту одноразового використання заздалегідь або обіцяти поставити його замовникам … «

Саме ця концепція побудови експериментальної, або прототипну системи призвела до виникнення «структурної», «еволюційної» моделі швидкого прототипування (RAD), і спіральної моделі. У своїй боле пізньої, в рівній мірі повної плідних ідей роботі під назвою «No Silver Bullet, the Essence and Accidents of Programming» Брукс вважає, що більшість помилок, що виникають при розробці ПЗ, все ж пов’язані з неправильним розумінням концепції системи, а не з синтаксисом або логікою. Розробка ПЗ завжди буде важким завданням, і ми ніколи не знайдемо чудодійну панацею або «срібну кулю». Він підкреслює позитивний момент у застосуванні методів швидкого прототипування: «Найважчою складовою процесу побудови програмної системи є прийняття однозначного рішення про те, що саме необхідно побудувати. Жодна з інших складових роботи над концепцією не представляє собою таку трудність, як визначення детальних технічних вимог, включаючи всі аспекти зіткнення продукту з людьми, машинами та іншими програмними системами. Жодна інша складова роботи в такій ступені не завдає шкоди отриманої в результаті системі, якщо вона виконана неправильно. Саме цю складову процесу розробки найважче виправити на більш пізніх етапах.

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

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

Уотт Хемфрі (Watts Humphrey), який відомий як натхненник створення моделі СММ, розробленої Інститутом SEI, підтримує Брукса в його підході до важливості вимог і їх розробки: «У більшості систем укладений основний принцип, який включає в себе більше, ніж незначне еволюційна зміна. Система може змінити саме експлуатаційне оточення. Оскільки користувачі можуть міркувати про те чи іншому явищі тільки в рамках відомого їм оточення, вимоги до таких систем завжди формулюються в рамках поточного оточення. Отже, ці вимоги неодмінно будуть неповними, неточними і оманливими. Головним завданням для системного розробника є винахід процесу розробки, за допомогою якого можна буде виявити, визначити і розробити реальні вимоги. Цього можна досягти тільки при максимальному включенні користувача в процес розробки і часто з допомогою періодичного тестування прототипів або версій, отриманих на ранніх етапах розробки. Виявляється, що такі процеси завжди займають більше часу, але незмінно наприкінці призводять до розробки кращої системи набагато швидше, ніж при використанні будь-якої іншої стратегії «.

Переваги структурної еволюційної моделі швидкого прототипування

При використанні структурної еволюційної моделі швидкого прототипування для прийнятного проекту проявляються такі переваги:

• кінцевий користувач може «побачити» системні вимоги в процесі їх збору командою розробників; таким чином, взаємодія замовника з системою починається на ранньому етапі розробки;

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

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

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

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

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

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

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

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

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

• завдяки меншому об’єму доопрацювань зменшуються витрати на розробку;

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

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

• документація сконцентрована на кінцевому продукті, а не на його розробці;

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


  1. Робота повинна бути виконана згідно критеріїв оформлення документації на аркушах формату А4. У виняткових випадках допускається написання роботи в зошиті.

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

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

  4. Якщо потрібні пояснення – можна звернутись до викладача. Викладач сам вирішує відповідати на питання чи надати підказки, де можна знайти відповідь.

  5. Студенти можуть згрупуватись по дві-три людини та виконувати одне загальне завдання.

  6. Протягом виконання лабораторної роботи студенти можуть використовувати конспекти або інші джерела інформації.

  7. Роботу потрібно набирати на комп’ютері, що розташований в аудиторії або на власному ноутбукові, назвавши документ «Лабораторна робота № ».

  8. Лабораторну роботу обов’язково потрібно оформлювати рамками, що передбачені ЄГР.

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


КОНТРОЛЬНІ ПИТАННЯ:

  1. Коли вперше виникла концепція спіральної моделі?

  2. Назвіть основні переваги спіральної моделі?

  3. Назвіть основні недоліки спіральної моделі?

  4. Яка область використання спіральної моделі?



Лабораторна робота № 3
Тема: Вступ до екстремального програмування
Мета: Здобути теоретичні знання щодо методології екстремального програмування; навчитись використовувати принципи екстремального програмування при конструюванні власного програмного забезпечення.
Завдання: Ознайомтесь із основними принципами та технологіями, які пропонує екстремальне програмування. Спроектуйте гіпотетичне програмне забезпечення з використанням отриманої інформації. Дозволяється розподіл на групи по дві-три людини.
Екстремальне програмування (англ. Extreme Programming, XP) - одна з гнучких методологій розробки програмного забезпечення. Автори методології - Кент Бек, Уорд Каннінгем, Мартін Фаулер та інші.

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

Завдяки використанню надзвичайно коротких циклів розробки ХР пропонує швидку, реальну і постійно функціонуючу зворотний зв'язок.

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

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

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

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

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

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

ХР грунтується на методиках, які задовольняють як короткостроковим інстинктам окремих програмістів, так і довгостроковим інтересам всього проекту в цілому.

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

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

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

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

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

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

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

Екстремальне програмування запитує нас: чому б не виховати в собі хоробрість? Адже вона дуже важлива в роботі. Хіба можна без хоробрості взяти на себе відповідальність за виконання якогось завдання, та ще в конкретні терміни? Хіба можна без хоробрості усвідомити, що ти уперся в тупик, зробити крок назад і пошукати обхідний шлях? І, нарешті, що дозволить розробнику визнати свою помилку в оцінці завдання і вчасно попередити про це інших замість того, щоб поставити їх перед фактом вже тоді, коли всі терміни минуть? Користь хоробрості наявності, і кожен успіх, навіть у найменшій завданню, здатний цю хоробрість розвинути.

Екстремальне програмування (Extreme Programming, XP) виникло як еволюційний метод розробки ПЗ "знизу вгору". Цей підхід є прикладом так званого методу "живий" розробки (Agile Development Method). До групи "живих" методів входять, крім екстремального програмування, методи SCRUM, DSDM (Dynamic Systems Development Method, метод розробки динамічних систем), Feature-Driven Development (розробка, керована функціями системи) та ін

Основні принципи "живий" розробки ПЗ зафіксовані в маніфесті "живий" розробки, що з'явилося в 2000 році.

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

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

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

• Відпрацювання змін важливіша, ніж проходження планам.

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

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

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

За твердженням авторів XP, ця методика являє собою не стільки слідування якимось загальним схемами дій, скільки застосування комбінації наступних технік. При цьому кожна техніка важлива, і без її використання розробка вважається йде не по XP, згідно з твердженням Кента Бека (Kent Beck), одного з авторів цього підходу поряд з Уордом Каннінгемом (Ward Cunningham) і Роном Джефрісом (Ron Jeffries).

• Живе планування (planning game) Його завдання - якнайшвидше визначити обсяг робіт, які потрібно зробити до наступної версії ПЗ. Рішення приймається, в першу чергу, на основі пріоритетів замовника (тобто його потреб, того, що потрібно йому від системи для більш успішного ведення свого бізнесу) і, в другу, на основі технічних оцінок (тобто оцінок трудомісткості розробки, сумісності з іншими елементами системи та ін.) Плани змінюються, як тільки вони починають розходитися з дійсністю чи побажаннями замовника.

схема потока работ в xp
• Часта зміна версій (small releases)

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

• Метафора (metaphor) системи

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


Методичні вказівки до виконання роботи:

  1. Робота повинна бути виконана згідно критеріїв оформлення документації на аркушах формату А4. У виняткових випадках допускається написання роботи в зошиті.

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

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

  4. Якщо потрібні пояснення – можна звернутись до викладача. Викладач сам вирішує відповідати на питання чи надати підказки, де можна знайти відповідь.

  5. Студенти можуть згрупуватись по дві-три людини та виконувати одне загальне завдання.

  6. Протягом виконання лабораторної роботи студенти можуть використовувати конспекти або інші джерела інформації.

  7. Роботу потрібно набирати на комп’ютері, що розташований в аудиторії або на власному ноутбукові, назвавши документ «Лабораторна робота № ».

  8. Лабораторну роботу обов’язково потрібно оформлювати рамками, що передбачені ЄГР.

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



КОНТРОЛЬНІ ПИТАННЯ:


  1. Коли вперше виникло екстремальне програмування?

  2. Перерахуйте основні принципи екстремального програмування?

  3. Що таке програмування «знизу вгору»?

  4. Що таке «жива» розробка?

  5. Що таке «живе планування»?

Лабораторна робота № 4
  1   2   3   4   5


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

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