1-software_engineering_requirements (1133541), страница 6
Текст из файла (страница 6)
Однако, частныеметоды или нотации, как отмечается в SWEBOK, так или иначе следуют распространенным виндустрии практикам и тяготеют к тем формам, с которыми связаны накопленный опыт иподтвержденные общепринятой практикой знания. SWEBOK отмечает, что могут быть разработаныразличные виды моделей, включающие потоки работ и данных, модели состояний, трассировкисобытий, взаимодействия пользователей, объектные модели, модели структур данных, и т.п. Кстати,именно такая ситуация сложилась с UML, все чаще воcпринимаемым в качестве общепринятого илиde-facto стандарта в моделировании и включающем целый комплекс моделей (в UML 2.0 включено14 моделей, представленные в двух группах – статические модели и поведенческие), связанных иобъединенных общей архитектурой, на основе концепции метамоделей.По мнению автора, современное состояние стандарта UML (унифицированного языкамоделирования Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org )версии 2.0 вполне позволяет говорить о расширении его применимости в “чистом” бизнесмоделировании.
На фоне богатства выразительных средств, появления соответствующегоинструментального обеспечения работы с UML 2.0, длительной истории успешного применениястандарта UML 1.x, инструментов на его основе и повсеместного использования UML в области13Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ruОсновы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.объектно-ориентированного анализа и проектирования не только аналитиками, но архитекторами иразработчиками ПО, можно с уверенностью говорить о смещении фокуса индустрии программногообеспечения в сторону UML и отходу (как минимум, частичному) от IDEF, в применении каналитической деятельности.
Темпы такой “миграции”, конечно, зависят от степениконсервативности взглядов конкретных специалистов-аналитиков. Однако, давление рынка,требование унификации, в частности, выразительных средств описания активов проектов в рамкахвсей проектной команды – те причины, по которым, по мнению автора, аналитики, не воспринявшиеUML-ориентированный тренд, могут оказаться за бортом серьезных корпоративных ИТ-проектов.Даже на фоне “неприятия” UML некоторыми игроками рынка, критическая масса знаний и практик поего применению уже оказалась достаточно велика, чтобы игнорировать его применение. В то жесамое время, не стоит воспринимать UML как панацею – это касается любой технологии, практикиили подхода. Создан, активно развивается и уже поддержан индустрией стандарт BPMN – BusinessProcess Management Notation (см.
www.bpmi.org). Таким образом, все определяется конкретным“культурным” контекстом. Просто надо помнить об этом и оставаться “прагматиками”, вположительном понимании этого слова, не теряя креативности в повседневной деятельности.Необходимо отметить, что на практике наблюдается тенденция разделения вопросов определениятребований и моделирования. Это, например, заметно в современных методологиях, таких как RUP(Rational Unified Process), где работа с требованиями и моделирование/проектирование – суть дверазные дисциплины (об этом мы будем говорить в соответствующей главе).4.3 Архитектурное проектирование и распределение требований (Architectural Design andRequirements Allocation)Считается, что создание архитектуры программных решений является обязательным элементовуспешности таких проектов.
Архитектурное проектирование перекрывается с программным исистемным дизайном (проектированием) и иллюстрирует насколько сложно провести четкую граньмежду различными аспектами проектирования. Данная тема работы с программными требованиямитесно связана с секцией “Структура и архитектура программного обеспечения” (Software Structureand Architecture) области знаний “Проектирование программного обеспечения” (Software Design). Вомногих случаях, инженеры действуют как архитекторы, потому как процессы анализа и выработкитребований зависят от программных компонент, создаваемых для решения поставленныхзаданными требованиями задач, призванных, в конечном счете, добиться реализации поставленныхперед проектом целей.Архитектурное проектирование очень близко к концептуальному моделированию.
Непосредственноеотображение бизнес-сущностей реального мира на программные компоненты не являетсяобязательным. Во многом поэтому и существует такое разделение между моделированием ипроектированием. В принципе, можно говорить о том, что деятельность по моделированию вбольшей степени касается того, ”что” надо сделать, а архитектура - “как” это будет реализовано.Существует ряд стандартов и общепринятых практик, связанных с архитектурным проектированием.Среди них наиболее популярны: Стандарт IEEE 1471-2000 “Recommended Practice for Architectural Description of SoftwareIntensive Systems” Модель Захмана – Zachman Framework (www.zifa.com) TOGAF – The Open Group Architecture Framework (www.opengroup.org/architecture/)Важно заметить, что ни в коем случае не надо путать архитектурные рекомендации (ArchitecturalGuidelines) с практиками и стандартами архитектурного проектирования. Одни (например, FederalEnterprise Architecture Framework FEAF - !!!) дают рекомендации по конкретным архитектурнотехнологическим решениям.
Другие концентрируются именно на том, чему стоит уделить вниманиепри создании архитектуры, как ее описать и детализировать, и что из себя представляетархитектура, как таковая (например, ISO 15704 Industrial Automation Systems – Requirements forEnterprise-Reference Architectures and Methodologies).5. Спецификация требований (Requirements Specification)На инженерном жаргоне, да и в терминологии ряда методологий, устоялся термин “softwarerequirements specification” (SRS) – спецификация программных требований. Для сложных систем, на14Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ruОсновы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.самом деле, существует целый комплекс спецификаций, документов, которые являются результатомсбора и анализа требований, их моделирования и архитектурного проектирования.
Эти документысистематически анализируются, в них вносятся изменения, они пересматриваются и утверждаются.Чаще всего, для описания комплексных проектов (в части требований) используется три основныхдокумента (спецификации): Определение системы (system definition) Системные требования (system requirements) Программные требования (software requirements)5.1 Определение системы (System Definition Document)Данный документ, часто называемый как “спецификация пользовательских требований” (userrequirements specification) или “концепция” (concept <of operations>), описывает системныетребования. Содержание документа определяет высокоуровневые требования, часто –стратегические цели, для достижения которых создается программная система.
Принципиальныммоментом является то, что такой документ описывает требования к системе с точки зрения областиприменения - “домена”. Соответственно, изложение требований в нем ведется в терминахприкладной области. Документ описывает системные требования вместе с необходимойинформацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур иорганизационных и других регламентов. Примером стандарта для создания и структурированиятакого документа является IEEE 1362 “Concept of Operations Document”.5.2 Спецификация системных требований (System Requirements Specification)В сложных проектах принято разделять спецификацию системных требований (system requirements)и спецификацию программных требований (software requirements).
При таком подходе программныетребования порождаются системными требованиями и детализируют требования к компонентам иподсистемам программного обеспечения. Документ описывает программную систему в контекстесистемной инженерии (system engineering), идеи которой кратко описаны в Главе 12 SWEBOK“Связанные дисциплины программной инженерии”.
Строго говоря, спецификация системныхтребований описывает деятельность системных инженеров и выходит за рамки обсужденияSWEBOK. Стандарт IEEE 1233 является одним из признанных руководств по разработке системныхтребований. И, как уже отмечалось ранее, не стоит забывать о том, что понятие система, в общемслучае, охватывает программное обеспечение, аппаратную часть и людей. Системная инженерия(см.
материалы INCOSE – www.incose.org ), в свою очередь, самостоятельная и не менее объемнаядисциплина чем программная инженерия. SWEBOK рассматривает системную инженерию какважную связанную дисциплину. Ну а системные требования – один из элементов реальногосвязывания различной инженерной деятельности - программной и системной.5.3 Спецификация программных требований (Software Requirements Specification - SRS)Часто эту спецификацию называют “требованиями к программному обеспечению”. Все же, учитываясуществование дисциплин системной и программной инженерии, мы используем термин“программные требования”, как более точно подходящий по смыслу по моему мнению.Программные требования устанавливают основные соглашения между пользователями(заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чегоот нее не стоит ожидать. Документ может включать процедуры проверки получаемого программногообеспечения на соответствие предъявляемым ему требованиям (вплоть до содержания плановтестирования), характеристики, определяющие качество и методы его оценки, вопросы безопасностии многое другое.
Часто программные требования описываются на обычном языке. В то же время,существуют полуформальные и формальные методы и подходы, используемые для спецификациипрограммных требований. В любом случае, задача состоит в том, чтобы программные требованиябыли ясны, связи между ними прозрачны, а содержание данной спецификации не допускалоразночтений и интерпретаций, способных привести к созданию программного продукта, неотвечающего потребностям заинтересованных лиц.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
