1 Bases Conceptuales Sistema Inf. IIEtapas en el proceso de desarrollo Metodologías para el proceso de desarrollo Herramientas para el análisis , diseño, desarrollo

2 Motivación Construcción de una casa para “fido”Extraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples

3 Motivación Construcción de un ChaletExtraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construido eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

4 Motivación Construcción de un RascacielosExtraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

5 CICLO DE VIDA Marco de referencia común para equipos de trabajoIncorpora procesos ,actividades y tareas a desarrollar. Existencia de diferentes paradigmas en el tiempo Ciclo de vida en cascada, espiral , evolutivos, y los mas recientes orientados a objetos.

6 Ciclo de Vida para el desarrollo de Software según la IEEE e ISO/IEC“Una aproximación lógica a la adquisición , el suministro, el desarrollo, la explotación y el mantenimiento del software” ( Norma IEEE 1074) “Un marco de referencia que contiene los procesos , las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abacando la vida del sistema desde la definición de requerimientos hasta la finalización de su uso” ( Norma ISO 12207)

7

8 ISO 12207 Propósito Establecer un marco común para el ciclo de vida del software para adquirir, suministrar, desarrollar, operar y mantener software gestionar, controlar y mejorar el marco como base para el comercio internacional de software Una arquitectura de alto nivel para el ciclo de vida Modularidad Cohesión: un proceso por función principal Acoplamiento: interfaces mínimas Responsabilidad Un proceso bajo la responsabilidad de una parte (de un acuerdo – relación cliente-proveedor -)

9 ISO 12207 – árbol de procesos Principales funciones y partesACQUISITION Principales funciones y partes SUPPLY DEVELOPMENT OPERATION MAINTENANCE PRIMARY LIFE CYCLE SUPPORTING DOCUMENTATION Soportan otras funciones, con un propósito CONFIGURATION MANAGEMENT QUALITY ASSURANCE VERIFICATION VALIDATION JOINT REVIEW AUDIT Gestión de la organización y mejora PROBLEM RESOLUTION ORGANIZATIONAL MANAGEMENT INFRASTRUCTURE Para formalizar el ajuste del estándar IMPROVEMENT TRAINING TAILORING

10 Estructura de un procesoPROCESS ACTIVITY 1 • • • ACTIVITY n TASK 1 • • • TASK X TASK 1 Proceso compuesto por actividades Una actividad compuesta por tareas TASK INPUTS OUTPUTS Naturaleza de una tarea: Una acción con entradas y salidas Indica qué hacer, no cómo

11 Características del estándarImplementa principios de TQM Cada parte/participante tiene responsabilidad apropiada Ciclo PDCA (Plan-Do-Check-Act) incorporado en los procesos Plan: Tareas, WBS, calendario, responsabilidad, etc. Do: Ejecución de los planes Check: Evaluaciones internas al proceso Suplementado con evaluaciones inter-procesos y de mejora Act: Vuelta atrás para solución de problemas Establece un nexo con Ingeniería de Sistemas Software tratado como parte de un sistema Ingeniería de Sistemas fundamento de Ingeniería de Software Se proporciona el contexto necesario del sistema Actividades de software ubicadas en ese contexto Software extraído e integrado al sistema Ingeniería de Software participa en Ingeniería del Sistema

12 Conceptos básicos Organización y Parte Tipos de acuerdos ProyectoOrganización: un grupo independiente de personas Parte: Quien participa en un acuerdo Partes pueden ser de la misma o de diferentes organizaciones Tipos de acuerdos Desde un acuerdo informal a un contrato legal Proyecto Un proyecto puede existir en la fase de pre-acuerdo, post-acuerdo, o una combinación de ambos Un proyecto puede abarcar una parte o todo el ciclo de vida

13 Conceptos básicos (cont.)Se adapta a cambios en la tecnología Independiente de métodos de gestión/ingeniería Lenguajes de programación Ambientes de ingeniería de software Modelos de ciclo de vida Cascada, incremental, evolutivo, reingeniería, utilizable con prototipación No es un estándar para productos Requiere que las salidas específicas sean documentadas No prescribe formatos, contenidos explícitos ni medios Compatible con estándar de productos de la organización No es un estándar de métricas Muchas tareas requieren métricas e indicadores El estándar no prescribe ninguno Contiene referencias a ISO 9126 como guía

14 Evaluación es una función elementalPURPOSE FORUM/MOTIVE Check, Review, Audit, Verify, Validate, Assure, Inspect, Monitor, Control, Improve, ... Diverse, Different, Formal, Informal, Peer, Independent, Defensive, Critique ENTITY Process, Activity, Task, Inputs, Outputs, Data, Product, Plan, Contract, Report, ... RESULTS; REPORTS EVALUATION CRITERIA At various levels: Requirements, Derived reqmts., Ad hoc conditions, 1 E V A L U T S 2 INTERNAL INTERNAL BETWEEN PROCESS 1 PROCESS 2 PROCESSES EVALUATION EVALUATION 1 & 2 E V A L U T J O I N Y

15 Procesos Primarios Operación Adquisición Mantenimiento SuministroSuministro Mantenimiento T E/T U Desarrollo O: THE SAME POINTS; E: EXECUTE; T: TASK; U: USE PLAN, DO, CHECK & ACT

16 Proceso de AdquisiciónPara quien adquiere productos y servicios de software Cubre períodos previos al contrato y de contrato Actividades Uso interno Procesos invocados Salidas P Reqs. Sistema Plan Adquisición Criterios Aceptación R Inicio Desarrollo E - C Reqs. Adquisición incl. –ajustes a12207 - referencias a contrato O Preparar Llamado N T R A Preparar y ajustar contrato Control Interno Contrato con: proveedor otros Ajuste T O C Revisión Conjunta O Controlar al Proveedor Audit. Verif. Valid. Control y evaluación de resultados N T R A Aceptación y Cierre Productos y servicios aceptados T O

17 Proceso de Adquisición actividades y tareas1. Inicio 4. Controlar al Proveedor • Describir necesidades • Controlar de acuerdo con Revisión Conjunta y Auditoriía • Definir Reqs. Sistema • Definir Reqs. Sw. (Posiblemente) • Suplementar con V&V • Preparar plan de adquisición • Definir estrategia de aceptación 2. Llamado (RFP) 5. Aceptación y cierre • Documentar Reqs. Adquisic. • Determinar procesos • Preparar para aceptación, incl. pruebas • Definir referencias al contrato • Establecer hitos de revisión • Cumplir revisiones/pruebas de aceptación 3. Preparación y actualización del contrato • Aceptar entregables • Asumer Gestión de Configuración • Establecer procedimientos de selección de proveedor • Seleccionar proveedor • Ajustar e involucrar a las partes • Negociar contrato [ durante el contrato]

18 Proceso de Suministro Para el proveedor de productos/serviciosCubre períodos previos al contrato y de contrato QUALITY SUPPLY CO. A COMPANY Actividades Uso interno Procesos invocados Salidas P R E Decisión de ofrecer Inicio - C O N Preparar Respuesta Propuesta Contratar Contrato Plan(es) gestión del proyecto C Planificación O Elegir uno o más N Ejecución y Control Control de Resultados T MONITOR, DEV. OPN. MNT. ACQ. R CONTROL A Revisión y Evaluación T Resultados de evaluaciones JT. REV. AUDIT V&V QA O Entrega y Cierre Productos/ servs. entregados

19 Proceso de Suministro actividades y tareas1. Inicio 4. Planificación 6. Revisión y Evaluación • Revisar reqs. Adquisición • Si necesario, elegir modelo de ciclo de vida • Establecer reqs. para planes • Desarrollar y documentar PGP planes de gestión de proyecto [15 ITEMS] • Revisar RFP • Decidir ofertar o aceptar contrato • Coordinar con adquirente • Revisión conjunta • Auditoría • V&V • Acceso al adquirente • QA por proceso QA 2. Preparar respuesta 5. Ejecución y Control • Preparar propuesta 3. Contratar 7. Entrega y Cierre • Cumplir PGPs • Desarrollar, Operar o mantener • Controlar progreso/Calidad • Gestioanr Subcontratos • Conexión con IVVT • Conexión con otras partes • Negociar contrato con adquirente • Solicitar modificaciones • Entregar el producto o servicio • Proporcionar Asistencia

20 Proceso de Desarrollo Para quien desarrolla (o modifica) productos de software - Puede llevar a cabo algunas actividades de Ingeniería del Sistema - Actividades no necesariamente en orden Actividades Uso interno Procesos invocados Salidas Implementación del Proceso Modelos y planes desarrollo Documentación C.M. Resolución Problemas Análisis Reqs. Sistema Evaluaciones Reqs. Sistema Diseño Arq. Sistema Arq. Sistema Evaluaciones - HW, SW, MO Análisis reqs. SW Evaluaciones ISO/IEC 9126 JT. REVIEWS Reqs. SW Diseño Arq. SW Evaluaciones JT. REVIEWS Arq. SW Diseño Det. SW Evaluaciones JT. REVIEWS Diseño Det. SW Código SW Base de Datos Codif./Test SW Evaluaciones Integración SW Evaluaciones JT. REVIEWS SW Integrado (SCI) Test Cualific. SW Evaluaciones AUDITS Diseño y Código Integración Sistema Evaluaciones SW Integrado (SIS) Test Cualif. Sistema Evaluaciones Diseño y Código AUDITS Plan Instalación Instalación SW Evaluaciones SW instalado Aceptación SW y Soporte SW pronto para entrega

21 Proceso de Desarrollo actividades y tareas1. Implementación del Proceso 3. Diseñar Arquitectura del Sistema • Definir/elegir Modelo(s) de ciclo de vida - base para el proyecto Basado en iteraciones/recursiones de las actividades y tareas desde Análisis. Reqs. Sistema hasta Aceptación de SW y Soporte • Producir una arquitectura del sistema • Identificar HW, SW e items de operación manual • Emplea de forma regular los procesos DOC, CM, y RES. PROB • Elegir/Ajustar Métodos/herramientas/… Internos 5. Diseñar Arquitectura del SW • Desarrollar, Documentar, Ejecutar planes • Producir una Arquitectura del SW • Puede usar No-entregables evitar dependencia de operación y mantenimiento futuros • Identificar componentes del SW 2,3,10,11 Actividades del Sistema 8. Integración SW 10. Integración Sistema • Realizar o soportar 4-9, 12,13 Actividades SW • Agregados integrados • Caminos de división e integración pueden ser distintos • Realizar

22 Proceso de Desarrollo Organización del SistemaHI X SI X MO HW SW SC SC SU SU SU SU Significados: HI- HARDWARE ITEM; SI- SOFTWARE ITEM; MO- MANUAL OPERATIONS; SC- SOFTWARE COMPONENT; SU- SOFTWARE UNIT; X- OTHER • pide Arquitectura y diseño, pero no implica estilo ni método de representación, ni de derivación • Caminos de Organización e integración pueden ser diferentes

23 Desarrollo de Software SU FUNCIONAMIENTOENTRADA < PROCESO SUMINISTRO PLAN(ES) GESTION PROYECTO > < IMPLEMENTACIÓN PROCESO MODELO(S) DE CICLO DE VIDA; METODOS, HERRAMIENTAS, ...; PLAN(ES) DE DESARROLLO DESARROLLO > < ANALISIS REQS. SISTEMA REQS. Y ESPECIFICACIÓN DEL SISTEMA > < ARQUITECTURA SISTEMA [HW, SW, MO] DISEÑO ARQ. SISTEMA > < ANALISIS REQS.SW > ... REQS. Y ESPECIFICACIONES DEL SW [LINEAS BASE] < TEST CUALIF. SW > ... DISEÑO Y CODIGO SW [LINEAS BASE] MANUALES USUARIO, ... O < TEST CUALIF. SISTEMA > ... < ACEPT. Y SIPORTE SW PRODUCTOS Y SERVICIOS PRONTOS PARA ENTREGAR SALIDA > • PROYECTO ESTABLECE LINEAS BASE - DE QUE Y CUANDO • PERMITIDAS ITERACIONES/RECURSIONES: PARA CONSTRUIR MODELOS ESPECÍFICOS GEBERAR MODELOS PREDEFINIDOS I T E R A C I O N • LINEAS BASE EN REVISIONES/AUDITORIAS PREDETERMINADAS - FORO PARA INVOLUCRAR PARTES CLAVE • NO SE PRECISAN TODAS LAS ACTIVIDADES (TAREAS) EN UN PROCESO (ACTIVIDAD) EN CADA ITERACIÓN O RECURSIÓN, PERO DEBIERAN COMPLETARSE EN LA ÚLTIMA ITERACIÓN O RECURSIÓN • LINEAS BASE INHIBEN CAMBIOS NO PLANEADOS O FACILES < • ENTREGABLES INCLUYEN AL MENSOS 3 PRODUCTOS EN LINEA BASE: - REQUERIMIENTOS, DISEÑO, CODIGO RECURSION >

24 Proceso de operación Para quien opera un sistema que contiene softwareQUALITY LINES Actividades Uso interno Procesos invocados Salidas - OPERATION PLAN Implementación del proceso Resolución de Problemas Mantenimiento - OPERATION PROCEDURES Testing y Aseguramiento interno SW operacional liberado Prueba Operacional [funciones realizadas] Operación Sistema Soporte a Usuarios - Solicitudes de usuario Resolución de problemas

25 Proceso de Operación Actividades y tareas1. Implementación del Proceso 2. Testing Operacional • Realizar testing operacional para cada liberación • Liberar luego que los criterios se cumplen • Asegurar que código/Base de datos Funcionan de acuerdo a lo planeado • Desarrollar un plan operacional • Establecer estándares operacionanles Documentar y ejecutar plan • Establecer procedimientos para resolución de problemas • Establecer procedimientos para Testing operacional Conectarse con proceso de mantenimiento • Establecer procedimientos para liberar Productos para uso operacional 3. Operación del Sistema • Opera en ambiente 4. Soporte a usuarios • Asistir a usuarios • Encaminar solicitudes de usuarios de mantenimiento de forma apropiada • Para arreglos temporales, dar opción a utilizarlos

26 Proceso de MantenimientoPara quien mantiene productos de software HD QUALITY FIXING Actividades Uso interno Procesos invocados Salidas Resolución Problemas Implementación del proceso CM Planes/Procs. Mantenimiento Análisis Prob./Modif. - PROB./MOD. ANAL/SOLN. Implement. modificación Desarrollo SW modificado Revisiones Internas Resultados Revisión Aceptación revisión mantenimiento Revisiones Internas Migración Planes/Reportes migr. Sistema migrado Plan retrio Archivos Retiro del SW

27 Proceso de Mantenimiento Actividades y tareasImplementación del Proceso 3. Implementación Modificación 5. Migración • Develop, document and execute plan • Establish procedures for problem reports and modifications requests • Manage modifications • Determinar elementos a modificar • Usar proceso desarrollo para las modificaciones • Suplementar con testing para asegurar que las partes Modificadas y no modificadas están bien resueltas • Desarrollar/documentar/ ejecutar plan • Notificar usuarios, etc. • Realizar operaciones en paralelo • Realizar operaciones a posteriori por impacta 2. Análisis del Problema/Modificación 6. Retiro del SW 4. Aceptación de revi- sión Mantenimiento • Desarrollar/documentar/ ejecutar plan • Notificar usuarios, etc. • Realizar operaciones en paralelo • Proveer acceso a datos/ productos retirados • Analyze modifications for impacts • Replicate/vefify problems • Implement modifications • Document and get approval • Revisar con organización que autoriza

28 Procesos de Soporte Para soportar otro procesos en llevar a cabo una función específica QUALITY ASSURANCE ADQUISICION VERIFICACION SUMINISTRO DOCUMENTACION VALIDACION DESARROLLO JOINT REVIEW CONFIGURATION OPERACION MANAGEMENT AUDIT. MANTENIMIENTO RESOLUCION PROBLEMAS EMPLEA/ iNVOCA

29 Proceso de DocumentaciónPara establecer estándares de documentación - MEDIOS, FORMATO, ESTRUCTURA, CONTENIDO, ARCHVO, DISTRIBUCION, EJEMPLOS: MANUALES DE USUARIO DE SU ORG.; IEEE SRS, ... Actividades Uso interno Procesos invocados Salidas Plan de Documentación Implementación del proceso Documentos “preparados" Diseño y Desarrollo Documentos producidos Producción Documentos Modificados Mantenimiento CONFIGURATION MANAGEMENT

30 Proceso de Gestión de la Configuración• Para GC de Productos y tareas • INTERNA O EXTERNA • IDENTIFICAR PRODUCTOS CONTROLADOS ACTIVITIES OUTPUTS Actividades Uso interno Procesos invocados Salidas Implementación del proceso CONFIGURATION MANAGEMENT PLAN Identificación de Configuración Esquem,a de Identificación - def. Líneas base Control Configuración Control de acceso y Auditoría internos Resultados de CC Reportes de estado CC Determinar estado de Configuración Evaluación Interna Evaluación de la Configuración Reportes de Evaluación Gestión y entrega de la liberación(RELEASE) Productos Entregables

31 Proceso de Aseguramiento de la Calidad• Para asegurar la conformidad de productos/servicios con requerimientos y de acuerdo con planes • Externa, con independencia organizacional • Usa el término “Asegura” en lugar de “Evalúa” Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS Plan de Aseguramiento de la calidad Resolución de Problemas Implementación del proceso V&V, JT. REVIEW, AUDIT. comoTécnicas Productos Asegurados Aseguramiento del Producto Aseguramiento del Proceso Procesos Asegurados Aseguramiento del Sistema de Calidad De acuerdo a lo especificado en el contrato ISO 9001

32 Proceso de Aseguramiento de la Calidad Actividades y tareas1. Implementación del Proceso 3. Aseguramiento del Proceso • Establecer proceso de QA para el proyecto Asegurar que:: • Procesos empleados son conformes • Desarrollar/Documentar/ Ejecutar Plan de QA • Prácticas de ingeniería interna conformes • Coordinar con procesos de Verificación, Validación,Revisión Conjunta y Auditoría • Requerimientos primarios son Pasados a lo subcontratistas • Se proporciona soporte a las otras partes 2. Aseguramiento del Producto • Se dispone de personal entrenado y de entrenamiento Asegurar que: • Planes están/son Documentados// Conformes/Ejecutados 4. Aseguramiento del Sistema de Calidad • Productos/Documentación Conformes • Productos se pueden entregar y ser Aceptados por adquirente • Gestión de calidad adicional por ISO 9001

33 Proceso de Verificación• Para la verificación de los requerimientos de un producto en una actividad contra las actividades previas • Interna o Independiente • Usa el término “Verificar” en lugar de “evaluar” Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS Resolución de Problemas Implementación del proceso Plan de Verificación Verificación Contrato - Proceso - Requerimientos - Diseño - Código - Integraci{on - Documentación Productos y Servicios Verificados Cada uno con sus propios criterios

34 Proceso de VerificaciónActividades y tareas 2. Verificación del Contrato • El proveedor tiene la capacidad requerida • Las necesidades de usuario están cubiertas • Manejo adecuado de cambios en los reqs. • Estipula conexiones entre las partes 3. Verificación del Proceso • Planificación adecuada y oportuna • Procesos adecuados/implementados y se ejecutan de acuerdo a lo previsto • Estándares/Procedimientos/Ambientes adecuados • Personal asignado y entrenado 4. Verificación de Requerimientos • Consistentes/Factibles/Verificables • Asignados de forma apropiada • Reqs. Críticos Correctos por métodos rigurosos • Determinar si y cuánto se precisa - Usar factores de criticidad • Determinar el grado de independencia 1. Implementación del Proceso 5. Verificación del Diseño • Correcto/Consistente/Trazable • Adecuada Secuencia/Asignación de Eventos, E/S, Interfaces, Lógica, Tiempos, Tamaños, Recuperación, ... • Diseño implementa Reqs. Críticos de forma Correcta [mostrado por métodos rigurosos] 6. Verificación del Código • Correcto/Verificable/Trazable • Similar a Diseño 7. Verificación de Integración • Componentes/Unidades Integradas Completamente/Correctamente • Items integrados en el sistema completamente Y correctamente • Llevado a cabo de acuerdo a planes 8. Verificación de Documentación • Adecuada/Completa/Consistente • Oportuna • Sigue CM

35 Proceso de Validación • Para la validación de productos como están construidos respecto a criterios especificados • Interna o Independiente • Usa el término “Validar” en lugar de “Evaluar” • Confianza en la validación: a partir de pruebas ACTIVITIES OUTPUTS Salidas Actividades Uso interno Procesos invocados Implementación del Proceso Resolución de Problemas Plan de Validación Validación Productos y Servicios Validados 4/5 Tareas: Testing 1 Tarea: Uso previsto

36 Proceso de Revisión ConjuntaPara revisiones conjuntas entre revisor y revisado - Típicamente por proveedor con adquirente - Tanto técnicas como de gestión Revisión del estado del proyecto, productos, tareas respecto a que estén completos y conformes Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS Agenda, Alcance, Foro, etc., Implementación del Proceso Resolución de Problemas Revisiones de Gestión de Proy, Estado del Proyecto Y decisiones Resultados Revisión Revisiones Técnicas

37 Proceso de Auditoría Para auditoríoas entre auditor y auditado- Típicamente por adquirente con proveedor Para evaluar cumplimiento de requerimientos/¨Planes/Contrato ACTIVITIES OUTPUTS Salidas Actividades Uso interno Procesos invocados Implementación del Proceso Agenda, Alcance, Foro, etc., Resolución de Problemas Resultados Auditoría Auditoría

38 Proceso de Resolución de ProblemasPara analizar y resolver problemas, tomando acciones correctivas y detectando tendencias Un proceso cíclico: - Problemas reportados/ingresados - Acción tomada - Causas identificadas/eliminadas - Resolución/Disposición lograda/registrada - Tendencia detectada Nota: No todo problema precisa una acción correctiva Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS Implementación del Proceso Problemas Resueltos Resolución de Problemas

39 Procesos Organizacionales• Para que una organización gestione y mejore su proceso a nivel corporativo PROCESO DE GESTION 1 PROCESO DE INFRAESTRUCTURA PROCESO PRIMARIO 2 3 PROCESO DE SOPORTE PROCESO DE MEJORA 4 PROCESO DE ENTRENAMIENTO 1: Gestionar siguiendo el proceso de gestión 2: Establecer infraestructura de acuerdo al proceso de infraestructura 3: Mejorar siguiendo el proceso de mejora 4: Entrenar al personal de acuerdo al proceso de entrenamiento Nota: El proceso de gestión se instancia en procesos primarios y de soporte porque se gestionan de forma diferente

40 Proceso de Gestión Para la gestión general del proceso a lo largo del ciclo de vida - Se instancia en otros procesos Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS [Requerimiento del Proceso] Inicio y definición de alcance Planificación Plan de Gestión Ejecución y control [Reportes] Revisión y Evaluación [Reportes] [Productos] Cierre [Servicios]

41 Proceso de InfraestructuraPara establecer y mantener la infraestructura a lo largo del ciclo de viuda Infraestructura: procedimientos, estándares, herramientas, equipos, espacio Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS Implementación del Proceso Infraestructura Establecer la infraestructura Configuración de la Infraestructura Mantener la infraestructura [Registros]

42 Proceso de Mejora Para establecer, evaluar, medir, controlar y mejorar un proceso a lo largo del ciclo de vida ACTIVITIES OUTPUTS Salidas Actividades Uso interno Procesos invocados Establecer el proceso [Proceso(s) establecido(s)] Procedimientos y Planes de Evaluación Evaluar el proceso [Evaluación, Historia, Registros de Costo de la Calidad] Mejorar el proceso

43 Proceso de EntrenamientoPara entrenar al personal y mantenerlo entrenado ACTIVITIES OUTPUTS Salidas Actividades Uso interno Procesos invocados Implementación del Proceso Plan de Entrenamiento Desarrollo del material de entrenamiento Manuales de Entrenamiento Implementación del Plan de entrenamiento Registros de Entrenamiento [Personal entrenado]

44 Proceso de Ajuste Un proceso especial• Para el ajuste del estándar a un proyecto - Agregados en contrato • Este proceso no admite ajuste Salidas Actividades Uso interno Procesos invocados ACTIVITIES OUTPUTS Identificar ambiente del proyecto Características del proyecto Solicitar información Entradas de las organizaciones Procesos, activi- dades y tareas seleccionadas Seleccionar procesos, actividades y tareas Documentar las razones y decisiones de ajustes Razones y decisiones de ajustes 3-33

45 Procesos basados en evaluaciónF I M P R O V S E M E N T R M A N C E E O V A F L N U O A T C I T A R O E N Y E N M V S P L E A L U P A I N T R E V U N A L E V I S A T O R L I J E E U O W T A N N T I S I O N S INTER-PARTY PROCESS 1 EVALUATIONS PROCESS n V E I O N A U D I T R I F A T I C A D T I O L I N & V A Q U E A L I T Y A S S U R A N C Múltiples tareas basadas en evaluación I M P R O V E M E N T • Evs. internas a un proceso: contra criterios especificados • Verificación: respecto a (resultados de) actividades previas • Validación: respecto al uso previsto • QA: Aseguramiento respecto a requerimientos/planes • Revisiones Conjuntas (Jnt.Rev.): Evaluaciones del estado del proyecto y de productos • Auditoría: Evaluación del cumplimiento con requerimientos/planes/contrato

46 Funciones Críticas Proceso Tareas Adquisición Suministro Desarrollo• Incluir estándares/procedimientos relacionadas con diseño/ testing/ conformidad • DEFINE SAFETY/SECURITY/CRITICALITY REQUIREMENTS Abordar en planes de proyecto (se sugieren planes separados) gestión de: - SAFETY/SECURITY/ Requerimientos críticos - Polítca/ Regulación/ Certificación relacionados Suministro Desarrollo Abordar planificación, análisis, diseño y cualificación de requerimientos relacionados con seguridad (safety,security) y críticos, incluyendo ergonomía • Analizar impacto de modificaciones sobre funciones de seguridad (safety/security) /críticas Mantenimiento • Producir/ almacernar documentos de acuerdo a políticas de seguridad Documentación Gest. Configuración • Controlar/auditar acceso al software que procesa funciones de seguridad (safety/security) / críticas • Determinar esfuerzo de verificación por requerimiento crítico • Verificar mediante métodos rigurosos que las funciones de seguridad (safety/security) /críticas son analizadas/ diseñadas/ codificadas correctamente Verificación Nota: puede ser suplementado o adaptado para sistemas críticos para la seguridad (sec./safe)

47 Procesos e interaccionesORGANIZATION MANAGEMENT INFRASTRUCTURE TRAINING IMPROVEMENT M F PROJECT OPERATION F F F F E: 3 T O ACQUISITION SUPPLY MAINTENANCE O U: 4 T U: 4 E E: 2,3 T P JOINT REVIEW E E: ACQ E U E: 3 T: SUB E U E AUDIT P QA E: 3 DEVELOPMENT E: 3 E: 1,2,3 (T)E E (I)V&V V&V E: 3 E: 3 1 E 2 3 4 PROBLEM DOCUMENTATION CM TAILORING RESOLUTION O - THE SAME POINTS, ACQ - ACQUISITION, SUB - SUBCONTRACTOR PDCA E - EXECUTE, F - FEEDBACK, M - MANAGE, P - PARTICIPATE, T - TASK; U - USE E:N - EXECUTE THE PROCESS NUMBERED N

48 Claves en el Desarrollo de SINotación Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Metodología Herramientas

49 Notación “El modelado captura las partes esenciales del sistema”Orden Item envío Proceso de Negocios Sistema Computacional

50 Notación Modelado para manejar la Complejidad“... Hay dos formas de construir software: una es hacerlo tan simple que obviamente no existan deficiencias, otra es hacerlo tan complejo que no existan deficiencias obvias” C:A.R. Hoare, Turing Award Lecture 1980.

51 Notación Modelado de la Arquitectura del SWInterface de Usuario (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.' by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?" asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself." Servidor de BDs (C++ & SQL, ..) “Modelar el sistema independientemente del lenguaje de implementación”

52 Notación Modelado para promover la ReutilizaciónMúltiples Sistemas Componentes Reutilizados

53 Metodología ¿Qué es una Metodología?En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo No existe una metodología de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable Sistema nuevo o modificado Requisitos nuevos o modificados Proceso de Desarrollo de Software

54 Metodología Procesos y MetodologíasLa Ingeniería de Software como disciplina Algunos modelos de proceso de desarrollo son: desarrollo en Cascada, usando Prototipos, Basado en Componentes, en Espiral (Incremental, Iterativo), Programación Automática. Las metodologías se basan en alguna combinación de estos enfoques Las metodologías (tanto comerciales como en el ámbito académico y de investigación) pueden ser agrupadas en dos grandes corrientes: Metodologías Estructuradas y Metodologías Orientadas a Objetos

55 Metodología Metodologías EstructuradasLos métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño primero y luego para el Análisis. Enfocados a implementaciones usando lenguajes de 3ra generación Ejemplos de metodologías estructuradas gubernamentales: MERISE (Francia), MÉTRICA 3 (España), SSADM (Reino Unido) Ejemplos de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering

56 Metodología Metodologías Orientadas a Objetos (OO)Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C#. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto En 1995 aparece el Método Unificado, que posteriormente se reorienta para dar lugar al Unified Modeling Language (UML), la notación OO más popular en la actualidad Algunos métodos OO con notaciones predecesoras de UML: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh) Algunas metodologías orientadas a objetos basadas en UML: Rational Unified Process (RUP), OPEN, MÉTRICA 3

57 Metodología Elementos de un Proceso SWActividades Herramientas Personas Proceso SW Roles Artefactos Notación

58 Herramientas CASE CASE es un acrónimo para Computer-Aided Software Engineering, aunque existen algunas variaciones para lo que actualmente se entiende por CASE: C Computer A Aided Assisted Automated S Software Systems E Engineering

59 Herramientas CASE ¿Qué es una CASE?En “Terminology for Software Engineering and Computer-aided Software Engineering”, B.Terry & D.Logee, Software Engineering Notes, Abril 1990, CASE es definido como: “Herramientas individuales para ayudar al desarrollador de software o administrador de proyecto durante una o más fases del desarrollo de software (o mantenimiento).” En “The CASE Experience”, Carma McClure, BYTE Abril 1989 p.235 se ofrece la siguiente definición: “Una combinación de herramientas de software y metodo-logías de desarrollo”

60