Информационные системы

Размещено на http://www.allbest.ru/

Содержание

Введение

Глава 1. Основы методологии проектирования ИС

1.1 История развития информационных технологий

1.2Жизненный цикл по ИС

1.3Модели жизненного цикла ПО

Глава 2. Методологии и технологии проектирования ИС

2.1 Общие требования к методологии и технологии

2.2 Методология RAD

Глава 3. Структурный подход к проектированию ИС

3.1 Сущность структурного подхода

3.2 Принципы, на которых базируется структурный подход. Метод SADT. Метод DFD

3.3 Метод функционального моделирования SADT

3.4 Состав функциональной модели

Заключение

Список использованной литературы



Введение

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики. Современные крупные проекты ИС характеризуются, как правило, следующими особенностями: сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов; наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема); отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем; необходимость интеграции существующих и вновь разрабатываемых приложений; функционирование в неоднородной среде на нескольких аппаратных платформах; разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств; существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.

Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.

Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

информационный технология компьютер проектирование



Глава 1. Основы методологии проектирования ИС

1.1 История развития информационных технологий

До второй половины 19 века основу информационных технологий составляли перо, чернильница и бухгалтерская книга. Коммуникация (связь) осуществляется путем направления пакетов (депеш). Продуктивность информационной обработки была крайне низкой, каждое письмо копировалось отдельно вручную, помимо счетов, суммируемых так же вручную, не было другой информации для принятия решений.

На смену «ручной» информационной технологии в конце 19 века пришла «механическая». Изобретение пишущей машинки, телефона, диктофона, модернизация системы общественной почты - все это послужило базой для принципиальных изменений в технологии обработки информации и, как следствие, в продуктивности работы. По существу «механическая» технология проложила дорогу к формированию организационной структуры существующих учреждений [10].

40 - 60-е гг. 20 века характеризуются появлением «электрической» технологии, основанной на использовании электрических пишущих машинок со съемными элементами, копировальных машин на обычной бумаге, портативных диктофонов. Они улучшили учрежденческую деятельность за счет повышения качества, количества и скорости обработки документов.

Появление во второй половине 60-х годов больших производительных ЭВМ на периферии учрежденческой деятельности (в вычислительных центрах) позволило смесить акцент в информационной технологии на обработку не формы, а содержания информации. Это было началом формирования «электронной», или «компьютерной» технологии. Как известно информационная технология управления должна содержать как минимум три важнейших компонента обработки информации: учет, анализ и принятие решений. Эти компоненты реализуются в «вязкой» среде - бумажном «море» документов, которое становится с каждым годом все более необъятным.

Сложившиеся в 60-х годах концепции применения автоматизированных систем управления (АСУ) не всегда и не в полной мере отвечают задаче совершенствования управления и оптимальной реализации компонентов информационной технологии, методологически эти концепции нередко опираются на представления о неограниченных возможностях «кнопочной»информационной технологии при непрерывном наращивании вычислительной мощности систем АСУ в применении наиболее общих имитационных моделей, которые в ряде случаев далеки от реального механизма оперативного управления.

Название «автоматизированная система управления» не совсем корректно отражает функции, которые такие системы выполняют, точнее было бы «автоматизированные системы обеспечения управления» (АСОУ), ибо в существующих АСУ, понятие «система» не включает решающего звена управления - пользователя. Игнорирование этого принципиального обстоятельства, по видимому, привело к тому, что расширение сети АСУ и повышение мощности их вычислительных средств обеспечили благодаря большим массивам первичных данных улучшение в основном учетных функций управления (справочных, статистических, следящих). Однако учетные функции отражают только прошлое состояние объекта управления и не позволяют оценить перспективы его развития, т.е. обладают низким динамизмом. В других компонентах технологии управления наращивание мощности АСУ не дало ощутимого эффекта. Отсутствие развитых коммуникационных связей рабочих мест пользователя с центральной ЭВМ, характерный для большинства АСУ пакетный режим обработки данных, низкий уровень аналоговой поддержки - все это фактически не обеспечивает высокого качества анализа пользователями данных статистической отчетности и всего интерактивного уровня аналитической работы. Тем самым эффективность АСУ на нижних ступенях управленческой лестницы, т.е. именно там, где формируются информационные потоки, существенно падает вследствие значительной избыточности поступающей информации при отсутствии средств агрегирования данных. Именно по этой причине, не смотря на ввод дополнительной системы АСУ, с каждым годом возрастает количество работников, занятых учетными функциями: на сегодняшний день шестую часть всех работников аппарата управления составляет учетно-бухгалтерский персонал.

Начиная с 70-х годов сформировалась тенденция перенесения центра тяжести развития АСУ на фундаментальные компоненты информационных технологий (особенно на аналитическую работу) с максимальным применением человеко-машинных процедур. Однако по-прежнему вся эта работа проводилась на мощных ЭВМ, размещенных централизованно в вычислительных центрах. При этом в основу построения подобных АСУ положена гипотеза, согласно которой задачи анализа и принятия решений относились к классу формализуемых, поддающихся математическому моделированию. Предполагалось, что такие АСУ должны повысить качество, полноту, подлинность и своевременность информационного обеспечения лиц, принимающих решения, эффективность работы которых будет возрастать благодаря увеличению числа анализируемых задач.

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

С появлением персональных компьютеров на «гребне микропроцессорной революции» происходит принципиальная модернизация идеи АСУ: от вычислительных центров и централизации управления, к распределенному вычислительному потенциалу, повышению однородности технологии обработки информации и децентрализации управления. Такой подход нашел свое воплощение в системах поддержки принятия решений (СППР) и экспертных системах (ЭС), которые характеризуют новый этап компьютеризации технологии организационного управления по существу - этап персонализации АСУ. Системность - основной признак СППР и признание того, что самая мощная ЭВМ не может заменить человека. В данном случае речь идет о структурной человеко-машинной единице управления, которая оптимизируется в процессах работы: возможности ЭВМ расширяются за счет структуризации пользователем решаемых задач и пополнения ее базы знаний, а возможности пользователя - за счет автоматизации тех задач, которые ранее было нецелесообразно переносить на ЭВМ по экономическим или техническим соображениям. Становится возможным анализировать последствия различных решений и получать ответы на вопросы типа: «что будет, если...?», не тратя времени на трудоемкий процесс программирования.

Важнейший аспект внедрения СППР и ЭС - рационализация повседневной деятельности работников управления. В результате их внедрения на нижних ступенях управления существенно укрепляется весь фундамент управления, уменьшается нагрузка на централизованные вычислительные системы и верхние ступени управления, что позволяет сосредоточить в них вопросы решения крупных долгосрочных стратегических задач. Естественно, что компьютерная технология СППР должна использовать не только персональные компьютеры, но и другие современные средства обработки информации.

Концепция СППР требует пересмотра существующих подходов к управлению трудовыми процессами в учреждении. По существу на базе СППР формируется новая человеко-машинная трудовая единица с квалификацией труда, его нормированием и оплатой. Она аккумулирует знания и умения конкретного человека (пользователя СППР) с интегрированными знаниями и умениями, заложенными в ПЭВМ [11].

1.2 Жизненный цикл по ИС

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).

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

Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [5]. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.

1.3 Модели жизненного цикла ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

каскадная модель (70-85 г.г.);

спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем [2]: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

Рис. 1.1. Каскадная схема разработки ПО 

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

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



Рис 1.3. Спиральная модель ЖЦ



Глава 2. Методологии и технологии проектирования ИС

2.1 Общие требования к методологии и технологии

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования определяется как совокупность трех составляющих: пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4); критериев и правил, используемых для оценки результатов выполнения технологических операций; нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

Рис. 1.4. Представление технологической операции проектирования

Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операции условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям: технология должна поддерживать полный ЖЦ ПО; технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций; технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам; технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования); технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие: стандарт проектирования; стандарт оформления проектной документации; стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать: набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации должен устанавливать: комплектность, состав и структуру документации на каждой стадии проектирования; требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать: правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; правила использования клавиатуры и мыши; правила оформления текстов помощи; перечень стандартных сообщений; правила обработки реакции пользователя.

2.2 Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения.

На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.

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

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

< 1000 функциональных элементов один человек1000-4000 функциональных элементов одна команда разработчиков> 4000 функциональных элементов 4000 функциональных элементов на одну команду разработчиков.

В качестве итога перечислим основные принципы методологии RAD: разработка приложений итерациями; необязательность полного завершения работ на каждом из этапов жизненного цикла; обязательное вовлечение пользователей в процесс разработки ИС; необходимое применение CASE-средств, обеспечивающих целостность проекта; применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; необходимое использование генераторов кода; использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; тестирование и развитие проекта, осуществляемые одновременно с разработкой; ведение разработки немногочисленной хорошо управляемой командой профессионалов; грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.



Глава 3. Структурный подход к проектированию ИС

3.1 Сущность структурного подхода

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов. Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие: принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных; принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы; принцип непротиворечивости - заключается в обоснованности и согласованности элементов; принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2); DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3); ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

3.2 Принципы, на которых базируется структурный подход. Метод SADT

Метод DFD

Проблема сложности является главной проблемой, которую приходится решать при создании больших систем любой природы, в том числе и ЭИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять все систему в целом. Единственно эффективный подход к решению этой проблемы заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и др. по отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем. Понятие «правильная» по отношению к декомпозиции означает следующее:Количество связей между отдельными подсистемами должно быть минимальным.

Связность отдельных частей внутри каждой подсистемы должна быть максимальной.

Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:

Каждая подсистема должна инкапсулировать свою содержимое (скрывать его от других подсистем).

Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие которых обусловлено разными способами декомпозиции систем. Первый подход называется функционально-модульным или структурным. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Итак, сущность структурного подхода к разработке ПО ЭИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:

Принцип «разделяй и властвуй»;

Принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, т.к. игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта»). Основными из этих принципов являются:

Принцип абстрагирования - выделение существенных аспектов системы и отвлечение от несущественных.

Принцип непротиворечивости обоснованность и согласованность элементов системы.

Принцип структурирования данных - данные должны быть структурированы и иерархически организованы.

В структурном подходе в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди них являются: DFD (Data Flow Diagrams) - диаграммы потоков данных; SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы;ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования: Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).Диаграммы, моделирующие данные и их отношения (ERD).Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT - модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес - процессов организации и взаимодействие между ними (использование SADT - моделей , как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

На стадии проектирования DFD используются для описания структуры проектируемой системы.

Перечисленные модели в совокупности дают полное описание ПО ЭИС независимо от того, является ли система существующей или вновь разрабатываемой.

3.3 Метод функционального моделирования SADT

Разработан Дугласом Россом в 1973г. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

Графическое представление блочного моделирования. Графика блоков и дуг SADT - диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются. Это:

Строгость и точность. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (3-6), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), разделение входов и управлений (правило определения роли данных).

Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель).

3.4 Состав функциональной модели

Результатом применения метода SADT является модель, состоящая из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Управляющая информация входит в блок сверху в то время, как входная информация, которая подвергается обработке, показаны с левой стороны блока, а результаты (выход) - справа. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей снизу.



Заключение

Проектирование информационной системы - это один из важнейших этапов ее существования то, с чего, собственно, должна начинаться её жизнь. Таким образом, прежде чем проектировать сеть, нужно понять, какие задачи будет решать сеть, какими будут основные потоки трафика, как физически будут расположены пользователи и ресурсы, нужно ли задание приоритетов видов трафика, как будут решаться вопросы защиты информации внутри сети, как сеть будет подключена к Интернет, как решить задачи управления правами доступа пользователей. Кроме того, в задачу предпроектного исследования входит изучение состояния зданий и сооружений в месте развертывания сети, анализ существующей инфраструктуры. Эта информация жизненно необходима как для постановки задачи проектирования, так и для самого проектирования.

Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.В работе рассмотрены цели создания ИС, задачи формирования требований к ИС, главная цель проектирования.



Список использованной литературы

Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-еизд.: Пер. с англ. - М.: Издательство Бином, СПб.: Невский диалект, 1999. - 332с.Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 1996. -202с.

Методология структурного анализа и проектирования. Марка Д.А., МакГоуэн К. М., "МетаТехнология", 1993. - 356с.

Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. М., 1996. - 245с.

Приемы объектно-ориентированного проектирования. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж.: Пер. с англ. - М.: ДМК, 2000. - 354с.

Трофимов С. А. CASE-технологии: практическая работа в Rational Rose - М.: БИНОМ, 2000. - 405с.

Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. - СПб: Питер, 2002. - 445с.

UML в кратком изложении. Применение стандартного языка объектного моделирования. Фаулер М., Скотт К.: Пер. с англ.- М.: Мир, 1999. - 273с.

UML и Rational Rose . Боггс У., БоггсМ.: Пер. с англ. - М.: Лори, 2000. - 266с.

Размещено на Allbest.ru