Тестовое задание на позицию "Системный аналитик"

Автор: Никитин Георгий Алексеевич

1. Определение требований к модели ✋

Тема задания: Разработка модуля "Паспорт"

Объект исследований: Информационная система.

Предмет исследований: Добавление и проверка паспортных данных.

Процессы верхнего уровня: ✋

• **А1 ** Управлять разработкой.
• **А2 ** Подготовить средства разработки.
• **А3 ** Провести разработку.
• **А4 ** Оценить качество разработки.
• **А5 ** Проанализировать проблемы.

Точка зрения: Менеджер проекта.

Цель моделирования: Определение автоматизируемых функций.

2. Функциональное моделирование процессов (IDEF0) ✋

• A-0 (контекстная диаграмма)

)

• A0 (диаграмма верхнего уровня)

• A2 (декомпозиция процесса/процессов внутренней среды)

• A3 (декомпозиция процесса/процессов внутренней среды)

• A4 (декомпозиция процесса/процессов внутренней среды)

3. Функциональное моделирование программных и информационных средств (DFD) ✋

Конфигурация технических средств: Рабочие станции (ПК).

Конфигурация программных средств: Многоуровневые.

**Допустимые виды хранилищ и их размещение:**бд Postgres, запоминающее устройство ПК.

• A33 Автоматизация процесса А33

4. Описание выбранного процесса ✋ в формате прецедента (Use Case) ✋

Диаграмма UML Use Case 4.1 Идентификатор прецедента: А33

4.2 Название прецедента: Подтверждение паспортных данных

4.3 Контекст: А3

4.4 Участники (actors) и цели (goals):

Участник	Категория	Цель (goal)
Нормативный документ	Инструмент	Обеспечить выстраивание идеальной системы
Специалист по качеству	Внешний	Произвести отправку сообщения
NALOG.RU API	Инструмент	Обеспечить работоспособность системы
APP API	Инструмент	Обеспечить работоспособность системы

4.5 Предусловия (pre-conditions):

• Выполненное подключение компонентов системы

• Специалист по качеству

4.6 Постусловия (post-conditions):

• Проведенная разработка
• Пользователь авторизован

4.7 Основной поток выполнения (main flow):

Участник	Действие (activity)	Ожидаемый результат
Пользователь	Вводит данные паспорта	Введенные данные
Пользователь	Нажимает кнопку "Проверить данные"	Данные отправлены
APPSERVER	Запрашивает данные у Nalog.ru	Данные запрошены
NALOG.RUSERVER	Отсылает статус	Отосланный статус
APPSERVER	Идентифицирует полученые данные	Получена информация
Пользователь	Видит статус	Пользователь узнал ИНН

4.8 Исключения (exceptions):

Условие (риск)	Последствия	Реакция
Сервер не доступен	Пользователь не получает отчет	Обратиться к разработчкику

4.9 Альтернативы (alternates):

Не предусмотрено.

4.10 Временные параметры:

• Триггер (событие, стартующее прецедент): Необходимость запросить ИНН.
• Номинальная частота повторения прецедента: 1-2 раза в день.
• Продолжительность прецедента: 3 минуты.

5. Описание структуры объекта ✋ в формате ERD (Class) ✋

• Описываемый объект: модуль в приложении.

• Диаграмма UML Class:

6. Описание алгоритма ✋ в формате UML (Sequence) ✋

• Описываемые процессы и потоки данных: А33

• Диаграмма UML Sequence:

7. Подготовка к интерпретации построенных моделей

7.1 Используемые паттерны проектирования и разработки ✋:

7.1.1 Процессная модель для сравнения: Задача: Необходимость запрашивать инн с помощью Nalog.ru Способ решения: при помощи методологии PDCA:

1. Этап Plan (планирование) Выявление проблемы:

• Процесс авторизации пользователя в Nalog.ru и запрос Инн является затратным по времени.
• Цель: автоматизация процесса авторизации с помощью модуля 'Паспорт'.
• Требования: повысить производительность и эффективность без увеличения трудозатрат
• Ожидаемый результат: разработано автоматизированный модуль, проверяющий корректность данных из Nalog.ru
• Ресурсы, необходимые для достижения ожидаемого результата: разработанные требования, наличие сервера, ПК или мобильного телефона, хранилище данных
• Процессы (запланированные действия):
• Разработать модуль "паспорт"
• Сделать возможным запрашивать данные у Nalog.ru
• Создать необходимые процедуры
• Разработать кнопки (функционал)

2. Этап Do (Выполнение) Разработчики-аналитики выполняют поставленные задачи
3. Этап Check (Проверка): По итогу разработки произвести апробацию, и в случае успеха, произвести внедрение
4. Act (Улучшение): При успешной работе системы она внедряется в проект с дальнейшей возможностью доработки.

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

7.2 Используемые паттерны выявления проблем ✋:

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

7.3 Возможные антипаттерны ✋:

Категория	Антипаттерн (риск)	Действие по избежанию
Разработка	Spaghetti code. Спагетти-код —Ход выполнения программы похож на спагетти, т.е извилистый и очень запутанный код.	изучение правил написания кода, переписывание кода
Архитектура	Большой комок грязи (Big ball of mud)	разработать "читаемую" архитектуру системы
Организация	Аналитический паралич. Неоправданно большие затраты на анализ и проектирование.	проанализировать приоритеты
Среда	Чрезмерное усложнение	стараться упростить систему

8. Интерпретация построенных моделей ✋

Расчет сложности разработки методом FPA IFPUG: Расчет трудозатрат на разработку «с нуля» методом COCOMO II: На данный момент не представляется возможным сделать актуальные отчеты, необходим сбор дополнительной информации у заказчика, а так же согласование сроков разработки.

9. Модель базы данных

10. Перечень хендлеров

1)GET v1/currentuser 2)GET v1/nalogdata - собирает данные из nalog.ru 3)POST v1/userdata - создает ссылку на ресурс 4)DELETE V1/userdata - позволяет удалять ссылку на ресурс