Ingeniería de Software

UNIVERSIDAD TECNOLGICA NACIONAL
Regional La Plata Dto. Sistemas
1.- Introduccin a la Ingeniera del Software
Ingeniera del Software 2010
Introduccin Ingeniera del Software Desarrollo del hardware

Aparicin de procesadores que cada dos aos doblan la capacidad de sus antecesores[1] 1946 ENIAC: Superficie de 160 m2 - 30 TM - capacidad de proceso de 30 KOPS. En 2002 El microprocesador Pentium IV a 2 Ghz ocupa una superficie de 217 mm2 y tiene una capacidad de proceso de 5.300 MTOPS En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware. Ley de Moore: Incremento constante de la capacidad de operacin Miniaturizacin Reduccin de costes para la produccin de hardware
Avance de las comunicaciones entre sistemas.

Consecuencia obvia: ordenadores potentes, de bolsillo, en permanente conexin con grandes sistemas, redes de comunicacin pblicas, sistemas de localizacin GPS, etc. Estas cuatro lneas de avance han extendido el mbito de aplicacin del hardware, e incrementado al mismo ritmo exponencial la complejidad de los sistemas en los que se integra. Los ordenadores ya no son mquinas tiles slo para la banca o el ejrcito. Se encuentran presentes en todos los mbitos, por su capacidad de proceso y de comunicacin pueden ofrecer soluciones a sistemas cada vez ms complejos. Este es el escenario creado por la industria del hardware, y que en las tres ltimas dcadas ha implicado a los desarrolladores de software en retos los que no han sabido responder con solvencia.
[1] Ley de Moore
Introduccin Ingeniera del Software Desarrollo del hardware

Desde 1965 la Ley de Moore rige la evolucin de los microprocesadores
100.000.000 Pentium IV Pentium III 10.000.000 Pentium 486 DX 1.000.000 386 286 100.000 8086 10.000 8080 4004 8008 1970 1975 1980 1985 1990 1995 2000 Pentium II
Factores que imprimen aceleracin al ritmo de crecimiento del hardware: Incremento de la capacidad de operacin. Consecuencias de la ley de Moore Incremento de la miniaturizacin. Reduccin de costes en la produccin. Comunicaciones entre sistemas
Transistores
Crisis de software Proyectos para el desarrollo de sistemas de software

Fracaso 2004 2000 19% 23% 28% 40% Problemtico 53% 49% 46% 33% xito 29% 28% 26% 27%
Introduccin Ingeniera del Software
1998
1995 1994
31%
53%
16%
El proyecto se aborta o el sistema no se llega a utilizar Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas. Problemas funcionales Proyecto realizado en el tiempo previsto, con los costes previstos, con la funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey,
Crisis del software
Este problema se identific por primera vez en 1968, ao en el que la NATO desarroll la primera conferencia sobre desarrollo de software, y en la que se acuaron los trminos crisis del software para definir a los problemas que surgan en el desarrollo de sistemas de software, e ingeniera del software para describir el conjunto de conocimientos que existan en aquel estado inicial. Algunas referencias tiles para comprender cules eran los conocimientos estables para el desarrollo de software en 1968 son:
En 1962 se public el primer algoritmo para bsquedas binarias. C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin
eliminacin de GoTo y la creacin de la programacin estructurada.
para la
En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi su famosa carta GoTo Statement Considered Harmful en 1968. La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb. El primero sobre anlisis de requisitos apareci en 1979
Ingeniera del software

Definicin original:

Fritz Baver, 1968 (conferencia NATO)
Establecimiento y uso de principios de ingeniera para obtener software econmico que trabaje de forma eficiente en mquinas reales.
Otras definiciones Disciplina para producir software de calidad desarrollado sobre las agendas y costes previstos y satisfaciendo los requisitos.
S. Schach 1990, Software Engineering
(1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el desarrollo, operacin y mantenimiento de software; esto es, la aplicacin de la ingeniera al software. (2) El estudio de (1).
IEEE 1993
Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de informtica de las universidades, y por organismos de estandarizacin (SEI, IEEE, ISO) para identificar las causas del problema y definir pautas estndar para la produccin y mantenimiento del software. Los esfuerzos se han encaminado en tres direcciones principales.
Identificacin de los factores clave que determinan la calidad del software. Identificacin de los procesos necesarios para producir y mantener software. Acotacin, estructuracin y desarrollo de la base de conocimiento necesaria para la produccin y mantenimiento de software.
El resultado ha sido la necesidad de profesionalizar el desarrollo, mantenimiento y operacin de los sistemas de software, introduciendo mtodos y formas de trabajo sistemticos, disciplinados y cuantificables. La forma de trabajo de programadores individuales surgida por la necesidad de los primeros programas, ha creado una cultura de la programacin heroica, para el desarrollo de software que es la principal causa de los problemas apuntados, y en la actualidad una de las principales resistencias a la implantacin de tcnicas de ingeniera para el desarrollo de sistemas
Caractersticas deseables de los Productos de Software
Mantenible.
Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones.
Confiable
El software no debe causar danos fsicos o econmicos en el caso de fallos.
Eficiente
El software no debe desperdiciar los recursos del sistema.
Fcil de Usar
El software debe contar con una interfaz de usuario adecuada y su documentacin.
Estndares y modelos

:
La Ingeniera del Software es una ingeniera muy joven que necesitaba
Definirse a s misma: Cules son las reas de conocimiento que la comprenden? Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin del
software
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
Definir criterios unificadores para las tareas de requisitos, pruebas, gestin de la

configuracin, etc
Los estndares son tiles porque: Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de software.
Engloban los conocimientos. Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad. Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones distintas.
Introduccin Ingeniera del Software Principales organizaciones de estandarizacin

Desde la identificacin del fenmeno crisis del software, han sido muchas las organizaciones que han abordado, con mayor o menor rigor, el anlisis de problemas en el desarrollo de sistemas de software. Sus trabajos se han encaminado a la localizacin de las causas; y a la exposicin en textos didcticos, normativos o estndares de procesos o prcticas necesarias para abordar el desarrollo, mantenimiento y operacin con las mayores garantas de xito. Han sido muchos los departamentos de universidades, organismos de normalizacin o investigacin nacionales o internacionales, sociedades de profesionales, departamentos de defensa, departamentos de calidad y procesos de empresas los que han ido generando normas y estndares. Este compendio considera como entidades de mayor reconocimiento internacional, por sus trabajos y esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a: ISO, IEEE- Computer Society y SEI.
Principales organizaciones de estandarizacin
ISO
Organizacin Internacional para la Estandarizacin. Fundada en 1947 Son miembros 87 pases. En 1987 la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y equipos. Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software:
SEI
ISO/IEC 12207 ISO/IEC TR 15504
Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/). Integrado en la Universidad Carnegie Mellon. Los trabajos y aportaciones realizadas por el Instituto de Ingeniera del Software a la Ingeniera del software son tambin referente mundial de primer orden, siendo la aportacin ms significativa los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi 15 aos de implantacin efectiva en entornos de produccin de software han demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para mejora de procesos, y como criterio de evaluacin para determinar la madurez, y por tanto fiabilidad de resultados previsibles de una organizacin de software.
Principales organizaciones de estandarizacin
IEEE Computer Society

IEEE Es el Instituto de Ingenieros en electricidad y electrnica (Institute of Electrical and Electronics Engineers).
Su misin es preservar, investigar y promover la informacin de las tecnologas elctricas y electrnicas. Surgi en 1963 con la fusin del AIEE (Instituto Americano de Ingenieros Elctricos) y el Instituto de Ingenieros de Radio (IRE). La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada en la actualidad por ms de 100.000 miembros en todo el mundo. Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la informacin. Realiza conferencias, publicaciones, cursos de formacin, y desarrolla estndares. Estndares para la Ingeniera del Software IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software. Algunos de ellos, correspondientes a las principales reas especficas de la Ingeniera del Software son:
IEEE IEEE IEEE IEEE IEEE
Std. Std. Std. Std. Std.
830 Prcticas recomendadas para las especificaciones de software. 1362 Gua para la especificacin del documento de requisitos ConOps 1063 Estndar para la documentacin de usuario de software. 1012 Estndar para la verificacin y validacin de software. 1219 Estndar para el mantenimiento del software
Principales estndares y modelos

SWEBOK: Software Engineering Body of knowledge
La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse a s misma: Cules son las reas de conocimiento que la comprenden?
Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

del software ISO/IEC 12207: Procesos del ciclo de vida del software
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software CMM / CMMI ISO/IEC TR 15504
Definir estndares menores para dibujar criterios unificadores en requisitos,

pruebas, gestin de la configuracin, etc.
IEEE 830 - IEEE 1362 - ISO/IEC 14764

SWEBOK
El proyecto SWEBOK (Software Engineering Body of Knowledge) comenz sus actividades de manera efectiva dentro del SWECC1 en 1997 (aunque el comit SWECC se cre en 1993). En el proyecto tambin estn representados: los dos principales organizaciones de estandarizacin en Ingeniera del Software: IEEE e ISO/IEC JTC1/SC/.
Los autores de las tres principales obras de Ingeniera del Software: Steve Mc Connell, Roger Pressman e Ian Sommerville.
Universidad de Qubec (Montreal) Empresas y organizaciones como: Rational, SAP, Boeing, Construx, MITRE, Raytheon, En 2001 el proyecto public ya una definicin consensuada del cuerpo de conocimiento aceptado en la ingeniera del software (http://www.swebok.org).
Las fuentes de informacin para la identificacin de las reas de conocimiento han sido los ndices de textos genricos sobre la Ingeniera del Software, los curricula para licenciatura y postgrado en Ingeniera de Software, y los criterios de admisin que se utilizan en el postgrado. Todos estos datos se han organizado siguiendo el estndar ISO/IEC 12207.
El cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio ms relevante y como la referencia de ms autoridad en toda la comunidad informtica para la acotacin y descripcin de los conocimientos que configuran la Ingeniera del software.
1 Software, Engineering Coordinating Comitee, Comisin creada por IEEE Computer Society y ACM (Association for Computer Machinery) para definir el cuerpo de la Ingeniera del Software
SWEBOK
SWEBOK da el primer paso necesario para constituir a la Ingeniera del Software como profesin: la delimitacin del cuerpo de conocimiento que comprende la profesin. Sin esta delimitacin no es posible validar de forma universal exmenes de licenciatura, no es posible la preparacin para acceder a la profesin, y no hay un consenso sobre el contenido de su currculo. El proyecto parte de la suposicin de que es necesario establecer cul es el cuerpo de conocimiento que deben conocer los ingenieros del software, y en su desarrollo ha agrupado este conocimiento en 10 reas
Requisitos Diseo Construccin Pruebas Mantenimiento
Gestin de la configuracin Gestin Procesos Herramientas y mtodos Calidad
Es importante resaltar que estas reas no incluyen aspectos importantes de las tecnologas de la informacin, tales como lenguajes especficos de programacin, bases de datos relacionales o redes o tecnologa de redes y comunicaciones. Esta es una consecuencia de la distincin que entre esencia y accidente se establece desde un enfoque de ingeniera. Por supuesto que un Ingeniero de Software debe conocer las tcnicas de cada momento, pero la definicin de procesos y metodologa de trabajo es la esencia de la profesin. As por ejemplo, el rea de conocimiento de requisitos, s que puede considerarse como esencia de la profesin. Los problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los requisitos son indistintos del hardware o lenguaje de programacin empleado. Eran los mismos hace dos dcadas que ahora, y todo nos hace suponer que seguirn siendo idnticos dentro de otros cuatro lustros.
ISO 12207: Propsito
Establecer un estndar para evitar una situacin de Torre de Babel en la gestin e ingeniera del software, proporcionando un marco y un lenguaje comn en la disciplina del software
Establece un marco comn para el ciclo de vida del software para Adquisicin, suministro, desarrollo, operacin y mantenimiento del software Gestionar, controlar y mejorar el marco Como base de referencia para el trabajo e intercambio entre organizaciones de software
Ciclo de vida del software

Periodo de tiempo que comienza al concebir la idea de un nuevo sistema de software, y termina cuando este se retira y deja de funcionar.
Introduccin Ingeniera del Software ISO 12207: Propsito

El estndar no prescribe:
Que deba emplearse ningn tipo de documentacin especfica. Que deba emplearse un tipo especfico de ciclo de desarrollo. Mtodos concretos para el desarrollo, mantenimiento u operacin del software.
Define el QU, no el CMO. Dice cules son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y operacin de los sistemas de software, asentando un marco estndar de referencia internacional, pero no se ocupa ni prescribe tcnicas especficas. El estndar sirve de referencia desde dos perspectivas diferentes: Para la adquisicin de sistemas y servicios de software. Para el suministro, desarrollo, mantenimiento y operacin de productos de software. No se trata de un estndar de certificacin, tipo ISO 9000, sino de un estndar para la normalizacin.
El estndar no cubre el desarrollo de productos de software para distribucin comercial masiva (productos enlatados).
Introduccin Ingeniera del Software ISO 12207: Procesos

5. Procesos primarios
5.1 Adquisicin 5.2 Suministro
6.- Procesos de soporte

6.1 Documentacin 6.2 Gestin de la configuracin 6.3 Control de calidad
5.3 Operacin 5.3 Desarrollo 5.3 Mantenimiento
6.4 Verificacin 6.5 Validacin 6.6 Reuniones 6.7 Auditora 6.8 Resolucin de problemas
7. Procesos organizacionales
7.1 Gestin 7.3 Mejora 7.2 Infraestructura 7.4 Formacin
ISO 12207

Actividad 1 Tarea 1 Proceso 1 Tarea 2
ISO 1227 define los procesos que componen el ciclo de

vida del software
Tarea n
Proceso N Actividad n
Ciclo de vida
Concepto Retirada
Tarea 1
Tarea 2
Tarea n
ISO 12207

PROCESO
ACTIVIDAD 1 ACTIVIDAD n
Un proceso est compuesto por actividades.

Una actividad est compuesta de tareas.
TAREA 1
TAREA X
TAREA 1
La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de

mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora) INICIO
PLAN
Tareas, agenda, asignaciones
ACT
Problemas y acciones correctivas
PROCESO
DO
Ejecucin de planes y tareas
CHECK
Evaluacin y medicin
FIN
INGENIERA DE SISTEMAS
ISO 12207 establece un nexo con la Ingeniera de sistemas al considerar al software como
parte de un sistema. Desde esta perspectiva se establece a la Ingeniera de sistemas como fundamento de la Ingeniera del Software.
Qu es un sistema?
Coleccin de componentes organizados para cumplir una funcin o conjunto de funciones

especficas.
Sistema de Entrada
IEEE Standard 610.12-1990

Elemento del sistema
Sistema
Sistema de Salida
Coleccin de elementos relacionados de forma que puedan realizar un objetivo tangible.

Pressman 1982
Introduccin Ingeniera del Software INGENIERA DE SISTEMAS

Sistema
Conjunto de elementos de hardware, software, personas, procedimientos, herramientas y otros

factores organizativos, organizados para llevar a cabo un objetivo comn.
Sistema de Software
Sistema o sub-sistema formado por una coleccin de programas y documentacin que de forma
conjunta satisfacen unos determinados requisitos. Un sistema de software puede ser en s mismo un sistema independiente que, por ejemplo, realiza su objetivo en un ordenador independiente. A este tipo de sistemas se les denomina tambin sistema intensivo de software, porque el sistema es prcticamente software. Un sistema de software puede ser tambin una parte de un sistema mayor. En cuyo caso se trata en realidad de un sub-sistema de software. P ej: El sistema SW de un avin de combate es en realidad un subsistema de SW del avin.
Ingeniera de sistemas
El trmino Ingeniera de sistemas surgi por primera vez en 1956, y fue propuesto por H. Hitch,
presidente del departamento de Ingeniera Aeronatica de la Universidad de Pensilvania, para intentar desarrollar una disciplina de ingeniera que pudiera abarcar el desarrollo de grandes sistemas que empleaban diversas disciplinas de ingenieras especficas: construccin de bombarderos, submarinos, etc. Los principios de Ingeniera de sistemas desarrollados en los 60 y 70 se aplicaron en programas como el Apolo, o el programa de misiles balsticos USAF/USN.
Algunas definiciones
Ingeniera de sistemas comprende la funcin de gestionar todo el esfuerzo de desarrollo para

conseguir un balance ptimo entre todos los elementos del sistema. Es el proceso que transforma la necesidad operacional en la descripcin de los parmetros del sistema, e integra esos parmetros para mejorar la eficiencia general del sistema. Defense Systems Management College, 1989
Los procesos de ingeniera de sistemas integran las secuencias de actividades y decisiones que
transforman la definicin de una necesidad en un sistema, que con un ciclo de vida optimizado, consigue un balance ptimo de todos sus componentes. USAF, 1985
La principal funcin de la ingeniera de sistemas es garantizar que el sistema satisface los

requisitos durante todo el ciclo de vida. Todas las dems consideraciones se alinean sobre esta funcin. Wymore 1993
La ingeniera de sistemas define el plan para gestionar las actividades tcnicas del proyecto. Identifica el ciclo de desarrollo y los procesos que ser necesario aplicar. Desde la Ingeniera de Sistemas se desarrolla la lnea base tcnica para todo el desarrollo, tanto de hardware como de software.
Funciones de la Ingeniera de sistemas
Definicin del problema: Determinacin de las expectativas hacia el producto, necesidades y

restricciones obtenidas y analizadas en los requisitos del sistema. Trabaja cerca del cliente para establecer las necesidades operacionales.
Anlisis de la solucin: Determinar las opciones posibles para satisfacer los requisitos y las
restricciones. Estudiar y analizar las posibles soluciones. Seleccionar la mejor, sopesando las necesidades inmediatas, opciones de implementacin, utilidad, evolucin del sistema
Planificacin de los procesos: Determinar los grupos de tareas tcnicas que se deben
realizar, el esfuerzo requerido para cada una, su prioridad y los riesgos que implican para el proyecto.
Control de los procesos: Determinar los mtodos para controlar las actividades tcnicas del
proyecto y los procesos; la medicin del progreso, revisin de los productos intermedios y ejecucin de las acciones correctivas, cuando corresponda.
Evaluacin del producto: Determinar la calidad y cantidad de los productos elaborados, a

travs de evaluaciones, pruebas, anlisis, inspecciones
Introduccin Ingeniera del Software INGENIERA DE SISTEMAS

Ingeniera de sistemas Ingeniera de sistemas de software Ingeniera del software
Anlisis del sistema
Pruebas del sistema

Pruebas de integracin del sis
Diseo del sistema
Ingeniera de sistemas Ingeniera de sistemas de software
Anlisis de requisitos del sw
Pruebas del sistema de sw
Diseo de la arquitectura del sw
Pruebas de integracin del sw
Diseo detallado del software
Pruebas del subsistema de SW.
Codificacin Pruebas unitarias

Gestin de Proyectos
Ingeniera de sistemas Gestin de proyectos Ingeniera del Soft.
Planificacin Organizacin Personal Direccin Control
Ingeniera de Sistemas
Ingeniera del Software
Definicin del problema Anlisis de la solucin Planificacin de procesos Control de procesos Evaluacin del producto
Diseo del software Codificacin Pruebas unitarias Integracin del subsistema de software
Definicin de Ingeniera de Software.

Es una disciplina o rea de la informacin o ciencias de la computacin, que ofrece mtodos o tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. La Ingeniera del Software trata de reas muy diversas de la informtica y de las ciencias computacionales, tales como constantes de compiladores, sistemas operativos o desarrollos de Internet.
Caractersticas y evolucin del software

un poco de historia Primeras dcadas: Desarrollar el hardware Reducir costes de procesamiento y almacenamiento Dcada de los ochenta: Desarrollo de la microelectrnica Mayor potencia de clculo y reduccin de costes Objetivo actual: mejorar la calidad de las soluciones software. 1965 - 1975
Multiusuario Tiempo real Bases de datos Software como producto Mayores gastos de mantenimiento Sistemas distribuidos Inteligencia Artificial Hardware de bajo coste Impacto en el consumo Redes area local y global Gran demanda
1959 - 1965
Orientacin por lotes Distribucin limitada Software a medida
1975 - 1989
Potentes sistemas de sobremesa Tecnologa de objetos Sistemas expertos Redes neuronales Cliente/servidor Tecnologas de Internet.
1989 -
AUMENTAN los problemas del desarrollo de software: Subexplotacin del potencial del hardware
Incapacidad de atender a la demanda Incapacidad de mantener el software existente
Caractersticas y Evolucin del Software

Software programas archivos de configuracin documentacin de la estructura del sistema manuales de instalacin y uso sitios web con informacin y actualizaciones Tipos de Software productos genricos sistemas producidos por una organizacin y que se venden en el mercado abierto sistemas gestores de bases de datos, procesadores de texto, paquetes grficos,... la organizacin controla la especificacin Productos Personalizados desarrollados especficamente para un cliente aplicaciones de negocio, sistemas de control de trfico areo, control de procesos de fabricacin,... el cliente controla la especificacin de la aplicacin
Caractersticas y Evolucin del Software

El software desde una perspectiva industrial El valor del software: de elemento aadido a principal elemento de coste
El desarrollo del software:
Algunas preguntas: Por qu se tarda tanto? (y casi siempre ms de lo previsto) Por qu la productividad es tan baja? Por qu cuesta tanto? Por qu siempre quedan errores sin localizar?
Naturaleza y Problemas del Desarrollo de Software

El software como elemento lgico. Se desarrolla, no se fabrica: Calidad del diseo. Costes ms importantes en la ingeniera Gestin especial de los proyectos Se deteriora con el mantenimiento Desarrollo a medida (ausencia de componentes) La crisis del software: problemas que aparecen en el desarrollo del software al desarrollar, mantener y atender la demanda de nuevas aplicaciones.
Sin tiempo para recoger datos histricos Planificacin y estimaciones imprecisas Dificultad de mantener el software existente Insatisfaccin del cliente Calidad Baja productividad
Naturaleza y Problemas del Desarrollo de Software

Causas de la crisis del software Naturaleza lgica del software Mala gestin de los proyectos ( ausencia de datos, deficiente comunicacin, ...) Ausencia de entrenamiento formal en nuevas tcnicas (programadores MITOS DE GESTIN vs. ingenieros de software) - Uso de estndares Resistencia al cambio - Uso de herramientas Mitos del software: - Mala planificacin: aumento
de programadores
MITOS DE LOS DESARROLLADORES - Programa funcionando = fin del trabajo - Calidad = el programa se ejecuta sin errores - Entrega al cliente: programa funcionando
MITOS DEL CLIENTE - Requisitos establecidos como una declaracin general de objetivos - Flexibilidad del software ante los cambios
La Ingeniera del Software

Definiciones establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico, fiable, eficiente y que satisfaga las necesidades del usuario disciplina que comprende todos los aspectos de la produccin de software, desde las etapas iniciales hasta el mantenimiento: disciplina de ingeniera: aplicacin de teoras, mtodos y herramientas para solucionar problemas, y teniendo en cuenta restricciones financieras y organizativas todos los aspectos de produccin: comprende procesos tcnicos del desarrollo y actividades como la administracin de proyectos, desarrollo de herramientas, mtodos y teoras Actividad de modelado solucin de problemas adquisicin de conocimiento dirigida por una fundamentacin
La Ingeniera del Software

Trata de ser la respuesta a la crisis del software Combinacin de elementos:
mtodos completos para todas las fases
mejores tcnicas de control de calidad
mejores elementos de programacin
herramientas para automatizar los mtodos

filosofa de coordinacin, control y buena gestin
Modelado
Modelado: mtodo bsico de la ciencia Modelo Representacin abstracta de un sistema que da respuesta a preguntas sobre el sistema tiles cuando se manejan sistemas grandes, pequeos, complicados o caros para tener una experiencia de primera mano Permiten visualizar y comprender sistemas que no existen o que slo se supone que existen Ejemplos: Biologa: modelos de dinosaurios a partir de restos Fsica: modelos que representan cmo se renen materia y energa en los niveles subatmicos ms bajos El sistema en el mundo real seran dinosaurios o partculas subatmicas
modelos
Modelado
Los ingenieros de software necesitan Comprender el ambiente de funcionamiento del sistema: construyen modelos del dominio del problema (sistemas de bolsa, control de trfico areo,...) Comprender los distintos sistemas que podran construir para evaluar alternativas: construyen modelos del dominio de la solucin Tcnicas y herramientas para construir los modelos (por ejemplo, diagramas de UML)
SIST EMA DE PAGOS Y FACT URACIN Solicitar bienes o servicios
<<subsistema>>
Sistema de visin
Hojear facturas
iniciador Confirmar pedido iniciador
<<subsistema>>
<<subsistema>> Controlador del brazo <<subsistema>> Controlador del asidero
Enviar factura al comprador iniciador iniciador
<<subsistema>>
Sistema de identificacin de objetos
Vendedor
Pagar factura
Comprador
<<extend>> iniciador
Planificar pago factura
Rechazar factura
Realizar transaccin
Pagar recargo por saldo deudor
<<subsistema>>
Pagar factura en da vencimiento

Sistema de cuentas bancarias
<<subsistema>>
Sistema de seleccin de embalajes
<<subsistema>> <<subsistema>> Sistema de embalaje

Controlador de cinta transportadora
Enviar aviso
Solucin de Problemas
Los ingenieros de software buscan una solucin adecuada, en varios pasos: 1. Formular el problema 2. Analizar el problema 3. Buscar soluciones 4. Decidir la solucin ms adecuada 5. Especificar la solucin Actividades bsicas del desarrollo 1. obtencin de requerimientos 2. anlisis 3. diseo del sistema 4. implementacin Otras actividades del desarrollo para evaluar la adecuacin de los modelos revisiones del anlisis: el modelo del dominio del problema se compara con la realidad del cliente revisiones del diseo: el modelo del dominio de la solucin se compara con los objetivos del proyecto pruebas: el sistema se valida contra el modelo del dominio de la solucin administracin del proyecto: se compara el modelo del proceso de desarrollo (calendario y presupuesto) con la realidad (trabajos entregados y recursos gastados)
Participantes y Papeles
Participantes: todas las personas involucradas en el proyecto Cliente: encarga y paga el sistema Desarrolladores: construyen el sistema (analistas, diseadores, programadores,...) Gerente o director del proyecto: planifica y calcula el presupuesto, coordina a los desarrolladores y cliente Usuarios finales: los que van a utilizar el sistema Papel (rol) Conjunto de responsabilidades en el proyecto o en el sistema Asociado con un conjunto de tareas y se asigna a un participante Un mismo participante puede cumplir varios papeles
Otros Conceptos de la Ingeniera del Software

Sistemas y Modelos Sistema: realidad subyacente Modelo: cualquier abstraccin de la realidad Productos de trabajo Artefacto o elemento que se produce durante el desarrollo (documento, fragmento de software,...) Dos tipos: Producto de trabajo interno: producto para el consumo interno del proyecto (por ejemplo, una revisin de la estructura de la base de datos, resultados de pruebas para el gerente,...) Entrega: producto de trabajo para un cliente (especificacin de requisitos, manual de usuario, producto final,...) Actividades, Tareas y Recursos Actividad (o fase): conjunto de tareas que se realiza con un propsito especfico (obtencin de requisitos, entrega, administracin,...) que pueden componerse de otras actividades Tarea: unidad elemental de trabajo que puede ser administrada; consumen recursos, dan como resultado productos de trabajo y dependen de productos de trabajo producidos por otras tareas Recursos: bienes que se utilizan para realizar el trabajo: tiempo, equipamiento y recursos humanos al planificar, el gerente divide el trabajo en tareas y les asigna recursos

Objetivos, requerimientos y restricciones Objetivos: principios de alto nivel que se utilizan para guiar el proyecto definen los atributos realmente importantes del sistema (seguridad, fiabilidad,...) a veces hay conflicto entre objetivos (por ejemplo, seguridad y bajo coste) que aumentan la complejidad del proyecto Requerimientos caractersticas que debe tener el sistema requerimiento funcional: rea de funcionalidad que debe soportar el sistema (por ejemplo, proporcionar billetes de tren) requerimiento no funcional: restriccin que se establece sobre el funcionamiento del sistema (por ejemplo, proporcionar billetes de tren en menos de un segundo) Otras restricciones: por ejemplo, utilizacin de un determinado lenguaje, de una determinada plataforma o de un sistema antiguo que el cliente no quiere retirar

Notaciones, Mtodos y Metodologas Notacin: conjunto de reglas grficas o de texto para representar un modelo (UML, Unified Modelling Language, es una notacin grfica orientada a objetos para representar modelos) Mtodo: tcnica repetible para resolver un problema especfico. Por ejemplo: un algoritmo de ordenacin es un mtodo para ordenar elementos en una lista la administracin de la configuracin es un mtodo para el seguimiento de los cambios Metodologa: coleccin de mtodos para la resolucin de una clase de problemas (OMT, metodologa de Booch, Catalysis, Proceso Unificado de Desarrollo,...)
Actividades de Desarrollo
ReservaBilletes
Viajero
CompraBillete
Anulacin reserva
Nombre del caso de uso: Actor participante:
CompraBillete Iniciado por Viajero
Precondicin: 1. El Viajero se para frente al distribuidor automtico de billetes Flujo de eventos: 2. El Viajero selecciona las estaciones de origen y destino 3. El DistribuidorDeBilletes muestra el precio del billete 4. El Viajero inserta una cantidad de dinero que, al menos, debe ser igual que el precio del billete 5. El DistribuidorDeBilletes emite el billete especificado al Viajero y devuelve el cambio si es necesario Postcondicin: 6. El Viajero coge el billete y el cambio Requisitos especiales: Si la transaccin no ser termina despus de un minuto de inactividad, el DistribuidorDeBilletes devuelve todo el dinero insertado
ingeniera de requerimientos el cliente y los desarrolladores definen el propsito y objetivos del sistema resultado: descripcin del sistema en trminos de participantes (actores) y funciones (casos de uso) actores: entidades externas que interactan con el sistema (incluyen roles como usuarios finales u otros sistemas con los que interacta el sistema) casos de uso: secuencias de eventos que describen todas las acciones posibles entre un actor y el sistema para una funcin especfica. se acuerdan requisitos no funcionales. Por ejemplo: el distribuidor de billetes debe estar disponible al menos un 95% del tiempo el distribuidor de billetes debe dar respuesta en menos de un segundo despus de seleccionada la transaccin
Anlisis Se produce un modelo correcto, completo, consistente, claro, realista y verificable Transformacin de los casos de uso en un modelo que describe por completo el sistema y que se usar en el diseo Descubrimiento y resolucin con el cliente de ambigedades e inconsistencias en el modelo de casos de uso
Transaccin
da como resultado cantidad pagada
BilleteTren
Saldo
vlido para
Moneda
Papel
Zona
Gestin facturas comprador
Gestin de planificacin de pagos
Gestin de cuentas
Diseo Diseo del sistema Definicin de los objetivos de diseo Descomposicin del sistema en subsistemas abordables por equipos Seleccin de estrategias para la construccin (plataformas hardware y software, almacenamiento de datos persistentes, control de acceso,...) Resultado: descripcin de las estrategias, descomposicin en subsistema
IU Solicitud de pago
Comprador Procesamiento de solicitudes de pago
Diseo de objetos: Definicin de objetos e interfaces de subsistemas, reestructuracin del modelo de objetos para lograr los objetivos de diseo, optimizacin del modelo para mejorar el rendimiento,... Resultado: modelo de objetos detallado
Procesamiento de facturas
Planificador de pagos
Gestor de pedidos
Solicitud de pago
Confirmacin de pedidos
Factura
Actividades del diseo Diseo arquitectnico Especificacin de los subsistemas Diseo de interfaz Diseo de componentes Diseo de la estructura de datos Diseo procedimental (algoritmos)
<<subsystem>> Gestin Trabajos Externos <<subsystem>> Gestin Sistema <<subsystem>> Mantenimientos de Gestin
<<subsystem>> Gestin Mantenimiento Correctivo
<<subsystem>> Validacin Usuarios
<<subsystem>> Gestin Instalaciones
<<subsystem>> Gestin Mantenimiento Preventivo <<subsystem>> Gestin Mquinas Subgrupo
<<subsystem>> Gestin Subgrupos-Instalaciones
<<subsystem>> Gestin Trabajos Externos <<subsystem>> Gestin Sistema
Alta Instalaciones
<<subsystem>> Mantenimientos de Gestin
<<include>>
<<include>> Baja Instalaciones <<include>>
<<subsystem>> Gestin Mantenimiento Correctivo
<<subsystem>> Validacin Usuarios
<<subsystem>> Gestin Instalaciones
Validar Usuario Administrador

(from Validacin Usuarios)
<<include>> Modificacin Instalaciones
<<subsystem>> Gestin Mantenimiento Preventivo <<subsystem>> Gestin Mquinas Subgrupo
<<subsystem>> Gestin Subgrupos-Instalaciones
Operario
Consulta Instalaciones
<<subsystem>> Gestin Mquinas

Alta Caractersticas-Maq <<include>> <<include>>
Gestin Caractersticas Mquinas
Gestin Tareas Mquinas

Administrador
Baja Caractersticas-Maq <<include>> Validar Usuario <<include>> Modificacin Caractersticas-Maq

Operario
Consulta Caractersticas-Maq
Nombre Prioridad Actor Extends Includes Pre-Condiciones Post-Condiciones Alta Caractersticas Mquina Media Administrador Ninguno Validar Usuario 1. El usuario est identificado. 2. El usuario selecciona la opcin de altas en el formulario. 1. Los datos de la nueva caracterstica quedan guardados si el proceso finaliza correctamente. 2. Los datos de la nueva caracterstica no quedan guardados si se produce algn error durante el proceso. 1. El sistema muestra el formulario de altas. 2. El usuario introduce los datos. 3. El sistema realiza la validacin de los datos. 4. Si la caracterstica ya existe [A]. 5. Si los datos no son correctos [B]. 6. El usuario selecciona la opcin de Guardar. 7. El sistema guarda los datos. 8. Si se guarda correctamente se visualiza un mensaje, si hay algn problema el sistema avisa con un mensaje de error. El proceso se puede cancelar en cualquier momento. A. Si la caracterstica ya existe se visualizan sus datos. B. Datos incorrectos, ir a punto 2.
: Administrador Opciones Frm Cliente CT RL Alta Instalacin Form_Alta Validar Datos INST ALACION Resultado Alta MENSAJES Seleccionar Crea() Crea()
Descripcin
Mostrar
Introducir Datos() Comprobar() Obtener Datos
Excepciones
...
Mostrar(Datos)
Si no Existe
Cubrir_Datos() Comprobar()
Alta Caractersticas-Maq
Datos Correctos Crear_Alta()
<<include>>
Construir
<<include>> Baja Caractersticas-Maq <<include>> Validar Usuario Administrador

Visualizar Resultado
Datos no Correctos
Construir
<<include>> Modificacin Caractersticas-Maq
Visualizar Mensaje Fin Si Fin Si
Operario
Nombre Prioridad Actor Extends Includes Pre-Condiciones Post-Condiciones Alta Caractersticas Mquina Media Administrador Ninguno Validar Usuario 1. El usuario est identificado. 2. El usuario selecciona la opcin de altas en el formulario. 1. Los datos de la nueva caracterstica quedan guardados si el proceso finaliza correctamente. 2. Los datos de la nueva caracterstica no quedan guardados si se produce algn error durante el proceso. 1. El sistema muestra el formulario de altas. 2. El usuario introduce los datos. 3. El sistema realiza la validacin de los datos. 4. Si la caracterstica ya existe [A]. 5. Si los datos no son correctos [B]. 6. El usuario selecciona la opcin de Guardar. 7. El sistema guarda los datos. 8. Si se guarda correctamente se visualiza un mensaje, si hay algn problema el sistema avisa con un mensaje de error. El proceso se puede cancelar en cualquier momento. A. Si la caracterstica ya existe se visualizan sus datos. B. Datos incorrectos, ir a punto 2.
Sistema (from Validar Usuario) Administrador (from Alta Mquinas)
Administrador Validado
Descripcin
Visualizar Formulario
Seleccionar Formulario
Comprobar Datos
Introducir Datos
Excepciones
Datos Incorrectos
Mensaje "Error Datos"
Datos Correctos
Comprobar Existencia de la Instalacin
Si Exi ste
Visualizar Datos Instalacin Seleccionar Guardar
No Existe
Alta Caractersticas-Maq
<<include>> <<include>>
Guardar Datos Instalacin

Error al Guardar
Baja Caractersticas-Maq <<include>> Validar Usuario Administrador

Instalacin Guardada
Mensaje "Error"
<<include>> Modificacin Caractersticas-Maq
Mensaje "Instalacin guardada"
Operario
Registra-venta-de Descrita-por 1 n 0..1 LineaDeVenta cantidad 1..n Contenida-en Registra-completas 1 Venta fecha hora 1 Pagada-mediante 1 Pago cantidad n 1 1 Iniciada-por 1 Cliente 1 Cajero Capturada-en 1 CatalogoDe Productos Especificacion DelProducto Contiene descripcin 1 1..n precio articuloID 1 Utilizado-por n Abastece 1 n Articulo 1..n
Tienda direccin nombre
1 Alberga 1..n Registro 1 1 1
Iniciado-por
1 Encargado
Registra-ventas-en
Servidor
ODBC
SGBD
TCP/IP
TCP/IP Cliente
Red Local
Impresora
TCP/IP
Cliente
Implementacin Traduccin del modelo de diseo (por ejemplo, del modelo de objetos) en cdigo fuente Incluye: implementacin de atributos y mtodos de cada objeto integracin de todos los objetos para que funcionen como un solo sistema Pruebas Pruebas de unidad: comparacin del modelo de diseo con cada objeto y subsistema Pruebas de integracin: combinaciones de subsistemas y comparacin con el modelo de diseo del sistema Pruebas del sistema: ejecucin de casos tpicos y excepcionales, y comparacin con el modelo de requerimientos Objetivo: descubrir la mayor cantidad posible de errores que se puedan reparar antes de entregar el sistema Mantenimiento Mejoras en el sistema (nuevas funciones, facilidad de uso,...) Correccin de errores Adaptacin a cambios en el entorno (hardware, software, legislacin,...) Actividad ms costosa del ciclo de vida de un producto software
Actividades de administracin del desarrollo Comunicacin Actividad crtica y costosa en tiempo Intercambio de modelos y documentos, informes de evolucin y calidad, negociaciones, comunicacin de decisiones,... Herramientas y notaciones Gestin de la Configuracin Proceso que supervisa y controla los cambios en los productos de trabajo Cambios: requerimientos, plataformas hardware y software, errores encontrados, mejoras del sistema,... Administracin del proyecto Objetivo: asegurar la entrega de un sistema de alta calidad a tiempo y dentro del presupuesto Planificacin y presupuesto del proyecto Contratacin de desarrolladores y coordinacin de equipos Vigilancia de la evolucin del proyecto Deteccin de desviaciones e intervencin
El Proceso de Desarrollo
CMM (Capability Maturity Model)

Proporciona una Gua sobre como
controlar los procesos:
de desarrollo del software. de mantenimiento.
Hacer evolucionar hacia una cultura de:

Ingeniera del software. Gestin eficiente.
Evolucin de las organizaciones segn el CMM

Control del Proceso Medicin del Proceso Definicin del Proceso Control Bsico
Mejorado
Gestionado
Definido
Repetible
Completa rea Procesos
Inicial Incompleto
Correlacin entre estimaciones y niveles de madurez
Nivel Incompleto
El rea del proceso (por ejemplo, la gestin de requisitos) an no se realiza o todava no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad.
Nivel Inicial
Segn las circunstancias utilizamos un proceso distinto. (algunos caticos) A medida, Poco formalizado, Uso de herramientas informales. Pocos procesos definidos. El xito depende del esfuerzo individual.
Nivel Repetible
Se tiene procesos estables de desarrollo, con control estadstico. Uso de datos historicos Establecimiento de procesos de gestin de proyecto, para hacer seguimiento de:
Coste. Planificacin. Funcionalidad.
Nivel Definido
Proceso de desarrollo perfectamente definido y estandarizado. Integrado en la organizacin. Bien documentado. Todos los proyectos utilizan una versin documentada y aprobada de proceso.
Nivel Gestionado
Mejoras de calidad sustanciales. Control cuantitativo de productos y proceso a travs de
Mediciones del proceso comprensibles. Mediciones de la calidad
Nivel Mejorado
A travs de mediciones del proceso utilizando ideas y tecnologas innovadoras obtenemos:
Mejoras en calidad y cantidad.
El Proceso: Modelos de Desarrollo

Proceso Conjunto ordenado de tareas, una serie de pasos que involucran actividades, restricciones y recursos, que producen una salida determinada Proceso de software: conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software Caractersticas Tiene una serie de actividades principales Utiliza recursos, est sujeto a restricciones y genera productos intermedios y finales Compuesto por subprocesos que se encadenan de alguna forma Cada actividad tiene sus criterios de entrada y salida, que permiten conocer cuando comienza y termina dicha actividad Existen principios orientadores que explican las metas de cada actividad Cuando implica la construccin de un producto, se suele llamar ciclo de vida Aportan consistencia y estructura sobre el conjunto de actividades, lo que permite realizar la misma tarea correctamente de forma repetida Existen diferentes modelos de proceso
Requisitos del usuario
Proceso de desarrollo de Software
Sistema software
Modelo en Cascada
Requerimentos y Anlisis Diseo Implementacin Pruebas Mantenimiento
resultado de cada fase: uno o ms documentos aprobados una fase comienza cuando la anterior termina en la prctica, las etapas se solapan iteraciones de coste elevado y reelaboracin del trabajo: tendencia a la congelacin de partes del desarrollo (especificaciones,...)
se retrasa la localizacin y correccin de errores pueden producir sistemas poco tiles para usuarios o mal estructurados inflexibilidad del modelo: dificultad para responder a cambios en los requerimientos
Desarrollo Evolutivo
Basado en: Desarrollo de una implementacin inicial Exposicin a comentarios y crtica del usuario Refinamiento a travs de diferentes versiones hasta llegar a un sistema adecuado
Recoleccin y refinamiento de requisitos Producto Diseo rpido
dos tipos:
prototipado evolutivo:
trabajo con cliente para explorar sus requerimientos y entregar un sistema final evolucin continua del prototipo mediante la agregacin de funciones y caractersticas propuestas por el cliente
prototipos desechables
comprensin de las necesidades del cliente desarrollo de una definicin mejorada de los requerimientos del sistema prototipos centrados en la experimentacin de requisitos poco claros o complejos
problemas
Refinamiento del prototipo Evaluacin del prototipo por el cliente Construccin del prototipo
prisas del cliente (utilizacin del prototipo como sistema final pasar elecciones debidas al prototipo a la implementacin final (entorno, sistema operativo,...) estructura deficiente evolucin del proceso difcil de gestionar herramientas y tcnicas especiales poco adecuado para grandes sistemas
Actividades Concurrentes
Especificacin
Versin Inicial
Descripcin del sistema
Desarrollo
Versiones Intermedias
Validacin
Versin Final
Problemas y Riesgos con los Modelos

Cascada

Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseo. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida.
Prototipado

Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseo se llevan a cabo paso a paso. Alto riesgo debido a falta de visibilidad
Evolutivo
Alto riesgo debido a la necesidad de tecnologa avanzada y habilidades del grupo desarrollador.
Prototipado con Lenguajes Visuales

Hypertext display component
Date component
File
Edit
Views
Layout
Options
Help General Index
12th January 2000 Range checking script 3.876
Draw canvas component
User prompt component + script
Tree display component

fuente: I. Sommerville, Software Engineering, 6th ed.,2000
Desarrollo Incremental
Definicin general de requerimientos
pasos
identificacin y priorizacin de funciones y servicios definicin de varios requerimientos que proporcionan parte de la funcionalidad, segn la prioridad (los ms importantes se entregan antes) definicin detallada de requerimientos del incremento y desarrollo con el proceso ms adecuado congelacin de requerimientos de incrementos desarrollados puesta en explotacin de los incrementos completados y entregados
Asignacin de requerimientos a incrementos
Diseo de la arquitectura del sistema
Desarrollo de incrementos del sistema
Validar incrementos
ventajas
puesta en marcha temprana los incrementos iniciales permiten refinar requerimientos de incrementos posteriores satisfaccin del cliente (bajo riesgo de fallo) sistema final muy probado y con pocos fallos
Integrar incrementos
Validar sistema
problemas
sistema incompleto sistema completo
incrementos relativamente pequeos adaptacin de requerimientos a incrementos del tamao apropiado
Sistema final
identificacin de recursos comunes a todos los incrementos
Modelo en Espiral
propuesto por Barry Boehm organizacin en ciclos
primer ciclo: factibilidad segundo ciclo: requerimientos tercer ciclo: diseo ...
Anlisis de riesgos An. Riesgo. Prototipo 1 Prototipo 3 Prototipo 2 DETERMINAR OBJETIVOS, ALTERNATIVAS Y RESTRICCIONES PROGRESO A TRAVS DE LAS ITERACIONES EVALUAR ALTERNATIVAS, IDENTIFICAR Y RESOLVER RIESGOS Anlisis de riesgos
Anlisis de riesgos
cada ciclo se divide en 4 sectores

definicin de objetivos, restricciones del producto y proceso, plan de administracin,...
evaluacin y reduccin de riesgos (por ejemplo, mejor definicin de requerimientos mediante prototipos) desarrollo y validacin: eleccin de un modelo para el desarrollo planificacin: el proyecto se revisa y se decide si se contina con el siguiente ciclo. si es as, se planifica la siguiente fase
PLANIFICAR SIGUIENTE FASE REVISIN Plan de . requerimientos Plan de ciclo de vida
Prototipo operativo
Concepto de operacin Requerimientos de software Validacin de requerimientos
Simulaciones, modelos, pruebas comparativas
Plan de desarrollo
Plan de integracin y prueba
Diseo del producto
Diseo detallado
Codificar Diseo de validacin y verificacin Prueba de unidad Prueba de integracin
Explotacin
Prueba de aceptacin
DESARROLLAR, VERIFICAR PRODUCTO DE SIGUIENTE NIVEL
Fases del Modelo de Espiral

Planteamiento de Objetivos
Se identifican los objetivos especficos para cada fase del proyecto.
Identificacin y reduccin de riesgos.
Los riesgos clave se identifican y analizan, y la informacin sirve para minimizar los riesgos.
Desarrollo y Validacin.
Se elige un modelo apropiado para la siguiente fase del desarrollo.
Planeacin.
Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.
Plantilla para una ronda del Espiral

Objetivos. Restricciones. Alternativas. Riesgos. Resolucin de riesgos. Resultados. Planes. Garantas (commitments).
Ventajas del Modelo de Espiral

Centra su atencin en la reutilizacin de componentes y eliminacin de errores en informacin descubierta en fases iniciales. Los objetivos de calidad son el primer objetivo. Integra desarrollo con mantenimiento. Provee un marco de desarrollo de hardware/software.
Problemas con el Modelo de Espiral

El desarrollo contractual especifica el modelo del proceso y los resultados a entregar por adelantado. Requiere de experiencia en la identificacin de riesgos. Requiere refinamiento para uso generalizado.
Visibilidad de Procesos
Los sistemas de software son intangibles por lo que los administradores necesitan documentacin para identificar el progreso en el desarrollo. Esto puede causar problemas.. El tiempo planeado para entrega de resultados puede no coincidir con el tiempo necesario para completar una actividad. La necesidad de producir documentos restringe la iteracin entre procesos. .El tiempo para revisar y aprobar documentos es significativo. El modelo de cascada es an el modelo basado en resultados mas utilizado.
Visibilidad del Modelo

Modelo de Proceso Modelo de Cascada Visibilidad del Proceso Buena visibilidad, cada actividad produce un documento o resultado Visibilidad pobre, muy caro al producir docuementos en cada iteracin. Buena visibilidad, en cada fase deben producirse documentos. Visibilidad moderada. Importante contar con documentacin de componentes reutilizables. Buena visibilidad, cada segmento y cada anillo del espiral debe producir un documento.
Modelos Formales
Desarrollo orientado a la reutilizacin
Modelo de Espiral
El Proceso Unificado de Desarrollo

Proceso unificado de desarrollo Propuesto por los autores de UML (lenguaje unificado de desarrollo) Basado en componentes interconectados a travs de interfaces Utiliza UML para desarrollar los esquemas y diagramas de un sistema software Principales aspectos definitorios Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental
Requisitos del usuario
Proceso de desarrollo de Software
Sistema software
El Proceso Unificado: Dirigido por Casos de Uso

Para construir un sistema con xito hay que conocer las necesidades y deseos de los futuros usuarios Usuario Personas que trabajan y necesitan el sistema Otros sistemas que interactan con el que estamos desarrollando Interaccin: Usuario inserta tarjeta en cajero automtico Usuario responde sobre la pantalla a las preguntas que realiza el cajero El usuario recibe una cantidad de dinero y su tarjeta Una interaccin as es un caso de uso Fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante Utilidad Casos de Uso Herramienta para especificar los requisitos de un sistema: representan los requisitos funcionales y juntos constituyen el modelo de casos de uso, que describe la funcionalidad total del sistema Guan el proceso de desarrollo (diseo, implementacin y prueba) Basndose en el modelo de casos de uso, se crean modelos de diseo e implementacin Se revisa cada modelo para que sean conformes al modelo de casos de uso Se prueba la implementacin para garantizar que los componentes del modelo de implementacin implementan correctamente los casos de uso No slo inician el proceso de desarrollo sino que ste sigue un hilo de trabajo que parte de los casos de uso
Retirar dinero
Cliente del banco
Ingresar dinero
Transferencia entre cuentas
El Proceso Unificado: Centrado en la Arquitectura

casos de uso gua
arquitectura
La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construccin Influida por diversos factores Necesidades de la empresa, tal y como las conduce perciben los usuarios y clientes Otros factores, como plataforma de explotacin (arquitectura hardware, sistema operativo, gestor de bases de datos, protocolos de comunicacin,...), componentes reutilizables, sistemas heredados, requisitos no funcionales,... Es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado. Capa especfica de la aplicacin Hay una constante interaccin entre los casos de uso y la arquitectura, que evolucionan en paralelo Los casos de uso deben encajar en la arquitectura cuando se realizan Capa general de la La arquitectura debe permitir el desarrollo de aplicacin todos los casos de uso requeridos El arquitecto Realiza un esquema en borrador de la Capa arquitectura que no es especfica de los casos intermedia de uso (por ejemplo, la plataforma) Trabaja con un subconjunto de los casos de uso principales del sistema, especificndolo en Capa de software detalle y realizndolo en trminos de del sistema subsistemas, clases y componentes A medida que los casos de uso se especifican y maduran, se descubre ms de la arquitectura, lo que a su vez lleva a la maduracin de ms casos de uso Este proceso contina hasta que se considera que se dispone de una arquitectura estable
El Proceso Unificado: Iterativo e Incremental

El trabajo se divide en partes ms pequeas o miniproyectos Miniproyecto: una iteracin que resulta en un incremento Iteracin: pasos en el flujo de trabajo Incremento: crecimiento del producto Las iteraciones estn controladas y planificadas Factores para seleccionar lo que se implementar en una iteracin La iteracin se centra en un grupo de casos de uso que juntos amplan la utilidad del producto desarrollado hasta ahora La iteracin trata los riesgos ms importantes Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la ltima iteracin En las primeras fases del ciclo de vida los incrementos implican modificaciones En las ltimas fases los incrementos implican menos modificaciones y ms aadidos a los modelos Para cada iteracin: Identificacin y especificacin de los casos de uso relevantes Creacin de un diseo utilizando la arquitectura seleccionada como gua Implementacin del diseo mediante componentes Verificacin de que los componentes satisfacen los casos de uso Si una iteracin cumple con sus objetivos, el desarrollo contina con la siguiente iteracin. Si no, se revisan las decisiones previas y se adopta un nuevo enfoque Ventajas del proceso iterativo controlado Reduccin del coste del riesgo a los costes de un solo incremento Reduccin del riesgo de no sacar al mercado el producto en el calendario previsto Se acelera el ritmo del esfuerzo de desarrollo en su totalidad, para obtener resultados claros a corto plazo Los requerimientos del usuario se van refinando en iteraciones sucesivas, por lo que se pueden acomodar mejor los cambios
La Vida del Proceso Unificado

El proceso unificado se repite a lo largo de una serie de ciclos Cada ciclo concluye con una versin del producto y consta de cuatro fases Inicio: descripcin del producto final a partir de una idea inicial y anlisis de negocio para el producto Principales funciones del sistema y usuarios ms importantes (modelo de casos de uso) Posible arquitectura del sistema Plan del proyecto, coste, identificacin y priorizacin de riesgos Elaboracin: Se especifican en detalle los principales casos de uso Se disea la arquitectura del sistema: vistas arquitectnicas del modelo de casos de uso, del modelo de anlisis, del modelo de diseo, del modelo de implementacin y modelo de despliegue Al final se pueden planificar las actividades y estimar recursos necesarios para finalizar el proyecto Construccin: Se crea el producto aadiendo el software a la arquitectura Al final se dispone de todos los casos de uso acordados para el desarrollo aunque puede incorporar defectos Transicin Periodo durante el cual el producto se convierte en versin beta, en la que usuarios prueban el producto e informan de defectos y deficiencias Se corrigen problemas e incorporan sugerencias Incluye actividades como la formacin del usuario, proporcionar una lnea de ayuda y asistencia,... Cada fase se divide a su vez en iteraciones
La Vida del Proceso Unificado

Fases Flujos de trabajo fundamentales
Requisitos
una iteracin en la fase de elaboracin
Inicio
Elaboracin
Construccin
Transicin
Anlisis
Diseo
Implementacin
Prueba
iter #1
iter #2
---
---
---
---
---
iter #n-1
iter #n
Iteraciones
Bibliografa
Bruegge, B., Dutoit, A.H., Ingeniera del Software Orientado a Objetos, cap. 1 Jacobson, I., Booch, G., Rumbaugh, J., El Proceso Unificado de Desarrollo de Software, cap. 1
Pressman, R.S., Ingeniera del Software. Un enfoque prctico, cap. 1 y 2

Sommerville, I., Ingeniera de Software, cap. 1, 2 y 3

Ingeniería de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ingeniería de Software

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD TECNOLGICA NACIONAL

Regional La Plata Dto. Sistemas

1.- Introduccin a la Ingeniera del Software

Ingeniera del Software 2010

Introduccin Ingeniera del Software Desarrollo del hardware

Avance de las comunicaciones entre sistemas.

[1] Ley de Moore

Introduccin Ingeniera del Software Desarrollo del hardware

Crisis de software Proyectos para el desarrollo de sistemas de software

Introduccin Ingeniera del Software

Crisis del software

Introduccin Ingeniera del Software

Ingeniera del software

Introduccin Ingeniera del Software

Ingeniera del software

Introduccin Ingeniera del Software

Ingeniera del software

Caractersticas deseables de los Productos de Software

El software no debe causar danos fsicos o econmicos en el caso de fallos.

El software no debe desperdiciar los recursos del sistema.

El software debe contar con una interfaz de usuario adecuada y su documentacin.

Introduccin Ingeniera del Software

La Ingeniera del Software es una ingeniera muy joven que necesitaba

Definir criterios unificadores para las tareas de requisitos, pruebas, gestin de la

Introduccin Ingeniera del Software Principales organizaciones de estandarizacin

Principales organizaciones de estandarizacin

Introduccin Ingeniera del Software

ISO/IEC 12207 ISO/IEC TR 15504

Principales organizaciones de estandarizacin

Introduccin Ingeniera del Software

IEEE Computer Society

IEEE IEEE IEEE IEEE IEEE

Std. Std. Std. Std. Std.

Principales estndares y modelos

Introduccin Ingeniera del Software

La Ingeniera del Software es una ingeniera muy joven que necesitaba:

Definirse a s misma: Cules son las reas de conocimiento que la comprenden?

Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

Definir estndares menores para dibujar criterios unificadores en requisitos,

Introduccin Ingeniera del Software

Introduccin Ingeniera del Software

Requisitos Diseo Construccin Pruebas Mantenimiento

Gestin de la configuracin Gestin Procesos Herramientas y mtodos Calidad

ISO 12207: Propsito

Introduccin Ingeniera del Software

Ciclo de vida del software

Introduccin Ingeniera del Software ISO 12207: Propsito

Introduccin Ingeniera del Software ISO 12207: Procesos

6.- Procesos de soporte

5.3 Operacin 5.3 Desarrollo 5.3 Mantenimiento

Introduccin Ingeniera del Software

ISO 1227 define los procesos que componen el ciclo de

Introduccin Ingeniera del Software

Un proceso est compuesto por actividades.

La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de

Introduccin Ingeniera del Software

Coleccin de componentes organizados para cumplir una funcin o conjunto de funciones

IEEE Standard 610.12-1990

Elemento del sistema

Elemento del sistema

Elemento del sistema

Coleccin de elementos relacionados de forma que puedan realizar un objetivo tangible.

Introduccin Ingeniera del Software INGENIERA DE SISTEMAS