Machine Translated by Google
2
Procesos de software
Objetivos El
objetivo de este capítulo es presentarle la idea de un proceso de software:
un conjunto coherente de actividades para la producción de software.
Cuando haya leído este capítulo, usted:
ÿ comprender los conceptos de procesos de software y modelos de procesos de
software;
ÿ han sido introducidos a tres modelos generales de procesos de software y
cuándo podrían usarse;
ÿ conocer las actividades fundamentales del proceso de ingeniería de requisitos de software,
desarrollo, pruebas y evolución de software;
ÿ comprender por qué los procesos deben organizarse para hacer frente a los cambios
en los requisitos y diseño del software;
ÿ comprender la noción de mejora del proceso de software y la
factores que afectan la calidad del proceso de software.
Contenido
2.1 Modelos de proceso de software
2.2 Actividades de proceso
2.3 Hacer frente al cambio 2.4
Mejora de procesos
Machine Translated by Google
44 Capítulo 2 ÿ Procesos de software
Un proceso de software es un conjunto de actividades relacionadas que conducen a la producción de un sistema
de software. Como mencioné en el Capítulo 1, hay muchos tipos diferentes de sistemas de software y no existe un
método de ingeniería de software universal que sea aplicable a todos ellos. En consecuencia, no existe un proceso
de software de aplicación universal. El proceso utilizado en diferentes empresas depende del tipo de software que
se desarrolle, los requisitos del cliente del software y las habilidades de las personas que escriben el software.
Sin embargo, aunque hay muchos procesos de software diferentes, todos deben incluir, de alguna forma, las
cuatro actividades fundamentales de ingeniería de software que introduje en el Capítulo 1:
1. Especificación del software La funcionalidad del software y las limitaciones de su
la operación debe ser definida.
2. Desarrollo de software Se debe producir el software que cumpla con las especificaciones.
3. Validación del software El software debe validarse para garantizar que hace lo que
el cliente quiere.
4. Evolución del software El software debe evolucionar para satisfacer las necesidades cambiantes de los clientes.
Estas actividades son actividades complejas en sí mismas e incluyen subactividades como la validación de
requisitos, el diseño arquitectónico y las pruebas unitarias. Los procesos también incluyen otras actividades, como
la gestión de configuración de software y la planificación de proyectos que respaldan las actividades de producción.
Cuando describimos y discutimos procesos, generalmente hablamos sobre las actividades en estos procesos,
como especificar un modelo de datos y diseñar una interfaz de usuario, y el orden de estas actividades. Todos
podemos relacionarnos con lo que la gente hace para desarrollar software. Sin embargo, al describir procesos,
también es importante describir quién está involucrado, qué se produce y las condiciones que influyen en la
secuencia de actividades:
1. Los productos o entregables son los resultados de una actividad de proceso. Por ejemplo, el resultado de la
actividad de diseño arquitectónico puede ser un modelo de la arquitectura del software.
2. Los roles reflejan las responsabilidades de las personas involucradas en el proceso. Ejemplos
de los roles son gerente de proyecto, gerente de configuración y programador.
3. Las condiciones previas y posteriores son condiciones que deben cumplirse antes y después de que se haya
llevado a cabo una actividad de proceso o se haya producido un producto. Por ejemplo, antes de que
comience el diseño arquitectónico, una condición previa puede ser que el consumidor haya aprobado todos
los requisitos; una vez finalizada esta actividad, una condición posterior podría ser que se hayan revisado
los modelos UML que describen la arquitectura.
Los procesos de software son complejos y, como todos los procesos intelectuales y creativos, dependen de
personas que toman decisiones y juicios. Como no existe un proceso universal que sea adecuado para todo tipo
de software, la mayoría de las empresas de software han desarrollado su propio proceso.
Machine Translated by Google
2.1 ÿ Modelos de procesos de software 45
procesos de desarrollo. Los procesos han evolucionado para aprovechar las capacidades de los
desarrolladores de software en una organización y las características de los sistemas que se están
desarrollando. Para los sistemas críticos para la seguridad, se requiere un proceso de desarrollo
muy estructurado en el que se mantengan registros detallados. Para los sistemas comerciales, con
requisitos que cambian rápidamente, es probable que sea mejor un proceso más flexible y ágil.
Como mencioné en el Capítulo 1, el desarrollo profesional de software profesional es una
actividad administrada, por lo que la planificación es una parte inherente de todos los procesos. Los
procesos impulsados por planes son procesos en los que todas las actividades del proceso se
planifican por adelantado y el progreso se mide con respecto a este plan. En los procesos ágiles,
que analizo en el Capítulo 3, la planificación es incremental y continua a medida que se desarrolla
el software. Por lo tanto, es más fácil cambiar el proceso para reflejar los requisitos cambiantes del
cliente o del producto. Como explican Boehm y Turner (Boehm y Turner 2004), cada enfoque es
adecuado para diferentes tipos de software. En general, para sistemas grandes, debe encontrar un
equilibrio entre los procesos ágiles y los basados en planes.
Aunque no existe un proceso de software universal, existe margen para la mejora de procesos
en muchas organizaciones. Los procesos pueden incluir técnicas obsoletas o no aprovechar las
mejores prácticas en ingeniería de software industrial. De hecho, muchas organizaciones aún no
aprovechan los métodos de ingeniería de software en su desarrollo de software. Pueden mejorar
su proceso mediante la introducción de técnicas como el modelado UML y el desarrollo basado en
pruebas. Discuto brevemente la mejora del proceso de software más adelante en el texto de este
capítulo y con más detalle en el Capítulo 26 de la web.
2.1 Modelos de procesos de software
Como expliqué en el Capítulo 1, un modelo de proceso de software (a veces denominado Ciclo de
vida de desarrollo de software o modelo SDLC) es una representación simplificada de un proceso
de software. Cada modelo de proceso representa un proceso desde una perspectiva particular y,
por lo tanto, solo proporciona información parcial sobre ese proceso. Por ejemplo, un modelo de
actividad de proceso muestra las actividades y su secuencia, pero puede que no muestre los roles
de las personas involucradas en estas actividades. En esta sección, presento una serie de modelos
de procesos muy generales (a veces llamados paradigmas de procesos) y los presento desde una
perspectiva arquitectónica. Es decir, vemos el marco del proceso pero no los detalles de las
actividades del proceso.
Estos modelos genéricos son descripciones abstractas de alto nivel de procesos de software
que se pueden utilizar para explicar diferentes enfoques para el desarrollo de software. Puede
pensar en ellos como marcos de procesos que pueden extenderse y adaptarse para crear procesos
de ingeniería de software más específicos.
Los modelos generales de proceso que cubro aquí son:
1. El modelo en cascada Toma las actividades fundamentales del proceso de especificación,
desarrollo, validación y evolución y las representa como fases de proceso separadas, como
especificación de requisitos, diseño de software, implementación y prueba.
Machine Translated by Google
46 Capítulo 2 ÿ Procesos de software
El proceso unificado racional
El Rational Unified Process (RUP) reúne elementos de todos los modelos de procesos generales discutidos aquí y admite
la creación de prototipos y la entrega incremental de software (Krutchen 2003). El RUP normalmente se describe desde
tres perspectivas: una perspectiva dinámica que muestra las fases del modelo en el tiempo, una perspectiva estática que
muestra las actividades del proceso y una perspectiva práctica que sugiere buenas prácticas para ser utilizadas en el proceso.
Las fases de RUP son el inicio, donde se establece un caso de negocio para el sistema; elaboración, donde se desarrollan los
requisitos y la arquitectura; construcción donde se implementa el software; y transición, donde se implementa el sistema.
http://software-engineering-book.com/web/rup/
2. Desarrollo incremental Este enfoque intercala las actividades de especificación, desarrollo y
validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada
versión agrega funcionalidad a la versión anterior.
3. Integración y configuración Este enfoque se basa en la disponibilidad de componentes o
sistemas reutilizables. El proceso de desarrollo del sistema se centra en configurar estos
componentes para su uso en un nuevo entorno e integrarlos en un sistema.
Como he dicho, no existe un modelo de proceso universal que sea adecuado para todo tipo
de desarrollo de software. El proceso adecuado depende del cliente y de los requisitos
reglamentarios, del entorno en el que se utilizará el software y del tipo de software que se
desarrolle. Por ejemplo, el software crítico para la seguridad generalmente se desarrolla utilizando
un proceso en cascada, ya que se requiere una gran cantidad de análisis y documentación antes
de que comience la implementación. Los productos de software ahora siempre se desarrollan
utilizando un modelo de proceso incremental. Los sistemas empresariales se desarrollan cada
vez más mediante la configuración de los sistemas existentes y su integración para crear un
nuevo sistema con la funcionalidad requerida.
La mayoría de los procesos prácticos de software se basan en un modelo general, pero a
menudo incorporan características de otros modelos. Esto es particularmente cierto para la
ingeniería de grandes sistemas. Para sistemas grandes, tiene sentido combinar algunas de las
mejores características de todos los procesos generales. Debe tener información sobre los
requisitos esenciales del sistema para diseñar una arquitectura de software que admita estos requisitos.
No se puede desarrollar esto de forma incremental. Los subsistemas dentro de un sistema más
grande pueden desarrollarse utilizando diferentes enfoques. Las partes del sistema que se
entienden bien se pueden especificar y desarrollar utilizando un proceso basado en cascada o se
pueden comprar como sistemas listos para usar para la configuración. Otras partes del sistema,
que son difíciles de especificar de antemano, siempre deben desarrollarse utilizando un enfoque
incremental. En ambos casos, es probable que los componentes de software se reutilicen.
Se han realizado varios intentos para desarrollar modelos de proceso "universales" que se
basen en todos estos modelos generales. Uno de los más conocidos de estos modelos universales
es el Proceso Unificado Racional (RUP) (Krutchen 2003), que fue desarrollado por Rational, una
compañía de ingeniería de software de EE.UU. El RUP es un modelo flexible que
Machine Translated by Google
2.1 ÿ Modelos de procesos de software 47
Definición de
requisitos
Diseño de
sistemas y software
Implementación y
pruebas unitarias
Integración y
pruebas del sistema.
Operación y
mantenimiento
Figura 2.1 El
modelo de cascada
se pueden instanciar de diferentes maneras para crear procesos que se asemejan a cualquiera de los
modelos de procesos generales discutidos aquí. El RUP ha sido adoptado por algunas grandes
empresas de software (en particular, IBM), pero no ha ganado una aceptación generalizada.
2.1.1 El modelo de cascada
El primer modelo publicado del proceso de desarrollo de software se derivó de los modelos de procesos
de ingeniería utilizados en la ingeniería de grandes sistemas militares (Royce 1970). Presenta el
proceso de desarrollo de software como una serie de etapas, como se muestra en la Figura 2.1.
Debido a la cascada de una fase a otra, este modelo se conoce como modelo en cascada o ciclo de
vida del software. El modelo de cascada es un ejemplo de un proceso impulsado por un plan. Al menos
en principio, usted planifica y programa todas las actividades del proceso antes de comenzar el
desarrollo de software.
Las etapas del modelo en cascada reflejan directamente las actividades fundamentales de
desarrollo de software:
1. Análisis y definición de requisitos Los servicios, restricciones y objetivos del sistema se establecen
mediante consultas con los usuarios del sistema. Luego se definen en detalle y sirven como
especificación del sistema.
2. Diseño de sistemas y software El proceso de diseño de sistemas asigna los requisitos a los
sistemas de hardware o software. Establece una arquitectura general del sistema. El diseño de
software implica identificar y describir las abstracciones fundamentales del sistema de software
y sus relaciones.
3. Implementación y pruebas unitarias Durante esta etapa, el diseño del software se realiza como un
conjunto de programas o unidades de programas. Las pruebas unitarias implican verificar que
cada unidad cumpla con su especificación.
Machine Translated by Google
48 Capítulo 2 ÿ Procesos de software
Modelo de proceso en espiral de Boehm
Barry Boehm, uno de los pioneros en ingeniería de software, propuso un modelo de proceso incremental basado en el riesgo. El proceso
se representa como una espiral más que como una secuencia de actividades (Boehm 1988).
Cada bucle en la espiral representa una fase del proceso de software. Por lo tanto, el bucle más interno podría estar relacionado con la
viabilidad del sistema, el siguiente bucle con la definición de requisitos, el siguiente bucle con el diseño del sistema, etc. El modelo en
espiral combina la evitación del cambio con la tolerancia al cambio. Asume que los cambios son el resultado de los riesgos del proyecto e
incluye actividades explícitas de gestión de riesgos para reducir estos riesgos.
http://software-engineering-book.com/web/spiral-model/
4. Integración y prueba del sistema Las unidades de programa individuales o los programas se
integran y prueban como un sistema completo para garantizar que se han cumplido los
requisitos del software. Después de la prueba, el sistema de software se entrega al cliente.
5. Operación y mantenimiento Normalmente, esta es la fase más larga del ciclo de vida. El sistema
está instalado y puesto en uso práctico. El mantenimiento implica corregir errores que no se
descubrieron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades
del sistema y mejorar los servicios del sistema a medida que se descubren nuevos requisitos.
En principio, el resultado de cada fase del modelo en cascada es uno o más documentos que
se aprueban (“firman”). La siguiente fase no debe comenzar hasta que la fase anterior haya
terminado. Para el desarrollo de hardware, donde se involucran altos costos de fabricación, esto
tiene sentido. Sin embargo, para el desarrollo de software, estas etapas se superponen y se
alimentan de información entre sí. Durante el diseño, se identifican problemas con los requisitos;
durante la codificación se encuentran problemas de diseño, y así sucesivamente.
El proceso de software, en la práctica, nunca es un modelo lineal simple, sino que implica
retroalimentación de una fase a otra.
A medida que surge nueva información en una etapa del proceso, los documentos producidos
en etapas anteriores deben modificarse para reflejar los cambios requeridos en el sistema. Por
ejemplo, si se descubre que un requisito es demasiado costoso para implementar, el documento de
requisitos debe cambiarse para eliminar ese requisito. Sin embargo, esto requiere la aprobación del
cliente y retrasa el proceso de desarrollo general.
Como resultado, tanto los clientes como los desarrolladores pueden congelar prematuramente la
especificación del software para que no se realicen más cambios. Desafortunadamente, esto significa
que los problemas se dejan para una resolución posterior, se ignoran o se programan. La congelación
prematura de requisitos puede significar que el sistema no hará lo que el usuario desea. También
puede dar lugar a sistemas mal estructurados, ya que los problemas de diseño se eluden mediante
trucos de implementación.
Durante la fase final del ciclo de vida (operación y mantenimiento), el software se pone en uso.
Se descubren errores y omisiones en los requisitos del software original.
Machine Translated by Google
2.1 ÿ Modelos de procesos de software 49
Surgen errores de programa y diseño, y se identifica la necesidad de una nueva funcionalidad.
Por lo tanto, el sistema debe evolucionar para seguir siendo útil. Hacer estos cambios
(mantenimiento de software) puede implicar repetir etapas de procesos anteriores.
En realidad, el software debe ser flexible y adaptarse a los cambios a medida que se
desarrolla. La necesidad de compromiso temprano y reelaboración del sistema cuando se realizan
cambios significa que el modelo en cascada solo es apropiado para algunos tipos de sistema:
1. Sistemas integrados en los que el software tiene que interactuar con los sistemas de hardware.
Debido a la inflexibilidad del hardware, normalmente no es posible retrasar las decisiones
sobre la funcionalidad del software hasta que se implemente.
2. Sistemas críticos donde existe la necesidad de un extenso análisis de seguridad y protección
de la especificación y el diseño del software. En estos sistemas, los documentos de
especificación y diseño deben estar completos para que este análisis sea posible. Los
problemas relacionados con la seguridad en la especificación y el diseño suelen ser muy
costosos de corregir en la etapa de implementación.
3. Grandes sistemas de software que forman parte de sistemas de ingeniería más amplios
desarrollados por varias empresas asociadas. El hardware de los sistemas puede
desarrollarse utilizando un modelo similar, y a las empresas les resulta más fácil utilizar un
modelo común para el hardware y el software. Además, cuando participen varias empresas,
es posible que se necesiten especificaciones completas para permitir el desarrollo
independiente de diferentes subsistemas.
El modelo de cascada no es el modelo de proceso adecuado en situaciones en las que es
posible la comunicación informal del equipo y los requisitos de software cambian rápidamente. El
desarrollo iterativo y los métodos ágiles son mejores para estos sistemas.
Una variante importante del modelo en cascada es el desarrollo de un sistema formal, donde
se crea un modelo matemático de la especificación de un sistema. Luego, este modelo se refina,
utilizando transformaciones matemáticas que preservan su consistencia, en código ejecutable.
Los procesos formales de desarrollo, como el basado en el método B (Abrial 2005, 2010), se
utilizan principalmente en el desarrollo de sistemas de software que tienen requisitos estrictos de
seguridad, confiabilidad o seguridad. El enfoque formal simplifica la producción de un caso de
seguridad o protección. Esto demuestra a los clientes o reguladores que el sistema realmente
cumple con sus requisitos de seguridad. Sin embargo, debido a los altos costos de desarrollar
una especificación formal, este modelo de desarrollo rara vez se usa, excepto para la ingeniería
de sistemas críticos.
2.1.2 Desarrollo incremental
El desarrollo incremental se basa en la idea de desarrollar una implementación inicial, obtener
retroalimentación de los usuarios y otros, y evolucionar el software a través de varias versiones
hasta que se haya desarrollado el sistema requerido (Figura 2.2).
Las actividades de especificación, desarrollo y validación están intercaladas en lugar de
separadas, con una rápida retroalimentación entre actividades.
Machine Translated by Google
50 Capítulo 2 ÿ Procesos de software
actividades
concurrentes
Especificación
Descripción
del esquema
Desarrollo
Validación
Versión
inicial
Versiones
intermedias
Versión final
Figura 2.2 Desarrollo
incremental
El desarrollo incremental de alguna forma es ahora el enfoque más común para el
desarrollo de sistemas de aplicaciones y productos de software. Este enfoque puede estar
basado en un plan, ágil o, más generalmente, una combinación de estos enfoques. En un
enfoque basado en un plan, los incrementos del sistema se identifican de antemano; si se
adopta un enfoque ágil, se identifican los primeros incrementos, pero el desarrollo de
incrementos posteriores depende del progreso y las prioridades del cliente.
El desarrollo de software incremental, que es una parte fundamental de los métodos
de desarrollo ágiles, es mejor que un enfoque en cascada para los sistemas cuyos
requisitos probablemente cambien durante el proceso de desarrollo. Este es el caso de la
mayoría de los sistemas comerciales y productos de software. El desarrollo incremental
refleja la forma en que resolvemos los problemas. Rara vez elaboramos una solución
completa del problema por adelantado, sino que avanzamos hacia una solución en una
serie de pasos, retrocediendo cuando nos damos cuenta de que hemos cometido un error.
Al desarrollar el software de forma incremental, es más barato y fácil realizar cambios en
el software a medida que se desarrolla.
Cada incremento o versión del sistema incorpora algunas de las funcionalidades que
necesita el cliente. Generalmente, los primeros incrementos del sistema incluyen la
funcionalidad más importante o requerida con mayor urgencia. Esto significa que el cliente
o usuario puede evaluar el sistema en una etapa relativamente temprana del desarrollo
para ver si ofrece lo que se requiere. De lo contrario, solo se debe cambiar el incremento
actual y, posiblemente, definir una nueva funcionalidad para incrementos posteriores.
El desarrollo incremental tiene tres ventajas principales sobre el modelo en cascada:
1. Se reduce el costo de implementar cambios en los requisitos. La cantidad de análisis y
documentación que se debe rehacer es significativamente menor que la requerida
con el modelo en cascada.
2. Es más fácil obtener comentarios de los clientes sobre el trabajo de desarrollo que se
ha realizado. Los clientes pueden comentar demostraciones del software y ver cómo
Machine Translated by Google
2.1 ÿ Modelos de procesos de software 51
Problemas con el desarrollo incremental
Aunque el desarrollo incremental tiene muchas ventajas, no está libre de problemas. La causa principal de la dificultad es el
hecho de que las grandes organizaciones tienen procedimientos burocráticos que han evolucionado con el tiempo y puede
haber una discrepancia entre estos procedimientos y un proceso iterativo o ágil más informal.
A veces, estos procedimientos están ahí por buenas razones. Por ejemplo, puede haber procedimientos para garantizar
que el software cumple adecuadamente implementa normativas externas (por ejemplo, en Estados Unidos, la normativa
contable Sarbanes Oxley). Es posible que no sea posible cambiar estos procedimientos, por lo que los conflictos de procesos
pueden ser inevitables.
http://software-engineering-book.com/web/incremental-development/
se ha implementado mucho. A los clientes les resulta difícil juzgar el progreso a partir de los documentos de
diseño de software.
3. Es posible la entrega temprana y la implementación de software útil para el cliente, incluso si no se ha incluido
toda la funcionalidad. Los clientes pueden usar y obtener valor del software antes de lo que es posible con
un proceso en cascada.
Desde una perspectiva de gestión, el enfoque incremental tiene dos problemas:
1. El proceso no es visible. Los gerentes necesitan entregables regulares para medir el progreso. Si los sistemas
se desarrollan rápidamente, no es rentable producir documentos que reflejen todas las versiones del
sistema.
2. La estructura del sistema tiende a degradarse a medida que se agregan nuevos incrementos. El cambio regular
conduce a un código desordenado a medida que se agregan nuevas funciones de cualquier manera posible.
Se vuelve cada vez más difícil y costoso agregar nuevas funciones a un sistema. Para reducir la degradación
estructural y el desorden general del código, los métodos ágiles sugieren que debe refactorizar (mejorar y
reestructurar) el software con regularidad.
Los problemas del desarrollo incremental se vuelven particularmente agudos para sistemas grandes, complejos
y de larga duración, donde diferentes equipos desarrollan diferentes partes del sistema. Los sistemas grandes
necesitan un marco o arquitectura estable, y las responsabilidades de los diferentes equipos que trabajan en
partes del sistema deben estar claramente definidas con respecto a esa arquitectura. Esto debe planificarse con
anticipación en lugar de desarrollarse gradualmente.
El desarrollo incremental no significa que tenga que entregar cada incremento al cliente del sistema. Puede
desarrollar un sistema de forma incremental y exponerlo a los clientes y otras partes interesadas para obtener
comentarios, sin necesariamente entregarlo e implementarlo en el entorno del cliente. La entrega incremental
(tratada en la Sección 2.3.2) significa que el software se usa en procesos operativos reales, por lo que es probable
que los comentarios de los usuarios sean realistas. Sin embargo, proporcionar comentarios no siempre es posible,
ya que experimentar con software nuevo puede interrumpir los procesos comerciales normales.
Machine Translated by Google
52 Capítulo 2 ÿ Procesos de software
Sistema de aplicación
disponible
Descubrimiento
Configurar el
sistema de
aplicaciones
de software
Refinamiento de
requisitos
Especificación de
requisitos
Adaptar
componentes
Evaluación
Integrar
de software
Componentes
disponibles
Figura 2.3 Ingeniería
de software orientada
sistema
Desarrollar nuevos
componentes
a la reutilización
2.1.3 Integración y configuración
En la mayoría de los proyectos de software, hay algo de reutilización de software. Esto sucede a menudo de
manera informal cuando las personas que trabajan en el proyecto conocen o buscan un código similar al que se
requiere. Los buscan, los modifican según sea necesario y los integran con el nuevo código que han desarrollado.
Esta reutilización informal tiene lugar independientemente del proceso de desarrollo que se utilice. Sin
embargo, desde el año 2000, los procesos de desarrollo de software que se centran en la reutilización del
software existente se han vuelto ampliamente utilizados. Los enfoques orientados a la reutilización se basan en
una base de componentes de software reutilizables y un marco integrador para la composición de estos
componentes.
Con frecuencia se reutilizan tres tipos de componentes de software:
1. Sistemas de aplicaciones independientes que están configurados para su uso en un entorno particular. Estos
sistemas son sistemas de propósito general que tienen muchas funciones, pero deben adaptarse para su
uso en una aplicación específica.
2. Colecciones de objetos que se desarrollan como un componente o como un paquete para integrarse con un
marco de componentes como el marco Java Spring (Wheeler y White 2013).
3. Servicios web que se desarrollan de acuerdo con estándares de servicio y que están disponibles para
invocación remota a través de Internet.
La Figura 2.3 muestra un modelo de proceso general para el desarrollo basado en la reutilización, basado en
integración y configuración. Las etapas en este proceso son:
1. Especificación de requisitos Se proponen los requisitos iniciales del sistema. Estos no tienen que ser
elaborados en detalle, pero deben incluir breves descripciones de los requisitos esenciales y las
características deseables del sistema.
2. Descubrimiento y evaluación del software Dado un esquema de los requisitos del software, se realiza una
búsqueda de componentes y sistemas que proporcionen la funcionalidad requerida. Los componentes y
sistemas candidatos se evalúan para ver si
Machine Translated by Google
2.1 ÿ Modelos de procesos de software 53
Herramientas de desarrollo de software
Las herramientas de desarrollo de software son programas que se utilizan para apoyar las actividades del proceso de ingeniería de software.
Estas herramientas incluyen herramientas de gestión de requisitos, editores de diseño, herramientas de soporte de refactorización, compiladores,
depuradores, rastreadores de errores y herramientas de creación de sistemas.
Las herramientas de software brindan soporte al proceso al automatizar algunas actividades del proceso y al proporcionar información sobre el software
que se está desarrollando. Por ejemplo:
ÿ El desarrollo de modelos de sistemas gráficos como parte de la especificación de requisitos o el software
diseño
ÿ La generación de código a partir de estos modelos gráficos.
ÿ La generación de interfaces de usuario a partir de una descripción de interfaz gráfica que el usuario crea de forma interactiva.
ÿ Depuración de programas mediante el suministro de información sobre un programa en ejecución
ÿ La traducción automática de programas escritos utilizando una versión antigua de un lenguaje de programación a una versión más
versión reciente
Las herramientas se pueden combinar dentro de un marco llamado Entorno de desarrollo interactivo o IDE. Esto proporciona un conjunto común de
facilidades que las herramientas pueden usar para que sea más fácil que las herramientas se comuniquen y operen de manera integrada.
http://software-engineering-book.com/web/software-tools/
cumplen los requisitos esenciales y si son generalmente adecuados para su uso en el
sistema.
3. Refinamiento de requisitos Durante esta etapa, los requisitos se refinan utilizando información
sobre los componentes y aplicaciones reutilizables que se han descubierto. Los requisitos
se modifican para reflejar los componentes disponibles y la especificación del sistema se
redefine. Cuando las modificaciones sean imposibles, se puede volver a ingresar a la
actividad de análisis de componentes para buscar soluciones alternativas.
4. Configuración del sistema de aplicación Si hay disponible un sistema de aplicación estándar
que cumple con los requisitos, puede configurarse para usarlo para crear el nuevo sistema.
5. Adaptación e integración de componentes Si no existe un sistema listo para usar, los
componentes reutilizables individuales pueden modificarse y desarrollarse nuevos componentes.
Luego se integran para crear el sistema.
La ingeniería de software orientada a la reutilización, basada en la configuración y la
integración, tiene la ventaja obvia de reducir la cantidad de software a desarrollar y, por lo tanto,
reducir los costos y los riesgos. Por lo general, también conduce a una entrega más rápida del software.
Sin embargo, los compromisos de requisitos son inevitables, y esto puede conducir a un sistema
Machine Translated by Google
54 Capítulo 2 ÿ Procesos de software
que no satisface las necesidades reales de los usuarios. Además, se pierde cierto control sobre la
evolución del sistema, ya que las nuevas versiones de los componentes reutilizables no están bajo el
control de la organización que los utiliza.
La reutilización del software es muy importante, por lo que varios capítulos del tercero he dedicado
varios capítulos de la tercera parte del libro a este tema. Los temas generales de reutilización de
software se tratan en el Capítulo 15, la ingeniería de software basada en componentes en los Capítulos
16 y 17 y los sistemas orientados a servicios en el Capítulo 18.
2.2 Actividades de proceso
Los procesos de software reales son secuencias intercaladas de actividades técnicas, colaborativas y
administrativas con el objetivo general de especificar, diseñar, implementar y probar un sistema de
software. En general, los procesos ahora son compatibles con herramientas. Esto significa que los
desarrolladores de software pueden usar una variedad de herramientas de software para ayudarlos,
como sistemas de gestión de requisitos, editores de modelos de diseño, editores de programas,
herramientas de prueba automatizadas y depuradores.
Las cuatro actividades básicas del proceso de especificación, desarrollo, validación y evolución se
organizan de manera diferente en diferentes procesos de desarrollo. En el modelo de caída de agua, se
organizan en secuencia, mientras que en el desarrollo incremental se intercalan. La forma en que se
llevan a cabo estas actividades depende del tipo de software que se desarrolle, la experiencia y
competencia de los desarrolladores y el tipo de organización que desarrolla el software.
2.2.1 Especificación del software
La especificación de software o la ingeniería de requisitos es el proceso de comprender y definir qué
servicios se requieren del sistema e identificar las restricciones en la operación y el desarrollo del
sistema. La ingeniería de requisitos es una etapa particularmente crítica del proceso de software, ya
que los errores cometidos en esta etapa conducen inevitablemente a problemas posteriores en el diseño
e implementación del sistema.
Antes de que comience el proceso de ingeniería de requisitos, una empresa puede llevar a cabo un
estudio de viabilidad o de marketing para evaluar si existe o no una necesidad o un mercado para el
software y si es o no técnica y financieramente realista desarrollar el software requerido. Los estudios
de factibilidad son estudios a corto plazo, relativamente baratos, que informan la decisión de continuar
o no con un análisis más detallado.
El proceso de ingeniería de requisitos (Figura 2.4) tiene como objetivo producir un documento de
requisitos acordado que especifique un sistema que satisfaga los requisitos de las partes interesadas.
Los requisitos generalmente se presentan en dos niveles de detalle. Los usuarios finales y los clientes
necesitan una declaración de requisitos de alto nivel; los desarrolladores de sistemas necesitan una
especificación de sistema más detallada.
Machine Translated by Google
2.2 ÿ Actividades del proceso 55
Obtención y
análisis de
requisitos
Especificación
de requisitos
Validación de
requisitos
Descripciones del sistema
Requisitos del
usuario y del sistema
Figura 2.4 El
Documento de
requisitos
proceso de
ingeniería de requisitos
Hay tres actividades principales en el proceso de ingeniería de requisitos:
1. Obtención y análisis de requisitos Este es el proceso de obtener los requisitos del sistema a
través de la observación de los sistemas existentes, conversaciones con usuarios y
compradores potenciales, análisis de tareas, etc. Esto puede implicar el desarrollo de uno o
más modelos y prototipos de sistemas. Estos le ayudan a comprender el sistema que se va a
especificar.
2. Especificación de requisitos La especificación de requisitos es la actividad de traducir la
información recopilada durante el análisis de requisitos en un documento que define un
conjunto de requisitos. En este documento se pueden incluir dos tipos de requisitos. Los
requisitos del usuario son declaraciones abstractas de los requisitos del sistema para el cliente
y el usuario final del sistema; Los requisitos del sistema son una descripción más detallada de
la funcionalidad que se proporcionará.
3. Validación de requisitos Esta actividad verifica los requisitos en cuanto a realismo, consistencia e
integridad. Durante este proceso, inevitablemente se descubren errores en el documento de
requisitos. Luego debe modificarse para corregir estos problemas.
El análisis de requisitos continúa durante la definición y especificación, y surgen nuevos
requisitos a lo largo del proceso. Por lo tanto, las actividades de análisis, definición y especificación
están intercaladas.
En los métodos ágiles, la especificación de requisitos no es una actividad separada, sino que se
considera parte del desarrollo del sistema. Los requisitos se especifican informalmente para cada
incremento del sistema justo antes de que se desarrolle ese incremento. Los requisitos se especifican
de acuerdo con las prioridades del usuario. La elicitación de requisitos proviene de los usuarios que
forman parte o trabajan en estrecha colaboración con el equipo de desarrollo.
Machine Translated by Google
56 Capítulo 2 ÿ Procesos de software
Entradas de diseño
Datos
Software
Información
de la plataforma
requisitos
descripciones
Actividades de diseño
Diseño
Diseño de
arquitectonico
Base de datos
diseño
interfaz
Selección y
diseño de
componentes.
Salidas de diseño
Diseño de
Figura 2.5 Un modelo general
del proceso de diseño
Arquitectura del sistema
base de datos
Especificación
de interfaz
Descripciones
de componentes
2.2.2 Diseño e implementación de software
La etapa de implementación del desarrollo de software es el proceso de desarrollar un sistema
ejecutable para entregarlo al cliente. A veces esto involucra actividades separadas de diseño y
programación de software. Sin embargo, si se utiliza un enfoque ágil para el desarrollo, el diseño
y la implementación se intercalan, sin que se produzcan documentos de diseño formales durante
el proceso. Por supuesto, el software todavía está diseñado, pero el diseño se registra
informalmente en pizarras y cuadernos de programadores.
Un diseño de software es una descripción de la estructura del software que se implementará,
los modelos de datos y las estructuras utilizadas por el sistema, las interfaces entre los
componentes del sistema y, a veces, los algoritmos utilizados. Los diseñadores no llegan a un
diseño terminado inmediatamente, sino que desarrollan el diseño por etapas. Agregan detalles
a medida que desarrollan su diseño, con un retroceso constante para modificar diseños anteriores.
La figura 2.5 es un modelo abstracto del proceso de diseño que muestra las entradas al
proceso de diseño, las actividades del proceso y las salidas del proceso. Las actividades del
proceso de diseño están entrelazadas y son interdependientes. Constantemente se genera
nueva información sobre el diseño, y esto afecta las decisiones de diseño anteriores. Por lo
tanto, la reelaboración del diseño es inevitable.
Machine Translated by Google
2.2 ÿ Actividades del proceso 57
La mayoría de las interfaces de software con otros sistemas de software. Estos otros sistemas incluyen
el sistema operativo, la base de datos, el middleware y otros sistemas de aplicación.
Estos conforman la "plataforma de software", el entorno en el que se ejecutará el software. La información
sobre esta plataforma es una entrada esencial para el proceso de diseño, ya que los diseñadores deben
decidir cómo integrarla mejor con su entorno. Si el sistema va a procesar datos existentes, entonces la
descripción de esos datos puede incluirse en la especificación de la plataforma. De lo contrario, la
descripción de los datos debe ser una entrada al proceso de diseño para que se pueda definir la organización
de los datos del sistema.
Las actividades en el proceso de diseño varían, dependiendo del tipo de sistema que se desarrolle. Por
ejemplo, los sistemas de tiempo real requieren una etapa adicional de diseño de temporización, pero es
posible que no incluyan una base de datos, por lo que no hay un diseño de base de datos involucrado. La
Figura 2.5 muestra cuatro actividades que pueden ser parte del proceso de diseño de sistemas de información:
1. Diseño arquitectónico, donde identifica la estructura general del sistema, los componentes principales (a
veces llamados subsistemas o módulos), sus relaciones y cómo se distribuyen.
2. Diseño de base de datos, donde se diseñan las estructuras de datos del sistema y cómo se representarán
en una base de datos. Una vez más, el trabajo aquí depende de si se va a reutilizar una base de datos
existente o se va a crear una nueva base de datos.
3. Diseño de interfaz, donde define las interfaces entre los componentes del sistema.
Esta especificación de interfaz debe ser inequívoca. Con una interfaz precisa, un componente puede
ser utilizado por otros componentes sin que estos tengan que saber cómo se implementa. Una vez
que se acuerdan las especificaciones de la interfaz, los componentes pueden diseñarse y desarrollarse
por separado.
4. Selección y diseño de componentes, donde busca componentes reutilizables y, si no hay componentes
adecuados disponibles, diseña nuevos componentes de software.
El diseño en esta etapa puede ser una simple descripción de componentes con los detalles de
implementación dejados al programador. Alternativamente, puede ser una lista de cambios a realizar
en un componente reutilizable o un modelo de diseño detallado expresado en UML. A continuación, el
modelo de diseño se puede utilizar para generar automáticamente una implementación.
Estas actividades conducen a los resultados del diseño, que también se muestran en la Figura 2.5.
Para los sistemas críticos, los resultados del proceso de diseño son documentos de diseño detallados que
establecen descripciones precisas y precisas del sistema. Si se utiliza un enfoque basado en modelos
(Capítulo 5), los resultados del diseño son diagramas de diseño. Cuando se utilizan métodos ágiles de
desarrollo, los resultados del proceso de diseño pueden no ser documentos de especificación separados,
sino que pueden estar representados en el código del programa.
El desarrollo de un programa para implementar un sistema se deriva naturalmente del diseño del
sistema. Aunque algunas clases de programas, como los sistemas críticos para la seguridad, generalmente
se diseñan en detalle antes de que comience cualquier implementación, es más común que el diseño y el
desarrollo del programa se intercalen. Las herramientas de desarrollo de software se pueden utilizar para
generar un programa esqueleto a partir de un diseño. Esto incluye código para
Machine Translated by Google
58 Capítulo 2 ÿ Procesos de software
Pruebas de
Prueba de
componentes
Pruebas del sistema
clientes
Figura 2.6 Etapas de la
prueba
definir e implementar interfaces y, en muchos casos, el desarrollador solo necesita agregar detalles de
la operación de cada componente del programa.
La programación es una actividad individual, y no hay un proceso general que se siga normalmente.
Algunos programadores comienzan con componentes que entienden, los desarrollan y luego pasan a
componentes menos entendidos. Otros adoptan el enfoque opuesto, dejando los componentes familiares
para el final porque saben cómo desarrollarlos. A algunos desarrolladores les gusta definir los datos al
principio del proceso y luego utilizarlos para impulsar el desarrollo del programa; otros dejan datos sin
especificar durante el mayor tiempo posible.
Normalmente, los programadores realizan algunas pruebas del código que han desarrollado.
Esto a menudo revela defectos del programa (errores) que deben eliminarse del programa.
Encontrar y corregir defectos del programa se denomina depuración. La prueba de defectos y la
depuración son procesos diferentes. Las pruebas establecen la existencia de defectos. La depuración
se ocupa de localizar y corregir estos defectos.
Cuando está depurando, debe generar hipótesis sobre el comportamiento observable del programa
y luego probar estas hipótesis con la esperanza de encontrar la falla que causó la anomalía de salida.
Probar las hipótesis puede implicar rastrear el código del programa manualmente. Puede requerir nuevos
casos de prueba para localizar el problema. Las herramientas de depuración interactivas, que muestran
los valores intermedios de las variables del programa y un seguimiento de las sentencias ejecutadas,
suelen utilizarse para respaldar el proceso de depuración.
2.2.3 Validación del software
La validación del software o, más generalmente, la verificación y validación (V & V) tiene como objetivo
mostrar que un sistema se ajusta a su especificación y cumple con las expectativas del cliente del
sistema. La prueba del programa, donde el sistema se ejecuta utilizando datos de prueba simulados, es
la principal técnica de validación. La validación también puede implicar procesos de verificación, como
inspecciones y revisiones, en cada etapa del proceso de software, desde la definición de los requisitos
del usuario hasta el desarrollo del programa.
Sin embargo, la mayor parte del tiempo y esfuerzo de V & V se dedica a la prueba del programa.
A excepción de los programas pequeños, los sistemas no deben probarse como una sola unidad
monolítica. La figura 2.6 muestra un proceso de prueba de tres etapas en el que los componentes del
sistema se prueban individualmente y luego se prueba el sistema integrado. Para el software
personalizado, las pruebas del cliente implican probar el sistema con datos reales del cliente. Para los
productos que se venden como aplicaciones, las pruebas de los clientes a veces se denominan pruebas
beta en las que los usuarios seleccionados prueban y comentan sobre el software.
Machine Translated by Google
2.2 ÿ Actividades del proceso 59
Las etapas en el proceso de prueba son:
1. Prueba de componentes Los componentes que forman el sistema son probados por las personas que desarrollan
el sistema. Cada componente se prueba de forma independiente, sin otros componentes del sistema. Los
componentes pueden ser entidades simples como funciones o clases de objetos o pueden ser agrupaciones
coherentes de estas entidades. Las herramientas de automatización de pruebas, como JUnit para Java, que
pueden volver a ejecutar las pruebas cuando se crean nuevas versiones del componente, se utilizan
comúnmente (Koskela 2013).
2. Pruebas del sistema Los componentes del sistema se integran para crear un sistema completo.
Este proceso se ocupa de encontrar errores que resultan de interacciones imprevistas entre componentes y
problemas de interfaz de componentes. También se ocupa de demostrar que el sistema cumple con sus
requisitos funcionales y no funcionales, y de probar las propiedades emergentes del sistema. Para sistemas
grandes, este puede ser un proceso de varias etapas donde los componentes se integran para formar
subsistemas que se prueban individualmente antes de que estos subsistemas se integren para formar el
sistema final.
3. Prueba del cliente Esta es la etapa final en el proceso de prueba antes de que el sistema sea aceptado para su
uso operativo. El sistema es probado por el cliente del sistema (o cliente potencial) en lugar de con datos de
prueba simulados. Para el software personalizado, las pruebas de los clientes pueden revelar errores y
omisiones en la definición de los requisitos del sistema, porque los datos reales ejercitan el sistema de manera
diferente a los datos de prueba. Las pruebas de los clientes también pueden revelar problemas de requisitos
en los que las instalaciones del sistema no satisfacen realmente las necesidades de los usuarios o el
rendimiento del sistema es inaceptable. Para los productos, las pruebas de los clientes muestran qué tan bien
el producto de software satisface las necesidades del cliente.
Idealmente, los defectos de los componentes se descubren temprano en el proceso de prueba y los problemas
de la interfaz se encuentran cuando el sistema está integrado. Sin embargo, a medida que se descubren defectos,
el programa debe ser depurado, y esto puede requerir que se repitan otras etapas en el proceso de prueba. Los
errores en los componentes del programa, por ejemplo, pueden salir a la luz durante las pruebas del sistema. Por lo
tanto, el proceso es iterativo con información que se retroalimenta de etapas posteriores a partes anteriores del
proceso.
Normalmente, la prueba de componentes es simplemente parte del proceso normal de desarrollo.
Los programadores crean sus propios datos de prueba y prueban progresivamente el código a medida que se
desarrolla. El programador conoce el componente y por lo tanto es la mejor persona para generar casos de prueba.
Si se utiliza un enfoque incremental para el desarrollo, cada incremento debe probarse a medida que se
desarrolla, con estas pruebas basadas en los requisitos para ese incremento. En el desarrollo basado en pruebas,
que es una parte normal de los procesos ágiles, las pruebas se desarrollan junto con los requisitos antes de que
comience el desarrollo. Esto ayuda a los evaluadores y desarrolladores a comprender los requisitos y garantiza que
no haya demoras a medida que se crean los casos de prueba.
Cuando se utiliza un proceso de software dirigido por un plan (por ejemplo, para el desarrollo de sistemas
críticos), las pruebas están dirigidas por un conjunto de planes de prueba. Un equipo independiente de probadores trabaja
Machine Translated by Google
60 Capítulo 2 ÿ Procesos de software
Especificación de
Diseño de
requisitos
Especificación del sistema
Cliente
Plan de prueba
diseño de
sistemas
componentes
Plan de
Plan de prueba
prueba de
de integración
integración del sistema
Prueba de
Servicio
cliente
Código de
componente y prueba
del subsistema
Prueba de
integración del sistema
Prueba de
integración del subsistema
Figura 2.7 Fases de prueba
en un proceso de software dirigido
por un plan
de estos planes de prueba, que se han desarrollado a partir de la especificación y el diseño del sistema. La
figura 2.7 ilustra cómo los planes de prueba son el vínculo entre las actividades de prueba y desarrollo. Esto
a veces se llama el modelo V de desarrollo (gírelo de lado para ver la V). El modelo V muestra las actividades
de validación del software que corresponden a cada etapa del modelo de proceso en cascada.
Cuando un sistema se va a comercializar como un producto de software, a menudo se utiliza un proceso
de prueba llamado prueba beta. La prueba beta implica entregar un sistema a una cantidad de clientes
potenciales que aceptan usar ese sistema. Informan de los problemas a los desarrolladores del sistema. Esto
expone el producto a un uso real y detecta errores que pueden no haber sido previstos por los desarrolladores
del producto. Después de esta retroalimentación, el producto de software puede modificarse y lanzarse para
pruebas beta adicionales o venta general.
2.2.4 Evolución del software
La flexibilidad del software es una de las principales razones por las que cada vez más software se incorpora
a sistemas grandes y complejos. Una vez que se ha tomado la decisión de fabricar el hardware, es muy
costoso realizar cambios en el diseño del hardware.
Sin embargo, se pueden realizar cambios en el software en cualquier momento durante o después del
desarrollo del sistema. Incluso los cambios extensos siguen siendo mucho más económicos que los cambios
correspondientes en el hardware del sistema.
Históricamente, siempre ha habido una división entre el proceso de desarrollo de software y el proceso de
evolución del software (mantenimiento de software). La gente piensa en el desarrollo de software como una
actividad creativa en la que se desarrolla un sistema de software desde un concepto inicial hasta un sistema
de trabajo. Sin embargo, a veces piensan que el mantenimiento del software es aburrido y poco interesante.
Piensan que el mantenimiento del software es menos interesante y desafiante que el desarrollo del software
original.
Esta distinción entre desarrollo y mantenimiento es cada vez más irrelevante.
Muy pocos sistemas de software son sistemas completamente nuevos, y hace mucho más
Machine Translated by Google
2.3 ÿ Hacer frente al cambio 61
Definir los requisitos
del sistema
Figura 2.8 Evolución del
Evaluar los sistemas
Proponer cambios en
existentes
el sistema
Modificar
sistemas
Sistemas
Nuevo
existentes
sistema
sistema de software
sentido ver el desarrollo y el mantenimiento como un continuo. En lugar de dos procesos separados, es más
realista pensar en la ingeniería de software como un proceso evolutivo (Figura 2.8) donde el software cambia
continuamente durante su vida útil en respuesta a los requisitos cambiantes y las necesidades del cliente.
2.3 Hacer frente al cambio
El cambio es inevitable en todos los grandes proyectos de software. Los requisitos del sistema cambian a
medida que las empresas responden a presiones externas, competencia y cambios en las prioridades de
gestión. A medida que se dispone de nuevas tecnologías, se hacen posibles nuevos enfoques para el diseño
y la implementación. Por lo tanto, cualquiera que sea el modelo de proceso de software que se utilice, es
esencial que pueda adaptarse a los cambios en el software que se está desarrollando.
El cambio se suma a los costos de desarrollo de software porque generalmente significa que el trabajo
que se ha completado debe rehacerse. Esto se llama reelaboración. Por ejemplo, si se han analizado las
relaciones entre los requisitos de un sistema y luego se identifican nuevos requisitos, se debe repetir parte o
la totalidad del análisis de requisitos. Entonces puede ser necesario rediseñar el sistema para cumplir con
los nuevos requisitos, cambiar cualquier programa que se haya desarrollado y volver a probar el sistema.
Se pueden utilizar dos enfoques relacionados para reducir los costos de reelaboración:
1. Anticipación de cambios, donde el proceso de software incluye actividades que pueden anticipar o
predecir posibles cambios antes de que se requiera una reelaboración significativa. Por ejemplo, se
puede desarrollar un sistema prototipo para mostrar algunas características clave del sistema a los
clientes. Pueden experimentar con el prototipo y refinar sus requisitos antes de comprometerse con
altos costos de producción de software.
2. Tolerancia al cambio, donde el proceso y el software están diseñados para que los cambios se puedan
realizar fácilmente en el sistema. Esto normalmente involucra alguna forma de desarrollo incremental.
Los cambios propuestos pueden implementarse en incrementos que aún no se han desarrollado. Si
esto es imposible, es posible que solo se deba modificar un único incremento (una pequeña parte del
sistema) para incorporar el cambio.
Machine Translated by Google
62 Capítulo 2 ÿ Procesos de software
En esta sección, analizo dos formas de hacer frente al cambio y a los requisitos cambiantes del
sistema:
1. Creación de prototipos del sistema, donde una versión del sistema o parte del sistema se desarrolla
rápidamente para comprobar los requisitos del cliente y la viabilidad de las decisiones de diseño.
Este es un método de anticipación de cambios, ya que permite a los usuarios experimentar con el
sistema antes de la entrega y así refinar sus requisitos.
Por lo tanto, es probable que se reduzca el número de propuestas de cambio de requisitos
realizadas después de la entrega.
2. Entrega incremental, donde los incrementos del sistema se entregan al cliente para comentarios y
experimentación. Esto admite tanto la evitación del cambio como la tolerancia al cambio. Evita el
compromiso prematuro con los requisitos para todo el sistema y permite incorporar cambios en
incrementos posteriores a un costo relativamente bajo.
La noción de refactorización, es decir, mejorar la estructura y organización de un programa, también
es un mecanismo importante que respalda la tolerancia al cambio. Hablo de esto en el Capítulo 3
(Métodos ágiles).
2.3.1 Prototipos
Un prototipo es una versión temprana de un sistema de software que se utiliza para demostrar
conceptos, probar opciones de diseño y obtener más información sobre el problema y sus posibles
soluciones. El desarrollo rápido e iterativo del prototipo es esencial para que los costos estén controlados
y las partes interesadas del sistema puedan experimentar con el prototipo en una etapa temprana del
proceso de software.
Un prototipo de software se puede utilizar en un proceso de desarrollo de software para ayudar
anticipar los cambios que puedan ser necesarios:
1. En el proceso de ingeniería de requisitos, un prototipo puede ayudar con la obtención
ción y validación de los requisitos del sistema.
2. En el proceso de diseño del sistema, se puede utilizar un prototipo para explorar soluciones de
software y en el desarrollo de una interfaz de usuario para el sistema.
Los prototipos del sistema permiten a los usuarios potenciales ver qué tan bien el sistema respalda
su trabajo. Pueden obtener nuevas ideas para los requisitos y encontrar áreas de fortaleza y debilidad
en el software. A continuación, pueden proponer nuevos requisitos del sistema. Además, a medida que
se desarrolla el prototipo, puede revelar errores y omisiones en los requisitos del sistema. Una
característica descrita en una especificación puede parecer clara y útil.
Sin embargo, cuando esa función se combina con otras funciones, los usuarios a menudo descubren
que su vista inicial era incorrecta o incompleta. La especificación del sistema puede entonces modificarse
para reflejar el cambio en la comprensión de los requisitos.
Machine Translated by Google
2.3 ÿ Hacer frente al cambio 63
Establecer
prototipo
de objetivos
plan de
Figura 2.9 Desarrollo de
prototipos
Definir
funcionalidad
prototipo
Definición
de esquema
Desarrollar
Evaluar
prototipo
prototipo
Prototipo
Reporte de
ejecutable
evaluacion
prototipos
Se puede usar un prototipo de sistema mientras se diseña el sistema para llevar a cabo experimentos
de diseño para comprobar la viabilidad de un diseño propuesto. Por ejemplo, el diseño de una base de
datos puede crearse un prototipo y probarse para verificar que admita un acceso eficiente a los datos
para las consultas de los usuarios más comunes. La creación rápida de prototipos con la participación
del usuario final es la única forma sensata de desarrollar interfaces de usuario. Debido a la naturaleza
dinámica de las interfaces de usuario, las descripciones textuales y los diagramas no son lo
suficientemente buenos para expresar los requisitos y el diseño de la interfaz de usuario.
En la figura 2.9 se muestra un modelo de proceso para el desarrollo de prototipos. Los objetivos de
la creación de prototipos deben ser explícitos desde el inicio del proceso. Estos pueden ser para
desarrollar la interfaz de usuario, desarrollar un sistema para validar los requisitos funcionales del sistema
o desarrollar un sistema para demostrar la aplicación a los gerentes. Un mismo prototipo normalmente
no puede cumplir todos los objetivos. Si los objetivos no se declaran, la gerencia o los usuarios finales
pueden malinterpretar la función del prototipo. En consecuencia, es posible que no obtengan los
beneficios que esperaban del desarrollo del prototipo.
La siguiente etapa en el proceso es decidir qué poner y, quizás más importante, qué dejar fuera del
sistema prototipo. Para reducir los costos de creación de prototipos y acelerar el cronograma de entrega,
puede dejar algunas funciones fuera del prototipo. Puede decidir relajar los requisitos no funcionales,
como el tiempo de respuesta y la utilización de la memoria. El manejo y la gestión de errores pueden
ignorarse a menos que el objetivo del prototipo sea establecer una interfaz de usuario. Los estándares
de confiabilidad y calidad del programa pueden verse reducidos.
La etapa final del proceso es la evaluación del prototipo. Durante esta etapa se debe prever la
capacitación de los usuarios, y los objetivos del prototipo se deben utilizar para derivar un plan de
evaluación. Los usuarios potenciales necesitan tiempo para sentirse cómodos con un nuevo sistema y
adaptarse a un patrón normal de uso. Una vez que utilizan el sistema con normalidad, descubren errores
y omisiones en los requisitos. Un problema general con la creación de prototipos es que los usuarios
pueden no usar el prototipo de la misma manera que usan el sistema final. Los probadores de prototipos
pueden no ser típicos de los usuarios del sistema. Es posible que no haya suficiente tiempo para capacitar
a los usuarios durante la evaluación del prototipo. Si el prototipo es lento, los evaluadores pueden ajustar
su forma de trabajar y evitar aquellas características del sistema que tienen tiempos de respuesta lentos.
Cuando se les proporcione una mejor respuesta en el sistema final, podrán utilizarlo de forma diferente.
Machine Translated by Google
64 Capítulo 2 ÿ Procesos de software
Definir los requisitos
del esquema
Asignar requisitos a
incrementos
Arquitectura del
sistema de diseño
Desarrollar incremento
del sistema
¿Sistema
incompleto?
Validar
incremento
Integrar
incremento
Validar
sistema
Implementar incremento
¿Sistema
completo?
Figura 2.10
Sistema final
Entrega incremental
2.3.2 Entrega incremental
La entrega incremental (Figura 2.10) es un enfoque para el desarrollo de software donde algunos
de los incrementos desarrollados se entregan al cliente y se implementan para su uso en su
entorno de trabajo. En un proceso de entrega incremental, los clientes definen cuáles de los
servicios son más importantes y cuáles son menos importantes para ellos. A continuación, se
define una serie de incrementos de entrega, y cada incremento proporciona un subconjunto de
la funcionalidad del sistema. La asignación de servicios a incrementos depende de la prioridad
del servicio, con los servicios de mayor prioridad implementados y entregados primero.
Una vez que se han identificado los incrementos del sistema, se definen en detalle los
requisitos para los servicios que se entregarán en el primer incremento y se desarrolla ese
incremento. Durante el desarrollo, se pueden realizar más análisis de requisitos para incrementos
posteriores, pero no se aceptan cambios de requisitos para el incremento actual.
Una vez que se completa y entrega un incremento, se instala en el entorno de trabajo normal
del cliente. Pueden experimentar con el sistema y esto les ayuda a aclarar sus requisitos para
posteriores incrementos del sistema. A medida que se completan nuevos incrementos, se
integran con los incrementos existentes para que la funcionalidad del sistema mejore con cada
incremento entregado.
La entrega incremental tiene una serie de ventajas:
1. Los clientes pueden usar los primeros incrementos como prototipos y adquirir experiencia que
informe sus requisitos para posteriores incrementos del sistema. A diferencia de los
prototipos, estos son parte del sistema real, por lo que no hay reaprendizaje cuando el
sistema completo está disponible.
2. Los clientes no tienen que esperar hasta que se entregue todo el sistema antes de que puedan
obtener valor de él. El primer incremento satisface sus requisitos más críticos, por lo que
pueden usar el software de inmediato.
3. El proceso mantiene los beneficios del desarrollo incremental en el sentido de que debería ser
relativamente fácil incorporar cambios al sistema.
Machine Translated by Google
2.4 ÿ Mejora de procesos 65
4. Dado que los servicios de mayor prioridad se entregan primero y luego se integran, los servicios del
sistema más importantes reciben la mayoría de las pruebas. Esto significa que es menos probable
que los clientes encuentren fallas de software en las partes más importantes del sistema.
Sin embargo, hay problemas con la entrega incremental. En la práctica, solo funciona en situaciones
en las que se está introduciendo un sistema completamente nuevo y los evaluadores del sistema tienen
tiempo para experimentar con el nuevo sistema. Los problemas clave con este enfoque son:
1. La entrega iterativa es problemática cuando el nuevo sistema pretende reemplazar un sistema existente.
Los usuarios necesitan toda la funcionalidad del sistema antiguo y, por lo general, no están dispuestos
a experimentar con un nuevo sistema incompleto. A menudo, no es práctico utilizar los sistemas
antiguo y nuevo juntos, ya que es probable que tengan diferentes bases de datos e interfaces de
usuario.
2. La mayoría de los sistemas requieren un conjunto de instalaciones básicas que son utilizadas por
diferentes partes del sistema. Como los requisitos no se definen en detalle hasta que se implementa
un incremento, puede ser difícil identificar las instalaciones comunes que necesitan todos los incrementos.
3. La esencia de los procesos iterativos es que la especificación se desarrolla junto con el software. Sin
embargo, esto entra en conflicto con el modelo de adquisición de muchas organizaciones, donde la
especificación completa del sistema es parte del contrato de desarrollo del sistema. En el enfoque
incremental, no existe una especificación completa del sistema hasta que se especifica el incremento
final. Esto requiere una nueva forma de contrato, que los grandes clientes, como las agencias
gubernamentales, pueden encontrar difícil de acomodar.
Para algunos tipos de sistemas, el desarrollo y la entrega incrementales no son el mejor enfoque. Estos
son sistemas muy grandes en los que el desarrollo puede implicar equipos que trabajan en diferentes
ubicaciones, algunos sistemas integrados en los que el software depende del desarrollo del hardware y
algunos sistemas críticos en los que se deben analizar todos los requisitos para comprobar si hay
interacciones que puedan comprometer la seguridad del usuario. sistema.
Estos grandes sistemas, por supuesto, sufren los mismos problemas de requisitos inciertos y
cambiantes. Por lo tanto, para abordar estos problemas y obtener algunos de los beneficios del desarrollo
incremental, se puede desarrollar un prototipo de sistema y usarlo como plataforma para experimentos con
los requisitos y el diseño del sistema. Con la experiencia adquirida con el prototipo, se pueden acordar los
requisitos definitivos.
2.4 Mejora de procesos
Hoy en día, existe una demanda constante por parte de la industria de software mejor y más barato, que
debe entregarse en plazos cada vez más ajustados. En consecuencia, muchas empresas de software han
recurrido a la mejora de procesos de software como una forma de mejorar la
Machine Translated by Google
66 Capítulo 2 ÿ Procesos de software
Medida
Cambio
Analizar
Figura 2.11 El ciclo de
mejora de procesos
calidad de su software, reduciendo costos o acelerando sus procesos de desarrollo. La mejora de
procesos significa comprender los procesos existentes y cambiar estos procesos para aumentar la
calidad del producto y/o reducir los costos y el tiempo de desarrollo. Cubro temas generales de
medición de procesos y mejora de procesos en detalle en el Capítulo 26 de la web.
Se utilizan dos enfoques bastante diferentes para la mejora y el cambio de procesos:
1. El enfoque de madurez de procesos, que se ha centrado en mejorar la gestión de procesos y
proyectos e introducir buenas prácticas de ingeniería de software en una organización. El nivel
de madurez del proceso refleja la medida en que se han adoptado buenas prácticas técnicas
y de gestión en los procesos de desarrollo de software organizacional. Los objetivos principales
de este enfoque son mejorar la calidad del producto y la previsibilidad del proceso.
2. El enfoque ágil, que se ha centrado en el desarrollo iterativo y la reducción de los gastos
generales en el proceso de software. Las características principales de los métodos ágiles son
la entrega rápida de funcionalidad y la capacidad de respuesta a los requisitos cambiantes del
cliente. La filosofía de mejora aquí es que los mejores procesos son aquellos con los gastos
generales más bajos y los enfoques ágiles pueden lograr esto.
Describo los enfoques ágiles en el Capítulo 3.
Las personas entusiastas y comprometidas con cada uno de estos enfoques generalmente son
escépticas sobre los beneficios del otro. El enfoque de la madurez del proceso tiene sus raíces en
el desarrollo impulsado por un plan y, por lo general, requiere mayores “gastos generales”, en el
sentido de que se introducen actividades que no son directamente relevantes para el desarrollo del
programa. Los enfoques ágiles se centran en el código que se está desarrollando y minimizan
deliberadamente la formalidad y la documentación.
El proceso general de mejora del proceso que subyace al enfoque de madurez del proceso es
un proceso cíclico, como se muestra en la Figura 2.11. Las etapas en este proceso son:
1. Medición del proceso Mide uno o más atributos del proceso o producto de software. Estas
medidas forman una línea de base que le ayuda a decidir si
Machine Translated by Google
2.4 ÿ Mejora de procesos 67
las mejoras en los procesos han sido efectivas. A medida que introduce mejoras, vuelve a medir
los mismos atributos, que con suerte habrán mejorado de alguna manera.
2. Análisis del proceso Se evalúa el proceso actual y se identifican las debilidades y los cuellos de
botella del proceso. Los modelos de proceso (a veces llamados mapas de proceso) que
describen el proceso pueden desarrollarse durante esta etapa. El análisis puede enfocarse
considerando características del proceso tales como rapidez y robustez.
3. Cambio de proceso Se proponen cambios de proceso para abordar algunas de las debilidades de
proceso identificadas. Estos se introducen y el ciclo se reanuda para recopilar datos sobre la
efectividad de los cambios.
Sin datos concretos sobre un proceso o el software desarrollado utilizando ese proceso, es
imposible evaluar el valor de la mejora del proceso. Sin embargo, es poco probable que las empresas
que inician el proceso de mejora de procesos tengan datos de proceso disponibles como referencia
de mejora. Por lo tanto, como parte del primer ciclo de cambios, es posible que deba recopilar datos
sobre el proceso de software y medir las características del producto de software.
La mejora de procesos es una actividad a largo plazo, por lo que cada una de las etapas del
proceso de mejora puede durar varios meses. También es una actividad continua ya que,
independientemente de los nuevos procesos que se introduzcan, el entorno empresarial cambiará y
los nuevos procesos tendrán que evolucionar para tener en cuenta estos cambios.
La noción de madurez del proceso se introdujo a fines de la década de 1980 cuando el Instituto
de Ingeniería de Software (SEI) propuso su modelo de madurez de la capacidad del proceso
(Humphrey 1988). La madurez de los procesos de una empresa de software refleja la gestión de
procesos, la medición y el uso de buenas prácticas de ingeniería de software en la empresa. Esta
idea se introdujo para que el Departamento de Defensa de EE. UU. pudiera evaluar la capacidad de
ingeniería de software de los contratistas de defensa, con miras a limitar los contratos a aquellos
contratistas que habían alcanzado el nivel requerido de madurez del proceso. Se propusieron cinco
niveles de madurez del proceso. como se muestra en la Figura 2.12. Estos han evolucionado y se
han desarrollado durante los últimos 25 años (Chrissis, Konrad y Shrum 2011), pero las ideas
fundamentales del modelo de Humphrey siguen siendo la base de la evaluación de la madurez del
proceso de software.
Los niveles en el modelo de madurez del proceso son:
1. Inicial Se cumplen los objetivos asociados con el área de proceso y para todos los procesos se
establece explícitamente el alcance del trabajo a realizar y se comunica a los miembros del
equipo.
2. Gestionado En este nivel, se cumplen los objetivos asociados con el área de proceso y existen
políticas organizacionales que definen cuándo se debe utilizar cada proceso. Debe haber planes
de proyecto documentados que definan los objetivos del proyecto. Los procedimientos de control
de procesos y gestión de recursos deben estar en funcionamiento en toda la institución.
3. Definido Este nivel se enfoca en la estandarización organizacional y el despliegue de procesos.
Cada proyecto tiene un proceso gestionado que se adapta a los requisitos del proyecto a partir
de un conjunto definido de procesos organizacionales. Los activos del proceso y las mediciones
del proceso deben recopilarse y utilizarse para futuras mejoras del proceso.
Machine Translated by Google
68 Capítulo 2 ÿ Procesos de software
Nivel 5
optimizando
Nivel 4
Gestionado
cuantitativamente
Nivel 3
definido
Nivel 2
Administrado
Nivel 1
Figura 2.12 Niveles de
Inicial
madurez de la capacidad
4. Administrado cuantitativamente En este nivel, existe la responsabilidad organizacional de utilizar
métodos estadísticos y otros métodos cuantitativos para controlar los subprocesos. Es decir,
las mediciones recopiladas de procesos y productos deben usarse en la gestión de procesos.
5. Optimización En este nivel más alto, la organización debe utilizar las mediciones del proceso y
del producto para impulsar la mejora del proceso. Se deben analizar las tendencias y adaptar
los procesos a las cambiantes necesidades del negocio.
El trabajo sobre los niveles de madurez de los procesos ha tenido un gran impacto en la industria
del software. Enfocó la atención en los procesos y prácticas de ingeniería de software que se
utilizaron y condujo a mejoras significativas en la capacidad de ingeniería de software. Sin embargo,
hay demasiados gastos generales en la mejora de procesos formales para las pequeñas empresas,
y la estimación de la madurez con procesos ágiles es difícil. En consecuencia, solo las grandes
empresas de software ahora utilizan este enfoque centrado en la madurez para la mejora del
proceso de software.
Puntos clave
ÿ Los procesos de software son las actividades involucradas en la producción de un sistema de software. proceso de software
los modelos son representaciones abstractas de estos procesos.
ÿ Los modelos de procesos generales describen la organización de los procesos de software. Ejemplos de estos
los modelos generales incluyen el modelo en cascada, el desarrollo incremental y la configuración e integración
de componentes reutilizables.
Machine Translated by Google
Capítulo 2 ÿ Sitio web 69
ÿ La ingeniería de requisitos es el proceso de desarrollar una especificación de software. Las especificaciones están
destinadas a comunicar las necesidades del sistema del cliente a los desarrolladores del sistema.
ÿ Los procesos de diseño e implementación se ocupan de transformar una especificación de requisitos en un sistema
de software ejecutable.
ÿ La validación del software es el proceso de comprobar que el sistema se ajusta a su especificación y
que satisfaga las necesidades reales de los usuarios del sistema.
ÿ La evolución del software tiene lugar cuando usted cambia los sistemas de software existentes para cumplir
con los nuevos requisitos. Los cambios son continuos y el software debe evolucionar para seguir siendo útil.
ÿ Los procesos deben incluir actividades para hacer frente al cambio. Esto puede implicar una fase de creación de
prototipos que ayude a evitar malas decisiones sobre los requisitos y el diseño. Los procesos se pueden estructurar
para el desarrollo iterativo y la entrega, de modo que se puedan realizar cambios sin interrumpir el sistema en su conjunto.
ÿ La mejora de procesos es el proceso de mejorar los procesos de software existentes para mejorar
calidad del producto, reducir los costos de desarrollo o reducir el tiempo de desarrollo. Es un proceso cíclico que implica la
medición, el análisis y el cambio del proceso.
Otras lecturas
"Modelos de proceso en ingeniería de software". Esta es una excelente descripción general de una amplia gama de modelos de
procesos de ingeniería de software que se han propuesto. (W. Scacchi, Encyclopaedia of Software Engineering, ed. JJ Marciniak, John
Wiley & Sons, 2001) http://www.ics.uci.edu/~wscacchi/ Papers/SE-Encyc/Process-Models-SE-Encyc .pdf
Mejora de Procesos de Software: Resultados y Experiencia de Campo. Este libro es una colección de artículos que se centran en
estudios de casos de mejora de procesos en varias pequeñas y medianas empresas noruegas. También incluye una buena introducción
a los aspectos generales de la mejora de procesos.
(Conradi, R., Dybå, T., Sjøberg, D. y Ulsund, T. (eds.), Springer, 2006).
"Modelos y metodologías del ciclo de vida del desarrollo de software". Esta publicación de blog es
un resumen sucinto de varios modelos de procesos de software que se han propuesto y utilizado.
Discute las ventajas y desventajas de cada uno de estos modelos (M. Sami, 2012). http://
melsatar.wordpress. com/2012/03/15/software-desarrollo-ciclo-de-vida-modelos-y-metodologías/
Sitio web
Diapositivas de PowerPoint para este capítulo:
www.pearsonglobaleditions.com/Sommerville
Enlaces a videos de apoyo:
http://software-engineering-book.com/videos/software-engineering/
Machine Translated by Google
70 Capítulo 2 ÿ Procesos de software 70 Capítulo 2 ÿ Procesos de software
Ejercicios
2.1. Sugerir el modelo de proceso de software genérico más apropiado que podría usarse como base
para gestionar el desarrollo de los siguientes sistemas. Explique su respuesta de acuerdo al tipo de sistema que se está
desarrollando:
Un sistema para controlar el frenado antibloqueo en un automóvil.
Un sistema de realidad virtual para apoyar el mantenimiento del software
Un sistema de contabilidad universitario que reemplaza un sistema existente
Un sistema interactivo de planificación de viajes que ayuda a los usuarios a planificar viajes con el menor
impacto ambiental
2.2. El desarrollo de software incremental podría usarse de manera muy efectiva para clientes que no tienen una idea clara
sobre los sistemas necesarios para sus operaciones. Conversar.
2.3. Considere el modelo de proceso de integración y configuración que se muestra en la Figura 2.3. Explique por qué es
fundamental repetir la actividad de ingeniería de requisitos en el proceso.
2.4. Sugiera por qué es importante hacer una distinción entre desarrollar los requisitos del usuario y desarrollar los requisitos
del sistema en el proceso de ingeniería de requisitos.
2.5. Utilizando un ejemplo, explique por qué las actividades de diseño del diseño arquitectónico, el diseño de bases de datos,
el diseño de interfaces y el diseño de componentes son interdependientes.
2.6. Explique por qué las pruebas de software siempre deben ser una actividad incremental y por etapas. ¿Son los
programadores las mejores personas para probar los programas que han desarrollado?
2.7. Imagine que un gobierno quiere un programa de software que ayude a realizar un seguimiento de la utilización de los
vastos recursos minerales del país. Aunque los requisitos planteados por el gobierno no estaban muy claros, se
encargó a una empresa de software el desarrollo de un prototipo. El gobierno encontró el prototipo impresionante y
pidió que se ampliara para que fuera el sistema real que se utilizaría. Analice los pros y los contras de adoptar este
enfoque.
2.8. Ha desarrollado un prototipo de un sistema de software y su gerente está muy impresionado con él. Ella propone que se
ponga en uso como un sistema de producción, con nuevas funciones agregadas según sea necesario. Esto evita el
gasto de desarrollo del sistema y hace que el sistema sea inmediatamente útil. Escriba un breve informe para su gerente
que explique por qué los sistemas de prototipos no deberían usarse normalmente como sistemas de producción.
2.9. Sugiera dos ventajas y dos desventajas del enfoque de evaluación y mejora de procesos que se incorpora en el marco
de Madurez de Capacidad de SEI.
2.10. Históricamente, la introducción de la tecnología ha provocado cambios profundos en el mercado laboral y, al menos
temporalmente, ha desplazado a personas de sus puestos de trabajo. Analice si es probable que la introducción de una
amplia automatización de procesos tenga las mismas consecuencias para los ingenieros de software. Si no cree que lo
hará, explique por qué no. Si cree que reducirá las oportunidades laborales, ¿es ético que los ingenieros afectados se
resistan pasiva o activamente a la introducción de esta tecnología?
Machine Translated by Google
Capítulo 2 ÿ Referencias 71
Referencias
Abrial, JR 2005. El Libro B: Asignación de Programas a Significados. Cambridge, Reino Unido: Cambridge
University Press.
. 2010. Modelado en Event-B: Ingeniería de Sistemas y Software. Cambridge, Reino Unido: Cambridge
University Press.
Böhm, BW (1988). "Un modelo en espiral de desarrollo y mejora de software". Computadora IEEE, 21 (5), 61–72.
doi:10.1145/12944.12948
Boehm, BW y R. Turner. 2004. "Equilibrio de la agilidad y la disciplina: evaluación e integración de métodos ágiles
y basados en planes". En 26 Int. Conf sobre Ingeniería de Software, Edimburgo, Escocia. doi:10.1109/
ICSE.2004.1317503.
Chrissis, MB, M. Konrad y S. Shrum. 2011. CMMI para el desarrollo: Directrices para la integración de procesos
y la mejora de productos, 3.ª ed. Boston: Addison-Wesley.
Humphrey, WS 1988. "Caracterización del proceso de software: un marco de madurez". Software IEEE 5 (2): 73–79.
doi:10.1109/2.59.
Koskela, L. 2013. Pruebas unitarias efectivas: una guía para desarrolladores de Java. Greenwich, CT:
Publicaciones de Manning.
Krutchen, P. 2003. El proceso unificado racional: una introducción, 3.ª ed. Reading, MA: Addison-Wesley.
Royce, WW 1970. “Gestión del desarrollo de grandes sistemas de software: conceptos y técnicas”. En IEEE
WESTCON, 1–9. Los Ángeles, California.
Wheeler, W. y J. White. 2013. Primavera en la práctica. Greenwich, CT: Publicaciones de Manning.