1. Diagrama de Nassi Schneiderman
1.1. También conocido como el diagrama de Chapín; es como un diagrama de flujo en el que se omiten las flechas y las cajas son contiguas. Las acciones sucesivas se escriben en cajas sucesivas y, como en los diagramas de flujo, se pueden escribir diferentes acciones en una caja.
2. El ciclo de la vida del sofware
2.1. Existen dos niveles en la construcción de programas: aquellos relativos a pequeños (los que normalmente realizan programadores individuales) y aquellos que se refieren a sistemas de desarrollo de programas grandes (proyectos de software) y que, generalmente requieren de un equipo de programadores.
2.1.1. La programación a pequeña escala se preocupa de los conceptos que ayudan a crear pequeños programas, aquellos que varían en longitud desde pocas lineas a unas pocas paginas.
2.1.2. Los programas de gran escala requieren de unos principios sólidos y firmes de lo que se conoce como ingeniería de software y que constituye un conjunto de técnicas para facilitar el desarrollo de programas de computadora. Estos programas o mejor dicho, proyectos de software están realizados por equipos de personas dirigidos por un director de proyectos (analista o ingeniero de software) y los programas pueden tener mas de 100,000 lineas de código.
2.2. Analisis
2.2.1. Diseño
2.2.1.1. Implementacion
2.2.1.1.1. Depuración
2.2.1.1.2. La etapa de implementacion (codificación) traduce los algoritmos del diseño en un programa escrito en un lenguaje de programación
2.2.1.2. La especificación de un sistema indica lo que se debe hacer, El gasto de tiempo en la fase del diseño sera ahorro de tiempo cuando se escriba y depura su programa.
2.2.2. ¿Cuales son los datos de entrada?
2.2.3. ¿Que datos son validos y que datos no son validos?
2.2.4. ¿Que utilizara el sistema?
2.2.5. ¿Cuales son los mensajes de error y de detección de errores deseables?
2.2.6. ¿Que hipótesis son posibles?
2.2.7. ¿Existen casos especiales?
2.2.8. ¿Cual es el formato de salida?
2.2.9. ¿Que documentación es necesaria?
2.2.10. ¿Como debe de ser de rapido el sistema?
2.2.11. ¿Cada cuanto tiempo ha de cambiarse el sistema despues que se haya entregado?
3. Factores de calidad del sofware
3.1. Eficiencia
3.1.1. La eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula
3.2. Transportabilidad
3.2.1. Es la facilidad con la que un software puede ser transportado sobre diferentes sistemas operativos
3.3. Verificalidad
3.3.1. Es su capacidad para soportar los procedimientos de validacion y de aceptar juegos de test o ensayo de programas
3.4. Integridad
3.4.1. Es la capacidad de un software a proteger sus propios componentes contra los procesos que no tenga el derecho de acceder
3.5. Facil de usar
3.5.1. Un software es facil de usar si se puede comunicar consigo de manera comoda
3.6. Correccion
3.6.1. Capacidad de los productos software de realizar exactamente las tareas definidas por su especifiacion
3.7. Robustez
3.7.1. Capacidad de los productos software de funcionar incluso en situaciones anormales
3.8. Extensibilidad
3.8.1. Diseño simple
3.8.2. Descentralizacion
3.9. Reutalizacion
3.9.1. Capacidad de los productos de ser reutilizados
3.10. Compatibilidad
3.10.1. Facilidad de los productos para ser combinados con otros
4. Programación estructurada
4.1. Los términos programación modular; programación descendente y programación estructurada se introdujeron en la segunda mitad de la década de los sesenta y a menudo sus termino se utilizan como sinónimos aunque no signifiquen lo mismo.
4.1.1. El programa tiene un diseño modular
4.1.2. Los modulos son diseñados de modo descendente
4.1.3. Cada modulo se codifica utilizando las tres estructuras de control básicas:
4.1.3.1. Secuencia
4.1.3.2. Selección
4.1.3.3. Repetición
5. Programación modular
5.1. La programación modular es uno de los métodos de diseño mas flexible y potentes para mejorar la productividad de un programa.
6. Fases en resolución de problemas
6.1. Análisis del problema
6.1.1. El problema se analiza teniendo presente la especificación de los requisitos dados por el cliente de la empresa o por la persona que encarga el programa
6.2. Diseño del algoritmo
6.2.1. Una vez analizado el problema, se diseña una solución que conducirá un algoritmo que resuelva el problema
6.3. Codificación
6.3.1. La solución se escribe en la sintaxis del lenguaje de alto nivel (por ejemplo, C) y se obtiene un programa.
6.4. Compilación y ejecucion
6.4.1. El programa se ejecuta, se comprueba rigurosamente y se eliminan todos los errores (denominados "bugs", en ingles) que puedan aparecer
6.5. Verificacion
6.6. Depuracion
6.7. Documentacion
6.7.1. Escritura de las diferentes fases del ciclo de vida del software, esencialmente el análisis, diseño y codificación, unidos a manuales de usuario y de referencia, así como normas para el mantenimiento.
6.8. Mantenimiento
6.8.1. El programa se actualiza y modifica, cada vez que sea necesario, de modo que se cumplan todas las necesidades de cambio de sus usuarios
7. Representación gráfica de algoritmos
7.1. Para representar un algoritmo se debe utilizar algun metodo que permita independizar dicho algoritmo del lenguaje de programacion elegido
7.1.1. Diagrama de flujo
7.1.1.1. Es una de las técnicas de representación de algoritmos mas antigua y a la vez mas utilizada, aunque se empleo ha disminuido considerablemente, sobre todo, desde la aparición de lenguajes de programación estructurados.
7.1.2. Diagrama N-S (Nassi - Schneiderman)
7.1.3. Lenguaje de especificacion de algoritmos: pseudocodigo
7.1.4. Lenguaje español, ingles...
7.1.5. Formulas
8. Metodos formales de verificacion de programas
8.1. Aserciones
8.1.1. Un aserto se escribe como un comentario y describe lo que supone sea verdadero
8.2. Pre condiciones y postcondiciones
8.2.1. Son afirmaciones sencillas sobre condiciones al principio y al final de los modulos