фывфв. Руководство пользователя Контрольный пример
 Скачать 7.68 Mb.
|
СпецификацияСпецификация, определение требований к программе - один из важнейших этапов, на котором подробно описывается исходная информация, формулируются требования к результату, поведение программы в особых случаях (например, при вводе неверных данных), разрабатываются диалоговые окна, обеспечивающие взаимодействие пользователя и программы. Процесс разработки начинается с создания концептуального описания будущего продукта, задающего "по-крупному" его образ, видение (этот документ так и называется "vision statement") в контексте требований рынка. Главным действующим лицом на этом этапе является "менеджер по продукту" (product manager) - специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача - донести до менеджеров по разработке ПО потребительские свойства будущего продукта, т.е. указать, какие цели и требования пользователей необходимо удовлетворить, какие для этого заложить функциональные возможности (product features) и в каком порядке в соответствии с существующими приоритетами следует их ранжировать. На основании vision statement менеджеры по разработке составляют функциональную спецификацию. Здесь функциональные особенности будущего продукта прописываются все еще с точки зрения будущего пользователя, правда, с большей степенью подробности, глубины и формализованное. Затрагиваются вопросы архитектуры проекта, определяются основные компоненты и взаимосвязи между ними. Принципиально то, что эта начальная спецификация вовсе не должна фиксировать всю функциональность будущего продукта, как и детали каждой из уже определенных функций. В течение последующих этапов работы эта спецификация подвергнется ревизии по мере того, как разработчики будут больше узнавать о самом продукте, обретающем материальное воплощение и в связи с этим способность "сообщать" о целесообразности наличия (формы) той или иной функции. На изменение функциональности будут влиять и внешние факторы, в том числе те реальные и потенциальные рыночные продукты, которые так или иначе конкурируют с разрабатываемым ПО. Наконец, функциональность зависит и от таких прозаических факторов, как недостаток ресурсов, отставание от графика или просто изъяны в реализации, которые невозможно или некогда исправить. В этом смысле корпоративная культура компании Microsoft не предполагает каких-либо комплексов: здесь без колебаний "режут по живому", отдавая приоритет своевременности выброса продукта на рынок. Статистические данные по основным продуктам Microsoft показывают, что в среднем около 25% содержащихся в исходной спецификации (разрекламированных, а потому ожидаемых потребителем) функциональных особенностей исчезают ко времени выпуска продукта; если же считать и то, что привнесено, то конечная функциональность будет отличаться от исходной на 30% и более. На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с проектировщиками, начинают на модульной основе создавать горизонтальную архитектуру продукта. Главное, что на этой стадии все основные функции ПО разбиваются на несколько групп (обычно три-четыре группы). Соответственно, формируется столько же подпроектов, работа над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификации функций по степени важности. Наиболее важные (1/3 от общего количества, если групп всего 3) попадают в первый подпроект; другие, менее приоритетные, реализуются в рамках второго подпроекта, и наконец, прочие, наименее значимые функции выполняются в последнем подпроекте. Каждый подпроект заканчивается выпуском промежуточной "контрольной" версии продукта (milestone release). программа язык алгоритм спецификация Определенная таким образом архитектура проекта отображается на организационную структуру: для реализации отдельных Функций в рамках одного подпроекта назначаются небольшие команды (small feature teams), которые и работают параллельно и максимально автономно. Для них определяется график работы и выделяются необходимые ресурсы, за рамки которых выходить не рекомендуется. Причем большое значение на рассматриваемом этапе придается сознательному принятию этих рамок самими разработчиками, которые имеют возможность детально проанализировать назначенную им задачу. В результате график, планируемый с точностью до дня, часто оказывается чересчур оптимистичным. Следует обратить внимание на весьма упрощенный подход к разработке архитектуры программного продукта: по сути, само понятие архитектуры низводится до вспомогательного инструментария, подчиненного интересам организационного планирования и управления. Между тем, с точки зрения современных представлений хорошо структурированная архитектура продукта есть необходимое условие его успешной разработки и - что особенно важно! - дальнейшего развития. Именно поэтому виднейшие авторитеты в области Software Engineering, например Гради Буч, рассматривают архитектуру, определяющую логическую и физическую структуры программной системы, как основу надлежащих стратегических и тактических проектных решений в целях построения качественного продукта. Известно, что многие продукты компании Microsoft, созданные на шаткой основе заведомо неполной и постоянно изменяемой спецификации, во многом ущербны. Именно в этом разгадка удивительных на первый взгляд отличий последовательных версий одного и того же продукта, не говоря уже о продуктах разных, но в то же время преемственных идеологически. Яркий тому пример - реализация механизмов DLE - OLE - ActiveX. Консервативная "несущая конструкция", каковой является архитектура ПО, гнется и ломается под грузом малоуправляемых мутаций и деформаций. В результате - масса проблем при реализации такого желательного принципа разработки, как повторное использование кода: достаточно сказать, что 50 % кода изменяется каждые 18 месяцев! [6] |