Академический Документы
Профессиональный Документы
Культура Документы
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.
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
(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
(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.
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.
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
No ser tan ingenuo para pensar que el sistema que ests construyendo
ser "EL" sistema que el cliente necesita, y
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.
METODOLOGA 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
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
METODOLOGA XP
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
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.
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
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.
(http://www.iso.org/iso/catalogue_detail.htm?csnumber=38932)
Facilita la autoevaluacin;
1.
2.
3.
4.
5.
6.
Verificacin de la conformidad.
una gua para establecer perfiles de proceso objetivo para los siguientes
propsitos:
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)
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
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