Sistem As

INGENIERÍA DEL SOFTWARE I
INGENIERIA DE SISTEMAS 1

INGENIERIA DE SISTEMAS
FACULTAD DE CIENCIAS BÁSICAS E
INGENIERÍA
CRÉDITOS
El módulo de estudio de la asignatura Ingeniería del Software I es propiedad de la Corporación Universitaria Remington.
Las imágenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas en la
bibliografía. El contenido del módulo está protegido por las leyes de derechos de autor que rigen al país.
Este material tiene fines educativos y no puede usarse con propósitos económicos o comerciales.
AUTOR
Rodrigo Alcides Patiño Arango
Ingeniero de sistemas
Experiencia 5 años
rodrigo.patino@remington.edu.co
Yolfaris Naidit Fuertes Arroyo

Ingeniera de Sistemas. (5 años de labor docente)
yolisfuertes@gmail.com yolfaris.fuertes@remington.edu.co
Nota: el autor certificó (de manera verbal o escrita) No haber incurrido en fraude científico, plagio o vicios de autoría;
en caso contrario eximió de toda responsabilidad a la Corporación Universitaria Remington, y se declaró como el único
responsable.
RESPONSABLES
Dr. Mauricio Sepúlveda
Director de la ESCUELA DE CIENCIAS BÁSICAS E INGENIERÍA
Director Pedagógico
Octavio Toro Chica
dirpedagogica.director@remington.edu.co
Coordinadora de Medios y Mediaciones
Angélica Ricaurte Avendaño
mediaciones.coordinador01@remington.edu.co
GRUPO DE APOYO
Personal de la Unidad de Medios y Mediaciones
EDICIÓN Y MONTAJE
Primera versión. Febrero de 2011.
Derechos Reservados
Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.
TABLA DE CONTENIDO
1. MAPA DE LA ASIGNATURA.............................................................................................. 8
2. CONTEXTUALIZACIÓN DE LA INGENIERÍA DEL SOFTWARE .................................................. 9
2.1. Ingeniería del software .................................................................................................... 11
2.1.1. Introducción a la ingeniería del software .......................................................................... 11
2.1.2. Estándares y modelos .................................................................................................... 13
2.1.3. Proyecto SWEBOK ......................................................................................................... 14
2.2. Un sistema ..................................................................................................................... 17
2.3. Ejercicio Tema 1.............................................................................................................. 19
2.4. Ingeniería de sistemas ..................................................................................................... 20

2.4.1. Ingeniería de software ................................................................................................... 20
2.5. Ejercicio Tema 2.............................................................................................................. 25
2.6. El proceso ...................................................................................................................... 26
2.6.1. Visión General del Proceso ............................................................................................. 26
2.6.2. Modelos de proceso ...................................................................................................... 28
2.7. Ejercicio Tema 3.............................................................................................................. 33
3. ENFOQUE DE LA INGENIERÍA DEL SOFTWARE ................................................................. 37
3.1. Ingeniería de sistemas basados en computadora ................................................................ 39
3.1.1. Sistemas Basados en Computadora ................................................................................. 39
3.2. Ejercicio del tema 1 ......................................................................................................... 42
3.3. La práctica: una visión genérica......................................................................................... 42
3.3.1. La práctica de la Ingeniería del Software .......................................................................... 42
3.4. Ejercicio tema 2 .............................................................................................................. 55
3.5. Ingeniería de Requisitos ................................................................................................... 55
3.5.1. Un puente hacia el diseño y la construcción ..................................................................... 55
3.6. Ejercicio tema 3 .............................................................................................................. 63
4. FILOSOFÍA ACERCA DE LA INGENIERÍA DEL SOFTWARE .................................................... 65
4.1. Programación Orientada A Objetos ................................................................................... 67
4.1.1. Orientación a objetos .................................................................................................... 67
4.1.2. UML ............................................................................................................................ 68
4.1.3. Objetivos y Usos del
XML ...................................................................................................................................... 73
4.1.4. SEI / CMM / CMMI ........................................................................................................ 74
4.2. Ejercicio del tema 1........................................................................................................ 76
5. ESTÁNDARES Y METODOLOGÍA ..................................................................................... 78
5.1. Ingeniería del Software de Sala Limpia ............................................................................... 80
5.1.1. El enfoque de sala limpia................................................................................................ 80
5.2. Ejercicios tema 1 ............................................................................................................. 83
5.3. Componentes del software .............................................................................................. 83
5.3.1. Ingeniería de software basada en componentes ............................................................... 83
5.3.2. El proceso ISBC ............................................................................................................. 85
5.4. Ejercicios tema 2 ............................................................................................................. 89
5.5. Reingeniería ................................................................................................................... 90
5.5.1. Reingeniería de Procesos de Negocios ............................................................................. 90
5.5.2. Reingeniería del Software .............................................................................................. 91
5.6. Ejercicio tema 3 .............................................................................................................. 94
6. PISTAS DE APRENDIZAJE ............................................................................................... 97
7. GLOSARIO ................................................................................................................... 98
8. BIBLIOGRAFÍA.............................................................................................................. 99
1
. MAPA DE LA ASIGNATURA
NOMBRE DE LA ASIGNATURA
PROPÓSITO GENERAL DEL MÓDULO

Dar a los estudiantes los conocimientos necesarios para que desarrollen software de alta calidad
utilizando los enfoques, herramientas y métodos requeridos para cada proceso y aplicables en cualquier
área del conocimiento.
OBJETIVO GENERAL
Comprender los diferentes enfoques que propone la Ingeniería del software los cuales reglamentados
bajo estándares de calidad sirven de guía inductiva al momento del desarrollo de un producto.
OBJETIVOS ESPECÍFICOS
Diferenciar claramente los diversos enfoques, estándares y metodologías que rigen a la ingeniería del
software y los diversos procesos que hacen que los proyectos funcionen adecuadamente.
Dar a conocer la bondades que tiene la práctica de la ingeniería del software como una guía que
coadyuva a la solución de las diversos problemáticas que tienen las empresas en cuanto al
control y manejo de la información, aplicando diversos modelos que ilustren de una manera
eficaz la forma como deben orientarse para su permanencia en el medio.
Aplicar conceptos claros del software mediante el uso de herramientas que faciliten la manera
del desarrollo de aplicaciones que satisfagan las necesidades del cliente al menor costo y en el
menor tiempo posible.
Desarrollar en el estudiante un alto grado de análisis, que le permita la comprensión de la estructura del
conocimiento de la ingeniería del software, para aplicarlo posteriormente en los diferentes tipos de
resolución de problemas que puedan presentarse aplicables en diversas áreas
UNIDAD 1 UNIDAD 2 UNIDAD 3 UNIDAD 4

Capacidad para Habilidad para Capacidad Habilidad para
comprender la identificar los Para realizar software de
introducción a la diferentes comprender los alta calidad bajo la
Ingeniería del enfoques procesos de la reglamentación de
Software estructurados de programación los estándares
la Ingeniería del orientada a necesarios o
Software objetos, XML y requeridos para
UML cada proceso de
desarrollo.
OBJETIVO GENERAL
Diferenciar claramente los diversos enfoques, estándares y metodologías que rigen a la ingeniería del
software y los diversos procesos que hacen que los proyectos funcionen adecuadamente.
OBJETIVOS ESPECÍFICOS
Reconocer la historia que enmarca el nacimiento de la Ingeniería del Software como disciplina.
Reconocer la historia y la estructura del conocimiento de la Ingeniería del Software a través de
los conceptos de Herramientas, Métodos, Procesos y Filosofías y/o Enfoques, analizando el
nivel de complejidad y las diferentes premisas y enfoques que existen respecto a la
Ingeniería del Software.
Diferenciar las Filosofías de pensamiento alrededor de la Ingeniería del Software y los estándares
y metodologías aplicadas
Prueba Inicial
En los siguientes enunciados seleccione la respuesta correcta
1. El software es:
a. La parte tangible del computador.

b. Un estándar específico de un modelo sistémico.
c. Modelo de proceso.
d. Parte intangible del computador.
e. Todas las anteriores.
f. Ninguna de las anteriores.
2. Un estándar es:
a. Una colección de componentes reutilizables.
b. Una reestructuración del hardware.
c. Normas internacionales que controlan el desarrollo del software.
d. Conjunto de instrucciones que permite al hardware de la computadora desarrollar un trabajo
útil.
3. Un sistema es:
a. Es la aproximación sistemática, disciplinada y cuantificable para desarrollar, operar y

mantener software.
b. Colección de componentes organizados para cumplir una función o conjunto de funciones
específicas.
c. Organización que da el primer paso necesario para constituir a la Ingeniería del Software
como profesión
d. Son los pasos predecibles que se deben seguir para desarrollar un programa.
4. Un marco de trabajo es:
a. Un conjunto de componentes tangibles.

b. Una evolución del software.
c. Un proyecto generado de argumentos sistémicos.
d. Un conjunto de actividades o tareas desarrolladas.
f. Ninguno de los anteriores.
5. La subdivisión que tiene un ciclo de mejora de un proceso es:
a. Planear, ejecutar, medición y mejora

b. Ejecutar, planear, medir y mejorar
c. Medir, planear, ejecutar y mejorar
d. Mejorar, medir, planear y ejecutar
6. El software de computadora es
a. El producto que los diseñadores de software construyen.

b. El producto que los técnicos de sistema construyen.
c. El producto que los ingenieros de software construyen.
d. Todas las anteriores.
e. Ninguna de las anteriores.
2.1. Ingeniería del software
2.1.1. Introducción a la ingeniería del software

El software es una reunión de aplicaciones que se instalan y ejecutan dentro de un sistema de
computacional. Estos programas los construyen los ingenieros de software. Se construye como
cualquier otro producto, buscando principalmente la satisfacción del usuario o cliente, lo cual se
refleja en la calidad con la cual es construido el producto. El software se ha convertido en un factor
que limita la evolución de los sistemas informáticos.
2.1.1.1 Definición Hardware

“El hardware es la parte tangible del computador, todos los elementos materiales que se pueden
tocar, como los dispositivos electrónicos y electromecánicos, entre estos tenemos (Monitor, Teclado,
Mouse, Main board, Disco duro, Memorias RAM (memoria de acceso aleatorio) y ROM (memoria de
solo lectura), unidades de almacenamiento de la información (CD, disquete, USB), parlantes,
procesador, entre otros)”1.
2.1.1.2 Definición Software
El software es la parte intangible del computador, lo que usted puede visualizar pero que no puede
tocar. Es catalogado como el alma del computador. Es el resultado que obtienen los ingenieros de
software al terminar su trabajo o labor. Se debe tener presente que el software no se desgasta, pero
si se deteriora. Dentro de las partes del software tenemos:
a. Sistema Operativo: el cual controla el funcionamiento del computador y de todos los programas.
(Dirige), o sea, que le permite al usuario comunicarse con el computador. Entre los sistemas
operativos más conocidos tenemos: Dos, Windows (y sus diferentes versiones),
NetWare, Unix, entre otros.
b. Aplicación: permite realizar trabajos o tareas específicas. Entre estas tenemos: Word, Excel,
juegos, etcétera.
c. Lenguajes de programación: permiten crear a aplicaciones. Entre estos tenemos: Lenguaje C,
Pascal, Visual Basic, Java, Visual Fox Pro, Fox Pro, .Net, entre otros.
1
www.slideshare.net/.../diapositivas-de-ingenieria-de-software, Diapositivas De Ingenieria De Software, tomado el 10-
05-2011.
Desarrollo del Hardware
La aparición de componentes que cada dos años doblan la capacidad de sus antecesores nos ha
rodeado en menos de cuatro décadas de máquinas capaces de procesar miles de millones de
operaciones por segundo (MTOPS).
En 1946 ENIAC ocupaba una superficie de 160 m2, pesaba 30 toneladas, y ofrecía una capacidad de
proceso de 30.000 instrucciones por segundo. En 2002 El microprocesador Pentium IV a 2 GHz ocupa
una superficie de 217 mm2 y tiene una capacidad de proceso de 5.300 MTOPS (“Millions of
theoretical operations per second) Este es el escenario creado por la industria del hardware, y que en
las tres últimas décadas ha implicado a los desarrolladores de software en retos a los que no han
sabido responder con solvencia.
La crisis del Software

Este término fue acuñado en los años 70, cuando la industria o imperio del software ya había
producido los suficientes programas que le permitieron darse cuenta de que en ellos algo fallaba, que
no se había podido satisfacer la necesidad perseguida (que los programas al entregarse al cliente
tuvieran garantizada la excelencia) Debido a esto salieron a la vista varios interrogantes objetos de
estudio y análisis previo:
¿Por qué lleva tanto tiempo terminar los programas?

¿Por qué es tan elevado el coste?
¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros
clientes?
¿Por qué es tan difícil constatar el progreso durante el desarrollo?

¿Por qué es tan difícil calcular cuánto tiempo va a costar?
Definitivamente en la época de los 70, la industria del software no había podido satisfacer la demanda
visionada. La complejidad del software producido y demandado se incrementaba constantemente.
Se debe tener presente que aún desde los años atrás hasta nuestra época el software es solicitado
para ejecutar las tareas demandantes que exige el medio y sobre todo está presente en todos los
sistemas que van desde los más sencillos hasta los de misión crítica.
Se puede afirmar entonces que las aplicaciones de software son complejas porque modelan la
complejidad del mundo real. Por lo tanto, si el cliente (persona que solicita la realización de un
programa o software) tiene claro qué quiere, interferirá mucho menos en el proceso de desarrollo,
obligando a cambiar aspectos que ya habían sido convenidos previamente con el desarrollador.
Más sin embargo no podemos descartar que ciertamente el cliente por lo general casi siempre le
exigirá cambios al desarrollador cuando ya ciertos aspectos del código estén terminados, por lo cual
es aconsejable pactar muy bien por escrito todas las exigencias del cliente antes de iniciar a construir
el código, para evitar complicaciones futuras2.
2.1.2. Estándares y modelos
“Definición:
Son normas internacionales que reglamentan y controlan el desarrollo de software a nivel mundial.
Los estándares son útiles porque:
Agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software, lo
cual permite construir software de alta calidad.
Proporcionan un marco (teórico-práctico) para implementar procedimientos de aseguramiento
de la calidad.
Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones
distintas”3.
Principales organizaciones de estandarización
“ ISO: Organización Internacional para la Estandarización.

En 1987 la (ISO) y la Comisión Internacional Electrotécnica (IEC), establecieron un Comité
Internacional (JTC1) para las Tecnologías de la Información. La misión del JTC1 es la “estandarización
en el campo de los sistemas de tecnologías de la información, incluyendo microprocesadores y
equipos.
Los estándares más importantes para la ISO son.

ISO/IEC 12207
ISO/IEC TR 15504
SEI: Instituto de Ingeniería del software.

IEEE: Instituto de Ingenieros en electricidad y electrónica, entre otras”4.
2
Roger S. Pressman
3
www.slideshare.net/.../diapositivas-de-ingenieria-de-software, Diapositivas De Ingeniería De Software, tomado 10-
05-2011
4
serdis.dis.ulpgc.es/.../02. %20Estandares%20y%20modelos%20de%20Ingenieria%20del%2... -, Resultados de la
búsqueda [PDF]
(Microsoft PowerPoint - Est\341ndares y modelos de Ingenier\355a ..., tomado el 10-05-2011
2.1.3. Proyecto SWEBOK
“Un Ingeniero de Software debe conocer las técnicas de cada momento, pero la definición de
procesos y metodología de trabajo es la “esencia” de la profesión. Así por ejemplo, el área de
conocimiento de requisitos, sí que puede considerarse como “esencia” de la profesión. Los problemas
que pueden derivarse en un proyecto por una mala obtención o gestión de los requisitos son
indistintos del hardware o lenguaje de programación empleado”5. Se puede afirmar que estos eran
los mismos hace dos décadas que ahora, y todo nos hace suponer que seguirán siendo idénticos
dentro de otros años venideros.
El proyecto SWEBOK fue quien constituyó a la Ingeniería del Software como profesión, se puede decir
que la certificó, para lo cual se tuvieron en cuenta varias áreas o requisitos necesarios para garantizar
la calidad del proyecto. Entre estos tenemos:
Gestión de la configuración
Gestión (planificación, supervisión y control de los métodos, procesos y herramientas) Los
Procesos (estrategias de planeación)
Herramientas y métodos (como centro de partida del proyecto)
Calidad (totalmente garantizada)
Requisitos (necesariamente de la etapa de comunicación y de los procesos)
Diseño
Construcción (código)
Pruebas (reglamentadas)
Mantenimiento (realimentación)
El proyecto parte de la suposición de que es necesario establecer cuál es el cuerpo de conocimiento

que deben conocer los ingenieros del software, y en su desarrollo ha agrupado estas 10 áreas del
conocimiento.
Es importante resaltar que estas áreas no incluyen aspectos importantes de las tecnologías de la
información, tales como lenguajes específicos de programación, bases de datos relacionales o redes o
tecnología de redes y comunicaciones.
Esta es una consecuencia de la distinción que entre “esencia” y “accidente” se establece desde un
enfoque de ingeniería.
5
www.slideshare.net/evelio/ingenieria-del-software, ingenieria del software, tomado 10-05-2011
Por supuesto que un Ingeniero de Software debe tener presente y conocer las técnicas de cada
momento, pero la definición de procesos y metodología de trabajo es la “esencia” de la profesión.
Como se comentó al comienzo del tema de Swebok. Se puede afirmar que es lo principal. Así por
ejemplo, el área de conocimiento de requisitos, sí que puede considerarse como “esencia” de la
profesión.
Los problemas que pueden derivarse en un proyecto por una mala obtención o gestión de los
requisitos son indistintos del hardware o lenguaje de programación empleado. Recuerde que los
problemas del proyecto parten de la etapa de comunicación (programador – cliente), ya que se
planea, analiza y construye lo que se recopila como centro de información necesaria para la
realización del producto final.
ISO 12207
Establece un marco en el ciclo de vida del software para la adquisición, suministro, desarrollo,
operación y mantenimiento del software, así como también para gestionar, controlar y mejorar el
marco de trabajo que incluye la realización del cada proceso que conlleve a la realización del
producto, lo que sirve como base de referencia para el trabajo e intercambio entre organizaciones de
software.
Ciclo de vida del software

Periodo de tiempo que comienza al concebir la idea de un nuevo sistema de software, y termina
cuando este se retira y deja de funcionar.
La ISO 12207 Define el QUÉ, no el CÓMO6.

Dice cuáles son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y
operación de los sistemas de software, asentando un marco estándar de referencia internacional,
pero no se ocupa ni prescribe técnicas específicas. El estándar sirve de referencia desde dos
perspectivas diferentes:
Para la adquisición de sistemas y servicios de software.

Para el suministro, desarrollo, mantenimiento y operación de productos de software.
El estándar no cubre el desarrollo de productos de software para distribución comercial masiva

(productos “en caja”).
Exactamente define los procesos que componen el ciclo de vida del software.
6
http://www.slideshare.net/msc080277/ingenieria-del-software2872 consultado el 24-06-2009
Gráfico #1 (Elaborado por los Autores)
Por lo cual se puede afirmar que un proceso está compuesto por actividades y estas a su vez por
tareas.
Gráfico #2(Elaborado por los Autores)
Programación actividades o tareas.
El ciclo de mejora de un proceso que lo componen actividades y tareas los cuales conlleva la
(Planificación, ejecución, medición y mejora)
Gráfico#3 (Elaborado por los Autores)
Ciclo de mejora del producto
ISO 12207 tiene una relación directa con la ingeniería de sistemas ya que el software se convierte en
parte importante del sistema
Pensar en desarrollar software o solucionar problemas empresariales sin tener una base sólida y un
conocimiento pleno sobre el tema es un gran error que se comete porque la persona que inicia con un
tipo de proyectos como esto tiene la gran responsabilidad sobre el trabajo encomendado y es ante
esas personas a las que le está trabajando a las que tiene que demostrarle que la solución dará a la
empresa ventajas competitivas y comparativas para poder permanecer en un mercado tan
competitivo. Y es por eso que se debe estar a la vanguardia de los nuevos avances para poder
desarrollar o solucionar problemas acordes a los lineamientos que se piden dentro de los estándares
que se deben utilizar en los cuales no se piensa en una solución para una empresa específica sino que
se piensa en empresas similares en donde la adaptación de un software debe ajustarse a los procesos
y no adaptar los procesos al software.
2.2. Un sistema
Es un conjunto de elementos que interactúan entre sí para alcanzar un objetivo específico.
Para desarrollar software, se necesita de una computadora (hardware: parte tangible del
computador), la cual está compuesta por diversos elementos o componentes (partes del hardware),
además se necesita de las personas (ingenieros de software), porque son quienes realizaran los
procedimientos que llevaran a la realización del programa o código fuente.
Cabe agregar que la Ingeniería de Sistemas es quien da paso a la Ingeniería del Software, empezando
con un entendimiento claro de todo el contexto que involucra tanto a los detalles técnicos como a los
diferentes procedimientos que se llevarán a cabo en la búsqueda del resultado esperado (producto o
software).
Ingeniería de sistemas comprende la Gestión de proyectos, función de planificar, supervisar y

controlar todo el esfuerzo de desarrollo para conseguir un balance óptimo entre todos los elementos
del sistema. Es el proceso que transforma la necesidad operacional en la descripción de los
parámetros del sistema (necesario para analizar o valorar la situación), e integra esos parámetros para
mejorar la eficiencia general del sistema.
Funciones de la Ingeniería de sistemas
“Definición del problema: Determinación de las expectativas hacia el producto, necesidades y

restricciones obtenidas y analizadas en los requisitos del sistema. Trabaja cerca del cliente para
establecer las necesidades operacionales.
Análisis de la solución: Determinar las opciones posibles para satisfacer los requisitos y las
restricciones. Estudiar y analizar las posibles soluciones. Seleccionar la mejor, sopesando las
necesidades inmediatas, opciones de implementación, utilidad, evolución del sistema
Planificación de los procesos: Determinar los grupos de tareas técnicas que se deben realizar, el
esfuerzo requerido para cada una, su prioridad y los riesgos que implican para el proyecto.
Control de los procesos: Determinar los métodos para controlar las actividades técnicas del
proyecto y los procesos; la medición del progreso, revisión de los productos intermedios y
ejecución de las acciones correctivas, cuando corresponda.
Evaluación del producto: Determinar la calidad y cantidad de los productos elaborados, a través
de evaluaciones, pruebas, análisis, inspecciones”7.
www.slideshare.net/.../unidad-uno-ingenieria-de-software, Unidad uno ingeniería de software, tomado el 10-05-2011

Gráfico #4 (Elaborado por los autores)
Ingeniería de sistemas – Gestión de proyectos – Ingeniería del Software
2.3. Ejercicio Tema 1
Mencione algunos ejemplos (3) positivos y negativos que indiquen el impacto del software en la
sociedad actual.
¿Qué haría usted para reducir el deterioro del software?
Mencione algunas posibles fallas del hardware y posibles soluciones para evitar estas fallas (3)
¿Cuáles son las principales organizaciones de estandarización?
¿Cree usted que una vez que el programa (software) ha sido terminado y puesto a funcionar EL
TRABAJO ESTÁ TERMINADO. Si – No. Por qué? EXPLIQUE
¿Cuál es el ciclo de mejora para la descomposición de un proceso en actividades y tareas?
2.4. Ingeniería de sistemas
2.4.1. Ingeniería de software
En la actualidad, el software es considerado el producto más importante dentro del campo

tecnológico mundial, debido a su crecimiento o desarrollo, se ha hecho tan indispensable en los
diferentes sectores de aplicación organizacional (sistemas de todo tipo), permitiendo rapidez en la
ejecución de los procesos, confiabilidad al momento de realizar una tarea específica, seguridad en el
manejo de la información, automatización de los procesos, etcétera.
La ingeniería de software se puede definir como la rama de la ingeniería que crea y mantiene las
aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de
proyectos, el ámbito de la aplicación, y otros campos. Esta ingeniería abarca un proceso, métodos y
herramientas fundamentados en el desarrollo del producto bajo normas o estándares que
reglamenten la calidad.
2.4.1.1 Software e Ingeniería del Software

En la actualidad, el software de computadora es la tecnología individual más importante en el ámbito
mundial. Es común darse cuenta que la invención de una tecnología puede tener efectos profundos e
inesperados en otras tecnologías con las que en apariencia no tiene ninguna relación.
(ESTE FENOMENO SE COMO LA LEY DE LA S CONSECUENCIAS IMPREVISTAS). El software se ha
convertido a través de los años en una tecnología indispensable en los negocios, la ciencia y la
ingeniería.
El software también ha permitido la creación de tecnologías nuevas como la ingeniería genética, ha

permitido la expansión de tecnologías existentes como las telecomunicaciones, el fin de tecnologías
antiguas como la industria de la impresión. En fin, se puede afirmar que el software es la fuerza
conductora de la tecnología del presente, ya que está relacionado con sistemas de todo tipo:
transporte, médicos, telecomunicaciones, militares, industriales, de entretenimiento, máquinas para
oficina entre otros.
El software de computadora es el producto que los Ingenieros de Software construyen: incluye los
programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura. Lo
construyen los ingenieros de software y casi todos en el mundo industrializado lo usan de manera
directa o indirecta.
Es importante porque afecta de forma muy cercana todos los aspectos de nuestras vidas. Este
software de computadora se construye de la misma forma que cualquier producto de éxito, mediante
la aplicación de un proceso que conduzca a un resultado de alta calidad que satisfaga las necesidades
de las personas que utilizaran el producto (se hace referencia a los programas, los cuales contienen
los datos y los demás documentos que constituyen el software) desde el punto de vista del usuario el
producto obtenido es la información.
En la sociedad moderna el papel de la ingeniería es proporcionar sistemas y productos que mejoren

los aspectos materiales de la vida humana, para que así la vida sea más fácil, segura y placentera8.
(Richard Fairley y Mery Willshire)
El papel evolutivo del software

El software es tanto un producto como el vehículo para su entrega. Es el transformador de la
información. El papel del software de computadora ha experimentado un cambio significativo en un
periodo un poco mayor a 50 años. Las mejorías sustanciales en el desempeño del hardware, los
cambios profundos en las arquitecturas de cómputo, los enormes incrementos en las capacidades de
memoria y almacenamiento, y la amplia variedad de opciones de salida y de entrada han propiciado el
surgimiento de sistemas más elaborados y complejos basados en computadoras.
Nadie sabe en realidad el futuro de los sistemas que día a día se construyen, más sin embargo sin
importar el lugar en el que resida el software, ya sea en un celular o dentro de una computadora
central, el software realiza la producción, el manejo, la adquisición, la modificación, el despliegue o la
transmisión de la información que puede ser tan simple como un solo bit o tan compleja como una
presentación multimedia. En su papel de vehículo para la entrega de un producto, el software actúa
como la base para el control de la computadora (sistemas operativos), la comunicación de
información (redes) y la creación y el control de otros programas (utilerías de software y ambientes).
9
El software entrega el producto más importante de nuestro tiempo: información. Transforma los
datos personales, por ejemplo las transacciones financieras de un individuo, de modo que los datos
sean más útiles en un contexto local. Maneja información de negocio para mejorar la competitividad,
proporciona una vía para las redes de información alrededor del mundo (Internet) y proporciona los
medios para adquirir información en todas sus formas (páginas web).
Se debe tener presente que el software es un elemento lógico en lugar de físico, de un sistema (parte
intangible del computador). El software se desarrolla o construye, no se manufactura (componentes
del hardware, los cuales pueden incluir problemas de calidad inexistentes o sea, fácil
8
Roger S. Pressman
9
Roger S. Pressman
de corregir en el software), el software no se desgasta, pero se deteriora (el cual se corrige con un
mejor diseño: implementación)
Los costos del software se concentran la ingeniería, esto quiere decir que los proyectos de software
no se pueden manejar como si fueran proyectos de manufactura. El hardware tiene un número
considerablemente alto de posibles fallas al inicio de su vida útil, se hace referencia a defectos de
diseño de fábrica (manufactura). También con el tiempo causa fallas en el hardware la acumulación de
polvo (falta de mantenimiento), la alta vibración, el abuso del hombre sobre los diferentes
componentes, las temperaturas extremas y muchos otros factores que hacen parte del medio
ambiente. Se puede decir que el hardware comienza a desgastarse, o peor aún a dañarse.
El software es inmune a los males ambientales que desgastan al hardware. Los errores del software
se corrigen, o sea que se implementan, más sin embargo se debe tener en cuenta la innovación o
mejor permanente de los programa, ya que este si tiende a deteriorarse.
En muchos casos se confunden los términos en cuanto a deterioro del software o problemas en el
desarrollo del software ya que este primero se puede deteriorar por las actualizaciones que se dan
permanentemente en el hardware o software, pero internamente el software no sufre problemas a
menos que sea por falla de hardware principalmente en el disco duro y la segunda parte si se puede
presentar con frecuencia debido a errores que no se detectaron en el momento de realizar las
pruebas o en muchos casos las dificultades que se presentaban en el desarrollo que se dejan para
corregir y luego esto se olvida.
Por eso es importante entender que lo que se busca con un software es solucionar los problemas
generando aplicaciones que tengan el menor error posible para que así la empresa pueda disminuir la
cantidad de tareas repetitivas que en muchas ocasiones se presentan y sus empleados hagan buen
uso del tiempo laboral.
La Naturaleza cambiante del software

En la actualidad existen siete grandes categorías del software de computadora que presentan retos
continuos para los ingenieros de software.
Software de sistemas:
Colección de programas escritos para servir a otros programas. Ejemplo: los compiladores, editores y
utilerías para la administración de archivos, los cuales procesar estructuras de información compleja
pero determinada. Otras aplicaciones de sistemas como los componentes del sistema operativo,
controladores, software de red, procesadores para telecomunicaciones, procesan datos
indeterminados
.
Software de aplicación:
Son programas independientes que resuelven una necesidad de negocios específica. Ejemplo: el
procesamiento de transacciones en los puntos de venta.
Software científico y de ingeniería:

Se caracteriza por algoritmos. Abarca desde la astronomía hasta la vulcanología, desde el análisis de la
tensión automotriz hasta la dinámica orbital de los transbordadores espaciales, y desde la biología
molecular hasta la manufactura automatizada. Diseño asistido por computadora.
Software incrustado o empotrado:

Reside en la memoria de solo lectura del sistema y con él se implementan y controlan características y
funciones para el usuario final y el sistema mismo. Ejemplo: control del teclado de un horno
microondas, las funciones digitales de un automóvil, como el control de combustible, los sistemas de
frenado, entre otros.
Software de línea de productos:

Diseñado para proporcionar una capacidad específica y la utilización de muchos clientes diferentes, se
puede enfocar en un nicho de mercado limitado. Ejemplo: productos para el control de inventarios,
hojas de cálculos, multimedia, entretenimiento, manejo de BD, administración de personal y finanzas
en los negocios.
Aplicación basada en Web:

Las “WebApps” engloban un espectro amplio de aplicaciones. En su forma más simple, las WebApps
son apenas un poco más que un conjunto de archivos de hipertexto ligados que presentan
información mediante texto y algunas gráficas. Actualmente estas aplicaciones están integradas con
base de datos y aplicaciones de negocios, ya que proporcionan características que les permite
evolucionar hacia ambientes computacionales sofisticados.
Software de inteligencia:
Utiliza algoritmos no numéricos en la resolución de problemas complejos que es imposible abordar
por medio de un análisis directo. Incluye la robótica, el reconocimiento de patrones (imagen y voz),
los juegos de computadoras, entre otros10.
Es de suma importancia reconocer las distintas categorías de software que existen en el medio para
determinar en un momento determinado lo que la empresa tiene ya sea para la implementación de
un sistema similar o la modificación en caso de estar llevando una asesoría a nivel general.
No cualquier categoría de estas sirve para cualquier tipo de empresa sino que esto depende de su
razón social, de su misión y visión, por eso es recomendable realizar el levantamiento de información
necesaria para no seguir cometiendo los errores en los que muchos desarrolladores han caído.
Software Heredado
Hace referencia al software o programas viejos, aquellos que utilizan tan solo algunas entidades
empresariales, gubernamentales o individuos. Estos fueron desarrollados hace décadas y han sido
modificados en forma continua (mejorados o innovados) para cumplir los requerimientos de los
cambios en los negocios y en las plataformas de cómputos. Ejemplo: Unix, FoxPro, Dos, entre otros.
Aquí se puede hacer énfasis a
los programas de computadora que hacen parte de los siete grandes dominios de aplicación que se
relacionó en el tema de la naturaleza cambiante del software.
Debe tenerse presente que todo sistema (el software es un sistema de información de cualquier
índole) si desea preservarse debe adaptarse al medio o entorno que lo rodea. Una de las principales
características de los sistemas es la adaptabilidad y evolución (crecimiento) constante.
Algunas veces el software heredado tiene diseños imposibles de extender, códigos complicados,
documentación escasa o inexistente, casos de prueba y resultados que nunca fueron archivados, un
historial de cambio manejado con pobreza, etcétera. Sin embargo, este software es indispensable
para algunas entidades, por lo tanto, aunque el programa sea viejo, pero si presta su utilidad o
satisface las necesidades del usuario y funciona de manera confiable, se dice que el sistema no está
roto ni requiere arreglos.
Sin embargo, conforme pasa el tiempo la tecnología evoluciona rápidamente, por lo tanto el software
debe adaptarse para satisfacer las necesidades de los nuevos ambientes o las nuevas tecnologías de
cómputos. El software debe mejorarse para una mejor implementación de su servicio, o sea
rediseñarse.
El proceso del software
10
Roger S, Pressman
Son los pasos predecibles que hay que realizar para crear el programa o código que permitirá la
satisfacción de una de las necesidades del cliente desde el campo de la preservación de la
información. Es decir, un mapa de carretera que ayude a crear un resultado de alta calidad y a tiempo.
(Definirlo, construirlo y probarlo), es importante seguir los pasos porque ofrece estabilidad, control y
organización a una actividad que puede volverse caótica si no se controla. Este enfoque debe ser ágil,
debe requerir solo aquellas actividades, controles y documentaciones apropiados para el equipo del
proyecto y el producto que ha de producirse. Se está seguro de que se ha hecho correctamente
cuando se determina la madurez, la calidad, la viabilidad del producto que se construye.
Defina con sus propia palabras que es un sistema y de por lo menos 4 ejemplos
El desarrollo de software se ve constantemente impedido por la lentitud en la creación de

componentes hardware y mecanismos que servirán para que extienda su potencial. (está de
acuerdo: si – no) PORQUÉ?
El modelo prescriptivo de procesos se propusieron para ordenar el caos que se pueda presentar
en el desarrollo del software. Todos los modelos relacionados establecen unas etapas
fundamentales que se deben tener presente al momento de desarrollar software de alta calidad.
Establezca un conjunto de actividades para la etapa de comunicación.
Relacione algunos ejemplos (positivos o negativos) que indiquen el impacto que ha tenido el
software en la sociedad actual.
Que impacto ha generado el avance tecnológico (involucrando software) en usted y por qué?
Defina con palabras propias lo que es para usted la ingeniería del software?
La ingeniería del software es una tecnología estratificada. Abarca un proceso, métodos y

herramientas fundamentales al momento de desarrollar software de alta calidad. Para usted,
cual es este proceso, herramientas y métodos que requiere esta ingeniería para el desarrollo de
software.
Las siguientes etapas hacen parte de la Ingeniería de Sistemas:
a. Codificación, planificación de procesos, control de procesos, evaluación del producto, diseño de

software.
b. Análisis de la solución, evaluación organizacional, control de procesos, comunicación, supervisión
del problema.
c. Evaluación del producto, definición del problema, supervisión del problema, control del proceso,
pruebas unitarias.
d. Control de procesos, análisis de la solución, evaluación del producto, planificación de procesos,
definición del problema.
f. Ninguna de las anteriores, Justifique su respuesta con un ejemplo.
Haga un análisis con respecto al papel evolutivo del software
2.6. El proceso
2.6.1. Visión General del Proceso
El desarrollo del software es un proceso de aprendizaje social, es un proceso iterativo de aprendizaje y

como resultado la materialización del conocimiento recolectado, depurado y organizado conforme el
proceso estuvo en ejecución.
El proceso de un software es
un marco de trabajo para las tareas que se requieren en la construcción de software de alta calidad. El
proceso es un sinónimo de Ingeniería del Software. Un proceso de software define el enfoque que se
adopta mientras el software está en desarrollo, pero la ingeniería del software también abarca las
tecnologías que requiere el proceso (métodos técnicos y herramientas automatizadas)11.
La ingeniería del software la realizan personas creativas y con conocimiento que deben trabajar en un
proceso de software madurado que sea apropiado para el producto que construyen y para las
demandas de sus mercados.
11
Roger S. Pressman
2.6.1.1 Estratificación del proceso
Se aplica al desarrollo de software de computadora, de que manera se construye, económicamente

que sea un software confiable, que funcione eficientemente en varias máquinas reales. Se busca la
compatibilidad Software Hardware, Más que una disciplina o un cuerpo de conocimiento, la
ingeniería es un verbo, una tecnología estratificada, una palabra de acción, una manera de abordar
un problema el cual al final debe estar sustentado en un compromiso con la calidad, fiabilidad y
viabilidad del producto.
Estratos de la Ingeniería del Software
Marco de trabajo
Establece la base para un proceso de software completo al identificar un número pequeño de

actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su tamaño
o complejidad. Abarca un conjunto de actividades que a su vez contienen conjuntos de acciones, es
decir una serie de tareas
relacionadas que producen un producto del trabajo en la ingeniería del software. Además el marco de
trabajo abarca un conjunto de actividades sombrilla aplicable a lo largo del proceso del software)
Un proceso define quien está haciendo qué, cuándo y cómo lograr cierta meta. (Ivar Jacobson, Grady
Booch y James Rumbaugh)
Marco de Trabajo (actividad sombrilla)
2.6.2. Modelos de proceso
Comunicación: Implica una intensa colaboración y comunicación con los clientes, además
abarca la investigación de requisitos y otras actividades relacionadas que ayudaran a un mejor
entendimiento de lo que se desea como producto final.
Planeación: 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 requerido, los
productos del trabajo que han de producirse y un programa de trabajo.
Modelado: Esta actividad abarca la creación de modelos que permiten al desarrollador y al

cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlo.
(Análisis y diseño)
Construcción: esta actividad combina la generación del código (ya sea manual o
automatizado) y la
realización de pruebas necesarias para descubrir errores en el código.
Despliegue: el software se entrega al cliente parcialmente para que lo evalúe y a su vez para
que proporcione la información basada en su evolución12..
12
Roger S. Pressman
Al desarrollar aplicaciones o solucionar problemas empresariales es importante llevar a cabo cada uno
de los modelos de procesos con todos sus principios porque esta documentación orienta al analista a
encontrar las dificultades que existen y así dar soluciones acordes a las necesidades de las empresas u
organizaciones.
Aunque es de entender que no todos los principios que se tienen se ajustan en su totalidad a los
problemas presentes para lo cual se debe investigar más sobre el tema y así complementar estos
principios, no olvidando que se debe generalizar para que esas soluciones puedan servir para otras
empresas u organizaciones y así se puede disminuir el tiempo de entrega de las soluciones.
La visión sistémica debe estar presente en todos los proyectos que se estén elaborando ya que es el
cimiento sobre el cual gira todo. Es bueno indagar de forma general sobre cada uno de los niveles
para observar distintos puntos de vista y así tener un mejor enfoque en la solución de problemas.
Visión sistémica de la Ingeniería del software
Gráfico #7 Elaborado por los Autores

Estructura del conocimiento en la I.S.
Filosofía - Enfoque
ISO/IEC 15504/SPICE
Ing. de sistemas
Ing. de software
Ing. de requisitos
OO
UML
XMI
CMM y CMMI
IEEE
Ing. del software de sala limpia
Ing. del software basada en componentes
Reingeniería de software
Proceso
Modelo O. Genérico
Modelos O. prescriptivos
Modelos O. ágiles
Modelos O. web
Modelos de gestión
Métodos
Modelado del análisis

Ing. del diseño
Diseño arquitectónico
Diseño a nivel de componentes
Diseño de la interfaz de usuario
Estrategias de prueba de software
Técnicas de prueba de software
Métricas del software
Métodos formales y/o matemáticos
Herramientas
Diagramas de escenarios
Diagramas de flujo
Diagramas de clases
Diagramas de comportamiento
Etc.
Nivel de la complejidad del producto de la Ingeniería de Sistemas

Niveles de la complejidad del producto
Datos: sin asociatividad a un contexto. Ejemplo: edad.
Información: con asociatividad a un contexto. Ejemplo: menor de edad.
Conocimiento: con asociatividad a múltiples contextos. Ejemplo : comportamiento usual de

los menores de edad.
Sabiduría: Creación de principios generalizados con base en el conocimiento procedente de

fuentes diferentes. Ejemplo: Según la psicología, la neuropsicología, la neurociencia y la
sociología la situación se debe enfrentar con x o y decisiones.
Niveles de la integración del modelo de capacidad de madurez
Nivel 0: Incompleto: la gestión de requisitos no alcanza todas las metas y objetivos definidos
para avanzar al nivel 1.
Nivel 1: Realizado: Las tareas específicas para producir el producto han sido realizadas.
Nivel 2: Administrado: Todos los criterios del nivel 1 han sido satisfechos. Toda la gente que
ejecuta el trabajo tiene acceso a los recursos adecuados para realizar su labor, los clientes
están implicados de manera activa, todas las tareas de trabajo y productos están monitoreados,
controlados y revisados y son evaluados en apego a la descripción del proceso.
Nivel 3: Definido: todos los criterios del nivel 2 se han cumplido.
Nivel 4: Administrado en forma cuantitativa: todos los criterios del nivel 3 han sido cumplidos,
además, el área del
proceso se controla y mejora mediante mediciones y evaluación cuantitativa. Los objetivos
cuantitativos para la calidad y el desempeño del proceso están establecidos y se utiliza como un
criterio para administrar el proceso.
Nivel 5: Mejorado: Todos los criterios del nivel 4 han sido satisfecho. Además, el área del
proceso se adapta y mejora mediante el uso de medios cuantitativos (estadísticos) para
reconocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del
área del proceso que se está considerando13.
Evaluación del proceso

La existencia de un proceso de software no es una garantía de que éste será entregado a tiempo, de
que satisfará las necesidades del cliente, o de que mostrará características de calidad a largo plazo.
Los patrones de proceso deben ir acompañados de una práctica sólida de la ingeniería del software.
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.
Premisas de la ingeniería del software
13
Roger S. Pressman
Se denomina premisa a cada una de las proposiciones de un razonamiento que dan lugar a la
consecuencia o conclusión de dicho razonamiento.
Cuando la ingeniería del software llegue hasta el antepenúltimo peldaño de la generación de

conocimiento, a las puertas de la sabiduría, el mundo se habrá acabado.
El desarrollo de software se ve constantemente impedido por la lentitud en la creación de

componentes hardware y mecanismos que servirán para que extienda su potencial.
La generación de nuevo hardware y de los diferentes mecanismos se realiza para el servir a las
pretensiones reprimidas de la ingeniería del software.
Diferencie claramente las categorías del software
¿Cree usted que el software heredado es de poca calidad? Justifique su respuesta
Que entiende usted por marco de trabajo y enuncie un ejemplo
Las actividades sombrilla ocurren a lo largo de todo el proceso del software. Cree usted que estas
actividades se aplican de modo uniforme a través del proceso o algunas están concentradas en
una o más actividades del marco de trabajo? (Justifique su respuesta)
¿Cuál es la subdivisión que tienen los modelos de procesos?
Realice una síntesis (consultar en internet o libros) con respeto a la subdivisión que tiene inmerso
los métodos.
Realice un ejemplo con cada uno de los niveles de capacidad de madurez ya sea desde el campo
administrativo, contable, financiero, entre otros.
Como entiende usted la premisa inicial.
¿Cuál es el propósito de la evaluación del proceso?
La ingeniería de software es una disciplina que integra al proceso, los métodos y las
herramientas para el desarrollo de software de computadora. Proponga un ejemplo
direccionado al campo organizacional en donde usted relacione estos elementos dentro de las
fases de los modelos prescriptivos de proceso.
Qué opina usted sobre el proceso de software personal.(PSP)
Qué opina usted sobre el proceso de software en equipo.(PSE)
¿Cree usted que el cambio es natural? ¿Puede usted combatir el cambio? Si___, No_____. ¿Por
qué?
(Relaciónelo con la evolución del software)
Es necesario trabajar duro para entender qué se debe hacer antes de comenzar. En ocasiones no
es posible desarrollar todos los detalles, pero entre más se sepa, menor es el riesgo que se corre
de fracasar. Siempre que se piense que no hay tiempo para la ingeniería del software, se debe
considerar si habrá tiempo para hacerlo todo de nuevo.
Realice un análisis detallado y profundo de la relación o síntesis que existe entre los siguientes
esquemas.
Plantear un ejemplo en donde se visualice a través de un concepto totalmente abstracto, el
objetivo que cumple cada uno de estos elementos en la aplicabilidad de las fases de los modelos
prescriptivos de proceso.
Prueba Final
1. Las siguientes actividades son el fundamento de la Ingeniería de sistemas:

a. Identificar, construir, evaluar, planificar y supervisar.
b. Analizar, modelar, supervisar, validar y planificar.
c. Gestionar los requisitos, supervisar, planificar, validar y controlar.
d. Modelar, validar, gestionar los requisitos, identificar y analizar.
2. Los elementos de un sistema son:

a. Hardware, personas, documentación, software y procedimiento.
b. Software, documentación, planificación, dirección y supervisión.
c. Hardware, software, procedimiento, supervisión y control.
d. Documentación, procedimiento, software, control y hardware.
3. Cuál es el objetivo principal de los estándares y cuáles son los mas utilizados dentro del desarrollo
del software
4. Que entiende usted por la ley de las consecuencias imprevistas e indique varios ejemplos en
donde esto se ha presentado
5. Son funciones de la Ingeniería de sistemas:

a. Definición del problema, análisis de la solución, codificación, despliegue y mantenimiento.
b. Control de procesos, planificación de procesos, pruebas iniciales, construcción y despliegue.
c. Evaluación del producto, control de procesos, planificación de procesos, análisis de la solución
y definición del problema.
d. Control de procesos, evaluación, personal, gestión del proceso y despliegue.
6. Las siguientes etapas hacen parte de la gestión de proyectos:

a. Organización, planificación del proceso, producto, evaluación y mantenimiento.
b. Control, organización, evaluación del proceso, producto y planificación del producto.
c. Personal, producto, evaluación del proceso, organización, dirección y control.
d. Dirección, control del proceso, personal, planificación y organización.
7. El software de computadora es: (justifique su respuesta)

a. El producto que los diseñadores de software construyen.
b. El producto que los técnicos de sistema construyen.
c. El producto que los ingenieros de software construyen.
8. Las actividades del marco de trabajo en su orden son

a. Comunicación, planeación, modelado, construcción y despliegue
b. Planeación, comunicación, modelado, construcción y despliegue
c. Modelado,
comunicación, Planeación, construcción y despliegue
d. Construcción, modelado, comunicación, Planeación y despliegue
9. Mediante un ejemplo a nivel empresarial explique los niveles de la integración del modelo de
capacidad de madurez
3. ENFOQUE DE LA INGENIERÍA DEL SOFTWARE
Objetivo general
Dar a conocer la bondades que tiene la práctica de la ingeniería del software como una guía que
coadyuva a la solución de las diversas problemáticas que tienen las empresas en cuanto al control y
manejo de la información, aplicando diversos modelos que ilustren de una manera eficaz la forma
como deben orientarse para su permanencia en el medio.
Objetivos específicos
Entender el enfoque propuesto por la Ingeniería de Sistemas.

Analizar la estructura de la Ingeniería de procesos de negocios y de producto
Comprender los diferentes enfoques de la Ingeniería de requisitos y su implementación al momento
de desarrollar software de alta calidad.
Prueba Inicial
1. Ingeniería de sistemas es:
a. Es el proceso que transforma la necesidad operacional en la descripción de los parámetros del

sistema, e integra esos parámetros para mejorar la eficiencia general del sistema.
b. Hace referencia al software o programas viejos, aquellos que utilizan tan solo algunas
entidades empresariales, gubernamentales o individuos.
c. Enfoque que se adopta mientras el software está en desarrollo. Es un marco de trabajo para
las tareas que se requieren en la construcción de software de alta calidad
d. Es la aproximación sistemática, disciplinada y cuantificable para desarrollar, operar y
mantener software.
2. Ingeniería de requisitos es:

a. comprender lo que realmente el cliente necesita antes de diseñar y desarrollar un software.

b. Obtener del cliente la información necesaria que permita el desarrollo del producto.
c. Analizar los requerimientos del cliente antes de empezar a desarrollar el software.
d. Negociar con el cliente acerca de la obtención de requisitos.
3. Ingeniería de software es:
a. El establecimiento y uso de principios sólidos de la ingeniería para obtener económicamente

un software confiable y que funcione de modo eficiente en máquinas reales.
b. Un marco de trabajo del proceso del software.
c. Un perfil de capacidad del área del proceso de la IMCM.
d. Es tanto un producto como el vehículo para su entrega.
3.1. Ingeniería de sistemas basados en computadora
3.1.1. Sistemas Basados en Computadora
“Hace casi 500 años, Maquiavelo dijo: No hay nada más difícil que llevar a cabo, más peligroso de
realizar o de éxito más incierto que encabezar la introducción de un nuevo orden de cosas 14"
En la actualidad estas palabras siguen vigentes, ya que cada vez que iniciamos una determinada tarea
siempre está inmersa en nuestro interior una pequeña duda o incertidumbre que hace que las cosas
se presenten de diversas formas con el objetivo de distraer y así desconcentrar un poco la atención de
la meta que desde el inicio se había trazado.
No podemos olvidar que todo en la vida tiene dificultades y contratiempos que busca distraer la
mente del ser humano que pretende según sus conocimientos dar solución a las distintas
problemáticas del mundo empresarial, del mundo que cada vez es más exigente y que de acuerdo a
sus grandes avances nos llevan a un ritmo tan acelerado que no alcanzamos a discernir con claridad lo
que se tiene hoy cuando llega algo nuevo permitiendo esto olvidarnos del ayer y volver a empezar.
Ante cualquier proyecto que nos enfrentemos en nuestro diario que hacer debemos comprenderlo en
su totalidad, porque éstas serían la base para garantizar el éxito y así buscar que el ciclo de vida sea
un poco mayor, por lo tanto, es parte fundamental entender el papel que cumplen las personas, el
hardware, el software las bases de datos y todos sus procesos para que de forma interdependiente
conformen el trabajo que se espera.
Importancia:
Se habla de un proverbio que dice: “Los árboles no dejan ver el bosque”, en este caso el bosque es
todo un sistema que tiene la capacidad de hacer algo y los árboles se refieren a todos sus
componentes o elementos que hacen parte de dicho sistema por ejemplo tenemos como bosque todo
un sistema de cómputo y como árboles todos sus dispositivos de entrada y salida como pueden ser el
teclado, el Mouse, el software, impresora, pantalla, etc.
3.1.1.1 Sistema basado en computadora

En todo momento se habla de sistemas aunque de forma explícita, pero siempre nos referimos a
aquello que es un todo que lo conforman muchas partes por ejemplo sistema educativo, político,
económico, nervioso, digestivo y bancarios entre otros, pero todo conlleva a que dentro de ellos
14
Roger S. Pressman
existen una ramificaciones que se deben de entender y que hacen que ese sistema como tal puede
funcionar con un orden específico.
Dentro de los sistemas basados en computadores se habla de macro elementos, que es también un
sistema basado en computadoras pero que hace parte de otro sistema mayor pero que se necesitan
que estos tengan una buena relación para poder cumplir con el objeto social que tiene la empresa o el
objetivo planteado inicialmente.
Por ejemplo un computador esta programado para realizar ciertas tareas que van dirigidas hacia otro
dispositivo, pero este otro dispositivo lo conforman otros elementos o dispositivos que harán que
puede funcionar mediante las instrucciones del principal. Otro ejemplo puede ser las empresas que
tienen la mayor parte de sus procesos sistematizados en donde se hacen las entregas de tareas por
lotes y cada lote pasas a otro sistema que tiene la capacidad de transformar ese proceso hasta que
llega a su estado final.
Jerarquía de la Ingeniería de Sistemas:

Está conformada por la visión global, visión de dominio, visión de elemento y visión detallada.
Visión Global:
Se analiza a nivel general el negocio o empresa para hacer la proyección respectiva y saber hasta
dónde se debe llegar con la solución, ejemplo: se debe analizar la empresa entre las cuales se observa
la misión, la visión y las necesidades principales
Visión de dominio: Se analiza un dominio específico para detectar las falencias y/o problemas que se
esté presentando, por ejemplo si es a nivel de empresa se analizará cada departamento, si es a nivel
se software se observará cada una de las opciones de submenú de una aplicación.
Visión del elemento:
Se analiza el producto a construir o fundamento del negocio. El objetivo es determinar las posibles
falencias antes de su funcionamiento global.
Visión detallada: Análisis genérico de todos los procedimientos que se estandarizan en el proyecto o
negocio, con el fin de estructurar su aplicación.
Ingeniería de procesos de negocio: Una visión general

El manejo de la información en las empresas es la parte más importante y a la que se le debe poner el
mejor empeño, debido a que ésta es la razón de ser de la misma ya que desde ahí se pueden extraer
los mejores informes para que se tome la mejor decisión en cualquier área o departamento. No
obstante para tener este control se requiere de aplicar con claridad el concepto de ingeniería de
sistemas e implantar o instalar los dispositivos o equipos necesarios para el control en su totalidad.
Para alcanzar los objetivos y metas de una empresa debemos tener presente la arquitectura de datos,
de aplicación y la infraestructura tecnológica.
Arquitectura de datos: Se definen cuáles son las necesidades de la información del negocio o de una
parte de él, los cuales representan los atributos que serán utilizados en todo el proceso incluyendo
sus relaciones para saber cómo será la comunicación por ejemplo. Vendedor – producto, un vendedor
expide productos x o producto x es expedido por un vendedor.
Arquitectura de aplicación: Son aquellos que permiten transformar los datos en información y dar
resultados que ayuden a tomar decisiones.
Infraestructura tecnológica: Es el soporte (Hardware y Software) donde se transforman y operan la

arquitectura de datos y la arquitectura de aplicación, como pueden ser los computadores, las redes,
telecomunicaciones, almacenamientos entre otros.
Ingeniería de producto: una visión general

Luego de recolectar toda la información que el cliente suministra, se busca satisfacerlo en sus
necesidades, dando como resultado un producto computarizado el cual necesitará de unas
arquitecturas básicas como pueden ser software, hardware, datos y personas.
También se indica que tecnología se utilizará, los medios de soporte y la forma en la que se entrega el
trabajo para garantizar su funcionalidad. Todos los requisitos que se necesita como parte del producto
siempre se obtienen del cliente y estos requisitos permiten el control de la información, ayuda a
observar la funcionalidad del producto, diseño e interfaces.
Luego de tener toda esta información bien organizada se puede pasar a realizar el conjunto de
actividades interdependientes para cada uno de los componentes del sistema. A medida que se va
desarrollando la aplicación, se deben hacer las respectivas modificaciones de diseño, restricciones,
Modelado del Sistema

Para esta operación hace parte fundamental el análisis y diseño al nivel del software y del sistema. Se
debe tener en cuenta que la Ingeniería de Sistemas ayuda a satisfacer las necesidades de los clientes a
través de su respectiva aplicación (desarrollo de software de alta calidad)
Se debe tener presente que en el momento de construir software cada uno de los elementos del
sistema se debe analizar individualmente con el fin de facilitar su desarrollo en el momento de la
construcción del código.
3.2. Ejercicio del tema 1
Como entiende usted la frase dicha por Maquiavelo: No hay nada más difícil que llevar a cabo,
más peligroso de realizar o de éxito más incierto que encabezar la introducción de un nuevo
orden de cosas
Haga un síntesis con respecto proverbio que dice: “Los árboles no dejan ver el bosque”, y de por
lo menos tres ejemplos en donde se vea todo esto reflejado, distinto al computador.
Mediante un ejemplo esplique los siguientes conceptos, arquitectura de datos, arquitectura de

aplicación e infraestructura tecnológica
3.3. La práctica: una visión genérica
3.3.1. La práctica de la Ingeniería del Software

Ellen Ullman representa un fragmento de vida al relatar los pensamientos de un practicante bajo
presión:
No tengo idea de qué hora es. No hay ventanas en esta oficina, tampoco reloj, sólo el LED
parpadeante en rojo de un horno de microondas, el cual parpadea 12:00,12:00, 12:00, 12:00. Joel y yo
hemos estado programando por días.
Tenemos un “bicho”, el necio demonio de un error. Por eso la pulsación roja sin tiempo se siente bien,
como una lectura de nuestros cerebros, los cuales se han sincronizado de alguna manera a la misma
velocidad del parpadeo
¿En qué estamos trabajando? Los detalles se me escapan ahora. Podríamos estar ayudando a gente
pobre y enferma o ajustando una serie de rutinas de bajo nivel para verificar bien en un protocolo de
una base de datos distribuida, no me importa. Me debería importar; en otra parte de mi ser más
tarde, quizá cuando salgamos de este cuarto lleno de computadores- me importa más por qué, para
quién y con qué propósito estoy escribiendo software. Pero ahora no.
He pasado a través de una membrana donde el mundo real y sus usos ya no importan. Soy un
ingeniero de software.
Cada vez que se desea construir software de alta calidad se debe tener claridad en cuanto a
principios, métodos y herramientas y tener claridad en el cómo se hacen las cosas para lograr los
objetivos y satisfacción del cliente.
En este trabajo se mostrará un mapa del camino para llegar al destino planteado, mostrando cuales
son los obstáculos que se puedan presentar y saber cuáles son las soluciones posibles para llegar al
éxito. Aquí se enseña el camino a seguir de manera segura y rápida, se indica cuando aumentar o
disminuir velocidad. Una de las partes fundamentales en el desarrollo de software es seleccionar el
método apropiado para tener la certeza de que se ha entendido y que se hará uso de las herramientas
apropiadas dentro de la sistematización para asegurar calidad de los productos que a diario se puedan
comercializar.
Las actividades a tener en cuenta dentro del marco de trabajo serán la comunicación, planeación,
modelado, construcción y despliegue; sobre estas actividades se debe trabajar arduamente con el fin
de que se logre un trabajo exitoso. En la esencia de la práctica para la resolución de problemas se
debe tener presente lo siguiente. Entender el problema, planear la solución, llevar a cabo el plan y
examinar el resultado para probar la precisión15
3.3.1.1 Principios esenciales
Dentro de los principios algunos se enfocan en la ingeniería como un todo y otros como una actividad
genérica del marco de trabajo.
1. La razón por lo que todo existe: Es muy importante hacer una serie de interrogantes como ¿se
da valor agregado al sistema?, antes de iniciar un proyecto ya que a partir de ahí se hace un
mejor enfoque de lo que se requiere en cualquier momento y se visiona para saber si vale la
pena continuar o abandonarlo.
2. Mantener lo simple. Desde lo simple se puede llegar a aquel trabajo con grado de dificultad,
pero el programador siempre debe tener en mente que él realiza un trabajo y que es para
otras personas que a veces se les dificultan hasta dar los primero pasos en el sistema, por lo
tanto lo simple, no quiere que el producto está malo o de poca calidad, es ahí en donde la
calidad se debe reflejar con mayor seguridad.
15
Roger S. Pressman
3. Mantener la visión: Si no conocemos la empresa u organización o entidad donde de desea

realizar un determinado proyectos o si no sabemos cuál es la visión sobre la cual se trabaja,
pues en un alto
porcentaje se llega al fracaso en la solución.
4. Lo que uno produzca, otros lo consumirán: Siempre en el desarrollo de aplicaciones o soluciones

empresariales se debe pensar en la otra persona que en cualquier momento puede continuar
con el proyecto o se beneficiará de él directa o indirectamente. Es también fundamental tener
presente a los usuarios ya que en algunos casos se desea continuar o realizar alguna
modificación o depuración en el código fuente
5. y así lo convertirá en otro usuario del código y así el ciclo de vida del software se puede
extender un poco más.
6. Estar abierto al futuro: El software siempre se debe estar proyectando a un buen tiempo y se
debe medir en meses y no en años debido a los grandes cambios tecnológicos e
implementación de hardware, porque éstos en el menor tiempo posible se vuelven obsoletos y
en algunos casos cuando no se proyecta a largo plazo el software éste también se ve afectado,
por eso se recomienda realizar un buen análisis observando desde la constitución de la empresa
e ir escudriñando hasta el proceso final.
7. Planear la reutilización: Se ha considerado la reutilización de código como algo muy importante

dentro de la programación y más aún cuando se trabaja en la programación orientada a objetos.
8. Pueden existir interrogantes con respecto a la reutilización ya que trabajar sobe algo que se
desconoce es un poco difícil, es por eso, que dentro de la programación que se esté llevando a
cabo siempre se documente todo el trabajo realizado ya sea para uno mismo utilizarlo o para
que otra persona pueda continuar o hacer uso de el sin ningún inconveniente.
9. Pensar: Es la parte en la que los desarrolladores o solucionadores de problemas empresariales

no tienen presente sino que a veces sin hacer un previo análisis inician actividades sin tener
presente las dificultades que durante el progreso puedan encontrar. Si pensamos bien en lo que
deseamos hacer pues encontramos los mejores resultados. Cuando se piensa bien en algo y aún
se hace mal lo que queda es principalmente una gran experiencia, pero se debe tener presente
que es menor no cometer el error porque a veces este cuesta mucho para contrarrestarlo.
10. La idea principal de estos principios es que la persona se apropie de ellos y pueda eliminar todas
aquellas barreras que lo conllevan a la pérdida de tiempo, dinero y hasta su propio
trabajo por no seguir paso a paso los lineamientos expuestos en este documento. Alguno de
estos pasos que no se tengan presentes en el desarrollo de problemas empresariales,
conllevará a fracaso del proyecto ya que lo más importante es entenderle al cliente todas las
necesidades para luego plasmar esta información en una realidad16.
Práctica de la comunicación
Una de las actividades más
importante con las que se enfrenta un ingeniero de software, es la comunicación efectiva en la que las
partes intervienen para hallar una solución a una problemática que se presenta permanentemente en
las empresas y sobre la cual se hará un análisis previo para encontrar las debilidades y fortalezas sobre
las cuales se trabajan. Existen principios sobre los cuales se debe basar para tener un buen éxito.
1. Escuchar: Cuando se sabe escuchar se entiende perfectamente lo que el usuario o cliente quiere,
es por eso, que se debe centrar la atención firmemente sobre la persona que está hablando sin
necesidad de hacer interrupciones que hagan perder el enfoque de lo que se quiere realmente.
2. Prepararse antes de comunicar: Es de vital importancia tener un poco de conocimiento sobre lo

que se va a hablar en una reunión, lo cual nos obliga a hacer investigaciones pertinentes al tema
a trabajar para que cuando se instale el diálogo se sepa con certeza del tema que se está
hablando y no entremos grandes vacíos que lo único que hacen es separarlo un poco más de la
realidad.
3. Alguien debe facilitar la actividad: Se debe nombrar un líder o mediador que facilite la
conversación entre las partes y que modere la reunión para que no se presentes discordias ni
dificultades entre las partes.
4. La comunicación cara a cara es lo mejor: Es fundamental este tipo de reuniones pero es

importante que exista otra representación de información para hacer el respectivo comparativo
y hacer una mejor discusión que permita orientar mejor a las partes.
5. Tomar notas y documentar las decisiones: Las notas que se tomen en el momento de estar en un
diálogo con el cliente es fundamental ya que si se desean realizar cambios o aclaraciones pues se
remiten directamente a las notas para que no existan dificultades en ningún momento.
6. Buscar colaboración: Cuando el conocimiento colectivo se combina para definir las características
del producto y/o servicio funciona cada vez mejor ya que se aclaran las dudas
16
Roger S. Pressman
existentes y se hace una mejor proyección hacia lo que realmente se espera del trabajo que se ha de
iniciar en el menor tiempo posible.
7. Conservar el enfoque, examinar un módulo a la vez: La idea principal de este punto es que el
mediador busque siempre redondear el tema que inició para que no halla ambigüedad en
ninguno de los puntos a resolver.
8. Si algo no está claro, se hace un dibujo: Cuando se hace un esquema se da mayor claridad en lo
que realmente se quiere transmitir a un equipo o grupo de personas y se dará una mejor
orientación para el logro
del objetivo.
9. Una vez que se llegue o no a un acuerdo sobre algo o si no hay claridad, se debe continuar hasta
llegar a la meta final. En el qué hacer diario se presentan muchos inconvenientes a los cuales se
les debe hacer frente y para eso se debe tomar una actitud muy positiva y hallar los puntos
críticos para empezar a corregirlos poco a poco hasta encontrar la solución.
10. La negociación no es un concurso, esta funciona mejor cuando ambas partes ganan. Cuando se
tiene entre las partes una meta y unos objetivos en común se pueden llegar a muchos acuerdos
en donde una parte no afecte la otra y se llegue a tener un trabajo acorde a las necesidades y el
ingeniero sienta satisfacción en su proyecto terminado17.
Práctica de la planeación
Aquí se definen metas y objetivos generales que ayuden a orientar al equipo de trabajo aunque en el
camino se tengan que hacer modificaciones, pues esto no afecta muy directamente el proceso que se
está siguiendo. Cuando no se hace una buena planeación en cualquier proyecto que se desee
implementar, pues el caos no demora mucho para verse reflejado en el avance que
17
Roger S. Pressman
diariamente se esté realizando y para ello se deben tener presente los principios básicos para evitar
contratiempos.
1. Entender los alcances del proyecto: Lo más importante de un proyecto que se desee desarrollar
es saber hasta dónde se quiere ir, es decir, saber el destino porque desde ahí empezamos a
buscar los caminos que nos conducen a ese lugar
2. Involucrar al cliente en la actividad de planeación: El cliente que sabe sus necesidades orientará
al ingeniero sobre lo que realmente necesita y luego entraría a negociar entre las partes las
fechas de entrega y demás asuntos del proyecto.
3. Reconocer que la planeación es iterativa: Cuando se hacen las entregas respectivas de los
avances del software, es en este momento cuando inician los distintos cambios que se deben
aplicar a la solución implementada, pues al procesar resultados se obtienen nuevas necesidades
o cambios a aplicar.
4. Estimar con base en el conocimiento disponible: Aquí en esta estimación se da la idea con
respecto al esfuerzo, costo y tiempo de terminación de las tareas, de acuerdo a los
conocimientos del equipo de trabajo.
5. Considerar el riesgo cuando se define el plan: En todo proyecto se debe prever el riesgo y se
debe tener el plan de contingencia adecuado para no retrasar el proyecto en el que se está
trabajando teniendo muy claro el cronograma de actividades que se planteó desde el inicio.
6. Ser realista: En todo desarrollo o solución de problemas el ser humano está expuesto a cometer
errores indirectamente y esto hace que el proyecto sufra pequeños retrasos por lo tanto nunca
se trabajará el tiempo completo como se establece en el cronograma, por lo tanto debe ser
prudente en la asignación de estos tiempos.
7. Ajustar la granularidad mientras se define el plan: Se debe detallar con claridad todas y cada una
de las tareas y/o actividades a desarrollar dependiendo del tiempo en que se proyecte para
observar el grado de dificultad que presente teniendo en cuenta que las cosas van cambiando
permanentemente para lo cual el tiempo para su terminación puede aumentar.
8. Definir como se intentará asegurar la calidad: Se debe programar un tiempo en el que se puedan
hacer revisiones para ir paso a paso asegurando la calidad del proyecto o producto.
9. Describir como se pretende incluir el cambio: Los cambios que se pueden hacer durante la
ejecución de un proyecto pueden ser muy complejos por lo tanto se debe analizar con claridad
en qué momento y de que forma el cambio será conveniente incluirlo para no detener su trayectoria.
10. Adaptar el plan a menudo y hacer los ajustes cuando éstos se requieran: En la mayoría de los
proyectos de software, estos van detrás del calendario establecido, es por eso que diariamente
se debe observar el plan inicial para que no se dé tanta diferencia a la realidad.
Es recomendable que todos los participantes del equipo de trabajo participen activamente en la
planeación porque de esa manera habrá más compromiso con el plan del proyecto.
En este punto se deberá responder a las siguientes preguntas why, what, who, where, how.
Antes de iniciar todo proyecto se debe analizar muy bien lo que realmente se quiere, ya que
normalmente en las empresas desean que la persona como analista, diseñador y/o programador
realice un sin número de trabajos casi que al mismo tiempo, pero lo más importante es encontrar la
magnitud de lo que se requiere para delimitar e iniciar con trabajos específicos de acuerdo al orden
de prioridades que tenga la empresa.
Al iniciar la solución se debe tener un plan o un cronograma de actividades que deben cumplirse
adecuadamente para alcanzar el objetivo esperado e ir llevando el control de cada paso que se
ejecuta para aumentar o disminuir el ritmo y no alterar los tiempo de entrega de la solución.
Se debe tener también claridad mediante actas sobre cada reunión que se realice y los cambios
pertinentes para que no se presenten inconvenientes durante el proceso o en la entrega del
proyecto18.
Práctica del modelado
18
Roger S. Pressman
Los modelos son la base fundamental para el trabajo que se va a realizar, por ejemplo para crear una
cerámica lo primero que se debe tener es el molde para que se tenga total originalidad. En la
ingeniería de software se crean dos clases de modelos los cuales con el de análisis y el de diseño.
Análisis:
En este se debe tener presente el dominio de la información, el dominio funcional y el de
comportamiento.
Diseño: Muestran las características del software que sirven como base para la construcción.
Principios que se deben tener presente en esta práctica
Modelado de análisis
1. El dominio de la información de un problema debe representarse y entenderse: Toda la
información que se manejará dentro de una organización o empresa se debe entender con
claridad para saber cómo va a ser la forma de comunicación entre cada una de las áreas o
departamentos y para definir la manera de ser almacenados.
2. Se deben definir las funciones que ejecuta el software: Cuando se tiene claridad en las funciones
que el software va a
realizar será de gran beneficio a los usuarios finales. En algunos casos las funciones permiten
control sobre el procesamiento interno o externo del software.
3. Se debe presentar el comportamiento del software (Como una consecuencia de eventos

externos). La forma como el software se comporta lo guía ambiente externo. El comportamiento
de un software se da principalmente de acuerdo a entrada de información de los usuarios, los
datos de control de un sistema externo o los datos que se recolectan por medio de la red.
4. Los modelos que presentan información, función y comportamiento deben partirse de forma que
descubran el detalle de una manera estratificada (o jerárquica): El análisis es el principal paso
para la solución de problemas de ingeniería y si el problema es muy grande, este debe dividirse
en problemas más pequeños hasta que se entienda uno por uno.
5. La tarea del análisis debe moverse de la información esencial hacia el detalle de la

implementación. El análisis comienza desde el punto de vista del usuario final. La “esencia” de los
problemas se describe con detalle de la forma en la que se implementará la solución19.
19
Roger S. Pressman
Modelado de diseño
1. El diseño debe ser rastreable hasta el modelo de análisis: El modelo enuncia el dominio de la
información del problema, las funciones que el usuario puede visualizar, el comportamiento del
sistema y el conjunto de clases que empaquetan los objetos.
2. Siempre se debe considerar la arquitectura del sistema que se va a construir: Es el esqueleto del
software que se va a construir afectando las interfaces, la estructura de datos, el flujo, el control
del programa, las pruebas
y el mantenimiento.
3. El diseño de datos es tan importante como el diseño de funciones de procesamiento. Se debe

estructurar muy bien los datos para que ayuden a simplificar el flujo del programa, el diseño y la
implementación de todas las partes del software.
4. Las interfaces (internas y externas) deben diseñarse con cuidado: La forma como se manejan los
datos en un sistema reflejará la eficiencia de su proceso, evita errores y simplifica el diseño. Una
interfaz bien diseñada ayuda a la realización de pruebas y validar sus funciones.
5. El diseño de interfaz del usuario debe ajustarse a las necesidades del usuario final. Lo más
importante del diseño de la interfaz es la facilidad de uso para satisfacción del usuario no
importando como esté estructurado internamente evitando la percepción que los usuarios le
pueden dar por su simplicidad en donde dicen que está “mal” hecho.
6. El diseño a nivel de componentes debe ser independiente del modo funcional. La funcionalidad
que se entrega debe centrarse en una función únicamente y terminada en su totalidad.
7. Los componentes deben estar apareados entre sí en forma mínima y vinculada con el ambiente
externo.
8. La presentación del diseño (modelos) deben ser fácilmente entendibles: Si el diseño no es fácil de
entender, es difícil que sirva como medio efectivo de comunicación, la idea principal es
comunicar información a los que generan el código, a los que probarán el software o a quienes
continúen con el software en dl futuro.
9. El diseño debe desarrollarse de manera iterativa. En cada iteración el diseñador debe buscar la
mayor simplicidad. El diseño es algo iterativo en donde los primeros pasos sirven para refinar y
corregir errores pero que luego en los nuevos avances se busaca la simplicidad del diseño
procurando mostrar la mejor calidad posible que se da en el desarrollo de aplicaciones.
Dentro de la práctica del modelado y el diseño es recomendable destacar la gran responsabilidad que
se tiene para que el software o
la solución pueda lograr alcanzar lo esperado por el cliente, teniendo claridad que en muchas
ocasiones el cliente no interpreta lo que se realiza como modelado de análisis pero lo que si
comprende en es el modelado de diseño porque es la forma como él va a observar el ingreso y salida
de información.
Tener presente que el cliente es el que exige como quiere ver la información pero muchas veces se le
debe hacer claridad no tanto por la visualización de un formulario sino la mejor manera del plasmar la
información para tener una buena trazabilidad de la misma y así permitirle ver sus informes de
distintas maneras pero que estos le ayuden a tomar las mejores decisiones dentro de su empresa para
alcanzar el éxito esperado.
Práctica de la construcción
Comprende programación y pruebas que hacen que el software satisfaga las necesidades que tiene el
cliente.
En las pruebas que se realizan se debe tener presente las de integración que son las que se realizan a
medida que se construye el software, las de validación que son las que evalúan la satisfacción de los
requisitos completamente y las de aceptación que son las que realiza el cliente con el producto final.
Principios y conceptos de codificación
Principio de preparación:
Antes de iniciar la programación se debe tener presente lo siguiente: Entender el problema, los
principios básicos de diseño, el lenguaje de programación con su ambiente de operación y el conjunto
de pruebas de unidad.
Principio de codificación:
Al iniciar la codificación se debe tener presente:
Seleccionar la estructura de los datos para tener un mejor diseño, mantener en lo posible la lógica
simple, manejar ciclos anidados para hacer más fácil la prueba, manejo de variables adecuadamente,
documentar el código y el manejo de sangrías en el código.
Principio de validación: Al terminar los pasos anteriores debe realizar:
Realizar pruebas y corregir errores y re-fabricar en algunos casos el código.

Principios de prueba
Algunos desarrolladores según su concepción dicen que un desarrollo con éxito es aquel en donde no
se encuentran errores. Las pruebas buscan encontrar diferentes tipos de errores.
1. Todas las pruebas deben ser rastreables hasta los requisitos del cliente: La pretensión principal
de este es encontrar errores.
2. Las pruebas se deben planear mucho antes de que comience el proceso de prueba: Tan pronto el
modelo de análisis esté terminado, se deben iniciar con los casos de prueba
3. El principio de Pareto es aplicable para las pruebas de software: El 80% de los errores
encontrados en el momento de la prueba, serán rastreables hasta el 20% de la aplicación
completa
4. Las pruebas deben comenzar “En los pequeño” y progresar hacia “lo grande”: Las pruebas
siempre inicial con la parte más sencilla y va avanzando a la medida que no existan errores y se
sigue progresando hasta terminar el software por completo.
5. Tener presente que las pruebas exhaustivas no son posibles.
Las pruebas que se le debe realizar al software no debe ser algo tan simple como para detectar
algunos errores sino que esta debe ser con gran profundidad para que la aplicación no falle en el
momento de ser entregada o al tiempo de estar en ejecución, por lo tanto es recomendable hacer uso
de algunos formatos que trabaja la empresas para implementar un manual pedagógico de tal manera
que esté tan bien estructurado que al instalar el software los usuarios finales hagan uso de este
manual y puedan comparar completamente los resultados del sistema con la información manual y así
corroborar la calidad del software implementado20.
Despliegue
Depende del modelo que se seleccione se harán entregas (despliegue) por etapas para satisfacer las
necesidades del cliente y esto hace se encuentren errores que el programador no había detectado.
Por cada etapa o avance que se entregue se debe proporcionar la documentación necesaria y el
personal idóneo para que de la capacitación.
Se deben tener presente para esta etapa lo siguiente principios:
1. Se deben administrar las expectativas que el cliente tiene del software: El cliente siempre espera
mucho más de lo que se había pactado inicialmente y esto no es de agrado para el equipo del
proyecto. Sobre la administración de expectativas, Noami Kartum establece:
“El punto inicial para administrar las expectativas es volverse más consciente acerca de lo que se
comunica y de la forma en que se hace”. Es recomendable que un ingeniero no se debe comprometer
a entregar más de lo que no puede en un tiempo determinado y debe ser cuidadoso en entregar lo
que se comprometió en el tiempo propuesto.
2. Se debe ensamblar y probar un paquete de entrega completo: Se debe entregar el software o el

programa en un CD o en otro medio de almacenamiento con todos los requerimientos necesarios
como puede ser la documentación, instaladores, librerías, entre otros.
Se debe establecer un régimen de soporte antes de entregar el software:
20
Roger S. Pressman
3. la responsabilidad y la información exacta es lo que espera un cliente ante cualquier pregunta o

dificultad que surja en el momento de trabajar con el software. Desde el inicio del proyecto se
debe hacer la planeación para el soporte y la forma de tener un registro específico para evaluar
los soportes realizados.
4. Se debe proporcionar material instructivo apropiado a los usuarios finales: Se debe realizar una
capacitación apropiada e indicar pautas para la solución de problemas que se presenten durante
la ejecución del software.
5. El software con errores se debe arreglar primero y entregarse después: En muchos casos debido
a la presión por el tiempo de entrega de software se hacen entregas por etapas de mala calidad
con la claridad que en la próxima versión se hará la corrección necesaria, pero el cliente al
detectar errores, estos quedarán impresos y guardados en su mente y más aún cuando causan
grandes daños en la empresa.
No se puede pensar que al realizar el despliegue del software ya hemos terminado todo y que
podemos relajarnos porque tenemos la certeza de que todo funcionará bien, pues creo que este es el
momento en donde debemos estar con mayor disponibilidad y en alerta ya que al estar digitando la
información pueden ocurrir un sin número de errores que ocasionen gran pérdida de información la
cual es fundamental para la
ejecución de las demás opciones programadas.
No se puede garantizar que al presentarse errores se puede recuperar por completo el proceso que se
estaba llevando a cabo ya que la información sigue siendo volátil y en cualquier momento se pierde
sin dejar evidencia alguna para hallarla y así ordenarla y llevarla al lugar correspondiente acarreando
grandes dificultades en el control de la información, pérdida de dinero o en muchos casas grandes
sanciones por parte del estado.
3.4. Ejercicio tema 2
Aplicar cada una de las etapas del modelo de procesos con sus principios más relevantes a un
problema ficticio ya sea administrativo, contable, financiero, entre otros.
3.5. Ingeniería de Requisitos
3.5.1. Un puente hacia el diseño y la construcción

Muchos desarrolladores se sienten tan atraídos por la parte de programación, que a veces inician un
trabajo sin saber qué es lo que se necesita y se argumenta que los detalles se van corrigiendo a
medida que se van realizando avances o con la entrega final del proyecto.
Debido a los grandes cambios que se dan a diario argumentan que la ingeniería de requisitos es una
pérdida de tiempo y que los usuarios finales entenderán mejor su necesidad luego de ejecutar los
primeros avances. Si no entendemos con claridad lo que el cliente quiere y no documentamos todos
los requisitos recolectados durante el proceso de análisis en combinación con principios, método y
herramientas con mayor seguridad el desarrollo de una solución tiende a fallar en el menor tiempo
posible.
La ingeniería de requisitos se debe adaptar a las necesidades del proceso, proyecto, producto y
personas que integran el proyecto. En la solución de problemas empresariales y luego de tener toda la
información organizada de acuerdo a las necesidades, se debe dar un orden de prioridad para ir
avanzando hasta terminar el trabajo y así lograr satisfacer al cliente en sus necesidades más
apremiantes.
Tareas de la Ingeniería de Requisitos
Inicio:
Las necesidades del control en el manejo de la información es la fuente principal para que un proyecto
comience su proceso de desarrollo, aunque existen otros modos en los que estos se presentan, a
veces por una pequeño conversación con alguien se pueden generar proyectos no solo desde el punto
de vista de programación sino desde la parte administrativa, comercial, de servicios, entre otros.
Para el desarrollo de
aplicaciones o problemas empresariales, el cliente debe tener muy buena comunicación con el
programador ya que desde ésta óptica se puede elaborar un trabajo acorde a las distintas necesidades
que se presentan en un sistema como el nuestro en donde cada días nos exigen más los grandes
competidores y para poder estar y subsistir se debe cambiar.
Obtención:
Los usuarios o clientes no saben que es lo que realmente necesitan, cuales son los objetivos del
sistema o producto, como el sistema satisface las necesidades y como se utilizará la solución ya que es
algo que no se define a simple vista sino que es a muy largo plazo. Existen tres puntos que
demuestran lo difícil que es la obtención.
1. Problema de ámbito: El cliente usuario no entrega los detalles adecuadamente y lo que hace es
distorsionar lo que requiere.
2. Problema de compresión: Los clientes usuarios nos saben la necesidad, desconocen en muchos
casos las bondades que ofrece un sistema de cómputo, no entregan por completo la información
básica ya que creen que el ingeniero descubre lo que ellos necesitan o dan información muy
distante de la realidad.
3. Problema de volatilidad: La forma organizada de la recolección de la información ayuda a evitar

inconvenientes debido a que los problemas empresariales cada día van cambiando.
Elaboración:
Su enfoque principal la elaboración de modelos que permitan indicar las funciones, las características
y restricciones de la aplicación.
En esta elaboración se hará uso de escenarios de usuario que indica la forma en que interactúan los
usuarios finales y el sistema, mostrando sus clases y relaciones mediante la variedad de diagramas
UML.
Negociación:
En el campo de la solución de problemas empresariales, es normal que los usuarios y clientes siempre
estén esperando más de lo que se puede entregar.
Lo más importante para tener una buena negociación es que se tengan bien definidos y organizados
los requisitos y más tarde se analizan el orden de prioridades con el que se debe trabajar. Se hacen
algunas estimaciones de esfuerzo y se estudia el costo con respecto a cada requisito analizado.
Especificación:
En esta se debe manejar una plantilla estándar para garantizar la consistencia de los requisitos
recolectados y buscando la mayor facilidad para su entendimiento.
Es el resultado de un arduo trabajo de ingeniería de requisitos que sirve para la ejecución del
concepto de ingeniería del software.
Validación:
En esta parte se analiza de toda la información extraída mediante la recolección de requisitos para
saber si existen falencias, omisiones, errores pero ya corregidos y si los estándares están siendo
usados adecuadamente para el proceso, proyecto y producto.
Dentro de la validación se cuenta con un equipo de trabajo completo como pueden ser ingenieros de
software, clientes, usuarios y demás personas que harán parte fundamental del proyecto y los que
encontraran las dificultades que se tengan en la información recolectada.
Gestión de requisitos:
Ayuda al equipo de proyecto a controlar, identificar, y rastrear los requisitos y las modificaciones que
se pueden presentar durante toda la etapa de desarrollo.
Inicio del proceso de la ingeniería de requisitos
El trabajo en equipo es lo más importante dentro del desarrollo de un proyecto, aunque la ingeniería
de requisitos solamente guía conversaciones con los miembros conocidos del equipo. Son muchas las
restricciones sobre las cuales trabajan los ingenieros de software debido a que los clientes pueden
estar ubicados en distintos lugares y en muchos casos solo tienen ideas vagas de lo que se necesita,
por lo tanto restringe un poco el proceso de desarrollo.
Para tener una solución exitosa se tendrán en cuenta algunos pasos necesarios dentro de la ingeniería
de requisitos.
1. Identificar los interesados: Somerville y Sawyer define a los interesados como “todos aquellos
que se benefician en una forma directo o indirecta del sistema que está en desarrollo”. Dentro de
los integrantes pueden ser clientes internos y externos, consultores, usuarios finales, gerentes de
producto entre otros.
2. Reconocimientos de múltiples puntos de vista: Todos los requisitos se extraen de diversas

personas y como cada uno está interesado en lo que es de su interés, es un poco difícil satisfacer
las necesidades de cada uno por lo cual el ingeniero debe generalizar su proyecto con el fin de
satisfacer las necesidades de todos los interesados sin desvirtuar su objetivo.
3. Trabajo con respecto a la colaboración: Lo más importante dentro de del desarrollo de proyectos
es que los clientes trabajen en compañía con los interesados, evitando con esto dificultades
durante toda la etapa de implementación. El principal objetivo del ingeniero de requisitos es
encontrar áreas en común y áreas en conflicto para llegar a un acuerdo y centralizar todo en un
objetivo único.
4. Formulación de las primeras preguntas: Estas se enfocan a los clientes y otros interesados, pero
estas preguntas deben ser libres “libres de contexto”.
¿Quién requiere el trabajo?

¿Para quién es la solución?
¿Qué beneficio económico se obtiene?
¿Existen otras fuentes que se ajuste a la necesidad?
Existen otras preguntas que permiten que el equipo de software entienda lo que realmente va a
realizar
¿Cuáles problemas debería solucionar?
¿Cuál es el ambiente en el que se aplicará la solución?
¿Las restricciones afectarán la búsqueda de la información?
Obtención de requisito
Recopilación conjunta de requisitos

Los participantes y los desarrolladores trabajan conjuntamente para encontrar los problemas,
proponer soluciones, mostrar enfoques y mostrar requisitos para la solución pero utilizan algunos
puntos fundamentales.
1. La reunión es dirigida por uno de los asistentes junto con los otros participantes
2. Se dan pautas para participar
3. Se debe llevar una agenda para tener el control y cubrir todos los puntos a tratar.
4. El moderador controla la reunión
5. Utilizar medios adecuados para entender la necesidad como pueden ser tablero electrónico, foro
virtual, etc.
6. Entender el problema, proponer soluciones, mostrar distintos enfoques y guiar lo manera de

lograr el objetivo.
Despliegue de la función de calidad (QFD): Este busca satisfacer la necesidad del cliente desde la
ingeniería del software y dentro de este despliego se deben identificar tres requisitos fundamentales.
1. Requisitos normales: Muestran al cliente los objetivos que se plantean desde el inicio durante las
reuniones, es decir, se refiere a avances mediante prototipos que orienten e indiquen al cliente
hacia dónde va el trabajo como pueden ser gráficos en pantalla con respecto a lo analizado de la
recolección de requisitos.
2. Requisitos esperados: Estos están inmerso en el sistema o producto, pero su ausencia causaría
insatisfacción. Ejemplo de estos requisitos la facilidad de uso, confiabilidad y la instalación de la
aplicación.
3. Requisitos estimulantes: Es todo aquello adicional que da valor agregado al software pero que no
estaban planeados pero que satisfacen al cliente.
El QFD utiliza medios como entrevistas, observación y revisión de la información histórica para tener
claridad en la recolección de los requisitos y luego toda esta información se transforma en una tabla
para su mejor interpretación con el cliente.
Desarrollo de casos de uso:

Este cuenta una historia como el usuario puede ver la comunicación en usuario final y el sistema.
Dentro de los casos de uso se debe identificar el conjunto de actores los cuales se interpretan como
diferentes personas o dispositivos que utiliza el sistema o producto, es decir, muestra la manera cómo
opera el sistema.
Entre el usuario final y el caso de uso existen diferencias ya que un usuario puede desempeñar varios
papeles al usar la aplicación en tanto que un actor identifica una entidad externa, pero no siempre es
una persona, que solo muestra el papel en caso de uso.
Ejemplo
Ejemplo, considérese al operador de una máquina (un usuario) que interactúa con la computadora de
control para una célula de manufactura que contiene varios robots y máquinas de control numérico.
Después de la revisión cuidadosa de los requisitos, el software para la computadora de control
requiere cuatro diferentes modos (actores) para su interacción:
Modo de programación, modo de prueba, modo de monitoreo y modo de resolución de problemas.

Por lo tanto, se pueden definir cuatro actores: el programador, el que realiza las pruebas, el que
monitorea y el que resuelve los problemas. En algunos casos el operador de la máquina puede
desempeñar todos estos papeles. En otras situaciones, son personas diferentes las que pueden
desempeñar el papel de cada actor.
Jacobson sugiere varias preguntas que se deberían contestar mediante casos de uso.
¿Quién(es) es (son) el(los) los actor(es) primario(s)?
¿Cuáles son las metas del actor?
¿Cuáles son las condiciones previas que deben existir antes de comenzar la historia?
¿Cuáles son las tareas o funciones principales que realiza el actor?
¿Cuáles excepciones podrían considerarse mientras se describe la historia?
¿cuáles son las variaciones posibles en la interacción del actor?
¿Cuál es la información del sistema que el actor adquirirá, producirá o cambiará?
¿El actor tendrá que informar al sistema acerca de cambios en el medio ambiente externo?
¿Cuán es la información que el actor desea del sistema?
¿El actor quiere ser informado acerca de cambios inesperados? 21
Construcción del modelo de análisis

Los modelos de análisis van cambiando a medida que se va adquiriendo nuevos conocimientos a
través de la experiencia y observan con mayor detenimiento las necesidades del cliente ya que desde
aquí se define su comportamiento y funcionalidad.
21
Roger S. Pressman
A medida que se van realizando bien las tareas de análisis, esto facilita el diseño que será la otra etapa
en la que se debe trabajar, pero el cliente no alcanza a entender por completo cuales son los
requisitos que el sistema necesita para satisfacer sus necesidades.
Elementos del modelo de análisis

Son varias las maneras de encontrar los requisitos para un sistema o aplicación para computadores
como por ejemplo los casos de uso o utilizar modos de representación para mostrar el modelo de
análisis.
Elementos comunes dentro de los modelos de análisis.

Elementos basados en escenarios
En este punto se utilizan los casos de uso con sus correspondientes diagramas como se muestra en la
figura.
Dentro de este elemento se muestra las funciones resultantes respecto a los requisitos se obtuvieron
durante la etapa inicial con los clientes y usuarios.
Elementos basados en clases

El caso de uso tiene inmerso objetos en los que se trabaja mientras que se utiliza el sistema y estos
objetos son denominados clases las cuales contienen nombre, atributos y operaciones que sirven para
manipular la información.
Negociación de requisitos
El cliente y el usuario entran a negociar en la cual el principal objetivo sobre el cual se debe trabajar es
el “ganar- ganar”. En este caso se pide un balance del funcionamiento, rendimientos y otros
elementos importantes para comparar con el costo y tiempo para ser colocado en el mercado.
Los clientes ganan al alcanzar los objetivos del software y el equipo de software gana al proyectar sus
costos y tiempos que se pueden alcanzar.
Validación de requisitos
Al tener los requisitos fundamentales para el modelo de análisis, se debe analizar para que no tenga
inconvenientes que obstaculicen las demás tareas o actividades que se deseen implementar. Para
analizar el modelo de análisis se deben tener presente las siguientes preguntas:
¿Cada requisito es consistente con el objetivo general del sistema/producto?
¿Todos los requisitos han sido especificados con el grado apropiado de abstracción? Esto es
¿algunos requisitos proporcionan un grado de detalle técnico que sea inapropiado en esta etapa?
El registro es necesario en realidad o presenta una característica agregada irrelevante para el
objetivo del sistema?
¿Cada requisito está limitado y no es ambiguo?
¿Algunos requisitos entran en conflicto con otros
¿Cada requisito es alcanzable en el ambiente técnico que recibirá el sistema o producto?
¿Cada requisito se puede probar una vez que éste haya sido implementado?
¿El modelo de requisitos refleja de manera apropiada la información, la función y el

comportamiento del sistema que será construido?
El modelo de requisito se ha sometido a “partición” para que exponga en forma progresiva

información más detallada acerca del sistema?22

Mediante un ejemplo a nivel empresarial indique como aplicaría las tareas de la ingeniería de
requisitos
Cree usted que al aplicar el concepto sobre inicio del proceso de la ingeniería de requisitos,
ayudará de forma directa a solucionar los problemas que las empresas tienen en el control y
manejo de información?, justifique su respuesta
Cree usted que al aplicar el concepto de casos de uso es suficiente para que el cliente comprenda
claramente la problemática que se va a solucionar?, justifique su respuesta.
Prueba Final
1. La meta de la Ingeniería de procesos de negocios es:
a. Crear un plan general de actividades o tareas.

b. Proporcionar un marco de trabajo.
c. Definir arquitecturas que permitan que un negocio utilice información de manera efectiva.
d. Definir el hardware y software que se utilizará en el desarrollo del producto.
2. La meta de la Ingeniería
del producto es:
a. Asignar por separado el proceso de requisitos sistémicos.

b. Traducir el deseo del cliente, de una serie de capacidades definidas, aun producto del trabajo.
c. Modelar las diferentes actividades del marco de trabajo.

d. Construir la base de datos del proyecto.
22
Roger S. Pressman
3. Simule la realidad de llevar a cabo el desarrollo de un proyecto y tome tres o cuatro de los putos
más relevantes de la práctica de la ingeniería del software, y aplique estos conceptos.
4. FILOSOFÍA ACERCA DE LA INGENIERÍA DEL SOFTWARE
Objetivo general
Aplicar conceptos claros del software mediante el uso de herramientas que faciliten la manera del
desarrollo de aplicaciones que satisfagan las necesidades del cliente al menor costo y en el menor
tiempo posible.
Objetivos específicos de la unidad
Identificar la propuesta de la Filosofía de Orientación a Objetos y la aplicación mediante el

lenguaje unificado de modelamiento.
Prueba Inicial
Desde un punto de vista orientado a objetos
1. un componente es:
a. La recopilación de la información necesaria.
b. Un conjunto de clases que colaboran entre si.
c. Explorar y definir cada clase.
d. Una interfaz de usuario.
f. Ninguna de las
anteriores.
2. Un atributo es:
a. Un objeto intangible.
b. Un conjunto de datos y operaciones sistémicas.
c. colección de valores de los datos que describen una clase.
d. Una rama de la ingeniería del software.
3. Una clase es:

a. Una descripción generalizada (por ejemplo, una plantilla, un patrón o un plano de trabajo)
que describe una colección de objetos similares.
b. Una abstracción de procedimientos requeridos.
c. Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado
a objetos
d. Modelado orientado a objetos.
4. Un objeto es:
a. Instancias de una clase específica.
b. Una clase de una descripción generalizada.
c. Colección de objetos similares.
d. Un encapsulamiento general de procesos.
5. Una subclase es:

a. Una clase básica.
b. Generación de conjunto de clases.
c. una especialización de la superclase
d. Un objeto sin datos.
4.1. Programación Orientada A Objetos
4.1.1. Orientación a objetos

Desde el punto de vista orientado a objetos un componente es un conjunto de clases que colaboran
entre sí. Recuerde que los modelados de análisis y diseño son acciones iterativas. Es probable que la
elaboración de la clase de análisis original requiera pasos de análisis adicionales, que son seguidos por
los pasos de modelado del diseño para representar la clase de diseño elaborada.
Cada clase de un componente se ha elaborado completamente para incluir todos los atributos y las
operaciones relevantes para su implementación. Como parte de la elaboración del diseño, también
deben definirte todas las interfaces (mensajes) que permiten que las clases se comuniquen y
colaboren con otras clases de diseño.
Para lograrlo el diseñador empieza con el modelo de análisis y elabora clases de análisis (en el caso de
componentes que se relacionan con el dominio del problema) y clases de infraestructura
(componentes que proporcionan servicio de soporte para el dominio del problema).
El objetivo general de la construcción de un software es primero que todo recopilar la información

necesitada, la cual se convierte en las necesidades exigidas por el cliente. El objetivo del análisis
orientado a objetos (AOO) es definir todas las clases (además de las relaciones y el comportamiento
asociado con ellas) relevantes para el problema y que deben resolverse. Los conceptos orientados a
objetos (OO) están bien establecidos en el mundo de la ingeniería del software.
Atributo: una colección de valores de los datos que describen una clase.
Clase: encapsula los datos y las abstracciones de procedimiento requeridos para describir el contenido
y el comportamiento de alguna entidad del mundo real. Una clase es una descripción generalizada
(por ejemplo, una plantilla, un patrón o un plano de trabajo) que describe una colección de objetos
similares.
Objetos:
Instancias de una clase específica. Los objetos heredan los atributos y operaciones de una clase.
Subclase:
Una especialización de la superclase. Una subclase puede heredar tanto los atributos como las
operaciones de una superclase.
Superclase:
También llamada una clase básica, es una generalización de un conjunto de clases que están
relacionadas con ella.
Un objeto contiene datos y operaciones.

Podemos distinguir dos tipos de objetos degenerados:
Un objeto sin datos (que sería lo mismo que una biblioteca de funciones)
Un objeto sin “operaciones”, con sólo operaciones del tipo crear, recuperar, actualizar y borrar (que
se correspondería con las estructuras de datos tradicionales)
Un sistema construido con
objetos degenerados no es un sistema verdaderamente orientado a objetos
En UML, un objeto se representa por un rectángulo con un nombre subrayado
Gráfico #9(Elaborado por los autores)
Ejemplo de varios objetos relacionados
Gráfico # 10
(Elaborado por los Autores)
4.1.2. UML23
UML = Unified Modeling Lenguaje

Un lenguaje de propósito general para el modelado orientado a objetos. Impulsado por el Object
Management Group (OMG, www.omg.org)
Documento “OMG Unified Modeling Language Specification”
UML combina notaciones provenientes desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)
23
http://www.clickear.com/manuales/uml consultado el 18-11-2011
Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas
notaciones
Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc. Pugna
entre distintos enfoques (y correspondientes gurús)
Los modelos de UML que se tratan en esta parte son los siguientes:
Diagrama de Estructura Estática,

Diagrama de Casos de Uso.
Diagrama de Secuencia.
Diagrama de Colaboración.
Diagrama de Estados.
HISTORIA DEL UML
Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. Se
presentó en el OOPSLA’95
El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational
Software. Herramienta CASE Rational Rose
INCONVENIENTES DEL UML
Definición del proceso de desarrollo usando UML. UML no es una metodología

No cubre todas las necesidades de especificación de un proyecto software. Por ejemplo, no
define los documentos textuales
Ejemplos aislados
“Monopolio de conceptos, técnicas y métodos en torno a UML y el OMG”
PERSPECTIVAS UML
UML es el lenguaje de modelado orientado a objetos estándar predominante ahora y en los

próximos años.
Razones:
Participación de metodólogos influyentes
Participación de importantes empresas
Estándar del OMG
Evidencias:
Herramientas que proveen la notación UML
“Edición” de libros (más de 300 en www.amazon.com)

Congresos, cursos, “camisetas”, etc.
PAQUETES UML
Los paquetes ofrecen un
mecanismo general para la organización de los modelos/subsistemas agrupando elementos de
modelado
Se representan gráficamente como:
Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema)

Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete
Una clase de un paquete puede aparecer en otro paquete por la importación a través de una
relación de dependencia entre paquetes
Todos los elementos no son necesariamente visibles desde el exterior del paquete, es decir, un
paquete encapsula a la vez que agrupa
El operador “::” permite designar una clase definida en un contexto distinto del actual
RESUMEN:UML define una notación que se expresa como diagramas sirven para representar
modelos/subsistemas o partes de ellos
El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por
ciento de UML-- Grady Booch.
Obsérvese el siguiente gráfico:
Gráfico #11 Elaborado por los autores

Importación de Paquetes
En Ulm se puede plasmar paso a paso todos los procesos que se desean implementar en la solución
de un problema empresarial ya sea desde la parte administrativa o desde el desarrollo de
aplicaciones, pero en ningún momento le va a solucionar problemas como por ejemplo de
programación o de la lógica sino que esta se debe aplicar la primera en un lenguaje de programación y
la segunda en esta aplicación u otra que se tenga disponible para su interpretación y saber así como
va a ser en flujo de información en la que se va a trabajar durante todo el desarrollo del proyecto.
Todo proceso que se desee llevar a cabo tendrá sus inconvenientes porque desde el punto de vista del
cliente y/o del usuario y/o programador, se pueden encontrar dificultades de retrasen un poco lo que
se está llevando a cabo, es por eso que Maquiavelo hace referencia a que “es difícil llevar a cabo” una
serie de proyectos y hacer que estos funcionen con la mayor claridad posible, porque en algunos
momentos las dificultades se presentan o el desánimo para seguir adelante con los proyectos.
XMLXML es una tecnología en realidad muy sencilla que tiene a su alrededor otras tecnologías que la
complementan y la hacen mucho más grande y con unas posibilidades mucho mayores. Es decir, al
lenguaje así como a las tecnologías que trabajan con él, sus usos, ventajas y modos de llevar a cabo las
tareas.
XML, con todas las tecnologías relacionadas, representa una manera distinta de hacer las cosas, más
avanzada, cuya principal novedad consiste en permitir compartir los datos con los que se trabaja a
todos los niveles, por todas las aplicaciones y soportes. Así pues, el XML juega un papel
importantísimo en este mundo actual, que tiende a la globalización y la compatibilidad entre los
sistemas, ya que es la tecnología que permitirá compartir la información de una manera segura, fiable,
fácil. Además, XML permite al programador y los soportes dedicar sus esfuerzos a las tareas
importantes cuando trabaja con los datos, ya que algunas tareas tediosas como la validación de estos
o el recorrido de las estructuras corre a cargo del lenguaje y está especificado por el estándar, de
modo que el programador no tiene que preocuparse por ello.
Vemos que XML no está sólo, sino que hay un mundo de tecnologías alrededor de él, de posibilidades,
maneras más fáciles e interesantes de trabajar con los datos y, en definitiva, un avance a la hora de
tratar la información, que es en realidad el objetivo de la informática en general. XML, o mejor dicho,
el mundo XML no es un lenguaje, sino varios lenguajes, no es una sintaxis, sino varias y no es una
manera totalmente nueva de trabajar, sino una manera más refinada que permitirá que todas las
anteriores se puedan comunicar entre sí sin problemas, ya que los datos cobran sentido.
XML es interesante en el mundo de Internet y el e-bussiness, ya que existen muchos sistemas

distintos que tienen que comunicarse entre sí, pero como se ha podido imaginar, interesa por igual a
todas las ramas de la informática y el tratamiento de datos, ya que permite muchos avances a la hora
de trabajar con ellos.
Para los que conozcan
también el lenguaje HTML, que espero que seáis muchos, he compilado aquí una serie de diferencias
entre HTML y XML que
El HTML se preocupa por formatear datos y para ello son las etiquetas que tiene el lenguaje, para
formatear la información que se desea mostrar.
El XML se preocupa por estructurar la información que pretende almacenar. La estructura la marca la
lógica propia de la información.
El desarrollo del HTML estuvo marcado la competencia entre los distintos visores del mercado. Cada
uno quería ser el mejor e inventaba etiquetas nuevas que a la larga entraban a formar parte del
estándar del W3C, como la etiqueta <FRAME>.
El desarrollo del XML está siendo llevado a cabo con rigor, siempre ajustado a lo que marca el
estándar que desarrolla el W3C, entidad que está desarrollando el XML con más diligencia que las
empresas con intereses particulares. Procesar la información en HTML es inviable, por estar mezclada
con los estilos y las etiquetas que formatean la información.
En XML se puede procesar la información con mucha facilidad, porque todo está ordenado de una
manera lógica, así mismo el formateo de la información para que se pueda entender bien por el
usuario es viable a través de un pequeño procesamiento, a través de hojas de estilos o similares24
4.1.3. Objetivos y Usos del XML

El XML se creó para que cumpliera varios objetivos.
Que fuera idéntico a la hora de servir, recibir y procesar la información que el HTML, para
aprovechar toda la tecnología implantada para este último.
Que fuera formal y conciso desde el punto de vista de los datos y la manera de guardarlos.
Que fuera extensible, para que lo puedan utilizar en todos los campos del conocimiento.
Que fuese fácil de leer y editar.
Que fuese fácil de implantar, programar y aplicar a los distintos sistemas.
El XML se puede usar para infinidad de trabajos y aporta muchas ventajas en amplios escenarios.
Veamos algunas ventajas del XML en algunos campos prácticos.
Comunicación de datos. Si la información se transfiere en XML, cualquier aplicación podría

escribir un documento de texto plano con los datos que estaba manejando en formato XML y
otra aplicación recibir esta información y trabajar con ella.
Migración de datos. Si tenemos que mover los datos de una base de datos a otra sería muy
sencillo si las dos trabajasen en formato XML.
Aplicaciones web. Hasta ahora cada navegador interpreta la información a su manera y los
programadores del web
tenemos que hacer unas cosas u otras en función del navegador del usuario. Con XML tenemos
una sola aplicación que maneja los datos y para cada navegador o soporte podremos tener una
hoja de estilo o similar para aplicarle el estilo adecuado. Si mañana nuestra aplicación debe
correr en WAP solo tenemos que crear una nueva hoja de estilo o similar.
Son sólo unos ejemplos que esperamos que comprendas aunque sea por encima ya que todavía hay
muchas cosas que no sabes sobre XML y las tecnologías relacionadas.
24
http://es.wikipedia.org/wiki/XML consultado el 10-05-2011
www.w3c.es/divulgacion/guiasbreves/tecnologiasXML consultado el 10-05-2011
4.1.4. SEI / CMM / CMMI
Capability Maturity Model Integration. Modelo para la mejora o evaluación de los procesos de
desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por el Instituto de
Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en
enero de 2002. CMMI se desarrolló para facilitar y simplificar la adopción de varios modelos de forma
simultánea, y su contenido integra y da relevo a la evolución de sus predecesores:
CMM-SW (CMM for Software), SE-CMM (Systems Engineering Capability Maturity Model),
IPD-CMM (Integrated Product Development)
El modelo para software (CMM-SW) establece 5 niveles de madurez para clasificar a las
organizaciones, en función de qué áreas de procesos consiguen sus objetivos y se gestionan con
principios de ingeniería. Es lo que se denomina un modelo escalonado, o centrado en la madurez de la
organización.
El modelo para ingeniería de sistemas (SE-CMM) establece 6 niveles posibles de capacidad para una
de las 18 áreas de proceso implicadas en la ingeniería de sistemas. No agrupa los procesos en 5
tramos para definir el nivel de madurez de la organización, sino que directamente analiza la capacidad
de cada proceso por separado. Es lo que se denomina un modelo continuo.
En el equipo de desarrollo de CMMI había defensores de ambos tipos de representaciones. El

resultado fue la publicación del modelo con dos representaciones: continua y escalonada. Son
equivalentes, y cada organización puede optar por adoptar la que se adapte a sus características y
prioridades de mejora
La visión continua de una organización mostrará la representación de nivel de capacidad de cada una
de las áreas de proceso del modelo.
La visión escalonada definirá a la organización dándole en su conjunto un nivel de madurez del 1 al 5.

Área de procesos
Las áreas de proceso que ayuda a mejorar o evaluar CMMI son 22 en la versión que integra desarrollo
de software e ingeniería de sistemas (CMMI-SE/SW) y 25 en la que cubre también integración de
producto (CMMI-SE/SW/IPPD).
Vistas desde la representación continua del modelo, se agrupan en 4 categorías según su finalidad:
Gestión de proyectos, Ingeniería, Gestión de procesos y Soporte a las otras categorías. Vistas desde la
representación escalonada, se clasifican en los 5 niveles de madurez. Al nivel de madurez 2
pertenecen las áreas de proceso cuyos objetivos debe lograr la organización para alcanzarlo.
El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación

de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al
software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los

Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca
registrada del SEI.
Crítica
Frecuentemente se critica al modelo CMM por no ser más específico en la definición de los procesos.
Para guiar a las organizaciones a definir y mejorar sus procesos indica qué actividades han de realizar,
pero nada sobre cómo hacerlo. Esto es así tanto en lo referente a la ingeniería como a las
herramientas o técnicas de gestión, aunque hace una curiosa excepción en las revisiones por pares
(peer reviews).
Del mismo modo, aunque insiste continuamente en la necesidad de las métricas, no da ninguna guía
concreta del tipo de métricas que son aceptables para una correcta práctica profesional.
Los técnicos se quejan a menudo de la enorme carga de "papeleo" que impone el modelo, viéndolo
más como un mecanismo de control por la dirección que una herramienta que les ayude en su
trabajo.
También resulta muy complejo, más todavía el CMMI, lo que hace que durante algún tiempo resulte
para mucha gente algo esotérico.
Síntesis de los modelos de procesos CMM y CMMI para desarrollo y mantenimiento de software.
CMMI (y previamente CMM) puede emplearse con dos finalidades:
1. Guía para mejorar los procesos que intervienen en el desarrollo y mantenimiento del software.
2. Criterio para determinar el nivel de madurez de una organización que desarrolla o mantiene
software en base a la capacidad de las áreas de procesos definidas en estos modelos.
La calidad de un producto o de un sistema es en su mayor parte consecuencia de la calidad de los

procesos empleados en su desarrollo y mantenimiento.
Madurez
Atributo de las organizaciones que desarrollan o mantienen los sistemas de software.
En la medida que éstas llevan a cabo su trabajo siguiendo procesos, y en la que éstos se encuentran
Homogéneamente implantados, definidos con mayor o menor rigor; conocidos y ejecutados por todos
los equipos de la empresa; y medidos y mejorados de forma constante, las organizaciones serán más o
menos “maduras”.
Los modelos CMMI ayudan a orientar al desarrollador a la forma como debe llevar a cada la solución
de un proyecto empresarial, proyectándolo a que la solución esté enfocada directamente con la
estandarización de todos sus procesos para que esta solución puede servir para otras dificultades de
otras empresas.
No obstante no se puede aplicar completamente la estandarización en todos los proyectos, pero al

analizar lo que realmente se quiere, se optará por seleccionar solo la información requerida para el
caso.
4.2. Ejercicio del tema 1
Que es la programación orientada a objetos y cuáles son sus elementos principales que lo
componen
Que es el UML, cuáles son sus ventajas y sus desventajas
Que es el XML y que diferencia existe con respecto al UML
Cuál es la diferencia entre SEI/CMM/CMMI y cuál es su objetivo en la implementación dentro del

desarrollo de software, puede complementar con información de internet o libros.
Qué opina usted con la crítica que se ha presentado con respecto al CMM
Prueba Final
1 Siguientes tipos de objetos son generados:
a. Objeto de datos y objeto de procesamiento.

b. Objeto sin datos y objeto sin operaciones.
c. Objeto de direcciones y objeto manipulado.
d. Objeto de clases y objetos de superclase.
2. En UML, un objeto se representa por:
a. Un círculo con un nombre subrayado.

b. Un cuadrado con un nombre subrayado.
c. Un rectángulo con un nombre subrayado.
d. Una circunferencia con un nombre subrayado.
3. En un paquete UML, cada paquete corresponde a:
a. Una organización para los modelos.

b. Una relación de dependencia mutua.
c. Una definición de superclases.
d. Un submodelo del modelo.
5. ESTÁNDARES Y METODOLOGÍA
Objetivo general
Desarrollar en el estudiante un alto grado de análisis, que le permita la comprensión de la estructura

del conocimiento de la ingeniería del software, para aplicarlo posteriormente en los diferentes tipos
de resolución de problemas que puedan presentarse aplicables en diversas áreas
Objetivos específicos de la unidad

Analizar los aportes realizados a la Ingeniería del Software por medio de los estándares de la IEEE
Comprender la metodología propuesta por la Ingeniería del Software de sala limpia, para los
sistemas basados en componentes
Entender la manera de aplicar la reingeniería tanto en el software como en el hardware dentro

de la empresa u organización.
Prueba Inicial
1. Reingeniería es:
a. La reconstrucción de un producto.
b. Crear un producto con una mejor funcionalidad, desempeño y fiabilidad, así como una mejor
facilidad de mantenimiento.
c. La búsqueda de una mayor facilidad de mantenimiento.
d. Ninguna de las anteriores.
2. Reestructuración:
a. Es la modificación del código fuente o los datos con la finalidad de adecuarlos para futuros
cambios.
b. Ocurre cuando la arquitectura básica de una aplicación es sólida, aun cuando el interior
técnico necesite trabajarse.
c. Se inicia cuando grandes partes del software son funcionales y sólo un subconjunto de los
componentes y datos necesitan una modificación extensa.
3. Ingeniería de software basada en componentes es:
a. Hace referencia a un conjunto de componentes de software estandarizados pre construido

que se hacen disponibles para encajar en un estilo arquitectónico específico para cierto
dominio de aplicación.
b. Es un proceso que concede particularmente importancia al diseño y la construcción de
sistemas reutilizables.
c. Integra los componentes para formar subsistemas y la aplicación cono un todo. Además,
algunos componentes
personalizados son sometidos a ingeniería para enfrentar aquellos aspectos del sistema que
no pueden ser implementados con el uso de los componentes existentes.
d. La Reutilización de software desarrollado internamente para implementar y recuperar los
requisitos.
e. a, b y c, son correctas.
f. b, c, d, son correctas.
g. d, c y a, son correctas.
h. Todas las anteriores.
i. Ninguna de las anteriores
5.1. Ingeniería del Software de Sala Limpia
5.1.1. El enfoque de sala limpia

Cuantas veces se ha escuchado la expresión: “hazlo bien la primera vez” esa es la filosofía primordial
de la ingeniería del software de sala limpia.
Un proceso que destaca la verificación matemática de la corrección antes de que comience la

construcción del programa y la certificación de la confiabilidad del software como parte de la
actividad de pruebas. El rasgo fundamental es tasas de falla extremadamente bajas que serían difíciles
o imposibles de lograr empleando métodos menos formales. Lo hace un ingeniero de software
especialmente entrenado. Es importante porque los errores implican la reelaboración. Ésta lleva
tiempo y aumenta los costos.
La sala limpia destaca las pruebas que ejercitan la forma en que el software es realmente utilizado.
Los casos de uso ofrecen una introducción al proceso de planeación de pruebas . Las más importantes
características de la sala limpia son la prueba de la corrección y las pruebas estadísticas de utilización.
Este enfoque es eficaz en cuanto a costo y tiempo para establecer un enfoque de fabricación que
evite la introducción de defectos de producción. Más que fabricar un producto y luego trabajar para
eliminar los defectos, el enfoque de sala limpia demanda la disciplina requerida para eliminar los
errores en la especificación y el diseño y luego fabricarlo en una forma limpia.
El enfoque de sala limpia utiliza una versión especializada del modelo de proceso incremental.
Mediante pequeños equipos de software independientes se desarrolla una “línea de incrementos de
software”. Conforme cada incremento se certifica se integra en el todo. Por ende, la funcionalidad del
sistema crece con el tiempo.
Las principales tareas llevadas a cabo como parte de la ingeniería del software de sala limpia son:
Planificación del incremento: se crea un plan de desarrollo de sala limpia, donde se crea la
funcionalidad de cada incremento.
Recopilación de requisitos.
Especificación de la estructura de cajas: ajustarse a los principios de análisis operativos. Se utiliza
un método de especificación que emplea estructuras de cajas, para describir la especificación
funcional.
Diseño formal. Especificaciones, estableciendo distinciones entre las actividades a realizar. (Cajas
negras)
Verificación de la corrección.
Generación de código, inspección y verificación.
Planificación de pruebas estadísticas.
Certificación.
La única forma de que en un programa ocurran los errores es que un autor los coloque ahí. No se
conocen otros mecanismos. La práctica correcta busca evitar la inserción de errores y, cuando se falla
al respecto, eliminarlos antes de probarlo o cualquiera otra forma de ejecutar el programa.
La sala limpia representa el primer intento práctico de someter el proceso de desarrollo de software al
control estadístico de la calidad con una estrategia bien definida para la mejora continua de los
procesos. Con el fin de alcanzar esta meta se definió un ciclo de vida único de sala limpia, el cual se
enfoca en la ingeniería del software basada en matemáticas para corregir diseños de software y en la
prueba de software basada en estadísticas para la certificación de la fiabilidad del software.
Esta ingeniería de software de sala limpia implementa técnicas de prueba con una alta probabilidad
de descubrir errores de alto impacto, además de verificar las especificaciones del diseño utilizando
una prueba de corrección basada matemáticamente. Obviamente, el enfoque de sala limpia aplica la
mayoría, si no todos, los principios y conceptos básicos de la ingeniería del software.
Los bueno análisis y procedimientos de diseño son esenciales si se quiere obtener alta calidad.
En la ingeniería de sala limpia se realizan pruebas basadas en la estadística. Aquí la prueba unitaria y
la depuración se sustituyen verificando la corrección y las pruebas basadas en estadística.
5.1.1.1 Especificación funcional

La ingeniería del software de sala limpia cumple con los principios de análisis operativo empleando un
método llamado especificación de estructura de cajas. Una caja encapsula al sistema en algún grado
de detalle. Por medio de un proceso de elaboración o refinamiento en niveles, las cajas se refinan en
una jerarquía donde cada una tiene transparencia referencial.
Esto es: “el contenido de información de cada especificación de caja es suficiente para definir su
refinamiento, sin depender de la implementación de alguna otra caja. Esto le permite al analista partir
un sistema jerárquicamente, moverse desde la representación esencial en la parte superior hacia un
detalle específico de la implementación en el fondo25.
Se utilizan 3 tipos de cajas:

Caja negra: la cual especifica el
comportamiento de un sistema o parte de este.
25
Roger S. Pressman
Caja de estado: encapsula los datos de estado y servicio en una forma análoga a los objetos (estímulos
– respuestas)
Caja transparente: contiene el diseño de procedimiento para la caja de estado.
Diseño de sala limpia

Utiliza con amplitud la filosofía de programación estructurada aplicada mucho más estricta. Esta se
emplea con eficiencia para refinar la función. (Si son aplicables las estructuras). Los datos de
programas se encapsulan como un conjunto de abstracciones que atienden las subfunciones. Los
conceptos de encapsulado de datos, ocultamiento de información y clasificación de datos se
aprovecha para crear el diseño de datos.
Si el lector se limita sólo a las estructuras conforme desarrolla un diseño de procedimiento, la prueba
de corrección es directa. Si se violan las estructuras las pruebas de corrección son difíciles o
imposibles.
Probar que un diseño es correcto requiere primero, identificar todas las condiciones y luego probar
que cada una toma el valor booleano adecuado. A estas condiciones se les llama subpruebas.
Las ventajas de la verificación del diseño son:
Reducir la verificación a un proceso finito.

Permitir al equipo de sala limpia verificar cada línea de diseño y código.
Produce mejor código que la prueba unitaria, entre otros…
Es bueno aclarar que la verificación del diseño debe aplicarse al propio código fuente.
(Verificación de la corrección)
Pruebas de sala limpia
Las pruebas estadísticas son parte integral de la misma estrategia de pruebas del mismo enfoque
de sala limpia.
La prueba estadística equivale a probar el software en la forma que los usuarios intentarían usarlo.
Esto se logra si los equipos de prueba de sala limpia (también llamados equipos de certificación)
determinan una distribución de probabilidad de uso para el software. La especificación (caja negra)
de cada incremento del software se analiza para definir un conjunto de estímulos (entradas o
eventos) que provocan el cambio de comportamiento del software. Con base en entrevistas con
usuarios potenciales, la creación de escenarios de uso y una comprensión general del dominio de
la aplicación, se asigna una probabilidad de uso a cada estímulo.
La certificación para la ingeniería del software requiere de 3 pasos:

Modelo de muestreo (para verificar que funcione bien, que se logra la fiabilidad requerida
Modelo de componentes (donde el analista hipotéticamente determinará posibles fallas del

software)
Modelo de certificación (se refiere a la fiabilidad global del sistema). Proyectado y certificado.
Aplicar la ingeniería del software de sala limpia no es un tema tan sencillo de llevar a cabo, aquí se
debe tener gran cuidado con cada una de las líneas analizadas y probadas para que el sistema cumpla
con las expectativas esperadas por parte del usuario final, no solo es observar todo lo que tiene que
ver con la caja negra que se refiere a todo lo que es la presentación de sus formularios de entrada e
informes de salida, sino que va un poco más allá de lo que alcanzamos a imaginar o descifrar de estos
términos.
La revisión concreta de cada una de las líneas de código es una parte fundamental dentro de la
ingeniería de sala limpia ya que en muchas ocasiones deseamos realizar una tarea específica y lo que
se hace es girar muchas veces sobre el mismo proceso para mostrar el mínimo resultado esperado, es
por eso, que se debe tener una lógica bien estructurada para hacer de las cosas difíciles algo fácil para
satisfacer las necesidades del cliente y disminuir al máximo las líneas de código que hacen que el
software ocupe mayor espacio.
5.2. Ejercicios tema 1
1. Haga una síntesis con resto a la aplicación de sala limpia dentro del desarrollo de software
2. Si se aplica el concepto de sala limpia claramente dentro del desarrollo de software, puedo
garantizar que los procedimientos aplicados, los ciclos y las decisiones serian eficientes para
garantizar la calidad?, justifique
3. Cuál es la diferencia entre caja blanca y caja negra, indique mediante un ejemplo esta
diferencia
4. Si hablamos de pruebas de software es lo mismo que hablar de pruebas de sala limpia?,

justifique
5.3. Componentes del software
5.3.1. Ingeniería de software basada en componentes

Hace referencia a un conjunto de componentes de software estandarizados pre construido que se
hacen disponibles para encajar en un estilo arquitectónico específico para cierto dominio de
aplicación.
En el contexto de la ingeniería del software la reutilización es una idea tanto antigua como nueva. Los
programadores han reutilizado ideas, abstracciones y procesos desde los primeros días de la
computación, pero el enfoque original para la reutilización era específico. En la actualidad, los
complejos sistemas de alta calidad basados en computadoras se deben construir en un tiempo muy
corto y demanda un enfoque más organizado de la reutilización.
Esta ingeniería (ISBC) es un proceso que concede particularmente importancia al diseño y la

construcción de sistemas reutilizables. Por lo tanto, alienta el uso de patrones arquitectónicos
predecibles y de infraestructura de software estándar, y por lo tanto conduce a un resultado de mayor
calidad.
La ISBC abarca dos actividades de ingenierías paralelas: La ingeniería de dominio: la cual explora un
dominio de aplicación con la intención específica de encontrar componentes funcionales, de
comportamientos y de datos que sean candidatos para la reutilización. Dichos componentes son
colocados en librerías de reutilización.
El desarrollo: el desarrollo basado en componentes obtiene requisitos de los clientes; selecciona un

estilo arquitectónico apropiado para satisfacer los objetivos del sistema a construir; y luego:*
Selecciona componentes potenciales para reutilización.
Califica los componentes para asegurarse que encajan adecuadamente en la arquitectura para el
sistema.
Adapta los componentes si se deben hacer modificaciones para integrarlos adecuadamente.
Integra los componentes para formar subsistemas y la aplicación cono un todo. Además, algunos
componentes personalizados son sometidos a ingeniería para enfrentar aquellos aspectos del sistema
que no pueden ser implementados con el uso de los componentes existentes. El resultado de la ISBC
es un software operativo, ensamblado con el uso de componentes de software existente y
desarrollado recientemente.
Esta ingeniería parece bastante similar a la ingeniería del software orientado a objetos convencional.
El proceso comienza cuando un equipo de software establece requisitos para el sistema que
construirá mediante técnicas convencionales de investigación de requisitos. Se establece un diseño
arquitectónico, pero en lugar de dirigirse inmediatamente hacia tareas de diseño más detalladas, el
equipo examina los requisitos para determinar qué subconjunto está directamente dispuesto para la
composición, y no para la construcción.
Se plantean las siguientes preguntas: Hay componentes comerciales de línea disponibles para
implementar los requisitos?
Hay disponibles componentes reutilizables desarrollados internamente para implementar los

requisitos?
Las interfaces para los
componentes disponibles son compatibles dentro de la arquitectura del sistema que se construirá.
COMPONENTE: parte importante, casi independiente y reemplazable de un sistema que satisface una
función clara en el contexto de una arquitectura bien definida26.
5.3.2. El proceso ISBC
Se caracteriza de tal forma que no sólo identifica los componentes candidatos sino que también
cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones
arquitectónicas, ensambla los componentes en un estilo arquitectónico seleccionado y actualiza los
componentes conforme los requisitos del sistema cambian.
El modelo de proceso para la ingeniería de software basada en componentes destaca las pistas
paralelas en las cuales la ingeniería del dominio se lleva a cabo concurrentemente con el desarrollo
basado en componentes. Los pasos de análisis y diseño arquitectónico definidos en el contexto de un
paradigma de diseño abstracto (ADP) implica que el modelo global del software representado como
datos, funciones y comportamientos (control) , se puede descomponer jerárquicamente. Conforme la
descomposición comienza, el sistema se representa como una colección de marcos de trabajo
arquitectónico, cada uno compuesto de uno o más patrones de diseño.
Ingeniería de dominio
Esta ingeniería trata de encontrar los aspectos comunes entre los sistemas para identificar los
componentes que sea posible aplicar en muchos sistemas (compatibilidad entre los componentes), y
para identificar familias de programas que se posicionen para sacar la mayor ventaja de dichos
componentes. (Paul Clementes)
La finalidad de la ingeniería de dominio es identificar, construir, catalogar y diseminar un conjunto de

componentes de software que sean aplicables para el software existente y futuro en un dominio de
aplicación particular. La meta global es establecer mecanismos que les permitan a los ingenieros de
software compartir dichos componentes para reutilizarlos durante el trabajo en sistemas nuevos y
existentes. La ingeniería de dominio incluye tres grandes actividades: análisis, construcción y
diseminación.
Se puede argumentar que la reutilización desaparecerá, no por eliminación, sino por integración en la
estructura de la práctica de la ingeniería del software. Como la reutilización cada vez tiene mayor
auge algunos creen que la ingeniería del dominio adquirirá tanta importancia como la ingeniería del
software durante la década siguiente.
26
Roger S. Pressman
En el proceso de análisis lo importante es definir el dominio que se investigará, categorizar los

elementos extraídos del dominio , recopilar una muestra representativa de las aplicaciones en el
dominio, analizar cada aplicación en la muestra y definir las clases de análisis, por último desarrollar
un modelo de análisis para las clases.
Es importante advertir que el
análisis del dominio es aplicable a cualquier paradigma de ingeniería del software, y que se puede
aplicar al desarrollo convencional y al orientado a objetos.
Desarrollo Basado en Componentes

Es una actividad de ISBC que ocurre en paralelo con la ingeniería del dominio. Al aplicar los métodos
de diseño de análisis y arquitectónico, el equipo de software refina un estilo arquitectónico apropiado
para el modelo de análisis creado para la aplicación que se construirá.
Una vez que la arquitectura se ha establecido, deben agregársele componentes que:
Estén disponibles en bibliotecas de reutilización.

Sean diseñados para satisfacer las necesidades personales del cliente. Por tanto, el flujo de tareas
para el desarrollo basado en componentes tiene dos trayectorias paralelas. Cuando los
componentes reutilizables están disponibles para su potencial integración en la arquitectura
tienen que cualificarse y adaptarse. Cuando se requieren nuevos componentes es preciso
diseñarlos. Entonces los componentes resultantes se componen (integran) en la plantilla
arquitectónica y se prueban en forma minuciosa.
Además de valorar si es justificado el costo de adaptación para la reutilización, el equipo de

software también evalúa si lograr la funcionalidad requerida y el desempeño se pueden hacer
eficientes respectos del costo. Desgraciadamente, la existencia de componentes reutilizables no
garantiza que puedan integrarse con facilidad o eficacia en la arquitectura elegida para una nueva
aplicación. Por esta razón se aplica una sucesión de actividades de desarrollo basada en
componentes cuando se propone el uso de un componente.
Calificación de componentes.(si realiza la función requerida)

Adaptación de componentes
Composición de componentes
Modelo de intercambio de datos (se debe definir mecanismos que permitan que los usuarios y
aplicaciones interactúen y transfieran datos (arrastrar y soltar, cortar y pegar). Los mecanismos
de intercambio de datos no sólo permiten la transferencia de datos humano-software y
componente-componente, sino también la transferencia entre recursos del sistema (arrastrar un
archivo a un icono de impresora para imprimirlo)
Automatización: implementar varias herramientas, macros y guiones para facilitar la interacción

entre componentes reutilizables.
Almacenamiento estructurado. Los datos heterogéneos (datos gráficos, voz, video, texto y
datos numéricos) que contiene un documento compuesto, deben estar organizados y ofrecer
acceso como una sola estructura de datos y no como una colección de archivos separados. Los
datos estructurados conservan un índice descriptivo de estructuras anidadas por las cuales las
aplicaciones pueden navegar libremente para ubicar, crear o editar contenidos de datos
individuales según ordene el usuario final.
Modelo de objeto subyacente. Asegura que los componentes desarrollados en diferentes

lenguajes de
programación y que residen en diferentes plataformas pueden ser interoperables. Es decir, los
objetos deben ser capaces de comunicarse a través de una red. Esto se logra si el modelo de
objeto define un estándar para la interoperabilidad de los componentes.
Clasificación y Recuperación de Componentes

Considérese un gran depósito de componentes. Cientos de miles de componentes de software
reutilizables se hallan en él. Pero ¿cómo encuentra un ingeniero de software el componente que
necesita?
Tendencias actuales que permitirán a los futuros ingenieros de software navegar entre bibliotecas
de reutilización.
Descripción de los componentes reutilizables. El concepto de un componente de software es una

descripción de lo que hace el componente. La interfaz con el componente está completamente
descrita y la semántica representada dentro del contexto de las precondiciones y las pos
condiciones identificada. El concepto debe comunicar la intención del componente.
El contenido de un componente describe cómo se construye el concepto. En esencia, el contenido es

información oculta para los usuarios habituales y que sólo necesitan conocerla quienes quieran
modificar o probar el componente.
El contexto sitúa un componente de software reutilizable en su dominio de aplicabilidad. Es decir, al
especificar las características conceptuales, operativas y de implementación el contexto permite que
un ingeniero de software encuentre el componente apropiado para satisfacer los requisitos de la
aplicación.
Para que sean útiles en la práctica, concepto, contenido y contexto se deben traducir en un esquema
de especificación concreto.
Economía ISBC
La ingeniería del software basada en componentes tiene un atractivo intuitivo. En teoría, debe
proporcionar a una organización de software con ventajas en cuanto a calidad y oportunidad, lo que
debe traducirse en ahorros.
Impacto sobre la calidad, la productividad y el costo

Calidad: en un entorno ideal, un componente de software que se desarrolle para reutilización se
verificaría como correcto y no contendría defectos. Con cada reutilización los defectos se encuentran
y eliminan, y, como resultado, mejora la calidad del componente. Con el tiempo el componente que
da virtualmente libre de defectos.
Productividad: cuando los componentes reutilizables se aplican a lo largo del proceso del software, se
dedica menos tiempo a la creación de planes, modelos, documentos, código y daos que se requieren
para crear un sistema fiable. Por lo tanto, se entrega al cliente el mismo nivel de funcionalidad con
menos esfuerzo, lo que mejora
la productividad. Aunque los reportes de mejora porcentual en la productividad son notablemente
difíciles de interpretar, parece que la reutilización del 30 al 50 por ciento puede resultar en mejoras
en la productividad en el rango del 25-40 por ciento.
Costo: los ahorros en el costo neto por la reutilización se estiman al proyectar el costo del proyecto si
éste fuese desarrollado desde cero, y luego se resta la suma de los costos asociados con la
reutilización y el costo real del software en los momentos de la entrega. El costo desarrollar un
componente reutilizable con frecuencia es mayor que el de desarrollar un componente específico
para una aplicación.
5.4. Ejercicios tema 2
Ingeniería del software basada en componentes es:
a. La cualificación de la interfaz de los mismos componentes para su reutilización.

b. La utilización de un modelo de intercambio de datos, herramientas, almacenamiento
estructurado y un modelo de objeto subyacente para construir las aplicaciones.
c. Es un proceso que concede particularmente importancia al diseño y construcción de sistemas
reutilizables.
d. La búsqueda de resultados enfocados a software operativos ensamblados con el uso de
componentes de software existente y desarrollado recientemente.
e. La reutilización de una idea tanto antigua como nueva.
f. Todas las anteriores.
g. Ninguna de las anteriores.
Justifique su respuesta con un ejemplo
Como explica usted la ingeniería de dominio?
Que se debe tener presente al desarrollar aplicaciones basadas en componentes
Describa dos ejemplos direccionados al campo empresarial en donde usted relacione la

reingeniería de procesos de negocios y la ingeniería inversa.
Explique mediante un ejemplo práctico ya sea en desarrollo de software o a nivel

administrativo o empresarial, Impacto sobre la calidad, la productividad y el costo
5.5. Reingeniería
5.5.1. Reingeniería de Procesos de Negocios

La RPN, excede el contorno de las tecnologías de la información y de la ingeniería del software. Hace
referencia a la búsqueda e implementación de un cambio radical en el proceso de negocios para
lograr resultados avanzados.
5.5.1.1 Proceso de negocios
Es un conjunto de tareas lógicamente relacionadas que se ejecutan para lograr un resultado de

negocios planeado. Dentro del proceso de negocio, la gente, el equipo, los recursos materiales y los
procedimientos del negocio se combinan para producir un resultado claro, conciso y definitivo. Los
ejemplos de procesos de negocios incluyen el diseño de un nuevo producto, la compra de servicios y
suministros, la contratación de un nuevo empleado y el pago a proveedores. Cada uno demanda un
conjunto de tareas y también emplea diversos recursos dentro del negocio.
Cada proceso de negocio tiene un cliente definido: una persona o grupo que recibe el resultado
(una idea, un informe, un diseño, un producto). Además, los procesos de negocios traspasan las
fronteras de la organización. Esto requiere que diferentes grupos de organizaciones participen en
las tareas lógicamente relacionadas que definen el proceso. La RPN se puede aplicar en cualquier
nivel de la jerarquía, pero conforme se amplía su ámbito los riesgos asociados con ello crecen
sustancialmente. Por esta razón, la mayoría de los esfuerzos de la RPN se enfoca en procesos
individuales o subprocesos.
Negocio: reducción de costo, reducción de tiempos, mejora de calidad y desarrollo y fortalecimiento

del personal.
Identificación del proceso: se identifican los procesos de mayor prioridad y luego se clasifica para
aplicar la actividad de la reingeniería.
Evaluación del proceso: Se identifican las tareas del proceso, costo y tiempo que consumen las tareas
del proceso.
Especificación y diseño del proceso: se preparan casos de uso y luego se diseña un conjunto de tareas
para el proceso
Elaboración de prototipos: un proceso de negocio debe ser llevado primero a un prototipo antes de
integrarse por completo.
Refinamiento y particularización: Luego de una retroalimentación del proceso este se refina y luego
se particulariza en un sistema de negocio27.
El objetivo de las herramientas del RPN es apoyar el análisis y la evaluación de los procesos de
negociación existentes y la especificación y el diseño de unos nuevos.
La mecánica de las herramientas varía. En general, las herramientas de la RPN permiten que un
analista de negocios modele los procesos de negocio existentes en un esfuerzo destinado a evaluar las
ineficiencias del flujo de trabajo o problemas funcionales.
Una vez que se identifican los problemas existentes las herramientas permiten que los analistas
elaboren prototipos o simulen procesos de negocio revisados.
5.5.2. Reingeniería del Software
El software al cual no se le puede dar mantenimiento no es un problema nuevo. De hecho, la

importancia cada vez mayor que se le concede a la reingeniería del software la han impulsado los
problemas en el mantenimiento del software que han ido creciendo durante más de 40 años.
5.5.2.1 Mantenimiento del Software

El mantenimiento del software existente implica casi el 60 por ciento del esfuerzo que emplea una
organización de desarrollo, y el porcentaje continúa elevándose conforme se produce más software.
Gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a 15 años de
antigüedad. Aun cuando dichos programas se crearon empleando las mejores técnicas de diseño y
codificación conocidas en la época, se crearon cuando el tamaño de los programas y el espacio de
27 Roger y S. pressman
almacenamiento eran las principales preocupaciones. Entonces emigraron hacia nuevas plataformas,
se ajustaron para adecuarlos a los cambios en las máquinas y a la tecnología de los sistemas
operativos aumentaron para satisfacer las necesidades de nuevos usuarios.
Otra razón respecto del problema del mantenimiento del software es la movilidad del personal. Es
posible que el equipo o persona que realizó el software ya no esté. En la actualidad pueda que no
haya nadie que tenga algún
conocimiento directo del sistema heredado.
Cuando se desea aplicar la reingeniería dentro de una empresa se debe observar muy bien lo que se
va a hacer ya que no se puede decidir a simple vista la aplicación de este término que puede costar no
solo tiempo sino una gran suma de dinero, adicionalmente puede generar inconvenientes entre las
mismas personas que laboran dentro de ella debido a los cambios que esto generaría y al malestar
que ocasiona sino se incluye un buen tema de concientización para la aceptación y el normal
funcionamiento de la nueva implementación.
5.5.2.2 Ingeniería Inversa

Invoca una imagen de ranura mágica. En la ranura se inserta una lista fuente sin documentar y
diseñado casualmente, y del otro extremo sale una descripción (y toda la documentación) completa
del diseño para el programa de computadora. La ingeniería inversa puede obtener información de
diseño a partir del código fuente, pero el grado de abstracción, (grado de detalle que se ofrece en un
grado de abstracción) de la documentación, el grado en el que las herramientas y un analista humano
trabajan en conjunto, y la direccionalidad del proceso son enormemente variables.
El grado de abstracción de un proceso de ingeniería inversa y las herramientas utilizadas para

efectuarlo se refieren a la sofisticación de la información del diseño que es posible obtener del código
fuente.
El proceso de ingeniería inversa debe ser capaz de derivar representaciones de diseño de

procedimiento, información de estructura de programa y datos (un grado de abstracción un poco más
elevado), modelos de objetos, modelo de flujo de datos o control y clases UML, diagramas de estado y
despliegue. Conforme el grado de abstracción aumenta, el ingeniero de software obtiene información
que le permitirá comprender con más facilidad el programa. Se deben abordar 3 temas de la
ingeniería inversa:
Grado de abstracción.
Integridad
Direccionamiento.
La aplicación de ingeniería inversa es un tema muy interesante ya que aquí se extrae de lo abstracto la
información para convertirla en una aplicación real aunque es de gran cuidado porque el objetivo
principal de la aplicación de ella es realizar un programa con gran similitud a otro con respecto a la
información que se interpreta incluyendo las mejoras que debe tener para su implementación.
Una de las cosas fundamentales dentro de la ingeniería inversa es tener claridad en el grado de
abstracción, la integridad y el direccionamiento porque de esto depende la efectividad en el buen
funcionamiento de la aplicación resultante, teniendo presente que en algunos casos el software del
cual se va a recolectar la información no funciona de acuerdo a las necesidades de la empresa o el
cliente, es por eso, que desea modificarlo y ante todo lograr ventajas competitivas y comparativas que
permitan de una manera
adecuada tomar la información para analizar completamente el buen funcionamiento de este
mediante lo informes entregados y verificados.
Reestructuración
Aunque la reestructuración del código puede aliviar inmediatamente los problemas asociados con la
depuración o los cambios pequeños, esto no es reingeniería, el beneficio real se logra sólo cuando se
reestructuran los datos y la arquitectura. La reestructuración modifica el código fuente o los datos con
la finalidad de adecuarlos para futuros cambios. En general, la reestructuración no modifica la
arquitectura global del programa.
Tiende a tocarse sobre los detalles de diseño de los módulos individuales y en las estructuras de
datos locales definidos dentro de los módulos.
La reestructuración ocurre cuando la arquitectura básica de una aplicación es sólida, aun cuando el
interior técnico necesite trabajarse. Se inicia cuando grandes partes del software son funcionales y
sólo un subconjunto de los componentes y datos necesitan una modificación extensa.
Reestructuración del código. (Diseño que produzca la misma función que el programa original)
Reestructuración de los datos. (se debe primero analizar el código fuente para poderlo
rediseñar.)
El objetivo de las herramientas de reestructuración es transformar el antiguo software de

computadora carente de estructura en lenguajes de programación y estructuras de diseño modernos.
En general, el código fuente se ingresa y transforma en un mejor programa estructurado. En algunos

casos, la transformación ocurre dentro del mismo lenguaje de programación. Un lenguaje de
programación antiguo se transforma en un lenguaje más moderno.
Ingeniería Directa
Qué opciones existen cuando se enfrenta un programa deficiente diseñado e implementado?
La reingeniería es muy parecida a la limpieza dental. Puede pensar en miles de razones para
demorarla, y la aplazará muchas veces. Pero eventualmente sus tácticas dilatorias regresarán para
provocarle dolor. En la mayoría de los casos, la ingeniería directa no simplemente crea el equivalente
moderno de un programa antiguo.
Más bien, los nuevos requisitos de usuario y tecnología se integran en el trabajo de reingeniería.
Ingeniería del software pag.918)
En algunos casos, la migración hacia la arquitectura cliente servidor no debe enfocarse como
reingeniería, sino como un nuevo esfuerzo de desarrollo. La reingeniería ingresa al cuadro sólo
cuando la funcionalidad específica del sistema antiguo se integrará en la nueva arquitectura.Ingeniería
directa para arquitecturas orientadas a objetos.
La Economía de la reingeniería
En un mundo perfecto, cualquier programa al que no se le pudiera dar mantenimiento sería retirado
inmediatamente, y sería sustituido por aplicaciones de mayor calidad con reingeniería desarrollada
empleando modernas prácticas de ingeniería del software. Sin embargo, se vive en un mundo de
recursos limitados.
La reingeniería demanda recursos que pueden utilizarse para otros propósitos del negocio. En
consecuencia, antes de que una organización intente someter a reingeniería una aplicación existente,
debe realizar un análisis costo beneficio.
El análisis costo beneficio representado en las ecuaciones se puede realizar para todas las aplicaciones
de alta prioridad identificadas durante el análisis de inventario.
Que es la reingeniería y en donde se puede aplicar

Cuál es el objetivo de las herramientas del reingeniería de procesos de negocio
Porque se dice que el mantenimiento de software Implica casi el 60 por ciento del esfuerzo
que emplea una organización?
Cree usted que la ingeniería inversa es más factible llevarla a cabo que la construcción de un
software haciendo todo el proceso completo? Justifique
Prueba Final
1. La ingeniería del software de sala limpia destaca:
a. El costo y tiempo de fabricación de un producto.

b. Los diferentes incrementos en la construcción del producto.
c. La fabricación del software.
d. Las pruebas que ejercitan la forma en que el software es realmente utilizado.
2. Las principales tareas llevadas a cabo por la ingeniería de software de sala limpia son:
a. Planificación del incremento, certificación y verificación de la corrección.

b. Recopilación de requisitos y diseño formal.
c. Especificación de la estructura de cajas y planificación de pruebas estadísticas.
d. Generación de código, inspección y verificación.
3. La ingeniería de
software basada en componentes integra los componentes para:
a. Desarrollar la interfaz de usuario.

b. Formar subsistemas y la aplicación como un todo.
c. Implementar los requisitos.
d. Investigación de requisitos.
4. La finalidad de la ingeniería de dominio es:

a. Supervisar, identificar, controlar y analizar un conjunto de componentes de software que
sean aplicables para el software existente y futuro en un dominio de aplicación particular.
b. Identificar, construir, catalogar y diseminar un conjunto de componentes de software que

sean aplicables para el software existente y futuro en un dominio de aplicación particular.
c. Planificar, supervisar y controlar un conjunto de componentes de software que sean

aplicables para el software existente y futuro en un dominio de aplicación particular.
d. Analizar, identificar y evaluar un conjunto de componentes de software que sean aplicables
para el software existente y futuro en un dominio de aplicación particular.
5. La reingeniería se puede aplicar a:
a. Software
b. Hardware
c. Personal
d. Todos los anteriores
6. Qué implicaciones positivas o negativas tiene la utilización de la ingeniería inversa
6. PISTAS DE APRENDIZAJE
Tener en cuenta: Que la crisis del software siempre se ha presentado a través de toda la historia
del desarrollo de software, lo que se pretende es evitar tanto inconveniente
Tener en cuenta: que el ciclo de mejora de un proceso es base fundamental para llevar a cabo un
buen desarrollo en los cuales se tienen en cuenta planear, ejecutor, medir y mejorar
Tener en cuenta: que la ley de las consecuencias imprevistas son acontecimientos o problemas que
se pueden presentarse en el cualquier momento o cambios de los objetivos de un producto.
Tenga presente: Que las categorías de software es necesario tener claro el concepto al desarrollar
aplicaciones o soluciones empresariales.
Tener en cuenta: Que para desarrollar aplicaciones es necesario llevar a cabo las actividades del
marco de trabajo tales como comunicación, planeación, modelado, construcción y despliegue.
Tenga presente: Que la base fundamental para un buen desarrollo está en una excelente
comunicación.
Tener en cuenta: Que el lenguaje unificado de modelamiento (UML), solo es una forma de diseñar
o dibujar la manera como fluirá la información.
Traer a memoria: Que la ingeniería del software de sala limpia ayuda a eliminar los diversos
procedimientos y códigos innecesarios.
Traer a memoria: Que aplicar la reingeniería no es cuestión de capricho, sino de necesidad de

mejorar los procesos de la empresa con el fin de cumplir su objeto social
Tenga presente: Que aplicar la ingeniería inversa en un determinado software es un proceso largo y
tedioso y que requiere de gran habilidad y destreza para su implementación, para no cometer el
error y decir que se encuentra en capacidad de reestructurarlo sin analizar.
7. GLOSARIO
ENIAC: Electronic Numerical Integrator And Computer (Computador e Integrador Numérico

Electrónico).
SWEBOK: Software Engineering Body of Knowledge (Cuerpo de la ingeniería del software.
ISO: Organización Internacional de Estandarización

QFD: Despliegue de función de calidad
CMM: Modelo de capacidad madurez.
CMMI: Integración de Modelos de Madurez de Capacidades.
UML: Lenguaje Unificado de Modelamiento
RPN: Reingeniería de Procesos de Negocio
8. BIBLIOGRAFÍA
Ph.D Roger S. Pressman, University of Connecticut, Ingeniería del Software un Enfoque Práctico, sexta
edición, Mc Graw Hill, 2002, 2005
Alfredo Weitzenfeld, Sur de California (Estados Unidos). Ingeniería del Software Orientado a Objetos
con UML, J

Sistem As

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistem As

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA DEL SOFTWARE I

INGENIERÍA DEL SOFTWARE I

Yolfaris Naidit Fuertes Arroyo

2.4. Ingeniería de sistemas ..................................................................................................... 20

PROPÓSITO GENERAL DEL MÓDULO

UNIDAD 1 UNIDAD 2 UNIDAD 3 UNIDAD 4

En los siguientes enunciados seleccione la respuesta correcta

a. La parte tangible del computador.

a. Es la aproximación sistemática, disciplinada y cuantificable para desarrollar, operar y

4. Un marco de trabajo es:

a. Un conjunto de componentes tangibles.

5. La subdivisión que tiene un ciclo de mejora de un proceso es:

a. Planear, ejecutar, medición y mejora

a. El producto que los diseñadores de software construyen.

2.1. Ingeniería del software

2.1.1. Introducción a la ingeniería del software

2.1.1.1 Definición Hardware

2.1.1.2 Definición Software

La crisis del Software

¿Por qué lleva tanto tiempo terminar los programas?

¿Por qué es tan difícil constatar el progreso durante el desarrollo?

2.1.2. Estándares y modelos

Principales organizaciones de estandarización

“ ISO: Organización Internacional para la Estandarización.

Los estándares más importantes para la ISO son.

SEI: Instituto de Ingeniería del software.

2.1.3. Proyecto SWEBOK

El proyecto parte de la suposición de que es necesario establecer cuál es el cuerpo de conocimiento

Ciclo de vida del software

La ISO 12207 Define el QUÉ, no el CÓMO6.

Para la adquisición de sistemas y servicios de software.

El estándar no cubre el desarrollo de productos de software para distribución comercial masiva

Gráfico #1 (Elaborado por los Autores)

Gráfico #2(Elaborado por los Autores)

Programación actividades o tareas.

Gráfico#3 (Elaborado por los Autores)

Ciclo de mejora del producto

Es un conjunto de elementos que interactúan entre sí para alcanzar un objetivo específico.

Ingeniería de sistemas comprende la Gestión de proyectos, función de planificar, supervisar y

Funciones de la Ingeniería de sistemas

“Definición del problema: Determinación de las expectativas hacia el producto, necesidades y

www.slideshare.net/.../unidad-uno-ingenieria-de-software, Unidad uno ingeniería de software, tomado el 10-05-2011

Gráfico #4 (Elaborado por los autores)

Ingeniería de sistemas – Gestión de proyectos – Ingeniería del Software

2.3. Ejercicio Tema 1

¿Qué haría usted para reducir el deterioro del software?

¿Cuáles son las principales organizaciones de estandarización?

2.4. Ingeniería de sistemas

2.4.1. Ingeniería de software

En la actualidad, el software es considerado el producto más importante dentro del campo

2.4.1.1 Software e Ingeniería del Software

El software también ha permitido la creación de tecnologías nuevas como la ingeniería genética, ha

En la sociedad moderna el papel de la ingeniería es proporcionar sistemas y productos que mejoren

El papel evolutivo del software

La Naturaleza cambiante del software

Software científico y de ingeniería:

Software incrustado o empotrado:

Software de línea de productos:

Aplicación basada en Web:

El proceso del software

2.5. Ejercicio Tema 2

El desarrollo de software se ve constantemente impedido por la lentitud en la creación de

La ingeniería del software es una tecnología estratificada. Abarca un proceso, métodos y

Las siguientes etapas hacen parte de la Ingeniería de Sistemas: