Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Лекции - Проектирование информационных систем - файл 1.doc


Лекции - Проектирование информационных систем
скачать (523.5 kb.)

Доступные файлы (1):

1.doc524kb.16.11.2011 12:33скачать

содержание
Загрузка...

1.doc

1   2   3   4   5   6
Реклама MarketGid:
Загрузка...

Лекция 14

^ Общая структура профиля информационной системы

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

  • определение целей использования данного профиля;

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

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

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

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

  • информационные ссылки на все исходные документы.

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

  • профиль прикладного программного обеспечения;

  • профиль среды информационной системы;

  • профиль защиты информации в информационной системе;

  • профиль инструментальных средств, встроенных в информационную систему.



Профиль прикладного программного обеспечения

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


^ Профиль среды информационной системы

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

Стандарты интерфейсов приложений со средой (API) должны быть определены по функциональным областям профилей информационной системы. Декомпозиция структуры среды функционирования системы на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды информационной системы по функциональным областям эталонной модели OSE/RM:

  • область графического пользовательского интерфейса;

  • область реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);

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

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

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

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


^ Профиль защиты информации

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

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

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

  • функции управления данными, реализуемые СУБД;

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

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

  • функции администрирования средств безопасности.

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


^ Профиль инструментальных средств

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

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

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

  • управлением конфигурацией прикладного программного обеспечения, тиражированием версий;

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

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

  • настройкой пользовательских интерфейсов (генерацией экранных форм и отчетов);

  • ведением баз данных системы;

  • восстановлением работоспособности системы после сбоев и аварий.

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

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


Лекция 15

Фазы жизненного цикла в рамках методологии RAD

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

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

  • фаза проектирования;

  • фаза построения;

  • фаза внедрения.

Рассмотрим каждую из них более подробно.


Фаза анализа и планирования требований.

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

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

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

  • проводится описание информационных потребностей;

примечание

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

  • ограничивается масштаб проекта;

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

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

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


^ Фаза проектирования

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

примечание

Термин CASE (Computer Aided Software/System Engineering) используется в настоя­щее время в весьма широком смысле. Первоначальное значение термина CASE огра­ничивалось лишь вопросами автоматизации разработки программного обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. Те­перь под термином -CASE-средства» понимаются программные средства, поддер­живающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обес­печение качества, конфигурационное управление и управление проектом, а также другие процессы.

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

примечание

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

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

При необходимости для каждого элементарного процесса создается частичный про­тотип: экран, диалог или отчет (это позволяет устранить неясности или неоднознач­ности). Затем определяются требования разграничения доступа к данным. После детального рассмотрения процессов определяется количество функциональ­ных элементов разрабатываемой системы. Это позволяет разделить информаци­онную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора меся­цев). С использованием CASE-средств проект распределяется между различными командами — делится функциональная модель.

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

  • общая информационная модель системы;

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

  • точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

  • построенные прототипы экранов, диалогов и отчетов.

примечание

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


^ Фаза построения

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

На фазе построения также требуется участие пользователей системы, которые оце­нивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирова­ние системы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется пол­ный программный код, выполняется тестирование совместной работы данной ча­сти приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы, а именно:

  • определяется необходимость распределения данных;

  • производится анализ использования данных;

  • производится физическое проектирование базы данных;

  • определяются требования к аппаратным ресурсам;

  • определяются способы увеличения производительности;

  • завершается разработка документации проекта.

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


^ Фаза внедрения

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


примечание

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


^ Ограничения методологии RAD

Несмотря на все свои достоинства, методология RAD тем не менее (как, впрочем, и любая другая методология) не может претендовать на универсальность. Ее при­менение наиболее эффективно при выполнении сравнительно небольших систем, разрабатываемых для вполне определенного предприятия.

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

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

Лекция 16

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

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

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

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

  • стандарты на продукты и услуги;

  • стандарты на процессы и технологии;

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


Виды стандартов

Существующие на сегодняшний день стандарты можно несколько условно разде­лить на несколько групп по следующим признакам:

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

  • по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандар­ты (например, ГОСТы, ANSI, IDEFO/i), стандарты международных консорциу­мов и комитетов по стандартизации (например, консорциума OMG), стандарты «де-факто» — официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например, Microsoft ODBC);

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

примечание

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

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

  • методика Oracle CDM (Custom Development Method) no разработке прикладных информационных систем под заказ;

  • международный стандарт ISO/IEC 12207:1995-08-01 на организацию жизненного цикла продуктов программного обеспечения;

  • отечественный комплекс стандартов ГОСТ 34.

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


^ Методика Oracle CDM

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентирован­ных на интенсивное использование баз данных. Методика Oracle CDM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях - Designer/2000).

Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:

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

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

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

  • наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;

  • возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от дру­гих;

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

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


^ Общая структура

Жизненный цикл формируется из определенных этапов (фаз) проекта и процес­сов, каждый из которых выполняется в течение нескольких этапов, Методика Oracle CDM определяет следующие фазы жизненного цикла информа­ционной системы:

  • стратегия (определение требований);

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

  • проектирование (преобразование требований в детальные спецификации сис­темы);

  • реализация (написание и тестирование приложений);

  • внедрение (установка новой прикладной системы, подготовка к началу эксплуа­тации);

  • эксплуатация (поддержка приложения и слежение за ним, планирование буду­щих функциональных расширений).

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

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

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

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

примечание

Использование генераторов приложений, входящих в состав DESIGNER/2000, позво­ляет полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность.

Методика Oracle CDM выделяет следующие процессы, протекающие на протяже­нии жизненного цикла информационной системы;

  • определение производственных требований;

  • исследование существующих систем;

  • определение технической архитектуры;

  • проектирование и построение базы данных;

  • проектирование и реализация модулей;

  • конвертирование данных;

  • документирование;

  • тестирование;

  • обучение;

  • переход к новой системе;

  • поддержка и сопровождение.

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


Особенности методики Oracle CDM

Отметим основные особенности методики Oracle CDM, определяющие область ее

применения и присущие ей ограничения.

  • Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:

    • классическая — предусматривает все этапы;

    • быстрая разработка — ориентированна на использование инструментов

    • моделирования и программирования Oracle;

    • облегчённый подход — рекомендуется в случае малых проектов и возможно­сти быстро прототипировать приложения.

  • Методика не предусматривает включение дополнительных задач, которые не оговорены в CDM, и их привязку к остальным. Также исключено удаление за­дачи (и порождаемых ею документов), не предусмотренное пи одной из трех моделей жизненного цикла, и изменение последовательности выполнения за­дач по сравнению с предложенной.

  • Все модели жизненного цикла являются по сути каскадными. Даже «облегчен­ный подход», несмотря на итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный поря­док выполнения задач.

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

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

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

  • Методика Oracle CDM представляет собой вполне конкретный материал, дета­лизированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инст­рументальные средства и СУБД фирмы Oracle.



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

Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».

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

Согласно ISO 12207, система — это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.

примечание

В отличие от Oracle COM стандарт ISO 12207 в равной степени ориентирован на организацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользователя); он может быть применен и в том случае, когда обе стороны — из одной организации.

^ Общая структура

В стандарте 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 определен один особый процесс, называемый процессом адаптации, который определяет основные действия, необходимые для адаптации этого стандарта к условиям конкретного проекта.

^ Особенности стандарта ISO 12207

Все сказанное выше позволяет сформулировать следующие особенности стандарта ISO 12207.

  • Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовать любую модель жизненного цикла.

примечание

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

  • Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Эта адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.

примечание

Согласно ISO 12207, добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Причем «контракт» понимается в самом широком смысле — от юридически оформленного документа до неформального соглашения. Это соглашение может быть определено даже единственной стороной — как задача, поставленная самому себе.

  • Стандарт принципиально не содержит описания конкретных методов действий, а тем более — заготовок решений или документации. Он лишь описывает архитектуру процессов жизненного цикла программного обеспечения, но не конкретизирует в деталях, как реализовывать или выполнять услуги и задачи, включённые в процессы. Данный стандарт не предписывает имена, форматы или точное содержание получаемой документации. Решения такого типа принимаются сторонами, использующими стандарт.

  • Обеспечение качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяю­щею персонала от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие потребностям приобретения.

  • Степень обязательности рассматриваемого стандарта следующая: после решения организации о применении ISO 12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые обеспечивают согласованность с этим стандартом.

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

Ценность стандарта ISO 12207 в том, что он содержит наборы задач, характеристик качества, критериев оценки и т. п., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:

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

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

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

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

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

  • внешние связи (интерфейсы) с единицей программного обеспечения;

  • требования квалификации;

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

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

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

  • определение данных и требований к базе данных;

  • установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);

  • документацию пользователя;

  • работа пользователя и требования выполнения;

  • требования сервиса пользователя.

примечание

Согласно стандарту IS012207, требование квалификации — это набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.

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

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

  • адаптацию процессов и задач стандарта к этой модели;

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

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


1   2   3   4   5   6



Скачать файл (523.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru