Как показала экспертиза, разработка инструментария для предприятий процесс непрерывный
Питер Коффи (PC Week Labs)
На предприятиях с большими информационными потребностями каждая заказная программа не конечный результат, а лишь очередной кадр в непрерывном процессе, направленном на удовлетворение постоянно обновляемых запросов.
В то же время результаты тестирования в PC Week Labs показывают, что львиная доля инструментария разработки приложений отражает совершенно другой менталитет. В них заложена традиционная схема ввод символов исходного текста и генерация на их основе исполняемого файла. В таких системах проектирования очень трудно установить взаимосвязь между тем, что нам необходимо в первую очередь, и тем, что мы получаем на выходе. При этом очень редко удается добиться, чтобы наиболее важные задачи выполнялись в минимальные сроки.
Все дело здесь, видимо, в том, что разработчики рассматривают ПО как завершенный продукт и у них возникает желание максимально расширить его возможности. К сожалению, за это слишком часто приходится расплачиваться качеством готового продукта.
Такой подход уходит корнями в прошлое, когда переделка ПО обходилась очень дорого. А поскольку каждая модернизация приложения требовала значительных средств, разработчики стремились включить в свои дистрибутивные комплекты как можно больше функций.
Сегодня модернизация программного продукта стоит намного дешевле. Появилась возможность централизации ПО, например, его хранения в виде Java-приложений, загружаемых с сервера непосредственно перед запуском. Программный комплект можно построить и по модульному принципу, скажем в виде динамических загружаемых библиотек. Как бы то ни было, но правильный выбор структуры ПО позволяет разработчикам оснащать свои продукты новыми функциями, не причиняя пользователям практически никакого беспокойства.
Единственное, что по-прежнему обходится очень дорого, это ошибки в программе. Более того, приложения сегодня становятся лицом фирмы, поэтому высокую цену порой приходится платить даже за погрешности чисто “косметического” характера. Простая опечатка в тексте приветствия может быть воспринята как признак пренебрежения мелочами. Отделы информационных технологий уже давно с задворок уверенно перешли в ряды создателей корпоративного образа.
Вместе с этим изменились и используемые средства. Сейчас разработчики архитектуры систем на предприятиях получили новый инструментарий, который намного полнее соответствует стоимости и приоритетам сегодняшнего процесса внедрения приложений.
SmallCycle фирмы Unity автоматизирует генерацию предупреждений и исправление ошибок
Фирма CenterLine Software предлагает комплект Acqua систему управления распространением ПО. Входящий в него инструментарий создания сценариев и генерации отчетов направлен на удовлетворение пользовательских требований к приложениям, и достигается это за счет проведения соответствующих тестов. Кроме того, он позволяет обеспечить единообразный подход к тестированию на всех этапах разработки.
Координация применения разнообразных тестовых средств и автоматическое документирование полученных результатов, которые обеспечивает Acqua, позволяют избежать неприятных сюрпризов накануне сдачи проекта. У разработчиков остается запас времени, чтобы спокойно решить, какие из функций начальной версии можно безболезненно оставить “на потом”. Таким образом, каждая новая версия все более приближается к идеалу отсутствию ошибок.
Конечно, полностью избавиться от них удастся едва ли. Очень важно осознать это и составить план по выявлению, диагностике и устранению ошибок. Здесь на помощь приходит пакет SmallCycle фирмы Unity Software Systems, содержащий средства управления обслуживанием программных продуктов на протяжении всего их жизненного цикла и работающий совместно с VisualAge for Smalltalk корпорации IBM.
Приложения, созданные с использованием SmallCycle, автоматически оснащаются средствами выявления и перехвата ошибок непосредственно в ходе выполнения программы. Всю полученную информацию они пересылают в Lotus Notes, где генерируются предупреждения, извещающие не только об отмеченной ошибке, но и о том, в какой системе она обнаружена.
Такие предупреждения в свою очередь инициируют процесс анализа ошибки, ход которого можно контролировать с помощью Notes или через World Wide Web. Когда программа устранения ошибки готова, создается “файл-заплата”. Он пересылается через Notes и автоматически устанавливается в системе, где произошел сбой.
В результате разработчики получают более точные и оперативные предупреждения об ошибках, пользователи быстрый и удобный способ устранения сбоев, а руководство систематические отчеты, позволяющие составить картину возникновения и устранения ошибок. Благодаря этому удается не только снизить стоимость жизненного цикла ПО, но и сохранить клиентов, которые обычно отсеиваются из-за низкого качества исходного текста программы.
