1. PROGRAMACIÓN MODULAR
1.1. Que es
1.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. 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. Cada uno de estos módulos se analizan, codifican y ponen a punto por separado.
1.1.1.1. como funciona
1.1.1.1.1. Cada programa contiene un módulo denominado programa principal que controla todo lo que sucede; se transfiere el control a submódulos (posteriormente se denominarán subprogramas), de modo que ellos puedan ejecutar sus funciones; sin embargo, cada submódulo devuelve el control al módulo principal cuando se haya completado su tarea. Si la tarea asignada a cada submódulo es demasiado compleja, éste deberá romperse en otros módulos más pequeños.
1.1.1.1.2. 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. Sin embargo, los resultados producidos por un módulo pueden ser utilizados por cualquier otro módulo cuando se transfiera a ellos el control.
1.1.1.1.3. Dado que los módulos son independientes, diferentes programadores pueden trabajar simultáneamente en diferentes partes del mismo programa. Esto reducirá el tiempo del diseño del algoritmo y posterior codificación del programa. Además, un módulo se puede modificar radicalmente sin afectar a otros módulos, incluso sin alterar su función principal.
2. EL CICLO DE VIDA DEL SOFTWARE
2.1. Existen dos niveles en la construcción de programas.
2.1.1. los de primer: nivel los pequeños programas o los que normalmente realizan programadores individuales que se denomina programación a pequeña escala.
2.1.1.1. La programación en pequeña escala se preocupa de los conceptos que ayudan a crear pequeños programas aquellos que varían en longitud desde unas pocas líneas a unas pocas páginas. En estos programas se suele requerir claridad y precisión mental y técnica.
2.1.1.1.1. Diseño
2.1.2. el segundo nivel: los que se refieren a sistemas de desarrollo de programas grandes y que, generalmente, requieren un equipo de programadores en lugar de personas individuales y se denomina programación a gran escala.
2.1.2.1. Estos programas o mejor 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 más de 100.000 líneas de código.
2.1.2.1.1. Diseño
2.2. Análisis
2.2.1. La primera etapa en la producción de un sistema de software es decidir exactamente qué se supone ha de hacer el sistema. Esta etapa se conoce también como análisis de requisitos o especificaciones y por esta circunstancia muchos tratadistas suelen subdividir la etapa en otras dos:
2.2.1.1. Análisis y definición del problema
2.2.1.1.1. Normalmente la definición del problema comienza analizando los requisitos del usuario, pero estos requisitos, con frecuencia, suelen ser imprecisos y difíciles de describir. Se deben especificar todos los aspectos del problema, pero con frecuencia las personas que describen el problema no son programadores y eso hace imprecisa la definición.
2.2.1.2. Especificación de requisitos
2.2.1.2.1. La fase de especificación requiere normalmente la comunicación entre los programadores y los futuros usuarios del sistema e iterar la especificación, hasta que tanto el especificador como los usuarios estén satisfechos de las especificaciones y hayan resuelto el problema normalmente.
2.2.2. Diseño
2.2.2.1. Para un sistema grande, esta etapa incluye también la fase de diseño de algoritmos, pero incluye el diseño e interacción de un número de algoritmos diferentes, con frecuencia sólo bosquejados, así como una estrategia para cumplir todos los detalles y producir el código correspondiente.
2.2.2.1.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.
2.2.2.2. Implementación (codificación)
2.2.2.2.1. La etapa de implementación (codificación) traduce los algoritmos del diseño en un programa escrito en un lenguaje de programación. 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.
2.2.2.3. Cuando los diferentes componentes de un programa se han implementado y comprobado individualmente, el sistema completo se ensambla y se integra.
2.2.2.3.1. Pruebas e integración
2.3. Iteración y evolución del software
2.3.1. Las etapas de vida del software suelen formar parte de un ciclo o bucle, como su nombre sugiere y no son simplemente una lista lineal
2.3.1.1. las diferentes etapas que rodean al núcleo: documentación son
2.3.1.1.1. Evolucion
2.3.1.1.2. Mantenimiento
2.3.1.1.3. Produccion
2.3.1.1.4. Pruebas
2.3.1.1.5. Codificacion
2.3.1.1.6. Verificacion
2.3.1.1.7. Diseño
2.3.1.1.8. Especificaciones
2.4. FACTORES EN LA CALIDAD DEL SOFTWARE
2.4.1. La construcción de software requiere el cumplimiento de numerosas características. Entre ellas se destacan las siguientes
2.4.1.1. Eficiencia
2.4.1.1.1. La eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula
2.4.1.2. Transportabilidad (portabilidad)
2.4.1.2.1. La transportabilidad o portabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
2.4.1.3. Verificabilidad
2.4.1.3.1. La verificabilidad facilidad de verificación de un software es su capacidad para soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas.
2.4.1.4. Integridad
2.4.1.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
2.4.1.5. Fácil de utilizar
2.4.1.5.1. Un software es fácil de utilizar si se puede comunicar consigo de manera cómoda.
2.4.1.6. Corrección
2.4.1.6.1. Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación
2.4.1.7. Robustez
2.4.1.7.1. Capacidad de los productos software de funcionar incluso en situaciones anormales
2.4.1.8. Extensibilidad
2.4.1.8.1. Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales para conseguir esta característica:
2.4.1.9. Reutilización
2.4.1.9.1. Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones
2.4.1.10. Compatibilidad
2.4.1.10.1. Facilidad de los productos para ser combinados con otros
3. FASES EN LA RESOLUCIÓN DE PROBLEMAS
3.1. Que es
3.1.1. El proceso de resolución de un problema con una computadora conduce a la escritura de un programa y a su ejecución en la misma. Aunque el proceso de diseñar programas es -esencialmente- un proceso creativo, se puede considerar una serie de fases o pasos comunes, que generalmente deben seguir todos los programadores.
3.1.1.1. fases
3.1.1.1.1. Las fases de resolución de un problema con computadora son:
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 términos se utilizan como sinónimos aunque no significan lo mismo. La programación modular y descendente ya se ha examinado anteriormente.
4.1.1. La programación estructurada significa escribir un programa de acuerdo a las siguientes reglas:
4.1.1.1. El programa tiene un diseño modular.
4.1.1.2. Los módulos son diseñados de modo descendente.
4.1.1.3. Cada módulo se codifica utilizando las tres estructuras de control básicas: secuencia, selección y repetición.
4.1.2. La programación estructurada es el conjunto de técnicas que incorporan:
4.1.2.1. recursos abstractos,
4.1.2.1.1. La programación estructurada se auxilia de los recursos abstractos en lugar de los recursos concretos de que dispone un determinado lenguaje de programación. Descomponer un programa en términos de recursos abstractos -según Dijkstra- 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.
4.1.2.2. diseño descendente (top-down),
4.1.2.2.1. El diseño descendente (top-down) es el proceso mediante el cual un problema se descompone en una serie de niveles o pasos sucesivos de refinamiento (stepwise). La metodología descendente 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. Es decir, se descompone el problema en etapas o estructuras jerárquicas, de forma que se puede considerar cada estructura desde dos puntos de vista: ¿qué hace? y ¿cómo lo hace?
4.1.2.3. estructuras básicas.
4.1.2.3.1. Las estructuras de control de un lenguaje de programación son métodos de especificar el orden en que las instrucciones de un algoritmo se ejecutarán. El orden de ejecución de las sentencias (lenguaje) o instrucciones determinan el .flujo de control. Estas estructuras de control son, por consiguiente, fundamentales en los lenguajes de programación y en los diseños de algoritmos especialmente los pseudocódigos.