32
платеж
программного обеспечения, следовательно,
отсутствует право использования объекта
авторского права
* ASP (Application Service Provider) - это компания, осуществляющая прикладной хостинг для
клиентов таким же образом, как ISP (провайдеры услуг Интернета) предоставляют услуги
хостинга на размещение веб-сайтов различным фирмам. Базовая модель заключается в том, что
передвижные или стационарные пользователи связываются с ASP через Интернет, чтобы
запустить свои приложения. Преимущество ASP в том, что он имеет центр данных, управляемый
профессионалами и снабженный всем необходимым оборудованием для обеспечения
отказоустойчивости, резервирования данных, высокого уровня работоспособности, хранения
прикладных программ, поддержки продукта и т.д.
** Технический платеж (technical fee) - это плата за:
a) инженерные и технические услуги, включая поддержку производственного процесса,
испытаний и контроля качества, поддержку путем предоставления патентованных
технологических процессов и/или секретов ноу-хау и права пользования
технической/конфиденциальной информацией, возникающей в результате постоянных
технических исследований и т.д.;
б) техническое обучение персонала.
33
ГЛАВА 3. Методология проектирования интернет - сайта
3.1 Обзор методологий проектирования интернет представительства
Как и в любом деле, создание сайтов происходит при помощи
различных методов. И заказчику обязательно следует знать, как же
происходят работы. Нет, конечно, не стоит вдаваться в мелочи и досконально
изучать вопрос, но в общих чертах, все-таки, следует понимать процесс
создания. А нужно это для того, чтобы понять, чего же заказчик на самом
деле желает получить и смочь объяснить это команде исполнителей, которой
будут доверены работы над интернет-проектом. кроме того, это поможет
избежать затрат на недобросовестных исполнителей, которые пообещают
выполнить все работы за две недели и как итог - или не уложатся в срок, или
же выдадут сайт, созданный на базе шаблона, за собственную разработку.
Итак, под методами создания интернет-сайтов понимается
совокупность приемов и инструментов разработки. Самыми
распространенными методами можно назвать:
1. Шаблоны. Шаблон представляет собой написанный один раз
"движок" - программную часть сайта, отвечающую за его функциональность,
и растиражированный дизайн - то есть внешнюю, видимую часть сайта. Из
несомненных достоинств данного метода можно отметить простоту
создания: ресурс может создать школьник, который уложиться в рекордно
короткий срок - час, не более (большая часть времени уйдет на поиск
шаблона). Главный же недостаток - растиражированность.
2. Конструктор сайта. Почти то же самое, что и шаблон. Главное
отличие - возможность подключения определенных модулей (допустим,
можно добавить поиск по сайту и, в то же время, избавиться от каталога).
конструктор позволяет выбрать и элементы дизайна, и даже переработать их.
Но ключевые элементы, по-прежнему, будут занимать свои места. Минусы и
плюсы конструктора аналогичны положительным и отрицательным чертам
34
шаблонов.
3. WYSIWYG-редакторы - (What You See Is What You Get - дословно -
"что ты видишь, то и получаешь", англ.) специальные программные среды
разработки сайтов, такие как Dream Weaver или Front Page. Сочетание среды
разработки сайта, графических редакторов (Adobe Photoshop, Corel Photopaint
и пр.) позволяет создавать сайт и сразу видеть конечный результат, который
сразу же можно протестировать. Из плюсов отмечается скорость разработки
и возможность написания ресурса всего лишь одним человеком, так как
подобный метод не предполагает необходимость познаний в языках
программирования (Java, PHP и пр.), поскольку ядро пишется автоматически
средой разработки. к недостаткам стоит отнести низкий уровень защиты от
вирусных атак, от проникновения злоумышленников (так как методы обхода
защиты программной части такого сайта известны многим хакерам и
вирусописателям). Также стоит добавить, что полученные скрипты не всегда
работают так, как задумывалось, и функциональность оказывается чуть
"ущербной". Кроме того, такой сайт "тяжел" для загрузки при медленном
подключении к сети интернет, его код не оптимизирован, что вызывает
"подвисания" браузера.
4. Сочетание WYSIWYG-редактора и программирования. в данном
случае создание сайта происходит в той же среде разработки, но
впоследствии над программным кодом работает программист, переписывая
или корректируя созданные скрипты. Специалист усиливает защиту сайта,
которая будет противостоять вирусным и хакерским атакам, отлаживает
"движок", выстраивает функциональность. Качественный сайт можно
получить только, применив подобный метод. Единственным его недостатком
считается высокая цена разработки.
3.2 IDEF0
На начальных этапах создания ИС необходимо понять, как работает
35
организация, которую собираются автоматизировать. Никто в организации не
знает, как она работает в той мере подробности, которая необходима для
создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии
вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник
хорошо знает, что творится на его рабочем месте, но плохо знает, как
работают коллеги. Поэтому для описания работы предприятия необходимо
построить модель. Такая модель должна быть адекватна предметной области,
следовательно, она должна содержать в себе знания всех участников бизнес-
процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является
IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и
называвшийся первоначально SADT - Structured Analysis and Design
Technique. (Подробно методология SADT излагается в книге Дэвида А.
Марка и Клемента Мак-Гоуэна "Методология структурного анализа и
проектирования SADT"M.Meтaтexнoлoгия, 1993.) В начале 70-х годов
вооруженные силы США применили подмножество SADT, касающееся
моделирования процессов, для реализации проектов в рамках программы
ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это
подмножество SADT было принято в качестве федерального стандарта США
под наименованием IDEF0. Подробные спецификации на стандарты IDEF
можно найти на сайте http://www.idef.com.
В IDEF0 система представляется как совокупность
взаимодействующих работ или функций. Такая чисто функциональная
ориентация является принципиальной - функции системы анализируются
независимо от объектов, которыми они оперируют. Это позволяет более
четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и
графическое), которое должно дать ответ на некоторые заранее
определенные вопросы.
Моделируемая система рассматривается как произвольное
36
подмножество вселенной. Произвольное потому, что, во-первых, мы сами
умозрительно определяем, будет ли некий объект компонентом системы, или
мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно
зависит от точки зрения на систему. Система имеет границу, которая
отделяет ее от остальной вселенной. взаимодействие системы с окружающим
миром описывается как вход (нечто, что перерабатывается системой), выход
(результат деятельности системы), управление (стратегии и процедуры, под
управлением которых производится работа) и механизм (ресурсы,
необходимые для проведения работы). Находясь под управлением, система
преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с
определения контекста, т. е. наиболее абстрактного уровня описания системы
в целом. в контекст входит определение субъекта моделирования, цели и
точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно
установить, что входит в систему, а что лежит за ее пределами, другими
словами, мы должны определить, что мы будем в дальнейшем рассматривать
как компоненты системы, а что как внешнее воздействие. На определение
субъекта системы будет существенно влиять позиция, с которой
рассматривается система, и цель моделирования - вопросы, на которые
построенная модель должна дать ответ. Другими словами, первоначально
необходимо определить область (Scope) моделирования. Описание области
как системы в целом, так и ее компонентов является основой построения
модели. Хотя предполагается, что в течение моделирования область может
корректироваться, она должна быть в основном сформулирована изначально,
поскольку именно область определяет направление моделирования и когда
должна быть закончена модель. При формулировании области необходимо
учитывать два компонента - широту и глубину. Широта подразумевает
определение границ модели - мы определяем, что будет рассматриваться
внутри системы, а что снаружи. Глубина определяет, на каком уровне
37
детализации модель является завершенной. При определении глубины
системы необходимо не забывать об ограничениях времени - трудоемкость
построения модели растет в геометрической прогрессии от глубины
декомпозиции. После определения границ модели предполагается, что новые
объекты не должны вноситься в моделируемую систему; поскольку все
объекты модели взаимосвязаны, внесение нового объекта может быть не
просто арифметической добавкой, но в состоянии изменить существующие
взаимосвязи. внесение таких изменений в готовую модель является, как
правило, очень трудоемким процессом (так называемая проблема
"плавающей области").
Цель моделирования (Purpose). Модель не может быть построена без
четко сформулированной цели. Цель должна отвечать на следующие
вопросы:
• Почему этот процесс должен быть за моделирован?
• Что должна показывать модель?
• Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать
усилия в нужном направлении. Примерами формулирования цели могут быть
следующие утверждения: "Идентифицировать и определить текущие
проблемы, сделать возможным анализ потенциальных улучшений",
"Идентифицировать роли и ответственность служащих для написания
должностных инструкций", "Описать функциональность предприятия с
целью написания спецификаций информационной системы" и т. д.
Точка зрения (Viewpoint). Хотя при построении модели учитываются
мнения различных людей, модель должна строиться с единой точки зрения.
Точку зрения можно представить, как взгляд человека, который видит
систему в нужном для моделирования аспекте. Точка зрения должна
соответствовать цели моделирования. Очевидно, что описание работы
предприятия с точки зрения финансиста и технолога будет выглядеть
совершенно по-разному, поэтому в течение моделирования важно оставаться
38
на выбранной точке зрения. Как правило, выбирается точка зрения человека,
ответственного за моделируемую работу в целом. Часто при выборе точки
зрения на модель важно задокументировать дополнительные альтернативные
точки зрения. Для этой цели обычно используют диаграммы FEO (For
Exposition Only), которые будут описаны в дальнейшем.
Методологию IDEF0 можно считать следующим этапом развития
хорошо известного графического языка описания функциональных систем
SADT (Structured Analysis and Design Teqnique). Несколько лет назад в
России небольшим тиражом вышла одноименная книга, посвящанная
описанию основных принципов построения SADT-диаграмм. Исторически,
IDEF0, как стандарт был разработан в 1981 году в рамках обширной
программы автоматизации промышленных предприятий, которая носила
обозначение ICAM (Integrated Computer Aided Manufacturing) и была
предложена департаментом Военно-Воздушных Сил США. Собственно
семейство стандартов IDEF унаследовало свое обозначение от названия этой
программы (IDEF=ICAM DEFinition). В процессе практической реализации,
участники программы ICAM столкнулись с необходимостью разработки
новых методов анализа процессов взаимодействия в промышленных
системах. При этом кроме усовершенствованного набора функций для
описания бизнес-процессов, одним из требований к новому стандарту было
наличие эффективной методологии взаимодействия в рамках “аналитик-
специалист”. Другими словами, новый метод должен был обеспечить
групповую работу над созданием модели, с непосредственным участием всех
аналитиков и специалистов, занятых в рамках проекта.
В результате поиска соответствующих решений родилась методология
функционального моделирования IDEF0. C 1981 года стандарт IDEF0
претерпел несколько незначительных изменения, в основном
ограничивающего характера, и последняя его редакция была выпущена в
декабре 1993 года Национальным Институтом По Стандарам и Технологиям
США (NIST).
39
Основные элементы и понятия IDEF0
Графический язык IDEF0 удивительно прост и гармоничен. В основе
методологии лежат четыре основных понятия:
Первым из них является понятие функционального блока (Activity
Box). Функциональный блок графически изображается в виде
прямоугольника и олицетворяет собой некоторую конкретную функцию в
рамках рассматриваемой системы. По требованиям стандарта название
каждого функционального блока должно быть сформулировано в глагольном
наклонении (например, “производить услуги”, а не “производство услуг”).
Каждая из четырех сторон функционального блока имеет своё
определенное значение (роль), при этом:
Верхняя сторона имеет значение “Управление” (Control);
Левая сторона имеет значение “Вход” (Input);
Правая сторона имеет значение “Выход” (Output);
Нижняя сторона имеет значение “Механизм” (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой
системы должен иметь свой уникальный идентификационный номер.
Рис. 3. Функциональный блок.
40
Вторым “китом” методологии IDEF0 является понятие интерфейсной
дуги (Arrow). Также интерфейсные дуги часто называют потоками или
стрелками. Интерфейсная дуга отображает элемент системы, который
обрабатывается функциональным блоком или оказывает иное влияние на
функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является
однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое
уникальное наименование (Arrow Label). По требованию стандарта,
наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той
или иной степени определяющие процессы, происходящие в системе. Такими
объектами могут быть элементы реального мира (детали, вагоны, сотрудники
и т.д.) или потоки данных и информации (документы, данные, инструкции и
т.д.).
В зависимости от того, к какой из сторон подходит данная
интерфейсная дуга, она носит название “входящей”, “исходящей” или
“управляющей”. Кроме того, “источником” (началом) и “приемником”
(концом) каждой функциональной дуги могут быть только функциональные
блоки, при этом “источником” может быть только выходная сторона блока, а
“приемником” любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по
требованиям стандарта должен иметь по крайней мере одну управляющую
интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс
должен происходить по каким-то правилам (отображаемым управляющей
дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его
рассмотрение не имеет никакого смысла.
При построении IDEF0 – диаграмм важно правильно отделять
входящие интерфейсные дуги от управляющих, что часто бывает непросто. К
примеру, на рисунке 2 изображен функциональный блок “Обработать
заготовку”.
41
В реальном процессе рабочему, производящему обработку, выдают
заготовку и технологические указания по обработке (или правила техники
безопасности при работе со станком). Ошибочно может показаться, что и
заготовка, и документ с технологическими указаниями являются входящими
объектами, однако это не так. На самом деле в этом процессе заготовка
обрабатывается по правилам, отраженным в технологических указаниях,
которые должны соответственно изображаться управляющей интерфейсной
дугой.
Рис. 4. Управляющая интерфейсная дуга.
Другое дело, когда технологические указания обрабатываются главным
технологом и в них вносятся изменения. В этом случае они отображаются
уже входящей интерфейсной дугой, а управляющим объектом являются,
например, новые промышленные стандарты, исходя из которых производятся
данные изменения.