Выходная информация: печатные документы, видеограммы, сообщения, содержащие результаты решения и имеющие определенное назначение в данной предметной области.
Входная информация: данные входных документов, сообщений, файлов БД, входные параметры решения задач.
Чтобы решить задачу пользователя средствами СУБД необходимо сначала спроектировать эту задачу. При проектировании задачи необходимо выполнить постановку и алгоритмизацию задачи на основе исходной БД.
В процессе постановки определяется характеристика задачи, входная и выходная информация.
В характеристику задачи входят цель, назначение, сущность задачи, установка периодичности и сроков решения, разрабатывается общая технология обработки данных.
Алгоритм задачи – это совокупность формальных действий и проверочных условий, выполнение которых осуществляется в определенной логической последовательности и позволяет решить поставленную задачу.
Описание алгоритма включает:
- Назначение и характеристику алгоритма;
- Структуру входных и выходных данных;
- Математическое описание алгоритма (формулы, выражения, методы)
- Контрольный пример, содержащий данные для всестороннего тестирования алгоритма.
- Процесс алгоритмизации заключается в разработке совокупности конкретных действий – операций.
- Разбиение – разбиение общей задачи на элементарные подзадачи, реализуемые какими-либо инструментальными средствами СУБД.
- Разработка блок-схемы задачи.
- Конкретизация и формализация выполнения каждой подзадачи, определение ее входных и выходных данных, описание ее алгоритма.
Способы формального описания алгоритма
Топ 10 программ которые нужны на любом компьютере. Лучшие программы для ПК
- Словесный – последовательность действий записывается на естественном языке.
- Графический – последовательность действий записывается функционально- технологической схемой и блок-схемой алгоритма.
Графический способ отличается наглядностью, простотой восприятия. Функционально-технологическая схема отражает технологию преобразования входных данных в выходные и общий алгоритм такого преобразования. На блок-схеме каждое действие алгоритма описывается более детально и отображается определенным графическим символом. Внутри графического символа дается его краткое описание.
Важный этап – декомпозиция задачи на подзадачи, легко реализуемые одним из средств СУБД (например, запросом, отчетом):
Общий вид функционально-технологической схемы подзадачи:
Завершающий этап создания приложения пользователя – конструирование приложения пользователя, объединяющего всю технологию обработки данных предметной области, которая включает загрузку, ведение БД и решение всего комплекса задач.
Основы создания макросов
Язык макросов является языком программирования, который позволяет реализовать задачи пользователя, выполняя необходимые действия над объектами Access и их элементами.
Макрос – это программа, состоящая из последовательности макрокоманд.
Пользователь Windows 10 — добавление, настройка, смена пароля, права доступа
Макрокоманда – инструкция, ориентированная на выполнение определенного действия.
Пример: макрокомандой можно открыть форму, отчет, напечатать отчет, запустить на выполнение запрос, применить фильтр, присвоить значение, создать меню для формы или отчета.
Язык макросов обеспечивает возможность выполнения большинства задач, не прибегая к программированию на VBA.
Макросы обеспечивают набор методов обработки объектов.
Макросы взаимодействуют с объектами на основе событий.
События наступают при выполнении определенных действий.
- Осуществляется в диалоговом режиме и сводится к записи в окне макроса последовательности макрокоманд для которых задаются параметры.
- Каждому макросу присваивается имя.
- При выполнении макроса макрокоманды выполняются последовательно в порядке их расположения.
- Имеется возможность определять условия выполнения макрокоманды.
Выполнение макроса осуществляется:
- При его открытии.
- При наступлении некоторого события создание макроса.
Формирование макрокоманд в окне макроса
- Макрокоманды вводятся в одноименный столбец.
- В нижней части окна выводятся аргументы макрокоманды
- В строки столбца Примечания вводятся комментарии.
Формирование макросов с помощью мыши
Для включения в макрос макрокоманд достаточно перетащить с помощью мыши объект из окна БД в строку макрокоманды.
Формирование значений аргументов макрокоманды
Для формирования значений аргументов макрокоманды нужно перенести объект из окна БД в строку аргумента, для которого задается значение.
Пример: при переносе таблицы в строку аргумента Тип объекта макрокоманды Закрыть, аргумент получает значение Таблица. Аргумент Имя таблицы в качестве значения получает имя перетаскиваемой таблицы.
Создание группы макросов
Группа макросов создается как один макрос, в котором содержится несколько поименованных макросов, связанных с решением одной задачи или используемых при работе с одной формой.
- Вызвать столбец Имя Макроса.
- В ячейку столбца Имя макроса ввести имя одного макроса, затем записать макрокоманды, в нем выполняемые.
- Для ссылок на макросы, которые вошли в группу макросов, используется синтаксис:
[ИмяГруппыМакросов].[ИмяМакроса]
Вызов макроса из другого макроса
Если некоторый набор макрокоманд будет использоваться в нескольких макросах, то можно создать макрос, содержащий эти макрокоманды и вызывать его из других макросов.
Вызов макроса выполняется макрокомандой ЗапускМакроса. Ее аргументы:
- [Имя макроса]
- [Число повторов]
- [Условие повтора] — логическое выражение. При значении Ложь повторное выполнение вызванного макроса не производится и возобновляется выполнение вызывающего макроса.
Метод ЗапускМакроса позволяет организовать циклы в программах на языке макросов.
Источник: itteach.ru
Описание программы для пользователя
При запуске программы пользователь увидит окно с несколькими окнами для ввода, переключателями, а также кнопки для действий (рисунок 6.1). 
Рисунок 6.1 — Общий вид программы 
Рисунок 6.2 — Пример работы программы После ввода данных и нажатия на кнопку «Go!», а также после нажатий на кнопки «Преобразовать» пользователь увидит окно, которое изображено на рисунке 6.2. При вводе данных и подсчете результатов важно помнить, что
- Программа понимает только разделительный знак « . » (точка).
- При выполнении операции деление необходимо вводить только целые, натуральные числа.
- При выполнении операции возведение в степень в окно, куда вводится степень («Число №2»), нужно вводить только целые, натуральные числа, и только до числа 9999, так как при введении большей степени программа просто не будет его считать. То же самое произойдет, если ввести дробное число, либо отрицательную степень.
Заключение
Список используемых источников
1 Гусев В. А., Мордкович А. Г. Математика: Справочные материалы. — М.: Просвещение, 1990. 2 Окулов С.М. Программирование в алгоритмах. — М.: БИНОМ. Лаборатория знаний, 2002. 3 Акритас А. Основы компьютерной алгебры с приложениями. – М: Мир, 1994. 4 Макоха А.Н., Зуй Б. Ю. Арифметика сверхбольших натуральных чисел в параллельных вычислительных системах 5 Макоха А.Н., Ионисян А.С.
Компьютерная эмуляция арифметических операций над целыми и рациональными числами в СОК. // Вестник СГУ. – Ставрополь: Изд-во СГУ, вып. 20, 1999.
Приложение а
(обязательное) Блок-схема программы 
Начало 
Выбор номера операции Создание в памяти ячейки для числа №1 
Создание в памяти ячейки для числа №2 0 Операция сложения 
Создание в памяти ячейки для остатка от деления 1 Операция вычитания 
Создание в памяти ячейки для результата 2 Операция умножения 
3 Операция деления 
Создание в памяти вспомогательной ячейки 
4 Операция возведение в степень 
Считывание в число №1 данных из поля Memo1 
Считывание в число №2 данных из поля Memo2 
Подсчет затраченного времени Запуск счетчика времени 
Вывод результата в поле Memo3 
Остаток ничему не равен 
Нет Да 
1 2 
1 2 Остаток не равен 0 
Да Нет 
Вывод в поле Memo3 результат вместе с остатком 
Освобождение памяти для ячейки с числом №1 
Освобождение памяти для ячейки с числом №2 Освобождение памяти для ячейки с остатком Освобождение памяти для ячейки с результатом Освобождение памяти для вспомогательной ячейки Конец 
Источник: studfile.net
А пользователь кто? Моделирование пользовательских ролей и описание персон
В гибкой разработке как никогда популярно использование пользовательских историй (user story). И если вы слышали или работали с ними, то в курсе, что они пишутся от имени разных пользователей (user types). Определение пользователей важно не только для этого инструмента, но и если используются сценарии (use cases) или иное представление требований. Эта статья расскажет о моделировании персон, о том, как можно определить пользовательские роли для своего продукта.
Сначала еще раз про user story
Пользовательская история (user story, US) содержит описание функциональности, которая будет представлять ценность для пользователя или покупателя программного обеспечения (ПО).
Она состоит из краткого текстового описания, понятного пользователю, устного обсуждения с командой разработки и заказчиком (в случае продуктовой разработки заказчик может быть внутренним) и тестов, которые говорят о деталях истории, дают понимание о критериях приемки.
Пример пользовательской истории:
Пользователь может создать список покупок.
Кроме такого лаконичного описания могут быть примечания, которые нужны для обсуждения («Он должен быть доступен всем в доме? Сохранять автоматически или по кнопке?») и список тестов, которые раскрывают суть реализации («Проверить: создание списка, добавление пунктов, удаление пунктов, возможность задать заголовок для списка, возможность указать количество товара, возможность не указывать количество товара» и т.д.). Само описание тестов может быть разным, но главное, чтобы по тестам было понятно, когда история действительно реализована. Также, если требуется, после обсуждения появляются дочерние истории, более мелкие.
Вообще формат истории может быть разным, самое важное в этом инструменте — обсуждение!
Для тех, кто привык к стандартному описанию требований, такой подход может быть непривычен («Как так без конкретного описания, что сделать?», «Неужели тесты – это часть user story»?). Приемочные тесты как раз должны описывать, что должно быть сделано, чтобы история считалась решенной. По крайней мере, задумка такова. В реальности зачастую к историям прибавляются задачи на разработку (tasks), в которых дается больше конкретики по принятым решениям.
В отличие от классических спецификаций (Software requirements specification, SRS) пользовательские истории краткие, не содержат в себе описания конкретной реализации, не являются контрактными обязательствами (!). Тем не менее, их использование хорошо зарекомендовало себя, так как отлично ложится на итеративную разработку (как extreme programming, agile или конкретно scrum), позволяет максимально привлекать заказчика в проект, стимулирует общение в команде и откладывает проработку деталей до момента непосредственной реализации (а не на старте проекта). В целом, использовать пользовательские истории можно даже в государственных контрактах, так как в первоначальном ТЗ может не быть конкретных деталей (а как раз, по сути, список US), однако по результатам разработки необходимо будет написать весь пакет требуемой документации.
На мой взгляд, в случае заказной разработки отдельно необходимо работать с разрешением споров, так как пользовательские истории (еще раз) – не контрактные обязательства. Нельзя обратиться к ним и сказать: «Вот тут так написано, мы так и сделали». Конечно, за счет привлечения заказчика к обсуждению и постоянного контакта с ним не должно возникать ситуации «сделали не то, что хотелось», но часто может возникать ситуация «сделали не всё, что хотелось», ведь у контрактов есть цена, рассчитанная на определенные трудозатраты. Этот момент необходимо прорабатывать отдельно, но он не является блокирующим для использования user story в проекте. Часто в подобных ситуациях команды приходят к некоторому гибридному варианту, что тоже имеет право на жизнь.
В любом случае при определении возможностей к реализации (так называемых фич) необходимо понимать, для каких пользователей они нужны. Это важно при любом способе разработки и документирования.
Пользовательские роли, персоны
Как мы знаем, в пользовательской истории есть некий пользователь, для которого и определена ценность той или иной функциональности. И здраво предположить, что будущие пользователи системы разные, имеют разные цели и опыт. Согласитесь, для продвинутого программиста и для бабушки, которая боится компьютера, будут важны разные аспекты взаимодействия с системами.
Для разделения историй по разным типам пользователей придуманы пользовательские роли.
Пользовательская роль (user role) – описание некоторой совокупности пользователей и предполагаемого взаимодействия с системой.
Кроме описания группы пользователей аналитики часто задают некоторый образ, дают роли имя, возраст, профессию, это часто помогает команде представить, для кого делается продукт, также помогает и выявить упущенные истории. Такое описание называется персоной или личностью (persona).
Существует несколько способов выявить, смоделировать роли пользователей.
Способ 1. Реальные пользователи
При наличии конкретного заказчика сформулировать группы потенциальных пользователей проще, потому что с ними можно взаимодействовать напрямую. Можно взять и описать конкретных людей. Важность тех или иных ролей можно проанализировать с помощью RACI-матриц.
Идеально, если представители разных категорий пользователей входят в команду заказчика. Чаще всего это называется рабочей группой, и очень многое зависит от того, как она была сформирована. Здесь кроется опасность упустить некоторых пользователей, поэтому для охвата всех групп стоит прибегать и к моделированию.
Способ 2. Мозговой штурм
Основным способом для моделирования ролей является мозговой штурм (разработчиков и заказчика) и дальнейшее уточнение ролей. В этом случае очно или онлайн все должны собраться и накидать названия возможных ролей. Важно помнить, что роль – это пользователь, то есть некоторый человек, олицетворяющий группу, тот, для кого делается система.
После мозгового штурма предложенные роли необходимо обсудить. Визуально их располагают по близости или пересечению. Часть из них объединяется, часть исключается как неважные (или неважные на данном этапе разработки).
В качестве примера приведу моделирование ролей для приложения по управлению домашними делами. Предполагается, что приложение будет помогать людям ставить напоминалки для себя или сожителей о необходимости сделать то или иное дело по дому, например, прибраться в комнате, помыть посуду или что-то купить.
В ходе мозгового штурма были сгенерированы следующие роли, которые расположили по близости и пересечению:
После обсуждения каждой роли было принято решение оставить следующие (розовые стикеры):
Команда пришла к мнению, что задачи уборщицы схожи с теми, что решают соседи или члены семьи. В случае если появятся истории, которые этому противоречат, то будет добавлена новая роль. Ребёнок не был объединен с кем-то, так как детям может потребоваться больше мотивации для выполнения домашних дел (возможно, некоторая геймификация процесса).
После этого для каждой роли необходимо дать описание. Атрибут роли (role attribute) — факт или полезная информация о пользователях, которые действуют в данной роли. Главное указать, что пользователь ожидает от вашего программного обеспечения.
Пример — описание роли «Мама»:
Естественно, не обязательно, чтобы в самом приложении фигурировало название этой роли.
Способ 3. Сегментирование
Лично мне нравится другой способ моделирования ролей – от целевой аудитории. В данном случае также можно (даже рекомендуется) использовать мозговой штурм, но не сразу для названия ролей, а для определения критериев по разделению ЦА.
Способ рассмотрим так же на примере определения пользователей приложения для планирования домашних дел.
Изначально необходимо определить целевую аудиторию (в нашем примере – люди, которые делят обязанности по ведению хозяйства), само описание может немного меняться в ходе исследования, так как можно находить новые, неучтенные изначально, сегменты ЦА.
После этого необходимо сформулировать критерии, по которым наша ЦА может быть сегментирована. Критерии могут быть любые, лишь бы они влияли на использование системы. Вот здесь как раз может пригодиться мозговой штурм. В нашем примере получилось разделить ЦА по модели взаимоотношений, заинтересованности, основной задаче, по размеру домохозяйства.
Примеры популярных критериев: частота использования программы, уровень подготовки пользователя, основные задачи. Иногда важны такие критерии как возраст, параметры здоровья, профессия, социальный статус.
После этого с помощью критериев необходимо определить категории целевой аудитории, и для каждой категории задать название или сразу описать персону. То есть необходимо придумать роль, человека, который сочетает в себе разные значения критериев для разделения ЦА. Например, член семьи, который распределяет и контролирует обязанности по дому – мать Анжела. Сосед в съемной квартире или общежитии, который заинтересован в понимании, кто когда что делает по дому – Санёк. Человек, который не заинтересован в наведении порядка, но вынужден что-то делать по дому – подросток Володька.
В данном случае изначально может получиться много ролей, их также следует объединить, если это возможно. Сделать это можно в ходе обсуждения с командой и заказчиком (как при мозговом штурме). Некоторые роли можно исключить как неважные (никто не запрещает потом к ним вернуться).
В данном примере для описания персон в качестве атрибутов определены бэкграунд, цель использования, контекст, что важно, что полезно, страхи. То есть из описания роли можно понять, на что делать акцент при разработке, а дополнительные детали помогают проникнуться персонажем.
Можно заметить, что в ходе такого способа моделирования был найден неучтенный ранее пользователь – хозяин фермы с наемными работниками (во время мозгового штурма по придумыванию ролей он не пришел никому в голову, а вот критерий размера дома помог сформулировать и такую роль).
Способ 4. Экстремальные персонажи
Что еще? Еще есть дополнительная методика – использование экстремальных персонажей (extreme characters). Вместо проектирования продукта для типичного пользователя предлагается подумать о пользователях с неординарными личностными качествами.
Так, при проектировании персонального цифрового помощника предлагается подумать не о бизнес-консультанте в костюме, а о наркоторговце и о папе римском. Это может помочь нащупать новые полезные фичи, но не факт, что их целесообразно будет включать в продукт. Во всяком случае, это интересный инструмент развития креативности.
В нашем примере такой метод может добавить в персоны Бабу Клаву – соседку, которая максимально далека от любых информационных технологий, но живет в одной семье или коммуналке с теми, кто активно использует приложение. Как ей и домочадцам можно помочь?
Что дальше
После определения ролей или персон можно собирать истории для них, конкретизировать требования (для кого будет ценна та или иная функциональность). Команда разработки и заказчик больше будут понимать, что обсуждать и что делать. Также во время описания персон сразу могут возникать идеи на счет необходимых историй, их следует фиксировать для дальнейшего обсуждения.
Резюме
- При разработке важно понимать, для кого та или иная функциональность имеет ценность.
- Определение пользовательских ролей (user types) полезно для разных методов документирования разработки.
- Способы определить пользовательские роли: описать реальных пользователей заказчика, сформулировать роли с помощью мозгового штурма, выделить роли через сегментирование целевой аудитории, найти экстремальных персонажей.
- Для полноты картины следует использовать все способы моделирования пользовательских ролей.
- Персона (persona) – воображаемое представление пользовательской роли (её очеловечивание), помогает членам команды лучше представлять пользовательскую роль.
- Само моделирование пользовательских ролей уже позволяет выявить новые пользовательские истории (или требования).
Михайлова Анна
Начальник отдела интеллектуального анализа данных, главный системный аналитик,
Консорциум «Кодекс»
Источник: habr.com