METODOLOGIA Y DESARROLLO DE SOFTWARE A.

FASES DEL CICLO DE VIDA Inicio (Incepcin) Idea Visin del Producto Elaboracin (Elaboration) Arquitectura ejecutable Construccin (Construction) Liberaciones del producto Transicin (Transition) Productos

1. Fase de incepcin Meta Consenso de los objetivos del proyecto Objetivos Principales Establecer el alcance, condiciones lmite Establecer casos de uso crticos y escenarios Demostrar arquitecturas candidatas Estimar el costo y calendario Evaluar el riesgo

Actividades Principales Formular el alcance (requerimientos y concepto operacional) Sintetizar una arquitectura (investigar los alcances del diseo y negociaciones) Planear y preparar el caso de negocios (administracin del riesgo, personal, costo/calendarizacin de avances)

Principal criterio de evaluacin: Los stakeholders coinciden en el alcance, costo y calendarizacin? Son entendibles los requerimientos? El plan es factible ? (estimados de costo y calendario? riesgos? prioridades? La arquitectura soporta esos criterios? Los gastos actuales vs planeados son aceptables?

2. Fase de elaboracin Meta

(precio fijo)

Decisin para el compromiso de la fase de construccin

Objetivos principales Bases de la arquitectura Bases de la visin Bases para un plan de construccin Demostrar que la arquitectura soportar la visin en un tiempo y costo razonable

Actividades principales Elaboracin de la visin Elaboracin del proceso e infraestructura Elaboracin de la arquitectura Seleccin de componentes (hacer/comprar)

Criterio principal de evaluacin La visin es estable? La arquitectura es estable? Se han identificado los riesgos principales? (muestra) El plan de construccin es factible? Los Stakeholders estn de acuerdo con la visn que se lograr con este plan y arquitectura? Los gastos actuales vs planeados son aceptables?

3. Fase de Construccin Meta entregable Expresar la propiedad intelectual como un producto

Objetivos principales y tareas posible Minimizar costos a travs de la optimizacin de recursos Lograr una calidad adecuada tan rpido como sea Lograr versiones tiles tan rpido como sea posible

Actividades principales procesos Administracin de recursos, control y automatizacin de

aceptacin

Desarrollo de componentes completos y pruebas Evaluacin de productos liberados contra criterios de

Criterios principales de evaluacin La base del producto es suficiente madura para ser desarrollada? (Funcionalidad). La base del producto es suficientemente estable? (Bugs) Los Stackeholders estn listos para la transicin de los usuarios! Los gastos actuales vs planeados son aceptables?

4. Fase de Transicin Meta Que la base del desarrollo alcance la visin completa Objetivos principales Lograr que el usuario alcance soporte propio Lograr que los stakeholders alcancen concurrencia para que en la base del desarrollo reuna los criterios de evaluacin de la visin Lograr que la base del producto final logre el tiempo y costo ptimos Actividades principales Sincronizacin e integracin del desarrollo dentro de las bases establecidas Desarrollo de ingeniera especfica Evaluacin de las bases del desarrollo contra la visin completa y los criterios de aceptacin Criterio principal de evaluacin El usuario est satisfecho? Los gastos actuales vs planeados son aceptables?

RESUMEN DEL PROCESO MODERNO Cada fase consiste de iteraciones que producen una capacidad tcnica demostrable y que se evala contra un conjunto de criterios La transicin de fase a fase mapea una decisin de negocios B. EVOLUCIN DE LA ECONOMA DE SOFTWARE

El desarrollo de software convencional Industria dominada por desarrollo personalizado Procesos ad-hoc Diseconoma de escala Modelos actuales de costo Basados principalmente en bases de datos empricas con muy pocas historias de xito sobre el desarrollo iterativo moderno. Es dficil lograr buenos estimados sobre el costo del software. 1. Economia de software La mayora de los modelos de costo pueden integrarse en una funcin de cinco parmetros: El tamao del producto final Size El proceso usado para producir el producto final Process Las capacidades del personal de ingeniera de software Personnel El ambiente formado por herramientas y tcnicas Environment La calidad requerida del producto: caractersticas, desempeo, confiabilidad y adaptabilidad Quality Relaciones entre los parmetros: Esfuerzo = (Personal) (Ambiente) (Calidad) (Tamao Proceso). El tamao afecta mayormente al costo del proyecto. La relacin entre esfuerzo y tamao produce una diseconoma de escala: A mayor software construdo, mayor costo por unidad POR QU? - Por la complejidad para administrar la comunicacin interpersonal entre los miembros del equipo. Tres generaciones de desarrollo de software: 1) Convencional (1960 y 1970) Herramientas personalizadas Procesos personalizados Componentes construidos en lenguajes primitivos Desempeo altamente predecible Costo, calendario y objetivos no alcanzados

2) Transicin (1980 y 1990) Ingeniera de Software - Ms procesos repetibles y COTS (30%) Productos comerciales: Sistemas Operativos, DBMS, Redes, GUIs - Componentes personalizados construdos en lenguaje de alto nivel (70%) Economa a escala (1980) No suficientes para el

desempeo del negocio Aplicaciones ms complejas, lenguajes existentes, tcnicas y tecnologas 3) Prcticas modernas (2000) Produccin de Software -Procesos administrados y cuantificables - Ambientes de automatizacin integrados Aproximadamente 70% de COTS Componentes desarrollados 30% Produccin rpida. Las tecnologas para automatizacin del ambiente, reduccin del tamao y mejoras en el proceso son dependientes. Avance en el proceso Incremento en la automatizacin de herramientas Nuevos componentes tecnolgicos

Retorno sobre la Inversin. El ROI se incrementa cuando el proyecto se repite en el ciclo de vida en varios dominios: ROI a travs de una lnea de negocio: Inversin en arquitectura comn, procesos y ambiente para todos los sistemas de la lnea de negocio ROI a travs de un proyecto con mltiples iteraciones: Inversin en arquitectura robusta, proceso iterativo maduro y automatizacin de procesos ROI a travs de las versiones del ciclo de vida de un producto: Inversin en arquitectura de producto, proceso de versiones durante el ciclo de vida y automatizacin de procesos El incremento en el ROI se basa en inversiones en arquitectura 2. ESTIMACION DE COSTOS Tpicos de los debates sobre modelos y herramientas de estimacin de costos: 1) Qu modelo de estimacin de costos utilizar? 2) Se mide el tamao del software en lneas de cdigo o en puntos de funcin? 3) Qu es lo que constituye en buen estimado? Modelos: COCOMO CHECKPOINT ESTIMACS KNOWLEDGE PLAN PRICE S PROQMS SEER SLIM SOFTCOST SPQR/20 Medidas del tamao del Software: 1) Lneas de Cdigo Fuente (SLOCS)

Deben definirse y contarse consistentemente Funcionan mejor en aplicaciones predominantemente personalizadas. 2) Puntos de Funcin Es la medida de Software de asociacin en la industria El mtodo es independiente de la tecnologa Permite la comparacin entre proyectos y organizaciones Desventajas: definiciones abstractas, mediciones que no son fcilmente derivables de artefactos evolutivos Consideraciones: Utilizar alguna medida Los puntos de funcin son tiles para comparaciones entre proyectos y entre organizaciones Los puntos de funcin sin tiles para la estimacin en las primeras etapas del proyecto En fases posteriores SLOC es ms til y preciso Las estimaciones de costo independientes son inexactas Deben realizarse por un equipo competente: El administrador de proyectos El administrador de la arquitectura, desarrollo y pruebas Iteracin a travs de varios estimados y anlisis de sensibilidad El equipo debe tomar la propiedad del estimado para el xito del proyecto Atributos de un buen estimado: Lo conciben el administrador del proyecto, el equipo de arquitectura, el equipo de desarrollo y el equipo de pruebas Es aceptado por los involucrados como ambicioso pero realizable Se basa en un modelo de costos bien definido y con bases aceptables Se basa en la experiencia de proyectos relevantes Se define con suficiente detalle para entender las reas de riesgo C. MEJORAS EN LA ECONOMA DE SOFTWARE

La tecnologa moderna de software permite la construccin de sistemas con menos lneas de cdigo generadas por persona. La mejora se ha logrado enfrentando balanceadamente los cinco parmetros bsicos. 1. Reduccin del tamao o complejidad del Software 2. Mejoras en el proceso de desarrollo 3. Personal ms hbil y mejores equipos 4. Uso de mejores ambientes 5. Negociaciones en los lmites de calidad Los parmetros son dependientes Las mejoras en la tecnologa de software se afectan por los avances en el desempeo del Hardware 1. Reduccin del tamao o complejidad del Software. Lenguajes de alto nivel. El desarrollo basado en componentes reduce el tamao del cdigo fuente necesario. Corresponde a la abstraccin y a las tecnologas de desarrollo basadas en componentes Tendencias: Lenguajes de alto nivel Orientacin a Objetos Reuso Componentes comerciales Reduccin del tamao o complejidad del Software, Lenguajes de alto nivel. Universal Function Points UPFs Entradas externas del usuario Salidas externas Grupos de datos lgicos internos Interfases externas de datos Solicitudes externas SlOC

Reduccin del tamao o complejidad del software Mtodos orientados a objetos Mejoran la productividad del software Tienen alto costo en entrenamiento, por ejemplo, UML Proveen notaciones mas formales para capturar y visualizar las abstracciones del software Reduccin del tamao o complejidad del software. Caractersticas de un proyecto orientado a objetos mnimas Enfoque al desarrollo que provee una coleccin de caractersticas escenciales Cultura centrada en resultados, enfatizando la comunicacin Uso efectivo de modelacin orientada a objetos Existencia de una visin fuerte a la arquitectura

Aplicacin de un ciclo de vida iterativo e incremental

Reduccin del tamao o complejidad del software Reuso. Reuso de componentes existentes y construccin de componentes reusables Enfatizan el retorno sobre la inversin cuando se utilizan en varios proyectos El principal obstculo es la fragmentacin de lenguajes, sistemas operativos, notaciones, arquitecturas computacionales, herramientas y estndares

Reduccin del tamao o complejidad del software Transicin de componentes reusables a productos comerciales. Se tiene una motivacin econmica para continuar el apoyo Se tiene propiedad en la mejora del producto, calidad, nuevas caractersticas y transicin a nuevas tecnologas Se tiene una base de datos amplia de clientes Reduccin del tamao o complejidad del software Componentes comerciales. Ventajas o o o o o o Costos por licencia predecibles Ampliamente utilizados, tecnologa madura Disponibles Organizacin dedicada al soporte Independencia hardware/Software Alta funcionalidad Debe maximizarse su integracin

Reduccin del tamao o complejidad del software

Desventajas o o o o o o Actualizaciones frecuentes Costos de licencias Cargos por mantenimiento Dependencia hacia el vendedor Sacrificios de eficiencia en ejecucin Restricciones de funcionalidad Integracin

 2.

Falta de control en actualizaciones y mantenimiento Caractersticas innecesarias Inadecuada confiabilidad y estabilidad Incompatibilidad entre vendedores Mejoras en el proceso de desarrollo

En una organizacin orientada al desarrollo de software existen muchos procesos y subprocesos Se relacionan con mtodos y tcnicas Tendencias Desarrollo iterastivo Modelos maduros de proceso Desarrollo primero-arquitectura Reformas en la adquisicin Mejoras en el proceso de desarrollo La calidad del proceso afecta el esfuerzo requerido y el calendario a) Se puede tener un proceso de N pasos y mejorar la eficiencia de cada paso b) Se puede tener un proceso de N pasos y eliminar algunos para tener un proceso de M pasos c) Se puede tener un proceso de N pasos y usar mayor concurrencia en las actividades o en los recursos

3. Personal ms hbil y mejores equipos Las diferencias en el personal influyen en la productividad El balance y la cobertura son dos de los ms importantes aspectos de los equipos excelentes La cobertura es hacia posiciones clave Un proyecto bien administrado puede tener xito con un equipo promedio Un proyecto mal administrado casi nunca tiene xito aun con un equipo experto Un sistema con buena arquitectura puede construirse con un equipo promedio Un sistema con arquitectura pobre puede descompensarse aun con un equipo experto. Personal ms hbil y mejores equipos Habilidades del administrador de proyectos

Contratacin Interfase con el usuario Toma de decisiones Formacin y crecimiento del equipo Ventas

4. Uso de mejores ambientes. Las herramientas y el ambiente tienen un efecto lineal en la productividad del proceso Herramientas de planeacin Herramientas para administracin de requerimientos Herramientas para aseguramiento de la calidad Herramientas de prueba Interfases de usuario. Apoyo en la automatizacin para evolucionar los artefactos de ingeniera de software. Uso de mejores ambientes Ingeniera Round Trip Capacidad clave del ambiente que apoya un desarrollo iterativo Automatizacin para asegurar loa transmisin eficiente y libre de errores de un artefacto a otro Forward engineering Backward engineering

La Ingeniera Round Tripdescribe el apoyo del ambiente necesario para cambiar un artefacto libremente y con esto cambiar automticamente otros artefactos La consistencia se mantiene en el conjunto entero de artefactos de requerimientos, diseo, implementacin y desplegado 5. Negociaciones en los lmites de calidad. Prcticas para incrementar la calidad del software. Enfoque a requerimientos y casos crticos de uso anticipadamente en el ciclo de vida Enfoque a completar requerimientos y seguimiento en etapas posteriores del ciclo de vida Enfoque hacia el balance entre la evolucin de requerimientos, diseo y plan durante el ciclo de vida Uso de mtricas e indicadores para medir el avance y la calidad de una arquitectura mientras evoluciona de un prototipo de alto nivel a un producto Negociaciones en los lmites de calidad

 Prcticas para incrementar la calidad del software Proveer ambientes integrados del ciclo de vida que apoyen anticipadamente y en forma contnua el control de la configuracin, administracin de cambios, mtodos rigurosos de diseo, automatizacin de la documentacin y la regresin formal de las pruebas Uso de modelacin lineal y lenguajes de alto nivel La penetracin anticipada y continua en el desempeo a travs de evaluaciones basadas en demostraciones Peer Inspection Inspecciones detalladas que frecuentemente son sobre- enfatizadas como aspecto clave en la calidad del sistema Son valiosas como segundo mecanismo Casos en que apoyan favorablemente: o La revisin de productos de un equipo junior por un equipo senior o Cuando se quiere hacer responsables a los autores sobre la calidad del software La exposicin de los detalles de arquitectura se logra mediante actividades rigurosas de ingeniera, como: Anlisis, prototipeo o experimentacin Construccin de modelos de diseo Compromiso del modelo de diseo a una implementacin ejecutable Demostracin de las fuerzas y debilidades de la implementacin en el contexto de subconjuntos crticos de casos de uso y escenarios Incorporacin de lecciones aprendidas en modelos, casos de uso, implementacin y planes. La evaluacin de la calidad de la ingeniera evolutiva debe realizarse por un equipo de ingeniera independiente de la arquitectura y del equipo de desarrollo D. METODOLOGIAS MODERNAS DESARROLLO DE SOFTWARE PARA LA ADMINISTRACIN DEL

La industria de Software tiende hacia nuevos mtodos para administrar la complejidad creciente de los proyectos de software. 1. Administracin de Proyectos de Desarrollo de software

 En la administracin de proyectos es muy importante el balance, especialmente entre los objetivos de sus stakeholders que se comunican en una variedad de lenguajes y notaciones Los tres lenguajes de representacin fundamentales en la ingeniera de software son: Requerimientos: El lenguaje del espacio del problema. Diseo: El lenguaje de transformacin. Realizaciones: El lenguaje de la solucin ejecutada. En la administracin de proyectos no hay recetas clave Interviene: El juicio El sentido comn La toma de decisiones dependiente de la situacin reas grises, dependencias situacionales y

Hay muchas negociaciones ambiguas.

La razn del xito es muy baja segn lo demuestran los estudios. Causas: El desarrollo de software es altamente impredecible La disciplina administrativa es ms un discriminador en el xito o fracaso que un avance tecnolgico El nivel de desperdicio y re-trabajo es un indicador de un proceso inmaduro 2. El Modelo de Cascada (Waterfall Model) para el desarrollo de software Ha sido el proceso bsico con el que se ha generado experiencia. Ha sido la fuente de los procesos de software convencionales. Ha permitido desarrollar buenas prcticas cuando se utiliza con tecnologas modernas. a. Existen dos pasos en comn en el desarrollo de software: Anlisis y codificacin b. Incluye otros pasos para administrar la libertad intelectual: del sistema. de software. Definicin de requerimientos Definicin de requerimientos Diseo del programa

Pruebas

c. Su estructura es riesgosa: La fase de prueba se realiza al finalizar el desarrollo Sntomas de proyectos con problemas bajo esta metodologa:
1)

Integracin Resolucin tarda del Descomposicin Relaciones Enfoque Integracin prolongada y descomposicin tarda del diseo El diseo del sistema se realiza enteramente en papel El sistema se implementa todo al mismo tiempo El sistema se integra despus de implantado Actividades de prueba. Consumo de 40% o ms de los recursos del ciclo de vida. a

prolongada y descomposicin tarda del diseo

2)

riesgo
3)

funcional orientada a requerimientos

4)

adversarias de los involucrados (stakeholders)

5)

documentos y juntas de revisin

Resolucin tarda del riesgo Riesgo: Probabilidad de incumplimiento en costo, caractersticas o calidad. Especificacin de requerimientos Riesgo real altamente impredecible Diseo Riesgo estabilizado Codificacin Resolucin de algunos componentes individuales del riesgo Integracin Riesgo tangible Rediseo con sacrificio en el producto final, especialmente en su mantenimiento Descomposicin funcional orientada a requerimientos

Enfoque para detectar la definicin precisa de los requerimientos e implementarlos Definicin de Shalls, requerimientos discretos La estructura de software est organizada alrededor de la estructura de especificacin de requerimientos

 Relaciones adversarias de los involucrados (stakeholders). Esto es debido a ... Las dificultades en a especificacin de requerimientos El intercambio de informacin aislada a travs de documentos en papel, que capturan la informacin de la ingeniera en formatos especiales (ad-hoc).

Enfoque

documentos

juntas

de

revisin Produccin de documentos para describir el producto Enfoque insuficiente para producir un incremento tangible del producto Desvo de las tareas que reducirn el riesgo y producirn software de calidad 3. Metodologas Ayer y Hoy La ingeniera convencional de software tiene numerosos principios bien establecidos, algunos an vlidos y otros obsoletos que aplican con modificaciones La ingeniera moderna de software incorpora muchos principios convencionales pero tambin nuevos enfoques 4. Los Principios de la Administracin Moderna de desarrollo de software arquitectura produccin y pruebas Basar el proceso en un enfoque primero Es el elemento central del diseo Primero diseo e integracin, despus Requiere un balance entre:

o Requerimientos o Decisiones de diseo o Planes del ciclo de Compromiso hacia el desarrollo completo Establecer un proceso iterativo de ciclo de vida

vida

Confronta el riesgo anticipadamente, es el elemento de administracin de riesgo

Control de riesgo a travs de incrementar la funcin, el desempeo y la calidad Los riesgos principales se afrontan anticipadamente para incrementar la predictibilidad y evitar el re-trabajo y desperdicio Mtodos de transicin del diseo que enfatizan el desarrollo basado en componentes Es el elemento de tecnologa Mtodos orientados a objeto, notaciones rigurosas y modelacin visual El uso de componentes: Reduce la cantidad de cdigo generado y el desarrollo personalizado Componente: Conjunto cohesivo de lneas provenientes de cdigo fuente o ejecutable con un comportamiento e interfase definido Establecer un ambiente para administracin de cambios Es el elemento de control Mtricas, Tendencias, Instrumentacin de procesos Bases objetivas de control que se requieren cuando existen diferentes equipos trabajando con artefactos compartidos Fomentar la libertad de cambios mediante herramientas que soporten la round trip engineering Es el elemento de automatizacin Herramientas complementarias, ambientes integrados Round trip engineering es el ambiente necesario para automatizar y sincronizar la informacin en diferentes formatos: Especificacin de Requerimientos, Mdulos de diseo, Cdigo fuente, Cdigo ejecutable, Casos de prueba Capturar los artefactos de diseo en una notacin rigurosa basada en mdulos UML Proveen medidas objetivas mejores que el enfoque tradicional de representacin en papel Instrumentar el proceso para un control de calidad objetivo y evaluacin del avance

La evaluacin del avance y la calidad de los productos intermedios deben integrarse al proceso Los mejores mecanismos de evaluacin son medidas bien definidas derivadas de los artefactos e integradas en las actividades y equipos de trabajo. Usar un enfoque basado en demostraciones para evaluar los artefactos intermedios Hacer la transicin de los artefactos bsicos hacia una demostracin ejecutable de escenarios relevantes que permitan la eliminacin anticipada de defectos en la arquitectura Planear entregables (releases) intermedios en grupos de escenarios de uso con niveles evolutivos de detalle Demostraciones anticipadas y continuas dentro del contexto operacional del sistema. Casos de uso La evolucin de los incrementos del proyecto y sus generaciones deben ser acordes al entendimiento de los requerimientos y arquitectura Establecer econmicamente escalable un proceso configurable que sea

El proceso debe asegurar que hay una economa de escala y un retorno sobre la inversin explotando: - El espritu de proceso comn - La automatizacin extensiva de procesos - La arquitectura comn y uso de componentes