EL PROCESO: UNA

VISION GENERAL.
Contenido
2. EL PROCESO: UNA VISION GENERAL.....................................................................................3
2.1. Ingeniería del software: una tecnología estratificada.......................................................3
2.2. Marco de trabajo para el proceso....................................................................................3
2.3. Integración del modelo de capacidad de madurez (IMCM)..............................................5
2.4. Patrones del proceso........................................................................................................8
2.5. Evaluación del proceso.....................................................................................................9
2.6. Modelos de procesos personales y en equipo..................................................................9
2.6.1. Proceso de software personal (PSP).............................................................................9
2.6.2. Proceso de software en equipo (PSE).........................................................................10
2.7. Tecnología del proceso...................................................................................................10
2.8. Productor y proceso.......................................................................................................11
2.9. Resumen.........................................................................................................................11
3. Referencias.........................................................................................................................11

Página 2

Ingeniería de Software I
 2. EL PROCESO: UNA VISION GENERAL.

En un fascinante libro que ofrece la visión de un economista sobre el software y la ingeniería del
software, Howard Baetjer, Jr. Debido a que el software, como cualquier capital, es conocimiento
materializado, y dado que el conocimiento de un inicio es disperso, tácito, latente y en gran medida es
incompleto, el desarrollo de software es un proceso de aprendizaje social. Es un proceso iterativo en el
que la herramienta en evolución sirve como un medio para la comunicación, en el cual cada nueva etapa
del diálogo de logra obtener más conocimiento útil de las personas implicadas. De hecho, la construcción
del software de computadora es un proceso iterativo de aprendizaje, y el resultado, hay algo que Baetjer
llamaría «el capital del software», es una materialización del conocimiento por recolectado, depurado y
organizado conforme el proceso estuvo en ejecución. Un proceso de software define el enfoque que sea
adoptar mientras el software estar en desarrollo. Pero la ingeniería de software también abarca las
tecnologías de que requiere el proceso.

¿Qué es? Cuando se trabajan para construir un producto o ¿Cuáles son los pasos? En detalle, el proceso que se adopte
sistema es importante seguir una serie de pasos predecibles: depende del software que se está construyendo. Un proceso
una especie de mapa de caracteres que ayude a crear un puede ser apropiado para crear un software para un sistema de
resultado de alta calidad y a tiempo. El mapa de carreteras que aeronáutica, mientras que un proceso distinto por completo
debe seguir se llama proceso de software. sería el indicado para la creación de un sistema web.

¿Quién lo hace? Los ingenieros de software y sus jefes ¿Cuál es el producto obtenido? Desde el punto de vista del
adaptan el proceso a sus necesidades y después que los siguen. ingeniero de software, los productos obtenidos son los
Además, la gente que ya ha solicitado el software tiene una programas, documentos y datos que se producen como
función que desempeñan en el proceso de definirlo, construido consecuencia de las actividades y tareas definidas por el
y probarlo. proceso.

¿Porque es importante? Porque ofrece de estabilidad, control ¿Cómo puedo estar seguro de que lo he hecho
y organización a una actividad que puede volverse caótica si no correctamente? Existen muchos mecanismos de evaluación
se controla. Sin embargo, un enfoque de ingeniería de software del proceso de software que permiten a las organizaciones de
moderno debe de ser “ágil” debe requerir sólo aquellas terminar la “madurez” el proceso de software. No obstante,
actividades, controles y documentación es apropiados para el que la calidad, el tiempo requerido, la viabilidad a largo plazo
equipo del proyecto y el producto que ha de producirse. del producto que se construye son los mejores indicadores de
la eficacia del producto que se utiliza.

1.

2.

2.1. Ingeniería del software: una tecnología estratificada.

El establecimientos y buzo de principios sólidos de la ingeniería para obtener económicamente un

software confiable y que funcione el modo eficiente en máquinas reales. Casi cualquier lector se sentiría
tentado a sumar otras ideas a esta definición. No obstante, que la definición de Bauer ofrece una idea
básica. Que se requiere para crear programas de computadora que funcionen de manera eficiente no sólo
en una, sino en varias máquinas reales en diferentes estas interrogantes continúan siendo un reto para los
ingenieros de software.

2.2. Marco de trabajo para el proceso.

Un marco de trabajo establece la base para un proceso de software completo al identificar un número
Página 3

pequeño de actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su
tamaño complejidad. Además, el marco de trabajo del proceso abarca un conjunto de actividades
sombrilla aplicable a lo largo del proceso de software. El siguiente marco de trabajo genérico del proceso
Ingeniería de Software I
se puede aplicar en la inmensa mayoría de los proyectos de software. Esta actividad establece un plan para
el trabajo de la ingeniería del software. Describe las tareas técnicas que deben realizarse, los riesgos
probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un
programa de trabajo. Esta actividad abarca la creación de modelos que permiten al desarrollador y el
cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos. Esta actividad
combina la generación del código y la relación de pruebas necesarias para descubrir de errores en el
código. El software se entrega al cliente, quien evalúa el producto recibido y proporciona información
basada en la evaluación. Estas cinco actividades genéricas del marco de trabajo son útiles durante el
desarrollo de programas pequeños, la creación de grandes aplicaciones en la red, y en la ingeniería del
sistema basado en computadoras grandes y complejas. Los detalles del proceso del software serán muy
diferentes en cada caso, pero las actividades dentro del marco permanecerán iguales. El análisis abarca un
conjunto de tareas de trabajo que conducen a la creación del modelo de análisis. El diseño abarca tareas de
trabajo que crean un modelo de diseño. El conjunto de tareas que mejor se ajuste a las necesidades del
proyecto y las características del equipo es el que se escoge al final. Esto implica que una acción de la
ingeniería del software se puede adaptar a las necesidades específicas del proyecto de software y a las
características del equipo del proyecto. El marco de trabajo descrito en la visión General de la ingeniería
de software lo completar una serie de actividades sombrilla.
Las actividades sombrillas se aplican durante el proceso del software y se tratan con detalle en capítulos
posteriores de este texto. Todos los modelos de proceso se caracterizan dentro del marco del proceso
mostrado en la figura 2.2. La aplicación inteligente de cualquier modelo de proceso del software debe
reconocer que la adaptación es esencial para el éxito de esta actividad. El grado en el cual las tareas de
trabajo están definidas dentro de cada actividad del marco de trabajo. La forma en la que se aplican las
actividades de aseguramiento de la calidad. La manera en la que se aplican las actividades de
aseguramiento y control. El grado General de detalle y el rigor con el que se describe el proceso. El grado
en el que los clientes están comprometidos con el proyecto.

El grado de autonomía otorgado al equipo del proyecto de software. Los modelos de proceso que
enfatizan la definición, la identificación y la aplicación detallada de las actividades del proceso han sido
aplicados dentro de la comunidad de la ingeniería del software en los últimos 30 años. La aplicación de
estos modelos prescritos intenta mejorar la calidad del sistema, hacer que los proyectos sean más
manejables, que las fechas de entrega y los costos sean predecibles, y guiar a los equipos de ingenieros de
software mientras realizan el trabajo que requiere construir un sistema. Sea los modelos prescriptivos se
aplican en forma dogmática y sin ninguna adaptación, estos pueden incrementar el grado de burocracia
asociada con la construcción de sistemas basados en computadoras, y de manera inadvertida crear
dificultades para los desarrolladores y los clientes.

En años recientes se han propuesto modelos de proceso que subrayan la agilidad del proyecto y siguen un
conjunto de principios, los cuales conducen a un enfoque más informal para el proceso del software. Estos
modelos Ágiles del proceso resaltan la manejabilidad y adaptabilidad. Esta pregunta ha ocasionado un
debate emocional entre los ingenieros de software y se abordará en el capítulo 4.
Página 4

Conjunto de tareas. 2. Entrevistar a cada uno de los clientes, por separado,

Ingeniería de Software I
 para determinar de manera General sus deseos y
Un conjunto de tareas define el trabajo real que debe realizarse necesidades.
para cumplir los objetivos de una acción de ingeniería del 3. Elaborar una lista preliminar de las funciones y
software. Por ejemplo, la recopilación de requisitos es una características basadas en la información que
acción importante de la ingeniería del software que ocurre ofrezcan los clientes.
durante la actividad de comunicación. La meta de la reunión de 4. Acero un programa de reuniones para recopilar los
requisitos es entender que desean los distintos clientes del requisitos.
software que se va a construir. 5. Producir escenarios informales de los usuarios
como parte de cada reunión.
6. Refinar escenarios de los usuarios con base en el
Para un proyecto pequeño, al parecer a simple, el conjunto de intercambio de información con los clientes.
tareas para la recopilación de requisitos puede ser como se 7. Elaborar una lista revisada de los requisitos de los
enumera a continuación: clientes.
8. Elaborar una lista revisada de los requisitos de los
1. Acero una lista de los clientes para el proyecto. clientes.
2. Invitar a todos los clientes a una reunión informal. 9. Utilizar técnicas de despliegue de funciones de
3. Pedir a cada cliente que haga una lista de calidad para jerarquizar los requisitos.
características y funciones requeridas. 10. Empaquetar los requisitos para que puedan
4. Establecer un debate sobre los requisitos y elaborar entregarse de manera incremental.
una lista final. 11. Observar las restricciones que serán puestas en el
5. Priorizar los requisitos. sistema.
6. Advertido las arias de incertidumbre. 12. Debatir métodos para validar el sistema.

Para cada proyecto de software mayor y más complejo, se Ambos conjuntos de tareas consiguen la recopilación de
requerirá un conjunto diferente de tareas. Este puede incluir la requisitos, pero son muy diferentes en cuanto profundidad y
siguiente lista: formalidad. El equipo de software elige el conjunto de tareas
que permite alcanzar la meta de cada actividad del proceso y
acción de ingeniería del software que mantenga la calidad y
1. Hacer una lista de los clientes para el proyecto.
agilidad.

2.3. Integración del modelo de capacidad de madurez (IMCM).

El instituto de ingeniería del software ha desarrollado un modelo completo de un amplio proceso basado
en un conjunto de capacidades de software y de sistemas que deben estar presentes conforme las
organizaciones alcanzan diferentes grados de capacidad y madurez del proceso. El SEI sostiene que para
lograr estas capacidades una organización debe de crear un modelo de proceso que se ajuste a las
directrices establecidas por la integración del modelo de capacidad de madurez Como un modelo
discreto. El modelo continuo IMCM describe un proceso en dos dimensiones, como se ilustra en la figura
2.3. Cada haría del proceso. Además, todo el trabajo asociado con el aria de procesos se ajusta a una
política organizacional definida; toda la gente que ejecuta el trabajo tiene acceso a recursos adecuados
para realizar su labor; los clientes están implicados de manera activa en el área de proceso, cuando éstos
se requieren; todas las áreas de trabajo y productos están monitoreados, controlados y revisados; y son
evaluados en apego a la descripción del proceso.

Definido. Todos los criterios del nivel ii se han cumplido. Además, el proceso está adaptado al conjunto
de procesos estándar de la organización de acuerdo con las políticas de adaptación de esta misma,  y
contribuye a la información de los productos de trabajo, mediciones y otras mejorías del proceso para
lagos activos del proceso organizacional. Las metas específicas establecen las características que deben
existir para que las actividades implicadas por un aria de proceso sean efectivas.  Las prácticas específicas
convierten en una meta en un conjunto de actividades relacionadas con el proceso. Por ejemplo, la
planeación del proyecto es una de las ocho varias del proceso definidas por la IMCM para la categoría de
gestión del proyecto. Además de las metas y prácticas específicas, la IMCM también define una serie de
cinco metas genéricas y prácticas relacionadas con cada aria del proceso. Cada una de las metas genéricas
corresponde a uno de los cinco niveles de capacidad. Por lo tanto, para lograr un nivel de capacidad
particular se debe alcanzar la meta genérica para ese nivel y las prácticas genéricas que corresponden a esa
meta.
Página 5

Ingeniería de Software I
ME 1 establecer estimaciones.
PE 1.1-1 estimar el alcance del proyecto.
PE 1.2-1 establecer estimaciones para los atributos del producto y las tareas del trabajo.
PE 1.3-1 definir el ciclo de vida del proyecto.
PE 1.4-1 de terminar estimaciones de esfuerzo y costo.

ME 2 desarrollar un plan de proyecto.

PE 2.1 -1 Establecer el presupuesto y el programa.
PE 2.2 -1 identificar los riesgos del proyecto.
PE 2.3 -1 planear la gestión de los datos.
PE 2.4 -1 planear los recursos del proyecto.
PE 2.5 -1 planear los conocimientos y habilidades que se requieren.
PE 2.6 -1 planear la participación del cliente.
PE 2.7 -1 establecer el plan de proyecto.

ME 3 comprometerse con la planeación.

PE 3.1 -1 revisar los planes que afectan el proyecto.
PE 3.2 -1 conciliar el trabajo y los niveles de recursos.
PE 3.3 -1 comprometerse con la planeación.

MG 1 alcanzar las metas específicas.

PG 1.1 realizar las prácticas base.

MG 2 Institucionalizar un proceso de gestión.

PG 2.1 establecer una política organizacional.
PG 2.2 planear el proceso.
PG 2.3 proporcionar recursos.
PG 2.4 asignar responsabilidades.
PG 2.5 capacitar gente.
PG 2.6 manejar configuraciones.
PG 2.7 identificar y a hacer participar a los clientes.
PG 2.8 monitorear y controlar el proceso.
PG 2.9 evaluar la adherencia de un módulo objetivo.
PG 2.10 revisar el estatus con un alto grado de gestión.

MG 3 Institucionalizar un proceso definido.

PG 3.1 establecer un proceso definido.
PG 3.2 recolectar información de la mejoría.

MG 4 Institucionalizar un proceso manejado e informar cuantitativa.

PG 4.1 establecer objetivos cuantitativos para el proceso.
PG 4.2 estabilizar el desempeño del sub proceso.

MG 5 Institucionalizar.
Página 6

PG 5.1 Asegurar la mejora continua del proceso.

PG 5.2 Corregir las causas de los problemas desde la raíz.

Ingeniería de Software I
 La IMCM: ¿se debe o no hacer? Grandes y complejos que impliquen dos cenas o cientos de
personas por varios meses o años. Es posible que la IMCM sea
La IMCM es un modelo total del proceso. Define en alrededor correcta en ciertas situaciones, sea la cultura organizacional es
de 700 páginas y las características del proceso que deben flexible frente a modelos de proceso estándares y se realizará
existir si una organización desea establecer un proceso de una gestión para lograr que sea un éxito.
software completo. La pregunta que se ha debatido durante una
década es la IMCM es ex es iba como la mayor parte de las No obstante, en otras situaciones es posible que la IMCM sea
cosas en la vida y el del software la respuesta no es muy simple demasiado para que una organización a la asimile de manera
y uno. exitosa. Esto significa que la IMCM es mala o demasiado
burocrática o que está pasada de moda no. Tan sólo significa
Siempre debe de adoptarse el espíritu de la IMCM. Frente al que lo correcto para la cultura de una compañía puede no serlo
riesgos de la simplificación excesiva, se argumenta que el para otra.
desarrollo del software debe de tomarse con seriedad: debe
planearse; debe controlar se de manera uniforme; debe La IMCM es un logro significativo para la ingeniería del
rastrearse con precisión; debe concluirse de manera software. Proporciona una exposición integral de las
profesional. Debe centrarse en las necesidades de los clientes actividades y acciones que deben estar presentes cuando una
del proyecto, las habilidades de los ingenieros de software y la organización construye un software de computadora. Aun si
calidad del producto terminado. Nadie debe de poner en duda una organización de software elige no adoptar sus detalles,
estas ideas. todo equipo de software debe retomar su espíritu y emprender
Los requisitos detallados de la IMCM deben tomarse en cuenta de su ex posición del proceso y la práctica de la ingeniería de
con seriedad sea una organización construye sistemas software.

Nivel Enfoque Arias del proyecto

 Innovación organizacional y
De optimización Mejora continua del proceso despliegue.
 Análisis causa al y resolución
 Ejecución del proceso organizacional
Gestionado de modo cuantitativo Gestión cuantitativa
 Gestión cuantitativa del proyecto
 Desarrollo de requisitos.
 Solución técnica.
 Integración del producto.
 Verificación.
 Validación.
 Enfoque del proceso organizacional.
 Definición del proceso organizacional.
Definido Estandarización del proceso
 Capacitación organizacional.
 Gestión integrada del proyecto.
 Gestión del riesgo.
 Análisis y resolución de la decisión.
 Diente organizacional para la
integración.
 Equipo integrado.
 Gestión de requisitos.
 Planeación del proyecto.
 Monitoreo y control del proyecto.
 Gestión de acuerdos del proveedor.
Gestionado Gestión básica del proyecto
 Medición y análisis.
 Aseguramiento de la calidad del
producto y del proceso.
 Gestión de la configuración.
Ejecutado

2.4. Patrones del proceso.

El proceso de software puede definirse como una colección de patrones que define en un conjunto de
actividades, acciones, tareas de trabajo o comportamiento relacionados que requiere el desarrollo de un
software de computadora. Mediante la combinación de patrones, un equipo de software puede construir un
proceso que satisfaga lo mejor posible y las necesidades de un proyecto. Algunos casos se puede utilizar
un patrón para describir un proceso completo, por ejemplo, un prototipo. Ambler propuso la siguiente
plantilla para describir un patrón de proceso. Al patrón se le asigna un hombre significativo que describa
su función dentro del software como comunicación con el cliente. Por ejemplo, el objetivo de la
comunicación con el cliente es establecer una relación de colaboración con el cliente en un esfuerzo
encaminado a definir el alcance del proyecto, los requisitos del negocio y otras condiciones del
proyecto. Los patrones de escenario definen una actividad del marco de trabajo para el proceso. Debido a
que una actividad del marco de trabajo reúne múltiples tareas de trabajo, un patrón de escenario incorpora
Página 7

múltiples patrones de tarea relevantes para el escenario actividad del marco de trabajo. Un ejemplo del
patrón de escenario es la comunicación. Este patrón incorpora el patrón de tareas de reunión de requisitos
y otros. Los patrones de fase definen la secuencia de actividades del marco de trabajo que ocurre junto con
Ingeniería de Software I
el proceso, aun cuando el flujo General de actividades es iterativo por naturaleza. Es el estado de entrada
para el proceso. Qué información de ingeniería del software o información del proceso ya existe.

Clientes y los ingenieros de software hayan establecido una colaboración en cuanto a comunicación. Haya
completado con éxito o un gran número de patrones de tarea específica dos para el patrón de
comunicación con el cliente. Se conozcan los alcances del proyecto, los requisitos básicos del negocio y
las restricciones del proyecto. En esta sección se discuten como el estado inicial del proceso existente
antes de que se haya implementado el patrón se modifica como consecuencia del inicio del patrón.
También se describe como la información de la ingeniería del software hoy la información del
proyecto, disponible antes de iniciado el patrón, se transforma como consecuencia del ejecución exitosa
del patrón. Se describe las condiciones que habrá una vez que el patrón haya sido implementado con
éxito. Es el estado de salida para el proceso. Se proporciona una lista de todos los patrones de proceso
directamente relacionados con este, en forma jerárquica o de alguna otra forma. Los patrones de proceso
proporcionan un mecanismo efectivo para describir cualquier proceso de software. Los patrones permiten
una organización de ingeniería de software para desarrollar una descripción del proceso jerárquico que
comience en un alto grado de abstracción un patrón de fase.

Ejemplo de un patrón del proceso. De software. Los clientes no están seguros de lo que desean; es
decir, no pueden describir ningún detalle de los requisitos de
El siguiente patrón de proceso abreviado describe un enfoque software.
aplicable cuando los clientes tienen una idea General de lo que
debe de hacerse, pero no están seguros de los requisitos Solución. Aquí se presenta una descripción del proceso de
específicos del software. prototipo. Para más detalles, véase el capítulo 3.

Nombre del patrón. Prototipo. Contexto resultante. Los clientes aprueban un prototipo de
software que identificar requisitos básicos por ejemplo,
Propósito. El objetivo del patrón es construir un modelo un modelos de interacción, rasgos computacionales, funciones de
prototipo que los clientes evalúen de modo iterativo en un procesamiento. Después:
esfuerzo encaminado a identificar los requisitos del software.
1) El prototipo puede evolucionar recorriendo una
Tipo. Patrón de fase. serie de incrementos para convertirse en el software
de producción.
2) Hoy prototipo se descarta y el software de
Contexto inicial. Deben cumplirse las siguientes condiciones producción se construye con otros patrones del
antes de iniciar este patrón: proceso.

1) Los clientes han sido identificados. Patrones relacionados. Los siguientes patrones están
2) Se ha establecido un modo de comunicación entre relacionados con este patrón: comunicación con el cliente;
los clientes y el equipo de trabajo. diseño iterativo; desarrollo iterativo; evaluación del
3) Los clientes han identificado el problema que ha de cliente; extracción de los requisitos.
resolverse.
4) Se ha desarrollado un entendimiento inicial del
alcance del proyecto, los requisitos básicos del Usos conocidos/ejemplos. El prototipo se recomienda cuando
negocio y las restricciones del proyecto. los requisitos son inseguros.

Problema. Los requisitos son vagos o no existen. No obstante,

se reconoce con claridad la existencia de un problema, y éste
debe de ir acompañado de una solución

2.5. Evaluación del proceso.

La existencia de un proceso de software no es garantía de que éste será entregado a tiempo, de que
satisfará las necesidades del cliente, o de que mostrará las características técnicas que producirán a
características de calidad a largo plazo capítulo 26. Los patrones de proceso deben ir acompañados de
unas prácticas sólidas de la ingeniería del software parte 2 de este libro). Además, el proceso mismo debe
evaluarse para asegurarse de que cumpla una serie de criterios básicos del proceso que han demostrado ser
esenciales para una ingeniería de software exitosa. El método MEIEMP utilizar el SEI IMCM sección2.3
como base para la evaluación. La apreciación basada en el CMM para el mejoramiento del proceso interno
ofrece una técnica de diagnóstico para evaluar la madurez relativa de una organización de software
mediante la ABC MPI un precursor de la IMCM, el cual se explica en la sección 2.3 como base para la
evaluación. Por lo tanto, el estándar se aplica de modo directo a compañías y organizaciones de software.
Página 8

Ingeniería de Software I
2.6. Modelos de procesos personales y en equipo.

El mejor proceso de software es el que está acerca de la gente que realiza el trabajo.  Es un escenario ideal
a, cada ingeniero de software crearía un proceso que llene lo mejor posible sus propias necesidades,  al
mismo tiempo satisfaga las amplias necesidades del equipo y la organización. Watts Humphrey y
argumenta que es posible crear un proceso de software personal o un proceso de software en equipo.

2.6.1. Proceso de software personal (PSP).

El modelo PSP define cinco actividades del marco de trabajo. Diseño de alto nivel. Revisión del diseño de
alto nivel. El diseño al nivel de componentes se refina y revisa. Mediante las mediciones y medidas
recolectadas una cantidad sustancial de datos debe analizarse de manera estadística se determina la
efectividad del proceso. Las mediciones y medidas deben ofrecer una guía para modificar el proceso y así
mejorar su efectividad. El PSP destaca la necesidad que tiene cada ingeniero de software de identificar los
errores desde el principio y la importancia de entender los tipos de errores que suele cometer. Estos se
llevan a cabo mediante una actividad de evaluación rigurosa aplicada en todos los productos de trabajo
que genera el ingeniero de software. El PSP representa un enfoque disciplinado, basado en mediciones, de
la ingeniería de software que puede conducir a un choque de culturas a muchos profesionales. Sin
embargo, cuando el PSP se presenta de un modo adecuado a los ingenieros de software, la mejoría
resultante en la productividad de la ingeniería del software y la calidad de este son significativas. En lo
cultural, grado requerido de medición es difícil para mucha gente involucrada en el software. Una
interrogante es si el PSP puede usarse como un proceso de software efectivo a un nivel personal. Pero aún
sí el PSP no es adoptado en su totalidad, vale la pena estudiar muchos de los conceptos de mejora del
proceso que éste representa.

2.6.2. Proceso de software en equipo (PSE).

Debido a que muchos proyectos de software en el ámbito industrial los dirige un equipo de
profesionales, Watts Humphrey extendió las lecciones aprendidas para la introducción del PSP y propuso
un proceso de software en equipo. La meta del PSE es construir un equipo de proyecto o auto dirigido que
se organice para producido un software de alta calidad. Acelerar el mejoramiento del proceso de software
al realizar, con el comportamiento normal y esperado, el nivel 5 del MCM. Facilitar la enseñanza
universitaria de habilidades de equipo industrial de calidad. Un equipo auto dirigido entiende en forma
consistente sus metas y objetivos generales. Al igual que sus contrapartes en el PSP nótese que la
terminología es diferente, estas actividades permiten al equipo planear, diseñar y construir un software de
una manera disciplinada al mismo tiempo que miden de modo cuantitativo el proceso y el producto. Los
análisis de resultados muestran el escenario para el mejoramiento del proceso. El PSE utiliza una amplia
variedad de escritos, formas y estándares que sirva para guiar a los miembros del equipo en su trabajo.
Los escritos definen actividades específicas del proceso por ejemplo
lanzamiento, diseño, implementación, integración y prueba, y análisis de resultados del proyecto y otras
funciones más detalladas del trabajo como planeación del desarrollo, desarrollo de requisitos, gestión de la
Página 9

configuración de software y prueba de unidad que son parte del proceso del equipo. Cada proyecto es
lanzado como una secuencia de tareas definida como un escrito que permite al equipo establecer una base
Ingeniería de Software I
sólida para iniciar el proyecto. Revisar los objetivos del proyecto con la gestión y acordar y documentar
las metas del equipo. Establecer las funciones del equipo. Definir el proceso de desarrollo del
equipo. Elaborar un plan de desarrollo para el proyecto en su totalidad. Adaptar los planes individuales a
un plan de equipo. Hacer un balance de la cantidad de trabajo del equipo para obtener un programa
mínimo en términos generales. Valorar los riesgos del proyecto y asigna responsabilidad de rastreo para
cada riesgo clave. éstos se ajustan a la naturaleza iterativo ha de muchos proyectos y permite que el
equipo se adapte a las necesidades cambiantes del cliente y a las lecciones aprendidas de actividades
previas. El equipo debe de comprometerse con el proceso y debe recibir capacitación para asegurarse de
que el enfoque se aplique de manera apropiada.

2.7. Tecnología del proceso.

Los modelos genéricos de proceso tratados en las secciones precedentes deben adaptarse para que los
utilice un equipo de proyecto de software. Las herramientas de tecnología del proceso permiten que una
organización de software construye un modelo y automatizado del marco de trabajo común del
proceso, de los conjuntos de tareas que las actividades sombrilla explicadas en la sección 2.2. Una vez
creado un proceso aceptable es posible utilizar otras herramientas de tecnología del proceso para
localizar, monitorear e incluso controlar todas las tareas de ingeniería de software definidas como una
parte del modelo de proceso.

Herramientas de modelado del proceso. Único acciones, tareas, productos de trabajo, ofrecen una guía
detallada del contenido o la descripción de cada elemento del
Objetivo: sea una organización trabajan el mejoramiento de un proceso, y después gestionan el proceso mientras se conduce.
proceso de un negocio o de un software, el primer objetivo es Algunos casos las herramientas de tecnología del proceso
entenderlo. Las herramientas de modelado del proceso también incorporan tareas de gestión del proyecto estándar, como
llamadas tecnología del proceso o herramientas de gestión del estimación, itinerario, rastreo y control.
proceso se utilizan para presentar los elementos clave de un
proceso para que éste pueda entenderse con mayor claridad. Herramientas representativas:
Tales herramientas también ofrecen vínculos de con Igraf Process Tools, distribuidas por Corel Corporation, es una
descripción del proceso que ayudan a quienes se interesen en el serie de herramientas que permiten al equipo organizar, medir
proceso entender las acciones y las tareas de trabajo necesarias y modelar el proceso de software.
para desarrollarlo. Las herramientas de modelación del proceso
proporcionan vínculos con otras herramientas que ofrecen Objexis Team Portal, desarrollado por Objexis Corporation,
soporte actividades definidas del proceso. proporciona la definición y el control completo del flujo de
trabajo de proceso.
Mecánica: las herramientas de esta categoría permiten al
equipo definir los elementos de un modelo de proceso

2.8. Productor y proceso.

Si el proceso es débil, sin duda el producto final sufrirá las consecuencias. Asimismo, una confianza

excesiva en el proceso es peligrosa. En un breve ensayo Margaret Davis comentar sobre la dualidad del
producto y el proceso. Alrededor de cada diez años, a veces cada cinco, la comunidad del software
redefine el problema cambiando su enfoque de los aspectos del producto a los asuntos del proceso.
Entonces se han obtenido lenguajes de programación estructurados producto seguidos por métodos de
análisis estructurado proceso y en cápsula acción de datos producto, así como el énfasis actual en el
modelo de madurez de capacidad para el desarrollo de software del instituto de ingeniería del software
proceso seguidos por los métodos orientados a objetos y el desarrollo ágil de software. Las oscilaciones
tampoco resuelven el problema, puesto que están destinadas a fallar mientras el producto y el proceso sean
tratados como si formaran una dicotomía en lugar de una dualidad. Creo que las observaciones posibles
sobre los artefactos del software y su desarrollo demuestran una dualidad fundamental entre el producto y
el proceso. Por lo tanto, mientras la rápida asimilación de reutilización metas en el desarrollo de software
aumenta de manera potencial la satisfacción que experimente a los profesionales de su trabajo, también
aumenta la urgencia de aceptación de la unidad del producto y el proceso. Considerar un artefacto
reutilizable como sólo un producto o sólo como un proceso oscurece el contexto y las maneras de
utilizarlo, hubo oscurece el hecho de que cada uso resulta en un producto que, a su tiempo, se aprovechará
como entrada a algunas otras actividades desarrollo de software. La gente obtiene tanta o más satisfacción
del producto creativo que del producto final. Un profesional del software creativo debe sentir tanta
satisfacción del proceso como el producto terminado. La dualidad del proyecto del producto y el proceso
es un elemento importante para mantener a la gente creativa comprometida mientras finaliza la transición
Página 10

desde la programación hasta la ingeniería del software.

Ingeniería de Software I
2.9. Resumen.

La ingeniería de software es una disciplina que integra al proceso, los métodos y las herramientas para el
desarrollo del software de computadora. La integración del modelo de capacidad de madurez es un
modelo total del proceso, que describe las metas, prácticas y capacidades específicas con que debe contar
un proceso de software maduro. Ambos destacan la medición, la planeación y la auto dirección como
ingredientes clave para un proceso de software exitoso.

3. Referencias.

Roger S. Pressman. (2002). Ingeniería del Software: Un Enfoque Práctico. México: McGraw Hill.

Página 11

Ingeniería de Software I