Ильин А.А., Евсюков В.В., Ильин Р.А. Информатика

Подождите немного. Документ загружается.

–

261

–

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

• снятие с эксплуатации.

Этап формирования требований к ПО является одним из важнейших, так

как допущенные просчеты могут существенным образом сказаться на конечном

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

шагов:

• планирование работ: определение целей разработки, предварительную

экономическую оценку проекта, построение плана–графика работ и

др.;

• проведение обследования деятельности автоматизируемого объекта:

определение структуры организации и ее целевых функций, анализ

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

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

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

• построение модели “AS–IS” (“как есть”), отражающей существующие

на момент обследования особенности функционирования организации и

выявление “

узких мест”, а также модели “ТО–ВЕ” (“как должно быть”),

отражающей представления о новых технологиях работы организации. Переход

от модели “AS–IS” к модели “ТО–ВЕ” может быть выполнен как на основе

совершенствования существующих технологий (инжиниринг бизнес-

процессов), так и через радикальное изменение технологий и

перепроектирование бизнес-процессов (реинжиниринг бизнес-процессов);

• собственно

формирование требований к ПО, предполагающее

определение следующих характеристик для каждого комплекта программного

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

производительности и среды функционирования компонентов); внешних

интерфейсов; спецификаций надежности и безопасности; требований к формам

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

документации; требований к эксплуатации и сопровождению и др.

Предполагается, что степень выполнения большинства

требований к ПО

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

ПО.

Этап проектирования и тестирования охватывает работы по созданию ПО

и его компонентов в соответствии с заданными требованиями, включая

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

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

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

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

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

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

конкретные технологии и поддерживающие их методики, стандарты и

–

262

–

инструментальные средства, которые обеспечивают выполнение процессов

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

Процесс разработки включает в себя следующие действия:

• проектирование архитектуры ПО, определяющей на высоком уровне

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

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

баз данных, подготовка предварительной версии пользовательской

документации, разработка и документирование предварительных

требований к

тестам и планам объединения (интеграции) различных компонент

программного обеспечения в единое целое;

• детальное проектирование ПО: описание отдельных компонентов

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

уровне, достаточном для последующего самостоятельного кодирования

(написания программных кодов) и тестирования; разработку и

документирование детального проекта базы данных; разработку и

документирование требований к тестам и плана тестирования компонент ПО;

обновление плана интеграции ПО;

• кодирование и тестирование ПО: разработка (кодирование) и

документирование каждого компонента ПО и базы данных, а также всех

тестовых процедур и данных для всестороннего тестирования каждого

компонента ПО; собственно тестирование каждого компонента ПО на

соответствие предъявляемым требованиям

с документированием результатов;

обновление при необходимости пользовательской документации; обновление

плана интеграции ПО;

• интеграция ПО, предполагающая сборку разработанных компонентов

в соответствии с планом интеграции в более крупные компоненты и

тестирование сформированных агрегированных компонентов. Интеграция

компонент ПО в единое целое и тестирование системы в целом;

• квалификационное тестирование. Целью этой операции является

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

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

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

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

проверяется полнота и адекватность технической и пользовательской

документации.

Этап

ввода в действие предполагает установку разработанного

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

осуществляется полномасштабная проверка работоспособности ПО и баз

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

определенного периода времени параллельно поддерживается

–

263

–

работоспособность двух систем: используемого у заказчика ПО (старой

системы) и внедряемого ПО (новой системы).

По результатам квалификационного тестирования ПО на оборудовании

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

требованиям на проектирование осуществляется окончательная передача

разработанного программного обеспечения заказчику с формальным

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

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

требованиям на

проектирование разработчик осуществляет доработку ПО (как правило, без

дополнительного финансирования со стороны заказчика). На этапе ввода в

действие разработчик осуществляет подготовку персонала заказчика к

самостоятельной эксплуатации установленного ПО.

Этап

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

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

с эксплуатации (по решению заказчика). Эксплуатация осуществляется в

условиях определенной среды в соответствии с пользовательской

документацией. В ней должны быть определены также процедуры локализации

и разрешения проблем, возникающих в процессе эксплуатации. При получении

от

разработчика очередной редакции программного продукта обязательно

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

оборудовании заказчика) и при наличии положительных результатов

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

процессе эксплуатации ПО заказчик информирует об этом разработчика с

целью их скорейшего устранения.

Под сопровождением понимается внесение изменений в ПО в целях

исправления ошибок

, повышения производительности или адаптации к

изменившимся условиям работы или требованиям. Модификация ПО

предполагает внесение необходимых изменений в компоненты ПО в

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

изменения также всесторонне тестируются, в документацию вносятся

необходимые корректировки, осуществляется тестирование на оборудовании

заказчика, результаты тестирования документируются, факт передачи

модифицированного ПО в эксплуатацию

также документируется. Схожие

действия выполняются при передаче разработанного ПО для эксплуатации в

другой среде (на другом оборудовании).

При проектировании прикладного программного обеспечения широко

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

спиральная (современная).

Для

каскадной модели характерен переход на следующий этап

проектирования только после полного завершения работы на предыдущем

этапе (возврат к предыдущим этапам не предусматривается). Каждый этап

–

264

–

заканчивается формированием конкретных результатов, которые служат в

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

результатам каждого этапа формируется соответствующий комплект

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

этапе (возможно и другой командой разработчиков) и для последующей

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

выполнения работ по этапу

определяется в соответствии со спецификацией

технического задания на разработку ПО (в рамках конкретного этапа). В целом

проектированию на основе каскадной модели свойственна логичность

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

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

результатов на каждом этапе.

Основным недостатком такого

подхода является большая длительность

периода проектирования, что во многих случаях не удовлетворяет заказчиков.

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

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

сформулировать требования к их разработке. Это объясняется как трудностями

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

детализации (со

стороны заказчика), так и возможными существенными

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

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

корректировка требований со стороны заказчика может осуществляться только

по завершению работ по очередному этапу (при условии, что они не

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

противном

случае необходимо перезаключение договора на разработку ПО).

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

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

спиральной модели жизненного цикла

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

является создание ПО по частям с широким использованием прототипов,

реализующих отдельные функции и внешние интерфейсы разрабатываемого

ПО. Каждая итерация (виток спирали) соответствует созданию очередной

версии ПО. В рамках каждой итерации уточняются цели и характеристики

объекта, оценивается качество полученных результатов и

планируется состав

работ по следующей итерации. При этом оцениваются риски превышения

сроков разработки и стоимости проекта, определяется целесообразность

выполнения еще одной итерации. Подобный подход с использованием

спиральной модели устраняет необходимость полного и точного

формулирования требований к системе на начальном этапе, так как они

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

разработчиков

с заказчиком в процессе реализации ряда итераций позволяет

выбрать (нащупать, уточнить) обоснованный вариант построения системы,

–

265

–

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

использования такого подхода является значительное сокращение сроков

разработки ПО при максимальном учете пожеланий заказчика,

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

задолго до получения завершающего результата имеет возможность видеть

работоспособные варианты ПО, отвечающие частичным наборам

предъявляемых к системе требований. На практике

при определении на

очередной итерации полного набора требований к системе часто

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

модели.

В 90-х годах при разработке прикладного ПО в рамках спиральной

модели широкое применение находит способ быстрой разработки приложений

– RAD. Его применение предполагает наличие трех составляющих:

• ряда групп разработчиков из нескольких специалистов

, способных

совместно проектировать отдельные подсистемы ПО;

• тщательно проработанного графика выполнения работ (обычно до 3

месяцев);

• тесного взаимодействия разработчиков с заказчиком с целью

своевременного получения дополнительных требований (сведений) со стороны

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

Предполагается, что разработчики имеют необходимый

профессиональный опыт в проектировании, программировании и тестировании

схожего по

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

В соответствии с подходом RAD основу жизненного цикла продукта

составляют три этапа:

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

• проектирование (собственно разработка);

• внедрение.

На первом этапе определяются:

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

приоритетные функции, требующие первоочередной проработки;

• информационные потребности к будущей системе (здесь

существенную

помощь заказчикам оказывают разработчики);

• временные рамки каждой из итераций и анализируется возможность

реализации проекта в целом (при заданном объеме финансирования, на

указанных заказчиком аппаратных средствах и др.);

• разрабатываются предварительные (самые общие) модели ПО.

На втором этапе выполняются следующие действия:

• детально рассматриваются все процессы системы, для каждого из

них

определяется возможный прототип (экранная форма, отчет, взаимодействие в

режиме диалога и др.);

–

266

–

• осуществляется группировка процессов с целью выделения ряда слабо

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

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

• определяются интересы взаимодействия между автономно

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

(файлы, документы, экранные формы и др.);

• определяются процедуры, реализующие разграничение

доступа к

данным;

• на основе сформированных моделей системы и требований

нефункционального характера (по производительности, надежности и др.)

осуществляется непосредственное кодирование (программирование) и

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

исходным требованиям;

• по мере завершения работ отдельными группами разработчиков их

результаты интегрируются и выполняется тестирование реализованной части

приложения в целом (процесс

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

работы последней группой разработчиков);

• анализируются и реализуются возможности повышения

производительности системы в целом;

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

Результатом данного этапа является полностью готовая система,

удовлетворяющая всем согласованным требованиям. Следует отметить

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

группами разработчиков с целью снятия проблем совместимости

данных при

интеграции подсистем в единую систему.

Этап внедрения предполагает обучение персонала заказчика, реализацию

комплекса мероприятий организационного характера для одновременной

эксплуатации двух систем (старой и новой).

Преимущества подхода RAD ощутимы при разработке проектов средней

сложности в рамках хорошо отлаженной среды разработки с многократным

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

выполнение

проектов.

Технология проектирования ПО определяется как совокупность

технологических операций проектирования в их последовательности и

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

Контекст технологической операции образуют:

• исходные данные в стандартном представлении (документы,

результаты предыдущих операций и др.);

• методологические материалы, инструкции, нормативы и стандарты,

критерии оценки результатов;

• исполнители;

–

267

–

• инструментальные средства;

• результаты в стандартном исполнении.

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

информационных систем должны обеспечивать:

• соответствие международному стандарту ISO/IEC 12207;

• возможность декомпозиции проекта на составные части (подсистемы,

разрабатываемые параллельно небольшими группами исполнителей с

последующей интеграцией результатов разработки в единое целое);

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

реализации

(СУБД, ОС, языков и систем программирования);

• поддержка проектирования комплексом согласованных CASE-

средств, обеспечивающих автоматизацию процессов на всех этапах жизненного

цикла ПО.

Электронные технологии вместе с поддерживающими их CASE-

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

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

для экономической информационной системы предполагает выполнение всеми

участниками проекта (

что особенно актуально для проектом с большим числом

группы разработчиков) общепринятых стандартов, основными из которых

являются:

•

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

моделей (диаграмм) на каждой стадии проектирования и степень их

детализации; правила отражения проектных решений на диаграммах;

требования к конфигурации рабочих мест проектировщиков, включая

настройки ОС, CASE-средств и др.; процедуры обеспечения совместной работы

над проектом (регламент обмена проектной информацией, правила интеграции

результатов, правила анализа проектных решений на непротиворечивость

др.);

•

стандарт оформления проектной документации, определяющий:

комплектность, состав и структуру документации на каждой стадии

проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127-94 “Системы

обработки информации. Документация пользователя и информация на упаковке

потребительских программных пакетов”); требования к оформлению

документации (включая требования к содержанию разделов, подразделов,

пунктов и др.); правила подготовки, рассмотрения, согласования и утверждения

документации с

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

настройкам средств автоматизации, обеспечивающих подготовку документации

(в том числе, CASE-средств, издательских систем и др.);

•

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

регламентирующий: правила оформления экранных форм (окон, элементов

управления и др.); правила использования клавиатуры и мыши; правила

–

268

–

обработки реакции пользователя; перечень вывозимых на экран стандартных

сообщений; правила для работы с системой подсказок (справочной системой).

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

ПО), стандарт ISO/IEC 12207 определяет также группы вспомогательных и

организационных процессов, в рамках модели жизненного цикла ПО.

Группа вспомогательных процессов, обеспечивающих выполнение

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

предусматривающий формализованное описание информации, формируемой в

течение жизненного цикла ПО; процесс управления конфигурацией,

ориентированный на применение административных и технических процедур

на всем протяжении жизненного цикла ПО; процесс обеспечения качества,

гарантирующий, что ПО и процесс его жизненного цикла соответствует

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

формальное доказательство правильности построения

ПО; процесс аттестации,

определяющий полноту соответствия заданных требований и созданного

программного продукта их конкретному функциональному назначению;

процесс совместной оценки, ориентированный на контроль планирования и

управления ресурсами, персоналом, аппаратурой и инструментальными

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

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

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

проверке действий другой стороны; процесс разрешения

проблем, предусматривающий анализ и решение проблем независимо от их

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

эксплуатации, сопровождения или других процессов.

Группа организационных процессов включает в себя: процесс

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

стороной при управлении своими процессам (

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

продукта, управление проектом в целом и конкретными задачами, включая

приобретение, поставку, разработку, эксплуатацию, сопровождение и др.);

процесс создания инфраструктуры, охватывающий выбор и поддержку

технологии, стандартов и инструментальных средств, выбор и установку

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

эксплуатации или сопровождения ПО; процесс усовершенствования,

ориентированный на повышение производительности

труда всех участвующих

в них специалистов за счет совершенствования используемой технологии,

методов управления, выбора инструментальных средств и обучения персонала;

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

последующее постоянное повышение квалификации персонала.

Создание

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

предполагает формирование:

–

269

–

• описания его применения, дающего общую характеристику продукта

с указанием среды его применения, требований к системному ПО (создающему

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

средств;

• руководства пользователя, включающего детальное описание

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

правило, руководство пользователя должно содержать необходимые сведения

для самостоятельного освоения

программного продукта конечным

пользователем;

• руководства программиста, определяющего особенности установки

(инсталляции) программного продукта и его внутренней структуры: состав и

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

качественной работы программного продукта.

Кроме того, во многих случаях создаются демоверсии и специальные

обучающие системы.

Важное значение для занимающейся разработкой ПО компании имеет

наличие у нее сертификата по стандарту качества ISO 2000 (международного

стандарта), гарантирующего, что владеющая данным сертификатом компания

сумеет выполнить программные проекты в срок и с высоким качеством.

Процесс сертификации предполагает приведение внутренней работы компании

в соответствие с жесткими требованиями стандарта ISO 2000, что требует

времени и значительных финансовых затрат (обучение проектировщиков и

вспомогательных служб,

отладка системы электронного документооборота и

др.). В то же время необходимо отметить, что получение крупного заказа на

проектирование, как правило, предполагает наличие у потенциального

разработчика сертификата качества ISO 2000.

6.3. CASE-СРЕДСТВА

В соответствии с международным стандартом под

CASE-средством

понимается программное средство, поддерживающее процессы жизненного

цикла ПО, включая анализ требований к системе, проектирование прикладного

ПО и баз данных, генерацию кода, тестирование, документирование,

обеспечение качества, управление конфигурацией ПО и управление проектом,

а также другие процессы. CASE-средства совместно с системным ПО и

техническими средствами образуют среду разработки ПО экономических

информационных систем.

Современный рынок CASE-средств насчитывает порядка трех сотен

различного рода программных систем, ориентированных к применению как на

персональных компьютерах, так и в сложных дорогостоящих вычислительных

системах с различными операционными системами.

–

270

–

Общепринятой является классификация CASE-средств по типам,

отражающая их функциональную ориентацию на те или иные процессы

жизненного цикла ПО. Она включает в себя следующие типы:

• средства анализа и проектирования, предназначенные для построения и

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

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

системных

требований и свойств, которыми система должна обладать, а также

создание проекта системы, удовлетворяющей этим требованиям и обладающей

соответствующими свойствами. Результатом их применения являются

спецификации компонентов системы и их интерфейсов, алгоритмов и структур

данных;

• средства проектирования баз данных, обеспечивающие моделирование

данных и генерацию схем баз данных (как правило, на структурированном

языке

запросов SQL) для наиболее распространенных СУБД;

• средства управления требованиями, обеспечивающие комплексную

поддержку разнородных требований к создаваемой системе;

• средства управления конфигурацией ПО, обеспечивающие

управляемость и контролируемость процессов разработки и сопровождения ПО;

• средства документирования, позволяющие автоматически извлекать

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

и включать ее в выходные

документы. При этом контролируются соответствие

документации проекту, взаимосвязь документов, обеспечивается их

своевременное обновление. Результирующая документация автоматически

формируется из множества источников, число которых не ограничено;

• средства тестирования, предназначенные для автоматического

тестирования приложений;

• средства управления проектом ПО, позволяющие оптимально

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

риски, оптимизировать использование имеющихся

ресурсов и избегать

конфликтных ситуаций, контролировать исполнение составленного плана,

анализировать фактические показатели и вносить своевременную коррекцию в

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

реализованных проектов;

• средства реверсного инжиринга, предназначенные для переноса

существующей системы ПО в новую среду. Они обеспечивают анализ

программных кодов и схем баз данных и

формирование на их основе различных

моделей и проектных спецификаций.

Для CASE - средств характерны следующие особенности:

• наличие эффективных графических средств для описания и

документирования системы, поддерживающих удобный интерфейс с

разработчиком;