1. Programación modular
1.1. La programación modular es uno de los métodos de diseño más flexible y potentes para mejorar la productividad de un programa.
1.1.1. En programación modular el programa se divide en módulos (partes independientes), cada una de las cuales ejecuta una Única actividad o tarea y se codifican independientemente de otros módulos.
1.1.1.1. Se diseña cada módulo con independencia de los demás, y siguiendo un método ascendente o descendente se llegará hasta la descomposición final del problema en módulos en forma jerárquica.
1.1.1.1.1. Los módulos son independientes en el sentido en que ningún módulo puede tener acceso directo a cualquier otro módulo excepto el módulo al que llama y sus propios submódulos.
2. Programación estructurada
2.1. Estas técnicas aumentan considerablemente la productividad del programa reduciendo en elevado grado el tiempo requerido para escribir, verificar, depurar y mantener los programas.
2.1.1. Recursos abstractos
2.1.1.1. Consiste en descomponer una determinada acción compleja en términos de un número de acciones más simples capaces de ejecutarlas o que constituyan instrucciones de computadoras disponibles.
2.1.2. Diseño descendente (Top-down)
2.1.2.1. Consiste en efectuar una relación entre las sucesivas etapas de estructuración de modo que se relacionasen unas con otras mediante entradas y salidas de información.
2.1.3. Estructuras de control
2.1.3.1. La programación estructurada hace los programas más fáciles de escribir, verificar, leer y mantener; utiliza un número limitado de estructuras de control que minimizan la complejidad de los problemas.
2.1.3.1.1. Seleccion
2.1.3.1.2. Secuencia
2.1.3.1.3. Repeticion
3. El ciclo de vida de un software
3.1. Analisis
3.1.1. En esta etapa se trata de analizar cual es problema que se quiere resolver y cuales son los requisitos necesarios
3.2. Diseño
3.2.1. Es preciso determinar si se pueden utilizar programas o subprogramas que ya existen o es preciso construirlos totalmente. El proyecto se ha de dividir en módulos utilizando los principios de diseño descendente
3.3. Implementación (Codificación)
3.3.1. Los algoritmos y las estructuras de datos realizadas en pseudocódigo han de traducirse codificados en un lenguaje que entiende la computadora: PASCAL, FORTRAN, COBOL, C, C++, C# o Java.
3.4. Pruebas e integración
3.4.1. La fase de pruebas es una parte esencial de un proyecto de programación. Durante la fase de pruebas se necesita eliminar tantos errores lógicos como pueda.
3.5. Verificacion
3.5.1. La verificación formal implica la aplicación de reglas formales para mostrar que un programa cumple su especificación: la verificación. La verificación formal funciona bien en programas pequeños, pero es compleja cuando se utiliza en programas grandes
3.6. Mantenimiento
3.6.1. Cuando el programa tiene tantos usuarios después de cierto tiempo se le tiene que dar mantenimiento y este es costoso pero de no hacerse el programa pasa a la etapa de obsolescencia.
3.7. Obsolescencia
3.7.1. fase en la que el software se queda anticuado y es preciso actualizarlo o escribir un nuevo programa sustitutorio del antiguo.
4. Factores en la calidad del software
4.1. Eficiencia
4.1.1. La eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula.
4.2. Transportabilidad
4.2.1. La eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula.
4.3. Verificabilidad
4.3.1. es su capacidad para soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas.
4.4. Integridad
4.4.1. La integridad es la capacidad de un software a proteger sus propios componentes contra los procesos que no tenga el derecho de acceder.
4.5. Facil de utilizar
4.5.1. Un software es fácil de utilizar si se puede comunicar consigo de manera cómoda.
4.6. Correccion
4.6.1. Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.
4.7. Extensibilidad
4.7.1. Facilidad que tienen los productos de adaptarse a cambios en su especificación.
4.8. Reutilizacion
4.8.1. Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
4.9. Compatibilidad
4.9.1. Facilidad de los productos para ser combinados con otros.
5. Fases en la resolución de problemas
5.1. Análisis del problema
5.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.
5.2. Diseño del algoritmo
5.2.1. Una vez analizado el problema, se diseña una solución que conducirá a un algoritmo que resuelva el problema.
5.3. Codificacion
5.3.1. La solución se escribe en la sintaxis del lenguaje de alto nivel (por ejemplo, C) y se obtiene un programa.
5.4. Ejecucion, verificacion y depuracion
5.4.1. El programa se ejecuta, se comprueba rigurosamente y se eliminan todos los errores (denominados «bugs», en inglés) que puedan aparecer.
5.5. Mantenimiento
5.5.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.
5.6. Documentacion
5.6.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. Representacion grafica de los algoritmos
6.1. Para conseguir este objetivo se precisa que el algoritmo sea representado gráfica o numéricamente, de modo que las sucesivas acciones no dependan de la sintaxis de ningún lenguaje de programación, sino que la descripción pueda servir fácilmente para su transformación en un programa, es decir, su codificación.
6.1.1. Diagrama de flujo
6.1.1.1. Es una de las técnicas de representación de algoritmos más antigua y a la vez más utilizada, aunque su empleo ha disminuido considerablemente, sobro todo, desde la aparición de lenguajes de programación estructurados.
7. DIAGRAMAS DE NASSI-SCHNEIDERMAN (N-S)
7.1. Es como un diagrama de flujo en el que se omiten las flechas de unión y las cajas son contiguas.
7.2. Las acciones sucesivas se escriben en cajas sucesivas y, como en los diagramas de flujo, se pueden escribir diferentes acciones en una caja.
8. MÉTODOS FORMALES DE VERIFICACIÓN DE PROGRAMAS
8.1. Aserciones
8.1.1. Un aserto se escribe como un comentario y describe lo que se supone sea verdadero sobre las variables del programa en ese punto.
8.2. Precondiciones
8.2.1. Una precondición de un procedimiento es una afirmación lógica sobre sus parámetros de entrada; se supone que es verdadera cuando se llama al procedimiento.
8.3. Postcondiciones
8.3.1. Una postcondición de un procedimiento puede ser una afirmación lógica que describe el cambio en el estado del programa producido por la ejecución del procedimiento
8.4. Reglas para pruebas de programas
8.4.1. Un medio útil para probar que un programa P hace lo que realmente ha de hacer es proporcionar aserciones que expresen las condiciones antes y después de que P sea ejecutada. En realidad las aserciones son como sentencias o declaraciones que pueden ser o bien verdaderas o bien falsas
8.5. Invariantes de bucles
8.5.1. Una invariante de bucle es una condición que es verdadera antes y después de la ejecución de un bucle. Las invariantes de bucles se utilizan para demostrar la corrección (exactitud) de algoritmos iterativos.
8.6. Programacion segura contra fallos
8.6.1. Un programa es seguro contra fallos cuando se ejecuta razonablemente por cualquiera que lo utilice. Para conseguir este objetivo se han de comprobar los errores en datos de entrada y en la lógica del programa.