Integrantes:

Pulla CinthiaSarango Marcia

Colección de conceptos , principios, métodos y herramientas para la planeación y desarrollo del software.

La práctica multiplica un modelo de proceso de software con los cómos técnicos y de gestión necesarios para realizar el trabajo.

Transforma un enfoque casual en algo + organizado + efectivo y probablemente más exitoso.

George Polya – How to Solve it puntualizó la esencia de la Resolución de Problemas y en consecuencia la esencia de la Práctica de la ingeniería de Software.

1. Entender el problema (comunicación y Análisis.

2. Planear una solución (modelado y diseño de Software).

3. Llevar a cabo el plan (generación de código)4. Examinar el resultado para probar la

precisión (pruebas y aseguramiento de calidad)

¿A quien le interesa la solución del problema?

¿Qué aspectos se desconocen? ¿Qué datos necesitamos para resolver

el problema de manera apropiada? ¿El problema puede dividirse en

categorías? El problema puede representarse

gráficamente?

¿Ha existido un problema similar antes?

¿Se ha resuelto un problema similar?-reutilizarse

¿Se pueden definir los subproblemas? ¿Se puede representar una solución de

modo que conduzca a una implementación efectiva?

¿La solución marcha conforme el plan?. ¿Es probable que cada parte de la

solución del componente sea correcta?¿Se ha revisado el diseño y el código? ¿Se han aplicado pruebas de corrección?

¿Es posible probar cada parte de la solución del componente?

¿La solución produce resultados acordes con los datos, funciones , rasgos y comportamientos que se requieren?. ¿El software ha sido validado contra todos los requisitos de los clientes?

Principios se enfocan a la ingeniería de Software como un todo, actividades especificas del marco de trabajo, acciones de ingeniería de Software.

Ayudan a establecer un conjunto sólido de práctica de ingeniería del software.

David Hooker ha propuesto siete principios esenciales, los cuales se enfocan en la práctica de la ingeniería del software como un todo, que se reproducen enseguida.

Ofrecer un valor a los usuarios Antes de señalar una pieza de

funcionalidad del sistema, antes de determinar las plataformas del hardware o los procesos del desarrollo.

Preguntarnos ¿Esto agrega un valor real al sistema?

Todo el diseño debe ser tan simple como es posible, pero no más simple

Las características hasta las internas deben descartarse en nombre de la simplicidad.

El resultado buscado es un software que se mantenga y sea menos propenso al error.

Una visión clara es esencial para el éxito en un proyecto de Software

Podría arriesgarse a tener mas de dos diseños

Arriesgar la visión arquitectónica de un software debilita y al final rompe hasta un sistema bien diseñado.

Siempre debe especificarse, diseñarse e implementarse con la idea de que alguien mas tendrá que entender lo que se realice.

Se debe diseñar teniendo en mente a quienes lo implementen , así como como codificar considerando a aquellos que deben mantener y extender el sistema

El hecho de facilitar el trabajo a otro agrega valor al sistema.

Un sistema con una larga vida tiene mas valor

Las especificaciones cambian a cada momento y plataformas de hardware son obsoletas después de algunos meses

Un sistema tiene éxito si están listos para adaptarse a éstos y otros cambios.

Ahorra tiempo y esfuerzo La reutilización de código y diseños ha

sido proclamada como un beneficio importante de uso de tecnologías orientadas a objetos.

La planeación adelantada para la reutilización reduce el costo e incrementa el valor de los componentes reutilizables y los sistemas en que dichos componentes se incorporan.

Pensamiento claro y completo antes de la acción= Buenos Resultados

Siempre se obtiene conocimiento de la manera de hacerlo bien de nuevo .

Pensamiento claro se introduce en el sistema es cuando surge su valor real-

Reflexión intensa de los primeros 6 principios, recompensas potenciales son enormes.

Recopilación de los requisitos del cliente se dan por medio de una actividad de comunicación u obtención de requisitos.

Principio 1 :Escuchar. Centrar atención en las palabras de quien se habla, evitarse interrupciones, no se debe ser conflictiva con palabras o actitudes.

Principio 2: Prepararse antes de comunicar. Invertir tiempo en entender el problema.

Principio 3: Se debe contar con un líder o mediador en cada reunión de comunicación

Principio 4: Comunicación cara a cara. Tener presente otra representación de la información relevante.

Principio 5: Tomar notas y documentar decisiones. Principio 6: Buscar la colaboración. Principio 7: Conservar el enfoque , examinar un módulo a

la vez Principio 8: Si algo no esta claro, se hace un dibujo. Principio 9: Una vez que se llegue a un acuerdo sobre algo

se debe continuar; si no se llega a un acuerdo, si una característica o función no esta clara y no se puede clarificar se debe continuar.

Principio 10: La negociación no es un concurso o un juego. Funciona mejor cuando ambas partes ganan – Debe ajustarse el plan para adaptarse a los cambios.

La planeación abarca un conjunto de prácticas técnicas y fe gestión que permiten al equipo se software definir un mapa del camino.

La planeación debe producirse con moderación, lo suficiente para proporcionar una guía útil para el equipo.

Principio #1: Entender los alcances del proyectos. Principio #2: Involucrar al cliente en la actividad de

planeación Principio #3: Reconocer que la planeación es iterativa. –

Retroalimentación. Principio #4: Estimar con base en el conocimiento disponible –

proporcionar un indicio del esfuerzo, costo y duración de las tareas.

Principio #5: Considerar el riesgo cuando se define el plan – El plan debe ajustarse ante la posibilidad de que uno o mas de estos riesgos se torne un problema real.

Principio #6: Ser Realista Principio #7: Ajustar la granularidad mientras se define el plan Principio #8: Definir como se intentará asegurar la calidad. Principio #9: Describir como se pretende incluir el cambio Principio #10: Adoptar el plan a menudo y hacer los ajustes

cuando estos se requieren.

¿Por qué está en desarrollo este sistema? ¿Qué se hará? ¿Cuándo se terminará? ¿Quién es el responsable de una función? ¿En donde se ubican dentro de la organización? ¿Cómo se realizará el trabajo en los sentidos

técnico y de gestión? ¿Cuánto se necesitará de cada recurso?.

Mejor entendimiento de la entidad real que se construirá.

Cuando la entidad es un software , el modelo debe ser capaz de representar la información que el software transforma, la arquitectura y las funciones que permiten que ocurra la transformación , las características que desean los usuarios y el comportamiento del sistema conforme se realiza la transformación

Principio #1: El dominio de información de un problema debe representarse y entenderse

Principio #2: Se deben definir las funciones que ejecuta el software

Principio #3: Se debe representar el comportamiento del software

Principio #4: Los modelos que presentan información, función y comportamiento deben partirse de forma que descubran el detalle de una manera estratificada (o jerárquica) – “Divide y ganarás”

Principio #5: La tarea del análisis debe moverse de la información esencial hacia le detalle de la implementación.

El modelo de diseño que se crea para el software proporciona una variedad de diferentes vistas del sistema.

Principio #1: El diseño debe ser rastreable hasta el modelo del análisis

Principio #2: Siempre se debe considerar la arquitectura del sistema que se va a construir.

Principio #3: El diseño de datos es tan importante como el diseño de funciones de procesamiento

Principio #4: Las interfaces (internas y externas ) deben diseñarse con cuidado.

Principio #5: El diseño de interfaz del usuario debe ajustarse a las necesidades del usuario final-

Principio #6 : El diseño a nivel de componentes debe ser independiente del modo funcional.

Principio #7: Los componentes deben estar apareados entre sí en forma mínima y vinculados con el ambiente externo.

Principio#8: Las representaciones del diseño deben ser fácilmente comprensibles .

Principio #9 : El diseño debe desarrollarse de manera iterativa. En cada iteración el diseñador debe buscar la mayor simplicidad.

La actividad de construcción abarca una serie de tareas de codificación y realización de pruebas que conducen al software operativo que esta listo para entregarlo al usuario final.

Principios de preparación: Antes de escribir una línea de código se debe estar seguro de:

1. Entender el problema a resolver2. Entender principios y conceptos del diseño3. Escoger un lenguaje de programación que satisfaga las

necesidades del software4. Seleccionar un ambiente de programación que proporcione

herramientas que faciliten el trabajo-5. Crear un conjunto de pruebas que serán aplicadas una vez

que se complete el componente que se va a codificar.

Principios de codificación: Cuando se comience a escribir el código se debe estar seguro de:

1. Restringir los algoritmos al seguir la practica de la programación estructurada.

2. Seleccionar las estructuras de datos que satisfagan las necesidades del diseño

3. Entender la arquitectura y crear interfaces4. Mantener la lógica condicional tan simple como sea posible5. Crear ciclos anidados , de forma sean fáciles de probar6. Seleccionar nombres de variables significativas7. Escribir código que tenga documentación propia8. Crear una configuración lineal: sangrías , líneas en blanco

Principios de Validación: Después de haber completado los primeros pasos de código se debe estar seguro de:

1. Conducir un ensayo de código cuando sea apropiado

2. Realizar pruebas de unidad y corregir los errores

3. Re fabricar el código

Principio 1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente

Principio 2: Las pruebas se deben planear mucho antes de que comience el proceso de prueba.

Principio 3: Principio de Pareto , aplicable a las pruebas de software

Principio 4: Las pruebas deben comenzar “en lo pequeño” y progresar hacia lo “grande”.

Principio 5: Las pruebas exhaustivas no son posibles.

Principio 1: Se deben administrar las expectativas que el cliente tiene del software.

Principio 2: Se debe ensamblar y probar un paquete de entrega completo

Principio 3: Se debe establecer un régimen de soporte antes de entregar el software

Principio 4: Se debe proporcionar material instructivo apropiado a los usuarios finales

Principio 5. El software con errores se debe arreglar primero y entregarse después.

Se debe contar con una buena comunicación entre el cliente, usuario final y las personas que intervienen en el desarrollo de software

La documentación debe constantemente actualizarse en función de los ajustes que hagamos en nuestra planeación

Aplicar constantemente pruebas a nuestro software a fin de mejorar su funcionalidad y calidad.

gracias