Западня со стороны требований




 

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

Цитата из докладной записки авиакомпании British Airways, опубликованная в журнале "Pilot Magazine", декабрь 1996 г.

 

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

Составление спецификации – это большая ответственность.

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

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

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

Проблемный вопрос для вас. Напишите короткую инструкцию по завязыванию бантиком шнурков на ботинках. Попробуйте!

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

 

 

Подсказка 57: Некоторые вещи лучше сделать, чем описывать

 

 

И наконец, существует "эффект смирительной рубашки" – конструкции, которая не оставляет кодировщику пространства для импровизации и отнимает усилия программирования любого рода. Кое-кто говорит, что хотел как лучше, но он неправ. Зачастую лишь на стадии написания текста некоторые варианты становятся очевидными. Во время написания программы вы можете подумать следующее: "Посмотрим вот сюда. Поскольку я написал эту подпрограмму именно таким образом, я смог добавить эту функциональную возможность практически без усилий". Или: "В спецификации говорится, что нужно сделать вот это, но я смог добиться практически того же результата, сделав по-другому, но затратил на это вдвое меньше времени". Ясно, что вы не обязаны вносить изменения, но у вас не было бы и намека на эту возможность, если бы ваши действия сдерживались конструкцией, изобилующей предписаниями.

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

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

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

 

Другие разделы, относящиеся к данной теме:

 

• Стрельба трассирующими

 

Вопросы для обсуждения

 

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

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

 

Круги и стрелки

 

[Фотографии] с кругами и стрелками и несколькими строками на обратной стороне, объясняющими, кто есть кто, должны были стать свидетельством против нас…

Арло Гатри, Ресторан Алисы

 

Начиная со структурного программирования, через бригады главного программиста, CASE-средства, разработку методом «водопада», спиральную модель, метод Джексона, диаграмму «сущность-связь», облака Буча, метод объектного моделирования, метод Objectory, метод Коуда/Йордона до современного языка UML информатика никогда не страдала от недостатка методов, стремившихся уподобить программирование инженерной дисциплине. Каждый метод имеет своих приверженцев, и каждый из них переживает период популярности. Затем ему на смену приходит следующий. Долгая жизнь была суждена возможно лишь одному из всех этих методов – структурному программированию.

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

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

 

 

Подсказка 58: Не будьте рабом формальных методов

 

 

Формальные методы имеют ряд серьезных недостатков.

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

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

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

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-03-31 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: