Professional Documents
Culture Documents
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
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,
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
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
Mantenible.
Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones.
Confiable
Eficiente
Fcil de Usar
Estndares y modelos
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
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.
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
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.
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
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
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
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.
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
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).
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
Tarea n
Proceso N Actividad n
Ciclo de vida
Concepto Retirada
Tarea 1
Tarea 2
Tarea n
ISO 12207
TAREA X
TAREA 1
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?
Sistema
Sistema de Salida
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.
INGENIERA DE SISTEMAS
Algunas definiciones
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 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.
INGENIERA DE SISTEMAS
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.
INGENIERA DE SISTEMAS
Ingeniera de Sistemas
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
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
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?
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
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
<<subsistema>>
Sistema de identificacin de objetos
Vendedor
Pagar factura
Comprador
<<extend>> iniciador
Rechazar factura
Realizar transaccin
<<subsistema>>
<<subsistema>>
Sistema de seleccin de embalajes
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
Actividades de Desarrollo
ReservaBilletes
Viajero
CompraBillete
Anulacin reserva
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
Actividades de Desarrollo
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
Actividades de Desarrollo
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
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)
Actividades de Desarrollo
<<subsystem>> Gestin Trabajos Externos <<subsystem>> Gestin Sistema <<subsystem>> Mantenimientos de Gestin
Actividades de Desarrollo
<<subsystem>> Gestin Trabajos Externos <<subsystem>> Gestin Sistema
Alta Instalaciones
<<subsystem>> Mantenimientos de Gestin
<<include>>
Operario
(from Validacin Usuarios)
Consulta Instalaciones
Operario
(from Validacin Usuarios)
Consulta Caractersticas-Maq
Actividades de Desarrollo
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
Excepciones
...
Mostrar(Datos)
Si no Existe
Cubrir_Datos() Comprobar()
Alta Caractersticas-Maq
<<include>>
Construir
Visualizar Resultado
Datos no Correctos
Construir
Operario
(from Validacin Usuarios)
Consulta Caractersticas-Maq
Actividades de Desarrollo
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
Datos Correctos
Si Exi ste
No Existe
Alta Caractersticas-Maq
<<include>> <<include>>
Mensaje "Error"
Operario
(from Validacin Usuarios)
Consulta Caractersticas-Maq
Actividades de Desarrollo
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
Iniciado-por
1 Encargado
Registra-ventas-en
Actividades de Desarrollo
Servidor
ODBC
SGBD
TCP/IP
TCP/IP Cliente
Red Local
Impresora
TCP/IP
Cliente
Actividades de Desarrollo
Actividades de Desarrollo
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 Desarrollo
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
Mejorado
Gestionado
Definido
Repetible
Completa rea Procesos
Inicial Incompleto
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.
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
Desarrollo Evolutivo
Actividades Concurrentes
Especificacin
Versin Inicial
Desarrollo
Versiones Intermedias
Validacin
Versin Final
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.
Date component
File
Edit
Views
Layout
Options
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
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
Sistema final
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
Prototipo operativo
Plan de desarrollo
Plan de integracin y prueba
Diseo detallado
Explotacin
Prueba de aceptacin
Los riesgos clave se identifican y analizan, y la informacin sirve para minimizar los riesgos.
Desarrollo y Validacin.
Planeacin.
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.
Desarrollo Evolutivo
Modelos Formales
Modelo de Espiral
Sistema software
Retirar dinero
Ingresar dinero
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
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