PRACTICA DE INGENIERÍA DE SOFTWARE

Conjunto amplio de principios, conceptos, métodos y herramientas que deben considerarse al planear y desarrollar software.
Principios Fundamentales: 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. Principios Que Guían el Proceso:
  1. Los siguientes principios fundamentales se aplican a la estructura y, por extensión, a todo proceso de software:
    1. 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.
      1. 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.
        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í.
        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.
        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.
        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.
        Principio 7. Evaluar el riesgo. Son muchas las cosas que pueden salir mal cuando se desarrolla software. Es esencial establecer planes de contingencia.
        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.
2. Principios que guían la práctica
  1. tiene un solo objetivo general: entregar a tiempo software operativo de alta calidad que contenga funciones y características que satisfagan las necesidades de todos los participantes. Para lograrlo, debe adoptarse un conjunto de principios fundamentales que guíen el trabajo técnico.
    1. 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. 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. Cuando se usa la abstracción hoja de cálculo, se supone que se comprende lo que es una hoja de cálculo, la estructura general de contenido que presenta y las funciones comunes que se aplican a ella.
        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.
        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.
        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.
        Principio 6. Buscar patrones. Brad Appleton [App00] sugiere que: 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.
        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.
        Principio 8. Tener en mente que alguien dará mantenimiento al software. El software será corregido en el largo plazo, cuando se descubran sus defectos, se adapte a los cambios de su ambiente y se mejore en el momento en el que los participantes pidan más capacidades.
PRINCIPIOS QUE GUÍAN TODA ACTIVIDAD ESTRUCTURAL: los principios que tienen mucha relevancia para el éxito de cada actividad estructural genérica, definida como parte del proceso de software.
1. Principios de comunicación: Un cliente tiene un problema que parece abordable mediante una solución basada en computadora. Usted responde a la solicitud de ayuda del cliente. Ha comenzado la comunicación.
  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.
    1. 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.
      1. Principio 3. Alguien debe facilitar la actividad. Toda reunión de comunicación debe tener un líder (facilitador) 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.
        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.
        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.
        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.
        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.
        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.
        Principio 9. a) Una vez que se acuerde algo, avanzar. b) Si no es posible ponerse de acuerdo en algo, avanzar. c) Si una característica o función no está clara o no puede aclararse en el momento, avanzar.
        Principio 10. La negociación no es un concurso o un juego. Funciona mejor cuando las dos partes ganan. Hay muchas circunstancias en las que usted y otros participantes deben negociar funciones y características, prioridades y fechas de entrega.
2. Principios de planeación: ayuda a definir las metas y objetivos generales (por supuesto, sujetos al cambio conforme pasa el tiempo). Sin embargo, la comprensión de estas metas y objetivos no es lo mismo que definir un plan para lograrlo. La actividad de planeación incluye un conjunto de prácticas administrativas y técnicas que permiten que el equipo de software defina un mapa mientras avanza hacia su meta estratégica y sus objetivos tácticos.
  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.
    1. 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.
      1. 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.
        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.
        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.
        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.
        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).
        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.
        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.
        Principio 10. Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran. Los proyectos de software se atrasan respecto de su programación. Por tanto, tiene sentido evaluar diariamente el avance, en busca de áreas y situaciones problemáticas en las que las actividades programadas no se apeguen al avance real.
3. Principios de modelado: Se crean modelos para entender mejor la entidad real que se va a construir. Cuando ésta es física (por ejemplo, un edificio, un avión, una máquina, etc.), se construye un modelo de forma idéntica pero a escala. Sin embargo, cuando la entidad que se va a construir es software, el modelo debe adoptar una forma distinta.
  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.
    1. 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).
      1. Principio 3. Tratar de producir el modelo más sencillo que describa al problema o al software. No construya software en demasía [Amb02b]. 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).
        Principio 4. Construir modelos susceptibles al cambio. Suponga que sus modelos cambiarán, pero vigile que esta suposición no lo haga descuidado.
        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.
        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.
        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.
        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.
        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
        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.

Nächster

PRACTICA DE INGENIERÍA DE SOFTWARE

Beschreibung

Zusammenfassung der Ressource

ähnlicher Inhalt

	Erstellt von Abner Gustavo Cuxum Larios vor fast 7 Jahre