Menú

Què és el model V STLC?

what is stlc v model

Proveu El Nostre Instrument Per Eliminar Problemes

Què és el model V STLC?

Un dels principals handicaps de model cascada STLC va ser que es van trobar defectes en una etapa molt posterior del procés de desenvolupament ja que es van fer proves al final del cicle de desenvolupament. Es va fer molt difícil i costós solucionar els defectes, ja que es va trobar en una etapa molt posterior. Per superar aquest problema, es va introduir un nou model de desenvolupament anomenat 'Model V'

El model V és ara un dels processos de desenvolupament de programari més utilitzat. La introducció del model V ha demostrat realment la implementació de proves des de la fase de requisits. El model V també s’anomena model de verificació i validació.

Model V STLC

Què aprendreu:

Verificació i validació

Per entendre el model V, primer entenem què és la verificació i la validació del programari.

Verificació : La verificació és una tècnica d’anàlisi estàtica. En aquesta tècnica, les proves es fan sense executar el codi. Els exemples inclouen: ressenyes, inspecció i tutorial.

Validació : La validació és una tècnica d’anàlisi dinàmica on es fan proves mitjançant l’execució del codi. Alguns exemples inclouen tècniques de proves funcionals i no funcionals.

Model V

En el model V, el desenvolupament i les activitats de control de qualitat es fan simultàniament. No hi ha una fase discreta anomenada Prova, sinó que la prova comença des de la fase de requisits. Les activitats de verificació i validació van de la mà.

Per entendre el model V, vegem la figura següent:

Model STLC V.

programari gratuït de còpia de seguretat de l’ordinador al disc dur extern

En un procés de desenvolupament típic, la part esquerra mostra les activitats de desenvolupament i la part dreta mostra les activitats de prova. No hauria d'equivocar-me si dic que en la fase de desenvolupament es realitzen tant la verificació com la validació juntament amb les activitats de desenvolupament reals.

Ara entenem la figura:

Costat de la mà esquerra

Com s'ha dit anteriorment, les activitats de l'esquerra són activitats de desenvolupament. Normalment sentim, quines proves podem fer en la fase de desenvolupament, però aquesta és la bellesa d’aquest model que demostra que les proves també es poden fer en totes les fases de les activitats de desenvolupament.

Anàlisi de requisits : En aquesta fase, es recullen, analitzen i estudien els requisits. Aquí no és important com s’implementa el sistema, però és important el que s’ha de fer el sistema. Sessions / tutorial de tempesta cerebral, es fan entrevistes per tenir els objectius clars.

  • Activitats de verificació : Revisions de requisits.
  • Activitats de validació : Creació de la UAT ( Prova d’acceptació de l’usuari ) casos de prova
  • Artefactes produïts : Document de comprensió de requisits, casos de proves UAT.

Requisits del sistema / Disseny d'alt nivell : En aquesta fase, es crea el disseny d'alt nivell del programari. L’equip estudia i investiga com es podrien implementar els requisits. També s’estudia la viabilitat tècnica dels requisits. L’equip també presenta els mòduls que es crearien / dependències, necessitats de maquinari / programari

  • Activitats de verificació : Ressenyes de disseny
  • Activitats de validació : Creació de Pla de proves del sistema i casos, Creació de mètriques de traçabilitat
  • Artefactes produïts : Casos de proves del sistema, informes de viabilitat, pla de proves del sistema, requisits de programari i maquinari, i mòduls a crear, etc.

Diseny arquitectònic: En aquesta fase, basat en el disseny d'alt nivell , es crea arquitectura de programari. Els mòduls, les seves relacions i dependències, els diagrames arquitectònics, les taules de bases de dades i els detalls tecnològics estan finalitzats en aquesta fase.

  • Activitats de verificació : Ressenyes de disseny
  • Activitats de validació : Pla de proves d’integració i casos de proves.
  • Artefactes produïts : Disseny de documents, pla de proves d’integració i casos de proves, dissenys de taules de bases de dades, etc.

Disseny de mòduls / Disseny de baix nivell: En aquesta fase, tots i cadascun dels mòduls dels components del programari es dissenyen individualment. En aquesta fase es finalitzen els mètodes, les classes, les interfícies, els tipus de dades, etc.

  • Activitats de verificació : Ressenyes de disseny
  • Activitats de validació : Creació i revisió de casos de proves unitàries.
  • Artefactes produïts : Casos de proves unitàries,

Implementació / Codi : En aquesta fase, es realitza la codificació real.

  • Activitats de verificació : Revisió de codi, revisió de casos de prova
  • Activitats de validació : Creació de casos de proves funcionals.
  • Artefactes produïts : casos de prova, revisar la llista de comprovació.

A la dreta

El costat dret mostra les activitats de prova o la fase de validació. Començarem per la part inferior.

Proves unitàries: En aquesta fase, s’executen tots els casos de prova d’unitat, creats a la fase de disseny de baix nivell.

* La prova unitària és una tècnica de prova de caixa blanca, on s’escriu un fragment de codi que invoca un mètode (o qualsevol altre fragment de codi) per comprovar si el fragment de codi està donant o no la sortida esperada. Aquesta prova la realitza bàsicament l’equip de desenvolupament. En cas d’alguna anomalia, es registren i fan un seguiment dels defectes.

Artefactes produïts : Resultats d'execució de les proves d'unitats

Proves d’integració : En aquesta fase, s'executen els casos de prova d'integració creats a la fase de disseny arquitectònic. En cas d'alguna anomalia, es registren els defectes i se'n fa un seguiment.

* Prova d’integració: la prova d’integració és una tècnica en què els mòduls provats per unitat s’integren i es comproven si els mòduls integrats donen els resultats esperats. En paraules més senzilles, valida si els components de l'aplicació funcionen junts com s'esperava.

Artefactes produïts : Resultats de la prova d’integració.

Proves de sistemes : En aquesta fase s'executen tots els casos de proves del sistema, casos de proves funcionals i casos de proves no funcionals. Dit d'una altra manera, aquí es realitzen les proves reals i reals de l'aplicació. Es registren els defectes i es fa un seguiment del seu tancament. L’informe de progrés també és una part important d’aquesta fase. Les mètriques de traçabilitat s’actualitzen per comprovar la cobertura i el risc mitigat.

Artefactes produïts : Resultats de proves, registres de proves, informe de defectes, informe resum de proves i matrius de traçabilitat actualitzades.

Proves d’acceptació d’usuaris : Les proves d'acceptació estan bàsicament relacionades amb les proves de requisits empresarials. Aquí es fan proves per validar que els requisits empresarials es compleixen a l'entorn de l'usuari. Proves de compatibilitat i, de vegades, proves no funcionals ( Càrrega, tensió i volum ) també es fan proves en aquesta fase.

Artefactes produïts : Resultats UAT, matrius de cobertura empresarial actualitzades.

Quan s’ha d’utilitzar el model V?

El model V és aplicable quan:

  • El requisit està ben definit i no és ambigu
  • Els criteris d’acceptació estan ben definits.
  • El projecte és de grandària curta a mitjana.
  • La tecnologia i les eines utilitzades no són dinàmiques.

Avantatges i inconvenients de l’ús del model V.

PROSCONTRES
- El desenvolupament i el progrés són molt organitzats i sistemàtics-No apte per a projectes més grans i complexos
- Funciona bé per a projectes de mida petita i mitjana.- No és adequat si els requisits no són consistents.
- Les proves comencen des del principi, de manera que s’identifiquen ambigüitats des del principi.- No es produeix cap programari de treball en l'etapa intermèdia.
- Fàcil de gestionar, ja que cada fase té objectius i objectius ben definits.- No hi ha cap provisió per fer anàlisis de risc, de manera que hi ha incertesa i riscos.

Lectura recomanada

^