Principios de Planeacin 1.- Entender el alcance del Proyecto. *Dejar Cerrado el Sistema *Hasta donde va a llegar nuestro Sistema.

2.- Involucrar en la Actividad de Planeacin a los participantes de software. *Inclur la Participacin del Grupo de trabajo. 3.- Reconocer que la planeacin es Iterativa. *Cada etapa del proceso requiere una retroalimentacin. *Tiempo Optimista - Tiempo Normal - Tiempo Pesimista 4.- Estimar con base a lo que sabe. *Definir tiempo En base a la Experiencia 5.- Al definir el Plan tomar en cuenta los riesgos. *Riesgos de Personal, Recursos Econmicos, De tiempo 6.- Ser Realista. *Tomar en cuenta cualquier situacin o imprevisto q se presente. *Un miembro del equipo Nunca va rendir al 100% en su totalidad. *En el tiempo. 7.- Ajustar la Granularidad cuando se define el Plan. *Definir el tiempo estimado correcto a cada etapa 8.- Definir como se va a controlar la calidad. *Desarrollar software de calidad *Al final de cada etapa realizar una Revisin Tcnica-Formal. 9.- Describir como se busca manejar el cambio. *Documentar los parmetros especficos del cambio para llevar un control. 10.- Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran. *No confiarse del Grupo de Trabajo hay q ver los avances. Principios de Modelado 1.- El equipo de software tiene como objetivo principal elaborar software no crear modelos. 2.- Viajar ligero no crear mas modelos de los necesarios. *Cree slo aquellos modelos que hagan mas fcil construir el software. 3.- Tratar de producir el modelo mas sencillo que describa al problema o al software. 4.- Construir Modelos Susceptibles al cambio. *Tiene que ser susceptible al cambio pero sin abusar. 5.- Ser capaz de enunciar un propsito explicito para cada modelo que se cree. *Los Modelos enunciados deben ser claros y aportar al sistema. 6.- Adaptar los modelos que se desarrollan al Sistema en cuestin. *Debemos adaptar los modelos al tipo de software a desarrollar. 7.- Tratar de construir modelos tiles pero olvidarse de elaborar modelos perfectos. *Un modelo simple puede ayudar mas que un modelo perfecto o complejo. 8.- No ser Dogmtico respecto de la sintaxis del modelo, si se tiene xito para comunicar contenido la representacin es secundaria. *Todo modelo tiene una sintaxis y semntica 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 preocupados. 10.- Obtener retroalimentacin tan pronto como sea posible. *En la actualidad el software se construye con un grupo de desarrollo. *Construir Modelos con la opcin de que otra persona lo evale. Requerimientos de los principios de Modelado

1.- Debe representarse y entenderse el dominio de informacin de un problema. *Entrada de datos --> Proceso --> Salida de Informacin 2.- Debe definirse las funciones que realizara el software. *(Clientes-Usuarios-Desarrolladores) Revisin Tcnica-Formal. 3.- Debe representarse el comportamiento del software (como consecuencia de eventos externos). *Desarrollo de Controles y Validaciones. 4.- Los modelos que representen informacin, funcin y comportamiento deben dividirse de manera que revelen los detalles en forma estratificada (o jerrquica). 5.- El trabajo de anlisis debe avanzar de la informacin esencial hacia la implementacin en detalle. Principios de modelado de Diseo. 1.- El diseo debe poderse rastrear hasta el modelo de requerimientos. 2.- Siempre tomar en cuenta la arquitectura del sistema que se va a construir. 3.- El diseo de los datos es tan importante como las funciones del procesamiento. 4.- Las interfaces tanto internas como externas deben disearse con cuidado. 5.- El diseo de la interfaz de usuario debe ajustarse a las necesidades del usuario final, sin embargo en todos los casos debe resaltar la facilidad de su uso. 6.- El diseo de nivel de componentes debe tener independencia funcional. *Que no este ligado al proyecto, sino que cada componente tiene su funcionalidad. 7.- Los componentes deben estar acoplados con holgura entre si y con el ambiente externo. *Niveles de acoplamiento entre componentes. *Entre mas niveles de acoplamiento exista, hay mas probabilidades de error. 8.- La representaciones del diseo (Modelos) deben entenderse con facilidad. *El diseo debe ser claro para agilizar el trabajo del programador. 9.- El diseo debe desarrollarse de forma iterativa, el diseador debe buscar mas sencillez en cada iteracin. Principios de Construccin Principios de Codificacin y Pruebas Los principios que guan el trabajo de codificacin se relacionan de cerca con el estilo, lenguajes y mtodos de programacin. Principios de Preparacin Antes de escribir una sola linea de codigo asegrese de: *Entender el problema que se trata de resolver. *Comprender los principios y conceptos bsicos del diseo. *Elegir un lenguaje de programacin que satisfaga las necesidades del software que se va a elaborar y el ambiente en que se operara. *Seleccionar un ambiente de programacin que disponga de herramientas que hagan mas fcil su trabajo. *Crear un conjunto de pruebas unitarias que se aplicara una ves que se haya terminado el componente a codificar. Principios de Programacin Cuando comience a escribir codigo asegrese de: *Restringir sus algoritmos por medio del uso de programacin estructurada. *Tomar en consideracin el uso de programacin por parejas. *Seleccionar estructura de datos que satisfagan las necesidades del diseo. *Entender la Arquitectura del software y crear interfaces que son congruentes con ella.

*Mantener la lgica condicional tan sencilla como sea posible. *Crear lazos anidados que se puedan probar con facilidad. *Seleccionar nombres significativos para las variables y seguir otros estndares locales de codificacin. *Escribe codigo que se documente a si mismo. *Crear una imagen visual (Lineas con sangra y en blanco) que ayuden a entender. Principio de Validacin Una vez que se haya terminado su primer intento de codificacin asegrese de: *Realizar el recorrido del codigo cuando sea apropiado. *Llevar a cabo pruebas unitarias y corregir los errores que se detecten. *Redisear el Codigo. Principios de la Prueba 1.- Todas las pruebas deben poder rastrearse hasta los requerimientos del cliente. 2.- Las pruebas deben planearse mucho antes de que den comienzo. 3.- El principio de pareto se aplica a las pruebas de software. 4.- Las pruebas deben comenzar "en lo pequeo" y avanzar hacia lo grande. 5.- No son posibles las pruebas exhaustivas. Deber Estndares de Codificacin y Programacin