Введение

Здравствуйте, уважаемые собратья по клавиатуре и манипулятору типа мышь!

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

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

Влияние стандартов на процессы архитектурного проектирования

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

• Анализ требований;
• Проектирование;
• Кодирование;
• Тестирование;
• И т. д;

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

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

Должны быть учтены такие аспекты, как:

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

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

Перечень стандартов и их содержание, на конкретном предприятии, должно определяться на стадии планирования.

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

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

В качестве отступления мы приведем следующий пример.

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

• Стандарт на работу с требованиями;

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

• Стандарт на разработку архитектуры программного продукта;

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

• Стандарт процесса кодирования;

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

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

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

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

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

Большинство современных стандартов, описывающих работу с требованиями, выдвигают следующие характеристики, которым должно отвечать каждое их них:

• Конкретность/измеримость;
• Корректность/обоснованность;
• Соответствие функциональности программного продукта;
• Возможность последующей верификации;
• Уникальность;
• Последовательность;
• Непротиворечивость;
• Возможность декомпозиции;
• Изменяемость с минимальными затратами;
• Трассируемость;

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

Но изменения, иногда вносятся и в скелет.

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

Принципы и темп развития современного мира определяют его черты.

Можно привести следующий пример:

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

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

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

Процессы разработки должны начинаться с процесса разработки требований и вестись в соответствии с планом, корректируемым по «ходу».

Выводы

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

До встречи!

Авторы статьи

Иван Никитин

Михаил Цулая