Файл: Отчет по практической работе дисциплина Качество информационных систем.docx
Добавлен: 18.01.2024
Просмотров: 208
Скачиваний: 1
| № критерия | Критерии категории требований | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Являются ли требования к проекту легко определимыми и реализуемыми? | Да | Нет | Да | Нет | Нет |
| 2. | Могут ли требования быть сформулированы в начале ЖЦ? | Да | Да | Да | Да | Нет |
| 3. | Нужно ли демонстрировать требования с целью их определения? | Да | Нет | Нет | Да | Да |
| 4. | Нужно ли реализовать основные требования на ранних этапах разработки? | Да | Да | Да | Да | Да |
| № критерия | Критерии категории команды разработчиков проекта | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Являются ли проблемы предметной области проекта новыми для большинства разработчиков? | Нет | Нет | Да | Да | Да |
| 2. | Являются ли инструментальные средства, используемые в проекте, новыми для большинства разработчиков? | Да | Нет | Нет | Да | Нет |
| 3. | Приемлет ли команда разработчиков оценки, проверки, стадии разработки? | Нет | Да | Нет | Нет | Нет |
| № критерия | Критерии категории коллектива пользователей | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Будет ли присутствие пользователей ограничено в ЖЦ разработки? | Нет | Нет | Нет | Нет | Да |
| 2. | Будут ли пользователи вовлечены во все фазы ЖЦ разработки? | Нет | Нет | Нет | Да | Нет |
| № критерия | Критерии категории типов проекта и рисков | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Разрабатывается ли в проекте продукт нового для организации направления? | Нет | Да | Да | Да | Нет |
| 2. | Будет ли проект являться расширением существующей системы? | Да | Да | Да | Нет | Да |
| 3. | Необходим ли высокий уровень надежности продукта проекта? | Нет | Да | Да | Нет | Да |
| 4. | Является ли график сжатым? | Нет | Да | Нет | Да | Нет |
| 5. | Предполагается ли повторное использование компонентов? | Нет | Да | Да | Да | Да |
| 6. | Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)? | Нет | Нет | Нет | Да | Да |
Задание №5. Расположите по степени важности критерии.По степени важности, выбор модели для ЖЦ системы «Диагностика локальных сетей» используется следующий порядок:
| № критерия | Критерии категории требований | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Нужно ли реализовать основные требования на ранних этапах разработки? | Да | Да | Да | Да | Да |
| 2. | Могут ли требования быть сформулированы в начале ЖЦ? | Да | Да | Да | Да | Нет |
| 3. | Нужно ли демонстрировать требования с целью их определения? | Да | Нет | Нет | Да | Да |
| 4. | Являются ли требования к проекту легко определимыми и реализуемыми? | Да | Нет | Да | Нет | Нет |
| № критерия | Критерии категории команды разработчиков проекта | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Являются ли проблемы предметной области проекта новыми для большинства разработчиков? | Нет | Нет | Да | Да | Да |
| 2. | Являются ли инструментальные средства, используемые в проекте, новыми для большинства разработчиков? | Да | Нет | Нет | Да | Нет |
| 3. | Приемлет ли команда разработчиков оценки, проверки, стадии разработки? | Нет | Да | Нет | Нет | Нет |
| № критерия | Критерии категории коллектива пользователей | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Будет ли присутствие пользователей ограничено в ЖЦ разработки? | Нет | Нет | Нет | Нет | Да |
| 2. | Будут ли пользователи вовлечены во все фазы ЖЦ разработки? | Нет | Нет | Нет | Да | Нет |
| № критерия | Критерии категории типов проекта и рисков | Каскадная | RAD | Инкрементная | Быстрого прототипирования | Эволюционная |
| 1. | Будет ли проект являться расширением существующей системы? | Да | Да | Да | Нет | Да |
| 2. | Предполагается ли повторное использование компонентов? | Нет | Да | Да | Да | Да |
| 3. | Разрабатывается ли в проекте продукт нового для организации направления? | Нет | Да | Да | Да | Нет |
| 4. | Необходим ли высокий уровень надежности продукта проекта? | Нет | Да | Да | Нет | Да |
| 5. | Является ли график сжатым? | Нет | Да | Нет | Да | Нет |
| 6. | Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)? | Нет | Нет | Нет | Да | Да |
реализация этого процесса должна быть гибкой, что обеспечивается с помощью настраиваемых моделей жизненного цикла разработки ПО.
Ответы на вопросы:
Вопрос №1. Модель быстрого протитипирования предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.
Начало жизненного цикла разработки помещено в центре эллипса.
Следующий уровень – создание исходного прототипа на основе быстрого анализа, проекта база данных, пользовательского интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования.
После этого следуют тестирование в предельных режимах, определение квалификационных критериев и настройка, а затем, как обычно, функциональное сопровождение.
Вопрос №2. XP-процесс - облегченный (подвижный) процесс (или методология). ХР-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.
Основная идея ХР — устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов* и реляционных баз данных.
Вопрос №3.
Зрелость процессов — это степень их управляемости, контролируемости и эффективности.
Макетирование — это процесс создания объемного изображения, позволяющего определить параметры пространственной структуры, размеров, пластики и пропорций поверхностей.
Вывод: в ходе данной практической работы мы познакомились с моделями жизненного цикла, научились выбирать и адаптировать модель жизненного цикла, подходящей к условиям конкретного проекта.