77yVjY4P

1__________________________________________________________________________________________________________________
2Софтвер
3(дефиниција, карактеристики, видови)
4Y2K
5Y2K bug
6Year 2000 bug or Millennium Bug
72
8Софтвер
9ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
10И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
11СОФТВЕРСКО ИНЖЕНЕРСТВО
12Софтвер
13 Значење на софтверот
14 Софтвер –дефиниција (?!)
15 Природа на софтверот
16 Карактеристики на софтверот како
17продукт
183
19Софтвер
20ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
21И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
22СОФТВЕРСКО ИНЖЕНЕРСТВО
23Значењето на софтверот денес
24 Можете ли да го замислите светот денес без
25софтвер?
26 Софтверот е насекаде (мобилни телефони, лифтови,
27автомобили, вселенски летала, нуклеарни
28електрани, ...)
29 Улогата на софтверот во економијата на САД:
30Софтвер
314
32Total Real Value Added by the Software and Related Services
33(in billions)
34ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
35И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
36СОФТВЕРСКО ИНЖЕНЕРСТВО
37Софтверска индустрија
38 Од 1997 до 2012 софтверската индустрија во С.А.Д.
39пораснала од 149 милијарди USD на 425 милијарди
40USD, односно нејзиниот удел во GDP од 1.7% на
412.6%
42 Бројот на директно вработени во софтверската
43индустрија во С.А.Д. пораснал од 778.000 работни
44места во 1990 на над 2.500.000 во 2014 или од 0.9%
45на 2.2% од сите вработени.
46 Се смета дека софтверската индустрија во С.А.Д.
47поддржува уште над милион работни места кои ја
48сервисираат
49Софтвер
505
51The software market is large and
52highly globalized…
53Robert J. Shapiro, The U.S. Software Industry: An Engine for Economic Growth and Employment, 2014, www.siia.net
54ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
55И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
56СОФТВЕРСКО ИНЖЕНЕРСТВО
57Неуспешен развој на софтвер
58 Според истражување на IBM (1994):
5955% од системите чинеле повеќе од
60предвиденото
6168% го пробиле рокот за испорака
6288% морало да бидат сериозно
63редизајнирани
64Софтвер
656
66ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
67И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
68СОФТВЕРСКО ИНЖЕНЕРСТВО
69Економски ефект на грешките во
70софтверот
71 Софтверот е подложен на грешки пред сè поради
72неговата комплексност.
73 Новите софтверски апликации веќе не се мерат во
74илјади туку во милиони линии на код.
75 Околу 80% од цената за развој на софтвер се троши
76за да се идентификуваат и коригираат дефектите
77 Сепак и понатаму исклучително мал број на продукти
78се испорачува со толку високо ниво на дефекти како
79софтверот
80 Зголемената комплексност на софтверот како и
81намалениот очекуван животен век на софтверските
82продукти ја зголемува економската цена на грешките
83Софтвер
847
85ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
86И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
87СОФТВЕРСКО ИНЖЕНЕРСТВО
88Загуби поради софтвер
89 Проценката е дека софтверските грешки ја чинат
90економијата на С.А.Д. 59,5 милијарди долари
91годишно или околу 0.6% од GDP*.
92 Половина од оваа штета ја трпат корисниците на
93софтвер, половина развивчите.
94 Околу 1/3 од овие грешки можеле да бидат
95отстранети доколку било имплементирано подобро
96тестирање.
97 Моментално, преку половина од грешките се наоѓаат
98дури по испораката на софтверот (или неговата
99пробна работа во реална средина)
100*) http://www.nist.gov/public_affairs/releases/n02-10.htm
101Софтвер
1028
103ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
104И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
105СОФТВЕРСКО ИНЖЕНЕРСТВО
106НЕСРЕЌИ
107 Најголем број на експерти се согласува
108дека најверојатниот начин светот
109(животот на нашата планета или
110цивилизацијата каква што ја познаваме)
111да биде уништен е при случајна несреќа
112(by accident).
113Софтвер
1149
115ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
116И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
117СОФТВЕРСКО ИНЖЕНЕРСТВО
118Тука настапуваме ние – компјутерските
119професионалци!
120* Nathaniel Borenstein, inventor of MIME, in: Programming as if People Mattered:
121Friendly Programs, Software Engineering and Other Noble Delusions, Princeton University Press, Princeton, NJ, 1991.
122НИЕ ГИ ПРЕДИЗВИКУВАМЕ
123СЛУЧАЈНИТЕ НЕСРЕЌИ!
124Софтвер
12510
126ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
127И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
128СОФТВЕРСКО ИНЖЕНЕРСТВО
129Кобни софтверски грешки
130 Машина за радиотерапија со софтверски контролер
131кој преозрачил неколку пациенти, некои од нив
132починале
133http://sunnyday.mit.edu/therac-25.html
134 Panama 22 May, 2001: 28 пациенти преозрачени; 8
135починале; 3/4 од преостанатите 20 се очекува да
136имаат сериозни компликации кои во некои случаи
137можат да бидат и фатални
138http://www.fda.gov/cdrh/ocd/panamaradexp.html
139 Ariane-5 ESA, 1996: Комплетна загуба на ракетата и
140корисниот товар (за среќа нема жртви) поради
141грешка во исклучок фрлен од ADA код кој и не бил
142потребен по полетувањето
143http://www.esa.int/htdocs/tidc/Press/Press96/ariane5rep.html
144http://www.ima.umn.edu/~arnold/disasters/ariane.html
145Софтвер
14611
147https://www.youtube.com/watch?v=EMVBLg2MrLs
148http://www.cse.psu.edu/~gxt29/bug/softwarebug.html
149ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
150И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
151СОФТВЕРСКО ИНЖЕНЕРСТВО
152MIM-104 Patriot SAM
153 На 25 февруари 1991 година,
154Ирачка ракета SCUD убива 28
155американски војници во Dharan и
156покрај заштитата од најмодерните
157Patriot батерии. Истрагата открила дека
158ова се случило поради софтверска
159грешка во системот за наведување на
160MIM-104 Patriot SAM ракетите поради
161отстапување на софтверскиот часовник
162на системот кој без прекин работел
163преку 100 часа од само 1/3 секунда што
164резултирало во грешка од 600 метри.
165http://en.wikipedia.org/wiki/Patriot_missile
166Софтвер
16712
168ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
169И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
170СОФТВЕРСКО ИНЖЕНЕРСТВО
171Квалитет на софтвер
172 Една мерка: bugs/kloc
173 може да се измери дури по испораката/интеграцијата
174 просекот во индустријата е околу 10
175 висок квалитет – 0.1 или помалку
176 Стандардната „гаранција“ при испорака на софтвер е
177безмалку никаква.
178 Единствено софтверот за специјални системи
179(контрола на авио-сообраќај, контрола на нуклеарни
180централи и сл.) е ригорозно „развиван“ за да се
181обезбеди одреден квалитет кој доаѓа и со одредена
182гаранција.
183kloc – KiloLinesOfCode илјада линии изворен код
184Софтвер
18513
186ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
187И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
188СОФТВЕРСКО ИНЖЕНЕРСТВО
189“Standard” software disclaimer (1)
190 [This] Software is provided 'as is' without warranty of
191any kind, either express or implied, including, but not
192limited to, the implied warranties of fitness for a
193purpose, or the warranty of non-infringement. Without
194limiting the foregoing, the [Firm] makes no warranty
195that:
196 the software will meet your requirements
197 the software will be uninterrupted, timely, secure or
198error-free
199 the results that may be obtained from the use of the
200software will be effective, accurate or reliable
201 the quality of the software will meet your expectations
202 any errors in the software obtained from the [Firm] will
203be corrected.
204Софтвер
20514
206ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
207И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
208СОФТВЕРСКО ИНЖЕНЕРСТВО
209Standard software disclaimer (2)
210 In no event shall the [Firm] be liable to you or any third
211parties for any special, punitive, incidental, indirect or
212consequential damages of any kind, or any damages
213whatsoever, including, without limitation, those resulting
214from loss of use, data or profits, whether or not the [Firm]
215has been advised of the possibility of such damages,
216and on any theory of liability, arising out of or in
217connection with the use of this software.
218 The use of this software is done at your own discretion
219and risk and with agreement that you will be solely
220responsible for any damage to your computer system or
221loss of data that results from such activities. No advice or
222information, whether oral or written, obtained by you
223from the [Firm] or from the [Firm] web site shall create
224any warranty for the software.
225Софтвер
22615
227ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
228И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
229СОФТВЕРСКО ИНЖЕНЕРСТВО
230Што е потребно за да се подобри
231квалитетот на софтверот?
232 “You know what’s needed before we get good
233software? Cars in this country got better when
234Japan showed us that cars could be built better.
235Someone will have to show the industry that
236software can be built better.”
237John Murray, FDA’s software quality guru
238quoted in Software Conspiracy, Mark Minasi,
239McGraw Hill, 2000
240ТОА СТЕ ВИЕ!
241Софтвер
24216
243ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
244И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
245СОФТВЕРСКО ИНЖЕНЕРСТВО
246Неколку корисни совети
247 Треба да научите не само како да
248пишувате добар код, туку како да
249правите добар софтвер што е поважно.
250 Софтвер кој ќе биде:
251помалку гломазен
252подиректен
253помалку врзан за технологијата која набргу
254ќе застари
255Софтвер
25619
257ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
258И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
259СОФТВЕРСКО ИНЖЕНЕРСТВО
260Неколку корисни совети
261 Не штедете време во размислување
262 Не брзајте да кодирате
263 Дизајнирањето е поинтересно од дебагирањето
264“I gave desperate warnings against the obscurity, the
265complexity, and over-ambition of the new design, but my
266warnings went unheeded. I conclude that there are two
267ways of constructing a software design: One way is to
268make it so simple there are obviously no deficiencies
269and the other way is to make it so complicated that there
270are no obvious deficiencies.”
271Tony Hoare, Turing Award Lecture,
2721980 talking about the design of Ada
273Софтвер
27420
275ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
276И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
277СОФТВЕРСКО ИНЖЕНЕРСТВО
278Keep it simple!
279 Обидувајте се секогаш да го избирате
280наједноставниот дизајн кој ја врши
281работата.
282 Не компликувајте без потреба
283 Запомнете дека секогаш е можно
284релативно едноставно нешто од
285едноставно да се направи
286компликувано, но ѓаволски тешко е да
287се направи нешто навистина
288едноставно.
289Софтвер
29021
291ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
292И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
293СОФТВЕРСКО ИНЖЕНЕРСТВО
294За што ќе зборуваме...
295 Што е тоа компјутерски софтвер?
296 Зошто се трудиме да направиме
297високо-квалитетни компјутерски
298системи?
299 Како може да се категоризира
300софтверот според доменот на
301апликација?
302 Што означува „софтверски процес“?
303Софтвер
30422
305ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
306И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
307СОФТВЕРСКО ИНЖЕНЕРСТВО
308Софтвер - дефиниција
309Софтверот се:
3101) инструкции (компјутерска програма) кои кога
311се извршуваат ги обезбедуваат
312посакуваните особини, функции и
313перформанси;
3142) податочни структури кои овозможуваат
315програмите адекватно да ги манипулираат
316информациите;
3173) описни информации, како копија на хартија
318или виртуелна форма кои го опишуваат
319работењето и употребата на програмите.
32023
321Софтвер
322ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
323И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
324СОФТВЕРСКО ИНЖЕНЕРСТВО
325Софтвер
326 Што е тоа? – Продуктот кој го
327дизајнираат и градат софтверските
328инженери
329 Од нивен аспект -програми,
330документација, податоци
331 Од аспект на крајниот корисник –
332излезната информација (ефектот) на
333софтверот која го прави нивниот свет
334подобар
335Софтвер
33624
337ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
338И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
339СОФТВЕРСКО ИНЖЕНЕРСТВО
340Различни аспекти кон софтверот
341 Од аспект на софтверските инженери
342софтверот е составен од програми,
343документи и податоци потребни за да
344се развие софтверскиот систем
345 Од аспект на корисникот софтверот е
346само продукт кој ги задоволува или не
347ги задоволува нивните барања и им ја
348олеснува работата
349Софтвер
35025
351ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
352И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
353СОФТВЕРСКО ИНЖЕНЕРСТВО
354Двојна природа на софтверот
355 Софтверот е истовремено и краен продукт и
356основно средство за „производство“ и
357испорака на крајниот продукт.
358 Овозможува искористување на
359пресметковниот и меморискиот потенцијал на
360компјутерскиот хардвер
361 Ја овозможува основата на контролата на
362компјутерот (ОС), мрежата и овозможува
363креирање и контрола на други програми
364Софтвер
36526
366ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
367И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
368СОФТВЕРСКО ИНЖЕНЕРСТВО
369Информациско општество
370 Земјоделско општество
371 поголемиот дел од населението се занимава со
372обработка на земја и производство на храна
373 Индустриско општество
374 поголемиот дел од населението се занимава со
375производство на материјални добра
376 Информациско општество
377 поголемиот дел од населението се занимава со
378давање услуги – манипулација на информации
379Софтвер
38027
381ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
382И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
383СОФТВЕРСКО ИНЖЕНЕРСТВО
384Трансформатор на информации
385 Софтверот врши трансформација на
386информација
387 креирање
388 менаџирање
389 прибирање
390 промена
391 прикажување
392 пренос
393на информации
394 Софтверот го испорачува највредното нешто
395во денешно време
396ИНФОРМАЦИЈА
397Софтвер
39828
399ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
400И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
401СОФТВЕРСКО ИНЖЕНЕРСТВО
402Карактеристики на софтверот
403Софтверот е логички а не физички систем!
4041. Софтверот не се произведува, тој се развива
405 квалитетот се постига преку добар дизајн (но нема
406производство на ништо материјално)
407 активностите зависат од луѓе но релациите помеѓу луѓето се
408различни
409 трошоците се концентрирани во инженерството
4102. Софтверот не се троши (абе), но се „расипува“ (се
411збајатува, се влошува)  (сл.1, сл.2)
4123. И покрај сé помасовната употреба на „готов“
413софтвер како и сé поголемото свртувањето кон
414развој на компонентно базирани системи, сé уште
415најголем дел од софтверот се развива по
416нарачка
417Софтвер
41829
419ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
420И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
421СОФТВЕРСКО ИНЖЕНЕРСТВО
422Рата на дефекти за хардвер
423“Infant “Wear out”
424mortality”
425Time
426F
427ailure rat
428e
429Софтвер
43030
431ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
432И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
433СОФТВЕРСКО ИНЖЕНЕРСТВО
434Рата на дефекти за софтвер
435Increased failure
436rate due to side
437effects
438Time
439F
440ailure ra
441t
442e
443Change
444Actual curve
445Idealized curve
446Софтвер
44731
448ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
449И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
450СОФТВЕРСКО ИНЖЕНЕРСТВО
451Карактеристики на софтверот
452 Софтверот се јавува и како финален продукт и како
453алатка за развој на други продукти.
454 Софтверот се развива, тој не се произведува
455 Софтверот не се троши (абе), но застарува
456 Најголемиот дел од софтверот се прави по нарачка
457 Софтверот може да биде екстремно комплексен па
458поради тоа и тежок за разбирање и следење што
459остава многу голем простор за човечки грешки.
460 Развојот на комплексен софтвер кој ќе биде без
461грешки (или барем тие ќе бидат сведени на
462прифатливо ниско ниво) е неизводливо доколку на
463целиот процес не се пристапи на правилен и
464организиран начин.
465Софтвер
46632
467ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
468И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
469СОФТВЕРСКО ИНЖЕНЕРСТВО
470Софтвер - домени на примена
471 Системски софтвер
472 (компајлери, едитори) обработува комплексни но одредени
473информациски структури
474 (оперативни системи, драјвери) обработува претежно неодредени
475информации
476 Во обата случаја се карактеризира со висока
477инеракција/зависност од хардверот, повеќе корисници,
478паралелни операции и распоредување, споделување на
479ресурси, комплексни податочни структури, надворешни
480интерфејси
481 Real-time software
482 надгледува процеси и појави од реалниот свет: се појавуваат – треба да бидат
483обработени во реално време. Треба да дава одредени гаранции за
484времетраењето на обработките.
485 Апликативен софтвер
486 индивидуални програми кои решаваат одредени бизнис потреби
487(инвентари, платни списоци, сметководство, ...)
488Софтвер
48933
490ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
491И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
492СОФТВЕРСКО ИНЖЕНЕРСТВО
493Софтвер - домени на примена
494 Инженерски и научен софтвер
495 CAM, CAD, симулации, комплексни нумерички пресметки, ...
496 Вградлив (embedded) софтвер
497 вграден во продукти или системи со цел да обезбеди контролна
498функција за системот и/или крајниот корисник
499 мобилни телефони, MP3 players, routers, микробранови печки,
500автомобили
501 Софтвер за PC - масовен софтвер (Product-line)
502 дизајниран да обезбеди одредени специфични функционалности за
503различни корисници; фокусиран на
504 специфичен пазар (магацинско работење)
505 масовен пазар (word processing, spreadsheets, computer graphics,
506multimedia, entertainment)
507 Web и мобилни апликации
508 веб апликации на кои им се пристапува преку прегледувач (browser)
509 апликации кои се поставени на мобилни уреди
510 Софтвер за вештачка интелигенција
511 роботика, експертни системи, препознавање на облици (слика,
512говор) ...
513Софтвер
51434
515ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
516И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
517СОФТВЕРСКО ИНЖЕНЕРСТВО
518Legacy software
519 Стар „наследен“ софтвер (10+ години)
520 понекогаш од одредени причини засегнатите сакаат да го
521одржат во функција
522 долготраен, менуван и дополнуван
523 на него се потпираат некои од основните бизнис функции во
524одредена организација - и критичен за бизнисот - затоа е
525„незаменлив“
526 За жал, кај ваквите системи често се среќава и:
527 слаб квалитет
528 нефлексибилен дизајн
529 неразбирлив код
530 слаба или никаква документација
531 слабо одржувана историја на измени
53235
533Софтвер
534ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
535И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
536СОФТВЕРСКО ИНЖЕНЕРСТВО
537Прашања...
538... кои ги мачат софтверските инженери
539 Зошто е потребно толку многу време за да се
540заврши софтверот?
541 Зошто развојот е толку скап?
542 Зошто не можеме да ги пронајдеме сите
543грешки пред да го испорачаме софтверот?
544 Зошто губиме толку многу време на
545одржување на постоечки системи?
546 Зошто следењето на прогресот при развојот
547на софтвер е се уште тешко?
54836
549Софтвер
550ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
551И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
552СОФТВЕРСКО ИНЖЕНЕРСТВО
553Нови предизвици во развојот
554на софтвер
555 Open-world computing
556 networking, pervasive, distributed computing
557 Netsourcing
558 World Wide Web is rapidly becoming a computing
559engine as well as a content provider
560 Open source
561 distribution of source code for systems applications
562so that many people can contribute to its
563development
564Софтвер
56537
566ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
567И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
568СОФТВЕРСКО ИНЖЕНЕРСТВО
569Трендови
570 Web апликации и сервиси
571 Мобилни апликации
572 Cloud computing
573 Product line software
57438
575Софтвер
576ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
577И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
578СОФТВЕРСКО ИНЖЕНЕРСТВО
579WEB апликации
580 мрежно интензивни
581 конкурентност
582 непредвидливо оптоварување
583 перформанси
584 достапност
585 податочно водени
586 зависни од содржината
587 постојана еволуција
588 итност
589 сигурност
590 естетика
59139
592Софтвер
593ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
594И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
595СОФТВЕРСКО ИНЖЕНЕРСТВО
596Структура на продажната цена на софтверот
597 Вообичаено се дели на три дела:
5981. up-front fee - се наплаќа на почетокот како
599лиценца (право) на користење на
600софтверот
6012. maintenance – се наплаќа годишно за
602одржување (15-25% од 1.) – patches,
603upgrades, …
6043. инсталација, интеграција, обука, ..
605Софтвер
60640
607ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
608И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
609СОФТВЕРСКО ИНЖЕНЕРСТВО
610Трендови
611 1990 – околу 70% од приходите на
612јавните софтверски компании во САД
613биле од up-front fee
614 2000 – околу 50% од приходите се од
615up-front fee
616 Не се ретки компаниите кај кои овој
617процент е само 30%
618 Може да биде и 0% !!!
619Софтвер
62041
621ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
622И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
623СОФТВЕРСКО ИНЖЕНЕРСТВО
624Модели на лиценцирање
625 free OpenSource софтвер upfront=0
626 subscription license – се купува правото на користење на одредено
627време
628 подолг период 3 години – плаќање на рати
629 покус период 1 месец (хостирање)
630 usage license (Oracle)
631 site license
632 on-demand usage-based license
633 Software as a service
634 “Razor and blade” model – основната апликација се нуди бесплатно а се
635наплаќа за останатите делови на продуктот (Adobe)
636 Service model – основната апликација се дава бесплатно а се
637заработува на услуги како инсталација, конфигурација, одржување,
638обука, ... (Red Hat)
639 Advertising model – корисниците не плаќаат за употребата на
640софтверот, но за сметка на тоа мораат да гледаат реклами додека го
641користат (Google, Microsoft Live)
642Софтвер
64342
644ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
645И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
646СОФТВЕРСКО ИНЖЕНЕРСТВО
647Видови на софтвер ©
648 Proprietary software
649 non-free software or closed-source software
650 Free software (open-source software)
651 source code must be made available
652 Free software licenses
653 GNU General Public License
654 GNU Lesser General Public License
655 BSD License
656 Mozilla Public License
657 MIT License
658 Apache License
659Софтвер
66043
661ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
662И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
663СОФТВЕРСКО ИНЖЕНЕРСТВО
664Видови на софтвер (достапност)
665 Freeware (бесплатен)
666 Shareware (бесплатен во основана /
667ограничена форма или за одредено време)
668 Open source (бесплатен со достапен изворен
669код – може да се менува)
670 Commercial
671 Се продава за комерцијални цели
672 Proprietary но може и free (Red Hat, Sun, …)
673 Abandonware
674 Adware
675Софтвер
67644
677ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
678И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
679СОФТВЕРСКО ИНЖЕНЕРСТВО
680 Pressman 7th edition, Ch. 1
681or
682 Pressman 8th edition, Ch. 1
68345
684Процес на развој на софтвер
685ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
686И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
687СОФТВЕРСКО ИНЖЕНЕРСТВО 46
688Софтвер
689______________________________________________________________________________________________________________
690Модели на процеси
691за развој на софтвер
692Модели на процеси за развој
693на софтвер
694 Процесот кој ја обезбедува рамката за практикување на
695софтверското инженерство
696 Што е софтверски процес (процес за развој на софтвер)
697 Кои се генеричките рамковни активности присутни во секој
698софтверски процес
699 Како се моделираат процесите и што се процесни шаблони
700(модели)
701 Кои се пропишани процесни модели и кои се нивните предности
702и недостатоци
703 Што значи агилноста за модерното софтверско инженерство
704 Што е агилно софтверско инженерство и како се разликува од
705традиционалните процесни модели
7062
707Модели на процеси за развој на софтвер
708ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
709И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
710СОФТВЕРСКО ИНЖЕНЕРСТВО
711Генеричка процесна рамка
712 Комуницирање
713 Планирање
714 Моделирање
715 Конструкција
716 Употреба
717Паралелни активности:
718•Следење и контрола
719•Менаџирање на ризици
720•Проверка на квалитет
721•Формални технички прегледи
722•Measurement
723•Менаџирање на ефектите на
724промена
725•Менаџирање за повторна
726употреба
727•Подготовка и продукција на
728документи
729Модели на процеси за развој на софтвер
7303
731ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
732И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
733СОФТВЕРСКО ИНЖЕНЕРСТВО
734Process framework
735 Секоја акција е
736дефинирана со множество
737на задачи кои ги опишува
738работите кои треба да се
739завршат, продуктот кој ќе
740биде продуциран,
741проверките и граничниците
742на основа на кои ќе се
743проценува прогресот
7445
745Модели на процеси за развој на софтвер
746Process framework
747Umbrella activities
748framework activity 1 #
749Task sets
750work tasks
751work products
752quality assurance points
753project milestones
754software engineering action 1 1 # .
755Task sets
756work tasks
757work products
758quality assurance points
759project milestones
760software engineering action 1 k # .
761framework activity n #
762Task sets
763work tasks
764work products
765quality assurance points
766project milestones
767software engineering action n 1 # .
768Task sets
769work tasks
770work products
771quality assurance points
772project milestones
773software engineering action n m # .
774Software process
775ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
776И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
777СОФТВЕРСКО ИНЖЕНЕРСТВО
778Модели на процеси за развој на
779софтвер
780 За да ги реши актуелните проблеми,
781софтверскиот инженер (или тим) мора да
782примени стратегија за развој која ги опфаќа
783нивоата на процесот, методите и алатките
784како и генеричките фази во развојот на
785софтвер. Оваа стратегија е наречена модел
786на процес (за развој на софтвер) или
787парадигма на софтверското инженерство.
788 Изборот на моделот зависи од природата на
789проектот или апликацијата, методите и
790алатките кои ќе се користат како и резултатот
791кој се очекува
792Модели на процеси за развој на софтвер
7936
794ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
795И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
796СОФТВЕРСКО ИНЖЕНЕРСТВО
797Тек на процес
798 Опишува како се поставени рамковните активности, акции и
799задачи и ги моделира нивните меѓусебни релации во рамките
800на процесот (како се организирани во од аспект на секвенца и
801време)
802 Линеарен процесен тек - ги извршува рамковните активности
803во редоследен секвенцијален редослед (почнувајќи со
804комуницирање и завршувајќи со испорака)
805 Итеративен процесен тек ги повторува една или повеќе од
806активностите пред да премине на следна
807 Еволутивен поцесен тек ги извршува активностите во
808повторувачки циркуларен тек, испорачувајќи покомплетна
809верзија на софтверот со секое поминување низ циклусот
810 Паралелен процесен тек извршува една или повеќе активности
811паралелно (симултано) со другите активности
812Модели на процеси за развој на софтвер
8137
814ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
815И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
816СОФТВЕРСКО ИНЖЕНЕРСТВО
817Процесни модели (1)
8188
819Модели на процеси за развој на софтвер
820Communication Planning Modeling
821(a) Linear process flow
822Construction Deployment
823Communication Planning Modeling Construction Deployment
824(b) Iterative process flow
825ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
826И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
827СОФТВЕРСКО ИНЖЕНЕРСТВО
828Процесни модели (2)
8299
830Модели на процеси за развој на софтвер
831(c) Evolutionary process flow
832Planning
833Modeling
834Deployment Construction Increment
835released
836Communication
837(d) Parallel process flow
838Construction Deployment
839Communication Planning
840Modeling Time
841ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
842И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
843СОФТВЕРСКО ИНЖЕНЕРСТВО
844Групи на задачи
845 Секоја акција поврзана со некоја од
846рамковните активности на софтверското
847инженерство може да биде претставенa со
848одредена група на задачи
849 Малите проекти (со еден инволвиран) не
850бараат групи на задачи кои се сложени и
851детални како задачите кај комплексните тим- ориентирании проекти
852 Групите на задачи се прилагодуваат кон
853специфичните потреби на конкретниот
854софтверски проект и карактеристиките на
855проектниот тим
856Модели на процеси за развој на софтвер
85710
858ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
859И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
860СОФТВЕРСКО ИНЖЕНЕРСТВО
861За едноставен проект
862 За едноставен проект активноста
863комуникација може да се сведе на:
8641. Контакт по телефон со засегнатиот
8652. Дискусија околу барањата и прибелешки
8663. Организација на прибелешките во куса
867пишан текст за барањата
8684. Испраќање на текстот по електронска
869пошта до засегнатата страна на
870одобрување
87111
872Модели на процеси за развој на софтвер
873ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
874И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
875СОФТВЕРСКО ИНЖЕНЕРСТВО
876За сложени проекти
877 За посложени проекти со повеќе засегнати
878страни активноста комуникација може да
879вклучува повеќе конкретни акции како:
880 inception - почеток, зачнување
881 elicitation - „изнудување“, прибирање на барања
882 elaboration - елаборација (обработка)
883 negotiation - преговарање
884 specification - спецификација, и
885 validation - валидација, проверка
88612
887Модели на процеси за развој на софтвер
888ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
889И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
890СОФТВЕРСКО ИНЖЕНЕРСТВО
891Акции и задачи
892 Секоја акција може да биде
893претставена со повеќе групи на задачи
894секоја составена од работни задачи,
895работни продукти, проверка на
896квалитет, граничници, ..., соодветно
897избрани според природата на проектот
898и карактеристиките на тимот.
899 Пр. Requirements gathering
90013
901Модели на процеси за развој на софтвер
902ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
903И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
904СОФТВЕРСКО ИНЖЕНЕРСТВО
905За помал не многу сложен проект
906Множеството на работни задачи може да биде:
9071. Правење листа на засегнати страни во проектот
9082. Неформален состанок со засегнатите страни
9093. Барање до засегнатите страни да состават листа од
910посакувани карактеристики и функционалности
9114. Дискусија за барањата и составување на конечна
912листа
9135. Одредување приоритети на барањата
9146. Означување на деловите кои се несигурни
91514
916Модели на процеси за развој на софтвер
917ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
918И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
919СОФТВЕРСКО ИНЖЕНЕРСТВО
920За голем, сложен проект
921Множеството на работни задачи може да биде:
9221. Правење листа на засегнати страни во проектот
9232. Интервју со секоја од засегнатите страни за да се одредат вкупните потреби и
924барања
9253. Правење на листа од карактеристики и функционалности на основа на исказите
926на засегнатите страни
9274. Закажување на серија од состаноци за спецификација на апликацијата
9285. Спроведување на состаноците
9296. Конструирање на неформални кориснички сценарија како резултат од секој од
930состаноците
9317. Рафинирање на сценаријата на основа на повратните информации од
932засегнатите страни
9338. Правење на ревидирана листа од барања на засегнатите страни
9349. Одредување на приоритети на функционалностите
93510. Пакување на функционалностите за да можат да бидат испорачувани
936инкрементално
93711. Обележување на ограничувањата кои се поставени на системот
93812. Дискусија околу методите за валидација на системот
93915
940Модели на процеси за развој на софтвер
941ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
942И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
943СОФТВЕРСКО ИНЖЕНЕРСТВО
944Шаблони
945 Задачите во рамките на акција може да
946се изберат соодветно на специфичните
947потреби според типот на проектот,
948клиентот, тимот, ...
949 Шаблони
950Pattern Name, Forces, Type (stage, task,
951phase), Initial context, Problem, Solution,
952Resulting Context, Related Patterns, Known
953Uses and Examples
95416
955Модели на процеси за развој на софтвер
956ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
957И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
958СОФТВЕРСКО ИНЖЕНЕРСТВО
959Process Pattern
960Шаблон за процесни шаблони
961 Pattern Name – пр. TechnicalReviews
962 Forces – околина во која се сретнува
963 Type
9641. Stage pattern – дефинира проблем поврзан со рамковна
965или процесн активност (пр. EstablishingCommunication)
9662. Task pattern – дефинира проблем поврзан со акција или
967работна задача на софтверското инженерство (пр.
968RequirementsGathering)
9693. Phase pattern - дефинира секвенца на процесни
970активности кои се појавуваат во рамките на процесот (пр.
971SpiralModel или Prototyping)
97217
973Модели на процеси за развој на софтвер
974ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
975И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
976СОФТВЕРСКО ИНЖЕНЕРСТВО
977Process Pattern
978 Initial context – ги опишува предусловите за примена на
979шаблонот
980 На пр. за Planning (stage pattern) предуслов е да е воспоставена
981комуникација, основните барања и огнаничувања за проектот се
982познати
983 Solution – Опишува како успешно да се имплементира
984шаблонот
985 Resulting Context – Ги опишува условите кои ќе важат по
986успешната примена на шаблонот
987 Related Patterns – листа на други процесни шаблони кои се
988поврзани со него
989 На пр. Communication ги содржи шаблоните ProjectTeam,
990CollaborativeGuidelines, ScopeIsolation, RequirementsGathering,
991ConstraintDescription и ScenarioCreation.
992 Known Uses and Examples
99318
994Модели на процеси за развој на софтвер
995ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
996И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
997СОФТВЕРСКО ИНЖЕНЕРСТВО
998Пример за шаблон
999Pattern name. RequirementsUnclear
1000Intent. This pattern describes an approach for building a
1001model (a prototype) that can be assessed iteratively by
1002stakeholders in an effort to identify or solidify software
1003requirements.
1004Type. Phase pattern.
1005Initial context. The following conditions must be met
1006prior to the initiation of this pattern: (1) stakeholders have
1007been identified; (2) a mode of communication between
1008stakeholders and the software team has been
1009established; (3) the overriding software problem to be
1010solved has been identified by stakeholders; (4) an initial
1011understanding of project scope, basic business
1012requirements, and project constraints has been
1013developed.
1014Problem. Requirements are hazy or nonexistent, yet
1015there is clear recognition that there is a problem to be
1016solved, and the problem must be addressed with a
1017software solution. Stakeholders are unsure of what they
1018want; that is, they cannot describe software requirements
1019in any detail.
1020Solution. A description of the prototyping process
1021would be presented here and is described later in
1022Section 2.3.3.
1023Resulting context. A software prototype that identifies
1024basic requirements (e.g., modes of interaction,
1025computational features, processing functions) is
1026approved
1027by stakeholders. Following this, (1) the prototype may
1028evolve through a series of increments to become the
1029production software or (2) the prototype may be
1030discarded
1031and the production software built using some other
1032process
1033pattern.
1034Related patterns. The following patterns are related to
1035this pattern: CustomerCommunication,
1036IterativeDesign, IterativeDevelopment,
1037CustomerAssessment, RequirementExtraction.
1038Known uses and examples. Prototyping is
1039recommended when requirements are uncertain.
1040Модели на процеси за развој на софтвер
104119
1042ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1043И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1044СОФТВЕРСКО ИНЖЕНЕРСТВО
1045Process assessment and improvement
1046 Постоењето на процес за развој на софтвер не е
1047гаранција за успешен софтвер.
1048 Проценка дали процесот задоволува одредени
1049основни критериуми кои праксата покажала дека
1050есенцијални за успешно софтверско инженерство
1051 Различни пристапи:
1052 Standard CMMI Assessment Method for Process Improvement
1053(SCAMPI)
1054 CMM-Based Appraisal for Internal Process Improvement (CBA
1055IPI)
1056 SPICE (ISO/IEC15504)
1057 ISO 9001:2000 for Software
105820
1059Модели на процеси за развој на софтвер
1060ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1061И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1062СОФТВЕРСКО ИНЖЕНЕРСТВО
1063Capability Maturity Model
1064 Software Engineering Institute (SEI) развил модел за
1065изразување на зрелоста на софтверскиот процес кај
1066различни организации кои практикуваат развој на
1067софтвер во 5 нивоа според 18 дефинирани KPAs:
1068 Level 1: Initial – ad hoc & chaotic
1069 Level 2: Repeatable – основно менаџирање на проект за
1070следење на трошоци, рокови и функционалност.
1071Предвидлив успех за проекти слични на веќе изработените +
1072сé од Level 1
1073 Level 3: Defined – Софтверскиот процес и за менаџментот и
1074за инженерските активности е документиран,
1075стандардизиран и интегриран на ниво на целата
1076организација + сé од Level 2
1077 Level 4: Managed – Се вршат детални мерења на
1078софтверскиот процес и квалитетот на софтверот + сé од
1079Level 3
1080 Level 5: Optimizing – Континуирано подобрување на
1081процесот е овозможено со помош на квантитативни
1082повратни информации од процесот и тестирање на
1083иновативни идеи и технологии + сé од Level 4
1084Процес на развој на софтвер
108521
1086ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1087И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1088СОФТВЕРСКО ИНЖЕНЕРСТВО
1089Материјали:
1090 Roger S. Pressman, Software Engineering: A
1091Practitioner’s Approach, 7th edition, McGraw-Hill,
10922010.
1093 Chapter 2: Process Models (pg. 30-64)
1094 Roger S. Pressman, Software Engineering: A
1095Practitioner’s Approach, 5th edition, McGraw-Hill, 2001.
1096 Pratap P.J. Mohapatra, Software Engineering A Lifecycle
1097Approach, New Age Publishers, 2010.
1098 Gary B. Shelly, Harry J. Rosenblatt, Systems Analysis
1099and Design, 9th edition, Cengage Learning, 2011.
110022
1101Модели на процеси за развој на софтвер
1102ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1103И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1104СОФТВЕРСКО ИНЖЕНЕРСТВО 23
1105Модели на процеси за развој на софтвер
1106_________________________________________________________________________________________________________________
1107Класични (пропишани)
1108методи за развој на софтвер
1109Prescriptive process models
1110 Пропишани процесни модели
1111 Историјата забележала дека овие
1112традиционални модели вовеле
1113одредена корисна структура во
1114процесот и разумна водилка за
1115софтверските тимови низ процесот
1116 Секој процесен модел пропишува тек на
1117процесот (work flow) – начинот на кој
1118процесните елементи се во релација
1119едни со други
11202
1121Модели на процеси за развој на софтвер
1122ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1123И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1124СОФТВЕРСКО ИНЖЕНЕРСТВО
1125Поделба на процесните модели (1)
1126 Пропишани (плански водени)
1127 waterfall (водопад)
1128 инкрементални
1129 еволуциски
1130 конкурентни
1131 Специјални
1132 компонентно ориентирани
1133 формални методи
1134 аспектно ориентирани
1135 Unified process
11363
1137Модели на процеси за развој на софтвер
1138ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1139И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1140СОФТВЕРСКО ИНЖЕНЕРСТВО
1141Поделба на процесните модели (2)
1142 Агилни
1143 XP (екстремно програмирање)
1144 Industrial XP
1145 Adaptive Software Development (ASD)
1146 Scrum
1147 Dynamic Systems Development Method (DSDM)
1148 Crystal
1149 Feature Drive Development (FDD)
1150 Lean Software Development (LSD)
1151 Agile Modeling (AM)
1152 Agile Unified Process (AUP)
11534
1154Модели на процеси за развој на софтвер
1155ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1156И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1157СОФТВЕРСКО ИНЖЕНЕРСТВО
1158Модели на софтверски процеси
1159 Модел на водопад (waterfall model) (класичен животен циклус - старомоден, но разумен пристап кога барањата се добро
1160разбрани)
1161 Инкрементални модели (испорачува софтвер во мали
1162употребливи парчиња при што секое парче се заснова на веќе
1163претходно направените парчиња)
1164 Еволутивни модели
1165 Модел на прототипови (разумен иницијален чекор, кога клиентот
1166има легитимна потреба, но деталите не се добро
1167познати/дефинирани, развивачот треба да се спротивстави на
1168притисокот на инвеститорот грубиот прототип да се прошири во
1169продукциски систем)
1170 Спирален модел (ги комбинира итеративниот пристап на
1171прототипови со контролираниот систематски аспекти на водопад
1172моделот)
1173 Паралелен развоен модел (симултан инженеринг - овозможува
1174софтверските тимови да ги претставуваат итеративните и
1175паралелни елементи од кој било процесен модел)
1176Модели на процеси за развој на софтвер
11775
1178ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1179И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1180СОФТВЕРСКО ИНЖЕНЕРСТВО
1181Специјализирани процесни
1182модели
1183 Компонентен развоен модел (варијација на
1184спиралниот развоен модел во кој апликации се
1185градат од готови софтверски компоненти наречени
1186класи)
1187 Формални методи (ригорозна математичка нотација
1188која се користи за да се специфицира, дизајнира и
1189потврди/верификува компјутерски-базиран систем)
1190 Aspect-Oriented развој на софтвер (аспект- ориентирано програмирање - обезбедува процесот
1191на дефинирање, специфицирање, дизајнирање и
1192градење на софтверски аспекти како кориснички
1193интерфејси, сигурност и управување со меморијата
1194кои влијаат на многу делови на системот кој се
1195развива)
1196Модели на процеси за развој на софтвер
11976
1198ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1199И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1200СОФТВЕРСКО ИНЖЕНЕРСТВО
1201Линеарен секвенцијален модел
1202 Линеарниот секвенцијален модел наречен уште и
1203класичен или модел на водопад (waterfall model)
1204сугерира систематски секвенцијален пристап кој ги
1205вклучува следниве активности:
1206 Системско/информационо инженерство и моделирање
1207(бидејќи софтверот е дел од поголем систем)
1208 Анализа на барања на софтверот
1209 Дизајн
1210 Генерирање на код
1211 Тестирање
1212 Поддршка
1213Analysis Design Code Test
1214System/information
1215engineering
1216Модели на процеси за развој на софтвер
12177
1218ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1219И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1220СОФТВЕРСКО ИНЖЕНЕРСТВО
1221Фази во линеарниот секвенцијален модел (1)
1222 Софтверскиот аналитичар мора да го разбере
1223информацискиот домен на софтверот, како
1224потребните функции, однесување, перформанси и
1225интерфејси. Барањата се документираат и се
1226прегледуваат со клиентот.
1227 Дизајнот е повеќечекорен процес кој се фокусира
1228на 4 атрибути на програмата:
12291. податочни структури
12302. софтверски архитектури
12313. претстава на интерфејси
12324. процедурални (алгоритамски) детали
1233 Дизајнот ги преведува барањата во репрезентација
1234на софтверот преку која ќе може да се провери
1235неговиот квалитет уште пред да почне кодирањето
1236Модели на процеси за развој на софтвер
12378
1238ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1239И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1240СОФТВЕРСКО ИНЖЕНЕРСТВО
1241Фази во линеарниот секвенцијален модел (2)
1242 Генерирање на код – преведување на
1243дизајнот во машински читлива (извршна)
1244форма
1245 Тестирање – се концентрира на проверка на
1246интерната логика на софтверот (да се
1247проверат сите функции) – и екстерната
1248логика - дали за секој дефиниран влез се
1249добива бараниот излез
1250 Поддршка – промени: поправка на грешки,
1251прилагодување на нова околина или
1252функционални и перформансни промени
1253барани од клиентот
1254Модели на процеси за развој на софтвер
12559
1256ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1257И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1258СОФТВЕРСКО ИНЖЕНЕРСТВО
1259Класичен Waterfall модел
1260 Прифатлив пристап кога проблемот е
1261добро дефиниран
1262 Сугерира систематски секвенцијален
1263пристап
126410
1265Модели на процеси за развој на софтвер
1266Communication
1267 project initiation
1268 requirements gathering
1269Planning
1270 estimating
1271 scheduling
1272 tracking
1273Modeling
1274 analysis
1275 design Deployment
1276 delivery
1277 support
1278 feedback
1279Construction
1280 code
1281 test
1282ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1283И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1284СОФТВЕРСКО ИНЖЕНЕРСТВО
1285Waterfall
1286The waterfall model of Boehm (1981)
128711
1288Модели на процеси за развој на софтвер
1289ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1290И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1291СОФТВЕРСКО ИНЖЕНЕРСТВО
1292V-model
129312
1294Модели на процеси за развој на софтвер
1295Code
1296generation
1297Architectural
1298design
1299Component
1300design
1301Requirements
1302modeling
1303Acceptance
1304testing
1305System
1306testing
1307Integration
1308testing
1309Unit
1310testing
1311Executable
1312software
1313ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1314И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1315СОФТВЕРСКО ИНЖЕНЕРСТВО 13
1316Модифициран Waterfall модел
1317Requirements Process
1318System Allocation
1319Process
1320Concept Exploration
1321Process
1322Design
1323Process
1324Implementation Process
1325Installation
1326Process
1327Operation &
1328Support Process
1329Verification
1330& Validation
1331Process
1332Модели на процеси за развој на софтвер
1333ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1334И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1335СОФТВЕРСКО ИНЖЕНЕРСТВО
1336Предности на waterfall моделот
1337 Времето потрошено во раните фази (за нивно
1338прецизно завршување/специфицирање)
1339повеќектарно се отплатува во подоцнежните фази.
1340Доколку има грешка во дизајнот полесно (и многу
1341поевтино е да се промени дизајнот) отколку да се
1342потроши многу време на имплементација на лош
1343дизајн - Big Design Up Front (BDUF).
1344 Секоја од фазите да се заврши 100% за да се
1345осигури нејзина исправност пред да се проследи на
1346следната фаза.
1347 Генерирање и одржување прецизна и опсежна
1348документација
1349 Големите компании и владини контрактори работат
1350според овој модел.
1351Модели на процеси за развој на софтвер
135214
1353ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1354И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1355СОФТВЕРСКО ИНЖЕНЕРСТВО
1356Недостатоци на линеарниот
1357секвенцијален модел
1358 Најстар, најчесто користен (и најкритикуван)
1359модел. Некои од неговите недостатоци се:
1360 Реалните проекти ретко кога го следат строгиот
1361секвенцијален модел
1362 Често е тешко клиентот да ги зададе сите свои
1363барања на почетокот на проектот
1364 Клиентот мора да биде трпелив бидејќи работна
1365верзија на програмата ќе добие многу доцна во
1366текот на проектот
1367 blocking states – некои членови од тимот чекаат
1368другите да си ја завршат работата за тие да
1369продолжат (ниска продуктивност)
1370Модели на процеси за развој на софтвер
137115
1372ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1373И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1374СОФТВЕРСКО ИНЖЕНЕРСТВО
1375Критика на waterfall моделот
1376 Додека системот се имплементира барањата
1377се промениле
1378 Корисниците не можат прецизно да ги
1379дефинираат барањата или не се доволно
1380компетенти
1381 Не нуди можности за менаџерска контрола,
1382планирање на проектот и менаџмент на
1383ризици
1384 Голема одвоеност/специјализација на
1385членовите на тимот
1386Модели на процеси за развој на софтвер
138716
1388ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1389И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1390СОФТВЕРСКО ИНЖЕНЕРСТВО
1391Инкрементален модел (1)
1392 Барањата се релативно добро познати, но постои
1393потреба ограничено множество на функционалности
1394да биде обезбедено што побргу, а потоа да се
1395прочистат и прошират функциолностите
1396 Комбинација на линеарниот секвенцијален модел со
1397итеративната филозофија на развојот на
1398прототипови
1399 Секоја секвенца (која се повторува) продуцира
1400испорачлив инкремент на апликацијата. Во секоја
1401итерација се додаваат нови можности.
1402 За разлика од прототипот, инкременталниот модел
1403испорачува употреблив продукт (она што работи
1404работи, но не е имплементирано сé што е планирано)
1405Модели на процеси за развој на софтвер
140617
1407ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1408И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1409СОФТВЕРСКО ИНЖЕНЕРСТВО
1410Incremental Process Model
141118
1412Модели на процеси за развој на софтвер
1413increment 1 #
1414increment 2 #
1415delivery of
14161st increment
1417delivery of
14182nd increment
1419delivery of
1420nth increment
1421increment # n
1422Project Calendar Time
1423S
1424oftw
1425are
1426F
1427u
1428n
1429ctio
1430n
1431ality
1432a
1433n
1434d
1435F
1436e
1437ature
1438s
1439Communication
1440Planning
1441Modeling (analysis design) ,
1442Construction (code test) ,
1443Deployment (delivery feedback) ,
1444ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1445И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1446СОФТВЕРСКО ИНЖЕНЕРСТВО
1447Еволуциски процесни модели
1448 Факт е дека софтверот како и сите
1449комплексни системи мора да еволуира со тек
1450на времето. Барањата поставени пред него
1451често се менуваат додека трае самиот проект
1452(живее софтверот). Често пати е важно да се
1453издаде делумно оперативна (која задоволува
1454само дел од првичните барања) верзија на
1455софтверот, а подоцна да се надгради.
1456 Еволуциските модели го гледаат развојот на
1457софтверот како систем за кој однапред се
1458знае дека ќе мора да се менува
1459Модели на процеси за развој на софтвер
146019
1461ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1462И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1463СОФТВЕРСКО ИНЖЕНЕРСТВО
1464Модел на прототипови
1465 requirements gathering  quick design 
1466prototype construction  prototype evaluation 
1467се концентрираат на
1468деловите видливи за
1469клиентот (input/output),
1470целта не е
1471долготрајна
1472одржливост и добар
1473дизајн (само фасада).
1474Треба да се фрли!
1475Модели на процеси за развој на софтвер
147620
1477Communication
1478Quick plan
1479Construction
1480of
1481prototype
1482Modeling
1483 Quick design
1484Deployment
1485 Delivery
1486 & Feedback
1487ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1488И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1489СОФТВЕРСКО ИНЖЕНЕРСТВО
1490Предности на развој со
1491прототипови
1492 Помага подобро да се разбере што треба да
1493се изгради
1494 Кога се применува?
1495 Нејасно специфицирани барања (се
1496идентификуваат областите каде е неопходна
1497понатамошна попрецизна дефиниција)
1498 Клиентот има легитимен проблем, но не знаат да
1499го искажат (дефинираат)
1500 Брз (неоптимален) дизајн кој се фокусира на
1501аспектите видливи за корисникот
1502Модели на процеси за развој на софтвер
150321
1504ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1505И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1506СОФТВЕРСКО ИНЖЕНЕРСТВО
1507Проблеми при развој со прототипови
1508 Прототиповите се најчесто за една употреба
1509и со строго одредена намена и не треба да
1510еволуираат кон целосен систем
1511 притисок од страна на засегнатите страни
1512(нарачателот)
1513 несоодветни компромиси од страна на
1514програмерот
1515 Уште на почетокто да се истакне пред
1516клиентот дека ќе биде креиран прототип и
1517што тоа значи
1518Модели на процеси за развој на софтвер
151922
1520ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1521И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1522СОФТВЕРСКО ИНЖЕНЕРСТВО
1523Спирален модел (1)
1524 Спиралниот модел е еволуциски модел кој ги
1525комбинира итеративната природа на
1526прототип пристапот со контролираниот и
1527систематски аспект на линеарниот
1528секвенцијален модел.
1529 Софтверот се развива со серија на
1530инкрементални изданија
1531 Во првите фази е само на хартија или како
1532прототип, додека во подоцнежните фази се
1533оформува кон кончен продукт
1534 Воведува попрецизна контрола и
1535менаџирање на ризици
1536Модели на процеси за развој на софтвер
153723
1538ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1539И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1540СОФТВЕРСКО ИНЖЕНЕРСТВО
1541Спирален модел (2)
1542 Дефинира (3-6) рамковните активности
1543(task regions):
1544Customer communication
1545Planning
1546Risk analysis
1547Engineering
1548Construction and release
1549Customer evaluation
1550Модели на процеси за развој на софтвер
155124
1552ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1553И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1554СОФТВЕРСКО ИНЖЕНЕРСТВО
1555Спирален модел (3)
1556Модели на процеси за развој на софтвер
155725
1558Communication
1559Planning
1560Modeling
1561Construction Deployment
1562delivery
1563feedback
1564analysis
1565design
1566code
1567test
1568estimation
1569scheduling
1570risk analysis
1571ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1572И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1573СОФТВЕРСКО ИНЖЕНЕРСТВО
1574WINWIN спирален модел
1575 Многу сличен на стандардниот спирален модел во
1576кој комуникацијата со клиентот е претставена како
1577преговарање и наоѓање на компромиси помеѓу
1578цената, барањата и роковите.
15795. Define next level of
1580product and process,
1581including partitions
15826. Validate product and
1583process definitions
15843a. Reconcile win conditions
15852. Identify stakeholders'
1586win conditions
15871. Identify
1588next-level
1589stakeholders
15903b. Establish next-level objectives,
1591constraints and alternatives
15927. Review and comment
15934. Evaluate process and
1594product alternatives and
1595resolve risks
1596Модели на процеси за развој на софтвер
159726
1598ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1599И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1600СОФТВЕРСКО ИНЖЕНЕРСТВО
1601Паралелен модел
1602Паралелниот развоен модел
1603(Concurrent Development
1604Model) може да се претстави
1605шематски со серија од
1606технички активности, задачи и
1607ним асоцирани состојби.
1608Секоја од активностите може
1609да егзистира во различна
1610состојба.
1611Дефинирани се серија од
1612настани кои можат да го
1613иницираат преминот од една
1614во друга состојба.
1615Сите активности може да
1616бидат истовремено активни но
1617секоја во различна состојба
161827
1619Модели на процеси за развој на софтвер
1620Under review
1621Baselined
1622Under
1623revision
1624Awaiting
1625changes
1626Under
1627development
1628Inactive
1629Modeling activity
1630Represents the state
1631of a software engineering
1632activity or task
1633Done
1634ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1635И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1636СОФТВЕРСКО ИНЖЕНЕРСТВО
1637Паралелен развоен модел за клиент-
1638сервер апликации
1639 Паралелниот развоен модел вообичаено се користи
1640при развојот на клиент-сервер апликации (кои
1641обично може да се претстават како збир на
1642функционални компоненти) каде конкурентниот
1643процес дефинира активности во две димензии
1644 системска димензија со активности design, assembly, use
1645 компонентна димензија со активности design, realization
1646 Конкурентноста се постига на два начина:
16471. Системските и компонентните активност се појавуваат
1648симултано и можат да се моделираат со моделот
1649ориентиран на состојби
16502. Типична клиент-сервер апликации се реализира со
1651употреба на многу компоненти од кои повеќето можат да се
1652дизајнираат и реализираат паралелно
1653Модели на процеси за развој на софтвер
165428
1655ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1656И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1657СОФТВЕРСКО ИНЖЕНЕРСТВО
1658Инкрементален и итеративен развој
1659 Waterfall model = "big bang" integration.
1660 Incremental development = scheduling and staging
1661strategy
1662 Поделба на развојот на фази и нивен распоред со што
1663различни делови од системот се развиваат во различно
1664време и со различен интензитет и се интегрираат како што
1665се завршени
1666 Iterative development = rework scheduling strategy
1667 Се планира време за ревизија и унапредување на делови од
1668системот (не подразбира задолжителен инкрементален
1669развој)
1670 Продуктот се испорачува на (дел од) клиентите и се
1671ревидира по повратните информации од нив
1672 Обединети во Rational Unified Process (RUP)
1673Модели на процеси за развој на софтвер
167429
1675ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1676И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1677СОФТВЕРСКО ИНЖЕНЕРСТВО
1678Итеративен развој
1679Модели на процеси за развој на софтвер
168030
1681ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1682И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1683СОФТВЕРСКО ИНЖЕНЕРСТВО
1684Waterfall vs. Iterative Risk
168532
1686Модели на процеси за развој на софтвер
1687ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1688И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1689СОФТВЕРСКО ИНЖЕНЕРСТВО
1690Компонентно-базиран развој
1691 Commercial off-the-shelf (COTS) софтверски
1692компоненти, понудени како продукти кои
1693обезбедуваат одредена функционалност со прецизно
1694дефинирани интерфејси кои може да бидат
1695интегрирани во софтвер кој се гради
1696 Component-based Development (CBD) моделот
1697вклучува голем дел од карактеристиките на
1698спиралниот модел – еволуциски, итеративен пристап
1699кон развојот на софтвер. CBD ги гради апликациите
1700користејќи готови претходно креирани (и тестирани)
1701софтверски компоненти (класи).
1702Модели на процеси за развој на софтвер
170333
1704ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1705И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1706СОФТВЕРСКО ИНЖЕНЕРСТВО
1707Компонентно базиран развој
1708 Процес сличен на спиралниот, со следниве чекори:
17091. Пребарување низ расположливите компоненти за
1710компоненти погодни за апликацискиот домен и
1711нивна проценка
17122. Проценка на интегралибилноста на компонентите
17133. Креирање на софтверска архитектура во која се
1714интегрираат компонентите
17154. Интеграција на компонентите во архитектурата
17165. Спроведување на темелно тестирање за да се
1717осигури соодветно функционирање
171834
1719Модели на процеси за развој на софтвер
1720ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1721И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1722СОФТВЕРСКО ИНЖЕНЕРСТВО
1723Software reusability
1724 Инженерскиот процес започнува со идентификација
1725на кандидат компоненти и пребарување во базата на
1726расположливи компоненти развиени во претходни
1727проекти дали постои готова компонента која може да
1728ги задоволи барањата. Ако постои истата се користи.
1729Ако не, се развива нова или адаптира некоја
1730постоечка според ОО методи, а потоа се вградува во
1731апликацијата и се става во базата на компоненти за
1732понатамошна употреба.
1733 CBD моделот води кон повторна употреба на
1734софтвер (software reuse) што овозможува некои
1735значајни предности како: 70% намалено време на
1736развој, 84% намалување во цената на проектот и
1737индекс на продуктивност од 26.2 (во споредба со
1738индустрискиот стандард од околу 16.9)
1739Модели на процеси за развој на софтвер
174035
1741ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1742И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1743СОФТВЕРСКО ИНЖЕНЕРСТВО
1744Компонентно-базиран развој
1745Customer
1746evaluation
1747Risk
1748analysis Planning
1749Customer
1750communication
1751Identify
1752candidate
1753components
1754Construct
1755nth iteration
1756of system
1757Put new
1758components
1759in library
1760Look up
1761components
1762in library
1763Extract
1764components
1765if available
1766Engineering
1767construction & release
1768Build
1769components
1770if unavailable
1771Модели на процеси за развој на софтвер
177236
1773ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1774И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1775СОФТВЕРСКО ИНЖЕНЕРСТВО
1776Модели на формални методи
1777 Вклучува збир активности кои водат кон формална
1778математичка спецификација на компјутерскиот
1779софтвер. Ваквата спецификација овозможува да се
1780специфицира, развие и верификува компјутерски
1781систем применувајќи ригорозна математичка
1782нотација.
1783 Нејзина варијација е т.н. clean room software
1784engineering
1785 Формалните методи нудат механизам за
1786согледување и отстранување на бројни проблеми
1787(како двосмисленост, некомплетност и
1788неконзистентност) кои тешко се откриваат ако се
1789користи некоја од другите софтверски парадигми
1790Модели на процеси за развој на софтвер
179137
1792ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1793И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1794СОФТВЕРСКО ИНЖЕНЕРСТВО
1795CleanRoom Software Engineering
1796 CleanRoom Software Engineering е процес за
1797развој на софтвер развиен во IBM со цел да
1798се произведе софтвер со предвидливо ниво
1799на доверливост (сигурност)
1800 Се фокусира на спречувањето на дефекти,
1801наместо нивно откривање и исправање
1802 Во последно време се поврзува со можности
1803за автоматска верификација на
1804спецификацијата со користење на формални
1805јазици за опис на спецификацијата
1806Модели на процеси за развој на софтвер
180738
1808ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1809И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1810СОФТВЕРСКО ИНЖЕНЕРСТВО
1811CleanRoom Software Engineering
1812 Во пракса поретко се применува (освен
1813за развој на критични системи)
1814 Скапа и долготрајна метода
1815 Потребно специфично предзнаење за
1816нејзина примена
1817 Несоодветна за комуникација на
1818дизајнот со клиентот
181939
1820Модели на процеси за развој на софтвер
1821ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1822И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1823СОФТВЕРСКО ИНЖЕНЕРСТВО
1824Аспектно-ориентирано
1825програмирање
1826 Aspect-oriented programming (AOP)
1827аспектно-ориентирано програмирање е
1828програмска парадигма која ги изолира
1829споредните и услужни функции од
1830бизнис логиката на главната програма
1831 Има за цел да се зголеми модуларност
1832со тоа што овозможува поделба на
1833грижите, формирајќи ја основата за
1834аспектно-ориентиран развој на
1835софтвер.
1836Модели на процеси за развој на софтвер
183742
1838ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1839И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1840СОФТВЕРСКО ИНЖЕНЕРСТВО
1841Аспектно-ориентиран развој на
1842софтвер
1843 Аспектно-ориентиран развој на софтвер (AOSD) е
1844нова технологија за развој на софтвер кој бара нова
1845модуларизација на софтверските системи со цел да
1846се изолираат секундарните и функциите за поддршка
1847од бизнис логиката на главната програма. AOSD
1848овозможува различните грижи (concerns) да бидат
1849изразени/разгледувани одвоено/изолирано и
1850автоматски да бидат обединети во единствен
1851работен систем (cross-cutting concerns)
1852 Пр. за concerns
1853 high-level properties of a system (e.g., security, fault tolerance)
1854 functions (e.g., the application of business rules)
1855 systemic (e.g., task synchronization or memory management)
1856Модели на процеси за развој на софтвер
185743
1858ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1859И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1860СОФТВЕРСКО ИНЖЕНЕРСТВО
1861RAD - Rapid Application Development
1862 Rapid Application Development (RAD) е моделот со
1863инкрементални и итеративни компоненти во развојот
1864на софтвер со нагласено исклучително кусо време
1865на развој. Забрзана варијанта на линеарниот
1866секвенцијален модел со масивна употреба на
1867компонентно ориентирана конструкција на
1868софтверот.
1869 RAD моделот ги има следниве фази (според
1870Pressman, 5th edition, 2001):
1871 Business modeling
1872 Data modeling
1873 Process modeling
1874 Application generation
1875 Testing and turnover
1876Модели на процеси за развој на софтвер
187744
1878ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1879И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1880СОФТВЕРСКО ИНЖЕНЕРСТВО
1881RAD модел (1)
1882Карактеристики:
1883 Рано развивање на прототипови (со
1884користење на алатки за брз развој на
1885прототипови) и нивна евалуација од страна
1886на клиентот
1887 Масовна употреба на готови компоненти
1888 Помалку формални ревизии и комуникација
1889помеѓу тимовите
1890 Минимално планирање
1891 JAD (joint application development)
1892 Корисниците се вклучени во сите чекори на
1893развојот
189445
1895Модели на процеси за развој на софтвер
1896ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1897И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1898СОФТВЕРСКО ИНЖЕНЕРСТВО
1899RAD модел (2)
1900 Применлив кога:
1901 барањата се добро разбрани
1902 опсегот на проектот е релативно ограничен (претежно за
1903инфрмациони системи)
1904 поделба на функционалностите за паралелно да се
1905развиваат од одвоени тимови
1906 на располагање се доволно човечки ресурси
1907 на располагање се софистицирани алатки за автоматизација
1908на процесите
1909 посветеност од страна на развивачите и клиентите за брз
1910развој (реагирање)
191146
1912Модели на процеси за развој на софтвер
1913ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1914И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1915СОФТВЕРСКО ИНЖЕНЕРСТВО
1916RAD модел (3)
1917 Недостатоци
1918 За големи проекти
1919потребни се големи
1920човечки ресурси
1921 Програмери и клиенти
1922посветени на RAD моделот
1923 Не е применлив на
1924поширок круг на апликации
1925 Не применлив кога
1926технолошките ризици се
1927високи (нови технологии,
1928софтвер,
1929интероперабилност)
1930Business
1931modeling
1932Team #1
1933Data
1934modeling
1935Process
1936modeling
1937Application
1938generation
1939Testing
1940&
1941turnover
1942Business
1943modeling
1944Data
1945modeling
1946Process
1947modeling
1948Application
1949generation
1950Testing
1951&
1952turnover
1953Data
1954modeling
1955Process
1956modeling
1957Application
1958generation
1959Testing
1960&
1961turnover
1962Team #2
1963Team #3
196460–90 days
1965Business
1966modeling
1967Модели на процеси за развој на софтвер
196847
1969ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1970И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1971СОФТВЕРСКО ИНЖЕНЕРСТВО
1972Unified Software Development Process
1973 Unified Process - “use case driven, architecture-centric,
1974iterative and incremental”
1975 Со употреба на Unified Modeling Language (UML) се
1976дефинираат компонентите од кои ќе се изгради
1977системот како и интерфејсот кој ќе ги поврзува
1978компонентите. Со комбинација на итеративен и
1979инкрементален развој UP ги дефинира функциите на
1980системот со примена на пристап базиран на
1981сценарија (од корисничка гледна точка). Потоа се
1982развиваат функции кои соодветствуваат на
1983архитектонската рамка на системот која ја опишува
1984формата која ќе ја поприми софтверот.
1985Модели на процеси за развој на софтвер
198649
1987ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
1988И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
1989СОФТВЕРСКО ИНЖЕНЕРСТВО
1990Rational Unified Process (RUP)
1991 Rational Unified Process (RUP) – нуди
1992итеративна флексибилна рамка за развој на
1993софтвер со можност на прилагодување кон
1994потребите на софтверскиот тим и клиентот
1995 6 принципи на RUP
19961. Adapt the process
19972. Balance stakeholder priorities
19983. Collaborate across teams
19994. Demonstrate value iteratively
20005. Elevate the level of abstraction
20016. Focus continuously on quality
2002Модели на процеси за развој на софтвер
200350
2004ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2005И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2006СОФТВЕРСКО ИНЖЕНЕРСТВО
2007The Unified Process (UP)
2008Модели на процеси за развој на софтвер
200951
2010software increment
2011Release
2012modeling
2013construction
2014planning
2015communication
2016deployment
2017ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2018И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2019СОФТВЕРСКО ИНЖЕНЕРСТВО
2020RUP project lifecycle
2021 RUP фази:
2022 Inception
2023 Elaboration
2024 Construction
2025 Transition
2026 Production
2027RUP претставува
2028имплементација на спирален
2029модел
2030Типичен профил на проект кој го
2031прикажува релативниот однос на фазите
2032Модели на процеси за развој на софтвер
203352
2034ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2035И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2036СОФТВЕРСКО ИНЖЕНЕРСТВО
2037Inception phase
2038 Зачнување – почетна (иницијална) фаза
2039Business case modeling
2040Rough architecture
2041Plan
2042 Аализи: Success factors (expected revenue,
2043market recognition, etc.), analysis and financial
2044forecast
2045 BCM: Basic use case model, project plan, initial
2046risk assessment and project description (the core
2047project requirements, constraints and key features)
2048are generated.
2049Модели на процеси за развој на софтвер
205053
2051ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2052И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2053СОФТВЕРСКО ИНЖЕНЕРСТВО
2054Elaboration phase
2055 Елаборација – проектот почнува да добива
2056форма
2057 problem domain analysis, refines and expands
2058 Ја проширува (разработува) архитектурата
2059од различни погледи:
2060 use case model,
2061 requirements model,
2062 design model,
2063 implementation model,
2064 deployment model
2065 Ревизија на план, ре-евалуација на ризици
2066Модели на процеси за развој на софтвер
206754
2068ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2069И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2070СОФТВЕРСКО ИНЖЕНЕРСТВО
2071Construction phase
2072 На основа на архитектонските модели,
2073барањата и дизајните се развиваат (или
2074земаат готови) компонентите за да се
2075добие оперативен систем
2076 Дизајнирање и спроведување на unit
2077тестови,
2078 Интеграција на компонентите и
2079интеграциско тестирање
2080Модели на процеси за развој на софтвер
208155
2082ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2083И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2084СОФТВЕРСКО ИНЖЕНЕРСТВО
2085Transition phase
2086 Доцните фази на конструкција и
2087испорака на корисникот
2088Трансфер на софтверот кон корисникот за
2089тестирање
2090Подготовка на документацијата за
2091поддршка
2092Инкрементот станува употреблив софтвер
2093Модели на процеси за развој на софтвер
209456
2095ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2096И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2097СОФТВЕРСКО ИНЖЕНЕРСТВО
2098Production phase
2099Употреба на софтверот од страна на
2100корисникот,
2101 надгледување,
2102 поддршка
2103 реагирање на извештаите на грешки и
2104барања за промени
2105 веројатно паралелно течат другите
2106фази од RUP за следниот инкремент
2107Модели на процеси за развој на софтвер
210857
2109ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2110И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2111СОФТВЕРСКО ИНЖЕНЕРСТВО
2112UP Work Products
2113Модели на процеси за развој на софтвер
211458
2115ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2116И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2117СОФТВЕРСКО ИНЖЕНЕРСТВО
2118Personal Process Models
2119“The best software process is one that is
2120close to the people who will be doing the
2121work.”
2122 Ја нагласува потребата од мерења на
2123продуктот и неговиот квалитет, со цел
2124да се преземат мерки за адаптација на
2125процесот
2126 дисциплиниран, metrics-based пристап
212759
2128Модели на процеси за развој на софтвер
2129ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2130И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2131СОФТВЕРСКО ИНЖЕНЕРСТВО
2132Personal Process Models
2133 PSP дефинира 5 рамковни активности (во сите се спроведува мерење)
21341. Planning
2135 проценка на големина и потребни ресурси, идентификација на работни
2136задачи
21372. High-level design
2138 спецификација на дизајнот на компонентите (прототипови по потреба)
21393. High-level design review
2140 формални методи за верификација на дизајнот
21414. Development
2142 ревизија на дизајнот на компонентите, генерирање, ревизија,
2143преведување и тестирање на кодот
21445. Postmortem
2145 користејќи ги собраните мерки и метрики се одредува ефективноста на
2146процесот (да се разберат типовите на грешки кои се појавуваат и да се
2147преземат активности и адаптација на процесот за нивно намалување)
214860
2149Модели на процеси за развој на софтвер
2150ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2151И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2152СОФТВЕРСКО ИНЖЕНЕРСТВО
2153Team Software Process (TSP)
2154 Да се изгради „само-управувачки“ тим кој се
2155организира самиот за да продуцира софтвер со
2156висок квалитет
2157 Цели
2158 креирање на тимови кои ќе ја планираат и следат својата
2159работа (3-20 инженери)
2160 Обука на менаџерите да ги водат и мотивираат своите
2161тимови
2162 забрзување на подобрувањето на софтверскиот процес
2163(CMM Level 5 е вообичаено и очекувано)
2164 обезбедување насоки за подобрување
2165 Промовирање на изучувањето тимски вештини на
2166индустриско ниво на универзитетите
216761
2168Модели на процеси за развој на софтвер
2169ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2170И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2171СОФТВЕРСКО ИНЖЕНЕРСТВО
2172Process technology tools
2173 Алатки кои помагаат во моделирање и
2174спроведувањето на процесот на развој
2175на софтвер
2176 Планирање, проценка, надгледување и
2177контрола на активностите, акциите и
2178задачите во моделот на процесот
2179 Листи на работи кои треба да бидат
2180сработени, материјали кои треба да
2181бидат испорачани, проверки кои треба
2182да бидат спроведени
218362
2184Модели на процеси за развој на софтвер
2185ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2186И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2187СОФТВЕРСКО ИНЖЕНЕРСТВО
2188Техники на 4-та генерација (4GT)
2189 Техниките на 4-та генерација вклучуваат
2190различни софтверски алатки на кои
2191заедничко им е што овозможуваат на
2192софтверскиот инженер да специфицира
2193одредени карактеристики на софтверот на
2194високо ниво. Алатката потоа автоматски
2195генерира изворен код на основа на
2196зададената спецификација. 4GT парадигмата
2197се фокусира на употреба на специјални
2198јазици или графичка нотација за опис на
2199проблемот.
2200Модели на процеси за развој на софтвер
220163
2202ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2203И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2204СОФТВЕРСКО ИНЖЕНЕРСТВО
2205Техники на 4-та генерација (4GT)
2206 Некои од овие алатки се: непроцедурални јазици за
2207упити во база на податоци, генератори на извештаи,
2208манипулација со податоци, генерирање на код,
2209софистицирани графички можности, кориснички
2210интерфејси, автоматско генерирање на HTML или
2211слични јазици и др.
2212 Предности: забрзан развој и зголемена
2213продуктивност
2214 Ограничувања: применлив на релативно мали
2215проекти и проекти од специфичен тесен проблемски
2216домен, неефикасност на произведениот код,
2217отежнато одржување ако се примани кај големи
2218проекти
2219Модели на процеси за развој на софтвер
222064
2221ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2222И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2223СОФТВЕРСКО ИНЖЕНЕРСТВО
2224Материјали:
2225 Roger S. Pressman, Software Engineering: A
2226Practitioner’s Approach, 7th edition, McGraw-Hill,
22272010.
2228 Chapter 2: Process Models (pg. 30-64)
2229 Roger S. Pressman, Software Engineering: A
2230Practitioner’s Approach, 5th edition, McGraw-Hill, 2001.
2231 Pratap P.J. Mohapatra, Software Engineering A Lifecycle
2232Approach, New Age Publishers, 2010.
2233 Gary B. Shelly, Harry J. Rosenblatt, Systems Analysis
2234and Design, 9th edition, Cengage Learning, 2011.
223565
2236Модели на процеси за развој на софтвер
2237ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2238И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2239СОФТВЕРСКО ИНЖЕНЕРСТВО 66
2240Модели на процеси за развој на софтвер
2241____________________________________________________________________________________________________________________________
2242Агилни методи
2243за развој на софтвер
2244The Manifesto for
2245Agile Software Development
2246“We are uncovering better ways of developing
2247software by doing it and helping others do it.
2248Through this work we have come to value:
2249 Individuals and interactions over processes
2250and tools
2251 Working software over comprehensive
2252documentation
2253 Customer collaboration over contract
2254negotiation
2255 Responding to change over following a plan
2256That is, while there is value in the items on the
2257right, we value the items on the left more.”
22582001 година
2259Агилни методи за развој на софтвер
22602
2261ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2262И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2263СОФТВЕРСКО ИНЖЕНЕРСТВО
2264Историја на агилните методи
2265 Се појавиле како реакција на "heavyweight"
2266методите како waterfall моделот
2267 Различни lightweight методи – слични на
2268агилната кои се појавиле пред 2000
2269 Scrum (1986),
2270 Crystal
2271 Extreme Programming (1996),
2272 Adaptive Software Development,
2273 Feature Driven Development,
2274 DSDM (1995).
2275 Agile Manifesto – формална дефиниција на
2276агилното програмирање
2277Агилни методи за развој на софтвер
22783
2279ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2280И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2281СОФТВЕРСКО ИНЖЕНЕРСТВО
2282Агилност
2283 Промени
2284 Флуидност
2285 Time-to-market
2286 луѓе (со различни персонални и
2287професионални особености)
22884
2289Агилни методи за развој на софтвер
2290ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2291И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2292СОФТВЕРСКО ИНЖЕНЕРСТВО
2293Agile software development
2294 Агилниот развој на софтвер претставува
2295концептуална рамка од софтверското инженерство
2296која промовира итерации при развојот на софтвер
2297низ целиот животен век на проектот
2298 Минимизирање на ризикот со развој на софтверот за
2299многу кусо време
2300 Секоја итерација (2-4 недели) ги вклучува сите фази
2301од развојот на софтвер: планирање, анализа на
2302барања, дизајн, кодирање, тестирање и
2303документирање
2304 Целта е да се има расположлив софтвер за испорака
2305(кој работи и без грешки) на крајот на секоја
2306итерација
2307 На крајот на секоја итерација тимот ги ре-евалуира
2308проектните приоритети
2309Агилни методи за развој на софтвер
23105
2311ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2312И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2313СОФТВЕРСКО ИНЖЕНЕРСТВО
2314Agile software development
2315 Агилните методи претпочитаат лице-в-
2316лице комуникација наместо пишани
2317документи
2318 Го истакнуваат софтверот кој работи
2319како единствена мерка за прогрес
2320 Агилните методи продуцираат многу
2321мал број на документи во споредба со
2322другите поради што се критикувани како
2323недисциплинирани
2324Агилни методи за развој на софтвер
23256
2326ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2327И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2328СОФТВЕРСКО ИНЖЕНЕРСТВО
2329Агилни методологии за развој на
2330софтвер
2331 Му даваат многу помало значење на
2332проектирањето, анализата и
2333документацијата и се концентрираат
2334што побргу да произведат употреблив
2335прототип
2336 Повеќе итерации
2337 Почеста комуникација со клиентите
2338 Екстремно програмирање
2339работа во парови на еден компјутер
2340Агилни методи за развој на софтвер
23417
2342ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2343И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2344СОФТВЕРСКО ИНЖЕНЕРСТВО
2345Цена на промени
23468
2347Агилни методи за развој на софтвер
2348Cost of change
2349using conventional
2350software processes
2351Cost of change
2352using agile processes
2353Idealized cost of change
2354using agile process
2355Development schedule progress
2356D
2357e
2358v
2359elo
2360p
2361m
2362e
2363n
2364t
2365c
2366o
2367s
2368t
2369ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2370И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2371СОФТВЕРСКО ИНЖЕНЕРСТВО
2372Преглед
2373 Агилниот развој на софтвер претставува разумен компромис
2374помеѓу преконвенционалниот пристап кон софтверското
2375инженерство за одредени класи на софтвер и одредени
2376видови на софтверски проекти
2377 Агилниот развој може да испорача успешен системи за кусо
2378време
2379 Агилниот развој ја потенцира постојаната комуникација и
2380соработка меѓу програмерите и корисниците
2381 Агилниот развој ја опфаќа филозофијата која го поттикнува
2382задоволството на клиентите, инкременталната испорака,
2383мали проектни тимови (составени од софтверски инженери и
2384заинтересирани страни), неформални методи, а минимална
2385продукција на останатите продукти на софтверското
2386инженерство (документација)
2387 Агилниот развој дава приоритет на тајмингот за испорака на
2388оперативен софтверски инкремент во однос на анализата и
2389дизајнот (за единствениот навистина важен продукт се смета
2390оперативен софтверски инкремент)
2391Агилни методи за развој на софтвер
23929
2393ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2394И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2395СОФТВЕРСКО ИНЖЕНЕРСТВО
2396Агилност
2397 Агилната екипа може да одговори на
2398промените во текот на развојот на
2399проектот
2400 Агилниот развој прифаќа дека
2401проектниот план мора да биде
2402флексибилен
2403 Агилноста охрабрува структура на
2404тимот и ставови кои ја прават
2405комуникацијата помеѓу програмерите и
2406корисниците полесна и понепосредна
2407 Отстранување на поделба помеѓу
2408клиентите и програмерите
2409Агилни методи за развој на софтвер
241010
2411ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2412И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2413СОФТВЕРСКО ИНЖЕНЕРСТВО
2414Агилност
2415 Агилноста ја нагласува важноста на брзата испорака
2416на оперативен софтвер а ги става во втор план
2417пропратните работни продукти
2418 Агилниот пристап може да се примени на било кој
2419софтверски процес сè додека на проектниот тим му е
2420дозволено да ги забрза задачите и го спроведе
2421планирањето на начинот со кој се елиминираат
2422несуштинските работни продукти
2423 Трошоците на промена се зголемуваат брзо како што
2424проект напредува кон завршување, колку што порано
2425е направена промената толку е поефтина
2426 Агилните процеси може да ја израмнат кривата на
2427цена на промена дозволувајќи на проектниот тим да
2428се прави промени и подоцна во текот на проектот по
2429многу пониски трошоци
243011
2431Агилни методи за развој на софтвер
2432ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2433И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2434СОФТВЕРСКО ИНЖЕНЕРСТВО
2435Агилни процеси
2436Клучни претпоставки за сите агилни процеси
24371. Тешко е однапред да се предвиди кои барања или
2438приоритети на клиентите ќе се променат и кои не
24392. За многу видови на софтвер, дизајнерските и
2440изведбени активности се испреплетени (изведбата
2441се користи за да се провери дизајнот)
24423. Анализата, дизајнот и тестирањето не се толку
2443предвидливи од перспектива на планирање колку
2444што би сакале
2445 За справување со непредвидливоста агилниот
2446процес мора постојано и самиот да се адаптира
2447 Инкременталната адаптација бара повратни
2448информации од клиентот врз основа на оценка на
2449испорачаниот софтверски инкремент (извршни
2450прототипови) во куси временски периоди
2451Агилни методи за развој на софтвер
245212
2453ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2454И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2455СОФТВЕРСКО ИНЖЕНЕРСТВО
2456Принципи на агилност (1)
24571. Највисок приоритет е да се задоволат клиентите преку
2458рана и континуирана испорака на употреблив софтвер
24592. Добредојдени се и промени на барањата подоцна во
2460развојот, на промената се гледа како на зголемување
2461на конкурентната предност на корисникот
24623. Честа испорака на употреблив софтвер со
2463преферирање на куси периоди на испорака (пр. секои 2
2464до 4 недели)
24654. Деловните луѓе и програмерите мора да работат заедно
2466секојдневно во текот на проектот
24675. Засновање на проектот околу мотивирани индивидуи,
2468со обезбедување на околината и поддршката која им е
2469потребна, и со верба дека ќе се заврши работата
24706. Директната лице-в-лице комуникација е најефективен
2471метод за пренесување на информации во рамките на
2472тимот за развој
2473Агилни методи за развој на софтвер
247413
2475ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2476И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2477СОФТВЕРСКО ИНЖЕНЕРСТВО
2478Принципи на агилност (2)
24797. Извршниот софтвер е примараната мерка со која
2480се проценува напредокот
24818. Агилните процеси промовираат одржлив развој - програмерите и корисниците би можеле да го
2482продолжат развојот на неодредено време
24839. Континуираната грижа за техничка совршеност и
2484добар дизајн ја подобрува агилноста
248510. Едноставност (дефинирана како она што не е
2486направено – бидејќи не морало да биде) е од
2487суштинско значење
248811. Најдобрите архитектури, барања и дизајн
2489произлегуваат од само-организирачките тимови
249012. Во редовни интервали тимовите согледуваат како
2491да станат поефикасни и го прилагодуваат своето
2492однесување во согласност со тоа
2493Агилни методи за развој на софтвер
249414
2495ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2496И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2497СОФТВЕРСКО ИНЖЕНЕРСТВО
2498Човечки фактори
2499Агилните методологии се фокусираат на талентите и
2500умешностите на индивидуите прилагодувајќи го
2501процесот на специфичностите на луѓето и тимовите.
2502Карактеристики кои треба да ги поседуваат членовите
2503на агилниот развоен тим:
2504 Компетентност (talent, software skills, process)
2505 Заедничка цел (to deliver a working software increment
2506on time)
2507 Соработка (team members with one another and all
2508other stakeholders)
2509 Способност за носење одлуки (the team is given
2510autonomy - decision-making authority for both technical
2511and project issues)
2512Агилни методи за развој на софтвер
251315
2514ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2515И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2516СОФТВЕРСКО ИНЖЕНЕРСТВО
2517Човечки фактори
2518 Способност за решавање непрецизно
2519дефинирани проблеми (непрецизност, чести
2520промени)
2521 Заемна доверба и почитување
2522 Само-организација
2523 тимот се сомоорганизира за работата која треба
2524да ја заврши
2525 тимот го организира процесот за најдобро да се
2526прилагоди на условите на околината
2527 распоредот на работа се организира за да се
2528испочитува рокот за испорака
2529 самоорганизацијата ја подобрува соработката и го
2530подига моралот
253116
2532Агилни методи за развој на софтвер
2533ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2534И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2535СОФТВЕРСКО ИНЖЕНЕРСТВО
2536Екстремно програмирање
2537 Екстремно програмирање (Extreme
2538Programming – XP) препорачува
2539практики за менаџерите и програмерите
2540кои стимулираат одредени вредности
2541при развојот на софтвер (software
2542engineering best practices taken to
2543"extreme" levels)
2544Kent Beck, Extreme Programming Explained, October 1999.
2545Агилни методи за развој на софтвер
254617
2547ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2548И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2549СОФТВЕРСКО ИНЖЕНЕРСТВО
2550XP Цели
2551 Обид да се консолидираат хуманоста и
2552продуктивноста
2553 Механизам за социјални промени
2554 Препораки за подобрување
2555 Стил на развој на софтвер
2556 Дисциплина при развојот на софтвер
2557Агилни методи за развој на софтвер
255818
2559ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2560И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2561СОФТВЕРСКО ИНЖЕНЕРСТВО
2562XP Вредности
25631. Communication
2564 informal (verbal) collaboration
25652. Simplicity
2566 design for immediate needs only
25673. Feedback
2568 from the implemented software itself, from the
2569customer, from other software team members
25704. Courage (discipline)
2571 design for now – change it later if needed
25725. Respect
257319
2574Агилни методи за развој на софтвер
2575ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2576И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2577СОФТВЕРСКО ИНЖЕНЕРСТВО
2578Екстремно програмирање (2)
2579Агилни методи за развој на софтвер
258020
2581user stories
2582 values
2583acceptance test criteria
2584iteration plan
2585
2586simple design
2587CRC cards
2588unit test
2589continuous integration software increment
2590project velocity computed
2591spike solutions
2592
2593prototypes
2594refactoring
2595pair programming
2596acceptance testing
2597Release
2598design
2599coding
2600planning
2601test
2602ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2603И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2604СОФТВЕРСКО ИНЖЕНЕРСТВО
2605Екстремно програмирање (3)
2606 Се потпира на објектно-ориентиран пристап
2607 Клучни активности (XP Process)
2608 Планирање (кориснички приказни создадени и подредени
2609според вредноста за клиентите)
2610 Дизајн (се преферира едноставен дизајн, CRC картички и
2611дизајн прототипови се единствените работни продукти, се
2612поттикнува рефакторирање, се преплетува со кодирањето)
2613 Кодирање (се фокусираат на unit тестови за проверка на
2614корисничките приказни, нагласува примена на
2615програмирање во парови за да се создаде код за
2616приказната, се користи континуирана интеграција и smoke
2617testing)
2618 Тестирање (unit тестови кои се создаваат уште пред кодот
2619се изведуваат со помош на автоматизирана рамка за
2620тестирање за да поттикне секојдневна употреба на
2621регресиско тестирање, интеграција и валидациско
2622тестирање, тестот за прифаќање се фокусира на системот
2623особини и функциите видлива од страна на корисникот)
2624 Planning
2625 user stories, value, cost, project velocity
2626 Design
2627 CRC cards and spike solutions, continuous design - refactoring
2628 Coding
2629 develop unit test before the code, pair programming, continuous
2630integration
2631 Testing
2632 automated testing, XP acceptance tests - derived from user stories
2633Агилни методи за развој на софтвер
263421
2635ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2636И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2637СОФТВЕРСКО ИНЖЕНЕРСТВО
2638XP Пракси
2639 Fine scale feedback
2640 Pair Programming
2641 Planning Game
2642 Test Driven Development
2643 Whole Team
2644 Continuous process
2645 Continuous Integration
2646 Design Improvement
2647 Small Releases
2648 Shared understanding
2649 Coding Standard
2650 Collective Code
2651Ownership
2652 Simple Design
2653 System Metaphor
2654 Programmer welfare
2655 Sustainable Pace
2656Агилни методи за развој на софтвер
265722
2658ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2659И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2660СОФТВЕРСКО ИНЖЕНЕРСТВО
2661Ограничувања на XP
2662 Променливост на барањата (лесно може да доведе
2663за изместување на фокусот кој може да предизвика
2664потреба од промени во веќе завршената работа
2665според тогаш актуелните барања)
2666 Конфликтни потреби на клиентите (за многу проекти
2667со повеќе засегнати страни може да биде тешко да
2668се одговори на потребите на сите)
2669 Со барањата претставени само како кориснички
2670приказни и тест за прфатловoст е тешко да се
2671избегнат пропустите и недоследностите
2672 Недостаток на формален дизајн (кај сложените
2673системи може да e неопходен формален
2674архитектонски дизајн за да се обезбеди квалитетен и
2675одржлив продукт)
2676Агилни методи за развој на софтвер
267723
2678ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2679И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2680СОФТВЕРСКО ИНЖЕНЕРСТВО
2681Industrial XP
2682 2005 – органска еволуција на XP
2683 Засновано на минимализмот,
2684ориентираноста кон корисникот и воден
2685од тестови развој на XP
2686 Вклучува повеќе менаџмент
2687 Ја проширува улогата на клиентот
2688 Ги унапредува техничките практики
2689Агилни методи за развој на софтвер
269024
2691ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2692И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2693СОФТВЕРСКО ИНЖЕНЕРСТВО
2694IXP нови практики
2695 Оценка на подготвеност (readiness assessment)
2696 Проектна заедница (project community)
2697 Тим -> (проширена) заедница: правници, контролори, ...
2698Пропишан начин на комуникација со нив
2699 Проценка на оправданост на проект (project
2700chartering)
2701 Менаџирање водено до тестови (test-driven
2702management)
2703 поставување на измерливи цели за проценка на напредокот
2704на проектот
2705 Ретроспективи (retrospectives)
2706 Специјализирани ревизии по секој инкремент – (issues,
2707events and lessons learned)
2708 Непрекинато учење (continuous learning)
2709Агилни методи за развој на софтвер
271025
2711ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2712И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2713СОФТВЕРСКО ИНЖЕНЕРСТВО
2714IXP модификации
2715 Модифицирање на некои од постоечките XP практики
2716 SDD (Story-Driven Development)
2717 се инсистира приказната за тест на прифатливост да биде
2718напишана пред да се пишува кодот
2719 DDD (Domain-Driven Design)
2720 Унапредување на системската метафора – креирање на модел
2721на домен
2722 работењето во парови е проширено на менаџерите и
2723другите засегнати
2724 Iterative usability (usability design that evolves)
2725 Модификации на практиките и редефинирање на
2726ролји и одговорности за да се прилагодат кон
2727посериозни и поголеми проекти за големи
2728организации
2729Агилни методи за развој на софтвер
273026
2731ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2732И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2733СОФТВЕРСКО ИНЖЕНЕРСТВО
2734Критика на XP
2735 Requirement volatility
2736Неформално барање на промени
2737 Conflicting customer needs
2738Различни корисници може да имаат
2739различни барања
2740 Requirements are expressed informally
2741User stories и acceptance tests се
2742единствените формални искази за барања
2743 Lack of formal design
2744Агилни методи за развој на софтвер
274527
2746ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2747И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2748СОФТВЕРСКО ИНЖЕНЕРСТВО
2749Cowboy coding
2750 Не е агилна метода
2751 Најгрубо речено програмира кој што
2752сака без план и визија
2753 software management Anti-pattern – на
2754изглед изгледа како да има предности
2755но овие предности се надвладеани од
2756консеквенците и ризикот на ваквиот
2757пристап
2758Агилни методи за развој на софтвер
275928
2760ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2761И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2762СОФТВЕРСКО ИНЖЕНЕРСТВО
2763Other Agile Process Models
2764 Extreme Programming (XP)
2765 Adaptive Software Development (ASD)
2766 Scrum
2767 Dynamic Systems Development Method
2768(DSDM)
2769 Crystal
2770 Feature Driven Development (FDD)
2771 Lean Software Development (LSD)
2772 Agile Modeling (AM)
2773 Agile Unified Process (AUP)
2774Агилни методи за развој на софтвер
277529
2776ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2777И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2778СОФТВЕРСКО ИНЖЕНЕРСТВО
2779Adaptive Software Development
2780 За комплексни
2781системи
2782 Почива на соработка
2783и самоорганизација во
2784тимот
2785 Колаборација
2786 Незлонамерно
2787критикување
2788 Помагање без гнев
2789 Без забошотување
2790 Поседување
2791квалификации кои
2792можат да помогнат
2793 Разгледување на
2794проблемите на
2795начин кои води кон
2796ефективна акција
2797Агилни методи за развој на софтвер
279830
2799adaptive cycle planning
2800 mission statement
2801
2802project constraints
2803basic requirements
2804time boxed release plan -
2805components implemented tested
2806 focus groups for feedback
2807 /
2808
2809formal technical reviews
2810postmortems
2811
2812Requirements gathering
2813 JAD
2814mini specs
2815software increment
2816-
2817adjustments for subsequent cycles
2818Release
2819
2820collaboration
2821speculation
2822learning
2823ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2824И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2825СОФТВЕРСКО ИНЖЕНЕРСТВО
2826Scrum
2827Requirements
2828Analysis
2829Design
2830Evolution
2831Delivery
2832Process pattern = sprint
2833Агилни методи за развој на софтвер
283431
2835every 24
2836hours
283730 days
2838Scrum 15 minute daily meeting : .
2839Team members respond to basics :
28401) What did you do since last Scrum
2841meeting?
28422) Do you have any obstacles ?
28433) What will you do before next
2844 meeting? Sprint Backlog
2845 Feature(s)
2846 :
2847assigned
2848to sprint
2849Product Backlog
2850Prioritized product features desired by the customer
2851 :
2852Backlog
2853items
2854expanded
2855by team
2856New functionality
2857is demonstrated
2858at end of sprint Backlog
2859Sprints
2860Scrum meetings
2861Demos
2862ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2863И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2864СОФТВЕРСКО ИНЖЕНЕРСТВО
2865DSDM
2866 Dynamic Systems Development Model
2867 Incremental prototyping
2868 Pareto принцип – 80% од апликацијата може да се
2869испорача за 20% од времето потребно за да се
2870изработи комплетно (100%)
2871 Feasibility study
2872 Business study
2873 Functional model iteration
2874 Design and build iteration
2875 Implementation
2876Агилни методи за развој на софтвер
287732
2878ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2879И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2880СОФТВЕРСКО ИНЖЕНЕРСТВО
2881Crystal
2882 Фамилија од методи (означени со различни бои) за
2883различна големина/комплексност на проекти
2884 Уважува дека различни проекти имаат потреба од
2885различни полиси, конвенции и методологии
2886 Crystal Clear
2887 Crystal Yellow
2888 Crystal Orange
2889 Crystal Orange Web
2890 Crystal Red
2891 Crystal Maroon
2892 Crystal Diamond
2893 Crystal Sapphire
289433
2895Агилни методи за развој на софтвер
2896ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2897И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2898СОФТВЕРСКО ИНЖЕНЕРСТВО
2899Feature Driven Development
2900 a feature is a client-valued function that can be
2901implemented in two weeks or less
2902Агилни методи за развој на софтвер
290334
2904Develop
2905an
2906Overall
2907Model
2908Build a
2909Features
2910List
2911Plan
2912By
2913Feature
2914Design
2915By
2916Feature
2917Build
2918By
2919Feature
2920(more shape
2921than content)
2922A list of features
2923grouped into sets
2924and subject areas
2925A development plan
2926Class owners
2927Feature Set Owners
2928A design
2929package
2930(sequences)
2931Completed
2932client value -
2933function
2934ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2935И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2936СОФТВЕРСКО ИНЖЕНЕРСТВО
2937FDD
2938 Collaboration among people on a FDD team
2939 Feature-based decomposition followed by by
2940integration of software increments
2941 Communication of technical detail using verbal,
2942graphical and text-based means
2943Template for defining a feature
2944<action> the <result> <by | for | of | to > a(n) <object>
2945Add the product to shopping cart
2946Display the technical specifications of the product
2947Store the shipping information for the customer
2948Агилни методи за развој на софтвер
294935
2950ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2951И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2952СОФТВЕРСКО ИНЖЕНЕРСТВО
2953Agile Modeling
2954 Large, business-critical systems must be
2955modeled so that:
29561. all constituencies can better understand
2957what needs to be accomplished
29582. the problem can be partitioned effectively
2959among the people who must solve it, and
29603. quality can be assessed as the system is
2961being engineered and built.
296236
2963Агилни методи за развој на софтвер
2964ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2965И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2966СОФТВЕРСКО ИНЖЕНЕРСТВО
2967Agile Modeling
2968 Suggests a set of agile modeling principles
2969Model with a purpose
2970Use multiple models
2971Travel light
2972Content is more important than representation
2973Know the models and the tools you use to
2974create them
2975Adapt locally
2976Агилни методи за развој на софтвер
297737
2978ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2979И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2980СОФТВЕРСКО ИНЖЕНЕРСТВО
2981Материјали:
2982 Roger S. Pressman, Software Engineering: A
2983Practitioner’s Approach, 7th edition, McGraw-Hill,
29842010.
2985 Chapter 3: Agile Development (pg. 65-94)
2986 Roger S. Pressman, Software Engineering: A
2987Practitioner’s Approach, 5th edition, McGraw-Hill, 2001.
2988 Pratap P.J. Mohapatra, Software Engineering A Lifecycle
2989Approach, New Age Publishers, 2010.
2990 Gary B. Shelly, Harry J. Rosenblatt, Systems Analysis
2991and Design, 9th edition, Cengage Learning, 2011.
299238
2993Агилни методи за развој на софтвер
2994ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
2995И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
2996СОФТВЕРСКО ИНЖЕНЕРСТВО 39
2997Агилни методи за развој на софтвер
2998_______________________________________________________________________________________________________________
2999Инженерство на барања
3000(Requirements Engineering)
3001Барања (побарувања)
3002 Што се?
3003 Кој ги дефинира?
3004 Зошто се важни?
3005 Кои се чекорите (за да се формулираат)?
3006 Што е излезен продукт?
3007 Како да знаеме дека сме го сториле
3008добро?
30092
3010Инженерство на барања
3011ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3012И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3013СОФТВЕРСКО ИНЖЕНЕРСТВО
3014Инженерство на барања
3015 Збир на активности и техники кои треба да
3016водат кон разбирање на барањата
3017 Главната активност која почнува за време на
3018комуникацијата со клиентот и продолжува за
3019време на моделирањето и треба да води кон
3020разбирање на барањата
3021 Адаптација според процесот, проектот,
3022продуктот, луѓето, ...
3023 Може да бидат изразени како: сценарија за
3024употреба, листи на функционалности и
3025карактеристики, модели или спецификација
30263
3027Инженерство на барања
3028ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3029И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3030СОФТВЕРСКО ИНЖЕНЕРСТВО
3031Requirements engineering (1)
3032 Requirements engineering (инженерство на
3033барања/потреби) обезбедува соодветни механизми
3034кои помагаат да се разбере што клиентот точно сака,
3035анализирање на потребите, проценка на
3036изводливост, преговарање околу разумно решение,
3037спецификација на одредено (разумно) решение,
3038валидација на спецификацијата и менаџирање на
3039барањата при нивната трансформација во
3040„оперативен“ систем
3041 Излезот од процесот на инженерство на барања
3042треба да биде спецификација на компјутерски систем
3043кој соодветно ќе ги задоволи потребите на клиентот
3044Инженерство на барања
30454
3046ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3047И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3048СОФТВЕРСКО ИНЖЕНЕРСТВО
3049Requirements engineering (2)
3050 Requirements engineering процесот може да
3051се подели на 7 чекори:
30521. зачеток (inception)
30532. согледување (requirements elicitation)
30543. елаборација (elaboration)
30554. преговарање (negotiation)
3056 анализа (requirements analysis and negotiation)
30575. спецификација (requirements specification)
3058 моделирање (system modeling)
30596. валидација (requirements validation)
30607. менаџирање (management)
3061Инженерство на барања
30625
3063ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3064И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3065СОФТВЕРСКО ИНЖЕНЕРСТВО
3066Inception
3067 Генерално кога ќе биде идентификувана нова
3068бизнис потреба или ќе биде откриен нов
3069потенцијален пазар или нов сервис.
3070 Засегнатите страни дефинираат бизнис
3071модел за идејата, првична студија за
3072изводливост и негов првичен опис
3073 За време на зачетокот, се добиваат
3074првичните сознанија за проблемот,
3075природата на решението, луѓето кои го
3076бараат решението и начинот на комуникација
3077со нив
30786
3079Инженерство на барања
3080ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3081И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3082СОФТВЕРСКО ИНЖЕНЕРСТВО
3083Requirements Elicitation
3084 Изгледа лесно...
3085 Да се прашаат (клиентот, крајните
3086корисници, останатите засегнати)
3087Што треба да се постигне?
3088Како системот треба да се вклопи во
3089деловните потреби?
3090Како ќе се користи при секојдневната
3091работа?
30927
3093Инженерство на барања
3094ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3095И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3096СОФТВЕРСКО ИНЖЕНЕРСТВО
3097Requirements Elicitation
3098Зошто согледувањето на барањата е тешко?
3099 Problems of scope (проблеми при дефинирање на опсегот) -
3100неправилни граници во системот, детали кои збунуваат наместо
3101да појаснат)
3102 Problems of understanding (проблеми на разбирање ) -
3103клиентите/корисниците ни самите не се сигурни што точно
3104сакаат, ограничено разбирање на можностите и ограничувањата
3105на компјутерскиот систем, ограничено разбирање на доменот на
3106проблемот, проблеми во комуникацијата со системскиот
3107инженер, испуштање на „очевидните“ информации,
3108специфицирање на конфликтни барања или барања кои се
3109непрецизни
3110 Problems of volatility (проблеми поради променливост) –
3111барањата се менуваат во тек на времето
3112Инженерство на барања
31138
3114ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3115И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3116СОФТВЕРСКО ИНЖЕНЕРСТВО
3117Elaboration
3118 Во процесот на елаборација информациите
3119прибрани во тек на зачетокот и
3120согледувањето се
3121 прошируваат
3122 прочистуваат
3123 Да се идентификуваат различните аспекти на
3124функциите, однесувањето и податоците
3125 Преку креирање и анализа на кориснички
3126сценарија за интеракцијата на крајните
3127корисници со системот
31289
3129Инженерство на барања
3130ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3131И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3132СОФТВЕРСКО ИНЖЕНЕРСТВО
3133Negotiation
3134 Се случува клиентите да бараат повеќе
3135од она што може да биде постигнато
3136или дури да постават различни
3137(контрадикторни) барања
3138 Разрешување на овие конфликти низ
3139процес од преговори во кои некои
3140барања се елиминираат, комбинираат,
3141менуваат
314210
3143Инженерство на барања
3144ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3145И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3146СОФТВЕРСКО ИНЖЕНЕРСТВО
3147Specification
3148 Спецификација, може да биде:
3149пишан документ
3150множество графички модели
3151формален математички модел
3152збирка кориснички сценарија
3153прототип
3154комбинација од горенаведените
315511
3156Инженерство на барања
3157ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3158И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3159СОФТВЕРСКО ИНЖЕНЕРСТВО
3160Validation
3161 Проверка на квалитетот на сработеното
3162(продуцираните материјали) за:
3163 недвосмисленост,
3164 јасност,
3165 неконзистентност,
3166 пропусти,
3167 грешки
3168 и нивно поправање
3169 Техничка ревизија од страна на тим од
3170софтверски инженери, клиенти, крајни
3171корисници и други засегнати страни
317212
3173Инженерство на барања
3174ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3175И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3176СОФТВЕРСКО ИНЖЕНЕРСТВО
3177Requirements management
3178 Менаџирање на барањата во текот на
3179нивното формулирање и менување кои
3180ќе постои и за време на изработката и
3181експлоатацијата на системот
3182 Следење на измените
318313
3184Инженерство на барања
3185ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3186И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3187СОФТВЕРСКО ИНЖЕНЕРСТВО
3188Requirements Gathering (1)
3189Чекори при прибирањето на барања:
3190 Проценка на бизнис и технолошката изводливост на
3191предложениот систем (feasibility study)
3192 Согледување на луѓето кои можат да помогнат во
3193спецификацијата на барањата и да се разбере
3194нивната организациона поставеност
3195 Дефинирање на технолошкото опкружување
3196(компјутерски архитектури, оперативни системи,
3197телекомуникациски потреби) во кое системот треба
3198да егзистира
3199 Идентификација на ограничувања во доменот
3200(карактеристики на деловното опкружувањето
3201специфични за апликацискиот домен) кои
3202наметнуваат ограничувања на функционалноста и
3203перформансите на системот или продуктот кој треба
3204да се изгради
3205Инженерство на барања
320614
3207ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3208И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3209СОФТВЕРСКО ИНЖЕНЕРСТВО
3210Requirements Gathering (2)
3211 Дефинирање на еден или повеќе методи за
3212прибирање на барањата (интервјуа, фокусни групи,
3213состаноци со тимови)
3214 Координира учество на повеќе страни во
3215дефинирањето на барањата од различни точки на
3216гледиште идентификувајќи ги принципите на секое
3217евидентирано барање
3218 Идентификација на нејасните (непрецизни) барања
3219како кандидати за испитување со конструкција на
3220прототипови
3221 Креирање на кориснички сценарија со цел
3222клиентите/корисниците подобро да ги
3223идентификуваат клучните барања
3224Инженерство на барања
322515
3226ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3227И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3228СОФТВЕРСКО ИНЖЕНЕРСТВО
3229Products Produced in
3230Requirements Elicitation
3231Во процесот на прибирање на барања се
3232„произведува“:
3233 Извештај за потребите и изводливоста (feasibility study)
3234 Извештај ограничен на делокругот на системот или
3235продуктот
3236 Листа на клиенти, корисници и останати инволвирани во
3237прибирањето/дефинирањето на барањата
3238 Опис на техничко-технолошкото опкружување на системот
3239 Листа на барања (организирани според функција) и
3240соодветните ограничувања на доменот на секое од нив
3241 Множество на кориснички сценарија кои проникнуваат во
3242употребата на системот или продуктот во различни услови
3243 Прототипови развиени поради подобро дефинирање на
3244барањата
3245Инженерство на барања
324616
3247ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3248И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3249СОФТВЕРСКО ИНЖЕНЕРСТВО
3250Requirements Analysis and
3251Negotiation
3252 При анализата, барањата
3253се категоризираат и се организираат во
3254сродни групи
3255се испитува релацијата на секое барање со
3256останатите
3257се проверуваат нивната конзистентност,
3258недостатоци и недоречености
3259се рангираат по важност според барањата
3260на клиентот/корисникот
3261Инженерство на барања
326217
3263ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3264И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3265СОФТВЕРСКО ИНЖЕНЕРСТВО
3266Requirements Analysis and
3267Negotiation
3268 Во процесот на анализа на барањата се поставуваат
3269и се одговара на прашања како:
3270 Дали секое од барањата е конзистентно со глобалната цел
3271на проектот?
3272 Дали барањата се специфицирани на соодветно ниво на
3273апстракција?
3274 Дали барањето е неопходно или претставува дополнителна
3275функција која не е есенцијална за реализација на системот?
3276 Дали секое од барањата е соодветно ограничено и
3277прецизно?
3278 Дали секое барање има познат извор (кој го задал)?
3279 Дали некое од барањата е во конфликт со некое друго?
3280 Дали секое од барањата може да се реализира во
3281зададената техничка околина во која ќе егзистира системот?
3282 Дали секое од барањата може да се провери (тестира)
3283откако ќе биде имплементирано?
3284Инженерство на барања
328518
3286ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3287И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3288СОФТВЕРСКО ИНЖЕНЕРСТВО
3289Requirements Analysis and
3290Negotiation
3291 Разрешувањето на недоследностите во
3292барањата се изведува со преговори
3293 Се рангираат барањата по важност
3294 Се прави груба проценка на потребниот
3295напор за да се задоволи секое од нив
3296 Се проценува цената и времето потребно за
3297реализација на проектот
3298 Врз база на овие проценки некои од
3299иницијалните барања се елиминираат, се
3300комбинираат или се менуваат
3301Инженерство на барања
330219
3303ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3304И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3305СОФТВЕРСКО ИНЖЕНЕРСТВО
3306Requirements Specification
3307 Стандарден шаблон за спецификација
3308 Системската спецификација претставува
3309основа за:
3310 хардверското инженерство
3311 софтверското инженерство
3312 податочното инженерство
3313 инженерство со човечки ресурси
3314 Системската спецификација ги дефинира
3315функциите и перформансите на
3316компјутерскиот систем, како и информациите
3317(податоци и контрола) кои се влез и излез од
3318системот
3319Инженерство на барања
332020
3321ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3322И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3323СОФТВЕРСКО ИНЖЕНЕРСТВО
3324System Modeling
3325 Модел на системот се гради (на хартија
3326/ нацрт) со цел да се евалуираат
3327системските компоненти и нивните
3328меѓурелации, како барањата и
3329ограничувањата се вклопуваат во оваа
3330слика и да се процени „естетиката“ на
3331системот што и да се подразбира под
3332тоа.
3333Инженерство на барања
333421
3335ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3336И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3337СОФТВЕРСКО ИНЖЕНЕРСТВО
3338Requirements Validation
3339 Квалитетот (одржливоста) на она што е
3340направено во процесот на инженеринг на
3341барања (requirements engineering) се
3342проценува во фазата на валидација на
3343барањата (requirements validation)
3344 Се испитува спецификацијата дали ги
3345задоволува критериумите и стандардите
3346поставени за проектот
3347 Примарниот механизам е технички преглед
3348 воочување на можни грешки, недоследности,
3349контрадикторности, непрецизности
3350 истакнување на делови каде е потребно
3351дообјаснување
3352 воочување на можни конфликтни или нереални
3353барања
3354Инженерство на барања
335522
3356ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3357И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3358СОФТВЕРСКО ИНЖЕНЕРСТВО
3359Прашања за валидација (1)
3360 Валидацијата на барањата може формално да се
3361изведе со формална проверка на секое барање во
3362однос на колекција од прашања во форма на листа
3363за штиклирање (checklist).
3364 Некои од прашањата кои можат да бидат поставени
3365се:
3366 Дали барањето е јасно поставено? Дали може да биде
3367погрешно разбрано?
3368 Дали е идентификуван изворот (човек, регулатива,
3369стандард, документ, препорака) на барањето?
3370 Дали барањето е квантитативно ограничено?
3371 Кои други барања се во врска со барањето? Дали се јасно
3372означени преку cross-reference matrix или друг механизам?
3373Инженерство на барања
337423
3375ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3376И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3377СОФТВЕРСКО ИНЖЕНЕРСТВО
3378Прашања за валидација (2)
3379 Дали барањето нарушува некои од ограничувањата на
3380доменот?
3381 Дали може да биде тестирано? Може ли да се
3382специфицираат тестови (критериуми за валидација) за тоа
3383да се провери?
3384 Дали барањето може да се следи до евентуален модел на
3385системот? (traceability)
3386 Дали барањето може да се следи до глобалните системски /
3387проектни цели?
3388 Дали спецификациите се дадени во структурирана форма
3389која значи лесно разбирање, референцирање и
3390преведување во потехнички документи?
3391 Дали е креиран индекс за спецификацијата?
3392 Дали барањата кои се однесуваат на перформансите,
3393однесувањето и операционите карактеристики на системот
3394се јасно изразени? Кои од барањата се подразбираат (се
3395излишни)?
3396Инженерство на барања
339724
3398ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3399И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3400СОФТВЕРСКО ИНЖЕНЕРСТВО
3401Менаџирање на барања (1)
3402 Барањата се менуваат...
3403 Менаџирање на барања (requirements
3404management) претставува збир од
3405активности кои помагаат на проектниот
3406тим да ги идентификува, контролира и
3407следи промените на барањата во текот
3408на изведбата на проектот.
3409Инженерство на барања
341025
3411ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3412И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3413СОФТВЕРСКО ИНЖЕНЕРСТВО
3414Менаџирање на барања (2)
3415Секое барање се идентификува и се означува
3416со единствен идентификатор
3417<requirement type><requirement #>
3418каде типот на секое од барањата може да биде:
3419 F = functional requirement,
3420 D = data requirement,
3421 B = behavioral requirement,
3422 I = interface requirement,
3423 P = output requirement.
3424Инженерство на барања
342526
3426ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3427И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3428СОФТВЕРСКО ИНЖЕНЕРСТВО
3429Traceability Tables
3430 По идентификацијата на барањата се прават т.н.
3431traceability tables (табели за следење) во кои јасно се
3432означуваат врските (релациите, зависноста) на секое
3433од барањата со еден или повеќе од аспектите на
3434системот или околината.
3435 Некои од можните traceability tables се:
3436 Features traceability table.
3437 Source traceability table.
3438 Dependency traceability table.
3439 Subsystem traceability table.
3440 Interface traceability table.
3441 вообичаено се одржуваат како дел од базата на
3442барања
3443Инженерство на барања
344427
3445ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3446И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3447СОФТВЕРСКО ИНЖЕНЕРСТВО
3448Traceability Table
3449Specific aspect of the system or its environment
3450Requirement
3451R01
3452R02
3453R03
3454R04
3455R05
3456Rnn
3457A01 A02 A03 A04 A05 Aii
3458Инженерство на барања
345928
3460ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3461И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3462СОФТВЕРСКО ИНЖЕНЕРСТВО
3463Software Requirements Specification
3464Template (1)
3465A software requirements specification (SRS) is a
3466document that is created when a detailed
3467description of all aspects of the software to be
3468built must be specified before the project is to
3469commence. It is important to note that a formal
3470SRS is not always written.
3471In fact, there are many instances in which effort expended on an SRS
3472might be better spent in other software engineering activities. However,
3473when software is to be developed by a third party, when a lack of
3474specification would create severe business issues, or when a system is
3475extremely complex or business critical, an SRS may be justified.
347629
3477Инженерство на барања
3478ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3479И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3480СОФТВЕРСКО ИНЖЕНЕРСТВО
3481Software Requirements Specification
3482Template (2)
3483Table of Contents
3484Revision History
34851. Introduction
34861.1 Purpose
34871.2 Document Conventions
34881.3 Intended Audience and
3489Reading Suggestions
34901.4 Project Scope
34911.5 References
349230
3493Инженерство на барања
34942. Overall Description
34952.1 Product Perspective
34962.2 Product Features
34972.3 User Classes and
3498Characteristics
34992.4 Operating Environment
35002.5 Design and Implementation
3501Constraints
35022.6 User Documentation
35032.7 Assumptions and
3504Dependencies
3505ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3506И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3507СОФТВЕРСКО ИНЖЕНЕРСТВО
3508Software Requirements Specification
3509Template (3)
35103. System Features
35113.1 System Feature 1
35123.2 System Feature 2
3513... (and so on)
35144. External Interface
3515Requirements
35164.1 User Interfaces
35174.2 Hardware Interfaces
35184.3 Software Interfaces
35194.4 Communications Interfaces
352031
3521Инженерство на барања
35225. Other Nonfunctional
3523Requirements
35245.1 Performance Requirements
35255.2 Safety Requirements
35265.3 Security Requirements
35275.4 Software Quality Attributes
35286. Other Requirements
3529Appendix A: Glossary
3530Appendix B: Analysis Models
3531Appendix C: Issues List
3532ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3533И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3534СОФТВЕРСКО ИНЖЕНЕРСТВО
3535Software Requirements Engineering
3536 Инженерство (анализа) на софтверски
3537барања е процесот на откривање,
3538прочистување, моделирање и спецификација
3539на софтверските барања.
3540 Инженерство на софтверски барања
3541претставува систематска употреба на
3542докажани принципи, техники, јазици, и алатки
3543за ефективна анализа, документирање и
3544еволуција на корисничките барања и
3545спецификацијата на софтверскиот систем кој
3546треба да ги задоволи тие барања.
3547 Во него активно учествуваат и клиентот и
3548софтверскиот инженер
354932
3550Инженерство на барања
3551ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3552И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3553СОФТВЕРСКО ИНЖЕНЕРСТВО
3554Чекори
3555 Барањата се идентификуваат преку
3556прибирање податоци од клиентот
3557 Барањата се анализираат и прочистуваат за
3558да се обезбеди нивна јасност, комплетност и
3559конзистентност.
3560 Се изработува спецификација вклучувајќи и
3561модел на софтверот и истата се проверува
3562(одобрува) од клиентот. Барањата можат да
3563бидат репрезентирани со прототип,
3564спецификација, симболички модел, ...
3565 Излез е документ (Software requirements
3566specification)
356733
3568Инженерство на барања
3569ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3570И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3571СОФТВЕРСКО ИНЖЕНЕРСТВО
3572Принципи при спецификација
3573 Одвоеност на функционалноста од
3574имплементацијата
3575 Да се развие модел за посакуваното однесување на
3576системот како одѕиви на стимули од околината
3577 Воспоставување на контекстот во кој ќе работи
3578софтверот преку специфицирање на начинот на кој
3579системските компоненти интер-реагираат со
3580софтверот
3581 Креирање на когнитивен модел наместо дизајн или
3582имплементација (како системот го спознаваат
3583корисниците)
3584 Спецификацијата може да биде и некомплетна и
3585непрецизна
3586 Воспоставување на структура на содржината на
3587спецификацијата која овозможува лесни промени
358834
3589Анализа и моделирање на барања
3590ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3591И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3592СОФТВЕРСКО ИНЖЕНЕРСТВО
3593Репрезентација
3594 Форматот и содржината треба да бидат
3595релевантни за проблемот
3596 Информациите презентирани во
3597спецификацијата треба да бидат вгнездени
3598 Дијаграмите и останатите начини на
3599означување треба да се контролирани и
3600конзистентни (стандардизирани)
3601 Репрезентацијата треба да биде погодна за
3602промени
360335
3604Анализа и моделирање на барања
3605ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3606И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3607СОФТВЕРСКО ИНЖЕНЕРСТВО
3608Репрезентација на софтверски
3609барања
3610 Спецификација – кулминација на анализата
3611 IEEE standard No. 830-1984 – стандарден формат за
3612репрезентација на софтверските барања
3613 Introduction (цели, контекст)
3614 Information description (детален опис на проблемот,
3615содржина, тек и структура на информациите, хардверски,
3616софтверски и кориснички интерфејси)
3617 Functional Description (за секоја функција која е потребна за
3618решавање на проблемот, наративен опис, ограничувања,
3619перформанси, дијаграми, врска со останатите елементи)
3620 Behavioral Description (функционирање на софтверот како
3621последица на надворешни настани и интерна состојба)
3622 Validation Criteria (како да се провери успешно реализиран
3623софтвер, дефинирање на тестови
3624 Bibliography and Appendix (друга документација, референци,
3625стандарди, ...)
362636
3627Анализа и моделирање на барања
3628ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3629И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3630СОФТВЕРСКО ИНЖЕНЕРСТВО
3631Ревизија на спецификација на
3632софтверски барања
3633 Се изведува и од клиентот и од развивачот
3634 Обид да се провери дали спецификацијата е
3635комплетна, конзистентна и прецизна
3636 Појаснување на изразите како: нешто,
3637малку, понекогаш, вообичаено, претежно, ...
3638 По изведената ревизија, спецификацијата се
3639потпишува и станува дел од договорот
3640помеѓу клиентот и развивачот
3641 Барањата за дополнителни промени
3642„поинаку“ се третираат
364337
3644Анализа и моделирање на барања
3645ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3646И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3647СОФТВЕРСКО ИНЖЕНЕРСТВО
3648IEEE Std. 830
3649According to IEEE Std. 830, a Software Requirements
3650Specification (SRS) should address the following issues:
3651 Functionality. What is the software supposed to do?
3652 External interfaces. How does the software interact
3653with people, the system’s hardware, other hardware, and
3654other software?
3655 Performance. What is the speed, availability, response
3656time, recovery time of various software functions, and so
3657on?
3658 Attributes. What are the portability, correctness,
3659maintainability, security, and other considerations?
3660 Design constraints imposed on an implementation.
3661Are there any required standards in effect,
3662implementation language, policies for database integrity,
3663resource limits, operating environment(s) and so on?
366438
3665Анализа и моделирање на барања
3666ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3667И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3668СОФТВЕРСКО ИНЖЕНЕРСТВО
3669IEEE Std. 830
3670This is what should be targeted by an SRS. There
3671are other topics that should be excluded from an
3672SRS, according to the standard:
3673 The SRS writer(s) should avoid placing either
3674design or project requirements in the SRS.
3675 (The SRS) should not describe any design or
3676implementation details. These should be
3677described in the design stage of the project.
3678 The SRS should address the software product,
3679not the process of producing the software
3680product.
368139
3682Анализа и моделирање на барања
3683ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3684И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3685СОФТВЕРСКО ИНЖЕНЕРСТВО
3686IEEE Std. 830
3687IEEE Std. 830 describes the following characteristics of a good SRS,
3688which should be observed both when writing and reviewing an SRS:
3689 Correct. An SRS is correct if, and only if, every requirement stated
3690therein is one that the software shall meet.
3691 Unambiguous. An SRS is unambiguous if, and only if, every
3692requirement stated therein has only one interpretation.
3693 Complete. An SRS is complete if, and only if, it includes the
3694following elements:
3695 a) All significant requirements, whether relating to functionality,
3696performance, design constraints, attributes, or external interfaces.
3697 b) Definition of the responses of the software to all realizable classes of
3698input data in all realizable classes of situations.
3699 c) Full labels and references to all figures, tables, and diagrams in the
3700SRS and definition of all terms and units of measure.
3701 Consistent. Consistency refers to internal consistency. If an SRS
3702does not agree with some higher-level document, such as a system
3703requirements specification, then it is not correct.
370440
3705Анализа и моделирање на барања
3706ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3707И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3708СОФТВЕРСКО ИНЖЕНЕРСТВО
3709IEEE Std. 830
3710 Ranked for importance and/or stability. An SRS is ranked
3711for importance and/or stability if each requirement in it has an
3712identifier to indicate either the importance or stability of that
3713particular requirement.
3714 Verifiable. An SRS is verifiable if, and only if, every
3715requirement stated therein is verifiable. A requirement is
3716verifiable if, and only if, there exists some finite cost-effective
3717process with which a person or machine can check that the
3718software product meets the requirement.
3719 Modifiable. An SRS is modifiable if, and only if, its structure
3720and style are such that any changes to the requirements can
3721be made easily, completely, and consistently while retaining
3722the structure and style.
3723 Traceable. An SRS is traceable if the origin of each of its
3724requirements is clear and if it facilitates the referencing of
3725each requirement in future development or enhancement
3726documentation.
372741
3728Анализа и моделирање на барања
3729ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3730И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3731СОФТВЕРСКО ИНЖЕНЕРСТВО
3732Засегнати страни, гледишта,
3733приоритети, ...
3734 Идентификување на засегнатите (stakeholder
3735identification)
3736 Иницијална листа на луѓе (и други извори)
3737кои ќе придонесат во откривањето на
3738барањата
3739 Гледишта (Viewpoints)
3740 маркетинг, бизнис, корисници, софтверски
3741инженери, одржувачи, ...
3742 да се согледаат неконзистентните и конфликтни
3743барања
3744 воспоставување на приоритети
374542
3746Инженерство на барања
3747ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3748И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3749СОФТВЕРСКО ИНЖЕНЕРСТВО
3750Собирање информации за
3751барањата на софтверот
3752 Состанок или интервју
3753 Контекстно независни прашања
3754 Кој стои зад барањето?
3755 Кој ќе го користи решението?
3756 Кои би биле економските придобивки на успешно
3757решение?
3758 Прашања кои ќе помогнат подобро да го разбере
3759проблемот
3760 Кои проблеми треба да ги реши софтверското решение?
3761 Како би се карактеризирало доброто решение?
3762 Која е околината во која би се користело решението?
3763 Дали постојат специфични барања околу перформансите
3764на решението или дополнителни ограничувања?
376543
3766Инженерство на барања
3767ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3768И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3769СОФТВЕРСКО ИНЖЕНЕРСТВО
3770Собирање информации за
3771барањата на софтверот
3772 Мета-прашања
3773 Дали моите прашања се релевантни за вашиот проблем?
3774 Дали вашите одговори се официјални?
3775 Дали некој друг може да даде дополнителни информации
3776околу проблемот?
3777 Дали треба да прашам уште нешто?
3778 Состанок како комбинација на
3779 решавање на проблемот
3780 преговори
3781 спецификација
378244
3783Инженерство на барања
3784ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3785И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3786СОФТВЕРСКО ИНЖЕНЕРСТВО
3787FAST
3788 Facilitated Application Specification Techniques
3789(FAST) – формирање заеднички тим од
3790клиенти и развивачи на софтвер кои работат
3791заедно за да го идентификуваат проблемот,
3792да понудат елементи на решението, да
3793преговараат околу различните пристапи и да
3794специфицираат прелиминарно множество на
3795барања
3796 Претежно користен за информациони
3797системи (JAD – IBM, METHOD)
379845
3799Инженерство на барања
3800ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3801И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3802СОФТВЕРСКО ИНЖЕНЕРСТВО
3803Collaborative Request Gathering
3804 Состанок (на неутрален терен)
3805 Правила на игра
3806 Агенда
3807 „Олеснувач“
3808 Механизам за дефиниција
3809 Целта е да се идентификува проблемот, да се
3810предложат елементи на решението, да се разгледаат
3811различните пристапи, да се специфицира
3812прелиминарно множество на барања во атмосфера
3813која поволна за решавање на проблемот
3814 Пред состанокот – дистрибуција на “product request”
3815документ, секој учесник прави листа на свои
3816забелешки (согледувања, дополнувања) (листа на
3817објекти, дополнителни сервиси, ограничувања,
3818перформанси)
381946
3820Инженерство на барања
3821ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3822И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3823СОФТВЕРСКО ИНЖЕНЕРСТВО
3824Product description example
3825Our research indicates that the market for home
3826management systems is growing at a rate of 40 percent
3827per year. The first SafeHome function we bring to
3828market should be the home security function. Most
3829people are familiar with “alarm systems” so this would
3830be an easy sell.
3831The home security function would protect against
3832and/or recognize a variety of undesirable “situations”
3833such as illegal entry, fire, flooding, carbon monoxide
3834levels, and others. It’ll use our wireless sensors to detect
3835each situation. It can be programmed by the
3836homeowner, and will automatically telephone a
3837monitoring agency when a situation is detected.
383847
3839Инженерство на барања
3840ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3841И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3842СОФТВЕРСКО ИНЖЕНЕРСТВО
3843SafeHome
3844 Objects
3845 smoke detectors, window and door sensors, motion detectors,
3846an alarm, an event (a sensor has been activated), a control
3847panel, a display, telephone numbers, a telephone call
3848 Services (act on objects)
3849 setting the alarm, monitoring the sensors, dialing the phone,
3850programming the control panel, reading the display
3851 Constraints
3852 the system must have a manufactured cost of less than $80,
3853must be user-friendly, must interface directly to a standard phone
3854line
3855 Performance criteria
3856 a sensor event should be recognized within one second, an
3857event priority scheme should be implemented
385848
3859Инженерство на барања
3860ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3861И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3862СОФТВЕРСКО ИНЖЕНЕРСТВО
3863Состанок
3864 Оправданост на проектот
3865 Презентирање на индивидуалните листи (за секоја
3866област)
3867 Листите се комбинираат
3868 Дискусија – консензус листа
3869 Поделба на подтимови кои ќе развијат мини- спецификации
3870 презентација на мини-спецификациите кои можат да
3871откријат нови објекти, сервиси, ... и дискусија
3872 листа на отворени прашања
3873 Критериуми за валидација
3874 Делегирање на пишувањето на комплетна драфт
3875спецификација на база на сите материјали од FAST
3876состанокот
387749
3878Инженерство на барања
3879ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3880И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3881СОФТВЕРСКО ИНЖЕНЕРСТВО
3882Mini-specification for the SafeHome
3883object control panel
3884The control panel is a wall-mounted unit that is
3885approximately 9 x 5 inches in size. The control panel
3886has wireless connectivity to sensors and a PC. User
3887interaction occurs through a keypad containing 12 keys.
3888A 3 x 3 inch LCD color display provides user feedback.
3889Software provides interactive prompts, echo, and
3890similar functions.
389150
3892Инженерство на барања
3893ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3894И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3895СОФТВЕРСКО ИНЖЕНЕРСТВО
3896Quality Function Deployment
3897 Quality function deployment (QFD) е техника за
3898менаџирање на квалитет која ги преведува
3899потребите на корисниците во технички барања на
3900софтверот. Се концентрира на согледување што е
3901значајно за корисникот и испорака на овие барања
3902низ инженерскиот процес.
3903 QFD идентификува три типа на барања:
3904 Normal requirements (Нормални барања – како што се
3905поставени од клиентот)
3906 Expected requirements (Подразбирани барања – ненагласени
3907фундаментални барања)
3908 Exciting requirements (Можности кои не се побарани, но од
3909кои клиентот би бил особено задоволен)
391051
3911Инженерство на барања
3912ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3913И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3914СОФТВЕРСКО ИНЖЕНЕРСТВО
3915QFD
3916 Многу од QFD концептите се
3917применливи и во процесот на собирање
3918на барањата
3919function deployment
3920information deployment
3921task deployment
3922Value analysis (одредување приоритети)
392352
3924Инженерство на барања
3925ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3926И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3927СОФТВЕРСКО ИНЖЕНЕРСТВО
3928Сценарија на употреба
3929(Usage Scenarios)
3930 Како функционалностите и особините
3931ќе бидат користени од различните класи
3932на крајни корисници
3933 Сценарија - use cases
393453
3935Инженерство на барања
3936ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3937И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3938СОФТВЕРСКО ИНЖЕНЕРСТВО
3939Elicitation Work Products
3940 Изјава за потреба и остварливост (statement of need and
3941feasibility)
3942 Дефинирање на опсег (bounded statement of scope for the system
3943or product)
3944 Листа на засегнати страни
3945 Опис на техничкото опкружување на системот
3946 Листа на барања (организирана според функции и
3947ограничувањата придружени за секое од нив)
3948 Множество на сценарија за употреба кои обезбедуваат увид во
3949употребата на системот во различни оперативни околности
3950 Евентуални прототипови развиени за подобро да се
3951дефинираат барањата
395254
3953Инженерство на барања
3954ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3955И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3956СОФТВЕРСКО ИНЖЕНЕРСТВО
3957Материјали:
3958 Roger S. Pressman, Software Engineering: A
3959Practitioner’s Approach, 7th edition, McGraw-Hill,
39602010.
3961 Chapter 5: Understanding requirements (pg. 119-)
396255
3963Модели на процеси за развој на софтвер
3964ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3965И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3966СОФТВЕРСКО ИНЖЕНЕРСТВО
3967Прашања?
3968Инженерство на барања
396956
3970_____________________________________________________________________________________________________________________
3971АНАЛИЗА И
3972МОДЕЛИРАЊЕ
3973дел 1
3974Акроними...
3975 ERD - Entity Relationship Diagram
3976 DFD - Data Flow Diagram
3977 STD - State Transition Diagram
3978 DOD - Data Object Description
3979 DFM - Data Flow Model
3980 PSPEC - Process Specification
3981 CSPEC - Control Specification
3982 PAT - Process Activation Table
3983 PDL - Program Design Language
3984 CASE - Computer-aided Software Engineering
3985Анализа и моделирање на барања
39862
3987ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
3988И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
3989СОФТВЕРСКО ИНЖЕНЕРСТВО
3990Анализа и моделирање
3991 На техничко ниво софтверското инженерство
3992почнува со низа активности на моделирање
3993кои водат кон детална спецификација на
3994барањата и разбирлива репрезентација на
3995дизајнот на софтверот кој треба да се
3996направи.
3997 Моделот за анализа е првата техничка
3998репрезентација на системот.
3999 Денес доминираат два пристапа:
4000 Структурна анализа
4001 Објектно-ориентирана анализа
4002Анализа и моделирање на барања
40033
4004ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4005И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4006СОФТВЕРСКО ИНЖЕНЕРСТВО
4007Модел
4008 Моделот креиран за време на анализата на
4009барања е основа за:
4010 анализа за разбирање на информациите кои ги
4011процесира системот, функциите со кои го прави
4012тоа и однесувањето на системот со што процесот
4013на прибирање и анализа на барањата го прави
4014полесен и посистематски
4015 ревизија, одредување на комплетност,
4016конзистентност и прецизност на спецификацијата
4017 дизајн обезбедувајќи му на дизајнерот основна
4018репрезентација на софтверот кој треба да се
4019преслика во имплементациски контекст
40204
4021Анализа и моделирање на барања
4022ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4023И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4024СОФТВЕРСКО ИНЖЕНЕРСТВО
4025Анализа
4026 Анализа е активност во која се гради модел
4027 Во неа се креираат и анализираат податочни,
4028функционални, модели на однесување и
4029други модели кои треба да ја претстават
4030суштината на она што треба да се изгради
4031 Се употребува комбинација од текст и
4032дијаграмска (графичка) претстава за да се
4033опишат барањата за податоци,
4034функционалност и однесување на начин кој е
4035едноставен за разбирање и што е уште
4036поважно овозможува проверка на
4037коректноста, комплетноста и конзистентноста
4038Анализа и моделирање на барања
40395
4040ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4041И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4042СОФТВЕРСКО ИНЖЕНЕРСТВО
4043Моделирање
4044 Податочното моделирање ги дефинира
4045податочните објекти, атрибутите и
4046релациите
4047 Функционалното моделирање изразува
4048како податоците ќе се трансформираат
4049во системот
4050 Моделирање на однесување го
4051изразува влијанието на настаните на
4052системот (и неговата реакција)
4053Анализа и моделирање на барања
40546
4055ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4056И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4057СОФТВЕРСКО ИНЖЕНЕРСТВО
4058Моделирање и анализа на барања
4059 Што е?
4060 комбинација од текст и дијаграми и шеми кои ги
4061отсликуваат барањата на начин на кој е релативно
4062лесно да се разберат и ревидираат од аспект на
4063коректност, комплетност и конзистентност
4064 Кој го прави? – софтверскиот инженер
4065(аналитичар)
4066 Зошто се важни?
4067 при валидацијата се гледаат од неколку различни
4068перспективи (модели на сценарија, податочни
4069модели, класни модели, ...)
40707
4071Анализа и моделирање на барања
4072ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4073И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4074СОФТВЕРСКО ИНЖЕНЕРСТВО
4075Моделирање и анализа на барања
4076 Крајниот продукт на анализата (SRS)
4077мора да биде лесен за одржување
4078 Проблем со големината - ефективно
4079партицинирање (организација на
4080документот)
4081 Диференцирање помеѓу логичките
4082(есенцијални) и физичките
4083(имплементациски) аспекти
4084 Интерфејси, логика, полиси, ...
40858
4086Анализа и моделирање на барања
4087ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4088И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4089СОФТВЕРСКО ИНЖЕНЕРСТВО
4090Анализа на барања
4091 Да се произведат модели
4092 Scenario-based models
4093 Data models
4094 Class-oriented models
4095 Flow-oriented models
4096 Behavioral models
4097 Ги обезбедуваат клучните информации
4098потребни на дизајнерот на софтвер за
4099моделите да ги преведе во архитектурен
4100дизајн, дизајн на интерфејси и дизајн на
4101компоненти
41029
4103Анализа и моделирање на барања
4104ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4105И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4106СОФТВЕРСКО ИНЖЕНЕРСТВО
4107Анализа на барања
4108Алката која ги поврзува системското
4109инженерство и дизајнот на софтвер
4110Software
4111design
4112Software
4113requirements
4114analysis
4115System
4116engineering
411710
4118Анализа и моделирање на барања
4119System
4120description
4121Analysis
4122model
4123Design
4124model
4125ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4126И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4127СОФТВЕРСКО ИНЖЕНЕРСТВО
4128Анализа на барања
4129Анализата на барања треба да:
4130 резултира со спецификација за
4131оперативните карактеристики на
4132софтверот (function, data, behavior)
4133 да ги воочи интерфејсите на софтверот
4134со останатите елементи на системот
4135 да ги воспостават ограничувањата кои
4136софтверот мора да ги задоволи
413711
4138Анализа и моделирање на барања
4139ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4140И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4141СОФТВЕРСКО ИНЖЕНЕРСТВО
4142Анализа на барања
4143 Процесот на анализа на барањата на
4144софтверскиот дизајнер треба да му обезбеди
4145репрезентација на
4146 информациите,
4147 функциите и
4148 однесувањето
4149кои треба да се преточат во
4150 податочен дизајн
4151 архитектурен дизајн
4152 дизајн на кориснички интерфејс
4153 дизајн на компоненти
415412
4155Анализа и моделирање на барања
4156ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4157И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4158СОФТВЕРСКО ИНЖЕНЕРСТВО
4159Анализа на барања
41601. Препознавање на проблемот
41612. Проценка на проблемот и создавање решение
4162(евалуација и синтеза)
4163 дефинирање на сите екстерно видливи податочни објекти
4164 согледување на текот и содржината на информациите
4165 дефинирање и елаборирање на сите функции на софтверот
4166 разбирање на однесувањето на софтверот во контекст на
4167настаните кои влијаат на системот
4168 дефинирање на карактеристиките на интерфејсот кон
4169системот
4170 откривање на дополнителни ограничувачки фактори во
4171дизајнот
41723. Моделирање
41734. Спецификација
41745. Ревизија
4175концентрирање на ШТО не КАКО!
417613
4177Анализа и моделирање на барања
4178ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4179И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4180СОФТВЕРСКО ИНЖЕНЕРСТВО
4181Елементи на моделот за анализа
4182Треба да постигне три основни цели:
41831. Да опише што сака клиентот
41842. Да создаде основа за креирање на
4185софтверскиот дизајн
41863. Да се дефинира множество на барања
4187кои ќе може да се проверат откако
4188софтверот ќе биде направен
4189Анализа и моделирање на барања
419014
4191ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4192И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4193СОФТВЕРСКО ИНЖЕНЕРСТВО
4194Анализа – основни принципи
4195 Секој метод за анализа има различен аспект
4196 Заеднички оперативни принципи за систематски
4197приод кон проблемот:
41981. Информацискиот домен на проблемот мора да
4199биде претставен и разбран
42002. Мора да бидат дефинирани функциите кои треба
4201да ги изведува софтверот
42023. Однесувањето на софтверот (како последица на
4203екстерни настани) мора да биде претставено
42044. Моделите кои ги опишуваат информациите,
4205функцијата и однесувањето мора да бидат
4206поделени на начин кој ги открива деталите во
4207слоевита (хиерархиска) претстава
42085. Процесот на анализа треба да се движи од
4209есенцијалните информации кон
4210имплементациските детали
421115
4212Анализа и моделирање на барања
4213ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4214И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4215СОФТВЕРСКО ИНЖЕНЕРСТВО
4216Основни принципи во фазата на
4217анализа
4218 Продуцирање на документи кои лесно
4219се одржуваат (ажурираат) - SRS
4220 Партиционирање (поделба)
4221 Употреба на графички приказ
4222 Разлика помеѓу логичката (есенцијална)
4223и физичката (имплементациска)
4224претстава мора да се земе во предвид
4225Анализа и моделирање на барања
422616
4227ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4228И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4229СОФТВЕРСКО ИНЖЕНЕРСТВО
4230Основни правила при креирање
4231модели за анализа
4232 фокусирање на барања кои се видливи во доменот на
4233проблемот – нивото на апстракција треба да е релативно
4234високо
4235 секој елемент треба да придонесува во разбирањето на
4236софтверските барања и да дава поглед во информацискиот,
4237функцискиот и доменот на однесување на системот
4238 одложување на инфраструктурните и други нефункционални
4239модели за подоцна
4240 минимизирање на поврзаноста во системот
4241 моделот на барања да обезбедува вредност за засегнатите
4242страни
4243 моделот да биде што е можно поедноставен
424417
4245Анализа и моделирање на барања
4246ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4247И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4248СОФТВЕРСКО ИНЖЕНЕРСТВО
4249Domain Analysis
4250 Шаблони за анализа често се
4251појавуваат кај апликации од одреден
4252бизнис домен
4253 Кој ги дефинира, категоризира, ...?
425418
4255Анализа и моделирање на барања
4256Domain
4257analysis
4258Sources of
4259domain
4260knowledge
4261Customer surveys
4262Expert advice
4263Current future requirements /
4264Existing applications
4265Technical literature
4266Domain
4267analysis
4268model
4269Functional models
4270Domain languages
4271Reuse standards
4272Class taxonomies
4273ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4274И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4275СОФТВЕРСКО ИНЖЕНЕРСТВО
4276Пристапи при моделирање на
4277барања
4278 Структурна анализа
4279податоците и процесите кои ги
4280трансформираат податоците ги разгледува
4281како посебни ентитети
4282 Објектно-ориентирана анализа
4283дефинирање на класи и начинот на кои
4284колаборираат за да го решат проблемот
428519
4286Анализа и моделирање на барања
4287ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4288И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4289СОФТВЕРСКО ИНЖЕНЕРСТВО
4290Елементи на анализа
4291Software
4292Requirements
4293Class
4294models
4295e g. ,.
4296class diagrams
4297collaboration diagrams
4298Flow
4299models
4300e g. ,.
4301DFDs
4302data models
4303Scenario based -
4304models
4305e g. ,.
4306use cases
4307user stories
4308Behavioral
4309models
4310e g. ,.
4311state diagrams
4312sequence diagrams
431320
4314Анализа и моделирање на барања
4315ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4316И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4317СОФТВЕРСКО ИНЖЕНЕРСТВО
4318Scenario-Based Modeling
4319 Прелиминарен Use Case
4320 Рафинирање на прелиминарниот Use Case
4321 Дали актерот на одредено место може да
4322преземе и други акции?
4323 Дали актерот може да се сретне со грешка на
4324одредено место, каква и што при тоа?
4325 Дали е можно актерот да се сретне со поинакво
4326однесување (иницирано од надворешни
4327настани на пр.) и кои би можеле да бидат тие?
4328 Составување формален Use Case
4329 Придружни UML модели (Activity, Swimlane
4330Diagrams)
433121
4332Анализа и моделирање на барања
4333ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4334И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4335СОФТВЕРСКО ИНЖЕНЕРСТВО
4336Прелиминарен Use-Case
4337 Use-Case ~ “contract for behavior”
4338 начинот на кој актерот го користи компјутерскиот
4339систем за да постигне одредена цел
4340 ги опфаќа интеракциите кои се појавуваат помеѓу
4341креаторите на информации, консументите на
4342информации и самиот систем
4343 Прелиминарниот Use-Caseсе се пишува прво во
4344наративна неформална форма
4345 потоа (ако е потребно) во поформална структурна
4346форма
434722
4348Анализа и моделирање на барања
4349ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4350И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4351СОФТВЕРСКО ИНЖЕНЕРСТВО
4352Use case: Access camera surveillance via the Internet—display
4353camera views (ACS-DCV)
4354Actor: homeowner
4355If I’m at a remote location, I can use any PC with appropriate browser
4356software to log on to the SafeHome Products website. I enter my user
4357ID and two levels of passwords and once I’m validated, I have access
4358to all functionality for my installed SafeHome system. To access a
4359specific camera view, I select “surveillance” from the major function
4360buttons displayed. I then select “pick a camera” and the floor plan of the
4361house is displayed. I then select the camera that I’m interested in.
4362Alternatively, I can look at thumbnail snapshots from all cameras
4363simultaneously by selecting “all cameras” as my viewing choice. Once I
4364choose a camera, I select “view” and a one-frame-per-second view
4365appears in a viewing window that is identified by the camera ID. If I
4366want to switch cameras, I select “pick a camera” and the original
4367viewing window disappears and the floor plan of the house is displayed
4368again. I then select the camera that I’m interested in. A new viewing
4369window appears.
437023
4371Анализа и моделирање на барања
4372ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4373И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4374СОФТВЕРСКО ИНЖЕНЕРСТВО
4375Подредена секвенца на акции на корисникот. Секоја
4376акција претставена со декларативна реченица
43771. The homeowner logs onto the SafeHome Products website.
43782. The homeowner enters his or her user ID.
43793. The homeowner enters two passwords (each at least eight
4380characters in length).
43814. The system displays all major function buttons.
43825. The homeowner selects the “surveillance” from the major function
4383buttons.
43846. The homeowner selects “pick a camera.”
43857. The system displays the floor plan of the house.
43868. The homeowner selects a camera icon from the floor plan.
43879. The homeowner selects the “view” button.
438810. The system displays a viewing window that is identified by the
4389camera ID.
439011. The system displays video output within the viewing window at one
4391frame per second.
439224
4393Анализа и моделирање на барања
4394ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4395И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4396СОФТВЕРСКО ИНЖЕНЕРСТВО
4397Примарни сценарија
4398 Секвенцијалната презентација не
4399разгледува алтернативни интеракции
4400(додека наративната е послободна и може
4401да содржи и алтернативи)
440225
4403Анализа и моделирање на барања
4404ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4405И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4406СОФТВЕРСКО ИНЖЕНЕРСТВО
4407Рафинирање на сценарио
4408 Опис на алтернативните интеракции
4409 Секое примарно сценарио се разгледува од аспект
4410на следниве прашања
44111. Може ли актерот да преземе други акции на ова
4412место?
44132. Дали е можно актерот да наиде на грешка на ова
4414место? Ако може, каква?
44153. Дали е можно актерот да наиде на поинакво
4416однесување на системот на ова место (иницирано
4417од некој настан кој не е под контрола на актерот)?
4418Ако може, кој настан и какво однесување?
441926
4420Анализа и моделирање на барања
4421ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4422И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4423СОФТВЕРСКО ИНЖЕНЕРСТВО
4424Секундарни сценарија
4425 Одговорите на претходните прашања водат
4426кон секундарни сценарија кои се дел на
4427истиот Use-Case но опишуваат алтернативно
4428однесување
4429 Пр.
44306. The homeowner selects “pick a camera.”
44317. The system displays the floor plan of the house.
4432 Може ли да преземе други акции?
4433 Може ли да наиде на грешка?
4434 Може ли да наиде на поинакво однесување?
443527
4436Анализа и моделирање на барања
4437ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4438И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4439СОФТВЕРСКО ИНЖЕНЕРСТВО
4440Use-Case exception
4441 Исклучок опишува ситуација (испад или алтернатива
4442избрана од корисникот) кое предизвикува системот
4443да се однесува поинаку
4444 Можни прашања за откривање исклучоци: Дали има
4445случаи ...
4446 ... во кои се појавува одредена „функција за проверка“ во
4447текот на овој Use-Case (која може да предизвика
4448пријавување на грешка)?
4449 ... во кои помошна функција или актер може да не одговори
4450на упатено барање?
4451 ... во кои слаби перформанси на системот може да
4452предизвикаат неочекувани или несоодветни кориснички
4453акции?
445428
4455Анализа и моделирање на барања
4456ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4457И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4458СОФТВЕРСКО ИНЖЕНЕРСТВО
4459Формален Use-Case
4460 Use case:
4461 Iteration:
4462 Primary actor:
4463 Goal in context:
4464 Preconditions:
4465 Trigger:
4466 Scenario:
4467 Exceptions:
446829
4469Анализа и моделирање на барања
4470 Priority:
4471 When available:
4472 Frequency of use:
4473 Channel to actor:
4474 Secondary actors:
4475Channels to
4476secondary actors:
4477 Open issues:
4478ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4479И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4480СОФТВЕРСКО ИНЖЕНЕРСТВО
4481Formal Use Case (1)
4482 Use case: Access camera surveillance via the
4483Internet—display camera views (ACS-DCV)
4484 Iteration: 2, last modification: January 14 by V. Raman.
4485 Primary actor: Homeowner.
4486 Goal in context: To view output of camera placed
4487throughout the house from any remote location via the
4488Internet.
4489 Preconditions: System must be fully configured;
4490appropriate user ID and passwords must be obtained.
4491 Trigger: The homeowner decides to take a look inside
4492the house while away.
4493 Scenario:
44941. …
44952. …
449630
4497Анализа и моделирање на барања
4498ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4499И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4500СОФТВЕРСКО ИНЖЕНЕРСТВО
4501Formal Use Case (2)
4502 Exceptions:
45031. ID or passwords are incorrect or not recognized - see use case
4504Validate ID and passwords.
45052. Surveillance function not configured for this system - system
4506displays appropriate error message; see use case Configure
4507surveillance function.
45083. Homeowner selects “View thumbnail snapshots for all camera” -
4509see use case View thumbnail snapshots for all cameras.
45104. A floor plan is not available or has not been configured - display
4511appropriate error message and see use case Configure floor plan.
45125. An alarm condition is encountered - see use case Alarm
4513condition encountered.
451431
4515Анализа и моделирање на барања
4516ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4517И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4518СОФТВЕРСКО ИНЖЕНЕРСТВО
4519Formal Use Case (3)
4520Priority: Moderate priority, to be implemented after basic
4521functions.
4522When available: Third increment.
4523Frequency of use: Moderate frequency.
4524Channel to actor: Via PC-based browser and
4525Internet connection.
4526Secondary actors: System administrator, cameras.
4527Channels to secondary actors:
45281. System administrator: PC-based system.
45292. Cameras: wireless connectivity.
453032
4531Анализа и моделирање на барања
4532ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4533И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4534СОФТВЕРСКО ИНЖЕНЕРСТВО
4535Formal Use Case (4)
4536Open issues:
45371. What mechanisms protect unauthorized use of this
4538capability by employees of SafeHome Products?
45392. Is security sufficient? Hacking into this feature would
4540represent a major invasion of privacy.
45413. Will system response via the Internet be acceptable
4542given the bandwidth required for camera views?
45434. Will we develop a capability to provide video at a higher
4544frames-per-second rate when high bandwidth connections
4545are available?
454633
4547Анализа и моделирање на барања
4548ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4549И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4550СОФТВЕРСКО ИНЖЕНЕРСТВО
4551Графички репрезентации
4552 доколку е потребно – да се вклучат
4553(појаснуваат)
4554 Use case се фокусира на
4555функционалните барања и барањата за
4556однесување на системот – најчесто не
4557соодветен за нефункционалните
4558барања
4559 UML модели (дијаграми)
456034
4561Анализа и моделирање на барања
4562ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4563И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4564СОФТВЕРСКО ИНЖЕНЕРСТВО
4565UML модели (дијаграми)
4566 Activity Diagram
4567 Swimlane Diagrams
4568 State Machine Diagram
4569 Interaction / Communication Diagram
4570 Sequence / Timing diagrams
457135
4572Анализа и моделирање на барања
4573ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4574И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4575СОФТВЕРСКО ИНЖЕНЕРСТВО
4576Data-Modeling
4577 Ако софтверот има потреба од креирање,
4578манипулација на комплексни податочни структури
4579или интерфејс кон база на податоци, вообичаено се
4580прави податочен модел
4581 Еntity-relationship diagram (ERD) ги опишува сите податочни
4582објекти кои се внесуваат, чуваат, трансформираат и
4583продуцираат во апликацијата
4584 Податочни објекти (Data Objects)
4585 предмет, екстерен ентитет, појава, настан, улога,
4586организациона единица, ...
4587 Атрибути
4588 ги дефинираат особините на податочниот објект: именуваат,
4589опишуваат, референцираат
4590 Релации
459136
4592Анализа и моделирање на барања
4593ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4594И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4595СОФТВЕРСКО ИНЖЕНЕРСТВО
4596Податочно моделирање
4597 Податочното моделирање (data modeling)
4598одговара на прашања релевантни за
4599податоците кои се обработуваат:
4600 Кои се примарните податочни објекти кои ќе се
4601процесираат?
4602 Кој е составот на секој од овие објекти и кои се
4603атрибутите кои го карактеризираат?
4604 Каде се наоѓа објектот?
4605 Која е релацијата на секој од објектите со
4606останатите објекти?
4607 Која е релацијата помеѓу објектите и процесите
4608кои ги трансформираат?
4609 За полесно да се одговорат овие прашања се
4610користи ERD (Entity relationship diagram).
4611Анализа и моделирање на барања
461237
4613ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4614И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4615СОФТВЕРСКО ИНЖЕНЕРСТВО
4616Entity relationship diagram (ERD)
4617 ERD – графичка нотација која овозможува
4618идентификација на податочните објекти и
4619нивните релации
4620 Ги разгледува „чистите“ податоци и нивните
4621релации, независно од процесите кои ги
4622трансформираат
4623 Податочните модели се состојат од:
4624 податочни објекти
4625 атрибути кои ги опишуваат објектите
4626 релации кои ги поврзуваат податочните објекти
4627меѓусебно
4628Анализа и моделирање на барања
462938
4630ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4631И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4632СОФТВЕРСКО ИНЖЕНЕРСТВО
4633Data objects, attributes, relationships
4634Objects: Attributes: Relationships:
4635owns
4636Name
4637Address
4638Age
4639Driver's license
4640Number
4641Make
4642Model
4643ID number
4644Body type
4645Color
4646Анализа и моделирање на барања
464739
4648ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4649И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4650СОФТВЕРСКО ИНЖЕНЕРСТВО
4651Особини на податочен објект
4652Особини на податочен објект:
4653 Единствен идентификатор
4654 Игра одредена улога во системот
4655 Опишан е преку атрибутите
4656Типични објекти:
4657 External entities (ентитет кој продуцира или консумира
4658информации)
4659 Things (извештај, приказ)
4660 Occurrences or events (телефонски повик, аларм)
4661 Roles (продавач)
4662 Organizational units (сметководство)
4663 Places (магацин)
4664 Structures (датотека)
4665Анализа и моделирање на барања
466640
4667ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4668И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4669СОФТВЕРСКО ИНЖЕНЕРСТВО
4670Податочен објект
4671 Податочен објект – репрезентација на
4672било која композитна информација.
4673 Податочните објекти се во релација
4674едни со други. Релацијата претставува
4675именувана врска помеѓу објектите
4676лице поседува автомобил
4677 Податочниот објект содржи (обединува)
4678само податоци
4679Анализа и моделирање на барања
468041
4681ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4682И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4683СОФТВЕРСКО ИНЖЕНЕРСТВО
4684Атрибути (1)
4685Make Model ID# Body type Color Owner
4686Identifier
4687Instance
4688Lexus
4689Chevy
4690BMW
4691Ford
4692LS400
4693Corvette
4694750iL
4695Taurus
4696AB123. . .
4697X456. . .
4698XZ765. . .
4699Q12A45. . .
4700Sedan
4701Sports
4702Coupe
4703Sedan
4704White
4705Red
4706White
4707Blue
4708RSP
4709CCD
4710LJL
4711BLF
4712Ties one data object to another,
4713in this case, owner
4714Naming
4715attributes
4716Descriptive
4717attributes
4718Referential
4719attributes
4720object: automobile
4721attributes:
4722 make
4723 model
4724 ID#
4725 body type
4726 color
4727 owner
4728Анализа и моделирање на барања
472942
4730ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4731И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4732СОФТВЕРСКО ИНЖЕНЕРСТВО
4733Атрибути (2)
4734 Атрибутите ги дефинираат својствата на
4735објектот и имаат една од трите
4736карактеристики:
4737 ја именуваат инстанцата на податочниот објект
4738 ја опишуваат инстанцата на податочниот објект
4739 референцираат кон друга инстанца во друга
4740табела
4741 Еден (или повеќе) од атрибутите мора да
4742бидат дефинирани како идентификатор (клуч
4743кој може но не мора да биде единствен)
4744 Изборот на атрибути за даден податочен
4745објект зависи од проблемот (апликацијата)
4746 Се прикажуваат во табела или елипса
4747Анализа и моделирање на барања
474843
4749ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4750И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4751СОФТВЕРСКО ИНЖЕНЕРСТВО
4752Class-Based Modelling
4753 Ги опишува
4754објектите со кои системот ќе манипулира
4755операциите (методи, сервиси) кои ќе
4756бидат применувани на објектите
4757релациите (некои хиерархиски) помеѓу
4758објектите
4759колаборациите помеѓу класите
476044
4761Анализа и моделирање на барања
4762ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4763И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4764СОФТВЕРСКО ИНЖЕНЕРСТВО
4765Class-Based Modeling
4766 Идентификација и анализа на класите
4767 Специфицирање на атрибути
4768 Дефинирање на операциите (методите)
4769 CRC моделирање (Class-ResponsibilityCollaborator)
4770 Асоцијации и зависности
4771 Пакети
477245
4773Анализа и моделирање на барања
4774ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4775И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4776СОФТВЕРСКО ИНЖЕНЕРСТВО
4777Идентификација и анализа на класите
4778 Идентификација на класите и методите со
4779анализа на корисничките сценарија
4780 што може да бидат објекти:
4781 External entities (други системи, уреди, луѓе)
4782 Things (извештај, приказ)
4783 Occurrences or events (телефонски повик, аларм)
4784 Roles (продавач)
4785 Organizational units (сметководство)
4786 Places (магацин)
4787 Structures (датотека)
4788 што не се објекти
4789 императивни процерури (InvertImage)
479046
4791Анализа и моделирање на барања
4792ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4793И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4794СОФТВЕРСКО ИНЖЕНЕРСТВО
4795Спецификација на атрибути
4796 Атрибутите ја опишуваат класата, ја
4797дефинираат и појаснуваат
4798 Зависат од примената на класата
4799(контекстто на проблемот)
4800 Пр.
4801class: car
4802attributes: maker, model_no, prod_year,
4803milage, color, … ?
4804attributes: reg_no, owner, color, …
480551
4806Анализа и моделирање на барања
4807ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4808И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4809СОФТВЕРСКО ИНЖЕНЕРСТВО
4810Дефинирање на операции
4811 Различни видови на операции, 4 главни
4812категории
48131. Операции со кои се манипулираат
4814податоците (додавање, бришење,
4815реформатирање,...)
48162. Операции кои прават некаква пресметка
48173. Операции кои проверуваат состојба на
4818објект
48194. Операции кои го надгледуваат објектот за
4820појава на контролирачки настан
482152
4822Анализа и моделирање на барања
4823ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4824И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4825СОФТВЕРСКО ИНЖЕНЕРСТВО
4826CRC моделирање
4827 Class-responsibility-collaborator моделирање
4828 Index-cards
4829 class name
4830 class responsibilities (attributes and operations)
4831“anything the class knows or does”
4832 collaborators (други потребни класи за да ги дадат
4833потребните информации за класата да може да
4834одговори на своите одговорности)
483553
4836Анализа и моделирање на барања
4837ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4838И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4839СОФТВЕРСКО ИНЖЕНЕРСТВО
4840Index-cards
484154
4842Анализа и моделирање на барања
4843Class:
4844Des
4845Res aborat or:
4846Class:
4847De
4848ollaborat or:
4849Class:
4850D
4851Collaborat or:
4852Class FloorPlan :
4853Description
4854Responsibility: Collaborator:
4855Incorporates walls doors and windows , ,
4856Shows position of video cameras
4857Defines floor plan name type /
4858Manages floor plan positioning
4859Scales floor plan for display
4860Scales floor plan for display
4861Wall
4862Camera
4863ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4864И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4865СОФТВЕРСКО ИНЖЕНЕРСТВО
4866Класи
4867 Категории на класи:
4868 Entity classes (called model or business classes) –
4869екстрахирани директно од проблемот,
4870вообичаено работи кои се перзистентни за време
4871на извршување на апликацијата, вообичаено се
4872сместуваат во бази на податоци
4873 Boundary classes (гранични класи) – за креирање
4874на интерфејси, содржат информации кои му се
4875битни на корисникот, менаџираат со начинот на кој
4876ентитетните објекти се презентираат на
4877корисниците
4878 Controller classes (контролер класи) …
487955
4880Анализа и моделирање на барања
4881ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4882И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4883СОФТВЕРСКО ИНЖЕНЕРСТВО
4884Контролер класи
4885 Controller classes (контролер класи) –
4886менаџираат одредена работа (која треба да
4887се изведе) од почеток до крај (се дефинираат
4888во процесот на дизајн)
4889 креирање и промена на ентитетни објекти
4890 инстанцирање на гранични објекти при нивното
4891примање информации од ентитетните објекти
4892 комплексни комуникации помеѓу множества на
4893објекти
4894 валидација на податоците кои се проследуваат
4895помеѓу објектите или корисникот и објектите
489656
4897Анализа и моделирање на барања
4898ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4899И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4900СОФТВЕРСКО ИНЖЕНЕРСТВО
4901Одговорности
4902 Основни водилки за идентификација на
4903одговорностите
49041. Интелигенцијата на системот да биде дистрибуирана низ
4905класите така што најдобро ќе може да одговори на
4906предизвиците (“Dumb” / “Smart” classes)
49072. Одговорностите да бидат што погенерално поставени
49083. Информациите и однесувањето придружено со нив треба
4909да биде во иста класа (енкапсулација)
49104. Информациите за едно нешто треба да бидат
4911локализирани во една класа, а не дистрибуирани низ
4912повеќе
49135. Одговорностите треба да бидат делени помеѓу повеќе
4914класи каде што тоа е можно
491557
4916Анализа и моделирање на барања
4917ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4918И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4919СОФТВЕРСКО ИНЖЕНЕРСТВО
4920Колаборација –
4921Соработка меѓу класите
4922 Класите ги исполнуваат своите
4923одговорности на еден од два начини:
4924Со употреба на сопствените операции за
4925манипулација над атрибутите
4926Преку соработка со други класи
492758
4928Анализа и моделирање на барања
4929ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4930И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4931СОФТВЕРСКО ИНЖЕНЕРСТВО
4932Player
4933PlayerHead PlayerBody PlayerArms PlayerLegs
4934Релации помеѓу класите
4935 Три генерички релации:
4936is-part-of (UML aggregation)
4937has-knowledge-of
4938depends-upon
493959
4940Анализа и моделирање на барања
4941ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4942И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4943СОФТВЕРСКО ИНЖЕНЕРСТВО
4944Структурна анализа
4945 Во некои случаи посоодветно е системот да
4946се моделира разгледувајќи ги податоците и
4947процесите кои истите ги трансформираат
4948како посебни ентитети:
4949 Податочни објекти кои се трансформираат додека
4950се движат низ системот
4951 Како апликацијата се однесува како последица на
4952надворешните дејствија
4953 Збирка на трансформации кои се вршат на
4954податоците
495560
4956Анализа и моделирање на барања
4957ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4958И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4959СОФТВЕРСКО ИНЖЕНЕРСТВО
4960Data model
4961 Software = data processing
4962 + event processing
4963 Информацискиот домен содржи три различни погледи на
4964податоците и контролите:
49651. Information content - содржина и релации на информациите
4966(data model) – (индивидуални податоци и контролни објекти
4967како колекција од информации кои системот ги
4968трансформира) paycheck, system status
49692. Information flow - проток на информации (начинот на кој се
4970менуваат податоците и контролите кога минуваат низ
4971системот)
49723. Information structure - Структура на информации – интерна
4973организација на разни податочни и контролни структури (дали
4974да бидат организирани како матрица, дрво, дали
4975информациите да се чуваат во единствена структура или во
4976неколку одвоени поврзани структури, ...)
497761
4978Анализа и моделирање на барања
4979ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4980И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4981СОФТВЕРСКО ИНЖЕНЕРСТВО
4982Моделирање
4983Модели на
4984 функционирање
4985 однесување
4986Functional models
4987 најмалку 3 генерички функции: влез,
4988процесирање, излез
4989Behavioral models
4990 стимул/одѕив карактеристики (состојба на
4991програмата – чекање, процесирање,
4992печатење, ..., која се менува под дејство на
4993настан)
499462
4995Анализа и моделирање на барања
4996ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
4997И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
4998СОФТВЕРСКО ИНЖЕНЕРСТВО
4999Куса историја
5000 Почетоци: 70-ти и 80-ти години
5001 DeMarco (1979) – името: структурна анализа
5002и основни графички симболи и модели
5003 Page-Jones, Gane&Sarson и др. - варијации
5004 Методи фокусирани кон информациони
5005системи без соодветна нотација за
5006моделирање на контрола и однесување
5007 Real-time екстензии (Ward & Mellor, Hartley &
5008Pirbhai)
5009Анализа и моделирање на барања
501063
5011ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5012И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5013СОФТВЕРСКО ИНЖЕНЕРСТВО
5014Елементи на моделот за анализа
5015State-transition
5016diagram
5017Entity
5018relationship
5019diagram
5020Data flow
5021diagram
5022Data dictionary
5023Control specification
5024Process specification
5025(PSPEC)
5026Data
5027object description
5028Анализа и моделирање на барања
502964
5030ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5031И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5032СОФТВЕРСКО ИНЖЕНЕРСТВО
5033Елементи на моделот за анализа
5034Data dictionary – описи на сите објекти кои се користат во моделот
5035Три различни дијаграми:
5036 Entity relationship diagram (ERD) – data modeling activity – ги
5037опишува релациите помеѓу објектите
5038 атрибутите на секој објект се опишани во DOD (data object
5039description)
5040 Data flow diagram (DFD) – со две цели:
50411. како податоците се трансформираат при нивното движење низ
5042системот
50432. да ги опише функциите кои ги трансформираат податоците
5044 описите на функциите од DFD се презентираат во PSPEC (process
5045specification)
5046 State transition diagram (STD) – го опишува однесувањето на
5047системот како последица на надворешни настани
5048 претставува различни модалитети на однесување (состојби) и
5049начинот на кој се преминува од една во друга состојба
5050 дополнителни детали за контролните аспекти се содржани во
5051CSPEC (control specification)
5052Анализа и моделирање на барања
505365
5054ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5055И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5056СОФТВЕРСКО ИНЖЕНЕРСТВО
5057Релации
5058 Податочните објекти може да бидат поврзани со
5059други објекти на различни начини
5060 Релацијата го претставува видот на поврзаност
5061 Врската во објект/релација паровите е двонасочна
5062Book Bookstore
5063Book Bookstore Stocks
5064Displays
5065Orders
5066Sells
5067Returns
5068Анализа и моделирање на барања
506966
5070ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5071И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5072СОФТВЕРСКО ИНЖЕНЕРСТВО
5073Кардиналност на релација
5074 Обичната релација (X е во релација со Y)
5075често не обезбедува доволно информации за
5076поврзаноста на објектите од аспект на
5077софтверското инженерство
5078 Кардиналност – го дефинира максималниот
5079број на објекти кои може да учествуваат во
5080релација. Искажува колку појави на објектот
5081X се поврзани со колку појави на објектот Y.
5082(Колку = еден или повеќе). Може да биде:
5083 1:1 (еден спрема еден)
5084 1:N (еден спрема многу)
5085 M:N (многу спрема многу)
5086Анализа и моделирање на барања
508767
5088ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5089И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5090СОФТВЕРСКО ИНЖЕНЕРСТВО
5091Модалност на релација
5092 Модалноста на дадена релација е 0
5093доколку нема експлицитна потреба
5094релацијата да постои или истата е
5095опциона
5096 Модалноста на дадена релација е 1 ако
5097појавата на релацијата е задолжителна
5098Анализа и моделирање на барања
509968
5100ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5101И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5102СОФТВЕРСКО ИНЖЕНЕРСТВО
5103Графичка претстава
5104 Објектите се претставуваат со
5105правоаголници
5106Атрибутите во вид на табела за објектот
5107или во елипси под објектот
5108 Релациите се именувани линии кои ги
5109поврзуваат објектите (или се
5110прокажуваат како ромб на линијата)
5111 Кардиналноста и модалноста се
5112прикажуваат до излезот на линијата од
5113објектот
5114Анализа и моделирање на барања
511569
5116ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5117И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5118СОФТВЕРСКО ИНЖЕНЕРСТВО
5119ERD дијаграми (алтернативни прикази)
5120object object relationship 1 2
5121(0:m)
5122(1:1)
5123object1 object2
5124relationship
5125attribute
5126Анализа и моделирање на барања
512770
5128ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5129И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5130СОФТВЕРСКО ИНЖЕНЕРСТВО
5131Графичка претстава на
5132кардиналноста и модалноста
5133customer Repair action
5134Cardinality Cardinality
5135Modality Modality
5136Is provided with
5137Анализа и моделирање на барања
513871
5139ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5140И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5141СОФТВЕРСКО ИНЖЕНЕРСТВО
5142Графичка претстава
5143 Симболите поблиску до објектите ја означуваат
5144кардиналноста, а оние подалеку - модалноста
5145manufacturer builds car
5146ID#
5147Data object table
5148Model Body type Engine Transmission • • •
5149Анализа и моделирање на барања
515072
5151ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5152И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5153СОФТВЕРСКО ИНЖЕНЕРСТВО
5154ERD пример 1
5155 A customer indicates that there is a problem. If the
5156problem is diagnosed as relatively simple, a single repair
5157action occurs. However, if the problem is complex,
5158multiple repair actions may be required.
5159Customer Repair action is provided with
5160Cardinality:
5161Implies that a single
5162customer awaits repair action(s)
5163Cardinality:
5164Implies that there may be
5165many repair action(s)
5166Modality: Mandatory
5167Implies that in order to
5168have a repair action(s),
5169we must have a customer
5170Modality: Optional
5171Implies that there may
5172be a situation in which a
5173repair action is not necessary
5174Анализа и моделирање на барања
517573
5176ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5177И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5178СОФТВЕРСКО ИНЖЕНЕРСТВО
5179ERD пример 2
5180Manufacturer Builds Car
5181Licenses Dealership Stocks
5182Contracts Transports
5183Shipper
5184Анализа и моделирање на барања
518574
5186ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5187И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5188СОФТВЕРСКО ИНЖЕНЕРСТВО
5189ERD пример 3
5190(1:1) (1:m)
5191Customer places request
5192for service
5193generates (1:n)
5194(1:1)
5195work
5196order
5197work
5198tasks
5199materials
5200consists
5201of
5202lists
5203(1:1)
5204(1:w)
5205(1:i)
5206selected
5207from
5208standard
5209task table
5210(1:w)
5211(1:1)
5212(0:1)
5213Анализа и моделирање на барања
521475
5215ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5216И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5217СОФТВЕРСКО ИНЖЕНЕРСТВО
5218Data object type hierarchies
5219 Освен ERD може да се приложи и DO
5220хиерархија
5221Car
5222European U.S. Asian
5223Swedish German Italian French/
5224English Japanese Korean
5225Анализа и моделирање на барања
522676
5227ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5228И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5229СОФТВЕРСКО ИНЖЕНЕРСТВО
5230Associative data object
5231 ERD нотацијата нуди и механизам со кој
5232може да се прикаже и асоцијацијата
5233помеѓу објекти
5234Electronics
5235Car
5236Engine Chassis Interior Drive train
5237Анализа и моделирање на барања
523877
5239ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5240И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5241СОФТВЕРСКО ИНЖЕНЕРСТВО
5242Прашања?
524378
5244Анализа и моделирање на барања
5245___________________________________________________________________________________________________________________
5246Дизајнирање:
5247концепти и принципи
5248Дизајн
5249 Воден од креативност – местото каде што се
5250сретнуваат корисничките барања и техничките
5251ограничувања во формулација на продукт или систем
5252 Репрезентација на моделот на софтвер но сега од
5253аспект на архитектура на софтверот, податочни
5254структури, интерфејси и компоненти
5255 Дизајнот се проверува за грешки, неконзистентности,
5256пропусти, се проценува дали можеби постојат
5257подобри алтернативи, и дали може да биде
5258имплементиран со зададените ограничувања,
5259ресурси и временска рамка
52602
5261Дизајнирање
5262ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5263И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5264СОФТВЕРСКО ИНЖЕНЕРСТВО
5265Добар дизајн
5266 „Добро дизајнираните градби треба да
5267се одликуваат со цврстина, вредност и
5268задоволство“ (Vitruvius)
5269 цврстина – да нема грешки кои би го
5270спречиле во неговата функција
5271 вредност – соодветен на целите на кои
5272е наменет
5273 задоволство – неговото користење
5274треба да е позитивно искуство
52753
5276Дизајнирање
5277ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5278И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5279СОФТВЕРСКО ИНЖЕНЕРСТВО
5280Дизајн
5281 Дизајнот претставува смислена инженериска
5282репрезентација на нешто што треба да биде
5283изградено.
5284 Во секој процес на дизајнирање постојат две главни
5285фази диверзификација и конвергенција
5286 диверзификација – аквизиција на репертоар од
5287алтернативи и градбениот материјал на дизајнот
5288(компоненти, решенија, знаење од каталози, книги,
5289искуство, хевристика, ...)
5290 конвергенција – избор и комбинирање на соодветни
5291елементи од репертоарот со цел да се задоволат
5292целите на дизајнот според барањата, критериуми кои
5293овозможуваат проценка на квалитетот
5294 Елиминација на сите освен една конфигурација на
5295компоненти според која ќе биде изработен
5296финалниот продукт во итеративен пристап кој води
5297кон финалниот дизајн
5298Дизајнирање
52994
5300ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5301И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5302СОФТВЕРСКО ИНЖЕНЕРСТВО
5303Дизајнирање
5304 Дизајнот треба да може да се следи до
5305барањата на клиентот и истовремено да
5306може да му се процени квалитетот според
5307предефинирани критериуми за „добар“
5308дизајн.
5309 Во контекст на софтверското инженерство
5310дизајнирањето се фокусира на:
5311 податоци (шаблони, ...)
5312 архитектура (шаблони, ...)
5313 интерфејси (ергономија)
5314 компоненти (програмирање)
5315Дизајнирање
53165
5317ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5318И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5319СОФТВЕРСКО ИНЖЕНЕРСТВО
5320Важност на дизајнот
5321 Зошто е важен дизајнот?
5322 Поаѓа од моделот на барања
5323 Негов „производ“ е спецификација за дизајнот кој
5324опфаќа дизајнерски модели за опис на податоците,
5325архитектурата, интерфејсите и компонентите.
5326 Во секоја фаза продуктите на дизајнерскиот процес
5327се ревидираат за јасност, коректност, комплетност и
5328конзистентност во однос на барањата и меѓусебно.
5329 Софтверскиот дизајн ја нема „длабочината“,
5330флексибилноста и квантитавниот пристап
5331карактеристичен за други инженериски дисциплини.
5332Дизајнирање
53336
5334ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5335И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5336СОФТВЕРСКО ИНЖЕНЕРСТВО
5337Софтверски дизајн
5338 Софтверскиот дизајн е првата од трите
5339технички активности (дизајн, кодирање,
5340тестирање) кои се потребни за да се направи
5341и тестира софтверот.
5342 Моделите за анализа ги обезбедуваат
5343неопходните информации потребни за
5344градење на четирите дизајн модели:
5345 податочен дизајн (data design)
5346 архитектонски дизајн (architectural design)
5347 дизајн на интерфејси (interface design)
5348 дизајн на компоненти (component-level design)
5349Дизајнирање
53507
5351ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5352И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5353СОФТВЕРСКО ИНЖЕНЕРСТВО
5354Преведување на моделот за анализа
5355во софтверски дизајн
5356ion pt i cr
5357es dt c
5358je bo
5359ta
5360aD
5361Control specification (CSPEC)
5362Process specificatio
5363n (PS
5364PEC
5365relationship
5366diagram
5367Data flow
5368diagram
5369Data
5370Dictionary
5371Interface
5372design
5373Componentlevel
5374design
5375Architectural
5376design
5377Data
5378design
5379The analysis model The design model
5380State-transition
5381diagram
5382Дизајнирање
53838
5384ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5385И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5386СОФТВЕРСКО ИНЖЕНЕРСТВО
5387Преведување на моделот за
5388анализа во модел за дизајн
53899
5390Дизајнирање
5391Data/Class Design
5392Architectural Design
5393Interface Design
5394Use cases - text
5395Use-case diagrams
5396Activity diagrams
5397Swimlane diagrams
5398Data flow diagrams
5399Control-flow diagrams
5400Processing narratives
5401State diagrams
5402Sequence
5403diagrams
5404Class diagrams
5405Analysis packages
5406CRC models
5407Collaboration diagrams
5408Flow-oriented
5409elements
5410Behavioral
5411elements
5412Class-based
5413elements
5414Scenerio-based
5415elements
5416Component-Level
5417Design
5418Analysis Model
5419ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5420И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5421СОФТВЕРСКО ИНЖЕНЕРСТВО
5422Дизајн на податоци
5423 Дизајнот на податоци (data design - DD)
5424ги трансформира информациите од
5425податочното моделирање од процесот
5426на анализа во податочни структури
5427потребни за имплементација на
5428софтверот користејќи ги ERD и Data
5429Dictionary.
5430 Дел од DD се појавува и при дизајнот на
5431софтверската архитектура и дизајнот на
5432компонентите.
5433Дизајнирање
543410
5435ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5436И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5437СОФТВЕРСКО ИНЖЕНЕРСТВО
5438Дизајн на архитектура
5439 Архитектурата ги дефинира релациите
5440помеѓу главните структурни елементи на
5441софтверот и „шаблоните за дизајн“ кои може
5442да се употребат за да се задоволат
5443поставените барања како и ограничувањата
5444кои условуваат кои шаблони за дизајн може
5445да се употребат
5446 Софтверската архитектурата ја дефинира
5447рамката на системот која произлегува од
5448спецификацијата на системот, моделот за
5449анализа и интеракцијата на подсистемите
5450дефинирани во процесот на анализа
5451Дизајнирање
545211
5453ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5454И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5455СОФТВЕРСКО ИНЖЕНЕРСТВО
5456Дизајн на интерфејси
5457 Интерфејсите го дефинираат начинот
5458на кои софтверските компоненти
5459комуницираат меѓу себе, со системите
5460со кои комуницира и со луѓето кои го
5461користат.
5462 DFD и CFD ги содржат најголем дел од
5463информациите потребни за дизајн на
5464интерфејсите
5465Дизајнирање
546612
5467ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5468И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5469СОФТВЕРСКО ИНЖЕНЕРСТВО
5470Дизајн на компоненти
5471 Дизајнот на компоненти ги
5472трансформира структурните елементи
5473на софтверската архитектура во
5474процедурален опис на софтверски
5475компоненти.
5476 Деталните информации добиени од
5477PSPEC, CSPEC и STD се користат како
5478основа при дизајнот на компонентите
5479Дизајнирање
548013
5481ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5482И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5483СОФТВЕРСКО ИНЖЕНЕРСТВО
5484Зошто е важен дизајнот?
5485 Квалитетот на крајниот продукт (софтверот)
5486многу зависи од дизајнот.
5487 При дизајнирањето се носат одлуки кои
5488значително влијаат на успешноста на
5489конструкцијата на софтверот како и на
5490неговото понатамошно (лесно) одржување
5491 Дизајнот овозможува репрезентација на
5492софтверот во која може да се процени
5493неговиот квалитет уште пред да биде
5494направен!
5495Дизајнирање
549614
5497ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5498И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5499СОФТВЕРСКО ИНЖЕНЕРСТВО
5500Дизајнирање во нивоа
5501 Дизајнот претставува итеративен процес во кој
5502барањата се преведуваат во план за конструкција
5503(реализација) на софтверот.
5504 Планот претставува холистички поглед на софтверот
5505(системот) - дизајнот е претставен на високо ниво на
5506апстракција на кое лесно може да се следи
5507специфичната цел на системот како и подеталните
5508податочни, функционални и барања на однесување.
5509 Низ итерациите дизајнот се детализира кон сè
5510пониски нивоа на апстракција од кои сè уште може да
5511се следи патеката до поедините барања (иако оваа
5512врска станува посуптилна)
5513Дизајнирање
551415
5515ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5516И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5517СОФТВЕРСКО ИНЖЕНЕРСТВО
5518Контрола на квалитет
5519 Во тек на процесот на дизајнирање
5520квалитетот на дизајнот кој се развива
5521континуирано се контролира (технички
5522прегледи, проверки на дизајнот, ...) при што
5523следните три карактеристики се главните
5524водилки кон добар дизајн:
5525 дизајнот мора да ги задоволи сите експлицитни
5526(содржани во моделот) и имплицитни (од
5527клиентот) барања
5528 дизајнот мора да биде разбирлив за оние кои (ќе)
5529го генерираат кодот, тестираат и одржуваат кодот
5530 дизајнот треба да пружи комплетна слика на
5531софтверот од аспект на податочниот,
5532функционалниот и доменот на однесување од
5533имплементациска перспектива
5534Дизајнирање
553516
5536ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5537И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5538СОФТВЕРСКО ИНЖЕНЕРСТВО
5539Проценка на квалитетот на дизајнот
5540 За успешна проценка на квалитетот на
5541дизајнот неопходно е да се воспостават
5542одредени технички критериуми за добар
5543дизајн.
5544 Дизајнот треба да:
55451. има добра архитектонска структура
55461) креиран со употреба на препознатливи шаблони за
5547дизајн
55482) составен од компоненти кои имаат добри дизајнерски
5549карактеристики
55503) може да биде имплементиран во еволутивен пристап
55512. да е модуларен (логично поделен на елементи
5552кои реализираат специфични функции и
5553подфункции)
5554Дизајнирање
555517
5556ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5557И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5558СОФТВЕРСКО ИНЖЕНЕРСТВО
5559Проценка на квалитетот на дизајнот
55603. да содржи јасна репрезентација на податоците,
5561архитектурата, интерфејсите и компонентите
5562(модулите)
55634. да води кон податочни структури соодветни на
5564објектите кои треба да се имплементираат,
5565изведени од познати податочни шаблони
55665. да води кон компоненти кои се карактеризираат
5567со независни функционални карактеристики
55686. да води кон интерфејси кои ја намалуваат
5569комплексноста на поврзаноста помеѓу модулите
5570и кон надворешниот свет
55717. да биде изведен низ итеративен процес воден
5572од информациите добиени од процесот на
5573анализа на барања
5574Дизајнирање
557518
5576ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5577И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5578СОФТВЕРСКО ИНЖЕНЕРСТВО
5579Еволуција на софтверски дизајн
5580 Критериуми за развој на модуларни
5581програми (структурирано
5582програмирање)
5583 Преведување на DFD и податочни
5584структури во дизајн
5585 Објектно ориентиран пристап
5586 Денес акцентот се става на
5587софтверските архитектури
5588Дизајнирање
558919
5590ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5591И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5592СОФТВЕРСКО ИНЖЕНЕРСТВО
5593Атрибути на квалитет
5594 Functionality – функционалност
5595 Usability – употребливост
5596 Reliability – сигурност
5597 Performance – перформанси
5598 Supportability - поддршка
5599extensibility+maintainability
5600(проширување/одржување)
560120
5602Дизајнирање
5603ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5604И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5605СОФТВЕРСКО ИНЖЕНЕРСТВО
5606Методи за дизајн на софтвер
5607 Постојат различни методи за дизајн на
5608софтвер
5609 Заеднички карактеристики им се:
56101. механизам за преведување на моделот
5611за анализа во репрезентација на дизајнот
56122. нотација за претстава на функционалните
5613компоненти и нивните интерфејси
56143. хевристика за рафинирање и поделба
56154. сугерирани начини за проверка на
5616квалитет
5617Дизајнирање
561821
5619ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5620И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5621СОФТВЕРСКО ИНЖЕНЕРСТВО
5622Принципи за дизајн (1)
5623 Дизајнот на софтвер е и процес и
5624модел
5625процес – секвенца на чекори кои му
5626овозможуваат на дизајнерот да ги опише
5627сите аспекти на софтверот кој треба да се
5628направи (креативност, искуство, шаблони,
5629водење од квалитет)
5630модел – еквивалент на архитектонскиот
5631план за градба – го изразува глобалниот
5632поглед на целиот софтвер
5633Дизајнирање
563422
5635ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5636И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5637СОФТВЕРСКО ИНЖЕНЕРСТВО
5638Принципи за дизајн (2)
5639 Основните принципи за дизајн треба да
5640обезбедат навигација низ процесот на дизајн:
5641 Да не се ограничиме на “tunnel vision” - да се
5642разгледаат и алтернативни пристапи
5643 Да може да се трасира до моделот за анализа
5644 Да не се измислува „топла вода“
5645 Колку што е можно да ја следи структурата на
5646проблемот во реалниот свет
5647 Униформност (конзистентен стил, формат, ознаки)
5648и интеграција (водење грижа за дефинирање на
5649интерфејсите помеѓу компонентите)
5650Дизајнирање
565123
5652ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5653И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5654СОФТВЕРСКО ИНЖЕНЕРСТВО
5655Принципи за дизајн (3)
5656Структурирана организација кој
5657овозможува промени
5658Организација која ќе обезбеди „нежно“
5659откажување во непредвидени ситуации
5660Дизајнот не е кодирање, кодирањето не е
5661дизајн
5662Квалитетот на дизајнот треба
5663континуирано да се проценува
5664Преглед (ревизија) на дизајнот со цел да
5665се минимизираат концептуалните грешки
5666Дизајнирање
566724
5668ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5669И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5670СОФТВЕРСКО ИНЖЕНЕРСТВО
5671Екстерни и интерни фактори за
5672квалитет
5673 Екстерни фактори за квалитет –
5674карактеристики на софтверот кои можат
5675непосредно да бидат забележани од
5676корисниците (брзина, сигурност,
5677точност, корисност, лесна употреба, ...)
5678 Интерни фактори за квалитет – висок
5679квалитет на дизајн од техничка
5680перспектива
5681Дизајнирање
568225
5683ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5684И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5685СОФТВЕРСКО ИНЖЕНЕРСТВО
5686Концепти на дизајн (1)
5687 Основните концепти за дизајнот му помагаат
5688на софтверскиот инженер да одговори на
5689следниве прашања:
5690 Кои критериуми да се употребат за да се изврши
5691поделба на софтверот на индивидуални
5692компоненти?
5693 На кој начин функционалните и податочни детали
5694за софтверот да се одвојат од концептуалната
5695репрезентација на софтверот?
5696 Кој критериум го дефинира техничкиот квалитет
5697на софтверскиот дизајн?
5698Дизајнирање
569926
5700ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5701И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5702СОФТВЕРСКО ИНЖЕНЕРСТВО
5703Концепти на дизајн (2)
5704 “The beginning of wisdom [for a software
5705engineer] is to recognize the difference
5706between getting a program to work, and
5707getting it right“ (M. A. Jackson)
5708 Фундаменталните концепти на
5709софтверскиот дизајн ја обезбедуваат
5710потребната рамка за ова да се направи
5711на „вистинскиот начин“.
5712Дизајнирање
571327
5714ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5715И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5716СОФТВЕРСКО ИНЖЕНЕРСТВО
5717Основни концепти за дизајн
5718 Апстракција
5719 Рафинирање
5720 Модуларност
5721 Софтверски архитектури
5722 Контролна хиерархија
5723 Структурна поделба
5724 Податочни структури
5725 Софтверски процедури
5726 Сокривање на информациите
5727Дизајнирање
572828
5729ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5730И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5731СОФТВЕРСКО ИНЖЕНЕРСТВО
5732Апстракција
5733 Апстракција му овозможува на дизајнерот
5734да се фокусира на решавање на проблемот
5735без да се осврнува на ирелевантните
5736детали (на пониските нивоа)
5737 Различни нивоа на апстракција – на повисоките
5738нивоа решението се опишува со изрази соодветни на
5739доменот на проблемот, најниското ниво е изворниот
5740код. Постепен премин од проблемски ориентирана
5741кон имплементациски ориентирана терминологија
5742 Процедурална апстракција – именувана секвенца на
5743инструкции кои имаат точно одредена функција
5744 Податочна апстракција – именувана колекција на
5745податочни објекти
5746 Контролна апстракција – се однесува на контролата
5747на програмата без специфицирање на интерните
5748детали
5749Дизајнирање
575029
5751ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5752И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5753СОФТВЕРСКО ИНЖЕНЕРСТВО
5754Рафинирање (прочистување)
5755 Постепеното прочистување претставува
5756top-down стратегија за дизајн според
5757која програмата се развива преку
5758сукцесивно рафинирање на
5759процедуралните детали (N. Wirth)
5760 Рафинирањето е процес на
5761елаборација кој му помага на
5762дизајнерот да ги открива деталите на
5763пониските нивоа во текот на
5764напредувањето на дизајнот
5765Дизајнирање
576630
5767ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5768И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5769СОФТВЕРСКО ИНЖЕНЕРСТВО
5770Апстракција ↔ Рафинирање
5771 Апстракцијата и рафинирањето се
5772комплементарни концепти
5773Апстракцијата му овозможува на
5774дизајнерот специфицирање на
5775процедурите и податоците игнорирајќи ги
5776имплементациските детали
5777Рафинирањето му помага на дизајнерот да
5778ги открие деталите како што
5779дизајнирањето напредува
5780Дизајнирање
578131
5782ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5783И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5784СОФТВЕРСКО ИНЖЕНЕРСТВО
5785Separation of concerns
5786 C(x) - комплексност на проблемот x
5787 E(x) – напор (време) потребно да се реши
5788проблемот x
5789 C(p1) > C(p2) ⇒ E(p1) > E(p2)
5790 C(p1 + p2) > C(p1) + C(p2)
5791 E(p1 + p2) > E(p1) + E(p2)
5792 заклучок: раздели и владеј – главен аргумент
5793за модуларност
5794 со поделбата на подпроблеми не може да се
5795оди во бесконечност!
5796Дизајнирање
579732
5798ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5799И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5800СОФТВЕРСКО ИНЖЕНЕРСТВО
5801Модуларност (1)
5802 Најчеста манифестација на Separation of
5803concerns принципот
5804 Поделба на софтверот на индивидуални
5805именувани и адресабилни компоненти
5806наречени модули кои се интегрираат со цел
5807да се задоволат проблемските барања.
5808 Модуларноста е основниот атрибут на
5809софтверот кој овозможува одржување и
5810интелектуално менаџирање на сложени
5811системи
5812 Монолитен софтвер
5813Дизајнирање
581433
5815ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5816И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5817СОФТВЕРСКО ИНЖЕНЕРСТВО
5818Модуларност (2)
5819M
5820Region of minimum
5821cost
5822Number of modules
5823Cost to integrate
5824Total software cost
5825Cost / module
5826Cost or effort
5827Дизајнирање
582834
5829ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5830И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5831СОФТВЕРСКО ИНЖЕНЕРСТВО
5832Модуларност (4)
5833 Критериуми за евалуација на метод за
5834дизајн од аспект на модуларноста:
5835 Modular decomposability.
5836 Modular composability.
5837 Modular understandability.
5838 Modular continuity. (effects of changes)
5839 Modular protection. (effects of errors)
5840Information Hiding
5841Functional Independence
5842Дизајнирање
584335
5844ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5845И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5846СОФТВЕРСКО ИНЖЕНЕРСТВО
5847Софтверска архитектура (1)
5848 Софтверската архитектура се однесува
5849на глобалната структура на софтверот
5850и начинот на кој оваа структура го
5851обезбедува концептуалниот интегритет
5852на системот.
5853 Во поедноставена форма претставува
5854(хиерархиска) структура на програмски
5855компоненти (модули), начинот на кој
5856истите комуницираат и структурата на
5857податоците кои ги користат
5858Дизајнирање
585936
5860ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5861И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5862СОФТВЕРСКО ИНЖЕНЕРСТВО
5863Софтверска архитектура (2)
5864 Една од целите е да ја даде појдовната
5865архитектонска шема на системот која ќе
5866служи како рамка за детални дизајнерски
5867активности
5868Особини кои се дел од архитектонскиот дизајн:
5869 Структурни особини (модули, објекти,
5870филтри)
5871 Екстра-функционални особини
5872(перформанси, капацитет, сигурност,
5873адаптибилност, ...)
5874 Фамилијарност со слични системи (design
5875patterns, reusability)
5876Дизајнирање
587737
5878ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5879И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5880СОФТВЕРСКО ИНЖЕНЕРСТВО
5881Архитектонски дизајн
5882 За дадени спецификации за бараните особини на
5883системот архитектонскиот дизајн може да биде
5884претставен со еден или повеќе модели како:
5885 Структурни модели (колекција на програмски компоненти)
5886 Рамковни модели (апстракција со цел идентификација на
5887повторливи шаблони за архитектонски дизајн)
5888 Динамички модели (однесување на системот и како тоа
5889влијае на промена на структурата на системот)
5890 Процесни модели (дизајн на бизнис или технички процес)
5891 Функционални модели (функционална хиерархија на
5892системот)
5893 Јазици за опис на архитектури - architectural
5894description languages (ADLs)
5895Дизајнирање
589638
5897ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5898И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5899СОФТВЕРСКО ИНЖЕНЕРСТВО
5900Design model
5901 Data Design Elements
5902 Architectural Design Elements
5903 Interface Design Elements
5904 Component-Level Design Elements
5905 Deployment-Level Design Elements
590641
5907Дизајнирање
5908ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5909И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5910СОФТВЕРСКО ИНЖЕНЕРСТВО
5911Software design specification
5912 Дефинирање на делокругот на дизајн процесот
5913 Спецификација на податочниот дизајн (DB, file structures, internal data
5914structures and cross reference)
5915 Приказ на начинот на кој дизајнот на програмската архитектура е
5916изведен од моделот за анализа + дополнителни структурни шеми
5917 Дизајн на екстерни и интерни програмски интерфејси + GUI
5918 Наративен опис на индивидуалните програмски компоненти
5919 Requirements cross reference (матрица)
5920 да се обезбеди дека сите барања се задоволени со софтверскиот дизајн
5921 да се означи кои компоненти се критични за имплементацијата на
5922специфичните барања
5923 Документација за тестирање (на индивидуалните модули и
5924интеграцијата) или во одвоена спецификација на процедури за
5925тестирање
5926 Дизајнерски ограничувања (меморија, специјален интерфејс, ...)
5927 Дополнителни информации (опис на алгоритми, алтернативни
5928процедури, други документи, ...)
5929Дизајнирање
593042
5931ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5932И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5933СОФТВЕРСКО ИНЖЕНЕРСТВО
5934Прашања?
593543
5936Дизајнирање
5937____________________________________________________________________________________________________________________________
5938Софтверски
5939архитектури
5940Дизајн
5941 Целта на дизајнирањето е да изгради
5942кохерентна, добро испланирана
5943репрезентација на програмите која се
5944концентрира на релациите на нејзините
5945делови
5946 Дизајнирањето е водено од
5947информациите
5948 Систематски пристап кон изведувањето
5949на архитектонски дизајн
5950Софтверски архитектури
59512
5952ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5953И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5954СОФТВЕРСКО ИНЖЕНЕРСТВО
5955Архитектонски дизајн
5956 Архитектонскиот дизајн ја репрезентира
5957структурата на податочните и
5958програмски компоненти потребни за
5959изградба на компјутерскиот систем
5960 Го разгледува архитектонскиот стил,
5961структурата и карактеристиките на
5962компонентите кои ќе го сочинуваат
5963системот, и релациите помеѓу
5964архитектонските компоненти на
5965системот
59663
5967Софтверски архитектури
5968ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5969И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5970СОФТВЕРСКО ИНЖЕНЕРСТВО
5971Архитектура
5972 data architecture - database or data warehouse
5973designer
5974 архитект на бази на податоци
5975 system architecture - system architect
5976 системски архитект – избира архитектонски стил
5977според потребите собрани во фазата на
5978requirements engineering
5979 обезбедува целосна слика на интерната
5980структура на системот пред да се посветиме
5981на детелите
59824
5983Софтверски архитектури
5984ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
5985И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
5986СОФТВЕРСКО ИНЖЕНЕРСТВО
5987Што е архитектура?
5988 Форма (стил) на физичка структура
5989 Начинот на кој компонентите се интегрирани
5990во една кохерентна функционална целина
5991 Начинот на кој структурата се вклопува во
5992околната
5993 Начинот на кој ја задоволува својата основна
5994цел, функционалност при задоволувањето на
5995потребите на човекот
5996 Естетското чувство за структурата – визуелно
5997влијание (детали – осветлување, мебел, ...)
5998 Конечно, тоа е еден вид уметност
5999Софтверски архитектури
60005
6001ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6002И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6003СОФТВЕРСКО ИНЖЕНЕРСТВО
6004Софтверска архитектура
6005 Софтверската архитектура на програма (или
6006компјутерски систем) ја претставува
6007структурата на системот кој е составен од
6008софтверски компоненти, екстерно видливите
6009карактеристики на овие компоненти и
6010нивните меѓусебни релации.
6011 Софтверската архитектура
6012 е опис на структурата на системот
6013 е првиот артефакт кој може да се анализира за да
6014се утврди квалитетот
6015 служи како појдовен план (шема)
6016 е опис на релациите помеѓу компонентите и
6017нивната поврзаност
6018Софтверски архитектури
60196
6020ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6021И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6022СОФТВЕРСКО ИНЖЕНЕРСТВО
6023Што е софтверската архитектура?
6024 Софтверската архитектура не е „оперативен“
6025систем. Таа е репрезентација на системот која на
6026софтверскиот инженер му овозможува:
60271. Да врши анализа дали дизајнот ги задоволува
6028поставените барања
60292. Да разгледа алтернативни архитектури во фаза
6030кога правењето измени во дизајнот е сè уште
6031релативно лесно
60323. Да го намали ризикот придружен со изградбата на
6033софтверот
6034Архитектонскиот дизајн се фокусира на
6035репрезентацијата на структурата на софтверските
6036компоненти нивните особини и интеракции.
6037Софтверски архитектури
60387
6039ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6040И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6041СОФТВЕРСКО ИНЖЕНЕРСТВО
6042Софтверски компоненти
6043 Софтверските компоненти се основните градбени
6044блокови на архитектурата
6045 Можат да бидат едноставни програмски модули, ОО
6046класи, БП, middleware, ...
6047 Особини на софтверските компоненти ги
6048претставуваат нивните карактеристиките неопходни
6049за да се разбере начинот на кој тие „се поврзуваат“
6050(interact) со останатите компоненти
6051 На ниво на СА нивните интерни особини (алгоритам)
6052не се специфицирани – не се разгледуваат
6053 Според Kazmann дизајнот е инстанца на архитектура
6054(како што објект е инстанца на класа во ООП)
6055Софтверски архитектури
60568
6057ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6058И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6059СОФТВЕРСКО ИНЖЕНЕРСТВО
6060Зошто е важна архитектурата?
6061 Овозможува комуникација помеѓу инволвираните во
6062изработката на системот
6063 Ги истакнува раните одлуки за дизајн кои ќе имаат
6064големо влијание на целата работа на софтверскиот
6065инженер која следи како и на конечната успешност на
6066системот
6067 Овозможува прифатлив, релативно едноставен
6068модел на структурата на системот и начинот на кој
6069функционираат компонентите во него (како целина)
6070Архитектонскиот дизајн и архитектонските шаблони
6071се преносливи (применливи и при дизајнирање на
6072други системи)
6073Софтверски архитектури
60749
6075ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6076И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6077СОФТВЕРСКО ИНЖЕНЕРСТВО
6078Developing
6079Organization’s
6080Management
6081Stakeholder
6082Marketing
6083Stakeholder
6084End User
6085Stakeholder
6086Customer
6087Stakeholder
6088Maintenance
6089Organization
6090Stakeholder
6091Architect
6092Low cost,
6093keeping
6094people
6095employed!
6096Neat features, short
6097time to market, low
6098cost, parity with
6099competing products!
6100Behavior,
6101performance,
6102security,
6103reliability!
6104Modifiability
6105!
6106Low cost,
6107timely delivery,
6108not changed
6109very often!
6110Ohhhhh
6111…
6112Софтверски архитектури
611310
6114ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6115И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6116СОФТВЕРСКО ИНЖЕНЕРСТВО
6117Architectural Description
6118 Architectural Description – опис на архитектура
6119– колекција на сите продукти кои
6120документираат архитектура
6121 IEEE-Std-1471-2000 - IEEE Recommended
6122Practice for Architectural Description for
6123Software-Intensive Systems
6124 воспоставување на концептуална рамка и речник
6125кои ќе се користат при развојот на архитектурата
6126 да обезбеди водилки за репрезентација на описот
6127на архитектурата
6128 да охрабри стабилни практики во архитектонскиот
6129дизајн
613011
6131Софтверски архитектури
6132ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6133И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6134СОФТВЕРСКО ИНЖЕНЕРСТВО
6135Архитектонски одлуки
6136 Архитектура – тоа се илјадници одлуки
6137(големи и мали) кои може да имаат
6138одлучувачко влијание за следните
6139акции во конструкцијата и успешноста
6140на целиот систем
6141 Погледи
6142 stakeholder concerns
6143 разгледување на алтернативи
6144 документирање на главните одлуки
614512
6146Софтверски архитектури
6147ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6148И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6149СОФТВЕРСКО ИНЖЕНЕРСТВО 13
6150Софтверски архитектури
6151ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6152И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6153СОФТВЕРСКО ИНЖЕНЕРСТВО
6154Архитектонски жанрови
6155 Artificial intelligence
6156 Commercial and nonprofit
6157 Communications
6158 Content authoring
6159 Devices
6160 Entertainment and sports
6161 Financial
6162 Games
6163 Government
616414
6165Софтверски архитектури
6166 Industrial
6167 Legal
6168 Medical
6169 Military
6170 Operating systems
6171 Platforms
6172 Scientific
6173 Tools
6174 Transportation
6175 Utilities
6176ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6177И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6178СОФТВЕРСКО ИНЖЕНЕРСТВО
6179Архитектонски стилови
6180 Архитектонскиот стил ја одредува
6181категоријата на системот што вклучува
6182 множество на компоненти кои изведуваат
6183одредени функции на системот (DB, пресметковни
6184модули, ...)
6185 множество на врски кои овозможуваат
6186комуникација, координација и кооперација помеѓу
6187компонентите
6188 ограничувања кои ги дефинираат начините на кои
6189компонентите може да се интегрираат во системот
6190 семантички модел кој му овозможува на
6191дизајнерот да ги разбере глобалните особини на
6192системот преку анализа на особините на неговите
6193делови
6194 Поделба на архитектонските стилови
6195Софтверски архитектури
619615
6197ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6198И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6199СОФТВЕРСКО ИНЖЕНЕРСТВО
6200Архитектонски шаблони
6201 Опсегот на шаблонот е потесен од архитектурите,
6202фокусирајќи се на еден аспект на архитектурата
6203 шаблоните воведуваат некои правила во
6204архитектурата опишувајќи како софтверот ќе се
6205справува со некои аспекти на неговата
6206функционалност на ниво на инфраструктура
6207(конкурентност на пр.)
6208 архитектурните шаблони се однесуваат на конкретни
6209аспекти на однесување во контекст на архитектурата
6210(како RT апликациите ја решаваат синхронизацијата)
621116
6212Софтверски архитектури
6213ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6214И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6215СОФТВЕРСКО ИНЖЕНЕРСТВО
6216Преглед на архитектонски стилови
6217 Скоро сите софтверски системи може да се
6218категоризираат во еден од глобалните арх.
6219стилови:
62201. Data-centered architectures (податочно-центрични)
62212. Data-flow architectures (проточни)
62223. Call and return architectures (повикување и
6223враќање)
62244. Object-oriented architectures (објектно-
6225ориентирани)
62265. Layered architectures (слоевити)
622717
6228Софтверски архитектури
6229ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6230И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6231СОФТВЕРСКО ИНЖЕНЕРСТВО
6232Data-centered architecture
6233 data repository / clients
6234 data repository can be passive, active (blackboard)
6235 integrability
6236Софтверски архитектури
623718
6238Client
6239software
6240Client
6241software
6242Client
6243software
6244Client
6245software
6246Client
6247software
6248Client
6249software
6250Client
6251software
6252Client
6253software
6254Data store
6255(repository or
6256blackboard)
6257ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6258И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6259СОФТВЕРСКО ИНЖЕНЕРСТВО
6260Data-flow architecture
6261 pipe and filter pattern
6262 batch sequential
6263Filter
6264Pipes
6265Filter
6266Filter
6267Filter Filter
6268Filter Filter
6269Filter
6270(a) Pipes and filters
6271Filter
6272Filter
6273(b) Batch sequential
6274Filter Filter Filter Filter
6275Софтверски архитектури
627619
6277ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6278И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6279СОФТВЕРСКО ИНЖЕНЕРСТВО
6280Call and return architecture
6281Main program
6282Controller
6283subprogram
6284Controller
6285subprogram
6286Controller
6287subprogram
6288Application
6289subprogram
6290Application
6291subprogram
6292Application
6293subprogram
6294Application
6295subprogram
6296Application
6297subprogram
6298Application
6299subprogram
6300Application
6301subprogram
630220
6303Софтверски архитектури
6304 Main-programand-subprogram
6305 Remote
6306procedure call
6307ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6308И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6309СОФТВЕРСКО ИНЖЕНЕРСТВО
6310Object-oriented architecture
6311 Во компонентите се енкапсулирани и
6312податоците и операциите кои ги
6313манипулираат. Комуникацијата и
6314координацијата се изведува со праќање на
6315пораки.
6316Софтверски архитектури
631721
6318ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6319И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6320СОФТВЕРСКО ИНЖЕНЕРСТВО
6321Layered architectures
6322Core layer
6323Components
6324User interface layer
6325Application layer
6326Utility layer
6327Софтверски архитектури
632822
6329 Секој слој
6330изведува
6331операции кои
6332прогресивно
6333стануваат се
6334поблиски до
6335машинските
6336ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6337И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6338СОФТВЕРСКО ИНЖЕНЕРСТВО
6339Virtual machine architecture
6340Data
6341(Program State)
6342Interpret
6343Engine
6344Internal
6345State
6346Program Being
6347Interpreted
6348Program
6349Instructions
6350State Data
6351Selected Instruction
6352Selected Data
6353Data Updates
6354Inputs
6355Outputs
6356Софтверски архитектури
635723
6358ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6359И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6360СОФТВЕРСКО ИНЖЕНЕРСТВО
6361Софтверски архитектури
636224
6363ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6364И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6365СОФТВЕРСКО ИНЖЕНЕРСТВО
6366Организација и прочистување
6367 Како да се избере вистинската од големиот број
6368архитектонски алтернативи?
6369Аспекти:
6370 контрола
6371 како се спроведува, дали е видлива јасна хиерархија, која е
6372улогата на компонентите во неа, како ја
6373споделуваат/пренесуваат контролата, дали работата
6374синхроно или асинхроно
6375 податоци
6376 како се пренесуваат податоците помеѓу компонентите, дали
6377протокот е континуиран или спорадичен, дали постојат
6378податочни компоненти и која е нивната улога, дали се
6379пасивни или активни, каква е интеракцијата помеѓу
6380податоците и контролата во системот
6381Софтверски архитектури
638225
6383ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6384И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6385СОФТВЕРСКО ИНЖЕНЕРСТВО
6386Дизајн на архитектура
6387 Итеративен процес
6388 Почнува со дефинирање на контекстот
6389(екстерните ентитети со кои системот ќе
6390остварува интеракција и видот на оваа
6391интеракција) – дефинирање на екстерните
6392интерфејси
6393 Дефинирање на архетипи (апстракција која
6394опишува елемент на системско однесување)
6395 Дефинирање и рафинирање на софтверските
6396компоненти кои би го имплементирале секој
6397архетип
639828
6399Софтверски архитектури
6400ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6401И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6402СОФТВЕРСКО ИНЖЕНЕРСТВО
6403Контекст на системот
6404 Architectural context diagram (ACD)
640529
6406Софтверски архитектури
6407Superordinate systems
6408Subordinate systems
6409Depends on
6410Uses
6411Uses
6412Used by
6413Peers
6414Actors
6415Target system
6416интерфејс
6417ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6418И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6419СОФТВЕРСКО ИНЖЕНЕРСТВО
6420SafeHome Architecture context
642130
6422Софтверски архитектури
6423Target system :
6424security function Uses
6425Uses Peers Homeowner
6426SafeHome
6427product
6428Internet based -
6429system
6430Surveillance
6431function
6432Sensors
6433Control
6434panel
6435Sensors
6436Uses
6437ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6438И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6439СОФТВЕРСКО ИНЖЕНЕРСТВО
6440Дефинирање на архетипи
6441 Дефинирање на интерфејсите и
6442идентификација на сите податоци кои ќе
6443течат низ нив
6444 архетип – класа или шаблон кој ја опишува
6445основната апстракција битна за дизајнот на
6446архитектурата за целниот систем
644731
6448Софтверски архитектури
6449ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6450И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6451СОФТВЕРСКО ИНЖЕНЕРСТВО
6452Архетипи за Safehome
6453 Пример за архетипи за Safehome
6454Node
6455Detector
6456Indicator
6457Controller
6458 Нивно рафинирање
645932
6460Софтверски архитектури
6461Controller
6462Node
6463Communicates with
6464Detector Indicator
6465ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6466И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6467СОФТВЕРСКО ИНЖЕНЕРСТВО
6468Рафинирање во компоненти
6469 Првично според класите за анализа
6470 Архитектурата ќе содржи и многу
6471инфраструктурни компоненти кои ќе
6472ги овозможат апликациските
6473компоненти но немаат директна врска
6474со апликацискиот домен (management
6475components, communication components,
6476database components, ...)
647733
6478Софтверски архитектури
6479ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6480И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6481СОФТВЕРСКО ИНЖЕНЕРСТВО 34
6482Софтверски архитектури
6483SafeHome
6484executive
6485External
6486communication
6487management
6488GUI Internet
6489interface
6490Function
6491selection
6492Security Surveillance Home
6493management
6494Control panel
6495processing
6496Detector
6497management
6498Alarm
6499processing
6500-
6501ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6502И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6503СОФТВЕРСКО ИНЖЕНЕРСТВО
6504Елаборација
650535
6506Софтверски архитектури
6507External
6508communication
6509management
6510GUI Internet
6511interface
6512Security
6513Control
6514panel
6515processing
6516Detector
6517management
6518Alarm
6519processing
6520Keypad
6521processing
6522CP display
6523functions
6524Scheduler Phone
6525communication
6526Alarm
6527SafeHome
6528executive
6529Sensor
6530ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6531И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6532СОФТВЕРСКО ИНЖЕНЕРСТВО
6533Анализа на алтернативни архитектури
6534 Два пристапа за анализа на
6535алтернативни архитектури:
6536Итеративен метод за проценка на
6537компромисите во дизајните (trade-offs)
6538Примена на псевдо-квантитативни техники
6539за проценка на квалитетот на дизајнот
6540Софтверски архитектури
654136
6542ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6543И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6544СОФТВЕРСКО ИНЖЕНЕРСТВО
6545ATAM (1)
6546 Software Engineering Institute (SEI) развил метода за
6547развој на архитектури architecture trade-off analysis
6548method (ATAM) која претставува итеративно
6549повторување на активностите:
65501. Собирање сценарија
65512. Извлекување на барањата, ограничувањата и опис
6552на околината
65533. Опис на архитектонските стилови/шаблони избрани
6554да ги задоволат сценаријата и барањата
6555 module view - work assignments, information hiding
6556 process view - system performance
6557 data-flow view - functional requirements
6558Софтверски архитектури
655937
6560ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6561И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6562СОФТВЕРСКО ИНЖЕНЕРСТВО
6563ATAM (2)
65644. Проценка на атрибутите на квалитет разгледувајќи
6565го секој одделно (reliability, performance, security,
6566maintainability, flexibility, testability, portability,
6567reusability, interoperability)
65685. Одредување на осетливоста на секој од атрибутите
6569на квалитет на атрибутите на архитектонскиот стил
65706. Критика на кандидат архитектурите (од чекор 3) врз
6571основа на анализата на осетливост од чекор 5
6572 Воочување на можните компромиси помеѓу некои
6573од атрибутите на архитектурата во однос на
6574барањата, промена на архитектурите (евентуално
6575отфрлање на некои од нив) и повторување на
6576чекорите.
6577Софтверски архитектури
657838
6579ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6580И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6581СОФТВЕРСКО ИНЖЕНЕРСТВО
6582Квантитативни водилки за
6583архитектонски дизајн
6584 Предложени се едноставни модели кои
6585би му помогнале на архитектот да ја
6586одреди мерката во која архитектурата
6587одговара на одредени критериуми
6588(design dimensions) на „погодност“.
6589 Овие критериуми (design dimensions)
6590најчесто вклучуваат атрибути на
6591квалитет (reliability, performance, …)
6592Софтверски архитектури
659339
6594ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6595И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6596СОФТВЕРСКО ИНЖЕНЕРСТВО
6597Spectrum Analysis модел
6598 Го проценува дизајнот во однос на спектар „на
6599погодност“ кој се протега од најдобриот до најлошиот
6600дизајн. Секоја предложената архитектура се
6601проценува во однос на добиените резултати за
6602секоја од димензиите на дизајнот на соодветниот
6603спектар, кои се собираат за да се добие вкупниот
6604резултат.
6605 Sw – резултат на најлошиот (но применлив) дизајн
6606 Sb - резултат на најдобриот дизајн (оптимален но
6607тешко изводлив поради ограничувања – цена, време)
6608 Is – spectrum index
6609Is
6610=[(S-Sw)/(Sb-Sw)]×100
6611 означува колку дадената архитектура е блиска до
6612оптималниот систем од спектарот на разумно
6613избрани дизајни
6614 improvement index Imp=Is1-Is2
6615Софтверски архитектури
661640
6617ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6618И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6619СОФТВЕРСКО ИНЖЕНЕРСТВО
6620Design selection analysis
6621 Design selection analysis
6622d=(Ns/Na)×100
6623 Ns - број на задоволени дизајнерски
6624димензии
6625 Na - вкупен број на дизајнерски
6626димензии
6627Софтверски архитектури
662841
6629ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6630И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6631СОФТВЕРСКО ИНЖЕНЕРСТВО
6632Contribution analysis
6633 Одредување на релативниот приоритет
6634на барањата при одредувањето на
6635архитектурата
6636 Quantified design space (QDS) –
6637референтна матрица на која се внесува
6638влијанието на секое од барањата на
6639секој од разгледуваните дизајни (оценка
66401-10)
6641 Дава претстава зошто одредени дизајни
6642добиваат помала оценка од други
6643Софтверски архитектури
664442
6645ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6646И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6647СОФТВЕРСКО ИНЖЕНЕРСТВО
6648Комплексност на архитектура
6649 Техника за проценка на глобалната
6650комплексност на предложена архитектура.
6651Комплексноста е одредена од
6652информациските/контролните текови во
6653системот.
6654 Sharing dependencies (две или повеќе компоненти
6655кои користат исти ресурси)
6656 Flow dependencies (да заврши u за да му ги
6657проследи податоците на v)
6658 Constrained dependencies (ограничувања при
6659релативниот тек – u и v не може да се одвиваат
6660паралелно – взаемно се исклучуваат)
6661Софтверски архитектури
666243
6663ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6664И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6665СОФТВЕРСКО ИНЖЕНЕРСТВО
6666ADL
6667 Architectural Description Languages –
6668јазици за опис на архитектури
6669 Обезбедуваат семантика и синтакса за
6670опис на софтверски архитектури
6671разложување архитектонски компоненти
6672сложување архитектонски компоненти
6673опис на интерфејси
667444
6675Софтверски архитектури
6676ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6677И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6678СОФТВЕРСКО ИНЖЕНЕРСТВО 45
6679Пресликување на барањата во архитектура
6680 Не постои генерално пресликување од
6681моделот на барања во секој од
6682архитектонските модели.
6683 Техника за пресликување на моделот
6684на барања во call-and-return
6685архитектура наречен и структурен
6686дизајн нуди соодветна транзиција од
6687DFD во софтверска архитектура
6688Софтверски архитектури
6689ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6690И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6691СОФТВЕРСКО ИНЖЕНЕРСТВО 65
6692Финализирање на
6693архитектонскиот дизајн
6694 По развојот и рафинирањето на
6695програмската структура, потребно е уште и
6696да се:
6697 даде наративен опис на процесирањето на секој
6698модул (processing, decisions, I/O)
6699 даде опис на интерфејсите на секој модул
6700 дефинираат локалните и глобалните податочни
6701структури
6702 опишат сите ограничувања на дизајнот
6703 спроведе преглед и ревизија на дизајнот
6704 да се разгледа потребата од понатамошно
6705рафинирање
6706Софтверски архитектури
6707ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6708И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6709СОФТВЕРСКО ИНЖЕНЕРСТВО
6710Прашања?
671166
6712Софтверски архитектури
6713________________________________________________________________________________________________________________________
6714ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6715Component-Level
6716Design
6717Софтверско инженерство
6718ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6719И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6720СОФТВЕРСКО ИНЖЕНЕРСТВО
6721Процедурален дизајн
6722 Процедуралниот дизајн (дизајн на
6723компоненти) доаѓа по податочниот,
6724архитектонскиот и дизајнот на
6725интерфејси.
6726 Целта е да се трансформира дизајнот
6727во оперативен софтвер
6728 Ова да се направи без воведување
6729грешки во процесот (кои подоцна би
6730требало да се исправаат)
6731Софтверски архитектури
67322
6733ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6734И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6735СОФТВЕРСКО ИНЖЕНЕРСТВО
6736Component-Level Design
6737 Дизајнот на ниво на компоненти
6738 ги воспоставува алгоритамските детали
6739неопходни за манипулација на податочните
6740структури
6741 ја ефектуира комуникацијата помеѓу компонентите
6742преку интерфејсите
6743 ги имплементира алгоритмите за процесирање во
6744секоја од компонентите
6745 Наративниот опис на процесирањето во
6746секоја од компонентите се преведува во
6747модел на процедурален дизајн (графичка,
6748табелана, текстуална, претстава)
6749Софтверски архитектури
67503
6751ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6752И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6753СОФТВЕРСКО ИНЖЕНЕРСТВО
6754Зошто е важно?
6755 Дизајнот на ниво на компоненти го
6756претставува софтверот во форма која
6757овозможува ревизија на деталите на дизајнот
6758за коректност и конзистентност со останатите
6759репрезентации на дизајнот (податочна,
6760архитектонска, интерфејси)
6761 Независно до механизмот за репрезентација,
6762податочните структури, алгоритмите,
6763интерфејсите и дизајнот на ниво на
6764компоненти треба да следи некои добро
6765познати препораки за процедурален дизајн
6766кои помагаат да се избегнат грешките
6767Софтверски архитектури
67684
6769ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6770И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6771СОФТВЕРСКО ИНЖЕНЕРСТВО
6772Контролна хиерархија
6773 Контролната хиерархија на
6774програмската структура ја изразува
6775организацијата на програмските
6776компоненти и подразбира хиерархиска
6777контрола
6778 Контролната хиерархија не ги
6779репрезентира процедуралните аспекти
6780на софтверот како секвенца на
6781процесите, настаните, редослед на
6782одлуки или повторување на операции
6783Дизајнирање
67845
6785ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6786И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6787СОФТВЕРСКО ИНЖЕНЕРСТВО
6788Структура на контролна хиерархија
6789 Најчесто се користи претстава во форма на разгрането дрво
6790Fan-out
6791Fan-in
6792Depth
6793Width
6794a c
6795d e k l m
6796t g h n opq
6797j i r
6798M
6799b
6800superordinate
6801subordinate
6802Visibility
6803Connectivity
6804Дизајнирање
68056
6806ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6807И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6808СОФТВЕРСКО ИНЖЕНЕРСТВО
6809Структурна поделба (1)
6810 Хоризонтална поделба (влез, процесирање,
6811излез)
6812 полесно тестирање, одржување, проширување
6813 поголемо количество податоци кои се препраќаат
6814интерфејсите на модулите и покомплексна
6815глобална контрола на текот
6816(a) Horizontal partitioning
6817Function 2
6818Function 1 Function 3
6819Дизајнирање
68207
6821ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6822И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6823СОФТВЕРСКО ИНЖЕНЕРСТВО
6824Структурна поделба (2)
6825 Вертикална поделба (factoring)
6826 Дистрибуција на контролата во top-down пристап
6827 повисоки нивоа – повеќе контрола
6828 пониски нивоа – повеќе работа
6829 Претстава на влијанието на промена
6830Decision-making
6831modules
6832“Worker”
6833modules
6834(b) Vertical partitioning
6835Дизајнирање
68368
6837ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6838И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6839СОФТВЕРСКО ИНЖЕНЕРСТВО
6840Податочни структури
6841 Податочните структури - репрезентација на
6842логичката поврзаност помеѓу индивидуалните
6843податочни елементи
6844 Многу што зависи од нив – начинот на организација и
6845пристап до податоците, алтернативите за нивно
6846процесирање
6847 Заслужуваат најмалку исто внимание како и дизајнот
6848на алгоритмите
6849 Постојат одреден број на „класични“ податочни
6850структури кои ги чинат основните градбени блокови
6851за конструкција на пософистицирани структури
6852 скалари, вектори, полиња, структури, поврзани листи,
6853хиерархиски структури, ...
6854 Изборот на податочната структура ги диктира
6855организацијата, методите за пристап, степенот на
6856асоцијативност и алтернативите за процесирање на
6857информациите
6858Дизајнирање
68599
6860ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6861И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6862СОФТВЕРСКО ИНЖЕНЕРСТВО
6863Софтверски процедури
6864 Софтверски процедури – детали за процесирањето во
6865секој од модулите
6866 Прецизна спецификација на
6867процесирањето кое вклучува
6868секвенца на настани, егзактни
6869точки за одлучување,
6870повторувачки операции па дури
6871и организација на податоците и
6872податочните структури
6873 Поврзаноста помеѓу структурата
6874и процедурите – процесирањето
6875во секој модул мора да вклучи
6876референца кон сите негови
6877субординирани модули Procedure for ultimately
6878subordinate module
6879Procedure for
6880subordinate module
6881Procedure for
6882superordinate module
6883Дизајнирање
688410
6885ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6886И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6887СОФТВЕРСКО ИНЖЕНЕРСТВО
6888Компоненти
6889 Компонента – модуларен градбен блок
6890на компјутерски софтвер
6891 модуларен, испорачлив и заменлив дел
6892на систем кој сокрива имплементација и
6893експонира множество на интерфејси
689411
6895Софтверски архитектури
6896ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6897И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6898СОФТВЕРСКО ИНЖЕНЕРСТВО
6899Class-Based Components
6900Принципи:
6901 The Open-Closed Principle (OCP) – модул треба да е отворен за
6902проширување а затворен за измени
6903 The Liskov Substitution Principle (LSP) – подкласите може да ги заменат
6904класите
6905 Dependency Inversion Principle (DIP) – зависност од апстракција, не
6906конкретни компоненти
6907 The Interface Segregation Principle (ISP) – повеќе интерфејси
6908специфични за различни клиенти се подобри од еден интерфејс за
6909општа употреба
6910 The Release Reuse Equivalency Principle (REP) – гранулите на
6911реупотреба се гранули на испорака (packages)
6912 The Common Closure Principle (CCP) – класите кои се менуваат заедно
6913припаѓаат заедно (кохезивно пакување)
6914 The Common Reuse Principle (CRP) – класите кои не се користат заедно
6915не треба да се спакувани заедно
691612
6917Софтверски архитектури
6918ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6919И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6920СОФТВЕРСКО ИНЖЕНЕРСТВО
6921Дизајнирање на компоненти
6922 Компоненти – конвенција за именување
6923 Интерфејси
6924 lollipop instead of UML box and dashed arrow notation
6925 за конзистентност интерфејсите да излегуваат само до
6926левата страна на компонентата
6927 да се прикажат само оние кои се релевантни за
6928компонентата во дадениот контекст (иако можеби има и
6929други)
6930 Зависности и наследство
6931 моделирање на зависностите од лево на десно
6932 моделирање на наследството од долу нагоре
6933 зависноста на компонентите да биде искажана преку
6934нивните интерфејси
693513
6936Софтверски архитектури
6937ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6938И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6939СОФТВЕРСКО ИНЖЕНЕРСТВО
6940Сокривање на информациите
6941 Сокривањето на информации (information hiding) се
6942однесува на одлуката како да се изврши поделбата
6943на софтверското решение со цел да се добие „добро“
6944множество на модули.
6945 Принципот на криење на информации сугерира
6946креирање на модулите така да се „кријат“ еден од
6947друг – информациите (процедурите и податоците) од
6948еден модул да бидат недостапни за останатите
6949модули кои немаат потреба од истите
6950 Ограничување на пристапот до информациите во
6951рамките на модулот – помали можности за
6952пропагација на грешки при подоцнежни промени
6953 Модулите меѓусебно ги разменуваат само
6954информациите неопходни за постигнување на
6955функцијата на софтверот
6956Дизајнирање
695714
6958ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6959И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6960СОФТВЕРСКО ИНЖЕНЕРСТВО
6961Ефективен модуларен дизајн
6962 Модуларниот дизајн придонесува кон:
6963 намалена комплексност
6964 поедноставни промени
6965 поедноставна имплементација (паралелен развој)
6966 Функционалната независност се постигнува
6967со развој на модули со „едноумни“ функции и
6968„аверзија“ кон преголема интеракција со
6969други модули
6970 Секој модул да обработува специфична
6971подфункција од барањата и да има
6972едноставен интерфејс гледан од остатокот од
6973програмската структура
6974Дизајнирање
697515
6976ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6977И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6978СОФТВЕРСКО ИНЖЕНЕРСТВО
6979Зошто независноста е важна?
6980 Софтверот со ефективна модуларност
6981(независни модули):
6982 полесно се развива (одвоени функции, едноставен
6983интерфејс)
6984 полесно се одржува и тестира (секундарните
6985ефекти поради модификација на кодот или
6986дизајнот се ограничени, пропагацијата на грешки е
6987намалена, reusable modules)
6988 Независноста се мери преку два
6989квалитативни критериуми:
6990 cohesion – кохезија
6991 coupling – упарување (поврзаност)
6992Дизајнирање
699316
6994ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
6995И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
6996СОФТВЕРСКО ИНЖЕНЕРСТВО
6997Кохезија
6998 Кохезивен модул изведува единствена
6999задача со минимална интеракција со
7000процедури кои се изведуваат во други
7001делови на програмата
7002 Од аспект на пожелноста кохезијата се
7003претставува како спектар со
7004нелинеарна скала (тежиме кон висока
7005кохезија, но и онаа од средниот дел на
7006спектарот е прифатлива)
7007Дизајнирање
700817
7009ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7010И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7011СОФТВЕРСКО ИНЖЕНЕРСТВО
7012Кохезија
7013 „едноумност“ на компонентите
7014 Функционална кохезија – компонентата изведува
7015одредена операција и враќа резултат
7016 Слоевита кохезија (пакети, компоненти, класи) -
7017повисоките слоеви пристапуваат на сервисите од
7018пониските нивоа но не обратно)
7019 Комуникациска кохезија - операциите за пристап
7020до исти податоци се групирани во една класа
7021 Класите и компонентите во кои ги има овие
7022три типа на кохезија релативно лесно се
7023имплементираат, тестираат и одржуваат
702418
7025Софтверски архитектури
7026ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7027И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7028СОФТВЕРСКО ИНЖЕНЕРСТВО
7029Видови кохезија
7030 Коинцидентна кохезија - на долниот (непожелен) дел
7031од спектарот е модул кои изведува група слабо
7032поврзани или неврзани задачи (coincidental cohesion)
7033 Логичка кохезија - модул кој изведува логичко
7034поврзани задачи (печатење...) (logical cohesion)
7035 Времена кохезија - модули кој обединува задачи кои
7036се изведуваат истовремено (temporal cohesion)
7037 Процедурална кохезија – процесирачките елементи
7038во модулот се меѓузависни и мора да бидат изведени
7039по одреден редослед (procedural cohesion)
7040 Комуникациска кохезија – сите процесирачки
7041елементи во модулот се концентрираат на единствен
7042дел од податочната структура
7043Дизајнирање
704419
7045ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7046И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7047СОФТВЕРСКО ИНЖЕНЕРСТВО
7048Поврзаност (coupling)
7049 Coupling - поврзаност помеѓу модулите во
7050софтверската структура
7051 Зависи од интерфејсот, местото на
7052рефернцирање и податоците кои се
7053испраќаат преку интерфејсот
7054 Во софтверскиот дизајн се тежнее кон што
7055помала поврзаност
7056 Едноставната поврзаност резултира во
7057софтвер кој е поразбирлив и го намалува
7058пропагирањето на грешките низ системот
7059Дизајнирање
706020
7061ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7062И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7063СОФТВЕРСКО ИНЖЕНЕРСТВО
7064Coupling
7065 Поврзаноста на компонентите е
7066неопходна за функционирање на
7067системот, но
7068 како што се зголемува степенот на
7069поврзаност помеѓу компонентите, расте
7070и комплексноста на системот, а со тоа и
7071потешкотиите при негова
7072имплементација, тестирање и
7073одржување
707421
7075Софтверски архитектури
7076ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7077И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7078СОФТВЕРСКО ИНЖЕНЕРСТВО
7079Типови на поврзаност
7080 routine call coupling
7081 type use coupling
7082 data coupling
7083 stamp coupling
7084 inclusion or import
7085coupling
7086 control coupling
7087 external coupling
7088 common coupling
7089 content coupling
7090Дизајнирање
709122
7092a
7093b c
7094Data
7095structure
7096Data
7097(variables)
7098e
7099Control
7100flag
7101i
7102j k
7103d
7104f g h
7105No direct
7106coupling
7107Global data
7108area
7109ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7110И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7111СОФТВЕРСКО ИНЖЕНЕРСТВО
7112Типови на поврзаност
7113 Coupling types:
7114 routine call coupling
7115 type use coupling
7116 data coupling
7117 stamp coupling
7118 inclusion or import coupling
7119 control coupling
7120 external coupling (модули поврзани со околината
7121на системот - compiler coupling, OS coupling)
7122 common coupling (користи и менува глобални
7123податоци)
7124 content coupling (модифицира локални податоци
7125на друг модул)
7126Дизајнирање
712723
7128ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7129И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7130СОФТВЕРСКО ИНЖЕНЕРСТВО
7131Хевристики за дизајн на ефективна
7132модуларност
7133 Манипулации над програмската структура:
7134 Намалување на поврзаноста и зголемување на кохезијата
7135(exploding/imploding modules)
7136 Намалување на структури со голем fan-out и тежење кон
7137поголем fan-in на подлабоките нивоа
7138 Задржување на опсегот на ефектите од даден модул во
7139рамките на опсегот на контрола на истиот модул
7140 Евалуација на интерфејсите на модулите со цел да се
7141намали комплексноста и редунданцијата и да се зголеми
7142конзистентноста
7143 Дефинирање на модули со предвидлива функција (blackbox)
7144и избегнување на пререстриктивни модули
7145 Тежење кон модули со контрола на влез и избегнување на
7146„патолошки врски“
7147A pathological connection is a reference to an identifier or any entity inside a module originating from
7148outside the module.
7149Дизајнирање
715024
7151ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7152И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7153СОФТВЕРСКО ИНЖЕНЕРСТВО
7154Ефективна модуларност
7155a
7156b e
7157i
7158j k
7159d
7160m f g h r
7161c
7162n
7163q
7164p
7165x
7166Avoid a "pancaked" structure
7167Дизајнирање
716825
7169ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7170И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7171СОФТВЕРСКО ИНЖЕНЕРСТВО
7172Дизајн на компоненти
71731. Идентификувај ги сите класи кои
7174кореспондираат на доменот на проблемот
71752. Идентификувај ги сите класи кои
7176кореспондираат на инфраструктурниот
7177домен (не се опишани во барањата и често
7178не се внесени во архитектонскиот модел)
717926
7180Софтверски архитектури
7181ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7182И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7183СОФТВЕРСКО ИНЖЕНЕРСТВО
7184Дизајн на компоненти
71853. Елеаборирај ги сите класи кои не се
7186реупотребуваат како готови
7187a) Специфицирај ги пораките каде класите или
7188компонентите колаборираат (collaboration
7189diagram)
7190b) Идентификувај ги соодветните интерфејси за
7191секоја компонента
7192c) Елеаборација на атрибутите и дефинирање на
7193типовите и податочните структури потребни за
7194нивна имплементација (UML activity diagram)
719527
7196Софтверски архитектури
7197ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7198И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7199СОФТВЕРСКО ИНЖЕНЕРСТВО
7200Дизајн на компоненти
72014. Опиши ги перзистентните извори на
7202податоци (бази на податоци и датотеки) и
7203идентификувај ги класите потребни за нивно
7204менаџирање
72055. Развиј и елаборирај го однесувањето на
7206класата или компонентата (UML state
7207diagrams)
72086. Елаборирај deployment дијаграми и
7209дополнителни имплементациски детали
72107. Рефакторирање на секој компонентен дизајн
7211и постојано разгледување на алтернативи
721228
7213Софтверски архитектури
7214ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7215И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7216СОФТВЕРСКО ИНЖЕНЕРСТВО
7217Објекно-ориентиран дизајн
7218Design classes
72191. User interface classes (апстракции за HCI – визуелни
7220репрезентации на метафори)
72212. Business domain (атрибути и сервиси)
72223. Process classes (бизнис апстракции од пониско ниво)
72234. Persistent classes (претставуваат datastore / DB – чуваат
7224податоци и кога софтверот не се извршува)
72255. System classes (функции за контрола и управување со
7226софтверот кои овозможуваат системот да работи и
7227комуницира со околината)
7228 Класите за анализа (бизнис поглед)
7229 Дизајнерски класи (многу повеќе технички детали)
723029
7231Дизајнирање
7232ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7233И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7234СОФТВЕРСКО ИНЖЕНЕРСТВО
7235Well-formed classes
7236 Complete and sufficient
7237 Primitiveness (еден начин за да се
7238постигне една работа)
7239 High cohesion
7240 Low coupling
724130
7242Дизајнирање
7243ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7244И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7245СОФТВЕРСКО ИНЖЕНЕРСТВО
7246Структурирано програмирање
7247 Djikstra (1960-ти) предложил употреба
7248на множество од ограничени логички
7249конструкции од кои може да се
7250конструира секоја програма
7251 Пресликување на функционалниот
7252домен – го следи процедуралниот „тек“
7253 Конструкции со предвидлива логичка
7254структура – влез на врвот, излез на
7255дното
7256Софтверски архитектури
725731
7258ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7259И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7260СОФТВЕРСКО ИНЖЕНЕРСТВО
7261Основни конструкции
7262 Основни конструкции:
7263 секвенца (sequence)
7264 условно гранење (condition)
7265 повторување (repetition)
7266 Структурен дизајн:
7267 намалена комплексност
7268 подобрена читливост
7269 подобрено тестирање
7270 подобрено одржување
7271 chunking (препознавање на цели процедурални
7272елементи)
7273Софтверски архитектури
727432
7275ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7276И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7277СОФТВЕРСКО ИНЖЕНЕРСТВО
7278Графички претстави
7279 Блок Дијаграм на тек
7280First
7281task
7282Next
7283task
7284Sequence
7285Condition
7286F T
7287If-then-else
7288Then-part
7289Selection
7290Case
7291condition
7292Case part
7293T
7294T
7295T
7296F
7297F
7298F
7299T
7300F
7301T
7302F
7303Do white Repeat until
7304Else-part
7305Софтверски архитектури
730633
7307ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7308И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7309СОФТВЕРСКО ИНЖЕНЕРСТВО
7310Вгнездување
7311Else-part First task
7312Next task
7313Then-part
7314Loop task
7315Loop
7316condition
7317Condition
7318Софтверски архитектури
731934
7320ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7321И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7322СОФТВЕРСКО ИНЖЕНЕРСТВО
7323Недостатоци
7324 Догматската употреба на структурните
7325конструкции може да предизвика
7326неефикасност во некои случаи (излез
7327од тело на вгнездени циклуси)
7328 Можни решенија:
7329редизајнирање на процедуралната
7330репрезентација за да се изгуби излезот од
7331средина на блок
7332контролирано нарушување на строгата
7333структурна конструкција
7334Софтверски архитектури
733535
7336ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7337И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7338СОФТВЕРСКО ИНЖЕНЕРСТВО
7339Box diagram
7340 Оневозможено нарушување на
7341структурната конструкција (NassiShneiderman,
7342N-S charts, Chapin charts)
73431. функционален домен (лесно видлива
7344сликовно претставена структура)
73452. произволно пренесување на контролата
7346не е можно
73473. лесно одредување на опсегот на важење
7348на локалните и глобалните променливи
73494. лесна претстава на рекурзија
7350Софтверски архитектури
735136
7352ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7353И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7354СОФТВЕРСКО ИНЖЕНЕРСТВО
7355Box diagram
7356First task
7357Next task
7358Next +1 task
7359Sequence
7360Loop condition
7361Do-whilepart
7362Loop condition
7363Repeat-untilpart
7364Repetition Selection
7365Condition
7366F T
7367Elsepart
7368Thenpart
7369Case condition
7370Value Value
7371Casepart
7372Casepart
7373If-then-else
7374Софтверски архитектури
737537
7376ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7377И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7378СОФТВЕРСКО ИНЖЕНЕРСТВО
7379Табеларна претстава
7380 При потреба од евалуација на сложена
7381комбинација од услови за селекција на
7382соодветна акција
7383 Табели за одлучување – претстава на
7384условите и акциите во табеларна
7385форма
7386 Табелите
7387потешко може да бидат погрешно разбрани
7388полесно се имплементираат директно во
7389машински читлива форма
7390Софтверски архитектури
739138
7392ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7393И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7394СОФТВЕРСКО ИНЖЕНЕРСТВО
7395Табела за одлучување (1)
7396Conditions 1 2 3 4
7397Rules
7398n
7399Condition #1
7400Condition #2
7401Condition #3
7402Action #1
7403Action #2
7404Action #3
7405Action #4
7406Action #5
7407Actions
7408Софтверски архитектури
740939
7410ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7411И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7412СОФТВЕРСКО ИНЖЕНЕРСТВО
7413Табела за одлучување (2)
7414 Конструкција на табела за одлучување
74151. Набројување на сите акции поврзани со
7416одреден модул
74172. Набројување на сите услови (одлуки) кои
7418се релевантни за дадениот модул
74193. Поврзување на одредени групи услови со
7420соодветните акции
74214. Дефинирање на правилата кои
7422одредуваат кои акции се појавуваат при
7423одредена комбинација на услови
7424Софтверски архитектури
742540
7426ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7427И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7428СОФТВЕРСКО ИНЖЕНЕРСТВО
7429Пример
7430Conditions 1
7431TTFFF
7432FFTTF
7433TFTF
7434FTFT
74352345
7436Rules
7437Fixed rate acct.
7438Variable rate acct.
7439Consumption <100 kwh
7440Consumption ≥100 kwh
7441Min. monthly charge
7442Schedule A billing
7443Schedule B billing
7444Other treatment
7445Actions
7446If the customer account is
7447billed using a fixed rate
7448method, a minimum monthly
7449charge is assessed for
7450consumption of less than 100
7451KWH (kilowatt-hours).
7452Otherwise, computer billing
7453applies a Schedule A rate
7454structure. However, if the
7455account is billed using a
7456variable rate method, a
7457Schedule A rate structure will
7458apply to consumption below
7459100 KWH, with additional
7460consumption billed according
7461to Schedule B.
7462Софтверски архитектури
746341
7464ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7465И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7466СОФТВЕРСКО ИНЖЕНЕРСТВО
7467Пример
7468 Попуст за prepaid мобилен
7469 Доколку е корисник подолго од 1 година, за
7470вредност на сообраќај 200-499 ден. добива
7471попуст од 20 ден, а за сообраќај над 500 ден.
7472добива попуст од 50 ден. и 10 бесплатни SMS
7473пораки.
7474 Ако е корисник помалку од 1 година, за
7475вредност на сообраќај 300-499 ден. добива
7476попуст од 20 ден, а за сообраќај над 500 ден.
7477добива попуст од 40 ден. и 5 бесплатни SMS
7478пораки.
7479Софтверски архитектури
748042
7481ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7482И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7483Услови 1 2 3 4 5 6 7 8
7484Корисник>1год. F F F F T T T T
7485Сообраќај
7486<200 ден. T T
7487200-299 ден. T T
7488300-499 ден. T T
7489>500 ден. T T
7490Акции
7491Попуст 0 ден.   
7492Попуст 20 ден.   
7493Попуст 40 ден. 
7494Попуст 50 ден. 
7495Бонус SMS 0 0 0 5 0 0 0 10
7496Софтверски архитектури
749743
7498ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7499И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7500СОФТВЕРСКО ИНЖЕНЕРСТВО
7501Пример:
7502 Пресметка за кабелски интернет (наративно):
7503 Постојат фиксен и прогресивен модел.
7504 Кај фиксниот модел (проток од xx Kb/s) секој претплатник плаќа
7505фиксна претплата од 500 ден. во која се вклучени 500 MB
7506остварен проток. По надминувањето на оваа вредност протокот
7507опаѓа на yy Kb/s.
7508 Кај прогресивниот модел (проток од zz Kb/s) претплатник плаќа
7509фиксна претплата од 1000 ден. во која се вклучени 1 GB
7510остварен проток.
7511 За секои дополнителни започнати 500 MB се наплаќаат
7512дополнителни 200 денари
7513 Максималната сума која може да му се наплати на
7514претплатникот (без оглед на остварениот трансфер) не може да
7515надмине 1500 ден.
7516Софтверски архитектури
751744
7518ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7519И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7520СОФТВЕРСКО ИНЖЕНЕРСТВО
7521Program design language
7522 Program design language (PDL), структуриран
7523англиски или псевдокод - речник на говорен а
7524синтакса на програмски јазик
7525 За разлика од „вистинските“ програмски јазици PDL
7526има и наративен дел.
7527 Карактеристики на PDL:
7528 фиксна синтакса со клучни зборови кои овозможуваат
7529структурни конструкции, декларации на податоци и
7530модуларност
7531 слободна синтакса на говорниот јазик со која се опишува
7532процесирањето
7533 можност за декларирање на едноставни (скалар, поле) и
7534комплексни (листи, стебла) податочни структури
7535 можност за дефинирање на подпрограми и техники за нивно
7536повикување (и опис на интерфејси)
7537Софтверски архитектури
753845
7539ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7540И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7541СОФТВЕРСКО ИНЖЕНЕРСТВО
7542Пример
7543PROCEDURE security.monitor;
7544INTERFACE RETURNS system.status;
7545TYPE signal IS STRUCTURE DEFINED
7546name IS STRING LENGTH VAR;
7547address IS HEX device location;
7548bound.value IS upper bound SCALAR;
7549message IS STRING LENGTH VAR;
7550END signal TYPE;
7551TYPE system.status IS BIT (4);
7552TYPE alarm.type DEFINED
7553smoke.alarm IS INSTANCE OF signal;
7554fire.alarm IS INSTANCE OF signal;
7555water.alarm IS INSTANCE OF signal;
7556temp.alarm IS INSTANCE OF signal;
7557burglar.alarm IS INSTANCE OF signal;
7558TYPE phone.number IS area code + 7-digit number;
7559Софтверски архитектури
756046
7561ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7562И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7563СОФТВЕРСКО ИНЖЕНЕРСТВО
7564Пример
7565•
7566•
7567initialize all system ports and reset all hardware;
7568CASE OF control.panel.switches (cps):
7569WHEN cps = "test" SELECT
7570CALL alarm PROCEDURE WITH "on" for test.time in seconds;
7571WHEN cps = "alarm-off" SELECT
7572CALL alarm PROCEDURE WITH "off";
7573WHEN cps = "new.bound.temp" SELECT
7574CALL keypad.input PROCEDURE;
7575WHEN cps = "burglar.alarm.off" SELECT deactivate signal
7576[burglar.alarm];
7577•
7578•
7579•
7580DEFAULT none;
7581ENDCAS
7582Софтверски архитектури
758347
7584ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7585И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7586СОФТВЕРСКО ИНЖЕНЕРСТВО
7587Пример
7588REPEAT UNTIL activate.switch is turned off
7589reset all signal.values and switches;
7590DO FOR alarm.type = smoke, fire, water, temp, burglar;
7591READ address [alarm.type] signal.value;
7592IF signal.value > bound [alarm.type]
7593THEN phone.message = message [alarm.type];
7594set alarm.bell to "on" for alarm.timeseconds;
7595PARBEGIN
7596CALL alarm PROCEDURE WITH "on", alarm.time in seconds;
7597CALL phone PROCEDURE WITH message [alarm.type], phone.number;
7598ENDPAR
7599ELSE skip
7600ENDIF
7601ENDFOR
7602ENDREP
7603END security.monitor
7604Софтверски архитектури
760548
7606ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7607И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7608СОФТВЕРСКО ИНЖЕНЕРСТВО
7609Attributes of design notation
7610 Modularity
7611 Overall simplicity
7612 relatively simple to learn
7613 relatively easy to use
7614 generally easy to read
7615 Ease of editing
7616 Machine readability
7617 Maintainability
7618 Structure enforcement
7619 Automatic processing
7620 Data representation
7621 Logic verification
7622 "Code-to" ability
7623Софтверски архитектури
762449
7625ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7626И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7627СОФТВЕРСКО ИНЖЕНЕРСТВО
7628Прашања?
762950
7630Софтверски архитектури
7631_______________________________________________________________________________________________________________
7632ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7633Кориснички
7634интерфејси
7635Софтверско инженерство
7636ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7637И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7638СОФТВЕРСКО ИНЖЕНЕРСТВО
7639Дизајн на интерфејси
7640 Дизајн на интерфејси помеѓу
7641софтверските компоненти
7642 Дизајн на интерфејси помеѓу софтверот
7643и други технички средства кои
7644продуцираат или консумираат
7645информации
7646 Дизајн на интерфејси помеѓу човекот
7647(корисникот) и компјутерот
7648Софтверски архитектури
76492
7650ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7651И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7652СОФТВЕРСКО ИНЖЕНЕРСТВО
7653Кориснички интерфејс
7654 Траба да обезбеди ефикасен комуникациски
7655медиум помеѓу човекот и компјутерот
7656 Според него корисникот го препознава и цени
7657софтверот
7658 Корисникот помалку ги гледа скриените
7659квалитети и функционалност на софтверот и
7660го цени според едноставноста со која може
7661да ги постигне своите цели
7662 Дизајнот на интерфејс зависи како од
7663технолошките прашања така и од
7664проучување на потребите, однесувањето и
7665желбите на корисникот
7666Софтверски архитектури
76673
7668ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7669И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7670СОФТВЕРСКО ИНЖЕНЕРСТВО
7671Дизајн на кориснички интерфејс
7672Златни правила:
76731. Да се даде контролата на корисникот
76742. Да се намали оптоварувањето на
7675меморијата на корисникот
76763. Конзистентен интерфејс
7677 Наметнување ограничувања во интерфејсот
7678со цел да се поедностави, но за кого?
7679Едноставна имплементација -
7680фрустрирачка употреба
7681Софтверски архитектури
76824
7683ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7684И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7685СОФТВЕРСКО ИНЖЕНЕРСТВО
7686Контролата на корисникот
7687 Дефинирање на модови на интеракција кои нема да
7688го принудуваат корисникот да преземе непотребни
7689или несакани акции
7690 Обезбедување флексибилна интеракција (keyboard,
7691mouse, …)
7692 Интеракција која ќе може да се откаже (прекине) и
7693поништи (undo) (одстори?)
7694 Унапредување на интеракцијата со искуството на
7695корисникот и можност за нагодување (macro)
7696 Сокривање на техничките детали од обичниот
7697корисник
7698 Овозможување директна интеракција со објектите на
7699екранот
7700Софтверски архитектури
77015
7702ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7703И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7704СОФТВЕРСКО ИНЖЕНЕРСТВО
7705Корисникот да треба што
7706помалку да памти (и размислува)
7707 Намалување на потребата од краткотрајна
7708меморија (да не мора да ги памти минатите
7709акции)
7710 Воспоставување на соодветни подразбирани
7711вредности (за просечен корисник, можност за
7712специфицирање индивидуални преференци,
7713ресет)
7714 Дефинирање на интуитивни кратенки
7715(shortcuts)
7716 Визуелен изглед на интерфејсот заснован на
7717метафора од реалниот свет
7718 Прогресивен пристап до деталите
7719Софтверски архитектури
77206
7721ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7722И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7723СОФТВЕРСКО ИНЖЕНЕРСТВО
7724Конзистентен интерфејс
77251. Организација на визуелните
7726информации според стандарди за
7727дизајн кои се применуваат на сите
7728прикази
77292. Конзистентна употреба на ограничени
7730број начини за внесување на податоци
77313. Конзистентно дефинирани и
7732имплементирани механизми за
7733навигација
7734Софтверски архитектури
77357
7736ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7737И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7738СОФТВЕРСКО ИНЖЕНЕРСТВО
7739Конзистентен интерфејс
7740 Лесна идентификација на контекстот на
7741тековната акција од страна на
7742корисникот
7743 Задржување на конзистентноста низ
7744фамилија од апликации
7745 Да не се прават промени од
7746вообичаените очекувања на корисникот
7747за интерфејсот (стандардот) без добра
7748причина
7749Софтверски архитектури
77508
7751ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7752И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7753СОФТВЕРСКО ИНЖЕНЕРСТВО
7754Анализа и дизајн на
7755интерфејси
7756 user model – профил на корисникот на
7757системот (возраст, пол, образование,
7758...)
7759 design model (user: novice,
7760knowledgeable intermittent/frequent user)
7761 mental model (system perception)
7762 implementation model – изглед и
7763однесување на интерфејсот
77649
7765Софтверски архитектури
7766ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7767И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7768СОФТВЕРСКО ИНЖЕНЕРСТВО
7769The User Interface Design Process
7770Interface
7771validation
7772Implementation Interface design
7773User, task, and
7774environment analysis
7775Софтверски архитектури
777610
7777Interface construction
7778Interface analysis and modeling
7779ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7780И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7781СОФТВЕРСКО ИНЖЕНЕРСТВО
7782Активности при дизајн на
7783интерфејс
7784 Анализа на корисниците
7785 корисници, задачи, содржина, околина
7786 информации од: интервју, продажба, маркетинг, поддршка
7787 Анализа и моделирање на задачите
7788 Дизајн на интерфејс
7789 воспоставување на цели
7790 пресликување на секоја цел во секвенца на специфични
7791акции
7792 индицирање на состојбата на системот и дефинирање на
7793контролни механизми
7794 Дефинирање на објекти и акции на интерфејсот
7795(изглед и распоред на контроли, копчиња, икони,
7796type, click, drag, drop, …)
7797Софтверски архитектури
779811
7799ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7800И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7801СОФТВЕРСКО ИНЖЕНЕРСТВО
7802Design issues
7803 System response time
7804 length
7805 variability
7806 User help facilities
7807 integrated (context sensitive)
7808 add-on
7809 Error information handling
7810 describe the problem in jargon that the user can understand
7811 provide constructive advice for recovering from the error
7812 indicate any negative consequences of the error
7813 accompanied by an audible or visual cue
7814 should be "nonjudgmental." never place blame on the user
7815 Command labeling
7816 Will every menu option have a corresponding command?
7817 What form will commands take?
7818 How difficult will it be to learn and remember the commands? What can
7819be done if a command is forgotten?
7820 Can commands be customized or abbreviated by the user?
7821 Accessibility / Internationalization
7822Софтверски архитектури
782312
7824ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7825И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7826СОФТВЕРСКО ИНЖЕНЕРСТВО
7827Имплементација на кориснички
7828интерфејс
7829 UIDS (user-interface toolkits or user-interface
7830development systems)
7831 managing input devices (such as a mouse or keyboard)
7832 validating user input
7833 handling errors and displaying error messages
7834 providing feedback (e.g., automatic input echo)
7835 providing help and prompts
7836 handling windows and fields, scrolling within windows
7837 establishing connections between application software and the
7838interface
7839 insulating the application from interface management functions
7840 allowing the user to customize the interface
7841Софтверски архитектури
784213
7843ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7844И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7845СОФТВЕРСКО ИНЖЕНЕРСТВО
7846Прашања?
784714
7848Софтверски архитектури
7849____________________________________________________________________________________________________________________________
7850Тестирање
7851Менаџирање на квалитет
7852 Квалитет на софтвер
7853user satisfaction =
7854compliant product + good quality
7855+ delivery within budget and schedule
7856 Како да се постригне?
7857Методи на СИ
7858Техники на проектен менаџмент
7859Контрола на квалитет
7860Обезбедување квалитет
78612
7862Тестирање
7863ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7864И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7865СОФТВЕРСКО ИНЖЕНЕРСТВО
7866Обезбедување квалитет
7867 Прегледи (review)
7868 Тестирање
7869Техники
7870Стратегии
7871 Формални модели и верификација
7872 Менаџирање на конфигурации
7873 Метрики
78743
7875Тестирање
7876ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7877И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7878СОФТВЕРСКО ИНЖЕНЕРСТВО
7879Тестирање
7880 Поради човечката неспособност да
7881работи и комуницира перфектно (без
7882грешки), софтверот мора да се
7883проверува
7884 Тестирањето е критичниот елемент во
7885процесот за проверка на квалитетот на
7886софтверот и претставува конечна
7887ревизија на спецификацијата, дизајнот
7888и кодирањето
7889Тестирање
78904
7891ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7892И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7893СОФТВЕРСКО ИНЖЕНЕРСТВО
7894Важност на тестирањето
7895 Тестирањето е една од фазите на
7896развој на софтвер која (исто така) треба
7897да се планира
7898 Се случува и 30-40% од трудот во
7899проектот да се потроши на тестирање
7900 Кај некои специјални системи
7901тестирањето може да чини 3-5 пати
7902повеќе од сите останати фази на
7903развојот на софтвер заедно
7904Тестирање
79055
7906ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7907И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7908СОФТВЕРСКО ИНЖЕНЕРСТВО
7909Цел на тестирањето
7910 Целта на тестирањето е да се откријат (и
7911поправат) што поголем број грешки пред
7912софтверот да се испорача на клиентот.
7913 За да се постигне ова треба да се
7914„конструираат“ и изведат серија на тестови
7915кои имаат голема веројатност да пронајдат
7916грешка
79172 главни пристапа:
7918 тестови кои ја проверуваат интерната логика на
7919компонентите
7920 тестови кои генерирајќи влез и набљудувајќи го
7921излезот од програмата се обидуваат да откријат
7922грешки во функционирањето, однесувањето и
7923перформансите на софтверот
7924Тестирање
79256
7926ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7927И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7928СОФТВЕРСКО ИНЖЕНЕРСТВО
7929Кој го изведува?
7930 Софтверскиот инженер - во почетните
7931фази на развојот на софтвер
7932(спецификацијата, архитектурата)
7933 Програмерот – својот дел од кодот
7934 Специјалист (тестер) – во последните
7935фази – интеграција
7936 Крајниот корисник – во текот на целиот
7937животен век на користење на
7938апликацијата
7939Тестирање
79407
7941ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7942И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7943СОФТВЕРСКО ИНЖЕНЕРСТВО
7944Зошто е важно?
7945 При ревизиите и останатите техники за
7946SQA може да се откријат грешки но не
7947се доволни
7948 За да се пронајдат што е можно повеќе
7949грешки неопходно е тестовите да бидат
7950конструирани дисциплинирано (test
7951case design) и да се изведат
7952систематски
7953Тестирање
79548
7955ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7956И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7957СОФТВЕРСКО ИНЖЕНЕРСТВО
7958Како се прави?
7959 Тестирањето на софтверот се прави од две
7960перспективи:
79611. White box testing – креирање на тестови на
7962основа на интерната програмска логика
79632. Black box testing - креирање на тестови од
7964аспект само на влезот и излезот од системот
7965 При тестирањето треба да се промени
7966перспективата – да се обидеме да го
7967„урнеме“ софтверот
7968Тестирање
79699
7970ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7971И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7972СОФТВЕРСКО ИНЖЕНЕРСТВО
7973Грешки...
7974 За разлика од останатите активности
7975при развојот на софтвер кои се
7976„конструктивни“, тестирањето е
7977систематско спроведување
7978„деструктивна“ активност
7979 Ако го прифатиме фактот дека човекот
7980(и сè што тој прави) не е совршен(о) и
7981дека е човечки да се греши, мора да се
7982вложи дополнителен труд за нивно
7983лоцирање и поправање
7984Тестирање
798510
7986ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
7987И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
7988СОФТВЕРСКО ИНЖЕНЕРСТВО
7989Цели
7990 Тестирањето претставува извршување на
7991програмата со цел да се пронајдат грешки
7992во неа
7993 Добар тест е оној кој има висока веројатност
7994да пронајде неоткриени грешки
7995 Успешен тест е оној кој успеал да открие се
7996уште неоткриена грешка
7997 Целта е да се дизајнираат тестови кои ќе
7998откријат најголем број грешки со минимален
7999напор и време
8000Тестирање
800111
8002ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8003И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8004СОФТВЕРСКО ИНЖЕНЕРСТВО
8005Нуспродукти
8006 Со тестирањето не само што се
8007откриваат грешки туку и се проверува
8008дали програмата работи според
8009спецификациите
8010 Податоците собрани при тестирањето
8011претставуваат добар показател на
8012доверливоста и квалитетот на
8013софтверот
8014 Тестирањето не може да докаже
8015непостоење на грешки во софтверот
8016Тестирање
801712
8018ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8019И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8020СОФТВЕРСКО ИНЖЕНЕРСТВО
8021Принципи
80221. Сите тестови мора да може да се трасираат
8023до барањата на клиентот
80242. Тестирањето треба да се планира доволно
8025долго пред да започне
80263. Pareto принцип – 80% од грешките се
8027лоцирани во 20% од модулите
80284. Почнување со тестирање „на мало“ и
8029постепено поместување кон тестирање „на
8030големо“
80315. Исцрпно тестирање не е можно
80326. За да биде најефективно тестирањето е
8033најдобро да биде изведено од независна
8034страна
8035Тестирање
803613
8037ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8038И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8039СОФТВЕРСКО ИНЖЕНЕРСТВО
8040Testability
8041 Testability = колку лесно одредена
8042програма може да биде тестирана
8043 Уште при креирањето на програмата да
8044се мисли на нејзиното тестирање и како
8045би можело истото да се олесни
8046Тестирање
804714
8048ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8049И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8050СОФТВЕРСКО ИНЖЕНЕРСТВО
8051Testability атрибути
8052Карактеристики (атрибути) на софтверот од
8053аспект на можностите за негово тестирање:
8054 Operability
8055 Observability
8056 Controllability
8057 Decomposability
8058 Simplicity
8059 Stability
8060 Understandability
806115
8062Тестирање
8063ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8064И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8065СОФТВЕРСКО ИНЖЕНЕРСТВО
8066Operability (оперативност)
8067“The better it works, the more efficiently it can be tested”
8068(Колку подобро работи, поефикасно може да се
8069тестира)
8070 Системот има малку грешки (грешките значат
8071дополнителна анализа и извештаи во процесот на
8072тестирање)
8073 Нема грешки кои го блокираат извршувањето на
8074тестови
8075 Продуктот се развива во функционални чекори
8076(овозможува истовремен развој и тестирање).
807716
8078Тестирање
8079ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8080И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8081СОФТВЕРСКО ИНЖЕНЕРСТВО
8082Observability (набљудливост)
8083“What you see is what you test“
8084(Она што се гледа е она што се тестира)
8085 Влезовите внесени при тестирањето
8086произведуваат одреден излез
8087 Состојбата на системот и променливите се
8088видливи за време на извршувањето
8089 Погрешните излези се лесно забележливи
8090 Интерените грешки автоамтски се фаќаат и
8091пријавуваат
8092 Изворниот код е достапен
809317
8094Тестирање
8095ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8096И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8097СОФТВЕРСКО ИНЖЕНЕРСТВО
8098Controllability (контрола)
8099“The better we can control the software, the more the
8100testing can be automated and optimized”
8101(Колку подобро можеме да го контролираме
8102софтверот, толку тестирањето може да се
8103автоматизира и оптимизира)
8104 Сите можни излези може да бидат генерирани преку
8105некоја комбинација на влезови, а влезно/излезните
8106формати се конзистентни и структурирани
8107 Сите делови од кодот може да се извршат со
8108соодветна комбинација на влезовите
8109 Тестовите можат да бидат формално
8110специфицирани, автоматизирани и репродуцирани
811118
8112Тестирање
8113ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8114И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8115СОФТВЕРСКО ИНЖЕНЕРСТВО
8116Decomposability (разложливост)
8117“By controlling the scope of testing, we can more
8118quickly isolate problems and perform smarter
8119retesting“
8120(Со контролирање на опсегот на тестирање,
8121може побрзо да се изолираат проблемите и
8122помудро да се изведува повторно тестирање)
8123 Софтверскиот систем е изграден од
8124независни модули кои може да се тестираат
8125независно
8126Тестирање
812719
8128ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8129И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8130СОФТВЕРСКО ИНЖЕНЕРСТВО
8131Simplicity (едноставност)
8132"The less there is to test, the more quickly we can test it“
8133(Колку помалку има за тестирање, побргу може да се
8134истестира)
8135 Functional simplicity (множеството на
8136функционалности е минимизирано само на
8137неопходно потребните за задоволување на
8138барањата)
8139 Structural simplicity (архитектурата е модуларизирана
8140за да се намали пропагацијата на грешки)
8141 Code simplicity (усвоени стандарди за кодирање со
8142што се олеснува инспекцијата и одржувањето)
8143Тестирање
814420
8145ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8146И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8147СОФТВЕРСКО ИНЖЕНЕРСТВО
8148Stability (стабилност)
8149"The fewer the changes, the fewer the disruptions
8150to testing.“
8151(Колку помалку промени, толку помалку
8152прекини во тестирањето)
8153 Промените во софтверот се ретки и
8154контролирани
8155 Нововнесените промени не ги нарушуваат
8156постојните тестови
8157 Софтверот добро се справува со испади
8158Тестирање
815921
8160ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8161И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8162СОФТВЕРСКО ИНЖЕНЕРСТВО
8163Understandability (разбирливост)
8164"The more information we have, the smarter we
8165will test“
8166(Колку повеќе информации имаме, подобро
8167може да тестираме)
8168 Архитектонскиот дизајн и зависностите
8169помеѓу интерните, екстерните и делените
8170компоненти се добро разбрани
8171 Техничката документација е лесно достапна,
8172добро организирана, детална, прецизна и
8173точна.
8174 Промените во дизајнот се проследуваат до
8175тестерите
8176Тестирање
817722
8178ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8179И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8180СОФТВЕРСКО ИНЖЕНЕРСТВО
8181Атрибути на „добар“ тест
8182Атрибути на „добар“ тест:
81831. Висока веројатност да пронајде грешка
81842. Добриот тест не смее да биде редундантен
8185– времето и ресурсите за тестирање се
8186ограничени
81873. Добриот тест треба да биде најдобриот од
8188видот
8189 (од група слични тестови да се избере оној кои има
8190најголема веројатност да открие цела класа на грешки)
81914. Добриот тест не треба да биде ниту
8192премногу едноставен ниту премногу
8193комплексен
8194Тестирање
819523
8196ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8197И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8198СОФТВЕРСКО ИНЖЕНЕРСТВО
8199Test Case Design
8200Цел:
8201 Креирање тестови кои имаат најголема
8202веројатност да откријат најмногу грешки
8203со минимален напор и за најмалку
8204време
8205 Постојат бројни методологии кои
8206обезбедуваат систематски пристап кон
8207тестирањето
8208Тестирање
820924
8210ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8211И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8212СОФТВЕРСКО ИНЖЕНЕРСТВО
8213Black / White box testing
8214 Сите инженерски (и некои други) продукти може во
8215принцип да се тестираат на два различни начини
82161. Познавајќи ја спецификацијата на функцијата за
8217која продуктот е дизајниран, може да се изведуваат
8218тестови кои ќе демонстрираат дека сите функции
8219се оперативни, истовремено барајќи грешки во
8220секоја од функциите – Black box testing („црна
8221кутија“ – без познавање на деталите како системот
8222е реализирани и функционира)
82232. Познавајќи ја интерната структура (и начин на
8224функционирање) на продуктот, може да се
8225изведуваат тестови кои ќе осигурат дека интерно
8226сè функционира како што траба (според
8227спецификациите) – White box testing (glass box
8228testing)
8229Тестирање
823025
8231ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8232И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8233СОФТВЕРСКО ИНЖЕНЕРСТВО
8234Black / White box кај софтвер
8235За софтверот:
8236 Black box testing – тестирање преку
8237интерфејсот на софтверот на неговата
8238функционалност (влез, излез, DB),
8239фундаменталните аспекти на системот без
8240осврт на неговата интерната структура и
8241организација
8242 White box testing – тестирање на
8243процедуралните детали на софтверот преку
8244тестови кои проверуваат специфични групи
8245на услови и/или циклуси
8246Тестирање
824726
8248ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8249И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8250СОФТВЕРСКО ИНЖЕНЕРСТВО
8251Ограничувања
8252 И покрај можноста за сеопфатност на white
8253box тестовите, физички е невозможно да се
8254изведат сите можни тестови (да се проверат
8255сите можни патеки на извршување на
8256програмата)
8257 Пример - 100 реда C програма во која има:
8258 2 вгнездени циклуси кои се повторуваат од 1 до 20
8259пати секој зависно од податок на влезот
8260 во внатрешниот циклус има 4 if-then-else структури
8261 Постојат околу 1014 можни патеки по кои
8262може да се изведе оваа програма
8263Ако 1 test case = 1 ms → преку 3000 години
8264Тестирање
826527
8266ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8267И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8268СОФТВЕРСКО ИНЖЕНЕРСТВО
8269White Box Testing (1)
8270 White box testing (glass box testing) е метод за
8271дизајнирање на тестови кој го користи познавањето
8272на контролна структура на процедуралниот дизајн за
8273изведување на тестови.
8274 На овој начин можат да се изведат тестови кои:
8275 гарантираат дека сите независни контролни патеки во
8276модулот ќе бидат извршени барем еднаш
8277 ги извршуваат сите логички одлуки на нивната вистинита и
8278невистинита страна
8279 ги извршуваат сите циклуси на самите граници и во рамките
8280на предвидениот опсег
8281 ја проверуваат валидноста на интерните податочни
8282структури
8283Тестирање
828428
8285ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8286И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8287СОФТВЕРСКО ИНЖЕНЕРСТВО
8288White Box Testing (2)
8289 И покрај ограничувањата (физичката неможност да
8290се проверат сите тестови кои може да се генерираат)
8291white box тестирањето е важно бидејќи:
8292 Појавата на логички грешки и погрешни претпоставки е
8293обратно пропорционална со веројатноста на преземањето
8294на патеката низ програмата (поверојатни грешки кај
8295специјалните случаи)
8296 Логичките патеки за кои мислиме дека ретко се извршуваат,
8297всушност можеби се извршуваат регуларно – да не наведе
8298на погрешен дизајн
8299 Постојат случајни типографски грешки (голем број ги открива
8300компајлерот, но некои остануваат незабележани -
8301подеднакво е веројатно да се појават и на ретките и на
8302вообичаените патеки низ програмата)
8303Тестирање
830429
8305ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8306И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8307СОФТВЕРСКО ИНЖЕНЕРСТВО
8308Basis Path Testing
8309 Basis path testing (McCabe, 1976) –
8310изведување на мера за логичка
8311комплексност на процедуралниот
8312дизајн. Користење на истата во
8313дизајнирањето на основното множество
8314на извршни патеки кои гарантираат
8315извршување на секоја наредба во
8316програмата најмалку еднаш при
8317тестирањето
8318Тестирање
831930
8320ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8321И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8322СОФТВЕРСКО ИНЖЕНЕРСТВО
8323Flow Graph Notation
8324 Графичка претстава на контролниот
8325логички тек на програмата во форма на
8326граф
8327 Секоја структура во процедуралниот
8328опис се заменува со соодветен симбол
8329If While
8330The structured constructs in flow graph form:
8331Where each circle represents one or more
8332nonbranching PDL or source code statements
8333Until
8334Case
8335Sequence
8336Тестирање
833731
8338ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8339И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8340СОФТВЕРСКО ИНЖЕНЕРСТВО
8341Пресликување во Flow Graph (1)
83421
83433
834410
83456
83469
83472
83484
83497 8 5
835011
83511
83522,3
83536 4,5
83549
835510
835611
83577 8
8358R1
8359R3
8360R2
8361R4
8362Region
8363Node
8364Edge
8365path 1: 1-11
8366path 2: 1-2-3-4-5-10-1-11
8367path 3: 1-2-3-6-8-9-10-1-11
83681-2-3-4-5-10-1-2-3-6-8-9-10-1-11 path 4: 1-2-3-6-7-9-10-1-11
8369basis
8370set
8371paths
8372Тестирање
837332
8374ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8375И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8376СОФТВЕРСКО ИНЖЕНЕРСТВО
8377Пресликување во Flow Graph (2)
8378 Секој јазел во графот на тек претставува
8379една или повеќе процедурални „наредби“
8380блокови
8381 Секвенца на процесни блокови и ромб за
8382(едноставна) одлука може да се претстават
8383со единствен јазел
8384 Секоја врска мора да заврши во јазел дури и
8385ако тој не претставува процедурален блок
8386 Областите ограничени со јазли и врски се
8387нарекуваат региони
8388Тестирање
838933
8390ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8391И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8392СОФТВЕРСКО ИНЖЕНЕРСТВО
8393Пресликување во Flow Graph (3)
8394 Кај сложените услови (AND, OR) PDL изразите се
8395пресликуваат во поинаков граф. За секој од
8396примитивните услови се креира одвоен јазел
8397 predicate node – јазел за (одлука) гранење од кој
8398излегуваат најмалку 2 врски
8399Predicate
8400node
8401.
8402.
8403.
8404IF a OR b
8405then procedure x
8406else procedure y
8407ENDIF
8408y
8409b
8410a
8411x
8412x
8413Тестирање
841434
8415ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8416И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8417СОФТВЕРСКО ИНЖЕНЕРСТВО
8418Cyclomatic Complexity
8419 Софтверска метрика која претставува квантитативна
8420мера на логичката комплексност на програма
8421 Од аспект на тестирањето на основни патеки
8422вредноста на цикломатската комплексност го
8423дефинира бројот на независни патеки во програмата
8424и ја дава горната граница на тестови кои треба да се
8425изведат за да се обезбеди секоја наредба да биде
8426извршена барем еднаш
8427 Независна патека е произволна патека на
8428извршување низ програмата која воведува
8429извршување на барем еден нов процесирачки израз
8430или условно гранење (поминува низ барем една нова
8431врска од графот)
8432Тестирање
843335
8434ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8435И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8436СОФТВЕРСКО ИНЖЕНЕРСТВО
8437Пресметување на цикломатската
8438комплексност
8439 Цикломатска комплексност може да се
8440пресмета на три начини:
84411. Бројот на регионите на графот на тек
8442соодветствува на цикломатската
8443комплексност
84442. Цикломатската комплексност V(G) на
8445графот G е дефинирана како:
8446V(G) = E – N + 2
8447каде E е бројот на врски (рабови) во графот,
8448N е бројот на јазли
84493. V(G) = P + 1
8450каде P е бројот на предикатни јазли во
8451графот G
8452Тестирање
845336
8454ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8455И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8456СОФТВЕРСКО ИНЖЕНЕРСТВО
8457Цикломатската комплексност
84581
84592,3
84606 4,5
84619
846210
846311
84647 8
8465R1
8466R3
8467R2
8468R4
84691
84702
84716 3
84729
84734
84745
84757 8
8476региони = 4
8477V(G)= 11 рабови
8478V(G)= 3 предикатни јазли + 1 = 4
84791. Број на регионите
84802. V(G) = E – N + 2
84813. V(G) = P + 1
8482– 9 јазли +2 = 4
8483Тестирање
848437
8485ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8486И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8487СОФТВЕРСКО ИНЖЕНЕРСТВО
8488Deriving Test Cases
84891. Од PDL или од кодот се црта графот
8490на тек
84912. Одредување на цикломатска
8492комплексност од графот
84933. Одредување на основното множество
8494на независни патеки
84954. Подготовка на тестови кои ќе
8496овозможат извршување на секоја од
8497патеките од основното множество
8498Тестирање
849938
8500ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8501И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8502СОФТВЕРСКО ИНЖЕНЕРСТВО
8503Пример
8504PROCEDURE average;
8505This procedure computes the average of 100 or fewer
8506numbers that lie between bounding values; it also computes the
8507sum and the total number valid.
8508INTERFACE RETURNS average, total.input, total.valid;
8509INTERFACE ACCEPTS value, minimum, maximum;
8510TYPE value[1:100] IS SCALAR ARRAY;
8511TYPE average, total.input, total.valid;
8512minimum, maximum, sum IS SCALAR;
8513TYPE i IS INTEGER;
8514Тестирање
851539
8516ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8517И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8518СОФТВЕРСКО ИНЖЕНЕРСТВО
8519i = 1;
8520total.input = total.valid = 0;
8521sum = 0;
8522DO WHILE value[i] <> –999 AND total.input < 100
8523ENDDO
8524IF total.valid > 0
8525ENDIF
8526END average
8527increment total.input by 1;
8528IF value[i] > = minimum AND value[i] < = maximum
8529ENDIF
8530increment i by 1;
8531THEN average = sum / total.valid;
8532ELSE average = –999;
8533THEN increment total.valid by 1;
8534sum = s sum + value[i]
8535ELSE skip
85361
85373
85386
85394
85405
85417
85428
85439
854410
854511 12
854613
85472 1
85482
85493
85504
85515
85526
85537
85548
85559
855610
855712 11
855813
8559V(G) = 6 regions
8560V(G) = 17 edges 13 nodes + 2 = 6
8561V(G) = 5 predicate nodes + 1 = 6
8562Тестирање
856340
8564ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8565И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8566СОФТВЕРСКО ИНЖЕНЕРСТВО
8567Патеки
8568path 1: 1-2-10-11-13
8569path 2: 1-2-10-12-13
8570path 3: 1-2-3-10-11-13
8571path 4: 1-2-3-4-5-8-9-2-. . .
8572path 5: 1-2-3-4-5-6-8-9-2-. . .
8573path 6: 1-2-3-4-5-6-7-8-9-2-. . .
85741
85752
85763
85774
85785
85796
85807
85818
85829
858310
858412 11
858513
8586Тестирање
858741
8588ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8589И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8590СОФТВЕРСКО ИНЖЕНЕРСТВО
8591Test Cases (1)
8592Path 1 test case:
8593value(k) = valid input, where k < i for 2 ≤ i ≤ 100
8594value(i) = 999 where 2 ≤ i ≤ 100
8595Expected results: Correct average based on k values and proper
8596totals.
8597Note: Path 1 cannot be tested stand-alone but must be tested as
8598part of path 4, 5, and 6 tests.
8599Path 2 test case:
8600value(1) = 999
8601Expected results: Average = 999; other totals at initial values.
8602Path 3 test case:
8603Attempt to process 101 or more values.
8604First 100 values should be valid.
8605Expected results: Same as test case 1.
8606Тестирање
860742
8608ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8609И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8610СОФТВЕРСКО ИНЖЕНЕРСТВО
8611Test Cases (2)
8612Path 4 test case:
8613value(i) = valid input where i < 100
8614value(k) < minimum where k < i
8615Expected results: Correct average based on k values and proper
8616totals.
8617Path 5 test case:
8618value(i) = valid input where i < 100
8619value(k) > maximum where k <= i
8620Expected results: Correct average based on n values and proper
8621totals.
8622Path 6 test case:
8623value(i) = valid input where i < 100
8624Expected results: Correct average based on n values and proper
8625totals.
8626Тестирање
862743
8628ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8629И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8630СОФТВЕРСКО ИНЖЕНЕРСТВО
8631Матрица на граф
8632 Матрица на граф е квадратна матрица со онолку
8633редови колку што има јазли графот. Ќелиите
8634соодветствуваат на врски помеѓу јазлите.
86351
86363
86374
86382
86395
8640a
8641b
8642c
8643d
8644e
8645f
8646g
8647Flow graph
86481 34 2 5
86491
86503
86514
86522
86535
8654a
8655g e
8656c f
8657d b
8658Connected to
8659node
8660Node
8661Graph matrix
8662Тестирање
866344
8664ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8665И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8666СОФТВЕРСКО ИНЖЕНЕРСТВО
8667 Со воведување на тежини на врските помеѓу
8668јазлите може да стане моќна алатка за
8669проценка на програмската контролна
8670структура при тестирањето. Тежината може
8671да претставува:
8672 Веројатноста дека врската (дел од патеката) ќе
8673биде извршена
8674 Потрошено процесорско време при изведувањето
8675на врската
8676 Потребна меморија
8677 Потребни ресурси
8678Тестирање
867945
8680ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8681И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8682СОФТВЕРСКО ИНЖЕНЕРСТВО
8683Connection matrix
8684 1 – постои врска помеѓу јазлите i и j,
86850 – не постои врска.
8686 Одредување на цикломатската комплексност
8687од матрицата
86881 34 2 5
86891
86903
86914
86922
86935
86941
86951 1
86961 1
86971 1
8698Connected to
8699node
8700Node
8701Graph matrix
8702Connections
87031 – 1= 0
87042 – 1 = 1
87052 – 1 = 1
87062 – 1 = 1
8707—
87083 + 1 = 4
8709Cyclomatic
8710complexity
87111
87123
87134
87142
87155
8716a
8717b
8718c
8719d
8720e
8721f
8722g
8723Flow graph
8724Тестирање
872546
8726ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8727И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8728СОФТВЕРСКО ИНЖЕНЕРСТВО
8729Condition Testing
8730 Метод за дизајн на тестови кои ги испитуваат
8731логичките изрази во програмски модул – булова
8732променлива или релациски израз
8733E1 <relational-operator> E2
8734 каде E1 и E2 се аритметички изрази, а операторот е
8735еден од: <, ≤, =, ≠,> или ≥
8736 Сложен израз е составен од два или повеќе изрази,
8737загради и булови операции (AND, OR, NOT)
8738 Ако условот е погрешен, тогаш барем една негова
8739компонента е погрешна
8740 Boolean operator error
8741 Boolean variable error
8742 Boolean parenthesis error
8743 Relational operator error
8744 Arithmetic expression error
8745Тестирање
874647
8747ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8748И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8749СОФТВЕРСКО ИНЖЕНЕРСТВО
8750Condition Testing
8751 Две предности:
8752Едноставна проценка на покриеност со
8753тестот
8754Покриеноста до условите обезбедува
8755водство при генерирањето на
8756дополнителни тестови
8757 Целта е да се најдат не само грешки во
8758условите туку преку нив и други грешки
8759Тестирање
876048
8761ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8762И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8763СОФТВЕРСКО ИНЖЕНЕРСТВО
8764Branch Testing
8765 За сложен израз C, треба да се изведат
8766и гранката за точен и гранката за
8767неточен услов како и сите прости
8768услови во C.
8769Тестирање
877049
8771ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8772И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8773СОФТВЕРСКО ИНЖЕНЕРСТВО
8774Domain Testing
8775 Изведување на 3 до 4 теста за релационен
8776израз
8777E1 <relational-operator> E2
8778 Потребни се три теста за да се покријат
8779случаите кога E1 e >, < и = со E2.
8780 За Булови изрази со n променливи потребни
8781се сите 2n тестови.
8782 BRO (Branch and relational operator) testing
8783 Ограничување на условот D за изразот C е
8784покриен со извршувањето на C ако за време
8785на извршувањето на C резултатот на секој
8786прост израз во C го задоволува условот D.
8787Тестирање
878850
8789ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8790И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8791СОФТВЕРСКО ИНЖЕНЕРСТВО
8792BRO testing
8793 C1: B1 & B2
8794cc (D1, D2) {(t, t), (f, t), (t, f)}
8795 C2: B1 & (E3 = E4)
8796cc (D1, D2) {(t, =), (f, =), (t, >), (t, <)}
8797 C3: (E1 > E2) & (E3 = E4)
8798cc (D1, D2) where D1, D2 is >, =, <
8799{(>, =), (=, =), (<, =), (>, >), (>, <)}
8800Тестирање
880151
8802ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8803И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8804СОФТВЕРСКО ИНЖЕНЕРСТВО
8805Data Flow Testing
8806 Избор на патеки за тестирање на основа на
8807локациите на дефиниција на променливи во
8808програмата и нивна употреба
8809 За изразот со реден број S:
8810 DEF(S) = {X | statement S contains a definition of X}
8811 USE(S) = {X | statement S contains a use of X}
8812 Дефиницијата на променливата X во изразот S е
8813жива во изразот S’ ако постои патека од изразот S до
8814S’ во која нема друга дефиниција на X
8815 Definition-use (DU) chain на променливата X е во
8816форма [X, S, S’] каде S и S’ се броеви на изрази, X е
8817во DEF(S) и во USE(S’) и дефиницијата на X е жива
8818во S’.
8819Тестирање
882052
8821ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8822И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8823СОФТВЕРСКО ИНЖЕНЕРСТВО
8824Data Flow Testing Strategy
8825 DU testing strategy - да се покријат сите
8826DU вериги барем по еднаш
8827 Погодни за избор на тест патеки во
8828програми со вгнездени гренења и
8829циклуси
8830Тестирање
883153
8832ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8833И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8834СОФТВЕРСКО ИНЖЕНЕРСТВО
8835Definition-use testing
8836proc x
8837B1;
8838do while C1
8839if C2
8840then
8841if C4
8842then B4;
8843else B5;
8844endif;
8845else
8846if C3
8847then B2;
8848else B3;
8849endif;
8850endif;
8851enddo;
8852B6;
8853end proc;
8854нека променливата X е дефинирана во
8855последниот израз во блоковите B1,
8856B2, B3, B4 и B5,
8857и нека е употребена во првиот израз во
8858блоковите B2, B3, B4, B5 и B6.
8859DU – извршување на најкусата патека
8860од секој Bi
8861, 0 < i ≤ 5 до секој Bj
8862, 1 < j ≤
88636.
8864(ваквите патеки ја покриваат и
8865употребата на X во условите C1, C2,
8866C3 и C4)
8867Иако постојат 25 можни DU вериги,
8868потребни се само 5 патеки за да се
8869покријат сите вериги (ако се
8870повторува, циклусот ги опфаќа)
8871Тестирање
887254
8873ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8874И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8875СОФТВЕРСКО ИНЖЕНЕРСТВО
8876Assume that all variables are integers (of type int). In the following code:
88771 i = get_a_number_from_console();
88782 j = get_a_number_from_console();
88793 if (a<30) {
88804 i= get_a_number_from_console();
88815 } else {
88826 j=5;
88837 }
88848 if (a>b) {
88859 i=8;
888610 j=6;
888711 } else {
888812 printf("%d\n",j);
888913 }
889014 if (b<30) {
889115 printf("%d\n",i);
889216 j=6;
889317 } else {
889418 printf("%d\n",i);
889519 }
889655
8897Тестирање
8898DEF(i) = { 1, 4, 9 }
8899USE(i) = { 15, 18 }
89006 DU pairs
89011-18 (a=35, b=32)
89021-15 (a=35, b=29)
89034-15 (a=25, b=24)
89044-18 (not feasible)
89059-15 (a=29, b=25)
89069-18 (a=35, b=34)
8907ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8908И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8909СОФТВЕРСКО ИНЖЕНЕРСТВО
8910Definition-use path
8911 DU-path = патека која за променливата
8912v постoјан DEF(v, m), USE(v, n) јазли
8913така што m и n се почетниот и крајниот
8914јазел на патеката соодветно.
891556
8916Тестирање
8917DEF DEF
8918USE
8919ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8920И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8921СОФТВЕРСКО ИНЖЕНЕРСТВО
8922Definition-clear path
8923 DC-path = DU патека во која почетниот
8924јазел е единствениот дефинициски
8925јазел во патеката.
892657
8927Тестирање
8928DEF
8929USE
8930DEF DEF
8931USE
8932ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8933И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8934СОФТВЕРСКО ИНЖЕНЕРСТВО
8935Loop Testing
8936 Техника за тестирање која се фокусира
8937само на валидноста на циклусите
8938Simple loops
8939Nested loops
8940Concatenated
8941loops
8942Unstructured
8943loops
8944Четири класи на циклуси
8945 обични (simple loops)
8946 нанижани (concatenated
8947loops)
8948 вгнездени (nested
8949loops)
8950 неструктурирани
8951(unstructured loops)
8952Тестирање
895358
8954ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8955И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8956СОФТВЕРСКО ИНЖЕНЕРСТВО
8957Simple Loops
8958 Следниве тестови може да се изведат
8959над обичните циклуси:
89601. Прескокни го целосно циклусот
89612. Едно изминување низ циклусот
89623. Две изминувања
89634. m изминувања низ циклусот (m<n)
89645. n-1, n, n+1 изминувања низ циклусот
8965Тестирање
896659
8967ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8968И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8969СОФТВЕРСКО ИНЖЕНЕРСТВО
8970Nested Loops
89711. Почни на највнатрешниот циклус. Постави ги сите
8972останати циклуси на минимална вредност
89732. Изведи ги тестовите за едноставен циклус за
8974највнатрешниот циклус, додека надворешните
8975циклуси стојат на минимална вредност. Додади
8976дополнителни тестови за надвор од опсег и
8977исклучени вредности
89783. Движи се нанадвор, тестирајќи го следниот
8979надворешен циклус, додека сите останати
8980надворешни циклуси се на минимална вредност, а
8981вгнездените циклуси на „типични“ вредности
89824. Продолжи сè додека сите циклуси не се тестирани
8983Тестирање
898460
8985ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8986И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8987СОФТВЕРСКО ИНЖЕНЕРСТВО
8988Concatenated and Unstructured Loops
8989 нанижаните циклуси
8990се тестираат како обични ако се независни
8991се тестираат како вгнездени ако се зависни
8992 Секогаш кога е можно
8993неструктурираните циклуси треба да се
8994преработат во структурен дизајн
8995Тестирање
899661
8997ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
8998И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
8999СОФТВЕРСКО ИНЖЕНЕРСТВО
9000Black Box Testing
9001 Black Box Testing (behavioral testing) се
9002фокусира на функционалните барања
9003на софтверот
9004 Да се изведат множества на влезови
9005кои целосно би ги провериле
9006функционалните барања на програмата
9007 Комплементарен (а не алтернативен)
9008приод во однос на White box testing кој
9009би требало да открие друг вид на
9010грешки
9011Тестирање
901262
9013ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9014И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9015СОФТВЕРСКО ИНЖЕНЕРСТВО
9016Грешки кај Black Box тестирање
9017 Black Box тестирањето се обидува да
9018пронајде грешки во следниве категории:
90191. погрешна или функција која недостасува
90202. грешки во интерфејсот
90213. грешки во податочните структури или
9022базите на податоци
90234. грешки во однесувањето или
9024перформансите
90255. грешки при иницијализација и терминирање
9026Тестирање
902763
9028ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9029И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9030СОФТВЕРСКО ИНЖЕНЕРСТВО
9031Black Box тестирање
9032 Обично се изведува во подоцнежните фази на развој
9033на софтвер (за разлика од White Box)
9034 Намерно ја игнорира програмската структура и се
9035концентрира на грешки во информацискиот домен:
9036 How is functional validity tested?
9037 How is system behavior and performance tested?
9038 What classes of input will make good test cases?
9039 Is the system particularly sensitive to certain input values?
9040 How are the boundaries of a data class isolated?
9041 What data rates and data volume can the system tolerate?
9042 What effect will specific combinations of data have on system
9043operation?
9044Тестирање
904564
9046ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9047И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9048СОФТВЕРСКО ИНЖЕНЕРСТВО
9049Black Box техники
9050 Со примена на Black Box техниките за
9051тестирање се изведуваат тестови кои:
9052го намалуваат за повеќе од еден бројот на
9053дополнителни тестови кои треба да ги
9054направиме за да се постигне прифатливо
9055тестирање
9056ни кажуваат нешто за присуство или
9057отсуство на комплетни класи на грешки, а
9058не само за изолирана конкретна грешка за
9059конкретен тест
9060Тестирање
906165
9062ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9063И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9064СОФТВЕРСКО ИНЖЕНЕРСТВО
9065Graph-Based Testing Methods
9066 Прв чекор е да се разберат објектите кои се
9067моделирани во софтверот и релациите кои ги
9068поврзуваат овие објекти
9069 Креирање на граф на важните објекти и
9070релациите помеѓу нив
9071 nodes – објекти
9072 links – релации
9073 node weights – одредени особини на објектот
9074 link weights – карактеристики на релацијата
9075 Изведување серија тестови кои ќе го покријат
9076графот со проверка на секој објект и релации
9077и ќе ги откријат евентуалните грешки
9078Тестирање
907966
9080ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9081И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9082СОФТВЕРСКО ИНЖЕНЕРСТВО
9083Object Graph
9084 directed link
9085 bidirectional link,
9086(symmetric link)
9087 parallel link
9088New file
9089menu
9090select
9091Menu select generates Document
9092window
9093Document
9094text
9095Is represented as
9096Contains
9097Allows editing of
9098(generation time < 1.0 sec)
9099Attributes:
9100Start dimension: default setting
9101 or preferences
9102Background color: white
9103Text color: default color
9104 or preferences
9105Тестирање
910667
9107ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9108И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9109СОФТВЕРСКО ИНЖЕНЕРСТВО
9110Graph-Based Testing
9111 Постојат методи за тестирање на
9112однесување кои употребуваат графови
9113 Се цртаат објектите и релациите во форма
9114на граф и се нанесуваат соодветни тежини
9115 Се анализираат релациите и нивните
9116својства (транзитивност, симетрија,
9117рефлексивност)
9118 Се изведуваат соодветни тестови кои ќе ги
9119проверат нивните воочени особини
9120Тестирање
912168
9122ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9123И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9124СОФТВЕРСКО ИНЖЕНЕРСТВО
9125Equivalence Partitioning
9126 Го дели влезниот домен на програмата на
9127класи на податоци од кои се изведуваат
9128тестовите
9129 Идеалниот тест открива цела класа на
9130грешки
9131 Евалуација на еквивалентни класи за влезни
9132услови
9133 Секоја еквивалентна класа претставува
9134множество на валидни или невалидни
9135влезови (типично валидни или невалидни
9136нумерички вредности, опсези, множество
9137поврзани вредности или булов услов
9138Тестирање
913969
9140ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9141И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9142СОФТВЕРСКО ИНЖЕНЕРСТВО
9143Equivalence Classes
9144 Еквивалентните класи може да се дефинираат
9145според следниов рецепт:
91461. Ако влезниот услов дефинира опсег, се
9147дефинираат една валидна и две невалидни
9148еквивалентни класи
91492. Ако влезниот услов претставува специфична
9150вредност, се дефинираат една валидна и две
9151невалидни еквивалентни класи
91523. Ако влезниот услов дефинира елемент од
9153множество, се дефинираат една валидна и една
9154невалидна еквивалентна класа
91554. Ако влезниот услов е булова логичка вредност, се
9156дефинираат една валидна и една невалидна
9157еквивалентна класа
9158Тестирање
915970
9160ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9161И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9162СОФТВЕРСКО ИНЖЕНЕРСТВО
9163 During the log-on sequence, the software
9164supplied for the banking application
9165accepts data in the form
9166area code—blank or three-digit number
9167prefix—three-digit number not beginning with
91680 or 1
9169suffix—four-digit number
9170password—six digit alphanumeric string
9171commands—check, deposit, bill pay, and the
9172like
9173Тестирање
917471
9175ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9176И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9177СОФТВЕРСКО ИНЖЕНЕРСТВО
9178The input conditions associated with each data element for
9179the banking application can be specified as
9180area code: Input condition, Boolean—the area code may
9181or may not be present.
9182Input condition, range—values defined
9183between 200 and 999, with specific exceptions.
9184prefix: Input condition, range—specified value >200
9185Input condition, value—four-digit length
9186password: Input condition, Boolean—a password may or
9187may not be present.
9188Input condition, value—six-character string.
9189command: Input condition, set—containing commands
9190noted previously.
9191Тестирање
919272
9193ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9194И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9195СОФТВЕРСКО ИНЖЕНЕРСТВО
9196Boundary Value Analysis (BVA)
9197 Од сеуште недоволно разјаснети
9198причини, поголем број на грешки се
9199јавуваат на границите на влезниот
9200домен отколку во средината
9201 Анализата на гранични вредности е
9202техника за тестирање комплементарна
9203на еквивалентно партиционирање
9204 BVA води кон креирање на тестови кои
9205оперираат на работ на доменот
9206Тестирање
920773
9208ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9209И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9210СОФТВЕРСКО ИНЖЕНЕРСТВО
9211BVA
9212 Guidelines for BVA are similar in many respects to those
9213provided for equivalence partitioning:
92141. If an input condition specifies a range bounded by values
9215a and b, test cases should be designed with values a
9216and b and just above and just below a and b.
92172. If an input condition specifies a number of values, test
9218cases should be developed that exercise the minimum
9219and maximum numbers. Values just above and below
9220minimum and maximum are also tested.
92213. Apply guidelines 1 and 2 to output conditions.
92224. If internal program data structures have prescribed
9223boundaries (e.g., an array has a defined limit of 100
9224entries), be certain to design a test case to exercise the
9225data structure at its boundary.
9226Тестирање
922774
9228ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9229И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9230СОФТВЕРСКО ИНЖЕНЕРСТВО
9231Comparison Testing
9232 Во специјални ситуации се развиваат
9233независни системи според иста
9234спецификација
9235 Се извршуваат паралелно и им се
9236споредуваат резултатите
9237Тестирање
923875
9239ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9240И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9241СОФТВЕРСКО ИНЖЕНЕРСТВО
9242Orthogonal Array Testing
9243 Се применува кај апликации кај
9244кои влезниот домен е релативно
9245мал, но сепак преголем за
9246исцрпно тестирање на сите
9247можни комбинации
9248 OAT се обидува да генерира
9249влез за тестовите кои ќе бидат
9250униформно дисперзирани низ
9251доменот на тестот
9252Y
9253X
9254Y
9255X
9256Z
9257Тестирање
925876
9259ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9260И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9261СОФТВЕРСКО ИНЖЕНЕРСТВО
9262 “one input item at a time” testing strategy
9263 Such test cases are useful only when one is
9264certain that these test parameters do not
9265interact.
9266 The orthogonal array testing approach enables
9267us to provide good test coverage with far fewer
9268test cases than the exhaustive strategy.
9269Y Y
9270X X
9271Z Z
9272One input item at a time L9 orthogonal array
9273Тестирање
927477
9275ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9276И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9277СОФТВЕРСКО ИНЖЕНЕРСТВО
9278 Detect and isolate
9279all single mode
9280faults.
9281 Detect all double
9282mode faults.
9283 Multimode faults.
9284Test
9285case Test parameters
9286PPPP
92871
92881234
92892
92903
92913
92921
92932
92942
92953
92961
92971
92982
92993
93002
93013
93021
93033
93041
93052
93061
93072
93083
93091
93102
93113
93121
93132
93143
93151
93161
93171
93182
93192
93202
93213
93223
93233
93241
93252
93263
93274
93285
93296
93307
93318
93329
9333Тестирање
933478
9335ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9336И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9337СОФТВЕРСКО ИНЖЕНЕРСТВО
9338Тестирање на специјални околини,
9339архитектури и апликации
9340 Testing GUIs
9341 Testing of Client/Server Architectures
9342 Testing Documentation and Help Facilities
9343 Testing for Real-Time Systems
9344Task testing.
9345Behavioral testing.
9346Intertask testing.
9347System testing.
9348Тестирање
934979
9350ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9351И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9352СОФТВЕРСКО ИНЖЕНЕРСТВО
9353Прашања?
935480
9355Тестирање
9356_________________________________________________________________________________________________________________________________________________
9357ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9358СТРАТЕГИИ
9359за тестирање
9360на софтвер
9361Софтверско инженерство
9362ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9363И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9364СОФТВЕРСКО ИНЖЕНЕРСТВО
9365Стратегии за тестирање
9366 Стратегиите за тестирање на софтвер
9367го опфаќаат процесот на:
9368планирање на тестирањето
9369организирано развивање на тестови
9370нивно спроведување
9371прибирање на податоците и нивна
9372обработка
9373исправање на грешките
9374Тестирање
93752
9376ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9377И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9378СОФТВЕРСКО ИНЖЕНЕРСТВО
9379Што опфаќаат?
9380 Планирање на спроведувањето на
9381тестирањето
9382 Дали да се тестира целата програма
9383или дел по дел? По кој редослед?
9384 Дали да се повторуваат и спроведените
9385тестови по додавањето на нови
9386компоненти?
9387 Во кој момент во тестирањето да се
9388вклучи и клиентот?
9389Тестирање
93903
9391ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9392И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9393СОФТВЕРСКО ИНЖЕНЕРСТВО
9394Кој го прави и зошто е важно
9395 Кој го прави?
9396Го планираат менаџерот, софтверскиот
9397инженер и специјалисти за тестирање
9398 Зошто е важно?
9399Знае да зафат значително време (и
9400ресурси) од проектот – разумно е да се
9401спроведува систематски и стратешки
9402Тестирање
94034
9404ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9405И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9406СОФТВЕРСКО ИНЖЕНЕРСТВО
9407Стратешки приод кон тестирањето
9408 Тестирањето претставува множество активности кои
9409можат да се планираат однапред и да се спроведат
9410систематски
9411 Предложени се повеќе стратегии (шаблони) со
9412следниве генерички карактеристики:
9413 Тестирањето почнува на ниво на компоненти и се простира
9414„нагоре“ кон целосно интегрираниот систем
9415 Различни техники за тестирање се соодветни за различни
9416моменти
9417 Тестирањето го спроведуваат програмерите и специјалисти
9418за тестирање
9419 Тестирањето и дебагирањето (отстранувањето на грешки)
9420се различни работи (но составен дел на секоја стратегија за
9421тестирање)
9422Тестирање
94235
9424ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9425И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9426СОФТВЕРСКО ИНЖЕНЕРСТВО
9427Верификација и валидација
9428 Верификацијата се однесува на активности
9429кои обезбедуваат софтверот коректно да
9430имлементира одредена функција.
9431 Валидацијата се однесува на други
9432активности кои обезбедуваат изградениот
9433софтвер да ги задоволува барањата на
9434клиентот.
9435Verification: "Are we building the product right?"
9436Validation: "Are we building the right product?“
9437 V&V вклучуваат активности кои се
9438однесуваат на SQA. Тестирањето е само
9439една. Квалитетот не се тестира!
9440Тестирање
94416
9442ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9443И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9444СОФТВЕРСКО ИНЖЕНЕРСТВО
9445Организирање на тестирањето
9446 Тестирање – конфликт на интереси
9447 Самите програмерите најдобро го знаат својот
9448продукт, но кон него имаат позитивно чувство
9449(како кон свое дело) и често премногу „нежно“ го
9450третираат во тестовите
9451 Програмерите се одговорни за тестирањето на
9452одвоените модули и првите фази на интеграцијата
9453 Потоа тестирањето може да го преземе ITG
9454(Independent Test Group)
9455 Програмерите и ITG мора да соработуваат при
9456тестирањето (и ITG се дел од проектот)
9457Тестирање
94587
9459ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9460И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9461СОФТВЕРСКО ИНЖЕНЕРСТВО
9462Стратегија за тестирање на софтвер
9463System testing
9464Validation testing
9465Integration testing
9466Unit testing
9467Code
9468Design
9469Requirements
9470System engineering
9471Тестирање
94728
9473ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9474И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9475СОФТВЕРСКО ИНЖЕНЕРСТВО
9476Стратегија за тестирање
94771. Unit testing (white-box testing tehniques)
94782. Integration testing (verification and
9479program construction) – mainly black-box
94803. Validation testing – testing validation
9481criteria form requirements analysis -
9482black-box exclusively
94834. System testing – outside software
9484engineering
9485Тестирање
94869
9487ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9488И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9489СОФТВЕРСКО ИНЖЕНЕРСТВО
9490Чекори при тестирање
9491Unit
9492test Code
9493Design
9494Requirements
9495Testing
9496“direction”
9497Integration test
9498High-order
9499tests
9500Тестирање
950110
9502ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9503И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9504СОФТВЕРСКО ИНЖЕНЕРСТВО
9505Критериуми за комплетирање на
9506тестирањето
9507 Кога сме завршиле со тестирањето?
9508 Никогаш – „должноста“ преминува на клиентот...
9509 Кога ние сме завршиле со тестирањето?
9510 Кога ќе снема време или пари...
9511 Иако никогаш не можеме да бидеме сигурни дека
9512нема грешки, потребни се поригорозни
9513квантитативни критериуми како, на пример:
9514 Доволно сме тестирале кога ќе можеме со 95%
9515сигурност да кажеме дека веројатноста
9516програмата да не „падне“ по 1000 CPU часа
9517работа во просечна околина е поголема од 0.995.
9518Тестирање
951911
9520ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9521И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9522 Logarithmic Poisson execution-time model
9523каде
9524f(t)- е очекуваниот кумулативен број на грешки кои
9525настанале за одредено време на извршување t
9526l0 - иницијален интензитет на испади (бр. на испади во
9527единица време на почетокот на тестирањето)
9528p - експоненцијално намалување на интензитетот на
9529испади со откривањето и поправањето на грешките
9530Тековната вредност на интензитетот на испади се
9531добива како извод на f(t)
9532( ) (1/ )ln( 1) f t = p l0 pt +
9533( ) /( 1) f t = l0 l0 pt +
9534Тестирање
953512
9536ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9537И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9538СОФТВЕРСКО ИНЖЕНЕРСТВО
9539Failure model
9540 Може да се предвиди ратата на испади во текот на
9541тестирањето. Ако измерените вредности разумно се
9542совпаѓаат со кривата на моделот – ќе може да се
9543предвиди потребното време за кривата да падне под
9544одредено ниво
9545Execution time,t
9546l
95470
9548Predicted ailure intensity. l( t)
9549Data collected during testing
9550Тестирање
955113
9552ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9553И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9554СОФТВЕРСКО ИНЖЕНЕРСТВО
9555Strategic Issues
9556 Specify product requirements in a
9557quantifiable manner long before testing
9558commences.
9559 State testing objectives explicitly.
9560 Understand the users of the software and
9561develop a profile for each user category.
9562 Develop a testing plan that emphasizes
9563“rapid cycle testing.”
9564Тестирање
956514
9566ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9567И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9568СОФТВЕРСКО ИНЖЕНЕРСТВО
9569Strategic Issues
9570 Build “robust” software that is designed to
9571test itself.
9572 antibugging techniques, automated and regression
9573testing
9574 Use effective formal technical reviews as a
9575filter prior to testing.
9576 Conduct formal technical reviews to
9577assess the test strategy and test cases
9578themselves.
9579 Develop a continuous improvement
9580approach for the testing process.
9581Тестирање
958215
9583ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9584И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9585СОФТВЕРСКО ИНЖЕНЕРСТВО
9586Unit testing
9587 Верификација на
9588најмалите делови на
9589софтверскиот дизајн –
9590компоненти и модули
9591 white-box
9592 паралелно
9593Цел – откривање на грешки:
9594 во пресметки
9595 во споредувања
9596 во контролен тек Test
9597cases
9598Module Interface
9599Local data structures
9600Boundary conditions
9601Independent paths
9602Error handling paths
9603Тестирање
960416
9605ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9606И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9607СОФТВЕРСКО ИНЖЕНЕРСТВО
9608More Common Errors in Computation
96091. misunderstood or incorrect arithmetic
9610precedence
96112. mixed mode operations
96123. incorrect initialization
96134. precision inaccuracy
96145. incorrect symbolic representation of an
9615expression
9616Тестирање
961717
9618ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9619И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9620СОФТВЕРСКО ИНЖЕНЕРСТВО
9621Common Errors in Control
9622 Comparison and control flow are closely coupled to one
9623another (i.e., change of flow frequently occurs after a
9624comparison). Test cases should uncover errors such as:
96251. comparison of different data types
96262. incorrect logical operators or precedence,
96273. expectation of equality when precision error makes
9628equality unlikely
96294. incorrect comparison of variables
96305. improper or nonexistent loop termination
96316. failure to exit when divergent iteration is encountered,
9632and
96337. improperly modified loop variables
9634Тестирање
963518
9636ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9637И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9638СОФТВЕРСКО ИНЖЕНЕРСТВО
9639Error handling testing
96401. Error description is unintelligible.
96412. Error noted does not correspond to error
9642encountered.
96433. Error condition causes system intervention
9644prior to error handling.
96454. Exception-condition processing is incorrect.
96465. Error description does not provide enough
9647information to assist in the location of the cause
9648of the error.
9649Тестирање
965019
9651ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9652И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9653СОФТВЕРСКО ИНЖЕНЕРСТВО
9654Unit Test Procedures
9655 Because a
9656component is not a
9657stand-alone program,
9658driver and/or stub
9659software must be
9660developed for each
9661unit test.
9662 Drivers and stubs
9663represent overhead.
9664Test
9665cases
9666Interface
9667Local data structures
9668Boundary conditions
9669Independent paths
9670Error handling paths
9671Module
9672to be
9673tested
9674Stub Stub
9675Driver
9676RESULTS
9677Тестирање
967820
9679ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9680И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9681СОФТВЕРСКО ИНЖЕНЕРСТВО
9682Integration Testing
9683 Интеграција – интерфејси
9684 кумулативна непрецизност
9685 глобални податоци
9686 “big bang” approach
9687 incremental integration
9688програмата се интегрира и тестира во мали
9689инкременети при што грешките полесно се
9690изолираат и поправаат
9691систематски пристап
9692Тестирање
969321
9694ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9695И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9696СОФТВЕРСКО ИНЖЕНЕРСТВО
9697Top-down Integration
9698 Модулите се интегрираат движејќи се
9699надолу во контролната хиерархија (се
9700почнува со главната програма)
9701 Модулите се интегрираат или во
9702длабочина (depth-first) или во широчина
9703(breadth-first)
9704Тестирање
970522
9706ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9707И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9708СОФТВЕРСКО ИНЖЕНЕРСТВО
9709Top-down Integration
9710M1
9711M2 M3
9712M5 M6 M7
9713M8
9714M4
9715Тестирање
971623
9717ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9718И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9719СОФТВЕРСКО ИНЖЕНЕРСТВО
9720Integration Process Steps
9721The integration process is performed in a series of five
9722steps:
97231. The main control module is used as a test driver and
9724stubs are substituted for all components directly
9725subordinate to the main control module.
97262. Depending on the integration approach selected (i.e.,
9727depth or breadth first), subordinate stubs are replaced
9728one at a time with actual components.
97293. Tests are conducted as each component is integrated.
97304. On completion of each set of tests, another stub is
9731replaced with the real component.
97325. Regression testing may be conducted to ensure that
9733new errors have not been introduced.
9734Тестирање
973524
9736ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9737И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9738СОФТВЕРСКО ИНЖЕНЕРСТВО
9739Top-down Integration
9740 Top-down пристапот за интеграција ги
9741верификува клучните контролни
9742структури и точки на одлука рано во
9743процесот на тестирање
9744 confidence builder
9745 stubs, drivers = overhead
9746Тестирање
974725
9748ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9749И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9750СОФТВЕРСКО ИНЖЕНЕРСТВО
9751Bottom-up Integration
9752 Го почнува тестирањето и
9753обединувањето на модулите и
9754компонентите на најниското ниво на
9755програмската структура и се движи
9756нагоре (no stubs)
9757Тестирање
975826
9759ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9760И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9761СОФТВЕРСКО ИНЖЕНЕРСТВО
9762Integration Process Steps
9763A bottom-up integration strategy may be
9764implemented with the following steps:
97651. Low-level components are combined into
9766clusters (sometimes called builds) that perform
9767a specific software subfunction.
97682. A driver (a control program for testing) is
9769written to coordinate test case input and output.
97703. The cluster is tested.
97714. Drivers are removed and clusters are combined
9772moving upward in the program structure.
9773Тестирање
977427
9775ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9776И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9777СОФТВЕРСКО ИНЖЕНЕРСТВО
9778Bottom-up Integration
9779M c
9780Ma
9781D2 D3 D1
9782Mb
9783Cluster 1
9784Cluster 3
9785Cluster 2
9786Тестирање
978728
9788ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9789И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9790СОФТВЕРСКО ИНЖЕНЕРСТВО
9791Regression Testing
9792 Со секое додавање на нов модул во
9793процесот на интеграција софтверот се
9794менува
9795 Регресиски тестови – повторно
9796извршување на подмножество на веќе
9797спроведени тестови со цел да се
9798провери дека промените не
9799предизвикале несакани споредни
9800ефекти
9801 capture/playback tools
9802Тестирање
980329
9804ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9805И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9806СОФТВЕРСКО ИНЖЕНЕРСТВО
9807Regression Test Types
9808The regression test suite (the subset of tests to be
9809executed) contains three different classes of test
9810cases:
9811 A representative sample of tests that will
9812exercise all software functions.
9813 Additional tests that focus on software functions
9814that are likely to be affected by the change.
9815 Tests that focus on the software components
9816that have been changed.
9817Тестирање
981830
9819ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9820И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9821СОФТВЕРСКО ИНЖЕНЕРСТВО
9822Smoke Testing
98231. Software components that have been translated into
9824code are integrated into a “build.” A build includes all
9825data files, libraries, reusable modules, and engineered
9826components that are required to implement one or more
9827product functions.
98282. A series of tests is designed to expose errors that will
9829keep the build from properly performing its function. The
9830intent should be to uncover “show stopper” errors that
9831have the highest likelihood of throwing the software
9832project behind schedule.
98333. The build is integrated with other builds and the entire
9834product (in its current form) is smoke tested daily. The
9835integration approach may be top down or bottom up.
9836Тестирање
983731
9838ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9839И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9840СОФТВЕРСКО ИНЖЕНЕРСТВО
9841Smoke Testing Benefits
9842 Smoke testing provides a number of
9843benefits when it is applied on complex,
9844timecritical software engineering projects:
9845 Integration risk is minimized.
9846 The quality of the end-product is improved.
9847 Error diagnosis and correction are
9848simplified.
9849 Progress is easier to assess.
9850Тестирање
985132
9852ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9853И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9854СОФТВЕРСКО ИНЖЕНЕРСТВО
9855 Предности и недостатоци на top-down и
9856bottom-up пристапите
9857 Sandwich testing
9858 Идентификација на критичните модули и
9859нивно тестирање што е можно порано
9860 addresses several software requirements
9861 has a high level of control (resides relatively high in
9862the program structure)
9863 is complex or error prone (cyclomatic complexity may
9864be used as an indicator), or
9865 has definite performance requirements.
9866Тестирање
986733
9868ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9869И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9870СОФТВЕРСКО ИНЖЕНЕРСТВО
9871Integration Test Documentation
9872 Целосниот план за интеграција на компонентите и
9873опис на специфичните тестови како и на генералната
9874методологија се документира во test specification и
9875содржи план и процедури за тестирање кое може да
9876биде поделено во фази
9877 Критериуми при тестирањето:
9878 Interface integrity
9879 Functional validity
9880 Information content
9881 Performance
9882 Опис на дополнителниот софтвер (stubs and drivers)
9883 Опис на околината за тестирање и потребните
9884ресурси (хардвер, симулатори, ...)
9885Тестирање
988634
9887ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9888И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9889СОФТВЕРСКО ИНЖЕНЕРСТВО
9890Testing in the OO Context
9891 Unit Testing in the OO Context
9892 Integration Testing in the OO Context
9893thread-based testing (respond to one input or
9894event)
9895use-based testing (independent classes - use
9896very few server classes toward dependent
9897classes)
9898Stubs/drivers
9899Cluster testing
990035
9901Тестирање
9902ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9903И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9904СОФТВЕРСКО ИНЖЕНЕРСТВО
9905Validation Testing
9906 Почнува откако софтверот е целосно
9907интегриран
9908 Дали софтверот ги задоволува
9909очекувањата на клиентот (според
9910Software Requirements Specification – ги
9911опишува кориснички видливите
9912атрибути на софтверот)
9913 Серија на black-box тестови (deficiency
9914list)
9915 Alpha and Beta Testing
9916Тестирање
991736
9918ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9919И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9920СОФТВЕРСКО ИНЖЕНЕРСТВО
9921System Testing
9922 Recovery Testing
9923 forces the software to fail and than recover
9924 Security Testing
9925 verify that protection mechanisms built into a system
9926will, protect it from improper penetration
9927 Stress Testing
9928 executes a system in a manner that demands
9929resources in abnormal quantity, frequency, or volume
9930 Performance Testing
9931 Deployment testing (configuration testing)
9932Тестирање
993337
9934ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9935И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9936СОФТВЕРСКО ИНЖЕНЕРСТВО
9937Debugging
9938 Како последица на успешните тестови – откриените грешки треба да се поправат – debugging
9939Identified
9940causes
9941Suspected
9942causes
9943Additional
9944tests
9945Corrections
9946Regression
9947tests
9948Execution
9949of cases
9950Results
9951Test
9952cases
9953Debugging
9954Тестирање
995538
9956ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9957И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9958СОФТВЕРСКО ИНЖЕНЕРСТВО
9959 Дебагирање – барање и поправање на грешки – барање на
9960причината за забележана последица (дополнителни тестови за
9961прецизно лоцирање на проблемот)
9962 Зошто дебагирањето е тешко:
99631. The symptom and the cause may be geographically remote.
99642. The symptom may disappear (temporarily) when another error is
9965corrected.
99663. The symptom may actually be caused by nonerrors (e.g., round-off
9967inaccuracies).
99684. The symptom may be caused by human error that is not easily traced.
99695. The symptom may be a result of timing problems, rather than processing
9970problems.
99716. It may be difficult to accurately reproduce input conditions (e.g., a real- time application in which input ordering is indeterminate).
99727. The symptom may be intermittent. This is particularly common in
9973embedded systems that couple hardware and software inextricably.
99748. The symptom may be due to causes that are distributed across a number
9975of tasks running on different processors.
9976Тестирање
997739
9978ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9979И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9980СОФТВЕРСКО ИНЖЕНЕРСТВО
9981Debugging Approaches
9982 Целта е да се пронајде и исправи
9983забележана аномалија – зависи од:
9984 системски пристап
9985 интуиција
9986 среќа
9987 Debugging approaches
9988 brute force,
9989 backtracking,
9990 cause elimination.
9991 When all else fails, get help!
9992Тестирање
999340
9994ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
9995И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
9996СОФТВЕРСКО ИНЖЕНЕРСТВО
9997Пред да се поправи грешката
9998 Three simple questions that every software engineer
9999should ask before making the "correction" that removes
10000the cause of a bug:
100011. Is the cause of the bug reproduced in another part
10002of the program?
10003 erroneous pattern of logic that may be reproduced elsewhere
100042. What "next bug" might be introduced by the fix I'm
10005about to make?
10006 If the correction is to be made in a highly coupled section of the
10007program, special care must be taken when any change is made.
100083. What could we have done to prevent this bug in the
10009first place?
10010 establishing a statistical software quality assurance approach
10011Тестирање
1001241
10013ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ НАУКИ
10014И КОМПЈУТЕРСКО ИНЖЕНЕРСТВО
10015СОФТВЕРСКО ИНЖЕНЕРСТВО
10016Прашања?
1001742
10018Тестирање
10019_______________________________________________________________________________________________________________________________________