Документы, создаваемые в процессе анализа
Концепция системы/Business Vision
В первую очередь мы проводим предварительное интервью с заказчиком, во время которого определяются цель создания системы, её границы и её место в окружающем мире.
Бизнес-требования/BRD
Серия уточняющих интервью, в которых заказчик развивает свою идею. Уточняется и углубляется понимание проблем, которые система должна решать.
Функциональные требования/FRD
Поиск логических несоответствий, детализация требований до уровня, понятного программистам.
План тестирования/Test Plan
План тестирования необходим для команды тестировщиков и составляется на основе FRD и других сопутствующих документов. Цель данного документа – ответить на 3 главных вопроса: что, как и когда будет тестироваться.
Риски/Risk List
Зачастую вместе с FRD составляется специальный документ - список рисков. В документе учитываются основные риски, которые могут повлиять на разработку системы в заданный срок.
Особенности формирования ТЗ на создание ИС
В ТЗ на создание конкретной ИС, разрабатываемом в результате стадии предпроектного обследования, должно быть указание на имеющиеся исходные данные и на средства описания исходных данных. Ссылки в ТЗ на документы, определяющие выбранные средства описания исходных данных, являются частью профиля инструментальной среды, поддерживающей основные процессы: проектирование, разработку, сопровождение и развитие прикладного программного обеспечения ИС.
В ТЗ должны быть определены требования к жизненному циклу ИС и даны ссылки на действующие нормативные документы по жизненному циклу, т. е. определен профиль жизненного цикла ИС.
Аналогично в ТЗ задаются требования к качеству прикладного программного обеспечения ИС и соответственно первичный профиль качества.
В ТЗ задаются функциональные требования к ИС (состав задач, решаемых ИС) и указываются ссылки на ведомственные нормативные документы, которые регламентируют правила и процедуры выполнения функций и операций.
При этом стадии разработки профилей, которые определяются разработчиком системы по его усмотрению, должны быть увязаны со стадиями жизненного цикла ИС и выполняться во времени таким образом, чтобы эти разрабатываемые профили могли быть применены тогда, когда это требуется по логике детализации проекта.
Исходя из выбранной модели жизненного цикла ИС и возможного влияния решений, принимаемых на какой-либо стадии проекта, на решения, которые были предложены ранее, следует учитывать итерационный характер формирования функциональных профилей ИС и, при необходимости, корректировки ТЗ.
18. Проектирование ИС [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 7.2., 28.3., 31.3., 41.2. | Проектирование информационных систем. Базовые модели процесса разработки ИС. Методологии проектирования ИС. | Алексеев Пётр Сергеевич | Андрей Трифонов | ОПЛ (Ден), ответ Наташи, ответ Милы |
Ответ Наташи
Модели разработки ИС
Существует 3 типа моделей ЖЦ:
- Каскадная модель («водопад»)
- Спиральная модель («спираль»)
- Поэтапная модель («водоворот»)
1) Каскадная модель, в которой переход на следующий этап означает полное завершение работ на предыдущем этапе.
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ (или “водопад”). Его основной характеристикой является разбиение всей разработки на этапы, при этом переход на следующий этап происходит только после полного завершения работ на текущем (см. рис).
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. При этом этапы работ выполняются в логичной последовательности, что позволяет планировать сроки завершения всех работ и соответствующие затраты. Этот подход хорошо зарекомендовал себя при построении ИС, для которых в начале разработки можно достаточно точно и полно сформулировать все требования и предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Каскадная модельИС состоит из последовательно выполняемых этапов. Каждый этап полностью заканчивается до того, как начнется следующий. Этапы не перекрываются во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий. Возврат к предыдущим этапам не предусмотрен или всячески ограничен. Исправление ошибок происходит лишь на стадии тестирования. Результат появляется только в конце разработки ИС. Критерием появления результата является отсутствие ошибок и точное соответствие полученной ИС первоначальной её спецификации.
Для этой модели характерна автоматизация отдельных несвязанных задач, не требующая выполнения информационной интеграции и совместимости, программного, технического и организационного сопряжения. В рамках решения отдельных задач каскадная модель по срокам разработки и надёжности оправдывала себя. Применение каскадной модели к большим и сложным проектам вследствие большой длительности процесса проектирования и изменчивости требований за это время приводит к их практической нереализуемости.
Преимущества каскадной модели:
· Полная детальная постановка задачи дает ясное представление, какой функциональностью будет обладать ИС по окончанию разработки;
· Возможность определить точные сроки и стоимость проекта (так как набор необходимых функций ИС точно известен);
Недостатки каскадной модели:
· Длительный срок от начала работ до первой рабочей версии (реальная эксплуатация ИС начинается только на этапе внедрения);
· Возможное несоответствие нуждам заказчика (из-за длительного процесса разработки ИС потребности заказчика могут измениться, и Система не будет им соответствовать);
· Высокая стоимость внесения изменений (большинство ошибок и упущений обнаруживаются на этапах тестирования и внедрения, т.е. в конце проекта. Исправления приводят к повторению всех этапов);
· Частое нарушение сроков создания и превышение бюджета создания ИС (так как сроки и бюджет жестко фиксированы и не учитывают возможных недоработок постановки задачи и ошибок разработки).
· Создание и сопровождение огромного количества документации, которая должна сделать процесс разработки более контролируемым и формализованным.
Недостатки связаны с тем, что реальный процесс создания ПО ИС обычно не укладывается в такую жёсткую схему. Практически постоянно возникает потребность возвращаться к предыдущим этапам, уточнять или пересматривать принятые решения. В результате затягиваются сроки выполнения работы, пользователи могут вносить замечания лишь по завершению всех работ с системой. При этом модели автоматизируемого объекта могут устареть к моменту их утверждения.
2) Для преодоления этих проблем предложена спиральная модель ЖЦ (рис. 2.3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.
Рис 2.3. Спиральная модель.
В этой модели особое внимание уделяется начальным этапам разработки – выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание фрагмента (компонента) или версии программного продукта. На них уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
В этой модели результат появляется фактически на каждом витке спирали. Этот промежуточный результат анализируется, и выявленные недостатки ИС побуждают проведение следующего витка спирали. Таким образом последовательно конкретизируются детали проекта и в итоге выбирается и доводится до реализации обоснованный вариант. Спираль завершается тогда, когда клиент и разработчик приходят к согласию относительно полученного результата.
Модель состоит из последовательно расположенных этапов (как и “водопад”) в пределах одного витка спирали. Внутри витка спирали этапы не имеют обратной связи. Анализ результата осуществляется в конце витка и инициирует новый виток спирали. Исправление ошибок происходит при тестировании на каждом витке спирали. Ошибки, которые не могут быть исправлены и требуют более глубоких структурных изменений, инициируют новый виток спирали. Этапы могут перекрываться во времени в пределах одного витка спирали. Результат появляется в конце каждого витка спирали и подвергается подробному анализу. При переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов. Процесс ориентирован на развитие и модификацию ИС в процессе её проектирования, на анализ рисков и издержек во время проектирования.
Основная особенность данного метода состоит в концентрации сложности на начальных этапах разработки ИС (анализ, проектирование). Сложность и трудоёмкость последующих этапов в пределах одного витка спирали относительно невысокие. При этом методе предлагается способ снижения затрат в целом при разработке ИС (и любого иного ПО) за счёт предотвращения потенциальных ошибок на этапах её анализа и проектирования. При этом используется подход к организации проектирования ИС “сверху-вниз”, когда сначала определяется состав функциональных подсистем, а затем постановка отдельных задач.
Процессы моделирования всё чаще осуществляются с использованием специальных компьютерных программных средств, позволяющих автоматизировать эту деятельность.
3) Поэтапная (итерационная) модель с промежуточным контролем. Разработка ПО ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоёмкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.
В итерационной модели, так же, как и в модели “водопад” используется последовательность расположения этапов создания ИС. Но каждый следующий этап имеет обратную связь с предыдущими этапами. Исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы – промежуточный контроль. Следующий этап не начинается, пока не завершится предыдущий. При первом проходе по модели сверху вниз, как только обнаружена ошибка, осуществляется возврат к предыдущим этапам (снизу вверх), вызвавшим ошибку. Этапы оказываются растянутыми во времени. Результат появляется только в конце разработки ИС, как и в модели “водопад”.
Преимущества итерационной модели:
· Заказчик начинает использовать ИС значительно раньше, чем в других моделях разработки (в максимально короткий срок заказчик получает работоспособную версию ИС, в которой реализована часть функций, а каждый этап наращивает функциональность Системы, пока не будут удовлетворены все требования заказчика);
· Возможность легко удовлетворять изменившиеся требования к ИС (в ходе выполнения проекта, по окончанию каждого этапа, можно менять набор функций, цели создания ИС);
· Количество ошибок сведено к минимуму (подробная постановка задачи и проектирование в начале каждого этапа, а также многократное тестирование сводят к минимуму количество ошибок анализа, проектирования и разработки);
· Невысокая стоимость внесения изменений (благодаря своевременной реакции на изменения в бизнес-процессах заказчика и быстрому выявлению ошибок анализа и проектирования).
Недостатки итерационной модели:
· Общий срок создания ИС может отличаться от запланированного вначале (так как набор функций Системы может корректироваться);
· Стоимость создания ИС может изменяться (из-за изменения набора функций Системы, меняется объем работ и, следовательно, стоимость).