Проблема проектиования

2

Содержание

Введение……..2

      Глава 1

                 Стандартные методики внедрения сложных ИС.

Начальная стадия………..4

Стадия уточнения…..6

Глава 2

                    Проектирования ИС

Принципы проектирования информационных систем……..8

Структурный подход к проектированию ИС………….10

Выходная информация…13

Введение

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

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

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

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

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

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

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

получение информации;

переработка информации;

анализ, подготовка и принятие решения.

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

Стандартные методики внедрения сложных ИС.

Начальная стадия

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

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

Основные риски этапа:

      формулирование идеи проекта в технических терминах, а не в терминах бизнеса;

      излишне широкие функциональные и/или  организационные рамки проекта, не позволяющие реализовать его разумные сроки;

      выбор неадекватной технической платформы

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

Стадия уточнения

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

Стадия уточнения разбивается на этапы обследования, проектирования:

      функциональная модель;

      каталог документов

      описание правил бизнеса

      описание справочника.

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

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

Правило бизнеса представляет собой типовой алгоритм ведения в ситуациях, стандартных для бизнеса.

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

Изолированное описание функций, документов, правил бизнеса и справочников недостаточны. Крайне важно описать соотношение функции документов.

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

Глава 2 проектирования информационных систем

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

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

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

Принцип «снизу-вверх». Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства и создание программного аппарата для этого  растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные:

      автоматизацию ведения бухгалтерского аналитического учета:

      автоматизацию технических процессов.

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

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

      управление трудовыми ресурсами;

      управление сбытом;

      управление материально-техническим снабжением;

      управление запасами;

      бухучет;

      анализ хозяйственной деятельности;

      управление производством и тд.

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

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

К недостаткам такого подхода относят трудности с реализацией обмена информацией между подсистемами и избыточного бора т обработки информации.

Структурный подход к проектированию ИС

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

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

      принцип «разделяй и властвуй»- для решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

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

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

      внешние сущности;

      системы/подсистемы;

      накопители данных;

      потоки данных.

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

Системы и подсистемы. При построении модели сложной ИС она может быть  конкретной диаграммой в виде одной системы, либо декомпозирована на ряд подсистем.

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

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

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО).

ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия  из эксплуатации.

Выходная информация

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

При проектировании выходных данных документов желательно соблюдать следующие правила:

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

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

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