Iniciar proyecto con Power Builder y Subversion

Pautas Generales:

1. Obligatorio leer: "Buenas Prácticas de Gestión de Versiones con Subversion", de allí lo más importante:

• Trunk: Rama de desarrollo principal, nuestro desarrollo será en esta carpeta.
• Tags: Rama de gestión de versiones. Reservado para versiones cerradas, por tanto no se desarrollará sobre esta rama. Cada versión corresponde con los entregables del sistema.
• Branches: Rama con evoluciones paralelas al Trunk. No utilizar salvo para desarrollos auxiliares, levantamiento de errores que luego llevaremos al trunk y tag para pasar a producción.

2. Trabajaremos usando un servidor Subversion para el control de versiones y PBSCC para descomponer los objetos de los PBL de Power Builder, como expliqué en este post.

3. Antes de comenzar el desarrollo necesitaremos instalar: en el servidor el VisualSVN, y en cada cliente el TortoiseSVN y PBSCC pra el control de fuentes con Power Builder.
4. La dirección del Repositorio será de la siguiente forma: https://servidor.int/svn/Aplicacion/
5. El desarrollo lo haremos en la carpeta trunk del repositorio: https://servidor.int/svn/Aplicacion/trunk/


I. Instalación Inicial de las fuentes en el Servidor

1.1 Poner la versión inicial de las fuentes en el trunk
1.2 Hacer el primer tag llamado 1.0.0

II. Instalación inicial de cada desarrollador
2.1 Crear las carpetas "SVN-WORK" y "FUENTES"
2.2 En SVN-WORK se hará el primer update para descargar la versión a su copia de trabajo.
2.3 En la carpeta fuentes se deben grabar las fuentes (objetos PB: pbl, pbw, pbc...)

III. Instrucciones para el trabajo diario

Antes de editar un objeto de un PBL se debe coger con "CheckOut" y luego se podrá editar. Con esto también se bloquea el acceso de otros desarrolladores al objeto.

Al terminar la edición, se hace "CheckIn" que sube los cambios al repositorio

También se puede descartar los cambios trayendo la última versión del objeto con "Get Latest Version..."

Disciplina de Gestión de Proyectos

Es una Disciplina de Soporte de RUP.

Usamos la herramienta del RUP. Está entre las disciplinas

Tarea: ¿Cómo justificaríamos invertir en el proyecto?

La Gestión del Proyecto se hace desde que me aprueban el Proyecto. En realidad es el Acta de Constitución del Proyecto (Project Charter) la que da inicio a RUP.

Al inicio el Gestor de Proyecto debe hacer estos tres documentos:

• Casos de negocio
• Lista de Riesgos 
• Plan de Desarrollo de Software

El Project Charter lo firman:
El sponsor
El jefe de Sistemas
El jefe de la oficina que hizo el requerimiento
El jefe de alguna oficina con la que se integra el sistema.

Práctica la próxima clase, va a venir un enunciado para identificar objetos y clases. También conceptos básicos de UML.

Introducción al UML

1. Fundamentos del UML

Es un lenguaje Unificado de Modelado.
Tiene la característica de estar orientado a objetos.
Tiene gramática, sintaxis, elementos, reglas para nombrar estos elementos.

Estándar para el modelado de sistemas.
Es una notación, no es un proceso, ni es una metodología (como es RUP)

Creado en 1997. Se basa en metodologías antiguas: OMT, Booch, OOSE

Hubo cambios fuertes desde la versión 2.0 (en 2004)
Se espera que la versión 2.5 tenga grandes cambios también (aún no sale)

2. Estructura de UML

Elementos de UML

7 Elementos que intervienen en todos los diagramas: Clases, Interfaz, Colaboración, Casos de Uso, Clase Ativa, Componente y Nodo.
Curiosidad: Los actores son clases con un estereotipo
Los componentes son las librerías... los archivos físicos
Los componentes van en los nodos, son los equipos, servidores, discos duros... inclusive pueden ser hubs, routers... si es necesario

2 Elementos de Comportamiento:
Son la interacciones (flechas) y la Máquina de Estados (rectángulo redondeado)

Elemento de Agrupación: El Paquete
Elemento de Anotación: La Nota

Relaciones UML

Relación de Dependencia
Un elemento depende de otro



Relación de Asociación
Dos elementos necesitan trabajar en conjunto


Relación de Generalización
Apunta hacia el elemento general


Relación de realización
Un elemento de colaboración ayuda al caso de uso. Apunta hacia el caso de uso.




Diagramas UML

UML1.x
9 diagramas:
Diagrama de clases: de análisis, de diseño, de negocio. Varían por el estereotipo. Los únicos elementos son clases y relaciones (solo línea contínua)

Diagrama de casos de Uso: dos diagramas
Casos de Uso de Negocio: Expresa los procesos de la empresa, todos aquellos procesos que tienen relación con el sistema. El Actor (StickMan) y los casos de uso llevan un estereotipo de línea diagonal. La relación es una asociación simple sin flecha.
Casos de Uso del Sistema: Expresa las funciones de un sistema

Diagrama de Objetos: Modela las instancias de los elementos. Grafican un ejemplo, una instantánea.

Diagramas de Secuencia: Compuesto de Objetos, instanciados de una clase que ya exista. Es un modelo de análisis. Es una secuencia de mensajes y corresponde exactamente lo que debe ocurrir en un caso de uso. Es importante el orden en el que se envían los mensajes.

Diagrama de Colaboración: Corresponde al diagrama de secuencia, pero de distinta forma.

Diagrama de Estados: Muestra un valor de un atributo. Normalmente va pegado a una clase. Las líneas llevan los eventos y los mensajes. Tienen un solo inicio y pueden tener varios finales.

Diagrama de Actividades: Parecidos a los diagramas de flujo. Un solo inicio, las actividades son atómicas (no pueden ser subdividido). Corresponden a una operación o un caso de uso.

Diagrama de Componentes: Para los archivos físicos.

Diagrama de Despliegue: Va junto al de componentes. Muestra qué componentes van en qué nodo (servidor, pc de usuario y otros elementos de la red también).

UML2.x
Han cambiado algunas cosas:
d. de actividad tiene nuevos elementos
d. de Estados ahora se llama Máquina de Estado
d. Secuencia tmabién tiene nuevos elementos.

Diagrama de Visión de Interacción: Nuevo diagrama que muestra la secuencia entre diagramas, parecido al diagrama de actividad. Realmente puede expresar la secuencia de varias cosas, no solo casos de uso, como una caja negra.

Diagrama de tiempos: Para programar tiempos en dispositivos o piezas de software.

d. Comunicación es el de colaboración

Diagrama de Paquetes, aunque ya se usaba intuitivamente.

Diagrama de Estructura Compuesta: para software que pueden crear su propia estructura de clase o nuevos tipos de datos.

Hay una Estructura Taxonómica que categoriza los diagramas entre d. de Estructura (estáticos) y de Comportamiento (dinámicos)

También en la versión 2.0 aparecen los frames que tienen etiquetas: pkg, cmp (componentes), uc, act, stm (Máquina de Estado) y sd (d. de interacción)

Mecanismos Comunes
Elementos de Apoyo que ayudan a entender mejor el diagrama.

Especificación. un documento que ayuda a poner por escrito precondiciones, post condiciones, restricciones, errores,  etc


3. Arquitectura UML

4+1



REGLAS EN UML

Hay consideraciones, las cosas no pueden combinarse de cualquier manera, existen reglas.

Hay reglas para nombres, alcance, visibilidad y 2 mas

Para nombres:

La dependencia entre casos de uso include y extend.

Nombes de caso de uso de sistema se escriben en infinitivo, los nombres de casos de uso de negocio no tienen reglas porque dependen de cada negocio.

Para alcance: Da el significado específico a un nombre. Me dice cuando mostrar o no mostrar cosas. Como el include que en los casos de uso nunca van de uno con uno.

Para visibilidad:  los signos (+ u otros ). O la regla que dice que siempre debe haber estereotipo gráfica o textualmente.

Para integridad: relaciones apropiadas entre elementos.

Ejm: Un actor q no puede tener include con un caso de uso. include entre dos casos de uso.

Para Ejecución

Luego usamos el Enterprise Arquitect

- Herramienta poderosa... licenciada... pero no es fiel a UML para analisis de negocio

- Copy and Paste poderosos... al pegar en Word le pone automáticamente el frame

- Crear los elementos en sus paquetes y luego traerlos al diagrama como vínculo.

- Asegurarse de abrir el diagrama correcto con doble click... pasa seguido que ponemos actores en un sitio y no era...

- En Business Entities, para crear los objetos de negocio, debemos crear un diagrama de objetos, luego crear la clase (son clases creadas para apoyo nomás, no son las clases finales del sistema), luego instanciarla

- De Business Entity a Entity para al final poner tener las clases reales del software

- En entidades de negocio es necesario poner las clases y luego instanciarlas... en el modelo de Trabajadoers de Negocio, no es necesario crear las clases... solo se ponen objetos.
- Se puede subir los archivos de Enterprise Arquitect al subversion... leer esto
==
Precisiones:
El estereotipo es para los elementos, y es obligatorio en todos los diagramas y puede aparecer gráficamente o escrito.
El actor es una clase
Nunca poner BusinessWorker en un diagrama de Casos de Uso!
En las casos de uso no va la secuencia
==
Para el trabajo:
- Power Builder puede ser usado orientado a objetos? Sí... leer por qué
- Se puede subir los archivos de Enterprise Arquitect al subversion... leer esto
- Debo llegar a una nueva implementación del Gestor con un avance de los diagramas con Enterprise Arquitect.

Analisis y Diseño Orientado a Objetos

La Crisis del Software

Casos del Dpto de vehiculos motorizados de California y el caso de American Airlines

Razones:
Base Inestable, documentos no están estandarizados, formatos diferentes... diseños incomprensibles
Fallas en el Manejo de riesgo, faltó plan de contingencia, no planteó estrategia... y ante los problemas, no hay acción.
La complejidad del SW. Coplejidad en la lógica, complejidad en los procesos de negocio que conllevan a procesos automatizados complejos.

Soluciones:

• Buen análisis y Diseño, RUP tiene contemplado todas las herramientas para esto.
• Conservar un modelado sencillo. Programación lo más sencilla posible
• Usar un lenguaje de modelamiento común
• Compatible con diversas herramientas, no siempre tenemos las herramientas con las licencias... es mejor exportar los documentos a forma libre o estándar.

UML es necesario porque es un lenguaje estandarizado que permite graficar el sistema desde todas las perspectivas, por dentro y por fuera.. en cada evento, cada botón, cómo se registra en la base de datos, qué componentes salen producto de esa implementación y cómo se va a desplegar la aplicación.

Así como vamos a picar nuestras paredes y suelos de casa para poner el gas natural cuando no lo contemplamos en los planos, así también parcharemos los sistemas a la mala cuando tengamos que poner nuevas funcionalidades en nuestras aplicaciones.

Para lograr esto el concepto de orientación a objetos es muy útil, podremos armar el sistema como armando un rompecabezas.

Los objetos son comunes en la realidad, al nacer la RENIEC nos exige registrar a cada bebe. Así se reconoce la individualidad de cada persona. Y a su vez necesita información específica de cada uno, no quieren saber nuestro signo zodiacal o tipo de sangre, ellos necesitan los nombres, apellidos, fecha de nacimiento, y algunos datos más. No todos, solo algunos datos. Una universidad pide otro tipo de información, y así cada realidad exige distintos datos del objeto.

Un objeto posee características y comportamiento propios, únicos e inconfundibles.

Un buen análisis buscará encontrar esos elementos que lo hacen único e inconfundible.

Nunca asumir nada, siempre hay que analizar y preguntar siempre para conocer la identidad de un objeto.

Siempre observar las reglas de negocio preguntando

Los objetos tienen dos elementos: Atributos y Operaciones.

Los estados son valores de los atributos: Prendido, Apagado, Activo, Inacivo, Casado, Soltero, Aprobado, Desaprobado...

Siempre que vamos a hacer un sistema, se pregunta el alcance, para qué es el sistema y deben decirme qué atributos usar. Sino, corremos el riesgo de asumir.

==

Ejercicio: Hemos resaltado los objetos de este enunciado:

Juan Pérez es profesor del curso de Ingeniería de software dictado en la Escuela de Sistemas de la Facultad de Sistemas de la Universidad Peruana de Ciencias Aplicadas, también lo dicta en la escuela de sistemas de la Facultad de Sistemas de la UNI. Juan Pérez es profesor contratado en la UNI, pero es profesor nombrado en la Universidad. Es profesor principal en la UNI y es profesor asociado en la Universidad Peruana de Ciencias Aplicadas. Nació en Arequipa pero actualmente vive en Lima.

Pedro Alegría ingresa su código de estudiante al sistema de Reserva de cursos, el sistema le pregunta por el semestre a matricularse y este le indica que corresponde al semestre 2003-02, luego elige de la lista de horarios existentes, el horario nocturno.

De una lista de cursos disponibles, Pedro elige Inglés Básico, Electrónica Digital y Algoritmos Matemáticos. Como cursos electivos escoge Teoría de la Música y Programación en C++.

El sistema de Reservas de Cursos determina que los datos son conformes y le imprime el comprobante N° 0015264 para que se acerque al departamento de Caja puesto que internamente se acaba de enviar sus datos al sistema de Cobranzas para su proceso.

==

Programación Orientada a Objetos (características de objetos)

• Abstracción
• Encapsulamiento
• Cliente Servidor
• Jerarquía (dependencia) de dos tipos: Generalización (herencia) y Agregación (agrupamiento)
• Polimorfismo, una entidad que puede tomar diversas formas
• Modularidad, subdividir en partes más pequeñas para darles independencia
• Persistencia, capacidad de poder almacenarse en un lugar fijo para poder existir.

Clases

Agrupaciones de objetos con características y comportamientos similares. 

• Guía de estilo que recomienda RUP:
• Usar sustantivo singular
• Empezar con mayúscula
• No usar subrayado (los subrayado se usan en objetos, no en clases)
• Los nombres compuestos se escriben juntos.

Graficando:

Objeto:

Los objetos tienen los nombres subrayados

==
Ejercicio: se han  resaltado las clases en el siguiente enunciado:

En la base de datos de la Universidad Peruana de Ciencias Aplicadas, se representan datos sobre estudiantes y profesores. Para los estudiantes, se representa el apellido, edad, sexo, ciudad y provincia de nacimiento, ciudad y provincia de residencia de sus familias, lugares y provincias donde vivieron antes (con el lapso que vivieron en cada uno), cursos que han aprobado, con nombre, código, profesor, nota y fecha. Aunque para el caso de Alicia Fernández fue difícil registrar el lugar de residencia de sus padres porque es huérfana y su familia actual no recordaba ese dato.

Asimismo, se representan los cursos a los que un alumno asiste en la actualidad y, para cada uno, día, sitios y horas de dictado de las clases (cada curso se imparte a lo sumo una vez en un día).

Para estudiantes graduados, se representa el nombre del consejero y el número total de créditos en el último año. El Ing. Rubén De la Cruz es consejero de esta universidad por más de tres años consecutivos pero dejo de ser docente el ciclo pasado.

Para estudiantes de doctorado, se representa el título y área de investigación de sus tesis. Para los maestros, se representa el apellido, edad, lugar y provincia de nacimiento, nombre del departamento académico al que pertenecen, número de teléfono, título, situación y temas de investigación.

Algunos temas de investigación, como la Exportación de Espárragos, ya están prohibidos por haberse saturado el número de tesis presentadas.

==

Por qué fracasan los Proyectos de Software

Nos ponen algunas pero tienen maneras de resolverlas, RUP ofrece mejores practicas

Aplicar una metodología pero apliquémosla bien: una metodología y un lenguaje común

=====

Reflexiones para el trabajo:

- El Gestor no es Modulado... se puede hacer algo con esto?

- Control de versionamiento siempre

El futuro del desarrollador es positivo...

Encontré un artículo muy interesante de Hason Hiner que dice que la siguiente década es de los desarrolladores, a continuación algunos apuntes de este alentador informe:

- La década de los desarrolladores, conlleva a la década de las factorías y las app stores.

- Crear aplicaciones será más barato que modificarlas.

- Modular el ERP para transferir información en XML, adquirir estándares abiertos..? Aún no está claro usar el XML en ERP... mi entrada anterior

- Es un ambiente en el que sobrevive el más apto desarrollador. En este entorno, los desarrolladores tienen grandes oportunidades para la independencia y la creatividad. Los desarrolladores individuales y pequeños equipos de desarrolladores (a veces en colaboración con los diseñadores y gestores de proyectos) ahora pueden construir mini-imperios por sí mismos, gracias a los sistemas de micropagos tipo PayPal que permiten tener prácticamente toda la infraestructura necesaria para iniciar una empresa de consultoría negocio.

- De día en una gran empresa, de noche, freelance

- No importa tanto la ubicación para encontrar clientes. Correo electrónico, skype y una carpeta web respetable de productos.

- Tampoco importa la ubicación para trabajar colaborativamente.

¡¡¡¡ Aumentará la demanda de software: Ojo: la web se mete en la casa!!!!

- Otra idea es poner el ERP en la nube y ofrecerlo

- Habrá mayor presión para las oficinas de TI porque los usuarios se familiarizarán más aún con los sistemas y serán más exigentes. Habrá mayores tercerizaciones de servicios de TI. Los desarrolladores serán el centro de la atención.

Reflexión:

Yo debo saber hacer aplicaciones:

- Multiplataforma (windows, linux, web)
- Que hagan funciones "básicas":
    - Enviar correo
    - gestión de archivos
    - Login, manejo de usuarios, quizá LDAP

ERP y XML

Buscando la manera de mejorar mis aplicaciones pensé que dar al ERP funcionalidad de compartir y almacenar información en xml sería interesante, pero no luego de leer algunas opiniones, no termino por convenserme...

Leí el artículo de Doug Potter que me dio más elementos, pero que nos deja con la encrucijada.

Gestión de Riesgos en Proyectos de Software

Antes de la Clase:
Navegando en el RUP (Notas)

Glosario de Empresa
Glosario del Proyecto
Podrían estar en uno solo Glosario

Todos los documentos tienen una lista de comprobación o CheckList
No todos los documentos tienen ejemplos.

Los dominios son equivalentes (9) a las disciplinas (9)

Riesgos

Pueden ser positivos o negativos

Positivos (Oportunidades):

Aprueban presupuesto adicional, 

Negativos (Amenazas):

Recortes presupuestales, Fusión, rotación de personal, cambio de sponsor...

Tipos de Riesgos

Directos (Se tiene control)
  

Indirectos (No se tiene control)
  Terremotos, Cambio de Leyes,
  Se pueden tener Planes de acción

Proceso de Gestión de Riesgos
1. Identificación de Riesgos

• Tormentas de idea... para identificar riesgos
• Herramientas para la gestión del Riesgo

2. Análisis de Riesgos

3. Seleccionar los Riesgos a Gestionar

4. Plan de Gestión

• Hay responsables de cada riesgo
• Transferir: Se puede transferir el riesgo a un tercero: tercerizar. Pero se le debe hacer seguimiento
• Aceptar el riesgo
• Evitar, no tomo el riesgo
• Mitigar, tomar acción para reducir la probabilidad.

6. Monitoreo del Riesgo

Documentos RUP

1. Plan de Gestión de Riesgos

• Las primeras iteraciones son para los riesgos más peligrosos.
• 
  

===
Reflexiones

• Ojo, las herramientas case pueden terminar desplazando el rol del desarrollador!
• A veces las factorías usan un estándar de nombres de pbl o de base de datos, que no son intuitivos para forzar al cliente a llamarlos.
• En actas de reunión van nombres, en documentos de preferencia van cargos, roles, puestos...

Resoluciones para el trabajo:

• Debemos tener el modelo de negocio y casos de uso de nuestros sistemas (mem y lyl)
• Licencias? Por confirmar: si un programador (de servicios por honorarios) hace una parte de los sistemas, esto puede salvar a la empresa (factoring)... hecha la ley...
• El usuario no debe llamar al programador, sino al jefe de proyecto. Esto produce retrasos de desarrollo, además es un desorden de control de cambios.
• Lyl: donde poner el servidor?
• Para UML se puede usar StarUML, Poseidon, Eclipse
• No hay una aplicación donde subir los artefactos del ciclo de un desarrollo... hay q hacerla!
• Lyl: Cómo son los riesgos? Cómo serían los backup?
• Lyl si somos los que entendemos el negocio de OGA... cómo lo difundimos? como mantenemos esta ventaja?
• Siempre verificar las vacaciones de los usuarios que apoyan al equipo. A veces se puede aplazar las vacaciones del personal por el bien del proyecto, a veces debemos cambiar el cronograma. Si somos un factoring, debemos poner en acta que si alguien no está no se mueven las fechas y la conformidad la da alguien más.
• Las reuniones de avance de trabajo deben tener agenda y una de dos: lunes por la mañana o viernes por la mañana.

El Proceso Unificado, RUP

2. Mejores Prácticas

Modelamiento

Se recomienda usar Enterprise Arquiteck,

Calidad

Con la calidad no se juega

Testing: Reparar un software después de implementado cuesta más del doble.

"Nunca lo pruebe el mismo que lo programó"

• El sistema debe hacer lo que el usuario quería
• Debe hacerlo bien

Control de cambios

Documentar el requerimiento de cambio del sistema. Usar el formato. Se aclara la comunicación.

Existen formatos. Inclusive si hay una ley que exige el cambio.

Control de cambios de versiones

.. hay otras, chequear ppt

3. Elementos

Parentesis sobre los roles:
Los analistas y arquitecto de software deben documentar, pero el desarrollador no documenta. Todo llega listo para el programador... a este paso el rol del desarrollador será cubierto por una aplicación.

Las factorías de Software deberían tener obligatoriamente un sistema de levantamiento de requerimientos (Requisi Pro, super caro)

Roles
Características q debe tener una persona, define el comportamiento que debe tener una persona para cumplir ciertas tareas del proyecto.
Sombrero que usa una persona para tener varias posiciones en el proyecto

Un desarrollador debe saber de todas maneras: Word, Excel, Project.

Tareas 
Categorías de tareas:

• Thinking Steps
• Performing Steps
• Reviewing Steps

La tarea principal del Proyecto es la Especificación de los Casos de uso

Artefactos
El Documento Visión es uno de los principales artefactos

Fases
Todas las fases tienen un WorkFlow

Arquitectura de Desarrollo con Power Builder

Subversion y Power Builder

El tradicional esquema de desarrollo en Power Builder está compuesto por una carpeta de fuentes (pbl) en el servidor, a donde se conectan los programadores para actualizar sus fuentes locales (también pbl). Pero este esquema obliga a los desarrolladores a coordinar muy bien qué PBL está trabajando cada uno para evitar perder cambios al subir los archivos al servidor manualmente usando copy/paste de windows.

Actualmente existen varios mecanismos de control de cambios y versionamiento que permiten  revertir cambios a un punto exacto del historial, corregir conflictos por trabajo sobre el mismo archivo y proponen una arquitectura de trabajo seguro. Uno de estos mecanismos es el usado por Subversion, muy conocido en el mundo de la programación (aunque puede ser usado para todo tipo de versionamiento de documentos).

A continuación presentamos cómo utilizar Subversion y Power Builder.

I. Preparando el Ambiente

Mantener el orden de instalación por favor:

1. En el servidor:

Instalar el VisualSVN Server
página para descargar

2. En el Cliente (pc del desarrollador)

Instalar:
Slik Subversion (descargar)
TortoiseSVN (descargar)
PBSCC Proxy (descargar)

Luego explicaremos para qué sirve cada programa.

II. Configurando Repositorio, Copia de Trabajo y Carpeta de Fuentes

Power Builder maneja sus fuentes mediante librerías PBL, que encapsulan los objetos tales como ventanas, datawindows, etc. Esto es una limitación para los sistemas de control de cambios como Subversion, por eso recurrimos a PBSCC Proxy, que se encarga de desencapsular los objetos de los PBL y dejarlos listos para el control de cambios, los archivos finales no son desconocidos para nosotros, son los archivos srw o srd que usa PowerBuilder para exportar objetos.

1. Configurar Copia de trabajo y Repositorio

El TortoiseSVN introdujo funciones al menú contextual de windows, dando click derecho en nuestra carpeta de Copia de Trabajo, configuramos el SVN CheckOut:

En URL of Repository, ponemos la dirección URL del Repositorio creado en el servidor

En Checkout directory, por defecto aparaece la dirección de la carpeta de Copia de Trabajo

dar Ok

2. Configurar Fuentes Locales y Copia de Trabajo (en Power Builder)

Al instalar PBSCC Proxy, se han añadido algunas funciones al Power Builder.

En nuestra carpeta de Fuentes Locales (de archivos PBL), nos aseguramos de tener la última versión de nuestras fuentes, cuando todo esté listo, los demás desarrolladores podrán actualizar sus propias Carpetas Lcoales de nuestra versión.

Ahora abrimos el WorkSpace de nuestras Fuentes Locales y damos click derecho en el WorkSpace. Click en Propiedades.

Sourse Control System: escogemos PBSCC Proxy, que fue agregado al instalar la aplicación
User ID: mi usuario de referencia
Project: La dirección de mi carpeta de Copia de Trabajo. Ojo, no es la dirección del Repositorio
Local Root Directory: La dirección de la carpeta de Fuentes Locales.

Seleccionar las opciones como se muestra en la imagen anterior.

3. Primera subida del proyecto:

Selecciona todos los objetos y dar Ok, luego poner una descripción del lote de subida, Algo como: "Primera subida" o "Creación del Proyecto" y dar Ok. Esperar unos segundos y con esto estamos listos para el trabajo en un entorno controlado.

III. Trabajo cotidiano con Power Builder y Subversion

PBSCC trabaja con un sistema de bloqueo de objetos, el desarrollador puede hacer Check Out simplemente a un objeto para modificarlo o también a un conjunto de objetos haciendo Check Out al PBL o a la aplicación completa, hecho esto el/los objetos se bloquerán y nadie más del equipo podrá modificarlos:

Lo común es hacer Check Out en cada objeto que se modificará.

Realizado el cambio o una vez listo el objeto, lo grabamos y le damos Check In, en el menú desplegable. Lo que subirá los cambios ordenadamente al repositorio. Si hay un conflicto, serás informado.

IV. Otras anotaciones

1. Conociendo los Iconos de Estado:

Estado Liberado:
Falta hacer CheckOut antes de modificar algún objeto.

Estado controlado por usuario:


En este estado, el signo check indica que los objetos están a tu disposición y bloqueado para los demás miembros del equipo. Luego de la implementación se puede hacer Check In para subir los cambios al repositorio y soltar el bloqueo.

Estado No accesible

Los objetos están controlados por alguien más del equipo y no están disponibles para CheckOut.

Estos objetos pueden ser desbloqueados con Unlock del tortoise sobre nuestra carpeta de "Copia de Trabajo", pero no podremos subirlas al repositorio por el bloqueo de nuestro compañero, debemos esperar hasta que suelte el bloqueo.

Estado Nuevo

Los objetos con signo más son nuevos para el repositorio, son objetos creados recientemente. Con el Check In suben al repositorio y todos podrán conocerlos.

Estado Actualizado

Indica que los objetos son exactamente los traídos del repositorio, sucede cuando uno Trae la Última Versión en el menú secundario de cada objeto.

Fuentes en la web:
http://dm.char.com.ua/pb/pbscc/pbscc.htm
http://dm.char.com.ua/pb/pbscc/qstart.htm

Metodologías de Desarrollo de Software

Profesora: Amanda Sánchez Larriega,  pxasanch@cibertec.edu.pe
Carpeta de archivos:  file://ca301-serv/

Cada módulo es de calificación cancelatoria
Cualquier problema de material coordinarlo con Hugo Párraga en el primer piso (hparraga@ibertec.edu.pe),
Cualquier problema del curso coordinarlo con la profesora.

El único material completo que es referencia calificada es http://www.uml.org/

I. La Gerencia de Proyectos de Software

RUP es para Metodología
UML es para Leguaje

Ambos se usan para un proyecto.

Averiguar las reglas de negocio de la empresa en la que vamos a aplicar los trabajos. Estas diferencian los proyectos que pueden ser parecidos.

Tratemos que el proyecto sea lo más libre y abierto posible para la exposición. Ir buscando misión, visión... que tengamos acceso a la información

Proyecto: Esfuerzo temporal para crear un producto único.

Se realizan en equipo, cada uno desde su rol

El trabajo de un proyecto es variado, un proceso es repetitivo.

Algunos usan la Bitácora de Trabajo Diario. A veces ponemos lo mismo, otras veces, todo es distinto.

Los equipos de proyecto son temporales y dinámicos. Es un error contratar practicantes para documentar porque no conocen las reglas de negocio ni estuvieron en los problemas que hubo durante el proyecto.

La autoridad del jefe depende de la delegación de las responsabilidades.

Proyectos y subproyectos, RUP los organiza.... por módulos, actores, usuarios... en dos... etc.

Los proyectos deben cumplirse con el presupuesto indicado.
Nunca se negocea la calidad.
Siempre debe terminarse en el tiempo. No se recomienda inflar los tiempos.
Cubrir el alcance, el documento "visión" sirve mucho.

Factores Críticos de Exito:
Sponsor, de preferencia de gerente para arriba
Usar metodologías, el RUP es complejo, pero hay que acostumbrarse y se hace llevadero. UML también permite que todo el equipo entienda el proyecto.
El presupuesto, recortes presupuestales...
Definición del proceso. El proceso de desarrollo y el proceso de negocio deben estar definidos. Si este no existe, hay un problema que se debe resolver ya mismo.
Herramientas. Excel, MS Project...
Satisfacción del Cliente... hay técnicas.

2. La Dirección de Proyectos

Aplicación de conocimientos, experiencias, habilidades para cumplir los requerimientos.

Identificar los requisitos. Existe documentación formal, como el RSS para definir las característias del sistema.
Objetivos claros y realizables
Equilibrar la calidad, alcance, tiempo y costos.

PMBOK es un estandar que guía, pero no da pasos. Recomienda, pero no dice el cómo, para eso es la metodología.

Principios:
Seleccionar proyectos que ayuden al negocio, tipo la rendición de viáticos.
Entender los requerimientos y ponerlos bajo control
Preparar un plan razonable
Tener un buen equipo y establecer responsabilidades. A veces los grupos de influencia, tipo los sindicatos a veces dificultan trabajar con el mejor equipo.
Hacer seguimiento y dar visibilidad. Formatos
Usar la línea de base.
Documentar. La profe tiene todo traducido.
Si no ha sido probado, no trabajará. Si no pasa por testing, jamás debe pasar a producción
Asegurar la satisfacción del cliente
Ser proactivo

Grupos de procesos: Inicio, planeación, control, ejecución y cierre.

Destrezas, habilidades:

Habilidades de comunicación
Habilidades de organización
Construcción de equipos, con las personas ideales... nunca pongas enamorados en el mismo equipo.
Flexibilidad
Creatividad
Paciencia
Persistencia
Conocimiento Previo: Know How

Código de ética:

Compartir sus experiencias.
Aplicar el conocimiento profesional
Balancear intereses de los StakeHolder
Dar la cara
Respetar las diferencias

Funciones del Gerente de Proyectos:
Siempre preparar plan de contingencia
Administrar formalmente el cambio.
Reportar el estado real del proyecto

Liderazgo:
Ser líder o administrador del proyecto:
Es conservador o innovador?
Controlar o promover a las personas?
Visión a corto o a largo plazo? Chequear el PETI
Equilibrado o soñador?
Las personas solo respetan al administrador y siguen a los líderes

Errores clásicos de la Gestión de Proyectos

Estadísticas de Desarrollo de software:
Las grandes empresas suelen mantener los costos porque entienden lo importante de documentar.
Algunos interesados no apoyan para evitar control...
No se supone!!!
Roces con el cliente
Expectativas no realistas, mal calculo de tiempo
Politización
Tiempo desperdiciado al principio, futbol
Planes que ceden a la presión
Acortar actividades fundamentales: testing por ejemplo
No programen sin antes diseñar...
Falla de proveedores, licenciamiento por ejemplo, importaciones...
Control insuficiente
Omisión de tareas al estimar

Errores del producto:
Exceso de requerimientos.... ilimitados
Plantear demasiados objetivos a la vez... deb hacerse por etapas!!
Salirse de los objetivos
Mala negociación de tiempo...
Desarrollo orientado a investigación de herramientas que no conocemos...

Errores de la Tecnología:
Síndrome de la panacea: "Todo lo puedo comprar"
Cambio de herramientas (por plata por ejemplo) en medio proyecto
Ausencia de sistemas de control de versiones de código fuente: Siempre comenzar con Guardar Como!!!

4. Gestión del Recurso Humano

Motivación:
Injusticias del trabajo...  facebook para algunos... hay cosas que desmotivan. También hay cosas que motivan más. hay estímulos diferentes para cada persona. 

Qué cosas motivan a tu equipo??????
"Tu documento está excelente..." "qué buen trabajo haz hecho..."
Hay perfiles... Desarrolladores, ingenieros, les dan más prioridad a desarrollo personal, ideas, etc.

Poner obstáculos siempre desmotiva. El contento en el trabajo, la vida privada...
Oportunidad de tener cargo superior a alguien temporalmente motiva mucho

Factores q desmotivan... temperatura, iluminación, espacio, silencio, no tiene permisos para instalar cosas o acceso a hotmail, o poner usb. Acceso al papel, lapicero.
Pc muy lenta, o software lento. Anexos sin salida a la calle. Impresora a color, faxx sin manual, uso de copias legales de software. Flexibilidad horaria razonable.

Manipulación de la dirección, autoridades
Preciones innecesarias
Dirección incompetente, "que tanto documetnas... avanza!"
Equipos de poco tamaño.

RUP La herramienta

Fase de Inicio: Empezar con una planificación
A conocer la empresa: diagrama de negocio