Формирование команды. Члены команды.

⇐ ПредыдущаяСтр 3 из 3

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

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

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

Члены команды

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

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

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

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

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

· Главный технолог. Эту личность многие называют "BigGeek", однако давайте не попадаться в ловушку следования стереотипам. Этот член команды отвечает за то, как работает продукт. Он должен составить документ, в котором описываются технические и функциональные спецификации. Также он должен подготовить формы, наборы покупателя, базы данных, системы управления содержанием (CMS) и, в большей или меньшей мере, программную поддержку.

· Web-дизайнер. Он работает над внешним видом web-узла и отчитывается перед творческим директором. Среди прочих его обязанностей – создание динамической графики и рисунков, а также поверхностное программирование в программах Fireworks, Dreamweaver или Flash. Хотя эту роль иногда называют "PixelMonkey", ее задачи более важны, чем просто разбрасывание пикселей по экрану. С многих точек зрения эту роль можно сравнить с ведущим художником в традиционном производственном процессе создания графики.

· Flash-разработчик. Подчиняется творческому директору и отвечает за создание Flash-анимации и перевод графики из Freehand в содержание Flash. Он также отвечает за организацию содержания и оптимизацию его для отображения в Web.

· Программист Actionscript. Еще три года назад такой должности не существовало. Переход Ationscript (языка программирования Flash) к 4-й версии приложения Flash вызвал рождение этой профессии. Этот член команды отвечает за взаимодействие с пользователем через графический интерфейс и создание динамических страниц.

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

· Web-программист. Подчиняется техническому директору и работает с конструктором баз данных. Он отвечает за большинство задач программирования (на языках XML, HTML, DHTML, JavaScript), интегрирующих оболочку узла с программными функциями, обеспечивающими его работоспособность.

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

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

23. Микропроцесс проектирования информационных систем.

Г. Буч выделяет в процессе проектирования программного приложения микро и макропроцессы.

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

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

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

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

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

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

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

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

Микропроцесс обычно состоит из следующих видов деятельности:

выявление классов и объектов на данном уровне абстракции;
выяснение семантики этих классов и объектов;
выявление связей между этими классами и объектами;
спецификация интерфейса и реализация этих классов и объектов.

24. Макропроцесс проектирования информационных систем.

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

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

Макропроцесс обычно включает следующие действия:

- выявление сущности требований к программному продукту (концептуализация);

- разработка модели требуемого поведения системы (анализ);

- создание архитектуры для реализации (проектирование);

- итеративное выполнение реализации (эволюция);

- управление эволюцией продукта в ходе эксплуатации (сопровождение).

У всех нетривиальных программных разработок макропроцесс продолжается и после создания и внедрения системы.

Описание основных этапов разработки приложения дано в таблице.

Таблица- Основные этапы разработки приложения

Наименование этапа	Основные действия	Результаты
Выявление сущности требований к программному продукту (концептуализация)	1) определить цели апробации концепции и критерии того, что считать благополучным исходом; 2) собрать подходящую команду для разработки прототипа; 3) оценить готовый прототип и принять ясное решение о проектировании конечного продукта или о дальнейшем исследовании. Решение о начале разработки конечного продукта нужно принимать с разумным учетом потенциального риска, выявленного при апробации концепции.	Первичными продуктами концептуализации являются прототипы системы.
Разработка модели требуемого поведения системы (анализ)	1) идентифицировать основные функциональные точки системы и, если возможно, сгруппировать функционально связанные виды поведения. Рассмотреть возможность создания иерархии функций, в которой высшие функции вытекают из низших. 2) для каждого представляющего интерес набора функциональных точек сделать раскадровку сценария, используя технику анализа поведения. Когда прояснится семантика сценариев, следует документировать их, используя диаграммы объектов, которые иллюстрируют объекты. Приложить описание событий, происходящих при выполнении сценария, и порядок выполняемых в результате действий. Кроме того, необходимо перечислить все предположения, ограничения и показатели эффективности для каждого сценария; 3) если необходимо, сделать описания поведения системы в исключительных ситуациях; 4) для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат); 5) найти в сценариях повторяющиеся шаблоны и выразить их в терминах более абстрактных обобщенных сценариев или в терминах диаграмм классов, показывающих связи между ключевыми абстракциями. 6) внести изменения в словарь данных; включить в него новые классы и объекты, выявленные для каждого сценария, вместе с описанием их ролей и обязанностей.	Результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов Побочным результатом анализа будет оценка риска: выявление опасных мест, которые могут повлиять на процесс проектирования.
-Создание архитектуры для реализации (проектирование). Архитектурное планирование - охватывает логическую декомпозицию, состоящую в группировании классов, и физическую декомпозицию, состоящую в разбиении на модули и назначении заданий процессорам	1) рассмотреть группирование функциональных точек (найденных в анализе) и распределить их по слоям и разделам архитектуры. Функции, базирующиеся одна на другой должны попасть в разные слои; функции, сотрудничающие между собой для обеспечения требуемого поведения системы на данном уровне абстракции должны попасть в разделы системы, представляющие услуги на этом уровне; 2) проверить архитектуру созданием действующих релизов, которые частично удовлетворяют семантике нескольких важнейших сценариев, предоставленных анализом; 3) оценить достоинства и недостатки архитектуры. Определить риск изменения каждого ключевого архитектурного интерфейса, чтобы можно было заранее распределить ресурсы при эволюции системы.	Диаграммы классов и объектов.
Создание архитектуры для реализации (проектирование). Тактическое проектированиесостоит в принятии решений о множестве общих приемов	1) перечислить все случаи, когда нужно следовать единым общим приемам. Некоторые из них окажутся фундаментальными, независимыми от предметной области, например, управление памятью, обработка ошибок и т.д. Другие будут специфичны для данной области и будут содержать свойственные этой области идиомы и механизмы, такие, как принципы управления системами реального времени или транзакциями и базами данных в информационных системах; 2) для каждого приема составить сценарий, описывающий его семантику. Затем выразить ее в виде исполнимого прототипа, который может быть уточнен и представлен инструментально; 3) документировать каждый принцип и распространить полученные документы, чтобы обеспечить единое архитектурное видение.	Диаграммы классов и объектов Описания семантики. Сценарии
Создание архитектуры для реализации (проектирование). Программные релизы закладывают основы архитектурной эволюции системы.	1) полученные в результате анализа сценарии упорядочить от основных к второстепенным. Приоритетность сценариев лучше выяснить вместе с экспертом в предметной области, аналитиком, архитектором и контролером качества; 2) распределить функциональные точки по релизам так, чтобы последний релиз в серии представлял результирующую систему; 3) определить цели и расписание релизов так, чтобы дать время на разработку и синхронизировать релизы с другими действиями, например, с разработкой документации и полевыми испытаниями; 4) начать планирование задач, учитывая критические места проекта и ресурсы, отведенные на выпуск каждого релиза.	Программные релизы. План, в котором определены расписание работ, задачи коллектива и оценка риска.
Итеративное выполнение реализации (эволюция);	1) определить функциональные точки, которые попадут в новый релиз, и области наивысшего риска, особенно те, которые были выявлены еще при эволюции предыдущего релиза; 2) распределить задачи по релизам среди членов команды и начать новый микропроцесс. Контролировать микропроцесс, просматривая проект, и проверять состояние дел в важных промежуточных этапах с интервалами от нескольких дней до двух недель; 3) когда потребуется понять семантику требуемого поведения системы, поручить разработчикам сделать прототип поведения. Четко установить назначение каждого прототипа и определить критерии готовности. После завершения решить, как включить результаты прототипирования в этот или последующие релизы; 4) завершить микропроцесс интеграцией и очередным действующим релизом.	Серия исполняемых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели. Описание поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа системы
Управление эволюцией продукта в ходе эксплуатации (сопровождение).	1) упорядочить по приоритетам предложения о крупных изменениях и сообщения об ошибках, связанных с системными проблемами, и оценить стоимость переработки; 2) составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции; 3) если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения; 4) приступить к разработке следующего эволюционного релиза программы.	Список новых заданий: обнаруженные дефекты и новые требования.

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

Для анализа рекомендуется использовать технологию CRC – карточек. CRC обозначает Class – Responsibilities - Collaborators(Класс/ Ответственности/ Участники). Это простой и замечательно эффективный способ анализа сценариев. Карты CRC впервые предложили Бек и Каннингхэм для обучения объектно-ориентированному программированию, но такие карточки оказались отличным инструментом для общения разработчиков между собой.

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

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

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

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

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

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

Дата добавления: 2018-02-15; просмотров: 948; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 23

Мы поможем в написании ваших работ!