Жизненный цикл разработки приложений: мечты и реальность
Не секрет, что немало коммерчески успешных продуктов как в России, так и за рубежом было реализовано с применением только средств разработки приложений, и даже данные при этом нередко проектировались на бумаге. Не будет преувеличением сказать, что из всех возможных инструментов создания программного обеспечения в России (да и во многих европейских странах) сейчас популярны главным образом средства разработки приложений и в несколько меньшей степени - средства проектирования данных (прежде всего это касается проектов с небольшим бюджетом и сжатыми сроками реализации). Вся проектная документация, начиная с технического задания и заканчивая инструкцией пользователя, создается с помощью текстовых редакторов, и то, что какая-то ее часть является исходной информацией для программиста, означает лишь, что он ее просто читает. И это при том, что, с одной стороны, средства управления требованиями, моделирования бизнес-процессов, инструменты тестирования приложений, средства управления проектами и даже средства генерации проектной документации существуют довольно давно, а с другой стороны, любой руководитель проекта, естественно, хочет облегчить жизнь как себе, так и остальным исполнителям.
Чем же обусловлено недоверие многих руководителей проектов к инструментам, позволяющим автоматизировать многие этапы работы возглавляемых ими коллективов? На мой взгляд, тому есть несколько причин. Первая из них заключается в том, что очень часто применяемые компанией средства плохо интегрируются между собой. Рассмотрим типичный пример: для моделирования применяется Rational Rose, для написания кода - Delphi Professional, для проектирования данных - CA AllFusion Modelling Suite; средства интеграции этих продуктов или вообще отсутствуют для данной комбинации их версий, или некорректно работают с русским языком, или просто не приобретены. А в результате диаграммы прецедентов и иные модели, созданные с помощью Rose, становятся не более чем картинками в проектной документации, а модель данных главным образом служит источником ответа на вопросы типа: "Зачем это поле вообще нужно в той таблице?" И даже такие простые части приложения, как русские эквиваленты имен полей базы данных, пишутся участниками проекта как минимум три раза: один раз - при документировании модели данных или приложения, второй раз - при написании кода пользовательского интерфейса, а третий - при создании файла справочной системы и руководства пользователя.
Вторая, не менее серьезная причина недоверия к средствам поддержки жизненного цикла программного обеспечения заключается в том, что опять-таки из-за отсутствия или плохой функциональности средств интеграции таких продуктов во многих случаях может оказаться недоступной возможность постоянной синхронизации между собой всех частей проекта: моделей процессов, моделей данных, кода приложения, структуры базы данных. Понятно, что проект, реализующий классическую схему водопада (рис. 1), при которой сначала формулируются требования, потом производится моделирование и проектирование, затем разработка и, наконец, внедрение (об этой схеме и о других методологиях реализации проектов можно прочесть в серии обзоров Лилии Хаф, публикуемой в нашем журнале), есть скорее мечта, чем реальность - пока пишется код, заказчик успеет изменить у себя часть процессов или пожелать дополнительной функциональности. В результате выполнения проекта нередко получаются приложение, весьма далекое от того, что было описано в техническом задании, и база данных, имеющая мало общего с исходной моделью, причем синхронизация всего этого между собой с целью документирования и передачи заказчику превращается в довольно трудоемкую задачу.
Рис. 1. Схема водопада
Третья причина, по которой средства поддержки жизненного цикла программного обеспечения применяются далеко не везде, где они могли бы принести пользу, заключается в крайней ограниченности их выбора. На российском рынке активно продвигаются главным образом две линейки продуктов: инструменты IBM/Rational и инструменты Computer Associates (главным образом линейка продуктов AllFusion Modelling Suite), во многом ориентированные в данный момент на определенные виды моделирования, а не на постоянный процесс синхронизации кода, базы данных и моделей.
Есть и еще одна причина, которую можно отнести к разряду психологических факторов: существуют разработчики, которые вовсе не стремятся к полной формализации и документированию их приложений - ведь в этом случае они становятся незаменимыми и ценными сотрудниками, а человек, вынужденный разбираться после увольнения такого разработчика в его коде или просто сопровождающий его продукт, будет очень долго чувствовать себя полным идиотом. Такие разработчики, конечно, отнюдь не в большинстве, тем не менее я знаю как минимум пятерых руководителей компаний, которым подобные экс-сотрудники попортили немало крови.
Конечно, многим руководителям проектов, особенно проектов с небольшим бюджетом и ограниченными сроками, хотелось бы иметь инструмент, с помощью которого можно было бы сформулировать требования к разрабатываемому программному продукту... и в результате получить готовый дистрибутив работающего приложения. Это, конечно, лишь идеал, о котором пока можно только мечтать. Но если спуститься с небес на землю, то можно сформулировать более конкретные пожелания, а именно:
1. Средства управления требованиями должны упростить создание модели приложения и модели данных.
2. На основании этих моделей должна генерироваться значительная часть кода (желательно не только клиентского, но и серверного).
3. Значительная часть документации должна генерироваться автоматически, причем на языке той страны, для которой предназначено данное приложение.
4. При создании кода приложения в моделях должны происходить автоматические изменения, а при изменении модели должна происходить автоматическая генерация кода.
5. Код, написанный вручную, не должен исчезать при изменениях в модели.
6. Появление нового требования заказчика не должно вызывать серьезных проблем, связанных с изменениями моделей, кода, базы данных и документации; при этом все изменения должны производиться синхронно.
7. Средства контроля версий всего вышеперечисленного должны быть удобны с точки зрения поиска и отслеживания изменений.
8. И наконец, все эти данные (требования, код, модели, документация) должны быть доступны участникам проекта именно в той степени, в какой они необходимы им для выполнения своих обязанностей - не больше и не меньше.
Иными словами, цикл разработки приложений должен давать возможность осуществлять итеративную коллективную разработку без дополнительных затрат, связанных с изменениями требований заказчиков или способов их реализации.
Не буду вас уверять, что все эти пожелания абсолютно невозможно осуществить с помощью инструментов IBM/Rational или CA - технологии развиваются, появляются новые продукты, и то, что было невозможно сегодня, станет доступным завтра. Но, как показывает практика, интеграция этих инструментов с наиболее популярными средствами разработки, к сожалению, пока далеко не столь идеальна, как могло бы показаться на первый взгляд.