WikiDer > Софтверная компания
Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) (Узнайте, как и когда удалить этот шаблон сообщения)
|
А софтверная компания это компания, основной продукцией которой являются различные формы программного обеспечения, программные технологии, распространение и разработка программных продуктов.[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 стандарты. Небольшие софтверные компании иногда используют менее формализованные подходы. Каждый организация вырабатывает свой собственный стиль, который находится где-то между тотальной технократией (где все определяется числами) и тотальной анархией (где чисел вообще нет). Каким бы путем ни пошла организация, они рассматривают пирамиду, описывающую стоимость и риск внесения изменений в уже начатые процессы разработки:
Смотрите также
Рекомендации
- ^ «Что такое компания-разработчик программного обеспечения сегодня?». RedMonk. 2014 г.. Получено 2 июня, 2017.
- ^ Программный процесс: принципы, методология и технология Автор: Жан Клод Дерниам, Бадара Али Каба, Дэвид Уэстелл, стр.166
- ^ Greenlit: развитие телевизионных идей, основанных на фактах и реальности, от концепции до презентации стр.12
- ^ Управление успешными проектами с PRINCE2
- ^ Руководство пользователя к PMBOK Guide
- ^ Планирование экстремального программирования
- ^ Гибкое управление проектами с помощью Scrum
- ^ Упрощенный рациональный единый процесс: руководство по RUP для практиков
- ^ Microsoft Solutions Framework (MSF): Карманное руководство