Коллективист

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

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

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

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

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

Ролевая модель команды. Роли и их ответственности.

22.Управление рисками в программном проекте

Риски программных проектов можно разделить на четыре основные категории:

Риски связанные с требованиями

Технологические риски

Риски связанные с квалификацией персонала

Политические риски

Риски связанные с требованиями

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

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

Основной способ справится с этой группой рисков - контролировать процесс управления требованиями, создавать UML модели вариантов использования и привлекать заказчиков для обсуждения полученных моделей. Заказчик должен понять, даже если он этого не понимал в начале, что он получит на каждом этапе разработки и как этим можно будет пользоваться. Использование инструментальных средств для управления требованиями, таких как RequisitePro и ClearQuest и такого инструмента для создания моделей, как, например, Rational Rose

Технологические риски

Эта группа рисков объединяет риски связанные с используемыми технологиями. Какие технологии вы планируете применить. Использовались в вашей компании выбранные средства, насколько эти технологии отработаны или это " только что испеченные пирожки".

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

Наилучший вариант оценить технологические риски - это создать прототип для проверки новых технологий.

Риски связанные с квалификацией персонала

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

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

Политические риски

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

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

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

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

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

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

23.Инженерия требований. Определение и формализация требований.

Методы определения требований в программной инженерии

A | версия для печати

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >

3.1. Общие подходы к определению требований

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

3.1.1. Классификация требований

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

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

Требования - это утверждения о функциях и ограничениях системы.

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

Требования - это спецификация того, что и как должно быть реализовано.

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

условий или возможностей, необходимых пользователю для решения поставленных проблем или достижения целей;

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

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

документированное представление условий, возможностей ограничений среды на проектирование системы.

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

Требования к ПО состоят из требований пользователей, функциональных, системных и нефункциональных требований.

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

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

Варианты формализации требований

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

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

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

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

Требования в виде графа с зависимостями в одном из средств поддержки требований (IBM Rational RequisitePro, DOORS, Borland CaliberRM и нек. др.). Такое представление удобно при частом изменении требований, при отслеживании выполнения требований, при организации " привязки" к требованиям задач, людей, тестов, кода. Важно также, чтобы была возможность легко создавать такие графы из текстовых документов, и наоборот, создавать презентационные документы по таким графам.

Формальная модель требований для верификации, модельно-ориентированного тестирования и т. д.

. Билет 24.

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

· мотивация персонала на основе индивидуальных целей для достижения общей цели предприятия;

· создание идеологии, формирование и укрепление имиджа фирмы, в поддержании которого участвует персонал всего предприятия;

· установление взаимопонимания между руководством и персоналом;

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

· поддержание высокого уровня профессионализма;

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