OPTATIVA I: MODELADO DE PROCESOS PARA EL DESARROLLO DE SOFTWARE

Unidad I Introducción a la Ingeniería de Software

Herramienta de Evaluación Caso Práctico, Tabla Comparativa y Reporte
Rubro Saber Hacer (Parte 1 de 1)
Valor de la Actividad 4.0 pts. de un total de 4.0
Facilitador: M.C. Roberto Carlos Pérez Fernández

M
Cuatrimestre: 7 Grupo: TIC Sección: B Fecha: 25 de septiembre de 2015
Entrega en Tiempo: SI NO Hora Fuera de Tiempo:
Instrumentos: Caso Prác: Tabla: Reporte: Formato y Responsabilidad
Apellidos de los Participante(s):
Pérez Aguirre Josefina
Reyna Arredondo Miguel Ángel
Rodríguez Rodríguez Omar Raziel
Sáenz Cárdenas Virginia
Torres Baena Karla

Nota: Los Renglones Referentes A Las Fechas Y Hora De Entrega Serán Llenados Únicamente Por El Facilitador

Comentarios Generales:

1
 REQUERIMIENTOS
MODELO EN CASCADA

REQUERIMIENTOS

Uno de los principales requerimientos para este requerimiento, es que contenga las funcionalidades de
funcionalidades básicas e una calculadora para que así tenga un conocimiento más a fondo sobre lo que él
requiere. Una calculadora es un dispositivo que se utiliza para realizar cálculos aritméticos. Aunque las
calculadoras modernas incorporan a menudo un ordenador de propósito general, se diseñan para realizar
ciertas operaciones más que para ser flexibles. Por ejemplo, existen calculadoras gráficas especializadas en
campos matemáticos gráficos como la trigonometría y la estadística.

Mencionemos algunas funcionalidades básicas de una calculadora: + Sumas: Efectúa la suma, - Resta: Efectúa la
resta o sustracción, / División: Esta tecla ejecuta la división, * Multiplicación: Esta tecla ejecuta la multiplicación
y = Igual: Muestra el resultado de una operación matemática. Puede ser utilizado durante un cálculo en proceso
para asegurarse de que un cálculo intermedio cálculo se encuentre incompleto. Oprimiendo = se asegura que
ninguna operación o cálculo este pendiente. Algunas funciones hacen uso del botón Algunas funciones hacen
uso del botón = para significar la finalización de ingreso de datos, antes de proceder a evaluar el resultado.

Otro de los requerimientos de nuestro cliente es mostrar una ventana con la información de nuestro cliente
indicando al usuario que espere mientras se carga la aplicación. Las pantallas de “en proceso, o espere” son
importantes respetarlas ya que le permites al programa o bien a nuestra aplicación que se instale
correctamente, en este caso la pantalla de espera es solo permitirías que la aplicación pueda abrirse
correctamente y pueda funcionar como lo deseas, ya que permitimos que sus datos se reestablecieran con
toda la información que esta misma ha obtenido durante su proceso de carga de datos.

Por otra parte lo botones se van representaran con símbolos relacionados a su función como corresponde a
cada uno de ellos, se reflejaran en la pantalla para tener mayor facilidad de realizar las operaciones que
nuestro cliente requiera hacer. Los botones de calculadora son importantes ya que permiten realizar algunos
cálculos complejos e importantes que de otra forma no se podrían efectuar.

Esta aplicación además de tener funcionalidades básicas , pantalla de proceso en carga y botones según su
función, también contara con otra pantalla mostrando error cuando los procesos que se estén calculando o
se envíen este incorrectos.

2
MODELO CASCADA DISEÑO

DISEÑO

Vamos a desarrollar una calculadora muy básica, con la capacidad de realizar las operaciones matemáticas de
suma, resta, multiplicación, división de dos números así como tener la capacidad de elevar un número a la n
potencia, con dos campos de texto en los que el usuario podrá introducir los números a operar y cuatro botones
para realizar las operaciones de suma, resta, multiplicación y división.

Figura 1. Fase Requisitos

Esta imagen se muestran loso tipos de funcionalidades de una calculadora

Se agregara el proceso de carga de la aplicación para poder ejecutar y utilizar con éxito la aplicación. En esta
ventana se reflejara un mensaje que describirá el proceso de carga de los datos de la aplicación. Este proceso
permitirá cargar datos borrados y archivados que se estén resguardando dentro de la base de datos que
contendrá esta aplicación para un mejor funcionamiento.

Figura 2. Fase Requisitos

Proceso de carga que se reflejara en la aplicación cuando esta esté en ejecución

Esta misma aplicación se le agregara otra pantalla para mostrar los números mediante de botones para mayor
facilidad. El usuario podrá seleccionas a su gusto los números ya sea a través del teclado o a través del ratón
indicando así mismo el tipo de operación a realizar y finalmente mostrara en otra pantalla el resultado ya sea
correcto o incorrecto, de igual manera se le agregara una pantallas extra mostrando el éxito de la operación o
el erro de la mismas operación.

Figura 3 Fase Requisitos

3
 Imagen de correcto e incorrecto del proceso

MODELO CASCADA CODIFICACION

CODIFICACION

Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos
para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y
componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho
más rápido.

En esta fase nosotros puedes expresar el código de la aplicación, claro ya después de haber tenido los
requisitos, diseño de nuestro cliente. El diseño debe traducirse en una forma legible para la maquina. El paso
de codificación realiza esta tarea

Como podernos desarrollar una buena aplicación en un buen programa. Examina el programa que está
disponible actualmente para cumplir la tarea que quieres hacer y revisa si existe la manera de hacer que el
proceso sea más fácil o estable. Un programa exitoso es aquél que los usuarios encuentren muy útil.

Escribe todas las ideas que se te ocurran. Incluso si parece algo tonto o extravagante, puede tratarse de algo
que podría convertirse en algo útil o incluso brillante.

Para no tener problemas con los programas para desarrollar nuestras aplicaciones debemos preguntarnos esto
sobre nuestro programas Qué es lo que hacen? ¿Cómo podrían hacerlo de una mejor manera? ¿Qué es lo que
les falta? Las respuestas a estas preguntas pueden ayudarte a pensar en ideas para tu propia perspectiva.

Figura 4 Fase Codificación

En esta imagen se refleja la como seria la programación para nuestra aplicación

4
 PRUEBAS
MODELO CASCADA

PRUEBAS

En esta fase es importante realizar las pruebas necesarias para la ejecución de nuestra aplicación ya que nos
daremos de los errores de esta aplicación, de lo sobrante que no requiere, lo faltante para esta aplicación. En
esta fase realizan todas las pruebas necesarias para la ejecución de esta aplicación, es importante regresar a
los requerimientos que nuestro cliente requirió podrás corregir, agregar o quitar cosas de mas.

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona
correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Los desarrolladores cada vez estamos más concienciados de la importancia de las pruebas de software. Pero no
podemos pasar por alto la calidad de estas pruebas, ya que podemos caer en errores no contemplados sin
darnos cuenta. No es suficiente con hacer un par de tests y pensar que todo está todo correcto porque nuestra
aplicación pasa esos tests, es importante pararse a pensar si cómo hemos planteado las pruebas es la forma
correcta para detectar errores reales del código

La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren.

Figura 5 Fase Pruebas

Muestra las pruebas funcionales y del sistema de software

5
 MANTENIMIENT
O
MODELO CASCADA

MANTENIMIETO

Una de las etapas más críticas, ya que se destina un 75 % de los recursos, es el mantenimiento del Software ya
que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

En esta etapa después de haber revisado las expectativas que no se cumplieron, nos podemos regresar a la fase
en que estemos mal para poder corregir las áreas de oportunidad detectadas volver a corregía regresar a los
requisitos, diseño, codificación, pruebas o mantenimiento. El “Mantenimiento” implica a corregir errores no
descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y
saltar los servicios del sistema una vez que descubren nuevos requerimientos.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido
a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema
operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.

Figura 6 Fase Mantenimiento

Hay que pedir y tener el soporte suficiente de otras personas para poder realiza el mantenimiento.

6
 MODELO CASCADA

REQUERIMIEN
TOS

DISEÑO

CODIFICACION

PRUEBAS

MANTENIMIENT
O

7
MODELO V
Es una representación gráfica del ciclo de vida del desarrollo de sistemas, es un proceso que
representa una secuencia de pasos en el desarrollo del software. A continuación se muestra el
diseño del modelo requerido, así como el desarrollo de cada fase del modelo para el desarrollo
de la aplicación de la calculadora que requiere nuestro cliente.

El lado izquierdo El lado derecho

representa la creación representa la
de las verificación.
especificaciones.

Figura 1 Modelo V.
Modelo V, donde representa la creación de las especificaciones, así
como su verificación.

Objetivos del modelo V son los siguientes: Mejora la transparencia y control del proyecto, se describen
resultados y las responsabilidades de cada función, es un modelo de procesos estándares que nos asegura
obtener resultados con la calidad deseada, todo el proceso del ciclo de vida de un sistema lo podemos calcular y
controlar mediante la aplicación de procesos estandarizados, así reducen la dependencia de los proveedores.
Partes de la gráfica V

Figura 1.2 Modelo V.

Representa cada fase del modelo V.

 Requerimientos
 Diseño del sistema
 Códigos
 Pruebas de unidad e integración
 Pruebas de aceptación

8
Requerimientos: (Esta es la parte donde inicia el proyecto) Un cliente importante de una empresa de diseños
de carpintería de la Cd. De Torreón Coahuila, desea desarrollar una aplicación extensa y precisa que tenga la
mejor funcionalidad para facilitar su trabajo en la vida diaria de las personas, y que pueda mejorar el proceso de
trabajo de él y de sus empleados, la aplicación que requiere es similar a una calculadora para la utilización de
necesidades en la empresa, de los clientes, asistentes, empleados, gente externa y demás también sirve para el
uso en la vida cotidiana de cualquiera de nosotros, para administrar las cuentas de las cotizaciones que
requieren los clientes externos que requieren servicio de la carpintería, cada cliente llega con la necesidad de un
producto, el dueño como vendedor del producto requiere sacar precios, costos, importes, cotizaciones,
intereses, descuentos, promociones, y más costos acerca de la productividad de la empresa, requiere hacer
inventario para saber acerca del material que se terminó así como para saber el material requerido para la
nueva inversión, para la realización de nuevos materiales en la carpintería, de esta manera son más las ventas
en la empresa, la aplicación de la calculadora es la mejor opción para la realización de estas necesidades, por
eso la empresa requiere tener a la mano este software para desarrollar los requerimientos necesarios para la
facilitación de resolución de problemas. Requerimientos el conjunto de técnicas y procedimientos que nos
permiten conocer los elementos necesarios para definir nuestro proyecto, El análisis de requerimientos es la
tarea que plantea la asignación de software a nivel de sistema y el diseño de programas. El análisis de
requerimientos facilita al ingeniero de sistemas especificar la función y comportamiento de los programas,
indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe cumplir el
programa. El análisis de requerimientos nos permite refinar la asignación de software y representar el dominio
de la información que será tratada por el programa, “la aplicación de la calculadora”, el análisis de
requerimientos da al diseñador la representación de la información y las funciones que pueden ser traducidas
en datos, “el cliente que requiere la calculadora”, arquitectura y diseño procedimental. Finalmente, la
especificación de requerimientos suministra al dueño y al cliente, los medios para valorar la calidad de los
programas, una vez que se haya construido.

9
Análisis de necesidades y definición: el software desarrollado que el cliente desea obtener por medio de la
empresa de carpintería deberá tener las siguientes características de una calculadora científica: deberá poder
sumar, deberá restar, deberá dividir, también deberá elevar un número a cierta potencia, todo esto deberá
tener funcionalidad en la aplicación requerida, además de tener otras funcionalidades como definir
contraseñas, diferentes códigos de inicio, tener códigos de bloqueo, dar solución a problemas, y saber qué es lo
que el cliente requiere para la realización de la aplicación de la calculadora, el cliente también debe ser una
persona capaz de tener el conocimiento sobre el uso del software que requiere, saber qué es lo que necesita
sumar, dividir, restar, multiplicar, agregar potencias elevadas, etc., el cliente es la parte importante aquí, puesto
que el decide que requerimientos deberá contener su software, el nos dará especificaciones de cómo quiere
que sea el funcionamiento de su aplicación, como lo detallamos anteriormente el cliente decide la
funcionalidad, mientras la empresa realiza la aplicación el cliente decide si agregar o no agregar más detalles a
este, La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, El ámbito del
programa, establecido inicialmente durante la ingeniería del sistema, es refinado en detalle. Se analizan y
asignan a los distintos elementos de los programas las soluciones alternativas, tanto el que desarrolla el
software como el cliente tienen un papel activo en la especificación de requerimientos. El cliente intenta
reformular su concepto, algo nebuloso, de la función y comportamiento de los programas en detalles concretos,
El que desarrolla el software, en este caso nosotros como desarrolladores de la aplicación de la calculadora
actúa como interrogador, consultor y el que resuelve los problemas El análisis y especificación de
requerimientos puede parecer una tarea relativamente sencilla, pero las apariencias engañan, puesto que el
contenido de comunicación es muy alto, abundan los cambios por mala interpretación o falta de información
entre el cliente y el desarrollador del software, el dilema con el que se enfrenta un ingeniero de software puede
ser comprendido repitiendo la sentencia de un cliente anónimo: "Sé que crees que comprendes lo que piensas
que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir", para eso es muy
importante la comunicación entre el vendedor “nosotros” y el cliente, si no hay comunicación se pierden
muchos aspectos importantes, ya que se requiere saber las necesidades como vendedores, siempre debe haber
comunicación entre ambos, La evaluación del problema y la síntesis de la solución es la siguiente área principal
de trabajo del análisis, nosotros como desarrolladores de este software (“la calculadora” ) debemos evaluar el
flujo y estructura de la información, debemos refinar en detalle todas las funciones del programa, (“la
calculadora” ), establecer las características de la interface del sistema y descubrir las ligaduras del diseño, Cada
una de las tareas sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o solución
global, Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza
técnicas tales como evaluaciones, inspecciones y tutoriales. La validación es el proceso de comprobar que lo
que se ha especificado es lo que el usuario realmente quería, se trata de evaluar el sistema o parte de este
durante o al final del desarrollo para determinar si satisface los requisitos iníciales. La pregunta a realizarse es:
¿Es esto lo que el cliente quiere?, para eso es el análisis y el requerimiento del software.

10
Diseño del sistema: Al principio de ejecutar la aplicación “tipo calculadora” el cliente desea que muestre una
pantalla con información de él, además indicando que al presionar la tecla pedirá la opción de bloqueo
automáticamente, así como también su botón de “desbloqueo con éxito”. Nuestro cliente desea también que
su aplicación sea capaz también de mostrar mensajes de error cuando se accionen o se introduzcan datos
incorrectos, en orden no adecuado o que rompan las leyes matemáticas así como una impresión de las
operaciones realzadas. Alguna tecla me lance un mensaje diciendo… “cargando, espere un momento”, l a
interface principal del programa debe de mostrar los números a usar en botones de tal manera que el usuario
los pueda accionar ya sea a través del teclado o a través del ratón indicando así mismo el tipo de operación a
realizar La pantalla principal de la aplicación debe de mostrar los números a usar en botones de color negro,
estos de tal manera que el usuario los pueda accionar ya sea a través, deberá poder sumar, restar, deberá
dividir, también deberá elevar un número a cierta potencia, todo esto deberá tener funcionalidad en la
aplicación, Las necesidades del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es
necesario tener archivada una copia de la documentación original del cliente, así como cada revisión o cambio
que se haga a esta documentación. Como cada necesidad del cliente es tratada de diferente forma, es necesario
clasificar estas necesidades para saber cuáles de ellas serán satisfechas por el software y cuales por algún otro
producto del sistema, La especificación de requisitos de software es la actividad en la cual se genera el
documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades
del sistema que será desarrollado; describe el alcance del sistema y la forma en cómo hará sus funciones,
definiendo los requerimientos funcionales y los no funcionales, El diseño físico, actividad que sigue el diseño
lógico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseño indican
a los programadores que debe hacer el sistema. Nosotros como programadores escribimos los programas que
aceptan entradas por parte de los usuarios, procesan los datos,
Producen los informes y almacenan, estos datos en los archivos
Utilización de los datos de Requerimientos:
El alcance del diseño de sistemas se guía por el marco de referencia para el nuevo sistema desarrollado durante
el análisis. Los datos de los requerimientos, recopilados durante la investigación, conforman las actividades y
componentes del sistema. Los analistas formulan un diseño lógico que apoya los procesos y decisiones, los
contenidos del sistema pueden cambiar como resultado de un nuevo diseño.
El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de requerimientos.
En primer lugar se identifican las características generales, como informes y entradas; en el diseño de la salida
por ejemplo, los analistas deben conocer la longitud de campo de un dato específico para establecer cuanto
espacio dejar en la información, en la pantalla de despliegue visual o archivo.

11
Codificación: Basados en este documento de diseño de software de la aplicación para el dueño de la carpintería
se pone en marcha el desarrollo de esta, se codifica cada secuencia, con el fin de que el proyecto tenga
funcionalidad a como lo requiere el cliente, en la actualidad el trabajo de codificación, suele ser automático, y
su revisión también, mediante un lenguaje de programación adecuado, es el proceso de diseñar, codificar,
almacenar, depurar y almacenar el código fuente de programas fundamentales y computacionales, el propósito
de la codificación es tener conocimientos en varias áreas distintas, además del dominio al lenguaje a utilizar,
algoritmos especializados y lógica formal, el codificar no necesita necesariamente otras áreas como el análisis y
diseño de la aplicación, pero si el diseño del código, aunque si suelen estar fusionadas en el desarrollo de
pequeñas aplicaciones, Para codificar un algoritmo hay que conocer la sintaxis del lenguaje al que se va a
traducir. Sin embargo, independientemente del lenguaje de programación en que esté escrito un programa,
será su algoritmo el que determine su lógica , En esta etapa se tienen que traducir dichos algoritmos a un
lenguaje de programación específico; es decir, las acciones definidas en los algoritmo hay que convertirlas en
códigos
Para codificar un algoritmo hay que conocer la sintaxis del lenguaje al que se va a traducir. Sin embargo,
independientemente del lenguaje de programación en que esté escrito un programa, será su algoritmo, la
lógica de un programa establece cuáles son sus acciones y en qué orden se deben ejecutar. Por tanto, es
conveniente que todo programador aprenda a diseñar algoritmos antes de pasar a la fase de codificación.

12
Pruebas de integración y verificación: Aquí cada unidad es desarrollada de forma independiente, el cliente
verifica que el proyecto tenga sus requerimientos bien desarrollados, para no tener que pagar por hacer un
cambio, después de esto, se puede probar su funcionalidad, este es el proceso de revisión que verifica que el
sistema de software producido cumple con las especificaciones y que logra su cometido. Es normalmente una
parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones,
inspecciones y tutoriales. La validación es el proceso de comprobar que lo que se ha especificado es lo que el
usuario realmente quería, se trata de evaluar el sistema o parte de este durante o al final del desarrollo para
determinar si satisface los requisitos iníciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?, La
prueba y mantenimiento del programa es esencial para minimizar el riesgos por el uso de la aplicación
requerida. Es conveniente realizar la verificación y prueba antes de utilizar el sistema para un evento "en vivo"
(tanto en sí mismo como de manera conjunta con el equipo y las comunicaciones). Después de una prueba
exitosa, se requiere darle a los programas el debido mantenimiento para garantizar su buen funcionamiento
cuando se les requiera, para eso el cliente “la carpintería” requiere su aplicación de una calculadora y debe
especificar cuáles son sus necesidades para nosotros como desarrolladores poder cumplir con sus necesidades
como empresa, para eso hay que saber sus necesidades, el nivel de importancia de la tecnología impactará el
grado de rigor aplicado a los programas de verificación, prueba y mantenimiento de los programas. Para los
sistemas que se usen para desempeñar funciones electorales cruciales, como una votación electrónica, el grado
de rigor requerido será mayor, si bien ésta y las dos secciones que la acompañan separan el equipo, los
programas y las comunicaciones en tres apartados, su operación es con frecuencia interdependiente, y los
procedimientos de verificación, prueba y mantenimiento que se indican pueden llevarse a cabo con los tres
componentes en su conjunto.

13
Verificación del sistema: Después de que la aplicación ha superado las pruebas correspondientes que requirió
el cliente de Torreón, incluyendo el sistema completo tiene que ser evaluada con sus requisitos iníciales, para
poder pasar a la siguiente etapa que es lo más interesante, probar si funciona o no funciona la aplicación
deseada, La revisión de los requerimientos (nuestra aplicación, “la calculadora”), casi siempre produce
modificaciones en la función, comportamiento, representación de la información, ligaduras o criterios de
validación, eso dependiendo si el cliente requiere cambios, además se realiza una nueva apreciación del plan
del proyecto de software para determinar si las primeras estimaciones siguen siendo válidas después del
conocimiento adicional obtenido durante el análisis, Las pruebas de verificación de los programas, en este caso
(“nuestra aplicación”) (también conocida como pruebas de calidad) pueden comprender lo siguiente, probar los
programas para asegurar que reúnen los estándares exigidos y ejecutan las tareas esperadas, incluyendo
auditorías de código, asegurar que la documentación del sistema es la adecuada y esté completa, verificar que
el sistema es capaz de funcionar bajo las condiciones normales esperadas y potenciales condiciones adversas,
garantizar que se cuenta con medidas de seguridad y que estas se ajustan a los estándares establecidos,
asegurar que se cuenta con las debidas medidas de control de calidad, Puede ser necesario realizar auditorías a
los códigos de los programas, particularmente cuando estos se utilicen para sistemas cruciales. Generalmente
estas auditorías son más efectivas cuando las llevan a cabo expertos independientes de los autores del código.
Una auditoría de programas puede incluir medidas como las siguientes, verificar que el código es lógicamente
correcto, asegurar que el código tiene un diseño modular (es decir, está conformado por módulos que pueden
ser probados y evaluados por separado), revisar que no existan códigos "ocultos " que puedan ejecutar
funciones no autorizadas, verificar que todos los códigos sean directos y relativamente fáciles de entender,
asegurar que el código está diseñado para ser probado fácilmente -es decir, que permite probar los flujos de
información dentro y entre los módulos, verificar que el código incluya mecanismos correctores de errores que
permitan su detección inmediata y prevenir pérdidas de información, asegurar que el código cuenta con
mecanismos de seguridad para impedir accesos no autorizados, constatar que el sistema es utilizable sin
necesidad de procedimientos complejos u obscuros, asegurar que los programas pueden ser instalados
fácilmente, verificar que se les puede dar fácil mantenimiento a los programas y que, una vez instalados,
pueden identificarse y corregirse errores o defectos con facilidad, revisar si los programas pueden ser
modificados fácilmente para agregarles nuevas características.

14
Operación y mantenimiento: (Esta es la fase final del modelo V.) Se entrega al cliente la aplicación de la
calculadora para que la utilice por primera vez y así vea su funcionamiento, la vea completamente a detalle y
nos haga saber sus dudas o comentarios, también que muestre el resultado en la pantalla, de tal manera que si
le gustó o quedó satisfecho, después de que el programa ha sido verificado, probado e implantado, se debe
seguir dando mantenimiento, las rutinas de mantenimiento variarán de acuerdo con el tipo y complejidad de la
tecnología. Nosotros como vendedores y desarrolladores de software definimos el calendario de
mantenimiento requerido, siempre va a variar, el mantenimiento también puede ser realizado por el cliente
dependiendo el acuerdo en el que lleguemos nosotros con cada uno de nuestras clientes, a los sistemas se les
debe dar mantenimiento para asegurar que continúen operando en el nivel mostrado durante la etapa de
prueba. Si los sistemas se deterioran, existe el riesgo de que no se desempeñen conforme a los estándares
requeridos, puede ser necesario instalar sistemas de monitoreo o prueba para asegurar que las necesidades de
mantenimiento sean identificadas y satisfechas cuando resulte necesario. Cuando los sistemas son de uso
prolongado, se puede establecer un mecanismo para recibir retroalimentación de los usuarios como otra forma
de determinar las necesidades de mantenimiento y modificación, cuando se realicen modificaciones a los
programas como resultado de ejercicios de mantenimiento o actualización, puede ser necesario promover
rondas adicionales de verificación y prueba del sistema para asegurarse que siguen cumpliendo las normas
exigidas, Una vez que el programa a sido verificado, requieren ser rigurosamente probados para asegurar que
cada componente opere como es debido y que el sistema funcione exactamente de acuerdo con los
requerimientos locales específicos, entre las medidas de prueba se pueden considerar las siguientes, desarrollar
un conjunto de criterios para la prueba, aplicar pruebas funcionales para determinar si se han satisfecho los
criterios de prueba, aplicar evaluaciones de calidad para determinar si se han satisfecho los criterios de prueba,
conducir pruebas en condiciones de "laboratorio" y en una variedad de condiciones "reales", conducir pruebas
durante un periodo prolongado, para cerciorarse que los sistemas pueden funcionar de manera consistente ,
conducir "pruebas de carga", simulando tanto como sea posible una variedad de condiciones reales utilizando o
excediendo los volúmenes de información que se pueden esperar en una situación concreta , verificar que lo
que entra es lo que sale, introduciendo información conocida y verificando que el resultado sea consecuente
con ella.

15
 Modelo espiral

1.0 REQUERIMIENTOS Y OBJETIVOS

Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades
esenciales y deseables. La captura de los requerimientos tiene como objetivo principal la comprensión de lo
que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema
sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el que del sistema,
mientras que el diseño establece el como del sistema. La captura y el análisis de los requerimientos del sistema
es una de las fases más importantes para que el proyecto tenga éxito. Como regla de modo empírico, el costo
de reparar un error se incrementa en un factor de diez de una fase de desarrollo a la siguiente, por lo tanto la
preparación de una especificación adecuada de requerimientos reduce los costos y el riesgo general asociado
con el desarrollo

1.1 Funcionalidad
El cliente está profundamente interesado en una aplicación que sea muy similar a una calculadora en aspecto y
función.
El desea que cumpla con las operaciones matemáticas básicas las cuales son suma, resta, multiplicación y
división, aparte está interesado en agregar la función de potencia.
El cliente quiere un sistema confiable en las operaciones matemáticas pidió que se agregara un mensaje de
“error” en una ventana emergente cuando se accionen o se introduzcan datos incorrectos, en orden no
adecuado o que rompan las leyes matemáticas.

1.2 Interfaz
Una vez ya establecidos los requerimientos de funcionalidad principal nos enfocamos en La interface el cliente
desea que en la interfaz principal del programa muestre los números a usar en botones de tal manera que el
usuario los pueda accionar ya sea a través del teclado o a través del ratón.
Al igual que se refleje el tipo de operación a realizar y finalmente mostrar el resultado de la operación en la
pantalla.

1.3 Ejecución
En esta parte la aplicación, debe arrojar una ventana con toda la información del cliente y que indique que
espere mientras se carga la aplicación.

1.4 documentación
El sistema solo arrojara un documento que es la impresión de las operaciones realizadas por el cliente

16
2.0
ANÁLISIS DE RIESGO

Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un
proyecto de software. Es una tarea de ingeniería del software que permite especificar las características
operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las
restricciones que debe cumplir el software.
La especificación de requerimientos suministra al técnico y al cliente, los medios para valorar el cumplimiento
de resultados, procedimientos y datos, una vez que se haya construido. La tarea de análisis de los
requerimientos es un proceso de descubrimiento y refinamiento, el cliente y el desarrollador tienen un papel
activo en la ingeniería de requerimientos de software. El cliente intenta plantear un sistema que en muchas
ocasiones es confuso para él, sin embargo, es necesario que describa los datos, que especifique las funciones y
el comportamiento del sistema que desea. El objetivo es que el desarrollador actúe como un negociador, un
interrogador, un consultor, o sea, como persona que consulta y propone para resolver las necesidades del
cliente.

El objetivo de este proyecto es dar un sistema de calidad y seguridad al nuestro cliente minimizando a 0 de
preferencia los riesgos, retrasos y malos entendidos que le restan credibilidad y funcionamiento como costos
extras a nuestro proyecto.

Para eliminar los riesgos aremos una administración de actividades haciéndolo en 3 prototipos para asegurar la
calidad y funcionamiento y eliminar errores, bucles en el sistema y malos diseños apoyados en el diagrama de
Gantt de la fig. 1.

Fig. 1 diagrama de Gantt

En él se administran las actividades por tiempos para eliminar riesgos innecesarios o una mala organización por
parte de los programadores y demás involucrados en el proyecto.

17
3.0 DESARROLLO PROTOTIPO 1

En esta primera etapa del desarrollo nos vamos a enfocar en la funcionalidad y la interfaz de sistema.
Para esto nos regresamos a los requerimientos del cliente para ver qué es lo que necesita y así diseñar el cómo
lo vamos a hacer.

Empezamos diseñando la plataforma en la que vamos a trabajar ayudado con el programa visual studio y su
complemento blend
Para ayuda del diseño.

Este proyecto se basó básicamente en el diseño de una calculadora tradicional ya tiene mucha similitud a lo
que el cliente pide, anexando la función de potencia ya que esta solo se encuentra en calculadoras científicas al
igual que se añadió el botón de imprimir al diseño.

Para el diseño se utilizó la plataforma blend, en una mainwin.wpf agregamos un tex box que será nuestra
pantalla de la calculadora, se agregaron 12 botones que nos sirven como números el igual y el punto, de forma
que con el teclado o el ratón puedan ser agregados, para cumplir con el requerimiento.
De la misma forma agregamos 6 botones extras para las funcionalidades matemáticas al dado izquierdo
incluyendo el botón de potencia y el botón de borrar
Y por último se añadió el botón de imprimir para que el usuario pueda rescatar de forma impresa las
operaciones realizadas.

Fig. 2 diseño prototipo 1

En la fig. 2 vemos el aspecto de la interfaz sería el primer prototipo donde incluimos el diseño y anexamos sus
funcionalidades.
Este diseño aún está a que el cliente lo apruebe para continuar anexando las siguientes etapas a este proyecto.

18
4.0 PLANIFICACIÓN

Se montó el prototipo para una conferencia con el cliente para revisión de avances y eliminación de errores de
diseño y funcionalidad.
Estas conferencias son muy importantes para afianzar la confianza de nuestro cliente y para pulir detalles que
se hayan filtrado.

Al cliente le gusto nuestro diseño afortunadamente, probó cada una de las funcionalidades minuciosa y
detalladamente y concedió con nosotros de que la plataforma era muy amigable para el usuario y era
exactamente lo que él estaba buscando.

Se realizó una prueba con un empleado suyo, teniendo resultados positivos en la interacción programa-cliente
aparte de que nuestro sistema mostraba una estabilidad, fluidez y eficiencia al momento de hacer operaciones
básicas como operaciones más complejas

Esto marco la pauta para continuar con la segunda etapa de este proyecto.

19
5.0 DESARROLLO DEL PROTOTIPO 2

En esta segunda etapa implementaremos la ejecución y documentación estas se encuentran más especificadas
en los requerimientos del cliente que es la primera etapa de este proyecto.

Para este prototipo se creó una mainwin.wpf para el diseño de la ventana emérgete se manejó el mismo color
de fondo para que no se pierda el concepto de la aplicación.
Esta plantilla lleva un espacio para la información del cliente que la desplegamos en un label en la parte
superior izquierda y como complemento la fecha en la parte superior derecha, al igual que un textbox en el
cual nos lanzara el mensaje de espere mientras se carga la aplicación.
Esta ventana no cuenta con botones ni interacción solo está diseñada para dar tiempo a que el sistema se
cargue. Una vez completándose el proceso de carga la ventana se cerrara automáticamente para no cáusale
problemas al usuario y no tener que forzarlo a hacer más interacciones inútiles y se enfoque solo en lo esencial
que son las operaciones matemáticas a realizar.

Fig. 3 diseño de ventana emergente

Al igual se diseñó el formato del documento que el sistema tiene que imprimir como parte del método sugerido
por nuestro cliente
Para esto se diseñó en una plantilla mainwin en blanco donde os da la información del cliente y las operaciones
realizadas

20
Todo está desplegando con ayuda de texbox y labels que se actualizan según el contenido que llevara el
documento como se muestra en la fig. 4

Fig. 4 documento de impresión

21
6.0 PLANIFICACIÓN

Se armó el segundo prototipo para la cita con nuestro cliente donde se evaluaría la eficacia, ergonomía, diseño
y lo amigable del proyecto.

Una vez más el cliente dispuso de uno de sus empleados para que realizara distintas simulaciones en el
prototipo para observar su comportamiento.
Como era de esperarse el sistema continúo teniendo la estabilidad necesaria para que el cliente quedara
satisfecho con lo realizado.

A este punto nuestro cliente ya avía explorado cada uno de los requerimientos y los avía aprobado.
Este es el punto clave del proyecto ya que los prototipos fueron aceptados así que nuestro proyecto va en un
muy buen camino, ahora viene la última parte que es la integración de lo realizado en un solo sistema
respetando lo que el cliente ya a pre autorizado.

22
7.0 INTEGRACIÓN

En esta parte utilizamos el segundo prototipo que es la ventana del mensaje de espera mientras que en
segundo plano se empieza a cargar la aplicación.
Este proceso no tarda más de 30 segundos dependiendo del hardware del cliente ya que esto puede hacer que
varié la velocidad y fluidez del sistema.
Una vez concluido los 30 segundos se abriría el primer prototipo que es la base de la calculadora donde ya
están codificadas y cargadas las funciones lógicas de la calculadora.

Cargamos también el documento que imprime en el botón de impresión para darle vida a esta funcionalidad
que es compatible con cualquier impresora que el cliente tenga.

De esta manera el sistema estará total mente compilado y listo para la disposición del cliente teniendo un
calidad y estabilidad en el trabajo que es un plus para nuestro cliente ya que nos ubica como un empresa
responsable y nos abre las puertas para futuros proyectos o para una mejora del sistema a una escala mucho
mayor.

23
 Fig.5
modelo
implementado

Modelo de prototipos

Usaremos el método de Prototipos para desarrollar un caso de uso en el cual se apliquen cada una de las fases
que lo distinguen además de conocer un poco más de ellas.

Fase 1. Investigación preliminar:

Al inicio de cada solicitud por parte de un cliente lo más recomendable es establecer una reunión entre las
partes interesadas, los clientes y la persona a cargo del desarrollo de la aplicación. Dentro de este ambiente
pueden existir muchas variantes para un buen acuerdo, no obstante en la mayoría de los casos pueden existir
algunas barreras entre ambas partes por lo que lo recomendable es que esté presente la persona con la
suficiente experiencia para resolver dudas. La reunión debe llevarse a cabo en un lugar neutral, formal y que se
utilicen como mecanismos de apoyo gráficas, diagramas, ejemplos etc. Un cliente importante de la región
necesita desarrollar un software debido a que está interesado en una aplicación para computadora, la cual
tenga una función similar a una calculadora, con esto asegurara llevar un proceso más rápido con eficiencia,
planificación y productividad.

Es necesario fomentar procesos de evaluación en función de optimizar el uso de los recursos humanos,
tecnológicos o financieros disponibles para lograr un desarrollo más armónico y planificado. Bajo esta
perspectiva se ofrece una propuesta de Prototipo para el desarrollo de una aplicación. El prototipo es una
aplicación que funciona con la finalidad de probar varias suposiciones formuladas por analistas y usuarios con
respecto a las características requeridas del sistema, se crean con rapidez, evolucionan a través de un proceso
interactivo y tienen un bajo costo de desarrollo.

Cuyos requerimientos principales son: desarrollar la capacidad de realizar operaciones matemáticas de suma,
resta, multiplicación, división, elevar un número a una potencia, además de que adquiera la capacidad de
mostrar mensajes de error cuando se accionen o se introduzcan datos incorrectos en un orden no adecuado o
que rompan las leyes matemáticas así como impresión de las operaciones realizadas. Para el desarrollo, se
aplicarán las herramientas y técnicas para levantar los requerimientos de usuario, y producir las salidas que
satisfagan las necesidades de información y el acceso en forma integrada a la misma, se aplicara el modelo de
prototipo.

Recordemos que es nuestro contacto inicial con el cliente, tenemos que aprender a escuchar detalladamente
cada uno de los requerimientos, ya es una base fundamental para las siguientes etapas, aquí es donde se
definen los requerimientos, objetivos, recursos a utilizar, el tiempo que vamos a invertir, los costos, de esta
manera podemos brindarle una mejor solución y con ello un buen servicio.

Cuando nos encontramos elaborando una aplicación para un cliente determinado cometemos errores por
querer quedar bien con el cliente y no sabemos decir “NO” lo que nos puede comprometer de más en cuento a
tiempos de entrega o desarrollar algo que sabemos de antemano que no podemos hacer, por lo general es muy
común tener ese tipo de roses con los clientes ya que a ellos sus jefes les dan un tiempo de entrega pero a veces
están tan ocupados que lo dejan para al final lo que provoca todos los contratiempos anteriores.

Siguiendo con los análisis del cliente nos faltaría analizar los tiempos de entrega, quien va estar a cargo del
proyecto es decir conocer a las personas a las cuales nos tenemos que dirigir para un mejor resultado, realizar
una cotización en base a lo solicitado siempre y cuando todos los requerimientos sean reales, brindarle al
cliente la mejor opción, realizar una planeación de las tareas y fechas de entrega que vamos a ir realizando,

24
tener en
cuenta
todo y cada uno de los procesos a seguir. Hay un dicho en programación que dice “yo lo creo en hechos y datos”
remarcando la importancia de contar con la información, con data podemos crear en supuestos que no tienen
rigor.

Fase 2. Análisis y especificación:

Análisis es un procedimiento para determinar tareas y requisitos de aptitudes de trabajo y el perfil del personal
con el propósito de destacarlo, su responsabilidad de ejecución, relaciones e informes de trabajo,
generalmente se parte de un método o una hoja de operaciones estimulada de las distintas tareas a realizar.
Dentro de esta primera fase se establece el problema que se va a resolver mediante el software. Una vez
establecido el problema se hace una recopilación exhaustiva de información para determinar las características
y el funcionamiento que el sistema debe tener, con base a estos requerimientos se realiza un primer
acercamiento al proceso que debe realizar el software para lograr su cometido, esto se ve reflejado en un
modelo de funcionamiento que debe considerar al usuario final.

Como su mismo nombre de la fase lo dice realizamos un análisis detallado del software y especificamos que
objetos va a llevar, como vamos a formar su diseño básico. Continuando con el desarrollo de la aplicación
podemos definir que nuestro cliente es una persona seria que busca este software con el objetivo principal de
mejorar su proceso y facilitarlo, por lo tanto podemos comenzar por plasmar nuestra idea en algún cuaderno
definir sus puntos principales como su función principal, pensar en colores similares a los logos de la empresa,
trabajaremos de la mano con nuestro cliente para crear un prototipo (algo sencillo) que nuestro cliente se valla
dando la idea de cómo estaremos trabajando siempre contando con su aprobación y establecer confianza.

El mejor consejo es simplificar el programa, lo principal es identificar la entrada, su manipulación y producir una
salida. Recordemos que un modelo se centra básicamente en lo que debe hacer un sistema y no en como lo
debe hacer, este llega hacer el puto de revisión además se convierte en la base del diseño proporcionando una
representación o depende de nosotros escoger un modelo en el cual tengamos que realizar las cosas por partes
y posteriormente juntarlas. Una vez revisados los requerimientos, analizado sus necesidades y posibles
soluciones definimos el tipo de lenguaje que se va a utilizar de acuerdo con las necesidades encontradas.

Los objetivos de un análisis y requerimientos son principalmente;

Actividades del puesto o servicio: En primer lugar, se establecen las actividades de trabajo propiamente dichas,
expresadas básicamente en verbos como Hacer, programar, clasificar, documentar, etc., con indicaciones sobre
el cómo, el porqué y el cuándo de esas actividades.

Comportamiento humano: Se reúne información en términos de exigencias personales del puesto, que van
desde el esfuerzo físico requerido y la exposición a factores ambientales desfavorables, hasta la atención
requerida, los niveles de decisión, de comunicación, etc.

Equipamiento utilizado en el trabajo: Se registra información sobre productos, materiales, máquinas, equipos,
herramientas, conocimientos aplicados, etc.

Criterios de desempeño: Se refiere a la cantidad y calidad de producto esperado, tiempo dedicado, integración
grupal, iniciativa, y todo otro criterio que luego sirva para evaluar el desempeño del trabajador.

Contexto del servicio: Se refiere a las condiciones físicas, temporales y sociales, interacciones conocimientos,
incentivos y dificultades.

25
Requerimientos humanos: Se refiere a los niveles y tipos de educación, capacitación, experiencia previa y
características personales físicas y anímicas, intereses, etc.

Fase 3. Diseño y construcción:

En esta fase se produce un modelo que cumpla con los requerimientos entregados en la fase de análisis, esto
tiene dos enfoques, el operativo y el computacional. En el operativo se consideran los métodos de ingreso y
salida de datos así como el diseño de pantallas, la forma como el usuario percibe el software desarrollado en la
parte computacional se deben determinar las variables que se van a manejar, así como el algoritmo que debe
implementarse, para esto se hace uso de diagramas, tablas, entre otros describiendo el lugar en donde cada
variable será almacenada y cómo será procesada. Es en esta fase donde el diseño evoluciona a algo más formal
y complejo, hablamos de la realización de nuestra aplicación, de poner en marcha todo los conocimientos
adquiridos en nuestras fases anteriores recordemos que una vez llegando a esta fase como nuestro método lo
dice “prototipo” podemos realizar nuestro primer prototipo es decir nuestro primer diseño y construcción
posteriormente revisarlo con el cliente. Cuando ya definimos el lenguaje de programación lo siguiente es
comenzar a desarrollar la aplicación lo más parecido posible a lo requerido en la primera fase.

En esta fase se produce un modelo que cumpla con los requerimientos entregados en la fase de análisis. Esto
tiene dos enfoques, el operativo y el computacional, en el operativo se consideran los métodos de ingreso y
salida de datos así como el diseño de pantallas. La forma como el usuario percibe el software desarrollado. En la
parte computacional se deben determinar las variables que se van a manejar, así como el algoritmo que debe
implementarse, para esto se hace uso de tablas, diagramas de flujo etc. Describiendo el lugar en donde cada
variable será almacenada y cómo será procesada podemos continuar con el diseño de nuestra página principal,
nuestra primera pantalla es nuestra carta de presentación, dicen que de la vista nace el amor por lo tanto que
tratemos de enamorar al cliente de su aplicación, la elaboración de una calculadora donde ingresaremos
números y realizara las operaciones de sumar, restas, multiplicar y dividir, la cual es un poco complicado al
momento de realizar las operaciones, entradas: crear ventanas, botones, formularios básicos, paneles y arreglos
de botones. Debe contener el método principal, y la otra clase contiene la interfaz, eventos y operaciones
realizadas por el ejercicio práctico. El programa realiza las cuatro operaciones básicas de las matemáticas (suma,
resta, multiplicación y división).

26
Se
incluyen los
resultados de las fases anteriores facilitando el proceso de mantenimiento del software ya que le permite a
nuevos equipos de desarrollo entender la labor realizada y les da pautas para continuar mejorando el sistema.
Una parte importante que no se puede dejar pasar es la documentación se subdivide en una documentación
interna y un manual técnico. La documentación interna se realiza poniendo comentarios dentro del código
fuente, comentarios cortos y precisos del proceso que se realiza. El manual técnico contiene el análisis con el
cuál se llega al problema, así como el algoritmo diseñado y el código fuente desarrollada. La segunda parte de la
documentación describe el funcionamiento del software y está dirigida a los usuarios finales. Esta es tan
importante como el desarrollo mismo, ya que con esta se aumenta la probabilidad de que el software sea
utilizado de la forma esperada, explotando todas las funciones y servicios que preste.

Fase 4. Evaluación:

Cuando llegamos a esta fase no quiere decir que ya terminamos, significa que podemos realizar un diagnóstico
de nuestro avance, es aquí donde podemos corregir errores, donde podemos evaluar los puntos principales de
nuestro software, nos auto revisamos los requerimientos iniciales, la secuencia de nuestro funcionamiento,
nuestro cliente determinara su primera evaluación dará el visto bueno o malo. La finalidad de esta etapa es
conocer nuestro avance y la oportunidad de que si algo no gusta podemos pasar a la siguiente fase y corregir
errores, modificaciones de diseño entre otros.

“Consiste en el proceso de comprobar la precisión de los datos, conjunto de reglas que se pueden aplicar a un
control para especificar el tipo y datos del usuario.”2 Cuando se hace un programa de carácter científico es
posible que los datos esperados como entradas no tengan siempre la misma naturaleza (números enteros,
números reales, expresiones, funciones, etc...). Es por esto que se deben realizar comprobaciones de datos para
asegurarle al usuario que los datos que está ingresando pueden ser procesados de la forma como el programa
fue diseñado y codificado. No basta con buena información gráfica, tampoco se puede confiar en el “sentido
común” ya que para el programador resulta demasiado evidente, pero se desconoce el enfoque que un usuario
le pueda dar.

En esta fase se busca detectar errores, sean computacionales, de diseño o de análisis. Se comparan los
resultados obtenidos con el software con los resultados esperados y se evalúa el comportamiento del sistema
en cuanto a velocidad y rendimiento. Esta prueba no debe confundirse con el proceso de depuración: durante la
prueba se determina la existencia de errores (el hecho de que no se encuentre ninguno durante esta fase no
prueba la inexistencia de errores), por otro lado, durante el proceso de depuración se determina la localización
del error (o los errores).

Tanto los programas como las funciones son desarrollos de software muy útiles para ampliar la funcionalidad de
nuestras calculadoras. Lo más importante de esta fase es evaluar los requerimientos iniciales, de esta manera
podemos darnos cuenta si nos desviamos de los requerimientos iniciales o estamos dentro de ellos. La
evaluación es una fase en la que nos permite estar al tanto de nuestras fallas y de lo que podemos mejorar, el
cliente es una pieza fundamental ya que la finalidad es brindarle la mejor solución además de dar la mejor
imagen y permitir que nos recomienden con más clientes activos.

Puede parecer aburrida y repetitiva esta fase por todo lo que tendrás que comprender sin embargo cada uno de
ellos tienen una finalidad importante, una enseñanza a lo largo de todo su proceso, en lo general nos muestra
que por más obvio que sean las situaciones en nuestra vida diaria todo lleva un proceso, todo se basa en algo
incluso nosotros mismos nos basamos en algo para realizar todas nuestras actividades, por ejemplo antes de ir a
dormir ya tienes un plan o tienes la idea de lo que vas a ser al día siguiente.

27
Evidentemente una cultura de calidad no se crea de la noche a la mañana, sino es el resultado del ejemplo, del
trabajo conjunto y de los resultados que se obtienen, es decir, los resultados retroalimentan el
comportamiento. Sin embargo, cuando se tiene una actitud favorable, ésta se constituye en un factor que pone
en marcha todo el proceso. Si bien, no se puede decir que las estrategias implementadas lograron establecer
una cultura de calidad, al menos, se pude afirmar que mejoraron las actitudes tanto del cliente como del
programador.

Fase 5. Modificación:

“La documentación de la aplicación es el conjunto de información que nos dice qué hacen los sistemas, cómo lo
hacen y para quién lo hacen.”

Una vez ya terminadas las fases anteriores e identificando todas las fallas podemos distinguir si los
requerimientos iniciales coinciden con nuestra aplicación y su finalidad. Esta etapa nos da la oportunidad de
regresar a la fase de evaluación una vez terminada esta, en caso de requerirse modificaciones es en esta etapa
es el momento de realizarlas, es donde el diseño del prototipo, la documentación para programación resaltan
como otro punto llamado diseño técnico ya que las fallas deben de estar solo en el diseño técnico puesto que
estas fases requieren en todo el proceso estar en contacto con el ciento.

Otro punto importante para la realización de la modificación es el diseño técnico ya que son implementadas y
probadas para optimizar su funcionamiento.

Por ultimo esta la operación y la mantención que no es otra cosa que el mantenimiento preventivo y correctivo
para que este alcance una mejor calidad de vida. Todo la aplicación está sujeto a cambios, las principales
razones pueden resumirse en los errores que los usuarios puedan encontrar en el sistema, así como un cambio
en el hardware o software que ocasionen incompatibilidad con el sistema, y por último, ampliaciones que
pueda requerir el sistema, detalles que no hayan sido contemplados durante las fases anteriores. Estos cambios
infieren que se retorne a las fases iniciales completando así el ciclo.

Este es el inicio de la vida útil del sistema desarrollado se debe abordar estrategias de distribución de la
aplicación y la comunicación de que los usuarios sean entrenados en el uso del mismo. Muchas veces un cambio
de sistema presenta problemas referentes a la conversión de sistemas anteriores al presentado, así como
problemas para su uso. Problemas que deben solucionarse para lograr el éxito del sistema.

“Consiste en el proceso de comprobar la precisión de los datos; conjunto de reglas que se pueden aplicar a un
control para especificar el tipo y el intervalo de datos que los usuarios pueden especificar. “Cuando se hace un
programa de carácter científico es posible que los datos esperados como entradas no tengan siempre la misma
naturaleza (números enteros, números reales, funciones, ecuaciones, etc...). Es por esto que se deben realizar
comprobaciones de datos para asegurarle al usuario que los datos que está ingresando pueden ser procesados
de la forma como el programa fue diseñado y codificado.

Cuando se realiza la etapa de modificación y después de llevarse a cabo los procesos internos en caso de faltar
modificaciones se tiene que regresar a la fase de evaluación y así sucesivamente hasta que esté todo correcto o

28
hasta que
el
cliente este satisfecho, lo más importante en general es aprender de cada uno de los errores que se nos van
presentando y saber solucionarlos ya que en todo momento de nuestra vida o incluso de una aplicación
tendremos que aprender a sobre llevarlo es indispensable ser siempre positivos y esforzarnos cada día por ser
mejores.

Tabla comparativa de los modelos de ingeniería de software

Modelo Modelo de Modelo de Espiral Modelo en V Modelo de

Cascada Prototipos
Fases *Análisis de *Comunicación *Conceptos de *Análisis y
requisitos: En esta con el cliente: Las Operaciones: Que especificación: El
fase se analizan las tareas requeridas debe hacer el propósito de esta
necesidades de los para establecer sistema a grandes sub fase es
usuarios finales del comunicación rasgos. desarrollar un
software para entre el *Requisitos del diseño básico para
determinar qué desarrollador y el sistema: el prototipo inicial.
objetivos debe cliente. Arquitectura del *Diseño y
cubrir. *Planificación: Las mismo diseño construcción: El
*Diseño del tareas requeridas detallado. objetivo de esta
Sistema: para definir *Programación: Es sub fase es obtener
Descompone y recursos, el tiempo la fase de un prototipo
organiza el sistema y otras implementación en inicial.
en elementos que informaciones la que se *Evaluación: Esta
puedan elaborarse relacionadas con el desarrollan los etapa tiene dos
por separado, proyecto. Son elementos propósitos: extraer
aprovechando las todos los unitarios o a los usuarios la
ventajas del requerimientos. módulos del especificación de
desarrollo en *Análisis de programa. los requerimientos
equipo. riesgos: Las tareas *Integración: adicionales del
*Diseño del requeridas para Integrar las sistema y verificar
Programa: Es la evaluar riesgos distintas partes, que el prototipo
fase en donde se técnicos y otras test y verificación desarrollado lo
realizan los informaciones de las mismas. haya sido en
algoritmos relacionadas con el *Verificación: En concordancia con
necesarios para el proyecto. esta fase se valida la definición de

29
cumplimiento de *Ingeniería: Las y verifica el requerimientos del
los requerimientos tareas requeridas sistema antes de sistema. Si los
del usuario así para construir una entregarse. usuarios identifican
como también los o más *Mantenimiento: fallas en el
análisis necesarios representaciones Se realiza prototipo,
para saber que de la aplicación. mantenimiento del entonces el
herramientas usar *Construcción y sistema creado. desarrollador
en la etapa de adaptación: Las simplemente
Codificación. tareas requeridas corrige el prototipo
*Codificación: Es la para construir, antes de la
fase en donde se probar, instalar y siguiente
implementa el proporcionar evaluación. El
código fuente, soporte al usuario. proceso de
haciendo uso de *Evaluación del evaluación puede
prototipos así cliente: Las tareas ser dividido en:
como de pruebas y requeridas para preparación,
ensayos para obtener la reacción demostración, uso
corregir errores. del cliente según la del prototipo y
*Pruebas: Los evaluación del discusión de
elementos, ya software creado comentarios.
programados, se durante la etapa En esta fase se
ensamblan para de ingeniería e decide si el
componer el implementación prototipo es
sistema y se durante la etapa aceptado o
comprueba que de instalación. modificado.
funciona *Modificación:
correctamente y Esto ocurre cuando
que cumple con los la definición de
requisitos, antes requerimientos del
de ser entregado al sistema es alterada
usuario final. en la sub−fase de
*Implantación: Es evaluación. El
la fase en donde el desarrollador
usuario final entonces debe
ejecuta el sistema. modificar el
*Mantenimiento: prototipo de
Una de las etapas acuerdo a los
más críticas, ya comentarios
que se destina un hechos por los
75% de los usuarios.
recursos, es el *Término: Una vez
mantenimiento del que se ha
Software ya que al desarrollado un
utilizarlo como prototipo estable y
usuario final puede completo, es
ser que no cumpla necesario ponerse
con todas nuestras de acuerdo en
expectativas. relación a aspectos
de calidad y de
representación del
sistema.

30
Actividades Sugiere un Las actividades de Se define las Permite que todo
enfoque este modelo se distintas fases el sistema, o
sistemático, conforman en una intermedias que se algunos de sus
secuencial hacia el espiral, en la que requieren para partes, se
desarrollo del cada bucle o validar el construyan
software, que se iteración desarrollo de rápidamente para
inicia con la representa un aplicación, es comprender con
especificación de conjunto de decir, para facilidad y aclarar
requerimientos del actividades. Las garantizar que el ciertos aspectos en
cliente y que actividades no los que se
continúa con la están fijadas a aseguren que el
planeación, el ninguna prioridad, usuario este de
modelado, la sino que las
construcción y el siguientes se eligen
despliegue para en función del
culminar en el análisis de riesgo,
soporte del
software
terminado.
Ventajas * No hace falta * La adaptabilidad *Específica bien los *Permite la
mencionar, es un en el diseño del roles de los construcción del
modelo lineal y, modelo de espiral distintos tipos de sistema con
por supuesto, los en la ingeniería de pruebas a realizar. requisitos poco
modelos lineales software se adapta *Hace explícito claros o
son las más a cualquier parte de la cambiantes.
simples a ser número de iteración y trabajo *El cliente recibe
implementadas. cambios, que que hay que una versión del
* La cantidad de pueden ocurrir realizar. sistema en muy
recursos durante cualquier *Este método poco tiempo, por
necesarios para fase del proyecto. involucra chequeos lo que lo puede
implementar este * Dado que la de cada una de las evaluar, probar e,
modelo es mínimo. construcción de etapas del método incluso, empezar a
* Una gran ventaja prototipos se Cascada. utilizarlo
del modelo de realiza en *Es un método *Se pueden
cascada es que la pequeños más robusto y introducir cambios
documentación se fragmentos o completo que el en las
produce en cada trozos, estimación método cascada y funcionalidades del
etapa del de costos se produce software sistema en
desarrollo del convierte en fácil y de mayor calidad cualquier
modelo de el cliente puede que con el modelo momento
cascada. obtener el control cascada. *Involucra al
* Después de cada sobre la *Es un modelo usuario en la
etapa importante administración del sencillo de y de evaluación de la
de la codificación nuevo sistema. fácil aprendizaje. interfaz de usuario
de software, las *Involucra al *Permite entender
pruebas se realizan usuario en las bien el problema
para comprobar el pruebas. antes de la
correcto implementación
funcionamiento final
del código.
Desventajas *La mayor * Los modelos en *Es difícil que el *El cliente puede

31
desventaja del espiral funcionan cliente exponga quedar convencido
modelo de cascada mejor para los explícitamente con las primeras
es uno de sus grandes proyectos todos los versiones y, quizás,
mayores ventajas. solamente, donde requisitos. no vea la
No se puede volver los costos son *El cliente debe necesidad de
atrás, si la fase de mucho más altos y tener paciencia, ya completar el
diseño ha ido mal, los requisitos del que obtendrá el sistema o
las cosas pueden sistema de pre producto al final rediseñarlo con la
ser muy implica un mayor del ciclo de vida. calidad necesaria
complicado en la nivel de *El modelo no *Requiere trabajo
fase de ejecución. complejidad. contempla la del cliente para
* Los pequeños * La evaluación de posibilidad de evaluar los
cambios o errores los riesgos retornar etapas distintos
que surgen en el involucrados en el inmediatamente prototipos y
software completo proyecto pueden anteriores, cosa traducirlo en
puede causar disparar el costo y que en la realidad nuevos requisitos
mucho problema. puede ser mayor puede ocurrir. *Requiere un
* La mayor que el costo de la *Se pierde dinero, tiempo adicional
desventaja del construcción del ya que si algún para definir
modelo de cascada sistema. proceso fue mal adecuadamente el
es que hasta la * Los modelos en desarrollado, este sistema
etapa final del ciclo espiral trabajan en debe ser revisado *No se sabe
de desarrollo se ha un protocolo, que de nuevo, lo que exactamente
completado, un debe ser seguido puede traer como cuánto será el
modelo de trabajo estrictamente para consecuencia un tiempo de
del software no su buen "RollBack" de todo desarrollo ni
está en las manos funcionamiento. un proceso. cuantos prototipos
del cliente. Por lo *Las pruebas se tienen que
tanto, es difícil en pueden ser caras y desarrollar
condiciones de a veces no lo *Si un prototipo
mencionar si lo suficientemente fracasa, el coste
que se ha diseñado efectivas. del proyecto puede
es exactamente lo resultar muy caro.
que había pedido.

32