He надо изобретать колесо

Работаете ли вы сами или надеетесь на консультантов, накопленный опыт поможет избежать разработки с нуля.

Грег Диджиованни использовал все возможности, когда менеджер по вопросам информации фирмы Nabisco (Парсиппани, шт. Нью-Джерси) Джо Фарелли обязал всех сотрудников отдела информационных технологий (ИТ) выработать свод правил для разработки приложений на уровне предприятия. После года участия в различных конференциях и разговорах с консультантами в поисках заказанного боссом готового решения Диджованни пришел к нему с пустыми руками.

Разочарованный таким результатом Диджиованни укрепился во мнении, что фирме необходимо самой формализовать процесс разработки. Что же он предлагает? По его мнению, фирма-изготовитель печенья и крекеров должна находиться в "автономном" полете и создать свои собственные инструкции на базе накопленного опыта.

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

Пол Тиннирелло, старший вице-президент по информационным системам AM Best, страховой организации в Клинтоне (шт. Нью-Джерси) и автор учебника по разработке приложений (Handbook on Application Development), заметил: "Собственные методики компаний могут быть так же трудны в использовании, как и любые покупные, потому что в них есть все, кроме

главного". Предложения Тиннирелло допускают много вариантов и условий при создании методологии учета опыта.

НЕ ЗАПИРАЙТЕ МЕНЯ

Этот совет как нельзя лучше соответствовал плану Диджиованни. Менеджер компании Nabisco по поддержке разработки приложений хотел создать свод гибких правил для развивающейся области клиент-сервер, а не зацикливаться на старой статической методологии. Так в Nabisco было положено начало проекту SRC (System Release Cycle), который будет готов в следующем году.

Средства Nabisco SRC, дополняющие стандартный для Nabisco набор инструментов разработки под Windows, таких, как Visual Basic корпорации Microsoft и PowerBuilder фирмы Sybase,  -  объединят экспериментальные правила создания ПО, выработанные восемью ИТ-группами компании в области построения приложений для предприятия.

Собранный в SRC свод практических правил будет применяться всей компанией. Среди них: данные о конфигурации моделей ПК, электронных таблицах, текстовых процессорах и клиентах электронной почты, а еще  -  требование, чтобы каждое приложение перед вводом в эксплуатацию проходило тестирование в лаборатории контроля качества Nabisco для гарантии того, что оно соответствует стандартам группы.

"Мы хотели отыскать тактический подход, который отвечал бы нашим потребностям в разработках клиент-сервер и в то же время был бы достаточно гибок, чтобы воспринять последующие рыночные изменения в области анализа и проектирования",  -  объяснил Диджиованни. В основе SRC лежат практические правила, согласно которым приложения и усовершенствования должны выпускаться в 4 этапа поэтапно, а не сразу. Это вовлекает пользователей в работу над проектом на более ранних этапах, и они успевают вовремя сделать свои замечания, в то время как работники отделов ИТ могут более эффективно учесть их требования.

"Такой подход доказывает, что сегодня разработка приложений  -  динамичный и развивающийся процесс, зависящий от нововведений независимых поставщиков ПО,"  -  сказал Диджиованни.

Подобный уровень гибкости нужен не каждой компании. Например, компания Kemper National Insurance (Лонг Гроув, шт. Иллинойс) знает, что существуют стабильные продукты, используемые в задачах системного анализа, проектирования, архитектуры и разделения. Компания Kemper в прошлом году для перехода на архитектуру клиент-сервер выбрала Architect Process Manager, продукт управления процессами фирмы James Martin & Со. (Рестон, шт. Виргиния).

Компонент этой системы Architect: Planner позволил фирме Kemper приспосабливать шаблоны проектов таким образом, чтобы иметь возможность вводить в них свой свод практических правил, объединяя их в одно целое. Эти правила включают сессии совместной разработки приложений для получения обратной связи от пользователей, формальный обзор систем по техническим вопросам и согласование проектов с пользователями для обсуждения области действия и назначения ответственных подразделений. Свод практических правил в фирме Kemper также требует оценки каждой фазы разработки и включения руководящих правил с целью повторного использования процесса при построении приложений в будущем.

"Когда разработчики систем приходят к Architect: Planner, они могут обращаться к методологии непосредственно... и видят, как фактически выполнить задание по плану (шаблону) проекта",  -  говорит Мэрилин Ричардс, старший аналитик отдела контроля качества в фирме Kemper. По ее словам, "эта методология увеличила продуктивность планирования проекта и способствовала разработке более качественных систем".

ПОЛЬЗА ОБЩЕНИЯ С ЗАКАЗЧИКОМ

Корпорация United America Health Care (Детройт) имела представление о том, как перейти на архитектуру клиент-сервер, но ее сотрудники не обладали достаточным опытом. Для помощи в формализации накопленного опыта разработки программного обеспечения корпорация обратилась в консультационную фирму Grant Thornton LLP (Чикаго).

Команда Гранта Торнтона, используя методологию Extended Relational Analysis, разработанную корпорацией Relational Systems (Бирмингем, шт. Мичиган), выделила в 10 отделах United America от 7 до 14 дней для обсуждения с пользователями их бизнес-процессов. Это было первым элементом формализации накопленного опыта.

Консультанты использовали методологию Extended Relational Analysis для разработки проекта базы данных и прототипов графических интерфейсов пользователя, которые периодически предъявлялись на рецензию. Это было вторым элементом формализации накопленного опыта.

"В сотрудничестве с отделом информационных систем управления корпорации UA Грант Торнтон определил удобные окна ввода и формы отчетов на основании требований пользователей и задокументировал все бизнес-правила, полученные на этапе построения прототипов и разработки проекта базы данных,"  -  сказал Майк Дойл, ныне директор по системам корпорации UA, являвшийся координатором этого проекта, начатого в октябре 1993 г., со стороны Гранта Торнтона. Среди бизнес-правил была формула для определения даты выписки пациента и процедура оплаты пребывания в больнице.

"Команда создала большую библиотеку классов с помощью программы SQLWindows корпорации Gupta. Эта библиотека поможет ввести обязательные стандарты на приложения, а также на методы разработки кода",  -  дополнил Дойл.

В результате общения с пользователями консультанты смогли оценить продолжительность разработки. "Мы поняли сложность бизнес-процессов и бизнес-логики вне зависимости от того, какие средства используются для создания кода",  -  заметил Дойл.

У Гранта Торнтона и персонала отдела информационных систем управления ушло пять месяцев на создание проекта и па определение сроков построения приложений для 10 отделов корпорации UA. В результате этого процесса корпорации UA удалось формализовать еще несколько практических правил: теперь проводится ежемесячное собрание управленцев различного ранга для отслеживания проекта и получения отзывов по приложениям, устанавливаются конкретные сроки, чтобы избежать повторных рассмотрений одного и того же. "Иначе вы этот проект никогда не завершите",  -  сказал Дойл.

Фирма Nabisco также многого ожидает от свода практических правил после внедрения SRC.

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

ЭСТЕР ШАЙН