ГОСы / Milekhina_Otvety

28 Технология управления разработкой ИС

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

Назначение технологии управления разработкой ИС – поддержание объекта в требуемом состоянии. Управление – по времени, по отклонениям.

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

На выходе: корректирующие воздействия Основная часть

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

1.ТП съема фактических данных

2.ТП сравнения фактических данных с плановыми данными

3.ТП анализа расходования ресурсов (материальных и временных)

4.ТП анализа объемов выполненных работ

5.ТП подготовки отчетов о ходе разработки

6.ТП формирования нового плана с учетом использованных ресурсов, выполненных работ и оставшихся ресурсов

При формировании нового плана нужно обратить внимание на перечень оставшихся работ. В случае появление новых, ранее не запланированных работ, их следует внести в план.

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

Если нет ограничений в технологии выполнения, при большем количестве ресурсов работу можно выполнить за меньшее количество времени. Например, если в группе разработчиков 6 человек, они могут написать программу за 15 дней. А если их – 10, то они могут написать программу за 10 дней.

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

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

41

29 ТСП формирования раздела постановки задачи "Характеристика комплекса задач"

Предполагается, что к данному этапу написано техническое задание, разработаны все обеспечивающие подсистемы. Кроме того, проведён анализ бизнес-процессов (с помощью нотации IDEFO TO-BE – анализ функционального пространства задачи, IDEF3 – проверка синхронизации), спроектирована конструкция задачи и определены: 1) метод и дискретность управления; 2) набор параметров, характеризующих состояние процесса; 3) структура управляющих воздействий; 4) места реализации управляющих воздействий.

Раздел «Характеристике комплекса задач» содержит общие характеристики комплекса задач и связь комплекса задач с организационной структурой объекта автоматизации. Предполагается, что используется оригинальный метод проектирования.

Раздел «Характеристика комплекса задач» служит основой для формирования (проектирования) структур входных и выходных потоков данных, отражаемых в разделах «Входная информация» и «Выходная информация» постановки задачи. Постановка задачи является базой для разработки информационного, программного и технологического обеспечения по задачам.

43

30 ТСП формирования раздела постановки задачи "Выходная информация"

Раздел постановки задачи "Выходная информация" содержит описание структуры выходной информации. Предполагается, что разработано техническое задание, информационное обеспечение, содержащее описание условно-постоянной информации, сформирован раздел постановки задачи «Характеристика комплекса задач». Разработаны формы для внешних документов; формы для внутренних документов требуется разработать.

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

44

31 ТСП формирования раздела постановки задачи "Входная информация"

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

Назначение раздела: описание структуры входной информации Область применения: проектирование форм входной информации

Исходные данные: материалы ТЭО, положения о структурных подразделениях ОУ, требования ГОСТов по оформлению документов, описание машинных носителей информации, унифицированные формы документов.

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

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

46

32 Технология формирования информационной модели. Классы информационных потоков. Правила отображения информационной модели в Rational Rose и BPWin. Назначение нотаций.

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

Вкачестве объекта автоматизации может быть выделена любая система, например, в качестве экономической системы можно рассматривать организацию, отдельное подразделение предприятия, отдел, конкретное рабочее место, все определяется границами выбранной системы. Традиционно слева указываются входные информационные потоки xi(t), справа - выходные информационные потоки yj(t). Мощность множества входов X = {x} и множества выходов Y = {y} зависит от размеров рассматриваемой системы, и в общем случае количество входных информационных потоков не равно количеству выходных. Выходные информационные потоки являются результатом работы информационной системы, и их формирование возможно лишь при условии полноты входной информации, другими словами, каждый выходной поток должен быть обеспечен одним или несколькими входными.

Классы информационных потоков:

1)Оперативная информация, информация, которая меняется более чем на 30 % в течение короткого времени. (Погода, изменение курса валюты); 2)Условно-постоянная информация, информация, которая не меняется более чем на 30 % в течение короткого времени; 3)Нормативно-справочная информация;

4)Хранимая информация, информация, хранение которой регламентировано на хранимом уровне (Архив); 5)Накопленная информация; 6)Технологическая информация, информация, которая позволяет пользователю функционировать

информационную систему в бесперебойном состоянии.

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

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

Врезультате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

спецификации классов, объектов, атрибутов и операций

заготовки текстов программ;

модель разрабатываемой программной системы.

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

BPwin это программный продукт, разработанный компанией ltd. Logic Works. Он предназначен для поддержки процесса создания информационных систем.

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

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

47

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

Правила:

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

3.Правило семи. Число элементов на диаграмме декомпозиции не должно превышать семи, но и не должно быть слишком малым(более двух).

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

BPwin позволяет создавать следующие виды моделей:

Функциональные диаграммы, построенные на основе стандарта IDEF0. Эти диаграммы разделяются на четыре вида:

o Первый вид, это контекстная диаграмма. Она представляет описание процесса на самом верхнем уровне. На этой диаграмме дается общее представление процесса и его взаимосвязи с внешней средой или другими процессами;

o Второй вид – диаграмма декомпозиции. Она детализирует информацию контекстной диаграммы;

o Третий вид – диаграмма дерева узлов. Эта диаграмма в BPwin предназначена для отображения иерархии функций;

o Четвертый вид – диаграмма описаний. Применяется для представления отдельных частей процесса. С ее помощью можно дать различные описания, которые не поддерживаются стандартом IDEF0.

Диаграммы потока работ (FCD), построенные на основе стандарта IDEF3. Эти диаграммы дают возможность показать логику процесса, за счет представления задач в определенной последовательности. В дальнейшем, эти модели можно использовать в качестве основы для создания динамических моделей.

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

Модели стоимостного анализа. Эти модели строятся по правилам стоимостного анализа (Activity Base Costing - анализ). Модель может быть построена, только если уже существует полностью законченная и непротиворечивая функциональная модель. На каждую из задач функциональной модели назначаются метрики, представляющие затраты. Для модели определяются центры затрат. В результате получается модель стоимостного анализа.

Динамические модели. Эти модели могут быть построены на основе диаграмм потока работ. BPwin позволяет исследовать эффекты в ходе дискретного изменения состояния задач процесса. Для этого могут задаваться различные сценарии поведения процесса. Чтобы провести динамическое моделирование необходимо экспортировать диаграммы на основе IDEF3 в специальный программный продукт – business process simulator (для BPwin 4.0) или Arena (для BPwin 7).

48

33 Технология формирования структурной модели объекта автоматизации TO-BE

Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнеспроцессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Цель: разработка технологии формирования структурной модели ОА TO-BE.

Входы информационной модели: модель ОА AS-IS, недостатки модели ОА AS-IS, средства реализации для построения модели ОА AS-IS .

Выходы информационной модели: структурная модель ОА TO-BE.

1.ТП анализа выделенных недостатков

2.ТП структуризации недостатков по видам нотаций

3.ТП Формирования целей совершенствования системы и определения их значений

4.ТП выделения допустимых вариантов устранения недостатков

5.ТП анализа допустимых методов устранения недостатков

6.ТП определения критериев выбора метода

7.ТП выбора метода устранения недостатков

8.ТП устранения недостатков:

e.По механизмам

9.ТП построения модели To-Be

10.ТП проведения ABC анализа

11.ТП проверки на достижение поставленной цели

12.ТП формирования плана разработки/совершенствования ИС

Заключение: на основе построения модели ОА TO-BE устраняются недостатки модели ОА AS-IS, а так же строится модель данных, прототип и затем окончательный вариант ИС.

Из метод. материалов к 1 Лабе Жукова:

Для проведения качественного построения диаграмм TO-BE для нового процесса необходимо:

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

v построить граф синтеза выходных потоков, это позволит провести анализ применяемости элементов входных потоков при формировании выходных потоков и оценить объемы обрабатываемых данных;

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

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

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

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

v выбираются инструменты и приспособления для выполнения контрольных действий;

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

v выбираются способы передачи предметов труда между операциями;

v выбирается квалификация исполнителя, и формируются требования к его знаниям, умениям и навыкам;

49

34 Технология формирования структурной модели объекта автоматизации AS-IS.

Цель: разработка технологии формирования структурной модели объекта автоматизации AS-IS. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов Входы: Результаты анализа ОА, предметной области.

Выходы: структурная модель ОА AS-IS, количественные характеристики (время, затраты).

Перечень ТП:

1.ТП анализа ОА

2.ТП документирования цели, области и точки зрения

3.ТП определения количества уровней декомпозиции

4.ТП анализа и выбора средств реализации

5.ТП построение структурной модели AS-IS

5.1.Определение входных потоков модели

5.2.Определение выходных потоков модели

5.3.Определение управляющих воздействий

5.4.Определение механизмов

5.5.Разработка контекстной диаграммы

5.6.Экспертиза на соответствие реальных бизнес-процессов контекстной диаграмме

5.7.Определение количества фрагментов декомпозиции

5.8.Определение последовательности активностей

5.9.Определение взаимосвязей м/у фрагментами

5.10.Разработка первого уровня декомпозиции

5.11.Проверка на полноту, корректность и адекватность предметной области, если соответствует, то 5.14,

нет-5.13

5.12.Проверка на соответствие диаграммы цели и точки зрения, если соответствует, то 5.14, нет-5.13

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

5.14.Согласование построенной диаграммы с заказчиком, экспертом, специалистом в ПО

5.15.Доработка диаграмм в соответствии с рекомендациями

5.16.Разработка следующих уровней декомпозиции

5.17.Анализ полученной модели на соответствие реальным процессам работы ОА, если не соответствует,

то 5.18.

5.18.Корректировка декомпозиций модели

6.ТП получения количественных характеристик наблюдаемых процессов

50