WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 13 | 14 || 16 | 17 |   ...   | 27 |

ПРОВЕДЕНИЕ ФИНАНСОВОГО АНАЛИЗА В «1С: ПРЕДПРИЯТИЕ» Е. И. Богунова Филиал Кемеровского государственного университета в г. Анжеро-Судженске Выдвижение на первый план финансовых аспектов деятельности субъектов хозяйствования, возрастание роли финансов – характерная для всех стран тенденция. Профессиональное управление финансами неизбежно требует глубокого анализа, позволяющего более точно оценить неопределенность ситуации с помощью современных количественных методов исследования. В связи с этим существенно возрастает приоритетность и роль финансового анализа. Финансовый анализ – это комплексное системное изучение финансового состояния предприятия (ФСП) и факторов его формирования с целью оценки степени финансовых рисков и прогнозирования уровня доходности капитала.

Основные задачи анализа:

1) своевременная и объективная диагностика финансового состояния предприятия, установление его «болевых точек» и изучение причин их образования;

2) поиск резервов улучшения финансового состояния предприятия, его платежеспособности и финансовой устойчивости;

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

Для проведения финансового анализа существует много программных продуктов. Эти продукты условно можно разделить на две категории:

1) небольшие приложения, которые проводят финансовый анализ на основе внешних данных. Основной недостаток этих приложений – это то, что хранение и накопление данных и их анализ проводятся в разных приложениях;

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

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

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

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

1) показатели ликвидности;

2) показатели платежеспособности;

3) показатели рентабельности (прибыльности);

4) показатели эффективности использования активов;

5) показатели рыночной активности.

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

ПОСТРОЕНИЕ АРХИТЕКТУРЫ СЕРВЕРА РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ К. Ю. Войтиков, П. Н. Тумаев Филиал Кемеровского государственного университета в г. Анжеро-Судженске В то время как параллельное программирование со сложными алгоритмами разделения потоков – удел суперкомпьютеров, высокопроизводительных кластеров и высокоскоростных сетей, существует целый пласт задач, также нуждающихся в огромных вычислительных мощностях, но практически решаемых при помощи массивов обычных персональных компьютеров и существующих сетей общего назначения. К таким задачам можно отнести многократное решение задач, зависящих от случайных величин, и сбор статистики результатов таких вычислений.

В [1] была сформулирована задача организовать работу объектноориентированной системы имитационного моделирования [2], используя для расчетов распределенную компьютерную сеть. Модель системы была дополнена двумя ключевыми в данном контексте компонентами: GRIDServer и GRID-Client. GRID-Client – компонент, агрегирующий в себя компоненты, участвующие в расчетах, и обеспечивающий их связь с сервером;

GRID-Server – компонент, осуществляющий разделение заданий на сегменты, обеспечивающий координацию Удаленных Калькуляторов (компьютеров, использующихся для расчетов) и клиентов системы, а также хранящий задания и результаты расчетов. Также была представлена общая структура данных компонентов.

Рассмотрим внутреннюю организацию компонента GRID-Server более подробно.

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

Кроме всего прочего, она включает необходимость описать большое количество правил бизнес-логики в отношениях между сущностями системы, не усложняя структуру самой системы без необходимости. Исходя из этого, для создания модели компонента GRID-Server было решено воспользоваться архитектурным решением «Модель предметной области» [3]. Вдобавок это облегчит понимание системы разработчиками дополнительных модулей (о которых будет сказано ниже). Кроме этого, в дальнейшем планируется прибегнуть к xml-сериализации объектов системы, для хранения их на диске и возможности работать с ними, как с любыми другими документами (копировать, переносить, отправлять по электронной почте и т. д.). В таком случае наличие в системе объектов, четко соответствующих сущностям предметной области системы в реальном мире, позволит получать логичные, легко воспринимаемые человеком схемы xml-файлов.

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

На основе выделенных сущностей была построена модель классов предметной области системы, представленная на рис. 1.

Помимо классов, представляющих основные сущности предметной области, в данной модели также присутствуют классы TaskRepository, GridTaskRepository и GridClientRepository, являющиеся хранилищами заданий, подзаданий и карточек Grid-клиентов соответственно. Фактически вся связь других компонентов системы с моделью предметной области (например, добавление нового задания, получение списка подзаданий для заданного GRID-клиента и т. д.) будет осуществляться только через эти хранилища.

Для достижения высокой степени повторной используемости компонентов системы, а точнее, для реализации возможности использовать однажды развернутую систему для выполнения любых расчетов, реализован механизм расширения вычислительной функциональности системы при помощи подключаемых модулей. Как видно из диаграммы классов, представленной на рис. 1, класс Task не описывает задание системы сам по себе, на него ложится лишь обязанность хранения самой общей информации о задании, например, такой как необходимое количество результатов подзадний. Все же логическое описание задания и его численные параметры хранятся в экземпляре класса TaskContent. Сам по себе класс TaskContent является абстрактным и в чистом виде не может содержать какой-либо информации вообще. Для каждого же конкретного вида заданий требуется создать класс, унаследованный от TaskContent, способный хранить необходимые для описания такого задания данные. Помимо этого в модели присутствует ряд других абстрактных классов, совместно реализующих необходимый интерфейс для системы, с одной стороны, и предоставляющих платформу для создания собственных самодостаточных моделей описания заданий и их результатов, а также инструментов для их решения – с другой. Такими классами являются: класс Result, описывающий результат задания, необходимый пользователю системы; класс GridResult, описывающий результат подзадания, то есть конкретного экземпляра выполнения задания GRID-клиентом; и класс Calculator, непосредственно совершающий расчеты. Пример созданного таким образом модуля представлен на рис. 2.

Рис. 2. Механизм создания модуля системы Для описания задания с тремя параметрами от класса TaskContent унаследован класс ConcreteTaskContent с соответствующими полями. Для решения такого рода задач от класса Calculator унаследован класс ConcreteCalculator, «знающий», как поступать с экземплярами класса ConcreteTaskContent, передаваемыми ему при использовании. В качестве результата своей работы ConcreteCalculator возвращает экземпляр, также описанный в модуле класса ConcreteGridResult, потомка класса GridResult.

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

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

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

Литература 1. Тумаев П. Н. Разработка архитектуры системы распределенных вычислений на основе технологии Microsoft WCF // Информационные технологии и математическое моделирование: материалы VIII Всероссийской научно-практической конференции с международным участием (12–13 ноября 2009 г.). – Томск: Изд-во Том. ун-та, 2009. – Ч. 1. – С. 213–215.

2. Войтиков К. Ю., Моисеев А. Н. Модель компонентов распределенной системы моделирования процессов массового обслуживания // Информационные технологии и математическое моделирование: материалы VIII Всероссийской научно-практической конференции с международным участием (12–13 ноября 2009 г.). – Томск: Изд-во Том.

ун-та, 2009. – Ч. 1. – С. 122–123.

3. Фаулер М. Архитектура корпоративных программных приложений: Пер. с англ. – М.: Вильямс, 2004. – 544 с.

Работа выполнена при поддержке АВЦП «Развитие научного потенциала высшей школы (2009–2010 годы)», проект № 4761 «Разработка методов исследования немарковских систем массового обслуживания и их применение к сложным экономическим системам и компьютерным сетям связи».

ОСОБЕННОСТИ РЕАЛИЗАЦИИ ЗАДАЧНОГО ПОДХОДА В ОБУЧЕНИИ РЕКУРСИИ В КУРСЕ ИНФОРМАТИКИ Е. И. Гурова, Е. В. Киргизова Лесосибирский педагогический институт – филиал Сибирского федерального университета В нашей статье мы хотим показать, как, используя в процессе обучения множество различных типов задач (задачный подход) по программированию рекурсии, можно сформировать у учеников определенный (продуктивный) тип мышления.

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

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

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

В нашем исследовании мы опираемся на классификацию (см.

табл. 1) и определение учебной задачи, предложенные Г. А. Баллом, который определяет задачу как «систему, обязательными компонентами которой являются: а) предмет задачи, находящийся в исходном состоянии, б) модель требуемого состояния предмета задачи» [1]. В том числе мы определяем задачу через ее структурно-компонентный состав (О. С. Зайцев, У. Р. Рейтман, А. Ф. Эсаулов, И. Я. Лернер и др.) [2].

Таблица Классификация учебных задач (по Г. А. Баллу) 1. Неотнесенные Индивидуальные и родовые задачи, материально-направленные и типы информационные задачи, принципиально неразрешимые и прин задач ципиально разрешимые задачи Индивидуальные и родовые задачи, материально-направленные и информационные задачи, принципиально неразрешимые задачи и принципиально разрешимые задачи, рутинные и нерутинные зада2. Отнесенные чи, задачи, неразрешимые для определенного пользователя, и задатипы задач чи, разрешимые для определенного пользователя, четкие и нечеткие задачи, внешние и внутренние задачи, теоретические и практические задачи На основе анализа задач, приведенных в школьных учебниках по информатике, нами была выявлена типология задач с нетрадиционной формулировкой, решение которых предполагает перестройку известных способов решения, поиск неизвестных решающему закономерностей, способов действий. Основанием разделения задач с нетрадиционной формулировкой на четыре типа является набор известных компонентов задачи.

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

При этом можно сделать вывод, что любую из задач классификации Г. А. Балла можно представить в какой-либо из вышеуказанных формулировок.

Pages:     | 1 |   ...   | 13 | 14 || 16 | 17 |   ...   | 27 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.