Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Информация о ведущих видах расчета из различных источников



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

В справке Конфигуратора приведено описание предопределенной табличной части ПВР ВедущиеВидыРасчета, но нет правил заполнения ведущих ВР.

Ведущие виды расчета используются для перерасчета неактуальных записей в регистрах расчета. Необходимость указания ведущих видов расчета продемонстрирована на примере. Пусть ВР "А" является базовым для ВР "Б", а тот в свою очередь является базовым для ВР "В". Если механизм перерасчетов будет опираться только на базовые ВР, то при изменениях по ВР "А" выяснится необходимость перерасчета только для ВР "Б". И только после внесения изменений (перерасчета) по ВР "Б" выяснится необходимость перерасчета для "В". Правильное использование ведущих ВР позволяет избежать подобных многоэтапных перерасчетов. В данном примере для ВР "В" нужно указать ведущие ВР "А" и "В".

Ведущий вид расчета - вид расчета, результат которого косвенно влияет на данный вид расчета".

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

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

Если "Невыход" вытесняет "Оклад" по периоду действия, а "Премия" зависит по базовому периоду от "Оклада", то в качестве ведущих для "Премии" нужно указывать следующие ВР: "Оклад", "Невыход" . То есть, при формировании списка ведущих ВР нужно учитывать транзитивные (или каскадные) зависимости.

Предназначение ведущих ВР - "отразить влияние видов расчета друг на друга. Влияние может возникать:

- при настройке базы,

- при определении вытеснения,

- от каскадной зависимости видов расчета,

- от специфики решаемой задачи.

24. АВТОМАТИЗАЦИЯ ПО ВИДАМ УЧЕТА В 1С.

Мы видим три направления построения системы управленческого учета:

1. Использование таблиц Excel (что является приемлемым для небольших частных компаний, состоящих из 2‒3-х человек).

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

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

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

· Отчеты группы «Денежные средства»,

· Отчет «Продажи»,

· Отчет «Доходы и расходы»,

· Отчет «Оборотные средства»,

· Отчеты «Расчеты с покупателями» и «Расчеты с поставщиками»,

· Отчет «Задолженность покупателей»,

· Отчеты «Динамика задолженности поставщикам» и «Задолженность поставщикам».

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

3. Использование специальных систем оперативного и управленческого учета.

Дальнейшее развитие учёта необходимой управленческой информации на предприятиях ведёт к развитию более объёмной системы сбора информации, нежели это возможно в рамках бухгалтерского учёта.
И для этого используются системы последней версии 1С:Предприятие 8, некоторые из которых претендуют на звание систем ERP-класса.

Управленческий учет, как часть стандартного функционала, есть в системах «1С:Управление торговлей» (УТ), «1С:Управление торговым предприятием» (УТП) и «Управление производственным предприятием» (УПП).

В УТ и УТП набор отчетов для руководителя достаточно велик, присутствуют элементы планирования.

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

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

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

На наш взгляд, автоматизация управленческого учета и бюджетирования на основе УПП (даже если собственно производство отсутствует) — решение, близкое к идеальному.

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


25. ЗАДАНИЕ И ИСПОЛЬЗОВАНИЕ ТИПОВЫХ ОПЕРАЦИЙ В 1С.

Что означает режим «Типовые операции». Режим «Типовые операции» появился еще в более ранних версиях «1С: Бухгалтерии», и, фактически является одним из первых «интеллектуальных» средств облегчения труда бухгалтерам. Начиная с «1С: Бухгалтерии» базовой версии (Проф 2.0), режим «типовых операций» был «оттеснен на второй план» режимом «Документы и расчеты». Используя этот режим, позволяло создавать документы, которые могли регистрировать данные о хозяйственной операции, формировать печатную форму первичных документов и автоматически формировать бухгалтерские проводки.
Что автоматизируют типовые операции. Работу бухгалтера с большинством бухгалтерских программ можно представить в виде следующей простейшей схемы.   1. Хозяйственная операция, произошедшая на предприятии, должна быть представлена в виде группы бухгалтерских проводок. Эти проводки отражают изменение состояния средств, имущества и обязательств предприятия, произошедшее в результате рассматриваемой операции. 2. Проводки вводятся в бухгалтерскую программу. В простейшем случае, достаточно указать дату проводки, корреспондирующие счета и сумму. Как правило, для всех проводок операции должна быть указана одинаковая дата. Корреспондирующие счета проводок обязательно вводятся в соответствии с хранящимся в программе планом счетов, который и определяет структуру учета. 3. Бухгалтерская программа в соответствии с введенными проводками выполняет суммирование и группировку информации по счетам бухгалтерского учета. 4. При помощи имеющихся в программе отчетов бухгалтер сам может увидеть итоговое состояние средств, имущества и обязательств предприятия.   Все бухгалтерские программы имеют целый набор отчетов, которые позволяют увидеть не только итоги, но и их изменение по датам и периодам в различных разрезах. Изложенная выше схема, конечно же, весьма примитивна, однако, она отражает суть процесса. Очевидно, что в рассмотренной схеме наиболее трудоемкими являются первые 2 этапа: оформление хозяйственно операции в виде бухгалтерских проводок и ввод этих проводок в программу. Для автоматизации этих действий и служит режим «Типовые операции».
В каких случаях нужно создавать типовые операции. Однозначного ответа на этот вопрос, конечно, нет. Хотя, скорее всего, ответ должен быть такой: «В любых, если вы считаете, что вам это удобно». Например, вы желаете быстро автоматизировать рутинные действия. Документы типовой конфигурации «1С: Бухгалтерии 7.7» позволяют автоматизировать ввод наиболее часто встречающихся хозяйственных операций. Однако на каждом предприятии существуют свои особенности оформления одних и тех же операций. В этом случае придется либо «подстраиваться» под тот стиль работы, который диктуется документами типовой конфигурации, либо настраивать существующие документы, изменяя их под свои потребности.   Чаще всего мы рекомендуем все-таки использовать существующие документы типовой конфигурации и не изменять их. Причина такой рекомендации заключается в том, что в этом случае вы наиболее просто может загружать обновления программы «1С: Бухгалтерия» и использовать регламентированные отчеты, распространяемые фирмой «1С», без дополнительной настройки этих отчетов. Однако набор документов типовой конфигурации не в состоянии охватить все возможные ситуации, которые могут возникать на предприятии. В тех случаях, когда возможностей существующих документов не хватает, рекомендуется использовать ввод операций вручную. Но если какие- либо хозяйственные операции вы вводите слишком часто, то вместо ввода операций вручную можно создать в Конфигураторе новые виды документов- для автоматизации именно этих хозяйственных операций.   Однако, создание новый видов документов- процесс, требующий определенного опыта работы с программой и времени. И если пока не хватает опыта, и нет времени- нужно как можно быстрее получить результат, то наиболее целесообразный путь- создание и использование типовых операций. Другой пример целесообразности создания именно типовой операции- когда хозяйственная операция происходит достаточно редко, чтобы создавать для нее специальный документ, но все же не настолько редко, чтобы каждый раз вводить ее вручную.   В этом разрезе список типовых операций можно считать своего рода справочником по схемам бухгалтерских проводок. Схема проводок хозяйственной операции, которая встречается достаточно редко, может быть забыта, и, чтобы вспомнить ее, необходимо потратить время. Если такую операцию внести в список типовых операций- «помнить» будет «1С: Бухгалтерия». Можно также посоветовать хранить в списке типовых операций схемы проводок, которые не нужны сейчас, но, возможно, понадобятся в будущем. Например, вы прочитали в экономическом издании статью, в которой излагается порядок оформления в бухгалтерском учете тех или иных хозяйственных операций. Обычно в подобных статьях приводятся и схемы бухгалтерских проводок. Даже если в данный момент приведенные схемы проводок вам не нужны, можно записать предлагаемые схемы проводок в список типовых операций- возможно, они понадобятся позднее.   Наконец, одним из характерных случаев использования типовых операций является такой порядок работы, когда настраивает типовые операции опытный бухгалтер или аудитор, а применяет их для регистрации хозяйственных операций (точнее, первичных документов) работник, мало знакомый либо вовсе не знакомый с бухгалтерским учетом. Кстати, создание типовых операций с такой целью способно существенно повлиять на процесс настройки этих операций.

24. СОСТАВ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ ДЛЯ ПРОЕКТИРОВАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ.

Рабочий проект автоматизированной системы управления. Представляет собой утвержденную в установленном порядке техническую документацию, содержащую уточненные и детализированные обще-системные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности автоматизированной системы управления и уточненный перечень мероприятий по подготовке объекта к внедрению (ГОСТ 19675—74).

Рабочий проект автоматизированной системы управления содержит следующие документы:

1. Ведомость документов рабочего проекта.

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

3. Уточненный расчет экономической эффективности системы по официальной методике.

4. Технология ввода и регистрации информации.

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

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

7. Формы нормативно-справочной информации, инструкции по их заполнению и внесению изменений.

8. Альбом шифров, содержащий систему шифровки и альбом шифров.

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

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

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

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

25. СОДЕРЖАНИЕ И ДОКУМЕНТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ.

Предпроектное обследование объекта выполняется при решении вопроса о создании АСУ для данного объекта. На этом этапе проводятся сбор и подготовка материалов для обсуждения и принятия решения и для выработки общих глобальных требований, которым должна удовлетворять данная АСУ.

Начинается предпроектное обследование объекта автоматизации. На этом этапе привлекаются специалисты заказчика и эксперты, хорошо знакомые с предметной областью, для которой составляется задача.

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

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

Существенное значение при проектировании придается предпроектному обследованию объекта.

Создание АСУ ТСК характеризуется следующей последовательностью технологических операций: предпроектное обследование объекта управления; создание пускового комплекса и внедрение комплекса задач, реализующих информационно-справочный режим функционирования; внедрение задач, оптимизирующих процессы планирования и управления ТСК; внедрение элементов автоматического управления машинами и агрегатами; совершенствование и дальнейшее развитие системы путем внедрения новых задач АСУ.

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

Проектирование КТС САПР начинается с анализа технических требований к системе проектирования, итогов Предпроектного обследования объектов проектирования и исходных данных.

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

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

Технико-экономическое обоснование создания или модернизации АБИС, а также отдельных ее узлов производится на основе выполнения технико-экономического анализа данных, полученных в ходе предпроектного обследования объекта автоматизации. Целью анализа является определение узких мест в действующей организационно-функциональной структуре организации, технологии выполнения работ и выработка исходных предложений на их устранение, в том числе средствами автоматизации.

Технико-экономическое обоснование создания или модернизации АБИС, а также отдельных ее узлов производится на основе выполнения технике-экономического анализа данных, полученных в ходе предпроектного обследования объекта автоматизации. Целью анализа является определение узких мест в действующей организационно-функциональной структуре организации, технологии выполнения работ и выработка исходных предложений на их устранение, в том числе средствами автоматизации.

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

В соответствии с имеющимся в России опытом проектирования ряда АИС различного назначения и сложности проектирование АБИС как правило включает в себя четыре этапа ( стадии) выполнения работ: предпроектное обследование объекта автоматизации, концептуальное, эскизное, техническое и рабочее проектирование. В отдельных случаях некоторые стадии проектирования, например, эскизного и технического проектирования или технического и рабочего проектирования, полностью или частично объединяются. Как следует из примечаний к ГОСТ 34.601 - 90, такое объединение не противоречит установленным нормам.

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

 

26. ИСПОЛЬЗОВАНИЕ СИСТЕМ КЛАССИФИКАЦИИ И КОДИРОВАНИЯ.

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

 

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

порядковая

серийно-порядковая

последовательная

параллельная

шахматная

система кодирования с повторениями.

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

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

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

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

систематизация объектов внутри каждого классификационного множества и отнесения объектов к конкретному классу.

выбора оснований кодов с учетом требований и спецификации ИС.

проведение кодирования объектов и оформления материалов кодирования.

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

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

разработка инструктивных и методических материалов для пользователей системы.

27. МЕТОД СТРУКТУРНОГО ПРОЕКТИРОВАНИЯ СИСТЕМ УПРАВЛЕНИЯ.

Метод SADT (Structured Analysis and Design Technique) - структурный анализ и техническое проектирование разработан Дугласом Россом в 1973 г. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др.

Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 (Icam DEFinition) — подмножества SADT. IDEF0 был утвержден в качестве федерального стандарта США, его подробные спецификации можно найти на сайте http://www.idef.com. Семейство стандартов IDEF мы рассмотрим боле подробно в следующем разделе. Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Основные элементы этого метода основываются на следующих концепциях.

1. Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих "ограничения".

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

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

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

Метод SADTможет использоваться для моделирования самых разнообразных систем и определения требований и функций с последующей разработкой информационной системы, удовлетворяющей этим требованиям и реализующей эти функции. В существующих системах метод SADT может применяться для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются. Здесь мы рассмотрим три технологии моделирования SADT: метод функционального моделирования IDEF0, метод описания бизнес-процессов IDEF3 и метод построения диаграмм потоков данных (DFD). Все описанные подходы входят в семейство стандартов IDEF (Integrated DEFinition), полный перечень и назначение которых приведены в следующем разделе.

Семейство стандартов IDEF во многом обязано появившейся в 80-х гг. технологии автоматизированной поддержки разработки информационных систем CASE (Computer Aided Software Engineering). В последнее время CASE-технологии приобретают все большее распространение для моделирования и анализа деятельности предприятий, предоставляя богатый набор возможностей для оптимизации или, в терминах CASE, реинжиниринга технологических процедур, выполняемых этими предприятиями — бизнес-процессов. Значительная часть SADT была принята ВВС США как часть их программы интегрированной компьютерной поддержки производства (Integrated Computer-Aided Manufacturing — ICAM). Эта технология, переименованная в IDEF0, довольно быстро стала стандартом технологии моделирования деятельности в министерстве обороны США.

В 1993 г. группа пользователей IDEF совместно с Национальным институтом стандартов и технологии предприняли попытку создания документированного стандарта для IDEF0, который мог бы использоваться как военными, так и гражданскими департаментами правительства США. Этот стандарт был опубликован как федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS).

Несколько независимо, но с использованием аналогичных подходов технология DFD (Data Flow Diagrams — диаграммы потоков данных) завоевала популярность для структурной разработки, а впоследствии и структурного анализа проектов построения информационных систем. Диаграммы потоков данных во многом аналогичны моделям IDEF0 и могут быть использованы при проектировании информационных систем, например, после разработки моделей анализа IDEF0. Стандарт IDEF3 был специально разработан для закрытого проекта ВВС США. Это технология получения описания деталей процесса от экспертов в предметной области и разработки таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, эта технология приобрела широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0.

28. РАБОТА СИСТЕМЫ УПРАВЛЕНИЯ НА КАЖДОМ ЭТАПЕ ЖИЗНЕННОГО ЦИКЛА.

В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла.

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

Опыт создания и использования заказных ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

· анализ - определение того, что должна делать система;

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

· разработка - создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое;

· тестирование - проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа;

· внедрение - установка и ввод системы в действие;

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

Этапы разработки, тестирования и внедрения ИС обозначаются единым, объемлющим термином - реализация.

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

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

29. CASE – ТЕХНОЛОГИИ ПРИ РАЗРАБОТКЕ АВТОМАТИЗИРОВАННЫХ СИСТЕМ УПРАВЛЕНИЯ.

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

 1. Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятия:

· определение организационно-штатной структуры предприятия;

· определение функциональной структуры предприятия;

· определение перечня целевых функций структурных элементов - подразделений и должностных лиц;

· определение круга и очередности обследования структурных элементов системы управления согласно сформулированным целевым функциям;

· обследование деятельности выделенных структурных элементов;

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

2. Разработка моделей деятельности структурных элементов и системы управления в целом:

· выделение множества внешних объектов, оказывающих существенное влияние на деятельность структурного элемента;

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

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

· спецификация информационных потоков между основными процессами деятельности, уточнение связей между процессами и внешними объектами;

· оценка объемов, интенсивности и других необходимых характеристик информационных потоков;

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

· объединение DFD-моделей структурных элементов в единую модель системы управления предприятием.

3. Разработка информационных моделей структурных элементов и модели информационного пространства системы управления:

· определение сущностей модели и их атрибутов;

· проведение атрибутного анализа и оптимизация сущностей;

· идентификация отношений между сущностями и определение типов отношений;

· разрешение неспецифических отношений;

· анализ и оптимизация информационной модели;

· объединение информационных моделей в единую модель информационного пространства.

· Разработка предложений по автоматизации системы управления предприятия:

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

· составление перечня подсистем и логических АРМов (автоматизированных рабочих мест), определение способов их взаимодействия;

· разработка предложений по очередности проектирования и реализации подсистем и отдельных логических АРМов, входящих в состав ИС;

· разработка требований к средствам базового технического обеспечения ИС;

· разработка требований к средствам базового программного обеспечения ИС.

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

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

Построенная модель является законченным результатом по следующим причинам:

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

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

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

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

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

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

 


Поделиться:



Последнее изменение этой страницы: 2019-03-31; Просмотров: 316; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.094 с.)
Главная | Случайная страница | Обратная связь