- •«Проектирование ис» 2011
- •1. Понятие информационной системы. Типовые функциональные компоненты ис
- •2. Схема развития ис
- •3. Этапы проектирования ис
- •4. Понятие жизненного цикла ис, модели жизненного цикла информационной системы
- •5. Основные принципы создания ис
- •6. Требования к методологии и технологии разработки ис
- •7. Методология rad
- •8. Методы проектирования ис
- •9. Функционально-ориентированные методологии проектирования. Основные принципы функциональной методики idef0
- •10. Методология idef0. Виды стрелок на диаграммах idef0
- •11. Методология idef0. Нумерация работ и диаграмм. Каркас диаграммы
- •12. Методология idef0. Виды диаграммы idef0
- •13. Диаграммы потоков данных. Назначение. Нотации dfd. Рекомендации по построению
- •14. Основные элементы диаграмм dfd
- •15. Диаграммы dfd. Элементы для декомпозиции данных
- •16. Диаграммы dfd. Управляющие элементы диаграмм
- •17. Методология idef3. Назначение диаграмм. Основные элементы
- •18. Виды перекрестков на диаграммах idef3
- •19. SwimLane диаграммы и построение сценариев SwimLaneDiagrams (диаграмма плавательных дорожек).
- •20. Стоимостной анализ. Принципы связи abc анализа и idef0
- •21. Количественный и качественный анализ диаграмм модели idef
- •22. Моделирование данных. Архитектура ansi-sparc
- •24. Er-диаграммы. Определение сущности, атрибута, связи
- •25. Методология idef1x. Виды и мощности связей. Понятие зависимых и независимых сущностей
- •26. Методология idef1x. Виды зависимых сущностей
- •27. Нормальные формы er-диаграмм. Получение реляционной схемы из er-диаграмм
- •28. Реляционная модель данных. Структурная часть. Управляющая связь. Виды ключей
- •29. Реляционная модель данных. Набор ограничений целостности. Операции, нарушающие целостность
- •Ограничения кортежа.Ограничения целостности кортежапредставляют собой ограничения, накладываемые на допустимые значенияотдельногокортежа отношения, ине являющиесяограничением целостности атрибута.
- •30. Реляционная алгебра. Теоретико-множественные операции
- •31. Реляционная алгебра. Специальные операции
- •32. Реляционная модель данных. 1нф, 2нф, 3нф, нфбк
- •33. Реляционная модель данных. Нормальные формы более высоких порядков
- •36. Язык моделирования uml. Назначение. Характеристики. Перечень диаграмм
4. Понятие жизненного цикла ис, модели жизненного цикла информационной системы
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ разработки систем (Systems Development Life Cycle, SDLC) отслеживает историю ЖЦ ИС и представляет «полную картину», в рамках которой могут быть спланированы и качественно оценены и проекты БД и разработка прикладных программ. ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Методология проектирования ИС описывает процесс создания и сопровождения систем в виде ЖЦ ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственности участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом. Модель ЖЦ отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления.Модель ЖЦ – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. [ISO/IEC 12207]Модели жизненного цикла информационной системы.-Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок (т. е. единое целое). Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем [2]:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем. - Поэтапная модель с промежуточным контролем (рис. 2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. Однако, и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. -Спиральная модель. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо вводить временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. На практике наибольшее распространение получили две основные модели ЖЦ: - каскадная (период 1970-1985); -спиральная (после 1985).Сравнение моделей ЖЦНесмотря на настойчивые рекомендации компаний – вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели.