ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.01.2024
Просмотров: 79
Скачиваний: 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 – Описание таблицы «События»
Таблица «События» необходима для записи события связанного с клиентом, при начале работы диспетчер заносит в эту таблицу данные для того, чтобы дать ясную картину о клиенте на предприятия, то есть брал ли он больничные, уходил ли он в отпуск , по какой причине это происходило и как часто это было.
Рисунок 3 – Описание таблицы «Должности»
Таблица «Должности» выполняет функцию выбора собственно самой должности, описание этой должности и выбор ставки за определённую должность. Например, клиент выбрал должность младшего помощника повара, ему описывают его обязанности на этой должности и предлагают ставку в виде 200Р/час.
Рисунок 4 – Описание таблицы «Журнал»
Таблица «Журнал» необходима для записи и хранения всей информации о клиенте, то есть связанные с ним события, должности и само собой его персональные данные, а также дату для того, чтобы знать в какой временной промежуток информация о клиенте дополнялась или удалялась. Например, определенный сотрудник на должности повара уволился 1 апреля 2010 года , а затем устроился на должность водителя такси 5 сентября 2010 года.
Рисунок 5 – Описание таблицы «Сотрудники»
Таблица «События» необходима для записи персональных данных, то есть имя, фамилия, отчество клиента, его дата рождения, контактный номер телефона для связи с клиентом, а также его паспортные данные в виде серии и номера паспорта. Записанные данные отправляются на предприятие для дальнейшего трудоустройства обратившегося клиента.
1.5 Используемые технологии
Вот лишь несколько функций языка C#, которые позволяют создавать надежные и устойчивые приложения. Сборка мусора автоматически освобождает память, занятую недостижимыми неиспользуемыми объектами. Типы, допускающие значение null, обеспечивают защиту от переменных, которые не ссылаются на выделенные объекты. Обработка исключений предоставляет структурированный и расширяемый подход к обнаружению ошибок и восстановлению после них. Лямбда – выражения поддерживают приемы функционального программирования. Поддержка языков для асинхронных операций предоставляет синтаксис для создания распределенных систем. В C# имеется Единая система типов. Все типы C#, включая типы–примитивы, такие как int и double, наследуют от одного корневого типа object. Все типы используют общий набор операций, а значения любого типа можно хранить, передавать и обрабатывать схожим образом. Более того, C# поддерживает как определяемые пользователями ссылочные типы, так и типы значений. C# позволяет динамически выделять объекты и хранить упрощенные структуры в стеке. C# поддерживает универсальные методы и типы, обеспечивающие повышенную безопасность типов и производительность. C# предоставляет итераторы, которые позволяют разработчикам классов коллекций определять пользовательские варианты поведения для клиентского кода.