Часто ли вы задумывались над тем, откуда берутся сложные программные продукты, кто и как их создает? Возможно ли создание крупной серьезной системы небольшой командой или для этого нужна целая корпорация? Как быстро можно создать такую систему? Попробуем разобраться в этих вопросах…
– Что такое индустриальное программирование?
– Сидят индусы и пишут «триальные» программы!
Интернет-шутка последних лет
Как ни странно, но с точки зрения практика этот каламбур отражает текущее положение дел в области разработки программ. Судите сами. Во-первых, все больше ПО создается в режиме офшорного аутсорсинга. Во-вторых, считается хорошим тоном размещение «пробной» бесплатной версии на сайте разработчика. В-третьих, программа будет иметь коммерческий успех, если она разработана быстро. Поэтому масштабные программные продукты создаются крупными коллективами, и возникает необходимость в координации и управлении процессами.
Стандартом де-факто в этой области сегодня является RUP (Rational Unified Process), для которого есть соответствующий инструментарий, в том числе Open Source; написано множество документов и руководств, а также существует огромное количество примеров успешного применения этой методики на практике. Однако как в действительности разрабатывается ПО в компаниях, которые ориентированы на промышленный рынок?
Содержание
Иногда заказчик и разработчик общаются на столь разных языках, что контракт может сорваться, даже не начавшись. Тем не менее существуют довольно эффективные методики оценки софта. Вот что рекомендует Уоттс Хамфри (Watts S. Humphrey) в вышедшей в 2004 г. книге Managing the Software Process.
Прежде всего, добиться от заказчика максимально подробной и близкой к реальной картины его требований. В идеале должен получиться набор диаграмм прецедентов (UseCases) в UML-нотации.
Опытные компании всегда имеют готовые исходные тексты на том или ином языке программирования и образцы проектов в какой-либо среде управления ими. «Исходники» нужны для подсчета ориентировочного числа строк кода (Lines-of-Code, LOC), а данные о проекте – для расчета времени, за которое они могут быть получены. Исходя из цифр LOC определяется время разработки, количество ресурсов и в результате – стоимость проекта.
Инструментарий, который используется на этапе оценки нового ПО, – это, как правило, средства UML (Rational Rose, Poseidon for UML и др.) и интегрированные среды разработки с поддержкой централизованного хранения исходных кодов (CVS, Subversion и др.).
Прежде всего, зачем вообще RUP предусматривает этап моделирования? Почему бы не потратить это время на реальную разработку, вместо того чтобы «убивать» его на нечто непонятное, называемое «моделированием»?
Ответ прост: моделирование избавляет проектировщика от внесения правок в дизайн проекта в случае, если в процессе разработки требования клиента изменились или при проектировании были допущены ошибки либо сделаны неверные выводы. Элементарная прогонка на модели наиболее типичных ситуаций выявляет до 90% конструктивных ошибок, исправление которых обошлось бы дорого при реальной разработке.
При построении модели используется опыт и инструментарий, наработанный многими известными компаниями в рамках парадигмы быстрой разработки приложений (Rapid Application Developement, RAD). Вместе с тем полезность использования RAD при создании реальной системы весьма проблематична: немало типовых шаблонов не годится по тем или иным причинам, большинство универсальных модулей и библиотек обладает весьма посредственной производительностью и т. д.
А вот при моделировании системы использование RAD – это именно «то, что доктор прописал». Основными задачами здесь являются:
Инструментарий должен максимально экономить время при существенных изменениях системы, вплоть до изменения ее архитектуры, а также быть плотно связанным или иметь собственные средства, позволяющие оперативно обновлять документацию на проектируемую систему – как пользовательскую – для заказчика, так и техническую – для разработчика.
Исходя из практического опыта в качестве платформы моделирования можно рекомендовать Java, а в качестве рабочего инструмента – пакет Poseidon for UML, который существует как в виде коммерческой версии, так и Open Source (gentleware.com).
Как ни банально это звучит, этап проектирования – самый важный и сложный при построении ПО. Последствия ошибок, допущенных на данном этапе, могут быть фатальными для проекта. Однако если этап моделирования не был проигнорирован, в руках разработчика уже находится довольно мощное оружие. Еще более облегчат создание ПО типовые решения для разного рода задач – например, описанные в появившейся около трех лет назад книге Мартина Фаулера (Martin Fowler) Patterns of Enterprise Application Architecture. Ее можно рассматривать как справочник по типовым решениям, содержащий полезные советы и примеры реализации.
| EUP является расширением RUP. Жизненный цикл EUP включает две новые стадии, Построение и Вывод из эксплуатации, а также несколько новых классов задач в корпоративном разделе |
При проектировании серьезного ПО редко можно встретить экспериментирование. Гораздо большее значение имеет правильно организованная библиотека типовых решений. Способы организации зависят и от языка программирования, и от специфики ПО. Если не говорить о примитивном копировании кусков кода, то можно отметить два способа.
Один из них – организация библиотеки типовых решений в CVS вместе с набором скриптов, которые «затачивают» имеющееся в репозитории решение под конкретную задачу. Второй (и самый перспективный с точки зрения автора) – создание набора UML-диаграмм, объектов, классов и т. п. с соответствующими вставками кода. Конечно, на организацию такой библиотеки потребуется время. Но период разработки сокращается настолько, что его можно сравнить с RAD, и при этом качество программ повышается.
Инструментарий на этапе проектирования используется тот же, что и на этапе моделирования, – UML, только здесь упор делается на диаграммах классов, объектов и их взаимодействия. Вместе с тем стоит отметить, что возможность использовать UML-средства непосредственно в IDE-средах разработчики получили только в последнее время.
Этап реализации для компании, в которой правильно поставлен процесс разработки, лишен какого-либо креатива и, следовательно, относительно безопасен. Все ответственные решения приняты ранее, все межмодульные интерфейсы определены, существует даже пример «как должно быть» – модель. В отдельных случаях дело доходит до того, что на этапе реализации людей не привлекают. Известны проекты, разработанные в Rational Rose так тщательно, что сгенерированные исходные коды с необходимой функциональностью не требовали последующих правок. Но… Хотя данный этап и «механичен», тем не менее, и здесь можно допустить ошибки.
Первая связана с элементарной человеческой ленью, когда программист не дополняет создаваемый набор классов или библиотеку функций вразумительным комментарием. Хочется подчеркнуть, что комментирование исходного текста – обязательный этап разработки программ, и к нему нужно относиться серьезно. В том числе и из экономических соображений: при смене кодера новый человек легче и быстрее разберется в создаваемом исходном тексте. Современные IDE поддерживают и даже автоматизируют этот процесс: в Java это JavaDoc, в C/C++ – Doxygen.
Вторая распространенная ошибка – отсутствие корпоративного стиля форматирования исходного кода. Привычка к единому стилю оставляет кодеру больше времени для его основной работы. Кроме того, снижается количество различий между версиями – в них попадают только действительно значимые исправления. Опять же, IDE сейчас позволяют настраивать форматирование исходного кода и полностью приводить его в порядок.
Третья ошибка связана с системой поддержки командной работы, в частности культуры помещения изменений в CVS (хотя правильная и эффективная работа с CVS – не столько технически, сколько организационно – заслуживает отдельного рассмотрения).
Четвертая – отладка и собственно трактовка термина «отладка». Одни понимают под этим сугубо процесс прогонки программы в пошаговом режиме, другие – компиляцию с отладочной информацией и последующий просмотр логов, третьи и вовсе считают, что отладка – всего лишь исправление ошибок компилятора. По мнению автора, отладка – это подготовка программы к работе, предусматривающая все необходимые этапы. Тестировщику должна приходить готовая программа, а не ее сырая версия.
Итак, тестировщик – не отладчик. Его задача – как можно полнее выявить скрытые проблемы ПО, его недочеты, неудобства и т. п. При нормально поставленном процессе тестировщик лишен необходимости лицезреть «тупые баги» разработчика, обеспечен документацией о необходимых действиях пользователя (используя диаграммы прецедентов) и снабжен Unit-тестами для повторной проверки измененных версий программ.
Вообще, тестирование – тема больная. Хороший тестировщик в каком-то смысле актер. Он должен уметь войти в образ рядового пользователя и смоделировать его поведение при работе с системой. Если интерфейс неочевиден – он обязан это заметить, что не так легко, если смотришь на него и нажимаешь одни и те же кнопки сотни раз в день. С другой стороны тестировщик – инженер. Его задача – охватить своими действиями как можно большее количество логических ветвей системы и при этом правильно интерпретировать или хотя бы точно описать полученный результат в каком-либо инструменте фиксации ошибок (например, Bugzilla).
Если для утилит и «индус-триальных» программ процесс внедрения обычно ограничивается запуском инсталляционного архива, то для промышленного софта он не менее важен, чем все предыдущие. Здесь зачастую приходится решать разнообразные проблемы, не относящиеся напрямую к софту – с «железом», сетью, персоналом и т. д. Не зря для решения задач внедрения в UML предусмотрен специальный тип документов – диаграммы развертывания, где специфицируются различные аспекты и особенности системы на площадке заказчика. Но и эту проблему можно если не решить, то хотя бы значительно упростить при помощи соответствующих технических и инструментальных средств.
Речь идет об SNMP, сетевом протоколе для мониторинга работоспособности устройств или компонентов системы. В исследуемый компонент встраивается «SNMP-датчик», который опрашивается внешней системой сбора статистики и анализа (если используются типовые блоки, то в них уже могут быть встроены необходимые «SNMP-датчики»). В результате ПО, снабженное такой «вакциной», становится более управляемым и менее подверженным сбоям, что очень немаловажно на следующем этапе – сопровождения системы.
Довольно странно, что отцы-основатели методологии RUP не включили в исходную спецификацию этап сопровождения системы, хотя именно в промышленных условиях от применения RUP достигается наибольший эффект. Все этапы, следующие за внедрением, специфицированы в расширениях, например в EUP (Enterprise Unified Process) – см. рис.
Этап сопровождения очень важен в судьбе софтверного проекта. Сложную систему нельзя надолго оставлять без присмотра, и если IT-специалисты заказчика не смогут самостоятельно справиться с неполадками, может быть принято решение о ее замене продуктом другой компании. То же произойдет и при неадекватном сопровождении системы силами разработчика или специализированной компании.
Как правило, для сопровождения системы выделяется менеджер поддержки. Он является инициатором внесения изменений в исходный код и выпуска новой версии – т. е. нового витка этапов от моделирования до внедрения. Его задача существенно облегчается, если имеется система мониторинга. При соответствующей настройке она способна не просто указать на факт сбоя, но и помочь сделать правильный вывод о его причине и даже предупредить о том, что сбой скоро возникнет (естественно, с учетом того, что в поставляемый продукт встроены «SNMP-датчики»).
Далеко не всегда производитель выпускает качественное ПО в короткие сроки. Справедливо и обратное – не всегда быстро разработанное ПО качественное. Но при правильной организации процесса компания, безусловно, может быстро создавать отличные продукты. Для этого нужно всего лишь исключить наступание на те же грабли.
Сейчас и в нашей стране серьезные софтверные компании (причем серьезные – не обязательно крупные) по-настоящему озабочены внедрением у себя соответствующих процессов и последующей сертификацией уровня их зрелости (CMM, CMMI) – это открывает перед ними двери для заказов более высокого уровня. И конечно, выигрывают от этого все: и компании-разработчики, и пользователи, которые потом работают с их продукцией.