MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez...

67
MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO ARTEFACTOS CON CALIDAD TESIS PARA OBTENER EL TÍTULO DE INGENIERA EN SISTEMAS COMPUTACIONALES PRESENTA: MARÍA CORTEZ SORIANO DIRECTOR DE TESIS: DR. CÉSAR ARTURO GUERRA GARCÍA ENERO 2019 UNIVERSIDAD AUTÓNOMA DE SAN LUIS POTOSÍ COORDINACIÓN ACADÉMICA REGIÓN ALTIPLANO OESTE

Transcript of MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez...

Page 1: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

MEJORA DE PROCESOS DE SOFTWARE

CONSIDERANDO ARTEFACTOS CON CALIDAD

TESIS PARA OBTENER EL TÍTULO DE

INGENIERA EN SISTEMAS COMPUTACIONALES

PRESENTA:

MARÍA CORTEZ SORIANO

DIRECTOR DE TESIS:

DR. CÉSAR ARTURO GUERRA GARCÍA

ENERO 2019

UNIVERSIDAD AUTÓNOMA DE SAN LUIS POTOSÍ

COORDINACIÓN ACADÉMICA REGIÓN ALTIPLANO OESTE

Page 2: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

2

Page 3: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

3

ÍNDICE

Agradecimiento ............................................................................................................................. 6

Resumen ........................................................................................................................................ 7

I. Introducción ............................................................................................................................... 8

1.1 IMPORTANCIA ..................................................................................................................................................... 8

1.2 PROBLEMÁTICA ................................................................................................................................................... 8

1.3 PROPUESTA DE SOLUCIÓN .................................................................................................................................. 9

II. Áreas Relacionadas: Estándar ISO/IEC 29110 y Calidad de Datos .......................................... 11

2.1 ISO/IEC 29110 .................................................................................................................................................... 11

2.2 CALIDAD DE DATOS ........................................................................................................................................... 14

III. Modelo de Calidad de Datos en Procesos de Desarrollo de Software ................................... 18

IV. Aplicación del Modelo a un Caso de Estudio ......................................................................... 26

4.1 ARTEFACTOS DEL CASO DE ESTUDIO ................................................................................................................. 26

4.2 METADATOS DE LOS ARTEFACTOS DEL CASO DE ESTUDIO ............................................................................... 32

V. Conclusiones y Trabajo a Futuro ............................................................................................. 41

VI. Referencias ............................................................................................................................. 42

Anexo A ....................................................................................................................................... 43

Anexo B ....................................................................................................................................... 43

Page 4: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

4

ÍNDICE DE FIGURAS

Figura 1. Estándares utilizados para la mejora. ............................................................................ 8

Figura 2. Estándares en los cuales se basa la norma ISO/IEC 29110 .......................................... 11

Figura 3. Estructura de la norma ISO 29110 [15] ........................................................................ 13

Figura 4. Procesos de la guías del perfil básico [19]. ................................................................... 14

Figura 5. Características/dimensiones definidas en el estándar 25012 [18]. ............................. 15

Figura 6. Ejemplo de calidad de datos ........................................................................................ 17

Page 5: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

5

ÍNDICE DE TABLAS Tabla 1. Partes identificadas en la norma ISO/IEC 29110 [14]. ................................................... 12

Tabla 2. Características o dimensiones inherentes al sistema [18]. ........................................... 16

Tabla 3. Características o dimensiones dependientes del sistema [18]. .................................... 16

Tabla 4. Tabla de contenido de un Paquete de Despliegue [10]. ............................................... 19

Tabla 5. Paquete de Despliegue 4: Gestión de proyecto, Perfil Básico (PD4). ............................ 20

Tabla 6. Paquete de Despliegue 6: Entrega del producto, Perfil Básico (PD6). ......................... 20

Tabla 7. Paquete de Despliegue 7: Análisis de requerimientos del software, Perfil Básico (PD7).

..................................................................................................................................................... 20

Tabla 8. Dimensiones aplicables a los artefactos de los Paquetes de Despliegue. .................... 21

Tabla 9. Dimensiones de calidad de datos aplicadas a los artefactos de los PD. ........................ 23

Tabla 10. Conjunto de metadatos comunes para los PD seleccionados. .................................... 24

Tabla 11. Descripción del proyecto de software solicitado por la empresa ACME. ................... 26

Tabla 12. Artefacto del PD4- Plan de proyecto ........................................................................... 27

Tabla 13. Artefacto del PD4- Estructura de Desglose de Trabajo (EDT) ..................................... 28

Tabla 14. Artefacto del PD4- Informe de reuniones-Ejemplo de contenidos. ............................ 28

Tabla 15. Artefacto del PD6- Formulario de instrucciones de entrega ....................................... 30

Tabla 16. Artefacto del PD6- Formulario de acta de aceptación ................................................ 31

Tabla 17. Artefacto del PD7- Escenario de atributo de calidad .................................................. 32

Tabla 18. Artefacto del PD7- Documento de requerimientos .................................................... 32

Tabla 19. Metadatos plan de proyecto ....................................................................................... 33

Tabla 20. Dimensiones aplicables a los metadatos del plan de proyecto ................................... 33

Tabla 21. Metadatos EDT ............................................................................................................ 34

Tabla 22. Dimensiones aplicables a los metadatos del EDT ........................................................ 34

Tabla 23. Metadatos solicitud de cambio ................................................................................... 35

Tabla 24. Dimensiones aplicables a los metadatos de la solicitud de cambio ............................ 35

Tabla 25. Metadatos informe de reuniones ................................................................................ 36

Tabla 26. Dimensiones aplicables a los metadatos del informe de reuniones ........................... 36

Tabla 27. Metadatos formulario de instrucciones de entrega .................................................... 37

Tabla 28. Dimensiones aplicables a los metadatos del formulario de instrucciones de entrega 37

Tabla 29. Metadatos formulario de acta de aceptación ............................................................. 38

Tabla 30. Dimensiones aplicables a los metadatos del formulario de acta de aceptación ........ 38

Tabla 31. Metadatos de escenarios de atributos de calidad ...................................................... 39

Tabla 32. Dimensiones aplicables a los metadatos de los escenarios de atributos de calidad .. 39

Tabla 33. Metadatos documento de requerimientos ................................................................. 40

Tabla 34. Dimensiones aplicables a los metadatos del documento de requerimientos ............ 40

Page 6: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

6

Agradecimiento

Si puedes soñarlo, puedes lograrlo.

Walt Disney

Tiempo atrás, titularme de la Universidad era un sueño que pensé no lograría. Sin embargo,

después de una decisión precipitada, de un camino lleno de esfuerzo y dedicación y del apoyo

de muchas personas valiosas, ese sueño se convierte en realidad dejando en mi memoria

además de conocimientos, un sinfín de experiencias que forman parte importante de una de las

mejores etapas de mi vida.

Durante esta etapa, fueron muchas las personas que contribuyeron conmigo para la conclusión

de esta meta. En primer lugar, quiero agradecer a mi familia, a mis padres, Francisco y María por

aconsejarme, confiar y creer en mi cuando ni yo misma lo hacía, a mis hermanas y hermanos

por apoyarme en cada paso; gracias por no dejarme sola a pesar de los errores y faltas que

cometí.

Agradezco también a mis profesores, quienes a lo largo de la carrera nos brindaron no solo sus

conocimientos sino también sus valores. Gracias por aclarar las dudas y otras veces dejarme con

más cuestionamientos, ya que me sirvió para poner a prueba mis capacidades de búsqueda y

entendimiento.

El desarrollo de esta tesis no lo puedo catalogar como algo fácil, pero lo que sí puedo hacer, es

afirmar que sin la guía de mi asesor el Dr. César Arturo Guerra la realización de este trabajo me

hubiera costado muchas horas de desvelo. Le agradezco por la paciencia, las aclaraciones, los

consejos y sobre todo por confiar en que podía lograrlo satisfactoriamente.

Y no podía dejar de lado a mis compañeros y amigos de cursos, quienes desde el inicio de esta

etapa y a pesar de la diferencia de edad me brindaron su apoyo, no solo académico sino

personal, muchas gracias por hacer mi etapa estudiantil más fácil y muchas veces divertida;

ustedes fueron los protagonistas de muchas de las mejores experiencias que pase, varias veces

caímos y nos levantamos juntos a pesar de las diferencias, por esa razón a todos y cada uno les

agradezco la aceptación de mi persona en sus vidas.

A todas las personas mencionadas anteriormente, gracias por contribuir con su granito de arena

a lo largo de la realización de este sueño.

Page 7: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

7

Resumen Las pequeñas organizaciones (PO) dedicadas al desarrollo de software se han convertido en una

pieza muy importante en la economía mundial, ya que sus aportes pueden ser utilizados por

sistemas más grandes y complejos, sin embargo, este tipo de organizaciones no son reconocidas

como entidades que producen software de calidad. Debido a esto, las PO desean mejorar sus

procesos de software utilizando prácticas eficientes de Ingeniería de Software adaptadas a su

tamaño. La Organización Internacional para la Estandarización (ISO) creó un grupo de trabajo,

que en 2010 presentó el estándar ISO/IEC 29110, constituido por un conjunto de guías y buenas

prácticas que se ajustan a las características y necesidades de las PO. La ISO/IEC 29110 parte 5

provee una serie de paquetes de despliegue, los cuales son un conjunto de artefactos que

facilitan la implementación de los procesos en las PO, sin embargo, no garantizan la calidad en

los datos de los artefactos utilizados en los procesos de desarrollo del software, por lo tanto, en

el presente trabajo se propone un modelo de calidad de datos basado en la norma ISO/IEC

25012, que pueda ser usado en los artefactos que se utilizan durante los procesos de la ISO/IEC

29110 involucrados en el desarrollo de software en PO. Se pretende que el modelo propuesto

permita incrementar la capacidad y calidad de los procesos de desarrollo software y, como

consecuencia, la calidad de los productos y/o servicios que ofrecen, acercándolas a competir

con empresas de mayor nivel.

Page 8: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

8

I. Introducción

1.1 IMPORTANCIA En la actualidad la industria del software en diversos países, reconoce el valor de las

aportaciones de productos y servicios que brindan las Pequeñas Organizaciones (PO), ya que

también pueden desarrollar y mantener software que se utilizan en sistemas más grandes y

complejos, por lo cual, a lo largo de todo el mundo se ha vuelto de gran interés, debido a que

ahora la industria del software constituye uno de los pilares de la economía en varios países al

tener el potencial de generar efectos significativos sobre otras industrias, a través de las mejoras

que puede provocar la utilización de software que agilicen alguno de sus procesos [1].

Una pequeña organización está definida como aquella entidad (empresa, organización,

departamento o proyecto) con 25 o menos personas, sin embargo, al ser pequeña no deja de

ser considerada de importancia, ya que al desarrollar software que es utilizado por sistemas

mayores, se considera un proveedor importante, que contribuye al crecimiento económico de

cada país [2].

De acuerdo con la Organization for Economic Co-operation and Development (OECD) en su

reporte “Pequeñas y Medianas Empresas y Perspectiva Empresarial (2005)”, las Pequeñas y

Medianas Empresas constituyen el tipo de organización de negocio dominante en el mundo,

contabilizando por encima del 95% del total de los negocios dependiendo del país. El reto para

los gobiernos que conforman el OECD es proveer un ambiente de competitividad entre esta gran

cantidad de negocios.

1.2 PROBLEMÁTICA Según encuestas y estudios como los que se mencionan en [3], se muestra que las pequeñas

organizaciones desean mejorar sus procesos de software incrementando la capacidad y calidad

de sus procesos y, como consecuencia la calidad de sus productos y/o servicios. En el mismo

estudio se evidencía que éstas se encuentran utilizando estándares de organizaciones como el

Software Engineering Institute (SEI) y el International Standard for Standarization (ISO) para

tratar de mejorar sus procesos, todos los utilizados son mostrados en la Figura 1.

Figura 1. Estándares utilizados para la mejora.

Page 9: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

9

Sin embargo, es claro que la mayoría de los estándares internacionales no se ajustan a sus

necesidades, debido a que requieren de una gran inversión en presupuesto, tiempo y recursos

que las PO no tienen, ya que dichos estándares están dirigidos a las grandes organizaciones.

Como consecuencia las PO tienen muy limitada la forma de ser reconocidas como entidades que

producen software de calidad. Por lo tanto, son aisladas en algunas actividades económicas;

además de que para la construcción de sus productos, requieren prácticas eficientes de

Ingeniería de Software adaptado a su tamaño.

Para corregir esas dificultades, la Organización Internacional para la Estandarización (ISO)

constituyó el grupo de trabajo SC7-WG24, el cual tiene como objetivo adaptar estándares para

que puedan ser utilizados en PO desarrolladoras de software [4].

En 2010, este grupo presentó un conjunto de guías que se ajustan a las características de las PO,

las cuales fueron presentadas en el estándar ISO/IEC 29110 [5], estableciendo un marco común

para describir perfiles evaluables del ciclo de vida de software basados en estándares

internacionales, ya que resalta las prácticas de la ISO/IEC 12207 [6] y procesos de la ISO/IEC

15289 [7], sin excluir diferentes metodologías del ciclo de vida como lo son: cascada, iterativo,

incremental, evolutivo o ágil; los perfiles especificados en la ISO/IEC 29110 permiten mejorar la

calidad del producto y/o servicio así como el desempeño de la organización; sin embargo, la

utilización del estándar no garantiza la calidad de los datos que se manipulan en los artefactos

utilizados durante los procesos de desarrollo de software.

Aunque existe una variedad de trabajos como [8] y [9] orientados a la mejora de procesos de

desarrollo de software, ninguno se enfoca a evaluar o gestionar la calidad de datos de los

artefactos mencionados dentro de la norma ISO/IEC 29110 para PO; después de una búsqueda

exhaustiva de material semejante para la realización de este trabajo de investigación y

obteniendo resultados negativos, se llegó a la conclusión de que hasta el momento no se ha

presentado ninguna propuesta que considere la calidad de datos en los artefactos utilizados en

los procesos, descritos en la norma ISO/IEC 29110.

1.3 PROPUESTA DE SOLUCIÓN En la actualidad, es fundamental que las empresas de desarrollo de software mantengan un

nivel aceptable de calidad en procesos y productos/servicios; para que las PO puedan alcanzar

este nivel, la ISO/IEC 29110 parte 5 [10], provee una serie de paquetes de despliegue, los cuales

buscan que las PO concluyan exitosamente un proyecto de desarrollo de software, siguiendo

una colección de mejores prácticas que las conducirá a cumplir con estándares de calidad

adecuados y, por lo tanto, las acerca a competir con empresas de mayor nivel.

Los paquetes de despliegue son un conjunto de artefactos que facilitan la implementación de

los procesos en las PO; los datos son la parte más importante de los artefactos, ya que a través

de la manipulación de los mismos, se genera información de valor para los procesos siguientes

así como para el cliente/empresa.

Muchas veces no se da la suficiente importancia a los datos que son utilizados en las

organizaciones, no solo en las desarrolladoras de software sino también en aquellas

Page 10: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

10

pertenecientes a otras áreas de la industria, y este hecho podría pasar desapercibido; sin

embargo, es uno de los problemas a los que se enfrenta la mayoría de las empresas, ya que la

falta de calidad en los datos que son utilizados en cada uno de los procesos que se siguen para

la gestión de un proyecto genera un impacto negativo, ya que al no contar con datos fiables se

suelen cometer errores que afectan tanto el desempeño como la imagen de la empresa.

Por tal razón, el objetivo del presente trabajo, es proponer un modelo de calidad de datos

basado en las características de calidad del estándar ISO/IEC 25012, el cual puede ser usado en

los artefactos que se utilizan durante los procesos de la ISO/IEC 29110 involucrados con el

desarrollo de software en PO, dicho modelo no solo mejorará la calidad de los datos usados en

los artefactos, sino también por consecuencia, la de los productos/servicios.

En el siguiente capítulo se describen con más claridad las principales áreas involucradas con la

propuesta del trabajo como los son los estándares ISO/IEC 25012 e ISO/IEC 29110.

Page 11: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

11

II. Áreas Relacionadas: Estándar ISO/IEC 29110 y Calidad de

Datos

2.1 ISO/IEC 29110 Como se mencionó anteriormente, la norma ISO/IEC 29110 presenta un conjunto de guías

que establecen un marco común para describir perfiles evaluables del ciclo de vida del

software para PO. Los perfiles evaluables son 4 y en conjunto forman el grupo de perfiles

genérico [5]:

Perfil de entrada/inicial: Dirigido a PO que desarrollan proyectos de tamaño menor

a 6 personas-meses.

Perfil básico: Dirigido a PO que desarrollan un solo proyecto por un equipo de

trabajo, y sin ningún riesgo.

Perfil intermedio: Dirigido a PO que desarrollan múltiples proyectos.

Perfil avanzado: Dirigido a PO que desean mantenerse y crecer como empresas

desarrolladoras de software independientes y competitivas.

Un perfil es un conjunto de procesos compuesto por partes de normas ISO y cuyo propósito

es precisamente adaptar y adecuar esos estándares a las necesidades de las PO. La norma

ISO/IEC 29110 fue creada para mejorar la calidad en el desarrollo y mantenimiento de

software en pequeñas empresas, basado en una combinación de estándares reconocidos a

nivel mundial (ver Figura 2).

Figura 2. Estándares en los cuales se basa la norma ISO/IEC 29110

Esta combinación reúne las mejores prácticas de cada estándar adaptándolas a las necesidades

de las PO:

Norma Mexicana MoProSoft: Modelo para el desarrollo de software que está enfocado

en procesos considerando la estructura básica de la empresa, distingue tres niveles de

organización: Alta Dirección, Gerencia y Operación [11].

ISO/IEC 15289: Especifica el propósito y contenido del ciclo de vida del software, así

como el de la información de la gestión de algún servicio (documentación) [7].

Page 12: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

12

ISO/IEC 15504: Proporciona una base para realizar evaluaciones de la capacidad de los

procesos de software y refleja los resultados en una escala común [12].

ISO/IEC 12207: Es un marco de referencia que contiene los procesos, actividades y

tareas involucrados en el desarrollo de un producto software, abarcando desde la

definición de requisitos hasta que el sistema se deja de utilizar [6].

Metodologías: Estructuras o modelos en las cuales se define una relación de todas las

actividades tanto con los procesos como entre si [13].

La norma ISO/IEC 29110 se divide en 5 partes de acuerdo al tipo de audiencia al que está

dirigida, es decir, al campo de aplicación de cada una conformando el marco de trabajo que

se muestra en la Tabla 1:

ISO/IEC 29110 Título Audiencia Parte 1 Visión general Empresas, evaluadores,

desarrolladores, consultores, etc.

Parte 2 Marco de referencia y taxonomía

Normalizadores, desarrolladores, consultores. No es para las empresas.

Parte 3 Guía de evaluación Evaluadores y empresas

Parte 4 Especificación de los perfiles Normalizadores, desarrolladores, consultores. No es para las empresas.

Parte 5 Guía de Gestión e Ingeniería Empresas. Tabla 1. Partes identificadas en la norma ISO/IEC 29110 [14].

En cada parte de la norma ISO/IEC 29110 se presentan documentos que proporcionan

información para la implementación de los perfiles definidos.

La ISO/IEC 29110-1, introduce los conceptos de procesos, ciclo de vida y normalización, para la

serie ISO/IEC 29110. Asimismo, presenta las características y requisitos de una PO y aclara los

fundamentos para los perfiles, documentos, estándares y guías de una PO específica.

La ISO/IEC 29110-2, introduce los conceptos para el perfil normalizado de Ingeniería de Software

para las PO, y define los términos comunes para el Conjunto de documentos del Perfil de las PO.

Especifica también los elementos comunes para todos los perfiles (estructura, conformidad,

evaluación) e introduce la taxonomía (catálogo) de perfiles de la ISO/IEC 29110.

La ISO/IEC 29110-3 define los lineamientos y requisitos para la evaluación de procesos,

necesarios para alcanzar los propósitos definidos en los perfiles de la PO. También contiene

información que puede ser útil para desarrolladores de métodos y herramientas de evaluación.

Esta dirigida a personas que tienen relación con el proceso de evaluación, por ejemplo, el

evaluador y el patrocinador de la evaluación, quienes necesitan orientación en el aseguramiento

de que los requisitos para realizar una evaluación han sido alcanzados.

Page 13: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

13

La ISO/IEC 29110-4, para cada perfil hay un documento de especificación de perfiles,

identificado como 29110-4-X, donde la X es el número asignado al perfil. Su propósito es

proporcionar la composición específica para todos los perfiles del Grupo de Perfiles Genérico,

los cuales son aplicables a las PO. El documento 29110-4-1 “Especificación. Perfil Básico PMI” es

un ejemplo de una especificación de perfil que tiene como propósito definir una guía de gestión

de proyectos y desarrollo de software [4]. Estos perfiles se aplican y están dirigidos a

autores/proveedores de: guías, herramientas y otro material de apoyo.

La ISO/IEC 29110-5 provee una guía de implementación sobre Gestión e Ingeniería para cada

perfil del Grupo del Perfil Genérico; y al igual que en la parte 4, cuenta con un documento 29110-

5-1 “Guía de Gestión e Ingeniería. Perfil Básico” que es un ejemplo basado en el perfil de la

ISO/IEC 29110 Parte 4-1. El Perfil Básico describe el desarrollo de software de una sola aplicación

por un solo equipo de proyecto, sin ningún riesgo especial o factores situacionales.

Si un nuevo perfil es necesario, la ISO/IEC 29110 parte 4 y 5 pueden ser desarrolladas sin afectar

a los documentos ya existentes, y se denominarían ISO/IEC 29110 parte 4-m y parte 5-m-n

respectivamente, a través de los procesos del ISO/IEC 29110.

En la Figura 3 se describe la serie ISO/IEC 29110 según el tipo de documento con el cual fueron

presentados, de igual forma posiciona las partes en el marco de trabajo de referencia según la

audiencia descrita previamente. La visión general y las guías fueron publicadas como Reportes

Técnicos (RT) y los perfiles como Estándares Internacionales (EI).

Figura 3. Estructura de la norma ISO 29110 [15].

Page 14: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

14

Los documentos que componen el estándar son los siguientes:

Visión General (29110-1): En este informe se incluyen los conceptos principales,

necesarios para comprender y utilizar los documentos de ISO/IEC 29110.

Perfiles de la ISO 29110: Los perfiles se definen con el propósito de empaquetar

referencias y/o partes de otros documentos de manera formal, con el fin de ajustarlos

a las necesidades y características de las PO.

- Marco de referencia y taxonomía (EI 29110-2).

- Especificaciones de perfil (IE 29110-4).

Guías de la ISO 29110: Las guías contienen las directrices de aplicación sobre cómo

realizar los procesos para alcanzar los niveles de madurez (por ejemplo: tareas

recomendadas, medidas, técnicas, plantillas, modelos y métodos, entre otros). Se

desarrollan para la implantación de los procesos y para la evaluación.

- Guías de evaluación (RT 29110-3).

- Guías de gestión e ingeniería (29110-5).

La ISO/IEC 29110-5 es la parte más importante para las PO, ya que en ésta se proveen las guías

para los procesos de Gestión del Proyecto (GP) e Implementación de Software (IS) para el Perfil

Básico del Grupo del Perfil Genérico especificado en la ISO/IEC 29110 Parte 4-1, en ellas se

describen una serie de actividades y tareas, así como un conjunto de documentos que se deben

producir durante el desarrollo de software. En la Figura 4 se puede apreciar cómo los procesos

de GP e IS están relacionados entre sí.

Figura 4. Procesos de la guías del perfil básico [19].

2.2 CALIDAD DE DATOS En la actualidad no hay una definición precisa sobre calidad de datos, ya que ésta no solo

depende de sus características, sino también del entorno en el que se utilizan los datos, los

procesos y usuarios [16].

Por lo tanto, en general los datos se consideran de calidad si satisfacen los requisitos para su uso

previsto, ya sea en operaciones, toma de decisiones o procesos. La calidad de los datos es un

factor clave, ya que el acierto de las decisiones que toma una organización depende en gran

medida de la calidad de la información en que dichas decisiones se basan. Son precisamente

estas características/dimensiones las que se encuentran reflejadas en el modelo de Calidad de

Page 15: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

15

Datos definido por el estándar ISO/IEC 25012 [17] que se encuentra compuesto por 15

características (ver Figura 5).

Figura 5. Características/dimensiones definidas en el estándar 25012 [18].

Las características de Calidad de Datos están clasificadas en dos grandes categorías:

Calidad de Datos Inherente: Se refiere al grado en el cual las características de calidad

de datos que tienen el potencial intrínseco para satisfacer las necesidades establecidas

cuando los datos son utilizados bajo condiciones específicas. Es decir, el grado en el que

los valores de los datos pertenecen a un dominio especifico, cumplen con alguna

restricción y respetan la relación entre los datos. Estas características se muestran en la

Tabla 2.

Calidad de Datos Dependiente del Sistema: Las dimensiones mostradas en la Tabla 3 se

refieren al grado con el que la calidad de datos es alcanzada y preservada a través de un

sistema computacional cuando los datos son utilizados bajo condiciones específicas. La

calidad de datos depende del dominio tecnológico en el que los datos se utilizan, y se

alcanza mediante las capacidades de los componentes del sistema computacional tales

como: dispositivos hardware (respaldo software para alcanzar la recuperabilidad) y otro

software (herramientas de migración para alcanzar la portabilidad).

Page 16: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

16

Dimensión Descripción

Exactitud Los datos tienen atributos que representan correctamente el verdadero valor

del atributo deseado de un concepto o evento en un contexto especificado.

Completitud Los datos asociados con una entidad tienen valores para todos los atributos

necesarios para la representación de la entidad.

Consistencia Los datos están libres de contradicción y son coherentes con el resto de datos

de su contexto de uso determinado.

Credibilidad Los datos tienen atributos que se consideran ciertos y creíbles para los

usuarios.

Actualidad Los datos tienen atributos con valores actualmente válidos para usos

determinados.

Tabla 2. Características o dimensiones inherentes al sistema [18].

Dimensión Descripción

Accesibilidad Los datos pueden ser accedidos para usos específicos por personal designado.

Conformidad Los datos tienen que adherirse a los estándares referentes a la calidad de datos

en un contexto de uso específico.

Confidencialidad Los datos tienen atributos que aseguran que éstos son sólo accedidos por

personal autorizado; es un aspecto de la seguridad de la información.

Eficiencia Los datos tienen atributos que pueden ser procesados y proporcionados con

los niveles de rendimiento esperados.

Precisión Los datos tienen atributos que son correctos o proporcionan discernimiento

en un contexto de uso específico.

Trazabilidad Los datos tienen atributos que proporcionan un camino de acceso auditado a

ellos, o a cualquier otro cambio realizado sobre los mismos.

Comprensibilidad Los datos tienen atributos que permiten ser interpretados por otros usuarios

y/o lenguajes de uso específico, cierta información puede ser expresada

mediante metadatos.

Disponibilidad Los datos tienen atributos que permiten ser obtenidos por usuarios

autorizados.

Portabilidad Los datos tienen atributos que permiten ser movidos de un sistema a otro,

preservando el nivel de calidad.

Recuperabilidad Los datos tienen atributos que les permiten mantener y preservar un nivel

específico de operatividad y calidad, incluso si hay fallas en el sistema.

Tabla 3. Características o dimensiones dependientes del sistema [18].

En la Figura 6 se ejemplifica la importancia que tiene la calidad de datos hoy en día; el ejemplo

muestra la funcionalidad “Login” que podría pertenecer a cualquier aplicación, aquí se puede

observar que los datos introducidos tanto para el “user” como para el “password” deberán

satisfacer las dimensiones de calidad Exactitud y Completitud, ya que si por error el usuario

introduce un carácter equivocado, el sistema no permitirá su acceso.

Page 17: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

17

Figura 6. Ejemplo de calidad de datos

Page 18: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

18

III. Modelo de Calidad de Datos en Procesos de Desarrollo de

Software

Como se mencionó en la sección 2.1, el propósito del proceso de Gestión del Proyecto es realizar

de manera ordenada todas las tareas del proyecto de implementación del software, las cuales

permiten cumplir con los objetivos del proyecto en calidad, tiempo y forma. Una de las

condiciones para cumplir con las tareas del proyecto es tener el Enunciado del Trabajo del

proyecto (EDT) establecido, y con fechas lo más aproximadas para la realización de las diferentes

actividades.

El propósito del proceso de Implementación del Software (IS) es realizar de manera ordenada

las actividades de análisis, diseño, construcción, integración y pruebas para productos software

nuevos o con modificaciones.

Con la finalidad de facilitar la implementación de las guías proporcionadas en la norma ISO/IEC

29110-5 para las PO, se puso a disposición un conjunto de Paquetes de Despliegue o

Implementación (PD). Un Paquete de Despliegue es un conjunto de artefactos desarrollados

para facilitar la implementación de un conjunto de prácticas, de las seleccionadas del marco de

trabajo de una PO.

Un Paquete de Despliegue (PD) no se debe confundir con un modelo referencial a seguir, ya que

son solo un conjunto de buenas prácticas probadas y que son sugeridas para la realización de un

proyecto de desarrollo de software de manera eficiente, y que cumpla con los estándares de

calidad.

Los elementos que típicamente contiene un Paquete de Despliegue se pueden observar en la

Tabla 4.

El elemento de “Referencias a otros estándares y modelos” es sólo presentado con fines

informativos para mostrar que un Paquete de Despliegue tiene vínculos explícitos a la Parte 5

de la ISO/IEC 29110, con estándares ISO, tal como ISO/IEC 12207 o con el Modelo de Madurez

de la Capacidad del Software Integrado (CMMI por sus siglas en inglés), desarrollado por el

Software Engineering Institute (SEI).

Los Paquetes de Despliegue están diseñados para que una PO pueda implementar su contenido,

sin tener que aplicar el marco completo al mismo tiempo [10].

Page 19: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

19

1. Descripción técnica

Propósito del documento

¿Por qué éste tema es importante? 2. Definiciones clave 3. Relaciones con la ISO/IEC 29110 4. Visión general de los procesos, actividades, tareas, roles y productos 5. Descripción de los procesos, actividades, tareas, pasos, roles y productos

Descripción de roles

Descripción técnica

Descripción de artefactos 6. Plantilla(s) 7. Ejemplo(s) 8. Lista(s) de comprobación 9. Herramienta(s) 10. Referencias a otros estándares y modelos (por ejemplo ISO 9001, ISO/IEC 12207, CMMI) 11. Referencias 12. Forma de evaluación.

Tabla 4. Tabla de contenido de un Paquete de Despliegue [10].

Para el Perfil Básico de una PO, se encuentran disponibles un conjunto de Paquetes de

Implementación:

1.- Construcción y Pruebas Unitarias

2.- Verificación y Validación

3.- Integración y Pruebas

4.- Gestión del Proyecto

5.- Arquitectura y Diseño Detallado

6.- Entrega del Producto

7.- Análisis de Requisitos

8.- Control de Versiones

9.- Autoevaluación

La propuesta de este trabajo es un modelo de calidad de datos basado en las características de

calidad del estándar ISO/IEC 25012, el cual puede ser usado por el personal designado para el

desarrollo de software, para mejorar la calidad de los datos gestionados en los artefactos de los

Paquetes de Despliegue utilizados durante los procesos de la ISO/IEC 29110. Así mismo, será de

ayuda para que las PO puedan mejorar no solo la calidad de sus procesos, sino también la calidad

de la información que se genera en ellos y como consecuencia se brindará un producto/servicio

software de alta calidad, que las acercará a competir con empresas de mayor tamaño.

Para cada PD se utilizan diferentes artefactos para la realización de los procesos, éstos a su vez

serán presentados como productos de entrada y/o salida de otros procesos. En esta propuesta

se trabajará únicamente con los paquetes de despliegue de Gestión del Proyecto, Entrega del

Producto y Análisis de Requisitos, debido a que se considera que dentro de las guías de Gestión

del Proyecto (GP) e Implementación de Software (IS) son los que cuentan o pueden producir un

mayor número de artefactos en los cuales se podrá poner a prueba el modelo de calidad de

datos presentado en este trabajo. En las Tablas 5, 6 y 7 se muestran los artefactos requeridos

en los procesos/actividades de los Paquetes de Despliegue seleccionados.

Page 20: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

20

Proceso Artefactos Planificación del Proyecto -Plan de proyecto

-Descripción del proyecto

Ejecución del Plan del Proyecto -Registro del estado del proyecto

-Solicitudes de cambio

Evaluación y Control del Proyecto -Plan de proyecto

-Solicitudes de cambio

Cierre del Proyecto -Plan del proyecto

-Software

-Acta de aceptación

Tabla 5. Paquete de Despliegue 4: Gestión de proyecto, Perfil Básico (PD4).

Proceso Artefactos Gestión de Proyecto (GP),

Actividad GP 1 Planificación del Proyecto

-Enunciado del Trabajo (EDT)

-Plan de proyecto

-Formulario de instrucciones de entrega

-Formulario de acta de aceptación

Gestión de Proyecto (GP),

Actividad GP 4 Cierre De proyecto

-Configuración del software

-Formulario de Instrucciones de entrega

-Formulario de acta de aceptación

Implementación del Software (IS),

Actividad IS 6 Entrega del Producto

-Configuración del software

-Formulario de instrucciones de entrega

aprobado

-Formulario de acta de aceptación

Tabla 6. Paquete de Despliegue 6: Entrega del producto, Perfil Básico (PD6).

Proceso Artefactos Implementación de Software,

Identificación de requerimientos

-Casos de uso

-Escenarios de atributos de calidad

-Documentos de requerimientos

Implementación de Software,

Perfeccionamiento y análisis de requerimientos

-Casos de uso

-Escenarios de atributos de calidad

-Documentos de requerimientos

-Prototipo del software

Implementación de Software,

Verificación y validación de requerimientos

-Documentos de requerimientos

-Prototipo del software

Implementación de Software,

Gestión del Cambio de requerimientos

-Documentos de requerimientos

Tabla 7. Paquete de Despliegue 7: Análisis de requerimientos del software, Perfil Básico (PD7).

Como se mencionó con anterioridad, en esta propuesta es utilizado como base el modelo de

Calidad de Datos definido por el estándar ISO/IEC 25012, el cual está compuesto por 15

dimensiones o características de calidad, las cuales se pretende aplicar a los artefactos

Page 21: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

21

generados y utilizados en los paquetes de despliegue seleccionados. En la Tabla 8 se muestra la

evaluación de los paquetes de despliegue en relación con las dimensiones de calidad con las que

se sugiere deberían contar los artefactos de los paquetes seleccionados. Cabe mencionar que

no todas las dimensiones son aplicables a los 3 paquetes, ya sea porque esos paquetes no

cumplen con la dimensión o por que utiliza artefactos que ya fueron evaluados en algún otro

paquete.

Dimensiones Paquete de despliegue

PD4 PD6 PD7

Exactitud

Completitud

Consistencia

Credibilidad

Actualidad

Accesibilidad

Conformidad

Confidencialidad

Eficiencia

Precisión

Trazabilidad

Comprensibilidad

Disponibilidad

Portabilidad

Recuperabilidad

Tabla 8. Dimensiones aplicables a los artefactos de los Paquetes de Despliegue.

Una vez identificados los artefactos que se utilizan en cada paquete de despliegue, se prosiguió

a identificar que dimensión es más favorable a cada artefacto, esta relación es mostrada en la

Tabla 9, así como también una descripción adecuada al contexto de los procesos de los paquetes

de despliegue.

Page 22: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

22

Dimensión Artefactos Descripción

Exactitud

-Plan del Proyecto

-Descripción del Proyecto

-Registro del estado del proyecto

-Solicitud de cambio

-Enunciado de trabajo

-Documentos de requerimientos

Todos los artefactos deberán

tener toda instrucción, proceso,

actividad y tarea, escrita y

descrita de forma exacta, de tal

manera que pueda ser

interpretada con claridad.

Completitud

-Plan de proyecto

-Software

-Acta de aceptación

-Configuración del software

-Formulario de instrucciones de entrega

-Casos de uso

-Escenarios de atributos de calidad

-Documentos de requerimientos

Todos los artefactos tendrán que

contar con datos completos,

permitiendo así que los datos

asociados a otros procesos

tengan el valor esperado y las

tareas puedan ser completadas

en tiempo y forma.

Consistencia

-Plan de proyecto

-Descripción del proyecto

-Solicitudes de cambio

-Casos de uso

-Escenarios de atributos de calidad

-Documentos de requerimientos

-Prototipos del software

Los artefactos contarán con

información coherente y estable,

ya que la información brindada

por artefactos iniciales será la

base que permita el desarrollo de

procesos posteriores.

Credibilidad

-Plan de proyecto

-Descripción del proyecto

-Solicitudes de cambio

-Formulario de instrucciones de entrega

Los artefactos de cada proceso

deberán tener datos creíbles y

verdaderos, permitiendo así que

los objetivos sean alcanzados.

Actualidad

-Registro del estado del proyecto

-Solicitudes de cambio

-Casos de uso

-Documentos de requerimientos

Los artefactos requieren datos e

información actualizados, ya que

de ellos depende el flujo y acceso

a procesos posteriores

Accesibilidad

-Plan de proyecto

-Descripción del proyecto

-Solicitudes de cambio

-Enunciado de trabajo (EDT)

-Documentos de requerimientos

-Prototipo del software

De acuerdo a los roles

especificados en el perfil

genérico, los artefactos, deberán

estar en completa disposición

para roles específicos en

procesos determinados.

Conformidad

-Plan de proyecto

-Descripción del proyecto

-Solicitud de cambio

-Acta de aceptación

-Enunciado del trabajo (EDT)

-Configuración del software.

Los artefactos deberán cumplir,

primero, con las especificaciones

del cliente, seguida de los

requerimientos establecidos para

cada proceso; y cada proceso

deberá seguir las normativas

Page 23: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

23

-Formulario de instrucciones de entrega -

Formulario de acta de aceptación

-Casos de uso

-Documento de requerimientos

-Prototipo del software

(ISO´s) correspondientes y

vigentes durante su realización.

Confidencialidad

-Plan de proyecto

-Registro el estado del proyecto

-Solicitudes de cambio

-Software

De acuerdo a los roles

establecidos, se debe asegurar

que datos serán accedido por el

personal autorizado en cada área

y cual no.

Precisión

-Plan del proyecto

-Descripción del proyecto

-Solicitudes de cambio

-Caso de uso

-Documento de requerimientos

Los artefactos deben mostrar

datos concisos que proporcionen

solo información necesaria para

decidir de forma correcta las

actividades para los siguientes

procesos.

Trazabilidad

-Plan de proyecto

-Registro el estado del proyecto

-Solicitudes de cambio

-Configuración del software

-Casos de uso

-Prototipos del software

Todos los artefactos deben tener

datos trazables, de modo que sus

orígenes puedan ser

determinados con facilidad.

Comprensibilidad

-Plan de proyecto

-Descripción del proyecto

-Solicitud de cambio

-Software

-Acta de aceptación

-Configuración del software.

-Formulario de instrucciones de entrega

-Casos de uso

-Documento de requerimientos

-Prototipo del software

Todos los artefactos deberán

contar con datos de forma clara,

que permitan ser interpretados y

entendidos por roles y lenguajes

específicos.

Portabilidad

-Software

-Prototipo del software

Los artefactos podrán ser

instalados, movidos,

reemplazados o eliminados de un

proceso a otro durante el

desarrollo del proyecto.

Tabla 9. Dimensiones de calidad de datos aplicadas a los artefactos de los PD.

Las dimensiones de calidad de datos adecuadas, servirán como referencia para la realización de

cada artefacto dentro del desarrollo de algún proceso del Grupo de Perfil Genérico, ya que se

centra en las características que deben tener los datos estructurados dentro de un sistema para

ser considerados de calidad.

Page 24: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

24

Al mencionar calidad de datos, es obvio que a lo que se le está aplicando calidad es a los datos

que se presentan y se describen en cada uno de los artefactos, por lo cual los datos expuestos

en cada uno de ellos se considera un recurso clave para la toma de decisiones, ya que

dependiendo de la interpretación que se le dé a éstos, se llevarán a cabo acciones que puedan

atraer resultados satisfactorios o negativos.

Por tal motivo, lo que el modelo de calidad de datos propuesto en este trabajo expone, es un

documento que muestre datos que describen a otros datos, es decir, un conjunto de metadatos

(ver Tabla 10), los cuales son comunes a la mayoría de los artefactos de los paquetes de

despliegue seleccionados. Estos datos son considerados de vital importancia, ya que de ellos

dependerá, en principio, el correcto seguimiento en los procesos de desarrollo de software.

Título del documento

Id del documento

Nombre del proyecto al que pertenece el documento

Historial de revisiones, incluye:

o Fecha

o Número de versión

o Autores

o Roles involucrados

Gestor del proyecto

Equipo de trabajo (ejemplo: Líder técnico, Diseñador, Analista,

Programador)

Cliente

o Revisor

o Revisiones

Confidencialidad

o Roles autorizados

Gestor del proyecto

Equipo de trabajo (ejemplo: Líder técnico, Diseñador, Analista,

Programador)

Cliente

Áreas Involucradas

o Productos de entrada

o Productos de salida

o EDT

Último acceso al documento

Ubicación del documento

Palabras clave

Tabla 10. Conjunto de metadatos comunes para los PD seleccionados.

Page 25: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

25

Cabe mencionar que este conjunto de metadatos puede ser aplicable para el resto de los

paquetes de despliegue, siempre y cuando se identifiquen e incluyan los metadatos específicos

para cada artefacto.

Page 26: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

26

IV. Aplicación del Modelo a un Caso de Estudio Con la finalidad de poner en práctica la propuesta del modelo de calidad de datos, ésta se aplicó

a los artefactos de los paquetes de despliegue seleccionados (mostrados en las Tablas 5, 6 y 7);

dichos artefactos son utilizados durante el desarrollo de un proyecto de software. En la Tabla 11

se describen a grandes rasgos el proyecto en el cual se utilizará la propuesta.

4.1 ARTEFACTOS DEL CASO DE ESTUDIO Enseguida se describen algunos de los artefactos realizados para el caso de estudio, estos

artefactos fueron realizados usando como modelo las plantillas proporcionadas por cada

paquete de despliegue (PD4, PD6, PD7) para el desarrollo de software; las plantillas pueden ser

usadas como modelo, o bien pueden ser modificadas para su uso conveniente durante los

diferentes procesos del desarrollo.

PD4.- Gestión de Proyecto

En el PD4 Gestión de Proyecto, las plantillas proporcionadas son: el plan de proyecto, estructura

de desglose de tareas (EDT), solicitudes de cambio e informe de reuniones. Estas plantillas, una

vez realizadas se convertirán en los artefactos más importantes en el desarrollo de proyectos

software, ya que en ellos se describe de manera detallada el producto que se espera obtener al

final del proyecto, el orden en el que se llevará a cabo las actividades y tareas, además de los

posibles cambios e informes sobre el avance del proyecto. Los artefactos realizados según las

plantillas y adecuados al caso de estudio son mostrados en las Tablas 12, 13, 14 y 15.

1 Descripción del Proyecto

1.1 Propósito, alcance y objetivos

- Propósito: Desarrollar un proyecto web, que sea de ayuda para la empresa ‘ACME’ a tener una

mejor y más rápida captura y venta de sus productos, así como un mejor control en la

administración e inventario.

La empresa ‘ACME’ ha solicitado el desarrollo de un software que le permita una rápida atención a

clientes, captura y modificación de clientes, productos, proveedores y notas de compra, así como la

generación de facturas.

Además de eso la empresa ha solicitado que el software auxilie en la parte de inventario, permitiendo

tener un mejor control sobre el historial de productos, así como el cálculo estimado de recursos

económicos totales y por producto.

Por otra parte se ha solicitado que el software cuente con autentificación de usuarios, que le permitirá

a la empresa tener un mejor control sobre la administración, ya que además, ha solicitado que el

software brinde información parcial y total de las ventas diarias, reiniciando en ceros después de un

corte total y guardando la información para consultas posteriores; el software también deberá permitir

el control de un súper usuario (administrador) que se encargue de autorizar o restringir actividades

para otros usuarios (empleados/personal).

Tabla 11. Descripción del proyecto de software solicitado por la empresa ACME.

Page 27: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

27

- Alcance del proyecto: incluye desde el planteamiento del proyecto hasta la instalación del

mismo bajo las condiciones de entrega especificadas por el cliente.

- Objetivos: Lograr que el programa realice la captura de clientes, proveedores, productos y

notas de compra, realice ventas y de forma automática se realice la actualización de

inventario, además deberá contar con una jerarquía de usuarios limitando la realización de

algunas actividades a los usuarios que no sean administradores.

- Lista de los miembros del Equipo: gestor del proyecto, equipo de trabajo y cliente.

1.2 Entregables del Proyecto

- Documentación, software.

- Formulario de instrucciones de entrega.

2 Organización del Proyecto

2.1 Proceso modelo

Para el desarrollo del sistema se usará el método de cascada, iniciando por la planificación,

análisis de requerimientos, diseño, codificación, pruebas unitarias, integración, pruebas de

sistema y mantenimiento.

2.2 Responsabilidades del Proyecto

Una identificación de los roles y responsabilidades específicas a ser adoptadas por cada

miembro del Equipo de Proyecto.

2.3 Procedimientos para el Control de Cambios

Los cambios propuestos serán sometidos a evaluación, después de haber sido evaluados y

aceptados serán enviados al equipo de trabajo correspondiente para su desarrollo y/o

implementación.

2.4 Gestión de la Configuración

La configuración del software, líneas base y elementos de configuración de software.

3 Paquetes de Trabajo, Cronograma y Presupuesto

3.1 Paquetes de Trabajo

Descripción del EDT.

Actividades Fecha inicio Fecha final

Planificación 01/01/2018 30/01/2018

Análisis de Requerimientos 01/02/2018 30/02/2018

Diseño 01/03/2018 30/03/2018

Codificación 01/04/2018 20/05/2018

Pruebas 21/05/2018 30/05/2018

Integración 01/06/2018 25/06/2018

Pruebas del sistema 26/06/2018 07/07/2018

Implementación y Entrega 08/07/2018 30/09/2018

Mantenimiento 01/10/2018 -----------

Tabla 12. Artefacto del PD4- Plan de proyecto

Page 28: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

28

Número

de Tarea

Tipo de Tarea Descripción de la Tarea Estimación (días)

1 Tarea principal Iniciación de la implementación del

software

30(20+10)

1.1 Sub-tarea Revisar el plan del proyecto 20

1.2 Sub-tarea Establecer el entorno de

implementación

10

2 Tarea principal Análisis de los requisitos del software 19(10+2+3+4)

2.1 Sub-tarea Recopilar información 10

2.2 Sub-tarea Identificar alcance del proyecto 2

2.3 Sub-tarea Identificar y capturar los requisitos 3

2.4 Sub-tarea Estructurar o priorizar los requisitos 4

3 Tarea principal Identificación de los componentes del

software

11(4+7)

3.1 Sub-tarea Comprender la especificación de los

requisitos

4

3.2 Sub-tarea Documentar la identificación de los

componentes

7

4 Tarea principal Construcción del software 124(30+50+8+25+11)

4.1 Sub-tarea Diseñar 30

4.2 Sub-tarea Codificar 50

4.3 Sub-tarea Verificar 8

4.4 Sub-tarea Integrar 25

4.5 Sub-tarea Verificar 11

Tabla 13. Artefacto del PD4- Estructura de Desglose de Trabajo (EDT)

Nombre del Proyecto:

Punto de Ventas Genérico

Fecha y Lugar:02/01/2018,

Oficina 1, empresa ´ACME´

Asistentes: Equipo de proyecto

Objetivo(s): Realizar la planeación del desarrollo del proyecto

Comentarios: Se requiere la asistencia de todos los líderes de áreas, para realizar una mejor estrategia en

la planeación del proyecto.

Próxima Reunión (Fecha, lugar, asistentes, objetivos):

Aún no definida.

Tabla 14. Artefacto del PD4- Informe de reuniones-Ejemplo de contenidos.

Page 29: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

29

Nombre del Proyecto: Punto de Ventas Genérico

Fecha: __15/03/18____

Solicitud de Cambio: Integrar un mecanismo que permita realizar consultas diarias, semanales, mensuales,

anuales, por proveedor y/o por cliente, generando un reporte que puede ser impreso o solo visualizado.

Impacto: Bajo, es un cambio que no afecta el desarrollo de ninguna de los requisitos que el cliente

especificó en su solicitud inicial.

Criticidad, fecha en la que se requiere: _01/06/18 es la fecha donde tiene que estar terminada esta

funcionalidad, ya que este día inicia de la integración de todas las funcionalidades y se requiere para luego

dar inicio a las pruebas que determinarán si el software es lo que el cliente necesita.

Estado: Aceptado Pospuesto Rechazado

Comentarios: La fecha de entrega puede aplazarse hasta 20 días después de la fecha antes mencionada,

ya que esta funcionalidad es secundaria por lo tanto puede ser integrada después de las funcionalidades

principales.

Tabla 15. Artefacto del PD4- Solicitudes de cambio- Ejemplo de contenidos

PD6.- Entrega de Producto

Los artefactos realizados para este paquete son importantes desde el inicio, aunque

mayormente enfocados a los procesos efectuados durante el cierre del proyecto. Las Tablas 16

y 17 muestran los artefactos relevantes a este paquete y adecuados al caso de estudio.

Formulario de Instrucciones de Entrega

Identificación de Proyecto o Nombre del Cliente: Punto de Venta Genérico

Cliente: “ACME”

Preparado por: Melissa Rodríguez.

Fecha: 2018-07-01.

Identificación de Entregables:

Software, manuales de usuario.

Requerimientos de entrega:

Page 30: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

30

Software instalado en equipos de cómputo de la empresa

Orden secuencial de las tareas a ser ejecutadas:

1.- Llega al lugar indicado para realizar la instalación.

2.- Verificar que los equipos de cómputo tengan los requerimientos necesarios para que sean compatibles

con el software.

3.- Realizar las instalaciones necesarias para el manejo de bases de datos.

4.- Instalación del software.

5.- Realización de pruebas de compatibilidad.

Releases aplicables:

Software

Criterios de Aceptación:

Criterio de Aceptación Fecha de cumplimiento del Criterio

1 Software funcional 2018/10/01

2

3

Componentes de Software Información de Versión

Captura de ventas 1

Captura de clientes 1

Captura de proveedores 1

Captura de notas de compra 1

Consultas 1

Generación de reportes 1

Captura y modificación de inventario 1

Respaldo y procedimientos de recuperación:

EL software debe tener incluido un sistema de respaldo, el cual generará una copia de seguridad para toda

la información cada semana, si existiese alguna avería la recuperación será posible con una pérdida de datos

mínima.

Aprobado por:

______________________ _______________________________

Gestor de Proyecto Cliente o Representante de Cliente

Fecha: 2018-07-15.

Tabla 15. Artefacto del PD6- Formulario de instrucciones de entrega

Page 31: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

31

Formulario de Acta de Aceptación

Identificación de Proyecto: Punto de venta

Preparado por: Melissa Rodríguez

Fecha: 2018/07/18

Criterios de Aceptación:

Criterio de Aceptación Fecha de cumplimiento del Criterio

1 Cumple con las instrucciones de entrega 2018-10-05

2 Cumple con los requerimientos solicitados 2018/10/05

3 Interfaz amigable 2018/10/05

4 Documentación actualizada 2018/10/15

5 La entrega incluye manual de usuario 2018/10/15

Firmas de Aceptación:

Componentes de Software Información de Versión Fecha de aceptación

por el Cliente

Firma de Cliente

Captura de ventas 1

Captura de clientes 1

Captura de proveedores 1

Captura de notas de

compra

1

Consultas 1

Generación de reportes 1

Captura y modificación de

inventario

1

Tabla 16. Artefacto del PD6- Formulario de acta de aceptación

PD7.- Análisis de Requerimientos.

El último paquete de despliegue utilizado para este trabajo, es el PD7 Análisis de

Requerimientos, en el cual los artefactos de mayor importancia son generados en conjunto con

el cliente, ya que en ellos se especifican los requisitos con los cuales debe contar el producto

software solicitado, además de que se deben contemplar los posibles escenarios para algunos

atributos. Para el caso de estudio esta información es especificada en las Tablas 18 y 19.

Page 32: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

32

Escenario de calidad: El usuario podrá consultar los catálogos de productos, clientes,

proveedores, usuarios, en un horario indistinto, obteniendo resultados

en un tiempo casi inmediato.

Atributo de calidad Desempeño

Estímulo El usuario decide consultar el catálogo de productos existentes en

bodega.

Fuente de Estímulo Seleccionar la opción deseada en el menú de opciones, introducir fechas

y/o nombres de la búsqueda requerida y presionar la tecla Enter o

selecciona el botón a través del click del mouse.

Ambiente Entorno de trabajo administrativo

Artefacto (si se conoce) Reportes (Catálogos)

Respuesta Muestra catálogo solicitado, además de dar la opción de exportarlo,

imprimirlo o guardarlo en diferentes formatos.

Medida de la Respuesta Medio segundo hasta 3 segundos.

Tabla 17. Artefacto del PD7- Escenario de atributo de calidad

Especificación de requisitos de software:

Se muestra en el Anexo A.

Tabla 18. Artefacto del PD7- Documento de requerimientos

4.2 METADATOS DE LOS ARTEFACTOS DEL CASO DE ESTUDIO

Como se mencionó previamente, como parte de la propuesta se define un documento

con un conjunto de metadatos aplicables a los distintos artefactos utilizados en los

procesos, el documento con metadatos revela datos de importancia sobre los artefactos

generados y utilizados durante los procesos de desarrollo del caso de estudio (ver

Tablas 20, 22, 24, 26, 28, 30, 32, 34).

Page 33: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

33

Documento: Plan de Proyecto

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo y cliente

Confidencialidad Líder Técnico, Diseñador, Analista, Programador

Producto de Entrada Descripción del proyecto

Proceso Planificación del proyecto

Producto de Salida Plan de proyecto, EDT, Formulario de Instrucciones de Entrega

Ubicación: C:\user\docs\proyectsPDV1pp.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, planeación, EDT, software.

Aprobado por:

______________________

Gestor de Proyecto

Tabla 19. Metadatos plan de proyecto

Asimismo, en las Tablas 21, 23, 25, 27, 29, 31, 33, 35, se muestran las dimensiones de calidad

pertinentes para cada uno de los documentos con los metadatos propuestos, así como una

descripción adecuada al caso de estudio.

Dimensión a cumplir Descripción

Exactitud

El artefacto deberá especificar de forma exacta los productos de salida

que pudieran verse involucrados en el desarrollo del software, de

manera que el equipo de trabajo pueda tener una buena organización y

rápida respuesta si algún producto llegase a afectar a otro proceso.

Completitud

El artefacto tendrá que contar la ubicación completa. De tal manera que

facilite la localización del proceso al que pertenece, evitando también el

tras papeleo con algún otro proyecto.

Tabla 20. Dimensiones aplicables a los metadatos del plan de proyecto

Page 34: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

34

Documento: Estructura de Desglose de Trabajo

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo

Confidencialidad Líder Técnico, Diseñador, Analista, Programador

Producto de Entrada Descripción del proyecto

Proceso Planificación de proyecto

Producto de Salida Estructura de Desglose de Tareas,

Formulario de instrucciones de entrega

Ubicación: C:\user\docs\proyects1PDVEDT.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, actividades, tareas, EDT, software.

Aprobado por:

______________________

Gestor de Proyecto

Tabla 21. Metadatos EDT

Dimensión a cumplir Descripción Consistencia El artefacto deberá mostrar coherencia en los roles involucrados,

productos y procesos de forma que permitirá a las tareas seguir un

orden adecuado durante los procesos de desarrollo del proyecto.

Credibilidad El artefacto deberá tener información creíble y verdadera que permita

al equipo de trabajo lograr los objetivos establecidos y que, a su vez

cumplan con lo solicitado por el cliente.

Tabla 22. Dimensiones aplicables a los metadatos del EDT

Page 35: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

35

Documento: Solicitudes de Cambio

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo y cliente

Confidencialidad Líder Técnico, Diseñador, Analista, Programador, Cliente

Producto de

Entrada

Solicitud de Cambio,

Informe de Reuniones

Proceso Ejecución del Plan de proyecto

Producto de

Salida

Plan de Proyecto,

Estructura de Desglose de Tareas,

Solicitudes de cambio

Ubicación: C:\user\docs\proyects1SdC.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, actividades, tareas, EDT, cambios.

Aprobado por:

______________________

Gestor de Proyecto

Tabla 23. Metadatos solicitud de cambio

Dimensión a cumplir Descripción Actualidad El artefacto deberá contar con el último acceso actualizado, haciendo

saber al equipo de trabajo sobre cambios solicitados o realizados

durante el desarrollo de software, evitando además retrasos y

desorganización en alguno de los procesos.

Accesibilidad El artefacto deberá especificar los roles autorizados para su

manipulación.

Tabla 24. Dimensiones aplicables a los metadatos de la solicitud de cambio

Page 36: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

36

Documento: Informe de Reuniones

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo

Confidencialidad Líder Técnico, Diseñador, Analista, Programador

Producto de

Entrada

Informe de Reuniones, Solicitud de Cambio

Proceso Planificación y Ejecución de Proyecto

Producto de

Salida

Informe de Reuniones,

Solicitud de Cambio,

Estructura de Desglose de Tareas

Ubicación: C:\user\docs\proyects1IR.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, actividades, tareas, EDT, informes.

Aprobado por:

______________________

Gestor de Proyecto

Tabla 25. Metadatos informe de reuniones

Dimensión a cumplir Descripción

Precisión El/los productos de salida deben mostrar la información necesaria para

una correcta toma de decisiones durante los procesos de desarrollo de

software.

Trazabilidad El/los productos de entrada y salida deben mostrar la información

trazable, de modo que los roles autorizados puedan identificar la

procedencia y destino de los datos utilizados durante el desarrollo del

software.

Tabla 26. Dimensiones aplicables a los metadatos del informe de reuniones

Page 37: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

37

Documento: Formulario de Instrucciones de Entrega

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo y cliente

Confidencialidad Gestor del Proyecto, Cliente

Producto de

Entrada

Descripción del proyecto

Proceso Cierre de proyecto y Entrega de Producto

Producto de Salida Formulario de Instrucciones de Entrega,

Formulario de Instrucciones de Entrega Aprobado

Ubicación: C:\user\docs\proyects1FdIE.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, actividades, formulario, cierre, software, entrega.

Aprobado por:

______________________

Gestor de Proyecto

Tabla 27. Metadatos formulario de instrucciones de entrega

Dimensión a cumplir Descripción

Confidencialidad El artefacto será consultado/utilizado solo por el personal

autorizado para la entrega.

Comprensibilidad El artefacto deberá contar con información clara que le permita

al equipo de trabajo entregar el proyecto en tiempo y forma, de

acuerdo a las especificaciones indicadas por el cliente.

Tabla 28. Dimensiones aplicables a los metadatos del formulario de instrucciones de entrega

Page 38: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

38

Documento: Formulario de Acta de Aceptación

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo y cliente

Confidencialidad Líder Técnico, Diseñador, Analista, Programador

Producto de

Entrada

Descripción del proyecto

Proceso Entrega del producto

Producto de

Salida

Acta de Aceptación

Ubicación: C:\user\docs\proyects1FdAA.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, software, entrega.

Aprobado por:

______________________

Gestor de Proyecto

Tabla 29. Metadatos formulario de acta de aceptación

Dimensión a cumplir Descripción Exactitud El artefacto deberá mostrar de manera clara y exacta el nombre del

proyecto, ID y cliente, para evitar alguna confusión si llegara a haber

otro proyecto con información similar.

Actualidad El artefacto deberá mostrar los últimos accesos y ubicación actualizada

para evitar retrasos y malos entendidos durante las revisiones de

aceptación.

Tabla 30. Dimensiones aplicables a los metadatos del formulario de acta de aceptación

Page 39: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

39

Documento: Escenario de Atributos de Calidad

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo

Confidencialidad Líder Técnico, Diseñador, Analista, Programador

Producto de Entrada Descripción del proyecto

Proceso Implementación del Software.

Producto de Salida Estructura de desglose de tareas

Ubicación: C:\user\docs\proyects1EAdC.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, calidad, escenario, software,

Aprobado por:

______________________

Gestor de Proyecto

Tabla 31. Metadatos de escenarios de atributos de calidad

Dimensión a cumplir Descripción Credibilidad El artefacto deberá mostrar productos, procesos, nombres y palabras

creíbles, información que facilitará la ubicación de algún otro artefacto. Tabla 32. Dimensiones aplicables a los metadatos de los escenarios de atributos de calidad

Page 40: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

40

Documento: Especificación de Requerimientos del Software

Nombre del Proyecto: Punto de Ventas Genérico

ID: PVG1

Cliente: Empresa ‘ACME’

Autor: Melissa Rodríguez

Fecha:02/01/2018

Versión: 1

Revisión: 1

Involucrados Gestor de proyecto, equipo de trabajo, Cliente

Confidencialidad Líder Técnico, Diseñador, Analista, Programador

Producto de Entrada Descripción del proyecto

Proceso Implementación del Software.

Producto de Salida Especificación de Requerimientos del Software

Ubicación: C:\user\docs\proyects1EdRS.docs

Último acceso: 20/09/2018

Palabras Clave: Gestión, calidad, escenario, software,

Aprobado por:

______________________

Gestor de Proyecto

Tabla 33. Metadatos documento de requerimientos

Dimensión a cumplir Descripción Precisión El artefacto deberá mostrar palaras clave claras y precisas, que faciliten

la búsqueda de artefactos relacionados con el mismo artefacto y/o

proceso durante el desarrollo del software.

Trazabilidad El/los productos de entrada y salida serán mostrados de forma clara, de

modo que los roles autorizados puedan identificar la procedencia y

destino de los datos utilizados durante el desarrollo del software.

Tabla 34. Dimensiones aplicables a los metadatos del documento de requerimientos

Page 41: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

41

V. Conclusiones y Trabajo a Futuro En la actualidad la Ingeniería del Software ha tomado gran importancia debido al crecimiento

de la industria de software, y son las PO uno de los principales motores de la economía en este

sector a nivel mundial.

Debido al gran auge las PO buscaron mejorar la calidad de sus procesos de desarrollo de

software, sin embargo, los estándares que utilizaban no se ajustaban a sus necesidades ya que

estaban diseñadas para empresas de mayor tamaño, además de que requerían inversiones más

grandes en cuestión económica y de tiempo.

La Organización Internacional para la Estandarización (ISO) preocupada por resolver estas

dificultades y apoyar a las PO, creó el grupo de trabajo SC7-WG24, quien en 2010 presentó la

ISO/IEC 29110, constituida por un conjunto de guías que establecen un marco común que

describe perfiles evaluables del ciclo de vida del software basados en estándares internacionales

que además se ajustan a las características de las PO.

Una vez presentada la norma ISO/IEC 29110, las PO comenzaron la elaboración de sus productos

tomando como referencia las guías provistas en las diferentes partes de la norma; la parte 5, es

la encargada de proveer las guías para la Gestión del Proyecto (GP) e Implementación de

Software (IS), que a su vez proveen un conjunto de Paquetes de Despliegue (PD) en los que se

describen y proporcionan plantillas para la realización de artefactos para todos los procesos de

desarrollo de software bajo estándares de calidad. Sin embargo, guiarse de procesos de calidad,

no garantiza la calidad en los datos de los artefactos que se generan en cada proceso.

Por tal motivo, y al no encontrar trabajos relacionados con la calidad de los datos enfocados a

la mejora de procesos en la norma ISO/IEC 29110; el presente trabajo propone un modelo de

calidad de datos, basado en las características que se encuentran reflejadas en el modelo de

calidad definido por el estándar ISO/IEC 25012. El modelo propuesto, se enfoca en la calidad de

los artefactos de los PD de la parte 5 del estándar ISO/IEC 29110 y afecta de manera directa a

los metadatos que describen a los artefactos, ya que aplicados de forma adecuada brindarán

una mejor referencia en la ejecución de los procesos involucrados en el desarrollo de software

en las PO; de esta manera, al aumentar la calidad de los datos se aumenta aún más la calidad de

sus procesos, así como la de sus productos y/o servicios, aproximando a las PO a competir con

empresas de mayor tamaño.

El presente trabajo en sus primeras etapas, fue presentado como ponencia en el 2° Congreso

Nacional y 1er. Congreso Internacional de Agroindustrias, Automatización y Agronegocios y 5

Jornada en Ciencia y Tecnología Agroindustrial “INNOVACIÓN Y DESARROLLO DESDE EL VALLE

DEL SALADO” (ver Anexo B), llevado a cabo del 8 al 12 de octubre del 2018, siendo publicada en

el libro electrónico de esta última con registro ISBN: 978-607-535-071-4.

Como trabajo a futuro se pretende aplicar este modelo de calidad de datos a todos los artefactos

de los Paquetes de Despliegue que comprenden el ISO/IEC 29110-5, para la implementación de

los aspectos de Gestión e Ingeniería descritos en el Perfil Básico del Grupo de Perfil Genérico.

Page 42: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

42

VI. Referencias [1] M. Acebo Plaza, A. Núñez, M. Villavicencio, J. Rodríguez, J. Zambrano, & J. Quijano,

“Orientación estratégica para la toma de decisiones, Industria de Software”, Revista estudios

industriales, Escuela Superior Politécnica del Litoral ESPOL, Ecuador, Investigación, 2017.

[2] M. L. Saavedra G & Y. Hernández C., “Caracterización e importancia de las MIPYMES en

Latinoamérica: Un estudio comparativo.,” Actualidad Contable Faces, vol. 11, no. 17, pp. 122–

134, 2008.

[3] F. J. Pino, F. García, & M. G. Piattini Velthuis, “Revisión sistemática de mejora de procesos

software en micro, pequeñas y medianas empresas”, REICIS. Revista Española de Innovación,

Calidad e Ingeniería del Software, vol. 2, no. 1, pp. 6–23, 2006.

[4] J. A. Calvo-Manzano, J. Garzás, M. G. Piattini Velthuis, F. J. Pino, J. Salillas, & J. L. Sánchez,

“Perfiles del ciclo de vida del software para pequeñas empresas: los informes técnicos ISO/IEC

29110,” REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software, vol. 4, no. 2,

pp. 96–108, 2008.

[5] C. Y. Laporte, “La implementación de la norma ISO/IEC 29110 Guías de Gestión e Ingeniería para las organizaciones pequeñas,” presentado en el 5th Congreso Internacional de Mejora de Procesos de Software, Aguascalientes, México, 2016.

[6] A. Cornejo, “ISO 12207,” Normas y Estándares en Proyectos de T.I, Sistemas de Calidad en

T.I, 2015. Página web: https://normasyestandaresproyectosti.wordpress.com/2015/01/29/iso-

12207/. Accesado por última vez: 28/12/2018.

[7] ISO, “International Organization for Standardization, ISO/IEC/IEEE 15289:2017 Systems and

software engineering -- Content of life-cycle information items (documentation)”, International

Organization for Standardization, 2018. Página

web: https://www.iso.org/standard/71950.html. Accesado por última vez: 04/01/2019.

[8] A. Mas & E. Amengual, “La mejora de los procesos de software en las pequeñas y medianas

empresas (pyme)”, REICIS. Revista Española de Innovación, Calidad e Ingeniería del

Software, vol. 1, no. 2, pp. 7–29, 2005.

[9] R. M. Cuentas Morat & J. L. Ramos Castro, “Implementación de herramientas de soporte para

los procesos de la norma ISO/IEC 29110- Perfil Básico”, Universidad Peruana de Ciencias

Aplicadas (UPC), 2015.

[10] Comité Técnico de Normalización de Ingeniería de Software y Sistemas de Información,

“Norma Técnica NTP- ISO/IEC RT 29110-5-1-2 Peruana 2012,” Lima, Perú, 2012. Página

web: http://profs.etsmtl.ca/claporte/Publications/Publications/NTP-RT%2029110-5-1-

2.v.5.pdf. Acessado por última vez: 19/06/2018.

[11] G. Salgado, “MoProSoft: Un modelo para mejorar la calidad del software en México”, 2017.

Página Web: http://conogosi.org/articulos/moprosoft-un-modelo-para-mejorar-la-calidad-del-

sotfware-en-mexico/. Accesado por última vez: 21/12/2018.

Page 43: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

43

[12] Grupo EQA, “La norma SPICE, ISO/IEC 15504”, España. Página web:

https://eqa.es/presentaciones/presentacion_ISO_15504.pdf. Accesado por última vez:

04/01/2019.

[13] R. S. Pressman, “Ingeniería de Software, un enfoque práctico”, 7th ed. McGraw Hill, pp. 25-

54, 2010.

[14] ISO/IEC 29110 – Ingeniería de Software. Página Web: http://nycecolombia.co/isoiec-29110.

Accesado por última vez: 21/07/18.

[15] Estructura de la Norma ISO 29110. Página Web: http://e-

processmexico.com/consultoria/iso-29110/. Accesado por última vez: 23/07/18.

[16] L. Cai & Y. Zhu, “The Challenges of Data Quality and Data Quality Assessment in the Big

Data Era”. Data Science Journal, 14: 2, pp. 1-10, 2015. Disponible en:

http://dx.doi.org/10.5334/dsj-2015-002.

[17] ISO, “Systems and software engineering -- Systems and software Quality Requirements and

Evaluation (SQuaRE) -- System and software quality models,” International Organization for

Standardization, 2018. Disponible en: https://www.iso.org/standard/35736.html.

[18] Características definidas en el estándar 25012. Página Web:

https://iso25000.com/index.php/normas-iso-25000/iso-25012. Accesado por última vez:

25/07/18.

[19] C. Y. Laporte, N. Séguin, G. Villa-Boas, S. Buasung, “Pequeñas empresas de tecnología,

aprovechando las ventajas de las normas de ingeniería de software y sistemas”, Revista ISO

Focus+, 2013. Disponible en: https://www.iso.org/sites/edumaterials/focus/iso-pequenas-

empresas-de-tecnologia.pdf

Page 44: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

44

Anexo A

Page 45: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

45

Especificación de requisitos de software Proyecto: Sistema de Punto de venta Genérico Revisión 1

Septiembre 2018

Page 46: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

46

Ficha del documento

Fecha Revisión Autor Verificado dep. Calidad.

22/10/2016 1 GREEN-SOFT

Documento validado por las partes en fecha: 04/02/2018

Por el cliente Por la empresa suministradora

‘ACME’

GREEN-SOFT

Fdo. D./ Dña Ana Costilla Méndez Fdo. D./Dño Juan José Contreras

Page 47: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

47

1. Introducción Este documento es una Especificación de Requisitos Software (SRS) para el Sistema de Punto

de Venta Genérico. Esta especificación se ha estructurado basándose en las directrices dadas

por el estándar IEEE Práctica Recomendada para Especificaciones de Requerimientos Software

ANSI/IEEE 830,1998 y por las especificaciones solicitadas por el cliente.

1.1 Propósito El presente documento tiene como propósito definir las especificaciones fundamentales del

software, tanto funcionales como no funcionales para el desarrollo de un sistema de punto de

venta que permita gestionar distintos procesos administrativos y de venta. Este será utilizado

por personas dedicadas al comercio lo cual incluye dueños, gerentes y empleados.

1.2 Alcance Esta especificación de requisitos está dirigida al usuario del sistema, para que pueda continuar

con la eficiencia y desarrollo de la empresa, la cual tiene por objetivo principal la gestión de

procesos administrativos (ventas, compras, inventarios), eficientizando el tiempo y por

consecuencia se espera una mejoría en las ventas.

1.3 Personal involucrado Nombre Juan José Contreras Torres

Rol Analista, Diseñador y Programador

Categoría Profesional Ingeniero en S.C.

Responsabilidades Análisis de información, diseño y programación del SPVG

Información de contacto [email protected]

Nombre Luis Antonio Contreras López

Rol Diseñador y Programador

Categoría Profesional Ingeniero en S.C.

Responsabilidades Análisis de diseño y programación del SPVG

Información de contacto [email protected]

Nombre Linda Lozano Alfaro

Rol Analista y Diseñador

Categoría Profesional Ingeniero en S.C.

Responsabilidades Análisis de información y diseño

Información de contacto [email protected]

Page 48: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

48

1.4 Definiciones, acrónimos y abreviaturas Referencia Titulo Usuario Persona que usara el sistema de punto de venta

SPVG Sistema de Punto de Venta Genérico

ERS Especificaciones de Requerimientos Software

RF Requerimiento Funcional

RNF Requerimiento no Funcional

1.5 Definiciones, acrónimos y abreviaturas Referencia Titulo IEEE Standard IEEE 830-1998

1.6 Resumen En este documento se encontrará la información acerca de las características del producto software requerido por el cliente, detallando tanto los requisitos funcionales como los no funcionales, que debe satisfacer el sistema.

Page 49: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

49

2. Descripción General

2.1 Perspectiva del producto El SPVG será un producto diseñado para trabajar en cualquier entorno comercial requerido por el cliente, lo que permitirá su utilización de forma rápida y eficaz, además que facilitará los procesos de compra-venta e inventariado mejorando de este modo la rápida atención al cliente.

2.2 Funcionalidad del producto

Ilustración 1. Diagrama de caso de uso

Page 50: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

50

2.3 Características de los usuarios

Tipo de Usuario Administrador

Formación Secundaria

Habilidades Computo Básico

Actividades Administrador (compra-ventas, captura de datos)

Tipo de Usuario Empleado

Formación Secundaria

Habilidades Computo Básico

Actividades Ventas

2.4 Restricciones Lenguaje en uso: java.

Interfaz intuitiva.

El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma

de programación.

El sistema se diseñará según un modelo cliente/servidor.

Sistema SQL para la gestión de base de datos.

2.5 Suposiciones y dependencias Se asume que los requisitos descritos son estables.

2.7 Evolución previsible del sistema Implementación de conexión en red en varias sucursales con la misma base de datos.

Actualización de interfaz del software.

Ampliación de base de datos.

3 Requisitos específicos

REQUISITOS FUNCIONALES

Page 51: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

51

Número de requisito RF01

Nombre de requisito Autentificación de Usuario

Tipo Requisito Restricción

Requisito previos Administrador/Empleado Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF02

Nombre de requisito Realización de Ventas

Tipo Requisito Restricción

Requisito previos Administrador/Empleado Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF03

Nombre de requisito Generación de Factura

Tipo Requisito Restricción

Requisito previos Administrador/Empleado Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF04

Nombre de requisito Verificación de Existencias

Tipo Requisito Restricción

Requisito previos Administrador/Empleado Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF5

Nombre de requisito Cierre de Caja

Tipo Requisito Restricción

Requisito previos Administrador/Empleado Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF06

Nombre de requisito Captura de Artículos

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Page 52: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

52

Número de requisito RF07

Nombre de requisito Captura de Compras

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF08

Nombre de requisito Captura de Empleados

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF09

Nombre de requisito Captura de Clientes

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF010

Nombre de requisito Captura de Proveedores

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF011

Nombre de requisito Modificar Artículo

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF012

Nombre de requisito Modificar Cliente

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Page 53: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

53

Número de requisito RF013

Nombre de requisito Modificar Proveedor

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF014

Nombre de requisito Modificar Empleados

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF015

Nombre de requisito Consultar Artículo

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF016

Nombre de requisito Consultar Empleados

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF017

Nombre de requisito Consultar Proveedores

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Número de requisito RF018

Nombre de requisito Consultar Corte de Caja

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

Page 54: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

54

Número de requisito RF019

Nombre de requisito Captura de Inventario

Tipo Requisito Restricción

Requisito previos Administrador Registrado

Prioridad del requisito Alta/Esencial Media/Deseado Bajo/Opcional

REQUISITOS NO FUNCIONALES

Número de requisito RNF01

Nombre de requisito Rendimiento

Tipo Requisito Restricción

Requisito previos

Prioridad del requisito Alta Media Bajo

Número de requisito RNF02

Nombre de requisito Disponibilidad

Tipo Requisito Restricción

Requisito previos Usuarios autorizados, artículos registrados, ventas

Prioridad del requisito Alta Media Bajo

Número de requisito RNF03

Nombre de requisito Usabilidad

Tipo Requisito Restricción

Requisito previos Usuarios autorizados, artículos registrados, ventas

Prioridad del requisito Alta Media Bajo

Número de requisito RNF04

Nombre de requisito Recuperabilidad

Tipo Requisito Restricción

Requisito previos Usuarios autorizados, artículos registrados, ventas

Prioridad del requisito Alta Media Bajo

Page 55: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

55

3.1 Requisitos comunes de las interfaces

3.1.1 Interfaces de Usuario

La interfaz con el usuario consistirá en un conjunto de ventanas con botones, listas y campos de

textos, que puedan ser usadas de forma fácil e intuitiva.

3.1.2 Interfaces de Hardware

Será necesario disponer de equipos de cómputo básico en perfecto estado, contando además con

la siguiente característica:

Lector de códigos de barras

Impresora de tickets

3.1.3 Interfaces de Software

Sistema operativo: Windows XP o superior.

3.2 Requisitos Funcionales (descripción)

3.2.1 Requisito funcional 1

Autentificación del usuario: Los usuarios deberán identificarse para acceder a cualquier

parte del sistema.

El sistema podrá ser manejado por los usuarios autorizados dependiendo del

rango en su nivel de accesibilidad, ya sea administrativo o ventas.

3.2.2 Requisito funcional 2

Realización de Venta: El sistema deberá permitir una fácil captura de productos y un rápido

cálculo de la cuenta, agilizando de esta manera la atención a clientes de la empresa.

3.2.3 Requisito funcional 3

Generación de Factura: El sistema permitirá al administrador y/o empleados la opción de

impresión de nota en ticket o factura según la petición del cliente.

3.2.4 Requisito funcional 4

Verificación de Existencias: El sistema permitirá al usuario administrativo o empleado dar

una vista rápida a la existencia de productos ya sea por ID o nombre.

3.2.5 Requisito funcional 5

Cierre de Caja: El sistema permitirá al usuario administrativo o empleado realizar el corte

caja de forma parcial o total que muestre el total de ventas realizadas durante el día.

Page 56: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

56

3.2.6 Requisito funcional 6

Captura de Artículos: El sistema permitirá al usuario administrativo la captura de artículos,

que serán guardados en una base de datos para su posterior manipulación.

3.2.7 Requisito funcional 7

Captura de Compras: El sistema permitirá al usuario administrativo la captura de las

compras realizadas, agregando los totales a la existencia de los productos contenidos en la

compra.

3.2.8 Requisito funcional 8

Captura de Empleados: El sistema permitirá al usuario administrativo dar de alta a nuevos

empleados.

3.2.9 Requisito funcional 9

Captura de Clientes: El sistema permitirá al usuario administrativo dar de alta la información

correspondiente a nuevos clientes.

3.2.10 Requisito funcional 10

Captura de Proveedores: El sistema permitirá al usuario administrativo dar de alta la

información correspondiente a nuevos proveedores.

3.2.11 Requisito funcional 11

Modificar Artículo: El sistema permitirá al usuario administrativo modificar y/o actualizar la

información existente de cualquier artículo.

3.2.12 Requisito funcional 12

Modificar Cliente: El sistema permitirá al usuario administrativo modificar y/o actualizar la

información existente de cualquier cliente.

3.2.13 Requisito funcional 13

Modificar Proveedor: El sistema permitirá al usuario administrativo modificar y/o actualizar

la información existente de cualquier proveedor.

Page 57: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

57

3.2.14 Requisito funcional 14

Modificar Empleados: El sistema permitirá al usuario administrativo modificar y/o

actualizar la información existente de cualquier empleado.

3.2.15 Requisito funcional 15

Consultar Artículo: El sistema permitirá al administrador consultar una lista con toda la

información de los productos existentes.

3.2.16 Requisito funcional 16

Consultar Empleados: El sistema permitirá al administrador consultar una lista con la

información relacionada con el personal que labora en la empresa.

3.2.17 Requisito funcional 17

Consultar Proveedores: El sistema permitirá al administrador consultar una lista con

información sobre los proveedores con los cuales tiene acuerdo la empresa.

3.2.18 Requisito funcional 18

Consultar Cortes de Caja: El sistema permitirá al administrador consultar una lista con toda

la información sobre los cortes de caja, a partir de un periodo seleccionado.

3.2.19 Requisito funcional 19

Capturar Inventario: El sistema permitirá al administrador la captura de inventario, el cual

una vez finalizado restaurara las existencias en los productos seleccionados.

3.3 Requisitos No Funcionales (descripción)

3.3.1 Requisito no funcional 1

Rendimiento: El sistema deberá ajustarse a las expectativas del cliente en cuanto a los

tiempos de respuesta en cada operación.

3.3.2 Requisito no funcional 2

Disponibilidad: El sistema deberá tener una disponibilidad de 99.99% en las diferentes

operaciones del sistema, durante las 24 horas al día, todos los días del año.

Page 58: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

58

3.3.3 Requisito no funcional 3

Usabilidad: El sistema deberá disponer de una interfaz sencilla y atractiva, además de una

clara documentación y opciones de ayuda que permite realizar consultas sobre la

funcionalidad de las operaciones con el menor tiempo.

3.3.4 Requisito no funcional 4

Recuperabilidad: El sistema deberá disponer de una base de datos que además de guardar

la información utilizada por la empresa, creara respaldos diarios, lo cual permitirá una fácil

recuperación si llegase a ocurrir alguna falla.

Page 59: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

59

Anexo B

Page 60: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

60

MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO ARTEFACTOS CON CALIDAD

Cortez Soriano María*, Guerra-García César

Coordinación Académica Región Altiplano Oeste UASLP, San Luis Potosí, México.

[email protected], [email protected]

RESUMEN:

Las pequeñas organizaciones (PO) dedicadas al desarrollo de software se han convertido en una pieza muy importante en la economía mundial, ya que sus aportes pueden ser utilizados por sistemas más grandes y complejos, sin embargo, muchas de las PO no son reconocidas como entidades que producen software de calidad. Debido a esto, las PO desean mejorar sus procesos de software utilizando prácticas eficientes de Ingeniería de Software adaptadas a su tamaño. La Organización Internacional para la Estandarización (ISO) creó un grupo de trabajo, que en 2010 presentó el estándar ISO/IEC 29110, constituido por un conjunto de guías y buenas prácticas que se ajustan a las características y necesidades de las PO. La ISO/IEC 29110 parte 5 provee una serie de paquetes de despliegue, los cuales son un conjunto de artefactos que facilitan la implementación de los procesos en las PO, sin embargo, no garantizan la calidad de datos en los datos de los artefactos utilizados en los procesos, por lo tanto, en el presente trabajo se propone un modelo de calidad de datos basado en la norma ISO/IEC 25012, que pueda ser usado en los artefactos que se utilizan durante los procesos de la ISO/IEC 29110 involucrados en el desarrollo de software en PO. Se pretende que el modelo propuesto permita incrementar la capacidad y calidad de los procesos de desarrollo software y, como consecuencia, la calidad de los productos y/o servicios que ofrecen poniéndolas a competir con empresas de mayor nivel.

PALABRAS CLAVE: Pequeñas Organizaciones, calidad de datos, ISO/IEC 29110, ISO 25012, metadatos.

INTRODUCCIÓN:

En la actualidad la industria del software en diversos países reconoce el valor de las aportaciones de productos y servicios que brindan las Pequeñas Organizaciones (PO), ya que también pueden desarrollar y mantener software que se utiliza en sistemas más grandes y complejos, debido a ello, a lo largo de todo el mundo se ha vuelto de gran interés. Asimismo, la industria del software incluyendo las PO´s, generan efectos significativos sobre otras industrias, a través de las mejoras que puede provocar la utilización de software que agilice uno o varios de sus procesos [1] [2].

Según encuestas y estudios como los que se mencionan en [3], muestran que las pequeñas organizaciones desean mejorar sus procesos de software incrementando la capacidad y calidad de sus procesos y, como consecuencia la calidad de sus productos y/o servicios.

Page 61: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

61

En el mismo estudio se evidencia que las PO están utilizando estándares que no se ajustan a las necesidades de las PO, ya que requieren inversión en presupuesto, tiempo y recursos que las PO no tienen. Como consecuencia las PO no suelen ser reconocidas como entidades que producen software de calidad.

En 2010, el grupo SC7-WG24 creado por la ISO presentó un conjunto de guías que se ajustan a las características de las PO, las cuales fueron presentadas en el estándar ISO/IEC 29110, estableciendo un marco común para describir perfiles evaluables del ciclo de vida de software basados en estándares internacionales, debido a que considera las prácticas de la ISO/IEC 12207 [4] y procesos de la ISO/IEC 15289 [5], sin excluir diferentes metodologías del ciclo de vida como lo son: cascada, iterativo, incremental, evolutivo o ágil.

En la actualidad, es fundamental que las empresas de desarrollo de software mantengan un nivel aceptable de calidad en procesos y productos/servicios; para que las PO puedan alcanzar este nivel, la ISO/IEC 29110 parte 5, provee una serie de paquetes de despliegue, los cuales buscan que las PO concluyan exitosamente un proyecto de desarrollo de software; los paquetes de despliegue son un conjunto de artefactos que facilitan la implementación de los procesos en las PO; los datos almacenados en los artefactos constituyen la parte más importante, ya que a través de la manipulación de los mismos, se genera información de valor para los procesos siguientes así como para el cliente/empresa. Uno de los problemas a los que se enfrenta la mayoría de las empresas es la falta de calidad en los datos que son utilizados en cada uno de los procesos que se siguen para la gestión de un proyecto, esto tiene un impacto en las empresas ya que al no contar con datos fiables se suelen cometer errores que afectan tanto el desempeño como la imagen de la empresa; por tal razón, el objetivo del presente trabajo, es proponer un modelo de calidad de datos, que pueda ser usado en los artefactos que se utilizan durante los procesos del estándar ISO/IEC 29110 involucrados con el desarrollo de software en PO, y que a su vez, mejore la calidad de los productos y/o servicios. AREAS RELACIONADAS

Estándar ISO/IEC 29110

El estándar ISO 29110 se divide en 5 partes de acuerdo al tipo de audiencia al que está dirigida, es decir, al campo de aplicación de cada una conformando el marco de trabajo que se muestra en la Tabla 1 [6].

Page 62: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

62

Tabla 1. Partes identificadas en el estándar ISO 29110.

ISO/IEC 29110 Titulo Audiencia Parte 1 Visión General Empresas, evaluadores,

desarrolladores, consultores, etc.

Parte 2 Marco de Referencia y Taxonomía

Normalizadores, desarrolladores, consultores, No es para las empresas.

Parte 3 Guía de Evaluación Evaluadores y empresas

Parte 4 Especificación de los Perfiles Normalizadores, desarrolladores, consultores. No es para las empresas.

Parte 5 Guía de Gestión e Ingeniería Empresas.

Esta norma cuenta con perfiles de entrada básico, intermedio y avanzado, lo que permite ser implementada por pequeñas empresas con un solo proyecto, hasta empresas con intenciones de avance como desarrolladoras de software.

En la Figura 1 se describe la serie ISO/IEC 29110 y posiciona las partes en el marco de trabajo de referencia. La visión general y las guías fueron publicados como reportes técnicos (RT) y los perfiles como Estándares Internacionales (IE) [7].

Figura 1. Estructura del Estándar ISO 29110 [8].

Page 63: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

63

Calidad de datos

En la actualidad no hay una definición precisa sobre calidad de datos, ya que ésta no solo depende de sus características, sino también del entorno en el que se utilizan los datos, los procesos y usuarios [9]. Por lo tanto, la calidad de los datos es un factor clave, ya que el acierto de las decisiones que toma una organización depende en gran medida de la calidad de la información en que dichas decisiones se basan. Son precisamente estas características las que se encuentran reflejadas en el modelo de Calidad de Datos definido por el estándar ISO/IEC 25012 [10] que se encuentra compuesto por 15 características [11] (ver Figura 2).

Figura 2. Características definidas en el estándar ISO 25012.

PROPUESTA

En el estándar ISO/IEC 29110-5 se proveen guías para la implementación sobre gestión e ingeniería para el Perfil Básico del Grupo del Perfil Genérico especificado en el ISO/IEC 29110 Parte 4. El Perfil Básico describe el desarrollo de software de una sola aplicación por un solo equipo de proyecto sin ningún riesgo especial o factores situacionales. Con la finalidad de facilitar la implementación del estándar ISO/IEC 29110 para las PO, se puso a disposición un conjunto de Paquetes de Despliegue (PD) [7]. Un PD es un conjunto de artefactos desarrollados para facilitar la implementación de un conjunto de prácticas, de las seleccionadas del marco de trabajo de una PO. Para el Perfil Básico de una PO, se encuentran disponibles un conjunto de Paquetes de Implementación: 1.- Construcción y Pruebas Unitarias 2.- Verificación y Validación 3.- Integración y Pruebas 4.- Gestión del Proyecto 5.- Arquitectura y Diseño Detallado 6.- Entrega del Producto 7.- Análisis de Requisitos

Page 64: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

64

8.- Control de Versiones 9.- Autoevaluación

La propuesta de este trabajo es un modelo de calidad de datos que pueda ser usado por el personal designado para el desarrollo de software, para mejorar la calidad de los datos gestionados en los artefactos de los Paquetes de Despliegue utilizados durante los procesos de desarrollo de software. Asimismo, será de ayuda para que las PO puedan mejorar sus procesos y como consecuencia, brindar un producto/servicio software de alta calidad que las acercará a competir con empresas de mayor tamaño.

Para cada PD se utilizan diferentes artefactos, que a su vez serán presentados como productos de entrada y/o salida de otros procesos. En esta propuesta se trabajará únicamente con los paquetes de despliegue de Gestión del Proyecto, Entrega del Producto y Análisis de Requisitos. En la Figura 3 se muestran los artefactos requeridos en los procesos/actividades de los Paquetes de Despliegue seleccionados.

Figura 3. Artefactos requeridos en los procesos/actividades de los Paquetes de Despliegue seleccionados.

La Figura 4 muestra las dimensiones que se sugiere deberían satisfacer cada uno de los

artefactos de los Paquetes de Despliegue seleccionados. Por cuestión de espacio de este

trabajo, la descripción de cada una de las relaciones es omitida.

Page 65: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

65

Figura 4. Dimensiones aplicables a los artefactos de los Paquetes de Despliegue.

Metadatos

Analizando los artefactos, se propone un conjunto de metadatos (ver Figura 5), los cuales

son comunes a la mayoría de los artefactos de los paquetes de despliegue seleccionados.

Page 66: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

66

Figura 5. Conjunto de metadatos comunes para los PD seleccionados.

Cabe mencionar que este conjunto puede ser aplicable para el resto de los paquetes de

despliegue, siempre y cuando se identifiquen e incluyan los metadatos específicos para

cada artefacto.

CONCLUSIONES

El presente trabajo propone un modelo de calidad de datos que puede ser aplicado durante

los diferentes procesos de desarrollo de software. Este modelo se enfoca en la calidad de

los artefactos de los Paquetes de Despliegue de la parte 5 del estándar ISO/IEC 29110; el

modelo afecta de manera directa a los metadatos que describen a los artefactos, ya que

aplicados de forma adecuada brindarán una mejor referencia al curso de los procesos

involucrados en el desarrollo de software en las PO, así mismo, aproximará a las PO a

competir con empresas de mayor nivel, ya que al aumentar la calidad de los datos aumenta

la calidad de sus procesos así como la de sus productos y/o servicios.

RECONOCIMIENTOS

“Se agradece al Programa para el Desarrollo Profesional Docente (PRODEP) por el apoyo al profesor (UASLP-PTC-627) y al alumno, a través del proyecto asignado 511-6/18-8708”.

Page 67: MEJORA DE PROCESOS DE SOFTWARE CONSIDERANDO …salinas.uaslp.mx/Documents/Tesis/Maria Cortez Soriano.pdf · 29110 involucrados en el desarrollo de software en PO. Se pretende que

67

REFERENCIAS:

[1] Acebo Plaza, M., Núñez, A., Villavicencio, M., Rodríguez, J., & Quijano, J. (2017, enero). Orientación estratégica para la toma de decisiones, Industria de Software. Estudios Industriales, Escuela Superior Politécnica del Litoral ESPOL, 45 p.

[2] Saavedra G, Maria L. & Yolanda Hernández C. 2008. “Caracterización e importancia de las MIPYMES en Latinoamérica: Un estudio comparativo.” Actualidad Contable Faces, Julio, pp. 122–134. [3] Pino, F. J., García, F., & Piattini Velthuis, M. G. (2006). Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software, 2(1), 6–23. [4] Cornejo, A. (2015, enero). ISO 12207. Recuperado de: https://normasyestandaresproyectosti.wordpress.com/2015/01/29/iso-12207/ [5] ISO. (2018, July). International Organization for Standardization, ISO/IEC/IEEE 15289:2017 Systems and software engineering -- Content of life-cycle information items (documentation). Recuperado de: https://www.iso.org/standard/71950.html [6] nyce. (2018, June 20). ISO/IEC 29110. Obtenido de https://www.nyce.org.mx/ertificacion-iso-29110/ [7] Comité Técnico de Normalización de Ingeniería de Software y Sistemas de Información. (2012). Ingeniería De Software. Perfiles del ciclo de vida para las pequeñas organizaciones (PO). Parte 5-1-2: Guía de gestión e ingeniería: Grupo de perfil genérico. Perfil básico. En Norma Técnica NTP- ISO/IEC RT 29110-5-1-2 Peruana 2012(83). Lima, Perú: R.00xx-2012/CNB-INDECOPI. [8] T&C Innovation Services S. (2018). ISO 29110. Obtenido de http://e-processmexico.com/consultoria/iso-29110/ [9] Cai, L. & Zhu, Y., (2015). The Challenges of Data Quality and Data Quality Assessment in the Big Data Era.

Data Science Journal. 14, p.2. http://dx.doi.org/10.5334/dsj-2015-002

[10] International Organization for Standardization. (2008). ISO/IEC 25012: Systems and software engineering

-- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models. Obtenido de https://www.iso.org/standard/35733.html.

[11] iso25000.com. (2018). ISO/IEC 25012. Obtenido de https://iso25000.com/index.php/normas-iso-25000/iso-

25012.