Бизнес процессы компании по разработке программного обеспечения

В данной статье рассмотрен анализ текущей реализации бизнес-процессов компании, занимающейся разработкой программного обеспечения.

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

Каждой компании для успешной конкуренции на современном быстроменяющемся рынке услуг в целом и разработке программного обеспечения в частности необходимо постоянно совершенствовать бизнес-процессы. Данная идея лежит в основе японской философии и практики кайдзен. Первым шагом на пути совершенствования является описание процессов «КАК ЕСТЬ».

Целью данной работы является анализ текущей реализации бизнес-процессов компании, занимающейся разработкой программного обеспечения.

Группа компаний CSN (Communication Service Network) включает три юридических лица: ООО «ИнСистема» (адрес: 308034, г. Белгород, ул. Академическая, 23 А, оф. 9), ООО «Связь-Сервис-Сети» (адрес: 308034, г. Белгород, ул. Академическая, 23 А, оф. 9), ООО «ИнфоСтудия» (адрес: 308034, г. Белгород, ул. Академическая, 23 А, оф. 9). Объектом рассмотрения является компания ООО «Связь-Сервис-Сети».

ООО «Связь-Сервис-Сети» специализируется на разработке и внедрении прикладных программных решений на платформе 1С-Битрикс, в том числе интернет-магазинов, систем биллинга, корпоративных сайтов, корпоративных порталов [3].

Основной вид деятельности компании – оказание услуг по разработке и внедрению прикладных программных решений на платформе 1С-Битрикс.

Основная цель деятельности компании – извлечение прибыли.

Виды услуг, оказываемые компанией ООО «Связь-Сервис-Сети»:

создание сайтов (проектирование интерфейса, современный дизайн, адаптивная верстка под мобильные устройства, программирование и техническую поддержку);

разработка Интернет-магазинов на платформе IC-Битрикс: Управление сайтом;

внедрение корпоративных порталов Битрикс24 (необходимая настройка, необходимый функционал, доработка модулей под специфику

бизнеса, обучение сотрудников работе с порталом);

организация IP-телефонии;

хостинг (размещение файлов, программных модулей и других компонентов сайтов на серверах Исполнителя, размещение записей доменных зон Абонента на DNS серверах, DNS-хостинг, размещение почтового сервера и почтовых ящиков, размещение баз данных абонента в формате MySQL, ежедневное резервное копирование всей информации, техническая поддержка);

обучение Битрикс [3].

Для достижения уставных целей компания ООО «Связь-Сервис-Сети», в соответствии с действующим законодательством, имеет право:

производить на всей территории Российской Федерации и за рубежом необходимые для этого операции;

самостоятельно осуществлять внешнеэкономическую деятельность и импортно-экспортные сделки;

реализовать услуги по ценам и тарифам на договорной основе, а в случаях, предусмотренных законодательством – по государственным регулируемым ценам;

производить расчеты по обязательствам и сделкам общества в безналичном порядке через учреждения банков, и наличными деньгами, в том числе и при расчетах на внешнеэкономическом рынке.

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

К основным преимуществам услуг компании ООО «Связь-Сервис­Сети» относятся следующие:

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

Высокая степень обученности сотрудников.

Использование современных программных продуктов. В качестве платформы для IT-решений используется продукты «1С-Битрикс» – отечественного лидера разработок в ряду систем управления веб-ресурсами и корпоративными порталами.

Статус Золотого Сертифицированного партнёра «1С-Битрикс», что гарантирует Клиентам качество реализованных проектов, а также свидетельствует о комплексном и систематическом подходе к обучению и сертификации своих специалистов.

Использование технологии разработки «Скрам» (SCRUM), благодаря которой максимально эффективно распределяется потенциал команды разработчиков. Благодаря этому клиент быстро получает первую версию продукта, готовую для внесения изменений в проект и техническое задание «на ходу» и полностью адаптированную для последующей модернизации и расширения функционала с минимальными финансовыми и временными рисками.

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

Продвижение услуг производится методом интернет-рекламы и личных продаж. Привлечение новых клиентов и создание своей клиентской базы осуществляется при помощи менеджеров. Менеджеры компании, используя различные справочники, периодически обзванивают организации, участвуют в тематических выставках и конференциях. Контакт с потенциальными и возможными клиентами осуществляется при помощи email-рассылки и индивидуальных дистанционных и личных консультаций.

Организационная структура основной компании ООО «Связь-Сервис­Сети» группы компаний построена по иерархичному принципу. Возглавляет компанию генеральный директор, которому подчиняются секретарь, бухгалтер, специалист по кадровому делопроизводству и структурные подразделения: отдел по работе с клиентами, отдел разработки, отдел сопровождения и отдел обучения.

Классификация бизнес-процессов компании:

управляющие процессы (стратегическое управление, управление финансами, управление информационной безопасностью);

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

обеспечивающие (управление учетом, управление ИТ поддержкой, управление административно-хозяйственной деятельностью, управление персоналом).

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

В ходе проведения анализа предметной области представим диаграммы бизнес-процессов компании «КАК ЕСТЬ», для чего применены CASE средства структурного анализа BPwin в виде нотации IDEF0, IDEF3. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, обмениваясь информационными и материальными потоками с помощью людских и производственных ресурсов, потребляемых каждой работой [1]. IDEF3 позволяет описать взаимодействия информационных потоков, последовательности выполнения работ и сценариев взаимодействия модель дополняют диаграммами еще одной методологии [2]. Так в IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.

Реализация моделей в нотациях IDEF0, IDEF3 находит отражение в контекстных диаграммах, которые представлены на рисунках 1-5.

Рисунок 1 – Оказание услуг по веб-разработке

На контекстной диаграмме А0 рисунка 1 отражены основные входные потоки, выходные данные, ресурсы и управление. Управляющими воздействиями на деятельность компании являются Закон о защите прав потребителей и Устав.

Ресурсами являются отдел разработки, отдел по работе с клиентами, отдел сопровождения, отдел обучения и заказчик.

Входными потоками являются заявка, счет на оплату, ПО и лицензии (отображаются слева).

В свою очередь, выходные потоки – Акт о выполненной работе/платежное поручение, уведомление клиенту о невозможности выполнить заявку, выполненная работа, уведомление заказчика о невозможности подписания договора (отображаются справа).

Далее выполним детализацию подпроцессов процесса «Оказание услуг по веб-разработке», протекающих в ООО «Связь-Сервис-Сети». К ним относятся: планирование работ, выполнение работ и приемка результата.

Рисунок 2 – Оказание услуг по веб-разработке

При обращении клиента в компанию ООО «Связь-Сервис-Сети» производится процесс – анализ заявки клиента. В результате анализа заявки принимается решение возможности или невозможности заключения договора. Если заключение договора возможно — происходит согласование основных условий и подписание. Затем формируется Устав проекта.

Далее более детально рассмотрим процесс – «Планирование работ», представленный на рисунке 3.

Рисунок 3 – Планирование работ

Данный процесс представлен с учётом нотации IDEF3, который состоит из ряда этапов, с применением логических перекрестков Эксклюзивное ИЛИ. Применение логических перекрёстков ИЛИ означает исполнения одного из процессов, связанных с анализом заявки клиента.

На рисунке 4 представлен бизнес-процесс «Выполнение работ».

Рисунок 4 – Выполнение работ

В ходе данного процесса составляется календарно-сетевой график, закрепление ответственных исполнителей, подготовка технического задания и выполнение работ. Также присутствует логический перекресток Эксклюзивное ИЛИ, он означает исполнение одного из процессов, связанных с выполнением работ.

Далее выполняется процесс «Приемка результата», представленный на рисунке 5.

Рисунок 5 – Приемка результата

Данный процесс также представлен в нотации IDEF3. На данном процессе вначале выполняется представление результатов заказчику. Далее с помощью логического перекрестка Эксклюзивное ИЛИ выполняется одно из действий, связанных с результатом приемки. Если работа принята, выполняется обучение специалистов заказчика. Далее выполняется заключение договора на сопровождение, если сопровождение нужно, если нет – подписание закрывающих документов. Далее заполняется акт о выполненной работе.

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

Список использованных источников:

IDEF0 [Электронный ресурс]. – Режим доступа URL:

https://ru.wikipedia.org/wiki/IDEF0 (дата обращения 09.12.2020)

IDEF3 [Электронный ресурс]. – Режим доступа URL:

https://ru.wikipedia.org/wiki/IDEF3 (дата обращения 09.12.2020)

ООО «СВЯЗЬ-СЕРВИС-СЕТИ» хостинг [Электронный ресурс]. – Режим доступа URL: https://ООО «Связь-Сервис-Сети».ru/hostmg/ (дата обращения 03.12.2020)

Обзор процесса разработки программного обеспечения

Введение

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

Я работаю в IT последние 15 лет, хотя программированием начал заниматься значительно раньше. Основное направление моей деятельности как системного архитектора была организация разработки программ, разработка концепций и верхнеуровневой архитектуры и контроль выполнения концепции на протяжении проекта. Кроме управления разработкой ПО и создания архитектуры, я время от времени занимаюсь решением сложных технических проблем и написанием некоторых критически важных участков кода, где необходимо не только знание самого языка и среды разработки, но и их внутренней организации, иногда преподносящей неприятные сюрпризы.

Проекты, над которыми я работаю, чаще всего связаны с разработкой заказного или инвестиционного программного обеспечения. Также мне приходилось работать с встроенным ПО и программами, ориентированными на выпуск «хитов» (что, с лёгкой руки Джоэля Спольски, я называю далее игровым ПО, хотя на самом деле некоторые игровые проекты ближе к инвестиционным).

Заказное программное обеспечение может быть предназначено для внутреннего или внешнего заказчика. Эксклюзивные права на разработанную систему получает заказчик, и работа над развитием системы в дальнейшем может быть передана другому исполнителю.

В отличие от заказного ПО, работа над инвестиционным программным обеспечением ведётся самим исполнителем на деньги внутреннего или внешнего инвестора. Как правило, права на код системы остаётся у исполнителя, что стимулирует непрерывную работу по улучшению своего продукта и последовательный выпуск версий с более развитой функциональностью.

Встроенное программное обеспечение поставляется вместе с аппаратной частью и, грубо говоря, не подлежит сопровождению, поскольку отзыв партии устройств производителем – дело очень затратное и потому исключительное.

Разработка игровых хитов также практически не содержит фазы сопровождения. Кроме того, пользователи игровых программ, даже столкнувшись с ошибкой в игре, очень редко загружают обновлённую версию. Поэтому разработка игр, как правило, имеет свою экономику и свой процесс разработки.

Нашими заказчиками являются органы власти, крупные государственные и коммерческие организации и, конечно, мы сами. Поэтому в смысле заказного ПО в нашем процессе часто присутствует некоторая разница между процессами разработки продуктов для внутреннего и для внешнего заказчиков. Некоторые нюансы я укажу в этой статье. Уровень формализации отношений с заказчиком у нас варьируется от проекта к проекту очень широко. В целом, чем больше бюджет проекта, тем выше формальность. Государственный заказчик или крупные коммерческие предприятия (особенно с государственным участием) обычно имеют законодательные ограничения на формирование, размещение заказа и приёмку результатов работ. Ещё одним ограничением крупных организаций является тот факт, что их персонал, являющийся источником требований и основным пользователем наших систем, имеет очень ограниченную доступность для исполнителей, хотя бы вследствие своей занятости. Однако для небольших организаций уровень формализации падает и иногда уходит в противоположную крайность, где возникает недостаточный уровень ответственности заказчика в рамках проекта.

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика».

В качестве примера работы над инвестиционным проектом я могу привести разработку комплексной системы безопасности, которую мы создавали как «коробочный» продукт. Под моим руководством было выпущено последовательно четыре версии этой системы, пользователями которой стали самые разные коммерческие и государственные организации, включая мэрию Москвы, АФК «Система», банки, бизнес-центры и, конечно, наш собственный офис. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок и пережить сложные времена кризиса. Опыт работы над этим и ещё несколькими инвестиционными проектами тоже был учтён при формировании используемого мной процесса разработки.

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

Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.

Процесс разработки заказного ПО

Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

Рисунок 1. Процесс разработки заказного программного обеспечения.

Работа над проектом начинается с подготовительного этапа. Цель этапа состоит в том, чтобы на основе предложений заказчика создать некоторую концепцию будущей системы и, отталкиваясь от этой концепции, провести оценку востребованности и реализуемости проекта. Если решение о привлечении исполнителя принимается заказчиком на конкурсной основе, то предварительный этап фактически является стадией подготовки потенциального исполнителя к конкурсу, включая формирование необходимой документации.

Не нужно тратить время и ресурсы на проект, чья концепция признаётся невостребованной или нереализуемой. Такой проект должен быть завершён. В ряде случаев требуется некоторая итеративная работа с заказчиком по коррекции концепции проекта, пока либо не будет достигнут приемлемый баланс требований заказчика и затрат исполнителя, либо не будет принято решение о сворачивании работ.

Проект, концепция которого выглядит приемлемой для реализации, выходит на этап разработки требований. На этом этапе исполнитель должен сформировать перечень всех явных и скрытых потребностей заказчика. Часто оказывается, что заказчик либо не определился со своими потребностями, либо его потребности вступают в противоречие между собой, с возможностями заказчика или с возможностями исполнителя. Целями этапа являются выявление всех скрытых потребностей, решение конфликтов требований, формирование целостного технического решения и анализ реализуемости подготовленного решения.

Иногда уточнение требований приводит к пересмотру концепции проекта. Если после уточнения всех требований не удаётся найти приемлемого технического решения, проект приходится сворачивать либо откладывать на некоторое время в ожидании более приемлемых обстоятельств.

Если техническое решение найдено, исполнитель приступает к разработке архитектуры будущей системы. Цель этапа – определение верхнеуровневой логической и физической архитектуры, полностью покрывающей все требования заказчика. При разработке архитектуры проводится рецензирование и уточнение концепции, требований и предварительного технического решения, что даёт возможность предупредить наиболее опасные риски.

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

Если баланс был найден, и удалось создать приемлемую архитектуру системы, исполнитель может переходить к реализации и поставке системы. Реализация может проходить в один или несколько этапов. Для небольших проектов одноэтапная поставка всего функционала системы может быть вполне приемлемой. Однако, чем больше проект, тем выше зависимости подсистем внутри создаваемой системы. В этих условиях следует делить реализацию на несколько этапов так, чтобы в конце каждого этапа команда разработчиков имела готовый к поставке продукт. При этом самый важный, фундаментальный функционал должен разрабатываться на ранних этапах, а надстройки, работающие поверх этих основных компонентов, следует реализовывать позднее. В таком случае наиболее опасные для системы ошибки будут исправлены на первых этапах, и риск того, что прикладная функциональность системы будет основана на нестабильной основе, будет значительно снижен.
После поставки полностью завершённой системы проект заказного ПО обычно переходит к этапу опытной эксплуатации. Цель этого этапа заключается в проверке качества работы разработанной системы в реальных условиях эксплуатации. Как правило, на этом этапе исполнитель совместно с заказчиком проводит измерение количественных метрик, позволяющих определить качество созданной системы. В первую очередь проверяются функциональные характеристики качества, затем – нефункциональные. При наличии несоответствий исполнитель корректирует код системы.

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

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

Любой проект в конечном счёте приходит к своему завершению. Этап прекращения проекта имеет целью анализ результатов, внесение изменений в процесс разработки на основе полученного опыта и пополнение базы знаний разработчиков новыми эффективными решениями и предостережениями, а также новыми готовыми компонентами, которые можно будет использовать в следующих проектах.

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

Процесс разработки инвестиционного ПО

Процесс разработки инвестиционного ПО отличается тем, что параллельно может идти работа сразу над несколькими версиями продукта: пока первая версия сопровождается, вторая уже реализуется, а для третьей формулируются требования. Процесс показан на рисунке 2.

Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

Обратите внимание на момент начала работ над следующей версией продукта. Этот момент настаёт, как только пройден этап создания архитектуры текущей разрабатываемой версии. До этого на этапах формирования требований и создания архитектуры, как правило, идёт обсуждение, какие функции следует реализовать в текущей версии, а какие перенести на будущее. И только тогда, когда требования к текущей версии сформулированы, рецензированы и подтверждены архитектурой системы, имеет смысл думать о следующей версии.

Кроме того, после разработки архитектуры, как правило, у аналитиков и архитекторов проекта появляется некоторая свобода действий, поскольку на этапах поставки основная нагрузка ложится на программистов. Эту свободу можно использовать для проработки концепции и требований для следующей версии.

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

Говоря о процессе разработки инвестиционного ПО, нужно понимать, что работа над несколькими версиями имеет ряд явных и скрытых взаимозависимостей между параллельными ветками процесса.

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

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

Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.

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

В-четвёртых, имеет место обратная ситуация, когда персонал, работающий над одной версией, ничего не знает о том, какие решения принимаются в рамках работ над другой версией. Частично проблема снимается, если исправления всей документации и кода будут немедленно распространяться на все более поздние версии, о чём я говорил выше. Но одними исправлениями дело не должно ограничиваться. Нужно, чтобы команда, работающая над одной версией, понимала, почему были приняты те или иные решения при работе над другой версией. Для этого нужна база знаний для разработчиков – специальная информационная система, в которой должны описываться все проблемы, с которыми столкнулись разработчики при работе над той или иной версией продукта, и способы решения этих проблем. База знаний должна рассылать всем участникам проекта уведомления о поступлении новых записей. Нельзя пускать на самотёк взаимодействие двух команд, работающих над разными версиями одного продукта.

Процесс разработки встроенного ПО

Как уже отмечалось выше, встроенное ПО отличается от заказного тем, что его крайне сложно сопровождать.

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

Таким образом, при разработке встроенного ПО возникает сразу несколько важных ограничений.

Во-первых, поставка выполняется в рамках только одного этапа: никто не будет встраивать в устройства наполовину работающую программу.

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр

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

Ещё одним фактором, выделяющим производство игр, является тот факт, что игра интересна пользователю либо пока он не прошёл последний уровень, либо пока у него не произошла фатальная ошибка. Это значит, что вторую версию игры он не будет покупать или даже бесплатно загружать только ради исправлений нескольких ошибок.

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

Поставка игрового программного обеспечения происходит в рамках одного единственного этапа. Даже если сначала создаётся некое ядро, «движок» игровой системы, его работу невозможно проверить без реализации всего функционала системы.

Для игрового ПО нет этапов опытной эксплуатации и вывода из эксплуатации. Игры сразу поступают в продажу, а после использования просто удаляются пользователем по мере утраты интереса к ним.

Заключение

В рамках статьи я попытался сделать обзор «верхнего уровня» процесса разработки прикладного программного обеспечения. Каждый этап процесса, безусловно, нуждается в отдельном обсуждении с обязательным учётом особенностей разрабатываемых программных средств.

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

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

Создание программных продуктов – головная боль для многих руководителей. Нужно правильно поставить задачу разработчикам, знать, как их контролировать, всегда иметь возможность оперативно внести изменения или «откатить» релиз, если в продукте нашли критическую ошибку.

Генрик Мкртчян — сооснователь и генеральный директор агентства веб-разработки «Кодеры», рассказал, как под ключ организовать процесс разработки в компании: от постановки задач до релиза продукта.

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

Команда сможет решать вопросы «на ходу», подстраиваться под рынок и менять требования в моменте. Результат, который вы получите «на выходе», может сильно отличаться от предполагаемого. 

Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.

2. Определяем роли и состав команды

Решив, по какой методологии вы будете делать проект, легче понять, кого набирать в команду и как делегировать задачи. Определите, какие специалисты нужны под проект. Основную экспертизу держите внутри компании, а «руки» можно подключить и на аутсорс.

Классический отдел разработки состоит из следующих сотрудников:

• менеджер проекта: контролирует рабочий процесс, дедлайны, оптимизирует работу сотрудников;
• архитектор: определяет стек технологий, проектирует общую инфраструктуру проекта, его основные компоненты, модули и сервисы;

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

• системный администратор: осуществляет бесперебойную работу серверов, настраивает площадки для разработчиков и обеспечивает техническую инфраструктуру.

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

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

Опросите конечных пользователей, чтобы выявить их потребности и получить максимально реалистичный прототип продукта. Такое исследование нужно провести «на берегу», до начала рабочих действий по проекту, чтобы конечный продукт был жизнеспособен и чтобы сделать продукт под запрос, а не наоборот.

Уделите внимание техническому заданию. ТЗ – гарант, что вы не потратите время зря, не переплатите и получите нужный результат. Кроме того, оно обеспечивает техническое развитие продукта и поможет:

• оценить задачу по бюджету, срокам и объему человеко-часов;
• упростить сдачу-приемку проекта;
• объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».

4. Обеспечиваем команду техническими инструментами

За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы. 

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

Убедитесь, что у всех членов команды имеется доступ к инструментам разработки и рабочему окружению.

Учитывайте, в каких условиях будет работать продукт. Среда разработки должна быть максимально приближена к боевой.

Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения

5. Планируем работу команды

Постройте график реализации проекта, по которому будет работать вся команда. Распишите сроки по каждой задаче и определите финальную дату готовности проекта.

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

Здесь же декомпозируйте по задачам техническое задание. Разбейте его на небольшие задачи и распределите трудовые ресурсы так, чтобы каждый сотрудник был полностью загружен задачами.

Лучше всего рассматривать структуру команды в компаниях от 10 человек. В ней, как правило, также есть и второстепенные функции (бухгалтерия, юристы, клининг и т. д.). Их чаще всего отдают на аутсорс. Кроме того, в компании должны быть продавцы, маркетологи и HR.

На начальном этапе директор может справляться с частью функций сам (продавать, продвигать услуги, искать и нанимать сотрудников). Такая ситуация характерна, прежде всего, для стартапов, где команда может брать на себя все функции сразу. Так как это недавно запущенный проект, и его цель – окупить инвестиции и получить прибыль в максимально короткие сроки, директор может быть и продавцом, и разработчиком, и курьером. Однако чаще всего там уже есть деление на сферы ответственности. Например, в команде LICA (разрабатывают ИТ-продукт по подбору станков и тканей для текстильной промышленности), которую я курирую на программе Moove, кто-то взял на себя роль CEO, кто-то — CTO, а кто-то занялся продажами и общением с клиентами.

Ребята сами поделили сферы ответственности, исходя из компетенций и собственного опыта. Попытки перекинуть непрофильные задачи на других членов команды приводили к конфликтам (так, например, обзвон базы клиентов для технического специалиста был проблемой, он отказывался это делать). В итоге пришли к тому, что у каждого есть своя сфера ответственности и задачи изначально делятся по этим сферам.

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

Этапы создания ПО

• создание концепции/ТЗ;
• проработка архитектуры программного обеспечения;
• создание технической документации;
• реализация проекта;
• тестирование и приемка;
• внедрение;
• техническая поддержка.

На каждом этапе должен быть свой отдел со своими задачами:

• проектный офис;
• отдел проектирования программного обеспечения;
• отдел тестирования и документирования;
• отдел разработки;
• отдел внедрения и сопровождения.

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

• менеджеры проекта;
• программисты;
• тестировщики;
• разработчики документации;
• инженерные психологи;
• технологи по разработке ПО.

Вспомогательная группа — это специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:

• группа менеджмента и маркетинга продукта;
• специалисты по технической поддержке ПО;
• администраторы бета-тестирования.

По сути в любой команде, занимающейся разработкой продукта, можно выделить следующие роли в команде:

Developer

Занимается производством программных продуктов.

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

1. По разделению ответственности:

• Backend developer — разработчик программно-аппаратной части комплексного ПО;
• Frontend developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

2. По платформам:

• Web;
• Mobile;
• Server-Side;
• и так далее.

User Experience Designer (UX)

Занимается производством карт пользовательского опыта.

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

Эту роль ошибочно путают, а порою и совмещают с ролью UI Designer. UX и UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про аналитику и систематизацию, чем про эргономику и эстетику.

User Interface Designer (UI)

Занимается производством графической составляющей интерфейсов.

Этот человек разрабатывает визуальную часть пользовательского интерфейса. Основными целями работы UI дизайнера являются: интуитивность восприятия, простота, юзабилити и эстетика интерфейса ПО.

Quality Assurance (QA)

Занимается проверкой результата.

QA занимается тестированием всего, как бы странно это ни звучало.

Системный подход специалиста QA позволяет тестировать как программный код, так и продуманность карт пользовательского опыта.

Human Resource (HR)

Занимается первичным подбором кандидатов.

Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.

Team Leader

Отвечает за работу группы специалистов.

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

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

Tech Leader

Отвечает за грамотный аргументированный выбор технических решений:

1. Ответственный выбор стороннего ПО для проекта;
2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
3. Определение технических особенностей в процессах производства.

Scrum Master

Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.

Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).

Project Manager (PjM)

Отвечает за старт, ведение и сдачу проектных работ.

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.

Архитектор (Architect)

Ключевая обязанность архитектора — проектирование архитектуры ПО, т. е. принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.

Бизнес Аналитик (Business Analyst)

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

Системный аналитик (System Analyst)

Занимается, в основном, анализом данных и принятием решений о том, как будет работать система, какие методы будут использоваться, а также написанием основных технических документов (техническое задание или ТЗ, спецификации). Важная часть работы — функциональный анализ, в результате которого выделяется перечень функций, которые должна выполнять система, а также определение требований к системе.

Технический писатель (Technical writer)

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

Читайте статью в первоисточнике: tproger.ru

Без процесса не понять….

Процесс

Как мы работаем, какова последовательность наших шагов, каковы нормы и правила в поведении и работе, каков регламент отношений между членами команды, как проект взаимодействует с внешним миром и т.д.? Все это вместе мы склонны называть процессом. Его осознание, выстраивание и улучшение — основа любой эффективной групповой деятельности. Поэтому не случайно, что процесс оказался одним из основных понятий программной инженерии.

Центральным объектом изучения программной инженерии является процесс создания ПО – множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (проектных планов, документации, программного кода, тестов, пользовательской документации и пр.).

Однако на сегодняшний день не существует универсального процесса разработки ПО – набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. Будем называть это предварительное описание конкретным процессом, отличая его от плана работ, проектных спецификаций и пр. Например, в системе Microsoft Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В VSTS существуют заготовки для конкретных процессов на базе CMMI, Scrum и др.

В рамках компании возможна и полезна стандартизация всех текущих процессов, которую будем называть стандартным процессом. Последний, таким образом, оказывается некоторой базой данных, содержащей следующее:

• информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования – различных IDE, СУБД и т.д.);
• описание практик разработки – проектного менеджмента, правил работы с заказчиком и т.д.;
• шаблоны проектных документов – технических заданий, проектных спецификаций, планов тестирования и т.д. и пр.

Также возможна стандартизация процедуры разработки конкретного процесса как «вырезки» из стандартного. Основная идея стандартного процесса – курсирование внутри компании передового опыта, а также унификация средств разработки. Очень уж часто в компаниях различные департаменты и проекты сильно отличаются по зрелости процесса разработки, а также затруднено повторное использование передового опыта. Кроме того, случается, что компания использует несколько средств параллельных инструментов разработки, например, СУБД средства версионного контроля. Иногда это бывает оправдано (например, таковы требования заказчика), часто это необходимо – например, Java, .NET (большая компетентность оффшорной компании позволяет ей брать более широкий спектр заказов). Но очень часто это произвольный выбор самих разработчиков. В любом случае, такая множественность существенно затрудняет миграцию специалистов из проекта в проект, использование результатов одного проекта в другом и т.д.
Однако при организации стандартного процесса необходимо следить, чтобы стандартный процесс не оказался всего лишь формальным, бюрократическим аппаратом. Понятие стандартного процесса введено и подробно описано в подходе CMMI.

Необходимо отметить, что наличие стандартного процесса свидетельствует о наличии «единой воли» в организации, существующей именно на уровне процесса. На уровне продаж, бухгалтерии и др. привычных для всех компаний процессов и активов единство осуществить не трудно. А вот на уровне процессов разработки очень часто каждый проект оказывается сам по себе (особенно в оффшорных проектах) – «текучка» захватывает и изолирует проекты друг от друга очень прочно.

Совершенствование процесса

Определение. Совершенствование процесса (software process improvement) – это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки. Причины актуальности этой деятельности для компаний-производителей ПО заключается в следующем.

1. Происходит быстрая смена технологий разработки ПО, требуются изучение и внедрение новых средcтв разработки.
2. Наблюдается быстрый рост компаний и их выход на новые рынки, что требует новой организации работ.
3. Имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки.

Что и каким образом можно улучшать.

1. Переход на новые средства разработки, языки программирования и т.д.
2. Улучшение отдельных управленческих и инженерных практик – тестирования, управления требованиями и пр.
3. Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI).
4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.).

Мы отделили п. 3 от п. 4 потому, что на практике 4 далеко не всегда означает действительную созидательную работу по улучшению процессов разработки ПО, а часто сводится к поддержанию соответствующего документооборота, необходимого для получения сертификации. Сертификат потом используется как средство, козырь в борьбе за заказы.

Главная трудность реального совершенствования процессов в компании заключается в том, что она при этом должна работать и создавать ПО, ее нельзя «закрыть на учет».

Отсюда вытекает идея непрерывного улучшения процесса, так сказать, малыми порциями, чтобы не так болезненно. Это тем более разумно, что новые технологии разработки, появляющиеся на рынке, а также развитие уже существующих нужно постоянно отслеживать. Эта стратегия, в частности, отражена в стандарте совершенcтвования процессов разработки CMMI.

Pull/Push стратегии. В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО) существуют две следующие парадигмы.

1. Organization pull – инновации нацелены на решение конкретных проблем компании.
2. Technology push – широкомасштабное внедрение инноваций из стратегических соображений. Вместо конкретных проблем, которые будут решены после внедрения инновации, в этом случае рассматриваются показатели компании (эффективность, производительность, годовой оборот средств, увеличение стоимости акций публичной компании), которые будут увеличены, улучшены после внедрения инновации. При этом предполагается, что будут автоматически решены многочисленные частные проблемы организации, в том числе и те, о которых в данный момент ничего не известно.

Пример использования стратегии organization pull – внедрение новых средств тестирования в ситуации, когда высоки требования по качеству в проекте, либо когда качество программной системы не удовлетворяет заказчика.

Пример использования стратегии technology push – переход компании со средств структурной разработки на объектно-ориентрованные. Еще один пример использования той же стратегии – внедрение стандартов качества ISO 9000 или CMMI. В обоих этих случаях компания не решает какую-то одну проблему или ряд проблем – она хочет радикально изменить ситуацию, выйти на новые рубежи и т.д.

Проблемы применения стратегии technology push в том, что требуется глобальная перестройка процесса. Но компанию нельзя «закрыть на реконструкцию» – за это время положение на рынке может оказаться занято конкурентами, акции компании могут упасть и т.д. Таким образом, внедрение инноваций, как правило, происходит параллельно с обычной деятельностью компании, поэтапно, что в случае с technology push сопряжено с большими трудностями и рисками.

Использование стратегии organization pull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technology push.

Необходимо также отметить, что существуют проблемы, которые невозможно устранить точечными переделками процесса, то есть необходимо применять стратегию technology push. Приведем в качестве примера зашедший в тупик процесс сопровождения и развития семейства программных продуктов – компания терпит большие убытки, сопровождая уже поставленные продукты, инструментальные средства проекта безнадежно устарели и находятся в плачевном состоянии, менеджмент расстроен, все попытки руководства изменить процесс наталкиваются на непонимание коллектива, ссоры и конфликты. Возможно, что в таком случае без «революции» не обойтись.

Еще одно различие обеих стратегий: в случае с organization pull, как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technology push.

Классические модели процесса

Определение модели процесса. Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса (process model).

Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить. Однако, сама идея модели процесса является одной из самых ранних в программной инженерии, когда считалось, что удачная модель – самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структуру команды и т.д.), которые должны быть определены согласовано друг с другом. И стали развиваться интегральные методологии разработки. Тем не менее существует несколько классических моделей процесса, которые полезны на практике и которые будут рассмотрены ниже.

Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.

Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.

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

Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта, кодирование – программистом, тестирование – тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди.

В рамках одной фазы может выполняться много различных видов деятельности. Кроме того, один вид деятельности может выполняться на разных фазах – например, тестирование: на фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при разработке и перед сдачей производить, собственно, само тестирование. На настоящий момент для сложного программного обеспечения используются многомерные модели процесса, в которых отделение фаз от видов деятельности существенно облегчает управление разработкой ПО.

Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM – ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы.

Водопадная модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования.

Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование – см.
рис.
2.1.

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

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

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

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

Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта модель также часто используется в оффшорных проектах^{1От английского offshore – вне берега, в расширенном толковании – вне одной страны.}
с почасовой оплатой труда. Водопадная модель вошла в качестве составной части в другие модели и методологии, например, в MSF.

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

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

Каждый виток имеет следующую структуру (секторы):

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

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

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

Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль, – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО.

Компания, разрабатывающая программное обеспечение

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

Содержание

• 1 Типы
• 2 Общие роли в компании-разработчике программного обеспечения
• 3 Структура
• 4 Методологии
• 5 Жизненный цикл продукта
• 6 Системы и процедуры
  • 6.1 Бизнес-аналитики
  • 6.2 Программисты
  • 6.3 Тестировщики
  • 6.4 Менеджеры проектов / продуктов
• 7 Аудиты эффективности
• 8 См. также
• 9 Ссылки

Типы

Существует несколько различных типов компаний-разработчиков программного обеспечения:

• Крупные и известные компании, производящие готовые коммерческие продукты (COTS), такие как Microsoft, SAP AG, Oracle Corporation, HP, Adobe Systems и Red Hat
• Мелкие компании, которые производят индивидуальное программное обеспечение для другие компании и предприниматели
• Компании, производящие специализированное коммерческое готовое программное обеспечение, такое как Panorama, Hyperion и Siebel Systems
• Компании, производящие программное обеспечение как услуга SaaS, например Google, Facebook и LinkedIn
• Компании pr производство программных компонентов, таких как Dundas
• Application Service Provider, например Salesforce
• Компании, производящие программное обеспечение на заказ для вертикальных отраслей или определенного географического региона регионы
• Независимые поставщики программного обеспечения (ISV), которые создают, разрабатывают и продают потребительское или корпоративное программное обеспечение, которое используется конечными пользователями

Все они могут быть отнесены к одной или многие из следующего:

• договорный — когда компания-разработчик программного обеспечения получает контракт на поставку определенного программного обеспечения извне (программное обеспечение аутсорсинг )
• разработка продукта — когда она производит готовое к использованию упакованное программное обеспечение; Готовый коммерческий продукт

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

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

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

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

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

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

Структура

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

Типичная структура компании-разработчика программного обеспечения

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

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

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

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

Методологии

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

• водопадная модель, включая методологии управления проектами, такие как PRINCE2 или PMBoK
• гибкая разработка программного обеспечения, например Extreme Программирование и SCRUM

Существуют также некоторые методологии, которые объединяют оба, например, спиральная модель, Rational Unified Process (RUP) или MSF..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестировщики

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

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

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

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

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

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

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

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

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

См. Также

• Список крупнейших компаний-разработчиков программного обеспечения

Ссылки

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