Информационные системы в экономике

o Большое табличное поле, куда  будет выведен отчет

o Кнопка формирования обычно  вверху, крайняя справа «Сформировать».

Форма обработки 1С

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

o Может не иметь формы вообще (см. использование обработок как  классы)

o У отчетов и обработок формы  списка нет.

Логика (порядок) работы пользователя в 1С следующая:

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

Пользователь выбирает пункт меню или гиперссылку на рабочем столе  – открывается форма списка 1С

В форме списка 1С пользователь выбирает команду (например добавить) или существующий элемент списка (элемент справочника или документ) и начинает работать с формой 1С.

Закончив работать с документом, пользователь закрывает форму документа 1С и возвращается в форму списка 1С. Закончив с ней – возвращается к меню.

Таким образом пользователь работает всегда с формами 1С, начиная с  форма списка 1С и переходя к  форме элемента 1С. Если программист  не нарисовал формы, то 1С генерирует формы по умолчанию. Они естественно лишены идеальной красоты и совершенства, но работать позволяют.

Автоматически сгенерированная форма  списка 1С обычно содержит минимум  полей (код/наименование и дата/номер  соответственно). Автоматически сгенерированная  форма элемента обычно содержит все поля (реквизиты), перечисленные сверху вниз.

Задача формы 1С – открыться  и ждать действий пользователя. При  действии – отреагировать. Таким  образом основу модуля формы 1С составляют обработчики событий. Это такие  функции, которые вызываются тогда, когда пользователь совершает какое то действие на форме 1С.

Автоматически сгенерированная форма  списка 1С обычно содержит минимум  полей (код/наименование и дата/номер  соответственно). Автоматически сгенерированная  форма элемента обычно содержит все  поля (реквизиты), перечисленные сверху вниз.

Задача формы 1С – открыться  и ждать действий пользователя. При  действии – отреагировать. Таким  образом основу модуля формы 1С составляют обработчики событий. Это такие  функции, которые вызываются тогда, когда пользователь совершает какое то действие на форме 1С.

 

1.2.4 Практические  методы проектирования и внедрения  информационных систем

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

Методы проектирования ИС подразумевают  использование определённых программных  и аппаратных средств, составляющих инструментальные средства программирования ИС.

Метод проектирования включает совокупность трёх составляющих:

1) пошаговой процедуры, определяющей последовательность технологических операций проектирования (Приложение №1, рис.6);

2) критериев и правил, используемых  для оценки результатов выполнения  технологических операций;

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

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

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

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

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

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

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

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

• проектирования;
• оформления проектной документации;
• пользовательского интерфейса.

Проектирование вообще и ИС в  частности обычно осуществляется поэтапно. В общем случае основные этапы  проектирования, заключаются в проведении некоторой последовательности исследований (Приложение №1, рис.7).

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

Наиболее часто при проектировании ИС используют технологии и методы системного проектирования.

Системное (предварительное, концептуальное) проектирование включает в себя следующие  стадии:

1) определение общих целей проектирования с формированием локальных (отдельных) целей разработки;

2) формирование концепции системы  (объекта исследования) и подготовки  данных для создания модели  объекта; 

3) разработки описания системы  в виде структур объекта  проектирования и построения функциональных подсистем объекта;

4) формализация задач проектирования, в том числе формирование области  поиска решений, систем предпочтений  и ограничений, требований к  объекту и т.п. 

Результатом системного (концептуального) проектирования является разработка ТЗ и, при необходимости, технико-экономического обоснования.

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

КОНЦЕПТУАЛЬНОЕ  ПРОЕКТИРОВАНИЕ

Концептуальное проектирование порой  называют техническим. Его основными этапами являются:

1) предварительное проектирование,

2) эскизное (рабочее или техно-рабочее)  проектирование,

3) изготовление, испытания и доводка  опытного образца системы (Приложение №1, рис.8).

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

В ходе выполнения последующих стадий проектирования предполагается более глубокая и детализированная проработка решений, выработанных на данной стадии. При этом не исключается появление необходимости их существенного изменения. Хотя действующие нормативные документы предусматривают возможность, внесение изменений в проект или программу (концепцию), как правило, это связано с потерями финансовых, материальных и трудовых ресурсов как со стороны “Заказчика”, так и “Разработчика”. Указанные потери могут оказаться весьма значительными, если необходимо вносить весомые изменения в первоначальные проектные решения и чем позже эта потребность возникает. Отсюда следует особая значимость данной стадии проектирования для успешного создания АИС, а также ответственность Разработчиков и Заказчика при выполнении работ и согласовании итогового документа.

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

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

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

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

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

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

Результатом концептуальной стадии проектирования АИС является итоговый документ –  “Концептуальный проект”, “Аванпроект”, “Пилотный проект” или “Концепция и программа создания…”. В дальнейшем будут преимущественно использоваться термины “Концептуальный проект” и “Концепция” или “программа создания…”.

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

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

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

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

 

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