Об управлении разработками в наших краях УП «ВЦ Мингорисполкома» г. Минск, Республика Беларусь

1. Постановка задачи и основной тезис 1. Основные причины проблем в области управления IT- разработками Массовый, почти скачкообразный, переход к персонализации вычислений. Расширение сферы применения компьютеров; выход разработчиков на контакт с потребителем; рост количества локальных задач; возрастание спроса на разработчиков, как следствие снижение их качества. «Развращение» заказчиков Распад СССР и изменение экономических условий. Сокращения ИТ-специалистов, отъезды и уход в другие сферы деятельности, массовый приход молодежи, следовательно снижение уровня специалистов и потеря среднего звена (25-35 лет). Оба фактора вызвали качественное изменение в профессиональной среде- разрушение сложившейся (и еще не очень устоявшейся тогда!) технологии. Тем не менее сходные проблемы были и есть и в других странах (судя по по книгам от Брукса и до авторов последнего времени). Проблемы первых руководителей. Сегодня – время восстановить распавшуюся связь времен и дел).

Трудности процесса восстановления нормального управления разработкой отражены на схеме:

Внешний элемент (фактор) здесь недовольство заказчиков, задержки проекта, трудности сопровождения. Хаос,безусловно, в головах. Преобразующая идея- методология основанная на стандартизации. При этом для успеха преобразования должны выполняться следующие условия: Компетентность –требовательность- контроль - триада-ядро нормального и результативного управления IT-разработками. Нарушение полноты этой конструкции с необходимостью влечет упущения в качественных показателях проекта.

2. Ситуация первая: управляет «компетентность» Плюсы: грамотная разработка архитектуры; правильная схема базы данных; хорошая проработка компонент и их взаимодействия; разрешение конфликтных ситуаций. Минусы: излишнее увлечение совершенством кода; недооценка разнозначимости частей системы; плохое знание внешних условий функционирования проекта, недооценка требований заказчика; недоработка документации. Результат: неполнота реализации с точки зрения заказчика, недостатки в документации, возможны трудности в сопровождении из-за сложности кода и недостаточности комментариев.

3. Ситуация вторая: управляет «требовательность» Плюсы: внешние спецификации отслеживаются; выдерживаются сроки предоставления результатов; подготовлена документация. Минусы: Не учтены все варианты функционирования, исключения, особые ситуации; проектные решения, схемы баз данных - «лобовые», нерациональные. Результат: «потемкинская деревня»: внешний лоск, но реальных удобств пользователя мало, надежность низкая, сопровождение затруднено; трудности в устранении замечаний пользователя в ходе эксплуатации проекта.

4. Ситуация третья: управляет «контроль». Плюсы:; выдерживаются сроки предоставления результатов; подготовлена документация. Минусы: плюсы зачастую фиктивны и усугубляются минусы предыдущего варианта; как правило, не все функционалы и сервисы ре6ализованы; документация оформлена вовремя, но неполна и неточна. Результат: еще хуже, чем в предыдущем варианте, но!… часто разработчику удается доказать, что формальные параметры проекта выполнены, повлияли сроки, недостаток финансирования – «доведем в ходе эксплуатации».

5. Ситуация четвертая: управляет «компетентность- требовательность». Плюсы: реализация на уровне; внешние спецификации выдержаны; документация подготовлена. Минусы: могут быть не соблюдены сроки предоставления результатов, например, вследствие несогласования действий разных групп разработчиков Результаты: вполне приемлемые.

6. Ситуация пятая: управляет «компетентность- контроль». Плюсы: реализация на уровне; внешние спецификации выдержаны; документация подготовлена. Минусы: могут быть не соблюдены сроки предоставления результатов, например, вследствие несогласования действий разных групп разработчиков; внешние спецификации изменены в ходе работ. Результаты: вполне приемлемые, но не без замечаний заказчика.

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

8. Ситуация седьмая: нет ничего Как ни странно, случается.

9. Ситуация восьмая: все есть! Бывает и такое!

10. Что делать? Регламентировать процесс управления разработкой с помощью методологии стандартов. Стандарт предприятия (СТП) на оформление текстов и программ. 1. Общие положения 2. Объекты, рассматриваемые в настоящем стандарте 3. Правила формирования имен Имена файлов, классов, объектов 3.2. Правила формирования имен переменных 3.3. Особые случаи (исключения 4. Правила форматирования исходного программного текста 5. Требования к экранной форме 6. Требования к терминологии пользовательского интерфейса 7. Оформление программы для передачи заказчику.

СТП «Технология проектирования». 1. Общие положения 2. Регламентация разработки проектных решений 2.1. Условия начала разработки 2.2. Общий состав работ по проектированию 2.3. Определение общей архитектуры системы (комплекса 2.4. Проектирование структуры базы данных 2.5. Формирование бизнес-процессов и алгоритмов обработки данных 2.6. Проектирование интерфейса пользователя 2.7. Программирование и тестирование 2.8. Разработка документации 2.9. Организационно-распорядительная документация 3. Порядок передачи проекта или его части на сопровождение (разработку, доработку) другому сотруднику 4. Сопровождение разработанной системы (комплекса) Приложения. Текущие проектные решения; Журнал разработчика; Журнал тестирования; Журнал сопровождения разработки.

СТП «Основные проектные решения». назначение и цели создания (развития) системы; краткая характеристика объектов автоматизации; основные технические решения; описание информационной базы; описание интерфейса пользователя; основные алгоритмы реализации; обработка аварийных (исключительных) ситуаций.

4. Применение ГОСТ (ОСТ, СТБ). Управление эффективнее, если управляемый процесс регламентирован. Разумное применение стандартов на этапы разработки может удачно сочетать обеспечение творческой свободы разработчиков с необходимостью регламентации достижений этой свободы. В сочетании с преемственностью поколений управленцев это может обеспечить реализацию приведенной триады.

Спасибо за внимание. Брагинский Матвей Аронович, главный технолог УП «ВЦ Мингорисполкома» тел ; факс ; моб ;