Karen Alejandra Sampayo Rodriguez
Fecha de Nacimiento: 26 de Enero de 1994
Estado Civil: Soltera
E-mail: Karenalejandra_26@hotmail.com
Estudios
Realizados
SUPERIOR
Universidad Simón Bolívar
Ingeniería de Sistemas Bachiller Académico
VII Semestre (Actualmente) Soledad – 2008
Diurno
Estudiante de VII Semestre de Ingeniería De Sistemas en la Universidad Simón Bolívar nacida el 26 de Enero de 1994, con 18 años de edad, de Barranquilla- Atlántico. Culmine mis estudios como bachiller académico en el Instituto Monsalve New Love de Soledad- Atlántico.
Me considero una estudiante y futura profesional con excelentes relaciones interpersonales, capacidad para asumir responsabilidades, trabajar en equipo, alto grado de cumplimiento y compromiso laboral, con habilidades para desempeñarme en el área comercial. Buen criterio en la toma de decisiones y actitud de buen servicio, así como predisposición a la formación continua.
Los Siguientes son Algunos Conceptos solicitados por la Ingeniera Adriana Iglesias en la asignatura de Ingeniería Del Software II.
CMMI
CMMI (Capability Maturity Model Integration) es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales de procesos efectivos, lo que mejorará su rendimiento. CMMI basado en la mejora del proceso incluye la identificación de las fortalezas de su organización, procesos y debilidades y hacer cambios en el proceso de convertir debilidades en fortalezas.
CMMI se aplica a los equipos, grupos de trabajo, proyectos, divisiones y organizaciones enteras. Los modelos de CMMI son colecciones de las mejores prácticas que ayudan a las organizaciones para mejorar drásticamente la eficacia y calidad. Estos productos o soluciones de CMMI , consisten en prácticas.
Para mas informacion sacado de http://www.sei.cmu.edu/cmmi/
Para mi opinión el CMMI esta basado en un modelo de calidad hacia las empresas que deseen instaurar o implementar proyectos con mayor calidad y menor riesgos en el desarrollo de dicho proyecto, buscando así la organización de este y evaluando todos los procesos para su desarrollo, basándose en pruebas experimentales para así asegurar la calidad.
OPENUP
Openud es un conjunto estandarizado de conceptos de procesos de desarrollo de software de código abierto. Es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software basados en desarrollo iterativo, ágil e incremental; y es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo.
Este proceso de desarrollo unificado está basado en Rational Unified Process (RUP), desarrollado por IBM y reconocido mundialmente como uno de los procesos de desarrollo de software de mayor calidad, basándose en los principios de Adaptación, Importancia a los involucrados e interesados en los resultados del proyecto; Colaboración, Valor a la iteración; y Calidad Continua.
OpenUP/Basic permite un abordaje ágil al proceso de desarrollo de software, con sólo proveer un conjunto simplificado de contenidos, fundamentalmente relacionados con orientación, productos de trabajo, roles, y tareas.
OpenUP/Basic es un proceso interactivo de desarrollo de software simplificado, completo y extensible. Es un proceso para pequeños equipos de desarrollo que valoran los beneficios de la colaboración y de los involucrados con el resultado del proyecto, por encima de formalidades innecesarias.
OpenUP está caracterizado por cuatro principios básicos interrelacionados, a saber:
1 – Colaboración para unificar intereses y compartir conocimientos.
2 – Equilibrio de prioridades competentes a maximizar el valor de los involucrados con el resultado del proyecto.
3 – Enfoque en la articulación de la arquitectura.
4 – Desarrollo continuo para obtener realimentación y realizar las mejoras respectivas. OpenUP/Basic se centra en articular la arquitectura para facilitar la colaboración técnica, reducir el riesgo y minimizar el sobreesfuerzo de desarrollo.
OpenUP/Basic procura un equilibrio entre las necesidades de los involucrados con los resultados del proyecto y los costos técnicos, con el fin de maximizar el valor de los involucrados y las guías del proceso de desarrollo.
OpenUP/Basic desarrolla un ciclo de vida interactivo que mitiga el riesgo a tiempo y ofrece demostrar resultados en curso al cliente del proyecto.
sacado de http://cbasqa.wordpress.com/2008/09/02/proceso-de-desarrollo-openup/
Para mi Openup es un modelo de desarrollo para proyectos que se necesiten rápidamente, es decir que tienen que ser desarrollados de manera ágil, por ello se basan en el desarrollo incremental, en el cual los requerimientos del cliente mas importantes son priorizados y debido a cada incremento se entrega una funcionalidad del sistema.
sacado de http://cbasqa.wordpress.com/2008/09/02/proceso-de-desarrollo-openup/
Para mi Openup es un modelo de desarrollo para proyectos que se necesiten rápidamente, es decir que tienen que ser desarrollados de manera ágil, por ello se basan en el desarrollo incremental, en el cual los requerimientos del cliente mas importantes son priorizados y debido a cada incremento se entrega una funcionalidad del sistema.
XP
XP (EXtreme PROGRAMACIÓN) es una disciplina para el desarrollo de software que hace hincapié en la implicación del cliente y trabajo en equipo. Desarrollado por Kent Beck, Ward y Cunningham Ron Jeffries, que se basa en un conjunto formal de reglas sobre cómo se desarrolla la funcionalidad como la definición de una prueba antes de escribir el código y el diseño nunca más se necesita para apoyar el código que se escribe.
XP está diseñado para dirigir el proyecto correctamente en lugar de concentrarse en las fechas previstas de reuniones, que son a menudo poco realista en este negocio. Algunas de las prácticas fundamentales son de diseño simple, la programación por parejas y la entrega de versiones pequeñas pero frecuentes.
Ver Información detallada en http://encyclopedia2.thefreedictionary.com/Extreme+Programming
Yo personalmente defino esta programación extrema como una metodología ágil y con muchas ventajas, dado que es capaz de adaptarse a los cambios que sean requeridos por el cliente, como se dijo anteriormente se basa en pruebas con anterioridad y antes de escribir el código se verifica el diseño para que nunca mas intervenga en los cambios requeridos por el cliente al código, es decir este tipo de metodología se basa en cambiar múltiples veces los requerimientos sin alterar mucho el sistema.
Ver Información detallada en http://encyclopedia2.thefreedictionary.com/Extreme+Programming
Yo personalmente defino esta programación extrema como una metodología ágil y con muchas ventajas, dado que es capaz de adaptarse a los cambios que sean requeridos por el cliente, como se dijo anteriormente se basa en pruebas con anterioridad y antes de escribir el código se verifica el diseño para que nunca mas intervenga en los cambios requeridos por el cliente al código, es decir este tipo de metodología se basa en cambiar múltiples veces los requerimientos sin alterar mucho el sistema.
SCRUM
"Wikipedia"
Scrum es un proceso de desarrollo de software iterativo y creciente utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas.
ScrumAlliance:
Scrum es un framework de desarrollo ágil de software. El trabajo es estructurado en ciclos de trabajo llamados sprintes, iteraciones de trabajo con una duración típica de dos a cuatro semanas. Durante cada sprint, los equipos eligen de una lista de requerimientos de cliente priorizados, llamados historias de usuarios, para que las características que sean desarrolladas primero sean las de mayor valor para el cliente. Al final de cada sprint, se entrega un producto potencialmente lanzable / distribuible / comerciable.
Roles De Scrum
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
ScrumTeam o Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc).
Tomado de http://www.aplicandoscrum.com/scrum/
En mi opinión el SCRUM se basa al igual que el OpenUP en el desarrollo incremental, solo que en este tipo de metodología se prevee una duración fija, en este caso de 2 a 4 semanas por cada entrega, al igual que el desarrollo incremental como su nombre lo dice se basa en la entrega de adelantos funcionales con cada incremento, priorizando los requerimientos mas importantes.
Roles De Scrum
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
ScrumTeam o Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc).
Tomado de http://www.aplicandoscrum.com/scrum/
En mi opinión el SCRUM se basa al igual que el OpenUP en el desarrollo incremental, solo que en este tipo de metodología se prevee una duración fija, en este caso de 2 a 4 semanas por cada entrega, al igual que el desarrollo incremental como su nombre lo dice se basa en la entrega de adelantos funcionales con cada incremento, priorizando los requerimientos mas importantes.
ITIL
ITIL, Information Technology Infrastructure Library, es una colección de las mejores prácticas observadas en la industria de TI (Tecnologías de la Información) . Es un conjunto de libros en los cuales se encuentran documentados todos los procesos referentes a la provisión de servicios de tecnología de información hacia las organizaciones.
ITIL por medio de procedimientos, roles, tareas, y responsabilidades que se pueden adaptar a cualquier organización de TI, genera una descripción detallada de mejores practicas, que permitirán tener mejor comunicación y administración en la organización de TI. Proporciona los elementos necesarios para determinar objetivos de mejora y metas que ayuden a la organización a madurar y crecer.
Las ventajas de ITIL para los clientes y usuarios
• Mejora la comunicación con los clientes y usuarios finales a través de los diversos puntos de contacto acordados.
• Los servicios se detallan en lenguaje del cliente y con más detalles.
• Se maneja mejor la calidad y los costos de los servicios.
• La entrega de servicios se enfoca mas al cliente, mejorando con ello la calidad de los mismos y relación entre el cliente y el departamento de IT.
• Una mayor flexibilidad y adaptabilidad de los servicios.
Desventajas
• Tiempo y esfuerzo necesario para su implementación.
• Que no de se de el cambio en la cultura de las área involucradas.
• Que no se vea reflejada una mejora, por falta de entendimiento sobre procesos, indicadores y como pueden ser controlados.
• Que el personal no se involucre y se comprometa.
• La mejora del servicio y la reducción de costos puede no ser visible.
• Que la inversión en herramientas de soporte sea escasa. Los procesos podrán parecer inútiles y no se alcancen las mejoras en los servicios.
Para ampliar su conocimiento visite http://www.soporteremoto.com.mx/help_desk/articulo04.html , tomado de aquí.
Para ampliar su conocimiento visite http://www.soporteremoto.com.mx/help_desk/articulo04.html , tomado de aquí.
Para mi ITIL es una buena opción tanto para usuarios como clientes, es decir ITIL es un conjunto de información en un solo lugar que le proporciona a cada persona las diferentes estrategias,definiciones y procedimientos para la correcta organización y gestión de los proyectos, ayudandoles a lograr la calidad y minimizando los riesgos.
COBIT
COBIT (Objetivos de Control para la Información y Tecnologías Relacionadas) es un estándar abierto internacional que define los requisitos para el control y la seguridad de los datos sensibles y proporciona un marco de referencia. COBIT , que proporciona un marco de referencia, se introdujo en la década de 1990 por el IT Governance Institute.
COBIT se compone de un resumen ejecutivo, directrices de gestión, el marco, los objetivos de control, herramientas de aplicación y guías de auditoría. Se proporciona amplio soporte, incluyendo una lista de factores críticos de éxito para medir la eficacia del programa de seguridad y punto de referencia para fines de auditoría. COBIT ha sido revisado varias veces desde el inicio y las actualizaciones se publican a intervalos regulares.
Tomado de http://searchsecurity.techtarget.com/definition/COBIT
Para mi Cobit es un conjunto de estándares en los cuales se deben basar los proyectos y su desarrollo para proporcionar calidad a este. Allí se encuentran un conjunto de requisitos y objetivos en los cuales deben basarse las realizaciones y el desarrollo de los proyectos. ademas ayuda a manejar la información de una mejor manera a través de directrices allí propuestas.
LEAN
La idea central consiste en maximizar el valor del cliente y reducir al mínimo los residuos. Simplemente, lean significa crear más valor para los clientes con menos recursos.
Una organización ágil entiende el valor de los clientes y centra sus procesos clave para aumentar continuamente. El objetivo final es ofrecer un valor ideal para el cliente a través de un proceso de creación de valor perfecta que tiene cero residuos.
Para lograr esto, los cambios en el pensamiento lean en el centro de gestión de la optimización de las tecnologías por separado, los activos, y los departamentos verticales para optimizar el flujo de productos y servicios a través de corrientes de valor que fluyen horizontalmente a través de tecnologías, bienes y servicios a los clientes.
La eliminación de los residuos a lo largo de las corrientes de valor, en vez de en puntos aislados, crea procesos que requieren menos esfuerzo humano, menos espacio, menos capital y menos tiempo para hacer los productos y servicios a un costo mucho menor y con defectos mucho menos, en comparación con los sistemas empresariales tradicionales . Las empresas son capaces de responder a los deseos cambiantes de los clientes con una gran variedad, alta calidad, bajo costo y con tiempos de ejecución muy rápida. Además, la gestión de la información se vuelve mucho más simple y preciso.
Informacion Ampliada en la Siguiente Pagina http://www.lean.org/whatslean/
En mi opinión este tipo de metodología se basa en la agilidad, pero también en el ahorro, digo esto porque el fin de este método es no dejar residuos, es decir que no queden sobrantes, se debe entregar mas funcionalidad al cliente sin desperdiciar recursos, aportando así mas valor con menos gastos.
MSF
Microsoft Solutions Framework (MSF) es un conjunto de principios, modelos, disciplinas, conceptos y directrices para la entrega de tecnología de la información de las soluciones de Microsoft . MSF no se limita al desarrollo de aplicaciones sólo, es también aplicable a otros proyectos como los proyectos de despliegue de redes o infraestructura. MSF no obliga al desarrollador a utilizar una determinada metodología ( Cascada , ágil ), pero les permite decidir qué método utilizar.
Microsoft Solutions Framework (MSF) es un conjunto de software de ingeniería procesos , principios y prácticas probadas con el objeto de permitir a los desarrolladores lograr el éxito en el ciclo de desarrollo de software (SDLC). MSF proporciona una orientación adaptable, basado en las experiencias y mejores prácticas dentro y fuera de Microsoft, para aumentar la posibilidad de un suministro eficaz de una tecnología de la información solución para el cliente por el trabajo rápido, disminuyendo el número de personas en el equipo del proyecto , evitando el riesgo , al tiempo que permite alta calidad de los resultados.
Tomado de http://en.wikipedia.org/wiki/Microsoft_Solutions_Framework
Considero que MSF se basa en un conjunto de pasos o instrucciones para desarrollar un proyecto, brindando así al cliente o usuario el poder escoger la metodología que mejor se adapte a su proyecto y que le proporcione así, menos costos y mas funcionalidad, obteniendo un producto de mayor calidad.
PMI-PMBOK
El project management Body of knowledge (libro de estandares para la gestion de proyectos (PMBOK) es un estandar reconocido internacionalmente (IEEE, ANSI) este trabaja con el uso del conocimiento, de las habilidades, de las herramientas, y de las tecnicas para resolver requisitos del proyecto. La guía del PMBOK define un ciclo vital del proyecto, 5 grupos de procesos y 9 áreas de conocimiento de la tarea de administración de proyectos.
Un equipo de proyectos funciona en 9 áreas de conocimiento con un numero de procesos basicos:
1. Integracion: Desarrolle la carta del proyecto, la declaracion del alcance y el plan. Dirija, maneje, supervise y controle el proyecto de innovacion.
2. Alcance: Planeacion, definicion, creacion, verificacion y control de la estructura de division, de responsabilidades del trabajo.
3. Tiempo: Definicion, secuenciamiento, estimación de recursos necesarios y de la duración, desarrollo y control del cronograma.
4. Costo: Planeamiento de recursos, costos estimados, presupuesto y control.
5. Calidad: Planeamiento de la calidad, aseguramiento de la calidad y control de calidad.
6. Recurso Humano: Planeamiento, contratación, desarrollo y administración del recurso humano.
7. Comunicaciones: Planificación de comunicaciones, distribución de la información, difusión del desempeño.
8. Riesgos: Planeamiento e identificación de riesgos, análisis de riesgos (cualitativa y cuantitativa), planeamiento de la respuesta ante riesgos (acción) y supervision y control del riesgo.
9. Consecución: Plan de contrataciones y adquisiciones, selección e incentivos de los vendedores, administración y cierre de contratos.
Tomado de http://www.12manage.com/methods_pmi_pmbok_es.html
Para mi el PMBOK como se dijo anteriormente es un conjunto de estándares, los cuales deben seguirse a la hora de elaborarse un proyecto, así como en nuestra sociedad hay requisitos y reglas que seguirse, la realización de nuestros proyectos también se basan en el cumplimiento de ciertos pasos, para así lograr éxito en nuestro proyecto.
PRINCE2
PRINCE2 ( PRoyectos EN Controlled Environments) es un método basado en procesos para la eficacia de la gestión de proyectos . Este método se centra en la organización, la gestión y el control.
PRINCE2 es un estándar de facto utilizado extensamente por el Gobierno del Reino Unido y es ampliamente reconocida y utilizada en el sector privado, tanto en el Reino Unido e internacionalmente.
El método PRINCE2 es de dominio público, ofreciendo normas de buenas prácticas en gestión de proyectos . PRINCE2 es una marca registrada de la Oficina del Gabinete.
Las características principales de PRINCE2 son los siguientes:
Su enfoque en la justificación de negocio
Una organización de estructura definida para el equipo de gestión de proyectos
Su producto enfoque basado en la planificación
Su énfasis en la división del proyecto en fases manejables y controlables
Su flexibilidad para ser aplicados en un nivel apropiado para el proyecto.
Para mayor Información Visite http://www.prince2.com/what-is-prince2.asp
Para mi PRINCE es un estándar al igual que los anteriores basado en las normas y requisitos para el desarrollo de los proyectos, para así obtener como resultado buenas practicas y sobre todo calidad y organización en este.
DRA
El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.
Para Saber Mas Visite
http://www.mitecnologico.com/Main/ModeloDesarrolloRapidoAplicaciones
Para mi DRA es una metodología la cual se basa en la rapidez de los proyectos pero con gran funcionalidad, ademas este tipo de metodologías están orientados a la reutilizacion dado que se necesita optimizar el tiempo y es mas factible tomar cosas hechas e incorporarlas a nuevos sistemas.
CRYSTAL
Concebido por Alistair Cockburn, este modelo no describe una metodología cerrada, sino un conjunto de ellas, junto con los criterios para seleccionar y adecuar la más apropiada al proyecto. Los parámetros para determinarla son la criticidad y el tamaño del sistema que se va a construir.
Fundamentos de Crystal
* Desarrollo iterativo e incremental.
* Duración máxima de una iteración: 4 meses.Recomienda duraciones entre 1 y 3 meses.
* Especial énfasis en la importancia de laspersonas sobre los procesos.
* Especial énfasis en la comunicación directa.
* Modelo abierto a la adaptación e introducciónde prácticas de otros modelos ágiles(Extreme Programming, Scrum...)
Tomado de http://es.scribd.com/doc/61815330/44/CRYSTAL
Para mi KRYSTAL es un conjunto de metodologías, la cual ofrece muchas ventajas dado que permite al cliente adoptar un conjunto de pasos de dichas metodologías a los proyectos, brindando así mayor flexibilidad y mayor adaptación en la elaboración y desarrollo de estos.
KANBAN
Es una señal visual que determina cuanto se a consumido y cuanto parar o cuando hacer un cambio. Es una autorización para realizar el trabajo y reabastecer materiales.
Kanban ha demostrado ser útil en equipos que realizan desarrollo Ágil
de software; Kanban es una aproximación a la gestión del cambio. No es un proceso de desarrollo de software o de gestión de proyectos. Kanban es una aproximación a la introducción de cambios en un ciclo de vida de desarrollo de software o metodología de
gestión de proyectos.
Los principales objetivos son:
• Incrementar la fuerza de trabajo
• Minimizar el stock de inventario
• Recortar tiempos muertos
• Incrementar el nivel de servicio al cliente
• Incrementar productividad
• Reducción de desperdicios de materia prima
• Reducción de desperdicio de tiempo
• Reducción de Inventario en Proceso
Tomado de www.tec.com.mx/aplicaciones/twiki/.../KanbanWebInformation.doc
Para mi KANBAN aunque no es una metodología es una muy buena estrategia de optimizacion ya que permite que no hayan desperdicios ni errores, ademas incrementa la productividad en la realización y desarrollo de los proyectos.
TSP
Es una metodología para dirigir el trabajo de mejora y desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural. Conjunto de procesos estructurados que indican qué hacer en cada fase del desarrollo del proyecto y muestra cómo conectar cada fase para construir un producto completo.
Objetivos
* Maximizar calidad Software, Minimizar costos.
* Integrar equipos independientes de alto rendimiento que planeen y registren su trabajo, establezcan metas, y sean dueños de sus procesos y planes.
* Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad.
* Acelerar la mejora continúa de procesos.
* Proveer de una guía para el mejoramiento en organizaciones maduras
CICLO DE VIDA
* Lanzamiento
* Estrategia
* Planeación
* Requerimientos
* Diseño
* Implementación
* Prueba
* Postmortem
Tomado de http://www.slideshare.net/JuanGarcia99/team-software-process-tsp-9839315
Para mi este tipo de metodología ayuda a mejorar el entorno en el cual trabajan los ingenieros y programadores, dividiendo así cada fase para que sea cumplida por cada equipo y luego se construya un producto completo, basándose en la organización y la calidad del software.
PSP
El PSP (Personal Software Process)es un marco de trabajo de procesos para guiara a los desarrolladores en:
* Definir sus propios procesos
* Planear y dar seguimiento a su propio trabajo
* Administrar la calidad de sus propios productos de trabajo
El PSP es un proceso personal que al estar basado en los principios de mejora, ayuda a la gente a establecer sus metas personales, identificar qué métodos utilizarán, medir sus trabajo y analizar los resultados, para ajustar los métodos que utilizan para cumplir sus metas.
En conclusión, el PSP es un proceso definido para ayudar a realizar mejor el trabajo, cuyo objetivo es obtener y reportar datos precisos y completos del trabajo que se realiza a nivel individual, con el fin de mejorar el proceso individual, afectando de esta manera al desempeño de todo el equipo.
Niveles del PSP
* PLANEACIÓN.
* DISEÑO DE ALTO NIVEL
* REVISIÓN DEL DISEÑO DE ALTO NIVEL
* DESARROLLO
* ANÁLISIS DE RESULTADOS
Visite http://www.avantare.com/portal/page.aspx 8,6,162,O,S,0,PAG;CONC;159;13;D;39038085;0;PAG;
Para mi PSP se basa en la meta personal de cada ingeniero para cumplir sus propósitos, el cual se basa en principios para mejorar los ámbitos en los cuales se desarrolla, y así obtener mejor desempeño por parte de los trabajadores.
RUP
El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Tomado de Wikipedia, para ampliar mas esta informacion visite http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
En mis palabras RUP es un proceso basado en el conjunto de metodologías utilizables para la elaboración de proyectos, permitiendo al usuario escoger cualquiera que se adapte a lo que el necesita.
Manifiesto Ágil
Valores del Manifiesto Agil
Valorar más a los individuos y su interacción que a los procesos y las herramientas
Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.
Valorar más el software que funciona que la documentación exhaustiva
Poder ver anticipadamente como se comportan las funcionalidades esperadas sobre prototipos o sobre las partes ya elaboradas del sistema final ofrece una retroalimentación (feedback) muy estimulante y enriquecedor que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá conseguir un documento que contenga requisitos detallados antes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de la documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.
Valorar más la colaboración con el cliente que la negociación contractual
Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.
Valorar más la respuesta al cambio que el seguimiento de un plan
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Principios Del Manifiesto Ágil
Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los principios que de ellos se derivan:
Planning Poker
Es una técnica para calcular una estimación basado en el consenso, en su mayoría utilizado para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. Es utilizado comúnmente en el desarrollo ágil de software, en particular en la metodología Extreme Programming.
Trabajar con planning poker fue muy chevere, como realizamos las estimaciones fue una manera divertida y rapida de estimar la duración de los sprints, ademas de socializar y ver los puntos de vista de cada uno de los integrantes del equipo, fortaleciendo lazos de amistad y buen manejo de los ambientes para un mejor desempeño en el desarrollo del proyecto.
Arquitectura De Software
La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. (según IEEE Std 1471-2000)
Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
.jpg)
Ejes Fundamentales
Diseño o selección de la arquitectura: Cómo crear o seleccionar una arquitectura con base de requerimientos funcionales, de performance o de calidad.
Representación de la arquitectura: Cómo comunicar una arquitectura.
Evaluación y análisis de la arquitectura: Cómo analizar una arquitectura para predecir cualidades del sistema en que se manifiesta. Un problema semejante es cómo comparar y escoger entre diversas arquitecturas en competencia.
Desarrollo y evolución basados en arquitectura: Cómo construir y mantener un sistema dada una representación de la cual se cree que es la arquitectura que resolverá el problema correspondiente.
Estilo Arquitectónico
Un estilo arquitectónico define una familia de sistemas en términos de un patrón de organización estructural.
Algunos estilos arquitectónicos son:
Modelo Vista- Controlador
Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista.
Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.
La finalidad del modelo es mejorar la reusabilidad por medio del desacople entre la vista y el modelo. Los elementos del patrón son los siguientes:
El modelo es el responsable de:
-Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
- Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: “Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor”.
- Lleva un registro de las vistas y controladores del sistema.
- Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una inserción, etc).
El controlador es el responsable de: - Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
- Contiene reglas de gestión de eventos, del tipo “SI Evento Z, entonces Acción W”. Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método “Actualizar()”. Una petición al modelo puede ser “Obtener_tiempo_de_entrega( nueva_orden_de_venta )”.
Las vistas son responsables de:
-Recibir datos del modelo y los muestra al usuario.
-Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
Pueden dar el servicio de “Actualización()”, para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).
Para mas informacion visite:
http://www.comusoft.com/modelo-vista-controlador-definicion-y-caracteristicas
Para mi opiniòn como estudiante de Ingenieria de Sistemas el modelo vista controlador deberia ser uno de los patrones màs utilizados por los programadores, ya que ademàs de separar los modelos, de las vistas y los controladores nos proporcionan muchas ventajas en cuanto a optimizaciòn de còdigos, porquè? porque cuando separamos el programa en tres (modelo, vista, controlador) puede proporcionarnos que una vista al ser independiente pueda tener varias representaciones de un mismo modelo, un ejemplo claro seria la representacion de datos, como una tabla o como un diagrama de barras, pero todo esto de un mismo modelo. Otra ventaja seria que podemos hacer o generar varias vistas sin modificar o alterar el modelo dado que el obejetivo de este patròn es ser uno independiente del otro.
Patrón
Es aquel que describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de forma tal que esa solución puede ser usada un millón de veces, sin hacerlo de la misma manera dos veces.
C. Alexander, “The Timeless Way of Building”, 1979
Patrón De Diseño
Son aquellos que representan soluciones a problemas que surgen cuando se desarrolla software en un contexto particular.
Estos, facilitan la reutilización de arquitecturas y diseños de software exitoso.
Los patrones de diseño pretenden:
Existen varios patrones de diseño, los cuales se clasifican como se muestra a continuación:
Patrones Creacionales: Inicialización y configuración de objetos.
Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.
Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.
Patrones Creacionales
Constituyen la base del CÓMO se diseñará el sistema. Se aplican en los primeros momentos del diseño.
Los patrones GRASP describen los principios fundamentales de diseño de objetos para la asignación de responsabilidades. Constituyen un apoyo para la enseñanza que ayuda a entender el diseño de objeto esencial y aplica el razonamiento para el diseño de una forma sistemática, racional y explicable.
En cuanto a las responsabilidades UML define una responsabilidad como “un contrato u obligación de un clasificador”.
Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento.
Básicamente, estas responsabilidades son de los siguientes dos tipos:
Conocer:
* Conocer los datos privados encapsulados.
* Conocer los objetos relacionados.
* Conocer las cosas que puede derivar o calcular.
Hacer:
* Hacer algo él mismo, como crear un objeto o hacer un cálculo.
* Iniciar una acción en otros objetos.
* Controlar y coordinar actividades en otros objetos.
GRASP Se pueden destacar 5 patrones Principales que son:
Solución:Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad.
Patrón Creador
Solución: Asignarle a la clase B la responsabilidad de crear una instancia de clase A en uno de los siguientes casos:
B agrega los objetos A.
B contiene los objetos A.
B registra las instancias de los objetos A.
B utiliza específicamente los objetos A.
B tiene los datos de inicialización que serán transmitidos a A cuando este objeto sea creado.
B es un creador de los objetos A.
Si existe más de una opción, prefiera la clase B que agregue o contenga la clase A.
Patrón Alta Cohesión
Solución: Asignar una responsabilidad de modo que la cohesión siga siendo alta.
Patrón Controlador
Solución: Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase que represente una de las siguientes opciones:
El “sistema” global (controlador de fachada).
La empresa u organización global (controlador de fachada).
Algo en el mundo real que es activo y que pueda participar en la tarea (controlador de tareas).
Un manejador artificial de todos los eventos del sistema de un caso de uso, generalmente denominados “manejador <NombreCasodeUso> (controlador de casos de uso).
Para saber mas visite:
http://jorgesaavedra.wordpress.com/category/patrones-grasp/
Patrones Goft
Nombre del patrón y clasificación
Propósito: qué hace el patrón
También conocido como: otros nombres del patrón (opcional)
Motivación: el problema de diseño
Aplicabilidad: situaciones donde el patrón puede ser aplicado
Estructura: Una representación gráfica de las clases dentro del patrón
Participantes: Las clases y objetos participantes y sus responsabilidades
Colaboraciones: De los participantes para llevar a cabo sus responsabilidades
Consecuencias: trade-offs, preocupaciones, …
Implementación: Hints, Técnicas
Código de Ejemplo : Fragmento de código que muestra una implementación posible
Usos conocidos: Patrones que se encuentran en sistemas reales
Patrones relacionados: Patrones estrechamente relacionados
En mi opinión los patrones deberían ser de los mas utilizados por los programadores, ya que ofrecen demasiadas ventajas y beneficios para nosotros como Ingenieros, estos patrones nos proporcionar la manera correcta de llevar y desarrollar un proyecto, llevándolo por el camino del éxito, permitiendo la reutilización de códigos que manejen una estructura utilizable en cualquier proyecto, es allí donde radica el éxito de los patrones, ya que son buenas practicas y técnicas utilizadas para el desarrollo de proyectos de software.
Antipatrones
Antipatrones de diseño Orientado a Objetos
Arquitectura Cliente -Servidor
Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto.
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.
Beneficios:
Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo).
Reduce el tráfico en la Red.
Opera bajo sistemas abiertos.
Permite el uso de interfaces gráficas variadas y versátiles.
¿Qué es el Cliente?
Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores.
Características:
El Cliente oculta al Servidor y la Red.
Detecta e intercepta peticiones de otras aplicaciones y puede redirigirlas.
Dedicado a la cesión del usuario ( Inicia...Termina ).
El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls).
Funciones Comunes del Cliente:
Mantener y procesar todo el dialogo con el usuario.
Manejo de pantallas.
Menús e interpretación de comandos.
Entrada de datos y validación.
Procesamiento de ayudas.
Recuperación de errores.
¿Qué es el Servidor?
Conjunto de Hardware y Software que responde a los requerimientos de un cliente.
Tipos Comunes de Servidores:
Servidor de Archivos.
Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX).
Servidor de Comunicaciones
Servidor de Impresión.
Servidor de Terminal.
Servidor de Aplicaciones.
Funciones Comunes del Servidor:
Acceso, almacenamiento y organización de datos.
Actualización de datos almacenados.
Administración de recursos compartidos.
Ejecución de toda la lógica para procesar una transacción.
Procesamiento común de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación).
Tomado de http://en.wikipedia.org/wiki/Microsoft_Solutions_Framework
Considero que MSF se basa en un conjunto de pasos o instrucciones para desarrollar un proyecto, brindando así al cliente o usuario el poder escoger la metodología que mejor se adapte a su proyecto y que le proporcione así, menos costos y mas funcionalidad, obteniendo un producto de mayor calidad.
PMI-PMBOK
El project management Body of knowledge (libro de estandares para la gestion de proyectos (PMBOK) es un estandar reconocido internacionalmente (IEEE, ANSI) este trabaja con el uso del conocimiento, de las habilidades, de las herramientas, y de las tecnicas para resolver requisitos del proyecto. La guía del PMBOK define un ciclo vital del proyecto, 5 grupos de procesos y 9 áreas de conocimiento de la tarea de administración de proyectos.
Un equipo de proyectos funciona en 9 áreas de conocimiento con un numero de procesos basicos:
1. Integracion: Desarrolle la carta del proyecto, la declaracion del alcance y el plan. Dirija, maneje, supervise y controle el proyecto de innovacion.
2. Alcance: Planeacion, definicion, creacion, verificacion y control de la estructura de division, de responsabilidades del trabajo.
3. Tiempo: Definicion, secuenciamiento, estimación de recursos necesarios y de la duración, desarrollo y control del cronograma.
4. Costo: Planeamiento de recursos, costos estimados, presupuesto y control.
5. Calidad: Planeamiento de la calidad, aseguramiento de la calidad y control de calidad.
6. Recurso Humano: Planeamiento, contratación, desarrollo y administración del recurso humano.
7. Comunicaciones: Planificación de comunicaciones, distribución de la información, difusión del desempeño.
8. Riesgos: Planeamiento e identificación de riesgos, análisis de riesgos (cualitativa y cuantitativa), planeamiento de la respuesta ante riesgos (acción) y supervision y control del riesgo.
9. Consecución: Plan de contrataciones y adquisiciones, selección e incentivos de los vendedores, administración y cierre de contratos.
Tomado de http://www.12manage.com/methods_pmi_pmbok_es.html
Para mi el PMBOK como se dijo anteriormente es un conjunto de estándares, los cuales deben seguirse a la hora de elaborarse un proyecto, así como en nuestra sociedad hay requisitos y reglas que seguirse, la realización de nuestros proyectos también se basan en el cumplimiento de ciertos pasos, para así lograr éxito en nuestro proyecto.
PRINCE2
PRINCE2 ( PRoyectos EN Controlled Environments) es un método basado en procesos para la eficacia de la gestión de proyectos . Este método se centra en la organización, la gestión y el control.
PRINCE2 es un estándar de facto utilizado extensamente por el Gobierno del Reino Unido y es ampliamente reconocida y utilizada en el sector privado, tanto en el Reino Unido e internacionalmente.
El método PRINCE2 es de dominio público, ofreciendo normas de buenas prácticas en gestión de proyectos . PRINCE2 es una marca registrada de la Oficina del Gabinete.
Las características principales de PRINCE2 son los siguientes:
Su enfoque en la justificación de negocio
Una organización de estructura definida para el equipo de gestión de proyectos
Su producto enfoque basado en la planificación
Su énfasis en la división del proyecto en fases manejables y controlables
Su flexibilidad para ser aplicados en un nivel apropiado para el proyecto.
Para mayor Información Visite http://www.prince2.com/what-is-prince2.asp
Para mi PRINCE es un estándar al igual que los anteriores basado en las normas y requisitos para el desarrollo de los proyectos, para así obtener como resultado buenas practicas y sobre todo calidad y organización en este.
DRA
El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.
Para Saber Mas Visite
http://www.mitecnologico.com/Main/ModeloDesarrolloRapidoAplicaciones
Para mi DRA es una metodología la cual se basa en la rapidez de los proyectos pero con gran funcionalidad, ademas este tipo de metodologías están orientados a la reutilizacion dado que se necesita optimizar el tiempo y es mas factible tomar cosas hechas e incorporarlas a nuevos sistemas.
CRYSTAL
Concebido por Alistair Cockburn, este modelo no describe una metodología cerrada, sino un conjunto de ellas, junto con los criterios para seleccionar y adecuar la más apropiada al proyecto. Los parámetros para determinarla son la criticidad y el tamaño del sistema que se va a construir.
Fundamentos de Crystal
* Desarrollo iterativo e incremental.
* Duración máxima de una iteración: 4 meses.Recomienda duraciones entre 1 y 3 meses.
* Especial énfasis en la importancia de laspersonas sobre los procesos.
* Especial énfasis en la comunicación directa.
* Modelo abierto a la adaptación e introducciónde prácticas de otros modelos ágiles(Extreme Programming, Scrum...)
Tomado de http://es.scribd.com/doc/61815330/44/CRYSTAL
Para mi KRYSTAL es un conjunto de metodologías, la cual ofrece muchas ventajas dado que permite al cliente adoptar un conjunto de pasos de dichas metodologías a los proyectos, brindando así mayor flexibilidad y mayor adaptación en la elaboración y desarrollo de estos.
KANBAN
Es una señal visual que determina cuanto se a consumido y cuanto parar o cuando hacer un cambio. Es una autorización para realizar el trabajo y reabastecer materiales.
Kanban ha demostrado ser útil en equipos que realizan desarrollo Ágil
de software; Kanban es una aproximación a la gestión del cambio. No es un proceso de desarrollo de software o de gestión de proyectos. Kanban es una aproximación a la introducción de cambios en un ciclo de vida de desarrollo de software o metodología de
gestión de proyectos.
Los principales objetivos son:
• Incrementar la fuerza de trabajo
• Minimizar el stock de inventario
• Recortar tiempos muertos
• Incrementar el nivel de servicio al cliente
• Incrementar productividad
• Reducción de desperdicios de materia prima
• Reducción de desperdicio de tiempo
• Reducción de Inventario en Proceso
Tomado de www.tec.com.mx/aplicaciones/twiki/.../KanbanWebInformation.doc
Para mi KANBAN aunque no es una metodología es una muy buena estrategia de optimizacion ya que permite que no hayan desperdicios ni errores, ademas incrementa la productividad en la realización y desarrollo de los proyectos.
TSP
Es una metodología para dirigir el trabajo de mejora y desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural. Conjunto de procesos estructurados que indican qué hacer en cada fase del desarrollo del proyecto y muestra cómo conectar cada fase para construir un producto completo.
Objetivos
* Maximizar calidad Software, Minimizar costos.
* Integrar equipos independientes de alto rendimiento que planeen y registren su trabajo, establezcan metas, y sean dueños de sus procesos y planes.
* Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad.
* Acelerar la mejora continúa de procesos.
* Proveer de una guía para el mejoramiento en organizaciones maduras
CICLO DE VIDA
* Lanzamiento
* Estrategia
* Planeación
* Requerimientos
* Diseño
* Implementación
* Prueba
* Postmortem
Tomado de http://www.slideshare.net/JuanGarcia99/team-software-process-tsp-9839315
Para mi este tipo de metodología ayuda a mejorar el entorno en el cual trabajan los ingenieros y programadores, dividiendo así cada fase para que sea cumplida por cada equipo y luego se construya un producto completo, basándose en la organización y la calidad del software.
PSP
El PSP (Personal Software Process)es un marco de trabajo de procesos para guiara a los desarrolladores en:
* Definir sus propios procesos
* Planear y dar seguimiento a su propio trabajo
* Administrar la calidad de sus propios productos de trabajo
El PSP es un proceso personal que al estar basado en los principios de mejora, ayuda a la gente a establecer sus metas personales, identificar qué métodos utilizarán, medir sus trabajo y analizar los resultados, para ajustar los métodos que utilizan para cumplir sus metas.
En conclusión, el PSP es un proceso definido para ayudar a realizar mejor el trabajo, cuyo objetivo es obtener y reportar datos precisos y completos del trabajo que se realiza a nivel individual, con el fin de mejorar el proceso individual, afectando de esta manera al desempeño de todo el equipo.
Niveles del PSP
* PLANEACIÓN.
* DISEÑO DE ALTO NIVEL
* REVISIÓN DEL DISEÑO DE ALTO NIVEL
* DESARROLLO
* ANÁLISIS DE RESULTADOS
Visite http://www.avantare.com/portal/page.aspx 8,6,162,O,S,0,PAG;CONC;159;13;D;39038085;0;PAG;
Para mi PSP se basa en la meta personal de cada ingeniero para cumplir sus propósitos, el cual se basa en principios para mejorar los ámbitos en los cuales se desarrolla, y así obtener mejor desempeño por parte de los trabajadores.
RUP
El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Tomado de Wikipedia, para ampliar mas esta informacion visite http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
En mis palabras RUP es un proceso basado en el conjunto de metodologías utilizables para la elaboración de proyectos, permitiendo al usuario escoger cualquiera que se adapte a lo que el necesita.
Manifiesto Ágil
Valores del Manifiesto Agil
Valorar más a los individuos y su interacción que a los procesos y las herramientas
Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.
Valorar más el software que funciona que la documentación exhaustiva
Poder ver anticipadamente como se comportan las funcionalidades esperadas sobre prototipos o sobre las partes ya elaboradas del sistema final ofrece una retroalimentación (feedback) muy estimulante y enriquecedor que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá conseguir un documento que contenga requisitos detallados antes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de la documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.
Valorar más la colaboración con el cliente que la negociación contractual
Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.
Valorar más la respuesta al cambio que el seguimiento de un plan
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Principios Del Manifiesto Ágil
Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los principios que de ellos se derivan:
- Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
- Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
- Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
- Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
- Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
- La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
- El software que funciona es la principal medida del progreso.
- Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica enaltece la agilidad.
- La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
- En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
Planning Poker
Es una técnica para calcular una estimación basado en el consenso, en su mayoría utilizado para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. Es utilizado comúnmente en el desarrollo ágil de software, en particular en la metodología Extreme Programming.
Trabajar con planning poker fue muy chevere, como realizamos las estimaciones fue una manera divertida y rapida de estimar la duración de los sprints, ademas de socializar y ver los puntos de vista de cada uno de los integrantes del equipo, fortaleciendo lazos de amistad y buen manejo de los ambientes para un mejor desempeño en el desarrollo del proyecto.
Arquitectura De Software
Arquitectura De Software
La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. (según IEEE Std 1471-2000)
Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
.jpg)
Ejes Fundamentales
Diseño o selección de la arquitectura: Cómo crear o seleccionar una arquitectura con base de requerimientos funcionales, de performance o de calidad.
Representación de la arquitectura: Cómo comunicar una arquitectura.
Evaluación y análisis de la arquitectura: Cómo analizar una arquitectura para predecir cualidades del sistema en que se manifiesta. Un problema semejante es cómo comparar y escoger entre diversas arquitecturas en competencia.
Desarrollo y evolución basados en arquitectura: Cómo construir y mantener un sistema dada una representación de la cual se cree que es la arquitectura que resolverá el problema correspondiente.
Estilo Arquitectónico
Un estilo arquitectónico define una familia de sistemas en términos de un patrón de organización estructural.
Algunos estilos arquitectónicos son:
- Flujo de Datos Secuencial por lotes / Tubos y Filtros.
- Llamada y Retorno Modelo Vista – Controlador (MVC) / Arquitectura Orientada a Objetos.
- Centrado en los Datos (repositorios) Pizarrones o repositorios (Blackboards).
- Distribuidas Cliente-Servidor/ multicapas.
- Heterogéneas Arquitecturas Basadas en Eventos / Arquitecturas Orientadas a servicios.
Modelo Vista- Controlador
Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista.
Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.
La finalidad del modelo es mejorar la reusabilidad por medio del desacople entre la vista y el modelo. Los elementos del patrón son los siguientes:
El modelo es el responsable de:
-Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
- Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: “Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor”.
- Lleva un registro de las vistas y controladores del sistema.
- Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una inserción, etc).
El controlador es el responsable de: - Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
- Contiene reglas de gestión de eventos, del tipo “SI Evento Z, entonces Acción W”. Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método “Actualizar()”. Una petición al modelo puede ser “Obtener_tiempo_de_entrega( nueva_orden_de_venta )”.
Las vistas son responsables de:
-Recibir datos del modelo y los muestra al usuario.
-Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
Pueden dar el servicio de “Actualización()”, para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).
Para mas informacion visite:
http://www.comusoft.com/modelo-vista-controlador-definicion-y-caracteristicas
Para mi opiniòn como estudiante de Ingenieria de Sistemas el modelo vista controlador deberia ser uno de los patrones màs utilizados por los programadores, ya que ademàs de separar los modelos, de las vistas y los controladores nos proporcionan muchas ventajas en cuanto a optimizaciòn de còdigos, porquè? porque cuando separamos el programa en tres (modelo, vista, controlador) puede proporcionarnos que una vista al ser independiente pueda tener varias representaciones de un mismo modelo, un ejemplo claro seria la representacion de datos, como una tabla o como un diagrama de barras, pero todo esto de un mismo modelo. Otra ventaja seria que podemos hacer o generar varias vistas sin modificar o alterar el modelo dado que el obejetivo de este patròn es ser uno independiente del otro.
Patrón
Es aquel que describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de forma tal que esa solución puede ser usada un millón de veces, sin hacerlo de la misma manera dos veces.
C. Alexander, “The Timeless Way of Building”, 1979
Patrón De Diseño
Son aquellos que representan soluciones a problemas que surgen cuando se desarrolla software en un contexto particular.
Estos, facilitan la reutilización de arquitecturas y diseños de software exitoso.
Los patrones de diseño pretenden:
- Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
- Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
- Formalizar un vocabulario común entre diseñadores.
- Estandarizar el modo en que se realiza el diseño.
- Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
- Imponer ciertas alternativas de diseño frente a otras.
- Eliminar la creatividad inherente al proceso de diseño.
Existen varios patrones de diseño, los cuales se clasifican como se muestra a continuación:
Patrones Creacionales: Inicialización y configuración de objetos.
Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.
Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.
- Método de Fabricación ( Factory Method ): Parte del principio de que las subclases determinan la clase a implementar.
- Fábrica Abstracta ( Abstract Factory ): El problema a solucionar por este patrón es el de crear diferentes familias de objetos, como por ejemplo la creación de interfaces gráficas de distintos tipos (ventana, menú, botón, etc.).
- Builder (constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
- Prototype:Se basa en la clonación de ejemplares copiándolos de un prototipo.
- Singleton: Restringe la instanciación de una clase o valor de un tipo a un solo objeto.
- Adaptador (Adapter): Convierte una interfaz en otra.
- Puente (Bridge): Desacopla una abstracción de su implementación permitiendo modificarlas independientemente.
- Objeto Compuesto (Composite): Utilizado para construir objetos complejos a partir de otros más simples, utilizando para ello la composición recursiva y una estructura de árbol.
- Envoltorio (Decorator): Permite añadir dinámicamente funcionalidad a una clase existente, evitando heredar sucesivas clases para incorporar la nueva funcionalidad.
- Fachada (Facade): Permite simplificar la interfaz para un subsistema.
- Peso Ligero (Flyweight): Elimina la redundancia o la reduce cuando tenemos gran cantidad de objetos con información idéntica.
- Apoderado (Proxy): Un objeto se aproxima a otro.
Patrones de Comportamiento
- Intérprete (Interpreter): Intérprete de lenguaje para una gramática simple y sencilla.
- Método plantilla (Template Method): Algoritmo con varios pasos suministrados por una clase derivada.
- Cadena de responsabilidad (Chain of responsibility): La base es permitir que más de un objeto tenga la posibilidad de atender una petición.
- Orden (Command): Encapsula una petición como un objeto dando la posibilidad de “deshacer” la petición.
- Iterador (Iterator): Define una interfaz que declara los métodos necesarios para acceder secuencialmente a una colección de objetos sin exponer su estructura interna.
- Mediador (Mediator): Coordina las relaciones entre sus asociados. Permite la interacción de varios objetos, sin generar acoples fuertes en esas relaciones.
- Recuerdo (Memento): Almacena el estado de un objeto y lo restaura posteriormente.
- Observador (Observer): Notificaciones de cambios de estado de un objeto.
- Estado (Server): Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.
- Estrategia (Strategy): Utilizado para manejar la selección de un algoritmo.
- Visitante (Visitor): Operaciones aplicadas a elementos de una estructura de objetos heterogénea.
Para mas Informacion visite:
http://msdn.microsoft.com/es-es/library/bb972240.aspx
Patrones Grasp
General Responsability Assignment Software Patterns,
Patrones de Principios Generales para Asignar Responsabilidades
Constituyen la base del CÓMO se diseñará el sistema. Se aplican en los primeros momentos del diseño.
Los patrones GRASP describen los principios fundamentales de diseño de objetos para la asignación de responsabilidades. Constituyen un apoyo para la enseñanza que ayuda a entender el diseño de objeto esencial y aplica el razonamiento para el diseño de una forma sistemática, racional y explicable.
En cuanto a las responsabilidades UML define una responsabilidad como “un contrato u obligación de un clasificador”.
Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento.
Básicamente, estas responsabilidades son de los siguientes dos tipos:
Conocer:
* Conocer los datos privados encapsulados.
* Conocer los objetos relacionados.
* Conocer las cosas que puede derivar o calcular.
Hacer:
* Hacer algo él mismo, como crear un objeto o hacer un cálculo.
* Iniciar una acción en otros objetos.
* Controlar y coordinar actividades en otros objetos.
GRASP Se pueden destacar 5 patrones Principales que son:
- Experto.
- Creador.
- Alta cohesión.
- Bajo acoplamiento.
- Controlador.
Solución:Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad.
Patrón Creador
Solución: Asignarle a la clase B la responsabilidad de crear una instancia de clase A en uno de los siguientes casos:
B agrega los objetos A.
B contiene los objetos A.
B registra las instancias de los objetos A.
B utiliza específicamente los objetos A.
B tiene los datos de inicialización que serán transmitidos a A cuando este objeto sea creado.
B es un creador de los objetos A.
Si existe más de una opción, prefiera la clase B que agregue o contenga la clase A.
Patrón Alta Cohesión
Solución: Asignar una responsabilidad de modo que la cohesión siga siendo alta.
Patrón Controlador
Solución: Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase que represente una de las siguientes opciones:
El “sistema” global (controlador de fachada).
La empresa u organización global (controlador de fachada).
Algo en el mundo real que es activo y que pueda participar en la tarea (controlador de tareas).
Un manejador artificial de todos los eventos del sistema de un caso de uso, generalmente denominados “manejador <NombreCasodeUso> (controlador de casos de uso).
Para saber mas visite:
http://jorgesaavedra.wordpress.com/category/patrones-grasp/
Patrones Goft
Nombre del patrón y clasificación
Propósito: qué hace el patrón
También conocido como: otros nombres del patrón (opcional)
Motivación: el problema de diseño
Aplicabilidad: situaciones donde el patrón puede ser aplicado
Estructura: Una representación gráfica de las clases dentro del patrón
Participantes: Las clases y objetos participantes y sus responsabilidades
Colaboraciones: De los participantes para llevar a cabo sus responsabilidades
Consecuencias: trade-offs, preocupaciones, …
Implementación: Hints, Técnicas
Código de Ejemplo : Fragmento de código que muestra una implementación posible
Usos conocidos: Patrones que se encuentran en sistemas reales
Patrones relacionados: Patrones estrechamente relacionados
En mi opinión los patrones deberían ser de los mas utilizados por los programadores, ya que ofrecen demasiadas ventajas y beneficios para nosotros como Ingenieros, estos patrones nos proporcionar la manera correcta de llevar y desarrollar un proyecto, llevándolo por el camino del éxito, permitiendo la reutilización de códigos que manejen una estructura utilizable en cualquier proyecto, es allí donde radica el éxito de los patrones, ya que son buenas practicas y técnicas utilizadas para el desarrollo de proyectos de software.
Antipatrones
- Son aquellos formulados para no escoger malos caminos, es decir, es la contrapartida natural al estudio de los patrones de diseño.
- El estudio formal de errores que se repiten permite reconocer y reconducir los elementos involucrados hacia una mejor solución.
- Descripción de las cosas que no debes hacer
Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. Son una extensión natural a los patrones de diseño. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores más comunes relacionados con la industria del software. Un buen antipatrón explica por qué la solución original parece atractiva, por qué se vuelve negativa y cómo recuperarse de los problemas que ésta genera.
Existen muchos antipatrones, por lo tanto mencionaré algunos antipatrones los cuales son:Antipatrones de diseño Orientado a Objetos
- Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que no añade modificación alguna.
- Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito.
- Modelo de dominio anémico (anemic domain model): Usar un modelo del dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado.
- Objeto sumidero (object cesspool): Reusar objetos no adecuados realmente para el fin que se persigue.
- Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una única parte del diseño (clase).
- Poltergeist: Emplear objetos cuyo único propósito es pasar la información a terceros objetos.
- Código ravioli (ravioli code): Construir sistemas con multitud de objetos muy débilmente conectados.
- Comprobación de tipos en lugar de interfaz (checking type instead of interface): Comprobar que un objeto es de un tipo concreto cuando lo único que se necesita es verificar si cumple un contrato determinado.
- Confianza ciega (blind faith): Descuidar la comprobación de los resultados que produce una subrutina, o bien de la efectividad de un parche o solución a un problema.
- Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar.
- Fallo de caché (caching failure): Olvidar restablecer una marca de error cuando éste ya ha sido tratado.
- Lava seca (lava flow): Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante. Esto es análogo a un flujo de lava en el que se van endureciendo pedazos de roca. La solución incluye un proceso de gestión de la configuración que elimina el código muerto y permite evolucionar o rehacer el diseño para acrecentar la calidad.
Antipatrones Metodológicos
- Bala de plata (silver bullet): Asumir que nuestra solución técnica favorita puede resolver un problema mucho mayor.
- Desarrollo conducido por quien prueba (tester driven development): Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de los informes de errores.
- Desfactorización (de-factoring): Eliminar funcionalidad y reemplazarla con documentación.
- Factor de improbabilidad (improbability factor): Asumir que es improbable que un error conocido cause verdaderos problemas.
- Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.
Antipatrones de Gestión
- Todo lo que tienes es un martillo (all you have is a hammer): Gestión gris y plana, incapaz de tratar a los subordinados de manera personalizada y acorde con sus necesidades particulares.
- Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de "éxito a cualquier precio".
- Dos caras (doppelganger): Coordinador o compañero que en un determinado momento puede ser agradable y de trato fácil, pero igualmente puede volverse irracional y despiadado de modo inesperado.
- Rodeos improductivos (fruitless hoops): Gestor o coordinador que solicita grandes cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una decisión.
- Niñito de oro (golden child): Situación en la que ciertas responsabilidades, oportunidades, reconocimientos o recompensas van a parar a un determinado miembro del equipo como consecuencia de una relación personal o en clara contradicción con su rendimiento real.
- Pollo sin cabeza (headless chicken): Se aplica al gestor, coordinador o responsable que vive en una permanente situación de pánico y medidas desesperadas.
- Líder pero no gestor (leader not manager): Un buen líder no tiene por qué ser necesariamente un buen gestor, coordinador o responsable.
Tomado de:
http://msdn.microsoft.com/es-es/library/bb972251.aspx
http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o
Como estudiante de Ingeniería de Sistemas, en mi experiencia me ha pasado que en la realización y desarrollo de los proyectos de software, dicho proyecto algunas veces no me funcione o haga lo que pide el cliente, en este caso el docente, esto se dio ya que muchas veces programamos de manera en que solo nos corra el programa, reutilizando códigos que están malos y que hacen que el proyecto termine fracasando, todo esto se debe al mal manejo y al uso constante de antipatrones, como lo dijimos anteriormente los antipatrones son formulados para no escoger malos caminos, es decir muestran las diferentes situaciones que terminan en fracaso con el fin de que no vuelvan a pasar, es por ello que hoy por hoy es recomendable el uso de patrones los cuales representan soluciones a problemas que surgen cuando se desarrolla software, para así aumentar el éxito del proyecto.
http://msdn.microsoft.com/es-es/library/bb972251.aspx
http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o
Como estudiante de Ingeniería de Sistemas, en mi experiencia me ha pasado que en la realización y desarrollo de los proyectos de software, dicho proyecto algunas veces no me funcione o haga lo que pide el cliente, en este caso el docente, esto se dio ya que muchas veces programamos de manera en que solo nos corra el programa, reutilizando códigos que están malos y que hacen que el proyecto termine fracasando, todo esto se debe al mal manejo y al uso constante de antipatrones, como lo dijimos anteriormente los antipatrones son formulados para no escoger malos caminos, es decir muestran las diferentes situaciones que terminan en fracaso con el fin de que no vuelvan a pasar, es por ello que hoy por hoy es recomendable el uso de patrones los cuales representan soluciones a problemas que surgen cuando se desarrolla software, para así aumentar el éxito del proyecto.
Arquitectura Cliente -Servidor
Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto.
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.
Beneficios:
Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo).
Reduce el tráfico en la Red.
Opera bajo sistemas abiertos.
Permite el uso de interfaces gráficas variadas y versátiles.
¿Qué es el Cliente?
Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores.
Características:
El Cliente oculta al Servidor y la Red.
Detecta e intercepta peticiones de otras aplicaciones y puede redirigirlas.
Dedicado a la cesión del usuario ( Inicia...Termina ).
El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls).
Funciones Comunes del Cliente:
Mantener y procesar todo el dialogo con el usuario.
Manejo de pantallas.
Menús e interpretación de comandos.
Entrada de datos y validación.
Procesamiento de ayudas.
Recuperación de errores.
¿Qué es el Servidor?
Conjunto de Hardware y Software que responde a los requerimientos de un cliente.
Tipos Comunes de Servidores:
Servidor de Archivos.
Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX).
Servidor de Comunicaciones
Servidor de Impresión.
Servidor de Terminal.
Servidor de Aplicaciones.
Funciones Comunes del Servidor:
Acceso, almacenamiento y organización de datos.
Actualización de datos almacenados.
Administración de recursos compartidos.
Ejecución de toda la lógica para procesar una transacción.
Procesamiento común de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación).
