ГОСы / ФБИ ПРИС 2016
.pdf27 Структурные модели в бизнесе
Я оставляю эту теорию, но на самом деле здесь или какая-то модель из «Калашян, Калянов. Структурные модели бизнеса. DFD-технологии», или модель бизнеса из вашей ВКРБ. Показать входы-выходы, алгоритм процесса (образцы в книге).
В основе деятельности по бизнес-моделированию в бизнесе лежит реорганизация бизнес-процессов. В основе структурных моделей лежит структурный анализ – метод исследования системы, который начинается с общего обзора системы, а затем детализируется, приобретая иерархическую структуру в все большим количеством уровней. Для таких моделей характерно разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней, ограниченный контекст, включающий лишь существенные на каждом уровне детали; строгие формальные правила записи; последовательное приближение к конечному результату. Все модели структурного анализа базируются на ряде базовых принципов, регламентирующий процесс анализа бизнес-систем:
Принцип абстрагирования — выделение существенных с некоторых позиций аспектов системы и отвлечения от несущественных ее аспектов с целью представления системы в простом общем виде.
Принцип формализации — необходимость строгого методологического подхода к решению проблемы
Принцип доступности — ограничение доступа к несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию
Принцип полноты — контроль на присутствие лишних элементов
Принцип непротиворечивости — обоснованность и согласованность элементов
Принцип независимости данных — модели данных должны быть проанализированы и спроектированы независимо от процессов их обработки
Все существующие методологии либо применяют технологии диаграмм потоков данных DFD, либо IDEF0.
В основе классической DFD-технологии лежат три группы средств моделирования:
диаграммы, иллюстрирующие функции, которые система должна выполнять,
исвязи между этими функциями — диаграммы потоков данных DFD + словари данных + спецификации процессов нижнего уровня;
диаграммы, моделирующие данные и их взаимосвязи — диаграммы «сущность-связь» ERD
диаграммы, моделирующие поведение системы — диаграммы переходов состояний STD.
Диаграммы потоков данных DFD являются основным средством функционального моделирования бизнес-системы. С их помощью система разбивается на процессы и представляется в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, также выявить отношения между этими процессами. Чаще всего данная методология используется для проектирования программного обеспечения. Базовая нотация включает 4 рассматриваемых объекта:
Поток данных является для моделирования передачи информации (или даже физ. Компонентов) из одной части системы в другую. Потоки на данной диаграмме изображаются с помощью именованных стрелок.
Назначение процесса состоит в преобразовании входных потоков в выходные в соответствии с действом, задаваемым именем процесса. Символ процесса включает
три разделѐнных горизонтальными чертами поля: верхнее поле содержит номер процесса и аббревиатуру детализирующего объекта (КД – контекстная диаграмма, ДПД – диаграмма потоков данных, МС – мини-спецификация), среднее поле содержит имя процесса, нижнее поле содержит имя исполнителя процесса.
Накопитель данных позволяет определять данные, которые будут сохраняться вне процессов. Когда процесс сохраняет данные, то стрелка потока данных направлена
внакопитель данных, и, наоборот, когда доступ в накопитель данных осуществляется для чтения, стрелка потока данных направлена в процесс.
Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Такие объекты находятся за пределами системы и не должны участвовать в обработке.
Диаграмма IDEF0 может применяться для проектирования как программного обеспечения, так и вообще любых бизнес объектов. IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями. Методология IDEF0 незначительно отличается от классической схемы описания бизнес-процессов DFD. Основным отличием является классификация входов работы. Стандарт предлагает следующую типизацию входов работ:
Вход. Входит в работу слева и показывает информационные и материальные потоки, которые преобразуются в бизнес процессе.
Управление. Входит в работу сверху и показывает материальные и информационные потоки, которые не преобразуются в процессе, но нужны для его выполнения.
Механизм. Входит в работу снизу и показывает людей, технические средства, информационные системы и т.п., при помощи которых бизнес процесс реализуется.
Результаты выходят из блока справа.
28 Модель (точнее, методология) быстрой разработки приложений
От Андрея:
RAD (от англ. rapid application development — быстрая разработка приложений) —
концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.
Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.
1.Необходимо выполнение проекта в сжатые сроки. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет ещѐ до завершения еѐ проектирования.
2.Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.
3.Проект выполняется в условиях ограниченности бюджета. Разработка ведѐтся небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения.
4.Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причѐм достаточно скоро после начала проекта.
5.Возможно разбиение проекта на функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы еѐ можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD-групп).
6.Низкая вычислительная сложность ПО.
RAD-технология не является универсальной, то есть еѐ применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объѐм пользовательского интерфейса невелик.
Модель быстрой разработки приложений включает следующие фазы:
Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
Тестирование: тестируются новые компоненты и интерфейсы.
Другими словами, методология быстрой разработки – это разработка с использованием средств генерации кода по UML схемам или с помощью визуального программирования (как в Delphi, например).
Из презентации Кравченко:
Этапы:
Преимущества методологии RAD:
применение мощных инструментальных средств позволя-ет сократить время цикла разработки всего проекта;
создание системы выполняется коллективом, знающим процессы предметной области;
уменьшаются затраты благодаря сокращенному времени цикла, а также меньшему количеству задействованных разра-ботчиков;
уменьшается риск, связанный с соблюдением графика ра-бот, за счет сокращенного времени цикла;
сведение к минимуму риска того, что система не будет удовлетворять требованиям предметной области;
основное внимание уделяется не документации, а кодированию (программированию), при этом поддерживается прин-цип «получаете то, что видите» (What you see is what you get, WYSIWYG);
использование различных стандартных методологий моделирования
Недостатки:
низкое качество программного продукта, если заказчики не могут принимать активное участие в процессе создания системы на протяжении всего ЖЦ;
необходимость достаточного количества высококвалифицированных разработчиков, умеющих пользоваться выбранными инструментальными средствами разработки;
необходимость наличия готовых компонентов проектируемой системы до начала проекта
Области применения методологии RAD:
для систем, которые поддаются моделированию и основаны на использовании компонентных объектов;
для систем, требования к которым хорошо известны;
для систем, если заказчик может принимать активное участие в процессе создания системы на протяжении всего ЖЦ и имеет навыки по использованию автоматизированных инстру-ментальных средств разработки и организации коллективной работы;
проект имеет сокращенные сроки выполнения (не более 60 дней);
для систем, в которых функционал реализуется в виде последовательных действий;
для систем, предназначенных для концептуальной проверки возможностей и эффективности автоматизации;
для систем, которые имеют небольшое количество автоматизируемых бизнеспроцессов предметной области;
когда затраты и соблюдение графика не являются самыми важными критериями процесса создания системы (например, при разработке внутренних инструментальных средств);
при невысокой степени технических рисков;
когда команде, работающей над проектом, знакома предметная область и она обладает навыками в использовании средств разработки.
29 Модель по методу "хирургическая бригада"
Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых при равной подготовке и двухлетнем стаже.
Лучше всего иметь маленькую активную команду — как можно меньше мыслителей. Часто лучше всего, если команда состоит из двух человек, один из которых является лидером.
Для создания действительно крупных систем маленькая активная команда работает слишком медленно.
Харлан Миллз предложил организацию команды разработчиков в виде бригады хирургов. При этом лишь несколько человек занято проектированием, а остальные работники находятся на подхвате.
Опыт разработки большинства действительно больших систем показывает, что подход к ускорению с позиций грубой силы оказывается дорогостоящим, медленным, неэффективным и приводит к появлению систем, не являющихся концептуально целостными.
Хирург: главный программист. Определяет технические условия на функциональность и эксплуатационные характеристики программы. Назначается из числа наиболее опытных и талантливых специалистов. Он сам разрабатывает, пишет и отлаживает программу, полностью и единолично несет ответственность за конечный результат. В совершенстве владеет языком программирования и имеет неограниченный доступ к ЭВМ.
Второй пилот: второе «я» хирурга, может выполнять любую работу хирурга, но менее опытен.
Ведет параллельную разработку той же программы, знает ее до тонкостей. Принимает участие в дискуссиях, может давать советы, однако "хирург" решает, следует ли их принимать. В случае несчастья с "хирургом" второй пилот способен повести дальнейшее дело сам, дополнительной подготовки ему для этого не потребуется.
Администратор: обеспечивает связь менеджмента с хирургом. Занимается административными и коммерческими вопросами проекта. Но
ключевые решения из этой сферы принимает сам "хирург", он же несет за них ответственность.
Редактор: правка записей хирурга.
осуществляет техническую помощь в издании документов, которые готовит "хирург". Читает, корректирует, делает верстку, снабжает иллюстрациями, ссылками, библиографией, следит за размножением, корректировкой, распространением.
Секретари: помогают администратору и редактору.
Делопроизводитель: отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта.
Инструментальщик: разрабатывает вспомогательное ПО.
сопровождает инструментальное программное обеспечение (редакторы, трансляторы, компоновщики, системы программирования) и при необходимости создает новые.
Отладчик: разрабатывает тесты и тестирует ПО.
Языковед: специалист по языку, на котором ведѐтся разработка.
знаток языков и систем программирования. Кроме консультаций "хирурга" по его заданию ищет эффективные способы реализации заданных функций.
Организация по типу хирургических бригад с главным программистом предлагает способ достижения целостности продукта благодаря его проектированию в нескольких головах и общей продуктивности благодаря наличию многочисленных помощников при радикально сокращенном обмене информацией.
30 Спиральная модель ЖЦ
Спиральная модель – классический пример применения эволюционной стратегии конструирования. Модель (автор Б. Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах. Модель определяет четыре действия, представляемые четырьмя квадрантами спирали.
1.Планирование – определение целей, вариантов и ограничений.
2.Анализ риска – анализ вариантов и распознавание/выбор риска.
3.Конструирование – разработка продукта следующего уровня.
4.Оценивание – оценка заказчиком текущих результатов конструирования.
Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали строятся все более полные версии ПС. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используемое в квадранте конструирования.
Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде "продолжать, не продолжать". Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Эти действия на рисунке пронумерованы и имеют следующее содержание:
1.– начальный сбор требований и планирование проекта;
2.– та же работа, но на основе рекомендаций заказчика;
3.– анализ риска на основе начальных требований;
4.– анализ риска на основе реакции заказчика;
5.– переход к комплексной системе;
6.– начальный макет системы;
7.– следующий уровень макета;
8.– сконструированная система;
9.– оценивание заказчиком.
Достоинства спиральной модели:
1.наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
2.позволяет явно учитывать риск на каждом витке эволюции разработки;
3.включает шаг системного подхода в итерационную структуру разработки;
4.использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
1.сравнительная новизна (отсутствует достаточная статистика эффективности модели);
2.повышенные требования к заказчику;
3.трудности контроля и управления временем разработки.
Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework). В качестве языка моделирования используется язык UML (Unified Modeling Language). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточнять характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируется только то, что можно предвидеть, разрабатывается то, что запланировано, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы.
Однако для этого нужны очень большие средства. Действительно, если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участвовать в проекте: архитекторы, программисты, тестировщики, инструкторы и т. д. Более того, усилия различных групп должны быть синхронизированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения.