39. Особенности командной разработки по

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

Недостатки: объем работы, вся ответственность на себе

Преимущества работы в команде:

1. Путём объединения знаний и ресурсов может быть решено огромное разнообразие сложных вопросов

2. Решение проблем часто стребует большого разнообразия знаний, навыков и опытов

3. Повышается моральный дух и чувство сопричастности в принятии решений

4. Лучше возможности для создания связей между отдельными разработчиками

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

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

Командные роли:

1. Координатор – уточняет цели, определяет повестку дня, приоритеты, выделяет проблемы, подводит итоги. Имеет решающее значение, но не доминирует в дискуссии.

2. Формирователь – придаёт форму коллективным усилиям. Может давить на команду, если это даёт конкретный результат.

3. Мыслитель – источник оригинальных идей, пожеланий и предложений, которые радикальны и оригинальны

4. Оцениватель – измеряет и беспристрастно анализирует

5. Исполнитель – преобразует решение стратегии в определённые конкретные задачи

6. Коммуникатор – действует за пределами команды, принося идеи, информацию и события

7. Коллективист – сохраняет целостность команды. Предотвращает её распад

8. Специалист – имеет постоянное чувство сроков.

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

Развитие команды (4 этапа):

1. Формирование (осознание)

2. Штурм (конфликт)

3. Нормирование (кооперация)

4. Выполнение (продуктивная стадия)

Критерии сформировавшейся команды:

• Определяет ясные цели

• Открытость и свободное выражение противоположных мнений

• Поддержка и доверие

• Сотрудничество

• Успешный процесс принятия решений

• Весомые межгрупповые отношения

• Возможность индивидуального развития

40. Оценка стоимости по. Модели и методики. Модель cocomo

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

• Какие затраты необходимы для выполнения этапов?

• Сколько времени это займет?

• Какова стоимость выполнения данного этапа?

Расчеты оценки стоимости (этапы):

• Предварительные расчеты на ранней стадии для утверждения бюджета.

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

Цена продукта включает:

• Издержки производства.

• Предполагаемая прибыль.

Параметры при оценке проекта:

• Стоимость аппаратных средств.

• Расходы на командировки и обучение персонала.

• Расходы на персонал.

• Расходы на вспомогательный персонал.

• Расходы на компьютерные сети и связь.

• Централизованные услуги.

• Социальное обеспечение и выплаты служащим (пенсии, страховки).

Факторы, влияющие на стоимость ПО:

• Возможности рынка ПО.

• Непредвиденные факторы.

• Условия контракта.

• Изменение требований.

• Финансовая стабильность.

Оценка продукта основана на тех. показателях продукта. Показателей 2 вида:

1. Показатели размера (количество строк, LOC*чел./мес. и т.д.)

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

Проблема всех методов оценки стоимости ПО - низкая точность. Выделим методы:

1. Алгоритмическое моделирование себестоимости - анализ ранее произведенных проектов. Определяется зависимость от количественных показателей.

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

3. Оценки по аналогии.

Закон Паркинсона:

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

4. Назначение цены с целью выиграть контракт (price to win).

Оценка может выполняться двумя способами:

1. Нисходящий - рассматривается функциональность в целом и далее на низком уровне.

2. Восходящий - сначала оценивается системные компоненты а потом вся система.

Модель COCOMO использует простую форму регрессии с параметрами, собранными по статистике. Первая версия опубликована в 1981 году. В 1997 - вторая версия. Доработана и опубликована в 2000 году. Состоит из 3 последовательно детализуемых форм:

1. Базовая - на этапе выработки спецификации.

2. Расширенная - после определения требований к ПО.

3. Углубленная - после окончания проектирования ПО.

В общем виде уравнения имеют вид:

, где

E - затраты труда на проект в чел./мес.

S - размер кода (скорректированный)

EAF - фактор уточнения затрат. В базовой модели EAF = 1.

a, b - коэффициенты, зависящие от вида продукта.