Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1430IS08/docs/propuestaTG.docx · Web...

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado - Investigación

PROPUESTA PARA TRABAJO DE GRADOTÍTULO

V2Soft: Guía metodológica para el proceso de Validación y Verificación de Requerimientos para el usuario final

MODALIDAD

Proyecto de investigación, guía metodológica

OBJETIVO GENERAL

Desarrollar una guía metodológica que apoye el proceso de Validación y Verificación de Requerimientos, por parte de Stakeholders con rol de usuario y cliente, en empresas que no son desarrolladoras de Software

ESTUDIANTE(S)

María Ximena Narváez Barrera __________________________________________Documento Celular Teléfono fijo Correo Javerianocc. 1032381282 301-723-1552 7571370 [email protected]

DIRECTOR

Ing. Miguel Eduardo Torres__________________________________Correo Javeriano Empresa donde trabaja y [email protected]; Pontificia Universidad Javeriana; Profe-

sor Departamento de Sistemas

1

mailto:[email protected]

mailto:[email protected]


Contenido

ILUSTRACIONES Y TABLAS..............................................................................................4

1. OPORTUNIDAD O PROBLEMÁTICA................................................................................5

1.2 DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA........................................................51.3 FORMULACIÓN...........................................................................................................61.4 JUSTIFICACIÓN............................................................................................................61.5 IMPACTO ESPERADO DEL PROYECTO...............................................................................7

2 DESCRIPCIÓN DEL PROYECTO.......................................................................................8

2.1 OBJETIVO GENERAL..................................................................................................... 82.2 OBJETIVOS ESPECÍFICOS................................................................................................82.3 ENTREGABLES O RESULTADOS ESPERADOS.......................................................................8

3 PROCESO..............................................................................................................10

3.1 SPRINT 1: INVESTIGACIÓN...........................................................................................113.1.1 Metodología............................................................................................................113.1.2 Actividades..............................................................................................................12

3.2 SPRINT 2: DESARROLLO DEL ESTADO DEL ARTE...............................................................123.2.1 Metodología............................................................................................................123.2.2 Actividades..............................................................................................................123.2.3 Hitos........................................................................................................................13

3.3 SPRINT 3: SELECCIÓN DE METODOLOGÍAS ACORDE A LAS NECESIDADES DE LA GUÍA...............133.3.1 Metodología............................................................................................................133.3.2 Actividades..............................................................................................................133.3.3 Hitos........................................................................................................................14

3.4 SPRINT 4: IDENTIFICAR LAS DEBILIDADES, FALENCIAS Y/O PROBLEMÁTICAS..........................143.4.1 Metodología............................................................................................................143.4.2 Actividades..............................................................................................................153.4.3 Hitos........................................................................................................................15

3.5 SPRINT 5: DESARROLLO DE LA GUÍA METODOLÓGICA.......................................................153.5.1 Metodología............................................................................................................163.5.2 Actividades..............................................................................................................163.5.3 Hitos........................................................................................................................16

3.6 SPRINT 6: METODOLÓGICA EVALUACIÓN DE LA GUÍA.......................................................173.6.1 Metodología............................................................................................................173.6.2 Actividades..............................................................................................................173.6.3 Hitos........................................................................................................................18

2


4 GESTIÓN DEL PROYECTO...........................................................................................19

4.1 CALENDARIZACIÓN....................................................................................................194.2 PRESUPUESTO.......................................................................................................... 214.3 ANÁLISIS DE RIESGOS.................................................................................................224.4 COMPROMISO DE APOYO DE LA INSTITUCIÓN.................................................................28

4.4.1 Marco institucional.................................................................................................284.5 DERECHOS PATRIMONIALES.........................................................................................28

5 MARCO TEÓRICO / ESTADO DEL ARTE.........................................................................29

5.1 FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO..........................................295.2 GLOSARIO................................................................................................................35

6 REFERENCIAS Y BIBLIOGRAFÍA....................................................................................39

6.1 REFERENCIAS............................................................................................................396.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO...........................40

7 ANEXOS................................................................................................................43

3


Ilustraciones y tablas

Lista de ilustraciones

Ilustración 1. Actividades Empresa...........................................................................................5Ilustración 2. Impactos esperados............................................................................................7Ilustración 3. Actividades transversales de cada Sprint..........................................................10Ilustración 4. Tipos de riesgos................................................................................................22Ilustración 5. Marco institucional...........................................................................................28Ilustración 6. Ingeniería de Requerimientos...........................................................................29Ilustración 7. Distribución de los defectos.............................................................................31Ilustración 8. Esfuerzo para encontrar y corregir defectos.....................................................32Ilustración 9. Desarrollo de Requerimientos y Validación......................................................34Ilustración 10. Metodología SCRUM. Tomado de [3].............................................................43

Lista de tablas

Tabla 1. Entregables trabajo de grado.......................................................................................9Tabla 2. Actividades Sprint 1....................................................................................................12Tabla 3. Actividades Sprint 2....................................................................................................13Tabla 4. Hito Sprint 2................................................................................................................13Tabla 5. Actividades Sprint 3....................................................................................................14Tabla 6. Hito Sprint 3................................................................................................................14Tabla 7. Actividades Sprint 4....................................................................................................15Tabla 8. Hito Sprint 4................................................................................................................15Tabla 9. Actividades Sprint 5....................................................................................................16Tabla 10. Hitos Sprint 5............................................................................................................17Tabla 11. Actividades Sprint 6..................................................................................................18Tabla 12. Hitos Sprint 6............................................................................................................18Tabla 13. Cronograma trabajo de grado..................................................................................21Tabla 14. Presupuesto Recursos físicos....................................................................................21Tabla 15. Presupuesto Recursos humanos..............................................................................21Tabla 16. Presupuesto Total.....................................................................................................22 Tabla 17.Valoración de riesgos................................................................................................23Tabla 18. Tabla de riesgos........................................................................................................27Tabla 19. Porción costo por fase..............................................................................................32Tabla 20. Desventajas Outsourcing..........................................................................................34Tabla 21. Verificación y Validación..........................................................................................38

4


1. Oportunidad o Problemática

1.2 Descripción de la Oportunidad o ProblemáticaEn Colombia se presenta el modelo de empresa que busca el desarrollo de necesidades o productos de software, en empresas terceras (outsourcing), debido que este proceso no hace parte de su modelo de negocio y adicional, permite que se enfoquen en lo que real -mente es su negocio, como se menciona en [1] “Así podemos enfocarnos a producir, porque de lo contrario tendría que asumir desarrollos que no podría soportar con personal de dedi-cación exclusiva y que aumenta la carga prestacional” y a responder a un mercado cada vez más exigente y competitivo “En esas condiciones, todas las empresas necesitan servicios especializados, porque ninguna organización puede hacer de todo con buena rentabilidad.”[1]

Por lo tanto, por estrategia, necesidades, competencia y oportunidades, las empresas se requiere crear nuevos productos y/o servicios o mejoras a los ya existentes, para ofrecer-los a sus clientes tanto externos como internos y optimizar procesos que van acorde a su negocio.

Dada esta característica, la empresa terceriza el desarrollo de software, realiza una defini -ción y especificación de los requerimientos que se deben satisfacer y queda a la espera de ver estos requerimientos en una aplicación funcional.

Cuando se cumple el proceso de desarrollo y se recibe el software, existen empresas, que realizan una fase adicional, antes de poner a disposición el producto. Realizan la Validación y Verificación de los requerimientos en el software, este proceso, permite evaluar la comple-titud, consistencia y comportamiento del producto y así tener la garantía que se satisface los requerimientos establecidos.

En la Ilustración 1. Actividades Empresa, se sintetizan las actividades anteriormente mencio-nadas, correspondientes a la empresa que busca el outsourcing como alternativa para el desarrollo:

5

Define y especifica

Requerimientos

Terceriza desarrollo

Recibe desarrollo

Valida y Verifica Requerimientos

Certifica cumpliento


Ilustración 1. Actividades Empresa

El proceso de validación y Verificación de requerimientos consiste en la comprobación de los requerimientos desarrollados conforme a los especificados, acorde a la definición del Inter-national Software Testing Qualifications Board, la verificación es la "Confirmación mediante examen y mediante el suministro de evidencia objetiva que la especificación de los requisitos se han cumplido."[2] y la validación es la "Confirmación mediante examen y mediante el suministro de evidencia objetiva de que se han cumplido los requisitos para un uso específico previsto o aplicación."[2]

En el estudio de la validación y verificación de requerimientos, se ha identificado, una pro -blemática correspondiente a los requerimientos de sistemas no triviales, cuya complejidad, obliga que el proceso sea riguroso y exhaustivo; teniendo en cuenta la definición dada por [3] “en primer lugar, las pruebas no son determinantes. En segundo lugar, es necesario reali -zar pruebas bajo restricciones de tiempo y presupuesto.”, y al ser un proceso necesario, que no solo depende de la habilidad y del conocimiento del negocio de quien realiza la actividad, sino también de factores externos (tiempo, recursos, presupuesto), se presenta la oportuni-dad de proponer una metodología que apoye el proceso de validación y verificación de re -querimientos, bajo las condiciones descritas bajo la pregunta ¿Cómo lograr la validación y Verificación de requerimientos, que garantice la completitud de su especificación, para em-presas que contratan desarrollos a externos (outsourcing)?

1.3 FormulaciónDesarrollar una guía metodológica, que permita a una empresa que contrata desarrollos de software con terceros (Outsourcing), garantizar la calidad integral de la validación y verifica-ción de los requerimientos, su cumplimento y calidad.

1.4 JustificaciónLa calidad de los proyectos de software está directamente relacionada con el proceso de validación y verificación de requerimientos, debido que este proceso busca garantizar que los requerimientos establecidos se cumplan, que se encuentren acorde a su especificación y su funcionalidad sea la esperada por el usuario final.

Por lo tanto, el trabajo de grado busca dar una alternativa de mejora, determinando las actividades que son necesarias bajo los lineamientos de las buenas prácticas y metodolo-gías, a las empresas que realizan la validación y verificación de requerimientos y que terce-rizan el proceso de desarrollo de software, debido a que son empresas que buscan solucio -nes y al ser los expertos en el negocio, deben evaluar que realmente sus necesidades sean cubiertas.

6


1.5 Impacto Esperado del ProyectoA continuación en la Ilustración 2. Impactos esperados, se especifica los impactos estimados por el trabajo de grado.

Ilustración 2. Impactos esperados

7

Continuidad de la investigación y retroalimentación de la guia a partir de academicos y personas que realicen en su día a día, la Validación y Verificación de Requerimientos.

Corto Plazo

Aplicación de la guía en empresas que tercerice el desarollo.Analisis de costo y beneficio de implementación.

Mediano Plazo

Inclusión y difusión de la guía en estandares correspondientes a ingeniería de Requerimientos y a Pruebas de Software.

Largo Plazo


2 Descripción del Proyecto

Esta sección presenta la descripción general del proyecto.

2.1 Objetivo generalDesarrollar una guía metodológica que apoye el proceso de Validación y Verificación de Requerimientos, por parte de Stakeholders con rol de usuario y cliente, en empresas que no son desarrolladoras de Software1

2.2 Objetivos Específicos

Generar documento del estado del arte sobre las prácticas y modelos actuales de validación y verificación de los requerimientos de software para usuario final.

Seleccionar las mejores prácticas y modelos de validación y verificación de los re-querimientos.

Identificar las debilidades, falencias y/o problemáticas presentadas en el proceso de validación y verificación de requerimientos.

Elaborar una guía metodológica, que especifique el proceso de validación y verifica-ción de los requerimientos de software, dando alternativas de manejo a los puntos críticos identificados, en el marco de referencia de una empresa no desarrolladora de software

Evaluar la guía metodológica planteada, por medio de lista de chequeo y encuestas, dirigidas a expertos en validación y verificación de requerimientos

2.3 Entregables o Resultados EsperadosA continuación en la Tabla 1. Entregables trabajo de grado, se especifican los entregables del Trabajo de Grado y su correspondiente descripción.

Entregable Descripción

Estado del arte Documento con la base teórica para el desa-rrollo del trabajo de grado. Corresponde al marco teórico del trabajo de grado.

Guía metodológi- Guía metodológica para la validación y verifi-

1 Que usan los servicios de un tercero para el desarrollo de software, o, Empresas cuyo fin no es el desarrollo de software, o , Empresas clientes que no son del ámbito del desarrollo de software

8


ca cación de requerimientos

Documento con análisis de resulta-

dos

Documento con la evaluación de la guía me-todológica por parte de expertos. Correspon-de al proceso de Validación cuantitativa y cualitativa del grupo seleccionado para su evaluación.

Memoria del tra-bajo de grado.

Memoria del trabajo de grado, incluye como finalizo el proyecto, y los siguientes resulta-dos de los objetivos específicos:

Estado del arte Proceso de evaluación, selección de

prácticas para la guía Debilidades, falencias y/o problemá-

ticas encontrados en el proceso. Resultado de evaluación de la guía

Página web. Página web que permitirá el acceso a la in-formación del trabajo de grado y sus docu-mentos

Tabla 1. Entregables trabajo de grado

9


3 Proceso

El trabajo de grado se desarrollara bajo la metodología SCRUM, debido a que establece las actividades que se deben realizar en una metodología ágil que busca cumplir con el desarro-llo de los objetivos en tiempos acordados, con un incremento continuo. Debido que “Scrum tiene como base la idea de creación de ciclos breves, que comúnmente se llaman iteraciones, y que en Scrum se llamarán “Sprint” ”[4], de acuerdo a [5]: “Se denomina Sprint a cada ciclo o iteración de trabajo que produce una parte del producto terminada y funcionalmente ope-rativa (incremento)”

Por cada uno de los Sprint del proyecto se ejecutaran actividades que permitirán, definir, ejecutar, evaluar y retroalimentar, las ejecuciones de las iteraciones. En la Ilustración 3.Actividades transversales de cada Sprint, se presentan las actividades que se deben realizar acorde a la metodología, en cada uno de los Sprints de la propuesta. Actividades tomadas de la bibliografía [4] y [3].

Ilustración 3. Actividades transversales de cada Sprint

Sprints del proyecto

Para el desarrollo del trabajo de grado se identificaron seis fases que serán identificados como el Sprints, su desarrollo se apoyara en las metodologías de investigación: Descriptiva y exploratoria.

10

Reunión de planificación

del Sprint

Determinar cuales y como vana a ser las funcionalidades que se incorporaran en el

Sprint

Qué se entregará al terminar el Sprint.Cuál es el trabajo

necesario para realizar el

incremento previsto, y cómo lo llevará a

cabo

Scrum diario

Evaluación diaria del avance del proyecto:

- Lo que ha logrado desde el anterior

scrum diario.- Lo que va ha hacer

hasta el próximo scrum diario.

- Si están teniendo algún problema, o si

prevé que puede encontrar algún impedimento.

Revisión del Sprint

Al finalizar cada Sprint se revisa

funcionalmente el resultado, con los

implicados del proyecto.

Permite descubrir planteamientos

erróneos,mejorables o

malinterpretaciones en las

funcionalidades

Retrospectiva del Sprint

Reunión donde se debate el Sprint recientemente finalizado y los camibios que se

podrian mejorar en el proximo Sprint.

¿Qué ha ido bien durante el último

Sprint? , ¿Qué será mejorado para el siguiente Sprint?


El primer Sprint, corresponde a la investigación de cada una las fuentes de informa-ción sobre la validación y verificación de requerimientos, como resultado, se tendrá una bibliografía seleccionada que permite el desarrollo del segundo Sprint.

El propósito del segundo Sprint, es la creación del estado del arte que permita cono -cer el estado actual del proceso, precisar las definiciones del proceso de Validación y Verificación de Requerimientos, las metodologías, prácticas existentes y las necesi-dades que se deben cubrir en el proceso. Busca abordar la teoría y las practicas actuales.

En el tercer Sprint, se realizara la selección de actividades de validación y verifica-ción de requerimientos, que sean acorde a las necesidades de las empresas que tercerizan el desarrollo y se encargan de realizar este proceso. Es una fase importan-te porque enfoca la información del estado del arte al propósito de la guía.

Con el cuarto Sprint, se determinara las debilidades, falencias y/o problemáticas presentadas en el proceso de Validación y Verificación de los requerimientos, que afectan a los Stakeholders responsables del proceso de validación y verificación de los requerimientos. El interés de la fase es reconocer los eventos tanto internos como externos que rodean el proceso para determinar los frentes que se deben considerar en la guía.

El Sprint donde se desarrolla la guía metodológica es la quinta, como base se tiene el resultado de los Sprints anteriores donde se reconocieron puntos importantes que se deben tener en cuenta para su desarrollo.

Finalmente, el sexto Sprint busca la evaluación de la guía desarrollada en el Sprint quinto, la evaluación debe ser realizada por expertos quienes podrán evaluar si la guía da un valor agregado, evaluara si esta cubre todas las actividades necesarias, si es coherente, si es relevante. A partir de la evaluación se retroalimentara la guía.

A continuación, se realizara la descripción de la metodología que se abordara para el cum-plimiento de cada una de los Sprints y las actividades (Sprint backlog) asociadas

3.1 Sprint 1: Investigación El objetivo de la fase es la investigación de las fuentes relevantes para el desarrollo de la propuesta

3.1.1 Metodología

La metodología con la que se desarrollara la fase, es la exploratoria que permite “Un avance en el conocimiento de un fenómeno, con frecuencia con el propósito de precisar mejor un problema o para poder explicitar una hipótesis”[6] , o bien como lo menciona Malhotra en [7] “Es el diseño de investigación que tiene como objetivo primario facilitar una mayor pene-tración y compresión del problema que enfrenta el investigador” , bajo esta metodología se realizara la búsqueda de las fuentes que serán usadas en la siguiente fase.

11


3.1.2 Actividades

Las actividades que se realizaran bajo el desarrollo de la metodología, se definen en la Tabla2. Actividades Sprint 1.

Id actividad Actividad Resultado

A01 Búsqueda de fuentes primarias y secundarias de la validación y verifi-cación de los requerimientos

Referencias bibliografías: libros, artículos, trabajos de grado, que soporten el tema de investiga-ción

A02 Obtención de la bibliografía de la actividad A01

Bibliografía del trabajo de grado

A03 Consulta de la bibliografía obtenida en la actividad A02

Definición de bibliografía útil

Tabla 2. Actividades Sprint 1

3.2 Sprint 2: Desarrollo del estado del arteEn esta fase se desarrollara el estado del arte de la validación y verificación de los requeri -mientos.

3.2.1 Metodología

La metodología en la que se basara el desarrollo de la fase, es la descriptiva, ya que permite realizar la definición del proceso de validación y verificación de requerimientos, “La investi-gación descriptiva es el tipo de investigación concluyente que tiene como objetivo principal la descripción de algo, generalmente las características o funciones del problema en cuestión” [7]

3.2.2 Actividades

Las actividades que se realizaran bajo el desarrollo de la metodología, se definen en la Tabla3. Actividades Sprint 2


A04 Extracción de información de la acti-vidad A03

Desarrollo de fichas bibliográfi-cas

A05 Interpretación y análisis de la infor-mación extraída

Identificación de información valiosa y contundente para conti-nuar con la actividad A06

A06 Desarrollo de documento de estado del arte, basado en las fichas biblio-gráficas de la actividad A04 y la infor-

Documento con el estado del arte

12


mación analizada en A05

A07 Desarrollo de sección de la memoria de trabajo de grado con la documen-tación de A06

Documento parcial de memoria de trabajo de grado


3.2.3 Hitos

Los Hitos correspondientes al Sprint 2 se encuentran en la Tabla 4. Hito Sprint 2

Id Hito Hito Resultado

H01 Documento con el estado del arte. Definido en la sección 2.3Entrega-bles o Resultados Esperados

Cumplimiento del objetivo espe-cífico 1

H02 El resultado de la fase se incluye en la memoria de trabajo de grado

Cumplimiento parcial de la docu-mentación de la memoria del trabajo de grado.

Tabla 4. Hito Sprint 2

3.3 Sprint 3: Selección de metodologías acorde a las necesidades de la guíaA partir del estado del arte, seleccionar las metodologías, actividades acorde al objetivo de la guía, empresas que tercerizan el desarrollo

3.3.1 Metodología

La metodología en la que se basara el desarrollo de la fase, es la descriptiva, ya que permite la selección de las mejores prácticas y modelos de validación y verificación de los requeri-mientos y permite encontrar la relación entre las variables de estudio. Debido que “La Inves-tigación descriptiva es aquella que busca especificar las propiedades, características, y los perfiles importantes de personas, grupos, comunidades o cualquier otro fenómeno que se someta a un análisis”[8].

3.3.2 Actividades



A08 Identificación de actividades que son necesarias para la validación y verifi-cación de requerimientos en la etapa

Actividades identificadas.

13


posterior de desarrollo.

A09 Análisis de la información del estado del arte.

Identificación de la relación de las metodologías del estado del arte con las actividades identifi-cadas en A08.

A10 Desarrollo de documento con la información identificada en A09.

Documento con el resultado con la información identificada.

A11 Desarrollo de sección de la memoria de trabajo con la información de A10



3.3.3 Hitos



H03 Documento con las actividades de validación y verificación de requeri-mientos, acorde a las necesidades de las empresas de estudio.

Definido en la sección 2.3Entrega-bles o Resultados Esperados


H04 El resultado de la fase se incluye en la memoria de trabajo de grado

Cumplimento parcial de la docu-mentación de la memoria del trabajo de grado


3.4 Sprint 4: Identificar las debilidades, falencias y/o problemáticas Determinar las debilidades, falencias y/o problemáticas del proceso de Validación y Verifi-cación de los requerimientos desde el punto de vista de las necesidades de los Stakeholders, con el fin de identificar oportunidades de mejora.

3.4.1 Metodología

Para el desarrollo de la fase, se escogió la metodología descriptiva, como se mencionó en la sección 3.3.1, esta metodología permite identificar las propiedades en estudio, en este caso el entorno real del proceso de validación y verificación de los requerimientos.

14


3.4.2 Actividades



A12 Generar las preguntas para la en-cuesta con la que se realizara el le-vantamiento de información

Formato de encuesta dirigida a los Stakeholders

A13 Ejecución de la encuestas Resultados de las encuestas

A14 Análisis de los resultados de las en-cuestas realizadas en A13

Identificación de puntos críticos del proceso de validación y verifi-cación.

A15 Desarrollo de sección de la memoria de trabajo de grado con la documen-tación de A14



3.4.3 Hitos



H05 Documento con las Debilidades, falencias y/o problemáticas en-contrados



H06 El resultado de la fase se incluye en la memoria del trabajo de grado

Cumplimiento parcial de la docu-mentación de la memoria del trabajo de grado


3.5 Sprint 5: Desarrollo de la Guía metodológicaFase de desarrollo de la guía metodológica, corresponde a la fase central del trabajo de gra -do y toma como base las fases anteriores.

15


3.5.1 Metodología

La metodología que se empleara para el desarrollo de la fase, corresponde a la descriptiva, ya que permite realizar la definición y descripción del proceso para la validación y verifica-ción de requerimientos para las empresas que tercerizan el desarrollo.

Esta metodología permite en función de la guía:

Describiro Característicaso Funciones

Especificaro Propiedadeso Característicaso Perfiles

3.5.2 Actividades

Las actividades que se realizaran bajo el desarrollo de la metodología, se definen en la Tabla9. Actividades Sprint 5.


A16 Desarrollo de la guía metodológica de acuerdo a los resultados obteni-dos en las fases anteriores

V2Soft: Guía metodológica para el proceso de Validación y Verifi-cación de Requerimientos para el usuario final

A17 Desarrollo de sección de la memoria de trabajo de grado con el resultado de la actividad A16



3.5.3 Hitos

Los Hitos correspondientes al Sprint 5 se encuentran en la Tabla 10. Hitos Sprint 5.


H07 V2Soft: Guía metodológica para el proceso de Validación y Verificación de Requerimientos.



H08 La guía metodológica se incluye en la memoria del trabajo de grado

Cumplimiento parcial de la docu-mentación de la memoria del

16


trabajo de grado

Tabla 10. Hitos Sprint 5

3.6 Sprint 6: Metodológica Evaluación de la guíaLa sexta fase, busca la evaluación de la guía desarrollada en la fase anterior por parte de expertos en Validación y Verificación de Requerimientos

3.6.1 Metodología

La metodología para esta fase es la descriptiva, ya que permite realizar estudio de los resul -tados de la guía, mediante la aplicación de encuestas a expertos

3.6.2 Actividades



A18 Búsqueda de expertos que se com-prometan con evaluar la guía desa-rrollada

Expertos comprometidos para la evaluación de la guía

A19 Determinar criterios a evaluar Lista de criterios que se deben evaluar en la guía

A20 Creación de modelo de evaluación que incluya los criterios encontrados en A14

Modelo de evaluación que se entregara a los expertos.

Encuesta Lista de chequeo

A21 Reunión con los expertos para expo-ner la V2Soft guía metodológica y entregar el modelo de evaluación

Evaluación de la guía por parte de los expertos

A22 Valoración de los resultados de las evaluaciones de los expertos

Documento con el resultado de la evaluación y el análisis de los resultados

A23 Retroalimentación de guía metodo-lógica. En caso de ser necesario se vuelve a realizar la actividad A03 que permite la consulta de bibliografía que soporte los comentarios obteni-dos en la evaluación

Mejora de la guía metodológica acorde a comentarios

A24 Desarrollo de sección de la memoria de trabajo de grado con la documen-

Documento de memoria de tra-bajo de grado finalizado

17


tación de la fase 6

A25 Desarrollo de página Web con el trabajo de grado

Página web del trabajo de grado


3.6.3 Hitos

Los Hitos correspondientes al sprint 6 se encuentran en la Tabla 12. Hitos Sprint 6.


H09 Documento con el resultado de la evaluación y el análisis de los resul-tados.



H10 La evaluación de la guía metodológi-ca se incluye en la memoria del tra-bajo de grado

Cumplimiento de la documenta-ción de la memoria del trabajo de grado

H11 Página web del trabajo de grado Cumplimiento del entregable del trabajo de grado: Página web

Tabla 12. Hitos Sprint 6

18


4 Gestión del Proyecto

4.1 CalendarizaciónEn esta sección se encuentran las actividades y su respectiva programación de fecha inicio, fecha final y tiempo de dedicación, consolidados en la Tabla 13. Cronograma trabajo de gra-do.

Id activi-dad

Actividad Fecha de inicio

Fecha final Tiempo dedicación

SPRINT 1

AS01 Reunión de planificación del Sprint 28-07-2014 28-07-2014 1 Hora

A01 Búsqueda de fuentes primarias y secundarias de la validación y verificación de los requerimientos

28-07-2014 01-08-2014 8 Horas

A02 Obtención de la bibliografía de la actividad A01 02-08-2014 05-08-2014 8 Horas

A03 Consulta de la bibliografía obtenida en la actividad A02

06-08-2014 09-08-2014 8 Horas

AS02 Reunión de revisión del Sprint 08-08-2014 08-08-2014 0.5 Horas

AS03 Retrospectiva del Sprint 08-08-2014 08-08-2014 0.5 Horas

SPRINT 2


A04 Extracción de información de la actividad A03 10-08-2014 12-08-2014 4 Horas

A05 Interpretación y análisis de la información extraída 13-08-2014 15-08-2014 6 Horas

A06 Desarrollo de documento de estado del arte, basa-do en las fichas bibliográficas de la actividad A04 y la información analizada en A05

16-08-2014 22-08-2014 14 Horas

A07 Desarrollo de sección de la memoria de trabajo de grado con la documentación de A06

23-08-2014 24-08-2014 4 Horas



SPRINT 3


A08 Identificación de actividades que son necesarias para la validación y verificación de requerimientos en la etapa posterior de desarrollo.

25-08-2014 28-08-2014 8 horas

A09 Análisis de la información del estado del arte. 29-08-2014 05-09-2014 6 Horas

19


A10 Desarrollo de documento con la información iden-tificada en A09.

05-09-2014 10-09-2014 8 Horas

A11 Desarrollo de sección de la memoria de trabajo con la información de A10

11-09-2014 12-09-2014 4 Horas



SPRINT 4


A12 Generar las preguntas para la encuesta con la que se realizara el levantamiento de información

13-09-2014 13-09-2014 3 Horas

A13 Ejecución de la encuestas 14-09-2014 18-09-2014 4 Horas

A14 Análisis de los resultados de las encuestas realiza-das en A13

19-09-2014 23-09-2014 8 Horas

A15 Desarrollo de sección de la memoria de trabajo de grado con la documentación de A13

24-09-2014 25-09-2014 2 Horas



SPRINT 5


A16 Desarrollo de la guía metodológica de acuerdo a los resultados obtenidos en las fases anteriores

13-10-2014 16-10-2014 40 Horas

A17 Desarrollo de sección de la memoria de trabajo de grado con el resultado de la actividad A15

17-10-2014 22-10-2014 12 Horas



SPRINT 6


A18 Búsqueda de expertos que se comprometan con evaluar la guía desarrollada

25-10-2014 27-10-2014 5 Horas

A19 Determinar criterios a evaluar 28-10-2014 29-10-2014 4 Horas

A20 Creación de modelo de evaluación que incluya los criterios encontrados en A14

30-10-2014 31-10-2014 5 Horas

A21 Reunión con los expertos para exponer la V2Soft guía metodológica y entregar el modelo de evalua-ción

03-11-2014 03-11-2014 2 Horas

20


A22 Valoración de los resultados de las evaluaciones de los expertos

04-11-2014 08-11-2014 10 Horas

A23 Retroalimentación de guía metodológica. En caso de ser necesario se vuelve a realizar la actividad A03 que permite la consulta de bibliografía que soporte los comentarios obtenidos en la evalua-ción

09-11-2014 14-11-2014 12 Horas

A24 Desarrollo de sección de la memoria de trabajo de grado con la documentación de la fase 6

15-11-2014 16-11-2014 5 Horas

A25 Desarrollo de página Web con el trabajo de grado 17-11-2014 24-11-2014 14 Horas



Tabla 13. Cronograma trabajo de grado

4.2 PresupuestoEl presupuesto para el desarrollo del proyecto de trabajo de grado, se encuentra divido en dos grupos, que representan:

Recursos humanos, ver Tabla 15. Presupuesto Recursos humanos Recursos físicos y servicios, ver Tabla 14. Presupuesto Recursos físicos

Y un presupuesto total, ver Tabla 16. Presupuesto Total

RECURSOS FÍSICOS Y SERVICIOS

Rubro Cantidad Valor TotalComputador 1 $1.800.000 $1.800.000Salida para investigación inicial 4 $20.000 $80.000Salida para reuniones con expertos 8 $20.000 $160.000Papelería 1 $100.000 $100.000Documentación y libros asociados 4 $80.000 $320.000Total $2.460.000

Tabla 14. Presupuesto Recursos físicos

RECURSOS HUMANOS

PersonaHoras de

trabajo por semana

Semanas Precio por hora Total

María Ximena Narváez Barrera 12 18 $15.000 $3.240.000Ing. Miguel Torres 2 18 $50.000 $1.800.000Total 14 36 $85.000 $5.040.000

Tabla 15. Presupuesto Recursos humanos

21


TOTALES

Ítem ValorRecursos Humanos $5.040.000

Recursos Físicos y Servicios $2.460.000

Total $7.500.000

Tabla 16. Presupuesto Total

4.3 Análisis de RiesgosLos riesgos del proyecto están clasificados según su tipo, ver Ilustración 4. Tipos de riesgos, pero para que se materialice el riesgo se analizó la probabilidad de ocurrencia, el impacto de la materialización del riesgo en el proyecto y su criticidad que corresponde a la valora -ción: Probabilidad vs Impacto.

Ilustración 4. Tipos de riesgos La probabilidad mide la posible en que se materialice el riesgo, puede ser Alto (A),

medio (M), o baja (B) El impacto se refiere al efecto del riesgo en el proyecto, si el impacto es Alto (A) es

un riesgo cuya materialización afecta de manera negativa al desarrollo del proyecto causando una posible suspensión, un riesgo con impacto medio (M), significa que su materialización pone en peligro al trabajo, haciendo que se retrase la ejecución nor -mal del mismo. Y el impacto bajo (B) su materialización no afecta al desarrollo del proyecto pero es un riesgo que se debe controlar antes que suba de nivel.

La criticidad o valoración está determinada por la combinación de la probabilidad y el impacto, en la Tabla 17.Valoración de riesgos, se encuentra la valoración respecto a la probabilidad y el impacto en el proyecto.

22

Plan eación P Se refi ere a los riesgos asociados a la etapa d e o rgan ización del proyecto do nde se contem plan los ti em pos y la m anera de e jecucion de l proyecto

Ejecución ERiesgos asociad os a e jecución de las actividades identificadas en la etapa de p laneació n

Com u nicación C Riesgos asociados a la falta de com u nicación entre la persona que desarrolla e l trabajo de grado, e l d irecto r y las posibles fuentes d e apoyo


Tabla 17.Valoración de riesgos

En la Tabla 18. Tabla de riesgo, se presentan los riesgos identificados para el proyecto, su identificador, su descripción, se clasificaron de acuerdo a: tipo, probabilidad, impacto, se asignó la valoración de acuerdo a la Tabla 17.Valoración de riesgos, se definió un plan para mitigar el riesgo y un plan de contingencia en caso de presentarse el riesgo.

23

Grave

Medio

Bajo

Probabili-dad

Impacto Valoración

A A GraveA M Grave

A B Medio

M A Grave

M M Medio

M B Medio

B A Medio

B M Bajo

B B Bajo

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado - <Guía Metodológica>

Id riesgo

Tipo

Descripción Proba-bilidad

Impac-to

Valo-ración

Mitigación Contingencia

R01 P Mala definición del alcance del proyecto M A Validación del alcance con director de

trabajo de grado

Re definición de nuevo alcance Generación de nuevo cronograma con

las actividades de la redefinición del alcance

R02 P Mala definición del problema B A

Validación de la problemática con direc-tor de trabajo de grado

Identificación de problemática de acuer-do al alcance de la guía, definición del marco temático de la guía

Re definición de la problemática Generación de nuevo cronograma con

las actividades de la redefinición de problemática

R03 P Mala planeación del Cronograma M A Validación de actividades y cronograma

con director de trabajo de grado

Modificación de cronograma Trabajo extra para la conformación de

las nuevas actividades

R04 EMala ejecución del

cronograma M A

Llevar un control estricto del cronogra-ma donde se tenga especificadas las fechas de entrega

Llevar un control estricto las actividades a ejecutar.

Actualización de cronograma, donde se incluye las fechas actualizadas

Ejecución de actividades hasta cubrir el desfase de la mala ejecución

R05 P,E Cambio de activida-des M M

Actividades aprobadas y evaluadas por el director de trabajo de grado

Actualización de cronograma, donde se incluye el cambio de actividades

Trabajo extra para cubrir la modificación de actividades

R06 PActividades no con-templadas en el cro-

nogramaB A

Validación de actividades con director Validación de actividades obligatorias

para trabajo de grado enfocado a guía metodológica

Inclusión de actividades en cronograma Inclusión de nuevos tiempos para ejecu-

ción de actividades Aumentar horas de trabajo para cubrir

los nuevos tiempos

Página 24


R07 P,ETiempos asignados para las actividades no son suficientes

M A Controlar el cumplimiento de tiempos

en cada una de las actividades especifi-cadas en el cronograma.

Aumentar horas de trabajo para cumplir con las actividades planteadas

R08 E Pérdida de informa-ción bibliográfica M A

Administración de bibliografía en Zotero y en repositorio

Incluir en repositorio, los documentos identificados en la bibliografía

Uso de la información registrada en repositorio y búsqueda de información con las referencias de Zotero

R09 E Pérdida de docu-mentación de la guía M B

Documentación de la guía con copia en el repositorio

Llevar bitácoras en un repositorio con la trabajo de grado información importan-te para el desarrollo del

Uso de información registrada en repo-sitorio

R10 P,E Falta de información B A Consulta de fuentes de información Identificación de temas pilares para la

búsqueda de bibliografía

Búsqueda de información Asignación de tiempo extra para la bús-

queda de información faltante

R11 E Bibliografía irrele-vante o errada B M

Validación de calidad de las bibliografías Búsqueda de bibliografía acorde a los

temas a desarrollar Bibliografía de fuentes confiables, como

libros y académicas

Supresión de bibliografía identificada como irrelevante o fuente no confiable

En caso de ser bibliografía poco confia-ble, búsqueda de nuevas fuentes

R12 EControl errado de

versiones del docu-mento

B M Definición de versiona miento de cada uno de los entregables

Corrección de versiones acorde a defini-ciones

R13 E Perdida de equipo personal M M Información, documentación y bibliogra-

fía en repositorio Uso de equipos de la facultad

R14 E,C Falta de comunica-ción con el director de trabajo de grado

B A Estar en constante contacto con el di-rector de trabajo de grado para resolver dudas que se vayan presentando.

Programar reuniones periódicas con el

Plantear reuniones extra a las progra-madas en el trabajo de grado

Página 25


director del trabajo de grado: Fijar hora-rio

Reunirse con el director de trabajo de grado, para comprobar el avance y desa-rrollo del proyecto

Llevar una bitácora de las reuniones realizadas con el director de trabajo de grado, donde se muestre las decisiones tomadas.

R15 EPoca disponibilidad

del director de traba-jo de grado

B A Planificación de reuniones con el direc-

tor de trabajo de grado acorde su hora-rio disponible.

Definición de nuevos tiempos de reunio-nes para dar continuidad

R16 C Reuniones poco efi-cientes B A

Planeación de temas a tratar en cada una de las reuniones

Cumplimiento de temas planeados en cada reunión

Generación de acta de cada reunión realizada

Re planificación de reuniones con objeti-vos claros

Ejecución de reuniones acuerdo a la planificación realizada

R17 E Incumplimiento de entregas B A

Seguimiento y cumplimiento de crono-grama de trabajo de grado

Entrega inmediata del compromiso defi-nido desde el cronograma de activida-des

Entrega de compromisos en el menor tiempo posible según cronograma

Aumentar horas de trabajo para cubrir el desvío de tiempos por el incumpli-miento

R18 E Alcance del proyecto no cumplido B A

Seguimiento al cronograma, actividades y su cumplimiento

En caso de evidenciarse retraso, se in-cluirán horas de trabajo con el fin de estar acorde a cronograma

Validación de actividades faltantes Inclusión de tiempo para finalizar traba-

jo en el semestre en curso

R19 P,E,C

No contar con perso-nas expertas para la

B A Búsqueda de terceros conocedoras del tema para que evalúen la guía

Búsqueda de personal académico cono-cedora en el proceso de ingeniería de

Página 26


evaluación de la guía requerimientos para que evalúen la guía

R20 P,C

Indisponibilidad de personas expertas

para la evaluación de la guía

M A

Establecer compromisos con los exper-tos que van evaluar guía para realizar las actividades de evaluación

Búsqueda de nuevas personas expertas que se comprometen en la evaluación de la guía

Aumentar horas de trabajo para poder realizar las actividades correspondientes al contacto de personas expertas

R21 E La calidad de la guía no es la esperada B A

Basarse en estándares y mejores prácti-cas para la generación de la guía

Aumentar horas de trabajo enfocados a mejorar los puntos encontrados con falencia de calidad, soportándose en mejores prácticas y estándares

R22 E

Las personas exper-tas no ven valor

agregado a la guía o evalúa mal la guía.

B A

Realizar acuerdo con los evaluadores para mostrar avances en el desarrollo de la guía , con el fin de recibir retroalimen-tación

Corregir las retroalimentaciones recibi-das por parte de los evaluadores, en caso de ser necesario incluir correccio-nes, se debe incluir tiempo adicional para realizar las actividades.

Tener en cuenta los comentarios sumi-nistrados por los evaluadores para in-cluirlos en la guía

Aumentar horas de trabajo para com-plementar la guía acorde a los comenta-rios, sugerencias de los evaluadores

Volver al ciclo de evaluación de la guía, para esto se debe realizar nuevamente las actividades correspondientes a los evaluadores,

Tabla 18. Tabla de riesgos

Página 27


4.4 Compromiso de apoyo de la Institución Al realizarse el trabajo de grado en la institución; la institución se compromete a apoyar a la estudiante durante el transcurso del semestre en el que se realizara el trabajo de grado, con los recursos necesarios, para que se realice y se finalice adecuadamente el trabajo de grado.

4.4.1 Marco institucional

En la Ilustración 5. Marco institucional, se especifica el marco institucional del proyecto de trabajo de grado.

Ilustración 5. Marco institucional

4.5 Derechos PatrimonialesTanto los derechos morales como los patrimoniales por la producción intelectual pertene-cen a la estudiante que desarrolla el trabajo de grado.

Página 28

Universidad Pontifica Universidad Javeriana

Departamento Departamento de Sistemas Facultad de Ingeniería

Director trabajo de grado

Miguel Eduardo Torres

Proyecto de Grado a cargo de Estudiante

María Ximena Narváez BarreraIngeniería de sistemasUltimo Semestre


5 Marco Teórico / Estado del Arte

En esta sección, se presenta información complementaria a la propuesta de trabajo de gra -do, se profundizara el proceso de validación y verificación de requerimientos desde un pun-to de vista macro con el fin de presentar su importancia y su línea de conocimiento.

5.1 Fundamentos y conceptos relevantes para el proyecto.Uno de los procesos que favorece el éxito y calidad de los proyectos de ingeniería de softwa-re, es la ingeniería de Requerimientos, tal como se define en [9], “La ingeniería de requeri-mientos es uno de los procesos más importantes, pero a su vez más críticos, dentro del desa -rrollo de software ya que es donde se define el diseño de la solución según las necesidades del cliente”.

La ingeniería de Requerimientos, establece actividades que soportan y facilitan el ciclo de vida de los requerimientos, desde su desarrollo, hasta su administración; permite encontrar, establecer, definir y documentar los requerimientos de software, también permite, que los involucrados del sistema o Stakeholders, comprendan de manera más fácil las necesidades y el propósito del sistema, la definición de los atributos y condiciones que el sistema debe cumplir. En la Ilustración 6. Ingeniería de Requerimientos, se presenta el dominio y los sub-componentes que enmarcan el proceso, tomadas de [10].

Ilustración 6. Ingeniería de Requerimientos

A continuación se describe cada subcomponente del desarrollo de los Requerimientos:

Recolección: Fase correspondiente al levantamiento de los requerimientos que se deben desarrollar, esta actividad, permite identificar, descubrir las necesidades, intereses, para sí conocer los límites del sistema y entender el problema a solucio-nar. [9]

Página 29

Ingeniería de Requerimientos

Desarrollo de los Requerimientos

Recolección Análisis Especificación Validación

Administración de

Requerimientos


Análisis: Corresponde al análisis de los requerimientos recolectados, esta etapa es primordial, ya que permite, según [11] definir:

o “Detectar y resolver los conflictos entre los requerimientoso Descubrir los límites del software y como deben obrar recíprocamente con su

ambienteo Elaborar los requerimientos del sistema para derivar requisitos de softwa-

re.”

Adicional, permite reconocer las características de los requerimientos, su clasifica-ción, son la base de la especificación y para el proceso de validación y verificación. Es la etapa que permite evaluar si realmente se comprendió los requerimientos recolectados.

Especificación: Definición de un documento que presente los requerimientos reco-lectados y analizados, de manera consistente, los requerimientos se deben presen-tarse de manera completa, se debe documentar cada una de las funcionalidades, capacidades y restricciones del sistema. Los requerimientos que se especifiquen deben cumplir con las características de calidad: Correcto, Completo, factible, no – ambiguo, necesario, consistente, prioriza-ble, entendible, verificable, modificable, trazable, diseño independiente, no redun-dante. [12]

Validación: “Se refiere al proceso de examinar el documento de los requerimientos para asegurarse de que se define el software correctamente.”[11]. Esta validación se conoce como validación estática delos requerimientos. Permite “Encontrar errores, evidenciar carencia de claridad, confusión o contradicciones” [11].

Pero aun así, teniendo un buen proceso de desarrollo de requerimientos, se puede presentar inconsistencias, que no fueron detectadas en dicha etapa. Por lo tanto, no solo es necesario que la validación y verificación de requerimientos se realice de manera estática, si no también dinámica, es decir, se realice una vez el desarrollo de software se haya concluido, teniendo en cuenta que, la verificación confirma que el software, presenta los requerimientos especificados, garantizando que se “desarrolló el producto correctamente” y con la validación confirma que el software se ajustará al uso pretendido, garantizando que “desarrolló el producto correcto”.

Importancia del proceso de Validación y verificación de Requerimientos

Estudios como [13] y [14], muestran la necesidad e importancia del proceso de Validación y Verificación de requerimientos. En la Ilustración 7. Distribución de los defectos, se presentan los porcentajes donde se encuentran la causa raíz de los defectos de un proyecto:

Página 30


RequerimientosDiseñoOtrosCodificación

Ilustración 7. Distribución de los defectos

Más de la mitad de todos los defectos del proyecto, pueden atribuirse al proceso de levantamiento de requerimientos.

La causa raíz de que el 56% de todos los defectos identificados en los proyectos, en la fase de validación y verificación, es el resultado de errores cuyo origen es la fase de desarrollo de los requerimientos. De estos errores, la mitad de ellos se debe a que están mal escritos, ambiguos, no son claros o son incorrectos. La otra mitad se debe a los requerimientos que fueron omitidos. [13]. Un proceso bien definido para la validación estática de requerimientos, mitigaría en gran parte dicho porcentaje de la etapa de requerimientos.

Los demás porcentajes de la Ilustración 7. Distribución de los defectos, está dada por el diseño, otros y la codificación.

En la Ilustración 8. Esfuerzo para encontrar y corregir defectos, se definen los porcentajes del estudio [14], donde se muestra que los defectos de los requerimientos son desapercibi-dos hasta la fase de la ejecución de pruebas, o, hasta que el sistema es desarrollado y entre-gado al cliente.

En este caso, el esfuerzo y costo, que lleva a corregir los defectos cuyo origen se puede re -montar a los requerimientos, es incluso más alto que 82%, puesto que un error en requeri-mientos se debe corregir no solamente en los requerimientos, sino también en el diseño, el código, y los casos de prueba, en todos los artefactos donde se encuentren definidos o rela -cionado. Por lo tanto, el esfuerzo del re-trabajo puede casi igualar el esfuerzo inicial del diseño, del desarrollo y de la prueba.

Página 31

27%

10% 7%


RequerimientosDiseñoOtrosCodificación

Ilustración 8. Esfuerzo para encontrar y corregir defectos

El estudio referenciado en [14], presenta el costo del esfuerzo requerido para dar solución a los defectos encontrados en una fase determinada, presentado en la Tabla 19. Porción costopor fase, por ejemplo si se detecta un defecto en la fase de Operación del sistema, su co-rrección presentaría un costo de 40 veces a 1000 veces, de lo que hubiera costado corregir-lo en la fase de Requerimientos.

Fase donde se encuentra el defecto Porción de costoRequerimiento 1Diseño 3-6Codificación 10Pruebas de sistema / Integración 15-40Pruebas de aceptación de usuario 30-70Operación 40-1000

Tabla 19. Porción costo por fase

Teniendo en cuenta el estudio [14], se reconoce la importancia del proceso de validación y verificación de Requerimientos y su esfuerzo requerido. Es un proceso valioso, que permite determinar inconsistencias, falencias y/o omisiones que no fueron detectados en fases ante-riores.

Cuando se realiza un buen proceso de desarrollo de requerimientos, se da la base y los fun -damentos del sistema, la ingeniería de Requerimientos, disminuye la brecha entre lo defini -do y lo desarrollado, sus etapas son primordiales y son el sustento de la fase posterior, pero es mediante el proceso de verificación y validación de requerimientos que se demuestra lo que realmente hace el sistema y que su funcionalidad se encuentra conforme lo solicitado y esperado.

Página 32

82%

13%4 %


Teniendo en cuenta el marco del proyecto de trabajo de grado, donde la empresa terceriza el proceso de desarrollo software, modelo presentado en la Ilustración 1. Actividades Em-presa, se identifica que el involucramiento en validación y verificación de requerimientos es más que necesaria por parte de los interesados del sistema, no solo por las razones expues -tas anteriormente, si no que adicional, los encargados de realizar la validación y verificación son Stakeholders que conocen el negocio y la operación del día a día, son los expertos que pueden identificar con mayor precisión las posibles falencias, conocen el uso esperado y la razón por la que se construyó el sistema.

La empresa encargada del outsourcing, cumple con lo definido en el documento de especifi-cación de requerimientos, pero no pueden garantizar al cien por ciento, que el sistema reali-ce lo que cliente realmente espera, sino es el usuario el que realmente evalúa.

Pero no solamente se identificó como la única desventaja que se puede presentar por terce-rizar el proceso de desarrollo, en la Tabla 20. Desventajas , se incluyen problemáticas que pueden afectar el proceso de Validación y verificación de requerimientos, tomados de [15]y [16].

Desventaja Implicación

Es necesario que se gestione la empresa tercera que es responsable de las tareas de desarrollo.

Garantizar el cumplimento y entregas espe-radas.

Existe el riesgo que la empresa de outsour-cing se declare en quiebra o pase por dificul-tades importantes.

Se puede presentar retrasos en los proyec-tos que dependen directamente del desa-rrollo.

La empresa tercera, atendiende a otros clientes, o la empresa que subcontrata no es atendida con la dedicación necesaria.

Implica que los desarrollos o solución a los defectos encontrados en el proceso de vali-dación y verificación de requerimientos no se den en los tiempos esperados, generando retraso en los objetivos de la empresa.

La comunicación no es la esperada, debido que no se expresan inquietudes, dudas o preguntas, que se pueden presentar a lo largo del desarrollo del proyecto.

Los desarrollo esperados no cumplen con la funcionalidad esperada, debido que la em-presa supone muchas de las respuestas.

Dependencia con el proveedor del servicio . Se tiene dependencia de la empresa porque es la que realiza el desarrollo y realizara correcciones, se dependerá de sus tiempos de respuesta para solucionar los problemas que se presenten debido al desarrollo.

Puede perderse el control sobre el producto final y verse afectada la calidad.

Surge, la necesidad de la validación y verifi-cación de los requerimientos para el usuario

Página 33


final.

Se puede afectar la confidencialidad de los productos nuevos y novedosos.

Al tercerizar el desarrollo es la empresa tercera quien materializara la idea, por lo tanto los servicios y productos novedosos dependerán de la confidencialidad que se establezca.

Tabla 20. Desventajas Outsourcing

Validación y verificación de Requerimientos

La validación y verificación de Requerimientos, se puede realizar en dos momentos del pro-yecto de software, antes del desarrollo y luego de su desarrollo, lo que determina la manera como se realizara el proceso.

Cuando se realiza la validación y verificación de requerimientos antes de ser implementado, es un proceso estático, que busca garantizar que cada uno de los artefactos especificados no se presente diferencias, problemas o errores. Por lo tanto permite mejorar el proceso de desarrollo de los requerimientos en cada una de sus etapas anteriores, en la Ilustración 9.Desarrollo de Requerimientos y Validación, se presenta la relación de la validación respecto a las otras etapas.

Ilustración 9. Desarrollo de Requerimientos y Validación

Cuando se realiza la validación y verificación de requerimientos posterior al desarrollo, es dinámico, ya que se realiza sobre un producto y permite evaluar la funcionalidad y compor -

Página 34


tamiento de acuerdo a lo requerido. Este proceso requiere varias etapas y su fundamento son las pruebas de Software.

5.2 GlosarioEn esta sección se presenta la definición de las palabras claves que fueron mencionadas en la propuesta.

D

Corresponde a la diferencia entre la especificación correcta del artefacto y una ver-

sión incorrecta. Es un error que se presenta en el software, que puede ocasionar un evento o situa-

ción no esperado.

I

“Es una disciplina de la ingeniería que comprende todos los aspectos de la produc-

ción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza” [17]

“Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, es decir, la aplicación de la ingería de so-ftware” [11]

“La ingeniería de requerimientos es una disciplina de la ingeniería de software, la cual se refiere a todas las actividades relacionadas con el ciclo de vida de los reque-rimientos de un proyecto” [10].

O

Es el proceso en el cual una empresa, busca externalizar con otra empresa parte o totalmente una actividad

Página 35

Outsourcing

Ingeniería de Software

Ingeniería de Requerimientos

Defecto


También conocido como “subcontratación”, “tercerización”, o “externalización”, por ende, “Es la subcontratación de terceros para hacerse cargo de ciertas activida-des complementarias a la actividad principal”[18], la definición de [19] es: “En In-glés, la palabra "out" significa fuera y "source" significa fuente u origen, es decir, la expresión se refiere a una fuente externa. Por lo tanto, una empresa busca una fuen-te externa que pueda funcionar en un área del negocio de manera más eficiente, obteniendo así más tiempo para centrarse en los aspectos clave de la gestión empre-sarial.”

En el contexto de la guía metodología del trabajo de grado, esta va dirigida a empre -sas que usan los servicios de un tercero para el desarrollo de software. La entrada para el proceso de desarrollo serán los requerimientos previamente definidos.

R

Definición de las características que debe cumplir un sistema, como se menciona en [3]: “Un requerimiento es una característica que debe tener un sistema o una restric -ción que debe satisfacer para que sea aceptado por el cliente.”

En el Swebok, “Un requerimiento de software es una característica que se debe exhi-bir para solucionar un cierto problema del mundo real. La guía se refiere a requeri -mientos de software porque se refiere a los problemas que se tratarán por el softwa -re. Por lo tanto, un requerimiento de software es una característica que se debe exhi-bir por el software desarrollo o adaptado para solucionar un problema en particular” [11]

Los requerimientos definen los lineamientos para el desarrollo de software, por lo tanto, y para el contexto de la guía, corresponden a las definiciones que se deben evaluar y garantizar luego que su desarrollo se ha cumplido.

S

Según [4] “Scrum es un modelo de desarrollo ágil caracterizado por: o Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y

ejecución completa del producto. o Basar la calidad del resultado más en el conocimiento tácito de las personas en

equipos auto organizados, que en la calidad de los procesos empleados.

Página 36

Requerimientos

SCRUM


o Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada”

Son las personas involucradas o interesadas en un proyecto, debido que de una forma u otra, hacen parte del proceso o actividad de estudio.

Es el acrónimo de “Software Engineering Body of Knowledge”, es una guía desarrollada por la IEEE Computer Society, donde se define una base para el cuerpo de conocimiento de la ingeniería de Software, más no el cuerpo. “Constituye un valioso elemento a la infraestructura de la ingeniería del software”[11]

V

La verificación y validación es el nombre que se da a los procesos de comprobación y análisis que se encarga de asegurar que el software que se desarrolla está acorde a la especificación de los requerimientos y cumple las necesidades de los clientes, es un proceso de ciclo de vida completo: Inicia con las revisiones de los requerimientos y continúa con las revisiones del diseño y las inspecciones del código hasta la prueba. [20]

En la Tabla 21. Verificación y Validación se presenta un cuadro comparativo con la defini-ción y diferencia entre Verificación y Validación de Requerimientos

Verificación Validación

“El proceso de evaluación de un sistema o componente para determinar si el sistema de una fase de desarrollo dado satisface las condiciones impuestas al comienzo de esa fase.” (IEEE Std. 610.12-1990)[21]

“El proceso de evaluación de un sistema o componente durante o al final del proceso de desarrollo para determinar si un sistema o un componente cumple los requisitos especificados.” (IEEE 610.12- 1990)[19]

“¿Estamos construyendo el producto co-rrectamente?”

“¿Estamos construyendo el producto co-rrecto?”

El software debería ajustarse a su especifi-cación.

El software debería hacer lo que el cliente realmente reclama.

Comprobar que el software está de acuer-do con su especificación, comprobar si satisface con los requerimientos funciona-

Asegurar que el sistema satisface su especi-ficación para demostrar que el software hace lo que el cliente espera que haga.

Página 37

Validación y Verificación de Requerimientos

STAKEHOLDERS

SWEBOK


les y no funcionales.

Tabla 21. Verificación y Validación

Nombre asignado a la guía metodológica. La letra V junto al número dos, hace referen-cia a la Validación y Verificación de requerimientos, y Soft de Software. Lo que significa: Validación y Verificación de requerimientos de Software.

Página 38

V2Soft


6 Referencias y Bibliografía

6.1 Referencias[1] «El outsourcing, aliado del ahorro en los negocios», Portafolio, p. 1, 22-jul-2013.[2] ISTQB, International Software Testing Qualifications Board, «Glossary Archive - ISTQB®

Glossary of Testing Terms». Erik van Veenendaal (The Netherlands), 19-oct-2012.[3] B. Bruegge y Allen H. Dutoit, Ingeniería de Software orientado a objetos, Primera Edi-

ción., vol. 1. México: Prentice Hall, 2002.[4] Manuel Trigas Gallego, «Gestión de proyectos informáticos. Metodología Scrum». .[5] Juan Palacio, «Gestión de proyectos Scrum Manager. (scrum Manager I y II) V.2.5». 25-

abr-2014.[6] Alexis Labarca C, «LOS MÉTODOS DE INVESTIGACIÓN Aplicados a las Ciencias de la Con-

ducta», Métodos de investigación. [En línea]. Disponible en: http://teologiacultura.file-s.wordpress.com/2007/12/mc3a9todos-de-investigacic3b3n-aplicados-a-la-cs-educaci-c3b3n.pdf. [Accedido: 18-may-2014].

[7] Malhotra, Naresh K, Investigación de mercados un enfoque práctico. México: Prentice Hall, 1997.

[8] G. L. D. Fernádez Collado, G, Investigación y Comunicación. México: McGraw - Hill, 1989.[9] C. W. Aybüke Aurum, Engineering and Managing Software Requirements. Editorial

Springer, 2005.[10] Wiegers K, Software Requirements, Second Edition. Microsoft Press©, 2003.[11] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge

(SWEBOK(R)). 2013.[12] V. C. L. Miguel Eduardo Torres y Laura Catalina Zorro, «Notas de clase - Ingenieria de

Requerimientos». Pontificia Universidad Javeriana, 2011.[13] P. S. ć Marija Rakic ć -Skokovi ć, «Requirements - Based Testing Process in Practice», In-

ternational Journal of Industrial Engineering and Managem ent (IJIEM), vol. Vol 1 No 4, p. PP. 155-161, 24-dic-2013.

[14] Bender RBT Inc, «Requirements Based Testing Process Overview». Bender RBT Inc, 2009.

[15] José Antonio Bohon Devars, «Ventajas y desventajas del outsourcing», 31-jul-2009. [En línea]. Disponible en: http://www.cnnexpansion.com/opinion/2009/07/30/ventajas-y-desventajas-del-outsourcing.

[16] Grupo BN Outsourcing, «Ventajas e inconvenientes del outsourcing». [En línea]. Dispo-nible en: http://www.bnoutsourcing.com/articulos/ventajas-y-desventajas-del-outsour-cing. [Accedido: 26-may-2014].

[17] Sommerville, Ian, Ingeniería de Software, Septima. Mexico: Person Addison Wesley.[18] E- conomic, «Outsourcing | Diccionario de e-conomic», Definición Outsourcing. [En lí-

nea]. Disponible en: http://www.e-conomic.es/programa/glosario/definicion-outsour-cing. [Accedido: 23-may-2014].

[19] «Significado de Outsourcing - Qué es, Concepto y Definición». [En línea]. Disponible en: http://www.significados.info/outsourcing/. [Accedido: 23-may-2014].

Página 39


[20] P. L. José M, Drake, «Verificación y Validación», 2009.[21] IEEE, «IEEE Guide for Developing System Requirements Specifications». IEEE, 12-1998.

6.2 Bibliografía Propuesta para el desarrollo del Trabajo de GradoSe incluyen referencias bibliográfica que apoyara el proceso del trabajo de grado, es impor-tante aclarar que dentro de las primeras actividades se encuentra la búsqueda de bibliogra-fía que soporte el proceso.

Gary E. Mogyorodi, "What Is Requirements-Based Testing?" Cross talk the journal of defence software engineering, march 2003

Gary E. Mogyorodi, B. Math., M.B.A. Requirements - Based Testing - Ambiguity Reviews. Mississauga, Ontario Canada. 2005

Wiegers K, SOFTWARE REQUIREMENTS. Second edition.Microsoft Press©; 2003 Unidad 11. VALIDACION DE REQUISITOS Master de Ingeniería de Software Disponi-

ble en http://is.ls.fi.upm.es/docencia/masterTI/ARS/docs/Manual_M2C1U11.pdf Ian F, Alexander. Richard Stevens. Writing better requirements.Person education. Escalona, Maria Jose. Koch, Nora. Ingenieria de requisitos.Escuela Técnica Superior

de Ingeniería Informática Universidad de Sevilla Matriz de validación de requerimientos. Disponible en : http://

eisc.univalle.edu.co/cursos/.../8-Matriz_ValidacionRequerimientos.pdf Gestión de requisitos Disponible en: http://www.es.sogeti.com/Que-hacemos/Tes-

ting/Gestion-de-requisitos/ http://www.sstc-online.org/proceedings/2003/PDFFiles/pres1137.pdf Peter Zielczynski. Requirements Management using IBM RequisitePro. 2008. Antonio Bucchiarone, Stefania Gnesi, Alessandro Fantechi. An Experience in Using

a Tool for Evaluating a Large Set of Natural Language Requirements. ACM. 2010. Jim Whitehead. Collaboration in Software Engineering: A Roadmap. 2007. IEEE. Jonas Helming, Maximilian Koegel, Helmut Naughton. Towards Traceability from

Project Management to System Models. IEEE. 2009. Andrian Marcus, Xinrong Xie, Denys Poshyvanyk. When and How to Visualize Trace-

ability Links?. ACM. 2005. Carrillo de Gea, J.,M., Nicolas, J., Aleman, J. L. F., Toval, A., Ebert, C., & Vizcaino, A.

(2011). Requirements engineering tools.IEEE Software, 28(4), 86-91. doi:10.1109/MS.2011.81.

Rational. Using Rational RequisitePro® Version 2000.02.10. Christof Ebert. Requirements Engineering Tools. IEEE. 2010. Narciso cerpa, June m. Verner. Why did your Project fail. ACM. 2009. Jim Whitehead. Collaboration in Software Engineering: A Roadmap. IEEE. 2007. Luqi, Robert Steigerwald, Gary Hughes, Valdis Berzins. Caps as a requirements engi-

neering tool. ACM. 1991.

Página 40


Raimundas Matuleviius. Prototype of the Evaluation Framework for Functional Re-quirements of RE-tools- 2005. IEEE.

Matthias Heindl, Franz Reinisch,Stefan Biffl,Alex Egyed. Value-Based Selection of Requirements Engineering Tool Support. 2006. IEEE.

Vanessa Loaiza, Laura Zorro, Miguel Torres. Notas de Clase – Ingeniería de Requeri-mientos. 2011.

Castro, C.; Cleland-Huang, J.; Utilizing recommender systems to support software requirements elicitation. In Proceedings of the 2nd International Workshop on rec-ommendation Systems for Software Engineering (RSSE '10). ACM. 2010.

Using Rational RequisitePro. Rational Software Corporation. 2000. Marnewick, A.; Pretorius, J.-H.; Pretorius, L.; , "A perspective on human factors

contributing to quality requirements: A cross-case analysis," IEEE. vol., no., pp.389-393. 2011.

Azlena Haron, A.H.; Sahibuddin, S.; , "The roles of an actor in requirement engineer -ing (RE) process,". IEEE International Conference on, vol.1, no., pp.436-440, 9-11. 2010.

Gruenbacher P., “Integrating Groupware and CASE Capabilities For Improving Stakeholder Involvement in Requirements Engineering”, euromicro, p. 2232, Pro-ceedings of The 26th EUROMICRO Conference (EUROMICRO'00)-Volume 2, 2000.

Mishra, D.; Mishra, A.; Yazici, A.;, "Successful requirement elicitation by combining requirement engineering techniques," Applications of Digital Information and Web Technologies, 2008. ICADIWT 2008. First International Conference on the , vol., no., pp.258-263, 4-6 Aug. 2008

Elizabeth Hull, Ken Jackson, Jeremy Dick. Requirements Engineering. 2011. Sprin-ger.

Ian Alexander, Ljerka Beus-Dukic. Discovering Requirements. 2009. Wiley. Ralph R. Young. The Requirements Engineering Handbook. 2003. Artech House.

Peter Zielczynski. Requirements Management Using IBM Rational RequisitePro. 2008. IBM Press.

Vale, L.; Albuquerque, A.B.; Beserra, P.V.; , "The Importance of Professional Quality of Requirements Analysts for Success of Software Development Projects: A Study to Identify the Most Relevant Skills," IEEE. pp.253-262, 28-30. 2011

Ruzanna Chitchyan,Américo Sampaio,Awais Rashid, Paul Rayson. A Tool Suite for Aspect-Oriented Requirements Engineering. 2006. IEEE.

David Bolton, Sara Jones and David Till, City University David Furber and Stewart Green, King’s College London. A Generic Modelling Ap-

proach to Requirements Capture in the Domain of Air Traffic Control. Martin Sarabura, Paul Bowden. Solving Requirements Management Challenges in

Product Line Development. 2008. IEEE. Huzam S. F. Al-Subaie, Tom S. E. Maibaum. Evaluating the Effectiveness of a Goal-

Oriented Requirements Engineering Method. 2006. IEEE. Daniel Le M6tayer. Program analysis for software engineering new applications,

new requirements, new tools.

Página 41


Michael Breen. Statestep: A Tool for Systematic, Incremental Specification. 2004. IEEE.

Juan M. Carrillo de Gea, Joaquín Nicolás, José L. Fernández Alemán, Ambrosio To-val, Christof Ebert, and Aurora Vizcaíno. Requirements Engineering Tools. 2010. IEEE.

Norbert Seyff, Paul Grünbacher, Neil Maiden, Amit Tosar. Requirements Engineer-ing Tools Go Mobile. 2004. IEEE.

Isabelle Cˆot´e and Maritta Heisel. A UML Profile and Tool Support for Evolutionary Requirements Engineering. 2011. IEEE.

Página 42


7 Anexos

En la Ilustración 10. Metodología SCRUM. Tomado de [3], se presenta la metodología SCRUM

Ilustración 10. Metodología SCRUM. Tomado de [3]

Página 43

Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1430IS08/docs/propuestaTG.docx · Web...

Documents

Transcript of Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1430IS08/docs/propuestaTG.docx · Web...