1 - МФК Кумсков курс Процессы Разработки - Лекция 1 - 25-09-2025

Межфакультетский курс МГУ - МФК МГУ - осень 2025 - полугодовой «Процессы разработки программного обеспечения, бизнес-анализ и визуальные модели» Кумсков Михаил Иванович, профессор кафедры вычислительной математики мехмата МГУ Аудитория 428, 2-й учебный корпус МГУ Среда 17:00–18:30 Лекция 1 - 24.10.2025 Цель курса – формирование базовых знаний по процессам разработки программного обеспечения, включая понимание различных подходов к управлению. В рамках курса проводится сравнение классического задачного подхода и процессного подхода, предложенного Эдвардом Демингом. Показано, что на процессном подходе основаны современные методы, такие как Agile и Scrum. Задачи курса: ввести слушателей в круг современных подходов к организации работ при создании ПО; показать важность концептуальной целостности проекта на основе бизнес-анализа; описать развитие методов визуального моделирования (UML, BPMN); рассмотреть лучшие практики и актуальные паттерны использования CASE-систем визуального моделирования. Основной результат обучения – владение системным подходом при выявлении бизнес и системных требований к информационной системе и практиками построения визуальных моделей. Коммуникации как ключевой фактор успеха проекта Даже при корректном планировании и наличии технической экспертизы проект может оказаться неуспешным: перерасход бюджета, срыв сроков и недовольство заказчика при формальном выполнении требований. Главная причина — нарушение проектных коммуникаций. Различают внешние коммуникации (с заказчиком и пользователями) и внутренние (внутри команды). Непонимание требований или ожиданий заказчика, а также информационные разрывы между членами команды ведут к ошибкам и росту рисков. Лучшие практики организации работы в проекте • Итерационная (инкрементная) разработка: проект разбивается на ряд мини‑проектов (итераций), каждая завершается работающим прототипом и демонстрацией заказчику. • Управление требованиями: выявление, классификация (функциональные/нефункциональные), документирование, приоритезация; регламент работы с изменениями (change requests). • Компонентная архитектура: проектирование модулей с опубликованными интерфейсами; стабилизация интерфейсов при наращивании функциональности. • Визуальное моделирование: использование UML (диаграммы прецедентов/use case, классов, состояний, активностей и др.); применение стереотипов для адаптации под предметную область. • Постоянная проверка качества: quality inspection (качество продукта) и quality assurance (качество процесса). Необходимость регрессионного тестирования и его автоматизации. • Управление изменениями и конфигурацией: версионный контроль исходных артефактов; фиксирование состава сборки (конфигурации) для воспроизводимости. Иллюстративные сюжеты и аксиомы • Аксиома Фредерика Брукса: добавление людей в отстающий ИТ‑проект приводит к ещё большему отставанию («Мифический человеко‑месяц»). Вывод — критична концептуальная целостность и продуманная архитектура. • Исторические примеры: разработка IBM/360 и попытка воспроизведения ЕС ЭВМ в СССР; роль архитектурных решений и организационных практик. • Метафора Вавилонской башни: отсутствие ограничений по ресурсам и времени не гарантирует успех — нарушенные коммуникации рушат проект. Итерации, прецеденты (Use Case) и пользовательские истории Итерация признаётся завершённой только при наличии нового работающего прототипа. Демонстрация прототипа заказчику — обязательна для получения обратной связи и планирования следующих изменений. Use Case — услуга системы для внешнего участника (пользователь/другая система) с описанием основного и альтернативных потоков. User Story — конкретный экземпляр прохождения по сценарию (включая альтернативные ветви). Use Case — естественная единица разбиения функциональности на итерации; во второй и последующих итерациях реализуются новые прецеденты и принятые change requests. RUP, Agile, риски и процессный менеджмент RUP (Rational Unified Process) рассматривается как структурированная процессная основа, в которую встроены итерации и роли; Agile заимствует многие практики и переносит планирование на уровень команды. Важно понимать различие управленческих подходов и учитывать нагрузку на менеджера проекта при итерационной модели. Риск — событие с вероятностью наступления и величиной ущерба, а также синоним неопределенности (в оценках сроков, объема и стоимости работ). Цель итерационной разработки — раннее выявление и минимизация архитектурных и коммуникационных рисков. DevOps объединяет разработку и эксплуатацию общей метрикой результата; при сбоях в эксплуатации ответственность разделяется и проблемы устраняются совместно.