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

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

План

автоматизация управленческий декомпозиция информационный

1. Наименование организации и основные показатели ее деятельности. Средства автоматизации управленческого труда, используемые в организации

2. Функциональные компоненты информационной системы. Функциональная декомпозиция информационной системы промышленного предприятия

3. Основные процессы жизненного цикла ИС. Вспомогательные процессы. Проектирование ИС. Спиральная модель проектирования и ее преимущества

Литература

1. Информационные системы на предприятии

В 1997 году образованное открытое акционерное общество "ХАРС", основное направление деятельности которого является предоставление аудиторских услуг.

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

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

Общая численность работников данной организации составляет 21 чел. (рис. 1), в том числе: работников бухгалтерии - 2 чел., возглавляемые главным бухгалтером (рис. 2); работников, связанных непосредственно с аудиторской деятельностью, - 13 чел.. Руководство текущей деятельностью ООО "ХАРС" осуществляется директором, который является аттестованным аудитором.



Рис. 1. Структура ООО «ХАРС»

В дополнение рис. 1 следует отметить, что:

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

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

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

В процессе своей деятельности ООО "ХАРС" подписывает договоры о предоставлении аудиторских услуг, в которых одним из важных пунктов является стоимость и порядок оплаты услуг. Следовательно, возникает необходимость бухгалтерского учета по расчетам с покупателями и заказчиками (где предметом продажи стоит считать предоставление услуг), а также бухгалтерский учет финансово расчетных операций. ООО "ХАРС", как и много других организаций и предприятия, пользуется газом, канализацией и тому подобное, арендует помещение, в котором располагается офис, а значит, возникает бухгалтерский учет по расчетам с поставщиками и заказчиками.

Поэтому структура бухгалтерии и основных направлений бухгалтерского учета выглядят таким способом (рис. 2):

Рис. 2. Структура бухгалтерии ООО «ХАРС»

На предприятии используются 15 компьютеров и 2 сервера, а также 4 принтера и 2 сканера:

1 компьютер и 1 принтер находятся у секретаря - кадровика;

- 11 компьютеров и 1 сервер, а также 2 принтера и 1 сканер - для работников, которые занимаются непосредственно аудитом; у каждого из аудиторов и специалистов есть свое автоматизированное рабочее место, а сервер находится у директора ООО "ХАРС";

- 3 компьютера и 1 сервер, а также 1 принтер и 1 сканер - для работников бухгалтерии;

Все компьютеры организации оснащены процессором Intel Реntium IV, оперативной памятью 256 МБ.

Сервером для бухгалтерии руководит SСО Ореп Sегvег 5.0.5.

Защита от внешних атак осуществляется соответствующей настройкой предельного маршрутизатора под управлением FгееВSD (настройке подлежит служба IPWF2), который препятствует проникновению ошибочного пакета данных в сеть.

Для доступа к ресурсам Unix-машин на предприятии используется стандартная система защиты этой операционной системы. Защита от доступа, которая не санкционируется, осуществляется с помощью процедуры введения логин-пароля.

Доступ к конкретному ресурсу осуществляется с помощью разных серверов.

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

Физический доступ к серверам ограничен только работниками технического персонала.

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

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

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

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

Основные задания, выполняемые системой АРМ (реализуются в виде независимых модулей единственной системы):

1) автоматизация всех ежедневных операций, ведения бухгалтерии и составления сводных отчетов;

2) коммуникация с филиалами и иногородними отделениями;

3) автоматизировано взаимодействие с клиентами;

4) анализ всей деятельности и системы выбора оптимальных в данной ситуации решений;

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

Поскольку численность сотрудников не высокая и объем бухгалтерского учета не настолько велик , поэтому бухгалтерия состоит из 3 чел.(2 бухгалтера и 1 главного бухгалтера), а рабочее место каждого бухгалтера соединяет в себе несколько АРМов, то есть 1 бухгалтер охватывает несколько участков бухгалтерского учета. Структура локальной вычислительной сети представлена на рис. 3.

Рис. 3. Структура локальной вычислительной сети ООО "ХАРС"

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

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

Применение бухгалтерской программы в ООО "ХАРС" позволило осуществить переход к безбумажной технологии, на больше высоком уровне и более оперативно обеспечивает решение традиционных учетных заданий. Кроме того, появились возможности для организации более глубокой аналитической работы.

Все это требует от работников бухгалтерии ООО "ХАРС" и других организаций знания ПК, умение пользоваться функциональными пакетами прикладных бухгалтерских программ.

Минимальная конфигурация АРМ бухгалтера включает ПК на базе процессора с тактовой частотой больше 700 Мhz, оперативной памятью 256 МБ, жесткий диск не менее 20 Гб. Для хранения информации на внешних носителях, необходимы устройства записи на внешние носители.

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

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

2. Функциональные компоненты информационной системы. Функциональная декомпозиция информационной системы промышленного предприятия

САSЕ - технологии - инструментальная база проектирования

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

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

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

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

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

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

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

3) Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований.

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

5) Доступность для разных категорий пользователей.

6) Рентабельность.

7) Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

Интегрированный CASE-пакет содержит четыре основные компоненты:

1) Средства централизованного хранения всей информации о проектируемом ПО в течении всего ЖЦ (репозитарии) являются основой CASE-пакета. Соответствующая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

· инкрементный режим при вводе описаний объектов;

· распространение действия нового или скорректированного описания на информационное пространство всего проекта;

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

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

· сборку любой запрошенной версии;

· контроль информации на корректность, полноту и состоятельность.

2) Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия & CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т. д.

3) Средства анализа, проектирования и разработки предназначены для того, чтобы обеспечить планирование и анализ различных описаний, а также их преобразования в процессе разработки.

4) Средства вывода служат для документирования, управления проектом и кодовой генерации.

· Все перечисленные компоненты в совокупности должны:

· поддерживать графические модели;

· контролировать ошибки;

· организовывать и поддерживать репозитарий;

· поддерживать процесс проектирования и разработки.

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

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

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

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

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

· улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта);

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

· ускоряют процесс проектирования и разработки;

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

· поддерживают развитие и сопровождение разработки;

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

CASE - средство AllFusion Process Modeler (BPwin)

Компания CA предоставляет решение AllFusion Process Modeler. Эта мощная система предоставляет базовый фундамент для понимания, оптимизации и автоматизации бизнес-процессов.

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

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

· С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

· С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

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

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

Методология IDEF0

Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

· Стрелки входа (входят в левую грань работы) -- изображают данные или объекты, изменяемые в ходе выполнения работы.

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

· Стрелки выхода (выходят из правой грани работы) -- изображают данные или объекты, появляющиеся в результате выполнения работы.

· Стрелки механизма (входят в нижнюю грань работы) -- изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…)

· Стрелки вызова (выходят из нижней грани работы) -- изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.

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



Рисунок .1. Функциональный блок и интерфейсные дуги

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

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

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис..2 и Рис..4. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).

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

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

Рисунок 2 - Пример контекстной диаграммы

Как видно на Рис.2, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.

Рисунок .3 - Пример диаграммы декомпозиции

Рисунок .4 - Пример контекстной диаграммы



Рисунок .5 - Пример диаграммы декомпозиции

Иерархия диаграмм

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

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

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

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

Рисунок .6 - Структура SADT-модели. Декомпозиция диаграмм



Рисунок .7 - Соответствие должно быть полным и непротиворечивым

Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.

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



Рис. .8. Пример механизма

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. На рисунке 7.9 показано типичное дерево диаграмм.

Рисунок .9 - Иерархия диаграмм

Диаграммы дерева узлов (Node Tree Diagram)

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

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

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

Рисунок 10 - Пример диаграммы дерева узлов



Рисунок 11- Диаграмма дерева узлов

3. Основные процессы жизненного цикла ИС. Вспомогательные процессы. Проектирование ИС. Спиральная модель проектирования и ее преимущества

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

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

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 6.1 - Каскадная схема разработки ПО

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

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

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

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

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

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

1. начальный сбор требований и планирование проекта;

2. та же работа, но на основе рекомендаций заказчика;

3. анализ риска на основе начальных требований;

4. анализ риска на основе реакции заказчика;

5. переход к комплексной системе;

6. начальный макет системы;

7. следующий уровень макета;

8. сконструированная система;

9. оценивание заказчиком.

Как показано на рис. 6.3, спиральная модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

· планирование -- определение целей, вариантов и ограничений;

· анализ риска -- анализ вариантов и распознавание (выбор) риска;

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

· оценивание -- оценка заказчиком текущих результатов конструирования.

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

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

Недостатками спиральной модели являются:

· новизна (отсутствует достаточная статистика эффективности модели);

· повышенные требования к заказчику;

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

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

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

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

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

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

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

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

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

К таким стандартам относятся следующие:

стандарт проектирования;

стандарт оформления проектной документации;

стандарт пользовательского интерфейса.



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

Стандарт проектирования должен устанавливать:

набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

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

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

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

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

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

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

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

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных.

Литература

1. Курицкий Б.Я., Организация делопроизводства и управления в офисе. Спб.: ВНУ, 1997.

2. Матвієнко О.В. Основи менеджменту інформаційних систем. -Київ:2005.

3. Международньїе банковские стандартьі. Под. ред. С. И. Кумок. -М..-1995.

4. С.В.Глушаков. Персональний компьютер для секретарей и менеджерові - Харьков: ФОЛИО, 2005.

5. Модульная программа для менеджеров. Т. 17. Годин В.В., Корнеев И.К. - Управление информационными ресурсами. М.: Финансы и статистика, 1999.

6. Ситнік В.Ф. та ін. Основи інформаційних систем: Навч. Посібник. - Вид. 2-ге, перероб.і доп. / В.Ф.Ситнік, Т.А. Писаревська, Н.В. Єрьоміна, О.С. Краєва. За ред. В.Ф. Ситника. - К.:КНЕУ, 2001. - 420с.

7.Бутинець Ф.Ф. та ін. Інформаційні системи бухгалтерського обліку: Підручник для студентів вищих навчальних закладів. / Ф.Ф.Бутинець, С.В. Івахненков, Т.В. Давидюк, Т.В. Шахрайчук. За ред. проф. Ф.Ф.Бутинця. 2-е вид., перероб. і доп. - Житомир: ПП “Рута”, 2002 - 544с.

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