Мета: Навчитись конструювати нескладне ПЗ, розробляти вимоги до нього. Закріпити навички по будові діаграм засобами UML .
Теоретична частина
Розробка програмного забезпечення (ПЗ) – це складний процес, в який входить багато складових. В загальному випадку це:
- визначення проблеми;
- вироблення вимог;
- створення плану конструювання;
- розробка архітектури ПЗ, або високорівневе проектування;
- детальне проектування;
- кодування і відлагодження;
- блочне тестування;
- інтеграційне тестування;
- інтеграція;
- тестування системи;
- корегувальне супроводження.
Проектування ПЗ - це процес визначення архітектури, набору компонентів, їх інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту.
Термін конструювання програмного забезпечення (software construction) описує детальне створення робочої програмної системи за допомогою комбінації кодування, верифікації (перевірки), модульного тестування (unit testing), інтеграційного тестування та відлагодження.
На рисунку 9.1 показано місце конструювання як частину кроків серед процесів, що проходять при побудові ПЗ.
Рисунок 9.1 Конструювання серед процесів побудови ПЗ
Процеси конструювання зображені всередині сірого еліпсу. Головними компонентами конструювання є кодування та відлагодження, однак воно включає і детальне проектування, блочне тестування, інтеграційне тестування та інші процеси.
Іноді конструювання називають "кодуванням" або "програмуванням". Кодування в даному випадку видається не найкращим терміном, так як воно має на увазі механічну трансляцію розробленого плану в команди мови програмування, тоді як конструювання є зовсім не механічним процесом і часто пов’язане з творчістю та аналізом. Сенс слів "конструювання" та "програмування" досить близький.
Дана область знань пов'язана з іншими областями. Найбільш сильний зв'язок існує з проектуванням (Software Design) і тестуванням (Software Testing). Причиною цього є те, що сам по собі процес конструювання програмного забезпечення зачіпає важливі аспекти діяльності з проектування й тестування. Крім того, конструювання відштовхується від результатів проектування, а тестування (у будь-якій своїй формі) передбачає роботу з результатами конструювання. Досить складно визначити межі між проектуванням, конструюванням і тестуванням, тому що всі вони пов'язані в єдиний комплекс процесів життєвого циклу і, в залежності від обраної моделі життєвого циклу і застосовуваних методів (методології), таке розділення може мати різний вигляд.
Хоча ряд операцій з проектування детального дизайну може відбуватися до стадії конструювання, великий обсяг такого роду проектних робіт відбувається паралельно з конструюванням або як його частина. Це є сутність зв'язку з областю знань "Проектування програмного забезпечення".
Порядок виконання роботи
1. За обраною темою з лабораторної роботи №8 розробити вимоги до функціонального ПЗ:
- З конструювати ПЗ використовуючи рисунок 9.1;
- В UML побудувати діаграму варіантів використання;
- В UML побудувати діаграму діяльності.
2. Напишіть будь-яку нескладну програму на мові С++ або Delphi, наприклад: обчислення квадратного рівняння, обчислення площі трикутника за формулою Герону, тощо.
3. Розробити діаграму послідовності та потоку даних
4. Протестуйте програму та оформіть результати як лабораторну роботу.
Лабораторна робота 10. Документування ПЗ
Мета: Здобути навички по розробці та оформленні документації ПЗ, розробляти технічне завдання до ПЗ
Теоретична частина
Програми повинні бути відповідним чином задокументовані. Документація на програми стандартизована в рамках ЕСПД.
Документація включає:
1. Опис застосування:
– призначення програми;
– умови застосування;
– опис завдання.
2. Опис програми:
– загальні відомості;
– постановка задачі;
– опис логічної структури.
3. Керівництво по використанню:
– вхідні та вихідні дані;
– запуск програми;
– перевірка програми.
4. Текст програми
Вимоги до змісту технічного завдання визначає ГОСТ 19.201-78. Технічне завдання оформляють відповідно до ГОСТ 19.106-78 на аркушах формату А4 і А3, без заповнення полів сторінки. Номери сторінок проставляють у верхній частині сторінки над текстом.
Наявність титульної частини є обов’язковою. Інформаційну частину допускається в документ не включати.
Технічне завдання повинне містити наступні розділи:
- вступ;
- підстави для розробки;
- призначення розробки;
- вимоги до програми або програмного продукту;
- вимоги до програмної документації;
- техніко-економічні показники;
- стадії і етапи розробки;
- порядок контролю і приймання;
- у технічне завдання допускається включати додатки.
Залежно від особливостей програми або програмного виробу допускається уточнювати зміст розділів, вводити нові розділи або об'єднувати окремі з них.
У розділі “Вступ” вказують найменування, коротку характеристику області застосування програми або програмного продукту і об'єкту, в якому використовують програму або програмний продукт.
У розділі “ Підстави для розробки” повинні бути вказані:
- документ (документи), на підставі яких ведеться розробка;
- організація, що затвердила цей документ, і дата його затвердження;
- найменування і (або) умовне позначення теми розробки.
У розділі “ Призначення розробки” повинне бути вказане функціональне та експлуатаційне призначення програми або програмного продукту.
Розділ “Вимоги до програми або програмного продукту” повинен містити наступні підрозділи:
- вимоги до функціональних характеристик;
- вимоги до надійності;
- умови експлуатації;
- вимоги до складу і параметрів технічних засобів;
- вимоги до інформаційної і програмної сумісності;
- вимоги до маркірування і упаковки;
- вимоги до транспортування і зберігання;
- спеціальні вимоги.
У підрозділі “Вимоги до функціональних характеристик” повинні бути вказані вимоги до складу виконуваних функцій, організації вхідних і вихідних даних, тимчасових характеристик і т.п.
У підрозділі “Вимоги до надійності” повинні бути вказані вимоги для забезпечення надійного функціонування (забезпечення стійкого функціонування, контроль вхідної і вихідної інформації, час відновлення після відмови і т. п.).
У підрозділі “Умови експлуатації” повинні бути вказані умови експлуатації (температура навколишнього повітря, відносна вогкість і т.п. для вибраних типів носіїв даних), при яких повинні забезпечуватися задані характеристики, а також вид обслуговування, необхідна кількість і кваліфікація персоналу.
У підрозділі “Вимоги до складу і параметрів технічних засобів” указують необхідний склад технічних засобів з вказівкою їх основних технічних характеристик.
У підрозділі “Вимоги до інформаційної і програмної сумісності” повинні бути вказані вимоги до інформаційних структур на вході і виході, до методів рішення, початкових кодів, мов програмування і програмних засобів, що використовуються програмою. При необхідності повинен забезпечуватися захист інформації і програм.
У підрозділі “Вимоги до маркірування і упаковки” у загальному випадку указують вимоги до маркірування програмного продукту, варіанти і способи упаковки.
У підрозділі “Вимоги до транспортування і зберігання” повинні бути вказані для програмного продукту умови транспортування, місця зберігання, умови зберігання, умови складування, терміни зберігання в різних умовах.
У розділі “ Вимоги до програмної документації” повинен бути вказаний попередній склад програмної документації і, при необхідності, спеціальні вимоги до неї.
У розділі “ Техніко-економічні показники” повинні бути вказані: орієнтовна економічна ефективність, передбачувана річна потреба, економічні переваги розробки в порівнянні з кращими вітчизняними і зарубіжними зразками або аналогами.
У розділі “ Стадії і етапи розробки” встановлюють необхідні стадії розробки, етапи і зміст робіт (перелік програмних документів, які повинні бути розроблені, узгоджені і затверджені), терміни розробки, а також визначають виконавців.
У розділі “ Порядок контролю і приймання” повинні бути вказані види випробувань і загальні вимоги до приймання роботи.
У додатках до технічного завдання, при необхідності, приводять: перелік науково-дослідних і інших робіт, що обґрунтовують розробку; схеми алгоритмів, таблиці, описи, обґрунтування, розрахунки і інші документи, які можуть бути використані при розробці; інші джерела розробки.
Порядок виконання роботи
1. Згідно з тем лабораторної роботи №8 розробити документацію до ПЗ.
2. Розробити технічне завдання.
3. Оформити у вигляді звіту та здати роботу
Приклад оформлення технічного завдання.
Технічне завдання являє собою документ, в якому сформульовані основні цілі розробки, вимоги до програмного продукту, визначені терміни та етапи розробки і регламентований процес приймально-здавальних випробувань. У розробці технічного завдання беруть участь як представники замовника, так і представники виконавця. В основі цього документа лежать вихідні вимоги замовника, аналіз передових досягнень техніки, результати виконання науково-дослідних робіт, передпроектних досліджень, наукового прогнозування.
Розробка технічного завдання виконується в наступній послідовності. Перш за все, встановлюють набір виконуваних функцій, а також перелік і характеристики вихідних даних. Потім визначають перелік результатів, їх характеристики і способи подання.
Далі уточнюють середовище функціонування програмного забезпечення: конкретну комплектацію і параметри технічних засобів, версію операційної системи і, можливо, версії і параметри іншого встановленого програмного забезпечення, з яким належить взаємодіяти майбутньому програмному продукту.
У випадках, коли розробляється програмне забезпечення збирає та зберігає деяку інформацію або включається в управління будь-яким технічним процесом, необхідно також чітко регламентувати дії програми у випадку збоїв обладнання та енергопостачання.
Технічне завдання повинно містити такі розділи:
• вступ;
• найменування та область застосування;
• підстава для розробки;
• призначення розробки;
• технічні вимоги до програми або програмного виробу;
• техніко-економічні показники;
• стадії і етапи розробки;
• порядок контролю та приймання;
• додатки.
Залежно від особливостей програми або програмного виробу допускається уточнювати зміст розділів, вводити нові розділи або об'єднувати окремі з них. При необхідності допускається в технічне завдання включати додатки.
Приклад.
Програма сортування одномірного масиву.
1. Вступ.
Справжнє технічне завдання поширюється на розробку програми сортування одновимірного масиву методами бульбашки, прямого вибору, Шелла і швидкого сортування, призначеної для використання школярами старших класів при вивченні курсу шкільної інформатики.
2. Основа для розробки.
2.1 Програма розробляється на основі навчального плану кафедри «Інформатика та програмне забезпечення обчислювальних систем».
2.2 Найменування роботи:
«Програма сортування одновимірного масиву».
2.3 Виконавець: компанія BcstSoft.
2.4 Співвиконавці: відсутні.
3. Призначення
Програма призначена для використання школярами при вивченні теми «Обробка одновимірних масивів» в курсі «Інформатика».
4. Вимоги до програми або програмному продукту.
4.1. Вимоги до функціональних характеристик
4.1.1. Програма повинна забезпечувати можливість виконання таких функцій:
• введення розміру масиву і самого масиву;
• зберігання масиву і пам'яті;
• вибір метолу сортування;
• висновок текстового описі методу сортування;
• висновок результату сортування.
4.1.2. Вихідні дані:
• розмір масиву, заданий цілим числом;
• масив.
4.1.3. Організація вхідних і вихідних даних.
Вхідні дані надходять з клавіатури.
Вихідні дані відображаються на екрані і при необхідності виводяться на друк.
4.2.Требованія до надійності
Передбачити контроль введеної інформації. Передбачити блокування некоректних дій користувача при роботі з системою.
4.3.Требованія до складу і параметрів технічних засобів.
Система повинна працювати на IBM-сумісних персональних комп'ютерах.
Мінімальна конфігурація:
• тип процесора Pentium і вище;
• обсяг оперативного пам'яті 32 Мб і більше;
• обсяг вільного місця на жорсткому диску 40 Мб.
Рекомендована конфігурація:
• тип процесора Pentium II 400;
• обсяг оперативного пам'яті 128 Мб;
• обсяг вільного місця на жорсткому диску 60 Мб.
4.4. Вимоги до програмної сумісності.
Програма повинна працювати під управлінням сімейства операційних систем Win 32 (Windows 95/98/2000 / МЕ / ХР і таке інше)
5. Вимоги до програмної документації.
5.1. Програмні модулі, що розробляються повинні бути самодокументовані, тобто, тексти програм повинні містити всі необхідні коментарі.
5.2.Програма, що розробляється повинна включати довідкову інформацію про роботу програми, описи методів сортування та підказки учням.
5.3.У складі супроводжуючої документації повинні входити:
· Пояснювальна записка на п'яти аркушах, що містить опис розробки.
· Керівництво користувача.
Дата: 2016-10-02, просмотров: 356.
