ОППО_КР_пример_содержан

ВСТУП

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

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

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

Метою даною курсової роботи є проектування програмного забезпечення для автоматизації вирішення задач обліку продажів Інтернет магазину автозапчастин за етапами RUP/INCEPTION та RUP/ELABORATION.

1 ОГЛЯД ОСНОВНИХ ПРИНЦИПІВ СУЧАСНОЇ ПРОГРАМНОЇ ІНЖЕНЕРІЇ

1.1 Вивчення основних положень сучасної програмної інженерії

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

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

1.2 Ядро знань SWEBOK

Software Engineering Body Of Knowledge (SWEBOK) є продукцією Software Engineering Coordinating Committee під патронатом IEEE Computer Society.

SWEBOK всеосяжний термін, що описує загальні знання в рамках професії програмної інженерії. Так як зазвичай не вдається встановити повний звід знань, навіть нових дисциплін, таких, як програмне забезпечення, в єдиний документ, існує необхідність в керівництві знаннями з боку програмної інженерії[2].

SWEBOK описує 10 областей знань:

Software requirements – програмні вимоги;

Software design – дизайн (архітектура);

Software construction – конструювання програмного забезпечення;

Software testing – тестування;

Software maintenance – експлуатація (підтримка) програмного забезпечення;

Software configuration management – конфігураційне управління;

Software engineering management – управління у програмній інженерії;

Software engineering process – процеси програмної інженерії;

Software engineering tools and methods – інструменти і методи;

Software quality – якість програмного забезпечення.

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

Computer engineering – комп’ютерна інженерія;

Computer science – комп’ютерні науки;

Management – менеджмент;

Mathematics – математика;

Project management – керівництво проектом;

Quality management – керівництво якістю;

Systems engineering – системна інженерія.

SWEBOK не асоційований з тією чи іншою моделлю (наприклад, життєвого циклу) або методом. Хоча на перший погляд перші п’ять галузей знань у SWEBOK представлені в традиційній послідовній (каскадній - waterfall) моделі, це не більше ніж дотримання прийнятої послідовності висвітлення відповідних тем [3]. Перші п’ять галузей можна побачити на рисунку 1.1

Рисунок 1.1 – Галузь знань SWEBOK [3]

Інші п’ять галузей зображено на рисунку 1.2

Рис. 1.2 — Галузі знань SWEBOK зв’язних дисциплін [3]

1.3 Стандарти ISO/IEC 12207, ISO/IEC 9126

ISO/IEC 12207 є стандарт Міжнародної Організації зі Стандартизації для процесів життєвого циклу програмного забезпечення. Він прагне бути стандартом, який визначає всі завдання, необхідні для розробки і супроводу ПЗ.

ISO 12207 стандарт встановлює процеси життєвого циклу програмного забезпечення, у тому числі процеси та види діяльності, що застосовуються в ході придбання та налаштування послуг системи[4]. Кожен процес має множину результатів, пов'язаних з ним. Є 23 процеси, 95 заходів, 325 завдань та 224 підсумки (новий "ISO / IEC 12207:2008 системи та програмна інженерія – процеси

життєвого циклу програмного забезпечення" визначає 43 системні процеси та 43 процеси програмного забезпечення).

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

Стандарт розділяє життєвий цикл розробки ПЗ на п’ять основних процесів та відповідних наборів діяльностей.

Придбання (acquisition) – охоплює дії, залучені у запровадження проекту. Фаза придбання може бути розділена на різні заходи і матеріали, які будуть завершені в хронологічному порядку.

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

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

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

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

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

ISO 9126 — «Інформаційна технологія. Оцінка програмного продукту. Характеристики якості й посібник з їхнього застосування» (Software product Quality Requirements and Evaluation). Це міжнародний стандарт, що визначає оцінні характеристики якості програмного забезпечення[4].

Модель внутрішніх і зовнішніх характеристик якості ПЗ складається із шести груп базових показників, кожну з яких деталізовано декількома нормативними субхарактеристиками:

Функціональна придатність:

придатність до застосування;

коректність (вірність, точність);

здатність до взаємодії;

захищеність.

Надійність:

рівень завершеності (відсутність помилок);

стійкість до дефектів;

відновлюваність;

доступність;

готовність. Ефективність:

тимчасова ефективність;

використання ресурсів. Практичність (застосовність):

зрозумілість;

простота використання;

можливість вивчення;

привабливість. Підтримка:

зручність для аналізу;

здатність до змін;

стабільність;

зручність для тестування. Портативність:

адаптованість;

простота встановлення (інсталяції);

співіснування (відповідність);

заміщення.

Устандартах також визначена модель характеристик якості у використанні. Основними характеристиками якості ПЗ у використанні є:

системна ефективність та використання програмного продукту за призначенням;

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

безпека;

задоволення вимог та витрат користувачів згідно з метою застосування ПЗ

[4].

1.4 Основи методології та технології RUP

Rational Unified Process (RUP) – це методологія розробки програмного забезпечення, створена компанією Rational Software [5].

Воснові RUP лежать наступні принципи:

Рання ідентифікація і безперервне (до закінчення проекту) усунення основних ризиків;

Концентрація на виконанні вимог замовників до виконуваної програми(аналіз і побудова моделі прецедентів (варіантів використання));

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

Компонентна архітектура, що реалізовується і тестується на ранніх стадіях проекту;

Постійне забезпечення якості на всіх етапах розробки проекту (продукту);

Робота над проектом у згуртованій команді, ключова роль у якій належить архітекторам[5].

RUP використовує ітеративну модель розробки. В кінці кожної ітерації (в ідеалі що триває від 2 до 6 тижнів) проектна команда повинна досягти запланованих на дану ітерацію цілей, створити або допрацювати проектні артефакти і отримати проміжну, але функціональну версію кінцевого продукту. Ітеративна розробка дозволяє швидко реагувати на змінні вимоги, виявляти і усувати ризики на ранніх стадіях проекту, а також ефективно контролювати якість створюваного продукту.

Рисунок 1.3 – Графічне зображення процесу розробки за RUP-ом.

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

1Початок (Inception) - на цьому етапі:

Формуються бачення і межі проекту;

Створюється економічне обґрунтування (business case);

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

Створюється базова версія моделі прецедентів;

Оцінюються ризики.

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