ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.01.2024
Просмотров: 144
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
1 Проектирование системы автоматизации учёта кадров на предприятии
1.1 Выявление основных сущностей и их взаимосвязей.
1.2 Требования к разрабатываемой системе
1.3 Разработка диаграмм деятельности.
1.4 Разработка схемы базы данных
2 Описание разрабатываемой системы
2.1 Описание интерфейса пользователя
Для того, чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования. Варианты использования – это описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять как результаты, которые хочет получить пользователь влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность.
В процессе тестирования, описанные ранее варианты использования позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.
Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "Что пользователи ждут от системы?" задавать вопрос "Что система должна сделать для конкретного пользователя?". Такой подход позволяет искать функции, которые нужны многим пользователям и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.
Определим сущность для разрабатываемого приложения. В данном случае в качестве актера выступает «Сотрудник» кадрового агентства, который имеет варианты взаимодействия с приложением (Рисунок 1).
Рисунок 1 – Use case диаграмма автоматизации учета кадров на предприятии.
1.2 Требования к разрабатываемой системе
Для начала необходимо разобраться, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт—менеджера об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из :
-
User story; -
Use cases; -
Wireframes.
Сосредоточимся на User story и Use cases.
Пользовательская история, или User Story — это описание функций продукта простым языком, составленное с точки зрения пользователя. Она помогает понять, какую пользу клиенту принесет функционал приложения, еще на этапе аналитики проекта. Пользовательские истории служат неким контекстом для разработчиков: те понимают, чего хочет от продукта конечный пользователь, и работают более целенаправленно. Эти истории состоят из нескольких предложений и не углубляются в детали: они отражают суть и фокусируются на главном.
Пользовательские истории помогают сосредоточиться на потребностях пользователя: как он будет использовать приложение? Чего он ждет от продукта? Как поведет себя в той или иной ситуации? Таким образом, ответы на эти вопросы помогут создателям продукта решать настоящие проблемы клиентов. Вот несколько главных задач, для которых необходимо использовать User Stories:
-
Организовать работу. Когда проект разбит на части, связанные с пользовательскими историями, каждая из них представляет собой цельную и понятную задачу. Так разработчики могут фокусироваться на каждой из них и получать измеримый результат; -
Cохранить фокус на пользователе. Конечно, разработка включает себя десятки сложных задач, связанных с техническими, финансовыми и другими вопросами. Однако User Story — это постоянное напоминание команде о тех, для кого этот продукт создается, и направляют их работу в нужное русло; -
Сплотить команду. Несмотря на то, что у каждого есть свои задачи, каждый понимает конечную цель и видит себя частью целого. Только работая сообща, можно достичь нужного пользователю результата, и пользовательские истории дают четкое понимание этого аспекта работы; -
Найти свежие решения. Команда старается придумать самый приятный и интересный способ решить задачу пользователя. Часто это приводит к появлению новых интересных идей и их воплощению. Результат — полезный и уникальный продукт.
Хоть каждая пользовательская история и уникальна, но у них всех имеются стандартные элементы создания пользовательской истории, которые позволяют лучше всего понять пользователя приложения. Эти элементы включают в себя:
-
Заголовок – краткое описание истории; -
Я как – роль; -
Желания или требования – функционал; -
Для того, чтобы облегчить или улучшить – польза.
Необходимо создать приложение, которое позволит сотруднику кадрового агентства упростить процесс регистрации посетителя при выборе должности, ставки. Также приложение должно предоставлять сотруднику информацию о уже зарегистрированном посетителе. Необходима возможность просмотра данных взятых из журнала.
На основе данных требований, можно составить следующие user stories для разрабатываемого приложения:
-
Я как сотрудник хочу иметь списки для того, чтобы не покидать рабочее место и скорее начать обслуживать следующего посетителя; -
Я как сотрудник хочу, чтобы данные сохранялись автоматически по истечению времени для того, чтобы не покидать рабочее место и скорее начать обслуживать следующего посетителя; -
Я как сотрудник хочу просматривать информацию о посетителе для того, чтобы быть спокойным, что я правильно подобрал должности для данного посетителя; -
Я как сотрудник хочу просматривать журнал для того, чтобы не было каких – либо недочётов или конфликтных ситуаций с посетителями; -
Я как сотрудник хочу просматривать имеющиеся данные в журнале для того, чтобы своевременно предоставлять её посетителю и руководству предприятий;
Use case (также use case, сценарий использования) – это сценарий взаимодействия пользователя или пользователей с программным продуктом для достижения конкретной цели.
Use case содержат следующие сведения:
-
кто использует сайт или приложение; -
что пользователь хочет сделать; -
цель пользователя; -
шаги, которые делает пользователь, чтобы совершить определенное действие; -
описание того, как сайт или приложение реагируют на действия пользователя.
Use case не содержат детали реализации, а также описания пользовательского интерфейса или экранов.
В use case описывается не каким образом программа делает что—либо, а что именно она делает. Именно этого подхода и нужно придерживаться, создавая use case.
В отличие от user story, которая излагается от имени какого—то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:
-
запрос страницы браузером (браузер – веб—сервер); -
отправка ‘письма по электронной почте (отправитель – почтовый клиент). -
обращение спортсмена к тренеру (игрок – тренер).
Use case могут содержать следующие элементы. Их количество зависит от сценария:
-
Актер (actor) — тот, кто использует систему. Если взять за пример онлайн—магазин, там может быть несколько акторов: покупатели, продавцы, компании, занимающиеся доставкой, компании, проводящие платежи; -
Стейкхолдер (stakeholder) — тот, кто заинтересован в определенном поведении системы. Зачастую это не конечный пользователь, а кто—то, получающий выгоду от функционирования системы. В случае с онлайн—магазином это может быть партнер — платежная платформа; -
Первичное действующее лицо (primary actor) — человек или система, чьи цели достигаются при помощи нашего продукта. В онлайн—магазине это может быть основной дистрибьютор, чьи товары продаются на этой онлайн—платформе; -
Предусловия и постусловия — что должно быть в наличии или должно произойти до и после запуска сценария использования; -
Триггеры — события, запускающие use case; -
Успешный сценарий — use case, при котором все идет по плану, без ошибок и неожиданностей; -
Альтернативные пути — вариации основного успешного сценария на случай, если что—то пойдет не так на уровне системы, путём нарушения алгоритмов.
Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес—логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.
Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде use case.
1.3 Разработка диаграмм деятельности.
К задачам сотрудника кадрового агентства относится работа с клиентами для дальнейшего трудоустройства, а также создание сводных отчетов, которые записываются и хранятся в журнале для высшего руководства (Приложение А).
База данных aknp состоит из следующих сущностей (таблиц): "Сотрудники", "Должности", "События" и "Журнал". Сотрудник напрямую работает с клиентами, в его обязанности входит регистрация данных клиента перед подачей их предприятию. После каждой смены сотрудник создает и помещает общую базу журнала.
Кадровое агентство – предоставляет услуги по благоприятному трудоустройству.
Сотрудник:
-
записать данные клиента, создать предварительно событие; -
записать выбранную должность клиентом; -
дописать событие и о принятие на работу клиента; -
сохранить событие и данные клиента; -
занести все данные в журнал.
Клиент:
-
дать разрешение на обработку своих персональных данных; -
выбрать выгодную для себя должность; -
заключить договор с предприятием; -
приходить в кадровое агентство для возможности изменения своей должности.
1.4 Разработка схемы базы данных
Схема связей базы данных aknp, показывает какие сущности соединены между собой и по каким атрибутам.
Схема «сущность–связь» (также ERD или ER–диаграмма) — это разновидность блок–схемы, где показано, как разные «сущности» (люди, объекты, концепции и так далее) связаны между собой внутри системы. ER–диаграммы чаще всего применяются для проектирования и отладки реляционных баз данных в сфере образования, исследования и разработки программного обеспечения и информационных систем для бизнеса. ER–диаграммы (или ER–модели) полагаются на стандартный набор символов, включая прямоугольники, ромбы, овалы и соединительные линии, для отображения сущностей, их атрибутов и связей (ПРИЛОЖЕНИЕ В).
Эти диаграммы устроены по тому же принципу, что и грамматические структуры: сущности выполняют роль существительных, а связи — глаголов.
Каждая таблица необходима для выполнения конкретных функций.
Рисунок 2 – Описание таблицы «События»