В Камаев - Технологии программирования

Одной из наиболее опасных болезней разработки программ является синдром "ползущего проекта", или "оползня". Он проявляется, когда функциональная спецификация неполно рассматривает отдельные аспекты проекта. В этом случае, по мере создания системы, пользователи, рассматривая отдельные готовые модули, будут просить внести некоторые усовершенствования, ссылаясь на неясные описания данного модуля в функциональной спецификации. Постепенно система будет приобретать вид огромного динозавра в заплатках, поскольку глобальные изменения разработанных структур программы производить уже нельзя, а изменения и усовершенствования необходимо вносить. Это может привести к перерасходу временного лимита на создание отдельных модулей и нестабильности работы системы из-за выпадания отдельных функциональных кусков программы из строгой общей схемы всей системы.

Быстрое макетирование — метод проектирования, разработки и изменения интерфейсов пользователя "на лету". Конечные пользователи должны активно включаться в данный процесс, поскольку разработка интерфейса вместе с пользователем происходит значительно быстрее, нежели без него. Совместная разработка дает возможность "подогнать" интерфейс под пользователя за несколько коротких сессий. Для этого существуют специальные средства, в частности CASE-средства. С мощными CASE-средствами процесс разработки приложений заметно упрощается. Проектировщик использует программные средства для создания и компоновки словарей данных, потоков данных и диаграмм объектов, а в некоторых случаях прототипов процессов обработки данных и функционального кода.

Однако использование CASE-средств разработки приложений не очень распространено в сфере разработки промышленных приложений. Это происходит по двум причинам. Во-первых, это ограниченность возможностей CASE-систем. Во-вторых, если CASE-система достаточно мощна и многофункциональна, то она требует больших временных затрат на ее освоение.

В конце данного этапа, если была написана хорошая, легко понимаемая, неперегруженная и непустая функциональная спецификация, системный аналитик или техническая группа сможет перейти к следующему этапу — созданию технической спецификации, — основываясь на информации, полученной на всех предыдущих этапах.

Техническое проектирование — это мост между функциональной спецификацией и фактической стадией кодирования. Часто команда разработчиков пытается сократить и объединить стадию разработки функциональной спецификации и техническое проектирование и разработать один документ. Это ошибка.

Во-первых, пользователь будет читать документ с большим количеством непонятных ему технических подробностей. В данном случае пользователь отбросит ваш документ, что может привести к недостаточной законченности упомянутого документа.

Во-вторых, если функциональная спецификация концентрирует внимание на требованиях и пожеланиях пользователя, то техническое проектирование должно ориентироваться на создание методов реализации данных требований. Только после того как обе эти фазы завершены и акценты расставлены, программист может приступать к непосредственному кодированию.

Когда обе эти стадии объединены, разработчик не может сконцентрироваться на каком-либо одном направлении мышления и в результате этого получается неясный и плохо отработанный документ. Или, что еще хуже, программист начинает реализовывать идею, которая еще не определена до конца пользователем.

Среда разработкипозволяет всем членам команды знать размещение всех файлов проекта, библиотек, документов и другой связанной с проектом информации. Она должна быть создана таким образом, чтобы все члены команды разработчиков с минимальными затратами времени могли обратиться к любой информации, относящейся к проекту.

Создание временной диаграммы проекта является важнейшим этапом работ, на котором необходимо составить детальное расписание сроков начала и окончания разработки каждого модуля, частей проекта и всего проекта в целом. Необходимо учитывать время, затрачиваемое на дополнительные контакты с заказчиком, разработку специфических инструментальных средств, а также возможные проблемы, связанные с непредвиденными обстоятельствами (например, болезнь сотрудника или частичная потеря данных вследствие сбоев аппаратного обеспечения).