Софтверная компания - Software company

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

Типы

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

Крупные и известные компании, производящие коммерческая готовая продукция (COTS), например Microsoft, SAP AG, Корпорация Oracle, HP, Adobe Systems и Красная шляпа^{[нужна цитата ]}
Меньше компании которые производят индивидуальное программное обеспечение для других компаний и предпринимателей
Компании, производящие специализированное коммерческое готовое программное обеспечение, такое как Панорама, Гиперион, и Siebel Systems
Компании, производящие программное обеспечение как услугу SaaS, Такие как Google, Facebook, и LinkedIn
Компании производящие программные компоненты, Такие как Дандас
Поставщик службы приложений Такие как Salesforce
Компании производящие программное обеспечение на заказ для вертикальных отраслей или определенных географических регионов
Независимые поставщики программного обеспечения (ISV) которые создают, развивают и продают потребителю или корпоративное программное обеспечение что потребляется конечные пользователи

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

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

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

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

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

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

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

Технические писатели кто пишет все документация Такие как руководства пользователя
Специалисты по выпуску, которые отвечают за сборку всего продукта и версия программного обеспечения
Дизайнеры пользовательского опыта, которые создают архитектуру дизайна на основе бизнес-требований, исследований пользователей и опыта в удобство использования
Графические дизайнеры которые обычно несут ответственность за дизайн графический интерфейс пользователя.
Инженеры по техническому обслуживанию, которые поддерживают две, три или более линии поддержки
Консультанты несут ответственность за приведение решения в действие, особенно если требуются некоторые специальные знания. Примеры этого включают: строительство многомерные кубы в программное обеспечение для бизнес-аналитики, интеграция с существующими решениями и реализация бизнес-сценариев в управление бизнес-процессами программного обеспечения.

Структура

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

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

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

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

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

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

Методологии

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

то модель водопада, включая такие методологии управления проектами, как PRINCE2^[4] или же PMBoK^[5]
гибкая разработка программного обеспечения, Такие как Экстремальное программирование^[6] и SCRUM^[7]

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты моделирования, такие как Системы Sparx Архитектор предприятия или же IBM Рациональная роза

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

Системы контроля версий и версия программного обеспечения процедуры
Инструменты анализа кода и стандарты кодирования, подтверждено вручную или автоматически
Механизмы развертывания

Тестеры

Системы отслеживания ошибок
Автоматизация тестирования инструменты
Инструменты для тестирования производительности и стресс-тестирования

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

Управление корпоративными проектами (EPM) системы и процедуры
Управление портфелем продуктов (PPM)
Управление изменениями системы и процедуры

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

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

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

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

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

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

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

Список крупнейших софтверных компаний