joined_document
.pdf
Так как на любом этапе жизненного цикла потенциально возможны ошибки, влияющие на последующие этапы, при выявлении таких ошибок целесообразно вернуться на тот этап, на котором была допущена ошибка, и исправить ее. Не всегда, правда, удается определить, на каком этапе была допущена ошибка, поэтому иногда используют возврат на предыдущий этап, если там ошибку исправить не удалось, то на предшествующий этому этап и так далее. Такая модель позволяет учесть самые разные факторы, влияющие на процесс разработки, и в пределе может дать идеальный результат. Но проблема использования такой модели заключается в непрогнозируемых материальных, людских и временных затратах. То есть с применением этой модели можно создать идеальную информационную систему, но вопрос, сколько времени и денег для этого понадобится.
Одним из способ решения такой проблемы является разбиение информационной системы на ряд подзадач, решение каждой из таких задач представляется как
20
разработка «мини информационной системы», для которой применяется своя модель жизненного цикла.
20
Такая модель получила название «итерационной», или спиралевидной. Итерацией в такой модели называется подзадача, отдельно решаемая с применением каждого из этапов. По завершении одной итерации, на которой были пройдены все этапы, начинается следующая итерация, на которой вся последовательность этапов повторяется снова.
При этом существует большое количество вариаций данной модели. Например, из циклического повторения этапов может исключаться анализ, проводимый только один раз вначале проекта, и / или внедрение, проводимое один раз в конце проекта. Такая модель часто и называется собственно итерационной.
Существует вариант итерационной модели, при котором каждая итерация может также «зацикливаться», то есть после завершения основной работы по итерации продолжается улучшение функционала до приемлемого уровня качества (при этом параллельно могут разрабатываться другие итерации). Такая модель часто и называется спиралевидной.
21
Методологии проектирования ИС
Парадигмы программирования
Процедурная
Структурная
Объектно-ориентированная
1
Модульное программирование
Нисходящий анализ
Сразу разрабатывается основная логика
Много «заглушек»
Восходящий анализ
Пишется только «полезный» код
Ошибки в анализе могут выявиться в последний момент
Модульное программирование
Нисходящий анализ
применяется на первых этапах
Восходящий анализ
применяется при «рефакторинге»
2
Структурная декомпозиция
компьютер
hardware |
software |
|||||
процессор |
|
|
|
операционная |
||
|
|
|
||||
|
|
|
система |
|||
|
|
|
|
|
|
|
память |
|
|
|
|
драйвера |
|
|
|
|
||||
материнская плата |
|
|
|
|
|
прикладные программы |
|
|
|
|
|||
Иерархическая декомпозиция
|
|
|
|
компьютеры |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
планшеты |
персональные |
сервера |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
на базе |
на базе iOS |
|
|
|||||
Android |
|
|
||||||
|
|
|
|
|
|
|
||
3
Анализ требований к информационной системе
Уровни требований
Бизнес-требования
Пользовательские требования
Функциональные и нефункциональные
требования
1
Бизнес-требование
Приложение должно хранить список книг библиотеки, фиксировать выданные читателям книги, отслеживать
длительность пользования экземпляром
книги
Пользовательские требования
Любой пользователь:
Выполнить поиск книги в библиотеке
2
Пользовательские требования
Неавторизованный пользователь:
Выполнить вход в систему
Пользовательские требования
Авторизованный пользователь:
Выполнить выход из системы
Сменить пароль
3
Пользовательские требования
Читатель:
Просмотреть список выданных ему книг
Просмотреть личные данные
Пользовательские требования
Библиотекарь:
Выдать читателю книгу
Отметить факт возврата книги
Просмотреть список выданных читателю книг
4