Instituto Tecnológico Superior De Ciudad Hidalgo

Carrera: Ingeniería en Sistemas Computacionales.

Materia: Verificación y Validación de Software

Nombre de la práctica: Investigación

Grupo: 078CA

Integrantes:
Gonzalo Ballesteros Martínez.

Edgar Camacho Cruz.

Ignacio Luz Reyes.

Marisol García Pérez

Nombre del profesor(a): I.S.C Mariela Chávez Marcial

Fecha de entrega: 19/02/2021

 Índice

Índice .............................................................................................................. 1
Introducción .................................................................................................... 2
Desarrollo ....................................................................................................... 3
Fases del proceso de desarrollo de software ............................................. 3
Análisis de requisitos ............................................................................... 3
Diseño y arquitectura............................................................................... 3
Programación .......................................................................................... 4
Pruebas ................................................................................................... 4
Documentación........................................................................................ 5
Mantenimiento ......................................................................................... 5
Metodología ................................................................................................ 6
Importancia ................................................................................................. 7
Modelos del Proceso de Desarrollo Software ............................................. 8
Modelo en cascada o convencional ........................................................ 9
Modelo evolutivo...................................................................................... 9
Modelo transformacional ....................................................................... 10
Modelo en espiral .................................................................................. 11
Conclusión .................................................................................................... 12
Fuentes ......................................................................................................... 13

1
 Introducción

Desarrollar un software significa construirlo simplemente mediante su

descripción. Está es una muy buena razón para considerar la actividad de
desarrollo de software como una ingeniería. En un nivel más general, la
relación existente entre un software y su entorno es clara ya que el software
es introducido en el mundo de modo de provocar ciertos efectos en el
mismo.

Aquellas partes del mundo que afectarán al software y que serán afectadas
por él será el Dominio de Aplicación. Es allí donde los usuarios o clientes
observarán si el desarrollo del software ha cumplido su propósito.

Una de las mayores deficiencias en la práctica de construcción de software

es la poca atención que se presta a la discusión del problema. En general
los desarrolladores se centran en la solución dejando el problema
inexplorado. El problema a resolver debe ser deducido a partir de su
solución.

Esta aproximación orientada a la solución puede funcionar en campos

donde todos los problemas son bien conocidos, clasificados e investigados,
donde la innovación se ve en la detección de nuevas soluciones a viejos
problemas.

2
 Desarrollo

Fases del proceso de desarrollo de software

Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para

crearlo. Mientras que los clientes piensan que ellos saben lo que el software
tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de
software para reconocer requisitos incompletos, ambiguos o contradictorios.
El resultado del análisis de requisitos con el cliente se plasma en el
documento ERS, Especificación de Requerimientos del Sistema, cuya
estructura puede venir definida por varios estándares, tales como CMM-I.
Asimismo, se define un diagrama de Entidad/Relación, en el que se
plasman las principales entidades que participarán en el desarrollo del
software. La captura, análisis y especificación de requisitos (incluso pruebas
de ellos), es una parte crucial; de esta etapa depende en gran medida el
logro de los objetivos finales. Se han ideado modelos y diversos procesos
de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de
la Ingeniería de Requisitos.

Diseño y arquitectura

Se refiere a determinar cómo funcionará de forma general sin entrar en

detalles. Consiste en incorporar consideraciones de la implementación
tecnológica, como el hardware, la red, etc. Se definen los casos de uso para
cubrir las funciones que realizará el sistema, y se transforman las entidades
definidas en el análisis de requisitos en clases de diseño, obteniendo un
modelo cercano a la programación orientada a objetos.

3
 Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de
ingeniería de software, pero no es necesariamente la porción más larga. La
complejidad y la duración de esta etapa está íntimamente ligada al o a los
lenguajes de programación utilizados.

Pruebas

Consiste en comprobar que el software realice correctamente las tareas

indicadas en la especificación. Una técnica de prueba es probar por
separado cada módulo del software, y luego probarlo de forma integral, para
así llegar al objetivo. Se considera una buena práctica el que las pruebas
sean efectuadas por alguien distinto al desarrollador que la programó,
idealmente un área de pruebas; sin perjuicio de lo anterior el programador
debe hacer sus propias pruebas. En general hay dos grandes formas de
organizar un área de pruebas, la primera es que esté compuesta por
personal inexperto y que desconozca el tema de pruebas, de esta forma se
evalúa que la documentación entregada sea de calidad, que los procesos
descritos son tan claros que cualquiera puede entenderlos y el software
hace las cosas tal y como están descritas. El segundo enfoque es tener un
área de pruebas conformada por programadores con experiencia, personas
que saben sin mayores indicaciones en qué condiciones puede fallar una
aplicación y que pueden poner atención en detalles que personal inexperto
no consideraría.

4
 Documentación

Todo lo concerniente a la documentación del propio desarrollo del software

y de la gestión del proyecto, pasando por modelaciones (UML), diagramas,
pruebas, manuales de usuario, manuales técnicos, etc; todo con el
propósito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y

nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo
inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene
que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste
en arreglar errores, o bugs. La mayor parte consiste en extender el sistema
para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la
Ingeniería civil, Arquitectura y trabajo de construcción es dar mantenimiento.

Se puede decir que con la mejora continua garantiza la calidad del producto,
ya que el estarla aplicando día con día es la mejor decisión que puede llegar
a tener cualquier empresa, porque de esta manera evita grandes problemas
en la elaboración o desarrollo de los productos. Esto es fundamental para
todas las empresas ya que se vuelven competitivas, con mayor
productividad y eficiencia. No hay que olvidar que la mejora se da porque el
cliente es el rey y hay que satisfacer todas y cada una de sus necesidades
siempre garantizando la calidad.

5
Metodología

Todo desarrollo de software es riesgoso y difícil de controlar, pero si no

llevamos una metodología de por medio, se obtiene clientes insatisfechos
con el resultado y desarrolladores aún más. Sin embargo, muchas veces no
se toma en cuenta el utilizar una metodología adecuada, sobre todo cuando
se trata de proyectos pequeños de dos o tres meses. Con relación a los
proyectos que se desarrollan con mayor envergadura, hay si se toma el
sentido de basarse en una metodología de desarrollo y se empieza a buscar
cuál sería la más apropiada para dicho caso. A fin de cuenta no
encontramos muchas veces la más adecuada y se termina por hacer un
diseño propio de metodología, por supuesto no está mal siempre y cuando
sirva para alcanzar el objetivo. Muchas veces se realiza el diseño del
software de manera rígida, tal como el cliente lo solicitó, de esa manera
cuando el cliente en la "etapa de prueba" solicita un cambio se hace muy
difícil de realizarlo, pues si se hace altera las cosas que no se habían
previsto, y este es uno de los factores que atrasan el proyecto y crea
incomodidad al desarrollador y en muchas oportunidades no llegan a
cumplir con el cambio solicitado, esto conlleva malestar en el cliente puesto
que no ha sido tomado en cuenta su pedido; para evitar estos incidentes se
debe llegar a un acuerdo formal con el cliente al inicio del proyecto de
manera que no perjudique el desarrollo del mismo. Muchas veces los
usuarios finales se dan cuenta que dejaron de mencionar algunas cosas y lo
manifiestan en la etapa inicial del proyecto cuando se le muestra el prototipo
del mismo.

6
 • La metodología RUP es la más adaptable para proyectos de largo
plazo.
• La metodología XP en cambio, se recomienda para proyectos de
corto plazo.
• La metodología MSF se adapta a proyectos de cualquier dimensión y
de cualquier tecnología.

Importancia

El software es el intermediario cada vez más grande entre la información y

la inteligencia humana. De la misma manera que preocupa para poder
acceder a la información, si existe la censura, es tema de preocupación de
quien controla este intermediario y las garantías de su transparencia y
confiabilidad. En principio, el software es un programa informático o
conjunto de ellos que tiene un fin determinado, es el de procesar los textos
que usamos, el controlador de grabación de nuestros espacios favoritos o
las aplicaciones que permiten operar un teléfono móvil. Está compuesto por
un conjunto de instrucciones que el usuario realiza para ejecutar una
función específica. Normalmente los programadores escriben en un
lenguaje en el que todos pueden entender y que después es traducido al
lenguaje binario el único que las máquinas entienden. El conjunto de
órdenes en el lenguaje que todos trabajan se llaman código fuente. Sino se
accede al código solo se puede usar el programa, no se puede ver cómo
está hecho o introducir comentarios. Un ejemplo muy utilizado es el de la
receta de cocina, en el que el código fuente son las instrucciones que
permite confeccionar un plato. Sin la receta solo se pude degustar el plato,
pero no se sabe si se le añade algo vaya en contra de algunos de esos
ingredientes ya que se desconocen su composición y proporción. En este
sentido, el código fuente juega un papel fundamental en la manera como se

7
debe entender el software. Los ordenadores de las empresas eléctricas,
centrales nucleares, sistema de control de aviación, bancos y en general,
todo el software de uso cotidiano, tuvieron que ser revisados. Finalmente,
algunas aplicaciones fueron corregidas, otras ya funcionaban correctamente
y no hubo que lamentar ninguna catástrofe, pero hubo miles de predicciones
apocalípticas sobre las consecuencias que se podría llegar a obtener este
error, así podría haber sido si no se hubiera reparado a tiempo.

Modelos del Proceso de Desarrollo Software

No existe consenso sobre cuál es el mejor modelo del proceso software.

Distintos equipos de desarrollo pueden utilizar diferentes modelos de
proceso software para producir el mismo tipo de sistema software. Sin
embargo, algunos modelos son más apropiados para producir ciertos tipos
de sistemas, de forma que si no se utiliza un modelo adecuado puede
ocurrir que el sistema software resultante sea de menor calidad.
El reparto de costes entre las distintas fases del proceso de desarrollo es
difícil de determinar dado los distintos modelos de proceso existentes. Sin
embargo, en dependencia del modelo que se adopte, al menos el 60% del
coste total se emplea en la actividad de evolución del sistema. La
estimación de este porcentaje es pesimista, ya que la tasa de crecimiento
de nuevos productos software es mucho mayor que la tasa de productos
software que quedan en desuso (no tienen que ser mantenidos), por lo que
el número de operaciones de mantenimiento que se realizan sigue
aumentando. El proceso de diseño software debería, por tanto, tener en
cuenta la posterior evolución del sistema.

8
 Modelo en cascada o convencional

Tomado de otras ingenierías es el primer modelo de desarrollo software

propuesto. Ampliamente usado en la industria por su facilidad de gestión y
visibilidad. Sin embargo, su principal problema reside en su poca flexibilidad
al separar el proceso de desarrollo en etapas totalmente distintas. En la
práctica estas etapas no tienen fronteras tan bien definidas, lo que hace
que, en no pocas ocasiones, se solapen y compartan información.
Los principales problemas de este modelo son: dificultad para realizar
prototipos, reutilizar software y realizar pruebas sin disponer de una
implementación del sistema.

Modelo evolutivo

En este modelo se entrelazan las actividades de especificación, desarrollo y

validación. Inicialmente, se desarrolla rápidamente un sistema inicial a partir
de una especificación muy abstracta. El sistema se va refinando con la
información que van suministrando los clientes y/o usuarios hasta que se
obtiene un sistema final que satisfaga todas las necesidades previstas. El
sistema final obtenido puede rediseñarse para producir otro más robusto y
más fácil de mantener, Existen dos tipos de procesos de desarrollo
evolutivos:

• Exploratorio: Su objetivo es trabajar con el cliente para identificar y

construir el sistema final a partir de una especificación informal. El
resultado del proceso es el sistema final.
Prototipado desechable: Su objetivo es entender los requisitos del

9
 cliente. El resultado del proceso es la especificación del sistema (el
prototipo se deshecha).
• Los principales problemas de este modelo son: escasa visibilidad; los
continuos cambios que hacen que los sistemas desarrollados estén
deficientemente estructurados; y la necesidad de disponer, en
muchos casos, de un equipo de desarrollo altamente calificado. Estos
problemas hacen que la aplicación de este modelo se suela limitar a
sistemas interactivos de tamaño pequeño o mediano. La deficiente
estructura dificulta las tareas de mantenimiento de ahí que se suela
aplicar a sistemas con una vida corta y a partes de grandes sistemas,
especialmente a sistemas de inteligencia artificial y a interfaces de
usuario.

Modelo transformacional

Se basa en disponer de una especificación formal del sistema y en

transformar, con métodos matemáticos, esta especificación en una
implementación. Si las transformaciones que se aplican son correctas es
posible asegurar que el sistema construido satisface la especificación, es
decir, es posible obtener programas correctos por construcción. Otra de sus
ventajas es la posibilidad de realizar el mantenimiento a nivel de
especificación. Por lo que es necesario disponer de una especificación
inicial correcta y de diseñadores altamente calificados. Además no existe
apenas experiencia en la aplicación de este modelo a grandes proyectos.
Modelo basado en reutilización: En este modelo se supone que alguno de
los componentes del sistema final ya existe. El proceso de desarrollo se
centra en integrar las partes ya existentes más que en construir todo el
sistema desde el principio. Las ventajas que desde un punto de vista

10
económico puede producir este modelo actualmente empiezan a ser
estudiadas en profundidad. Prácticamente no existe experiencia sobre el
empleo de este modelo, si bien, se están haciendo numerosos estudios e
investigaciones para posibilitar su uso.

Modelo en espiral

Desarrollado por Boehm en el año 1988 con el objetivo de reunir las

ventajas de los modelos de proceso software en cascada y de prototipado.
Se incluye el análisis de riesgo como una parte importante del proceso de
desarrollo software. El modelo tiene la forma de una espiral en la que cada
vuelta representa cada una de las fases en las que se estructura el proceso
software y está organizada en cuatro sectores:

1. Definición de objetivos, alternativas y restricciones de cada fase del

proyecto.

2. Evaluación de alternativas y análisis de riesgos.

3. Desarrollo y validación. Se elige el modelo de proceso de desarrollo

que se considere más adecuado.

4. Planificación de las siguientes fases del proyecto.

11
 Conclusión

Los diagramas y la forma de cómo son representados los distintos

procesos para el desarrollo de software de un sistema, es una forma más
clara de saber cómo será los distintos métodos o interacciones que debe
conocer un analista o programador para poder tener un sistema robusto,
preciso y que pueda estar al tanto de las necesidades del cliente al
momento se ser elaborado con los mínimos requerimientos de software y
que el cliente pueda trabajar con su sistema terminado al cabo de todo el
proceso que se podrá sistematizar y tener más control de la información que
se obtendrá o que será capaz de ser guarda con seguridad para tanto los
clientes como de sus jefes.

En esta etapa es la que se ve claramente si es o no viable el sistema

después de las diversas etapas que se realizaron anteriormente y se pueda
implementar en el negocio para el cual está elaborado, así como la de
análisis también es importante esta etapa ya que aquí es donde se ve la
parte de la creación de las interfaces del sistema o los diseños que se
llevaran para que el cliente tenga un ambiente amigable o que no sea
complejo al momento de ser usado por alguno de ellos.

Todo bajo el estándar de UML que usa como diagramas cada uno y que son
basados en objetos o también se pueden orientar a objetos como lo es la
programación.

Destacando que además de ser algo complementario para la programación

es una de las actividades en las cuales se lleva más tiempo y que ayuda a
elaborar distintos documentos, manuales o datos técnicos que serán de
gran ayuda para el cliente o el desarrollador de software que pueda cumplir
con las reglas para la creación de un software o la de conocer qué tipo de

12
equipos se tendrán que utilizar para poder ejecutar con facilidad el sistema
terminado y conocer como es el proceso interno aunque el cliente no tendrá
que conocer todo a fondo.

Fuentes

fing. (17 de 02 de 2021). fing. Obtenido de

https://www.fing.edu.uy/inco/cursos/ingsoft/pis/proceso/MUM/dat/intro/
intro.htm

monigrafias. (03 de 02 de 2021). monigrafias. Obtenido de

https://www.monografias.com/trabajos39/desarrollo-del-
software/desarrollo-del-software.shtml

Ruvalcaba, M. (17 de 02 de 2021). sg. Obtenido de

https://sg.com.mx/revista/1/procesos-software

Salim, C. L. (25 de 03 de 2013). TECNOLÓGICO DE ESTUDIOS

SUPERIORES DE ECATEPEC. Obtenido de http://isc-
dps.blogspot.com/

13