Proyectos de software
1 recomendación4,157 vistas
Un proyecto tiene un inicio y fin, busca un objetivo. Tiene dos fases: formulación y gestión. Se compone de áreas y debe tener un cierre. Todo proyecto se organiza en torno a tres dimensiones: calidad, tiempo y dinero. Los proyectos nacen de necesidades y están compuestos por acciones con ingeniería presente en sus dos fases.
Proyectos de software
- 1. Un proyecto es un conjunto de acciones que tienen un inicio y un fin y buscan un objetivo.- Formulación○ Gestión○ Las Áreas de un proyecto son dos:- Proyecto vs Producto I F Proyecto Producto Todo Proyecto debe tener un cierre.- Dentro del proyecto puede haber pruebas locales.- Los proyectos nacen de las necesidades de una empresa, un persona, una entidad.- Todo Proyecto tiene 3 dimensiones- Calidad DineroTiempo Conceptual○ Construcción○ Todo Proyecto tiene dos Fases o Etapas, en las cuales la ingeniería esta presente:- Un proyecto de ingeniería esta para solucionar problemas- El Plan de Gestión de Proyectos no es un simple plan, sino es un conjunto de planes (planes subsidiarios) - Proyectos de Software martes, 25 de octubre de 2011 17:40 Proyectos de Software página 1
- 2. Base line = punto de partida = punto de referencia Sirve para comparara el avance Pueden ser orientados a la Calidad, tiempo y costo El de calidad es mas desmenuzado pues hay que ver las especificaciones. Recorte de pantalla realizado: 04/10/2011 20:40 Vista de Implementación Diagrama de Secuencia• Diagrama de estados• Diagrama de Colaboración• Pegado de <http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational> Modelo de Implementación Código fuente, ejecutables, bases de datos, otros. Project martes, 04 de octubre de 2011 20:35 Proyectos de Software página 2
- 3. La metodología PMP Propone 5 procesos los cuales los podemos observar en la siguiente gráfica: - La Institución que desarrolló la metodología PMP es PMI (Project Management Institution)- Realizan procesos repetitivos General Manager□ Production Manager□ Es controlada por: Matriciales○ Viven de Proyectos General Manager□ Project Manager□ Es controlada por Programas (conjunto de proyectos afines)□ Portafolios ( conjunto de proyectos realizados; no necesariamente afines)□ Proyectos□ Se organizan por Orientada a Proyectos○ Para el estudio de esta metodología se clasifican a las empresas en:- Se encuentra en el PMBOK (Project Manager Book Of Knowledge)- La metodología PMP es el resultado de un conjunto de sub-planificaciones- Metodología PMP (Project Management Profesional) martes, 25 de octubre de 2011 17:55 Proyectos de Software página 3
- 4. Datos (fecha, sponsor, manager name, lugar)○ Problema (situación Actual)○ Objetivos (respuesta positiva al problema)○ Hitos (Son los entregables del proyecto deben contener las fecha de entrega de los mismos)○ Es un documento que contiene las siguientes secciones:- Autorizar el inicio del proyecto○ Negociar los términos globales del proyecto○ Direccionar○ El Project Charter sirve para- El desarrollo del Project Charter puede ser desarrollado sin la presencia de un gerente- Plan de Negocio Idea del Negocio Estudio de la factibilidad Business Case (Plan de Negocio)○ Contract (Optional *)○ Lo que Quiere el cliente Si tiene detalle es un pliego de requisitos Si no tiene detalle son los requisitos iniciales Project Statement of Work○ Cultura Ambiente de la Empresa Enterprise Enviromental Factors○ Funcionamiento de la empresa Procesos de la Empresa Organization Process Assets○ Entradas del Project Charter- La salida de las entradas anteriores da como resultado el Project Charter- Para la Creación del mismo es necesario de Expert Judgments- Project Title:○ Project Sponsor (auspiciante)○ Date Prepared○ Project Manager○ Project Customer○ Project Purpose or Justification○ Project Description○ Project and Product Requirments○ Acceptance Criteria (Criterio bajo el cual será evaluado el proyecto; Ejemplo: Interfaz)○ Initial Risks○ Project Objetives○ Project Objetives Success Criteria Person Approving Proces Benefits Requeriments Estimated Budget○ Staffing Decisions Budget Management and Variance (Presupuesto y varianzas que puede dar el proyecto) Technical Decision (Quien(s) pueden tomar las decisiones técnicas) Conflict Resolution (Como se van a resolver los problemas cuando son internos pueden tratarse con reglamentos y mediadores; cuando son externos pueden tratarse con Leyes, Contrato,y Mediador) Escalation Path for Authority Limitations (Jerarquía de Jefes) Approvals Project Manager Authority Level○ Firmas de Responsabilidad○ Partes del Project Charter- Cuando el cliente da la lógica del Negocio el software es del cliente Todo Proyecto funciona con gente Multidiciplinaria Project Charter martes, 25 de octubre de 2011 18:10 Proyectos de Software página 4
- 5. Collect Requirements○ Funcional Arquitectura PBS puede tener dos enfoques:□ Partes (Funcionalidad Gruesa o Grande) Componentes ( Funcionalidades Finas) PBS es un organigrama compuesto por□ Es orientado al Producto□ La Herramienta es el PBS (Product Breackdown Structure) Define Scope○ Los pasos de la planificación son:- Recorte de pantalla realizado: 25/10/2011 19:13 Es orientado al proyecto No es el Cronograma Permite Delegar Funciones Permite definir equipos Permite subcontratar Permite contratar el personal WBS (Work Breakdown Structure)○ Recorte de pantalla realizado: 25/10/2011 19:13 Paquetes de trabajo□ Estructura de trabajo□ Tiempo□ Finish to start Start to start Finish to finish Secuencia de Tareas Predecesoras Concadenadas□ Formado por Cronograma○ El requerimiento es una necesidad Las especificaciones es la parte técnica Requerimientos y especificaciones aportan a la calidad Planificación martes, 25 de octubre de 2011 18:58 Proyectos de Software página 5
- 6. Son aquellas entidades que afectan o se ven afectados de forma directa o indirecta al proyecto.○ Skateholder Register Project Title: Date Prepared: Name Positio n Role Contact Informatio n Require ments Expectations Influen ce Classific ation Ing. Glenda Toala Directiv o Directora de la Carrera de Ingeniería de Sistemas gtoala@ups. edu.ec Que el proyecto integre a las 2 materias. Identificar los Involucrados• Identificar los Intereses• Los pasos para la gestión de involucrados son:• Cuando se trata con conglomerados es preferible tratar con los gremios (asociaciones) Cuando el gremio no tiene fuerza se puede acudir a los caudillos Stakeholders (Involucrados) viernes, 04 de noviembre de 2011 17:58 Proyectos de Software página 6
- 7. Todo proyecto genera riesgos, los mismos que con una previa planificación y análisis se pueden reducir su impacto y hasta eliminar el impacto de los mismo en el proyecto. Planificar la gestión○ Ejemplo: Arquitectura no compatible, Herramientas desconocidas□ Tecnología Competencias Comportamiento Gente□ Políticas de la Organización□ Infraestructura Física□ Ambiente interno Competencia□ Leyes□ Mercado Laboral□ Vientos Tornados Inundaciones Naturaleza□ Ambiente Externo Identificar los riesgos○ Análisis Cualitativo○ Análisis Cuantitativo○ Actividades Respuesta○ Monitorear Actividades vs Riesgos○ Las actividades para la planificación de riesgo son:• Mitigar○ Aceptar○ Transferir○ Frente a los riesgos se puede• Se sabe que existen pero no se sabe si se da Cuando se los mitiga afecta al presupuesto y al cronograma Conocidos-Desconocidos○ No se tiene conocimiento de cómo, cuándo ni en donde puede pasar. Cuando se los mitiga afecta a un porcentaje del presupuesto Se miden en probabilidades % Desconocidos-Desconocidos○ Tipos de Riesgos• Cuando se ACEPTA un riesgo se afecta al gasto (Ejercicio en Ejecución)• Risk (Riesgos) viernes, 04 de noviembre de 2011 18:02 Proyectos de Software página 7
- 8. Se lo ejecuta antes de la realización del proyecto.- Se define el Plan de Recursos Humanos (HRP)- WBS Cronograma PSW (Project Statement of Work | lo que quiere el cliente) Contrato Las entradas son- Funciones Cargos Capacidad de trabajar bajo presión Genéricas◊ Administración de usuarios en Linux Especificas◊ Pueden ser: Competencias (hacer)□ Formación/Educación (cursos)□ Experiencia (años)□ Perfiles El resultado es:- Planificación del Personal1. Gestión del Personal2. Se lo ejecuta cuando inicia el proyecto Existen dos momento Continuos- Parciales- Eventuales- Tiempo- Parcial- Completo- Jornal- Contratos- Cuando se planifica es necesario tener en cuenta dos factores Define autoridades y competencias- Roles + Responsabilidades (Contesta el qué?)1. Adquisición- Plan de Liberación del Personal (Cronograma)- Competencias vs tiempo Necesidades de capacitación- Reconocimiento -> Cursos Recompensas -> Dar algo a cambio Plan de Reconocimientos y Recompensas- Iess decimos Cumplimiento (Normas Legales)- Movilización Seguridad- Plan de Dirección de Personal (Contesta el cómo?)2. PLAN DE RECURSOS HUMANOS Organigrama1. Matriz de Asignación de responsabilidadesa. Matrices2. HERRAMIENTAS PARA PRH Metodología del Talento Humano viernes, 04 de noviembre de 2011 18:35 Proyectos de Software página 8
- 9. El plan de calidad permite aprobar el control de la calidad, pues el mismo da los parámetros necesarios para medir la Calidad. - ITIL○ UP○ COBIT○ RUB○ ISO 9000 son fundamentos, no existe certificación de esta norma ISO○ Existen buenas prácticas- Check List○ Metricas○ Process Improvemt (Good Practices | Mejoramiento)○ Componentes del Plan de la Gestión de la Calidad- Quality Plan○ Quality Assurance○ Quality Control○ Procesos para llegar a la Calidad- Gestión de la Calidad viernes, 04 de noviembre de 2011 19:17 Proyectos de Software página 9
- 10. Gestión del cronograma Perlt martes, 08 de noviembre de 2011 20:09 Proyectos de Software página 10
- 11. Recorte de pantalla realizado: 15/11/2011 15:23 Recorte de pantalla realizado: 15/11/2011 15:24 Recorte de pantalla realizado: 15/11/2011 15:25 Gestión de Costes martes, 15 de noviembre de 2011 15:23 Proyectos de Software página 11
- 12. Recorte de pantalla realizado: 15/11/2011 15:25 Recorte de pantalla realizado: 15/11/2011 15:26 Recorte de pantalla realizado: 15/11/2011 15:26 Recorte de pantalla realizado: 15/11/2011 15:27 Proyectos de Software página 12
- 13. Recorte de pantalla realizado: 15/11/2011 15:27 Proyectos de Software página 13
- 14. UP (RUP)○ XP○ SCRUM○ MSF○ OOHDM○ Entre las principales metodologías tenemos:- Metodologías para el Desarrollo de SW martes, 13 de diciembre de 2011 20:00 Proyectos de Software página 14
- 15. No es una metodología- Es un lenguaje- Es una notación de modelado- www.omg.org- UML lunes, 19 de diciembre de 2011 19:11 Proyectos de Software página 15
- 16. Todo lo que es tangible se lo realiza en Cascada- El SW debe ser incremental e iterativo- Incremental significa que en el transcurso del proyecto se generan hitos llamados incrementos - Incremento n Incremento .. Incremento 3 Incremento 2 Incremento 1 Incremento 0 Iterativo significa que los procesos ser repiten- Mejor Seguimiento de Procesos○ Es mas barato○ Se tiene bien claro lo que se necesita○ Se lo denomina modelo de ingeniería por excelencia Cascada Características- Incremento n A - D - C -P - I Incremento .. A - D - C -P - I Incremento 3 A - D - C -P - I Incremento 2 A - D - C -P - I Incremento 1 A - D - C -P - I Incremento 0 A - D - C -P - I Modelo de Fases martes, 13 de diciembre de 2011 20:02 Proyectos de Software página 16
- 17. Se lo denomina modelo de ingeniería por excelencia○ Se lo usa en todo tipo de ingeniería pues es el más ideal y más controlado○ Se lo realiza cuando no se tiene bien claro lo que se desea○ Espiral- Iteración = vuelta○ ¿Qué debe hacer?□ Funcionales Cómo?□ No funcionales Existen dos tipos de requerimientos○ Es el mas usado en ingeniería de software y es el más controlado○ Modelo incremental- Proyectos de Software página 17
- 18. Unifite Process- Es libre su versión privativa es RUP, misma que es de Rational- UP + UML dan como resultado patrones- Un patrón es una forma predeterminada para usar uml, adaptada al UP- UP recomienda que cada iteración dure 4 semanas- Cada iteración es panificable- Existe un Plan de iteración- Los entregables se denominan Artefactos (SW - Documentos - Productos)- Los paquetes de trabajo se denominan Disciplinas- Inicio1. Elaboración2. Construcción3. Transición => pruebas4. FASES DE UP- Modelado de Negocio○ Requerimientos○ Análisis y Diseño○ Implementación○ Pruebas de Despliegue○ Configuración y manejo de Cambios○ Gestión del Proyecto○ Gestión del Ambiente (Involucrados)○ DISCIPLINAS DE UP- Plan de Desarrollo- Plan de Iteraciones- Creación○ Refinamiento ( Corregir y crecer)○ TODO ARTEFACTO TIENE DOS MOMENTOS- Todo documento tiene una versión con su historial de versionamiento, mismo que es administrado por el Oficial de Configuración - Fecha Responsable Versión Portada○ Historial de Versionamiento○ Indice○ Todo Documento tiene:- Es el primer entregable□ No es una especificación□ Project Chartes y PBS de Alto nivel□ Visión del sistema Tiene un PBS WBS y cronograma por cada iteración□ requerimientos Plan de Riesgos Plan de calidad Plan de costos Cronograma Tiene :□ Plan de Iteración Inicio○ Modelo de Negocio Diagrama de clases simple - diagrama de procesos - casos de uso del negocio Documento de Análisis (Modelo de Análisis) Diagrama de Casos de Uso Documento de Diseño (Modelo de Diseño) Diagrama de Actividad - Diagrama de Secuencia - Diagrama de Clases Modelo de Implementación Diagrama de Despliegue Reglas de negocio (Decisiones parámetros) Lógica del negocio (Como proceso) Ser divide en dos□ Modelo de negocio Modelo de Negocio Elaboración○ Artefactos posibles:- Requisitos- Modelo de negocio (Como funciona la empresa)- El SW sea de bueno debe tener como entradas: Escalabilidad (evoluciona)- Parametrizable (reglas del negocio editables)- El sistema ideal Esencia de la metodología- REALIZACIÓN DE CASOS DE USO UP martes, 13 de diciembre de 2011 20:07 Proyectos de Software página 18
- 19. Modelo de negocio Es una primera aproximación al modelo de Diseño.□ Permite entender un poco como es el sistema en el negocio.□ Lo que debe hacer el sistema en el negocio.□ Si se puede que dar en este modelo.□ La profundidad depende del team de trabajo□ A mayor modelado mejor SW□ Especificación de Requerimientos (Funcionales y no Funcionales)◊ Modelo de Negocio◊ Lo alimenta de: Es recomendable usar escenarios , ya que los mismos pueden ser módulos Las acciones derivan en métodos Realización de Casos de Usos del Sistema□ Modelo de Análisis Encargado de refinar el modelo de análisis□ Valida resultados de modelos de Requisitos y análisis□ Los patrones de diseño se usan para dar reusabilidad, extensibilidad y robustez□ Modelo=>datos Visuales Controladores) Vista (Cjto de objetos Responde a eventos◊ Controlador Patron MVC (Modelo Vista Patron) construir esl SW□ Modelo de Diseño Proyectos de Software página 19
- 20. Visual - Gráfica○ Diagrama de Casos de Uso- Funcionalidad○ Casos de Uso- Nombre Descripción Actores Pre-condiciones Post-condiciones Flujo principal Flujo alternatico Requerimientos Tecnológicos y Requerimientos escpeciales Contiene○ Descripción de Casos de Uso- Digrama BPMN- Permite una visualización del negocio○ Una manera integral del negocio○ BPMN- MODELO DE ANÁLISIS- Diagramas estáticos describen estructura- arquitectura como están los componentes (ejemplo diagrama de clases) - Diagrama dinámicos describe comportamiento que hacer?? (ejemplo diagrama de actividades) - Diagramas de iteración describe como interactúa los componentes con ese comportamiento (diagrama de secuencia) - El usuario interactúa con una clase a través de métodos Diagramas lunes, 19 de diciembre de 2011 20:49 Proyectos de Software página 20
- 21. Conceptual (creación virtual)○ Construcción (creación "tangible")○ Todo proceso de ingeniería tiene dos etapas:- Se modela de acuerdo a la profundidad de acuerdo al jefe de proyecto○ Modelar es una buena práctica- Luego se puede simular- Permite una visualización del negocio○ Una manera integral del negocio○ BPMN- Lógica del negocio (Proceso, Cómo?)○ Reglas del Negocio (condiciones)○ El modelo de negocio tiene dos elementos- Diagrama de procesos mas fuerte que Dominios y casos de usos- Si es sincronico interoperabilidad- Si es asincronico barrido datos- Ingeniería lunes, 19 de diciembre de 2011 19:39 Proyectos de Software página 21
- 22. Framework para un completo desarrollo de productos y sistemas- Es iterativa e incremental- Al iniciar la metodología el equipo revisa los requerimientos versus las tics disponibles.- Existen reuniones constantes para tratar temas de avances del proyecto.- El SW es complicado, la metodología debe ser simple, mas la documentación puede set compleja. - Respesenta la voz el cliente Finacia el proyecto Launch project Product Owner○ Suelen ser de 5 a 9 personas que se encargan del trabajo del proyecto que tienen diferentes skills Ejemplo: Analista, diseñador, desarrollador, Tester, comunicador técnico, documentador,…. Team○ El que lidera la metodología (no necesariamente el proyecto) ScrumMaster○ Roles de SCRUM SCRUM martes, 10 de enero de 2012 20:37 Proyectos de Software página 22
- 23. Principios fundamentales Metologia escalable y permite extenders, asi por ejemplo pueden haber grupos de 3 o4 hasta de 50 persons Flexible- Adaptable- Escalable- Technology agnostic cualquier tipo de metodologia- Caracteristicas Preparación de planes de trabajo ejmplo WBS, Risk Plan○ Estrategia y alcance(SCOPE PBS)- El plano para la elaboracion de un casa○ Planeacion y testeo del concepto- Pilotaje de las pruebas en el medio ambiente○ Develop Deployment plan (Despliege poner en marcha)○ Estabilización- Deployment- Stages Ver los pasos para la administracion de procesos MSF Riesgos Identify- Analizar yprioridades- Plan y Shedule- Track y report- Control- learn- Steps paln risks Permiten definir evaluar y estimar Conocimieto abilidades y skill KSA Disponibilidad de Administración Fases deol proces de msf Deploy complete Viscion Entre las metodologías cambia la forma de ejecución es decir el modelo de gestión Esta metodología considera un proceso de aprendizaje. Crecimiento del equipo Incremental- Iterative- Flexible- Risk Management- Escalable (Metogologia y SW)- Understant el buissnes model- Involve the client (Mayoria)- Knowledge database (store knowledge)- Quality (good practices, involve with client, good definition of scope, continius testing) - Technology agnostic- - Factors for a good SW methodology Metodología MSF lunes, 23 de enero de 2012 19:45 Proyectos de Software página 23
- 24. Metodologia para el desarrollo de software educacional El proposito es crear un sw creativo Es necesario que el team este formado de manera multidisciplinaria Es necesario tener las características de los usuarios y de su nivel de competencia Al realizar SW educativo se diseñan interfaces y ambientes __________________________________________________________________________________ ________________ Project and product could be sold DESED martes, 24 de enero de 2012 20:13 Proyectos de Software página 24
- 25. SUM is a methology to develop video games, basada en SCRUM Teams are multidisciplinary, it is between 3 and 7 It´s a flexible methodology Games adapt to structure abd rikes A difernecia de Scrum esta metodología usa grupos con subroles Concepto• Administrativa○ Del Juego○ Planeación• Preparación• Verificación○ Correcion○ Beta• Liberación○ Evaluación○ Cierre• Las faces son En el desarrollo de games no ha modelo de negocio pues se basa en conceptos, ideas, caracteristicas. Mecanismos de Interacción, Historia, Características y Escenarios son los principales aspectos para considerar en un game. Video Game Methodology lunes, 30 de enero de 2012 19:58 Proyectos de Software página 25