Как стать автором
Обновить

Конструирование ПО, метафоры, предварительные требования

Время на прочтение 15 мин
Количество просмотров 9.6K

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

Почему именно абзацы из книги, а не своими словами? Потому что во многих случаях сказать лучше очень сложно. И потом, чистые тезисы читать скучно — надоедает на второй странице.
Если топик понравится — готов стараться описать в статьях всю книгу, с каждым разом все уменьшая объем и увеличивая плотность информации.

Конструирование ПО


Что такое конструирование ПО?


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

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

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

Почему конструирование ПО так важно?


Конструирование — крупная часть процесса разработки ПО. В зависимости от размера проекта на конструирование обычно уходит 30-80 % общего времени работы.

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

— Повышенное внимание к конструированию может намного повысить производительность труда отдельных программистов.

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

Конструирование — единственный процесс, который выполняется
во всех случаях.


В конечном счете ваша компетентность в конструировании ПО определяет то,
насколько хороший вы программист.


Метафоры, позволяющие лучше понять разработку ПО


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

Важность метафор


Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем
понятное явление с чем-то похожим, но более понятным, вы можете догадаться,
как справиться с проблемой. Такое использование метафор называется моделированием».
История науки полна открытий, сделанных благодаря метафорам. Так, химик Кекуле однажды во сне увидел змею, схватившую себя за хвост. Проснувшись, он понял, что свойства бензола объяснила бы молекулярная структура, имеющая похожую кольцевую форму. Дальнейшие эксперименты подтвердили его гипотезу (Barbour, 1966).

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

Иногда люди упрощают суть метафор. На каждый из описанных примеров так и
тянет ответить: «Разумеется, правильная метафора более полезна. Другая метафора
была неверной!» Так-то оно так, но это слишком упрощенное представление. История науки — не серия переходов от «неверных» метафор к «верным». Это серия
переходов от «менее хороших» метафор к «лучшим».

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

Как использовать метафоры?


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

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

Далее рассмотрим популярные метафоры, характеризующие разработку ПО.

Литературная метафора: написание кода


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

Подобный подход может быть практичным, если вы пишете банальное письмо своей тетушке. Однако расширение метафоры «написания» ПО вплоть до выбрасывания первого
экземпляра программы — не лучший совет в мире разработки ПО, где крупная система по стоимости уже сравнялась с 10-этажным офисным зданием или океанским лайнером.

Сельскохозяйственная метафора: выращивание системы


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

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

Метафора жемчужины: медленное приращение системы



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

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

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

Строительная метафора: построение ПО


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

Для построения метровой башни требуется твердая рука, ровная поверхность и
10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в
100 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.

Комбинирование метафор



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

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

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

Семь раз отмерь, один раз отрежь: предварительные условия



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

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

Важность выполнения предварительных условий


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

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

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


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

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

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

Ученые из компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW и других
организаций обнаружили, что исправление ошибки к началу конструирования обходится в 10-100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска (Fagan, 1976; Humphrey, Snyder, and Willis, 1991; Leffingwell 1997; Willis et al., 1998; Grady, 1999; Shull et al., 2002; Boehm and Turner, 2004).

Определите тип ПО, над которым вы работаете


Разработкой чего вы занимаетесь?
— Встроенные системы, от которых зависит жизнь людей
— Бизнес-системы
— Системы целевого назначения

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

Влияние итеративных подходов на предварительные условия


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

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

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

Одно популярное практическое правило состоит в том, чтобы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения дополнительных требований и выполнять по мере работы систематичный контроль изменений, принимая только самые важные требования. Возможен и другой вариант: вы можете определить заранее 20% только самых важных требований и разрабатывать оставшуюся часть ПО небольшими фрагментами, определяя дополнительные требования и дорабаты — дорабатывая проект приложения по мере прогресса.

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

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

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

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



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

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

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

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

Не имея хорошего определения проблемы, можно потратить усилия на решение не той проблемы.

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



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

— Наличие явных требований помогает избегать споров.

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

Миф о стабильности требований ПО



Возможно, вы считаете, что «Понтиак Ацтек» — самый великолепный автомобиль
из когда-либо созданных, являетесь членом Общества Верящих в Плоскую Землю
и каждые четыре года совершаете паломничество в Розуэлл, штат Нью-Мексико, на
место приземления инопланетян. Если это так, можете и дальше верить в то, что
требования в ваших проектах меняться не будут. Если же вы уже перестали верить
в Санта-Клауса или хотя бы прекратили признаваться в этом, вы можете кое-что
предпринять, чтобы свести зависимость от изменений требований к минимуму.

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



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

Убедитесь, что всем известна цена изменения требований. Думая о новой
функции, клиенты приходят в возбуждение. Кровь у них разжижается, переполняет продолговатый мозг, и они впадают в эйфорию, забывая обо всех собраниях, посвященных обсуждению требований, о церемонии подписания и всех документах. Угомонить таких одурманенных новыми функциями людей проще всего, заявив: «Ого, это действительно прекрасная идея! Но ее нет в документе требований, поэтому я должен пересмотреть график работы и смету, чтобы вы могли решить, хотите ли вы реализовать это прямо сейчас или позднее». Слова «график» и «смета» отрезвляют куда лучше, чем кофе и холодный душ, и многие требования быстро превращаются в пожелания.

— Задайте процедуру контроля изменений

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

— Оставьте проект, если требования особенно неудачны

Помните о бизнес-модели проекта

Контрольный список: требования


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

Не все вопросы будут актуальны для вашего проекта. Если вы работаете над
неформальным проектом, над некоторыми вопросами даже не нужно задумываться. Другие вопросы важны, но не требуют формальных ответов. Однако если вы работаете над крупным формальным проектом, вам, наверное, следует ответить на каждый вопрос.

Специфические функциональные требования


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

Специфические нефункциональные требования (требования к качеству)


— Определено ли ожидаемое пользователем время реакции для всех необходимых операций?
— Определены ли другие временные параметры, такие как время обработки данных, скорость их передачи и пропускная способность системы?
— Определен ли уровень защищенности системы?
— Определена ли надежность системы, в том числе такие аспекты, как следствия сбоев в ее работе, информация, которая должна быть защищена от сбоев, и стратегия обнаружения и исправления ошибок?
— Определены ли минимальные требования программы к объему памяти и
свободного дискового пространства?
— Определены ли аспекты удобства сопровождения системы, в том числе способность системы адаптироваться к изменениям специфических функций, ОС и интерфейсов с другими приложениями?
— Включено ли в требования определение успеха? Или неудачи?

Качество требований


— Написаны ли требования на языке, понятном пользователям? Согласны ли с этим пользователи?
— Нет ли конфликтов между требованиями?
— Определено ли приемлемое равновесие между параметрами-антагонистами, такими как устойчивость к нарушению исходных предпосылок и корректность?
— Не присутствуют ли в требованиях элементы проектирования?
— Согласован ли уровень детальности требований? Следует ли какое-нибудь требование определить подробнее? Менее подробно?
— Достаточно ли ясны и понятны требования, чтобы их можно было передать независимой группе конструирования? Согласны ли с этим разработчики?
— Каждое ли требование релевантно для проблемы и ее решения? Можно ли проследить каждое требование до его источника в проблемной среде?
— Можно ли протестировать каждое требование? Можно ли будет провести независимое тестирование, которое позволит сказать, выполнены ли все требования?
— Определены ли все возможные изменения требований и вероятность каждого изменения?

Полнота требований


— Указаны ли недостающие требования, которые невозможно определить до начала разработки?
— Полны ли требования в том смысле, что если приложение будет удовлетворять всем требованиям, то оно будет приемлемо?
— Не вызывают ли какие-нибудь требования у вас дискомфорта? Исключили ли вы требования, которые не поддаются реализации и были включены лишь для успокоения клиента или начальника?

Стив Макконнелл
Теги:
Хабы:
+16
Комментарии 21
Комментарии Комментарии 21

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн