AIS управление на проекти. AIS „Управление на проекти. Основни концепции за проектиране на AIS

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

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

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

При разработването на IS в повечето случаи се дава предимство на стандартни дизайнерски решения, адаптирани към специфичните условия и възможности на Клиента. Индивидуални проекти се разработват при липса на стандартни решения или когато основните параметри на организацията се различават значително (с повече от 10-15%) от стандартните решения. Това обикновено се отнася за големи и големи организации.

Нито една схема за развитие на ИС не е абсолютна. Възможни са различни варианти, в зависимост например от първоначалните условия, при които се извършва разработката: разработва се изцяло нова система; вече е извършено проучване на предприятието и има модел на неговата дейност; предприятието вече има IS, която може да се използва като първоначален прототип или трябва да бъде интегрирана с разработения.

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

Проектирането на всеки обект се извършва с:

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

След избора на метод за проектиране на AIS е необходимо да се планира набор от работи за създаване на система в съответствие с типичните етапи от нейното развитие. Проектът се преглежда и одобрява от клиента. Проектирането на AIS включва изпълнението на определени етапи и етапи.

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

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

За автоматизация различни видоведейности (управление, проектиране, изследвания и др.), включително техните комбинации, използват разпоредбите на ГОСТ 34.601-90. Той предвижда следните етапи и етапи на проектиране (таблица 1).

таблица 2

Стандартът също така посочва, че:

• · Етапи и етапи, извършвани от организации, участници в създаването на АС, са определени в договори и техническо задание въз основа на този стандарт.
• · Позволено е да се изключат етап „Проект на проект“ и отделни етапи на работа на всички етапи, да се комбинират „Технически проект“ и „Работна документация“ в един етап „Техно-работен дизайн“. В зависимост от спецификата на създаваните АЕЦ и условията за тяхното създаване се допуска извършването на отделни етапи от работата преди завършване на предишните етапи, паралелно във времето изпълнение на етапите на работа, включването на нови етапи на работа.

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

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

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

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

Държавният стандарт GOST 19.102-77 установява следните етапи на разработване на софтуерна документация:

• 1. Техническо задание;
• 2. Проект на проект;
• 3. Технически проект;
• 4. Работен проект;
• 5. Изпълнение.

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

Като част от изпълнението на първия етап „Формиране на изисквания за AU“, обектът се изследва и необходимостта от създаване на AIS се обосновава, като се вземат предвид изискванията на потребителя за проектираната AIS. Тези процедури на първата фаза на проектиране са част от предварителното проучване. Това може да включва и процедурите от втория етап на проектиране - „Разработване на концепцията за АЕЦ”.

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

В процеса на предварително проектиране за извършване на необходимите проектни работи се идентифицират следните:

• · материални ресурси,
• · финансови ресурси,
• · човешки ресурси,
• · Временни ресурси.

Понастоящем всяка организация има на разположение някои материални ресурси, като правило, с разнороден произход. За да се гарантира безопасността на тези ресурси, е необходимо да се водят записи и да се определят отговорни лица. Решението на този проблем може да се осъществи с помощта на различни приложения като 1С: Предприятие, AVARD и много други. Но тези програми са много скъпи, както при покупка, така и при поддръжка. Изискват специално образование и обучение на персонал.

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

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

Към основната инструменти за проектиранеможе да се припише:

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

Системи за автоматизирано проектиране (CAD), включващи използването на компютри на всички етапи от създаването на AIS.

Общи изисквания към инструментите за проектиране:

Пълно покритие на целия процес на създаване на AIS;

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

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

Достъпност в разработката и простота (простота) в изпълнение;

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

Адаптивност и рентабилност.

Между методи за проектиранеразпределят:

Оригинален дизайн;

Типичен дизайн и неговите видове: елементарен, подсистемен, модулен, групов;

Компютърно проектиран дизайн.

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

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

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

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

2. разработване на автоматизирани системи за проектиране.

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

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

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

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

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

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

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

Следните дейности се поддават най -ефективно на автоматизацията:

1. счетоводство, включително управленско и финансово. Най -голям брой RFPs са създадени за счетоводни цели. Сред тях са „1С: Счетоводство“, „Турбо-счетоводител“, „Инфо-счетоводител“, „Парус“, „АБАКУС“, „Бамби +“ и др.;

2. Помощно и информационно обслужване икономическа дейност... Представен от следното ПЧП: „ГАРАНТ“ (данъци, счетоводство, одит, предприемачество, банкиране, валутно регулиране, митнически контрол); „КОНСУЛТАНТ +“ (данъци, счетоводство, одит, предприемачество, банкиране, валутно регулиране, митнически контрол).

3. икономически и финансови дейности... Представен от следната RFP:

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

б) Многопотребителски мрежов комплекс за пълна автоматизация на корпорация "Галактика" (АД "Нови Атлант"), който включва планиране, оперативно управление, счетоводство и контрол, анализ, освен това позволява в рамките на DSS да се гарантира решението на бизнес планирането проблеми при използване на проекта за ПЧП- експерт.

4. организация на работата на ръководителя;

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

6. обучение.

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

Компютърно проектирани системи за проектиране -вторият, бързо развиващ се начин за провеждане на проектни работи.

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

През последното десетилетие се появи нова посока в областта на автоматизацията на ИС и ИТ проектирането - CASE технология за автоматизирано разработване на софтуер(CASE - Компютърно подпомаган софтуер / системно инженерство). Нарастващата сложност на информационните системи, нарастващите изисквания към тях доведоха до необходимостта от индустриализация на технологиите за тяхното създаване.

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

Основната цел на CASE е да автоматизира максимално развитието и работата на системите.

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

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

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

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

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

CASE имат следните основни предимства:

Подобрете качеството на създадената IS (IT) чрез автоматичен контрол (на първо място, контрол на проекта);

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

Ускоряване на процеса на проектиране и разработване на системата;

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

Те подпомагат разработването и поддържането на вече функционираща ИС.

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

Фирми-разработчици на инструменти за анализ и проектиране на IP и IT

Фирми-разработчици на специални инструменти с акцент върху тесни предметни области или на отделни етапи от жизнения цикъл на ИС;

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

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

Фирми, специализирани в издаването на периодични издания и бюлетини за CASE технологиите.

Nbsp; Модели на жизнения цикъл на AIS

Модел на жизнения цикъл на AISе структура, която описва процесите, действията и задачите, които се извършват, както и хода на развитие, експлоатация и поддръжка през целия жизнен цикъл на системата.

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

Моделът на жизнения цикъл на AIS включва:

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

Ключови събития или точки на завършване и вземане на решения.

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

I. Модел на водопадаописва класическия подход към развитието на системите във всяка предметна област; е широко използван през 70 -те и 80 -те години на миналия век.

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

Разпределете петстабилни етапи на развитие, практически независими от предметната област (фиг. 1.1).

На първоНа този етап се извършва проучване на проблемната зона, формулират се изискванията на клиента. Резултатът от този етап е заданието (задание за разработка), съгласувано с всички заинтересовани страни.

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

Третоетап - изпълнение на проекта; по същество разработка на софтуер (кодиране) в съответствие с дизайнерските решения на предишния етап. В този случай методите за внедряване не са от основно значение. Резултатът от този етап е готовият софтуерен продукт.

На четвъртиНа този етап получения софтуер се проверява за съответствие с изискванията, посочени в техническото задание. Пробната операция ви позволява да идентифицирате различни видове скрити недостатъци, които се появяват в реалните условия на AIS.

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

Фигура 1.1 Модел на жизнения цикъл на AIS на водопада

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

Предимствата на каскадния модел:

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

2) последователното изпълнение на етапите на работа ви позволява да планирате времето за завършване и съответните разходи.

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

Недостатъци на модела на водопада:

Значително забавяне при получаване на резултати;

Грешки и недостатъци на всеки етап се появяват, като правило, на следващите етапи на работа, което води до необходимостта от връщане;

Сложността на паралелната работа по проекта;

Прекомерно пренасищане с информация на всеки от етапите;

Сложност на управлението на проекти;

Високо ниво на риск и ненадеждни инвестиции.

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

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

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

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

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

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

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

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

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

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

II. Итеративен моделсе състои в поредица от кратки цикли (стъпки) на планиране, изпълнение, проучване, действие.

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

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

недостатъциитеративен модел:

· Животът на всеки етап се удължава за целия период на работа;

· Поради големия брой повторения, има несъответствия при внедряването на проектни решения и документация;

· Сложност на архитектурата;

· Трудностите при използването на проектна документация на етапите на внедряване и експлоатация налагат препроектиране на цялата система.

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

Всяка итерация представлява завършен цикъл на разработка, водещ до пускането на вътрешна или външна версия на продукт (или подмножество на крайния продукт), която се подобрява от итерация към итерация, за да се превърне в завършена система (Фигура 1.2).

Ориз. 1.2. Спирален модел на AIS на жизнения цикъл

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

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

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

Предимстваитеративен подход:

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

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

Намаляване на нивото на рискове (следствие от предишното предимство, тъй като рисковете се откриват точно по време на интеграцията). Нивото на рисковете е максимално в началото на развитието на проекта; с напредването на развитието той намалява;

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

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

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

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

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

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

Доставени са съвременни методологии и технологии за проектиране на AIS, които ги прилагат в електронен форматзаедно с CASE-инструменти и включват библиотеки от процеси, шаблони, методи, модели и други компоненти, предназначени за изграждане на софтуер от класа системи, към които е насочена методологията. Електронните методологии и технологии са в основата на набор от договорени инструментиразвитие на AIS. Характеристиките на съвременните методически решения за проектиране на AIS не могат да бъдат приложени без определени проектни технологии, които съответстват на мащаба и спецификата на проекта.

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

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

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

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

Основните изисквания за избраната технология за проектиране са, както следва:

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

· Технологията трябва да отразява максимално всички етапи от жизнения цикъл на проекта;

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

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

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

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

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

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

Според степента на автоматизация те се разграничават:

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

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

Според степента на използване на типичните дизайнерски решения те се разграничават:

оригинал (индивидуален)дизайн, когато проектните решения се разработват „от нулата“ в съответствие с изискванията за AIS;

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

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

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

По степента на адаптивност на дизайнерските решения следните методи се различават:

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

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

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

Комбинацията от различни характеристики на класификацията на методите за проектиране определя естеството на използваната технология за проектиране AIS. Има два основни класа технология за проектиране: каноничени индустриални... Технологията за промишлен дизайн е разделена на два подкласа: автоматизиран(използване на CASE технологии) и типичен(параметрично ориентиран или ориентиран към модел) дизайн.

Таблица 1.1.Характеристики на класовете по технология на проектиране

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

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

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

Етап 1.Формиране на изисквания за AIS:

· Проучване на съоръжението и обосновка на необходимостта от създаване на AIS;

· Формиране на потребителски изисквания за AIS;

· Изготвяне на доклад за извършената работа и тактико -техническо задание за развитие.

Етап 2.Развитие на концепцията AIS:

· Проучване на обекта за автоматизация;

· Извършване на необходимата изследователска работа;

· Разработване на възможности за концепцията на AIS, отговаряща на изискванията на потребителите;

· Изготвяне на доклада и одобряване на концепцията.

Етап 3.Техническа задача:

Разработване и одобряване на технически спецификации за създаване на AIS.

Етап 4.Предварително проектиране:

· Разработване на предварителни проектни решения за системата и нейните части;

· Разработване на обща документация за AIS и нейните части.

Етап 5.Технически проект:

· Разработване на дизайнерски решения за системата и нейните части;

· Разработване на документация за AIS и нейните части;

· Разработване и изпълнение на документация за доставка на компоненти;

· Разработване на проектни задачи в свързани части на проекта.

Етап 6.Работна документация:

· Разработване на работна документация за AIS и нейните части;

· Разработване и адаптиране на програми.

Етап 7.Пускане в експлоатация:

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

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

· Строително -монтажни работи; въвеждане в експлоатация;

· Провеждане на предварителни тестове;

· Провеждане на пробна експлоатация;

· Провеждане на приемни тестове.

Етап 8.Ескорт на AIS:

· Изпълнение на работа в съответствие с гаранционните задължения;

· Следгаранционно обслужване.

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

Материалите, получени в резултат на проучването, се използват за:

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

Изготвяне на технически спецификации за разработване на системи;

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

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

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

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

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

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

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

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

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

Възможности за развитие и модернизиране на системата;

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

изисквания за софтуер и системи за управление на бази данни (СУБД).

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

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

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

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

При изучаване на всяка задача за функционален контрол се определя следното:

Име на задача; условия и честота на неговото решение;

Степента на формализация на проблема;

Източници на информация, необходими за решаване на проблема;

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

Процедурата за коригиране на информация;

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

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

Съществуващи средства за комуникация;

Приета точност на решението на проблема;

Сложността на решаването на проблема;

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

Потребители на получената информация за задачата.

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

Брой документи;

Място на формиране на индикатори за документи;

Връзката на документите по време на тяхното формиране;

Маршрутът и продължителността на движението на документа;

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

Вътрешни и външни информационни комуникации;

Обемът на документа в знаци.

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

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

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

Моделите на организационната дейност се създават в два типа 1:

Моделът „както е“ - отразява съществуващите бизнес процеси в организацията;

Моделът „да бъдеш” отразява необходимите промени в бизнес процесите, като се има предвид въвеждането на AIS. й

Още на етапа на анализ е необходимо да се включи тестовата група в работата за решаване на следните задачи:

Получаване на сравнителни характеристики на хардуерни платформи, операционни системи, СУБД и др.;

Разработване на работен план за гарантиране на надеждността на AIS и неговото тестване.

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

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

Резултатите от проучването представляват обективна основа за формиране на технически спецификации за AIS.

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

При разработването на техническо задание (ТЗ) е необходимо да се решат следните задачи:

· Да се ​​установи общата цел на създаване на AIS;

· Установяване на общи изисквания за проектираната система;

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

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

· Разработване и обосноваване на изискванията за подсистеми;

· Да се ​​определят етапите на създаване на системата и сроковете за тяхното внедряване;

Направете предварително изчисление на разходите за създаване на система и определете нивото икономическа ефективностизпълнение;

· Да се ​​определи съставът на изпълнителите.

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

Таблица 1.6. Съставът и съдържанието на техническата задача (ГОСТ 34.602-89)

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

AIS функции;

Функции на подсистемите, техните цели и очаквания ефект от внедряването;

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

Концепция на информационната база и нейната разширена структура;

Функции на системата за управление на бази данни;

Състав на изчислителна система и други технически средства;

Функции и параметри на основния софтуер.

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

В съответствие с ГОСТ 19.102-77, предварителният етап на проектиране съдържа два етапа: разработване на предварителен проект; одобрение на проекта на проекта.

Първият етап от развитието се състои от:

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

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

Разработване на общо описание на алгоритъма за решаване на проблема;

Разработване на предпроектно проучване;

Разработване на обяснителна бележка.

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

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

Задължителни документи:

1) актуализиран мандат за проектиране и разработване
работа на AIS;

2) спецификация на квалификационните изисквания за AIS;

3) набор от изисквания за функционални софтуерни компоненти и описания на данни;

4) спецификация на изискванията за вътрешни интерфейси на компонента и интерфейси с външната среда;

5) описание на системата за управление на базата данни, структура и разпространение на софтуер и информационни обекти в базата данни;

6) проекти на насоки за защита на информацията и осигуряване на надеждността на функционирането на AIS;

7) предварителна версия на ръководството за администратор на AIS;

8) предварителна версия на ръководството за потребителя на AIS;

9) преработен план за изпълнение на проекта;

10) усъвършенстван план за управление на осигуряването на качеството на AIS;

11) обяснителна бележка на предварителния проект на AIS;

12) ревизиран договор (споразумение) с клиента за подробности-
нов дизайн на AIS.

Документи, изготвени по споразумение с клиента:

1) предварително описание на функционирането на AIS;

2) диаграма на потоците от данни между функционалните компоненти на AIS;

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

4) описание на показателите за качество на компонентите и изискванията към тях по етапите на разработване на AIS;

5) доклад за технически и икономически показатели, график за изпълнение на проекта, разпределение на ресурси и бюджет;

6) таблица за разпределение на специалисти по компоненти и етапи на работа;

7) сертификати на разработчици за право на използване на технологии и инструменти за автоматизация за разработване на AIS;

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

9) план за отстраняване на грешки на софтуерни компоненти, осигуряващ му методи и инструменти за автоматизация на тестове;

10) предварително ръководство за подробен проект
vaniya, програмиране и отстраняване на грешки на компонентите на AIS;

11) предварителен план за продажба и изпълнение;

12) описание на предварителната структура на базата данни.

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

Таблица 1.7. Съдържание на техническия проект

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

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

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

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

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

Разходите за идентифициране и отстраняване на грешки в по -късните етапи на проектиране се увеличават приблизително експоненциално (Фигура 1.10).

Изследователите преброяват 169 вида грешки, обобщени в 19 големи класа:

1) логически;

2) грешки при манипулиране на данни;

3) I / O грешки;

4) грешки в изчисленията;

Ориз. 1.10.Относителните разходи за откриване и отстраняване на единична грешка

5) грешки в потребителските интерфейси;

6) грешки в операционната система и помощните програми;

7) грешки в оформлението;

8) грешки в интерфейсите за програмиране;

9) грешки в интерфейсите "Програма - системен софтуер";

10) грешки при работа с външни устройства;

11) грешки при взаимодействие с базата данни (DB);

12) грешки при инициализация на база данни;

13) грешки при промени при поискване отвън;

14) грешки, свързани с глобални променливи;

15) повтарящи се грешки;

16) грешки в документацията;

17) нарушение на техническите изисквания;

18) неразпознати грешки;

19) грешки на оператора.

Не всички грешки идват от разработчика. Според различни изследователи от 6 до 19% от грешките са причинени от грешки в документацията.

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

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

Ориз. 1.11.Връзка между разработването и тестването по етапи на проектиране на AIS

Техниката за отстраняване на грешки взема предвид симптомите на възможни грешки:

Неправилна обработка (грешен отговор, резултат) - до 30%;

Неправилно прехвърляне на контрол - 16%;

Несъвместимост на програмите с използваните данни - 15%;

Несъвместимост на програми за предавани данни - до 9%.

При разработването на задачи за отстраняване на грешки се решават следните задачи:

Писане на тестове;

Избор на точки, зони и маршрути за управление;

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

Определяне на реда на тестване;

Оценка на надеждността и сложността на отстраняване на грешки.

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

Контрол при теглене;

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

Издаване на състоянието на компонентите на паметта по време на изпълнение на програмата;

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

Установяване на тестови стойности на изходните данни;

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

Извършване на сервизни операции за подготовка на програмата за тестване.

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

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

2. Съберете и анализирайте информация, за да опростите процеса на тестване:

Характеристики и статистика за грешки;

За спецификата на изходните данни и последователността на променящите се променливи в програмата и тяхното взаимно влияние;

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

3. Намерете само една грешка наведнъж.

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

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

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

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

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

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

10. Измерете сложността на програмите. В програми с висока сложност има голяма вероятност от спецификации и грешки при проектирането, а с ниска сложност - грешки в кодирането и писането.

11. За увеличаване на опита и практиката при отстраняване на грешки изкуствено поставяйте грешки в програмите. След определен период на отстраняване на грешки, програмистът трябва да посочи всички останали грешки, които не е открил. Подобно „засяване“ се използва широко за оценка на броя на неоткритите грешки (ако както изкуствените, така и реалните грешки са еднакво открити и коригирани, тогава процентът на въведените въведени грешки и реалните грешки може да се използва за предвиждане колко от тях остават).

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

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

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

Изпратете вашата добра работа в базата знания е проста. Използвайте формата по -долу

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

публикувано на http://www.allbest.ru/

Министерство на образованието и науката Руска федерация

Федерален държавен бюджет образователна институциявисше професионално образование

Санкт Петербургски държавен университет за технологии и дизайн

Курсова работа

По дисциплина: "Архитектура на информационните системи"

По темата: „Проектиране на автоматизирани информационни системи“

ВЪВЕДЕНИЕ

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

Ето само някои от предимствата на използването на изчисления за организация:

* Възможност за оперативен контрол върху точността на информацията;

* Намаляване на броя на възможните грешки при генериране на получени данни;

* Възможност за бърз достъп до всякакви данни;

* Възможност за бързо генериране на отчети;

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

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

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

* Единна информационна среда на предприятието;

* Режим в реално време;

* Независимост от законодателството;

* Интеграция с други приложения (включително вече работещи системи в предприятието);

* Поетапно внедряване и др.

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

Целта на тази работа: Да се ​​запознае с концепцията за автоматизирани информационни системи, да разгледа процеса на проектиране.

За да се постигне целта, е необходимо да се решат следните задачи:

§ Формулирайте дефиниции на основни понятия и термини;

§ Помислете за целите и задачите на дизайна;

§ Запознайте се с основните етапи на проектиране;

§ Откройте фазите на развитие на автоматизирани информационни системи;

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

1. ОПРЕДЕЛЕНИЕ НА КОНЦЕПЦИИ АВТОМАТИЗИРАНА ИНФОРМАЦИОННА СИСТЕМА (AIS), ИНФОРМАЦИОННА СИСТЕМА (IS), ПРОЕКТ И ДИЗАЙН

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

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

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

а) проекция - това, което се получава чрез анализ на сложни явления с цел получаване на опростени представи, и

б) проект - това, което се получава чрез синтезиране на сложни представи от набор от по -прости изображения.

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

При проектирането на информационни системи информационните системи са обекти на проектиране и това е съвсем естествено за информатиката (тъй като ИС се считат за нейни основни обекти).

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

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

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

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

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

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

Добавянето на термина „автоматизиран“ към понятието „система“ отразява начините за създаване и функциониране на такава система.

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

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

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

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

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

Следните основни отличителни черти на проекта като обект на управление могат да бъдат разграничени:

· Ограничена крайна цел;

· Ограничена продължителност;

· Ограничен бюджет;

· Необходими ограничени ресурси;

· Новост за предприятието, за което се реализира проектът;

· Сложност;

· Правна и организационна поддръжка.

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

Проектирането на AIS се разбира като процес на преобразуване на входна информация за обект, методи и опит при проектирането на обекти със сходна цел в съответствие с GOST в проект за IS.

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

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

Технологията за проектиране на AIS е съвкупност от методология и инструменти за проектиране на AIS, както и методи и средства за нейната организация (управление на процеса на създаване и модернизиране на проект AIS).

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

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

Предмет на всяка избрана технология за проектиране трябва да бъде отражението на взаимосвързани процеси на проектиране на всички етапи от жизнения цикъл на AIS. Основните изисквания за избраната технология за проектиране включват следното:

· Създаденият проект трябва да отговаря на изискванията на клиента;

· Максимално отразяване на всички етапи от жизнения цикъл на проекта;

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

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

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

· Надеждност на дизайна и работата на проекта;

· Проста поддръжка на проектна документация.

Технологията за проектиране на AIS се основава на методологията, която определя същността, основните отличителни технологични характеристики.

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

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

компютърно проектирана информационна система за проектиране

2. ЦЕЛИ И ДИЗАЙН ЦЕЛИ

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

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

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

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

Основната задача на всеки успешен проект е да гарантира, че по време на стартирането на системата и по време на нейната работа ще бъде възможно да се гарантира:

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

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

· Изискваното време за реакция на системата на заявката;

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

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

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

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

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

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

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

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

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

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

3. ЕТАПИ НА ДИЗАЙН

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

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

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

Могат да се разграничат следните фази на развитие на автоматизирани информационни системи:

3.1 Формиране на концепцията. Концептуална фаза

Това включва:

· Формиране на идеи;

· Формиране на ключов екип по проекта;

· Проучване на мотивациите и изискванията на клиента и другите участници;

· Събиране на изходни данни и анализ на съществуващото състояние;

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

· Сравнителна оценка на алтернативите;

· Подаване на предложения, тяхното разглеждане и одобрение.

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

3.2 Изготвяне на техническо предложение

§ разработване на основното съдържание на основната структура на проекта;

§ разработване и одобряване на технически спецификации;

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

§ изготвяне на прогнози и бюджет на проекта;

§ развитие календарни плановеи увеличени работни графици;

§ подписване на договор с клиента;

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

3.3 Дизайн

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

§ изпълнение на основни проектни работи;

§ разработване на частни технически спецификации;

§ изпълнение на идеен проект;

§ изготвяне на технически спецификации и инструкции;

§ представяне на разработката на проекта, разглеждане и одобрение.

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

3.4 Развитие

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

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

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

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

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

3.5 Пускане в експлоатация на системата

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

Основните видове работа:

§ сложни тестове;

§ обучение на персонал за работата на създаваната система;

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

§ съпровод, подкрепа, обслужване;

§ оценка на резултатите от проекта и изготвяне на окончателни документи.

4. СЪСТАВ И СТРУКТУРА НА ТЕХНИЧЕСКИЯ ДИЗАЙН И ТЕХНИЧЕСКИЯ ДИЗАЙН

1. Общи разпоредби

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

1.2. TK е разработен за системата като цяло, проектиран да работи независимо или като част от друга система.

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

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

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

1.6. Промените в ТЗ се съставят чрез допълнение или протокол, подписан от клиента и разработчика. Допълнението или посоченият протокол е неразделна част от ТЗ по IP. На заглавната страница на ТЗ трябва да има запис „Валидно от ...“.

2. Състав и съдържание

2.1. ТЗ съдържа следните раздели, които могат да бъдат разделени на подраздели:

1) обща информация;

2) целта и целите на създаването (развитието) на системата;

3) характеристики на обектите;

4) системни изисквания;

5) състава и съдържанието на работата по създаването на системата;

6) процедурата за контрол и приемане на системата;

7) изисквания за състава и съдържанието на работата по подготовката на обекта за разработка за въвеждане на системата в експлоатация;

8) изисквания за документация;

9) източници на развитие.

TK може да включва приложения.

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

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

2.3. В раздела „Обща информация“ посочете:

1) пълното име на системата и нейния символ;

2) кода на темата или кода (номера) на договора;

3) името на компаниите на разработчика и клиента (потребителя) на системата и техните данни;

4) списък на документите, въз основа на които се създава системата, от кого и кога са одобрени тези документи;

5) планираните начални и крайни дати за създаване на системата;

6) информация за източниците и процедурата за финансиране на работата;

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

2.4. Раздел "Цел и цели на създаване (развитие) на системата" се състои от подраздели:

1) целта на системата;

2) целта на създаването на системата.

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

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

2.5. В раздела "Характеристики на обекта на информатизация" дайте:

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

2) информация за условията на работа на обекта за автоматизация.

2.6. Разделът Системни изисквания се състои от следните подраздели:

1) изисквания към системата като цяло;

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

3) изисквания за видовете сигурност.

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

2.6.1. В подраздел „Изисквания за системата като цяло“ посочете:

изисквания за структурата и функционирането на системата;

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

индикатори за местоназначение;

изисквания за надеждност;

изисквания за безопасност;

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

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

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

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

изисквания за защита от влиянието на външни влияния;

изисквания за чистота на патента;

изисквания за стандартизация и унификация;

Допълнителни изисквания.

2.6.1.1. Изискванията за структурата и функционирането на системата включват:

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

2) изисквания за методи и средства за комуникация за обмен на информация между компонентите на системата;

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

4) изисквания за режимите на работа на системата;

5) изисквания за диагностика на системата;

6) перспективи за развитие, модернизация на системата.

2.6.1.2. Изискванията за броя и квалификацията на персонала на ИС включват:

§ изисквания за броя на персонала (потребителите) на ИС;

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

§ необходим режим на работа на персонала на ИС.

2.6.1.3. В изискванията към показателите за предназначението на ИС са дадени стойностите на параметрите, характеризиращи степента на съответствие на системата с нейното предназначение.

2.6.1.4. Изискванията за надеждност включват:

1) състава и количествените стойности на показателите за надеждност за системата като цяло или нейните подсистеми;

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

3) изисквания за надеждност на хардуер и софтуер;

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

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

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

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

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

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

2.6.1.10. Допълнителните изисквания включват специални изисквания по преценка на разработчика или клиента на системата.

2.6.2. В подраздел „Изисквания за функциите (задачите)“, изпълнявани от системата, са дадени следното:

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

§ при създаване на система в две или повече опашки - списък с функционални подсистеми, отделни функции или задачи, които се пускат в действие в 1 -вата и следващите опашки;

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

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

§ списък и критерии за повреди за всяка функция, за които са зададени изисквания за надеждност.

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

2.6.3.2. За информационна поддръжка на системата са дадени следните изисквания:

1) към състава, структурата и методите за организиране на данни в системата;

2) обмен на информация между компонентите на системата;

3) информационна съвместимост със свързани системи;

4) относно прилагането на системи за управление на бази данни;

5) към структурата на процеса на събиране, обработка, прехвърляне на данни в системата и представяне на данни;

6) за защита на данните;

7) контрол, съхранение, актуализиране и възстановяване на данни;

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

2.6.3.4. За софтуера на системата е даден списък на закупения софтуер, както и изискванията:

1) до зависимостта на софтуера от операционната среда;

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

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

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

2) към функционалните, дизайнерските и експлоатационните характеристики на техническата поддръжка на системата.

2.6.3.6. Изискванията за метрологична поддръжка включват:

1) предварителен списък на измервателните канали;

2) изисквания за точността на измерванията на параметрите и (или) за метрологичните характеристики на измервателните канали;

3) изисквания за метрологична съвместимост на техническите средства на системата;

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

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

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

2.6.3.7. За организационна подкрепа са дадени изискванията:

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

2) към организацията на функционирането на системата и реда за взаимодействие между персонала на ИС и персонала на обекта на информатизация;

3) за защита от грешни действия на персонала на системата.

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

Този раздел също така предоставя:

1) списък на документите, представени в края на съответните етапи и етапи на работа;

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

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

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

2.8. В раздела "Процедура за контрол и приемане на системата" посочете:

1) видове, състав, обхват и методи на изпитване на системата и нейните компоненти;

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

2.9. В раздела „Изисквания за състава и съдържанието на работата по подготовката на обекта за автоматизация за въвеждане в експлоатация на системата“ е необходимо да се предостави списък на основните дейности и техните изпълнители, които трябва да бъдат изпълнени при подготовката на проекта за въвеждане в експлоатация на ИС.

Списъкът на основните дейности включва:

1) въвеждане на информацията, постъпваща в системата (в съответствие с изискванията за информационна и езикова подкрепа);

2) създаване на условия за функционирането на проекта, при които се гарантира съответствието на създадената система с изискванията, съдържащи се в ТЗ;

3) създаване на звена и услуги, необходими за функционирането на системата;

4) времето и процедурата за набиране на персонал и обучение на персонала.

2.10. В раздела „Изисквания за документация“ са дадени следното:

1) списък на комплектите и типовете документи, които ще бъдат разработени, съгласувани от разработчика и Клиента на системата;

2) списък на документите, издадени на машинен носител;

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

2.11. Разделът „Източници на развитие“ трябва да изброява документите и информационните материали, въз основа на които е разработена ТЗ и които трябва да се използват при създаването на системата.

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

3.1. Разделите и подраздели на ТЗ трябва да се поставят в реда, установен в раздела. 2 от този стандарт.

3.2. Номерата на листове (страници) се записват, като се започне от първия лист, следващ заглавната страница, в горната част на листа (над текста, в средата) след обозначаването на TK кода по IP.

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

Формата на заглавната страница на ТЗ е дадена в Приложение 2. Формата на последната страница на ТЗ е дадена в Приложение 3.

3.4. Заглавната страница на допълнението към ТЗ е съставена по същия начин, както заглавната страница на техническото задание. Вместо името „Техническо задание“ те пишат „Допълнение № ... към ТЗ за AC ...“.

3.5. В следващите листове на допълнението към ТЗ се поставя основата за промяната, съдържанието на промяната и връзките към документите, в съответствие с които са направени тези промени.

3.6. При представяне на текста на допълнение към ТЗ трябва да се посочат номерата на съответните клаузи, подточки, таблици на основния ТЗ и др. И думите „замени“, „допълни“, „изключи“, „преформулира ”Трябва да се използва.

Процедурата за разработване, координиране и одобряване на ТЗ за ИС.

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

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

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

Работата по одобряването на проекта на ТЗ за ИС се извършва съвместно от разработчика на ТЗ и клиента на системата, всеки в организациите на нейното министерство (отдел).

3. Срокът на одобрение на проекта на ТЗ във всяка организация не трябва да надвишава 15 дни от датата на получаването му. Препоръчва се изпращането на копия от проекта на ТЗ (копия) едновременно до всички организации (отдели) за одобрение.

4. Коментарите по проекта на ТЗ трябва да бъдат представени с техническа обосновка. Решенията по коментарите трябва да се вземат от разработчика на проекта на ТЗ и клиента на системата преди одобряването на ТЗ по ИС.

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

6. Одобрението на проекта на ТЗ е разрешено за съставяне на отделен документ (писмо). В този случай, под заглавието „Договорено“ направете връзка към този документ.

7. Одобрението на ТЗ се извършва от ръководителите на компаниите на разработчика и клиента на системата.

8. Копия от одобрения ТЗ в рамките на 10 дни след одобрението се изпращат от разработчика на ТЗ на участниците в създаването на системата.

9. Координирането и одобряването на допълнения към ТЗ се извършват по начина, определен за ТЗ по ИС.

10. Не се допуска одобрение на промените в ТЗ след подаването на системата или нейната опашка за приемни тестове.

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

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

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

Всъщност техническият проект съдържа комплекс от икономически, математически и алгоритмични модели.

Пълен набор от технически дизайн на системата включва 10 документа:

1. Обяснителна бележка.

2. Функционална и организационна структура на системата.

3. Постановка на проблем и алгоритъм на решение.

4. Организиране на информационната база.

5. Албум на формуляри на документи.

6. Софтуерна система.

7. Принципът на изграждане на комплекс от технически средства.

8. Изчисляване на икономическата ефективност на системата.

9. Мерки за подготовка на съоръжението за внедряване на системата.

10. Списък на документите.

От горния списък документ 3 „Изложение на задачите и алгоритъмът за решаване“ се изпълнява за всяка отделна задача, включена в EIS, останалите документи са общи за цялата система. В допълнение, документи 1, 2, 5, 8 и 9 могат да бъдат разработени за отделни подсистеми.

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

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

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

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

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

§ икономико -математически модел на проблема (структурна и подробна форма на представяне);

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

§ нормативна справочна информация (НСИ) - съдържание и форми на представяне;

§ информация, съхранявана за комуникация с други задачи;

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

§ информация за извършване на промени (система за извършване на промени и списък с информация, подлежаща на промени);

§ алгоритъм за решаване на задачата (последователност от етапи на изчисление, диаграма, формули за изчисление);

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

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

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

Информационната част на техническия проект обединява документи 4 и 5. Документът „Организация на информационната база“ отразява: източници на информация и методи за нейното предаване за решаване на първичния комплекс от функционални задачи; набор от показатели, използвани в системата; състав на документите, срокове и честота на получаването им; основни дизайнерски решения за организацията на фонда на НСИ; състав на НСИ, включително списък на детайлите, тяхното определение, значение, обхват на промяна и списък на документите на НСИ; списък с набори от данни за референтни данни, техния обем, ред и честота на корекция на информацията; предложения за унифициране на документацията, тест пример за изменение на НСИ; структурна форма на НСИ с описание на връзката между елементите; изисквания за технологията на създаване и поддържане на фонда; методи за съхранение, търсене, модификация и контрол, определяне на обеми и потоци от информация на референтни данни.

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСЪК НА ИЗПОЛЗВАНАТА ЛИТЕРАТУРА

1. Насоки за изучаване на дисциплината „Автоматизирани информационни системи“ [Електронен ресурс]. - Москва, 2006. - Режим на достъп:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Заглавие. от екрана.

2. Уикипедия, безплатната енциклопедия [Електронен ресурс]/Статия „Информационна система“ - Режим на достъп: http://ru.wikipedia.org/wiki/Информационна система.

3. Компютърна преса: Интернет списание. - Електрон. Дан. - [Б.м., 2001]. - Режим на достъп: http://compress.ru/article.aspx?id=12282.

4. Вендров А. М., „Проектиране на софтуер за икономически информационни системи“ / А.М. Вендра. - М.: „Финанси и статистика“, 2000. - 364 с.

5. "Техническо задание за създаване на автоматизирана система" / - М.: ГОСТ 34.602-89, 1990.

6. Грекул В.И. "Проектиране на информационни системи" / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкин. - М.: Интернет университет за информационни технологии, 2008.

Публикувано на Allbest.ru

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

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

дипломна работа, добавена на 22.11.2015 г.


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

практически доклад, добавен на 16.04.2017 г.


Жизнен цикъл на автоматизираните информационни системи. Основи на методологията за проектиране на автоматизирани системи, базирани на CASE технологии. Фазата на анализ и планиране, изграждане и внедряване на автоматизирана система. Модел на водопад и спирала.

курсова работа, добавена на 20.11.2010 г.


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

дипломна работа, добавена на 23.06.2015 г.


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

презентация, добавена на 14.10.2013 г.


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

резюме, добавено на 17.11.2011 г.


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

курсова работа, добавена на 04.11.2014 г.


Създаване и организиране на автоматизирани информационни системи (AIS). Основни компоненти и технологични процеси на AIS. Етапи и етапи на създаване на AIS от позицията на ръководството на организацията. Разработване на комплекси от дизайнерски решения за автоматизирана система.

резюме, добавено на 18.10.2012 г.


Основните фактори, влияещи върху историята на развитието на корпоративни автоматизирани информационни системи. Техните общи характеристики и класификация. Състав и структура на интегрирана AIS. ERP системите като съвременен тип корпоративна информационна система.

презентация, добавена на 14.10.2013 г.


Анализ на предметната област, етапи на проектиране на автоматизирани информационни системи. Системи за инструменти за разработка на софтуер. Ролята на инструментите CASE в проектирането на информационния модел. Логическият модел на проектираната база данни.

На 1 декември 2015 г. се проведе открита защита на Автоматизираната информационна система за управление на проекти (AIS PU), създадена със заповед на Министерството на промишлеността и търговията на Русия. В отбраната, председателствана от първия заместник -министър на промишлеността и търговията на Руската федерация Глеб Никитин, участваха ръководители на отдели на министерството, представители на Министерството на икономическото развитие и Министерството на отбраната на Руската федерация.

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

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

Системата е създадена от руския системен интегратор "Inline-Technologies" с участието на местния разработчик на софтуер "LM-Soft". AIS PU е разработен на базата на руската платформа 1С, използвайки безплатен софтуер и собствен софтуер.

Въз основа на резултатите от изучаването на функционалността на системата бяха получени положителни отзиви както от ръководството и служителите на Министерството на промишлеността и търговията, така и от Министерството на икономическото развитие, което отговаря за прилагането на механизмите за управление на проекти в правителството тела. Освен това положителна обратна връзка за възможностите на AIS PU беше дадена от промишлени предприятия, които представиха своите пилотни проекти като част от развитието на системата. По -специално, представители на Държавния научен център „Крилов“, АД „Научно -производствена корпорация“ Уралвагонзавод ”и Федералния държавен научно -изследователски институт по геодезия дадоха положителна обратна връзка за пилотната работа на ПУ AIS. Трябва също така да се отбележи, че представители на Garrison JSC, който е под юрисдикцията на Министерството на отбраната, както и представители на някои банки с държавно участие, проявиха жив интерес към системата и интерес към съвместно сътрудничество при изпълнението на управлението на проекти .

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

„Основната цел на въвеждането на AIS PU е да подобри качеството на контрол и управляемост, да улесни взаимодействието между властите и изпълнителите на мащабни проекти. При разработването на системата се вземат предвид преди всичко отрасловите стандарти, постановления и разпореждания на правителството, укази на президента и заповеди на министъра на промишлеността и търговията, както и най -добрите местни и чуждестранни практики. Повече от 600 компонента са проектирани за AIS PU, качени са над 20 000 справочници, речници и класификатори. Като част от по -нататъшната работа по развитието на AIS PU се планира интегрирането на системата като една от подсистемите на Държавната информационна система на промишлеността, която в момента се създава от Министерството на промишлеността и търговията на Русия “, каза Сергей Валуев.

Въвеждането на методи за управление на проекти е определено като един от основните инструменти за модернизиране на публичната администрация и е залегнало в новото издание на „Основните направления на дейност на правителството на Руската федерация за периода до 2018 г.“, подписано от Prime Министър Дмитрий Медведев.