Разработчику поручено создать веб-сайт или другое программное решение. Он должен определить, что именно клиент хочет от своего сайта, а также убедить его в предоставлении необходимого количества времени и суммы денег для создания веб-сайта. Это позволит команде разработки создать именно тот сайт, который нужен клиенту. Трудность заключается в том, что клиент зачастую сам не знает, чего он хочет. Нередки случаи, когда он требует выполнения работы за очень короткий промежуток времени. Команда разработки не знает, что нужно клиенту, а разработчики не всегда знают, как достичь желаемого результата, даже если конечный результат известен.
Многие менеджеры и ведущие специалисты в области разработки ПО следуют
схеме, называемой "
Из
В данной лекции используется ряд специальных терминов, определения которых приводятся ниже.
Под владельцем подразумевается получатель веб-сайта. Термин клиент обозначает пользователя сервера. Данное разграничение предотвращает путаницу, возникающую при равнозначном использовании этих терминов. Владельцем является начальник, сотрудник отдела продаж или рекламный представитель. Несмотря на то, что мотивы каждого владельца различны, все они выступают в роли заменителей конечных пользователей. Владелец всегда требует от сайта выполнения определенной задачи с наименьшими затратами ресурсов.
Термин конечный пользователь обозначает лицо, потребляющее некоторое программное обеспечение. Это может быть человек, использующий браузер для просмотра веб-сайтов или получающий файл по электронной почте с сервера SMTP. Конечный пользователь взаимодействует с программным решением.
Термины программное решение, автоматизированное решение и решение являются взаимозаменяемыми. В данной лекции все они объединены в термин "решение". Решением называется комбинация программного и аппаратного обеспечения, необходимого для выполнения определенной работы.
Менеджером проекта является лицо, осуществляющее контроль над проектом с момента выделения владельцем средств на создание решения до получения клиентом готового продукта. Менеджер проекта выполняет работу по управлению требованиями клиента и отвечает за соблюдение временных рамок проекта. Если проект является долгосрочным, менеджер проекта выступает в роли ответственного за прибыль проекта.
Бизнес-аналитик является официальным адвокатом владельца и определяет, каким образом должно функционировать решение. Данное лицо, как правило, владеет функциональной спецификацией. Эту роль могут выполнять и другие лица, например, менеджеры проекта и разработчики.
Команда разработки – группа разработчиков, ведущих специалистов, менеджеров по разработке и системных архитекторов. В разных организациях должности и роли различаются. В общем случае команда разработчиков занимается написанием кода, но не осуществляет контроль над кодом и настройку оборудования.
Системные специалисты занимаются управлением оборудованием. Они отвечают за аппаратную часть, управляя, настраивая и поддерживая аппаратное обеспечение и операционную систему. Лица данной категории производят настройку решений, но не занимаются написанием кода.
Разработчик пользовательских интерфейсов занимается реализацией логики представления для конкретного программного решения. Разработчик объектов отвечает за создание кода бизнес-логики и логики данных.
UML – аббревиатура от
Use case – описание бизнес-события или процесса, осуществляемого программой.
QA – аббревиатура от
В унифицированном процессе выделяются четыре этапа и пять технологических процессов, составляющих процедуру разработки. Итерация включает следующие этапы.
Технологические процессы являются составными частями этапов. Каждый этап должен содержать все эти процессы.
В начале работы над любым проектом определяется область, представляющая собой обзор или описание желаемого результата. Если все участники проекта согласны с определенной областью, то далее следует сбор требований, результатом которого является функциональный проект. По завершении сбора требований разрабатывается технический проект, определяющий построение программного решения; результатом является техническая спецификация. Функциональный проект отвечает на вопрос "что", а технический проект – на вопрос "как". После описания решение передается в разработку для реализации построения и тестирования согласно технической спецификации. По завершении процесса разработки программное решение тестируется согласно функциональной спецификации. После прохождения всех необходимых тестов осуществляется публикация программы или ее доставка клиенту, и проект считается завершенным. На рисунке 6.1 показан общий процесс построения веб-сайта.
(рис 6.1) Общий процесс построения веб-сайтаМногие новые методологии, например,
Каждый этап имеет промежуточный результат или набор промежуточных результатов, являющихся основанием для дальнейшей работы над проектом. Область обычно является документом, в котором приводятся требования заказчика и оценка разработки решения, отвечающего этим требованиям. В результате сбора требований создается функциональная спецификация, описывающая функционирование программного продукта и его внешний вид. Этап технического проекта заканчивается созданием технической спецификации. В результате разработки и программирования создается группа файлов, которые проходят модульное тестирование, отвечающих требованиям технической спецификации, а также программа инсталляции решения. Итогом этапа тестирования продукта является документ, свидетельствующий о том, что в результате программирования разработано программное решение, отвечающее требованиям функциональной спецификации. Наконец, на этапе реализации выставляется счет, сообщается о выходе программы пользователям и создается инструкция по эксплуатации программного продукта.
Примечание. Примеры документов, описываемых в данной лекции, доступны на веб-сайте автора книги.
Передача промежуточных результатов между этапами и командами разработки в рамках программного проекта часто является причиной разногласий. Успех проекта зависит от эффективности работы сотрудников отдела продаж, рекламы, бизнес-аналитиков и инженеров по программному обеспечению. При появлении разногласий порой бывает очень сложно добиться слаженной работы. Эффективной стратегией обеспечения согласованности действий специалистов является такая организация работы, когда при разработке промежуточных результатов руководствуются исключительно требованиями заказчика. Степень производительности в этом случае напрямую зависит от выполнения требований клиента.
В команде разработки ее сотрудники являются клиентами по отношению к друг другу. Например, если функциональной спецификации не хватает ясности в выражении конечного результата при ее прочтении инженером по программному обеспечению, бизнес-аналитик должен усовершенствовать документ, а не надеяться на самостоятельность этого инженера. Если установка программного обеспечения осуществляется неправильно, то разработчик программы установки или сценария должен ее откорректировать, чтобы системный персонал смог установить программу без проблем. Таким образом, разработчик является клиентом бизнес-аналитика, а системные инженеры – клиентами разработчика. Ответственность за эффективное использование клиентом промежуточных результатов является единицей измерения профессиональной эффективности команды. Если члены команды разработки уважают и любят разрабатываемый продукт, то эффективность их работы будет высока. Привейте команде разработки проекта дисциплину и чувство ответственности, и успех не будет зависеть от индивидуальных особенностей и уровня каждого специалиста в команде разработки.
Еще одной причиной спорных ситуаций является время, затрачиваемое на создание программного продукта. Как правило, чем дольше работа над проектом, тем больше создается функциональных возможностей и программ. Исходные требования могут со временем измениться, поэтому уменьшение сроков доставки снижает вероятность того, что требования заказчика изменятся. Это также понижает уровень стрессовых ситуаций в команде разработки.
Кто-то поспешит заметить, что требования устанавливаются владельцем, а
не командой разработки. Уменьшение времени на разработку программного
продукта приведет к успеху только при сужении области разработки или
расширении штата разработчиков. Естественно, что требования
устанавливаются владельцем, поэтому при "урезке" требуемой
функциональности владелец удовлетворен не будет. Наилучший способ
решить данную проблему – сузить область, т.е. разбить проект на более
мелкие. В данном случае владельцу можно предоставить план работы над
проектом. Согласно
Целью определения области является выделение средств на разработку. Владельцу предоставляется перспективный план программного решения и, в случае одобрения, владелец выделяет ресурсы и средства, необходимые для разработки. Перспективный план содержит:
Поскольку нет уверенности в том, что владелец согласится выделить средства на весь проект, менеджер проекта определяет, какие элементы необходимо включить в перспективный план. Работа по подготовке перспективного плана проводится в соответствии с отношениями между организацией-разработчиком и потенциальным владельцем. Например, владелец может принять предложение по перспективному плану, если ему предоставят определенную информацию. В этом случае нужно приложить максимум усилий, поскольку вероятность этого достаточна велика. В другой ситуации мнение владельца о предлагаемом проекте неизвестно, поэтому приложенные усилия и временные затраты могут не привести к положительному результату, особенно при наличии конкурентов, предлагающих свои собственные решения.
Следует иметь в виду риск наложения ответственности на организацию разработки при неясности некоторых фактов. При отсутствии возможности сверки с расписанием после проведения сбора требований действия, осуществляемые на этапе определения функциональности, должны выполняться на этапе определения области. Владельца нужно предупредить о сложностях, связанных с реализацией плана, а также дать понять, что задачи, выходящие за рамки рассматриваемого уровня сложности, приведут к увеличению стоимости проекта и временных затрат.
После того как менеджер по счетам ставит задачу проекта, команда разрабатывает калькуляцию. Затем менеджер проекта проектирует план и определяет затраты времени на проект, промежуточные результаты и ключевые моменты.
Предположим, что после представления перспективного плана владелец согласился с поставленными условиями. Начинается следующий этап процесса – определение функциональности. В таблице 6.1 приведены промежуточные результаты работы на этапе определения области с указанием стороны, ответственной за их получение.
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Описание требований владельца – постановка задачи | Менеджер по счетам. |
| 2 | Квалифицированная оценка области | Разработчики. |
| 3 | Квалифицированный план проекта относительно области | Менеджер проекта. |
| 4 | Согласие владельца относительно области и предлагаемое время завершения работы над проектом | Менеджер проекта. |
В начале работы по созданию программного продукта владелец видит перед собой некоторый идеал, о котором он сообщает организации, занимающейся работой над проектом. Владелец или менеджер определяют результат работы (постановка задачи). Постановку задачи можно сделать после 15-минутного телефонного разговора, зафиксировать на паре листов бумаги или подытожить в предложении из 15 слов. Ниже приведен пример постановки задачи на выполнение работы.
Владельцу нужен веб-сайт, на котором менеджер сможет публиковать рецепты. Сотрудники, подчиненные менеджеру, должны размещать свои комментарии относительно рецептов. Каждый может читать комментарии для рецептов, опубликованных соответствующим менеджером.
Владельцу требуется узел для приложения.
Владелец желает получить завершенный проект через три недели, к 22 июня, на которое назначена презентация пивоваренных достижений.
Эффективной стратегией по оценке области является определение всех промежуточных результатов, необходимых для создания программного решения. Промежуточные результаты уточняются в рамках допущений, связанных с их получением и сопутствующим риском. Промежуточные результаты следует определять по возможности самым широким образом в отношении требований, которым они должны удовлетворять. Сотрудники, участвующие в оценке, рассматривают тезисы разработчика как контрпродуктивные меры, используемые разработчиками для собственной защиты. Уточненные тезисы являются начальным эскизом, описывающим функционирование программного решения. Разработчики должны подробнейшим образом описать ключевые моменты для информирования команды об аспектах, влияющих на объем ресурсов, необходимых для разработки программного решения. На рисунке 6.2 в качестве основы для веб-сайта, на котором публикуются рецепты пивоварения, использована демонстрационная оценка, приведенная выше.
(рис 6.2) Пример оценки области, представленный в виде электронной таблицы
Далее необходимо разработать квалифицированный план проекта области.
План проекта области содержит обзор этапов
Предсказывать будущее сложно. Необходимо определить выполняемые задачи и тех, кто должен заниматься их выполнением. Следует определить зависимости для этих задач. Например, нельзя выехать на машине из гаража, не открыв ворота.
(рис 6.3) Диаграмма Ганта плана демонстрационного проекта, созданная на этапе определения области работыПроект области дает начальное понимание объема работ. Если предположения оценки области правильны, и план показал, что работу нельзя завершить в установленные сроки, следует адаптировать стратегию. Это потребует от владельца принятия альтернативной области работы, применения этапного подхода к разработке программного решения за счет увеличения числа итераций либо перехода команды разработки к альтернативному варианту проекта.
После разработки плана и создания всех документов, связанных с перспективным планированием, план представляется владельцу. После принятия плана владельцем проект возвращается менеджеру проекта для утверждения. При несогласии владельца с перспективным планом менеджеру по счетам необходимо предоставить другие варианты документа, определяющего область работ, а также план проекта.
Целью определения функциональности является получение от владельца подробного описания результата работы над проектом. Ниже представлены цели проведения этапа определения функциональности.
Как говорилось выше, способ существования программного решения и его функции составляют функциональное требование к программному решению. Фразу "способ существования и функционирования решения" можно интерпретировать очень вольно, поэтому следует сузить область функциональности в контексте программного решения. Задайте владельцу следующие вопросы и получите ответы, уточняющие функциональные требования, предъявляемые к программному решению для интернета.
При определении способа существования и функционирования решения большая часть информации зависит от мнения владельца. Часто владелец сам не знает точно, что именно он хочет видеть в результате проекта. На этапе сбора требований владелец должен сделать заключение о результатах. Определив суть программного решения, владелец выявляет промежуточные результаты и необходимые ресурсы.
При определении программного решения его нужно задокументировать с указанием того, что владелец ожидает от конечного результата проекта. Этот документ называется функциональной спецификацией. После создания функциональной спецификации оценка повторно проверяется и при необходимости пересматривается.
План проекта с основными этапами и датами является частью
функциональной спецификации. Владелец должен ознакомиться с
функциональной спецификацией и оценкой. Работу не следует начинать,
пока он письменно виде не подтвердит
Функциональная спецификация описывает ожидаемый результат работы над проектом с точки зрения владельца. Она является подготовительным этапом перед составлением технического проекта и обеспечивает понимание владельцем конечного результата. В этом документе указываются действия, выполняемые программным решением. Видимые промежуточные результаты нужно подробно описать, чтобы разработчик создавал программное решение без дополнительных вопросов к владельцу. Функциональная спецификация создается с технически абстрагированной точки зрения и не содержит технических инструкций по созданию решения.
| Порядок выполнения | Промежуточный результат | Ответственная сторона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) Демонстрационные сценарии и исключения функциональной спецификации
В приложении размещается самая разная информация. Если информация важна для проекта и может пригодится членам команды, работающей над проектом, то ее следует разместить в приложении.
Для написания функциональной спецификации ее автор должен знать функциональные требования. Он должен выполнить сбор функциональных требований, консультируясь с бизнес-аналитиком, обсудившим функциональность программного решения с владельцем. Успех данного исследования зависит от места расположения владельца, который либо доступен для беседы с аналитиком, либо не может предоставить необходимую информацию. Бизнес-аналитик помогает владельцу сосредоточиться на важной и полезной для проекта информации, исключая технические детали построения проекта.
Бизнес-аналитик обдумывает информацию, предоставленную владельцем, и создает подробную функциональную спецификацию, после чего команда разработки эффективно разрабатывает программное решение. Аналитик идентифицирует все требования программного решения, начиная с документов, описывающих область работы.
Затем с помощью UML составляются диаграммы use-case бизнес-процессов. Как и многие другие задачи, диаграммы use-case создаются с максимальном количеством деталей для более точного описания бизнес-процессов. Диаграммы UML упрощают документацию use-case и облегчают ее понимание и сверку.
После сбора аналитиком всей необходимой информации use-case она документируется в виде формы или таблицы. Шаблон или форма для документирования информации use-case включает в себя следующие элементы.
Например:
Имя: Поиск рецепта. Идентификатор: UC001. Действующие лица: Пользователь. Предварительные условия: Пользователь должен осуществить успешный вход на сайт.
Процесс:
Последующие условия: пользователю в окне браузера отображается нужный рецепт.
Такой тип анализа помогает при разработке решений. Шаблон use-case соответствует шаблону функционирования самого кода программы. Секция "Процесс" последовательности use-case является алгоритмом, который является частью создаваемого программного решения.
После проверки и подтверждения владельцем задокументированных последовательностей use-case их связывают с требованиями, определенными владельцем. Если use-case-не соответствуют этим требованиям, то они либо отбрасываются, либо определяются другие требования.
По завершении работы над функциональной спецификацией следует проверить оценку и план, представленные на этапе выявления области работы. Для внесения изменений следует определить вспомогательные функциональные требования, позволяющие увеличить сроки или использовать дополнительные ресурсы. Если владелец согласится с новым расписанием, переходите к выполнению следующего этапа проекта. В противном случае измените область работы для удовлетворения требованиям по доставке готового продукта.
Моделью называется инструкция по построению программного решения. Она объясняет способы размещения программного решения на узле и определяет задачи, необходимые для построения решения. Промежуточные результаты процесса построения также выявляются в модели. В идеальном случае модель содержит достаточное количество информации, чтобы программист создал программное решение.
Модель состоит из диаграмм, текста, рисунков, псевдокода и других
элементов, определяющих технические особенности. Промежуточные
результаты процесса разработки модели носят следующие названия: фасад,
сценарии
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Фасад | Бизнес-аналитик и разработчики. |
| 2 | Техническая спецификация | Разработчики. |
| 3 | Сценарии |
Контроль качества. |
Фасад в данном контексте не является объектно-ориентированным методом программирования. Этот элемент можно назвать ограниченным прототипом или креативной экспериментальной моделью с небольшой степенью реальности. Определение фасада позволяет владельцу представить себе программное решение перед получением окончательного продукта. Фасад демонстрирует программное решение в действии в окне браузера.
Моделирование решения происходит по окончании сбора требований и отражения их в функциональной спецификации. На данном этапе предполагается, что владелец точно представляет себе конечный результат, и что это нашло свое отражения в документе. Тем не менее, в реальной жизни после просмотра предварительного варианта проекта владелец может добавить в него что-нибудь.
Во многих интернет-проектах владелец сконцентрирован на том, как конечный пользователь будет взаимодействовать с программой. В процессе создания модели и построения решения фасад подтверждает внешний вид и функции программного обеспечения. Проекты веб-порталов обычно включают в себя следующие промежуточные результаты.
Почему бы не реализовать логику представления перед построением прочих элементов? Если программное решение поддерживает абстракцию от бизнес-логики и логики представления, то в первую очередь можно заняться логикой представления. Технологией, поддерживающей такую абстракцию, является язык XML. В рамках данной лекции мы будем работать с форматом XML.
Совместные усилия по программированию правил функционирования,
сценариев и источников данных приводят к созданию документов XML,
необходимых логике представления для получения конечного результата.
Перед построением источников данных или программы разработчик создает
техническую спецификацию, устанавливающую метод, согласно которому
функционируют данные элементы, включая создаваемый код XML. Это
означает, что код XML моделируется перед построением программы. Следует
проверить модель XML перед построением источника данных или программы,
применяющей правила функционирования. Необходимо написать файлы
сценариев, используемые для применения логики представления, и это
можно сделать перед созданием программы поддержки (или после). При
изменении требований корректировка файла сценария логики представления
потребует меньших усилий, чем изменение скомпилированного кода
Проверка функциональной спецификации является значимым действием, направленным на подтверждение корректности модели и технической спецификации. Часть процесса моделирования, в которой происходит описание фасада, направлена на достижение именно этой цели. Ниже приведены конкретные задачи, решаемые при работе над фасадом в процессе моделирования.
По завершении работы над фасадом можно выполнять оставшуюся часть работы по созданию кода правил функционирования и источника данных. Фасадную часть также можно продемонстрировать владельцу. Хотя она и не является полнофункциональной, но все-таки отражает процесс работы и показывает, что все идет по плану. Владелец чувствует себя непосредственным участником процесса и берет на себя некоторую ответственность за конечный результат разработки.
Созданные файлы логики представления фасадной части не должны изменяться в процессе построения решения за исключением случаев, когда требуется поддержка других версий браузера или платформ клиента.
Построение фасадной части требует взаимодействия лиц, участвующих в определении и построении решения: бизнес-аналитика, разработчика, программирующего логику представления, и разработчика бизнес-логики или логики данных. Разработчика логики представления будем называть разработчиком пользовательского интерфейса, а разработчика кода бизнес-логики и логики данных – разработчиком объектов.
Процесс работы над фасадом начинается с определения
Примечание. Многие объекты в .NET автоматически фиксируют состояние объекта в XML. Эта функциональность заменяет определение объектов для использования в решении, что является большим преимуществом, поскольку в конечном итоге нужно создать объекты, реализующие XML. ASP.NET предоставляет множество способов разработки и отображения XML (см. лекции 2 и 3).
Для любой фасадной части необходимо получить следующие промежуточные результаты.
Разработчик пользовательского интерфейса выполняет большую часть работы, напрямую связанную с этим этапом, создавая требуемый пользовательский интерфейс, указанный в функциональной спецификации. На данном этапе бизнес-аналитик выполняет минимальный объем работы. Роль аналитика заключается в уточнении спецификации и ее проверке. Разработчик объектов проверяет существующее решение на наличие источников XML, несущих в себе объекты или данные, определяемые как содержимое документа XML "крайнего случая". В этот поиск можно включить классы .NET Framework, если технология .NET Framework входит в программное решение. Если разработчик пользовательского интерфейса хорошо знаком с результирующими XML, то можно начать создание основного кодf или провести анализ выполняемости компонентов нового решения.
Фасадная часть считается завершенной, если в браузере отображаются окна с помощью документов XML "крайнего случая", при этом, как правило, невозможен переход от одного окна фасада к другому, и отсутствуют ссылки. Перед непосредственной разработкой возможна настройка логики представления.
Представление фасада разработчику требует возможности отображения окна в браузере. 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" ?>
Представление фасадной части показывает владельцу окна его будущего программного решения в браузере. Переход от одних окон к другим реализуется посредством сценариев. После первого ознакомления с фасадной частью владелец обычно вносит свои коррективы и предложения.
В результате демонстрации фасадной части, как правило, изменяется область работы. При этом работы над проектом может сильно усложниться ввиду установленных сроков сдачи проекта. Причиной изменения области работы является то, что решение в браузере выглядит иначе, чем в функциональной спецификации. Владелец должен знать, что любое изменение сдвигает срок окончания проекта. Если владелец не согласен с изменением сроков доставки, фасадная часть упростит продажу готового решения, ведь члены команды разработки отразили в ней все требования владельца. В этом случае можно сделать следующее.
Фасад представляет собой видимую часть некоторой программной структуры. Он отражает ту часть процесса моделирования, которую разработчики называют созданием прототипа. Многие думают, что при создании прототипа требуется дополнительная работа по определению способов построения того или иного компонента. Прототип позволяет владельцу увидеть то, что создает команда разработки, а разработчикам – понять требования владельца. На создание прототипа уходит большой объем работы и ресурсов. Фасадная часть отличается от прототипа тем, что предлагает альтернативные возможности.
Некоторые владельцы непосредственно вмешиваются в процесс разработки, чтобы наставить разработчиков "на путь истинный". Стратегия разработки фасадной части предусматривает участие владельца в проекте и позволяет извлечь из этого определенную выгоду.
Владельцы иногда сомневаются в том, что разработчики уложатся во временные рамки или выделенные средства, и для этого есть основания. Проекты программного обеспечения часто не выполняются в срок, превышают установленный бюджет, и многие проблемы "всплывают" перед окончанием работ. Поэтому необходимо уведомить владельца о возможности выхода за временные рамки и сообщить о возникающих проблемах. Иногда проблема возникает из-за неадекватного определения требований или их изменения при работе над программным решением. Главный разработчик может ошибочно заключить, что владелец уведомлен о последствиях этих изменений, а владелец обвинит разработчиков в том, что продукт сделан некорректно.
Участие владельца или лица, принимающего решение относительно проекта, во всех этапах работы решает эту проблему. Естественно, они не должны участвовать в процессе технического моделирования. Им, как правило, интересна реализация элементов. Фасадная часть позволяет владельцу участвовать в процессе и оказывать некоторое влияние на процесс разработки.
Презентация фасадной части, как правило, оказывает позитивное влияние на ход выполнения проекта. Разработчики показывают свои навыки, предлагая альтернативные решения по реализации той или иной функциональности. Они получают одобрение своей работы от тех, кто не участвует процессе разработки, и гордятся тем, что им доверили представлять фасадную часть владельцу.
Примечание. Разработчику необходимо соблюдать осторожность при внесении предложений, касающихся общих архитектурных решений сайта. В порыве энтузиазма амбициозный разработчик может взять на себя обязательство разработки решения, работающего в частных случаях, но налагающего большие ограничения.
После представления фасадной части в функциональную спецификацию вносятся изменения (если это необходимо), и, в случае одобрения владельцем, процесс моделирования считается завершенным. Документ XML "крайнего случая", созданный при моделировании фасадной части, определяет модель данных программного решения. Элементы XML внутри спецификаций XML представляют собой экземпляры объектов в формате языка XML. Заключительным действием этапа моделирования является описание способов конфигурирования имеющегося решения или создание нового решения, представляющего определенные в ходе фасадного моделирования объекты в виде XML.
Техническая спецификация должна быть достаточно подробной, чтобы команда разработки разработала необходимое программное решение согласно указанным позициям. В этом случае помогает документирование, когда разработчика излагает свои соображения на бумаге. Техническая спецификация дополняет функциональную спецификацию планом построения программного обеспечения. Техническая спецификация включает в себя следующие элементы.
При построении технической спецификации следует руководствоваться той же стратегией нумерации, что и в функциональной спецификации (см. рис. 6.4) Лицевая страница технической спецификации во многом похожа на титульную страницу функциональной спецификации.
Следует создать общую структуру или шаблон технической спецификации для обеспечения состоятельности технической спецификации. Шаблон применяется по умолчанию, и можно отказаться от его использования, чтобы обеспечить соответствие документа требованиям, предъявляемым к описанию модели. Если документ изменяется для каждого проекта, следует скорректировать шаблон документа. Ниже приведена рекомендуемая структура технической спецификации.
Данная область представляет собой набор основных положений, отражающих производство рассматриваемого решения. Во введении не должны дублироваться сведения из функциональной спецификации; вместо этого в нем описывается проект так, как если бы разработчик был ознакомлен с функциональной спецификацией. Опасность дублирования информации из функциональной спецификации состоит в том, что данный документ обычно обновляется и не принадлежит автору технической спецификации. Функциональную спецификацию можно обновить для подготовки к предстоящему усовершенствованию решения. Если техническая спецификация содержит во введении данные, измененные в функциональной спецификации в результате обновления, то она считается некорректной.
В данном разделе представляются сущности, выявленные в процессе работы над фасадной частью проекта. Здесь приводится сводная диаграмма, отражающая связь этих объектов в реальном мире. Данный раздел предназначен для документирования аналитических заключений, появившихся в результате разработки фасада, а также для обеспечения вспомогательного базиса для создаваемой модели классов.
Данный раздел содержит код, обеспечивающий поддержку экземпляров объектов, описанных в объектной модели. Эти два раздела кажутся аналогичными, однако различие заключается в том, что определенные классы могут представлять несколько экземпляров объектов. Модель класса обеспечивает абстракцию от объектов реального мира к структурам кода, представляющим эти объекты.
В данном разделе представляется описание слоя данных или способа
хранения данных в системе. Классовая диаграмма является хранилищем
данных внутри памяти, а диаграмма данных – аппаратной системой хранения
информации. В этом разделе приводится описание модели базы данных, а
также файлов и
В данном разделе приводится описание возможностей программного решения,
если оно создано правильно. Здесь можно привести тест или набор тестов,
которые нужно создать для проверки программного решения и заключения о
правильности функционирования решения в процессе тестирования. В данном
разделе необходимо описать данные, обеспечивающие условия
"крайнего случая" для модульного тестирования.
"Крайний случай" обычно представляет собой обработку строк,
содержащих специальные символы, таких как ~ ` ! @ # $ % ^ * ( ) _
+ - { } [ ] \ | ; : ' " < > ? / .,.
Данные "крайнего случая" позволяют определить время выполнения при обработке большего объема данных по сравнению с обычным, с которым чаще всего взаимодействует решение.
В данном разделе описывается способ переноса решения в среду функционирования. Диаграмма реализации показывает файлы, обеспечивающие существование классов и функций. Решение, как правило, состоит из нескольких библиотек DLL, поэтому диаграмма определяет имеющиеся или новые библиотеки DLL, содержащие классы или функции. С помощью версии и имени необходимо определить зависимости решения. Кроме этого, следует предоставить инструкции по установке и деинсталляции наряду с описанием действий по проверке правильности произведенной установки.
Сценарии
Сценарий
Сценарий тестирования оформляется в виде таблицы со следующими полями.
Построение решения заключается в написании разработчиком кода или сценариев конфигурации программного обеспечения в соответствии с требованиями технической и функциональной спецификациях. В качестве вспомогательных действий разработчик осуществляет модульное тестирование и контроль кода. При необходимости создается документация для конечного пользователя. В таблице 6.4 приведены промежуточные результаты этапа построения решения.
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Код | Разработчики. |
| 2 | Документация | Разработчики. |
При написании кода разработчик руководствуется технической и функциональной спецификацией. Если в процессе программирования возникают трудности, связанные с техническим или функциональным проектом, о них нужно сообщить ответственному за соответствующий документ – разработчику (для технической спецификации) или бизнес-аналитику (для функциональной спецификации). При возникновении проблем разработчик должен описать причину для внесения корректив в структуру решения. Разработчик предлагает рекомендации по решению возникающих проблем, что поддерживает ответственность за программное решение всех участников проекта. Обязанности разработчика при написании кода заключаются в следующем.
Разработчик создает код на своем рабочем компьютере, здесь же он выполняет модульное тестирование. Целью модульного тестирования является подтверждение правильности работы функций и классов. При возникновении ошибки модульное тестирование позволяет отыскать дефекты в логических алгоритмах или же недостатки спецификации.
При успешном завершении модульного тестирования решение нужно перенести в другую среду для проведения комплексного тестирования. Этот тип тестирования проверяет его совместную работу с другими программами, с которыми ему предстоит взаимодействовать.
При возникновении ошибки модульное тестирование позволит определить место нахождения дефектов в логических алгоритмах или недостатки спецификации.
Если решение прошло тестирование обоих видов, его нужно перенести в
отдельную среду для проведения
При переносе решения с одной среды тестирования на другую необходимо внимательно управлять этими средами. В среде разработки для интернета существуют следующие среды.
Рабочая станция разработчика обеспечивает самую
Среду контроля качества нужно отделить от среды разработки, чтобы решения тестировались одновременно с работой программистов над другими частями программы. Данная среда предназначена для функционального тестирования сотрудниками отдела контроля качества. Среда контроля качества должна быть максимально приближена к той среде, в которой будет функционировать готовое программное решение. Доступ разработчиков в данную среду нужно запретить, чтобы решения устанавливались только старшими разработчиками или сотрудниками отдела контроля качества. Опасность предоставления доступа большому числу людей заключается в повреждении сценариев тестирования. Эту среду отделяют от интернета, так как она не поддерживает работу с глобальной сетью, в которой будет функционировать решение. Производительность не играет особой роли, поэтому не следует выделять дополнительные ресурсы. В данной среде обеспечиваются те же физические ограничения, что и в среде функционирования решения. Например, если решение работает в распределенной среде или среде с балансировкой нагрузки, то физические ограничения нужно продублировать, чтобы максимально приблизиться к той среде, в которой могут возникнуть ошибки.
Среда подготовки обеспечивает тестирование решения для одобрения его владельцем после прохождения функционального теста. Здесь владелец является главным лицом, принимающим работу. Среда подготовки используется в следующих целях.
Среду подготовки нужно полностью закрыть для доступа разработчиками. Ее изменения должны контролироваться системным администратором.
Среда функционирования – это узел, на котором располагается доступный клиенту продукт. Главным потребителем в среде функционирования является конечный пользователь. В данной среде важен уровень производительности. Управление средой функционирования осуществляется только системным персоналом.
После прохождения решением модульного и комплексного тестирования сотрудник отдела контроля качества должен выполнить функциональные сценарии для тестирования решения. Назначение данного теста заключается в следующем.
При обнаружении отклонений или дефектов тестировщик должен остановить сценарий тестирования, зафиксировать результат ошибочного события и отправить его разработчикам. В зависимости от серьезности и приоритета ошибки разработчики разрабатывают "заплатку" или вносят коррективы в следующую реализацию решения. В таблице 6.5 приведен обзор промежуточных результатов этапа тестирования.
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Выполнение сценария тестирования | Контроль качества. |
| 2 | Описание ошибки | Тестировщик. |
| 3 | Устранение ошибки | Разработчики. |
В большинстве организаций, занимающихся разработкой, используется программное обеспечение для записи, постановки в очередь и отслеживания ошибок. Система отслеживания ошибок поддерживает следующие возможности.
Как правило, при
Последним шагом является реализация решения. Как правило, речь идет об установке системным администратором программы на веб-сервер и другие необходимые узлы. Установка по возможности проводится с помощью программного обеспечения, в автоматизированном режиме, без ручного копирования файлов.
Некоторые программные пакеты служат для построения программ установки. Это, например, шаблоны проекта программы установки Visual Studio .NET InstallShield или Wyse. Построение программы установки может показаться лишним, но оно позволяет избежать ошибок установки. Программа установки является частью решения и проходит соответствующие тесты. При установке должен проводиться тест для подтверждения правильности инсталляции решения, чтобы установщик знал о возникновении любых неполадок. В программное решение также следует включить сценарий деинсталляции.
Еще одним действием при производстве программного продукта является реклама и информирование конечных пользователей о появлении нового решения. Эти действия требуют строгого соблюдения сроков сдачи проекта, и реализация в этом случае должна происходить точно по назначенному расписанию.
После завершения проекта следует провести анализ для определения того, насколько методология процесса приемлема для организации. Процесс, представленный в данной лекции, появился в результате такого анализа. Был добавлен этап работы над фасадной частью, так как сотрудники отдела рекламы и продаж не понимали функциональную спецификацию и должны были увидеть решение на экране монитора. Циклы разработки обычно длились около шести месяцев, однако организация нуждалась в более частом усовершенствовании своего сайта. В результате разработчики сократили цикл до трех месяцев и выяснили, что усовершенствования можно проводить с большей степенью надежности из-за снижения объема выполняемых работ.
Анализ должен ответить на следующие вопросы.
Разработчику поручено создать веб-сайт или другое программное решение. Он должен определить, что именно клиент хочет от своего сайта, а также убедить его в предоставлении необходимого количества времени и суммы денег для создания веб-сайта. Это позволит команде разработки создать именно тот сайт, который нужен клиенту. Трудность заключается в том, что клиент зачастую сам не знает, чего он хочет. Нередки случаи, когда он требует выполнения работы за очень короткий промежуток времени. Команда разработки не знает, что нужно клиенту, а разработчики не всегда знают, как достичь желаемого результата, даже если конечный результат известен.
Многие менеджеры и ведущие специалисты в области разработки ПО следуют
схеме, называемой "
Из
В данной лекции используется ряд специальных терминов, определения которых приводятся ниже.
Под владельцем подразумевается получатель веб-сайта. Термин клиент обозначает пользователя сервера. Данное разграничение предотвращает путаницу, возникающую при равнозначном использовании этих терминов. Владельцем является начальник, сотрудник отдела продаж или рекламный представитель. Несмотря на то, что мотивы каждого владельца различны, все они выступают в роли заменителей конечных пользователей. Владелец всегда требует от сайта выполнения определенной задачи с наименьшими затратами ресурсов.
Термин конечный пользователь обозначает лицо, потребляющее некоторое программное обеспечение. Это может быть человек, использующий браузер для просмотра веб-сайтов или получающий файл по электронной почте с сервера SMTP. Конечный пользователь взаимодействует с программным решением.
Термины программное решение, автоматизированное решение и решение являются взаимозаменяемыми. В данной лекции все они объединены в термин "решение". Решением называется комбинация программного и аппаратного обеспечения, необходимого для выполнения определенной работы.
Менеджером проекта является лицо, осуществляющее контроль над проектом с момента выделения владельцем средств на создание решения до получения клиентом готового продукта. Менеджер проекта выполняет работу по управлению требованиями клиента и отвечает за соблюдение временных рамок проекта. Если проект является долгосрочным, менеджер проекта выступает в роли ответственного за прибыль проекта.
Бизнес-аналитик является официальным адвокатом владельца и определяет, каким образом должно функционировать решение. Данное лицо, как правило, владеет функциональной спецификацией. Эту роль могут выполнять и другие лица, например, менеджеры проекта и разработчики.
Команда разработки – группа разработчиков, ведущих специалистов, менеджеров по разработке и системных архитекторов. В разных организациях должности и роли различаются. В общем случае команда разработчиков занимается написанием кода, но не осуществляет контроль над кодом и настройку оборудования.
Системные специалисты занимаются управлением оборудованием. Они отвечают за аппаратную часть, управляя, настраивая и поддерживая аппаратное обеспечение и операционную систему. Лица данной категории производят настройку решений, но не занимаются написанием кода.
Разработчик пользовательских интерфейсов занимается реализацией логики представления для конкретного программного решения. Разработчик объектов отвечает за создание кода бизнес-логики и логики данных.
UML – аббревиатура от
Use case – описание бизнес-события или процесса, осуществляемого программой.
QA – аббревиатура от
В унифицированном процессе выделяются четыре этапа и пять технологических процессов, составляющих процедуру разработки. Итерация включает следующие этапы.
Технологические процессы являются составными частями этапов. Каждый этап должен содержать все эти процессы.
В начале работы над любым проектом определяется область, представляющая собой обзор или описание желаемого результата. Если все участники проекта согласны с определенной областью, то далее следует сбор требований, результатом которого является функциональный проект. По завершении сбора требований разрабатывается технический проект, определяющий построение программного решения; результатом является техническая спецификация. Функциональный проект отвечает на вопрос "что", а технический проект – на вопрос "как". После описания решение передается в разработку для реализации построения и тестирования согласно технической спецификации. По завершении процесса разработки программное решение тестируется согласно функциональной спецификации. После прохождения всех необходимых тестов осуществляется публикация программы или ее доставка клиенту, и проект считается завершенным. На рисунке 6.1 показан общий процесс построения веб-сайта.
(рис 6.1) Общий процесс построения веб-сайтаМногие новые методологии, например,
Каждый этап имеет промежуточный результат или набор промежуточных результатов, являющихся основанием для дальнейшей работы над проектом. Область обычно является документом, в котором приводятся требования заказчика и оценка разработки решения, отвечающего этим требованиям. В результате сбора требований создается функциональная спецификация, описывающая функционирование программного продукта и его внешний вид. Этап технического проекта заканчивается созданием технической спецификации. В результате разработки и программирования создается группа файлов, которые проходят модульное тестирование, отвечающих требованиям технической спецификации, а также программа инсталляции решения. Итогом этапа тестирования продукта является документ, свидетельствующий о том, что в результате программирования разработано программное решение, отвечающее требованиям функциональной спецификации. Наконец, на этапе реализации выставляется счет, сообщается о выходе программы пользователям и создается инструкция по эксплуатации программного продукта.
Примечание. Примеры документов, описываемых в данной лекции, доступны на веб-сайте автора книги.
Передача промежуточных результатов между этапами и командами разработки в рамках программного проекта часто является причиной разногласий. Успех проекта зависит от эффективности работы сотрудников отдела продаж, рекламы, бизнес-аналитиков и инженеров по программному обеспечению. При появлении разногласий порой бывает очень сложно добиться слаженной работы. Эффективной стратегией обеспечения согласованности действий специалистов является такая организация работы, когда при разработке промежуточных результатов руководствуются исключительно требованиями заказчика. Степень производительности в этом случае напрямую зависит от выполнения требований клиента.
В команде разработки ее сотрудники являются клиентами по отношению к друг другу. Например, если функциональной спецификации не хватает ясности в выражении конечного результата при ее прочтении инженером по программному обеспечению, бизнес-аналитик должен усовершенствовать документ, а не надеяться на самостоятельность этого инженера. Если установка программного обеспечения осуществляется неправильно, то разработчик программы установки или сценария должен ее откорректировать, чтобы системный персонал смог установить программу без проблем. Таким образом, разработчик является клиентом бизнес-аналитика, а системные инженеры – клиентами разработчика. Ответственность за эффективное использование клиентом промежуточных результатов является единицей измерения профессиональной эффективности команды. Если члены команды разработки уважают и любят разрабатываемый продукт, то эффективность их работы будет высока. Привейте команде разработки проекта дисциплину и чувство ответственности, и успех не будет зависеть от индивидуальных особенностей и уровня каждого специалиста в команде разработки.
Еще одной причиной спорных ситуаций является время, затрачиваемое на создание программного продукта. Как правило, чем дольше работа над проектом, тем больше создается функциональных возможностей и программ. Исходные требования могут со временем измениться, поэтому уменьшение сроков доставки снижает вероятность того, что требования заказчика изменятся. Это также понижает уровень стрессовых ситуаций в команде разработки.
Кто-то поспешит заметить, что требования устанавливаются владельцем, а
не командой разработки. Уменьшение времени на разработку программного
продукта приведет к успеху только при сужении области разработки или
расширении штата разработчиков. Естественно, что требования
устанавливаются владельцем, поэтому при "урезке" требуемой
функциональности владелец удовлетворен не будет. Наилучший способ
решить данную проблему – сузить область, т.е. разбить проект на более
мелкие. В данном случае владельцу можно предоставить план работы над
проектом. Согласно
Целью определения области является выделение средств на разработку. Владельцу предоставляется перспективный план программного решения и, в случае одобрения, владелец выделяет ресурсы и средства, необходимые для разработки. Перспективный план содержит:
Поскольку нет уверенности в том, что владелец согласится выделить средства на весь проект, менеджер проекта определяет, какие элементы необходимо включить в перспективный план. Работа по подготовке перспективного плана проводится в соответствии с отношениями между организацией-разработчиком и потенциальным владельцем. Например, владелец может принять предложение по перспективному плану, если ему предоставят определенную информацию. В этом случае нужно приложить максимум усилий, поскольку вероятность этого достаточна велика. В другой ситуации мнение владельца о предлагаемом проекте неизвестно, поэтому приложенные усилия и временные затраты могут не привести к положительному результату, особенно при наличии конкурентов, предлагающих свои собственные решения.
Следует иметь в виду риск наложения ответственности на организацию разработки при неясности некоторых фактов. При отсутствии возможности сверки с расписанием после проведения сбора требований действия, осуществляемые на этапе определения функциональности, должны выполняться на этапе определения области. Владельца нужно предупредить о сложностях, связанных с реализацией плана, а также дать понять, что задачи, выходящие за рамки рассматриваемого уровня сложности, приведут к увеличению стоимости проекта и временных затрат.
После того как менеджер по счетам ставит задачу проекта, команда разрабатывает калькуляцию. Затем менеджер проекта проектирует план и определяет затраты времени на проект, промежуточные результаты и ключевые моменты.
Предположим, что после представления перспективного плана владелец согласился с поставленными условиями. Начинается следующий этап процесса – определение функциональности. В таблице 6.1 приведены промежуточные результаты работы на этапе определения области с указанием стороны, ответственной за их получение.
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Описание требований владельца – постановка задачи | Менеджер по счетам. |
| 2 | Квалифицированная оценка области | Разработчики. |
| 3 | Квалифицированный план проекта относительно области | Менеджер проекта. |
| 4 | Согласие владельца относительно области и предлагаемое время завершения работы над проектом | Менеджер проекта. |
В начале работы по созданию программного продукта владелец видит перед собой некоторый идеал, о котором он сообщает организации, занимающейся работой над проектом. Владелец или менеджер определяют результат работы (постановка задачи). Постановку задачи можно сделать после 15-минутного телефонного разговора, зафиксировать на паре листов бумаги или подытожить в предложении из 15 слов. Ниже приведен пример постановки задачи на выполнение работы.
Владельцу нужен веб-сайт, на котором менеджер сможет публиковать рецепты. Сотрудники, подчиненные менеджеру, должны размещать свои комментарии относительно рецептов. Каждый может читать комментарии для рецептов, опубликованных соответствующим менеджером.
Владельцу требуется узел для приложения.
Владелец желает получить завершенный проект через три недели, к 22 июня, на которое назначена презентация пивоваренных достижений.
Эффективной стратегией по оценке области является определение всех промежуточных результатов, необходимых для создания программного решения. Промежуточные результаты уточняются в рамках допущений, связанных с их получением и сопутствующим риском. Промежуточные результаты следует определять по возможности самым широким образом в отношении требований, которым они должны удовлетворять. Сотрудники, участвующие в оценке, рассматривают тезисы разработчика как контрпродуктивные меры, используемые разработчиками для собственной защиты. Уточненные тезисы являются начальным эскизом, описывающим функционирование программного решения. Разработчики должны подробнейшим образом описать ключевые моменты для информирования команды об аспектах, влияющих на объем ресурсов, необходимых для разработки программного решения. На рисунке 6.2 в качестве основы для веб-сайта, на котором публикуются рецепты пивоварения, использована демонстрационная оценка, приведенная выше.
(рис 6.2) Пример оценки области, представленный в виде электронной таблицы
Далее необходимо разработать квалифицированный план проекта области.
План проекта области содержит обзор этапов
Предсказывать будущее сложно. Необходимо определить выполняемые задачи и тех, кто должен заниматься их выполнением. Следует определить зависимости для этих задач. Например, нельзя выехать на машине из гаража, не открыв ворота.
(рис 6.3) Диаграмма Ганта плана демонстрационного проекта, созданная на этапе определения области работыПроект области дает начальное понимание объема работ. Если предположения оценки области правильны, и план показал, что работу нельзя завершить в установленные сроки, следует адаптировать стратегию. Это потребует от владельца принятия альтернативной области работы, применения этапного подхода к разработке программного решения за счет увеличения числа итераций либо перехода команды разработки к альтернативному варианту проекта.
После разработки плана и создания всех документов, связанных с перспективным планированием, план представляется владельцу. После принятия плана владельцем проект возвращается менеджеру проекта для утверждения. При несогласии владельца с перспективным планом менеджеру по счетам необходимо предоставить другие варианты документа, определяющего область работ, а также план проекта.
Целью определения функциональности является получение от владельца подробного описания результата работы над проектом. Ниже представлены цели проведения этапа определения функциональности.
Как говорилось выше, способ существования программного решения и его функции составляют функциональное требование к программному решению. Фразу "способ существования и функционирования решения" можно интерпретировать очень вольно, поэтому следует сузить область функциональности в контексте программного решения. Задайте владельцу следующие вопросы и получите ответы, уточняющие функциональные требования, предъявляемые к программному решению для интернета.
При определении способа существования и функционирования решения большая часть информации зависит от мнения владельца. Часто владелец сам не знает точно, что именно он хочет видеть в результате проекта. На этапе сбора требований владелец должен сделать заключение о результатах. Определив суть программного решения, владелец выявляет промежуточные результаты и необходимые ресурсы.
При определении программного решения его нужно задокументировать с указанием того, что владелец ожидает от конечного результата проекта. Этот документ называется функциональной спецификацией. После создания функциональной спецификации оценка повторно проверяется и при необходимости пересматривается.
План проекта с основными этапами и датами является частью
функциональной спецификации. Владелец должен ознакомиться с
функциональной спецификацией и оценкой. Работу не следует начинать,
пока он письменно виде не подтвердит
Функциональная спецификация описывает ожидаемый результат работы над проектом с точки зрения владельца. Она является подготовительным этапом перед составлением технического проекта и обеспечивает понимание владельцем конечного результата. В этом документе указываются действия, выполняемые программным решением. Видимые промежуточные результаты нужно подробно описать, чтобы разработчик создавал программное решение без дополнительных вопросов к владельцу. Функциональная спецификация создается с технически абстрагированной точки зрения и не содержит технических инструкций по созданию решения.
| Порядок выполнения | Промежуточный результат | Ответственная сторона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) Демонстрационные сценарии и исключения функциональной спецификации
В приложении размещается самая разная информация. Если информация важна для проекта и может пригодится членам команды, работающей над проектом, то ее следует разместить в приложении.
Для написания функциональной спецификации ее автор должен знать функциональные требования. Он должен выполнить сбор функциональных требований, консультируясь с бизнес-аналитиком, обсудившим функциональность программного решения с владельцем. Успех данного исследования зависит от места расположения владельца, который либо доступен для беседы с аналитиком, либо не может предоставить необходимую информацию. Бизнес-аналитик помогает владельцу сосредоточиться на важной и полезной для проекта информации, исключая технические детали построения проекта.
Бизнес-аналитик обдумывает информацию, предоставленную владельцем, и создает подробную функциональную спецификацию, после чего команда разработки эффективно разрабатывает программное решение. Аналитик идентифицирует все требования программного решения, начиная с документов, описывающих область работы.
Затем с помощью UML составляются диаграммы use-case бизнес-процессов. Как и многие другие задачи, диаграммы use-case создаются с максимальном количеством деталей для более точного описания бизнес-процессов. Диаграммы UML упрощают документацию use-case и облегчают ее понимание и сверку.
После сбора аналитиком всей необходимой информации use-case она документируется в виде формы или таблицы. Шаблон или форма для документирования информации use-case включает в себя следующие элементы.
Например:
Имя: Поиск рецепта. Идентификатор: UC001. Действующие лица: Пользователь. Предварительные условия: Пользователь должен осуществить успешный вход на сайт.
Процесс:
Последующие условия: пользователю в окне браузера отображается нужный рецепт.
Такой тип анализа помогает при разработке решений. Шаблон use-case соответствует шаблону функционирования самого кода программы. Секция "Процесс" последовательности use-case является алгоритмом, который является частью создаваемого программного решения.
После проверки и подтверждения владельцем задокументированных последовательностей use-case их связывают с требованиями, определенными владельцем. Если use-case-не соответствуют этим требованиям, то они либо отбрасываются, либо определяются другие требования.
По завершении работы над функциональной спецификацией следует проверить оценку и план, представленные на этапе выявления области работы. Для внесения изменений следует определить вспомогательные функциональные требования, позволяющие увеличить сроки или использовать дополнительные ресурсы. Если владелец согласится с новым расписанием, переходите к выполнению следующего этапа проекта. В противном случае измените область работы для удовлетворения требованиям по доставке готового продукта.
Моделью называется инструкция по построению программного решения. Она объясняет способы размещения программного решения на узле и определяет задачи, необходимые для построения решения. Промежуточные результаты процесса построения также выявляются в модели. В идеальном случае модель содержит достаточное количество информации, чтобы программист создал программное решение.
Модель состоит из диаграмм, текста, рисунков, псевдокода и других
элементов, определяющих технические особенности. Промежуточные
результаты процесса разработки модели носят следующие названия: фасад,
сценарии
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Фасад | Бизнес-аналитик и разработчики. |
| 2 | Техническая спецификация | Разработчики. |
| 3 | Сценарии |
Контроль качества. |
Фасад в данном контексте не является объектно-ориентированным методом программирования. Этот элемент можно назвать ограниченным прототипом или креативной экспериментальной моделью с небольшой степенью реальности. Определение фасада позволяет владельцу представить себе программное решение перед получением окончательного продукта. Фасад демонстрирует программное решение в действии в окне браузера.
Моделирование решения происходит по окончании сбора требований и отражения их в функциональной спецификации. На данном этапе предполагается, что владелец точно представляет себе конечный результат, и что это нашло свое отражения в документе. Тем не менее, в реальной жизни после просмотра предварительного варианта проекта владелец может добавить в него что-нибудь.
Во многих интернет-проектах владелец сконцентрирован на том, как конечный пользователь будет взаимодействовать с программой. В процессе создания модели и построения решения фасад подтверждает внешний вид и функции программного обеспечения. Проекты веб-порталов обычно включают в себя следующие промежуточные результаты.
Почему бы не реализовать логику представления перед построением прочих элементов? Если программное решение поддерживает абстракцию от бизнес-логики и логики представления, то в первую очередь можно заняться логикой представления. Технологией, поддерживающей такую абстракцию, является язык XML. В рамках данной лекции мы будем работать с форматом XML.
Совместные усилия по программированию правил функционирования,
сценариев и источников данных приводят к созданию документов XML,
необходимых логике представления для получения конечного результата.
Перед построением источников данных или программы разработчик создает
техническую спецификацию, устанавливающую метод, согласно которому
функционируют данные элементы, включая создаваемый код XML. Это
означает, что код XML моделируется перед построением программы. Следует
проверить модель XML перед построением источника данных или программы,
применяющей правила функционирования. Необходимо написать файлы
сценариев, используемые для применения логики представления, и это
можно сделать перед созданием программы поддержки (или после). При
изменении требований корректировка файла сценария логики представления
потребует меньших усилий, чем изменение скомпилированного кода
Проверка функциональной спецификации является значимым действием, направленным на подтверждение корректности модели и технической спецификации. Часть процесса моделирования, в которой происходит описание фасада, направлена на достижение именно этой цели. Ниже приведены конкретные задачи, решаемые при работе над фасадом в процессе моделирования.
По завершении работы над фасадом можно выполнять оставшуюся часть работы по созданию кода правил функционирования и источника данных. Фасадную часть также можно продемонстрировать владельцу. Хотя она и не является полнофункциональной, но все-таки отражает процесс работы и показывает, что все идет по плану. Владелец чувствует себя непосредственным участником процесса и берет на себя некоторую ответственность за конечный результат разработки.
Созданные файлы логики представления фасадной части не должны изменяться в процессе построения решения за исключением случаев, когда требуется поддержка других версий браузера или платформ клиента.
Построение фасадной части требует взаимодействия лиц, участвующих в определении и построении решения: бизнес-аналитика, разработчика, программирующего логику представления, и разработчика бизнес-логики или логики данных. Разработчика логики представления будем называть разработчиком пользовательского интерфейса, а разработчика кода бизнес-логики и логики данных – разработчиком объектов.
Процесс работы над фасадом начинается с определения
Примечание. Многие объекты в .NET автоматически фиксируют состояние объекта в XML. Эта функциональность заменяет определение объектов для использования в решении, что является большим преимуществом, поскольку в конечном итоге нужно создать объекты, реализующие XML. ASP.NET предоставляет множество способов разработки и отображения XML (см. лекции 2 и 3).
Для любой фасадной части необходимо получить следующие промежуточные результаты.
Разработчик пользовательского интерфейса выполняет большую часть работы, напрямую связанную с этим этапом, создавая требуемый пользовательский интерфейс, указанный в функциональной спецификации. На данном этапе бизнес-аналитик выполняет минимальный объем работы. Роль аналитика заключается в уточнении спецификации и ее проверке. Разработчик объектов проверяет существующее решение на наличие источников XML, несущих в себе объекты или данные, определяемые как содержимое документа XML "крайнего случая". В этот поиск можно включить классы .NET Framework, если технология .NET Framework входит в программное решение. Если разработчик пользовательского интерфейса хорошо знаком с результирующими XML, то можно начать создание основного кодf или провести анализ выполняемости компонентов нового решения.
Фасадная часть считается завершенной, если в браузере отображаются окна с помощью документов XML "крайнего случая", при этом, как правило, невозможен переход от одного окна фасада к другому, и отсутствуют ссылки. Перед непосредственной разработкой возможна настройка логики представления.
Представление фасада разработчику требует возможности отображения окна в браузере. 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" ?>
Представление фасадной части показывает владельцу окна его будущего программного решения в браузере. Переход от одних окон к другим реализуется посредством сценариев. После первого ознакомления с фасадной частью владелец обычно вносит свои коррективы и предложения.
В результате демонстрации фасадной части, как правило, изменяется область работы. При этом работы над проектом может сильно усложниться ввиду установленных сроков сдачи проекта. Причиной изменения области работы является то, что решение в браузере выглядит иначе, чем в функциональной спецификации. Владелец должен знать, что любое изменение сдвигает срок окончания проекта. Если владелец не согласен с изменением сроков доставки, фасадная часть упростит продажу готового решения, ведь члены команды разработки отразили в ней все требования владельца. В этом случае можно сделать следующее.
Фасад представляет собой видимую часть некоторой программной структуры. Он отражает ту часть процесса моделирования, которую разработчики называют созданием прототипа. Многие думают, что при создании прототипа требуется дополнительная работа по определению способов построения того или иного компонента. Прототип позволяет владельцу увидеть то, что создает команда разработки, а разработчикам – понять требования владельца. На создание прототипа уходит большой объем работы и ресурсов. Фасадная часть отличается от прототипа тем, что предлагает альтернативные возможности.
Некоторые владельцы непосредственно вмешиваются в процесс разработки, чтобы наставить разработчиков "на путь истинный". Стратегия разработки фасадной части предусматривает участие владельца в проекте и позволяет извлечь из этого определенную выгоду.
Владельцы иногда сомневаются в том, что разработчики уложатся во временные рамки или выделенные средства, и для этого есть основания. Проекты программного обеспечения часто не выполняются в срок, превышают установленный бюджет, и многие проблемы "всплывают" перед окончанием работ. Поэтому необходимо уведомить владельца о возможности выхода за временные рамки и сообщить о возникающих проблемах. Иногда проблема возникает из-за неадекватного определения требований или их изменения при работе над программным решением. Главный разработчик может ошибочно заключить, что владелец уведомлен о последствиях этих изменений, а владелец обвинит разработчиков в том, что продукт сделан некорректно.
Участие владельца или лица, принимающего решение относительно проекта, во всех этапах работы решает эту проблему. Естественно, они не должны участвовать в процессе технического моделирования. Им, как правило, интересна реализация элементов. Фасадная часть позволяет владельцу участвовать в процессе и оказывать некоторое влияние на процесс разработки.
Презентация фасадной части, как правило, оказывает позитивное влияние на ход выполнения проекта. Разработчики показывают свои навыки, предлагая альтернативные решения по реализации той или иной функциональности. Они получают одобрение своей работы от тех, кто не участвует процессе разработки, и гордятся тем, что им доверили представлять фасадную часть владельцу.
Примечание. Разработчику необходимо соблюдать осторожность при внесении предложений, касающихся общих архитектурных решений сайта. В порыве энтузиазма амбициозный разработчик может взять на себя обязательство разработки решения, работающего в частных случаях, но налагающего большие ограничения.
После представления фасадной части в функциональную спецификацию вносятся изменения (если это необходимо), и, в случае одобрения владельцем, процесс моделирования считается завершенным. Документ XML "крайнего случая", созданный при моделировании фасадной части, определяет модель данных программного решения. Элементы XML внутри спецификаций XML представляют собой экземпляры объектов в формате языка XML. Заключительным действием этапа моделирования является описание способов конфигурирования имеющегося решения или создание нового решения, представляющего определенные в ходе фасадного моделирования объекты в виде XML.
Техническая спецификация должна быть достаточно подробной, чтобы команда разработки разработала необходимое программное решение согласно указанным позициям. В этом случае помогает документирование, когда разработчика излагает свои соображения на бумаге. Техническая спецификация дополняет функциональную спецификацию планом построения программного обеспечения. Техническая спецификация включает в себя следующие элементы.
При построении технической спецификации следует руководствоваться той же стратегией нумерации, что и в функциональной спецификации (см. рис. 6.4) Лицевая страница технической спецификации во многом похожа на титульную страницу функциональной спецификации.
Следует создать общую структуру или шаблон технической спецификации для обеспечения состоятельности технической спецификации. Шаблон применяется по умолчанию, и можно отказаться от его использования, чтобы обеспечить соответствие документа требованиям, предъявляемым к описанию модели. Если документ изменяется для каждого проекта, следует скорректировать шаблон документа. Ниже приведена рекомендуемая структура технической спецификации.
Данная область представляет собой набор основных положений, отражающих производство рассматриваемого решения. Во введении не должны дублироваться сведения из функциональной спецификации; вместо этого в нем описывается проект так, как если бы разработчик был ознакомлен с функциональной спецификацией. Опасность дублирования информации из функциональной спецификации состоит в том, что данный документ обычно обновляется и не принадлежит автору технической спецификации. Функциональную спецификацию можно обновить для подготовки к предстоящему усовершенствованию решения. Если техническая спецификация содержит во введении данные, измененные в функциональной спецификации в результате обновления, то она считается некорректной.
В данном разделе представляются сущности, выявленные в процессе работы над фасадной частью проекта. Здесь приводится сводная диаграмма, отражающая связь этих объектов в реальном мире. Данный раздел предназначен для документирования аналитических заключений, появившихся в результате разработки фасада, а также для обеспечения вспомогательного базиса для создаваемой модели классов.
Данный раздел содержит код, обеспечивающий поддержку экземпляров объектов, описанных в объектной модели. Эти два раздела кажутся аналогичными, однако различие заключается в том, что определенные классы могут представлять несколько экземпляров объектов. Модель класса обеспечивает абстракцию от объектов реального мира к структурам кода, представляющим эти объекты.
В данном разделе представляется описание слоя данных или способа
хранения данных в системе. Классовая диаграмма является хранилищем
данных внутри памяти, а диаграмма данных – аппаратной системой хранения
информации. В этом разделе приводится описание модели базы данных, а
также файлов и
В данном разделе приводится описание возможностей программного решения,
если оно создано правильно. Здесь можно привести тест или набор тестов,
которые нужно создать для проверки программного решения и заключения о
правильности функционирования решения в процессе тестирования. В данном
разделе необходимо описать данные, обеспечивающие условия
"крайнего случая" для модульного тестирования.
"Крайний случай" обычно представляет собой обработку строк,
содержащих специальные символы, таких как ~ ` ! @ # $ % ^ * ( ) _
+ - { } [ ] \ | ; : ' " < > ? / .,.
Данные "крайнего случая" позволяют определить время выполнения при обработке большего объема данных по сравнению с обычным, с которым чаще всего взаимодействует решение.
В данном разделе описывается способ переноса решения в среду функционирования. Диаграмма реализации показывает файлы, обеспечивающие существование классов и функций. Решение, как правило, состоит из нескольких библиотек DLL, поэтому диаграмма определяет имеющиеся или новые библиотеки DLL, содержащие классы или функции. С помощью версии и имени необходимо определить зависимости решения. Кроме этого, следует предоставить инструкции по установке и деинсталляции наряду с описанием действий по проверке правильности произведенной установки.
Сценарии
Сценарий
Сценарий тестирования оформляется в виде таблицы со следующими полями.
Построение решения заключается в написании разработчиком кода или сценариев конфигурации программного обеспечения в соответствии с требованиями технической и функциональной спецификациях. В качестве вспомогательных действий разработчик осуществляет модульное тестирование и контроль кода. При необходимости создается документация для конечного пользователя. В таблице 6.4 приведены промежуточные результаты этапа построения решения.
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Код | Разработчики. |
| 2 | Документация | Разработчики. |
При написании кода разработчик руководствуется технической и функциональной спецификацией. Если в процессе программирования возникают трудности, связанные с техническим или функциональным проектом, о них нужно сообщить ответственному за соответствующий документ – разработчику (для технической спецификации) или бизнес-аналитику (для функциональной спецификации). При возникновении проблем разработчик должен описать причину для внесения корректив в структуру решения. Разработчик предлагает рекомендации по решению возникающих проблем, что поддерживает ответственность за программное решение всех участников проекта. Обязанности разработчика при написании кода заключаются в следующем.
Разработчик создает код на своем рабочем компьютере, здесь же он выполняет модульное тестирование. Целью модульного тестирования является подтверждение правильности работы функций и классов. При возникновении ошибки модульное тестирование позволяет отыскать дефекты в логических алгоритмах или же недостатки спецификации.
При успешном завершении модульного тестирования решение нужно перенести в другую среду для проведения комплексного тестирования. Этот тип тестирования проверяет его совместную работу с другими программами, с которыми ему предстоит взаимодействовать.
При возникновении ошибки модульное тестирование позволит определить место нахождения дефектов в логических алгоритмах или недостатки спецификации.
Если решение прошло тестирование обоих видов, его нужно перенести в
отдельную среду для проведения
При переносе решения с одной среды тестирования на другую необходимо внимательно управлять этими средами. В среде разработки для интернета существуют следующие среды.
Рабочая станция разработчика обеспечивает самую
Среду контроля качества нужно отделить от среды разработки, чтобы решения тестировались одновременно с работой программистов над другими частями программы. Данная среда предназначена для функционального тестирования сотрудниками отдела контроля качества. Среда контроля качества должна быть максимально приближена к той среде, в которой будет функционировать готовое программное решение. Доступ разработчиков в данную среду нужно запретить, чтобы решения устанавливались только старшими разработчиками или сотрудниками отдела контроля качества. Опасность предоставления доступа большому числу людей заключается в повреждении сценариев тестирования. Эту среду отделяют от интернета, так как она не поддерживает работу с глобальной сетью, в которой будет функционировать решение. Производительность не играет особой роли, поэтому не следует выделять дополнительные ресурсы. В данной среде обеспечиваются те же физические ограничения, что и в среде функционирования решения. Например, если решение работает в распределенной среде или среде с балансировкой нагрузки, то физические ограничения нужно продублировать, чтобы максимально приблизиться к той среде, в которой могут возникнуть ошибки.
Среда подготовки обеспечивает тестирование решения для одобрения его владельцем после прохождения функционального теста. Здесь владелец является главным лицом, принимающим работу. Среда подготовки используется в следующих целях.
Среду подготовки нужно полностью закрыть для доступа разработчиками. Ее изменения должны контролироваться системным администратором.
Среда функционирования – это узел, на котором располагается доступный клиенту продукт. Главным потребителем в среде функционирования является конечный пользователь. В данной среде важен уровень производительности. Управление средой функционирования осуществляется только системным персоналом.
После прохождения решением модульного и комплексного тестирования сотрудник отдела контроля качества должен выполнить функциональные сценарии для тестирования решения. Назначение данного теста заключается в следующем.
При обнаружении отклонений или дефектов тестировщик должен остановить сценарий тестирования, зафиксировать результат ошибочного события и отправить его разработчикам. В зависимости от серьезности и приоритета ошибки разработчики разрабатывают "заплатку" или вносят коррективы в следующую реализацию решения. В таблице 6.5 приведен обзор промежуточных результатов этапа тестирования.
| Порядок выполнения | Промежуточный результат | Ответственная сторона |
|---|---|---|
| 1 | Выполнение сценария тестирования | Контроль качества. |
| 2 | Описание ошибки | Тестировщик. |
| 3 | Устранение ошибки | Разработчики. |
В большинстве организаций, занимающихся разработкой, используется программное обеспечение для записи, постановки в очередь и отслеживания ошибок. Система отслеживания ошибок поддерживает следующие возможности.
Как правило, при
Последним шагом является реализация решения. Как правило, речь идет об установке системным администратором программы на веб-сервер и другие необходимые узлы. Установка по возможности проводится с помощью программного обеспечения, в автоматизированном режиме, без ручного копирования файлов.
Некоторые программные пакеты служат для построения программ установки. Это, например, шаблоны проекта программы установки Visual Studio .NET InstallShield или Wyse. Построение программы установки может показаться лишним, но оно позволяет избежать ошибок установки. Программа установки является частью решения и проходит соответствующие тесты. При установке должен проводиться тест для подтверждения правильности инсталляции решения, чтобы установщик знал о возникновении любых неполадок. В программное решение также следует включить сценарий деинсталляции.
Еще одним действием при производстве программного продукта является реклама и информирование конечных пользователей о появлении нового решения. Эти действия требуют строгого соблюдения сроков сдачи проекта, и реализация в этом случае должна происходить точно по назначенному расписанию.
После завершения проекта следует провести анализ для определения того, насколько методология процесса приемлема для организации. Процесс, представленный в данной лекции, появился в результате такого анализа. Был добавлен этап работы над фасадной частью, так как сотрудники отдела рекламы и продаж не понимали функциональную спецификацию и должны были увидеть решение на экране монитора. Циклы разработки обычно длились около шести месяцев, однако организация нуждалась в более частом усовершенствовании своего сайта. В результате разработчики сократили цикл до трех месяцев и выяснили, что усовершенствования можно проводить с большей степенью надежности из-за снижения объема выполняемых работ.
Анализ должен ответить на следующие вопросы.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.