Пристапи за развој на софтвер. Структурен пристап кон развој на софтвер. Принципи и значење на агилен развој

1.Кодирање

Во фазата на развој на софтвер се вршат следните главни дејства: кодирање; тестирање; развој на систем за помош на ПП; креирање на корисничка документација; креирање верзија и инсталација на софтвер,

Кодирањето е процес на конвертирање на резултатите од дизајнот на високо и ниско ниво во готов софтверски производ. Со други зборови, при кодирање, компајлираниот софтверски модел се опишува со користење на избраниот програмски јазик, кој може да биде кој било од постоечките јазици. Изборот на јазик се врши или на барање на клиентот, или земајќи го предвид проблемот што се решава и лично искуствопрограмери.

При кодирање, мора да го следите стандардот за избраниот јазик, на пример, за јазикот C е ANSI C, а за C++ е ISO/IEC 14882 „Стандард за C++ ProgrammingLanguage“.

Покрај општо прифатениот стандард за програмски јазик, компанијата може да развие и свои дополнителни барања за правилата за пишување програми. Тие главно се однесуваат на правилата за форматирање на текстот на програмата.

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

Во фазата на кодирање, програмерот пишува програми и сам ги тестира. Овој тип на тестирање се нарекува единечно тестирање. Сите прашања поврзани со тестирањето на софтверот се дискутирани во Поглавје. 10, овде е опишана и технологијата за тестирање што се користи во фазата на развој на софтвер. Оваа технологија се нарекува тестирање „стаклена кутија“ (стаклена кутија);понекогаш тоа се нарекува и тестирање „бела кутија“ (бела кутија)наспроти класичниот концепт на „црна кутија“.

Во тестирањето на црната кутија, програмата се третира како објект чија внатрешна структура е непозната. Тестерот внесува податоци и го анализира резултатот, но не знае точно како функционира програмата. При изборот на тестови, специјалист бара влезни податоци и услови кои се интересни од негова гледна точка, што може да доведе до нестандардни резултати. Тој е првенствено заинтересиран за оние претставници на секоја класа на влезни податоци во кои најверојатно ќе се појават грешки во програмата што се тестира.

При тестирање на „стаклена кутија“ ситуацијата е сосема поинаква. Тестерот (во овој случај самиот програмер) развива тестови врз основа на познавање на изворниот код до кој има пристап целосен пристап. Како резултат на тоа, тој ги добива следните бенефиции.

1. Насока на тестирање. Програмерот може да ја тестира програмата на делови, да развие специјални потпрограми за тестирање кои го повикуваат модулот што се тестира и му ги пренесуваат податоците од интерес за програмерот. Многу е полесно да се тестира посебен модул како „стаклена кутија“.

2.Целосно покривање на кодот. Програмерот секогаш може да одреди кои фрагменти од кодот работат во секој тест. Тој гледа кои други гранки на кодот остануваат непроверени и може да ги избере условите под кои тие ќе бидат тестирани. Подолу опишуваме како да го следиме степенот на покриеност на кодот на извршените тестови.

3. Способност за контрола на текот на командите. Програмерот секогаш знае која функција треба да се изврши следната во програмата и каква треба да биде нејзината моментална состојба. За да открие дали програмата работи како што мисли, програмерот може да вклучи команди за дебагирање кои прикажуваат информации за нејзиното извршување или да користи специјална програма за да го направи тоа. софтвернаречен дебагер. Дебагерот може да направи многу корисни работи: следење и менување на секвенцата на извршување на програмските команди, прикажување на содржината на неговите променливи и нивните адреси во меморијата итн.

4.Способност за следење на интегритетот на податоците. Програмерот знае кој дел од програмата треба да го промени секој податочен елемент. Со следење на состојбата на податоците (користејќи го истиот дебагер), тој може да идентификува грешки како што се менување на податоците од погрешни модули, нивно неправилно толкување или неуспешна организација.Програмерот може да го автоматизира самиот тестирање.

5. Визија на внатрешни гранични точки. ВО изворен кодвидливи се оние гранични точки на програмата кои се скриени од надворешен поглед. На пример, може да се користат неколку сосема различни алгоритми за извршување на одредена акција, а без да се погледне кодот, невозможно е да се одреди кој одбрал програмерот. Друг вообичаен пример би бил проблем со прелевање во бафер кој се користи за привремено складирање на влезните податоци. Програмерот може веднаш да каже со колкава количина на податоци ќе се прелее баферот и нема потреба да спроведува илјадници тестови.

6. Можност за тестирање утврдена со избраниот алгоритам. Тестирањето на обработката на податоците што користи многу сложени пресметковни алгоритми може да бара посебни технологии. Класичните примери вклучуваат трансформација на матрица и сортирање на податоци. Тестерот, за разлика од програмерот, треба точно да знае кои алгоритми се користат, па затоа мора да се сврти кон специјализирана литература.

Тестирањето на стаклената кутија е дел од процесот на програмирање. Програмерите ја вршат оваа работа цело време; тие го тестираат секој модул откако ќе го напишат, а потоа повторно откако ќе го интегрираат во системот.

Кога вршите тестирање на единицата, можете да користите технологија за структурно или функционално тестирање или и двете.

Структурнитестирањето е тип на тестирање на стаклена кутија. Неговата главна идеја е правилниот избор на софтверската патека што треба да се тестира. За разлика од него функционалнитестирањето спаѓа во категоријата тестирање на црната кутија. Секоја програмска функција се тестира со внесување на нејзините влезни податоци и анализа на нејзиниот излез. Во исто време, внатрешната структура на програмата многу ретко се зема предвид.

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

Предмет на тестирање може да биде не само целосна патекапрограма (редоследот на команди што ги извршува од почеток до завршување), но и нејзините поединечни делови. Апсолутно е нереално да се тестираат сите можни начини на извршување на програма. Затоа, специјалистите за тестирање ги идентификуваат од сите можни патеки оние групи кои апсолутно треба да се тестираат. За избор користат посебни критериуми наречени критериуми за покриеност (критериуми за покриеност),кои одредуваат многу реален (макар и доста голем) број на тестови. Овие критериуми понекогаш се нарекуваат логички критериуми за покривање,или критериуми за комплетност.

3. Развој на систем за помош софтверски производ. Креирање на корисничка документација

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

Често се случува неколку луѓе да работат на креирање на софтвер, но никој од нив не сноси целосна одговорност за неговиот квалитет. Како резултат на тоа, софтверот не само што нема корист од фактот што го развиваат повеќе луѓе, туку и губи, бидејќи секој потсвесно ја префрла одговорноста на другиот и очекува дека неговите колеги ќе го завршат овој или оној дел од работата. Овој проблем се решава со назначување уредник кој сноси целосна одговорност за квалитетот и точноста на техничката документација.

Системот за помош на ПП е формиран врз основа на материјалот развиен за упатството за употреба. Таа е формирана и креирана од лицето одговорно за извршување на оваа работа. Може да биде или технички уредник или некој од развивачите заедно со техничкиот уредник.

Добро документирана ПП ги има следните предности.

1. Леснотија на користење. Ако софтверот е добро документиран, тогаш е многу полесно да се примени. Корисниците го учат побрзо, прават помалку грешки и како резултат на тоа ја вршат својата работа побрзо и поефикасно.

2. Пониска цена техничка поддршка. Кога корисникот не може да сфати како да ги изврши дејствата што му се потребни, тој ја повикува службата за техничка поддршка на производителот на ПХБ. Водењето таква услуга е многу скапо. Добриот прирачник им помага на корисниците сами да ги решаваат проблемите и да ја намалат потребата да контактираат со тимот за техничка поддршка.

3. Висока сигурност. Неразбирливата или невешт документација го прави софтверот помалку сигурен, бидејќи неговите корисници имаат поголема веројатност да направат грешки и да им е тешко да разберат што ги предизвикало и како да се справат со нивните последици.

Леснотија на одржување. Огромна сума пари и време се трошат на анализирање на проблеми кои се предизвикани од грешки на корисниците. Промените направени во новите изданија на софтвер често се само промени на интерфејсот на старите функции. Тие се воведени за корисниците конечно да сфатат како да го користат софтверот и да престанат да повикуваат техничка поддршка. Добро управување во голема мера

Компјутерски науки, кибернетика и програмирање

Итерација N Унифициран развојен процес софтвер USDP Use Case Model ги опишува случаите во кои ќе се користи апликацијата. Аналитичкиот модел ги опишува основните класи за апликацијата. Дизајнерскиот модел ги опишува врските и односите помеѓу класите и доделените објекти.Моделот за распоредување ја опишува дистрибуцијата на софтверот низ компјутерите.

Лекција бр. 20
Општи принципи и пристапи за развој на софтвер

Модели за развој на софтвер

1. Водопаднаја
2. Каскаден модел
3. Спирала
4. Екстремно програмирање
5. Инкрементално
6. Методологија на MSF

Модел на водопад

Спирален модел

Инкрементален развој

Анализа на барањата

Дизајн

Имплементација

Компонента

тестирање

Интеграција

Тестирање

една целина

Итерација 1 Итерација 2…. Итерација Н

Унифициран процес на развој на софтвер (USDP)

1. Употребен модел ги опишува случаите во кои ќе се користи апликацијата.
2. Аналитичкиот модел ги опишува основните класи за апликацијата.
3. Дизајнерскиот модел ги опишува врските и односите помеѓу класите и избраните објекти
4. Моделот на распоредување ја опишува дистрибуцијата на софтверот низ компјутерите.
5. Моделот за имплементација ја опишува внатрешната организација на програмскиот код.
6. Тест моделот се состои од компоненти за тестирање, процедури за тестирање и различни тест случаи.

Методологија на MSF

Типични компоненти за архитектура на софтверски производ и типични софтверски барања

толеранција на грешкизбир на својства на системот што ја зголемува неговата доверливост преку откривање грешки, обновување и локализирање на лошите последици за системот. При дизајнирање на кој било реален систем за да се обезбеди толеранција на грешки, неопходно е да се предвидат сите можни ситуации кои можат да доведат до дефект на системот и да се развијат механизми за справување со дефекти.

Доверливост способноста на системот да издржи разни неуспеси и неуспеси.

Одбивање ова е системска транзицијакако резултат на грешката во целосно нефункционална состојба.

Несреќа грешка во работата на системот што не доведува до дефект на системот.

Колку помалку неуспеси и неуспеси во одреден временски период, толку посигурен се смета системот.

Како и други дела кои може да ве интересираат
57355.		Разновидност на органски соединенија, нивна класификација. Органски материи од жива природа	48,5 KB
	Разновидноста на органските соединенија е одредена од уникатната способност на атомите на јаглерод да се поврзуваат едни со други со едноставни и повеќекратни врски за да формираат соединенија со речиси неограничен број атоми поврзани во синџири: циклуси, велосипеди, трицикли, полицикли, рамки итн.
57359.		Обработка на модели на вербални информации	291 KB
	Основни поими: модел; информативен модел; вербални информации модел; прибелешка; апстрактни. Синопсис Синопсис од лат. Направете белешка за 2. Зачувајте го документот во сопствената папка под името Забелешка.
57361.		Број и слика 3. Порамнување на броеви на граници 3. Пишување броеви 3. Порамнување на бројот на објекти	35,5 KB
	Колку суштества има Кој е на прво место Кој е на последно место Кој е рангиран на број 1 Кој е рангиран на број 2 Наведете ги соседите на ежот. Кој е десната верверица Кој е левак жирафа Кој е најголем Кој е најмал Кој стои среде суштества Гра Покажи ми, немај милост.

Денес во софтверското инженерство постојат два главни пристапи за развој на софтвер за EIS, чија фундаментална разлика се должи на различни начинираспаѓање на системи. Првиот пристап се нарекува функционално-модуларен или структурен. Се заснова на принципот на функционално распаѓање, во кој структурата на системот е опишана во однос на хиерархијата на неговите функции и преносот на информации помеѓу поединецот функционални елементи. Вториот, објектно-ориентиран пристап користи разградување на објектот. Во овој случај, структурата на системот е опишана во смисла на објекти и врски меѓу нив, а однесувањето на системот е опишано во смисла на размена на пораки помеѓу објектите.

Значи, суштината на структурниот пристап кон развојот на софтвер за EIS лежи во неговото распаѓање (распаѓање) на автоматизирани функции: системот е поделен на функционални потсистеми, кои, пак, се поделени на потфункции, оние на задачи итн. специфични процедури. Во исто време, автоматизираниот систем одржува холистички поглед во кој сите компоненти се меѓусебно поврзани. Кога се развива систем „од долу нагоре“, од индивидуални задачи до целиот систем, се губи интегритетот, се јавуваат проблеми при опишување информациска интеракцијапоединечни компоненти.

Сите најчести методи на структурниот пристап се засноваат на голем број општи принципи. Основните принципи се:

принципот „раздели и владеј“ (види потсекција 2.1.1);

принципот на хиерархиско подредување е принципот на организирање на компонентите на системот во хиерархиски структури на дрво со додавање на нови детали на секое ниво.

Истакнувањето на два основни принципи не значи дека преостанатите принципи се споредни, бидејќи игнорирањето на кој било од нив може да доведе до непредвидливи последици (вклучувајќи го и неуспехот на целиот проект). Главните од овие принципи се:

принципот на апстракција - истакнување на суштинските аспекти на системот и апстрахирање од неважното;

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

принцип на структурирање на податоците - податоците мора да бидат структурирани и хиерархиски организирани.

Структурниот пристап користи главно две групи алатки кои ја опишуваат функционалната структура на системот и односите помеѓу податоците. Секоја група алатки одговара на одредени типови на модели (дијаграми), од кои најчести се:

DFD (Data Flow Diagrams) - дијаграми за проток на податоци;

SADT (Structured Analysis and Design Technique - метод на структурна анализа и дизајн) - модели и соодветни функционални дијаграми;

ERD (Entity-Relationship Diagrams) - дијаграми за ентитет-врска.

Дијаграмите за проток на податоци и дијаграмите за врска со ентитетите се најчесто користените типови на модели во алатките CASE.

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

Во фазата на формирање на барања за софтвер, SADT моделите и DFD се користат за изградба на моделот „AS-IS“ и моделот „TO-BE“, со што се одразува постоечката и предложената структура на деловните процеси на организацијата и интеракцијата помеѓу нив ( употребата на SADT моделите, по правило, е ограничена само на оваа фаза, бидејќи тие првично не беа наменети за дизајн на софтвер). Со помош на ERD, описот на податоците што се користат во организацијата се врши на концептуално ниво, независно од алатките за имплементација на базата на податоци (DBMS).

Во фазата на дизајнирање, DFD се користат за да се опише структурата на дизајнираниот софтверски систем и тие можат да се рафинираат, прошират и дополнат со нови дизајни. Слично на тоа, ERD се рафинирани и дополнети со нови конструкции кои го опишуваат претставувањето на податоците на логично ниво погодно за последователно генерирање на шема на база на податоци. Овие модели може да се дополнат со дијаграми што ја рефлектираат архитектурата на софтверот, блок дијаграми на програми, хиерархија екрански формии мени, итн.

Наведените модели заедно даваат целосен опис на EIS софтверот, без разлика дали системот е постоечки или ново развиен. Составот на дијаграмите во секој конкретен случај зависи од сложеноста на системот и потребната комплетност на неговиот опис.

Предметната област за повеќето примери на дијаграми дадени во ова поглавје е даночниот систем на Руската Федерација, чиј најцелосен опис е содржан во даночниот законик на Руската Федерација. Информациска технологија, кои се користат во даночниот систем на Руската Федерација, имаат одредени карактеристики.

Значи, суштината на структурниот пристап кон развојот на софтвер за EIS лежи во неговото распаѓање (распаѓање) на автоматизирани функции: системот е поделен на функционални потсистеми, кои, пак, се поделени на потфункции, оние на задачи итн. специфични процедури. Во исто време, системот одржува холистички поглед во кој сите компоненти се меѓусебно поврзани. Кога се развива систем „од долу нагоре“, од индивидуални задачи до целиот систем, се губи интегритетот и се јавуваат проблеми при опишување на информациската интеракција на поединечни компоненти.

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

1. Принципот на „раздели и владеј“;

2. Принципот на хиерархиско подредување е принципот на организирање на компонентите на системот во хиерархиски структури на дрво со додавање на нови детали на секое ниво.

Изолирањето на два основни принципи не значи дека преостанатите принципи се споредни, бидејќи игнорирањето на било кој од нив може да доведе до непредвидливи последици (вклучувајќи го и неуспехот на целиот проект“). Главните од овие принципи се:

1. Принципот на апстракција - истакнување на суштинските аспекти на системот и апстрахирање од неважното.

2. Принципот на конзистентност, валидност и конзистентност на елементите на системот.

3. Структурен принцип податоци - податоцимора да бидат структурирани и хиерархиски организирани.

Во структурниот пристап, главно постојат две групи на алатки кои ја опишуваат функционалната структура на системот и односите помеѓу податоците. Секоја група алатки одговара на одредени типови на модели (дијаграми), најчести меѓу нив се:

· DFD (Data Flow Diagrams) - дијаграми за проток на податоци;

· SADT (Structured Analysis and Design Technique - методологија на структурна анализа и дизајн) - модели и соодветни функционални дијаграми: нотации IDEF0 (функционално моделирање на системи), IDEF1х (концептуално моделирање на бази на податоци), IDEF3х (конструкција на системи за проценка на квалитетот на работа на некој предмет; графички описпроток на процеси, интеракција на процеси и објекти кои се менуваат од овие процеси);

· ERD (Entity - Relationship Diagrams) - ентитет-однос дијаграми.

Речиси сите методи на структурен пристап (структурна анализа) во фазата на формирање на барања за софтвер користат две групи алатки за моделирање:

1. Дијаграми кои ги илустрираат функциите што системот мора да ги извршува и односите помеѓу овие функции - DFD или SADT (IDEF0).

2. Дијаграми кои моделираат податоци и нивните односи (ERD).

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

Во фазата на формирање на барања за софтвер, SADT моделите и DFD се користат за изградба на моделот „AS-IS“ и моделот „TO-BE“, со што се одразува постоечката и предложената структура на деловните процеси на организацијата и интеракцијата помеѓу нив ( употребата на SADT моделите кои обично се ограничени само на оваа фаза, бидејќи тие првично не биле наменети за софтверски дизајн). Со помош на ERD, опис на податоците што се користат во организацијата се врши на концептуално ниво, без оглед на алатките за имплементација на базата на податоци (DBMS).

1. Цел на технологијата за програмирање. Историја на развојот на програмската технологија. Видови софтверски проекти. Компоненти на програмската технологија. Проект, производ, процес и луѓе

2. Програмски животен циклус. Цикличната природа на развојот. Основни концепти на технологија за програмирање. Процеси и модели. Фази и врти. Пресвртници и артефакти. Засегнати страни и вработени.

3. Идентификација и анализа на барањата. Софтверски барања. Графикон за развој на барања. Управување со барањата.

4. Архитектонски и детален проект. Имплементација и кодирање. Тестирање и верификација. Процес на контрола на квалитетот. Методи на бела и црна кутија. Инспекции и прегледи. Цели за тестирање. Верификација, валидација и тестирање на системот. Одржување и тековен развој.

5. Модели на развојниот процес. Модели на водопади и транспортери. Спирални и инкрементални модели. Модели за флексибилни развојни процеси.

6. Изградба на процесен модел. Идентификувајте ги барањата за процесот. Користени фази, пресвртници и артефакти. Избор на процесна архитектура. Постапка за извршување на стандарден проект. Документирани процедури.

7. Модели на тим за развој. Колективна природа на развој. Оптимална големина на тимот. Подреденост на учесниците во проектот. Развој на тимот и развој на персоналот. Специјализација, соработка и интеракција.

8. Модели на тим за развој. Хиерархиски модел на тим. Метод на хируршки тим. Модел на врснички тим.

9. Природата на програмирањето. Наука за програмирање. Уметноста на програмирање. Занаетот за програмирање. Програмски парадигми. Структурно програмирање. Логичко програмирање. Објектно-ориентирано програмирање.

10. Софтверска архитектура. Управување со настани. Архитектура на клиент/сервер. Услуги. Трислојна архитектура. Програмски дизајн. Концептуален дизајн. Логички дизајн. Детален дизајн.

1. Новиков пристапи кон развој на софтвер“ http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Екстремно програмирање. – Санкт Петербург: Петар, 2002 г.

3. Технологија за развој на софтвер. – Санкт Петербург. : Петар, 2004 година.

4. Брукс Џуниор. се дизајнирани и креирани софтверски системи. М.: Наука, 1975; ново издание на преводот: The Mythical Man-Month. СПб.: СИМБОЛ+, 1999 г.

5. Алгоритми + структури на податоци = програми. М., Мир, 1978 година.

6. Систематско програмирање. Вовед. М.: Мир, 1977 година.

7. Структурно програмирање. М.: Мир, 1975 година.

8. Програмска дисциплина. М.: Мир, 1978 година.

9. Технологии за развој на софтвер. – Санкт Петербург: Петар, 2002 г.

10. Тереховско програмирање. М.: БИНОМ, 2006 г.

11. Рамбо Ј. Унифициран процес на развој на софтвер. Санкт Петербург: Петар, 2002 година.

Економска теорија за менаџери

Основни микроекономски теории. Примери на примена во анализата на економските процеси. Основни макроекономски теории. Примери на примена во анализата на економските процеси. Принципи и методи на управување со економските процеси. Алатки за проценка на степенот на развиеност на економските процеси Проблеми на проширена репродукција. Фактори на економски раст на руската економија. Критериуми и индикатори за одржлив развој. Измазнување на цикличните флуктуации. Улогата на мултипликаторот и акцелераторот во проценката на темпото на економскиот развој. Производните функции во економијата. Примери на примена во анализата на економските процеси. Профит. Пресметка на индикатори кои влијаат на добивката, графичка сликарамномерна точка. Методологија за спроведување на инвестициска политика.

Курс по економска теорија: учебник за универзитети / Ед. . –Киров: „АСА“, 2004. Колемаев - математичко моделирање. Моделирање на макроекономски процеси и системи: учебник. М.: ЕДИНСТВО-ДАНА, 2005. Бажинска кибернетика. Харков: Конзул, 2004. Работилница Леушин за методи на математичко моделирање: учебник. Државата Нижни Новгород техн. Универзитет - Н. Новород, 2007. Политичарите за економија: Предавања на нобеловци по економија. М.: Модерна економија и право, 2005. Черемних. Напредно ниво: Учебник.-М.:ИНФРА-М, 2008. Еволуција на мини-економските институции. Економски институт, филијала Урал на Руската академија на науките, - М.: Наука, 2007 година.

Технологии за развој и донесување одлуки за управување [N]

Донесување одлуки како основа на активноста на менаџерот. Вовед во теоријата на одлуки. Основни концепти на теоријата на одлуки. Модели за управување со бизнисот и нивното влијание врз одлучувањето. Различни начиникласификација на решенија. Класификации: според степенот на формалност, според степенот на рутина, според зачестеноста, според итноста, според степенот на постигнување на целите, според методот на избор на алтернатива. Основни методи на одлучување. Волеви методи на одлучување. Цели на одлучување. Време кога барате решенија. Основни грешки Математички методи на одлучување. Математички аспекти на теоријата на одлуки. Оперативно истражување. Математички пристап кон донесување одлуки. Дрво на одлуки. Модели на развој и одлучување. Теорија на игри. Математички методи на одлучување. Математички аспекти на теоријата на одлуки. Модели на теорија на редици. Модели за управување со залихи. Модел на линеарно програмирање. Транспортни задачи. Симулациско моделирање. Мрежна анализа. Економска анализа. Ограничувања на рационални модели. Карактеристики на развој и одлучување во група. Метод за одредување на групна кохезија врз основа на степенот на поврзаност на множества. Методи за донесување колективни одлуки. Консензус метод. Методи на гласање. Креативни методи на одлучување. Бура на идеи. Конференција на идеи. Советот на бродот. Методот „Капчиња за размислување“ на Де Боно. Теорија на инвентивно решавање проблеми (TRIZ). Совршено крајно решение. Примери на проблеми и нивни решенија со помош на TRIZ. Примена на TRIZ методите при донесување уникатни и креативни одлуки. Методи за развој на идеи за решенија и нивно прилагодување на ситуацијата. Модел на дрво за гол. Стратегија за координирање на интересите. Формирање на одлуки за координирање на интересите. Методи за утврдување на интересите на договорните страни. Системи за поддршка на одлуки (експертски системи). Историја на создавање на системи за одлучување. Класификација на системи за одлучување. Типична структураекспертски систем. Методи на презентирање знаење. Методи на логичко заклучување. Примена на експертски системи во пракса.

I. Теорија на одлучување: Учебник. - М.: Испит, 2006. - 573 стр. I. Донесување одлуки. Теорија и методи за развој на менаџерски одлуки. Упатство. - М.: МарТ, 2005. - 496 стр Развој на одлуки за управување - М.: Издавачка куќа "Дело", 2004 - 392 стр. Експертски проценки и донесување одлуки - М.: Патент, 1996. - 271 стр. Таха // Вовед во оперативно истражување = Операционо истражување: вовед. - 7-ми изд. - М.: „Вилијамс“, 2007. - стр. 549-594. Г. Теил. Економски прогнози и донесување одлуки. М.: „Прогрес“ 1970. К. Д. Луис. Методи за прогнозирање на економските показатели. М.: „Финансии и статистика“ 1986. Г. С. Килдишев, А. А. Френкел. Анализа и прогнозирање на временски серии. М.: „Статистика“ 1973. O. Kim, C. W. Muller, U. R. Klekka и други. Фактор, дискриминантна и кластерска анализа. М.: „Финансии и статистика“ 1989. Ефективен менаџер. Книга 3. Донесување одлуки. – МИМ ЛИНК, 1999 Туревски и менаџмент на претпријатие за моторно транспорт. - М.: Виша школа, 2005. , ; Изменето од . Системска анализа во управувањето: упатство. – М.: Финансии и статистика, 2006. , Тинков: учебник. – М.: КНОРУС, 2006 година.

Моделирање на деловните процеси во системи за интегрирано управување

По кои принципи се разликуваат деловните процеси? Кој е проблемот на сеопфатен опис на деловните процеси? Што е систем, какви својства има? Улогата на системската анализа во моделирањето на деловните процеси? Процесот како предмет на контрола. Процесна средина. Основни елементи на еден деловен процес. Предности и недостатоци на функционално и процесно управување. Циклус на управување со PDCA. Фази на циклусот на управување со процесите. PDCA циклус и имплементација на барањата ISO 9001:2008. SADT методологија (Structured Analysis and Design Technique - метод на структурна анализа и дизајн). Суштина. Основни одредби. Како е претставен функционалниот модел на активност во методологијата IDEF0? Што значат активностите во дијаграмите на функционалниот модел, како се прикажуваат според методологијата IDEF0? За што служат стрелките во дијаграмите на функционалните модели, кои се нивните типови и типови? DFD методологија. Суштина. Основни компоненти на DFD дијаграмите. Кои се карактеристиките на DFD дијаграмите и што е опишано во нив? Кои се карактеристиките на објектите на дијаграмот DFD? Што значат стрелките на дијаграмот DFD? IDEF3 методологија. Суштина. Алатки за документација и моделирање. Кои се карактеристиките на IDEF3 дијаграмите и што е опишано во нив? Кои се карактеристиките на објектите на дијаграмот IDEF3? А стрелецот? Класификација на процесите. Типични деловни процеси. Реинженеринг и неговата технологија. Кога е препорачливо да се користи реинженеринг при управување со компанија? Процеси на следење и мерење. Индикатори на организациски процеси. Нумерички и рејтинг проценки на процесите.

"Modeling business processes with AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Creating Information systems with AllFusion Modeling Suite" ед. "Dialog-MEPhI" 2003 "Практика на функционално моделирање со AllFusion Process Modeler 4.1. (BPwin) Каде? Зошто? Како?" ед. "Dialogue-MEPhI" 2004 Dubeykovsky моделирање со AllFusion Process Modeler (BPwin). ед. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Methodology of structural analysis and design SADT" 1993 класична работа за методологијата SADT. Cheremnykh анализа на системи: IDEF-технологии, Моделирање и анализа на системи. IDEF технологии. Работилница. М.: Финансии и статистика, 2001. „Структурни деловни модели: DFD технологии“ http://www. /Level4.asp? ItemId=5810 „Теорија и практика на реорганизација на деловните процеси“ 2003/ П50.1.. Методологија на функционално моделирање. М.: Госстандарт на Русија, 2000. http://www. IDEF0, IDEF3, DFD http://www. Моделирање на деловни процеси користејќи BPwin http://www. /department/se/devis/7/ IDEF0 во моделирање на процесите на управување со бизнисот http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

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

1. ИТ архитектура

2. Домени на процеси на управување.

3. Список на процеси во доменот Планирање и организација

4. Список на процеси на домен Стекнување и имплементација

5. Список на процеси во доменот Операција и одржување

6. Список на процеси во доменот на мониторинг и евалуација

7. Карактеристики на нивоата на моделот на процесна зрелост

9. KPI и KGI нивниот однос и цел

1. 10.Општи ИТ контроли и контроли на апликации. Области на одговорност и одговорности на бизнисот и ИТ.

Кобит 4.1 руско издание.

Правно регулирање на создавањето и користењето на интелектуалната сопственост

1. Наведете ги интелектуалните права на резултатите од интелектуалната активност и обелоденете ја нивната содржина.

2. Наведете ги видовите договори за располагање со ексклузивни права. Опишете го секој од овие договори за располагање со ексклузивни права.

4. Опишете ги главните одредби за правна заштита на компјутерска програма како предмет на авторско право.

5. Споредете ги главните одредби за правна заштита на Базата на податоци како објект на авторско право и како предмет на сродни права.

6. Опишете ги условите за патентност на предметите на патентните права: пронајдоци; корисни модели; индустриски дизајни.

7. Проширете ја содржината на критериумите за патентност за пронајдок: новина; инвентивен чекор; индустриска применливост.

8. Опишете ги условите и постапката за добивање на патент за пронајдок, корисен модел или индустриски дизајн, како и условите што ја обезбедуваат валидноста на патентите и нивните периоди на важност.

9. Дефинирајте „know-how“ и наведете ги условите при чие создавање се јавува и се спроведува правната заштита на производните тајни.

10. Наведете ги заштитените средства за индивидуализација и наведете ги нивните споредбени карактеристики.

1. Права на интелектуална сопственост во Руска Федерација, учебник // М, Проспект, 2007 г

2., Право за интелектуална сопственост, учебник // М, РИОР, 2009 г.

Управување со развој на проекти и софтвер [I]

Што е методологија, зошто е потребна. Општа структура на методологијата, главни елементи на методологијата. Принципи за дизајнирање на сопствена методологија. Примери на различни артефакти, улоги, компетенции, гранични услови. Структурата на методологијата според Cowburn, методологија метрика. Критериуми за дизајн на Cowburn. Критериуми за избор на методологија, Cowburn матрица. Животен циклус на проектот. Модели на водопад и итеративен животен циклус. Граници на применливост за водопади и итеративни модели. RUP како пример за итеративна методологија. Основни концепти на RUP, граници на применливост. Улогата на луѓето во развојот на софтвер. Агилни методологии, основни принципи на агилни методологии. Причината за појавата на флексибилни методологии. Scrum како пример за флексибилна методологија. Улоги, артефакти, активности во Scrum. Граници за применливост на Scrum. Екстремно програмирање (XP) Идеи, вредности, основни практики, граници на применливост. Сличности и разлики помеѓу Scrum и XP. Собирање и управување со барања. Основни практики, термини, принципи. Пристапи за документирање на проект и производ, главни видови документи. Примери на практики за управување со барања од методологиите дискутирани во курсот. Планирање на развој на софтвер. Видови планови, управување со ризик, популарни ризици. Примери на практики за развојно планирање од методологиите дискутирани во курсот. Тестирање во развој на софтвер. Концептот на склопување (изградба) на софтверски производ. Основни методи на тестирање, термини. Примери на практики за тестирање од методологиите дискутирани во курсот. Концептот на склопување (изградба), методи за складирање на код, алатки. Два принципи за организирање на работа со систем за контрола на верзии. Карактеристики на процесот на издавање/прикажување на производи за различни категории на производи, примери на практики. Современи концепти на софтверска архитектура, архитектури на повеќе нивоа, критериуми за архитектура. Список на неопходни одлуки при дизајнирање софтвер, пристапи за избор на систем за складирање податоци.

Кент Бек - Екстремно програмирање Фредерик Брукс - Митскиот месец на човекот или како се создаваат софтверските системи. Том ДеМарко - Краен рок. Роман за управување со проекти. Том Де Марко, Тимоти Листер - Валцирање со мечките. Том де Марко, Тимоти Листер - Човечки фактор_ успешни проекти и тимови. Алистер Кауберн - Секој проект има своја методологија. Alistair Cowburn - Луѓето како нелинеарни и најважни компоненти во креирањето софтвер. Андриј Орлов - Белешки на инженер за автоматизација. Професионална исповед. Филип Крачен - Вовед во рационален унифициран процес. Хенрик Книберг - Scrum и XP: белешки од првите редови. Презентации на предавања на курсот