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

Уважаемые коллеги! Требую здоровой и конструктивной критики.
Недавно проходил собеседование в одной крупной российской ИТ- компании. На собеседовании в качестве теста на профпригодность было предложено выполнить задание.

Задание: «Необходимо написать задание программисту на разработку диалогового окна копирования файлов в файловом менеджере типа Total Commander или FAR.»

Что в результате сделал я:
Аннотация
Учитывая то, что формы взаимодействия программистов и аналитиков в разных компаниях разные, обусловлены разными факторами и спецификой, документация составлена согласно требованиям Руководящего документа по стандартизации РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». РД 50-34.698-90 является действующим российским стандартом. Область его применения охватывает круг задач, решаемых в рамках предложенного задания.
По полученным исходным данным составлены следующие документы, являющиеся заданием программисту для разработки компонента приложения.

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

1. Описание постановки задачи (ГОСТ 34.201-89 ТП-П4). Документ содержит описание поставленных задач.
2. Описание алгоритма (ГОСТ 34.201-89 ТП-ПБ). Документ содержит алгоритма решения поставленной задачи. Алгоритм представлен в текстовом виде.

Описание постановки задачи

Содержание
СОДЕРЖАНИЕ 1
1 ХАРАКТЕРИСТИКИ КОМПЛЕКСА ЗАДАЧ 2
1.1 НАЗНАЧЕНИЕ КОМПЛЕКСА ЗАДАЧ 2
1.2 ПЕРЕЧЕНЬ ОБЪЕКТОВ ПРИ УПРАВЛЕНИИ КОТОРЫМИ РЕШАЮТ КОМПЛЕКС ЗАДАЧ; 2
1.3 ПЕРИОДИЧНОСТЬ И ПРОДОЛЖИТЕЛЬНОСТЬ РЕШЕНИЯ; 2
1.4 УСЛОВИЯ, ПРИ КОТОРЫХ ПРЕКРАЩАЕТСЯ РЕШЕНИЕ КОМПЛЕКСА ЗАДАЧ АВТОМАТИЗИРОВАННЫМ СПОСОБОМ (ПРИ НЕОБХОДИМОСТИ); 2
2 ВЫХОДНАЯ ИНФОРМАЦИЯ 2
2.1 ПЕРЕЧЕНЬ И ОПИСАНИЕ ВЫХОДНЫХ ДАННЫХ 2
2.2 ВЫХОДНЫЕ СООБЩЕНИЯ 2
3 ВХОДНАЯ ИНФОРМАЦИЯ 3
3.1 ПЕРЕЧЕНЬ И ОПИСАНИЕ ВХОДНЫХ ДАННЫХ 3
3.2 ВХОДНЫЕ СООБЩЕНИЯ 3
4 ОПИСАНИЕ ЭКРАННОЙ ФОРМЫ МОДУЛЯ 3
4.1 ЭСКИЗ ЭКРАННОЙ ФОРМЫ МОДУЛЯ 3
4.2 ЭЛЕМЕНТЫ ЭКРАННОЙ ФОРМЫ 4

1 Характеристики комплекса задач
1.1 Назначение комплекса задач
Задачей работы диалогового окна копирования файлов в файловом менеджере типа Total Commander (далее – менеджер) является обеспечение возможности копирования объектов файловой системы на различные носители информации.
Диалоговое окно является дополнительным компонентом файлового менеджера – модулем.
Для обозначения разработки, принято решение присвоить модулю наименование «Копирование».
Модуль «Копирования» функционирует, и вызываться только из файлового менеджера.
1.2 Перечень объектов, при управлении которыми решают комплекс задач
Объектами управления являются:
• файлы;
• каталоги файловой системы носителей информации.
1.3 Периодичность и продолжительность решения
Продолжительность решения зависит от:
• размеров объекта копирования;
• параметров быстродействия технических средств.

1.4 Условия, при которых прекращается решение комплекса задач автоматизированным способом (при необходимости)

Постановка задач. Киножурнал «Фити́ль»

Условиями прекращения решения задачи является:
• Прекращение операции пользователем
• Закрытие файлового менеджера
2 Выходная информация
2.1 Перечень и описание выходных данных
Выходными данными модуля является информация о процессе копирования, отображаемая в виде текста на экранной форме. Информация должна содержать следующие данные:
1) Скорость копирования
2) Наименование копируемого файла
3) Обратный отсчет времени копирования в формате hh.mm.ss
4) Результат выполнения копирования в процентах.

2.2 Выходные сообщения
При работе с экранной формой (ЭФ) модуля пользователю могут выдаваться следующие сообщения:
1) Отсутствие файлов для копирования
2) Выбранный(ые) файл(ы)/каталог(и) защищены от копирования
3) Указанный каталог-получатель неверен
4) Указанный каталог-получатель недоступен
5) Недостаточно свободного места на получателе. Продолжить копирование? (ДА/НЕТ).
6) Копирование прервано
7) «Выбранный файл уже существует. Заменить?». ДА/НЕТ
3 Входная информация
3.1 Перечень и описание входных данных
Модуль получает следующие входные данные и команды:
1) Наименования выбранных для копирования файлов/каталогов и место их размещения. Информации о выделенных файлах считывается из активной панели файлового менеджера при вызове модуля.
2) Путь копирования выбранных файлов. По умолчанию данные о пути копирования поступают из неактивной панели менеджера, в которой открыт определенный каталог (каталог-получатель). Поле ввода пути копирования допускает ручной ввод каталога-получателя.
3) Команда вызова модуля. Команда выполняется после одного из следующих действий:
• Нажатие функциональной клавиши F5 на клавиатуре ПЭВМ.
• Кнопки «Copy» на панели инструментов менеджера.
4) Команда копирования. Выполняется после нажатия на кнопку «Копировать» экранной формы модуля или кнопки ДА сообщения «Выбранный файл уже существует. Заменить?».
5) Команда отмены копирования. Выполняется после нажатия на кнопку «Отмена» экранной формы модуля.
3.2 Входные сообщения
Модуль получает следующие входные сообщения
1) Об отсутствии свободного пространства на носителе информации, на который осуществляется копирование
2) О защите копируемых файлов
3) Об отсутствии доступа к каталогу-получателю
4) Об отсутствии указанного каталога-получателя
5) О существовании одноименного объекта в каталоге-приемнике.
4 Описание экранной формы модуля
4.1 Эскиз экранной формы модуля
Эскиз экранной формы модуля изображен на рис.1

Рис.1. Экранная форма модуля
4.2 Элементы экранной формы
Элементы ЭФ модуля представлены в таблице 1. ЭФ модуля является модальной, при ее открытии остальные элементы менеджера становятся недоступны.
Выходные данные, описанные в разделе 2.1., должны появляться на экранной форме при выполнении процедуры копирования. Располагать объекты на экранной форме допускается любым способом, выбранным разработчиком.
Расположение элементов экранной формы должно отвечать требованиям эргономики и технической эстетики.
Таблица 1. Элементы экранной формы модуля «Копирование»
№ п/п Наименование элемента Тип Описание
1. Информация о копируемых объектах Label Если происходит копирование одного объекта, то в метке выводится наименование объекта (например, «Тест.txt»), если больше одного, то количество объектов (например «2 файла(ов)»).
2. Путь Edit Содержит путь копирование. Допускается ручной ввод.
3. Копировать Button Кнопка запуска процедуры копирования
4. Отмена Button Кнопка закрытия экранной формы.

На работу меня не приняли, объяснив это тем, что форма соблюдена, но задача и требования учтены недостаточно четко.
Покритикуйте, пожалуйста, поясните, в чем я ошибся, в чем неправ?
PS Если потребуется, могу скинуть 2-й док-т — описание алгоритма

Источник: author-it.ru

Качество и тестирование программ

Жизненный цикл ПО

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

Шаги процесса программирования по Райли

Постановка задачи Документ Проектирование решения Документ Кодирование алгоритма Документ Сопровождение программы

Программирование

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

Программисты

системный аналитик алгоритмист кодировщик сопровождающий программист 5

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

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

Характеристики Хорошей Постановки Задачи

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

Стандартная форма постановки задачи (по Д. Райли )

Наименование задачи (схематическое определение); Общее описание (краткое изложение задачи); Ввод; Вывод; Ошибки; Пример.

Пример.Постановка задачи в стандартной форме(1)

НАЗВАНИЕ Сортировка трех целых чисел. ОПИСАНИЕ Ввод и вывод трех целых чисел, отсортированных от меньшего числа к большему. ВВОД Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «–».

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

Пример. Постановка задачи в стандартной форме(2)

ОШИБКИ 1) Если введено менее трех чисел, программа ждет дополнительного ввода. 2) Строки ввода, кроме первых трех, игнорируются. 3) Если какая-либо из первых трех строк содержит более одного целого числа, то программа завершает работу и выдает сообщение. ОШИБКА ВВОДА – допускается только одно целое число на строке. ПРИМЕР: ввод – 3 2 + 17 вывод – 3 2 + 17

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

Как ставить задачи по продукту, чтобы получать хороший результат?

Почему даже при очень подробном техзадании результат по задачам может быть неожиданно плохим? Что больше влияет на результат — подробное ТЗ или погружение в боли пользователей? В этой статье мы попробуем ответить на эти вопросы.

Самый важный вопрос продуктовой разработки

Самый важный вопрос к любой задаче, возникающей в продуктовой разработке — “ЗАЧЕМ?”.

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

Правильный ответ на каждый “Зачем?” — это конструкция: “Потому что это положительно повлияет на метрики такие-то”. Если такого ответа нет, то задача, вероятно, не приоритетная или вовсе ненужная.

В идеале вопросом “Зачем?” должны задаваться все члены продуктовой команды.

Если этого нет, то могут возникать следующие проблемы:

1. Механическое решение задач — что дали, то и делаю.
2. Отсутствие желания влиять на решение — есть менеджер, он и решает.
3. Отсутствие эмпатии к проблеме, которую решает задача.
4. Отсутствие ответственности — ты придумал решение, ты и отвечай.

Как сделать так, чтобы все участники команды мыслили продуктово и проникались задачами?

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

Общий фреймворк постановки задачи

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

1. Контекст — необходимо донести до исполнителя всё, что вокруг задачи: пользовательские истории, связанные с задачей; схожие проблемы, решаемые раньше; почему задачу не сделали прежде и т. п.
2. Цель — это наше “Зачем”. Зачем мы вообще решаем задачу: какую и чью боль хотим решить, когда её надо решить.
3. Решение — возможное решение или набор решений задачи. Формат изложения зависит от роли исполнителя. Важно донести, что на решение можно влиять. При этом влияние должно быть при ознакомлении с задачей, а не после реализации.

Укрупнённая структура описания задачи

Если вы ещё не выработали свою структуру постановки задач, то можно воспользоваться следующей:

1. Источники проблематики и контекст — детально описываем контекст задачи: какие были обращения, кто заказал, какие уже были подходы к решению и так далее.
2. Цель выполнения работ — какие боли в итоге должна решить задача.
3. Ожидания от результата — каким менеджер видит итог решения задачи.
4. Требования к работам — описание одного или нескольких вариантов решения задачи.
5. Взаимосвязь с существующими функциями — как отразится на существующих функциях, о каких связях не стоит забывать.
6. Какую документацию надо подготовить по итогам.
7. Как будет приниматься задача, тестирование итога.
8. Как будет проходить внедрение — возможно, нужны предварительные рассылки по пользователям или миграции содержимого БД, или ещё что-либо.

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

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

Аналитика и бизнес-исследование

Контекст

Формулировка гипотез и job stories по форме кто-что-зачем. Для того, чтобы поставить задачу, нужно:

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

Цель

Цель описывается гипотезами, job stories или user stories (подробнее тут: https://habr.com/ru/company/otus/blog/482066/). Все подвергается сомнению и приоритезации на уровне здравого смысла, опыта и понимания уже существующей аналитики по продукту.

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

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

Решение

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

Аналитика — всегда неопределенность. Данных есть от силы 40 %, из них достоверных — 10-15%, а вывод надо дать с «гарантией», что по крайней мере не будет не то, что противоположного исхода, а отклонения от текущей ситуации менее, чем наполовину.

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

1. Анализ изменений KPI по мере развития продукта.
2. Обнаружение и изучение аномалий.
3. Поиск «узких мест» и точек роста.
4. И прогнозирование, чего бы там теория не говорила — то, что и хотят получить часто, все остальное могут и не читать.

Продуктовый дизайн и проектирование

Контекст

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

Если дизайнер концентрирует своё внимание исключительно на UI (структура, цвета кнопок, расположении блоков и т. п.) и не часто задаётся главным продуктовым вопросом “Зачем?”, значит либо дизайнер не продуктовый, либо контекст и цели задач не донесены.

В дизайн-задачах контекстом являются:

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

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

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

Цель

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

Решение

Ранее мы писали, как правильно общаться с дизайнером — https://t.me/FreshProductGo/22. Максимально детально опишите требования к макету, который хотите получить. Если в макете присутствуют текстовые элементы (лендинг, email, баннеры и прочее) — обязательно предоставляйте вычитанные и финальные варианты текстов.

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

Вёрстка (front end)

Контекст

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

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

Цель

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

Решение

Верстальщику важно понимать, как должны «вести себя» блоки сайта при добавлении/удалении текста. А менеджеру важно учесть, что изменение дизайна (а мы здесь картинку подвинем или классическое поиграйте со шрифтами) на стадии верстки повлечет за собой увеличение времени работы исполнителя.

Вопросы, которые должны быть закрыты при постановке задач:

1) как будут работать главные элементы?

2) как будут отображаться формы/списки/ссылки/кнопки/изображения и т. п.?

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

3) для каких устройств и в каких браузерах будет работать сайт и приложение?

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

4) Какие цвета / шрифты используются на сайте и приложении?

Дизайнер совместно с макетами сайта должен предоставить палитру используемых цветов и прикрепить используемые шрифты/иконки. Иначе верстальщик никогда не поймет, «что же хотел сказать художник».

Разработка (back end)

Чем структурированнее будет постановка, тем лучше и удобнее для разработчика.

Контекст:

1. Те же пользовательские истории, что для дизайнера и верстальщика.
2. Принципиальный механизм решения, если он есть.
3. Рисунок/схема с потоками информации от пользователей к системе и обратно (блок-схемы взаимодействия сервисов, сценарии пользователя).

Цель

Нужно рассказать, о чем проект и как им будут пользоваться:

1. Общее описание целей.
2. Какие задачи должен решать проект, какие показатели он должен изменить (технические).
3. На кого проект ориентирован (пользователи с какой квалификацией будут им пользоваться).
4. На каких платформах он должен работать.
5. С какими системами проект должен быть интегрирован (автоматически получать или передавать данные).
6. Требования к функциям проекта.
7. Требования к ролям пользователей.

Решение

При постановке задачи потребуется закрыть следующие вопросы (конкретика зависит от этапа развития — делаем новый продукт или развиваем существующий):

1. Версии продукта (веб-версия и другие).
2. Типы страниц и элементов страниц сайта (описание основных функциональных страниц и ключевых элементов).
3. Типы (роли) пользователей (структурированное описание всех ролей: пул возможностей и ограничений).
4. Пользовательские сценарии (User story: кто и каким образом взаимодействуем со всем функционалом сайта).
5. Структура данных (клиенты, субъекты инфраструктуры и прочее).
6. Перечень интеграций в рамках задачи.
7. Функциональные требования к сервисам.
8. Нефункциональные требования к сервисам.
9. Дизайн и верстка. Общее описание.
10. Требования к интеграциям.
11. Архитектура сервисов.
12. Эргономика и техническая эстетика (макеты визуальной составляющей системы и прочее).
13. Требования к тестированию.
14. Этапы работ по созданию сервиса.
15. Порядок контроля и приемки сервиса.
16. Дальнейшая поддержка продукта и дорожная карта внедрения.

В качестве вывода:

1. Лучше потратить больше времени на проработку и постановку задачи, чем потом тратить время на переделку результата.
2. Каждый участник продуктовой команды должен на бизнес-уровне понимать, зачем он делает текущую задачу.
3. В задачах крайне важен контекст и все знания, которые так или иначе относятся к причинам, по которым задача вообще появилась.

Статья подготовлена в соавторстве с Михаилом Грековым.

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