МФПУ Синергия — Кейсы — Юриспруденция

1. Анализ и моделирование предметной области

Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснение смысла высказанных требований, называется анализом предметной области. Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики ИС должны научиться:

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

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

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

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

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

Следует рассмотреть:

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

Для предметной области выберите главный бизнес-процесс и создайте для него контекстную диаграмму функциональной модели бизнес-процесса в нотации IDEF0 (не менее 3-х уровней декомпозиции).

2. Требования к ИС

Опишите требования к разрабатываемой системе (по ГОСТ Р ИСО/МЭК 12207). При этом должны быть учтены такие факторы, влияющие на сопровождаемость, как:

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

3. Техническая и программная архитектура ИС

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

• не менее 3-х серверов различного назначения;
• не менее 3-х рабочих станций;
• не менее 3-х единиц периферийного оборудования;
• не менее 3-х единиц коммуникационного оборудования, обеспечивающего выход в сеть Internet и беспроводное подключение периферийных устройств и/или ПК.

Далее приводится описание технической архитектуры – используемые аппаратные средства, уязвимые места, достаточность или недостаточность серверов и рабочих станций, актуальность используемых аппаратных средств или необходимость их замены и так далее.

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

• серверные операционные системы;
• клиентские операционные системы;
• систему управления базой данных (СУБД);
• антивирусное программное обеспечение;
• программное обеспечение общего назначения;
• офисное программное обеспечение;
• прикладное программное обеспечение в соответствии с задачей.

Далее приводится описание программной архитектуры – используемые программные средства, уязвимые места, актуальность используемых программных средств или необходимость их замены и так далее.

4. Сравнительный анализ готовых решений для автоматизации задачи

Провести сравнительный анализ представленных на рынке систем автоматизации выбранной задачи (не менее 3-х продуктов по не менее, чем 7 параметрам). Результаты представить в виде таблицы:

В качестве параметров можно рассматривать: используемую СУБД, стоимость одного рабочего места, операционную систему, на которой работает продукт, системные требования, наличие web-интерфейса, возможность удаленного доступа и так далее.

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

5. Сравнительный анализ способов приобретения ИС для автоматизации задачи

Определить оптимальный способ приобретения программного средства для автоматизации выбранной задачи. Результаты представить в виде таблицы:

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

6. Сравнительный анализ компаний – разработчиков ИС для автоматизации задачи

Провести сравнительный анализ представленных на рынке компаний-разработчиков программного обеспечения (не менее 3-х компаний по не менее, чем 5 параметрам). Результаты представить в виде таблицы:

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

Также необходимо привести краткое описание каждой компании-разработчика с указанием ее особенностей, отзывов клиентов, имиджа, репутации и так далее. Описание компаний должны содержать ссылки на соответствующие сайты в списке литературы.

7. Риски разработки и внедрения программного средства

Дается краткое понятие ИТ рисков. Далее необходимо определить возможные риски (не менее 3-х для каждого этапа жизненного цикла) разработки и внедрения программного средства автоматизации выбранной задачи и пути их предотвращения, результаты представить в виде таблицы:

8. Возможные дефекты программного средства

Дается краткое понятие дефектов программного средства. Далее необходимо сформировать таблицу возможных дефектов программного средства (не менее 3-х для каждого этапа жизненного цикла) и определить пути снижения вероятности их возникновения:

9. Сравнительный анализ стратегий внедрения ИС для автоматизации задачи

Дается краткое описание стратегий внедрения. Далее необходимо определить оптимальную стратегию внедрения, исходя из имеющихся у компании сотрудников и аппаратно-программных ресурсов. Результаты представить в виде таблицы:

Достоинства и недостатки стратегии внедрения указываются, исходя из имеющихся у компании сотрудников и аппаратно-программных ресурсов.

10. Разграничение прав доступа к ИС

Дается краткое описание принципов разграничения прав доступа. Далее необходимо для выбранной задачи автоматизации определить требования по ограничению прав доступа к различным областям программного средства (не менее 5 областей, не менее 3-х групп пользователей). Результаты оформите в виде таблицы:

На пересечении строки «Группы пользователей» и столбца «Модуль» указывается один из режимов доступа: «Полный», «Только чтение», «Чтение и запись». В режиме «Чтение и запись» пользователь может знакомиться с информацией и добавлять свои записи, но не имеет прав на удаление и редактирование записей (как правило, кроме добавленных им самим).

Выводы

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

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

Список использованной литературы

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

При составлении списка литературы в алфавитном порядке следует придерживаться следующих правил и их расположения:

• законодательные акты и постановления правительства РФ;
• специальная научная литература;
• методические, справочные и нормативные материалы, статьи периодической печати;
• названия и адреса Интернет-ресурсов.

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

Для законодательных актов необходимо указывать их полное название, принявший орган и дату принятия.

При использовании Интернет-ресурсов сначала приводится название материала и автор (если указан), а затем полный адрес его размещения (включая страницу). Ссылка должны быть актуальна на момент прохождения практической подготовки. В случае потери ссылкой актуальности – указать дату, на которую ссылка бы

Эксперт

Жанна

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

Задать вопрос

Представленная информация была полезной?

Да

91.07%

Нет

8.93%

Проголосовало: 168

или напишите нам прямо сейчас:

Написать в MAX

Написать в Telegram

Написать в WhatsApp