Завдання І. Життєвий цикл інформаційної системи. Порівняння моделей життєвого циклу

Завдання ІІ. Бізнес-процеси складського підрозділу

Список використаної літератури

Завдання І. Життєвий цикл інформаційної системи. Порівняння моделей життєвого циклу

Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ).

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

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії й задачі, які повинні бути виконані під час створення ПЗ.

Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:

1. основні процеси ЖЦ ПЗ (придбання, поставка, розробка, експлуатація, супровід);

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

3. організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка й поліпшення самого ЖЦ, навчання).

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

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

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

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

У процесі реалізації проекту важливе місце займають питання ідентифікації, опису й контролю конфігурації окремих компонентів і всієї системи в цілому. Керування конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, насамперед процеси розробки й супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожний з яких може мати різновиди або версії, виникає проблема врахування їхніх зв'язків і функцій, створення уніфікованої структури й забезпечення розвитку всієї системи. Керування конфігурацією дозволяє організувати, систематично враховувати й контролювати внесення змін у ПЗ на всіх стадіях ЖЦ. Загальні принципи й рекомендації конфігураційного обліку, планування й керування конфігураціями ПЗ відбиті в стандарті ISO 12207-2.

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

ЖЦ ПЗ носить ітераційний характер : результати чергового етапу часто викликають зміни в проектних рішеннях, прийнятих на більш ранніх етапах.

Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Під моделлю ЖЦ розуміється структура, що визначає послідовність виконання й взаємозв'язки процесів, дій і задач, виконуваних протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, у яких остання створюється й функціонує.

Регламенти ISO/IEC 12207 є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії й задачі, включені в ці процеси.

На сьогодні найбільше поширення одержали наступні дві основні моделі ЖЦ:

· каскадна модель (70-85 р.г.);

· спіральна модель (86-90 р.г.).

Спочатку в однорідних ІС кожний додаток був єдиним цілим. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбивка всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (Рис.1).

Рис. 1.1. Каскадна схема життєвого циклу ПЗ

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

Позитивні сторони застосування каскадного підходу полягають у наступному:

— на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти й погодженості;

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

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

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

Рис2. Реальний процес розробки ПЗ за каскадною схемою

--> ЧИТАТЬ ПОЛНОСТЬЮ <--