Големина на текста:
09. Програмна Реализация
09.1. Планиране и
управление на ПР - Нужни
предпоставки за кодиране на
разработваната система: *По
отношение на интензивността и
производителността на процеса
на кодиране се въвежда се
плановост, определя се степен
на използване на техническата
и програмна база, разпределят
се финансовите разходи и т.н.
*Регламентира се взаимна
подчиненост на участниците в
производствения колектив, а
също се въвежда контрол и
отчетност при изпълнение на
производствените етапи и фази.
09.2. Производствен план -
компоненти: *Ясно и точно
формулирани цели на
производствения процес. – а те
зависят от поставените ни
изисквания към разработваната
програмна система.
*Стратегическо планиране на
производството. – избира се
технологичен подход и техноло-
гична последователност на
отделните фази. *Оценка и
планиране на необходимите
ресурси. – зависят от техни-
ческото задание, основните и
допълнителни изисквания към
програмната система, от
разработените спецификации,
от наличната технологична
база, както и от състава и
квалификацията на работния
колектив. *Състав и структура
на работния колектив. – трябва
да има изисквания за квалифи-
кацията, както и опит в предме-
тната област. *Планиране и
управление на производствения
процес. – то е с динамичен
характер и зависи от множество
трудно прогнозими фактори.
Разпространен подход е
мрежовия – има различни
видове дейности с етапи
разделени на фази и операции –
те са самостоятелни, имат
завършен вид и подлежат на
отчетност. дейностите се
свързват в производствени и
технологични вериги.
*Планиране на документацията.
- обхваща всички технологични
етапи на производство. Пълна
информация за изпълняваните
функции на системата, за
намаляване на грешките, за
внасяне на изменения,
предварителна подготовка на
потребителите. Описанието на
програмната част се оформя в
раздели както следва: увод,
предназначение, описание на
логиката, използвани техни-
чески средства, извикване и
зареждане, входна информация,
изходна информация. Могат да
се разработят и специализирани
ръководства.
09.3. Организация на
работния колектив – има три
варианта за разпределение на
производствените задачи: *
чрез специализирана група за
изпълнение на всеки отделен
етап - получават се проектни
решения и програмна реали-
зация с високо качество, * чрез
разпределение на програмните
модули по специализирани
групи за изпълнение – резул-
тата е високо качество на
отделните модули, * като
първото* на отделните
подсистеми - отделните
подсистеми са с високо
качество, но съгласуването им
води до излишни дублирания. #
При организирането на
работния колектив трябва: * да
се оценят изискванията
наложени от проектираната
програмна система, * Да се
определят функциите на всеки
изпълнител, * да се извърши
разпределение на програмните
модули. # Методите за контрол
и отчетност: метод на структур-
ния анализ, на структурния
преглед, на непосредствения
контрол. 09.4. Методика на
кодиране - разпределение на
паметта, Единен стил на наиме-
нуване, стандартизация на
оформлението.
10. Тестване на програмни
системи и модули.
Тестването е етап при който се
изпълняват планирани действия
за откриване и корегиране на
грешки. Има два подхода за
това: теоретично доказателство
и експериментална проверка.
10.1 Видове тестове – биват
статични и динамични. Статич-
ните се изпълняват чрез оглед
на програмния текст или на
резултатите от компилацията.
Динамичните са свързани с
реални опити над програмната
система – биват *детермини-
рани тестове (определени
входни данни – определен
очакван резултат), *вероят-
ностни тестове (случайни данни
за проверка за зацикляне),
*тестове в реално време,
*детерминилани тестове (биват
външни и структурни).
10.2. Грешките - при
статичните тестове могат да
бъдат най-различни: при
описание на променливите, при
обръщения към променливи,
при изчисления, при сравня-
ване, при управление, входно –
изходни грешки.
10.3. Технология на тестване
- * прави се стратегия на
тестване, определят се целите и
задачите на тестването, както и
последователността на тесто-
вете. После трябва да се напра-
ви анализ на данните, дали
тестовете са достатъчни и защо
са възникнали въпросни греш-
ки. Да се коригира грешката и
да се прецени нужни ли са още
тестове.
11. Външно тестване на
програмни модули.
При този вид тестване програм-
ните модули се разглеждат като
“черна кутия” – анализират се
само получените резултати.
11.1. Планиране на външни
тестове - обхваща: *Подготов-
ка на модула, *избор на метода
за тестване, *разработка на
критерий за достатъчност на
тестванията, *допълнителни
тестове, *подготовка на входни-
те данни и *формиране на
тестова последователност. #
Критерий за ефективност -
максималено много открити
грешки, минимум брой тестове,
минимално количество на
недопустимите данни.
11.2. Методи за тестване -
*Метод на еквивалентното
разделяне на входните данни:
Входните данни се представят
като множество от еквивалентни
класове. Трябва да определим
представителни данни от всеки
клас, а класовете се определят
няколко начина: чрез анализ се
входните условия и чрез разде-
ляне на данните на правилен
или неправилен клас. Избраните
данни от правилните класове са
от няколко множества, а при
неправилните класове всеки
клас трябва да се тества самос-
тоятелно. *Метод на гранични-
те значения: използва се при
програми с т.нар. “чувствител-
ни” зони - непроектирано пове-
дение в границите на определен
диапазон. Най-близката стой-
ност не предизвикваща прекъс-
ване се нарича гранична стой-
ност. Граничните значения се
определят по: *Наличието на
функции с разрив, *Определени
диапазони на изменение, *Вход-
ни данни с дискретни стойности,
*Форматно преобразуване.
*Метод на функционалните
диаграми - базира на причинно-
следствените връзки. Следстви-
ята могат да бъдат: тъждест-
вени(на входа {А}, на изхода
{В}) и нетъждествени(на входа
{А}, на изхода неможе {В}),
дизюнктивни(на входа допус-
тими данни, наизхода опреде-
лен резултат) и конюнктивни(на
входа данни от всички множест-
ва за да има резултат). Ограни-
ченията могат да са: включващи
(на входа данни поне от едно
множество) и изключващи(ако
на входа има две множества,
едното изключва другото),
единично включващо(от много
множества постъпват само едни
данни) и потвърждаващо
ограничение(множествата са
свързани). 11.3. Методика на
външното тестване – Отделя
се програмния модул, функци-
оналните му спецификации,
входните и изходни данни от
спецификациите, разделяне на
входните данни на правилни и
неправилни класове, установя-
ване на причинно-следствените
връзки, избор на метод, опреде-
ляне на тестови данни, създава-
не на тестова среда, корекция
на грешките и документиране на
резултатите.
12. Структурно тестване на
програмни модули – правят се
върху основата на програмния
текст. Чрез комбинации от вход-
ни данни през всички оператори
и цикли се следи изпълнението
на програмния модул. Има два
подхода за това: *Тестване без
нарушение на целостта(контрол
и следене на изменението на
променливите). *Тестване с
предварителни корекции(чрез
изменяне на програмния текст).
12.1. Планиране на структур-
ни тестове - три задачи:
*формират се цели - частичен
тест по оператори, по условия и
пълен тест. *критерий за създа-
ване на тестови маршрути(път
по който се изпълнява програм-
ния модул) – формализация
(управляващите оператори се
представят като върхове на
граф) и критерий(покриват се
всички върхове и дъги на графа
при минимално число на тесто-
вите маршрути, с минимално
число на линейно-независими
маршрути, с минимално число
маршрути предизвикващи всич-
ки възможни комбинации от
дъги). *стратегия за изпълнение
на тестовите последователности
(вътрешната структура на моду-
ла представлява база за плани-
ране на необходимите тестове.)
– стратегиите биват: за най-
важните компоненти на модула
(най-вероятните участъци, къ-
дето се формират условия за
управление), стратегии, основа-
ващи се на количеството прове-
рявани условия, стратегии на
най-вероятните маршрути в
програмния модул.
12.2. Методи за провеждане
на структурни тестове - *Чрез
предварителна подготовка на
програмния модул (отделянето
му от текста на програмната
система и анализиране на
програмния текст, формално
“заменяне” на управляващите
оператори с IF, съставяне на
управляващ граф на програмния
модул - всеки IF представлява
връх на граф, неговите THEN и
ELSE блокове – дъги.) Локален
метод за структурно тестване
– използва се за откриване на
грешки в определен участък на
програмния модул. Има няколко
етапа: първо определяне на
линеен участък от програмата,
определяне на променливите,
определят се входните и
междинните данни по методите
за външно тестване, следва
подготовка на участъка за
тестване. Метод на минимал-
ното покритие – представлява
минимално множество маршрути
покриващо изцяло управлява-
щия граф. Също има няколко
етапа: преобразуване на прог-
рамния текст в програма с IF
оператори. Съставя се управля-
ващ граф и матрицата на връз-
ките. В графа се определят
контурите. После се отстранява
дъга, която прави контура
линеен участък. Самата дъга
интерпретира минимален брой
оператори. Съставя се непълна
упакована матрица на връзките.
Определя се минимално множе-
ство от маршрути покриващи
управляващия граф, а за всеки
маршрут се определят входните
данни. Следва поетапно тества-
не на участъците. Метод на
пълния структурен тест
тестват се всички оператори,
условия и цикли чрез пълна
опакована матрица , включваща
и дъгите образуващи контури.
Етапите и са: провеждане на
тестове за минимално покритие
(за грешки предимно в линей-
ните участъци), формиране на
минимално множество от марш-
рути покриващи цикличните
участъци, а трябва и за всеки
цикъл да се определят стойнос-
ти на данните за многократно и
еднократно изпълнение. Трябва
да се провеждат планираните
тестове. 12.3. Методика на
структурното тестване
определят се целите на тества-
нето, прави се критерий на
тестване, преобразува се прог-
рамния текст, като се съставя
управляващ граф и матрица на
връзките, разработва се страте-
гия за тестване, избира се метод
за тестване, определят се тесто-
вите данни, създава се главна
тестваща програма, изпълняват
се после-дователно тестовете и
накрая се анализират резулта-
тите. Правят се корекции и нови
тестове за тяхната проверка.
13. Внедряване и съпровож-
дане на програмно осигуря-
ване - процес при който про-
дукта се предава на възложи-
теля на носител, извършва се
инсталиране на програмата,
генерира се необходимата мини-
мална база от данни, провеждат
се контролни и демострационни
изпитания и се оформя приемо-
предавателен протокол. Важна е
подготовката на потребителски-
те кадри, да се създаде подхо-
дяща организационна среда и
нужните предпоставки (техни-
чески и програмни). Има влияе-
щи на внедряването фактори:
субективни като подготовка,
информационна дисциплина и
контрол, и обективни като
грешки. 13.1. Организаци-
онни и технически предпос-
тавки – Тяхната цел: опреде-
ляне основните изисквания към
средата, възможност за инста-
лиране на програмата, за създа-
ване на информационната база,
някакво първоначално нейно
запълване с минимум от данни,
създаване на условия за откри-
ване и корекция на грешките, а
също и на условия за ефективен
процес на внедряване. Нужни
резултати за внедряването:
разработена програмна система,
инсталационна програма, техни-
ческа и експлоатационна доку-
ментация и дистрибутивен носи-
тел. Важна е организацията за
внедряване и експлоатация на
продукта. В това влизат догово-
реност за сроковете на внедря-
ване, планиране как точно да
стане внедряването, контрол на
експлоатацията и регистриране
и корекции на грешките. Техни-
ческите предпоставки: компю-
търна конфигурация, дистрибу-
тивен носител и документация
(техническа, програмна и екс-
плоатационна). Необходими са
ресурси за създаването на тези
организационни и технически
предпоставки. Те трябва да се
разпределят по подходящ начин
през целия процес. 13.2 Етапи
на внедряване - *Първоначал-
ното внедряване включва пред-
ставяне на програмата и на
техническата документация –
програмата се инсталира, създа-
ва се някаква база и се запълва.
*Изпитания – планират се нуж-
ните изпитания, провеждат се,
регистрират се грешките –
правят се нужните корекции по
програмата и документацията.
*Изследване – този процес
изисква точност на резултатите,
производителност на обработка-
та и ефективност на системата
(в два аспекта: икономическа –
приходи/разходи, и социална –
удобство за работа и др.)
13.3. Съпровождане – вид
продължение на внедряването.
Осигурява се възможност въз-
никналите грешки в процеса на
работа да бъдат отстранявани
без да се прекъсва работата.
Това става чрез откриване и
корекция на грешките, добавяне
и разширяване на някой функ-
ции с цел повишаване на
ефективността, и с времето -
модифициране и нови версии.
Препоръчва се предварително
разпределение на функциите
между специалиста и потреби-
теля, правене на защита на
системата и някакви критерий
за определяне нужда от нова
версия или модификации.
14. Оценка на програмно
осигуряване – програмата
притежава параметри по които
може да бъде сравнена с други
и така да бъде оценена. Някой
от потребителските параметри:
икономически и социален ефект
от внедряването, сложност и
удобство на потребителския
интерфейс, възвръщаемост на
вложените средства, цена и
срокове за внедряване, упра-
вление и експлоатация. Техни-
чески параметри: наличие и
настойка на инсталационна
програма, възможности за кон-
фигуриране според потребите-
ля, изисквания към компютъра,
ефективност при взаимодей-
ствие с други програми, възмож-
ност за създаване на версии,
експлоатационни разходи и др.
Параметри на производствения
процес: време за проектиране и
разработка, производителност,
оценка за надеждност и качест-
во на програмите, организация
на проектиране, разработка и
внедряване, икономическа рен-
табилност и ефективност на чо-
вешките ресурси. 14.2. Видове
оценки – три вида: *Предвари-
телна оценка – трябва да се оп-
редели себестойността на про-
грамата чрез оценка според
времето за проектиране и раз-
работка, нужния колектив, ква-
лификацията му, нивото на про-
изводителност и т.н. *Междинна
оценка – на няколко различни
технологични етапа: функцио-
нално, информационно и про-
грамно специфициране, програ-
миране, тестване и др. *Крайна
оценка – прави се след като е
готова програмата и се гледат
наднормените разходи на време
и средства, допуснатите откло-
нения и др. 14.3. Методика за
оценяване на програмни сис-
теми – Определя се целта и
предназначението на разработ-
ваните оценки, сферата им в за-
висимост от факторите и опре-
делените от тях параметри,
определят се местата за оценка,
прави се проучване за опреде-
ляне на факторите, които вияят
на оценките. Разработва се
скала за измерване на парамет-
рите, теоретично обоснована
връзка между фактори и стой-
ности на параметри, и накрая се
правят експериментални изсле-
двания. 14.4. Методи и моде-
ли за оценка - моделът е ана-
литичен запис на група пара-
метри обединени в единна фор-
мула. Видове модели: *алгори-
тмични модели - линеен модел
(основава се на линейна зави-
симост между параметрите),
мултиприкативен (Всички пара-
метри участвуват с ненулев
коефициент), аналитичен (пара-
метрите са свързани по анали-
тичен начин), табличен (оцен-
ката се извършва по таблици) и
комбиниран (участвуват система
от формули и таблици). *екс-
пертни модели - състои се в
анализиране становищата на
отделните експерти, но същест-
вува невъзможност за контрол
над качеството на оценяване и
достовереността на оценките.
*модел на аналогията – изра-
ботва се оценка на основата от
данни на други вече разрабо-
тени подобни проекти. По този
начин се отчита опита от тях и
степента на надеждност е висо-
ка. *модел на паркенсон –
екстремална оценка при макс.
производителност на колектива
и макс. възможности на прогр.
среда. Удобно е за оценка до
каква степен са използвани
предоставените възможности.
*модел „отгоре – надолу” -
поетапно оценяване. Първо на
цялата програма, после на
отделните и компоненти и т.н.
*модел „отдолу - нагоре” –
обратното на миналото.
15. Сложност на програмно
осигуряване – това е показа-
тел за оценка на програмата,
има количествен характер, но
могат да се използват и качест-
вени показатели за сложност.
Сложността от своя страна е
коплексна оценка, обхващаща
конструктивните, експлоатаци-
онни и производствени характе-
ристики на програмата. Оценка-
та за сложност позволява да се
сравняват и съпоставят различ-
ни програми, както и възмож-
ност за изследване на сложност-
та. Има фактори, които и оказ-
ват влияние – общи (слож-ност
на реалната система, на техни-
ческото задание, на информа-
ционната база) и спе-циални
(технологичен подход, методи
за проектиране, основни харак-
теристики). 15.2. Видове
сложност - *Функционална –
отчита се сложността на изпъл-
няваните функции и решавани
задачи. *Информационна -
данни, структури, движение,
обработка. *Програмна - на
програмната архитектура и на
методите за проектиране. *Екс-
плоатационна - за сложността
на потребителския интерфейс,
управление и др. 15.3. Статич-
на и динамична сложност
Статичната - включва
показатели, които не се вляят от
условията и режимите на рабо-
та: Количество на командите, на
глобалните и локални промен-
ливи, обем на информационната
база, на необходимата памет,
производствени разходи. Дина-
мична – с показатели отчитащи
променящи се стойности: експе-
риментална (измерва при реал-
ни условия), изчислителна (от-
читаща обема и продължител-
ността на изчислителните про-
цеси) и аналитична сложност
(теоретично изведена оценка за
необходимите операции). 15.4.
Сложност на програмни мо-
дули – Статична - Брой и обем
на променливите и константите,
както и обем за разполагане на
данни. Информационна – отно-
шение на количеството данни в
междумодулния интерфейс към
кол. на локалните данни, кол.
на командите в модула към пре-
поръчителното кол. Общото кол.
на данните към броя на коман-
дите. Структурна - на базата на
управляващия граф на модула.
Аналитична оценка на динамич-
ната сложност - посредством
експертно определяне на макси-
мално необходимите операции
за изпълнение на модула.
Експериментална оценка на
динамичната сложност – за
определяне на зависимост
между входните данни и изчис-
лителното време.
16. Качество на програмното
осигуряване - представлява
интегрирана оценка, включваща
функционални, информационни,
програмни и експлоатационни
показатели, оценки за слож-
ност, производствени разходи и
др. 16.1. Основни задачи при
оценка на качеството – да се
определят факторите, показа-
телите и критерийте за оценка.
Също така и методите за коли-
чествена оценка на показате-
лите, както и функционален
модел за оценка и изследване
на качеството. Качеството се
оценява в три аспекта: Оценка
на концептуалния проект (слож-
ност, система, управление, ре-
жими и настойка), на потреби-
телския интерфейс (удобство,
надежност и производителност,
обучение), и на на конструкти-
вните и експлоатационни пара-
метри (изисквания, експлоата-
ционни разходи, качество).
16.2. Критерий – Функционал-
ни критерий за качество – това
са общата функционална архи-
тектура, номенклатура и състав
на функциите, оценка на функ-
циите за защита, също и възмо-
жност за модифициране и раз-
витие. Интерфейсни критерии за
качество – Апаратни, клавиа-
тура (обем и начини за въвеж-
дане, управление на курсора),
други средства (мишка, джой-
стик и др), сенсорни екрани,
устройства за въвеждане и
извеждане на графична инфор-
мация, датчици и др. Общосис-
темни програмни критерии -
движение и избор на курсор,
звук при избор, формиране и
използване на сенсорни точки и
фигури, на система от екрани,
меню-техника и др. Специални
програмни критерий - екранни
полета за въвеждане и извеж-
дане, функционална близост и
зависимост на даннови полета и
пояснителна информация, логи-
ческа последователност на
въвеждане и извеждане и др.
Общи критерий - сложност на
програмата по модули, подсис-
теми и като цяло, оценка на
надеждността, коректност на
програмите и мобилност на
проекта. Специални критерии -
точност на представяне и прео-
бразуване на входните данни,
допустим диапазон на изме-
нение, състав и обем на крайни-
те резултати, възможност за
следене и контрол.
07. Иинформационни специ-
фикации - Информационната
среда включва: источници и
приемници на информация,
видове и типове данни, групи-
рането им, информационни
маршрути и потоци. 07.1. Жиз-
нен цикъл - *Формират се
целите (създаване на инфор-
мационна база , осигуряваща
изискванията на програмната
система). *Изяснение на инфор-
мационните потребности (групи-
рат се по описание на инфор-
мационната база на реалната
система, както и по описание на
информационното осигуряване).
*Разработват се информационни
структури (специфицирани
данни и информационни, алго-
ритмични, физически и програ-
мни връзки между тях). *Прави
се анализ на информационните
структури - неформален анализ
(експертна проверка, източници
на информация, непълна класи-
фикация на типовете данни и
прекъснати информационни
маршрути), анализ за структур-
на коректност (изолирани вър-
хове, прекъснати пътища и
наличие на контури), функцио-
нална пълнота (достатъчност на
данните, без недостиг или изли-
шък), статични и динамични па-
раметри (конструктивни параме-
три, интезитет и честота, конту-
ри и др). *Синтез на информа-
ционни структури - вериги от
данни (оптимални по дължина,
брой, честота и период), Ключо-
ви думи (по честота на актив-
ност, по входно – изходна
активност, по начало на често
използвани вериги), оптимални
схеми (минимално дублиране на
данните и рационално физичес-
ко разпределение), оптимални
структури от данни (мин. разход
на памет за указатели, структу-
ра с макс. на изпълняваните
функции, мин. време за достъп
и търсене с макс. производител-
ност при обработка), система от
файлове (при ограничение на
отворените файлове и без огра-
ничение на файловете), опти-
мални файлове (мин. и макс.
вътрешна свързаност на
данните, специални решения),
оптимални записи (с еднотипни
записи, структурирани записи и
с различни по състав и структу-
ра записи). 07.2. Класифика-
ция - Информационните специ-
фикации са функционално и
програмно ориентирани. Някой
от тях непрекъснато присъстват
в системата, докато други са
преходни. Функционално ориен-
тираните спецификации биват:
на данните (обозначение, тип,
дължина, точност на предста-
вяне), на операциите (обединя-
ване, сливане, селекция, струк-
туриране), на движението
(описание на маршрути и др).
Програмно ориентираните
спецификации биват: на про-
грамните данни (програмно
представени данни, свързани с
обработка на информацията и
др), на интерфейсните данни
(източник, приемник, информа-
ционен канал и др), на физичес-
ките данни (данни свързани с
разпределението по нивата на
паметта и др). Междинните
спецификации биват: описание
на данни свързани с първона-
чалното инсталиране на програ-
мната система и създаване на
базата от данни, за настройкта
на системата и за управление на
режимите на работа. Техника
на информационното специ-
фициране - три етапа: подго-
товка за проучване на информа-
ционните потребности, форми-
ране на представа и регистри-
ране на информационното
съдържание, и документиране
на получените резултати.
*Подготвителният етап – Проуч-
ване на функционалните специ-
фикации и структури, подготов-
ка на специалистите за съвмест-
ната им работа и накрая доку-
ментиране на резултатите.
*Етап на формиране и регис-
триране - проучване на подобни
програми, проучване на съпът-
ствуваща докумен-тация, регис-
триране и докумен-тиране на
резултатите. *Доку-ментиране -
обща и специална част.
08. Програмни специфи-
кации - Разработката на ПС е
последния етап от описанието
на проектните решения. Отчитат
се редица фактори, като компю-
търната и програмна среда за
развитие. Основната цел на ПС
е описание и проект на про-
грама, по предварително разра-
ботени функционални специфи-
кации. За целта са необходими
няколко неща: Разработка на
технологична и обща структурна
схеми. Също и алгоритмизация
на проектните решения за вида
и състава на изпълняваните
функции, както и проектни
решения за използване ресур-
сите на наличните библиотеки и
системи за управление на бази
от данни. 08.1. Технологична
схема на обработка – разра-
ботва се на базата на проект-
ните решения за функционал-
ната структура на реалната сис-
тема. Схемата определя основ-
ните режими на работа и обра-
ботката на данните.
08.2. Алгоритмизация на
проектните решения -
Алгоритмични (програмни) конс-
трукции: Линейна конструкция
(преместване и преобразуване
на информация). Различими и
неразличими редове. Разклоне -
на конструкция (условие: два,
три и повече възможни отго-
вора, IF, Case, Do Case, Select
Case и др.) Циклична конструк -
ция (с пред условие, с пост
условие, изброими от ... до, за
всеки от......) Конструкция
преход (с връщане /запомняне
на адреса/, без връщане). 08.3.
Анализ на програмните
спецификации - Неформален
анализ – включва експертна
проверка на документацията,
неопределени модули по вход и
изход, некласифицирани моду-
ли. Анализ за структурна корек -
тност - изолирани върхове и
подграфи, прекъснати пътища,
неправилно вложени цикли и
структури, наличие на контури.
04. Управление на техноло-
гичния проект - Разработка на
програмната: етапи - *разработ-
ка на форми и обекти, свързани
с потребителския интерфейс,
*кодиране на модули и проце-
дури, *определяне и поддържа-
не на променливи и константи,
*постъпкова компилация и
корекция на грешките. Тестване
на програмата: цели, критерий
и методи за тестване, формали-
зация и верификация (ръчно и
автоматично тестване), тестови
последователности (локализа-
ция и корекция), оценка за
достатъчност (статични и дина-
мични парам). Внедряване:
предпоставки: технически,
организационни и програмни,
документация и обучение на
потребителите (ръководства на
Администратора и на Потреби-
теля), Инсталация генериране
експериментиране и внедряване
(при грешки - намиране и коре-
кция). Съпровождане: експлоа-
тация на програмната система
(при грешки - намиране и коре-
кция), модификации или нови
версии (ново техническо зада-
ние).

Това е само предварителен преглед

За да разгледате всички страници от този документ натиснете тук.
Последно свалили материала:
ДАТА ИНФОРМАЦИЯ ЗА ПОТРЕБИТЕЛЯ
14 фев 2016 в 15:27 студент на 47 години от Габрово - ТУ - Габрово, факулетет - Стопанско, специалност - Икономика на търговията, випуск 2017
01 дек 2014 в 12:17 студентка на 28 години от Варна - Икономически университет, факулетет - Стопански факултет, специалност - Икономика и управление на търговията, випуск 2015
11 фев 2014 в 08:10 студентка на 44 години от София - СУ "Св. Климент Охридски", факулетет - Факултет за начална и предучилищна педагогика, випуск 2011
05 окт 2012 в 06:17 ученик
31 май 2012 в 10:05 студент на 28 години от Варна - ВИНС, факулетет - информатика, специалност - Информатика, випуск 2012
13 мар 2012 в 19:23 студентка на 47 години от Русе - Русенски университет "Ангел Кънчев", факулетет - Факултет бизнес и мениджмънт, специалност - бизнес и мениджмънт, випуск 2017
23 яну 2012 в 16:07 студентка на 31 години от Варна - Икономически университет, факулетет - Стопански факултет, специалност - Аграрна икономика, випуск 2012
26 ное 2011 в 22:34 в момента не учи
29 май 2011 в 20:30 студентка
04 фев 2011 в 19:15 студентка на 33 години от Габрово - Технически университет
 
Домашни по темата на материала
Ред за изпълнение на заданието
добавена от the-honey.cat 12.01.2017
1
5
Ред за изпълнение на заданието
добавена от the-honey.cat 12.01.2017
2
4
 
Онлайн тестове по Планиране и прогнозиране
Тест по Фирмено планиране за студенти от 3-ти курс
изпитен тест по Планиране и прогнозиране за Студенти от 3 курс
Тестът се състои общо от 45 въпроса: първите 25 от тях са с подточки с по един верен отговор, а вторите 20 са тип твърдения с отговор ДА или НЕ като само едно от двете е вярно. Предназначен е за студенти изучаващи фирменото планиране.
(Труден)
45
6
1
21 мин
25.10.2016
Бизнес планиране - тест 1
изпитен тест по Планиране и прогнозиране за Студенти от 4 курс
Тестът съдържа 10 затворени въпроса, всеки от които изисква един или повече верни отговора.
(Труден)
10
39
1
1 мин
23.05.2015
» виж всички онлайн тестове по планиране и прогнозиране

Пищови ст-02

Материал № 344029, от 24 май 2009
Свален: 33 пъти
Прегледан: 36 пъти
Качен от:
Предмет: Планиране и прогнозиране , Икономика
Тип: Анализ
Брой страници: 2
Брой думи: 2,408
Брой символи: 20,709

Потърси помощ за своята домашна:

Имаш домашна за "Пищови ст-02"?
Намери бързо решение, с помощтта на потребители на Pomagalo.com:

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