Estos son todo los apuntes de proyectos de software que he tomado, espero que les sirvan

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