Trabajo investigativo No. 04 Análisis de sistemas · Esto se aplica con metodologías que permiten...
53
Trabajo investigativo No. 04 Análisis de sistemas Presentado por: Camilo Esteban Rodriguez Forero. Andres Mauricio Clavijo. Jhon Alexander Chacon Torres. Brayan Andrés Valero Pinzón. Presentado a: Juan Carlos Guevara Bolaños. Universidad Distrital Francisco José de Caldas. Sistematización de datos. Facultad Tecnológica. Bogotá D.C. Colombia, jueves 10 de marzo 2016.
Transcript of Trabajo investigativo No. 04 Análisis de sistemas · Esto se aplica con metodologías que permiten...
Trabajo investigativo No. 04
Análisis de sistemas
Presentado por:
Camilo Esteban Rodriguez Forero.
Andres Mauricio Clavijo.
Jhon Alexander Chacon Torres.
Brayan Andrés Valero Pinzón.
Presentado a:
Juan Carlos Guevara Bolaños.
Universidad Distrital Francisco José de Caldas.
Sistematización de datos.
Facultad Tecnológica.
Bogotá D.C. Colombia, jueves 10 de marzo 2016.
Contenido
1. Introducción.
2. Conceptos.
2.1. Paradigma de software.
2.2. Metodología de desarrollo de software.
2.3. Método de desarrollo de software.
3. Describir los diferentes tipos de clasificación de metodologías de
software.
4. Describir 2 metodologías estructuradas.
4.1. Nombre.
4.2. Características.
4.3. Etapas.
4.4. Diagramas utilizados en cada etapa.
4.5. Ejemplo explicativo.
5. Describir 4 metodologías iterativas e incrementales.
5.1. Nombre.
5.2. Características.
5.3. Etapas.
5.4. Diagramas utilizados en cada etapa.
5.5. Ejemplo explicativo.
6. Describir 4 metodologías ágiles.
6.1. Nombre.
6.2. Características.
6.3. Etapas.
6.4. Diagramas utilizados en cada etapa.
6.5. Ejemplo explicativo.
7. Conclusiones.
8. Bibliografía.
Introducción
El presente trabajo consta de un organizado seguimiento del software, en áreas que
componen el mismo, algunos conceptos y con estos un esquema que permite al
usuario mejorar las técnicas y métodos de producción de proyectos de software un
poco más estructurados. Esto se aplica con metodologías que permiten el desarrollo
del software de una manera más detallada y según las seleccionada con muchas
más características.
Conceptos
Paradigma de software
Los paradigmas de Software son métodos y pasos, que se llevan a cabo
mientras el software se diseña. Hay muchos métodos que se han propuesto y
que funcionan hoy en día, pero necesitamos ver donde se ubican estos
paradigmas en el marco de la Ingeniería de software. Estos se pueden
combinar en varias categorías, en las que cada uno de ellos contiene a la
otra:
Metodología de desarrollo de software
Se describe como el conjunto de herramientas, técnicas, procedimientos y
soporte documental para el diseño de Sistemas de información.
Particularmente, una metodología se basa en una combinación de los
modelos de proceso genéricos para obtener como beneficio un software que
solucione un problema. Adicionalmente una metodología debería definir con
precisión los artefactos, roles y actividades, junto con prácticas, técnicas
recomendadas y guías de adaptación de la metodología al proyecto. Sin
embargo, la complejidad del proceso de creación de software es netamente
dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento
de la metodología estará acorde al nivel de aporte del proyecto, ya sea
pequeño, mediano o de gran nivel.
Método de desarrollo de software
Es un método que permite aumentar la calidad del software a desarrollar,
esto en cuanto a características de seguridad, facilidad del sistema entre
otros; además reducen el costo del software, se evitan ciertos costos por
características del programa o por tiempo y finalmente aumentan su poder,
debido a que estos usan ciertas programaciones algo rigurosas.
Descripción de tipos de clasificación de metodologías de software
Estructuradas: Proponen la creación de modelos del sistema que
representan: los procesos, los flujos, la estructura de datos.
Orientadas a procesos : Los datos se introducen en el sistema y el mismo
responde ante ellos, transformándolos para obtener la salida.
Jerárquicas : La estructura de control del programa debe ser jerárquica y se
debe derivar de la estructura de datos del programa.
No jerárquicas: Se centran en la creencia de que esta metodología
identifique con éxito la naturaleza de los datos de una organización.
Mixtas: Cubren con más amplitud el proceso de desarrollo y utilizan técnicas
que estudian los sistemas desde varios puntos de vista, tanto en la visión de
los procesos o funciones del sistema, las estructuras de los datos, el estudio
de eventos, etc.
Orientadas a objetos: Modelado del sistema examinando el dominio del
problema como un conjunto de objetos que interactúan entre sí. Los objetos
encapsulan funciones más datos.
Para sistemas de tiempo real: Sistemas que controlan un ambiente
recibiendo datos, procesándolos y devolviendolos con la suficiente rapidez
como para influir en dicho ambiente en ese momento.
Describir 2 metodologías estructuradas
Las metodologías estructuradas se basan en la estructuración y
descomposición funcional de problemas en unidades más pequeñas
interrelacionadas entre sí. Representan los procesos, flujos y estructuras de
datos, de una manera jerárquica y ven el sistema como
entradasprocesosalidas.
Nombre :
Metodología SSADM.
Características :
Es un enfoque de sistemas para el análisis y diseño de sistemas de
información. Una de las principales características de SSADM es la
participación intensiva de los usuarios en la etapa de análisis de requisito y
proporciona un conjunto de procedimientos para llevar a cabo el análisis y
diseño, pero no cubre aspectos como la planificación estratégica ni entra en
la construcción del código.
Los aspectos claves de esta metodología son:
1. Énfasis en los usuarios: sus requisitos y participación.
2. Definición del proceso de producción.
3. Tres puntos de vista: datos, eventos y procesos.
4. Máxima flexibilidad en herramientas y técnicas de implementación.
Etapas:
Estudio de Viabilidad.
Definición del problema.
Identificación del proyecto.
Análisis:
Análisis del sistema actual.
Especificación de requerimientos.
Selección de opciones técnicas.
Diseño:
Diseño de datos.
Diseño de procesos.
Diseño físico.
Diagramas utilizados en cada etapa:
EVS
Ejemplo explicativo:
La metodología SSADM se aplicará a la empresa Almagister especialmente
en el departamento de dirección académica, enfocado en el proceso de
inscripción de los estudiantes de los distintos cursos.
Fase 0: estudio de viabilidad ¿El proyecto es técnicamente posible? ¿La
empresa puede llevarlo a cabo financieramente? ¿El nuevo sistema será
compatible con las prácticas actuales? ¿Será aceptado socialmente el nuevo
sistema?
Fase 1: Investigación del entorno actual La información de la situación actual
se representa por medio de diagramas.
Fase 2: Opciones del sistema de negocios.
Fase 3: Especificación de requisitos A nivel de usuario:
Crear cuentas de usuarios.
Matricular cursos.
Abandonar cursos.
Modificar datos personales.
Enviar mensajes a otros usuarios.
Visualizar e imprimir historial de cursos realizados.
Participar en foros realizar evaluaciones.
Publicar y descargar archivos .
A nivel de la empresa:
Registrar en la base de datos a los nuevos usuarios Administrar listado e
información de usuarios.
Permitir o negar matriculación de los nuevos usuarios.
Enviar mensajes a los usuarios.
Activar foros para los usuarios.
Publicar y descargar archivos.
Publicar y guardar evaluaciones.
Eliminar o bloquear usuarios.
Fase 4 : opciones técnicas del sistema.
Fase 5: diseño lógico.
Fase 6: diseño físico.
Nombre:
Métrica V3.
Características:
1. Proporcionar o definir Sistemas de Información que sirvan a la
consecución de los fines de la Organización mediante la definición de
un marco estratégico para el desarrollo de los mismos.
2. Dotar a la Organización de Productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al análisis
de requisitos.
3. Mejorar la productividad permitiendo una mayor capacidad de
adaptación a los cambios y teniendo en cuenta la reutilización en la
medida de lo posible.
4. Facilitar la comunicación y entendimiento entre los distintos
participantes en la producción de software a lo largo de todo el ciclo de
vida.
5. Facilitar la operación, mantenimiento y uso de los Productos software
obtenidos.
Etapas:
Plan de sistemas de información.
Análisis de Sistemas.
Diseño del sistema.
Construcción de Sistemas.
Implementación de sistemas.
Diagramas utilizados en cada etapa:
PSI
ASI
DSI
CSI
IAS
Ejemplo explicativo:
Se determinará la necesidad del Sistema de Gestión Telefónica,
proporcionando una definición inicial del mismo.
Muestra todos los aspectos referentes a nuestra aplicación realizando una
especificación y un análisis detallado del sistema.
Estudio de Viabilidad del Sistema(EVS)
Mediante este estudio se pretende descubrir las necesidades que tiene el
Servicio de Tecnologías de la Información y las Comunicaciones del
Ayuntamiento X para el desarrollo del Sistema de Gestión Telefónica.
En ningún momento se contempla la adquisición de un software comercial,
puesto que las necesidades que tienen son muy específicas y prefieren
utilizar los medios de los que disponen y realizar una aplicación que cubra
todas sus necesidades.
Se sientan las bases de cómo será el Plan de desarrollo de la Aplicación
Gestión Telefónica. Los tres primeros meses se destinarán al análisis y
Diseño del Sistema y después de su aprobación se pasará a la fase de
Construcción del Sistema.
Análisis del Sistema de Información (ASI)
En esta tarea se presenta una descripción a alto nivel del sistema. Se
presentarán las principales áreas de negocio a las cuales el sistema debe dar
soporte, las funciones que el sistema debe realizar, la información utilizada,
las restricciones y otros factores que afectan al desarrollo del mismo.
En términos generales, el sistema deberá proporcionar soporte a las
siguientes tareas de Gestión Telefónica:
Gestión de usuarios.
Gestión de departamentos.
Gestión de dispositivos.
Gestión de extensiones telefónicas.
Gestión de proveedores de telefonía.
Gestión de líneas telefónicas.
Gestión de solicitudes de telefonía.
Gestión de facturas de telefonía.
Gestión de partidas presupuestarias.
Gestión de servicios de telefonía.
Diseño del Sistema de Información (DSI)
Este proceso consta de un primer bloque de actividades, que se realizan en
paralelo, y cuyo objetivo es obtener el diseño de detalle del sistema de
información que comprende la partición física del sistema de información,
independiente de un entorno tecnológico concreto, la organización en
subsistemas de diseño, la especificación del entorno tecnológico sobre el que
se despliegan dichos subsistemas y la definición de los requisitos de
operación, administración del sistema, seguridad y control de acceso. En el
caso de diseño orientado a objetos, conviene señalar que se ha contemplado
que el diseño de la persistencia se lleva a cabo sobre bases de datos
relacionales.
De este primer bloque de actividades se obtienen los siguientes
productos:
Catálogo de requisitos (se completa).
Catálogo de excepciones.
Catálogo de normas para el diseño y construcción.
Diseño de la arquitectura del sistema.
Entorno tecnológico del sistema.
Procedimientos de operación y administración del sistema.
Procedimientos de seguridad y control de acceso.
Diseño detallado de los subsistemas de soporte.
Modelo físico de datos optimizado.
Asignación de esquemas físicos de datos a nodos.
Construcción del Sistema de Información (CSI)
Es en este proceso donde se lleva a cabo la construcción de los
componentes de migración y procedimientos de migración y carga inicial de
datos si fuera necesario.
Como resultado de dicho proceso se obtiene:
Resultado de las pruebas unitarias.
Evaluación del resultado de las pruebas de integración.
Evaluación del resultado de las pruebas del sistema.
Producto software:
Código fuente de los componentes
Procedimientos de operación y administración del sistema.
Procedimientos de seguridad y control de acceso.
Manuales de usuario.
Especificación de la formación a usuarios finales.
Código fuente de los componentes de migración y carga inicial
de datos.
Procedimientos de migración y carga inicial de datos.
Evaluación del resultado de las pruebas de migración y carga
inicial de datos.
Implantación y Aceptación del Sistema (IAS)
Se toman como punto de partida los componentes del sistema probados de
formas unitarias e integradas en el proceso Construcción del Sistema de
Información (CSI), así como la documentación asociada. El Sistema se
someterá a las Pruebas de Implantación con la participación del usuario de
operación cuya responsabilidad, entre otros aspectos, es comprobar el
comportamiento del sistema bajo las condiciones más extremas. También se
someterá a las Pruebas de Aceptación cuya ejecución es responsabilidad del
usuario final.
En este proceso se elabora el plan de mantenimiento del sistema de forma
que el responsable del mantenimiento conozca el sistema antes de que éste
pase a producción.
También se establece el acuerdo de nivel de servicio requerido una vez que
se inicie la producción. El acuerdo de nivel de servicio hace referencia a
servicios de gestión de operaciones, de soporte a usuarios y al nivel con el
que se prestarán dichos servicios.
Como resultado de este proceso se obtienen los siguientes productos:
Plan de implantación del sistema en su totalidad.
Equipo de implantación que realizará la implantación.
Plan de formación del equipo de implantación (esquema, materiales,
recursos necesarios, planificación y especificación de la formación de
usuarios finales).
Evaluación de las pruebas de implantación del sistema por parte del
usuario de operación.
Evaluación de las pruebas de aceptación del sistema por parte del
usuario final.
Plan de mantenimiento previo al paso a producción.
Acuerdo de nivel de servicio del sistema.
Sistema en producción.
Describir 4 metodologías iterativas e incrementales
Nombre.
Metodología incremental
Características.
∙ Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta
frecuencia.
∙ El usuario se involucre más.
∙ Difícil de evaluar el costo total.
∙ Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
∙ Requiere gestores experimentados.
∙ Los errores en los requisitos se detectan tarde.
∙ El resultado puede ser muy positivo.
Etapas.
Este modelo tiene las siguientes etapas:
1. DEFINICIÓN DEL PROBLEMA y ANÁLISIS DE REQUERIMIENTOS
Es una situación por resolver, algo que debe ser mejorado o solucionado.
Es común decir que no hay investigación sin un “problema” y que un problema bien
planteado es mejor que cualquier solución gratuita.
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual
se le va a presentar la solución de esta.
Es una condición o necesidad de un usuario para resolver un problema o alcanzar
un objetivo.
Un requerimiento es simplemente una declaración abstracta de alto nivel de un
servicio que debe proporcionar el sistema o una restricción de éste.
2. DISEÑO GLOBAL
Es un diseño general del problema planteado, es la elaboración en la búsqueda de
una solución en cualquier campo, teniendo en cuenta los parámetros y análisis de
requerimientos que se hayan obtenido para el desarrollo de un resultado acorde con
el problema.
Permite describir cómo el sistema va a satisfacer los requerimientos. Esta etapa a
menudo tiene diferentes niveles de detalle. Los niveles más altos de detalle
generalmente describen los componentes o módulos que formarán el software a ser
producido. Los niveles más bajos, describen, con mucho detalle, cada módulo que
contendrá el sistema.
Es un diseño piloto, se hace para presentar una opciòn al cliente con capacidad de
modificaciòn.
sus puntos son:
3. Codificación o programación
Aquí es donde el software a ser desarrollado se codifica. Dependiendo del tamaño
del proyecto, la programación puede ser distribuida entre distintos programadores o
grupos de programadores. Cada uno se concentrará en la construcción y prueba de
una parte del software, a menudo un subsistema. Las pruebas, en general, tiene por
objetivo asegurar que todas las funciones están correctamente implementadas
dentro del sistema.
4. Prueba
Esta situación nos permite comprobar las cualidades y la calidad de la solución
planteada
para tener varias opciones o dependiendo solo una, para demostrar la
circunstancias de nuestro método.
Entrega
Ya teniendo todos los aspectos anteriores debidamente organizados y teniendo en
cuenta la
operación del proceso y el resultado de cada uno de sus pasos elaboramos
conclusiones y resolvemos los estados sucesivos de desarrollo para la solución del
problema que se definió
en el comienzo del modelo.
Diagramas utilizados en cada etapa.
Ejemplo explicativo.
Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría
aportar, en principio, funciones básicas de edición de archivos y producción de
documentos (algo como un editor simple).
En un segundo incremento se le podría agregar edición más sofisticada, y
degeneración y mezcla de documentos. En un tercer incremento podría
considerarse el agregado de funciones de corrección ortográfica, esquemas de
paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones
matemáticas. Así sucesivamente hasta llegar al procesador final requerido. Así, el
producto va creciendo, acercándose a su meta final, pero desde la entrega del
primer incremento ya es útil y funcional para el cliente, el cual observa una
respuesta rápida en cuanto a entrega temprana; sin notar que la fecha límite del
proyecto puede no estar acotada ni tan definida, lo que da margen de operación y
alivia presiones al equipo de desarrollo.Como se dijo, el Iterativo Incremental es un
modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios
en los requisitos en tiempo de desarrollo; se admite cierto margen para que el
software pueda evolucionar. Aplicable cuando los requisitos son medianamente bien
conocidos pero no son completamente estáticos y definidos.Con cada incremento se
agrega nueva funcionalidad o se cubren nuevos requisitos bien se mejora la versión
previamente implementada del producto software. Este Modelo brinda cierta
flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por
parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e
implementarse como un nuevo incremento o, eventualmente,podrá constituir una
mejora/adecuación de uno ya planeado.
Nota: Una evolución de este enfoque se conoce como Programación Extrema
(XPExtreme Programming).
Nombre.
Modelo en espiral
Características.
∙ Es un modelo que puede combinarse con otros modelos de procesos de desarrollo
(cascada y evolutivo).
∙ Es el mejor modelo que se utiliza para desarrollar grandes sistemas.
∙ El análisis de riesgo requiere la participación de personal con experiencia.
∙ VENTAJAS
∙ Modelo de proceso adaptable.
∙ El modelo de espiral puede aplicarse a lo largo de la vida del software.
∙ Es apropiado para desarrollar Sistemas Operativos.
Etapas.
Comunicación con el cliente: esta es una tarea requerida para establecer
comunicación entre el desarrollador y el cliente.
Planificación: esta tarea es necesaria aplicarla para poder definir los recursos, el
tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los
requerimientos.
Análisis De Riesgos: esta es una de las tareas principales por lo que se aplica el
modelo en espiral, es requerida para evaluar los riesgos técnicos y otras
informaciones relacionadas con el proyecto.
Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más
representaciones de la aplicación.
Construcción y adaptación: esta tarea es requerida en el modelo espiral porque
se necesita construir, probar, instalar y proporcionar soporte al usuario.
Evaluación del cliente: esta también es una tarea principal, necesaria para adquirir
la reacción del cliente según la evaluación de las representaciones del software
creadas durante la etapa de ingeniería y la de implementación creada durante la
etapa de instalación.
Diagramas utilizados en cada etapa.
Ejemplo explicativo.
es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa
de construcción de prototipos con los aspectos controlados y sistemáticos del
modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de
versiones incrementales del software. En el modelo espiral, el software se desarrolla
en una serie de versiones incrementales. Durante las primeras iteraciones, la
versión incremental podría ser un modelo en papel o un prototipo. Durante las
últimas iteraciones, se producen versiones cada vez más completas del sistema
diseñado.
El modelo en espiral se divide en un número de actividades de marco de trabajo,
también llamadas regiones de tareas. Generalmente, existen entre tres y seis
regiones de tareas.
El Modelo Espiral es particularmente apto para el desarrollo de Sistemas Operativos
(complejos); también en sistemas de altos riesgos o críticos (Ej. navegadores y
controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte
gestión del proyecto y sus riesgos, técnicos o de gestión
Nombre.
Metodología modelo de prototipos.
Características.
∙ Describe las fases principales de desarrollo de software.
∙ Define las fases primarias esperadas de ser ejecutadas durante esas fases.
∙ Ayuda a administrar el progreso del desarrollo del software
∙ Provee un espacio de trabajo para la definición de un detallado proceso de
desarrollo de software.
∙ Reduce el riesgo de construir productos que no satisfagan las necesidades de los
usuarios
∙ Reduce costo y aumenta la probabilidad de éxito
∙ Exige disponer de las herramientas adecuadas
∙ Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
∙ También ofrece un mejor enfoque cuando el responsable del desarrollo del
software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debería tomar la interacción humanomáquina.
Etapas.
Comunicación: tener una interacción con el cliente para evaluar la petición del software y determinar
si el programa a desarrollar es un buen candidato para construir un prototipo.Debido
a que el cliente debe interaccionar con el prototipo para determinar el refinamiento
del proyecto
Plan rápido: cuando se tienen que los resultados de un proyecto son aceptables, se procede a
desarrollar una representación abreviada de los requerimientos.Antes de que pueda
comenzar la construcción de un prototipo, en este se debe representar los dominios
funcionales y de información del programa. La aplicación de estos principios de
análisis fundamentales, pueden realizarse mediante los métodos de análisis de
requerimientos.
Modelado diseño rápido: Después de que se haya revisado la representación de los requerimientos, se crea
un conjunto de especificaciones de diseño abreviadas para el prototipo.El diseño
debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el
diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior
y a los aspectos de diseño de datos.
Construcción de prototipo: El software del prototipo se crea, prueba y se corrigen Idealmente todos los posibles
errores, los bloques de construcción de software preexisten se utilizan para crear el
prototipo de una forma rápida y se determina si un prototipo es funcional o no. Para
las aplicaciones interactivas con el hombre,es posible frecuentemente crear un
prototipo en papel que describa la interacción hombremaquina.
Desarrollo y entrega:
Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la
prueba" de la aplicación y sugiere modificaciones. Este paso es el núcleo del
método de construcción de prototipo. Es aquí donde el cliente puede examinar una
representación implementada de los requerimientos del programa, sugerir
modificaciones que harán al programa cumplir mejor las necesidades reales.
Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén
formalizados o hasta que el prototipo haya evolucionado hacia un sistema de
producción.
Diagramas utilizados en cada etapa.
Ejemplo explicativo.
Prototipo informático para la evaluación de la calidad de la educación superior
Definición del Problema: Las universidades necesitan desarrollar procesos de evaluación institucional de desempeño, que conllevan a la revisión de sus estructuras funcionales y al
conocimiento diagnóstico de la situación actual con el fin de incrementar los niveles de eficacia, eficiencia y efectividad de la gestión universitaria. Es necesario fomentar procesos de evaluación en función de optimizar el uso de los recursos humanos, tecnológicos y financieros disponibles en la institución a objeto de lograr un desarrollo más armónico y planificado, en atención a una estricta observación de su misión. Bajo esta perspectiva se ofrece una propuesta de Prototipo Informático para la Evaluación de la Calidad de la Educación Superior, cuyos objetivos, entre otros, son: fomentar e incentivar la cultura de evaluación de la calidad universitaria; diseñar indicadores de gestión universitaria para dicho sistema de información, para cada uno de los ámbitos: académico, investigación, extensión y administrativo. Para el desarrollo, se aplicarán las herramientas y técnicas para levantar los requerimientos de usuario, y producir las salidas que satisfagan las necesidades de información y el acceso en forma integrada a la misma; respecto a los diferentes niveles de la pirámide organizacional, accesibilidad a indicadores de gestión de calidad universitaria a través de módulos interdependientes; esto es, cada nivel con su vista de usuario en la base de datos. Se aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el diseño de base de datos relacional. El prototipo está diseñado bajo una interfaz gráfica para interactuar con el usuario a través de botones programables y la navegación del sistema se realizará a través de pantallas tipo ventanas VER EJEMPLO COMPLETO: https://sistemas2009unl.wordpress.com/prototiposinformaticos/
Nombre.
Proceso Racional Unificado o RUP
Características.
∙ Ser iterativo e incremental. Resulta muy práctico dividir el trabajo en piezas o
miniproyectos.
∙ Centrado en la arquitectura. Nos da la forma del sistema y debe diseñarse de
forma que este pueda evolucionar no únicamente de su desarrollo inicial, sino en
futuras generaciones.
∙ Los casos de uso. Representan los requerimientos base para el desarrollo del
sistema, constituyen el punto de partida para las tareas de análisis y diseño y son la
fuente para que el equipo de pruebas construya los casos de pruebas.
El RUP permite
∙ Describir la organización, documentación, funcionalidad y restricciones de un
software.
∙ Documentar y registrar las decisiones que se tomen para el desarrollo de un
software.
∙ Implementar los diferentes diagramas de UML, dando paso a la reducción de
tiempo a la hora de desarrollar un software.
∙ Además, el RUP da cabida a las mejoras de las siguientes prácticas en el
desarrollo de un software:
Administrar los Requerimientos:
∙ Esta práctica permite documentar, agilizar, mejorar los requerimientos obtenidos
para el desarrollo de un software, es sin duda una metodología que ayuda a insertar
nuevos cambios a un sistema de información (actualizaciones).
Implementar arquitecturas basadas en Componentes:
∙ Como es de saberse, antes de realizar el desarrollo completo de un aplicativo, es
necesario realizar un modelo a escala del mismo, pues bien, el RUP ofrece
herramientas basadas en los componentes del sistema a implementar, dando vía al
modelamiento seguro del mismo.
Modelar Visualmente el Software:
∙ El RUP permite mostrar en una GUI el modelo de software desarrollado,
permitiendo al desarrollador mostrar errores y poder corregirlos, sin duda, la interfaz
gráfica da vida al sistema y es ella quien me permite realizar modificaciones.
Verificar la Calidad de Software:
∙ El verificar la calidad del producto realizado, es una práctica que sustenta el
desarrollo del mismo, el RUP, como herramienta colaboradora, ofrece formas de
diseño, implementación, ejecución, entre otras del software, antes de que éste sea
implementado. En pocas palabras, permite realizar testing al aplicativo.
Controlar los Cambios realizados al Software:
∙ El RUP además de ofrecer herramientas para el desarrollo y análisis, permite
también suministrar recursos que sean ajustables a los posibles cambios que pueda
sufrir el software, ya sea de actualización o innovación del mismo.
Etapas.
Fases del Modelo RUP
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones
en número variable según el proyecto y en las que se hace un mayor o menor
hincapié en los distintas actividades.
• Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión
muy general de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
• Elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificación de los casos de uso seleccionados y el primer análisis del dominio del
problema, se diseña la solución preliminar.
• Construcción
El propósito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.
• Transición
El propósito de esta fase es asegurar que el software esté disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe
verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.
Diagramas utilizados en cada etapa.
Ejemplo explicativo.
La metodología rup es una de las más utilizadas para la realización de proyectos,
esto debido a su facilidad de desarrollo, además porque está compuesta por
iteraciones.
Ejemplo.
El objetivo de esta página web es mostrar un ejemplo de desarrollo de software
basado en la metodología de Rational Unified Process (RUP). El proyecto es el
desarrollo de un sistema para la gestión de artículos deportivos de una empresa del
sector de ventas de deportes a clientes tanto a mayoristas como a minoristas. Se
incluye hasta la segunda iteración de la fase de construcción, según la división
establecida en el documento Plan de Desarrollo Software. Por motivos de privacidad
no se pueden publicar los datos de la entidad para la que se diseñó el software.
Gracias a la metodología rup el desarrollo e implementación este problema es
realizable de manera mas comoda.
En el ejemplo planteado se analizan los requerimientos, se hace un análisis y diseño
del problema una vez hecho esto se procede a la etapa de implementación luego
prueba y desarrollo, todo esto mediante iteraciones lineales concurrentes.
Describir 4 metodologías ágiles
Nombre:
SCRUM
Características:
Enfatiza valores y prácticas de gestión, sin pronunciarse sobre
requerimientos, prácticas de desarrollo, implementación y demás
cuestiones técnicas.
Hace uso de Equipos autodirigidos y autoorganizados.
Puede ser aplicado teóricamente a cualquier contexto en donde un
grupo de gente necesita trabajar junta para lograr una meta común.
Desarrollo de software iterativos incrementales basados en prácticas
ágiles.
Iteraciones de treinta días; aunque se pueden realizar con más
frecuencia, estas operaciones, conocidas como Sprint.
Dentro de cada Sprint se denomina el Scrum Master al Líder de
Proyecto quien llevará a cabo la gestión de la iteración.
Etapas:
1. Reunión de planificación de Sprint
El trabajo a realizar en el Sprint se prevé en la Reunión de Planificación del
Sprint. Este plan se crea con la colaboración de todo el Equipo Scrum.
La reunión de planificación de un Sprint es un evento de tiempo variable.
Para un Sprint de un mes tiene ocho horas de duración. Para Sprints más
cortos, el evento es proporcionalmente más corto. Por ejemplo, para un
Sprint de dos semanas, las reuniones de planificación de Sprint son de cuatro
horas de duración.
2. El Scrum Diario
Es un evento de 15 minutos, cuyo objetivo es que el equipo de desarrollo
sincronice actividades, y cree un plan para las próximas 24 horas. Esto
se realiza mediante la inspección del trabajo desde el último Scrum Diario, y
la previsión del trabajo que se puede hacer antes del próximo. El Scrum
Diario se lleva a cabo en la misma hora y lugar cada día para reducir la
complejidad.
El equipo de desarrollo utiliza elScrum Diario para evaluar el progreso hacia
la meta del Sprint y evaluar la tendencia del progreso en finalizar el trabajo en
el Sprint Backlog. Cada día, el equipo de desarrollo debe ser capaz de
explicar al dueño del producto y al Scrum Master como van a trabajar juntos
como un equipo autoorganizado para lograr el objetivo y crear el incremento
previsto en el resto del Sprint.
3. Trabajo de desarrollo durante el Sprint
Cuando el sprint está en curso, debemos asegurar que:
No se realizan cambios que afectan al objetivo del Sprint.
No disminuyen los objetivos de calidad.
El Alcance podrá aclararse y renegociarse entre el propietario del
producto y el Equipo de Desarrollo a medida que se va
aprendiendo.
Cuando un Sprint es demasiado largo, la definición de lo que se está
construyendo puede cambiar, puede aumentar la complejidad y puede
aumentar el riesgo. Los Sprints permiten previsibilidad al garantizar la
inspección y la adaptación de los avances hacia una meta de por lo menos
cada mes de calendario.
4. Revisión del Sprint
Se lleva a cabo al final del Sprint, para inspeccionar el incremento y adaptar,
si es necesario, el Product Backlog. El Equipo Scrum y las partes
interesadas colaboran durante la revisión de lo que se hizo en el Sprint.
Basado en ese y cualquier cambio en el Product Backlog durante el Sprint,
los asistentes trabajan en las próximas cosas que se podrían hacer. Esta es
una reunión informal, y la presentación del incremento está destinada a
obtener retroalimentación y fomentar la colaboración.
La revisión de Sprint incluye los siguientes elementos:
Los asistentes son el Equipo Scrum y los interesados clave invitados por
el Dueño de Producto;
El propietario del producto identifica lo que se ha “hecho” y lo que no se
ha “hecho”;
El equipo de desarrollo discute lo que anduvo bien durante el Sprint, qué
problemas hubo y cómo se resolvieron;
El equipo de desarrollo demuestra el trabajo que se ha “hecho” y
responde preguntas sobre el Incremento;
El propietario del producto analiza el estado actual del Product Backlog, y
estima fechas de finalización basado en el progreso hasta la fecha, y,
Todo el grupo colabora en qué hacer a continuación, de modo que la
revisión del Sprint ofrece valiosos aportes a las subsiguientes reuniones
de planificación de Sprint.
Se hace una revisión de cómo el mercado o el uso potencial del producto
podría haber cambiado lo que es de más valor para hacer a continuación;
y, Se hace una revisión de la línea de tiempo, presupuesto, capacidades
potenciales y mercado para la próxima entrega prevista del producto.
5. Retrospectiva del Sprint
Es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y
crear un plan de mejoras para ejecutar durante el siguiente sprint. El
propósito de la retrospectiva de Sprint es:
Revisar cómo fue el último Sprint en lo que respecta a las personas,
relaciones, procesos y herramientas;
Identificar y ordenar los temas principales que salieron bien y las
potenciales mejoras, y
Crear un plan para la implementación de mejoras con respecto a cómo el
Equipo Scrum hace su trabajo.
Diagramas utilizados en cada etapa:
Ejemplo explicativo:
Una empresa que ha sabido adaptarse perfectamente a las metodologías
ágiles es Spotify, haciendo especial hincapié en la figura del Scrum Master.
Muchas veces contratan un Agile Coach externo con una gran experiencia en
el campo para liderar los proyectos. Vemos aquí la importancia de contar con
roles especializados que conozcan las metodologías ágiles para llevar un
proyecto de este tipo al éxito. Ya no solo el Scrum Master, sino también otros
roles como el Product Owner, responsable de entender al cliente y al usuario
para saber trasladar en tiempo y forma la información adecuada al equipo de
desarrollo.
Spotify es consciente de la metodología de trabajo de su competencia
(Google o Apple por ejemplo), por lo que decidieron acercarse al Scrum de
forma muy sistemática. Compitiendo contra semejantes corporaciones,
sabían que en cualquier momento podrían ser derrotados a menos que
fuesen más rápidos, más baratos y mejores.
Por ejemplo, fijémonos en el nuevo iTunes Radio, ofrece exactamente lo
mismo que Spotify. Es por eso que han tenido que mejorar sus equipos de
trabajo para asegurarse que van más rápido. En Spotify los equipos se
organizan por escuadrones (squads), pequeños equipos de Scrum con la
habilidad de implementar el software desarrollado al final de cada sprint, sin
romper ningún otro equipo. Una característica curiosa del funcionamiento de
Spotify es que cada uno de estos pequeños grupos tiene una parte del
producto que es totalmente suyo. Después crean tribus(tribes) agregando
distintos escuadrones, tal y como vemos en la imagen a continuación.
Nombre:
Extreme programming
Características:
Metodología basada en prueba y error.
Fundamentada en Valores y Prácticas.
Expresada en forma de 12 Prácticas–Conjunto completo–Se
soportan unas a otras–Son conocidas desde hace tiempo. La
novedad es juntarlas.
Etapas:
Fase I: Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de
usuario que son de interés para la primera entrega del producto. Al
mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologías y prácticas que se utilizarán en el
proyecto. Se prueba la tecnología y se exploran las posibilidades de
la arquitectura del sistema construyendo un prototipo. La fase de
exploración toma de pocas semanas a pocos meses, dependiendo
del tamaño y familiaridad que tengan los programadores con la
tecnología.
Fase II: Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de
usuario, y correspondientemente, los programadores realizan una
estimación del esfuerzo necesario de cada una de ellas. Se toman
acuerdos sobre el contenido de la primera entrega y se determina
un cronograma en conjunto con el cliente. Una entrega debería
obtenerse en no más de tres meses. Esta fase dura unos pocos
días.
Las estimaciones de esfuerzo asociado a la implementación de las
historias la establecen los programadores utilizando como medida
el punto. Un punto, equivale a una semana ideal de programación.
Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el
equipo de desarrollo mantiene un registro de la "velocidad" de
desarrollo, establecida en puntos por iteración, basándose
principalmente en la suma de puntos correspondientes a las
historias de usuario que fueron terminadas en la última iteración.
La planificación se puede realizar basándose en el tiempo o el
alcance. La velocidad del proyecto es utilizada para establecer
cuántas historias se pueden implementar antes de una fecha
determinada o cuánto tiempo tomará implementar un conjunto de
historias. Al planificar por tiempo, se multiplica el número de
iteraciones por la velocidad del proyecto, determinándose cuántos
puntos se pueden completar. Al planificar según alcance del
sistema, se divide la suma de puntos de las historias de usuario
seleccionadas entre la velocidad del proyecto, obteniendo el
número de iteraciones necesarias para su implementación.
Fase III: Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser
entregado. El Plan de Entrega está compuesto por iteraciones de
no más de tres semanas. En la primera iteración se puede intentar
establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las historias
que fuercen la creación de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qué historias
se implementarán en cada iteración (para maximizar el valor de
negocio). Al final de la última iteración el sistema estará listo para
entrar en producción.
Los elementos que deben tomarse en cuenta durante la
elaboración del Plan de la Iteración son: historias de usuario no
abordadas, velocidad del proyecto, pruebas de aceptación no
superadas en la iteración anterior y tareas no terminadas en la
iteración anterior. Todo el trabajo de la iteración es expresado en
tareas de programación, cada una de ellas es asignada a un
programador como responsable, pero llevadas a cabo por parejas
de programadores. Wake en [18] proporciona algunas guías útiles
para realizar la planificación de la entrega y de cada iteración.
Fase IV: Producción
La fase de producción requiere de pruebas adicionales y revisiones
de rendimiento antes de que el sistema sea trasladado al entorno
del cliente. Al mismo tiempo, se deben tomar decisiones sobre la
inclusión de nuevas características a la versión actual, debido a
cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteración, de tres
a una semana. Las ideas que han sido propuestas y las
sugerencias son documentadas para su posterior implementación
(por ejemplo, durante la fase de mantenimiento).
Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto
XP debe mantener el sistema en funcionamiento al mismo tiempo
que desarrolla nuevas iteraciones. Para realizar esto se requiere de
tareas de soporte para el cliente. De esta forma, la velocidad de
desarrollo puede bajar después de la puesta del sistema en
producción. La fase de mantenimiento puede requerir nuevo
personal dentro del equipo y cambios en su estructura.
Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del
cliente en otros aspectos como rendimiento y confiabilidad del
sistema. Se genera la documentación final del sistema y no se
realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios
esperados por el cliente o cuando no hay presupuesto para
mantenerlo.
Diagramas utilizados en cada etapa:
Ejemplo explicativo:
Como ejemplo se puede aplicar esta metodología en la industria financiera. El
desarrollo rápido de software lo suficientemente flexible como para adaptarse
a los continuos cambios de la industria sería vital. En el entorno de trabajo
sería común el estrés (la presión complicaría aún más la tarea ya de por si
complicada de obtener software de calidad). En este campo se prefiere
habitualmente el software rápido, aunque contenga errores.
En este caso se trato de desarrollar rápidamente un software que fuese
robusto y útil. La programación extrema tendría el conseguir una aplicación
buena, de desarrollo rápido y útil. Estos son las características propias que
puede abordar la programación extrema (XP).
Repo Margining System
Este es un ejemplo de un proyecto de estas características.
La aplicación permitiría el comercio electrónico a través del navegador y
mantener informadas a las dos partes del trato. Además capturaría las ofertas
que se hiciesen y las mostraría en un lugar dedicado para ello:
El equipo estaría formado por 7 integrantes.
El espacio laboral estaría habilitado para favorecer la comunicación
entre los componentes.
Se empezaría desarrollando (utilizando el lenguaje de programación
JAVA) las clases, para poder realizar las pruebas y posteriormente
permitir el refactoring.
Todo el trabajo no se tendría que empezar desde cero, puesto que el
equipo contaba con código de otros trabajos previos y que podrían
reutilizar.
Nombre:
Dynamic Systems Development Method
Características:
Existe un constante involucramiento del usuario dentro del proceso,
lo que permite valorar el producto a tiempo.
El equipo de trabajo puede tomar decisiones.
Se hace una entrega frecuente de productos.
Los cambio son reversibles.
Es iterativo e incremental.
El equipo de trabajo de dos a seis integrantes.
Las pruebas se hacen a lo largo del ciclo de vida del proyecto.
Etapas:
Fase 1: PreProyecto:
Se identifican los proyectos propuestos.
Fase 2: Ciclo de Vida del Proyecto:
Etapa 1: Estudio de Viabilidad
Etapa 2: Estudio del Negocio
Etapa 3: Iteración del Modelo Funcional
Etapa 4: Iteración de Diseño y Desarrollo
Etapa 5: Aplicación
Fase 3: PostProyecto:
Asegurarse que el sistema operativo acepte de manera eficaz y segura
el proyecto.
Diagramas utilizados en cada etapa:
Ejemplo explicativo:
MOSCOW:
Representa una forma de priorizar los temas.
Esta es una sigla que significa:
MUST (DEBE) tener este requisito para satisfacer necesidades
del negocio.
MUST (DEBE) tener este requisito, pero el proyecto no depende
de ello.
COULD (PODRÍAN) tener este requisito sin que afecte las
condiciones del sistema.
WOULD (SE) tiene este requisito en una fecha posterior.
Timeboxing:
Se utiliza para apoyar los objetivos principales del DSDM.
Prototipos:
Permite descubrir de manera previa deficiencia del sistema.
Exámenes:
Es una técnica independiente para poder medir el logro de cada
iteración.
Taller:
Consiste en llevar a las partes interesadas a discutir
necesidades, funcionalidades, y comprensión mutua.
Nombre:
Kanban.
Características:
La metodología Kanban se basa en una serie de principios que la diferencian
del resto de metodologías conocidas como ágiles:
Calidad garantizada. Todo lo que se hace debe salir bien a la
primera, no hay margen de error. De aquí a que en Kanban no se
premie la rapidez, sino la calidad final de las tareas realizadas. Esto se
basa en el hecho que muchas veces cuesta más arreglarlo después
que hacerlo bien a la primera.
Reducción del desperdicio. Kanban se basa en hacer solamente lo
justo y necesario, pero hacerlo bien. Esto supone la reducción de todo
aquello que es superficial o secundario (principio YAGNI).
Mejora continua. Kanban no es simplemente un método de gestión,
sino también un sistema de mejora en el desarrollo de proyectos,
según los objetivos a alcanzar.
Flexibilidad. Lo siguiente a realizar se decide del backlog (o tareas
pendientes acumuladas), pudiéndose priorizar aquellas tareas
entrantes según las necesidades del momento (capacidad de dar
respuesta a tareas imprevistas).
Etapas:
1) Definir el flujo de trabajo de los proyectos:
para ello, simplemente deberemos crear nuestro propio tablero, que deberá
ser visible y accesible por parte de todos los miembros del equipo. Cada una
de las columnas corresponderá a un estado concreto del flujo de tareas, que
nos servirá para saber en qué situación se encuentra cada proyecto. El
tablero debe tener tantas columnas como estados por los que pasa una
tarea, desde que se inicia hasta que finaliza (p.e: diagnóstico, definición,
programación, ejecución, testing, etc.).
A diferencia de SCRUM, una de las peculiaridades del tablero es que este es
continuo. Esto significa que no se compone de tarjetas que se van
desplazando hasta que la actividad queda realizada por completo. En este
caso, a medida que se avanza, las nuevas tareas (mejoras, incidencias o
nuevas funcionalidades) se acumulan en la sección inicial, de manera que en
las reuniones periódicas con el cliente se priorizan y se colocan dentro de la
sección que se estima oportuna.
Dicho tablero puede ser específico para un proyecto en concreto o bien
genérico. No hay unas fases del ciclo de producción establecidas sino que se
definirán según el caso en cuestión, o se establecerá un modelo aplicable
genéricamente para cualquier proyecto de la organización.
2) Visualizar las fases del ciclo de producción:
Al igual que Scrum, Kanban se basa en el principio de desarrollo
incremental, dividiendo el trabajo en distintas partes. Esto significa que no
hablamos de la tarea en sí, sino que lo dividimos en distintos pasos para
agilizar el proceso de producción.
Normalmente cada una de esas partes se escribe en un postit y se pega en
el tablero, en la fase que corresponda. Dichos postits contienen la
información básica para que el equipo sepa rápidamente la carga total de
trabajo que supone: normalmente descripción de la tarea con la estimación
de horas. Además, se pueden emplear fotos para asignar responsables así
como también usar tarjetas con distintas formas para poner observaciones o
indicar bloqueos (cuando una tarea no puede hacerse porque depende de
otra).
Al final, el objetivo de la visualización es clarificar al máximo el trabajo a
realizar, las tareas asignadas a cada equipo de trabajo (o departamento), así
como también las prioridades y la meta asignada.
3) Stop Starting, start finishing:
Este es el lema principal de la metodología Kanban. De esta manera, se
prioriza el trabajo que está en curso en vez de empezar nuevas tareas.
Precisamente, una de las principales aportaciones del Kanban es que el
trabajo en curso debe estar limitado y, por tanto, existe un número máximo de
tareas a realizar en cada fase.
En realidad, se trata de definir el máximo número de tareas que podemos
tener en cada una de las fases (p.e: 3 tareas en la fase de planificación; 2, en
la fase de desarrollo; una, en la fase de pruebas, etc.) y, por tanto, restringir
el trabajo en curso. A esto, se le añade otra idea que, por muy obvia que
pueda parecer, la práctica nos demuestra que no es así: no se puede abrir
una nueva tarea sin finalizar otra.
De esta manera, se pretende dar respuesta al problema habitual de muchas
empresas de tener muchas tareas abiertas pero con un ratio de finalización
muy bajo. Aquí lo importante es que las tareas que se abran se cierren antes
de empezar con la siguiente.
4) Control del Flujo:
A diferencia de SCRUM, la metodología Kanban no se aplica a un único
proyecto, sino que mezcla tareas y proyectos. Se trata de mantener a los
trabajadores con un flujo de trabajo constante, las tareas más importantes en
cola para ser desarrolladas y un seguimiento pasivo para no tener que
interrumpir al trabajador en cada momento.
Asimismo, dicha metodología de trabajo nos permite hacer un seguimiento
del trabajo realizado, almacenando la información que nos proporcionan las
tarjetas.
Diagramas utilizados en cada etapa:
Ejemplo explicativo:
KANBAN y el sistema Toyota:
Toyota utilizó ampliamente el sistema KANBAN durante muchos años como
medio para manifestar las necesidades de materiales entre dos centros de
proceso. Kanban, a v a n c e s 6 traducido literalmente significa “registro
visible” o “placa visible”, y se le da el significado de “tarjeta” generalmente. El
sistema KANBAN de Toyota emplea una tarjeta para indicar la necesidad de
entregar más partes y una tarjeta idéntica o similar para indicar la necesidad
de producir más partes. Una característica particular del sistema KANBAN de
Toyota es que es un sistema de extracción. KANBAN proporciona las partes
cuando se les necesita, sólo que sin conjeturas y por lo tanto sin el exceso de
inventario que resulta de las suposiciones erróneas. En el sistema KANBAN
de Toyota, cada tipo de parte componente, o número de parte, tiene su
propio recipiente especial destinado a contener una cantidad precisa del
número de parte, preferiblemente una cantidad muy pequeña. Hay dos
tarjetas, que de aquí en adelante se llamarán kanban, por cada recipiente.
Las kanban identifican el número de parte y la capacidad del recipiente y
ofrecen alguna otra información. Una kanban, la de producción, sirve al
centro de trabajo que produce el número de parte; la otra, llamada kanban de
retiro, sirve al centro de trabajo usuario. Cada recipiente sigue un ciclo, desde
el centro de trabajo productor y su punto de abastecimiento hasta el centro de
trabajo usuario y su punto de abastecimiento, para después regresar. Una
kanban se cambia por la otra en el trayecto. Cuando se trabaja bajo el
sistema KANBAN y JAT, los trabajadores están siempre recogiendo
información sobre la serie siguiente de problemas y periódicamente se les
llena de elogios cuando un problema es resuelto. Para recibir elogios, evitar
la crítica, sentir satisfacción y eludir el trabajo extraordinario no planeado, los
trabajadores KANBAN por lo general apoyan las características de
mejoramiento y sienten entusiasmo por la productividad que ofrece el
sistema.
Tipos de procesos:
Al iniciar el estudio del sistema KANBAN es importante primero comprender
lo que es un proceso subsecuente y un proceso precedente, para poder
definir las reglas que rigen el movimiento del kanban.
Procesos subsecuentes:
El proceso río abajo dentro del flujo del proceso de manufactura hacia donde
el proceso normal lleva las partes se llama proceso subsecuente. El centro de
trabajo que recibe las partes ensambladas es el subsecuente al proceso que
ensambla las partes.
Procesos precedentes:
Supóngase que se camina hasta el proceso que recibe las partes ya
ensambladas y vemos, hacia atrás, hacia el proceso que las ensambla. Este
proceso será el precedente al proceso donde nos encontramos ahora. Un
proceso subsecuente en un caso particular podría ser el precedente a otro,
todo depende de su posición relativa en el flujo de manufactura. Un kanban
siempre tomará partes de los procesos precedentes y las enviará a los
procesos subsecuentes. KANBAN está formado por un conjunto de tarjetas
que viajan entre procesos a v a n c e s 7 precedentes y subsecuentes, para
comunicar cuáles son las partes que se necesitan en los procesos
subsecuentes.
Tipos de tarjetas:
El sistema KANBAN requiere dos tipos de tarjeta para operar correctamente:
una de retiro y otra de producción; ambos tipos no difieren entre sí en su
apariencia, sino en una etiqueta que indica su tipo y que debe aparecer en
letras grandes en la parte superior de cada tarjeta. Para diferenciarlos por su
tipo se pueden emplear distintos colores, de manera que los trabajadores
sepan fácilmente cuál es cuál y sean capaces de evitar el error de
mezclarlos.
Kanban de retiro:
El kanban de retiro viaja entre los centros de trabajo y su finalidad es
autorizar el movimiento de partes de uno a otro centro. En un sistema
kanban, el de retiro debe siempre de acompañar al flujo de materiales de un
proceso a otro. Un kanban de retiro siempre debe de especificar el tamaño
del lote y la dirección del proceso. El kanban debe además mostrar el nombre
del proceso precedente y su localización en el edificio, así como el proceso
subsecuente y su localización. Una vez que un kanban de retiro toma las
partes, se queda con ellas durante todo el tiempo. Después, cuando los
procesos subsecuentes han consumido la última parte del lote, el kanban
viajará de nuevo hacia el proceso precedente para obtener nuevas partes.
Kanban de producción:
El objetivo del kanban de producción es enviar la orden al proceso
precedente para que se elaboren más partes. Cuando el kanban de retiro
llega a un proceso precedente es casi seguro que encuentre disponibles uno
o varios contenedores con las partes que habrán de ser tomadas. El kanban
de producción debe acompañar a los contenedores en ese momento. El
empleado que está al servicio del centro de trabajo colocará el kanban de
retiro en un lugar visible en los contenedores y luego los enviará al proceso
subsecuente. Antes de mover los contenedores, recogerá el kanban de
producción, este autoriza al centro de trabajo para elaborar un nuevo lote de
partes. Una estación de trabajo puede usar cualquier variedad de métodos
para reabastecerse por su centro de trabajo proveedor, por ejemplo un foco
que se prende y apaga, el mismo contenedor vacío o un mensaje en una
terminal de computadora. El Kanban es visual, lo que representa una ventaja
al no depender de un sistema electrónico para conocer la cantidad de materia
prima disponible y la que se requiere. a v a n c e s.
Faltantes en el kanban de producción:
En un ambiente real de operación existen posibilidades de que cuando llegue
un kanban de retiro al proceso precedente, no haya un kanban de producción
que lo espere con las partes. En este caso, el sistema debe tratar la situación
como una emergencia de partes. El empleado debe enviar el kanban de retiro
directamente al área de producción y tratarlo como uno de producción
temporal. La llegada de un kanban de retiro al área de producción dará a éste
mayor importancia que a los kanban de producción normal, pero no mayor
que la que tienen los otros kanban de retiro que ya se encuentren ahí.
Conclusiones En conclusión, las metodologías nos permiten tener un camino que nos ayuda a
tener un mejor desarrollo de software en cuanto a la estructura del mismo y las
características y/o requisitos que se deben tener para lograr un buen producto. Sin
embargo cada una de las metodologías presenta ciertos puntos que ayudan un poco
más al desarrollo paso a paso del software pero así mismo también extienden las
horas de trabajo en el semejante, por ende ya queda al criterio del líder del grupo
escoger la metodología a llevar para lograr la elaboración completa del software.
Bibliografía
http://www.tutorialspoint.com/es/software_engineering/software_engineering_
overview.htm
http://paradigmasiut.blogspot.com.co/2013/04/metodologiadedesarrollodes
oftware.html
http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.p
df
http://es.slideshare.net/haljho2015/clasificacionmetodologias48294040
http://cmapspublic.ihmc.us/rid=1GR3MCB9D14NPP5B1527/Metodos%20de
sarrollo%20del%20software.cmap
http://www.academia.edu/4984909/Metodologia_de_desarrollo_de_software
http://datateca.unad.edu.co/contenidos/204023/Garcia_F._y_Bravo_C._Meto
dologias_de_desarrollo_de_software.pdf
http://www.eumed.net/tesisdoctorales/2014/jlcv/software.htm
http://es.slideshare.net/mariantoniettabarreto/metodologiassadm43301429
http://es.slideshare.net/felipeSkabarragan/auditoria3381317
http://earchivo.uc3m.es/bitstream/handle/10016/13192/PFC%20Margarita%2
0Guerrero%20Barrios.pdf?sequence=1
http://es.slideshare.net/OliverCenteno/mtricav3yrup
http://desarrollodefw.blogspot.com.co/2012/10/caracteristicasscrum.html
http://www.obsedu.com/bloginvestigacion/projectmanagement/las5etapas
enlossprintsdeundesarrolloscrum/
http://comunidad.iebschool.com/iebs/agilescrum/exitosyfracasosenproyect
osscrumspotifyvshealthcare/
http://ingenieriadesoftware.mex.tl/52753_XPExtremePrograming.html
http://www.cyta.com.ar/ta0502/v5n2a1.htm
https://ingenieriadelsoftwareuah2015.wordpress.com/2015/03/29/metodosde
desarrollodesistemasdinamicosdsdm/
http://ingenieriadesoftware.mex.tl/images/18149/DSDM%20documento.pdf
http://www.uacj.mx/DGDCDC/SP/Documents/avances/Documents/2006/Avan
ces%20141.%20Montes,%20Vidal.pdf
http://www.cyta.com.ar/ta0502/v5n2a1.htm
https://procesosoftware.wikispaces.com/Modelo+Incremental
http://desarrollodefw.blogspot.com.co/2012/10/caracteristicasscrum.html
http://www.dtic.ua.es/jdare10/presentaciones/JDARE1007.pdf
http://modeloentregaporetapas.blogspot.com.co/
http://iswudistrital.blogspot.com.co/2012/09/ingenieriadesoftwarei.html
http://rupuml.blogspot.com.co/2009/06/caracteristicas.html
http://metodologiadesoftware.blogspot.com.co/2012/11/fasesdelmodelorup_
27.html
http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/
