Vizito Encydia-Wikilingue.Com

Programaro

programaro - Wikilingue - Encydia

ĝi konas kiel programaro[1] al la equipamiento logika aŭ logika apogo de cifereca komputilo; ĝi komprenas la aron de la necesaj logikaj komponantoj kiu faras ebla la realigo de specifaj taskoj, en contraposición al la fizikaj komponantoj de la sistemo, nomita aparataro.

Tiaj logikaj komponantoj inkludas, inter multaj aliaj, komputikaj aplikoj —kiel la tekstoprilaborilo, kiu permesas al la uzanto realigi ĉiujn taskojn concernientes al la eldono de tekstoj— aŭ la programaro de sistemo —kiel la mastruma sistemo, kiu, esence, ĝi permesas al la resto de la programoj funkcii adekvate, havigante la interago kun la fizikaj komponantoj kaj la resto de la aplikoj, havigante ankaŭ interfaco por la uzanto—.

Enhavo

Etimologio

Programaro (prononco AFI:[soft'ɣware])[2] estas devena vorto de la anglo (laŭvorte: mildaj aŭ molaj partoj), kiu en la hispana ne posedas taŭgan tradukadon al la kunteksto, por kiu uzas ŝin al li asiduamente sen traduki kaj tiel estis akceptita de la Reala Hispana Akademio (RAE).[3] Kvankam ne estas strikte lin sama, ĝi kutimas anstataŭi por esprimoj tiaj kiel programoj (komputikaj) aŭ aplikoj (komputikaj).[4]

Programaro estas kion nomas produkto en Inĝenierio de Programaro.[5]

Difino de programaro

Probable la plej formala difino de programaro estas la sekva:

Estas la aro de la programoj de cómputo, proceduroj, reguloj, dokumentado kaj datumoj asociita ke ili formas parton de la operacioj de sistemo de komputado.
Ĉerpita de la normo 729 de la IEEE[6]

Konsiderante ĉi tiu difino, la koncepto de programaro iras pli tie de la programoj de cómputo en liaj malsamaj statoj: kodo fonto, binara aŭ ejecutable; ankaŭ lia dokumentado, datumoj al procesi kaj informo de uzanto formas parton de la programaro: tio estas, ĝi ĉirkaŭprenas ĉiu lin intangible, ĉiu lin "ne fizikisto" rilatigita.

La termino «programaro» estis uzita por la unua fojo en ĉi tiu senso por John W. Tukey en 1957. En la sciencoj de la komputado kaj la inĝenierio de programaro, la programaro estas la tuta informo procesita de la komputikaj sistemoj: programoj kaj datumoj. La koncepto de legi malsamajn sekvencojn de instrukcioj de la memoro de mekanismo por kontroli la ŝtonojn estis enkondukita de Babilas Babbage kiel ĝi dividas de lia maŝino diferencial. La teorio kiu formas la bazon de la plej granda parto de la moderna programaro estis proponita de unua fojo por Alan Turing en lia provo de 1936, "La numeroj computables", kun apliko al la problemo de decido.

Klasifiko de la programaro

Se bone ĉi tiu distingo estas, en iu modo, arbitra, kaj kelkfoje malklara, al la oportunaj finoj povas klasifiki al la programaro en tri grandaj tipoj:

Procezo de kreo de la programaro

ĝi difinas kiel Procezo al la ordema aro de paŝoj al sekvi por alveni al la solvo de problemo aŭ obtención de produkto, en ĉi tiu aparta kazo, por sukcesi la obtención de produkto programaro kiu solvas problemon.

La procezo de kreo de programaro povas alveni al esti tre kompleksa, dependante de lia portas, karakterizaj kaj criticidad de la sama. Ekzemple la kreo de mastruma sistemo estas tasko kiu postulas projekton, demarŝo, multnombraj rimedoj kaj ĉiu la teamo disciplinado de laboro. En la alia ekstrema, se ĝi klopodas simplan programon (ekzemple, la rezolucio de ekvacio de dua ordo), ĉi tiu eblas realigita de sola programador (inkluzive ŝatanto) facile. Estas tuj kiam ili kutime dividas en tri kategorioj laŭ lia grandeco (linioj de kodo) aŭ kosto: de Malgranda, Meza kaj Granda portas. Ekzistas pluraj metodikoj por estimi ĝin, unu el la plej popularaj estas la sistemo COCOMO kiu havigas metodojn kaj programaron (programo) kiu kalkulas kaj ĝi havigas korinklinon de ĉiuj kostoj de produktado en projekto programaro" (rilato horoj/viro, mona kosto, kvanto de linioj fonto konsentite al uzita lingvo, ktp.).

Konsiderante la de granda portas, estas necese realigi tantas kaj tiel kompleksaj taskoj, tiel teknikaj, de gerenciamiento, forta demarŝo kaj diversaj analizo (inter aliaj) kiu ĉiu la inĝenierio faras mankon por lia studo kaj realigo: estas la Inĝenierio de Programaro.

Dum en la de meza portas, malgrandaj teamoj de laboro (inkluzive avezado analizisto-programador solitario) povas realigi la taskon. Kvankam, ĉiam en kazoj de meza kaj granda portas (kaj kelkfoje ankaŭ en iuj de malgranda portas, laŭ lia complejidad), ili devas sekvi iujn etapojn kiuj estas necesaj por la konstruo de la programaro. Tiaj etapoj, se bone devas ekzisti, estas malrigidaj en lia formo de apliko, konsentite al la metodiko aŭ Procezo de Disvolviĝo elektita kaj uzita de la teamo de disvolviĝo aŭ por la analizisto-programador solitario (se estus la kazo).

La "procezoj de disvolviĝo de programaro" posedas regulojn preestablecidas, kaj devas esti aplikitaj en la kreo de la programaro de meza kaj granda portas, pro tio ke en kontraŭa kazo lin pli sekura estas kiu la projekto aŭ ĝi ne sukcesas fini aŭ ĝi finas sen plenumi la objektivojn antaŭviditaj, kaj kun vario de neakcepteblaj misfunkciadoj (malsukcesas, en malmultaj vortoj). Inter tiaj "procezoj" ilin estas lertaj aŭ malpezaj (ekzemplo XP), pezaj kaj malrapidaj (ekzemplo RUP) kaj interaj variantoj; kaj ili kutime aplikas konsentite al la tipo, portu kaj tipología de la programaro al disvolvi, al kriterio de la ĉefo (se lin estas) de la teamo de disvolviĝo. Iuj de tiuj procezoj estas Extreme Programming (XP), Rational Unified Process (RUP), Feature Driven Development (FDD), ktp.

Ĉiu estu la "uzita" kaj aplikita procezo al la disvolviĝo de la programaro (RUP, FDD, ktp), kaj preskaŭ sendepende de li, ĝi ĉiam devas apliki Modelon de Ciklo de Vivo".[7]

ĝi estimas ke, de la tuta de projektoj grandaj programaro entreprenitaj, ĉirkaŭ 28% malsukcesas, ĉirkaŭ 46% falas en severajn modifojn kiu lin prokrastas kaj ĉirkaŭ 26% estas plene prosperaj. [8]

Kiam projekto malsukcesas, malofta fojo estas pro teknikaj faŭltoj, la ĉefa kaŭzas de misfunkciadoj kaj fiaskoj estas la manko de apliko de bona metodiko aŭ procezo de disvolviĝo. Inter aliaj, forta tendenco, de antaŭ malmultaj jardekoj, ĝi estas plibonigi la metodikojn aŭ procezoj de disvolviĝo, aŭ krei novaj kaj concientizar al la profesiaj en lia taŭga uzo. Kutime la specialistoj en la studo kaj disvolviĝo de ĉi tiuj areoj (metodikoj) kaj vi agordas (tiaj kiel modeloj kaj ĝis la sama demarŝo de la projektoj) estas la Inĝenieroj en Programaro, estas lia orientiĝo. La specialistoj en ajna alia areo de komputika disvolviĝo (analizisto, programador, Lic. En Komputika, Inĝeniero en Komputika, Inĝeniero de Sistemoj, ktp.) Kutime aplikas liajn konojn specialigitaj sed uzante modeloj, paradigmas kaj procezoj jam ellaboritaj.

Estas komuna por la disvolviĝo de programaro de meza portu ke la homaj teamoj implikitaj aplikas liajn proprajn metodikojn, kutime híbrido de la antaŭaj procezoj kaj kelkfoje kun propraj kriterioj.

La procezo de disvolviĝo povas impliki multnombraj kaj diversaj taskoj[7] , de lin administrativo, pasante por lin teknika kaj ĝis la demarŝo kaj la gerenciamiento. Sed preskaŭ strikte ĉiam plenumas iujn minimumajn etapojn; kiuj povas resumi kiel ĝi sekvas:

En la antaŭaj etapoj povas varii iomete liaj nomoj, aŭ esti pli sumaj, aŭ kontraŭe, esti pli rafinitaj; ekzemple indiki kiel sola fazo (al la finoj dokumenta filmoj kaj interpretativos) de "Analizo kaj Dezajno"; aŭ indiki kiel "Implementación" kio estas koncerna kiel "Kodigo"; sed en rigoreco, ĉiuj ekzistas kaj ili inkludas, esence, la samaj specifaj taskoj.

En la alineo 4 de la ĉeestanta artikolo tostas plej grandajn detalojn de ĉiu de la printitaj etapoj.

Modeloj de procezo aŭ ciklo de vivo

Por ĉiu de la fazoj aŭ printitaj etapoj en la ítem antaŭa, ekzistas sub-etapoj (aŭ taskoj). La modelo de procezo aŭ modelo de ciklo de vivo uzita por la disvolviĝo difinas la ordon por la taskoj aŭ aktivecoj implikitaj[7] ankaŭ difinas la kunordigon inter ili, ligo kaj realimentación inter la menciitaj etapoj. Inter la plej konitaj povas mencii: modelo en akvofalo aŭ secuencial, modelo espiral, modelo iterativo incremental. De la antedichos estas siavice iuj variantoj aŭ alternativaj, pli aŭ malpli allogaj laŭ estas la apliko postulita kaj liaj kondiĉoj.[8]

Modelo akvofalo

Oriento, kvankam estas pli komune konita kiel modelo en akvofalo estas ankaŭ nomita "klasika modelo", "tradicia modelo" aŭ "modelo lineal secuencial".

La modelo en pura akvofalo malfacile uzas tia kiu, ĉar ĉi tio implicus antaŭa kaj absoluta kono de la kondiĉoj, la ne volatilidad de la samaj (aŭ rigideco) kaj etapoj subsiguientes liberaj de eraroj; tio nur eblus aplicable al malabundaj kaj malgrandaj disvolviĝoj de sistemoj. En ĉi tiuj cirkonstancoj, la paŝo de etapo al alia de la menciitaj estus sen reveno, ekzemple pasi de la Dezajno al la Kodigo implicus ĝustan dezajnon kaj sen eraroj nek probabla modifo aŭ evoluado: "kodu lin desegnita ke ne estos tute ne variantoj nek eraroj". Ĉi tio estas utópico; pro tio ke intrínsecamente la programaro estas de karaktero evolutivo, cambiante kaj malfacile libera de eraroj, tiel dum lia disvolviĝo kiel dum lia vivo operativa.[7]

Fig. 2 - Modelo pura akvofalo aŭ secuencial por la ciklo de vivo de la programaro.

Iu ŝanĝo dum la ekzekuto de ĉiu de la etapoj en ĉi tiu modelo secuencial implicus rekomenci de la komenco la tuta kompleta ciklo, kiu redundaría en altaj kostoj de tempo kaj disvolviĝo. La figuro 2 specimeno ebla skemo de la modelo en demando.[7]

Tamen, la modelo akvofalo en iuj de liaj variantoj estas unu el la nuntempe pli uzitaj[10] , por lia efikeco kaj simpleco, pli ol nenio en programaro de malgranda kaj iuj de meza portas; sed neniam (aŭ tre malofta fojo) uzas lin al li en lia pura formo, kiel ĝi diris antaŭe. En loko de tio, ĝi ĉiam produktas iu realimentación inter etapoj, kiu ne estas tute predecible nek rigida; ĉi tio donas ŝancon al la disvolviĝo de produktoj programaro en kiuj estas iuj incertezas, ŝanĝoj aŭ evoluadoj dum la ciklo de vivo. Tiel ekzemple, fojo kaptitaj (elicitados) kaj specifitaj la kondiĉoj (unua etapo) povas pasi al la dezajno de la sistemo, sed dum ĉi tiu lasta fazo lin pli probabla estas kiu devas realigi ĝustigas en la kondiĉoj (kvankam estas minimumaj), jam estas por faŭltoj detektitaj, ambigüedades aŭ bone por kiu la propraj kondiĉoj ŝanĝis aŭ evoluita; kun kiu devas redoni al la unua aŭ antaŭa etapo, fari la adekvataj reajustes kaj poste daŭrigi denove kun la dezajno; ĉi tio lasta konas kiel realimentación. Lin normala en la modelo akvofalo estos tiam la apliko de la sama kun liaj etapoj realimentadas de iu formo, permesante posteniri de al la antaŭa (kaj inkluzive povi salti al pluraj antaŭaj) se estas postulita.

De ĉi tiu maniero akiras modelon akvofalo realimentado", kiu eblu esquematizado kiel ĝi ilustras al li la figuron 3.

Arkivo:ModeloCascadaRealimentado.Jpg
Fig. 3 - Modelo akvofalo realimentado por la ciklo de vivo.

Lin koncerna estas, al grandaj trajtoj, la formo kaj uzo de ĉi tiu modelo, unu el la plej uzitaj kaj popularaj.[7] La modelo Akvofalo Realimentado rezultas tre alloga, ĝis idealo, se la projekto prezentas alta rigidéz (malmultaj aŭ neniu ŝanĝo, ne evolutivo), la kondiĉoj estas tre klaraj kaj estas ĝuste specifitaj.[10]

Estas pli similaj variantoj al la modelo: mi rafinas de etapoj (pli etapoj, plej malgrandaj kaj pli specifaj) aŭ inkluzive montri malpli etapoj de la indikitaj, kvankam en tia kazo la faltante estos ene de iu alia. La ordo de tiuj fazoj indikitaj en la ítem antaŭa estas la logika kaj taŭga, sed avertu , kiel ĝi diris, kiu kutime estos realimentación al malantaŭen.

La modelo lineal aŭ en Akvofalo estas la paradigma pli malnova kaj vaste uzita, tamen la kritikoj lin (vidi malavantaĝojn) metis en dubon lia efikeco. Malgraŭ ĉiu havas tre gravan lokon en la Inĝenierio de programaro kaj daŭre estas la plej uzita; kaj ĉiam estas pli bona kiu enfokusigu al la hazardo.[10]

Malavantaĝoj de la modelo akvofalo:[7]

Modeloj evolutivos

La programaro evoluas kun la tempo. La kondiĉoj de la uzanto kaj de la produkto kutimas ŝanĝi laŭigu disvolvas la sama. La datoj de merkato kaj la konkurado faras ke ne eblu atendi al meti en la merkato absolute kompleta produkto, tial ĝi devas enkonduki limigitan funkcian version de iu formo por malpezigi la konkurajn premojn.

En tiuj aŭ aliaj similaj situacioj la desarrolladores bezonas modelojn de progreso kiu estas desegnitaj por akomodi al evoluado temporal aŭ progresiva, kie la centraj kondiĉoj estas konitaj de antemano, kvankam ne estas bone difinitaj al nivelo detalo.

En la modelo Akvofalo kaj Akvofalo Realimentado ne konsideras la naturon evolutiva de la programaro, ĝi proponas kiel statika kun kondiĉoj bone konitaj kaj difinitaj de la komenco.[7]

La evolutivos estas modeloj iterativos, ili permesas disvolvi versiojn ĉiufoje pli kompletaj kaj kompleksaj, ĝis alveni al la objektiva fino dezirita; inkluzive evolui pli tie, dum la fazo de operacio.

La modeloj “Iterativo Incremental” kaj “Espiral” (inter aliaj) estas du de la plej konitaj kaj uzitaj de la tipo evolutivo.[10]

Modelo iterativo incremental

En ĝeneralaj terminoj, ni povas distingi, en la figuro 4, la ĝeneralaj paŝoj kiujn sekvas la procezo de disvolviĝo de produkto programaro. En la modelo de ciklo de vivo selektita, ili identigas klare koncernaj paŝoj. La Priskribo de la Sistemo estas esenca por specifi kaj fari la malsamajn pliigojn ĝis alveni al la suma Produkto kaj fino. La aktivecoj concurrentes (Especificación, Disvolviĝo kaj Validación) sintezas la detalan disvolviĝon de la pliigoj, kiu faros poste.

Arkivo:Modelo Gral Evolutivo Incremental.Jpg
Fig. 4 - Diagramo genérico de la disvolviĝo evolutivo incremental.

La diagramo 4 nin montras en formo tre esquemática, la funkciado de ciklo iterativo incremental, kiu permesas la transdonon de versioj parciales al mezuro kiu iras konstruante la produkto fino.[7] Tio estas, al mezuro kiu ĉiu pliigo difinita alvenas al lian etapon de operacio kaj bontenado. Ĉiu versio elsendita korpigas al la antaŭaj pliigoj la funcionalidades kaj kondiĉoj kiuj estis analizitaj kiel necesaj.

La incremental estas modelo de tipo evolutivo kiu estas bazita en pluraj cikloj Akvofalo realimentados aplikitaj ree, kun filozofio iterativa.[10] En la figuro 5 montras rafinas de la antaŭa diagramo, sub skemo temporal, por akiri fine la skemo de la Modelo de ciklo de vivo Iterativo Incremental, kun liaj aktivecoj genéricas asociitaj. Ĝi tie observas klare ĉiu ciklo akvofalo kiu estas aplikita por la obtención de pliigo; ĉi tiuj lastaj iras integrante por akiri la produkton kompleta fino. Ĉiu pliigo estas ciklo Akvofalo Realimentado, kvankam, por simpleco, en la figuro 5 montras kiel secuencial pura.

Arkivo:Modelo Iterativo Incremental.Jpg
Fig. 5 - Modelo iterativo incremental por la ciklo de vivo de la programaro,.

ĝi observas ke ekzistas aktivecoj de disvolviĝo (por ĉiu pliigo) kiu estas realigitaj en paralela aŭ concurrentemente, tiel ekzemple, en la figuro, dum ĝi realigas la dezajnon detalo de la unua pliigo jam realigas en analizo de la dua. La figuro 5 estas nur esquemática, pliigo ne nepre komencos dum la fazo de dezajno de la antaŭa, ĝi eblas posta (inkluzive antaŭe), en ajna tempo de la antaŭa etapo. Ĉiu pliigo finas kun la aktiveco de “Operacio kaj Bontenado” (indikita "Operacio" en la figuro), kiu estas kie produktas la transdonon de la produkto parcial al la kliento. La momento de komenco de ĉiu pliigo estas dependa de pluraj faktoroj: tipo de sistemo; sendependeco aŭ dependeco inter pliigoj (du de ili plene sendependaj eblas facile komencitaj al la sama tempo se ĝi disponas de sufiĉa dungitaro); kapablo kaj kvanto de profesiaj implikitaj en la disvolviĝo; ktp.

Sub ĉi tiu modelo transdonas programaron “por funkciaj partoj pli malgrandaj”, sed reutilizables, nomitaj pliigoj. Ĝenerale ĉiu pliigo konstruas sur tiu kiu jam estis transdonita.[7]

Kiel ĝi montras en la figuro 5, ili aplikas sekvencojn Akvofalo en gradigita formo, dum ĝi progresas la tempon kalendaro. Ĉiu sekvenco lineal aŭ Akvofalo produktas pliigon kaj ofte la unua pliigo estas baza sistemo, kun multaj suplementaj funkcioj (konitaj aŭ ne) sen transdoni.

La kliento uzas komence tiu baza sistemo intertanto, la rezulto de lia uzo kaj evaluación povas alporti al la plano por la disvolviĝo de la/la sekvaj pliigoj (aŭ versioj). Krome ankaŭ alportas al tiu plano aliaj faktoroj, kiel lin estas la priorización (plej granda aŭ plej malgranda urĝaĵo en la neceso de ĉiu pliigo) kaj la dependeco inter pliigoj (aŭ sendependeco).

Poste de ĉiu integriĝo transdonas produkton kun plej granda funcionalidad kiu la antaŭa. La procezo ripetas ĝis atingi la programaron kompleta fino.

Estante iterativo, kun la modelo incremental transdonas produkton parcial sed tute operacional en ĉiu pliigo, kaj ne parto kiu estu uzita por reajustar la asignoj (kvazaŭ ĝi okazas en la modelo de konstruo de prototipoj).[10]

La enfokusigu incremental rezultas tre utila kun malalta dotación de dungitaro por la disvolviĝo; ankaŭ se ne estas disponebla datas limon de la projekto por kion transdonas nekompletaj versioj sed kiu havigas al la uzanto funcionalidad baza (kaj ĉiufoje plej granda). Ankaŭ estas utila modelo al la finoj de evaluación.

Noto: ĝi Eblas konsiderita kaj utila, en ajna momento aŭ pliigo korpigi temporalmente la paradigma MCP kiel komplemento, havante tiel mixtura de modeloj kiuj plibonigas la skemon kaj ĝenerala disvolviĝo.

Ekzemplo:

Procesoro de teksto kiu estas disvolvita sub la paradigma Incremental povus alporti, en komenco, bazaj funkcioj de eldono de arkivoj kaj produktado de dokumentoj (iu kiel simpla eldonisto). En dua pliigo oni povus aldoni al li eldonon pli kompleksa, kaj de generacio kaj miksaĵo de dokumentoj. En tria pliigo povus konsideri la aldonita de funkcioj de korekto ortográfica, skemoj de paginado kaj ŝablonoj; en kvaraj kapabloj de propraj desegno kaj matematikaj ekvacioj. Tiel sinsekve ĝis alveni al la procesoro fino postulita. Tiel, la produkto iras kreskante, alproksimigante al lia metu finon, sed de la transdono de la unua pliigo jam estas utila kaj funkcia por la kliento, kiu observas rapidan respondon koncerne al frua transdono; sen rimarki ke datas al ŝi limon de la projekto povas ne esti acotada nek tiel difinita, kion donas rando de operacio kaj ĝi malpezigas premojn al la teamo de disvolviĝo.

Kiel ĝi diris, la Iterativo Incremental estas modelo de la tipo evolutivo, tio estas ili kie permesas kaj ili atendas probablajn ŝanĝojn en la kondiĉoj en tempo de disvolviĝo; ĝi akceptas iun randon por ke la programaro povu evolui. Aplicable kiam la kondiĉoj estas modere bone konitaj sed ne estas tute statikaj kaj difinitaj, demando tiu kiu se estas nemalhavebla por povi uzi modelon Akvofalo.

La modelo estas aconsejable por la disvolviĝo de programaro en kiu observas, en lia komenca etapo de analizo, kiu posedas areojn sufiĉe bone difinitaj al kovri, kun sufiĉa sendependeco kiel por esti disvolvitaj en pluaj etapoj. Tiaj areoj al kovri kutimas havi malsamajn gradojn de urĝas por kiu la samaj devas priorizar en antaŭa analizo, tio estas, difini kiu estos la unua, la dua, kaj tiel sinsekve; ĉi tio konas kiel “difino de la pliigoj” kun bazo en priorización. Ili povas ne ekzisti funkciaj prioritatoj fare de la kliento, sed la desarrollador devas fiksi ilin de ĉiuj modoj kaj kun iu kriterio, pro tio ke bazante en ili disvolvos kaj ili transdonos la malsamajn pliigojn.

La fakto kiun ekzistas funkciaj pliigoj de la programaro portas tuj al pensi en skemo de disvolviĝo modular, sekve ĉi tiu modelo havigas tia paradigma de dezajno.

En resumo, modelo incremental portas al pensi en disvolviĝo modular, kun transdonoj parciales de la produkto programaro nomitaj “pliigoj” de la sistemo, kiu estas elektitaj laŭ prioritatoj predefinidas de iu modo. La modelo permesas implementación kun pluaj rafinitecoj (pligrandigo aŭ pliboniĝo). Kun ĉiu pliigo aldonas nova funcionalidad aŭ ili kovras novajn kondiĉojn aŭ ĝi bone plibonigas la version antaŭe implementada de la produkto programaro.

Ĉi tiu modelo tostas iu flexibilidad por ke dum la disvolviĝo inkludas ŝanĝojn en la kondiĉoj fare de la uzanto, ŝanĝo de kondiĉoj proponita kaj aprobita povas analizi kaj implementarse kiel nova pliigo aŭ, eventuale, ĝi povos konstitui pliboniĝon/adecuación de oni jam planita. Kvankam se ĝi produktas ŝanĝon de kondiĉoj fare de la kliento kiu tuŝu antaŭajn pliigojn jam finitaj (detección/malfrua aliĝo) devas taksi la factibilidad kaj realigi interkonsenton kun la kliento, pro tio ke ĝi povas impactar forte en la kostoj.

La selektado de ĉi tiu modelo permesas realigi fruajn funkciajn transdonojn al la kliento (kiu estas beneficioso tiel por li kiel por la grupo de disvolviĝo). priorizan la transdonoj de tiuj moduloj aŭ pliigoj kiujn ŝprucas la neceso operativa de fari ĝin, ekzemple por antaŭaj ŝarĝoj de informo, nemalhavebla por la sekvaj pliigoj.[10]

La modelo iterativo incremental ne devigas al specifi kun precizeco kaj detalo absolute ĉiu kion la sistemo devas fari, (kaj kiel), antaŭ esti konstruita (kiel la kazo de la akvofalo, kun kondiĉoj frostigitaj). Ĝi nur faras en la evoluanta pliigo. Ĉi tio revenas pli regebla la procezo kaj ĝi reduktas la trafon en la kostoj. Ĉi tio estas tiel, ĉar en kazo de ŝanĝi aŭ refari la kondiĉojn, ĝi nur tuŝas parton de la sistemo. Kvankam, logike, ĉi tiu situacio pligravigas se ĝi prezentas en stato antaŭita, tio estas en la lastaj pliigoj. En definitiva, la modelo havigas la aliĝon de novaj kondiĉoj dum la disvolviĝo.

Kun paradigma incremental reduktas la tempon de komenca disvolviĝo, pro tio ke implementa funcionalidad parcial. Ĝi ankaŭ havigas trafon ventajoso fronte al la kliento, kiu estas la frua transdono de partoj operativas de la programaro.

La modelo havigas ĉiujn avantaĝojn de la modelo en akvofalo realimentado, reduktante liaj malavantaĝoj nur al la medio de ĉiu pliigo.

La modelo incremental ne estas rekomendinda por kazoj de sistemoj de reala tempo, de alta nivelo de sekureco, de procesorado distribuita, aŭ de alta indico de riskoj.

Modelo espiral

La modelo espiral estis proponita komence de Barry Boehm. Estas modelo evolutivo kiu konjugacias la naturon iterativa de la modelo MCP kun la kontrolitaj kaj sistemaj aspektoj de la Modelo Akvofalo. Ĝi havigas potencial por rapida disvolviĝo de versioj incrementales. En la modelo Espiral la programaro konstruas en serio de versioj incrementales. En la unuaj iteraciones la versio incremental eblus modelon en papero aŭ bone prototipo. En la lastaj iteraciones produktas versiojn ĉiufoje pli kompletaj de la sistemo desegnita.[7] [10]

La modelo dividas en numero de Aktivecoj de kadro de laboro, nomitaj "regionoj de taskoj". Ĝenerale ekzistas inter tri kaj ses regionoj de taskoj (estas variantoj de la modelo). En la figuro 6 montras la skemon de Modelo Espiral kun 6 regionoj. En ĉi tiu kazo klarigas varianton de la originala modelo de Boehm, elmontrita en lia klopodita 1988; en 1998 elmontris pli freŝan traktaton.

Arkivo:Modelo Espiral Boehm.Jpg
Fig. 6 - Modelo espiral por la ciklo de vivo de la programaro.

La regionoj difinitaj en la modelo de la figuro estas:

La aktivecoj formulitaj por la kadro de laboro estas ĝeneralaj kaj ili aplikas al ajna projekto, granda, meza aŭ malgranda, kompleksa aŭ ne. La regionoj kiuj difinas tiujn aktivecojn komprenas aron de taskoj" de la laboro: tiu aro jes devas adapti al la karakterizaĵoj de la projekto en aparta al entrepreni. Rimarku kiu lin printita en la ítems de 1 al 6 estas aroj de taskoj, iuj de la ili kutime dependas de la projekto aŭ disvolviĝo en se.

Malgrandaj projektoj postulas malaltan kvanton de taskoj kaj ankaŭ de formalidad. En plej grandaj projektoj aŭ kritikistoj ĉiu regiono de taskoj enhavas laborojn de pli alta nivelo de formalidad. En ajna kazo aplikas aktivecojn de protekto (ekzemple, demarŝo de agordo de la programaro, garantio de kvalito, ktp.).

Al la komenco de la ciklo, aŭ procezo evolutivo, la teamo de inĝenierio ĝiras ĉirkaŭ la espiral (metafóricamente parolante) komencante por la centro (markita kun ๑ en la figuro 6) kaj en la senso indikita; la unua cirkvito de la espiral povas produkti la disvolviĝon de especificación de la produkto; la sekvaj paŝoj povus generi prototipon kaj iom post iom versioj pli kompleksaj de la programaro.

Ĉiu paŝo por la regiono de planizado provokas ĝustigas en la plano de la projekto; la kosto kaj planizado realimentan en funkcio de la evaluación de la kliento. La peranto de projektoj devas ĝustigi la numeron de iteraciones postulitaj por kompletigi la disvolviĝon.

La modelo espiral povas iri adaptante kaj apliki laŭlonge de la tuta Ciklo de vivo de la programaro (en la klasika modelo, aŭ akvofalo, la procezo finas al la transdono de la programaro).

Alternativa vidado de la modelo povas observi ekzamenante la "akso de punkto de eniro de projektoj". Ĉiu de la circulitos (๏) fiksitaj laŭlonge de la akso reprezentas punktojn de ekkuro de la malsamaj projektoj (rilatigitaj); al scii:

Kiam la espiral karakterizas de ĉi tiu formo, estas operativa ĝis la programaro retiriĝas, eventuale povas esti senaga (la procezo), sed kiam produktas ŝanĝon la procezo eltiras denove en la punkto de eniro proprigita (ekzemple, en "Pliboniĝo de la Produkto").

La modelo espiral donas enfokusigas realisma, kiu evoluas egala kiu la programaro; ĝi adaptas tre bone por grandskala disvolviĝoj.

La Espiral uzas la MCP por redukti riskojn kaj ĝi permesas apliki ĝin en ajna etapo de la evoluado. Ĝi subtenas la enfokusigas klasika (akvofalo) sed korpigas kadron de laboro iterativo kiu reflektas pli bona la realaĵo.

Ĉi tiu modelo postulas konsideri teknikajn riskojn en ĉiuj etapoj de la projekto; aplikita adekvate devas redukti ilin antaŭ ol estas vera problemo.

La Modelo evolutivo kiel la Espiral estas aparte kapabla por la disvolviĝo de Mastrumaj sistemoj (kompleksaj); ankaŭ en sistemoj de altaj riskoj aŭ kritikistoj (Ej. Navegadores kaj controladores aeronáuticos) kaj en ĉiuj tiuj ke estu necesa forta demarŝo de la projekto kaj liaj riskoj, teknikistoj aŭ de demarŝo.

Gravaj malavantaĝoj:

Ĉi tiu modelo ne uzis tiel, kiel la Akvofalo (Incremental) aŭ MCP, tial ĝi ne havas bone mezurita lia efikeco, estas paradigma relative nova kaj malfacila de implementar kaj kontroli.

Modelo espiral Win & Win

Interesa varianto de la Modelo Espiral antaŭe vidita (Fig. 6) Estas la "Modelo espiral Win-Win"[8] (Barry Boehm). La Modelo Espiral antaŭa (klasika) sugestas la konekton kun la kliento por fiksi la kondiĉojn, kiu simple demandas al la kliento kion ĝi bezonas kaj li havigas la informon por daŭrigi; sed ĉi tio estas en ideala kunteksto kiun malofta fojo okazas. Kutime kliento kaj desarrollador eniras en intertraktadon, ĝi negocas koston fronte al funcionalidad, rendimento, kvalito, ktp.

"Estas tuj kiam la obtención de kondiĉoj postulas intertraktadon, kiu sukcesas kiam ambaŭ partoj gajnas".

La pli bonaj intertraktadoj pelas en akiri "Venkon & Venko" (Win & Win), tio estas kiu la kliento gajnu akirante la produkto kiu lin kontentigas, kaj la desarrollador ankaŭ gajnas atingante buĝeto kaj dato de realisma transdono. Evidente, ĉi tiu modelo postulas fortajn kapablecojn de intertraktado.

La modelo Win-Win difinas aron de aktivecoj de intertraktado al la komenco de ĉiu paŝo ĉirkaŭ la espiral; ili difinas la sekvajn aktivecojn:

  1. Identigo de la sistemo aŭ subsistemas ŝlosila de la directivos(*) (scii kion volas).
  2. Determino de "kondiĉoj de venko" de la directivos (scii kion bezonas kaj ĝi kontentigas ilin)
  3. Intertraktado de kondiĉas al ili "venkon" de la directivos por akiri kondiĉas "Venkon & Venko" (negoci por ke ambaŭ gajnas).

(*) Directivo: Kliento elektita kun rekta intereso en la produkto, kiu eblas premiita de la organizo se ĝi sukcesas aŭ kritikita se ne.

La modelo Win & Win faras emfazon en la komenca intertraktado, ĝi ankaŭ enkondukas 3 limŝtonoj en la nomita procezo "punktoj de fijación", kiu helpas al establi la completitud de ciklo de la espiral, kaj ili havigas limŝtonojn de decido antaŭ daŭrigi la projekton de disvolviĝo de la programaro.

Etapoj en la disvolviĝo de la programaro

Preno, analizo kaj especificación de kondiĉoj

Al la komenco de disvolviĝo (ne de projekto), ĉi tiu estas la unua fazo kiu realigas, kaj, laŭ la modelo de procezo adoptita, ĝi povas preskaŭ fini por pasi al la proksima etapo (kazo de Modelo Akvofalo Realimentado) aŭ ĝi povas fari parte por poste repreni ŝin (geedziĝas Modelon Iterativo Incremental aŭ aliaj de karaktero evolutivo).

En simplaj vortoj kaj esence, dum ĉi tiu fazo, ili akiras, ili kunvenas kaj ili specifas la funkciajn karakterizaĵojn kaj ne funkciaj ol devos plenumi la futuran programon aŭ sistemon al disvolvi.

La bonecoj de la karakterizaĵoj, tiel de la sistemo aŭ programo al disvolvi, kiel de lia medio, parametroj ne funkciaj kaj arkitekturo dependas ege de lin bone sukcesita ol estas ĉi tiu etapo. Ĉi tiu estas, probable, la de plej granda graveco kaj unu el la plej malfacilaj fazoj de sukcesi certe, ĉar ne estas automatizable, ne estas tre teknika kaj ĝi dependas en granda mezuro de la kapableco kaj sperto de la analizisto kiu ŝin realigas.

Ĝi implikas forte al la uzanto aŭ kliento de la sistemo, sekve ĝi havas nuancojn tre subjektivaj kaj estas malfacila de modelar kun certeco aŭ apliki teknika kiu estas "la plej proksima al la taŭga" (fakte ne ekzistas "la strikte taŭga"). Se ili bone konceptis plurajn metodikojn, inkluzive programaro de apogo, por preno, elicitación kaj registro de kondiĉoj, ne ekzistas formo infalible aŭ absolute confiable, kaj ili devas apliki kune bonaj kriterioj kaj tre komuna senso fare de la aŭ la analizistoj komisiitaj de la tasko; estas fundamenta ankaŭ sukcesi fluida kaj taŭga konekto kaj kompreno kun la uzanto fino aŭ kliento de la sistemo.

La plej grava artefakto rezulto de la kulmino de ĉi tiu etapo estas kio konas kiel especificación de kondiĉoj programaro aŭ simple dokumento ERS.

Kiel ĝi diris, la kapableco de la analizisto por interagi kun la kliento estas fundamenta; lin komuna estas kiu la kliento havas ĝeneralan objektivon aŭ problemon al solvi, ĝi ne konas tute ne la areo (komputika), nek lia ĵargono, ĝi eĉ ne scias kun precizeco kion devus fari la produkto programaro (kio kaj cuantas funkcioj) nek, multe malpli, ĝi kiel devas operacii. En aliaj malpli oftaj kazoj, la kliento "pensas ke" ĝi scias ĝuste kion la programaro devas fari, kaj ĝi ĝenerale trafas tre parte, sed lia empecinamiento entorpece la tasko de elicitación. La analizisto devas havi la kapablon por lidiar kun ĉi tiu tipo de problemoj, kiu inkludas homajn rilatojn; ĝi devas scii meti al la nivelo de la uzanto por permesi taŭgan konekton kaj komprenon.

Malabundaj estas la situacioj kiujn la kliento scias kun certeco kaj inkluzive kun completitud kio postulas de lia futura sistemo, oriento estas la plej simpla kazo por la analizisto.

La relativaj taskoj al preno, elicitación, modelado kaj registro de asignoj, krom esti ege grava, ĝi povas alveni al esti dificultosa de sukcesi acertadamente kaj porti sufiĉe relativa tempo al la tuta procezo de la disvolviĝo; al la procezo kaj metodikoj por efektivigi ĉi tiun aron de aktivecoj kutime supozas ilin al li propra parto de la Inĝenierio de Programaro, sed donita la antedicha complejidad, ĝi nuntempe parolas pri Inĝenierion en Kondiĉoj[11] , kvankam ŝi ankoraŭ ne ekzistas formale.

Estas grupoj de studo kaj esploro, en ĉiuj, kiu estas ekskluzive verŝitaj al la koncepti modelojn, teknikaj kaj procezoj por provi sukcesi la ĝentilan prenon, analizo kaj registro de asignoj. Ĉi tiuj grupoj estas kiuj kutime parolas pri la Inĝenierion en Kondiĉoj; tio estas ĝi proponas ĉi tiun kiel areo aŭ disciplino sed ne kiel kuro universitaria en se sama.

Iuj kondiĉoj ne bezonas la ĉeeston de la kliento, por esti kaptitaj aŭ analizitaj; en iuj kazoj al ili povas proponi la saman analiziston aŭ, inkluzive, adopti unuflanke decidoj kiujn ĝi konsideras taŭgaj (tiel en funkciaj asignoj kiel ne funkciaj). Por citi probablajn ekzemplojn: Iuj kondiĉoj sur la arkitekturo de la sistemo, kondiĉoj ne funkciaj tiaj kiel la relativaj al la rendimento, nivelo de apogo al eraroj operativos, platformoj de disvolviĝo, internaj rilatoj aŭ ligoj inter la informo (inter registroj aŭ tabuloj de datumoj) al stoki en kazo de bazoj aŭ datenbankoj de datumoj, ktp. Iuj funkciaj tiaj kiel malĉefaj ebloj aŭ de necesaj apogo por pli bona aŭ pli simpla operatividad; ktp.

La obtención de especificaciones de la kliento (aŭ aliaj aktoroj intervinientes) estas homa procezo tre interaga kaj iterativo; kutime al mezuro kiu kaptas la informon, ĝi analizas ŝin al li kaj realimenta kun la kliento, rafinante ŝin, polurante ŝin kaj korektante se estas necesa; ĉiu estu la metodo de ERS uzita. LA analizisto ĉiam devas alveni al koni la temática kaj la problemo al solvi, regi ĝin, ĝis iu punkto, ĝis la medio kiu la futura sistemo al disvolvi lin ĉirkaŭprenas. Por tio la analizisto devas havi altan kapablon por kompreni problemojn de tre diversaj areoj aŭ disciplinoj de laboro (kiu ne estas specife liaj); tiel ekzemple, se la sistemo al disvolvi estos por gestionar informo de asekuristino kaj liaj filioj remotas, la analizisto devas compenetrar en kiel ŝi laboras kaj ĝi manipulas lian informon, de niveloj tre malaltaj kaj inkluzive alvenante ĝis la gerenciales. Donita al granda diverseco de kampoj al kovri, la analizistoj kutimas esti ĉeestitaj de specialistoj, tio estas homo kiu konas profunde la areo por kiu disvolvos la programaron; evidente sola persono (la analizisto) ne povas ĉirkaŭpreni tiel vasta kvanto de areoj de la kono. En grandaj entreprenoj de disvolviĝo de produktoj programaro, estas komune havi analizistojn specialigitaj en iuj areoj de laboro.

Kontraŭe, ne estas problemo de la kliento, tio estas li ne havas kial scii nenion de programaro, nek de dezajnoj, nek aliaj aĵoj rilatigitaj; ĝi nur devas limigi al alporti objektivojn, datumoj kaj informo (de propra mano aŭ de liaj registroj, teamoj, oficistoj, ktp) al la analizisto, kaj gvidita de li, por ke, en unua petskribo, ĝi difinas la "Universon de Parolado", kaj kun posta laboro sukcesu fari la taŭgan dokumenton ERS.

Estas bone konita la premo kiun ili suferas la desarrolladores de komputikaj sistemoj por kompreni kaj elliberigi la necesojn de la klientoj/uzantoj. Kiom pli kompleksa estas la kunteksto de la plej malfacila problemo estas sukcesi ĝin, ĝi kelkfoje pelas al la desarrolladores al devi igi preskaŭ spertaj de la regadoj kiuj analizas.

Kiam ĉi tio ne okazas estas tre probabla ol generas aron de kondiĉoj[12] eraraj aŭ nekompletaj kaj sekve produkto de programaro kun alta grado de malaprobo fare de la klientoj/uzantoj kaj alta kosto de reingeniería kaj bontenado. Ĉiu tio kiu ne detektas, aŭ rezultu malbone komprenita en la komenca etapo provokos fortan negativan trafon en la kondiĉoj, propagante ĉi tiu fluo degradante laŭlonge de la tuta procezo de disvolviĝo kaj pliigante lia malutilo kiom pli malfrua estas lia detección (Bell kaj Thayer 1976)(Davis 1993).

Procezoj, modelado kaj formoj de elicitación de kondiĉoj

Estante kiu la preno, elicitación kaj especificación de kondiĉoj, estas parto crucial en la procezo de disvolviĝo de programaro, pro tio ke de ĉi tiu etapo dependas la atingon de la objektivaj finoj antaŭviditaj, ili konceptis modelojn kaj diversaj metodikoj de laboro por ĉi tiuj finoj. Ankaŭ ekzistas iloj programaro kiun apogas la relativaj taskoj realigitaj de la inĝeniero en kondiĉoj.

La normo IEEE 830-1998 tostas normalización de la "Praktikoj Rekomenditaj por la Especificación de Kondiĉoj Programaro".[13]

Al mezuro kiun akiras la kondiĉoj, ĝi kutime iras ilin al li analizante, la rezulto de ĉi tiu analizo, kun aŭ sen la kliento, plasmo en dokumento, konita kiel ERS aŭ Especificación de Kondiĉoj Programaro, kies strukturo povas veni difinita de pluraj normoj, tiaj kiel CMM-1a.

Unua paŝo por realigi la relevamiento de informo estas la kono kaj difino trafita kio konas kiel "Universo de Parolado" de la problemo, kiu difinas kaj ĝi komprenas por:

Universo de Parolado (UdeD): estas la ĝenerala kunteksto en kiu la programaro devos esti evoluinta kaj ĝi devos operacii. La UdeD inkludas ĉiujn fontojn de informo kaj ĉiuj personoj rilatigitaj kun la programaro. Tiuj personoj estas konitaj ankaŭ kiel aktoroj de tiu universo. La UdeD estas la realaĵo circunstanciada por la aro de objektivoj difinitaj de kiuj demandaron la programaro.

De la eltiro kaj analizo de informo en lia medio akiras ĉiuj especificaciones necesaj kaj tipoj de kondiĉoj por la futura produkto programaro.

La objektivo de la Inĝenierio de Kondiĉoj (IRI) estas sistematizar la procezo de difino de kondiĉoj permesante elicitar, modelar kaj analizi la problemon, generante devontigo inter la Inĝenieroj de Kondiĉoj kaj la klientoj/uzantoj, pro tio ke ambaŭ partoprenas en la generacio kaj difino de la kondiĉoj de la sistemo. La IRI alportas aron de metodoj, teknikaj kaj iloj kiuj ĉeestas al la inĝenieroj de kondiĉoj (analizistoj) por akiri asignojn lin pli sekuraj, veraces, kompletaj kaj oportunaj eblaj, permesante esence:

Se bone ekzistas diversaj formoj, modeloj kaj metodikoj por elicitar, difini kaj dokumenti asignojn, ĝi ne povas diri ke iu de ili estas pli bona aŭ plej malbona kiu la alia, ili kutimas havi muchísimo en komuna, kaj ĉiuj plenumas la saman objektivon. Tamen, kio se ĝi povas diri sen duboj estas kiu estas nemalhaveble uzi iu de ili por dokumenti la especificaciones de la futura produkto programaro. Tiel ekzemple, estas grupo de argentina esploro kiu de faras plurajn jarojn proponis kaj ĝi studas la uzon de la LEL (Léxico Etendita de la Lingvo) kaj Scenejoj kiel metodiko, tie[14] prezentas unu el la tantas referencoj kaj bibliografio sur tio. Alia formo, pli ortodoksa, de kapti kaj dokumenti kondiĉojn povas akiri en detalo, ekzemple, en la laboro de la Universitato de Sevilo sur "Metodiko por la Analizo de Kondiĉoj de Sistemoj Programaro".[15]


En la Fig. 7 montras skemon, pli aŭ malpli strikta, kvankam ne detala, de la paŝoj kaj taskoj al sekvi por realigi la prenon, analizo kaj especificación de asignoj programaro. Ankaŭ tie observas kion artefakto aŭ dokumento akiras en ĉiu etapo de la procezo. En la diagramo ne explicita metodiko aŭ modelo al uzi, simple pautan la taskoj kiuj devas plenumi , de iu maniero.

Fig. 7 - Diagramo de taskoj por preno kaj analizo de kondiĉoj.

ebla lerta, ĝenerala kaj ordinato, de taskoj rekomenditaj por akiri la difinon de kio devas realigi, la produktoj al akiri kaj la teknikoj al uzi dum la aktiveco de elicitación de kondiĉoj, en fazo de Especificación de Kondiĉoj Programaro estas:

  1. Akiri informon sur la regado de la problemo kaj la aktuala sistemo (UdeD).
  2. Prepari kaj realigi la kunvenojn por elicitación/intertraktado.
  3. Identigi/revizii la objektivojn de la uzanto.
  4. Identigi/revizii la objektivojn de la sistemo.
  5. Identigi/revizii la kondiĉojn de informo.
  6. Identigi/revizii la funkciajn kondiĉojn.
  7. Identigi/revizii la ne funkciajn kondiĉojn.
  8. Priorizar objektivaj kaj kondiĉoj.

Iuj bazaj komencoj al konsideri:

Klasifiko kaj identigo de asignoj

ili povas identigi du formojn de kondiĉoj:

Tio estas, ambaŭ estas lin sama, sed kun malsama nivelo de detalo.

Ekzemplo de kondiĉo de uzanto: La sistemo devas fari pruntojn Ekzemplo de kondiĉo de sistemo: Funkcio prunto: enirita kodo kompaniano, ekzempla kodo; eliro: ĝi datas redonon; ktp.

ili klasifikas en tri la tipoj de kondiĉoj de sistemo:

  • Funkciaj kondiĉoj

La funkciaj kondiĉoj priskribas:

  • La servoj kiujn havigas la sistemo (funkcioj).
  • La respondo de la sistemo antaŭ determinitaj eniroj.
  • La konduto de la sistemo en apartaj situacioj.
  • Kondiĉoj ne funkciaj

La ne funkciaj kondiĉoj estas limigoj de la servoj aŭ funkcioj kiujn proponas la sistemo (ej. Cotas de tempo, procezo de disvolviĝo, rendimento, ktp.)

Ekzemplo 1. La Centra biblioteko devas esti kapabla de atenti samtempe al ĉiuj bibliotekoj de la Universitato
Ekzemplo 2. La tempo de respondo al konsulto remota ne devas esti pli alta ol 1/2 s
Siavice, estas tri tipoj de kondiĉoj ne funkciaj:
  • Kondiĉoj de la produkto. Ili specifas la konduton de la produkto (Ej. Servoj, memoro, imposto de misfunkciadoj, ktp.)
  • Kondiĉoj organizativos. ili derivas de la politikoj kaj proceduroj de la organizoj de la klientoj kaj desarrolladores (Ej. Normoj de procezo, lingvoj de programado, ktp.)
  • Eksteraj kondiĉoj. ili derivas de eksteraj faktoroj al la sistemo kaj al la procezo de disvolviĝo (Ej. Leĝdonaj kondiĉoj, etikaj, ktp.)
  • Kondiĉoj de la regado.

La kondiĉoj de la regado derivas de la regado de la apliko kaj ili reflektas karakterizaĵojn de koncerna regado.

Ili eblas funkciaj aŭ ne funkciaj.

Ej. La sistemo de biblioteko de la Universitato devas esti kapabla de eksporti datumojn per la Lingvo de Intercomunicación de Bibliotekoj de Hispanio (LIBE). Ej. La sistemo de biblioteko ne povos konsenti bibliotekojn kun materialo cenzurita.

Dezajno de la sistemo

Kodigo de la programaro

Dum ĉi tiu la etapo realigas la taskojn kiuj komune konas kiel programado; kiu konsistas, esence, en porti al kodo fonto, en la lingvo de programado elektita, ĉiu lin desegnita en la antaŭa fazo. Ĉi tiu tasko ŝin realigas la programador, sekvante por kompleta la lineamientos postulitaj en la dezajno kaj en konsidero ĉiam al la funkciaj kondiĉoj kaj ne funkciaj (ERS) specifitaj en la unua etapo.

Estas komune pensi kiu la etapo de programado aŭ kodigo (iuj ŝin nomas implementación) estas kiu insume la plej granda parto de la laboro de disvolviĝo de la programaro; tamen, ĉi tio eblas relativa (kaj ĝenerale aplicable al sistemoj de malgranda portu) pro tio ke la antaŭaj etapoj estas cruciales, maltrankviligaj kaj ili povas porti sufiĉe pli tempo. ĝi kutimas fari korinklinojn de ĉirkaŭ 30% de la tuta tempo insumido en la programado, sed ĉi tiu cifero ne estas consistente pro tio ke ĝi dependas en granda mezuro de la karakterizaĵoj de la sistemo, lia criticidad kaj la lingvo de programado elektita.[8] Dum plej malgranda estas la nivelo de la plej granda lingvo estos la tempo de programado postulita, tiel ekzemple postrestus pli tempo en kodi algoritmon en lingvo ensamblador kiu la sama planita en lingvo C.

Dum ĝi planas la aplikon, sistemo, aŭ programaro ĝenerale, ili realigas ankaŭ taskoj de depuración, ĉi tio estas la laboro de iri liberigante al la kodo de la eraroj factibles de esti trovitaj en ĉi tiu fazo (de semántica, sintaksa kaj logika). Estas sorto de solapamiento kun la sekva fazo, pro tio ke por elpurigi la logikon estas necese realigi unuigajn provojn, kutime kun datumoj de provo; certe estas kiu ne ĉiuj eraroj estos trovitaj nur en la etapo de programado, estos aliaj kiu trovos dum la etapoj subsiguientes. La apero de iu funkcia eraro (malbona respondo al la asignoj) eventuale povas porti al redoni al la fazo de dezajno antaŭ daŭrigi la kodigon.

Dum la fazo de programado, la kodo povas adopti plurajn statojn, dependante de la formo de laboro kaj de la lingvo elektita, al scii:

  • Kodo fonto: estas la skribita rekte por la programadores en eldonistoj de teksto, kiu generas la programon. Ĝi enhavas la aron de instrukcioj koditaj en iu lingvo de alta nivelo. Povas esti distribuita en pakoj, proceduroj, bibliotekoj fonto, ktp.
  • Kodo kontestas: estas la binara aŭ intera kodo resultante de procesi kun compilador la kodo fonto. Ĝi konsistas en kompleta tradukado kaj de sola fojo de ĉi tiu lasta. La kodo kontestas ne estas komprenebla por la homo (kutime estas binara formato) sed ankaŭ ne estas rekte ejecutable por la komputilo. ĝi klopodas interan reprezenton inter la kodo fonto kaj la kodo ejecutable, al la finoj de ligo fino kun la rutinoj de biblioteko kaj inter proceduroj aŭ bone por lia uzo kun malgranda intera interpretisto [al modo de malsamaj ekzemploj vidu EUPHORIA, (intera interpretisto), FORTRAN (compilador pura) MSIL (Microsoft Intermediate Language) (interpretisto) kaj BASIC (pura interpretisto, intera interpretisto, compilador intera aŭ compilador pura, ĝi dependas de la versio uzita)].
    • La kodo kontestas ne ekzistas se la programador laboras kun lingvo al modo de pura interpretisto, en ĉi tiu kazo la sama interpretisto komisias de traduki kaj ekzekuti linion por linio la kodo fonto (konsentite al la fluo de la programo), en tempo de ekzekuto. En ĉi tiu kazo ankaŭ ne ekzistas la aŭ la arkivoj de kodo ejecutable. Malavantaĝo de ĉi tiu kategorio estas kiu la ekzekuto de la programo aŭ sistemo estas iom pli malrapida ol se ĝi faris kun intera interpretisto, kaj sufiĉe pli malrapida ol se ekzistas la aŭ la arkivoj de kodo ejecutable. Tio estas ĝi ne favoras la rendimenton en rapido de ekzekuto. Sed granda avantaĝo de la kategorio pura interpretisto, estas kiu la ĉi tiu formo de laboro havigas ege la tasko de depuración de la kodo fonto (fronte al la alternativo de fari ĝin kun compilador pura). Ĝi ofte kutimas uzi miksitan formon de laboro (se la lingvo de programado elektita lin permesas), tio estas komence labori al modo de pura interpretisto, kaj fojo elpurigita la kodo fonto (liberigita de eraroj) uzas compilador de la sama lingvo por akiri la kodon ejecutable kompleta, kun kiu agiliza la depuración kaj la rapido de ekzekuto optimiza.
  • Kodo ejecutable: Estas la binara kodo rezulto de kunligi oni aŭ pli fragmentoj de kodo kontestas kun la rutinoj kaj necesaj bibliotekoj. Ĝi konstituas oni aŭ pli binaraj arkivoj kun formato tia kiu la mastruma sistemo estas kapabla de ŝarĝi ĝin en la memoro RAM (eventuale ankaŭ dividas en virtuala memoro), kaj konduto al lia rekta ekzekuto. Por lin antaŭa diras ke la kodo ejecutable estas rekte "komprenebla por la komputilo". La kodo ejecutable, ankaŭ konita kiel kodo maŝino, ne ekzistas se programo kun kategorio de "pura interpretisto".

Provoj (unuigaj kaj de integriĝo)

Inter la diversaj provoj kiujn oni efektivigas lin al la programaro povas distingi ĉefe:

  • Unuigaj provo: ili Konsistas en provi aŭ testear pecoj de malgrandaj programaro; al nivelo de sekcioj, proceduroj, funkcioj kaj moduloj; tiuj kiu havu funcionalidades specifaj. Koncernaj provoj uzas por certigi la ĝentilan funkciadon de sekcioj de kodo, multe pli reduktitaj ol la aro, kaj kiu havas konkretajn funkciojn kun iu grado de sendependeco.
  • Provoj de integriĝo: ili realigas fojon kiu la unuigaj provoj estis finitaj prospere; kun ĉi tiuj provas certigi ke la kompleta sistemo, inkluzive la subsistemas kiu formas la grandajn individuajn pecojn de la programaro funkciu ĝuste operaciinte kaj inteoperar en aro.

La provoj kutime efektivigas kun la nomitaj datumoj de provo, kiu estas aro selektita de tipaj datumoj al kiuj povas vidi submetita la sistemo, la moduloj aŭ la blokoj de kodo. Ili ankaŭ elektas: Datumoj kiuj portas al kondiĉoj limoj al la programaro sekve de provi lian toleron kaj robustez; datumoj de utileco por mezuradoj de rendimento; datumoj kiuj propocan apartaj aŭ eventualaj kondiĉoj malmulta komunaj kaj al kiuj la programaro kutime ne estos submetita sed povas okazi; ktp. La "datumoj de provo" ne nepre estas fikciaj aŭ "kreitaj", sed kutime se lin estas la de malmulta probablo de spritaĵo.

Ĝenerale, ekzistas fazo probatoria fino kaj kompleta de la programaro, nomita Beta Testo, dum kiu la sistemo instalita en normalaj kondiĉoj de operacio kaj laboro estas provita ĝisfunde sekve de trovi erarojn, nestabilecoj, eraraj respondoj, ktp. Kiu pasis la antaŭajn kontrolojn. Ĉi tiuj estas kutime realigitaj por adekvata dungitaro kontraktita aŭ tuŝita specife al tio. La eblaj trovitaj eraroj transdonas al la desarrolladores por lia depuración. En la kazo de programaro de disvolviĝo "al petita", la uzanto fino (kliento) estas kiu realigas la Beta Testo, havante por tio periodo de provo interkonsentita kun la desarrollador.

Instalado kaj paŝo al produktado

La instalado de la programaro estas la procezo por kiu la evoluintaj programoj estas transferidos taŭge al la komputilo destinas, inicializados, kaj, eventuale, agorditaj; ĉio tio kun la intenco de esti jam uzitaj por la uzanto fino. Ĝi konstituas la etapon fino en la propre koncerna disvolviĝo de la programaro. Poste de ĉi tiu la produkto eniros en la fazon de funkciado kaj produktado, por kiu estis desegnita.

La instalado, dependante de la evoluinta sistemo, ĝi povas konsisti en simpla kopio al la rigida disko destino (maloftaj kazoj nuntempe); aŭ bone, pli komune, kun unu el complejidad intera en kiu la malsamaj arkivoj komponantoj de la programaro (ejecutables, bibliotekoj, propraj datumoj, ktp.) Estas descomprimidos kaj kopiitaj al specifaj lokoj preestablecidos de la disko; ili inkluzive kreas interligojn kun aliaj produktoj, krom la propra mastruma sistemo. Ĉi tiu lasta kazo, komune estas sufiĉe aŭtomata procezo kiu estas kreita kaj gvidita kun heramientas specifaj programaro (pakita kaj dissendo, instaladores).

En produktoj de plej granda complejidad, la dua alternativa estas la uzita, sed estas realigita aŭ gvidita de specialistoj; ĝi povas inkluzive postuli la instaladon en pluraj kaj malsamaj computadores (instalado distribuita).

Ankaŭ, en programaro de meza kaj alta complejidad kutime estas postulita procezo de agordo kaj sankontrolo, por kiu atribuas taŭgajn parametrojn de funkciado kaj testea la operatividad funkcia de la produkto.

En produktoj de amasa vendo la kompletaj instaladoj, se estas relative simplaj, kutimas esti realigitaj de la propraj uzantoj finoj (tiaj kiel mastrumaj sistemoj, pakoj de oficejo, utilitarios, ktp.) Kun propraj iloj de instalado gvidita; inkluzive la agordo kutimas esti aŭtomata. En produktoj de specifa dezajno aŭ "al mezuro" la instalado restas restriktita, kutime, al personoj specialistoj implikitaj en la disvolviĝo de la programaro en demando.

Fojo realigita prospere la instalado de la programaro, la sama sekvinbero al la fazo de produktado (operatividad), dum kiu plenumas la funkciojn por kiuj estis evoluinta, tio estas, estas fine uzita por la (aŭ la) uzanto fino, produktante la rezultoj atenditaj.

Bontenado

La bontenado de programaro estas la procezo de kontrolo, pliboniĝo kaj optimización de la jam evoluinta kaj instalita programaro, kiu ankaŭ inkludas depuración de eraroj kaj difektoj kiuj povu esti filtrita de la fazo de provoj de kontrolo kaj beta testo. Ĉi tiu fazo estas la lasta (antaŭ iterar, laŭ la modelo uzita) kiu aplikas al la ciklo de vivo de la disvolviĝo de programaro. La fazo de bontenado estas kiu venas post kiam la programaro estas operativo kaj en produktado.

De bona dezajno kaj dokumentado de la disvolviĝo dependos kiel estos la fazo de bontenado, tiel en kosto temporal kiel mona. Modifoj realigitaj al programaro kiu estis ellaborita kun dokumentado indebida aŭ malriĉa kaj malbone dezajno povas alveni al esti tiel aŭ pli peniga ol disvolvi la programaron de la komenco. Por tio, estas de fundamenta graveco respekti laŭdeve ĉiuj taskoj de la fazoj de la disvolviĝo kaj subteni taŭga kaj ĝi kompletigas la dokumentadon.

La periodo de la fazo de bontenado estas kutime la plej granda en la tuta ciklo de vivo.[8] Ĉi tiu fazo implikas ankaŭ ĝisdatigoj kaj evoluadoj de la programaro; ne nepre implicas ke la sistemo havis erarojn. Oni aŭ pli ŝanĝoj en la programaro, ekzemple de adapto aŭ evolutivos, ĝi povas porti inkluzive al rever kaj adapti de parto de la unuaj fazoj de la komenca disvolviĝo, ŝanĝante ĉiuj aliaj; dependante de kiom profundaj estu la ŝanĝoj. La modelo komuna akvofalo estas aparte peniga en bontenado, pro tio ke lia rigideco implicas ke ajna ŝanĝo provokas revenon al fortaj kaj komenca fazo alteraciones en la aliaj fazoj de la ciklo de vivo.

Dum la periodo de bontenado, estas komuna kiu ŝprucas novajn reviziojn kaj versiojn de la produkto; kiu lin liberigas pli elpurigita, kun plej granda kaj pli bona funcionalidad, pli bona rendimento, ktp. Pluraj sono la facetoj kiuj eblas ŝanĝitaj por provoki ŝanĝojn deseables, evolutivos, adaptoj aŭ pligrandigoj kaj pliboniĝoj.

Ili esence havas la sekvajn tipojn de ŝanĝoj:

  • Perfectivos: Tiuj kiu portas al pliboniĝo de la interna kvalito de la programaro en ajna aspekto: Reestructuración de la kodo, difino pli klara de la sistemo kaj lia dokumentado; optimización de la rendimento kaj eficiencia.
  • Evolutivos: Aldonitaj, modifoj, inkluzive eliminij, necesaj en la programaro por kovri lian ekspansion aŭ ŝanĝon, laŭ la necesoj de la uzanto.
  • Adaptivos: Modifoj kiuj tuŝas al la medioj en kiuj la sistemo operacias, tiaj kiel: Ŝanĝoj de agordo de la aparataro (por ĝisdatigo aŭ pliboniĝo de elektronikaj komponantoj), ŝanĝoj en la programaro de bazo, en perantoj de datumbazo, en konektoj, ktp.
  • Correctivos: Alteraciones necesaj por korekti erarojn de ajna tipo en la produkto evoluinta programaro.

Vidu ankaŭ

Modeloj de ciklo de vivo

Referencoj

  1. ↑ Vortaro de la hispana lingvo 2005 (2010). Wordreference.Com (ed.): «Programaro» (vortaro). Espasa-Calpe. Konsultita la 1an de februaro 2010.
  2. ↑ Http://www.Respublicae.Net/lingvo/silabas/descomponer.Php Silabeador kaj Transcriptor Fonético kaj Fonológico
  3. ↑ Reala Hispana Akademio. «Signifo de la vorto Programaro». Vortaro de la Hispana Lingvo, 22aº Eldono. Konsultita la 14an de marto 2008.
  4. ↑ Reala Hispana Akademio. «Uzo de la vorto Programaro». Vortaro panhispánico de duboj, 1.° Eldono (oktobro 2005). Konsultita la 8an de februaro 2009.
  5. ↑ Pressman, Roger S. (2003). «La produkto», Inĝenierio de la Programaro, ĝi enfokusigas Oportuna, Kvina eldono eldono., Meksiko: Mc Graw Hill.
  6. ↑ IEEE Std, IEEE Programaro Engineering Standard: Glossary of Programaro Engineering Terminology. IEEE Computer Society Press, 1993
  7. ↑ Al b c d kaj f g h i j k «Ciklo de Vivo de la Programaro». Grupo Alarcos - Supera Lernejo de Komputika de Reala Urbo.
  8. ↑ Al b c d kaj Pressman, Roger S. (2003). «La procezo», Inĝenierio de la Programaro, ĝi enfokusigas Oportuna, Kvina eldono eldono., Mexico: Mc Graw Hill.
  9. ↑ «Termino "Elicitar"». 1Ra. Signifo - Wiktionary. Konsultita la 15 Dic 2008.
  10. ↑ Al b c d kaj f g h i «Ciklo de vivo de la Programaro kaj Modeloj de disvolviĝo». Mezlernejo de Profesia Formado - Ciferecaj Libroj.
  11. ↑ Programaro Requirements Engineering”, 2nd Edition, IEEE Computer Society. La Alamitos, CA, 1997 (Kompendio de papers kaj artikoloj en inĝenierio de kondiĉoj)
  12. ↑ «3a Workshop de Engenharia de Kondiĉoj». WER 2000, Rio-de-Ĵaneiro, 2000..
  13. ↑ «Recommended Practice for Programaro Requirements Specification». IEEE-SA Standards Board.
  14. ↑ «LEL kaj Scenejoj kiel metodiko en Inĝenierio de Kondiĉoj». Univ. De Morón, Bonaero.
  15. ↑ «Metodiko por la analizo de Kondiĉoj de Sistemoj Programaro». Univ. De Sevilo, 2001.

Bibliografio

Libroj

  • JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000). La Procezo Unuigita de Disvolviĝo de Programaro (en la hispana), Pearson Addisson-Wesley.
  • Pressman, Roger S. (2003). Inĝenierio de la Programaro, ĝi enfokusigas Oportuna, Kvina eldono eldono (en la hispana), Mc Graw Hill. ISBN 84-481-3214-9.
  • JACOBSON; BOOCH; RUMBAUGH (1999). UML - La Lingvo Unuigita de Modelado (en la hispana), Pearson Addisson-Wesley. Rational Programaro Corporation, Addison Wesley Iber-amerika. ISBN 84-7829-028-1.
  • Haeberer, Al. M.; P. Al. S. Veloso, G. Baum (1988). Formalización de la procezo de disvolviĝo de programaro, Ed. Preliminar eldono (en la hispana), Bonaero: Kapelusz. ISBN 950-13-9880-3.
  • Fowler, Martin; Kendall Sccott (1999). UML Guto al Guto (en la hispana), Addison Wesley. ISBN 9789684443648.
  • Loucopoulos, Pericles; Karakostas, 5a. (1995). System Requirements Engineering (en la angla), London: McGraw-Hill Companies, pp. 160 P.. ISBN 978-0077078430.
  • Sommerville, Ian; P. Sawyer (1997). Requirements Engineering: Al Good Practice Guide, 1ra. Edition eldono (en la angla), Wiley & Sons, pp. 404 P.. ISBN 978-0471974444.
  • Gottesdiener, Ellen; P. Sawyer (2002). Requirements by Collaboration: Workshops for Defining Needs (en la angla), Addison-Wesley Professional, pp. 368 P.. ISBN 978-0201786064.

Artikoloj kaj revuoj

  • Weitzenfeld - “La Procezo por Disvolviĝo de Programaro” - 2002
  • Karolo Reynoso - “Metodoj Heterodoxos evoluanta de Programaro” - 2004
  • Grupo ISSI - Univ. Politeknika de Lertaj Valencio - “Metodikoj en la Disvolviĝo de Programaro” - 2003
  • Martin Fowler - La Nova Metodiko - 2003
  • Cutter IT Journal – “Requirements Engineering and Management”. August 25, 2000. Cutter Consortium.
  • “Programaro Requirements Engineering”, 2nd Edition, IEEE Computer Society. La Alamitos, CA, 1997 (Kompendio de papers kaj artikoloj en inĝenierio de kondiĉoj).

Eksteraj ligoj

Wikcionario

Akirita de "http://ks312095.Kimsufi.Com../../../../Articles/al/r/t/Encydia-Wikilingue%7EArt%C3%ADculos_petitaj_2358.Html"