Ingeniería de Software I - Teoria PDF

Title Ingeniería de Software I - Teoria
Author Julio Giacoman Barba
Course Ingenieria De Software I
Institution Universidad Autónoma Gabriel René Moreno
Pages 8
File Size 128.9 KB
File Type PDF
Total Downloads 106
Total Views 143

Summary

Avance de la materia Ingenieria de software I - Ing Rolando Martinez...


Description

Ingeniería de Software I Ing. Rolando Martínez Canedo 1. INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE Calidad Satisfaga todos los requerimientos de los usuarios (Mide El Producto) Productividad Producir en menor tiempo, costo, esfuerzo (Mide El Proceso) Discutible La complejidad del problema, la plataforma del lenguaje de programación 2. EL PRODUCTO DE SOFTWARE Características: Otro Producto 

Es tangible, se deteriora, fabricado.

Software 

El software es abstracto y desarrollado



No es resultado de un proceso de fabricación



El Software es convencional, distinto, particular



El Software es extraordinario, es comprendido por un ISW



El software no se gasta, pero se vuelve obsoleto

3. APLICACIONES DEL SOFTWARE 

Software de sistemas (lo que hace posible que otro software haga su trabajo; ej.: so, motor de base de datos, drive)



Software de gestión (proceso volúmenes enormes de datos, son softwares empresariales)



Software de tiempo real (aquel que utiliza información que se da en el momento, SIG)



Software de ingeniería o científico (se utiliza para realizar operaciones complejas, simulador)



Software de computadora personal (software de carácter portable y rápido)



Software empotrado (es dependiente de otro software, no es movible)



Software de Inteligencia Artificial (es determinístico, regla, conocimiento, sistemas expertos)



Software para la web (juegos portables, comercio electrónico, mensajería).

EL PROCESO Es un conjunto de pasos, ideas. En todo lo que tenga que ver el software, Proceso=Ing. de software La Gestión De Software Son las actividades de: planificación, desarrollo, soporte técnico (ciclo de vida) Ingeniería de Software Es un enfoque sistemático, disciplinado y cuantificable que se aplica a lo largo del ciclo de vida del software. Enfoque. - tiene visión sobre la gestión del software. Sistemático. - Estaba planificado, organizable. Disciplinado. - Normas, principio, éticas, que tiene el Ing. de software, estándares. Cuantificable. - Poder medir, evaluación para determinar un estado, para saber si esta mejor, peor. Tecnología Multicapa. - Enfoque de calidad, Estrategia (es hacerlo en el menor tiempo), Métodos (tiene un alcance reducido, debe tener por lo menos 2 cosas: lenguaje (me proporciona mecanismo para poder implementar el proceso), proceso (secuencia de pasos)), Herramientas (Es un instrumento para facilitar el trabajo(HW/SW)) Los mejores aspectos de SW  Calidad, Productividad 4. PROCESO DE DESARROLLO DE SOFTWARE Marco De Trabajo Genérico Del Software: Comunicación, Planificación, Modelado, Construcción, Despliegue. Definición del Proyecto: comunicación, planificación. Elementos de Configuración del Software: comunicación, planificación, modelado, construcción. Comunicación. - ¿Cuál es el propósito de la comunicación? Es poder entender de qué se trata todo el contexto donde se va a desarrollar el software. Pueden ser reuniones, entrevistas, manuales de funciones. Por lo menos debe haber 2 partes (DesarrolladorCliente). -Requerimiento. - Expresa el contenido que se va a desarrollar, en terminología natural (cualquier persona puede entenderlo) -Requisitos. - Es lo que el software debe hacer, pero ya está expresado en un lenguaje técnico, propósito: reducir la ambigüedad, es universal(UML) -Especificación de Requisitos. - Describe lo que el software debe hacer, lo que se debe cumplir antes del querer iniciar algún tipo de actividad. Es una descripción detallada,

completa, libre de ambigüedad de c/u de los requerimientos (Diagrama de Colaboración, Estado, Actividades, Pseudocódigo) -Funciones del software. - Es lo que el software debe hacer, pero ya está implementado. Las funciones son la implementación de los requisitos del software Planificación. - PAPS (Plan de Administración de Proyecto de Software) Objetivos, Requerimientos principales, Rendimiento (tiempo esperado), Fiabilidad (grado de confianza), Análisis de Riesgo (Prevenir para que el plan se vaya a completar), Estimaciones (cuanto, tiempo, desarrollo del software), planificación Temporal (uso del tiempo), Análisis de Factibilidad (técnica (tecnología del proyecto), económica (presupuesto), legal (contrato)) Modelo. - Es una representación de un conjunto de abstracciones en el análisis y diseño. Análisis. - “que es lo que el SW debe hacer” ERS (Especificación del Requisito de Software). Diseño. - “Como” va ser implementado el SWDDS (Descripción de Diseño de SW). Cuando se está definiendo ED, Algoritmos, Interfaces, Arquitectura, Procesos, etc. ¿Cuándo el SW es correcto? Es correcto cuando hace todo lo que el cliente quiere. El diseño describe como el SW va a satisfacer todos los requisitos del análisis. El diseño describe como el SW debe ser implementado. Construcción. - Es llegar a obtener el producto final -Implementación. - CF (Código Fuente)  Programando, codificando=traducir de los modelos de diseño a un conjunto de instrucciones escritas en algún lenguaje de programación. -Pruebas de Unidad. - Es la búsqueda de errores. RP (Reporte de Pruebas)Reporte de Pruebas (preparación de datos de entrada, estructura, etc.), Ejecución del Plan (en función al reporte se sabrá de las falencias en que puntos se han encontrado). Despliegue. - Pruebas alfa, beta; instalación(migración). - diagrama de despliegue; Capacitación. - manual de usuarios, seminario, help disk, etc. Operación. - (proceso donde los usuarios utilizan el software, el software entra en producción). Mantenimiento. - Siempre que estoy haciendo “CAMBIOS” es mantenimiento. 4 razones Por La Cual Hacer Mantenimiento Correctivo, Adaptativo, Preventivo, Perfectivo. Durante la fase de operación aparece un defecto y cambiarlo, adaptar el software en función a la nueva estructura del negocio, no hay fallas no hay cambios, no hay errores,

no cambia la política, el software no va fallar, el software puede mejorar haciendo algunos cambios. ESTRATEGIAS DE DESARROLLO  Ciclos de vida (ventajas, desventajas, producto, cuando usarlo) 5. GESTION DE PROYECTOS DE SOFTWARE (GPS) DIRECCION DE PROYECTO. - Ing. de software ”GESTOR” PAPS (Plan de administración de proyecto de software) Es un PROYECTO EXITOSO cuando: Un gestor es el que crea el proyecto, Un gestor es el encargado de la ejecución del proyecto, Un gestor que se concluya con éxito. Anteproyecto=perfil de proyecto=plan de proyecto es como una presentación de propuestas, es lo que se hace antes de comenzar el proyecto Ejecutar un Proyecto: es cuando la base es estable, como el propósito, recursos, etc. ¿Qué habrá antes de un proyecto? Una planificación ¿Cuándo se inicia un proyecto? Cuando un plan de proyecto es aceptado o aprobado. ¿Qué se hace durante un proyecto? Se hace ejecución de la planificación de un proyecto. ¿Cuándo se concluye un proyecto? Cuando se logra que los objetivos fueron alcanzados ¿Cuándo se termina un proyecto con éxito? Que se lograron los objetivos y requerimientos, haberlo hecho el proyecto según lo calculado (tiempo, costo y trabajo) ¿Qué motiva a hacer un plan? PAPS. Un plan de proyecto es lo que nos hace hacerlo de manera efectiva. Un buen plan debería ejecutar con éxito al proyecto -Responsabilidades de un Gestor de Software. Personal: es el encargado del esfuerzo humano (# de personas), quienes van a desarrollar, cual es el perfil de c/u de los integrantes del grupo de desarrollo, roles, seguimiento, comunicación, supervisión, motivación. Producto: Es el resultado del proyecto de la definición de las características del producto que se va a desarrollarRequisitos funcionales, requisitos no funcionales. Proceso: Son los cambios que se efectúan a medida del desarrollo, tiene que utilizar la tecnología de SW (tecnología Multicapa) Proyecto: Es la planificación y construcción

-Características de un Proyecto de Software. - La comunicación entre el cliente y el dpto. de desarrollo (para ser analista) debe ser buena persona en la comunicación. Las características que debe tener un analista: Liderazgo (organizado), Especialista en tema de decisiones (un tipo que tiene información (conocimiento)), Debe ser un generador de ideas (no puede ser pasivo, es el q siempre se le prende el foco), Un negociador por naturaleza, Motivador. Factores De Motivación En El Equipo De Trabajo. - Sueldo o recursos económicos, el trato (la forma de cómo valorar, dirigirse e interactuar con una persona), herramientas de trabajo (lugar, clima apropiado, como interactuar buen ambiente de trabajo), reconocimiento de los logros (promociones, vacaciones, cursos, talleres, etc.), apoyo de la actualización (cursos, talleres, consolidar su información de su conocimiento, saber o aprender más de información), publicidad 6. METRICAS DEL SOFTWARE Mediciones, cuando estamos comparando un objeto con una referencia y algún objeto definido. Métricas es un conjunto de Datos de proyectos previos para ver: que paso con el proyecto, para hacer estimaciones. -Métricas Directas. - Medir en un solo paso, no deja ambigüedad, asocia a una escala definida. MOT (Métricas Orientas al Tamaño) -Métricas Indirectas. - Su resultado es subjetivo, podría dejar un cierto grado de ambigüedad (porque podría ser muy discutible), se hace a través de pasos (un test), MOF (Métricas Orientadas a la Función). 7. ESTIMACIONES EN EL SOFTWARE Costo (a la inversión económica para el desarrollo del software), Tiempo (en el periodo de tiempo que toma el completo desarrollo del software), Esfuerzo. - Los elementos que se deberían analizar, cuanto tiempo, costo y esfuerzo va tardar: Tamaño: lo podemos clasificar (pequeño, mediano, grande), se puede hacer a través del # de requerimientos o funciones que se espera que el software va a hacer Complejidad: (simple, intermedio, avanzado) está dado por el sistema y por el grado de operaciones que tiene el software, el grado de interacción que hay entre ellas, el grado de conocimiento que tengamos de lo que vamos hacer. Estructuración del cliente: es el grado de organización que tiene el cliente con el que vamos a trabajar

- Ámbito del software: para definir el alcance del proyecto. Objetivos del proyecto, requerimientos principales, rendimiento, fiabilidad, restricciones, interfaces externas. Objetivo General  Todo lo que se va a hacer Objetivo Específico  Como alcanzarlo, son las metas para alcanzar el objetivo general. (diseño, pruebas, implementación, análisis, requisitos)PUDS Requerimientos  expresados en lenguaje natural Rendimiento  asociar al tiempo de respuesta-eficiencia Fiabilidad  es el grado de tolerancia con respecto a las fallas o defectos Restricciones  técnicas (plataforma), legales (el software su funcionalidad está regida por alguna disposición legal (bancos, sistema facturación)), recursos (tiene que ver con el tiempo, fecha de entrega, etc.) Interfaces Externas  Con que otras entidades externas va interactuar donde sea necesario interactúan con una interfaz. Métodos de Estimación -Orientadas al tamaño KLDC. Ventajas: método sencillo, se pueden obtener estimaciones de tiempo y costo. Desventajas: depende de la plataforma del desarrollo 3GL – 4GL, depende de las líneas de código, las metodologías de diseño pueden cambiar de un tiempo a otro, los datos históricos pueden ser antiguos -Cocomo Básico. Significa modelo constructivo corto. Identifica al proyecto en una categoría (orgánico, semiacoplado, empotrado) -Cocomo II. este enfoque está pensado en proyectos de software orientados a objetos, se puede llenar bajo el criterio del diagrama de CU, del total del software cuanto se va reutilizar. -Ecuación del SW. La ecuación del software es un modelo multivariable que asume una distribución específica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. GESTION DE RIESGOS Estrategias a) Riesgo Reactiva: es la forma natural de afrontar los riesgos, es cuando de pronto sucede el riesgo y en ese momento analiza el riesgo y toma decisiones. b) Riesgo Proactiva: para un determinado propósito tratar de establecer de establecer un conjunto de actividades con el propósito de reducir la presencia de riesgos y la probabilidad de aminorar el riesgo

Riesgo Técnico: Todas las situaciones no previstas, interpretación de requisitos, usar un ciclo de vida inapropiado, pérdida de código fuente, HW y SW indebidos y necesarios, etc. Riesgo de Gestión: Que afectan desde el punto de vista de la administración, estimaciones mal hechas, cronograma mal planeado, problema con el personal, uso económico, tiempo, etc. Riesgo de Negocio: Son los más críticos, porque el impacto es sobre todo el proyecto. Ej.: que quiebre el negocio que pidió el software, no saber vender el software, oportunidades del mercado, etc. Análisis de Riesgos -Identificar Riesgos: una vez hecho el plan, tenemos que pensar que pueda salir mal -Determinar Probabilidad de Presencia: hay probabilidad de riesgo, tiene la probabilidad de que se un X% -Medir el Impacto: Analizamos c/u de los riesgos (efecto en el proyecto, riesgo, impacto, critico, etc.) -Evaluación de Riesgo: Ver el tipo de impacto y como se puede elaborar -Elaborar Plan de aversión o contingencia. - Se debe hacer un conjunto de actividades para reducir la probabilidad del riesgo (moderado, significativo, crítico) PLANIFICACION TEMPORAL a) Identificar Actividades: Estrategias, MétodosEstructurado, OO. b) Asignar tipo a las actividades (Análisis y Diseño 50-60%, Implementación 20-25%, Pruebas 25-30%) FUNDAMENTOS DEL ANALISIS a) Reconocimiento (definir el contexto en el que se va a trabajar). b) Evaluación (basarse alternativas a los problemas o dificultades - REQUERIMIENTOS). c) Modelado (usando métodos abstractos y modelos. Está basado en 2 puntos: que sirva para reducir la complejidad de modo que, sirva como elemento de comunicación – UML REQUISITOS). d) Especificación (agarra uno por uno y empieza a describirlos de forma detallada, eliminado ambigüedad, debe tener procesos, datos, interfaces). e) Revisión (tenemos que encontrar alguna manera que lo que identificado es lo correcto, satisfaga al cliente, cumpla con alguna metodología conocida) Punto de Vista de Validación. - Es una aproximación o construcción de prototipo, una vez que cumple su misión de válidas, quien decide es el cliente y el analista, se deshecha, para comenzar la original basada en las aproximaciones.

Punto de Vista de Calificación. - Basado en preguntas, es como una autoevaluación, si se ha utilizado alguna forma de requisito, etc. FUNDAMENTOS DEL DISEÑO Es la etapa de soluciones (creativos, ingeniosos, etc.), como va ser diseñado e implementado el software (DDS), las 4 razones para presentar cuando uno diseña: ED, Arquitectura, Formulario o Interfaces, Proceso....


Similar Free PDFs