Минимизация сложности программного обеспечения

Минимизация сложности программного обеспечения

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

 

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

 

Достигается:

 

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

 

Ожидание изменений в программном обеспечении как фактор, влияющий на конструирование ПО

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

Конструирование ПО с возможностью проверки

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

Методы достижения

 

· обзор, оценка кода (code review)

· модульное тестирование (unit-testing)

· структурирование кода для и совместно с применениям автоматизированных средств тестирования (automated testing)

· ограниченное применение сложных или тяжелых для понимания языковых структур

 

Стандарты в конструировании ПО (Standards in Constructing)

Стандарты, которые напрямую применяются при конструировании, включают:

коммуникационные методы (например, стандарты форматов документов и оформления содержания)

языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка программирования Java)

платформы (например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows - Win32 API, Application Programming Interface или.NET Framework SDK, Software Development Kit)

Модели конструирования (Construction Models)

Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В большинстве случаев, модели конструирования определяются используемым стандартом жизненного цикла, применяемыми методологиями и практиками. Некоторые стандарты жизненного цикла, по своей природе, являются ориентированными на конструирование – например, экстремальное программирование (XP- eXtreme Programming). Также следует рассмотреть конструирование в неразрывной связи с проектированием (в части моделирования), например, RUP (Rational Unified Process).

Планирование конструирования (Construction Planning)

Планирование конструкторской деятельности определяет порядок, в котором создаются компоненты и другие активы данной области знаний (фазы деятельности), проводятся работы по обеспечению качества получаемого программного обеспечения, распределяются* задачи и соответствующие ресурсы, в том числе, определяются назначения/отображения работ конкретным инженерам-программистам, членам проектной группы. Все это происходит, следуя правилам, определяемым используемым методом (методологией, практиками и т.п.).

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

Интеграция (Integration) ПО

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

Кроме упомянутых аспектов интеграции, к обсуждаемым интеграционным вопросам конструирования относятся:

· планирование последовательности, в которой интегрируются компоненты;

· обеспечение поддержки создания промежуточных версий программного обеспечения;

· задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент;

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

Ядро знаний SWEBOCK

На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех

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

В связи с этим мировое компьютерное сообщество пришло к необходимости

систематизации накопленных знаний и общие из них зафиксировать в виде ядер

знаний (Body of Knowledge – BOK) для разных областей информатики [19]. Для

создания ядра знаний ПО был создан международный комитет при американском

объединении компьютерных специалистов ACM (Association for Computing

Machinery) и институте инженеров по электронике и электротехнике IEEE Computer

Society. В комитет вошли специалисты мирового уровня в области информатики и

разработки ПО, которые внесли свой опыт и знания, а также систематизировали

накопленные разнородные знания и определили (1999г., 2001г., 2004г.) ядро

профессиональных знаний SWEBOK (Software Engineering Body Knowledge)

программной инженерии [20], как основы проектирования ПО. Ядро включает сумму

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

отдельные процессы проектирования ЖЦ ПО и методы их поддержки.

18 Определение дисциплины программная инженерия

Программная инженрия (Software Engineering) является отраслью компьютерной

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

закономерности развития в ней знаний, обобщает накопленный опыт

программирования в виде комплексов общих знаний и правил регламентации

инженерной деятельности разработчиков ПО.

Как инженерная дисциплина охватывает все аспекты создания ПО, начиная от

разработки требований до создания, сопровождения и снятия с эксплуатации ПО, а

также оценку трудозатрат, производительности и качества.

Инженерия изменений программных продуктов выполняется методами реинжинерии,

реверсной инженерии (перепрограммирование) и рефакторинга программных

компонентов и интерфейсов. Применение готовых продуктов (модулей, программ,

систем и т.п.) в новых разработках привело к их инженерии, при которой компоненты

становятся коммерческим продуктом, приносят прибыль разработчикам и сокращают

затраты при создании новых систем за счет их накопления в репозитариях или

электронных библиотеках.

Программостроение больших программных проектов становится инженерным по своей

сути.

Нотации проектирования

позволяют представить артефакты ПО и его структуру, а

также поведение системы. Существует два типа нотаций: структурные, поведенческие

и множество различных их представлений.

Структурные нотации являются графическими, они используются для представления

структурных аспектов проектирования, компонентов и их взаимосвязей, элементов

архитектуры и их интерфейсов. К ним относятся формальные языки спецификаций и

проектирования: ADL (Architecture Description Language), UML (Unified Modeling

Language), ERD (Entity–Relation Diagrams), IDL (Interface Description Language), классы

и объекты, компоненты и классы (CRC Cards), Use Case Driven и др. Нотации

включают языки описания архитектуры и интерфейса, диаграммы классов и объектов,

диаграммы сущность-связь, компонентов, развертывания, а также структурные

диаграммы и схемы.

Поведенческие нотации отражают динамический аспект поведения систем и их

компонентов. Таким нотациям соответствуют диаграммы: Data Flow, Decision Tables,

Activity, Colloboration, Pre-Post Conditions, Sequence, таблицы принятия решений,

формальные языки спецификации, языки проектирования PDL и др.

33 Стратегия и методы проектирования ПО. Данный раздел знаний представляет

различные стратегии и методы, которые используются при проектировании. К общим

стратегиям относятся: снизу-вверх, сверху–вниз, абстракции, паттерны и др.

Функционально–ориентированные (структурные) методы базируются на структурном

анализе, структурных картах, Dataflow-диаграммах и др. Они ориентированы на

идентификацию функций и их уточнение сверху–вниз, после чего проводится

разработка диаграмм потоков данных и описание процессов. В обьектно–

ориентированном проектировании ключевую роль играет наследование, полиморфизм

и инкапсуляция, а также абстрактные структуры данных и отображение объектов [30]

Подходы, ориентированные на структуры данных, базируются на методе Джексона

(Jackson) [8] и используются для задания входных и выходных данных структурными

диаграммами.

Компонентное проектирование ориентировано на использование и интеграцию

компонентов (особенно компонентов повторного использования) и на их интерфейс,

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

программирования, в том числе сервисно-ориентированного, в котором группы

компонентов обеспечивают функциональный сервис. К другим методам относятся:

формальные, точные и трансформационные методы, а также UML для моделирования

архитектурных решений с помощью диаграмм [31].

Виды тестирования ПО

К видам тестирования относятся:

– функциональное тестирование, которое заключается в проверке соответствия

выполнения специфицированных функций;

– регрессионное тестирование – тестирование системы или ее компонентов после

внесения в них изменений;

– тестирование эффективности – проверка производительности, пропускной

способности, максимального объема данных и системных ограничений в соответствии

со спецификациями требований;

– нагрузочное (стресс) тестирование – проверка поведения системы при максимально

допустимой нагрузке или при превышении;

– альфа и бета-тестирование – внутреннее и внешнее тестирование системы. Альфа –

без плана, бета с планом тестирования;

– тестирование конфигурации – проверка структуры и идентификации системы на

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

К видам тестирования относятся также подходы и методы проверки поведения

системы на этапе испытания ПО и приемки в соответствии с требованиями и

заданными параметрами относительно состава ПО, количества и типа компьютеров,

среды и ОС.

Техники тестирования ПО

:

– «белый (стеклянный) ящик», основанный на задании информации о структуре ПО

или системе;

– «черный ящик», основанный на задании тестовых наборов данных для проверки

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

– основанные на спецификациях, анализе граничных значений, таблицах принятия

решений, критериев потоков данных, статистики отказов и др.;

– основанные на использовании блок–схем, по которым строятся программы и наборы

тестов для покрытия всех условий выполнения частей системы и системы в целом;

– на основе обнаруженных дефектов, условий использования, природы и особенностей

приложения и др.

Управление тестированием ПО

:

– планирование процесса тестирования (составление планов, тестов, наборов данных) и

измерение показателей качества ПО;

– проведение тестирования reuse-компонентов и паттернов, как основных объектов

сборки ПО;

– генерация необходимых тестовых сценариев, соответствующих среде выполнения

ПО;

– верификация правильности реализации системы и валидация реализованных

требований к ПО;

– сбор данных об отказах, ошибках и др. непредвиденных ситуациях при выполнении

программного продукта;

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

Стандарт ISO/IEC, ГОСТ 12207 не выделяет деятельность по тестированию в качестве

самостоятельного процесса, а рассматривает тестирование, как необъемлемую часть

ЖЦ.

 

Эволюция ПО.

Известный специалист в области ПО Леман (1970г.) предложил

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

поскольку сданная в эксплуатацию система не всегда является полностью завершенной,

ее надо изменять в течение срока эксплуатации. В результате программная система

становиться более сложной и плохо управляемой, возникает проблема уменьшения ее

сложности. К техникам эволюции ПО относятся реинженерия, реверсная инженерия и

рефакторинг.

Реинженерия – это улучшение возможностей, функций в устаревшем ПО путем его

реорганизации и реструктуризации, перепрограммирования или настройка на другую

платформу или среду с обеспечением удобства его сопровождения

Реверсная инженерия состоит в восстановлении спецификации (графов вызовов,

потоков данных и др.) по полученному коду системы (особенно, когда в нее внесено

много изменений) для наблюдения за ней на более высоком уровне. Восстанавливается

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

перестройки системы к новой форме.

Рефакторинг ориентирован на улучшение структурных характеристик и качественных

показателей объектно-ориентированных программ без изменения их поведения. Этот

процесс реализуется путем изменения отдельных операций над текстами,

интерфейсами, средой программирования и выполнения ПО, а также настройки или

внесения изменений в инструментальные средства поддержки ПО. Если сохраняется

форма существующей системы при изменении, то рефакторинг – один из вариантов

обратной инженерии.

 

41 Управление конфигурацией ПО (Software Configuration Management–

SCM)

Управление конфигурацией – дисциплина идентификации компонентов системы,

определения функциональных и физических характеристик аппаратного и

программного обеспечения для проведения контроля внесения изменений и

трассирования конфигурации на протяжении ЖЦ. Это управление соответствует

одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим

и административным руководством проекта и заключается в контроле указанных

характеристик конфигурации системы и их изменении; составления отчета о

внесенных изменениях в конфигурацию и статус их реализации; проверки

соответствия внесенных изменений заданным требованиям.

Конфигурация системы – состав функций, программных и физических характеристик

программ или их комбинаций, аппаратного обеспечения, обозначенные в технической

документации системы и реализованные в продукте.

Конфигурация ПО включает набор функциональных и физических характеристик ПО,

заданных в технической документации и достигнутых в готовом продукте. Т.е это

сочетание разных элементов продукта вместе с заданными процедурами сборки и

отвечающие определенному назначению. Элемент конфигурации – график разработки,

проектная документация, исходный и исполняемый код, библиотека компонентов,

инструкции по установке системы и др.

Каскадная модель ЖЦ

 

Одной из первых начала применяться каскадная или водопадная модель, в которой

каждая работа выполняется один раз и в том порядке, как они представлены в схеме

модели ЖЦ. Т.е. делается предположение, что каждая работа будет выполнена

настолько тщательно, что после ее завершения и перехода к следующему этапу

возвращения к предыдущему не потребуется. Разработчик проверяет промежуточный

результат разными известными методами верификации и фиксирует его в качестве готового эталона для следующего этапа

Инкрементная модель ЖЦ

 

Эту заложена еще называют нарастающей моделью, суть которой состоит в

возможности усовершенствования продукта. Разработка начинается с

предоставления набора требований и реализации системы путем последовательного

конструирования и фиксации промежуточных продуктов (1, …, N) системы,

постепенно приближающейся к итоговой системе.

 

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

последующую структуру добавляют дополнительные требования и так до тех пор,

пока не будет окончательно согласованы требования и соответственно разработка

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

необходимые процессы, работы и задачи, например, анализ требований и создание 52

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

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

квалификационные испытания ПС выполняются при создании каждой последующей

структуре.

 

Данную модель разработки целесообразно использовать, в случае когда:

– желательно реализовать некоторые возможности системы быстро за счет создания

промежуточного продукта;

– система разделена на отдельные составные части структуры, которые можно

представлять как некоторый промежуточный продукт;

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

Спиральная модель

 

Исходя из возможности внесения изменений как в процесс, так и в создаваемый

промежуточный продукт была создана спиральная модель.

.

Данная модель ЖЦ допускает анализ продута на витке разработки, его проверку,

оценку его правильности и принятия решения двигаться на следующий виток или

опуститься на нижний для доработки.

 

Отличие этой модели от каскадной модели состоит в возможности спиральной модели

обеспечивать многоразовое возвращение к процессу формулирования требований и к

повторной разработке с любого процесса выполнения работ. 54

На изображенной спиральной модели (рис.2.3), каждый виток спирали соответствует

одной из версий разработки системы. При необходимости внесения изменений в

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

вносятся изменения в предварительно зафиксированные требования, после чего

происходит возврат на предыдущий виток спирали для продолжения реализации

новой версии системы с учетом изменений.

Эволюционная модель ЖЦ

 

В случае эволюционной модели система разрабатывается в виде последовательности

блоков структур (конструкций). В отличие от инкрементной модели ЖЦ,

подразумевается, что требования устанавливаются частично и уточняются в каждом

последующем промежуточном блоке структуры системы

Работы и задачи процесса разработки в соответствии с данной моделью выполняются

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

Так как промежуточные блоки структуры соответствуют реализации некоторых

требований, то соответственно их реализацию можно проверять на процессе

сопровождения и эксплуатации, т.е. параллельно с процессом разработки блоков

структуры системы. При этом вспомогательные и организационные процессы могут 55

выполняться параллельно с процессом разработки и накапливать сведения по данным

количественных и качественных оценок на процессах разработки.

 

Преимущества применения данной модели ЖЦ состоит в следующем:

– проведение быстрой реализация некоторых возможностей системы;

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

– в системе выделяются отдельные части для реализации их в отдельности;

– возможность увеличения финансирования системы;

– обратная связь устанавливается с заказчиком для уточнения требований;

– упрощение внесения изменений.

.

Минимизация сложности программного обеспечения

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

 

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

 

Достигается:

 

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