Шаги подготовки к разработке программного обеспечения: 10 ключевых деталей

Успех разработки программного обеспечения начинается с тщательной подготовки

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

Исследование спроса: от расплывчатых идей до четких портретов

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

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

Анализ потребностей: от бизнес - языка к логике продукта

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

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

Технико - экономическое обоснование: прогнозирование рисков до ввода в эксплуатацию

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

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

Прототип: визуализация абстрактных потребностей

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

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

Технический выбор: выбор подходящего инструмента для проекта

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

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

Архитектурный дизайн: создание скелета системы

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

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

Разложение задач и расчет рабочего времени: преобразование чертежей в выполнимые планы

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

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

Подготовка среды разработки: проложить путь к эффективному кодированию

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

Контроль версий кода является краеугольным камнем среды разработки, и Git стал фактическим стандартом, требующим четких стратегий управления ветвями, таких как Git Flow или Trunk Based Development, с четкими спецификациями сотрудничества для разработки функций, устранения дефектов и выпуска версий. Зависимость от менеджмента гарантирует, что все разработчики используют одну и ту же версию сторонней библиотеки, избегая неловкой ситуации « работать на моем компьютере». Непрерывная интеграция конвейера реализует автоматическое построение, автоматическое тестирование, автоматическое развертывание после передачи кода, передает повторяющийся труд машинам и позволяет разработчикам сосредоточиться на творческой работе. Качество подготовки среды разработки напрямую влияет на эффективность разработки и качество кода. Предпринимательская группа не уделяла внимания экологической согласованности на начальном этапе проекта, и шесть разработчиков использовали шесть различных версий базы данных и промежуточных компонентов, чтобы обнаружить большое количество проблем с совместимостью на этапе совместной настройки и были вынуждены приостановить работу на две недели для согласования окружающей среды.

Формирование команды и разделение ролей: правильные люди делают правильные вещи

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

Для малых и средних проектов один человек может одновременно выполнять несколько функций, но обязанности должны быть ясными. Менеджер продукта отвечает за правильность требований и гарантирует, что команда делает все правильно; Менеджер проекта отвечает за управляемость прогресса и гарантирует, что команда работает правильно; Дизайнер отвечает за рациональность технического решения; Инженер - разработчик отвечает за качество реализации кода; Инженер - испытатель отвечает за надежность результатов. Формирование команды - это не только штатное расписание, но и формирование культуры. Самоорганизация, постоянное совершенствование и работа с пользователями, за которые выступает Agile Development, должны стать коллективным консенсусом. Первый запуск проекта - это не только развертывание рабочей миссии, но и возможность создать общее видение и объединить моральный дух команды. Исследования показали, что проекты с четким восприятием ролей и высокой сплоченностью были в 2,3 раза успешнее, чем проекты с ослабленными командами.

Опубликован устав проекта: официально началась разработка

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

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