Адаптация унифицированного процесса
Унифицированный процесс представляет собой обобщенную методологию разработки программного обеспечения любого типа, поэтому в данной лекции представлен конкретный вариант процесса, базирующийся на унифицированном процессе, используемом для разработки программного обеспечения интернет-портала. Этот процесс основывается на личном опыте автора книги, и приводится лишь в качестве варианта унифицированного процесса. Этот процесс можно модифицировать в соответствии с определенными условиями, в зависимости от требований сторон-участников проекта.
В начале работы над любым проектом определяется область, представляющая собой обзор или описание желаемого результата. Если все участники проекта согласны с определенной областью, то далее следует сбор требований, результатом которого является функциональный проект. По завершении сбора требований разрабатывается технический проект, определяющий построение программного решения; результатом является техническая спецификация. Функциональный проект отвечает на вопрос "что", а технический проект – на вопрос "как". После описания решение передается в разработку для реализации построения и тестирования согласно технической спецификации. По завершении процесса разработки программное решение тестируется согласно функциональной спецификации. После прохождения всех необходимых тестов осуществляется публикация программы или ее доставка клиенту, и проект считается завершенным. На рисунке 6.1 показан общий процесс построения веб-сайта.
Рис. 6.1. Общий процесс построения веб-сайта
Многие новые методологии, например, Extreme Programming и Agile, усложняют и расширяют унифицированный процесс. Они предлагают разработчикам возможности по оптимизации процесса создания программного продукта.
Extreme Programming предлагает такие подходы, как исключение документации, уменьшение времени цикла разработки и программирование парами. Элементы Extreme Programming представлены в методологии, обсуждаемой в данной лекции, так как они эффективны при разработке решений для интернета.
Каждый этап имеет промежуточный результат или набор промежуточных результатов, являющихся основанием для дальнейшей работы над проектом. Область обычно является документом, в котором приводятся требования заказчика и оценка разработки решения, отвечающего этим требованиям. В результате сбора требований создается функциональная спецификация, описывающая функционирование программного продукта и его внешний вид. Этап технического проекта заканчивается созданием технической спецификации. В результате разработки и программирования создается группа файлов, которые проходят модульное тестирование, отвечающих требованиям технической спецификации, а также программа инсталляции решения. Итогом этапа тестирования продукта является документ, свидетельствующий о том, что в результате программирования разработано программное решение, отвечающее требованиям функциональной спецификации. Наконец, на этапе реализации выставляется счет, сообщается о выходе программы пользователям и создается инструкция по эксплуатации программного продукта.
Примечание. Примеры документов, описываемых в данной лекции, доступны на веб-сайте автора книги.
Передача промежуточных результатов между этапами и командами разработки в рамках программного проекта часто является причиной разногласий. Успех проекта зависит от эффективности работы сотрудников отдела продаж, рекламы, бизнес-аналитиков и инженеров по программному обеспечению. При появлении разногласий порой бывает очень сложно добиться слаженной работы. Эффективной стратегией обеспечения согласованности действий специалистов является такая организация работы, когда при разработке промежуточных результатов руководствуются исключительно требованиями заказчика. Степень производительности в этом случае напрямую зависит от выполнения требований клиента.
В команде разработки ее сотрудники являются клиентами по отношению к друг другу. Например, если функциональной спецификации не хватает ясности в выражении конечного результата при ее прочтении инженером по программному обеспечению, бизнес-аналитик должен усовершенствовать документ, а не надеяться на самостоятельность этого инженера.
Если установка программного обеспечения осуществляется неправильно, то разработчик программы установки или сценария должен ее откорректировать, чтобы системный персонал смог установить программу без проблем. Таким образом, разработчик является клиентом бизнес-аналитика, а системные инженеры – клиентами разработчика. Ответственность за эффективное использование клиентом промежуточных результатов является единицей измерения профессиональной эффективности команды. Если члены команды разработки уважают и любят разрабатываемый продукт, то эффективность их работы будет высока. Привейте команде разработки проекта дисциплину и чувство ответственности, и успех не будет зависеть от индивидуальных особенностей и уровня каждого специалиста в команде разработки.
Еще одной причиной спорных ситуаций является время, затрачиваемое на создание программного продукта. Как правило, чем дольше работа над проектом, тем больше создается функциональных возможностей и программ. Исходные требования могут со временем измениться, поэтому уменьшение сроков доставки снижает вероятность того, что требования заказчика изменятся. Это также понижает уровень стрессовых ситуаций в команде разработки.
Кто-то поспешит заметить, что требования устанавливаются владельцем, а не командой разработки. Уменьшение времени на разработку программного продукта приведет к успеху только при сужении области разработки или расширении штата разработчиков. Естественно, что требования устанавливаются владельцем, поэтому при "урезке" требуемой функциональности владелец удовлетворен не будет. Наилучший способ решить данную проблему – сузить область, т.е. разбить проект на более мелкие. В данном случае владельцу можно предоставить план работы над проектом. Согласно унифицированному процессу такие мелкие проекты называются итерациями. По завершении работы над всеми итерациями осуществляется реализация готового продукта. Предпочтительно разрабатывать программный продукт с использованием большего числа итераций. Одну большую задачу труднее выполнить, она сопряжена с большим риском, чем решение последовательных мелких задач, приводящих к получению такого же продукта.
Что такое диаграмма Ганта?
Предсказывать будущее сложно. Необходимо определить выполняемые задачи и тех, кто должен заниматься их выполнением. Следует определить зависимости для этих задач. Например, нельзя выехать на машине из гаража, не открыв ворота.
Диаграмма Ганта предназначена для графического отображения следующих аспектов.
Задачи проекта.Лица, ответственные за выполнение задач.Зависимости задач от других задач и событий.Предполагаемые даты завершения задач.
Диаграмма Ганта отражает видение предстоящего процесса. Диаграмма Ганта не поможет точно предсказать будущее, однако обеспечит простоту восприятия предположений другими людьми.
Диаграммы Ганта создаются c помощью программного обеспечения по управлению проектом, например, Microsoft Project или Visio. Диаграмма (см. рис. 6.3) разработана с помощью Microsoft Project.
увеличить изображение
Рис. 6.3. Диаграмма Ганта плана демонстрационного проекта, созданная на этапе определения области работы
Проект области дает начальное понимание объема работ. Если предположения оценки области правильны, и план показал, что работу нельзя завершить в установленные сроки, следует адаптировать стратегию. Это потребует от владельца принятия альтернативной области работы, применения этапного подхода к разработке программного решения за счет увеличения числа итераций либо перехода команды разработки к альтернативному варианту проекта.
После разработки плана и создания всех документов, связанных с перспективным планированием, план представляется владельцу. После принятия плана владельцем проект возвращается менеджеру проекта для утверждения. При несогласии владельца с перспективным планом менеджеру по счетам необходимо предоставить другие варианты документа, определяющего область работ, а также план проекта.
Что такое фасад?
Фасад в данном контексте не является объектно-ориентированным методом программирования. Этот элемент можно назвать ограниченным прототипом или креативной экспериментальной моделью с небольшой степенью реальности. Определение фасада позволяет владельцу представить себе программное решение перед получением окончательного продукта. Фасад демонстрирует программное решение в действии в окне браузера.
Моделирование решения происходит по окончании сбора требований и отражения их в функциональной спецификации. На данном этапе предполагается, что владелец точно представляет себе конечный результат, и что это нашло свое отражения в документе. Тем не менее, в реальной жизни после просмотра предварительного варианта проекта владелец может добавить в него что-нибудь.
Во многих интернет-проектах владелец сконцентрирован на том, как конечный пользователь будет взаимодействовать с программой. В процессе создания модели и построения решения фасад подтверждает внешний вид и функции программного обеспечения. Проекты веб-порталов обычно включают в себя следующие промежуточные результаты.
Конфигурации и сценарии источников данных.Файлы двоичного кода и сценариев, получающие данные и применяющие правила функционирования.Файлы сценариев, используемые для применения логики представления.
Почему бы не реализовать логику представления перед построением прочих элементов? Если программное решение поддерживает абстракцию от бизнес-логики и логики представления, то в первую очередь можно заняться логикой представления. Технологией, поддерживающей такую абстракцию, является язык XML. В рамках данной лекции мы будем работать с форматом XML.
Совместные усилия по программированию правил функционирования, сценариев и источников данных приводят к созданию документов XML, необходимых логике представления для получения конечного результата. Перед построением источников данных или программы разработчик создает техническую спецификацию, устанавливающую метод, согласно которому функционируют данные элементы, включая создаваемый код XML.
Это означает, что код XML моделируется перед построением программы. Следует проверить модель XML перед построением источника данных или программы, применяющей правила функционирования. Необходимо написать файлы сценариев, используемые для применения логики представления, и это можно сделать перед созданием программы поддержки (или после). При изменении требований корректировка файла сценария логики представления потребует меньших усилий, чем изменение скомпилированного кода бизнес-объекта. Если логика представления оформлена в виде XSL, XSLT или другой технологии представления (например, веб-форм ASP.NET), то для тестирования файла сценария логики представления используются статические документы XML.
Проверка функциональной спецификации является значимым действием, направленным на подтверждение корректности модели и технической спецификации. Часть процесса моделирования, в которой происходит описание фасада, направлена на достижение именно этой цели. Ниже приведены конкретные задачи, решаемые при работе над фасадом в процессе моделирования.
Создание документа XML для каждого рассматриваемого события решения, имеющего место в проекте портала.Построение логики представления.Визуальная демонстрация функционирования продукта и подтверждение корректности его функционирования..
По завершении работы над фасадом можно выполнять оставшуюся часть работы по созданию кода правил функционирования и источника данных. Фасадную часть также можно продемонстрировать владельцу. Хотя она и не является полнофункциональной, но все-таки отражает процесс работы и показывает, что все идет по плану. Владелец чувствует себя непосредственным участником процесса и берет на себя некоторую ответственность за конечный результат разработки.
Созданные файлы логики представления фасадной части не должны изменяться в процессе построения решения за исключением случаев, когда требуется поддержка других версий браузера или платформ клиента.
Демонстрационная постановка задачи
Владельцу нужен веб-сайт, на котором менеджер сможет публиковать рецепты. Сотрудники, подчиненные менеджеру, должны размещать свои комментарии относительно рецептов. Каждый может читать комментарии для рецептов, опубликованных соответствующим менеджером.
Владельцу требуется узел для приложения.
Владелец желает получить завершенный проект через три недели, к 22 июня, на которое назначена презентация пивоваренных достижений.
Диаграмма данных
Описание контейнера или таблиц.Описание всех полей или атрибутов в таблице или контейнере.Описание ключей, используемых в таблицах.
В данном разделе представляется описание слоя данных или способа хранения данных в системе. Классовая диаграмма является хранилищем данных внутри памяти, а диаграмма данных – аппаратной системой хранения информации. В этом разделе приводится описание модели базы данных, а также файлов и элементов каталогов.
Диаграмма классов
Описание назначения каждого класса.MВзаимоотношения с другими классами (наследование, композиция и накопление).Функции в объекте (предназначение, описание интерфейса, параметры, типы данных).Параметры состояния инициализации, применяемые к решению и связанным с ним объектам.Псевдокод функций.
Данный раздел содержит код, обеспечивающий поддержку экземпляров объектов, описанных в объектной модели. Эти два раздела кажутся аналогичными, однако различие заключается в том, что определенные классы могут представлять несколько экземпляров объектов. Модель класса обеспечивает абстракцию от объектов реального мира к структурам кода, представляющим эти объекты.
Допущения
Указывать любую новую информацию, которая поможет разобраться в деталях программного продукта, влияющих на вынесение решения.
Эта область позволяет автору спецификации выделить определенные ситуации или условия, которые нужно согласовать с владельцем. Например, владелец мог заключить контракт со студией графического дизайна на изготовление рисунков, отображаемых на сайте. Если эти рисунки не соответствуют пользовательскому интерфейсу, созданному при разработке решения, фирма, создавшая рисунки, будет отвечать за их изменение.
Функциональная спецификация
Функциональная спецификация описывает ожидаемый результат работы над проектом с точки зрения владельца. Она является подготовительным этапом перед составлением технического проекта и обеспечивает понимание владельцем конечного результата. В этом документе указываются действия, выполняемые программным решением. Видимые промежуточные результаты нужно подробно описать, чтобы разработчик создавал программное решение без дополнительных вопросов к владельцу. Функциональная спецификация создается с технически абстрагированной точки зрения и не содержит технических инструкций по созданию решения.
| 1 | Функциональная спецификация | Бизнес-аналитик. |
| 2 | Квалифицированная оценка функциональных требований | Разработчики. |
| 3 | Квалифицированный план проекта для функциональных требований | Менеджер проекта. |
| 4 | Согласие владельца с определенными функциональными требованиями, даты окончания работ в плане | Менеджер проекта. |
Функциональная спецификация занимает объем не более 30 страниц и состоит из следующих элементов.
Определение каждого функционального требования; это нужно, чтобы специалисты по разработке и контролю качества могли определенным образом называть компоненты спецификации в технической спецификации и сценариях тестирования.Рисунки или диаграммы каждого окна, связанного с результатом проекта или представляемого конечному пользователю.Запись контроля за изменениями.Содержание.Титульная страница с именем владельца и названием проекта.Нижний колонтитул с именем компании разработки, сведениями о конфиденциальности информации и датой печати документа.Идентификация проекта запоминающимся именем.
Хорошим методом уникальной идентификации каждого элемента в функциональной спецификации является нумерация фрагментов текста, описывающих работу того или иного компонента. Данный метод целесообразен для описания субординации функциональных спецификаций.
На рисунке 6. 4 приведен пример фрагмента текста в документе, в котором используется иерархическая нумерация для определения функциональных спецификаций.
Рекомендуемый объем функциональной спецификации не должен превышать 30 страниц, так как он должен оперативно просматриваться членами команды разработки перед планированием и началом непосредственной работы над программным решением. Не создавайте спецификацию произвольного размера. Если функциональные требования занимают более 30 страниц, не урезайте их, а вместо этого создайте еще одну функциональную спецификацию для определения всех функциональных требований.
Рис. 6.4. Уникально определенные с помощью иерархической нумерации функциональные требования
При наличии нескольких небольших функциональных спецификаций вместо одной в проекте появляется большее число итераций. Функциональная спецификация может рассматриваться как область итераций. Функциональная спецификация определяет мельчайшие части проекта, с которыми нужно ознакомить владельца.
Разработка всегда осуществляется согласно функциональным требованиям. Итерации уменьшают цикл разработки и снижают вероятность получения некорректного результата. Чем больше в проекте итераций, тем больше промежуточных результатов, с которыми нужно ознакомить владельца. Ему будет намного спокойнее наблюдать за успешным выполнением промежуточных этапов проекта, чем находиться в томительном ожидании конечного результата. Выполнение проекта с итерациями будет "занимать" голову владельца позитивными событиями, связанными с проектом. Если владелец не может видеть или понять промежуточные результаты, или если между ними проходит длинный промежуток времени, то он начинает отрицательно судить о ходе выполнения проекта.
На титульной странице спецификации необходимо разместить имя владельца, название проекта, область контроля за изменением, область нижнего колонтитула и содержание. Имя владельца и название проекта определяют происхождение проекта.
Нижний колонтитул сообщает о компании, издавшей данный документ, о дате издания и конфиденциальности документа.
Заключение о конфиденциальности имеет юридическую силу, если документ предоставляется другой организации, не имеющей права на его просмотр. При составлении с компанией контракта на разработку ПО владелец обычно подписывает договор о неразглашении, который запрещает предоставление полученных материалов другим организациям. Если документ имеет статус конфиденциального, то получатели несут правовую ответственность при нелегальном прочтении документа. Владелец должен соблюдать большую осторожность при распространении документа, а получатель документа должен понимать требования конфиденциальности перед прочтением документа.
Область контроля за изменениями на лицевой странице документа определяет дату, номер версии, обзор изменений, внесенных в документ, с указанием авторов изменений. На рисунке 6.5 показан пример титульной страницы функциональной спецификации.
Примечание. Многие текстовые процессоры, такие как Microsoft Word и Word Perfect, автоматически создают оглавление. Для правильной работы генератора оглавления необходимо, чтобы в тексте использовались определенные стили. Например, оглавление на рисунке 6.5 сгенерировано с использованием стилей Heading 1 (Заголовок 1) и Heading 2 (Заголовок 2). Многие авторы спецификаций допускают ошибку, создавая весь документ в текстовом процессоре и игнорируя форматирование текста.
Примечание. Документ Word, использованный в качестве демонстрационной функциональной спецификации, доступен с исходным кодом на веб-сайте автора книги.
увеличить изображение
Рис. 6.5. Титульная страница демонстрационной функциональной спецификации
Разработка шаблона функциональной спецификации или ее общей структуры является хорошо зарекомендовавшим себя конструктивным подходом, который позволяет всем пользователям документа отыскивать определенную информацию по аналогии с другими спецификациями, изученными ранее.Недостатком такого подхода является то, что однажды допущенная ошибка может повторяться снова и снова.
Чтобы привести в равновесие конструктивность и предоставление документации, отвечающей требованиям организации, сконцентрируйтесь на сути проекта. При необходимости отклонитесь от шаблона, принятого по умолчанию, чтобы поточнее описать работу программного решения.
Если функциональная спецификация изменяется в каждом проекте, то следует изменить шаблон документа. Ниже приведены основные положения, которыми следует руководствоваться при составлении функциональной спецификации.
Функциональные задачи
Перечислить все возможности сайта (избегайте слишком подробного описания).Указать получаемые результаты в терминах бизнес-логики.
Данная область содержит обзор действий, реализуемых программным решением, с точки зрения владельца. Она определяет краткие термины, представляющие типы функциональностей в программном решении, конструктивно используемые всеми участниками проекта. Данная область содержит описание всех элементов, упомянутых в документе определения области работы.
Модульное тестирование
Описание тестовой структуры решения.Данные "крайнего случая", используемые при модульном тестировании кода.
В данном разделе приводится описание возможностей программного решения, если оно создано правильно. Здесь можно привести тест или набор тестов, которые нужно создать для проверки программного решения и заключения о правильности функционирования решения в процессе тестирования. В данном разделе необходимо описать данные, обеспечивающие условия "крайнего случая" для модульного тестирования. "Крайний случай" обычно представляет собой обработку строк, содержащих специальные символы, таких как ~ ` ! @ # $ % ^ & * ( ) _ + - { } [ ] \ | ; : ' " < > ? / . ,.
Данные "крайнего случая" позволяют определить время выполнения при обработке большего объема данных по сравнению с обычным, с которым чаще всего взаимодействует решение.
Объектная модель
Результаты работы над фасадной частью.
В данном разделе представляются сущности, выявленные в процессе работы над фасадной частью проекта. Здесь приводится сводная диаграмма, отражающая связь этих объектов в реальном мире. Данный раздел предназначен для документирования аналитических заключений, появившихся в результате разработки фасада, а также для обеспечения вспомогательного базиса для создаваемой модели классов.
Области функциональных задач
Описать в деталях функциональные задачи.Описать, как работает функциональная задача с точки зрения клиента.Описать построение всех окон, входящих в функциональную задачу.Описать возможные варианты обработки взаимодействия с конечным пользователем.Описать исключения относительно возможных ответов на незапланированные взаимодействия конечного пользователя.
Для каждой функциональной задачи, определенной в области Functional Objectives (Функциональные задачи), должна присутствовать область функциональной задачи. Эта область подробно описывает функциональную задачу: бизнес-логику, которой она принадлежит, способ функционирования (с точки зрения владельца) компонентов решения, относящихся к задаче. Следует определить и обрисовать экранные и системные процессы, привести структуру каждого окна, определить сценарии для успешных и неудачных операций. Общей ошибкой в функциональных задачах является отсутствие описания того, что происходит в случае успешных и неудачных событий. Явное описание разрешенных и запланированных событий конечного пользователя и ожидаемых результатов позволит избежать ошибок при определении функциональности. Например, можно составить таблицу, описывающую события и соответствующие ожидаемые ответы программного решения (см. рис. 6.6).
Рис. 6.6. Демонстрационные сценарии и исключения функциональной спецификации
Оценка области
Целью оценки области является создание основы для определения времени разработки проекта. Разработчики создают оценку области для информирования команды разработки о необходимых технических ресурсах. Тезисы оценки предоставляют дополнительную информацию о том, что, по мнению самих разработчиков, хочет получить в итоге заказчик. В оценке описывается реализация отдельных аспектов проекта. Многие программисты считают предоставление оценки области задачей рискованной и сложной, так как на данном этапе еще не определены требования к проекту. Разумеется, приведенная демонстрационная постановка задачи не совсем точна, и на получение программного решения может потребоваться от трех недель до трех лет в зависимости от требований к проекту.
Эффективной стратегией по оценке области является определение всех промежуточных результатов, необходимых для создания программного решения. Промежуточные результаты уточняются в рамках допущений, связанных с их получением и сопутствующим риском. Промежуточные результаты следует определять по возможности самым широким образом в отношении требований, которым они должны удовлетворять. Сотрудники, участвующие в оценке, рассматривают тезисы разработчика как контрпродуктивные меры, используемые разработчиками для собственной защиты. Уточненные тезисы являются начальным эскизом, описывающим функционирование программного решения. Разработчики должны подробнейшим образом описать ключевые моменты для информирования команды об аспектах, влияющих на объем ресурсов, необходимых для разработки программного решения. На рисунке 6.2 в качестве основы для веб-сайта, на котором публикуются рецепты пивоварения, использована демонстрационная оценка, приведенная выше.
увеличить изображение
Рис. 6.2. Пример оценки области, представленный в виде электронной таблицы
Окна программного решения
Перечислить все окна, являющиеся частью решения. Имена окон должны использоваться в тексте документа.
В данной области предлагается способ наименования или идентификации всех окон, изменяющихся или создаваемых в процессе работы. Наиболее распространенной ошибкой функциональной спецификациях является то, что она не отражает навигационные возможности сайта. Идентификация всех окон в начале процедуры уменьшает риск возникновения данной ошибки.
Определение функциональности
Целью определения функциональности является получение от владельца подробного описания результата работы над проектом. Ниже представлены цели проведения этапа определения функциональности.
Определить, каким образом существует и функционирует программное решение, чтобы разработчик с наименьшими аналитическими затратами мог создать это решение без запроса дополнительных сведений от владельца.Согласовать с владельцем результат работы над проектом: представление программного решения, способ его функционирования после сдачи проекта, дату окончания работ.Повторно вывести оценку объема работы и сроков его выполнения.Получить согласие владельца с представлением программного решения, его функциональными возможностями и датой окончания работ.
Как говорилось выше, способ существования программного решения и его функции составляют функциональное требование к программному решению. Фразу "способ существования и функционирования решения" можно интерпретировать очень вольно, поэтому следует сузить область функциональности в контексте программного решения. Задайте владельцу следующие вопросы и получите ответы, уточняющие функциональные требования, предъявляемые к программному решению для интернета.
Где будет расположено программное решение в процессе функционирования?
Решение можно разместить на сайте владельца либо на сайте сторонней организации. Платформу (операционная система, веб-сервер или другой продукт, предназначенный для оптимизации работы) можно выбрать заранее и оговорить для совместного использования с разрабатываемым решением. Если владелец не знает ответа на данный вопрос, тогда специалист предоставляет свои рекомендации.Каких клиентов будет обслуживать программное решение? Интернет-решения не всегда поддерживают клиент браузера. Иногда требуются другие способы поддержки программных решений, расположенных в различных местах интернета, с данными, которые нужно обрабатывать перед предоставлением конечному пользователю. Специалист определяет всех потребителей данных и функциональных возможностей.Что требуется для работы программного решения? Интернет-решения могут обслуживать и другие серверы, расположенные в интернете.
В решении можно предусмотреть получение данных из другой системы перед обработкой информации. Специалист определяет всех поставщиков данных и функциональных возможностей.Кто взаимодействует с системой? Выявляются конечные пользователи, действия, которые они выполняют в программном решении, и их требования к решению. Каковы роли, существующие в технологическом процессе, и какова ответственность, связанная с этими ролями?Какие сущности реального мира представляются в программном решении?
Выявляется и документируется объектная модель программного решения. Необходимо определить и смоделировать объекты в системе и их атрибуты, абстрагируясь от технических ограничений системы. Определяются объекты, описывающие действия, выполняемые программным решением.Что именно выполняет программное решение? В конечном счете программа производит над данными определенные действия перед доставкой клиенту. Для определяемых объектов моделируются и документируются соответствующие взаимодействия и описываются выполняемые действия.
При определении способа существования и функционирования решения большая часть информации зависит от мнения владельца. Часто владелец сам не знает точно, что именно он хочет видеть в результате проекта. На этапе сбора требований владелец должен сделать заключение о результатах. Определив суть программного решения, владелец выявляет промежуточные результаты и необходимые ресурсы.
При определении программного решения его нужно задокументировать с указанием того, что владелец ожидает от конечного результата проекта. Этот документ называется функциональной спецификацией. После создания функциональной спецификации оценка повторно проверяется и при необходимости пересматривается.
План проекта с основными этапами и датами является частью функциональной спецификации. Владелец должен ознакомиться с функциональной спецификацией и оценкой. Работу не следует начинать, пока он письменно виде не подтвердит функциональность, описанную в спецификации. В таблице 6.2 приведены промежуточные результаты, необходимые для выполнения этапа определения функциональности.
Определение модели
Моделью называется инструкция по построению программного решения. Она объясняет способы размещения программного решения на узле и определяет задачи, необходимые для построения решения. Промежуточные результаты процесса построения также выявляются в модели. В идеальном случае модель содержит достаточное количество информации, чтобы программист создал программное решение.
Модель состоит из диаграмм, текста, рисунков, псевдокода и других элементов, определяющих технические особенности. Промежуточные результаты процесса разработки модели носят следующие названия: фасад, сценарии функционального тестирования и техническая спецификация (см. табл. 6.3).
| 1 | Фасад | Бизнес-аналитик и разработчики. |
| 2 | Техническая спецификация | Разработчики. |
| 3 | Сценарии функционального тестирования. | Контроль качества. |
Определение области проекта
Целью определения области является выделение средств на разработку. Владельцу предоставляется перспективный план программного решения и, в случае одобрения, владелец выделяет ресурсы и средства, необходимые для разработки. Перспективный план содержит:
краткое описание работы;расписание работ.
Поскольку нет уверенности в том, что владелец согласится выделить средства на весь проект, менеджер проекта определяет, какие элементы необходимо включить в перспективный план. Работа по подготовке перспективного плана проводится в соответствии с отношениями между организацией-разработчиком и потенциальным владельцем. Например, владелец может принять предложение по перспективному плану, если ему предоставят определенную информацию. В этом случае нужно приложить максимум усилий, поскольку вероятность этого достаточна велика. В другой ситуации мнение владельца о предлагаемом проекте неизвестно, поэтому приложенные усилия и временные затраты могут не привести к положительному результату, особенно при наличии конкурентов, предлагающих свои собственные решения.
Следует иметь в виду риск наложения ответственности на организацию разработки при неясности некоторых фактов. При отсутствии возможности сверки с расписанием после проведения сбора требований действия, осуществляемые на этапе определения функциональности, должны выполняться на этапе определения области. Владельца нужно предупредить о сложностях, связанных с реализацией плана, а также дать понять, что задачи, выходящие за рамки рассматриваемого уровня сложности, приведут к увеличению стоимости проекта и временных затрат.
После того как менеджер по счетам ставит задачу проекта, команда разрабатывает калькуляцию. Затем менеджер проекта проектирует план и определяет затраты времени на проект, промежуточные результаты и ключевые моменты.
Предположим, что после представления перспективного плана владелец согласился с поставленными условиями. Начинается следующий этап процесса – определение функциональности. В таблице 6.1 приведены промежуточные результаты работы на этапе определения области с указанием стороны, ответственной за их получение.
| 1 | Описание требований владельца – постановка задачи | Менеджер по счетам. |
| 2 | Квалифицированная оценка области | Разработчики. |
| 3 | Квалифицированный план проекта относительно области | Менеджер проекта. |
| 4 | Согласие владельца относительно области и предлагаемое время завершения работы над проектом | Менеджер проекта. |
Определения и сокращения
Определить любые потенциально непонятные термины, используемые в данном документе или в сфере деятельности владельца.Определить сокращения, используемые в любых местах документа и в сфере деятельности владельца.
Данная область определяет термины для предотвращения путаницы, она также фиксирует номенклатуру проекта. Приводимые здесь названия используются для описания сущностей и предотвращают применение нескольких терминов к одной и той же концепции.
Определения терминов
В данной лекции используется ряд специальных терминов, определения которых приводятся ниже.
Под владельцем подразумевается получатель веб-сайта. Термин клиент
обозначает пользователя сервера. Данное разграничение предотвращает путаницу, возникающую при равнозначном использовании этих терминов. Владельцем является начальник, сотрудник отдела продаж или рекламный представитель. Несмотря на то, что мотивы каждого владельца различны, все они выступают в роли заменителей конечных пользователей. Владелец всегда требует от сайта выполнения определенной задачи с наименьшими затратами ресурсов.
Термин конечный пользователь обозначает лицо, потребляющее некоторое программное обеспечение. Это может быть человек, использующий браузер для просмотра веб-сайтов или получающий файл по электронной почте с сервера SMTP. Конечный пользователь взаимодействует с программным решением.
Термины программное решение, автоматизированное решение и решение
являются взаимозаменяемыми. В данной лекции все они объединены в термин "решение". Решением называется комбинация программного и аппаратного обеспечения, необходимого для выполнения определенной работы.
Менеджером проекта является лицо, осуществляющее контроль над проектом с момента выделения владельцем средств на создание решения до получения клиентом готового продукта. Менеджер проекта выполняет работу по управлению требованиями клиента и отвечает за соблюдение временных рамок проекта. Если проект является долгосрочным, менеджер проекта выступает в роли ответственного за прибыль проекта.
Бизнес-аналитик является официальным адвокатом владельца и определяет, каким образом должно функционировать решение. Данное лицо, как правило, владеет функциональной спецификацией. Эту роль могут выполнять и другие лица, например, менеджеры проекта и разработчики.
Команда разработки – группа разработчиков, ведущих специалистов, менеджеров по разработке и системных архитекторов. В разных организациях должности и роли различаются. В общем случае команда разработчиков занимается написанием кода, но не осуществляет контроль над кодом и настройку оборудования.
Системные специалисты занимаются управлением оборудованием. Они отвечают за аппаратную часть, управляя, настраивая и поддерживая аппаратное обеспечение и операционную систему. Лица данной категории производят настройку решений, но не занимаются написанием кода.
Разработчик пользовательских интерфейсов занимается реализацией логики представления для конкретного программного решения. Разработчик объектов отвечает за создание кода бизнес-логики и логики данных.
UML – аббревиатура от Unified Modeling Language (Унифицированный язык моделирования). Этот язык применяется для документирования любых процессов. Для документирования программного обеспечения используются рисунки.
Use case – описание бизнес-события или процесса, осуществляемого программой.
QA – аббревиатура от Quality Assurance (Контроль качества). Обозначает членов команды разработки ПО, ответственных за тестирование программного обеспечения.
План проекта области
Далее необходимо разработать квалифицированный план проекта области. План проекта области содержит обзор этапов унифицированного процесса с датами, определенными относительно начала проекта в соответствии с оценкой разработчиков промежуточных результатов. Сюда также включаются этапы участия в проекте самого владельца, например, время, в течение которого владелец должен ответить на предложение или дать согласие на предоставление средств. На рисунке 6.3 показан демонстрационный план проекта в виде диаграммы Ганта.
После завершения проекта
После завершения проекта следует провести анализ для определения того, насколько методология процесса приемлема для организации. Процесс, представленный в данной лекции, появился в результате такого анализа. Был добавлен этап работы над фасадной частью, так как сотрудники отдела рекламы и продаж не понимали функциональную спецификацию и должны были увидеть решение на экране монитора. Циклы разработки обычно длились около шести месяцев, однако организация нуждалась в более частом усовершенствовании своего сайта. В результате разработчики сократили цикл до трех месяцев и выяснили, что усовершенствования можно проводить с большей степенью надежности из-за снижения объема выполняемых работ.
Анализ должен ответить на следующие вопросы.
Каковы различия между действительными и запланированными датами окончания этапов разработки? Этот вопрос помогает оптимизировать процесс оценки при работе над следующим проектом. Большие различия говорят о невозможности предугадать или измерить ресурсы организации.Потребовался ли в процессе разработки промежуточных результатов больший объем ресурсов, нежели запланированный в процессе оценки? Этот вопрос позволяет оптимизировать процесс оценки для использования в следующем проекте.Удовлетворен ли владелец решением? При отрицательном ответе потребуется внесение улучшений в стратегию разработки.Удовлетворен ли владелец методом доставки решения? Моменты, связанные с доставкой решения, часто опускаются при сборе требований. При отрицательном ответе потребуются дополнительные усилия для предотвращения такого финала в будущем.Какие ошибки обнаружены и каковы их причины? Являлись проблемы аномальными или систематическими, требуется ли внесение соответствующих изменений в процесс?Выгоден ли проект? Ответ на этот вопрос позволит принять решение о том, стоит ли заниматься подобными проектами в будущем.Можно ли базировать на данном решении другие продукты, которые могут заинтересовать других клиентов? Многие компании-производители ПО находят свою нишу на рынке посредством поиска ответа на данный вопрос. Если один владелец желает заполучить программное решение, то, скорее всего, найдутся и другие, готовые заплатить за решение.Можно ли реализовать повторяемый и выгодный бизнес-процесс? Если владелец обращается к компании с новым заказом, то возможна продажа автоматизированного решения для снижения стоимости работ.
| © 2003-2007 INTUIT.ru. Все права защищены. |
Постановка задачи
В начале работы по созданию программного продукта владелец видит перед собой некоторый идеал, о котором он сообщает организации, занимающейся работой над проектом. Владелец или менеджер определяют результат работы (постановка задачи). Постановку задачи можно сделать после 15-минутного телефонного разговора, зафиксировать на паре листов бумаги или подытожить в предложении из 15 слов. Ниже приведен пример постановки задачи на выполнение работы.
Построение решения
Построение решения заключается в написании разработчиком кода или сценариев конфигурации программного обеспечения в соответствии с требованиями технической и функциональной спецификациях. В качестве вспомогательных действий разработчик осуществляет модульное тестирование и контроль кода. При необходимости создается документация для конечного пользователя. В таблице 6.4 приведены промежуточные результаты этапа построения решения.
| 1 | Код | Разработчики. |
| 2 | Документация | Разработчики. |
При написании кода разработчик руководствуется технической и функциональной спецификацией. Если в процессе программирования возникают трудности, связанные с техническим или функциональным проектом, о них нужно сообщить ответственному за соответствующий документ – разработчику (для технической спецификации) или бизнес-аналитику (для функциональной спецификации). При возникновении проблем разработчик должен описать причину для внесения корректив в структуру решения. Разработчик предлагает рекомендации по решению возникающих проблем, что поддерживает ответственность за программное решение всех участников проекта. Обязанности разработчика при написании кода заключаются в следующем.
Создание кода, отвечающего требованиям технической спецификации.Проверка кода в системе хранения и контроля кода по процедурам.Модульное тестирование кода.Комплексное тестирование кода.
Разработчик создает код на своем рабочем компьютере, здесь же он выполняет модульное тестирование. Целью модульного тестирования является подтверждение правильности работы функций и классов. При возникновении ошибки модульное тестирование позволяет отыскать дефекты в логических алгоритмах или же недостатки спецификации.
При успешном завершении модульного тестирования решение нужно перенести в другую среду для проведения комплексного тестирования. Этот тип тестирования проверяет его совместную работу с другими программами, с которыми ему предстоит взаимодействовать.
При возникновении ошибки модульное тестирование позволит определить место нахождения дефектов в логических алгоритмах или недостатки спецификации.
Если решение прошло тестирование обоих видов, его нужно перенести в отдельную среду для проведения функционального тестирования, чтобы проверить соответствие требованиям функциональной спецификации.
При переносе решения с одной среды тестирования на другую необходимо внимательно управлять этими средами. В среде разработки для интернета существуют следующие среды.
Рабочая станция разработчика.Разработчики.Контроль качества.Подготовка.Производство.
Рабочая станция разработчика обеспечивает самую неконтролируемую среду. Она предназначена для создания кода и модульного тестирования, проведения анализа, экспериментов и диагностики. Среда разработки представляет собой среду сервера, дающую разработчикам доступ к установке решений для их тестирования. Она должна удовлетворять требованиям, связанным с тестированием. Установку дополнительного программного обеспечения необходимо запретить. Здесь должны находиться только те программы, которые будут присутствовать в среде, где планируется развертывание решения. Рассматриваемая среда должна ограничивать доступ в интернет и из него, поскольку она является незащищенной, и высока возможность нападения хакера. Производительность данной среды не играет особой роли, поэтому не следует выделять для нее дополнительные ресурсы.
Среду контроля качества нужно отделить от среды разработки, чтобы решения тестировались одновременно с работой программистов над другими частями программы. Данная среда предназначена для функционального тестирования сотрудниками отдела контроля качества. Среда контроля качества должна быть максимально приближена к той среде, в которой будет функционировать готовое программное решение. Доступ разработчиков в данную среду нужно запретить, чтобы решения устанавливались только старшими разработчиками или сотрудниками отдела контроля качества. Опасность предоставления доступа большому числу людей заключается в повреждении сценариев тестирования.
Эту среду отделяют от интернета, так как она не поддерживает работу с глобальной сетью, в которой будет функционировать решение. Производительность не играет особой роли, поэтому не следует выделять дополнительные ресурсы. В данной среде обеспечиваются те же физические ограничения, что и в среде функционирования решения. Например, если решение работает в распределенной среде или среде с балансировкой нагрузки, то физические ограничения нужно продублировать, чтобы максимально приблизиться к той среде, в которой могут возникнуть ошибки.
Среда подготовки обеспечивает тестирование решения для одобрения его владельцем после прохождения функционального теста. Здесь владелец является главным лицом, принимающим работу. Среда подготовки используется в следующих целях.
Рекламная демонстрация и обучение.Резервное копирование готового решения.Тестирование производительности.
Среду подготовки нужно полностью закрыть для доступа разработчиками. Ее изменения должны контролироваться системным администратором.
Среда функционирования – это узел, на котором располагается доступный клиенту продукт. Главным потребителем в среде функционирования является конечный пользователь. В данной среде важен уровень производительности. Управление средой функционирования осуществляется только системным персоналом.
Представление фасадной части
Представление фасада разработчику требует возможности отображения окна в браузере. Microsoft Internet Explorer версии 5.5 и выше преобразует XML в HTML при помощи XSL и XSLT. IE является самой подходящей платформой для представления фасадной части на компьютере с любой версией операционной системы Windows. Представление фасадной части происходит обычно на рабочем месте владельца, где возможно отсутствие связи интернетом. Фасадную часть можно установить на сервере, преобразующим XML и XSL/XSLT, однако использование браузера для выполнения преобразования всегда позволит просмотреть результат работы.
Для осуществления преобразования XML в HTML с помощью XSL или XSLT в IE добавьте инструкцию обработки (см. листинг 6.1) над остальным кодом XML. Документ XML, содержащий инструкцию обработки, будет преобразован с помощью таблицы XSL с именем MyXSLSheet.xsl. При поступлении документа XML от веб-сервера указанная таблица XSL должна поступать оттуда же. В листинге 6.1 показано, что файл MyXSLSheet.xsl располагается в том же каталоге, что и сам файл XML.
<?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="MyXSLSheet.xsl" ?>
Листинг 6.1. Processing Instruction to Transform XML into HTML (html, txt)
Представление фасадной части показывает владельцу окна его будущего программного решения в браузере. Переход от одних окон к другим реализуется посредством сценариев. После первого ознакомления с фасадной частью владелец обычно вносит свои коррективы и предложения.
В результате демонстрации фасадной части, как правило, изменяется область работы. При этом работы над проектом может сильно усложниться ввиду установленных сроков сдачи проекта. Причиной изменения области работы является то, что решение в браузере выглядит иначе, чем в функциональной спецификации. Владелец должен знать, что любое изменение сдвигает срок окончания проекта. Если владелец не согласен с изменением сроков доставки, фасадная часть упростит продажу готового решения, ведь члены команды разработки отразили в ней все требования владельца. В этом случае можно сделать следующее.
Внести несложные изменения в текущее решение на ранней стадии процесса.Немедленно предложить дополнительные услуги относительно текущего программного решения.Начать сбор требований для второго этапа проекта.
Представить другую полезную информацию, связанную
Представить use-case документацию. Представить другую полезную информацию, связанную с функциональностью проекта.
В приложении размещается самая разная информация. Если информация важна для проекта и может пригодится членам команды, работающей над проектом, то ее следует разместить в приложении.
Разработка фасада
Построение фасадной части требует взаимодействия лиц, участвующих в определении и построении решения: бизнес-аналитика, разработчика, программирующего логику представления, и разработчика бизнес-логики или логики данных. Разработчика логики представления будем называть разработчиком пользовательского интерфейса, а разработчика кода бизнес-логики и логики данных – разработчиком объектов.
Процесс работы над фасадом начинается с определения окон интерфейса (это отражено в функциональной спецификации и документе XML). Каждое окно, определенное в функциональной спецификации, находит отражение в документе XML. Разработчик пользовательского интерфейса и разработчик объектов работают совместно для разработки документов XML "крайнего случая". Документы XML "крайнего случая" представляют собой сценарии, указываемые в функциональной спецификации. Целью этих документов является выбор набора тестовых данных, моделирующих самые плохие ситуации, что позволяет увеличить надежность кода. После создания документа XML "крайнего случая" разработчик логики представления создает функционирующий код логики представления в соответствии с этим документом.
Примечание. Многие объекты в .NET автоматически фиксируют состояние объекта в XML. Эта функциональность заменяет определение объектов для использования в решении, что является большим преимуществом, поскольку в конечном итоге нужно создать объекты, реализующие XML. ASP.NET предоставляет множество способов разработки и отображения XML (см. лекции 2 и 3).
Для любой фасадной части необходимо получить следующие промежуточные результаты.
Одна или несколько спецификаций XML "крайнего случая" для каждого окна, определенного в функциональной спецификации.Код логики представления для каждого окна функциональной спецификации.
Разработчик пользовательского интерфейса выполняет большую часть работы, напрямую связанную с этим этапом, создавая требуемый пользовательский интерфейс, указанный в функциональной спецификации. На данном этапе бизнес-аналитик выполняет минимальный объем работы. Роль аналитика заключается в уточнении спецификации и ее проверке. Разработчик объектов проверяет существующее решение на наличие источников XML, несущих в себе объекты или данные, определяемые как содержимое документа XML "крайнего случая". В этот поиск можно включить классы .NET Framework, если технология .NET Framework входит в программное решение. Если разработчик пользовательского интерфейса хорошо знаком с результирующими XML, то можно начать создание основного кодf или провести анализ выполняемости компонентов нового решения.
Фасадная часть считается завершенной, если в браузере отображаются окна с помощью документов XML "крайнего случая", при этом, как правило, невозможен переход от одного окна фасада к другому, и отсутствуют ссылки. Перед непосредственной разработкой возможна настройка логики представления.
Реализация
Диаграмма реализации.Описание данных на узле (библиотеки, версии).Сценарий реализации (необходимые шаги, порядок выполнения, конфигурация узла).Подтверждение успешного проведения реализации.Шаги по деинсталляции.
В данном разделе описывается способ переноса решения в среду функционирования. Диаграмма реализации показывает файлы, обеспечивающие существование классов и функций. Решение, как правило, состоит из нескольких библиотек DLL, поэтому диаграмма определяет имеющиеся или новые библиотеки DLL, содержащие классы или функции. С помощью версии и имени необходимо определить зависимости решения. Кроме этого, следует предоставить инструкции по установке и деинсталляции наряду с описанием действий по проверке правильности произведенной установки.
Реализация решения
Последним шагом является реализация решения. Как правило, речь идет об установке системным администратором программы на веб-сервер и другие необходимые узлы. Установка по возможности проводится с помощью программного обеспечения, в автоматизированном режиме, без ручного копирования файлов.
Некоторые программные пакеты служат для построения программ установки. Это, например, шаблоны проекта программы установки Visual Studio .NET InstallShield или Wyse. Построение программы установки может показаться лишним, но оно позволяет избежать ошибок установки. Программа установки является частью решения и проходит соответствующие тесты. При установке должен проводиться тест для подтверждения правильности инсталляции решения, чтобы установщик знал о возникновении любых неполадок. В программное решение также следует включить сценарий деинсталляции.
Еще одним действием при производстве программного продукта является реклама и информирование конечных пользователей о появлении нового решения. Эти действия требуют строгого соблюдения сроков сдачи проекта, и реализация в этом случае должна происходить точно по назначенному расписанию.
Сбор функциональных требований
Для написания функциональной спецификации ее автор должен знать функциональные требования. Он должен выполнить сбор функциональных требований, консультируясь с бизнес-аналитиком, обсудившим функциональность программного решения с владельцем. Успех данного исследования зависит от места расположения владельца, который либо доступен для беседы с аналитиком, либо не может предоставить необходимую информацию. Бизнес-аналитик помогает владельцу сосредоточиться на важной и полезной для проекта информации, исключая технические детали построения проекта.
Бизнес-аналитик обдумывает информацию, предоставленную владельцем, и создает подробную функциональную спецификацию, после чего команда разработки эффективно разрабатывает программное решение. Аналитик идентифицирует все требования программного решения, начиная с документов, описывающих область работы.
Затем с помощью UML составляются диаграммы use-case бизнес-процессов. Как и многие другие задачи, диаграммы use-case создаются с максимальном количеством деталей для более точного описания бизнес-процессов. Диаграммы UML упрощают документацию use-case и облегчают ее понимание и сверку.
После сбора аналитиком всей необходимой информации use-case она документируется в виде формы или таблицы. Шаблон или форма для документирования информации use-case включает в себя следующие элементы.
Имя use-case. Короткое информативное имя.Идентификатор use-case. Уникальный буквенно-цифровой код.Действующие лица. Все конечные пользователи, принимающие участие в use case.Предварительные условия. Часть среды, присутствующая в реализации use-case.Процесс. Что происходит в процессе use-case.Последующие условия. Что представляет собой среда после выполнения use-case.
Например:
Имя: Поиск рецепта. Идентификатор: UC001. Действующие лица: Пользователь. Предварительные условия: Пользователь должен осуществить успешный вход на сайт.
Процесс:
Пользователь щелкает на ссылке "Поиск рецепта".В окне браузера открывается окно "Поиск рецепта".Пользователь вводит в диалоговом окне ключевое слово, которое присутствует в искомом рецепте.Пользователь нажимает на клавишу Enter.Окно обновляется с отображением результатов поиска.Если пользователь получает искомое имя рецепта: Пользователь щелкает на ссылке для получения рецепта.Рецепт отображается в окне браузера.Если пользователь не получает искомого имени рецепта: Пользователь вводит новый критерий поиска рецепта в диалоговом окне ввода ключевого слова.Пользователь осуществляет поиск, до тех пор пока рецепт не будет найден.
Последующие условия: пользователю в окне браузера отображается нужный рецепт.
Такой тип анализа помогает при разработке решений. Шаблон use-case соответствует шаблону функционирования самого кода программы. Секция "Процесс" последовательности use-case является алгоритмом, который является частью создаваемого программного решения.
После проверки и подтверждения владельцем задокументированных последовательностей use-case их связывают с требованиями, определенными владельцем. Если use-case-не соответствуют этим требованиям, то они либо отбрасываются, либо определяются другие требования.
По завершении работы над функциональной спецификацией следует проверить оценку и план, представленные на этапе выявления области работы. Для внесения изменений следует определить вспомогательные функциональные требования, позволяющие увеличить сроки или использовать дополнительные ресурсы. Если владелец согласится с новым расписанием, переходите к выполнению следующего этапа проекта. В противном случае измените область работы для удовлетворения требованиям по доставке готового продукта.
Сценарии функционального тестирования
Сценарии функционального тестирования базируются на содержимом функциональной спецификации, поэтому они включаются в этап построения решения в качестве промежуточных результатов. Сценарии тестирования документируют действия, которые должно выполнять решение с соответствии с требованиями функциональной спецификации.
Сценарий функционального тестирования нужно документировать таким образом, чтобы лицо, ответственное за разработку или требования к функционированию, могло выполнить этот сценарий. По аналогии с другими документами сценарий должен включать в себя следующие элементы.
Запись контроля изменений.Титульная страница с именем владельца и названием проекта.Нижний колонтитул с названием компании, сведениями о конфиденциальности документа и датой его печати.
Сценарий тестирования оформляется в виде таблицы со следующими полями.
Последовательный номер. Номер, уникально идентифицирующий шаг в сценарии.Элемент действия. Название или имя этапа; рекомендуется использовать имя, соответствующее началу действия или наличию раздела, в котором выполняется действие.Действия пользователя. Описание действий по тестированию решения.Входные данные. Описание действий для получения отклика от решения.Ожидаемые результаты. Результаты работы решения.Действительные результаты. Действительные результаты работы решения.Успех или неудача тестирования. Значение типа boolean, отражающее успешное или неудачное прохождение теста.
Шаблон технической спецификации
Следует создать общую структуру или шаблон технической спецификации для обеспечения состоятельности технической спецификации. Шаблон применяется по умолчанию, и можно отказаться от его использования, чтобы обеспечить соответствие документа требованиям, предъявляемым к описанию модели. Если документ изменяется для каждого проекта, следует скорректировать шаблон документа. Ниже приведена рекомендуемая структура технической спецификации.
Создание технической спецификации
После представления фасадной части в функциональную спецификацию вносятся изменения (если это необходимо), и, в случае одобрения владельцем, процесс моделирования считается завершенным. Документ XML "крайнего случая", созданный при моделировании фасадной части, определяет модель данных программного решения. Элементы XML внутри спецификаций XML представляют собой экземпляры объектов в формате языка XML. Заключительным действием этапа моделирования является описание способов конфигурирования имеющегося решения или создание нового решения, представляющего определенные в ходе фасадного моделирования объекты в виде XML.
Техническая спецификация должна быть достаточно подробной, чтобы команда разработки разработала необходимое программное решение согласно указанным позициям. В этом случае помогает документирование, когда разработчика излагает свои соображения на бумаге. Техническая спецификация дополняет функциональную спецификацию планом построения программного обеспечения. Техническая спецификация включает в себя следующие элементы.
Определение каждого технического требования, чтобы разработчики соответствующим образом называли компоненты спецификации.Запись контроля за изменениями.Оглавление.Титульная страница с именем владельца и названием проекта.Нижний колонтитул с именем организации, сведениями о конфиденциальности и номером версии, использованными в функциональной спецификации.
При построении технической спецификации следует руководствоваться той же стратегией нумерации, что и в функциональной спецификации (см. рис. 6.4) Лицевая страница технической спецификации во многом похожа на титульную страницу функциональной спецификации.
Стиль сайта
Описать внешний вид и стиль (шрифт, использование браузера и расположение окна) всего сайта в целом.
Данная область не является обязательной. Многие организации придерживаются определенных стилей, определяющих внешний вид сайта, а также обработку определенных условий или расположения окна. Например, следующая инструкция определяет тип расположения окна.
Запрос у конечного пользователя параметров запроса требует открытия нового окна браузера; в противном случае все содержимое отображается в том же самом окне браузера, обеспечивающем переход по сайту. Единовременно открывается не более двух окон браузера для правильного использования сайта.
Тестирование решения
После прохождения решением модульного и комплексного тестирования сотрудник отдела контроля качества должен выполнить функциональные сценарии для тестирования решения. Назначение данного теста заключается в следующем.
Проверка соответствия решения требованиям и задачам, описанным в функциональной спецификации.Поиск дефектов в алгоритмах решения.Поиск отклонений от соответствия предъявляемым требованиям.
При обнаружении отклонений или дефектов тестировщик должен остановить сценарий тестирования, зафиксировать результат ошибочного события и отправить его разработчикам. В зависимости от серьезности и приоритета ошибки разработчики разрабатывают "заплатку" или вносят коррективы в следующую реализацию решения. В таблице 6.5 приведен обзор промежуточных результатов этапа тестирования.
| 1 | Выполнение сценария тестирования | Контроль качества. |
| 2 | Описание ошибки | Тестировщик. |
| 3 | Устранение ошибки | Разработчики. |
В большинстве организаций, занимающихся разработкой, используется программное обеспечение для записи, постановки в очередь и отслеживания ошибок. Система отслеживания ошибок поддерживает следующие возможности.
Настраиваемое уведомление ответственных сторон по электронной почте.Возможность приложения скрин-шотов или другого материала.Настраиваемые уровни состояния.Настраиваемые уровни приоритета.Отчетность для накопительного анализа ошибок.Возможность сканирования ошибок в порядке сортировки, определяемом пользователем.
Как правило, при функциональном тестировании всегда возникают ошибки. Довольно часто возникают ситуации, требующие принятия решения о передаче программного продукта в среду функционирования. Владельца необходимо обеспечить отчетами о тестировании для принятия решения о выходе из сложившейся ситуации.
Унифицированный процесс
В унифицированном процессе выделяются четыре этапа и пять технологических процессов, составляющих процедуру разработки. Итерация включает следующие этапы.
Отправная точка. Определение требований, которым должно удовлетворять ПО, и задач, которые оно должно выполнять.Тщательная разработка. Создание решения, выполняющего поставленные задачи.Конструирование. Программирование, документирование и настройка программного обеспечения.Сдача работы. Выпуск программы или ее доставка заказчику.
Технологические процессы являются составными частями этапов. Каждый этап должен содержать все эти процессы.
Сбор требований. Выполнение исследований для определения требований и задач.Анализ. Изучение собранных данных для выяснения конкретных целей создания программы.Создание. Создание решения.Применение. Переход к среде, в которой будет выполняться программное решение.Тестирование. Проверка соответствия решения определенным требованиям.
Вне области
Перечислить возможности, обычно присутствующие в области функциональных задач, но удаленные из программного решения.Перечислить возможности, обычно включаемые в решения, но исключенные из данного решения.Перечислить возможности, присутствующие в данном решении.Перечислить возможности, не включенные в данный этап решения, но появляющиеся на следующем этапе.
Данную область противопоставляют области функциональных задач, так как она содержит функциональные задачи, не включенные в рассматриваемое программное решение. Она уточняет представление всех участников проекта о том, что отсутствует в данном решении. Функциональные задачи, приведенные в предыдущей области, по-разному воспринимаются различными читателями. Если читатель не полностью ознакомился со всей функциональной спецификацией, он не поймет, что означает конкретная функциональная задача.
Перечень элементов или файлов, которые
Обзор решения.Перечень создаваемых элементов (сценарии, компоненты, сценарии базы данных и т.д.). Перечень элементов или файлов, которые можно изменять в имеющемся решении.Определения и сокращения.Определения всех потенциально сложных для понимания терминов, используемых в документе или технологической среде.Определения сокращений, используемых в документе или в сфере деятельности владельца.Вне области.Перечень того, что, по мнению разработчика, следовало бы сделать, но чего делать нельзя.Допущения.
Данная область представляет собой набор основных положений, отражающих производство рассматриваемого решения. Во введении не должны дублироваться сведения из функциональной спецификации; вместо этого в нем описывается проект так, как если бы разработчик был ознакомлен с функциональной спецификацией. Опасность дублирования информации из функциональной спецификации состоит в том, что данный документ обычно обновляется и не принадлежит автору технической спецификации. Функциональную спецификацию можно обновить для подготовки к предстоящему усовершенствованию решения. Если техническая спецификация содержит во введении данные, измененные в функциональной спецификации в результате обновления, то она считается некорректной.
