Методы проектирования снизу-вверх и сверху-вниз

Метод проектирования «снизу-вверх»

Информационная система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия.

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

Такой подход отчасти сохраняется и сегодня.

Проблема данного метода:

В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но:

· практически полностью отсутствует стратегия развития комплексной системы автоматизации,

· объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.

Метод проектирования «сверху-вниз»

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

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

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

Проблемы данного метода:

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

Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия

Материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.

 

Подходы к проектированию ИС

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

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

Структурный (функциональный) подход

Сущность подхода

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

 

Объектно-ориентированный подход

 

Сущность подхода

 

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

 

 

Ответ Милы

+ дополнительно см. вопрос 11.

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

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

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

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

К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ:

• Задачная модель;
• каскадная модель (или системная) (70-85 г.г.);
• спиральная модель (настоящее время).

Задачная модель

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

• Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);
• Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).

Общий вывод: достаточно большую эффективную ИС таким способом создать невозможно.

Каскадная модель

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

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

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

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

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

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

Спиральная модель

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

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

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

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

 

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

• небольшую команду программистов (от 2 до 10 человек);
• короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
• повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

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

• фаза определения требований и анализа;
• фаза проектирования;
• фаза реализации;
• фаза внедрения.

Основные принципы методологии RAD:

· разработка приложений итерациями;

· необязательность полного завершения работ на каждом из этапов жизненного цикла;

· обязательное вовлечение пользователей в процесс разработки ИС;

· необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

· необходимое использование генераторов кода;

· использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

· тестирование и развитие проекта, осуществляемые одновременно с разработкой;

· ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

Последовательность этапов создания ИС на фазе определения требований и анализа:

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

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

Результатами проектирования архитектуры являются:

• модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);
• модель данных (ERD и подсхемы ERD);

модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

Типовой процесс разработки и внедрения информационной системы включает следующие этапы: (ссылка на подробное описание процесса внедрения)

· заключение договора (предварительный контакт, экспресс обследование, определение границ проекта и согласование условий договора).

· обследование бизнеса предприятия заказчика.

· проектирование модели бизнеса.

· разработка специализированного ПО.

· технологическое внедрение (установка оборудования и программного обеспечения у заказчика).

· сопровождение и развитие.

Основные функции, выполняемые с помощью CASE-средств:

· формирование функциональной модели информационной системы. Наиболее распространенный метод реализации данной функции – метод SADT (технология IDEF0), позволяющий описать процесс в ИС в виде иерархии функций, связанных между собой входящими/исходящими потоками (материальными, финансовыми, информационными), управляющими воздействиями, исполнителями;

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

· формирование архитектуры информационной системы. Наиболее распространенный метод реализации данной функции - DFD (Data Flow Diagrams – диаграммы потоков данных) - методология структурно- функционального анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных;

· структурирование (моделирование) данных, в том числе создание концептуальной модели структуры базы данных, автоматическая генерация физической модели БД и др. Наибольшее распространение получили: метод построения ER (Entity-Relationship)-диаграмм Чена и методология Уорнера-Орра DSSD (Data Structured Systems Development);

· быстрая разработка приложений (визуальное программирование). Средства, обеспечивающие данную функцию, называются RAD-средствами (Rapid Application Development). Они представляют собой визуальные дизайнеры приложений с автоматической кодогенерацией и позволяют создавать приложения в интерактивном режиме с помощью набора визуальных средств.

Последовательность разработки информационных систем:

а) каскадная схема; б) спиральная схема; в) макетная схема

 

Ответ прошлых лет (Ден)

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

Технология проектирования определяется как совокупность трех составляющих:

· пошаговой процедуры, определяющей последовательность технологических операций проектирования;

· критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

· технология должна поддерживать полный ЖЦ ПО;

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

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

· технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

· технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

· технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.

Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.

1. Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

3. Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.

4. Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия.

5. Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

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

7. Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.

 

19. Проектирование ИС [J]

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
	11.2.	Проектирование информационных систем. Инфраструктура ИС. Платформы ИС.	Алексеев Пётр Сергеевич	Саша Хохрина	ОПЛ (Ден), готовый ответ Саши Хо

 

Готовый ответ Саши Хо

 

Инфраструктура ИС

 

Определения

 

Инфраструктура

Определение из Википедии:

Инфраструктура - комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы.

По ГОСТ Р 53114-2008 «Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения»:

Инфраструктура – совокупность зданий, оборудования и служб обеспечения, необходимых для функционирования организации