Instituto Politécnico Nacional

Escuela Superior de Ingeniería

Mecánica y Eléctrica
Unidad Culhuacan

Carrera de Ingeniería en Computación

1CM45
Fundamentos de Programación

Unidad V Aplicaciones

Profesora: Salaz Jimenez Veronica

Alumno: Castellanos Ayala Vanessa Fernanda

Semestre 2023-2

7 de Mayo de 2023
Tema 5.1
Análisis del problema y elaboración del algoritmo

Desde hace unos 25 años, el software cada vez está más presente en los negocios,
empresas, en nuestras vidas cotidianas y debemos ser conscientes de ello. Hasta
el punto de que casi cualquier acción que queramos realizar a lo largo del día implica
interactuar con el software de uno u otro modo. Desde el programa informático de
citas que utiliza nuestro dentista, a los carteles informativos que vemos en el metro,
las máquinas que controlan nuestro cuerpo durante una operación, sacar dinero de
un cajero, el hecho de llamar por teléfono, que se extraiga el tren de aterrizaje de
un avión, o realizar una compra.

Podríamos pasarnos un día entero poniendo ejemplos sobre lo incluida que está la
informática en nuestras vidas. La sociedad cada día requiere de sistemas
informáticos más completos, robustos y eficaces o lo que es lo mismo, sistemas de
software de gran calidad. Sobre todo en aquellos de los que dependen nuestras
propias vidas, ya que lo cierto es que se produzca un error en el programa de citas
por mucho que nos afecte no es vital, pero siempre querremos evitar un fallo en la
máquina que controla nuestra vida mientras estamos bajo los efectos de la
anestesia general en una operación.

Con este ejemplo queda claro que el impacto de un fallo de un sistema a otro es
muy diferente: pérdida de tiempo, problema medioambiental, pérdidas económicas
o incluso de vidas humanas. Y por ello, tendrán diferente coste de control. Pero sin
duda alguna, el factor común a todas ellas es que se debe cuidar mucho la calidad
de los servicios disponibles para nuestro bienestar. Es en este punto donde entra la
ingeniería de software y más en concreto la fase de calidad de software. Una fase
que día a día cobra más fuerza porque la experiencia está demostrando que fallos
en el software van a existir, así que cuanto antes se localicen, menores serán las
consecuencias que puedan ocasionar. Un fallo puede ser ocasionado por diversos
motivos :
- El principal es el fallo humano. Ya sea un fallo en documentación, en codificación,
o provocado por las condiciones en las que se generó el software, como presión
temporal, complejidad de infraestructura o código o cambio tecnológico.
- En otras ocasiones son las condiciones ambientales las que pueden ocasionar
fallos al modificar el hardware y afectar a la ejecución del software. Magnetismo,
radiación, contaminación, etc
Partimos del hecho de que un programador no puede resolver un problema que
no entiende. Por esta razón, la primera etapa en todo proceso de construcción de
software consiste en tratar de entender el problema que tiene el cliente, y expresar
toda la información que él suministre, de manera tal que cualquier otra persona
del equipo de desarrollo pueda entender sin dificultad lo que espera el cliente de
la solución. Esta etapa se denomina análisis y la salida de esta etapa la llamamos
la especificación del problema.

Para introducir los elementos de la especificación, vamos a hacer el paralelo con

otras ingenierías, que comparten problemáticas similares. Considere el caso de
un ingeniero civil que se enfrenta al problema de construir una carretera. Lo
primero que éste debe hacer es tratar de entender y especificar el problema que
le plantean. Para eso debe tratar de identificar al menos tres aspectos del
problema: Los requerimientos del usuario (entre qué puntos quiere el cliente la
carretera, cuántos carriles debe tener, para qué tipo de tráfico debe ser la
carretera), El mundo en el que debe resolverse el problema (el tipo de terreno, la
cantidad de lluvia, la temperatura), y Las restricciones y condiciones que plantea
el cliente (el presupuesto máximo, que las pendientes no sobrepasen el 5%).

Sería una pérdida de tiempo y de recursos para el ingeniero civil, intentar construir
la carretera si no ha entendido y definido claramente los tres puntos antes
mencionados. Y más que tiempo y recursos, habrá perdido algo muy importante
en una profesión de servicio como es la ingeniería, que es la confianza del cliente.
En general, todos los problemas se pueden dividir en estos tres aspectos. Por
una parte, se debe identificar lo que el cliente espera de la solución. Esto se
denomina un requerimiento funcional. En el caso de la programación, un
requerimiento funcional hace referencia a un servicio que el programa debe
proveer al usuario.

El segundo aspecto que conforma un problema es el mundo o contexto en el que

ocurre el problema. Si alguien va a escribir un programa para una empresa, no le
basta con entender la funcionalidad que éste debe tener, sino que debe entender
algunas cosas de la estructura y funcionamiento de la empresa. Por ejemplo, si
hay un requerimiento funcional de calcular el salario de un empleado, la
descripción del problema debe incluir las normas de la empresa para calcular un
salario. El tercer aspecto que hay que considerar al definir un problema son los
requerimientos no funcionales, que corresponden a las restricciones o
condiciones que impone el cliente al programa que se le va a construir. Fíjese que
estos últimos se utilizan para limitar las soluciones posibles. En el caso del
programa de una empresa, una restricción podría ser el tiempo de entrega del
programa, o la cantidad de usuarios simultáneos que lo deben poder utilizar.

A continuación se resume el ciclo de vida de construcción de un programa y nos

va a permitir introducir la terminología básica que necesitamos:

Paso 1: Una persona u organización, denominada el cliente, tiene un problema y

necesita la construcción de un programa para resolverlo. Para esto contacta una
empresa de desarrollo de software que pone a su disposición un programador.
Paso 2: El programador sigue un conjunto de etapas, denominadas el proceso,
para entender el problema del cliente y construir de manera organizada una
solución de buena calidad, de la cual formará parte un programa.
Paso 3: El programador instala el programa que resuelve el problema en un
computador y deja que el usuario lo utilice para resolver el problema. Fíjese que
no es necesario que el cliente y el usuario sean la misma persona. Piense por
ejemplo que el cliente puede ser el gerente de producción de una fábrica y, el
usuario, un operario de la misma.

Entender y especificar el problema que se quiere resolver es sólo la primera etapa

dentro del proceso de desarrollo de un programa. Es importante que el lector
entienda que si el problema no es pequeño (por ejemplo, el sistema de
información de una empresa), o si los requerimientos no funcionales son críticos
(por ejemplo, el sistema va a ser utilizado simultáneamente por cincuenta mil
usuarios), o si el desarrollo se hace en equipo (por ejemplo, veinte ingenieros
trabajando al mismo tiempo).

La primera etapa para resolver un problema es analizarlo. Para facilitar este

estudio, se debe descomponer el problema en sus tres partes. Una vez que el
problema se ha entendido y se ha expresado en un lenguaje que se pueda
entender sin ambigüedad, pasamos a la etapa de diseño. Aquí debemos
imaginarnos la solución y definir las partes que la van a componer. Es muy común
comenzar esta etapa definiendo una estrategia.

Cuando el diseño está terminado, pasamos a construir la solución.

El proceso debe ser entendido como un orden en el cual se debe desarrollar una
serie de actividades que van a permitir construir un programa. El proceso
planteado tiene tres etapas principales, todas ellas apoyadas por herramientas y
lenguajes especiales:

Análisis del problema: el objetivo de esta etapa es entender y especificar el

problema que se quiere resolver. Al terminar, deben estar especificados los
requerimientos funcionales, debe estar establecida la información del mundo del
problema y deben estar definidos los requerimientos no funcionales.

Diseño de la solución: el objetivo es detallar, usando algún lenguaje (planos,

dibujos, ecuaciones, diagramas, texto, etc.), las características que tendrá la
solución antes de ser construida. Los diseños nos van a permitir mostrar la
solución antes de comenzar el proceso de fabricación propiamente dicho. Es
importante destacar que dicha especificación es parte integral de la solución.

Construcción de la solución: tiene como objetivo implementar el programa a partir

del diseño y probar su correcto funcionamiento.

Cada una de las etapas de desarrollo está apoyada por herramientas y lenguajes,
que van a permitir al programador expresar el producto de su trabajo. En la etapa
de construcción de la solución es conveniente contar con un ambiente de
desarrollo que ayuda, entre otras cosas, a editar los programas y a encontrar los
errores de sintaxis que puedan existir.

La solución a un problema tiene varios componentes; El primero es el diseño (los

planos de la solución) que debe definir la estructura del programa y facilitar su
posterior mantenimiento. El segundo elemento es el código fuente del programa,
escrito en algún lenguaje de programación como Java, C, C# o C++.

El tercer elemento de la solución son los archivos de construcción del programa.

En ellos se explica la manera de utilizar el código fuente para crear el código
ejecutable. Este último es el que se instala y ejecuta en el computador del usuario.
El programa que permite traducir el código fuente en código ejecutable se
denomina compilador.

El último elemento que forma parte de la solución son las pruebas. Allí se tiene
un programa que es capaz de probar que el programa que fue entregado al cliente
funciona correctamente. Dicho programa funciona sobre un conjunto predefinido
de datos, y es capaz de validar que para esos datos predefinidos (y que simulan
datos reales), el programa funciona bien.

Mediante las herramientas de diseño de algoritmos se pueden desarrollar los

mismos, las alternativas de diseño de algoritmos son principalmente dos:

Diagrama de flujo: Representan de forma visual el flujo de los datos a través del
tratamiento de información. Los diagramas de flujo describen que operaciones y en
que secuencia se requieren para solucionar un problema dado. Los diagramas de
flujo se dibujan generalmente usando algunos símbolos estándares.

-Los Diagramas de flujo deben escribirse de arriba hacia abajo, y/o de izquierda a
derecha. -
Los símbolos se unen con líneas, las cuales tienen en la punta una flecha que indica
la dirección que fluye la información procesos, se deben de utilizar solamente líneas
de flujo horizontal o verticales (nunca diagonales). -Se debe evitar
el cruce de líneas, para lo cual se quisiera separar el flujo del diagrama a un sitio
distinto, se pudiera realizar utilizando los conectores. Se debe tener en cuenta que
solo se van a utilizar conectores cuando sea estrictamente necesario.
-No deben quedar líneas de flujo sin conectar.
-Todo texto escrito dentro de un símbolo debe ser legible, preciso, evitando el uso
de muchas palabras. –-
Todos los símbolos pueden tener más de una línea de entrada, a excepción del
símbolo final.
-Solo los símbolos de decisión pueden y deben tener más de una línea de flujo de
salida (unam.mx, s.f.).
Pseudocódigo: Es una técnica que sirve para escribir programas de computadora
en lenguaje natural de tal manera que se facilite la comprensión, prueba y posterior
codificación en un lenguaje de programación específico
Es muy fácil pasar de pseudocódigo a un programa en algún lenguaje de
programación, si se siguen las reglas se puede observar claramente los niveles que
tiene cada operación.
Prueba de escritorio: Todo algoritmo debe ser probado antes de ser ejecutado para
tener la certeza de que lograremos el objetivo. La forma de probarlo es siguiente
cada uno de los pasos que indica el algoritmo. A esto le llamaremos prueba de
escritorio. En la prueba de escritorio, un algoritmo bien hecho siempre debe
funcionar
Al poner en marcha los pasos del algoritmo para determinar si logrará o no el
objetivo, tal vez se tengan que hacer algunas modificaciones hasta logar el objetivo
esperado. El algoritmo debe ser lo suficientemente detallado para que no exista
duda alguna al ejecutarse.
Tema 5.2
Codificación e implementación

Durante esta etapa se realizan las tareas que comúnmente se conocen como
programación; que consiste, esencialmente, en llevar a código fuente, en el lenguaje
de programación elegido, todo lo diseñado en la fase anterior. Esta tarea la realiza
el programador, siguiendo por completo los lineamientos impuestos en el diseño y
en consideración siempre a los requisitos funcionales y no funcionales (ERS)
especificados en la primera etapa.
Se suele hacer estimaciones de un 30% del tiempo total insumido en la
programación, pero esta cifra no es consistente ya que depende en gran medida de
las características del sistema, su criticidad y el lenguaje de programación elegido.7
En tanto menor es el nivel del lenguaje mayor será el tiempo de programación
requerido, así por ejemplo se tardaría más tiempo en codificar un algoritmo en
lenguaje ensamblador que el mismo programado en lenguaje C.
Mientras se programa la aplicación, sistema, o software en general, se realizan
también tareas de depuración, esto es la labor de ir liberando al código de los errores
factibles de ser hallados en esta fase (de semántica, sintáctica y lógica). Hay una
suerte de solapamiento con la fase siguiente, ya que para depurar la lógica es
necesario realizar pruebas unitarias, normalmente con datos de prueba; claro es
que no todos los errores serán encontrados sólo en la etapa de programación, habrá
otros que se encontrarán durante las etapas subsiguientes. La aparición de algún
error funcional eventualmente puede llevar a retornar a la fase de diseño antes de
continuar la codificación.

Durante la fase de programación, el código puede adoptar varios estados,

dependiendo de la forma de trabajo y del lenguaje elegido, a saber:
Código fuente: es el escrito directamente por los programadores en editores de
texto, lo cual genera el programa. Contiene el conjunto de instrucciones codificadas
en algún lenguaje de alto nivel. Puede estar distribuido en paquetes,
procedimientos, bibliotecas fuente, etc.
Código objeto: es el código binario o intermedio resultante de procesar con un
compilador el código fuente. Consiste en una traducción completa y de una sola vez
de este último. El código objeto no es inteligible por el ser humano pero tampoco es
directamente ejecutable por la computadora. Se trata de una representación
intermedia entre el código fuente y el código ejecutable, a los fines de un enlace
final con las rutinas de biblioteca y entre procedimientos o bien para su uso con un
pequeño intérprete intermedio.

El código objeto no existe si el programador trabaja con un lenguaje a modo de

intérprete puro, en este caso el mismo intérprete se encarga de traducir y ejecutar
línea por línea el código fuente (de acuerdo al flujo del programa), en tiempo de
ejecución. En este caso tampoco existe el o los archivos de código ejecutable. Una
desventaja de esta modalidad es que la ejecución del programa o sistema es un
poco más lenta que si se hiciera con un intérprete intermedio, y bastante más lenta
que si existe el o los archivos de código ejecutable. Es decir no favorece el
rendimiento en velocidad de ejecución. Pero una gran ventaja de la modalidad
intérprete puro, es que él está forma de trabajo facilita enormemente la tarea de
depuración del código fuente (frente a la alternativa de hacerlo, es decir inicialmente
trabajar a modo de intérprete puro, y una vez depurado el código fuentes utiliza un
compilador del mismo lenguaje para obtener el código ejecutable completo, con lo
cual se agiliza la depuración y la velocidad de ejecución se optimiza.

Código ejecutable: Es el código binario resultado de enlazar uno o más fragmentos

de código objeto con las rutinas y bibliotecas necesarias. Constituye uno o más
archivos binarios con un formato tal que el sistema operativo es capaz de cargarlo
en la memoria RAM y proceder a su ejecución directa. Por lo anterior se dice que
el código ejecutable es directamente “inteligible por la computadora”.
El código ejecutable, también conocido como código máquina, no existe si se
programa con modalidad de “intérprete puro”.
Tema 5.3
Pruebas modulares e integrales

Las pruebas integrales se tienen que aplicar justo después de haber llevado a cabo
cada prueba unitaria con la intención de probar los métodos aplicados en el
desarrollo. Si no existen ningún problema de código y las pruebas unitarias han
terminado de forma exitosa se podrá pasar al test integral para asegurarse de que
en este punto no se produce ningún tipo de problema en la combinación de
elementos unitarios. El motivo principal se encuentra en que el test integral lleva a
cabo la revisión conjunta de los diferentes elementos que están presentes con el
objetivo de formar el software. Se realiza la comprobación para ver que todo
funciona de una manera adecuada en conjunto, dado que no es extraño que se
produzcan alteraciones en el rendimiento.

Con esta comprobación representada por la prueba de integración podremos ver

si la comunicación entre los distintos componentes presentes en el software es
funcional. Se comprueban también las comunicaciones de forma invariable tanto si
están representadas con software o con hardware. En el caso de ser necesario ir
más allá por la existencia de subsistemas los profesionales que estén al cargo de
este software también tendrán que hacer la prueba específica de subsistemas, que
viene a ser una variación de la de integración pero profundizando en los elementos
que están incluidos dentro de cada sistema.

Durante este proceso en el cual se verifican los distintos tipos de integración, los
especialistas tendrán que ensamblar los módulos independientes, dar forma al
software al completo y verificar el proceso a conciencia. Una de las ventajas de este
protocolo se encuentra en la oportunidad de llevar a cabo pruebas de una manera
paralela, lo que aporta flexibilidad extra en el proceso de calendarización. Para ello
se optará por la elección de frameworks en los que las pruebas se puedan
combinar con el desarrollo y con la supervisión simplificada de los procesos,
especialmente en aquellos casos en los que las pruebas puedan ser un poco más
complejas. El resultado garantizará que el proyecto de software pueda avanzar
hacia su siguiente fase antes de darse por finalizado.

Mencionada la prueba unitaria y las pruebas de integración, el proceso de testing

pasa por otras fases que resultan relevantes y se deben tener en cuenta para
mejores resultados. La prueba funcional es otro de los procesos que se tendrán que
gestionar para alcanzar la mayor estabilidad y confianza en que el rendimiento sea
el adecuado. Lo que hacemos en este caso, una vez vemos que las conexiones
están en forma a través del test integral, es ver que el software que hemos diseñado
y gestionado está actuando de manera conveniente teniendo en cuenta el objetivo
para el cual fue creado.

Cada fase del testing tiene unas exigencias y unos puntos clave en los que nos
debemos fijar. Eso es algo que siempre tenemos que tener en cuenta para que el
testing resulte satisfactorio y no terminemos sufriendo demasiadas complicaciones.
Por lo tanto, en la fase de la prueba funcional en lo único que nos tendremos que
fijar es en que se produzca el tipo de soporte que tenemos en mente cuando
hablamos del software en cuestión. Analizaremos las salidas y las entradas que se
produzcan al software, así como los resultados. No importa en este caso si en el
diseño del software se ha encontrado algún tipo de defecto o posible mejora, dado
que la cuestión en esta prueba consiste en comprobar el funcionamiento. Por lo
tanto, hemos pasado a un proceso que después de comprobar que todo está en su
sitio nos indica si realmente tiene un buen rendimiento, algo clave para poder
colocarse en el perfil del cliente y comprobar que vaya a obtener el nivel de
satisfacción requerido.

Si en un futuro se descubren fallos, para asegurar que las pruebas realizadas en su

momento fueron correctas y suficientes, habrá que demostrar que dicho fallo no se
reprodujo durante la realización de las pruebas o que la prueba que produce el fallo
no estaba contenida en el plan de pruebas inicial. Lo que apuntará a que el fallo del
software sea debido a otras causas, como pueden ser una actualización del
software o un fallo en el entorno.

En un proceso de pruebas deben ser probadas todas las funcionalidades de un

software de manera sistemática. Si un software es nuevo se comprueba el correcto
funcionamiento del software por completo. Cuando se trata de una actualización o
un módulo nuevo, el foco sobre el que se debe centrar el mayor esfuerzo a realizar
en pruebas es el software de nueva creación.

Pero no menos importante es asegurar que el software que ya existía sigue

funcionando de la misma forma. Esto se soluciona diseñando un plan de pruebas
de regresión que es una batería de pruebas con las que se certifica si el software
ya existente sigue funcionando de la misma forma que antes de instalar el software
nuevo. Además, dicho plan de pruebas de regresión debe ejecutarse con cada
nueva incorporación de software al software inicial.

Para finalizar el tema del esfuerzo necesario a emplear en pruebas, diremos que
teniendo en cuenta los problemas generales que hemos identificado (ámbito,
alcance y costes) utilizaremos los conocimientos teóricos sobre el diseño de casos
de prueba para poder definir un conjunto finito y viable y que por supuesto, aporte
fiabilidad y calidad, ya sea a un software nuevo o a uno ya existente.

Finalización de las pruebas por motivos de coste o tiempos, es un motivo de

finalización aplastante pero conlleva un riesgo importante a tener en cuenta, ya que
tiende a originar costes adicionales por la aparición posterior de errores, asimismo,
no es un criterio que pueda asegurar la fiabilidad del sistema. Puede venir dado por
ejemplo, a causa de una planificación escasa de recursos. En definitiva, este criterio
de finalización denota una mala planificación de las pruebas.
Tema 5.4

Mantenimiento

El mantenimiento de software es el proceso de cambiar, modificar y actualizar el

software para satisfacer las necesidades del cliente. El mantenimiento del software
se realiza después del lanzamiento del producto por varias razones, que incluyen la
mejora del software en general, la corrección de problemas o errores, mejorar el
rendimiento y más.
El mantenimiento de software es una parte natural del SDLC (ciclo de vida del
desarrollo de software). Los desarrolladores de software no pueden darse el lujo de
lanzar un producto y dejar que se ejecute, deben estar constantemente atentos a
corregir y mejorar su software para seguir siendo competitivos y relevantes.

El uso de las técnicas y estrategias correctas de mantenimiento de software es una

parte fundamental para mantener cualquier software en ejecución durante un largo
período de tiempo y mantener contentos a los clientes y usuarios.

Tipos de mantenimiento:

Mantenimiento preventivo de software: El mantenimiento preventivo de software

está mirando hacia el futuro para que su software pueda seguir funcionando como
se desee durante el mayor tiempo posible.

Esto incluye realizar los cambios necesarios, actualizaciones, adaptaciones y más.

El mantenimiento preventivo del software puede abordar pequeños problemas que
en un momento dado pueden carecer de importancia, pero pueden convertirse en
problemas mayores en el futuro. Estos se denominan fallas latentes que deben
detectarse y corregirse para asegurarse de que no se conviertan en fallas efectivas.

Mantenimiento perfectivo de software: Al igual que con cualquier producto en el

mercado, una vez que el software se lanza al público, surgen nuevos problemas e
ideas. Los usuarios pueden ver la necesidad de nuevas características o requisitos
que les gustaría ver en el software para convertirlo en la mejor herramienta
disponible para sus necesidades. Es entonces cuando entra en juego el
mantenimiento perfectivo del software.

El mantenimiento perfectivo de software tiene como objetivo ajustar el software

agregando nuevas características según sea necesario y eliminando características
que son irrelevantes o no efectivas en el software dado. Este proceso mantiene el
software relevante a medida que el mercado y las necesidades del usuario cambian.

Mantenimiento adaptativo de software: El Mantenimiento adaptativo de software

tiene que ver con las tecnologías cambiantes, así como con las políticas y reglas
relacionadas con su software. Las cuales incluyen cambios en el sistema operativo,
almacenamiento en la nube, hardware, etc. Cuando se realizan estos cambios, su
software debe adaptarse para cumplir adecuadamente los nuevos requisitos y
continuar funcionando bien.
 Bibliografía

Docs, T. p. (2021). Escuela de Ingenierias Industriales. (Sphinx, Productor)

Recuperado el febrero de 2023, de
https://www2.eii.uva.es/fund_inf/cpp/temas/6_control_flujo_iterativo/for.html
Docs, T. p. (5 de febrero de 2021). Escuela de Ingenierias Industriales. Obtenido
de
https://www2.eii.uva.es/fund_inf/cpp/temas/6_control_flujo_iterativo/for.html
Goin, M. (2016). Caminando Junto al lenguaje C. Belgrano 526, Viedma, Río
Negro, Argentina: UNRN.
GOMEZ, J. B. (Primera edición: 2012). Analisis y Diseño del Algoritmos. Viveros
de Asís 96, Col. Viveros de la Loma, Tlalnepantla, C.P. 54080, Estado de
México.: Red Tercer Milenio.
Palmer, R. (. (13 de Septiembre del 2019). Manual de Planificación y
Programación de Mantenimiento. McGraw-Hill Education.
Panama, I. (s.f.). Sistema de codificacion autorizada. CEPAL.
rodriguez, F. (2022 ultima modificacion ). Que es un interprete y que es un
compilador?
Rodríguez, N. G. (Marzo 2015). Las Pruebas de Integración como Proceso de la
Calidad del Software en el Ámbito de las Telecomunicaciones. ESCUELA
POLITÉCNICA SUPERIOR CARLOS III.
Tinajero, E. R. (s.f.). Programacion e implementacion de sistemas . México:
Universidad Nacional Autonoma de M`.