ingeniería del software: nuestro producto debe funcionar

48
Francisco Sánchez Cid http ://web.iti.upv.es/~fsanche z [email protected] @_Francisco_1978 Ingeniería del Software: Nuestro producto, debe funcionar

Upload: francisco-cid

Post on 24-May-2015

157 views

Category:

Technology


0 download

DESCRIPTION

Presentación con algunos consejos acerca de la gestión de un proyecto software, basado en un caso real. Destaca la importancia del equipo, de la planificación del proyecto, y de un correcto análisis de requisitos.

TRANSCRIPT

Page 1: Ingeniería del Software: Nuestro producto debe funcionar

Francisco Sánchez Cid http

://web.iti.upv.es/~fsanchez [email protected] @_Francisco_1978

Ingeniería del Software:

Nuestro producto, debe funcionar

Page 2: Ingeniería del Software: Nuestro producto debe funcionar

Contenido de la charla

Ingeniería del software práctica: “nuestro producto debe funcionar”

1Instituto Tecnológico de

Informática

2ACME TPV

3Algunos

consejos

Page 3: Ingeniería del Software: Nuestro producto debe funcionar

Instituto Tecnológico de Informática

Quiénes somos, qué hacemos

1

Page 4: Ingeniería del Software: Nuestro producto debe funcionar

ITI “Quiénes somos”

• Centro Tecnológico especializado en Investigación, Desarrollo e Innovación en Tecnologías de la Información y Comunicación

• Somos una asociación sin ánimo de lucro y pertenecemos a la Red de Institutos Tecnológicos de la Comunidad Valenciana (junto al del Juguete, el Cerámico, el de la Madera..)

• El ITI desarrolla una labor de I+D+I transfiriendo a las empresas la posibilidad de incorporar a sus productos las tecnologías y capacidades desarrolladas en proyectos de I+D+I

Page 5: Ingeniería del Software: Nuestro producto debe funcionar

Inteligencia de negocio

Big Data

Data Mining

Capacidades en Optimización y BI

Page 6: Ingeniería del Software: Nuestro producto debe funcionar

Tecnologías inteligentes de digitalización

Sistema OCR/ ICR capaz de reconocer y exportar información impresa y manuscrita

Características

Tecnología propia

Plantillas, gestión de lotes y validación inteligente

Exportación de resultados en varios formatos, compatible con diferentes plataformas

Integrable con otros sistemas de gestión documental y otras herramientas de gestión

Proceso sencillo

Papel Digitalización Validación Exportación

Page 7: Ingeniería del Software: Nuestro producto debe funcionar

Control de Accesos y Presencia por Reconocimiento Facial

Sistema de IDENTIFICACIÓN y/o VERIFICACIÓN biométrica basada en análisis de imágenes faciales. A partir de una o varias imágenes de la cara de una persona se puede averiguar o validar la identidad de esta.

iticab.iti.es

¿Porqué biometría facial?

• Es la forma más natural de identificarnos: los humanos nos reconocemos mirándonos a la cara sin ningún otro tipo de interacción (habla, tacto…).

• Por supuesto no nos reconocemos mirándonos al IRIS o las huellas de los dedos

• Los accesos son auditables de forma rápida y segura por el personal responsable de los accesos y la seguridad. Simplemente hay que mirar la foto de quien ha entrado y si ha habido un intento de suplantación de un usuario.

• Con las huellas dactilares es imposible saber si quien ha entrado es quien dice ser por la huella o si se trata de un impostor

Page 8: Ingeniería del Software: Nuestro producto debe funcionar

Sistema avanzado de inspección industrial en 3D

Sistema de inspección que aplica técnicas de Visión Artificial para el control de calidad o clasificación. Realiza la adquisición de imágenes de un objeto a través de múltiples cámaras, mientras la pieza está en caída libre.

Page 9: Ingeniería del Software: Nuestro producto debe funcionar

Y además...• Inteligencia ambiental

• Sensorización avanzada

• Sistemas embebidos y de

comunicaciones

• Cloud computing

• Análisis, Diseño y Desarrollo

Software

• ...

• ¡ah! y Calidad del Software

Page 10: Ingeniería del Software: Nuestro producto debe funcionar

2 ACME TPV

Un año de desarrollo

Page 11: Ingeniería del Software: Nuestro producto debe funcionar

Todo comienza con entrevistas con el cliente:

• Visión del sistema: qué componentes hay, qué interacciones

• Requisitos de alto nivel: la funcionalidad a grandes rasgos

• Plan inicial: una estimación muy arriesgada

El lanzamiento

EntregaDesarrolloLanzamiento

Page 12: Ingeniería del Software: Nuestro producto debe funcionar

Decisiones que marcarán el futuro del proyecto:

• El equipo de desarrollo: perfil tecnológico, perfil personal, roles

• Análisis de requisitos: la base para poder cerrar una entrega

El lanzamiento

EntregaDesarrolloLanzamiento

Page 13: Ingeniería del Software: Nuestro producto debe funcionar

Decisiones que marcarán el futuro del proyecto:

• Tecnologías: Java 7, MySQL, JPA, ActiveMQ, ...

• Entorno de trabajo: Netbeans, Eclipse, Windows, Linux, Trac, SVN...

El lanzamiento

EntregaDesarrolloLanzamiento

¿Cómo elegir y quién debe elegir?¿Elegiríais la última versión?

¿Flexibilidad a cambio de complejidad?

Page 14: Ingeniería del Software: Nuestro producto debe funcionar

A estas alturas, debe estar claro:

• Análisis de Requisitos: documento de referencia, en el que se define toda la funcionalidad a implementar. Ni más ni menos.

• Plan del proyecto: hoy en día es común trabajar de forma iterativa, pero es necesario un plan que establezca horizontes de entrega

El lanzamiento

EntregaDesarrolloLanzamiento

El plan hay que revisarlo por iteraciones

Documento crítico

Page 15: Ingeniería del Software: Nuestro producto debe funcionar

El desarrollo

EntregaDesarrolloLanzamiento

¡Comenzamos a trabajar!

¿y por donde empiezo?

Page 16: Ingeniería del Software: Nuestro producto debe funcionar

Defi

nir y

asi

gnar

Al comienzo, el proyecto está muy poco definido, pero el equipo está a la espera de trabajo

¿Qué podemos asignarles?

Page 17: Ingeniería del Software: Nuestro producto debe funcionar

Defi

nir y

asi

gnar

Al comienzo, el proyecto está muy poco definido, pero el equipo está a la espera de trabajo

¿Qué podemos asignarles?

• Crear la estructura de proyecto, con paquetes principales, y reglas de empaquetado y despliegue

• Formación: servidores sobre los que se desplegará, sistemas de gestión de BBDD, nuevas tecnologías a aplicar...

• Si tenemos que trabajar con hardware específico: primeras pruebas de control

Entre tanto, seguimos con el diseño del sistema:• Arquitectura: separación en componentes, primeros diagramas de

clase y de secuencia• Modelo de datos: primeras entidades a persistir, con su

descripción completa y todos los atributos que creamos necesarios

Page 18: Ingeniería del Software: Nuestro producto debe funcionar

Arquitectura en capas (MVC):Modelo, Vista, Controlador

Modelo: BBDD relacional, con autogeneración JPAVista: Swing básicaControlador: Java 7

Diseño: Definir la Arquitectura

MySQL DB XML

Persistencia

Operadores

Servicios

Disp.

HW

Comunicaciones

Estados

GUI

Page 19: Ingeniería del Software: Nuestro producto debe funcionar

Máquina de estados:

Arquitectura modular: Estados

En lugar de...

MySQL DB XML

Persistencia

Operadores

Servicios

Disp.

HW

Comunicaciones

Estados

GUI

Page 20: Ingeniería del Software: Nuestro producto debe funcionar

Java Persistence API (JPA): >> Autogeneración>> Cambio rápido

Definir la Arquitectura

Modelo ER (Tablas)

Entidades (Clases

Autogeneradas)

Controladores (Clases

Programadas)

MySQL DB XML

Persistencia

Operadores

Servicios

Disp.

HW

Comunicaciones

Estados

GUI

Page 21: Ingeniería del Software: Nuestro producto debe funcionar

Persistencia modelo de datos

Modelo ER (Tablas)

Entidades (Clases

Autogeneradas)

Controladores (Clases

Programadas)

Automático

Page 22: Ingeniería del Software: Nuestro producto debe funcionar

El desarrollo

EntregaDesarrolloLanzamiento

Ya podemos trabajar de verdad:Cada miembro del equipo tiene una responsabilidad

Persistencia -> Técnico 1Flujo de caja -> Técnico 2Ofertas -> Técnico 3Hardware -> Técnico 4Comunicaciones -> Técnico 5

Page 23: Ingeniería del Software: Nuestro producto debe funcionar

El desarrollo

EntregaDesarrolloLanzamiento

Ya podemos trabajar de verdad:Cada miembro del equipo tiene una responsabilidad

Persistencia -> Técnico 1Flujo de caja -> Técnico 2Ofertas -> Técnico 3Hardware -> Técnico 4Comunicaciones -> Técnico 5

¿Detectáis algún riesgo ahí arriba?

Page 24: Ingeniería del Software: Nuestro producto debe funcionar

Ries

gos

del p

roye

cto

¿Qué ocurre si alguien del equipo falla?• Evaluar el retraso: tiempo de transferencia, búsqueda de un

nuevo miembro para el equipo• Depende de quién falle, pero sólo hay una solución:

documentación y puesta en común

Page 25: Ingeniería del Software: Nuestro producto debe funcionar

Ries

gos

del p

roye

cto

¿Qué ocurre si alguien del equipo falla?• Evaluar el retraso: tiempo de transferencia, búsqueda de un

nuevo miembro para el equipo• Depende de quién falle, pero sólo hay una solución:

documentación y puesta en común

Además, ¿cuando os retrasabais, a quién llamabais?

Page 26: Ingeniería del Software: Nuestro producto debe funcionar

El desarrollo

EntregaDesarrolloLanzamiento

Proseguimos con el desarrollo...

Tenemos un montón de HW implementado, pero llegan nuevos problemas

Page 27: Ingeniería del Software: Nuestro producto debe funcionar

Distintas versiones para un mismo dispositivo

Escáner

Impresora¿Se os ocurre alguna solución?

Page 28: Ingeniería del Software: Nuestro producto debe funcionar

Distintas versiones para un mismo dispositivo

Herencia: funcionalidad común heredada

Page 29: Ingeniería del Software: Nuestro producto debe funcionar

Distintas versiones para un mismo dispositivo

Interfaces: funcionalidad común definida y acotada

Page 30: Ingeniería del Software: Nuestro producto debe funcionar

Distintas versiones para un mismo dispositivo

Patrones: patrón factoría. Instanciamos según configuración y conseguimos independencia

Page 31: Ingeniería del Software: Nuestro producto debe funcionar

El desarrollo

EntregaDesarrolloLanzamiento

Ya estamos a mitad de camino...

¿Qué hace nuestra TPV?• Identifica los productos y los añade al ticket de venta• Aplica ofertas• Transfiere la información de venta al servidor de tienda• Recibe cambios en los datos del servidor de ventas• Identifica a los clientes por fidelización• Realiza recargas de telefonía móvil• Permite pagos con tarjeta de crédito• ...

Page 32: Ingeniería del Software: Nuestro producto debe funcionar

Las

com

unic

acio

nes

Surge un nuevo problema

La cantidad de mensajes que van y vienen en la tienda es ingente, y además:• Los mensajes deben llegar siempre a su destino. • Si el destino no está accesible, hay que esperar a que lo esté• Hay mensajes para un único destino• Hay mensajes para muchos destinos a la vez

Page 33: Ingeniería del Software: Nuestro producto debe funcionar

Las

com

unic

acio

nes

Surge un nuevo problema

La cantidad de mensajes que van y vienen en la tienda es ingente, y además:• Los mensajes deben llegar siempre a su destino. • Si el destino no está accesible, hay que esperar a que lo esté• Hay mensajes para un único destino• Hay mensajes para muchos destinos a la vez

De nuevo, os pregunto ¿qué podemos hacer para gestionar bien estas comunicaciones?

Page 34: Ingeniería del Software: Nuestro producto debe funcionar

Las

com

unic

acio

nes

Patrones de Integración Empresarial

Durable Subscriber

Guaranteed Delivery

Publish-Subscribe

Page 35: Ingeniería del Software: Nuestro producto debe funcionar

Patrones de integración basados en mensajería

>> Confirmación de entrega de mensajes

>> Persistencia de la mensajería

>> Durabilidad de los mensajes

>> Independencia de la localización física

Modelo de colas

Page 36: Ingeniería del Software: Nuestro producto debe funcionar

El desarrollo

EntregaDesarrolloLanzamiento

Y nos acercamos al final• Hay cambios de última hora en los requisitos• El equipo de test no para de reportar incidencias• Comienzan las prisas en el desarrollo. Hay que echar horas

extras. Toca trabajar algún festivo y fin de semana• El estrés del equipo se dispara• El cliente pide informes de avance continuos

Si no actuamos, el proyecto se nos va de las manos¿qué podemos hacer?

Page 37: Ingeniería del Software: Nuestro producto debe funcionar

Decisiones que marcarán el futuro del proyecto:

• El equipo de desarrollo: perfil tecnológico, perfil personal, roles

• Análisis de requisitos: la base para poder cerrar una entrega

Volvemos al lanzamiento

EntregaDesarrolloLanzamiento

Hay que quitar presión. Actividades fuera de la

oficina, flexibilidad horaria, teletrabajo, ...

Page 38: Ingeniería del Software: Nuestro producto debe funcionar

Decisiones que marcarán el futuro del proyecto:

• El equipo de desarrollo: perfil tecnológico, perfil personal, roles

• Análisis de requisitos: la base para poder cerrar una entrega

Volvemos al lanzamiento

EntregaDesarrolloLanzamiento

Hay que se inflexible con el cliente. Los nuevos

requisitos implican tiempo, esfuerzo, y dinero

Page 39: Ingeniería del Software: Nuestro producto debe funcionar

El Jefe de Proyecto, debe ser el primero y el último

Si queremos conseguir la implicación del equipo

Page 40: Ingeniería del Software: Nuestro producto debe funcionar

La importancia del testeo

EntregaDesarrolloLanzamiento

Page 41: Ingeniería del Software: Nuestro producto debe funcionar

La importancia del testeo

EntregaDesarrolloLanzamiento

Al final del desarrollo es cuando se hacen más patentes las virtudes del testeo. Por ejemplo, el testeo unitario:

• Al implementarlo, parece tedioso e innecesario: “sabemos lo que estamos haciendo y qué debe devolver nuestra función”

• Pasan 10 meses• Se han implementado 500 nuevas funciones• Se va el desarrollador• Hay que hacer una modificación en (por ejemplo) el cálculo del margen

para el reparto de las ofertas en un lote de productos, que lleva funcionando bien casi 1 año

¿Alguien se atreve?

Page 42: Ingeniería del Software: Nuestro producto debe funcionar

...esa es otra historia

Y respecto a la entrega...

Page 43: Ingeniería del Software: Nuestro producto debe funcionar

3 ALGUNOS CONSEJOS

Espero que os sirvan...

Page 44: Ingeniería del Software: Nuestro producto debe funcionar

Consejo 1: Sed ingenieros

• Todos empezamos desde abajo, así que…– Hazte un buen

programador– Pero no lo olvides:

• Eres Ingeniero, aunque tu rol sea programador

– Hazte un buen tecnólogo• No es sólo programar, es

conocer la tecnología– Internacionalízate

Page 45: Ingeniería del Software: Nuestro producto debe funcionar

Consejo 2: Sed diseñadores

• Maneja el MVC con soltura:

• Aprende el porqué de 3 cosas:– Interfaces– Herencia– Patrones

Page 46: Ingeniería del Software: Nuestro producto debe funcionar

Consejo 3: Sed técnicos

• Respecto a la programación:– Ingenia, busca, no des nada por seguro: duda de todo.– Sé maduro: aplica patrones– Sé limpio: aplica formatos estándar– Consulta (o participa) en proyectos de SW libre

• Respecto a la tecnología:– No sólo programes, conoce la tecnología– Aprende a crear tu propio criterio: busca y compara– No es Java, sino Struts, Hibernate, Spring…– No es .NET, sino SQLServer, Sharepoint, Visual Studio…

Page 47: Ingeniería del Software: Nuestro producto debe funcionar

Consejo 4: Disfruta de lo que haces

• Respecto a ti:• Sé humilde, pero

intrépido• Saca todo el partido

de los que saben• Procura estar al día en

tecnología

Y entre nosotros…Aquello que hagas, hazlo

bien

Page 48: Ingeniería del Software: Nuestro producto debe funcionar

¿preguntas?

Y eso es todo...