Анализ существующих систем
Некоторые программы пишутся, чтобы работать самостоятельно вне каких бы то ни было систем, напрямую взаимодействуя лишь с конечным пользователем. Однако часто приходится разрабатывать проекты, которые необходимо внедрить в уже существующую систему. В таком случае следует проанализировать все детали и механизмы работы систем, с которыми требуется наладить взаимодействие. Будет ли создаваемая система сервером, обслуживающим существующую систему, или ее клиентом? Сможете ли вы добиться однотипности интерфейсов двух систем и адаптировать свой проект к имеющимся стандартам? Будут ли взаимосвязи с существующей системой статическими или динамическими?
На эти и аналогичные вопросы следует отвечать на этапе анализа, прежде чем вы приступите к проектированию новой системы. Кроме того, необходимо зафиксировать те ограничения, которые могут возникнуть косвенно в результате взаимодействия двух систем. Не замедлит ли новая система работу существующей системы, не исчерпает ли она предоставляемые ресурсы и машинное время и т.д.
Когда наконец-то придет понимание того, что система должна делать и как себя вести, необходимо уточнить бюджет и сроки проекта. Часто крайний срок диктуется заказчиком: "На эту работу у вас 18 месяцев". У программиста на этот счет может быть свое мнение, которое необходимо высказать. Идеально, если заказчик и исполнитель придут к компромиссу, но в любом случае время и бюджет всякого проекта всегда ограничены. Уложиться в сроки и не превысить бюджет часто бывает труднее, чем написать программу.
При определении бюджета и сроков следует учесть два момента.
• Если вы определили, во сколько в среднем обойдется проект, то попросите немного больше, тогда, может быть, вам дадут ту сумму, на которую вы рассчитывали.
• Закон Либерти утверждает, что на все требуется больше времени, чем ожидалось,
даже если был учтен закон Либерти.
После того как время и бюджет будут установлены, определитесь с приоритетами. Вы все равно не уложитесь в срок, будьте к этому готовы. Важно, чтобы к тому моменту, когда нужно будет что-то показывать, у вас уже было что показать. Если вы строили мост, а время уже истекло, то позаботьтесь о том, чтобы была проложена хотя бы велосипедная дорожка. Это, конечно, не Бог весть что, но лучше чем ничего. По крайней мере, можно будет попросить денег на продолжение. Если же время истекло, а вы дошли только до середины реки, то это еще хуже.
Ко всем цифрам, зафиксированным в документации, следует относиться серьезно, но не "брать дурного в голову". В начале работ фактически невозможно точно оценить сроки выполнения проекта. Желательно приберечь для себя от 20 до 25% времени для маневра, если в ходе выполнения проекта возникнут неожиданности. В конце концов, для всех важен успех проекта и обоснованные колебания в сроках всегда допустимы.
Примечание: Мы вовсе не призываем к бесшабашному отношению к срокам, зафиксированным в документе. Просто реалии таковы, что на ранних этапах планирования невозможно точно определить, сколько времени и денег потребуется на разработку этого проекта. Приоритетом при этом должна быть максимальная реализация требований заказчика, что, вполне вероятно, может вызвать необходимость корректировки исходных цифр при выполнении проекта.
Визуализация является финальной частью документа требований. Такое модное название носят диаграммы, рисунки, изображения экранов, прототипы и другие визуальные средства, созданные для того, чтобы помочь в проектировании графического интерфейса пользователя создаваемого продукта.
При создании больших проектов бывает полезно разработать полный прототип проекта, чтобы лучше представить, как поведет себя система в тех или иных ситуациях. Часто графическое приложение к документации лучше всего справляется с функцией определения требований к проекту, так как позволяет наглядно увидеть, какой должна быть система и как она должна работать в конечном варианте.
К концу каждого этапа анализа и проектирования накапливается ряд документов, называемых артефактами. Приблизительный набор таких документов показан в табл. 18.1. Эти документы используются для организации взаимодействия и протоколирования отношений между заказчиком и исполнителем. Их подписание обеими сторонами гарантирует, что исполнитель четко понял и принял все требования заказчика и обязуется разработать в указанные сроки проект, который в окончательном варианте должен выполнять точно определенный ряд функций.
Читать дальше