UNIVERSIDAD TECNOLÓGICA DE SANTIAGO (UTESA)
ASIGNATURA: Seminario Informático II
SECION: 001
TEMA: Formulación de proyecto
NOMBRE Y MATRICULA: Carlos Raynier Adames || 2-11-4559
PRESENTADO A: Prof. Neldo Ortega
SANTO DOMINGO, REP. DOM.
FECHA DE ENTRGA:
22-08-2020
Introducción y presentación de
la asignatura
Índice
• Introducción
• Objetivos
• Capacidades
• Temario
• Organización
• Metodología
• Evaluación
• Contactos y Página Web
• Bibliografía
Introducción
• Técnico
• Organizativo
• Económico y Administrativo
• Comercial
• Legal y Normativo
• Etc.
Objetivos
• Familiarizar al alumno en el trabajo como integrante de un grupo
• Concienciar al alumno de la importancia de la gestión de proyectos
software, hardware y de comunicaciones
• Conocer, analizar y potenciar los factores que influyen en el éxito de un
proyecto
• Conocer el papel y uso de los estándares de informática y de la
legislación que pueda afectar al desarrollo de sus proyectos
• Elegir y aplicar los modelos de desarrollo de proyectos de informática
existentes y que el alumno ha adquirido en otras asignaturas
• Planificar y gestionar temporalmente un proyecto de informática, con
asignación y gestión de recursos
• Establecer las medidas de seguimiento y control de un proyecto
• Estimar y medir proyectos software
• Identificar riesgos
• Establecer políticas de gestión y distribución de versiones
Temario
1.Introducción a los Proyectos de Informática
2.Medición de software
3.Modelos de Estimación
4.Organización de los Recursos Humanos
5.Formalización de Proyectos
6.Calidad de los Proyectos de Informática
7.Gestión de Riesgos
8.Planificación Temporal
9.Seguimiento y Control
10.Modelos de Desarrollo de Proyectos de Software Libre
Organización
Carpeta del Alumno (Contenidos) en formato electrónico (RTF, WORD,
otros formatos a negociar con los profesores)
• Hoja identificativa del alumno con nombre, email, DNI, etc.
• Informes personales de las discusiones en clase
• Informes que se soliciten
• Estimación previa de un proyecto
• Informe sobre la formación del equipo más adecuado para el
desarrollo del proyecto del grupo
• Informe sobre los sistemas de calidad. ¿Cuál es el más adecuado al
proyecto en de tu grupo?
• Definición de un Riesgo
• Informe personal de seguimiento de la planificación prevista
• Plantear un modelo de Proyecto de Sw. Libre
Metodología
• El alumno adquirirá en las clases de teoría los conocimientos y base
suficiente para conocer y comprender tanto los riesgos como las
técnicas asociadas a la gestión de proyectos de informática.
• En las clases de tablero se harán ejemplos prácticos de los temas
vistos en teoría, asimismo el alumno deberá ir preparando un trabajo
(Carpeta del Alumno) que entregará al final del curso y que estará
relacionado con la dirección y control de proyectos.
• El alumno se integrará en un grupo de prácticas y realizará un
proyecto que irá documentando en un entregable denominado
Carpeta del Grupo
• Durante el curso el alumno será requerido a leer, para discusión en
clase, artículos o temas relacionados con la gestión de proyectos y
con aspectos conflictivos o relacionados con ésta.
Evaluación
Dos tipos de Evaluación
• Evaluación continua
• Examen final
No se consideran “compensables” y será obligatorio superar el cinco en las
pruebas y exámenes
No se guardarán notas entre convocatorias
Si el alumno no se presenta a ninguno de…
• Examen final
• Presentación del Ejercicio (Carpeta del grupo)
• Carpeta del alumno (individual)
• Test
Será evaluado como No Presentado
Si se presenta a alguno de ellos será evaluado como Suspenso
Concepto de Proyecto
Conceptos ambiguos
• Proyecto, Ejecución, etc.
El proyecto se caracteriza por
• Concreción
• Objetivo definido
• Unicidad
• Responde a una demanda o necesidad puntual
• Dominio de Aplicación
• Versa sobre un dominio de aplicación concreto (Expertos de
dominio)
• Flexibilidad
Fases de los Proyectos
Especificación de Proyecto
• Definición estándar encaminada a describir cómo se ha de ejecutar el
proyecto
Ejecución del Proyecto
• Desarrollo del proyecto para conseguir el producto con los criterios
acordados
Gestión de Proyectos
• Iniciación del Proyecto
• Calificación del Proyecto
• Desarrollo del Proyecto
• Cierre del Proyecto
• Proyecto de Informática ≠ Proyecto Software
Tipo de Proyectos Informáticos
• Software
• Hardware
• Comunicaciones y Redes
• Instalaciones de Hardware
• Sistemas de Misión Crítica
• Auditorías
• Peritajes
• Consultoría y Asesoría
• Seguridad Informática (ISO 17799)
• Reingeniería de Proyectos
Complejidad del desarrollo de
Proyectos de Informática
• Un Proyecto de Informática comprenderá uno o varios de los
Tipos de Proyectos anteriores
• Complejidad por las características de cada tipo de Proyecto y
de su combinación
Complejidad especial de los Proyectos de Software
• Interpretación de las especificaciones del cliente
• Fabricación usando elementos de muy bajo nivel (Lenguajes de Programación)
• Complejidad de adaptación de software vertical
Proyectos de Desarrollo de Software
• Crisis del Software
• Metodologías de Desarrollo
• RUP, Ágiles, etc.
• Paradigmas
• Estructurado, OOP, Funcional, 4GL, MDA, etc.
• Concepto del Ciclo de Vida de las Aplicaciones software
Modelo en cascada
• No refleja realmente el proceso de desarrollo del software
• Se tarda mucho tiempo en pasar por todo el ciclo
• Perpetúa el fracaso de la industria del software en su comunicación
con el usuario final
• El mantenimiento se realiza en el código fuente
• Las revisiones de proyectos de gran complejidad son muy difíciles
• Impone una estructura de gestión de proyectos
Modelo de Prototipos
Obtención de modelos de escala reducida Los modelos se validan por el
usuario
Desventaja: Se tiende a reutilizar el prototipo y se le colocan “parches”
Se divide en dos fases:
• Fase A: Diseño, construcción y evaluación de prototipos
• Fase B: Diseño, desarrollo, pruebas e integración
Modelo en espiral
Planificación: determinación de objetivos, alternativas y restricciones.
Análisis de riesgo: análisis de alternativas e identificación / resolución
de riesgos.
Ingeniería: desarrollo del producto del "siguiente nivel",
Evaluación del cliente: Valorización de los resultados de la ingeniería.
Modelos Ágiles
Estas son basadas en la adaptabilidad, más que en el carácter predictivo
Son más orientadas a las personas que a los procesos
Para entender mejor los fundamentos de las metodologías ágiles para el
desarrollo de software es conveniente revisar un poco la naturaleza de
esta actividad
• El diseño especifica las piezas y como ellas se relacionan
• El diseño es la base del plan de construcción
• El plan define tareas y dependencia entre tareas. Permite
definir la agenda y el presupuesto de construcción
• El diseño requiere de gente más preparada, creativa y
costosa. La construcción de gente menos preparada y
costosa
• Un buen diseño establece una forma directa y planificada
de construir la aplicación
Iteraciones y Ciclos
Actividades
Actividades
fundamentales Inicio Elaboración Construcción Transición
Requisitos
Análisis
Diseño
Implementación
Prueba
Iter #1 Iter #2 --- --- --- --- --- --- Iter #n- 1 Iter
Organización matricial
El jefe de Proyecto
Situación
Funciones
• Colaboración con el cliente en la definición y concreción de los objetivos del
proyecto.
• Planificación del proyecto en todos sus aspectos, identificando las actividades
a realizar, los recursos a poner en juego, los plazos y los costes previstos.
• Dirección y coordinación de todos los recursos empleados en el proyecto.
• Mantenimiento permanente de las relaciones externas del proyecto:
clientes, proveedores, subcontratistas, otras direcciones, etc.
• Toma de decisiones necesarias para conocer en todo momento la situación en
relación con los objetivos establecidos.
• Adopción de las medidas correctoras pertinentes para poner remedio a las
desviaciones que se hubieran detectado.
• Responder ante clientes y superiores de la consecución de los objetivos del
proyecto.
• Proponer, en su caso, modificaciones a los límites u objetivos básicos del
proyecto cuando concurran circunstancias que así lo aconsejen.
Recursos Financieros
Reagrupamiento de tareas: tarea hamaca
• Definida por: un conjunto de tareas detalladas
• Carga: suma de cargas de sus componentes
• Comienzo: la menor de las fechas de comienzo
• Fin: la más tardía de sus componentes
No supone ninguna economía de realización tan solo de
representación
WBS – Ejemplo
• Proyecto: tres subsistemas. El 1 y el 3 subcontratados
a terceros y el subsistema 2 descompuesto en tres
módulos
WBS del proyecto
WBS/PBS del proyecto ejemplo (nivel de detalle).
La representación elipses/rectángulos hace aparecer
un producto nuevo: el cuaderno de cargas del sistema
WBS/PBS detallado del subsistema 2 aparece un
nuevo producto suplementario: cuaderno de cargas
del SS2
La estructura en árbol del WBS induce un mecanismo
de herencia de las relaciones de dependencia:
El Proyecto debe constar de los
siguientes documentos básicos:
• Índice General
• Memoria,
• Requisitos del Sistema
• Anexos
• Diseño del Sistema
• Estimación de Tamaño y Esfuerzos
• Planes de Gestión de la Ejecución del Proyecto
• Gestión del alcance del proyecto.
• Gestión de plazos del proyecto.
• Gestión de costes del proyecto.
• Gestión de la calidad del proyecto.
• Gestión de recursos humanos del proyecto.
• Gestión de comunicaciones del proyecto.
• Gestión de riesgos del proyecto.
• Gestión de adquisiciones del proyecto.
• Seguridad
• Presupuesto
• Estudios con Entidad Propia, cuando proceda
Contenidos de la Memoria
• M1 Introducción
• M2 Objeto
• M3 Antecedentes
• M4 Descripción de la situación actual
• M5 Normas y referencias
• M5.1 Disposiciones legales y normas aplicadas
• M5.2 Bibliografía
• M5.3 Métodos, Herramientas, Modelos, Métricas y Prototipos
• M5.4 Plan de gestión de la calidad aplicado durante la redacción del
Proyecto
• M5.5 Otras referencias
• M6 Definiciones y abreviaturas
• M7 Requisitos iniciales
• M8 Alcance
Requisitos del sistema
• Funcionalidad y transformación de entradas en salidas
• Rendimiento. Especificación de cada requisito de rendimiento de forma
comprobable y cuantitativamente. Aspectos que deberían reflejarse.
• Atributos de calidad. Usabilidad, eficiencia, factibilidad, mantenibilidad, y
portabilidad.
• Restricciones de diseño e implementación. Restricciones impuestas
externamente (estándares, departamento de marketing,..), limitaciones
de hardware (compiladores, memoria,..), y requisitos de proyecto
(características de seguridad).
• Requisitos externos.
• Requisitos de seguridad física.
• Requisitos de seguridad lógica. Requisitos prioritarios. Pueden ser
identificados por análisis de riesgos.
• Documentación de usuario. Descripción de requisitos referentes a
contenidos.
• Especificación de la interacción hombre-máquina. Descripción de requisitos
para una apropiada interacción, sistemas automáticos.
ANEXOS
• Documentación de entrada
• Catálogos de los elementos constitutivos del objeto del
Proyecto
• Listados
• Información en soportes lógicos, magnéticos, ópticos u
otros
• Otros documentos que se juzguen necesarios
Presupuesto
• Determinación del coste de cada item del proyecto
• Determinación de los costes acumulados de cada parte del proyecto
• Determinación del coste total del proyecto
• La Calidad del Diseño se corresponde con la
proporción de necesidades del usuario que son
cubiertas por el diseño realizado.
ISO 9000-2000
Gestión de la Calidad
• Gestión del alcance del proyecto
• Gestión de plazos del proyecto
• Gestión de costes del proyecto
• Gestión de la calidad del proyecto
• Gestión de recursos humanos del proyecto
• Gestión de comunicaciones del proyecto
• Gestión de riesgos del proyecto
• Gestión de adquisiciones del proyecto
• Gestión de la configuración
Gestión
Conclusiones
Los riesgos son un factor más a tener en cuenta en la gestión de
proyectos
Están determinados por todos los elementos (factores) que
afectan al proyecto y que pueden provocar situaciones adversas
Para gestionar bien los riesgos hay que establecer un Plan de
Riesgos
Los riesgos son vivos y se debe definir el modo de adaptar
permanentemente el Plan de riesgos
Para gestionar los riesgos es importante definir una metodología
de trabajo y contar con herramientas de gestión de riesgos
