Разработка ПО — это нечто большее, чем программирование. Это утверждение является не парадоксом, а осознанием всех факторов, влияющих на успех программного проекта, и всех возникающих задач, не связанных с написанием программ, но требующих внимания. Вот несколько примеров.
Эти и другие виды деятельности, обсуждаемые в этой лекции, не включают приемы программирования, но если не принимать их во внимание, они могут разрушить проект, независимо от его технического совершенства.
В предыдущих лекциях мы почти исключительно сосредоточивались на программировании, но картина была бы не полна без рассмотрения непрограммистских аспектов инженерии программ.
Это широко разветвленная и хорошо разработанная дисциплина. Для ее полного рассмотрения требуется отдельный учебник. К счастью, несколько учебников уже существует, ссылки на них можно будет найти в конце этой лекции в разделе "Дальнейшее чтение". Данная лекция имеет более ограниченные цели: ввести несколько непрограммистских аспектов программной инженерии, достаточных, чтобы пробудить ваш интерес и желание прочесть имеющуюся литературу по этой теме.
Важную роль в инженерии программ играют инструментальные средства, применяемые при разработке. Обзор некоторого инструментария появлялся в предыдущих лекциях.
Следующее определение, охватывающее широкую область, будет нам полезно.
Два важных свойства инженерии программ устанавливаются в этом определении — ПО должно быть программным продуктом и иметь определенное качество.
Программный продукт — это ПО, предназначенное для функционирования в реальном окружении и для решения реальных задач. Разрабатываемое в экспериментальных целях ПО — "программа на выброс", используемая однократно, не сопровождаемая в течение длительного времени, — не квалифицируется как продукт. Исключением будет случай, когда эксперимент является частью достижения широкой цели, принадлежащей инженерии программ. Например, эксперимент по оценке различных возможных алгоритмов сам по себе не квалифицируется, но все меняется, если он выполняется как часть разработки программного продукта.
Программный продукт должен удовлетворять комбинации ограничений. Они могут включать:
Забота о качестве находится в центре инженерии программ. Определение говорит об "определенных стандартах" качества. Качество не есть нечто такое, что кто-то произвольно объявил присутствующим или отсутствующим в программном процессе или продукте, оно должно оцениваться настолько объективно, насколько это возможно.
Определение также говорит о "разработке и оперировании". Программная конструкция не возникает мгновенно, наряду с разработкой появляется процесс фактического использования (оперирования) ПО. Даже фаза разработки не должна пониматься как создание некоторого законченного выпуска системы: то, что происходит после этого, также имеет значение. Мы уже встречались с техническим термином для этого вида деятельности.
Термин "сопровождение" пришел из других областей инженерной деятельности — сопровождение машины или дома. Как указывают многие, аналогия "хромает", поскольку программа не повреждается от частого использования в отличие от предметов материального мира — после тысячи запусков она остается такой же, как и при первом запуске. Однако как программистский термин "сопровождение" продолжает использоваться — и никаких проблем не возникает, если понимать его в соответствии со сделанным определением.
Жаргонный термин будет полезен для обсуждения.
Сопричастником программного проекта является любой человек, который воздействует на проект и на его качество или который оказывается под влиянием проекта с достигнутым качеством.
Понятие охватывает множество людей: разработчиков, тестеров, менеджеров проекта, других членов команды. Но сюда же включаются и будущие пользователи системы, все те, на кого проект воздействует, в их числе и менее приятная, но все же существующая часть людей — те, кто не станет пользователями, поскольку система сделает их текущую работу бесполезной. К сопричастникам относятся маркетологи и люди, занимающиеся продажей, в чьи обязанности входит поиск потребителей программного продукта после его выпуска, тренеры, обучающие работе с продуктом, ИТ-отделы в корпорациях, приобретающих продукт.
Важной частью управления проектом является идентификация всех сопричастников на ранних этапах, чтобы рассмотреть их потребности и ограничения каждой из групп.
Для понимания вызовов, стоящих перед инженерией программ, можно рассматривать эту дисциплину как состоящую из пяти частей — пяти граней равной важности. Программирование — это первый компонент одной из частей (второй — реализация). В качестве мнемоники этой классификации будем использовать акроним DIAMO (по первым буквам английских слов, именующих части дисциплины — Describe, Implement, Assess, Manage, Operate. Акроним является префиксом слова Diamond — бриллиант).
Описание (Describe): многие виды деятельности в инженерии программ включают понимание и специфицирование задач и систем. Целью такой деятельности является не построение решения, а описание свойств решения. Описание может требоваться перед построением решения на этапе анализа требований и проектирования спецификаций или на более поздних этапах при создании документации
(рис 9.1) DIAMO. Бриллиант инженерии программ
Реализация (Implement): задача построения программ. Этап включает не просто реализацию (программирование в узком смысле этого термина), но и проектирование — определение архитектуры системы на высоком уровне абстракции.
Оценка (Assess): большая часть процесса связана с анализом ПО. Продукты, подлежащие оценке, — это не только программы, но и все, что входит в понятие ПО, в частности, архитектура проекта и документация. Наиболее общей целью является выявление погрешностей (можно сказать по-другому — установление корректности). На этом этапе решаются такие важные задачи, как статический анализ программ, тестирование и отладка. Это, однако, далеко не все, что требуется оценить. В частности, при эффективной организации процесса разработки требуются количественные показатели как продукта (размер, сложность, ...), так и процессов (время, стоимость), что и является предметом соответствующих метрик.
Управление (Manage): любой серьезный проект, даже с несколькими разработчиками, требует управления. К этой части относятся такие задачи, как установление коммуникаций в команде разработчиков. Сегодня проблема усложняется из-за того, что многие современные проекты выполняются географически распределенной командой, на это накладываются и языковые барьеры. Сюда же относятся задачи составления расписания, выдерживания контрольных сроков, установление взаимодействия с пользователями и другими сопричастниками, управление неизбежными запросами на изменение.
Функционирование (Орегаtе): когда все проанализировано, спроектировано, реализовано, протестировано и документировано, тогда только все и начинается — система должна функционировать. Она должна быть развернута и начать успешно работать. Фаза развертывания в индустрии может быть главным камнем преткновения. Представьте себе инсталляцию банковского ПО, которое должно работать в тысячах автоматов во многих странах, с необходимостью учета местного контекста (языка дисплея, требований безопасности, сетевых соединений). Сюда же относится обеспечение устойчивого процесса будущих обновлений системы.
За программированием, конечно же, остается его фундаментальная роль: нет программ — нет и инженерии программ. Все другие виды деятельности теоретически не обязательны. На практике любой серьезный проект должен уделять внимание всем сторонам инженерии программ.
Качество — главная цель инженерии программ — является понятием со многими различными характеристиками, часто называемых факторами качества. Давайте рассмотрим некоторые из наиболее важных факторов.
Обсуждение инженерии программ предполагает два дополняющих друг друга аспекта.
Число ошибок в поставляемой программе является примером проблемы продукта. Поставляется ли программа в соответствии с расписанием — пример проблемы процесса.
В каждом случае оба аспекта играют свою роль: процесс определяет, в частности, обнаружение и удаление ошибок, а выдерживание сроков влияет на продукт, например, из-за опускаемой частично функциональности.
Факторы качества ПО удобно обсуждать, рассматривая их с трех разных позиций.
В каждой области рассмотрим главные цели, начав с наиболее очевидного свойства — качества непосредственного продукта. Обсуждение включает некоторые комментарии, объясняющие, почему некоторые другие факторы играют не столь важную роль. Два общих замечания об этом обзоре:
На следующем рисунке показана общая классификация факторов качества, которые предстоит рассмотреть.
Качество продукта включает следующие факторы.
(рис 9.2) Факторы качества ПО
Некоторые качества продукта не оказывают непосредственного влияния на его текущих пользователей, но важны для тех, кто занимается его поставкой. Если я водитель автомобиля, то меня не очень волнует простота модификации ПО, отвечающего за работу кондиционера, мне важно, чтобы кондиционер хорошо работал (непосредственный фактор). Но если я отвечаю за разработку ПО для Nissan или BMW, то я должен учитывать долговременную перспективу: будет ли система просто обновляться, сможет ли версия, разработанная для седанов, быть преобразована за разумные деньги в версию для кабриолетов?
При описании ПО часто встречается термин "пользователь", приобретший уже почти мифический смысл. Хорошо заботиться о пользователях, но с точки зрения долговременной перспективы сопричастники включают и другие группы, о которых следует заботиться. Более общие термины — клиенты, заказчики — применимы как к нынешним пользователям, так и к тем, кто работал или будет работать с системой в будущем.
Качества, ориентированные на долгий период, включают:
расширяемость: простота добавления функциональности. И здесь ключом является структура. Изученная нами ОО-техника — абстракция данных, скрытие информации, классы, универсальность, контракты, наследование, динамическое связывание, агенты и прочее — облегчает расширение. Расширяемость является принципиальным требованием практической разработки ПО, поскольку функциональность практически каждой системы подвергается изменениям.
Причины изменений могут быть разные: в начальном определении требований пропущены некоторые функции, отложенные на время возможности, как следствие успеха системы, ведущее к ее развитию. Хороший процесс разработки выстраивает дисциплину таких изменений, определяя строгие процедуры анализа новых запросов;
В литературе можно найти ссылки на фактор качества, называемый сопровождаемостью, предполагающий простоту работы с системой после выпуска начального релиза. Это важное понятие не является независимым фактором, а представляет комбинацию уже рассмотренных долговременных факторов, так как сопровождаемость включает и фиксацию ошибок, и расширение функциональности и перенос на другие платформы.
Все рассмотренные до сих пор свойства являются внешними факторами качества: они представляют прямой интерес для клиентов. Качество включает и внутренние факторы, характеризующие то, как фактически написана система, эти факторы значимы только для разработчиков. Неформально со многими из них вы знакомы, поскольку они соответствуют советам по проектированию и программированию, проходящим через всю книгу. При проектировании ПО классы должны отражать релевантные абстракции данных, между классами должны устанавливаться подходящие отношения (наследования и клиентские), необходимо использовать преимущества разработанных образцов проектирования, включать осмысленные контракты, применять скрытие информации, встраивать в проект документацию и использовать комментарии, писать проект в читаемом стиле, облегчающем его будущее расширение.
Еще одним примером внутренних факторов является список свойств, определяемых ниже. Этими свойствами должны обладать правильно построенные документы, задающие требования к системе, но некоторые из них применимы и к программам. Внутренние качества — это тот фундамент, на котором строится качество системы. Внешние факторы, внешние свойства достижимы только при высоком внутреннем качестве системы. Корректность и простота исправлений, например, сводятся в конечном итоге к систематическому программированию,
Но нужно понимать, что, в конечном счете, значение имеют внешние факторы, так как они напрямую связаны с потребностями клиентов, в интересах которых создается система.
Факторы процесса оценивают качество механизмов, применяемых для создания ПО. Они включают:
Модели процессов, такие как CMMI (изучаемые позже в этой лекции), ставят эти факторы во главу угла, в частности, последние пять, обучая культуре производства, где оценивание, предсказуемость, измеримость, воспроизводимость и самосовершенствование являются встроенными центральными практиками.
В то время как разработка должна стремиться к достижению наилучшего качества по всем показателям, предшествующий обзор показывает, что компромиссы неизбежны.
Одна из характеристик хорошо управляемого проекта состоит в том, что компромиссы анализируются и разрешаются явным образом. В противном случае они все равно были бы разрешены как-либо, но далеко не очевидно, что это было бы сделано лучшим образом. Типичный пример — оптимизация, в которой нет очевидной необходимости, но которая может отрицательно влиять на другие факторы.
Инженерия программ включает несколько задач. Вы уже много узнали об одной из их — реализации, и получили некоторое представление о других, таких как проектирование, документирование, задание спецификаций. Теперь мы пройдем по списку главных задач, упорядочим его в первом приближении, начиная от задач, отвечающих интересам клиентов, до тех, что имеют дело с внутренними свойствами ПО.
Анализ осуществимости является задачей изучения проблем клиентов. На этом этапе необходимо принять решение о возможности и желательности построения программной системы (или системы, включающей разработку ПО). Второй аспект, хотя и не следующий из названия, не менее важен, чем первый, — не всякую систему, которую можно построить, следует строить.
Анализ требований определяет функциональность системы. Элементы, составляющие документ требований, могут быть двух видов.
Спецификация является точным описанием отдельных элементов системы. Требования ориентированы на клиента. Спецификация преобразует их в форму, непосредственно используемую при разработке системы. Главная разница состоит в законченности и точности: спецификация должна давать недвусмысленный ответ на каждый релевантный вопрос об операциях системы.
Требования и спецификация иногда рассматриваются как единая деятельность. В моделях жизненного цикла, представленных далее, они рассматриваются как независимые. Деятельности, рассматриваемые до сих пор, только указывали на проблему, которая должна быть решена. Для следующих задач мы перейдем в мир программных решений.
Проектирование, называемое также архитектурой, состоит в построении общей структуры программной системы. Этот этап ответственен, в частности, за определение отдельных элементов или модулей этой системы и за отношения между этими модулями.
Реализация является задачей фактической разработки программного текста. Она известна также как кодирование, но в термине чувствуется пренебрежительный оттенок — после того, как великие мыслители выполнили анализ и проектирование, рутинную работу по написанию программы могут выполнить прислужники. В этой книге программирование понимается в широком смысле как конструирование программ, не только реализация, но и проектирование и анализ.
Создание документации представляет задачу описания различных аспектов системы, чтобы помочь ее пользователям и другим сопричастникам, в частности, разработчикам. Помимо документов, создаваемых для пользователей, она может включать планы проекта (для менеджеров), документы требований, спецификации, планы проектирования. Слово "документ" заменило более традиционное слово "отчет", представляемый обычно как бумажный документ. Сегодняшняя документация представляется в электронном виде, как Web-страницы, онлайновая справка, регулярно обновляемая. Документация является частью программного текста в виде заголовочных комментариев — специальных документируемых комментариев, которые есть в таких языках, как Eiffel, Java и C#.
Верификация и проверка правильности должны ответить на вопрос, является ли система удовлетворительной. Два аспекта дополняют друг друга.
REAL , как если бы она имела тип INTEGER .Сопровождение, как уже отмечалось, не представляет вид независимой деятельности, а является комбинацией перечисленных выше задач. Единственной отличительной чертой сопровождения является то, что сопровождение начинается с той минуты, когда выпущен первый релиз системы.
В литературе по инженерии программ много внимания уделяется моделям жизненного цикла: спецификации того, как расписать перечисленные выше виды деятельности по фактическим процессам. Подобные упражнения имеют свои пределы, поскольку модели описывают идеализированные процессы, в то время как разработка является человеческой деятельностью со всеми неизбежными элементами непредсказуемости.
(рис 9.3) Модель водопада
Начальной точкой всех обсуждений моделей жизненного цикла являлась статья 1970 года, посвященная модели водопада (которая фактически была написана ради критики модели, но служит теперь как ссылка на определение этого понятия). Идея "водопада" проста — задачи выполняются в определенном порядке.
Общей практикой стало графическое представление модели, возможно, из-за отсутствия устойчивого определения. Будем следовать этой практике и здесь. Следующий рисунок задает представление этой модели.
Этот и некоторые другие элементы этого раздела являются адаптированными материалами главы 28 из моей книги "Объектно-ориентированное конструирование программных систем", 2006 г., которая содержит более детальное обсуждение моделей процесса.
Недостаток этой модели — в ее жесткости, так как предполагается, что все виды деятельности синхронизированы. На верхних уровнях модели все может быть гладко и хорошо, но на этапе реализации может оказаться, что надежды не могут быть реализованы в коде, так что приходится возвращаться в начало.
(рис 9.4) Спиральная модель
В своей книге (Software Engineering Economics Prentice Hall, 1988) Барри Боем предложил модель, которая смягчает жесткость, применяя итеративный подход, основанный на успешных прототипах. Эта модель известна под именем спиральной модели и показана на следующем рисунке.
Каждый прототип в спиральной модели следует последовательности шагов, подобных водопаду, но он предполагает проверку гипотез и пробных проектов, прежде чем создается реально работающая система. Каждая итерация спирали строится с учетом уроков предыдущей итерации.
Спиральная модель более гибкая, чем водопад, и не имеет некоторых принципиальных недостатков. Риск, связанный с этой моделью, состоит в том, что прототип — это не модель, здесь часто ослабляются ограничения (например, производительность), что позже может стать критически важным, перечеркивая ценность уроков прототипа.
Еще один риск, связанный с этой моделью, состоит в том, что когда сокращается бюджет или сроки выпуска релиза становятся определяющими, то в качестве релиза выпускается прототип, изначально не предназначенный для этой цели.
Кластерная модель наилучшим образом сочетается с ОО-разработкой в том виде, как она представлена в этой книге. Она модифицирует базисную модель водопада, отменяя синхронность протекающих процессов. Предполагается, что система разделяется на несколько подсистем или кластеров, каждый со своим мини-процессом, как показано на следующем рисунке. В результате к последовательному измерению добавляется аспект параллелизма, так как несколько кластеров могут разрабатываться параллельно. Как следствие, менеджер проекта получает большую свободу в реагировании на сюрпризы процесса разработки. Некоторые задачи будут решены быстрее, чем ожидалось, другие (что чаще происходит) — медленнее.
Для минимизации рисков разработка должна начинаться с наиболее фундаментальных кластеров, обеспечивающих критическую функциональность, и двигаться по направлению к частям, ориентированным на пользователя. Бывает трудно убедить заказчиков в целесообразности такого порядка работы (им бы хотелось иметь работающий прототип как можно скорее), но данный подход чаще приводит к успеху.
(рис 9.5) Кластерная модель
Задачи, появляющиеся при разработке каждого кластера, совпадают с задачами водопадной модели за одним исключением — этапа обобщения. Идея в том, что удовлетворительной реализации кластера может быть недостаточно, если нам требуется повторное использование. Целью фазы обобщения является удаление из кластерных классов любого свойства, ограничивающего без необходимости их применимость, такого как ограничение на размеры, несовершенная структура наследования, недостаточность контрактов. В результате кластерные классы могут быть применимыми в будущих разработках и отвечать потребностям текущего проекта.
Разработка каждого кластера выполняется непрерывно, а не в виде последовательности независимых шагов, как в модели водопада. Эта идея бесшовной разработки, в частности, важна в подходе Eiffel, где анализ, проектирование и реализация — все используют единую нотацию и построены на едином базисе, начиная с отложенных классов высокого уровня, которые описывают проблему. Фазы проектирования и реализации состоят из уточнений и обогащений этих классов. Это облегчает возврат (символизируемый стрелкой возврата на рисунке) к предыдущим фазам для улучшения или корректировки несовершенной предыдущей версии.
В ответ на жесткость процессов, предписываемых моделью разработки, agile-методы, в частности, подход, называемый "экстремальным программированием", меньше внимания уделяет планам и процессам, фокусируясь вместо этого на элементах, таких как:
Появление в девяностые годы этой гибкой методологии вызвало ожесточенные споры. Это воспринималось как социологический феномен — революция программистов против засилья менеджеров. Теперь все понемногу успокоилось, и многие практики, такие как непрерывная интеграция, широко приняты. Другие, такие как "тесты предпочтительнее спецификаций", остаются под вопросом. Но становится ясно, что процесс разработки ПО может быть как структурированным, так и гибким (agile).
Разработка ПО — это нечто большее, чем программирование. Это утверждение является не парадоксом, а осознанием всех факторов, влияющих на успех программного проекта, и всех возникающих задач, не связанных с написанием программ, но требующих внимания. Вот несколько примеров.
Эти и другие виды деятельности, обсуждаемые в этой лекции, не включают приемы программирования, но если не принимать их во внимание, они могут разрушить проект, независимо от его технического совершенства.
В предыдущих лекциях мы почти исключительно сосредоточивались на программировании, но картина была бы не полна без рассмотрения непрограммистских аспектов инженерии программ.
Это широко разветвленная и хорошо разработанная дисциплина. Для ее полного рассмотрения требуется отдельный учебник. К счастью, несколько учебников уже существует, ссылки на них можно будет найти в конце этой лекции в разделе "Дальнейшее чтение". Данная лекция имеет более ограниченные цели: ввести несколько непрограммистских аспектов программной инженерии, достаточных, чтобы пробудить ваш интерес и желание прочесть имеющуюся литературу по этой теме.
Важную роль в инженерии программ играют инструментальные средства, применяемые при разработке. Обзор некоторого инструментария появлялся в предыдущих лекциях.
Следующее определение, охватывающее широкую область, будет нам полезно.
Два важных свойства инженерии программ устанавливаются в этом определении — ПО должно быть программным продуктом и иметь определенное качество.
Программный продукт — это ПО, предназначенное для функционирования в реальном окружении и для решения реальных задач. Разрабатываемое в экспериментальных целях ПО — "программа на выброс", используемая однократно, не сопровождаемая в течение длительного времени, — не квалифицируется как продукт. Исключением будет случай, когда эксперимент является частью достижения широкой цели, принадлежащей инженерии программ. Например, эксперимент по оценке различных возможных алгоритмов сам по себе не квалифицируется, но все меняется, если он выполняется как часть разработки программного продукта.
Программный продукт должен удовлетворять комбинации ограничений. Они могут включать:
Забота о качестве находится в центре инженерии программ. Определение говорит об "определенных стандартах" качества. Качество не есть нечто такое, что кто-то произвольно объявил присутствующим или отсутствующим в программном процессе или продукте, оно должно оцениваться настолько объективно, насколько это возможно.
Определение также говорит о "разработке и оперировании". Программная конструкция не возникает мгновенно, наряду с разработкой появляется процесс фактического использования (оперирования) ПО. Даже фаза разработки не должна пониматься как создание некоторого законченного выпуска системы: то, что происходит после этого, также имеет значение. Мы уже встречались с техническим термином для этого вида деятельности.
Термин "сопровождение" пришел из других областей инженерной деятельности — сопровождение машины или дома. Как указывают многие, аналогия "хромает", поскольку программа не повреждается от частого использования в отличие от предметов материального мира — после тысячи запусков она остается такой же, как и при первом запуске. Однако как программистский термин "сопровождение" продолжает использоваться — и никаких проблем не возникает, если понимать его в соответствии со сделанным определением.
Жаргонный термин будет полезен для обсуждения.
Сопричастником программного проекта является любой человек, который воздействует на проект и на его качество или который оказывается под влиянием проекта с достигнутым качеством.
Понятие охватывает множество людей: разработчиков, тестеров, менеджеров проекта, других членов команды. Но сюда же включаются и будущие пользователи системы, все те, на кого проект воздействует, в их числе и менее приятная, но все же существующая часть людей — те, кто не станет пользователями, поскольку система сделает их текущую работу бесполезной. К сопричастникам относятся маркетологи и люди, занимающиеся продажей, в чьи обязанности входит поиск потребителей программного продукта после его выпуска, тренеры, обучающие работе с продуктом, ИТ-отделы в корпорациях, приобретающих продукт.
Важной частью управления проектом является идентификация всех сопричастников на ранних этапах, чтобы рассмотреть их потребности и ограничения каждой из групп.
Для понимания вызовов, стоящих перед инженерией программ, можно рассматривать эту дисциплину как состоящую из пяти частей — пяти граней равной важности. Программирование — это первый компонент одной из частей (второй — реализация). В качестве мнемоники этой классификации будем использовать акроним DIAMO (по первым буквам английских слов, именующих части дисциплины — Describe, Implement, Assess, Manage, Operate. Акроним является префиксом слова Diamond — бриллиант).
Описание (Describe): многие виды деятельности в инженерии программ включают понимание и специфицирование задач и систем. Целью такой деятельности является не построение решения, а описание свойств решения. Описание может требоваться перед построением решения на этапе анализа требований и проектирования спецификаций или на более поздних этапах при создании документации
(рис 9.1) DIAMO. Бриллиант инженерии программ
Реализация (Implement): задача построения программ. Этап включает не просто реализацию (программирование в узком смысле этого термина), но и проектирование — определение архитектуры системы на высоком уровне абстракции.
Оценка (Assess): большая часть процесса связана с анализом ПО. Продукты, подлежащие оценке, — это не только программы, но и все, что входит в понятие ПО, в частности, архитектура проекта и документация. Наиболее общей целью является выявление погрешностей (можно сказать по-другому — установление корректности). На этом этапе решаются такие важные задачи, как статический анализ программ, тестирование и отладка. Это, однако, далеко не все, что требуется оценить. В частности, при эффективной организации процесса разработки требуются количественные показатели как продукта (размер, сложность, ...), так и процессов (время, стоимость), что и является предметом соответствующих метрик.
Управление (Manage): любой серьезный проект, даже с несколькими разработчиками, требует управления. К этой части относятся такие задачи, как установление коммуникаций в команде разработчиков. Сегодня проблема усложняется из-за того, что многие современные проекты выполняются географически распределенной командой, на это накладываются и языковые барьеры. Сюда же относятся задачи составления расписания, выдерживания контрольных сроков, установление взаимодействия с пользователями и другими сопричастниками, управление неизбежными запросами на изменение.
Функционирование (Орегаtе): когда все проанализировано, спроектировано, реализовано, протестировано и документировано, тогда только все и начинается — система должна функционировать. Она должна быть развернута и начать успешно работать. Фаза развертывания в индустрии может быть главным камнем преткновения. Представьте себе инсталляцию банковского ПО, которое должно работать в тысячах автоматов во многих странах, с необходимостью учета местного контекста (языка дисплея, требований безопасности, сетевых соединений). Сюда же относится обеспечение устойчивого процесса будущих обновлений системы.
За программированием, конечно же, остается его фундаментальная роль: нет программ — нет и инженерии программ. Все другие виды деятельности теоретически не обязательны. На практике любой серьезный проект должен уделять внимание всем сторонам инженерии программ.
Качество — главная цель инженерии программ — является понятием со многими различными характеристиками, часто называемых факторами качества. Давайте рассмотрим некоторые из наиболее важных факторов.
Обсуждение инженерии программ предполагает два дополняющих друг друга аспекта.
Число ошибок в поставляемой программе является примером проблемы продукта. Поставляется ли программа в соответствии с расписанием — пример проблемы процесса.
В каждом случае оба аспекта играют свою роль: процесс определяет, в частности, обнаружение и удаление ошибок, а выдерживание сроков влияет на продукт, например, из-за опускаемой частично функциональности.
Факторы качества ПО удобно обсуждать, рассматривая их с трех разных позиций.
В каждой области рассмотрим главные цели, начав с наиболее очевидного свойства — качества непосредственного продукта. Обсуждение включает некоторые комментарии, объясняющие, почему некоторые другие факторы играют не столь важную роль. Два общих замечания об этом обзоре:
На следующем рисунке показана общая классификация факторов качества, которые предстоит рассмотреть.
Качество продукта включает следующие факторы.
(рис 9.2) Факторы качества ПО
Некоторые качества продукта не оказывают непосредственного влияния на его текущих пользователей, но важны для тех, кто занимается его поставкой. Если я водитель автомобиля, то меня не очень волнует простота модификации ПО, отвечающего за работу кондиционера, мне важно, чтобы кондиционер хорошо работал (непосредственный фактор). Но если я отвечаю за разработку ПО для Nissan или BMW, то я должен учитывать долговременную перспективу: будет ли система просто обновляться, сможет ли версия, разработанная для седанов, быть преобразована за разумные деньги в версию для кабриолетов?
При описании ПО часто встречается термин "пользователь", приобретший уже почти мифический смысл. Хорошо заботиться о пользователях, но с точки зрения долговременной перспективы сопричастники включают и другие группы, о которых следует заботиться. Более общие термины — клиенты, заказчики — применимы как к нынешним пользователям, так и к тем, кто работал или будет работать с системой в будущем.
Качества, ориентированные на долгий период, включают:
расширяемость: простота добавления функциональности. И здесь ключом является структура. Изученная нами ОО-техника — абстракция данных, скрытие информации, классы, универсальность, контракты, наследование, динамическое связывание, агенты и прочее — облегчает расширение. Расширяемость является принципиальным требованием практической разработки ПО, поскольку функциональность практически каждой системы подвергается изменениям.
Причины изменений могут быть разные: в начальном определении требований пропущены некоторые функции, отложенные на время возможности, как следствие успеха системы, ведущее к ее развитию. Хороший процесс разработки выстраивает дисциплину таких изменений, определяя строгие процедуры анализа новых запросов;
В литературе можно найти ссылки на фактор качества, называемый сопровождаемостью, предполагающий простоту работы с системой после выпуска начального релиза. Это важное понятие не является независимым фактором, а представляет комбинацию уже рассмотренных долговременных факторов, так как сопровождаемость включает и фиксацию ошибок, и расширение функциональности и перенос на другие платформы.
Все рассмотренные до сих пор свойства являются внешними факторами качества: они представляют прямой интерес для клиентов. Качество включает и внутренние факторы, характеризующие то, как фактически написана система, эти факторы значимы только для разработчиков. Неформально со многими из них вы знакомы, поскольку они соответствуют советам по проектированию и программированию, проходящим через всю книгу. При проектировании ПО классы должны отражать релевантные абстракции данных, между классами должны устанавливаться подходящие отношения (наследования и клиентские), необходимо использовать преимущества разработанных образцов проектирования, включать осмысленные контракты, применять скрытие информации, встраивать в проект документацию и использовать комментарии, писать проект в читаемом стиле, облегчающем его будущее расширение.
Еще одним примером внутренних факторов является список свойств, определяемых ниже. Этими свойствами должны обладать правильно построенные документы, задающие требования к системе, но некоторые из них применимы и к программам. Внутренние качества — это тот фундамент, на котором строится качество системы. Внешние факторы, внешние свойства достижимы только при высоком внутреннем качестве системы. Корректность и простота исправлений, например, сводятся в конечном итоге к систематическому программированию,
Но нужно понимать, что, в конечном счете, значение имеют внешние факторы, так как они напрямую связаны с потребностями клиентов, в интересах которых создается система.
Факторы процесса оценивают качество механизмов, применяемых для создания ПО. Они включают:
Модели процессов, такие как CMMI (изучаемые позже в этой лекции), ставят эти факторы во главу угла, в частности, последние пять, обучая культуре производства, где оценивание, предсказуемость, измеримость, воспроизводимость и самосовершенствование являются встроенными центральными практиками.
В то время как разработка должна стремиться к достижению наилучшего качества по всем показателям, предшествующий обзор показывает, что компромиссы неизбежны.
Одна из характеристик хорошо управляемого проекта состоит в том, что компромиссы анализируются и разрешаются явным образом. В противном случае они все равно были бы разрешены как-либо, но далеко не очевидно, что это было бы сделано лучшим образом. Типичный пример — оптимизация, в которой нет очевидной необходимости, но которая может отрицательно влиять на другие факторы.
Инженерия программ включает несколько задач. Вы уже много узнали об одной из их — реализации, и получили некоторое представление о других, таких как проектирование, документирование, задание спецификаций. Теперь мы пройдем по списку главных задач, упорядочим его в первом приближении, начиная от задач, отвечающих интересам клиентов, до тех, что имеют дело с внутренними свойствами ПО.
Анализ осуществимости является задачей изучения проблем клиентов. На этом этапе необходимо принять решение о возможности и желательности построения программной системы (или системы, включающей разработку ПО). Второй аспект, хотя и не следующий из названия, не менее важен, чем первый, — не всякую систему, которую можно построить, следует строить.
Анализ требований определяет функциональность системы. Элементы, составляющие документ требований, могут быть двух видов.
Спецификация является точным описанием отдельных элементов системы. Требования ориентированы на клиента. Спецификация преобразует их в форму, непосредственно используемую при разработке системы. Главная разница состоит в законченности и точности: спецификация должна давать недвусмысленный ответ на каждый релевантный вопрос об операциях системы.
Требования и спецификация иногда рассматриваются как единая деятельность. В моделях жизненного цикла, представленных далее, они рассматриваются как независимые. Деятельности, рассматриваемые до сих пор, только указывали на проблему, которая должна быть решена. Для следующих задач мы перейдем в мир программных решений.
Проектирование, называемое также архитектурой, состоит в построении общей структуры программной системы. Этот этап ответственен, в частности, за определение отдельных элементов или модулей этой системы и за отношения между этими модулями.
Реализация является задачей фактической разработки программного текста. Она известна также как кодирование, но в термине чувствуется пренебрежительный оттенок — после того, как великие мыслители выполнили анализ и проектирование, рутинную работу по написанию программы могут выполнить прислужники. В этой книге программирование понимается в широком смысле как конструирование программ, не только реализация, но и проектирование и анализ.
Создание документации представляет задачу описания различных аспектов системы, чтобы помочь ее пользователям и другим сопричастникам, в частности, разработчикам. Помимо документов, создаваемых для пользователей, она может включать планы проекта (для менеджеров), документы требований, спецификации, планы проектирования. Слово "документ" заменило более традиционное слово "отчет", представляемый обычно как бумажный документ. Сегодняшняя документация представляется в электронном виде, как Web-страницы, онлайновая справка, регулярно обновляемая. Документация является частью программного текста в виде заголовочных комментариев — специальных документируемых комментариев, которые есть в таких языках, как Eiffel, Java и C#.
Верификация и проверка правильности должны ответить на вопрос, является ли система удовлетворительной. Два аспекта дополняют друг друга.
REAL , как если бы она имела тип INTEGER .Сопровождение, как уже отмечалось, не представляет вид независимой деятельности, а является комбинацией перечисленных выше задач. Единственной отличительной чертой сопровождения является то, что сопровождение начинается с той минуты, когда выпущен первый релиз системы.
В литературе по инженерии программ много внимания уделяется моделям жизненного цикла: спецификации того, как расписать перечисленные выше виды деятельности по фактическим процессам. Подобные упражнения имеют свои пределы, поскольку модели описывают идеализированные процессы, в то время как разработка является человеческой деятельностью со всеми неизбежными элементами непредсказуемости.
(рис 9.3) Модель водопада
Начальной точкой всех обсуждений моделей жизненного цикла являлась статья 1970 года, посвященная модели водопада (которая фактически была написана ради критики модели, но служит теперь как ссылка на определение этого понятия). Идея "водопада" проста — задачи выполняются в определенном порядке.
Общей практикой стало графическое представление модели, возможно, из-за отсутствия устойчивого определения. Будем следовать этой практике и здесь. Следующий рисунок задает представление этой модели.
Этот и некоторые другие элементы этого раздела являются адаптированными материалами главы 28 из моей книги "Объектно-ориентированное конструирование программных систем", 2006 г., которая содержит более детальное обсуждение моделей процесса.
Недостаток этой модели — в ее жесткости, так как предполагается, что все виды деятельности синхронизированы. На верхних уровнях модели все может быть гладко и хорошо, но на этапе реализации может оказаться, что надежды не могут быть реализованы в коде, так что приходится возвращаться в начало.
(рис 9.4) Спиральная модель
В своей книге (Software Engineering Economics Prentice Hall, 1988) Барри Боем предложил модель, которая смягчает жесткость, применяя итеративный подход, основанный на успешных прототипах. Эта модель известна под именем спиральной модели и показана на следующем рисунке.
Каждый прототип в спиральной модели следует последовательности шагов, подобных водопаду, но он предполагает проверку гипотез и пробных проектов, прежде чем создается реально работающая система. Каждая итерация спирали строится с учетом уроков предыдущей итерации.
Спиральная модель более гибкая, чем водопад, и не имеет некоторых принципиальных недостатков. Риск, связанный с этой моделью, состоит в том, что прототип — это не модель, здесь часто ослабляются ограничения (например, производительность), что позже может стать критически важным, перечеркивая ценность уроков прототипа.
Еще один риск, связанный с этой моделью, состоит в том, что когда сокращается бюджет или сроки выпуска релиза становятся определяющими, то в качестве релиза выпускается прототип, изначально не предназначенный для этой цели.
Кластерная модель наилучшим образом сочетается с ОО-разработкой в том виде, как она представлена в этой книге. Она модифицирует базисную модель водопада, отменяя синхронность протекающих процессов. Предполагается, что система разделяется на несколько подсистем или кластеров, каждый со своим мини-процессом, как показано на следующем рисунке. В результате к последовательному измерению добавляется аспект параллелизма, так как несколько кластеров могут разрабатываться параллельно. Как следствие, менеджер проекта получает большую свободу в реагировании на сюрпризы процесса разработки. Некоторые задачи будут решены быстрее, чем ожидалось, другие (что чаще происходит) — медленнее.
Для минимизации рисков разработка должна начинаться с наиболее фундаментальных кластеров, обеспечивающих критическую функциональность, и двигаться по направлению к частям, ориентированным на пользователя. Бывает трудно убедить заказчиков в целесообразности такого порядка работы (им бы хотелось иметь работающий прототип как можно скорее), но данный подход чаще приводит к успеху.
(рис 9.5) Кластерная модель
Задачи, появляющиеся при разработке каждого кластера, совпадают с задачами водопадной модели за одним исключением — этапа обобщения. Идея в том, что удовлетворительной реализации кластера может быть недостаточно, если нам требуется повторное использование. Целью фазы обобщения является удаление из кластерных классов любого свойства, ограничивающего без необходимости их применимость, такого как ограничение на размеры, несовершенная структура наследования, недостаточность контрактов. В результате кластерные классы могут быть применимыми в будущих разработках и отвечать потребностям текущего проекта.
Разработка каждого кластера выполняется непрерывно, а не в виде последовательности независимых шагов, как в модели водопада. Эта идея бесшовной разработки, в частности, важна в подходе Eiffel, где анализ, проектирование и реализация — все используют единую нотацию и построены на едином базисе, начиная с отложенных классов высокого уровня, которые описывают проблему. Фазы проектирования и реализации состоят из уточнений и обогащений этих классов. Это облегчает возврат (символизируемый стрелкой возврата на рисунке) к предыдущим фазам для улучшения или корректировки несовершенной предыдущей версии.
В ответ на жесткость процессов, предписываемых моделью разработки, agile-методы, в частности, подход, называемый "экстремальным программированием", меньше внимания уделяет планам и процессам, фокусируясь вместо этого на элементах, таких как:
Появление в девяностые годы этой гибкой методологии вызвало ожесточенные споры. Это воспринималось как социологический феномен — революция программистов против засилья менеджеров. Теперь все понемногу успокоилось, и многие практики, такие как непрерывная интеграция, широко приняты. Другие, такие как "тесты предпочтительнее спецификаций", остаются под вопросом. Но становится ясно, что процесс разработки ПО может быть как структурированным, так и гибким (agile).
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.