02-Ingenieria Del Software I

ESCUELA DE CIENCIAS BSICA E INGENIERA
ASIGNATURA: Ingeniera del Software I
CORPORACIN UNIVERSITARIA REMINGTON

DIRECCIN PEDAGGICA
Este material es propiedad de la Corporacin Universitaria Remington (CUR), para los estudiantes de la CUR
en todo el pas.
2011
Corporacin Universitaria Remington Direccin Pedaggica
Ingeniera del Software I Pg. 5
CRDITOS
El mdulo de estudio de la asignatura Ingeniera del Software I es propiedad de la Corporacin Universitaria Remington.
Las imgenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas en la
bibliografa. El contenido del mdulo est protegido por las leyes de derechos de autor que rigen al pas.
Este material tiene fines educativos y no puede usarse con propsitos econmicos o comerciales.
AUTOR
Rodrigo Alcides Patio Arango
Ingeniero de sistemas
Experiencia 5 aos
rodrigo.patino@remington.edu.co
Yolfaris Naidit Fuertes Arroyo

Ingeniera de Sistemas. (5 aos 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 cientfico, plagio o vicios de autora; en
caso contrario eximi de toda responsabilidad a la Corporacin Universitaria Remington, y se declar como el nico
responsable.
RESPONSABLES
Dr. Mauricio Seplveda
Director de la ESCUELA DE CIENCIAS BSICAS E INGENIERA
Director Pedaggico
Octavio Toro Chica
dirpedagogica.director@remington.edu.co
Coordinadora de Medios y Mediaciones
Anglica Ricaurte Avendao
mediaciones.coordinador01@remington.edu.co
GRUPO DE APOYO
Personal de la Unidad de Medios y Mediaciones
EDICIN Y MONTAJE
Primera versin. Febrero de 2011.
Derechos Reservados
Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.
Corporacin Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Pgina Web: www.remington.edu.co - Medelln - Colombia
TABLA DE CONTENIDO
1. MAPA DE LA ASIGNATURA ............................................................................................... 8

2. CONTEXTUALIZACIN DE LA INGENIERA DEL SOFTWARE.................................................. 9
2.1. Ingeniera del software ....................................................................................................... 11
2.1.1. Introduccin a la ingeniera del software ............................................................................ 11
2.1.2. Estndares y modelos ......................................................................................................... 13
2.1.3. Proyecto SWEBOK............................................................................................................... 14
2.2. Un sistema .......................................................................................................................... 17
2.3. Ejercicio Tema 1.................................................................................................................. 19
2.4. Ingeniera de sistemas ........................................................................................................ 20
2.4.1. Ingeniera de software ........................................................................................................ 20
2.5. Ejercicio Tema 2.................................................................................................................. 25
2.6. El proceso ........................................................................................................................... 26
2.6.1. Visin General del Proceso.................................................................................................. 26
2.6.2. Modelos de proceso ........................................................................................................... 28
2.7. Ejercicio Tema 3.................................................................................................................. 33
3. ENFOQUE DE LA INGENIERA DEL SOFTWARE .................................................................. 37
3.1. Ingeniera de sistemas basados en computadora ................................................................ 39
3.1.1. Sistemas Basados en Computadora ..................................................................................... 39
3.2. Ejercicio del tema 1............................................................................................................. 42
3.3. La prctica: una visin genrica........................................................................................... 42
3.3.1. La prctica de la Ingeniera del Software ............................................................................. 42
3.4. Ejercicio tema 2 .................................................................................................................. 55
3.5. Ingeniera de Requisitos ...................................................................................................... 55
3.5.1. Un puente hacia el diseo y la construccin ........................................................................ 55
3.6. Ejercicio tema 3 .................................................................................................................. 63
4. FILOSOFA ACERCA DE LA INGENIERA DEL SOFTWARE .................................................... 65
4.1. Programacin Orientada A Objetos ..................................................................................... 67
4.1.1. Orientacin 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. ESTNDARES Y METODOLOGA ...................................................................................... 78
5.1. Ingeniera 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. Ingeniera de software basada en componentes ................................................................. 83
5.3.2. El proceso ISBC ................................................................................................................... 85
5.4. Ejercicios tema 2 ................................................................................................................. 89
5.5. Reingeniera........................................................................................................................ 90
5.5.1. Reingeniera de Procesos de Negocios ................................................................................ 90
5.5.2. Reingeniera del Software ................................................................................................... 91
5.6. Ejercicio tema 3 .................................................................................................................. 94
6. PISTAS DE APRENDIZAJE................................................................................................. 97
7. GLOSARIO ...................................................................................................................... 98
8. BIBLIOGRAFA ................................................................................................................ 99
1. MAPA DE LA ASIGNATURA
NOMBRE DE LA ASIGNATURA
PROPSITO GENERAL DEL MDULO

Dar a los estudiantes los conocimientos necesarios para que desarrollen software de alta calidad utilizando
los enfoques, herramientas y mtodos requeridos para cada proceso y aplicables en cualquier rea del
conocimiento.
OBJETIVO GENERAL
Comprender los diferentes enfoques que propone la Ingeniera del software los cuales reglamentados bajo
estndares de calidad sirven de gua inductiva al momento del desarrollo de un producto.
OBJETIVOS ESPECFICOS
Diferenciar claramente los diversos enfoques, estndares y metodologas que rigen a la ingeniera
del software y los diversos procesos que hacen que los proyectos funcionen adecuadamente.
Dar a conocer la bondades que tiene la prctica de la ingeniera del software como una gua que
coadyuva a la solucin de las diversos problemticas que tienen las empresas en cuanto al control
y manejo de la informacin, 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 anlisis, que le permita la comprensin de la
estructura del conocimiento de la ingeniera del software, para aplicarlo posteriormente en los
diferentes tipos de resolucin 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
introduccin a la diferentes comprender los alta calidad bajo la
Ingeniera del enfoques procesos de la reglamentacin de
Software estructurados de programacin los estndares
la Ingeniera del orientada a necesarios o
Software objetos, XML y requeridos para
UML cada proceso de
desarrollo.
2. CONTEXTUALIZACIN DE LA INGENIERA DEL SOFTWARE
OBJETIVO GENERAL
Diferenciar claramente los diversos enfoques, estndares y metodologas que rigen a la ingeniera
del software y los diversos procesos que hacen que los proyectos funcionen adecuadamente.
OBJETIVOS ESPECFICOS
Reconocer la historia que enmarca el nacimiento de la Ingeniera del Software como disciplina.
Reconocer la historia y la estructura del conocimiento de la Ingeniera del Software a travs de
los conceptos de Herramientas, Mtodos, Procesos y Filosofas y/o Enfoques, analizando el
nivel de complejidad y las diferentes premisas y enfoques que existen respecto a la
Ingeniera del Software.
Diferenciar las Filosofas de pensamiento alrededor de la Ingeniera del Software y los
estndares y metodologas aplicadas
Prueba Inicial
En los siguientes enunciados seleccione la respuesta correcta
1. El software es:
a. La parte tangible del computador.

b. Un estndar especfico de un modelo sistmico.
c. Modelo de proceso.
d. Parte intangible del computador.
e. Todas las anteriores.
f. Ninguna de las anteriores.
2. Un estndar es:
a. Una coleccin de componentes reutilizables.
b. Una reestructuracin 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 aproximacin sistemtica, disciplinada y cuantificable para desarrollar, operar y

mantener software.
b. Coleccin de componentes organizados para cumplir una funcin o conjunto de funciones
especficas.
c. Organizacin que da el primer paso necesario para constituir a la Ingeniera del Software
como profesin
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 evolucin del software.
c. Un proyecto generado de argumentos sistmicos.
d. Un conjunto de actividades o tareas desarrolladas.
f. Ninguno de los anteriores.
5. La subdivisin que tiene un ciclo de mejora de un proceso es:
a. Planear, ejecutar, medicin 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 diseadores de software construyen.

b. El producto que los tcnicos de sistema construyen.
c. El producto que los ingenieros de software construyen.
d. Todas las anteriores.
e. Ninguna de las anteriores.
2.1. Ingeniera del software
2.1.1. Introduccin a la ingeniera del software

El software es una reunin 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 satisfaccin 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 evolucin de los sistemas informticos.
2.1.1.1 Definicin Hardware

El hardware es la parte tangible del computador, todos los elementos materiales que se pueden
tocar, como los dispositivos electrnicos y electromecnicos, 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 informacin (CD, disquete, USB),
parlantes, procesador, entre otros)1.
2.1.1.2 Definicin 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 ms conocidos tenemos: Dos, Windows (y sus diferentes versiones),
NetWare, Unix, entre otros.
b. Aplicacin: permite realizar trabajos o tareas especficas. Entre estas tenemos:
Word, Excel, juegos, etctera.
c. Lenguajes de programacin: 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 aparicin de componentes que cada dos aos doblan la capacidad de sus antecesores nos ha
rodeado en menos de cuatro dcadas de mquinas capaces de procesar miles de millones de
operaciones por segundo (MTOPS).
En 1946 ENIAC ocupaba una superficie de 160 m2, pesaba 30 toneladas, y ofreca 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 dcadas ha implicado a los desarrolladores de software en retos a los que no han
sabido responder con solvencia.
La crisis del Software

Este trmino fue acuado en los aos 70, cuando la industria o imperio del software ya haba
producido los suficientes programas que le permitieron darse cuenta de que en ellos algo fallaba,
que no se haba 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 anlisis 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 difcil constatar el progreso durante el desarrollo?

Por qu es tan difcil calcular cunto tiempo va a costar?
Definitivamente en la poca de los 70, la industria del software no haba podido satisfacer la
demanda visionada. La complejidad del software producido y demandado se incrementaba
constantemente.
Se debe tener presente que an desde los aos atrs 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 ms sencillos hasta los de misin crtica.
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 realizacin de un
programa o software) tiene claro qu quiere, interferir mucho menos en el proceso de desarrollo,
obligando a cambiar aspectos que ya haban sido convenidos previamente con el desarrollador.
Ms sin embargo no podemos descartar que ciertamente el cliente por lo general casi siempre le
exigir cambios al desarrollador cuando ya ciertos aspectos del cdigo estn terminados, por lo cual
es aconsejable pactar muy bien por escrito todas las exigencias del cliente antes de iniciar a
construir el cdigo, para evitar complicaciones futuras2.
2.1.2. Estndares y modelos
Definicin:
Son normas internacionales que reglamentan y controlan el desarrollo de software a nivel mundial.
Los estndares son tiles porque:
Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de software, lo
cual permite construir software de alta calidad.
Proporcionan un marco (terico-prctico) para implementar procedimientos de aseguramiento
de la calidad.
Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones
distintas3.
Principales organizaciones de estandarizacin
ISO: Organizacin Internacional para la Estandarizacin.

En 1987 la (ISO) y la Comisin Internacional Electrotcnica (IEC), establecieron un Comit
Internacional (JTC1) para las Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin
en el campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y
equipos.
Los estndares ms importantes para la ISO son.

ISO/IEC 12207
ISO/IEC TR 15504
SEI: Instituto de Ingeniera del software.

IEEE: Instituto de Ingenieros en electricidad y electrnica, entre otras4.
2
Roger S. Pressman
3
www.slideshare.net/.../diapositivas-de-ingenieria-de-software, Diapositivas De Ingeniera De Software, tomado 10-05-
2011
4
serdis.dis.ulpgc.es/.../02. %20Estandares%20y%20modelos%20de%20Ingenieria%20del%2... -, Resultados de la
bsqueda [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 tcnicas de cada momento, pero la definicin de
procesos y metodologa de trabajo es la esencia de la profesin. As por ejemplo, el rea de
conocimiento de requisitos, s que puede considerarse como esencia de la profesin. Los
problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los requisitos
son indistintos del hardware o lenguaje de programacin empleado5. Se puede afirmar que estos
eran los mismos hace dos dcadas que ahora, y todo nos hace suponer que seguirn siendo
idnticos dentro de otros aos venideros.
El proyecto SWEBOK fue quien constituy a la Ingeniera del Software como profesin, 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:
Gestin de la configuracin
Gestin (planificacin, supervisin y control de los mtodos, procesos y herramientas)
Los Procesos (estrategias de planeacin)
Herramientas y mtodos (como centro de partida del proyecto)
Calidad (totalmente garantizada)
Requisitos (necesariamente de la etapa de comunicacin y de los procesos)
Diseo
Construccin (cdigo)
Pruebas (reglamentadas)
Mantenimiento (realimentacin)
El proyecto parte de la suposicin de que es necesario establecer cul 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 tecnologas de la
informacin, tales como lenguajes especficos de programacin, bases de datos relacionales o redes
o tecnologa de redes y comunicaciones.
Esta es una consecuencia de la distincin que entre esencia y accidente se establece desde un
enfoque de ingeniera.
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 tcnicas de cada
momento, pero la definicin de procesos y metodologa de trabajo es la esencia de la profesin.
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
profesin.
Los problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los
requisitos son indistintos del hardware o lenguaje de programacin empleado. Recuerde que los
problemas del proyecto parten de la etapa de comunicacin (programador cliente), ya que se
planea, analiza y construye lo que se recopila como centro de informacin necesaria para la
realizacin del producto final.
ISO 12207
Establece un marco en el ciclo de vida del software para la adquisicin, suministro, desarrollo,
operacin y mantenimiento del software, as como tambin para gestionar, controlar y mejorar el
marco de trabajo que incluye la realizacin del cada proceso que conlleve a la realizacin 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 CMO6.

Dice cules son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y
operacin de los sistemas de software, asentando un marco estndar de referencia internacional,
pero no se ocupa ni prescribe tcnicas especficas. El estndar sirve de referencia desde dos
perspectivas diferentes:
Para la adquisicin de sistemas y servicios de software.

Para el suministro, desarrollo, mantenimiento y operacin de productos de software.
El estndar no cubre el desarrollo de productos de software para distribucin 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
Grfico #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.
Grfico #2(Elaborado por los Autores)
Programacin actividades o tareas.
El ciclo de mejora de un proceso que lo componen actividades y tareas los cuales conlleva
la (Planificacin, ejecucin, medicin y mejora)
Grfico#3 (Elaborado por los Autores)
Ciclo de mejora del producto
ISO 12207 tiene una relacin directa con la ingeniera 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 slida 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 solucin 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
estndares que se deben utilizar en los cuales no se piensa en una solucin para una empresa
especfica sino que se piensa en empresas similares en donde la adaptacin 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 interactan entre s para alcanzar un objetivo especfico.
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),
adems se necesita de las personas (ingenieros de software), porque son quienes realizaran los
procedimientos que llevaran a la realizacin del programa o cdigo fuente.
Cabe agregar que la Ingeniera de Sistemas es quien da paso a la Ingeniera del Software,
empezando con un entendimiento claro de todo el contexto que involucra tanto a los detalles
tcnicos como a los diferentes procedimientos que se llevarn a cabo en la bsqueda del resultado
esperado (producto o software).
Ingeniera de sistemas comprende la Gestin de proyectos, funcin 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 descripcin de
los parmetros del sistema (necesario para analizar o valorar la situacin), e integra esos
parmetros para mejorar la eficiencia general del sistema.
Funciones de la Ingeniera de sistemas
Definicin del problema: Determinacin 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.
Anlisis de la solucin: 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 implementacin, utilidad, evolucin del sistema
Planificacin de los procesos: Determinar los grupos de tareas tcnicas 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 mtodos para controlar las actividades tcnicas del
proyecto y los procesos; la medicin del progreso, revisin de los productos intermedios y
ejecucin de las acciones correctivas, cuando corresponda.
Evaluacin del producto: Determinar la calidad y cantidad de los productos elaborados, a

travs de evaluaciones, pruebas, anlisis, inspecciones7.
7
www.slideshare.net/.../unidad-uno-ingenieria-de-software, Unidad uno ingeniera de software, tomado el 10-05-2011
Grfico #4 (Elaborado por los autores)
Ingeniera de sistemas Gestin de proyectos Ingeniera 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 hara usted para reducir el deterioro del software?
Mencione algunas posibles fallas del hardware y posibles soluciones para evitar estas fallas (3)
Cules son las principales organizaciones de estandarizacin?
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
Cul es el ciclo de mejora para la descomposicin de un proceso en actividades y tareas?
2.4. Ingeniera de sistemas
2.4.1. Ingeniera de software
En la actualidad, el software es considerado el producto ms importante dentro del campo

tecnolgico mundial, debido a su crecimiento o desarrollo, se ha hecho tan indispensable en los
diferentes sectores de aplicacin organizacional (sistemas de todo tipo), permitiendo rapidez en la
ejecucin de los procesos, confiabilidad al momento de realizar una tarea especfica, seguridad en el
manejo de la informacin, automatizacin de los procesos, etctera.
La ingeniera de software se puede definir como la rama de la ingeniera que crea y mantiene las
aplicaciones de software aplicando tecnologas y prcticas de las ciencias computacionales, manejo
de proyectos, el mbito de la aplicacin, y otros campos. Esta ingeniera abarca un proceso,
mtodos y herramientas fundamentados en el desarrollo del producto bajo normas o estndares
que reglamenten la calidad.
2.4.1.1 Software e Ingeniera del Software

En la actualidad, el software de computadora es la tecnologa individual ms importante en el
mbito mundial. Es comn darse cuenta que la invencin de una tecnologa puede tener efectos
profundos e inesperados en otras tecnologas con las que en apariencia no tiene ninguna relacin.
(ESTE FENOMENO SE COMO LA LEY DE LA S CONSECUENCIAS IMPREVISTAS). El software se ha
convertido a travs de los aos en una tecnologa indispensable en los negocios, la ciencia y la
ingeniera.
El software tambin ha permitido la creacin de tecnologas nuevas como la ingeniera gentica, ha

permitido la expansin de tecnologas existentes como las telecomunicaciones, el fin de tecnologas
antiguas como la industria de la impresin. En fin, se puede afirmar que el software es la fuerza
conductora de la tecnologa del presente, ya que est relacionado con sistemas de todo tipo:
transporte, mdicos, telecomunicaciones, militares, industriales, de entretenimiento, mquinas
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 tamao 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 aplicacin 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 dems documentos que constituyen el software) desde el punto de
vista del usuario el producto obtenido es la informacin.
En la sociedad moderna el papel de la ingeniera es proporcionar sistemas y productos que

mejoren los aspectos materiales de la vida humana, para que as la vida sea ms fcil, segura y
placentera8. (Richard Fairley y Mery Willshire)
El papel evolutivo del software

El software es tanto un producto como el vehculo para su entrega. Es el transformador de la
informacin. El papel del software de computadora ha experimentado un cambio significativo en un
periodo un poco mayor a 50 aos. Las mejoras sustanciales en el desempeo del hardware, los
cambios profundos en las arquitecturas de cmputo, 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 ms elaborados y complejos basados en computadoras.
Nadie sabe en realidad el futuro de los sistemas que da a da se construyen, ms 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 produccin, el manejo, la adquisicin, la modificacin, el despliegue o
la transmisin de la informacin que puede ser tan simple como un solo bit o tan compleja como
una presentacin multimedia. En su papel de vehculo para la entrega de un producto, el software
acta como la base para el control de la computadora (sistemas operativos), la comunicacin de
informacin (redes) y la creacin y el control de otros programas (utileras de software y
ambientes).
9
El software entrega el producto ms importante de nuestro tiempo: informacin. Transforma los
datos personales, por ejemplo las transacciones financieras de un individuo, de modo que los datos
sean ms tiles en un contexto local. Maneja informacin de negocio para mejorar la
competitividad, proporciona una va para las redes de informacin alrededor del mundo (Internet) y
proporciona los medios para adquirir informacin en todas sus formas (pginas web).
Se debe tener presente que el software es un elemento lgico en lugar de fsico, 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, fcil
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 diseo: implementacin)
Los costos del software se concentran la ingeniera, esto quiere decir que los proyectos de software
no se pueden manejar como si fueran proyectos de manufactura. El hardware tiene un nmero
considerablemente alto de posibles fallas al inicio de su vida til, se hace referencia a defectos de
diseo de fbrica (manufactura). Tambin con el tiempo causa fallas en el hardware la acumulacin
de polvo (falta de mantenimiento), la alta vibracin, 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 an a daarse.
El software es inmune a los males ambientales que desgastan al hardware. Los errores del software
se corrigen, o sea que se implementan, ms sin embargo se debe tener en cuenta la innovacin o
mejor permanente de los programa, ya que este si tiende a deteriorarse.
En muchos casos se confunden los trminos 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 categoras del software de computadora que presentan retos
continuos para los ingenieros de software.
Software de sistemas:
Coleccin de programas escritos para servir a otros programas. Ejemplo: los compiladores, editores
y utileras para la administracin de archivos, los cuales procesar estructuras de informacin
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 aplicacin:
Son programas independientes que resuelven una necesidad de negocios especfica. Ejemplo: el
procesamiento de transacciones en los puntos de venta.
Software cientfico y de ingeniera:

Se caracteriza por algoritmos. Abarca desde la astronoma hasta la vulcanologa, desde el anlisis de
la tensin automotriz hasta la dinmica orbital de los transbordadores espaciales, y desde la
biologa molecular hasta la manufactura automatizada. Diseo asistido por computadora.
Software incrustado o empotrado:

Reside en la memoria de solo lectura del sistema y con l se implementan y controlan caractersticas
y funciones para el usuario final y el sistema mismo. Ejemplo: control del teclado de un horno
microondas, las funciones digitales de un automvil, como el control de combustible, los sistemas
de frenado, entre otros.
Software de lnea de productos:

Diseado para proporcionar una capacidad especfica y la utilizacin de muchos clientes diferentes,
se puede enfocar en un nicho de mercado limitado. Ejemplo: productos para el control de
inventarios, hojas de clculos, multimedia, entretenimiento, manejo de BD, administracin de
personal y finanzas en los negocios.
Aplicacin basada en Web:

Las WebApps engloban un espectro amplio de aplicaciones. En su forma ms simple, las WebApps
son apenas un poco ms que un conjunto de archivos de hipertexto ligados que presentan
informacin mediante texto y algunas grficas. Actualmente estas aplicaciones estn integradas
con base de datos y aplicaciones de negocios, ya que proporcionan caractersticas que les permite
evolucionar hacia ambientes computacionales sofisticados.
Software de inteligencia:
Utiliza algoritmos no numricos en la resolucin de problemas complejos que es imposible abordar
por medio de un anlisis directo. Incluye la robtica, el reconocimiento de patrones (imagen y voz),
los juegos de computadoras, entre otros10.
Es de suma importancia reconocer las distintas categoras de software que existen en el medio para
determinar en un momento determinado lo que la empresa tiene ya sea para la implementacin de
un sistema similar o la modificacin en caso de estar llevando una asesora a nivel general.
No cualquier categora de estas sirve para cualquier tipo de empresa sino que esto depende de su
razn social, de su misin y visin, por eso es recomendable realizar el levantamiento de
informacin necesaria para no seguir cometiendo los errores en los que muchos desarrolladores
han cado.
Software Heredado
Hace referencia al software o programas viejos, aquellos que utilizan tan solo algunas entidades
empresariales, gubernamentales o individuos. Estos fueron desarrollados hace dcadas 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 cmputos. 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 aplicacin que se relacion en el tema de la naturaleza cambiante del software.
Debe tenerse presente que todo sistema (el software es un sistema de informacin de cualquier
ndole) si desea preservarse debe adaptarse al medio o entorno que lo rodea. Una de las principales
caractersticas de los sistemas es la adaptabilidad y evolucin (crecimiento) constante.
Algunas veces el software heredado tiene diseos imposibles de extender, cdigos complicados,
documentacin escasa o inexistente, casos de prueba y resultados que nunca fueron archivados, un
historial de cambio manejado con pobreza, etctera. 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 tecnologa evoluciona rpidamente, por lo tanto el
software debe adaptarse para satisfacer las necesidades de los nuevos ambientes o las nuevas
tecnologas de cmputos. El software debe mejorarse para una mejor implementacin de su
servicio, o sea redisearse.
El proceso del software
10
Roger S, Pressman
Son los pasos predecibles que hay que realizar para crear el programa o cdigo que permitir la
satisfaccin de una de las necesidades del cliente desde el campo de la preservacin de la
informacin. 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 organizacin a una actividad que puede volverse catica 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 creacin de

componentes hardware y mecanismos que servirn 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 comunicacin.
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 tecnolgico (involucrando software) en usted y por qu?
Defina con palabras propias lo que es para usted la ingeniera del software?
La ingeniera del software es una tecnologa estratificada. Abarca un proceso, mtodos y

herramientas fundamentales al momento de desarrollar software de alta calidad. Para usted,
cual es este proceso, herramientas y mtodos que requiere esta ingeniera para el desarrollo
de software.
Las siguientes etapas hacen parte de la Ingeniera de Sistemas:
a. Codificacin, planificacin de procesos, control de procesos, evaluacin del producto, diseo

de software.
b. Anlisis de la solucin, evaluacin organizacional, control de procesos, comunicacin,
supervisin del problema.
c. Evaluacin del producto, definicin del problema, supervisin del problema, control del
proceso, pruebas unitarias.
d. Control de procesos, anlisis de la solucin, evaluacin del producto, planificacin de procesos,
definicin del problema.
f. Ninguna de las anteriores, Justifique su respuesta con un ejemplo.
Haga un anlisis con respecto al papel evolutivo del software
2.6. El proceso
2.6.1. Visin General del Proceso
El desarrollo del software es un proceso de aprendizaje social, es un proceso iterativo de

aprendizaje y como resultado la materializacin del conocimiento recolectado, depurado y
organizado conforme el proceso estuvo en ejecucin.
El proceso de un software es un marco de trabajo para las tareas que se requieren en la

construccin de software de alta calidad. El proceso es un sinnimo de Ingeniera del Software. Un
proceso de software define el enfoque que se adopta mientras el software est en desarrollo, pero
la ingeniera del software tambin abarca las tecnologas que requiere el proceso (mtodos tcnicos
y herramientas automatizadas)11.
La ingeniera 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 Estratificacin del proceso
Se aplica al desarrollo de software de computadora, de que manera se construye, econmicamente

que sea un software confiable, que funcione eficientemente en varias mquinas reales. Se busca la
compatibilidad Software Hardware, Ms que una disciplina o un cuerpo de conocimiento, la
ingeniera es un verbo, una tecnologa estratificada, una palabra de accin, 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 Ingeniera del Software
Marco de trabajo
Establece la base para un proceso de software completo al identificar un nmero pequeo de

actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su
tamao 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
ingeniera del software. Adems 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, cundo y cmo lograr cierta meta. (Ivar Jacobson,
Grady Booch y James Rumbaugh)
Marco de Trabajo (actividad sombrilla)
2.6.2. Modelos de proceso
Comunicacin: Implica una intensa colaboracin y comunicacin con los clientes, adems
abarca la investigacin de requisitos y otras actividades relacionadas que ayudaran a un
mejor entendimiento de lo que se desea como producto final.
Planeacin: establece un plan para el trabajo de la ingeniera del software. Describe las
tareas tcnicas que deben realizarse, los riesgos probables, los recursos que sern
requerido, los productos del trabajo que han de producirse y un programa de trabajo.
Modelado: Esta actividad abarca la creacin de modelos que permiten al desarrollador y al

cliente entender mejor los requisitos del software y el diseo que lograr satisfacerlo.
(Anlisis y diseo)
Construccin: esta actividad combina la generacin del cdigo (ya sea manual o
automatizado) y la realizacin de pruebas necesarias para descubrir errores en el cdigo.
Despliegue: el software se entrega al cliente parcialmente para que lo evale y a su vez para
que proporcione la informacin basada en su evolucin12..
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 documentacin 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 ms 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 visin sistmica debe estar presente en todos los proyectos que se estn 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 solucin de problemas.
Visin sistmica de la Ingeniera del software
Grfico #7 Elaborado por los Autores
Estructura del conocimiento en la I.S.
Filosofa - 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
Reingeniera de software
Proceso
Modelo O. Genrico
Modelos O. prescriptivos
Modelos O. giles
Modelos O. web
Modelos de gestin
Mtodos
Modelado del anlisis

Ing. del diseo
Diseo arquitectnico
Diseo a nivel de componentes
Diseo de la interfaz de usuario
Estrategias de prueba de software
Tcnicas de prueba de software
Mtricas del software
Mtodos formales y/o matemticos
Herramientas
Diagramas de escenarios
Diagramas de flujo
Diagramas de clases
Diagramas de comportamiento
Etc.
Nivel de la complejidad del producto de la Ingeniera de Sistemas

Niveles de la complejidad del producto
Datos: sin asociatividad a un contexto. Ejemplo: edad.
Informacin: con asociatividad a un contexto. Ejemplo: menor de edad.
Conocimiento: con asociatividad a mltiples contextos. Ejemplo: comportamiento usual de

los menores de edad.
Sabidura: Creacin de principios generalizados con base en el conocimiento procedente de

fuentes diferentes. Ejemplo: Segn la psicologa, la neuropsicologa, la neurociencia y la
sociologa la situacin se debe enfrentar con x o y decisiones.
Niveles de la integracin del modelo de capacidad de madurez
Nivel 0: Incompleto: la gestin de requisitos no alcanza todas las metas y objetivos definidos
para avanzar al nivel 1.
Nivel 1: Realizado: Las tareas especficas 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
estn implicados de manera activa, todas las tareas de trabajo y productos estn
monitoreados, controlados y revisados y son evaluados en apego a la descripcin 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,
adems, el rea del proceso se controla y mejora mediante mediciones y evaluacin
cuantitativa. Los objetivos cuantitativos para la calidad y el desempeo del proceso estn
establecidos y se utiliza como un criterio para administrar el proceso.
Nivel 5: Mejorado: Todos los criterios del nivel 4 han sido satisfecho. Adems, el rea del
proceso se adapta y mejora mediante el uso de medios cuantitativos (estadsticos) para
reconocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del
rea del proceso que se est considerando13.
Evaluacin del proceso

La existencia de un proceso de software no es una garanta de que ste ser entregado a tiempo, de
que satisfar las necesidades del cliente, o de que mostrar caractersticas de calidad a largo plazo.
Los patrones de proceso deben ir acompaados de una prctica slida de la ingeniera del software.
Adems, el proceso mismo debe evaluarse para asegurarse de que cumpla una serie de criterios
bsicos del proceso que han demostrado ser esenciales para una ingeniera de software exitosa.
Premisas de la ingeniera 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 conclusin de dicho razonamiento.
Cuando la ingeniera del software llegue hasta el antepenltimo peldao de la generacin de

conocimiento, a las puertas de la sabidura, el mundo se habr acabado.
El desarrollo de software se ve constantemente impedido por la lentitud en la creacin de

componentes hardware y mecanismos que servirn para que extienda su potencial.
La generacin de nuevo hardware y de los diferentes mecanismos se realiza para el servir a las
pretensiones reprimidas de la ingeniera del software.
Diferencie claramente las categoras 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 travs del proceso o algunas estn
concentradas en una o ms actividades del marco de trabajo? (Justifique su respuesta)
Cul es la subdivisin que tienen los modelos de procesos?
Realice una sntesis (consultar en internet o libros) con respeto a la subdivisin que tiene
inmerso los mtodos.
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.
Cul es el propsito de la evaluacin del proceso?
La ingeniera de software es una disciplina que integra al proceso, los mtodos 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?
(Relacinelo con la evolucin 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 ms se sepa, menor es el riesgo que se
corre de fracasar. Siempre que se piense que no hay tiempo para la ingeniera del software, se
debe considerar si habr tiempo para hacerlo todo de nuevo.
Realice un anlisis detallado y profundo de la relacin o sntesis que existe entre los siguientes
esquemas.
Plantear un ejemplo en donde se visualice a travs 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 Ingeniera 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, documentacin, software y procedimiento.
b. Software, documentacin, planificacin, direccin y supervisin.
c. Hardware, software, procedimiento, supervisin y control.
d. Documentacin, procedimiento, software, control y hardware.
3. Cul es el objetivo principal de los estndares y cules 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 Ingeniera de sistemas:

a. Definicin del problema, anlisis de la solucin, codificacin, despliegue y mantenimiento.
b. Control de procesos, planificacin de procesos, pruebas iniciales, construccin y despliegue.
c. Evaluacin del producto, control de procesos, planificacin de procesos, anlisis de la
solucin y definicin del problema.
d. Control de procesos, evaluacin, personal, gestin del proceso y despliegue.
6. Las siguientes etapas hacen parte de la gestin de proyectos:

a. Organizacin, planificacin del proceso, producto, evaluacin y mantenimiento.
b. Control, organizacin, evaluacin del proceso, producto y planificacin del producto.
c. Personal, producto, evaluacin del proceso, organizacin, direccin y control.
d. Direccin, control del proceso, personal, planificacin y organizacin.

7. El software de computadora es: (justifique su respuesta)

a. El producto que los diseadores de software construyen.
b. El producto que los tcnicos de sistema construyen.
c. El producto que los ingenieros de software construyen.
8. Las actividades del marco de trabajo en su orden son

a. Comunicacin, planeacin, modelado, construccin y despliegue
b. Planeacin, comunicacin, modelado, construccin y despliegue
c. Modelado, comunicacin, Planeacin, construccin y despliegue
d. Construccin, modelado, comunicacin, Planeacin y despliegue
9. Mediante un ejemplo a nivel empresarial explique los niveles de la integracin del modelo de
capacidad de madurez
3. ENFOQUE DE LA INGENIERA DEL SOFTWARE
Objetivo general
Dar a conocer la bondades que tiene la prctica de la ingeniera del software como una gua que
coadyuva a la solucin de las diversas problemticas que tienen las empresas en cuanto al control y
manejo de la informacin, aplicando diversos modelos que ilustren de una manera eficaz la forma
como deben orientarse para su permanencia en el medio.
Objetivos especficos
Entender el enfoque propuesto por la Ingeniera de Sistemas.

Analizar la estructura de la Ingeniera de procesos de negocios y de producto
Comprender los diferentes enfoques de la Ingeniera de requisitos y su implementacin al momento
de desarrollar software de alta calidad.
Prueba Inicial
1. Ingeniera de sistemas es:
a. Es el proceso que transforma la necesidad operacional en la descripcin de los parmetros

del sistema, e integra esos parmetros 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 construccin de software de alta calidad
d. Es la aproximacin sistemtica, disciplinada y cuantificable para desarrollar, operar y
mantener software.
2. Ingeniera de requisitos es:
a. comprender lo que realmente el cliente necesita antes de disear y desarrollar un software.

b. Obtener del cliente la informacin 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 obtencin de requisitos.
3. Ingeniera de software es:
a. El establecimiento y uso de principios slidos de la ingeniera para obtener econmicamente

un software confiable y que funcione de modo eficiente en mquinas 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 vehculo para su entrega.
3.1. Ingeniera de sistemas basados en computadora
3.1.1. Sistemas Basados en Computadora
Hace casi 500 aos, Maquiavelo dijo: No hay nada ms difcil que llevar a cabo, ms peligroso de
realizar o de xito ms incierto que encabezar la introduccin de un nuevo orden de cosas14"
En la actualidad estas palabras siguen vigentes, ya que cada vez que iniciamos una determinada
tarea siempre est inmersa en nuestro interior una pequea duda o incertidumbre que hace que las
cosas se presenten de diversas formas con el objetivo de distraer y as desconcentrar un poco la
atencin de la meta que desde el inicio se haba trazado.
No podemos olvidar que todo en la vida tiene dificultades y contratiempos que busca distraer la
mente del ser humano que pretende segn sus conocimientos dar solucin a las distintas
problemticas del mundo empresarial, del mundo que cada vez es ms 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 seran 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 cmputo 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 explcita, pero siempre nos referimos a
aquello que es un todo que lo conforman muchas partes por ejemplo sistema educativo, poltico,
econmico, 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 especfico.
Dentro de los sistemas basados en computadores se habla de macro elementos, que es tambin un
sistema basado en computadoras pero que hace parte de otro sistema mayor pero que se necesitan
que estos tengan una buena relacin 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 harn
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.
Jerarqua de la Ingeniera de Sistemas:

Est conformada por la visin global, visin de dominio, visin de elemento y visin detallada.
Visin Global:
Se analiza a nivel general el negocio o empresa para hacer la proyeccin respectiva y saber hasta
dnde se debe llegar con la solucin, ejemplo: se debe analizar la empresa entre las cuales se
observa la misin, la visin y las necesidades principales
Visin de dominio: Se analiza un dominio especfico 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 aplicacin.
Visin del elemento:
Se analiza el producto a construir o fundamento del negocio. El objetivo es determinar las posibles
falencias antes de su funcionamiento global.
Visin detallada: Anlisis genrico de todos los procedimientos que se estandarizan en el proyecto
o negocio, con el fin de estructurar su aplicacin.
Ingeniera de procesos de negocio: Una visin general

El manejo de la informacin en las empresas es la parte ms importante y a la que se le debe poner
el mejor empeo, debido a que sta es la razn de ser de la misma ya que desde ah se pueden
extraer los mejores informes para que se tome la mejor decisin en cualquier rea o departamento.
No obstante para tener este control se requiere de aplicar con claridad el concepto de ingeniera 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 aplicacin y la infraestructura tecnolgica.
Arquitectura de datos: Se definen cules son las necesidades de la informacin del negocio o de una
parte de l, los cuales representan los atributos que sern utilizados en todo el proceso incluyendo
sus relaciones para saber cmo ser la comunicacin por ejemplo. Vendedor producto, un
vendedor expide productos x o producto x es expedido por un vendedor.
Arquitectura de aplicacin: Son aquellos que permiten transformar los datos en informacin y dar
resultados que ayuden a tomar decisiones.
Infraestructura tecnolgica: Es el soporte (Hardware y Software) donde se transforman y operan la

arquitectura de datos y la arquitectura de aplicacin, como pueden ser los computadores, las redes,
telecomunicaciones, almacenamientos entre otros.
Ingeniera de producto: una visin general

Luego de recolectar toda la informacin que el cliente suministra, se busca satisfacerlo en sus
necesidades, dando como resultado un producto computarizado el cual necesitar de unas
arquitecturas bsicas como pueden ser software, hardware, datos y personas.
Tambin se indica que tecnologa 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 informacin,
ayuda a observar la funcionalidad del producto, diseo e interfaces.
Luego de tener toda esta informacin 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 aplicacin, se deben hacer las respectivas modificaciones de diseo, restricciones,
Modelado del Sistema

Para esta operacin hace parte fundamental el anlisis y diseo al nivel del software y del sistema.
Se debe tener en cuenta que la Ingeniera de Sistemas ayuda a satisfacer las necesidades de los
clientes a travs de su respectiva aplicacin (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
construccin del cdigo.
3.2. Ejercicio del tema 1
Como entiende usted la frase dicha por Maquiavelo: No hay nada ms difcil que llevar a cabo,
ms peligroso de realizar o de xito ms incierto que encabezar la introduccin de un nuevo
orden de cosas
Haga un sntesis 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

aplicacin e infraestructura tecnolgica
3.3. La prctica: una visin genrica
3.3.1. La prctica de la Ingeniera del Software

Ellen Ullman representa un fragmento de vida al relatar los pensamientos de un practicante bajo
presin:
No tengo idea de qu hora es. No hay ventanas en esta oficina, tampoco reloj, slo 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 das.
Tenemos un bicho, el necio demonio de un error. Por eso la pulsacin 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. Podramos 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 debera importar; en otra parte de mi ser ms
tarde, quiz cuando salgamos de este cuarto lleno de computadores- me importa ms por qu, para
quin y con qu propsito estoy escribiendo software. Pero ahora no.
He pasado a travs 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, mtodos y herramientas y tener claridad en el cmo se hacen las cosas para lograr los
objetivos y satisfaccin del cliente.
En este trabajo se mostrar un mapa del camino para llegar al destino planteado, mostrando cuales
son los obstculos que se puedan presentar y saber cules son las soluciones posibles para llegar al
xito. Aqu se ensea el camino a seguir de manera segura y rpida, se indica cuando aumentar o
disminuir velocidad. Una de las partes fundamentales en el desarrollo de software es seleccionar el
mtodo apropiado para tener la certeza de que se ha entendido y que se har uso de las
herramientas apropiadas dentro de la sistematizacin para asegurar calidad de los productos que a
diario se puedan comercializar.
Las actividades a tener en cuenta dentro del marco de trabajo sern la comunicacin, planeacin,
modelado, construccin y despliegue; sobre estas actividades se debe trabajar arduamente con el
fin de que se logre un trabajo exitoso. En la esencia de la prctica para la resolucin de problemas se
debe tener presente lo siguiente. Entender el problema, planear la solucin, llevar a cabo el plan y
examinar el resultado para probar la precisin15
3.3.1.1 Principios esenciales
Dentro de los principios algunos se enfocan en la ingeniera como un todo y otros como una
actividad genrica del marco de trabajo.
1. La razn 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 visin: Si no conocemos la empresa u organizacin o entidad donde de desea

realizar un determinado proyectos o si no sabemos cul es la visin sobre la cual se trabaja,
pues en un alto porcentaje se llega al fracaso en la solucin.
4. Lo que uno produzca, otros lo consumirn: 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
tambin fundamental tener presente a los usuarios ya que en algunos casos se desea
continuar o realizar alguna modificacin o depuracin en el cdigo fuente
5. y as lo convertir en otro usuario del cdigo y as el ciclo de vida del software se puede
extender un poco ms.
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 aos debido a los grandes cambios tecnolgicos e
implementacin 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 tambin
se ve afectado, por eso se recomienda realizar un buen anlisis observando desde la
constitucin de la empresa e ir escudriando hasta el proceso final.
7. Planear la reutilizacin: Se ha considerado la reutilizacin de cdigo como algo muy

importante dentro de la programacin y ms an cuando se trabaja en la programacin
orientada a objetos.
8. Pueden existir interrogantes con respecto a la reutilizacin ya que trabajar sobe algo que se
desconoce es un poco difcil, es por eso, que dentro de la programacin 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 ningn
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 anlisis 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 an 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 prdida 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 ms importante es entenderle al cliente todas
las necesidades para luego plasmar esta informacin en una realidad16.
Prctica de la comunicacin
Una de las actividades ms importante con las que se enfrenta un ingeniero de software, es la
comunicacin efectiva en la que las partes intervienen para hallar una solucin a una problemtica
que se presenta permanentemente en las empresas y sobre la cual se har un anlisis 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 atencin 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 reunin, lo cual nos obliga a hacer investigaciones pertinentes al
tema a trabajar para que cuando se instale el dilogo se sepa con certeza del tema que se est
hablando y no entremos grandes vacos que lo nico que hacen es separarlo un poco ms de la
realidad.
3. Alguien debe facilitar la actividad: Se debe nombrar un lder o mediador que facilite la
conversacin entre las partes y que modere la reunin para que no se presentes discordias ni
dificultades entre las partes.
4. La comunicacin cara a cara es lo mejor: Es fundamental este tipo de reuniones pero es

importante que exista otra representacin de informacin para hacer el respectivo
comparativo y hacer una mejor discusin 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 dilogo 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 ningn momento.
6. Buscar colaboracin: Cuando el conocimiento colectivo se combina para definir las

caractersticas 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 proyeccin hacia lo que realmente se espera del trabajo que se
ha de iniciar en el menor tiempo posible.
7. Conservar el enfoque, examinar un mdulo a la vez: La idea principal de este punto es que el
mediador busque siempre redondear el tema que inici para que no halla ambigedad 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
orientacin 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 crticos para empezar a corregirlos poco a poco hasta encontrar la solucin.
10. La negociacin no es un concurso, esta funciona mejor cuando ambas partes ganan. Cuando se
tiene entre las partes una meta y unos objetivos en comn 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 satisfaccin en su proyecto terminado17.
Prctica de la planeacin
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 planeacin 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 bsicos para evitar
contratiempos.
1. Entender los alcances del proyecto: Lo ms importante de un proyecto que se desee desarrollar
es saber hasta dnde 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 planeacin: El cliente que sabe sus necesidades orientar
al ingeniero sobre lo que realmente necesita y luego entrara a negociar entre las partes las
fechas de entrega y dems asuntos del proyecto.
3. Reconocer que la planeacin 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 solucin implementada, pues al procesar resultados se obtienen nuevas
necesidades o cambios a aplicar.
4. Estimar con base en el conocimiento disponible: Aqu en esta estimacin se da la idea con
respecto al esfuerzo, costo y tiempo de terminacin 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 solucin de problemas el ser humano est expuesto a
cometer errores indirectamente y esto hace que el proyecto sufra pequeos retrasos por lo
tanto nunca se trabajar el tiempo completo como se establece en el cronograma, por lo tanto
debe ser prudente en la asignacin 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 terminacin 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
ejecucin 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 mayora de los
proyectos de software, estos van detrs 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
planeacin porque de esa manera habr ms 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, diseador y/o programador
realice un sin nmero de trabajos casi que al mismo tiempo, pero lo ms importante es encontrar la
magnitud de lo que se requiere para delimitar e iniciar con trabajos especficos de acuerdo al orden
de prioridades que tenga la empresa.
Al iniciar la solucin 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 solucin.
Se debe tener tambin claridad mediante actas sobre cada reunin que se realice y los cambios
pertinentes para que no se presenten inconvenientes durante el proceso o en la entrega del
proyecto18.
Prctica 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 cermica lo primero que se debe tener es el molde para que se tenga total originalidad. En la
ingeniera de software se crean dos clases de modelos los cuales con el de anlisis y el de diseo.
Anlisis:
En este se debe tener presente el dominio de la informacin, el dominio funcional y el de
comportamiento.
Diseo: Muestran las caractersticas del software que sirven como base para la construccin.
Principios que se deben tener presente en esta prctica
Modelado de anlisis
1. El dominio de la informacin de un problema debe representarse y entenderse: Toda la
informacin que se manejar dentro de una organizacin o empresa se debe entender con
claridad para saber cmo va a ser la forma de comunicacin 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 gua ambiente externo. El
comportamiento de un software se da principalmente de acuerdo a entrada de informacin 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 informacin, funcin y comportamiento deben partirse de forma
que descubran el detalle de una manera estratificada (o jerrquica): El anlisis es el principal
paso para la solucin de problemas de ingeniera y si el problema es muy grande, este debe
dividirse en problemas ms pequeos hasta que se entienda uno por uno.
5. La tarea del anlisis debe moverse de la informacin esencial hacia el detalle de la

implementacin. El anlisis 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 solucin19.
19
Roger S. Pressman
Modelado de diseo
1. El diseo debe ser rastreable hasta el modelo de anlisis: El modelo enuncia el dominio de la
informacin 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 diseo de datos es tan importante como el diseo de funciones de procesamiento. Se debe

estructurar muy bien los datos para que ayuden a simplificar el flujo del programa, el diseo y
la implementacin de todas las partes del software.
4. Las interfaces (internas y externas) deben disearse con cuidado: La forma como se manejan
los datos en un sistema reflejar la eficiencia de su proceso, evita errores y simplifica el diseo.
Una interfaz bien diseada ayuda a la realizacin de pruebas y validar sus funciones.
5. El diseo de interfaz del usuario debe ajustarse a las necesidades del usuario final. Lo ms
importante del diseo de la interfaz es la facilidad de uso para satisfaccin del usuario no
importando como est estructurado internamente evitando la percepcin que los usuarios le
pueden dar por su simplicidad en donde dicen que est mal hecho.
6. El diseo a nivel de componentes debe ser independiente del modo funcional. La funcionalidad
que se entrega debe centrarse en una funcin nicamente y terminada en su totalidad.
7. Los componentes deben estar apareados entre s en forma mnima y vinculada con el ambiente
externo.
8. La presentacin del diseo (modelos) deben ser fcilmente entendibles: Si el diseo no es fcil
de entender, es difcil que sirva como medio efectivo de comunicacin, la idea principal es
comunicar informacin a los que generan el cdigo, a los que probarn el software o a quienes
continen con el software en dl futuro.
9. El diseo debe desarrollarse de manera iterativa. En cada iteracin el diseador debe buscar la
mayor simplicidad. El diseo 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 diseo
procurando mostrar la mejor calidad posible que se da en el desarrollo de aplicaciones.
Dentro de la prctica del modelado y el diseo es recomendable destacar la gran responsabilidad

que se tiene para que el software o la solucin 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 anlisis pero lo que si comprende en es el modelado de diseo porque es la forma
como l va a observar el ingreso y salida de informacin.
Tener presente que el cliente es el que exige como quiere ver la informacin pero muchas veces se
le debe hacer claridad no tanto por la visualizacin de un formulario sino la mejor manera del
plasmar la informacin 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.
Prctica de la construccin
Comprende programacin 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 integracin que son las que se realizan
a medida que se construye el software, las de validacin que son las que evalan la satisfaccin de
los requisitos completamente y las de aceptacin que son las que realiza el cliente con el producto
final.
Principios y conceptos de codificacin
Principio de preparacin:
Antes de iniciar la programacin se debe tener presente lo siguiente: Entender el problema, los
principios bsicos de diseo, el lenguaje de programacin con su ambiente de operacin y el
conjunto de pruebas de unidad.
Principio de codificacin:
Al iniciar la codificacin se debe tener presente:
Seleccionar la estructura de los datos para tener un mejor diseo, mantener en lo posible la lgica
simple, manejar ciclos anidados para hacer ms fcil la prueba, manejo de variables
adecuadamente, documentar el cdigo y el manejo de sangras en el cdigo.
Principio de validacin: Al terminar los pasos anteriores debe realizar:
Realizar pruebas y corregir errores y re-fabricar en algunos casos el cdigo.
Principios de prueba
Algunos desarrolladores segn su concepcin 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 pretensin 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 anlisis 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, sern rastreables hasta el 20% de la aplicacin
completa
4. Las pruebas deben comenzar En los pequeo y progresar hacia lo grande: Las pruebas
siempre inicial con la parte ms 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 aplicacin no falle en el
momento de ser entregada o al tiempo de estar en ejecucin, por lo tanto es recomendable hacer
uso de algunos formatos que trabaja la empresas para implementar un manual pedaggico 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 informacin
manual y as corroborar la calidad del software implementado20.
Despliegue
Depende del modelo que se seleccione se harn entregas (despliegue) por etapas para satisfacer las
necesidades del cliente y esto hace se encuentren errores que el programador no haba detectado.
Por cada etapa o avance que se entregue se debe proporcionar la documentacin necesaria y el
personal idneo para que de la capacitacin.
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 ms de lo que se haba pactado inicialmente y esto no es de agrado para el
equipo del proyecto. Sobre la administracin de expectativas, Noami Kartum establece:
El punto inicial para administrar las expectativas es volverse ms 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 ms 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 documentacin, instaladores, libreras, entre otros.
Se debe establecer un rgimen de soporte antes de entregar el software:
20
Roger S. Pressman
3. la responsabilidad y la informacin 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 planeacin para el soporte y la forma de tener un registro especfico para evaluar
los soportes realizados.
4. Se debe proporcionar material instructivo apropiado a los usuarios finales: Se debe realizar una
capacitacin apropiada e indicar pautas para la solucin de problemas que se presenten
durante la ejecucin del software.
5. El software con errores se debe arreglar primero y entregarse despus: En muchos casos
debido a la presin por el tiempo de entrega de software se hacen entregas por etapas de mala
calidad con la claridad que en la prxima versin se har la correccin necesaria, pero el cliente
al detectar errores, estos quedarn impresos y guardados en su mente y ms an cuando
causan grandes daos 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 informacin pueden ocurrir un sin nmero de errores que ocasionen gran prdida de informacin
la cual es fundamental para la ejecucin de las dems 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 informacin sigue siendo voltil 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 informacin, prdida 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 ms relevantes a un
problema ficticio ya sea administrativo, contable, financiero, entre otros.
3.5. Ingeniera de Requisitos
3.5.1. Un puente hacia el diseo y la construccin

Muchos desarrolladores se sienten tan atrados por la parte de programacin, 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 ingeniera de requisitos es una
prdida de tiempo y que los usuarios finales entendern 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 anlisis en combinacin con principios, mtodo y
herramientas con mayor seguridad el desarrollo de una solucin tiende a fallar en el menor tiempo
posible.
La ingeniera de requisitos se debe adaptar a las necesidades del proceso, proyecto, producto y
personas que integran el proyecto. En la solucin de problemas empresariales y luego de tener toda
la informacin 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 ms
apremiantes.
Tareas de la Ingeniera de Requisitos
Inicio:
Las necesidades del control en el manejo de la informacin 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 pequeo conversacin con alguien se pueden generar proyectos no solo
desde el punto de vista de programacin sino desde la parte administrativa, comercial, de servicios,
entre otros.
Para el desarrollo de aplicaciones o problemas empresariales, el cliente debe tener muy buena
comunicacin 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 das nos
exigen ms los grandes competidores y para poder estar y subsistir se debe cambiar.
Obtencin:
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 solucin ya que
es algo que no se define a simple vista sino que es a muy largo plazo. Existen tres puntos que
demuestran lo difcil que es la obtencin.
1. Problema de mbito: El cliente usuario no entrega los detalles adecuadamente y lo que hace es
distorsionar lo que requiere.
2. Problema de compresin: Los clientes usuarios nos saben la necesidad, desconocen en muchos
casos las bondades que ofrece un sistema de cmputo, no entregan por completo la
informacin bsica ya que creen que el ingeniero descubre lo que ellos necesitan o dan
informacin muy distante de la realidad.
3. Problema de volatilidad: La forma organizada de la recoleccin de la informacin ayuda a evitar

inconvenientes debido a que los problemas empresariales cada da van cambiando.
Elaboracin:
Su enfoque principal la elaboracin de modelos que permitan indicar las funciones, las
caractersticas y restricciones de la aplicacin.
En esta elaboracin se har uso de escenarios de usuario que indica la forma en que interactan los
usuarios finales y el sistema, mostrando sus clases y relaciones mediante la variedad de diagramas
UML.
Negociacin:
En el campo de la solucin de problemas empresariales, es normal que los usuarios y clientes
siempre estn esperando ms de lo que se puede entregar.
Lo ms importante para tener una buena negociacin es que se tengan bien definidos y organizados
los requisitos y ms 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.
Especificacin:
En esta se debe manejar una plantilla estndar para garantizar la consistencia de los requisitos
recolectados y buscando la mayor facilidad para su entendimiento.
Es el resultado de un arduo trabajo de ingeniera de requisitos que sirve para la ejecucin del
concepto de ingeniera del software.
Validacin:
En esta parte se analiza de toda la informacin extrada mediante la recoleccin de requisitos para
saber si existen falencias, omisiones, errores pero ya corregidos y si los estndares estn siendo
usados adecuadamente para el proceso, proyecto y producto.
Dentro de la validacin se cuenta con un equipo de trabajo completo como pueden ser ingenieros
de software, clientes, usuarios y dems personas que harn parte fundamental del proyecto y los
que encontraran las dificultades que se tengan en la informacin recolectada.
Gestin 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 ingeniera de requisitos
El trabajo en equipo es lo ms importante dentro del desarrollo de un proyecto, aunque la

ingeniera de requisitos solamente gua 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 solucin exitosa se tendrn en cuenta algunos pasos necesarios dentro de la
ingeniera 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 mltiples puntos de vista: Todos los requisitos se extraen de diversas

personas y como cada uno est interesado en lo que es de su inters, es un poco difcil
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 colaboracin: Lo ms importante dentro de del desarrollo de

proyectos es que los clientes trabajen en compaa con los interesados, evitando con esto
dificultades durante toda la etapa de implementacin. El principal objetivo del ingeniero de
requisitos es encontrar reas en comn y reas en conflicto para llegar a un acuerdo y
centralizar todo en un objetivo nico.
4. Formulacin de las primeras preguntas: Estas se enfocan a los clientes y otros interesados, pero
estas preguntas deben ser libres libres de contexto.
Quin requiere el trabajo?

Para quin es la solucin?
Qu beneficio econmico 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
Cules problemas debera solucionar?
Cul es el ambiente en el que se aplicar la solucin?
Las restricciones afectarn la bsqueda de la informacin?
Obtencin de requisito
Recopilacin conjunta de requisitos

Los participantes y los desarrolladores trabajan conjuntamente para encontrar los problemas,
proponer soluciones, mostrar enfoques y mostrar requisitos para la solucin pero utilizan algunos
puntos fundamentales.
1. La reunin 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 reunin
5. Utilizar medios adecuados para entender la necesidad como pueden ser tablero electrnico,
foro virtual, etc.
6. Entender el problema, proponer soluciones, mostrar distintos enfoques y guiar lo manera de

lograr el objetivo.
Despliegue de la funcin de calidad (QFD): Este busca satisfacer la necesidad del cliente desde la
ingeniera 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 dnde va el trabajo como pueden ser grficos en pantalla con respecto a lo
analizado de la recoleccin de requisitos.
2. Requisitos esperados: Estos estn inmerso en el sistema o producto, pero su ausencia causara
insatisfaccin. Ejemplo de estos requisitos la facilidad de uso, confiabilidad y la instalacin de
la aplicacin.
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, observacin y revisin de la informacin histrica para tener
claridad en la recoleccin de los requisitos y luego toda esta informacin se transforma en una tabla
para su mejor interpretacin con el cliente.
Desarrollo de casos de uso:

Este cuenta una historia como el usuario puede ver la comunicacin 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
cmo opera el sistema.
Entre el usuario final y el caso de uso existen diferencias ya que un usuario puede desempear
varios papeles al usar la aplicacin 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, considrese al operador de una mquina (un usuario) que interacta con la computadora
de control para una clula de manufactura que contiene varios robots y mquinas de control
numrico. Despus de la revisin cuidadosa de los requisitos, el software para la computadora de
control requiere cuatro diferentes modos (actores) para su interaccin:
Modo de programacin, modo de prueba, modo de monitoreo y modo de resolucin 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 mquina puede
desempear todos estos papeles. En otras situaciones, son personas diferentes las que pueden
desempear el papel de cada actor.
Jacobson sugiere varias preguntas que se deberan contestar mediante casos de uso.
Quin(es) es (son) el(los) los actor(es) primario(s)?
Cules son las metas del actor?
Cules son las condiciones previas que deben existir antes de comenzar la historia?
Cules son las tareas o funciones principales que realiza el actor?
Cules excepciones podran considerarse mientras se describe la historia?
cules son las variaciones posibles en la interaccin del actor?
Cul es la informacin del sistema que el actor adquirir, producir o cambiar?
El actor tendr que informar al sistema acerca de cambios en el medio ambiente externo?
Cun es la informacin que el actor desea del sistema?
El actor quiere ser informado acerca de cambios inesperados? 21
Construccin del modelo de anlisis

Los modelos de anlisis van cambiando a medida que se va adquiriendo nuevos conocimientos a
travs 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 anlisis, esto facilita el diseo 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 anlisis

Son varias las maneras de encontrar los requisitos para un sistema o aplicacin para computadores
como por ejemplo los casos de uso o utilizar modos de representacin para mostrar el modelo de
anlisis.
Elementos comunes dentro de los modelos de anlisis.

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 informacin.
Negociacin 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.
Validacin de requisitos
Al tener los requisitos fundamentales para el modelo de anlisis, se debe analizar para que no tenga
inconvenientes que obstaculicen las dems tareas o actividades que se deseen implementar. Para
analizar el modelo de anlisis 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 abstraccin? Esto es
algunos requisitos proporcionan un grado de detalle tcnico que sea inapropiado en esta
etapa?
El registro es necesario en realidad o presenta una caracterstica 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 tcnico 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 informacin, la funcin y el

comportamiento del sistema que ser construido?
El modelo de requisito se ha sometido a particin para que exponga en forma progresiva

informacin ms detallada acerca del sistema?22

Mediante un ejemplo a nivel empresarial indique como aplicara las tareas de la ingeniera de
requisitos
Cree usted que al aplicar el concepto sobre inicio del proceso de la ingeniera de requisitos,
ayudar de forma directa a solucionar los problemas que las empresas tienen en el control y
manejo de informacin?, justifique su respuesta
Cree usted que al aplicar el concepto de casos de uso es suficiente para que el cliente
comprenda claramente la problemtica que se va a solucionar?, justifique su respuesta.
Prueba Final
1. La meta de la Ingeniera 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 informacin de manera efectiva.
d. Definir el hardware y software que se utilizar en el desarrollo del producto.
2. La meta de la Ingeniera del producto es:
a. Asignar por separado el proceso de requisitos sistmicos.

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 ms relevantes de la prctica de la ingeniera del software, y aplique estos conceptos.
4. FILOSOFA ACERCA DE LA INGENIERA 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 especficos de la unidad
Identificar la propuesta de la Filosofa de Orientacin a Objetos y la aplicacin mediante el

lenguaje unificado de modelamiento.
Prueba Inicial
Desde un punto de vista orientado a objetos
1. un componente es:
a. La recopilacin de la informacin necesaria.
b. Un conjunto de clases que colaboran entre si.
c. Explorar y definir cada clase.
d. Una interfaz de usuario.
2. Un atributo es:
a. Un objeto intangible.
b. Un conjunto de datos y operaciones sistmicas.
c. coleccin de valores de los datos que describen una clase.
d. Una rama de la ingeniera del software.
3. Una clase es:

a. Una descripcin generalizada (por ejemplo, una plantilla, un patrn o un plano de trabajo)
que describe una coleccin de objetos similares.
b. Una abstraccin 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 especfica.
b. Una clase de una descripcin generalizada.
c. Coleccin de objetos similares.
d. Un encapsulamiento general de procesos.
5. Una subclase es:

a. Una clase bsica.
b. Generacin de conjunto de clases.
c. una especializacin de la superclase
d. Un objeto sin datos.
4.1. Programacin Orientada A Objetos
4.1.1. Orientacin 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 anlisis y diseo son acciones iterativas. Es probable que la
elaboracin de la clase de anlisis original requiera pasos de anlisis adicionales, que son seguidos
por los pasos de modelado del diseo para representar la clase de diseo elaborada.
Cada clase de un componente se ha elaborado completamente para incluir todos los atributos y las
operaciones relevantes para su implementacin. Como parte de la elaboracin del diseo, tambin
deben definirte todas las interfaces (mensajes) que permiten que las clases se comuniquen y
colaboren con otras clases de diseo.
Para lograrlo el diseador empieza con el modelo de anlisis y elabora clases de anlisis (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 construccin de un software es primero que todo recopilar la informacin

necesitada, la cual se convierte en las necesidades exigidas por el cliente. El objetivo del anlisis
orientado a objetos (AOO) es definir todas las clases (adems de las relaciones y el comportamiento
asociado con ellas) relevantes para el problema y que deben resolverse. Los conceptos orientados a
objetos (OO) estn bien establecidos en el mundo de la ingeniera del software.
Atributo: una coleccin 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 descripcin
generalizada (por ejemplo, una plantilla, un patrn o un plano de trabajo) que describe una
coleccin de objetos similares.
Objetos:
Instancias de una clase especfica. Los objetos heredan los atributos y operaciones de una clase.
Subclase:
Una especializacin de la superclase. Una subclase puede heredar tanto los atributos como las
operaciones de una superclase.
Superclase:
Tambin llamada una clase bsica, es una generalizacin de un conjunto de clases que estn
relacionadas con ella.
Un objeto contiene datos y operaciones.

Podemos distinguir dos tipos de objetos degenerados:
Un objeto sin datos (que sera lo mismo que una biblioteca de funciones)
Un objeto sin operaciones, con slo operaciones del tipo crear, recuperar, actualizar y borrar (que
se correspondera 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 rectngulo con un nombre subrayado
Grfico #9(Elaborado por los autores)
Ejemplo de varios objetos relacionados
Grfico # 10
(Elaborado por los Autores)
4.1.2. UML23
UML = Unified Modeling Lenguaje

Un lenguaje de propsito 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 mtodos y tcnicas OO, con muchos aspectos en comn pero utilizando distintas
notaciones
Inconvenientes para el aprendizaje, aplicacin, construccin y uso de herramientas, etc. Pugna
entre distintos enfoques (y correspondientes gurs)
Los modelos de UML que se tratan en esta parte son los siguientes:
Diagrama de Estructura Esttica,

Diagrama de Casos de Uso.
Diagrama de Secuencia.
Diagrama de Colaboracin.
Diagrama de Estados.
HISTORIA DEL UML
Comenz como el Mtodo Unificado, con la participacin de Grady Booch y Jim Rumbaugh.
Se present en el OOPSLA95
El mismo ao se uni Ivar Jacobson. Los Tres Amigos son socios en la compaa Rational
Software. Herramienta CASE Rational Rose
INCONVENIENTES DEL UML
Definicin del proceso de desarrollo usando UML. UML no es una metodologa

No cubre todas las necesidades de especificacin de un proyecto software. Por ejemplo, no
define los documentos textuales
Ejemplos aislados
Monopolio de conceptos, tcnicas y mtodos en torno a UML y el OMG
PERSPECTIVAS UML
UML es el lenguaje de modelado orientado a objetos estndar predominante ahora y en los

prximos aos.
Razones:
Participacin de metodlogos influyentes
Participacin de importantes empresas
Estndar del OMG
Evidencias:
Herramientas que proveen la notacin UML
Edicin de libros (ms de 300 en www.amazon.com)

Congresos, cursos, camisetas, etc.
PAQUETES UML
Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas

agrupando elementos de modelado
Se representan grficamente como:
Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema)

Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento
pertenece a (est definido en) slo un paquete
Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una
relacin 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 notacin que se expresa como diagramas sirven para representar
modelos/subsistemas o partes de ellos
El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por
ciento de UML-- Grady Booch.
Obsrvese el siguiente grfico:
Grfico #11 Elaborado por los autores

Importacin de Paquetes
En Ulm se puede plasmar paso a paso todos los procesos que se desean implementar en la solucin
de un problema empresarial ya sea desde la parte administrativa o desde el desarrollo de
aplicaciones, pero en ningn momento le va a solucionar problemas como por ejemplo de
programacin o de la lgica sino que esta se debe aplicar la primera en un lenguaje de
programacin y la segunda en esta aplicacin u otra que se tenga disponible para su interpretacin
y saber as como va a ser en flujo de informacin 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 difcil 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 desnimo para seguir adelante con los
proyectos.
XMLXML es una tecnologa en realidad muy sencilla que tiene a su alrededor otras tecnologas que
la complementan y la hacen mucho ms grande y con unas posibilidades mucho mayores. Es decir,
al lenguaje as como a las tecnologas que trabajan con l, sus usos, ventajas y modos de llevar a
cabo las tareas.
XML, con todas las tecnologas relacionadas, representa una manera distinta de hacer las cosas, ms
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
importantsimo en este mundo actual, que tiende a la globalizacin y la compatibilidad entre los
sistemas, ya que es la tecnologa que permitir compartir la informacin de una manera segura,
fiable, fcil. Adems, 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 validacin de
estos o el recorrido de las estructuras corre a cargo del lenguaje y est especificado por el estndar,
de modo que el programador no tiene que preocuparse por ello.
Vemos que XML no est slo, sino que hay un mundo de tecnologas alrededor de l, de
posibilidades, maneras ms fciles e interesantes de trabajar con los datos y, en definitiva, un
avance a la hora de tratar la informacin, que es en realidad el objetivo de la informtica 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 ms 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 informtica y el tratamiento de datos, ya que permite muchos avances a la
hora de trabajar con ellos.
Para los que conozcan tambin el lenguaje HTML, que espero que seis 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 informacin que se desea mostrar.
El XML se preocupa por estructurar la informacin que pretende almacenar. La estructura la marca
la lgica propia de la informacin.
El desarrollo del HTML estuvo marcado la competencia entre los distintos visores del mercado. Cada
uno quera ser el mejor e inventaba etiquetas nuevas que a la larga entraban a formar parte del
estndar del W3C, como la etiqueta <FRAME>.
El desarrollo del XML est siendo llevado a cabo con rigor, siempre ajustado a lo que marca el
estndar que desarrolla el W3C, entidad que est desarrollando el XML con ms diligencia que las
empresas con intereses particulares. Procesar la informacin en HTML es inviable, por estar
mezclada con los estilos y las etiquetas que formatean la informacin.
En XML se puede procesar la informacin con mucha facilidad, porque todo est ordenado de una
manera lgica, as mismo el formateo de la informacin para que se pueda entender bien por el
usuario es viable a travs de un pequeo procesamiento, a travs 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 idntico a la hora de servir, recibir y procesar la informacin que el HTML, para
aprovechar toda la tecnologa 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 fcil de leer y editar.
Que fuese fcil 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 prcticos.
Comunicacin de datos. Si la informacin se transfiere en XML, cualquier aplicacin podra

escribir un documento de texto plano con los datos que estaba manejando en formato XML y
otra aplicacin recibir esta informacin y trabajar con ella.
Migracin de datos. Si tenemos que mover los datos de una base de datos a otra sera muy
sencillo si las dos trabajasen en formato XML.
Aplicaciones web. Hasta ahora cada navegador interpreta la informacin a su manera y los
programadores del web tenemos que hacer unas cosas u otras en funcin del navegador del
usuario. Con XML tenemos una sola aplicacin que maneja los datos y para cada navegador o
soporte podremos tener una hoja de estilo o similar para aplicarle el estilo adecuado. Si
maana nuestra aplicacin debe correr en WAP solo tenemos que crear una nueva hoja de
estilo o similar.
Son slo unos ejemplos que esperamos que comprendas aunque sea por encima ya que todava hay
muchas cosas que no sabes sobre XML y las tecnologas 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 evaluacin de los procesos de
desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por el Instituto de
Ingeniera del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versin
en enero de 2002. CMMI se desarroll para facilitar y simplificar la adopcin de varios modelos de
forma simultnea, y su contenido integra y da relevo a la evolucin 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 funcin de qu reas de procesos consiguen sus objetivos y se gestionan con
principios de ingeniera. Es lo que se denomina un modelo escalonado, o centrado en la madurez de
la organizacin.
El modelo para ingeniera de sistemas (SE-CMM) establece 6 niveles posibles de capacidad para una
de las 18 reas de proceso implicadas en la ingeniera de sistemas. No agrupa los procesos en 5
tramos para definir el nivel de madurez de la organizacin, 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 haba defensores de ambos tipos de representaciones. El

resultado fue la publicacin del modelo con dos representaciones: continua y escalonada. Son
equivalentes, y cada organizacin puede optar por adoptar la que se adapte a sus caractersticas y
prioridades de mejora
La visin continua de una organizacin mostrar la representacin de nivel de capacidad de cada

una de las reas de proceso del modelo.
La visin escalonada definir a la organizacin dndole 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 versin que integra
desarrollo de software e ingeniera de sistemas (CMMI-SE/SW) y 25 en la que cubre tambin
integracin de producto (CMMI-SE/SW/IPPD).
Vistas desde la representacin continua del modelo, se agrupan en 4 categoras segn su finalidad:
Gestin de proyectos, Ingeniera, Gestin de procesos y Soporte a las otras categoras. Vistas desde
la representacin escalonada, se clasifican en los 5 niveles de madurez. Al nivel de madurez 2
pertenecen las reas de proceso cuyos objetivos debe lograr la organizacin para alcanzarlo.
El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de

evaluacin de los procesos de una organizacin. 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 investigacin y desarrollo patrocinado por el Departamento de Defensa de los

Estados Unidos de Amrica y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca
registrada del SEI.
Crtica
Frecuentemente se critica al modelo CMM por no ser ms especfico en la definicin de los
procesos. Para guiar a las organizaciones a definir y mejorar sus procesos indica qu actividades han
de realizar, pero nada sobre cmo hacerlo. Esto es as tanto en lo referente a la ingeniera como a
las herramientas o tcnicas de gestin, aunque hace una curiosa excepcin en las revisiones por
pares (peer reviews).
Del mismo modo, aunque insiste continuamente en la necesidad de las mtricas, no da ninguna gua
concreta del tipo de mtricas que son aceptables para una correcta prctica profesional.
Los tcnicos se quejan a menudo de la enorme carga de "papeleo" que impone el modelo, vindolo
ms como un mecanismo de control por la direccin que una herramienta que les ayude en su
trabajo.
Tambin resulta muy complejo, ms todava el CMMI, lo que hace que durante algn tiempo resulte
para mucha gente algo esotrico.
Sntesis de los modelos de procesos CMM y CMMI para desarrollo y mantenimiento de software.
CMMI (y previamente CMM) puede emplearse con dos finalidades:
1. Gua para mejorar los procesos que intervienen en el desarrollo y mantenimiento del software.
2. Criterio para determinar el nivel de madurez de una organizacin 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
Homogneamente 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
sern ms o menos maduras.
Los modelos CMMI ayudan a orientar al desarrollador a la forma como debe llevar a cada la solucin
de un proyecto empresarial, proyectndolo a que la solucin est enfocada directamente con la
estandarizacin de todos sus procesos para que esta solucin puede servir para otras dificultades de
otras empresas.
No obstante no se puede aplicar completamente la estandarizacin en todos los proyectos, pero al

analizar lo que realmente se quiere, se optar por seleccionar solo la informacin requerida para el
caso.
4.2. Ejercicio del tema 1
Que es la programacin orientada a objetos y cules son sus elementos principales que lo
componen
Que es el UML, cules son sus ventajas y sus desventajas
Que es el XML y que diferencia existe con respecto al UML
Cul es la diferencia entre SEI/CMM/CMMI y cul es su objetivo en la implementacin dentro

del desarrollo de software, puede complementar con informacin de internet o libros.
Qu opina usted con la crtica 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 crculo con un nombre subrayado.

b. Un cuadrado con un nombre subrayado.
c. Un rectngulo con un nombre subrayado.
d. Una circunferencia con un nombre subrayado.
3. En un paquete UML, cada paquete corresponde a:
a. Una organizacin para los modelos.

b. Una relacin de dependencia mutua.
c. Una definicin de superclases.
d. Un submodelo del modelo.
5. ESTNDARES Y METODOLOGA
Objetivo general
Desarrollar en el estudiante un alto grado de anlisis, que le permita la comprensin de la

estructura del conocimiento de la ingeniera del software, para aplicarlo posteriormente en los
diferentes tipos de resolucin de problemas que puedan presentarse aplicables en diversas reas
Objetivos especficos de la unidad
Analizar los aportes realizados a la Ingeniera del Software por medio de los estndares de la
IEEE
Comprender la metodologa propuesta por la Ingeniera del Software de sala limpia, para los
sistemas basados en componentes
Entender la manera de aplicar la reingeniera tanto en el software como en el hardware dentro

de la empresa u organizacin.
Prueba Inicial
1. Reingeniera es:
a. La reconstruccin de un producto.
b. Crear un producto con una mejor funcionalidad, desempeo y fiabilidad, as como una
mejor facilidad de mantenimiento.
c. La bsqueda de una mayor facilidad de mantenimiento.
d. Ninguna de las anteriores.
2. Reestructuracin:
a. Es la modificacin del cdigo fuente o los datos con la finalidad de adecuarlos para futuros
cambios.
b. Ocurre cuando la arquitectura bsica de una aplicacin es slida, aun cuando el interior
tcnico necesite trabajarse.
c. Se inicia cuando grandes partes del software son funcionales y slo un subconjunto de los
componentes y datos necesitan una modificacin extensa.
3. Ingeniera 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 arquitectnico especfico para cierto
dominio de aplicacin.
b. Es un proceso que concede particularmente importancia al diseo y la construccin de
sistemas reutilizables.
c. Integra los componentes para formar subsistemas y la aplicacin cono un todo. Adems,
algunos componentes personalizados son sometidos a ingeniera para enfrentar aquellos
aspectos del sistema que no pueden ser implementados con el uso de los componentes
existentes.
d. La Reutilizacin 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. Ingeniera del Software de Sala Limpia
5.1.1. El enfoque de sala limpia

Cuantas veces se ha escuchado la expresin: hazlo bien la primera vez esa es la filosofa primordial
de la ingeniera del software de sala limpia.
Un proceso que destaca la verificacin matemtica de la correccin antes de que comience la

construccin del programa y la certificacin de la confiabilidad del software como parte de la
actividad de pruebas. El rasgo fundamental es tasas de falla extremadamente bajas que seran
difciles o imposibles de lograr empleando mtodos menos formales. Lo hace un ingeniero de
software especialmente entrenado. Es importante porque los errores implican la reelaboracin. 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 introduccin al proceso de planeacin de pruebas. Las ms
importantes caractersticas de la sala limpia son la prueba de la correccin y las pruebas estadsticas
de utilizacin.
Este enfoque es eficaz en cuanto a costo y tiempo para establecer un enfoque de fabricacin que
evite la introduccin de defectos de produccin. Ms 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 especificacin y el diseo y luego fabricarlo en una forma limpia.
El enfoque de sala limpia utiliza una versin especializada del modelo de proceso incremental.
Mediante pequeos equipos de software independientes se desarrolla una lnea 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 ingeniera del software de sala limpia son:
Planificacin del incremento: se crea un plan de desarrollo de sala limpia, donde se crea la
funcionalidad de cada incremento.
Recopilacin de requisitos.
Especificacin de la estructura de cajas: ajustarse a los principios de anlisis operativos. Se
utiliza un mtodo de especificacin que emplea estructuras de cajas, para describir la
especificacin funcional.
Diseo formal. Especificaciones, estableciendo distinciones entre las actividades a realizar.

(Cajas negras)
Verificacin de la correccin.
Generacin de cdigo, inspeccin y verificacin.
Planificacin de pruebas estadsticas.
Certificacin.
La nica forma de que en un programa ocurran los errores es que un autor los coloque ah. No se
conocen otros mecanismos. La prctica correcta busca evitar la insercin 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 prctico de someter el proceso de desarrollo de software
al control estadstico 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 ingeniera del software basada en matemticas para corregir diseos de software y en
la prueba de software basada en estadsticas para la certificacin de la fiabilidad del software.
Esta ingeniera de software de sala limpia implementa tcnicas de prueba con una alta probabilidad
de descubrir errores de alto impacto, adems de verificar las especificaciones del diseo utilizando
una prueba de correccin basada matemticamente. Obviamente, el enfoque de sala limpia aplica
la mayora, si no todos, los principios y conceptos bsicos de la ingeniera del software.
Los bueno anlisis y procedimientos de diseo son esenciales si se quiere obtener alta calidad.
En la ingeniera de sala limpia se realizan pruebas basadas en la estadstica. Aqu la prueba unitaria y
la depuracin se sustituyen verificando la correccin y las pruebas basadas en estadstica.
5.1.1.1 Especificacin funcional

La ingeniera del software de sala limpia cumple con los principios de anlisis operativo empleando
un mtodo llamado especificacin de estructura de cajas. Una caja encapsula al sistema en algn
grado de detalle. Por medio de un proceso de elaboracin o refinamiento en niveles, las cajas se
refinan en una jerarqua donde cada una tiene transparencia referencial.
Esto es: el contenido de informacin de cada especificacin de caja es suficiente para definir su
refinamiento, sin depender de la implementacin de alguna otra caja. Esto le permite al analista
partir un sistema jerrquicamente, moverse desde la representacin esencial en la parte superior
hacia un detalle especfico de la implementacin 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 anloga a los objetos
(estmulos respuestas)
Caja transparente: contiene el diseo de procedimiento para la caja de estado.
Diseo de sala limpia

Utiliza con amplitud la filosofa de programacin estructurada aplicada mucho ms estricta. Esta se
emplea con eficiencia para refinar la funcin. (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 informacin y clasificacin de datos se
aprovecha para crear el diseo de datos.
Si el lector se limita slo a las estructuras conforme desarrolla un diseo de procedimiento, la

prueba de correccin es directa. Si se violan las estructuras las pruebas de correccin son difciles o
imposibles.
Probar que un diseo 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 verificacin del diseo son:
Reducir la verificacin a un proceso finito.

Permitir al equipo de sala limpia verificar cada lnea de diseo y cdigo.
Produce mejor cdigo que la prueba unitaria, entre otros
Es bueno aclarar que la verificacin del diseo debe aplicarse al propio cdigo fuente.
(Verificacin de la correccin)
Pruebas de sala limpia
Las pruebas estadsticas son parte integral de la misma estrategia de pruebas del mismo enfoque
de sala limpia.
La prueba estadstica equivale a probar el software en la forma que los usuarios intentaran
usarlo. Esto se logra si los equipos de prueba de sala limpia (tambin llamados equipos de
certificacin) determinan una distribucin de probabilidad de uso para el software. La
especificacin (caja negra) de cada incremento del software se analiza para definir un conjunto
de estmulos (entradas o eventos) que provocan el cambio de comportamiento del software. Con
base en entrevistas con usuarios potenciales, la creacin de escenarios de uso y una
comprensin general del dominio de la aplicacin, se asigna una probabilidad de uso a cada
estmulo.
La certificacin para la ingeniera 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 hipotticamente determinar posibles fallas del

software)
Modelo de certificacin (se refiere a la fiabilidad global del sistema). Proyectado y certificado.
Aplicar la ingeniera 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 lneas 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 presentacin de sus formularios de
entrada e informes de salida, sino que va un poco ms all de lo que alcanzamos a imaginar o
descifrar de estos trminos.
La revisin concreta de cada una de las lneas de cdigo es una parte fundamental dentro de la
ingeniera de sala limpia ya que en muchas ocasiones deseamos realizar una tarea especfica y lo
que se hace es girar muchas veces sobre el mismo proceso para mostrar el mnimo resultado
esperado, es por eso, que se debe tener una lgica bien estructurada para hacer de las cosas
difciles algo fcil para satisfacer las necesidades del cliente y disminuir al mximo las lneas de
cdigo que hacen que el software ocupe mayor espacio.
5.2. Ejercicios tema 1
1. Haga una sntesis con resto a la aplicacin 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. Cul 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. Ingeniera 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 arquitectnico especfico para cierto dominio de
aplicacin.
En el contexto de la ingeniera del software la reutilizacin es una idea tanto antigua como nueva.
Los programadores han reutilizado ideas, abstracciones y procesos desde los primeros das de la
computacin, pero el enfoque original para la reutilizacin era especfico. En la actualidad, los
complejos sistemas de alta calidad basados en computadoras se deben construir en un tiempo muy
corto y demanda un enfoque ms organizado de la reutilizacin.
Esta ingeniera (ISBC) es un proceso que concede particularmente importancia al diseo y la

construccin de sistemas reutilizables. Por lo tanto, alienta el uso de patrones arquitectnicos
predecibles y de infraestructura de software estndar, y por lo tanto conduce a un resultado de
mayor calidad.
La ISBC abarca dos actividades de ingenieras paralelas: La ingeniera de dominio: la cual explora un
dominio de aplicacin con la intencin especfica de encontrar componentes funcionales, de
comportamientos y de datos que sean candidatos para la reutilizacin. Dichos componentes son
colocados en libreras de reutilizacin.
El desarrollo: el desarrollo basado en componentes obtiene requisitos de los clientes; selecciona un

estilo arquitectnico apropiado para satisfacer los objetivos del sistema a construir; y luego:*
Selecciona componentes potenciales para reutilizacin.
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 aplicacin cono un todo. Adems, algunos
componentes personalizados son sometidos a ingeniera 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 ingeniera parece bastante similar a la ingeniera del software orientado a objetos
convencional. El proceso comienza cuando un equipo de software establece requisitos para el
sistema que construir mediante tcnicas convencionales de investigacin de requisitos. Se
establece un diseo arquitectnico, pero en lugar de dirigirse inmediatamente hacia tareas de
diseo ms detalladas, el equipo examina los requisitos para determinar qu subconjunto est
directamente dispuesto para la composicin, y no para la construccin.
Se plantean las siguientes preguntas: Hay componentes comerciales de lnea 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 funcin clara en el contexto de una arquitectura bien definida26.
5.3.2. El proceso ISBC
Se caracteriza de tal forma que no slo identifica los componentes candidatos sino que tambin
cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones
arquitectnicas, ensambla los componentes en un estilo arquitectnico seleccionado y actualiza los
componentes conforme los requisitos del sistema cambian.
El modelo de proceso para la ingeniera de software basada en componentes destaca las pistas
paralelas en las cuales la ingeniera del dominio se lleva a cabo concurrentemente con el desarrollo
basado en componentes. Los pasos de anlisis y diseo arquitectnico definidos en el contexto de
un paradigma de diseo abstracto (ADP) implica que el modelo global del software representado
como datos, funciones y comportamientos (control) , se puede descomponer jerrquicamente.
Conforme la descomposicin comienza, el sistema se representa como una coleccin de marcos de
trabajo arquitectnico, cada uno compuesto de uno o ms patrones de diseo.
Ingeniera de dominio
Esta ingeniera 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 ingeniera 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 aplicacin 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 ingeniera de dominio incluye tres grandes actividades: anlisis, construccin y
diseminacin.
Se puede argumentar que la reutilizacin desaparecer, no por eliminacin, sino por integracin en
la estructura de la prctica de la ingeniera del software. Como la reutilizacin cada vez tiene mayor
auge algunos creen que la ingeniera del dominio adquirir tanta importancia como la ingeniera del
software durante la dcada siguiente.
26
Roger S. Pressman
En el proceso de anlisis lo importante es definir el dominio que se investigar, categorizar los

elementos extrados del dominio , recopilar una muestra representativa de las aplicaciones en el
dominio, analizar cada aplicacin en la muestra y definir las clases de anlisis, por ltimo desarrollar
un modelo de anlisis para las clases.
Es importante advertir que el anlisis del dominio es aplicable a cualquier paradigma de ingeniera
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 ingeniera del dominio. Al aplicar los mtodos
de diseo de anlisis y arquitectnico, el equipo de software refina un estilo arquitectnico
apropiado para el modelo de anlisis creado para la aplicacin que se construir.
Una vez que la arquitectura se ha establecido, deben agregrsele componentes que:
Estn disponibles en bibliotecas de reutilizacin.

Sean diseados 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 estn disponibles para su potencial integracin en la arquitectura
tienen que cualificarse y adaptarse. Cuando se requieren nuevos componentes es preciso
disearlos. Entonces los componentes resultantes se componen (integran) en la plantilla
arquitectnica y se prueban en forma minuciosa.
Adems de valorar si es justificado el costo de adaptacin para la reutilizacin, el equipo de

software tambin evala si lograr la funcionalidad requerida y el desempeo 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
aplicacin. Por esta razn se aplica una sucesin de actividades de desarrollo basada en
componentes cuando se propone el uso de un componente.
Calificacin de componentes.(si realiza la funcin requerida)

Adaptacin de componentes
Composicin de componentes
Modelo de intercambio de datos (se debe definir mecanismos que permitan que los usuarios y
aplicaciones interacten y transfieran datos (arrastrar y soltar, cortar y pegar). Los mecanismos
de intercambio de datos no slo permiten la transferencia de datos humano-software y
componente-componente, sino tambin la transferencia entre recursos del sistema (arrastrar
un archivo a un icono de impresora para imprimirlo)
Automatizacin: implementar varias herramientas, macros y guiones para facilitar la

interaccin entre componentes reutilizables.
Almacenamiento estructurado. Los datos heterogneos (datos grficos, voz, video, texto y
datos numricos) que contiene un documento compuesto, deben estar organizados y ofrecer
acceso como una sola estructura de datos y no como una coleccin 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 segn ordene el usuario final.
Modelo de objeto subyacente. Asegura que los componentes desarrollados en diferentes

lenguajes de programacin y que residen en diferentes plataformas pueden ser interoperables.
Es decir, los objetos deben ser capaces de comunicarse a travs de una red. Esto se logra si el
modelo de objeto define un estndar para la interoperabilidad de los componentes.
Clasificacin y Recuperacin de Componentes

Considrese un gran depsito de componentes. Cientos de miles de componentes de software
reutilizables se hallan en l. Pero cmo encuentra un ingeniero de software el componente que
necesita?
Tendencias actuales que permitirn a los futuros ingenieros de software navegar entre bibliotecas
de reutilizacin.
Descripcin de los componentes reutilizables. El concepto de un componente de software es

una descripcin de lo que hace el componente. La interfaz con el componente est
completamente descrita y la semntica representada dentro del contexto de las
precondiciones y las pos condiciones identificada. El concepto debe comunicar la intencin del
componente.
El contenido de un componente describe cmo se construye el concepto. En esencia, el contenido

es informacin oculta para los usuarios habituales y que slo necesitan conocerla quienes quieran
modificar o probar el componente.
El contexto sita un componente de software reutilizable en su dominio de aplicabilidad. Es decir, al
especificar las caractersticas conceptuales, operativas y de implementacin el contexto permite
que un ingeniero de software encuentre el componente apropiado para satisfacer los requisitos de
la aplicacin.
Para que sean tiles en la prctica, concepto, contenido y contexto se deben traducir en un
esquema de especificacin concreto.
Economa ISBC
La ingeniera del software basada en componentes tiene un atractivo intuitivo. En teora, debe
proporcionar a una organizacin 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 reutilizacin se
verificara como correcto y no contendra defectos. Con cada reutilizacin 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 creacin de planes, modelos, documentos, cdigo 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 difciles de interpretar, parece que la reutilizacin
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 reutilizacin 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
reutilizacin 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 especfico
para una aplicacin.
5.4. Ejercicios tema 2
Ingeniera del software basada en componentes es:
a. La cualificacin de la interfaz de los mismos componentes para su reutilizacin.

b. La utilizacin 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 diseo y construccin de
sistemas reutilizables.
d. La bsqueda de resultados enfocados a software operativos ensamblados con el uso de
componentes de software existente y desarrollado recientemente.
e. La reutilizacin 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 ingeniera 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

reingeniera de procesos de negocios y la ingeniera inversa.
Explique mediante un ejemplo prctico ya sea en desarrollo de software o a nivel

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

La RPN, excede el contorno de las tecnologas de la informacin y de la ingeniera del software. Hace
referencia a la bsqueda e implementacin 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 lgicamente 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 diseo de un nuevo producto, la compra de servicios
y suministros, la contratacin de un nuevo empleado y el pago a proveedores. Cada uno demanda
un conjunto de tareas y tambin 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 diseo, un producto). Adems, los procesos de negocios traspasan las
fronteras de la organizacin. Esto requiere que diferentes grupos de organizaciones participen en
las tareas lgicamente relacionadas que definen el proceso. La RPN se puede aplicar en cualquier
nivel de la jerarqua, pero conforme se ampla su mbito los riesgos asociados con ello crecen
sustancialmente. Por esta razn, la mayora de los esfuerzos de la RPN se enfoca en procesos
individuales o subprocesos.
Negocio: reduccin de costo, reduccin de tiempos, mejora de calidad y desarrollo y fortalecimiento

del personal.
Identificacin del proceso: se identifican los procesos de mayor prioridad y luego se clasifica para
aplicar la actividad de la reingeniera.
Evaluacin del proceso: Se identifican las tareas del proceso, costo y tiempo que consumen las
tareas del proceso.
Especificacin y diseo del proceso: se preparan casos de uso y luego se disea un conjunto de
tareas para el proceso
Elaboracin de prototipos: un proceso de negocio debe ser llevado primero a un prototipo antes de
integrarse por completo.
Refinamiento y particularizacin: Luego de una retroalimentacin del proceso este se refina y luego
se particulariza en un sistema de negocio27.
El objetivo de las herramientas del RPN es apoyar el anlisis y la evaluacin de los procesos de
negociacin existentes y la especificacin y el diseo de unos nuevos.
La mecnica de las herramientas vara. 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. Reingeniera 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 reingeniera del software la han impulsado los
problemas en el mantenimiento del software que han ido creciendo durante ms de 40 aos.
5.5.2.1 Mantenimiento del Software

El mantenimiento del software existente implica casi el 60 por ciento del esfuerzo que emplea una
organizacin de desarrollo, y el porcentaje contina elevndose conforme se produce ms software.
Gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a 15 aos
de antigedad. Aun cuando dichos programas se crearon empleando las mejores tcnicas de diseo
y codificacin conocidas en la poca, se crearon cuando el tamao 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 mquinas y a la tecnologa de los
sistemas operativos aumentaron para satisfacer las necesidades de nuevos usuarios.
Otra razn 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 algn conocimiento directo del sistema heredado.
Cuando se desea aplicar la reingeniera 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 aplicacin de este trmino 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 generara y al
malestar que ocasiona sino se incluye un buen tema de concientizacin para la aceptacin y el
normal funcionamiento de la nueva implementacin.
5.5.2.2 Ingeniera Inversa

Invoca una imagen de ranura mgica. En la ranura se inserta una lista fuente sin documentar y
diseado casualmente, y del otro extremo sale una descripcin (y toda la documentacin) completa
del diseo para el programa de computadora. La ingeniera inversa puede obtener informacin de
diseo a partir del cdigo fuente, pero el grado de abstraccin, (grado de detalle que se ofrece en
un grado de abstraccin) de la documentacin, 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 abstraccin de un proceso de ingeniera inversa y las herramientas utilizadas para

efectuarlo se refieren a la sofisticacin de la informacin del diseo que es posible obtener del
cdigo fuente.
El proceso de ingeniera inversa debe ser capaz de derivar representaciones de diseo de

procedimiento, informacin de estructura de programa y datos (un grado de abstraccin un poco
ms elevado), modelos de objetos, modelo de flujo de datos o control y clases UML, diagramas de
estado y despliegue. Conforme el grado de abstraccin aumenta, el ingeniero de software obtiene
informacin que le permitir comprender con ms facilidad el programa. Se deben abordar 3 temas
de la ingeniera inversa:
Grado de abstraccin.
Integridad
Direccionamiento.
La aplicacin de ingeniera inversa es un tema muy interesante ya que aqu se extrae de lo abstracto
la informacin para convertirla en una aplicacin real aunque es de gran cuidado porque el objetivo
principal de la aplicacin de ella es realizar un programa con gran similitud a otro con respecto a la
informacin que se interpreta incluyendo las mejoras que debe tener para su implementacin.
Una de las cosas fundamentales dentro de la ingeniera inversa es tener claridad en el grado de
abstraccin, la integridad y el direccionamiento porque de esto depende la efectividad en el buen
funcionamiento de la aplicacin resultante, teniendo presente que en algunos casos el software del
cual se va a recolectar la informacin 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 informacin para analizar completamente el buen
funcionamiento de este mediante lo informes entregados y verificados.
Reestructuracin
Aunque la reestructuracin del cdigo puede aliviar inmediatamente los problemas asociados con la
depuracin o los cambios pequeos, esto no es reingeniera, el beneficio real se logra slo cuando
se reestructuran los datos y la arquitectura. La reestructuracin modifica el cdigo fuente o los
datos con la finalidad de adecuarlos para futuros cambios. En general, la reestructuracin no
modifica la arquitectura global del programa.
Tiende a tocarse sobre los detalles de diseo de los mdulos individuales y en las estructuras de
datos locales definidos dentro de los mdulos.
La reestructuracin ocurre cuando la arquitectura bsica de una aplicacin es slida, aun cuando el
interior tcnico necesite trabajarse. Se inicia cuando grandes partes del software son funcionales y
slo un subconjunto de los componentes y datos necesitan una modificacin extensa.
Reestructuracin del cdigo. (Diseo que produzca la misma funcin que el programa original)
Reestructuracin de los datos. (se debe primero analizar el cdigo fuente para poderlo
redisear.)
El objetivo de las herramientas de reestructuracin es transformar el antiguo software de

computadora carente de estructura en lenguajes de programacin y estructuras de diseo
modernos.
En general, el cdigo fuente se ingresa y transforma en un mejor programa estructurado. En algunos

casos, la transformacin ocurre dentro del mismo lenguaje de programacin. Un lenguaje de
programacin antiguo se transforma en un lenguaje ms moderno.
Ingeniera Directa
Qu opciones existen cuando se enfrenta un programa deficiente diseado e implementado?
La reingeniera es muy parecida a la limpieza dental. Puede pensar en miles de razones para
demorarla, y la aplazar muchas veces. Pero eventualmente sus tcticas dilatorias regresarn para
provocarle dolor. En la mayora de los casos, la ingeniera directa no simplemente crea el
equivalente moderno de un programa antiguo.
Ms bien, los nuevos requisitos de usuario y tecnologa se integran en el trabajo de reingeniera.

Ingeniera del software pag.918)
En algunos casos, la migracin hacia la arquitectura cliente servidor no debe enfocarse como
reingeniera, sino como un nuevo esfuerzo de desarrollo. La reingeniera ingresa al cuadro slo
cuando la funcionalidad especfica del sistema antiguo se integrar en la nueva
arquitectura.Ingeniera directa para arquitecturas orientadas a objetos.
La Economa de la reingeniera
En un mundo perfecto, cualquier programa al que no se le pudiera dar mantenimiento sera retirado
inmediatamente, y sera sustituido por aplicaciones de mayor calidad con reingeniera desarrollada
empleando modernas prcticas de ingeniera del software. Sin embargo, se vive en un mundo de
recursos limitados.
La reingeniera demanda recursos que pueden utilizarse para otros propsitos del negocio. En
consecuencia, antes de que una organizacin intente someter a reingeniera una aplicacin
existente, debe realizar un anlisis costo beneficio.
El anlisis costo beneficio representado en las ecuaciones se puede realizar para todas las
aplicaciones de alta prioridad identificadas durante el anlisis de inventario.
Que es la reingeniera y en donde se puede aplicar

Cul es el objetivo de las herramientas del reingeniera de procesos de negocio
Porque se dice que el mantenimiento de software Implica casi el 60 por ciento del esfuerzo
que emplea una organizacin?
Cree usted que la ingeniera inversa es ms factible llevarla a cabo que la construccin de un
software haciendo todo el proceso completo? Justifique
Prueba Final
1. La ingeniera del software de sala limpia destaca:
a. El costo y tiempo de fabricacin de un producto.

b. Los diferentes incrementos en la construccin del producto.
c. La fabricacin 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 ingeniera de software de sala limpia son:
a. Planificacin del incremento, certificacin y verificacin de la correccin.

b. Recopilacin de requisitos y diseo formal.
c. Especificacin de la estructura de cajas y planificacin de pruebas estadsticas.
d. Generacin de cdigo, inspeccin y verificacin.
3. La ingeniera de software basada en componentes integra los componentes para:
a. Desarrollar la interfaz de usuario.

b. Formar subsistemas y la aplicacin como un todo.
c. Implementar los requisitos.
d. Investigacin de requisitos.
4. La finalidad de la ingeniera 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 aplicacin
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 aplicacin
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 aplicacin 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 aplicacin particular.
5. La reingeniera se puede aplicar a:
a. Software
b. Hardware
c. Personal
d. Todos los anteriores
6. Qu implicaciones positivas o negativas tiene la utilizacin de la ingeniera inversa
6. PISTAS DE APRENDIZAJE
Tener en cuenta: Que la crisis del software siempre se ha presentado a travs 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 categoras 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 comunicacin, planeacin, modelado, construccin y despliegue.
Tenga presente: Que la base fundamental para un buen desarrollo est en una excelente
comunicacin.
Tener en cuenta: Que el lenguaje unificado de modelamiento (UML), solo es una forma de
disear o dibujar la manera como fluir la informacin.
Traer a memoria: Que la ingeniera del software de sala limpia ayuda a eliminar los diversos
procedimientos y cdigos innecesarios.
Traer a memoria: Que aplicar la reingeniera no es cuestin 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 ingeniera inversa en un determinado software es un proceso

largo y tedioso y que requiere de gran habilidad y destreza para su implementacin, 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 Numrico

Electrnico).
SWEBOK: Software Engineering Body of Knowledge (Cuerpo de la ingeniera del software.
ISO: Organizacin Internacional de Estandarizacin
QFD: Despliegue de funcin de calidad
CMM: Modelo de capacidad madurez.
CMMI: Integracin de Modelos de Madurez de Capacidades.
UML: Lenguaje Unificado de Modelamiento
RPN: Reingeniera de Procesos de Negocio
8. BIBLIOGRAFA
Ph.D Roger S. Pressman, University of Connecticut, Ingeniera del Software un Enfoque Prctico,
sexta edicin, Mc Graw Hill, 2002, 2005
Alfredo Weitzenfeld, Sur de California (Estados Unidos). Ingeniera del Software Orientado a Objetos
con UML, J

02-Ingenieria Del Software I

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02-Ingenieria Del Software I

Uploaded by

Copyright:

Available Formats

ESCUELA DE CIENCIAS BSICA E INGENIERA

ASIGNATURA: Ingeniera del Software I

CORPORACIN UNIVERSITARIA REMINGTON

Yolfaris Naidit Fuertes Arroyo

1. MAPA DE LA ASIGNATURA ............................................................................................... 8

4.1.1. Orientacin a objetos.......................................................................................................... 67

PROPSITO GENERAL DEL MDULO

UNIDAD 1 UNIDAD 2 UNIDAD 3 UNIDAD 4

2. CONTEXTUALIZACIN DE LA INGENIERA DEL SOFTWARE

En los siguientes enunciados seleccione la respuesta correcta

a. La parte tangible del computador.

a. Es la aproximacin sistemtica, disciplinada y cuantificable para desarrollar, operar y

4. Un marco de trabajo es:

a. Un conjunto de componentes tangibles.

5. La subdivisin que tiene un ciclo de mejora de un proceso es:

a. Planear, ejecutar, medicin y mejora

a. El producto que los diseadores de software construyen.

2.1. Ingeniera del software

2.1.1. Introduccin a la ingeniera del software

2.1.1.1 Definicin Hardware

2.1.1.2 Definicin Software

a. Sistema Operativo: el cual controla el funcionamiento del computador y de todos los

Desarrollo del Hardware

La crisis del Software

Por qu lleva tanto tiempo terminar los programas?

Por qu es tan difcil constatar el progreso durante el desarrollo?

2.1.2. Estndares y modelos

Principales organizaciones de estandarizacin

ISO: Organizacin Internacional para la Estandarizacin.

Los estndares ms importantes para la ISO son.

SEI: Instituto de Ingeniera del software.

2.1.3. Proyecto SWEBOK

El proyecto parte de la suposicin de que es necesario establecer cul es el cuerpo de conocimiento

Ciclo de vida del software

La ISO 12207 Define el QU, no el CMO6.

Para la adquisicin de sistemas y servicios de software.

El estndar no cubre el desarrollo de productos de software para distribucin comercial masiva

Grfico #1 (Elaborado por los Autores)

Grfico #2(Elaborado por los Autores)

Programacin actividades o tareas.

Grfico#3 (Elaborado por los Autores)

Ciclo de mejora del producto

Es un conjunto de elementos que interactan entre s para alcanzar un objetivo especfico.

Ingeniera de sistemas comprende la Gestin de proyectos, funcin de planificar, supervisar y

Funciones de la Ingeniera de sistemas

Definicin del problema: Determinacin de las expectativas hacia el producto, necesidades y

Evaluacin del producto: Determinar la calidad y cantidad de los productos elaborados, a

Grfico #4 (Elaborado por los autores)

Ingeniera de sistemas Gestin de proyectos Ingeniera del Software

2.3. Ejercicio Tema 1

Qu hara usted para reducir el deterioro del software?

Cules son las principales organizaciones de estandarizacin?

2.4. Ingeniera de sistemas

2.4.1. Ingeniera de software

En la actualidad, el software es considerado el producto ms importante dentro del campo

2.4.1.1 Software e Ingeniera del Software

El software tambin ha permitido la creacin de tecnologas nuevas como la ingeniera gentica, ha

En la sociedad moderna el papel de la ingeniera es proporcionar sistemas y productos que

El papel evolutivo del software

La Naturaleza cambiante del software

Software cientfico y de ingeniera:

Software incrustado o empotrado:

Software de lnea de productos:

Aplicacin basada en Web: