El software	Construir software es semejante a otras ingenierias Se entrega: -Tarde -Excediendo el presupuesto -Con fallas residuales
Crisis del software	La ingenieria de software tiene sus problemas y propiedades unicos -Larga duración -Mal pronóstico
Metodo nuevo mas rapido Debería usarse?	COnsidere los costos de capacitación Consisdere el impacto de introducir una nueva tecnología Considere los efectos del metodo en el mantenimiento Suele primar la idea de producir "tan rápido como sea posible"
Modelo de ciclo de vida	Los pasos a seguir cuando se construye software Una descripción teórica de lo que debería hacerse
Ciclo de vida	Los pasos reales, ejecutados al desarrollar un producto específico
Modelo clásico (1970)	Fase de requisitos Fase de análisis (especificación) Fase de diseño Fase de implementación Mantenimiento posentrega Retiro
Fase de requerimientos	Explorar el concepto Obtener los requerimientos del cliente
Fase de análisis	Analizar los requerimientos del cliente Preparar el documento de especificaciones Preparar el plan de gestión del proyecto de software Qué se espera que haga el producto
Fase de diseño	Diseño arquitectónico, seguido por Diseño detallado Cómo lo hará el producto
Fase de implementación	Cada componente tiene codificación y pruebas unitarias Integración: prueba como un todo de todos los componentes Prueba de aceptación del cliente
Mantenimiento post-entrega	Mantenimiento correctivo Mantenimiento perfectivo Mantenimiento adaptativo
Retiro	nada
Consecuencias modelo clásico	EL producto ha sido instalado El cliente quiere funcionalidades extra El cliente quiere qu ese haga el mismo cambio antes de la instalacion ( meta móvil) El desarrollo desde cero es raro hoy en dia La reutilización está generalizada
Mantenimiento posentrega	Es primoridial reducir costos en esta fase antes que en la codificación Cuando antes detectemos y corrijamos una falla , menos nos costará
Corregir fallas	Temprano: generalmente, cambiar un documento Tarde: cambiar el codigo y la documentación, probar el cambio, realizar pruebas de regresión, reistalar el producto en las computadoras del cliente
Importancia de técnicas de requerimientos, análisis y diseño	Para encontrar fallas tan rapido como sea posible Reducir cantidad total de fallas (costo)
Planeación	Las actividades de planeación se llevan a cabo a lo largo de todo el ciclo de vida No hay una fase separada de planeación
Pruebas	Las actividades de prueba continuas deben llevarse a cabo a lo largo de todo el ciclo de vida Son responsabilidad de todo profesional de software y del grupo de aseguramiento de la calidad del software No hay fase separada de pruebas
Documentación	Deben realizarse en paralelo con todas las otras actividades de desarrollo y mantenimiento No hay una fase separada de documentación
Orientación a objetos	El paradigma estructurado tiene problemas de mantenimiento posentrega (70 a 80% del esfuerzo total) porque son orientados a acción o datos pero no ambos
Fortalezas de P O O	El mantenimiento posentrega es más seguro con el ocultamiento de información (menos fallas de regresión) Desarrollo más fácil: Los objetos tienen contrapartes físicas Simplifica el modelado
Mas fortalezad	Los objetos son unidades independientes La comunicación se realiza enviando mensajes El paradigma promueve la reutilización Los objetos son introducidos temprano: transicion suave del flujo de analisis al diseño y se codifican durante la implementación
Conclusión	Puede resolver algunos de los problemas del paradigma clásico Es la mejor alternativa disponible en la actualidad

Descubre

Crear Tarjetas

Acerca de Nosotros

Explore Tarjetas

Comparta este Set de Tarjetas de Aprendizaje

Tarjetas de Aprendizaje relacionadas

Analisis Ii Parcial 1

Cómo estudiar sus tarjetas

Rango de Cartas a estudiar

23 Cartas en este set