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




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

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

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

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



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

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

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

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. Продовження процесу виконання реалізується за допомогою впорядкованої послідовності кроків. У моделі передбачено, що кожна наступна фаза починається лише тоді, коли повністю завершено виконання попередньої фази Кожна фаза має певні критерії входу і виходу: вхідні і вихідні дані.

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

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



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

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



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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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


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

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

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

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

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



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


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

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