miércoles, 27 de julio de 2011

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.


sábado, 23 de julio de 2011

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.

viernes, 22 de julio de 2011

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


miércoles, 20 de julio de 2011

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

viernes, 15 de julio de 2011

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

miércoles, 13 de julio de 2011

Arquitectura y Diseño de un entorno de Desarrollo

A continuación mis apuntes del video de las jornadas Symfony 2010. Hecho para PHP, pero recomendable para todas las plataformas... a propósito se viene la capacitación en Metodologías de Desarrollo?..


Acá el link de las jornadas 2010... (Creo que ya están las del 2011 también...)

Metodología de Desarrollo Ágil: XP eXtreme Programming
-         Centrado en las personas, fomentar la comunicación, programar de a dos
-         Ciclos de desarrollo más dinámicos
-         Pruebas durante el desarrollo
-         Los equipos se organizan en: Programador, Jefe de Proyecto y Cliente
-         Cliente completamente integrado
-         User-Stories; trozos de funcionalidad que agregan valor, completos y probados.
-         Releases, planificación de entregas, priorizar, 2 o 3 semanas cada una.
-         Metodología TDD: Empezar a hacer los test antes que nada.
-          
Metodología de Desarrollo Ágil: SCRUM
-         BackLog, conjuntos de descripciones de funciones, ordenadas y priorizadas, puntuación
-         Sprint, conjunto de backlogs a implementar en un entregable
-         Reuniones diarias del equipo para ver tareas.
-         Chiste del cerdo y la gallina: roles cerdo (marcan la pauta, deciden) y roles gallina.
-         Herramientas de gestión de tareas: Gira (Jira), orientado a SCRUM

No todo es blanco y negro, usemos lo que nos sirva más.

Herramientas de Documentación
-         Wiki: MediaWiki, Confluence, DocuWiki
-         DocBook (XML), XML Mind

Sistemas de Control de Versiones
-         Versionado, accesible, comparaciones, ramas de versiones del trunc
-         Repositorios Centralizados (CVS o Subversion)
-         Repositorios Distribuidos (GIT o Mercurial) Las ramas se crean en local, deja desconectarse de la copia central. Compartir ramas concretas a algunos usuarios.
-         Tortoise HG para Windows (mercurial), clientes para estas herramientas hay miles.

Herramientasde Construcción
-         Empaquetar y poner en producción
-         Evitar que el pase a producción se haga manualmente (para base de datos y programas)
-         Para backups, documentación, etc
-         Servidor de Construcción Continua: Builds automatizados, test unitarios, detección de problemas de integración
-         Para PHP: Apache Ant o Phing; usan xml para describir las tareas que queremos hacer. Es flexible, pero obliga a que el resto de desarrolladores se lo aprenda.
-         Apache Maven o php-maven: Todos los proyectos tienen la misma estructura de construcción, ciclo de vida.
-         La herramienta inclusive tiene funcionalidades de phing.
-         Leer a Martin Fowler sobre la Integración Continua, todos haciendo commit.
-         Hudson, como un servidor de cron. Dispara tareas cuando detecte un commit.
-         PhpUnderControl: Testing, documentación, análisis del código con PHP_CodSniffer
-         CruiseControl
-         Atlassian bamdoo (Jira)

Gestión de Proyectos e Incidencias
-         Para planificar mi programación Agil de Scrum.
-         Jira, tiene una API., Interfaz sencilla. Hay plugins para ambientes de desarrollo. Cada tarea puede tener un contexto, para tareas que terminaré mañana, se abren los archivos registrados. Los commit están orientados a las tareas, hace commit a todos los ficheros del contexto.
-         Realmente aportan valor añadido.

Pruebas unitarias
-         Pruebas de trozos de código
-         Porciones de código que ayudan a probar que las funcionalidades cumplan con los requerimientos de usuario
-         Deben cumplir requisitos, deben ser rápidas, las lentas deben estar en el servidor de integración continua.
-         Hay tipos: unitarias de desarrollo, de integración (con base de datos, web services, etc.), de rendimiento (o estrés), de funcionalidades.
-         Symfony ya tenía testing, pero va a usar PHPUnit
-         Mocks y Stubs
-         PHPUnit: Acerción: el resultado de la prueba se compara con un valor esperado. También pruebas por resultado. Se pueden usar en los servidores de integración contínua
-         Para test funcionales del usuario: Selenium (plugin para firefox), para aserciones. Además ayuda a guardar secuencias de uso en el navegador.
-         TDD: Desarrollo dirigido por test. “No añadir más código que el que realmente necesito”
-         Cobertura de los test en porcentaje
-         Mock “impostor”; clases que suplen a otros de forma controlada, para simular fallos sin necesidad de interactuar con otros elementos reales.
-         Análisis estàtico del còdigo: intenta prevenirme de posibles errores. Complementan las pruebas. PHP_Depend, para evitar procedimientos con muchos parámetros, o muy largos, o muy complejos con varios if… Avisan que nos pasamos de complejidad.
-         PHPCDP: Detecta código duplicado tipo CopyPaste.
-         Sonar: un entorno web donde se unen las herramientas de código estático. Navegar en los errores en la línea del código, es personalizable.

IDE para el desarrollo de Aplicaciones
- Integran Subversion o GIT, Phing, Jira,  PHPUnit, Análisis Estático.