Ciclo de vida RUP

DE ENTRE TODOS LOS MODELOS DE CICLO DE VIDA , EXISTE EL MODELO RUP QUE ASEGURA LA PRODUCCIÓN DE SOFTWARE DE ALTA CALIDAD QUE CUMPLA CON LAS NECESIDADES DE LOS USUARIOS, CON UNA PLANEACIÓN Y PRESUPUESTO PREDECIBLE.

             EL CICLO DE VIDA RUP SE DIVIDE EN 4 FASES: INICIACIÓN,ELABORACIÓN, CONSTRUCCIÓN Y TRANSICIÓN.                                          

CONCEPCIÓN, INICIO O ESTUDIO DE OPORTUNIDAD

• Define el ámbito y objetivos del proyecto;

• Se define la funcionalidad y capacidades del producto;

ELABORACIÓN

• Tanto la funcionalidad como el dominio del problema se estudian en profundidad; • Se define una arquitectura básica;

• Se planifica el proyecto considerando recursos disponibles;

CONSTRUCCIÓN

• El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación;

• Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura);

• Gran parte del trabajo es programación y pruebas;

TRANSICIÓN

• Se libera el producto y se entrega al usuario para un uso real;

• Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc.

• Los manuales de usuario se completan y refinan con la información anterior; Todas las fases no son idénticas en términos de tiempo y esfuerzo.

RUP PARA EL DESARROLLO DE SOFTWARE MODERNO QUE JUNTO CON UML TRATA DE MEJORAR EL DESARROLLO DE SOFTWARE NO SOLO CON UNA SERIE DE PASOS ESTABLECIDOS SI NO COMBINANDO VARIOS MODELOS, ESTO DEPENDIENDO DE LAS NECESIDADES DE LA EMPRESA QUE LO SOLICITE.

CICLO DE VIDA SCRUM

SCRUM  DEFINE  UN  PROCESO  EMPÍRICO,  ITERATIVO  E  INCREMENTAL  DE  DESARROLLO QUE INTENTA OBTENER VENTAJAS RESPECTO A LOS PROCESOS DEFINIDOS (CASCADA, ESPIRAL, PROTOTIPOS, ETC.)

EL PROCESO

EN SCRUM UN PROYECTO SE EJECUTA EN BLOQUES TEMPORALES CORTOS Y FIJOS (ITERACIONES DE UN MES NATURAL Y HASTA DE DOS SEMANAS, SI ASÍ SE NECESITA). CADA ITERACIÓN TIENE QUE PROPORCIONAR UN RESULTADO COMPLETO, UN INCREMENTO DE PRODUCTO FINAL QUE SEA SUSCEPTIBLE DE SER ENTREGADO CON EL MÍNIMO ESFUERZO AL CLIENTE CUANDO LO SOLICITE.

EL PROCESO PARTE DE LA LISTA DE OBJETIVOS/REQUISITOS PRIORIZADA DEL PRODUCTO, QUE ACTÚA COMO PLAN DEL PROYECTO. EN ESTA LISTA EL CLIENTE PRIORIZA LOS OBJETIVOS BALANCEANDO EL VALOR QUE LE APORTAN RESPECTO A SU COSTE Y QUEDAN REPARTIDOS EN ITERACIONES Y ENTREGAS. DE MANERA REGULAR EL CLIENTE PUEDE MAXIMIZAR LA UTILIDAD DE LO QUE SE DESARROLLA Y EL RETORNO DE INVERSIÓN MEDIANTE LAREPLANIFICACIÓN DE OBJETIVOS QUE REALIZA AL INICIO DE CADA ITERACIÓN. 

UN PRINCIPIO CLAVE DE SCRUM ES EL RECONOCIMIENTO DE QUE DURANTE UN PROYECTO LOS CLIENTES PUEDEN CAMBIAR DE IDEA SOBRE LO QUE QUIEREN Y NECESITAN.

Casos de uso UML

El CASO DE USO REPRESENTA UNA UNIDAD FUNCIONAL COHERENTE

DE UN SISTEMA, SUBSISTEMA O CLASE.

EN UN CASO DE USO UNO O MAS ACTORES INTERACCIONAN CON EL SISTEMA QUE REALIZA ALGUNAS ACCIONES.

ELEMENTOS DE UN MODELO DE CASOS DE USO:

      ·         ACTORES

      ·         CASOS DE USO

      ·         RELACIONES

ACTOR:

UNA DEFINICIÓN PREVIA, ES QUE UN ACTOR ES UN ROL QUE UN USUARIO JUEGA CON RESPECTO AL SISTEMA. ES IMPORTANTE DESTACAR EL USO DE LA PALABRA ROL, PUES CON ESTO SE ESPECIFICA QUE UN ACTOR NO NECESARIAMENTE REPRESENTA A UNA PERSONA EN PARTICULAR, SINO MÁS BIEN LA LABOR QUE REALIZA FRENTE AL SISTEMA.

CASO DE USO:

ES UNA OPERACIÓN/TAREA ESPECÍFICA QUE SE REALIZA TRAS UNA ORDEN DE ALGÚN AGENTE EXTERNO, SEA DESDE UNA PETICIÓN DE UN ACTOR O BIEN DESDE LA INVOCACIÓN DESDE OTRO CASO DE USO.

RELACIONES:

• ASOCIACIÓN: 

ES EL TIPO DE RELACIÓN MÁS BÁSICA QUE INDICA LA INVOCACIÓN DESDE UN ACTOR O CASO DE USO A OTRA OPERACIÓN (CASO DE USO). DICHA RELACIÓN SE DENOTA CON UNA FLECHA SIMPLE.

• DEPENDENCIA O INSTANCIACIÓN:

ES UNA FORMA MUY PARTICULAR DE RELACIÓN ENTRE CLASES, EN LA CUAL UNA CLASE DEPENDE DE OTRA, ES DECIR, SE INSTANCIA (SE CREA). DICHA RELACIÓN SE DENOTA CON UNA FLECHA PUNTEADA.

• GENERALIZACIÓN:

ESTE TIPO DE RELACIÓN ES UNO DE LOS MÁS UTILIZADOS, CUMPLE UNA DOBLE FUNCIÓN DEPENDIENDO DE SU ESTEREOTIPO, QUE PUEDE SER DE USO (<<USES>>) O DE HERENCIA (<<EXTENDS>>).

ESTE TIPO DE RELACIÓN ESTA ORIENTADO EXCLUSIVAMENTE PARA CASOS DE USO (Y NO PARA ACTORES).

EXTENDS: SE RECOMIENDA UTILIZAR CUANDO UN CASO DE USO ES SIMILAR A OTRO (CARACTERÍSTICAS).

USES: SE RECOMIENDA UTILIZAR CUANDO SE TIENE UN CONJUNTO DE CARACTERÍSTICAS QUE SON SIMILARES EN MÁS DE UN CASO DE USO Y NO SE DESEA MANTENER COPIADA LA DESCRIPCIÓN DE LA CARACTERÍSTICA.

DE LO ANTERIOR CABE MENCIONAR QUE TIENE EL MISMO PARADIGMA EN DISEÑO Y MODELAMIENTO DE CLASES, EN DONDE ESTA LA DUDA CLÁSICA DE USAR O HEREDAR.  

METRICAS Y CALIDAD DE SOFTWARE

CONJUNTO DE MEDIDAS DESTINADAS A CONOCER O ESTIMAR EL TAMAÑO U OTRA CARACTERÍSTICA DE UN SOFTWARE O UN SISTEMA DE INFORMACIÓN, GENERALMENTE PARA REALIZAR COMPARATIVAS O PARA LA PLANIFICACIÓN DE PROYECTOS DE DESARROLLO. 

EN LA SIGUIENTE FIGURA PUEDEN OBSERVAR QUE LAS MÉTRICAS PUEDEN PROPORCIONAR UNA RETROALIMENTACIÓN IMPORTANTE PARA MEJORAR LA CALIDAD DEL PRODUCTO DE SOFTWARE

LA MÉTRICAS DE SOFTWARE SON LAS QUE ESTÁN RELACIONADAS CON EL DESARROLLO DEL SOFTWARE COMO FUNCIONALIDAD, COMPLEJIDAD, EFICIENCIA.

                             

                                 LAS MÉTRICAS Y LA CALIDAD DE SOFTWARE

EL OBJETIVO PRIMORDIAL DE LA INGENIERÍA DEL SOFTWARE ES PRODUCIR UN SISTEMA,  APLICACIÓN O PRODUCTO DE ALTA CALIDAD

                                                  CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE ES UNA PREOCUPACIÓN A LA QUE SE DEDICAN MUCHOS ESFUERZOS. SIN EMBARGO, EL SOFTWARE CASI NUNCA ES PERFECTO. TODO PROYECTO TIENE COMO OBJETIVO PRODUCIR SOFTWARE DE LA MEJOR CALIDAD POSIBLE, QUE CUMPLA, Y SI PUEDE SUPERE LAS EXPECTATIVAS DE LOS USUARIOS.

            OTRAS METRICAS QUE SE APLICAN EN LOS SOFTWARE

METRICAS DEL MODELO DE ANALISIS,  METRICAS BASADAS EN LA FUNCIÓN,

LA METRICA BANG,  METRICAS DE LA CALIDAD DE ESPECIFICACION,  METRICA DEL MODELO DEL DISEÑO METRICAS DE DISEÑO DE ALTO NIVEL, METRICAS DE DISEÑO EN LOS COMPONENTES,  METRICAS DE COHESION, METRICAS DE ACOPLAMIENTO,

METRICAS DE COMPLEJIDAD,  METRICAS DE DISEÑO DE INTERFAZ,  METRICAS DE CODIGO FUENTE,  METRICAS PARA PRUEBAS,  METRICAS DE MANTENIMIENTO.

¡¡¡¡ LINK DE MATERIAL DE ESTUDIO¡¡

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo4.pdf

MODELAMIENTO VISUAL Y UML

                                            ¿QUÉ ES EL MODELAMIENTO VISUAL?

EL MODELAMIENTO VISUAL PROVEE UNA PLANTILLA DEL SISTEMA. EL VISUALIZAR ESTA PLANTILLA,  AYUDA A ENTENDER EL SISTEMA QUE SE CREA Y CÓMO QUISIERA CREARSE, PERMITE ENTENDER LA ESTRUCTURA O COMPORTAMIENTO DEL MISMO, SIRVE DE GUÍA DURANTE EL PROCESO DE CONSTRUCCIÓN DEL SW Y NOS PERMITE DOCUMENTAR LAS DECISIONES QUE SE TOMAN.

                                         BENEFICIOS DEL MODELAMIENTO VISUAL

•          CAPTURA PROCESOS

•          INCREMENTA LA COMUNICACIÓN

•          DEFINE LA ARQUITECTURA

•          ADMINISTRA LA COMPLEJIDAD

•          REUTILIZACIÓN                                

                                                                UML

LENGUAJE UNIFICADO DE MODELADO: LENGUAJE ESTÁNDAR QUE PERMITE VISUALIZAR,   ESPECIFICAR, CONSTRUIR Y DOCUMENTAR LOS ARTEFACTOS DEL SISTEMA DE SOFTWARE. ESTÁ DEMOSTRADO QUE EL TRABAJO CON UML INCREMENTA LA PRODUCTIVIDAD, REDUCE EL CICLO DE VIDA DE CONSTRUCCIÓN DEL SOFTWARE E INCREMENTA LA CALIDAD DEL SISTEMA.

                                                  PERSPECTIVAS PARA EL UML

UML ES EL LENGUAJE DE MODELAMIENTO ESTÁNDAR PREDOMINANTE LOS PRÓXIMOS AÑOS. ENTRE LAS RAZONES:

• PARTICIPAN METODOLOGISTAS INFLUYENTES.
• PARTICIPAN EMPRESAS IMPORTANTES.
• TIENE LA ACEPTACIÓN DEL OMG COMO NOTACIÓN ESTÁNDAR.

                                                          DESCRIPCIÓN DE UML

•          LOS ELEMENTOS Y DIAGRAMAS UML ESTÁN BASADOS EN EL PARADIGMA ORIENTADO A OBJETOS.

•          ENTRE LAS PARTES DE UML TENEMOS:

                    1. LAS VISTAS.

                    2. LOS DIAGRAMAS.

                    3. LOS ELEMENTOS DEL MODELO.

                    4. LO MECANISMOS DE EXTENSIÓN.

  

EL CICLO DE VIDA MODERNO DE UN SISTEMA.

DEL ESTUDIO PRELIMINAR SE PUEDEN DERIVAR VARIOS PROYECTOS DE SISTEMAS O NINGUNO. CADA UNO DE LOS PROYECTOS QUE SE GENERE DEBERÁ TRANSITAR POR LAS RESTANTES ETAPAS.

                              SE GARANTIZA LA MODELACIÓN EN FORMA FÍSICA Y LÓGICA.

Las etapas de desarrollo de un sistema se dividen en 2 grupos en función de la orientación de los modelos que utilizan:

·    Las relacionadas con el estudio del problema:

·    Estudio Preliminar.

·    Análisis.

·    Las relacionadas con los requerimientos del proceso computacional o de solución del problema.

·    Diseño.

·    Desarrollo.

LA INGENIERÍA DEL SOFTWARE SEGÚN LA IEEE

       ¿QUÉ ES LA INGENIERÍA DEL SOFTWARE SEGÚN LA IEEE?

LA INGENIERÍA DEL SOFTWARE SEGÚN LA IEEE ES AQUELLA APLICACIÓN PRÁCTICA DEL CONOCIMIENTO  CIENTÍFICO EN EL DISEÑO Y CONSTRUCCIÓN DE PROGRAMAS DE COMPUTADORA Y  LA DOCUMENTACIÓN ASOCIADA REQUERIDA PARA DESARROLLAR, SU TRABAJO ES PROMOVER LA CREATIVIDAD, EL DESARROLLO Y LA INTEGRACIÓN, COMPARTIR Y APLICAR LOS AVANCES EN LAS TECNOLOGÍAS DE LA INFORMACIÓN, ELECTRÓNICA Y CIENCIAS EN GENERAL PARA BENEFICIO DE LA HUMANIDAD Y DE LOS MISMOS PROFESIONALES.

¿EN QUÉ SE DIFERENCIA UN PROGRAMADOR DE UN INGENIERO DE SOFTWARE?

UN INGENIERO DE SOFTWARE NO SE ENFOCA EN ENTENDER COMO FUNCIONA EL PROGRAMA DENTRO DE UN SISTEMA OPERATIVO, O POR ASI DECIRLO, DENTRO DE LA COMPUTADORA.  LE IMPORTA QUE EL PRODUCTO (SOFTWARE) ENTREGADO CUMPLA CON LOS REQUERIMIENTOS DEFINIDOS, DE FORMA QUE LE ENTREGUE “VALOR” AL CLIENTE, MAS  EL PROGRAMADOR SABE COMO FUNCIONA EL SOFTWARE, ES DECIR, QUE ALGORITMOS UTILIZA, COMO MANEJA LA MEMORIA, MANEJO DE RECURSOS DEL COMPUTADOR PARA PODER REALIZAR ALGUNA TAREA O PROCEDIMIENTO COMPUTACIONAL.

1.    ¿CUÁL ES LA DIFERENCIA ENTRE UN INGENIERO DE SOFTWARE Y UN INGENIERO DE SISTEMAS?

LA INGENIERÍA DE SOFTWARE ES LA DISCIPLINA O ÁREA DE LA INFORMÁTICA QUE OFRECE MÉTODOS Y TÉCNICAS PARA DESARROLLAR Y MANTENER SOFTWARE DE CALIDAD A FIN DE OBTENER SOFTWARE DE MODO RENTABLE, QUE SEA FIABLE Y TRABAJE EN MÁQUINAS REALES MAS EL INGENIERO DE SISTEMAS ES AQUEL QUE PERMITE IMPLEMENTAR U OPTIMIZAR SISTEMAS COMPLEJOS Y TRANSFORMAR UNA NECESIDAD DE OPERACIÓN EN UNA DESCRIPCIÓN DE PARÁMETROS DE RENDIMIENTO DEL SISTEMA Y UNA CONFIGURACIÓN DEL SISTEMA A TRAVÉS DEL USO DE UN PROCESO INTERACTIVO DE DEFINICIÓN, SÍNTESIS, ANÁLISIS, DISEÑO, PRUEBA Y EVALUACIÓN PARA ASEGURAR LA COMPATIBILIDAD DE TODAS LAS INTERFACES DE PROGRAMA Y FUNCIONALES DE MANERA QUE OPTIMICE LA DEFINICIÓN Y DISEÑO DEL SISTEMA TOTAL.