Этап предпроектных работ начинается с первоначального осознания потребности создания новой или модификации существующей автоматизируемой информационной системы (АИС) (группы АИС) или путей автоматизации деятельности и процессов. Данный этап является периодом начального изучения, сбора фактов и анализа, изучения действующего законодательства и существующей организационной структуры, обзора аналогичных существующих АИС. Для разработки выходных документов данного этапа разработчику требуется обратная связь с пользователями.
Посредством анализа, определения осуществимости, оценки затрат, маркетинга, интеллектуальных способностей и материально-технического снабжения, изучения альтернатив, а также экспериментальной разработки, вырабатываются одно или несколько альтернативных решений для удовлетворения потребности заказчика или реализации концепции. Также на этом этапе определяется потребность в одной или нескольких подсистемах для реализации программной системы.
Выходными элементами этапа предпроектных работ являются следующие основные артефакты:
📝Как составить техническое задание для разработки мобильного приложения?
На этом этапе принимается решение: продолжать реализацию программной системы или прекратить дальнейшую работу.
3.2 Этап разработки
Этап разработки начинается с достаточно подробного уточнения требований заказчика и проектного решения и преобразует их в один или несколько жизнеспособных программных продуктов, которые обеспечивают работу в течение этапа эксплуатации. На этом этапе программная система может быть прототипом.
Оговариваются, анализируются, разрабатываются, создаются, испытываются и, при необходимости, оцениваются механизмы взаимодействия программных элементов и организационных структур, а также определяются требования к аппаратным средствам, инфраструктуре пользователя, обучению и сопровождению.
Результатом выполнения этапа являются разработка программного продукта, работоспособность и функциональность которого подтверждена квалификационными испытаниями, необходимой документацией, а также проведение других необходимых разработок.
На этом этапе посредством привлечения всех заинтересованных сторон обеспечивается включение в проект аспектов будущих этапов, а также требований и возможностей соответствующих систем обеспечения. При этом требуется обратная связь с заинтересованными лицами, которые отвечают за реализацию последующих этапов.
Выходными элементами этапа разработки являются следующие основные артефакты:
— версия программной системы;
— протокол квалификационного тестирования;
— акт передачи в опытную эксплуатацию.
В случае объявления тендера на разработку программной системы техническое задание должно являться составной частью тендерного предложения.
Планирование этапа разработки начинается на предыдущем этапе, чтобы обеспечить наличие или возможность создания в организации инфраструктуры систем обеспечения разработки, состоящей из методов, технических средств, инструментов и компетентных людских ресурсов для осуществления анализа процессов, моделирования, создания прототипов, проектирования, интегрирования, испытания и документирования. Эти элементы разрабатываются или приобретаются по мере необходимости для поддержки этапа разработки.
09 Пример составления технического задания
3.3 Процессы жизненного цикла программной системы
Определенные в настоящем техническом регламенте процессы жизненного цикла программной системы могут использоваться любой организацией (подразделением), приобретающей и использующей, и/или создающей и поставляющей программную систему. Процессы могут применяться на любом уровне в иерархии программной системы и на любом этапе жизненного цикла программной системы.
Процессы жизненного цикла программной системы базируются на принципах модульности (максимальная связанность функций процесса и минимальная связь между процессами) и ответственности (процесс ассоциируется с ответственностью за его реализацию). Функции, выполняемые этими процессами, определяются специфическими целями, требуемыми результатами и наборами деятельностей, которые составляют этот процесс.
Любой процесс, применяемый в жизненном цикле программной системы, продолжителен во времени. Структурно он может состоять из трех фаз, как показано на рисунке 3.
Структура выполнения процессов
Во время подготовительной фазы может происходить ознакомление с предметной областью, изучение результатов ранее выполнявшихся процессов, производиться предварительные планирование и расчеты.
Во время активной фазы происходит непосредственное выполнение процесса. В настоящем техническом регламенте при описании процессов освещаются действия только активной фазы.
Во время фазы завершения могут выполняться действия по анализу результатов, завершаться деятельности, начатые во время активной фазы, продолжаться работы, не ограниченные сроком окончания.
Организация (сторона) осуществляет процессы жизненного цикла программной системы избирательно для достижения цели и результатов этапов жизненного цикла системы. Описываемые в настоящем техническом регламенте процессы могут быть дополнены теми процессами, которые организация в зависимости от проекта посчитает необходимыми для достижения максимальной эффективности системы.
Для каждого процесса определяются цели и результаты, а также деятельности, необходимые для их достижения. Каждый процесс должен быть задокументирован.
3.4 Перечень процессов
Процессы жизненного цикла программной системы объединяются в четыре группы, согласно таблице 1.
Процессы жизненного цикла программной системы
Источник: diplomba.ru
Как правильно составить задание на разработку и каким оно должно быть
Допустим, у вас есть свой бизнес и вы успешно дошли до фазы «Нам нужен сайт» или даже «Нам нужно автоматизировать важный бизнес-процесс». Вы даже нашли ребят, которые с удовольствием готовы реализовать любые смелые затеи, но есть один нюанс: команда разработки просит сформулировать задание на проект (обычно это называется «Дайте-нам-ТЗ»). И с этого момента 99% заказчиков начинают делать и писать совсем не то, что просит подрядчик.
В этой статье мы расскажем, как самостоятельно составить действительно полезный документ, который поможет понять задачу, а не наоборот.
Что такое техническое задание (и почему на самом деле вам нужно не оно)
Для начала пора бы разобраться в терминологии: в процессе разработки проекта мы постоянно пишем какие-то документы, у всех них разное назначение и пишутся они для разных участков проекта и разной аудитории.
На старте проекта команде важно понять бизнес-задачу:
- каким бизнес-целям должен служить разрабатываемый продукт?
- какие задачи продукт должен решить?
- кто и в каких ситуациях будет пользоваться продуктом?
- какие есть ограничения в части реализации?
- какие конкуренты у бизнеса и у продукта?
Заказчик же, пытаясь донести суть задания до команды разработки, привык оперировать одним емким понятием — техническое задание.
Что есть ТЗ?
Это документ, на основании которого команда разработки реализует проект, и который описывает:
- назначение системы, которую надо разработать;
- перечень функций и алгоритмов, которые должны быть реализованы в рамках проекта;
- требования к интерфейсам;
- требования к интеграциям (включая техническое описание API или любого другого формата обмена данными, который предполагается использовать);
- требования к архитектуре системы;
- бизнес-процессы;
- пользовательские сценарии;
- методологию разработки;
- технологический стек (какие технологии будут использованы и почему);
- и много чего еще.
То есть ТЗ содержит исчерпывающие знания о назначении системы, функциональности и методах реализации и отвечает на вопросы:
- Какие компоненты включает система и как они будут взаимодействовать?
- Какие функции и алгоритмы нужно разработать, как именно и при помощи какого стека технологий?
- Как должен вести себя интерфейс
Очевидно, что разработка такой документации требует, во-первых, специализированных знаний (поэтому ТЗ пишут, как правило, системный аналитик или ведущий разработчик), во-вторых, понимания бизнес-целей и задач.
Вывод: на старте проекта нам нужно не ТЗ, описывающее, как делать систему, а документ, отвечающий на вопрос «Зачем и для кого мы делаем эту систему?»
Как сформулировать бизнес-требования
Документ, описывающий бизнес-цели и бизнес-требования к системе, называется Business Requirements Document, или BRD, или бизнес-и-функциональные требования к системе.
Составить такой документ можно самостоятельно, если следовать определенным алгоритмам.
Рассмотрим на примере: у клиента есть некий бизнес и ощущение (возможно, подкрепленное статистикой), что бизнес начал или продолжает стагнировать.
Бизнес: магазин виниловых пластинок, представленный в Москве несколькими точками оффлайн-продаж.
Проблематика с точки зрения владельца бизнеса: коллекционеры винила не имеют возможности регулярно посещать магазин, мониторить новинки и оперативно заказывать интересующие товары, а поскольку бизнес не автоматизирован — все предзаказы делаются только по телефону, что неудобно и бизнесу, и покупателю.
В итоге магазин упускает потенциальную прибыль, увеличивает нагрузку на продавцов и консультантов, имеет скудное представление о портрете своего покупателя и не может коммуницировать с аудиторией в объеме, необходимом для выстраивания дальнейшей маркетинговой стратегии. Плюс на складе постоянно оказываются какие-то неучтенные остатки, что искажает статистику товарооборота.
Решение: разработать интернет-магазин, в котором покупатель сможет посмотреть весь каталог, сделать предзаказ и отследить его исполнение, а продавец — обеспечить своевременное исполнение заказа, получить отчет о состоянии склада, по пути сняв статистику о пользовательских интересах и пользовательском поведении.
Итак, у нас есть понимание бизнес-проблемы и ее решения. Тут важно не начать писать ТЗ, а все же написать Бизнес-требования (невзирая на творческий зуд, стимулирующий к написанию детального задания на разработку).
Начинаем документ с пункта «Бизнес-цель». Наши бизнес-цели следующие:
- Увеличить оборот товара на складе.
- Собрать данные о целевой аудитории для дальнейшего использования в разработке маркетинговых стратегий.
- Снизить нагрузку на персонал магазинов за счет автоматизированности функций заказа / оплаты / доставки.
- Увеличить процент повторных продаж.
Если понятны цели — становятся ясны и задачи проекта:
- Обеспечить функции предзаказа товаров, оплаты и доставки.
- Настроить систему сбора статистики по продажам.
- Настроить систему учета остатков на складах.
- Обеспечить функции возврата покупателей.
Промежуточный результат: сформулирован перечень задач, где каждая задача привязана к определенной (или нескольким) целям.
Теперь уточняем, что должна уметь делать система, чтобы каждая задача в разрезе каждой цели была успешно решена. То есть фиксируем основные функции системы.
На выходе должна получиться вот такая матрица
Теперь команде разработки понятно, зачем заказчику нужен интернет-магазин, какими базовыми функциями он должен обладать и по каким параметрам будет оцениваться успешность проекта.
Но обычно интернет-магазины не эффективны, если у них нет интерфейса.
А как же требования к дизайну?
Формулируя эти требования, многие скатываются в формат «я хочу / мне нравится», проецируя таким образом личное чувство прекрасного на систему, которая в первую очередь должна быть функциональной и удобной.
Важно понимать, что дизайн — не изобразительное искусство, в отношении которого каждый имеет право на мнение «нравится / не нравится», а интерфейс — не просто какая-то интерактивная картинка, раскрашенная в разные цвета.
Интерфейс (экраны, страницы) — это как раз тот набор элементов (картинки, тексты, кнопки, галочки, интерактивные формы и т.д.), при помощи которого пользователи будут взаимодействовать с вашей системой. И требования к нему должны быть обоснованы функциональным назначением системы и сценариями использования.
Чтобы нарисовать качественный дизайн, нужно понимать, каким целям он будет служить (на эти вопросы отвечает BRD), какой контент будет публиковаться, какие есть технические ограничения по реализации и поддержке.
Требования к интерфейсу
Скажем сразу — ничто так не радует сердце UI/UX-проектировщиков и дизайнеров интерфейсов, как референсы. То есть примеры уже реализованных похожих проектов.
Референсы просят не потому, что каждый творец в душе плагиатор и хочет облегчить себе жизнь, а потому, что восприятие у всех разное и трактовать формулировки вида «хочется чего-то травянисто-зеленого и вызывающего ощущение летнего пикника на даче у бабушки» в разрезе конкретной задачи на дизайн — заведомо игра в гадание на гороскопах, потеря смысла задания и времени.
Добавить же в BRD ссылку на уже работающий проект — явно проще, чем детально описать каждую страницу, рискуя быть неправильно понятым.
Вывод: команде будет намного проще понять задачу по дизайну, если в ее описании присутствует:
- Описание пожеланий в сочетании с описанием реальных возможностей заказчика (например: «у нас есть отличные фото продукции в высоком качестве, поэтому хотелось бы использовать это в дизайне»; «у нас красивый логотип и мы хотели бы использовать его цвета и в дизайне сайта»; «у нас много хороших текстов, описывающих преимущества нашего магазина, и было бы хорошо их разместить»).
- Перечень ограничений (например: «не использовать черный цвет»; «нет качественных фото продукции»).
- Ссылки на нравящиеся сайты близкой тематики с кратким описанием, почему нравится тот или иной компонент.
Держаться в рамках, соблюдать границы
Итак, выше мы договорились, каким целям будет служить наша система, каким требованиям будет соответствовать интерфейс. Следующий важный момент — определить границы системы и рамки проекта.
Границы системы — это набор компонентов системы, взаимодействующих друг с другом в рамках выполнения соответствующих бизнес-процессов.
Например, мы понимаем, что интернет-магазин будет интегрирован с некой системой товарооборота, откуда интернет-магазин получает данные о товарных остатках и их стоимости (допустим, у нас 1С УТ), следовательно 1С — это важный компонент всей системы, который принимает участие в таких бизнес-процессах, как «Публикация товарного каталога на сайте» и «Оформление товара покупателем».
Рамки проекта — это набор функций системы, которые должны быть реализованы в рамках проекта «Разработка интернет-магазина».
Если обращаться к примеру с интеграцией 1С — то задачи по интеграции с 1С в рамки проекта укладываются, а вот задачи по возможным доработкам 1С — будут относиться к другому проекту.
- При формировании требований на разработку пишем не техническое задание, а бизнес-и-функциональные требования.
- По возможности — описываем основные процессы, характерные для вашего бизнеса.
- При формировании требований к дизайну — оперируем референсами, а не личными эстетическими настройками.
- Определяем границы системы и проекта, явно обозначаем их команде разработки и не выходим за эти рамки, пытаясь реализовать Систему-В-Широком-Смысле-Слова.
Практика показывает, что при соблюдении этих правил работоспособные системы выходят в релиз в должном качестве и в срок.
Источник: www.agima.ru
Техническое задание на разработку приложения
Техническое задание — один из главных этапов создания мобильного приложения. При этом, самый первый. А значит, пропустить его или отложить нельзя. Ведь от того, насколько хорошо составлено ТЗ, будет зависеть, какое приложение вы получите и как будет рассчитана стоимость мобильного приложения . Оно может получиться отличным, но не тем, какое нужно именно вам.
Написать хорошее ТЗ сложно, это не дело пяти минут. Но есть отличная новость! Эта ответственная задача ложится не только на ваши плечи, но и на плечи мобильного разработчика. Он тоже заинтересован в успехе вашего сотрудничества.
1 шаг. Идея разработки мобильного приложения
Опишите ваше будущее приложение будто рассказываете рецепт сложного блюда. Какие ингредиенты вы хотите туда положить? Какие функции они выполняют? Запишите их, продумайте, какая между ними логика взаимодействия. Не пытайтесь втиснуть в одно приложение все сразу — ведь в блюдах мы не мешаем все, что находим в холодильнике.
Мы выбираем что-то главное и добавляем к нему несколько менее важных ингредиентов, для того чтоб вкус получился уникальным.
Посмотрите, нет ли аналогов приложения? Если нет, то вам крупно повезло. Обычно же аналоги находятся и в крупных размерах — ваша задача придумать, чем ваше приложение будет отличаться, причем в лучшую сторону. И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.
Если же вы делаете приложение под свои бизнес-задачи, то вам будет полезно посмотреть, какие приложения есть у ваших конкурентов. Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.
2 шаг. Вопросы, с которых начинается ТЗ
Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:
1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?
2. Какие задачи решает приложение? Если оно для клиентов, то что клиенты смогут делать с помощью вашего приложения – заказывать товары, услуги, бронировать, записываться онлайн, узнавать об акциях и т.д.? Если оно для сотрудников, то какие функции в приложении помогут им работать эффективнее?
3. На каком устройстве вы хотите видеть ваше приложение? Смартфон, планшет или десктоп?
4. В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.
5. Когда вы хотите получить готовое приложение? То есть сроки.
6. Какой у вас бюджет? Уникальное приложение стоит не дешево, однако стоит учитывать те бонусы, которые вы за счет него получите — прибыль от увеличения заказов или оптимизации бизнеса.
Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.
Если вы не технический писатель или программист — подготовить грамотное ТЗ самостоятельно у вас, к сожалению, вряд ли получится. Но вам обязательно поможем мы, разработчики, ведь мы успешно делали это десятки раз.
3 шаг. Настало время ТЗ!
ТЗ – индивидуальный документ, и каждый раз составляется заново под каждый проект. Это также зависит и от разработчика, к которому вы обратились. Ведь у всех свой метод работы, а это значит, что в ваших интересах составить техзадание максимально подробно.
За некоторыми исключениями, ТЗ состоит из вот таких разделов:
1. Терминология. Очень важно договориться о терминах заранее, ведь одно и то же слово вы и разработчик можете понимать по-разному.
2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей.
К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку.
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно?
Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо.
Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?
6. Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.
Начните прямо сейчас!
На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия. А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности мы берем на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта. Поэтому начинайте прямо сейчас — заполните бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!
Источник: punicapp.com