Слайд 21. Постановка задачи и основной тезис
1. Основные причины проблем в области
![1. Постановка задачи и основной тезис 1. Основные причины проблем в области](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-1.jpg)
управления IT-разработками.
1.1. Массовый, почти скачкообразный, переход к персонализации вычислений.
Расширение сферы применения компьютеров; выход разработчиков на контакт с потребителем; рост количества локальных задач; возрастание спроса на разработчиков, как следствие снижение их качества. «Развращение» заказчиков.
1.2. Распад СССР и изменение экономических условий.
Сокращения ИТ-специалистов, отъезды и уход в другие сферы деятельности, массовый приход молодежи, следовательно снижение уровня специалистов и потеря среднего звена (25-35 лет).
Оба фактора вызвали качественное изменение в профессиональной среде- разрушение сложившейся (и еще не очень устоявшейся тогда!) технологии.
Тем не менее сходные проблемы были и есть и в других странах (судя по по книгам от Брукса и до авторов последнего времени).
Проблемы первых руководителей.
Сегодня – время восстановить распавшуюся связь времен и дел).
Слайд 3Трудности процесса восстановления нормального управления разработкой отражены на схеме:
![Трудности процесса восстановления нормального управления разработкой отражены на схеме:](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-2.jpg)
Слайд 4
Внешний элемент (фактор) здесь недовольство заказчиков, задержки проекта, трудности сопровождения.
![Внешний элемент (фактор) здесь недовольство заказчиков, задержки проекта, трудности сопровождения. Хаос ,безусловно,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-3.jpg)
Хаос ,безусловно, в головах.
Преобразующая идея- методология основанная на стандартизации.
При этом для успеха преобразования должны выполняться следующие условия:
Компетентность –требовательность- контроль - триада-ядро нормального и результативного управления IT-разработками.
Нарушение полноты этой конструкции с необходимостью влечет упущения в качественных показателях проекта.
Слайд 52. Ситуация первая: управляет «компетентность»
Плюсы: грамотная разработка архитектуры; правильная схема базы
![2. Ситуация первая: управляет «компетентность» Плюсы: грамотная разработка архитектуры; правильная схема базы](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-4.jpg)
данных; хорошая проработка компонент и их взаимодействия; разрешение конфликтных ситуаций.
Минусы: излишнее увлечение совершенством кода; недооценка разнозначимости частей системы; плохое знание внешних условий функционирования проекта, недооценка требований заказчика; недоработка документации.
Результат: неполнота реализации с точки зрения заказчика, недостатки в документации, возможны трудности в сопровождении из-за сложности кода и недостаточности комментариев.
Слайд 63. Ситуация вторая: управляет «требовательность»
Плюсы: внешние спецификации отслеживаются; выдерживаются сроки предоставления
![3. Ситуация вторая: управляет «требовательность» Плюсы: внешние спецификации отслеживаются; выдерживаются сроки предоставления](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-5.jpg)
результатов; подготовлена документация.
Минусы: Не учтены все варианты функционирования, исключения, особые ситуации; проектные решения, схемы баз данных - «лобовые», нерациональные.
Результат: «потемкинская деревня»: внешний лоск, но реальных удобств пользователя мало, надежность низкая, сопровождение затруднено; трудности в устранении замечаний пользователя в ходе эксплуатации проекта.
Слайд 74. Ситуация третья: управляет «контроль».
Плюсы:; выдерживаются сроки предоставления результатов; подготовлена документация.
Минусы:
![4. Ситуация третья: управляет «контроль». Плюсы:; выдерживаются сроки предоставления результатов; подготовлена документация.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-6.jpg)
плюсы зачастую фиктивны и усугубляются минусы предыдущего варианта; как правило, не все функционалы и сервисы ре6ализованы; документация оформлена вовремя, но неполна и неточна.
Результат: еще хуже, чем в предыдущем варианте , но!…
часто разработчику удается доказать, что формальные параметры проекта выполнены, повлияли сроки, недостаток финансирования – «доведем в ходе эксплуатации».
Слайд 85. Ситуация четвертая: управляет «компетентность- требовательность».
Плюсы: реализация на уровне; внешние спецификации
![5. Ситуация четвертая: управляет «компетентность- требовательность». Плюсы: реализация на уровне; внешние спецификации](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-7.jpg)
выдержаны; документация подготовлена.
Минусы: могут быть не соблюдены сроки предоставления результатов, например, вследствие несогласования действий разных групп разработчиков
Результаты: вполне приемлемые.
Слайд 96. Ситуация пятая: управляет «компетентность- контроль».
Плюсы: реализация на уровне; внешние спецификации
![6. Ситуация пятая: управляет «компетентность- контроль». Плюсы: реализация на уровне; внешние спецификации](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-8.jpg)
выдержаны; документация подготовлена.
Минусы: могут быть не соблюдены сроки предоставления результатов, например, вследствие несогласования действий разных групп разработчиков; внешние спецификации изменены в ходе работ.
Результаты: вполне приемлемые, но не без замечаний заказчика.
Слайд 107. Ситуация шестая: управляет «требовательность- контроль».
Плюсы: почти отсутствуют, хотя документация как
![7. Ситуация шестая: управляет «требовательность- контроль». Плюсы: почти отсутствуют, хотя документация как](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-9.jpg)
техническая, так и организационно-распорядительная может быть формально подготовлена.
Минусы: проект не содержит грамотных решений.
Результаты: заказчику сдается , практически, фиктивная система.
Слайд 11
8. Ситуация седьмая: нет ничего
Как ни странно, случается.
![8. Ситуация седьмая: нет ничего Как ни странно, случается.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-10.jpg)
Слайд 12 9. Ситуация восьмая: все есть!
Бывает и такое!
![9. Ситуация восьмая: все есть! Бывает и такое!](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-11.jpg)
Слайд 13 10. Что делать?
Регламентировать процесс управления разработкой с помощью методологии стандартов.
Стандарт
![10. Что делать? Регламентировать процесс управления разработкой с помощью методологии стандартов. Стандарт](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-12.jpg)
предприятия (СТП) на оформление текстов и программ.
1. Общие положения
2. Объекты, рассматриваемые в настоящем стандарте
3. Правила формирования имен.
3.1. Имена файлов, классов, объектов
3.2. Правила формирования имен переменных
3.3. Особые случаи (исключения
4. Правила форматирования исходного программного
текста
5. Требования к экранной форме
6. Требования к терминологии пользовательского
интерфейса
7. Оформление программы для передачи заказчику
.
Слайд 14 СТП «Технология проектирования».
1. Общие положения
2. Регламентация разработки проектных решений
2.1.
![СТП «Технология проектирования». 1. Общие положения 2. Регламентация разработки проектных решений 2.1.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-13.jpg)
Условия начала разработки
2.2. Общий состав работ по проектированию
2.3. Определение общей архитектуры системы (комплекса
2.4. Проектирование структуры базы данных
2.5. Формирование бизнес-процессов и алгоритмов
обработки данных
2.6. Проектирование интерфейса пользователя
2.7. Программирование и тестирование
2.8. Разработка документации
2.9. Организационно-распорядительная документация
3. Порядок передачи проекта или его части на
сопровождение (разработку, доработку) другому
сотруднику
4. Сопровождение разработанной системы (комплекса)
Приложения.
Текущие проектные решения; Журнал разработчика; Журнал тестирования; Журнал сопровождения разработки.
Слайд 15 СТП «Основные проектные решения».
назначение и цели создания (развития) системы;
![СТП «Основные проектные решения». назначение и цели создания (развития) системы; краткая характеристика](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-14.jpg)
краткая характеристика объектов автоматизации;
основные технические решения;
описание информационной базы;
описание интерфейса пользователя;
основные алгоритмы реализации;
обработка аварийных (исключительных) ситуаций.
Слайд 164. Применение ГОСТ (ОСТ, СТБ).
Управление эффективнее, если управляемый процесс регламентирован.
Разумное применение стандартов
![4. Применение ГОСТ (ОСТ, СТБ). Управление эффективнее, если управляемый процесс регламентирован. Разумное](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/450897/slide-15.jpg)
на этапы разработки может удачно сочетать обеспечение творческой свободы разработчиков с необходимостью регламентации достижений этой свободы.
В сочетании с преемственностью поколений управленцев это может обеспечить реализацию приведенной триады.