WikiDer > Софтверная компания

Software company

А софтверная компания это компания, основной продукцией которой являются различные формы программного обеспечения, программные технологии, распространение и разработка программных продуктов.[1] Они составляют индустрия программного обеспечения.

Типы

Есть несколько разных типов софтверных компаний:

Все они могут быть отнесены к одной или нескольким из следующих категорий:[2]

  • договорная - когда компания-разработчик программного обеспечения получает контракт на поставку определенного программного обеспечения извне (программное обеспечение аутсорсинг)
  • разработка продукта - когда он производит готовое, упакованное программное обеспечение; Коммерческая готовая продукция

Общие роли в софтверной компании

Организация программного обеспечения Компания - это очень специализированный вид управленческих навыков, когда опытные люди могут превратить организационную проблему в уникальное преимущество. Например, если подгруппы распределены по разным часовые пояса может разрешить 24-часовой рабочий день компании, если команды, системы и процедуры хорошо отработаны. Хорошим примером является команда тестировщиков в часовом поясе на 8 часов впереди или отстает от команды разработчиков, которая исправляет программные ошибки найдены тестировщиками.

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

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

Структура

Менеджера компании-разработчика программного обеспечения обычно называют Head Of Development (HOD),[3] и отчитывается перед заинтересованные стороны. Он или она возглавляет подгруппы напрямую или через менеджеров / лидеров в зависимости от размера группы. организация. Обычно наиболее оперативными являются бригады до 10 человек. В более крупных организациях существуют две модели иерархии:

Типовая структура софтверной компании

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

Матричная структура

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

Также существует ряд вариантов этих структур, и ряд организации Распространите эту структуру и разделите ее на различные отделы и подразделения.

Методологии

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

Есть также несколько методологий, которые сочетают в себе оба, например спиральная модель, рациональный унифицированный процесс (RUP)[8] или же MSF.[9]

Жизненный цикл продукта

Независимо от используемой методологии, жизненный цикл продукта всегда состоит как минимум из трех этапов:

  • Дизайн - включая деловую и техническую спецификацию
  • C - сама разработка
  • Тестирование - менеджмент качества

В идеале каждый этап занимает 30% общего времени, а оставшиеся 10% являются резервом.

В UML схема последовательности взаимодействия этих групп могут выглядеть так:

Общее взаимодействие между четырьмя основными группами

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

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

Системы и процедуры

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

Бизнес-аналитики

Программисты

Тестеры

Менеджеры проектов / продуктов

Это также Управление жизненным циклом приложений (ALM), которые включают некоторые из этих функций в один пакет и используются в группах. Они поставляются от различных поставщиков, таких как Borland, ECM или Compuware.

Аудит эффективности

У хорошо зарекомендовавших себя софтверных компаний обычно есть способ измерить собственную эффективность. Обычно это делается путем определения набора ключевые показатели эффективности (KPI), например

  • Среднее количество ошибок, совершаемых разработчиком за единицу времени или исходные строки кода
  • Количество ошибок, обнаруженных тестером за цикл тестирования
  • Среднее количество циклов испытаний до Отсутствие отказов от ошибок (ZBB)
  • Среднее время цикла испытаний
  • Расчетное время выполнения задачи по сравнению с реальным временем выполнения задачи (точность планирования)
  • Количество корректировок к исходному уровню

Ряд организаций ориентированы на достижение оптимального уровня Модель зрелости возможностей (CMM), где «оптимальный» не обязательно означает наивысший. Существуют также другие системы, такие как Университет Карнеги Меллонс SEMA, или в частности ISO стандарты. Небольшие софтверные компании иногда используют менее формализованные подходы. Каждый организация вырабатывает свой собственный стиль, который находится где-то между тотальной технократией (где все определяется числами) и тотальной анархией (где чисел вообще нет). Каким бы путем ни пошла организация, они рассматривают пирамиду, описывающую стоимость и риск внесения изменений в уже начатые процессы разработки:

пирамида, показывающая риск и временные затраты на изменение

Смотрите также

Рекомендации

  1. ^ «Что такое компания-разработчик программного обеспечения сегодня?». RedMonk. 2014 г.. Получено 2 июня, 2017.
  2. ^ Программный процесс: принципы, методология и технология Автор: Жан Клод Дерниам, Бадара Али Каба, Дэвид Уэстелл, стр.166
  3. ^ Greenlit: развитие телевизионных идей, основанных на фактах и ​​реальности, от концепции до презентации стр.12
  4. ^ Управление успешными проектами с PRINCE2
  5. ^ Руководство пользователя к PMBOK Guide
  6. ^ Планирование экстремального программирования
  7. ^ Гибкое управление проектами с помощью Scrum
  8. ^ Упрощенный рациональный единый процесс: руководство по RUP для практиков
  9. ^ Microsoft Solutions Framework (MSF): Карманное руководство