Фаза 1: Что мы делаем?
В предыдущем поколении дизайна программ (называемом процедурным дизайном ), это называлось “созданием анализа требований и спецификаций системы”. При этом, конечно, были потери; документы с пугающими названиями, которые могли стать большими проектами по своему собственному праву. Однако это была хорошая идея. Анализ требований говорит: “Создавая список руководящих указаний, мы будем использовать его, чтобы знать, когда работа выполнена и потребитель удовлетворен”. Спецификации системы говорят: “Это описание того, что (а не как) программа будет делать, чтобы удовлетворить требованиям ”. Анализ требований является соглашением между вами и потребителем (даже если потребитель работает в вашей компании или является другим объектом или системой). Спецификации системы - это вершина исследований проблемы и, в некотором смысле, открытие в том, будет ли это выполнено и как долго это будет выполняться. И то и другое требует договоренности всех людей (и поэтому они со временем будут изменяться), я думаю, что лучше сохранять их настолько голыми, насколько возможно — идеально для списков и основных диаграмм — для сохранения времени. Вы можете иметь другие ограничения, требующие от вас включить их в увеличивающуюся документацию, но пытайтесь оставить начальную документацию как можно меньше и кратче - это может быть сделано в несколько приемов группового мозгового штурма с лидером, который создает описание. Это не только требует отдачи от каждого, это также способствует приобретению начальных соглашений для каждого в команде. Конечно, может быть более важно начать проект с большим энтузиазмом.
Необходимо сосредоточится на самом главном из того, что вы пробуете выполнить в этой фазе: определить то, что система предполагает выполнять. Наиболее ценный инструмент для этого - это коллекция, называемая “использование причин ”. Использование причин идентифицирует ключевые особенности системы, которые будут реализовывать некоторые классы, которые вы будете использовать. Таким образом, хорошо описываются ответы на такие вопросы, как [10]:
Если вы разрабатываете банкомат, например, использование причин в обычном аспекте функциональности системы позволит описать, что банкомат будет делать во всех возможных ситуациях. Каждая из этих “ситуаций” называется сценарием, а использование причин может помочь при сборе сценариев. Вы можете думать, что сценарий как вопрос, начинающийся с: “Что делает система, если..?” Например, “Что делает банкомат, если пользователь недавно положил чек, меньше 24 часов назад, и нет достаточного количества денег, так как чек еще не был оприходован, для выполнения нужного снятия?”
Использование диаграмм причин, несомненно, проще для предотвращения зависаний в реализации вашей системы:
Каждая взаимодействующая персона представляет “действующее лицо”, которое обычно является человеком или любым другим родом свободного агента. (Это даже может быть другая компьютерная система, как в случае с “ATM”.) Прямоугольник представляет границы вашей системы. Эллипс представляет использование причин, которые описывают ценную работу, выполняемую системой. Линии между действующими лицами и причинами использования представляют взаимодействие.
Не имеет значения, как действительно реализована ваша система, так как она выглядит так для пользователя.
Использование причин не обязательно должно быть чрезвычайно сложны м, даже если лежащая в основе система сложна. Это предназначено для показа системы, как она видна пользователю. Например:
Использование причин вырабатывает спецификации требований, определяя все взаимодействия, которые пользователь может иметь в системе. Вы пробуете обнаружить весь набор использования причин для вашей системы и когда вы сделаете это, то вы получите ядро того, для чего предназначена система. Великолепная вещь - это фокусировка на использовании причин, так как это всегда наталкивает вас на сущность и предохраняет вас от отклонения от проблемы, являющейся критичной при выполнении работы. Таким образом, если вы имеете полный набор причин использования, вы можете описать вашу систему и перейти к следующей фазе. Вероятно, вы не обнаружите их все с первой попытки, но это ничего. Все они откроют себя в свое время и, если вы требуете точные спецификации системы, вы обманитесь.
Если вы ошиблись, вы можете выполнить быстрый этой фазы, используя инструмент грубого приближения: описание системы в несколько параграфов, а затем взглянуть на существительные и глаголы. Существительные могут подсказать действующих лиц, контекст использования причин (например, “холл”), или артефакты, управляемые при использовании причин. Глаголы могут подсказать взаимодействие между действующими лицами и указать шаги при использовании причин. Вы также обнаружите, что существительные и глаголы вырабатывают объекты и сообщения на фазе дизайна ( заметьте, что использование причин описывает взаимодействие между подсистемами, так что “существительные и глаголы” технически можно использовать как инструмент, генерирующий использование причин [11].
Граница между использованием причин и действующими лицами может выходить за пределы пользовательского интерфейса, но это не определяет интерфейс пользователя. О процессе определения и создания интерфейса пользователя смотрите Software for Use by Larry Constantine и Lucy Lockwood, (Addison-Wesley Longman, 1999) или сходите на www.ForUse.com.
Хотя это черная работа, в этой точке важны некоторые основы планирования. Теперь у вас есть обзор того, что вы будете строить, так что вы вероятно способны оценить, сколько это может длиться. Большинство факторов здесь вступают в игру. Если вы рассчитываете длинный план, то компания может решить не осуществлять его (и при этом используются их аргументы, иногда более весомые, чем — это хорошая вещь). Или управляющий может уже решил, сколько такой проект может длиться и попробовать пересмотреть вашу оценку. Но лучше иметь реальную оценку с начала и следовать ее решениям. Имеется много попыток полностью согласоваться с техникой оценки (большинство таких способов диктуются торговой политикой), но, вероятно, лучший подход - основываться на ваш опыт и интуицию. Нутром почувствуйте, сколько времени это займет, затем умножьте это на два и добавьте 10 процентов. Возможно, ваше нутро чувствует правильно; вы можете выполнить какую-то работу за это время. “Удвоение” превратится во что-нибудь приличное, а 10 процентов уйдет на финальную полировку и детали [12]. Однако, вы хотите объяснить это и, независимо от жалоб и манипуляций, которые случаться при использовании такого планирования, это только кажется, что это работает не так.
