Тестування програмного забезпечення

Проектування програмного забезпечення

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

На цьому етапі:

1. Формується структура і визначається архітектура програмного забезпечення.

2. Визначаються модулі, які розділяються на ієрархічні рівні.

3. Вибирається структура інформаційних масивів, що становлять базу даних.

4. Розробляються алгоритми.

Мета етапу – це розбиття складних задач на під задачі меншої складності.

Програмування (реалізація)

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

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

Супровід програмного забезпечення

Супровід – це процес виправлення помилок та координація всіх елементів системи відповідно до користувача. Вносяться зміни в програмне забезпечення. Це відбувається з двох причин:

1. В програмне забезпечення залишаються помилки не виявлені під час тестування.

2. Користувачі хочуть вдосконалити програмне забезпечення або самі щось хочуть змінити.

Моделі розробки програмного засобу

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

Види моделей життєвого циклу: каскадна(водоспадна), спіральна, ітеративна.

Найбільшого поширення набули каскадна та спіральна модель розробки програмного засобу.

Каскадна (водоспадна) модель

Каскадна (водоспадна, 70 – 80 рр.) – в рамках цієї моделі процес розробки відбувається послідовно по етапах життєвого циклу. Водоспадна система застосовується для програм однорідних інформаційних систем. Її основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного стану на наступний відбувається тільки після того, як буде повністю завершена робота на поточному етапі. В даній курсовій роботі використовується саме ця модель.

Спіральна модель

Спіральна модель процесу(86 – 90 рр.) – передбачає послідовність етапів розробки життєвого циклу, яка виконується більше одного разу. Упор розробки робиться на етап «системний аналіз» і проектування. Кожний виток спіралі відповідає створенню фрагмента або версії програмного засобу. На нього уточнюються характеристики проекту і планується робота на наступному витку спіралі. При такому способі робіт буде повне виконання роботи на кожному етапі, але головне надати користувачу найшвидше працездатний продукт.

Ітеративна модель

Ітеративний підхід (англ. Iteration, «повторення») у розробці програмного забезпечення - це виконання робіт паралельно з безперервним аналізом отриманих результатів і коригуванням попередніх етапів роботи. Проект при цьому підході в кожній фазі розвитку проходить повторюваний цикл PDCA: Планування - Реалізація - Перевірка - Оцінка (англ. Plan-do-check-act cycle).

Технологія розробки програмного забезпечення

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

У програмі BPwin можна створювати моделі трьох видів. Для цього використовуються такі методології: IDEF0, IDEF3, DFD.

Методологія IDEF0

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

Діаграма складається з блоків і стрілок.

Функціональна діяльність – її робота(дієслово).

Перед тим, як створювати діаграму IDEF0 потрібно визначити:

1. Призначення моделі – це набір питань на які повинна відповідати модель.

2. Границі моделювання (її межі) – це рівень деталізації.

3. Точка зору – вибирається перспектива з якої бачиться система.

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

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

Методологія IDEF3

IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) - методологія моделювання і стандарт документування процесів, що відбуваються в системі. Метод документування технологічних процесів являє собою механізм документування та збору інформації про процеси. IDEF3 показує причинно-наслідкові зв'язки між ситуаціями і подіями в зрозумілій експерту формі, використовуючи структурний метод вираження знань про те, як функціонує система, процес або підприємство.

Методологія DFD

DFD - загальноприйняте скорочення від англ. Data Flow Diagrams - діаграми потоків даних. Так називається методологія графічного структурного аналізу, що описує зовнішні по відношенню до системи джерела і адресати даних, логічні функції, потоки даних і сховища даних, до яких здійснюється доступ.

Діаграма потоків даних (data flow diagram, DFD) - один з основних інструментів структурного аналізу і проектування інформаційних систем, що існували до широкого поширення UML. Незважаючи на що має місце в сучасних умовах зміщення акцентів від структурного до об'єктно-орієнтованого підходу до аналізу і проектування систем, «старовинні» структурні нотації раніше широко і ефективно використовуються як в бізнес-аналізі, так і в аналізі інформаційних систем.

Методологія UML

UML (англ. Unified Modeling Language - уніфікована мова моделювання) - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це - відкритий стандарт, який використовує графічні позначення для створення абстрактної моделі системи, званої UML-моделлю. UML був створений для визначення, візуалізації, проектування та документування, в основному, програмних систем. UML не є мовою програмування, але на підставі UML-моделей можлива генерація коду.

Діаграма варіантів використання (use case diagram) - діаграма, на якій зображуються відносини між акторами й варіантами використання.

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

Варіант використання описується овальною формою дієсловом, стрілки – зв’язки.

Дата добавления: 2015-06-27