miércoles, 13 de junio de 2007

Metodologias Agiles (LD)

Lean Development



Lean Development (LD) es el método menos divulgado entre los reconocidamente importantes. La palabra “lean” significa magro, enjuto; en su sentido técnico apareció por primera vez en 1990 en el libro de James Womack La Máquina que Cambió al Mundo . LD, iniciado por Bob Charette, se inspira en el éxito del proceso industrial Lean Manufacturing, bien conocido en la producción automotriz y en manufactura desde la década de 1980. Este proceso tiene como precepto la eliminación de residuos a través de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo más perfecto posible.

Los procesos a la manera americana corrían con sus máquinas al 100% de capacidad y mantenían inventarios gigantescos de productos y suministros; Toyota , en contra de la intuición, resultaba más eficiente manteniendo suministros en planta para un solo día, y produciendo sólo lo necesario para cubrir las órdenes pendientes. Esto es lo que se llama Just in Time Production. Con JIT se evita además que el inventario degrade o se torne obsoleto, o empiece a actuar como un freno para el cambio. Toyota implementaba además las técnicas innovadoras del Total Quality Management de Edward Deming, que sólo algunos matemáticos y empresarios de avanzada conocían en Estados Unidos. Hasta el día de hoy la foto de Deming en Toyota es más grande y esplendorosa que la del fundador, Toyoda Sakichi.

Otros aspectos esenciales de Lean Manufacturing son la relación participativa con el empleado y el trato que le brinda la compañía, así como una especificación de principios, disciplinas y métodos iterativos, adaptativos, auto-organizativos e interdependientes en un patrón de ciclos de corta duración que tiene algo más que un aire de familia con el patrón de procesos de los MAs (http://www.strategosinc.com/principles.htm). Existe unanimidad de intereses, consistencia de discurso y complementariedad entre las comunidades Lean de manufactura y desarrollo de software.Mientras que otros MAs se concentran en el proceso de desarrollo, Charette sostenía que para ser verdaderamente ágil se debía conocer además el negocio de punta a punta. LD se inspira en doce valores centrados en estrategias de gestión

1.

Satisfacer al cliente es la máxima prioridad.

2.

Proporcionar siempre el mejor valor por la inversión.

3.

El éxito depende de la activa participación del cliente.

4.

Cada proyecto LD es un esfuerzo de equipo.

5.

Todo se puede cambiar.

6.

Soluciones de dominio, no puntos.

7.

Completar, no construir.

8.

Una solución al 80% hoy, en vez de una al 100% mañana.

9.

El minimalismo es esencial.

10.

La necesidad determina la tecnología.

11.

El crecimiento del producto es el incremento de sus prestaciones, no de su tamaño.

12.

Nunca empujes LD más allá de sus límites.

Dado que LD es más una filosofía de management que un proceso de desarrollo no hay mucho que decir del tamaño del equipo, la duración de las iteraciones, los roles o la naturaleza de sus etapas. Últimamente LD ha evolucionado como Lean Software Development (LSD); su figura de referencia es Mary Poppendieck .
Uno de los sitios primordiales del modelo son las páginas consagradas a LSD que mantiene Darrell Norton , donde se promueve el desarrollo del método aplicando el framework .NET de Microsoft. Norton ha reformulado los valores de Charette reduciéndolos a siete y suministrando más de veinte herramientas análogas a patrones organizacionales para su implementación en ingeniería de software.
Los nuevos principios son:

1.

Eliminar basura (las herramientas son Seeing Waste, Value Stream Mapping). Basura es todo lo que no agregue valor a un producto, desde la óptica del sistema de valores del cliente. Este principio equivale a la reducción del inventario en manufactura. El inventario del desarrollo de software es el conjunto de artefactos intermedios. Un estudio del Standish Group reveló que en un sistema típico, las prestaciones que se usan siempre suman el 7%, las que se usan a menudo el 13%, “algunas veces” el 16%, “raras veces” el 19% y “nunca” el 45%. Esto es un claro 80/20: el 80% del valor proviene del 20% de los rasgos. Concentrarse en el 20% útil es una aplicación del mismo principio que subyace a la idea de YAGNI.

2.

Amplificar el conocimiento (Feedback, Iterations, Synchronization, Set-based Development). El desarrollo se considera un ejercicio de descubrimiento.

3.

Decidir tan tarde como sea posible (Options Thinking, The Last Responsible Moment, Making Decisions). Las prácticas de desarrollo que proporcionan toma de decisiones tardías son efectivas en todos los dominios que involucran incertidumbre porque brindan una estrategia basada en opciones fundadas en la realidad, no en especulaciones. En un mercado que cambia, la decisión tardía, que mantiene las opciones abiertas, es más eficiente que un compromiso prematuro. En términos metodológicos, este principio se traduce también en la renuencia a planificarlo todo antes de comenzar. En un entorno cambiante, los requerimientos detallados corren el riesgo de estar equivocados o ser anacrónicos.

4.

Entregar tan rápido como sea posible (Pull Systems, Queueing Theory, Cost of Delay). Se deben favorecer ciclos cortos de diseño ? implementación ? feedback ? mejora. El cliente recibe lo que necesita hoy, no lo que necesitaba ayer.

5.

Otorgar poder al equipo (Self Determination, Motivation, Leadership, Expertise). Los desarrolladores que mejor conocen los elementos de juicio son los que pueden tomar las decisiones más adecuadas.

6.

Integridad incorporada (Perceived Integrity, Conceptual Integrity, Refactoring, Testing). La integridad conceptual significa que los conceptos del sistema trabajan como una totalidad armónica de arquitectura coherente. La investigación ha demostrado que la integridad viene con el liderazgo, la experiencia relevante, la comunicación efectiva y la disciplina saludable. Los procesos, los procedimientos y las medidas no son substitutos adecuados.

7.

Ver la totalidad (Measurements, Contracts). Uno de los problemas más intratables del desarrollo de software convencional es que los expertos en áreas específicas (por ejemplo, bases de datos o GUIs) maximizan la corrección de la parte que les interesa, sin percibir la totalidad.

Otra preceptiva algo más amplia es la de Mary Poppendieck , cuidadosamente decantadas del Lean Manufacturing y de Total Quality Management (TQM), que sólo coincide con la de Norton en algunos puntos:

1.

Eliminar basura – Entre la basura se cuentan diagramas y modelos que no agregan valor al producto.

2.

Minimizar inventario – Igualmente, suprimir artefactos tales como documentos de requerimiento y diseño.

3.

Maximizar el flujo – Utilizar desarrollo iterativo.

4.

Solicitar demanda – Soportar requerimientos flexibles.

5.

Otorgar poder a los trabajadores.

6.

Satisfacer los requerimientos del cliente – Trabajar junto a él, permitiéndole cambiar de ideas.

7.

Hacerlo bien la primera vez – Verificar temprano y refactorizar cuando sea preciso.

8.

Abolir la optimización local – Alcance de gestión flexible.

9.

Asociarse con quienes suministran – Evitar relaciones de adversidad.

10.

Crear una cultura de mejora continua.

Las herramientas, junto con el prolijo desarrollo de la metodología, se detallan en un texto de Mary y Tom Poppendieck , consistentemente encomiado por sus lectores. Igual que Agile Modeling, que cubría sobre todo aspectos de modelado y documentación, LD y LSD han sido pensados como complemento de otros métodos, y no como una metodología excluyente a implementar en la empresa. LD prefiere concentrarse en las premisas y modelos derivados de Lean Production, que hoy constituyen lo que se conoce como el canon de la Escuela de Negocios de Harvard. Para las técnicas concretas de programación, LD promueve el uso de otros MAs que sean consistentes con su visión, como XP o sobre todo Scrum.

Aunque la formulación del método es relativamente reciente, la familiaridad de muchas empresas con los principios de Lean Production & Lean Manufacturing ha facilitado la penetración en el mercado de su análogo en ingeniería de software. LD se encuentra hoy en América del Norte en una situación similar a la de DSDM en Gran Bretaña, llegando al 7% entre los MAs a nivel mundial (algo menos que Crystal pero el doble que Scrum). Existen abundantes casos de éxito documentados empleando LD y LSD, la mayoría en Canadá. Algunos de ellos son los de Canadian Pacific Railway, Autodesk y PowerEx Corporation. Se ha aplicado prácticamente a todo el espectro de la industria.

viernes, 18 de mayo de 2007

practica#1

Diseño de Sistemas

El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones). El proceso de diseño de un sistema complejo se suele realizar de forma descendente:

  • Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).
  • Diseño e implementación de cada uno de los subsistemas:
    • Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis.
    • Desarrollo según la especificación.
    • Prueba.
  • Integración de todos los subsistemas.
  • Validación del diseño.

Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo. En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente. De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento). Así, con respecto al diseño de herramientas software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilización de lenguaje natural, etc.

La Ingeniería de Software es el establecimiento y uso de principios de ingeniería para obtener software que sea confiable y que funcione eficientemente en máquinas reales.

La Ingeniería de Software es relativamente nueva ya que aparece a finales de los años sesenta y principios de los setenta, comenzando con las Técnicas de Programación Estructurada, incorporándolas a las fases del ciclo vital de software. La Programación Estructurada fue seguida por otros métodos estructurados de análisis y también métodos estructurados de diseño. Además, comenzaron a usarse tecnologías orientadas a objetos. En un principio la programación era la tarea de oro de la Ingeniería de Software pero ahora la ingeniería y el diseño de requisitos son más importantes.

En los años noventa la gerencia de proyecto ganó interés y llegó a ser un componente importante en la Ingeniería de Software. En la década pasada, los estándares de la Ingeniería de Software y la madurez de proceso han caracterizado la industria del software como una disciplina madura.

En un nivel más técnico, la Ingeniería de Software comienza con una serie de tareas que hacen modelos y que resultan en una especificación completa de requisitos y una representación comprensiva de diseño del software que será construído. Se han desarrollado muchos métodos para hacer modelos de sistemas de información. Sin embargo, los métodos Orientados a Objeto (OO) van a llegar a ser el estándar.

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.

Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

¿Qué es lo que hace?

¿Cómo se hace?

¿Con que frecuencia se presenta?

¿Qué tan grande es el volumen de transacciones o decisiones?

¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:

1). La división del sistema en componentes

2). La construcción de un modelo del sistema.

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

Componentes

Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado.

Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

Reglas: estándares para describir y documentar el sistema en forma correcta y completa.

Diseño Estructurado.

El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.

El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.

Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

Análisis de flujo de datos.

Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.

Herramientas

Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.

Diagrama de flujo de datos

Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes.

El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.

El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos.

El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas.

Notaciones: son cuatro símbolos, que fueron desarrollados y promovidos la mismo tiempo por dos organizaciones: Yourdon y Gane y Sarson.

Flujo de datos: son movimientos de datos en una determinada dirección, desde un origen hasta un destino. Es un paquete de datos.

MÉTODO DEL PROTOTIPO DE SISTEMAS

La construcción de prototipos representa una estrategia de desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso.

Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.

Así mismo este método resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación. El método del prototipo de sistemas consta de 5 etapas:

1). Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es tan importante para el m‚todo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.

2). Desarrollo de un modelo de trabajo: Es fácil comenzar el procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interacción es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes:

a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.

b). Pantallas y formatos para la entrada de datos.

c). Módulos esenciales de procesamiento.

d). Salida del sistema

3). Utilización del prototipo: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas

4). Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.

Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.

5). Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.

Definición de Base de Datos

Se define una base de datos como una serie de datos organizados y relacionados entre sí, los cuales son recolectados y explotados por los sistemas de información de una empresa o negocio en particular.

Las bases de datos proporcionan la infraestructura requerida para los sistemas de apoyo a la toma de decisiones y para los sistemas de información estratégicos, ya que estos sistemas explotan la información contenida en las bases de datos de la organización para apoyar el proceso de toma de decisiones o para lograr ventajas competitivas. Por este motivo es importante conocer la forma en que están estructurados las bases de datos y su manejo.

Los modelos de datos

En el proceso de abstracción que conduce a la creación de una base de datos desempeña una función prioritaria el modelo de datos. El modelo de datos, como abstracción del universo de discurso, es el enfoque utilizado para la representación de las entidades y sus características dentro de la base de datos, y puede ser dividido en tres grandes tipos (KORTH y SILBERSCHATZ, 1993: 6-11):

1. Modelos lógicos basados en objetos: los dos más extendidos son el modelo entidad-relación y el orientado a objetos. El modelo entidad-relación (E-R) se basa en una percepción del mundo compuesta por objetos, llamados entidades, y relaciones entre ellos. Las entidades se diferencian unas de otras a través de atributos. El orientado a objetos también se basa en objetos, los cuales contienen valores y métodos, entendidos como órdenes que actúan sobre los valores, en niveles de anidamiento. Los objetos se agrupan en clases, relacionándose mediante el envío de mensajes. Algunos autores definen estos modelos como "modelos semánticos".

2. Modelos lógicos basados en registros: el más extendido es el relacional, mientras que los otros dos existentes, jerárquico y de red, se encuentran en retroceso. Estos modelos se usan para especificar la estructura lógica global de la base de datos, estructurada en registros de formato fijo de varios tipos. El modelo relacional representa los datos y sus relaciones mediante tablas bidimensionales, que contienen datos tomados de los dominios correspondientes. El modelo de red está formado por colecciones de registros, relacionados mediante punteros o ligas en grafos arbitrarios. El modelo jerárquico es similar al de red, pero los registros se organizan como colecciones de árboles. Algunos autores definen estos modelos como "modelos de datos clásicos".

3. Modelos físicos de datos: muy poco usados, son el modelo unificador y el de memoria de elementos. Algunos autores definen estos modelos como "modelos de datos primitivos".

Los objetivos del modelo de datos son dos:

1. Formalización: definir formalmente las estructuras permitidas y las restricciones a fin de representar los datos de un SI.

2. Diseño: el modelo resultante es un elemento básico para el desarrollo de la metodología de diseño de la base de datos.

Los diferentes modelos de datos comparten, aunque con diferentes nombres y notaciones, unos elementos comunes, componentes básicos de la representación de la realidad que realizan. Estos componentes se identifican gracias a la clasificación, y pueden identificarse conceptos estáticos y conceptos dinámicos.