Проектирование информационных систем. Секреты успешного проектирования ИС (информационной системы) на примере строительства поликлиники — mashamult.ru

Введение

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

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

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

Проектирование информационных систем обхватывает три главные области:

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

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

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

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

Если разобраться, то так ли уж непредсказуемо развитие системы и вправду
ли получить информацию о ней нереально? Возможно, представление о системе в
целом и о предполагаемых (управлением) путях ее развития можно получить средством
семинаров. Опосля этого разбить сложную систему на наиболее обыкновенные составляющие,
упростить связи меж компонентами, предугадать независимость компонент
и обрисовать интерфейсы меж ними (чтоб изменение 1-го компонента автоматом
не тянуло за собой существенного конфигурации другого компонента), также способности
расширения системы и «заглушки» для нереализуемых в той либо другой версии системы
функций. Исходя из схожих простых суждений описание того, что предполагается
воплотить в информационной системе, уже не кажется настолько мистическим. Можно
придерживаться традиционных подходов к разработке информационных систем, один
из которых — схема «водопада» (рис. 1) — описан ниже. Коротко
будут рассмотрены и некие остальные подходы к разработке информационных систем,
где внедрение частей, обрисованных в схеме «водопада», также допустимо.
Какого подхода из описываемых ниже придерживаться (и есть ли смысл выдумывать
свой подход) — в некий мере дело вкуса и событий.

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

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

Ниже мы разглядим некие схемы разработки проекта.

«Водопад» — схема разработки проекта

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

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

Стратегия

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

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

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

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

В документе непременно должны быть описаны:

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

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

Необходимо подчеркнуть, что и на шаге выбора стратегии, и на шаге анализа, и при
проектировании независимо от способа, используемого при разработке проекта, постоянно
следует систематизировать планируемые функции системы по степени значимости. Один
из вероятных форматов представления таковой систематизации — MoSCoW — предложен
в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley,
1994.

Эта аббревиатура расшифровывается так: Must have — нужные функции; Should
have — предпочтительные функции; Could have — вероятные функции; Won’t have — отсутствующие
функции.

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

Анализ

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

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

Аналитики собирают и фиксируют информацию в 2-ух взаимосвязанных формах:

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

2-мя традиционными плодами анализа являются:

иерархия функций, которая разбивает процесс обработки на составные части
(что делается и из что это состоит);
модель «сущность-связь» (Entry Relationship model, ER-модель), которая
обрисовывает сути, их атрибуты и связи (дела) меж ними.

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

Ниже мы разглядим три более нередко используемые методологии структурного анализа:

диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые
служат для формализации инфы о сущностях и их отношениях;
диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для
формализации представления функций системы;
диаграммы переходов состояний (State Transition Diagrams, STD), которые
отражают поведение системы, зависящее от времени; диаграммы актуальных циклов
сущностей относятся конкретно к этому классу диаграмм.

Нормализация

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

Допустимые типы связей. При не далеком рассмотрении связи типа «один к одному»
(рис. 7) практически постоянно оказывается, что A и B представляют
собой в реальности различные подмножества 1-го и такого же предмета либо различные
точки зрения на него, просто имеющие хорошие имена и по-разному описанные связи
и атрибуты.

Связи «почти все к одному» представлены на рис. 8 .

I — довольно мощная система, предполагающая, что вхождение сути B
не быть может сотворено без одновременного сотворения по наименьшей мере 1-го связанного
с ним вхождения сути A.

II — это более нередко встречающаяся форма связи. Она подразумевает, что каждое
и хоть какое вхождение сути A может существовать лишь в контексте 1-го (и
лишь 1-го) вхождения сути B. В свою очередь, вхождения B могут существовать
как в связи с вхождениями A, так и без нее.

III — применяется изредка. Как A, так и B могут существовать без связи меж ними.

Связи «почти все ко почти всем» представлены на рис. 9 .

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

II — применяется изредка. Такие связи постоянно подлежат предстоящей детализации.

Разглядим сейчас рекурсивные связи (рис. 10).

I — изредка, но имеет пространство. Отражает связи альтернативного типа.

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

III — имеет пространство на ранешних шагах. Нередко отражает структуру «списка материалов»
(обоюдная вложенность компонент). Пример: любой КОМПОНЕНТ может состоять
из 1-го и наиболее (остальных) КОМПОНЕНТОВ и любой КОМПОНЕНТ может употребляться
в одном и наиболее (остальных) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся последующие:
неотклонимая связь «почти все ко почти всем» (рис. 11) и ряд рекурсивных
связей (рис. 12).

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

Диаграммы потоков данных

Логическая DFD (рис. 13) указывает наружные по отношению
к системе источники и стоки (адресаты) данных, идентифицирует логические функции
(процессы) и группы частей данных, связывающие одну функцию с иной (потоки),
также идентифицирует хранилища (накопители) данных, к которым осуществляется
доступ. Структуры потоков данных и определения их компонент хранятся и анализируются
в словаре данных. Любая логическая функция (процесс) быть может детализирована
при помощи DFD нижнего уровня; когда предстоящая детализация перестает быть полезной,
перебегают к выражению логики функции с помощью спецификации процесса (мини-спецификации).
Содержимое всякого хранилища также сохраняют в словаре данных, модель данных
хранилища раскрывается при помощи ER-диаграмм.

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

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

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

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

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

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

Некие принципы проверки свойства и полноты информационной
модели
(источник — Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley,
1990)

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

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

Свойство сущностей

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

Перечень проверочных вопросцев для сути:

Отражает ли имя сути сущность данного объекта?
Нет ли пересечения с иными сущностями?
Имеются ли хотя бы два атрибута?
Всего атрибутов не наиболее восьми?
Есть ли синонимы/омонимы данной сути?
Суть определена стопроцентно?
Есть ли неповторимый идентификатор?
Имеется ли хотя бы одна связь?
Существует ли хотя бы одна функция по созданию, поиску, корректировке,
удалению, архивированию и использованию значения сути?
Ведется ли история конфигураций?
Имеет ли пространство соответствие принципам нормализации данных?
Нет ли таковой же сути в иной прикладной системе, может быть, под иным
именованием?
Не имеет ли суть очень общий смысл?
Достаточен ли уровень обобщения, воплощенный в ней?

Перечень проверочных вопросцев для подтипа:

Отсутствуют ли пересечения с иными подтипами?
Имеет ли подтип какие-нибудь атрибуты и/либо связи?
Имеют ли все они свои собственные неповторимые идентификаторы либо наследуют
один на всех от супертипа?
Имеется ли исчерпающий набор подтипов?
Не является ли подтип примером вхождения сути?
Понимаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный
подтип от остальных?

Свойство атрибутов

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

Перечень проверочных вопросцев для атрибута:

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

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

Перечень проверочных вопросцев для связи:

Имеется ли ее описание для каждой участвующей стороны, буквально ли оно отражает
содержание связи и вписывается ли в принятый синтаксис?
Участвуют ли в ней лишь две стороны?

Не является ли связь переносимой?

Заданы ли степень связи и обязательность для каждой стороны?
Допустима ли система связи?

Не относится ли система связи к изредка применяемым?

Не является ли она лишней?
Не меняется ли она со временем?
Если связь неотклонимая, постоянно ли она отражает отношение к сути, представляющей
обратную сторону?

Для исключающей связи:

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

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

Необходимо подчеркнуть, что на шаге анализа следует уделить внимание функциям анализа
и обработки вероятных ошибок и отклонений от предполагаемого образца работы
системы. Следует выделить более критические для работы системы процессы и обеспечить
для их в особенности серьезный анализ ошибок. Обработка ошибок СУБД (коды возврата),
обычно, представляет собой обособленный набор функций либо одну-единственную
функцию.

Уточнение стратегии

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

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

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

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

КомпьютерПресс 9″2001

1

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

информационная система

структура

методика

вкладывательный проект

административная структура

1. Брыкин И.М., Беклемишев А.В. Оценка, выбор и анализ вкладывательных проектов. – М.: ООО «Интернациональная Медиа Группа», 2011. – 47 с.

2. Бэйли Д.В., Шарп У.Ф., Александер Г.Д. Инвестиции. – М.: ИНФРА-М, 2012. – 1028 с.

3. Виленский П.Л., Лившиц В.Н., Смоляк С.А. Оценка эффективности вкладывательных проектов. Теория и практика: Учеб. Пособие. – М.: Дело, 2008. – 888 с.

4. Кравченко Т.К., Пресняков В.Ф. Инфокоммуникационные технологии управления предприятием – М.: ГУ ВШЭ, 2003. – 272 с.

5. Липсиц И.В., Коссов В.В. Вкладывательный анализ. Подготовка и оценка инвестиций в настоящие активы. – М.: ИНФРА-М, 2014. – 320 с.

6. Светлов Н.М., Светлова Г.Н. Информационные технологии управления проектами – М.: ИНФРА-М, 2012. – 144 с.

7. Шуремов Е. Компьютерный анализ бизнеса. // Мир ПК (Персональный компьютер — компьютер, предназначенный для эксплуатации одним пользователем). – 1998. – № 1. – С. 80–83.

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

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

Посреди имеющихся финансово-аналитических систем можно выделить разработки таковых компаний, как «Эксперт Системс», «Галактика», «ИНЭК», «Альт-Инвест», но их действенное внедрение без доработок административными организационными структурами проблематично, так как обозначенные системы не решают задач оценки проекта во связи с параметрами, приоритетными для административной структуры, но не денежного нрава.

Структура информационной системы

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

Анализ денежного состояния компании, в том числе в динамике;

Анализ денежной части бизнес-плана проекта;

Анализ воздействия кредита на финансовое состояние компании;

Учет ценностей городка в процессе анализа проекта;

Сравнительный анализ проектов нескольких компаний;

Прогноз развития компании и возврата кредитов.

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

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

Бухгалтерского баланса и доп документов по балансу;

Денежной части бизнес-плана проекта;

Доборной инфы, требующейся для учета ценностей административного органа управления.

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

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

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

«Модуль расчета денежных характеристик» производит расчет денежных коэффициентов.

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

«Модуль анализа проекта и визуализации результатов» производит представление результатов анализа аналитическими, графическими и табличными методами.

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

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

Методика анализа вкладывательных проектов

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

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

Таковым образом, имеется L-групп начальных характеристик , где и L-групп относительных характеристик , где , l — номер группы, а kl — порядковый номер показателя в группе.

На базе первичных характеристик формируются Q-групп вторичных характеристик , где q = 1, Q, , а mq — порядковый номер показателя в q-ой группе. Эти характеристики назовем коэффициентами.

На базе характеристик и формируются характеристики динамики их конфигурации в абсолютных и относительных единицах вида

где j — охарактеризовывает номер измерений показателя либо коэффициента.

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

Тогда I = J + 1.

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

В процессе анализа предпринимательского проекта решаются по последней мере три принципные задачки:

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

б) оценка способности кредитования, исходя из ценностей администрации;

Эти задачки решаются в рамках многоуровневого анализа коэффициентов и характеристик.

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

а) На втором и следующих уровнях анализируются другие коэффициенты и характеристики, также динамика их конфигурации.

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

На последующем шаге формируется оценка проекта по пт

б) Для учета интересов администрации вводится доборная группа характеристик {fh} и критерий {χh}, где h = 1,H. Эти характеристики могут быть рассчитаны либо представлены предприятием. Если предприятие не соответствует аспектам, оно исключается из группы потенциально кредитуемых.

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

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

где ζ — номер сценария;

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

Также веса определяются для участвующих в рейтинге групп характеристик и коэффициентов, т.е. , где d ζ — номер группы, а D ζ
— общее число групп, участвующих в оценке;

Веса меньше 1, суммы весов всякого набора по всей выборке равны 1.

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

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

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

д) чем выше R ζ
s, тем выше рейтинг s-го компании в ζ
-ом сценарии оценки.

Нормировкой {R ζ
s} по , можно расставить компании в порядке возрастания либо убывания их рейтинга. Рейтинг по показателям , и fh можно проводить раздельно.

Заключение

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

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

Библиографическая ссылка

Клевцов С.И., Клевцова А.Б. МОДЕЛЬ ИНФОРМАЦИОННОЙ СИСТЕМЫ АНАЛИЗА ИНВЕСТИЦИОННЫХ ПРОЕКТОВ ДЛЯ АДМИНИСТРАТИВНЫХ СТРУКТУР // Фундаментальные исследования. – 2016. – № 12-1. – С. 58-61;
URL: http://fundamental-research.ru/ru/article/view?id=41046 (дата воззвания: 26.04.2019).
Предлагаем вашему вниманию журнальчики, издающиеся в издательстве «Академия Естествознания»

Выслать свою неплохую работу в базу познаний просто. Используйте форму, расположенную ниже

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

Подобные документы

курсовая работа , добавлен 10.07.2014

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

дипломная работа , добавлен 03.07.2015

Цель сотворения информационной системы. Автоматическая информационная система «Строительное предприятие». Внедрение вычислительной техники и программного обеспечения для сотворения автоматической информационной системы управления на предприятии.

курсовая работа , добавлен 04.01.2011

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

дипломная работа , добавлен 20.07.2014

Рассмотрение сотворения модели информационной системы при помощи AllFusion Process Modeler 4.1 (Bpwin4.1) в эталоне IDEF0. Описание диаграммы дерева узлов. Анализ сотворения модели данных склада. Свойства информационной модели в нотации IDEF1X.

курсовая работа , добавлен 10.04.2015

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

дипломная работа , добавлен 17.07.2012

Виды, систематизация и состав информационных систем. Понятия «производственный процесс» и «бизнес-процесс». Анализ структуры управления и состояния информатизации компании ООО «Грин Строй», разработка информационной системы на базе процессного подхода.

курсовая работа , добавлен 24.02.2014

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

контрольная работа , добавлен 20.02.2012

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

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

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

Цель проектирования информационной системы и связанные понятия

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

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

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

Организация проектирования ИС

Компанию проектирования ИС принято делить на 2 типа:

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

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

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

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

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

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

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

Декомпозиция может иметь несколько уровней, что дозволяет выделить классы ТПР:

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

Возможность реализации модульного подхода считается достоинством элементных ТПР. Но в случае несовместимости различных частей процесс их объединение приводит к повышению издержек. Подсистемные ТПР, кроме реализации модульного подхода, дают возможность провести параметрическую настройку на объекты различных уровней управления. Задачи с объединением появляются в случае вербования продукта нескольких различных производителей ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств). Не считая того, адаптивность ТПР с позиций непрерывного реинжиниринга действий считается недостаточной. Объектные ТПР, по сопоставлению с прошлыми классами, различаются огромным количеством плюсов:

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

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

Главные методологии проектирования ИС

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

SADT
. Методология многофункционального моделирования работ, которая базирована на структурном анализе и графическом представлении организации как системы функций. Здесь выделяется многофункциональная, информационная и динамическая модели. В истинное время методология известна как нотация (эталон) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие действия, снизу – объекты управления, слева – входные данные, а справа – выходные.
RAD
. Методология резвой разработки приложений. В RAD стремительная разработка приложений вероятна за счёт внедрения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно показать в макете, а проект поделить на многофункциональные элементы.
RUP
. В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе многофункциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных маленьких проектов со своими планами и задачками. Для итерационного цикла свойственна повторяющаяся оборотная связь и адаптация к ядру ИС.

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

Информационная система управления проектами
[англ. — Project Management Information System]. Удачная и продуктивная проектная деятельности организации невозможна без внедрения информационных технологий. С целью автоматизации действий и консолидации данных управления проектами выступает информационная система управления проектами, которая представляет собой равновесный организационно-технологический комплекс программных, технических и информационных средств и инструментов, направленный на реализацию, поддержку и увеличение эффективности действий управления проектами. ИСУП является неотъемлемой частью корпоративной системы управления проектами (КСУП).

База информационной системы управления проектами -это единое информационное место, позволяющая в разы повысить свойство и эффективность управления проектами в организации в протяжении всего актуального цикла проекта и программки за счет поддержки действий управления проектом. Некие ИСУП нацелены не только лишь на проекты и программки, да и на автоматизацию действий управления ранцем компании, что даёт возможность управлять стратегическим планированием. Функционал информационной системы управления проектами делает последующие задачки:

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

Обилие информационных систем управления проектами

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

Локальные информационные системы управления проектами. В главном предназначаются для малого бизнеса, личных бизнесменов и компаний, в каких фактически нет проектной деятельности, кроме 1-го — 2-ух маленьких проектов. Плюсы таковых систем в дешевизне и доступности. В качестве примера можно привести Microsoft Project Standart либо Professional, Open Project и д.р.
Серверные информационные системы управления проектами. Глобальное решение, направленное на средний и большой бизнес, в задачки которого заходит автоматизация проектного управления на уровне проекта, программки, ранца проектов (либо нескольких ранцев) и автоматизация действий проектного кабинета. Данные системы очень распространенны в мире, и большая часть ведущих компаний употребляют конкретно их, для управления проектами. Минусы в дороговизне внедрения и сопровождения, необходимость укомплектовывать штат компании. Фаворитами таковых систем являются Oracle Primavera, HP Project and Portfolio Management Center, Enterprise Project Management Solutions. К слову почти все из этих систем уже сейчас предоставляют решение на базе веб технологий, как описано ниже.
Информационные системы управления проектами на базе веб технологий. Современный подход к предоставлению услуг, по функционалу не отличающийся от серверных решений, но позволяющий компаниям не внедрять у себя это решение, закупая много специального оборудования (компы, сервера) и формируя штат персонала поддержки и сопровождения, а употреблять современный подход — пасмурные технологии на базе которых посторонняя компания удаленно предоставляет нужный функционал, что дозволяет употреблять мощности поставщика услуг и понижает издержки на внедрение и сопровождение. Минусы состоят в том, что Вы передаёте всю информацию по проектной деятельности посторонней компании, которая отвечает за их сохранность и эти системы на нынешний денек не настолько функциональны, нежели серверные решения, также они наименее настраиваемые. Как пример можно привести такие решения — IBN, COMINDWORK, МЕГАПЛАН.

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

Источник: knia.ru