Что такое задачи программы

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

Техническое задание в соответствии со стандартом ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» имеет следующие основные разделы:

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

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

Цели и задачи программы

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

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

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

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

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

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

Родовые программы. Кармические задачи

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

• примитивные интерфейсы;
• интерфейсы-меню;
• интерфейсы со свободной навигацией;
• интерфейсы прямого манипулирования.

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

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

Интерфейс со свободной навигацией реализует множество сценариев работы, не привязанных к уровням иерархии команд, а предполагает определение множества команд на конкретном шаге работы. Такие интерфейсы называют графическими пользовательскими интерфейсами (GUI – Graphic User Interface) или интерфейсами WYSIWYG (What You See Is What You Get – что видишь, то и получишь). Преимущества интерфейсов со свободной навигацией по сравнению с интерфейсами-меню заключаются в возможности доступа к любым командам и в выборе команд, имеющих смысл в данный момент. Диалоговые окна программы содержат меню различных видов (кнопочное, ниспадающее, контекстное) и элементы управления вводом/выводом, реализующие диалог с пользователем.

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

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

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

• выбор метода программирования: процедурный или объектно-ориентированный;
• выбор языка программирования: C++ (безусловный лидер), Pascal, Basic, Ada и др.;
• выбор среды программирования: Visual C++, Visual Basic фирмы Microsoft, Delphi, Turbo C++, C++ Builder фирмы Borland, Visual Ada фирмы IBM и др.

Использование интерфейса со свободной навигацией или интерфейса прямого манипулирования требует выбора объектно — ориентированного подхода к программированию и выбора современной среды визуального программирования, например, Visual C++, Builder C++, Delphi.

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

• декомпозицию и содержательную постановку задач;
• эксплуатационные ограничения;
• математические методы решения;
• модели программного обеспечения.

Модели программного обеспечения зависят от технологии программирования (процедурная или объектно-ориентированная).

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

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

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

В настоящее время стандартным средством описания разрабатываемого программного обеспечения с использованием объектно-ориентированного подхода является фактически графический язык UML (Unified Modeling Language – универсальный язык моделирования), разработанный авторами Буча, Рамбо и Якобсоном в 1995 г.

Язык UML имеет следующие часто используемые диаграммы:

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

Диаграммы используют единую графическую нотацию.

Язык UML поддерживается пакетом Rational Rose – CASE- средством фирмы «Rational Software Corporation», предназначенного для автоматизации проектирования программного обеспечения при объектно-ориентированном подходе. Варианты Rational Rose определяются языком программирования (C++, Smalltalk, Builder, Ada, SQL Windows, ObjectPro). Основной вариант -Rational Rose/C++-разрабатывает документацию на базе диаграмм UML и генерирует программы на C++.

Источник: studfile.net

Задачи программы — клиенты единой поддержки

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

Существует 3 типа задач, которые могут быть добавлены в программу:

1. Пользовательская задача
2. Задача элемента каталога
3. Задача рекомендаций по оценке или возможности

Добавьте задачу в программу

Пользовательская задача

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

Задача элемента каталога

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

Задача рекомендаций по оценке или возможности

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

Кнопка «Добавить рекомендации» будет присутствовать только в программе исправления оценки.

Как редактировать задачу

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

Пользовательская задача

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

Задача элемента каталога

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

Задача рекомендаций по оценке или возможности

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

Управление задачами

Удаление задачи

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

Завершение задачи

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

Клонирование задачи

Нажмите на стрелку, чтобы развернуть задачу, а затем нажмите Клонировать задачу. Это откроет диалоговое окно, где вы сможете добавить владельца вновь созданной клонированной задаче. Нажмите Клонировать задачу.

Чтобы оставить общий отзыв о Центре ресурсов или содержимому, отправьте свой отзыв или комментарий своему представителю Майкрософт. По конкретным запросам и обновлениям контента, касающимся Services Hub, пожалуйста, свяжитесь в нашей командой поддержки, чтобы отправить обращение.

Обратная связь

Были ли сведения на этой странице полезными?

Источник: learn.microsoft.com

Как правильно поставить задачу для разработки

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина.

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

Этап подготовки

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

Декомпозиция задач

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

Название задачи

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

[версионная особенность] [раздел] — [часть экрана] — [что сделать]

Разберем каждую часть названия:

• [версионная особенность] — это может быть версия платформы, MacOS/iPad фичи;
• [раздел] — описывает, в каком разделе добавляется функциональность;
• [часть экрана] — указывает конкретный блок на экране, если изменения касаются его;
• [что сделать] — суть изменения или фичи;

Примеры хороших названий:

• «Подключить Firebase Performance»
• «Профиль (авторизованный) — добавить пункт история заказов»
• «История заказов — реализовать загрузку и отображение списка заказов»
• «Заказ из истории — Блок итого — Добавить строку дополнительных услуг»
• «[iPad] История заказов — Реализовать просмотр конкретного заказа в split view режиме»
• «[iOS 13+] Настройки — Добавить пункт «Siri shortcuts»

Примеры неудачных названий:

• «Подключить экран к API» — (какой раздел, экран?)
• «Цветовая индикация» — (ее нужно добавить? изменить? где находится?)

Описание задачи

Описание должно быть необходимым и достаточным.

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

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

Не забудьте описать:

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

Описание должно учитывать платформенные особенности, не допустите ошибочных расхождений в одинаковой функциональности.

Лайфхаки и советы

1. Структурируйте и будьте аккуратны. Разделяйте задачу на логические блоки, чтобы удобно было читать и находить информацию. Для начального заполнения задачи пользуйтесь шаблоном (например, YouTrack, который мы используем в работе, автоматически добавляет формат базовой задачи с местом для верстки, логики и сразу с базовым чек-листом, всем советуем, очень удобно).
2. Не допустите пересечения параллельных задач между разработчиками. Так вы получите увеличение трудозатрат на разрешение конфликтов и дублирование.
3. Ставьте задачи на любые изменения. Без этого вы не сможете доказать разработчику, что он сделал что-то не так. Устные договоренности ничего не значат! Без задачи изменения не будут протестированы тестировщиком. Кроме того, часто поставленные задачи служат единственным источником информации о поведении приложения. Отсутствие задачи в начале — недостаток информации потом.
4. Связь задач между платформами. Обязательно свяжите задачи про одинаковые фичи между двумя платформами в системе постановки задач. Так проще поддерживать актуальность описаний задач при изменениях на обеих платформах, догоняющий разработчик сможет узнать, кто делал задачу на другой платформе, и прочитать обсуждение.
5. Визуализация для задачи. Иногда схема, диаграмма или картинка опишет разработчику что-то понятнее, чем сложный текст — или хотя бы поможет быстрее разобраться в задаче.

Чек-лист для разработчика

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

1. наиболее старую поддерживаемую версию платформы — она же обычно и самая проблемная;
2. работу на маленьком девайсе;
3. темную тему;

Кроме того, в зависимости от задачи чек-лист может дополняться следующими пунктами:

• крайние кейсы для проверки;
• пустые состояния;
• состояния ошибок;
• подгрузка данных (если она постраничная);
• обновление данных (PTR);
• большие/маленькие данные;
• заглушки для текстов/картинок;
• горизонтальная ориентация.

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

Ожидаемый эстимейт по задаче

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

Шаги описания задачи

Итак, зафиксируем пройденный материал:

• Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
• Подберите правильное название задачи.
• В самом начале описания задачи поясните разработчику ценность изменения.
• Добавьте путь до изменяемого экрана, если это не очевидно.
• Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
• Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
• Если предполагается переиспользование для реализации, явно укажите это.
• Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
• Если необходимо сохранение данных для будущего использования, укажите.
• Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
• Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
• Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
• Укажите прошлые локальные данные, если они используются.
• Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
• Укажите логику для пустых данных.
• Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
• Пропишите логику для обработки специальных ошибок.
• Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
• Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
• Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
• Дополните базовый чек-лист.
• Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
• Перечитайте всю задачу от начала до конца!

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

Примеры хорошо описанных задач

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

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

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

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

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

Добавлена связь с другой задачей — по добавлению API к этому экрану.

Пример 5. Указаны кейсы для разных объемов данных (не помещается на одну строку — где-то проблема решается с помощью многоточия, где-то — переносом строки). В чек-листы также добавлена проверка.
Понятная работа с полями api. Указано, в каких форматах отображать текущий год и будущие даты.

Источник: habr.com