Sistemas de Calidad – Conceptos y definiciones

¿En qué consiste la Norma IEEE 830?, ¿a qué etapas del proceso de SW se enfoca, y cuál es la importancia de su empleo? Considerando la norma IEEE 830, ¿Qué debe contener el ERS?, menciona al menos 5 contenidos, y justifica la importancia que tiene para sus usuarios, el incluirlos.

  • Consiste en especificar los requerimientos del cliente de forma detallada, donde no exista ninguna ambigüedad con el fin de satisfacer las necesidades que el cliente necesita.
  • Se enfoca a la etapa de planificación, donde se vacían todas las especificaciones de los requisitos del software, esto tiene una gran importancia debido a que con esto se crea una documentación extensa, donde se encuentra todo lo que el sistema deberá de tener, haciendo mucho más fácil su elaboración porque funge como guía.
  • Debe contener gran cantidad de información, entre las que se encuentran la justificación del problema, en este apartado se define como y porque el sistema estará brindando la solución a la petición del cliente, es muy importante porque te da una visión general en lo que el sistema estaría cubriendo para dar solución al problema, también debe contener el alcance del sistema, es decir hasta donde el sistema va a ser funcional para brindarle la solución a la problemática que presenta el cliente, es vital colocar el alcance, así los usuarios estarán consientes hasta donde será el límite del software. 
  • Otro apartado que debe de tener es la del personal involucrado, quienes serán los encargados de desarrollar de inicio a fin el sistema, se hace con el fin de que los usuarios tengan especificados la labor de cada uno de los involucrados, una cosa muy importante es que tengan premisas y restricciones, aquí se colocan las limitantes que tendrán los involucrados, hasta donde les toca desarrollar el proyecto en general y es valioso ya que los usuarios se limitaran a estos puntos para darle finalización al proyecto. Por ultimo también una de las cosas que debe tener son los criterios de éxito del proyecto, con el fin de que los usuarios vean que herramientas se utilizaran para que el proyecto pueda ser finalizado satisfactoriamente.

Desde el punto de vista de su uso, explica la diferencia que existe entre el Project Chárter, y el ERS; y explica por qué el ERS, podría servir de base para el contrato de un proyecto de SW.

  • Tienen similitudes pero cada uno cuenta con sus particularidades, el ERS involucra a todos los que participan en el proyecto, además especifica cuánto cuesta el sistema, por otra parte es especulativo, brinda una propuesta de solución a lo que pide el cliente en general describe cómo se va hacer el sistema, en cambio el Project Chárter menciona quienes van a ser los responsables del proyecto y es exclusivamente para una gestión interna ya que cuenta con métricas de trabajo mencionando quien va hacer cada actividad y cuanto costo va a tener el realizarla. 
  • Al igual que el Project chárter el ERS puede funcionar como base de inicialización del proyecto porque cuenta de alguna manera con auditorias con los involucrados incluyendo el cliente, al igual para él le quedaría más claro cómo va a estar desarrollado el sistema cubriendo los lineamientos que pidió.

Una vez definidos los requerimientos del sistema, ¿cómo se podría afrontar el cambio de éstos por parte del cliente (ya sea en alcance, definición, o asignación de recursos) ?, da al menos 2 opciones factibles y justifícalas.

  • 1. Reajustar el proyecto a los cambios. Enfocarse en los requerimientos más importantes del sistema y únicamente trabajar con ellos, cubrir los requerimientos con mayor grado de nivel, siempre y cuando se llega a un acuerdo por ambas partes, tanto el cliente como la empresa desarrolladora.
  • 2 Trabajar con el sistema. Al presentarse una situación de cambios respecto al alcance (tiempo, costos y calidad), otra opción viable para esto, sería terminar el proyecto, tal y como le planeo desde el inicio y hablar con el cliente, dejando en la mesa los puntos que por parte de la empresa se cubrieron y los que se cubrieron por parte de él, así como los que faltan por cubrir, ya sea monetario, de esta forma, al cliente se le informa que aún tiene una deuda, la cual deberá cubrir a cambio de lo que se le entrego.

Explica a qué se enfoca, y cuál es la importancia de aplicar la norma ISO/IEC 26514:2008 en un proyecto, así como las etapas del proceso de SW donde puede aplicarse.

  • Se enfoca en ayudar a los diseñadores y desarrolladores a definir el proceso de clasificación de la documentación del software, es decir, se encarga de cubrir las necesidades de cualquier persona que utiliza aplicaciones de software, teniendo la información precisa sobre el mismo lo cual puede ayudar a un usuario, estableciendo los requisitos mínimos para la estructura, el contenido de la información y el formato de la documentación de usuario.
  • Las etapas en las que se puede trabajar esta norma son las implicadas en el diseño, especificando y en la elaboración de la documentación de usuario dividendo estás etapas en dos partes: la primera abarca el proceso de documentación de usuario para los desarrolladores y diseñadores. En él se describe como establecer lo que necesitan los usuarios y la información que deben de conocer. La segunda parte establece los requisitos mínimos para la estructura, el contenido de la información y el formato de la documentación de usuario.

¿Qué consideraciones se deben tener al desarrollar documentación en un proyecto de SW, y por qué?, y ¿qué atributos de calidad se impulsan al aplicar estas consideraciones, y cómo lo hacen?

  • No haya tecnicismos. Que la documentación se presente clara y concisa, que el usuario entienda fácilmente como está conformado el sistema y que acciones puede realizar en el mismo.
  • Ambigüedad en la información. Que la información que se presente en la documentación no pueda ser tomada a varios modos de interpretación, que el cliente entienda claramente el porqué de cada módulo del sistema y como trabajar con él, así como, que esté al tanto de qué manera se conforma el sistema y que se puede hacer en caso de errores mínimos.
  • Los atributos que se implican al cubrir estas consideraciones son la usabilidad y la factibilidad. La usabilidad lo que hace es que al entregar una documentación limpia y aplicando las consideraciones, le genera al usuario una facilidad de uso y entendimiento, haciendo posible que todas las dudas que se tengan acerca del sistema se puedan entender rápidamente con la documentación. Por su parte, la factibilidad, lo que ayuda es a que toda la información que se presente, apruebe la realización de cada actividad que muestra, otorgando seguridad a la documentación.

Justifica el uso de Modelos de Proceso por parte de las empresas, y la importancia que tiene para éstas la obtención de certificaciones en sus procesos.

  • Se proporcionan las bases para realizar una comparación de lo que actualmente se está elaborando en el proceso con lo que se tiene establecido.
  • A través de la experiencia cada tarea se va mejorando, especificar con que tarea se logró el éxito del proceso y cómo fue que se realizó ésta y finalmente estandarizar el proceso.
  • Se conoce la dirección del proceso, en pocas palabras la finalidad con la cual se creó este proceso y que partes de este apoyaran el proyecto.
  • Proporciona apoyo para mejorar el proceso.
  • Monitorear y coordinar el proceso para proveer ayuda en su medición.

Explica la razón del origen de CMMI, y define los 5 niveles que lo componen.

  • Se originó debido a que el modelo CMM se enfocaba solo a cubrir unas partes de planeación de estrategias de mejora, en cambio el modelo CMMI integro todas estas herramientas con el fin de mejorar los procesos para llegar a una mejora continua dentro de cualquier empresa.
  • Inicial (no se encuentran definidos los procesos y su nivel corporativo es muy ineficiente)
  • Repetible o gestionado (aquí se establecen los procesos de administración, al igual de los objetivos específicos y generales de la empresa, se encuentran proyectos planificados y se crean los hitos para revisiones de mejora)
  • Definido (en este nivel es donde ya los objetivos del nivel 2 se han cumplido, existen procesos comprendidos, hay una participación de todos y se conocen los procesos)
  • Administrado (se establecen los objetivos de calidad, existen medidas de procesos analizadas y hay estudios de estadísticas)
  • Optimizado (en el último nivel es donde la mejora continua está presente, ya hay una reducción en los costos de proceso y se le da seguimiento a cada proceso para la mejora constante)

Explica cómo surge y a qué se enfoca el Modelo SPICE (Norma ISO/IEC 15504). SPICE se creó para realizar una evaluación y mejora del software donde sea aplicable a cualquier organización, para ser utilizada como una herramienta de evaluación además de que es independiente de la organización, el modelo de clico de vida, de la metodología y de la tecnología.

  • En 1991. Fue creado por el Comité Internacional de estándares de Ingeniería de Software y Sistemas a través de su Grupo de Trabajo sobre Evaluación de proceso, para investigar la necesidad y los requisitos para un estándar.
  • En 1995. Se creó el primer borrador (Fase 1), donde su objetivo era validar las decisiones de diseño y usabilidad.
  • 1996 – 1998. Fase 2, Proveer una guía de aplicación y revisar la consistencia, validez, adecuación, usabilidad y portabilidad de SPICE.
  • 1998. Fase 3, se realizó con la idea de aportar entradas y publicar el estándar ISO es aquí donde se cierra el proyecto SPICE

SPICE se enfoca a:

  • Desarrollar un borrador de trabajo para un estándar de evaluación de procesos de software.
  • Llevar a cabo los ensayos de la industria de la norma emergente.
  • Promover la transparencia de tecnología de la evaluación de procesos de software a la industria del software a nivel mundial.

Explica cómo surge Moprosoft, es decir cuáles son las razones que originaron la importancia de contar con un modelo mexicano, y cómo esto impulsa la Competitividad en la Economía Mexicana. Define en grandes rasgos la diferencia entre Moprosoft y Competisoft. Explica en qué consisten los 3 niveles de Moprosoft.

La Dra. Hanna Oktaba  cuando era presidente en AMCIS (“Asociación Mexicana para la Calidad en Ingeniería de Software”) junto con sus compañeros comenzaron a entrevistar algunas empresas y concluyeron que las empresas mexicanas se catalogan como MyPEs (Micro y Pequeñas Empresas) y las capacidades están en un estándar 1, concluyeron que las empresas querían un estándar que se acople a lo que hacen y que este mismo sea mexicano.

Comenzaron a revisar los modelos de procesos en base a esos requerimientos de ISO9000:2000, CMM-SW, ISO12207, ISO15504 y la versión inicial de CMMI. Ante a esta situación ninguno de estas normas cumplía lo que las empresas mexicanas buscaba por lo que la doctora y sus colaboradores lanzaron un proyecto a la SE (Secretaria de Economía) para lo que entre septiembre y diciembre del año 2002 generarían MoProSoft (Modelo de Procesos para la Industria de Software) para lo que la SE en junio del 2003 hizo público el proyecto. Las organizaciones con este estándar generan y elevan sus niveles de capacidad y no morir en el intento.

Moprosoft tiene 3 niveles los cuales son:

  • Alta dirección: Aquí se gestiona el negocio, el por qué fue creada la organización, los objetivos considerando las necesidades de los clientes.
  • Gerencia: Está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos
  • Operación: Está integrada por procesos de administración de proyectos específicos (cumplir con los objetivos y establece costo y tiempo de los proyectos) y mantenimiento de software (Pruebas del software como análisis, diseño, construcción, integración)

La diferencia que tiene moprosoft y competisoft es que el primero se dedica a que las empresas mexicanas desarrolladoras de software se estandaricen para la mejora de sus procesos en cambio competisoft tiene como objetivo que las empresas sean competitivas no solo para empresas mexicanas sino para empresas pequeñas y medianas de iberoamerica.

¿Qué certifica ITIL?, y ¿qué se define como un servicio en ITIL?; razona si existe alguna diferencia entre la definición per se para Proyecto de TI, con la definición de un servicio de TI de ITIL.

  • ITIL se encarga de certificar personas para lograr que realicen de mejor manera los procesos correspondientes,  un servicio de ITIL se define como es un conjunto de mejores prácticas y recomendaciones para la administración de procesos, donde el usuario solicita y busca algún cambio menor por ejemplo un cambio de contraseña o que se le provean servicios comunes a otro usuario, también se encarga de la gestión de los recursos que se ofrecen.
  • ITIL guían a los proveedores internos en la planeación, entrega y administración de servicios de TI de calidad. Al tratarse de un conjunto de mejores prácticas y no de una metodología per se, la implantación de los procesos ITIL es diferente entre diversas organizaciones.
  • Un servicio de ITIL va enfocado a cualquier actividad, ya sea servicio, producto, etc. Enfocado al área de tecnologías de la información por muy grande o pequeño que este sea, se diferencia de un proyecto TI por que el proyecto contiene un conjunto de actividades y no necesariamente todas al área de TI.

Para mas información consulta lo siguiente: