Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Перечислить и охарактеризовать этапы развития АИС

Информационное обеспечение (ИО) АИС

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

Информация есть сообщение новых, ранее не известных сведений.

Информационное обеспечение (ИО) - предоставление информационных ресурсов в распоряжение какого-либо объекта или субъекта.

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

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

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

ИО автоматизированных информационных систем состоит из внемашинного и внутримашинного ИО.

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

Классификация - система распределения объектов по классам в соответствии с определенным признаком (основание классификации). Объекты необходимо классифицировать для:

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

-для разработки правил, алгоритмов обработки информации.

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

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

При классификации нужно соблюдать требования полнота охвата; однозначность реквизитов; возможность включения новых объектов.

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

Существует две системы классификации объектов: иерархическая и фасетная.

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

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

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

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

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

 

 

08.12.2008

Основные стадии создания АИС

Структурная схема терминов

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

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

Этапы разработки и внедрения АИС:

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

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

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

4. Составление концептуального проекта, в который помимо всего прочего отражает общая схема создаваемой системы, основные цели, которые должны быть достигнуты при реализации этой системы, перечень подсистем задач АРМа, основные связи между ними, структуры БД и БЗ; формирование графика работ по реализации или проекта системы. (если создается крупная система для крупного предприятия, то результаты последних 10 - 12 лет говорят о том, что данная работа до конца никогда не доводится: - очень большой и сложный объем работы, - очень высокая скорость изменения и технологий и ПО, - длительный срок обработки крупных систем должен учитывать все протекающие изменения на предприятии на этом длинном отрезке времени)

5. Составление полного экономического обоснования. (Срок реализации 2-4 недели.)

6. Реализация системы. (очень объемный и может составить 75-85% всего объема работ и, как правило, это связанно с модернизацией, которая вызвана ошибками в проектировании, неправильной оценкой предстоящих работ, текущими изменениями на предприятии. Длительность: 2-4,5 года для крупной системы.)

Примечание

Этапы 4 и 5 частично могут входить в ТЗ. Этап 6 может быть разбит на:

1. Этап проектирования и макетирования системы.

2. Внедрения и модернизация системы.

3. Этап эксплуатации.

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

· проектирование системы по черновому варианту (как макет) и сразу внедряется.

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

· автоматизация проектных работ.

Для небольших предприятий и организаций срок создания может быть 0,5-2 года.

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

Техническое задание должно состоять из следующих разделов:

1. Наименование;

2. Основание для создания;

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

4. Требования к АИС; (требования к системе в целом, требования к видам обеспечения)

5. Состав, содержание, ограничение работ по подготовке объекта к вводу АИС в действие;

6. Показатели эффективности АИС;

7. Порядок контроля и приемки АИС;

8. Источники разработки.

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

Этап составления общей схемы (проекта АИС)

При описании схемы АИС необходимо сделать следующее:

1. Спроектировать экранные и бумажные формы входных и выходных документов информации.

2. Разработать и описать структуры связей в системе, желательно стандартизировать интерфейс, меню, экранные формы и т.п.

3. Необходимо описать и сформулировать временные характеристики выполнения включенных в систему задач. Желательно стремится к режиму работы задач в режиме реального времени (т.е. отставание системы должно быть минимальным).

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


Этап обследования

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

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

Необходимо выяснить вопросы:

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

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

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

Этап обработки результатов обследования

Цель данного этапа получить комплексное представление о предприятии, объекте, получить формальное описание, уточнить перечень и количество задач и функций, выполняемых подразделениями, составить схему документооборота, составить схему информационных связей (модель), производственных структур, служб материально-технического снабжения, складов, составить схему движения материального потока. Если предприятие состоит из отдельных финансовых объектов составить схему финансового оборота. На этом же этапе можно подготовить предварительные схемы информационных связей для ограниченного количества финансовых задач (бухгалтерский учет, движение материальных средств, планирование производства и т.д.). Подготовить материалы для технико-экономического обоснования проекта. Выработать и подготовить положение по необходимым изменениям структуры объекта, по функциям подразделений, по ликвидации параллельных информационных потоков, т.е. надо подробно описать структуру организации предприятия и утвердить у руководства.

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

Главная задача систематизировать весь собранный материал и на его основании составить грубую схему АИС для исследуемого объекта. Формирование технического задания

Содержание работ по каждой стадии создания АИС

Структурная схема терминов

Организация предпроектного обследования

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

На этой стадии исследуются экономические показатели работы предприятия или учреждения, его организационная структура, информационные потоки, документооборот, методы учета и планирования. Обследование способствует определению основных параметров проектируемой системы и подразумевает сбор данных об объекте автоматизации в соответствии с конкретно выбранными методами. Важным этапом на этой стадии является анализ результатов обследования, который, учитывая характер собранных данных, их объем, и, как правило, жесткие сроки, целесообразно проводить с применением вычислительной техники. На этой стадии можно выделить два этапа, которые завершаются подготовкой и утверждением двух документов: ТЭО и технического задания (ТЗ).

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

ТЗ - документ, завершающий предпроектную стадию создания.

Организация работ на стадии технического проектирования

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

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

Организация работ на стадии рабочего проектирования

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

В состав технических инструкций, которые, как правило, являются типовыми, входят инструкции по: сбору, регистрации, контролю и передаче информации; переносу ее на машинные носители, ведению архива носителей документов; порядку передачи выходной, результатной информации. Должностные инструкции определяют права и обязанности производственного и управленческого персонала при эксплуатации АИС, регламентируют их действия в новых условиях производства.

Организация работ на стадии внедрения системы

Внедрение разработанной системы - это процесс постепенного перехода от существующей системы обработки данных к новой, автоматизированной.

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

· подготовка объекта к внедрению АИС

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

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

 

Перечислить и охарактеризовать этапы развития АИС

 

Тема 1.2. Жизненный цикл АИС и его этапы

Жизненный цикл (ЖЦ) - одно из базовых понятий методологии проектирования ИС. Это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ, является международный стандарт ISO/IEC (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

Структура ЖЦ по стандарту ISO/IEC базируется на трех группах процессов:

· основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, аттестация, аудит, решение проблем);

· организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение).

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

Обеспечение качества проекта - верификация, тестирование ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки требованиям данного этапа. Для этого проводится тестирование.

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

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

Наибольшее распространение получили две основные модели ЖЦ:

· каскадная модель (70-85 гг.);

· спиральная модель (86-90 гг.).

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

Положительные стороны применения каскадного подхода:

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

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

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

Рисунок 1.2.1. Схема каскадного подхода

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

Рисунок 1.2.2. Реальный процесс создания ИС на базе каскадной модели

Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model).

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

В спиральной модели ЖЦ (рис. 1.2.3), делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.

Рисунок 1.2.3. Спиральная модель ЖЦ

 

Каждый виток спирали соответствует созданию нового фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также "Продолжающимся проектированием". Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", rapid prototyping approach или "fast-track".

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

Основы методологии проектирования АС на основе CASE-технологий (Computer Aided Software Engineering)

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

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

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

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

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

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

Известно несколько моделей жизненного цикла программного обеспечения. Под моделью жизненного цикла ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении всего цикла. Модель ЖЦ зависит от специфики АС и специфики условий, в которых система создается и функционирует. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадный способ и спиральная модель. Каскадная модель применяется, как правило, для разработки однородных АС, представляющих собой единое целое. Ее основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Преимущества применения каскадного способа заключаются в следующем: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении АС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные расчетные системы, системы реального времени и др. В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания АС никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапами уточнении или пересмотре ранее принятых решений.

Такую трансформацию каскадной схемы разработки АС можно рассматривать как "моделирование с промежуточным контролем". Межэтапные корректировки обеспечивают большую надежность каскадной модели, хотя и увеличивают весь период разработки. Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к АС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут вносить свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания АС пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. От перечисленных недостатков свободна спиральная модель разработки АС (рис. 1.2.3), в которой делается упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания автоматизированной системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям АС работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков АС. В рамках спиральной модели ЖЦ широкое распространение получил один из подходов к разработке ПО, известный как методология быстрой разработки приложений RAD (Rapid Application Development). Эта методология включает в себя три составляющие: небольшая команда программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл ПО в соответствии с методологией RAD состоит из четырех фаз: анализа и планирования требований; проектирования; построения; внедрения.

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

На этапе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Устанавливаются требования разграничения доступа к данным. На этой же фазе происходит определение необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении АС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время (60 - 90 дней). С использованием CASE-средств проект АС распределяется между различными командами (делится функциональная модель). Результатом данного этапа должны быть: общая информаци<

Последнее изменение этой страницы: 2016-08-29

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...