KMM

Kanban Maturity Model

Descripción extraída de Berriprocess:

El Kanban Maturity Model (KMM) está pensado para ayudar a las organizaciones a definir su hoja de ruta y acciones concretas que les permitan desarrollar su agilidad.

Concretamente:

  • KMM define siete niveles de madurez organizacional
  • Explica la intención y los detalles de implementación de 132 prácticas específicas
  • Proporciona un conjunto completo de ejemplos de tableros kanban
  • Define en detalle qué prácticas y métricas usar
  • Describe la integración de KMM con modelos y métodos actuales, en particular Lean / TPS, Real World Risk Model (por Nassim Taleb), CMMI y Mission Command.
  • Mapea 20 valores culturales a los siete niveles de madurez.

Site

STEP

Systematic Test and Evolution Process

Descripción extraída del Syllabus de 2012 ISTQB Advanced Level Test Manager

STEP (Systematic Test and Evaluation Process), like CTP and unlike TMMi and TPI Next, does not require that improvements occur in a specific order.
STEP is primarily a content reference model which is based upon the idea that testing is a lifecycle activity that begins during requirements formulation and continues until retirement of the system. The STEP methodology stresses “test then code» by using a requirements-based testing strategy to ensure that early creation of test cases validates the requirements specification prior to design and coding.
Basic premises of the methodology include:

  • A requirements-based testing strategy
  • Testing starts at the beginning of the lifecycle
  • Tests are used as requirements and usage models
  • Testware design leads software design
  • Defects are detected earlier or prevented altogether
  • Defects are systematically analyzed
  • Testers and developers work together

Site de ISTQB en inglés

Site del ISTQB en español (SSTQB)

TDD

Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.

Wikipedia ES

Wikipedia ES

Wikipedia EN

Introducción a TDD (en inglés)

A continuación se presentan los enlaces del primer libro en castellano de Desarrollo guiado por pruebas (Test Driven Development – TDD). Publicado en Enero de 2010. El objetivo de los autores es ofrecer a la comunidad de desarrolladores un recurso en castellano sobre le desarrollo guiado por pruebas.

JIT

El método «JIT», (traducción del inglés Just in Time o justo a tiempo) es un sistema de organización de la producción para las fábricas, de origen japonés. También conocido como método Toyota, permite reducir costos, especialmente de inventario de materia prima, partes para el ensamblaje, y de los productos finales.

Los métodos de Toyota han inspirado al mundo del desarrollo software (Lean software development)

Wikipedia

 

Inner Sourcing

Inner source es el uso de las mejores prácticas de desarrollo de software de código abierto y el establecimiento de una cultura de código abierto dentro de las organizaciones. La organización puede desarrollar software propietario, pero internamente abre su desarrollo. El término fue acuñado por Tim O’Reilly en 2000

Wikipedia

Site

 

 

SQuaRE

ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del producto software.

DevOps

DevOps de define como una cultura, una forma de entregar y desplegar el software en producción. La base de DevOps es aparentemente simple: automatizar las actividades de entrega de la versión del software y su paso a producción sin apenas intervención de actividades manuales.

Sin embargo su aplicación conlleva una gran actividad de ingeniería de software ya que debe definir el pipeline que llevará cada versión del software a producción de forma automatizada y realizando todos los controles de calidad asociados.

Es esta labor de diseño e implementación del proceso mediante un pipeline la labor más costosa y crítica. Sin embargo el resultado es pasos a producción en horas desde que la versión de software se ha liberado con un exhaustivo control de calidad y una trazabilidad detallada que permite conocer con precisión la versión de cada funcionalidad, requisito y características del software que esté en producción.

DevOps Agile Skills Association (DASA) es una asociación de empresas a nivel mundial que forman una comunidad para crear y divulgar competencias en DevOps.

Los miembros de DASA están organizados en:

  • Tranining Partnerts
  • Courseware Partners
  • Exam Service providers
  • Forerunners
  • Ambassadors

 

 

Wikipedia

Lean Software Development

Lean manufacturing (‘producción ajustada’, ‘manufactura esbelta’, ‘producción limpia’ o ‘producción sin desperdicios’)​ es un modelo de gestión enfocado a la creación de flujo para poder entregar el máximo valor para los clientes, utilizando para ello los mínimos recursos necesarios, es decir, ajustados.

El Sistema de Producción Toyota (Toyota Production System o TPS en inglés) es un sistema integral de producción «Integral Production System» y gestión surgido en la empresa japonesa automotriz del mismo nombre. En origen, el sistema se diseñó para fábricas de automóviles y sus relaciones con proveedores y consumidores, sin embargo este se ha extendido hacia otros ámbitos. Este sistema es un gran precursor para el genérico Lean Manufacturing.

Muchos de sus principios y herramientas se han trasladado al mundo del desarrollo software bajo la denominación de Lean Development. La metodología de desarrollo de software lean (traducción aproximada de lean: «fino» o «esbelto») es una traducción de los principios y las prácticas de la forma de producir lean, hacia el área del desarrollo de software. Inicialmente, originado en el Sistema de Producción de Toyota y ahora, apoyado por una corriente que está surgiendo desde la comunidad Ágil. Este método ofrece todo un marco teórico sólido y basado en la experiencia, para las prácticas ágiles de gestión.

Lean en Wikipedia

Sistema de producción Toyota en Wikipedia

Lean software development

 

OMT

La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de investigación de los laboratorios General Electric.
OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.

Wikipedia

 

EITBOK

EITBOK (Enterprise Information Technology Body of Knowledge). En esta guía, la IEEE Computer Society, en cooperación con el proyecto ACM IT2017, establece una línea de base para el conjunto de conocimientos para la práctica de la tecnología de la información empresarial (EIT). Este trabajo ha sido emprendido como parte de la responsabilidad de la Sociedad de promover el avance tanto de la teoría como de la práctica en este campo.

La guía se compone de los siguientes trabajos especializados:

 

Wiki EITBOK

 

 

COBIT

Objetivos de Control para Información y Tecnologías Relacionadas (COBIT, en inglés: Control Objectives for Information and related Technology) es una guía de mejores prácticas presentada como framework, dirigida al control y supervisión de tecnología de la información (TI). Mantenida por ISACA (en inglés: Information Systems Audit and Control Association) y el IT GI (en inglés: IT Governance Institute), tiene una serie de recursos que pueden servir de modelo de referencia para la gestión de TI, incluyendo un resumen ejecutivo, un framework, objetivos de control, mapas de auditoría, herramientas para su implementación y principalmente, una guía de técnicas de gestión.

Wikipedia

Scrumban

Conocemos Kanban y Scrum como metodologías de gestión Agile. Scrumban combina las mejores características de ambos métodos. Reúne la naturaleza preceptiva de Scrum y la capacidad de mejora del proceso de Kanban, permitiendo a los equipos moverse hacia el desarrollo Agile y a mejorar constantemente sus procesos.

Wikipedia

What is Scrumban

 

 

KANBAN

Kanban es un método para gestionar el trabajo intelectual, con énfasis en la entrega justo a tiempo, mientras no se sobrecarguen los miembros del equipo. En este enfoque, el proceso, desde la definición de una tarea hasta su entrega al cliente, se muestra para que los participantes lo vean y los miembros del equipo tomen el trabajo de una cola.

Kanban se puede dividir en dos partes:

  • Kanban – Un sistema de gestión de proceso visual que le indica qué producir, cuándo producirlo, y cuánto producir.
  • El método Kanban – Una aproximación a la mejora del proceso evolutivo e incremental para las organizaciones.

Dos de sus características principales son:

  • WIP (Work in progress): indicador del número de tareas simultáneamente abiertas que limita los cambios de contexto del equipo de desarrollo aumentado la productividad y disminuyendo los errores
  • Informe visual. El propio tablero de gestión es en sí mismo un informe de situación que simplifica la labor de reporting y el avance del proyecto

Wikipedia

CORBA

Common Object Request Broker Architecture (CORBA) es un estándar definido por Object Management Group (OMG) que permite que diversos componentes de software escritos en múltiples lenguajes de programación y que corren en diferentes computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos heterogéneos.

Wikipedia

Sitio

 

SOA

La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido creadas para satisfacer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad.

Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.

Wikipedia

SOMA

El paradigma de SOA desarrollado por IBM denominado Soma (Service Oriented Modeling and Architecture) brinda las técnicas en varias dimensiones para adoptar SOA. En los proyectos que apalancan SOA/SOMA, los servicios son identificados, diseñados e implementados.

IBM

 

LeadingAgile

LeadingAgile se enfoca en construir una estrategia de transformación que respete el status quo de la organización mientras que pone las bases de lo que se necesita en el futuro. Permite trabajar con enfoques tales como

  • Predictivo o adaptativo
  • Emergente o convergente

Todo ello en base a los objetivos y situación de la organización, es decir, aplicar las opciones más útiles.

Sitio

 

LESS

LeSS es Scrum (Large-Scale Scrum – LeSS), no es un Scrum renovado y mejorado. Y no es Scrum en la parte inferior de cada equipo, y algo diferente en capas en la parte superior. Más bien, se trata de averiguar cómo aplicar los principios, el propósito, los elementos y la elegancia de Scrum en un contexto de gran escala, tan sencillamente como sea posible. Al igual que Scrum y otros marcos verdaderamente ágiles, el LeSS es «una metodología apenas suficiente» por razones de alto impacto.

Wikipedia

Sitio

 

SAFE

Scaled Agile Framework (o SAFe) es un marco ágil (adaptativo) de desarrollo de software que consiste en una base de conocimientos de patrones integrados destinados al desarrollo Lean-Agile a escala empresarial. Sus defensores consideran que SAFe es escalable y modular, permitiendo que una organización lo aplique de una manera que se adapte a sus necesidades.

SAFe sincroniza alineación, colaboración y entrega para un gran número de equipos ágiles. Apoya el desarrollo de software y sistemas, desde la modesta escala de menos de 100 profesionales hasta las soluciones de software más grandes y complejos sistemas que requieren miles de personas para crear y mantener el software. SAFe fue desarrollado sobre la experiencia, basado en ayudar a los clientes a resolver sus problemas de escalado más difíciles. SAFe aprovecha tres cuerpos principales de conocimiento: desarrollo de software ágil, desarrollo de productos lean y pensamiento sistémico.

SAFe fue elaborado en los libros y el blog de Dean Leffingwell. La versión 1.0 de SAFe, el primer lanzamiento oficial, fue publicada en su forma actual de sitio web en 2011. La última versión renombrada «SAFe 4.0 para Lean Software e Ingeniería de Sistemas», fue lanzada en enero de 2016.

Wikipedia

Sitio

 

BABOK

La Guía para el Cuerpo de Conocimiento de Análisis de Negocios (Guide to the Business Analysis Body of Knowledge – BABOK® Guide) es el estándar esencial para ayudar a los profesionales y sus grupos de interés a ofrecer valor comercial y crear mejores resultados de negocio.

BABOK® Guide amplía el alcance del análisis de negocios, proporcionando dirección y apoyo esenciales para los profesionales en ámbitos como la agilidad, la inteligencia empresarial, la tecnología de la información, la arquitectura empresarial y la gestión de procesos de negocio.

 

Wikipedia

Sitio

 

IREB

IREB (International Requirements Engineering Board; el consejo internacional de expertos en IR), es una organización sin ánimo de lucro proveedora del esquema de certificación Certificado Profesional en Ingeniería de Requisitos (CPRE). El consejo está compuesto de representantes líderes en IR, que provienen de la academia, investigación, empresa y consultoría.

El CPRE es un certificado personal; se dirige a individuos que tratan con requisitos y tienen grandes demandas en términos de calidad.

Desde 2007, más de 32,000 profesionales en 70 países han pasado con éxito el examen de Nivel Fundacional CPRE. El certificado es reconocido en todo el mundo y tiene una validez de por vida.

Wikipedia

Sitio

Sitio (ES)

CSQE

El Ingeniero Certificado de Calidad de Software (Certified Software Quality Engineer – CSQE) entiende el desarrollo e implementación de calidad de software, inspección, pruebas, verificación y validación de software, e implementa procesos y métodos de desarrollo y mantenimiento de software.

Wikipedia

Sitio

TMAP

TMap® (Test Management Approach) es la metodología de pruebas de SOGETI, que combina conocimientos sobre cómo probar y qué administrar, así como técnicas para el consultor de pruebas individuales.

Wikipedia

Sitio

 

TMMi

El marco TMMi ha sido desarrollado por la Fundación TMMi como guía y marco de referencia para la mejora de procesos de prueba y se posiciona como un modelo complementario a la versión 1.2 CMMI [CMMI] al abordar esas cuestiones importantes para poner a prueba los gestores de pruebas, ingenieros de pruebas y los profesionales de la calidad del software. Pruebas como se define en el TMMi se aplica en su sentido más amplio para abarcar a todas las actividades relacionadas con la calidad del producto software.

Wikipedia

Sitio

 

ISTQB

El International Software Testing Qualifications Board (ISTQB) es una organización de certificación de profesionales de las pruebas de software que opera a nivel internacional. Fundada en Edimburgo en noviembre de 2002, ISTQB es una asociación sin ánimo de lucro legalmente registrada en Bélgica.

ISTQB Certified Tester es una certificación estandarizada para probadores de software y la certificación es ofrecida por ISTQB. Las calificaciones se basan en un programa de estudios y hay una jerarquía de calificaciones y directrices para la acreditación y el examen. El ISTQB es una organización de certificación de certificación de pruebas de software que tiene más de 500.000 certificaciones emitidas; El ISTQB consta de 57 juntas miembros en todo el mundo representando 81 países (fecha: mayo de 2017).

Wikipedia

Sitio

 

ITIL

La Biblioteca de Infraestructura de Tecnologías de Información (o ITIL, por sus siglas en inglés) es un conjunto de conceptos y buenas prácticas usadas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.

Wikipedia

ISO 29119

Los estándares de prueba de software ISO 29119 son un conjunto de documentos definidos internacionalmente que tratan los conceptos, procesos, técnicas, documentos, tecnologías y términos de pruebas de software.

Actualmente ISO 29119 tiene cinco partes. El conjunto de normas utiliza un enfoque en capas para definir las pruebas de software, que es común a muchos estándares ISO. Este conjunto de normas presenta: definiciones y conceptos de prueba (parte 1); Procesos de prueba (parte 2); Documentación de prueba (parte 3); Técnicas de ensayo (parte 4); Y las pruebas dirigidas por palabras clave (parte 5).

Wikipedia

Sitio en inglés

Sitio en español (Universidad de Oviedo)

Normas que ha sustituido:

  • IEEE 829 Test Documentation
  • IEEE 1008 Unit Testing
  • BS 7925-1 Vocabulary of Terms in Software Testing
  • BS 7925-2 Software Component Testing Standard

 

ISO 12207

ISO/IEC 12207 Information Technology / Software Life Cycle Processes, es el estándar para los procesos de ciclo de vida del software de la organización ISO.

Los procesos se clasifican en tres tipos: procesos principales, procesos de soporte y procesos de la organización. Los procesos de soporte y de organización deben existir independientemente de la organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación particular.

Procesos principales.

  • Adquisición.
  • Suministro.
  • Desarrollo.
  • Operación.
  • Mantenimiento.

Procesos de soporte.

  • Documentación
  • Gestión de la configuración.
  • Aseguramiento de calidad.
  • Verificación.
  • Validación.
  • Revisión conjunta.
  • Auditoría.
  • Resolución de problemas.

Procesos de la organización.

  • Gestión.
  • Infraestructura.
  • Mejora.
  • Recursos Humanos.

Wikipedia

Web ISO 12207:2017

ISO 25000

El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE (System and Software Quality Requirements and Evaluation) es organizar, enriquecer y unificar las series que cubren dos procesos principales: especificación de requisitos de calidad del software y evaluación de la calidad del software, soportada por el proceso de medición de calidad del software.

Las características de calidad y sus mediciones asociadas pueden ser útiles no solamente para evaluar el producto software sino también para definir los requerimientos de calidad.La serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC 9126 (Software Product Quality) e ISO/IEC 14598 (Software Product Evaluation).

ISO 25000 representa una familia de normas con más de 40 documentos publicados cuyo mayor referente puede ser ISO 25010 sobre las característica de calidad del producto software.

Wikipedia

Referencias: iso25000.com

ISO 9126 Norma sustituida por la ISO 25010 que ha sido un referente de las características del software.

ASL

La Biblioteca de Servicios de Aplicación (Application Services Library – ASL) es un marco de dominio público de las mejores prácticas utilizadas para estandarizar procesos dentro de Application Management, la disciplina de producir y mantener sistemas y aplicaciones de información. El término «biblioteca» se utiliza porque ASL se presenta como un conjunto de libros que describen las mejores prácticas de la industria de TI. Se describe en varios libros y artículos (muchos de ellos sólo están disponibles en holandés) y en el sitio web oficial de la Fundación ASL BiSL.

ASL está estrechamente relacionado con los marcos ITIL (para IT Service Management) y BiSL (Gestión de la Información y Gestión Funcional) y el Modelo de Madurez de Capacidad (CMM).

El marco ASL se desarrolló porque ITIL, adoptado por los departamentos de infraestructura de TI, resultó inadecuado para la gestión de aplicaciones: en ese momento, ITIL carecía de orientación específica para el diseño de aplicaciones, desarrollo, mantenimiento y soporte. Las nuevas versiones de ITIL, en particular V3, han abordado cada vez más los dominios de desarrollo de aplicaciones y administración de aplicaciones; La Fundación ASL BiSL ha publicado un libro blanco que compara ITIL v3 con ASL.

ASL se desarrolló a finales de los noventa en los Países Bajos, originalmente como el modelo propietario R2C, que se convirtió en ASL en 2000. En 2001 fue donado por el proveedor de servicios de TI PinkRoccade a la Fundación ASL, ahora la Fundación ASL BiSL. La versión ASL2 fue publicada en 2009.

Wikipedia

Sitio

 

BISL

Biblioteca de Servicios de Información Empresarial (Business Information Services Library – BiSL), anteriormente conocida como Biblioteca de Gestión de Servicios de Información Empresarial, es un marco utilizado para la gestión de la información.

BiSL es un estándar de dominio público desde 2005, regida por la Fundación ASL BiSL (anteriormente ASL Foundation). El marco describe una norma para los procesos dentro de la gestión de la información empresarial en la estrategia, la gestión y el nivel de operaciones. [1] BiSL está estrechamente relacionada con el marco de ITIL y ASL, pero la principal diferencia entre estos marcos es que ITIL y ASL se centran en la oferta de información (el propósito de una organización de TI), mientras que BiSL se centra en el lado de la demanda (la organización desde la perspectiva del usuario final).

Wikipedia

Sitio

 

Agile software development

El desarrollo ágil de software envuelve un enfoque para la toma de decisiones en los proyectos de software, que se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto. Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo.

Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, pruebas y documentación. Teniendo gran importancia el concepto de «Finalizado» (Done), ya que el objetivo de cada iteración no es agregar toda la funcionalidad para justificar el lanzamiento del producto al mercado, sino incrementar el valor por medio de «software que funciona» (sin errores).

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.

Wikipedia

Manifiesto ágil y los 12 principios

 

Prototipado

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Wikipedia

 

SCRUM

Scrum es el nombre con el que se denomina a los marcos de desarrollo ágiles caracterizados por:

  • Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
  • Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.
  • Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

Wikipedia

Guías oficiales de Scrum en varios idiomas

Guía de Scrum en español (2017 – PDF)

ScrumAlliance

Scrum.org

Guía de Scrum (Jerónimo Palacios)

Scrum y XP desde la trincheras (primera edición en castellano)

Scrum and XP from the Trenches (segunda edición en inglés)

 

eXtreme Programming

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Wikipedia

Sitio

CMMi

Integración de modelos de madurez de capacidades o Capability Maturity Model Integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

Wikipedia

Sitio

DAD

La entrega ágil disciplinada (Disciplined agile delivery – DAD) es un marco de procesos que permite tomar decisiones simplificadas en torno a la entrega de soluciones incrementales e iterativas. DAD se basa en las muchas prácticas adoptadas por los defensores del desarrollo de software ágil, incluyendo Scrum, el modelado ágil, el desarrollo de software lean, y otros.

La referencia primaria para la entrega ágil disciplinada es el libro del mismo nombre, escrito por Scott Ambler y Mark Lines.

En particular, el DAD ha sido identificado como un medio para ir más allá de Scrum. Según el consultor senior de Cutter, Bhuvan Unhelkar, «el marco del DAD proporciona un mecanismo cuidadosamente construido que no sólo agiliza el trabajo de TI, sino que lo más importante, permite la ampliación». Paul Gorans y Philippe Kruchten piden más disciplina en la implementación de enfoques ágiles e indican que el DAD, como ejemplo de marco, es «un enfoque híbrido y ágil para la entrega de soluciones TI empresariales que proporciona una base sólida desde la que escalar».

Wikipedia

Sitio

AUP

El Proceso Unificado Ágil de Scott Ambler o Agile Unified Process (AUP) en inglés es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development – TDD), Modelado Ágil, Gestión de Cambios Ágil, y Refactorización de Base de Datos para mejorar la productividad.

Scott Ambler dejó el desarrollo de esta metodologia en 2006 para dedicarse al desarrollo de la metodología DAD (Disciplined Agile Delivery)

Wikipedia

Sitio oficial

CDM

La metodología de diseño construccionista (CDM – Constructionist design methodology) es un enfoque para construir sistemas altamente modulares de muchos componentes que interactúan. La fuerza del MDL radica en la simplificación del modelo de sistemas complejos y multifuncionales que requieren una evolución arquitectónica del flujo de datos enredado y de las jerarquías de control.

Wikipedia

Artículo sobre Constructionist Design Methodology

EUP

Enterprise Unified Process (EUP) es una variante extendida del Proceso Unificado (RUP) y fue desarrollado por Scott W. Ambler y Larry Constantine en 2000, reelaborado en 2005 por Ambler, John Nalbone y Michael Vizdos. EUP fue introducido originalmente para superar algunas carencias de RUP, a saber, la falta de rendimiento y utilidad así como la eventual retirada de un sistema de software. Se agregaron dos fases y varias disciplinas nuevas. EUP considera que el desarrollo de software no es una actividad autónoma, sino que está integrado en el ciclo de vida del sistema (que se construirá o mejorará o sustituirá), el ciclo de vida de TI de la empresa y el ciclo de vida de la empresa. Se trata de desarrollo de software como se ve desde el punto de vista del cliente.

Wikipedia

VFSM

Una máquina de estado finito virtual es una máquina de estados finitos (FSM) definida en un entorno virtual. El concepto VFSM proporciona un método de especificación de software para describir el comportamiento de un sistema de control que utiliza nombres asignados de propiedades de control de entrada y de acciones de salida.

El método VFSM introduce un modelo de ejecución y facilita la idea de una especificación ejecutable. Esta tecnología se utiliza principalmente en aplicaciones complejas de control de máquinas, instrumentación y telecomunicaciones.

Wikipedia

RAD

Rapid application development (RAD)

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (ingeniería asistida por computadora). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Wikipedia

SADT

Análisis Estructurado y Técnicas de Diseño. Structured Analysis and Design Technique (SADT) – 1969

Es parte de una serie de métodos estructurados, que representan un conjunto de técnicas de análisis, diseño y programación que se desarrollaron en respuesta a los problemas que enfrenta el mundo del software desde 1960 hasta la década de 1980.

Wikipedia

Descripción

 

Programación estructurada

La programación estructurada es un paradigma de programación orientado a mejorar la claridad, calidad y tiempo de desarrollo de un programa de computadora, utilizando únicamente subrutinas y tres estructuras: secuencia, selección (if y switch) e iteración (bucles for y while), considerando innecesario y contraproducente el uso de la instrucción de transferencia incondicional (GOTO), que podría conducir a «código estropajo», que es mucho más difícil de seguir y de mantener, y era la causa de muchos errores de programación.

Surgió en la década de 1960, particularmente del trabajo de Böhm y Jacopini, y una famosa carta, «La sentencia goto, considerada perjudicial», de Edsger Dijkstra en 1968 — y fue reforzado teóricamente por el teorema del programa estructurado, y prácticamente por la aparición de lenguajes como ALGOL con adecuadas y ricas estructuras de control.

Wikipedia

Programación estructurada SOL

Programación estructurada Jackson

 

 

Cascada

El desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.

Wikipedia

Booch

La Metodología de Booch es una técnica usada en ingeniería de software. Es un lenguaje de modelado de objetos y una metodología ampliamente usada en el diseño de software orientado a objetos. Fue desarrollada por Grady Booch mientras trabajaba para Rational Software (hoy parte de IBM).

Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje Unificado de Modelado (UML), que combina elementos gráficos de la metodología de Booch junto a elementos de la técnica de modelado de objetos y la Ingeniería de software orientada a objetos

Los aspectos metodológicos de la metodología de Booch fueron incorporados en varias metodologías y procesos, siendo la principal de ellas el Proceso Racional Unificado (RUP).

Wikipedia

Orientación a Objetos

La programación orientada a objetos (POO, u OOP según sus siglas en inglés) es un paradigma de programación. Los objetos manipulan los datos de entrada para la obtención de datos de salida específicos, donde cada objeto ofrece una funcionalidad especial.

Wikipedia

RUP

Proceso Racional Unificado (Rational Unified Process)

Es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM.​ Junto con el Lenguaje Unificado de Modelado (UML), se utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

Se caracteriza por ser adaptable a cada organización e incluso a cada proyecto.

Wikipedia

Iterativo

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software creado en respuesta a las debilidades del modelo tradicional de cascada.

Básicamente este modelo de desarrollo, que no es más que un conjunto de tareas agrupadas en pequeñas etapas repetitivas (iteraciones), es uno de los más utilizados en los últimos tiempos ya que, como se relaciona con novedosas estrategias de desarrollo de software y una programación extrema, es empleado en metodologías diversas.

Wikipedia

Espiral

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Wikipedia

DSDM

El método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM) es un método que provee un framework para el desarrollo ágil de software, apoyado por su continua implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema que reúna las necesidades de la empresa en tiempo y presupuesto. Es uno de un número de métodos de desarrollo ágil de software y forma parte de la alianza ágil.

DSDM fue desarrollado en el Reino Unido en los años 90 por un consorcio de proveedores y de expertos en la materia del desarrollo de sistemas de información (IS), el consorcio de DSDM, combinando sus experiencias de mejores prácticas. El consorcio de DSDM es una organización no lucrativa y proveedor independiente, que posee y administra el framework. La primera versión fue terminada en enero de 1995 y publicada en febrero de 1995. La versión actualmente en uso (abril de 2006) es la versión 4.2: El framework para el Negocio Centralizado Desarrollado lanzado en mayo de 2003.

En octubre de 2016 el consorcio DSDM modificó su marca a Agile Business Consortium.

Wikipedia

Sitio

SSADM

SSADM fue producida a partir de 1980 para la Agencia Central de Informática y Telecomunicaciones (ahora Oficina de Comercio Gubernamental), una oficina de la Administración del Reino Unido que se ocupaba del uso de la tecnología en la administración pública.

SSADM es un método de cascada para el análisis y diseño de sistemas de información con un enfoque riguroso en la documentación hacia el diseño del sistema.

Wikipedia

Ciclo de vida

El Proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software.

Este proceso tiene como objetivo construir, entregar y mantener el software, desde la conceptualizacion de una necesidad hasta la entrega y retirada del sistema. Se definen las distintas fases o bloques de actividades que se utilizan para entregar un software que cumpla los requisitos para los que fue concebido.

Según ISO 12207: marco de referencia que contiene los procesos, las actividades y las tarear involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso.

Wikipedia

SWEBOK

La Guía del Cuerpo de Conocimientos de Ingeniería de Software (Software Engineering Body of Knowledge – SWEBOK Guide) describe los conocimientos generalmente aceptados sobre ingeniería de software. Sus 15 áreas de conocimiento (KAs) resumen conceptos básicos e incluyen una lista de referencias que apunta a información más detallada.

Áreas de conocimiento (knowledge areas – KAs)

Wikipedia

Formulario de descarga gratuita de la guía SWEBOK

 

 

Buenas prácticas

Conjunto coherente de acciones que han obtenido buenos, o incluso excelentes, resultados en un determinado contexto y que se espera que, en contextos similares, rindan similares resultados.

Las Mejores Prácticas Corporativas de forma general, las podemos definir como una serie de metodologías, sistemas, herramientas, y técnicas aplicadas y probadas con resultados sobresalientes en empresas que han sido reconocidas como de clase mundial. (Instituto Mexicano de Mejores Prácticas Corporativas)

Wikipedia

Marco de referencia

Concepto habitualmente asimilable a marco de trabajo. Se suele utilizar el concepto de marco de referencia cuando el objetivo no es tanto definir la forma de desarrollar software, sino establecer un punto de referencia (benchmark) que sirva para medir la situación actual de la forma de trabajar con una situación ideal o de objetivo definida por dicho marco de referencia. Ejemplo: CMMi

 

Modelo

Proceso genérico y utilizado como referencia, que define a alto nivel las actividades, roles y elementos utilizados así como la organización y secuenciación de los mismos, para desarrollar software de una forma característica y propia. Ni la calidad ni el desempeño dependen del modelo. Los modelos suelen ser más genéricos y menos concretos es sus propuestas tratando aspectos más culturales y de enfoque.

Sinónimos: modelo de referencia, marco de referencia

Metodología

Es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas.

RAE: Conjunto de métodos que se siguen en una investigación científica, un estudio o una exposición doctrinal.

Método: Es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas.

Wikipedia

 

Marco de trabajo

Del inglés framework. Entorno de trabajo o marco de trabajo es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar. Varios autores y experto en desarrollo agile, indican que las propuestas que utilizan no se pueden denominar metodologías sino frameworks.

En ocasiones, este concepto se utiliza para clasificar a soluciones software a modo de librerías o componentes especializados altamente adaptables. Por este motivo este término puede ser confuso. Continuar leyendo «Marco de trabajo»

ISO 15504

El ISO/IEC 15504, también conocido como Software Process Improvement Capability Determination, abreviado SPICE, en español, «Determinación de la Capacidad de Mejora del Proceso de Software» es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software.

Wikipedia ES

 

Métrica 3

Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información versión 3. Divulgada por el Ministerio de Hacienda y Función Pública. Aunque disponible de forma libre para cualquier empresa, su utilización actual está prácticamente restringida a las administraciones públicas.

Esta metodología se basa en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology – Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination).

Wikipedia ES

Documentación

Normas ISO

Las normas ISO (International Organization for Standardization), junto a las normas IEEE, crean el conjunto de documentos y conocimiento más veterano, extensos y de mayor valor que aplican a la ingeniería del software e ingeniería de sistemas. A continuación se muestran los distintos catálogos de normas que cubren prácticamente todos los aspectos del desarrollo de software y sistemas.

Normas ISO relativas al Software

Normas ISO relativas aspectos generales de las tecnologías de la información

Normas ISO relativas a la seguridad de la información

Normas ISO por ICS (International Classification for Standards) relativas a las tecnologías de la información