«Что, где, когда?» современного софтостроения

Часто ли вы задумывались над тем, откуда берутся сложные программные продукты, кто и как их создает? Возможно ли создание крупной серьезной системы небольшой командой или для этого нужна целая корпорация? Как быстро можно создать такую систему? Попробуем разобраться в этих вопросах...

– Что такое индустриальное программирование?
– Сидят индусы и пишут «триальные» программы!
Интернет-шутка последних лет

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

Стандартом де-факто в этой области сегодня является 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) – это открывает перед ними двери для заказов более высокого уровня. И конечно, выигрывают от этого все: и компании-разработчики, и пользователи, которые потом работают с их продукцией.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365