Problemos, kurias dažnai turi spręsti programinės įrangos inžinieriai, yra labai sudėtingos. Suprasti problemų pobūdį gali būti labai sunku, ypač jei sistema yra nauja.
Todėl sunku tiksliai apibrėžti, ką sistema turėtų daryti. Paslaugų ir apribojimų aprašymai yra reikalavimai sistemai, o šių paslaugų ir apribojimų atradimo, analizės, dokumentavimo ir tikrinimo procesas vadinamas reikalavimų inžinerija. Daugelis programinės įrangos inžinerijos problemų kyla dėl netikslumo nustatant reikalavimus. Natūralu, kad sistemų kūrėjas pateikia aiškinimą dėl dviprasmiško reikalavimo, kad būtų supaprastintas jo įgyvendinimas. Tačiau dažnai tai nėra tai, ko nori klientas. Turi būti nustatyti nauji reikalavimai ir padaryti sistemos pakeitimai. Be abejo, tai atidėlioja pristatymą ir padidina išlaidas.
Sistemos vartotojo reikalavimai apibūdina funkcinius ir nefunkcinius reikalavimus taip, kad jie būtų suprantami sistemos vartotojams, neturintiems išsamių techninių žinių. Jie tik nurodo išorinį sistemos elgesį ir, kiek įmanoma, vengia sistemos projektavimo ypatumų. Todėl vartotojo reikalavimai neturėtų būti apibrėžti naudojant diegimo modelį. Jie turėtų būti parašyti natūralia kalba, paprastomis schemomis ir vaizdais.
Kai vartotojo reikalavimuose yra per daug informacijos, jie riboja sistemos kūrėjo laisvę pateikti novatoriškus vartotojo problemų sprendimus ir daro reikalavimus sunkiai suprantamus. Vartotojų reikalavimai turėtų būti sutelkti ties pagrindiniais teikiamais ištekliais.
Programinės įrangos procesas yra veiklos ir susijusių rezultatų, kurie lemia programinės įrangos produkto sukūrimą, rinkinys. Tai gali būti programinės įrangos kūrimas nuo nulio, nors nauja programinė įranga vis labiau kuriama plečiant ir modifikuojant esamas sistemas. Viena iš priežasčių, kodėl automatikos procesui skiriamas ribotas dėmesys, yra didžiulė programinės įrangos procesų įvairovė. Idealaus proceso nėra, o skirtingos organizacijos sukūrė visiškai skirtingą programinės įrangos kūrimo metodą. Procesai vystėsi siekiant išnaudoti organizacijos žmonių galimybes, taip pat specifines kuriamų sistemų savybes. Todėl net toje pačioje organizacijoje gali būti daugybė skirtingų programinės įrangos kūrimo procesų.
La metodología del Proceso Unificado de Desarrollo (RUP) traza pautas muy concretas para el desarrollo de proyecto de software, define en un enfoque de alta colaboración, evolutivo y flexible para asimilar los cambios en los requerimientos del software en un ambiente de negocios dinámico. De igual forma define claramente los hitos donde son necesarias la revisiones formales del proyecto, las cuales incluyen la aprobación por parte del cliente. A continuación se puede apreciar en el diagrama el ciclo de vida de un proyecto de software basado en RUP:
Jo evoliucinis požiūris apima iteracinį ir laipsnišką vystymąsi. Pasikartojantis pobūdis yra kairėje diagramos pusėje esančiose veiklose (reikalavimai, analizė, dizainas ir kt.); Intensyvus vystymasis atliekamas per tam tikrą laiką prototipų formavimu, sukurtu per visą prototipą. Kūrimo etape yra kuriamas prototipas su architektūra, kuri apima didesnės techninės rizikos naudojimo atvejus. Savo ruožtu, programinė įranga taip pat, kaip ir kūrimo etape, kiekvienos iteracijos pabaigoje yra gaminama taip pat, kaip ir kūrimo etape, ją galima naudoti testavimo tikslais arba demonstravimo programinę įrangą klientui. Kiekvieną kartą pasibaigus iteracijai, tai pažymi esmę, kur būtina peržiūrėti klientą,kur analizuojamas reikalavimų vykdymas, projekto eiga, analizuojamos realios ir planuojamos išlaidos. Paskutinės kartojimo, atitinkančio kiekvieną projekto etapą, atveju, klientas turi sukurti patvirtinimo dokumentą, kuriame klientas siūlo savo sutikimą su projekto pasiekimais, tokiu būdu priimdamas finansinę ir techninę programinės įrangos prasmę. kad vystosi.
Pradiniame plėtros etape (Concepción) sukuriami projekto pagrindai. Apibrėžta apimtis, pradinis planas, verslo vizija su tikslais ir projekto pagrindimas. Šie artefaktai yra tobulinami viso projekto plėtros metu. Pradiniai reikalavimai nustatomi naudojimo atvejais.
Šiame etape jūs pradedate galvoti apie pradinę sistemos architektūrą verslo ir techniniu požiūriu. Šis procesas apima koncepcinio modelio ir diegimo modelio sukūrimą, ir šiame etape - aukšto lygio.
Aukšto lygio projekto planas yra apibrėžtas ir vėliau tobulinamas į išsamesnį planą. Aukšto lygio plane nagrinėjamos pagrindinės priklausomybės ir bendra strategija, tuo tarpu patobulinti planai (atitinkantys išsamesnes iteracijas) tvarko taktiką, tinkančią kiekvienos iteracijos situacijoms. Planuojant projektą reikia atsižvelgti į ilgalaikius veiksmus, tokius kaip operacijos, palaikymas ir nuolatinis tobulinimas.
Šis projektavimo etapas baigiasi užtikrinant apibrėžtos srities, plėtros plano ir rizikos analizės buvimą, kai klientai sutinka su tuo, kas išdėstyta, ir turi perspektyvią duomenų saugyklos statybos strategiją.
Šiame etape yra keletas bendrų klaidų, turėtumėte vengti:
- Pagalvokite, kad tai yra tradicinio reikalavimų nustatymo etapas. Pagalvokite, kad turite turėti tobulus modelius ir planus. Projekto pradžioje pabandykite sukurti išsamų duomenų modelį.
Sukurti artefaktai:
- Projekto plano vizijos naudojimo atvejų koncepcijos diagrama Diegimo schema Kliento patvirtinimo dokumentas
Priežastys, kodėl organizacijos naudoja RUP programinės įrangos projektams kurti:
- RUP kontroliuoja apimties riziką: RUP pripažįsta faktą, kad kuriant reikalavimus keičiasi reikalavimai, ir apibrėžia lankstų požiūrį į šių reikalavimų kontrolę. Bandymas išsamiai apibrėžti reikalavimus projekto pradžioje yra labai rizikingas sprendimas. RUP neapsiriboja duomenimis: viena iš priežasčių, kodėl programinės įrangos projektai žlunga, yra nepakankama verslo vertė. Identifikuodamas ir sutelkdamas dėmesį į verslo vertę naudojimo atvejais, RUP įgyja poreikių vaizdą, pageidautina, kad būtų orientuotas į duomenis. RUP anksti kontroliuoja techninę riziką: daugelis programinės įrangos projektų žlunga dėl pasitikėjimo, kad Jie pateikia anksti sukurtus išsamius modelius. Jei duomenų modelis yra labai išsamus,Joje užfiksuota „unikali tiesa“ ir jie praleido mėnesius prie to darbo. Problema ta, kad bet kokia architektūra gerai veikia popieriuje. Kol architektūra nebus patikrinta kodu, jūs negalite būti tikri, ar ji tinkamai veikia. RUP kontroliuoja riziką. Finansinis: iteracinis ir laipsniškas vystymasis, kuris anksti valdo svarbiausius projekto komponentus, garantuoja, kad pirmiausia garantuojama didžiausia funkcionalumo vertė, visą laiką maksimaliai padidinant investicijų grąžą. RUP leidžia greitai ir greitai judėti: programinė įranga yra sudėtinga, reikalingas lankstumas, tačiau tuo pačiu išlaikant kontrolės lygį, kad plėtra būtų efektyvi.Kol architektūra nebus patikrinta su kodu, negalite būti tikri, ar ji tinkamai veikia RUP kontroliuoja finansinę riziką: pasikartojanti ir pamatinė plėtra, kuri anksti valdo kritinius projekto komponentus, užtikrina, kad pirmiausia garantuojama didžiausia funkcionalumo vertė. visą laiką maksimaliai padidindama investicijų grąžą. „RUP“ leidžia disciplinuotai pasiekti judrumą: programinės įrangos projektai yra sunkūs, reikalingas lankstumas, tačiau tuo pačiu išlaikant kontrolės lygį, kad plėtra būtų efektyvi.Kol architektūra nebus patikrinta su kodu, negalite būti tikri, ar ji tinkamai veikia RUP kontroliuoja finansinę riziką: pasikartojanti ir pamatinė plėtra, kuri anksti valdo kritinius projekto komponentus, užtikrina, kad pirmiausia garantuojama didžiausia funkcionalumo vertė. visą laiką maksimaliai padidindama investicijų grąžą. „RUP“ leidžia disciplinuotai pasiekti judrumą: programinės įrangos projektai yra sunkūs, reikalingas lankstumas, tačiau tuo pačiu išlaikant kontrolės lygį, kad plėtra būtų efektyvi.Visą laiką maksimaliai padidinkite IG. RUP leidžia greitai ir greitai valdyti judrumą: sunku įgyvendinti programinės įrangos projektus, reikalingas lankstumas, tačiau tuo pačiu išlaikant kontrolės lygį, kad plėtra būtų efektyvi.Visą laiką maksimaliai padidinkite IG. RUP leidžia greitai ir greitai valdyti judrumą: sunku įgyvendinti programinės įrangos projektus, reikalingas lankstumas, tačiau tuo pačiu išlaikant kontrolės lygį, kad plėtra būtų efektyvi.
Reikalavimų pokyčiams reikalingas evoliucinis ir lankstus, aukšto lygio bendradarbiavimas. Vieningas plėtros procesas (RUP) nusako tokį požiūrį.
Bibliografija
Ian Sommerville, „ Programinės įrangos inžinerija “, 6-asis leidimas. „Pearson Education“, 2002 m.
I. Archer Pupo, „Vieningo vystymosi proceso fazės“.
