Учреждение «Университет «Туран»
|
|
|
|
|
|
|
УТВЕРЖДЕНО на заседании кафедры «Информационные технологии» учреждения «Университет «Туран» Протокол № __ от «____»______ 2012 г. Заведующая кафедрой ______________________С.А. Тусупова
|
ЛЕКЦИОННЫЙ КОМПЛЕКС-КОНТЕНТ
(ТЕЗИСЫ ЛЕКЦИЙ, ИЛЛЮСТРАТИВНЫЙ И РАЗДАТОЧНЫЙ МАТЕРИАЛ, СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ)
«Методы структурного анализа и проектирования»
Специальность:6М070300 «Информационные системы» (магистратура, профильное, научное и педагогическое направление)
По дисциплине:Методы структурного анализа и проектирования
Авторы:Джапаров Б.А., д.т.н., профессор, Нысанбаева С.Е., д.т.н., профессор
Технология обучения:кредитная
Форма обучения: очное
Языковое отделение:русское
Система оценки знаний магистрантов:рейтинговая
Алматы, 2012
ГЛОССАРИЙ*
Авторская проверка — это процесс критической оценки собственной работы.
Авторская проверка — это процесс критической оценки собственной работы.
Анализ системы — определение того, что система будет делать.
Блоки на диаграмме - изображают системные функции.
Декомпозиция — это процесс создания диаграммы, детализирующей определенный блок и связанные с ним дуги.
Документирование проекта — создание базы данных проекта, текстуальное описание составных частей проекта.
Дуги - изображают множество различных объектов системы.
Моделирование в SADT - инженерная дисциплина, означает, что модели создаются исходя из действительной ситуации и что эти модели проходят через серию последовательных улучшений до тех пор, пока они в точности не будут представлять реальный мир.
Опрос - получение информации, необходимой для начала либо для продолжения построения определенной части модели.
Опросы для сбора фактов - проводятся, когда пытаются определить, как функционирует система в настоящее время.
Опросы для определения проблем - полезны, когда вы хотите выяснить, что в системе не в порядке.
Проектирование — определение подсистем и их взаимодействие,
Разработка спецификаций — формализованное описание требований.
Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое,
Свойства — это нефункциональные характеристики, именованные величины, описывающие некоторые важные аспекты объектов и функций системы.
Создание проекта — определение подсистем и взаимодействий между ними.
СПД - сетевое представление процессов, процедур, функций и данных, соединяющих их.
Структурный анализ - метод исследования, которой начинается с общего обзора системы и затем детализируется, приобретая иерархическую структуру со все большим числом уровней.
Субъект SADT моделирования – сама система
Тестирование — проверка работы системы.
Установка — введение системы в действие.
Формулировка требований и целей проекта — определение того, что проектируемая система будет делать.
Функционирование — использование системы.
ICOM - схема кодирования дуг, вход (Input), управление (Control), выход (Output), механизм (Mechanism).
SADT-диаграммы - декомпозиции ограниченных объектов.
SADT-модель — это описание системы, у которого есть единственный субъект, цель и одна точка зрения.
[gl] Тема 1 Понятие системного анализа. [:]
В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ). ЖЦ является моделью создания и использования ПО, отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей.
Традиционно выделяются следующие основные этапы ЖЦ ПО:
анализ требований,
проектирование,
кодирование (программирование),
тестирование и отладка,
эксплуатация и сопровождение.
ЖЦ образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе ЖЦ порождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки их соответствия исходным.
Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:
КАСКАДНАЯ МОДЕЛЬ(70-80г.г. 20 в.) - предполагает переход на следующий этап после полного окончания работ по предыдущему этапу.
ПОЭТАПНАЯ МОДЕЛЬ С ПРОМЕЖУТОЧНЫМ КОНТРОЛЕМ(80-85г.г. 20 в.) - итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки.
СПИРАЛЬНАЯ МОДЕЛЬ(86-90г.г. 20 в.) - делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Специалистами отмечаются следующие преимущества спиральной модели:
накопление и повторное использование программных средств, моделей и прототипов;
ориентация на развитие и модификацию ПО в процессе его проектирования;
анализ риска и издержек в процессе проектирования.
Главная особенность индустрии ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. Рассмотрим эти этапы более подробно.
АНАЛИЗ ТРЕБОВАНИЙ является первой фазой разработки ПО, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем ПО известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.
Список требований к разрабатываемой системе должен включать:
совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение);
описание выполняемых системой функций;
ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются:
архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонент ПО, их интерфейсы.
ЭТАП ПРОЕКТИРОВАНИЯ дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как "(итерационный) процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям". Обычно этот этап разделяют на два подэтапа:
проектирование архитектуры ПО, включающее разработку структуры и интерфейсов компонент, согласование функций и технических требований к компонентам, методам и стандартам проектирования, производство отчетных документов;
детальное проектирование, включающее разработку спецификаций каждой компоненты, интерфейсов между компонентами, разработку требований к тестам и плана интеграции компонент.
В результате деятельности на этапах анализа и проектирования должен быть получен проект системы, содержащий достаточно информации для реализации системы на его основе в рамках бюджета выделенных ресурсов и времени.