UNIVERSIDAD NACIONAL DEL ALTIPLANO PUNO

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

CODIFICACION,
PRUEBAS Y
MANTENIMIENTO

DOCENTE : Aldo Hernan Zanabria Galvez

MATERIA : Ingenieria de Software
ESTUDIANTE : Roni Wagner Itusaca Maldonado
SEMESTRE : Quinto
FECHA : 18/12/2020

Puno – Perú
A. Fase 3: Codificación

El objetivo de la codificación es traducir las especificaciones del diseño en un

lenguaje de programación, para ello se tuvo que realizar de manera adecuada
las fases 1 y 2 de análisis e diseño.
A la hora de codificar hay q seguir una guía de estilo, en especial si estamos
trabajando en equipo. El código debe estar bien implementado y debe de ser
fácil de entender, como salida de esta fase tenemos los programas en si, el
manual técnico y el de usuario. El manual técnico es un documento interno en
donde se describe las funciones del cogido a detalle de lo que hacen y el
manual de usuario describe como manejar el sistema este se entrega con el
software ejecutable. Durante este proceso es habitual realizar cambios en el
diseño, en tales casos también será necesario actualizar el documento
correspondiente.
Para llevar a cabo correctamente las pruebas de software son necesarias que
tenga estos productos e información relativa:
• Código.
• Manual de Usuario.
• Manual Técnico.
• Documento de diseño.
• Especificaciones de requisitos de software.
• Entorno donde funciona el sistema.

B. Fase 4: Pruebas

¿Por qué y para que hacer pruebas?

Se realizan pruebas para demostrar si existe algún error en el software, y para
demostrar que el sistema funciona correctamente, sin embargo, siempre existen
errores, pero estos no son detectados por los desarrolladores si no por lo
usuarios, es mejor para los desarrolladores encontrar gran cantidad de errores
antes de entregar el software. Es casi imposible realizar pruebas exhaustivas de
un código ya que tomaría una gran cantidad de tiempo, para ello se propone
diseñar casos de prueba y seguir una estrategia de prueba que nos permita
identificar el mayor numero de errores con el menor número de casos posibles.
Un buen caso de prueba es aquel que tiene una alta probabilidad de detectar un
error no descubierto todavía.

Se tiene que tener en cuenta dos definiciones:

• Verificación: Comprueba el funcionamiento correcto del software desde

un punto de vista técnico.
• Validación: Responde a la pregunta ¿Se ha construido el sistema
correcto? Así se comprueba si los resultados de usuario se cumplen.
Un caso de prueba este compuesto por dos partes: Las entradas que vamos a
probar y el resultado esperado. Es importante revisar el resultado de cada
prueba, además los casos de prueba deben estar escritos tanto para condiciones
de entradas validas e invalidas.
Uno mismo no tiende a encontrar errores en su propio código , por lo que otro
miembros del equipo de desarrollo debe probar nuestro código para poder
informarnos de los errores encontrados. Finalmente es necesario documentar
los casos de prueba, solo sol el diseño de los casos que vamos a probar si no
también los resultados obtenidos, y en caso de ser negativo el procedimiento
que se siguió hasta resultar ser correcto.
Es necesario realizar pruebas de código a lo largo de todo el ciclo de vida del
proyecto. Después del análisis de requisitos tendremos que comprobar por
ejemplo de que todos los requisitos estén bien identificados, que no hay
requisitos contradictorios ni redundantes, ni inconscientes. Después de diseño
tendremos que asegurar que todos los requisitos descritos cumplen con las
métricas de acoplamiento y cohesión. Después de codificación podemos hacer
inspecciones de código que consisten únicamente en revisarlos de manera
visual, es decir leyéndolo.
Tenemos dos técnicas de pruebas de código:

• Pruebas de caja blanca: Comprueban a lógica interna del programa, se

centran en la estructura y comportamiento interno del código.
Técnicas:
o Recorrer todos lo caminos independientes y comprobar todas las
decisiones lógicas y todos lo bucles.
• Pruebas de caja negra: Nos fijaremos únicamente en los datos de entrada
y salida. Introduciremos los datos de entrada que hayamos seleccionado
y comprobaremos que generan las salidas especificadas en los
requisitos.
Técnicas:
o Partición en clases de equivalencia.
o Análisis de valores limite.
Con estas dos técnicas lo que conseguimos es diseñar un conjunto de casos de
prueba que tengan la más alta probabilidad de detectar el mayor numero de
errores posibles. Se usa más caja negra debió a la facilidad; para módulos u
objetos complejos se crea casos adicionales que examinen la lógica del
programa con técnicas de caja blanca.

La estrategia de prueba en un sistema informático será desde adentro hacia

afuera, es decir empezando con los módulos mas pequeños y finalizando con el
sistema completo, dado esto las primeras pruebas serán unitarias donde se
prueba cada función o modulo por separado.
Seguidamente se realizarán las pruebas de integración, donde se agruparán los
módulos ya probados para comprobar las interfaces entre ellos. Lo que se hace
es integrar los distintos módulos uno a uno al grupo de módulos ya probados. No
debemos integrar varios módulos a la vez ya que si da un error no sabremos de
donde procede.
Luego se realizarán las pruebas de validación donde se comprueba si las salidas
están en concordancia con los requisitos de usuarios especificados. Y, por otra,
las pruebas del sistema en las que integraremos nuestro sistema informático en
el entorno hardware y software donde funcionará.
 Finalmente, el cliente realiza las pruebas de aceptación y comprueba que el
producto final se ajusta a los requisitos de usuario, es decir, a lo que ellos
pidieron. Si estas pruebas son satisfactorias, el cliente dará el proyecto por
aceptado.

C. Fase 3: Mantenimiento.
Una vez culminado nuestro software que ya esta siendo utilizado por los
usuarios, comienza un nuevo proceso, el de mantenimiento, este comprende
algunas actividades para mantener en un funcionamiento correcto del software
como: corrección de errores, mejoras de rendimiento o atributos, añadir
funcionalidades, adaptarlos a un cambio de entorno, etc.
El mantenimiento tiene una serie de problemas que las fases anteriores no, estas
dificultan su realización y aumentan su coste, por ejemplo:
• Dificultad en seguir la evolución del software a través de las versiones o
de los cambios.
• La complicación en comprender un programa ajeno.
• La mala documentación.
El mantenimiento en duración es mucho mas largo que el desarrollo, pero los
recursos que utilizan son menores y más difíciles de estimar.

Cuanto mas nos preocupemos por la mantenibilidad (la facilidad de corregir,

adaptar o mejorar el software) de nuestro software durante el proceso de
desarrollo, más fácil será hacerle su mantenimiento ahora.
Tipos de mantenimiento:

• Correctivo: Se basa en corregir errores.

• Adaptativo: Acomodar el software a nuevos entornos o cambios del
mismo.
• Preventivo: Prevenir errores.
• Estructural: Modificar la arquitectura interna (reingeniería).
• Perfectivo: Mejorar, Añadir requisitos o ampliar los implementados.
Tenemos 3 estrategias de mantenimiento con las que abordar este proceso:

• Mantenimiento estructurado o planificado: Se acumulan las peticiones de cambio

aceptadas y se realizan todas a la vez cada cierto tiempo. Según llegan las
peticiones de mantenimiento, se evalúan y analizan. Las aprobadas se ponen en
una cola y se llevarán a cabo en el siguiente periodo que corresponda,
• Mantenimiento no estructurado: Es bajo demanda. Según llegan las peticiones
de mantenimiento se van resolviendo e implementando.
• Mantenimiento combinado: Lo primero que se hace es evaluar la petición de
cambio. Si es viable se analiza su severidad, ¿cómo de grave es para el sistema
informático y su entorno? Si no es muy severa se encola y se realizará en las
fechas de nuestro mantenimiento planificado. Si es muy grave, se atenderá
inmediatamente resolviendo la incidencia.
No hay una estrategia mejor que otra, esta dependerá de lo que se haya acordado con
el cliente y de la que sea mas adecuada para el proyecto. También es importante
actualizar la documentación a medida que se realizan los cambios, controlar las
versiones y asegurarnos de la calidad del producto que estamos manteniendo.
Antes de empezar cualquier actividad, debemos firmar con el cliente el contrato de
mantenimiento donde se recogen todas las condiciones bajo las que se realizará este
servicio. Justo al inicio deberemos llevar a cabo el plan de mantenimiento donde
establecemos qué vamos hacer, quién, cuándo y cómo. Al igual que el plan de desarrollo
debe irse actualizando a lo largo del proyecto. Por otra parte, debemos crear un
formulario de petición de mantenimiento, de tal forma que el cliente solicite su petición
siempre a través de este formulario y del medio que hayamos acordado con él.
Finalmente, el informe de cambios recoge los detalles del cambio ya realizado,
incluyendo objetivos, fecha, esfuerzo, persona encargada del cambio, etc. Y, muy
importante, no nos olvidemos tampoco de documentar los programas que cambiemos
para que queden registradas las modificaciones que vayamos realizando.