- •Оглавление
- •Глава 1. Жизненный цикл программного обеспечения ……………………………………………43
- •Глава 2. Методические аспекты
- •Глава 3. Моделирование бизнес-процессов
- •Глава 4. Анализ и проектирование
- •Глава 5. Технологии создания программного
- •Глава 6. Оценка трудоемкости создания
- •Глава 7. Особенности современных проектов ........527
- •Предисловие
- •Введение
- •Глава 1 жизненный цикл программного обеспечения
- •Нормативно-методическое обеспечение создания по
- •Стандарт жизненного цикла по
- •Основные процессы жц по
- •Вспомогательные процессы жизненного цикла по
- •Организационные процессы жизненного цикла по
- •Взаимосвязь между процессами жц по
- •Модели жизненного цикла по
- •Каскадная модель жц
- •Итерационная модель жизненного цикла
- •Методика spmn
- •Пример процесса «управление требованиями»
- •Пример процесса «управление конфигурацией по»
- •Общие принципы проектирования систем
- •Визуальное моделирование
- •Структурные методы анализа и проектирования по
- •Метод функционального моделирования
- •Описание типов связей
- •Моделирования процессов idef3
- •Типы связей idef3
- •Типы соединений
- •Моделирование потоков данных
- •Количественный анализ диаграмм
- •Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •Моделирование данных
- •Объектно-ориентированные методы анализа и проектирования по
- •Основные принципы построения объектной модели
- •Основные элементы объектной модели
- •Значения мощности
- •Унифицированный язык моделирования uml
- •Диаграммы вариантов использования
- •Диаграммы взаимодействия
- •Диаграммы классов
- •Диаграммы состояний
- •Диаграммы деятельности
- •Диаграммы компонентов
- •Диаграммы размещения
- •Механизмы расширения uml
- •Количественный анализ диаграмм uml
- •Основные элементы языка uml
- •Основные типы связей языка uml
- •Диапазоны оценок для диаграмм uml
- •Образцы
- •Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
- •Структурный (процессный) подход к моделированию бизнес-процессов
- •Принципы процессного подхода
- •Применение диаграмм потоков данных
- •Система моделирования aris
- •Метод ericsson-penker21
- •Пример использвания процессного подхода
- •История болезни пациента
- •Спецификация структур данных
- •Построение диаграмм потоков данных нулевого и последующих уровней
- •Объектно-ориентированный подход к моделированию бизнес-процессов
- •Методика моделирования
- •Пример использования объектно-ориентированного подхода
- •Пример спецификации требований к программному обеспечению
- •Пример структурного проектирования по
- •Построение диаграмм системных процессов и диаграмм последовательностей экранных форм
- •Объектно-ориентированный анализ
- •Архитектурный анализ
- •Анализ вариантов использования
- •Объектно-ориентированное проектирование
- •Проектирование архитектуры системы
- •Проектирование элементов системы
- •Глава 5 технологии создания программного обеспечения
- •Определение технологии
- •Общие требования, предъявляемые
- •Внедрение тс по в организации
- •Общие сведения
- •Определение потребностей в тс по
- •Оценка и выбор тс по
- •Критерии оценки и выбора тс по
- •Выполнение пилотного проекта
- •Практическое внедрение тс по
- •Примеры тс по
- •Технология rup (rational unified process)
- •Технология oracle
- •Технология borland
- •Технология computer associates
- •Глава 6 оценка трудоемкости создания программного обеспечения
- •Методы оценки и их классификация
- •Методика оценки трудоемкости разработки по на основе функциональных точек
- •Определение функциональных типов
- •Определение количества и сложности функциональных типов по данным
- •Сложность ilf и eif
- •Определение количества и сложности транзакционных функциональных типов
- •Подсчет количества функциональных точек
- •Зависимость количества fp от сложности функционального типа
- •Коммуникации данных
- •Распределенная обработка данных
- •Сложность ei
- •Сложность ео
- •Производительность
- •Эксплуатационные ограничения
- •Частота транзакций
- •Ввод данных в режиме «онлайн»
- •Эффективность работы конечных пользователей1
- •Онлайновое обновление
- •Сложная обработка31
- •Повторное использование
- •Простота установки
- •Простота эксплуатации
- •Количество возможных установок на различных платформах
- •Гибкость32
- •Оценка трудоемкости разработки
- •Размер программного обеспечения в fp и loc
- •Распределение временных затрат по стадиям для маленьких и больших проектов
- •Статистические данные
- •Статистические (регрессионные) модели
- •Группа процессов
- •Определение весовых показателей вариантов использования
- •Определение технической сложности проекта
- •Определение уровня квалификации разработчиков
- •Оценка трудоемкости проекта
- •Методы, основанные на экспертных оценках
- •Метод дельфи
- •Метод декомпозиции работ
- •Средства оценки трудоемкости
- •Планирование итерационного процесса создания по
- •Глава 7 особенности современных проектов
- •Категории «безнадежных» проектов
- •Причины, порождающие «безнадежные» проекты
- •Причины разногласий между участниками проекта
- •Переговоры в «безнадежном» проекте
- •Человеческий фактор в «безнадежных» проектах
- •Процессы в «безнадежных» проектах
- •Динамика процессов
- •Контроль над продвижением проекта
- •Технология и инструментальные средства «безнадежных» проектов
- •Дополнительная литература
- •Краткий словарь терминов
- •Список основных сокращений
Количественный анализ диаграмм
IDEFO И DFD
Для проведения количественного анализа диаграмм IDEF0 и DFD используются следующие показатели:
количество блоков на диаграмме - N;
уровень декомпозиции диаграммы — L;
число стрелок, соединяющихся с i-м блоком диаграммы — Аi. Данный набор показателей относится к каждой диаграмме модели. Ниже перечислены рекомендации по их желательным значениям.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах,
т. е. с увеличением уровня декомпозиции убывал бы коэффициент N/L. По мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, например, что у любого блока количество входящих стрелок и стрелок управления не должно быть значительно больше, чем количество выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка — готовое изделие.
Количественная оценка сбалансированности диаграммы может быть выполнена с помощью коэффициента сбалансированности:
Kb=
|
|.
Необходимо стремиться к тому, чтобы значение Kb для диаграммы было минимальным.
2.3.5.
Сравнительный анализ sadt-моделей и диаграмм потоков данных
Сравнительный анализ данных методов структурного анализа проводится по следующим параметрам16:
адекватность средств решаемым задачам;
согласованность с другими средствами структурного анализа;
интеграция с другими процессами ЖЦ ПО (прежде всего с процессом проектирования).
Адекватность средств решаемым задачам. Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). С другой стороны, не существует никаких принципиальных ограничений на использовании DFD в качестве средства моделирования бизнес-процессов. Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Например, в Министерстве обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. Достоинствами применения моделей SADT для описания бизнес-процессов являются:
полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
комплексная декомпозиция; возможность агрегирования и детализации потоков данных и управления (разделение и слияние стрелок);
жесткие требования метода, обеспечивающие получение моделей стандартного вида;
соответствие подхода к описанию процессов стандартам ISO 9000.
В большинстве российских организаций бизнес-процессы начали формироваться и развиваться сравнительно недавно, они слабо типизированы, поэтому разумнее ориентироваться на модели, основанные на потоковых диаграммах. Кроме того, на практике у большинства моделей SADT отмечается ряд недостатков, в частности:
сложность восприятия (большое количество стрелок);
большое количество уровней декомпозиции;
трудность увязки нескольких процессов, представленных в различных моделях одной и той же организации.
Если же речь идет не о системах вообще, а о ПО ИС, то здесь DFD вне конкуренции. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. SADT-диаграммы оказываются значительно менее выразительными и удобными при моделировании ПО. Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к ПО стирается смысловое различие между входами и выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и правилами их преобразования. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
В SADT вообще отсутствуют выразительные средства для моделирования особенностей ИС. DFD же с самого начала создавались как средство проектирования ИС (тогда как SADT — как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
Наличие в DFD спецификаций процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT (a именно, обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.
Жесткие ограничения SADT, запрещающие использовать более 6-7 блоков на диаграмме, в ряде случаев вынуждают искусственно детализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реальной предметной области. В качестве примера достаточно рассмотреть модель операции по снятию денег с вклада физического лица в банке. В настоящий момент существуют более тридцати типов таких вкладов. Для моделирования соответствующих операций целесообразно использовать единственную DFD, поскольку все без исключения операции имеют одни и те же входы (сберегательная книжка и расходный ордер) и выходы (сберегательная книжка и наличные деньги) и различаются лишь механизмами начисления процентов. Если же попытаться структурировать эти операции путем группирования по какому-либо признаку (срочные, пенсионные, размеры процентов и т.п.) в соответствии с ограничениями SADT, то получится как минимум 6 диаграмм (верхний уровень и округленная в большую сторону дробь 30/7), сложность каждой из которых не меньше сложности единственной диаграммы, моделирующей все операции.
Согласованность с другими средствами структурного анализа. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами моделирования данных. Согласование SADT-модели с ERM практически невозможно или носит искусственный характер. В свою очередь, DFD и ERM взаимно дополняют друг друга и являются согласованными, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERM.
Интеграция с другими процессами ЖЦ ПО. Важная характеристика модели — ее совместимость с моделями, используемыми в последующих процессах (прежде всего в процессе проектирования).
DFD могут быть легко преобразованы в модели проектируемой системы. Известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логичный и безболезненный переход от формирования требований к проектированию системы. С другой стороны, формальные методы преобразования SADT-диаграмм в проектные решения отсутствуют.
Необходимо отметить, что рассмотренные разновидности средств структурного анализа примерно одинаковы с учетом возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
2.3.6.
