1. Principios fundamentales
1.1. La práctica de la ingeniería de software está guiada por un conjunto de principios fundamentales que ayudan en la aplicación del proceso de software significativo y en la ejecución de métodos eficaces de ingeniería de software.
1.2. Principios que guían al proceso
1.2.1. En el nivel del proceso, los principios fundamentales establecen un fundamento filosófico que guía al equipo de software cuando realiza actividades estructurales y actividades sombrilla, cuando navega por el flujo del proceso y elabora un conjunto de productos del trabajo de la ingeniería de software.
1.2.2. Principio 1. Ser ágil. Ya sea que el modelo de proceso que se elija sea prescriptivo o ágil, son los principios básicos del desarrollo ágil los que deben gobernar el enfoque. Todo aspecto del trabajo que se haga debe poner el énfasis en la economía de acción: en mantener el enfoque técnico tan sencillo como sea posible, hacer los productos del trabajo que se generan tan concisos como se pueda y tomar las decisiones localmente, siempre que sea posible
1.2.3. Principio 2. En cada etapa, centrarse en la calidad. La condición de salida para toda actividad, acción y tarea del proceso debe centrarse en la calidad del producto del trabajo que se ha generado.
1.2.4. Principio 3. Estar listo para adaptar. El proceso no es una experiencia religiosa, en él no hay lugar para el dogma. Cuando sea necesario, adapte su enfoque a las restricciones impuestas por el problema, la gente y el proyecto en sí.
1.2.5. Principio 4. Formar un equipo eficaz. El proceso y práctica de la ingeniería de software son importantes, pero el objetivo son las personas. Forme un equipo con organización propia en el que haya confianza y respeto mutuos.
1.2.6. Principio 5. Establecer mecanismos para la comunicación y coordinación. Los proyectos fallan porque la información importante cae en las grietas o porque los participantes no coordinan sus esfuerzos para crear un producto final exitoso. Éstos son aspectos de la administración que deben enfrentarse
1.2.7. Principio 6. Administrar el cambio. El enfoque puede ser formal o informal, pero deben establecerse mecanismos para administrar la forma en la que los cambios se solicitan, evalúan, aprueban e implementan.
1.2.8. Principio 7. Evaluar el riesgo. Son muchas las cosas que pueden salir mal cuando se desarrolla software. Es esencial establecer planes de contingencia.
1.2.9. Principio 8. Crear productos del trabajo que agreguen valor para otros. Sólo genere aquellos productos del trabajo que agreguen valor para otras actividades, acciones o tareas del proceso. Todo producto del trabajo que se genere como parte de la práctica de ingeniería de software pasará a alguien más.
1.3. Principios que guían a la practica
1.3.1. En el nivel de la práctica, los principios fundamentales definen un conjunto de valores y reglas que sirven como guía cuando se analiza un problema, se diseña una solución, se implementa y prueba ésta y cuando, al final, se entrega el software a la comunidad de usuarios.
1.3.2. Principio 1. Divide y vencerás. Dicho en forma más técnica, el análisis y el diseño siempre deben enfatizar la separación de entidades (SdE). Un problema grande es más fácil de resolver si se divide en un conjunto de elementos (o entidades).
1.3.3. Principio 2. Entender el uso de la abstracción. En su parte medular, una abstracción es una simplificación de algún elemento complejo de un sistema usado para comunicar significado en una sola frase
1.3.4. Principio 3. Buscar la coherencia. Ya sea que se esté creando un modelo de los requerimientos, se desarrolle un diseño de software, se genere código fuente o se elaboren casos de prueba, el principio de coherencia sugiere que un contexto familiar hace que el software sea más fácil de usar.
1.3.5. Principio 4. Centrarse en la transferencia de información. El software tiene que ver con la transferencia de información: de una base de datos a un usuario final, de un sistema heredado a una webapp, de un usuario final a una interfaz gráfica de usuario (GUI, por sus siglas en inglés), de un sistema operativo a una aplicación, de un componente de software a otro… la lista es casi interminable.
1.3.6. Principio 5. Construir software que tenga modularidad eficaz. La separación de entidades (principio 1) establece una filosofía para el software. La modularidad proporciona un mecanismo para llevar a cabo dicha filosofía. Cualquier sistema complejo puede dividirse en módulos (componentes), pero la buena práctica de la ingeniería de software demanda más. La modularidad debe ser eficaz.
1.3.7. Principio 6. Buscar patrones. El objetivo de los patrones dentro de la comunidad de software es crear un cúmulo de bibliografía que ayude a los desarrolladores de software a resolver problemas recurrentes que surgen a lo largo del desarrollo. Los patrones ayudan a crear un lenguaje compartido para comunicar perspectiva y experiencia acerca de dichos patrones y sus soluciones.
1.3.8. Principio 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes. Cuando un problema y su solución se estudian desde varias perspectivas distintas, es más probable que se tenga mayor visión y que se detecten los errores y omisiones.
1.3.9. Principio 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes. Cuando un problema y su solución se estudian desde varias perspectivas distintas, es más probable que se tenga mayor visión y que se detecten los errores y omisiones.
2. Principios que guían toda actividad estructural
2.1. Principios de comunicación
2.1.1. Principio 1. Escuchar. Trate de centrarse en las palabras del hablante en lugar de formular su respuesta a dichas palabras. Si algo no está claro, pregunte para aclararlo, pero evite las interrupciones constantes. Si una persona habla, nunca parezca usted beligerante en sus palabras o actos
2.1.2. Principio 2. Antes de comunicarse, prepararse. Dedique algún tiempo a entender el problema antes de reunirse con otras personas. Si es necesario, haga algunas investigaciones para entender el vocabulario propio del negocio.
2.1.3. Principio 3. Alguien debe facilitar la actividad. Toda reunión de comunicación debe tener un líder que: 1) mantenga la conversación en movimiento hacia una dirección positiva, 2) sea un mediador en cualquier conflicto que ocurra y 3) garantice que se sigan otros principios
2.1.4. Principio 4. Es mejor la comunicación cara a cara. Pero por lo general funciona mejor cuando está presente alguna otra representación de la información relevante
2.1.5. Principio 5. Tomar notas y documentar las decisiones. Las cosas encuentran el modo de caer en las grietas. Alguien que participe en la comunicación debe servir como “secretario” y escribir todos los temas y decisiones importantes
2.1.6. Principio 6. Perseguir la colaboración. La colaboración y el consenso ocurren cuando el conocimiento colectivo de los miembros del equipo se utiliza para describir funciones o características del producto o sistema.
2.1.7. Principio 7. Permanecer centrado; hacer módulos con la discusión. Entre más personas participen en cualquier comunicación, más probable es que la conversación salte de un tema a otro.
2.1.8. Principio 8. Si algo no está claro, hacer un dibujo. La comunicación verbal tiene sus límites. Con frecuencia, un esquema o dibujo arroja claridad cuando las palabras no bastan para hacer el trabajo.
2.2. Principios de planeación
2.2.1. Principio 1. Entender el alcance del proyecto. Es imposible usar el mapa si no se sabe a dónde se va. El alcance da un destino al equipo de software.
2.2.2. Principio 2. Involucrar en la actividad de planeación a los participantes del software. Los participantes definen las prioridades y establecen las restricciones del proyecto. Para incluir estas realidades, es frecuente que los ingenieros de software deban negociar la orden de entrega, los plazos y otros asuntos relacionados con el proyecto.
2.2.3. Principio 3. Reconocer que la planeación es iterativa. Un plan para el proyecto nunca está grabado en piedra. Para cuando el trabajo comience, es muy probable que las cosas hayan cambiado. En consecuencia, el plan deberá ajustarse para incluir dichos cambios. Además, los modelos de proceso iterativo incrementales dictan que debe repetirse la planeación después de la entrega de cada incremento de software, con base en la retroalimentación recibida de los usuarios.
2.2.4. Principio 4. Estimar con base en lo que se sabe. El objetivo de la estimación es obtener un índice del esfuerzo, costo y duración de las tareas, con base en la comprensión que tenga el equipo sobre el trabajo que va a realizar. Si la información es vaga o poco confiable, entonces las estimaciones tampoco serán confiables.
2.2.5. Principio 5. Al definir el plan, tomar en cuenta los riesgos. Si ha identificado riesgos que tendrían un efecto grande y es muy probable que ocurran, entonces es necesario elaborar planes de contingencia. Además, el plan del proyecto (incluso la programación de actividades) deberá ajustarse para que incluya la posibilidad de que ocurran uno o más de dichos riesgos.
2.2.6. Principio 6. Ser realista. Las personas no trabajan 100% todos los días. En cualquier comunicación humana hay ruido. Las omisiones y ambigüedad son fenómenos de la vida. Los cambios ocurren. Aun los mejores ingenieros de software cometen errores. Éstas y otras realidades deben considerarse al establecer un proyecto.
2.2.7. Principio 7. Ajustar la granularidad cuando se defina el plan. La granularidad se refiere al nivel de detalle que se adopta cuando se desarrolla un plan. Un plan con “mucha granularidad” proporciona detalles significativos en las tareas para el trabajo que se planea, en incrementos durante un periodo relativamente corto (por lo que el seguimiento y control suceden con frecuencia). Un plan con “poca granularidad” da tareas más amplias para el trabajo que se planea, para plazos más largos.
2.2.8. Principio 8. Definir cómo se trata de asegurar la calidad. El plan debe identificar la forma en la que el equipo de software busca asegurar la calidad. Si se realizan revisiones técnicas,3 deben programarse.
2.2.9. Principio 9. Describir cómo se busca manejar el cambio. Aun la mejor planeación puede ser anulada por el cambio sin control. Debe identificarse la forma en la que van a recibirse los cambios a medida que avanza el trabajo de la ingeniería de software.
2.3. Principios de modelado
2.3.1. Principio 1. El equipo de software tiene como objetivo principal elaborar software, no crear modelos. Agilidad significa entregar software al cliente de la manera más rápida posible. Los modelos que contribuyan a esto son benéficos, pero deben evitarse aquellos que hagan lento el proceso o que den poca perspectiva.
2.3.2. Principio 2. Viajar ligero, no crear más modelos de los necesarios. Todo modelo que se cree debe actualizarse si ocurren cambios. Más importante aún es que todo modelo nuevo exige tiempo, que de otra manera se destinaría a la construcción (codificación y pruebas).
2.3.3. Principio 3. Tratar de producir el modelo más sencillo que describa al problema o al software. Al mantener sencillos los modelos, el software resultante también lo será. El resultado es que se tendrá un software fácil de integrar, de probar y de mantener (para que cambie).
2.3.4. Principio 4. Construir modelos susceptibles al cambio. Suponga que sus modelos cambiarán, pero vigile que esta suposición no lo haga descuidado.
2.3.5. Principio 5. Ser capaz de enunciar un propósito explícito para cada modelo que se cree. Cada vez que cree un modelo, pregúntese por qué lo hace. Si no encuentra una razón sólida para la existencia del modelo, no pierda tiempo en él.
2.3.6. Principio 6. Adaptar los modelos que se desarrollan al sistema en cuestión. Tal vez sea necesario adaptar a la aplicación la notación del modelo o las reglas; por ejemplo, una aplicación de juego de video quizá requiera una técnica de modelado distinta que el software incrustado que controla el motor de un automóvil en tiempo real.
2.3.7. Principio 7. Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos. Cuando un ingeniero de software construye modelos de requerimientos y diseño, alcanza un punto de rendimientos decrecientes. Es decir, el esfuerzo requerido para terminar por completo el modelo y hacerlo internamente consistente deja de beneficiarse por tener dichas propiedades.
2.3.8. Principio 8. No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para comunicar contenido, la representación es secundaria. Aunque cada miembro del equipo de software debe tratar de usar una notación consistente durante el modelado, la característica más importante del modelo es comunicar información que permita la realización de la siguiente tarea de ingeniería. Si un modelo tiene éxito en hacer esto, es perdonable la sintaxis incorrecta.
2.3.9. Principio 9. Si su instinto dice que un modelo no es el correcto a pesar de que se vea bien en el papel, hay razones para estar preocupado. Si usted es un ingeniero de software experimentado, confíe en su instinto. El trabajo de software enseña muchas lecciones, algunas en el nivel del inconsciente.
2.3.10. Principio 10. Obtener retroalimentación tan pronto como sea posible. Todo modelo debe ser revisado por los miembros del equipo. El objetivo de estas revisiones es obtener retroalimentación para utilizarla a fin de corregir los errores de modelado, cambiar las interpretaciones equivocadas y agregar las características o funciones omitidas inadvertidamente.
2.4. Principios de construcción
2.4.1. Principio 1. Debe representarse y entenderse el dominio de información de un problema. El dominio de información incluye los datos que fluyen hacia el sistema (usuarios finales, otros sistemas o dispositivos externos), los datos que fluyen fuera del sistema (por la interfaz de usuario, interfaces de red, reportes, gráficas y otros medios) y los almacenamientos de datos que recaban y organizan objetos persistentes de datos
2.4.2. Principio 2. Deben definirse las funciones que realizará el software. Las funciones del software dan un beneficio directo a los usuarios finales y también brindan apoyo interno para las características que son visibles para aquéllos. Algunas funciones transforman los datos que fluyen hacia el sistema. En otros casos, las funciones activan algún nivel de control sobre el procesamiento interno del software o sobre los elementos externos del sistema.
2.4.3. Principio 3. Debe representarse el comportamiento del software (como consecuencia de eventos externos). El comportamiento del software de computadora está determinado por su interacción con el ambiente externo. Las entradas que dan los usuarios finales, el control de los datos efectuado por un sistema externo o la vigilancia de datos reunidos en una red son el motivo por el que el software se comporta en una forma específica.
2.4.4. Principio 4. Los modelos que representen información, función y comportamiento deben dividirse de manera que revelen los detalles en forma estratificada (o jerárquica). El modelado de los requerimientos es el primer paso para resolver un problema de ingeniería de software. Eso permite entender mejor el problema y proporciona una base para la solución (diseño).
2.4.5. Principio 5. El trabajo de análisis debe avanzar de la información esencial hacia la implementación en detalle. El modelado de requerimientos comienza con la descripción del problema desde la perspectiva del usuario final. Se describe la “esencia” del problema sin considerar la forma en la que se implementará la solución.