18 Методология функциональных точек в оценке разработки
Программного обеспечения
Задача метода разбить систему на мелкие части так, чтобы они могли, быть, лучше, понимаемы, и, анализируемы, что обеспечивает более
структурированный подход для решения проблемы. Функциональные точки – это своего рода часы в качестве измерения времени или километры в качестве измерения расстояния, другими словами - это подход измерения.
Программное приложение, в сущности, определяется набором элементарных процессов. Существует два основных типа элементарных
процессов – данные в движении и данные в покое. Данные в движении описывают потоки данных из приложения вовне и извне в приложение. На концептуальном уровне анализ функциональных точек помогает определить два абстрактных уровня данных – в покое и данных в движении. В соответствии с тем, что существует 3 основных фазы проектирования: разработка, дополнительные требования и поддержка, существует по аналогии 3 типа подсчетов функциональных точек. Формула, определяющая продуктивность программного обеспечения: Продуктивность = Количество функциональных точек / количество инпутов (за период времени, с учетом качества). Маргинальные издержки определяются величиной затрат на увеличение числа функциональных точек на единицу.
Причины увеличения маргинальных издержек:
1. Сложность увеличивается с размером проекта.
2. По мере увеличения размера проекта больше количество заданий, требующее завершения.
3. По мере увеличения размера проекта больший размер команды программистов затрудняет управление.
Функциональные точки - единицы измерения проекта и они остаются постоянными в независимости от программистов или языка реализации проекта.
Деление компонентов:
RET (Record Element Type) – Элемент записи
FTR (File Type Referenced) – Ссылка на файл
DET (Data Element Type)– Элемент данных__
19. Методы организации бригад разработчиков.
С точки зрения административной, бригада - структурная производственная единица, которая может быть образована в рамках существующего структурного подразделения для выполнения определенной работы, имеющей конкретный
результат. При определении результата работы бригады может быть сформулировано частичное
техническое задание.Существуют два варианта бригад:
1) предметная область ПИ определяется в терминах программирования, то есть
задание представляется собой результат работы относящийся к программированию;
2) предметная область ПИ определяется в терминах того языка, который используется в предметной области (функционально и математическо ориентированные ППП);
В первом случае предметная область имеет вид хорошо знакомый и понятный программисту и работа предполагает техническое проектирование может выполнить программист. Бригада может быть сформирована из специалистов одного профиля
(в основном программисты).
Во втором случае работы по техническому проектированию могут быть выполнены
специалистом в предметной области. Принятое им проектное решение, вплоть до
технического проекта в дальнейшем доводится до машинной реализации
специалистом-программистом. параллельно эксплуатируется документация, по
возможности, должна разрабатываться специалистом из предметной области. В
процессе внедрения, проверка работоспособности ППП тоже проводится
специалистом из предметной области.
20 Методы взаимодействия в коллективах разработчиков.
Группа людей, объединенных для выполнения работы, сама по себе не становится самоуправляемой командой. Становление команды это процесс, включающий в себя последовательное прохождение четырех четко выраженных этапов [34].
Объединение.
Разногласия и конфликты.
Становление.
Отдача.
Замечание А.Орлова: «В англоязычной литературе названия этих этапов звучат более выразительно: 1) Forming, 2) Storming , 3) Norming, 4) Performing. Кстати, иногда добавляют еще пятый этап Reforming, который возвращает команду из последней стадии в начало :)».