Intro Ingenieria Software

Microsoft Solution Framework 3.0 y 4.0 (MSF)

Escrito por scruz334 14-11-2007 en General. Comentarios (4)

Microsoft Solution Framework 3.0 (MSF)

http://scruz334.blogspot.es/img/msf.jpg

Este modelo se basa principalmente en los modelos espiral y cascada (hitos y fases). Como su nombre lo dice fue desarrollado por Microsoft con el objetivo de crear un modelo estructurado basado en una estructura de trabajo en desarrollo de software.

Tiene como principios fundamentales la comunicación (entre cliente/usuario y entre nosotros), una capacitación de las personas (disciplina de disponibilidad) es decir cumple con el proceso de formación de personal, compartir los roles entre todo el equipo de trabajo. MSF es un proceso versionado y se debe crear versiones para el negocio de cada cliente, debe ser ágil, ya que es menos abultado que RUP. Otro principio es la inversión de calidad (tiempo, trabajo, dinero); hay que tomar en cuenta que cada proyecto es una inversión, más no un gasto.

MSF se compone de 2 modelos y 3 disciplinas. Modelo de Equipo y de Proceso. Disciplina de  Administración de Proyecto,  Administración  de Riesgos y Administración de la Preparación.

Como vimos MSF es un proceso muy largo, pero a la vez es muy solvente para la solución de un problema. Este modelo no utiliza UML.

Para empezar con un proyecto de desarrollo empezaremos con la visión, cuya meta principal es establecer la comunicación y evaluar aquellas limitaciones que podamos tener. Luego analizaremos si existen riesgos para controlarlos a tiempo.

Después de analizar la visión seguimos con la planificación en donde se debe tener en cuenta el cronograma establecido (tiempo, dinero, recursos) y concretar los puntos de control de avance del proyecto. Este cronograma debe hacerse sobre Microsoft Proyect. Debemos enfatizar en que nuestro cronograma puede ser cambiado tan solo si el proyecto así lo pida, pero tomando en cuenta que nuestro objetivo del proceso es agrandar la calidad disminuyendo el tiempo de entrega.

Para seguir con el desarrollo se debe conseguir versiones del producto entregable, las cuales deben ser entregadas mediante fuentes y ejecutables (construcción de los frameworks).

En la estabilización se encuentra y se solucionan posibles errores. Y que no nos pase lo mismo que Windows Vista, el cual salió al mercado sin lograr estabilizar y solucionar todos sus defectos. Hasta que finalmente llegamos a la instalación del software donde éste es aceptado por el cliente. Se entrega al cliente en formatos digitales y documentados ejecutables, directorios, archivos, bases de datos, scripts, instaladores, manuales y licencias. Como en todo proceso de desarrollo de software brindamos el soporte técnico adecuado.

 

Microsoft Solution Framework 4.0 Agile (MSF)

MSF 4.0 presenta dos principios adicionales: una mayor vinculación estrecha con los clientes y que todos los productos sean entregables. Utiliza frameworks descriptivos similares en muchos aspectos a MSF 3.0, pero la gran diferencia es incluye dos metodologías:

MSF para el desarrollo de Aplicaciones Ágiles y MSF para el proceso de mejora CMM.

Al igual que la versión anterior define un equipo de trabajo, pero la ventaja es que aumenta la agilidad.

 

Ventajas

 

La ventaja principal ventaja es que al ser un modelo desarrollado por Microsoft se puede tener mayor soporte y mantenimiento, además la mayoría de los usuarios finales están más acostumbrados con este producto. Además sirve para grandes y pequeños proyectos.

Cabe recalcar que MSF no se parece al RUP en algunas definiciones (principalmente en la cuestión de los cambios).

Pero al haber estudiado todos estos modelos, veo que MSF será el mas conveniente para desarrollar el proyecto que nos habló la ingeniera.

 

Desventajas

 

La principal desventaja es que se torna un trabajo bastante largo, ya que para cada fase se debe documentar profundamente todo lo que se haga, pero no deja de ser un modelo que tiene buenos resultados.

 

LINKS

*      http://rrivera334.blogspot.es/i2007-05/

Este link es de un compañer@ del semestre pasado en donde habla de las dos versiones de MSF 3.0 y 4.0 y finalmente habla de modelos ágiles y su diferencia con modelos antes estudiados.

*      http://209.85.165.104/search?q=cache:FQ4TFUVaCXAJ:download.microsoft.com/download/4/4/E/44E1B331-E509-4D10-A9E3-B60640A3A403/20051206-ARC-BA.ppt+Microsoft+Solution+Framework+4.0+Agile+(MSF)&hl=es&ct=clnk&cd=1&gl=ec&client=firefox-a

Este link habla más profundamente de MSF  v.4 Agile proporcionado por la Lic. Patricia Scalzone.

*      http://es.wikipedia.org/wiki/SW-CMM

Este link define lo que es CMM: El Modelo de Madurez de la Capacidad para el desarrollo de Software (Capability Maturity Model for Software, SW-CMM)

 

 

 

 

 

 

 

 

 

 

RUP Parte 2 y OpenUP

Escrito por scruz334 07-11-2007 en General. Comentarios (2)

Proceso Unificado Rational RUP con Herramientas

Parte 2

Esta clase empezamos con la segunda parte de RUP, analizando Trabajadores, actividades y artefactos.

Los trabajadores ejecutan cierta actividad con el fin de obtener un artefacto. Como vimos el trabajador desempeña ciertos roles, y dicha persona debe tener diferentes funciones, es decir debe usar varias camisetas, por ejemplo el diseñador del proyecto a su vez puede ser autor y diseñador de casos de uso. Pudiendo ocupar cualquiera de estos roles cualquier otra persona que desarrolla el proyecto. Es por eso, que cuando tengamos a cargo una obra, debemos estar listos y dispuestos a tomar parte en cualquier rol que tengamos que desempeñarnos.

Dentro de las actividades encontramos la unidad de trabajo, la cual debe ser realizada por aquella persona cuyo propósito general debe ser el crear un artefacto. Para realizar un proyecto debemos tomar en cuenta el tiempo que la actividad debe ser ejecutada, pero debe demorarse tan solo horas o días.

Los artefactos son aquellos segmentos de información producidos o usadas por un proceso. En este punto enfocaremos la utilización y las formas.

Para la utilización tomamos por entrada a un artefacto, luego realizamos una actividad y finalmente a la salida de este proceso tenemos de nuevo al artefacto terminado.

Para las formas definimos un modelo, vemos cual es su elemento, adjuntamos todos los documentos, nos apoyamos de nuestro código fuente creado, el cual nos sirve solo a nosotros, más no al usuario final y posteriormente entregamos al cliente el ejecutable.

RUP nos ayuda a entregar un ejecutable mucho más pronto, ya que a diferencia de los modelos anteriores afronta primordialmente aquellas tareas riesgosas y las hace más pequeñas. También podemos mejorar la calidad, ya que se pueden estar realizando pruebas continuamente. La principal ventaja por la que yo aplicaría este proceso para un desarrollo, es que permite una mejor comunicación entre un ingeniero de software y de negocios, ya que maneja un lenguaje común.

Como vimos anteriormente en RUP parte 1, tan solo se lo puede aplicar en proyectos grandes más no en los simples o pequeños.

Si queremos desarrollar en RUP primero debemos conocer acerca de UML, lo que representa una desventaja un tanto complicada pero a la vez nos ayuda a instruirnos y prepararnos más como profesionales.

 

Openup

El siguiente tema tratado en clase es OpenUP, que se aplica en enfoques tanto iterativo como incremental. Este proceso puede ser desarrollado para hacer frente a una extensa diversidad de tipos de proyectos.

Asimismo OpenUP mantiene las mismas características de RUP, que contiene el desarrollo iterativo, casos de uso y escenarios de conducción de desarrollo, gestión de riesgos, y el enfoque centrado en la arquitectura.
Existe una forma más básica y fácil de manejar de OpenUP que es OpenUP / Basic, objetivos más pequeños y con sede equipos interesados en el desarrollo ágil e iterativo. Incluyo un link con esta información más adelante.

 En una página web encontre que Open Unified Process (OpenUP) es una parte del Eclipse Process Framework (EPF), un proceso de código abierto desarrollado en el marco Eclipse de fuente abierta organización. Ofrece las mejores prácticas de una variedad de desarrollo de software líderes de pensamiento y de la más amplia comunidad de desarrollo de software que cubren un conjunto diverso de perspectivas y necesidades de desarrollo.

LINKS

http://www.epfwiki.net/wikis/openupsp/openup_basic/customcategories/introduction_to_openup_basic,_BTJ_YMXwEduywMSzPTUUwA.html

este link habla específicamente de OPENUP BASIC en español.

 

 

http://www.eclipse.org/epf/

Este link nos lleva a la página principal de Eclipse Process Framework Project (EPF)

 

Proceso Unificado Rational RUP con Herramientas

Escrito por scruz334 04-11-2007 en General. Comentarios (5)

Proceso Unificado Rational RUP con Herramientas

Parte 1

 

El Proceso Unificado Rational es un proceso de desarrollo de software que se ha ido desarrollando con el tiempo, el mismo que se maneja conjuntamente con el Lenguaje Unificado de Modelado UML, y en la actualidad es la más manejada para el análisis, implementación y documentación de sistemas orientados a objetos.

RUP como vimos se desarrolla en unos principios básicos que como vimos se deben cumplir para que nuestro proyecto en desarrollo tenga éxito. Estos principios son: adaptar el proceso, balancear prioridades, demostrar valor iterativamente, elevar el nivel de abstracción y enfocarse en la calidad del producto.

Además se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso.

Analizamos un diagrama con esta característica, el cual se divide en fases y cada una de estas en una serie de iteraciones. Aquellas iteraciones dan como consecuencia un incremento del producto desarrollado dentro del que se aumenta o se perfecciona todas las funcionalidades del sistema que se está desarrollando.

Vimos como en cada modelo de desarrollo se cumple un ciclo de vida también en RUP: Concepción, Elaboración, Construcción, Transición.

RUP es más cómoda para utilizarla en grandes proyectos ya que necesita un grupo de trabajo el cual tiene que ser apto para dirigir un proceso complicado en varias fases. Pero si aplicamos este modelo para pequeños proyectos, seguramente no es posible cubrir los costos para que nuestro equipo de trabajo cubra las expectativas.

En algunas páginas de Internet además encontré que la continua validación de RUP como proceso de desarrollo y sus innegables ventajas con respecto a otras metodologías de desarrollo han tenido como consecuencia de que muchos usuarios/clientes utilicen estos medios para construir sistemas que sean efectivos desde el punto de vista del costo y de trascendente aporte a la generación de valor de una empresa en el largo plazo. Si bien RUP corresponde a una metodología de trabajo intensiva en recursos, su aproximación al problema no sólo garantiza que los proyectos abordados serán ejecutados íntegramente sino que además evita desviaciones importantes respecto de los plazos y también permite una definición acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parciales posteriores.

La próxima clase analizaremos la segunda parte de este interesante modelo.

LINKS:

Ø      http://www.willydev.net/descargas/articulos/general/cualxpfddrup.PDF

Este link da vista general de RUP. Además también enfoca y compara  RUP, XP y FDD que también tienen pocas similitudes entre si, aunque XP y FDD poseen algunas más al ser ambos más ligeros.

Ø      http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Hernandez.pdf

Este link es un trabajo de un doctorado, analiza RUP y su relación con las técnicas y métodos de la ingeniería de uso del software.

MODELOS DE PROCESO ITERATIVOS E INCREMENTALES

Escrito por scruz334 31-10-2007 en General. Comentarios (8)

MODELOS DE PROCESO ITERATIVOS E INCREMENTALES

 

La principal característica de estos modelos es que permite crear cada vez versiones más completas de software, para esto construimos versiones sucesivas de un producto. Se crea una primera versión que es utilizada por el usuario donde se provee retroalimentación al desarrollador, y según los requerimientos especificados de éste usuario se crea una segunda versión.

 

Modelo Incremental.-

Como vimos este era un modelo tipo cascada el cual origina una primera versión con su respectiva funcionalidad, aplicamos de nuevo cascada sobre aquella versión 1 y obtenemos como resultado una versión 2 más una funcionalidad 2. Este proceso aplicamos cada vez que deseamos crear una versión más completa según los requerimientos de nuestro cliente.

El modelo incremental se aplica cuando en un proyecto tenemos un tiempo límite y no disponemos del personal suficiente para que nuestro propósito sea implementado completamente.

Además existen altos riesgos en este modelo pero se los puede reducir si tan solo construimos una parte del sistema y dejamos lo demás para complementarlo en versiones posteriores.

 

Modelo Iterativo.-

A diferencia del modelo incremental, al modelo iterativo no se le agrega funcionalidad si no que en cada iteración se mejora su funcionalidad.

 

Ventajas

Las ventajas que ofrece un desarrollo iterativo e incremental son varias y variadas, pero debe quedar claro que es muy difícil obtener todas juntas ya que depende del contexto en el que se implemente el proceso. En general las ventajas son:

  • Resolución de problemas de alto riesgo en tiempos tempranos del proyecto.
  • Visión de avance en el desarrollo desde las etapas iniciales del desarrollo.
  • Obtención del feedback del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar todas las adaptaciones identificadas para cumplir con los objetivos planteados.
  • Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos, según demuestran estudios realizados sobre proyectos que han aplicado esta técnica.
  • Permite manejar la complejidad del proyecto, apuntando a la resolución de los problemas por partes, y no caer en la inanición del “súper análisis” del producto.
  • El aprendizaje y experiencia del equipo iteración tras iteración, mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo.
  • El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvíos en la duración total del proyecto.
  • Su adopción, con ciertos recaudos, no presenta grandes inversiones.

DESVENTAJAS

Hasta el momento se podría decir que no existen grandes desventajas, pero sí hay puntos a manejar con sumo cuidado:

  • El uso de un desarrollo iterativo e incremental no garantiza por sí solo el éxito de su uso.
  • Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.

LINKS:

Ø      http://www.is.ls.fi.upm.es/UDIS/docencia/proyecto/docs/curso/06CursoOO_DisenoEvolutivo.doc - (Este link da un ejemplo de desarrollo incremental e iterativo. Una forma de desarrollo evolutivo es el llamado desarrollo iterativo e incremental.)

Ø      http://www.unibe.edu.do/tic/ingenieria.pdf (Este link se refiere al porque de los fracasos del desarrollo de software con un Proceso Dirigido por los Casos de Uso. Proceso Iterativo e Incremental. Proceso Iterativo e Incremental. Proceso Centrado en la Arquitectura)

LINKS ADICIONALES

Escrito por scruz334 29-10-2007 en General. Comentarios (1)

LINKS

 

http://www.ati.es/novatica/2004/168/168-4.pdf

En este link encontraremos un lenguaje estándar para el modelado de software.

 

http://msdn2.microsoft.com/en-us/architecture/aa948857.aspx

Este link muestra una definición básica sobre SOA (Service Oriented Architecture), más algunos artículos publicados.

 

http://www-306.ibm.com/software/solutions/soa/

Aquí encontraremos una orientación de SOA pero tratado por IBM.

 

http://www.es-asp.net/tutoriales-asp-net/tutorial-215-217/utilizar-el-protocolo-soap-1-2.aspx

Aquí presento un link acerca de un tutorial de cómo utilizar el protocolo soap

http://scruz334.blogspot.es/admin/archivos/eek.gif