Учебник по курсу теория систем и структурный подход к моделированию icon

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


Смотрите также:
Методические Указания к курсовому проекту по курсу «Теория информационных процессов и систем»...
Методические Указания к курсовому проекту по курсу «Теория информационных процессов и систем»...
«Технология разработки автоматизированных защитных систем»...
Темы курсовых работ по дисциплине «Социальная психология малых групп»...
Курс: «введение в проектирование систем: структурный подход». К. т н. Марк Шмуилович Левин...
Системный анализ, управление и обработка информации...
Примерная рабочая программа по курсу «теория систем и системный анализ»...
Реферат по курсу «Теория организации» на тему «Принципы динамической организации»...
Список тем курсовых работ по «Моделированию систем»...
Теория систем и системный анализ. Методическое пособие По курсу лекций: Красов А. В...
Перечень вопросов к экзамену по курсу «Проектирование автоматизированных систем»...
Программа вступительного испытания...



страницы:   1   2   3   4
Учебник по курсу

ТЕОРИЯ СИСТЕМ И СТРУКТУРНЫЙ ПОДХОД К МОДЕЛИРОВАНИЮ.

БИЗНЕС МОДЕЛИРОВАНИЕ.


Авторы:       

Васючкова Татьяна Сергеевна,  к.ф.-м. н., доцент, зам.декана ФИТ НГУ, Иванчева Наталья Александровна, ст. преподаватель, ФИТ НГУ

Содержание.

Часть I. Сущность, принципы и методологии структурного подхода к проектированию информационных систем.

1.1. Введение. Особенности программных изделий как объекта труда. Четыре подхода к организации процесса разработки программ. Две основные стратегии проектирования программных систем – функциональная декомпозиция (структурный подход) и объектно - ориентированное проектирование.

1.2. Краткий обзор основных понятий системологии. Определение системы. Классификация систем (физико – биологические, социальные, эрготехнические). Базовые категории системного подхода. Общие закономерности свойств, поведения, развития систем любой природы. Иерархичность структуры. Целостность и эмергентность. Целеобусловленность. Коммуникативность. Типы функционирования. Системное время. Управление и самоорганизация в системах.

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

1.4. Моделирование как главный метод системного обследования. Виды моделей. Особенности моделирования эрготехнических систем. Функциональное моделирование. Понятия целевой функции, критериев успеха, альтернатив в достижении цели, анализа риска.

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

Часть 2. Использование CASE-средств при проектировании информационных систем.
Введение. Моделирование систем. Методология SADT.

2.1.Функциональное моделирование в стандарте IDEF0.

2.1.1. Общие принципы.

2.1.2. Диаграммы в модели IDEF0.

2.1.3. Графический язык диаграмм нотации IDEF0.

2.1.4. Начальный этап моделирования.

2.1.5. Продолжение моделирования. Декомпозиция.

2.1.6. Рекомендации к процессу моделирования.

2.2.Функциональное моделирование   в среде  CASE-средства BPwin.

2.2.1.      Инструментарий BPwin для создания функциональной модели в  нотации IDEF0.

2.2.2.      Слияние и расщепление моделей.

2.2.3.      Функционально-Стоимостной анализ (АВС –Activity Based Costing)

2.3. Методология моделирования DFD (Date Flow Diagramming). Разработка

      диаграмм потоков данных в среде CASE-средства BPwin.

2.4. Методология IDEF3. Разработка диаграмм описания процессов в среде CASE-средства Bpwin.

2.5.Создание в среде CASE-средства BPwin смешанной модели.

2.6.Моделирование данных. Методология IDEF1X.

2.6.1. Реляционная модель данных.   

2.6.2. Проектирование реляционной модели.

2.6.3. Разработка модели данных в среде ERwin.

2.6.3.1. Логические модели данных.

2.6.3.2. Физические модели данных.

2.6.3.3. Инструменты ERwin.

2.6.3.4. Создание логической модели данных. Сущности и связи.

2.6.3.5. Создание физической модели данных.

 

 Часть 3. Лабораторный практикум.

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

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

Лабораторная работа 3. Разработка диаграммы верхнего уровня модели. Формулирование главной функции системы. Анализ обьектов и распределение их по типам интерфейсных дуг. Разработка контекстной диаграммы. Разработка диаграммы декомпозиции первого уровня.

Лабораторная работа 4. CASE-средство BPwin.
Изучение среды разработки и инструментария CASE-средства BPwin. Разбор примеров моделей в нотации IDEF0. Изучение элементов диаграмм в нотации IDEF0. Блоки и дуги. Иерархия диаграмм. Создание учебной модели для освоения инструментария.

Лабораторная работа 5. Разработка функциональной модели.
Выполнение индивидуального задания: создание функциональной модели системы в нотации IDEF0 c глубиной декомпозиции 3 уровня.

Лабораторная работа 6. Слияние моделей.
Разработка отдельной модели, отражающей декомпозицию отдельного функционального блока. Освоение технологии слияния моделей.

Лабораторная работа 7. Функционально-стоимостной анализ (ABC).
Изучение технологии функционально-стоимостного анализа (ABC). Определение центров и движителей затрат функциональных блоков модели. Расчет стоимости модели.

Лабораторная работа 8. Нотация DFD.
Изучение элементов диаграмм в нотации DFD. Работы (Activity).Потоки данных (Arrow). Внешние сущности (Еxternal Reference). Хранилища данных(Date Store). Правила нумерация обьектов.
Рассмотрение примеров. Освоение технологии разработки диаграмм DFD.

Лабораторная работа 9. Разработка диаграммы DFD.
Выполнение индивидуального задания: дополнение функциональной модели системы в нотации IDEF0.
Диаграммами потоков данных (DFD).

Лабораторная работа 10. Нотация IDEF3
Изучение элементов диаграмм в нотации IDEF3. Единицы работы (Unit of Work (UOW)). Типы связей: старшая (Precedence), отношение(Relational Link). Потоки обьектов (Object Flow). Перекрестки (Junction). Обьекты ссылки. Рассмотрение примеров. Освоение технологии создания диаграмм потоков работ.

Лабораторная работа 11. Разработка диаграммы IDEF3.
Выполнение индивидуального задания: дополнение функциональной модели системы в нотации IDEF0 диаграммами потоков работ (IDEF3).

Лабораторная работа 12. CASE-средство ERwin.
Изучение среды разработки CASE-средства ERwin. Рассмотрение примеров моделей.
Изучение элементов диаграмм в нотации ERD. Логическая и физическая модели данных.
Сущности, типы сущностей. Атрибуты. Ключи. Связи, типы связей. Категоризаторы.

Лабораторная работа 13. Разработка диаграммы ERD.
Выполнение индивидуального задания: разработка реляционной модели данных в нотации ERD для выбранной предметной области.

Лабораторная работа 14. Cвязывание модели данных и модели процессов.
Изучение технологии связывания модели данных и модели процессов. Экспорт данных из ERwin в BPwin и связывание модели данных со стрелками и работами. Экспорт и импорт через файлы формата .EAX - .BPX.

Заключение.
Рекомендации по дальнейшему изучению дисциплины. Обсуждение возможностей и целесообразности синтеза структурного и объектно – ориентированного подходов. Дополнительные задания для самостоятельного тренинга по применению изученных инструментальных средств.

^ Список используемых источников.

1) Коллинз Г., Блей Дж. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: Финансы и статистика, 1986. – 264 с.

2) Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление: Учебник. – М.: ИНФРА-М, 2005. – 319 с. (Учебники для программы МВА).

3) Антонов А.В. Системный анализ. Учеб. Для вузов. – М.: Высш. Шк., 2004.- 454 с.

4) Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами.- М.: Изд. Дом «Вильямс», 2004. – 1136 с.

5) Sommerwill I. Software engineering. Addison-Wesley Publ. Ltd., 1996. – 742 p.

6) Pressman R. S. Software Engineering. A practitioner’s approach. The McGraw-Hill Comp. Inc., 1997. 862 p.

7) Фокс Дж. Программное обеспечение и его разработка. М.: Мир, 1985. – 359 с.

8) Боэм Б. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. – 512 с.

9) Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. М.: Изд-во Бином, СПб.: Невский диалект, 1999. – 560 с.

10) Дэвид А. Марка и Клемент МакГоуэн «Методология структурного анализа и проектирования SADT».- М.: Изд. Мета Технология. 1993.- 240 с.


11) C.В.Маклаков «BPwin и Erwin. CASE-средства разработки информационных систем» Москва. ДИАЛОГ-МИФИ. 2001 г.


12) Каменова М., Громов А., Ферапонтов М, Шматалюк А. Моделирование бизнеса. Методология ARIS., М.: ООО Издательство «Серебряные нити», 2001. – 327 с.


13) Г.Н. Калянов, Case структурный системный анализ (автоматизация и применение), М.: Изд-во ЛОРИ, 1996


14) Сурмин Ю.П., Теория систем и системный анализ: Учеб. пособие. – К.: МАУП, 2003.- 368 с.


15) Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов: учеб. пособие. – М.: Финансы и статистика, 2007. – 240с.


16) Морозов В.П., Дымарский Я.С. Элементы теории управления ГАП: Математическое обеспечение. – Л.: Машиностроение, Ленингр. отделение, 1984.- 333 с.


17) О’Коннор Дж. Искусство системного мышления: Необходимые знания о системах и творческом подходе к решению проблем/ Джозеф О’Коннор и Иан Макдермот; Пер. с англ.. – М.: Альпина Бизнес Букс, 2006. - 256 с.

 


ПРЕДИСЛОВИЕ


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


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

  • анализ проблемы и постановка задачи, определение требований к ПО – при этом создается серия моделей для описания предметной области, изучения и корректной постановки задачи

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

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


Мы видим, что деятельность по производству программных систем – это деятельность, основанная на моделировании. Программирование как инженерная дисциплина использует много методологий, технологий. Но при решении вопроса разбиения задачи на подзадачи/системы на подсистемы (с детальной проработкой каждой подсистемы) все методы и технологии разделяются на две подгруппы – (1)структурный подход с функциональной декомпозицией и (2) объектно-ориентированный подход.


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

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


Авторы надеются, что этот курс будет полезен в двух отношениях

  • познакомит с идеологией структурного подхода и даст возможность освоить методы и инструменты, реализующие структурный подход - методологиею SADT, технологии и инструменты (DFD, IDEF0, IDEF1X, IDEF3, ERwin, BPwin, ERD)

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

Часть 1. Сущность, принципы и методологии структурного подхода к проектированию информационных систем


Раздел 1.1. Базовые понятия технологии разработки программ (Software Engineering)


1.1.1. Вычислительные машины – орудие труда нового типа

Очевидно, что потребность в программном обеспечении (ПО) определяется тем, для чего и как будет использоваться вычислительная машина. Создателям информационных технологий и программного обеспечения важно знать историю вопроса – как эволюционировало понимание ЭВМ в качестве орудия труда нового типа [7].


Марк Лухан утверждает, что каждое орудие представляет собой продолжение функций человеческих органов.


Дополняемый орган Орудие


Нога Колесо, велосипед, автомобиль, самолет


Кулак Камень, дубинка, ружье


Кожа Одежда


Глаз Очки, телескоп, микроскоп, радиолокатор


Рот, ухо Радио, микрофон


Мозг Бумага (память), калькулятор, арифмометр


Мозг Вычислительная машина


Воля *) Вычислительная машина


*) Воля понимается как способность принимать и исполнять решения


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


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


Прогресс в использовании вычислительных машин шел в точности по общей схеме.


  1. Сначала ЭВМ – «большой арифмометр» для научных и инженерных расчетов.




  1. Затем добавляется функция долговременного хранения больших объемов постоянно обновляющихся данных. Такие информационные системы (банковские, справочные, заказа авиабилетов и пр.) с мультидоступом и мультиобработкой данных способствовали прорывному росту технологий разработки программ. Появились базы данных, СУБД, декларативные языки описания данных, языки запросов, графические интерфейсы, мультимедиа.




  1. В 1910 году Бертран Рассел и Норт Уайтхед выпустили труд «Principia Mathematica», в котором выдвинули принцип, что основанием всех математических дисциплин является логика. То есть доказательство теорем, решения различных задач можно рассматривать в терминах специального вида утверждений, каждое из которых может быть истинным или ложным. Мы обнаруживаем, что ЭВМ не просто арифмометр и хранилище данных. Это еще и логическая машина. Логический вывод, поддержанный специальными инструментами, превращает ЭВМ в «генератора» знаний и в хранилище знаний. Множество задач и направлений искусственного интеллекта базируется на понимании ЭВМ как логической машины.




  1. Наконец, самое сложное использование ЭВМ – динамическое управление системами, где на каждом шаге делается выбор варианта дальнейшего поведения в зависимости от предыдущего поведения и влияния случайных воздействий в непредсказуемые моменты времени. Как правило, такие сложные системы содержат в себе элементы и действия, связанные с перечисленными выше – в пунктах 1-3.


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


1.1.2. Программный продукт как объект труда – признаки сложности


  1. Большая программная система никогда не может быть отлажена до конца, даже после многих лет тестирования и использования. До конца могут быть отлажены только маленькие программы. В больших и сложных программах слишком много путей исполнения и действий пользователей. В таких системах число вариантов (маршрутов) исполнения может составлять 10 в степени 3000 и более. Заметим, что возраст Вселенной в секундах меньше! То есть за тысячи лет мы не сможем с помощью тестирования проверить правильность работы каждой веточки исполнения у такой программы. Нельзя говорить – «в программной системе нет ошибок». С учетом вышесказанного такое утверждение некорректно. Корректным будет сказать – «на наборе из ста тысяч тестов система работает правильно».




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




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




  1. Эффект большого масштаба проявляется на программных системах объемом более 300000 строк и существенно усложняет разработку системы. (1) Резко снижается средняя производительность труда исполнителей, (2) Проблема планирования и координации усилии сотен (иногда тысяч!) исполнителей требует создания инфраструктуры, документирующей планы, их изменения, отчеты по фактическому состоянию дел. Необходимо применять специальные методы распределения работ, создания команд исполнителей, правил взаимодействия между исполнителями/командами. Для управления разработкой действительно большой системы более 50% средств затрачивается на планирование, проверку, составление графиков, руководство и управление. (3) Существенно возрастает объем документации в удельном выражении – на 1000 строк простой программы надо писать меньше документации, чем на 1000 строк большой системы.




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

(2) Логическая сложность проявляется в многообразии различных вариантов, выбор среди которых надо производить на каждом шаге решения.

Ф. Брукс в своей книге «Мифический человеко-месяц» утверждает, что системное программное обеспечение в девять раз труднее разрабатывать, чем прикладное. Главная причина в его высокой логической сложности.


  1. Отсутствие ясных и полных требований к большой системе в начале разработки. Дж. Фокс, замечательную книгу которого «Программное обеспечение и его разработка» [7] мы постоянно цитируем, приводит типичный пример. При построении системы автоматизации нефтеочистительных заводов программист спрашивает, каким образом инженер-нефтяник узнает, когда надо нажать на рычаг. Тот отвечает «Очень просто. Я опускаю палец в струю и пробую на вкус» Попытайтесь теперь запрограммировать это! Нередко при построении больших систем управления процессами, взаимодействующих со многими пользователями, реальное использование вычислительной машины можно осознать только после того, как система попадет в руки пользователей! Пользователи всегда находят новые способы применения своих инструментов.

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

    • обеспечение легкости внесения изменений

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




  1. Свойства программ конфликтуют между собой. Разрешая эти конфликты, разработчик стоит перед сложным выбором компромисса.

Ниже перечисляются 12 свойств, присущих всем программам.


Характеристика программ Понятия с этим Фаза жизненного

связанные цикла


(1) Заставляет ЭВМ выпол- Функция Фаза

нять задание использования


(2) Занимает память ЭВМ Размер Фаза

использования


(3) Тратит ресурсы ЦП Эффективность Фаза

(центрального процессора) использования


(4) Легкость использования Практичность Фаза

использования


(5) Легкость восстановления Устойчивость Фаза

после сбоя восстанавливаемость использования


(6) Содержит ошибки Правильность Фаза

использования


(7) Требует времени для График разработки Фаза создания разработки


(8) Требует людей для Людские ресурсы Фаза

создания на разработку разработки


(9) Требует специального Материальные Фаза

инструментария для ресурсы на разработки

разработки разработку


(10) Требует денег для Стоимость Фаза

создания разработки


(11) Модифицируется Архитектура Фаза

структура сопровождения


(12) Существует по кра- Документация Фаза йней мере в одной сопровождения

форме, а нужно две


Стремление воплотить эти характеристики в программу приводит к конфликтам. В программах написанных очень быстро (характеристика 7), обычно крайне неэкономно используется память и машинное время (характеристики 2 и 3) по сравнению с программами, которые писались медленнее. Кроме того, быстро написанные программы обычно не выполняют на все 100% функции, которые они должны были выполнять (1).

Если на создание программы требуется 100 чел.-мес., то мы могли бы взять 10 программистов, которые будут работать 10 месяцев. Но сделать эту же работу за 1 месяц, наняв 100 человек, невозможно. Укороченные графики (7) могут совершенно разрушить попытку построить стройную, легко модифицируемую структуру (11). Малая стоимость разработки (10) находится в явном противоречии со всеми остальными аспектами.



  1. Качество программы зависит от ее типа – не надо усложнять разработку программы необязательными требованиями [7]. Некоторые программы и не требуется развивать, или делать дорогой дружественный интерфейс пользователя. Все инструменты проходят два этапа – разработку и использование. У большинства есть и третий этап – техническое обслуживание и совершенствование на фоне использования. Простая деревянная зубочистка – предмет одноразового использования, она не требует ремонта. Существуют и программы – зубочистки. После получения результата ее можно выкинуть. Существуют программы типа молотка. Их пишут, используют очень много раз. Как и молотки, они не требуют никаких модификаций, изменений и исправлений. Существуют программы типа небоскреба. Они, как и здания, требуют ремонта, перепланировки и некоторого дополнительного сопровождения. Большинство программ – это «небоскребы». Они требуют самого тщательного документирования для сопровождения и дальнейшей модификации при выпуске версий программы.


1.1.3. Процесс разработки программ – жизненный цикл программного обеспечения


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


Любое программное изделие проходит следующие этапы [5].

  • анализ требований

  • проектирование

  • кодирование (программирование)

  • тестирование и отладка

  • эксплуатация и сопровождение


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


Популярны три вида моделей ЖЦПО для программ разного масштаба и сложности


  1. Каскадная модель (70-80гг.) – предполагает переход на следующий этап после полного окончания работ по предыдущему этапу.

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

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

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


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

  1. Подход по модели водопада/каскадной модели – для небольших, несложных, типовых задач

  2. Эволюционные подходы по итеративной и спиральной моделям – для задач средней сложности, с элементами новизны, с необходимостью искать новые решения

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

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



Самыми сложными являются этапы анализа требований и постановки задачи, проектирования. Если ошибку, допущенную на этих этапах, не «отловить» сразу, ее должна обнаружить процедура тестирования. Но тогда стоимость в человеко-часах исправления этой ошибки будет в 10 – 30 раз выше. Если и тестирование не обнаружит такую ошибку, то проект может завершиться неудачей.


На этапе анализа требований нужно ответить на вопрос «Что должна делать будущая система?». В практике создания ПО [13] известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.


Список требований к разрабатываемой системе должен включать


  • совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, внешние условия ее функционирования, состав людей и работ)

  • описание выполняемых системой функций

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


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


  • архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО

  • интерфейсы и распределение функций между человеком и системой

  • требования к программным и информационным компонентам ПО, необходимые программные ресурсы, аппаратные ресурсы, требования к БД, интерфейсы компонентов.


Этап проектирования дает ответ на вопрос «Как система будет удовлетворять, предъявленным ей требованиям, Что она должна делать?». Исследуются структура системы, логические связи ее элементов. Но в отвлечении от реализации на конкретной платформе.


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


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

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


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






Скачать 0.54 Mb.
оставить комментарий
страница1/4
Дата28.09.2011
Размер0.54 Mb.
ТипУчебник, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы:   1   2   3   4
плохо
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

Рейтинг@Mail.ru
наверх