Бизнес процесс разработка программного продукта

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

From Wikipedia, the free encyclopedia

In software engineering, a software development process is a process of dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.^[1]

Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.

A life-cycle «model» is sometimes considered a more general term for a category of methodologies and a software development «process» a more specific term to refer to a specific process chosen by a specific organization.^{[citation needed]} For example, there are many specific software development processes that fit the spiral life-cycle model. The field is often considered a subset of the systems development life cycle.

History[edit]

The software development methodology (also known as SDM) framework didn’t emerge until the 1960s. According to Elliott (2004), the systems development life cycle (SDLC) can be considered to be the oldest formalized methodology framework for building information systems. The main idea of the SDLC has been «to pursue the development of information systems in a very deliberate, structured and methodical way, requiring each stage of the life cycle––from the inception of the idea to delivery of the final system––to be carried out rigidly and sequentially»^[2] within the context of the framework being applied. The main target of this methodology framework in the 1960s was «to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines».^[2]

Methodologies, processes, and frameworks range from specific prescriptive steps that can be used directly by an organization in day-to-day work, to flexible frameworks that an organization uses to generate a custom set of steps tailored to the needs of a specific project or group. In some cases, a «sponsor» or «maintenance» organization distributes an official set of documents that describe the process. Specific examples include:

1970s

• Structured programming since 1969
• Cap Gemini SDM, originally from PANDATA, the first English translation was published in 1974. SDM stands for System Development Methodology

1980s

• Structured systems analysis and design method (SSADM) from 1980 onwards
• Information Requirement Analysis/Soft systems methodology

1990s

• Object-oriented programming (OOP) developed in the early 1960s and became a dominant programming approach during the mid-1990s
• Rapid application development (RAD), since 1991
• Dynamic systems development method (DSDM), since 1994
• Scrum, since 1995
• Team software process, since 1998
• Rational Unified Process (RUP), maintained by IBM since 1998
• Extreme programming, since 1999

2000s

• Agile Unified Process (AUP) maintained since 2005 by Scott Ambler
• Disciplined agile delivery (DAD) Supersedes AUP

2010s

• Scaled Agile Framework (SAFe)
• Large-Scale Scrum (LeSS)
• DevOps

It is notable that since DSDM in 1994, all of the methodologies on the above list except RUP have been agile methodologies — yet many organizations, especially governments, still use pre-agile processes (often waterfall or similar). Software process and software quality are closely interrelated; some unexpected facets and effects have been observed in practice ^[3]

Among these, another software development process has been established in open source. The adoption of these best practices known and established processes within the confines of a company is called inner source.

Prototyping[edit]

Software prototyping is about creating prototypes, i.e. incomplete versions of the software program being developed.

The basic principles are:^[1]

• Prototyping is not a standalone, complete development methodology, but rather an approach to try out particular features in the context of a full methodology (such as incremental, spiral, or rapid application development (RAD)).
• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• The client is involved throughout the development process, which increases the likelihood of client acceptance of the final implementation.
• While some prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.

A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problems, but this is true for all software methodologies.

Methodologies[edit]

Agile development[edit]

«Agile software development» refers to a group of software development frameworks based on iterative development, where requirements and solutions evolve via collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.

The Agile model also includes the following software development processes:^[4]

• Dynamic systems development method (DSDM)
• Kanban
• Scrum
• Crystal
• Atern
• Lean software development

Continuous integration[edit]

Continuous integration is the practice of merging all developer working copies to a shared mainline several times a day.^[5] Grady Booch first named and proposed CI in his 1991 method,^[6] although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

Incremental development[edit]

Various methods are acceptable for combining linear and iterative systems development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.

There are three main variants of incremental development:^[1]

1. A series of mini-Waterfalls are performed, where all phases of the Waterfall are completed for a small part of a system, before proceeding to the next increment, or
2. Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of a system, or
3. The initial software concept, requirements analysis, and design of architecture and system core are defined via Waterfall, followed by incremental implementation, which culminates in installing the final version, a working system.

Rapid application development[edit]

Rapid application development (RAD) is a software development methodology, which favors iterative development and the rapid construction of prototypes instead of large amounts of up-front planning. The «planning» of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

The rapid development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively; further development results in «a combined business requirements and technical design statement to be used for constructing new systems».^[7]

The term was first used to describe a software development process introduced by James Martin in 1991. According to Whitten (2003), it is a merger of various structured techniques, especially data-driven information technology engineering, with prototyping techniques to accelerate software systems development.^[7]

The basic principles of rapid application development are:^[1]

• Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.
• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• Aims to produce high quality systems quickly, primarily via iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques.
• Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance.
• Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.
• Generally includes joint application design (JAD), where users are intensely involved in system design, via consensus building in either structured workshops, or electronically facilitated interaction.
• Active user involvement is imperative.
• Iteratively produces production software, as opposed to a throwaway prototype.
• Produces documentation necessary to facilitate future development and maintenance.
• Standard systems analysis and design methods can be fitted into this framework.

Waterfall development[edit]

The waterfall model is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through several phases, typically:

• Requirements analysis resulting in a software requirements specification
• Software design
• Implementation
• Testing
• Integration, if there are multiple subsystems
• Deployment (or Installation)
• Maintenance

The first formal description of the method is often cited as an article published by Winston W. Royce^[8] in 1970, although Royce did not use the term «waterfall» in this article. Royce presented this model as an example of a flawed, non-working model.^[9]

The basic principles are:^[1]

• The Project is divided into sequential phases, with some overlap and splash back acceptable between phases.
• Emphasis is on planning, time schedules, target dates, budgets, and implementation of an entire system at one time.
• Tight control is maintained over the life of the project via extensive written documentation, formal reviews, and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase. Written documentation is an explicit deliverable of each phase.

The waterfall model is a traditional engineering approach applied to software engineering. A strict waterfall approach discourages revisiting and revising any prior phase once it is complete.^{[according to whom?]} This «inflexibility» in a pure waterfall model has been a source of criticism by supporters of other more «flexible» models. It has been widely blamed for several large-scale government projects running over budget, over time and sometimes failing to deliver on requirements due to the Big Design Up Front approach.^{[according to whom?]} Except when contractually required, the waterfall model has been largely superseded by more flexible and versatile methodologies developed specifically for software development.^{[according to whom?]} See Criticism of Waterfall model.

Spiral development[edit]

In 1988, Barry Boehm published a formal software system development «spiral model,» which combines some key aspects of the waterfall model and rapid prototyping methodologies, in an effort to combine advantages of top-down and bottom-up concepts. It provided emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems.

The basic principles are:^[1]

• Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
• «Each cycle involves a progression through the same sequence of steps, for each part of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individual program.»^[10]
• Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration, and (2) evaluate alternatives; Identify and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration.^[11]
• Begin each cycle with an identification of stakeholders and their «win conditions», and end each cycle with review and commitment.^[12]

Shape Up[edit]

Shape Up is a software development approach introduced by Basecamp in 2018. It is a set of principles and techniques that Basecamp developed internally to overcome the problem of projects dragging on with no clear end. Its primary target audience is remote teams. Shape Up has no estimation and velocity tracking, backlogs, or sprints, unlike Waterfall, Agile, or Scrum. Instead, those concepts are replaced with appetite, betting, and cycles. As of 2022, besides Basecamp, notable organizations that have adopted Shape Up include UserVoice and Block.^[13][14]

Cycles[edit]

Through trials and errors, Basecamp found that the ideal cycle length is 6 weeks. This 6 week period is long enough to build a meaningful feature and still short enough to induce a sense of urgency.

Shaping[edit]

Shaping is the process of preparing work before being handed over to designers and engineers. Shaped work spells out the solution’s main UI elements, identifies rabbit holes, and outlines clear scope boundaries. It is meant to be rough and to leave finer details for builders (designers and engineers) to solve, allowing the builders to exercise their creativity and make trade-offs.^[15] Shaped work is documented in the form of a pitch using an online document solution that supports commenting, allowing team members to contribute technical information asynchronously. Such comments are crucial for uncovering hidden surprises that may derail the project.

Before a cycle begins, stakeholders hold a betting table, where pitches are reviewed. For each pitch, a decision is made to either bet on it or drop it.^[16]

Appetite[edit]

The way Shape Up determines how much time is allocated to a project is diametrically opposed to other methodologies. Shape Up starts with an appetite (for example, 6 weeks) and ends with a solution design that can be delivered within this constraint. The appetite becomes a hard deadline for the project’s builders.^[17]

Building[edit]

Shape Up is a two-track system where shapers and builders work in parallel. Work that is being shaped in the current cycle may be given to designers and engineers to build in a future cycle.

Recognizing the technical uncertainties that come with building, progress is tracked using a chart that visualizes the metaphor of the hill, aptly named the hill chart. The uphill phase is where builders are still working out their approach, while the downhill is where unknowns have been eliminated. Builders proactively and asynchronously self-report progress using an interactive online hill chart on Basecamp or Jira, shifting focus from done or not-done statuses to unknown or solved problems. The use of hill chart replaces the process of reporting linear statuses in scrum or Kanban standup.^[18][19]

Advanced methodologies[edit]

Other high-level software project methodologies include:

• Behavior-driven development and business process management.^[20]
• Chaos model — The main rule always resolve the most important issue first.
• Incremental funding methodology — an iterative approach
• Lightweight methodology — a general term for methods that only have a few rules and practices
• Structured systems analysis and design method — a specific version of waterfall
• Slow programming, as part of the larger Slow Movement, emphasizes careful and gradual work without (or minimal) time pressures. Slow programming aims to avoid bugs and overly quick release schedules.
• V-Model (software development) — an extension of the waterfall model
• Unified Process (UP) is an iterative software development methodology framework, based on Unified Modeling Language (UML). UP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development: inception, elaboration, construction, and guidelines. Many tools and products exist to facilitate UP implementation. One of the more popular versions of UP is the Rational Unified Process (RUP).
• Big Bang methodology — an approach for small or undefined projects, generally consisting of little to no planning with high risk.

Process meta-models[edit]

Some «process models» are abstract descriptions for evaluating, comparing, and improving the specific process adopted by an organization.

• ISO/IEC 12207 is the international standard describing the method to select, implement, and monitor the life cycle for software.
• The Capability Maturity Model Integration (CMMI) is one of the leading models and is based on best practices. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.
• ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards have been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.
• ISO/IEC 15504 Information technology—Process assessment is also known as Software Process Improvement Capability Determination (SPICE), is a «framework for the assessment of software processes». This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitors software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.
• ISO/IEC 24744 Software Engineering—Metamodel for Development Methodologies, is a power type-based metamodel for software development methodologies.
• SPEM 2.0 by the Object Management Group.
• Soft systems methodology — a general method for improving management processes.
• Method engineering — a general method for improving information system processes.

In practice[edit]

A variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One software development methodology framework is not necessarily suitable for use by all projects. Each of the available methodology frameworks is best suited to specific kinds of projects, based on various technical, organizational, project, and team considerations.^[1]

Software development organizations implement process methodologies to ease the process of development. Sometimes, contractors may require methodologies employed, an example is the U.S. defense industry, which requires a rating based on process models to obtain contracts. The international standard for describing the method of selecting, implementing, and monitoring the life cycle for software is ISO/IEC 12207.

A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of designing software. Others apply project management techniques to designing software. Large numbers of software projects do not meet their expectations in terms of functionality, cost, or delivery schedule — see List of failed and overbudget custom software projects for some notable examples.

Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.

A particular development team may also agree to program environment details, such as which integrated development environment is used one or more dominant programming paradigms, programming style rules, or choice of specific software libraries or software frameworks. These details are generally not dictated by the choice of model or general methodology.

See also[edit]

• Systems development life cycle
• Computer-aided software engineering (some of these tools support specific methodologies)
• List of software development philosophies
• Outline of software engineering
• OpenUP
• Project management
• Software development
• Software development effort estimation
• Software release life cycle
• Top-down and bottom-up design#Computer science

References[edit]

External links[edit]

• Selecting a development approach at cms.hhs.gov.
• Gerhard Fischer, «The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design», 2001
• Subway map of agile practices at Agile Alliance

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

Ключевые слова: бизнес-процесс, компания, программное обеспечение, нотация, 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)

Создание и поддержка программ и приложений

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

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

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

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

Содержание

• 1 Методологии
• 2 Действия по разработке программного обеспечения
  • 2.1 Выявление потребности
  • 2.2 Процесс планирования
  • 2.3 Проектирование
  • 2.4 Внедрение, тестирование и документирование
  • 2.5 Развертывание и обслуживание
• 3 Подтемы
  • 3.1 Просмотр модели
  • 3.2 Моделирование бизнес-процессов и данных
  • 3.3 Компьютерная разработка программного обеспечения
  • 3.4 Интегрированная среда разработки
  • 3.5 Язык моделирования
  • 3.6 Парадигма программирования
  • 3.7 Повторное использование программного обеспечения
• 4 См. Также
  • 4.1 Роли и отрасль
  • 4.2 Конкретные приложения
• 5 Ссылки
• 6 Дополнительная литература

Методологии

A процесс разработки программного обеспечения (также известный как методология разработки программного обеспечения, модель или жизненный цикл) — это структура, которая используется для структуры, планировать и контролировать процесс разработки информационных систем. За прошедшие годы появилось множество таких структур, каждая из которых имеет свои сильные и слабые стороны. Существует несколько различных подходов к разработке программного обеспечения: одни используют более структурированный инженерный подход к разработке программного обеспечения, тогда как другие могут использовать более постепенный подход, при котором программное обеспечение развивается по мере его разработки по частям. Одна методология разработки системы не обязательно подходит для использования во всех проектах. Каждая из доступных методологий лучше всего подходит для конкретных типов проектов, основанных на различных технических, организационных, проектных и групповых соображениях.

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

• Анализ проблема
• Исследование рынка
• Сбор требований к предлагаемому программному обеспечению
• Разработка плана или дизайна программного обеспечения
• Внедрение (кодирование) программного обеспечения
• Тестирование программного обеспечения
• Развертывание
• Обслуживание и исправление ошибок

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

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

Деятельность по разработке программного обеспечения

Определение потребности

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

В книге «Great Software Debates», Алан М. Дэвис заявляет в главе «Требования», подраздел «Недостающая часть разработки программного обеспечения»

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

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

Процесс планирования

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

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

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

Проектирование

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

Внедрение, тестирование и документирование

Внедрение — это часть процесса, где инженеры-программисты фактически программируют код для проекта.

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

Документирование внутреннего дизайна программного обеспечения с целью дальнейшего обслуживания и усовершенствования осуществляется на протяжении всего процесса разработки. Это также может включать в себя написание API, внешнего или внутреннего. Процесс разработки программного обеспечения, выбранный командой разработчиков, определит, сколько внутренней документации (если таковая имеется) необходимо. Плановые модели (например, Waterfall ) обычно создают больше документации, чем модели Agile.

Развертывание и обслуживание

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

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

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

Подтемы

Модель представления

TEAF Матрица представлений и перспектив.

A Модель представления — это структура, которая предоставляет точки обзора в системе и ее среде для использования в процессе разработки программного обеспечения. Это графическое представление базовой семантики представления.

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

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

Моделирование бизнес-процессов и данных

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

пример взаимодействия между бизнес-процессы и модели данных.

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

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

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

Компьютерная разработка программного обеспечения

Компьютерная разработка программного обеспечения (CASE) в полевых условиях программное обеспечение инженерия — это научное применение набора программных инструментов и методов для разработки программного обеспечения, в результате которого создаются высококачественные, бездефектные и обслуживаемые программные продукты. Это также относится к методам разработки информационных систем вместе с автоматизированными инструментами, которые можно использовать в процессе разработки программного обеспечения. Термин «автоматизированная разработка программного обеспечения» (CASE) может относиться к программному обеспечению, используемому для автоматизированной разработки системного программного обеспечения, то есть компьютерного кода. Функции CASE включают анализ, проектирование и программирование. Инструменты CASE автоматизируют методы проектирования, документирования и создания структурированного компьютерного кода на желаемом языке программирования.

Двумя ключевыми идеями проектирования компьютерных систем программного обеспечения (CASE) являются:

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

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

Интегрированная среда разработки

Anjuta, C и C ++ IDE для среды GNOME

интегрированная среда разработки (IDE), также известная как интегрированная среда проектирования или интегрированная среда отладки, — это программное приложение, которое предоставляет программистам комплексные возможности для разработки программного обеспечения.. IDE обычно состоит из:

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

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

Язык моделирования

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

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

• Нотация моделирования бизнес-процессов (BPMN и XML в форме BPML) является примером язык моделирования процессов.
• EXPRESS и EXPRESS-G (ISO 10303-11) — это международный стандартный язык моделирования данных общего назначения.
• Extended Enterprise Modeling Language (EEML) обычно используется для моделирования бизнес-процессов на разных уровнях.
• Блок-схема — схематическое представление алгоритма или пошагового процесса,
• язык моделирования фундаментальных концепций моделирования (FMC) для программно-интенсивные системы.
• IDEF — это семейство языков моделирования, наиболее известные из которых включают IDEF0 для функционального моделирования, IDEF1X для информации моделирование и IDEF5 для моделирования онтологий.
• LePUS3 — это объектно-ориентированный язык описания визуального дизайна и язык формальных спецификаций, который является подходит в первую очередь для моделирования больших объектно-ориентированных (Java, C ++, C# ) программ и шаблонов проектирования.
• Язык спецификаций и описания (SDL) — это язык спецификаций, ориентированный на недвусмысленная спецификация и описание поведения реактивных и распределенных систем.
• Unified Modeling Language (UML) — это язык моделирования общего назначения, являющийся отраслевым стандартом для определения систем с интенсивным использованием программного обеспечения. UML 2.0, текущая версия, поддерживает тринадцать различных техник диаграмм и имеет широкую поддержку инструментов.

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

Парадигма программирования

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

A язык программирования может поддерживать несколько парадигм. Например, программы, написанные на C ++ или Object Pascal, могут быть чисто процедурными или чисто объектно-ориентированными или содержать элементы обоих парадигмы. Разработчики программного обеспечения и программисты решают, как использовать эти элементы парадигмы. В объектно-ориентированном программировании программисты могут думать о программе как о совокупности взаимодействующих объектов, в то время как в функциональном программировании программу можно рассматривать как последовательность оценок функций без сохранения состояния. При программировании компьютеров или систем с большим количеством процессоров процессно-ориентированное программирование позволяет программистам рассматривать приложения как наборы параллельных процессов, действующих на логически разделяемые структуры данных.

Так же, как разные группы в программная инженерия отстаивает разные методологии, разные языки программирования отстаивают разные парадигмы программирования. Некоторые языки предназначены для поддержки одной парадигмы (Smalltalk поддерживает объектно-ориентированное программирование, Haskell поддерживает функциональное программирование), в то время как другие языки программирования поддерживают несколько парадигм (например, Object Pascal, C ++, C#, Visual Basic, Common Lisp, Scheme, Python, Ruby и Оз ).

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

Примеры парадигм высокого уровня:

• Аспектно-ориентированная разработка программного обеспечения
• предметно-ориентированное моделирование
• Модельно-ориентированная инженерия
• Объектно-ориентированное программирование методологии
  • Объектно-ориентированный дизайн (OOD) Грэди Буча, также известный как объектно-ориентированный анализ и дизайн (OOAD). Модель Буча включает шесть диаграмм: класс, объект, переход между состояниями, взаимодействие, модуль и процесс.
• Разработка программного обеспечения на основе поиска
• Сервис-ориентированное моделирование
• Структурированное программирование
• Нисходящее и нижнее дизайн вверх
  • Программирование сверху вниз : разработано в 1970-х годах исследователем IBM Харланом Миллсом (и Никлаусом Виртом ) в разработке структурного программирования.

Программное обеспечение повторное использование

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

• A программная среда — это многоразовая проектирование или реализация программной системы или подсистемы.
• Компонентная разработка программного обеспечения включает интеграцию существующих компонентов для создания приложения.
• Сервис-ориентированные архитектуры или сервисно-ориентированное программирование основывается на концепции компонентов для предоставления сетевых услуг, таких как веб-сервисы.
• Программные продукты стремятся разрабатывать программное обеспечение на основе общего набора «основных» активов и процессов, чтобы производить ряд продуктов (или «приложений») для конкретного рынка.
• API (Интерфейс прикладного программирования, установить набор » определения подпрограмм, протоколы и инструменты для создания прикладного программного обеспечения «, которые могут быть использованы в будущем b uilds.
• Документация с открытым исходным кодом через такие библиотеки, как GitHub, предоставляет разработчикам программного обеспечения бесплатный код для повторного использования и внедрения в новые приложения или проекты.

См. также

• Непрерывная интеграция
• Специальное программное обеспечение
• DevOps
• Функциональная спецификация
• Продуктивность программирования
• Схема программного обеспечения
• Дизайн программного обеспечения
• Оценка усилий при разработке программного обеспечения
• Процесс разработки программного обеспечения
• Управление проектами программного обеспечения
• Язык спецификаций и описания
• Опыт пользователя
• Программная отрасль

Роли и отрасль

• Бакалавр наук в области информационных технологий
• Компьютерный программист
• Консультирующий инженер-программист
• Оффшорная разработка программного обеспечения
• Разработчик программного обеспечения
• Разработчик программного обеспечения
• Издатель программного обеспечения

Специальные приложения

• Разработка видеоигр
• Разработка веб-приложений
• Веб-инженерия
• Разработка мобильных приложений

Ссылки

Дополнительная литература

Wikimedia Commons имеет отношение к СМИ редакция Разработка программного обеспечения .

• Кит, Эдвард (1992). Тестирование программного обеспечения в реальном мире. Эддисон-Уэсли Профессионал. ISBN 0201877562 .
• Маккарти, Джим (1995). Динамика разработки программного обеспечения. Microsoft Press. ISBN 1556158238 .
• Конде, Дэн (2002). Управление программным продуктом: управление разработкой программного обеспечения от идеи до продукта, от маркетинга до продаж. Книги Аспатора. ISBN 1587622025 .
• Дэвис, А. М. (2005). Достаточно управления требованиями: там, где разработка программного обеспечения встречается с маркетингом. Издательская компания «Дорсет Хаус», инкорпорейтед. ISBN 0932633641 .
• Хастед, Эдвард (2005). Программное обеспечение, которое продает: практическое руководство по разработке и маркетингу вашего программного проекта. Wiley Publishing. ISBN 0764597833 .
• Хоманн, Люк (2003). За пределами архитектуры программного обеспечения: создание и поддержка успешных решений. Эддисон-Уэсли Профессионал. ISBN 0201775948 .
• Джон У. Хорч (2005). «Две ориентации на то, как работать с объектами». В: Программное обеспечение IEEE. т. 12, вып. 2, стр. 117–118, март, 1995 г.
• Риттингхаус, Джон (2003). Управление поставками программного обеспечения: методология управления разработкой программного обеспечения. Цифровая пресса. ISBN 155558313X .
• Вигерс, Карл Э. (2005). Подробнее о требованиях к программному обеспечению: острые вопросы и практические советы. Microsoft Press. ISBN 0735622671 .
• Высоцкий, Роберт К. (2006). Эффективное управление программными проектами. Вайли. ISBN 0764596365.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройте:

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

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

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

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

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

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

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

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