Что такое постановка задачи в программировании

Постановка задачи

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

По-английски: Problem definition

См. также: Жизненный цикл программного обеспечения

Финансовый словарь Финам .

• Поставщик
• Постановление Правительства РФ

Смотреть что такое «Постановка задачи» в других словарях:

• Постановка задачи — Постановка задачи точная формулировка условий задачи с описанием входной и выходной информации. Входная информация по задаче данные, поступающие на вход задачи и используемые для её решения. Выходная информация может быть представлена … Википедия
• Постановка+задачи — Постановка задачи точная формулировка условий задачи с описанием входной и выходной информации. Входная информация по задаче это данные, поступающие на вход задачи и используемые для её решения. Выходная информация может быть представлена в виде… … Википедия
• постановка задачи — инструктаж Словарь русских синонимов … Словарь синонимов
• постановка задачи — — [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN problem definition … Справочник технического переводчика
• Постановка задачи — один из двух элементов научного познавательного процесса, который состоит из постановок и решений; конкретное решение, в свою очередь, тоже может быть представлено в виде процесса из постановок задач (подзадач) и решения их; постановка задачи… … Мир Лема — словарь и путеводитель
• ПОСТАНОВКА ЗАДАЧИ — предложение для решения, выполнения, обсуждения, получения конечного результата, составление исходных материалов и определение необходимой цели для решения задачи … Большой экономический словарь
• постановка задачи — Syn: инструктаж … Тезаурус русской деловой лексики
• ПОСТАНОВКА ЗАДАЧИ ЦЕНООБРАЗОВАНИЯ — понятие в маркетинге, которое предполагает выяснение целей фирмы, которые она стремится достичь с помощью конкретного товара, ими могут быть: обеспечение выживаемости, максимизация текущей прибыли, завоевание лидерства по показателям доли рынка… … Большой экономический словарь
• Задачи на взвешивание — Задачи на взвешивание тип олимпиадных задач по математике, в которых требуется установить тот или иной факт (выделить фальшивую монету среди настоящих, отсортировать набор грузов по возрастанию веса и т. п.) посредством… … Википедия
• постановка общей задачи — — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN general formulation … Справочник технического переводчика

• Обратная связь: Техподдержка, Реклама на сайте

• �� Путешествия

Экспорт словарей на сайты, сделанные на PHP,

WordPress, MODx.

• Пометить текст и поделитьсяИскать в этом же словареИскать синонимы
• Искать во всех словарях
• Искать в переводах
• Искать в ИнтернетеИскать в этой же категории

Поделиться ссылкой на выделенное

Прямая ссылка:

… Нажмите правой клавишей мыши и выберите «Копировать ссылку»

Постановка задачи.

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

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

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

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

Рассмотрим постановку так называемой закрытой транспортной задачи.

Пусть имеется т поставщиков A_v A_v . А_т некоторого однородного товара и пусть я- — количество единиц этого товара у /-го поставщика. Товар следует перевезти в п точек назначения B_v В_2У. В_п (потребителям); пусть j-й потребитель заинтересован в Ь- единицах товара. Суммарная потребность в товаре потребителей равна суммарной возможности поставщиков. Расходы на перевозку одной единицы товара от A_i к Б составляют с_ц денежных единиц.

Цель: составить такой план перевозок от А- к B_Jy чтобы общая стоимость перевозки всего товара была минимальной.

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

Задача 1. Попытаться найти какой-либо план перевозок от A_i к В_)У такой, что все запросы потребителей будут удовлетворены и товар от всех поставщиков будет вывезен. При этом общая стоимость перевозки всего товара может не быть минимальной.

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

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

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

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “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. Указано, в каких форматах отображать текущий год и будущие даты.

1. Этапы решения задач на компьютере

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

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

Рис. \(1\). Этапы решения задачи

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

На входе — проблема; на выходе — исходные данные и формат результатов.

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

3. Создание алгоритма решения. На этом этапе реализуются методы, с помощью которых будет осуществляться решение. Здесь необходимо скоординировать работу всех участников проекта решения. Создаются блок-схемы алгоритмов, технологические карты загрузки оборудования, например распараллеливание вычислений. Определяется последовательность выполнения отдельных блоков вычислений.
На входе — математическая модель; на выходе — блок-схема или другой способ описания алгоритма.

4. Составление программы для решения задачи. Алгоритм реализуется на конкретном языке программирования. Уточняются формат и область значений результатов в зависимости от выбранного языка программирования.
На входе — блок-схема или другой способ описания алгоритма; на выходе — программа обработки исходных данных.

5. Тестирование и отладка программы. Составление программы обработки исходных данных — процесс трудоёмкий, особенно если необходимо соединить блоки разных разработчиков и параллельно работающих процессов. Отладка программы выполняется в несколько этапов: определяются синтаксические и семантические ошибки. Для обнаружения ошибок проводят тестирование на специально подготовленных данных. Внутри программы расставляют «контрольные точки», получая таким образом сообщение об ошибке в ходе выполнения программы до её завершения. Кроме компьютерного тестирования полученные данные должен проанализировать специалист в той области, в которой работает поставленная задача. Такой подход позволяет выявить ошибки на предыдущих этапах решения задачи. Например, анализ результатов может выявить недочёты, связанные с выбором алгоритма решения, постановкой задачи или со сбором исходных данных. В этом случае процесс решения возвращается на предыдущие этапы и проводится их корректировка.
На входе — программа обработки исходных данных; на выходе — результаты решения задачи.