Archivo de la categoría: Call for Action

Incorporación de Mario Piattini Velthuis al Consejo de Dirección de SEMAT Iberia

El profesor Mario Piattini Velthuis, catedrático de la Universidad de Castilla-La Mancha (UCLM) se ha incorporado al Consejo de Dirección de SEMAT Iberia (Advisory Board Chapter SEMAT Iberia) con fecha 30 de noviembre de 2012.

El profesor Mario Piattini ha obtenido el premio Nacional 2012 a la Trayectoria Profesional del Ingeniero en Informática, un reconocimiento concedido por unanimidad de los miembros de la Federación de Ingenieros Informáticos de España. Es autor de numerosos libros en el área de Ingeniería de Software, Calidad de Software, Auditoria de Sistemas de Información y Gobierno de Tecnología de la Información.

Anuncios

Resumen de Semat

Semat es una iniciativa establecida en Septiembre de  2009 por la alianza  de Ivar Jacobson, Bertrand Meyer y  Richard Soley.

De acuerdo a la presentación que realizaron en Zurich en marzo de 2012 expresan que el desarrollo de software “esta impulsado por modas y caprichos, hace veinte años se trataba OO, hace doce años acerca de componentes, UML, proceso unificado(RUP), hace diez años CMMI y spice, hace cuatro años XP, ayer  Scrum,  ahora  Lean y Kanban. Todos muy buenos pero ninguno tiene lo que se necesita.

La ingeniería de software está gravemente obstaculizado hoy por prácticas inmaduras. Los problemas específicos incluyen:

  • La prevalencia de caprichos más típico de la moda de la industria que de una ingeniería de la disciplina.
  • La falta de una adecuada y ampliamente aceptada base teórica.
  • El gran número de métodos y variantes de método, con diferencias poco entendidas y amplificadas artificialmente.
  • La falta de evaluación y validación experimental creíbles.

La división entre la práctica de la industria y la investigación académica

 La visión de Semat:

Apoyar un proceso para refundar la ingeniería de software basada en una sólida teoría, principios probados y unas mejores prácticas que:

  • Incluyan un núcleo de elementos ampliamente acordados, extensible para usos específicos.
  • Resuelva los aspectos tanto de la tecnología como los de las personas.
  • Este apoyado por la industria, la academia, los investigadores y los usuarios
  • Soporte la extensión para enfrentar los cambiantes requerimientos y tecnología

Todo este proceso esta apoyado por gran cantidad de personalidades entre otros:

Pekka Abrahamsson, Scott Ambler, Victor Basili, Jean Bézivin, Robert V. Binder, Dines Bjorner, Barry Boehm, Alan W. Brown, Larry Constantine, Steve Cook, Bill Curtis, Donald Firesmith, Erich Gamma, Carlo Ghezzi, Tom Gilb, Ellen Gottesdiener, Sam Guckenheimer, Robert Glass, David Harel, Brian Henderson-Sellers, Martin Griss, Capers Jones, Ivar Jacobson, Philippe Kruchten, Harold Lawson, Robert Martin, Bertrand Meyer, James Odell, Meilir Page-Jones, Dieter Rombach, Ken Schwaber, Alec Sharp, Richard Soley, Andrey Terekhov, Fuqing Yang, Ed Yourdon.

Apoyos corporativos: ABB, Switzerland;Chalmers, Sweden;Ericsson, Sweden;Fujitsu, UK;Huawei, China;IBM, USA;Microsoft, Spain;KAIST, Korea;Peking University, China;KTH Royal Institute of Technology,;Sweden;SAAB, Sweden;Samsung SDS, Korea;Swedish Institute of Computer;Science, Sweden;SINTEF, Norway;Software Engineering Center, Korea;SEI, USA;Telecom Italia, Italy;City of Toronto, Ontario, Canada;Wellpoint, USA;

Cada uno de nosotros sabe cómo desarrollar  software, pero como comunidad no tenemos una base común ampliamente aceptado.

Debemos empezar por una base común, el Kernel, el kernel incluye la esencia de la ingeniería de software:

  • El kernel debe ser generado a partir de un gran número de métodos
  • El Kernel es independiente de la práctica y el método.
  • El kernel incluye elementos que son universales para todos los esfuerzos de desarrollo del software

El kernel se extiende con prácticas (captura la esencia de la ingeniería de sw, establece un mapa del contexto de la ingeniería de sw, constituye una base para evaluar el progreso del trabajo):

  • El kernel es universal
  • Se crean métodos específicos  cuando se adicionan practicas sobre el kernel, como arquitecturas, casos de uso, iteraciones, desarrollo orientado a pruebas,componentes,  etc.
  • Se pueden crear muchos métodos sobre el mismo kernel.

Organización del kernel.

El kernel se organiza a través de Alphas de cliente, Alphas de solución, Alphas de tarea

 α :Alpha es un acrónimo para  Abstract-Level Progress Health Attribute : Un elemento esencial de esfuerzo de ingeniería de sw  que es relevante para la evaluación del progreso y salud de la tarea.

La justificación de un lenguaje mas que describe los procesos de desarrollo de software se dar por las siguientes razones:

  • Apoyo de un kernel
  • Soporte de semántica dinámica
  • Centrarse en los profesionales/practicantes

Algunas características del lenguaje:

  • Estructura y Escalabilidad: capas e incrementos
  • Flexibilidad y extensibilidad: Composición y elementos genéricos
  • Semántica dinámica: Base Formal

 

Resumen de lo nuevo:

  • El enfoque hacia  los profesionales prácticos, no los ingenieros de proceso
  • El enfoque es el uso de métodos y su adaptación,  no la descripción del método
  • Semat es incluyente no excluyente, incluye todos los métodos y prácticas pertinentes ( buenos o malos)
  • Hay un pequeño núcleo de lo esencial
  • Hecho para equipos pequeños y grandes organizaciones
  • Fundado  en prácticas desde la base, y no en los procesos desde arriba
  • La separación de las responsabilidades como principio fundamental
  • Ligero y ágil en el trabajo con métodos
  • No va mas la vieja metáfora: El proceso es el programa – el computador es el equipo.
  • El proceso es lo que el equipo hace. La adaptación ocurre dinámicamente como una retrospectiva de lo que el equipo ha hecho a través de un lazo de retroalimentación.

De acuerdo a Carlos Alberto cuesta SEMAT está inquieto por los siguientes aspectos de la ingeniería del software:

  • No hay consenso en la definición de ingeniería del software.
  • Debe propiciarse un diálogo entre los proponentes de los diferentes métodos con el fin de unificar criterios en pro de construir un método amplio aplicable de manera flexible a los desarrollos para desestimular la ampliación artificial de los existentes que nacieron como respuesta a necesidades puntuales.
  • Paralelamente se debe trabajar sobre un estándar de medición para las etapas de desarrollo y para la evaluación del producto obtenido.
  • Los dos horizontes anteriores no se logran si no hay consenso en la utilización de “los artefactos” utilizados para representar las diferentes fases del desarrollo de software y más aún si no son aceptados o al menos entendidos por otras disciplinas como la administración, para dar sólo un ejemplo.
  • Debería convenirse un estándar para la implementación del framework de herramientas, para que la misma industria del software implemente dicho estándar.
  • Para lograr lo anterior deben existir convenios en donde los investigadores queden inmersos en las empresas para que haya la posibilidad de observar los problemas reales y proponer las soluciones a partir de la visión in situ.