dossier ingenieria de software ii - aula...
Post on 29-Sep-2018
212 Views
Preview:
TRANSCRIPT
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 -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 -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 -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 -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 -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.
top related