PROCESOS DE
SOFTWARE
OBJETIVOS
● Objetivo principal: introducir la idea de un proceso de software, que es
un conjunto coherente de actividades para la producción de software.
● Comprenderá los conceptos y modelos sobre procesos de software.
● Se introducirá en los tres modelos de proceso de software genérico y
sabrá cuándo usarlos.
● Entenderá las principales actividades del proceso de ingeniería de
requerimientos de software, así como del desarrollo, las pruebas y
evolución del software.
● Comprenderé por qué deben organizarse los procesos para enfrentar los
cambios en los requerimientos y el diseño de software.
● Entenderá cómo el Proceso Unificado Racional (Rational Unified
Process, RUP) integra buenas prácticas de ingenieria de software para
crear procesos de software adaptables.
2
Contenido
•2.1 Modelos de proceso de software
•2.2 Actividades del proceso
•2.3 Cómo enfrentar el cambio
•2.4 El Proceso Unificado Racional
3
Un proceso de software es una serie de actividades relacionadas que
conduce a la elaboración de un producto de software.
Las cuatro actividades que son fundamentales para la ingeniería de
software:
1. Especificación del software: Tienen que definirse tanto la
funcionalidad del software como las restricciones de su operación.
2. Desarrollo e implementación del software: Debe desarrollarse el
software para cumplir con las especificaciones.
3. Validación del software: Hay que validar el software para asegurarse
de que cumple lo que el cliente quiere.
4. Evolución del software: El software tiene que evolucionar para
satisfacer las necesidades cambiantes del cliente.
4
Las descripciones de los procesos deben incluir:
1. Productos, que son los resultados de una actividad del proceso.
2. Roles, que reflejan las responsabilidades de la gente que interviene
en el proceso.
3. Precondiciones y postcondiciones, que son declaraciones válidas
antes y después de que se realice una actividad del proceso o se cree
un producto.
5
2.1 Modelos de proceso de software
“
Un modelo de proceso de software es una representación simplificada de este
proceso. Cada modelo del proceso representa a otro desde una particular
perspectiva y, por lo tanto, ofrece sólo información parcial acerca de dicho proceso..
Los modelos del proceso que se examinan aquí son:
1. El modelo en cascada: Éste toma las actividades fundamentales del proceso de
especificación, desarrollo, validación y evolución
2. Desarrollo incremental: Este enfoque vincula las actividades de especificación,
desarrollo y validación.
3. Ingeniería de software orientada a la reutilización: Este enfoque se basa en la
existencia de un número significativo de componentes
6 reutilizables.
1 El modelo en cascada
El modelo en cascada es consecuente con otros modelos del proceso
de ingeniería y en cada fase se produce documentación. Esto hace que
el proceso sea visible, de modo que los administradores monitoricen el
progreso contra el plan de desarrollo.
7
Las principales etapas del modelo en cascada reflejan directamente las actividades
fundamentales del desarrollo:
1. Análisis y definición de requerimientos: Los servicios, las restricciones y las metas
del sistema se establecen mediante consulta a los usuarios del sistema.
2. Diseño del sistema y del software: El proceso de diseño de sistemas asigna los
requerimientos, para sistemas de hardware o de software, al establecer una
arquitectura de sistema global.
3. Implementación y prueba de unidad: Durante esta etapa, el diseño de software se
realiza como un conjunto de programas o unidades del programa.
4. Integración y prueba de sistema: Las unidades del programa o los programas
individuales se integran y prueban como un sistema completo para asegurarse de que
se cumplan los requerimientos de software.
5. Operación y mantenimiento: Por lo general (aunque no necesariamente), esta es la
fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica.
8
Ingeniería de software de cuarto limpio
Un ejemplo del proceso de desarrollo formal, diseñado originalmente por
IBM, es el proceso de cuarto limpio (cleanroom). En el proceso de
cuarto limpio, cada incremento de software se especifica formalmente y
tal especificación se transforma en una implementación. La exactitud del
software se demuestra mediante un enfoque formal.
9
2 Desarrollo incremental
El desarrollo incremental se basa en la idea de diseñar una
implementación inicial, exponer ésta al comentario del
usuario, y luego desarrollarla en sus diversas versiones hasta
producir un sistema adecuado.
10
Comparado con el modelo en cascada, el desarrollo incremental
tiene tres beneficios importantes:
1. Se reduce el costo de adaptar los requerimientos cambiantes del
cliente.
2. Es más sencillo obtener retroalimentación del cliente sobre el
trabajo de desarrollo que se realizó.
3. Es posible que sea más rápida la entrega e implementación de
software útil al cliente, aun si no se ha incluido toda la funcionalidad.
Desde una perspectiva administrativa, el enfoque incremental
tiene dos problemas:
1. El proceso no es visible.
2. La estructura del sistema tiende a degradarse conforme se tienen
nuevos incrementos.
11
Problemas con el desarrollo incremental
Aunque el desarrollo incremental tiene muchas ventajas, no está exento
de problemas. La principal causa de la dificultad es el hecho de que las
grandes organizaciones tienen procedimientos burocráticos que han
evolucionado con el tiempo y pueden suscitar falta de coordinación entre
dichos procedimientos y un proceso iterativo o ágil más informal.
12
3. Ingeniería de software orientada a la reutilización
Sucede con frecuencia de manera informal, cuando las personas
que trabajan en el proyecto conocen diseños o códigos que son
similares a lo que se requiere.
13
Aunque la etapa inicial de especificación de requerimientos y la etapa de
validación se comparan con otros procesos de software en un proceso
orientado a la reutilización, las etapas intermedias son diferentes. Dichas
etapas son:
1. Análisis de componentes: Dada la especificación de requerimientos, se
realiza una búsqueda de componentes para implementar dicha
especificación.
2. Modificación de requerimientos: Durante esta etapa se analizan los
requerimientos usando información de los componentes descubiertos.
3. Diseño de sistema con reutilización: Durante esta fase se diseña el marco
conceptual del sistema o se reutiliza un marco conceptual existente.
4. Desarrollo e integración: Se diseña el software que no puede procurarse
de manera externa, y se integran los componentes y los sistemas COTS
para crear el nuevo sistema.
14
Existen tres tipos de componentes de software que pueden usarse en un
proceso orientado a la reutilización:
1. Servicios Web que se desarrollan en concordancia para atender servicios estándares
y que están disponibles para la invocación remota.
2. Colecciones de objetos que se desarrollan como un paquete para su integración con
un marco de componentes como .NET o J2EE.
3. Sistemas de software independientes que se configuran para usar en un entorno
particular.
15
Herramientas de Desarrollo
Son programas usados para apoyar las actividades del proceso de la ingeniería de software
como editores de diseño, diccionarios de datos, compiladores, etc.
Apoyan al automatizar actividades como:
● Desarrollo de modelos de sistemas gráficos como especificación de requerimientos o
diseño.
● Generación de código a partir de dichos modelos de sistemas gráficos.
● Producción de interfaces de usuario a partir de una descripción de interfaz gráfica.
● Depuración del programa mediante el suministro de información sobre un programa
que se ejecuta.
● Traducción automatizada de programas escritos, usando una versión anterior de un
lenguaje para tener una versión más reciente.
Las herramientas pueden combinarse en un marco llamado ambiente de desarrollo
interactivo o IDE (Interactive Development Environment). Esto ofrece un conjunto común de
facilidades, que usan las herramientas para comunicarse y operar con mayor destreza en una
forma integrada.
16
2.2 ACTIVIDADES DEL PROCESO
Los procesos de software real son secuencias
entrelazadas de actividades técnicas, colaborativas y
administrativas con la meta general de especificar,
diseñar, implementar y probar un sistema de
software.
El proceso tiene como actividades básicas:
1. Especificación de software
2. Desarrollo e implementación de Software
3. Validación de Software
4. Evolución de Software
17
1. ESPECIFICACIÓN DE SOFTWARE
También conocida como ingeniería de
requerimientos es el proceso de comprender y
definir qué servicios requiere el sistema, resultando
en un documento de requerimientos con dos
niveles de detalle: para usuarios finales y para
desarrolladores.
18
1. ESPECIFICACIÓN DE SOFTWARE
Esta actividad también resulta en otras cuatro actividades:
● Estudio de factibilidad: Se realiza una estimación sobre las necesidades identificadas del usuario
y si las tecnologías actuales (hardware y software) las cubren.
● Obtención y análisis de requerimientos: Este proceso deriva los requerimientos del sistema
basándose en los sistemas existentes, discusiones con usuarios, proveedores potenciales,
análisis de tareas, etc.
● Especificación de requerimientos: Se transcribe la información recopilada durante la actividad
de análisis en un documento de requerimientos. Y hay dos niveles de requerimientos:
○ Requerimientos del usuario: son informes abstractos de requerimientos para el cliente y el
usuario final del sistema.
○ Requerimientos del sistema: descripción detallada de la funcionalidad a ofrecer.
● Validación de requerimientos: Se verifica que los requerimientos sean realistas, coherentes y
completos.
19
1. ESPECIFICACIÓN DE SOFTWARE
Este proceso no sigue un orden estricto, de hecho el análisis y la especificación de
requerimientos están estrechamente vinculadas en la ingeniería de requerimientos.
20
2. DESARROLLO E IMPLEMENTACIÓN
Aquí corresponde el proceso de convertir una
especificación en un sistema ejecutable.
El diseño de software es una descripción de los
modelos y estructuras de datos, interfaces e incluso
algoritmos usados. Los diseñadores trabajan de
manera iterativa con ayuda del backtracking (vuelta
atrás) para corregir diseños anteriores.
Las actividades en este proceso varían dependiendo
del tipo de sistema a desarrollar.
Para sistemas críticos, deben producirse documentos
de diseño detallados que establezcan descripciones
exactas del sistema.
21
2. DESARROLLO E IMPLEMENTACIÓN
Un modelo general de diseño de software tiene cuatro actividades principales:
● Diseño arquitectónico: Identifica la estructura global del sistema, los principales
componentes (subsistemas o módulos), sus relaciones y cómo se distribuyen.
● Diseño de interfaz: Se definen las interfaces entre los componentes del sistema,
los componentes se diseñan y desarrollan de manera concurrente.
● Diseño de componentes: Se toma cada componente del sistema y se diseña como
funcionará. Puede ser un simple dato de la funcionalidad que se espera
implementar y al programador se le deja el diseño específico. Si se reutiliza un
componente se haría una lista de cambios a realizar.
● Diseño de base de datos: Se diseñan las estructuras del sistema de datos y como
se representarán en una base de datos. Este trabajo depende de si una base de
datos se reutilizará o se creará una nueva.
22
2. DESARROLLO E IMPLEMENTACIÓN
Modelo general del proceso de diseño
23
Métodos estructurados en el diseño
Los métodos estructurados son un enfoque al diseño de software
donde se definen los modelos gráficos que hay que desarrollar.
El método también define un proceso para diseñar los modelos y las
reglas que se aplican a cada tipo de modelo.
Los métodos estructurados conducen a documentación
estandarizada para un sistema y son muy útiles al ofrecer un marco
de desarrollo para los creadores de software con menor experiencia.
24
2. DESARROLLO E IMPLEMENTACIÓN
Las herramientas de desarrollo de software generan
un programa "esqueleto" a partir de un diseño,
incluyendo un código para definir e implementar
interfaces, así que el desarrollador solo necesita
detallar.
La programación es una actividad personal y no hay
un proceso de forma general.
En esta fase el programador suele depurar (debugging)
con pruebas del código como puede ser rastrear un
problema manualmente o crear casos de prueba.
25
3. VALIDACIÓN DE SOFTWARE
La validación y verificación del software (V&V) se crea para mostrar que
un sistema cumple con las especificaciones y expectativas del cliente.
La técnica principal para validar es haciendo pruebas con datos
simulados en base a tres etapas.
26
3. VALIDACIÓN DE SOFTWARE
1. Pruebas en el desarrollo: prueba de cada componente de manera independiente,
generalmente utilizando herramientas de automatización de pruebas.
2. Pruebas del sistema: se integran los componentes para crear un sistema completo y se
buscan errores en la interacción de estos y problemas de interfaz.
3. Pruebas de aceptación: Es la parte final de las pruebas y se usan datos suministrados por
el cliente en lugar de simulaciones.
Los procesos de desarrollo y pruebas de componentes están entrelazados ya que los
programadores construyen sus propios datos de prueba y experimentan en el código de manera
incremental. Este enfoque es sensible económicamente ya que el programador conoce el
componente y es el más indicado para generar casos de prueba.
27
3. VALIDACIÓN DE SOFTWARE
En ocasiones a las pruebas de aceptación se les identifica como “pruebas alfa”
y continúa hasta que el desarrollador del sistema y el cliente estén de acuerdo
en que el sistema entregado es una implementación aceptable de los
requerimientos.
Cuando un sistema se marca como producto de software se utiliza el proceso
de “prueba beta” que es entregar el sistema a algunos clientes potenciales que
estén de acuerdo para reportar los problemas a los desarrolladores.
28
4. EVOLUCIÓN DE SOFTWARE
Es muy costoso hacer cambios de diseño una vez fabricado el hardware pero respecto
al software se pueden hacer cambios en el software, siendo más barato que un
cambio de hardware.
Los costos de mantenimiento son varias veces el costo de desarrollo pero sus
procesos son menos desafiantes.
La ingeniería de software se debe ver como un proceso evolutivo ya los
requerimientos y necesidades del cliente cambian a lo largo de la vida del software. 29
2.3 Cómo enfrentar el cambio
El cambio es inevitable en todos los grandes
proyectos de software. Cualquiera que sea el modelo
del proceso de software utilizado, es esencial que
ajuste los cambios al software a desarrollar.
30
El cambio se agrega a los costos del desarrollo de software
debido a que, por lo general, significa que el trabajo ya
terminado debe volver a realizarse. (Rehacer )
Es necesario rediseñar el sistema para entregar los nuevos
requerimientos, cambiar cualquier programa que se haya
desarrollado y volver a probar el sistema.
31
Existen dos enfoques relacionados que se usan para reducir
los costos del rehacer:
[Link] de sistema, donde
rápidamente se desarrolla una versión
del sistema o una parte del mismo,
para comprobar los requerimientos
del cliente y la factibilidad de algunas
decisiones de diseño.
Es probable que se reduzca el número
de propuestas de cambio de
requerimientos posterior a la entrega.
32
Existen dos enfoques relacionados que se usan para reducir
los costos del rehacer:
[Link] incremental, donde los
incrementos del sistema se entregan al
cliente para su comentario y
experimentación. Esto apoya tanto al
hecho de evitar el cambio como a tolerar
el cambio.
Evita el compromiso prematuro con los
requerimientos para todo el sistema y, por
otro, permite la incorporación de cambios
en incrementos mayores a costos
relativamente bajos.
33
2.3.1 Creación del Prototipo
Un prototipo es una versión inicial de un sistema de
software que se usa para demostrar conceptos, tratar
opciones de diseño y encontrar más sobre el
problema y sus posibles soluciones.
Anticipan los cambios que se requieran:
[Link] el proceso de ingeniería de requerimientos, un
prototipo ayuda con la selección y validación de
requerimientos del sistema.
[Link] el proceso de diseño de sistemas, un prototipo
sirve para buscar soluciones específicas de software
y apoyar el diseño de interfaces del usuario.
34
La creación rápida de prototipos con la
participación del usuario final es la única forma
sensible para desarrollar interfaces de usuario
gráficas para sistemas de software..
Los objetivos de la creación de prototipos
deben ser más explícitos desde el inicio del
[Link] siguiente etapa del proceso
consiste en decidir qué poner y, algo quizá
más importante, qué dejar fuera del sistema
de prototipo.
35
Para reducir los costos de creación de prototipos y acelerar las fechas de entrega, es
posible dejar cierta funcionalidad fuera del prototipo y, también, decidir hacer más flexible
los requerimientos no funcionales, como el tiempo de respuesta y la utilización de
memoria.
La etapa final del proceso es la evaluación del prototipo. Hay que tomar provisiones
durante esta etapa para la capacitación del usuario y usar los objetivos del prototipo para
derivar un plan de evaluación
36
Algunos problemas en la creación del
prototipo
● Quizás el prototipo no se utilice
necesariamente en la misma forma que el
sistema final.
● El revisor del prototipo tal vez no sea un
usuario típico del sistema.
● Podría resultar insuficiente el tiempo de
capacitación durante la evaluación del
prototipo.
● En ocasiones, los desarrolladores están
presionados por los administradores para
entregar prototipos desechables, sobre todo
cuando existen demoras en la entrega de la
versión final del software.
37
2.3.2 Entrega de Incremental
Enfoque al desarrollo de software donde
algunos de los incrementos diseñados se
entregan al cliente y se implementan para
usarse en un entorno operacional. Los
clientes identifican, en un bosquejo, los
servicios que proporciona el sistema.
Identifican cuáles servicios son más
importantes y cuáles son menos
significativos para ellos.
38
La entrega incremental tiene algunas ventajas:
1. Los clientes pueden usar los primeros
incrementos como prototipos y adquirir
experiencia que informe sobre sus
requerimientos, para posteriores
incrementos del sistema
2. Los clientes deben esperar hasta la
entrega completa del sistema, antes de
ganar valor del mismo.
3. Mantiene los beneficios del desarrollo
incremental en cuanto a que debe ser
relativamente sencillo incorporar cambios
al sistema.
4. Puesto que primero se entregan los
servicios de mayor prioridad y luego se
integran los incrementos, los servicios de
sistema más importantes reciben mayores
pruebas.
39
2.3.2 Modelo Espiral de Boehm
El proceso de software se representa
como una espiral, y no como una
secuencia de actividades con cierto
retroceso de una actividad a otra.
Cada ciclo en la espiral representa una
fase del proceso de software. Por ende, el
ciclo más interno puede relacionarse con
la factibilidad del sistema, el siguiente
ciclo con la definición de requerimientos,
el ciclo que sigue con el diseño del
sistema, etcétera.
40
Cada ciclo en la espiral se divide en cuatro sectores:
1. Establecimiento de objetivos: Se identifican restricciones en el proceso y el producto, y se traza un
plan de gestión detallado. Se identifican los riesgos del proyecto. Pueden planearse estrategias
alternativas, según sean los riesgos.
1. Valoración y reducción del riesgo: En cada uno de los riesgos identificados del proyecto, se realiza un
análisis minucioso. Se dan acciones para reducir el riesgo.
1. Desarrollo y validación :Se elige un modelo de desarrollo para el sistema. Ejemplos: , la creación de
prototipos desechables sería el mejor enfoque de desarrollo, si predominan los riesgos en la interfaz del
usuario.
Si el principal riesgo identificado es la integración de subsistemas, el modelo en cascada sería el mejor
modelo de desarrollo a utilizar.
1. Planeación : Se revisa y se toma una decisión sobre si hay que continuar con otro ciclo de la espiral.
La diferencia principal entre el modelo en espiral con otros modelos de proceso de software es su
reconocimiento explícito del riesgo.
41
2.4 Proceso Unificado Racional (Rational Unified Process)
Es un ejemplo de un modelo de proceso moderno
que se derivó del trabajo sobre el UML y el proceso
asociado de desarrollo de software unificado.
Es un buen ejemplo de un modelo de proceso
híbrido, es un modelo en fases que identifica cuatro
fases discretas en el proceso de software. A
diferencia del modelo en cascada, donde las fases se
igualan con actividades del proceso, las fases en el
RUP están más estrechamente vinculadas con la
empresa que con las preocupaciones técnicas.
42
Fases del RUP:
1. Concepción: Establecer un caso empresarial para el sistema.. Deben identificarse todas las entidades
externas (personas y sistemas) que interactuarán con el sistema y definirán dichas interacciones.
2. Elaboración: desarrollar la comprensión del problema de dominio, establecer un marco conceptual
arquitectónico para el sistema, diseñar el plan del proyecto e identificar los riesgos clave del proyecto.
3. Construcción: Incluye diseño, programación y pruebas del sistema.
4. Transición: Interés por el cambio del sistema desde la comunidad de desarrollo hacia la comunidad de
usuarios, y por ponerlo a funcionar en un ambiente real.
Todo el conjunto de fases puede expresarse de manera incremental, como se
muestra en la flecha en curva desde transición hasta concepción.
43
Flujos de trabajo
estáticos en el
Proceso
Unificado
Racional
44
PUNTOS CLAVE
● Los procesos de software son actividades implicadas en la producción de un
sistema de software. Los modelos de proceso de software consisten en
representaciones abstractas de dichos procesos.
● Los modelos de proceso general describen la organización de los procesos de
software. Los ejemplos de estos modelos generales incluyen el modelo en
cascada, el desarrollo incremental y el desarrollo orientado a la
reutilización.
● La ingeniería de requerimientos es el proceso de desarrollo de una
especificación de software. Las especificaciones tienen la intención de
comunicar las necesidades de sistema del cliente a los desarrolladores del
sistema.
● Los procesos de diseño e implementación tratan de transformar una
especificación de requerimientos en un sistema de software ejecutable.
Pueden usarse métodos de diseño sistemáticos como parte de esta 45
transformación.
PUNTOS CLAVE
● La validación del software es el proceso de comprobar que el sistema se
conforma a su especificación y que satisface las necesidades reales de los
usuarios del sistema.
● La evolución del software tiene lugar cuando cambian los sistemas de software
existentes para satisfacer nuevos requerimientos. Los cambios son continuos y
el software debe evolucionar para seguir siendo útil.
● Los procesos deben incluir actividades para lidiar con el cambio. Esto puede
implicar una fase de creación de prototipos que ayude a evitar malas decisiones
sobre los requerimientos y el diseño. Los procesos pueden estructurarse para
desarrollo y entrega iterativos, de forma que los cambios se realicen sin
perturbar al sistema como un todo.
● El Proceso Unificado Racional es un modelo de proceso genérico moderno que
está organizado en fases (concepción, elaboración, construcción y transición),
pero separa las actividades (requerimientos, análisis y diseño, etcétera) de
dichas fases. 46
Ejercicios
2.1. Explicando las razones para su respuesta, y con base en el tipo de sistema a desarrollar, sugiera el modelo de
proceso de software genérico más adecuado que se use como fundamento para administrar el desarrollo de los
siguientes sistemas:
● Un sistema para controlar el antibloqueo de frenos en un automóvil
Se utilizará un modelo en cascada, porque este tipo de desarrollo es muy adecuado para un proceso dirigido
por un plan; en principio, usted debe planear y programar todas las actividades del proceso, antes de
comenzar a trabajar con ellas.
● Un sistema de realidad virtual para apoyar el mantenimiento de software
En este tipo de sistema sería necesario utilizar un desarrollo de tipo incremental, porque el mismo se iría
construyendo y evolucionando según el testeo del sistema y además el sistema se desarrolla como una
serie de versiones (incrementos), y cada versión añade funcionalidad a la versión anterior.
● Un sistema de contabilidad universitario que sustituya a uno existente
Este sistema se podría realizar mediante la ingeniería de software orientada a la reutilización, porque se
parte de un sistema existente, el cual se puede reutilizar parte del mismo.
● Un sistema interactivo de programación de viajes que ayude a los usuarios a planear viajes con el
menor impacto ambiental
Se podría utilizar un desarrollo de tipo incremental, porque se puede ir desarrollando parcialmente y ver si se
cubren las necesidades del cliente en cada versión que se está desarrollando.
47
Ejercicios
2.2. Explique por qué el desarrollo incremental es el enfoque más efectivo para diseñar sistemas de
software empresariales. ¿Por qué este modelo es menos adecuado para ingeniería de sistemas de tiempo
real?
El desarrollo incremental es mejor para el software empresarial porque refleja la forma en que se
resuelven los problemas, se avanza en una serie de pasos hacia la solución de los mismo y es más
sencillo obtener retroalimentación del cliente sobre el trabajo de desarrollo que se realizó. En
sistemas de tiempo real presenta la dificultad de alterar los procesos empresariales normales,
porque el proceso no es visible. Los administradores necesitan entregas regulares para medir el
avance.
2.3. Considere el modelo de proceso basado en reutilización que se muestra en la figura 2.3. Explique por
qué durante el proceso es esencial tener dos actividades separadas de ingeniería de requerimientos.
En este modelo de proceso, es necesario tener dos actividades referidas a requerimientos porque al
trabajar con un sistema donde se reutilizan procesos, hay que adecuar los nuevos requerimientos a
los componentes que se puedan reutilizar y los que se descubran que se puedan adaptar al sistema.
Muchas veces no se pueden cumplir los requerimientos necesarios, entonces hay que volver a la
etapa de diseño para encontrar soluciones alternativas.
48
Ejercicios
2.4. Sugiera por qué, en el proceso de ingeniería de requerimientos, es importante hacer una distinción entre
desarrollar los requerimientos del usuario y desarrollar los requerimientos del sistema.
Porque los requerimientos del usuario son informes abstractos para que el cliente pueda utilizar el
sistema y los requerimientos del sistema son una descripción más detallada del sistema para los
desarrolladores.
2.5. Describa las principales actividades en el proceso de diseño de software y
las salidas de dichas actividades. Con un diagrama, muestre las posibles
relaciones entre las salidas de dichas actividades.
● Diseño arquitectónico: Identifica la estructura global del sistema, los
principales componentes, sus relaciones y cómo se distribuyen.
● Diseño de interfaz: Se definen las interfaces entre los componentes del
sistema y se diseñan y desarrollan.
● Diseño de componentes: Se toma cada componente del sistema y se
diseña cómo funcionará. Puede ser un simple dato de la funcionalidad que
se espera implementar y al programador se le deja el diseño específico.
● Diseño de base de datos: Se diseñan las estructuras del sistema de
datos y cómo se representarán en una base de datos o si se utilizará una
ya existente.
49
Ejercicios
2.6. Explique por qué el cambio es inevitable en los sistemas complejos, y mencione ejemplos (además
de la creación de prototipos y la entrega incremental) de las actividades de proceso de software que
ayudan a predecir los cambios y a lograr que el software por desarrollar sea más resistente al cambio.
Los requerimientos del sistema varían conforme la empresa procura que el sistema responda a
presiones externas y se modifican las prioridades administrativas. Un ejemplo es mostrarle al
cliente y de ser posible, que firme el documento de ERS(especificación de requisitos de software),
en donde la consultoría especifica los requerimientos funcionales y no funcionales.
2.7. Explique por qué los sistemas desarrollados como prototipos por lo general no deben usarse como
sistemas de producción.
[Link] ser imposible corregir el prototipo para cubrir requerimientos no funcionales, como los
requerimientos de rendimiento, seguridad, robustez y fiabilidad, ignorados durante el desarrollo del
prototipo.
[Link] única especificación de diseño es el código del prototipo. Esto no es muy bueno para el
mantenimiento a largo plazo
[Link] lo general, durante el desarrollo de prototipos se hacen más flexibles los estándares de
calidad de la organización.
50
Ejercicios
2.8. Exponga por qué el modelo en espiral de Boehm es un modelo adaptable que puede apoyar las
actividades tanto de evitar el cambio como de tolerar el cambio. En la práctica, este modelo no se ha
usado ampliamente. Sugiera por qué éste podría ser el caso.
Ya que este modelo supone que los cambios son resultado de riesgos del proyecto e incluye actividades
de gestión de riesgos explícitas para reducir tales riesgos. El modelo en espiral requiere de la creación de
varios prototipos, y esto lo pueden causar retrasos en la creación del sistema final.
2.9. ¿Cuáles son las ventajas de proporcionar visiones estática y dinámica del proceso de software
como en el Proceso Unificado Racional?
La ventaja radica en que las fases del proceso de desarrollo no están asociadas con flujos de
trabajo específicos. En principio, al menos, todos los flujos de trabajo RUP pueden estar activos en
la totalidad de las etapas del proceso.
51
Ejercicios
2.10. Históricamente, la introducción de la tecnología ha causado profundos cambios en el mercado
laboral y, al menos temporalmente, ha reemplazado a personas en los puestos de trabajo. Explique si es
probable que la introducción de extensos procesos de automatización tenga las mismas consecuencias
para los ingenieros de software. Si no cree que haya consecuencias, explique por qué. Si cree que
reducirá las oportunidades laborales, ¿es ético que los ingenieros afectados resistan pasiva o
activamente la introducción de esta tecnología?
Creemos que sí podrían generarse cambios pero no que los puestos de ingeniería de software
dejarían de existir ya que los avances de las herramientas tecnológicas para el desarrollo
dependen del estudio y aporte de los desarrolladores, aunque esto sí podría representar una
reducción de oportunidades laborales en las fabricas de software y no creemos que sea ético una
resistencia activa ante su introducción, ya que permitir el cambio facilita el trabajo y abre puertas a
mejores aplicaciones.
52
