La practica una vision general

2.  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.

3.  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)

4.  ¿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?

5.  ¿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?

6.  ¿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?

7.  ¿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?

8.  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.

9.  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?

10.  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.

11.  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.

12.  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.

13.  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.

14.  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.

15.  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.

17.  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

18.  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.

19.  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.

20.  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.

21.  ¿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?.

22.  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

23.  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.

24.  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.

25.  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.

26.  Principios de preparación: Antes de escribir una línea de
código se debe estar seguro de:
1. Entender el problema a resolver
2. Entender principios y conceptos del diseño
3. Escoger un lenguaje de programación que satisfaga las
necesidades del software
4. 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.

27.  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 interfaces
4. Mantener la lógica condicional tan simple como sea posible
5. Crear ciclos anidados , de forma sean fáciles de probar
6. Seleccionar nombres de variables significativas
7. Escribir código que tenga documentación propia
8. Crear una configuración lineal: sangrías , líneas en blanco

28.  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

29.  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.

30.  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.

31.  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.