Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 16

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

9.3). Преобразование одном модели в др)тую можно кратко описать следуюгдил» образом. ° Сотрудники предприятия становятся акторами разрабатываелгой системы. ° Описанные для сотрудников предцриятня варианты поведения люжно автоматизироватлп это помогает нам выявить прецеденты системы и определить необходимыс функциональные возможности. 4 См. каггопа! Яойвагс Согрогабоп (1999). 78 Часть 1.

Анализ проблемы ° Сущности бизнес-процесса — это то, в поддержке чего нам должна помочь система, по. этому оии помогают нам выявить классы сущностей при анализе модели системы. Модялвроваяяа еяетамм гяе. 5.3. Моделя бизнес процмти я сяпяаям Модель бизнес-процесса и последующее ее преобразование упрощают процесс перехода от понимания бизнес-процесса и существующих в нем проблем к созданию приложений, способствующих их решению. Когда использовать моделирование бизнес-процесса Моделирование бизнес-процесса не является универсальным методом, который мы рекомендуем применять в процессе каждой разработки программного обеспечения. Бизнес-моделн, в основном, нужны в сложной многомерной прикладной среде, когда мной ство людей непосредственно вовлекаются в использование системы.

Например, при создакии дополнительной функции для существующего телекоммуникационного коммутатора моделировать бизиес-процесс не понадобится. Но при создании системы ввода заказов для компании СоосЬАге~Ь моделирование бизнес-процесса позволит получить определенные преимущества при проведении анализа проблемы. Заключение В этой главе описан специальный метод анализа проблем — моделирование бизнеспроцесса. При этом обсуждались следующие вопросы.

Глава 5. Моделирование бизнес-процессов ° Зачем нужно моделировать бизнес-процесс ° Как, используя язык ОМЬ, преобразовать разработанные в инженерии программ- ного обеспечения л~етоды и применить нх в моделировании бизнес-процесса ° Основные артефакты моделирования бизнес-процесса — модель прецедентов биз- нес-процесса и модель объектов бнзнес-процесса ° Как, используя модель бизнес-процесса, перейти к определению программных приложений и выявить требования к программному обеспечению Далее.. В следующей главе мы рассмотрим инженерию систем, интенсивно исполыующих программное обеспечение. Это еще один метод анализа проблем, который поможет придать форму приложениям, разрабатываемым для систем встроенного типа.

Глава 6 Инженерия систем, интенсивно использующих программное обеспечение г. '" „... Основные полонсеннж гц ° гс г'гй Сцстемиая инженерия — это наиболее подходящий дяя разработки встрос еннйх систем метод анализа проблем г: И Системная 'инженерия помогает понять требования, ггредъявляеыыс к '.' программнъгм Приложениям, выполняемым внутри создаваемой системы. ° Нисходящий процесс разработки требований гарантирует, что каждое ,';: ' системное требование выполняется определенной подсистемой гпггг сово. ' гкупностью взаимодействующих подсистем.

е И На современном этапе зачастую необходимо оггтилгггзггровать затраты на разработку программного обеспечения, а ие затраты на технические компоненты системы. В главе б мы рассмотрели моделирование бизнес-процессов. Этот метод прилгепяется для анализа проблем в области !Ь/Пэприложеггигг. Оп помогает определить, какие приложения следует создать и где опи должны выполняться, принимая во впилюцпс вычислггтельиую среду компании, расположение ес цолраэделеиий, зданий, политических и физических конструкций. Другими словами, оц помогает определить, ио'<ечу н где долж. но появиться некое приложение. В процессе анализа происходит постепенный переход иэ обллсяги яробяелгм к первому приближению обллгжп рен<енпя, где в олгголг плп нескольких приложениях будут существовать функцнональпыс воэможности, решающие дашпчо про<блсму и удовлетворяющие конечную потребность пользователя.

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

эы. Следует найтн дргтой метод. который поможет ответить на вопросгл логи хг и гг3г. Этим и ацщмастся агслгелпиш ггиягеггсргцг (сггсггжчггое ггрсгкигггроэагггге-зулгеггг его гггсггггбу 82 Часть 1. Анализ проблемы Что такое системная инженерия Согласно определению Международной ассоциации системного проектирования (1птетпайопа! Соипсг! оп Епб!пеег'!пя Ьузтегпз, 1ХСОЬЕ 1999) Ситпемнпя инженфня — эпю междисциплинарный подход и аюптветствующие ему федства, которые иозтыяют создавать успешно работающие пизпеиы. Это дисцтттглина, коттфпя занимается вьшвлением на ранних этапах цтгкла рафаботтгки нотребноопей клиента и необходимых функциональных еознозкностей, а пюкже документированием птребовпний За этим должны следовать разработка технического проекпш как единого целого и проверка тфавильности создаваемой системы.

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

Но мы не будем полностью обсуждать данный подход в книге по требованиям к программному обеспечению! (Более подробно о системной инженерии см. Вес)гт!и (1997).) В рамках данной книги мы используем системную инхтенерию в качестве метода анализа проблемы, чтобы понять потребности проблемной области и требования, которые должны быть предъявлены к решению. Иными словами. в нашем случае системная инхтенерия поможет понять пфебтмпния, копифые будут тфедьявлены ко всем тфофаммным тфиеоженням, вытиыняемым внуефп сисоммыреииния (независимо от того, выполняются ли они встроенным микропроцессором или системой УХ1Х в рамках всемирной теле. коммуникационной системы).

Основные принципы системной инженерии Системная инженерия предлагает восемь основных принципов. Если мы собираемся использовать системную инженерию в качестве метода анализа проблемы, основные принципы дисциплины должны укззать нам, как следует действовать, анализируя проблему с целью выработки требований. Рабочая группа по применению методов системной инженерии 1ХСОЬЕ (1ХСОБЕ Ь)чтегпз Епб!пееппя Ргаспсез гтотй(пб бг опр, ! 993) сформулировала восемь основных принципов. Глава 6. Инженерия систем, интенсивно использующих программное...

83 ° Знание проблемы, клиента и потребителя. ° Использование основанных на потребностях критериев эффективности для при- нятия системных решений. ° Задание требований и управление ими. ° Выявление и оценка альтернатив при выработке решения. ° Верификация и проверка правильности требований, а также функционирования решения. ° Обеспечение целостности системы.

° Использование согласованного и документированного процесса. ° Организация действий согласно плану. В этом списке перечислены некоторые основные принципы систелсной инженерии. Но в данной дисциплине существует раздел, в основе которого лежит иной процесс— процесс последовательной декомпозиции сложных систем на более простые. Декомпозиция сложных систем С помощью процесса декомпозиции сложная проблема (система) (рис. б.1) разбивается на две меньшие проблемы — подсистемы (рис. б.2).

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