IDENTIFICACIÓN DE LOS PUNTOS CRÍTICOS DEL SISTEMA DE INFORMACIÓN EN

DESARROLLO

Cristhian Danilo Carrillo Mendoza

SERVICIO NACIONAL DE APRENDIZAJE SENA

TECNÓLOGO EN ANÁLISIS Y DESARROLLO DE SISTEMAS DE
INFORMACIÓN
01 de abril. del 2019
 IDENTIFICACIÓN DE LOS PUNTOS CRÍTICOS DEL SISTEMA DE INFORMACIÓN EN
DESARROLLO

Cristhian Danilo Carrillo Mendoza

Instructor
Luis Alberto Pava Carmona
Ingeniero de Sistemas, Especialista en Desarrollo de Software.

SERVICIO NACIONAL DE APRENDIZAJE SENA

TECNÓLOGO EN ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
01 de abril. del 2019

2
Tabla de contenido

1. Introducción................................................................................................................ 4
2. Identificación de los puntos críticos del sistema ........................................................... 5
3. Glorasio .................................................................................................................... 12
4. Referencias
Luis Alberto Pava Carmona ................................................................................................. 2

1. INTRODUCCION

3
La identificación de los puntos críticos del sistema de información en desarrollo, es fundamental para
cumplir las expectativas del cliente, en vías de solucionar la problemática planteada, para ello es de
suma importancia que los StakeHolders o partes interesadas sigan estrictamente las normas,
buenas prácticas, estándares de calidad, modelos, tiempos, etc., puesto que a medida que se avanza
en el ciclo de vida del software, son muchos los factores que influyen en que el resultado final no sea
el esperado, si no se siguen los lineamientos de desarrollo tenidos en cuenta para cumplir las tareas
u objetivos del proyecto.

Para que en el desarrollo del proyecto no haya inconvenientes de este tipo, es importante establecer
los posibles errores y como solucionarlos con una propuesta objetiva, clara y realizable.

Hoy día se pueden gestionar la calidad de un sistema de información a partir de estándares de

calidad como:

 ISO/IEC 9000-3
 ISO/IEC 9004-2
 ISO/IEC 9126
 ISO/IEC 1091
 ISO/IEC 12207
 ISO/IEC 14598
 ISO/IEC 15504
 ISO/IEC 25000
 ISO/IEC 27001:2013
 IEEE 830-1998

Esta es una lista de los muchos estándares que hay hoy día para gestionar la calidad del software,
hay que aclarar que en la práctica no se pueden utilizar todos al tiempo, no se trata de eso, sino
simplemente identificar las condiciones del proyecto y partiendo de esto se implementa el estándar
más adecuado.

2. IDENTIFICACION DE LOS PUNTOS CRITICOS DEL SISTEMA DE INFORMACION

4
ITEM PROPUESTA EVITAR ERROR
1 El analista es el responsable de la documentación, por lo que debe ser el mismo analista el que  Desviación intencional de
trate de asegurarse de que no hay lagunas de comprensión o puntos grises, visto que desde los requerimientos del
el comportamiento humano el cliente puede asumir algo diferente de lo que cree el analista cliente.
que se requiere, tener esto en mente es muy importante para evitar ambigüedades y que las  Requerimientos erróneos o
partes interesadas interpreten la documentación de la manera incorrecta. incompletos.

En el desarrollo del proyecto SIGEF (Sistema Gestor de Farmacia), la especificación de

requerimientos es fundamental por ello se aplica el estándar IEEE 830-1998 para la ERS
(Especificación de Requerimientos de Software), con el fin de documentar los acuerdos entre
el cliente y el grupo de desarrollo, sin desviar intencionalmente los requerimientos del cliente
por X o Y motivo, esto para cumplir con las exigencias estipuladas y así describir los
Requerimientos del Sistema Información de forma clara, precisa y concisa,

También se opta por realizar los diagramas de casos de usos, que aportan a la mejor
comprensión de los requerimientos del cliente, ya que estos se enfocan en que la solución
planteada para el problema específico sea entendida por todas las partes interesadas, por
medio de un lenguaje grafico estandarizado como lo es UML.

Así como hay RF que se tratan de “lo que hace” el sistema, también hay RNF que se tratan de
“como lo hace”, siendo estas características del sistema como la seguridad, escalabilidad,
mantenibilidad, robustez, usabilidad, disponibilidad, estabilidad, rendimiento, etc.
Prácticamente para la correcta especificación de los requerimientos, se propone tener en
cuenta los siguientes factores:

 Documentar los RF Y RNF aplicando el estándar IEEE 830-1998.

 Usar Diagramas de casos de uso para la identificación de requerimientos.
 Analizar la lógica del cliente, y hacer que detalle las funcionalidades del sistema.
 Identificar como cumplir los RNF.
 Seguir el estándar de calidad ISO/IEC 9000-3 para el desarrollo del Software.

En cualquier caso, tanto los RF como los RNF deben estar siempre documentados, incluso si es
difícil establecer la relación entre ellos. Esto ayudará al equipo a reducir las discusiones de ida y
vuelta, ahorrar tiempo y, sobre todo, problemas innecesarios con el cliente.

2 En la representación de datos es imposible prever todos los factores que pueden ocasionar  Error en la representación
errores en el desarrollo del proyecto SIGEF, aun así, es importante planificar de forma de los datos.

5
 cuidadosa las distintas maneras de afrontar estos problemas, además hay que tener en cuenta
tres factores:

1. Existen muchos factores que pueden causar errores o fallos en la estructura de datos.
2. En algunos patrones de modelado se pueden tener determinados errores.
3. En ocasiones el equipo de desarrollo le puede atribuir esos determinados errores a
algún tipo de patrón de modelado, por ello se debe investigar cuales son los patrones
de modelado que causan este tipo de errores, con qué frecuencia, específicamente
que componente del patrón lo causa y como evitar estos errores esto con el fin de
evitar la pérdida de recursos por este tipo de problemas,

Como propuesta para evitar estos problemas, es vital seguir los siguientes modelos para la
estructuración de los datos del sistema de información, e identificar los componentes de estos
que causen problemas a la hora de representar los datos.

 Modelo Entidad Relación Extendido.

 Modelo Relacional.
 Modelo Físico.

Cada uno de estos modelos tiene una estructura técnica para representar de la manera
correcta los datos, aunque hay que tener en cuenta que en el modelado de datos se pierde
eficacia y utilidad cuando; Se sobredimensionan los datos o Falta claridad y definición del
propósito de los datos.

Para lograr una exitosa representación de los datos sin errores, el analista o grupo de desarrollo
se deberán ceñir a los siguientes puntos:

1. Comprender la naturaleza de los datos con los que se va a trabajar.

2. Evitar que el modelado de datos se lleve a cabo de forma simultánea con el desarrollo de

software.

3. Tener claras las necesidades del negocio.

4. Basarse en un enfoque ágil para el diseño y desarrollo del modelado de datos.

5. Recordar que es la información contenida en los datos la que da sentido a las aplicaciones, y

no al contrario.

3 A medida que se avanza cada vez más en el proyecto, se toma conciencia sobre la aplicación  Pruebas de software
de pruebas de software, siendo estas necesarias para el cumplimiento de los requerimientos incompletas o erróneas.
del cliente, algunas pruebas son manuales, otras automáticas o con enfoques diferentes,

6
 también pueden tener varios niveles, existen muchos tipos de pruebas, estas se dividen en
funcionales y no funcionales, algunas de ellas son:

Pruebas Funcionales: Pruebas No Funcionales:

 Pruebas Unitarias.  Pruebas de compatibilidad.

 Pruebas de Integración.  Pruebas de seguridad.

 Pruebas de Componentes.  Pruebas de Stress.

 Pruebas de Funcionalidad.  Pruebas de usabilidad.

 Pruebas de Sistema.  Pruebas de rendimiento.

 Pruebas de Humo.  Pruebas de internacionalización y

 Pruebas Alpha. localización.

 Pruebas Beta.  Pruebas de escalabilidad.

 Pruebas de Regresión.  Pruebas de mantenibilidad.

 Pruebas de Aceptación.  Pruebas de instalabilidad.

 Pruebas de portabilidad.

Como propuesta y con el fin de evitar pruebas incompletas o erróneas, es importante que el
programador cuente con las competencias técnicas necesarias para dicha tarea, ya que es más
seguro que el programador con experiencia en este terreno se desempeñe mejor, que uno sin
experiencia, para así evitar pruebas incompletas o erróneas, es importante que el programador
encargado de esta tarea retroalimente a los demás, para que en conjunto se realicen las tareas.

Utilizar herramientas para la realización de pruebas de cualquier tipo es clave, ya que estas
buscan mejorar la calidad del software en desarrollo, estás pueden ser utilizadas como:

1. Herramientas de gestión de pruebas

2. Herramientas para pruebas funcionales
3. Herramientas para pruebas de carga y rendimiento

Debe tenerse en cuenta que hay herramientas de Software Libre, Código abierto, Software
Privado, partiendo de ello es recomendable utilizar las que más se ajusten a las necesidades
del proyecto, en el caso del proyecto SIGEF (sistema gestor de Farmacia), se opta por la
utilización de herramientas gratuitas.

4 Este caso tiene mucho que ver con el ACS (aseguramiento de la calidad del software), este se  Documentación inexacta o
compone por herramientas, métodos, estándares y técnicas para gestionar la calidad de un incompleta.
proyecto, con el fin de controlar diferentes aspectos del ciclo de vida del mismo, entre ellos la
gestión de documentación, esto para evitar DII (Documentación Incompleta o Inexacta),

7
 permitiéndonos controlar la calidad de la documentación y su trazabilidad, el ACS está
diseñado para acoplarse a cualquier metodología de desarrollo y de esta manera administrar
la calidad en el desarrollo de un proyecto.

La propuesta para el aseguramiento de la calidad del software debe contener:

1. Un proceso de ACS.
2. Tareas específicas de aseguramiento de la calidad y control de la calidad.
3. Prácticas eficientes de ingeniera de software (métodos y herramientas).
4. Control de todos los productos del trabajo de software y de los cambios que sufren.
5. Un procedimiento para garantizar el cumplimiento de los estándares del desarrollo
de software.
6. Mecanismos de medición y reporte.

A través del ACS no se busca solamente evitar todo tipo de errores, si no también mejorar continuamente
los procesos en el desarrollo de software por medio de la recolección y análisis de los errores.

Se propone un control de trazabilidad, asociado a identificar los diferentes documentos o

artefactos en un desarrollo de software, podrían causar problemas y por lo tanto perjudicar en
la calidad del producto. A través de IR-Kanban, que es un sistema de codificación del cual se
puede obtener un correcto control de la documentación asociada al proyecto como: ERS,
Diagramas de flujos, casos de uso, entre otros. Ayudando a identificar diferentes aspectos a
través de los sub códigos que lo componen.
5 Para el correcto funcionamiento de la interfaz de usuario, se tiene como objetivo el  Interfaz de usuario
cumplimiento de los requerimientos funcionales como no funcionales, evitando inconsistencias inconsistente.
y permitiendo en un principio que está presente la información y permita introducir
información a la base de datos, esto a través su diseño planificado cuidadosamente para
satisfacer las necesidades del cliente,

Para un buen diseño de la interfaz de usuario y su experiencia se propone considerar los

siguientes factores:

 Respectar las convenciones.

 Simplicidad.
 Mantener la jerarquía visual.
 Experiencia de usuario.
 Diseño Escalable.
 Librerías de Estilos.
 Detalles.
 Documentación del diseño.

8
 Estos factores son posteriormente tenidos en cuenta en la realización del prototipo, con el fin
de que las partes interesadas puedan opinar respecto al diseño, depurando errores y
considerando las opiniones del usuario final.

Para la elaboración del prototipo en el caso del proyecto SIGEF, se utilizó la herramienta
Balsamiq mockups 3, además de borradores a mano que sirvieron de guía para establecer la
interfaz básica del sistema y su funcionamiento.

Enlace hacia el diseño del prototipo de la Interfaz del sistema SIGEF.

Mantener la consistencia de los diseños a medida que el proyecto evoluciona es un desafío

que requiere de mucha disciplina y organización. Cuando una interfaz no es consistente
corremos el riesgo de que el usuario final perciba confusión y frustración mientras navega,
comprometiendo los objetivos del proyecto.
6 Para evitar errores en el diseño lógico del sistema es necesario un análisis riguroso, utilizando Errores en el diseño lógico.
las herramientas técnicas a la mano para continuar con el diseño, siendo este realizado con
UML (Lenguaje de Modelado Unificado), el cual está compuesto por los siguientes diagramas
ordenados en orden de prioridad.

 Diagrama de actividades.
 Diagrama de Clases.
 Diagrama de Secuencia.
 Diagrama de Casos de Uso.
 Diagrama de Estados.
 Diagrama de Componentes.
 Diagrama de Despliegue.
 Diagrama de Objetos.
 Diagrama de Paquetes.
 Diagrama de Tiempos.
 Diagrama de Colaboración.
 Diagrama de Interacción.
 Diagrama de Composición.

Dentro de las características del lenguaje de modelado UML:

 Visualizar: UML permite modelar de una forma gráfica un sistema de forma que otro lo
puede entender.
 Especificar: UML permite especificar cuáles son las características de un sistema antes de
su desarrollo.
 Construir: por medio de los modelos especificados se pueden construir los sistemas
diseñados.

9
  Documentar: los propios elementos gráficos sirven como documentación del sistema
desarrollado, lo cual ayudará al mantenimiento de las soluciones conceptuales en el
transcurso del tiempo.

Algunas ventajas de usa UML.

 Mejores tiempos totales de desarrollo (de 50 % o más).

 Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
 Establecer conceptos y artefactos ejecutables.
 Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
 Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
 Mejor soporte a la planeación y al control de proyectos.
 Alta reutilización y minimización de costos.
 Fácil actualización o modificado del software a programar.

En el desarrollo del proyecto SIGEF (Sistema Gestor de Farmacia), se viene utilizando el

programa StartUML 3.1.0, el cual tiene soporte para todos los diagramas del estándar que
actualmente está en la versión 2.5.1.

7 A veces por no tener el conocimiento de la forma correcta de desarrollar cada diagrama de  Error en la traducción al
UML, se realiza la diagramación del sistema de la manera como el diseñador cree que se lenguaje de programación
utilizan las representaciones gráficas, diseñando un diagrama de la forma incorrecta. a partir del diseño.

Hay es cuando surgen errores en la traducción al código, una de las herramientas para el
diseño de diagramas UML es StartUML, está también genera el código a partir del diseño, esta
herramienta aliada de los programadores, puede ayudar en gran parte en la traducción de las
representaciones graficas a código, pero aun así eso no significa que el trabajo este hecho,
ayuda bastante pero pueden ocurrir diferentes errores en la traducción del código, por esto es
de suma importancia no solo revisar el código que se genera a partir de este tipo de
herramientas, si no hacer la gestión adecuada para que se cumpla con la funcionalidad del
sistema informático, como la calidad del código previniendo futuros reprocesos, perdida de
recursos, desgaste del personal o hasta la reestructuración del código.

10
8 Para prevenir la deficiente interpretación de la comunicación con el cliente se propone el uso  Deficiente interpretación
específico del Diagrama de Comunicación del estándar UML, con el cual podemos definir de la comunicación con el
claramente la comunicación del sistema con el cliente, permitiendo de esta forma estructurar cliente.
la lógica del negocio como la de presentación de datos e interfaz, respecto a las necesidades
del usuario final, además hay que considerar los factores del diseño de la interfaz para cumplir
con los requerimientos funcionales como no funcionales, esto para que el sistema de
información logre una comunicación armoniosa con el user.

11
 3. GLOSARIO

StakeHolders: también llamados partes interesadas son todas aquellas personas, entidades y grupos
implícitos directa o indirectamente en el desarrollo de un proyecto de software.

IEEE 830-1998: El estándar IEEE 830-1998 para el SRS (en inglés) o ERS (Especificación de
requerimientos de software) es un conjunto de recomendaciones para la especificación de los
requerimiento o requisitos de software el cual tiene como producto final la documentación de los
acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias
estipuladas.

ISO 9000-3: Es una norma derivada de la ISO 9001 dedicada al proceso de desarrollo con calidad del
software. Cuando se publicó la ISO 9001 resultaba difícil aplicar esta norma genérica a el proceso de
software por esta razón se creó la ISO 9000-3 para el desarrollo, implementación y mantenimiento del
software.

ISO/IEC 27001:2013: es una norma internacional emitida por la Organización Internacional de

Normalización (ISO) y describe cómo gestionar la seguridad de la información en una empresa. La
revisión más reciente de esta norma fue publicada en 2013 y ahora su nombre completo es ISO/IEC
27001:2013. La primera revisión se publicó en 2005 y fue desarrollada en base a la norma británica BS
7799-2.

12
 4. REFERENCIAS

 http://normiso9000.blogspot.com/2016/03/iso-9000-3.html
 https://soporteadsi.blogspot.com/2018/05/glosario.html
 https://www.redalyc.org/articulo.oa?id=92218339013
 http://estandarescalidadsoftware.blogspot.com/
 https://medium.com/@requeridosblog/requerimientos-funcionales-y-no-funcionales-
ejemplos-y-tips-aa31cb59b22a
 https://blog.es.logicalis.com/analytics/modelo-de-datos-los-errores-que-salen-mas-caros
 https://www.paradigmadigital.com/dev/tdd-como-metodologia-de-diseno-de-software/
 https://www.omg.org/spec/UML/About-UML/

13