1. Control de proyecto
1.1. Se enfonca
1.1.1. Proceso continuo
1.1.1.1. Este proceso requiere de una estrategia global, apoyada por herramientas de trabajo que incrementen la productividad
1.1.1.2. El propósito de planificar y controlar es proveer una propuesta uniforme para el desarrollo y la administración de los proyectos.
1.1.2. Planificación
1.1.3. Organización
1.1.4. Staffing
1.1.5. Control
1.2. Aspectos relevantes
1.2.1. Habilidades de Gestión y la Jerarquía Organizacional
1.2.1.1. Habilidades Técnicas.
1.2.1.2. Habilidades Humanas
1.2.1.3. Habilidades Conceptuales
1.2.1.4. Habilidades de Diseño
1.2.2. problemas en la planificación de un proyecto de ingeniería de software
1.2.2.1. Requerimientos incorrectos e incompletos
1.2.2.2. No se manejan factores de riesgo
1.2.2.3. Las compañías no establecen políticas o procesos de desarrollo de software
1.2.2.4. Los costos y plazos no son re estimados cuando los requerimientos del sistema o el ambiente de desarrollo cambia.
1.2.2.5. Muchas especificaciones de requerimientos son inestables y sujetas a cambios mayores.
1.2.2.6. Es difícil estimar el tamaño y complejidad del proyecto de software
2. Calidad de software
2.1. Se enfoca en
2.1.1. Control de la calidad
2.1.2. Aseguramiento de la calidad
2.2. Aspectos relevantes
2.2.1. Fundamentos
2.2.1.1. Se destacan en
2.2.1.1.1. La ingeniería del software
2.2.1.1.2. Cultura y ética
2.2.1.1.3. Valor y costo de la calidad
2.2.1.1.4. Mejora de la calidad
2.2.1.1.5. Modelos y caracteristicas de la calidad
2.2.2. Procesos de gestión
2.2.2.1. Productor en termino de calidad
2.2.2.2. Planificacion de procesos
2.2.3. Consideraciones práctivas
2.2.3.1. Requerimientos
2.2.3.2. Técnicas de gestiín de calidad
2.2.3.3. Caracterización de defectos
2.2.3.4. Métricas
3. Tendencia Ingeniería del software
3.1. Existen diversas Tendencia dentro de la ingeniería del software, entra esas se encuentran
3.1.1. Programaciín orientado a objeto
3.1.2. Las herramientas CASE (Computer Aided Software Engineering (CASE))
3.1.2.1. De estas derivan los IDE ( entorno de desarrollo integrado)
3.2. Todas las tendencias son utilizadas para hacer facil el trabajo de programación y los programas sean de mayor calidad
3.2.1. La complejidad
3.2.2. La capacidad del diseño
3.2.3. Flexibilidad
3.2.4. Rapidez del desarrollo
3.2.5. Facilidad de modificación
3.2.6. Confiabilidad
4. Gestión de personal
4.1. Se enfoca
4.1.1. Mantener llenos los puestos que fueron establecidos en el proyecto
4.1.2. Seleccionar a cada caldidato, entrenamiento y otros.
4.2. Aspectos relevantes
4.2.1. Los principales problemas en esta etapa
4.2.1.1. Los jefes de proyecto son seleccionados por su habilidad para programar a en vez de su habilidad de gestión
4.2.1.2. La productividad de los programadores, analistas e ingenieros de software varía mucho de individuo en individuo.
4.2.1.3. Hay grandes cambios en el equipo de un proyecto software, especialmente en aquellos organizados matricialmente.
4.2.1.4. Los planes de entrenamiento para desarrolladores individuales de software no se desarrollan o mantienen.
4.2.1.5. Actividades derivadas
4.2.1.5.1. Llenar los puestos de la organización
4.2.1.5.2. Asimilar al personal recientemente asignado
4.2.1.5.3. Educar o entrenar al personal
4.2.1.5.4. Proveer de desarrollo general
4.2.1.5.5. Evaluar y valorar al personal
4.2.1.5.6. Compensar
5. Gestión de configuración
5.1. Identificación de configuración del software
5.1.1. Identifica elementos del software que seran controlados
5.1.2. Establece mnétodos de identificación que de los elementos
5.2. Control de la configuración del software
5.2.1. Proceso que determinan cambios a realiazar
5.2.2. Autoridad para aprobar cambios
5.3. Registro de estados
5.4. Auditorias de la configuración del SW
6. Ciclo de vida
6.1. Se enfoca
6.1.1. La secuencia estructurada y bien definida para el desarrollar el prodcuto del software deseado
6.2. Aspectos relevantes
6.2.1. Actividades del SDLC
6.2.1.1. Aporta una serie de pasos a seguir con la finalidad de diseñar y desarrollar un producto software de manera eficiente
6.2.1.1.1. Comunicación
6.2.1.1.2. Recolección de solicitudes
6.2.1.1.3. Estudio de viabilidad
6.2.1.1.4. Análisis del sistema
6.2.1.1.5. Diseño de Software
6.2.1.1.6. Codificación
6.2.1.1.7. Pruebas
6.2.1.1.8. Integración
6.2.1.1.9. Implementación
6.2.1.1.10. Mantenimiento y Funcionamiento
6.2.1.1.11. Disposición
7. Requerimientos de software
7.1. Se enfocan en
7.1.1. El análisis de requerimiento
7.1.1.1. Clasificación de requerimientos
7.1.1.2. Modelo conceptual
7.1.1.2.1. Desarrollados
7.1.1.2.2. Influenciados
7.1.2. La espicificación de requisitos
7.1.2.1. Especificación del sistema
7.1.2.2. Espeficicación del software
7.1.3. La validación de requerimientos
7.1.3.1. Elaboración de requisitos
7.1.3.2. Validación del modelo
7.1.3.3. Pruebas de aceptación
7.1.3.4. Importancia
7.1.4. Fundamentos de los requerimientos
7.1.4.1. Funcionales - no funcionales
7.1.4.2. Prioridad
7.1.4.3. Producto - proceso
7.1.4.4. Alcance
7.1.5. Consideraciones prácticas
7.1.5.1. Administración de cambio
7.1.5.2. Medición de requerimientos
7.1.6. Captura de requisitos
7.1.6.1. Fuente de requerimiento
7.1.6.1.1. Metas
7.1.6.1.2. Conocimiento de dominio
7.1.6.1.3. Ambiente operacional y organizacional
7.1.6.2. Técnicas de obtención
7.1.6.2.1. Entravistas
7.1.6.2.2. Prototipos
7.1.6.2.3. Reuiniones
7.1.7. Aspectos relevantes
7.1.7.1. Riesgos
7.1.7.2. Interrupciones
7.1.7.3. Vulnerabilidad
8. Gestión de riesgos
8.1. Se enfonca en
8.1.1. Estructuración para manejar la incertidumbrerelativa a una amenaza, a través de una secuencia deactividades humanas las cuales son:
8.1.1.1. Identificación de riesgos
8.1.1.2. Estimación de riesgos
8.1.1.3. Plan de riesgos
8.2. Aspectos relevantes
8.2.1. Riesgos del negocio
8.2.1.1. De mercado: desarrollar una producto que nadie quiere o necesita
8.2.1.2. Estratégico: desarrollar un producto que no encaja dentro del plan estratégico de la compañia
8.2.1.3. Desarrollar un producto que no saben como vender
8.2.1.4. Perder presupuesto o persona asignado
8.2.2. Riesgos técnicos
8.2.2.1. Se prsenta cuando el problema es mas dificil de resolver de lo esperado, amenazando calidad y el desarrollo del software hadciendo dificl la implementación
9. Estimación de esfuerzo
9.1. Se enfoca
9.1.1. Despertar en el público la conciencia sobre la problemática en la elaboración de estimaciones en el desarrollo de software
9.1.2. Presentar el concepto de unidad de producto y de cómo aplicarlo en la medición de software
9.1.3. Introducir el método de COSMIC para la medición del tamaño funcional y su papel en la generación de unidades de producto a partir de los requerimientos funcionales
9.2. Aspectos relebantes
9.2.1. Problemática de la estimación
9.2.1.1. Al inicio no sé sabe cuáles son todos los programas
9.2.1.2. Hay trabajos que no es una funcioón de esa cantidad de programas
9.2.1.3. El videl de estimación no permite usar la lógica de la estimación de abajo hacia arriba
9.2.2. Unidad de producto para la pordución de software
9.2.2.1. Tipos de requerimientos
9.2.2.1.1. No son requerimientos funcionales
9.2.2.1.2. Requerimientos funcionales