Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Procesosdeingenieriadelsoftware 090808100843 Phpapp01
Procesosdeingenieriadelsoftware 090808100843 Phpapp01
1.INTRODUCCIÓN
El proceso de ingeniería del software puede ser visto desde dos
enfoques: El primero: ciclo de vida del software, procesos durante
la adquisición, desarrollo, mantenimiento y cierre y el segundo
con definición, implementación, evaluación, manejo, cambio y
mejora del ciclo de vida del software
2.2.1.2Modelo QIP
2.3.1.2.2Desventajas
• No hay que usar en casos experimentales ya que no
puede funcionar.
• La gestión de desarrollo que es lenta porque da vueltas
hasta que el usuario este de acuerdo, o se pongan
limites.
• Imposibilidad de conocer a priori el tiempo de
desarrollo
• Es muy difícil y complejo realizarlo
2.3.1.3Iterativo e Incremental
2.3.1.4En espiral
Las ventajas y desventajas de este modelo son [30] [32]: El modelo en Espiral que se muestra en la Figura 8, es un modelo
de proceso de software evolutivo que combina la naturaleza
iterativa de construcción de prototipos con los aspectos
2.3.1.3.1Ventajas controlados y sistemáticos del modelo lineal secuencial.
• Se evitan proyectos largos y se entrega “algo de valor”
a los usuarios con cierta frecuencia. Según Wikipedia [31], las actividades de este modelo se
• El usuario se involucra más. conforman en una espiral, en la que cada bucle o iteración
• Mayor retorno de la inversión. representa un conjunto de actividades. Las actividades no están
fijadas a priori, sino que las siguientes se eligen en función del
• Disminuyen riesgos
análisis de riesgo, comenzando por el bucle interior. El software
• Se puede cambiar los requerimientos pues como nos se desarrolla en una serie de versiones incrementales.
basamos en una versión a esta la aumentamos o la
modificamos.
• Reduce costos, si algo sale mal solo volvemos a la • Durante las primeras iteraciones, la versión incremental
antigua versión y comenzamos de nuevo. podría ser un modelo en papel o un prototipo.
• Al usuario se le entrega parte del producto, es decir una • Durante las últimas iteraciones, se producen versiones
versión con la cual el puede trabajar. cada vez más completas del sistema diseñado.
2.3.1.4.1Ventajas
• No necesita una definición completa de los requisitos
para empezar a funcionar.
• Al entregar productos desde el final de la primera
iteración es mas fácil validar los requisitos
• El riesgo en general es menor, porque si todo se hace
mal , solo se ha perdido el tiempo y recursos invertidos
en una iteración
• El riesgo de sufrir retrasos es menor ya que al
identificar los problemas en etapas tempranas hay
tiempo de subsanarlos,
• El análisis del riesgo se hace de forma explícita y clara.
Une los mejores elementos de los restantes modelos.
• Reduce riesgos del proyecto
• Incorpora objetivos de calidad Figura 9. Fases del RUP [35]
• Integra el desarrollo con el mantenimiento, etc.
2.3.2.1.2Fase de Inicio
2.3.1.4.2Desventajas
• Es difícil evaluar los riesgos
En esta fase se define el modelo del negocio y el alcance del
• Necesita de la participación continua por parte del
proyecto, se identifican los autores y casos de usos y se diseñan
cliente
los casos de uso esenciales.
• Cuando se subcontrata hay que producir previamente
una especificación completa de lo que se necesita y esto Los objetivos son:
lleva tiempo. • Establecer el ámbito del proyecto y sus limites
• Genera mucho tiempo en el desarrollo del sistema • Encontrar los casos de uso críticos del sistema, los
• Modelo costoso requiere experiencia en la escenarios básicos.
identificación de riesgos • Mostrar una arquitectura para los escenarios principales.
• Estimar el coste en recursos y tiempo en todo el
2.3.2Metodologías de desarrollo de software proyecto.
• Estimar los riesgos, las fuentes de incertidumbre.
2.3.2.1RUP Los resultados de la fase son:
Los resultados de la fase de construcción deben ser: La metodología MSF (Microsoft Solucion Framework) [40], es
flexible e interrelacionada con una serie de conceptos, modelos y
• Modelos completos(casos de uso, análisis, diseño,
prácticas de uso, y guías para diseñar y desarrollar soluciones
despliegue e implementación)
empresariales de una manera que asegura que todos los elementos
• Arquitectura integra.
del proyecto tal como gente, procesos y herramientas, puedan ser
• Riesgos presentados mitigados exitosamente conducidos.
• Plan del proyecto para la fase de transición.
• Manual inicial de usuario.
MSF no sólo es aplicable al desarrollo de proyectos de desarrollo,
• Prototipo operacional.
también es aplicable a otros proyectos de TI, como el despliegue
• Caso del negocio actualizado. o proyectos de infraestructura o redes. MSF no fuerza al
desarrollador a utilizar una metodología específica (Cascada,
2.3.2.1.5Fase de Transición ágil), pero les permite decidir qué método utilizar.
2. Planeación: donde se desarrollan los procesos de MSF para Metodologías de Desarrollo Ágil (MSF4ASD)
diseño conceptual, lógico y físico, así como la MSF para Metodologías de Desarrollo Ágil es un proceso de
especificación funcional. La persona encargada de desarrollo manejado por escenarios, basado en contexto, que
funciones de administración de programas toma el utiliza muchas de las ideas incorporadas en Team System
mando durante esta fase y crea planes de proyecto que (herramientas de Microsoft). Este proceso incorpora las prácticas
tratan el desarrollo, la comunicación y otras tareas; y probadas desarrolladas en Microsoft con respecto a los
cada función proporciona los datos para crear la requerimientos, diseño, seguridades, rendimiento y pruebas
programación del proyecto. (testing) [42].
MSF para metodologías de desarrollo ágil presenta una guía
3. Desarrollo: El equipo crea y prueba la solución. La
muy recomendable a los Desarrolladores y Gestores de proyectos
persona encargada de funciones de desarrollo toma el
de software que pueden adaptarla a la metodología de su empresa,
mando durante esta fase.
en la que incluye documentos de ejemplo, plantillas, archivos en
4. Estabilización: El equipo crea la solución piloto en blanco de Project, Excel y Word para la administración de
preparación para el lanzamiento de producción. La proyectos, requerimientos, seguridad y pruebas.
persona encargada de las funciones de prueba toma el
mando durante esta fase. MSF para CMMI (MSF4CMMI)
EL MSF4CMMI para CMMI es una metodología formal para la
5. Instalación.
ingeniería de software es un proceso de mejora que proporciona a
las organizaciones los elementos esenciales del proceso continuo
6. Soporte
de mejora que den lugar a una reducción de Ciclo de vida del
Las características más relevantes del MSF son: Desarrollo de Software, la mejora de la capacidad para satisfacer
• Adaptable: Es parecido a un compás, usado en las metas de costos y el calendario, la construcción de productos
cualquier parte como un mapa, del cual su uso es de alta calidad.
limitado a un específico lugar. El MSF4CMMI se ha ampliado una orientación MSF4ASD con
una formalidad adicional, evaluación, verificación y auditoría
[43].
Essential Unified EssUP
Una de las ventajas de utilizar el proceso CMMI es el estándar de Process
evaluación por la que uno puede comparar la capacidad de
Feature Driven FDD De Luca & Coad
desarrollar software en otras organizaciones.
Development 1998 Palmer &
Felsing 2002,
2.3.2.3Modelo Ágil Lean
Development LD
Charette 2001,
El Modelo de Desarrollo Ágil se originó a mediados de los años Mary y Tom
1990 y se podría decir que fue extraído del modelo de desarrollo Poppendieck
en cascada, pues éste último era visto como burocrático, lento, Programación XP Beck 1999
degradante e inconsistente por lo exigente y muy estructurado en Extrema
sus formas de desarrollo de software que sin embargo realizaban
un trabajo eficiente. Scrum Scrum Sutherland 1994
En el año 2001, miembros prominentes de la comunidad de la Schwaber 1995
industria del software se reunieron en Sonwbird, Utah, y
Microsoft MSF Microsoft 1994
adoptaron el nombre de "Metodologías ágiles"[36].
Solutions
El modelo de desarrollo ágil es un paradigma de Desarrollo de Framework
Software que utiliza procesos ágiles (pequeñas y frecuentes
entregas con ciclos rápidos) enfocados en la gente y resultados, se Rapid RAD McConnell 1996
podría decir que es: Development
2.3.2.3.2Ventajas:
2.3.2.3.1Metodologías Agiles
Hacemos mención de algunas metodologías ágiles de desarrollo • Métodos de comunicación más eficaces en este tipo de
de software en la Tabla 1, estas metodologías son: metodologías.
• Es posible identificar y atacar los problemas más
críticos y controversiales del proyecto en las primeras
Tabla 1. Lista de Metodologías Ágiles etapas.
Metodología Acrónimo Creación • El cliente comenzará a ver su sistema lo más pronto
posible y verificar que se están cubriendo sus
Adaptive ASD Highsmith 2000 requerimientos de forma adecuada.
Software • Entrega de resultados tangibles en etapas tempranas del
Development proyecto.
Agile Modeling AM Ambler 2002
2.3.2.3.3Desventajas:
Agile RUP dx Booch, Martin,
• Proceso menos controlado y con pocos principios.
Newkirk 1998
• No existe contrato tradicional o al menos es bastante
Crystal Methods CM Cockbum 1998 flexible.
• Grupos pequeños, trabajando en el mismo sitio y no documentación de actividades de mantenimiento de
distribuidos adecuadamente. software.
• Menos énfasis en la arquitectura del software, siendo
ésta primordial para el éxito del proyecto de software. 2.3.3.2.2 ISO 14764:1998
2.3.2.3.4Uso de Metodologías Éste estándar internacional como es ISO 14764 [34] aclara los
requerimientos para el Proceso de Mantenimiento del Software.
El surgimiento de estas revolucionarias metodologías que no solo El Mantenimiento del Software es un proceso primario en el ciclo
nacen para el desarrollo de sistemas software sino para el manejo de vida de un producto software. En muchos proyectos,
o desarrollo de productos los incrementos en adeptos se presentan especialmente aquellos que tienen una vida larga, el
gradualmente con el tiempo y las tecnologías. En la Figura 11, se mantenimiento del software es con seguridad una de las
muestra [38] consideraciones más importantes del proyecto. Por esta razón es
necesario ser capaces de corregir los fallos que se encuentran
durante su manejo.
2.3.3.3ISO 9001-2000
Figura 11. Uso de Métodos Ágiles [38] El estándar o norma ISO 9001:2000 (Quality management
systems –Requirements) que significa Calidad del manejo de
requerimientos del sistema, especifica los requerimientos para el
2.3.3Procesos del ciclo de vida del Software manejo de la calidad de un sistema organizacional proveyendo
requerimientos de los productos y satisfacción del cliente.
Primario se basa en la calidad del software, y segundo en los
2.3.3.1Estándar IEEE 1074 procesos de ingeniería del software.
El estándar IEEE 1074 [7] y [8], es un estándar para la
generación de los que rigen el proceso de desarrollo de software y
mantenimiento de un proyecto. Este estándar requiere la selección 2.4Evaluación de Procesos
de proyectos de software y modelos de ciclo de vida, basado en la
misión, visión, metas y recursos de las organizaciones. También 2.4.1Modelos de Evaluación del proceso
describe las diferentes actividades que van a ser asignada en el
modelo seleccionado. Sin embargo, este estándar no es una guía
2.4.1.1CMMI
de instrucción. También puede ser utilizado para desarrollar los
procesos de organización para apoyar el desarrollo de software y CMMi intenta proveer una guía para los procesos. Las áreas
procesos que tiene una única función dentro de un proyecto. específicas relacionadas son:
2.3.3.2Procesos de Mantenimiento:
• Calidad de proceso y producto
2.3.3.2.1 IEEE 1219-1998
• Verificación del proceso
• Validación del proceso
El estándar IEEE 1219-1998 [9], se basa en procesos iterativos
para ejecutar y manejar el mantenimiento de software. Hubo inicialmente algún debate sobre si la ISO 9001 o CMMi
Los procesos están aplicados a: podrían ser usadas por los ingenieros del software para asegurar la
calidad. Este debate fue publicado y como resultado la decisión
• Planeación de mantenimiento mientras el producto está
ha sido tomada que los dos son complementarios y que
desarrollándose.
teniendo certificación ISO 9001 puede ayudar grandiosamente en
• Planeación y ejecución de mantenimiento para altos niveles de madurez del CMMi. [6]
productos de software existente. El modelo CMMI es un modelo de calidad del software que
• Aplica cualquiera de los modelos del ciclo de vida clasifica las empresas en niveles de madurez. Estos niveles sirven
disponibles. para conocer la madurez de los procesos que se realizan para
• Estándares prescriben los requerimientos para procesos, producir software.
control y manejo de la planeación, ejecución y
2.4.2Métodos de evaluación del proceso
Estos medos fueron desarrollados por el SW-CMM • Planificar el Proceso de Medición que implica tareas
como:
2.4.2.1CBA-IPI o Obtener características de la Organización.
o Identificar las necesidades de la Información.
El CBA-IPI [39], es un método de evaluación basado en CMM o Seleccionar las medidas.
sirve para mejorar internamente los procesos, fue desarrollado por o Definir los procedimientos de recolección de
el Softare Engneer Institute de la Universidad Carnegie Mellon. datos, análisis e informes.
Es una herramienta de diagnostico que permite a las o Definir los criterios de evaluación de los
organizaciones y proyectos el poder determinar las fortalezas y de productos de información y el proceso de
sus procesos de desarrollo de software, utiliza el método de medición.
madurez de capacidades para software desarrollado por el SEI o Revisar, aprobar y proporcionar recursos para
las tareas de medición.
2.4.2.2SCAMPI o Adquirir y utilizar tecnologías de apoyo.
Los métodos SCAMPI son grandes torres de evaluación CMMi. • Realizar el Proceso de Medición que implica tareas
Las actividades ejecutadas durante una evaluación, la distribución como:
de esfuerzo en estas actividades como la atmosfera durante una o Integrar los procedimientos,
evaluación son diferentes cuando son de mejora para la o Recoger los datos,
adjudicación de un contrato. o Analizar los datos y desarrollar productos de
información.
o Comunicar los resultados.
2.5Medidas de Productos y Procesos
• Evaluar la Medición que implica tareas como:
o Evaluar productos de información y el
La medición de software es una disciplina relativamente joven, proceso de medición,
consenso general sobre la definición exacta de los conceptos y o Identificar las mejoras potenciales.
terminología que maneja, aunque términos clave de medición del
software y métodos de medición han sido definidos en la ISO/IEC
15939 basados en el vocabulario ISO internacional de metrología. 2.5.1Medición del Proceso: ISO 15539-02
A pesar de todo, los lectores encontrarán diferencias
terminológicas en la literatura; por ejemplo, el término “métrica” La medición del Proceso significa recoger, analizar e interpretar
se utiliza a veces en vez de “medida”. En la Figura1 se muestra el información cuantitativa sobre nuestros procesos, para identificar
ámbito de ISO/IEC 15939: [10] las fuerzas y las debilidades de los mismos y para evaluarlos
después de que hayan sido implementados y/o cambiados.
Muchos son los propósitos que abarca la medición del Proceso en
el presente caso de estudio nos centraremos en la medición del
proceso para gestionar un proyecto de software enfocado en la
implementación y cambio del proceso.
• Las dos primeras métricas ayudan a descubrir si los Características de calidad del ISO 9126-1:2001:
cambios en el proceso mejoran la eficiencia de un
• Funcionalidad: conjunto de atributos que se relacionan
proceso. Por ejemplo, se puede medir el tiempo y
con la existencia de un conjunto de funciones y sus
esfuerzo necesarios para moverse de un hitos fijo a otro,
propiedades específicas. Las funciones son aquellas que
como la aceptación de requerimientos, terminación de
satisfacen lo indicado o implica necesidades. Las
un diseño arquitectónico, etc. Esos valores ayudan a
subcaracterísticas son: Idoneidad, Exactitud
identificar áreas de mejora en el proceso. Una vez
Interoperabilidad, Seguridad, Cumplimiento de normas.
introducidos los cambios, las mediciones posteriores
indican si los cambios han sido positivos. • Fiabilidad: conjunto de atributos relacionados con la
capacidad del software de mantener su nivel de
• El número de ocurrencias de un Evento Tienen
prestación bajo condiciones establecidas durante un
influencia directa en la calidad del software. Por
período de tiempo establecido. Las subcaracterísticas
ejemplo, incrementar el número de defectos
son: Madurez, Tolerancia a fallas, Facilidad de
descubiertos al cambiar el proceso de revisión del
Recuperación, Conformidad de Fiabilidad.
código probablemente se reflejará en una mejora de la
calidad del producto, aunque tiene que confirmarse por • Usabilidad: conjunto de atributos relacionados con el
mediciones posteriores del producto. esfuerzo necesitado para el uso, y en la valoración
Se describiría a las salidas de los procesos como: calidad del individual de tal uso, por un establecido o implicado
producto (errores por KLOC (Kilo Líneas de Código) o por Punto conjunto de usuarios. Las subcaracterísticas son:
Función (FP)), mantenibilidad (el esfuerzo para hacer un cierto Aprendizaje, Comprensión, Operatividad, Atractividad,
tipo de cambio), productividad (LDC (Líneas de Código)) o Conformidad de Usabilidad
Puntos Función por persona-mes), tiempo-de-mercado, o • Eficiencia: conjunto de atributos que se refieren a las
satisfacción del cliente (como medidos por medio de una encuesta relaciones entre el nivel de rendimiento del software y
a clientes). Esta relación depende del contexto particular (por la cantidad de recursos utilizados bajo unas condiciones
ejemplo, el tamaño de la organización o el tamaño del proyecto). predefinidas. Las subcaracterísticas son:
Compartimiento en el tiempo, Compartimiento de
De allí que el obtener las salidas del proceso que deseamos recursos, Conformidad de eficiencia.
significa que se debió haber implementado los procesos
• Mantenibilidad: conjunto de atributos relacionados con
adecuados.
la facilidad de extender, modificar o corregir errores en
un sistema software. Las subcaracterísticas de la
2.5.2Medición del Producto: ISO 9126-01 Facilidad de Mantenimiento son: Facilidad de análisis,
Facilidad de cambio, Estabilidad y Facilidad de prueba.
¿Qué es un producto de software? • Portabilidad: conjunto de atributos relacionados con la
Un producto de software se lo puede describir en un sentido capacidad de un sistema software para ser transferido
extenso como: los ejecutables, código fuente, descripciones de desde una plataforma a otra. Las subcaracterísticas de la
arquitectura, y así. Portabilidad son: Capacidad de instalación, capacidad
de reemplazamiento, Adaptabilidad y Co-Existencia.
De allí que las métricas del producto se refieren a las
características del propio software que incluye: la medición del
tamaño del producto, la estructura del producto y la calidad del
2.5.2.2Métricas Externas– ISO 9126-2:2003
producto.
Las cuales miden el software en sí mismo o software en ejecución
Un estándar internacional para la evaluación del Software es el (Calidad Externa – Ambiente de Prueba).
ISO 9126 supervisado por el proyecto SQuaRE, ISO 25000:2005.
[11] Permite evaluar la calidad del software desde distintas
2.5.2.3Métricas Internas – ISO 9126-3: 2003
perspectivas relacionadas con el desarrollo, adquisición,
Las cuales miden el comportamiento del sistema, dichas métricas
requerimientos, uso, evaluación, mantenimiento, aseguramiento
se aplican cuando el software no está en ejecución por ejemplo
de la calidad.
durante el diseño y codificación. (Calidad Interna – Ambiente de
El estándar está dividido en cuatro partes las cuales dirigen, Desarrollo)
respectivamente, lo siguiente:
2.5.2.4Calidad en Uso–ISO 9126-4: 2004
2.5.2.1Modelo de la Calidad El cual mide el efecto de usar el software en un contexto
específico (Ambiente de Producción).
Describe el modelo de calidad del producto de software ISO 9126-2, ISO 9126-3 e ISO 9126-4 están encaminados en
especificando 6 características de calidad interna (evalúa el total ambientes de Prueba, Desarrollo y Producción respectivamente.
de atributos que un software debe satisfacer) y externa (evalúa
¿Quién puede utilizar esta norma? • Desarrollo y mejora de los procesos de la
Esta Norma puede ser usada por desarrolladores, evaluadores organización
independientes y grupos de aseguramiento de la calidad • Definición de los procesos de la organización
responsable de especificar y evaluar la calidad del software. • Planificación de la formación
• Gestión de riesgos
3.MODELOS ESTANDARIZADOS • Análisis y resolución de toma de decisiones
En una unidad de organización del Instituto de Ingenieros • Mejora de Procesos “Bottom-Up”: este enfoque se
Eléctricos y Electrónicos (IEEE). Se estableció en 1963 cuando el centra en hacer mediciones como tamaño, esfuerzo,
Instituto Americano de Ingenieros Eléctricos (AIEE) y el Instituto productividad, defectos, reuso y otros indicadores de
de Ingenieros de Radio (IRE) se fusionaron para crear el IEEE. procesos consiguiendo así datos de líneas-base y cuando
En el momento de la fusión, la AIEE del Subcomité de gran se determina que habido mejoras potenciales el cambio
escala de Computación (creado en 1946) se fusionó con el IRE se implementa. El efecto del cambio determina la
del Comité Técnico de Electrónica Informática (establecida 1948) ocurrencia de una mejora significativa y el resultado es
para crear el Grupo de IEEE Computer. El grupo se convirtió en usado para manejar el cambio organizacional.
el IEEE Computer Society en 1971.
• Reingeniería de Negocios: establece mejor un cambio
radical que un cambio incremental, un poco similar al
7.REFERENCIAS
enfoque “Mejora de Procesos Bottom-Up”.
[1] Mario Piattini, Francisco J. Pino y Félix García,
5.2 Grupos de Procesos de Ingeniería de “Contribución de los estándares internacionales a la gestión
Sistemas e Ingeniería de Software (SEPG) de procesos software”, Facultad de Ingeniería Electrónica y
Telecomunicaciones, Universidad del Cauca, Colombia
http://www.aemes.org/rpm/descargar.php?volumen=4&nume
Software Engineering Process Group, nombre original dado al
ro=2&articulo=1
servicio registrado del Instituto de Igeniería del Software (SEI) a
los “grupos responsables por las actividades de proceso de las [2] Wikipedia, “Ingeniería de software”,
organizaciones del software”. Algunos de estos grupos son: http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwar
e
• SEPG: Grupo de Procesos de Ingeniería de Sistemas.
• SSEPG: Grupo de Procesos de Ingeniería de Software y
[3] Zavala R. 2000. Diseño de un Sistema de Información
Geográfica sobre internet. Tesis de Maestría en Ciencias de
Sistemas.
la Computación. Universidad Autónoma Metropolitana-
• SSPG: Grupo de Procesos de Software y Sistemas. Azcapotzalco. México, D.F. En prensa,
• PEG: Grupo de Ingeniería de Procesos. http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.
html#IngSoft
• PIG: Grupo de Mejora de Procesos.
[4] Luciano Guerrero, Monerreal: Canadá, 1999, “Ciclo de
• QIG: Grupo de Mejora de Calidad. Mejoramiento de Procesos, El modelo
• PTIG: Grupo de Mejora de Procesos y Tecnología. IDEAL,”www.geocities.com/SiliconValley/Lab/3629/IDEA
L_ciclo.pdf
6.CONCLUSIONES [5] “Software process engineering systems: models and industry
cases”,
http://herkules.oulu.fi/isbn9514265084/html/x287.html
Finalmente se puede concluir acerca del tema:
• Dentro del proceso de Ingeniería del Software los tres
[6] Francisco Ruiz, Procesos de Ingeniería del Software,
http://personales.unican.es/ruizfr/is1/doc/teo/02/is1-t02-
factores más importantes son: Personal, Métodos y
trans.pdf
Procedimientos y Herramientas y Técnicas.
• El proceso de ingeniería del software está basado en [7] IEEE, “IEEE 1074-2006”, http://www.techstreet.com/cgi-
procesos y modelos a la definición, evaluación y medición bin/detail?product_id=1277365
del software.
[8] IEEE Standard Association, “IEEE Std 1074-1997 IEEE
• Existen modelos y procesos aplicados en las diferentes Standard for Developing Software Life Cycle Processes -
etapas del proceso de software. Description”,
• La facilidad de entendimiento humano y comunicación, http://standards.ieee.org/reading/ieee/std_public/description/s
ayuda a llevar una buena definición de los procesos. e/1074-1997_desc.html
• La medición del Proceso de un Proyecto de Desarrollo de
Software es primordial pues gracias a éste nos permite [9] Jin Lyu, Kyle Hancock y Linus Luotsinen, IEEE Standard
identificar las fuerzas y las debilidades del mismo y a su 1219-1998 Software Maintenance,
vez del proyecto. http://classes.cecs.ucf.edu/eel6883/berrios/slides/ch%209%2
• La recolección de métricas del proceso es esencial para la 0-%20art%202%20-%20IEEE%20Standard%201219-
mejora del mismo y se utilizan para evaluar la eficiencia 1998.ppt
de un proceso y si éste ha mejorado con los cambios [10] “Métricas”, disponible en: http://alarcos.inf-
realizados. r.uclm.es/doc/Calidad/capitulo09.ppt
• Un producto de software constituye: los ejecutables,
código fuente, descripciones de arquitectura, y así.
[11] “ISO/IEC 9126” disponible en:
http://es.wikipedia.org/wiki/ISO/IEC_9126
• Medir un producto de software implica: la medición del
tamaño del producto, la estructura del producto y la [12] Fernanda Scalone, Software Quality Management,
calidad del producto. disponible en: http://softqm.blogspot.com/2007/01/visin-
• Las métricas en un proyecto de desarrollo de software e se general-acerca-de-iso-9126.html
pueden aplicar a procesos y productos. [13] María Del Carmen Sosa Sierra, “Inteligencia artificial en la
• Las métricas del proceso permiten a una organización de gestión financiera empresarial”,
ingeniería del software tener una visión profunda de la http://ciruelo.uninorte.edu.co/pdf/pensamiento_gestion/23/6_
eficacia de un proceso ya existente Inteligencia%20artificial.pdf
• Dos modelos estandarizados que se los puede utilizar para
la medición de la calidad del Software son: CMMI y ISO [14] Carlos J. Alonso González, Departamento de Informática,
9000. “Inducción de Reglas Proposicionales”,
http://www.infor.uva.es/~calonso/IAII/Aprendizaje/Induccio
nReglasProposicionales.pdf
[15] Wikipedia, “Normas ISO 9000” disponible en: [36] Wikipedia, disponible
http://es.wikipedia.org/wiki/Normas_ISO_9000 en:http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gi
[16] CINTERFOR,“ Gestión de calidad en la formación” l_de_software
disponible en: [37] “Gucoba” disponible en:
http://www.ilo.org/public/spanish/region/ampro/cinterfor/te
http://gucoba.com/index.php?option=com_content&vi
mas/calidad/doc/cedefop1.htm
ew=article&id=56&Itemid=57
[17] Wikipedia, “Software Engineering Institute” disponible en:
http://es.wikipedia.org/wiki/Software_Engineering_Institute [38] Monografias, disponibe en:
http://www.monografias.com/trabajos67/metodologia-
[18] Wikipedia, “British Computer Society” disponible en: desarrollo-softwares/metodologia-desarrollo-
http://en.wikipedia.org/wiki/British_Computer_Society
softwares2.shtml
[19] Wikipedia, “IEEE Computer Society” disponible en:
[39] “Método CBA IPI para la evaluación de proyectos”,
http://en.wikipedia.org/wiki/IEEE_Computer_Society
Disponible en:
[20] Wikipedia, “RUSSOFT” disponible en: http://www.geocities.com/SiliconValley/Lab/3629/cbai
http://en.wikipedia.org/wiki/RUSSOFT, disponible en: pi.htm
http://www.slideshare.net/aacevedolipes/spin-colombia
[40] “Metodologías De Desarrollo De Software”, María A.
[21] Rduardo A. Rodríguez Tello, “Procesos de software”, 2008, Mendoza Sanchez , 2004,
http://www.tamps.cinvestav.mx/~ertello/swe/sesion03.pdf http://www.willydev.net/InsiteCreation/v1.0/descargas
[22] Chirstian Tzec, “Fundamentos de Desarrollo de Sistemas”, /cualmetodologia.pdf
http://www.scribd.com/doc/16416960/Modelo-cascada-
[41] Microsoft Solution Framework, figura tomada de:
espiralincremental
http://caraujo334.blogspot.es/img/msf1.jpeg
[23] https://www.mytconsulting.com/principal/images/12207_5.p
ng [42] http://www.mentores.net/default.aspx?tabid=104&type
=art&site=183&parentid=32
[24] http://www.cs.umd.edu/users/basili/qip/img007.gif
[43] http://en.wikipedia.org/wiki/Microsoft_Solutions_Fra
[25] http://es.kioskea.net/contents/genie-logiciel/cycle-de- mework
vie.php3
[26] Sid@r, “Prototipado”,
http://www.sidar.org/recur/desdi/traduc/es/visitable/tecnicas/
Prototyping.htm
[27] “Introducción a la Ingeniería de Software”,
http://oacosta334.blogspot.es/tags/prototipo/
[28] Wikipedia, “Modelo de prototipos”, 2009,
http://es.wikipedia.org/wiki/Modelo_de_prototipos
[29] http://cmunoz334.blogspot.es/tags/Modelo/
[30] “MODELOS DE PROCESO ITERATIVOS E
INCREMENTALES”,
http://scruz334.blogspot.es/1193793960/
[31] Wikipedia, “Desarrollo en espiral”, Modificado: 16 abril del
2009,
http://es.wikipedia.org/wiki/Desarrollo_en_espiral#Ventajas
[32] Wikipedia, “Desarrollo iterativo y creciente”, Modificado 18
de Junio 2009,
http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente
#Debilidades_de_este_modelo_de_desarrollo
[33] Samira Lamayzi, “La norma ISO 14764”, 1999,
http://alarcos.inf-
cr.uclm.es/per/fruiz/cur/mso/comple/ISO14764.pdf
[34] http://www.aemes.org/rpm/descargar.php?volumen=4&nume
ro=2&articulo=1
[35] Juan Pablo Gomez Gallego, “Fundamentos de la
Metodología RUP Rational Unified Process”, 2007