Компания -разработчик программного обеспечения — это организация, принадлежащая государству или частной компании, созданная для получения прибыли, основными продуктами которой являются различные формы программного обеспечения , программные технологии, распространение и разработка программных продуктов. [1] Они составляют индустрию программного обеспечения .
Существует несколько различных типов компаний-разработчиков программного обеспечения:
Организация компании по разработке программного обеспечения — это очень специализированный тип управленческого навыка, где опытные люди могут превратить организационную проблему в уникальное преимущество. Например, распределение подкоманд в разных часовых поясах может позволить компании работать 24 часа в сутки, если команды, системы и процедуры хорошо отлажены. Хорошим примером является команда по тестированию в часовом поясе на 8 часов впереди или позади команды разработчиков, которая исправляет ошибки в программном обеспечении, найденные тестировщиками.
Профессиональная компания по разработке программного обеспечения обычно состоит как минимум из трех специализированных подгрупп:
В более крупных компаниях-разработчиках программного обеспечения применяется более узкая специализация, и довольно часто также имеются:
Менеджер компании-разработчика программного обеспечения обычно называется руководителем разработки (HOD), [2] и отчитывается перед заинтересованными сторонами . Он или она руководит подгруппами напрямую или через менеджеров/руководителей в зависимости от размера организации . Обычно наиболее оперативными являются команды численностью до 10 человек. В более крупных организациях обычно существуют две модели иерархии:
Все команды полностью независимы и работают отдельно над разными проектами. Структура довольно проста, и все сотрудники подчиняются одному человеку, что делает ситуацию достаточно ясной, однако это не является хорошим решением с точки зрения обмена знаниями и оптимального использования человеческих ресурсов.
В этой модели есть выделенные менеджеры/лидеры для каждой основной специализации, «арендующие» своих людей для конкретных проектов, возглавляемых менеджерами по продуктам/проектам, которые формально или неформально покупают людей и платят за их время. Это приводит к тому, что у каждого рядового сотрудника есть два начальника – менеджер по продукту/проекту и специализированный менеджер «ресурсов». С одной стороны, это оптимизирует использование человеческих ресурсов, с другой стороны, это может привести к конфликтам по поводу того, какой менеджер имеет приоритет в структуре.
Существует также ряд вариантов этих структур, и в ряде организаций эта структура распространена и разделена на различные департаменты и подразделения.
Компании-разработчики программного обеспечения могут использовать ряд различных методологий для создания кода. Они могут включать:
Существуют также некоторые методологии, которые объединяют оба подхода, например, спиральная модель , Rational Unified Process (RUP) [7] или MSF [8] .
Независимо от используемой методологии жизненный цикл продукта всегда состоит как минимум из трех этапов:
В идеале каждый этап занимает 30% от общего времени, а оставшиеся 10% остаются в резерве.
Диаграмма последовательности UML взаимодействия между этими группами может выглядеть следующим образом:
На каждом этапе ключевую роль играет определенная группа, однако каждый тип роли должен быть задействован на протяжении всего процесса разработки:
Компании-разработчики программного обеспечения обладают различными системами и процедурами, внедренными и работающими внутри всех подгрупп. Они включают:
Существуют также Application Lifecycle Management (ALM), которые встраивают некоторые из этих функций в один пакет и используются во всех группах. Они поставляются различными поставщиками, такими как Borland , ECM или Compuware .
Устоявшиеся компании-разработчики ПО обычно имеют некий способ измерения собственной эффективности. Обычно это делается путем определения набора ключевых показателей эффективности (KPI), таких как
Ряд организаций сосредоточены на достижении оптимального уровня Модели зрелости возможностей (CMM), где «оптимальный» не обязательно означает самый высокий. Существуют также другие системы, такие как SEMA Университета Карнеги-Меллона или определенные стандарты ISO . Небольшие компании-разработчики программного обеспечения часто используют облегченные подходы к своим процессам, формализованным или нет. Каждая организация вырабатывает свой собственный стиль, который находится где-то между полной технократией (где все определяется числами) и полной анархией (где вообще нет чисел). Какой бы путь ни выбрала организация, она рассматривает пирамиду, описывающую стоимость и риск внедрения изменений в уже начатые процессы разработки, как истинную модель управления изменениями.
