Metodologia De Desarrollo De Software Y Su Relacion Con El Aseguramiento De La Calidad En La Organización.docx

METODOLOGIA DE DESARROLLO DE SOFTWARE Y SU RELACION CON EL ASEGURAMIENTO DE LA CALIDAD EN LA ORGANIZACION Ing. Daniel Casazola Cruz| Curso de Actualización | Miguel Angel Torres Vargas (19-03-2019) 



El presente documento cuenta de dos partes donde la primera es el resumen de la lectura para el trabajo y la segunda parte es el análisis sobre el impacto que ha tenido implementar metodologías en la empresa Resumen, el presente trabajo es desarrollado para presentar el caso de la empresa Textile Sourcing Company donde se plasmarán los conceptos, definiciones y principios del tema a tratar

1. Introducción En el presente trabajo se plasmará el proceso de pruebas de calidad de software, para lo cual se pretende realizar pruebas al software desarrollado de modo que podamos obtener datos de como se esta realizando el avance y estas pruebas a. Antecedentes, en la empresa se tenia el siguiente escenario, no se realizaba un adecuado análisis de los requerimientos ni programación, tampoco validación SQA por lo que los sistemas desarrollados tenían errores en corto o largo tiempo de haberse implementado en la producción, 2. Metodologías a. ¿Por qué son necesarias las pruebas?, las pruebas del software son importante porque si no las realizamos podemos llevar a producción un sistema que, en lugar de facilitar el trabajo del usuario, le vamos a llenar de obstáculos, no siendo este el objetivo, además que podría costar mas tiempo y dinero realizar los ajustes y correcciones que cuando se hacen las pruebas de manera adecuada. b. Pruebas, es obligatorio realizar pruebas de software a las nuevas versiones del mismo, sin ellas no podríamos asegurar que el sistema no presentar errores c. Proceso de Pruebas, constituye 2 grandes grupos i. Verificación, en el área verificamos los requerimientos de usuario sean los mismos que los desarrollados ii. Validación, se procede a probar si soporta errores de entrada, calculo y de salida para poder decir que está correcto d. Principio de las pruebas, En los últimos años se ha propuesto una serie de principios que permiten establecer unas pautas comunes para que las empresas de desarrollo de software las conozcan y adapten a sus procesos de pruebas, de este enunciado identificaremos cuales principios se ajusta a la labor que se viene realizando. Los principios son: i. Principio 1. Las pruebas demuestran presencia de defectos, es el principal objetivo de demostración de las pruebas, ii. Principio 2. Las pruebas exhaustivas no existen, en este punto nos indican que no podríamos realizar pruebas de todo el sistema de extremo a extremo, por el contrario, se tiene que dividir en partes para poder obtener mejores resultados iii. Principio 3. Pruebas tempranas, este punto nos indica que cuando se hace una validación de pruebas del software temprano, ahorrará recursos ya sea

tiempo y dinero ya que si el error se muestra cuando el sistema ya está en producción, será mas costoso corregir todo el daño que ha causado iv. Principio 4. Agrupación de defectos, este punto indica que cuando separamos el sistema en agrupaciones para poder identificar errores validando, es mejor ya que nos podemos concentrar de manera más adecuada en resolverlos v. Principio 5. Paradoja del pesticida, en este punto se indica que, si presentamos un caso de pruebas y se encuentra errores, estos deben ser corregidos y no vueltos a encontrarse ya que supuestamente se debió mejorar el sistema vi. Principio 6. Las pruebas dependen del contexto, nos indican que el sistema se tiene que probar de acuerdo al contacto y exigencia para el requerimiento y que no es lo mismo hacer pruebas para un sistema pequeño que para el grande vii. Principio 7. Falacia de ausencia de errores, indica que las correcciones de errores son sirve de nada si no se cumple con el requerimiento del cliente. e. Modelo en V en pruebas de calidad de software En este punto el modelo en V nos indica que cuando vamos avanzando en el desarrollo del requerimiento se va haciendo una proyección de las pruebas que se tiene que realizar, luego en la etapa de validación (SQA) se desarrollan estas pruebas que fueron concebidas inicialmente, estas pruebas son: i. Pruebas de componentes, Estas pruebas se toman cuando se necesita o requiere probar por separado y no como sistema completo, es para probar la función del componente ii. Pruebas de integración, nos indica que podemos probar cómo funcionan 2 o más componentes que tengan relación iii. Prueba de sistemas, para hacer estas pruebas se debe elaborar un plan de pruebas, se unen todos los componentes ya integrados y se procede a realzar las pruebas como sistema, estas pruebas iv. Pruebas de aceptación, en estas pruebas se validan las pruebas funcionales indicadas en el requerimiento del sistema contra el sistema mismo para determinar si cumple al 100% v. Pruebas de backup / restauración, en este punto el sistema tiene que otorgar la calidad de poder sacar copia o backup a los personal encargado sin necesidad de entrar en la base de datos, tiene que poder exportar e importar datos en tablas para restauración, también se prueba la seguridad del sistema, aquí el personal que realiza la prueba tiene que tener claro lo que es un equivocación, defecto o falta y falla f. Calificación de pruebas i. Pruebas Funcionales, se refiere al aspecto funcional del sistema, es decir todo lo que el usuario ha requerido y como se debe comportar la aplicación, son las pruebas externas al sistema ii. Pruebas no funcionales, se o se orienta en las pruebas internas del sistema, rendimiento, validaciones con base de datos entre otros g. Técnicas de prueba h. Técnicas de caja negra, son usadas por el área de SQA, se determinan los valores de entrada y se validan los resultados, no se verifica el código del sistema, existen varios tipos de prueba para usar esta técnicas., en el siguiente ejemplo visualizamos un Miguel Torres Vargas - Página 2

cuadro donde identificamos los valores de entrada y salida según las pruebas, no teniendo en cuenta el código interno o cómo se comporta internamente el sistema

i.

Técnicas de caja blanca, el objetivo de estas técnica es validar el flujo de código, estándares, entre otros, se le pueden aplicar distintos niveles de pruebas, unitarias y de integración

3. Resultados: Se debe tener en cuenta que los procesos de pruebas se desarrollan por personas, son susceptibles a errores y por eso se deben reforzar bibliográficamente. La mayoría de las empresas han descuidado los procesos que involucran obtener un software de calidad 4. Discusión, es recomendable utilizar varios métodos de trabajo para encontrar errores en el software ya que las personas que desarrollan pueden tener una idea errónea o equivocada , las pruebas son importantes para identificar defectos y mejorar el software que es el objetivo final 5. Conclusión, se debe seguir implementando los procesos de pruebas del software en todas las empresas y en las universidades, generando un control de los defectos o fallas para obtener un mayor nivel de calidad

Miguel Torres Vargas - Página 3

APLICACION DE METODOLOGIA DE DESARROLLO DE SOFTWARE Y SU RELACION CON EL ASEGURAMIENTO DE LA CALIDAD EN LA ORGANIZACION 



Como ya hemos mencionado en trabajos anteriores, la empresa en sus inicios no tenia analista funcionales, mucho menos los programadores tenian claro estos conceptos de modo que los sistemas que desarrolaban no estaban documentados, probados y todos eran puestos en producción en caliente lo que originaba un gran descontento, desconfianza y baja de credibilidad del área TI La Aplicación de las metodologías en el área de TI para asegurar la calidad del software en la organización, fueron dando sus frutos, a medida que se fue estabilizando el área con un número determinado de personal y un numero de cuota por mes de proyectos se fue estabilizando también. Inicialmente el área de TI contaba con 3 programadores que no se daban abasto en la empresa en su magnitud inicial, esto sin contar que la empresa a lo largo del tiempo va creciendo por lo que también lo debe hacer el sistema para poder abarcar el ritmo de trabajo y la solicitud de los usuarios con respecto al mismo. En el siguiente cuadro tenemos una comparación del número de programadores y cuanto le costaba a la empresa mantenerlos y también cuanto le costaba (SobreCarga) volver a rehacer los trabajos mal hechos o que no se probaron antes de salir a producción. Cabe resaltar que inicialmente solo se programaba por programar donde el personal no tenía una técnica y asi el área y la empresa invertía tiempo y dinero. Como se puede apreciar según el cuadro tenemos que: - Inicialmente con 3 programadores tenía un gasto de S/ 3 000 soles que era sus pagos pero dejan proyectos inconclusos o fueron rechazados(18 proyectos), la fórmula del costo sobrecarga que se empleó para determinar cuánto le costaba a la empresa los problemas que se tenía con el software es el siguiente

-

Luego se contrató una nueva jefatura de sistemas para hacer una reingeniería donde concluyo incorporar analistas funcionales e implementar metodologías de trabajo, dando por resultado el dato de las gráficas, veamos los ejemplos

Miguel Torres Vargas - Página 4

Cuadro comparativo por Mes Mes del Año

Nro Programadores

Nro Analistas Funcionales

Nro de Projectos

Terminados

No Terminados

Costo Recursos S/

Costo SobreCarga

ene-18

3

0

22

4

18

S/. 3,000.00

S/. 18,000.00

feb-18

3

0

31

7

24

S/. 3,000.00

S/. 24,000.00

mar-18

4

0

16

8

8

S/. 3,950.00

S/. 7,900.00

abr-18

6

0

35

10

25

S/. 7,500.00

S/. 31,250.00

may-18

6

0

37

11

26

S/. 7,500.00

S/. 32,500.00

jun-18

5

1

24

16

8

S/. 6,200.00

S/. 9,920.00

jul-18

4

1

35

16

19

S/. 7,500.00

S/. 35,625.00

ago-18

5

2

37

24

13

S/. 9,400.00

S/. 24,440.00

sep-18

6

3

33

27

6

S/. 14,000.00

S/. 14,000.00

oct-18

6

4

38

33

5

S/. 14,000.00

S/. 11,666.67

nov-18

6

4

38

35

3

S/. 14,000.00

S/. 7,000.00

dic-18

6

4

44

41

3

S/. 14,000.00

S/. 7,000.00

ene-19

6

4

44

42

2

S/. 14,000.00

S/. 4,666.67

De donde se sacaron las siguientes graficas de análisis: 1. Contratación de personal, es claro que se contrató más personal para poder atacar todos los frentes de los problemas los cuales eran el día a día y los nuevos proyectos, el cuadro siguiente muestra cómo fue incorporándose personal al área

Contratación de Personal por Mes 7 6 5 4 3 2 1 0

Nro Programadores

Miguel Torres Vargas - Página 5

Nro Analistas Funcionales

2. Número de proyectos por mes, esta grafica muestra carga de trabajo que tenía encomendada el área y que no siempre fue desarrollándose satisfactoriamente

Nro de Projectos por Mes 50 40 30 20

10 0

Nro de Projectos

3. Cuadro Proyectos Terminados y No terminados, en el siguiente cuadro se puede analizar que a partir del mes de JULIO donde se incorporó la nueva metodología de trabajo el número de trabajos terminados y no terminados fue cambiando donde la satisfacción de los usuarios fue creciendo y recobrando credibilidad el área TI, se dejó atrás cuando solamente se cumplía ciertos proyectos y el resto del tiempo se gastaba en reprogramarlos

Proyectos Terminados y No Terminados 45 40 35

30 25

Terminados

20

No Terminados

15 10 5 0 Dec-17

Apr-18

Jul-18

Miguel Torres Vargas - Página 6

Oct-18

Feb-19

May-19

4. Avance de proyectos, en el siguiente cuadro se puede visualizar el número de proyectos, los proyectos terminados y los que no se han terminado donde cada vez es mayor que los trabajos dejados al área (requerimientos de usuario de mejora y nuevos proyectos) son terminados a tiempo, y la línea de no terminados cada vez es menor

Avance de Proyectos Nro de Projectos

Dec-17

Feb-18

Apr-18

May-18

Terminados

Jul-18

Sep-18

No Terminados

Oct-18

Dec-18

Feb-19

Mar-19

5. Costos de ReTrabajo, para calcular este costo utilizaron la formula inicial a grandes rasgos, este cuadro grafico muestra que inicialmente el costo monetario de volver a trabajar los proyectos era mayor que el invertido, por lo que posteriormente fue bajando y ajustándose al costo de los recursos que significa que lo que se está invirtiendo en personal, no es un gasto en vano ya que el sistema ahora si avanza y no tiene retrasos de programación.

S/. 50,000.00 S/. 40,000.00 S/. 30,000.00 S/. 20,000.00

Costo SobreCarga

S/. 10,000.00

Costo Recursos S/

Jan-19

Dec-18

Nov-18

Oct-18

Sep-18

Aug-18

Jul-18

Jun-18

May-18

Apr-18

Mar-18

Feb-18

S/. 0.00

Jan-18

Costo de Recursos

Costos ReTrabajo

El avance del sistema implica mejoras en procesos, automatizaciones nuevos horizontes que cubrir e implementar tal vez alguna certificación, cuando se cumplan mayor cantidad de requisitos para estas, seguir avanzando así concluye que el cliente confié en el sistema y no este causando retrasos

Miguel Torres Vargas - Página 7