principios que guian la practica ingenieria de software

principios que guian toda actividad estructural
1. principios de despliegue
  1. Deben manejarse las expectativas de los clientes.
    1. Debe ensamblarse y probarse el paquete completo que se entregará.
      1. entregarse 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.
      2. 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.
        Se deben proporcionar a los usuarios finales materiales de aprendizaje apropiados.
        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”
        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.
    2. Con demasiada frecuencia, el cliente espera más de lo que el equipo ha prometido entregar, y la desilusión llega de inmediato.
2. principios de comunicacion
  1. Escuchar
    1. Trate de centrarse en las palabras del hablante en lugar de formular su respuesa a dichas palabra.
  2. Alguien debe facilitar la actividad.
    1. Toda reunion de comunicacion debe tener un lider para mantener un rumbo en la comunicacion y mediar si ocurre algun problema
  3. Es mejor la comunicacion cara a cara.
    1. por lo general funciona mejor cuando esta presente alguna otra representacion de la informacion relevante.
  4. Tomar notas y documentar las decisiones
    1. Alguien que participe en la comunicación debe servir como “secretario” y escribir todos los temas y decisiones importantes
  5. Perseguir la colaboracion
    1. 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.
  6. Permanecer centrado; hacer modulos con la discusion.
    1. El facilitador debe formar módulos de conversación para abandonar un tema sólo después de que se haya resuelto
  7. Si algo no esta claro, hacer un dibujo.
    1. La comunicacion verbal tiene sus limites. Con frecuencia, un esquema o dibujo arroja claridad cuando l as palabras no bastan para hacer el trabajo.
  8. Una vez que se acuerde algo, avnazar. Si no es posible ponerse de acuerdo en algo, avanzar. Si una caracteristica o funcion no esta clara o no puede aclararse en el momento, avanzar.
    1. La comunicación, como cualquier actividad de ingeniería de software, requiere tiempo. En vez de hacer iteraciones sin fin, las personas que participan deben reconocer que hay muchos temas que requieren análisis y que “avanzar” es a veces la mejor forma de tener agilidad en la comunicación.
  9. La negociacion no es un concurso o un juego. Funciona mejor cuando las dos partes ganan.
    1. Hay muchas circunstancias en las que usted y otros participantes deben negociar funciones y caracteristicas, prioridades y fechas de entrega.
  10. Antes de comunicarse, prepararse.
    1. Dediquen algun tiempo a entender el problema antes de reunirse con otras personas.
3. principios de planeacion
  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. Involicrar en la actividad de planeacion a los participantes del software.
      1. Los participantes define las prioridades y establecen las restricciones del proyecto.
      2. 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.
        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.
        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 elaborar planes de contigencia.
        Ser realista.
        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.
        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.
        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.
        Describir como se busca manejar el cambio
        Aun la mejor planeacion puede se anulada por el cambio sin control.
        Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran.
        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. Cuando se detecten desviaciones, hay que ajustar el plan en consecuencia
4. principios de construccion
  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.
      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: Restringir sus algoritmos por medio del uso de programación estructurada Mantener la lógica condicional tan sencilla como sea posible
        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.
5. principios de modelado
  1. 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. 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. 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.
        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
        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).
        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.
  2. 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. Viajar ligero, no crear mas modelos de los necesarios.
      1. Todo modelo que se cree debe actualizarse si ocurren cambios.
      2. 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.
        Cosntruir modelos susceptibles al cambio.
        Suponga que sus modelos cambiaran, pero vigile que esta suposicion no lo haga descuidado.
        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.
        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.
        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
        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 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.
        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.
  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. 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. 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.
        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.
        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.
        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”.
        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.
principios fundamentales
1. debe adoptarse un conjunto de principios fundamentales que guíen el trabajo técnico para poder entregar a tiempo software operativo de alta caidad que contenga funciones y caracteristicas que satisfagan las necesidades de todos los participantes.
  1. divide y venceras
    1. el analisis y el diseño siempre deben enfatizar la separacion de entidades.
  2. entender el uso de la abstraccion
    1. una abstraccion es una simplificacion de algun elemento complejo de un sistema usado para comunicar significado en una sola frase.En la práctica de la ingeniería de software, se usan muchos niveles diferentes de abstracción, cada uno de los cuales imparte o implica significado que debe comunicarse.
  3. construir SW que tenga modularidad
    1. La separacion de entidades establece un filosofia para el software. La modularidad proporciona un mecanismo para llevar a cabo dicha filosofia.
  4. buscar patrones
    1. se trata de crear un cumulo de bibliografia que ayude a los desarrolladores de software a resolver problemas recurrentes que surgen a lo largo del desarrollo.
  5. buscar coherencia
    1. el principio de coherencia sugiere que un contexto familiar hace que el software sea mas facil de usar.
  6. centrarse en la transferencia de la informacion
    1. la información fluye a través de una interfaz, y como consecuencia hay posibilidades de cometer errores, omisiones o ambigüedades. Este principio implica que debe ponerse atención especial al análisis, diseño, construcción y prueba de las interfaces.
  7. representar el problema y su solucion desde diferentes perspectivas
    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. tener en mente el hecho de que se tendra que hacer mantenimiento al SW
    1. las actividades de mantenimiento resultan más fáciles si se aplica una práctica sólida de ingeniería de software a lo largo del proceso de software
2. principios que guian el proceso
  1. ser agil
    1. 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. estar listo para adaptar
    1. Cuando sea necesario, adapte su enfoque del proyecto a las restricciones impuestas por el problema, la gente y el proyecto en si.
  3. 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.
  4. 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.
  5. formar un equipo eficaz
    1. Forme un equipo con organizacion propia en el que haya confianza y respecto mutuos.
  6. evaluar el riesgo
    1. Son muchas las cosas que pueden salir mal cuando se desarrolla software. Es esencial establecer planes de contigencia.
  7. crear productos del trabajo que agruegen valor para otros
    1. Solo genere aquellos productos del trabajo que agreguen valor para otras actividades, acciones o tareas del proceso, ya que esto lo utilizara alguien mas.
  8. mecanismos de comunicacion y coordinacion
    1. Los proyectos fallan porque la informacion importante cae en las grietas o porque los participantes no coordinan sus esfuerzos para crear un producto final exitoso, es por eso que se deben crear mecanismos de comunicacion eficaces

Next up

principios que guian la practica ingenieria de software

Description

Resource summary

Similar

	Created by Alejandro Botia over 8 years ago