Ingenieria De Software

Desarrollo del Tema

Metodologías usadas en Ingeniería de Software

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software, algunas de estas metodologías son:

Programación estructurada sol desde 1969

Programación estructurada Jackson desde 1975

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la información (IE/IEM) desde 1981

Rapid application development (RAD) desde 1991.

Programación orientada a objetos (OOP) a lo largo de la década de los 90's

Virtual finite state machine (VFSM) desde 1990s

Dynamic Systems Development Method desarrollado en UK desde 1995.

Scrum (desarrollo), en la última parte de los 90's

Rational Unified Process (RUP) desde 1999.

Extreme Programming(XP) desde 1999

Enterprise Unified Process (EUP) extensiones RUP desde 2002

Agile Unified Process (AUP) desde 2005 por Scott Ambler

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:

Modelo en cascada: Framework lineal.

Prototipado: Framework iterativo.

Incremental: Combinación de framework lineal e iterativo.

Espiral: Combinación de framework lineal e iterativo.

RAD: Rapid Application Development, framework iterativo.

Con el pasar de los años se han hecho diferentes combinaciones para llevar a buen Puerto cada una de las metodologías con el desarrollo de software en la vida real, con esto tenemos el nacimiento del desarrollo ágil de software, en mi caso personal me ha tocado trabajar mucho con la metodología “MSF for agile software development” el cual está totalmente orientado a CMMI.

MSF – Microsoft Solution Framework

CMMI - Capability maturity model integration

El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

Microsoft Solution Framework en la vida real

Actividades y entregables del modelo de trabajo del MSF

Principales “milestones” Fase del modelo Principales actividades

Visión / Aprobada visión Establecer la visión del proyecto y levantar los requerimientos

Plan de proyecto aprobado Planeación Desarrollar especificaciones funcionales y un plan de desarrollo

Poner fecha para él “release”

visión de todos los entregables Desarrollo Completar el diseño

Implantar y probar el código

Desarrollar la documentación

Desarrollar la capacitación

Prepararse para la prueba Beta

“Release” Estabilización Completar las pruebas del sistema

Completar toda la presentación

Responsabilidades de los roles de equipo del modelo MSF

Rol Visión Aprobada Plan de Proyecto aprobado Visión completada “Release”

Product management Escribir el documento de visión Contribuir al diseño conceptual Administrar las expectativas del cliente

Coordinar la versión beta y la entrega del producto

Program management Desarrollar las metas del diseño, factores de éxito, conceptos de métricas y soluciones.

Establecer la infraestructura del proyecto. Hacer el bosquejo de la especificación funcional.

Diseño lógico especifico (en términos de negocio)

Construir un plan y calendarización para las siguientes fases

Poner la fecha de entrega

Administrar las especificaciones

Darle seguimiento al proyecto, comunicar el status del mismo

Reparar el plan beta

Coordinar el plan de testing Seguimiento al status y coordinación y calendarización del release

Development Aporta consultoría en elementos que le competen Evaluar las tecnologías

Participa en el diseño físico

Desarrolla pruebas de concepto o implantación de prototipos

Estima esfuerzos y tiempos en las tareas y define los mismos Desarrolla elementos del producto, demos, y prototipos operacionales

Construye release internos

Optimiza el código

Contribuye a las pruebas del testing Repara defectos

Realiza los documentos de diseño y especificaciones del producto

User education Establece la estrategia para el rendimiento del sistema, diseño visual y entrenamiento Evaluación del diseño para el rendimiento del sistema.

Planea y calendariza en un documento sus actividades

Construye y revisa la documentación, gráficas y materiales para impartir el curso

Contribuye a las pruebas con el testing

Da el entrenamiento

Administra el rendimiento del sistema

Testing Evalúa los acuerdos de la visión, que se cumplan Evalúa el diseño

Planea las pruebas y desarrolla el calendario para la siguiente fase

Evalúa el plan de desarrollo y el calendario para testing Ejecuta pruebas y reporta los resultados

Verifica bugs

Verifica el rendimiento del equipo contra las fechas acordadas de entrega Pruebas sobre la beta, release y producto final.

Pruebas de configuración y rendimiento de la aplicación.

Logistics management Identificar los requerimientos de plataforma necesaria para la implantación Evaluar el diseño

Desarrollar su propia plan y calendarización de actividades Construir las guías de soporte y operación

Construir el calendario del release final Soportar y administrar las betas

Administrar el proceso del release

Todo el equipo Definir riesgos Actualizar riesgos Actualizar riesgos Actualizar riesgos

Comentarios para adicionar en el MSF

Al iniciar un proyecto tengo que hacer una reunión de lluvia de ideas sobre el proyecto y como lo vamos a afrontar. Estar abierto a escuchar cosas negativas y fungir como moderador. Mencionar la expectativa que se tiene de cada uno de los miembros

Darles la libertad y confianza para que se expresen. Grabar en video la sesión. Sentarse de preferencia en mesa redonda

Generar pendientes y procurar un ambiente de trabajo agradable, buscar un horario adecuado y no muy pesado.

Si se pueden mezclar con comida ligera sería bueno.

Para cambios durante el desarrollo del proyecto

Cuando el proyecto está en desarrollo y el cliente pide cambios se tiene que considerar la opinión de todos los involucrados sobre todo del líder de testing quien aprobara si se hace o no y esto se le tiene que notificar al cliente.

Se tienen que tomar en cuenta cosas como: el impacto que tendrá en el código si se cambia, el tiempo de entrega, el beneficio para el cliente.

Aceptar cambios al final del desarrollo puede ser muy impactante para la solución, no es recomendable

Como program y product managers debemos llevar un tracking de los bugs o cambios que se van implantando en la aplicación y los que se tienen que hacer.

Definición del producto

1.-Conoces al contacto principal de parte del cliente

2.-Entendemos sus prioridades

3.-La meta del cliente es igual a la nuestra, corresponden?

4.-Conocemos las especificaciones? Tenemos un documento para revisarlas?

5.-Sabemos a ciencia cierta lo que NO incluirá el proyecto?

6.-Sobre que plataformas correrá la aplicación?

7.-Se contempla el HW del cliente para que pueda correr la aplicación?

8.-Que versiones de SW existen en el cliente? Nuestra aplicación lo soporta?

9.-Se requieren componentes adicionales? tarjetas de sonido, de red, de video, etc...

10.-Quién es el responsable del testing? Tiene los elementos suficientes para hacer sus pruebas?

11. - Geográficamente el tester puede ir con el cliente para aplicar sus pruebas?

12.- Tenemos un plan para documentar los entregables, quien va a documentar?

Calendarización de actividades

1.- Todo el equipo conoce la fecha de entrega final

2.- El equipo está de acuerdo en la fecha de entrega

3.- El tiempo destinado es el adecuado?

4.- El equipo tiene milestones definidos durante el proyecto? Esta definido el "colchón" del proyecto?

5.- Se va a tratar de entregar algo mas "extra" al final del proyecto?

6.- Dependemos de algo o alguien mas para entregar a tiempo el producto?

7.- Que tanta confianza tenemos en que el equipo de desarrollo entregue a tiempo el proyecto?

8.- El equipo de trabajo esta geográficamente en otro lugar? ¿Cuándo se reincorpora?

9.- Tenemos un plan por si el proyecto no se entrega a tiempo?

El proceso de administración de riesgos proactivo

Los 6 roles del modelo de equipos corresponden directamente a las 6 metas de calidad para un proyecto efectivo. Se mapean así:

Metas Rol

Satisfacer a los clientes Product management

Entregar el proyecto Program management

Entregar las especificaciones del producto Development

Entregar un release después de haberlo probado Testing

Asegurarse de que el cliente conozca la aplicación User education

Administración del deployment Logistics management

Junta Postmortem

Junta Postmortem, junta después de terminado el proyecto. Esta es importante para obtener retroalimentación del mismo, reunir a toda la gente. Pedirles sus comentarios por mail antes de la reunión. Enviarles por correo la agenda a tratar. En la reunión pedirles sus comentarios buenos y malos durante el proyecto. Documentar todo esto y aplicar mejoras prácticas para proyectos futuros. Como estuvieron Los siguientes puntos durante este proyecto: Milestones forzosos

Visión, Plan de trabajo aprobado, Visión de Desarrollo Completo, Pruebas, Release.

Conclusión personal

Como pudimos apreciar en las lecturas y en este ensayo, la Ingeniería de Software abarca al grupo de métodos, técnicas y herramientas que se utilizan en la producción del software, más allá de la actividad principal de programación.

En esta ocasión me gusto poner un ejemplo de la construcción de una barda y un edificio, ya que lo considero totalmente similar al desarrollo de software y me gustaría agregar el siguiente comentario copiado de Internet:

“El término "ingeniería" es una referencia directa a la ingeniería civil, una referencia al estudio de la construcción. En programación se aplica el mismo principio que en la construcción de un edificio: poner simplemente ladrillos y cemento no es suficiente. La construcción de un edificio consta de diversos pasos antes de comenzar con la fase de construcción, tales como el diseño arquitectónico, la albañilería, la fontanería, el diseño eléctrico, y durante este período se calculan los presupuestos y los plazos”

Ahora bien, MSF es una metodología que he utilizado durante muchos años, con la cual he tenido experiencias positivas y negativas, quise plasmar en este breve ensayo los principios básicos de MSF para poder hablar de un marco de trabajo conocido para mí. El hecho de utilizar MSF no me ha generado entregar siempre proyectos exitosos, pero si me ha permitido tener visibilidad y control de los mismos, y así poder prever y anticipar problemas. Es importante agregar que tengo aproximadamente 14 años utilizando MSF (en sus diferentes versiones) y con el pasar del tiempo se ha transformado para cumplir con los cambios de la industria (lenguajes, ambientes, sistemas operativos, industria y más).

Referencias de Investigación:

Ingeniería del Software, Un Enfoque Práctico

Autor: Roger Pressman

Edición: 6ta Edición

Formato: PDF

Agile Software Development: Best Practices for Large Software Development

Autor: Thomas Stober,Uwe Hansmann

Formato: PDF

MSDN Library

http://msdn.microsoft.com/en-us/library/ms123401.aspx

...