Дзюбенко А.Л., Ильин А.А., Мишин П.Н. и др. Информационные технологии управления: Учебное пособие

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

111

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

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

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

тельности шагов:

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

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

и др.;

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

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

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

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

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

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

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

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

быть”), отражающей представления о новых технологиях работы органи-

зации. Переход от модели “AS–IS” к модели “ТО–ВЕ” может быть выпол-

нен как на основе совершенствования существующих технологий

(инжи-

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

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

процессов);

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

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

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

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

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

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

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

и др.

Предполагается

, что степень выполнения большинства требований к

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

ботанного ПО.

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

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

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

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

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

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

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

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

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

112

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

процессов жизненного цикла ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ление плана интеграции

ПО;

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

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

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

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

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

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

плана

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

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

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

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

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

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

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

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

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

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

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

тельской документации.

Этап

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

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

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

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

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

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

ПО (новой системы).

113

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

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

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

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

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

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

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

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

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

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

Этап

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

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

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

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

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

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

тации. При получении от разработчика очередной редакции программ-

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

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

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

При обнаружении ошибок в процессе эксплуатации ПО заказчик ин-

формирует об этом разработчика с целью их скорейшего устранения.

Под сопровождением понимается

внесение изменений в ПО в целях ис-

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

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

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

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

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

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

вании

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

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

Схожие действия выполняются при передаче разработанного ПО для

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

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

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

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

Для

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

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

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

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

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

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

114

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

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

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

Оценка качества выполнения работ по этапу определяется в соответст-

вии со спецификацией технического задания на разработку ПО (в рам-

ках конкретного этапа). В целом проектированию на основе

каскадной

модели свойственна логичность следования этапов, что позволяет точно

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

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

пе.

Основным недостатком такого подхода является большая длительность

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

чиков. С другой стороны, для

сложных систем на начальной стадии про-

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

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

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

высокой степенью детализации (со стороны заказчика), так и возмож-

ными существенными изменениями во внешней среде, способными по-

влиять на

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

рамках подхода с каскадной моделью корректировка требований со сто-

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

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

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

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

Возникающие в ходе проектирования

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

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

спиральной модели жизнен-

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

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

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

сы разрабатываемого ПО. Каждая итерация (виток спирали) соответствует

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

цели и характеристики объекта, оценивается

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

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

ниваются риски превышения сроков разработки и стоимости проекта, оп-

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

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

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

этапе, так как они уточняются

по мере выполнения проекта. Тесные взаи-

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

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

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

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

115

тельное сокращение сроков разработки ПО при максимальном учете по-

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

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

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

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

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

системе

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

менением каскадной модели.

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

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

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

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

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

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

до 3 месяцев);

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

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

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

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

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

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

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

составляют три

этапа:

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

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

• внедрение.

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

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

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

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

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

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

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

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

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

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

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

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

действие в режиме диалога и др.);

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

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

116

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

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

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

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

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

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

данным;

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

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

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

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

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

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

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

части приложения в целом (процесс повторяется многократно до сдачи ре-

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

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

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

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

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

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

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

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

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

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

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

для одновре-

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

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

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

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

сроках на выполнение проектов.

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

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

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

ния.

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

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

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

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

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

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

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

117

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

новными из которых являются:

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

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

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

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

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

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

интеграции результатов, правила анализа

проектных решений на непроти-

воречивость и др.);

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

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

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

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

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

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

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

вания и

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

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

чивающих подготовку документации (в том числе, CASE-средств, изда-

тельских систем и др.);

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

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

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

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

118

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

системой).

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

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

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

ла ПО.

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

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

преду-

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

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

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

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

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

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

ле формальное

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

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

созданного программного продукта их конкретному функциональному на-

значению; процесс совместной оценки, ориентированный на контроль

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

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

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

димой

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

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

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

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

или других процессов.

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

ления, состоящий из действий и задач,

которые могут выполняться любой

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

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

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

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

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

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

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

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

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

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

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

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

Создание

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

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

119

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

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

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

технических средств;

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

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

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

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

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

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

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

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

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

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

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

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

ет наличие у нее

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

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

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

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

работы компании в соответствие с жесткими требованиями стандарта ISO

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

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

системы электронно-

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

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

наличие у потенциального разработчика сертификата качества ISO 2000.

5.3. CASE-средства

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

CASE-средством

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

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

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

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

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

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

ПО эко-

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

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

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

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

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

120

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

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

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

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

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

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

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

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

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

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

системы и их

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

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

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

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

СУБД;

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

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

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

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

ПО;

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

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

разработки проекта, и включать ее в выходные документы. При этом

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

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

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

которых не ограничено;

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

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

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

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

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

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

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

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

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

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

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

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

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

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