Анализ на информационната система на предприятието. Методи за проектиране на информационни системи и функционален анализ на дейността на организацията

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

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

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

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

Съвременните лидери на публични и частни организации са наясно, че скоростта на обработка на информацията, която непрекъснато се променя и нараства в обем, е въпрос на оцеляване на компанията на пазара и конкурентно предимство. Като цяло, целите на проектите за създаване на информационни системи се свеждат до осигуряване на условия, които позволяват тази информация да бъде получена, обработена и използвана чрез създаване на функционална отказоустойчива система с достатъчно:

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

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

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

Организацията на дизайна на IS обикновено се разделя на 2 вида:

Каноничният дизайн отразява технологичните характеристики на оригиналния (индивидуален) процес.
Типичният дизайн, който се характеризира със стандартно дизайнерско решение (TPR), е възпроизведен и подходящ за многократна употреба.

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

Каноничният дизайн се използва главно за локални и относително малки ИС с минимално използване на стандартни решения. Адаптирането на дизайнерските решения става само чрез препрограмиране на софтуерните модули.

Каноничният дизайн е организиран с помощта на модела на каскадния жизнен цикъл. Това включва разделяне на процеса на следните стъпки и стъпки:

Предпроектен етап. Изработени и съставени технически спецификации. Тоест се формират изискванията за IP, разработва се концепцията му, изготвя се предпроектно проучване и се пишат технически спецификации.
Етапът на проекта предвижда изготвяне на проекти и технически проекти, разработване на работна документация.
Следпроектният етап поражда дейности по внедряване на ИС, обучение на персонала и анализ на резултатите от тестовете. Част от този етап е поддръжката на ИС и отстраняването на установените недостатъци.

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

Типичният метод на проектиране се отличава с възможността за декомпозиране на проектираната ИС с разделяне на компоненти, които включват програмни модули, подсистеми, комплекси от задачи и др. За да внедрите компонентите, можете да използвате стандартни решениякоито вече съществуват на пазара и да ги персонализирате за нуждите на определена организация. В същото време типичният дизайн предполага задължителната наличност на документация, описваща подробно TPR и процедурите за настройка.

Декомпозицията може да има няколко нива, което позволява да се отделят класовете на TPR:

елементарен - за отделна задача (елемент),
подсистема - за отделни подсистеми,
обект - индустриални стандартни дизайнерски решения, съдържащи целия набор от подсистеми.

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

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

При внедряването на стандартен дизайн се използват параметрично-ориентирани и моделно-ориентирани подходи.

Основни методологии за проектиране на IC

Специфичните характеристики на процеса на проектиране позволяват да се отделят методологии, базирани на различни принципи. Сред основните съвременни методологии за проектиране на ИС са следните:

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

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

Сервизен център - организация, занимаваща се с предоставяне на услуги за сервизна поддръжка и поддръжка на машини, оборудване и други продукти. Дейността на сервизните центрове включва предпродажбен, гаранционен и следгаранционен ремонт.

Предприятие IP Михайлов А.О. се занимава с ремонт и поддръжка домакински уредии електроника, както и компютри, телефони и таблети, които клиентите носят в офиса, както и зареждане на касети и инсталиране на мрежи и телефонни централи. При невъзможност за доставка на оборудването от самия клиент се извършва посещение на място, като при необходимост се доставя от център за услуги. Когато клиентът се свърже със сервизния център, диспечерът изготвя заявление за приемане на поръчката. Извършва се анализ на обекта, в резултат на който се прави заключение дали оборудването ще бъде ремонтирано или не. Инженеринговият отдел изготвя ценова листа за ремонт и поддръжка на оборудване, като работи с доставчици на резервни части и устройства за ремонт на оборудване. Предстои ремонт специално оборудванеследвайки правилата за безопасност. Фирмата продава и периферни устройства за телефони, таблети и компютри. Предприятието се занимава със закупуване на употребявана и аварирала техника.

Фирмата работи квалифицирани специалистис дългогодишен опит. Директорът контролира цялата работа на предприятието.

Адрес на компанията:

Пермска територия, Кунгур, ул. Ленина 66

Режим на работа:

Пон-Пет: 10 - 19 без обяд

Слънце: почивен ден.

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

Извършеният анализ на предметната област дава пълно описание на предметната област на предприятието IP Михайлов А.О. за създаване на работеща информационна система за това предприятие. Дава се описание на работата на сервизния център, като се посочва работата на инженерния отдел. Създадена е и организационната структура на предприятието, която показва взаимодействието на директора и подчинените.

Оформяне на основни документи за управление на проект за информационна система

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

Управление на проекти - използването на знания, умения, методи, инструменти и технологии при изпълнението на проекта с цел постигане или надхвърляне на очакванията на участниците в проекта.

За правилното управление на проект за информационна система е необходимо да се генерират основни документи за управление на проекта. Основните документи ще бъдат Хартата и Планът за управление на проекта.

Харта на проекта

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

Хартата на проекта документира първоначалните изисквания за проект, които отговарят на нуждите и очакванията на заинтересованите страни.

Има харта на проекта.

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

Хартата на проекта трябва да съдържа следната информация:

Изисквания към проекта и продукта на проекта, в доста обща форма;

Цел на проекта;

Информация за назначения ръководител на проекта и нивото на неговите правомощия;

График на контролните събития;

Връзки между участниците в проекта;

Функционални организации и тяхното участие;

Предположения за организацията и средата, както и външни предположения;

Ограничения относно организацията и средата, както и външни ограничения;

Реален бизнес случай, който служи като обосновка на проекта с данни за възвръщаемост на инвестицията;

Бюджет на проекта.

Хартата на проекта увеличава вероятността за успешно завършване на проекта. Той документира намеренията на участниците в проекта в самото начало на проекта и може да служи като основна точка за разрешаване на спорове между членовете на екипа на проекта и изпълняващата организация.

По време на изготвянето на хартата на проекта, хартата на правилата за организиране на работата на проекта беше извършена с помощта на документация, стратегии, цели, методология на проекта, ролеви функции и правила на проекта, необходими за постигане на бизнес целите на проекта . Определени са отговорници за управлението и изпълнението.

Разработването на харта отнема значително време. При създаването на следващия проект разработената харта може да се използва като шаблон, така че разработването на хартата отнема по-малко време. Хартата на проекта помага при управлението на проекта, тъй като за работа в MS Project е необходима известна информация.

План за управление на проекта

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

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

1 Поддържащи планове за управление на проекти, които включват:

План за управление на обхвата на проекта;

План за управление на графика на проекта;

План за управление на разходите по проекта;

План за управление на качеството на проекта;

План за управление на персонала;

План за управление на комуникациите на проекта;

План за управление на риска по проекта;

План за управление на конфигурацията.

2 Базово ниво на проекта, състоящо се от:

Основен график на проекта;

Основен план за себестойност;

Основен план за качество;

Основен план за конфигурация;

Регистър на риска.

3 Резултати от анализа, извършен от екипа на проекта по отношение на съдържанието, обхвата и графика на проекта.

За проекта на информационната система „Отчитане на предоставените услуги“ е създаден план за управление на проекта. (Приложение Б)

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

Вторият параграф определя целите и задачите на проекта. Целите се формират въз основа на изискванията на клиента, които са автоматизиране на основните бизнес процеси на предприятието. Бяха поставени цели, като привличане на клиенти и увеличаване на печалбите, подобряване на качеството на предоставяните услуги.

Третият параграф определя изискванията към проектното решение и резултатите от проекта. Този раздел е елемент от основното съдържание на проекта. За да се осигури връзка между изискванията на клиента и резултатите от проекта, се препоръчва използването на функцията за качество.

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

Петият параграф определя инструментите и технологиите за осъществяване на управление на проекти.

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

Седмата точка описва нуждата от ресурси. То се определя от сложността на работата, отразена в предварително разработената IBS.

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

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

Десети и единадесети параграф отразяват предположенията и ограниченията от страна на изпълнителя. С напредването на проекта ограниченията може да се променят.

Дванадесетата точка са първоначално формулираните рискове. Посочени са вече известни рискове и основни категории потенциални рискове.

Управлението на риска е процесите, свързани с идентифицирането, анализа на рисковете и вземането на решения, които включват максимизиране на положителните и минимизиране на отрицателните последици от настъпването на рискови събития.

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

Планиране на управлението на риска - избор на подходи и планиране на дейности за управление на риска на проекта.

1 Идентифициране на риска - идентифициране на рискове, които могат да повлияят на проекта и документиране на техните характеристики.

2 Качествена оценка на риска - качествен анализ на рисковете и условията на тяхното възникване, за да се определи влиянието им върху успеха на проекта.

3 Количествено определяне - количествен анализвероятността от възникване и въздействието на последствията от рисковете върху проекта.

4 Планиране на отговора на риска - определяне на процедури и методи за смекчаване на негативните последици от рискови събития и използване на възможни ползи.

5 Мониторинг и контрол на риска - мониторинг на рисковете, идентифициране на оставащите рискове, прилагане на плана за управление на риска на проекта и оценка на ефективността на действията за намаляване на риска.

Представен е планът за управление на риска. (Приложение Б)

Планът за управление на проекта на информационната система „Отчитане на предоставените услуги“ позволи да се създадат документи и да се опишат характеристиките и границите на проекта, услугите, свързани с него, както и методите за приемане и управление на съдържанието. Декларацията за обхвата позволи да се оцени желаният резултат и послужи като основа за базов план за обхват, който да се следва за всички дейности по проекта.

Разработването на базова документация за управление на проекти на информационна система „Отчитане на предоставените услуги“ даде възможност да се опишат някои от документите за качествено и успешно внедряване на управление на проекти в MS Project. Ключът към успеха е разбирането на необходимостта от тези документи в процеса на управление на проекта. Резултатът от тази работа беше разработената харта на проекта и план за управление на проекта, които ще бъдат използвани в по-нататъшната работа.

Резултатът от първия раздел беше структурирането на проекта на ИС „Отчитане на предоставените услуги“ за предприятието IP Михайлов А.О., също бяха разработени хартата на проекта и планът за управление на проекта, които бяха използвани в по-нататъшната работа по управление на проекта . Процесът на генериране на основни документи е най-важната част от управлението на проекта, тъй като влияе върху качеството, продължителността и успеха на проекта.

Въведение

Заключение

Литература

Въведение

развитие различни области човешка дейностна настоящия етап е невъзможно без широко използване Информатикаи създаване на информационни системи от различни направления. Обработката на информация в такива системи се превърна в самостоятелно научно и техническо направление.

След фазата на изграждане информационен моделзапочва проектирането на системата. На този етап изборът технологични решениявъз основа на които ще бъде изградена информационната система.

Информация в модерен святсе превърна в един от най-важните ресурси, а информационните системи (ИС) станаха основен инструментв почти всички сфери на дейност.

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

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

цел контролна работае - разгледайте стъпка по стъпка процеса на създаване на информационни системи.

Целите на тази работа са да се установи основната цел на проектирането, както и целта на създаването на информационни системи.

1. Проектиране на информационни системи

Проектирането на информационни системи винаги започва с определянето на целта на проекта. Основната задача на всеки успешен проекте да се гарантира, че в момента на стартиране на системата и през целия период на нейната експлоатация е възможно да се осигури:

необходимата функционалност на системата и степента на адаптация към променящите се условия на нейното функциониране;

необходимата производителност на системата;

необходимото време за отговор на системата на заявка;

· безпроблемна работа на системата в необходимия режим, с други думи, готовността и готовността на системата да обработва потребителски заявки;

лекота на работа и поддръжка на системата;

необходимата сигурност.

Производителността е основният фактор, който определя ефективността на една система. Добрият дизайн е в основата на високопроизводителна система.

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

проектиране на обекти от данни, които ще бъдат внедрени в базата данни;

проектиране на програми, екранни форми, отчети, които ще осигурят изпълнението на заявки за данни;

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

Според съвременната методология процесът на създаване на ИС е процес на изграждане и последователно трансформиране на редица последователни модели на всички етапи от жизнения цикъл (ЖЦ) на ИС. На всеки етап от жизнения цикъл се създават специфични за него модели - организации, изисквания за IP, IP на проекта, изисквания към приложения и др. Моделите се формират от работни групи на екипа на проекта, съхраняват се и се натрупват в хранилището на проекта. Създаването на модели, тяхното управление, трансформиране и предоставяне за колективно ползване се извършва с помощта на специални софтуерни средства - CASE-инструменти.

Процесът на създаване на IP е разделен на няколко етапа (етапи), ограничени от определени времеви рамки и завършващи с пускането на конкретен продукт (модели, софтуерни продукти, документация и др.).

Обикновено се разграничават следните етапи на създаване на ИС: формиране на системни изисквания, проектиране, внедряване, тестване, въвеждане в експлоатация, експлоатация и поддръжка.

Началният етап от процеса на създаване на ИС е моделирането на бизнес процесите, които протичат в организацията и изпълняват нейните цели и задачи. Организационният модел, описан от гледна точка на бизнес процеси и бизнес функции, ни позволява да формулираме основните изисквания към ИС. Тази фундаментална позиция на методологията осигурява обективност при разработването на изискванията за проектиране на системата. Наборът от модели за описание на изискванията за IS след това се преобразува в система от модели, които описват концептуалния дизайн на IS. Модели на архитектура на ИС, изисквания към софтуер (SW) и информационна поддръжка(И ОТНОСНО). След това се формира софтуерната и IO архитектура, идентифицират се корпоративните бази данни и индивидуалните приложения, формират се модели на изискванията на приложенията и се извършва тяхното разработване, тестване и интегриране.

Целта на началните етапи на създаване на ИС, извършени на етапа на анализ на дейността на организацията, е формирането на изисквания за ИС, които правилно и точно отразяват целите и задачите на клиентската организация. За да определите процеса на създаване на ИС, който отговаря на нуждите на организацията, трябва да разберете и ясно да формулирате какви са тези нужди. За да направите това, е необходимо да се определят изискванията на клиентите за ИС и да се покажат на езика на моделите в изискванията за разработване на проект за ИС по такъв начин, че да се осигури съответствие с целите и задачите на организацията.

Задачата за формиране на изисквания към IP е една от най-отговорните, трудни за формализиране и най-скъпите и трудни за коригиране в случай на грешка. Съвременните инструменти и софтуерни продукти ви позволяват бързо да създавате ИС според готови изисквания. Но често тези системи не удовлетворяват клиентите, изискват многобройни подобрения, което води до рязко увеличение на действителната цена на ИС. Основната причина за тази ситуация е неправилното, неточно или непълно определяне на изискванията за ИС на етап анализ.

На етапа на проектиране на първо място се формират модели на данни. Проектантите получават резултатите от анализа като първоначална информация. Изграждането на логически и физически модели на данни е основна част от дизайна на базата данни. Информационният модел, получен по време на анализа, първо се преобразува в логически, а след това във физически модел на данни.

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

Крайните продукти на етапа на проектиране са:

схема на база данни (базирана на ER модела, разработен на етапа на анализ);

Набор от спецификации за системни модули (те са изградени на базата на функционални модели).

Освен това на етапа на проектиране се извършва и разработването на архитектурата на IS, включително избора на платформа (платформи) и операционна система ( операционна система). В разнороден IS няколко компютъра могат да работят на различни хардуерни платформи и да работят с различни операционни системи. В допълнение към избора на платформа, следните характеристики на архитектурата се определят по време на фазата на проектиране:

дали ще бъде архитектура "файл-сървър" или "клиент-сървър";

Ще бъде ли 3-степенна архитектура със следните слоеве: сървър, мидълуер (сървър на приложения), клиентски софтуер;

Дали базата данни ще бъде централизирана или разпределена. Ако базата данни е разпределена, тогава какви механизми ще се използват за поддържане на последователност и уместност на данните;

• дали базата данни ще бъде хомогенна, тоест дали всички сървъри на бази данни ще бъдат от един и същи производител (например всички сървъри само за Oracle или всички сървъри само за DB2 UDB). Ако базата данни не е хомогенна, тогава какъв софтуер ще се използва за обмен на данни между СУБД на различни производители (вече съществуващи или разработени специално като част от проекта);

· дали ще се използват паралелни сървъри на бази данни (напр. Oracle Parallel Server, DB2 UDB) за постигане на правилна производителност.

Етапът на проектиране завършва с разработване на технически проект на ИС. По време на фазата на изпълнение, създаването софтуероперативна документация.

След приключване на разработката на единичен модул от системата се извършва автономен тест, който има две основни цели:

откриване на модулни повреди (твърди повреди);

Съответствие на модула със спецификацията (наличие на всички необходими функции, липса на ненужни функции).

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

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

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

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

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

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

структура

методология

инвестиционен проект

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

1. Брикин И.М., Беклемишев А.В. Оценка, подбор и анализ на инвестиционни проекти. - М .: ООО "Международна медийна група", 2011. - 47 с.

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

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

4. Кравченко Т.К., Пресняков В.Ф. Инфокомуникационни технологии за управление на предприятието - М.: Държавен университет Висше училище по икономика, 2003. - 272 с.

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

6. Светлов Н.М., Светлова Г.Н. Информационни технологииуправление на проекти - М.: INFRA-M, 2012. - 144 с.

7. Шуремов Е. Компютърен бизнес анализ. // PC свят. - 1998. - № 1. - С. 80–83.

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

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

Сред съществуващите финансови и аналитични системи могат да се откроят разработките на такива фирми като Expert Systems, Galaktika, INEK, Alt-Invest, но тяхното ефективно използване без модификации от административните организационни структури е проблематично, тъй като тези системи не решават проблема проблеми на оценката на проекта по отношение на параметрите, които са приоритетни за административна структурано не и от финансов характер.

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

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

Анализ на финансовото състояние на предприятието, включително в динамика;

Анализ на финансовата част на бизнес плана на проекта;

Анализ на влиянието на кредита върху финансовото състояние на предприятието;

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

Сравнителен анализ на проекти на няколко предприятия;

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

Въз основа на характеристиките и характера на поставените задачи е разработена блокова схема на системата за анализ, показана на фигурата.

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

Счетоводен баланс и допълнителни балансови документи;

Финансова част от бизнес плана на проекта;

Допълнителна информация, необходима за отчитане на приоритетите на административния орган.

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

Структурата на основната част на системата е насочена към реализиране на функциите на анализа на инвестиционни проекти.

Ключова роля играе „Модул за настройка на работна среда и експертна система”. Този модул генерира различни сценариианализ, определение допълнителни правилаи критерии, отразяващи интересите на града и администрацията, определящи критични стойности на финансовите коефициенти.

"Модул за изчисляване на финансови показатели" изчислява финансови коефициенти.

Структурна схема на информационна система за анализ на инвестиционни проекти

„Модул за анализ на проекти и визуализация на резултатите“ представя резултатите от анализа в аналитичен, графичен и табличен вид.

„Модул за генериране на отчети“ е свързан със стандарта софтуерни инструментии е предназначен за изготвяне на отчетни материали.

Експертната система е предназначена да подпомага анализа на получените резултати.

Методика за анализ на инвестиционни проекти

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

Има много първоначални показатели, които са разделени на групи, които характеризират определени аспекти на финансовото състояние на организацията. Тези групи показатели са концентрирани в отделни документи, например счетоводен отчет и др.

По този начин има L-групи от начални показатели , където и L-групи от относителни показатели , където , l е номерът на групата, а kl е поредният номер на показателя в групата.

Въз основа на първичните показатели се формират Q-групи от вторични показатели, където q = 1, Q, , mq е поредният номер на показателя в q-та група. Тези показатели наричаме коефициенти.

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

където j - характеризира броя на измерванията на индикатора или коефициента.

Всеки показател и коефициент се фиксира в определен брой времеви точки. Получените стойности ни позволяват да идентифицираме динамиката на промените в показателите и коефициентите във времето:

Тогава I = J + 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 г.). Предлагаме на Вашето внимание списанията, издавани от издателство "Естествонаучна академия"

Проектиране на информационни системи

Част 1. Етапи на развитие на проекта: стратегия и анализ

Въведение "Водопад" - схема за развитие на проекта Стратегия Анализ ER диаграми дъги Нормализация Диаграми на потока от данни Някои принципи за проверка на качеството и пълнотата на информационния модел Качество на субекта Качество на атрибута Качество на връзката Системни функции Усъвършенстване на стратегията

Въведение

Проектирането на информационни системи винаги започва с определянето на целта на проекта. Основната задача на всеки успешен проект е да гарантира, че по време на стартирането на системата и през целия период на нейната експлоатация е възможно да се осигури:

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

необходимото време за отговор на системата на заявка;

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

лекота на работа и поддръжка на системата;

необходимата сигурност.

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

проектиране на обекти от данни, които да бъдат внедрени в базата данни;

проектиране на програми, екранни форми, отчети, които ще осигурят изпълнението на заявки за данни;

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

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

Смята се, че една сложна система не може да бъде описана по принцип. Това се отнася по-специално за системите за управление на предприятието. Един от основните аргументи е промяна в условията за функциониране на системата, например директивна промяна на определени информационни потоци от новото ръководство. Друг аргумент е обхватът на заданието, което за голям проект може да бъде стотици страници, докато техническият проект може да съдържа грешки. Възниква въпросът: може би е по-добре изобщо да не се провеждат проучвания и да не се прави никакъв технически проект, а да се напише системата „от нулата“ с надеждата, че ще има някакво чудодейно съвпадение на желанието на клиента с това, което са написали програмистите, и също така, че всичко това ще работи стабилно?

Ако погледнете, наистина ли е толкова непредвидимо развитието на системата и наистина ли е невъзможно да се получи информация за нея? Вероятно чрез семинари може да се получи представа за системата като цяло и за начините (управление), предвидени за нейното развитие. След това разбийте сложната система на по-прости компоненти, опростете връзките между компонентите, осигурете независимостта на компонентите и опишете интерфейсите между тях (така че промяната в един компонент да не води автоматично до значителна промяна в друг компонент) , както и възможността за разширяване на системата и "пъни" за нереализируеми в една или друга версия на системата от функции. Въз основа на такива елементарни съображения описанието на това, което трябва да се внедри в информационната система, вече не изглежда толкова нереалистично. Можете да следвате класическите подходи за разработване на информационни системи, един от които е схемата "водопад" ( ориз. 1) е описано по-долу. Ще бъдат разгледани накратко и някои други подходи за разработване на информационни системи, където използването на елементите, описани в схемата "водопад", също е приемливо. Кой подход от описаните по-долу да следвате (и дали има смисъл да измислите свой собствен подход) до известна степен е въпрос на вкус и обстоятелства.

Ориз. 1. Схема на водопада

Жизненият цикъл на софтуера е модел за неговото създаване и използване. Моделът отразява различните му състояния, като се започне от момента, в който възникне нуждата от този софтуер и се стигне до момента, в който той е напълно неизползван за всички потребители. Известни са следните модели на жизнения цикъл:

каскаден модел. Преходът към следващия етап означава пълно завършване на работата на предишния етап.

Етапен модел с междинен контрол. Разработката на софтуер се извършва на итерации с цикли обратна връзкамежду етапите. Корекциите между етапите могат да намалят сложността на процеса на разработка в сравнение с каскадния модел; животът на всеки от етапите се разтяга за целия период на развитие.

спираловиден модел. Специално вниманиесе дава на началните етапи на развитие - разработване на стратегия, анализ и проектиране, където осъществимостта на определени технически решения се проверява и обосновава чрез създаване на прототипи (прототипиране). Всяко завъртане на спиралата включва създаването на определена версия на продукта или някой от неговите компоненти, като същевременно се уточняват характеристиките и целите на проекта, определя се неговото качество и се планира работата на следващото завъртане на спиралата.

По-долу ще разгледаме някои от схемите за развитие на проекта.

Към началото

"Водопад" - схема за развитие на проекта

Много често проектирането се описва като отделен етап от развитието на проекта между анализа и развитието. В действителност обаче няма ясно разделение на етапите на разработване на проекта - дизайнът, като правило, няма ясно дефинирано начало и край и често продължава на етапите на тестване и изпълнение. Говорейки за етапа на тестване, трябва също да се отбележи, че както етапът на анализ, така и етапът на проектиране съдържат елементи от работата на тестерите, например за получаване на експериментална обосновка за избора на конкретно решение, както и за оценка на критериите за качество на получената система. На етапа на експлоатация е уместно да се говори за поддръжка на системата.

По-долу ще разгледаме всеки от етапите, като се спрем по-подробно на етапа на проектиране.

Към началото

Стратегия

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

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

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

Резултатът от етапа на определяне на стратегията е документ, който ясно посочва какво ще получи клиентът, ако се съгласи да финансира проекта; когато получава готовия продукт (работен график); колко ще струва (за големи проекти трябва да се изготви график за финансиране на различни етапи от работата). Документът трябва да отразява не само разходите, но и ползите, например времето за изплащане на проекта, очаквания икономически ефект (ако може да бъде оценен).

Документът трябва да описва:

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

набор от условия, при които се очаква да работи бъдещата система: системна архитектура, хардуер и софтуерни ресурсиосигурени на системата, външните условия за нейното функциониране, състава на хората и работите, които осигуряват гладкото функциониране на системата;

срокове за изпълнение на отделните етапи, форма на предаване на работата, ресурси, включени в процеса на разработване на проекта, мерки за защита на информацията;

описание на функциите, изпълнявани от системата;

бъдещи изисквания към системата в случай на нейното развитие, например способността на потребителя да работи със системата чрез Интернет и др.;

субекти, необходими за изпълнение на системни функции;

интерфейси и разпределение на функциите между човек и система;

изисквания за софтуер и информационни компоненти на софтуера, изисквания за СУБД (ако проектът трябва да бъде изпълнен за няколко СУБД, тогава изискванията за всяка от тях, или Общи изискваниякъм абстрактна СУБД и списък с препоръчани за този проектСУБД, които отговарят на посочените условия);

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

Произведено на този етапРаботата позволява да се отговори на въпроса дали си струва да продължим този проект и какви изисквания на клиента могат да бъдат изпълнени при определени условия. Може да се окаже, че проектът няма смисъл да продължава, например, защото определени изисквания не могат да бъдат изпълнени по обективни причини. Ако бъде взето решение да се продължи с проекта, тогава идеята за обхвата на проекта и оценката на разходите вече е налична за следващия етап от анализа.

Трябва да се отбележи, че на етапа на избор на стратегия, и на етапа на анализ, и по време на проектиране, независимо от метода, използван при разработването на проекта, винаги трябва да се класифицират планираните функции на системата по важност. . Един възможен формат за представяне на такава класификация, MoSCoW, беше предложен в Clegg, Dai и Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Това съкращение означава: Трябва да има - необходими функции; Трябва да има - желани функции; Може да има - възможни функции; Няма да има - липсващи функции.

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

Към началото

Анализ

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

Цялата информация за системата, събрана на етапа на определяне на стратегията, се формализира и прецизира на етапа на анализ. Особено внимание трябва да се обърне на пълнотата на предадената информация, анализа на информацията за липса на противоречия, както и търсенето на информация, която изобщо не се използва или се дублира. По правило клиентът не формира веднага изискванията към системата като цяло, а формулира изискванията към отделните й компоненти. Обърнете внимание на консистенцията на тези компоненти.

Анализаторите събират и записват информация в две взаимосвързани форми:

функции - информация за събития и процеси, които се случват в бизнеса;

entities – информация за неща, които са важни за организацията и за които нещо се знае.

Двата класически резултата от анализа са:

йерархия от функции, която разбива обработката на нейните съставни части (какво се прави и от какво се състои);

модел на същност-връзка (Entry Relationship model, ER-model), който описва същности, техните атрибути и връзки (релации) между тях.

Тези резултати са необходими, но не са достатъчни. Достатъчните резултати включват диаграми на потока от данни и диаграми жизнени циклиобразувания. Доста често възникват грешки в анализа, когато се опитвате да покажете жизнения цикъл на обект в ER диаграма.

По-долу ще разгледаме трите най-често използвани методологии за структурен анализ:

Entity-Relationship Diagrams (ERD), които служат за формализиране на информация за обекти и техните взаимоотношения;

диаграми на потока от данни (Data Flow Diagrams, DFD), които служат за формализиране на представянето на системните функции;

диаграми на прехода на състоянието (State Transition Diagrams, STD), които отразяват поведението на системата в зависимост от времето; Диаграмите на жизнения цикъл на обекта принадлежат към този клас диаграми.

Към началото

ER диаграми

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

Ориз. 2. Пример за ER диаграма

Обектът се показва като правоъгълник с името на обекта в горната част (например ЗАГЛАВИЯ). Кутията може да изброява атрибутите на обект; атрибутите на ER-диаграмите, въведени с удебелен шрифт, са ключови (така че идентичността на заглавието е ключов атрибут на обекта TITLES, други атрибути не са ключови).

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

Единичен ред вдясно ( ориз. 3) означава "един", "птичи крак", отляво е "много", а връзката се чете по реда, като например "един към много". Вертикална черта означава "задължително", кръг - "незадължително", например за всяка публикация в ЗАГЛАВИЕ трябва да се посочи издател в ИЗДАТЕЛИ, а един издател в ИЗДАТЕЛИ може да издава няколко заглавия в ЗАГЛАВИ. Трябва да се отбележи, че връзките винаги са коментирани (надпис на реда, изобразяващ връзката).

Ориз. 3. ER диаграмен елемент

Даваме и пример ( ориз. 4) образи на отразяващата връзка „служител“, където един служител може да контролира няколко подчинени и така нататък надолу по йерархията на позициите.

Ориз. 4. ER диаграма на рефлексивна връзка

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

Атрибутите на обекта могат да бъдат ключови - те са в удебелен шрифт; задължителни - те се предшестват от знака "*", т.е. тяхната стойност винаги е известна, незадължителни (незадължителни) - те се предшестват от O, т.е. стойностите на този атрибут в даден момент могат да бъдат отсъстващи или неопределени.

Към началото

дъги

Ако даден обект има набор от взаимно изключващи се взаимоотношения с други обекти, тогава се казва, че такива взаимоотношения са в дъга. Например, банкова сметка може да бъде издадена или за юридическо лице, или за индивидуален. Фрагмент от ER диаграмата за този тип връзка е показан в ориз. 5.

Ориз. 5. Арк

В този случай атрибутът СОБСТВЕНИК на обекта АКАУНТ има специално значение за този обект - обектът е разделен на типове по категории: "за физическо лице" и "за юридическо лице". Получените обекти се наричат подтипове, а оригиналният обект става супертип. За да се разбере дали е необходим супертип или не, е необходимо да се установи колко от едни и същи свойства имат различните подтипове. Трябва да се отбележи, че злоупотребата с подтипове и супертипове е доста често срещана грешка, както е показано в ориз. 6.

Ориз. 6. Подтипове (вдясно) и супертип (вляво)

Към началото

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

За да се предотвратят аномалии при обработката на данни, се използва нормализация. Принципите на нормализация за обектите на информационния модел са абсолютно същите като за моделите на данни.

Разрешени типове връзки. При по-внимателно разглеждане отношенията едно към едно ( ориз. 7) почти винаги се оказва, че A и B всъщност са различни подгрупи на едно и също нещо или различни гледни точки за него, просто имат различни имена и различно описани връзки и атрибути.

Ориз. 7. Връзки едно към едно

Отношенията много към едно са показани в ориз. 8.

Ориз. 8. Връзки много към едно

I е достатъчно силна конструкция, че запис на обект B не може да бъде създаден без едновременно създаване на поне един свързан запис на обект A.

II е най-често срещаната форма на комуникация. Предполага се, че всяко появяване на обект A може да съществува само в контекста на едно (и само едно) появяване на обект B. От своя страна, появяванията на B могат да съществуват както във връзка с появявания на A, така и без него.

III - използва се рядко. И А, и Б могат да съществуват без връзка помежду си.

Отношенията много към много са показани в ориз. 9.

Ориз. 9. Връзки много към много

I - такава конструкция често се провежда в началото на етапа на анализ и означава връзка - или неразбрана напълно и изискваща допълнително разрешение, или отразяваща проста колективна връзка - двойно свързан списък.

II - рядко се използва. Такива връзки винаги подлежат на допълнително уточняване.

Помислете сега за рекурсивните връзки ( ориз. 10).

Ориз. 10. Рекурсивни връзки

I - рядко, но се среща. Отразява връзки от алтернативен тип.

II - доста често се използва за описание на йерархии с произволен брой нива.

III - се провежда в ранните етапи. Често отразява структурата на "списъка с материали" (взаимно влагане на компоненти). Пример: всеки КОМПОНЕНТ може да се състои от един или повече (други) КОМПОНЕНТИ и всеки КОМПОНЕНТ може да се използва в един или повече (други) КОМПОНЕНТИ.

Невалидни типове връзки. Невалидните типове релации включват следното: Задължителна релация много към много ( ориз. единадесет) и редица рекурсивни връзки ( ориз. 12).

Ориз. 11. Невалидни релации много към много

Ориз. 12. Невалидни рекурсивни връзки

Задължителна връзка много към много е принципно невъзможна. Такава връзка би означавала, че нито едно от появяванията на A не може да съществува без B, и обратното. Всъщност всяка такава конструкция винаги се оказва погрешна.

Към началото

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

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

Ориз. 13. Пример за DFD

По-специално, DFD не показва процесите, които контролират действителния поток от данни и не прави разлика между валидни и невалидни пътища. DFD съдържат много полезна информация и в допълнение:

ви позволяват да представите системата по отношение на данни;

илюстрират външни механизми за подаване на данни, които биха изисквали специални интерфейси;

позволяват да се представят както автоматизирани, така и ръчни процеси на системата;

извършете ориентирано към данни разделяне на цялата система.

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

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

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

Външен обект (терминатор) представлява обект извън контекста на системата, който е източник или приемник на системни данни. Името му трябва да съдържа съществително име, като например „Клиент“. Предполага се, че обектите, представени от такива възли, не трябва да участват в никаква обработка.

Към началото

STD диаграми на прехода на състоянието

Жизненият цикъл на даден обект принадлежи към класа STD диаграми ( ориз. 14). Тази диаграма отразява промяната в състоянието на даден обект във времето. Например, помислете за състоянието на продукт в склад: продукт може да бъде поръчан от доставчик, доставен в склад, съхраняван в склад, подложен на контрол на качеството, продаден, отхвърлен, върнат на доставчик. Стрелките в диаграмата показват разрешените промени в състоянието.

Фиг.14. Пример за DFD

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

Към началото

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

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

Редовно представяйте своя информационен модел или негови отделни фрагменти, за които имате съмнения за одобрението на потребителите. Обърнете специално внимание на изключенията от правилата и ограниченията.

Към началото

Качество на субекта

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

Списък с въпроси за проверка за юридическото лице:

Името на обект отразява ли същността на този обект?

Има ли пресичане с други субекти?

Има ли поне два атрибута?

Има ли общо не повече от осем атрибута?

Има ли синоними/омоними за този обект?

Обектът напълно дефиниран ли е?

Има ли уникален идентификатор?

Има ли поне една връзка?

Има ли поне една функция за създаване, търсене, актуализиране, изтриване, архивиране и използване на стойност на обект?

Има ли история на промените?

Има ли съответствие с принципите за нормализиране на данните?

Съществува ли същият обект в друга приложна система, може би под различно име?

Твърде обща ли е същността?

Достатъчно ли е нивото на обобщение, въплътено в него?

Списък с скрининг въпроси за подтипа:

Има ли припокривания с други подтипове?

Подтипът има ли някакви атрибути и/или връзки?

Всички ли имат свои собствени уникални идентификатори или всички наследяват един от супертипа?

Има ли изчерпателен набор от подтипове?

Не е ли подтип пример за възникване на обект?

Знаете ли за някакви атрибути, връзки и условия, които отличават този подтип от другите?

Към началото

Качество на атрибута

Необходимо е да се установи дали това наистина са атрибути, тоест дали те описват тази същност по един или друг начин.

Списък със защитни въпроси за атрибут:

Името на атрибута съществително в единствено число ли е, което отразява същността на свойството, обозначено с атрибута?

Името на атрибута не включва ли името на обекта (не трябва)?

Атрибутът има ли само една стойност в даден момент?

Липсват ли дублирани стойности (или групи)?

Описани ли са форматът, дължината, валидните стойности, алгоритъмът за извличане и т.н.?

Възможно ли е този атрибут да е пропуснат обект, който би бил полезен за друга приложна система (съществуваща или предложена)?

Възможно ли е да е пропусната връзка?

Има ли нужда от история на промените?

Стойността му само от дадения обект ли зависи?

Ако стойността на даден атрибут е необходима, винаги ли е известна?

Има ли нужда от създаване на домейн за този и подобни атрибути?

Стойността му зависи ли само от част от уникалния идентификатор?

Стойността му зависи ли от стойностите на някои атрибути, които не са включени в уникалния идентификатор?