А. С. Агапов "Лаборатория нтр", г. Москва



Скачать 96.11 Kb.
Дата07.08.2013
Размер96.11 Kb.
ТипДокументы
Модель для выбора методологии разработки программных систем на основе стандарта ISO 15504

А. С. Агапов

"Лаборатория НТР", г. Москва

aas@ntrlab.ru

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

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

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

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

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

  • каковы допуски этих требований и

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

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


Как же можно определить, где находится этот оптимум? Для этого надо рассмотреть существующие методологии как точки, находящиеся в едином пространстве методологий. Как построить систему, в которую будут укладываться такие полярно противоположные подходы? Это возможно, так как все методологии имеют по существу одну цель -- снижение риска. Посмотрим, как такую задачу предлагают решать органы стандартизации. Стандарт ISO/IEC 15504 посвящен аттестации зрелости процессов создания программных средств. Результаты аттестации могут быть использованы для оптимизации и усовершенствования процессов разработки, используемых организацией.

Зрелость процесса – это его способность решать поставленную задачу. ISO/IEC 15504 предлагает оценивать зрелость процессов на основании их соответствия эталонной модели. Эталонная модель процессов представляет собой “абсолютный” взгляд на то, из каких процессов состоит создание программных средств и какова задача каждого процесса. О соответствии конкретного процесса эталонной модели судят именно по степени, в которой реализация конкретного процесса отвечает его “эталонному” назначению. Эталонная модель применима вне зависимости от конкретных условий.

Таким образом, любая методология включает в себя все процессы эталонной модели ISO/IEC 15504 или их подмножество. Процессы эффективны в той степени, в которой они решают свою задачу. Однако судить о степени соответствия процессов эталонной модели можно, лишь принимая во внимание контекст, в котором эти процессы выполняются. Для этого ISO/IEC 15504 предлагает строить аттестационную модель, которая дополняет процессы эталонной модели конкретными показателями – критериями, по которым можно судить о зрелости процесса. Аттестационная модель должна быть построена применительно к конкретным условиям и специфике реализации процесса.

Можно по-разному реализовать процессы, отвечающие одному и тому же назначению. В зависимости от конкретной ситуации и потребностей для реализации процессов могут быть выбраны различные средства. Меры зрелости реализации этих процессов тоже будут различными. Одним из таких средств является строгая регламентация промежуточных рабочих продуктов и управленческих процессов. По этому пути идут многие известные методологии. По наличию и свойствам этих продуктов и по строгости и полноте управленческих процессов можно судить о зрелости процесса. Таким образом, построена аттестационная модель, содержащаяся в ISO/IEC 15504 в качестве примера. Другим способом является построение процесса внутрипроектного взаимодействия, основанного на человеческом факторе. Те же процессы, составляющие эталонную модель ISO/IEC 15504 можно реализовать, основываясь на особенностях человеческой личности. Судить об эффективности таких процессов можно, если построить аттестационную модель, учитывающую “человеческий фактор”

Рассматривая в качестве примера "легкую" методологию XP (Extreme Programming) можно видеть, что в ней реализованы все основные процессы, входящие в эталонную модель ISO/IEC 15504. Наиболее характерные такие процессы и соответствующие им элементы XP приведены в таблице.

Процесс ISO/IEC 15504

Элемент XP

CUS 3 Выявление требований

User stories

MAN 2 Управление проектами

Планирование релиза, итерации

ENG 1.3 Проектирование программных средств

Spike, CRC-карты

ENG 1.4 Конструирование программных средств

Парное программирование, переработка

ENG 1.5 Интеграция программных средств

Непрерывная интеграция

ENG 1.6 Тестирование программных средств

Помодульные тесты

ENG 2 Сопровождение системы

User stories, итерации

SUP 4 Верификация

Функциональные тесты

Из приведенного примера мы видим, что основные процессы эталонной модели процессов реализованы в XP. Попробуем оценить зрелость этих процессов. По ISO 15504 зрелость процесса измеряется как совокупность оценок (рейтингов) обладания конкретного процесса определенными атрибутами, распределенными по уровням зрелости. Рейтинг атрибута определяет степень обладания процесса данным атрибутом – процесс может обладать атрибутом полностью (П), в основном (О), частично (Ч) или не обладать вовсе (Н).

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




1.
Выполняемый процесс

2.
Управляемый процесс

3.
Устоявшийся процесс




PA1.1
Выполнение процесса

PA2.1
Управление выполнением

PA2.2
Управление рабочими продуктами

PA3.1
Задание процесса

PA3.2
Обеспечение ресурсами

Выявление требований

П

П

П

П

П

Проектирование программных средств

О

О

П

Ч

П

Конструирование программных средств

П

П

П

П

П

Тестирование программных средств

П

П

П

П

П

Из примера видно, что должным образом реализованная методология XP обладает, по-видимому, по крайней мере, уровнем зрелости 3 по ISO 15504. Конечно, это только оценка. Для того чтобы сравнивать зрелость XP, других легких методологий а также процессов, реализованных конкретной организацией, необходимо разработать аттестационную модель, соответствующую контексту, в котором применимы эти методологии. Когда такая модель будет разработана, она позволит рационально оценивать зрелость процессов организаций, использующих легкие методологии.

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

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

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

  • критичность проекта и

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

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

Цели, которые ставятся при организации процесса, являются критерием эффективности. Такими целями могут являться, например:

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

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

  • обеспечение повышенных гарантий качества продукта;

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

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

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

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

Похожие:

А. С. Агапов \"Лаборатория нтр\", г. Москва iconСтандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва
Два наиболее высокоуровневых типа стандартов предприятия в области информационных систем — стандарты, относящиеся к архитектуре и...
А. С. Агапов \"Лаборатория нтр\", г. Москва iconКурс лекций москва 1998 ©Агапов И. И

А. С. Агапов \"Лаборатория нтр\", г. Москва iconКак заказывать программное обеспечение? (Модель iso 15504 pulse) Н. Э. Михайловский, “Лаборатория нтр”
С другой стороны люди этой профессии, как правило, являются отличными менеджерами и хорошими специалистами в области информационных...
А. С. Агапов \"Лаборатория нтр\", г. Москва iconРазмещение организаций-экспонентов на выставке MedSoft-2011
Лаборатория Акросс Инжиниринг, ООО (Москва) Член армит и Рош Диагностика Рус, зао (Москва)
А. С. Агапов \"Лаборатория нтр\", г. Москва iconНаучно-исследовательский семинар-лаборатория
В полном смысле слова это должна быть лаборатория исследовательской социологической мысли
А. С. Агапов \"Лаборатория нтр\", г. Москва iconОфис приема проб на анализ
Независимая испытательная лаборатория: Адрес: Москва, 2-ой Лихачевский пер., д. 1а. (схема проезда, фасад здания)
А. С. Агапов \"Лаборатория нтр\", г. Москва iconПаразитологическая лаборатория
Рс (Я) функционирует единственная в республике паразитологическая лаборатория, которая обеспечивает серологические исследования на...
А. С. Агапов \"Лаборатория нтр\", г. Москва iconПроизводственная лаборатория
Производственная лаборатория создается и ликвидируется приказом директора предприятия
А. С. Агапов \"Лаборатория нтр\", г. Москва iconЛаборатория биотехнологий Астраханского государственного университета
Лаборатория биотехнологий – постоянный участник международных выставок, конгрессов, совещаний, проходящих как в России, так и в странах...
А. С. Агапов \"Лаборатория нтр\", г. Москва iconЛаборатория Касперского
Лаборатория Касперского”, российский лидер в области разработки антивирусных систем безопасности, сообщает о появлении нового Windows...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org