Задачи для разработки программы

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

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

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

Чем занимается Java backend разработчик, типичные задачи и обязанности, порядок работы над задачами

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

— оптимальный маршрут между двумя аудиториями;

— местоположение запрашиваемой аудитории;

— информация о выбранном объекте.

В состав программы «Гид по МГТУ» входят следующие компоненты:

— компонент хранения данных об аудиториях;

— компонент предоставления справочной информации;

— компонент поиска оптимального маршрута;

Для эксплуатации программного продукта «Гид по МГТУ» определены следующие роли:

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

Пользователи программы должны иметь опыт работы с персональным компьютером на базе операционных систем Microsoft Windows на уровне рядового пользователя и свободно осуществлять базовые операции в стандартных приложениях Windows.

Для работы с программой не требуется покупка лицензий на программное обеспечение сторонних производителей. Базовой программной платформой является операционная система Microsoft Windows.

Перечень необходимой документации для сопровождения программы «Гид по МГТУ»:

— описание организации информационной базы;

— каталог баз данных;

Описания и иные текстовые документы на машинных носителях подготавливаются редактором Microsoft Word системы Windows.

Источник: studentopedia.ru

Задачи для разработки программы

ВРЕМЯ ПРОЧТЕНИЯ — 8 МИН

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

Основы постановки задачи на разработку программ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

крайние кейсы для проверки

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

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

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

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

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

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

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

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

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

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

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

Источник: cleverpumpkin.ru

Конспект для ученика по теме «Основные этапы разработки программ. Разбиение задачи на подзадачи»

В конспекте размещена статья на тему «Основные этапы разработки программ. Разбиение задачи на подзадачи». Информация содержит необходимый материал для сдачи ЕГЭ.

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

1. Постановка и анализ задачи. Четкое определение задачи и наборов входных и выходных данных.

2. Разработка алгоритма. Определение зависимости между входными и выходными данными, создание процедуры их преобразования.

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

4. Написание программного кода. Преобразование алгоритма в компьютерную программу на языке высокого уровня.

5. Тестирование и отладка программы. Тестирование — прогон программы на наборе тестов, для которых известен результат, с целью проверки правильности ее работы. Отладка (debug) — процесс выявления и устранения ошибок в программе.

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

Технология нисходящего программирования. Разбие­ние задачи на подзадачи. Процедуры и функции.

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

1. Вначале создаются и отлаживаются самые элементарные подпрограммы (скорее всего используя созданные ранее, хранимые в модулях-библиотеках).
2. Реализуется более крупный блок задачи путем вызова таких подпрограмм.
3. Повторяется пункт 2 до тех пор, пока не реализуется вся задача.

Достоинства этого подхода — уменьшается общий объем работы за счет ранее созданных участков кода.

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

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

Этапы решения сложной задачи X сверху вниз:

1. Разбиваем задачу X на несколько функциональных подзадач XI, Х2, ХЗ и т. д., т. е. выполняем ее декомпозицию.
2. Предполагаем, что впоследствии эти части будут разработаны, создаем их спецификации:

-Вид подпрограммы (процедура или функция);

-Ее имя; имена и типы формальных параметров, их порядок;

-Для функции — тип возвращаемого значения;

-Комментарии, описывающие назначение подпрограммы.

1. Пишем программу решения задачи X, заменив каждую из подпрограмм XI, Х2, ХЗ «заглушками», и отлаживаем ее в таком виде.

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

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

Процедуры и функции

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

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

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

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

• Главная
• Информатика
• 11 класс
• Блок 1. Информация и информационные процессы. Информация и ее кодирование
• 1.27 Основные этапы разработки программ. Разбиение задачи на подзадачи
• Текущая страница

Источник: shkolnik.pro