Nombres:

Apellidos:

Matricula:

Asignatura:
Ingeniería de Software I

Facilitadora:
 Introducción

En la siguiente asignación, después de haber leído y analizado el contenido de la

unidad II del libro “Ingeniería de Software”, estaremos danto respuesta de
manera resumida a conceptos sumamente importante a entender como parte de
los objetivos de la asignatura.

Para dar respuesta a los conceptos a continuación expuestos; se procedió primero

a dar lectura de la unidad, para después con ayuda del libro e internet dar
respuestas propias, conceptualizando a partir de mi propio entendimiento. Esto
para denotar cual fue mi entendimiento de los temas.
Investigar en la web acerca de la estructura de los procesos y modelos
de ciclos de vida del software.

Define, explica y da ejemplo de los siguientes temas:

1. Proceso.
2. Característica de los procesos.
3. Lenguaje para la especificación de procesos.
4. Modelos de ciclo vida del software.
5. Modelo en cascada.
6. Modelo en V
7. Modelo de prototipo.
8. Modelo en espiral.

Desarrollo de cada punto señalado por su numeración en esta lista se

podrán apreciar a partir de la página siguiente.
 1. Proceso

Para empezar, definamos en pocas palabras lo que es un proceso; Esto no es más

que un conjunto de instrucciones que serán ejecutadas con un fin definido. De
manera resumida esto sería lo que entendemos como Proceso, pero a que se
quieren referir en este caso con “Proceso”, pues hacen referencia a “Proceso para
el desarrollo de software”, también denominado ciclo de vida del desarrollo de
software, es una estructura aplicada al desarrollo de un producto de software.

Proceso de software
La meta de la ingeniería de software es construir productos de software, o
mejorar los existentes; en ingeniería de procesos, la meta es desarrollar o mejorar
procesos.
Un proceso de desarrollo de software es un conjunto de personas, estructuras de
organización, reglas, políticas, actividades y sus procedimientos, componentes de
software, metodologías, y herramientas utilizadas o creadas específicamente para
definir, desarrollar, ofrecer un servicio, innovar y extender un producto de
software.
Un proceso de software efectivo habilita a la organización a incrementar su
productividad al desarrollar software:

 Permite estandarizar esfuerzos, promover re-uso, repetición y consistencia

entre proyectos.
 Provee la oportunidad de introducir mejores prácticas de la industria.
 Permite entender que las herramientas deben ser utilizadas para soportar
un proceso.
 Establece la base para una mayor consistencia y mejoras futuras.

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

 Define cómo manejar los cambios y liberaciones a sistemas de software

existentes.
 Define cómo lograr la transición del software a la operación, y cómo
ejecutar los esfuerzos de operación y soporte.
Necesitamos un proceso de software cuya funcionalidad esté probada en la
práctica, y personalizado para que cumpla con nuestras necesidades específicas.

2. Característica de los procesos

Características de los procesos

Podemos hablar de proceso si se cumplen las siguientes características:

• Se pueden describir entradas y salidas.

• El proceso afecta a varios límites organizativos funcionales.

• Es capaz de cruzar vertical y horizontalmente la organización.

Se trata de una de las características principales del proceso.

• Se habla de metas y fines en lugar de acciones y medios, es decir, el proceso

responde al “¿qué?”, no al “¿cómo?”.

• El proceso debe ser fácilmente comprensible por cualquier persona de la

organización.

• El nombre que se asigne al proceso debe ser representativo de los conceptos y

actividades incluidos en el mismo.

Dos características esenciales de todo proceso son:

Variabilidad del proceso

Cada vez que se repite el proceso hay ligeras variaciones en la secuencia de

actividades realizadas que, a su vez, generan variabilidad en los resultados del
mismo expresados a través de mediciones concretas.

Continuando con el ejemplo de la mesa de la entrada Concepto de proceso ISO

9001:2015, cada vez que se corta un listón de madera para las patas de la mesa,
la longitud varía ligeramente. La variabilidad en este caso estaría relacionada con
el porcentaje de listones cortados fuera de tolerancia.

La variabilidad repercute en el destinatario del proceso, quien puede quedar más

o menos satisfecho con lo que recibe del proceso.

Las personas que realizan el proceso cuentan con una herramienta específica, el
Gráfico de Control:

Cada punto del gráfico representa una medición de la característica del proceso:

• En la línea horizontal (línea de abscisas) se representa el número de la medición

(observación realizada).

• En la línea vertical (línea de ordenadas) se representa la escala de medición

elegida para la característica que se trata de graficar.

• Las líneas horizontales que marcan los límites de variabilidad del proceso. En
todo proceso hay que trabajar para que los resultados estén dentro de los límites
de variabilidad establecidos.

• La variabilidad fuera de límites supone rechazo de los resultados del proceso.

Repetitividad del proceso

Como elemento clave para su mejora. Los procesos se crean para producir un
resultado y repetir ese resultado.

Esta característica de repetitividad permite trabajar sobre el proceso y mejorarlo:

• Cuantas más repeticiones más experiencia.

• Merece la pena invertir tiempo en mejorar el proceso, ya que los resultados se

van a multiplicar por el número de veces que se repite el proceso.

Al conjunto de actividades que, dentro de una organización, pretenden conseguir

que las secuencias de actividades cumplan lo

que esperan los destinatarios de las mismas y además sean mejoradas se le llama
gestión y mejora de procesos.

Cada uno de los procesos debe tener un responsable asignado, cuya función
estribe en comprobar que se cumple la metodología definida para la realización
del mismo y que los resultados obtenidos coincidan con los esperados.

Los procesos deben satisfacer el ciclo PDCA, también conocido como círculo de
Deming.Gestión de la Calidad
 3. Lenguaje para la especificación de procesos.

Lenguaje de especificación

En el contexto de la ingeniería eléctrica, la computación y ramas afines, un

lenguaje de especificación o lenguaje de descripción es un lenguaje formal o
semiformal cuya función es construir modelos de los sistemas que se desea
elaborar.

A diferencia de los lenguajes de programación, que son lenguajes interpretables

o traducibles por una computadora hacia una representación ejecutable, los
lenguajes de especificación no son, por lo general, utilizados para implementar el
sistema, sino para especificarlo, conceptualizarlo o incluso validarlo, aunque
también suelen ser legibles para un programa de computadora, que puede asistir
en el proceso de validación.

Lenguaje de especificación de procesos PSL

El Lenguaje de Especificación de Procesos (PSL) es una ontología desarrollada en

el National Institute of Standards and Technology (NIST) para la descripción de los
procesos básicos de producción, de la ingeniería y del negocio.

PSL está publicado en el Estándar Internacional 18629 de la Organización de

Estándares Internacionales (ISO), en donde se incluye la semántica para describir
los conceptos fundamentales de los procesos de producción.

PSL define una representación neutral que está orientado al dominio de los
procesos de producción, es decir, aquellos procesos cuyos productos son
materiales.
Objetivos de PSL

 El objetivo de PSL es crear una representación de procesos que sea común a

todas las aplicaciones de producción, genérica y robusta para representar la
información necesaria del proceso para alguna aplicación dada.

 Adicionalmente, PSL pretende facilitar la interoperabilidad entre las

aplicaciones para referirse, con esto, al desarrollo de traductores entre
formatos nativos u otras aplicaciones y PSL.

 Por otra parte, en cuanto al proceso de producción, el objetivo de PSL es servir

como interlengua para integrar varios procesos relacionados (planeamiento de
producción incluyendo, la planeación del proceso, la gerencia del workflow y la
gerencia del proyecto) a través del ciclo de vida de este proceso de
producción.

Ejemplo de PSL

En primer lugar, se deben declarar los recursos.

Instancias de las clases que pueden ser declaradas. Los puntos de tiempo son
creados para hacer posible la creación de una secuencia de actividades.
Luego, las actividades y sub actividades son especificadas.

Las actividades son asignadas a un periodo de tiempo que permiten a cada

actividad estar relacionadas en una secuencia de secuencias.
 4. Modelos de ciclo vida del software.

La ingeniería del software se vale de una serie de modelos que establecen y

muestran las distintas etapas y estados por los que pasa un producto software,
desde su concepción inicial, pasando por su desarrollo, puesta en marcha y
posterior mantenimiento, hasta la retirada del producto. A estos modelos se les
denomina “Modelos de ciclo de vida del software”. El primer modelo concebido
fue el de Royce, más comúnmente conocido como “Cascada” o “Lineal
Secuencial”. Este modelo establece que las diversas actividades que se van
realizando al desarrollar un producto software, se suceden de forma lineal.

Los modelos de ciclo de vida del software describen las fases del ciclo de software
y el orden en que se ejecutan las fases.
Un modelo de ciclo de vida de software es una vista de las actividades que
ocurren durante el desarrollo de software, intenta determinar el orden de las
etapas involucradas y los criterios de transición asociados entre estas etapas. Un
modelo de ciclo de vida del software:

 Describe las fases principales de desarrollo de software. • Define las fases

primarias esperadas de ser ejecutadas durante esas fases. • Ayuda a
administrar el progreso del desarrollo. • Provee un espacio de trabajo para la
definición de un proceso detallado de desarrollo de software.
 Las principales diferencias entre distintos modelos de ciclo de vida están en:

 El alcance del ciclo dependiendo de hasta dónde llegue el proyecto

correspondiente. Un proyecto puede comprender un simple estudio de
viabilidad del desarrollo de un producto, o su desarrollo completo o en el
extremo, toda la historia del producto con su desarrollo, fabricación y
modificaciones posteriores hasta su retirada del mercado.

 Las características (contenidos) de las fases en que dividen el ciclo. Esto puede
depender del propio tema al que se refiere el proyecto, o de la organización.

 La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si

tenemos libertad de repetirlas (iterar).
 5. Modelo en cascada

Es un enfoque metodológico que ordena rigurosamente las etapas del ciclo de

vida del software, de forma que el inicio de cada etapa debe esperar a la
finalización de la inmediatamente anterior.

El modelo en cascada es un proceso de desarrollo secuencial, en el que el

desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que
componen el ciclo de vida.

La primera descripción formal del modelo en cascada se cree que fue en un

artículo publicado en 1970 por Winston W. Royce, aunque Royce no usó el
término cascada en este artículo. Irónicamente, Royce estaba presentando este
modelo como un ejemplo de modelo que no funcionaba, defectuoso. En el
modelo original de Royce, existían las siguientes fases:
1.Especificación de requisitos.

2.Diseño.

3.Construcción (Implementación o codificación).

4.Integración.

5.Pruebas.

6.Instalación.

7.Mantenimiento.

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una

forma puramente secuencial.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria,

sigue siendo el paradigma más seguido a día de hoy.
 6. Modelo en V

El modelo en v se desarrolló para terminar con algunos de los problemas que se

vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo
encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se
introducían hasta el final del proyecto. El modelo en v dice que las pruebas
necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra
que las pruebas no son sólo una actividad basada en la ejecución. Hay una
variedad de actividades que se han de realizar antes del fin de la fase de
codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las
actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con los
desarrolladores y analistas de negocio de tal forma que puedan realizar estas
actividades y tareas y producir una serie de entregables de pruebas.
El modelo en v es un proceso que representa la secuencia de pasos en el
desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados
que han de ser producidos durante el desarrollo del producto. La parte izquierda
de la v representa la descomposición de los requisitos y la creación de las
especificaciones del sistema. El lado derecho de la v representa la integración de
partes y su verificación. V significa “Validación y Verificación”.
Realmente las etapas individuales del proceso pueden ser casi las mismas que las
del modelo en cascada. Sin embargo, hay una gran diferencia. En vez de ir para
abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de
codificación, formando una v. La razón de esto es que para cada una de las fases
de diseño se ha encontrado que hay un homólogo en las fases de pruebas que se
correlacionan.
 7. Modelo de prototipo

Modelo de Prototipos. También conocido como desarrollo con prototipación o

modelo de desarrollo evolutivo, se inicia con la definición de los objetivos globales
para el software, luego se identifican los requisitos conocidos y las áreas del
esquema en donde es necesaria más definición. Este modelo se utiliza para dar al
usuario una vista preliminar de parte del software. Este modelo es básicamente
prueba y error ya que si al usuario no le gusta una parte del prototipo significa
que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el
usuario quede satisfecho. Además, el prototipo debe ser construido en poco
tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues
a partir de que este sea aprobado nosotros podemos iniciar el verdadero
desarrollo del software. Pero eso si al construir el prototipo nos asegura que
nuestro software sea de mejor calidad, además de que su interfaz sea de agrado
para el usuario. Un prototipo podrá ser construido solo si con el software es
posible experimentar.
Etapas

 Recolección y refinamiento de requisitos

 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, evaluación del prototipo por el cliente
 Refinamiento del prototipo
 Producto de Ingeniería

Ventajas

No modifica el flujo del ciclo de vida

Reduce el riesgo de construir productos que no satisfagan las necesidades de los
usuarios
Reduce costo y aumenta la probabilidad de éxito
Exige disponer de las herramientas adecuadas
Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
También ofrece un mejor enfoque cuando el responsable del desarrollo del
software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debería tomar la interacción humano-
máquina.

8. Modelo en espiral

El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry

Boehm en 1985, utilizado de forma generalizada en la ingeniería del software. Las
actividades de este modelo se conforman en una espiral, cada bucle representa
un conjunto de actividades. Las actividades no están fijadas a priori, sino que las
siguientes se eligen en función del análisis de riesgos, comenzando por el bucle
anterior.

Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno
de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique
tenga la necesaria experiencia y habilidad para detectar y catalogar
correctamente riesgos.

Para cada ciclo habrá cuatro actividades:

1. Determinar o fijar objetivos:

• Fijar también los productos definidos a obtener: requerimientos, especificación,

manual de usuario.

• Fijar las restricciones.

• Identificar riesgos del proyecto y estrategias alternativas para evitarlos.

• Hay una cosa que solo se hace una vez: planificación inicial o previa

2. Análisis del riesgo:

• Estudiar todos los riesgos potenciales y se seleccionan una o varias alternativas

propuestas para reducir o eliminar los riesgos

3. Desarrollar, verificar y validar (probar):

• Tareas de la actividad propia y de prueba.

• Análisis de alternativas e identificación de resolución de riesgos.

• Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para

el desarrollo, que puede ser cualquiera de los otros existentes, como formal,
evolutivo, cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario
son dominantes, un modelo de desarrollo apropiado podría ser la construcción de
prototipos evolutivos.

4. Planificar:

• Revisar todo lo que se ha llevado a cabo, evaluándolo y decidiendo si se

continua con las fases siguientes y planificando la próxima actividad.
El proceso empieza en la posición central. Desde allí se mueve en el sentido de las
agujas del reloj.

Bibliografía
.alarcos.inf-cr.uclm.es/. (s.f.). Obtenido de
http://www.alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf alarcos

cflores334.blogspot.es. (s.f.). Obtenido de http://www.cflores334.blogspot.es/1192848180/ cflores334

efectodigital. (23 de 04 de 2018). Obtenido de https://www.efectodigital.online/:

https://www.efectodigital.online/single-post/2018/04/23/ciclo-de-vida-de-desarrollo-de-
software

gestion-calidad.com. (29 de 09 de 2016). Obtenido de https://gestion-calidad.com/caracteristicas-y-

tipologia-general-de-los-procesos#:~:text=Podemos%20hablar%20de%20proceso%20si%20se
%20cumplen%20las%20siguientes%20caracter%C3%ADsticas%3A&text=Se%20pueden
%20describir%20entradas%20y%20salidas.&text=El%20proce

info2.es.tl. (s.f.). Obtenido de https://info2.es.tl/LENGUAJE-DE-ESPECIFICACI%D3N.htm

Ruvalcaba, M. (s.f.). sg.com.mx. Obtenido de https://sg.com.mx/revista/1/procesos-software

wikipedia.org. (s.f.). Obtenido de http://www.es.wikipedia.org/wiki/Modelo_de_prototipos wikipedia

www.ecured.cu. (s.f.). Obtenido de https://www.ecured.cu/index.php?

title=Modelo_de_prototipos&action=edit

www.sidar.org. (s.f.). Obtenido de

http://www.sidar.org/recur/desdi/traduc/es/visitable/tecnicas/Prototyping.htm sidar