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

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

 

 

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

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

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

 

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

 

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.

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

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

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

 

 

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