Синтаксическая мера информации

В 1928 году Р.Хартли за единицу количественной меры информации, количество информации по формуле Хартли имеет вид.

Бит равен информации которая передается при приеме одного из двух равно вероятных сообщений.

При получение информации в один бит неопределенность, энтропия, уменьшается в два раза.

Семантическая мера информации

Тогда графически имеем оптимальное значение дисаупсового пользователя. Максимальное значение количества семантической информации получается. Когда поступающая информация с одной стороны понятна пользователю, а с другой несет раннее неизвестные ему сведения. Эта ценность информационного сообщения beta для системы управления альфа.

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

В такой постановки экономисты единицей измерения ценности информации считают денежные единицы.

Типовые компоненты архитектур информационных систем

Групповые и корпаротивные информационные системы могут строиться на основе различных архитектур.

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

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

ПС обеспечение средствами применяющими ввод от пользователя и отображающие то что ему сообщает ПЛ.

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

Логика управления данными, операций с базами для реализации прикладной логики управления операций с базами вызываемым для выполнения логики управления данными такие как, манипулирование данными, определение

Файловая операция

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

Вариант архитектура	Распределение компонентов	Пример реализации
клиент	Сервер 1	Сервер 2
Удаленное представленние данных с дост. К linux-системе	Ps LS	BL, DL, DS, FS	-

Рассмотрим варианты разработки IT инфраструктуры.

Уровень инфраструктуры.

Уровень приложений

Уровень ОС

Серверный уровень

Инженерный уровень

 

Уровень пользователя

Уровень приложения

Уровень ОС

Серверный уровень

Сетевой уровень

Инфраструктурный уровень

Резервный ВЦ

 

Уровень пользователя

Уровень приложений

Уровень ОС уровень ОС

Серверный уровень серверный уровень

Сетевой уровень сетевой уровень

Инженерный уровень инженерный уровень

Распределений ВЦ

 

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

1)технический уровень – установка вычислительной техники. Как правило вместе с техническими средствами устанавливается некоторое типовое ПО. Автоматизация документа оборота – самое примитивная форма

2)уровень автономных задач – разработка и внедрение программных средств для которых характерны следующие особенности:

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

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

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

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

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

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

В составе корпаротивных систем выделяют:

1)телекоммуникационную платформу обеспечивающую обмен информацией между удаленно расположенными узлами

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

3)информационная база – локальные и распределенные базы данных и СУБД

4)совокупность приложений – под приложениями понимается прикладное программное средство ориентированное на сбор, хранение, поиск и обработку информации. Таким образом в рамках корпаротивной информационной системы (КИС) элементом формирования уникальной части приложений является:

-тип приложения с точки зрения задач управления

-архитектура КИС

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

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

1)Приложение автоматизации документа оборот

- общее

-обще системные

-специальная

2)программное

-общее

-общесистемное

-специальное

3)информационное обеспечение

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

-унифицированная система документов

-база данных

Жизненный цикл ПО и средства его поддержки

Понятие жизненного цикла ПО

Жизненные циклы как путь из реального мира в мир абстракции и обратно представлен на рисунке.

Жизненный цикл ПО это непрерывный процесс который начинается с момента принятия решения по необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуататора.

На ряду с понятием жизненного цикл используется понятие модели ЖЦ. То есть формализованного описания процессов, составляющих ЖЦ.

ЖЦ программного обеспечения неразрывно связан с АСУ, АС, ИС, АИС.

Основными стандартами регламентирующими содержание жизненного цикла ПО.

Это стандарт где ЕСПД единая система программной документации.

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

Кроме этого организациями производителя ПО могут пприменяться различные отраслевые и корпаротивные. К таким стандартам следует отнести:

6)методика Oracle

И другие практики системной инженерии.

Рассмотрим путем сведения в таблицу стадии и этапы создания по ГОСТ 34.601, Гост 24.602-86 и ГОСТ 19.102-77. Представим графически V образную модель жизненного цикла и остальные пункты 6-10 в виде рисунков с пояснением.

Формирование требований к АС

1.1 обследование объекта и обоснование необходимости формирований требований пользователя к АС, оформление отчета о выполненной работе и заявки на разработку АС.

1.2 2)разработка концепций АС, изучение объекта, с разработкой вариантов концепций АС и выбор варианта удолетворяещего треббованиям пользователя.

2.4 оформление отчета о выполненной работе

3) техническое задание, разработка и утверждение технического задания на создания АС

4)эскизный проект

4.1)разработка предварительных проектных решений по системе и её частям.

4.2) разработка документаций на АС и её части

5)технические

И или технический требований, техничечских заданий на их разработку,

5.4 разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6)Рабочая документация

6.1)разработка рабочей документации на систему и её части

6.2) разработка или адаптация программ

7)ввод в действие

7.1)подготовка объекта автоматизации к вводу АС в действии

7.2)подготовка персонала

7.3)комплектация АС поставляемыми издельями (программными и техническими средства, программными техническими комплексами, информационными издельями

7.4)строительно монтажные

7.5)

7.6)проведение предварительных испытаний

7.7)проведение опытной эксплуатации

7.8)проведение приемочных испытаний

8)сопровождение АС

8.1)выполнение работ в соответствие с гарантийными обязательствами

8.2)после гарантийные

Разработка и оформление требования к системе

2.1)научно исследовательские работы

2.2)разработка ован проекта

2.3)разработка технического задания на АСУ

3.1)разработка предварительных решений по выбранному варианту АСУ и отдельным видам обеспечения

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

4.3)разработка решений по техническому обеспечению

4.4)разработка (выбор) алгоритмов автоматизируемой деятельности

4.9)разработка проектно-сметной строительной документации.

4.10)согласование решений по связям видов обеспечения и разработка обще системной документации на АСУ в целом

4.11)составление заказной документации на компоненты комплекса средств автоматизации или технического задания на их разработка

5.5)разработка или адаптация программ и документации

 

К основным процессам относятся, приобретение, поставка,

3)разработка

3а)анализ

3б)проектирование

3в)программирование

3г)оформление документации

-проектная

-эксплуатационная

3д)подготовка тестов

3е)подготовка материалов для обучения

4)эксплуатация

4а)внедрение компонентов ПО

4а1)конфигурирование

-базы данных

-рабочих мест пользователя

4а2)обеспечение эксплуатационной документации

4а3)проведение обучения персонала

4б)локализация проблем

4в)устранение причин возникновения проблем

4г)модификация программного обеспечения в рамках установленного проекта

4д)подготовка приложений по совершенствованию развитию и модернизации системы.

5)сопровождение

Вспомогательные процессы

1)документирование

2)управление конфигурацией

2а)управление версиями

2б)конфигурационный учет

2в)планирование

Организационные процессы

1)управление проектами

1а)планирование и организация работ

1б)создание коллективов разработчика

1в)контроль за сроками и качеством выполненных работ

-верификация

-проверка

-тестирование

2)создание инфраструктуры проекта

3)определение, оценка, и улучшение самого жизненного цикла.

4)обучение

Системная инженерия – это процессы жизненного цикла системы.

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

 

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

Валидация это потверждение что система удолетворяет пользовательским требованиям

Проверка или верификация это потверждение что специфированные к системе требования выполняются.

Стандартом iso ie15.288 стадии жизненного цикла, жестко не предписываются (они предписываются iso ie12,207)

25 обязательных процессов системной инженерии

1)обеспечение проектов

1а)управление моделью жизненного цикла

1б)управление инфраструктуры

1в)управление портфелем проектов

1г)управление персоналом

1д)управление качеством

2)проектные

2а)управление проектами

-управление планирования

-управление выполнением и контроль проекта

2б)поддержка проектов

-управление решениями

-управление рисками

-управление конфигурацией

-управление информацией

3)изготовление

4)интеграция

5)проверка

6)переход к эксплуатации

7)приемка

8)эксплуатация

9)обслуживание

10)вывод из эксплуатации

Модели жизненного цикла ПО

Определяет последовательность выполнения и взаимосвязи процессов, действий и задач на протяжение жизненного цикла.

Поэтапная модель

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

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

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

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

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

1)быстрая прототипирование

2)

Быстрое прототипирование

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

автоматизированые информационые системы

Приложение организационого управления они отражают состояние предметной в любои момент времени преобрадает режим Online Translation Processig (OLTP) оперативный режим

транзация - неделимый набор операций с базой данных

2.прил поддержки принятие решения Decison Suppor Systen (DSS)

преобладают сложные транзации и аналитическая обработка Оnline Analys Processing (OLAP)

приложения аналитического анализа данных и разного рода экспортные системы

3.инф справочные приложения

4.прил автоматизации документа

ЖИЗНЕНЫЙ ЦИКЛ И СТАНДАРТЫ.

согластно сборника 24 ГОСТ наиболее сущ. являются следующие виды обеспечения

1.математическая

-общая

-общая сист

-специальная

2.программная

-общая

-общая сист.

-специальная

3.информационое обеспечен

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

-унифец сист документов

-БД

ЖИЗНЕНЫЙ ЦИКЛ ПРОГРАМНОГО ОБЕСПЕЧИВАНИЯ И СРЕДСТВО ЕГО ПОДДЕРЖКИ.

1.понятие жизненого цикла програмного обеспечения

Функции. требования внешняя спецификация

что зачем

 

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

ЖЦ програмного обеспечения неразрывно связан с АСУ, АС, ИС, АИС.

основными стандартами регламет содержание ЖЦ.

1. ISO/IES 12207 (ISO - Internation Organizator of Stardatizator)(IES-

2.ISO/IES 15288

3. ГОСТ ЕСПД 19.102-77 этот стандарт (стандарт разработки)-сборник -19.

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

4. ГОСТ 24.602-86 (АСУ Состав и содержание по стадиям)

5.ГОСТ 34.601-90 (ИТ Комп. станд. на АС АС стандарт создания)

кроме этого ПО могут применяться различные отраслевые и кооперативные стандарты

6.Методика Orale CDM (Custon Develoment Method)

7. Методика ASDH (Astro Software Develome House)

8. Модель RAD (Raid Application Devolpment)

9.Модель ХP (eXreme Programing)

и др практики сист

рассмотрим путем таблицы стадие и этапы созд 34.601-90, ГОСТ 24.602-86 и ГОСТ 19.102-77

представим графически V- образная модель ЖЦ и остальные пункты 6-10 в виде рис.

1.1 обследование обекта и обоснование необходимости создание АС

1.2 формерование требование пользователя к АС

1.3 оформление отсчетов о выполненой работе и заявки АС(ТТЗ-тактико техническое задание)

2.разр АС

2.1 изучение обекта

2.2 проведение необходимых научно иследоват работ

2.3 разработка вариантов концепции АС и выбор варианта удовлетв требования польз

2.4 оформ отсчета о вып раб

3. тех задание

3.1 разработка и утверждение тех задания на созжание АС

4.искизный поект

4.1 разработка предварительных проект решений по системе и частям

4.2 разработка документачции на АС и её части

5.тех проект

5.1 разработка проектных решений по системе и её частям

5.2 разработка документации на АС и её части

5.3 разработка и оформление докуентации на поставку системы АС и или тех требований (тех заданий на их разр)

5.4 разработка заданий на проектировании в смежных частях проекта

6.рабоч документ

6.1 разработка документации на систему и части

6.2 разработка или одаптация программ

7. ввод бействий

7.1 подготовка об. к вводу АС действий

7.2 подготовка персонала

7.3 поставляем изделий (програмными и тех средсьвами, програмно тех комплексами, инф изделиями)

7.4 строительно монтаж работа

7.5 пуск налад работы

7.6 проведение испытаний

7.7 проведение опытной эксплуатац

7.8 проведение приём испытаний

8. сопровожд АС

8.1 выполнение работ в соответствии с гарант обяз

8.2 после гарант обслуживание.

сис с АСУ этапы АСУ ГОСТ 24.602-86.

1.Иследование и созд

2.Тех создание

3. Эксказ проект

4.Искизный

5.Рабоч документ.

6.изготовление не серийных компонентов

7.ввод в действие

1.1 обследование Автом Обекта

1.2 разработка и оформление требование в системе

2.1 научно иследовательские работы

2.2 разработка АВАН проэкта

2.3 разраб тех задания на АСУ

3.1 разработка предварительных решений по выбраному варианту АСУ и отдельным видам обеспечению

4.1 разработка окончательных решений по обще системю вопросам

4.2 разработка решений по организац решен

4.3 разработка решений по тех

4.4 разраб (выбор) алгоритм автоматизированых дейставй

4.5 разработка решений

4.6 разработка решений по лингвистическому обесп

4.7 програмному

4.8 по методическому

4.9 проекто смертной строительной

4.10 согласование решений по связям видов обеспечен меижу собой и разработка общей сист автоматиз на АСУ

4.11 составление заказ. док. на компоненты средств или ТЗ на их разработку

5.1 РД разраб по инф обеспеч

5.2 разработка РД

5.3 РД по методическому

5.4 по лингвистич

5.5 разраб програм и документов

5.6 на тех средства разового изготовления

5.7 раз. проектно смертной строительной докум

6.1 компонентов кса

6.2 автоном обкладка и испытание

7.1 подготовка организации к воду АСУ действий обуч. персонала полз

7.2 комплект АСУ

7.3 строит монтажные раб

7.4 пуско налад работы (комплекс)

7.5 проведение опытной эксплуатац АС У

7.6 проведение опыт

7.7 устранение замеч при работе

7.8 приёмка АСУ в пром инф

ГОСТ 19.102-77 стадия разраб ЭТап разраб

1.техническое задание

2.эскизный проект

3.технический проэкт

4.рабочий проект

5. внедрение

1.1 необходимости разраб програмы

1.2 науч иследовательские раб

1.3 раз и утверждение тех задания

2.1 разработка тех проэкт.

3.1 раз тех про

4.1 разраб програмы

4.2 програмной

4.3 испытание програмы

5.1 подготовка передачи программы

26.02.2013.

ISO/Ies 12207

Жц по

Основные процессы вспомогательные процессы

К основным процессам отнросится

1.приобретение

2.поставка

3.постановка

3.а. анализ

3.б.проект

3.г.оформ документации

-проектной

-эксплуатац

3.д.подг тестов

3.е подготовка мат обучения

4.эксплуатац

4.а.внедрение компонентов программного обеспечения

4.а.1. конфигурирование

-БД

-раб мест пользователей

4.а.2.обеспец документац

4.а.3.проведение обучение персонала

4.б.локализация проблем

4.в.устранение причин проблем

4.г.модифекация ПО в рамках уст проекта

4.д.подготовка приложений по совершествованию и модернизации сист

5.сопровождение

Вспомогательные процессы

1.документир

2.упр конфигурации

2.а.упр версиями

2.б.конфигурационый учет

2.в. планирование

Организационные процессы

1.упр проектами

1.а.планирование и организация раб

1.б создание коллектива разраб

1.в. контр за сроками и качеством работ

1.в.

-верификац

-проверка

-тестирование

2.создание инфо структ проекта

3.определение оценка и улучшение самого ЖЦ

4.обучение

Согласно ISO/IEC 15288 системная инженерия это процессы ЖЦ систем

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

Зафиксированный вариант (Baseline) это вариант спецификации или самой системы прошедшей формальное согласованиеи утверждение явл основанием для дальнейшего развития в которой внесены только через формальную процедуру или вариант продукта услуги.

Процесс это набор взаимосвязанных или действий преобразующий входы в выходы (ISO 9000;205) процессы сост из задач

Продукт процесса проект это мероприятие с определенными критериями начала и окончания предназначенное для создания продукта или услуги с учетом ресурсов и требований может быть рассмотрен как уникальтный экземпляр процесса состаящий из скординированых и управяемых действий и может вкл дейст из тех процессов определенных 15288

Приемка это подтверждение что система удовлетв ползов требованиям

Проверка (verification) подтверждение к сист выполняется.

Стандартом ISO/IEC 15288 стадии ЖЦ жестко не приписываются (они приписыв ISO/IEC 12277)

ISO/IEC 25 обязательных процессов систем инженер

1.обеспеч проектов

1.а.упр моделью ЖЦ

1.б. упр инфро структурой

1.в.упр прртф пректов

1.г.персоналом

1.д.качество

2.проектные

2.а.упр проектами

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

-управление управлением и контроль проекта

2.б поддержка проекта

-управление решениями

-управления рисками

-упр конфигурацией

-упр информации

Процессы обеспеч и проект процессы обеспечивают тех процесс

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

2.архитектурный дизайн

IEEE 1471 ISO/IEC 42010^2007

3.изготовление

4.интеграция

5.проверка

6.переход к эсплуатации

7.приемка

8.эксплуатация

9.обслуживание

10.вывод из эксплуатац

Контрактации

1.закупка

2.прставка

Модели ЖЦ программного обеспечения ……………………………………………………………………………………………………..стр..9.

Модель ЖЦ определяет последовательност выполнения и взаимосвязи процессов действий и задац на протяжении ЖЦ. модель ЖЦ зависит от специфики программного средства и спец условий в которой сист создается и функционир

В настояшее время наиболее

1.коскадное (1970:80)

2.поетапное (80:85)

3.спиральное (86:н.в)

Каскадная модель

Анализ требования

Приемно сдаточное испытание

Внешняя спецификация Комилическая отлад

Детальное проектирование автономная отделка

Кодирование

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

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

1.дискретной(во времени) тех процесс с остановками по завершению каждлго этапа и возможностью контроля и возврата при не удовлетвро результата (итерации разработки)

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

3.дисцеплина требует не переходить к этапу до полного заверш преведущего

Недостатки каскадной модели

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

2.болшая длительност полного цикла

Этим ЖЦ можно пользоваться дря расч систем сист реального времени

На рис линии сфера разграничении программистов и систем аналитиков

Такая модель соответствует V-модели по ISO/IEC 5288

 

идея функц и

Проверка и прим

треби архит развит

демократиз рабоч пров и прием

спец проекта проект сборка и

тест интегриров

и тест проект

 

реализация

 

t

 

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

Проверка функции

Проверка архитектуры

Проверка кода

код

архитектура

функции

требования

Под поэтапной моделью понимают V-образную модель интерпи=ритированую в след модели

 

 

 

 

 

Согласование результатов

С пользователем планиро

ванных с каждым

этапом. требования к прогр

системой в виде тех задания на все время

создания.

 

СПИЛАЛЬНАЯ МОДЕЛЬ.

Функциональное полотно

Комплексная откладка ВРЕМЯ

Т3

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

испытание

 

автономная кодировано

откладка

 

 

В СПИЛАЛЬНОЙ МОДЕЛИ ДЕЛАЕТЬСЯ СПИРАЛЬНЫЙ УКЛОН АНАЛИЗ И ПРОЕКТ

На этих этапах реализ тех решений проверяеться путем создания портотипов

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

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

Переход осуществяеться в соответствии плана даже если не вся запланированная работа закончина. план составляется полученых проэктов. Функциональность наращиваеться постепенно. 1 результат получается быстро сложность увеличиваеться постепенно такая модель удобна с низу в верх меньше моделиров на этапе.

Варианты спиральной модели являються

1.быстрое протипирование

2.инкрементная разработка

3.модели ЖЦ ASDH

(Astro Software Devolpmeht House)

Наибольший интерес представ след модели ЖЦ.

1.методика Orale

CMD (Custrom Devolopent Methol)

2.eXtreme Programming

3.RUP (Rational Uniled Process)

4RAD (rapid Application Devolopent)

 

Быстрое протетепирование……………………………………………………..

Портотип это макет или упращ версия будущего продукта для подтверждения его упращения.

Это не полная функциональность и,или не эффективность (портотип разраб на не эффективном языке)

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

 

Инкрементная разработка. это полностью работаспособная версия поступ в эксплуатацию. Это удобно для больших систем. Например

-ПО бортовой системы шатла. -7 енкриментов за 10 лет. –по этому принцепу работают программисты майкростфт (Micro Solutions Framework)

Рассмотрим спиральный вариант MSF

 

выпуск

 

анализ концепция

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

 

спецификация

разработка

Основные понятие SML

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

3)проектные (внутренние, функциональные) спецификации включают в себя

-проектные документы

-модели

-прототипы

-программа и методика испытаний

-сетевой график работы

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

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