Для поиска темы - пользуйтесь СИСТЕМОЙ ПОИСКА


Стоимость дипломной работы


Home Для студента... Стандарты и методики

Стандарты и методики
загрузка...
Рейтинг пользователей: / 0
ХудшийЛучший 

Лекция 6

Тема: Стандарты и методики

1. Назначение и виды стандартов
Одним из важных условий эффективного использования информационных тех¬нологий является внедрение корпоративных стандартов. Корпоративные стандарты представляет собой соглашение о единых правилах организации технологии или управления. При этом за основу корпоративных могут приниматься отраслевые, национальные и даже международные стан-дарты.
Однако высокая динамика развития информационных технологий приводит к быс¬трому ус-тареванию существующих стандартов и методик разработки информаци¬онных систем. Так, на-пример, в связи со значительным прогрессом в области программного обеспечения и средств вычислительной техники наблюдается рост размеров и сложности информационных систем. При этом существенно меняются требования как к основным функциям и сервисным возможностям систем, так и к динамике изменения этих функций. В этих условиях применение классиче¬ских способов разработки и обеспечения качества информационных систем ста¬новиться малоэффек-тивным и не приводит к уровню качества, адекватному реаль¬ным требованиям.
Полезны в этом отношении стандарты открытых систем (в первую очередь стан¬дарты на интерфейсы различных видов, включая лингвистические, и на протоко¬лы взаимодействия). Од-нако разработка систем в новых условиях требует также новых методов проектирования и новой организации проектных работ. Проекти¬рование и методическая поддержка организации разра-ботки информационных систем (включая программное обеспечение (ПО), и базы данных (БД)) традици¬онно поддерживаются многими стандартами и фирменными методиками.
Вместе с тем известно, что требуется адаптивное планирование разработки, в том числе в динамике процесса ее выполнения. Одним из способов адаптивного проектирова¬ния является разработка и применение профилей жизненного цикла информаци¬онных систем и программного обеспечения. Корпоративные стандарты образуют целостную систему, которая включает три вида стандартов:
  стандарты на продукты и услуги;
  стандарты на процессы и технологии;
  стандарты на формы коллективной деятельности, или управленческие стан-дарты.
Существующие на сегодняшний день стандарты можно несколько условно разде¬лить на несколько групп по следующим признакам.
1. По предмету стандартизации. К этой группе можно отнести функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования ин¬формационных систем и про-граммного обеспечения.
2. По утверждающей организации. Здесь можно выделить официальные между-на¬родные, официальные национальные или национальные ведомственные стандар¬ты (на-пример, ГОСТы, ANSI, IDEF0/1), стандарты международных консорциу¬мов и комитетов по стандартизации (например, консорциума OMG), стандарты «де-факто» — официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программиро-вания С), фирменные стандарты (например, Microsoft ODBC);
3. По методическому источнику. К этой группе относятся различного рода мето¬дические материалы ведущих фирм-разработчиков программного обеспечения, фирм-консультантов, научных центров, консорциумов по стандартизации.
Необходимо иметь в виду, что, хотя это и не очевидно, в каждую из указанных выше групп и подгрупп входят стандарты, существенно различающиеся по степени обяза¬тельности для различных организаций; конкретности и детализации содержащихся требований; откры-тости и гибкости, а также адаптируемости к конкретным условиям.
Ниже мы рассмотрим следующие стандарты и методики, касающиеся организа¬ции жизненного цикла информационных систем и программного обеспечения:
 методика Oracle CDM (Custom Development Method) no разработке приклад¬ных информационных систем под заказ;
 международный стандарт IS0/1 ЕС 12207:1995-08-01 на организацию жизнен¬ного цикла продуктов программного обеспечения;
 отечественный комплекс стандартов ГОСТ 34.
Поскольку рассматриваемые стандарты представляют собой весьма объемные до¬кументы, изложенные на десятках и даже сотнях страниц, то мы рассмотрим их лишь на уровне общей структуры и основных особенностей.

2. Методика Oracle CDM
Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разра-ботка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентирован¬ных на интенсивное использо-вание баз данных. Методика Oracle CDM является развитием давно разработанной версии Oracle С ASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях — Designer/2000).
Основу CASE-технологии и инструментальной среды фирмы ORACLE состав¬ляют:
 методология структурного нисходящего проектирования, при которой разра¬ботка прикладной системы представляется в виде последовательности четко определенных этапов;
 поддержка всех этапов жизненного цикла прикладной системы, начиная с са¬мых общих описаний предметной области до получения и сопровождения готового программного продукта;
 ориентация на реализацию приложений в архитектуре клиент-сервер с исполь¬зованием всех особенностей современных серверов баз данных, включая дек¬ларативные ограничения целостности, хранимые процедуры, триггеры баз дан¬ных, и с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя;
 наличие централизованной базы данных, репозитария, для хранения специфи¬каций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;
 возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение про¬екта системы и управление одновременным доступом к нему всех участни¬ков разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от дру¬гих;
 автоматизация последовательного перехода от одного этапа разработки к сле¬дующему. Для этого предусмотрены специальные утилиты, с помощью кото¬рых можно по спецификациям концептуального уровня (модели предметной области) автоматически получать первоначальный вариант спецификации уровня проектирования (описание структуры базы данных и состава про¬граммных модулей), чтобы на его основе после всех необходимых уточне¬ний и дополнений автоматически генерировать готовые к выполнению про¬граммы;
 автоматизация различных стандартных действий по проектированию и реали¬зации приложения: предусматривается генерация многочисленных отчетов по содержимому репозитария, обеспечивающих полное документирование теку¬щей версии системы на всех этапах ее разработки; с помощью специальных про¬цедур предоставляется возможность проверки спецификаций на полноту и не¬противоречивость.

2.1 Общая структура
Жизненный цикл формируется из определенных этапов (фаз) проекта и процес¬сов, каждый из которых выполняется в течение нескольких этапов.
Методика Oracle CDM определяет следующие фазы жизненного цикла информа¬ционной системы:
 стратегия;
 анализ (формулирование детальных требований к прикладной системе);
 проектирование (преобразование требований в детальные спецификации сис¬темы);
 реализация (написание и тестирование приложений);
 внедрение (установка новой прикладной системы, подготовка к началу эксплуа¬тации);
 эксплуатация (поддержка приложения и слежение за ним, планирование буду¬щих функциональных расширений).
Первый этап связан с моделированием и анализом процессов, описывающих дея¬тельность организации, технологические особенности работы. Целью является по¬строение моделей сущест-вующих процессов, выявление их недостатков и возмож¬ных источников усовершенствования. Этот этап не является обязательным в случае, когда существующая технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорга-низации.
Более точным названием первого этапа, вероятно, было бы «Определение требований».
На втором этапе разрабатываются детальные концептуальные модели предметной области, описывающие информационные потребности организации, особенности функционирования и т. п. Результатом являются модели двух типов:
 информационные, отражающие структуру и общие закономерности предмет¬ной области;
 функциональные, описывающие особенности решаемых задач. На третьей стадии (этапе проектирования) на основании концептуальных моде¬лей вырабатываются технические спецификации будущей прикладной системы — определяются структура и состав базы данных, специфицируется набор программ¬ных модулей. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит на основании данных кон¬цептуальных моделей.
На этапе реализации создаются программы, отвечающие всем требованиям проект¬ных спе-цификаций.
Использование генераторов приложений, входящих в состав DESIGNER/2000, позво¬ляет полностью автоматизировать этот этап, существенно сократить сроки разработки систе-мы и повысить ее качество и надежность.
Методика Oracle CDM выделяет следующие процессы, протекающие на протяже¬нии жизненного цикла информационной системы:
 определение производственных требований;
 исследование существующих систем;
 определение технической архитектуры;
 проектирование и построение базы данных; Q проектирование и реализация модулей;
 конвертирование данных;
 документирование;
 тестирование;
 обучение;
 переход к новой системе;
 поддержка и сопровождение.
Процессы состоят из последовательностей задач, задачи разных процессов взаи¬мосвязаны с помощью явных ссылок.

2.2 Особенности методики Oracle CDM
Отметим основные особенности методики Oracle CDM, определяющие область ее применения и присущие ей ограничения.
1. Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:
2. Методика не предусматривает включение дополнительных задач, которые не ого-ворены в CDM, и их привязку к остальным. Также исключено удаление за¬дачи (и порождае-мых ею документов), не предусмотренное ни одной из трех моделей жизненного цикла, и изменение последовательности выполнения за¬дач по сравнению с предложенной.
3. Все модели жизненного цикла являются по сути каскадными. Даже «облегчен¬ный подход», несмотря на итерационность выполнения действий по прототипированию, сохраня-ет общий последовательный и детерминированный поря¬док выполнения задач.
4. Методика не является обязательной, но может считаться фирменным стандар¬том. При формальном применении степень обязательности полностью соответ¬ствует ограничени-ям возможностей адаптации.
5. Прикладная система рассматривается в основном как программно-техничес¬кая сис-тема — например, возможность выполнения организационно-структур¬ных преобразований, практически всегда происходящих при переходе к новой информационной системе, в этой методике отсутствуют.
6. CDM теснейшим образом опирается на использование инструментария Oracle, не-смотря на утверждения о простом приспособлении CDM к проектам, в кото¬рых используется другой комплект инструментальных средств.
7. Методика Oracle CDM представляет собой вполне конкретный материал, дета¬лизированный до уровня заготовок проектных документов, рассчитанных на прямое исполь-зование в проектах информационных систем с опорой на инст¬рументальные средства и СУБД фирмы Oracle.

3. Международный стандарт ISO/IEC 12207: 1995-08-01

Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техничес¬ким комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».
По определению, ISO 12207 — базовый стандарт процессов жизненного цикла ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, в которых ПО является одной из составных частей. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает жиз¬ненный цикл от концептуализа-ции идей до завершения проекта.
Целесообразность совместного использования стандартов на информационные систе-мы и на ПО обусловливается одним из положений ISO 12207, согласно кото¬рому процессы, используемые во время жизненного цикла ПО, должны быть со¬вместимы с процессами, ис-пользуемыми во время жизненного цикла автоматизи¬рованной системы.
Согласно ISO 12207, система — это объединение одного или нескольких процес¬сов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 в равной степени ориентирован на орга¬низацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользо-вателя); он может быть применен и в том случае, когда обе стороны — из од¬ной организа-ции.

3.1 Общая структура
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жиз¬ненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов: приобретение, поставка, разработ¬ка и т. п. Несколько утрируя, мож-но сказать, что один процесс ISO 12207 сопоста¬вим со всеми процессами Oracle CDM вместе взятыми.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое дей-ствие — на ряд задач.
Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируются и выполняются другим процессом по мере необ-ходимости, причем нет заранее определенных последователь¬ностей (естественно, при сохране-нии логики связей по исходным сведениям за¬дач и т. п.).
Основные и вспомогательные процессы жизненного цикла.
В стандарте ISO 12207 описаны пять основных процессов жизненного цикла про¬граммного обеспечения:
 процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу про¬граммного обеспечения;
 процесс поставки определяет действия предприятия-поставщика, которое снаб¬жает покупателя системой, программным продуктом или службой программ¬ного обеспечения;
 процесс разработки определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт;
 процесс функционирования определяет действия предприятия-оператора, кото¬рое обеспечивает обслуживание системы в целом (а не только программного обеспечения) в процессе ее функционирования в интересах пользователей. В от¬личие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рас¬сматриваемых стандартах), определяются действия оператора по консультиро¬ванию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности;
 процесс сопровождения определяет действия персонала, обеспечивающего со¬провождение программного продукта, то есть управление модификациями про¬граммного продукта, поддержку его текущего состояния и функциональной пригодности; сюда же относятся установка программного изделия на вычисли¬тельной системе и его удаление.
Кроме основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов, которые являются неотъемлемой частью всего жизненного цикла программного изделия и обеспечивают должное качество проекта программного обеспечения. К вспомогательным процессам относятся:
 процесс решения проблем;
 процесс документирования;
 процесс управления конфигурацией;
 процесс обеспечения качества;
 процесс верификации;
 процесс аттестации;
 процесс совместной оценки;
 процесс аудита.
В стандарте ISO 12207 также определяются четыре организационных процесса:
 процесс управления;
 процесс создания инфраструктуры;
 процесс усовершенствования;
 процесс обучения.
Под процессом усовершенствования в стандарте ISO 12207 понимается не усовер¬шенствование информационной системы или программного обеспечения, а улучше¬ние самих процессов приобретения, разработки, обеспечения качества и т. д., реаль¬но осуществ-ляемых в организации.
И наконец, в стандарте ISO 12207 определен один особый процесс, называемый процес-сом адаптации, который определяет основные действия, необходимые для адаптации этого стан-дарта к условиям конкретного проекта.

3.2 Особенности стандарта ISO 12207
Все сказанное выше позволяет сформулировать следующие особенности стандар¬та ISO 12207.
1. Стандарт ISO 12207 имеет динамический характер, обусловленный способом оп-ределения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой харак¬тер позволяет реализовать любую мо-дель жизненного цикла.
2. Согласно стандарту ISO 12207, модель жизненного цикла — это структура, со-держа¬щая процессы, действия и задачи, которые осуществляются в ходе разработки, функ¬ционирования и сопровождения программного продукта в течение всей жизни систе¬мы, от определения требований до завершения ее использования.
3. Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Мно¬жество процессов и задач сконструировано так, что возможна их адаптация в соответствии с кон-кретными проектами информационных систем. Эта адапта¬ция сводится к исключению процес-сов, видов деятельности и задач, неприме¬нимых в конкретном проекте.
4. Согласно ISO 12207, добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Причем «контракт» по¬нимается в самом широком смысле — от юридически оформленного документа до нефор-мального соглашения. Это соглашение может быть определено даже единствен¬ной стороной — как задача, поставленная самому себе.
5. Стандарт принципиально не содержит описания конкретных методов действий, а тем более — заготовок решений или документации. Он лишь описывает архитектуру процессов жизненного цикла программного обеспечения, но не конк¬ретизирует в деталях, как реализо-вывать или выполнять услуги и задачи, вклю¬ченные в процессы. Данный стандарт не пред-писывает имена, форматы или точное содержание получаемой документации. Решения тако-го типа принима¬ются сторонами, использующими стандарт.
6. Обеспечение качества разными процессами выполняется с разной предусмот¬ренной степенью организационной независимости контролирующей деятель¬ности вплоть до обязательных требований к полной независимости проверяю¬щего персонала от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их прове¬рок на соответствие потребностям приобретения.
7. Степень обязательности рассматриваемого стандарта следующая: после ре¬шения организации о применении ISO 12207 в качестве условия торговых от¬ношений явля-ется ее ответственность за указание минимального набора тре¬буемых процессов и задач, ко-торые обеспечивают согласованность с этим стандартом.
8. Стандарт содержит предельно мало описаний, направленных на проектирова¬ние базы данных. Это можно считать оправданным, так как разные системы и разные при-кладные комплексы программного обеспечения могут не только использовать весьма специ-фические типы баз данных, но и вообще не исполь¬зовать базу данных.
Ценность стандарта ISO 12207 в том, что он содержит наборы задач, характерис¬тик качества, критериев оценки и т. п., дающие всесторонний охват проектных си¬туаций. На-пример, при выполнении анализа требований к системе предусматри¬вается, что:
 рассматривается область применения системы для определения требований, предъявляемых к системе;
 спецификация требований системы должна описывать: функции и возможнос¬ти системы, области применения системы, организационные требования и тре¬бования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограни¬чения и квалификационные требования.
Далее, при выполнении анализа требований к программному обеспечению пре¬дусмотрено 11 классов характеристик качества, которые используются позже при обеспече-нии качества.
При этом разработчик должен установить и документировать в виде требований к программному обеспечению следующие спецификации и характеристики:
 функциональные и возможные спецификации, включая исполнение, физичес¬кие характеристики и условия среды эксплуатации, при которых единица про¬граммного обеспечения должна быть выполнена;
 внешние связи (интерфейсы) с единицей программного обеспечения;
 требования квалификации;
 спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и веро¬ятностью травмы персонала;
 спецификации защищенности, включая спецификации, связанные с компро¬метацией точности информации;
 человеческие факторы спецификаций по инженерной психологии (эргономи¬ке), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в кон¬центрированном человеческом внимании, которые являются чувствительны¬ми к ошибкам человека и обучению;
 определение данных и требований к базе данных;
 установочные и приемочные требования поставляемого программного продук¬та в местах функционирования и сопровождения (эксплуатации);
 документацию пользователя;
 работа пользователя и требования выполнения;
 требования сервиса пользователя.
Согласно стандарту ISO 12207, требование квалификации — это набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетво¬ряющий ус-ловиям) его спецификациям и готовый для использования в целевой окру¬жающей среде.
Хотя стандарт не предписывает конкретной модели жизненного цикла или метода разработки, он определяет, что стороны-участники при использовании стандарта ответствен-ны за следующее:
 выбор модели жизненного цикла для разрабатываемого проекта;
 адаптацию процессов и задач стандарта к этой модели;
 выбор и применение методов разработки программного обеспечения;
 выполнение действий и задач, подходящих для проекта программного обеспе¬чения.


 
загрузка...

Добавить комментарий


Защитный код
Обновить