1

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

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

структура

методология

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

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

1. Брикин И.М., Беклемишев А.В. Оценка, избор и анализ на инвестиционни проекти. – М.: International Media Group LLC, 2011. – 47 с.

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

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

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

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

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

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

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

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

Сред съществуващите финансови аналитични системи могат да се подчертаят разработките на такива компании като Expert Systems, Galaktika, INEC, 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. – No 12-1. – С. 58-61;
URL: http://fundamental-research.ru/ru/article/view?id=41046 (дата на достъп: 26.04.2019 г.). Предлагаме на вашето внимание списания, издадени от издателство "Академия за естествени науки"

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

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

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

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

Основните понятия, използвани в теорията на информационните системи и автоматизираните информационни системи, са информация, система, система за търсене на информация, автоматизирана система за управление, автоматизирана работна станция. Информация - от лат. Informatio изясняване, представяне на първоначално информация, предавана от хора устно, писмено или по други начини от средата на 20-ти век, обща научна концепция, която включва обмен на информация между хора, човек и автомат, автомат и автомат. Системата е група от много специфично подредени и взаимосвързани елементи, които имат стабилно единство, вътрешна цялост и автономност на съществуване във външната среда. Системата за търсене на информация IPS е набор от инструменти за съхраняване, търсене и издаване при поискване на необходимата информация; търсенето за поставяне на информация в IPS се извършва ръчно или с помощта на компютър съгласно определени правила и в съответствие с приетия информационен език. Автоматизирана система за управление на автоматизирана система за управление е набор от математически методи, компютърен хардуер, комуникационни и организационни комплекси, които осигуряват рационално управление на сложен обект на процес в съответствие с дадена цел. Автоматизирано работно място работно място на оператор, диспечер, дизайнер, технолог, оборудвано с компютърна техника за автоматизиране на процеса на обработка и извеждане на информацията, необходима за изпълнение на производствена задача. Напоследък се увеличи ролята на информацията, използвана в предприятията и различни организации. Можем да кажем, че това е един от ресурсите, използвани в дейността на предприятието. Информационните ресурси обаче се различават по своите свойства от ресурсите в традиционната концепция за материални, енергийни и технологични.

Различни изследователи са предложили различни начини за класифициране на информационната поддръжка. Така че, от гледна точка на взаимодействието на предприятието на организацията с околната среда, цялата информация, главно документална, обикновено се разделя на входяща и изходяща. В зависимост от периода на съхранение се прави разлика между постоянни, полупостоянни, понякога актуализирани и променливи, редовно променящи се. Информацията също е разделена на нива на управление: фабрично, вътрешнозаводско, цехово и вътрешноцехово. Естеството на дейността е конструкторско-технологично. счетоводство, счетоводство и отчетност, планиране, маркетинг, персонал, производство. В автоматизираните системи информационната поддръжка се разделя на компютърно базирана в компютърната памет и немашинна. Тези класификации в различни комбинации се използват при индексиране на различни документи: писма, заповеди, инструкции и други документи, използвани от предприятията и организациите в тяхната практическа дейност. История на развитието. В историята на създаването на автоматизирани информационни системи две направления се развиха относително независимо: 1. развитие на автоматизирани информационни системи AIS като автоматизирани системи за управление на автоматизирани системи за управление 2. развитие на автоматизирани научно-технически информационни системи на ASNTI. Работата по тяхното създаване започва почти едновременно през 60-те години.

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

По същия начин и на ниво предприятия и особено тези, създадени през 70-те години. научни и производствени асоциации НПО, в структурата на автоматизирани системи за управление или интегрирани автоматизирани системи за управление на асоциации, се разграничават нива на ниво - автоматизирани системи за управление на асоциацията, автоматизирани системи за управление на предприятия и организации на научноизследователски институти, конструкторски бюра, включени в научни и производствени асоциации, автоматизирани системи за управление на производството, цехови комплекси, автоматизирани системи за управление на цехове и участъци. На ниво цехове и участъци автоматизираните системи за управление първоначално са разделени на автоматизирани системи за управление на технологичните процеси, автоматизирани системи за управление на техническата и технологична подготовка на производството и автоматизирани системи за управление на организацията на производството. Работата по създаването на централизирани национални автоматизирани системи за управление и ASTI беше спряна поради трансформациите от 19-91 г. Но при прехода към пазарна икономика, към правова държава, нараства ролята на друг важен вид информация - нормативно-правната и нормативно-методическата, регулираща дейността на предприятията, като същевременно им осигурява по-голяма самостоятелност и намалява организационната и административната документация на текущите заповеди и инструкции, които проверяват методите на командване и административно управление. Впоследствие, с развитието на предприятията и техните автоматизирани системи за управление, особено в условията на предоставяне на по-голяма независимост на производството и цеховете и преразпределението на управленските функции между администрацията на предприятието и ръководителите на производството и цеховете, също стана по-удобно да се представи структурата на автоматизираната система за управление като многостепенна, стратифицирана. Разделянето на автоматизираната система за управление на функционални и поддържащи части, а последните на информационна поддръжка, техническа, организационна, софтуерна и други видове поддръжка, направи възможно привличането на специалисти в тези области за изясняване на съответните видове поддръжка. Този подход към организирането на разработването на автоматизирани системи за управление помогна да се справи със сложността на системата и да ускори разработването на автоматизирани системи за управление чрез паралелна работа по анализ и избор на структурата на отделните видове поддръжка. Въпреки това, ако разработвате отделни проекти, тогава след разработването възниква доста сложна задача за тяхната координация, взаимовръзката на приетите структури на тези видове подкрепа, критериите, взети предвид по време на тяхното разработване, и т.н. Следователно, на определен етап от развитието на работата по създаването на автоматизирана система за управление, дори беше формулиран специален принцип на единство на информационната поддръжка, хардуера и софтуера като основни видове поддръжка. В момента има огромен брой готови софтуерни продукти. Следователно, когато създавате автоматизирана система в предприятие, няма нужда да се занимавате с независимо разработване на софтуер. Оценка на ефективността на информационните ресурси. Предвид разнообразието от видове и форми на информационните ресурси, проблемът за тяхната оценка изглежда почти неразрешим.

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

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

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

При тази постановка на проблема трябва да се решат два проблема: 1 да се формира структура от цели за основните насоки на развитие на системата, които определят нейната дейност през съответния период на съществуване; 2 да се избере подход за оценка на степента влияние на информацията върху постигането на целите. За да осигури пълен анализ на дейността на предприятието, организацията при формирането на структура от цели трябва да използва методи за структуриране на цели и функции, изборът на които се определя от предварително разработена концепция за нейното развитие. За да оцените степента на съответствие с целта, можете да използвате вероятностна мярка, т.е. да оцените вероятността даден информационен ресурс да бъде използван за постигане на подцел. Такива оценки могат да бъдат получени като оценки за относителната важност, относителния принос на даден информационен ресурс за изпълнението на съответната подцел, но това повдига проблема, че една и съща информация може да повлияе на повече от една подцел. Можете да използвате информационна мярка за степента на влияние на даден ресурс върху изпълнението на подцелите, което ви позволява да вземете предвид не само вероятността за постигане на подцел p, но и вероятността q тази информация да бъде използвана от вземащ решение при изпълнение на подцелта. Оценката на информационния потенциал H е по-удобна от оценките с относителна важност; те могат да бъдат обобщени; могат да се вземат предвид не само p, но и q; концепцията за информационен потенциал се възприема по-добре от управленските работници. В реални условия могат да се използват по-сложни методи.

Защо не? Това е добър пример. Един проект е проект навсякъде: плюс или минус едни и същи етапи, една и съща схема на управление, документооборот, управление на риска, контрол на качеството и т.н. Навсякъде има изисквания за оборудване, помещения и софтуер. Може да попитате какви могат да бъдат изискванията за помещения в Информационната система? Много е просто: местоположението на работните места на оператора и сървъра - и двете ще изискват климатизация. Ето какви са изискванията към помещенията. И едва ли някой днес се съмнява дали една болница има нужда от софтуер. Ако искате да сте в крак с времето, ще се изправите пред задачата да създадете автоматизирано медицинско заведение с електронни медицински досиета, където лекарите правят прегледи с таблети, а например медицинските сестри маркират почистена тоалетна не върху парче хартия, но на техния телефон. В този случай ще има много софтуерни изисквания. И веднага след като софтуерът е необходим, ще има нужда да инсталирате сървъри, да поставите някъде администратор и оператори. Всичко е взаимосвързано.

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

Програмен код вътре (но никой не го вижда)

Какво общо има болницата, ако ние разработваме софтуер?

Но не, скъпи разработчици, мениджъри, анализатори, тестери.

Вие не разработвате софтуер... Да вземем Android, това е софтуер. И ако например имате счетоводна система пред себе си, тогава вече имате работа не просто със софтуер, а с ИНФОРМАЦИОННА СИСТЕМА.

Разликата е очевидна. Ако сте купили телефон, всичко е просто: включете го, зеленото човече (Android) стартира и го използвайте. И ако сте закупили кутия със счетоводен софтуер, тогава е ясно, че сега имате нужда от сървъри, трябва да настроите мрежа, да конфигурирате работни станции, да обучите служители, да интегрирате системата с останалите информационни системи на предприятието и да стартирате системата в тестов режим. А счетоводителите все още трябва по някакъв начин да бъдат убедени да преминат към нов софтуер; не всички от тях са готови за иновации. Като цяло във всеки ИТ проект 10-20% са ИТ, а останалото са организационни и административни мерки и много интензивна, детайлна работа с персонала.

Информационна система (само софтуер ли е?)

И накрая, нека си спомним дефиницията на системата от далечните 90-те години, която никой не е отменил:

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

ГОСТ 34.003-90. Информационни технологии. Набор от стандарти за автоматизирани системи. Автоматизирани системи. Термини и дефиниции.

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

Как да проектираме болница

Да си представим, че сте строителна организация, клиент идва при вас и ви моли да построите болница на такова и такова място. Веднага ли ще хукнеш да слагаш тухли или...? Ако погледнете как често се създават информационни системи, тогава това е вярно: изпълнителите веднага започват да „смесват бетон и да купуват прозорци с двоен стъклопакет“. Например, ако не се окаже така, ще го възстановим! Ще възстановяваме, докато постигнем желания резултат.

Но ако сте сериозна организация, първо предложете на клиента строителен ПРОЕКТ. Съгласен ли си? Защо не е наред с Информационната система? Може би въпросът не е в разликите между изграждането и разработката на софтуер, а в това, че в случая на една и съща болница първо се мисли много, планира се и след това се строи, но софтуерът първо се разработва и след това се мисли? Затова ли чуваме много за измамни програмисти, но нищо за същите работници мигранти на строителна площадка? Строителите работят по проект, за разлика от предприемачите.

Без проект винаги е така, дори и да не се вижда

Нека сега разгледаме по-подробно процеса на проектиране. Има няколко етапа. Защо трябва да преминете през няколко етапа, защо не го направите наведнъж? За по-голяма яснота ще дам училищен пример... Колко години изучаваме действието умножение в училище? Ще кажете един-два месеца и ще сгрешите тотално. Да, как се умножава 5 по 6, минава за една седмица. Таблиците за умножение се учат за определено време. Колко учат умножение на дроби, числа със степени, логаритми, изрази в скоби, комплексни числа и степенуване? Почти всички учебни години! Оказва се, че изучаваме едно и също умножение всяка година от различни ъгли.
ami.

И защо това не се учи в първи клас?

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

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

Нека дадем друг пример. Вие сте на върха на планина, гледате надолу през мощен бинокъл и се опитвате да начертаете подробен маршрут надолу. През окулярите се вижда всяко камъче по пътеката, всяка локва. Но дали това е правилният път и дали води до върха, не се вижда с бинокъл: няма общ план. Интелигентният катерач първо ще очертае маршрутите на спускане с невъоръжено око и след това ще ги разгледа при голямо увеличение. Веднага щом се потопите в детайлите, губите цялостната представа за проекта. Ако веднага вземете телескоп, ще опишете перфектно 10 функции, като забравите за останалите 40 и изобщо не ги споменавате.

Вижда се добре, но само малка част

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

Сега нека най-накрая да преминем към разглеждане на етапите на проектиране.

1. Изготвяне на общи изисквания

И така, да кажем, че сте дизайнер. При вас идва клиент, „изпратен“ от отговорни строители. Клиентът, естествено, ви моли да разработите проект за болница. Тичаш до чертожната дъска и... Е, добре, това вече е древно - стартирай ArchiCAD и чертай.

Но, разбира се, не става въпрос за вас. Вие сте професионалист и започвате да задавате куп „глупави“ въпроси. И най-важното от тях е защо трябва да построим болница. Каква е целта на строежа? Ако целта не е ясна, тогава няма да можете да отговорите на въпроса дали трябва да бъде голяма болница или малка, какъв тип болница е, с какъв тип болница е оборудвана. За съжаление клиентите често казват много интересни неща, с изключение на основното - каква е тяхната цел. Това е, което първо трябва да се „извади“ от него. И трябва да зададете въпроса. Самият клиент не е специалист, той има идея и с това вижда ролята си завършена. Той не разбира какъв път трябва да измине, за да реализира идеята си. По правило клиентът чака доброто старо чудо - да дойде на морския бряг, да хвърли мрежа (да плати пари), да хване риба и тя ще изпълни желанието му... И става като във вица за богат човек, който, след като хванал златна рибка, поискал да му бъде изпълнено едно желание: „Искам да имам всичко!“ „Няма проблем – отговорила рибата, – имахте всичко...“

За да разберете целта на проекта, не е достатъчно да съставите няколко изречения със стандартен набор от фрази. Целта на проекта обикновено се определя въз основа на противопоставяне: те описват съществуващия информационен модел (например, хората седят в архива и сортират парчета хартия), след това - неговите недостатъци (поради липсата на автоматизация, 10 души участват в архива, което е очевидно излишно; други отдели не могат да получават информация със седмици от архива необходимата информация и т.н.) и предлагат решение (внедряване на софтуер, който ще позволи извършването на редица операции в автоматизиран режим; операциите трябва да бъдат изброени). Ако на пазара се въведе напълно нов тип услуга, тогава е необходимо да се проучи съществуващият пазар и да се „критикуват“ наличните там инструменти, след което да се предложи решение.

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

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

2. Избор на системна концепция

На този етап е необходимо да се изберат общи технически решения, с помощта на които да бъдат изпълнени изискванията, съставени на предишния етап. Ще бъде ли уеб приложение или естествено, дебел клиент или тънък, централизиран или разпределен, релационна СУБД или noSQL, монолит или микроуслуги, Java или Python. Често тези въпроси се забравят да бъдат обсъдени навреме и тогава се оказва, че един от програмистите самостоятелно е избрал определен инструмент и в крайна сметка това решение не позволява постигане на целта.

3. Разработване на технически спецификации

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

За информационната система разработването на технически спецификации () е централната част на проекта. описва:

1. КАКВО трябва да прави системата.
2. Каква трябва да бъде цялостната структура на системата.
3. Как да създадете система.

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

Когато описваме функциите на системата (а това е централната част на техническата спецификация), трябва да се разбира, че даваме изисквания за това КАКВО трябва да прави системата, а не КАК. Ширината на покритие трябва да е по-важна за вас от дълбочината. Например, на първия етап (съставяне на общи изисквания) ние идентифицирахме необходимостта от функция за блокиране на потребителско влизане. Условията за работа показват, че акаунтът се блокира, ако не се използва в продължение на 90 дни или след 6 неуспешни опита за влизане, достъпът може да бъде ограничен от администратора за определен период, трябва да се показва съобщение, когато блокиран потребител се опита да влезе и т.н. . И в техническия проект (нека да преминем напред) ще начертаем оформление на потребителска карта с блокиращ флаг и дата на отключване, ще създадем скрипт за влизане, в който се извършва проверка за блокиране, автоматично отключване след зададен период, блокиране при неуспешни опити за влизане; Нека да определим какво се изпълнява от страна на клиента и какво се изпълнява от страна на сървъра.

Бих искал да развенча няколко мита, свързани с развитието на .

Мит първи: Техническото задание съдържа изисквания само към изпълнителя.

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

4. Разработване на технически проект

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

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

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

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

5. Разработване на работна документация

Логичен е въпросът каква е тази работна документация за болница? Наистина ли има инструкции за почистване на коридора?! Шегата настрана, трябва ли да се поддържа противопожарната система? Необходимо. Ами асансьорите? Ами компютърните мрежи? Какво ще кажете за водопровода? „Е, това няма нищо общо с проекта за болницата!“ - ти каза. Да, това е отчасти вярно. Болницата обаче се предава на клиента като едно цяло и всички системи трябва да имат подходяща експлоатационна документация. А за да бъде доставката бърза и успешна, ще направите списък с изисквания, които можете да отметнете дали всичко е наред.

Наличието на потребителски и администраторски ръководства за IS е стандарт, всичко е ясно с това. Но за процеса на предаване и приемане на системата на клиента често се мисли в последния момент. И напразно. За това има отличен документ „Програма и тестова методология“, който също обикновено се класифицира като работни документи. Това е един вид контролен списък, съдържащ описание на процедурите за проверка. Ако този документ е изготвен предварително (и скриптът като основа може да бъде заимстван от техническия проект), тогава разработчиците ще имат ясен критерий за приемане на тяхната работа. Не е нужно да доказвате на вашите или външни програмисти, че сте прави - има сценарий, той трябва да се разработи. И няма да има проблеми с клиента - въображението вече е ограничено от документа.

Къде е мястото на Agile?

Някои хора силно подкрепят Agile (или други „гъвкави“ методи за разработка), докато други са категорично против него. Авторът на статията има собствено мнение: Agile е много добър, но не на място. И обикновено се използва за други цели.

Кажете ми, любители на Agile, възможно ли е, използвайки тази технология, да определите резултата, който ще получите в края на разработката, цената и времето? Не? Е, колко малоумни клиенти ще намерите, които ще се включат в работа с неясен резултат, бюджет и времетраене? Бихте ли поръчали ремонт на апартамент от екип, използващ Agile? Така Agile има своето място, но за вътрешни проекти. Можете да правите колкото искате ремонти и да преглеждате всичко по няколко пъти. За външни клиенти това е умело наречена измама (вие, разбира се, няма да се съгласите с тази формулировка, но се опитайте да убедите клиента в същото).

Клиентът си мисли: докога ще продължават да ме водят за носа?

Второ, Agile е добър в иновациите, където не е ясно какъв резултат се изисква или пътят за постигането му не е ясен. Това се нарича R&D, експериментална разработка на дизайн. Или дори научноизследователска и развойна дейност. Във всеки завод има експериментална работилница, където прототипите се произвеждат с файл и се преработват няколко пъти. Нека си представим, че трябва да преработим сензорния екран, всички жестове и поведение. Тук наистина трябва да опитате и опитате, не можете да опишете поведението предварително. Но колко често се сблъсквате с подобни задачи? Необходимо е да се прави разлика между инженерно развитие и научно изследване. Ние сме предимно инженери по информационни системи.

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

За съжаление, много често, докато „проповядват“ Agile, разработчиците се опитват да прикрият неспособността си да разработят системен дизайн (или дори не знаят, че това е възможно). Те действат по най-удобния за тях начин: ние ще го завършим и ще го завършим за парите на клиента. Докато никой не контролира разходите, те могат да се разминат. Но тогава външен наблюдател (властите) може да има усещането, че има процес, но не се вижда край и не се вижда резултат. Опитайте се да гледате не само от вашата камбанария.

Къде мога да науча повече за проектирането на информационни системи?

Има много книги на тази тема. Не е много дебел. Но книгата винаги е опит на някой друг. Но вие имате различен характер, отлична ситуация и проект. Има такава система TRIZ - теорията за решаване на изобретателски проблеми. Неговият автор Алтшулер се опитва да обясни стъпките, които трябва да се предприемат, за да се изобрети нещо. Оказва се? По правило не. Принципите са представени като интересни и полезни, но няма единен шаблон за изобретението. Всеки човек мисли и създава по свой собствен начин и е невъзможно да се научи това, можете само да научите. Трябва да използвате опита на някой друг, би било глупаво да не го използвате, но той трябва да бъде преживян (обработен) от вас, пренесен във ВАШЕТО мислене. Невъзможно е да копирате чудо.

Тагове: Добавете тагове

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

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

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

Въведение

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

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

необходим капацитет на системата;

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

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

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

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

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

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

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

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

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

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

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

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

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

Ориз. 1. Диаграма на водопада

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

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

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

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

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

Към началото

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

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

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

Към началото

Стратегия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Към началото

Анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

Към началото

ER диаграми

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

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

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

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

Един ред вдясно ( ориз. 3) означава "един", "птичи крак", вляво - "много", а връзката се чете по реда, като "един към много". Вертикална лента означава „задължително“, кръг означава „незадължително“, например за всяка публикация в TITLE трябва да бъде посочен издателят в PUBLISHERS и един издател в PUBLISHERS може да публикува няколко заглавия на публикации в TITLES. Трябва да се отбележи, че връзките винаги се коментират (надписът на линията, изобразяващ връзката).

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

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

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

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

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

Към началото

дъги

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

Ориз. 5. Арк

В този случай атрибутът OWNER на обекта ACCOUNT има специално значение за този обект - обектът е разделен на типове по категории: „за физическо лице“ и „за юридическо лице“. Получените обекти се наричат ​​подтипове, а оригиналният обект става супертип. За да разберете дали е необходим супертип или не, трябва да установите колко идентични свойства имат различните подтипове. Трябва да се отбележи, че злоупотребата с подтипове и супертипове е доста често срещана грешка. Те са изобразени, както е показано на ориз. 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 технологията. Това обаче не означава, че в изграждането и наблюдението на информационния модел трябва да участват само анализатори. Помощта от колеги също може да бъде много полезна. Включете ги в проверката на заявената цел и в подробното проучване на изградения модел, както от гледна точка на логиката, така и от гледна точка на отчитане на аспекти от предметната област. Повечето хора намират по-лесно да намерят недостатъци в работата на някой друг.

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

Към началото

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Към началото

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

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

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

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

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

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

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

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

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

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

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

Значението му само от тази същност ли зависи?

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

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

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

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

Въведение

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

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

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

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

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

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

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

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

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

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

• Каскаден модел. Преходът към следващия етап означава пълно завършване на работата на предишния етап.
• Стъпков модел с междинно управление. Разработката на софтуер се извършва на итерации с обратна връзка между етапите. Междуетапните корекции позволяват да се намали сложността на процеса на разработка в сравнение с водопадния модел; Животът на всеки етап се простира през целия период на развитие.
• Спирален модел. Особено внимание се отделя на началните етапи на разработка – разработване на стратегия, анализ и проектиране, където се тества и обосновава осъществимостта на определени технически решения чрез създаване на прототипи (макет). Всяко завъртане на спиралата включва създаването на определена версия на продукта или някой от неговите компоненти, като същевременно се изясняват характеристиките и целите на проекта, определя се неговото качество и се планира работата на следващото завъртане на спиралата.

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

„Водопад“ - диаграма за развитие на проекта

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

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

Стратегия

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

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

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

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

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

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

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

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

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

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

Анализ

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

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

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

• функции - информация за събития и процеси, които се случват в бизнеса;
• entities – информация за неща, които са важни за организацията и за които нещо се знае.

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

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

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

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

• Entity-Relationship Diagrams (ERD), които служат за формализиране на информация за обекти и техните взаимоотношения;
• Диаграми на потока от данни (DFD), които служат за формализиране на представянето на системните функции;
• Диаграми на прехода на състоянието (STD), които отразяват зависимото от времето поведение на системата; Диаграмите на жизнения цикъл на обекта принадлежат към този клас диаграми.

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

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

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

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

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

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

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

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

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

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

Нека сега разгледаме рекурсивните връзки (фиг. 10).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Името на обекта отразява ли същността на този обект?
• Има ли припокриване с други субекти?
• Има ли поне два атрибута?
• Общо няма повече от осем атрибута?
• Има ли синоними/омоними за този обект?
• Обектът напълно дефиниран ли е?
• Има ли уникален идентификатор?
• Има ли поне една връзка?
• Има ли поне една функция за създаване, търсене, редактиране, изтриване, архивиране и използване на стойност на обект?
• Има ли история на промените?
• Има ли съответствие с принципите за нормализиране на данните?
• Има ли същия обект в друга приложна система, може би под различно име?
• Твърде обща ли е същността?
• Достатъчно ли е нивото на обобщение, въплътено в него?

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

• Има ли припокриване с други подтипове?
• Подтипът има ли някакви атрибути и/или връзки?
• Всички ли имат свои собствени уникални идентификатори или наследяват един за всички от супертипа?
• Има ли изчерпателен набор от подтипове?
• Подтипът не е ли пример за възникване на обект?
• Знаете ли някакви атрибути, връзки или условия, които отличават този подтип от другите?

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

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

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

• Дали името на атрибута е съществително в единствено число, което отразява същността на свойството, обозначено с атрибута?
• Името на атрибута не включва ли името на обекта (не трябва)?
• Един атрибут има ли само една стойност в даден момент?
• Има ли дублирани стойности (или групи)?
• Описани ли са форматът, дължината, приемливите стойности, алгоритъмът за придобиване и т.н.?
• Може ли този атрибут да е липсващ обект, който би бил полезен за друга приложна система (съществуваща или предложена)?

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

Списък с контролни въпроси за комуникация:

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

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

• Посочена ли е степента на връзка и ангажираност за всяка страна?
• Приемлив ли е дизайнът на връзката?

Дизайнът на връзката един от рядко използваните ли е?

• Не е ли излишно?
• Не се ли променя с времето?
• Ако връзката е задължителна, тя винаги ли отразява връзката с обекта, представляващ противоположната страна?

За изключителна връзка:

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

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

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

Изясняване на стратегията

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

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

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

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

КомпютърПрес 9"2001