Auditoría de arquitectura de software y hardware
Auditoría de Software :
En la era digital es primordial que las empresas mantengan sus equipos tecnológicos actualizados. En este contexto surgen las Auditorías de Software, en un ambiente en el que no tener los medios tecnológicos actualizados o dentro de la legalidad para poder desarrollar el trabajo significa quedarse atrás frente a la competencia. Ante este escenario se pueden destacar las siguientes fases que se desarrollan al realizar una Auditoría de Software:
1.- Exploración y planteamiento.
2.- Estudio del soporte lógico de los equipos.
3.- Informe.
4.- Seguimiento y actualización constante
Auditoría de Hardware
Estas soluciones de consultoría y diagnóstico ofrecen la posibilidad de realizar un análisis completo a nivel tecnológico, que incluye desde inventarios de todo el parque informático, mapas de la arquitectura de red, test de rendimiento de comunicaciones, análisis de la capacidad para el teletrabajo, un informe fotográfico del cableado, de los racks, una tabla donde se analizan cada uno de los 20 controles CIS y su cumplimiento, etc…
Este diagnóstico se entrega en formato digital e impreso y suele tener unas 200 o 300 páginas. Cierra con una tabla de tareas, organizada por prioridad, coste y tiempo necesarios para realizar las tareas que se consideran oportunas para mejorar el rendimiento de la tecnología. Lo que facilita mucho la toma de decisiones por parte de los responsables con perfil menos técnico.
Experiencia en Auditoría de arquitectura de software y hardware
- Auditorías de todo el hardware de las empresas.
- Detección de malas prácticas en instalaciones.
- Visión global de la arquitectura de red.
- Auditoría de los 20 controles de CIS v7.
- Test de rendimiento y de velocidad de la red.
- Matriz de prioridades.
Implementación de arquitectura
La Arquitectura de la Información concluye con la documentación que permita la elaboración de la
estructura de información que se encuentra reflejada en la serie de informes y diagramas, para su
posterior desarrollo e implementación. En muchos casos, la decisión de usar algún software en
concreto, depende de la infraestructura actual de la institución, o el presupuesto general que se
tenga en el proyecto.
Elección de la Base de Datos
La base de datos es uno de los componentes esenciales en la arquitectura de la información para
contenidos dinámicos que se extraen desde estos repositorios de datos. Entre las características
esenciales debe estar su capacidad de escalabilidad, flexibilidad, performance, costo. Entre las
bases de datos comerciales se encuentra Oracle, SQL Server y otras de fuente abierta como el
MySQL, Postgress, SAPDB. En casos de Intranet, se debe tomar en cuenta la capacidad de tener
procedimientos almacenados y monitoreo de transacciones. Dependiendo de las políticas internas,
se tendrá que decidir el método de conexión y las restricciones de seguridad.
Elección del Lenguaje de Programación
El lenguaje de programación es la herramienta con la cual se realizará las interfaces de la
información, las cuáles deben tener características de modularidad, que permitan el desarrollo del
sitio Web. En arquitecturas de contenido estático, se debería manejar con programación de
inserción de encabezados y menús, que permitan un mantenimiento rápido y efectivo. En este caso
se puede optar por el Server Side Includes (SSI), para servidores Apache. En sitios Web que
requieran un uso intensivo de consultas a las bases de datos, se debe optar por un lenguaje que
brinde muchas funciones y características, las cuales se pueden encontrar PHP (Hipertext
Preprocessor), ASP (Active Server Pages), Coldfusion, Perl, TCL, etc.
Análisis del Sistema – Diseño de Flujogramas y Descripción de Procesos
En forma simultánea se debe ir trabajando la descripción de procesos que se encuentran detrás de
la implementación del sistema, elaborando para su fin la documentación técnica en los flujogramas
y la descripción de los procesos, como su interacción con toda la arquitectura de información. Cada
sistema tendrá una propio flujo de procesos e interacciones. En esta etapa se debe trabajar mucho
con el usuario final, y en evaluaciones de usabilidad para el correcto funcionamiento del sistema.
Métricas de calidad del código fuente
Antes de adentrarnos en este duro mundo, os explicamos varios puntos que nos ayudarán a medir la calidad de nuestro código y veremos la importancia que tiene cada uno.
Código duplicado
Este término se utiliza cuando hablamos de un código fuente que aparece más de una vez, ya sea dentro de uno o diferentes programas, de propiedad o mantenido, por la misma entidad.
La duplicación de código es generalmente considerada una señal de estilo de programación pobre, ya que un buen desarrollo está más asociado a la reutilización del mismo.
La principal desventaja es el mantenimiento del código, lo cual se convierte en una tarea mucho más costosa.
Código muerto
Es el código que se encuentra en nuestra aplicación, pero nunca es utilizado. Normalmente aparece después de hacer refactor en nuestro código.
Estándares de codificación
Se refiere a convenciones para escribir código fuente, las cuales frecuentemente son dependientes del lenguaje de programación.
Las convenciones más comunes hacen referencia a: nombres de variables, indentaciones, espaciado…
Bugs
Un bug es un error o un defecto en el software que hace que un programa funcione de forma incorrecta.
Complejidad ciclomática
Es una métrica de calidad software basada en el cálculo del número de caminos independientes que tiene nuestro código.
Cuanto más compleja sea la lógica de un código, más difícil será de entender, mantener y probar.
Comentarios
Los comentarios son añadidos usualmente con el propósito de hacer el código fuente más fácil de entender con vistas a su mantenimiento o reutilización.
Una mala o escasa documentación puede convertir el mantenimiento del código en una tarea muy costosa.
Al igual que ocurre con los tests, un gran porcentaje de comentarios no asegura calidad. Los comentarios deben ser buenos y aclaratorios explicando interfaces públicas, pero no lógica ni diseño.
Tests unitarios y de integración
Son una forma de comprobar el correcto funcionamiento de una unidad de código y de la integración de mismos.
Facilitan los cambios en la aplicación, ya que las pruebas nos aseguran que los nuevos cambios no han introducido errores en partes de código desarrolladas anteriormente y que están cubiertas por estos.
Por otro lado, documentan el código, siendo un libro abierto sobre el funcionamiento del código.
Cobertura de código
La cobertura de código es una medida que nos indica el porcentaje de código validado por los tests. Generalmente con una mayor cobertura aseguramos que no se introducen errores en una mayor parte del código, pero esto dependerá de la funcionalidad real que cubran los tests.
Documentación de arquitectura
No se preocupe si no tiene todavía una metodología , analizaremos su equipo, su tecnología, su presupuesto y sus herramientas actuales para proponerle la solución que mas se ajuste a sus necesidades. Existen muchas maneras de documentar, explicaremos uno de los más habituales usados en esta casa, los diagramas de arquitectura.
Los diagramas de arquitectura de software son una manera fantástica de comunicar cómo planea construir un sistema de software (diseño inicial) o cómo funciona un sistema de software existente (documentación retrospectiva, intercambio de conocimientos y aprendizaje).
Sin embargo, es muy probable que la mayoría de los diagramas de arquitectura de software que ha visto sean un lío confuso de cajas y líneas. Un desafortunado e involuntario efecto secundario del Manifiesto para el Desarrollo Ágil de Software es que muchos equipos han detenido o reducido sus esfuerzos de diagramación y documentación, incluyendo el uso de UML.
Ahora, estos mismos equipos tienden a confiar en diagramas ad hoc que dibujan en una pizarra o ensamblan utilizando herramientas de diagramación de propósito general, como Microsoft Visio. Ionut Balosin escribió el año pasado “The Art of Making Architectural Diagrams” (El arte de hacer diagramas arquitectónicos), que describe una serie de problemas comunes al hacerlo, relacionados con notaciones semánticas incomprensibles y poco claras.
Los diagramas ambiguos de arquitectura de software conducen a malentendidos, lo que puede ralentizar a un buen equipo. En nuestra industria, deberíamos esforzarnos por crear mejores diagramas de arquitectura de software. Después de años de crear software y trabajar con equipos de todo el mundo, he creado algo que llamo el “modelo C4”. C4 significa contexto, contenedores, componentes y código — un conjunto de diagramas jerárquicos que puede utilizar para describir la arquitectura de su software en diferentes niveles de zoom, cada uno útil para diferentes audiencias. Piensa en ello como Google Maps para tu código.
Pruebas de escalabilidad y rendimiento
Vea cómo funciona su aplicación web o aplicación en navegadores reales o dispositivos móviles bajo una carga de usuario simultánea pesada.
El equipo de Exceptia gestionará completamente la infraestructura de pruebas: no se requieren cuentas en la nube. Es bastante difícil administrar una plataforma web escalable, ya sea automatizada o manual, pero tratar de administrar también una plataforma de pruebas de carga escalable al realizar una prueba puede ser un gran dolor de cabeza. No desea preocuparse de si la plataforma de pruebas ha aumentado y apagado los nodos correctamente después de la prueba, y ciertamente no desea que el costo de los servidores en la nube huérfanos que se sigan ejecutando después de que termine una prueba.
Nosotros administraremos todos los aspectos de la nube durante una prueba, desde la creación de instancias de los servidores y la carga de los casos de prueba, hasta la agregación de los resultados de las pruebas y el cierre de los servidores. No es necesario que introduzca ninguna credencial de nube en el sistema y no se le cobrará ninguna tarifa oculta o adicional más allá del costo de la prueba de escalabilidad que solicitó.
¿Que nos aporta un arquitecto de software?
Como hemos comentado, la arquitectura del software es uno de los pilares más importantes para evitarnos problemas futuros. Pensar en el crecimiento de nuestro software también es fundamental, porque toda aplicación o sitio de internet cuya funcionalidad no se amplíe o se modifique, tiende a ser obsoleta relativamente en un corto espacio de tiempo.
Con el tiempo el software suele demandar crecer y con ello suele crecer su complejidad, es importante que tenga una forma bien definida, de modo que seamos capaces de tener una visión global a corto y largo plazo. De no ser así, al examinar cada una de sus partes por separado, lo más normal es que seamos incapaces de interpretar correctamente el funcionamiento y el motivo de su existencia.
La arquitectura del software por tanto define la estructura que debe de tener un software, las piezas que debemos construir y el modo en el que se deben de juntar y trabajar entre ellas. Se define a alto nivel mediante una serie de patrones y abstracciones que seguir para el desarrollo del software y para la interacción entre sus diversas piezas.
No hay que olvidar que mantenimiento sigue siendo esencial, porque aunque una aplicación se pueda desarrollar en unas pocas semanas o meses, lo más habitual en nuestro caso es que se mantenga durante años, añadiendo funcionalidades que detectamos y/o requieren los clientes y/o usuarios o corrigiendo problemas existentes.
