Professional Documents
Culture Documents
INGENIERIA DE SOFTWARE
Presenta
Camilo Andrs Frontado Escobar
Erik Alexis Valderrama
Alejandro Jimnez Mateus
Harold Jhovany Lpez Medina
Docente
Juan Carlos Guevara B.
Asignatura
Ingeniera de software
CONTENIDO
2. Introduccin.2
3. Ingeniera de software...3
3.1. Definicin.....3
3.2. Objetivos.............3
3.3. Caractersticas....4
3.4. Historia............4
4. Modelos de ciclo de vida del software...5
5. Metodologas de desarrollo de software ....13
6. Estndares para garantizar la calidad de software....29
7. Modelos de evaluacin de calidad de software......35
8. Elementos de un proyecto de desarrollo de software.......39
9. Conclusiones....40
10. Bibliografa..41
2. INTRODUCCION
3. INGENIERA DE SOFTWARE
3.1. Definicin
3.2. Objetivos
3.3. Caractersticas
-
3.4. Historia
A principios de los 1980, 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.
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.
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 HTML cambia
drsticamente la visin y recepcin de la informacin.
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.
Modelo en cascada
MODELO EN V: En el modelo en V o tambin conocido como modelo de 4
niveles, se basa en el modelo de cascada pura a diferencia de que contiene
dos sub etapas adicionales, El modelo de ciclo de vida V proviene del principio
que establece que los procedimientos utilizados para probar si la aplicacin
cumple las especificaciones ya deben haberse creado en la fase de diseo.
Modelo en V
La anterior figura muestra como cada una de las fases de desarrollo (izquierda
de la imagen), se alinean con la fase de testeo.
-
Modelo en espiral
-
para
construir
una
ms
Modelo Incremental
Las caractersticas del modelo incremental son las siguientes:
-
El grado de prioridad
Esfuerzo que demanda
Granulidad
Criterios de aceptacin
Es muy frecuente, a la vez de ser una prctica recomendada, que cada tarea
sea a la vez, "etiquetada", diferenciando, por ejemplo, cuando representa un
bug, una tarea de diseo, un test, etc.
Incremento de Funcionalidad: Es el que el equipo entrega al finalizar el
Sprint. El mismo debe asemejarse a un "software funcionando", permitiendo
implementarse operativamente sin restricciones en un ambiente productivo.
Inicio:
-
Documento Visin
Especificacin de Requerimientos
Elaboracin:
-
Construccin:
-
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:
-
Al incorporar controles que regulan las actividades, los flujos de salida de una
actividad pueden actuar como controles e incluso mecanismos en la actividad
precedente o dependiente.
Los diagramas SADT requieren una serie de puntos de partida:
-
Ahora que tenemos nuestros cuatro valores estamos preparados para construir
una Disciplina de Desarrollo de software. Qu tareas debemos de llevar a
cabo para desarrollar un buen software?
Codificar: Es la nica actividad de la que no podremos prescindir. Sin cdigo
fuente no hay programa, aunque hay gente que cuenta que existe software en
produccin del que se perdi el cdigo fuente. Por tanto, necesitamos codificar
y plasmar nuestras ideas a travs del cdigo. En una programacin en PX en
pareja el cdigo expresa tu interpretacin del problema, as podemos utilizarlo
para comunicar, para hacer mas tus ideas, y por tanto para aprender y mejorar.
Hacer pruebas: Las caractersticas del software que no pueden ser
demostradas mediante pruebas simplemente no existen. Las pruebas me dan
la oportunidad de saber si lo que implement es lo que en realidad yo pensaba
que haba implementado. Las pruebas nos indican que nuestro trabajo
funciona, cuando no podemos pensar en ninguna prueba que pudiese originar
un fallo en nuestro sistema entonces has acabado por completo.
Escuchar: Los programadores no lo conocemos todo, y sobre todo muchas
cosas que las personas de negocios piensan que son interesantes. Si ellos
pudieran programarse su propio software para qu nos querran? Si vamos a
hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos
que preguntar a quin necesita la informacin.
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. Los
diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo
complejo, divdela en varias. Si hay fallos en el diseo o malos diseos, estos
deben de ser corregidos cuanto antes.
A continuacin, describimos los artefactos de Xp, entre los que se encuentran:
Historias de Usuario, Tareas de Ingeniera y Tarjetas CRC.
Historias de Usuario
Representan una breve descripcin del comportamiento del sistema, emplea
terminologa del cliente sin lenguaje tcnico, se realiza una por cada
caracterstica principal del sistema, se emplean para hacer estimaciones de
tiempo y para el plan de lanzamientos, reemplazan un gran documento de
requisitos y presiden la creacin de las pruebas de aceptacin.
Estas deben proporcionar slo el detalle suficiente como para poder hacer
razonable la estimacin de cunto tiempo requiere la implementacin de la
historia, difiere de los casos de uso porque son escritos por el cliente, no por
los programadores, empleando terminologa del cliente. "Las historias de
usuario son ms "amigables" que los casos de uso formales".
empresarial de tal manera que se minimicen los impactos que les puedan
brindar a los usuarios para que continen con sus operaciones empresariales
de una manera normal.
Las disciplinas agregadas por EUP son: La disciplina de Modelamiento de
Negocio Empresarial, la que aparte de modelar el negocio del proyecto en
general se basa en especificar las actividades y procesos empresariales de los
cuales se puede extraer informacin que ayuda para saber que nuevos
procesos o actividades, que no se han tomado en cuenta, se pueden
automatizar.
La disciplina de Administracin del Portafolio se basa en organizar los
pequeos componentes de software, que muchas veces se realizan por
separado, con el fin de unificarlos y administrarlos segn los objetivos que cada
uno de estos tengan. La disciplina de Arquitectura Empresarial est relacionada
a modelos que demuestran cmo funcionan los diferentes tipos de arquitectura,
prototipos y buenas prcticas.
Dentro de esta disciplina se toman en cuenta las arquitecturas de negocio,
aplicacin, datos y red; esto organiza el proyecto a un mayor nivel ya que
dentro de cada arquitectura se especifican diferentes tipos de documentos
asociados a estas cuatro ramas que todo software debe contener.
La disciplina de Estrategia de Re-uso, se basa en reutilizar componentes de
software que son necesitados en ms de un proceso, se toma en cuenta su
documentacin y organizacin por cada proceso empresarial.
La Administracin de Recursos Humanos es una disciplina que apoya a la
organizacin de planes, actividades y calendarios segn responsabilidades al
momento del desarrollo de software, a su vez se toma en cuenta las
interacciones entre los colaboradores del proyecto, es decir formacin de
grupos de trabajo.
La disciplina de Administracin Empresarial se basa en el objetivo principal de
definir cmo una organizacin crea, mantiene y administra informacin fsica
del proyecto a realizar. Finalmente, la ltima disciplina aadida por EUP es la
disciplina Mejora de Procesos de Software, sta asegura que la organizacin
pueda definir, implementar y envolver ms de un proceso apropiado brindando
ayuda para conocer las metas finales de tu proyecto determinadas en base a
tus necesidades de negocio.
PRINCIPIOS DE LA AUP:
La AUP es gil, porque est basada en los siguientes principios:
1. El personal sabe lo que est haciendo. La gente no va a leer detallado el
proceso de documentacin, pero algunos quieren una orientacin de alto nivel
y / o formacin de vez en cuando. La AUP producto proporciona enlaces a
muchos de los detalles, si usted est interesado, pero no obliga a aquellos que
no lo deseen.
2. Simplicidad. Todo se describe concisamente utilizando un puado de
pginas, no miles de ellos.
3. Agilidad. gil ARRIBA El ajuste a los valores y principios de la Alianza gil.
4. Centrarse en actividades de alto valor. La atencin se centra en las
actividades que se ve que son esenciales para el de desarrollo, no todas las
actividades que suceden forman parte del proyecto.
5. Herramienta de la independencia. Usted puede usar cualquier conjunto de
herramientas que usted desea con el gil UP. Lo aconsejable es utilizar las
herramientas que son las ms adecuadas para el trabajo, que a menudo son
las herramientas simples o incluso herramientas de cdigo abierto.
6. Adaptacin de este producto para satisfacer sus propias necesidades. La
AUP producto es de fcil acomodo comn a travs de cualquier herramienta de
edicin de HTML. No se necesita comprar una herramienta especial, o tomar
un curso, para adaptar la AUP.
6. ESTANDARES
6.1 IEEE-STD-830: ESPECIFICACIONES DE REQUERIMIENTOS DEL
SISTEMA
La IEEE 830 se centra en el anlisis y desarrollo de requerimientos, es un
documento en el cual se integran los requerimientos del sistema desde
cualquier punto de vista (usuario, cliente y desarrollador), se crea con la base
fundamental de no caer en errores que permitan poner en peligro el proyecto,
incurriendo en coste o impidiendo la entrega estimada de dicha solucin.
Se debe considerar que el ERS (Especificaciones de requerimientos del
sistema) debe comprender la totalidad de los requerimientos funcionales y no
funcionales, estableciendo un acuerdo entre el cliente y el desarrollador, es una
base fundamental en el desarrollo del software. Es decir el desarrollador exige
detalladamente que debe hacer el software, exigiendo paramtricamente Qu
debe hacer el programa?, Cules son los parmetros de entrada y de salida
que intervienen en el proceso?, En qu maquina van a ser ejecutados los
procesos? y Qu tipos de usuarios directa o indirectamente intervendrn en el
sistema?; todas estas preguntas determinan que la satisfaccin del cliente se
adapte a lo que exigi al principio.
Un ejemplo de aplicacin, se puede considerar que en la documentacin de las
tesis de grado para las carreras enfocadas a los sistemas de informacin, la
mayora de universidades exigen una documentacin en donde se analizan los
requerimiento de la empresa cuando se habla de una pasanta en donde se va
a la etapa de levantamiento de informacin en donde se solicita los
requerimientos que se darn para las pautas de la solucin final.
Para ms claro un ejemplo de una tesis de grado de Cedeo Lolima en donde
se especifican los requisitos funcionales y no funcionales para un sistema de
automatizacin de los servicios administrativos en el rea de medicina de la
Universidad de Oriente- Ncleo Monagas.
Aplicacin
Un ejemplo de la aplicacin se puede ver en el documento Una aplicacin de
la norma ISO/IEC 15504 para la evaluacin por niveles de madurez de Pymes
y pequeos equipos de desarrollo, desarrollado por Javier Garzas, Carlos
Manuel Fernandez y Mario Piatinni en la Universidad Autnoma del Estado de
Mxico, en donde se buscaba minimizar los problemas que en la actualidad
PYMEs y pequeos grupos tienen para la bsqueda de mejorar los proceso
con las organizaciones asociadas a procesos de software indexadas.
El documento completo se puede encontrar
http://www.redalyc.org/articulo.oa?id=92217153012 .
en
la
siguiente
url:
Componentes
Propsito: Se debe especificar con claridad cul es el propsito del plan en el
desarrollo del proyecto especfico analizado la ubicacin del proyecto, la
organizacin y los estndares que se usaran.
Referencias: Es donde se establecen las referencias que se usaran en el
proyecto, implica la documentacin que se us en el desarrollo de un buen
escrito, hacer un llamado a los estndares que se estn usando a su vez
informacin adicional que se utiliz de manera implcita.
Roles y Responsabilidades: Identifica personas responsables de cada uno de
los procesos, indicando nombres el rol que poseen y una especificacin de las
actividades de las cuales son responsables dentro del proyecto.
Documentacin: En esta parte se especificada de manera clara y objetiva
toda la informacin que se generara en cada fase del proyecto, esto nos ayuda
a especificar en cada parte del proyecto la informacin que se est generando.
Estndares, prcticas, convenciones y mtricas: Se especifican los
estndares que se usaran, definir las mtricas y la forma en la cual se
obtendrn, tambin solamente se especifican como se usara cada estndar en
cada parte.
Revisiones y auditorias: Se indica el momento y los elementos que se
estarn revisando durante el proyecto, aqu es donde verificamos por los
cuales aseguramos la calidad y verificar los roles que son los encargados uno a
uno.
Reporte de problemas: Especificar los problemas de calidad y la persona
indicada para reportarlos, adems de especificar un mecanismo de resolucin,
aqu se puede verificar de manera preventiva ayudando la calidad del producto,
las personas encargadas y como trabajan.
Tcnicas, herramientas y metodologas: Especifican la metodologa que se
usaran dentro del proyecto, mirando un plan de trabajo. Se indican las
herramientas que se usaran junto con las tcnicas que ayudaran para el
cumplimiento de la metodologa del trabajo.
Mecanismo de control: Indica los mecanismos para asegurar que cada etapa
se lleva a cabo en el tiempo previsto, se verifican las especificaciones de cada
proceso.
Aplicacin
La revista de la Escuela de Administracin de Negocios describi en 1999 una
seccin en donde Saulo Ernesto Rojas Salamanca especificaba la Calidad del
Software en la Industria de la Informtica, donde se ha especificado las
caractersticas del Plan de Aseguramiento de Calidad para intervenir con las
tcnicas de ingeniera, para complementar los modelos para el mejoramiento
de la teora de software.
7. MODELOS DE EVALUACIN DE CALIDAD DE SOFTWARE
Alto nivel
Modelo de
Boehm
Nivel
intermedio
Bajo nivel
Portabilidad, }
Confiabilidad,
Eficiencia, Usabilidad,
Testeabilidad, Facilidad de
entendimiento, flexibilidad
Independencia, Autocontencin, Auto-contencin
Exactitud, Completitud,
Consistencia,
Robustez/integridad,
Accesibilidad, Eficiencia,
Comunicacin, Auto
descripcin, Estructuracin,
Legibilidad, Aumentabilidad
Independencia de dispositivos
Auto-contencin
De confiabilidad:
Auto-contencin
Exactitud
Completitud
Consistencia
Robustez/integridad
De eficiencia
Accesibilidad
Eficiencia de uso de dispositivos
De usabilidad
Robustez/integridad
Accesibilidad
Comunicacin
De testeabilidad
Comunicacin
Auto descripcin
Estructuracin
De entendibilidad
Consistencia
Estructuracin
Concisidad
Legibilidad
De modificabilidad
Estructuracin
Aumentabilidad
9. CONCLUSIONES
10. BIBLIOGRAFIA
http://www.cc.uah.es/drg/b/HispaSWEBOK.Borrador.pdf
http://www.etsisi.upm.es/estudios/grados/software/objetivos
http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-y-tiposde-software.html
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software#Historia
http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo
%20software.pdf
http://vanevargas.jimdo.com/m%C3%B3dulos/modelos/modelo-de-mccall/
http://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase6.pdf
http://image.slidesharecdn.com/iso15504web-101229173148phpapp01/95/isoiec-15504-introduccin-a-la-norma-de-evaluacin-de-procesosde-software-13-728.jpg?cb=1293643937
https://es.wikipedia.org/wiki/Modelo_de_evaluaci
%C3%B3n_de_procesos_software_ISO_15504_SPICE
https://prezi.com/jiybg8h9q3mx/estandares-ansiieee-730-1984-y-983-1986/
http://www.radikewl.com/5055484.html
http://www.ati.es/gt/calidad-sftware/presentacion.htm
http://www.ceisufro.cl/investigacion/lineas-de-investigacion/
http://www.ecured.cu/ISO_15504
http://www.iso15504.es/
http://juanmarcosteoria2.blogspot.com.co/2008/01/normas-iso-12207.html
http://es.slideshare.net/oprbguitar/norma-tecnica-peruana-iso-12207
http://unfviso12207.webcindario.com/index.php?mod=proceso_organizativos
http://es.ccm.net/contents/223-ciclo-de-vida-del-software
http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html
http://www.ecured.cu/Modelo_Espiral
http://ingenieraupoliana.blogspot.com.co/2010/10/modelo-de-desarrolloconcurrente.html
http://tema3isoftware.blogspot.com.co/p/modelos-de-desarrollo-tecnicas-y.html
https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologiascrum.html
https://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
http://e.exam-10.com/doc/10444/index.html?page=7
http://ingenieriadesoftware.mex.tl/63758_AUP.html
http://www.monografias.com/trabajos6/sista/sista.shtml
http://www.desarrolloweb.com/articulos/artefactos-scrum.html
http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP)
http://es.slideshare.net/joseluisdifu/proceso-unificado-gil-aup-17171038
https://prezi.com/24dgrrbjbn91/norma-iso-12207/
https://prezi.com/8ohm8mnwrujq/norma-internacional-iso-iec-122072008/
http://www.monografias.com/trabajos99/articulo-ntp-iso-iec-12207/articulo-ntpiso-iec-12207.shtml
http://tecnomaestros.awardspace.com/estandares_iso.php
http://seispice.blogspot.com.co/2012/05/spiceiso-iec-15504-norma-spiceisoiec.html
http://www.redalyc.org/articulo.oa?id=92217153012
http://geekswithblogs.net/dthakur/archive/2004/09/02/10570.aspx
http://ieee730.blogspot.com.co/
https://standards.ieee.org/findstds/standard/730-2014.html
https://prezi.com/jiybg8h9q3mx/estandares-ansiieee-730-1984-y-983-1986/
http://es.slideshare.net/Juan_Tapias/formato-ieee830srs-lleno
http://www.academia.edu/6647065/Especificaci
%C3%B3n_de_Requisitos_Software_seg%C3%BAn_el_est
%C3%A1ndar_de_IEEE_830
http://es.slideshare.net/mrcordova/ciclo-de-vida-del-software-ieee12207-2011
http://pfsanchez.blogspot.com.co/2007/01/ingeniera-de-software-estndaresdel.html
http://ocw.uc3m.es/ingenieria-telematica/software-decomunicaciones/transparencias/introduccion-a-la-ingenieria-del-software
http://www.monografias.com/trabajos5/inso/inso.shtml
http://es.slideshare.net/soreygarcia/introduccin-a-la-ingenieria-de-software14023309
http://www.siigroup.es/pfw_files/cma/Website/Site_ESP/nuestra_actividad/sprint
.png
http://humanos.uci.cu/wp-content/uploads/2010/03/RUP.png
http://www.opentrends.net/image/image_gallery?uuid=6eeb5c22-26ef-4a1e9f41-299ab942e964&groupId=10156&t=1361534289835
https://lh4.googleusercontent.com/aNCCbl6q23ANOXaakUSLVS9GLperwEuRe
glpkVw23-GijbUaw9EY9l89IuwoG4jloIKRJUJ9ZFghEg95ed41oCQkB3h51eHhw2e-0LURqy9_g_dtjKzqJ3c
https://www.youtube.com/watch?v=8iL-U1ONFJ8
https://www.youtube.com/watch?v=rwTrlieEcuQ