Определение модели жизненного цикла разработки ПП

Автор: Пользователь скрыл имя, 15 Января 2013 в 22:22, лабораторная работа

Описание работы

Каскадная модель максимально проста, она хорошо подходит для небольших проектов, когда требования определены заранее и их изменение исключено. В случае с библиотекарской системой учета, ее функции заведомо очевидны (хранение информации о книгах (названия, авторы, id, возможность брать книгу на дом) и читателях (ФИО, адрес, телефон, книги на руках, данные о времени взятия книги и т.п.)) => нет необходимости изменения требований в процессе работы (все можно предусмотреть заранее). Каскадно-возвратную модель использовать в данном случае не целесообразно, т.к. в этом случае нет возможности определить все требования в самом начале, а время разработки небольшого проекта может затянуться. Однако, при разработке любого ПО следует учитывать возможные риски (что не предусмотрено в каскадной модели), это позволяет спиральная модель. Используя эту модель, мы можем учесть любые требования заказчика, а синтезировав ее с простой каскадной моделью, нам удастся избежать усложнения структуры разработки.

Скачать полностью (98.91 Кб) Сколько стоит заказать работу?
Работа содержит 1 файл

ЛР1.docx

— 112.59 Кб (Скачать)

 

Министерство  образования  и науки Российской Федерации 
Федеральное агентство по образованию 
Государственное образовательное учреждение высшего профессионального образования 
«САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ МЕХАНИКИ И ОПТИКИ» 
ФАКУЛЬТЕТ СРЕДНЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

 

 

 

 

Лабораторная  работа № 1

На тему: Определение модели жизненного цикла разработки ПП

по дисциплине: ТРПП

 
 

 

 

 
 
 
Выполнила: 
Студентка группы 313 
Руденко Яна

Оценка:_______

Проверил: 
Антонов М.Б 
Дата:__________

Подпись:_______

 

 

 

 

 

 

Санкт-Петербург 
2012г.

Модели жизненного цикла  и их характеристики

 

Название модели

Модель

Характеристика (+/- для внутренней/внешней сред)

1

Каскадная

  1. Простота
  2. На каждой стадии формируется законченный набор проектной документации
  3. Определение основных требований в начале проекта
  1. Невозможно начать следующий этап, не закончив предыдущий
  2. Нельзя возвращаться на предыдущий этап
  3. Результат в самом конце разработки
  1. Понятность
  1. Нет возможности менять требования по мере развития проекта
  2. Результат в самом конце разработки

2

Каскадно-возвратная

  1. Самая простая модель
  1. Время жизни каждого из этапов растягивается на весь период разработки
  2. Нет возможности определить требования в начале
  3. Невозможно спланировать что-либо заранее (например, сколько сопровождать проект)
  4. Можем переходить только на один этап
  1. Возможность дополнять (корректировать) требования

–

3

Прототипированная

  1. Решение возникающих проблем на ранних стадиях
  1. Невозможно спланировать время
  2. Заказчик может предпочесть прототип
  3. Тесное сотрудничество с заказчиком (не всегда является недостатком, однако в большинстве случаев доставляет разработчику ряд неудобств)
  1. Заказчик в курсе действий разработчика на каждом этапе
  2. Разработчик может учесть любые пожелания заказчика
  1. Невозможно знать точное время завершения работ над проектом

4

Инкрементная или итерационная

  1. Легкость дополнения новых функций 
  2. Снижен риск неудачи
  3. Простое внедрение
  1. Возможны ситуации, требующие добавления сразу нескольких взаимосвязанных функций
  2. Первоначальная ошибка в проектировании может привести к краху системы
  1. Снижен риск неудачного релиза
  2. После каждой итерации получаем новый продукт
  3. Упрощённое внедрение
  1. Модель никак не уменьшает ни временные, ни финансовые затраты

5

Спиральная модель

 
  1. Легкость дополнения новых функций 
  2. Снижен риск неудачи
  3. Простое внедрение
  4. Разработчик может учесть любые пожелания заказчика
  1. Усложнённая структура разработки
  1. Есть возможность корректировать требования

–

6

Модель, основанная на использовании  предыдущих разработок

  1. Увеличивает производительность разработки
  2. Уменьшение затрат на разработку
  1. Возможно наследование ошибок
  1. Простое внедрение
  1. без наличия других продуктов, модель не реализуема

7

V-образная (Verification)

  1. Определение всех требований в начале разработки
  2. Каждые полученные данные подвергаются тестированию
  3. Модель проста в работа
  1. В модель не входят действия, направленные на анализ рисков
  1. Можно отслеживать ход процесса разработки
  2. Завершение каждой фазы является контрольной точкой (возможность контроля)
  1. Нет возможности вносить изменения требования



 

Исследование оптимальности моделей, применимо к проекту

Целью проекта  является разработка автоматизированной библиотекарской системы учета. В ходе данной работы необходимо выявить жизненные циклы, наиболее оптимальные для выполнения данной задачи. На мой взгляд таковыми являются:

  1. Каскадная модель


  1. Спиральная модель


 

 

 

 

 


 

 

 



 

 

Каскадная модель максимально проста, она хорошо подходит для небольших проектов, когда требования определены заранее и их изменение исключено. В случае с библиотекарской системой учета, ее функции заведомо очевидны (хранение информации о книгах (названия, авторы, id, возможность брать книгу на дом) и читателях (ФИО, адрес, телефон, книги на руках, данные о времени взятия книги и т.п.)) => нет необходимости изменения требований в процессе работы (все можно предусмотреть заранее). Каскадно-возвратную модель использовать в данном случае не целесообразно, т.к. в этом случае нет возможности определить все требования в самом начале, а время разработки небольшого проекта может затянуться. Однако, при разработке любого ПО следует учитывать возможные риски (что не предусмотрено в каскадной модели), это позволяет спиральная модель. Используя эту модель, мы можем учесть любые требования заказчика, а синтезировав ее с простой каскадной моделью, нам удастся избежать усложнения структуры разработки.

Таким образом начнем работу по спиральной модели, выполнив один виток, затем переедем на этап реализации в каскадную модель, внеся необходимые коррективы и дополнения:


 

 

 

 

 

 

 

 

 

 

Получившаяся  в результате модель, на мой взгляд, оптимальна для реализации проекта  по созданию автоматизированной библиотекарской  системы учета, т.к. несмотря на малый  объем и относительную простоту данного проекта мы учитываем  и устраняем возможные риски (которые  могут быть связаны, например, со временем), имеем возможность дважды протестировать проект, внося незначительные коррективы, но в то же время, строго ограничиваем количество этапов жизненного цикла, оптимизируя время разработки.


Информация о работе Определение модели жизненного цикла разработки ПП