Главная цель этого этапа — удостовериться в том, что вы понимаете потребности пользователя и приоритеты направлений разработки.
Далее следует функциональная спецификация — это мост между начальным обзором требований и технической спецификацией, разрабатываемой позже. Документ должен состоять из логических разделов типа краткого обзора системы, сопровождаемого кратким описанием главных фрагментов или функциональных объектов. Демонстрация планируемых экранных форм должна показывать основные направления действий с главными функциональными объектами и модулями программы. Раздел описания отчетов должен содержать все отчетные формы, которые вы планируете создавать. В больших системах основные модули могут быть разбиты на более простые с описанием того, что эти, более простые модули, будут делать.
Планируйте данный документ таким образом, чтобы пользователь, который не заинтересован в рассмотрении детальных особенностей системы, мог бы прочитать только первую часть документа с описанием основных функций, выполняемых системой. Пользователи, заинтересованные в рассмотрении более подробных деталей, могут продолжать читать документ дальше.
12.8. ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ
Ваши спецификации должны отвечать всем требованиям пользователей. Убедитесь, обратившись опять к начальному анализу перед завершением спецификации, что учтены все требования и запросы пользователей. Если требование пользователя не может быть удовлетворено, объясните, почему, а не просто исключите его из спецификации.
Вы также должны обсудить с пользователем ограниченные ресурсы, которые имеются у пользователя. Девяносто девять процентов проблем, возникающих при программировании, могут быть решены путем использования специфических внешних устройств, драйверов и сторонних программ.
Предположим, функциональная спецификация разработана, подписана и положена на полку. Но она может оказаться полностью бесполезной по ряду причин. При неправильном отношении к разработке функциональной спецификации она может быть плохо написана, плохо организована или, что наиболее вероятно, обременена томами описания ненужных технических подробностей. Говоря другими словами, работать с таким документом будет невозможно.
Одной из наиболее опасных болезней разработки программ является синдром "ползущего проекта", или "оползня". Он проявляется, когда функциональная спецификация неполно рассматривает отдельные аспекты проекта. В этом случае, по мере создания системы, пользователи, рассматривая отдельные готовые модули, будут просить внести некоторые усовершенствования, ссылаясь на неясные описания данного модуля в функциональной спецификации. Постепенно система будет приобретать вид огромного динозавра в заплатках, поскольку глобальные изменения разработанных структур программы производить уже нельзя, а изменения и усовершенствования необходимо вносить. Это может привести к перерасходу временного лимита на создание отдельных модулей и нестабильности работы системы из-за выпадания отдельных функциональных кусков программы из строгой общей схемы всей системы.
Быстрое макетирование — метод проектирования, разработки и изменения интерфейсов пользователя "на лету". Конечные пользователи должны активно включаться в данный процесс, поскольку разработка интерфейса вместе с пользователем происходит значительно быстрее, нежели без него. Совместная разработка дает возможность "подогнать" интерфейс под пользователя за несколько коротких сессий. Для этого существуют специальные средства, в частности CASE-средства. С мощными CASE-средствами процесс разработки приложений заметно упрощается. Проектировщик использует программные средства для создания и компоновки словарей данных, потоков данных и диаграмм объектов, а в некоторых случаях прототипов процессов обработки данных и функционального кода.
Однако использование CASE-средств разработки приложений не очень распространено в сфере разработки промышленных приложений. Это происходит по двум причинам. Во-первых, это ограниченность возможностей CASE-систем. Во-вторых, если CASE-система достаточно мощна и многофункциональна, то она требует больших временных затрат на ее освоение.
В конце данного этапа, если была написана хорошая, легко понимаемая, неперегруженная и непустая функциональная спецификация, системный аналитик или техническая группа сможет перейти к следующему этапу — созданию технической спецификации, — основываясь на информации, полученной на всех предыдущих этапах.
12.9. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
Техническое проектирование — это мост между функциональной спецификацией и фактической стадией кодирования. Часто команда разработчиков пытается сократить и объединить стадию разработки функциональной спецификации и техническое проектирование и разработать один документ. Это ошибка.
Во-первых, пользователь будет читать документ с большим количеством непонятных ему технических подробностей. В данном случае пользователь отбросит ваш документ, что может привести к недостаточной законченности упомянутого документа.
Во-вторых, если функциональная спецификация концентрирует внимание на требованиях и пожеланиях пользователя, то техническое проектирование должно ориентироваться на создание методов реализации данных требований. Только после того как обе эти фазы завершены и акценты расставлены, программист может приступать к непосредственному кодированию.
Когда обе эти стадии объединены, разработчик не может сконцентрироваться на каком-либо одном направлении мышления и в результате этого получается неясный и плохо отработанный документ. Или, что еще хуже, программист начинает реализовывать идею, которая еще не определена до конца пользователем.
Среда разработки позволяет всем членам команды знать размещение всех файлов проекта, библиотек, документов и другой связанной с проектом информации. Она должна быть создана таким образом, чтобы все члены команды разработчиков с минимальными затратами времени могли обратиться к любой информации, относящейся к проекту.
Создание временной диаграммы проекта является важнейшим этапом работ, на котором необходимо составить детальное расписание сроков начала и окончания разработки каждого модуля, частей проекта и всего проекта в целом. Необходимо учитывать время, затрачиваемое на дополнительные контакты с заказчиком, разработку специфических инструментальных средств, а также возможные проблемы, связанные с непредвиденными обстоятельствами (например, болезнь сотрудника или частичная потеря данных вследствие сбоев аппаратного обеспечения).
12.10. РЕАЛИЗАЦИЯ
Обычно на этапе кодирования всплывают все неприятные проблемы, которые только можно себе представить. Чем больше проект, тем больше проблем. Вот почему первые три шага так важны.
Если все из вышеописанных шагов полностью пройдены, то реализация программы значительно упрощается. В идеале все потенциальные узлы и ловушки должны быть предусмотрены и обойдены. Техническая спецификация может и должна быть передана команде программистов, выполняющих непосредственное кодирование, чтобы они могли записывать код, согласно детализированному проекту задачи. Любые проблемы, возникающие на этом этапе, должны отслеживаться программистами и помещаться в относящиеся к проблеме документы, чтобы отражать все возникающие изменения.
Обзор кода делается программистами — кодировщиками программ на специальной сессии (встрече). Как и на этапе обзора проекта, при обзоре кода "отлавливается" большое количество неточностей и ошибок, выявляются неоптимальные участки программы. Обзор кода позволяет также увидеть различным членам группы разработчиков фактический код, выполненный коллегами по проекту. Поскольку программирование является творческим процессом, то каждый член команды представляет видение одной и той же проблемы по-разному. Кто-то решает данный конкретный вопрос лучше, кто-то хуже. Обзор кода позволяет выявить хуже написанные участки программы и при необходимости переписать их, воспользовавшись советом более опытного члена команды. Также рассмотрение различных приемов, технологий и подходов к программированию позволяет воспользоваться ими для решения предстоящих проблем в последующих проектах. Особенно это полезно для новичков команды, хотя, как известно, "даже старую собаку можно научить новым трюкам".