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



Скачати 158.32 Kb.
Дата конвертації18.04.2016
Розмір158.32 Kb.
#11873
ТипМетодичні вказівки
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

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

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

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



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

до виконання контрольної роботи

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

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

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

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

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

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

від ___________201_ р.


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

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

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

ЗАГАЛЬНІ ПОЛОЖЕННЯ
Виконання контрольних робіт спрямовано на закріплення теоретичних знань та практичних навичок при вивченні дисципліни.

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

В результаті виконання контрольних робіт студент повинен знати:


  • Життєвий цикл програм;

  • Планування та управління проектами;

  • Тестування та забезпечення якості;

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

  • Організація команди розробників;

  • Документація;

  • Супровід;

  • Стандарти якості програмного забезпечення: ISO 9000, CASE-засоби розробки;

  • Структурний проектування;

  • Висхідний і спадний способи проектування та реалізації ПЗ;

  • Реінжиніринг програмного забезпечення;

  • Вбудовані системи синтаксичного аналізу.

Вміти:


  • Самостійно вивчати необхідні знання з предметної області;

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

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

  • Організовувати верифікацію, тестування і перевірку стабільності ПЗ;

  • Здійснювати розробку користувальницького інтерфейсу і інтеграцію проекту.

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



Контрольна робота
Вимоги до оформлення:


  1. Контрольна робота має один варіант для усіх студентів, виконується на аркушах формату А4 в друкованому варіанті згідно ДСТУ 30008-95. Також допускається виконання роботи у письмовому вигляді в окремому зошиті.

  2. Контрольна робота складається з двох завдань, а саме – дати розгорнуту відповідь на поставлене питання, а також побудувати одну або дві діаграми UML.

  3. Контрольна робота повинна бути здана на реєстрацію не пізніше ніж за тиждень до заліку або екзамену.

  4. Контрольна робота повинна містити в собі наступні розділи:

  • Титульний лист, на якому позначається назва дисципліни, ПІБ розробника, ПІБ викладача;

  • Тема;

  • Мета;

  • Завдання;

  • Відповідь на теоретичне питання;

  • Розроблені діаграми;

  • Перелік використаної літератури та інформаційних джерел;

  • Лист із заголовком «Рецензія», на якому викладач вказує помилки чи остаточну оцінку.

Контрольна робота № 1
Тема: Життєвий цикл програмного забезпечення. Мови конструювання.
Мета: Здобути теоретичні та практичні навички використання мов конструювання. Здобути теоретичні навички про життєвий цикл програмного забезпечення.
Завдання:

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

  2. Побудуйте діаграми прецедентів, класів та послідовності для обраної власноруч предметної області. Якщо обрати тему проблематично – звернутись до викладача, щоб він видав індивідуальне завдання.


Короткі теоретичні відомості:
Існують різні визначення технології розробки ПЗ. Нижче наведені найбільш поширені з них. Технологія розробки програмного забезпечення – це сукупність процесів і методів створення програмного продукту.

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

Технологія розробки програмного забезпечення – це система інженерних принципів для створення економічного ПО із заданими характеристиками якості.

Близьким за змістом до терміну технологія розробки ПЗ є широко використовуваний в даний час термін програмна інженерія (software engineering). Будь технологія розробки ПО базується на деякій методологи або сукупності методологій.

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

ПО – впровадження методів розробки ПС, що забезпечують досягнення відповідних характеристик якості.

В даний час широку популярність придбали два базових принципи розробки ПС: модульний і об’єктно-орієнтована.

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

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

Об’єктно-орієнтована розробка базується на застосуванні об’єктних методів, до яких відносяться методології об’єктно-орієнтованого аналізу, проектування і програмування.

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

Програмний модуль (software unit) – окремо налізуємо частина програмного коду (програми).

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

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

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

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

В даний час базовим стандартом в області ЖЦ ПС і систем є-ється міжнародний стандарт ISO / IEC 12207:2008 – Системна і програмна інженерія – Процеси життєвого циклу програмних засобів. У Республіці Білорусь c 2004 діє національний стандарт СТБ ІСО / МЕК 12207-2003 – Інформаційна технологія – Процеси життєвого циклу програмних коштів, що є автентичним аналогом попередньої редакції міжнародного стандарту ISO / IEC 12207:1995.

Відповідно до стандарту СТБ ІСО / МЕК 12207-2003 під життєвим циклом програмного засобу або системи мається на увазі сукупність процесів, робіт і завдань, що включає в себе розробку, експлуатацію та супровід програмного засобу або системи і охоплює їх життя від формулювання концепції до припинення використання. ЖЦ ПС складається з процесів. Кожен процес ЖЦ розділений на набір робіт. Кожна робота розділена на набір завдань.

Процеси ЖЦ ПС діляться на три групи:

• основні;

• допоміжні;

• організаційні.

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

• замовлення;

• постачання;

• розробка;

• експлуатація;

• супровід.

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

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

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

1) підготовка процесу розробки;

2) аналіз вимог до системи;

3) проектування системної архітектури;

4) аналіз вимог до програмних засобів;

5) проектування програмної архітектури;

6) технічне проектування програмних засобів;

7) програмування і тестування програмних засобів;

8) складання програмних засобів;

9) кваліфікаційні випробування програмних засобів;

10) збірка системи;

11) кваліфікаційні випробування системи;

12) введення в дію програмних засобів;

13) забезпечення приймання програмних засобів.

При виконанні роботи 1 «Підготовка процесу розробки» вибирається модель ЖЦ ПС і систем. У дану модель структуруються процеси, роботи і завдання стандарту СТБ ІСО / МЕК 12207-2003. Вибираються і адаптуються стандарти, методи, інструментальні засоби розробки, мови програмування. Формується план проведення робіт процесу розробки.

При виконанні роботи 2 «Аналіз вимог до системи» аналізується область застосування системи. На підставі результатів аналізу предметної області визначаються вимоги до ній. Виконується оцінка розроблених вимог.

При виконанні роботи 3 «Проектування системної архітектури» оп-чається загальна архітектура системи. Здійснюється розподіл вимог до системи між об’єктами технічних і програмних засобів архітектури і ручними операціями. Виробляється подальше уточнення вимог. Здійснюється оцінка архітектури системи і вимог до об’єктів архітектури.

При виконанні роботи 4 «Аналіз вимог до програмних засобів» аналізується призначення програмного засобу. Виходячи з результатів аналізу визначаються і уточнюються вимоги до програмного засобу. Виконується оцінка розроблених вимог.

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

При виконанні роботи 6 «Технічне проектування програмних засобів» здійснюється детальне проектування програмного засобу (розробляється технічний проект для компонентів програмного об’єкта).

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

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

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

Входы



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




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



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

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

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

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


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

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


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. Леффингуэлл Дин, Уидриг Дон. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. – М.: Изд. «Вильямс», 2012 г. – 448 с.

  2. Робертс Джейсон. Многоядерное программирование. – Спб.: Изд. «Питер», 2010 г. – 320 с.

  3. Фаулер Мартин. Рефакторинг. Улучшение существующего кода. – М.: Изд. «Символ-Плюс», 2005 г. – 432 с.

  4. Вигерс И. Карл. Разработка требований к программному обеспечению. – М.: Изд. «Русская Редакция», 2004 г. – 576 с.

  5. Магда Юрий. Программирование последовательных интерфейсов. – М.: Изд. «Вильямс», 2009 г. – 304 с.

  6. Макконелл Стивен. Сколько стоит программный проект? – Спб.: Изд. «Питер», 2007 г. – 304 с.

  7. www.intuit.ru – сайт із коспектами лекціями з дисципліни «Конструювання програмного забезпечення».

  8. http://www.lektorium.tv/course/?id=22930 – курс лекцій «Сучасні технології розробки програмного забезпечення».

  9. http://www.lektorium.tv/course/?id=22743 – курс лекцій «Динамічне програмування».

  10. http://www.lektorium.tv/course/?id=22757 – курс лекцій «Паралельне програмування».

Каталог: download -> version
version -> Екологічне право україни: сучасний етап вступ
version -> Конспект лекцій для студентів спеціальностей
version -> Дидактика як галузь педагогіки, її виникнення і розвиток
version -> Про особливості діяльності практичних психологів (соціальних педагогів) загальноосвітніх навчальних закладів в 2001-2002 навчальному році
version -> «Система роботи класного керівника з формування правового світогляду та культури учнівської молоді»
version -> Південноукраїнський національний педагогічний університет імені К. Д. Ушинського
version -> Діагностика готовності дітей до школи
version -> Методичні рекомендації щодо формування позитивних мотивів навчання; Об’єкт вивчення Позитивні мотиви в навчанні молодших школярів

Скачати 158.32 Kb.

Поділіться з Вашими друзьями:




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

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