Архитектуры и модели программ и знаний

Лекция 12

Организация процесса разработки программ

Сафонов Владимир Олегович

Профессор кафедры информатики Заведующий лабораторией Java-технологии

(http://polyhimnie.math.spbu.ru/jtl)

Санкт-Петербургский государственный университет

Email: vosafonov@gmail.com

WWW: http://www.vladimirsafonov.org

Процесс разработки программного

продукта (Software Process) 1/2

Бригада главного программиста – F.P.

Brooks (IBM, 1970-е гг.): хирург, второй пилот, администратор, языковед, тестер (контролер), инструментальщик, архивариус, редактор, секретарь администратора, секретарь редактора – всего 10 ролей (или людей, если такие есть в распоряжении)

F. Brooks: главный программист должен

писать основную часть документации сам (это реально только для небольших проектов)

Capability Maturity Model (CMM) – CMU SEI;

Motorola (уровень 5): 5 уровней организованности процесса разработки – initial, repeated, documented, supported by tools, optimizing

Процесс разработки программного

продукта (Software Process) 2/2

Extreme Programming (XP) – парное кодирование,

разработка тестов до разработки новой функциональности, refactoring, коллективное владение кодом

Подход Microsoft: (Software Project Survival Guide):

“tiger teams”

Agile development (например, XP) – выдача

результата по частям (1-2 недели); повторение водопадного цикла для каждого этапа

Scrum (“схватка” в регби) – процесс разработки

продукта короткими итерациями (по 1-2 недели), с подробным анализом каждого этапа и планированием следующего. Цель: быстрая реализация конкретной функциональности на очередных этапахПсихологические и нравственные проблемы

процесса разработки: излишний оптимизм, (не)совместимость разработчиков и др.

F.P. Brooks: Основные организационные проблемы при разработке программного продукта

Чем больше людей участвует в проекте, тем сложнее взаимосвязи: N людей -> N*(N-1)/2 связей

Программисты - оптимисты: Обычно начальная оценка сроков выполнения проекта оказывается в 2-5 раз меньше, чем его фактическая длительность => срывы графика, недовольство заказчика и т.д.Индивидуальный стиль и привычки весьма разнообразны. Некоторые люди вообще не могут работать в коллективе и в результате только мешают разработке

Software Process: Бригада

главного программиста (F.P. Brooks) 1/2

Команда из 10 людей; только 5 из них являются программистамиГлавный программист: Менеджер и технический лидер

проекта. 10+ лет профессионального опыта. Разрабатывает крупную часть проекта и содержательную часть документации самВторой пилот: Помощник (заместитель) главного

программиста. 5+ лет профессионального опыта. Может заменять шефа по техническим вопросамЯзыковед: отвечает за язык(и), используемый (-ые) в

проектеИнструментальщик: отвечает за инструменты, используемые в проекте

Контролер: отвечает за тесты и инструменты

тестирования проекта

Software Process: Бригада

главного программиста (F.P. Brooks) 2/2

Администратор – отвечает за бюджет, организацию,

ресурсы проекта

Секретарь администратораРедактор (ныне – технический писатель) – отвечает за всю пользовательскую документацию

Секретарь редактора

Архивариус – отвечает за всю рабочую документацию и архив проектаЕсли необходим большой коллектив, он строится как

иерархия таких бригад

Если людей не хватает, кому-то приходится совмещать несколько ролей

В целом, схема бригады главного программиста

остается вполне применимой сейчас

Организация компании- разработчика программ

Президент

Вице-президенты: Chief Technical Officer (CTO), Chief Engineering Officer (CEO), Human Resources (людские ресурсы)Группы разработчиков: менеджеры проектов, разработчики, технические писатели, релиз-инженеры

Группы QA (SQE): менеджеры, QA-инженеры (с отдельным бюджетом)

Группа безопасности – согласно принципам TWC, должна быть организована в каждой фирме. Цели: обучение инженеров и менеджеров основам безопасности; управление соблюдением дисциплины TWC

Группа маркетинга

Группы продаж (в каждом регионе) – самые большие подразделения

Marketing Requirements Document (MRD) – документ, описывающий рыночные требования к продукту. Разрабатывается на самой ранней стадии создания продукта, согласуется между менеджерами проекта, группами QA, группой security, группой маркетинга

Email как инструмент организации процесса разработки программ

Email – рабочий инструмент; все проектные

решения должны обсуждаться по emailTo: конкретному инженеру; Cc: менеджеру

проекта и технической группе

Subject: должен быть конкретен

Дружеское напоминание (до 10-15 раз);

рекомендуется быть терпеливыми

Email используется для: технических обсуждений;

нотификации о событиях; нотификации об

ошибках; нотификации об изменениях в кодем продукта (автоматически); рассылки рабочей документации; поставки изменений или измененных версий продукта при удаленной работе (outsourcing)

Вежливость: Dear John, <содержание>

Thanks, Ivan

Никакой грубости или спама

Каждый email должен быть конкретен и к месту