CAPITULO II.

EL PROCESO

El proceso.

El software, al igual que el capital, es el conocimiento incorporado, y puesto

que el conocimiento está inicialmente disperso, el desarrollo del software
implícito, latente e incompleto en gran medida, es un proceso social de
aprendizaje. El proceso es un diálogo en el que se reúne el conocimiento y
se incluye en el software para convertirse en software el software, al igual
que el capital, es el conocimiento incorporado, y puesto que el conocimiento
está inicialmente disperso, el desarrollo del software implícito, latente e
incompleto en gran medida, es un proceso social de aprendizaje. El proceso
es un diálogo en el que se reúne el conocimiento y se incluye en el software
para convertirse en software. El proceso proporciona una interacción entre
los usuarios y los diseñadores, entre los usuarios y las herramientas de
desarrollo, y entre los diseñadores y las herramientas de desarrollo
[tecnología].

¿Qué es? Cuando trabaja para construir un producto o un sistema, es

importante seguir una serie de pasos predecibles

¿Quién lo hace? Los ingenieros de software y sus gestores adaptan el

proceso a sus necesidades y entonces lo siguen.

¿Por qué es importante? Porque proporciona estabilidad, control y

organización a una actividad que puede, si no se controla, volverse caótica.

¿Cuáles son los pasos? Un proceso puede ser apropiado para crear
software de un sistema de aviación, mientras que un proceso diferente por
completo puede ser adecuado para la creación de un sitio web.

¿Cuál es el producto obtenido? Del punto de vista de un ingeniero de

software, los productos obtenidos son programas, documentos y datos que
se producen como consecuencia de las actividades de ingeniería del
software definidas por el proceso.

¿Cómo puedo estar seguro de que lo he hecho correctamente? Hay

una cantidad de mecanismos de evaluación del proceso del software que
permiten a las organizaciones determinar la «madurez. De su proceso del
software como un marco de trabajo de las tareas que se requieren para
construir software de alta calidad.

Un proceso de software define el enfoque que se toma cuando el software

es tratado por la ingeniería. También comprende las tecnologías que tiene
el proceso -métodos técnicos y herramientas automatizadas

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

INGENIERIA DEL SOFTWARE: UNA TECNOLOGIA ESTRATIFICADA.

[La ingeniería del software] es el establecimiento y uso de

principios robustos de la ingeniería a fin de obtener
económicamente software que sea fiable y que funcione
eficientemente sobre máquinas reales.

La definición de Bauer nos proporciona una línea base. ¿Cuáles son los
«principios robustos de la ingeniería» aplicables al desarrollo de software de
computadora? ¿Cómo construimos el software «económicamente» para que
sea «fiable»?

¿Qué se necesita para crear programas de computadora que funcionen

«eficientemente» no en una máquina si no en diferentes «máquinas
reales»? Éstas son cuestiones que siguen siendo un reto para los ingenieros
del software.

El IEEE ha desarrollado una definición más completa:

Ingeniería del software: (1) La aplicación de un enfoque

sistemático, disciplinado y cuantificable hacia el desarrollo,
operación y mantenimiento del software; es decir, la aplicación de
ingeniería al software. (2) El estudio de enfoques como en (1).

El fundamento de la ingeniería del software es la capa de proceso. El

proceso de la ingeniería del software es la unión que mantiene juntas las
capas de tecnología y que permite un desarrollo racional y oportuno de la
ingeniería del software. Las áreas claves del proceso forman la base del
control de gestión de proyectos del software y establecen el contexto en el
que se aplican los métodos técnicos, se obtienen productos del trabajo
(modelos, documentos, datos, informes, formularios, etc.),

Los métodos de la ingeniería del software indican «cómo» construir

técnicamente el software. Abarcan una gran gama de tareas que incluyen
análisis de requisitos, diseño, construcción de programas, pruebas y
mantenimiento. Las herramientas de la Ingeniería del software proporcionan
un enfoque automático o semi-automático para el proceso y para los
métodos. Se establece un sistema de soporte para el desarrollo del software
llamado ingeniería del software asistida por computadora (CASE).

2.1.2. Una visión general de la ingeniería del

Software

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

La ingeniería es el análisis, diseño, construcción, verificación y gestión de

entidades técnicas (o sociales). Cuestionar y responder las siguientes
preguntas:

¿Cuál es el problema a resolver?

¿Cuáles son las características de la entidad que se utiliza para resolver el

problema?

¿Cómo se realizará la entidad (y la solución)?

¿Cómo se construirá la entidad?

¿Qué enfoque se va a utilizar para no contemplar los errores que se

cometieron en el diseño y en la construcción de la entidad?

¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones,

adaptaciones y mejoras de la entidad?

La fase de definición se centra sobre el qué. El que desarrolla el software

intenta identificar qué información ha de ser procesada, qué función y
rendimiento se desea, qué comportamiento del sistema, qué interfaces van
a ser establecidas, qué restricciones de diseño existen, y qué criterios de
validación se necesitan para definir un sistema correcto.

La fase de desarrollo se centra en el cómo. Durante el desarrollo un

ingeniero del software intenta definir cómo han de diseñarse las estructuras
de datos, cómo ha de implementarse la función dentro de una arquitectura
de software, cómo han de implementarse los detalles procedimentales,
cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en
un lenguaje de programación (o lenguaje no procedimental) y cómo ha de
realizarse la prueba. La fase de mantenimiento se centra en el cambio que
va asociado a la corrección de errores, a las adaptaciones requeridas a
medida que evoluciona el entorno del software y a cambios debidos a las
mejoras producidas por los requisitos cambiantes del cliente.

Corrección. Llevando a cabo las mejores actividades de garantía de

calidad, es muy probable que el cliente descubra los defectos en el
software. El mantenimiento correctivo cambia el software para corregir los
defectos.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

Adaptación. Con el paso del tiempo, es probable que cambie el entorno

original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las
características externas de productos) para el que se desarrolló el software.
El mantenimiento adaptativo produce modificación en el software para
acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/ usuario puede descubrir

funciones adicionales que van a producir beneficios.

Prevención. El software de computadora se deteriora debido al cambio, y

por esto el mantenimiento preventivo también llamado reingeniería del
software, se debe conducir a permitir que el software sirva para las
necesidades de los usuarios finales. Las fases y los pasos relacionados
descritos en nuestra visión genérica de la ingeniería del software se
complementan con un número de actividades protectoras. Actividades de
protección

Entre las actividades típicas de esta categoría se incluyen:

• Seguimiento y control del proyecto de software

• Revisiones técnicas formales

• Garantía de calidad del software

• Gestión de configuración del software

• Preparación y producción de documentos

• Gestión de reutilización

• Mediciones

• Gestión de riesgos

2.2 EL PROCESO DE SOFTWARE.

Se establece un marco común del proceso definiendo un pequeño número

de actividades del marco de trabajo que son aplicables a todos los
proyectos del software, con independencia de su tamaño o complejidad. Un
número de conjuntos de tareas

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

Proceso>>El Software Engineering Institute (SEI)3 ha desarrollado un

modelo completo que se basa en un conjunto de funciones de ingeniería del
software que deberían estar presentes conforme organizaciones alcanzan
diferentes niveles de madurez del proceso. El SE1 utiliza un cuestionario de
evaluación y un esquema de cinco grados.

El enfoque del SE1 proporciona una medida de la efectividad global de las

prácticas de ingeniería del software de una compañía y establece cinco
niveles de madurez del proceso, que se definen de la forma siguiente:

Nivel 1: Inicial. El proceso del software se caracteriza según el caso, y

ocasionalmente incluso de forma caótica.

Nivel 2: Repetible. Se establecen los procesos de gestión del proyecto

para hacer seguimiento del coste, de la planificación y de la funcionalidad.

Nivel 3: Definido. El proceso del software de las actividades de gestión y

de ingeniería se documenta, se estandariza y se integra dentro de un
proceso de software de toda una organización. Todos los proyectos utilizan
una versión documentada y aprobada del proceso de la organización para el
desarrollo y mantenimiento del software.

Nivel 4: Gestionado. Se recopilan medidas detalladas del proceso del

software y de la calidad del producto. Mediante la utilización de medidas
detalladas, se comprenden y se controlan cuantitativamente tanto los
productos como el proceso del software.

Nivel 5: Optimización. Mediante una retroalimentación cuantitativa del

proceso, ideas y tecnologías innovadoras se posibilita una mejora del
proceso. El nivel 1 representa una situación sin ningún esfuerzo en la
25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

garantía de calidad y gestión del proyecto, donde cada equipo del proyecto
puede desarrollar software de cualquier forma eligiendo los métodos,
estándares y procedimientos a utilizar El nivel 2 representa el hecho de que
un desarrollador de software ha definido ciertas actividades tales como el
informe del esfuerzo y del tiempo empleado.

El nivel 3 representa el hecho de que un desarrollador de software ha

definido tanto procesos técnicos como de gestión. Es aquel en el que la
mayoría de los desarrolladores de software, pretenden conseguir con
estándares como el ISO 9001, y existen pocos casos de desarrolladores de
software que superan este nivel.

El nivel 4 comprende el concepto de medición y el uso de métricas cabe

destacar el concepto de métrica para comprender la importancia que tiene
que el desarrollador del software alcance el nivel 4 o el nivel 5. Una métrica
es una cantidad insignificante que puede extraerse de algún documento o
código dentro de un proyecto de software.

Estas métricas se utilizan entonces para supervisar y controlar un proyecto

de software, por ejemplo:

Una métrica de prueba puede usarse para determinar cuándo finalizar la

prueba de un elemento del código. Una métrica de legilibilidad puede
usarse para juzgar la legilibilidad de algún documento en lenguaje natural.
Una métrica de comprensión del programa puede utilizarse para
proporcionar algún umbral numérico que los programadores no pueden
cruzar. Para que estas métricas alcancen este nivel es necesario que todos
los componentes del nivel 3 CMM, en castellano MCM (Modelo de Capacidad
de Madurez), estén conseguidos.

El nivel 5 es el nivel más alto a alcanzar. Hasta ahora, muy pocos

desarrolladores de software han alcanzado esta fase. Representa la
analogía del software con los mecanismos de control de calidad que existen
en otras industrias de mayor madurez. Por ejemplo el fabricante de un
producto industrial como un cojinete de (rodamiento) puede supervisar y
controlar la calidad de los rodamientos producidos y puede predecir esta
calidad basándose en los procesos y máquinas utilizados para desarrollar
los rodamientos. En este orden debe destacarse que para que un
desarrollador de software alcance el nivel 5 tiene que tener cada proceso
definido rigurosamente y seguirlo al pie de la letra; esto es una
consecuencia de estar en el nivel 3.

En este orden debe destacarse que para que un desarrollador de software

alcance el nivel 5 tiene que tener cada proceso definido rigurosamente y
25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

seguirlo al pie de la letra; esto es una consecuencia de estar en el nivel 3. El

SE1 ha asociado áreas claves del proceso (ACPs) a cada uno de los niveles
de madurez. Las ACPs describen esas funciones de la ingeniería del
software.

Cada ACP se describe identificando las características siguientes: lodo

organización debería esforzarse poro alcanzar lo profundidad del MíM del
IIS. Sin embargo, lo implementación de cualquier aspecto del modelo puede
eliminarse en su situación.

Objetivos- los objetivos globales que debe alcanzar la ACP

Compromisos- requisitos (impuestos en la organización) que se deben

cumplir para lograr los objetivos y que proporcionan una prueba del intento
por ajustarse a los objetivos.

Capacidades- aquellos elementos que deben encontrarse (organizacional y

técnicamente) para permitir que la organización cumpla los objetivos.

Actividades- las tareas específicas que se requieren para lograr la función

ACP.

Métodos para supervisar la implementación-la manera en que las

actividades son supervisadas conforme se aplican.

Métodos para verificar la implementación- la forma en que se puede

verificar la práctica adecuada para la ACP.

Las ACPs se deberían lograr en cada nivel de madurez de proceso4:

Nivel 2 de Madurez del Proceso

• Gestión de configuración del software

• Garantía de calidad del software

• Gestión de subcontratación del software

• Seguimiento y supervisión del proyecto del software

• Planificación del proyecto del software

• Gestión de requisitos

Nivel 3 de Madurez del Proceso

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

• Revisiones periódicas

• Coordinación entre grupos

• Ingeniería de productos de software

• Gestión de integración del software

• Programa de formación

• Definición del proceso de la organización

• Enfoque del proceso de la organización

Nivel 4 de Madurez del Proceso

• Gestión de calidad del software

• Gestión cuantitativa del proceso

Nivel 5 de Madurez del Proceso

• Gestión de cambios del proceso

• Gestión de cambios de tecnología

• Prevención de defectos

2.3 MODELOS DE PROCESOS DE SOFTWARE.

Esta estrategia a menudo se llama modelo de proceso o paradigma de

ingeniería del software.

Se selecciona un modelo de proceso para la ingeniería del software según la

naturaleza del proyecto y de la aplicación, los métodos y las herramientas a
utilizarse, y los controles y entregas que se requieren. El desarrollo del
software se puede caracterizar como bucle de resolución de problemas en el
que se encuentran cuatro etapas distintas: «statusquo», definición de
problemas, desarrollo técnico e integración de soluciones. Status quo

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

«representa el estado actual de sucesos» la definición de problemas

identifica el problema específico a resolverse; el desarrollo técnico resuelve
el problema a través de la aplicación de alguna tecnología y la integración
de soluciones ofrece los resultados.

Raccoon sugiere un «Modelo del Caos» que describe el «desarrollo del

software como una extensión desde el usuario hasta el desarrollador y la
tecnología». Conforme progresa el trabajo hacia un sistema completo, las
etapas descritas anteriormente se aplican recursivamente a las necesidades
del usuario y a la especificación técnica del desarrollador del software.

2.4 modelo lineal secuencial

El modelo lineal secuencial sugiere un enfoque5 sistemático, secuencial,

para el desarrollo del software que comienza en un nivel de sistemas y
progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

Ingeniería y modelado de Sistemas/Información.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

Como el software siempre forma parte de un sistema más grande (o

empresa), el trabajo comienza estableciendo requisitos de todos los
elementos del sistema y asignando al software algún subgrupo de estos
requisitos. Esta visión del sistema es esencial cuando el software se debe
interconectar con otros elementos como hardware, personas y bases de
datos.

La ingeniería de información abarca los requisitos que se recogen en el nivel

de empresa estratégico y en el nivel del área de negocio.

Análisis de los requisitos del software. El proceso de reunión de

requisitos se intensifica y se centra especialmente en el software.

Diseño. El diseño del software es realmente un proceso de muchos pasos

que se centra en cuatro atributos distintos de programa: estructura de
datos, arquitectura de software, representaciones de interfaz y detalle
procedimental (algoritmo).

Generación de código. El diseño se debe traducir en una forma legible

por la máquina. El paso de generación de código lleva a cabo esta tarea. Si
se lleva a cabo el diseño de una forma detallada, la generación de código se
realiza mecánicamente.

Pruebas. Una vez que se ha generado el código, comienzan las pruebas del
programa. El proceso de pruebas se centra en los procesos lógicos internos
del software, asegurando que todas las sentencias se han comprobado.

Mantenimiento. El software indudablemente sufrirá cambios después de

ser entregado al cliente (una excepción posible es el software empotrado).
Se producirán cambios porque se han encontrado errores, porque el
software debe adaptarse para acoplarse a los cambios de su entorno
externo

El modelo lineal secuencial es el paradigma más antiguo y más

extensamente utilizado en la ingeniería del software. Sin embargo, la crítica
del paradigma ha puesto en duda los problemas que se encuentran algunas
veces en el modelo lineal secuencial se incluyen:

Los proyectos reales raras veces siguen el modelo secuencial que propone
el modelo. Aunque el modelo lineal puede acoplar interacción, lo hace
indirectamente.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

2.- A menudo es difícil que el cliente exponga explícitamente todos los

requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la
hora de acomodar la incertidumbre natural al comienzo de muchos
proyectos.

3.- El cliente debe tener paciencia. Una versión de trabajo del (los)
programa(s) no estará disponible hasta que el proyecto esté muy avanzado.
El ciclo de vida clásico sigue siendo el modelo de proceso más
extensamente utilizado por la ingeniería del software. Pese a tener
debilidades, es significativamente mejor que un enfoque hecho al azar para
el desarrollo del software.

2.5 MODELO DE CONSTRUCCION DE PROTOTIPOS.

Un cliente, a menudo, define un conjunto de objetivos generales para el

software, pero no identifica los requisitos detallados de entrada, proceso o
salida. El responsable del desarrollo del software puede no estar seguro de
la eficacia de un algoritmo, de la capacidad de adaptación de un sistema
operativo, o de la forma en que debería tomarse la interacción hombre
máquina.

Paradigma de construcción.

El desarrollador y el cliente encuentran y definen los objetivos globales para

el software, identifican los requisitos conocidos y las áreas del esquema en

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

donde es obligatoria más definición. Entonces aparece un «diseño rápido».

El diseño rápido se centra en una representación de esos aspectos del
software que serán visibles para el usuario/cliente En la mayoría de los
proyectos, el primer sistema construido apenas se puede utilizar.
Puede ser demasiado lento, demasiado grande o torpe en su uso, o
las tres a la vez. No hay otra alternativa que comenzar de nuevo,
aunque nos duela pero es más inteligente, y construir una versión
rediseñada en la que se resuelvan estos problemas.

El desarrollo de Aplicaciones (DRA) es un modelo de proceso del

desarrollo del software lineal y secuencial que enfatiza un ciclo de
desarrollo extremadamente corto. El modelo DRA es una adaptación a
<<alta velocidad>> del modelo lineal secuencial en el que se logra
el desarrollo rápido utilizando una construcción basada en
componentes .El Proceso DRA Permite al equipo de desarrollo crear
sistemas completamente funcionales el cual comprende las
siguientes fases:

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

Modelo de gestión

El flujo de información entre las funciones de gestión se modela en

forma que responda las necesidades:

• Modelo de gestión
• Modelo de datos
• Modelo del proceso
• Generación de aplicaciones
• Pruebas y entrega

El modelo de proceso de DRA tiene inconvenientes:

En proyectos grandes se requiere recursos humanos suficientes

requiere clientes y desarrolladores comprometidos en las rápidas
actividades necesarias no todos los tipos de aplicaciones son
adecuados para DRA.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

DRA no es adecuado cuando los riesgos técnicos son altos

EL modelo incremental

El modelo incremental combina elementos del modelo lineal

secuencial con filosofía interactiva de construcción de prototipos
.Cada secuencia lineal produce un incremento del software. Cuando
se utiliza un modelo incremental, el primer incremento es a menudo
es producto esencial .Es decir se afronta requisitos básicos, pero
muchas funciones suplementarias quedan sin extraer. El modelo del
proceso incremental se centra en la entrega de un producto
operacional con cada incremento. El desarrollo incremental es
particularmente útil cuando la dotación de personal no está
disponible para una implementación completa en la fecha límite que
se haya establecido para el proyecto.

Proceso en espiral

Es un modelo de proceso de software evolutivo que conjuga la

naturaleza iterativa de construcción de prototipos con los aspectos
controlados y sistemáticos del modelo lineal secuencial, el modelo en
espiral se divide en un numero de actividades de marco de trabajo,

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

también llamadas regiones de tareas, existen entre 3 y 6 regiones de

tareas las cuales son:

Comunicación con el cliente

Las tareas requeridas para establecer comunicación entre el

desarrollador y el cliente

Planificación

Las tareas requeridas para definir recursos, el tiempo y otra

información relacionadas con el proyecto.

Análisis de riesgos

Las tareas requeridas para evaluar riesgos técnicos y de gestión.

Ingeniería

Las tareas requeridas para construir una o más representaciones,

probar instalar y proporcionar soporte al usuario.

Construcción y acción

Las tareas requeridas para construir una o más, probar, instalar,

proporcionar soporte al usuario.

Evaluación del cliente.

Las tareas requeridas para obtener la relación del cliente según la

evaluación de las representaciones del software.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

Cuando empieza este proceso evolutivo, el equipo de ingeniería del

software gira alrededor de la espiral en la dirección de las agujas del
reloj, comenzando por el centro. El primer circuito de la espiral puede
producir el desarrollo de una especificación de productos; los pasos
siguientes en la espiral se podrían utilizar para desarrollar un
prototipo y progresivamente versiones más sofisticadas del software.
El modelo en espiral demanda una consideración directa de los
riesgos técnicos en todas las etapas del proyecto y si se aplica
adecuadamente debe reducir los riesgos antes de que se conviertan
en problemáticos.

El modelo de desarrollo concurrente

El modelo de proceso concurrente se puede representar en forma de

esquema como una serie de actividades técnicas importantes, tareas
y estados asociados a ellas. El modelo de proceso concurrente define
una serie de acontecimientos que dispararán transiciones de estado a
estado para cada una de las actividades de la ingeniería del software.
Por ejemplo, durante las primeras etapas del diseño, no se contempla
una inconsistencia del modelo de análisis. Esto genera la corrección
del modelo de análisis de sucesos, que disparará la actividad de
análisis del estado hecho al estado cambios en espera.

Desarrollo basado en componentes

Las tecnologías de objetos proporcionan el marco de trabajo técnico

para un modelo de proceso basado en componentes para la
25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

ingeniería del software. El paradigma orientado a objetos enfatiza la

creación de clases que encapsulan tanto los datos como los
algoritmos que se utilizan para manejar los datos. Si se diseñan y se
implementan adecuadamente, las clases orientadas a objetos son
reutilizables por las diferentes aplicaciones y arquitecturas de
sistemas basados en computadora. La actividad de la ingeniería
comienza con la identificación de clases candidatas. Esto se lleva a
cabo examinando los datos que se van a manejar por parte de la
aplicación y el algoritmo que se va a aplicar para conseguir el
tratamientoI2. Los datos y los algoritmos correspondientes se
empaquetan en una clase.

El modelo de métodos formales

El modelo de métodos formales comprende un conjunto de

actividades que conducen a la especificación matemática del
software de computadora. Los métodos formales permiten que un
ingeniero de software especifique, desarrolle y verifique un sistema
basado en computadora aplicando una notación rigurosa y
matemática.

Aunque todavía no hay un enfoque establecido, los modelos de

métodos formales ofrecen la promesa de un software libre de
defectos. Sin embargo, se ha hablado de una gran preocupación
sobre su aplicabilidad en un entorno de gestión:

1. El desarrollo de modelos formales actualmente es bastante caro y

lleva mucho tiempo.

2. Se requiere un estudio detallado porque pocos responsables del

desarrollo de software tienen los antecedentes necesarios para
aplicar métodos formales.

3. Es difícil utilizar los modelos como un mecanismo de comunicación

con clientes que no tienen muchos conocimientos técnicos.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo
CAPITULO II. EL PROCESO

El término técnicas de cuarta generación (T4G) abarca un amplio

espectro de herramientas de software que tienen algo en común:
todas facilitan al ingeniero del software la especificación de algunas
características del software a alto nivel. Cada vez parece más
evidente que cuanto mayor sea el nivel en el que se especifique el
software, más rápido se podrá construir el programa. El paradigma
T4G para la ingeniería del software se orienta hacia la posibilidad de
especificar el software usando formas de lenguaje especializado o
notaciones gráficas que describa el problema que hay que resolver en
términos que los entienda el cliente. Resumiendo, las técnicas de
cuarta generación ya se han convertido en una parte importante del
desarrollo de software. Cuando se combinan con enfoques de
ensamblaje de componentes, el paradigmaT4G se puede convertir en
el enfoque dominante hacia el desarrollo del software.

Tecnologías de proceso

Las herramientas de tecnología de procesos permiten que una

organización de software construya un modelo automatizado del
marco de trabajo común de proceso, conjuntos de tareas y
actividades de protección

Producto y Proceso

Si el proceso es débil, el producto final va a sufrir indudablemente.

Aunque una dependencia obsesiva en el proceso también es
peligrosa. El trabajo de los profesionales del software cambiará en los
próximos años. La dualidad de producto y proceso es un elemento
importante para mantener ocupada a la gente creativa hasta que se
finalice la transición de la programación a la ingeniería del software.

25 de Enero de 2011
Ramírez Delgado Brenda Carolina
Bueno Pérez Luis Enrique
Marrufo Luis Fernando
Jiménez Salazar Jairo