DOSSIER INGENIERIA DE SOFTWARE II - AULA...

56
DOSSIER INGENIERIA DE SOFTWARE II DOCENTE : Lic. Karen Ruth Chura Gonzales II/2011 La Paz Bolivia

Transcript of DOSSIER INGENIERIA DE SOFTWARE II - AULA...

DOSSIER INGENIERIA DE SOFTWARE II

DOCENTE : Lic. Karen Ruth Chura Gonzales

II/2011

La Paz – Bolivia

Ingeniería de Software II

KRCG -1-

I

Ingeniería de Software II

KRCG -2-

Índice General

Contenido Introducción ..................................................................................................................................... 4

1.1. Presentación.- ....................................................................................................................... 4 1.2. Objetivo.- .............................................................................................................................. 5

1.2.1. Objetivo General.- ......................................................................................................... 5 1.2.2. Objetivos Específicos.- .................................................................................................. 5

1.3. Importancia.-......................................................................................................................... 5 PARTE II ......................................................................................................................................... 9 CONTENIDO DEL DOSSIER ....................................................................................................... 9

2.1. Objetivos de la Materia.- ...................................................................................................... 9

2.1.1. Objetivo General.- ............................................................................................................. 9 2.1.2. Objetivos Específicos.- .................................................................................................. 9

2.2. Contenidos.- ........................................................................................................................ 10 2.2.1. Contenido Mínimo.- .................................................................................................... 10 2.2.2. Contenido Analítico ..................................................................................................... 10

2.3. Plan disciplina .................................................................................................................... 12 2.3.1. Metodología ................................................................................................................. 12

2.3.2. Modalidad de Evaluación ............................................................................................ 12 2.3.2. Métodos y Medios ....................................................................................................... 13

2.4. Desarrollo del contenido ..................................................................................................... 13 UNIDAD I ..................................................................................................................................... 15 INTRODUCCION - CONCEPTOS SOBRE GESTION DE PROYECTOS ............................... 15

2.4.1. El Espectro de la gestión.- ............................................................................................... 15 2.4.1.2. El personal.- .................................................................................................................. 15

2.4.1.3. El producto.- ................................................................................................................. 16 2.4.1.4. El proceso.- ................................................................................................................... 16 2.4.1.5. El proyecto.- ................................................................................................................. 17

UNIDAD II ................................................................................................................................ 18 PLANIFICACION DE PROYECTOS DE SOFTWARE ......................................................... 18

UNIDAD VII ................................................................................................................................. 40 INGENIERIA WEB ...................................................................................................................... 40

LECTURAS COMPLEMENTARIAS .......................................................................................... 47 3.1. Lecturas complementarias.- ................................................................................................ 47 3.2. Ingeniaría de Software.- ..................................................................................................... 47 3.3. Calidad de Software.- ......................................................................................................... 47 3.4. Obtener Software de Calidad.- ........................................................................................... 48

PARTE IV ..................................................................................................................................... 52 BIBLIOGRAFIA ........................................................................................................................... 52

4.1. Bibliografía.- ...................................................................................................................... 52 4.2. Bibliografía Complementaria.- .......................................................................................... 52

Ingeniería de Software II

KRCG -3-

PARTE V ....................................................................................................................................... 55 GLOSARIO ................................................................................................................................... 55

Ingeniería de Software II

KRCG -4-

Introducción

1.1. Presentación.-

La Ingeniería del Software va a introducirse en la cuarta década de su existencia y sufre

de los muchos puntos fuertes y débiles. La Ingeniería del Software se va aproximando a

su edad media con muchos logros a sus espaldas, pero con un trabajo significativo

todavía por hacer. Hoy en día, está reconocida como una disciplina legítima, digna de

tener una investigación seria. En la industria el Ingeniero del software ha sustituido al

programador como titulo de trabajo preferente. Los modelos de procesos de software,

métodos de ingeniería de software y herramientas se han adoptado con éxito en el

amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la

necesidad de un enfoque más disciplinado del software.

La búsqueda de técnicas que mejorasen la calidad y permitiesen reducir los costos de

las soluciones basadas en computadoras ha sido uno de los objetivos más perseguidos

desde los inicios de la informática. A mediados de los 60, la creación de un producto

software se convertía en una tarea angustiosa, se hizo por tanto necesario introducir

una serie de herramientas y procedimientos que facilitaran por un lado, la labor de

creación de nuevo software y por otro, la comprensión y el manejo del mismo. Estos

fueron los inicios de la Ingeniería del Software. Con el paso del tiempo, la evolución de

estos métodos nos han llevado a reconocer la Ingeniería del Software como una

verdadera disciplina, derivada de una investigación seria y de un estudio minucioso.

Por lo cual, es muy importante presentar el Dossier de la materia “Ingeniería de

Software II”, destinado a profesores y estudiantes; este permitirá una guía rápida de la

materia.

Ingeniería de Software II

KRCG -5-

1.2. Objetivo.-

1.2.1. Objetivo General.-

El Dossier tiene el objetivo principal de establecer un conjunto de documentos que rigen

la materia: “Ingeniería de Software”, la misma debe ser un referente para el estudiante y

el docente interesado.

1.2.2. Objetivos Específicos.-

1. Ofrecer el plan disciplinar de la materia.

2. Objetivos de la materia.

3. Los contenidos mínimos y analíticos.

4. Desarrollo de los capítulos de la materia.

5. Evaluación.

6. Lecturas complementarias.

7. Bibliografía.

1.3. Importancia.-

Consideramos que la importancia de documentos sobre una determinada materia,

permiten ayudar al interesado en muchos aspectos tales como: la Auto-formación, la

organización, información, entre otros; de modo que aprovechando este medio, es fácil

de llegar al estudiante y docente de la Universidad Salesiana de Bolivia. Es prioritario

ofrecer el servicio educativo de mayor calidad a los sectores sociales.

Por lo tanto, es importante lograr como objetivo una universidad que se constituya en

instancia de diálogo entre estudiantes, directores, docentes, administrativos y familias;

Ingeniería de Software II

KRCG -6-

que confié en los jóvenes de hoy valorizándolos y ofreciéndoles propuestas

pedagógicas atractivas.

Como ser:

1. ESTILO SALESIANO.- Las características del estilo salesiano son:

Cordialidad. Tratar al alumno con respeto, aclarando algunas interrogantes

que el estudiante pudiera tener, conduciéndolos hacia la verdad si se

muestran ideas equivocadas.

Estimular al estudiante haciéndole comprender que es capaz de realizar lo

que el se propone.

Crear un ambiente de democracia, lo cual permite que el estudiante se forme

así mismo.

Tener pleno respeto por la libertad del estudiante.

2. GRUPOS DE APRENDIZAJE COOPERATIVO.-

Los trabajos prácticos que constituyen el pilar principal de la materia se

desarrollaran en Grupos de Aprendizaje Cooperativo, los cuales mostraran en

todo momento características del Estilo Salesiano, y facilitando el proceso de

aprendizaje en cada uno de los miembros del grupo lo cual finalmente repercutirá

en el Aprendizaje de todos los GAC de la clase.

3. TECNOLOGÍA DE LA INFORMACIÓN Y COMUNICACIÓN

La comunicación y el uso de tecnología de la información es vital la aplicación de

la materia, por ello se motivara al estudiante la aplicación de la materia y el uso

de tecnologías de información

Ingeniería de Software II

KRCG -7-

La aplicación de estos Métodos nos llevará a que la clase se convierta en una •

CLASES MAGISTRALES Y PARTICIPATIVAS * que motive al estudiante a continuar

con los estudios en la carrera elegida.

La aplicación de estas tres Metodologías permiten que la universidad sea democrática

y solidaria, que reafirme los valores de nuestra identidad histórica: la solidaridad, el

respeto por las personas y las instituciones, la paz y la justicia social. Permite el

desarrollo de las capacidades y reconozca el merito en sus estudiantes. Que sea una

institución reflexiva en constante aprendizaje.

Ingeniería de Software II

KRCG -8-

Ingeniería de Software II

KRCG -9-

PARTE II

CONTENIDO DEL DOSSIER

2.1. Objetivos de la Materia.-

2.1.1. Objetivo General.-

Complementar el enfoque de ingeniería con todos los aspectos de gestión asociados a

los proyectos de ingeniería en el desarrollo y mantenimiento y mantenimiento de

software. Incidir en la gestión y organización tanto a nivel de empresa como de

proyecto para asegurar la consecución de software de calidad. Asimismo, se debe

insistir en el análisis de aplicaciones mediante métodos y técnicas avanzadas de

modelado como de extracción de requisitos.

2.1.2. Objetivos Específicos.-

Dar a conocer los conceptos fundamentales de complementación sobre

ingeniería de software.

Introducir al alumno al desarrollo de software utilizando técnicas y métodos

avanzados como CMM, PSP, SPICE, etc.

Utiliza el PSP para el desarrollo de software personal.

Dar a conocer las métricas para medir el software.

Comprender la importancia de la Materia en el ingeniero de sistemas

Enfatizar algunos conceptos centrales de la materia.

Preparar al estudiante en el manejo de Modelos, Técnicas, Herramientas de

Ingeniería de Software

Ingeniería de Software II

KRCG -10-

El estudiante será capaz de trabajar en grupos de aprendizaje cooperativos

(GAC) para una comprensión cabal de muchos acontecimientos que ocurren

diariamente en clases de la asignatura.

Promover el respeto, la cordialidad y la profundidad del afecto mutuo entre

estudiantes y en los grupos de aprendizaje cooperativo.

2.2. Contenidos.-

2.2.1. Contenido Mínimo.-

UNIDAD I. Introducción - conceptos sobre gestión de proyectos UNIDAD II. Planificación de proyectos de software UNIDAD III. Gestión y configuración del software UNIDAD IV. Proceso del software y métricas de proyectos UNIDAD V. Mantenimiento y documentación UNIDAD VI. Ingeniería del software del comercio electrónico cliente/servidor UNIDAD VII. Ingeniería Web UNIDAD VIII. Reingeniería

2.2.2. Contenido Analítico

UNIDADES Y CONTENDIDO ANALÍTICO DE LA MATERIA

UNIDAD I INTRODUCCION - CONCEPTOS SOBRE GESTION DE PROYECTOS El Espectro de la gestión, El personal, El producto, El proceso, El proyecto, El principio W

5HH.

UNIDAD II PLANIFICACION DE PROYECTOS DE SOFTWARE Observación sobre la Estimación, Objetivos de la Planificación del Proyecto, Ámbito del Software, Recursos, Estimación del proyectos de Software, Técnicas de Descomposición, Modelos Empíricos de Estimación (COCOMO), La Decisión de Desarrollar – Comprar, Herramientas Automáticas de Estimación.

Ingeniería de Software II

KRCG -11-

UNIDAD III GESTION Y CONFIGURACION DELSOFTWARE Gestión de Configuración del Software, El proceso de GCS. Identificación de Objetos en la Configuración del Software, Control de Versiones, Control de Cambios, Auditoria de la Configuración, Informes de Estado.

UNIDAD IV PROCESO DEL SOFTWARE Y METRICAS DE PROYECTOS Modelos de mejora CMM, SPICE, ISO 9001, ISO 9000 –3, ISO 9004-2, PSP

UNIDAD V MANTENIMIENTO Y DOCUMENTACION Ingeniería y Mantenimiento, Clasificación y Estadísticas, Factores de Costo de Mantenimiento, Mitos de los Desarrolladores, Documentación del Sistema y Usuario, Proceso de Mantenimiento, Re - Estructuración de la Documentación, Medición de Mantenimiento.

UNIDAD VI INGENIERIA DEL SOFTWARE DEL COMERCIO ELECTRONICO CLIENTE/SERVIDOR Introducción, Sistemas Distribuidos, Arquitecturas Estratificadas, Protocolos, Un Sistema de Comercio Electrónico, Tecnologías usadas para el Comercio Electrónico, El Diseño de Sistemas Distribuidos, Ingeniería de Seguridad, Componentes de Software para Sistemas C/S, Ingeniería de Software para Sistemas C/S, Problemas de Modelado de Análisis, Diseño de Sistemas C/S, Problemas de las Pruebas.

UNIDAD VII INGENIERIA WEB Los Atributos de Aplicaciones basadas en Web, El proceso IWEB, Un Marco de Trabajo para la IWEB, Formulación y Análisis de Sistemas Basados en Web, Diseño para Aplicaciones basadas en Web, Problemas de Gestión.

UNIDAD VIII REINGENIERIA Reingeniería de Procesos de Negocios, Reingeniería del Software, Ingeniería Inversa, Reestructuración, Ingeniería Directa (Forward Engineering), Economía de la Reingeniería.

Ingeniería de Software II

KRCG -12-

2.3. Plan disciplina

2.3.1. Metodología

La exposición por parte del profesor (motivación hacia la conceptualización).

La discusión entre el profesor y el estudiante, y entre los propios estudiantes

sobre definiciones y conceptos.

El trabajo practico apropiado

La consolidación y practica de técnicas y rutinas fundamentales.

La resolución de problemas, incluida la aplicación de las Métodos, técnicas y

herramientas de Ingeniería de Software a la vida real (o la aplicación).

Trabajos de investigación fundamentales para el .desarrollo científico del

estudiante.

Todas estas actividades estarán apoyadas por:

ESTILO SALESIANO. GRUPOS DE APRENDIZAJE COOPERATIVO

TECNOLOGÍA DE LA INFORMACIÓN Y COMUNICACIÓN

2.3.2. Modalidad de Evaluación

La evaluación es formativa periódica y sumativa, los exámenes parciales y final son

escritos.

Tres evaluaciones cada una por 100 puntos.

1er. Evaluación 100%

2da. Evaluación 100%

Evaluación Final 100%

Ingeniería de Software II

KRCG -13-

Procedimiento de Evaluaciones:

1er. Evaluación 100%

2da. Evaluación 100%

PROMEDIO DE EVALUACIONES 1er. y 2da. X%

Evaluación Final 100%

PROMEDIOS DE EVALUACIONES Y EVA. FINAL Y%

TOTAL EVALUACION 100%

Para cada evaluación se tomar en cuenta los siguientes parámetros:

Practicas Individuales 15%

Practicas en GAC 15%

Examen 40%

Proyecto 30%

TOTAL EVALUACION 100%

2.3.2. Métodos y Medios

Los métodos de aplicación del proceso curricular de la materia están contenidas en el

proceso de enseñanza y aprendizaje centrada en el estudiante para lograr un

aprendizaje significativo con razonamientos inductivos y deductivos y un aprendizaje

por descubrimiento programado, orientado, puro libre y al azar que permita al

estudiante desarrollar su potencialidad creativa.

2.4. Desarrollo del contenido

Se desarrollan a continuación:

Ingeniería de Software II

KRCG -14-

Ingeniería de Software II

KRCG -15-

UNIDAD I

INTRODUCCION - CONCEPTOS SOBRE GESTION DE PROYECTOS

2.4.1. El Espectro de la gestión.-

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: Personal, Producto,

Proceso y Proyecto.

El orden no es arbitrario. El gestor que se olvida que el trabajo de ingeniería del software es un

esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta

una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a

construir una elegante solución para un problema equivocado. El administrador que presta poca

atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.

El gestor que comprende un proyecto sin un plan sólido arriesga el éxito del producto.

2.4.1.2. El personal.-

La necesidad de contar con personal para el desarrollo del software altamente preparado y

motivado se viene discutiendo desde los años 60. De hecho, el “factor humano” es tan importante

que el Instituto de Ingeniería del Software ha desarrollado un Modelo de Madurez de Capacidad

de Gestión de Personal (MMCGP) “para aumentar la preparación de organizaciones del software

para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar,

motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de

software”.

Ingeniería de Software II

KRCG -16-

El Modelo de Madurez de gestión de personal define las siguientes áreas clave prácticas para el

personal que desarrolla software: Reclutamiento, Selección, Gestión de Rendimiento,

Entrenamiento, retribución, Desarrollo de la Carrera, Diseño de la Organización y del Trabajo y

Desarrollo Cultural y de Espíritu de Equipo.

El MMCGP es compañero del modelo de madurez de la capacidad de software, que guía a las

organizaciones en la creación de un proceso de software maduro.

2.4.1.3. El producto.-

Antes de poder planificar un proyecto, se deberían establecer objetivos y el ámbito del producto,

se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión.

Sin esta información es imposible definir unas estimaciones razonables (y exactas) del coste; una

valoración efectiva del riesgo, una subdivisión realista de las tareas de l proyecto o una

planificación del proyecto asequible que proporcione una indicación fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y

su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del

sistema o del negocio y continúa con el primer paso en el análisis de los requisitos del software.

Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán.

El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al

producto, y más importante, intenta abordar estas características de una manera cuantitativa.

Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones

alternativas.

2.4.1.4. El proceso.-

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado

plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede

aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.

Ingeniería de Software II

KRCG -17-

Diferentes conjuntos de tareas permiten a las actividades estructurales adaptarse a las

características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las

actividades protectoras – tales como garantía de calidad del software y medición – cubren el

modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen

lugar a lo largo del proceso.

2.4.1.5. El proyecto.-

Dirigimos los proyectos de software planificados y controlados por una razón principal - es la

única manera de gestionar la complejidad –. Y todavía seguimos esforzándonos. En 1998, los

datos de la industria del software indicaron que el 26 por 100 de proyectos de software fallaron

completamente y que el 26 por 100 experimentaron un desbordamiento en la planificación y en

el coste. Aunque la proporción de éxito para los proyectos del software ha mejorado un poco,

nuestra proporción de fracaso de proyecto permanece más alto del que debería ser. Para evitar el

fracaso del proyecto, un gestor de proyectos de software y los ingenieros del software que

construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender

los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un

enfoque de sentido común para planificar, supervisar y controlar el proyecto.

Ingeniería de Software II

KRCG -18-

UNIDAD II

PLANIFICACION DE PROYECTOS DE SOFTWARE

2.4.2.1. Observación sobre la Estimación.-

A un destacado ejecutivo se le preguntó una vez por la característica más importante que debe

tener un gestor de proyectos. Respondió: “ ... una persona con la habilidad de saber qué es lo que

va a ir mal antes de que ocurra ...”.

Debemos añadir: “... y con el coraje para hacer estimaciones cunado el futuro no está claro ...”.

La estimación de recursos, costes y planificación temporal de un esfuerzo en el desarrollo del

software requiere experiencia, acceder a una buena información histórica y el coraje de confiar en

predicciones (medidas) cuantitativas cuando todo lo que existe son datos cualitativos. La

estimación conlleva un riesgo inherente y este riesgo el que conlleva a la incertidumbre. Se deben

considerar:

- La complejidad del proyecto: Tiene un gran efecto en la incertidumbre, que es inherente en la

planificación. Sin embargo, la complejidad es una medida relativa que se ve afectada por la

familiaridad con esfuerzos anteriores.

- El tamaño del proyecto: Otro factor importante que puede afectar a la precisión y a la eficiencia

de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia

entre varios elementos del software.

- El grado de incertidumbre estructural: Tiene también efecto en el riesgo de la estimación. En

este contexto, la estructura se refiere al grado en el que los requisitos se han definido, las

facilidad con la que pueden subdividirse funciones, y la naturaleza jerárquica de la información

que debe procesarse.

Ingeniería de Software II

KRCG -19-

La disponibilidad de información histórica tienen una fuerte influencia en el riesgo de la

estimación. Al mirar atrás, podemos emular lo que se ha trabajado y mejorar las áreas en donde

surgieron problemas. Cuando se dispone de las métricas completas del software de proyectos

anteriores , se pueden hacer estimaciones con mayor seguridad; establecer planificaciones para

evitar dificultades anteriores, y así reducir el riesgo global.

El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas por

recursos, coste y planificación temporal.

2.4.2.2. Objetivos de la Planificación del Proyecto.-

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que

permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal. Estas

estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de

software, y deberían actualizarse regularmente a medida que progresa el proyecto. Además las

estimaciones deberían definir los escenarios del “mejor caso” y “peor caso” de forma que los

resultados del proyecto puedan limitarse.

2.4.2.2.1. Ámbito del Software.-

Es la primera actividad de la planificación del proyecto de software, se debe delimitar su

declaración. El ámbito del software describe:

- El control y los datos a procesar

- La función

- El rendimiento

- Las restricciones

- Las interfaces

- La fiabilidad

Ingeniería de Software II

KRCG -20-

2.4.2.2.1.1 OBTENCION DE LA INFORMACIÓN NECESARIA PARA EL AMBITO.-

Al principio de un proyecto de software las cosas siempre están borrosas. Se ha definido una

necesidad y se han enunciado las metas y objetivos básicos, pero todavía no se ha establecido la

información necesaria para definir el ámbito (prerrequisito para la estimación).La técnica

utilizada con más frecuencia para acercar al cliente y al desarrollador, y para hacer que comience

el proceso de comunicación es establecer un reunión o entrevista preliminar. La primera reunión

entre un ingeniero de software (el analista) y el cliente puede compararse a la primera cita entre

adolescentes.

Ninguna persona sabe lo que va ha preguntar, ambos están preocupados por si lo que dicen es

mal interpretado; ambos están pensando hasta donde podrían llegar (probablemente ambos tienen

expectativas diferentes); ambos quieren quitárselo de encima; pero al mismo tiempo quieren que

salga bien.

Gause y Weinberg sugieren que el analista comience haciendo preguntas de contexto libre

(abiertas). Es decir, una serie de preguntas que lleven a:

- Un entendimiento básico del problema

- Las personas que están interesadas en la solución

- La naturaleza de la solución que se desea y la efectividad prevista

PREGUNTAS QUE PODRÍAN FORMULARSE:

- ¿Quién está detrás de la solicitud de este trabajo?

- ¿Quién utilizará esta solución?

- ¿Cuál es el beneficio económico de una buena solución?

- ¿Hay otro camino para la solución?

Las preguntas siguientes permiten que el analista comprenda mejor el problema y que el cliente

exprese sus percepciones sobre una solución:

Ingeniería de Software II

KRCG -21-

- ¿Cómo caracteriza (el cliente) un resultado “correcto” que se generaría con una

solución satisfactoria?

- ¿Con qué problema(s) se afrontará esta solución satisfactoria?}

- ¿Puede mostrarme (o describirme) el entorno en el que se utilizará la solución?

- ¿hay aspectos o limitaciones especiales de rendimiento que afecten a la forma en

que se aborde la solución?

La última serie de preguntas se centra en la efectividad de la reunión, Gause y Weinberg las

llaman “metacuestiones” y proponen la lista siguiente (abreviada):

- ¿Es Ud. La persona apropiada para responder a estas preguntas?

- ¿Son “oficiales” las respuestas?

- ¿Son relevantes mis preguntas para su problema?

- ¿Estoy realizando muchas preguntas?

- ¿Hay alguien más que pueda proporcionar información adicional?

- ¿Hay algo más que debería preguntarle?

La sesión P&R sólo se debería usar para el primer encuentro, reemplazándose posteriormente por

un tipo de reunión que combine elementos de resolución de problemas, negociación y

especificación.

2.4.2.2.1.2 VIABILIDAD.-

Putnam y Myers sugieren, de forma acertada, que el estudio del ámbito no es suficiente. Una vez

que se ha comprendido el ámbito, tanto el equipo de desarrollo como el resto deben trabajar para

determinar si puede ser construido dentro de las dimensiones reflejadas anteriormente (Si es

Viable o Factible de realizarse: Técnicamente, Económicamente, Tiempo, Recursos). Esto es

crucial, aunque es una parte del proceso de estimación pasada por alto a menudo.

2.4.2.3. Recursos.-

Ingeniería de Software II

KRCG -22-

Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo del

software. Entre ellos tenemos

PERSONAS

COMPONENETES DE SOFTWARE REUTILIZABLES/

HERRAMIENTAS DE HARDWARE/SOFTWARE

2.4.2.3.1 RECURSOS HUMANOS.-

El encargado de la planificación comienza elevando el ámbito y seleccionando las habilidades

que se requieren para llevar a cabo el desarrollo. Hay que especificar tanto la posición dentro de

la organización (p.e. Gestor, Ing. De Software Experimentado, etc. ) como la especialidad (p.e.

Telecomunicaciones, Bases de Datos, Cliente/Servidor, etc.). En proyectos relativamente

pequeño una sola persona podrá llevar a cabo todos los pasos de ingeniería del software,

consultando con especialistas siempre que sea necesario.

El número de personas requerido para un proyecto de software sólo puede ser determinado

después de hacer estimación del esfuerzo de desarrollo (p.e. personas -mes).

2.4.2.3.2 RECURSOS DE SOFTWARE REUTILIZABLES.-

La ingeniería de Software basada en Componentes (ISBC) destaza la reutilización – esto es, la

creación y la reutilización de bloques de construcción de software – Dichos bloques de

construcción, llamados compomentes, deben establecerse en catálogos para una consulta más

fácil, estandarizarse para una fácil aplicación y validarse para una fácil integración.

Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a

medida que se avanza con la planificación:

Ingeniería de Software II

KRCG -23-

1. Componentes ya desarrollados: El software existente se puede adquirir de una tercera parte o

provenir de uno desarrollado internamente para un proyecto anterior. Llamados componentes

Comercialmente ya desarrollados (CCYD), estos componenetes están listos para utilizarse en el

proyecto actual y se han validado totalmente.

2. Componentes ya experimentados: Especificaciones, Diseños, Código o Datos de Prueba

existentes desarrollados para proyectos anteriores que son similares al software que se va a

construir para el proyecto actual. Los miembros del equipo de software actual ya han tenido la

experiencia completa en el área de la aplicación representada para estos componentes.

Las modificaciones, por tanto requeridas para componentes de total experiencia, tendrán un

riesgo relativamente bajo.

3. Componentes con experiencia parcial: Especificaciones, Diseño, Código o datos de prueba

existente desarrollados para proyectos anteriores que se relacionan con el software que se va ha

construir para el proyecto actual, pero que requieren una modificación sustancial. Los miembros

del equipo se software actual han limitado su experiencia sólo al área de aplicación representada

por estos componentes.

Las modificaciones, por tanto, requeridas para componentes de experiencia parcial tendrán

bastante grado de riesgo.

4. Componentes nuevos: Los componentes de software que el equipo de software debe construir

específicamente para las necesidades del proyecto. De forma irónica, a menudo se descuida la

utilización de componentes de software reutilizables durante la planificación, llegando a

convertirse en la preocupación primordial durante la fase de desarrollo del proceso de software.

Es mucho mejor especificar al principio las necesidades de recursos del software. De esta forma

se puede dirigir la evaluación técnica de alternativas y puede tener lugar la adquisición oportuna.

Ingeniería de Software II

KRCG -24-

2.4.2.3.3 RECURSOS DE ENTORNO.-

El entorno es donde se apoya el proyecto de software, llamado a menudo Entrono de Ingeniería

de Software (EIS). El hardware proporciona una plataforma con las herramientas (software)

requeridas para producir los productos que son el resultado de un buen práctica de reingeniería

del software. Como la mayoría de las organizaciones de software tienen muchos aspectos que

requieren acceso a EIS, un planificador de proyecto debe determinar la ventana temporal

requerida para el hardware y el software

2.4.2.4 Técnicas de Descomposición.-

2.4.2.4.1 TAMAÑO DEL SOFTWARE .-

En el contexto de la planificación de proyectos, el tamaño se refiere a una producción

cuantificable del proyecto del proyecto. Si se toma un enfoque directo, el tamaño puede medirse

en LDC. Si se selecciona un enfoque un enfoque indirecto, el tamaño se representa como PF.

2.4.2.4.1.1 Tamaño en lógica difusa:

Este enfoque usa técnicas aproximadas de razonamientos que son la piedra angular de la lógica

difusa.

2.4.2.4.1.2 Tamaño de componentes estándar:

El planificador de proyectos desarrolla estimaciones de características del dominio de

información estudiadas en el capítulo anterior (Ver Métricas del PF).

2.4.2.4.1.3 Tamaño de cambio:

El software se compone de un número de componentes estándar que son genéricos para un área

en particular para un sistema de información son: subsistemas, módulos, pantallas, informes,

Ingeniería de Software II

KRCG -25-

programas interactivos, LDC e instrucciones para objetos. El planificador de proyectos estima el

número de incidencias de cada uno de los componentes estándar y utiliza datos de proyectos

históricos para determinar el tamaño de entrega por componente estándar.

2.4.2.4.1.4 Tamaño del cambio:

El enfoque se utiliza cuando un proyecto comprende la utilización de software existente que se

debe modificar de alguna manera como de un proyecto como parte de un proyecto. El

planificador estima el número y tipo de modificaciones que se deben llevar a cabo.

2.4.2.4.2 ESTIMACIONES BASADAS EN PROBLEMAS.-

Las estimaciones de LDC, y PF son técnicas de estimación distintas. El planificador del

proyectos comienza con un enfoque limitados para el ámito del software y desde este estado

intenta descomponer el software en funciones que se pueden estimar individualmente. Para cada

función se estiman las LDC y el PF.

2.4.2.4.2.1 USO DE ESTIMACIÓN BASADA EN LDC.-

Considérese la situación de la una empresa denominada Supermercados KETAL�, la que cuenta

con sucursales en La Paz, Cbba y Sta. Cruz, cuenta en cada sucursal con 20, 30, 40 empleados

respectivamente. La empresa requiere los servicios de consultora en software para el inicio de un

proyecto que permita contar con un sistema integrado que permita el control del inventario

existente de los productos que ofrece, el control de asistencia y sanciones al personal, además

como se cuentan con lectores en código de barra se desea que las ventas se controlen usando el

mismo así como su registro en inventarios, se desea llevar u registro de toda la clientela de modo

que si se tiene alguna promoción éstos resulten primeramente beneficiados, Se desean registrar

los activos fijos que tiene la empresa en cada sucursal, también hacer un seguimiento del record

de trabajo de cada persona de modo que se las pueda categorizar para el pago de su salario,

también en cuanto a ventas se desea realizar un seguimiento de los pedidos y compras realizados

Ingeniería de Software II

KRCG -26-

a los proveedores, así como las ventas al por mayor bajo convenio con instituciones. Realizar el

análisis respectivo usando un estimación basada en LDC.

2.4.2.4.2.2 USO DE ESTIMACIÓN BASADA EB PF.-

Considerando el detalle anterior:

Realizar el análisis respectivo usando un estimación basada en PF

PROBLEMA DE APLICACIÓN:

Estimación basada en el tamaño. Luego de comprendido en ámbito del proyecto, y habiendo

realizado un estudio más detallado se identifican las funciones de software siguientes:

- Control de Inventarios(Productos en stock, ActivosFijos)

- Control del Personal

- Elaboración de Planillas de Sueldo

- Transacciones de productos (Compras, Ventas, Promociones,)

Por experiencia propia se conocen las líneas de código

necesarias para sistemas de Control de Inventarios:

Sopt=3000 Sm=4200 Spes=5000

FUNCION Sopt Sm Spes

Control de Inventarios 3.000 4.200 5.000

Control del Personal 6.000 6.800 8.000

Elaboración de Planillas de Sueldo 4.000 5.500 7.000

Transacciones de productos 7.000 7.800 9.000

Aplicando la fórmula respectiva para hallar la media ponderada (ó Valor Esperado - VE) para

estimar las LDC: VE = (Sopt + 4Sm+Spes)/6

Ingeniería de Software II

KRCG -27-

Por ejemplo para el Control de inventarios, tendremos un valor esperado de:

VE=(3.000 + 4*4.200+5.000) = 24800/6 = 4133

De la misma forma se realizarán otras estimaciones:

FUNCION LDC ESTIMADO

Control de Inventarios 4133

Control del Personal 6867

Elaboración de Planillas de Sueldo 5500

Transacciones de productos 7867

LINEAS DE CODIGO ESTIMADAS 24367

DATOS HISTORICOS

Además por la experiencia obtenida en anteriores proyectos similares se tienen los siguientes

datos históricos: Es posible realizar:

- 1500 LDC/pm (Líneas de código por mes)

- Tarifa Laboral de 7.500 Bs por mes a cada programador incluye impuestos de ley

- Coste total del proyecto: 55.000 Bs

Por lo que cada línea de código costó: 7.500/1.500 = 5 Bs

Esfuerzo estimado es:

Aplicando la regla de tres

7.500Bs ----- ----------------------- 1p erso na

55.000Bs - --------------------------- X personas

Luego: X = (55.000*1)/7.500 = 7 personas

DATOS ESTIMADOS

En el presente proyecto se precisará: Por lo que cada línea de código costó: 7.500/1.500 = 5 Bs

Esfuerzo estimado es:

Ingeniería de Software II

KRCG -28-

Aplicando la regla de tres

1.500 LDC ---- ------------------------ 1p ers ona

24.367 LDC - --------------------------- X personas

Luego: X = (24.367*1)/1.500 = 16 personas

Costo total del Proyecto: 16 *7.500 = 24.000 Bs

2.4.2.5. METRICAS ORIENTADAS A LA FUNCION.-

Este tipos de métricas del software orientadas a la función utilizan una medida de la

funcionalidad entregada por la aplicación como valor de normalización. Por ser la

“funcionalidad” una medida indirecta no es posible medirse directamente, se debe entonces

derivar indirectamente mediante otras medidas directas. Fueron propuestas por primera vez por

Albretch [ALB79], quien sugirió una medida llamada punto de función. Se deben considerar los

siguientes aspectos que a continuación se mencionan en el siguiente esquema:

CALCULO DE PUNTOS DE FUNCION

Para calcular los puntos de función (PF), se utiliza la relación siguiente:

PF = cuenta-total X [0.65 + 0,01 X

Ingeniería de Software II

KRCG -29-

Donde:

cuenta total: Es la suma de todas las entradas PF obtenidas al aplicar los parámetros de la tabla

anterior. Fi (i= 1 al 14) Son valores de ajuste de complejidad según respuestas a las siguientes

preguntas:

1. ¿Requiere el sistema de copias de seguridad y 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 el sistema 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 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 incluidos 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?

Cada una de las preguntas anteriores es respondida usando una nueva escala con rangos desde 0

(no importante o aplicable) hasta 5 absolutamente esencial. Los valores constantes de la ecuación

y los factores de peso que se aplican a las cuentas de dominios de información se

determinan empíricamente.

Una vez calculados los puntos de función, se utilizan de manera análoga a las LDC como forma

de normalizar las medidas de productividad, calidad y otros.

Ingeniería de Software II

KRCG -30-

2.4.2.6. Modelos Empíricos de Estimación (COCOMO).-

Una metodología que se encarga de medir proyectos software es COCOMO. La metodología

COCOMO (COnstructive COst MOdel) se debe a Barry Boehm, y está orientada a líneas de

código. Hay una jerarquía de modelos COCOMO: básico, intermedio y avanzado, la cual se

aplica a tres tipos diferentes de software:

1. Orgánico: proyectos relativamente sencillos, menores de 50.000 líneas de código. Se tiene

experiencia en proyectos similares y se encuentra en un entorno estable.

2. Semiacoplado: proyectos intermedios en complejidad y tamaño. La experiencia en este tipo de

proyectos es variable, y las restricciones intermedias.

3. Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y en un

entorno de gran innovación técnica. Se trabaja con unos requisitos muy restrictivos y de gran

volatilidad.

Dado que sólo se va a emplear una variable para la estimación (la línea de código), se empleará

COCOMO básico, ya que es un modelo univariable estático, con lo que se obtiene una valoración

objetiva del esfuerzo realizado.

Este proyecto será considerado como software orgánico, ya que posee menos de 50.000 líneas de

código. La ecuación del esfuerzo de COCOMO básico tiene la siguiente forma:

E = Esfuerzo = a KLDC b (persona x mes) Donde KLDC es el número de líneas de código,

distribuidas en millares, para el proyecto.

La ecuación del tiempo de desarrollo es:

T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)

Ingeniería de Software II

KRCG -31-

Por su parte los coeficientes a, b, c y d se obtienen empíricamente del estudio de una serie de

proyectos, y sus valores son:

Proyecto de software a b c d Orgánico 2,4 1,05 2,5 0,38

Semiacoplado 3,0 1,12 2,5 0,35

Empotrado 3,6 1,20 2,5 0,32

Tabla "Coeficientes COCOMO"

En el desarrollo de SpiderBot se han codificado 8,2 miles de líneas de código.

Esfuerzo realizado = 2,4 * 8,2 1,05 = 21,9 personas-mes

T = 2,5 * 21,9 0,38 = 8,1 mes

Nº de personas para desarrollar el proyecto = E/T= 21,9 / 8,1 3 personas

La controversia: Líneas de código frente a puntos de función

Existe en el mundo de la Ingeniería del Software una viva polémica sobre qué tipo de métricas

son mejores para evaluar un proyecto: las orientadas a tamaño o las que utilizan puntos de

función.

El centro de controversia está en considerar las líneas de código como medida clave, ya que los

que se oponen a su uso, aducen que las medidas basadas en líneas de código son dependientes del

lenguaje de programación. En cualquier caso esta polémica queda apartada gracias a Casper

Jones, quién creó la siguiente tabla de correspondencia entre algunos de los lenguajes de

programación más conocidos con su número de equivalencia entre líneas de código por punto de

función:

2.4.2.7. La Decisión de Desarrollar – Comprar.-

Ingeniería de Software II

KRCG -32-

Para realizar estimaciones seguras de coste y esfuerzo surge un numero de posible de opciones

como:

Retrasar la estimación mas adelante en el proyecto (obviamente se puede hacer una estimación

cien por ciento fiable después de completar el proyecto) Utilizar "técnicas de descomposición "

relativamente simples para generar las estimaciones del proyecto de software (por ej. Estimación

LDC y PF).

Desarrollar un modelo empírico para el coste y el esfuerzo de software.

Adquirir una o más herramientas automáticas de estimación.

Desdichadamente la primera opción, aunque atractiva no es practica, porque las estimaciones del

coste deben ser proporcionadas de antemano. Las tres opciones restantes son aproximaciones

viables para la estimación del proyecto de software. Las técnicas de descomposición utilizan una

aproximación de "divide y vencerás " para la estimación del proyecto de software. Los modelos

de estimación empíricos pueden utilizarse para completar las técnicas de descomposición y

ofrecer una aproximación de la estimación potencialmente evaluable por ella misma. Las

herramientas automáticas de estimación implementan una o mas técnicas de descomposición o

modelos empíricos

Ingeniería de Software II

KRCG -33-

UNIDAD III

GESTION Y CONFIGURACION DELSOFTWARE

1.4.3.1. Gestión de Configuración del Software.-

La salida del Proceso de Software es información que se puede dividir en tres amplias categorías:

1. Programas de computadoras

2. Productos de trabajo que describen los programas de computadora

3. Datos

Los elementos que comprenden la información producida como parte del proceso de software se

denominan colectivamente configuración del software

Si cada elemento de configuración simplemente condujera a otros elementos habría poca

confusión. Por desgracia, por cualquier razón. De hecho, la primera ley de la ingeniería de

sistemas a firma: “No importa donde se encuentre en el ciclo de vida del sistema, el sistema

cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida”.

1.4.3.2. El proceso de GCS.-

El procesos de Gestión de configuración de Software define una serie de tareas que tiene cuatro

objetivos principales:

1. Identificar todos los elementos que colectivamente definen la configuración del software.

2. Gestionar los cambios uno o más de dichos elementos.

3. Facilitar la construcción de diferentes versiones de una aplicación.

4. Garantizar que la calidad del software se conserva conforme la configuración

evolucionada a lo largo del tiempo.

Ingeniería de Software II

KRCG -34-

Un proceso que logra estos objetivos no necesita ser burocrático y molesto, pero si debe

caracterizarse en una forma que permita que un equipo de software desarrolle respuestas a un

conjunto de preguntas complejas.

1.4.3.1. Identificación de Objetos en la Configuración del Software.-

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. Es posible identificar dos

tipos de objetos básicos y agregados. Un objeto básico es una unidad de información creada por

un ingeniero de software durante el análisis, el diseño, el código o las pruebas. Un objeto

agregado es una colección de objetos básicos y otros objetos agregados.

Cada objeto tiene un conjunto de características distintivas que lo identifican de manera

exclusiva, un nombre, una descripción, una lista de recursos, y una realización.

1.4.3.2. Control de Versiones.-

El control de versiones 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 implementada o está directamente integrado con cuatro capacidades:

Una base de datos del proyecto que guarda todos los objetos de configuración relevantes.

Una capacidad de gestión de la versión que almacena todas as versiones de un objeto de

configuración

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.

Además, los sistemas de control de la versión y de control de cambio con frecuencia

implementan una capacidad de seguimiento de conflictos que permiten al equipo registrar y hacer

Ingeniería de Software II

KRCG -35-

el seguimiento del estado de todos los conflictos destacados que se asocian con cada objeto de

configuración.

1.4.3.3. Control de Cambios.-

Es un contexto moderno de ingeniería de software. Un gran proyecto de ingeniería de software el

cambio incontrolado conduce rápidamente al caos.

Respecto a tales proyecto el control de cambio combina procedimientos humanos y herramientas

automatizadas.

El objeto que se cambiara se colocara en un directorio que controle exclusivamente el ingeniero

de software que realiza el cambio. Un sistema de control de la versión actualiza el archivo

original una vez realizado el cambio.

1.4.3.4. Auditoria de la Configuración.-

La identificación, el control de la versión y el control del cambio ayudan al desarrollador del

software a mantener el orden en lo que de otro modo seria una situación caótica e inestable. Sin

embargo, incluso el mecanismo de control más exitoso sólo sigue un cambio hasta que no se

genera una OCI. La respuesta es doble:

1. revisiones técnicas formales

2. auditoria de la configuración del software

Una auditoria de configuración del software complementa la revisión técnica formal al abordar

las siguientes preguntas:

1. Se han incorporado modificaciones adicionales

Ingeniería de Software II

KRCG -36-

2. Se ha realizado un revisión técnica formla para evaluar la corrección técnica

3. Se ha seguido el proceso de software

4. Se han especificado la fecha y el autor del cambio

5. Se han seguido los procedimientos de GCS para destacar el cambio

6. Todos los ECS relacionados se han actualizado

1.4.3.5. Informes de Estado.-

El informe de estado es una tarea de GCS que responde las siguientes preguntas:

1. ¿que ocurrió?

2. ¿quien lo hizo?

3. ¿cuándo ocurrió?

4. ¿qué otra cosa será afectada?

Cada vez que se realiza una auditoria de la configuración de los resultados se reportan como parte

de la tarea IEC. El resultado del IEC es posible colocarlo en una base de datos en línea o en un

sitio web, de modo que los desarrolladores y los encargados del mantenimiento del software

pueden tener acceso a la información del cambio mediante categorías clave.

Ingeniería de Software II

KRCG -37-

UNIDAD IV

PROCESO DEL SOFTWARE Y METRICAS DE PROYECTOS

2.4.4.1. Modelos de mejora CMM.-

Ofrece un modelo de cinco pasos para la evaluación del proceso que incluye la iniciación, el

diagnostico, el establecimiento, la acción y el aprendizaje. Ofrece una técnica de diagnóstico para

evaluar la madurez relativa de un organización de software mediante la ABC MPI como base

para la evaluación

2.4.4.2. ISO 9001- ISO 9000 – ISO 9004-2.-

Es un estándar genérico que se aplica a cualquier organización que desee mejorar la calidad

general de los productos, sistemas o servicios que provee. Por lo tanto, el estándar se aplica de

modo directo a compañías y organización de software.

Debido a que el ISO se usa de manera ampliada en el ámbito internacional se examinará con

brevedad en los párrafos que sigue:

El ISO ha adoptado un ciclo que se aplica a los elementos de gestión de calidad de un proyecto de

software. Dentro de un contexto de software establece los objetivos, las actividades y tareas del

proceso necesarios para conseguir un software de alta calidad y una satisfacción del cliente.

2.4.4.3. PSP.-

Cada desarrollador utiliza algún proceso para construir un software de computadoras. El proceso

puede ser fortuito, puede cambiar a diario, puede no ser eficiente, efectivo o hasta exitoso, pero

existe un proceso. El modelo PSP define cinco actividades del marco de trabajo: Planeación,

Diseño de lato nivel, revisión del diseño de altos nivel, desarrollo y análisis de resultados.

Ingeniería de Software II

KRCG -38-

El PSP destaca la necesidad que tiene cada ingeniero de software de identificar los errores desde

el principio y la importancia de entender los tipos de errores que suele cometer. Eso se lleva

acabo mediante una actividad de evaluación rigurosa aplicada en todos los productos de trabajo

que genera el ingeniero de software.

Ingeniería de Software II

KRCG -39-

UNIDAD V

MANTENIMIENTO Y DOCUMENTACION

2.4.5.1. Ingeniería y Mantenimiento.-

El mantenimiento de software explica casi el 60 por ciento del esfuerzo que emplea una

organización de desarrollo y el porcentaje continua elevándose conforme se produce

mas software. Los lectores con escaso conocimientos sobre el tema podrían

preguntarse por que se requiere tanto mantenimiento y por qué se dedica tanto

esfuerzo

Otra razón respecto del problema del mantenimiento del software es la movilidad del

personal. Es probable que el equipo de software que realizó el trabajo original ya no

este. Peor aún, las generaciones subsecuentes de personal han modificado el sistema

y lo han dañado. En la actualidad tal vez no haya nadie que tenga algún conocimiento

del sistema heredado.

El cambio es inevitable cuando se construyen sistemas basados en computador; en

consecuencia, se deben desarrollar mecanismos para evaluar, controlar y efectuar

motivaciones.

Ingeniería de Software II

KRCG -40-

UNIDAD VII

INGENIERIA WEB

2.4.7.1. Los Atributos de Aplicaciones basadas en Web.-

En la actualidad los WebApp han mejorado o evolucionado en sofisticadas herramientas de

computación que no solo proporcionan función por si misma al usuario final, sino que también se

han integrado con bases de datos comparativas y aplicaciones de negocio,

Existe como debate en cuanto a que los WebApps, son diferentes a las muchas categorías de

software informático. En la gran mayoría de las WebApps se encuentran los siguientes atributos:

→ Intensidad de red

→ Concurrencia

→ Carga Impredecible

→ Desempeño

→ Disponibilidad

→ Gobernada por los datos

→ Sensibilidad la contenido

→ Evolución continua

→ Inmediatez

→ Seguridad

→ Estética

2.4.7.2. El proceso IWEB.-

Los atributos y aplicaciones basada en la Web tiene una profunda influencia sobre el proceso

IWeb que se elija. La intensa naturaleza de las aplicaciones de la red en este dominio sugiere una

diversa población de usuarios. Con frecuencia son conductoras de contenido, con énfasis en la

Ingeniería de Software II

KRCG -41-

estética, es probable que proyecten actividades de desarrollo paralelas dentro del proceso e

involucren un equipo de personal tanto técnico como lego.

Se toma en cuenta también los siguientes procesos: Comunicación, Planeación, Modelado,

Construcción y Despliegue.

2.4.7.3. Un Marco de Trabajo para la IWEB.-

Cualquiera de los modelos de proceso ágil se pueden aplicar de manera exitosa como un proceso

IWeb. El marco de trabajo del proceso que se presenta aquí es una amalgama de los principios e

ideas tratados anteriormente.

La efectividad de cualquier procesos de ingeniería depende de su adaptabilidad. Esto es, la

organización del equipo de proyecto, los modos de comunicación entre miembros del equipo, las

actividades de ingeniería y las tareas que deben realizarse, la información que se recolecta y cree,

y los métodos empleados para producir un producto de lata calidad deben estar adaptados a la

gente que realiza el trabajo, el plazo y las restricciones del proyecto, y al problema que quiere

resolver. Antes de definir un marco de trabajo de proceso para IWeb Se debe reconocer:

1. Las WebApps con frecuencia se entregan de manera incremental

2. Los cambios ocurrirán frecuentemente

3. Los plazos son cortos

2.4.7.4. Formulación y Análisis de Sistemas Basados en Web.-

La formulación de sistemas y aplicaciones basadas en Web representa una secuencia de acciones

de Ingeniería Web que comienza con la identificación de las necesidades del Negocio, se mueve

hacia una descripción de los objetivos de la WebApps, define grandes características y funciones

y realiza la recopilación de requisitos que conducen al modelo de un desarrollo de análisis.

Ingeniería de Software II

KRCG -42-

La formulación permite que los clientes y el equipo de ingeniería de software establezcan un

conjunto común de metas y objetivos para la construcción de un WebApps. También identifica el

ámbito del esfuerzo de desarrollo y proporciona un medio para determinar un resultado exitoso.

Basándose en las siguientes preguntas:

1. ¿Cuál es la principal motivación para la WebApp?

2. ¿Cuáles son los objetivos que debe satisfacer la WebApp?

3. ¿Quién usara la WebApp?

2.4.7.5. Diseño para Aplicaciones basadas en Web.-

Toda interfaz del usuario debe presentar las siguientes características: fácil de usar, fácil de

aprender, fácil de navegar, intituiva, consistente , eficiente, libre de errores y funcional. Debe

ofrecer al usuario final una experiencia gratificante. Los conceptos, principios y método de

diseño de la interfaz brindan al ingeniero web las herramientas requeridas para lograr esta lista de

atributos.

→ Diseño de la Interfaz

→ Diseño estético

→ Diseño de contenido

→ Diseño de navegación

→ Diseño arquitectónico

→ Diseño de componentes

Ingeniería de Software II

KRCG -43-

UNIDAD VIII

REINGENIERIA

2.4.8.1. Reingeniería de Procesos de Negocios.-

La reingeniería de procesos de negocio rebasa el ámbito de las tecnologías de la información y de

la ingeniería del software. Entre la muchas definiciones (la mayoría un tanto abstractas).

Como la mayoría de las actividades de ingeniería, la reingeniería el proceso de negocio es

iterativa. Las metas del negocio y los proceso con que se logran se deben adaptar a un entorno de

negocio cambiante. El modelo define seis actividades:

Definición del negocio: Las metas del negocio se identifican desde el contexto de cuatro

controladores clave.

Identificación el procesos: Se identifican lo procesos cruciales para mejorar la meta precisa en la

definición del negocio. Luego podría clasificarse de acuerdo con su importancia, necesidades de

cambio o en cualquier otro forma que sea adecuada para la actividad de reingeniería.

Evaluación de proceso: El proceso existente se analiza y mide exhaustivamente. Se identifican las

tareas del proceso.

Especificación y diseño del proceso: Con base en la retroalimentación obtenida durante las

primeras tres actividades de la RPN; se preparan casos de uso para cada procesos que será

rediseñado.

Elaboración de prototipos: Un proceso de negocio rediseñado debe convertirse en prototipo antes

de que sea integrado por completo en el negocio. Esta actividad “prueba” el proceso de modo que

puedan llevarse a cabo refinamientos.

Ingeniería de Software II

KRCG -44-

Refinamiento y particularización: Con base en la retroalimentación del prototipo, el proceso de

negocio se refina y luego se particulariza dentro de un sistema de negocio.

2.4.8.2. Reingeniería del Software.-

Una aplicación ha cubierto las necesidades de negocios de una compañía durante 10 a 15 años.

Durante este lapso se ha corregido, adaptado y mejorado muchas veces. Ahora la aplicación es

inestable. Todavía funciona pero, cada vez que se intenta un cambio, ocurren efectos colaterales,

inesperados y serios y la aplicación todavía tiene que evolucionar.

2.4.8.3. Ingeniería Inversa.-

La ingeniería inversa de datos ocurre en diferentes grados de abstracción y con frecuencia es la

primera tarea de reingeniería. Al nivel del programa, las estructuras de datos internos del

programa usualmente deben someterse a reingeniería inversa como parte de un esfuerzo global de

reingeniería. En el nivel del sistema las estructura globales de alto con frecuencia se someten a

reingeniería para ajustarlo con lo nuevo paradigma de gestión de bases de datos.

2.4.8.4. Reestructuración.-

La reestructuración de software modifica el código fuente a los datos con la finalidad de la

adecuación para futuros cambios. En general, la reestructuración no modifica la arquitectura

global del programa. Tiende a enfocarse sobre los problemas de diseño de los módulos

individuales y en las estructuras de datos locales definidos dentro de los módulos. Si se trabajo de

reestructuración se extienden más allá de las fronteras del módulo y abarca la arquitectura del

software, la reestructuración se convierte en ingeniería avanzada.

2.4.8.5. Ingeniería Directa (Forward Engineering).-

Para reliar la ingeniería directa tenemos los siguientes pasos:

Ingeniería de Software II

KRCG -45-

1. Se puede trabajar modificaciones tras modificaciones, luchando con el diseño implícito y el

código fuente para implementar los cambios necesarios.

2. Se puede intentar comprender el extenso funcionamiento interno del programa con el propósito

de realizar modificaciones,

3. Se puede rediseñar, recodificar y probar aquellas porciones del software que requieran

modificaciones mediante la aplicación de un enfoque de ingeniería del software en todos los

segmentos revisados.

4. Se puede rediseñar, recodificar y probar el programa completamente empleando herramientas

de reingeniería como auxiliares para comprender el diseño actual.

2.4.8.6. Economía de la Reingeniería.-

En un mundo perfecto, cualquier programa al que no se le pudiera dar mantenimiento reiterado

seria retirado inmediatamente, y seria sustituido por aplicaciones de ,mayor calidad con

reingeniería desarrolla empleando modernas practicas de ingeniería del software. Sin embargo, se

vive en un mundo de recursos limitados: La reingeniería demanda recursos que puedan utilizarse

para otros propósitos del negocio.

Ingeniería de Software II

KRCG -46-

Ingeniería de Software II

KRCG -47-

PARTE III

LECTURAS COMPLEMENTARIAS

3.1. Lecturas complementarias.-

Para cada clase se van a indicar dos tipos de lecturas: las recomendadas y las opcionales. Las

recomendadas son aquellas que creemos que mejor representan el contenido de la clase. Las

opcionales profundizan el tema y son material de referencia. Las únicas lecturas obligatorias de la

materia son los “papers fundacionales”. La asistencia a clases con el soporte de los slides usados

(que se envían a la lista de estudiantes antes de cada clase) deberían ser suficientes para contar

con material de estudio para los exámenes.

3.2. Ingeniaría de Software.-

La Ingeniería del Software trata con la problemática del desarrollo de software a gran escala, y

esto abarca tanto temas técnicos como de gestión. Esta materia funcionará de manera integrada

con Ingeniería de Software I para brindarles un panorama de los procesos y técnicas que pueden

ser usadas en este tipo de proyectos. La definición formal de Ingeniería de Software según la

IEEE es: La aplicación de enfoque sistemático, cuantificable y disciplinado al desarrollo,

operación y mantenimiento de Software. En la materia trataremos de entender a la Ingeniería de

Software en el contexto de su evolución histórica y de aprender conceptos que sean válidos por

varios años.

3.3. Calidad de Software.-

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su

utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad,

mantenibilidad, portabilidad, usabilidad, seguridad e integridad.

Ingeniería de Software II

KRCG -48-

La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un

software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas";

un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras

que un producto de software para ser explotado durante un largo período (10 años o más),

necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y

perfeccionamiento durante el tiempo de explotación.

La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar

muy costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es

imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas

las etapas del ciclo de vida del software.

3.4. Obtener Software de Calidad.-

La obtención de un software con calidad implica la utilización de metodologías o procedimientos

estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la

filosofía de trabajo, en áreas de lograr una mayor confiabilidad, mantenibilidad y facilidad de

prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el

control de la calidad del software.

La política establecida debe estar sustentada sobre tres principios básicos: tecnológico,

administrativo y ergonómico.

1. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.

2. El principio administrativo contempla las funciones de planificación y control del desarrollo

del software, así como la organización del ambiente o centro de ingeniería de software.

3. El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software,

pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

Ingeniería de Software II

KRCG -49-

Controlar la calidad de Software.-

Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores

o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo

que no se puede medir".

Las cualidades para medir la calidad del software son definidas por innumerables autores, los

cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas

de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes

criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC,

de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor,

criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que

conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad

del software y definen dos categorías de métricas: de complejidad de programa o código, y de

complejidad de sistema o estructura.

Todos los autores coinciden en que el software posee determinados índices medibles que son las

bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez

seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los

siguientes pasos:

Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación,

complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.

Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de

software es necesario definir los indicadores y sus magnitudes.

Crear o determinar los métodos de valoración de los indicadores: métodos manuales como

cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas

automatizadas para medir los criterios de cálculo.

Definir las regulaciones organizativas para realizar el control: quiénes participan en el control

de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

Ingeniería de Software II

KRCG -50-

A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto

para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se

dedique a la investigación, producción y comercialización del software, el cual incluye la

elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una

Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas

manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS,

de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.

Ingeniería de Software II

KRCG -51-

Ingeniería de Software II

KRCG -52-

PARTE IV

BIBLIOGRAFIA

4.1. Bibliografía.-

Permitirá al estudiante complementar sus conocimientos, sobre la materia y

conceptualizar y perfeccionar las definiciones dadas.

4.2. Bibliografía Complementaria.-

1. Ingeniería del Software: Un enfoque práctico, Roger S. Pressman, McGraw Hill,

quinta edición. (especialmente indicado para alumnos que no han cursado antes

una asignatura de Ingeniería del Software, o para repaso de esta disciplina).

2. Requirements Engineering. Processes and Techniques, Kotonya, G and

Sommerville, I, John Wiley & Sons. 1998

3. Mastering the requirement process. Robertson, S and Robertson, J, Addison-

Wesley. 1999

4. Software Requirements, Karl E. Wiegers, Microsoft Press, 1999

AUTOR

OBRA

LUGAR DE EDIC.

EDITORIAL

AÑO

Pressman Roger S.

Ingeniería de Software Un Enfoque Práctico

Sexta Edición Interamericana de España, S.A.U.

McGraw - Hill

2004

Pressman Roger S.

Ingeniería de Software Un Enfoque Práctico

Quinta Edición Interamericana de España, S.A.U.

McGraw - Hill

2002

Pressman Roger S.

Ingeniería de Software Un Enfoque Práctico

Cuarta Edición Interamericana de España, S.A.U.

McGraw - Hill

2002

Sodhi, Jag

Software Engineering Methods Management and CASE

McGraw – Hill

1991

Sommerville

Software Engineering

McGraw – Hill

1997

Ingeniería de Software II

KRCG -53-

5. Software Engineering (6th edition). Sommerville, I, Pearson Education Limited.

2001

6. “Requirements Engineering: A Framework for understanding”, R.J. Wieringa,

John Wiley&Sons LTD., 1996

7. Software Requirements, A. Davis, Prentice Hall, 1.993

8. REQUIREMENTS ENGINEERING: a good practice guide. Sommerville,

I.Sawyer, Wiley, 30 APR 1997

9. The Unified Modeling Language, G. Booch, J. Rumbaugh, I. Jacobson, Addison-

Wesley 1999

10. Formal Methods can deliver Provable Software, Nina Hall. Scientific Computing

World. March 1995.

11. El detalle de las lecturas de cada clase está en el detalle de teóricas. Algunos de

los libros importantes referenciados de esa página son:

12. Software Architecture in Practice, 2nd Edition / Len Bass, Paul Clements, Rick

Kazman / Addison-Wesley (2003), ISBN: 0321154959

13. Documenting Software Architectures: Views and Beyond/ Paul Clements (Editor),

Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord,

Judith Stafford / Addison Wesley Professional,2004

14. Software Architecture: Perspectives on an Emerging Discipline. Mary Shaw ,

David Garlan. Prentice Hall, 1996.

Ingeniería de Software II

KRCG -54-

Ingeniería de Software II

KRCG -55-

PARTE V

GLOSARIO

PALABRA DESCRICPCION

SOFTWARE Conjunto de programas informáticos interrelacionados

INGENIRIA

PROYECTO Conjunto de escritos, cálculos o dibujos que se hacen para dar idea

sobre algo

CALIDAD Circunstancia a que se somete una acción o sorpresa. Es muy

importante mantener la calidad de software durante toda la etapa

del ciclo debida del proyectos de software

METODOS Modo de obrar con una orden

TECNICAS Conjunto de recursos y procesos de una arte o ciencia.