01/07/2011

Las Siete Etapas de un Proyecto

Temario • • • • • •

(Autor anónimo)

Introducción Estado del arte Problemática general Criterios de diseño Casos típicos de estudio Un ejemplo de aplicación


1 - Aceptación inmediata
2 - Entusiasmo salvaje
3 - Primeras desilusiones
4 - Confusión Total
5 - Búsqueda de los culpables
6 - Castigo a los inocentes
7 - Promoción de los que no participaron

Métodos de diseño

1 01/07/2011

Los Proyectos de TODOS no son de NADIE ANONIMO

Project Management

2

El desafío: Evitar alentendidos

• Hay un viejo cuento con cuatro personajes: Todos, Alguien, Cualquiera y Nadie Ocurre que había que hacer un trabajo importante, y Todos sabía que Alguien lo haría. Cualquiera podría haberlo hecho, pero Nadie lo hizo. Alguien se enojó cuando se enteró, porque le hubiera correspondido a Todos. El resultado fue que Todos creía que lo haría Cualquiera, y Nadie se dio cuenta de que Alguien no lo haría. ¿Cómo termina la historia? Alguien reprochó a Todos porque en realidad Nadie hizo lo que hubiera podido hacer Cualquiera

Como fue propuesto por el Como fue especificado en el Como fue propuesto Como fue especificado en Comitente (Project Sponsor)por el Requerimiento Comitente (Project Sponsor) el Requerimiento

Como fue realizado por los Como fue instalado en el Como fue realizado por los Como fue instalado en el programadores Cliente Programadores Cliente

Como fue diseñado por el Como fue diseñado por el Analista Analista

LO QUE QUERÍA EL CLIENTE ! LO QUE QUERÍA EL CLIENTE !

1

01/07/2011

Los NO de los Proyectos

Los NO de los Proyectos •

No comience un proyecto sin haber hecho un estudio de factibilidad

•

No comience un proyecto sin una especificación escrita – Es la consecuencia directa del estudio de factibilidad, lleva tiempo hacerla pero es la mejor forma de evitar entredichos con quien encarga el proyecto y permite planificar la implementación de la solución




No comience un proyecto si no tiene soporte técnico del tema específico de la aplicación




No comience un proyecto sin las herramientas de software profesionales para encararlo




No comience un proyecto sin antes haber analizado soluciones de terceros para esa aplicación




No comience un proyecto sin contemplar el uso de un RTOS apto para la aplicación



•

No comience un proyecto Ud. solo si el proyecto es largo y complejo (más de 2 meses de duración) – Compártalo y se ahorrará dolores de cabeza – Divídalo en software, firmware, hardware, producto y documentación y subdivídalo si es necesario

Experiencias • Armar grupos con personas afines • Comenzar el proyecto rápidamente con el HW mínimo • Preveer la ausencia de un integrante • Plantear proyectos con sensores que se puedan obtener en el mercado local • Tamaño del proyecto 200 hs





o a alguien de confianza técnicamente idóneo a quien consultar

Consígalas y reducirá los tiempos de desarrollo

Del trabajo de los demás también se aprende

Estado del Arte, ¿cuál es? • Lineamientos a seguir: – KISS “Keep It Simple, Stupid” – DFE “Design for Excellence” – Documentarse debidamente antes de comenzar el diseño Métodos de diseño

8

2

01/07/2011

KISS, ¿qué significa? •

KISS, ¿qué se procura? • Afirma que la simplicidad es la clave del éxito de un diseño en ingeniería

KISS es un acronismo en inglés que significa: – “Keep It Simple, Stupid” (Mantenlo simple, estúpido)

•

• En el desarrollo de sistemas complejos en ingeniería debemos:

Una acepción menos chocante es: – “Keep It Short and Simple” (Mantenlo corto y simple)

– Desarrollar empleando partes sencillas, comprensibles que redundará en errores de fácil detección y corrección. – Rechazar lo rebuscado e innecesario

•

Comenzó a usarse en EEUU en los años 60 (en relación con el proyecto Apollo)

•

Deriva del “Principio de Economía” de William of Ockham (siglo XIV DC) y variantes formuladas por Leonardo da Vinci, Isaac Newton, Albert Einstein y otros.

Métodos de diseño

9

DFE, ¿qué significa?

10

• Diseñar para la excelencia no implica la implementación de todos y cada uno de los ítems listados, ya que que cualquier actividad de diseño estará fuertemente condicionado por dos factores:

Manufacture and Assembly Reliability Testing and Service Disassembly and Reassembly Use and Operability Green, Environment and Recycling Quality and Cost Logistic Inspection and International Etc., etc.

Métodos de diseño

Métodos de diseño

DFE, ¿qué se procura?

• DFE “Design For Excellence”: – – – – – – – – – –

• En otras palabras advierte al diseñador para que en su labor no “compre” problemas sino que “venda” soluciones

– La idiosincrasia tanto del diseñador como del medio en que éste se desempeña – El contexto en que se lleve a cabo el diseño propiamente dicho

11

Métodos de diseño

12

3

01/07/2011 Documentarse antes de …, ¿qué significa?

Documentarse antes de …, ¿qué se procura?

• Seguramente Ud. no es el primero que intenta resolver el problema que enfrenta, por tal motivo es recomendable que recopile toda documentación referida al diseño que está por encarar, a las técnicas y/o herramientas que pueden serle útiles para el diseño, etc., etc.; como por ejemplo: – – – – – –

Hojas de Datos (Fe de Erratas) Notas de Aplicación Ejercicios o Ejemplos de Diseño Manuales de Usuario Manuales de Referencia Técnica Etc., etc.

Métodos de diseño

13

Problemática General

•

Procure encarar la búsqueda con sentido común y criterio

•

Recuerde que la búsqueda en si misma es un medio y no un fin

•

Lea, analice y clasifique toda la documentación recopilada

•

Durante la etapa de diseño saque provecho de la información recopilada “aprendiendo del trabajo de los demás”

Métodos de diseño

14

• Optamos por el más usado, simple y seguro

Metodología de trabajo Diseño electrónico Analógico/Digital (Hard & Soft) Dibujo del Impreso Componentes Producto Fabricación del circuito impreso Fabricación del Producto Etc., etc. Métodos de diseño

Aproveche las facilidades que ofrecen las vías de comunicación actuales para la búsqueda de información

Metodología de Trabajo

• Debemos detenernos a analizar lo siguiente: – – – – – – – –

•

• Recomendaciones: – Procure aprender del método – Procure adaptarlo a su gusto – Si no esta conforme con el método: • Genere su propio método, pero use uno, pues: – Sin método cada diseño nos obliga a comenzar de cero

15

Métodos de diseño

16

4

01/07/2011

¿Cuál es el método?

¿En qué consiste el método?

• El método más usado simple y seguro para desarrollar aplicaciones con micro consiste en fraccionar la solución en módulos simples:

• Comunicar los módulos simples mediante: – Flags / Semáforos – Variables – Colas

– Startup / Inicio => Inicializaciones básicas del micro – Programa Principal => Iteración perpetua de Tareas (algoritmos de control)

• Garantizar que ningún módulo se apropie de la CPU (comportamiento comunitario)

– Manejadores / Drivers de Entrada / Salida => Interacción con el mundo exterior (atención de eventos y sincronismos)

Métodos de diseño

Métodos de diseño

17

Método de Diseño (1 de 2) Interrupciones Deshabilitadas

Entradas IN Serie Paralelo I2C SPI CAD Timer Ticks ¡ Cola Llena ! Deshabilitar interrupciones de Entrada

Drivers Interrupciones de entrada

Reset

Interrupciones OUT: Deshab IN: Hab

Startup / Inicio

variable?

Flags

Tarea 1

Flags

Variables Tarea 2

variable? Colas

Colas

Cola?

Tarea n PROGRAMA PRINCIPAL

•

Garantizar que ningún módulo se apropie de la CPU (comportamiento comunitario)

Salidas

Cola?

Flag? Variables

Método de Diseño (2 de 2)

Flag? Drivers Interrupciones de salida

18

OUT Serie Paralelo I2C SPI CDA Timer Ticks

¡ Cola Vacía! Deshabilitar interrupciones de Salida

Así SI !

?

Acción

Así NO !

?

Acción

19 Métodos de diseño Métodos de diseño

20

5

01/07/2011

Criterios de diseño

Casos típicos de estudio

• Como principiantes debemos asegurar que: • Cortex ejecuta ~ 50 MIPS – Tcpu-pp

≤ 1/2 Fmax Entrada a detectar/Salida a generar ≤1000 Tinstrucción ≤ Tick-mín ≤ 60~70% ∑ (Tcpu-driver/tarea)

– Tinstrucción ≈ 20 nS Tcpu-pp ≤ 20 µS – Tick-mín ≥ 20 µS Tcpu-driver/tarea ≤ 2µS – Fmax Entrada a detectar/Salida a generar ≤ 250 kHz unsigned char data timerTickUChar; // 0 a 5,1 mS unsigned int data timerTickUInt; // 0 a 1.300 mS unsigned long int data timerTickULongInt; // 0 a 85.899.345 mS

– Tcpu-driver/tarea ≤ Tcpu-pp / 10

if (!timerTickUXxx) timerTickUXxx--; Métodos de diseño

21

Métodos de diseño

¿Cómo mejorar el método?

22

¿Cómo mejorar el método?

• Para mejorar el método es conveniente además dividir la solución en capa de software: – Capa de acceso al Hardware – Capa de Manejadores de Dispositivos – Capa de Aplicación

• Dividir la solución en capas aporta portabilidad P O R T A B L E

Aplicación

Device Drivers Core Peripheral Access Layer Device Peripheral Access Layer Access Functions for Peripherals Hardware (Core & Peripherals)

Métodos de diseño

23

Métodos de diseño

24

6

01/07/2011

TECNICAS DE PLANIFICACION SOFTWARE

Metodo de trabajo

• REALIZADO EL ESQUEMA DE PLANIFICACION DE ACTIDADES • DEBEMOS ABOCARNOS A PLANIFICAR COMO SERA EL DESARROLLO DEL SOFTWARE . • PARA ELLO CONTAMOS CON UNA HERRAMIENTA QUE NOS ORDENARA

• Planificación de tareas (Diagrama de Gantt) • Asignación Roles y Actividades • Recolección de datos y precios

UML Básico

UML •

El UML (Unified Modeling Languaje) es un lenguaje grafico para • ¿Qué es UML ? • Siglas de Unified Modeling Language. • Es el sucesor de los métodos de Análisis y Diseño Orientado a Objetos de finales de los 80 y comienzo de los 90. • ¿ Por qué modelamos?

– visualizar – especificar – construir – documentar los componentes de un sistema de gran cantidad de software. 27

28

7

01/07/2011

Por que modelamos? •

Por que modelamos?

Construimos modelos para

•

– a) comunicar la estructura deseada y el comportamiento del sistema. – b) visualizar y controlar la arquitectura del sistema. – c) comprender mejor el sistema que estamos construyendo.

Construimos modelos para – d) simplificar el sistema. – e) reutilizar herramientas diseñadas por otro o por nosotros mismos. – f) controlar el riesgo.

29

30

Orientación a Objetos vs. Modelado tradicional •

Orientación a Objetos vs. Modelado tradicional

La perspectiva algorítmica tradicional tiene:

•

– El bloque principal de la construcción de software es el procedimiento o función. – Hace a los programadores centrarse en cuestiones de control y descomposición de algoritmos grandes en otros mas pequeños.

La perspectiva algorítmica tradicional tiene: – Si cambian los requisitos (seguro cambiaran) y el sistema crece (lo hará!) los sistemas algorítmicos se hacen difíciles de mantener

31

32

8

01/07/2011 Orientación a Objetos vs. Modelado tradicional •

Ciclo de Vida de Desarrollo de software Iterativo e Incremental: Un proceso iterativo es aquel que implica gestionar una sucesión continua de versiones ejecutables • Un proceso incremental es aquel que implica la integración continua de la arquitectura del sistema para producir estas versiones, con cada nueva versión se engloban mejoras incrementales con respecto a la otra • Además, un proceso iterativo e incremental es controlado por el riesgo, lo que significa que cada nueva versión se centra en acometer y reducir los riesgos más importantes para alcanzar el éxito del proyecto

La perspectiva orientada a objetos: – Este enfoque es la tendencia actual para el desarrollo de software. – Es valido en toda clase de dominios de problemas, abarcando un abanico de tamaños y complejidades.

33

Diagramas de estados •

•

Además de la estructura estática y del comportamiento dinámico, las vistas funcionales se pueden utilizar para describir a los sistemas. Las vistas funcionales ilustran la funcionalidad que proporciona un sistema. Los casos de uso son las descripciones funcionales del sistema. Normalmente, son modelados en la etapa de análisis de requisitos para describir y capturar cómo los actores podrían utilizar un sistema. Los diagramas de casos de uso deberían capturar solamente cómo un actor puede usar un sistema, pero no cómo debe ser construido dicho sistema. Las clases y las interacciones implementan los casos de uso en el sistema. Las interacciones son expresadas en diagramas de secuencia y/o colaboración. Entonces hay un enlace entre la visión funcional y la visión dinámica del sistema. Las clases utilizadas en la implementación de los casos de uso son modeladas y descritas en los diagramas de clase, en los diagramas de estado y/o actividad.

Diagramas de estados •

• •

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

9

01/07/2011 Contador

Un ejemplo de aplicación: Contador •

Diagrama de Estados y transiciones

Contador Ascendente / Descendente RESET / cuenta = CUENTAiNICIAL

– Cuenta ascendente desde CUENTAiNICIAL  hasta CUENTAfINAL

cuenta == CUENTAfiNAL / cuenta--

– Cuenta descendente desde CUENTAfINAL  hasta CUENTAiNICIAL – Itera ASC

•

DES

Recursos cuenta < CUENTAfiNAL / cuenta++

– Variables: estado , cuenta – Defines:

ASCENDENTE, DESCENDENTE, ESTADOmAXIMO, ESTADOiNICIAL, CUENTAiNICIAL, CUENTAfINAL

cuenta > CUENTAiNICIAL / cuenta -cuenta == CUENTAiNICIAL / cuenta++

Máquinas de Estado

37

Máquinas de Estado

Contador

Contador

Tabla de Estados y Transiciones

Implementaciones posibles

Estado Actual

X

ASCENDENTE

DESCENDENTE

Excitación

Estado Futuro

Acción

RESET || estado >= ESTADOmAXIMO

ESTADOiNICIAL

cuenta = CUENTAiNICIAL

estado < ESTADOmAXIMO && cuenta < CUENTAfINAL

ASCENDENTE

cuenta++

estado < ESTADOmAXIMO && cuenta == CUENTAfINAL

DESCENDENTE

cuenta--

estado < ESTADOmAXIMO && cuenta > CUENTAiNICIAL

DESCENDENTE

cuenta--

estado < ESTADOmAXIMO && cuenta == CUENTAiNICIAL

ASCENDENTE

cuenta++

Máquinas de Estado

38

– Switch (estado) – Arrays de punteros a función (estado) – Múltiples if (estado) • Desarrolladas en esta presentación – Tablas de excitaciones & acciones (estado, excitación) • Parser – Se recomienda compararlas en la implementación del mismo caso 39

Máquinas de Estado

40

10