Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

LAS 4P DE LA GESTION DE PROYECTOS DE SOFTWARE

No description
by

Simon Ariza

on 1 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of LAS 4P DE LA GESTION DE PROYECTOS DE SOFTWARE

LAS 4P DE LA GESTIÓN DE PROYECTOS DE SOFTWARE
PROCESO
marco de trabajo
establecer el plan detallado para el desarrollo de software
simplemente un método construido a partir de una metodología
una forma de hacer las cosas
Según Pressman en Ingeniería de Software
Definición dada por Booch, Jacobson, Rumbaugh (UML developers)
un proceso tiene actividades genéricas para cualquier proyecto
se detallan según las necesidades de cada proyecto
también tiene actividades sombrilla o de protección
Comunicación (requerimientos)
Planeación
Modelado (análisis y diseño)
Construcción (codificación y prueba)
Despliegue
Gestión del Riesgo
Seguimiento y control
Revisiones
Medición
Gestión de la configuración
Gestión de la reutilización
Preparación y producción de productos del trabajo
Personal Software Process
Team Software Process
Modelos generales reconocidos
Modelos con nombre propio
Métodos ágiles
proyectos pequeños de una persona
proyectos para equipos pequeños
cascada, espiral, iterativos
proceso unificado, ciclo de vida estructurado de Yourdon
Scrum, Crystal Clear, XP
En cada proyecto se selecciona un proceso, o se construye específico para cada proyecto
Una vez escogido el proceso como por ejemplo:
Lineal - secuencial, para sistemas pequeños y muy bien definidos.
DRA, cuando hay restricciones de tiempo ceñido y se puede modularizar.
Incremental, si no puede entregarse el producto completo por restricciones de tiempo o falta de
claridad en los requerimientos.
Según Pressman en Ingeniería de Software
Para proyectos pequeños de menos de 48 horas se debe:
Desarrollar una lista de problemas que deben aclararse.
Reunirse con los clientes para abordar problemas que deben aclararse.
Desarrollar en conjunto un enunciado del ámbito.
Revisar el enunciado del ámbito con todos los implicados.
Modificar el enunciado del ámbito según se requiera.
Para proyectos más complejos, en la actividad de comunicación se debe:

Revisar la petición del cliente.
Planificar y programar una reunión formal con el cliente.
Llevar a cabo investigaciones para especificar la solución propuesta y los enfoques existentes.
Preparar un documento de trabajo y una agenda para la reunión formal.
Celebrar la reunión.
Desarrollar en conjunto miniprospectos que reflejen los datos, función y características del comportamiento del software.
Revisar cada miniprospecto para valorar su consistencia y eliminar ambigüedades.
Reunir los miniprospectos en un documento.
Revisar el documento generado anteriormente o colección de casos de uso con todos los implicados.
Modificar el documento según se requiera.
Según Pressman en Ingeniería de Software
PROCESO
PROPORCIONA
TAMBIÉN ES
PARA
PUEDE SER
un proceso dice quien está haciendo qué, cuándo y cómo lograr la meta
Actividad:
Define las acciones que se llevarán a cabo en un momento dado del desarrollo de software
Controlar la calidad, gestionar la configuración de software y medir resultados
¿Qué es un proceso?
“serie de acciones que conducen a un final”
¿El proceso es la forma en que la organización opera o es la forma en que un desarrollador diseña, produce código, o prueba el software? ¿El proceso se refiere a administración, ingeniería, o ambas? ¿El proceso implica demasiada documentación y nos abstiene de desarrollar el producto objetivo?
siempre que para alcanzar algún fin deseado necesitemos ejecutar una serie de acciones, y estas acciones tengan cierto orden, dependencias, roles responsables, resultados, tiempos de ejecución y herramientas de apoyo, estaremos hablando de procesos,
Proceso de software
Un proceso de desarrollo de software es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y sus procedimientos, componentes de software, metodologías, y herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software
Elementos del proceso de software
Flujo de trabajo
Colección estructurada de actividades y elementos asociados (Artefactos y roles) que producen un resultado de valor
Artefacto
Son las entradas y salidas de las actividades pueden ser de diferentes tipos como: Documentos, modelos componentes
Disciplina
Conjunto integrado por actividades relativas a una rama particular de conocimiento: Ej Análisis y Diseño
Actividades
Flujo de trabajo
Rol
Producto o artefacto
Disciplina
Diversidad en Modelos

Actualmente existe una gran variedad de modelos para procesos de software. Podemos entenderlos más fácilmente si los clasificamos en dos tipos:
genéricos y específicos.
Modelos genéricos
Abarcan todos los procesos relacionados con el desarrollo del software:

CMM, CMMI, ISO 9001-2000.

* Nos dicen qué debemos hacer.
* Se usan como referencia para definir procesos en una organización y para autoevaluación.
* Medio para evaluar que tan bien está una organización.
Modelos específicos
Enfocados a la ingeniería de productos de software
UP, RUP, PSP,TSP

*Nos dicen como debemos hacer las cosas
* Se usan como guía para ejecutar proyectos
CMM (Capability Maturity Model)
Modelo de Madurez de Capacidades
Marco que describe elementos clave de procesos efectivos de software.
Creado por el Software Engineering Institute (SEI) en conjunto con Carnegie Mellon University. La primera versión se publicó en 1994.
CMM
describe un camino evolutivo en 5 niveles de mejora de procesos para lograr su madurez. Cubre prácticas de planeación, ingeniería y administración del desarrollo y mantenimiento de software.
ISO 9001-2000

ISO (International Standards Organization) en 1987 crea la norma ISO 9000, conjunto de estándares que establecen los requerimientos para la gestión de los sistemas de calidad. ISO 9000:2000 está formado por:
• ISO 9000 Fundamentos y Vocabulario.
• ISO 9001 Requisitos.
• ISO 9004 Recomendaciones.
La parte de Requisitos - ISO 9001:2000, está estructurado en 8 secciones:
1. Alcance.
2. Normas para la Consulta.
3. Términos y Definiciones.
4. Sistema de Gestión de la Calidad.
5. Responsabilidad de la Dirección.
6. Gestión de los Recursos.
7. Realización del Producto.
8. Medida, Análisis y Mejora.
CMMI (Capability Maturity Model Integration)

CMMI proporciona una guía para desarrollar procesos, que además ayuda a evaluar la madurez de la organización o capacidad de un área de procesos. CMMI incluye los procesos de ingeniería de software e ingeniería de sistemas.
CMMI vs. CMM

• Mejor alineación a objetivos de negocio.
• Mejor visibilidad hacia las actividades de ingeniería, con el objetivo de asegurar que el producto o servicio cumple las expectativas del cliente.
• Aprovechamiento de mejores prácticas adicionales (e.j., medición, riesgo, administración, y manejo de proveedores).
• Acoplamiento más estrecho con estándares de ISO.
PSP – Personal Software ProcessSM
Personal Software Process (PSP) es un proceso diseñado para ayudar a los ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está basado en una motivación: La calidad de software depende del trabajo de cada uno de los ingenieros de software.
PSP – Personal Software ProcessSM
PSP puede ser aplicado en:
• Desarrollo de programas.
• Definición de requerimientos.
• Documentación.
• Pruebas de sistemas.
• Mantenimiento de sistemas
TSP - Team Software ProcessSM
TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es desarrollado por equipos. TSP le enseña a los ingenieros a construir equipos autodirigidos y desempeñarse como un miembro efectivo del equipo. También muestra a los administradores como guiar y soportar estos equipos.
Estrategia de TSP

• Proveer un proceso sencillo basado en PSP
• Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento, Estrategia, Plan, Requerimientos, Diseño, Implementación, Pruebas, Postmortem
• Establecer medidas estándares para calidad y desempeño
• Proveer definiciones de roles, y evaluaciones de rol y de equipo
• Requiere disciplina de proceso
• Provee guía para manejo de problemas de trabajo en equipo
RUP
proceso de software desarrollado y comercializado por Rational Software (ahora parte de IBM).
está diseñado alrededor de seis mejores prácticas para el desarrollo de software:
• Desarrollar de manera iterativa.
• Administrar los requerimientos.
• Utilizar arquitecturas basadas en componentes.
• Modelar el software visualmente.
• Verificar la calidad de manera continua.
• Controlar los cambios.
RUP organiza los proyectos de software en dos dimensiones: la del tiempo y la de las actividades. En base al tiempo, los proyectos se dividen en cuatro fases secuenciales:
• Concepción – Definición de alcance, identificación de riesgos.
• Elaboración – Resolución de riesgos, establecimiento de arquitectura.
• Construcción – Generación del producto.
• Transición – Disponibilidad a la comunidad de usuarios finales.
Las actividades se organizan en nueve diferentes disciplinas que son ejecutadas durante las diferentes fases.
Full transcript