UNIVERSIDAD TECNOLÓGICA DE NEZAHUALCOYOTL TECNOLOGÍAS DE LA COMUNICACIÓN E INFORMACION ADMINISTRACIÓN DE PROYECTOS DE TI I.

Slides:



Advertisements
Presentaciones similares
Ciclo de Vida de Desarrollo de los Sistemas de Información
Advertisements

ingeniería de software
MÉTODOS DE ESTIMACIÓN Y GESTIÓN DEL RIESGO
2.3 Modelo de Capacidad de Madurez Integrado (CMMI®)
CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN
Ing. Francisco Rodríguez Novoa
PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
ANÁLISIS DE REQUERIMIENTOS
DISEÑO ORIENTADO AL OBJETO
Objetivos Desarrollar software funcional multi-modelo sobre distintas plataformas para el estudio de sistemas complejos de cómputo de alto rendimiento.
MaNuaL APQP CAPITULO 1 EQUIPO # 1 Lucero Honorina Alderete Loera
2. Diseño y Desarrollo del Producto
Herramientas Automáticas de Estimación
METRICAS DE PROCESO Y PROYECTO
Fundamentos de la Gestión de Proyectos
Tipos de Métricas.
Métricas en Proyectos de Software Prof. A/S: Diego Gutiérrez Gerenciamiento y Dirección de TI.
Presentación a la directora del proyecto Friend-Buster (Caza-Amigos) – PIS 2010.
Modelos de Proceso del Software
M.S.C. Ivette Hernández Dávila
Ingeniería del software de la usabilidad (I)
Contenido de un proyecto ejecutivo
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
Universidad Rey Juan Carlos
Fase Inicial Grupo 6 – PIS – 2013.
Evaluación de sistemas de cómputo
Unidad 4 Diseño Arquitectónico Basado en la Funcionalidad
Las etapas de un proyecto
Ciclo de Vida del Software Paradigmas de Desarrollo
Riesgos en Proyectos Informáticos
Métricas de calidad de software
Medición y Métricas del Software
Organización y Estructuración de Datos
Conceptos de Gestión y Planificación de Proyectos Software
Estimaciones de Proyecto ISF5501 Ingeniería de Software Semana 8.
Modelos Empíricos de Estimación
1 Riesgos en Proyectos Informáticos Objetivo: Identificar principales causales de riesgo de proyectos Luis Hevia.
Tema 4 Existencias Diapositivas empleadas por Manuel García-Ayuso Covarsí en las sesiones destinadas a la discusión de los contenidos teóricos del Tema.
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
INGENIERÍA DE SOFTWARE
Tema 1: Introducción a la Ingeniería de Software
Construcción de Software
Modelo en Cascada Planeación Estratégica Estudio de Factibilidad
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
Técnicas de Estimación de Esfuerzo
Saber que cambiar y como hacer que el cambio finalmente ocurra será fuente de ventajas competitivas para la compañía. La totalidad de presentaciones y.
Ámbito y Estimaciones de Proyecto ISF5501 Ingeniería de Software Semana 7/1.
Ámbito y Estimaciones de Proyecto
La Calidad y los Costos.  Conjunto de cualidades y características que constituyen la escencia de un producto y respaldan el grado de beneficio proporcionado.
INGENIERÍA DEL SOFTWARE GESTIÓN DE PROYECTOS
Medición y Métricas del Software
Introducción a las Ingenierías de la Información
Diseño de Sistemas.
Ciclo de vida de un sistema
Definición de sistema__________
Métricas de calidad de software
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Relación con otras asignaturas del plan de estudio
Estimación de proyectos de software
Especialidad en Administración de Proyectos
Modelo Prescriptivos de proceso
Gestión de proyectos fin de carrera
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Actividad 12. Estimación en los proyectos de software. M.C. Juan Carlos Olivares Rojas Syllabus May, 2009.
Semestre VIII – Lapso Académico Ingeniería en Informática.
Fundamentos de Computación
1 ESTIMACIÓN basada en PUNTOS de FUNCIÓN. 2 Agenda de la presentación 4 Técnicas de estimación. 4 Puntos de Función. (En general) 4 Puntos de Función.
RAPID APPLICATION DEVELOPMENT RAD. Proceso de RAD Involucrar en todos los aspectos al usuario en el desarrollo del sistema Uso continuo y repetitivo de.
El diseño de la interfaz de usuario requiere el estudio de las personas y el conocimiento tecnológico adecuado.
Verificación y Validación del Software
Transcripción de la presentación:

UNIVERSIDAD TECNOLÓGICA DE NEZAHUALCOYOTL TECNOLOGÍAS DE LA COMUNICACIÓN E INFORMACION ADMINISTRACIÓN DE PROYECTOS DE TI I

La Administración de Proyectos inicia con un conjunto de actividades que de manera colectiva se denominan planificación del proyecto, la cual incluye: 1) Estimar el trabajo que se realizará1) Estimar el trabajo que se realizará 2) Establecer de principio a fin el tiempo que se invertirá2) Establecer de principio a fin el tiempo que se invertirá 3) Identificar la prioridad de las tareas y definir a su responsable 4) Calcular los recursos que se requerirán4) Calcular los recursos que se requerirán 5) Vislumbrar los posibles cambios que ocurrirán5) Vislumbrar los posibles cambios que ocurrirán

Un trabajador técnico evitará a toda costa la planificación, sin embargo la planificación corriente arriba [inicio del proyecto] es barata, mientras que corriente abajo [fin del proyecto] es cara. Los proyectos promedio emplean 80% de su tiempo en poner a punto el sistema una vez que este termino, demeritando la $utilidad$ planteada inicialmente. La ley de Murphy: «Lo que puede salir mal, saldrá mal» y «Si hay cosas que pueden fallar, más cosas fallarán»

Determinar los co$tos es parte del estudio de factibilidad* incluyendo: 1) Retrasar la estimación hasta avanzado el proyecto 2) Calcule con base en experiencias pasadas 3) Usar técnicas de descomposición 4) Usar uno o más modelos empíricos para estimar costos y esfuerzos *La factibilidad posee cuatro dimensiones: Tecnológica (existe la tecnología para su desarrollo). Financiera (la organización, el cliente o el mercado puede pagar). Tiempo (¿nuestra velocidad vencerá a la competencia?). Recursos (¿Contamos con los recursos para terminar el proyecto?)

 COCOMO II es en realidad una jerarquía de modelos de estimación que aborda las siguientes áreas:  Modelo de composición de la aplicación  Modelo de composición de la aplicación: se usa durante las primeras etapas de la ingeniería del SW, cuando es necesario elaborar prototipos, interfaces de usuario, valoración del rendimiento y evaluación de la madurez tecnológica  Modelo de etapa temprana de diseño  Modelo de etapa temprana de diseño: se utiliza una vez que los requisitos y la arquitectura básica de SW fueron establecidos.  Modelo de etapa postarquitectónica  Modelo de etapa postarquitectónica: se usa durante la construcción del SW.  COCOMO II, calcula tres opciones de dimensionamiento: a) Puntos de objeto, b) Puntos de Función y c) Líneas de código fuente

puntos de objeto  Este modelo utiliza puntos de objeto, la cual es una medida indirecta que se calcula contabilizando: 1) Número de pantallas (interfaz de usuario), 2) Reportes y 3) Componentes para construir la aplicación.  Cada instancia de objeto (pantalla o reporte) posee un nivel de complejidad; simple, medio o difícil.  El nivel de complejidad se refiere al numero y la fuente de donde se están tomando los datos para generar la pantalla o el reporte 1.  También implica lo laborioso de la pantalla o reporte que se genere 2. 1 No es lo mismo una base de datos centralizada, distribuida, heterogénea o en cloud computing 2 No es lo mismo una pantalla para una factura que la modificación de un registro

 El nivel de complejidad se calcula conforme al numero de vistas a generar y el total de tablas que se utilizan como fuente de datos

 Estas dos opciones determinan el numero de secciones que el reporte contendrá en función de el origen de datos.  Finalmente se concluye con un concentrado de los tipos de objetos y su grado de complejidad