5.11. Паттерны grasp

Информационный эксперт

Низкая связанность

Устойчивый к изменениям

Контроллер

Полиморфизм

Чистая выдумка

Перенаправление

5.12. Антипаттерны

Антипаттерны в управлении разработкой ПО

Антипаттерны в проектировании ПО

Антипаттерны в объектно-ориентированном программировании

Антипаттерны в программировании

Методологические антипаттерны

Антипаттерны управления конфигурацией

Организационные антипаттерны

Шуточные антипаттерны

6. Архитектура и характеристики качества

6.1. Специфика требований к качеству ПО

6.2. Подход к построению архитектуры с позиций качества

6.3. Подходы к оцениванию архитектуры

Заключение

Введение

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

Институт Программной Инженерии Университета Карнеги-Меллон (Software Engineering Institute, SEI) - общепризнанный законодатель в предметной области «Исследований и разработок систем, интенсивно использующих ПО» к классу таких систем относит «системы, в которых ПО представляет существенный сегмент по следующим позициям: функциональность системы, ее стоимость, риски в процессе разработки, время разработки» [1]. В таких системах компоненты ПО взаимодействуют с другими ПО-компонентами, компонентами и подсистемами другой природы, датчиками, приборами и людьми, вовлеченными в процессы ис-пользования ПО.

Для разработок систем, интенсивно использующих ПО, типичны крупномасштабные проекты ─ десятки или сотни разработчиков, месяцы или годы разработки, сотни тысяч или десятки миллионов долларов. К сожалению, разработки таких систем часто приводят к результатам, которые не соответствуют запланированным ожиданиям. Значительное число разработок либо прекращается, либо превышает запланированное время и /или средства, либо завершается в более бедной версии. Степень успешности, выраженная в процентах числа проектов, завершившихся в соответствии с исходными замыслами и планами, невысока и по некоторым оценкам не превышает 35% [2].

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

- нереальные проектные цели;

- ошибочные оценки необходимых ресурсов;

- неадекватная система требований;

- слабое документирование текущего состояния проекта;

- отсутствие или слабое управление рисками;

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

- использование незрелых технологий;

- неспособность коллектива справиться со сложностью проекта;

- небрежности в разработке;

- слабое управление проектом;

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

- коммерческое давление на разработчиков и менеджеров проекта.

Для предостережения разработчиков ПО созданы каталоги классических ошибок. Один из таких каталогов представлен в [3], где типовые ошибки распределены по группам «разработчик», «процесс», «продукт» и «технология». Вот некоторые из них: увеличение числа исполнителей для завершения проекта, нереалистичные ожидания, принятие желаемого за действительное, исключение важных задач из процесса проверок, переключение на другие инструменты по ходу проектирования.

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

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

Важным концептуальным для методологии программной инженерии моментом стало введение понятия «архитектура» в его применении к ПО и системам, базирующимся на ПО. Началом использования современного значения этого понятия принято считать 1992 год - работа Д. Перри и А. Вульфа [4]. Дальнейшие исследования в системной и программной инженерии позволили выввести взаимосвязанную совокупность архитектур [2]:

- программного обеспечения;

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

- информационного обеспечения;

- организационного обеспечения раскрывающего связность организационных структур (в том числе на уровне персонифицированных ролей и ответственности) с бизнес-процессами;

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

Важные результаты, полученные в последние годы:

- создана предметная область «Архитектура ПО», задачи которой для разработки ПО носят принципиальный характер;

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

- созданы технологии и инструментальные средства, аналогов которых в предшествующей инженерной практике не было (например, мастер-методология Rational Unified Process (RUP), инструментальные средства программирования для корпоративных сетей, в том числе и для WEB-программирования);

- создан и подтвердил на практике свою исключительную полезность унифицированный язык моделирования UML.