Você está na página 1de 37

Trabajo Investigativo 01

Ingeniera de software

Presenta
David Camilo Snchez Mora 20132578060
Hector Felipe Hurtado Acosta 20131078401
Yojhan Leonardo Rodrguez 20131078023
Sebastin Espitia 20131078050

Docente
Juan Carlos Guevara B.

Universidad Distrital Francisco Jos de Caldas


Sistematizacin de datos
Facultad tecnolgica
Bogot D.C Colombia 08 de febrero de 2016

Contenido
2. Introduccin...........................................................................................................4
3. Ingeniera de software...........................................................................................5
3.1. Definicin............................................................................................................5
3.2. Objetivos.............................................................................................................5
3.3. Caractersticas....................................................................................................6
3.4. Historia................................................................................................................6
4. Seis modelos de ciclo de vida del software (A cada modelos realizar los
siguientes puntos)......................................................................................................8
4.1. Nombre...............................................................................................................8
4.2. Explicacin del funcionamiento..........................................................................8
5. Seis metodologas de desarrollo de software:...................................................13
Nombre y explicar sus etapas y actividades (En cada etapa y actividad describir
los artefactos que se entregan)...............................................................................13
ISO / IEC 25000 proporciona orientacin para el uso de la nueva serie de Normas
Internacionales nombrados Sistemas y requisitos de calidad de software y
Evaluacin (cuadrados). El propsito de la norma ISO / IEC 25000 es proporcionar
una visin general de los contenidos cuadrados, modelos de referencia comn y
definiciones, as como la relacin entre los documentos, permitiendo a los usuarios
de la gua de un buen conocimiento de esas series de normas, de acuerdo con su
propsito de uso. Tambin contiene una explicacin del proceso de transicin
entre la antigua norma ISO / IEC 9126 y la serie ISO / IEC 14598 y de la plaza...23
Determinacin de la capacidad del proceso (PCD) se ocupa de analizar los
resultados de una o ms conformes evaluaciones de proceso para identificar las
fortalezas, debilidades y riesgos implicados en la realizacin de un proyecto
especfico utilizando los procesos seleccionados dentro de una unidad
organizativa determinada. Una determinacin de la capacidad del proceso puede
proporcionar una entrada fundamental para seleccin de proveedores, en cuyo
caso se denomina a menudo "determinacin de la capacidad del proveedor"......26
ISO / IEC 15504-4: 2004 describe los procesos de PCD y PI y cmo desplegarlos,
y proporciona orientacin sobre..............................................................................26
1. La utilizacin de la evaluacin de proceso,......................................................26
2. Modelo de referencia del proceso de seleccin (s),.........................................26
3. El establecimiento de la capacidad de destino,................................................26
4. La definicin de la entrada de evaluacin,.......................................................26
5. Inferir el riesgo relacionada con el proceso de evaluacin de salida,..............26
6. Medidas de mejora de procesos,......................................................................26
7. Pasos de la determinacin de la capacidad del proceso,................................26
8. Comparabilidad de los anlisis de resultados de las evaluaciones.................26

ISO / IEC 15504-5: 2012...................................................................................27

(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?
csnumber=60555)....................................................................................................27
Proporciona una descripcin detallada de la estructura y los componentes clave
del proceso de evaluacin del modelo, que incluye dos dimensiones: una
dimensin de proceso y una dimensin de capacidad. Tambin introduce
indicadores de evaluacin.......................................................................................27
ISO / IEC 15504-5: 2012 utiliza las definiciones de procesos de la norma ISO / IEC
12207: 2008 para identificar un modelo de proceso de referencia. Los procesos del
modelo de proceso de referencia se describen en el modelo de evaluacin del
proceso en trminos de propsito y los resultados se agrupan en tres categoras
de procesos. El proceso de evaluacin del modelo ampla las definiciones de
procesos Modelo de referencia del proceso mediante la inclusin de un conjunto
de indicadores de rendimiento de proceso de llamadas prcticas de base para
cada proceso. El proceso de evaluacin del modelo tambin define un segundo
conjunto de indicadores de desempeo de los procesos mediante la asociacin de
los productos de trabajo con cada proceso.............................................................27
ISO / IEC 15504-5: 2012 duplica las definiciones de los niveles de capacidad y los
atributos de proceso de la norma ISO / IEC 15504-2, y se expande cada uno de
los nueve atributos a travs de la inclusin de un conjunto de prcticas
genricas. Estas prcticas genricas pertenecen a un conjunto de indicadores de
la capacidad del proceso, en asociacin con los indicadores de recursos
genricos, y los indicadores de productos genricos de trabajo............................27
ISO / IEC 15504-5: 2012 tambin ofrece lo siguiente:............................................27
Una declaracin de conformidad de la evaluacin del modelo de proceso con
los requisitos definidos en la norma ISO / IEC 15504-2;........................................27
Caractersticas seleccionadas de los productos tpicos de trabajo para ayudar
al evaluador para evaluar el nivel de capacidad de los procesos;..........................27
Guas de estilo para definir las prcticas de base, productos de trabajo y
prcticas genricas para ajustar el modelo de evaluacin del proceso, y la gua
que explica cmo ampliar o adaptar el modelo;......................................................27

Algunos procesos que complementen el proceso de evaluacin del modelo..28

ISO / IEC 15504-6: 2013...................................................................................28

(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?
csnumber=61492)....................................................................................................28
Constituye un proceso de evaluacin de modelos, conformes con los requisitos de
la norma ISO / IEC 15504-2, para la evaluacin de la capacidad de proceso de los
procesos del ciclo de vida del sistema....................................................................28
La dimensin del proceso de este modelo de evaluacin de proceso se basa en el
modelo de proceso de referencia contenida en la norma ISO / IEC 15288............28

ISO / IEC 15504-6: 2013 proporciona una nueva dimensin de los procesos para
la evaluacin del modelo de proceso derivado de la referencia de proceso revisado
modelo que figura en la norma ISO / IEC 15288: 2008..........................................28
El mbito de aplicacin de la norma ISO / IEC 15504-6: 2013 es consistente con el
alcance de la norma ISO / IEC 15504-5 con el fin de ayudar a la evaluacin de
situaciones en las que se est haciendo de ambos procesos del ciclo de vida del
software y del sistema.............................................................................................28
Los usuarios de ISO / IEC 15504-6: 2013 pueden reproducir libremente las
descripciones detalladas que figuran en el modelo de evaluacin ejemplar como
parte de cualquier herramienta o de otro material para apoyar el desempeo de las
evaluaciones de proceso, de modo que pueda ser utilizado para el fin previsto.. .28
7. Dos modelos de evaluacin de calidad de software (A cada metodologa realizar
los siguientes puntos)..............................................................................................32
7.1. Nombre.............................................................................................................32
7.2. Explicacin de los elementos del modelo........................................................32
7.1. Nombre.............................................................................................................32
7.2. Explicacin de los elementos del modelo........................................................32
8. Elementos de un proyecto de desarrollo de software.........................................32
9. Conclusiones.......................................................................................................32
10. Bibliografa.........................................................................................................32

2. Introduccin
El presente trabajo tiene como objetivo identificar, estudiar y conocer los diferentes
conceptos, objetivos, historia, modelos de ciclo de vida, metodologas, mtodos,
estndares y procesos de evaluacin de la calidad de la ingeniera de software.
El trabajo se divide en los diferentes conceptos, objetivos, historia, modelos de
ciclo de vida, metodologas, mtodos, estndares y procesos de evaluacin de la
calidad de la ingeniera de software.
3. Ingeniera de software

3.1. Definicin
Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de
los programas de computadora, procedimientos, reglas, la documentacin
asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo
autor, "un producto de software es un producto diseado para un usuario". En este
contexto, la Ingeniera de Software es un enfoque sistemtico del desarrollo,
operacin, mantenimiento y retiro del software", que en palabras ms llanas, se
considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los
principios de la ciencia de la computacin y las matemticas para lograr
soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de
desarrollo de software", es decir, "permite elaborar consistentemente productos
correctos, utilizables y costo-efectivos" [Cota 1994].
El proceso de ingeniera de software se define como "un conjunto de etapas
parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la
obtencin de un producto de software de calidad" [Jacobson 1998].El proceso de
desarrollo de software "es aquel en que las necesidades del usuario son
traducidas en requerimientos de software, estos requerimientos transformados en
diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y
certificado para su uso operativo". Concretamente "define quin est haciendo
qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson 1998].
3.2. Objetivos
En la construccin y desarrollo de proyectos se aplican mtodos y tcnicas para
resolver los problemas, la informtica aporta herramientas y procedimientos sobre
los que se apoya la ingeniera de software.
Disear aplicaciones informticas que se ajusten a las necesidades de las
organizaciones.
Dirigir y coordinar el desarrollo de aplicaciones complejas.
Intervenir en todas las fases del ciclo de vida de un producto.
Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realizacin de pruebas que verifiquen el correcto
funcionamiento de los programas y que se ajustan a los requisitos de
anlisis y diseo.
Disear, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de
aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando mtricas e
indicadores y controlando la calidad del software producido.

Organizar y supervisar el trabajo de su equipo de los tcnicos de


mantenimiento y los ingenieros de sistemas y redes.

3.3. Caractersticas

3.4. Historia
Cuando aparecieron las primeras computadoras digitales en la dcada de 1940,8
el desarrollo de software era algo tan nuevo que era casi imposible hacer
predicciones de las fechas estimadas de finalizacin del proyecto y muchos de
ellos sobrepasaban los presupuestos y tiempo estimados. Los desarrolladores
tenan que volver a escribir todos sus programas para correr en mquinas nuevas
que salan cada uno o dos aos, haciendo obsoletas las ya existentes.
El trmino Ingeniera del software apareci por primera vez en a finales de la
dcada de 1950. La Ingeniera de software fue estimulada por la crisis del software
de las dcadas de entre 1960 y 1980. La Ingeniera del software viene a ayudar a
identificar y corregir mediante principios y metodologas los procesos de desarrollo
y mantenimiento de sistemas de software.
Aparte de la crisis del software de las dcadas de entre 1960 y 1980, la ingeniera
de software se ve afectada por accidentes que conllevaron a la muerte de tres
personas; esto sucedi cuando la mquina de radioterapia Therac-25 emite una
sobredosis masiva de radiacin y afecto contra la vida de estas personas.9 Esto
remarca los riesgos de control por software,10 afectando directamente al nombre
de la ingeniera de software.

A principios de los 1980,11 la ingeniera del software ya haba surgido como una
genuina profesin, para estar al lado de las ciencias de la computacin y la
ingeniera tradicional. Antes de esto, las tareas eran corridas poniendo tarjetas
perforadas como entrada en el lector de tarjetas de la mquina y se esperaban los
resultados devueltos por la impresora.
Debido a la necesidad de traducir frecuentemente el software viejo para atender
las necesidades de las nuevas mquinas, se desarrollaron lenguajes de orden
superior. A medida que apareci el software libre, las organizaciones de usuarios
comnmente lo liberaban.
Durante mucho tiempo, solucionar la crisis del software fue de suma importancia
para investigadores y empresas que se dedicaban a producir herramientas de
software.
Para la dcada de 1980, el costo de propiedad y mantenimiento del software fue
dos veces ms caro que el propio desarrollo del software, y durante la dcada de
1990, el costo de propiedad y mantenimiento aument 30 % con respecto a la
dcada anterior. En 1995, muchos de los proyectos de desarrollo estaban
operacionales, pero no eran considerados exitosos. El proyecto de software medio
sobrepasaba en un 50 % la estimacin de tiempo previamente realizada, adems,
el 75 % de todos los grandes productos de software que eran entregados al cliente
tenan fallas tan graves, que no eran usados en lo absoluto o simplemente no
cumplan con los requerimientos del cliente.10
Algunos expertos argumentaron que la crisis del software era debido a la falta de
disciplina de los programadores.
Cada nueva tecnologa y prctica de la dcada de 1970 a la de 1990 fue
pregonada como la nica solucin a todos los problemas y el caos que llev a la
crisis del software. Lo cierto es que la bsqueda de una nica clave para el xito
nunca funcion. El campo de la ingeniera de software parece un campo
demasiado complejo y amplio para una nica solucin que sirva para mejorar la
mayora de los problemas, y cada problema representa slo una pequea porcin
de todos los problemas de software.
El auge del uso del Internet llev a un vertiginoso crecimiento en la demanda de
sistemas internacionales de despliegue de informacin en la World Wide Web. Los
desarrolladores se vieron en la tarea de manejar ilustraciones, mapas, fotografas
y animaciones, a un ritmo nunca antes visto, con casi ningn mtodo para
optimizar la visualizacin y almacenamiento de imgenes. Tambin fueron
necesarios sistemas para traducir el flujo de informacin en mltiples idiomas
extranjeros a lenguaje natural humano, con muchos sistemas de software
diseados para uso multilenguaje, basado en traductores humanos.

La ingeniera de software contribuyo alrededor de 90,000 millones de dlares por


ao ya que entra en juego el Internet; esto hace que los desarrolladores tuviesen
que manejar imgenes mapas y animaciones para optimizar la
visualizacin/almacenamiento de imgenes (como el uso de imgenes en
miniatura). El uso de los navegadores y utilizacin de lenguaje HTM cambia
drsticamente la visin y recepcin de la informacin.
Las amplias conexiones de red crea la proliferacin de virus informticos y la
basura en los correos electrnicos (E-mail) esto pone en una carrera contra el
tiempo los desarrolladores para crear nuevos sistemas de bloqueo o seguridad de
estas anomalas en la informtica ya que se volvan sumamente tediosas y
difciles de arreglar10
Despus de una fuerte y creciente demanda surge la necesidad de crear
soluciones de software a bajo costo, esto conlleva al uso de metodologas ms
simples y rpidas que desarrollan software funcional. Cabe sealar que los
sistemas ms pequeos tenan un enfoque ms simple y rpido para poder
administrar el desarrollo de clculos y algoritmos de software.

4. Seis modelos de ciclo de vida del software (A cada modelos realizar los
siguientes puntos)

4.1. Nombre

Modelo Cascada
Modelo De Desarrollo Incremental
Modelo De Desarrollo Evolutivo
Modelo de Prototipado de Requerimientos
Modelo Espiral
Modelo Concurrente

4.2. Explicacin del funcionamiento


Modelo Cascada
Este es el ms bsico de todos los modelos, y sirve como bloque de construccin
para los dems modelos de ciclo de vida. La visin del modelo cascada del
desarrollo de software es muy simple; dice que el desarrollo de software puede ser
a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas
bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin
de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las

flechas muestran el flujo de informacin entre las fases. La flecha de avance


muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin.

Modelo De Desarrollo Incremental


Los riesgos asociados con el desarrollo de sistemas largos y complejos son
enormes. Una forma de reducir los riesgos es construir slo una parte del sistema,
reservando otros aspectos para niveles posteriores. El desarrollo incremental es el
proceso de construccin siempre incrementando subconjuntos de requerimientos
del sistema. Tpicamente, un documento de requerimientos es escrito al capturar
todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El
desarrollo incremental no demanda una forma especfica de observar el desarrollo
de algn otro incremento. As, el modelo cascada puede ser usado para
administrar cada esfuerzo de desarrollo, como se muestra en la figura.
Modelo De Desarrollo Evolutivo
Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo
(algunas veces denominado como prototipado evolutivo) construye una serie de
grandes versiones sucesivas de un producto. Sin embargo, mientras que la
aproximacin incremental presupone que el conjunto completo de requerimientos
es conocido al comenzar, el modelo evolutivo asume que los requerimientos no
son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y
slo esos que son bien comprendidos son seleccionados para el primer
incremento. Los desarrolladores construyen una implementacin parcial del
sistema que recibe slo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen
retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la
especificacin de requerimientos es actualizada, y una segunda versin del
producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El
desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de
algn incremento. As, el modelo cascada puede ser usado para administrar cada
esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede
ser combinado tambin.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos
conocidos (incremental), y comprender al principio que muchos nuevos

requerimientos es probable que aparezcan cuando el sistema sea desplegado o


desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la
manipulacin de documentos, programas, datos de test, etc. desarrollados para
distintas versiones del software. Cada paso debe ser registrado, la documentacin
debe ser recuperada con facilidad, los cambios deben ser efectuados de una
manera controlada.
Modelo de Prototipado de Requerimientos
El prototipado de requerimientos es la creacin de una implementacin parcial de
un sistema, para el propsito explcito de aprender sobre los requerimientos del
sistema. Un prototipo es construido de una manera rpida tal como sea posible.
Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que
ellos experimenten con el prototipo. Estos individuos luego proveen la
retroalimentacin sobre lo que a ellos les gust y no les gust acerca del prototipo
proporcionado, quienes capturan en la documentacin actual de la especificacin
de requerimientos la informacin entregada por los usuarios para el desarrollo del
sistema real. El prototipado puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el prototipado
puede servir su papel inmediatamente antes de algn o todo el desarrollo
incremental en modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin
de requerimientos para sistemas complejos tiende a ser relativamente dificultoso
de cursar. Muchos usuarios y clientes encuentran que es mucho ms fcil proveer
retroalimentacin convenientemente basada en la manipulacin, leer una
especificacin de requerimientos potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn
incorporados, un prototipo generalmente se construye con los requerimientos
entendidos ms pobremente.
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida.
En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno
completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo
ejecutado, puedes seguir estos cuatros pasos:
Determinar qu quieres lograr.
Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por
cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.

Seguir la alternativa seleccionada en el paso 2.


Establecer qu tienes terminado.
La dimensin radial en la figura refleja costos acumulativos incurridos en el
proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros
viajaremos a resolver un conjunto particular de problemas del cliente. Durante el
primer viaje alrededor de la espiral, analizamos la situacin y determinamos que
los mayores riesgos son la interfaz del usuario. Despus de un cuidadoso anlisis
de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y
esperar lo mejor, escribir una especificacin de requerimientos y esperar que el
cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de
accin es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con
retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la
espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos
nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea
desplegado. Analicemos las rutas alternativas, y decidimos que la mejor
aproximacin es construir un incremento del sistema que satisfaga slo los
requerimientos mejor entendidos. Hagmoslo ya. Despus del despliegue, el
cliente nos provee de retroalimentacin que dir si estamos correctos con esos
requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas
de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios bsicos:

Decidir qu problema se quiere resolver antes de viajar a resolverlo.

Examinar tus mltiples alternativas de accin y elegir una de las ms


convenientes.

Evaluar qu tienes hecho y qu tienes que haber aprendido despus de


hacer algo.

No ser tan ingenuo para pensar que el sistema que ests construyendo
ser "EL" sistema que el cliente necesita, y

Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son


completamente compatible.

Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripcin del
proceso software. Mientras que la contribucin primaria del modelo espiral es en
realidad que esas actividades del software ocurran repetidamente, la contribucin
del modelo concurrente es su capacidad de describir las mltiples actividades del
software ocurriendo simultneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades
que ocurren en algn tiempo del proceso de desarrollo de software. Discutamos
un poco tales casos:
Los requerimientos son usualmente "lneas de base", cuando una mayora de los
requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un
esfuerzo considerable al diseo. Sin embargo, una vez que comienza el diseo,
cambios a los requerimientos son comunes y frecuentes (despus de todo, los
problemas reales cambian, y nuestro entendimiento de los problemas
desarrollados tambin). Es desaconsejado detener el diseo en este camino
cuando los requerimientos cambian; en su lugar, existe una necesidad de
modificar y rehacer lneas de base de los requerimientos mientras progresa el
diseo. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseo puede no ser afectado, medianamente afectado o se
requerir comenzar todo de nuevo.
Durante el diseo de arquitectura, es posible que algunos componentes
comiencen a ser bien definidos antes que la arquitectura completa sea
estabilizada. En tales casos, puede ser posible comenzar el diseo detallado en
esos componentes estables. Similarmente, durante el diseo detallado, puede ser
posible proceder con la codificacin y quizs regular testeando en forma unitaria o
realizando testeo de integracin previo a llevar a cabo el diseo detallado de todos
los componentes.
En algunos proyectos, mltiples etapas de un producto se han desarrollado
concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la
etapa 1 de un producto, y al mismo tiempo estar haciendo mantencin sobre un
componente 2, mientras que se est haciendo codificacin sobre un componente
3, mientras se realiza diseo sobre una etapa 4, y especificacin de requisitos
sobre un componente 5.
En todos estos casos, diversas actividades estn ocurriendo simultneamente.
Eligiendo seguir un proyecto usando tcnicas de modelacin concurrente, se
posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.

5. Seis metodologas de desarrollo de software:


Nombre y explicar sus etapas y actividades (En cada etapa y actividad
describir los artefactos que se entregan)

METODOLOGA RUP

Es una metodologa cuyo fin es entregar un producto de software. Se


estructura todos los procesos y se mide la eficiencia de la organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de
modelado UML, constituye la metodologa estndar ms utilizada para el
anlisis, implementacin y documentacin de sistemas orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y necesidades
de cada organizacin. Describe cmo aplicar enfoques para el desarrollo del
software, llevando a cabo unos pasos para su realizacin.
Se centra en la produccin y mantenimiento de modelos del sistema.
Fases del ciclo de vida del RUP:
1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance
del proyecto con los patrocinadores, identificar los riesgos asociados al
proyecto, proponer una visin muy general de la arquitectura de software y
producir el plan de las fases y el de iteraciones posteriores.
2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos
de uso que permiten definir la arquitectura base del sistema y se desarrollaran
en esta fase, se realiza la especificacin de los casos de uso seleccionados y
el primer anlisis del dominio del problema, se disea la solucin preliminar.
3. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad
del sistema, para ello se deben clarificar los requerimientos pendientes,
administrar los cambios de acuerdo a las evaluaciones realizados por los
usuarios y se realizan las mejoras para el proyecto.
4. Fase de Cierre: El propsito de esta fase es asegurar que el software est
disponible para los usuarios finales, ajustar los errores y defectos encontrados
en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte
tcnico necesario. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en el proyecto.
Ciclo de vida RUP

Artefactos RUP
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza
una serie de artefactos que sirven para comprender mejor tanto el anlisis
como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los
siguientes:
Inicio:
Documento Visin
Especificacin de Requerimientos
Elaboracin:
Diagramas de caso de uso
Construccin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista lgica:
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)
Vista de implementacin:
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
Vista conceptual
Modelo de dominio
Vista fsica

Mapa de comportamiento a nivel de hardware

METODOLOGA SCRUM

Scrum es una metodologa gil de desarrollo, aunque surgi como modelo para
el desarrollo de productos tecnolgicos, tambin se emplea en entornos que
trabajan con requisitos inestables y que requieren rapidez y flexibilidad;
situaciones frecuentes en el desarrollo de determinados sistemas de software.
Es una metodologa de desarrollo muy simple, que requiere trabajo duro
porque no se basa en el seguimiento de un plan, sino en la adaptacin
continua a las circunstancias de la evolucin del proyecto.
Fases de scrum
SCRUM comprende las siguientes fases:
1.- Pre-juego
Planificacin: Definicin de una nueva versin basada en la pila actual, junto
con una estimacin de coste y agenda. Si se trata de un nuevo sistema, esta
fase abarca tanto la visin como el anlisis. Si se trata de la mejora de un
sistema existente comprende un anlisis de alcance ms limitado. Arquitectura:
Diseo de la implementacin de las funcionalidades de la pila. Esta fase
incluye la modificacin de la arquitectura y diseo generales.
2.- Juego
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versin con
respeto contino a las variables de tiempo, requisitos, costo y competencia. La
interaccin con estas variables define el final de esta fase. El sistema va
evolucionando a travs de mltiples iteraciones de desarrollo o sprints.
3.- Post-juego
Preparacin para el lanzamiento de la versin, incluyendo la documentacin
final y pruebas antes del lanzamiento de la versin.

Herramientas y artefactos
Scrum no requiere ni provee prcticas de Ingeniera. En lugar de eso,
especifica prcticas y herramientas de gerencia que se aplican en sus distintas
fases para evitar el caos originado por la complejidad e imposibilidad de
realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto.
Cuando un proyecto comienza es muy difcil tener claro todos los
requerimientos sobre el producto. Sin embargo, suelen surgir los ms
importantes que casi siempre son ms que suficientes para un Sprint.
El objetivo es asegurar que el producto definido al terminar la lista es el ms
correcto, til y competitivo posible y para esto la lista debe acompaar los
cambios en el entorno y el producto.
Sprints
Un Sprint es el procedimiento de adaptacin de las cambiantes variables del
entorno (requerimientos, tiempo, recursos, conocimiento, tecnologa). Son
ciclos iterativos en los cuales se desarrolla o mejora una funcionalidad para
producir nuevos incrementos. Durante un Sprint el producto es diseado,
codificado y probado. Y su arquitectura y diseo evolucionan durante el
desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea
fcil de recordar y est siempre presente en el equipo.
Burn down Chart
La burn down chart es una grfica mostrada pblicamente que mide la cantidad
de requisitos en el Backlog del proyecto pendientes al comienzo de cada
Sprint. Dibujando una lnea que conecte los puntos de todos los Sprints

completados, podremos ver el progreso del proyecto. Lo normal es que esta


lnea sea descendente (en casos en que todo va bien en el sentido de que los
requisitos estn bien definidos desde el principio y no varan nunca) hasta
llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay
ms requisitos pendientes de ser completados en el Backlog).
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los tems de la
Product Backlog List que van a ser implementados en el siguiente Sprint.
Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no en agregar
funcionalidad. Suelen aplicarse cuando se prepara un producto para el release.
Son tiles cuando se estn realizando pruebas beta, se est introduciendo a un
equipo en la metodologa de Scrum o cuando la calidad de un producto no
alcanza los lmites esperados.

METODOLOGA XP

Se basa en la filosofa de que el mayor valor de negocio es entregado por el


programa ms sencillo que cumpla los requerimientos. Simple Design se
enfoca en proporcionar un sistema que cubra las necesidades inmediatas del
cliente, ni ms ni menos. Este proceso permite eliminar redundancias y
rejuvenecer los diseos obsoletos de forma sencilla.

Entendimiento
1. Diseo simple: se basa en la filosofa de que el mayor valor de negocio es
entregado por el programa ms sencillo que cumpla los requerimientos. Simple
Design se enfoca en proporcionar un sistema que cubra las necesidades
inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar
redundancias y rejuvenecer los diseos obsoletos de forma sencilla.
2. Metfora: desarrollada por los programadores al inicio del proyecto, define
una historia de cmo funciona el sistema completo. XP estimula historias, que
son breves descripciones de un trabajo de un sistema en lugar de los
tradicionales diagramas y modelos UML (Unified Modeling Language). La
metfora expresa la visin evolutiva del proyecto que define el alcance y
propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y
Colaboracin) tambin ayudarn al equipo a definir actividades durante el
diseo del sistema. Cada tarjeta representa una clase en la programacin
orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las
colaboraciones con las otras clases (cmo se comunica con ellas).
3. Propiedad colectiva del cdigo: un cdigo con propiedad compartida.
Nadie es el propietario de nada, todos son el propietario de todo. Este mtodo
difiere en mucho a los mtodos tradicionales en los que un simple programador
posee un conjunto de cdigo. Los defensores de XP argumentan que mientras
haya ms gente trabajando en una pieza, menos errores aparecern.
4. Estndar de codificacin: define la propiedad del cdigo compartido as
como las reglas para escribir y documentar el cdigo y la comunicacin entre
diferentes piezas de cdigo desarrolladas por diferentes equipos. Los
programadores las han de seguir de tal manera que el cdigo en el sistema se
vea como si hubiera estado escrito por una sola persona.

METODOLOGIA AUP

El Proceso Unificado gil (Agile UP) es un enfoque al desarrollo de software


basado en el Rational Unified Process (RUP) de IBM. El ciclo de vida de Agile
UP es serial en lo grande e iterativo en lo pequeo, liberando entregables
incrementales en el tiempo. Este describe de una manera simple y fcil de
entender la forma de desarrollar aplicaciones de software de negocio usando
tcnicas giles y conceptos que an se mantienen vlidos en RUP. El AUP
aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (test driven
development - TDD), Modelado gil, Gestin de Cambios gil, y
Refactorizacin de Base de Datos para mejorar la productividad.

Fases de Agile UP
Las fases son implementadas de una forma serial a lo largo de un proyecto de
Agile UP. Estas fases son:
1.

Iniciacin. El objetivo de esta fase es identificar el


alcance inicial del proyecto, una arquitectura potencial para el sistema y
obtener, si procede, financiacin para el proyecto y la aceptacin por parte de
los promotores del sistema.
2.
Elaboracin. Mediante esta fase se pretende
identificar y validar la arquitectura del sistema.
3.
Construccin. El objetivo de esta fase consiste en
construir software desde un punto de vista incremental basado en las
prioridades de los participantes.
4.
Transicin. En esta fase se valida y despliega el
sistema en el entorno de produccin.
Actividades y artefactos
1. Modelado. Su objeto es entender la lgica de negocio de la aplicacin, el
dominio del problema del proyecto e identificar una solucin viable para el
dominio del problema.
2. Implementacin. Transformar los modelos en cdigo ejecutable y realizar
pruebas bsicas, en particular pruebas unitarias.

3. Pruebas. Realizar una evaluacin de los objetivos para asegurar la calidad.


Esto incluye encontrar defectos, validar que el sistema funciona como fue
diseado y verificar que los requisitos se cumplen.
4. Despliegue. Planear la entrega del sistema y ejecutar el plan para hacer
que el sistema quede disponible para los usuarios finales.
5. Gestin de la configuracin. Gestionar el acceso a los artefactos del
proyecto. Esto incluye, adems de la traza de versiones de los artefactos, el
control de cambios y la gestin de los mismos.
6. Gestin del proyecto. Dirige las actividades que tienen lugar dentro del
proyecto, incluyendo gestin de riesgos, direccin del personal y
coordinacin.
7. Entorno. Apoyar el resto del esfuerzo asegurando que los procesos,
mtodos y herramientas estn disponibles para el equipo cuando los
necesitan.

METODOLOGIA DESARROLLO ADAPTATIVO DE SOFTWARE (DAS)

El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith 1998


como una tcnica para construir software y sistemas complejos. Los apoyos
filosficos del DAS se enfocan en la colaboracin humana y la organizacin
propia del equipo.

Fases de desarrollo
Fase de especulacin: Se inicia el desarrollo del proyecto. En ella se utiliza
informacin como la misin del cliente, las restricciones del proyecto y los
requisitos bsicos para definir el conjunto de ciclos en el que se harn los
incrementos
del
software.
Fase de colaboracin: Se busca que el equipo no solo se comunique o se
encuentre completamente integrados, se desea que exista confianza, donde se
puedan realizar crticas constructivas y ayudar si resentimientos, trabajar tan
duro como sea posible, comunicar de una forma oportuna los problemas que
se presenten para tomar acciones efectivas y poseer un conjunto de actitudes
que
contribuyan
al
trabajo
que
se
encuentran
realizando.
Aprendizaje: Permite mejorar el entendimiento real sobre la tecnologa, los
procesos utilizados y el proyecto. El aprendizaje individual permite al equipo
tener mayor posibilidad de xito.
Cada una de estas fases se unen entre s para llevar a cabo diversas
funciones, pero en si estas funciones son para sacar adelante un proyecto de
software de manera rpida, y trabajando en equipo, para que en un futuro,
obtengamos un software eficiente.
El Desarrollo adaptativo del software (ASD) proporciona un marco para el
desarrollo iterativo de sistemas grandes y complejos. El mtodo fomenta el
desarrollo iterativo e incremental con el uso de prototipos.
ASD resalta que las aproximaciones secuenciales en cascada solo funcionan
en entornos bien conocidos. Pero como los cambios ocurren frecuentemente
en el desarrollo software, es importante usar un mtodo tolerante a cambios. El
primer ciclo de un proyecto ASD suele ser corto, asegurando que el cliente est
involucrado
y
confirmando
la
viabilidad
del
proyecto.
Cada ciclo termina con una revisin en grupo enfocada al cliente. Durante las
reuniones de revisin, se estudia la aplicacin funcionando. El resultado de las
reuniones son peticiones de cambio documentadas.

METODOLOGIA 3P

Aceptacin.
Tareasdedevida(Fases)
Ingeniera.

Procesos.
desarrollo.

Ciclo

Paradigma 3P es una metodologa de desarrollo de software nacida al calor


de la experiencia acumulada del grupo de investigacin y desarrollo Atis
debido a la insuficiente capacidad de respuesta a los clientes utilizando
las
metodologas tradicionales. Paradigma 3P es una metodologa de

desarrollo de software nacida al calor de la experiencia acumulada del grupo


de investigacin y desarrollo Atis, debido a la insuficiente capacidad
de respuesta a los clientes utilizando las metodologas tradicionales.
Fases

Definicin del problema.


Identificacin de los procesos unitarios.
Diseo del prototipo.
Desarrollo del prototipo.
Prueba del prototipo.
Si <no prueba de Prototipo>ir a Paso 3.
Si <Prototipo difiere Sistema Deseado>ir a Paso 2.
Si <no Necesidades satisfechas>ir a Paso 2.
Implantacin.
Mantenimiento

Actividades
Codificar: Es necesario codificar y plasmar nuestras ideas a travs del cdigo
Hacer pruebas: Las caractersticas del software que no pueden ser
demostradas mediante pruebas simplemente no existen. Las pruebas dan la
oportunidad de saber si lo implementado es lo que en realidad se tena en
mente.
Escuchar: Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es
lo deseado, y tenemos que preguntar a quin necesita la informacin. Tenemos
que escuchar a nuestros clientes cules son los problemas de su negocio,
debemos de tener una escucha activa explicando lo que es fcil y difcil de
obtener, y la realimentacin entre ambos nos ayudan a todos a entender los
problemas.
Disear: El diseo crea una estructura que organiza la lgica del sistema, un
buen diseo permite que el sistema crezca con cambios en un solo lugar.
6. 1 ISO / IEC 25000
Sistemas y la calidad del software Requisitos y Evaluacin
https://es.wikipedia.org/wiki/ISO/IEC_25000
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?
csnumber=64764

ISO / IEC 25000 proporciona orientacin para el uso de la nueva serie de Normas
Internacionales nombrados Sistemas y requisitos de calidad de software y
Evaluacin (cuadrados). El propsito de la norma ISO / IEC 25000 es proporcionar
una visin general de los contenidos cuadrados, modelos de referencia comn y
definiciones, as como la relacin entre los documentos, permitiendo a los usuarios
de la gua de un buen conocimiento de esas series de normas, de acuerdo con su
propsito de uso. Tambin contiene una explicacin del proceso de transicin
entre la antigua norma ISO / IEC 9126 y la serie ISO / IEC 14598 y de la plaza.

ISO/IEC 2500n. Divisin de gestin de calidad. Los estndares que forman


esta divisin definen todos los modelos comunes, trminos y referencias a los
que se alude en las dems divisiones de SQuaRE.

ISO/IEC 2501n. Divisin del modelo de calidad. El estndar que conforma


esta divisin presenta un modelo de calidad detallado, incluyendo
caractersticas para la calidad interna, externa y en uso.

ISO/IEC 2502n. Divisin de mediciones de calidad. Los estndares


pertenecientes a esta divisin incluyen un modelo de referencia de calidad del
producto software, definiciones matemticas de las mtricas de calidad y una
gua prctica para su aplicacin. Presenta aplicaciones de mtricas para la
calidad de software interna, externa y en uso.

ISO/IEC 2503n. Divisin de requisitos de calidad. Los estndares que


forman parte de esta divisin ayudan a especificar los requisitos de calidad.
Estos requisitos pueden ser usados en el proceso de especificacin de
requisitos de calidad para un producto software que va a ser desarrollado
como entrada para un proceso de evaluacin.

ISO/IEC 2504n. Divisin de evaluacin de la calidad. Estos estndares


proporcionan requisitos, recomendaciones y guas para la evaluacin de un
producto software, tanto si la llevan a cabo evaluadores, como clientes o
desarrolladores.

ISO/IEC 2505025099. Estndares de extensin SQuaRE. Incluyen


requisitos para la calidad de productos de software Off-The-Self y para el
formato comn de la industria (CIF) para informes de usabilidad.

6.2 ISO/IEC 15504 Software Process Improvement Capability Determination


(SPICE)
ISO / IEC 15504: 2004.

(http://www.iso.org/iso/catalogue_detail.htm?csnumber=38932)

Proporciona informacin general sobre los conceptos de evaluacin de


proceso y su uso en los dos contextos de mejora de procesos y la
determinacin de la capacidad del proceso. En l se describe cmo las
partes de la suite encajan entre s, y proporciona una gua para su
seleccin y uso. Explica los requisitos contenidos en la norma ISO / IEC
15504, y su aplicabilidad a la realizacin de evaluaciones.

ISO / IEC 15504-2: 2003


(http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37458)

Define los requisitos para la realizacin de la evaluacin de proceso como


base para su uso en la mejora del proceso y determinacin de la capacidad.
Evaluacin de proceso se basa en un modelo de dos dimensiones que
contiene una dimensin de proceso y una dimensin de capacidad. La
dimensin de proceso es proporcionado por un modelo de referencia de
proceso externo, que define un conjunto de procesos que se caracterizan
por estados de resultados propsito del proceso. La dimensin de la
capacidad consiste en un marco de medicin que comprende seis niveles
de capacidad del proceso y sus atributos de proceso asociados.
El producto de la evaluacin consiste en una serie de calificaciones de
atributos para cada proceso evaluado, denominado el perfil de proceso, y
tambin puede incluir el nivel de capacidad alcanzado por dicho proceso.
Identifica el marco de medicin de la capacidad del proceso y los requisitos
para:

La realizacin de una evaluacin;

Modelos de referencia de proceso;

Modelos de evaluacin del proceso;

La verificacin de la conformidad de la evaluacin del proceso .

Los requisitos para la evaluacin de procesos definidos en la norma ISO /


IEC 15504-2: 2003 forma una estructura que:

Facilita la autoevaluacin;

Proporciona una base para su uso en la mejora de procesos y la


determinacin de la capacidad;

Tiene en cuenta el contexto en el que se implementa el proceso de


evaluar;

Produce una calificacin de proceso;

Aborda la capacidad del proceso para lograr su propsito;

Es aplicable en todos los dominios de aplicacin y tamaos de


organizacin; y

Puede proporcionar un punto de referencia objetiva entre las


organizaciones.

El conjunto mnimo de requisitos definidos en la norma ISO / IEC 15504-2:


2003 asegura que los resultados de la evaluacin son objetiva, imparcial,
consistente y repetible y representante de los procesos evaluados. Los
resultados de las evaluaciones de proceso conformes pueden compararse
cuando se consideran los alcances de las evaluaciones a ser similares.

ISO / IEC 15504-3: 2004.


(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=37454)

Proporciona una visin general del proceso de evaluacin e interpreta los


requisitos a travs de la provisin de orientacin sobre:

1.

A realizacin de una evaluacin;

2.

El marco de medicin de la capacidad del proceso;

3.

Proceso de modelos de referencia y modelos de evaluacin del proceso;

4.

Seleccin y uso de herramientas de evaluacin;

5.

Competencia de los evaluadores;

6.

Verificacin de la conformidad.

ISO / IEC 15504-4: 2004


(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=37462)

Proporciona orientacin sobre cmo utilizar un proceso de evaluacin


conformes dentro de un programa de mejora del proceso o para la
determinacin de la capacidad del proceso.
Dentro de un contexto de mejora de procesos (PI), la evaluacin del
proceso proporciona un medio para caracterizar una unidad organizativa en
trminos de la capacidad de los procesos seleccionados. Anlisis de la
salida de un proceso de evaluacin conformes respecto a los objetivos de
negocio de una unidad organizativa identifica fortalezas, debilidades y
riesgos relacionados con los procesos. Esto, a su vez, puede ayudar a
determinar si los procesos son eficaces en el logro de los objetivos de
negocio, y proporcionar los controladores para hacer mejoras.
Determinacin de la capacidad del proceso (PCD) se ocupa de analizar los
resultados de una o ms conformes evaluaciones de proceso para
identificar las fortalezas, debilidades y riesgos implicados en la realizacin
de un proyecto especfico utilizando los procesos seleccionados dentro de
una unidad organizativa determinada. Una determinacin de la capacidad
del proceso puede proporcionar una entrada fundamental para seleccin de
proveedores, en cuyo caso se denomina a menudo "determinacin de la
capacidad del proveedor".
ISO / IEC 15504-4: 2004 describe los procesos de PCD y PI y cmo
desplegarlos, y proporciona orientacin sobre
1. La utilizacin de la evaluacin de proceso,
2. Modelo de referencia del proceso de seleccin (s),
3. El establecimiento de la capacidad de destino,
4. La definicin de la entrada de evaluacin,
5. Inferir el riesgo relacionada con el proceso de evaluacin de salida,
6. Medidas de mejora de procesos,
7. Pasos de la determinacin de la capacidad del proceso,
8. Comparabilidad de los anlisis de resultados de las evaluaciones.

ISO / IEC 15504-5: 2012.


(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=60555)

Proporciona una descripcin detallada de la estructura y los componentes


clave del proceso de evaluacin del modelo, que incluye dos dimensiones:
una dimensin de proceso y una dimensin de capacidad. Tambin
introduce indicadores de evaluacin.
ISO / IEC 15504-5: 2012 utiliza las definiciones de procesos de la norma
ISO / IEC 12207: 2008 para identificar un modelo de proceso de
referencia. Los procesos del modelo de proceso de referencia se describen
en el modelo de evaluacin del proceso en trminos de propsito y los
resultados se agrupan en tres categoras de procesos. El proceso de
evaluacin del modelo ampla las definiciones de procesos Modelo de
referencia del proceso mediante la inclusin de un conjunto de indicadores
de rendimiento de proceso de llamadas prcticas de base para cada
proceso. El proceso de evaluacin del modelo tambin define un segundo
conjunto de indicadores de desempeo de los procesos mediante la
asociacin de los productos de trabajo con cada proceso.
ISO / IEC 15504-5: 2012 duplica las definiciones de los niveles de
capacidad y los atributos de proceso de la norma ISO / IEC 15504-2, y se
expande cada uno de los nueve atributos a travs de la inclusin de un
conjunto de prcticas genricas. Estas prcticas genricas pertenecen a un
conjunto de indicadores de la capacidad del proceso, en asociacin con los
indicadores de recursos genricos, y los indicadores de productos
genricos de trabajo.
ISO / IEC 15504-5: 2012 tambin ofrece lo siguiente:

Una declaracin de conformidad de la evaluacin del modelo de


proceso con los requisitos definidos en la norma ISO / IEC 15504-2;

Caractersticas seleccionadas de los productos tpicos de trabajo


para ayudar al evaluador para evaluar el nivel de capacidad de los
procesos;

Guas de estilo para definir las prcticas de base, productos de


trabajo y prcticas genricas para ajustar el modelo de evaluacin
del proceso, y la gua que explica cmo ampliar o adaptar el modelo;

Algunos procesos que complementen el proceso de evaluacin del


modelo.

ISO / IEC 15504-6: 2013


(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=61492)

Constituye un proceso de evaluacin de modelos, conformes con los


requisitos de la norma ISO / IEC 15504-2, para la evaluacin de la
capacidad de proceso de los procesos del ciclo de vida del sistema.
La dimensin del proceso de este modelo de evaluacin de proceso se
basa en el modelo de proceso de referencia contenida en la norma ISO /
IEC 15288.
ISO / IEC 15504-6: 2013 proporciona una nueva dimensin de los procesos
para la evaluacin del modelo de proceso derivado de la referencia de
proceso revisado modelo que figura en la norma ISO / IEC 15288: 2008.
El mbito de aplicacin de la norma ISO / IEC 15504-6: 2013 es consistente
con el alcance de la norma ISO / IEC 15504-5 con el fin de ayudar a la
evaluacin de situaciones en las que se est haciendo de ambos procesos
del ciclo de vida del software y del sistema.
Los usuarios de ISO / IEC 15504-6: 2013 pueden reproducir libremente las
descripciones detalladas que figuran en el modelo de evaluacin ejemplar
como parte de cualquier herramienta o de otro material para apoyar el
desempeo de las evaluaciones de proceso, de modo que pueda ser
utilizado para el fin previsto.

ISO / IEC TR 15504-7: 2008.


(http://www.iso.org/iso/catalogue_detail.htm?csnumber=50519)

Define las condiciones para una evaluacin de madurez de la organizacin,


en base a los perfiles de la capacidad del proceso derivados de la
evaluacin de proceso, y define las condiciones en que dichas evaluaciones
son vlidos.
Madurez de la organizacin es una expresin del grado en que una
organizacin implementa constantemente los procesos dentro de un mbito
definido que contribuye a la consecucin de sus objetivos de negocio
(actuales o proyectadas). Un modelo de madurez de la organizacin se
basa en uno o ms especfica Modelo (s) Evaluacin del proceso, y se
dirige a los dominios y contextos de uso del modelo (s) de referencia de
proceso a partir del cual se deriva el modelo (s) Evaluacin del proceso.
Contiene tambin orientacin sobre la aplicacin de los requisitos para la
construccin de un Modelo de Madurez de la organizacin; en la realizacin
de evaluaciones de madurez de la organizacin; y sobre la aplicacin de
clasificaciones de madurez de la organizacin para la mejora de procesos y
la determinacin de la capacidad.

ISO / IEC 15504-8 TS: 2012


(http://www.iso.org/iso/catalogue_detail.htm?csnumber=50625)

proporciona un ejemplo de un modelo de evaluacin de procesos de


Gestin de Servicios de TI (PAM) para su uso en la realizacin de una
evaluacin de conformidad con arreglo a los requisitos de la norma ISO /
IEC 15504-2. Se permite implementar procesos de la norma ISO / IEC
20000-1 que deben evaluarse de acuerdo con los requisitos de la norma
ISO / IEC 15504-2.
Una parte integral de la realizacin de una evaluacin es utilizar un PAM
que se construye para ese propsito. Un PAM est relacionado con un
modelo de proceso de referencia (PRM) y es conforme con la norma ISO /
IEC 15504-2.

ISO / IEC 15504-9 TS: 2011


(http://www.iso.org/iso/catalogue_detail.htm?csnumber=51684)

Documentos directrices para perfiles de proceso de destino para la


determinacin de la capacidad y la actividad de mejoramiento. Proporciona

una gua para establecer perfiles de proceso objetivo para los siguientes
propsitos:

por o en nombre de una organizacin con el objetivo de especificar


un perfil de proceso de destino para satisfacer las necesidades
especficas;
por o en nombre de una organizacin con el objetivo de especificar
un perfil de proceso de destino que sirve para evaluar la capacidad
real de la organizacin para cumplir con ese objetivo;
por o en nombre de una organizacin con el objetivo de especificar
un perfil de proceso de destino que sirve para evaluar la capacidad
real de otra organizacin para cumplir con ese objetivo;
por o en nombre de una organizacin con el objetivo de determinar la
necesidad de mejora en base a cualquier brecha de capacidades
entre la capacidad real y el perfil de proceso de destino.

6.3 IEEE std 730-2002 Standard for Software Quality Assurance Plans
(http://ingenieria1.udistrital.edu.co/udin1/pluginfile.php/12917/mod_resource/content/1/Estandares
%20para%20el%20Aseguramiento%20de%20la%20Calidad%20del%20Software.pdf)

El estndar IEEE 730 es una recomendacin para elaborar un Plan de


Aseguramiento de la Calidad del Software (SQAP, software Quality Assirance
Plan) para los proyectos de desarrollo de software. Proporciona los requerimientos
mnimos aceptables para la preparacin y el contenido de los planes de
aseguramiento de la calidad de software. El plan SQA sirve como gua de las
actividades de SQA en el proyecto.
Este estndar describe la preparacin y los contenidos de los planes SQA. Las
actividades principales del SQA incluyen la gestin, documentacin, mediciones,
revisiones, testing, informes de problemas y las acciones correctivas, control de
medios de comunicacin, control de proveedores,
gestin de registro,
capacitacin y gestin de riesgos. En las descripciones relacionadas con el plan
de SQA, el estndar IEEE 730 nos proporciona una valiosa informacin sobre
cada una de estas valiosas actividades.
En un plan SQA se pueden aplicar o citar requisitos y directrices establecidas en
otros estndares de la IEEE. Cuando en un proyecto de desarrollo de software se
incluyen un plan de este tipo, las decisiones relacionadas con la calidad deben ser
estudiadas y razonadas suficientemente antes de iniciar el desarrollo. El equipo de
desarrollo debera entonces ajustarse al plan y as mejorar continuamente los
procesos de desarrollo en beneficio del proyecto en curso y de los proyectos
futuros.
Este estndar se aplica (o puede afectar) a tres grupos; el usuario, el poveedor y
el pblico.
a) El usuario, puede ser otro tipo de la misma organizacin que desarrolla el
software, que necesita el producto con un grado razonable de confianza.
b) El proveedor, que necesita establecer un estndar para planificar y medir.

c) El pblico, quede verse afectado por el uso del producto


6.4 ISO/IEC 12207:2008
Procesos del ciclo de vida del software
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?
csnumber=43447)
ISO / IEC 12207: 2008 establece un marco comn para los procesos del ciclo de
vida del software, con la terminologa bien definida, que puede ser referenciado
por la industria del software. Contiene los procesos, actividades y tareas que se
van a aplicar durante la adquisicin de un producto de software o servicio y
durante el suministro, desarrollo, operacin, mantenimiento y eliminacin de
productos de software. El software incluye la parte de software de firmware.
Se aplica a la adquisicin de sistemas y productos de software y servicios, con el
suministro, desarrollo, operacin, mantenimiento y eliminacin de productos de
software y la parte de software de un sistema, bien sea interna o externamente a
una organizacin. Se incluyen aquellos aspectos de la definicin del sistema
necesario para proporcionar el contexto para los productos y servicios de software.
Proporciona un procedimiento que puede ser empleado para definir, controlar y
mejorar los procesos del ciclo de vida del software.
Los procesos, actividades y tareas de la norma ISO / IEC 12207: 2008 - ya sea
solos o en combinacin con la norma ISO / IEC 15288 - Tambin se pueden
aplicar durante la adquisicin de un sistema que contiene el software.

7. Dos modelos de evaluacin de calidad de software (A cada metodologa


realizar los siguientes puntos)
7.1. Nombre
MODELO DE MCCALL

El modelo de McCall fue el primero en ser presentado en 1977 y se origin


motivado por Air Forc y Dod. Se focaliza en el producto final identificando
atributos claves desde el punto de vista del usuario Estos atributos se denominan
factores de calidad y son normalmente atributos externos pero tambin se incluyen
algunos atributos posiblemente internos. Los factores de calidad son demasiados
abstractos para ser medidos directamente, por lo que por cada uno de ellos se
introduce atributos de bajo nivel denominados criterios de calidad. Algunos

criterios de calidad son atributos internos segn McCall que el atributo interno
tiene un efecto directo en el atributo externo correspondiente.
7.2. Explicacin de los elementos del modelo
1. FACTORES DE CALIDAD DE REVISION
2. La revisin del producto incluye los siguientes factores de calidad:
Mantenibilidad esfuerzo requerido para localizar y corregir fallas Flexibilidad
facilidad de realizar cambios Testeabilidad facilidad para realizar el testing,
para asegurarse que el producto no tiene errores y cumple con la
especificacin
3. FACTORES DE CALIDAD DE TRANCISION. La transicin del producto
incluye los siguientes factores de calidad Portabilidad esfuerzo requerido
para transferir entre distintos ambientes de operacin Reusabilidad facilidad
de reusar el software en diferentes contextos Interoperabilidad esfuerzo
requerido para acoplar el producto con otros sistemas
4. FACTORES DE CALIDAD DE OPERACIN La operacin del producto
incluye los siguientes factores de calidad Correctitud el grado en el que el
producto cumple con su especificacin Confiabilidad la habilidad del
producto de responder ante situaciones no esperadas Eficiencia el uso de
los recursos tales como tiempo de ejecucin y memoria de ejecucin
Integridad proteccin del programa y sus datos de accesos no autorizados
Usabilidad facilidad de operacin del producto por parte de los usuarios

7.1. Nombre
MODELO DE BOEHM
El segundo modelo de calidad ms conocido es presentado por Barry Boehm en
1978 Este modelo introduce caractersticas de alto nivel, caractersticas de nivel
intermedio y caractersticas primitivas, cada una de las cuales contribuye al nivel
general de calidad.
7.2. Explicacin de los elementos del modelo
CARACTERISTICAS DE ALTO NIVEL las caractersticas de alto nivel representan
requerimientos generales de uso pueden ser: Utilidadper-se cuan (usable,
confiable, eficiente) es el producto en s mismo Mantenibilidad cuan fcil es
modificarlo, entenderlos y retestearlo. Utilidad general si puede seguir usndose si
se cambia el ambiente

8. Elementos de un proyecto de desarrollo de software

EL PERSONAL
El factor humano siempre ser el ms importante en el desarrollo de soluciones
software, muchos empresarios famosos, lderes de empresas tecnolgicas,
coinciden que el xito que han alcanzado sus empresas no se debe a las
herramientas que utilizan, es la gente y el trabajo en equipo.

EL PRODUCTO
Muchas veces cuando un cliente pide que le construyan una solucin, siempre
pregunta cunto me va a costar? Pues bien, todo producto requiere estimaciones
cuantitativas y una adecuada planificacin. Una adecuada recoleccin de
informacin y un anlisis detallado de los requerimientos proporciona la
informacin necesaria para dar una estimacin del costo del producto. Antes de
planear un proyecto, se debe establecer los objetivos y el alcance que tendr el
proyecto, adems de sus restricciones tcnicas y de gestin. Con una buena
planificacin se puede estimar el tiempo que tomar desarrollar o construir el
producto y redimensionar el valor cuantitativo del producto.

EL PROCESO
El proceso del software proporciona un marco de trabajo desde el cual se puede
establecer un plan detallado para la construccin del software. Todas las
actividades del marco de trabajo se las pueden aplicar a la mayora de proyectos
de software, sino es a todos. El equipo de desarrollo debe elegir el proceso
adecuado y que le permita obtener una solucin o producto que satisfaga las
necesidades o requerimientos del cliente.

EL PROYECTO
Cuando se gestiona un proyecto exitoso, es necesario entender que este puede
llegar a fracasar. Segn John Reel, existen 10 razones por las cuales un proyecto
puede fracasar:
1. El personal de software no entiende las necesidades del los clientes.
2. El mbito del producto est mal definido.
3. Los cambios se gestionan mal.
4. La tecnologa elegida cambia.
5. Las necesidades comerciales cambian.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten a la utilizacin del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10. Los gestores evitan las mejores prcticas y las lecciones aprendidas.

9. Conclusiones
En el desarrollo del trabajo investigativo se pudo concluir, que se entendieron
diferentes metodologas y conceptos tales como:
Disear aplicaciones informticas que se ajusten a las necesidades de las
organizaciones.
Dirigir y coordinar el desarrollo de aplicaciones complejas.
Intervenir en todas las fases del ciclo de vida de un producto.
Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realizacin de pruebas que verifiquen el correcto
funcionamiento de los programas y que se ajustan a los requisitos de
anlisis y diseo.
Disear, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de
aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando mtricas e
indicadores y controlando la calidad del software producido.
10. Bibliografa
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html
http://www.etsisi.upm.es/estudios/grados/software/objetivos
http://www.buenastareas.com/ensayos/Metodologia-3P/5885628.html
http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm
https://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESA
RROLLO+DE+SOFTWARE

http://www.monografias.com/trabajos60/metodologias-desarrollosoftware/metodologias-desarrollo-software.shtml
http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-ytipos-de-software.html

Você também pode gostar