jueves, 3 de mayo de 2012

Calidad De Software.



La "Calidad del Software consiste en desarrollar productos lógicos que, cumpliendo las normas, satisfagan las necesidades del usuario, los requisitos implícitos (a menudo, no mencionados) y que tiendan a cero defectos.” Para conseguir un software de calidad es necesario realizar una serie de tareas a lo largo de todo el proceso de desarrollo de la aplicación. Es lo que se conoce como la garantía de calidad del software (SQA: “Software Quality Assurance”).Según Pressman:“La garantía de 
calidad delsoftware es un diseño planificado y sistemático de acciones que se requieren para asegurar la calidad del software”.
 Según (Pressman, 1995), basándose en los estudios de (McCall, 1977), los factores que afectan a la calidad del software se centran en tres aspectos importantes de un producto software: sus característicasoperativas, su capacidad de soportar los cambios (revisión del producto) ysu adaptabilidad a nuevos entornos (o transición del producto).

"La calidad de un producto es ampliamente gobernada por la calidad del proceso usado para construirlo“
Mark C. Paulk


Definiciones de calidad 


-Es un conjunto de propiedades asociadas a un objeto que le confieren capacidad para satisfacer necesidades implícitas o explícitas.
-La calidad de un producto o servicio es la percepción que el cliente tiene del mismo, es una fijación mental del consumidor que asume conformidad con dicho producto o servicio y la capacidad del mismo para satisfacer sus necesidades.
-La calidad significa aportar valor al cliente, esto es, ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible

ASEGURAMIENTO



Son las medidas preventivas que se toman paso a paso durante un proceso para evitar que el resultado final no sea defectuoso

Gestion De La Calidad De Software.

-Es la actividad esencial para asegurar la calidad de sus productos,y la competitividad frente a la oferta del mercado.
-Conjunto de acticidades de la funcion general de la direccion que determina la calidad, los objetivos y las responsabilidades.

Modelos De Calidad.


Son aquellos documentos que integran la mayor parte de las mejores practicas,proponen temas de administracion en los que cada organizacion debe hacer enfasis,integran diferentes practicas dirigidas a los procesos claves ademas, permiten medir los avances en calidad.

Estandares De Calidad.


Son aquellos que permiten definir un conjunto de criterios de desarrollo.guian la forma en que se aplica la ingenieria de software,ademas suministran los medios para que todos los procesos se realicen de la misma forma.


Estructura De Un Modelo De Calidad De Software.


- Factores De Calidad


Representan la calidad  desde el punto de vista del usuario y son las caracteristicas que componen la calidad, tambien se denominan atributos de calidad extremos.


- Criterios de Calidad Del Producto.


Estos criterios son atributos que, cuando esten presentes, contribuyen al aspecto de la calidad  que el factor asociado representa.Se trata de una vision de la calidad desde el punto de vista del producto de software. Tambien se denominan atributos de calidad internos.


- Metricas Del Producto.


Muestra cuales son las medidas cuantitativas de ciertas caracteristicas del producto que, cuando estan presentes,dan una indicacion del grado en que dicho producto posee un determinado atributo de calidad.

Reflexiones.


- Un software debe asegurar la obtencion de los beneficios de negocio a unos costos razonables.
- La calidad es el aliado de la planificación, no su adversario. Si sacrificamos la calidad por la planificación lo estamos haciendo mal.

miércoles, 2 de mayo de 2012

Diagrama De Arquitecturas.


Diagrama De Arquitecturas.


Mitos De Un Ingeniero De Software.


Un ingeniero de software contempla la capacidad de desarrollar, gestionar, evaluar y dirigir un proyecto de software utilizando todos los elementos y técnicas las cuales garanticen el correcto éxito del los procesos, de los equipos y del servicio para garantizar un proyecto de alta calidad.

En la actualidad todo lo que concebimos y vivimos a diario esta altamente ligado con la tecnología, con el ingenio que tubo el hombre para hacer mejores las cosas debido a sus necesidades ahora bien ¿Qué tiene que ver la tecnología con los ingenieros de software? pues la tecnología es la base de nuestra profesión por esto debemos estar totalmente ligados a esta, ya que esta va evolucionando día a día para darnos mejores frutos y mejoras en los artefactos existentes y nuevos. Pero pasa algo mas importante con esta porque no solo nos beneficiamos nosotros sino además las empresas y entidades las cuales siempre quieren estar a la vanguardia de mejores tecnologías en sus sistemas contables y ahí entramos nosotros los ingenieros de sistemas y los ingenieros de software ya que nosotros además de producir software maximizamos la calidad y minimizamos el coste además de brindarles una alta organización en sus datos, garantizándoles el éxito a las empresas.
Hoy en día se han creado muchos mitos los cuales involucran nuestra profesión como ingenieros de software las cuales son ideas muy equivocadas tales como “un ingeniero de software debe saber desde todo el contenido de un computador hasta su funcionamiento” ya que muchas personas entrelazan la ingeniería con computadores y esto es algo equivocado ya que el ingeniero de software además de producir software se encarga de los aspectos de evaluación, pruebas de verificación y validación de mantenimiento de un proyecto, como ingenieros de software debemos ser capaces de encabezar o ser miembro de grupos multidisciplinarios de desarrollo de todo tipo de software y que en equipo podamos lograr producir software de alta calidad pero desde luego que un ingeniero de software debe saber de toda esta temática planteada como lo son el correcto funcionamiento de u computador ya que es un elemento el cual usa diariamente pero no necesariamente debe ser un experto en el tema.
Otro mito algo singular es decir que los ingenieros de sistemas o ingenieros de software trabajan con computadores aunque los computadores hoy en día son una gran auge ya que tienen en si una gran tecnología, un ingeniero de sistemas no solo trabaja con computadores pues hay que tener en cuenta de que todavía existen muchas empresas sobretodo las pymes las cuales utilizan sistemas de facturación por decirlo así ”A lápiz y papel” estas todavía dependen de sistemas contables basados en libros y ajenos a una automatización electrónica pero claro que estos son una gran desventaja ya que su sistema puede resultar lento pero igual no dejan de ser funcionales he visto este caso por ejemplo en bibliotecas y farmacias las cuales toda su información es guardada en libros.
Otro mito el cual me gusta resaltar es que “un ingeniero de software debe saber programar”, púes opino que es importante que un ingeniero de sistemas o un ingeniero de software debe saber programar pero también es claro que para por ejemplo administrar información en una empresa no se necesita de esto más bien programan los que les gusta la materia y se desenvuelven bien en esto.
Por último quiero agregar un mito algo interesante “Los ingenieros de sistemas deben saber todo sobre sistemas operativos” para mi opinión no creo pues porque no necesariamente debe ser así porque los sistemas operativos pueden diseñarse  con independencia de cualquier plataforma, más bien todo esto puede ser verdad pero para la persona que le guste esta temática.
Ahora bien como estudiante de ingeniería de sistemas me veo en un futuro como una gran ingeniera y empresaria adoptando y empleando todos los conceptos que en mi carrera he estudiado trabajando en una gran empresa e incluso ajuntando para tener la mía propia ,por otro lado mis papas los cuales se han esforzado mucho porque yo salga adelante con mi carrera me ven en el futuro pues con una gran oficina y andando un computador e incluso manipulando maquinas como muchas veces he hablado con mis papas y sobretodo mi papa me cuenta de la empresa en la cual trabaja. Al contrario de la sociedad ya que esta te puede ver de diferentes ámbitos como desde un ingeniero completo e incluso uno incompleto depende de sus requerimientos, por esto pueden pensar de que solo estudiamos una carrera y nos podemos por decirlo así “ganar el dinero fácil” sin pensar todo el esfuerzo que nos ha tocado llegar a donde podamos estar, por otro lado un colega ingeniero de software nos puede ver como un profesional capacitado para enfrentarse a cualquier escenario que se pueda presentar al dirigir un proyecto ya que nos debemos basar en todos los elementos requeridos para obtener un proyecto de alta calidad teniendo en cuenta el correcto éxito de los procesos, de los servicios y del equipo como tal, ósea un ingeniero capaz de entregar soluciones propias y garantizar el correcto éxito de un entregable para ofrecer un servicio de calidad pero considero que aun me falta mucho por recorrer para ser un ingeniero de sistemas completo.

En conclusión la ingeniería de sistemas está altamente ligada a la tecnología pero hay muchos mitos los cuales debemos borrar ya que muchas personas pueden pensar que no sabes, o para que estudiaste o incluso que eres un mal profesional, igual para mi opinión creo que un ingeniero de sistemas debe ser completo debe saber de todo un poco para garantizar su buen trabajo en cualquier empresa ofreciéndole a cualquier cliente un producto o un servicio de alta calidad ya que esto en el futuro se vea reflejado.


Mitos de Un Ingeniero De Software
Lisbeth Paola Macías Cantillo
Universidad Simón Bolívar
Ingeniería de Sistemas 7ª Diurno

sábado, 7 de abril de 2012

Conceptos (RMI,CORBA,BPM,BPML)

RMI


La idea que sustenta RMI es un ideal recurrente en tecnologías de Orientación a Objetos: hacer que un objeto invoque a otro objeto remoto con independencia de la JVM o el servidor en el que se encuentra, como si fuera un objeto local. Transparencia respecto a la máquina.

Hay dos posibilidades:
  • El objeto servidor no está escrito en Java. Necesitamos algún sistema para que los objetos puedan hablar entre sí sin importar el lenguaje de codificación. En este sentido la solución más común es CORBA (Common Object Request Broker Architecture) del OMG (Object Management Group).

  • El objeto está en Java. Entonces usamos RMI, que es una tecnología más sencilla que CORBA. Antes de la versión 1.3 RMI sólo podía usar JRMP (Java Remote Method Protocol). Paro a partir de la versión 1.3 podemos usar además IIOP (Internet Inter-ORB) de OMG.
¿Cómo es posible que el objeto cliente pueda invocar al objeto remoto? Hay varias cosas que debemos tener, una de ellas es un interfaz para el objeto remoto. Un concepto fundamental es que el cliente sólo puede invocar al objeto remoto a través de su interfaz remota. La interfaz remota es el "escaparate" del objeto remoto, es el modo en que el objeto remoto "exporta" sus servicios. Aquello a lo que el cliente accede está en el interfaz del objeto remoto. Lo que no significa que el objeto remoto no tenga otros métodos, claro que puede tenerlos; pero sólo los métodos que estén en su interfaz son invocados por el cliente.

Arquitectura RMI






Las tres capas de RMI:

  • Capa de transporte: basada en TCP/IP.

  • Capa de sesión: conecta clientes con objetos remotos en una referencia de uno-a-uno.

  • Capa de presentación. La expresión "presentación" debe entenderse en el sentido OSI, es la capa que traduce los datos de sesión a la capa de aplicación y viceversa.

La capa de aplicación  del cliente traduce su invocación a una llamada al objeto Stub, que se traduce a JRMP, después a TCP, hasta llegar al nivel de hardware del cliente, que la envía al hardware donde está el objeto remoto. Aquí se recorre el orden inverso, desde el hardware hasta la capa de aplicación. Esta arquitectura mantiene la flexibilidad. Podemos reemplazar una sin afectar a la eficacia del conjunto. Por ejemplo, podemos usar UDP (User Datagram Protocol) en lugar de TCP.

Tomado de : 
http://www.proactiva-calidad.com/java/rmi/introduccion.html



BPM

Se llama Gestión o administración por procesos de negocio (Business Process Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de negocio, que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. El Modelo de Administración por Procesos, se refiere al cambio operacional de la empresa al migrar de una operación funcional a una operación de administrar por procesos.


Ventajas del modelo

Un proceso se puede ver como un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.
A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, y ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y actuar sobre ellos para optimizarlos.
Tomado dhttp://es.wikipedia.org/wiki/Gesti%C3%B3n_de_procesos_de_negocio

CORBA


CORBA es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas, de tal forma que el programador no se tiene que ocupar de tratar con sockets, flujos de datos, paquetes, sesiones etc. CORBA oculta todos estos detalles de bajo nivel. No obstante CORBA también brinda al programador una tecnología orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funciones normales dentro de su programa.
Veamos un ejemplo:


Esta función ejecutaría el método setMode sobre el objeto object, para el programador esta llamada es como una operación local, no hay más complejidad.
Los métodos y datos CORBA se agrupan formando lo que se demoninan interfaces, los interfaces pueden ser interpretados como objetos que grupan datos y métodos para acceder a estos. Todos estos interfaces se definen usado un lenguaje IDL (Interface Definition Language), que es precisamente esto, un lenguaje para la definición de interfaces. Este lenguaje es estandar y lo soportan todas las implementaciones CORBA.
es algo más que una abstracción que oculta la complejidad de red, -> TODAS LAS LLAMAS PARA EL PROGRAMADOR SON IGUALES -> SE DEFINEN OBJETOS Y METODOS -> LOS OBJETOS SON REMOTOS -> NO PORQUE CORBA OCULTE COSAS DEBEMOS DEJAR DE PENSAR EN LA EFICIENCIA DE RED Hay una multitud de sistemas con un propósito muy similar a CORBA circulando por el mundo, los más usados son: el RPC (Remote Procedure Call) de Sun Microsystems y DCOM (Distributed que los desarrolladores de GNOME han adoptado es individuales CORBA -> muy importante especificación, OMG


BPML 








Business Process Modeling Language (BPML) es un lenguaje para el modelado de procesos de negocio.BPML fue una propuesta de lenguaje, pero ahora el BPMI ha abandonado el soporte para esto en favor de BPEL4WS (Business Process Execution Language para Web Services)A partir de 2008, BPML También se ha
informado que ha sido descartado en favor de BPDM (Business Process metamodelo Definición ). BPMI tomó esta decisión cuando fue adquirida por la OMG con el fin de tener acceso a su especificación popular, BPMN ( Business Proceso de Modelo y notación ). Esta notación ha sido útil a OMG a fin de enriquecer con la notación UML proceso.
BPML, un superconjunto de BPEL, se llevó a cabo por los proveedores de la fase inicial, como Intalio Inc., pero los operadores tradicionales como IBM y Microsoft no ha aplicado BPML en su actual flujo de trabajo y las implementaciones de integración del motor (BizTalk Server, Websphere, etc.) Por lo tanto, abogó por un lenguaje más simple, BPEL. Hoy en día, las implementaciones de código abierto de BPML siguen siendo superiores a la capacidad de estos productos comerciales. Esto llevó a algunos a decir que BPML contra BPEL fue un caso de VHS contra Betamax. La analogía no es del todo correcto. Para VHS y Betamax tanto te permiten ver video - incluso si una aplicación se impuso. Eso no es el caso de BPML y BPEL. BPML fue diseñado como un lenguaje formal completa, capaz de modelar cualquier proceso, y, a través de un BPMS ( Business Process Management del sistema), implementado como un proceso de software ejecutable sin la generación de cualquier código de software. Esto no es posible con BPEL, desde BPEL no es un lenguaje de proceso completo. Para ilustrar esto, tenga en cuenta que BPEL se utiliza a menudo en combinación con Java para llenar los "desaparecidos" semántica. Además, BPEL está a menudo relacionado con implementaciones propietarias de motores de flujo de trabajo o de corredores de integración.Considerando que, BPML fue diseñado e implementado, como un motor de procesamiento de pura concurrente y distribuida.







Diferencias y Similitudes Entre Varias Arquitecturas


1. ES LO MISMO CLIENTE SERVIDOR QUE SOA

Para nuestro concepto tanto SOA como la arquitectura c/s son arquitecturas de gran importancia ya que la primera es la lógica del negocio y la segunda es la arquitectura en la cual se distribuye la información, Al contrario de las arquitecturas orientadas a objetos, SOA está formada por servicios de aplicación con acoplamiento débil y altamente interoperable.
Una diferencia clara de SOA con la arquitectura c/s es que esta está orientada a procesos y enfocada al cambio. De esta forma las empresas TI se benefician mucho ya que con esta pueden reconfigurar rápidamente sus recursos de TI sin necesidad de realizar una integración profunda, lo cual les permite liberar recursos para abrir espacio a la innovación y a la alta calidad.

2. ES LA  ARQUITECTURA CLIENTE SERVIDOR LA BASE DE SOA

La arquitectura C/S si es la base de SOA ya que SOA es una evolución de esta, aunque hay que tener en cuenta que SOA puede ser claramente independiente de la arquitectura C/S ya que esta es la lógica del negocio.
Como evolución de la arquitectura C/S esta contempla en si unos puntos claros de la arquitectura c/s Tales como:
-las funciones de la interface del usuario
- la lógica de las aplicaciones
- la administración de los datos, están separados de forma que cada una puede ser implementada usando las plataformas y las tecnologías que mejor se adapten a la tarea.
SOA incorpora servicios que corren en distintas plataformas y estos  están alojados en distintos servidores.

3. COMO SE ACOPLA SOA Y C/S CON SAAS Y ASP

Siendo SOA una evolución de la arquitectura cliente servidor enfocándose a los servicios podemos decir que hay una alta relación con las arquitecturas saas y asp ya que siendo ASP un proveedor de servicios, Y SASS un modelo de distribución de software podemos contemplar que todos están con un mismo fin satisfacer las necesidades del cliente ofreciendo en si un servicio o un software de calidad.
Aunque existen diferencias notables entre estas arquitecturas como por ejemplo ASP siendo proveedor de software este ofrece sus servicios a múltiples clientes y este puede adaptar dicho software a su modo para garantizar su necesidad en cambio en SAAS estando esta en la nube presta sus servicios a muchos clientes con la clara diferencia de que estos solo pueden acceder a este sin modificarlo un ejemplo claro de este es gmail y siendo SOA una arquitectura orientada a servicios en donde su claro objetivo no es más que darle soporte a los requisitos del negocio y contemplando la clara perspectiva de que la arquitectura c/s no garantiza la buena lógica de negocios ya que esta presentaba La congestión del tráfico ya que esta siempre ha sido un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultáneas al mismo servidor, puede ser que cause muchos problemas para éste ya que a mayor número de clientes, más problemas para el servidor por este motivo fue creado SOA ya que este satisface dichos problemas. Entonces como conclusión podemos decir que estas arquitecturas buscan la mejora de las tecnologías en sí, ya que un cliente siempre lo que espera en un software o en un servicio es la seguridad, la fiabilidad y la disponibilidad estas están en la clara respuesta sobre estos planteamientos ofreciéndonos siempre un servicio o un software de alta calidad garantizándonos éxitos a nosotros como clientes.

4. ESTANDARES DE SOA

Service Component Architecture (SCA): En el post pasado dijimos que esta especificación provee un modelo para la creación de componentes de servicios dentro de una solución de negocios, es decir las actividades las cuales están en el corazón de las aplicaciones. SCA provee un modelo de programación para crear componentes de servicios escritos ya sea en Java, BPEL, C++ o lenguajes declarativos como XSLT.

Service Data Objects (SDO): Establece un significado consistente a los datos que operan entre diversas aplicaciones sin importar la fuente o el formato de las mismas.Ofrece un mecanismo para unificar datos de diversas bases de datos y servicios.

Business Process Execution Language (BPEL): Provee un estándar de procesos de negocio empresarial para la ejecución y orquestación. Usando BPEL se pueden diseñar procesos de negocio que integran servicios discretos dentro de un flujo de proceso de presentación final. Esta integración reduce tremendamente los costos de proceso y complejidad.

Transformaciones XSL (XSLT): Procesa documentos XML y transforma datos de un esquema de documento XML en otro. 

Java Connector Architecture (JCA): Provee una solución en tecnología Java para la conexión entre diversos servidores de aplicaciones.
Java Messaging Service (JMS): Provee un estándar de mensajeo para comunicar diversas aplicaciones basadas en Java 2 y Enterprise Edition (Java EE) a través de sistemas heterogéneos.

Archivos Web Services Description Language (WSDL): Proporcionan los puntos de entrada en una aplicación compuesta SOA (composite application). El archivo WSDL proporciona un lenguaje estándar reducido y es la base para entender las capacidades de un servicio. El Simple Object Access Protocol (SOAP) proporciona el protocolo de red para la entrega de mensajes.

http://oscaryani.blogspot.com/2010/07/estandares-adoptados-por-oracle-soa.html


5. SOA NO ES LO MISMO QUE WEBSERVICES ¿Por qué?

SOA y servicios web son dos cosas diferentes ya que estos  son la preferencia basada en estándares  al contrario de SOA ya que este se puede implementar con múltiples tecnologías tales como MOM, CORBA, COBOL ETC.

SOA  es un mecanismo de intercambio de información dentro de los muchos que se utilizan,  para conectar o transmitir información de las aplicaciones. Estos son estándares, lo que comúnmente utilizamos. Es importante concretar que Web Services no es SOA, sino un mecanismo de intercambio de información.

Aunque hay que tener en cuenta que cuando se desea conseguir la máxima reutilización de información  se pueden utilizar los estándares más ampliamente soportados teniendo en cuenta aspectos como la reutilización de funcionalidades por otros consumidores, Reutilización de funcionalidades de otros servicios, Aprovechamiento de otras herramientas y Conocimiento del personal.

En conclusión podemos decir que SOA es una abstracción del éxito de los servicios web para integración de sistemas de información ofreciendo así un gran alto potencial ,bajos costos , alta integración y de gran flexibilidad favoreciendo en si la automatización de las relaciones de negocio a negocio a través de Internet. 

miércoles, 1 de febrero de 2012






Mi nombre es Lisbeth Paola Macias Cantillo tengo 20 años, termine mis estudios de bachiller en el Colegio CODEBA,actualmente me encuentro estudiando séptimo semestre de ingeniería de sistemas en la universidad Simón Bolívar.
soy una persona con principios éticos y valores,en el plano profesional me considero como una persona capaz de dar soluciones a todo tipo de problemas planteados en el manejo y manipulación de la información aplicando análisis, diseño y construcción de soluciones informáticas que se ajusten a las necesidades y condiciones de cualquier organización,con espíritu critico y creativo,disciplinada con hábitos y competencias para el aprendizaje permanente a lo largo de toda la vida,capaz de adaptarme al cambio en cualquier entorno y con estilo pro activo.


Ahora anexare todos los términos consultados.

Nota: Los enlaces utilizados para mi investigación aparecen al arrastrar el mouse sobre ellos a continuación de las palabras "Tomados de".

CMMI


Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.
Desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002.
Es empleado para guiar las mejoras de procesos durante el desarrollo de un proyecto, un departamento o hasta una organización.
El modelo de Capacidad y Madurez, es un método de definir y gestionar los procesos a realizar por una organización.
El modelo de calidad CMM aparece con la necesidad de mitigar los problemas que se presentan continuamente al momento de contratar empresas desarrolladoras de software, por la progresiva elevación de costos y desfase de las fechas de entrega.


Integra disciplinas como sistemas y software en un solo marco de trabajo,Describe formas efectivas y probadas de hacer las cosas, no es un enfoque radical.

Algunos de los objetivos del CMMI y que son buenos para el negocio.

  • Producir servicios y Productos de alta calidad.
  • Crear valor para los accionistas.
  •  Mejorar la satisfacción del cliente.
  •  Incrementar la participación en el mercado.
  • Ganar reconocimiento en la industria.
En Mi concepto el CMMI es un modelo de alta calidad, su principal característica es implementar proyectos de empresas sean grandes o medianas empresas dándoles a estas mayor desempeño en la calidad y menores riesgos en el desarrollo del proyecto por medio de pruebas experimentales para garantizar la calidad de los proyectos y así dándole credibilidad a la compañía.


                  svn.assembla.com/...importantes/EXP_CMMI_jPerdigon-1CMMIv1


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.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.


Para mi Concepto Openup esta basado en el desarrollo agil,ya que este se utiliza para proyectos que se necesitan rápidamente, Aqui los requerimientos mas importantes del cliente son los mas importantes y son entregables de inmediato por esto se basan en el desarrollo incremental.



Tomado de http://cbasqa.wordpress.com/2008/09/02/proceso-de-desarrollo-openup/



XP

Según David Valverde La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías Ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que se produce al utilizar otras ‘metodologías pesadas’.Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar

Para mi concepto XP es una metodologia Agil ya que esta es capaz de adptarse a cualquier cambio el cual sea requerido por el cliente ya que este al principio solo se toma un diseño el cual permita ser cambiado multiples veces sin afectar el sistema entregando un producto final sin ninguna alteracion a la calidad de este.



SCRUM



Según Wikipedia  Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental 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: Scrum de Scrums.

 Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que representa a los stakeholders (interesados externos o internos), y el Tema que incluye a los desarrolladores.


Para mi concepto Scrum esta basado en el desarrollo Incremental con la diferencia que aqui se prevee una duracion llamada "SPRING" la cual debe ser de 2 a 4 semanas priorizando los requerimientos mas importantes.


ITIL

Según Alejandro Hernandez y otros sitios consultados  ITIL  (Information Technology Infrastructure Library) o Librería de Infraestructura de Tecnologías de Información. Esta metodología es la aproximación más globalmente aceptada para la gestión de servicios de Tecnologías de Información en todo el mundo, ya que es una recopilación de las mejores prácticas tanto del sector público como del sector privado.
ITIL como metodología propone el establecimiento de estándares que nos ayuden en el control, operación y administración de los recursos (ya sean propios o de los clientes). Plantea hacer una revisión y reestructuración de los procesos existentes en caso de que estos lo necesiten (si el nivel deficiencia es bajo o que haya una forma más eficiente de hacer las cosas), lo que nos lleva a una mejora continua.
Otra de las cosas que propone es que para cada actividad que se realice se debe de hacer la documentación pertinente, ya que esta puede ser de gran utilidad para otros miembros del área, además de que quedan asentados todos los movimientos realizados, permitiendo que toda la gente esté al tanto de los cambios y no se tome a nadie por sorpresa.

En la documentación se pone la fecha en la que se hace el cambio, una breve descripción de los cambios que se hicieron, quien fue la persona que hizo el cambio, así como quien es el que autorizo el cambio, para que así se lleve todo un seguimiento de lo que pasa en el entorno. Esto es más que nada como método con el que se puede establecer cierto control en el sistema de cambios, y así siempre va a haber un responsable y se van a decir los procedimientos y cambios efectuados.

Para mi concepto ITIL,es una recopilación de las mejores prácticas tanto del sector público como del sector privado dando beneficios para todo tipo de usuario ya que por medio de este los usuarios pueden garantizar la calidad de sus proyectos y minimizar el riesgo que podría ser presentado en su sistema.





COBIT

Según Wikipedia El COBIT es precisamente un modelo para auditar la gestión y control de los sistemas de información y tecnología, orientado a todos los sectores de una organización, es decir, administradores IT, usuarios y por supuesto, los auditores involucrados en el proceso. 
Las siglas COBIT significan Objetivos de Control para Tecnología de Información y Tecnologías relacionadas (Control Objectives for Information Systems and related Technology). El modelo es el resultado de una investigación con expertos de varios países, desarrollado por ISACA (Information Systems Audit and involucrados en la organización. 
El COBIT es un modelo de evaluación y monitoreo que enfatiza en el control de negocios y la seguridad IT y que abarca controles específicos de IT desde una perspectiva de negocios. Control Association). 
La estructura del modelo COBIT propone un marco de acción donde se evalúan los criterios de información, como por ejemplo la seguridad y calidad, se auditan los recursos que comprenden la tecnología de información, como por ejemplo el recurso humano, instalaciones, sistemas, entre otros, y finalmente se realiza una evaluación sobre los procesos.

Para mi concepto COBIT son estándares en los cuales para crear un proyecto primero se deben basar en estos ,COBIT propone un marco donde se evalúan los criterios de información como la seguridad y la calidad haciendo mejoras en los proyectos para brindarle calidad a este.



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.

Para mi Concepto Lean se basa en una metodología ágil y economizadora porque ya que esta se basa en el ahorro sin dejar sobrantes en el proyecto entregándole funcionalidad al cliente facilitando así menos gastos y una funcionalidad optima.


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 por objeto permitir a los desarrolladores para 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 altacalidad de los resultados.

MSF para mi concepto son instrucciones dadas al cliente con las cuales este puede decidir entre cual es la que mas le conviene o cual esta mas acorde con su idea de proyecto para asi obtener un proyecto con menos gastos,prospero y de alta calidad en su sistema.


PMBOK

El PMBOK es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK es un estándar reconocido internacionalmente (IEEE Std 1490-2003) que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc.
El 'PMBOK' reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento comunes a casi todos los proyectos.
Los procesos se traslapan e interactúan a través de un proyecto o fase y son descritos en términos de:
§  Entradas (documentos, planes, diseños, etc.)
§  Herramientas y Técnicas (mecanismos aplicados a las entradas)
§  Salidas (documentos, productos, etc.).

Grupos básicos de Procesos
Los 5 grupos básicos de procesos son:
            Iniciación:
            Define y autoriza el proyecto o una fase del mismo. Está formado por dos procesos.
            Planificación:
Define, refina los objetivos y planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto. Está formado por veinte procesos.

Ejecución:
Compuesto por aquellos procesos realizados para completar el trabajo definido en el plan a fin de cumplir con las especificaciones del mismo. Implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto. Está formado por ocho procesos.

Seguimiento y Control:
Mide, supervisa y regula el progreso y desempeño del proyecto, para identificar áreas en las que el plan requiera cambios. Está formado por diez procesos.

Cierre:
Formaliza la aceptación del producto, servicio o resultado, y termina ordenadamente el proyecto o una fase del mismo. Está formado por dos procesos.


PMBOK para mi este provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería,estos son pasos o regalas que deben cumplirse a cabalidad para el buen desarrollo de un programa. 




PRINCE2
Metodología de Prince2


PRINCE2 ® (PRojects IN Controlled Environment) es un método estructurado de gestión de proyectos. Es una aproximación a las “buenas prácticas” para la gestión de todo tipo de proyectos que se ha convertido en el estándar de facto para la organización, gestión y control de proyectos.

El método divide los proyectos en fases manejables permitiendo el control eficiente de los recursos y el control periódico de su evolución. PRINCE2 está "basado en los productos", es decir, los planes del proyecto se centran en obtener resultados concretos, y no sólo en la planificación de las actividades que se llevan a cabo; PRINCE2 proporciona un lenguaje común en los proyectos.

Para mi concepto PRINCE2 esta basado en los productos ya que este se centra en las buenas practicas de la gestión de cada proyecto para crear un proyecto con resultados concretos de alta calidad.


DRA


Modelo DRA (Desarrollo Rápido de Aplicaciones):

El modelo DRA, es un modelo de proceso del desarrollo del software
lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto (Es una adaptación a alta velocidad del modelo lineal secuencial). El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos muy cortos de tiempo.

El DRA comprende las siguientes etapas:
  • Modelado de Gestión: aquí se modela el flujo de información entre las funciones de gestión. Este flujo debe "responder" a preguntas tales como ¿Qué información conduce el proceso de gestión?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?
  • Modelado de datos: se definen las características (atributos) de cada objeto, formado a partir del flujo de información, y las relaciones entre ellos.
  • Modelado del proceso: las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.
  • Generación de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas ya existentes o crea componentes reutilizables.
  • Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo cual permite que el tiempo de duración de las pruebas sea menor. Todo esto no impide que se tenga que probar cada uno de los nuevos componentes.
Desventajas:
  • Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el número suficiente de equipos.
  • Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario.
  • No es adecuado cuando los riesgos tecnicos son muy alto.

Para mi concepto DRA esta totalmente basado en la "Reutilizacion" ya que esta optimiza tiempo ya que esta utiliza cosas que ya otras personas las han creado y las acomoda a su fin común,esta se basa en la rapidez ya que sus entrega son rápidas pero con gran funcionalidad en el sistema.




CRYSTAL

Qué es Cystal Clear ?

Crystal Clear no es una metodología en si misma sino una familia de metodologías con un “código genético” común.

La idea es poder armar distintas metodologías para distintos tipos de proyectos. Cada proyecto y organización usará este código genético para generar su propia metodología.
El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad (como en los minerales, color y dureza).
Por ejemplo, Clear es para equipos de hasta 8 personas, Amarillo para equipos entre 10 – 20 miembros, Naranja para 20 a 25 personas, etc.

El Código Genético

El código genético consiste en:
1. Un “modelo de juegos cooperativos
Este modelo ve al desarrollo de software como una serie de partidos que consisten en inventar y comunicar. Cada partido es diferente y tiene como objetivo entregar software y prepararse para el siguiente juego. Esto permite al equipo trabajar concentrado y en forma efectiva con un objetivo claro cada vez.




2. Prioridades
Crystal Clear establece un conjunto de prioridades y principios que sirven de guía para la toma de decisiones
  • Eficiencia en el desarrollo: para hacer que los proyectos sean económicamente rentables
  • Seguridad en lo que se entrega
  • Habitabilidad: hacer que todos los miembros del equipo adopten y sigan las convenciones de trabajo establecidas por el equipo mismo.

3. Propiedades

  • Frecuencia en las entregas: entregar al usuario funcionalidad "usable" con una frecuencia de entre 2 semanas y no más de un mes.
  • Comunicación: Crystal Clear toma como uno de sus pilares a la comunicación. Promueve prácticas como el uso de pizarrones, pizarras y espacios destinados a que todos (miembros del equipo y visitas) puedan ver claramente el progreso del trabajo
  • Crecimiento reflexivo : es necesario que el equipo lleve a cabo reuniones periódicas de reflexión que permitan crecer y hacernos más eficientes.
    Estas tres propiedades son "obligatorias" para Crystal Clear, las siguientes pueden agregarse en la medida de las necesidades de cada grupo y proyecto
  • Seguridad personal: lograr que cada miembro del team pueda sentirse cómodo con el trabajo y el entorno
  • Concentración: las entregas frecuentes permiten que cada desarrollador puede enfocar de a un problema por vez evitando dispersiones.
  • Fácil acceso a usuarios clave: tratar de hacer que el usuario sea una parte más del equipo es fundamental para ir depurando errores de manera temprana.
  • Entorno técnico con: i - Testing automatizado (incorporación, por ejemplo, de UnitTest) - ii. Integración frecuente (uso de herramientas específicas como Cruise Control)
4. Principios
  • El grado de detalle necesario en documentar requerimientos, diseño, planeamiento, etc, varía según el proyecto
  • Es imposible eliminar toda documentación pero puede ser reducida logrando un modo de comunicación más accesible, informal y preciso que pueda ser accedido por todos los miembros del equipo.
  • El equipo ajusta constamente su forma de trabajo para lograr que cada personalidad encaje con los otros miembros, con el entorno y las particularidades de cada asignación


5. Estrategias
Ni las estrategias ni las técnicas son mandatorias para Crystal Clear. Pero es bueno tener en cuenta algunas de ellas al momento de empezar a trabajar.
Tres de las estrategias que están más relacionadas son las de apuntar a tener "Victorias Tempranas", arrancar el desarrollo de lo que se denomina un "Esqueleto que Camine" y pensar siempre en hacer "Rearquitectura Incremental" van de la mano.
El poder arrancar el proceso a partir de un esqueleto sobre el cual se irá agregando funcionalidad en cada una de las entregas ayuda a que se vean los avances desde el comienzo (aunque sea una simple pantalla de ABM que se conecta con la base de datos y muestra un solo dato). A medida que se avanza en el proceso, la rearquitectura permitirá ir agregando más "cuerpo" al esqueleto inicial.

Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio.




6. Técnicas
Igual que con las estrategias, hay una lista de técnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las más convenientes según el momento en que se encuentra el proceso de desarrollo del proyecto.
Las reuniones diarias (introducidas por la metodología Scrum) acompañan el seguimiento y mantienen el foco en el próximo paso a seguir, y también permiten la discusión productiva de líneas a seguir.
Las reuniones de reflexión periódicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qué cosas dan resultado y cuáles no o de empezar a trabajar.

Todo esto permite ir armando una metodología de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen.
En conclusión La guía de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeños. Da flexibilidad y prioriza la parte humana (como todas las Metodologías Agiles), apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo.

Presta especial importancia a la ubicación física del grupo, donde la comunicación cumple el principal rol. La entrega frecuente de código confiable y "funcionando" mantiene el foco y evita distracciones.El equipo es el que elige qué técnicas aplicar según lo que consideren apropiado en cada proyecto.

Para mi Crystal es una familia de metodologias las cuales tienen un codigo genetico para diferentes proyectos con el fin de ofrecerle a cada cliente la metodologia que este desee para que su proyecto tenga mayor organizacion y mayor alcance frente a las demas empresas compitiendo con una calidad factible. 


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.



Es importante ya que conduce al mejoramiento continuo . Permite una reducción continua de inventario . Alistamientos Largos Malos Diseños Paradas Inesperadas en equipos Proveedores No confiables Mala Calidad Distribucion de planta ineficiente Alistamientos Largos.

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

Para mi concepto KANBAN es el mejoramiento continuo ya que le ofrece a cualquier proyecto un debido control haciendo que este vea sus errores y dandole la manera como solucinar para obtener una productividad de calidad.



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


Para mi el TSP es la mejor metodología ya que ayuda a los ingenieros y programadores a trabajar en un mejor entorno diviendo la fase que se construye por equipo para luego construir un producto completo basándose en la organización para construir la calidad del proyecto.

Tomado de http://www.slideshare.net/JuanGarcia99/team-software-process-tsp-9839315


PSP

El psp se concentra en las practicas de trabajo de los ingenieros en una forma individual. El psp se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 lineas de código.El psp sirve para producir software de calidad,donde cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.
El psp se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos.El psp busca proporcionar un marco de trabajo para el personal involucrado en el proceso de desarrollo de software.El PSP demuestra como manejar la calidad desde el principio del trabajo.


Principios del PSP

cada ingeniero es esencialmente diferente(cada uno se encarga de su trabajo). para mejorara constantemente su funcionamiento,los ingenieros deben utilizar personalmente procesos bien definidos y medidos.
los ingenieros deben sentirse personalmente comprometidos en la calidad de sus productos,esto mejorara la calidad.

Objetivos del PSP

lograr una disciplina de mejora continua en el proceso de desarrollo. mejorar la calidad del proceso de desarrollo. en general,PSP provee calidad y productividad. El tiempo ahorrado en el testeo en base a una mejor calidad ahorra entre un 20 a 4o% del desarrollo.

Para mi concepto PSP se centra en la meta personal de cada ingeniero para cumplir sus tareas basándose en principios para mejorar los ámbitos en los cuales se desarrolla y así ver reflejado el desempeño de cada uno de los trabajadores que lo conforman.



RUP

Archivo:Rup espanol.gif


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.
También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.
El RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.

                               

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Para mi concepto RUP es un proceso de desarrollo de software el cual 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 para constituirle a cualquier proyecto una calidad optima.





A continuacion les hablare de nuevos temas propuestos por mi profesora Adriana los cuales son muy interesantes:

Manifiesto agil

Las metodologías ágiles de software hacen foco en las personas para crear los mejores equipos que, a su vez, sean capaces de crear el mejor software posible para un cliente. El Manifiesto Ágil es la expresión que define esta forma de pensar. Detrás del Manifiesto existen varios Principios que impulsan y guian al desarrollo Ágil.
Resulta útil tener presente estos principios, ya que nos sirven como guía en momentos de problemas, dudas o para generar nuestra visión de equipo. Les dejo entonces los Principios Ágiles: 

Los principios detrás del Manifiesto Ágil

Seguimos estos principios: 
Nuestra máxima prioridad es satisfacer al cliente a través de entregas tempranas y continuas de software valioso.
Le damos la bienvenida a los requerimientos cambiantes, incluso aunque aparezcan tarde en el desarrollo. Los procesos Ágiles aprovechan al cambio para crear una ventaja competitiva en el cliente.
Entregamos software funcionando frecuentemente, entre un par de semanas a un par de meses, prefiriendo los tiempos más cortos.
Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto.
Construimos proyectos sobre individuos motivados. Les damos el lugar y el apoyo que necesitan, y confiamos en ellos para hacer el trabajo.
El método más eficiente y efectivo de recolectar información para y dentro de un equipo de desarrollo es la conversación cara-a-cara.
La principal métrica de avance es el software funcionando.
Los procesos Ágiles fomentan el desarrollo sustentable. Los sponsors, los desarrolladores y los usuarios deberían ser capaces de un ritmo constante de forma indefinida.
Mejoramos la ágilidad prestando continua atención a la excelencia técnica y al buen diseño.
La simplicidad - el arte de maximiar la cantidad de trabajo que no se hace - es esencial.
Las mejores arquitecturas, requerimientos y diseños emergen de los equipos auto-gestionados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, y luego ajusta su comportamiento de forma acorde.

Tomado de: http://www.dosideas.com/noticias/metodologias/707-los-principios-detras-de-agil.html

 Planning Poker

El Planning Poker es una técnica para la estimación de trabajo o esfuerzo usada para cada tarea de una planificación en el desarrollo ágil de software. 


Planning poker es una técnica que nos permite calcular estimaciones asentadas en el consenso. Siendo una variación del método Wideband Delphi, el Planning poker es utilizado para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software en general y es comúnmente utilizado en el desarrollo ágil de software (principalmente en la metodología Extreme Programming).

Recursos necesarios

Los recursos para trabajar con la técnica Plannig poker son:
  • Cartas plannig poker (para descargar las cartas de NEPS, haga click en los siguientes enlaces: Cartas azules, Cartas rojas, Cartas verdes y Cartas negras)
  • Dos a cuatro participantes
  • Un moderador
  • Un reloj o algún elemento que determine el tiempo

Las cartas en el mazo están numeradas. Un mazo típico contiene tarjetas mostrando la secuencia de Fibonacci incluyendo el cero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. La razón de utilizar dicha secuencia es reflejar la incertidumbre inherente en la estimación. Otros mazos utilizan progresiones similares.
Actualmente, un mazo que se encuentra en el mercado utiliza la siguiente secuencia: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, una tarjeta de “inseguro” (se identifica con los signos de pregunta) y una de “necesito un descanso” (taza de café).

El Plannin Poker Ademas de ser una gran técnica para realizar estimaciones y los esfuerzos relativos al desarrollo de un proyecto es una manera didáctica y divertida de escuchar a los demás miembros del equipo sus aportes al porque de cada estimación teniendo en cuenta cada sprint,Fue una experiencia muy divertida y muy reconfortante en el futuro me gustaría aplicarla ya que no solo nos permite estimar el tiempo de la evolución del proyecto sino que ademas por este método podemos entrelazar lazos de amistad.


 Tomado de: http://softneps.wordpress.com/tag/planning-poker/

Mapa Conceptual Sobre La Arquitectura de Software 






Ahora les hablare de conceptos importantes para mi como estudiante de Ingenieria De Sistemas.

Arquitectura De Software

Segun la IEEE  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.
¿Que es Diseño De Arquitectura?
Esta trata de como crear o seleccionar una arquitectura con base de requerimientos funcionales de performance o calidad.

¿Que Es Un Patron?
Es aquel que describe un problema que ocurre una y otra vez en nuestro ambiente y luego describe el nucleo de la solucion a ese problema, de forma tal que esa solucion puede ser usada un millon de veces sin hacerlo de la misma manera dos veces.

Que son Patrones De Diseño?
Son aqeullos que representan soluciones a problemas que surgen cuando se desarrolla software en un cotexto particular.

¿Que son Antipatrones?
Son aquellos formulados para no escojer malos caminos,es decir es la contrapartida natural al estudio de los patrones de diseño.

Elementos de un patrón

• Nombre: describe el problema de diseño.
• El problema: describe cuándo aplicar el patrón.
• La solución: describe los elementos que componen el diseño, sus relaciones, responsabilidades y colaboración.

Clasificación de los patrones

• Según su propósito:
De creación: conciernen al proceso de creación de objetos.
De estructura: tratan la composición de clases y/o objetos.
De comportamiento: caracterizan las formas en las que interactúan y reparten responsabilidades las distintas clases u objetos.

Patrones de diseño fundamentales

Son patrones que no aparecen la tabla definida por Gamma, pero se utilizan habitualmente:

• DELEGATION
• INTERFACE
• MARKER INTERFACE

Patrón DELEGATION

Utilidad:
Cuando se quiere extender y reutilizar la funcionalidad de una clase SIN UTILIZAR LA HERENCIA
Ventajas:
• En vez de herencia múltiple
• Cuando una clase que hereda de otra quiere ocultar algunos de los métodos heredados
• Compartir código que NO se puede heredar

Patrón INTERFACE

Utilidad:
Definir un comportamiento independiente de donde vaya a ser utilizado
Ventajas
Desacople entre comportamiento y clase.Realización de clases “Utilities”

Patrón MARKER INTERFACE

• Utilidad
– Sirve para indicar atributos semánticos de una clase.
• Ventajas:
– Se puede preguntar si un objeto pertenece a una clase de un determinado tipo o no.
– Habitualmente se utiliza en clases de utilidades que tienen que determinar algo sobre objetos sin asumir que son instancias de una determinada clase o no.


Patrón SINGLETON

• Utilidad
– Asegurar  que una clase tiene una sola instancia y proporcionar un punto de acceso global a ella
• Ventajas
– Es necesario cuando hay clases que tienen que gestionar de manera centralizada un recurso
– Una variable global no garantiza que sólo se instancieuna vez.

Patrón FACTORY METHOD

Utilidad
Separar la clase que crea los objetos, de la jerarquía de objetos a instanciar
Ventajas
– Centralización de la creación de objetos
– Facilita la escalabilidad del sistema
– El usuario se abstrae de la instancia a crear.

Patrón ADAPTER

Intención
Convertir la interfaz de una clase en otra interfaz esperada por los clientes.
Permite que clases con  interfaces incompatibles se comuniquen
Ventajas
Se quiere utilizar una clase ya existente y su interfaz no se corresponde con la interfaz que se necesita. Se quiere envolver código no orientado a objeto con forma de clase.

Patrón COMPOSITE

Intención
Componer objetos en jerarquías todo-parte y permitir a los clientes
tratar objetos simples y compuestos de manera uniforme
Ventajas
¨Permite tratamiento uniforme de objetos simples y complejos así como composiciones recursivas
¨Simplifica el código de los clientes, que sólo usan una interfaz
¨Facilita añadir nuevos componentes sin afectar a los clientesInconvenientes
¨Es difícil restringir los tipos de los hijos
¨Las operaciones de gestión de hijos en los objetos simples pueden presentar problemas: seguridad frente a flexibilidad.

Patrón FACADE

Intención: El patrón FACADE simplifica el acceso a un conjunto de clases proporcionando una única clase que todos utilizan para comunicarse con dicho conjunto de clases.
Ventajas
– Los clientes no necesitan conocer las clases que hay tras la clase FACADE
– Se pueden cambiar las clases “ocultadas” sin necesidad de cambiar los clientes. Sólo hay que realizar los cambios necesarios en FACADE

Patrón OBSERVER

Intención
– Definir una dependencia 1:n de forma que cuando el objeto 1 cambie su estado, los n
objetos sean notificados y se actualicen automáticamente
• Motivación
– En un toolkit de GUI, separar los objetos de presentación (vistas) de los objetos de datos, de forma que se puedan tener varias vistas sincronizadas de los mismos datos (editor-subscriptor).

Patrón STRATEGY

Intención:
– Encapsular algoritmos relacionados en clases y hacerlos intercambiables.
– Se permite  que la selección del algoritmo se haga según el objeto que se trate.
Ventajas
– Se permite cambiar el algoritmo dinámicamente
– Se eliminan sentencias condicionales para seleccionar el algoritmo deseado.

Patrón ITERATOR

Intención:
– Proporcionar una forma de acceder a los elementos de una colección de objetos de manera Secuencial sin revelar su representación interna. Define una interfaz que declara métodos para acceder secuencialmente a la colección.
• Ventajas:
– La clase que accede a la colección solamente a través de dicho interfaz permanece independiente de la clase que implementa la interfaz.

Clasificación de PATRONES GRAPS

PATRÓN EXPERTO

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).                                  

Tomado de http://siul02.si.ehu.es/~alfredo/iso/06Patrones.pdf


MVC

El Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC) fue introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones:
  • Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada.
  • Vista (View): Muestra la información al usuario. Obtiene los datos del modelo. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador.
  • Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio (“service requests” en el texto original) para el modelo o la vista. El usuario interactúa con el sistema a través de los controladores.
Las Vistas y los Controladores conforman la interfaz de usuario. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz y el modelo. La separación del modelo de los componentes vista y del controlador permite tener múltiples vistas del mismo modelo. Si el usuario cambia el modelo a través del controlador de una vista, todas las otras vistas dependientes deben reflejar los cambios. Por lo tanto, el modelo notifica a todas las vistas siempre que sus datos cambien. Las vistas, en cambio, recuperan los nuevos datos del modelo y actualizan la información que muestran al usuario. La Figura 2 muestra la estructura del patrón MVC:


Bb972251.art235-img02-543x280(es-es,MSDN.10).jpg



Este patrón es muy popular y ha sido portado a una gran cantidad de entornos y frameworks como entre los que se encuentran WinForms, ASP .Net, etc. Las herramientas de programación visual como Visual Basic, Visual Studio .Net, etc., siguen también alguna variante de este esquema. El MVC es un patrón ampliamente utilizado en múltiples plataformas y lenguajes. Algunos de sus principales beneficios son:
  • Menor acoplamiento
    • Desacopla las vistas de los modelos
    • Desacopla los modelos de la forma en que se muestran e ingresan los datos
  • Mayor cohesión
    • Cada elemento del patrón esta altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio)
  • Las vistas proveen mayor flexibilidad y agilidad
    • Se puede crear múltiples vistas de un modelo
    • Se puede crear, añadir, modificar y eliminar nuevas vistas dinámicamente
    • Las vistas pueden anidarse
    • Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representación visual
    • Se puede sincronizar las vistas
    • Las vistas pueden concentrarse en diferentes aspectos del modelo
  • Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales
    • Una vista para cada dispositivo que puede varias según sus capacidades
    • Una vista para la Web y otra para aplicaciones de escritorio
  • Más claridad de diseño
  • Facilita el mantenimiento
  • Mayor escalabilidad

    Tomado de http://msdn.microsoft.com/es-es/library/bb972251.aspx

    Para mi concepto el MVC O Modelo Vista Controlador es una de los patrones más importantes ya que además de separar los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos, nos ofrece muchas ventajas tales como la reutilización de códigos por ejemplo una misma aplicación debe ejecutarse tanto en un navegador estándar como en un navegador de un dispositivo móvil, solamente es necesario crear una vista nueva para cada dispositivo; manteniendo el controlador y el modelo original.
    Este modelo MVC Además de ofrecernos la reutilización la cual he planteado anteriormente nos ofrece muchas ventajas como una clara separación entre interfaz, lógica de negocio y de presentación, Sencillez para crear distintas representaciones de los mismos datos, Simplicidad en el mantenimiento de los sistemas, Facilidad para desarrollar prototipos rápidos entonces vemos que el modelo vista controlador es una opción efectiva no solo para la organización de un proyecto sino además para la calidad de este.
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.
QUE ES UN CLIENTE
Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o de las aplicaciones es totalmente transparente para el cliente.
QUE ES UN SERVIDOR
Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a través de redes LANs o WANs, para proveer de múltiples servicios a los clientes y ciudadanos tales como impresión, acceso a bases de datos, fax, procesamiento de imágenes, etc.
ELEMENTOS DE LA ARQUITECTURA CLIENTE/SERVIDOR
En esta aproximación, y con el objetivo de definir y delimitar el modelo de referencia de una arquitectura Cliente/Servidor, debemos identificar los componentes que permitan articular dicha arquitectura, considerando que toda aplicación de un sistema de información está caracterizada por tres componentes básicos:
Presentación/Captación de Información
Procesos
Almacenamiento de la Información




Presentación Distribuida.
    El cliente asume parte de las funciones de presentación de la aplicación, ya que siguen existiendo programas en el servidor dedicados a esta tarea. El resto de funciones de la aplicación (negocio, acceso a datos) residen en el servidor.

Esta arquitectura se utiliza para construir emuladores de terminal, aplicaciones de control remoto, front ends gráficos de aplicaciones que residen en un host, etc. Algunos ejemplos de productos que siguen esta filosofía son VLC, Microsoft Terminal Server, Cytrix Metaframe, emulador de host para sistemas operativos modernos como Windows, etc. 
Presentación remota.
Toda la lógica de negocio y acceso a datos se ejecuta en el servidor, que en esta ocasión no realiza ninguna función relacionada con la presentación. Todas las funciones de presentación son ejecutadas en el cliente. Un ejemplo de este tipo de aplicaciones son las aplicaciones web, las de los terminales de cajeros automáticos, etc.

La principal ventaja es que la interfaz de usuario se adapta bien a las capacidades del entorno cliente (en la presentación distribuida el servidor tenía que ejecutar funciones dentro de un entorno que podría no ser el más apropiado para el cliente). La principal desventaja es que toda la información necesaria para la presentación tiene que circular por la red desde el servidor al cliente.
Procesos Lógica o proceso distribuido.La lógica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces del sistema de información de forma que los papeles de cliente y servidor sean intercambiables, excepto en el control de los datos que es responsabilidad exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo.
Acceso a datos remoto. El cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situación se dice que hay una gestión de datos remota.La principal ventaja de esta arquitectura radica en su sencillez de uso, y su proliferación al ser adaptada por lenguajes de cuarta generación (como Oracle Forms). La desventaja es la latencia de red introducida. Al descargarse toda la lógica de proceso en los aplicativos clientes, estos necesitan descargar los datos necesarios (entradas al proceso) que circulan por la red.

CARACTERISTICAS DEL MODELO CLIENTE/SERVIDOR
El Cliente y el Servidor pueden actuar como una sola entidad y también pueden actuar como entidades separadas, realizando actividades o tareas independientes.
Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o en la misma plataforma.
Para ver el gráfico seleccione la opción "Descargar" del menú superior
Un servidor da servicio a múltiples clientes en forma concurrente.
Cada plataforma puede ser escalable independientemente. Los cambios realizados en las plataformas de los Clientes o de los Servidores, ya sean por actualización o por remplazo tecnológico, se realizan de una manera transparente para el usuario final.

La Arquitectura Cliente servidor es una conjunto de reglas y definiciones las cuales nos ayudan para crear un producto,esta se compone de varios elementos principales como los son el cliente y el servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes.Ademas de esto esta arquitectura nos ofrece varias ventajas tales como la escalabilidad,la centralizacion de control y el facil mantenimiento haciendo de nuestro producto no solo un producto hecho de calidad sino que ademas con mucha seguridad.