PRINCIPIOS QUE GUIAN LA PRACTICA

Es un conjunto de conceptos, principios, metodos y herramientas a los que un ingeniero de software recurre en forma cotidiana.
4.1 CONOCIMIENTO DE LA INGENIERIA DE SOFTWARE
1. El cuerpo de conocimientos de la ingenieria de software ha evolucionado para convertirse en un "nucleo estable" que representa cerca de "75% del conocimiento necesario para desarrollar un sistema complejo".
4.2 PRINCIPIOS FUNDAMENTALES
1. Definen un conjunto de valores y reglas que sirven como guia cuando se analiza un problema, se disena una salucion, se implementa y prueba esta y cuando, al final, se entrega el software a la comunidad de usuarios.
  1. 4.2.1 Principios que guian el proceso
    1. Principio 1. Ser agil
      1. Ya sea que el modelo de proceso que se elija sea prescriptivo o agil, son los principios basicos del desarrollo agil los que deben gonernar el enfoque. Todo aspecto del trabajo que se haga debe poner el enfasis en la economia de accion en mantener el enfoque tecnico tan sencillo como sea posible, hacer los productos del trabajo que se genran tan concisos como se pueda y tomar las decisiones localmente, siempre que sea posible.
    2. Principio 2. En cada etapa, centrarse en la calidad.
      1. La condicion de salida para toda actividad, accion y tarea del proceso debe centrarse en la calidad del producto del trabajo que se ha generado.
    3. Principio 3. Estar listo para adaptar.
      1. El proceso no es una experiencia religiosa, en el 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 si.
    4. Principio 4. Formar un equipo eficaz
      1. El proceso y practica de la ingenieria de software son importantes, pero el objetivo son las personas. Forme un equipo con organizacion propia en el que haya confianza y respecto mutuos.
    5. Principiio 5. Establecer mecanismos para la comunicacion y coordinacion.
      1. Los propyectos fallan porque la informacion importante cae en las grietas o porque los participantes no coordinan sus esfuerzos para crear un producto final exitoso.
    6. Principio 6. Administrar el cambio.
      1. El enfoque puede ser formal o informal, pero deben establecerse mecanismos para administrar la forma en la que los cambios se solicitan, evaluan, aprueban e implementan.
    7. Principio 7. Evaluar el riesgo.
      1. Son muchas las cosas que pueden salir mal cuando se desarrolla software. Es esencial establecer planes de contigencia.
    8. Principio 8. Crrear productos del trabajo que agreguen valor para otros.
      1. Solo 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 practica de ingenieria de software pasara a alguieen mas.
2. 4.2.2 Principios quee guian la practica
  1. La practica de la ingenieria de software tiene un solo objetivo general entregar a tiempo software operativo de alta caidad que contenga funciones y caracteristicas que satisfagan las necesidades de todos los participantes.
    1. Principio 1. Divide y venceras.
      1. Dicho en forma mas tecnica, el analisis y el diseno siepre deben enfatizar la separacion de entidades.
    2. Principio 2. Entender el uso de la abstraccion.
      1. En su parte medulas, una abstraccion es una simplificacion de algun elemento complejo de un sistema usado para comunicar significado en una sola frase.
    3. Principio 3. Buscar la coherencia.
      1. Ya sea que se este creando un modelo de los requerimientos, se desarrolle un diseno de software, se genere codigo fuente o se elaboren casos de prueba, el principio de coherencia sugiere que un contexto familiar hace que el software sea mas facil de usar.
    4. Principio 4. Centrase en la transferencia de informacion.
      1. El software tiene que ver con la transferencia de informacion: de una base de datos a un usuario final, de un sistea heredado a una web|app, de un usuario final a una interfaz grafica de usuario.
    5. Principio 5. Construir software que tenga modularidad eficaz.
      1. La separacionde entidades establece un filosofia para el software. La modularidad proporciona un mecanismo para llevar a cabo dicha filosofia.
    6. Principio 6. Buscar patrones.
      1. El objetivo de los patrones dentro de una comunidad de software es crear un cumulo de bibliografia que ayude a los desarrolladores de software a resolver problemas recurrentes que surgen a lo largo del desarrollo.
    7. Principio 7. Cuando sea posible, representar el problema y su solucion desde varias perspectivas diferentes.
      1. Cuando un problema y su solucion se estudian desde varias perspectivas distintas, es mas probable que se tenga mayor vision y que se detecten los errores y omisiones.
    8. Principio 8. Tener en emnte que alguien dara mantenimiento al software.
      1. El software sera 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 qque los participantes pidan mas capacidades.
4.3 PRINCIPIOS QUE GUIAN TODA ACTIVIDAD ESTRUCTURAL
1. 4.3.1 Principios de comunicacion.
  1. Antes de que los requerimientos del cliente se analicen, modelen o especifiquen, deben recabarse a traves de la actividad de comunicacion.
    1. Principio1. Escuchar.
      1. Trate de centrarse en las palabras del hablante en lugar de formular su respuesa a dichas palabra.
      2. Principio 2. Antes de comunicarse, prepararse.
        Dediquen algun tiempo a entender el problema antes de reunirse con otras personas.
        Principio 3. Alguien debe facilitar la actividad.
        Toda reunion de comunicacion debe tener un lider (facilitador).
        Principio 4. Es mejor la comunicacion cara a cara.
        Pero por lo general funciona mejor cuando esta presente alguna otra representacion de la informacion relevante.
        Principio 5. Tomar notas y documentar las decisiones.
        Las cosas encuentran el modo de caer en las grietas.
        Principio 6. Perseguir la colaboracion.
        La colaboracion y el consenso ocurren cuando el conocimiento colectivo de los miembros del equipo se utilizan para describir funciones o caracteristicas del producto o sistema.
        Principio 7. Permanecer centrado; hacer modulos con la discusion.
        Entre mas personas participen en cualquier comunicacion, mas probable es que la conversacion salte de un tema a otro.
        Principio 8. Si algo no esta claro, hacer un dibujo.
        La comunicacion verbal tiene sus limites. Con frecuencia, un esquema o dibujo arroja claridad cuando l as palabras no bastan para hacer el trabajo.
        Principio 9. a) Una vez que se acuerde algo, avnazar. b) Si no es posible ponerse de acuerdo en algo, avanzar. c) Si una caracteristica o funcion no esta clara o no puede aclararse en el momento, avanzar.
        La comunicacion, como cualquier actividad de ingenieria de software, rquier tiempo.
        Principio 10. La negociacion no es un concurso o un juego. Funciona mejor cuando las doas partes ganan.
        Hay muchas circunstancias en las que usted y otros participantes deben negociar funciones y caracteristicas, prioridades y fechas de entrega.
2. 4.3.2 Principios de planeacion.
  1. Principio 1. Entender el alcance del proyecto.
    1. Es imposible usar el mapa si no se sabe a donde se va. El alcance da un destino al equipo de software.
    2. Prioridad 2. Involicrar en la actividad de planeacion a los participantes del software.
      1. Los participantes define las prioridades y establecen las restricciones del proyecto.
      2. Principio 3. Reconocer que la planeacion es iterativa.
        Un plan para el proyecto nunca esta grabado en piedra. Para cuando el trabajo comience, es muy probable que las cosas hayan cambiando.
        Principio 4. Estimar con base en lo que se sabe.
        El objetivo de la estimacion es obtener un indice del esfuerzo, costo y duracion de las tareas, con base en la compresion 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 tendrian un efecto grande y es muy probable que ocurran, entonces es necesario elborar planes de contigencia.
        Principio 6. Ser realista.
        Las personas no trabajan 100% todos los dias. En cualquier comunicacion humana hay ruido.
        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.
        Principio 8. definir como se trata de asegurar la calidad.
        El plan debe identificar la forma en la que el equipo de software busca asegurar la calidad.
        Principio 9. Describir como se busca manejar el cambio.
        Aun la mejor planeacion puede se anulada por el cambio sin control.
        Principio 10. Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran.
        Los proyectos de software se atrasan respecto de su programacion.
3. 4.3.3 Principio de modelado
  1. Principio 1. El equipo de software tiene como objetivo principal elaborar software, no crear modelos.
    1. Agilidad significa entregar software al cliente de la manera mas rapida posible.
    2. Principio 2. Viajar ligero, no crear mas modelos de los necesarios.
      1. Todo modelo que se cree debe actualizarse si ocurren cambios.
      2. Principio 3. Tratar de producir el modelo mas sencillo que describa al problema o al software.
        No construya software en demasia. Al mantener sencillos los modelos, el software resultante tambien lo sera.
        Principio 4. Cosntruir modelos susceptibles al cambio.
        Suponga que sus modelos cambiaran, pero vigile que esta suposicion 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. Si
        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. Requerimientos de los principios de modelado. En las últimas tres décadas se han desarrollado numerosos métodos de modelado de requerimientos. Los investigadores han identificado los problemas del análisis de requerimientos y sus causas, y han desarrollado varias notaciones de modelado y los conjuntos heurísticos correspondientes para resolver aquéllos.
    1. Principio 1. Debe representarse y entenderse el dominio de información de un problema.
      1. 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. 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.
        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
        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).
        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.
  3. Principios del modelado del diseño. El modelo del diseño del software es análogo a los planos arquitectónicos de una casa. Se comienza por representar la totalidad de lo que se va a construir (por ejemplo, un croquis tridimensional de la casa) que se refina poco a poco para que guíe la construcción de cada detalle (por ejemplo, la distribución de la plomería).
    1. Principio 1. El diseño debe poderse rastrear hasta el modelo de requerimientos.
      1. El modelo de requerimientos describe el dominio de información del problema, las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases de requerimientos que agrupa los objetos del negocio con los métodos que les dan servicio.
      2. Principio 2. Siempre tomar en cuenta la arquitectura del sistema que se va a construir.
        La arquitectura del software es el esqueleto del sistema que se va a construir. Afecta interfaces, estructuras de datos, flujo de control y comportamiento del programa, así como la manera en la que se realizarán las pruebas, la susceptibilidad del sistema resultante a recibir mantenimiento y mucho más.
        Principio 3. El diseño de los datos es tan importante como el de las funciones de procesamiento.
        El diseño de los datos es un elemento esencial del diseño de la arquitectura. La forma en la que los objetos de datos se elaboran dentro del diseño no puede dejarse al azar. Un diseño de datos bien estructurado ayuda a simplificar el flujo del programa, hace más fácil el diseño e implementación de componentes de software y más eficiente el procesamiento conjunto.
        Principio 4. Las interfaces (tanto internas como externas) deben diseñarse con cuidado.
        La manera en la que los datos fluyen entre los componentes de un sistema tiene mucho que ver con la eficiencia del procesamiento, la propagación del error y la simplicidad del diseño.
        Principio 5. El diseño de la interfaz de usuario debe ajustarse a las necesidades del usuario final. Sin embargo, en todo caso debe resaltar la facilidad de uso.
        La interfaz de usuario es la manifestación visible del software. No importa cuán sofisticadas sean sus funciones internas, ni lo incluyentes que sean sus estructuras de datos, ni lo bien diseñada que esté su arquitectura, un mal diseño de la interfaz con frecuencia conduce a la percepción de que el software es “malo”.
        Principio 6. El diseño en el nivel de componentes debe tener independencia funcional.
        La independencia funcional es una medida de la “mentalidad única” de un componente de software. La funcionalidad que entrega un componente debe ser cohesiva, es decir, debe centrarse en una y sólo una función o subfunción.
        Principio 7. Los componentes deben estar acoplados con holgura entre sí y con el ambiente externo.
        El acoplamiento se logra de muchos modos: con una interfaz de componente, con mensajería, por medio de datos globales, etc. A medida que se incrementa el nivel de acoplamiento, también aumenta la probabilidad de propagación del error y disminuye la facilidad general de dar mantenimiento al software.
        Principio 8. Las representaciones del diseño (modelos) deben entenderse con facilidad.
        El propósito del diseño es comunicar información a los profesionales que generarán el código, a los que probarán el software y a otros que le darán mantenimiento en el futuro. Si el diseño es difícil de entender, no servirá como medio de comunicación eficaz.
        Principio 9. El diseño debe desarrollarse en forma iterativa. El diseñador debe buscar más sencillez en cada iteración.
        Igual que ocurre con casi todas las actividades creativas, el diseño ocurre de manera iterativa. Las primeras iteraciones sirven para mejorar el diseño y corregir errores, pero las posteriores deben buscar un diseño tan sencillo como sea posible.
4. 4.3.4 Principios de construcción
  1. La actividad de construcción incluye un conjunto de tareas de codificación y pruebas que lleva a un software operativo listo para entregarse al cliente o usuario final.
    1. Principios de codificación. Los principios que guían el trabajo de codificación se relacionan de cerca con el estilo, lenguajes y métodos de programación. Sin embargo, puede enunciarse cierto número de principios fundamentales:
      1. Principios de preparación: Antes de escribir una sola línea de código, asegúrese de: • Entender el problema que se trata de resolver. • Comprender los principios y conceptos básicos del diseño. • Elegir un lenguaje de programación que satisfaga las necesidades del software que se va a elaborar y el ambiente en el que operará. • Seleccionar un ambiente de programación que disponga de herramientas que hagan más fácil su trabajo. • Crear un conjunto de pruebas unitarias que se aplicarán una vez que se haya terminado el componente a codificar.
        Principios de programación: Cuando comience a escribir código, asegúrese de: • Restringir sus algoritmos por medio del uso de programación estructurada [Boh00]. • Tomar en consideración el uso de programación por parejas. • Seleccionar estructuras de datos que satisfagan las necesidades del diseño. • Entender la arquitectura del software y crear interfaces que son congruentes con ella. • Mantener la lógica condicional tan sencilla como sea posible. Cita: “Durante gran parte de mi vida he sido un mirón del software, y observo furtivamente el código sucio de otras personas. A veces encuentro una verdadera joya, un programa bien estructurado escrito en un estilo consistente, libre de errores, desarrollado de modo que cada componente es sencillo y organizado, y que está diseñado de modo que el producto es fácil de cambiar.” David Parnas Evite desarrollar un programa elegante que resuelva el problema equivocado. Ponga especial atención al primer principio de preparación.
        Principios de validación: Una vez que haya terminado su primer intento de codificación, asegúrese de: • Realizar el recorrido del código cuando sea apropiado. • Llevar a cabo pruebas unitarias y corregir los errores que se detecten. • Rediseñar el código.
        Principios de la prueba. En un libro clásico sobre las pruebas de software, Glen Myers enuncia algunas reglas que sirven bien como objetivos de prueba: • La prueba es el proceso que ejecuta un programa con objeto de encontrar un error. • Un buen caso de prueba es el que tiene alta probabilidad de encontrar un error que no se ha detectado hasta el momento. • Una prueba exitosa es la que descubre un error no detectado hasta el momento.
  2. 4.3.5 Principios de despliegue
    1. Principio 1. Deben manejarse las expectativas de los clientes.
      1. Con demasiada frecuencia, el cliente espera más de lo que el equipo ha prometido entregar, y la desilusión llega de inmediato.
      2. Principio 2. Debe ensamblarse y probarse el paquete completo que se entregará.
        Debe ensamblarse en un CD-ROM u otro medio (incluso descargas desde web) todo el software ejecutable, archivos de datos de apoyo, documentos de ayuda y otra información relevante, para después hacer una prueba beta exhaustiva con usuarios reales.
        Principio 3. Antes de entregar el software, debe establecerse un régimen de apoyo.
        Un usuario final espera respuesta e información exacta cuando surja una pregunta o problema. Si el apoyo es ad hoc, o, peor aún, no existe, el cliente quedará insatisfecho de inmediato.
        Principio 4. Se deben proporcionar a los usuarios finales materiales de aprendizaje apropiados.
        El equipo de software entrega algo más que el software en sí. Deben desarrollarse materiales de capacitación apropiados (si se requirieran); es necesario proveer lineamientos para solución de problemas y, cuando sea necesario, debe publicarse “lo que es diferente en este incremento de software”.8
        Principio 5. El software defectuoso debe corregirse primero y después entregarse.
        Cuando el tiempo apremia, algunas organizaciones de software entregan incrementos de baja calidad con la advertencia de que los errores “se corregirán en la siguiente entrega”. Esto es un error.

Nächster

PRINCIPIOS QUE GUIAN LA PRACTICA

Beschreibung

Zusammenfassung der Ressource

ähnlicher Inhalt

	Erstellt von richard simbaña vor etwa 11 Jahre