7 Работа с кадрами. Перечислить роли разработчиков и дать характеристику каждой из них.

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

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

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

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

Дополнительные роли разработчиков:

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

Аналитик или системный аналитик: отвечает за развитие и интерпретацию требований конечных пользователей. Д.б. экспертом в предметной области откуда исходит заказ на разработку.

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

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

Менеджер интеграции: отслеживает новые версии компонентов системы, интегрирует их в работающую систему и доводит информацию об их наличии до смежных команд

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

Ответственный за документацию (технический писатель): отвечает за подготовку технической документации по создаваемому ПО, а также участвует в работе по созданию эксплуатационной документации

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

8 Использование языка uml при проектировании сложных программных систем. Какие диаграммы используются в uml для создания моделей программной системы.

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения.

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

• Use case diagram (диаграммы сценариев) - позволяет создать список операций, которые выпол­няет система. Часто этот вид диаграмм называют диаграммой функций;

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

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

• Deployment diagram (диаграммы топологии) - предназначен для анализа аппаратной части системы, то есть «железа», а не программ. При помощи данной диаграммы проектировщик может произвести анализ необходимой аппаратной конфигурации, на которой будут работать отдельные процессы системы, и описать их взаимодействие между собой и другими аппаратными устройствами. Этот тип диаграмм также позволяет анализировать взаимодействие процессов, работающих на разных компьютерах сети;

• State diagram (диаграммы состояний) - предназначена для отображения состоя­ний объектов системы, имеющих сложную модель поведения. Каждый объект системы, обладающий определенным поведением, мо­жет находиться в определенных состояниях и переходить из состояния в состояние в процессе реализации сценария поведения объекта;

• Activity diagram (диаграммы активности) - дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта;

• Interaction diagram (диаграммы взаимодействия) - включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе;

• Sequence diagram (диаграммы последовательностей действий) - Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений;

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

• Collaboration diagram (диаграммы сотрудничества) - Этот тип диаграмм позволяет описать взаимодействия объектов, абстра­гируясь от последовательности передачи сообщений. На этом типе диа­грамм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта, и типы этих сообщений;

• Class diagram (диаграммы классов) - Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого можно генерировать исходный код описанных классов;

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

• Component diagram (диаграммы компонент) - Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при проектировании физической структуры системы.