3. menu – меню. Реализовано в виде списка, причем каждый пункт может содержать подменю, которое тоже представляет собой список. Каждый элемент списка обязательно содержит текст (часто с горячей клавишей) и может содержать иконку 32*32, сочетание «горячих клавиш» для вызова элемента без вхождения в меню или символ 4. Сочетание icon+menu = Tool panel (Панель инструментов)

4. pointers – механизм индивидуальной настройки пользователя. Обозначается маленькой стрелкой в левом нижнем углу иконки. Пользователь может конфигурировать под себя любое количество указателей в любой папке и области.

Разработчик и архитектор в больших программах – разные люди.

Задача архитектора: представить предметную область с точки зрения пользователя (удобство использования интерфейса). Архитектор должен выяснить тезаурус пользователя и обеспечить лингвистическое обеспечение проекта.

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

19. Требования к программистам. Формирование команды программистов.

Требование к программистам и их оценка

1. Уровень образования

По учреждению выясняются возможности

Тестирование знаний

Резюме – представление опыта программистов, характеризующее его возможное применение.

На производительность влияют:

1. Наличие амбиций человека (собственная оценка своих качеств и себя в коллективе)
2. Уровень притязания. Самооценка может быть источником конфликтов в коллективе.
3. Коммуникабельность! при сдаче проекта.

Задача руководителя после подбора команды организовать работу так, чтобы по максимуму использовать профессиональные и персональные данные программистов.

20. Организация процесса работы команды программистов (персональная организация и коллективная работа).

Осуществляет руководитель проекта.

Опытный руководитель распараллеливает работы. Идет пересечение этапов.

По каждому этапу четко сформулирован результат. Если результата нет, то этап не завершен.

Документирование процесса работы. Все, что делается - оформляется.

Документация создается с начала реализации проекта. Оформляется в соответствии с ГОСТом (ISO) или с корпоративными стандартами документациями.

Удобно использовать маршрутный лист.

Достоинства подхода:

1. документация нужна не только тем, кто пишет программу, но и тем, кто работает рядом, т.е. вынужден использовать ваши результаты.

2. документация отражает текущее состояние работы над проектом

3. при окончании проекта требуется минимум усилий для оформления документации для передачи заказчику.

Организация персональной работы программиста

Менеджер планирует работу программисту, формулирует суть работы, сроки. Ежедневный самоотчет о проделанной работе позволяет менеджеру лучше планировать рабочее время программиста. Написание самоотчета занимает от 15 до 30 минут в день, но дисциплинирует программиста и дает возможность менеджеру перепланировать работу так, чтобы успеть.

Чем больше проект, тем большее значение принимает работа каждого программиста в отдельности и тем важнее любые инструменты, с помощью которых контролируется ход и выполнение работы.

Организация коллективной работы

Координация коллективной работы подразумевает информационное взаимодействие всех участников процесса, т.е. любой человек, участвующий в создании системы должен иметь возможность получать информацию о любых проектных решениях.

«Рабочая тетрадь». Все проектные решения документируются в рабочую тетрадь. Иногда размер всех рабочих тетрадей по проекту достигал толщины в 1 м.

Идея рабочей тетради поддерживается в виде выпуска очередной версии программного продукта, где документация и сам ПП отражают эволюцию его изменения.

Версия 0 является версией, готовой в бета-тестированию.

Согласование работ:

1. Распараллеливание работ

2. Сетевое планирование

Программные продукты, позволяющие осуществлять планирование работ и оптимизировать сроки:

1. MS Outlook
2. Time manager
3. MS Project – управление ресурсами, планирование с дискретностью от часа до месяца. Позволяет работать удаленным пользователям надо удаленным проектом.

21. Планирование работы команды программистов. Эффект второй системы.

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

1. Шифр, номер работы
2. Описание выполнения
3. Время окончания
4. Результат, если работа окончена.

Отслеживает эту информацию менеджер группы.

По оценкам 28-33% времени программист пишет программу. Остальное – совещания, согласования, поиск литературы, обучение, координация с программистами, пишущими совместные с его модулями – 60%.

Задача менеджера – минимизировать 60% так, чтобы увеличить время работы программиста над программой. Если менеджер хороший, то он сможет снизить 60% до 50%.

Критическая ситуация – проект не успевает по срокам:

В этом случае возможны следующие шаги:

1. увеличить число программистов на проект (зачастую только усугубляет положение);
2. на существующем количестве перераспределить работу, ввести дополнительное время;

Эффект второй системы

Часть фирм планируют разработку системы на «выброс», чтобы получить представление о трудностях, ошибках, проверить основные идеи, а после разрабатывать вторую систему.

22. Работа с заказчиком.

Специфическая функция взаимодействия с потенциальным или реальным потребителем ПП.

1. 1 Заказчик, 1 Разработчик
2. Заказчик объявляет тендер на разработку. Выигрывает фирма, которая либо уменьшает стоимость разработки, либо за эту же сумму предоставляет больше возможностей. Играет роль имидж компании (участие и завершение аналогичных разработок, участие в семинарах, совещаниях по теме, открытость компании).

Преимущества:

Заказчик в курсе всей работы

Тестирование параллельно с написанием

Лекция 2. Групповая разработка Программного обеспеченья (ПО).

Структурная формула всего механизма

Строение групп Асcура

Степень подвижности механизма

Кинематические пары

Обозначение на структурной схеме	Соединяемые звенья	Вид	Тип пары	Индекс пары
Характер соприкосновения	Степень подвижности

Число одноподвижных кинематических пар p 1 =7 , число двух подвижных кинематических пар р 2 =0.

а).Последняя группа Асcура

б).Предпоследняя группа Асcура

в).Начальный механизм

7.Класс всего механизма II , так как наивысший класс группы Ассура, входящей в данный механизм II.

• изучение инструментария коллективной разработки
• изучение принципов организации процесса разработки и управления коллективом разработчиков

Определения:

Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Основная идея систем контроля версий - запоминать все внесенные изменения с комментариями . Понятно кто когда что менял, зачем. Главное - можно все эти изменения откатить. Ну а кроме этого систему контроля версий можно обвешать дополнительными фишками и рюшечками.

Репозиторий, хранилище - место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. Существуют репозитории для хранения программ, написанных на одном языке (например, CPAN для Perl) или предназначенных для одной платформы. Многие современные операционные системы, такие как OpenSolaris, FreeBSD и большинство дистрибутивов Linux, имеют официальные репозитории, но также позволяют устанавливать пакеты из других мест. Большинство репозиториев бесплатны, однако некоторые компании предоставляют доступ к собственным репозиториям за платную подписку. Репозитории используются в системах управления версиями, в них хранятся все документы вместе с историей их изменения и другой служебной информацией. Русское сообщество Subversion рекомендует использовать вместо термина репозиторий термин хранилище, поскольку он полностью соответствует как прямому переводу слова «repository», так и его понятию. Существуют различные автоматизированные системы создания репозиториев. Один из типов репозиториев: хранилища на CD/DVD - установочные диски для пакетов того или иного ПО.

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

В корпоративной среде, система отслеживания ошибок может использоваться для получения отчётов, показывающих продуктивность программистов при исправлении ошибок. Однако, часто такой подход не даёт достаточно точных результатов, из-за того что разные ошибки имеют различную степень серьёзности и сложности. При этом серьёзность проблемы не имеет прямого отношения к сложности устранения ошибки.

Пример, Redmine BUGS - the Bug Genie Bugzilla eTraxis GNATS

Базовые принципы разработки ПО в VCS

Порядок использования системы управления версиями в каждом конкретном случае определяется техническими регламентами и правилами, принятыми в конкретной фирме или организации, разрабатывающей проект. Тем не менее, общие принципы правильного использования VCS немногочисленны и едины для любых разработок и систем управления версиями.

1. Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё незафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.
2. Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирование изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.
3. Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.
4. Версии проекта помечаются тэгами. Выделенная и помеченная тэгом версия более никогда не изменяется.

Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий.

Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает:-).
Транк (trunk) - основная ветка кода
Бранч (branch) - ответвления (для экспериментов, например)
Чекин (Check in (submit, commit)) - отправка кода в репозиторий
Чекаут (Check out) - получение изменения из репозитория.
Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом

Список литературы

Разработка программного обеспечения – это групповой процесс. Большинство программных продуктов рождается в результате коллективных усилий. Люди являются одной из главных составляющих, необходимых для производства программного продукта. При организации работы программистов важно учитывать не только их технические навыки, но и взаимодействие между ними.

Существует две основные модели организации коллектива при разработке ПО:

– Иерархическая модель. определяет начальников и подчиненных, т.е – это структура с вертикальной формой управления (контроля) элементами, входящими в неё. Фактически это пирамида, каждым уровнем которой управляет более высокий уровень. Можно выделить следующие недостатки иерархической модели:

§ нехватка информации на различных уровнях;

§ невозможность учесть все особенности проекта;

§ отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении – вверх по иерархии, к главному менеджеру;

§ трудность освоения новых технологий, необходимых при создании кроссплатформенных приложений;

§ сложность расстановки приоритетов.

– Модель проектной группы. В проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы - каждый за свой участок.

Можно выделить следующие недостатки модели группы:

§ разрозненная связь с внешними источниками информации;

§ несогласованное представление о разных сторонах проекта;

§ несогласованность личных планов членов группы;

§ отсутствие опыта, снижающее эффективность коллективной работы.

При разработке программного обеспечения выполняемые задачи распределяются по семи ролевым группам и шести ролям. Участники команды, выполняющие конкретную роль, должны рассматривать проект с точки зрения своей специализации и обладать необходимой квалификацией.

Рисунок 1 – Роли в модели проектной группы

Каждая ролевая группа выполняет свои задачи:

«Архитектура»

§ формулирует спецификацию решения и разрабатывает его архитектуру;

§ определяет структуру развертывания (внедрения) решения.

«Разработка»

§ определяет детали физического дизайна;

§ оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;

§ разрабатывает или контролирует разработку элементов;

§ подготавливает продукт к внедрению;

§ консультирует команду по технологическим вопросам.

«Тестирование»

§ обеспечивает обнаружение всех дефектов;

§ разрабатывает стратегию и планы тестирования;

§ осуществляет тестирование.

«Управление выпуском»

§ представляет интересы отделов поставки и обслуживания продукта;

§ организует снабжение проектной группы;

§ организует внедрение продукта;

§ вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;

§ организует сопровождение и инфраструктуру поставки.

«Удовлетворение потребителя»

§ представляет интересы потребителя в команде;

§ организует работу с требованиями пользователя;

§ определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;

§ определяет требования к системе помощи и её содержание;

§ разрабатывает учебные материалы и осуществляет обучение пользователей.

«Управление продуктом»

§ выступает в роли представителя заказчика;

§ организует работу с требованиями заказчика;

§ формирует ожидания заказчика;

§ формирует общее видение и рамки проекта;

§ определяет компромиссы между параметрами "возможности продукта / время / ресурсы";

§ организует маркетинг;

§ разрабатывает, поддерживает и исполняет план коммуникаций.

Влияние на успех группы такого важного фактора, как состав команды, выявили М. Белбин и его коллеги. Было проведено исследование нескольких сотен небольших групп в процессе их деятельности. Учёные определили, что поведение членов групп соответствует одной из девяти выделенных ими в ходе исследования ролей (Таблица 1).

Таблица 1 – Типология командных ролей М. Белбина

Виды командных ролей	Необходимые личностные качества и вклад в деятельность команды	Допустимые недостатки
Мыслитель (генератор идей)	Творческая направленность, богатое воображение, неординарность мышления. Стремление к новаторству. Источник оригинальных идей для команды.	Недостаточность опыта межличностного общения. Психологическая неустойчивость. Может долго задерживаться на рассмотрении "интересных идей".
Исполнитель	Претворяет идеи в практические действия. Превращает решения в легко выполнимые задания. Вносит упорядоченность в деятельность команды.	Недостаточная гибкость. Неприязнь к фантастическим идеям. Неприязнь к частым изменениям планов.
Доводчик	Усердие и добросовестность. Следит за тем, чтобы задания выполнялись полностью. Отслеживает своевременность выполнения заданий.	Чрезмерная обеспокоенность состоянием дел. Склонность к внутренним переживаниям. Нежелание перепоручать свои обязанности. Неприятие несерьезного отношения к его обязанностям со стороны других.
Оценщик (эксперт)	Исповедует беспристрастный критический анализ ситуации. Стратегический подход и проницательность в оценках. Точность суждений, стремление рассматривать все возможные варианты решения.	Недооценка факторов стимулирования и воодушевления. Недостаточность вдохновения и творческого воображения. Способность сбивать других, подавляя их инициативу.
Исследователь ресурсов	Владение искусством проведения переговоров, разнообразие контактов. Талант импровизатора, изучает благоприятные возможности. Энтузиазм, коммуникабельность.	Теряет интерес по мере угасания энтузиазма. Перескакивает от одной задачи к другой. Нуждается в повышенном внешнем давлении.
Формирователь	Постоянная ориентированность на решение поставленной задачи; стимулирует работу всей команды. Способствует реализации принятых решений; побуждает сотрудников работать интенсивнее. Энергичность, стремление к превосходству и работе с полной отдачей сил.	Легко переходит к состоянию раздражительности. Импульсивность и нетерпеливость. Нетерпимость к нечетким формулировкам и нерешительности в поведении. Результат - любой ценой.
Коллективист	Способствует гармонизации отношений в команде и устранению разногласий. Внимательно выслушивает собеседника; опирается на мнения других. Чуткость, отсутствие чрезмерной самоуверенности.	Нерешительность в кризисных ситуациях. Стремление избегать обострения ситуаций. Может воспрепятствовать совершению действий в решающий момент.
Председатель (координатор)	Четко формулирует цели; хорошо выполняет функции ведущего во время дискуссий. Способствует эффективному принятию решений. Имеет хорошие коммуникативные навыки; социальный лидер.	Может производить впечатление человека, склонного к манипуляциям. Склонность к переложению своих обязанностей на других. Может приписывать себе заслуги всей команды.
Специалист	Обладает редко встречающимися навыками и знаниями. Целеустремленность и способность концентрировать усилия. Инициативность и способность всецело отдаваться работе.	Полезен только в узкой профессиональной сфере. Зачастую слабые коммуникативные навыки. Иногда, образно выражаясь, "не видит леса за деревьями".

В равной степени важными для эффективной командной работы их можно считать лишь при условии, что они применяются в надлежащее время и наилучшим образом. Например, в тот период, когда команда только приступает к рассмотрению проблемы или к разработке проекта, обычно требуются инновационные идеи (т.е. нужен «мыслитель»). Затем возникает необходимость оценки того, как эти идеи могут быть претворены в практически выполнимые задачи (т.е. нужен «исполнитель»). Успех достигается при условии, что в команде есть хороший координатор («председатель»), задача которого - обеспечить наибольшую отдачу от членов команды в нужное время. Движущую силу и стимул команда обретает в лице энергичного «формирователя». Когда возникает необходимость в проведении сложных переговоров с другими группами, большое значение приобретают качества, которыми обладает «исследователь ресурсов». Чтобы сдерживать чрезмерные проявления энтузиазма, отвлекающие от главной цели, в составе команды должен быть «оценщик» (т.е. «эксперт»). Всевозможные трения и недоразумения между членами команды устраняются усилиями «коллективиста». Благодаря наличию «специалиста» команда имеет редко встречающиеся навыки и знания, в которых периодически возникает необходимость. Роль «доводчика» состоит в том, чтобы не упустить из виду даже мельчайшие детали реализации всех намеченных планов.

Однако для успешной разработки программного обеспечения недостаточно просто распределить среди участников проектной команды роли и обязанности. Необходимо, чтобы все участники команды понимали и соблюдали следующие базовые принципы коллективной работы:

– Единое понимание целей проекта. Данное условие является важнейшим фактором успеха как при разработке ПО, так и при любой совместной деятельности. На начальных этапах работы каждый участник команды имеет собственное мнение и представление о продукте. Необходимо обсудить частные мнения и по итогам обсуждения выработать концепцию проекта – единый документ, который содержит:

§ описание возможностей продукта (что продукт позволяет сделать);

§ конкретизацию продукта (описание функциональных возможностей данной версии);

§ описание путей реализации проекта.

– Равенство, свободный обмен информацией, общая ответственность и четкие ролевые функции. В группе разработчиков важна каждая роль. Только такой подход позволяет наладить свободный обмен информацией между проектными группами и отдельными разработчиками и сформировать общую ответственность за качество продукта проекта.

– Ориентация на продукт и понимание целей заказчика, нацеленность на результат.

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

§ обучение на опыте других проектов;

§ изучение методологии;

§ изучение технологий.

– Эффективное взаимодействие с внешними группами. Проектная группа должна эффективно взаимодействовать с внешними группами – с заказчиком, пользователями, другими разработчиками. За эффективность внешних взаимодействий отвечают менеджер проекта, менеджер продукта, специалист по внедрению и логистик. В их обязанности входят как внутренние, так и внешние контакты.

Можно выделить следующие этапы развития команды:

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

2. Второй этап – бурление (или неразбериха) – самый сложный и опасный период. Мотивация новизны уже исчезла, а сильные и глубокие стимулы у команды еще не появились. Неизбежные сложности или неудачи порождают конфликты, «поиск виновных». На этом этапе важно обеспечить открытую коммуникацию в команде – конфликты не следует прятать или разрубать. Споры необходимо разруливать – спокойно, терпеливо и тщательно.

3. Третий этап – становление. В команде растет доверие, люди начинают замечать в коллегах не только проблемные, но и сильные стороны. На смену битве амбиций приходит продуктивное сотрудничество. Четче становится разделение труда, исчезает дублирование функций. Лидер перестает находиться в состоянии постоянного аврала, работа по построению команды на этом этапе – уже не тушение пожара, а скрупулезный труд по отработке общих норм и правил.

4. Четвертый этап – отдача. Наконец-то можно получить дивиденды за потраченные усилия. Команда работает эффективно, высок командный дух, люди хорошо знают друг друга и умеют использовать сильные стороны коллег. Высок уровень доверия. Это лучший период для раскрытия индивидуальных талантов. Люди хотят и могут совершенствоваться, они более всего заинтересованы в профессиональном росте. Растет значение нематериальной мотивации сотрудников, а оценивать и поощрять материально лучше команду в целом. Если четвертый этап достигнут, значит, команда создавалась не зря.

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

– групповая работа над кодом, документами;

– учет проблем, ошибок, требований;

– документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;

– организация правильного тестирования.

Работа средств коллективной разработки основана на выполнении двух базовых функций:

– Ведение общей для всех разработчиков базы данных проекта, содержащей историю изменений в каждом файле проекта.

– Автоматизация следующих операций:

§ доступа к общей базе данных;

§ обработки конфликтующих версий файла;

§ именования различных версий файла;

§ ввода и сохранения комментариев к изменениям.

Формирование рабочих коллективов и выбор программного проекта вещи взаимосвязанные. В данном курсе даётся возможность студентам сначала «собрать команду», а потом выбрать проект. Группы, работающие над проектом должны состоять из 3-5 человек. Группы менее 3 человек, не позволят студентам получить навыки коллективной работы над проектом. Группы более 5 человек требуют более сложной координации и допустимы для уже сложившихся творческих коллективов.

При формировании групп следует учитывать психологическую совместимость, входящих в них студентов. Задача преподавателя помочь студентам получить навыки конструктивной работы в коллективе. При формировании и утверждении групп следует избегать как существующих, так и потенциальных конфликтов внутри одной группы.

В сильные сформированные группы преподаватель может по собственному усмотрению добавить студента, не нашедшего группу самостоятельно. Студенты, не сумевшие сформировать группы, разделяются на группы преподавателем, либо вводятся в уже существующие группы.

Сформированные группы утверждаются преподавателем. Если преподаватель считает, что с точки зрения освоения практических навыков, предусмотренных программой ТРПО, данная группа малоэффективна, то он вправе расформировать или переформировать такую группу. Использовать данное право следует только в исключительных случаях, предварительно проконсультировавшись с лектором.

Студенты на основе своих личных предпочтений и желаний организуют рабочие команды. Следует выбирать тех людей, с которыми приятно и интересно работать. После выбора темы проекта рекомендуется распределить роли между участниками, договориться о способах взаимодействия, а так же определить количество часов в неделю, выделяемых на работу над проектом каждым участником. Данный момент является очень важным, поскольку одной из распространенных причин провала проекта является невыполнение рабо­чих обязательств одним или несколькими членами группы.

Следует определить схему и частоту проведения собраний. Встреча коллектива, совместно работающего над проектом должна проходить не реже одного раза в неделю. Собрание является точкой интеграции полученных результатов проекта и определения дальнейших действий проекта. На собрании обсуждаются и вырабатываются различные решения, касающиеся проекта. Например, распределение задач, определение приоритетов, назначение ответственных, изменение плана и т.п.

1. Руководитель проекта назначает секретаря и оглашает заранее подготовленную повестку собрания и краткий отчет о текущем состоянии проекта. (~5 минут).

2. Участники собрания вносят замечания. В результате формируется окончательная повестка собрания. (~5 минут).

3. Собрание идет согласно выработанной повестке. Заслушиваются отчеты разработчиков о проделанной работе, включая отчеты об исправлении замечаний, и выполняется анализ текущей документации и других артефактов. Обсуждаются и определяются дальнейшие направления и задачи. (~35–70 минут).

4. Подведение итогов. Распределение задач, назначение ответственных и т.п. (~10 минут).

В случае недостаточности еженедельных собраний для командной работы разработчиков, команда может использовать дополнительное время. Например, это полезно на начальных этапах проекта в случае активной работы с заказчиком

Разработчики сочетают командную работу с индивидуальной. В процессе разработки каждому из разработчиков должны поручаться конкретные задачи для решения. Зоны ответственности, роли разработчиков и другие правила, регулирующие индивидуальную работу и ее сочетание с командной, фиксируются в плане проекта. Текущее распределение задач отражается в протоколах собраний и индивидуальных журналах разработчиков.

Разработка программного обеспечения, кроме достаточно сложного технического аспекта, имеет сложный организационный или даже психологический аспект.

Так известно, например, что потребности заказчика всегда достаточно сложно определить полностью в какие-то начальные моменты разработки и даже после обследования. Это влечет за собой большое количество незапланированных работ, что отрицательно сказывается на качестве продукта.

Вопрос в том, как построить модель отношений заказчика и разработчика с учетом интересов обеих сторон и без потери качества?

Каждая сторона состоит из независящих функционально ролей. Каждая роль может включать в себя несколько человек. Роли совместимы только внутри сторон.

Итак, сторона заказчика имеет следующие ключевые роли: менеджер продукта и бизнес-аналитик.

Менеджер продукта — это представитель разработчика у заказчика, он обязан представлять интересы заказчика у разработчика. Это главный источник информации как для заказчика, так и для разработчика, его цель — полное удовлетворение потребностей заказчика в рамках выделенных ресурсов.

Бизнес-аналитик — это представитель заказчика, ответственный за создание системы. Он досконально знает бизнес-процесс своего предприятия и обязан предоставлять полную и достоверную информацию.

Сторона разработчика : менеджер программы, аналитик, программист, тестировщик.

Менеджер программы — это главный технический специалист проекта, он является хранителем спецификации и заинтересован в ее минимальных изменениях во время разработки.

Аналитик формализует информацию, получаемую со стороны заказчика в виде моделей, он обязан уметь выявлять закономерности и делать правильные обобщения, анализировать и проектировать комплекс взаимосвязанных программ для реализации функций предметной области.

Программист — непосредственно кодировщик.

Тестировщик — специалист по тестированию, он отвечает за соответствие системы ее спецификации.

Сторона качества : бизнес-аналитик и технолог.

Бизнес-аналитик — специалист по предметной области вообще, независимо от конкретного предприятия.

Технолог — специалист по технологии, контролирующий правильность ее использования.

В реальности каждая сторона работает в противовес двум остальным и необходима для сохранения общего баланса.

Каждая роль может включать в себя несколько человек. Нужно учитывать, что при работе над большим проектом возникает проблема взаимодействия исполнителей между собой. Взаимодействие исполнителей друг с другом требует времени, что в определенной степени снижает производительность труда . Причем взаимное непонимание приводит к дополнительным затратам на последующих стадиях разработки, например, непонимание среди программистов приводит к дополнительным затратам на тестирование.

Проблема взаимодействия возникает уже при работе группы из четырех и более человек. Для управления их работой необходим руководитель.

Решением этой проблемы может стать организация бригад , например бригады главного программиста ,если рассматривать на примере программистов.

Бригададолжна включать от 3 до 7 человек. Число 10 является верхней границей численности бригады. Это обусловлено требованием максимальной управляемости коллектива.

В бригаде в зависимости от квалификации выделяют следующих специалистов.

Руководитель бригады (например, главный программист) — это превосходно подготовленный, творчески мыслящий, наделенный организацион­ными способностями специалист. Он выполняет работу верхнего уровня, в том числе распределение работы внутри бригады.

Заместитель руководителя бригады (например, старший программист) поддерживает тесную связь с руководителем бригады и дорабатывает более мелкие вопросы. При обсуждении проекта заместитель должен выступать в роли оппонента руководителю бригады.

Непосредственно исполнители (например, младшие программисты) — два или три "менее опытных" (но не "менее способных") специалиста. Они выполняют работу нижнего уровня, определенную руководителем бригады.

В большом проекте в состав каждой или нескольких бригад могут входить следующие специалисты.

Администратор отвечает за распределение времени, подбор кадров, размещение исполнителей, финансирование, поддержку связи с высшим руководством.

Библиотекарь ведет системную библиотеку, например, библиотеку модулей, используемых в оперативном режиме. Все изменения в программные модули вносит только библиотекарь. Он также ведет системную документацию — системный журнал.

Технический исполнитель (документатор) занимается написанием документации по проекту, что освобождает более квалифицированных специалистов от этой рутинной работы.

Секретарь выполняет обычную работу секретаря.

Опыт разработки крупных ПО показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы . Реализация подсистем должна выполняться отдельными группами специалистов. В случае использования CASE-средств это означает деление функциональной модели системы (ди­аграммы потоков данных для структурного подхода).

Поэтому после первоначального определения функций, которые должно выполнять разрабатываемое ПО, проект распределяется между различными командами раз­работчиков (рис. 12.1).

Рис. 12.1. Группы специалистов, занятых в разработке ПО

(n — количество функций ПО)

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

Результатом стадии должны быть:

Общая информационная модель системы;

Глобальные функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

Точно определенные интерфейсы между автономно разрабатываемыми подсистемами (те данные, которые передаются между ними);

Построенные прототипы экранных форм, отчетов, диалогов (должен быть определен стандарт интерфейса пользователя).

После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом.

Считается, что у нас в стране прекрасные программисты, и это действительно так!

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

Разобраться в причинах данного явления весьма важно для дальнейшего развития отечественной индустрии ПО.

Отчасти проблема связана с тем, что во многих ведущих зарубежных странах навык коллективного творчества развивается буквально со школы и продолжает формироваться в колледже и университете. У нас, к сожалению, такая традиция практически отсутствует. Каждый программист по отдельности, что называется, может подковать блоху, а вот наладить коллективный процесс в обычной кузнице не получается. При этом, надо сказать, что разрыв в этой области по сравнению с западными компаниями, к сожалению, не уменьшается, а увеличивается. В советские времена существовало множество крупных проектов, которые требовали создания технологий коллективной разработки продукта, а сейчас, в условиях отсутствия финансирования на крупные проекты, эти технологии утрачиваются.

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

Фирма «1С»

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

Экономическое ПО

На вопросы об организации процесса создания программных продуктов делового назначения фирмы «1С» и прежде всего системы программ «1С:Предприятие» ответил Алексей Харитонов , руководитель отдела продвижения экономических программ фирмы «1С».

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

Стыковка модулей сильно различается в системной и прикладной части. В системной части используются специализированные технологии разработки больших проектов (частично стандартные, частично выработанные собственно в «1С»). В прикладной части отдельные проекты являются, с одной стороны, независимыми прикладными решениями, а с другой - частью единой методологической системы. Они и работать могут как вместе, так и по отдельности.

Коллективная работа сама по себе является весьма важным организующим фактором. Есть и большое количество формальных инструкций, расписывающих порядок ведения проекта и взаимодействия разработчиков, но многое зависит от готовности самих специалистов помочь друг другу, чтобы наладить совместную работу.

По принятой у нас технологии разработки очень большая роль отводится руководителям проектов. Конечно, руководитель проекта планирует и координирует работы, следит за соблюдением технических требований к проекту и сроков его выполнения, собирает готовый проект. Но главное - каждый руководитель проекта в «1С» фактически является руководителем направления, его идеологом. Он творчески развивает свое направление, руководствуясь при этом не только анализом текущих потребностей рынка, но, что очень важно, - своим видением перспективы развития, вносит в разработки те новшества, потребность в которых будет осознана рынком только в будущем.

КП: Расскажите поподробнее, как организовано тестирование? Какое ПО для этого используется? Кто занимается тестированием?

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

Мы сами являемся пользователями собственных продуктов, и учет у нас поставлен так, что наши бухгалтеры, учетчики, менеджеры, являются альфа-тестерами наших новинок.

Очень важную роль в жизни фирмы играет отдел технической поддержки, один из самых многочисленных. Они отвечают на вопросы пользователей и партнеров, они же занимаются тестированием. Это очень хорошее решение по двум причинам: во-первых, они часто сталкиваются с ошибками в реальной «жизни» продукта, а во-вторых, это позволяет им хорошо изучить, «пощупать» продукт и таким образом к началу консультирования пользователей накопить немалый опыт обращения с ним.

Затем наступает этап бета-тестирования. К нему мы привлекаем в первую очередь наиболее продвинутых партнеров, но и «предметники», специалисты по учету, тоже занимаются тестированием.

Условия тестирования разные. Если тестируются конфигурации, то допускается установка системы у конечных пользователей. Пользователей предупреждают, что это бета-версия и что обычно у них эксплуатируется предыдущая, рабочая версия и параллельно проверяется и осваивается новая. Так, чтобы кто-то один мог протестировать все «1С:Предприятие» сразу, не бывает - обычно в бета-тестировании только одной новой конфигурации, например «Производство+Услуги+Бухгалтерия», принимает участие около 150 партнерских организаций. Бета-версии мы, как правило, продаем им по обычной цене, но с обязательным условием прислать потом отчет. Если партнер присылает нормальный отчет, то бета-версия ему потом заменяется на обычную. Бета-тестирование длится от полутора до трех месяцев, поступающие отчеты сводятся и обобщаются, затем выпускается «боевой» релиз, который тиражируется и поступает в продажу.

КП: Существуют ли какие-либо нормативные документы, предписывающие, как нужно писать программы внутри коллектива?

А.Х.: Такие документы, конечно, есть - на разработку как системной части, так и прикладных решений (конфигураций). Есть также внутренние инструкции и нормативы на контроль исправления ошибок и другие работы. Эти документы совершенствуются, со временем их становится все больше, на их основе мы создаем, например, открытые нормативы по сертификации тиражных партнерских разработок на получение логотипа «Совместимо! Система программ «1С:Предприятие».

КП: Если можно, расскажите, как документируется ПО.

А.Х.: Подробное и всестороннее документирование своих программ мы считаем исключительно важной задачей. Ведь современные системы автоматизации учета - это гибкие и в то же время функционально очень насыщенные продукты. Эффективно их использовать, корректно настраивать, вести учет с высокой степенью автоматизации без качественной документации нельзя. Так, например, официальные пользователи «1С:Бухгалтерия 7.7» получают в комплекте поставки семь томов документации общим объемом более 3000 страниц.

В написании документации участвуют и собственно разработчики, и специальные сотрудники, приглашаются сторонние специалисты, например аудиторы.

Выпускается и широкий спектр дополнительной методической литературы, посвященной ведению различных разделов учета с использованием программ «1С». Такие книги пишут профессиональные экономисты и специалисты по бухучету, например заведующий кафедрой Финансовой академии при Правительстве РФ профессор Д.В.Чистов или известный аудитор С.А.Харитонов.

А.Х.: Основное средство разработки системной части - MS Visual C++. Все прикладные решения пишутся собственно на технологической платформе «1С:Предприятие», возможности которой позволяют эффективно создавать и модифицировать прикладные решения.

Использование в «1С:Предприятие» набора типовых объектов предметной области позволяет избавить проектировщика от целого этапа разработки, а также от комплекса проблем, встающих при проектировании структур таблиц базы данных.

Объекты «1С:Предприятие» существенно упрощают не только проектирование и поддержание структуры базы данных. Второй их важной особенностью является то, что они реализуют существенную часть бизнес-логики задачи автоматизации. Три функциональных компонента «1С:Предприятие» поддерживают три основных механизма учета: оперативный учет, бухгалтерский учет и сложные периодические расчеты. Настройка этих механизмов выполняется визуально и обеспечивает не только все необходимые структуры данных, но и расчетные и аналитические операции.

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

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

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

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

Другим полезным механизмом является ведение журнала работы пользователей с фиксацией всех существенных действий пользователя и возможностью полного или выборочного просмотра журнала. При этом разработчик конфигурации может вносить в журнал дополнительные события, не протоколируемые системой по умолчанию. Используя журнал регистрации, разработчик имеет возможность получить не только список ошибок, возникавших в системе за то время, когда пользователи работали «без присмотра», но и проследить последовательность действий, приведших к возникновению этих ошибок.

Такие возможности системы «1С:Предприятие 7.7» позволили реализовать технологию непрерывного индустриального сопровождения эксплуатируемых учетных систем, которую мы считаем очень перспективной. Сейчас центральным звеном поддержки всех категорий пользователей и специалистов по внедрению является ежемесячно выпускаемый компакт-диск информационно-технологического сопровождения (ИТС). Это подписное издание, на котором содержатся обновления текущих версий программ, дополнения к типовым конфигурациям, новые формы отчетности, методические материалы и рекомендации по использованию программных продуктов, комментарии и правовая информация по учету, налогообложению и многое другое. В результате пользователю, работающему с системой, для внесения в нее очередных обновлений, например отражения изменений в правилах расчета налогов, достаточно установить новый релиз типовой конфигурации с диска ИТС.

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

Поэтому фирма «1С» принимает серьезные меры по технологической и методической поддержке партнеров-разработчиков, разработке технологий и стандартов интеграции «1С:Предприятия» с другими системами. Кроме упомянутой выше методики сертификации партнерских разработок на совместимость с «1С:Предприятие», выпущены методики интеграции с торговым оборудованием, совместно с ведущими разработчиками банковского ПО разработан открытый стандарт обмена данными с системами типа «клиент банка», сейчас совместно с Microsoft ведутся работы над стандартами по электронному обмену торговой информацией в формате XML..

(Продолжение следует)

КомпьютерПресс 10"2000