Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
151
Таблица 4.1
Требования к проекту
Требования
Каскад-
ная
Эволю-
ционная
Спи-
ральная
RAD
Являются ли требования легко
определимыми и / или хорошо
известными
Да Нет Нет Да
Могут ли требования быть
определены заранее
Да Нет Нет Да
Часто ли будут изменяться
требования
Нет Да Да Нет
Нужно ли демонстрировать
требования с целью их
конкретизации
Нет Да Да Да
Требуется ли для демонстрации возможностей и проверка
концепции
Нет Да Да Да
Будут ли требования отражать
сложность системы
Нет Да Да Нет
Обладает ли требование функциональными свойствами на
раннем этапе
Нет Да Да Да
Модель жизненного цикла требуется аккуратно выбрать и
настроить (подогнать и разработать) под задачи и цели проекта.
Модель, выбранная для проекта, должна обеспечивать потребности организации, соответствовать типу выполняемых работ, а также навыкам и инструментальным средствам, которые
имеются у разработчиков. Она может быть комбинацией нескольких моделей или их модификаций.
Выбор подходящей модели — это только начало. Следующая стадия заключается в ее подгонке в соответствии с потребностями этого проекта. Это означает, что выбранные реальные фазы и действия должны помочь руководителю проекта соотнести проект с выбранной моделью.
Если при выполнении проекта происходят какие-либо изменения, которые заставляют команду прийти к мысли, что другая модель была бы более действенной? В этом случае лучше
изменить модель, чем пытаться использовать ту, которая не под-
152
ходит в достаточной степени для соответствия потребностям
проекта.
4.9. Типовое проектирование ИС
Разработка оригинальной ИС длительна и затратна. Зачастую в этом нет необходимости. В самом деле, большинство
разрабатываемых ИС по обслуживанию деятельности предприятий имеют однотипные задачи, многократно решенные для аналогичных предприятий. Например, «торговля и склад», «бухгалтерия», «зарплата и кадры». Совершенно не обязательно всякий
раз «изобретать велосипед» и проектировать ИС с нуля. Куда
предпочтительнее иметь некую усредненную (типовую) систему, поддающуюся настройке в соответствии с конкретными потребностями предприятия. Либо иметь готовые компоненты
(типовые проектные решения), из которых, как из кубиков,
можно строить новую ИС.
Типовое проектное решение (ТПР) — это тиражируемое
(пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР отражает уровень декомпозиции системы. Выделяют следующие классы ТПР:
1) элементные ТПР типовые решения по задаче или по
отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
2) подсистемные ТПР в качестве элементов типизации
выступают отдельные подсистемы, разработанные с учетом
функциональной полноты и минимизации внешних информационных связей;
3) объектные ТПР типовые отраслевые проекты, включа-
ющие полный набор функциональных и обеспечивающих подсистем ИС.
Особенности различных классов ТПР приведены в
табл. 4.2.
153
Таблица 4.2
Основные характеристики ТПР
Класс и
реализация ТПР
Достоинства
Недостатки
1
2
3
Элементные ТПР
Библиотеки методоориентированных
программ
Обеспечивается применение модульного подхода к
проектированию и
документированию ИС
Большие затраты
времени на сопряжение разнородных элементов вследствие
информационной,
программной и
технической
несовместимости
Большие затраты
времени на доработку ТПР отдельных элементов
Подсистемные ТПР
Пакеты прикладных
программ
Достигается высокая степень интеграции элементов ИС
Позволяют осуществлять:
модульное проектирование; параметрическую
настройку программных
компонентов на различные объекты управления
Обеспечивают: сокращение затрат на проектирование и программирование взаимосвязанных
компонентов
Хорошее документирование отображаемых процессов обработки информации
Большие затраты
времени на сопряжение разнородных элементов вследствие
информационной,
программной и
технической
несовместимости
Большие затраты
времени на доработку ТПР отдельных элементов
154
Класс и
реализация ТПР
Достоинства
Недостатки
1
2
3
Объектные ТПР
Отраслевые проекты
ИС
Комплексирование всех
компонентов ИС за счет
методологического единства и информационной,
программной и технической совместимости
Открытость архитектуры
позволяет устанавливать
ТПР на разных программно-технических платформах
Масштабируемость допускает конфигурацию
ИС для переменного числа
рабочих мест
Конфигурируемость позволяет выбирать необходимое подмножество компонентов
Проблемы привязки типового
проекта к конкретному объекту
управления, что
вызывает в некоторых случаях
даже необходимость изменения
организационноэкономической
структуры объекта автоматизации
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов, поэтому для его применения принципиально важна возможность декомпозиции проектируемой ИС на компоненты, для которых на рынке есть подходящие готовые типовые проектные решения.
Каждое типовое решение — это собственно функциональные элементы (программные или аппаратные) плюс документация с детальным описанием ТПР и процедур настройки. Процедуры настройки необходимы для подгонки выбранного функционального элемента под разрабатываемую ИС.
Для реализации типового проектирования используются
два подхода: параметрически-ориентированное и модельно-
ориентированное проектирование.
155
4.9.1. Параметрически ориентированное проектирование
Оно включает следующие этапы:
1) определение критериев оценки пригодности пакетов
прикладных программ (ППП) для решения поставленных задач;
2) анализ и оценка доступных ППП по сформулированным
критериям;
3) выбор и закупка наиболее подходящего пакета,
настройка параметров (доработка) закупленного ППП.
Критерии оценки ППП делятся на следующие группы:
– назначение и возможности пакета;
– отличительные признаки и свойства пакета;
– требования к техническим и программным средствам;
– документация пакета;
– факторы финансового порядка;
– особенности установки пакета;
– особенности эксплуатации пакета;
– помощь поставщика по внедрению и поддержанию пакета;
– оценка качества пакета и опыт его использования;
– перспективы развития пакета.
Внутри каждой группы критериев выделяется некоторое
подмножество частных показателей, детализирующих каждый
из десяти выделенных аспектов анализа выбираемых ППП. Достаточно полный перечень показателей можно найти в литературе.
Числовые значения показателей для конкретных ППП
устанавливаются экспертами по выбранной шкале оценок
(например, 10-балльной). На их основе формируются групповые
оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений).
Нормированные взвешивающие коэффициенты также получаются экспертным путем.
4.9.2. Модельно-ориентированное проектирование
Заключается в адаптации состава и характеристик типовой
ИС в соответствии с моделью объекта автоматизации.
156
Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС,
так и с моделью конкретного предприятия.
Типовая ИС в специальной базе метаинформации репозитории содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование
ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench
(BEW), BAAN Enterprise Modeler). Возможно также создание
системы на базе типовой модели ИС из репозитория, который
поставляется вместе с программным продуктом и расширяется
по мере накопления опыта проектирования информационных
систем для различных отраслей и типов производства.
Репозиторий содержит базовую (ссылочную) модель ИС,
типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.
Базовая модель ИС в репозитории содержит описание
бизнес-функций, бизнес-процессов, бизнес объектов, бизнесправил, организационной структуры, которые поддерживаются программными модулями типовой ИС.
Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.
Модель конкретного предприятия строится либо путем
выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, либо
путем автоматизированной адаптации этих моделей в результате
экспертного опроса.
Построенная модель предприятия в виде метаописания
хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка ИС.
Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.
157
Модель бизнес функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия.
Модель бизнес-процессов отражает выполнение работ по
спецификации для функций самого нижнего уровня модели бизнес-функций. Для отображения процессов используется модель
управления событиями (ЕРС Event-driven Process Chain). Именно
модель бизнес-процессов позволяет выполнить настройку программных модулей приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.
Модели бизнес объектов используются для интеграции
приложений, поддерживающих исполнение различных бизнеспроцессов (см. описание языка UML).
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.
4.9.3. Порядок создания типовой ИС
Последовательность работ по созданию типовой ИС.
1. Выявляются и анализируются требования к конкретной
ИС, (см. в гл. 1 раздел «Сбор и классификация требований»).
2. Оцениваются на соответствие этим требованиям типо-
вых ИС, для оценки может использоваться могут использоваться
описанные выше (п. 4.9.1) критерии оценки ППП.
3. После выбора типовой ИС на базе имеющихся в ней
типовых моделей классов строится предварительная модель ИС,
в которой отражаются все особенности реализации ИС для конкретного предприятия.
4. Предварительная модель является основой для выбора
типовой модели системы и определения перечня компонентов,
которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся
в составе типовой ИС инструментальных средств.
Реализация типового проекта предусматривает выполнение следующих операций:
– установку глобальных параметров системы;
– задание структуры объекта автоматизации;
158
– определение структуры основных данных;
– задание перечня реализуемых функций и процессов;
– описание интерфейсов;
– описание отчетов;
– настройку авторизации доступа;
– настройку системы архивирования.
Вопросы и задания для самопроверки
1. В каких случаях оправдано применение:
– каскадной модели;
– модели эволюционного прототипирования;
– модели RAD;
– типового проектирования?
2. Сформулируйте наиболее существенные отличия меж-
ду моделями RAD и эволюционного прототипирования.
3. В чем вы видите перспективность ХР-
программирования?
4. Каковы основные категории оценки проекта при выбо-
ре модели жизненного цикла?
5. Какие варианты типового проектирования вы знаете?
6. Каковы критерии оценки ППП?
7. Руководствуясь советами раздела «Выбор модели жиз-
ненного цикла» для каждой из перечисленных четырех групп
проблем выберите подходящую модель жизненного цикла разработки ПО, аргументируйте свой выбор и опишите преимущества выбранной модели.
а) Организация переписывает код программы ХХ для того,
чтобы перенести ее со старой локальной сети в систему, подключенную к Internet. Функциональные возможности остаются
прежними. Рабочее задание требует изменения исходных качеств системы. Для новой среды будут изменены только входные и выходные подсистемы. Поскольку данная система относится к области финансов, в рамках действий по разработке особое внимание будет уделено ее тестированию и верификации. В
графике предусмотрено, что на выполнение проекта уйдет пять
месяцев, и над ним будут работать два человека. Какова самая
159
приемлемая модель жизненного цикла? В чем заключаются ее
преимущества для данного проекта?
б) Организация по разработке электронных компонентов
недавно приняла решение вложить средства в проектирование
«карманных» компьютеров, по образу и подобию карманных
компьютеров Ра1m Рilot. В этом случае предполагается применение сотовых модемов. Компания имеет значительный опыт в
выпуске серий продуктов, аналогичных этому, и считает, чир,
продавая его по более низкой цене, достигнет успеха на рынке.
Таким образом, организация хотела разработать рабочую модель, которая будет представлена на международной специализированной выставке по прошествии трех месяцев. Каков наиболее
подходящий принцип построения жизненного цикла? В чем заключается преимущества такого принципа для данного проекта?
в) Организация недавно завершила трехлетний процесс
разработки глобальной системы менеджмента конфигурации.
Теперь она готова перейти на следующую фазу, на которой приблизительно каждые три месяца будет выпускаться новый вариант программного продукта. В каждый выпуск будет включено в
среднем 12 новых свойств и соответствующее количество безошибочных вариантов. Над каждым выпуском будут совместно
работать команды, состоящие из одног — трехинженеров и
находящиеся в Индии, России и США. Время, отведенное на
разработку новых свойств, — от 1 до 5 месяцев. Для некоторых
свойств может возникнуть необходимость в выпуске нескольких
вариантов вплоть до их полной реализации. Что представляет
собой, на ваш взгляд, самый подходящий принцип построения
жизненного цикла? В чем заключается преимущества такого
принципа для данного проекта?
160
ПРИЛОЖЕНИЕ
САSЕ-средства
При проектировании ПО широко применяются так называемые САSЕ-средства.
Аббревиатура САSЕ (Соmputеr-аidеd Software Епgineering —
автоматизированная разработка ПО) обозначает специальный
тип программного обеспечения, предназначенного для поддержки процесса создания ПО на этапах разработки требований, проектирования, кодирования и тестирования. Поэтому к САSЕсредствам относятся редакторы проектов, словари данных, компиляторы, отладчики, средства построения систем и т. п.
САSЕ-технологии — это совокупность методологий и ин-
струментальных средств анализа, проектирования, разработки и
сопровождения ПО.
САSЕ-технологии предлагают поддержку процесса создания ПО путем автоматизации некоторых этапов разработки, а
также создания и предоставления информации, необходимой для
разработки. Приведем примеры тех процессов, которые можно
автоматизировать с помощью САSЕ-средств:
1. Разработка графических моделей системы на этапах со-
здания спецификации и проектирования.
2. Проектирование структуры ПО с использованием сло-
варей данных, хранящих информацию об объектах структуры и
связях между ними.
3. Генерирование пользовательских интерфейсов, на осно-
ве графического описания интерфейса, создаваемого в диалоговом режиме.
4. Отладка программ на основе информации, получаемой в
ходе выполнения программы.
5. Автоматическая трансляция программ, написанных на
устаревших языках программирования (например, СОВОL) в
программы, написанные на современных языках.
Фактически это повышение составляет примерно 40 %.
Хотя и это повышение весьма значительно, САSЕ технологии не
совершили революции в инженерии программного обеспечения,
как ожидалось.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]