Цель - инженерия программ

Введение в инженерию программ

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

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

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

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

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

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

Базисные определения

Следующее определение, охватывающее широкую область, будет нам полезно.

Определение: инженерия программ

Два важных свойства инженерии программ устанавливаются в этом определении — ПО должно быть программным продуктом и иметь определенное качество.

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

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

• ограничения качества (обсуждаемые далее): например, гарантию, что система будет функционировать без отказов, давать корректные результаты и быстро работать;
• ограничения размера: программный продукт может состоять из тысяч или десятков тысяч классов и других модулей и сотен тысяч или миллионов строк кода;
• временную протяженность: системы, используемые в индустрии, часто должны сопровождаться (постоянно использоваться и регулярно обновляться) в течение многих лет и даже десятилетий;
• командную разработку: такие системы могут включать большие команды разработчиков и огромное число пользователей. Это приводит к появлению проблем с коммуникацией и управлением разработкой;
• ограничения влияния: эти системы воздействуют на физические процессы и процессы, влияющие на жизнь людей, — поезда могут не приходить во время, телефоны не работать, зарплата не выплачиваться, заказы не выполняться, а фактически все может быть гораздо хуже. Этим объясняются и требования к качеству.

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

Определение также говорит о "разработке и оперировании". Программная конструкция не возникает мгновенно, наряду с разработкой появляется процесс фактического использования (оперирования) ПО. Даже фаза разработки не должна пониматься как создание некоторого законченного выпуска системы: то, что происходит после этого, также имеет значение. Мы уже встречались с техническим термином для этого вида деятельности.

Определение: сопровождение ПО

Термин "сопровождение" пришел из других областей инженерной деятельности — сопровождение машины или дома. Как указывают многие, аналогия "хромает", поскольку программа не повреждается от частого использования в отличие от предметов материального мира — после тысячи запусков она остается такой же, как и при первом запуске. Однако как программистский термин "сопровождение" продолжает использоваться — и никаких проблем не возникает, если понимать его в соответствии со сделанным определением.

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

Понятие охватывает множество людей: разработчиков, тестеров, менеджеров проекта, других членов команды. Но сюда же включаются и будущие пользователи системы, все те, на кого проект воздействует, в их числе и менее приятная, но все же существующая часть людей — те, кто не станет пользователями, поскольку система сделает их текущую работу бесполезной. К сопричастникам относятся маркетологи и люди, занимающиеся продажей, в чьи обязанности входит поиск потребителей программного продукта после его выпуска, тренеры, обучающие работе с продуктом, ИТ-отделы в корпорациях, приобретающих продукт.

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

DIAMO - облик инженерии программ

Для понимания вызовов, стоящих перед инженерией программ, можно рассматривать эту дисциплину как состоящую из пяти частей — пяти граней равной важности. Программирование — это первый компонент одной из частей (второй — реализация). В качестве мнемоники этой классификации будем использовать акроним DIAMO (по первым буквам английских слов, именующих части дисциплины — Describe, Implement, Assess, Manage, Operate. Акроним является префиксом слова Diamond — бриллиант).

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

Рис. 9.1. DIAMO. Бриллиант инженерии программ

Реализация (Implement): задача построения программ. Этап включает не просто реализацию (программирование в узком смысле этого термина), но и проектирование — определение архитектуры системы на высоком уровне абстракции.

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

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

Функционирование (Орегаtе): когда все проанализировано, спроектировано, реализовано, протестировано и документировано, тогда только все и начинается — система должна функционировать. Она должна быть развернута и начать успешно работать. Фаза развертывания в индустрии может быть главным камнем преткновения. Представьте себе инсталляцию банковского ПО, которое должно работать в тысячах автоматов во многих странах, с необходимостью учета местного контекста (языка дисплея, требований безопасности, сетевых соединений). Сюда же относится обеспечение устойчивого процесса будущих обновлений системы.

За программированием, конечно же, остается его фундаментальная роль: нет программ — нет и инженерии программ. Все другие виды деятельности теоретически не обязательны. На практике любой серьезный проект должен уделять внимание всем сторонам инженерии программ.