PRINCIPIOS DEL ANÁLISIS
Todos los métodos de
análisis se relacionan a través del siguiente conjunto de principios
operativos:
a. La representación y el
entendimiento del dominio de información de un problema. Requiere el examen del
dominio de la información. Este dominio contiene tres visiones diferentes de
los datos y del control: (1) contenido de la información y relaciones, (2)
flujo de la información y (3) estructura de la información. El contenido es
definido por los atributos necesarios para crearlo. El flujo representa como
cambian los datos y el control a medida que se mueven dentro de un sistema. La
estructura representa la organización interna de los elementos de datos o de
control.
b. La definición de
funciones que debe realizar el software. Los modelos se crean para entender de
mejor manera la entidad que se va construir como solución a un problema. Para
transformar la información el software debe realizar al menos tres funciones
genéricas: entrada, procesamiento y salida.
c. La representación del
comportamiento del software. La característica estimulo respuesta forma la base
del modelo de comportamiento. Un programa de computadora siempre está en un
estado, en un modo de comportamiento observable exteriormente (imprimiendo,
calculando, etc.).
d. La división de los
modelos que representan información, función y comportamiento de manera que se
puedan descubrir los detalles por capas, para que las partes puedan entenderse
fácilmente y establecer luego las interacciones entre las mismas de manera que
se pueda conseguir la función global.
e. El proceso de análisis
debería ir desde la información esencial hasta el detalle de la implementación.
Una visión esencial de los requisitos del software presenta las funciones a
conseguir y la información a procesar sin tener en cuenta los detalles de la
implementación. La visión de implementación de los requisitos del software
introduce la manifestación en el mundo real de las funciones de procesamiento y
las estructuras de la información.
PRINCIPIOS
DEL DISEÑO
El principio de segregación
de interfaces
Este principio, conocido
por ISP (Interface segregation principle), dice que
el una clase que implementa una interfaz no debe depender de métodos
que no utiliza. Esto como norma general implica que nuestras interfaces
deben ser sencillas y tener pocos métodos. Es preferible tener varias
interfaces pequeñas, a tener una interfaz grande. Así no obligamos a los clientes a
depender de métodos que no necesitan implementar.
El principio de inversión de
dependencias
En inglés DIP (Dependency
Inversion Principle), que viene a decir que las clases de alto
nivel, no deben depender de clases de bajo nivel. Ambos deben depender de
abstracciones. Además las abstracciones no deben depender de los detalles, si
no que los detalles deben depender de las abstracciones. En definitiva, lo que
tenemos que hacer es invertir las dependencias.
Por ejemplo, imaginemos una
clase Saludo que tiene un método que imprime un mensaje
dependiendo de la hora del día. Si es antes de las 12 de la mañana, escribe
"Buenos días". Si es más tarde escribe "Buenas tardes". En
este caso el componente de alto nivel es la clase Saludo, mientras
que el componente de bajo nivel, es una clase Date. El método Saludar instancia
un objeto de la clase Datepara comprobar la hora del día y realizar
el saludo que corresponda. En este caso tan simple, la clase Saludo depende
de una clase de bajo nivel Date. Esto hace que, entre otras cosas,
la clase Saludo sea más difícil de probar.
Si invertimos las
dependencias, lo que podemos hacer es pasar un objeto Datecomo
parámetro a la hora de instanciar la clase Saludo. Cuándo se llame
al método Saludar se utilizará dicho objeto. En este caso
estamos inyectando la dependencia a través del constructor de la clase Saludo.
Separa los asuntos
Principio SoC (separation
of concerns). Los asuntos, son los diferentes aspectos de la funcionalidad
de nuestra aplicación. Por ejemplo la capa de negocio, la capa de datos etc. Un
buen ejemplo de separación es el patrón MVC.
PRINCIPIO
DE CONSTRUCCION DEL SOFTWARE
Los principios fundamentales
de la construcción de software son:
·
Minimizar la Complejidad
·
Anticipar los Cambios
·
Pensar en la Verificación posterior
·
Aplicar Estándares
ü Minimizar
la Complejidad
·
Escribiendo código sencillo y fácil de leer
·
Utilizando estándares
·
Técnicas de codificación
·
Técnicas de aseguramiento de calidad
ü Anticipar
los Cambios
·
El software se ve afectado por los cambios en
su entorno y está destinado a cambiar a lo largo del tiempo
·
Aplicación de técnicas específicas
ü Pensar
en la Verificación posterior
·
Construir de forma que los fallos puedan ser
encontrados lo antes posible (al codificar, hacer pruebas u operar el sistema)
·
Técnicas:
Ø Seguir
estándares de codificación
Ø Hacer
pruebas unitarias
Ø Organizar
el código para soportar pruebas automatizadas
Ø Restringir
el uso de técnicas complejas
ü Aplicar
Estándares
·
Directamente a la construcción del software:
Ø Formatos
de comunicación (documentos, contenidos).
Ø Versiones
estándares de lenguajes de programación (Java, C++, C#,…).
Ø Reglas
de codificación (nombres de variables comentarios )
Ø Notaciones
de diagramas (UML,…).
Ø Intercambio
entre herramientas (XLM,…).
·
En un proyecto:
Ø Externos:
propuestos por organismos de estandarización (ISO, ANSI, AENOR), consorcios
industriales (OMG), asociaciones profesionales (IEEE, ACM).
Ø Internos:
creados por la propia organización.
PRINCIPIOS
DE CODIFICACION DEL SOFTWARE
La escritura del código
fuente es el principal esfuerzo de construcción de software
·
Aplicar técnicas para crear código fuente
comprensible (reglas de asignación de nombres y de formato del código, clases,
tipos enumerados, constantes, etiquetadas,…)
·
Manejar condiciones de error (errores
previstos e imprevistos, excepciones)
·
Prevenir brechas de seguridad a nivel de
código (llenado de buffers, overflow de índices de vectores, …)
·
Uso eficiente de recursos escasos (hilos,
bloqueos en bases de datos, …)
·
Organizar el código fuente (sentencias,
rutinas, clases, paquetes, …)
·
Documentar el código
PRINCIPIO
DE VALIDACION DEL SOFTWARE
La validación también es una
evaluación del sistema o de componentes, solo que es en el transcurso o al
final del proceso del desarrollo, donde se determina si cumple con lo
especificado.
Aspectos en la validación:
·
Construir el sistema correcto.
·
Evaluar la conformidad con la especificación
de requisitos.
Principales Principios:
·
Especificación de los requisitos.
·
Prevención de defectos.
·
Tiempo y Esfuerzo.
·
Ciclo de vida del software.
·
Planificación.
·
Procedimientos.
·
Validación del software.
·
Alcance de la validación.
·
Independencia de la validación.
·
Flexibilidad y Responsabilidad.
PRINCIPIO
DE PRUEBA DEL SOFTWARE
Las
pruebas revelan la presencia de bugs, no la ausencia de ellos
Probar reduce la
probabilidad de que existan bugs pero nunca se puede asegurar que no quede
ninguno oculto.
Además, cada tipo de pruebas
que realicemos (de sistema, de integración, añadir auditorías de código…) son
más efectivas para detectar un tipo de bug.
Es
imposible probarlo todo
El flujo de control de un
sistema software no trivial como los que acostumbramos a utilizar en el día a
día contiene miles de decisiones.
Estas decisiones se pueden
combinar entre ellas para dar lugar a una infinidad de posibles caminos. De
entrada, probar todos los caminos es un problema inabordable.
Y eso si no tenemos en
cuenta la prueba de requisitos no funcionales, como el rendimiento de un
sistema ante una exigente carga de usuarios, o requisitos específicos de
seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios
malintencionados.
Todo esto hace necesaria una
estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos
de calidad y de proyecto, y como reza el siguiente principio…
Cuanto
antes se comience a probar…mejor
Corregir un bug con una
revisión en la fase de captura de requisitos o en una prueba unitaria tiene un
coste mucho menor a lo que costará corregir este bug cuando se detecte en una
prueba de sistema, o peor aún, en una prueba de aceptación por el cliente.
En demasiadas ocasiones
existe una confianza excesiva en las pruebas de sistema, y todo el plan de
pruebas (cuando existe) se reduce a estas. Se confía en que todos los
componentes que no se probaron con una estrategia de pruebas unitarias y de
integración se puedan entender bien a unos días del hito de entrega (cuando
corregir un bug ya es demasiado caro, en lo que se denomina una prueba de
integración “big-bang”).
Curiosamente estas malas
prácticas se realizan para ahorrar costes, y finalmente el coste de la no
calidad cambia las tornas: siempre se acaba pagando en unos costes de
mantenimiento excesivos (con caídas de la productividad del 50% según Capers
Jones).
La
aglomeración de defectos. ¡Los bugs siempre van en pandilla!
Entender esto es muy
importante para plantear una buena estrategia de pruebas: los bugs suelen ir en
grupo. Se concentran en determinados puntos de un sistema software, no
manteniendo una distribución uniforme a lo largo del mismo.
Conclusión: si encuentras un
bug en un componente, es muy probable que haya más. Con lo que una posible
estrategia sería centrarse en mejorar las pruebas de aquellos componentes para
los que se han reportado un número mayor de bugs, para ser más eficaces a la
hora de cazarlos en fases tempranas.
La
paradoja del pesticida
O la necesidad de ajustar
continuamente tu plan de pruebas… porque según este principio un plan de
pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo
que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no haya!
(vuelve a leer el primer principio). Se habla de paradoja del pesticida ya que
estos matabichos usualmente sirven para un tipo de bichos, pero una vez no
queda ninguno del tipo específico que mata el pesticida… ¡nadie te dice que no
haya otros bichos campando a sus anchas!
Las
pruebas se deben adaptar a necesidades específicas
Esto viene a enlazar con lo
que he comentado antes. Si tu producto se centra en el ámbito de la seguridad
deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles
escenarios no amistosos. Si quieres probar una intranet donde los servicios más
vitales son los de imputación de horas y el de vacaciones, es lógico centrarse
en estos servicios y no invertir tiempo en otros componentes infrautilizados. Además, hay que tener en cuenta que los
recursos en los proyectos son siempre escasos, con lo que en el inicio del
proyecto hay que preguntarse… qué estrategia debemos seguir para encontrar y
corregir lo antes posible los bugs en las funcionalidades de mayor valor para
nuestros usuarios.
La
falacia de la ausencia de errores
Para terminar, nos
encontramos con la satisfacción del usuario y con el hecho de que los usuarios
elijan tu software para resolver sus necesidades. Que hayas corregido muchos
bugs no significa que finalmente tu software sea un éxito. En ocasiones hay que
primar un buen time to market, para luego corregir los problemas de calidad que
quedaron por el camino. Y esto si se hace de manera consciente y con una buena
estrategia, a priori, no debe ser un problema.
PRINCIPIO
DE DESPLIEGUE DEL SOFTWARE
·
Se deben administrar las expectativas que el
cliente tiene del software.
·
Se debe ensamblar y probar un paquete de
entrega completo.
·
Se debe establecer un régimen de soporte
antes de entregar el software.
·
Se debe proporcionar material instructivo
apropiado los usuarios finales.
·
El Software con errores se debe arreglar
primero y entregar después.
QUE ES UN EQUIPO DE ALTO
RENDIMIENTO?
