Что такое программное обеспечение (software)

Вид материала

Документы

Содержание Стандарты ISO серии 9000 Стандарты SEI SW-CMM ISO15504.Структура эталонной модели Выделяются пять типов процессов Три группы и пять категорий. ENG: Инженерная. Вспомогательные процессы Организационные процессы ORG: Организационная ISO15504. Измерение «Зрелость» 1. Неполный процесс (Incomplete). 2. Выполняемый (Performed) 3. Управляемый (Managed) 4. Устоявшийся (Established) 6. Оптимизируемый (Optimizing) Факторы успеха аттестации процессов Схема проведения процесса аттестации. Выбор совместимой модели Пользовательские требования Системные требования ... Полное содержание

Подобный материал:

• Комплекс программ технического обслуживания (кпто); пакеты программ, дополняющие возможности, 357.82kb.
• Тема: «Графические редакторы». Цели урока, 407.46kb.
• Билет 12 Программное обеспечение компьютера, состав и структура. Назначение операционной, 57.76kb.
• Программное обеспечение ЭВМ, 209.59kb.
• Тест программное обеспечение компьютера вариант 1 Назовите виды программного обеспечения, 16.04kb.
• Аппаратное и программное обеспечение процесса обработки текста, 32.78kb.
• Программное обеспечение вычислительной системы, 824.71kb.
• Учебная программа (Syllabus) Дисциплина: Интерфейсы компьютерных систем (iks 3304), 321.31kb.
• Реферат по Информационной безопасности Тема: «Антивирусы», 711.1kb.
• Пк программный комплекс; по программное обеспечение; ппо прикладное программное обеспечение, 208.41kb.

Стандарты ISO серии 9000

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

Но основным преимуществом модели ISO является известность, распространенность, признание на мировом уровне. Сейчас стандарты ISO являются обязательным минимумом который должна иметь любая организация существующая на рынке. Но конечно же, вследствие своей универсальности, модель на основе стандартов ISO серии 9000 получилась достаточно "высокоуровневой"

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

Стандарты SEI SW-CMM

Очень интересный подход к улучшению внутренних процессов разработки программного обеспечения определен в модели SEI SW-CMM. В основу данной модели (также как и в основу стандартов ISO серии 9000) положена теория TQM. Теория TQM основывается на постепенном улучшении внутренних производственных процессов за счет множества небольших внедряемых в компании улучшений. Однако, модели ISO и CMM несколько различаются в своих подходах к построению самосовершенствующихся систем управления качеством и улучшению производственных процессов.

В отличие от модели ISO, где для того, чтобы соответствовать требованиям, необходимо продемонстрировать 100%-ное соответствие модели (и только оно позволяет компании самосовершенствоваться), в модели SEI SW-CMM предусмотрен поэтапный подход к построению системы совершенствования процессов. Для достижения этой цели разработчики стандарта СММ определили пять уровней, которые должна пройти организация для того, чтобы достичь основной цели - повышения эффективности функционирования процессов компании и, как следствие, улучшения качества результатов производственных процессов и разрабатываемого программного обеспечения.


42.

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

/*ISO15504 создавался на основе различных стандартов, в т.ч. и СММ, конкретно о сходствах нет инфы*/

43.(источник SEI_Lec_04_QA.doc страница 30)

ISO15504.Структура эталонной модели

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

- Измерения «Процесс», содержащего перечень аттестуемых процессов ЖЦ ПО.


- Измерения «Зрелость», содержащего приложимый к любому процессу набор атрибутов, представляющих собой измеримые характеристики, необходимые для управления процессом и повышения зрелости его выполнения.

/*совместимая модель стандарта не нашёл*/

44.(источник SEI_Lec_04_QA.doc страница 30)

ISO15504. Измерение «Процесс»

Измерение «Процесс» представляет расширенный и уточненный вариант процессов,

представленных в стандарте ISO 12207.

В продвинутой версии выделяются:

Тип процесса.

Выделяются пять типов процессов:

- три типа для первого уровня (базовый, расширенный и новый)

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

базовый — процесс из 12207;

расширенный — расширение процесса из 12207;

новый — процесс, не описанный в 12207;

составляющий — часть процесса из 12207;

расширенный составляющий — расширенная часть процесса из 12207

Три группы и пять категорий.

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

Основные процессы:

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

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

Вспомогательные процессы:

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

Организационные процессы:

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

- ORG: Организационная. Процессы, которые устанавливают бизнес - цели организации и разрабатывают процессы, продукты или активы ресурсов, которые, будучи использованы в проектах организации, помогают ей достигать своих бизнес – целей

45.(источник SEI_Lec_04_QA.doc страница 31)

ISO15504. Измерение «Зрелость»

В измерении «Зрелость» эталонной модели мера зрелости основывается на наборе атрибутов процессов (process attribute - PA).


В эталонной модели ISO15504 в отличие от CMM применяется шесть уровней зрелости процессов со следующими атрибутами:

1. Неполный процесс (Incomplete).

Процесс не реализован, или не способен достичь итога процесса.

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


2. Выполняемый (Performed) - реализованный процесс достигает итог процесса.

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

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

- будут получены рабочие продукты, поддерживающие достижение итога процесса.

3. Управляемый (Managed) - ранее описанный осуществляемый процесс выполняется теперь под управлением, основанном на определенных целевых показателях (т.е., планируется, отслеживается, верифицируется и настраивается).

PA 3.1 Управление выполнением

PA 3.2 Управление рабочими продуктами

4. Устоявшийся (Established) - ранее описанный управляемый процесс теперь выполняется на основе заданного процесса, основанного на правильных с точки зрения программной инженерии принципах и способного достичь своего назначения.

PA 4.1 Задание процесса

PA 4.2 Обеспечение процесса ресурсами

5. Предсказуемый (Predictable) - ранее описанный устоявшийся процесс теперь устойчиво выполняется в заданных пределах для достижения назначения процесса.

PA 5.1 Измерение

PA 5.2 Количественное управление процессом

6. Оптимизируемый (Optimizing) - ранее описанный предсказуемый процесс теперь динамически адаптируется и изменяется для того, чтобы эффективно отвечать соответствующим текущим и проектируемым бизнес–целям организации.

PA 6.1 Изменение процесса

PA 6.2 Непрерывное усовершенствование

46.(источник SEI_Lec_04_QA.doc страница 31-32)

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




Код	Название	%	Комментарий
NA	Not Achieved - Не обладает	0% - 15%	Доказательства того, что аттестуемый процесс обладает заданным атрибутом, отсутствуют либо недостаточны
A	Achieved - Обладает частично	16% - 50%	Существуют доказательства разумного систематического подхода к заданному атрибуту и того, что аттестуемый процесс обладает им в некоторой степени. Некоторые аспекты достижения могут быть непредсказуемыми.
L	Largely achieved - Обладает в основном	51% - 85%	Существуют доказательства разумного систематического подхода к заданному атрибуту и того, что аттестуемый процесс обладает им в значительной степени. Выполнение процесса может варьироваться в некоторых областях или организационных единицах.
F	Fully achieved - Обладает полностью	86% - 100%	Существуют доказательства полного и систематического подхода к заданному атрибуту и того, что аттестуемый процесс обладает им в полной мере. В заданной организационной единице отсутствуют заметные недостатки


(см. Модель уровней зрелости процессов 15504_2_6_8_Модель уровней зрелости процессов.doc)

/*принципы оценки атрибутов эталонной модели не нашёл*/

47.(источник SEI_Lec_04_QA.doc страница 33 и презентация SEI_Lec_04_QA слайд 76)

Факторы успеха аттестации процессов.

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

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

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

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

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

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

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

Схема проведения процесса аттестации.

Документированный процесс – набор инструкций и процедура

- роли и обязанности;

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

- требуемые ресурсы;

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

- планирование;

- сбор данных;

- подтверждение данных;

- формирование рейтингов процесса.

Выбор совместимой модели

Факторы успеха аттестации процессов

- Обязательства заказчика и аттестаторы

- Мотивация – поддержка процессов, а не поиск виноватых

- Конфиденциальность

- Релевантность – уверенность в выгоде аттестации

- Доверие

48.(источник SEI_Lec_04_QA.doc страница 34)

- Для проведения аттестации аттестаторы демонстрируют свою компетентность

- Компетентность является результатом:

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

- владения основными технологиями ISO 15504, включая эталонную модель, аттестационные модели, методы и инструментальные средства, а также процессы выставления рейтингов;

- личных качеств, способствующих эффективной работе;

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

- Альтернативой демонстрации компетентности является подтверждение образования, специальной подготовки и опыта.

49.(источник Ingeneriya.po.djvu стр. 106-116)

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


Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых системой функций. Кроме требований этих двух уровней, применяется ещё более детализированное описание системы – проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.


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


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


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


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


1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указанно, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.


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


3 . Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.


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


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

50.

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

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

Полнота.


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


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


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


Ясность (недвусмысленность, определенность, однозначность спецификаций).


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


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


Корректность и согласованность (непротиворечивость).


Корректность - одно из важнейших свойств требований. К. Вигерс в [3.3] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определенной степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет.


Верифицируемость (пригодность к проверке).


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


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


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


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


Осуществимость (выполнимость).


Выполнимость требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами.


Трассируемость


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


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


Упорядоченность по важности и стабильности


Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.


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


Наличие количественной метрики


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


Каких требований не должно быть


требования должны отвечать на вопрос: "что должна делать система", абстрагируясь от вопроса "как она это должна делать".