Principios de Desarrollo del Software

1.  PRINCIPIOS DEL ANÁLISIS 

1.  Debe representarse y entenderse el dominio de información de un problema.

2.  Debe definirse las funciones que debe realizar el software.

3.  Debe representarse el comportamiento del software.

4.  Debe dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas.

5.  El proceso de análisis deriva ir desde la información esencial hasta el detalle de la implementación.

2.  PRINCIPIOS DEL  DISEÑO  

1.  El diseño deberá poderse rastrear hasta el modelo de análisis

2.  El diseño no deberá inventar nada que ya esté inventado

3.  El diseño deberá minimizar la distancia intelectual entre el software y el problema, como si de misma vida real se tratara.

4.  El diseño deberá presentar uniformidad e integración

5.  El diseño deberá estructurarse para admitir cambios

3.  LOS PRINCIPIOS DE CONSTRUCCIÓN

1.  Minimizar la Complejidad

2. Escribiendo código sencillo y fácil de leer código sencillo y fácil de leer

3.Utilizando estándares

4.Técnicas de codificación

5. Técnicas de aseguramiento de calidad

2.  Anticipar los Anticipar los Cambios

1.El software se ve afectado por los cambios en su entorno y está destinado a cambiar a lo largo del tiempo

2.Aplicación de técnicas específicas

3.  Pensar en la Verificación posterior

1.Construir de forma que los fallos puedan ser encontrados lo antes Construir de forma que los fallos puedan ser encontrados lo antes posible (al codificar, hacer pruebas u operar el sistema)

2.Seguir estándares de codificación

3.Hacer pruebas unitarias

4.Organizar el código para soportar pruebas automatizadas

5.Restringir el uso de técnicas complejas

4.  Aplicar Estándares

1.Formatos de comunicación (documentos, contenidos).

2.Versiones estándares de lenguajes de programación (Java, C++, C#,…).

3.Reglas de codificación (nombres de variables comentarios) Reglas de codificación (nombres de variables, comentarios,…).

4. Notaciones de diagramas (UML,…).

5.Intercambio entre herramientas (XLM,…).

4.  LOS PRINCIPIOS DE CODIFICACIÓN 

1.  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,…)

2.  Manejar condiciones de error (errores previstos e imprevistos, excepciones)

3.  Prevenir brechas de seguridad a nivel de código (llenado de buffers, overflow de índices de vectores) de índices de vectores,…)

4.  Uso eficiente de recursos escasos (hilos, bloqueos en bases de datos,…)

5.  Organizar el código fuente (sentencias, rutinas, clases, paquetes,…)

6.  Documentar el código

5.  PRINCIPIOS DE VALIDACIÓN 

1.  Especificación de los requerimientos: Una especificación documentada de los requisitos del software proporciona la base para la validación y la verificación. El proceso de validación del software no puede completarse si un establecimiento de las especificaciones de los requisitos.

2.  Prevención de defectos: Las necesidades del aseguramiento de la calidad del software fijan su atención en la prevención de defecto en el proceso de desarrollo del software y no en probar la calidad del código del software después de que se escribe.

3.  Tiempo y esfuerzo: La validación del software requiere de tiempo y esfuerzo. La preparación para la validación debe comenzar con anticipación; es decir, durante la planificación del diseño y desarrollo y el diseño de la entrada de datos. La conclusión final que muestra que el software se encuentra validado debe estar basada en la evidencia recolectada a partir de los esfuerzos planificados dirigidos a los largo el ciclo del vida el software.

4.  Ciclo de vida del software: El ciclo de vida del software contiene las tareas de ingeniería  de software y la documentación necesaria para soportar la validación del software. El ciclo de vida del software puede ser seguido completamente o tener variaciones en su desarrollo, debido a las propias características  y naturaleza del software que se desea desarrollar.

5.  Planificación: Los planes de validación del software especifican aspectos tales como el alcance, el método de validación, los recursos, el cronograma, los tipos y la magnitud de las actividades que se deben llevar a cabo para la validación.

6.  Procedimientos: Los procedimientos deben identificar las acciones específicas o la sucesión de acciones que deben tomarse para completar las actividades individuales de validación.

7.   Validación del software después de un cambio: El alcance de la validación debe estar basado en la complejidad del software y en los riesgos de la seguridad; no en el tamaño de la organización  o la restricción de los recursos.

8.  Independencia de la validación: Las actividades de validación deben ser conducidas cumpliendo el precepto básico de la gestión de la calidad sobre la independencia de la revisión. La autoevaluación es sumamente difícil.

9.  Flexibilidad y responsabilidad: La aplicación específica  de estos principios de validación del software pueden ser muy diferente de una aplicación a otra. El fabricante o desarrollador de software tiene flexibilidad a la hora de escoger cómo aplicar estos principios de validación pero es el responsable de demostrar que el software se ha validado.

6.  PRINCIPIOS DE PRUEBA 

1.  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.

2.  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.

3.  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).

4.  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

7.  PRINCIPIOS DE DESPLIEGUE

1.  Probar el producto en su entorno de ejecución final.

2.  Empaquetar el software para su distribución.

3.  Distribuir el software.

4.  Instalar el software.

5.  Proveer asistencia y ayuda a los usuarios.

6.  Formar a los usuarios y al cuerpo de ventas.

7.  Migrar el software existente o convertir bases de datos.