Проектирование программного обеспечения

Проектирование ПО определяется как «процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или компонента» и как «результат этого процесса», рассматриваемый как процесс.Проектирование ПО (рисунок 4.4)– это этап жизненного цикла разработки программного обеспечения, в котором анализируются требования к программному обеспечению, чтобы составить описание внутренней структуры ПО, которая послужит основой для его построения. Результат проектирования ПО описывает архитектуру программного обеспечения, то есть структуру программного обеспечения и его объединение в компоненты, а также интерфейсы между этими компонентами. Он также должен описывать компоненты на уровне детализации, что позволяет их создавать. Проектирование играет важную роль при создании программного обеспечения: во время проектирования программного обеспечения разработчики ПО создают различные модели, которые являются своего рода планом решения, которое будет реализовано. Мы можем анализировать и оценивать эти модели, чтобы определить, позволят ли они выполнять различныетребования.Мы также можем исследовать и оценивать альтернативные решения и компромиссы. Наконец, мы можем использовать полученные модели для планирования последующих действий по разработке, таких как проверка системы и валидация, в дополнение к использованию их в качестве исходных данных и отправной точки для построения и тестирования. В стандартном списке процессов жизненного цикла ПО, например, в стандарте ISO / IEC / IEEE Std. 12207, «Процессы жизненного цикла программного обеспечения» [2], разработка программного обеспечения состоит из двух видов деятельности, которые соответствуют анализу требований к программному обеспечению и разработке программногообеспечения:
• Архитектурный дизайн программного обеспечения (иногда называемый высокоуровневым дизайном): разрабатывает структуру верхнего уровня и организацию программного обеспечения и идентифицирует различные компоненты.

 • Детальный дизайн программного обеспечения: подробно описывается каждый компонент ПО для облегчения его построения.
В области знаний SoftwareDesign не обсуждается каждая тема, включающая слово «дизайн». В терминологии Тома ДеМарко [] темы, обсуждаемые в этой KA, касаются главным образом D-дизайна (дизайна декомпозиции), цель которого – сопоставление программного обеспечения с компонентами. Однако из-за его важности в области архитектуры программного обеспечения мы также рассмотрим FP-дизайн (дизайн семейных шаблонов), целью которого является установление эксплуатационной общности в семействе программных продуктов. Эта KA не рассматривает I-дизайн (дизайн изобретения), который обычно выполняется во время процесса требований к программному обеспечению с целью концептуализации и определения программного обеспечения для удовлетворения обнаруженных потребностей и требований, поскольку эта тема считается частью процесса требований (см. KA «Требования к программному обеспечению»). ЭтаKA дизайнаПО связана конкретно с требованиями к программному обеспечению:проектирование, управление программным обеспечением, модели и методы разработки программного обеспечения, качество программного обеспечения и вычислительные основы.

 

 

Рисунок 4.4. Структура области знаний по проектированию программного обеспечения

4.2.2. Конструирование программного обеспечения

 

Термин «конструкция программного обеспечения» относится к детальному созданию рабочего программного обеспечения посредством комбинации кодирования, проверки, модульного тестирования, тестирования интеграции и отладки. Область знаний SoftwareConstruction KA (рисунок 4.5) связана со всеми другими KA, но она наиболее тесно связана с KA SoftwareDesign и SoftwareTesting, потому что процесс создания программного обеспечения включает в себя трудоемкую разработку и тестирование ПО. Этот процесс использует результатыдизайна и передает свои результаты для тестирования; (слова «дизайн» и «тестирование» в этом случае относится к видам деятельности, а не к KA). Границы между дизайном, конструированием и тестированием (если таковые имеются) будут варьироваться в зависимости от процессов жизненного цикла ПО, которые используются в проекте. Хотя некоторые детализированные конструкции могут быть созданы до начала конструирования, во время этапа конструирования выполняются многие проектные работы. Таким образом, SoftwareConstruction KA тесно связан с Software KA. На протяжении всей разработки инженеры-разработчики программного обеспечения тестируют свои разработки и интегрируют их в систему.

Таким образом, KA программного обеспечения тесно связано с KA тестирования ПО. При конструировании программного обеспечения обычно производит наибольшее количество элементов конфигурации, которыми необходимо управлять в программном проекте (исходные файлы, документация, тестовые примеры и т. д.). Таким образом, KA программного обеспечения также тесно связано с KA SoftwareConfigurationManagement. Хотя качество программного обеспечения важно во всех KA, код является конечной версией программного проекта, и, таким образом, KA качества программного обеспечения тесно связано с Software KA. Поскольку разработка программного обеспечения требует знания алгоритмов и методов кодирования, она тесно связана с ComputingFoundations KA, посвященной основам компьютерной науки, которые поддерживают проектирование и построение программных продуктов. Она также связана с управлением проектами, поскольку управление конструированиемможет представлять значительные проблемы.

 

Рисунок 4.5. Структура области знаний по конструированию программного обеспечения

 

4.2.3. Тестирование программного обеспечения

Тестирование программного обеспечения состоит из динамической проверки того факта, что программа обеспечивает ожидаемое поведение в конечном наборе тестовых примеров, подходящим образом выбранном из обычно бесконечного набора. В приведенном выше определении выделенные курсивом слова соответствуют ключевым вопросам при описании области знаний тестирования программного обеспечения (рисунок 4.6):
• Динамическая: этот термин означает, что тестирование всегда подразумевает выполнение программы на выбранных наборах входов. Если быть точным, входное значение не всегда достаточно для проведения теста, поскольку сложная недетерминированная система может реагировать на один и тот же ввод с различным поведением в зависимости от состояния системы. Однако в этом KA термин «вход» означаетсоглашение, что его значение также включает заданное входное состояние в тех случаях, для которых это важно. Статические методы также рассматриваются в KA качества программного обеспечения. Они дополняют динамическое тестирование.Стоит отметить, что терминология различается среди разных сообществ, а некоторые используют термин «тестирование» также применительно к статическим методам.

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

• Выбор: многие предлагаемые методы тестирования существенно различаются в том, как выбирается тестовый набор, и разработчики программного обеспечения должны знать, что различные критерии отбора могут давать значительно различающиеся степени эффективности. Определение наиболее подходящего критериявыбора в данных условиях является сложной проблемой; на практике применяются методы анализа рисков и экспертиза программного обеспечения.

• Ожидаемое поведение: должно быть возможно, хотя и не всегда легко, решить: приемлемы ли наблюдаемые результаты тестирования программы или нет, в противном случае усилия по тестированию бесполезны. Наблюдаемое поведение может быть проверено на предмет потребностей пользователей (обычно называемое тестированием для проверки), в отношении спецификации (тестирование для проверки спецификации) или, возможно, неожиданного поведения из-за неявных требований или ожиданий (см. KA Приемочные тесты в требованиях к программному обеспечению).В последние годы созрел конструктивный взгляд на тестирование программного обеспечения. Тестирование больше не рассматривается как активность, которая начинается только после завершения фазы кодирования с ограниченной целью обнаружения сбоев. Тестирование программного обеспечения должно выполняться повсеместно на протяжении всего цикла разработки и обслуживания. В самом деле, планирование тестирования ПО должно начинаться с ранних этапов процесса определения требований к программному обеспечению, а планы и процедуры тестирования должны систематически и непрерывно развиваться – и, возможно, уточняться – по мере развития программного обеспечения. Эти мероприятия по планированию тестирования и непосредственно тестированию оказываются полезными для разработчиков ПО, они помогают выявить потенциальные недостатки, такие как ошибки в проектах, противоречия или упущения, двусмысленности в документации. Для многих организаций требования к качеству программного обеспечения является одним из способов профилактики: очевидно, что гораздо лучше предотвратить проблемы, чем исправить их. Таким образом, тестирование можно рассматривать как средство предоставления информации о функциональностии качественных атрибутов ПО, а также для выявления сбоев в тех случаях, когда предотвращение ошибок не было эффективным. Очевидно, что программное обеспечение все еще может содержать ошибки, даже после завершения обширной тестовой деятельности. Ошибки ПО, возникшие после поставки заказчику, устраняются путем корректирующего обслуживания. Темы обслуживания программного обеспечения рассматриваются в SoftwareMaintenance KA. В KA качества программного обеспечения (см. «Методы управления качеством программного обеспечения»).Методы управления качеством программного обеспечения разделяются на статические методы (без выполнения кода) и динамические (с выполнением кода). Обе категории полезны. Рассматриваемая KA фокусируется на динамических методах. Тестирование программного обеспечения также связано с разработкой программного обеспечения (см. KA «Строительное тестирование в программной конструкции»). В частности, тестирование модулей и их интеграции тесно связано с построением программного обеспечения, если оно не является его частью.

 

Рисунок 4.6. Структура области знаний по тестированию программного обеспечения

 

 

4.2.4. Сопровождениепрограммного обеспечения

Усилия по разработке программного обеспечения завершаются поставкой программного продукта, который удовлетворяет требованиям пользователя. Соответственно, программный продукт должен меняться или развиваться. После ввода в эксплуатацию обнаруживаются дефекты, происходит изменение рабочей среды и появление новых пользовательских требований. Фаза обслуживания жизненного цикла начинается после гарантийного срока или в процессе поддержки после внедрения, но операции по техническому обслуживанию происходят намного раньше. Обслуживание программного обеспечения является неотъемлемой частью жизненного цикла программного обеспечения. Однако оно не получило такой же степени внимания, как другие фазы ЖЦ (рисунок 4.7). Исторически сложилось так, что в большинстве организаций разработка программного обеспечения имеет гораздо более высокийстатус, чем его обслуживание. Это положение сейчас меняется, так как организации стремятся максимально уменьшить свои инвестиции в разработку нового ПО, стремясь сохранить при этом имеющееся программное обеспечение как можно дольше. Парадигма с открытым исходным кодом привлекла дополнительное внимание к проблеме сохранения программных артефактов, разработанных другими. В данном Руководстве сопровождение ПО определяется как совокупность действий, необходимых для обеспечения рентабельной поддержки программного обеспечения (рисунок 4.8). Мероприятия выполняются на предшествующей стадии, а такжепосле доставки. Предпусковые мероприятия включают планирование операций по доставке, оценку ремонтопригодности и логистику для перехода к эксплуатации. Деятельность по доставке включает в себя модификацию программного обеспечения, обучение, а также работу или взаимодействие со справочной службой. KA области знаний о поддержке программного обеспечения связана со всеми другими аспектами разработки ПО. Поэтому рассматриваемое описание KA связано со всеми другими KA руководства по разработке программного обеспечения.

 

Рисунок 4.7. Структура области знаний по сопровождению программного обеспечения

Рисунок 4.8. Работы по сопровождению программного обеспечения

4.2.5. Управление конфигурацией программного обеспечения

Система может быть определена как комбинация взаимодействующих элементов, организованных для достижения одного или нескольких заявленных целей []. Конфигурация системы –  это функциональные и физические характеристики аппаратного или программного обеспечения, изложенные в технической документации или достигнутые в продукте [1]; его также можно рассматривать как набор конкретных версий аппаратных средств, прошивки или программных элементов, объединенных в соответствии с конкретными процедурами сборки
для выполнения определенной цели. Таким образом, управление конфигурацией (C M, ConfigurationManagement) – это дисциплина по идентификации конфигурации системы в разные моменты времени с целью систематического управления изменениями конфигурации и поддержания целостности и отслеживания конфигурации в течение всего жизненного цикла системы. CM формально определяется как
дисциплина, применяющая техническое и административное руководство и надзор, для следующих целей:

· идентифицировать и документировать функциональные и физические характеристики элемента конфигурации,

· контролировать изменения этих характеристик,

· регистрировать и обрабатывать изменения отчета и статус реализации,

· а также проверять соответствие указанным требованиям.

Управление конфигурацией программного обеспечения (Softwareconfigurationmanagement - SCM) – это процесс жизненного цикла поддержки программного обеспечения, который обеспечивает управление проектами, разработку и обслуживание, деятельность по обеспечению качества, а также обслуживание клиентов и пользователей конечного продукта. Концепции управления конфигурацией применяются ко всем элементам, которые необходимо контролировать, хотя есть некоторые различия в реализации между аппаратным CM и программным CM. SCM тесно связан с деятельностью по обеспечению качества программного обеспечения (SoftwareQualityArea – SQA). Как определено в KA о качестве программного обеспечения, процессы SQA обеспечивают уверенность в том, что программные продукты и процессы в жизненном цикле проекта соответствуют указанным требованиям, а это достигается путем планирования, принятия и выполнения ряда мероприятий, для обеспечениядостаточной уверенности в качествепрограммного обеспечения. Деятельность SCM помогает в достижении этих целей SQA. В некоторых контекстах проекта конкретные требования SQA предписывают определенные действия SCM.

Деятельность SCM – это управление и планирование процесса SCM, идентификация конфигурации программного обеспечения, контроль конфигурации программного обеспечения, учет состояния конфигурации программного обеспечения, аудит конфигурации программного обеспечения и управление выпуском программного обеспечения. KA по управлению конфигурацией ПО относится ко всем другим KA, поскольку объектом управления конфигурацией является артефакт, созданный и используемый в процессе разработки программного обеспечения.

 

Рисунок 4.9. Структура области знаний по управлению конфигурацией программного обеспечения

 

4.2.6. Менеджмент в программной инженерии

 

Область знаний (KA) по менеджменту программного обеспечения может быть определена как применение управленческой деятельности – планирование, координация, измерение, мониторинг, контроль и отчетность – для обеспечения эффективного использования программных продуктов и программных услуг в интересах заинтересованных сторон. Связанная с ним дисциплина управления является важным элементом всех областей знаний,но, конечно, она более уместна для этой KA, чем для других KA. Измерение также является важным аспектом всех KA; тема измерительных программ представлена ​​в этом KA. В некотором смысле, должно быть возможным управлять проектом разработки программного обеспечения таким же образом, как управляются другие сложные процессы. Однако существуют специфические аспекты программных проектов и жизненного цикла программного обеспечения, которые усложняют эффективное управление, в том числе следующие:
• Клиенты часто не знают, что необходимо или что возможно.

• Клиентам часто не хватает понимания сложностей, присущих разработке программного обеспечения, особенно в отношении воздействия изменяющихся требований.

• Вероятно, что более глубокое понимание и изменение условий вызовут новые или измененные требования к программному обеспечению.

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

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

• Степень новизны и сложности часто высока.

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

Другие аспекты организационного управления оказывают влияние на разработку программного обеспечения (например, организационные политики и процедуры, которые обеспечивают структуру, в которой осуществляются проекты по разработке программного обеспечения). Возможно, эти политики и процедуры должны быть скорректированы с учетом требований для эффективной разработки и обслуживания программного обеспечения. Кроме того, для эффективного управления разработкой программного обеспечения на организационном уровне может потребоваться целый ряд политик, специфичных для разработки программного обеспечения. Например, политики обычно необходимы для создания конкретных общесистемных процессов или процедур для задач разработки программного обеспечения, таких как проектирование программного обеспечения, разработка программного обеспечения, оценка, мониторинг и отчетность. Такая политика важна для эффективного долгосрочного управления проектами в области разработки программного обеспечения во всей организации (например, создание последовательной основы для анализа эффективности выполнения предыдущих проектов и внедренияулучшений).
Еще одним важным аспектом организационного управления является политика и процедуры управления персоналом для найма, обучения и наставничества для развития карьеры не только на уровне проекта, но и для долгосрочного успеха организации. Персонал по разработке программного обеспечения может выполнять уникальные задачи по обучению или управлению персоналом (например, поддержание персонала при изменении курса валют, когда базовая технология подвергается быстрым и непрерывным изменениям). Управление связью также часто упоминается как упущенный, но важный аспект производительности отдельных лиц в области, где необходимо точное понимание потребностей пользователей, требований к программному обеспечению и программных продуктов. Кроме того, желательно управление портфелем, которое обеспечивает общее представление не только о программном обеспечении, которое в настоящее время разрабатывается в различных проектах и ​​программах (комплексные проекты), но и о программном обеспечении, которое планируется и в настоящее время используется в организации. Кроме того, повторное использование программного обеспечения является ключевым фактором поддержания и повышения производительности и конкурентоспособности. Эффективное повторное использование требует стратегического видения, которое отражает преимущества и недостатки повторного использования. В дополнение к пониманию аспектов управления, которые однозначно влияют на проекты программного обеспечения, разработчики программного обеспечения должны иметь некоторые знания об общих аспектах управления, которые обсуждаются в этой KA (даже в первые несколько лет после окончания обучения). Атрибуты организационной культуры и поведения, а также управление другими функциональными областями предприятия оказывают влияние, хотя и косвенно, на процессы разработки программного обеспечения организации.

 

4.2.7. Процесс программной инженерии

 

Инженерный процесс состоит из набора взаимосвязанных видов деятельности, которые преобразуют один или несколько входов в выходы при потреблении ресурсов, необходимых для осуществления преобразования. Многие из процессов традиционных инженерных дисциплин (например, электрических, механических, экономических, химических) связаны с преобразованием энергии и физических объектов из одной формы в другую, как в гидроэлектростанции, которая преобразует потенциальную энергию воды в электрическую энергию или нефтеперерабатывающий завод, использующий химические процессы для превращения сырой нефти в бензин. В KA этой области знаний процессы разработки программного обеспечения связаны с работой, выполняемой разработчиками программного обеспечения для разработки, сопровождения и управления программным обеспечением, таких процессов, как требования, проектирование, разработка, тестирование, управление конфигурацией и другие процессы разработки программного обеспечения. Для удобства чтения, в этом KA«процесс разработки программного обеспечения»будет называться «программным процессом». Кроме того, обратите внимание, что «программный процесс» означает рабочие действия, а не процесс использования внедренного программного обеспечения. Программные процессы определены по ряду причин: для облегчения понимания людьми, общения и координации; для содействия управлению проектами программного обеспечения; для эффективного и качественного измерения качества программных продуктов; для поддержки улучшения процесса; обеспечение основы для автоматизированной поддержки процесса выполнения. SWEBOK KA, тесно связанный с этим процессом разработки ПО, включают в себя управление программным обеспечением, модели и методы разработки программного обеспечения, а также качество программного обеспечения. Раздел «Анализ и определение коренных причин», входящий в технические основания KA, также тесно связан с процессом. SoftwareEngineeringManagement занимается настройкой, адаптацией и внедрением программных процессов для конкретного программного проекта (см. «Планирование процесса в SoftwareEngineeringManagement KA»). Модели и методы поддерживают системный подход к разработке и модификации программного обеспечения. Качество программного обеспечения KA связано с процессами планирования, обеспечения и контроля качества проекта и продукта. Результаты измерений в инженерных фондах KA необходимы для оценки и контроля процессов программного обеспечения.

 

Рисунок 4.10. Структура области знаний по процессам программной инженерии

 

 

4.2.8. Инструменты и методы программной инженерии

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

• Моделирование: обсуждается общая практика моделирования и дается представлениео принципах моделирования; свойствах и видах моделей; синтаксисе моделирования, семантике и прагматике, предпосылках, постусловиях и инвариантах.

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

• Анализ моделей: представлены некоторые общие методы анализа, используемые в моделировании, для проверки полноты, последовательности, правильности, прослеживаемости и взаимодействия.

• Методы разработки программного обеспечения: представлен краткий обзор широко используемых методов разработки программного обеспечения. Обсуждаетсясравнение эвристических методов, формальных методов, прототипирования и гибких методов.
Разбивка тем для моделей и методов разработки программного обеспечения KA показана на рисунке 4.11.

Рисунок 4.11 Структура области знаний по инструментам и методам программной инженерии

4.2.9 Качество ПО

Что такое качество программного обеспечения и почему так важно, чтобы это понятие было включено во многие области знаний (KA) Руководства SWEBOK?

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

На протяжении многих лет авторы и организации определяли термин качество по-разному. Для Фила Кросби это было «соответствие требованиям» []. Уоттс Хамфри называет его «достижением отличных уровней«пригодности для использования»[]. Между тем, IBM придумала термин «рыночное качество», где«клиент является конечным арбитром»[]. Совсем недавно качество программного обеспечения стало определяться как «способность программного продукта удовлетворять заявленным и подразумеваемым потребностям в определенных условиях» [4] и как «степень соответствия программного продукта установленным требованиям»; однако качество зависит от того, насколько эти установленные требования точно отражают потребности, желания и ожидания заинтересованных сторон [5]. Оба определения содержатт предпосылку соответствия требованиям. Но ни одно из них не относится к типам требований (например, функциональность, надежность, производительность или любые другие характеристики). Примечательно, однако, что эти определения подчеркивают, что качество зависит от требований. Эти определения также иллюстрируют еще одну причину распространенности термина о качестве программного обеспечения в настоящем Руководстве: частая неоднозначность термина качества программного обеспечения по сравнению с требованиями к качеству программного обеспечения. Требования к качеству программного обеспечения на самом деле являются атрибутами (или ограничениями) функциональных требований (что делает система). Программные требования могут также указывать использование ресурсов, протокол связи или многие другие характеристики.

В нашем изложении KA используетсяопределение качества программного обеспечения в широком смысле на основе приведенных выше определений,и определяются требования к качеству программного обеспечения в виде ограничений функциональных требований. Качество программного обеспечения достигается за счет соответствия всем требованиям независимо от того, какая характеристика указана или как сгруппированы,или названы требования. Качество программного обеспечения также рассматривается во многих KASWEBOK, потому что это основной параметр оценки усилий по разработке программного обеспечения. Для всех инженерных продуктов основная цель – обеспечить максимальную ценность для заинтересованных сторон, одновременно балансируя ограничения затрат и графика разработки; это иногда характеризуется как «пригодность для использования». Значение заинтересованности выражается в требованиях. Для программных продуктов заинтересованные стороны могут оценивать цену (то, что они платят за продукт), время выполнения (как быстро они получают продукт) и качество программного обеспечения. ЭтаKA  даетопределения и обзор практик, инструментов и методов для определения качества программного обеспечения и его оценки во время разработки, обслуживания и развертывания. В приведенных ссылках даются дополнительные сведения.

Рисунок 4.12. Структура области знаний по качеству ПО

 

4.2.10. Профессиональная практика программной инженерии

Область знаний о профессиональной практике KASoftwareEngineering связана с знаниями, навыками и отношениями, которыми должны обладать разработчики программного обеспечения, чтобы вести разработку программного обеспечения на профессиональной, ответственной и этичной основе. Из-за широкого применения программных продуктов в социальной и личной жизни качество программных продуктов может оказать глубокое влияние на наше личное благополучие и социальную гармонию. Инженеры-разработчики программного обеспечения должны решать уникальные техническиепроблемы,производить программное обеспечение с известными характеристиками и надежностью. Это требование относится к инженерам-программистам, которые обладают надлежащим набором знаний, навыков, образования и опыта в профессиональной практике. Термин «профессиональная практика» относится к способу оказания услуг, чтобы достичь определенных стандартов или критериев как в процессе выполнения услуги, так и в конечном продукте, являющемся результатом обслуживания. Эти стандарты и критерии могут включать как технические, так и нетехнические аспекты. Понятие профессиональной практики можно рассматривать как более применимое в тех профессиях, которые имеют общепринятую совокупность знаний; кодексы этики и профессионального поведения с наказаниями за нарушения; принятые процессы аккредитации, сертификации и лицензирования; и профессиональные общества, чтобы обеспечить и управлять всеми этими компонентами. Прием в эти профессиональные общества часто основывается на предписанной комбинации образования и опыта. Инженер-программист поддерживает профессиональную практику, выполняя всю работу в соответствии с общепринятыми практиками, стандартами и руководящими принципами, специально изложенными одним из профессиональных обществ. Например, Ассоциация вычислительной техники (ACM) и IEEE ComputerSociety (IEEE CS) создали Кодекс этики и профессиональной практики в области программного обеспечения. Также Британское компьютерное общество (БКС), и Международная федерация по обработке информации (ИФИП) установили аналогичные стандарты профессиональной практики. ISO / IEC и IEEE также предоставили международно признанные стандарты разработки программного обеспечения (см. Приложение B настоящего Руководства). IEEE CS создала две международные сертификационные программы (CSDA, CSDP) и соответствующее Руководство для Группы знаний по программному обеспечению (Руководство SWEBOK). Все это элементы, лежащие в основе профессиональной практики разработки программного обеспечения

Фиг. 4.1 Структура области знаний по качеству профессиональной практике в программной инженерии

5. Экономика программной инженерии

Экономика разработки программного обеспечения заключается в принятии решений, связанных с разработкой программного обеспечения в бизнес-контексте. Успех программного продукта, сервиса и решения зависит от хорошего управления бизнесом. Тем не менее, во многих компаниях и организациях отношения с программным бизнесом к разработке и разработке программного обеспечения остаются неопределенными. Эта область знаний (KA) представляет собой обзор по экономике программного обеспечения. Экономика - это изучение стоимости, затрат, ресурсов и их отношений в данном контексте или ситуации. В процессе разработки программного обеспечения мероприятия имеют свои затраты, и в результате программное обеспечение также имеет экономические характеристики. Экономика в области разработки программного обеспечения позволяет систематически изучать атрибуты программных процессов, которые связывают их с экономическими мерами. Эти экономические меры можно взвешивать и анализировать при принятии решений, которые входят в сферу действия программной организации и тех, которые входят в единую сферу деятельности всего производственного или приобретающего бизнеса. Экономика разработки программного обеспечения связана с согласованием технических решений программного обеспечения сбизнес-целей организации. Во всех типах организаций - будь то «коммерческая», «некоммерческая» или правительственная - это означает устойчивое пребывание в бизнесе. В «коммерческих» организациях это дополнительно относится к достижению ощутимой отдачи от инвестированного капитала - как активов, так и капитала. Этот KA был разработан таким образом, чтобы охватить все типы организаций, не зависящие от профиля, портфеля продуктов и услуг, ограничений на владение капиталом и налогообложения. Решения типа «Должны ли мы использовать конкретный компонент?» могут выглядеть легко с технической точки зрения, но могут иметь серьезные последствия для деловой жизнеспособности программного проекта и полученного продукта. Часто инженеры задаются вопросом: относятся ли к ним такие проблемы вообще, поскольку они «только инженеры». Экономический анализ и принятие решений являются важными инженерными соображениями, поскольку инженеры способны оценивать решения как технически, так и с точки зрения бизнеса. Содержание этойобласти знаний является важным для разработчиков программного обеспечения, даже если они никогда не участвуют в конкретных бизнес-решениях; у них будет хорошо продуманный взгляд на деловые вопросы и роль технических соображений в принятии бизнес-решений. Многие инженерные предложения и решения, такие как выбор варианта покупки, имеют глубокие внутренние экономические последствия, которые следует рассматривать в явном виде. Эта KA сначала охватывает основы, ключевую терминологию, базовые концепции и общие практики в области разработки программного обеспечения, чтобы указать, как включать принятие решений в разработку программного обеспечения или включать бизнес-перспективу. Затем она предоставляет перспективу жизненного цикла, выделяет управление рисками и неопределенностями и показывает, как используются методы экономического анализа. Некоторые практические соображения завершают описание области знаний.

Фиг. 4.1 Структура области знаний по экономике программной инженерии

13.Компьютерные основы программной инженерии

Объем области знаний вычислительных средств (KA) включает в себя разработку и операционную среду, в которой программное обеспечение развивается и выполняется. Поскольку никакое программное обеспечение не может существовать в вакууме или работать без компьютера, ядром такой среды является компьютер и его различные компоненты. Знания о компьютере и его основополагающих принципах аппаратного и программного обеспечения служат основой для разработки программного обеспечения. Таким образом, все разработчики программного обеспечения должны хорошо понимать область знаний Основы вычислений. Общепризнано, что разработка программного обеспечения основывается на информатике. Например, «SoftwareEngineering 2004: Руководство по учебным программам для программ бакалавриата в области разработки программного обеспечения» [1] четко гласит: «Одним из особенно важных аспектов является то, что разработка программного обеспечения основывается на компьютерных науках и математике».

Стив Токей написал в своей книге ReturnonSoftware:«И компьютерная наука, и разработка программного обеспечения связаны с компьютерами, вычислительной техникой и программным обеспечением. Наука вычисления, как совокупность знаний, лежит в их основе. Разработка программного обеспечения связана с применением компьютеров, вычислительной техники и программного обеспечения в практических целях, в частности, при проектировании, строительстве и эксплуатации эффективных и экономичных программных систем.»
Таким образом, в основе разработки программного обеспечения лежит понимание информатики. В то время как мало кто откажется от роли компьютерных наук в разработке программного обеспечения как в качестве дисциплины, так и в качестве совокупности знаний, нельзя переоценить важность информатики для разработки программного обеспечения; таким образом, этим определяетсяважностьКА по вычислительным основам.

Большинство тем, обсуждаемых в ComputingFoundations KA, также являются темами обсуждения на базовых курсах, которые выходят в области компьютерных и магистерских программ. Такие курсы включают программирование, структуру данных, алгоритмы, компьютерную организацию, операционные системы, компиляторы, базы данных, сети, распределенные системы и т. Д. Таким образом, может возникнуть соблазн разложить ComputingFoundations KA в соответствии с этими часто встречающимися подразделениями в соответствующих курсах. Тем не менее, чистое разделение по темам имеет серьезные недостатки. Во-первых, не все курсы по информатике связаны или не менее важны для разработки программного обеспечения. Таким образом, некоторые темы, которые в противном случае были бы рассмотрены в ходе курса по информатике, не рассматриваются в этомKA. Например, компьютерная графика, являясь важным курсом в области компьютерной науки, не входит в эту KA. Во-вторых, некоторые темы, обсуждаемые в этом руководстве, не существуют как самостоятельные курсы по программам бакалавриата или выпускника компьютерных наук. Следовательно, такие темы не могут быть надлежащим образом охвачены в чисто разбивке на основе курса. Например, абстракция - это тема, включенная в несколько различных курсов по информатике; неясно, какая абстракция курса должна принадлежать в разбивке по темам на основе курса. KA Основы вычислений разделены на семнадцать разных тем. Прямая полезность темы для разработчиков программного обеспечения - это критерий, используемый для выбора тем для включения в эту KA (см. Рис. 13.1). Преимущество этой тематической разбивки - это основание полагать, что ComputingFoundations– если ее нужно твердо воспринимать – следует рассматривать как совокупность логически связанных тем, в основе которых лежит разработка программного обеспечения в целом и разработка программного обеспечения в частности. KA Основы вычислений тесно связаны с разработкой программного обеспечения, разработкой программного обеспечения, тестированием программного обеспечения, обслуживанием программного обеспечения, качеством программного обеспечения и математическими базами KA.

Фиг. 4.1 Структура области знаний по компьютерным основам программной инженерии

14. Математические основы программной инженерии

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

Математика, в некотором смысле, является изучением формальных систем. Слово «формальное» связано с точностью, поэтому не может быть какой-либо двусмысленной или ошибочной интерпретации некоторого факта. Математика – это изучение отдельных и всех свойств какого-либо понятия. Эта может относиться к числам, символам, изображениям, звукам, видео – почти ко всему. Короче говоря, не только цифры и вычисления подчиняются точности. Напротив, инженер-программист должен иметь представление об абстракции в разнообразных областях приложений. KA Математические основы руководства SWEBOK охватывает основные методы определения набора правил для рассуждений в контексте исследуемой системы. Все, что можно вывести по этим правилам, является абсолютной определенностью в контексте этой системы. В этой KA определяются и обсуждаются методы, которые позволяют инженеру-программисту рассуждать точным (и, следовательно, математическим) стилем. Язык и методы логики, которые обсуждаются здесь, позволяют описать способ математических доказательства,которые позволяют установить истину,не прибегая к числам. Короче говоря, вы сможете написать программу для задачи, только если она будет следовать некоторой логике. Цель этогй KA - помочь вам развить навык идентификации и описания такой логики. Акцент делается на то, чтобы помочь вам понять основные понятия, а не оспаривать ваши арифметические способности.

Фиг. 4.1 Структура области знаний по математическим основам программной инженерии

 

15. Инженерные основы программной инженерии

IEEE определяет технику как «применение систематического, дисциплинированного, количественного подхода к структурам, машинам, продуктам, системам или процессам» [1]. В этой главе описываются некоторые инженерные навыки и методы, которые полезны для инженера-программиста. Основное внимание уделяется тем из них, которые поддерживают другие KA, одновременно сводя к минимуму дублирование тем, рассмотренных в другом месте этого документа. По мере развития теории и практики разработки программного обеспечения становится все более очевидным, что разработка программного обеспечения – это инженерная дисциплина, основанная на знаниях и навыках, общих для всех инженерных дисциплин. Эта (KA) – область знаний инженерных основ, которые применяются при разработке программного обеспечения и в других инженерных дисциплинах. Темы этой KA включают эмпирические методы и экспериментальные методы; статистический анализ; измерение; инженерный дизайн; моделирование, прототипирование и моделирование; стандарты; анализ основных причин. Применение этих знаний, в случае необходимости, позволит разработчикам программного обеспечения разрабатывать и поддерживать программное обеспечение более эффективно. А выполнение своих работ эффективно и успешно является целью всех инженеров во всех инженерных дисциплинах.

Фиг. 4.1 Структура области знаний по инженерным основам программной инженерии

 

Приложения к SWEBOK V.3

Для облегчения работы с Руководством SWEBOK авторы предлагают три Приложения. Мы, как и раньше, ограничимся только аннотациями к этим документам.

Приложение А

Описание спецификаций областей знаний

В этом документе представлены спецификации, предоставленные редакторами областей знаний (редакторами KA) версии 3 (V3) Руководства по созданию знаний по программному обеспечению (руководство SWEBOK). Этот документ также позволит читателям, рецензентам и пользователям четко понимать, какие спецификации были использованы при разработке этой версии руководства SWEBOK.

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

 

Приложение B

Стандарты IEEE и ISO / IEC, поддерживающие программное обеспечение свода знаний (SWEBOK)

Иногда говорят, что предложение стандартов разработки программного обеспечения намного превышает спрос. Это, конечно, не шутка. Обилие стандартов создает очень большое (практически бесконечное) множество альтернатив, из которого нужно выбрать меньшее число вариантов.Содной стороны – это благо, поскольку можно выбрать необходимый профиль стандартов, наиболее подходящий для разрабатываемого проекта системы, но, с другой стороны, работа с десятками предлагаемых стандартов достаточно сложна. Для облегчения этой проблемы могут быть полезны рекомендации, которые приводятся в данном приложении. В конце документа приводится сводный список стандартов, упомянутых в этом приложении (около 70). Чтобы облегчить чтение, в этом приложении сделаны некоторые упрощенияи сокращения.

 

Приложение C

Консолидированный справочный список

В сводном справочном списке указаны все рекомендуемые справочные материалы (до уровня номера раздела), которые сопровождают разбивку тем в каждой области знаний (KA). Этот консолидированный справочный список принимается сертификацией программного обеспечения и соответствующими продуктами для профессионального развития, предлагаемыми IEEE ComputerSociety. Редакторы KA использовали ссылки, присвоенные их разделам знаний, в виде сводного списка ссылок и рекомендуют их использовать.

 

 

Заключение

Список литературы

1. Гуд Г. X., Макол Р. Э. Системотехника. Введение в проектирование больших систем. - М: Советское радио, 1962. - 383 с.

2. Липаев В. А. Программная инженерия. Основы методологии. - М.: Теис, 2006 - 609 с.

3. Батоврин В.К. Толковый словарь по системной и программной инженерии: учеб. пособие для вузов. – М.: ДМК Пресс. 2012. – 280 с.

4. Орлик С. Введение в программную инженерию и управление жизненным циклом ПО http://sorlik.blogspot.com

5. ЛоусонГ. Путешествие по системному ландшафту http://www.litres.ru/pages/biblio_book/?art=10316387

6. Левенчук А.И. Системноинженерное мышление в управлении жизненным циклом https://vk.com/sistemnaya_inzheneriya_levenchuk

7. Моисеев Н.Н. Математические задачи системного анализа. М.: Наука. 1981. – 488 с.

8. Советов Б.Я., Яковлев С.А. Моделирование систем. М.: Высшая школа, 1995. – 350с.

9. Антонов А.В. Системный анализ. Учебник для вузов. М.: Высшая школа, 2004. – 454 с.

10. Сухомлин В.А. Введение в анализ информационных технологий. Учебник для вузов. М.: Горячая линия – Телеком. 2003. – 427 с.

11. Доррер Г.А. Теория информационных процессов и систем. Учебное пособие для студентов вузов, обучающихся по направлению 230200 Информационные системы. Красноярск: СибГТУ, 2010. – 242 с.

12. Checland, P.B. Models Validation in Soft Systems Practice –System Research, 1995. Vol. 12. № 1. P. 47 – 54.

13.

 

О принятии решений

Если мы предположим, что решения кандидатов разрешают
данная техническая проблема одинаково хорошо, почему
организация, которая выбрана?
Ответ заключается в том, что обычно существует большая разница
в расходах и доходах от различных
решения. Коммерческий, готовый, objectrequest
брокерский продукт может стоить несколько тысяч
долларов, но усилия по развитию доморощенных
служб, которые дают такую ​​же функциональность, может
легко стоить в несколько сот раз больше этой суммы.
Если решения кандидата все адекватно решат
проблема с технической точки зрения, то
выбор наиболее подходящей альтернативы
должны основываться на коммерческих факторах, таких как
оптимизации общей стоимости владения (TCO) или
максимизация краткосрочной отдачи от инвестиций
(ROI). Затраты на жизненный цикл, такие как коррекция дефектов,
полевые службы и продолжительность поддержки также актуальны
соображения. Эти затраты необходимо учитывать
при выборе между приемлемыми техническими
подходы, поскольку они являются частью срока службы
ROI (см. Раздел 4.3 «Возврат инвестиций»).
Систематический процесс принятия решений будет
добиться прозрачности и дать более позднее обоснование.
Критерии управления во многих организациях
выбор спроса по меньшей мере из двух альтернатив.
Систематический процесс показан на рисунке 12.3.
Он начинается с бизнес-задачи под рукой и
описывает шаги для идентификации альтернативных решений,
определять критерии отбора, оценивать решения,
реализовать одно выбранное решение и контролировать
производительность этого решения.
На рисунке 12.3 показан процесс, в основном пошаговый
и серийный. Реальный процесс более жидкий.
Иногда шаги могут выполняться в другом
порядок, и часто можно выполнить несколько шагов
и при этом ни  один из шагов не пропущен или не свернут. Это также
важно понять, что этот же процесс
применяется на всех уровнях принятия решений: от
решение, определяющее, является ли программное обеспечение
проект должен быть сделан вообще, к решению о
алгоритм или структура данных для использования в программном обеспечении
модуль. Разница заключается в том, как финансово значимые
решение есть и, следовательно, сколько
следует приложить усилия для принятия этого решения.
Решение на уровне проекта является финансово значимым
и, вероятно, требует относительно высоких
уровень усилий для принятия решения. Выбор
алгоритм часто гораздо менее материально значим
и требует гораздо более низкого уровня усилий для
принять решение, хотя тот же базовый
процесс принятия решений используется.
Чаще всего организация могла
выполнить более одного предложения, если он захочет
к, и обычно существуют важные отношения
среди предложений. Возможно, предложение Y может быть
осуществляется, если также предлагается Предложение X. Или
возможно, предложение P не может быть выполнено, если предложение
Q, и не может быть выполнено Q
если P был. Выбор намного проще сделать, когда
существуют взаимоисключающие пути - например,
либо A, либо B, либо C или что угодно. При подготовке
решений, рекомендуется
данный набор предложений, а также их различные
взаимосвязи, в набор взаимоисключающих
альтернативы. Затем выбор можно сделать
среди этих альтернатив.

В абстрактном смысле процесс принятия решений -
будь то принятие финансовых решений или иное,
о максимизации ценности. Альтернатива, которая
максимальная общая стоимость всегда должна быть выбрана.
Финансовая основа для стоимостного сравнения
сравнивая два или более денежных потока. Несколько баз
сравнения, в том числе
• настоящая стоимость
• будущая стоимость
• годовой эквивалент
• Внутренняя норма доходности
• (дисконтированный) срок окупаемости.
Исходя из временной стоимости денег, двух или более
денежные потоки эквивалентны только тогда, когда они равны
такая же сумма денег в общей точке
во время. Сравнение денежных потоков имеет смысл
когда они выражаются в одном и том же временном интервале.
Обратите внимание, что значение не всегда может быть выражено в
денежные средства. Например, будет ли элемент
является торговой маркой или нет, может существенно повлиять
его воспринимаемой ценности. Соответствующие значения, которые не могут
выражаться в денежном выражении по-прежнему необходимо
выраженные в аналогичных выражениях, чтобы они могли быть
оценивается объективно.