Стандарты CDM, ISO-12207 и их характеристики.
Методика Oracle CDM возникла как развитие разработанной ранее версии Oracle CASE-Method. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения о простом приспособлении CDM к проектам, в которых используется другой подход, рекомендуемый для малых проектов и возможности быстрого прототипирования приложений. Особенность методики состоит в том, что она не предусматривает: включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным; дополнительное удаление задачи (и порождаемых ею документов), не предусмотренных той или иной моделью ЖЦ; изменение последовательности выполнения задач по сравнению с предложенной, тем более – по ходу процесса проектирования.Все модели ЖЦ ИС являются по сути каскадными; даже «облегченный подход», несмотря на понятную итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач. Эта методика в основном ориентирована на разработку программно-технической системы или создание информационной системы с базами данных в достаточно традиционном понимании.
Стандарт ISO-12207
Первая редакция международного стандарта ISO/IEC 12207 подготовлена в 1995 году. По определению, это – базовый стандарт процессов ЖЦ, ориентированный на различные виды ПО и типы проектов ИС, куда ПО входит как составляющая часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации программного обеспечения. Он охватывает жизненный цикл ПО от концептуализации идей до завершения ЖЦ. Все процессы, используемые во время разработки ЖЦ ПО, должны быть совместимы с процессами, используемыми с временем реализации ЖЦ ИС. Отсюда понятна целесообразность совместного использования стандартов на ИС и на ПО. Исходя из данного стандарта, следует, что информационная система – это объединение одного или более процессов ее разработки, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей. Модель жизненного цикла – структура, содержащая процессы; действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течении всей жизни системы, от определения требований до завершения ее использования. В отличие от Oracle CDM стандарт ISO12207 ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь). Он так же может быть в равной степени применен, когда обе стороны – из одной организации.
|
|
|
Жизненный цикл по ISO/IEC 12207, по сравнению с CDM, состоит из гораздо более крупных 5-и обобщенных процессов: приобретение, поставка, разработка, функционирование и сопровождение. Один такой процесс сравним со всеми процессами CDM вместе взятыми. «Динамический» характер стандарта определяется способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовывать любую модель ЖЦ.
|
|
|
При этом каждый процесс разделен на набор действий, каждое действие – на набор задач. Очень важное отличие состоит в том, что каждый процесс, действие или задача инициируется и выполняется по мере необходимости.
Выделены 5 основных, 8 вспомогательных и 4 организационных процессов в ISO/IEC 12207:
1. приобретение – определяет действия предприятия-покупателя, которое приобретает ИС, программный продукт или сервис ПО;
2. поставка – определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО;
3. разработка – определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт;
4. функционирование – определяет действия предприятия-оператора, которое обеспечивает обслуживание системы в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности;
|
|
|
5. сопровождение – определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия из вычислительной системы.
Кроме основных пяти процессов данный стандарт обуславливает еще восемь вспомогательных и четыре организационных процесса, которые поддерживают реализацию основных процессов, будучи неотъемлемой частью всего ЖЦ, и обеспечивают требуемое качество проекта. Вспомогательные процессы – это процессы, связанные с решением проблем документирования, управления конфигурацией, гарантирования качества. Процесс гарантирования качества использует результаты остальных вспомогательных процессов группы обеспечения качества, в которую входят: процесс верификации, процесс аттестации, процесс совместной оценки, процесс аудита. Организационные процессы – это процессы: управления, создания инфраструктуры, усовершенствования, обучения. К ним относится особый процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта. Под процессом усовершенствования здесь понимается не усовершенствование ИС или ПО, а улучшение самих процессов приобретения, разработки, гарантирования качества и т.п., реально осуществляемых в организации.
|
|
|
В отличие отГОСТ 34602, стандарт ISO/12207 принципиально не содержит конкретных методов, действий, тем более каких-либо заготовок решений или документации. Он описывает архитектуру процессов ЖЦ, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы; стандарт не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа задач принимаются лицом, использующим стандарт. Польза стандарта состоит в том, что он содержит наборы задач, характеристик качества, критериев оценки и др., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
1. определяется область применения разрабатываемой системы для определения к ней требований;
2. спецификация требований системы должна описывать: функции и возможности системы, бизнес-процессы, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования;
3. спецификация требований системы должна быть документирована.
По результатам анализа требований к ПО предусмотрено 10 классов характеристик качества, которые используются при гарантировании качества. При этом разработчик должен установить и документировать следующие требования к программному обеспечению:
1) функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых программное обеспечение должно быть выполнено;
2) внешние связи с элементами программного обеспечения;
3) требования квалификации разработчиков и пользователей;
4) спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
5) спецификации защищенности, включая спецификации, связанные с компрометацией точности информации;
6) человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и предметным областям, которые являются чувствительными к ошибкам человека и обучению;
7) определение данных и требований базы данных;
8) установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
9) документация пользователя;
10) требования сервиса пользователя.
Очень важно, что эти и аналогичные требования хорошо корреспондируются с характеристиками ИС, предусмотренные в ГОСТ34 по видам обеспечения системы.
Стандарт не предписывает конкретную модель ЖЦ или метод разработки, но определяет, что стороны-участники использования стандарта ответственны за: выбор модели ЖЦ для проекта, адаптацию процессов и задач стандарта к этой модели, выбор и применение методов разработки, выполнение действий и задач, приемлемых для проекта.
Дата добавления: 2018-02-15; просмотров: 1679; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!