Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Практические соображения (Practical Considerations) Первый уровень декомпозиции секций данной области знаний напоминает описание последовательности действий. Это, безусловно, упрощенный взгляд на процесс работы с требованиями. Данный процесс, точнее, комплекс процессов, охватывает весь жизненный цикл программного обеспечения. Управление изменениями и сопровождение, поддержка актуальности требований и их реализации – ключ к успешным процессам программной инженерии. Далеко не каждая организация обладает культурой документирования и управления требованиями. Особенно часто это встречается в молодых небольших компаниях, выводящих на рынок новые продукты и обладающие “сильным вижином”, четким пониманием целей, для которых создается продукт, но не имеющих достаточно ресурсов и, во многом поэтому считающих, что динамизм – залог успеха. Постепенно такие компании вырастают, проекты – усложняются и, как следствие складывается ситуация, когда отследить все необходимые требования в неформальной форме уже просто невозможно. Эта тема практически неисчерпаема. Многие средние по масштабам компании пытаются сохранить тот же вровень гибкости и динамизма, который применялся во времена рождения компании, когда она еще была “стартапом” (start-up – название молодых компаний, которые раскручивали свои проекты во времена интернет-бума конца 90-х и которое прижилось для вновь образующихся малых бизнесов, растущих не столько на внешних инвестициях, сколько на идеях и упорстве ее создателей). Так или иначе, динамизм присущ не только компаниям, но и продуктам, самим требованиям к ним. Управление изменениями, концепцией, видением продукта не может быть хаотическим – история индустрии однозначно это показывает. Поэтому отношение к управлению требованиями как к постоянно действующему бизнес- процессу – абсолютно обоснованный подход, требующий применения определенных практик. В противном случае, мы практически гарантировано столкнемся с темни негативными последствиями, которые не раз описывались и упоминались выше. Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements Process) В большинстве случаев, понимание и интерпретация требований продолжает эволюционировать в процессе проектирования и разработки программного обеспечения. Кроме того, требования часто меняются в силу изменений бизнес-контекста для которого создается и в котором эксплуатируется программное обеспечение. Необходимо понимать неизбежность изменений и планировать шаги по уменьшению проблем, связанных с изменениями. В то же самое время, современные практики гибкой разработки говорят о том, что необходимо концентрироваться только на том, что требует внимания “прямо сейчас”, не закладываясь на предупреждение всех возможных рисков, в том числе связанных с изменениями, включая изменения требований. Говорить о том, какой подход – предупреждение или реагирование является гарантировано приводит к успеху – сложно сказать. Более того, если кто-то однозначно настаивает только на одной из идей и полностью отвергает другую – это профанация. Восприятие изменений и возможность их своевременной обработки - вопрос способности проектной команды работать в условиях постоянно меняющихся условий, принимаемых архитектурных решений и многих других культурных, технологических и организационных факторов. Так или иначе, понимание меняющейся природы требований – один из факторов адекватного реагирования на сами изменения, а, следовательно, и возможности успешного завершения проекта. Управление изменениями (Change Management) Управление изменениями – одна из ключевых тем управления требованиями. Необходимость определения процедур для обработки изменений совсем не то же самое, что и их детальная формализация. Такие процедуры необходимы. Им посвящена тема управления изменениями в приложении к требованиям. В то же время, рассматривать изменение требований в отрыве от других процессов, по меньшей мере, кажется странным. Соответственно, данный вопрос является составной частью управления изменениями и конфигурациями программного обеспечения (Software Configuration and Change Management, SCCM), которое сегодня принято называть просто конфигурационным управлением (Software Configuration Management, SCM), подразумевая, что это не только вопросы контроля версий, но управление всеми активами проекта, включая код, требования, запросы на изменения – change requests (в том числе, отчеты об ошибках – defect или bug reports), задачи (в терминах проектного менеджмента) и т.п. Общий комплекс вопросов конфигурационного управления рассматривается в области знаний SWEBOK “Управление конфигурациями программного обеспечения” (Software Configuration Management). Атрибуты требований (Requirements Attributes) Требования должны состоять не только из описания того, что необходимо сделать, но и содержать информацию, необходимую для интерпретации требований и управления ими. Например, с пользовательскими требованиями часто ассоциируют сценарии Use Case (как в текстовом, так и графическом представлении) и, в то же время, функциональные требования часто трансформируются в задачи в терминах проектного управления, с которыми связаны параметры законченности (например, в процентах), ответственности (например, кто является “владельцем” требования, кто из инженеров назначается исполнителем или принимает на себя обязанности, связанные с реализацией заданной функциональности, как это принято, например, в XP или FDD). Примеров существует множество и, в зависимости от применяемых практик и методов, сложившейся проектной и организационной культуры, спектр атрибутов может меняться достаточно широко, практически, неограниченно. Необходимо также помнить, что к обсуждаемым атрибутам также относятся параметры, связанные с классификацией требований (см. выше тему 4.1 “Классификация требований”). В свою очередь, принадлежность к тому или иному классу (категории, типу, виду) требований означает не только семантику того, “чему посвящены” требования (функциональности, параметрам качества и т.п.), но и комплекс атрибутов, общий для всех требований данного класса. В какой-то степени можно провести параллель между требованиями и записями (строками) в реляционной базе данных, где каждая запись обладает набором атрибутов (столбцов). В определенном смысле, можно и необходимо говорить о том или ином уровне атомарности требований (что не исключает связей между требованиями), представляемой такой метафорой. Трассировка требований (Requirements Tracing) Трассировка требований обеспечивает связь между требованиями и отслеживание источников требований. Трассировка является фундаментальной основой проведения анализа влияния (impact analysis) при изменении требований, помогая предсказывать эффект от внесения таких изменений. Трассировка предполагает направленную связь (представляется в виде сложного направленного ациклического графа) между требованиями, то есть зависимости. Требования (B) обладают обратной зависимостью (то есть вторичны) по отношению к требованиям (A) и заинтересованным лицам, которые являются источником либо образуют причину появления рассматриваемых требований (B). И, наоборот, требования (A) трассируются напрямую к тем требованиям (B) и элементам дизайна (например, модели или, в общем случае, кода, запросов на изменения и т.п.), которые порождаются или удовлетворяют требованиям (A). Измерение требований (Measuring Requirements) С практической точки зрения, обычно полезно иметь нечто, позволяющее определить “объем” требований для заданного (создаваемого) программного продукта. Это число полезно для исследования “масштабов” изменений в требованиях, оценки стоимостных характеристик (cost estimation) разработки и поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п. Измерение объема функциональности (Functional Size Measurement, FSM) техника такого рода численной оценки, определена на концептуальном уровне в стандарте IEEE 14143.1. Стандарты ISO/IEC и другие источники описывают частные методы FSM (например, модель COCOMO II для оценки стоимости, например, может использоваться в тесной связи с методами функциональных точек – functional points для оценки масштабов функциональности, то есть требований, предъявляемых заданной программной системе). Дополнительная информация по стандартам и подходам в оценке масштабов представлена в области знаний “Процесс программной инженерии” (Software Engineering Process). В дополнение к практическим соображениям, представленным в SWEBOK, на фоне общей тенденции разработки моделей <оценки> зрелости, стоит отметить, что существуют определенные работы и по созданию различных моделей зрелости требований. Например, наиболее популярная модель зрелости в индустрии программного обеспечения – CMMI включает разный объем и содержание работ по определению и управлению требованиями для уровней зрелости 2 и 3. Проектирование программного обеспечения Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. Содержит перевод описания области знаний SWEBOK “Software Design”, с замечаниями и комментариями. Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или ее компонентов называется проектированием. Результат процесса проектирования – дизайн. Рассматриваемое как процесс, проектирование есть инженерная деятельность в рамках жизненного цикла (в данном контексте – программного обеспечения), в которой надлежащим образом анализируются требования для создания описания внутренней структуры ПО, являющейся основой для конструирования программного обеспечения как такового. Программный дизайн (как результат деятельности по проектированию) должен описывать архитектуру программного обеспечения, то есть представлять декомпозицию программной системы в виде организованной структуры компонент и интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна является тот уровень детализации компонентов, который позволяет заняться их конструированием. Термины дизайн и архитектура могут использоваться взаимозаменяемым образом, но чаще говорят о дизайне как о целостном взгляде на архитектуру системы. Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения (Software Development Life Cycle), например, IEEE и ISO/IEC (ГОСТ Р ИСО.МЭК) 12207. Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей: Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание высокоуровневой структуры и организации компонентов системы; Детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования. В результате консенсуса, принятого создателями SWEBOK, данная область знаний не описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или “архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из известных специалистов в программной инженерии, предложил терминологическое разделение различных видов дизайна: D-дизайн (D-design, decomposition design) – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент; FP-дизайн (FP-design, family pattern design) – семейство архитектурных представлений, базирующихся на шаблонах; I-дизайн (I-design, invention) – создание высоко- уровневой концепции, видения того, что из себя будет представлять программная система; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации. Если обсуждать данную область знаний в терминах ДеМарко, проектирование программного обеспечения в понимании программной инженерии подразумевает D- и FP-дизайн. I-дизайн в большей степени относится к работе с программными требованиями. Соответственно, данная область знаний тесно связана со следующими областями программной инженерии: Software Requirements Software Construction Software Maintenance Software Engineering Management Software Quality Сама же область знаний по проектированию программного обеспечения представлена в виде 6 секций, структурированных по темам. Рисунок 3. Область знаний “Проектирование программного обеспечения” [SWEBOK, 2004, с.3-2, рис. 1] Основы проектирования (Software Design Fundamentals) Эта секция вводит концепции, понятия и терминологию в качестве основы для понимания роли и содержания проектирования (как деятельности) и дизайна (архитектуры, как результата) программного обеспечения. Темы данной секции: Общие концепции проектирования (General Design Concepts) К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения. Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и развиваемый консорциумом The Open Group (www.opengroup.org), предлагает следующие <возможные> цели (goals): Улучшение и повышение продуктивности бизнес- процессов Уменьшение затрат Улучшение операционной бизнес-деятельности Повышение эффективности управления Уменьшение рисков Повышение эффективности ИТ-организации Повышение продуктивности работы пользователей Повышение интероперабельности (возможности и прозрачности взаимодействия) Уменьшение стоимости <поддержки> жизненного цикла Улучшение характеристик безопасности Повышение управляемости Контекст проектирования (Context of Software Design) Для понимания роли проектирования программного обеспечения важно понимать контекст, в котором осуществляется проектирование и используются его результаты. В качестве такого контекста выступает жизненный цикл программной инженерии, а проектирование напрямую связано с результатами анализа требований, конструированием программных систем и их тестированием. Стандарты жизненного цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальное внимание вопросам проектирования и детализируют их, описывая контекст проектирования – от требований до тестов. Процесс проектирования (Software Design Process) Проектирование в основном рассматривается как двух- шаговый процесс: Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде. Техники применения (Enabling Techniques) Принципы проектирования, также называемые техниками применения, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения. Абстракция (Abstraction) В контексте проектирования программных систем существует два механизма абстракции – параметризация и специфицирование (может интерпретироваться как детализация). При этом, абстракция через специфицирование бывает трех видов: процедурная абстракция (динамическая, то есть в отношении поведения), абстракция данных (статическая, то есть в отношении информации) и абстракция контроля (то есть управления системой и обрабатываемой ею информацией). Обычно под абстракций, как результатом процесса абстракции, понимают модель, упрощающую поставленную проблему до рамок, значимых для заданного контекста. Связанность и соединение (Coupling and Cohesion) Связанность (Coupling) – определяет силу связи (часто, взаимного влияния) между модулями. Соединение (Cohesion) – определяет как тот или иной элемент обеспечивает связь внутри модуля, внутреннюю связь. Значение оригинальных терминов очень близко и, в зависимости от контекста, “связанность” и “соединение” могут рассматриваться как степень самодостаточности или ее отсутствия (coupling) и функциональная зависимость (cohesion) , соответственно. Хочется особенно подчеркнуть значимость этих понятий, так как с развитием сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA), слабосвязанной по своей природе (то есть со слабым “сопряжением”, слабой “силой связи” между модулями), по сравнению, например, с OMG CORBA (Common Object Request Broker Architecture), все чаще приходится сравнивать различные подходы и решения, определяемые способом и степенью связанности различных модулей, компонент и самих программных систем. Декомпозиция и разбиение на модули (Decomposition and Modularization) Декомпозиция и разбиение на модули сложных программных систем производится с целью получения более мелких и относительно независимых программных компонентов, каждый из которых несет различную функциональность (логически связанные группы функциональности). Инкапсуляция/сокрытие информации (Encapsulation/information hiding) Данная концепция предполагает группировку и упаковку (с точки зрения подготовки к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые для использования компонента или по другим причинам) были недоступны пользователям элементов (компонент). При этом, в качестве “пользователя” одного компонента может выступать другой компонент. Более того, при использовании объектно-ориентированного подхода, наследники компонентов могут не иметь доступа ко внутренним деталям реализации компонента, который является их предком (зависит от объектно- ориентированной модели конкретного языка программирования или платформы). Разделение интерфейса и реализации (Separation of interface and implementation) Данная техника предполагает определение компонента через специфицирование интерфейса, известного (описанного) и доступного клиентам (или другим компонентам), от непосредственных деталей реализации. |