471.51K

1_Лабораторная №1_Составление общих требований

1.

Архитектура
информационных систем

2.

Лабораторная работа №1.
Составление общих требований

3.

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

4.

К сожалению, заказчики зачастую говорят
очень много всего интересного, кроме главного, —
какова их цель. Вот это надо «вытащить» из них в
первую очередь. И задать вопрос должен
разработчик ИС. Сам заказчик — не специалист, у
него есть идея, и на этом он видит свою роль
выполненной. Он не понимает, какой путь
необходимо пройти для реализации его идеи. Как
правило, заказчик ждет, что проектировщик
исполнит его желание, не обговаривая подробности.
4

5.

Чтобы вникнуть в цель проекта, недостаточно составить
пару предложений со стандартным набором фраз. Цель
проекта
обычно
определяется
на
основе
противопоставления:
описывают
существующую
информационную модель (например, сидят люди в архиве и
бумажки перебирают), затем — ее недостатки (из-за
отсутствия автоматизации в архиве задействовано 10
человек, что явно избыточно, другие отделы не могут
неделями получить из архива нужную им информацию и т.д.)
и предлагают решение (внедрить ПО, которое позволит
осуществлять в автоматизированном режиме ряд операций,
операции надо перечислить). В случае, если на рынок
выводится совершенно новый вид сервиса, то требуется
изучить
существующий
рынок
и
«покритиковать»
имеющиеся там инструменты, затем предложить решение.
5

6.

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

7.

На данном этапе необходимо выбрать общие технические
решения, с помощью которых могут быть выполнены требования,
составленные на предыдущем этапе. Будет ли это веб-приложение или
нативное (это прикладные программы, которые были разработаны
для использования на определённой платформе или на определённом
устройстве. Одно из преимуществ нативных приложений — то,
что они оптимизированы под конкретные операционные системы,
поэтому они могут работать корректно и быстро.), толстый клиент
или тонкий (толстый клиент Данное приложение обеспечивает
полное функционирование вне зависимости от сервера. Часто он
выступает в роли хранилища информации. Все расчеты, обработка
совершается на устройстве пользователя. Тонким клиентом
называют компьютеры и программы, функционирующие в
терминальной или серверной сети. Множество задач по обработке
данных осуществляются на главных компьютерах, к которым
подсоединено приложение и компьютер. Часто представлен в виде
системного блока без жесткого диска.),
7

8.

централизованная база или распределенная, реляционная СУБД или
NoSQL (NoSQL (not only SQL — не только SQL) — обозначение
широкого класса разнородных систем управления базами данных,
появившихся в конце 2000-х — начале 2010-х годов и существенно
отличающихся от традиционных реляционных СУБД с доступом к
данным средствами языка SQL.), монолит или микросервисы (монолит
подразумевает
централизованный
цикл
обработки
запроса
пользователя, а микросервисы — децентрализованный. Микросервис
работает лишь с небольшой, максимально ограниченной областью
задач. Он выполняет минимум функций для достижения определенной
цели в вашем стеке. Вот более конкретный пример: допустим, в банке
есть "Login Service", и вы, конечно, не хотите, чтобы у этого сервиса
был доступ к финансовым транзакциям ваших клиентов. Эту область
вы вынесете в какой-нибудь “Transaction Service”), Java или Python.
Часто данные вопросы забывают обсудить вовремя, а потом
оказывается, что кто-то из программистов самостоятельно выбрал
определенный инструмент, а в конце концов данное решение не
позволяет достичь поставленной цели.
8

9.

Составили общие требования к ИС, выбрали
концепцию. «Ну, — скажет заказчик, — теперь все
понятно, можно проектировать». А можно ли?
Требования-то общие, их надо детализировать.
Например, на первом этапе вы определили, что должна
иметься бухгалтерия и производственный цех. Но какое
там будет оборудование, сколько будет рабочих мест и
т.д. Без этого проектировать тяжеловато будет. Это, вопервых. А во-вторых, необходимо прописать план
разработки ИС и ввода ее в эксплуатацию.
9

10.

Для
Информационной
Системы
разработка
(Технического задания) — центральная часть проекта.
Техническое задание описывает:
ТЗ
1. ЧТО должна делать система.
2. Какова должна быть общая структура системы.
3. Как создать систему.
То
есть,
ТЗ
содержит
функциональные
и
нефункциональные требования, а также требования к этапам
разработки, сдаче-приемке, документации. Также в ТЗ
должны быть кратко описаны процессы, которые мы
собственно автоматизируем.
10

11.

При описании функций системы (а это центральная часть
ТЗ) следует понимать — мы приводим требования к тому, ЧТО
должна делать система, а не КАК. Для вас должна быть важнее
широта охвата, а не глубина. Например, на первой стадии
(составление общих требований) мы выявили необходимость
наличия функции блокировки входа пользователя. В ТЗ указали,
что учетная запись блокируется при неиспользовании в течение
90 дней или после 6-и неудачных попыток входа, доступ может
быть ограничен администратором на определенный срок, при
попытке входа заблокированного пользователя необходимо
выводить сообщение и т.д. А в техническом проекте, мы
нарисуем макет карточки пользователя с флажком блокировки и
датой разблокировки, составим сценарий входа в систему, в
котором производится проверка на блокировку, автоматическая
разблокировка по истечении установленного срока, блокировка
в случае неудачных попыток входа; определим, что
выполняется на стороне клиента, а что на стороне сервера.
11
English     Русский Rules