Процес за развој на информациски систем
Избор на процес за развој
На почетокот кога почнале да се конструираат софтверските системи, истите се имплементирале без притоа да се прави одредена анализа за софтверскиот продукт. Целата работа околу создавањето на софтверскиот продукт била препуштена на програмерите и главен процес притоа било програмирањето. Програмерите добивале документ со корисничките побарувања и според нив и нивното искуство тие го конструирале бараниот софтвер. Се разбира тогаш бараните софтвери биле едноставни и не многу обемни и комплицирани. Во денешно време не е можно да се конструира софтвер без притоа да се искористи некоја од познатите методологии.
Техника која ќе ја користиме за да го изработиме ERP системот на TrainTraveller е објектно ориентираната методологија – RUP развојниот процес.
Дефиниција – Што е RUP?
RUP e добро дефиниран и структуриран процес за развој на софтверски систем којшто користи техники и алатки, коишто го помагаат програмирањето и имплементацијата на продуктот. Со други зборови RUP му обезбедува на продуктот индивидуализирана рамка за развојот на процесот, која што е прилагодлива и компанијата за која се развива системот сама ги бира елементите од процесот потребни за негов развој, т.е. RUP не е единствен конкретен утврден процес.
RUP бил креиран и првично се развивал во рамките на компанијата Rational Software Corporation, а потоа оваа компанија ја завзема компанијата IBM, а со неа и RUP.
RUP - карактеристики
Како и секој друг процес така и RUP има главни карактеристики кои целосно го опишуваат. Според главните карактеристики на RUP, тој се опишува како процесот што:
- се води според корисничките случаи
- е централизиран на архитектура
- е повторлив и постепен.
Овој процес не може без ниту една од наведените карактеристики, т.е. и трите карактеристики му се потребни за успешно развивање на системот. Покрај тоа и користењето техники, алатки и компоненти е неизбежно.
Воден од корисничките случаи
Согласно со карактеристиката дека се води според корисничките случаи, побарувањата на клиентите се изразуваат преку тие кориснички случаи. Тие ја доловуваат целосната функционалност на системот, но не само тоа, истите се користат за дизајнирање на системот, спроведување на развојниот процес и крајното тестирање на системот, со цел да се увиди дека системот ги исполнува барањата на клиентот, затоа што како што знаеме, клиентот и неговите побарувања се суштината на системот.
Централизиран на архитектурата
Што се однесува до архитектурата, RUP најмногу се фокусира на архитектурата со цел да се претстави и увиде системот уште пред да се имплементира. Содржи детали за платформата на системот и неговите нефункционалности. Најпрво се поставува опис на архитектурата во кратки црти, а потоа со развојот на процесот низ фазите на RUP истата се менува и детално се опишува. RUP подржува повеќе архитектурни модели и погледи и нуди методичен и системски начин на дизајнирање и валидирање на архитектурата. Сето тоа, т.е. имањето робустна архитектура при развојот на системот овозможува паралелен развој, минимизација на потребата од постојано преизработување на процесот и зголемување на повторното користење на компонентите на системот којшто се развива.
Итеративен и постепен процес
Последната, но не и помалку важна карактеристика на RUP e тоа што е повторлив и постепен. Поради сложеноста на системите кои се развиваат, потребно е барањата постепено да се развиваат и да се додефинираат, затоа што тие неможат да бидат целосно прецизни и добро дефинирани уште при првото дефинирање. Како што се менуваат условите и како што се стекнува разбирање со клиентите истите постепено се развиваат. Па според тоа процесот на развој се дефинира како серија контролирани повторувања. Од таа причина RUP процесот е составен од четири фази и секоја фаза се состои од неколку итерации во зависност од системот кој се развива. Архитектура на RUP
Во делот каде што опишавме дека RUP е итеративен и постепен процес, увидовме дека овој процес е составен од четири фази (иницијација, елаборација, конструкција и транзиција) и секоја фаза од неколку итерации.
Како што знаеме, RUP не е конкретно дефиниран, па според тоа фазите можат да се повторуваат, секоја фаза повеќе пати едно по друго или целото множество да се повтори повеќе пати во рамките на работните текови, се со цел успешно развивање на процесот.
Работните текови, секвенци на активности, кои се користат во RUP се :
- Деловно (бизнис) моделирање – се моделираат бизнис процесите преку кориснички случаи, се утврдува контекстот на системот
- Барања – се развиваат корисничките случаи и визијата на системот
- Анализа и дизајн – опис на архитектурата на системот, преку модели на компоненти, архитектурни модели, модели на секвенци и сл.
- Имплементација – користење на моделите на дизајн за имплементација на подсистемите и генерирање на код
- Тестирање – итеративен процес што се одвива низ сите фази, паралелно со имплементацијата и се користи за утврдување дали се исполнети барањата, функционалностите, сигурноста и перформансите на системот
- Поставување – се поставува комплетиран систем кај корисниците, истиот се инсталира, а корисниците се обучуваат
- Конфигурација и менаџирање со промени – се одржува и следи системот, се утврдуваат и се извршуваат промените во системот, доколку постојат
- Менаџирање со проектот – надгледување и управување со проектот, користејќи техники и алатки, со цел утврдување на успешноста на системот
- Околина – избор и набавка на соодветни алатки кои ќе се користат при развој на процесот
Иницијација (Зачеток)
Иницијацијата е првата од четирите фази кои го сочинуваат RUP процесот. Оваа фаза е многу кратка и служи за поставување на идејата на системот и утврдување на придонесот и ресурсите. Според тоа најпрво се реализира и пишува визијата на системот, па се дефинираат бизнис случаите, со кои овој систем е засегнат, се идентификуваат ризиците и се дефинира опсегот на системот. Покрај тоа се пресметува колкав ќе биде придонесот на системот и дали е вреден за понатамошно развивање.
Елаборација
Во фазата на елаборација најпрво се поставува и опишува архитектурата на системот. Притоа се дизајнираат дијаграми на кориснички случаи, класни и архитектурни дијаграми. Оваа фаза се состои од повеќе временски ограничени итерации за постигнување на целта. Во оваа фаза се пресметуваат и ризичните фактори и утврдување дека избраната архитектура ќе одговара на спецификациите на системот. Со завршување на споменатото, за крај на оваа фаза се поставува и план за фазата на конструкција.
Конструкција
Оваа е најголемата фаза од процесот. По поставената архитектура, системот се дизајнира, т.е. имплементира на делови, а потоа и се тестира. Како и елаборациската фаза и оваа фаза е составена од повеќе временски ограничени итерации. Со завршување на оваа фаза имаме готов функционален систем, заедно со негова документација.
Транзиција (премин)
При оваа фаза, системот се пренесува и инсталира во околината на крајните корисници. Во зависност од повратната информација на корисниците, системот може да се доработи и ажурира. Покрај конверзијата на системот оваа фаза и вклучува и обука на крајните корисници. Доколку се е во ред, овде завршува процесот на развој на систем – RUP.
Примена на RUP во TrainTraveller
Иницијализација за TrainTraveller
Како почеток ја имаме фазата за иницијализација на проектот. Во оваа фаза би имале две итерации, каде што ќе ги креираме корисничките барања, визијата на системот и анализата на ризиците.
1 - итерација
На почеток треба да се одржи состанок со компанијата којашто го нарачува системот и со сите заинтересирани страни. На овој состанок треба клиентот да ги изложи своите барања. Откако ќе заврши состанокот на тимот со клиентот, тимот се состанува и дискутира за системот. Потоа се пишува визијата на системот, и се составуваат корисничките барања според забелешките од состанокот. Со готова визија и првично дефинирани кориснички барања се завршува оваа итерација.
2 - итерација
Откако ќе заврши првата итерација, тимот повторно се состанува со клиентот, со што му ги презентира визијата и корисничките барања. На овој состанок тимот проверува дали правилно ги разбрал корисничките барања за да продолжи со развивање на системот понатаму. После состанокот тимот ги доработува и детализира визијата и корисничките барања и прави анализа на ризиците и придонесите од овој систем, со што одлучува да продолжи понатаму со развивање на истиот. На крај од оваа итерација тимот прави план за фазата на елаборација.
Доколку бидат потребни повеќе итерации при развојот на системот истите ќе бидат овозможени.
Елаборација за TrainTraveller
После фазата на иницијација, следува фазата на елаборација. Оваа фаза е подолга од фазата на иницијација. Во оваа фаза може да има од две до четири итерации во зависност од состаноците со клиентите и соработката меѓу тимот. Да претпоставиме дека оваа фаза ќе се содржи од четири итерации со цел да можеме да го пресметаме максималното време потребно за изработка на овој информациски систем.
1 – итерација
На почеток ја поставуваме прелиминарната архитектура на системот. Имаме повторна средба со клиентот за собирање на детали за корисничките барања и дефинирање на конечниот use case модел. Користејќи ја техниката на UML дијаграмите се опишува поставената архитектура.
2 – итерација
Во втората итерација ќе извршиме анализа на корисничките случаи и операциска анализа. Притоа ќе почнеме со детализирање на дијаграмите кои ја опишуваат кандидат архитектурата. Со тоа ќе го креираме првиот архитектурен прототип.
3 – итерација
Во следните две итерации повторно ќе се состанеме со клиентите, со цел собирање на повеќе детали и претставување на архитектурните прототипови. Исто така ќе продолжиме да ги детализираме UML дијаграмите (класни, секвенцни и дијаграми на активности) со цел да го достигнеме посакуваниот модел.
4 – итерација
На крај ги доработуваме графиците кои ја опишуваат архитектурата на информацискиот систем, со што го достигнуваме нивниот краен модел и му го претставуваме на клиентот конечниот архитектурен прототип. Исто така на крајот од оваа фаза во оваа итерација го дефинираме планот за фазата на конструкција.
Конструкција за TrainTraveller
Откако ја дефиниравме визијата, корисничките барања и архитектурата на системот, ќе почнеме со негова имплементација. Фазата на конструкција одзема најмногу време. Нашиот систем содржи 18 кориснички барања (use cases), па според тоа во оваа фаза е потребно секој use case посебно да се развие, да се дизајнира и имплементира. Потоа секој use case се интегрира во системот и накрај секој се тестира и се поправаат грешките доколку се појават.
1 – итерација
Најпрвин ги дизајнираме и имплементираме еден по еден секој од дефинираните кориснички барања. Како што ќе се комплетираат еден по еден секој од нив ќе се интегрира во системот. Накрај го извршуваме првиот прототип и му го претставуваме на клиентот.
2 – итерација
Во втората итерација ќе ги тестираме корисничките барања еден по еден и ќе ги поправаме грешките. Исто така доколку има забелешки од состанокот со клиентот истите ќе се досредат. Накрај од оваа итерација се прави документацијата за корисникот и правиме план за фазата на Транзиција.
Транзиција за TrainTraveller
Во оваа фаза потребно е системот којшто го развивме, да го пренесеме во околината на корисниците, а потоа да ги обучиме корисниците за работа со истиот. Според тоа сметаме дека сето ова може да го завршиме во една итерација.
1 – итерација
Во оваа итерација најпрво ќе го пренесеме готовиот систем во околината на корисниците и ќе го инсталираме таму каде што ќе биде потребно. По сето ова ќе ја извршиме потребната обука на корисниците за користење на системот. Со тоа се завршува и целиот развој на нашиот систем користејќи го RUP просецот.
