Ускорение разработки программного обеспечения. Методология RAD
В связи с развитием CASE-технологий в рамках спиральной модели жизненного цикла ПО в последнее время широкое распространение получила методология быстрой разработки приложений RAD (Rapid Application Development). Процесс разработки при этом содержит три элемента : небольшую команду программистов...(Технология разработки программного обеспечения)
Пакеты прикладных программ
Классификация пакетов прикладных программ (ППП) приведена на рис. 1.8. Проблемно-ориентированные ППП. Для некоторых предметных областей возможна типизация функций управления, структуры данных и алгоритмов обработки. Это вызвало разработку значительного количества ППП одинакового функционального назначения:...(Технология разработки программного обеспечения)
Пакет прикладных программ Microsoft Office
Прикладные программы часто объединяются в пакеты по роду деятельности пользователя. Наиболее популярным пакетом, предназначенным для решения задач автоматизации офиса, является Microsoft Office. Он представляет собой семейство прикладных программных продуктов, которое объединяет различные приложения...(Информатика)
Система контроля версий Subversion
Subversion - свободно распространяемая система управления версиями с открытым кодом. Subversion разработана специально для замены CVS, самой распространенной открытой системы управления версиями. Она обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и лишена ряда...(Технология разработки программного обеспечения)
ОСНОВЫ РАБОТЫ В СРЕДЕ РАЗРАБОТКИ STUDIO 2010 ИНТЕГРИРОВАННОЙ MICROSOFT VISUAL
В настоящее время для разработки программного обеспечения используются интегрированные среды разработчика - ИСР (англ. IDE - Integrated development environment). Интегрированная среда разработчика позволяет повысить производительность и эффективность работы программиста. Одной из интегрированных сред...(Программирование на языке высокого уровня. Программирование на языке С++)
Для достижения максимальной эффективности взаимодействия с вашим системным интегратором, будь то какая-либо третья компания-интегратор или команда специалистов в вашей организации, вы должны в первую очередь тщательно подготовиться, а затем часто – но не слишком часто – обмениваться информацией.
Подготовка начинается с четкого определения целей, однако это не так просто, как кажется на первый взгляд. Роджер Ричардсон (Roger Richardson), президент компании Delta Sigma Corp., которая занимается разработкой производственных систем для аэрокосмической отрасли, отмечает, что "владельцы бизнеса знают свои производственные процессы гораздо лучше нас. Они знают, что сложно и что легко, а также им известны все "подводные камни". То, что они не знают – это как автоматизировать процесс".
"К сожалению, за последние 30 лет во внутренней среде компаний, наших клиентов, произошли изменения", говорит Рэнди Дженнингс (Randy Jennings), вице-президент по развитию бизнеса системного интегратора Transbotics Corp, который специализируется на системах производства, складирования и дистрибуции. "Оказывается, целый слой менеджмента и технических специалистов в американской промышленности сейчас отсутствует. В результате у клиентов есть потребности и желания, но у них нет персонала, необходимого для четкой постановки задачи".
Планирование проекта непременно развивается сверху вниз. Это означает, что всё начинается с определения полной архитектуры – общей картины – затем начинают уточняться детали. Реализация, однако, развивается снизу вверх – вы сначала пишите код модулей и покупаете или создаёте аппаратную часть, а лишь затем интегрируете их в единую систему. Если детали вашего проекта не были определены до начала реализации, то вам придётся переделывать практически всё, тратя в несколько раз больше усилий, чем при наличии четкого представления. Если быть более точным, то в несколько раз больше усилий будет тратить ваш системный интегратор!
Часто обменивайтесь информацией – но не слишком часто
Боб Гамбургер (Bob Hamburger), менеджер по развитию бизнеса системного интегратора Bloomy Controls (системы сбора и управления данными), говорит, что, по их опыту, большинство вещей, которые крадут время – это элементы пользовательского интерфейса в программном обеспечении. "Один из вопросов, который наши опытные специалисты сразу спрашивают – это „Есть ли у вас какие-либо пожелания к виду и работе пользовательского интерфейса?”"
Гамбургер подчёркивает, что в проекте начинаются проблемы, когда специалист работает совместно с заказчиком, и заказчик говорит что-либо подобное следующему: "Выглядит неплохо, но давайте покрасим это в зелёный цвет, а не в синий". "Это подобно смерти от тысячи ран", сравнивает он. "Каждая мелкая вещь, о которой они просят, делается быстро, почти незаметно, но под конец вы тратите больше времени на добавления и изменения, а не на то, что было указано в контракте".
Вот где необходимо часто – но не слишком часто – общаться с заказчиком. Как заказчик, вы должны взаимодействовать достаточно часто, чтобы системный интегратор всегда имел всю необходимую ему информацию. Но с другой стороны, их нужно оставить в покое, чтобы они делали свою работу.
Основной фокус, по утверждению Гамбургера, заключается в частом, но не слишком частом обзоре проекта, а также в нахождении в самом начале проекта ответов на открытые вопросы по стилю, внешнему виду и функциональности интерфейсов – "вот вещи к которым заказчик, в конце концов, будет придираться".
Частота и выбор времени для обзоров проекта зависят от сложности и масштаба проекта. Как правило, достаточно еженедельных или ежемесячных отчётов о ходе работ на основе функциональных блоков (в заранее оговоренном виде) и двусторонних встреч во время окончания этапов проекта (также заранее определённых). Обзоры проекта вероятно должны проводиться чаще на начальной фазе и фазе проектирования и реже при фазах разработки и первичного тестирования системы. Конечно, все стороны должны иметь возможность связаться в тот же момент, когда возникнет какой-нибудь существенный вопрос. Контактов по не особо важным вопросам стоит избегать. Цвет фона окна интерфейса, к примеру, не стоит прерывания процесса разработки.
Источник: Transbotics
Автоматизировать или не автоматизировать
Автоматизация – это не панацея. Некоторые задачи просто ждут – не дождутся, когда их автоматизируют, но иные лучше продолжать делать вручную. Иногда интеграторы ищут однообразные, грязные или опасные задачи. Однако такие критерии в заводской среде не всегда работают. Дженнингс предпочитает смотреть на повторяемость задачи: "Нужно уметь распознавать повторяющиеся движения. Действия человека – это – лучший показатель возможности автоматизации процесса. Если вы видите человека, делающего какие-либо однообразные движения, то, скорее всего, эту функцию можно автоматизировать".
Очень сложные задачи, требующие высокой гибкости и принятия решений, не очень хорошо автоматизируются. "Также необходимо определить области, где нет нужды в постоянном принятии решений", подчёркивает Дженнингс. "Если задача трудно выполнять вручную, то решение по её автоматизации не будет очень хорошим".
Гари Кэш (Gary Cash), вице-президент по продукции и маркетингу поставщика распределительных систем FKI Logistex, утверждает, что при автоматизации процессов возрастает их точность, однако это не является причиной, по которой компании запускают подобные проекты. "Когда компания мала, все операции на складе производятся вручную. Автоматизация начинается тогда, когда становится понятно, что нельзя нанять больше людей и впихнуть их в одно здание, иначе они начнут сидеть друг у друга на головах. То есть когда не хватает производительности, начитается автоматизация. Некоторые функции автоматизируются раньше других. Перевозки, к примеру, как правило, идут первыми в этом списке".
Выполните сначала домашнее задание
Перед тем, как даже подумать о создании команды с системным интегратором, выполните сначала домашнее задание по проекту.
"Составьте четкое представление о своих потребностях", говорит Дженнингс. "Вам не нужно находить решения, но вам нужно понять свои потребности – не желания, а именно потребности".
Как только потребности определены, интегратор сможет помочь вам наилучшим способом. Документируйте вещи, которые вам в будущем пригодятся.
Системный интегратор должен понимать, откуда берётся исходный материал, какая у вас производимая продукция, какая ожидаемая максимальная норма выработки, насколько широк список производственных инструментов, каков цикл прохождения заказа до заказчика и жизненный цикл заказа в целом. Естественно, одна из вещей, которую нужно знать – это как продукция перемещается от одного процесса к другому. "Мы стараемся оптимизировать перемещения, чтобы она подавалась вовремя, для уменьшения дополнительных приспособлений", говорит Дженнингс. "Поэтому, один из самых серьёзных вопросов – это как выглядит помещение, и что вы в нём предусмотрели".
На первой встрече с заказчиком Гамбургер из Bloomy первым делом пытается создать четкое описание проблемы. Что клиент пытается достичь? Что они хотят автоматизировать? Что они пытаются измерить? Их этого основополагающего описания задачи он пробует определить различные аспекты системы. Какие типы датчиков будут использованы? Какие нужны типы силовых приводов? Сколько каналов для каждого типа физического параметра потребуются?
"Поскольку то, что мы делаем, по существу является сбором и управлением данных", говорит он, "то отправной точкой является определение списка каналов. Сколько потребуется аналоговых входов и выходов, и как они будут использоваться при тестировании устройства или при автоматизации процесса?"
"Мы записываем наше понимание проблемы и по крайней мере концептуальное описание решения, в том числе описание рекомендуемой нами аппаратной части, а также то, как система может быть спроектирована", добавляет Гамбургер.
В результате получается черновой вариант документа с оценкой людских ресурсов и примерным планом проекта. Обычно на данной стадии происходит несколько итераций перед тем, как интегратор и заказчик вырабатывают конечное коммерческое предложение и описание задачи. "Мы стараемся ограничить время предварительной работы инженеров, привлекая их только для уменьшения рисков проекта до приемлемого уровня, когда мы твёрдо уверены в том, что предлагаем", говорит Гамбургер. "Если задача достаточно сложная, мы, скорее всего, предложим многоступенчатый подход к проекту, первая фаза которого будет заключаться в определении требований проекта".
Гари Кэш из FKI говорит, что "мы должны понять ваш бизнес для того, чтобы помочь вам. Поэтому вам надо рассказать нам, как он работает, и мы придумаем, как заставить здание работать, как спроектировать его, как всё реализовать, и заставить всё работать как надо".
Также важны и будущие цели. Вы ведь не хотите оказаться в ситуации, в которой к тому времени, как ваш интегратор через год закончит проект, ваш бизнес уже перерастёт существующее помещение. Спрогнозируйте, каков будет оборот в 2010 году, и будет ли смысл к тому времени планировать расширение.
Ещё один серьёзный вопрос при организации сети заключается в том, будет ли разрабатываемое производственное оборудование связанно с корпоративной ИТ сетью или оно будет связано в отдельную сеть. "Существует разделительная линия между сетью в классическом понимании, которое используют ребята из отдела ИТ", говорит Гамбургер, "и сетью внутри производственного помещения".
Источник: Kuka Robot Group
Если разрабатываемая вами система связана с корпоративной сетью, то интегратор будет должен решить вопросы по ИТ-политикам безопасности, правам доступа, защиты от вирусов и любой в другой области, где требования могут отличаться. Большинство промышленных компьютеров находятся за файрволами, где они не могут быть видимы для внешнего мира. Если же вам надо запустить веб-сервер на каком-нибудь из них, потребуется более гибкая настройка параметров доступа.
"Вероятно 75% веб-интерфейсов, которые мы сделали", отмечает Гамбургер, "находятся в локальных сетях. Они доступны только с компьютеров, находящихся внутри защищенной сети. Остальные 25% потребовали от нас кооперации с ИТ специалистами клиента для того, чтобы они открыли доступ в своём файрволе или поставили выделенный сервер у себя в сети. Это, кстати, довольно просто – установить аппаратный файрвол с недорогим роутером для защиты веб-сервера от атак злоумышленников".
Современные системы обработки упаковок могут автоматически сливать потоки с разных конвейеров, которые даже могут двигаться с разными скоростями, но только если они управляются единой сетью, способной определять расстояния между входящими упаковками.
Коллективные разработки часто сталкиваются с проблемами разделения ресурсов - файлов и каталогов и необходимости синхронизации времени и места.
Системы разделения файлов
Для поддержки коллективной работы с файлами применяются три основных класса систем.
Системы управления версиями файлов.
Системы управления пространствами пользователей.
Системы синхронизации удаленных пространств.
Если три класса систем выпускаются одним производителем, то часто каждая последующая система в этом списке использует предыдущую систему, выступая в качестве надстройки.
О системах управления версиями файлов следует использовать не только при коллективной, но и при индивидуальной (авторской) разработке для решения задачи отслеживания изменений между различными версиями. Мы помещаем информацию об этих системах в данном разделе лишь с целью подчеркнуть их полную незаменимость при коллективных разработках.
Поскольку данные системы действительно очень важны, их реализации существуют в большом количестве практически для всех операционных систем. Приведем два стека таких систем (табл. 5.2).
Таблица 5.2. Примеры средств поддержки коллективной разработки
Система управления версиями файлов
Система управления версиями файлов предназначена для отслеживания изменений между различными версиями файлов и разделения доступа к ним. Файлы обычно содержат программы на языках программирования и тексты.
Обратим внимание на то, что системой отслеживаются именно изменения (дельты) между версиями, а не сами полные версии, что позволяет занимать небольшое количество дискового пространства. Каталог SCCS часто называют репозиторием проекта.
Как и все широко распространенные программы утилита SCCS имеет надстройки в виде графического интерфейса, например утилиту vertool.
Система управления пространствами
Система управления рабочими пространствами пользователей предназначена для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве. Система работает на основе модели "копирование-изменение-слияние" и понятия "рабочее пространство".
Рабочее пространство - специальным образом выделенная совокупность каталогов с файлами, переданными системе управления версиями файлов. Кстати, на профессиональном жаргоне разработчики называют свои рабочие пространства - песочницами.
Модель "копирование-изменение-слияние" отражает схему организации работы с пространствами. Основная последовательность действий такова:
Создается основное мастер-пространство, от которого разработчики порождают свои рабочие пространства.
После внесения изменений в своем рабочем пространстве разработчик передает их в мастер-пространство.
Все разработчики периодически обновляют свои рабочие пространства из мастер-пространства.
Основная проблема, которая может при этом возникнуть, - это конфликт изменений в том случае, когда разработчик передает измененные файлы в мастер-пространство, но они уже оказываются измененными другим разработчиком. Можно попытаться избежать такой ситуации, выполняя обновления как можно Чаще или установив регламент для внесений изменений.
Тем не менее если такая ситуация возникла, то требуется выполнить под управлением разработчика слияние файлов, в ходе которого конфликт будет разрешен. Процесс слияния в большинстве случаев требует интеллектуального подхода при принятии решений в формировании итогового файла. Автоматизировать можно лишь сам процесс формирования файла, например, используя утилиту слияния файлов filemerge.
Система синхронизации удаленных пространств
В ряде случаев может оказаться, что пространства некоторых разработчиков находятся на значительном удалении друг от друга. Очень часто пространства находятся в различных локальных сетях, каждая из которых имеет выход в Интернет. Возникают две проблемы - организация пересылки изменений и их синхронизация.
Для осуществления пересылки можно воспользоваться стандартными средствами Интернета - электронной почтой или утилитой ftp. Для облегчения синхронизации следует завести два дополнительных пространства-порта и выполнять их синхронизацию (например, при помощи семафоров). Утилиты, выполняющие пересылку, должны тщательно сверять контрольные суммы, чтобы убедиться в корректности полученной информации. Естественно, в пересылаемый пакет информации входят только инкрементальные изменения (дельты), а не измененные файлы целиком.
Системы поддержки работы виртуальных групп
Общение в виртуальных группах очень часто осуществляется через Интернет, а в качестве средств общения выступают традиционные и хорошо известные средства, такие как:
видеоконференции;
аудиоконференции;
средства группового общения в реальном времени (чаты);
средства группового общения с разным временем подключения (доски объявлений, форумы);
электронная почта (включая списки рассылки, архивы и поиск по ним). Однако все перечисленные средства имеют определенные недостатки. Например, видео- и аудиоконференции не позволяют передавать файлы, а средства группового общения в Интернете не обеспечивают секретности от доступа любых других пользователей с одной стороны и позволяют разработчикам выступать анонимно с другой стороны.
Системы поддержки работы виртуальных групп должны хранить и обрабатывать информацию, а также помогать разработчикам осуществлять общение друг с другом. Сформулируем некоторые общие требования к таким системам.
Необходимость регистрации пользователя при его входе в систему.
Сохранение всей переписки и прочих данных в архиве.
Использование системы управления версиями текстов для программ и документации.
Классификация систем поддержки работы групп по предоставляемым ими возможностям общения была предложена Бобом Йохансеном (Bob Johansen).
система упорядочивания доступа к данным для показов видеозаписей, слайдов и других документов;
система проведения мозговых штурмов и процедур принятия решений. Система дает возможность вносить идеи в список сразу после их возникновения. Как правило, такие системы обладают возможностями для быстрого голосования.
В одно и то же время, в одном и том же месте (same time, same place).. Это классический случай, когда разработчики имеют возможность встречаться в одном помещении в определенное время. Здесь оказываются полезными следующие системы поддержки:
В одно и то же время, в разных местах (same time, different place). Системы должны обеспечивать общение в реальном времени. Для этого обычно применяются средства аудио- и видеоконференций.
В разное время, в одном и том же месте (different time, same place). Это довольно редкая ситуация, когда существует комната группы, но разработчики не имеют возможности собраться в ней в одно и то же время. Разработчику должна быть предоставлена возможность доступа к репозиторию проекта и всей информации, доступной на данном этапе проекта.
В разное время, в разных местах (different time, different place). Системы реализуют возможности ведения конференций, форумов и чатов с асинхронным подключением, возможность доступа к репозиторию проекта.
Неограниченные возможности доступа к данным (anytime, anyplace). Эта категория оставлена автором классификации на дальнейшее развитие коммуникационных технологий, когда возможности доступа к данным станут практически неограниченными.
Обратим внимание на то, что часто тип систем поддержки работы виртуальных групп зависит от рода их деятельности.
Группы управления. Управляющие работники компаний, находящиеся в удаленных друг от друга подразделениях, обычно используют видеоконференции.
Группы проекта. Разработчикам требуется максимально возможное количество средств общения и доступа к репозиториям.
Группы сопровождения. Группам необходимы средства связи и быстрый доступ к данным из любого места.
Приведем несколько наиболее известных систем поддержки виртуальных групп:
Facilitate.com (компании Facilitate.com (http://www.facilitate.com/ ));
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича
Санкт-Петербургский Колледж Телекоммуникаций им. Проф. М.А. Бонч-Бруевича
Реферат
" Технология коллективной разработки "
Учебный предмет: Технология разработки программного обеспечения
Выполнила: студентка 510 группы
Белоусова Мария, ПКС 4 курс
Проверила: Кривоносова Н.В.
2. Понятие коллективной разработки
3. Технические командные роли
4. Психологические командные роли
5. Обязанности членов группы
6. Типы совместной деятельности
7. Общинная модель разработки
8. Повышение эффективности коллективной работы
Список используемой литературы
Все множество разработок в зависимости от количества участников и типов взаимоотношений между ними может быть сведено к триаде разработок, приведенной на рисунке ниже.
Люблю одиночество, даже когда я один. (Ж. Ренар )
Этот принцип был достаточно широко распространен в 70-80-е годы XX века. Сейчас он применяется редко.
Наиболее интересен принцип авторской разработки с точки зрения применения в области наукоемких приложений. Для таких приложений характерна необходимость многолетнего изучения предметной области, практически полное отсутствие начального финансирования проекта, малая рентабельность, определяемая узким кругом пользователей.
· исключения межличностных коммуникаций, связанных с необходимостью порождения и изучения большого количества технологической документации;
· исключения работ по разбиению проекта на составляющие, по распределению их между исполнителями, по координации деятельности исполнителей и контролю за их работой.
Объем программного продукта, выполненного методом авторской разработки, в 5-20 раз меньше по сравнению с индустриальными аналогами.
Авторская разработка предполагает достижение профессионального успеха, известности и славы в одиночку. Такое вполне реально, следует только правильно выбрать профессиональную "нишу", область ведения разработки.
2. Понятие коллективной разработки
программирование коллектив управление
Собрать стадо из баранов легко, трудно собрать стадо из кошек. (С.П. Капица )
Одним из основных вопросов коллективной разработки является разделение труда - от равноправных соисполнителей до организации в виде жесткой иерархии (например, бригады главного программиста).
О первых опытах коллективных разработок
Известно, что первые коллективные разработки программ велись примерно так. Начальник выполнял разделение большого проекта на меньшие части и передавал далее по иерархии. Через некоторое время, теперь уже снизу вверх, шла сборка программы из написанных фрагментов. Собрать работающий программный продукт удавалось не всегда.
3. Технические командные роли
Равноправные соисполнители
Бригада равноправных соисполнителей обычно состоит из специалистов, занимающихся примерно подобными задачами в рамках одного проекта. Естественно, специализаций в рамках одной бригады может быть несколько:
· инженеры-разработчики (специалисты по инженерии программирования и программисты);
· технические писатели;
· инженеры тестирования;
· инженеры качества;
· специалисты по сопровождению продукта;
· специалисты по продажам продукта.
Тип работы определяет содержание и природу выполняемой работы. Приведем список типов работ и областей специализации на основе классификации Конгер .
· Разработка приложений.
o Программист.
o Специалист по инженерии программирования.
o Специалист по инженерии знаний.
· Работа с приложениями.
o Специалист по приложениям.
o Администратор данных.
o Администратор базы данных.
· Техническая поддержка.
o Системный администратор.
o Сетевой администратор.
o Администратор коммуникаций,
· Обеспечение качества продукта.
o Технический писатель.
o Инженер тестирования.
o Инженер качества.
· Маркетинг.
o Специалист по сопровождению продукта.
o Специалист по продажам продукта.
· Системное интегрирование.
o Системный интегратор.
Из перечисленных специализаций очень интересна специализация системного интегратора. Основные задачи системного интегратора - предложить заказчику вариант решения его проблемы, выбрав наиболее приемлемый по цене и технике, и реализовать его. Таким образом, системный интегратор продает решения и несет ответственность за их реализацию. Системный интегратор как профессионал должен обладать знаниями из очень многих областей - прикладное и системное программное обеспечение, администрирование систем, аппаратура, сети, экономика и т. п.
Бригада главного программиста
Почему бригада скорой помощи состоит из двух врачей?
Один знает - куда ставить клизму, а другой - зачем!
(Анекдот о специализации в команде )
Харлан Миллз [Брукс 1999] предложил организовывать команды (бригады) главного программиста (chief programmer teams), подобные хирургическим бригадам. Лишь один участник команды занимается основной работой, остальные оказывают ему всевозможную поддержку. Бригада главного программиста включает десять человек, выполняющих специализированные роли в команде (рисунок ниже).
Основные члены бригады выполняют функции, перечисленные ниже.
· Главный программист. Лично выполняет анализ и проектирование, создание и отладку кода, написание документации. Должен обладать талантом, большим опытом работы и существенными знаниями.
· Дублер. Может выполнять любую работу главного программиста, но менее опытен. Подстраховывает главного программиста, может заниматься написанием кода, но не несет ответственности за проект.
· Администратор, он же - менеджер. Под его контролем - деньги, люди, помещения, машинные ресурсы, контакты с другими группами и руководством.
· Редактор. Фактически, это технический писатель. Его задача - критически переработать черновики документации (созданные главным программистом), снабдить их ссылками и библиографией и обеспечить публикацию или помещение в Интернете.
· Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных задач. Обычно работает с несколькими бригадами.
· Инструментальщик. Разработчик специализированных инструментов - утилит и скриптов. Поддерживает основной инструментарий и оказывает по нему консультации. При необходимости может осуществлять администрирование операционной системы.
· Отладчик. Разработчик тестов и организатор тестирования программного продукта.
· Делопроизводитель. Отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта. Благодаря делопроизводителю, активные программисты освобождались от рутинных работ. Заметим, что в настоящее время функции делопроизводителя автоматизированы и переданы репозиторию проекта.
4. Психологические командные роли
Роб Томсет (Rob Thomsett) предложил восемь ключевых ролей в проекте (рисунок ниже).
· Председатель. Выбирает путь, по которому команда движется вперед к общим целям. Умеет обнаружить сильные и слабые стороны команды и обеспечить наибольшее применение потенциала каждого ее участника.
· Архитектор. Он же оформитель. Придает законченную форму действиям команды. Имеет четкое представление о проблемах и их возможных решениях.
· Генератор идей. Предлагает радикально новые идеи и стратегии, новые подходы к решению проблем, с которыми сталкивается группа. Особое внимание уделяет главным проблемам.
· Критик. Он же скептик, оценивающий проблемы с прагматической точки зрения. Ищет недостатки, изъяны и недоделки. Компенсирует оптимизм генератора идей.
· Исполнитель. Работник, собственно занимающийся написанием кода. Как правило, он не обладает широтой кругозора.
· Завершающий. Поддерживает в команде настойчивость в достижении цели. Играет доминирующую роль на завершающих стадиях разработки.
· Дипломат. Поддерживает силу духа в участниках проекта. Оказывает им помощь в трудных положениях. Пытается улучшить взаимоотношения в команде.
· Организатор. Обнаруживает и сообщает о новых идеях, разработках и ресурсах. Имеет много друзей и связей в своей организации, с помощью которых можно выпросить или одолжить необходимые ресурсы.
В реальных командах программистов могут быть выделены не все из этих ролей. Роль исполнителя часто берут на себя сразу несколько членов команды.
5. Обязанности членов группы
И у коллективного подхода есть недостатки:
· разрозненная связь с внешними источниками информации;
· несогласованное представление о разных сторонах проекта;
· несогласованность личных планов членов группы;
· отсутствие опыта, снижающее эффективность коллективной работы.
MSF - не готовое решение, а каркас, который можно адаптировать для нужд любой организации. Один из элементов этого каркаса - модель проектной группы. Она описывает структуру группы и принципы, которым надо следовать для успешного выполнения проекта.
Хотя модель группы разработчиков весьма конкретна, при знаков знакомстве с MSF ее нужно рассматривать в качестве отправной точки. Разные коллективы реализуют этот каркас по-разному, в зависимости от масштаба проекта, размеров группы и уровня подготовки ее членов.
Чтобы проект считался удачным, следует решить определенные задачи:
· удовлетворить требования заказчика - проект должен выполнить требования заказчиков и пользователей, иначе ни о каком успехе не может быть и речи, возможна ситуация, когда бюджет и график соблюдены, но проект провалился, так как не выполнены требования заказчика;
· соблюсти ограничения - разработчики проекта должны уложиться в финансовые и временные рамки;
· выполнить спецификации, основанные на требованиях пользователей - спецификации - это подробное описание продукта, создаваемое группой для заказчика; они представляют собой соглашение между проектной группой и клиентом и регулируют вопросы, касающиеся приложения, в основе этого требования лежит принцип "сделать все, что обещано";
· выпустить продукт только после выявления и устранения всех проблем - не существует программ без дефектов, однако группа должна найти и устранить их до выпуска продукта в свет, причем устранением ошибки считается не только ее исправление, но и, например, занесение в документацию способа ее обхода; даже такой способ устранения проблем предпочтительнее, чем выпуск приложения, содержащего невыявленные ошибки, которые в любой момент могут преподнести неприятный сюрприз пользователям и разработчикам;
· повысить эффективность труда пользователей - новый продукт должен упрощать работу пользователей и делать ее более эффективной. Поэтому приложение, обладающее массой возможностей применять которые сложно или неудобно, считается провальным;
· гарантировать простоту развертывания и управления - эффективность развертывания непосредственно влияет на оценку пользователем качества продукта, например, ошибка в программе установки может создать у пользователей впечатление, что и само приложение небезгрешно, от проектной группы требуется не только подготовить продукт к развертыванию и гладко провести его, но и обеспечить пользователей поддержкой, организовав сопровождение приложения.
Примечание. На проект влияет множество факторов, некоторые из которых создают дополнительные ограничения. Когда проектная группа рассматривает на совещаниях цели проекта и график его создания и выпуска, следует убедиться, что проект окупится, то есть удастся выпустить нужный продукт, не превышая запланированных расходов.
Для достижения этих целей в модели проектной группы, выполняемые задачи распределяются по шести ролям: менеджмент продукта, менеджмент программы, разработка, тестирование, обучение пользователей и логистика. Люди, выполняющие конкретную роль, должны рассматривать проект со своей "колокольни" и обладать необходимой для этого квалификацией.
6. Типы совместной деятельности
Коллективная разработка предполагает большое количество различных действий, причем степень совместной деятельности может существенно изменяться от одного действия к другому. Можно выделить четыре типа совместной деятельности .
· Мандатная деятельность, обычно представленная формальными собраниями, проводимыми на регулярной основе. Обычно собрания планируются заранее, а присутствие на них обязательно. Статистика показывает, что программисты проводят около 4% своего рабочего времени на собраниях.
· Созываемая деятельность, которая имеет место в случае решения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее и в них участвуют только действительно заинтересованные в решении проблемы программисты. На эту деятельность уходит около 14% рабочего времени.
· Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же задачей одновременно и обмениваются информацией о выполняемой работе. Эта деятельность занимает около 41% рабочего времени.
· Индивидуальная деятельность имеет место, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим программистом и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени.
7. Общинная модель разработки
Совершенство в проекте достигается не тогда, когда нечего добавить, а тогда, когда нечего убрать. (Антуан де Сент-Экзюпери )
Идеология общинной ("базарной") модели разработки сформулирована в программной статье Эрика Раймонда (Eric Raymond) "Собор и Базар". Общинная модель характеризуется тремя основными факторами.
· Децентролизованность разработки. Не существует ограничения сверху на количество людей, принимающих участие в проекте. Как правило, разработки такого типа ведутся на базе сети Интернет и могут включать любого заинтересованного разработчика Сети.
· Разработка ведется на базе открытых исходных текстов. По ним можно разобраться с сутью задачи и в любой момент подключиться к разработке.
· Большое количество внешних тестеров (бета-тестеров), позволяющих быстро обнаруживать ошибки и проблемы в программе.
Эрик Рэймонд сформулировал несколько уроков, которые позволяют лучше понять особенности общинной разработки.
· Каждая хорошая программа начинается с энтузиазма разработчика.
· Хорошие программисты знают, что можно написать, а великие - что можно переписать.
· При правильном отношении интересная проблема найдет вас сама.
· Когда вы теряете интерес к программе, ваша последняя обязанность - передать ее компетентному преемнику.
· Следует выпускать ранние и частые версии программ.
· Обнаружить проблему и исправить ее могут разные люди.
· Иногда использовать идеи пользователей лучше, чем свои идеи.
8. Повышение эффективности коллективной работы
Вот какие отношения друг с другом и к работе возникают в такой группе:
· заинтересованность;
· надежда, оптимизм, готовность к работе;
· определение задач и решений;
· проявление взаимопомощи;
· доверительные уважительные отношения;
· единение.
Последнее очень важно: эффективность работы группы при этом выше всего.
Для успеха проекта недостаточно только распределить роли и обязанности. Помимо структуры, следует придерживаться определенных принципов и методов. Ниже обсуждаются "лучшие методы и принципы", которые успешно применялись не только внутри Microsoft, но также партнерами и заказчиками компании.
Общее представление о проекте . Важнейший фактор для успеха проекта - единое понимание целей и задач проекта всеми участниками. Каждый из них изначально имеет свое мнение, касающееся приложения. В процессе формирования общего представления о проекте все эти мнения обсуждаются, что позволяет добиться единства целей всех членов проектной группы и заказчика.
На основе выработанного представления о проекте создается документ "Концепция проекта", который:
· описывает не только то, что делает продукт, но и то, чего он не делает;
· конкретизирует продукт (например, позволяет включать и исключать определенные функциональные возможности из данной версии); *побуждает группу достичь сформулированной цели;
· содержит описание путей реализации проекта, благодаря чему проектная группа и заказчик могут начать работу.
Примечание Создание концепции не гарантирует согласия с ней всех участников проекта (разработчиков, заказчика и пользователей). Поэтому необходимо проследить, чтобы все они тщательно изучили ее и полностью в ней разобрались.
Выработка согласованного мнения о проекте позволяет избежать разногласий между участниками проекта, мешающих достичь поставленных целей и разъединяющих группу. Оптимальный способ согласования концепции - обсуждение целей и задач проекта. Такая дискуссия дает возможность добиться взаимопонимания всех членов группы. При этом их обязательства будут не простым согласием: "Да, мы будем работать над проектом", в них появится мотивация: "Давайте приступим к работе и сделаем что-то действительно новое". Дискуссию на ранних стадиях проекта, как правило, организуют ее сотрудники отделов менеджмента продукта и менеджмента программы, имеющие опыт маркетинговых исследований.
Внимание! Не обольщайтесь тем, что действия проектной группы и их цель понятны заказчику. Подробно обсуждайте проект с заказчиком на всех стадиях его выполнения.
Группа равных . В группе равных важна каждая роль. Такой подход, и только он, делает возможным неограниченный обмен информацией между членами группы, повышает ответственность за выполнение работы и усиливает понимание того, что все шесть целей проекта одинаково важны. Естественно, в таких группах надо проводить проверку качества продукта; это делает представитель заказчика, разбирающийся в решаемой задаче.
Подчеркнем, что равенство - это не анархия. Равенство существует лишь в отношении ролей; в рамках каждой роли следует придерживаться обычной иерархической модели. В каждой группе необходима должностная иерархия и наличие руководителя, ответственного за управление и координирование работы своего направления. Задача остальных членов группы, исполняющих ту же роль, - выполнять поставленные перед ними задачи.
Ориентация на продукт - это не призыв работать над коммерческим программным обеспечением одним способом, а над приложениями для внутреннего пользования - иначе. Это требование - относиться к результату работы, как к продукту.
Прежде всего нужно выяснить, является проект самостоятельным или частью более крупного проекта. MSF рекомендует идентифицировать проекты - это позволяет людям чувствовать себя членами команды. Скажем, в Microsoft принята практика присвоения проектам кодовых имен (например "Чикаго" для Windows 95 и "Мемфис" для Windows 98). Кодовые имена четко идентифицируют проект и работающую над ним группу, позволяют людям четче ощущать причастность к проекту и ответственность за него. Создать и усилить значимость группы, поднять ее боевой дух можно разными способами - скажем, помещая название проекта на футболки, кружки и прочие сувениры.
Сформированное отношение к продукту позволяет сконцентрироваться на результате проекта, а не на процессе его достижения вовсе не означает, что процесс не важен для группы. Мы просто иначе расставляем приоритеты - процесс должен служить достижению цели, а сам по себе он не имеет ценности. Увлеченность процессом не должна стоять на пути к результату. Необходимо прежде всего, чтобы все, чувствовали ответственность за выпуск продукта.
Бывший менеджер программ Microsoft Крис Питере описал отношение к продукту следующим образом:
"У нас всех... одна и та же работа - выпуск продукта. Ваша задача - не писать код, не тестировать его и не создавать спецификации. Ваша задача - выпустить продукт. Именно это делает группа разработки продукта.
Ваша роль разработчика или тестера - вторична. Я не хочу сказать, что она не имеет значения - конечно, она важна, - но она вторична по отношению к вашей основной задаче - выпуску продукта.
Когда вы просыпаетесь утром и приходите на работу, вы спрашиваете себя: " Что мы делаем, пишем код или делаем продукт? " Ответ очевиден - мы делаем продукт. Вы не должны программировать, вы обязаны не программировать, и это не каламбур " .
Ориентация на отсутствие дефектов - это требование соблюдения качества продукта. Оно вовсе не подразумевает, что продукт должен быть выпущен без дефектов; достаточно, чтобы дефектов было не больше нормы, установленной группой на ранних стадиях разработки. Кроме того, это означает, что группе придется постоянно контролировать качество на всех стадиях: если завтра потребуется выпустить готовый продукт, группа должна быть готова выполнить это обязательно. Таким образом, с точки зрения качества продукт всегда должен быть практически готов.
В успешных группах все отвечают за качество продукта - эту обязанность нельзя переложить на других. В этом смысле все члены группы являются представителями заказчика.
Понимание целей бизнеса . Чтобы выпустить успешный продукт, группе недостаточно разбираться только в технической стороне проекта. Создано множество технически совершенных и безупречно написанных продуктов, не способных выполнять задачи, поставленные заказчиком. Чтобы избежать такой ситуации, члены группы должны ясно представлять себе решаемую задачу.
И здесь необходимо активное участие заказчика в процессе разработки. Его обязательно нужно привлекать к созданию концепции проекта, к принятию решений по продукту и его использованию и к анализy промежуточных версий.
Ответственность в равной мере . Крис Питерс однажды не без юмора заметил:
"Чрезвычайно важно, чтобы ответственность разделяли сотрудники как можно более низких уровней. Ваша цель не в том, чтобы лишиться сна, переживая из-за проекта, которым вы руководите.
Ваша цель не в том, чтобы лишить сна руководителей направлений.
Не спать по ночам от переживаний за проект должны абсолютно все. Вот когда вы этого добьетесь, считайте, что распределили ответственность должным образом " .
Чтобы добиться согласованной работы всех членов группы, вы должны сделать их роли взаимозависимыми и перекрывающимися, они все в одинаковой мере должны разделять ответственность за выпуск нужного продукта в запланированные сроки. Таким образом разрушается узкая специализация членов группы, которая ведет к изолированности, а не к совместной работе.
Совместное проектирование . Джим Маккарти так описал концепцию общего участия в проектировании в своей книге "Dynamics of Software Development":
" Цель проектирования любого продукта - собрать лучшие идеи. Поэтому в проектировании должны участвовать все члены группы " .
В создании функциональных спецификаций должны участвовать представители всех направлений, так как у каждого из них свое представление о проекте. Они должны убедиться, что в проекте учтены не только требования всей группы, но и требования каждой роли.
Обучение на опыте других проектов . Чтобы не полагаться на удачу, стоит воспользоваться опытом работы над другими проектами, как успешными, так и провалившимися. Изучение опыта - основа совершенствования. Один из методов структурирования и накопления опыта - подведение итогов каждого этапа, зафиксированное в обзоре. Обзор, основа которого - сопоставление планов с результатами, помогает скорректировать дальнейший ход работы и избежать ошибок в дальнейшем. Кроме того, при этом можно выявить хорошо зарекомендовавшие себя методы, чтобы применять их в будущем.
Примечание. Очень важно делиться информацией о методах работы с другими группами разработчиков своей организации.
· используйте меньше людей, но лучших в своей области;
· подбирайте задачи в соответствии с квалификацией и мотивацией людей;
· помогайте людям набирать опыт и знания;
· подбирайте людей, дополняющих друг друга;
· не бойтесь отсекать все, что не подходит.
Обучение группы . Работа группы эффективна, если все ее члены понимают, что они делают. Однако во многих случаях это простое правило реализуется недостаточно полно. Выпустить же нужный продукт в срок удастся только при наличии формального и неформального планов обучения проектной группы.
Изучение методологии . Разработка программного обеспечения - это не только создание кода. Поэтому изучение методологии разработки руководителями групп и основными участниками проекта сократит затраты и время выполнения проекта.
Изучение технологий . Создать хороший продукт очень сложно. Поэтому группам разработчиков, логистиков и, по возможности, менеджеров программы надо изучать существующие технологии. Каждый день появляются новые формы обучения современнейшим технологиям, однако для успешнойреализации таких технологий недостаточно только знания их основ, необходимо понимать способы их применения.
Вот какие технологии необходимы для работы над проектом по созданию системы управления ресурсами (Resource Management System, RMS), о которой идет речь в практикумах этой книги:
· Dynamic HTML;
· Microsoft Active Server Pages (ASP);
· Microsoft Visual Basic Scripting Edition (VBScript); *Microsoft Internet Information Server (US);
· Microsoft Windows NT 4.0;
· Microsoft Windows 2000;
· Microsoft Systems Management Server 2.x (SMS);
· Microsoft Outlook 2000;
· Microsoft Visual InterDev;
· Microsoft Visual Basic 6.0 (VB);
· Microsoft Visual C++ 6.x (C++), библиотеки ATL и STL;
· Microsoft Transaction Server 2.0 (MTS);
· Microsoft SQL Server 7.x;
· создание СОМ-объектов с помощью VB и C++;
· ActiveX Data Objects (ADO);
· Collaborative Data Objects (CDO).
Часто при обучении упускают из вида сопровождение приложения в существующей информационной инфраструктуре. Однако успех проекта зависит не только от качества созданного кода. Проектная группа должна исследовать взаимное влияние инфраструктуры и приложения друг на друга. Как скажется на приложении появление новых операционных систем, новых версий существующих операционных систем или новых базовых приложений, используемых продуктом?
Кроме того, проектной группе придется учесть то обстоятельство, что во время работы над проектом могут появиться новые технологии или новые версии приложений. Нужно уметь оценивать влияние новых функциональных возможностей таких продуктов на жизненный цикл проекта. Поэтому время на обучение следует включать в график проекта еще до определения даты выпуска приложения.
Координация работы с внешними группами . Проектная группа, рассчитывающая на успех, должна взаимодействовать с внешними группами - как с заказчиком и пользователями, так и с другими разработчиками. Этим занимаются менеджер программы, менеджер продукта, инструктор и логистик. В обязанности этих ролей входят как внутренние, так и внешние контакты, в то время как разработчики и тестеры изолированы от общения с внешним миром. (Такая изоляция приводит к повышению эффективности труда этих двух групп.)
Важно, чтобы взаимодействие с внешними группами было явным и понятным. На рис. 3.3 проиллюстрирована координация взаимодействий, связанных как с бизнесом, так и с технологиями. Проектным группам, как правило, приходится взаимодействовать с большим количеством внешних организаций, включая финансовые и юридические подразделения и отделы контроля качества продукта.
Коллективное владение кодом позволяет каждому разработчику выдвигать новые идеи в любой части проекта, изменять любую строку программы, добавлять функциональность, фиксировать ошибку и проводить реорганизацию. Один человек просто не в состоянии удержать в голове проект нетривиальной системы. Благодаря коллективному владению кодом снижается риск принятия неверного решения (главным разработчиком) и устраняется нежелательная зависимость проекта от одного человека.
Работа начинается с создания тестов модуля, она должна предшествовать программированию модуля. Тесты необходимо помещать в библиотеку кодов вместе с кодом, который они тестируют. Тесты делают возможным коллективное создание кода и защищают код от неожиданных изменений. В случае обнаружения ошибки также создается тест, чтобы предотвратить её повторное появление.
Кроме тестов модулей, создаются тесты приемки, они основываются на пользовательских историях. Эти тесты испытывают систему как "черный ящик" и ориентированы на требуемое поведение системы.
На основе результатов тестирования разработчики включают в очередную итерацию работу над ошибками.
Все коды в проекте создаются парами программистов, работающими за одним компьютером. Парное программирование приводит к повышению качества без дополнительных затрат времени. А это, в свою очередь, уменьшает расходы на будущее сопровождение программной системы.
Оптимальный вариант для парной работы - одновременно сидеть за компьютером, передавая друг другу клавиатуру и мышь. Пока один человек набирает текст и думает (тактически) о создаваемом методе, второй думает (стратегически) о размещении метода в классе.
Во время очередной итерации всех сотрудников перемещают на новые участки работы. Такие перемещения помогают устранить изоляцию знаний и "узкие места". Особенно полезна смена одного из разработчиков при парном программировании.
Замечено, что программисты очень консервативны. Они продолжают использовать код, который трудно сопровождать, только потому, что он все еще работает. Боязнь модификации кода у них в крови. Это приводит к предельному понижению эффективности систем. В XP считают, что код нужно постоянно обновлять - удалять лишние части, убирать ненужную функциональность. Этот процесс называется реорганизацией кода. Поощряется безжалостная реорганизация, сохраняющая простоту проектных решений. Реорганизация поддерживает прозрачность и целостность кода, обеспечивает легкое понимание, исправление и расширение. На реорганизацию уходит значительно меньше времени, чем на сопровождение устаревшего кода. Увы, нет ничего вечного - когда-то отличный модуль теперь может быть совершенно не нужен.
И еще одна составляющая коллективного владения кодом - непрерывная интеграция.
Без последовательной и частой интеграции результатов в систему разработчики не могут быть уверены в правильности своих действий. Кроме того, трудно вовремя оценить качество выполненных фрагментов проекта и внести необходимые коррективы.
По возможности XP-разработчики должны интегрировать и публично отображать, демонстрировать код каждые несколько часов. Интеграция позволяет объединить усилия отдельных пар и стимулирует повторное использование кода.
Список используемой литературы
1. С.А. Орлов. Технологии разработки программного обеспечения: Учебник. - СПб.: Питер, 2002
2. Брауде Э. Технология разработки программного обеспечения. - СПб.: Питер, 2004
3. Г.С. Иванова, Т.Н. Ничушкина, Е.К. Пугачев. Объектно-ориентированное программирование: Учебник для вузов. - 2-е изд., перераб. и доп./Под. Ред. Г.С. Ивановой. - М.: Издательство МГТУ им. Н.Э Баумана, 2003.
4. Книга цитат от Джона Ллойда
Размещено на Allbest.ru
...Подобные документы
Использование моделирования в программной инженерии в процессе разработки программного обеспечения. Основные этапы процесса разработки программного обеспечения, их характеристика. Моделирование процессов, их определение фазами и видами деятельности.
реферат , добавлен 25.12.2017
Понятие программной инженерии как применения определенного систематического измеримого подхода при разработке, эксплуатации и поддержке программного обеспечения. Модели процесса разработки программного обеспечения. Управление программными проектами.
презентация , добавлен 12.11.2014
Понятие программного обеспечения, вопросы его разработки и использования. Общая характеристика системного программного обеспечения и работа операционной системы. Специфика процесса управления разработкой программного обеспечения и его особенности.
курсовая работа , добавлен 23.08.2011
Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.
курсовая работа , добавлен 29.06.2010
Реализация задачи использования методики SDLC (управление жизненным циклом разработки программного обеспечения) при внедрении реальной системы информационных технологий. Описание проекта внедрения системы автоматической регистрации участников выставок.
реферат , добавлен 10.09.2010
Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.
дипломная работа , добавлен 13.07.2011
Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа , добавлен 26.09.2014
Основные этапы разработки программного обеспечения (пакета программ), анализ требований к системе. Метод пошаговой детализации. Языки программирования низкого уровня и высокого уровня (императивные, объектно-ориентированные, функциональные, логические).
презентация , добавлен 13.10.2013
Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.
курсовая работа , добавлен 14.12.2012
Порядок автоматизации расчетов себестоимости и длительности программного обеспечения производственного предприятия. Выбор языка программирования и системы управления базами данных. Разработка алгоритмов расчета себестоимости программного обеспечения.
3. menu – меню. Реализовано в виде списка, причем каждый пункт может содержать подменю, которое тоже представляет собой список. Каждый элемент списка обязательно содержит текст (часто с горячей клавишей) и может содержать иконку 32*32, сочетание «горячих клавиш» для вызова элемента без вхождения в меню или символ 4. Сочетание icon+menu = Tool panel (Панель инструментов)
4. pointers – механизм индивидуальной настройки пользователя. Обозначается маленькой стрелкой в левом нижнем углу иконки. Пользователь может конфигурировать под себя любое количество указателей в любой папке и области.
Разработчик и архитектор в больших программах – разные люди.
Задача архитектора: представить предметную область с точки зрения пользователя (удобство использования интерфейса). Архитектор должен выяснить тезаурус пользователя и обеспечить лингвистическое обеспечение проекта.
Замечание: невозможно учесть все требования пользователя, поэтому желательны пункты Параметры, Сервис, Настройка, Конфигурация – варьирует характеристиками создаваемого программным продуктом под конкретного пользователя. Например: цвет фона, меню, наличие строки состоянии. В общем случае, чем лучше проработан интерфейс пользователя, тем конкурентоспособнее он.
19. Требования к программистам. Формирование команды программистов.
Требование к программистам и их оценка
- Уровень образования
По учреждению выясняются возможности
Тестирование знаний
Резюме – представление опыта программистов, характеризующее его возможное применение.
На производительность влияют:
- Наличие амбиций человека (собственная оценка своих качеств и себя в коллективе)
- Уровень притязания. Самооценка может быть источником конфликтов в коллективе.
- Коммуникабельность! при сдаче проекта.
Задача руководителя после подбора команды организовать работу так, чтобы по максимуму использовать профессиональные и персональные данные программистов.
20. Организация процесса работы команды программистов (персональная организация и коллективная работа).
Осуществляет руководитель проекта.
Опытный руководитель распараллеливает работы. Идет пересечение этапов.
По каждому этапу четко сформулирован результат. Если результата нет, то этап не завершен.
Документирование процесса работы. Все, что делается - оформляется.
Документация создается с начала реализации проекта. Оформляется в соответствии с ГОСТом (ISO) или с корпоративными стандартами документациями.
Удобно использовать маршрутный лист.
Достоинства подхода:
1. документация нужна не только тем, кто пишет программу, но и тем, кто работает рядом, т.е. вынужден использовать ваши результаты.
2. документация отражает текущее состояние работы над проектом
3. при окончании проекта требуется минимум усилий для оформления документации для передачи заказчику.
Организация персональной работы программиста
Менеджер планирует работу программисту, формулирует суть работы, сроки. Ежедневный самоотчет о проделанной работе позволяет менеджеру лучше планировать рабочее время программиста. Написание самоотчета занимает от 15 до 30 минут в день, но дисциплинирует программиста и дает возможность менеджеру перепланировать работу так, чтобы успеть.
Чем больше проект, тем большее значение принимает работа каждого программиста в отдельности и тем важнее любые инструменты, с помощью которых контролируется ход и выполнение работы.
Организация коллективной работы
Координация коллективной работы подразумевает информационное взаимодействие всех участников процесса, т.е. любой человек, участвующий в создании системы должен иметь возможность получать информацию о любых проектных решениях.
«Рабочая тетрадь». Все проектные решения документируются в рабочую тетрадь. Иногда размер всех рабочих тетрадей по проекту достигал толщины в 1 м.
Идея рабочей тетради поддерживается в виде выпуска очередной версии программного продукта, где документация и сам ПП отражают эволюцию его изменения.
Версия 0 является версией, готовой в бета-тестированию.
Согласование работ:
1. Распараллеливание работ
2. Сетевое планирование
Программные продукты, позволяющие осуществлять планирование работ и оптимизировать сроки:
- MS Outlook
- Time manager
- MS Project – управление ресурсами, планирование с дискретностью от часа до месяца. Позволяет работать удаленным пользователям надо удаленным проектом.
21. Планирование работы команды программистов. Эффект второй системы.
После того, как намечены все этапы, определены исполнители (ресурсы проекта и сроки), необходимо организовать получение информации о текущем состоянии проекта. Для этого можно организовать карты учёта такой структуры:
- Шифр, номер работы
- Описание выполнения
- Время окончания
- Результат, если работа окончена.
Отслеживает эту информацию менеджер группы.
По оценкам 28-33% времени программист пишет программу. Остальное – совещания, согласования, поиск литературы, обучение, координация с программистами, пишущими совместные с его модулями – 60%.
Задача менеджера – минимизировать 60% так, чтобы увеличить время работы программиста над программой. Если менеджер хороший, то он сможет снизить 60% до 50%.
Критическая ситуация – проект не успевает по срокам:
В этом случае возможны следующие шаги:
- увеличить число программистов на проект (зачастую только усугубляет положение);
- на существующем количестве перераспределить работу, ввести дополнительное время;
Эффект второй системы
Часть фирм планируют разработку системы на «выброс», чтобы получить представление о трудностях, ошибках, проверить основные идеи, а после разрабатывать вторую систему.
22. Работа с заказчиком.
Специфическая функция взаимодействия с потенциальным или реальным потребителем ПП.
- 1 Заказчик, 1 Разработчик
- Заказчик объявляет тендер на разработку. Выигрывает фирма, которая либо уменьшает стоимость разработки, либо за эту же сумму предоставляет больше возможностей. Играет роль имидж компании (участие и завершение аналогичных разработок, участие в семинарах, совещаниях по теме, открытость компании).
Преимущества:
Заказчик в курсе всей работы
Тестирование параллельно с написанием