Documentos de Académico
Documentos de Profesional
Documentos de Cultura
implementadas por seres humanos y por ende en cualquiera de sus etapas de creación se puede
entre otras. Si no se ha identificado ese defecto y el software o la aplicación se ejecuta, hay un alto
riesgo de que la aplicación no haga lo que debería hacer o el objeto para lo cual fue creada, es
decir se genera un fallo o desperfecto, lo que podría generar una catástrofe como las que se han
mencionado en este documento y muchas otras más, es importante conocer que los fallos
también
se pueden presentar por situaciones del entorno, como la radiación, descarga eléctrica,
Administración: Establecer un plan de trabajo, darle seguimiento para ver que se cumpla y
en caso de que no, resolver los problemas que detengan el avance del proyecto.
Requerimientos: Hay que establecer y acordar los requerimientos en una etapa temprana
del proyecto, aunque no se puedan definir en su totalidad, al menos hay que buscar tener
definida la mayor parte del proyecto o bien, tener bien definida la primera parte que se va a
desarrollar.
Diseño: Mantener el diseño simple y útil, realizando únicamente lo necesario para ayudar
tipos de diagramas UML, pero en realidad no es necesario utilizarlos todos, sobre todo en
un desarrollo ágil, muchas veces con los diagramas de flujo, de secuencia o ambos bien
diseñados es más que suficiente como base para la codificación.
común en las empresas pequeñas es aventarse a programar antes de seguir las prácticas
de los puntos anteriores. Existen muchas prácticas de programación que hay que seguir,
como son el uso de nomenclaturas, pruebas de humo, revisión en pares y las propias de
todos los artefactos relacionados al proyecto, por ejemplo, la documentación del proyecto.
ya que existen muchos tipos de pruebas, como puede ser de interacción con otras
aplicaciones ajenas al proyecto o de performance, pero que nos puede dar visibilidad de
que el proyecto funcione o no. El error más común al realizar las pruebas, es encontrar uno
Dependencias: Todos los proyectos tienen dependencias, por lo general los proyectos
fácil prevenirlas, por ejemplo, por lo regular los desarrollos de software requieren de
infraestructura tecnológica, contar con información para realizar testing, permisos de otros
algunas.
c. ¿Cómo cree usted que el cliente percibe si un producto de desarrollo de software tiene
buena calidad? Sustente la respuesta.
El estándar ISO/IEC 9126 presenta la calidad del software como un conjunto de seis
características globales:
Funcionalidad. Las funciones del software son aquellas que buscan satisfacer las
grupo de usuarios.
modificaciones específicas.
otro.
varía de un sistema a otro, dependiendo del tipo de software que se va a desarrollar, para
determinar su utilidad e idoneidad. Este desarrollo debe ser confiable, mantenible y flexible para
calidad.
A través del modelo EPCU es posible determinar un valor cuantitativo consistente, de manera
formal y que nos permita hacer comparaciones acerca de la calidad de los productos de software
de una manera práctica.
Este modelo permite evaluar a partir del juicio de experto, mediante mecanismos formales de
manejo de información imperfecta y con base en el estándar de calidad ISO/IEC 25000, la calidad
de los productos de software tanto desde el punto de vista de su construcción (calidad interna)
como desde el punto de vista del usuario (calidad externa).
Debido a que el índice de calidad es consecuencia de los distintos valores de las categorías
definidas por el estándar, es posible determinar estrategias relevantes y factibles para
incrementar el índice de calidad a través de mejorar las categorías de calidad.
El poder tener un valor cuantitativo de calidad, sin duda, dará certeza al usuario, sobre todo si el
también participa en la evaluación de la calidad externa del producto de software.