Елементи структурного підходу

Правила розробки інтерфейсу

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

Прості правила дизайну:

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

Правило 2. Такі поля як OK або Cancel, повинні знаходитися з правого боку.

Правило 3. Переклади повинні бути змістовними.

Правило 4. Діалогові вікна повинні відповідати потоку даних між користувачем і системою.

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

Правило 6. Ми повинні пам'ятати про надсилання підтверджень користувачеві. У випадку об'ємних команд користувач повинен отримувати інформацію про відправлення йому команди. Зображення може бути виконане у формі текстової інформації, відсотків виконання команди, "термометра".

Правило 7. У системи повинна бути проста обробка помилок. Помилка повинна бути показана, а правильні дані повинні використовуватися для виконання наступного завдання.

Правило 8. У системи повинна бути операція "відміна". У найпростішому випадку система повертається до останньої операції. У складніших - до попередніх.

Правило 9. Система повинна давати змогу користувачеві контролювати роботу. Користувачі не люблять операцій, що ініціюються без їх відома. Такі операції не повинні робитися системою, а реакція на команди Esc, Ctr+C, Break… повинна бути дуже швидкою.

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

Правило 11. Зв'язані операції повинні бути об'єднані в один діалог. Якщо це неможливо, операції повинні бути розділені таким чином, щоб зв'язані діалоги були доступні.

Правило 12. Потрібно дотримуватися правила Міллера. Правило Міллера 7+/-2 говорить, що людина може зосередитися на 5-9 елементах. Правило повинне застосовуватися при проектуванні меню, підменю, діалогових полів і т.д. Правило може бути реалізоване шляхом декомпозиції інтерфейсу і його подальшим групуванням в об'єднані групи.

 

Елементи структурного підходу

Структурні методи комбінують статичний опис процесів і статичні моделі даних.

До цього класу моделей належать наступні підходи:

методи Yourdon (DeMarco і Ward/Mellon),

методологія структурного системного аналізу і дизайну (Structured System Analysis and Design Methodology, SSADM),

техніка структурного аналізу і дизайну (Structured Analysis and Design Technique, SADT).

Згідно з DeMarco, структурний аналіз використовує наступні методи:

Словник баз даних,

Схеми потоків даних,

Структурована англійська мова,

Таблиці рішень,

Дерева рішень.

Інші методи:

Схема перетворення,

Діаграма зміни станів,

Список подій,

Схема даних,

Пред- і післяумови,

Діаграми відносин "сутність-зв'язок",

Історія життя об'єкту.

Недолік використання структурного підходу - труднощі в об'єднанні моделей.

 

3.Прапорці потоку даних (малюнки не витирати! Вони є ключовими у відповіді!)

Виклик пов'язаний з потоком даних від модуля запиту до викликаного модуля і навпаки. Перший відповідає параметрам вводу, останній - параметрам виводу.

Малюнок 7.5.5. Прапори потоку даних.

Малюнок 7.5.6. Використання даних.

Структурні діаграми відформатовані зверху-вниз, тобто модулі запиту вище викликаних модулів.

Структурні діаграми являються специфікацією блок-схем даних.

Високорівневий модуль, який є джерелом даних, викликає модуль нижчого рівня, який є одержувачем даних.

Малюнок 7.5.7. Структурні діаграми проти DFD.

Постійність бази даних

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

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

База даних характерна постійним зберіганням, обмеженим об'ємом і хорошою організацією.

Постійність

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

 

Обмеження бази даних

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

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

База даних характерна постійним зберіганням, обмеженим об'ємом і хорошою організацією.

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

 

Послідовність бази даних

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

 

Зв’язок бази даних з реальністю

Цей постулат є критичним у формулюванні вимоги для бази даних. Наприклад, якщо база даних описує тотожність тобто ім'я, прізвище, адресу, положення і т.д., послідовність означає, що дані зміняться згідно тільки реальним змінам, тобто положення міняється, якщо службовець отримує підвищення. Бази даних повинні оновлюватися згідно з фактичними даними. Зв'язність - це нелегке завдання. Бізнес не може бути повністю комп'ютеризовано. Людина - важливий компонент системи. Процедури повинні розроблятися ретельно, і людські ресурси повинні бути відповідальною частиною системи. Процедура надсилання інформації повинна бути описана в процедурах. Дані оновлення - одна з найважчих проблем, зокрема, коли є багато баз даних і багато систем в компанії. Таким чином виконується відповідна інтеграція систем (підсистеми) в модулі, і обмін даними виконується модулями.

 

Контроль копіювання даних

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

 

Модель даних

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

 

Доступність даних

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

 

Безпека даних

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

 

Критерії вибору СУБД

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

Найважливіші критерії відбору СУБД:

Продуктивність

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

Масштабованість

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

Функціональність

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

Узгодження із стандартами

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

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

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

Надійність

Надійність позначає частоту відмов. Чим вище надійність - тим вище вартість.

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

Підтримка

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

Середовище розробки

Середовище розробки описує, на яких апаратних засобах і програмному забезпеченні система працюватиме.

Вартість

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

 

Методи оптимізації системи

Для оптимізації роботи системи застосовуються наступні методи:

використання статичних змінних замість динамічних,

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

вибір типів з мінімальними величинами.

Ці методи можуть призвести до менш зрозумілого коду замість його оптимізації. Обработа помилок може стати складнішою або неможливою.

Кориснішим було б проведення оптимізації ще на етапі дизайну або навіть аналізу.

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

 

 

Фізична структура системи

Одним із завдань етапу дизайну - описати фізичну структуру системи.

Вона включає:

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

- Декомпозиція системи на конкретні програми.

- Фізичний розподіл даних і програм.

 

Верифікація діаграм класів

Всі діаграми проекту повинні бути веріфіковані.

У верефікації діаграм класів потрібно враховувати наступне:

ациклічні відносини узагальнення-спеціалізації,

варіанти відносин циклічного об'єднання,

класи, що не мають відношення до інших класів, не повинні бути включені. Але іноді таке трапляється,

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

 

Співпраця з клієнтом

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

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

Оцінка вартості рішень

Оцінка вартості визначається для кожного з варіантів рішень.

Вартість складають наступні аспекти:

· вартість апаратури,

· вартість навчання професіоналів,

· вартість придбання інструментів,

· робоче навантаження.

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

 

37. Алгоритмічні методи. Вони вимагають атрибути даних у формі номерів або описів. Відповідна математична формула видає результат.

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

Метод COCOMO (Constructive Cost Model). Метод заснований на декількох формулах, які дають змогу зробити оцінку повної вартості, якщо відома кількість рядків коду. Це є слабким місцем методу. Функціональний метод. Метод оцінює вартість, базуючись на функціях, які повинні бути реалізовані. Метод Delphi. Цей метод заснований декількома експертами, які не мають зв'язку між собою.

Аналіз активних дій. Проект ділиться на дії, відомі з попередніх проектів.

 

38. Метод COCOMO (Constructive Cost Model). Метод заснований на декількох формулах, які дають змогу зробити оцінку повної вартості, якщо відома кількість рядків коду. Це є слабким місцем методу. Число рядків може бути відоме тільки коли розробка архітектури системи завершена, що зазвичай надто пізно. Поняття "рядок коду" залежить від мови програмування. COCOMO пропонує декілька рішень: просте, середньої складності і складне (детальне). Простий метод обчислює вартість, застосовуючи просту формулу для оцінки числа людей і місяців, потрібних для завершення проекту. Метод середньої складності змінює результати простого методу, враховуючи нові чинники, які залежать від складності проекту. Складний метод враховує нові чинники і вплив інших факторів на систему, але це не призводить до збільшення точності оцінок.

 

39. Функціональний метод. Метод оцінює вартість, базуючись на функціях, які повинні бути реалізовані. Тому метод може бути застосований тільки після того, як функції стануть хоча б приблизно відомі. Метод включає кількість введень, виводів, необхідний розмір пам'яті і інші критерії. Компоненти множаться на вагу, після чого підводяться підсумки. Результат представляється як точка функції. Вартість може змінюватися, якщо з'являться складніші умови програмування. Існує спосіб перетворення цієї суми у вартість рядків коду (COCOMO). Метод широко використовується і має лише невеликі недоліки.

 

40. Метод Delphi. Цей метод заснований декількома експертами, які не мають зв'язку між собою. Експерти обчислюють витрати незалежно один від одного, базуючись на їх власному досвіді. Вони анонімні. Вони обгрунтовують свої оцінки, після чого координатор отримує їх результати. У разі великих відмінностей в оцінках обчислюється середня величина і посилається назад експертам. Процедура повторюється поки не буде досягнута угода.

 

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

 

Рівні опису вимог?

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

Задоволення вимог - це структурована форма ясності вимог, що використовує загальну мову і базові структури.

Специфікація ПЗ - формальний опис вимог.

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

46 .Основні вимоги до опису вимог по системі?

Хороший опис вимог повинен задовольняти наступні вимоги:

· бути повним і послідовним,

· описувати зовнішній режим роботи,

· описувати обмеження системи,

· бути доступним для модифікування,

· брати до уваги можливі майбутні зміни,

· описувати швидкодію системи в екстремальних або небажаних ситуаціях.

 

Методи опису вимог?

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

· Математичний формалізм – вживається рідше, ніж колись.

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

· Табліци, форми. Вимоги задані в таблицях (зазвичай двохрівневі), асоційовані різними зв'язками (наприклад, таблиця із зв'язками типів користувачів із сервісами).

· Блоки і діаграми: графічні форми, що зображують процеси.

· Контекстні діаграми: показують системи, оточення, входи і виходи.

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

 

Типи вимог?

Функціональні вимоги(Описують функції (дії, операції) виконувані системою, що використовує зовнішні системи)

нефункціональні вимоги(Обмеження ф-них(у вигляді таблиці))

 

Якість документа з вимогами

Найбільш важливі чинники для якісних вимог:

Стиль

· Ясність: однозначне формулювання, ясне для користувача і розробника,

· Структура документа,

· Відповідність: ніяких протиріч у формуванні вимог,

· Змінність: формулювання по ключових моментах.

Гнучкість

· Можливість додавання нових вимог.

Специфікація ролей

· Можливість пов'язати особу з вимогою, описувати дію вимоги.

Помірність

· Паперовий або електронний варіант,

· Контроль версії документа.

Словник

Не може бути незрозумілих термінів для якої-небудь із сторін.

Всі специфічні треміни повинні бути додані в словник.

Всі невизначеності повинно бути уточнено. Приклад:

Термін	Визначення	Синоніми
Банківський рахунок	Послідовність номерів, записаних через дефіс, що визначають ресурси та операції клієнта	рахунок

 

 

Що є метою побудови моделі?

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

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

· модель вимог - описується, наприклад, випадками використання,

· аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

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

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

Які існують моделі?

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

· модель вимог - описується, наприклад, випадками використання,

· аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

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

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

Логічна модель:

· показує, що повинна робити система,

· показує ієрархію системи,

· уникає термінології реалізації,

· дозволяє ухвалювати рішення "від причини до наслідків" і назад.

Моделі об'єктів

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

 

Аналітична модель

Хороша аналітична модель повинна мати наступні характеристики:

· вона повинна бути спрощеним описом системи,

· функції повинні бути представлені ієрархічно,

· логічна модель повинна слідувати певним правилам,

· модель повинна будуватися за допомогою добре відомих методів і інструментів,

· модель використовується для ухвалення рішень в подальшому дизайні.

Модель ПЗ повинна бути спрощеним описом, який представляє найважливіші особливості ПЗ на високому абстрактному рівні.

Результати етапу аналізу?

Результи цього етапу наступні:

· задовільні вимоги, описані в документі,

· словник даних,

· документація моделі, що містить:

· діаграми класів,

· діаграми випадків використання,

· діаграми послідовності повідомлень,

· діаграми станів,

· визначення класів, атрибутів, відносин, методів і т.д.

· графік етапу дизайну,

· попереднє визначення персоналу і терміну.

Поняття про методологію швидкої розробки програмних ужитків (RAD)?

Швидка розробка програм (rapid application development, RAD)

Швидкою розробкою програм називаються методи швидкого прототипування або отримання готових застосувань. Вони отримані з комп'ютерних методів бачення. Термін RAD використовується іноді як синонім мов/середовищ розробки нового покоління (4GL). Приклади RAD-інструментів: Borland Delphi RAD Pack, IBM Visual Age (для Small Talk), Microsoft Access Developer’s Toolkit, Microsoft Visual FoxPro Professional, Visual Studio FoxPro, PowerBuilder Desktop, Power++ та інші.

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

 

Розробка інтерфейсу?

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

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

 

Сутність моделі водоспаду?

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

 

Переваги і недоліки моделі

Основна перевага каскадної моделі - керованість. Модель полегшує планування і моніторинг.

Серед недоліків є наступні:

· Необхідність дотримуватись встановленого порядку проведення робіт.

Програмісти віддають перевагу вільнішому стилю роботи.

· Підвищення ціни наслідків помилок, зроблених на різних етапах. Помилки,

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

· Довгий період, протягом якого немає контакту з клієнтом. Тільки стратегічний етап, формулювання вимог і етапу аналізу здійснюються за участю клієнта.

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

 

Переваги і недоліки моделі

Переваги і недоліки моделі

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

Недоліки моделі такі ж, як у каскадної моделі. Ще одним недоліком є: потрібно вкладати більше інвестицій в роботу з підготовки документів (наприклад ті, що відповідають стандарту DOD STD 2167, складають більше 50% всього робочого навантаження); потрібні паузи в розробці ПЗ для перевірки документів клієнтом. Деякі організації, наприклад IEEE, пропонують свої власні стандарти для документованого виконання програмних проектів.

 

Сутність прототипування?

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

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

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

Прототипування – це модель, яка прагне мінімізувати ризик помилок у формулюванні вимог.

 

Мета побудови прототипу?

Головна мета розробки прототипу - краще формулювання вимог, тобто:

· знаходження відмінностей між побажаннями клієнта і розробника

· виявлення відсутніх функцій

· виявленняя найбільш складних операцій

· формулювання вимог по деталізації

Методи побудови прототипу?

· Часткова реалізація (тільки частина вимог виконана. Прототипуються лише найважчі вимоги).

· Мови високого рівня (Smalltalk, LISP, Prolog, мови подальших поколінь, мови формальної функціональної специфікації)

· Використання готових компонентів.

· Генератори інтерфейсу користувача (реалізація прототипу часто обмежується розробкою інтерфейсу користувача).

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

· Робота на папері (це швидкий і зручний метод розробки інтерфейсу користувача, який замовники, зазвичай, високо цінують).

·

·

·

·

·

·

Переваги і недоліки моделі

Переваги:

· менші часові розриви у взаємодії із замовником

· можливість більш швидкого використання частин системи

· гнучкість при затримках в роботі

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

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

 

Переваги і недоліки моделі

Переваги використання готових компонентів:

· висока надійність, - готові компоненти добре перевірені на практиці

· зменшення ризику

· ефективне використання експертів

· стандартні вимоги. Готові компоненти реалізовувалися відповідно до деяких стандартів, які повинні бути задоволені в поточному проекті.

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

Недоліками моделі є:

· додаткова вартість створення компонентів для подальшого використання (компоненти системи повинні бути розроблені для користування. Вартість інвестицій може не відшкодуватися в майбутньому).

· Залежність від одного постачальника (постачальник може перестати розробляти бібліотеку або не модифікувати її під нові вимоги ПЗ чи нову апаратуру).

· Недолік інструментів, що підтримують роботу (у разі CAD/CAM, які, як було згадано вище, служать в інших дисциплінах тієї ж мети, що і CASE, мають можливість використання бібліотек готових компонентів. Інструменти CASE підтримували в обмеженому об'ємі цей вид роботи до останнього часу. Сучасні інструменти кращі, але розробка нових все ще необхідна).

 

 

·

·

·

·

·

·

·

·

·

·

·

·

·

·

Дії на стратегічному етапі?

На цьому етапі виконуються наступні дії:

· обговорення проекту з представниками клієнта

· визначення мети проекту з точки зору клієнта

· визначення можливостей і контексту проекту

· приблизне формулювання вимог, аналіз і проект системи

· формулювання альтернативних рішень

· аналіз

· представлення результатів представникам клієнта і здійснення виправлень

· попереднє планування і вибір структури команди

· стандартні визначення

Типи вимог?

Вимоги до ПЗ можуть бути розділені на два типи:

· Функціональні вимоги. Вони описують функції (операції, дії), що виконуються системою;

· Нефункціональні вимоги. Вони описують обмеження функціональності.

Сутність етапу аналізу?

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

Мета проектування полягає в тому, щоб визначити, як система повинна бути реалізована.

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

Етап аналізу також називають етапом моделювання. Логічна модель на цьому етапі покращує розуміння системних вимог.

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

 

Сутність етапу реалізації?

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

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

· відхід від ризикованих методів (наприклад, використання вказівників),

· обмежені принципи доступу (розділення пам'яті, інкапсуляція),

· використання типізованих мов і компіляторів,

· використання мов високого рівня,

· послідовність у використанні інтерфейсів між модулями,

· врахування надзвичайних ситуацій (порожні множини, цикли, невизначеності),

· використання існуючих компонентів,

· мінімум відмінностей між концептуальною моделлю і моделлю реалізації.

Сутність етапу тестування?

Під тестуванням розуміють:

· сертифікацію - перевірка відповідності системи вимогам клієнта;

· перевірка - перевірка відповідності системи вимогам етапу формулювання вимог.

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

Тести розрізнять по деяких критеріях.

Види тестів?

Розрізняються такі тести:

· динамічні - які порівнюють результати роботи програми з правильними результатами

· статичні - засновані на аналізі коду.

Фази тестування?

Фази тестування:

· тестування модулів (виконується після їх конструювання і реалізації).

· тестування системи (виконується після її інтеграції. Воно охоплює тестування системи і всіх модулів).

· приймальне випробування (системи, які розроблені для клієнта, передаються клієнтам і перевіряється ними. Такі т