1. Algoritmo
1.1. Metodo para resolver un problema mediante una seria de pasos
1.1.1. Precisos
1.1.2. Definidos
1.1.3. Finitos
2. Fases en la resolucion de problemas
2.1. Analisis del problema
2.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.
2.1.1.1. Diseño de algoritmo
2.2. Diseño de algoritmo
2.2.1. En la etapa de diseño se determina como hace el programa la tarea solicitada.
2.2.1.1. Divide y venceras
2.2.1.1.1. Diseño descendente o modular
2.2.1.1.2. La resolución de un problema complejo se realiza dividiendo el problema en subproblemas y a continuación dividir estos subproblemas en otros de nivel más bajo, hasta que pueda ser implementada una solución en la computadora.
2.2.2. Diseño modular
2.2.2.1. Cualquier programa bien diseñado consta de un programa principal (el módulo de nivel alto) que llama a subprogramas (módulos de nivel bajo) que a su vez pueden llamar a otros subprogramas.
2.2.2.1.1. Programar el modulo
2.2.2.1.2. Comprobar el modulo
2.2.2.1.3. Depurar el modulo (si es necesario)
2.2.2.1.4. Combinar el modulo con los modulos anteriores
2.3. Herramientas de programacion
2.3.1. Diagramas de flujo
2.3.1.1. Es una representación gráfica de un algoritmo.
2.3.2. Pseudocodigo
2.3.2.1. Es una herramienta de programación en la que las instrucciones se escriben en palabras similares al inglés o español, que facilitan tanto la escritura como la lectura de programas.
2.3.2.2. Lenguaje de especijicaciones de algoritmos.
2.4. Codificación de un programa
2.4.1. Es la escritura en un lenguaje de programación de la representación del algoritmo desarrollada en las etapas precedentes. Dado que el diseño de un algoritmo es independiente del lenguaje de programación utilizado para su implementación, el código puede ser escrito con igual facilidad en un lenguaje o en otro.
2.4.1.1. Algoritmo en lenguaje de programacion
2.4.2. Para realizar la conversión del algoritmo en programa se deben sustituir las palabras reservadas en español por sus homónimos en inglés, y las operaciones/instrucciones indicadas en lenguaje natural expresarlas en el lenguaje de programación correspondiente.
2.4.2.1. Algoritmo en lenguaje de programacion
2.5. Compilación y ejecución,
2.5.1. El programa fuente se convierte a lenguje maquina, eso se hace con compilador y el sistema operativo que se encarga de la compilación.
2.5.2. Si no se producen errores, obteniéndose el programa objeto que todavía no es ejecutable directamente.
2.5.3. Se debe instruir al sistema operativo para que realice la fase de montaje o enlace (link), carga, del programa objeto con las librerías del programa del compilador. El proceso de montaje produce un programa ejecutable.
2.6. Verificasion y depuracion
2.6.1. Errores de compilación. Se producen normalmente por un uso incorrecto de las reglas del lenguaje de programación y suelen ser errores de sintusis. Si existe un error de sintaxis, la computadora no puede comprender la instrucción, no se obtendrá el programa objeto y el compilador imprimirá una lista de todos los errores encontrados durante la compilación.
2.6.2. Errores de ejecución. Estos errores se producen por instrucciones que la computadora puede comprender pero no ejecutar. Ejemplos típicos son: división por cero y raíces cuadradas de números negativos. En estos casos se detiene la ejecución del programa y se imprime un mensaje de error.
2.6.3. Errores lógicos. Se producen en la lógica del programa y la fuente del error suele ser el diseño del algoritmo. Estos errores son los más difíciles de detectar, ya que el programa puede funcionar y no producir errores de compilación ni de ejecución, y sólo puede advertir el error por la obtención de resultados incorrectos. En este caso se debe volver a la fase de diseño del algoritmo, modificar el algoritmo, cambiar el programa fuente y compilar y ejecutar una vez más.
2.7. Mantenimiento y documentacion.
2.7.1. La documentación de un problema consta de las descripciones de los pasos a dar en el proceso de resolución de un problema. Programas pobremente documentados son difíciles de leer, más difíciles de depurar y casi imposibles de mantener y modificar.
2.7.2. La documentación es vital cuando se desea corregir posibles errores futuros o bien cambiar el programa. Tales cambios se denominan mantenimiento del programa. Después de cada cambio la documentación debe ser actualizada para facilitar cambios posteriores.
3. Programacion modular
3.1. 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.
3.2. Cada programa contiene un módulo denominado programa principal que controla todo lo que sucede; se transfiere el control a submódulos (programa de menor nivel), 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.
3.3. El proceso sucesivo de subdivisión de módulos continúa hasta que cada módulo tenga solamente una tarea específica que ejecutar. Esta tarea puede ser entrada, salida, manipulación de datos, control de otros módulos o alguna combinación de éstos. Un módulo puede transferir temporalmente (hifurcar) el control a otro módulo; sin embargo, cada módulo debe eventualmente devolver el control al módulo del cual se recibe originalmente el control.
4. Programacion estructurada
4.1. Reglas
4.1.1. El programa tiene un diseño modular.
4.1.2. Los módulos son diseñados de modo descendente.
4.1.3. Cada módulo se codifica utilizando las tres estructuras de control básicas: secuencia, selección y repeticion
4.2. Lenguajes
4.2.1. BASIC
4.2.2. Pascal
4.2.3. FORTRAN
4.2.4. C
4.2.5. GOTO
4.3. Tecnicas incorporadas
4.3.1. Recursos abstractos,
4.3.1.1. consiste en des- componer una determinada acción compleja en términos de un número de acciones más simples capa- ces de ejecutarlas o que constituyan instrucciones de computadoras disponibles.
4.3.2. Diseño descendente (top-down),
4.3.2.1. proceso mediante el cual un problema se descompone en una serie de niveles o pasos sucesivos de refinamiento
4.3.2.2. 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.3.3. Estructuras básicas.
4.3.3.1. Tipos
4.3.3.1.1. Secuenciales,
4.3.3.1.2. Selectivas,
4.3.3.1.3. Repetitivas.
4.3.3.2. Programa propio
4.3.3.2.1. Posee un solo punto de entrada y uno de salida ofin para control del programa.
4.3.3.2.2. Existen caminos desde la entrada hasta la salida que .se pueden seguir y que pasan por todas las partes del progrema
4.3.3.2.3. Todas las instrucciones son ejecutahles y no existen /ai.os CJ bucles infinitos (sin fin).
5. Representación gráfica de los algoritmos
5.1. Diagrama de flujo,
5.1.1. 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.
5.1.2. Diagrama que utiliza los símbolos estándar (cajas) y que tiene los pasos de algoritmo escritos en esas cajas unidas por flechas, denominadas líneas deflujo, que indican la secuencia en que se debe ejecutar.
5.1.2.1. Los símbolos estándar normalizados por ANSI (abreviatura de American National Standars Institute) son muy variados.
5.2. Diagrama N-S (Nassi-Schneiderman),
5.2.1. Es como un diagrama de flujo en el que se omiten las flechas de unión y las cajas son contiguas.
5.2.2. Las acciones sucesivas se escriben en cajas sucesivas y, como en los diagramas de flujo, se pueden escribir diferentes acciones en una caja.
5.3. Lenguaje de especificación de algoritmos: pseudoccídigo,
5.4. Fáciles de transformar en programas
5.4.1. Lenguaje esparlol, inglés
5.4.2. Formulas
6. Ciclo de vida de un software
6.1. Analisis
6.1.1. Análisis y definición del problema.
6.1.1.1. Comienza analizando los requisitos del usuario,
6.1.1.2. Pero con frecuencia las personas que describen el problema no son programadores y eso hace imprecisa la definición.
6.1.2. Especificación de requisitos.
6.1.2.1. En la etapa de especificaciones puede ser muy Útil para mejorar la comunicación entre las diferentes partes implicadas construir un prototipo o modelo sencillo del sistema final; es decir, escribir un programa prototipo que simule el comportamiento de las partes del producto software deseado.
6.2. Diseño
6.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. A continuación, se debe indicar la interacción entre módulos; un diagrama de estructuras proporciona un esquema claro de estas relaciones.
6.2.2. La etapa de implementució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 56 Programación en C. Metodología, algoritmos y estructura de datos han de traducirse codificados en un lenguaje que entiende la computadora:
6.2.2.1. PASCAL
6.2.2.2. FORTRAN,
6.2.2.3. COBOL
6.2.2.4. C
6.2.2.5. C++
6.2.2.6. C#
6.2.2.7. Java
6.3. Implementacion
6.4. Pruebas e integracion
6.4.1. Cuando los diferentes componentes de un programa se han implementado y comprobado individualmente, el sistema completo se ensambla y se integra. La etapa de pruebas sirve para mostrar que un programa es correcto.
6.5. Verificasion
6.6. Mantenimiento
6.6.1. Un sistema de software producirá errores que serán detectados, casi con seguridad, por los usuarios del sistema y que no se descubrieron durante la fase de prueba. La corrección de estos errores es parte del mantenimiento del software.
7. Calidad de software
7.1. Eficiencia
7.1.1. La eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula.
7.2. Portabilidad
7.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.
7.3. Vereficabilidad
7.3.1. 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.
7.4. Integridad
7.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.
7.5. Fácil de utilizar
7.5.1. Un software es fácil de utilizar si se puede comunicar consigo de manera cómoda.
7.6. Correccion
7.6.1. Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.
7.7. Robustez
7.7.1. Capacidad de los productos software de funcionar incluso en situaciones anormales.
7.8. Extensibilidad
7.8.1. Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales para conseguir esta característica.
7.8.1.1. Diseño simple
7.8.1.2. Descentralización
7.9. Reutilizacion
7.9.1. Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
7.10. Compatibilidad
7.10.1. Facilidad de los productos para ser combinados con otros.