IID – инкрементная итеративная разработка

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

Эволюционная модель. Итерационная разработка

Итеративный подход предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все этапы жизненного цикла ПО в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии (релиза) ПО, включающей функциональность всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементно.

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

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

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

· очень рано начать тестирование пользователями;

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

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

Эволюционная модель. Инкрементная разработка

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

Для организации инкрементной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление проекта: добавляется новая документация как текстовая, так и графическая (например, новые диаграммы на UML), расширяется набор тестов, добавляются новые программные коды и т. д. Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементная разработка проходит лучше всего, если следующая итерация n+1 начинается после того, как обновление всех артефактов в итерации n закончено, и существенно хуже, если время, требуемое на обновление артефактов, значительно превышает выбранный интервал.

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

 

5. Технологии и методы проектирования ИС.

 

Проектирование ЭИС

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

Проект ЭИС - это проектно-конструкторская и технологическая документация, в которой представлено описание проектных решений по созданию и эксплуатации ЭИС в конкретной программно-технической среде

Технология проектирования ЭИС - это совокупность:

- методов (+ концепция);

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

- методов и средств организации проектирования (управление проектом создания ЭИС).

 

Классификация методов проектирования:

1) По степени автоматизации проектных работ:

- ручное проектирование;

- автоматизированное проектирование.

 

2) По степени типизации:

- оригинальное проектирование;

- типовое проектирование.

 

3) По степени адаптивности проектных решений:

- реконструкция (перепрограммирование);

- параметризация (настройка);

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

 

Основные классы технологий проектирования:

1) Каноническая технология (обычное ручное оригинальное проектирование);

2) Индустриальная технология:

- автоматизированное проектирование (применение CASE-средств);

- типовое проектирование (бывает параметрически-ориентированное и модельно-ориентированное).

 

 

6. Типовое проектирование ИС. Классификация типовых проектных решений (ТПР). Методы типового проектирования. Критерии оценки пакетов прикладных программ.

 

Типовое проектирование ИС предполагает создание систем из готовых типовых элементов.

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

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

Типовое проектное решение (ТПР) – это тиражируемое, пригодное к многократному использованию проектное решение

Методы типового проектирования:

- элементный;

- подсистемный;

- объектный.

Элементные ТПР - это типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному).

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

– сложность сопряжения и доработки.

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

+ модульное проектирование;

+ параметрическая настройка;

+ сокращение затрат на проектирование;

+ хорошее документирование;

– сложность комплексирования.

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

+ высокая степень интеграции;

+ открытость архитектуры;

+ масштабируемость;

+ конфигурируемость;

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

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

- параметрически-ориентированный;

- модельно-ориентированный.

Параметрически-ориентированное проектирование включает следующие этапы:

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

- анализ и оценка доступных ПП;

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

- настройка параметров (доработка) ППП;

- обучение персонала.

 

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

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

 

Критерии оценки ППП

- назначение и возможности пакета;

- отличительные признаки и свойства пакета;

- требования к техническим и программным средствам;

- документация пакета;

- факторы финансового порядка;

- особенности установки пакета;

- особенности эксплуатации пакета;

- помощь поставщика по внедрению и поддержке;

- оценка качества пакета и опыт его использования;

- перспективы развития пакета;

 

7. Моделирование предметной области как основа проектирования ИС.

 

В основе проектирования ИС лежит моделирование предметной области.

Модель предметной области – некоторая система, имитирующая структуру или функционирование исследуемой предметной области.

Модели позволяют оценить достоинства и недостатки существующей ИС и построить эффективную архитектуру новой ИС.

Требования к моделям

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

- понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

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

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

 

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

Структурный аспект предполагает построение:

1) объектной структуры;

2) функциональной структуры;

3) структуры управления;

4) организационной структуры;

5) технической структуры.

 

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

 

1) Объектная структура - отражает состав взаимодействующих в процессах материальных и информационных объектов предметной области.

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

 

2) Функциональная структура - отражает взаимосвязь функций (действий) по преобразованию объектов в процессах.

Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Бизнес-процессы и информационные процессы, как правило, неразрывны.

Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

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

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

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

 

3) Структура управления - отражает события и бизнес-правила, которые воздействуют на выполнение процессов.

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

 

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

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

5) Техническая структура определяет:

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

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

 

Оценочные аспекты связаны с показателями эффективности автоматизируемых процессов:

1) время решения задачи;

2) стоимостные затраты на обработку информации;

3) надежность процессов;

4) косвенные показатели эффективности.

 

Для расчета показателей используются статические и динамическиеметоды.

 

Уровни детализации аспектов:

1) Внешний уровень – определение требований (состав основных компонентов системы);

2) Концептуальный уровень – спецификация требований (характер взаимодействия компонентов системы);

3) Внутренний уровень – реализация требований (программно-технические средства для реализации требований).

 

Методологии моделирования предметной области:

- функционально-ориентированные

- объектно-ориентированные

 

Функционально-ориентированный подход

Организация рассматривается как набор функций, связанных потоками объектов.

+ структурный подход к проектированию;

+ процедурная строгость декомпозиции;

+ высокая наглядность представления;

– процессы отделены от данных;

– низкая адаптивность к изменению предметной области.

Графические методы: IDEF0, DFD, IDEF3, IDEF1x, EPC ид.р

 

Объектно-ориентированный подход

Модель предметной области рассматривается как совокупность взаимодействующих во времени объектов.

+ Высокая устойчивость к изменениям предметной области;

+ Лучшая реализация динамического поведения системы;

– Низкая наглядность представления.

Графический метод: UML (Unified Modeling Language)

 

Цели создания моделей деятельности предприятия

- подготовка к внедрению корпоративной информационной системы;

- проведение реорганизации деятельности предприятия (реинжиниринг бизнес- процессов);

- подготовка предприятия к сертификации по стандартам ISO 9000.

 

8. Методология IDEF1X. Назначение. Правила построения моделей данных.

 

IDEF1X(IDEF1 еХtended) – методология построения реляционных структур. Относится к типу методологий «сущность – связь» и используется для моделирования реляционных БД в системе.

Стандарт IDEF1x используют для:

o Представления информационных потоков и структуру данных

o Создания полной карты баз данных и их связей с другими информационными системами

o Анализа информационных ресурсов организации

o Выявления несовершенств текущей реализации структуры базы данных организации

o Реализации более качественного метода использования информационных ресурсов организации

 

Согласно стандарту, основными составляющими модели IDEF1X являются:

1) люди, предметы, явления, о которых хранится информация (далее – сущности)

2) связи между этими элементами (далее – отношения)

3) характеристики этих элементов (далее – атрибуты)

Сущность – это множество реальных или абстрактных объектов (людей, мест, событий), обладающих общими атрибутами или характеристиками.

Типы зависимых сущностей:

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

- Категориальная – дочерняя сущность в иерархии наследования

- Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущности

- Именующая - частный случай ассоциативной сущности, не имеет собственных атрибутов, только атрибуты родительской сущности

 

1. Сущность должна иметь уникальное имя и именоваться существительным в единственном числе.

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

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

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

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

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

Различают следующие уровни представления сущности: диаграмма «сущность-связь» (ERD), модель данных, основанная на ключах (KB), полная атрибутивная модель (FA)

Атрибут – характеристика сущности.

1. Каждый атрибут каждой сущности обладает уникальным именем.

2. Сущность может обладать любым количеством атрибутов.

3. Различают собственные и наследуемые атрибуты. Собственные атрибуты являются уникальными в рамках модели. Наследуемые передаются от сущности-родителя при определении идентифицирующей связи.

Отношения – связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (имеет, определяет, …).

1) При определении отношения типа «родитель-потомок»:

1.1. Экземпляр потомка связан с одним родителем

1.2. Экземпляр-родитель может быть связан с несколькими экземплярами потомков.

2) В идентифицирующем отношении сущность-потомок всегда является зависимой от идентифицирующей сущности.

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

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

 

9. Методология IDEF0. Назначение. Область применения. Правила построения диаграмм в нотации IDEF0.

 

IDEF0– методология функционального моделирования. Система отображается в виде набора взаимосвязанных функциональных блоков.

(Разработан в 1981 г. в рамках программы ICAM.)

Основа стандарта – методология структурного анализа и проектирования SADT (Structured Analysis and Design Technique) Дугласа Росса. Модель SADT(IDEF0) представляет собой иерархическую систему диаграмм.

Полноту и точность модели обеспечивает:

- четкая цель моделирования;

- одна точка зрения;

- единственный субъект моделирования (границы модели).

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

Стандарт IDEF0 используют для:

o Документирования связей процессов в общем виде

o Выявления скрытых процессов организации

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

o Выявление "узких мест" процессов организации

 

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

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

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

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

Стрелки (дуги)

- Вход (Input) – материал или информация, которые используются (преобразуются) работой для получения результата (выхода).

- Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Управление влияет на работу, но не преобразуется работой. У каждой работы должно быть управление.

- Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода.

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

- Вызов (Call) – обращение к другой модели.

 

Декомпозиция

 

10. Методологии IDEF3. Назначение. Область применения. Правила построения диаграмм в нотации IDEF3.

 

IDEF3– методология документирования процессов. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. Относится к классу нотаций WFD (Work Flow Diagrams) и предназначена для описания бизнес-процессов нижнего уровня.

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

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

· Записывать в терминах системного анализа сырые данные, полученные в ходе интервью.

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

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

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

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

· Создавать имитационные модели.

IDEF3 рассматривает поведенческие аспекты существующих или проектируемых систем. Знания о процессах структурированы в виде контекстных сценариев, что делает IDEF3 удобным инструментом сбора данных для описания системы.

Синтаксические элементы IDEF3

UOW (Unit Of Work, Activity, Работа)

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

Связи

Показывают взаимоотношения работ. Все связи однонаправлены и могут быть направлены куда угодно (обычно слева направо). В IDEF3 возможны три вида связей:

Объект ссылки (Referent)

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

Перекрестки

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

Различают:

перекрестки для слияния (Fan-in Junction)

перекрестки для разветвления (Fan-out Junction)

 

11. Нотация DFD. Правила построения DFD-диаграмм.

 

DFD(Data Flow Diagrams) – диаграммы потоков данных. Описывают внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ.

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

Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko).

В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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

Функциональные блоки

Функциональный блок DFD моделирует некоторую функцию, которая преобразует сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения, как IDEFO. В некоторых интерпретациях нотации DFD Гейна-Сарсона механизмы исполнения IDEFO моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 4.3).

Внешние сущности

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