ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К БУДУЩЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ

Решение любой задачи заключается в достижении определенной конечной цели. Кроме того, все задачи объединяет еще одно понятие — «управление». Мы настолько привыкли к этому слову, что практически не задумываемся над его сущностью. А между тем это понятие чрезвычайно важно для понимания наших действий вообще и формулирования задач в частности. Оно относится к любой системе: экономической, технической, биологической, социальной и т.п.

Управление — это процесс поддержания системы в заданных параметрах путем обработки информации о текущем состоянии системы и принятия на этой основе решений о воздействии на систему. Ключевым словом в этом определении является «информация», т.е. можно сказать, что управление основано на информации.

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

В [42, с. 192] в качестве задач маркетинга указаны, в частности, следующие:

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

. учет требований покупателей к характеристикам продукции;

  • • учет каналов распространения товаров.
  • 3) по функции анализа:
    • • анализ жизненного цикла товара;
    • • оценка конкурентоспособности товара и исследование конкурентной среды;
    • • оценка эффективности рекламы.

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

  • • учет посетителей сайта;
  • • расчет скидки на товар;
  • • анализ продаж.

Более четкое название задачи предполагает и наличие более простого последующего алгоритма решения. В свою очередь, чем проще алгоритм, тем меньше ошибок может быть сделано при его реализации. Это позволяет ускорять процесс отладки программ и в конечном счете сокращать время разработки программного продукта. Но название задачи не обязательно должно включать в себя конкретизацию объектов управления. Например, детализацию задачи «Расчет скидки на товар» необходимо учитывать в разделе математического обеспечения в процессе описания алгоритма. При этом можно предусмотреть, например, такие варианты расчета для:

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

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

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

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

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

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

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

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

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

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

Примеры вариантов периодичности решения:

  • • один раз в месяц;
  • • ежедневно;
  • • ежегодно в последней декаде декабря;
  • • по мере необходимости.

Как правило, любая задача решается не автономно, а имеет взаимосвязи со смежными задачами как внутри определенного комплекса задач (автоматизированного рабочего места (АРМ), подсистемы[1]), так и с другими комплексами задач (АРМ, подсистемами). Такая взаимосвязь может иметь следующие варианты:

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

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

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

выполнении предусмотренных там процедур по подготовке недостающей информации.

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

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

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

  • • не позднее установленной даты;
  • • не позднее регламентированного времени суток;
  • • к заданной дате;
  • • к заданному времени суток;
  • • не менее чем за указанное количество дней до установленной даты и т.д. К числу специфических особенностей задачи можно отнести, в частности, следующие:
    • 1) одновременное решение задачи в одноименных подразделениях компании;
    • 2) синхронизация анализа результатов решения в одноименных подразделениях организации;
    • 3) регламентированная последовательность анализа результатов;
    • 4) обязательное представление результатов решения в графической форме;
    • 5) обязательное размещение результатов решения в ХД или в архивах;
    • 6) обязательное обобщение результатов решения по определенным показателям перед размещением в ХД или архивах;
    • 7) обязательный предварительный просмотр информации, передаваемой на архивное хранение, в том числе в ХД;
    • 8) обязательное сохранение отсканированных образов документов;
    • 9) автоматическая замена (или удаление) более ранних по хронологии данных и (или) документов;
    • 10) сохранение промежуточных результатов решения в течение заданного интервала времени;
    • 11) просмотр промежуточных результатов;
    • 12) возможность обращения к текстовым документам и т.д.

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

Для интервью характерны следующие особенности:

  • 1) обязательное определение цели, которая должна быть достигнута по окончании;
  • 2) длительность интервью в целях сбора информации об объекте или предмете автоматизации, как правило, не должна превышать 30 минут;
  • 3) наличие у интервьюера минимально необходимого, но достаточного объема знаний о той предметной области, о которой пойдет речь, чтобы не только понимать суть ответов, но и своевременно редактировать при необходимости вектор беседы;
  • 4) предварительная подготовка вопросов. Важно учитывать и сочетать вопросы закрытого типа (т.е. предполагающие ответ «да» или «нет») и отрытого типа (предполагающие развернутый ответ);
  • 5) корректный выбор участников интервью (руководителей или рядовых сотрудников), поскольку в зависимости от их должностного статуса вопросы следует формулировать соответствующим образом. В интервьюировании могут также участвовать клиенты компании;
  • 6) человек, проводящий интервью, должен быть хорошим слушателем, чтобы уметь оперативно реагировать на особенности текущей ситуации и своевременно корректировать подготовленные вопросы согласно реальным ответам того специалиста, с которым интервью проводится;
  • 7) недопустимость критики в адрес работника, участвующего в интервью;
  • 8) у интервью, как источника информации, есть одна существенная проблема: человек, излагающий свою точку зрения на поставленный вопрос, всегда будет в некоторой степени субъективен.

Анкетирование применяется достаточно широко, но его эффективность будет высокой при соблюдении нескольких условий:

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

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

Для того чтобы проектируемая система интернет-маркетинга была актуальной и могла сохранять свою работоспособность в течение определенного времени, при ее создании должны использоваться самые современные ИТ. А для этого проектировщикам надо постоянно отслеживать все изменения, происходящие в данной сфере (включая информационное, техническое, программное, лингвистическое обеспечение), и при необходимости проектировать новые технологии. Например, в настоящее время популярной технологией для создания сайта с динамическим содержанием является система управления содержимым, т.е. контентом (Content Management System, CMS), позволяющая «собирать» сайт по принципу конструктора «Лего». Причем важно, что из одних и тех же элементов можно собрать самые различные «конструкции», наполняя предлагаемые структуры соответствующим содержанием. В число конструкций, например, включаются следующие:

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

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

  • • поддержка RSS;
  • • баннеры;
  • • web-статистика.

Кроме того, можно создавать:

  • • блоги;
  • • чаты;
  • • форумы;
  • • F.A.Q.;
  • • обмен ссылками;
  • • настраиваемые формы обратной связи;
  • • фотогалереи;
  • • голосования;
  • • интернет-магазин;
  • • поиск по сайту;
  • • платежные системы;
  • • подписки.

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

  • [1] Поскольку не существует единого принятого стандарта по поводу терминологии для выделения отдельных частей ИС, то разные разработчикив процессе декомпозиции системы используют, соответственно, разные подходы: подсистемы, модули, блоки, контуры.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >