Iarq-001 Protocolo de Indagacion Inicial de Un Sistema Informatico

Tipo Referencia Vigencia Página
Instructivo IARQ-001 1 de 15
Alcance: Arquitectura/Engineering Versión:1.0

Título: PROTOCOLO DE INDAGACIÓN INICIAL DE UN SISTEMA INFORMÁTICO
PROTOCOLO DE INDAGACION INICIAL DE UN SISTEMA

INFORMATICO
Historial Nombre y Apellido Cargo Versión Fecha Observaciones

Elaboración Arquitecto Core Inicial. Pasos del Método científico.
INTRODUCCION
El sector de Arquitectura / Engineering está enfocado en le esfuerzo de indagar

inicialmente todos los sistemas de la empresa, con el objeto de prever futuras
herramientas de migración hacia tecnologías que mejoren y optimicen lo existente.
Es con este fin que se desarrolla el documento presente, que se hace extensivo a los
referentes técnicos de los sectores considerados.
PROCEDIMIENTO DE INDAGACION
Para realizar las preguntas adecuadas en esta fase exploratoria, se ha tomado como
referencia la propuesta surgida desde la UTN (Universidad Tecnológica Nacional)
como MODELO DE PROTOCOLO PARA ANÁLISIS Y EVALUACIÓN DEL
SOFTWARE DESARROLLADO EN LAS PYMES ARGENTINAS (*).
Este modelo evalúa diferentes metodologías de software, y plantea un protocolo para

indagar el análisis del sistema inicial. A continuación, la serie de preguntas
inadagatorias que necesitamos sean respondidas:
PROTOCOLO DE INDAGACION INICIAL DE UN SISTEMA INFORMATICO
Le agradecería responda el siguiente cuestionario donde: Si es la respuesta

Si No NA NS/NC
correcta, No la negativa. N/A es No Aplica, y NS/NC es No Sabe o No Contesta.
DOCUMENTACIÓN INTERNA Y EXTERNA

1. ¿El usuario revisó el sistema y el manual del usuario considerando la
completitud y alcance?
2. ¿La terminología, las descripciones del menú y las respuestas del
sistema son consistentes con el programa?
3. ¿Es realmente fácil encontrar una guía dentro de la documentación o
de la ayuda del sistema?
4. ¿El diseño del documento (tipo de formato, tipo de letra, etc.) es
apropiado para comprender y asimilar rápidamente la información?
ASEGURAMIENTO DE LA CALIDAD
5. ¿Están documentadas todas las etapas del desarrollo?
El presente documento contiene información de NARANJA SA de carácter confidencial.

Nivel de Seguridad: Restringido| Uso Interno – Este documento deja de ser copia controlada una vez impreso.

6. ¿Se siguió un modelo de sistema documental?

7. ¿Se consideró cómo puede incorporarse la tolerancia a los defectos
para reducir al mínimo la probabilidad de que un defecto se transforme en
una falla?
8. ¿Es fácil mover el sistema desde una ubicación a otra o de un tipo de
computadora a otra?
9. ¿Se respetan los requerimientos definidos para la confiabilidad,
disponibilidad, facilidad de mantenimiento, seguridad y los restantes atributos
de la calidad?
10. ¿Existen actividades que puedan hacer que nuestro proceso sea más
eficiente para asegurar la calidad?
DEFINICIÓN DE REQUISITOS
11. ¿Se han especificado las interfaces externas necesarias?
12. ¿Se han especificado todos los recursos de hardware necesarios?
13. ¿Los requisitos están bien definidos? (no hay contradicciones, son
comprensibles, se especifica el rendimiento)
14. ¿Si el requisito se puede probar se han especificado las pruebas de
validación?
15. ¿Se han definido los criterios de aceptación para cada una de las
funciones definidas?
16. ¿Los requerimientos definidos fueron verificados con la
implementación del software?
DISEÑO
17. ¿Cubre el diseño todos los requisitos funcionales definidos?
18. ¿Es el diseño suficientemente detallado y sin ambigüedades como
para que sea posible implementarlo?
PRUEBAS FUNCIONALES (CAJA NEGRA)
19. ¿Es consistente el comportamiento del sistema con la información que
debe procesar y las funciones que se desarrollaron?
20. ¿Se probaron combinaciones específicas de datos (condiciones válidas
y no válidas) para evaluar el efecto que tienen sobre el sistema?
21. ¿Se han desarrollado casos de prueba en los valores límites, y apenas
arriba y debajo de estos?
22. ¿Se probaron una tasa de datos y un volumen de datos qué debe
tolerar el sistema?
23. ¿El sistema es sensible a determinados valores de entrada?
PRUEBAS ESTRUCTURALES (CAJA BLANCA)
24. ¿Se han probado en cada módulo todos los caminos independientes?
25. ¿Se corrió el software probando todas las condiciones lógicas?
26. ¿Se han ejecutado todos lo bucles en sus límites y dentro de sus
límites operacionales?
27. ¿Se han probado las estructuras de datos para asegura su validez?
OBJETOS
28. ¿Se han probado las operaciones de cada clase?
29. ¿Se examinó el desempeño al colaborar una clase con otra?
APLICACIONES WEB
30. ¿Tiene el sitio una forma de navegación fácil de entender?
31. ¿El sitio usa CSS (hojas de estilo en cascada) para todos los aspectos
de la presentación (fuentes, color, borde, etc.)?
32. ¿El estilo estético del contenido entra en conflicto con el estilo
estético de la interfaz?
33. ¿La Web utiliza en forma óptima el tamaño y la resolución de la
pantalla?
34. ¿Se realizaron pruebas para la compatibilidad de diferentes
configuraciones de
35. ¿Se realizaron pruebas para evaluar la facilidad de uso de una página
Web completa?
36. ¿La USN (Unidad Semántica de Navegación) se logra en su totalidad
sin error?
37. ¿Se han probado todas las rutas para acceder a la USN?
38. ¿Todo nodo de navegación se puede acceder dentro del contexto de


las rutas de navegación que define la USN?

39. ¿Existe un mecanismo para regresar al nodo precedente o al
comienzo de la ruta de navegación?
40. ¿Los mecanismos de navegación funcionan adecuadamente?
41. ¿Todos los nodos se pueden alcanzar desde el mapa del sitio?
42. ¿La Web es totalmente compatible con el sistema operativo del
servidor?
43. ¿La Web se ha probado con la configuración de servidor distribuido (si
existe uno) que se haya elegido?
44. ¿Se hicieron pruebas para descubrir errores entre la Web y la BD
(Bases de Datos) remota?
45. ¿Se realizaron pruebas que demuestren la validez de los datos brutos
que recibe el servidor Web?
46. ¿La Web está adecuadamente integrada con el software de base de
datos? ¿La Web es sensible a diferentes versiones del software de BD?
47. ¿El tiempo de respuesta del servidor se reduce hasta un punto donde
es apreciable e inaceptable?
48. ¿El sistema se degrada fácilmente o el servidor se desconecta cuando
se rebasa su capacidad?
CLIENTE/SERVIDOR
49. ¿Se ha probado las funciones de coordinación y de manejo de datos
del servidor?
50. ¿Se ha considerado el desempeño del servidor? (tiempo de respuesta
y procesamiento total de los datos)
51. ¿Se ha probado la exactitud e integridad de los datos en las
transacciones y almacenamientos del servidor?
52. ¿Se han realizado las pruebas de comunicaciones de red? (mensajes,
transacciones y tráfico de red de manera correcta)
INTEGRACIONES
53. ¿Existen codificaciones (encoding) a tener en cuenta entre ambientes
de integración? (ASCII-EBCDIC, español-inglés, localizaciones)
54. ¿Son necesarias transformaciones propias específicas de los datos a
nivel servicios o conectores?
55. ¿Son necesarios protocolos específicos a nivel conectores? ¿Están
soportados, son estándares conocidos e incorporables, hay que desarrollarlos
desde cero?
56. ¿Nivel de conformidades de seguridad (usuarios, perfiles, tokens)?
¿Verifica nuestro estándar en uso en la Software Factory? ¿Debe
incorporarse?
SISTEMAS DE TIEMPO REAL
57. ¿Se han hecho pruebas para el manejo de eventos (procesamiento de
interrupciones, temporización de datos, paralelismo entre las tareas que
manejan datos)?
58. ¿Se han asignado y manejado apropiadamente las propiedades de
interrupción?
59. ¿Se ha manejado correctamente el procesamiento de cada
interrupción?
60. ¿El desempeño de cada procedimiento de manejo de interrupciones
cumple con los requisitos?
61. ¿Un elevado número de interrupciones que llega en momentos críticos
crea problemas en la función o el desempeño del sistema?
AMBIENTE DE RED
62. ¿Se ha probado la memoria requerida durante un enlace?
63. ¿Se han probado los recursos requeridos durante un enlace?
64. ¿Se ha probado la arquitectura y el desempeño de la red?
VERIFICACIÓN
65. ¿Se han creado los datos de prueba y métodos de prueba necesarios
para probar adecuadamente el software?
66. ¿Se ha desarrollado un proceso razonable para determinar si los
defectos fueron corregidos satisfactoriamente?
67. ¿Se puede llegar a un estado del sistema que debe ser evitado (como
por ejemplo por razones de seguridad)?


68. ¿Se consideró al programador en las pruebas de verificación y

validación del software de manera no exclusiva?
69. ¿La información respecto de cambios del software es recopilada y
documentada?
MANTENIMIENTO
70. ¿El software es fácil de mantener?
71. ¿Se hacen muchos cambios a los requisitos del software después de la
entrega del mismo?
Se pide que las respuestas sean: Correcta (Si), incorrecta o Negativa (No), No
Aplica (N/A), No Sabe o No Contesta (NS/NC). Abarcando con las múltiples
opciones todas las posibilidades que puede considerar quien completa el cuestionario.
También pensando en la claridad se usó un vocabulario sencillo y al mismo tiempo
estándar.
Tras la indagación inicial, y siguiendo el MÉTODO CIENTÍFICO PARA LA

RESOLUCIÓN DE PROBLEMAS (MC14), eventualmente se puede profundizar si
fuese necesario, hacia un análisis funcional general, en base a pasos. Anexo a la
presente, y son opcionales.
PROCEDIMIENTO DE ANALISIS FUNCIONAL
Dentro de la Arquitectura de Microservicios, existen principios que guían y permiten la

creación de una solución atractiva. Son los siguientes:
✓ La orientación a servicios como base

Consiste en proporcionar interfaces claramente definidas (servicios) con
una semántica de negocio clara y política de seguridad.
✓ Integridad de procesos a escala de Internet
Los procesos de negocio no se circunscriben a lo que ocurre dentro de la
empresa, sino también hacia afuera.
✓ Integración con competencias de negocio y sistemas de Backend
Integrar y controlar la frontera : este control incluye el seguimiento y la
aplicación de acuerdos de nivel de servicio (SLA) con socios y
consumidores.
✓ Uso de los estándares de la industria como base
Son los estándares de servicios (API y patrones), pudiendo soportar todas
las interacciones basadas en mensajes, interfaces, recursos (como REST)
o eventos.
Existen estándares específicos de canales.
✓ Aprovechamiento y ampliación de las tecnologías de código abierto
✓ Provisión de la plataforma para un entorno creciente


Como parte de la integración, necesariamente surgen temas de codificaciones

(encoding) y transformaciones propias, protocolos soportados, conformidades de
seguridad (usuarios, perfiles, tokens), etc., que se definen en cada estándar, y deben
identificarse su uso y eventual riesgo.
Particularmente en Arquitectura/Engineering, se implementa sobre esa visión de API –

Aplication Programming Interfaces, con microservicios REST, y partimos de tipos de
componentes de software ya específicos:
 Servicio (MS): exponer la puerta de entrada vía un publicador. El protocolo en

general más usado es (http/https) .
 Orquestador / Controlador (ORQ): orquestar o controlar el flujo de llamadas y

lógica entre servicios (microservicios).
 Conector (CON): conectar a repositorios internos o externos, como ESB/OSB, base

de datos, hardware, u otros sistemas externos, desde el orquestador / controlador.
El análisis funcional que identifique a cada uno de estos componentes a partir del
correspondiente diseño arquitectónico, debe detallar como mínimo:
 Servicio (MS):
o Nombre del Servicio
o Parámetros
o Tipo Respuesta
o Quien es su Cliente / Consumidor
o Usuario de conexión
o Qué Expone (WSDL, REST, otro?)
 Orquestador / Controlador (ORQ):
o Diagrama de Secuencia
o Diagrama de Flujo
o Umbrales
 Conector (CON):
o Tipo Conexión (página web, socket, base de datos…)
o Tipo Mensaje (xml, json, texto…)


o Usuario y Contraseña
o Dirección de publicación (URL)
o Credenciales de conexión-Token-ApiKey
o Protocolo
 de Red (IP u otro?)
 de Transporte (TCP,UDP, SSH, otro?)
 de Sesión (HTTP, FTP, Telnet, otro?)
 de Aplicación / Presentación (HTTP XML, FTP, Telnet, otro?)
o Seguridad (WS-Security, relación de confianza, VPN, otro?


ANEXOS Y REFERENCIAS
MODELO DE PROTOCOLO PARA ANÁLISIS Y EVALUACIÓN DEL SOFTWARE

DESARROLLADO EN LAS PYMES ARGENTINAS.
Por Martín Alejo VALIENTE, UTN , 2008.

http://posgrado.frba.utn.edu.ar/investigacion/tesis/MIS-2009-Valiente.pdf


MÉTODO MC-14.
Es una abreviatura de Método Científico consistente en 14 etapas.
Contenido
Las 14 Etapas del MC-14
Las 11 etapas principales
Las 3 etapas de refuerzos extra
El sistema completo de ciencia y la resolución de problemas
Paso 1: Observación curiosa
¿Qué se debe buscar?
Desarrollo de la curiosidad
Paso 2: ¿Existe algún problema?
Paso 3: Objetivos y planificación
Paso 4: Búsqueda, exploración y recopilación de pruebas
Buscar posibles soluciones
Paso 5: Generación creativa y alternativas lógicas
Paso 6: Evaluación de las evidencias o pruebas
Paso 7: Realización de hipótesis, conjeturas y suposiciones
Características y nomenclatura de las Hipótesis
Predicción de las consecuencias


Paso 8: Refutación o cuestionamiento de las hipótesis

Experimentación, testeo y desafío de hipótesis
Repetición de los experimentos
Paso 9: Realización de conclusiones
Características de la conclusión
Pensamiento crítico con nuestras conclusiones
Preparación de las conclusiones al público
Paso 10: Prórroga o dilación de afirmaciones o juicios de valor
Paso 11: Desarrollo de la teoría y envío a revisión por pares
Procedimientos en función del tipo de investigación
Ingrediente paso 12: Métodos creativos, lógicos y no lógicos y técnicos
Métodos no lógicos
Métodos lógicos
Métodos técnicos
Ingrediente paso 13: Objetivos del método científico
Ingrediente paso 14: Aptitudes y habilidades cognitivas
Habilidades cognitivas
PASOS DE ANALISIS GENERAL DE UN SISTEMA INFORMATICO
Paso 1: Observación curiosa
En muchos casos el problema o situación a analizar estará planteado, pero en otros casos
el área de Arquitectura deberá descubrir nuevos problemas en base a la observación y el
uso de instrumentos, herramientas, percepción, razonamiento, imaginación, etc.
Paso 2: ¿Existe algún problema?
En caso de que el problema no esté definido se procederá a definir el alcance del mismo.
Una vez que el problema/requerimiento está definido se deberá revisar que la Definición
del Requerimiento cumpla con los siguientes aspectos:
Aspecto a Explicación/Ejemplo Acción en

Considerar caso de in-
cunplimiento
Claridad El alcance debe estar claramente especificado y no debe ser Rechazar
ambiguo.
Completitud El requerimiento solicitado debe estar completo. Por ejemplo Rechazar

para el caso de una funcionalidad que contempla la creación
de una tabla histórica que se prevé tendrá un crecimiento
importante, se deberá contemplar el esquema de depuración
de dicha tabla caso contrario la definición del requerimiento
será incompleta
Funcionalidad No La funcionalidad requerida no debe existir en el mismo o en Rechazar

existente otro módulo, es decir no debe intentarse repetir una
funcionalidad ya existente.


Factibilidad de El requerimiento debe ser factible de implementar. Rechazar

implementar Considerar el siguiente ejemplo: Se sabe que las transacciones
on-line deben tener un tiempo de duración pequeño (máximo 2
segundos). No sería factible de implementar una transacción
on-line que sea costosa y que se prevea que va a durar por
ejemplo 60 segundos, en este caso se debe pensar en un
proceso Batch.
Ajuste a los El requerimiento debe satisfacer las necesidades del usuario y Rechazar
requerimientos del del negocio
Negocio
NOTA: En caso de rechazo de la actividad se deberá explicar el motivo y cuando sea

posible gestionar el cumplimiento del requerimiento con la persona que haya originado el
requerimiento.
Paso 3: Objetivos.
En caso de que la definición del requerimiento cumpla con lo establecido en la sección

anterior se continuará identificando claramente los Objetivos que se desean alcanzar con el
Análisis. Cada objetivo deberá iniciar con un verbo en infinitivo.
Paso 4: Búsqueda, exploración y recopilación de pruebas
Este es el centro del análisis/resolución del Requerimiento, se explorarán todos los puntos
de vista, fuentes de información y Antecedentes, tales como:
 Información estadística
 Informes realizados anteriormente
 Eventos ocurridos relacionados con el análisis solicitado
 Manuales
 Otra Información disponible en Internet
 Documentación Técnica (típicamente DER, DFD, Diccionario de Datos, Diagrama
Arquitectónico, etc.)
 Programas Fuentes
También se debe considerar el uso de herramientas, tales como:
 Repositorio de Código fuente (VSS, SVN, GIT, ...)
 Procedimientos Almacenados (SP) en Base de Datos
 Herramienta de Documentación / Autodocumentacion, Historias
 Ambientes de Desarrollo y Testing a los que tiene acceso Arquitectura/Engineering en
donde se pueden revisar estructuras, distribución de datos, ejecutar consultas (SQL),
analizar programas, monitorear ejecución de procesos, etc.
 Manuales de Estándares y Buenas Prácticas
En este punto es necesario empezar la búsqueda de soluciones con el uso de pensamiento

crítico.
Paso 5: Generación creativa y alternativas lógicas
En esta sección se describe como realizar el Análisis del Requerimiento /Problema. Se

pueden resolver muchos problemas por el mismo método que lo han sido muchos otros
descubrimientos; la prueba y error o usando un método sistemático, gradual y analítico de


razonamiento lógico. Se debe recopilar toda la información y agruparla o reordenarla hasta

que encaje.
 Razonamiento reflexivo
 Disparadores de idea
El razonamiento reflexivo: Se trata sencillamente de buscar, explorar, seguir las intuiciones,

recopilar los datos pertinentes, principios y conceptos básicos y ordenarlos mentalmente.
Buscar con esos datos en la memoria las conexiones existentes. Se puede cargar la mente
con todos los datos, después descansar, y luego comenzar de nuevo con la solución del
problema de una manera relajada. Cada parada y comienzo del problema hace que se
aborde inconscientemente el problema de forma diferente pero teniendo en cuenta la
experiencia anterior. Los resultados mejores se obtienen cuando el tiempo entre intento e
intento es lo suficientemente grande como para descansar la mente y lo suficientemente
corto como para que las ideas se tengan todavía frescas en la memoria.
Los disparadores de idea: Se trata de situaciones, comportamientos, objetos o palabras que

permiten simular la memoria o una parte de la memoria de datos que está almacenada y
disparar o desencadenar un tren de sucesos nuevos que no habían sido simulados por el
razonamiento reflexivo. Es por eso que primero es necesario cargar la mente con los datos
pertinentes usando el razonamiento reflexivo para que la idea pueda llegar a ser
desencadenada. Algunos disparadores de uso común son:
 Experimentación y visualización
 Tener discusiones o debates, opiniones
 Revisar los componentes del problema o lugares relacionados
 Brainstorm o tormenta de ideas
 Conferencias y exhibiciones acerca de temas relacionados
 Usar programas o software de ordenación de ideas.
 Describir por escrito la situación actual y revisión por parte de otros
Paso 6: Evaluación de las evidencias o pruebas
En esta etapa se realiza la pre experimentación y una verificación de las pruebas que se
han recopilado, de las fuentes de información, no de las predicciones finales o de la
inducción o solución planificada. Se formularán algunas Soluciones Propuestas en caso
que corresponda intervenir a los Arquitectos.
En el caso de ser necesario la elaboración/revisión del Diseño las soluciones propuestas se

deberán tener en cuenta los siguientes aspectos:
Aspecto a Explicación/Ejemplo Acción en caso de

Considerar incumplimiento
Tiempo de Respuesta Se deben diseñar soluciones que sean óptimas en su Rechazar
óptimo tiempo de respuesta
Cumplimiento de Referirse al documento de estándares de la Rechazar
Estándares de Diseño herramienta que se esté usando.


Análisis de Impacto Cuando se realiza algun cambio en el sistema, se Rechazar

Completo debe realizar un análisis para identificar todos los
componentes que pueden sufrir algún impacto por el
cambio realizado y posteriormente se deberán
identificar los cambios a realizar en cada uno de ellos.
Se deberán usar las siguientes herramientas:
Ambientes de trabajo habilitados para el equipo de
Arquitectura.
Programas almacenados en Visual Source Safe.
Herramienta de Documentación
Administrabilidad Capacidad de ser administrado y manejado. Por Rechazar

ejemplo crear una tabla de parametría a la que el
usuario no pueda acceder por front-end no permite
administrarla. Por lo tanto el diseño de esta tabla
debe contemplar la creación de una transacción de
Front-end para su administración.
Disponibilidad Grado de la continuidad operacional del sistema. Por Rechazar
ejemplo permitir que el cliente pueda realizar
transacciones 7x24 en la red de cajeros automáticos a
pesar de que el sistema esté off-line durante la
ejecución del Batch de fin de día.
Testabilidad Que pueda ser probado, verificado o examinado. Por Rechazar
ejemplo en caso de un proceso complejo y largo, dejar
tablas intermedias con subtotales para
posteriormente poder controlar y realizar seguimiento
de errores en caso de descuadres.
Seguridad Grado de seguridad del componente o sistema. Aplica Rechazar

en el caso de nuevas arquitecturas y servicios. Por
ejemplo en el caso de la generación de interfases de
salida (archivos planos) usar algoritmos de
encriptación de datos.
Trazabilidad Trazar o dejar huella de los movimientos y procesos Rechazar
por los que pasa un determinado producto
Concurrencia Diseñar procesos/componentes que puedan Rechazar

ejecutarse en paralelo con otros sin generar impacto.
Por ejemplo considerar el impacto negativo que puede
presentarse por lockeos en objetos.
Cumplimiento de Referirse al documento de Buenas prácticas de la Evaluar acción a seguir

Buenas Prácticas de herramienta que se esté usando.
Diseño
Robustez Capacidad de los productos de software de reacciónar Evaluar acción a seguir
apropiadamente ante condiciones imprevistas. Por
ejemplo verificar que el Diseño contemple la
posibilidad de reprocesamiento en caso de
cancelaciones imprevistas y que además procese solo
los registros no procesados (Proceso Reenganchable)


Escalabilidad Capacidad de expansión sin perder la calidad en el Evaluar acción a seguir

servicio. La expansión puede ser:
Funcional (por ejemplo crear más productos de forma
paramétrica)
Carga (que pueda soportar mayor carga por ejemplo
que un servicio pueda soportar mayor cantidad de
transacciónes por hora.
Integración (por ejemplo un servicio que pueda ser
usado desde otros sistemas)
Costo - Beneficio Considerar la viabilidad económica y del tiempo de Evaluar acción a seguir
implementación de la solución propuesta
Modularidad Subdividir un sistema en piezas más pequeñas que se Evaluar acción a seguir
puedan crear independientemente y después utilizar
en diversos sistemas para conducir funcionalidades
múltiples
Mantenibilidad Poder ejecutar una determinada operación de Evaluar acción a seguir

mantenimiento en el tiempo de reparación prefijado y
bajo las condiciones acordadas con el cliente. Se
deberá evitar el diseño de componentes complejos ya
que requieren un nivel alto de especialización y
tiempo alto para su mantenimiento.
Usabilidad Se refiere a la facilidad con que los usuarios pueden Evaluar acción a seguir
utilizar una herramienta o sistema
Reusabilidad Grado en que partes de una aplicación pueden Evaluar acción a seguir
utilizarse en otras aplicaciones. Por ejemplo la
creación de procedimientos y funciones que realicen
una tarea específica y que puedan ser reutilizados en
otras aplicaciones.
Posibilidad de Diseñar para poder deshabilitar o realizar rollback, es Evaluar acción a seguir
Deshabilitar decir que se pueda volver atrás fácilmente.
NOTAS:
- La columna “Acción en caso de incumplimiento” aplica para el caso de revisión por parte
de Arquitectura de Diseños elaborados por otras áreas. En caso de que está acción sea
“Rechazar” significa que es una falta grave y que el Arquitecto debe rechazar el Diseño
explicando el motivo.
- Los aspectos que tienen la acción “Evaluar acción a seguir” pueden en algunos casos
interpretarse como falta grave y en otros como falta leve, por lo que dependiendo de cada
caso en particular el Arquitecto deberá determinar si rechaza o si acepta el Diseño. Por
ejemplo puede haber un requerimiento en el que no es importante tener en cuenta en el
Diseño la Escalabilidad (por ejemplo una consulta de una tabla de parametría que se sabe
no tendrá más de 10 registros). Por el contrario pueden haber otros requerimientos en los
que la Escalabilidad es de suma importancia (por ejemplo el Diseño de un servicio de
Reentrada para la ejecución de transacciones).
Paso 7: Realización de hipótesis, conjeturas y suposiciones
Primero, es necesario revisar el paso 6 ya que la hipótesis final es la solución propuesta

para la más reciente definición del problema. En el paso 6 probablemente se habrán


descartado las soluciones menos probables obteniéndose la solución más fuerte (Solución
Recomendada).
Cuando la hipótesis principal ha sido elegida, es necesario realizar predicciones de por qué
y cómo algo ocurrirá, basándose en la precisión de las hipótesis. Verificar estas
predicciones permite probar, justificar, falsear y cuestionar la hipótesis en el paso 8. La
predicción de las consecuencias mediante la hipótesis o solución escogida es una parte
muy importante del método científico.
Paso 8: Refutación o cuestionamiento de las hipótesis
En el cuestionamiento de las hipótesis se deben tener en cuenta el grado o nivel del

desafío, es decir, el desafío o prueba que debe superar la hipótesis dependerá del tipo de
problema y su importancia. Aun así los experimentos o desafíos realizados a las hipótesis
deben como mínimo comprobar las predicciones.
Paso 9: Realización de conclusiones
Revisando las líneas generales mostradas en el paso 6 ya se habrán probado y desafiado

todas las hipótesis. Si las hipótesis se consideran parcialmente incorrectas, se debe
retroceder, modificar y luego volver a probar las nuevas hipótesis otra vez. Si las hipótesis
son totalmente incorrectas se retrocede y se toma un camino diferente
Las Conclusiones desarrolladas a partir de las hipótesis que han pasado las pruebas deben
tener las siguientes características más importantes:
 Ser lo suficientemente general como para ajustarse a todos los datos

relacionados
 Ser lo suficientemente concreta como para definir posibles excepciones y
conocer que datos de entrada son aceptables o no
 Ser consistente cuando es probada o verificada por otras personas, multitud
de veces
 Rara vez debe describir situaciones de las que no se tenga evidencia o no
hayan sido probadas
 Debe ser posible realizar una descripción de ésta y debe quedar claro qué
problema se ha resuelto
En caso que corresponda además de las Conclusiones se deberán presentar:

Limitaciones, especulaciones y Vista Futura, Presentación y Recomendaciones de
la Conclusión.
Estas conclusiones y recomendaciones contienen especial importancia debido a que

constituyen el aporte o valor agregado que da el Arquitecto a la solución del
problema/requerimiento.
En caso de que corresponda finalmente se deberán indicar en el informe los Anexos

y Referencias usadas en el desarrollo del análisis.


A continuación se indican los siguientes pasos del método MC-14. La aplicación de

los mismos deberá ser analizada en cada caso particular. Se recuerda que el
método en detalle se lo presenta en la sección Anexos de este documento.
Paso 10: Prórroga o dilación de afirmaciones o juicios de valor
A discreción.


Iarq-001 Protocolo de Indagacion Inicial de Un Sistema Informatico

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Iarq-001 Protocolo de Indagacion Inicial de Un Sistema Informatico

Cargado por

Copyright:

Formatos disponibles

Tipo Referencia Vigencia Página

Alcance: Arquitectura/Engineering Versión:1.0

PROTOCOLO DE INDAGACION INICIAL DE UN SISTEMA

Historial Nombre y Apellido Cargo Versión Fecha Observaciones

El sector de Arquitectura / Engineering está enfocado en le esfuerzo de indagar

Este modelo evalúa diferentes metodologías de software, y plantea un protocolo para

PROTOCOLO DE INDAGACION INICIAL DE UN SISTEMA INFORMATICO

Le agradecería responda el siguiente cuestionario donde: Si es la respuesta

DOCUMENTACIÓN INTERNA Y EXTERNA

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

6. ¿Se siguió un modelo de sistema documental?

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

las rutas de navegación que define la USN?

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

68. ¿Se consideró al programador en las pruebas de verificación y

Tras la indagación inicial, y siguiendo el MÉTODO CIENTÍFICO PARA LA

PROCEDIMIENTO DE ANALISIS FUNCIONAL

Dentro de la Arquitectura de Microservicios, existen principios que guían y permiten la

✓ La orientación a servicios como base

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

Como parte de la integración, necesariamente surgen temas de codificaciones

Particularmente en Arquitectura/Engineering, se implementa sobre esa visión de API –

 Servicio (MS): exponer la puerta de entrada vía un publicador. El protocolo en

 Orquestador / Controlador (ORQ): orquestar o controlar el flujo de llamadas y

 Conector (CON): conectar a repositorios internos o externos, como ESB/OSB, base

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

MODELO DE PROTOCOLO PARA ANÁLISIS Y EVALUACIÓN DEL SOFTWARE

Por Martín Alejo VALIENTE, UTN , 2008.

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

Paso 8: Refutación o cuestionamiento de las hipótesis

PASOS DE ANALISIS GENERAL DE UN SISTEMA INFORMATICO

Paso 1: Observación curiosa

Paso 2: ¿Existe algún problema?

Aspecto a Explicación/Ejemplo Acción en

Completitud El requerimiento solicitado debe estar completo. Por ejemplo Rechazar

Funcionalidad No La funcionalidad requerida no debe existir en el mismo o en Rechazar

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

Factibilidad de El requerimiento debe ser factible de implementar. Rechazar

NOTA: En caso de rechazo de la actividad se deberá explicar el motivo y cuando sea

En caso de que la definición del requerimiento cumpla con lo establecido en la sección

Paso 4: Búsqueda, exploración y recopilación de pruebas

En este punto es necesario empezar la búsqueda de soluciones con el uso de pensamiento

Paso 5: Generación creativa y alternativas lógicas

En esta sección se describe como realizar el Análisis del Requerimiento /Problema. Se

El presente documento contiene información de NARANJA SA de carácter confidencial.

Alcance: Arquitectura/Engineering Versión:1.0

razonamiento lógico. Se debe recopilar toda la información y agruparla o reordenarla hasta

El razonamiento reflexivo: Se trata sencillamente de buscar, explorar, seguir las intuiciones,

Los disparadores de idea: Se trata de situaciones, comportamientos, objetos o palabras que

Paso 6: Evaluación de las evidencias o pruebas

En el caso de ser necesario la elaboración/revisión del Diseño las soluciones propuestas se

Aspecto a Explicación/Ejemplo Acción en caso de