Ім'я файлу: IPZ-31 Pra 2 Denysenko Nikita.docx
Розширення: docx
Розмір: 209кб.
Дата: 24.12.2020
скачати
Пов'язані файли:
Курсова Денисенко.docx

Практична робота №2. Стандарт і моделі життєвого циклу.

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

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

Виділяють такі розповсюджені типи моделей життєвого циклу ПС:

  • Каскадна

  • Інкрементна

  • Спіральна

  • V-подібна

  • Ітеративна

  • Еволюційного протипування

  • Адаптивні моделі

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

Еволюційна модель має певні переваги у розробці даної програми:

  1. В еволюційній моделі вимоги можливо уточнювати в кожному наступному проміжному блоці структури системи.

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

  3. Зворотний зв'язок із замовником для уточнення функціональних вимог.

  4. Можливість збільшення фінансування системи.

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



Схема реалізації еволюційної моделі

Кількість ітерацій буде залежати від внесених змін вимог.

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

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

  • основні процеси (процес придбання, процес постачання, процес розроблення, процес експлуатації, процес супроводження);

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

  • організаційні процеси (створення інфраструктури, керування, навчання, вдосконалення).

Для кожного з процесів визначені види діяльності (дії – activity), задачі, сукупність результатів (виходів) діяльності і розв’язання задач, а також деякі специфічні вимоги.

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

  • процес придбання - описує дії замовника (customer) ПС;

  • процес постачання - визначає дії з передачі покупцю програмного продукту або сервісу;

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

  • процес експлуатації - визначає дії підприємства-оператора, що забезпечує обслуговування системи в ході її експлуатації користувачами

  • процес супроводження - визначає дії організації, що виконує супровід програмного продукту

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

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

Документування передбачає формалізований опис інформації, створеної протягом ЖЦ ПС.

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

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

Аудит - визначення відповідності вимогам, планам і умовам договору.

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

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


скачати

© Усі права захищені
написати до нас