'

Об управлении разработками в наших краях

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

Спасибо за внимание. Брагинский Матвей Аронович, главный технолог УП «ВЦ Мингорисполкома» тел. +375 17 251 75 52; факс +375 17 251 75 41; моб. +375 29 508 22 29; e-mail: mbr52@minsk.gov.by


×

HTML:





Ссылка: