Информационный бизнес. Методическое пособие для бакалавров и младших специалистов

54)Содержание и структура бизнес-плана информационной фирмы.

55)Организация презентации фирмы информационного

бизнеса.

56)Трудности вхождения провайдерской фирмы в информационный, рынок.

57)Понятие провайдерской фирмы, классификация провайдерских фирм.

58)Доступ в Интернет – uplink-провайдеры, подключение местного провайдера к региональному.

59)Характеристика продукции провайдерской фирмы.

60)Оценка рисков провайдерской фирмы, мероприятия по предотвращению рисков.

3. Планы практических работ Введение

Создание информационного бизнеса (ИБ) предполагает множество шагов и действий, которые наиболее полно отображаются в документе «Бизнес-план». Это определение целей и задач создаваемого ИБ, товарной группы, привлечение инвесторов, расчет требуемых инвестиций и их возврата, т. е. отрицательных и положительных денежных потоков, прогнозирование рисков и их преодоления. С подробной методикой формирования бизнес плана ИБ, а точнее Интернет-компании, можно познакомиться в источнике «Бизнес-план создания Интернет-компании».

Мы же сосредоточим свое внимание и усилия на более сложной и проблематичной части проекта ИБ, а именно на создании Информационной среды ИБ средствами информационных технологий. Для этого мы должны использовать т. н. CASE (Computer aided Software

Engineering), средства «Объектно-ориентированного анализа и проектирования (ООА/П)» и моделирования информационных систем. Одним из наиболее популярных и современных CASE средств моделирования является продукт Rational Rose.

21

Основы UML моделирования

1) Цель и назначение «Унифицированного языка моделирования» (UML - Unified Modeling Language).

Целью UML-моделирования является создание UMLмодели будущей информационной системы с помощью автоматизированного средства разработки ИТ-проектов и программного обеспечения или CASE-системы (Computer aided Software Engineering).

Чтобы спроектировать достаточно сложную (несложные программы уже давно разработаны) качественную и надежную программу необходимо применять т. н. объектную технологию проектирования, где проектируемая система рассматривается как совокупность сущностейобъектов со своими свойствами, связей между этими объектами и методами (программами), которыми обладают эти объекты. И если не провести достаточно глубокий анализ проектируемой системы со стороны требований к системе и ожидаемых свойств, то разработанные программы как результат плохого моделирования не дадут ожидаемый результат. Это приведёт к резкому увеличению затрат на разработку системы, поскольку многие стадии разработки придется повторять с начала. Исследование факторов риска для программных продуктов показало, что 37 % риска связано с требованиями (неполные требования, слабое участие заказчика-пользователя, изменение требований). Поэтому появившиеся в 80-х годах прошлого столетия средства

«Объектно-ориентированного анализа и проектирования

(ООА/П)» как раз и предназначены для облегчения, унификации и систематизации этой определяющей стадии создания программных систем – анализ проектируемой системы. Целью указанного средства не является получение окончательного программного кода, хотя многие программы и могут быть реализованы в результате ООА/П, напротив, тщательное исследование требований системы должно привести к построению хорошей модели, доступной для

22

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

Вторым основополагающим принципом «Объектноориентированного анализа и проектирования (ООА/П)»

является итеративная разработка проекта методом «от главного к деталям» или методом «нисходящего проектирования» («сверху вниз»). Этот принцип заключается в том, что сначала определяются главные требования и свойства системы, которые затем детализируются и уточняются в процессе проектирования. В рамках унифицированного процесса проектирования ООА/П работа над проектом включает четыре основные фазы:

Начало (inception) – определение начального видения проблемы, прецедентов, оценка сложности задачи.

Развитие (elaboration) – формирование более полного видения проблемы, итеративная реализация базовой архитектуры, создание наиболее критичных компонентов (разрешение высоких рисков), идентификация основных требований, получение более реалистических оценок.

Конструирование (construction) – итеративная реализация менее критичных и простых элементов, подготовка к передаче и развертыванию.

Передача (transition) – бета-тестирование и развертывание.

Процесс «Объектно-ориентированного анализа и проектирования (ООА/П)» предлагается выполнить с помощью унифицированного языка моделирования UML

(Unified Modeling Language).

2) Пример UML модели «Система автоматизации торговли NextGen».

Рассмотрим основные приемы построения UMLмодели на примере системы автоматизации торговли NextGen.

В западных технологиях принят стандарт т. н. POSсистема (Point-of-sale system) – это компьютеризированное

23

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

Система должна поддерживать различные типы клиентских терминалов, сенсорный ввод данных и т. п.

3) Видение проектируемой системы «Автоматизация торговли NextGen».

Этот документ (артефакт) описывает основные свойства системы. Свойства системы описываются сжато путем перечисления основных функций:

Оформление продаж.

Авторизация платежей (по кредитной или дебитной карточке, чеком).

Системное администрирование и управление пользователями, безопасностью, таблицами констант и кодов и т. д.

Автоматический переход в автономный режим работы при выходе из строя внешних систем.

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

Определение и выполнение настраиваемых бизнесправил в фиксированных точках выполнения сценариев.

24

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

Введение

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

Экономические предпосылки

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

Формулировка проблемы

Традиционные Р0S-системы не обладают гибкостью, неустойчивы к сбоям и не обеспечивают интеграцию с внешними системами. Это приводит к проблемам с оформлением продаж, несоответствию программного обеспечения экономическим потребностям предприятий, невозможности точной и своевременной обработки данных и поддержки планирования. Эти проблемы касаются кассиров, менеджеров по продажам, системных администраторов и руководителей предприятий.

25

Место системы, основные пользователи

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

Заинтересованные лица и проблемы заинтересованных лиц

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

Демографические особенности рынка

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

Заинтересованные лица, не являющиеся пользователями системы

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

Пользователи системы

Сотрудники предприятия согласно функциям, клиенты, покупатели. Названные пользователи должны иметь прозрачный доступ к информации системы, формировать нестандартные запросы.

26

Основные задачи высокого уровня и проблемы заинтересованных лиц

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

Задачи уровня пользователя:

Кассир. Оформляет продажи, возврат товаров, регистрирует выручку.

Системный администратор. Управляет пользователями, безопасностью и системными таблицами.

Менеджер. Осуществляет запуск и завершает работу системы.

Система анализа торговой деятельности. Анализирует данные о продажах.

Окружение

Внешние по отношению к данной системе системы и структуры: маркетинговые сайты, статистика, гос. системы, банки, платежные системы.

Перспективы продукта

Система NextGen обычно будет устанавливаться в магазинах, при использовании мобильных терминалов она будет располагаться вблизи сети магазинов либо внутри магазинов. Система будет обслуживать пользователей и взаимодействовать с другими системами.В контекстной диаграмме (рис. 1.1) отображены основные участники системы и сама POS-система (Point-of-sale system) автоматизации торговли NextGen.

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

27

Рис. 1.1. Видение системы NextGen. Контекстная диаграмма

28

исследования. Прецеденты определяют пожелания или соглашения относительно поведения системы.

Итак, прецеденты – это требования (хотя и не все требования). Некоторые считают требованиями только список функций и свойств типа «система должна...». На самом деле это не так. Ключевая идея использования прецедентов как раз и состоит (обычно) в снижении роли списка требований в старом понимании этого слова.

Прецеденты типа "черный ящик" (Blасk-Bох саse) – это самый типичный и рекомендуемый тип прецедентов. Они не описывают внутреннюю работу системы, ее компоненты или дизайн, не расписывают, как это делать. Наоборот, системе вменяются некоторые обязанности. Этот метафорический термин широко применяется в объектноориентированном проектировании: программные элементы имеют обязанности и взаимодействуют с другими элементами со своими обязанностями. Позднее, на этапе проектирования, создается решение, удовлетворяющее разработанной спецификации.

Прецедент. Оформление продажи

.Основной успешный сценарий (или основной процесс)

1.Покупатель подходит к кассовому аппарату Р0Sсистемы с выбранными товарами.

2.Кассир открывает новую продажу.

3.Кассир вводит идентификатор товара.

4.Система записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил.

Кассир повторяет действия, описанные в пп. 3-4, для каждого наименования товара.

5.Система вычисляет общую стоимость покупки с

налогом.

6.Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.

30