Ingeniería Software

De Computacion

Cuando el software de computadora triunfa, - cuando se satisface las necesidades de la gente que lo utiliza, cuando se diseño, cuando se desempeña sin fallas durante un largo periodo, cuando es fácil de modificar e incluso más fácil de usar cambia las cosas para mejorar. Pero cuando el software falla – cuando sus usuarios no están satisfechos, cuando es proclive un error, cuando es difícil de cambiar e incluso difícil de usar – ocurren cosas malas. Todos queremos construir software que haga las cosas mejor, y evitar las cosas malas que asechan en las sombras de los esfuerzos fallidos. Para tener éxito es necesaria la disciplina cuando se diseña y construye el software. Es necesario también un enfoque de ingeniería. La ingeniería del software ha evolucionado: desde una idea oscura practicada por un número de relativamente pequeño de fanáticos hasta una disciplina de ingeniería legítima. En la actualidad se reconoce como una materia valiosa para la investigación seria el estudio consciente y el animado debate. En la industria el ingeniero de software ha sustituido al programador como el titular laboral de preferencia. Los modelos de proceso, los métodos de ingeniería y las herramientas de software se ha adoptado exitosamente a lo largo de un amplio espectro de aplicaciones industriales. Aunque los gestores y los profesionales reconocen por igual la necesidad de un enfoque más disciplinado del software, continúan debatiendo la forma en que se aplicará la disciplina. Muchos individuos y compañías todavía desarrollan software de manera aleatoria, aun cuando construyan sistemas para atender las tecnologías más avanzadas de la actualidad. Muchos profesionales y estudiantes no están concientes de los métodos modernos y, como resultado, resulta afectada la calidad del software que producimos, con lo cual las cosas malas suceden. Además, continúa el debate y la controversia acerca de la verdadera naturaleza del enfoque de la ingeniería del software. El estado de esta disciplina es un estudio de contrastes. Las actitudes han cambiado, el progreso se ha materializado, pero todavía falta mucho por hacer antes de que la disciplina alcance la madurez.

[editar] Objetivo General

Dotar al estudiante del marco conceptual y las técnicas necesarias que permitan manejar la gestión de proyectos y los temas avanzados de la ingeniería de software.

[editar] Objetivos Especificos

Conocer como se debe gestionar el personal, el proceso y los problemas durante un proyecto de software.
Conocer como pueden emplearse las métricas de software para gestionar el proceso de software y el respectivo proceso
Conocer y aplicar las técnicas que pueden aplicarse para evaluar formalmente los riesgos que pueden incidir en el éxito del proyecto.
Conocer como se gestionan los cambios durante el desarrollo de software y durante la entrega al cliente.
Conocer y aplicar las notaciones y preliminares matemáticos que se requieren para especificar formalmente el software.
Conocer las actividades clave que se llevan a cabo durante el proceso para crear sistemas de ingeniería de sala limpia.
Conocer como se emplea la ingeniería del software basada en componentes para crear sistemas a partir de componentes reutilizables.
Conocer que actividades técnicas se requieren para la reingeniería del software.

[editar] Bibliografia

Texto Base

Pressman Roger., Ingeniería de Software un Enfoque Práctico. 6ta edición. McGraw-Hill México. ISBN 970-10-5473-3. 2005.

Bibliografía complementaria

Mc Connell Steve, Desarrollo y gestión de Proyectos Informáticos Ed. McGraw-Hill. 1998 ISBN: 8448112296.
Fundamentos d la Dirección de Proyectos PMI, Project Management Institute, Inc, Newtown Square, Pennsylvania EEUU, ISBN 1-930699-45-X 2004
Grompone Juan, Gestión de Proyectos de Software. 1era. Edición, Editorial La Flor de Itapbi Montevideo Uruguay ISBN 9974-592-05-4 1996.
Linger Richard C, Cleanroom Software Engineering Reference Model Version 1.0 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 1996.

[editar] Desarrollo del Aprendizaje

[editar] Capitulo 1: CONCEPTOS DE GESTIÓN DE PROYECTOS

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	21. Conceptos de Gestión de Proyectos
Páginas	640 – 661
Horas de estudio empleadas para el desarrollo del contenido	3 horas

[editar] Propositos

Este capitulo se consideran conceptos claves que conducen a la gestión efectiva de proyectos de software. La gestión de proyectos de software involucra la planificación supervisión y control del personal, el proceso y los eventos que ocurren mientras el software evoluciona desde un concepto preliminar hasta una implementación operativa

[editar] Conceptos Clave

Gestión de proyectos: Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La gestión de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre.

Ámbito del software: La primera actividad de gestión dentro de un proyecto de software es la determinación del ámbito (alcance) del software el que no debe ser ambiguo ni incomprensible a nivel de gestión y técnico. Se debe acotar un enunciado del ámbito del software: establecer de manera explicita los datos cuantitativos (número de usuarios simultáneos, tiempos de respuesta máximo etc.), y describir los factores que reducen los riesgos (los algoritmos se comprenden bien y están disponibles en C++)

Descomposición del problema:A veces llamada partición o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos, Durante la fijación del ámbito no se realiza intento alguno por descomponer completamente el problema. Más bien, la descomposición se aplica en dos grandes áreas: 1) la funcionalidad que debe entregarse, 2) el proceso que se empleará para entregarla.

Equipo de software: La mejor estructura del equipo depende del estilo de gestión de cada organización, del número de personas que integrarán el equipo y de sus grados de habilidad, así como de la dificultad global del problema

Equipos ágiles: La filosofía ágil alienta la satisfacción del cliente y la temprana entrega incremental de software; pequeños equipos de trabajo enormemente motivados; métodos informales; mínimos productos de trabajo de ingeniería de software; y simplicidad global de desarrollo. Los equipos ágiles adoptan características de los equipos de proyecto exitosos, y evitan muchas de las toxinas que crean problemas. Sin embargo, el enfoque ágil subraya la competencia individual (miembros del equipo) en conjunción con la colaboración del grupo como factores de éxito cruciales para el equipo.

Lideres de equipos: La gestión del proyecto es una actividad intensamente humana; por tanto, los profesionales competentes con frecuencia no son buenos líderes de equipo. Simplemente no tienen la mezcla correcta de habilidades con el personal.

Modelo de liderazgo:

Motivación
Organización
Ideas o innovación
Resolución de problemas
Dotes de gestión
Incentivos
Influencia y fomento de la cultura de equipo

Participantes: Para ser eficaz, el equipo de proyecto debe estar organizado en una forma que maximice las capacidades y habilidades de cada persona.

Taxonomía:

Gestores ejecutivos
Gestores
Profesionales
Clientes
Usuarios finales

Proceso: El proceso de desarrollo de software “es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo”. Concretamente “define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo” [Jacobson 98].

[editar] Esquema de Estudio

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
21.1 El espectro de la gestión	Se describe el enfoque principal de la gestión de proyectos de software basado en las cuatro P: personal, producto, proceso y proyecto.	Defina dada uno de los enfoques de la gestión de proyectos y establezca como se interrelacionan.
21.2.Personal	Se describe la importancia del personal en un proyecto de software. El personal debe estar organizado en equipos eficientes, motivados para hacer un trabajo de software de alta calidad y coordinados para lograr una comunicación eficaz	Razone la importancia de contar con personal altamente capacitado para el desarrollo de un proyecto de software. Haga anotaciones de las principales características que a su criterio debe cumplir el personal de software. Indique cuales son a su criterio las principales características que debe cumplir un líder de equipo Analice el ensayo HOGAR SEGURO de la Pág. 651, comente acerca de la conversación de los actores
21.3 Producto	Permite examinar el producto y el problema que se intenta resolver desde el inicio del proyecto, es decir establecer y acotar ámbito del producto esto es: se establecen de manera explícita los datos cuantitativos, las restricciones o limitaciones y los factores de reducen los riesgos.	Defina el ámbito del problema para una pequeña aplicación de inventarios de un hospital donde se deben registrar ingresos y egresos, caducidad de medicinas.
21.4 Proceso	Describe cómo seleccionar un marco de trabajo común mediante la aplicación de un paradigma de ingeniería de software adecuado y la elección de un conjunto de tareas para llevar a cabo el trabajo.	Consultar modelos de procesos de referencia, tradicionales (MSF – RUP), ágiles (XP – AUP), realizar observaciones a cada uno de ellos y encontrar puntos coincidentes.
21.5 Proyecto	Describe un enfoque de sentido común para la efectiva gestión de proyectos y evitar algunos problemas planteados.	Realice tablas resumen de los principales problemas (además de los indicados en libro), los que usted considera perjudicarían la gestión de un proyectos de software.
21.6 El principio W5HH	Permite abordar los objetivos del proyecto, los hitos, y planificación, responsabilidades, gestión y enfoques técnicos y recursos requeridos.	Analice detalladamente cada una de las preguntas planteadas por el principio para la definición de características claves del proyecto.

[editar] Capitulo 2 : CONCEPTOS DE GESTIÓN DE PROYECTOS

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	22 Métricas del Proceso de Proceso y Proyecto
Páginas	663 – 685
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

Este capitulo le permitirá al estudiante, a través de la medición, obtener una visón de la eficacia del proceso de software y los proyectos que se llevan a cabo utilizando el proceso como marco de trabajo. La medición permitirá destacar las tendencias (ya sean buenas o malas) y hacer mejores estimaciones y como también marcar las áreas problema de modo que se puedan desarrollar remedios y mejorar el proceso de software.

[editar] Conceptos Clave

EED: Métrica de calidad (eficacia en la eliminación de defectos - EFD) que ofrece servicios tanto en el ámbito del proyecto como en el del proceso. Permite filtrar las actividades de garantía de calidad y de control conforme se aplica a través de todas las actividades del marco de trabajo del proceso.

Indicador: Es una métrica o combinación de métricas que proporcionan una visión del proceso, del proyecto o del software en sí, y poder hacer ajustes para que las cosas mejoren.

Medición: Proporciona una indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto. Pueden ser directas, por ejemplo: número de líneas de código, número de errores encontrados, etc., o pueden ser indirectas, por ejemplo: funcionalidad, calidad, complejidad, etc.

Medida: Acto de determinar una medida

Medidas de calidad: Las métricas de calidad se asocian a unos determinados atributos medibles, no siempre evidentes, para reconocer la presencia o ausencia de calidad.

Medidas de productividad: Las métricas de productividad recogen la eficiencia del proceso de producción de software y relacionan el software que se ha construido con el esfuerzo que ha costado elaborarlo.

MEPS: Conforme una organización se siente más cómoda con la recopilación y el empleo de métricas del proceso, la deducción de indicadores simples da la pauta para un enfoque más riguroso llamado mejora estadística del proceso de software (MEPS). Aplica el análisis de falla de software para recopilar información acerca de todos los errores y defectos que se encuentran al desarrollar y utilizar una aplicación, sistema o producto.

Métrica: Es una medida cuantitativa del grado en que un sistema o proceso posee un atributo dado. Por lo general relaciona una o más medidas, por ejemplo: número de errores encontrados por cada mil líneas de código.

METRICAS DEL SOFTWARE

Métricas técnicas	Se centran en las características del software por ejemplo: la complejidad lógica, el grado de modularidad.
Métricas de calidad	Proporcionan un indicador de cómo se ajusta el software a los requisitos implícitos e explícitos del cliente.
Métricas de productividad	Se centran en el rendimiento del proceso de la Ingeniería de Software.
Métricas orientadas a la persona	Proporcionan información sobre la forma en que la gente desarrolla el software, desde la perspectiva de la efectividad de las herramientas y métodos.
Métricas orientadas al tamaño	Son medidas directas al software y el proceso por el cual se desarrolla.
Métricas orientadas a la función	Son medidas indirectas del software y del proceso por el cual se desarrolla. Estas medidas se centran en la funcionalidad o utilidad del software.

Métricas de casos de uso: El caso de uso se define en etapas tempranas del proceso de software, lo que permite emplearlo en la estimación antes de iniciar las actividades significativas de modelado y construcción

Métricas de proyecto: Las métricas del proceso se recopilan en el curso de todos los proyectos y durante largos periodos. Proporcionan un conjunto de indicadores de proceso que conduzcan a al mejora de los procesos de largo plazo.

La única forma de racional de mejorar cualquier proceso es medir sus atributos específicos, desarrollar un conjunto de métricas significativas con base en dichos atributos y luego emplear las métricas para ofrecer indicadores que conducirán a una estrategia de mejora

Métricas de proceso: A diferencia de las métricas del proceso de software que se utilizan con propósitos estratégicos, las métricas del proyecto son tácticas. Es decir, un gerente de proyecto y un equipo de software emplean las métricas del proyecto y los indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las actividades técnicas.

La primera aplicación de las métricas del proyecto en la mayoría de proyectos de software ocurre durante la estimación.

Métricas orientadas a la función: Se usa de manera efectiva como medio para medir la funcionalidad que entrega un sistema. Emplea datos históricos, se usa para: 1) estimar el costo o el esfuerzo requerido para diseñar, codificar y probar el software; 2) predecir el número de errores que se encontrarán durante la prueba; 3) pronosticar el número de componentes, de las líneas de código proyectadas, o ambas en el sistema implementado.

La medida de punto de función se propuso en 1979 y trata de medir la funcionalidad o utilidad del software.

Cálculo del punto de función1

1. Hay que completar la siguiente tabla de valores del dominio de la información:

Puntos de Función

Basados en una combinación de características del programa: Entradas y salidas externas; interacciones de usuario; interfaces externas; ficheros usados por el sistema. Se asocia un peso con cada uno de ellos. Los puntos de función se calculan multiplicando cada factor por su peso y sumando todos ellos.

Donde:

Entradas de usuario. Son entradas que proporcionan diferentes datos a la aplicación. No confundirlos con las peticiones de usuario.
Salidas de usuario. Son reportes, pantallas o mensajes de error que proporcionan información. Los elementos de un reporte, no se cuentan de forma separada.
Peticiones de usuario. Es una entrada interactiva que produce la generación de alguna respuesta del software en forma de salida interactiva.
Archivos. Son los archivos que pueden ser parte de una base de datos o independientes.
Interfaces externas. Son los archivos que se usan para transmitir información a otro sistema.

Indicaciones:

Contar cada medida por separado.

Asociar, de alguna manera, un valor de complejidad a cada medida. La siguiente tabla muestra una heurística para decidir la complejidad de todo el sistema.

Para cada medida, multiplicar su cuenta por el factor de complejidad elegido y escribirlo en la columna de la extrema derecha.
Sumar la columna de la extrema derecha y obtener un total T que indica el valor del dominio de la información.

2. Responder a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial.

1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?

2. ¿Requiere comunicación de datos?

3. ¿Existen funciones de procesamiento distribuido?

4. ¿Es crítico el rendimiento?

5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?

6. ¿Requiere entrada de datos interactiva?

7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?

8. ¿Se actualizan los archivos maestros de forma interactiva?

9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?

10. ¿Es complejo el procesamiento interno?

11. ¿Se ha diseñado el código para ser reutilizable?

12. ¿Están incluidas en el diseño la conversión y la instalación?

13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?

14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

Sumar los puntos asignados a cada respuesta y obtener un total F que indica un valor de ajuste de complejidad.

3. El punto de función FP se calcula con la siguiente ecuación:

PF = T * (0.65 + 0.01 * F).

Métricas orientadas a objetos Las métricas de proyectos de software convencionales (LCD o PF) se aplican en la estimación de proyectos de software orientados a objetos. Sin embargo estas métricas no proporcional el suficiente grado de granularidad para la planificación y los ajustes de esfuerzo que se requieren conforme se itera a lo largo de un proceso evolutivo o incremental. Se sugiere el siguiente conjunto de métricas para proyectos de OO:

Número de guiones de escenario
Número de clases clave
Número de clases de apoyo
Número promedio de clases de apoyo por clase clave.
Número de subsistemas.

Métricas orientadas al tamaño: Preceden de la normalización de las medidas de calidad o productividad considerando el tamaño de software que se ha producido. El desarrollo de métricas que se asimilen con métricas similares precedentes de otros proyectos requiere elegir líneas de código (LDC) como valor de normalización

Medidas:

Líneas de código (LDC).
Esfuerzo en hombre-mes.
Costo en dólares.
Número de páginas de documentación.
Número de errores. Fallas detectadas antes de entregar el software al cliente.
Número de defectos. Fallas detectadas después de entregar el software al cliente.
Número de personas en el proyecto.

Métricas

Errores por KLDC (mil líneas de código).
Defectos por KLDC.
Costo por KLDC.
Páginas de documentación por KLDC.
Errores por hombre-mes.
LDC por hombre-mes.
Costo por página de documentación.

Ventajas

Son fáciles de calcular.
Muchos modelos de estimación de software usan LOC o KLOC como datos de entrada.
Existen un amplio conjunto de datos y literatura basados en LOC.

Desventajas

Son dependientes del lenguaje de programación.
Perjudica a los programas cortos pero bien diseñados.

Su uso en estimación es difícil porque hay que estimar las LOC a producirse mucho antes de que se complete el análisis y el diseño.

2¿Qué es una línea de código?

Es una medida propuesta inicialmente cuando los programas se escribían en tarjetas, con una línea por tarjeta. actualmente los lenguajes permiten escribir varias sentencias en una línea, o una misma sentencia en varias líneas. Se debe decidir qué programas deberían contarse como parte del sistema. Asumen una relación lineal entre el tamaño y el volumen de documentación

[editar] Esquema de estudio

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
22.1 Métricas en los dominios del proceso y el proyecto	Permite definir, como una organización puede adoptar una visión estratégica al proporcionar información de la eficacia de un proceso de software. Además, en este capitulo se analiza las principales determinantes de calidad del software y la eficacia organizacional	Revisar puntos 22.1.1, interesa que se adquiera un conocimiento general del tema. Realice un análisis desde su perspectiva de las determinantes para la calidad del software y la eficacia organizacional, tome como base la figura 22.1 Revisar puntos 22.1.2, interesa que se adquiera un conocimiento general del tema. Analice el ensayo HOGAR SEGURO de la página 668 comente acerca de los puntos tratados por los actores.
22.2 Medición del Software	Describe las principales categorías para efectuar la medición del software.	Analice cada una de las métricas del software, realice un cuadro comparativo que permita establecer sus principales características, coincidencias y diferencias. Revisar el punto 15.2, interesa que se adquiera un conocimiento general del tema. Revisar el punto 15.3. interesa que adquiera conocimiento general acerca de las métricas del modelo de análisis. Analice el ensayo HOGAR SEGURO de la Pág.: 473 comente acerca de los puntos tratados por los actores. Investigue cada una de las herramientas para la medición de software que se presentan en la página 676.
22.3 Métricas para la calidad del software	Permite determinar la calidad del software a través de la medición de errores y defectos, lo que proporciona un indicio de la efectividad de la garantía de la calidad del software.	Analice cada una de las métricas de calidad propuestas en la Pág.: 677 – 678 e indique cual usted considera de mayor importancia al momento de medir la calidad del software. Analice el ensayo HOGAR SEGURO de la página 679 comente acerca de los puntos tratados por los actores.
22.4 Integración de las métricas dentro del procesos de software	Describe el enfoque para instituir un programa de de recopilación de métricas en una organización a partir de una línea base de métricas para la calidad.	Defina un programa de métricas para una organización, para esto fundamente con los puntos 22.5 y 22.6. Analice el programa de métricas descrito en la Pág.: 685 y realice un análisis comparativo con el que desarrollo en el punto anterior.

[editar] Capitulo 3:ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	23 Estimación para proyectos de software
Páginas	691 – 717
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

Este capitulo plantea la necesidad de utilización de metodologías tradicionales para la estimación de proyectos software en donde se ha resuelto correctamente la necesidad de conocer la duración de un proyecto como una variable dependiente de los recursos a emplear. Se propone la combinación de las técnicas de Puntos de Función y COCOMO para establecer una estimación dependiente de un conjunto de variables consideradas en un proyecto para establecer una estimación mas precisa del mismo.

[editar] Conceptos Clave

Ambito: Describe las funciones y características que se entregarán a los usuarios finales, los datos que sin de entrada y salida, el “contenido” que se presenta a los usuarios como consecuencia de emplear el software, así como el desempeño, las restricciones, las interfases y la confiabilidad que acotan el sistema.

COCOMO: El método COCOMO permite determinar los valores de las siguientes dos variables:

Meses/hombre a aplicar al proyecto

* Meses totales del proyecto (dependiendo de factores tales como los atributos de fiabilidad requerida del software, tamaño de la base de datos, complejidad del producto, limitaciones en el tiempo de ejecución, limitaciones de memoria principal, volatilidad de la máquina virtual, frecuencia de cambio en el modelo de explotación del ordenador, capacitación de los analistas, experiencia en aplicaciones, capacitación de los programadores, experiencia en la máquina virtual, experiencia en el lenguaje de programación, prácticas modernas de programación, uso de herramientas para el desarrollo del software y limitaciones en la planificación).

En la figura se presenta un esquema de estimación que proporciona además de las horas hombre a emplear el tiempo total del proyecto (basándose para ello en el conocimiento previo de la cantidad de sentencias de código del proyecto) lo que permite determinar el plazo de entrega. Mostrándose, además, como a partir de estos dos valores (horas hombre y tiempo total) y simplemente por el cociente de ambos se obtiene la cantidad de recursos (personas) para llevarlo a cabo. A partir de allí se puede elaborar el costo mediante la aplicación de ratios, de igual forma que en las metodologías tradicionales.

Complejidad: La construcción de software puede involucrar elementos de gran complejidad, que en muchos de los casos no son tan evidentes como los que se pueden ver en otras ingenierías. Un puente, un edificio, una mina, una red de ferrocarriles son ejemplos de sistemas complejos de otras ingenierías, pero el ingeniero de software construye sistemas cuya complejidad puede parecer que permanece oculta. El usuario siempre supone que en informática todo es fácil (“apretar un botón y ya está)

Estimación basada en LCD: La medida más utilizada para determinar el tamaño de un proyecto informático ha sido, durante mucho tiempo, la de las líneas de código del software final obtenido. A menudo, en la literatura especializada se utilizan diversas denominaciones según las interpretaciones de cada uno respecto de la definición de éstas.

A continuación presentamos algunas de éstas:

a) LDC: líneas de código. Es la más habitual y antigua.

b) KLDC: miles de líneas de código. Es la unidad de medida que adoptan la mayoría de modelos clásicos de estimación de costes en la calificación de un proyecto informático.

c) DSI: instrucciones de código fuente realmente entregadas, y su múltiplo KDSI, que surgieron para que se tuviera en cuenta que, en los nuevos entornos de desarrollo y construcción de software, buena parte de las líneas de código no siempre las ha escrito el equipo del proyecto, sino que las han generado las herramientas de productividad del entorno de programación.

d) NCSS: líneas de código fuente sin tener en cuenta los comentarios, y su múltiplo KNCSS, por el hecho de considerar que en un buen proceso de construcción los programas incluyen líneas de comentario o que una línea de tratamiento se puede escribir en diferentes líneas de código para aumentar la legibilidad y mejorar la mantenibilidad del software.

e) NSLDC: nuevas líneas de código fuente, tal como se realiza en el modelo COCOMO 2 para que se tenga en cuenta que sólo deben contarse las líneas de código nuevas sin contar las que incorpore automáticamente el entorno de programación, o, lo más importante en este caso, el hecho de que parte del código final puede proceder de la reutilización de rutinas u objetos ya disponibles que no se han de volver a escribir, pero que se incorporan al proyecto informático en curso.

Las diferentes denominaciones de la medida de las líneas de código: Las diferentes denominaciones que existen cuando se habla de las líneas de código recogen el hecho de que tenemos bastantes dificultades y dudas a la hora de medirlas. Éstos son algunos de los planteamientos que hacen difícil la valoración:

¿Debemos contar o no las líneas de comentario?
¿Qué ocurre cuando una única instrucción se escribe, por legibilidad, en dos o más líneas de código fuente?

* ¿Se deben tener en cuenta las líneas que haya generado automáticamente el entorno de programación (gestor de formularios de pantalla, gestor de acceso a la base de datos, etc.)?

¿Se deben tener en cuenta las líneas de código de rutinas o los objetos reutilizados procedentes de otras aplicaciones?
¿Es la medida basada en las líneas de código indiferente al lenguaje de programación utilizado?
¿Qué pasa con las ratios de productividad establecidas cuando cambian los lenguajes de programación utilizados?

Estimación basada en PF: Existen diferentes modelos de estimación de las cargas de un proyecto informático. La mayoría utilizan como medida de las primitivas de salida las líneas de código en cualquiera de las versiones posibles. Otra alternativa, cada día más utilizada, es la medida de los puntos de función que definió Albrecht en un primer artículo del año 1979 y que fue revisado (y relacionado también con la métrica de las líneas de código) en el año 1983 por el mismo Albrecht, ayudado por Gaffney.

El recuento de los puntos de función, deja algunos aspectos a la interpretación de quien lleva a cabo la medida y ello ha generado diferentes artículos y trabajos que, manteniendo la idea central de Albrecht, intentan ayudar a adaptar el recuento de puntos de función a la realidad cambiando la informática de gestión: bases de datos relacionales, nuevos lenguajes y entornos de programación, nuevas herramientas de programación visual, orientación a objetos, etc.

Desde el año 1984, el denominado grupo internacional de usuarios de los puntos de función, IFPUG (de la denominación inglesa International Function Points User Group) publica periódicamente la manera correcta de evaluar los diferentes aspectos discrecionales del recuento de puntos de función de Albrecht. La versión 3.0, fechada en el año 1990, y la 4.0, que es de 1994, son las más utilizadas hoy y la diversa literatura técnica actual sobre puntos de función hace referencia a ellas a menudo.

Actualmente, la mayoría de especialistas estarían de acuerdo en afirmar que la métrica de los puntos de función es la más utilizada. El trabajo del IFPUG la pone en cierta manera al día, mientras que las métricas basadas en las líneas de código no siempre se han adaptado bien a los nuevos lenguajes de programación o a las herramientas RAD.

A pesar de todo, continúa vivo el problema de que la métrica fue pensada durante los años setenta, cuando la informática era bastante diferente de lo que es hoy en lenguajes, tipo de aplicaciones, importancia de las bases de datos, en el papel decisivo de las comunicaciones y de la distribución de sistemas, etc.

EL IFPUG ha decidido mantener inalterada la estructura de la métrica, lo que no facilita su utilización actual. En concreto, el :

IFPUG recomienda, siguiendo las directrices que establece, construir procedimientos normalizados y uniformes en cada instalación para proceder al recuento de los puntos de función siempre de una misma manera homogénea.

Estimación basada en el proceso: La técnica más común para estimar un proyecto es basar la estimación en el proceso que se empleará. Esto es, el proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo para lograr cada tarea.

Estimación basada en casos de uso: Los casos de uso permiten que un equipo de software comprenda el ámbito del software y los requisitos. Si embargo desarrollar un enfoque de estimación con casos de uso es problemático. Por esta razón antes que los casos de uso se emplean en la estimación, se establece el nivel de estructura jerárquica, se determina la longitud promedio (en páginas) de cada caso de uso, se define el tipo de software (tiempo real, de negocios, de ingeniería, científico, anidado) y se considera una arquitectura común del sistema.

Planificación del proyecto: El objetivo de la planificación del proyecto es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Además, las estimaciones deben definir los escenarios de mejor y peor caso de modo que los resultados del proyecto se puedan acotar.

Recursos: La segunda tarea en la planificación es la estimación de los recursos necesarios para completar el esfuerzo de desarrollo del software. Las tres grandes categorías de los recursos en de ingeniería: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software).

[editar] Esquema de estudio

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
23.1 Observaciones acerca de la estimación	Describe una panorámica acerca del proceso de estimación de proyectos de software.	Revisar puntos 23.2, 23.3, y 23.4 interesa que se adquiera un conocimiento general del tema. Realice un cuadro en donde se reúnan las principales características de los recursos utilizados para completar el esfuerzo de desarrollo de software
23.5 Estimación de proyectos de software	Describe las principales categorías para efectuar la medición del software.	Revise los ejemplos de estimación basada en LCD de la Pág. 701 Analice el ensayo HOGAR SEGURO de la página 702 comente acerca de los puntos tratados por los actores. Revise los ejemplos de estimación basada en Puntos de Función de la Pág. 703 Revisar los puntos 23.6.5, 23.6, 23.6.7 y 23.6.8 interesa que se adquiera un conocimiento general de los temas planteados. Revise la información proporcionada en la Pág. 709 Técnicas de estimación automatizada para proyectos de software
23.7 Modelos empíricos de estimación		Investigue acerca de la evolución Constructuve Cost Model (COCOMO) Revisar los puntos 23.8, 23.9 y 23.10 interesa que se adquiera un conocimiento general de los temas planteados. Investigue las herramientas para la estimación de esfuerzo y costo descritas en la Pág.: 716
23.9 Técnicas de estimación especializadas.	Permiten realizar estimaciones para proyecto de duración extremadamente corta, que probablemente tengan una continua corriente de cambios – la planificación del proyecto en general y la estimación se debe abreviar.	Revisar puntos 23.9.1 y 23.9.2 interesa que se adquiera un conocimiento general del tema. Recopile información de metodologías extremas XP – AUP, que le permitan obtener un enfoque claro de cómo aplicar la estimación

[editar] Capitulo 4 : GESTIÓN DEL CAMBIO

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	27 Gestión del Cambio
Páginas	797 – 825
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

La gestión de configuración del software es una actividad protectora que se aplica a lo largo del proceso de software. La gestión de configuración del software permitirá al estudiante identificar, controlar, auditar e informar modificaciones que invariablemente ocurren mientras se desarrolla software y después de que se libera a un cliente.

[editar] Conceptos Clave

Auditorias: La identificación, el control de la versión y el control del cambio ayudan al desarrollador del software a mantener orden en lo que de otro modo sería una situación caótica e inestable

Cambio: El cambio es inevitable cuando se construye software de computadora. Y el cambio aumenta el grado de confusión entre los ingenieros de software que trabajan en un proyecto. La confusión se origina cuando los cambios no se analizan antes de implementarlos, no se reportan a quienes deben saberlo o no se controlan en una forma que mejorará la calidad y reducirá el error.

Control de la versión: Combina procedimientos y herramientas para gestionar diferentes versiones de objetos de configuración que se crean durante el proceso del software. Un sistema de control de la versión implementa o está directamente integrado en cuatro grandes capacidades:

1. Una base del proyecto (depósito) que guarda todos los objetos de configuración relevantes.

2. Una capacidad de gestión de la versión que almacena todas las versiones de un objeto de configuración

3. Una facilidad de hechura que permita al ingeniero de software recopilar todos los objetos de configuración relevantes y construir una versión especifica de software.

Control del cambio: El control del cambio es vital. Nos preocupamos por los cambios porque una pequeña perturbación en el código puede crear una gran falla en el producto. Pero también puede resolver una gran falla o permitir maravillosas nuevas capacidades.

El control de cambios es una actividad de procedimiento que asegura la calidad y la consistencia conforme los cambios se realizan en un objeto de configuración. El proceso de control de cambios comienza con una petición de cambio, conduce a una decisión para aceptar o rechazarla y culmina con una actualización controlada del ECS que se cambiará.

Depósito: Es un conjunto de mecanismos y estructuras de datos que permite que un equipo de software maneje el cambio de una forma eficaz. Proporciona las funciones obvias de un sistema de gestión de base de datos pero, además el depósito realiza o impulsa las siguientes funciones:

La integridad de datos
Compartir información
La integración de herramientas
La integración de los datos
El fortalecimiento de la metodología
Estandarización de los documentos.

ECS: Un elemento de configuración del software (ECS) es información que se crea como parte del proceso de ingeniería de software. Se puede considerar que un ECS es una sola sección de una gran especificación o un caso de prueba de un gran conjunto de pruebas. Un ECS es un documento, un conjunto completo de casos de prueba o un componente de un programa dado (por ejemplo: una función C++ o un applet de Java)

Gestión del contenido: Se relaciona con la gestión de la configuración en el sentido en que un sistema de gestión de contenido (SGC) establece un proceso (apoyado por herramientas) que adquiere contenido existente (de un amplio ordenamiento de objetos de configuración de la Webapp), los estructura en una forma que permite presentarlos a un usuario final y luego los ofrece al entorno del lado del cliente para su despliegue.

Identificación: El control y la gestión de elementos de configuración del software requiere nombrar cada uno por separado y luego organizarlo mediante un enfoque orientado a objetos. El esquema de identificación para los objetos de configuración debe reconocer que los objetos evolucionan a lo largo del proceso de software.

Informe de estado: El informe de estado de la configuración (a veces llamado contabilidad de estado) es una tarea de GCS que responde a las siguientes preguntas: 1) ¿qué ocurrió? 2) ¿quien lo hizo? 3) ¿cuándo ocurrió? 4) ¿qué otra cosa será afectada?

Líneas base: Una especificación o producto que se ha revisado formalmente y se está de acuerdo con los resultados, y que a partir de ahí se sirve como la base para el desarrollo ulterior y que puede cambiarse sólo por medio de procedimientos formales de control de cambio.

En el contexto de la ingeniería del software, una línea base es un hito en el desarrollo del software. Se marca un alinea base para la entrega de uno o mas elementos de configuración del software (ECS) que se han aprobado como consecuencia de una revisión técnica formal. Por ejemplo, los elementos de un modelo de diseño se han documentado y revisado. Se han encontrado errores y se han corregido. Una vez que todas las partes del modelo se han revisado, corregido y luego aprobado, el modelo de diseño se convierte en una línea base.

[editar] Esquema de Estudio

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
27.1Gestión de la configuración del software.	Describe el conjunto de actividades que se han desarrollado para gestionar el cambio a lo largo del ciclo de vida del software,	Defina un escenario particular para la Gestión de la Configuración del software, identificando cada uno de los involucrados, luego compare su trabajo con el especificado en el libro para esto revise el punto 27.1.1 Describa las actividades que tienen que cumplir cada uno de los elementos de las GCS Identifique las principales actividades que involucra el levantamiento de una línea base para GCS, para esto tome como referencia el punto 27.1.3 y la figura 27.1
27.2 El deposito de la ECS	Proporciona una descripción de la manera cuantitativa de evaluar la calidad de los atributos internos de un producto.	Determine cual es el principal beneficio de un depósito de ECS. Fundamente este tema con la lectura de los puntos 27.2.2 y 27.2.3 Analice el sistema de versiones concurrentes (SVC) descrito en la Pág.: 809.
27.3 El proceso de la GCS	Define una serie de tareas que permiten: identificar los elementos que definen la configuración del software, gestionan los cambios a uno o más de dichos elementos, facilitan la construcción de diferentes versiones de una misma aplicación y garantizan que la calidad del software se conserve conforme la configuración evoluciona a lo largo del tiempo	Realice un análisis de cada una de las cinco tareas de la gestión de configuración del software. Analice el ensayo HOGAR SEGURO de la página 813 comente acerca de los puntos tratados por los actores. Investigue las herramientas de soporte a la Gestión de Configuración de Software descritas en la Pág.: 815.
27.4 Gestión de la configuración para ingeniaría Web	La gestión de la configuración para la ingeniería Web es similar en muchos aspectos a la GCS para el software convencional, sin embargo, cada una de las tareas principales de la GCS se deben destacar para hacerla tan simples como sea posible, y se deben aplicar provisiones especiales para la gestión del contenido	Realice un análisis de los temas que se deben tratar en la gestión de configuración de la WebApp. Pág. 816 Detalle el funcionamiento de la función de la gestión del contenido para WebApp. Investigue las herramientas de gestión del contenido descritas en la Pág.: 819 - 820. Detalle el funcionamiento de la función de la gestión del cambio para WebApp. Investigue las herramientas de gestión del cambio descritas en la Pág.: 822. Detalle el funcionamiento de la función de la gestión del cambio para WebApp. Detalle el funcionamiento del control de la versión para WebApp. Investigue acerca de cada uno de los estándares de GCS descritos en la Pág.: 824.

[editar] Capitulo 5 : MÉTODOS FORMALES DE LA INGENIERÍA DE SOFTWARE

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	28 Métodos Formales
Páginas	831 – 854
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

Los métodos formales permitirán que el estudiante cree una especificación más completa, consistente y precisa que las que se producen empleando métodos convencionales. Todo esto utilizando la notación de la teoría de conjuntos y lógica para crear un claro planteamiento de hechos (requisitos).

[editar] Conceptos Clave

Esquema: Es en esencia, la especificación análoga del componente del lenguaje de programación. En la misma forma que los componentes se emplean para estructurar un sistema, los esquemas se utilizan al estructurar una especificación formal.

Estados: Un sistema puede estar en uno o varios estados, y cada uno de ellos representa un modo de comportamiento observable externamente.

Invariante de datos: Define lo que está garantizando que no cambiará.

Lenguaje Z: Es un lenguaje de especificación queque aplica conjuntos tipificados, relaciones y funciones dentro del contexto de predicados lógicos de primer orden para construir esquemas, un medio para estructurar una especificación formal.

OCL: Lenguaje restringido a objetos (OCL), es una notación formal desarrollada de modo que los usuarios de UML puedan conferirle mayor precisión a sus especificaciones. Dispone de todo el poder de la lógica y las matemáticas discretas.

Operadores lógicos: Un componente importante de un método formal es la lógica: el algebra de expresiones verdaderas y falsas

Pre y poscondiciones: Una precondición define las circunstancias en las cuales es válida una operación en particular.

Una poscondición de una operación define lo que esta garantizando que será cierto hasta completar una operación.

[editar] Esquema de Estudio

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
28.1 Conceptos básicos	Describe los fundamentos teóricos de los métodos formales de la ingeniería de software.	Revisar los puntos 28.1.1, 28.1.2, 28.1.3 interesa que se adquiera un conocimiento general de los conceptos de los métodos formales.
28.2 Preliminares matemáticos	La aplicación eficaz de los método formales requiere un conocimiento operativo de la notación matemática asociada con los conjuntos y las secuencias, y de la notación lógica utilizada en el calculo de predicados	Revisar los puntos 28.2.1, 28.2.2, 28.2.3, 28.2.4, 28.3 interesa que se adquiera una concepción general del tema.
28.3. Lenguajes formales de especificación.	Los lenguajes formales de especificación se basan en tres corrientes que permiten dar una notación formal a las especificaciones de usuario estas se basan en: 1) el dominio sintáctico (notación especifica con la que se representa la especificación), 2) el dominio semántico (ayuda a definir el universo de objetos que se empleará para definir el sistema y 3) un conjunto de relaciones (definen las reglas que indican cuales objetos satisfacen adecuadamente la especificación).	Analice cada uno de los componentes principales de un lenguaje formal y señale sus diferencias. Revise los puntos 28.5 (Lenguaje restringido a objetos (OCL), y 28.6, (Lenguaje de especificación Z.) es importante que adquiera destrezas en la utilización de estos lenguajes. Investigue cada una de las herramientas diseñadas para Métodos Formales descritas en la Pág.: 852 Complemente el estudio de este capítulo con la lectura de los puntos 28.7 y 28.8.

Tema a revisar

Descripción del Contenido a revisar

Actividades Recomendadas

Planificación Personal del estudio (fecha)

¿Requiero Tutorial?

Anotaciones

28.1 Conceptos básicos

Describe los fundamentos teóricos de los métodos formales de la ingeniería de software.

Revisar los puntos 28.1.1, 28.1.2, 28.1.3 interesa que se adquiera un conocimiento general de los conceptos de los métodos formales.

28.2 Preliminares matemáticos

La aplicación eficaz de los método formales requiere un conocimiento operativo de la notación matemática asociada con los conjuntos y las secuencias, y de la notación lógica utilizada en el calculo de predicados

Revisar los puntos 28.2.1, 28.2.2, 28.2.3, 28.2.4, 28.3 interesa que se adquiera una concepción general del tema.

28.3. Lenguajes formales de especificación.

Los lenguajes formales de especificación se basan en tres corrientes que permiten dar una notación formal a las especificaciones de usuario estas se basan en: 1) el dominio sintáctico (notación especifica con la que se representa la especificación), 2) el dominio semántico (ayuda a definir el universo de objetos que se empleará para definir el sistema y 3) un conjunto de relaciones (definen las reglas que indican cuales objetos satisfacen adecuadamente la especificación).

Analice cada uno de los componentes principales de un lenguaje formal y señale sus diferencias.

Revise los puntos 28.5 (Lenguaje restringido a objetos (OCL), y 28.6, (Lenguaje de especificación Z.) es importante que adquiera destrezas en la utilización de estos lenguajes.

Investigue cada una de las herramientas diseñadas para Métodos Formales descritas en la Pág.: 852

Complemente el estudio de este capítulo con la lectura de los puntos 28.7 y 28.8.

[editar] Capitulo 6:INGENIERÍA DE SOFTWARE DE SALA LIMPIA

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	29 Ingeniería de Software de Sala Limpia
Páginas	858 – 875
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

Este capítulo presenta las principales características del proceso de sala limpia: desarrollo incremental en el ciclo de vida y el aseguramiento de la calidad a través de pruebas estadísticas. El ciclo de vida comienza con una especificación que no solamente define funciones y requerimientos de rendimiento, sino, también identifica el uso operacional del software y una secuencia anidada de subconjuntos de funciones de usuario que pueden ser desarrolladas e probadas como incrementos que se acumulan dentro de un sistema final

[editar] Conceptos Clave

Certificación: En el contexto del enfoque de ingeniería de software de sala limpia la certificación implica que la fiabilidad se especifica para cada componente.

La certificación para la ingeniería de software requiere la creación de tres modelos:

Modelos de muestreo
Modelo de componentes
Modelos de certificación

Especificación de caja de estado: La caja de estado “es una generalización simple de una máquina de estados”. Conforme ocurren los procesamientos, un sistema responde a los eventos (estímulos) mediante la realización de transiciones desde el estado actual hasta cierto estado nuevo.

Especificación de caja transparente: Esta cercanamente relacionada con el diseño de procedimientos y la programación estructurada.

Especificación de caja negra: Describe la abstracción, estímulos y respuesta mediante notación mostrada en la figura. Muchos de los conceptos introducidos para los sistemas orientados a objetos también son aplicables respecto de la caja negra. Las abstracciones de datos y las operaciones que manipulan dichas abstracciones las encapsula la caja negra. Al igual que una jerarquía de clase, la especificación de caja negra puede exhibir el uso de jerarquías en las cuales las cajas de nivel inferior heredan las propiedades de cajas superiores en la estructura de árbol.

Especificación de estructura de cajas: La ingeniería de software de sala limpia cumple con los principios de análisis operativos empleando este método. Una caja encapsula al sistema (o algún aspecto de este) en algún grado de detalle, por medio de un proceso de elaboración o refinamiento de niveles, las cajas se refinan en una jerarquía donde cada una tiene transparencia referencial. Esto es el contenido de información de cada especificación de caja es suficiente para definir su refinamiento, sin depender del refinamiento de alguna otra caja.

Especificación funcional: El objetivo global es moverse desde una especificación (o modelo) que capture la esencia de un problema hasta una especificación que ofrezca sustanciales de talles de implementación.

Estrategia de sala limpia: El enfoque de sala limpia utiliza un versión especializada del modelo de proceso incremental, Mediante pequeños equipos de software independientes desarrolla una línea de incrementos de software. Conforme cada incremento se certifica se integra en el todo. Por ende, la funcionalidad des sistema crece con el tiempo.

Prueba estadística de uso: La prueba estadística de uso “equivale a probar software en la forma que los usuarios intentarían usarlo”. Esto se logra si los equipos de prueba de sala limpia determinan una distribución de probabilidad de uso para el software.

[editar] Esquema de Estudio

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.

Tema a revisar

Descripción del Contenido a revisar

Actividades Recomendadas

Planificación Personal del estudio (fecha)

¿Requiero Tutorial?

Anotaciones

29.1 El enfoque sala limpia

Más que fabricar un producto y luego trabajar para eliminar los defectos, el enfoque de sala limpia demanda la disciplina requerida para eliminar los errores en la especificación y el diseño y luego fabricarlo de una manera limpia.

“La única forma de que en un programa ocurran los errores es que un autor los ponga ahí. No se conocen otros mecanismos….La práctica correcta busca evitar la inserción de errores y, cuando se falla al respecto, eliminarlos antes de probarlo o cualquiera otra forma de ejecutar el programa”

Haga un análisis de la estrategia ingeniería de sala limpia a partir de la figura 29.1.

En forma análoga analice las tareas que se realizan una vez que la funcionalidad se ha asignado a al elemento de software del sistema.

Ejemplifique a través de modelos como los de las figuras 29.2, 29.3 y 29.4, 29.5 el refinamiento de estructura de cajas, especificación de caja negra, especificación caja de estado y especificación de caja transparente para esto tome como base la fundamentación teórica de estos temas

29.3 Diseño de sala limpia

Establece el enfoque general utilizado por la ingeniería de software

29.4 Pruebas de sala limpia.

La estrategia y las tácticas de la pruebas de sala limpia son fundamentalmente diferentes de los enfoques de prueba convencionales. La meta de las pruebas de sala limpia es validar los requisitos de software demostrando que una muestra estadística de casos de uso se ha ejecutado exitosamente.

“La calidad no es un acto es un hábito”

Seleccione un componente de programa que usted haya diseñado y establezca una distribución de probabilidad de uso del software.

Defina en sus propias palabras cual es la diferencia fundamental entre pruebas estadísticas de uso vs. pruebas de validación del software.

En forma análoga revise el punto 29.4.2 Certificación, como complemento a la temática del capítulo.

[editar] Capitulo 7 :INGENIERÍA DE SOFTWARE BASADA EN COMPONENTES

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	30 Ingeniería de Software Basada en Componentes
Páginas	879 – 899
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

Este capitulo presenta los modelos, conceptos y mecanismos fundamentales sobre los que se apoya actualmente el desarrollo de aplicaciones software basado en componentes reutilizables. En primer lugar, las arquitecturas software y los marcos de trabajo intentan ofrecer soluciones de diseño desde el punto de vista estructural de las aplicaciones, y de las relaciones entre sus componentes. A otro nivel se encuentra la programación orientada a componentes, un paradigma que propugna la construcción de componentes reutilizables en entornos abiertos y distribuidos, con el objetivo de lograr un mercado global de software.

[editar] Conceptos Clave

Adaptación: En un contexto ideal, la ingeniería del dominio crearía una biblioteca de componentes que podrían integrarse fácilmente a una arquitectura de aplicación.

Calificación: Garantiza que el componente candidato realiza la función requerida, encajará adecuadamente en el estilo arquitectónico que especifica el sistema y mostrará las características de calidad (por ejemplo: desempeño, fiabilidad, facilidad de uso) que requiere la aplicación.

Componentes:

Las propiedades características de un componente son:

Es una unidad de implementación independiente.
Es una unidad compuesta por terceras partes.
No cuenta con un estado observable desde el exterior.

Un componente encapsula las características que lo constituyen. Un componente nuca deberá ser desarrollado parcialmente. En este contexto una tercera parte no debe esperar tener acceso a los detalles de construcción de todo lo que involucra a los componentes.

Para que un componente pueda funcionar con otros componentes de terceras partes, éste necesita ser suficientemente independiente, y tener sus especificaciones de que es lo que requiere y que es lo que provee, lo suficientemente detalladas. En otras palabras, un componente necesita encapsular su implementación e interactuar con su ambiente a través de interfaces bien definidas.

Finalmente un componente no debe tener ningún posible estado observable desde el exterior. Esto quiere decir que se requiere que el componente no pueda ser distinguido de copias de si mismo. Una posible excepción a esta regla son los atributos que no inciden en el funcionamiento del componente, como lo es el número de serie del componente.

Debido a la naturaleza de los componentes en ningún proceso deberá haber a lo más una sola copia de un componente en particular. Por lo tanto no es significativo hablar acerca de un numero de copias disponibles de un componente. Los componentes son unidades de peso pesado con exactamente una instancia en el sistema.

Algunas definiciones más sobre componentes y que ayudaran a dar una visión más amplia son las siguientes:

Para Booch, un componente reutilizable de software es un módulo lógicamente cohesivo y con poco acoplamiento que denota una sola abstracción.

Los componentes de software reutilizables son elementos auto contenidos, claramente identificables que describen y/o realizan funciones específicas, tienen interfaces claras, documentación apropiada y un propósito de rehúso bien definido.

Los componentes de software son bloques reutilizables de construcción de sistemas de software. Encapsulan aplicaciones o servicios técnicos con sentido semántico. Difieren de otros tipos de módulos reutilizables en que pueden modificarse, al tiempo de diseño, en sus ejecutables binarios, mientras los demás lo hacen en su nivel de programa fuente. Los componentes restringen acceso vía una o más interfaces públicas que definen propiedades, métodos y eventos que permiten comunicación. Las propiedades y métodos representan una API típica. Los componentes existen y operan en contenedores que les brindan contexto compartido para interactuar con otros componentes y acceso a servicios del sistema.

DBC: El desarrollo basado en componentes (DBC) es una actividad de ISBC que ocurre en paralelo con la ingeniería del dominio. Al aplicar los métodos del diseño del análisis y arquitectónico el equipo de software refina un estilo arquitectónico para el modelo de análisis creado para la aplicación que se construirá. Una vez que la arquitectura se ha establecido, deben agregarse componentes que 1) estén disponibles en bibliotecas de reutilización, 2) sean diseñadas para satisfacer las necesidades personales del cliente.

Entorno de reutilización: La reutilización de componentes de software debe apoyarla un entorno que incluya los siguientes formatos:

* Una base de datos de componentes capaz de almacenar componentes de software, así como la información de clasificación necesaria para recuperarlos.

Un sistema de gestión de bibliotecas que ofrezca acceso a la base de datos.

* Un sistema de recuperación de componentes de software que permita que una aplicación cliente recupere componentes y servicios del servidor de la biblioteca.

* Herramientas de ISBC que apoyen la integración de los componentes reutilizados en un nuevo diseño o implementación.

Ingeniería del dominio:Permite identificar, construir, catalogar y diseminar un conjunto de de componentes de software que sean aplicables para el software existente y futuro en un dominio de aplicación particular.

La ingeniería del dominio trata de encontrar los aspectos comunes entre los sistemas para identificar los componentes que sea posible aplicar en muchos sistemas, y para identificar familias de programas que se posicionen para sacar la mayor ventaja de dichos componentes.

ISBC: La ingeniería de software basada en componentes (ISBC), es un proceso que concede particular importancia al diseño y la construcción de sistemas basados en computadoras que utilizan componentes de software reutilizables

Una afirmación que puede ser establecida con certeza es la siguiente: los componentes son para composición. La composición habilita cosas prefabricadas para ser rehusadas posteriormente en nuevas composiciones cualesquiera. Más allá de esta observación trivial, hay muchas cosas que no están claras.

Para convertir un elemento en reusable, no es suficiente iniciar con un diseño monolítico de una solución completa y entonces particionarla en fragmentos. Las descripciones de los componentes deben estar generalizadas cuidadosamente para permitir la reusabilidad en un número suficiente de diferentes contextos. Una sobregeneralización tiene que ser evitada para mantener las descripciones suficientemente ligeras con el fin de reusarlas y que permanezcan útiles.

Los componentes de software son unidades ejecutables de producción independiente, adquisición e implementación que pueden formar parte de un sistema funcional. Para permitir la composición, un componente de software se adhiere a un modelo de componentes particular y apunta a una plataforma de componentes particular.

Los sistemas compuestos integrados por componentes de software conforman el software de componentes. El requerimiento de la independencia y la forma ejecutable elimina muchas abstracciones del software; tales como declaraciones de tipo, macros de C, plantillas de C++, o bloques de Smalltalk. Otras abstracciones, como procedimientos, clases, módulos, o aún aplicaciones enteras, pueden formar componentes, mientras estén en una forma ejecutable que siga siendo integrable.

El motivo por el cual producir, distribuir, comprar y usar componentes de software, es porque los componentes son el camino a seguir, debido a que todas las demás disciplinas de ingeniería han introducido componentes desde que han llegado a ser maduras.

Ejemplo del diseño de un componente .NET: A continuación se describiré los distintos tipos de componentes que se pueden encontrar en una aplicación o servicio distribuido .NET, se muestra un ejemplo de una aplicación comercial:

El análisis de la mayoría de las soluciones empresariales basadas en modelos de componentes por capas muestra que existen varios tipos de componentes habituales. En la siguiente figura se muestran los tipos de componentes para el ejemplo de una aplicación comercial.

Imagen:Componentesdeaplicacioncomercial.jpg

Componentes identificados en el ejemplo de la aplicación de comercio.

Componentes de interfaz de usuario (IU): La mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicación. En el ejemplo de aplicación comercial, un sitio Web permite al cliente ver productos y realizar pedidos, y una aplicación basada en el entorno operativo Microsoft Windows permite a los representantes de ventas escribir los datos de los pedidos de los clientes que han telefoneado a la empresa. Las interfaces de usuario se implementan utilizando formularios de Windows Forms, páginas Microsoft ASP.NET, controles u otro tipo de tecnología que permita procesar y dar formato a los datos de los usuarios, así como adquirir y validar los datos entrantes procedentes de éstos.

Componentes de proceso de usuario: En un gran número de casos, la interacción del usuario con el sistema se realiza de acuerdo a un proceso predecible. Por ejemplo, en la aplicación comercial, podríamos implementar un procedimiento que permita ver los datos del producto. De este modo, el usuario puede seleccionar una categoría de una lista de categorías de productos disponibles y, a continuación, elegir uno de los productos de la categoría seleccionada para ver los detalles correspondientes. Para facilitar la sincronización y organización de las interacciones con el usuario, resulta útil utilizar componentes de proceso de usuario individuales. De este modo, el flujo del proceso y la lógica de administración de estado no se incluye en el código de los elementos de la interfaz de usuario, por lo que varias interfaces podrán utilizar el mismo ‘’motor’’ de interacción básica.

Componentes de flujos de trabajo empresariales: Una vez que el proceso de usuario ha recopilado los datos necesarios, éstos se pueden utilizar para realizar un proceso empresarial. Por ejemplo, tras enviar los detalles del producto, el pago y el envío a la aplicación comercial, puede comenzar el proceso de cobro del pago y preparación del envío. Gran parte de los procesos empresariales conllevan la realización de varios pasos, los cuales se deben organizar y llevar a acabo en un orden determinado. Por ejemplo, el sistema empresarial necesita calcular el valor total del pedido, validar la información de la tarjeta de crédito, procesar el pago de la misma y preparar el envío del producto.

Componentes empresariales: Independientemente de si el proceso empresarial consta de un único paso o de un flujo de trabajo organizado, la aplicación requerirá probablemente el uso de componentes que implementen reglas empresariales y realicen tareas empresariales. Por ejemplo, en la aplicación comercial, deberá implementar una funcionalidad que calcule el precio total del pedido y agregue el costo adicional correspondiente por el envío del mismo. Los componentes empresariales implementan la lógica empresarial de la aplicación.

Agentes de servicios: Cuando un componente empresarial requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para administrar la semántica de la comunicación con dicho servicio. Por ejemplo, los componentes empresariales de la aplicación comercial descrita anteriormente podrían utilizar un agente de servicios para administrar la comunicación con el servicio de autorización de tarjetas de crédito y utilizar un segundo agente de servicios para controlar las conversaciones con el servicio de mensajería. Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el servicio al formato que requiere la aplicación.

Interfaces de servicio: Para exponer la lógica empresarial como un servicio, es necesario crear interfaces de servicios que admitan los contratos de comunicación (comunicación basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes. Por ejemplo, el servicio de autorización de tarjetas de crédito debe exponer una interfaz de servicios que describa la funcionalidad que ofrece el servicio, así como la semántica de comunicación requerida para llamar al mismo. Las interfaces de servicios también se denominan fachadas empresariales.

Componentes lógicos de acceso a datos: La mayoría de las aplicaciones y servicios necesitan obtener acceso a un almacén de datos en un momento determinado del proceso empresarial. Por ejemplo, la aplicación empresarial necesita recuperar los datos de los productos de una base de datos para mostrar al usuario los detalles de los mismos, así como insertar dicha información en la base de datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lógica necesaria para obtener acceso a los datos en una capa independiente de componentes lógicos de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el mantenimiento de la misma.

Componentes de entidad empresarial: La mayoría de las aplicaciones requieren el paso de datos entre distintos componentes. Por ejemplo, en la aplicación comercial es necesario pasar una lista de productos de los componentes lógicos de acceso a datos a los componentes de la interfaz de usuario para que éste pueda visualizar dicha lista. Los datos se utilizan para representar entidades empresariales del mundo real, como productos o pedidos. Las entidades empresariales que se utilizan de forma interna en la aplicación suelen ser estructuras de datos, como conjuntos de datos, DataReader o secuencias de lenguaje de marcado extensible (XML), aunque también se pueden implementar utilizando clases orientadas a objetos personalizadas que representan entidades del mundo real necesarias para la aplicación, como productos o pedidos.

Componentes de seguridad, administración operativa y comunicación: La aplicación probablemente utilice también componentes para realizar la administración de excepciones, autorizar a los usuarios a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones.

Proceso: Se caracteriza de tal forma que no sólo identifica los componentes candidatos sino que también cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones arquitectónicas, ensambla los componentes en un estilo arquitectónico seleccionado y actualiza los componentes conforme los requisitos cambian.

Puntos de estructura: Es una abstracción que debe tener un número limitado de instancias. Además la abstracción debe recurrir a través de las aplicaciones en el dominio. De otro modo no se justifica el costo de verificar, documentar y diseminar el punto de estructura.

[editar] Esquema de Estudio

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
30.1 Ingeniería de Sistemas basada en componentes	Describe como la ingeniería de software basada en componentes ofrece beneficios inherentes en la calidad del software, la productividad del desarrollador y el costo global del sistema. En la actualidad los complejos sistemas de alta calidad basados en computadoras se deben construir en un tiempo muy corto y demanda un enfoque mas organizado de reutilización, es por esto que	Cual es la concepción que usted tiene de la ingeniería de software basada en componentes. Indique si es posible construir sistemas complejos mediante el ensamblado de componentes de software reutilizables provenientes de un catálogo, realice un análisis.
30.2 El proceso ISBC	Se caracteriza de tal forma que no sólo identifica los componentes candidatos sino que también cualifica la interfaz de cada componente. Destaca dos procesos concurrentes: la ingeniería del dominio y el desarrollo basado en componentes	En base a la figura 30.1 analice el proceso de ISBC. Fundamente el proceso de la ISBC con la lectura de los puntos 30.3 y 30.4 Destaque en una tabla las principales características de la ingeniería del dominio y el desarrollo basado en componentes Analice la información presentada en la Pág.: 890 en donde se describe la Arquitectura común e distribución de objetos. Obtenga un resumen con ideas principales.
30.5 Clasificación y recuperación de componentes	Los esquemas de clasificación permiten que un desarrollador encuentre y recupere componentes reutilizables y se ajuste a un modelo que identifica concepto, contenido y contexto. La clasificación enumerada, la clasificación por facetas y la clasificación de valores y atributos son representativas de muchos esquemas de clasificación de componentes	Conceptualice un esquema de clasificación de componentes de acuerdo a su experiencia en desarrollo, una vez que lo haya realizado contraste su trabajo con el planteado en la Pág: 893 – Describa un entorno para la reutilización de componentes y constaste su trabajo con la información descrita en la Pág.:894 Investigue las herramientas de software para el desarrollo basado en componentes descritas en la Pág.: 895.
30.6 Economía de la ISBC	La economía de la reutilización se aborda con una sola pregunta ¿es efectivo en costo el construir menos y reutilizar más? En general la respuesta es sí, pero un planificador de software debe considerar los costos importantes asociados con la calificación, adaptación e integración de los componentes reutilizables	Emita un criterio personal sobre el impacto de la calidad, la productividad y el costo en un ambiente de reutilización. Defina un punto de estructura adicional al planteado el libro para el análisis de costos

[editar] Capitulo 8 :REINGENIERÍA

[editar] Datos Generales:

Texto Base	Pressman Roger S. Ingeniería del Software. Un enfoque práctico 6ta edición. McGrawHill Interamericana Mexico. 2005.
Capítulo	29 Reingeniería
Páginas	902 – 924
Horas de estudio empleadas para el desarrollo del contenido	8 horas

[editar] Proposito

El propósito de este capitulo es el de desarrollar en el estudiante habilidades para comprender los modelos de negocio con el propósito de efectuar cambios para mejorar la competitividad en alguna área del negocio. Examinar sistemas y aplicaciones de información con la finalidad de reestructurarlos o reconstruirlos de manera que presenten mayor calidad.

[editar] Conceptos Clave

Análisis de inventarios: Las organizaciones de software deberían tener un inventario de todas sus aplicaciones. Al ordenar esta información de acuerdo con la importancia para el negocio, antigüedad, facilidad actual para el mantenimiento y otros criterios localmente importantes, aparecen los candidatos para reingeniería. Entonces se pueden asignar los recursos a las aplicaciones candidatas para el trabajo de reingeniería.

Economía: La reingeniería demanda de recursos que pueden utilizarse para otros propósitos del negocio. En consecuencia, antes de que una organización intente someter a reingeniería una aplicación existente, debe realizar un análisis costo beneficio.

Procesos de negocio: Conjunto de tareas lógicamente relacionadas que se ejecutan para lograr resultados de negocios especifico. Dentro del proceso de negocio, la gente, el equipo, los recursos materiales y los procedimientos del negocio, se combinan para producir un resultado específico.

Ingeniería directa: Reconstruye un programa empleando modernas prácticas de ingeniería de software y la información aprendida en la ingeniería inversa.

A partir de los productos de ingeniería inversa se construye el programa mediante técnicas de ingeniería directa.

* Reespecificación: Se reespecifican las especificaciones recuperadas del sistema heredado para incluir los nuevos requisito, modificar las funcionalidades existentes o añadir nuevas.

* Rediseño: Se refinan los modelos creados en el paso anterior, definiendo la arquitectura que tendrá el sistema, obteniendo un nuevo diseño. En este paso, hay que tener ya en cuenta los requisitos no funcionales (como el lenguaje de implementación, plataforma de explotación, etc.). Una vez que tanto los requisitos funcionales como los no funcionales se han tratado, se puede comenzar la generación de código

* Reimplementación: La generación de código puede ser llevada a cabo mediante herramientas CASE de manera automática, partiendo de los modelos desarrollados del sistema heredado.

Puesta en marcha.

Ingeniería inversa: Puede obtener información de diseño a partir de código fuente, pero el grado de abstracción, la completitud de la documentación, el grado en que las herramientas y un analista humano trabajen en conjunto, y la direccionalidad de proceso son enormemente variables.

El proceso de ingeniería inversa debe ser capaz de derivar representaciones de diseño de procedimiento (un grado de abstracción bajo), información de estructura de programa y datos (un grado de abstracción más elevado), modelos de objeto, modelos de flujo de datos o de control (un grado de abstracción relativamente alto) y clases UML, diagramas de estado y despliegue (un grado alto de abstracción)

Muchos sistemas tienen el código fuente como la única representación fiable. Esto es más común en sistemas muy antiguos que han tenido muchos cambios durante su ciclo de vida.

Estos sistemas tienen un crecimiento substancial desde su inicio, y generalmente no han tenido actualizaciones de su documentación. Aquí es donde la ingeniería inversa es la técnica recomendada para redocumentar el sistema.

El primer documento que se necesita para navegar fácilmente en el sistema y encontrar la localización de un problema a nivel de análisis del Mantenimiento del Sistema es el esquema del programa.

Los pasos a seguir para realizar la ingeniería inversa son:

a) Disección del código fuente en unidades formales.

b) Descripción semántica de las unidades formales y declaración de unidades funcionales.

c) Creación de esquemas de entrada/salida de unidades.

d) Declaración y descripción semántica de circuitos lineales.

e) Declaración y descripción semántica de aplicaciones del sistema.

f) Creación de la anatomía del sistema.

Mantenimiento de software: La distinción entre las actividades asociadas con el desarrollo y aquellas asociadas con el mantenimiento, están basadas en la visibilidad de los problemas del sistema y la forma de transmitírselo a los usuarios, grupo de pruebas y desarrolladores. Antes del desarrollo, la visibilidad de los problemas del sistema para los usuarios y el grupo de pruebas podría ser relativamente baja, ya que la reparación de algunos problemas puede ser manejada de una manera informal por el grupo de desarrollo. Sin embargo, una vez que el sistema ha sido liberado, es necesario un proceso de seguimiento más formal. Esta formalidad es necesaria debido a que muchos grupos dentro de la organización influyen en la información transmitida de los problemas del sistema. Por ejemplo, el personal de soporte al usuario necesita saber sobre los problemas para que a su vez puedan describírselos a los usuarios. El grupo de pruebas necesita saber sobre los problemas ya que pueden ser requeridos rápidamente para generar un plan de pruebas enfocado sobre las áreas problemáticas. También los gerentes necesitan conocerlos para poder priorizar el trabajo que se está haciendo.

Una simple definición de mantenimiento es: el proceso de registro y seguimiento de problemas y la petición y gestión de respuestas. Un problema no necesariamente implica un defecto del software. Los problemas aparecen simplemente porque el comportamiento esperado del sistema no coincide con el comportamiento actual. Esto puede ser el resultado de un defecto del software, pero puede ser fácilmente el resultado de un desconocimiento de las capacidades del sistema, o de la utilización incorrecta del flujo de trabajo, o de una documentación pobre, o de cambios en las directrices de la empresa, o de otras tantas razones. La gestión de las respuestas a los problemas del sistema cubre un millar de posibles actividades. Algunas de las posibles respuestas a los problemas del sistema podrían incluir: liberación de nuevas versiones, sesiones de planificación, identificación de la formación necesaria, actualización de la documentación, etc.

Desde el punto de vista del grupo de desarrollo, el aspecto más significativo de un problema será si es causa de un defecto del software. La calidad de la información comunicada desde el usuario al grupo de desarrollo es crucial para poder determinarlo y para su rápida resolución.

Estándares de mantenimiento: Existen diversos estándares de otros tantos organismos internacionales de estandarización que tienen una relación directa o indirecta con el Mantenimiento del Software:

Para los procesos del ciclo de vida del software: IEEE 1074 e ISO 12207.
Para la calidad del software y sus métricas: IEEE 1061 e ISO 9126.
Para el Mantenimiento del Software: IEEE 1219 e ISO/IEC 14764

Los estándares para los procesos del ciclo de vida del software nos permiten encajar y asociar el proceso de mantenimiento con los demás procesos existentes para el software. Los estándares de calidad del software interesan en mantenimiento del software porque los factores de calidad del software (especialmente la complejidad y la mantenibilidad) inciden directamente sobre el esfuerzo de mantenimiento necesario.

Modelo de proceso RPN: Define metas del negocio, identifica y evalúa los procesos de negocios existentes, especifica y diseña procesos revisados y elabora prototipos, los refina y particulariza dentro de un negocio. Permite la definición de las formas en las cuales las tecnologías de la información

Reestructuración: Modifica el código fuente o los datos con la finalidad de adecuarlos para futuros cambios. En general, la reestructuración no modifica la arquitectura global del programa. Tiende a enfocarse sobre los detalles de diseño de los módulos individuales y en las estructuras de datos locales definidos dentro de los módulos. Si el trabajo de reestructuración se extiende más a lá de las fronteras de módulo, y abarca la arquitectura del software, la reestructuración se convierte en ingeniería avanzada.

Reestructura de datos: Antes de comenzar la reestructuración de datos se debe llevar a cabo una actividad e ingeniería inversa denominada análisis de código fuente, una vez completado este se comienza con el rediseño de datos. En su forma más simple, un paso de estandarización de registro de datos clarifica las definiciones para lograr la consistencia entre los nombres de elementos de datos o formatos de registros físicos dentro de una estructuras de datos existente o formato de archivo.

[editar] Esquema de Estudio

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
31.1 Reingeniería de procesos de negocio	Describe, que el ámbito de la reingeniería se centra en el proceso de negocio con el propósito de efectuar los cambios para mejorar la competitividad en alguna área del negocio	Revisar los puntos 31.1.1,y 31.1.2, interesa que se adquiera un conocimiento general de los tipos de los procesos de negocio y el modelo RPN Considere una actividad de desarrollo en la cual a participado, describa el proceso de negocio utilizado y utilice la RPN descrita en el libre para recomendar cambios al proceso con la finalidad de hacerlo más eficiente Investigue las herramientas de software para la Reingeniería de procesos de negocio descritas en la Pág.: 895
31.2 Reingeniería del software	Una aplicación que ha cubierto las necesidades de negocio de una compañía durante mucho tiempo indica que ha tenido correcciones y adaptaciones de mejora en muchas ocasiones, el personal se enfrentó a esto con las mejores intenciones y las buenas prácticas de la ingeniería de software fueron omitidas, tornando a la aplicación inestable, la aplicación tiene que evolucionar. Elsoftware al cual no se le puede dar mantenimiento no es un problema nuevo, de hecho cada vez más se le concede mayor importancia a la reingeniería de software, en la resolución de estos problemas.	Revisar los puntos 31.2.1, interesa que se adquiera un conocimiento general acerca del mantenimiento del software. En base a la figura 31.2 haga un análisis del modelo de procesos de la reingeniería del software descritos en el punto 31.2.2
31.3 Ingeniería Inversa	El objetivo de la ingeniería inversa es el de obtener información de diseño a partir de código fuente, pero el grado de abstracción, la completitud de la documentación, el grado en que las herramientas y un analista humano trabajan en conjunto, y la direccionalidad del proceso son enormemente variables. En este punto de ilustran las principales características de la ingeniería inversa en lo que tiene que ver a la comprensión de los datos, procesamiento de la información y las interfaces de usuario.	Revisar los puntos 31.3.1, 31.3.2 y 31.3.3 interesa que se adquiera un conocimiento general del tema. Investigue las herramientas de software para la ingeniería inversa descritas en la Pág.: 916
31.5 Ingeniería directa		Revisar los puntos 31.5.1, 31.5.2 y 31.5.3 interesa que se adquiera un conocimiento general del tema.

Obtenido de "http://www.utpl.edu.ec/ecc/wiki/index.php/Ingenier%C3%ADa_Software"

Ingeniería Software

De Computacion

Tabla de contenidos

[editar] Objetivo General

[editar] Objetivos Especificos

[editar] Bibliografia

[editar] Desarrollo del Aprendizaje

[editar] Capitulo 1: CONCEPTOS DE GESTIÓN DE PROYECTOS

[editar] Datos Generales:

[editar] Propositos

[editar] Conceptos Clave

[editar] Esquema de Estudio

[editar] Capitulo 2 : CONCEPTOS DE GESTIÓN DE PROYECTOS

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de estudio

[editar] Capitulo 3:ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de estudio

[editar] Capitulo 4 : GESTIÓN DEL CAMBIO

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de Estudio

[editar] Capitulo 5 : MÉTODOS FORMALES DE LA INGENIERÍA DE SOFTWARE

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de Estudio

[editar] Capitulo 6:INGENIERÍA DE SOFTWARE DE SALA LIMPIA

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de Estudio

[editar] Capitulo 7 :INGENIERÍA DE SOFTWARE BASADA EN COMPONENTES

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de Estudio

[editar] Capitulo 8 :REINGENIERÍA

[editar] Datos Generales:

[editar] Proposito

[editar] Conceptos Clave

[editar] Esquema de Estudio

Vistas

Herramientas personales

Navegación

Buscar

Herramientas