Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
TRPO_1-11.docx
Скачиваний:
1
Добавлен:
01.04.2025
Размер:
49.21 Кб
Скачать

В чем заключается суть водопадной модели жизненного цикла по? Для каких проектов эта модель наиболее применима?

Водопадная модель (каскадная) – реализует принцип однократного выполнения каждого вида деятельности в виде заранее ограниченных и однозначно упорядоченных во времени стадий этапов.

Каждый этап основывается на действиях предыдущего этапа. Процесс имеет пять этапов (шагов):

  1. анализ формирования требований. Путём консультаций с заказчиком определяются функциональные возможности, ограничения и цели создаваемой системы. Всё это фиксируется в письменном виде и передаётся заинтересованным сторонам на подпись;

  2. проектирование системы и ПО. Выработка решений удовлетворяющих всем требованиям и ограничениям. Разрабатывается общая архитектура системы и проект программных компонентов;

  3. кодирование и тестирование модулей;

  4. сборка и тестирование системы. Тестируется, удовлетворяет ли система своей спецификации;

  5. эксплуатация и сопровождение системы. Сопровождение системы включает исправление ошибок не обнаруженных на ранних этапах, совершенствование программных компонентов, подгонку функциональных возможностей под новые требования.

Достоинства модели:

  • даёт план и временной график по всем этапам проекта;

  • упорядочивает процесс разработки ПО.

Этот подход применим и эффективен, когда область проблемы хорошо изучена, но программирование является сравнительно молодой наукой.

Недостатки модели:

  • негибкое разбиение процесса на отдельные фиксированные этапы;

  • результаты проекта доступны заказчику только в конце работы;

  • цикл основан на чёткой формулировке требований, на первой стадии;

  • требования заказчика в начале проекта определены лишь частично и могут меняться.

Причины изменений требований:

  • меняется пользовательская среда (изменение бизнес-проектов), повышение образованности пользователей;

  • меняется задача;

  • меняются основные технологии;

  • появление нового программного или аппаратного обеспечения;

Всё это называется рисками программного проекта.

Риск – проектный фактор, который подвергает проект опасности.

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

Что такое «архитектура программного обеспечения»? Какие основные элементы в нее входят? Каким главным свойством, на Ваш взгляд, должна обладать высококачественная архитектура?

Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы.

Архитектура определяет структуру, состоящую из структурных элементов. Структурный элемент может быть подсистемой, процессом, библиотекой, базой данных, вычислительным узлом, системой в традиционном смысле, готовым продуктом и так далее.

Также стоит отметить следующие свойства:

  • Архитектура определяет поведение

  • Архитектура концентрируется на значимых элементах

  • Архитектура уравновешивает потребности заинтересованных лиц

  • Архитектура воплощает решения на основе логического обоснования

  • Архитектура может соответствовать некоторому архитектурному стилю

  • На архитектуру оказывает влияние ее окружение

  • Архитектура оказывает влияние на структуру коллектива

  • Архитектура представлена в каждой системе

Подробно обо всех свойствах http://www.ibm.com/developerworks/ru/library/eeles/

Примеры архитектурных стилей и моделей:

  • Blackboard

  • Клиент-серверная модель (client-server)

  • Архитектуры, построенные вокруг базы данных (database-centric architecture)

  • Распределенные вычисления (distributed computing)

  • Событийная архитектура (event-driven architecture)

  • Front end and back end

  • Неявные вызовы (implicit invocations)

  • Монолитное приложение (monolithic application)

  • Peer-to-peer

  • Пайпы и фильтры (pipes and filters)

  • Plugin

  • Representational State Transfer

  • Rule evaluation

  • Поиск-ориентированная архитектура

  • Сервис-ориентированная архитектура

  • Структурированная

  • Трех-уровневая

Кто входит в понятие «заинтересованные лица» при разработке требований? Почему их необходимо выявлять? Приведите пример заинтересованных лиц для своего проекта.

Заинтересованное лицо - это физическое лицо, группа или организация (или ее категории), которые заинтересованы в системе или имеют связанные с ней задачи.

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

К заинтересованным лицам могут относиться заказчики, разработчики или пользователи.

По википедии:

Заинтересованные лица являются людьми или организациями (юридические лица, такие как компании, комитеты по стандартизации), у которых есть действительный интерес к системе. Они могут быть затронуты этой системой прямо или косвенно. Начиная с 1990-х основной акцент при разработке требований ставится на идентификации заинтересованных лиц. При этом нужно учесть что заинтересованные лица не ограничены организацией, нанимающей аналитика. К заинтересованным лицам также относятся:

  • любой, кто пользуется системой (пользователи и обслуживающий персонал)

  • любой, кто извлекает выгоду из системы (функциональную, политическую, финансовую и социальную)

  • любой вовлечённый в покупку или обеспечение системы

  • организации, которые регулируют аспекты системы (финансовые, безопасность, и другие)

  • люди или организации, настроенные против системы (отрицательные заинтересованные лица),

  • организации, ответственные за системы, которые взаимодействуют с системой согласно проекту

  • те организации, которые объединяются горизонтально с организацией, для которой аналитик проектирует систему

15

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]