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

Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Поиск источников:  «Компания-разработчик программного обеспечения»  -  новости  · газеты  · книги  · ученый  · JSTOR ( декабрь 2007 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) Эта статья написана как личное размышление, личное эссе или аргументированное эссе , в котором излагаются личные чувства редактора Википедии или представлены оригинальные аргументы по теме. Пожалуйста, помогите улучшить его , переписав в энциклопедическом стиле . ( Май 2014 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

Типы [ править ]

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

• Есть компании, продающие доступные для использования коммерческие готовые продукты (COTS), такие как Microsoft Outlook, Word и Excel, Adobe Systems Acrobat, Illustrator и другие инструменты проектирования или приложения Google, такие как Chrome.
• Многие компании предоставляют услуги по разработке программного обеспечения и имеют структуру для разработки программного обеспечения для других компаний и предприятий.
• Компании, производящие специализированное коммерческое готовое программное обеспечение, такое как Panorama , Hyperion и Siebel Systems
• Компании, предоставляющие программное обеспечение как услугу ( SaaS ), такие как служба электронной почты Google Gmail, Voice и Maps, а также такие компании, как Salesforce и Zendesk.
• Технология, которая мобилизует социальные сети, такие как Facebook , LinkedIn , Instagram , Twitter и Parler .
• Существуют также другие типы продуктов SaaS компаний, предоставляющих услуги ИТ-инфраструктуры и облачных вычислений, такие как Amazon Web Services (AWS) , Microsoft Azure Cloud Services и услуги хостинга GoDaddy.
• API как услуга, который позволяет сторонним разработчикам взаимодействовать с программным обеспечением компании, таким как Google Geo Location API, Google Calendar API и т. Д.
• Компании, производящие программные компоненты , такие как Syncfusion , DevExpress, Telerik UI, Kendo UI и Dundas
• Поставщик службы приложений, например Salesforce
• Компании, производящие программное обеспечение на заказ для вертикальных отраслей или определенных географических регионов
• Независимые поставщики программного обеспечения (ISV), которые создают, разрабатывают и продают потребительское или корпоративное программное обеспечение , которое используется конечными пользователями.

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

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

Общие роли в компании-разработчике программного обеспечения [ править ]

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

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

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

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

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

Структура [ править ]

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

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

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

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

Методологии [ править ]

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

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

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

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

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

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

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

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

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

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

Системы и процедуры [ править ]

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

Бизнес-аналитики [ править ]

• Инструменты моделирования, такие как Sparx Systems Enterprise Architect или IBM Rational Rose

Программисты [ править ]

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

Тестеры [ править ]

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

Менеджеры проектов / продуктов [ править ]

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

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

Аудиты эффективности [ править ]

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

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

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

См. Также [ править ]

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

Ссылки [ править ]