Actualidad informática
Noticias y novedades sobre informática
admin
Sobre el concepto “Nivel de Madurez”
1 – Los niveles de madurez NO nacieron en el mundo del software. Fue mucho antes. El creador del concepto de “nivel de madurez” fue Crosby. El gurú de la calidad Crosby, que no tenía nada que ver con el desarrollo software, escribió un libro llamado “Quality is free” (la calidad es gratis), en el que aparecía el “Quality Management Maturity Grid (QMMG)”, con cinco niveles de madurez y que servía para evaluar los procesos de una organización. Posteriormente, sería Humphrey quien aplicaría esta idea al software (en “Characterizing the Software Process: A Maturity Framework” (1987)). Después Mark Paulk escribiría el CMM.
2 – El artículo donde por primera vez apareció el concepto de “nivel de madurez” aplicado al software es uno de los artículos más citados de la historia de la ingeniería software. Con motivo de su 25 aniversario, la revista IEEE Software recopiló sus artículos más citados, y en cuarta posición estaba el de Mark Paulk et al., “Capability Maturity Model, Version 1.1” (vol. 10, no. 4, 1993, pp. 18–27). Mark Paulk, excelente profesional y persona, con el que tuve la suerte de trabajar, y de conocer, al hacer con él mi estancia postdoctoral.
3 – Hoy hay ya decenas de campos dentro de la ingeniería del software que utilizan el concepto de nivel de madurez (incluido el mundo ágil). Los niveles de madurez no sólo existen el famoso CMMI. No sólo es la ISO 15504 parte 7 la que también utiliza niveles de madurez. Desde su aparición han aparecido múltiples Modelos de Madurez (*MM): QualiPSo Open Source Maturity Model (OMM), de aplicación al software libre, A Competency-Based Maturity Model, para la aplicación de ITIL, Outsourcing Management Maturity Model (OMMM), de aplicación en la externalización, Test Maturity Model Integration (TMMi), pruebas, Architecture Capability Maturity Model (ACMM), para arquitectura, y… un Agile Maturity Model (AMM).
Fuente: Javier Garzás
El fallo de la nave Fobos-Grunt se debió a un problema informático
Artículo publicado por Nancy Atkinson el 31 de enero de 2012 en Universe Today
Roscosmos dice hoy que un problema informático provocado por rayos cósmicos fue la razón del fallo de la nave Fobos-Grunt. Adicionalmente, chips ‘defectuosos’ en el ordenador pueden haber desempeñado algún papel, dice el director de la Agencia Espacial Federal (Roscosmos) Vladimir Popovkin. La misión original tenía como objetivo retornar una muestra de la mayor luna de Marte, pero la nave impactó en la Tierra el 15 de enero, después de que el cohete no pudiese sacarla de la órbita de la Tierra poco después de su lanzamiento en noviembre. Esta afirmación procede de un estudio realizado por una comisión liderada por Yuri Koptev, antiguo director de la Agencia Espacial Rusa.
“Hubo un reinicio de dos conjuntos de sistemas informáticos de a bordo por lo que se movió hacia el modo de máximo ahorro de energía y el comando de espera”, dice Popovkin, citado por la agencia de noticias rusa RIA Novosti. “La razón más probable es el impacto de partículas espaciales muy cargadas”.
En lo que respecta a los chips de ordenador defectuosos, Popovkin dice que los componentes fueron importados. “Probablemente aquí está la causa”, dice. Supuestamente, la NASA y el Departamento de Defensa de los Estados Unidos también han encontrado productos defectuosos, de acuerdo con un artículo en Itar-Tass.
Anatoly Zak de RussianSpaceWeb.com informa en más detalle de los posibles defectos en el diseño del sistema de control de vuelo de la sonda, conocido como BKU, comentando que “el culpable más probable del fallo en la ignición de la unidad de propulsión de la sonda después de que hubiese entrado en órbita el 9 de noviembre, fue un error de programación en el sistema de control de vuelo”.
Zak dice que una fuente de la industria reveló que la comisión que estudia el fallo “concluyó que el fallo de la misión se debía al error de diseño y la carencia de pruebas en tierra del BKU”, añadiendo que “sus defectos habían sido bien documentados mucho antes del fatídico lanzamiento”. El BKU era el ordenador principal y el “cerebro” de la nave.
Ampliar en: Ciencia Kanija
Algunas notas sobre el desarrollo software en la NASA
Breve extracto de notas interesantes sobre el desarrollo software en este contexto tan especial (Fuente, blog deJavier Garzás). Los Rovers son artefactos que mandan a explorar el espacio. En este caso a Marte, donde los Rovers más famosos son el Spirit y el Opportunity, que llegaron a Marte en 2004.
Las siguientes notas están extraídas principalmente de interesantes trabajos sobre el tema y sobre el Software Engineering Laboratory (SEL) de la NASA (ver aquí y aquí):
– Lección: No había un único proceso de desarrollo. Cada proyecto tenía su propia estructura.
– Se utilizaba Goal, Question, Metric (GQM) para evaluar la protección frente a fallos.
– Lección: la recogida de datos requiere de un proceso riguroso y un equipo de gente preparada.
– Lección: hay una relación simbiótica entre investigación y práctica, ambos ganan cuando interactúan
– Lección: minimice la burocracia
– Lección. Que exista una baseline del software, y que se saquen periódicamente “fotos” de la “salud” y progreso.
– Lección: estima periódicamente el tamaño, esfuerzo del equipo y el plan.
– Lección: Fomenta la cultura de equipo
– Lección: No implementes cambios sin conocer el impacto
– Lección: evita proyectos con exceso de personas
– Lección: gran cantidad de documentos no asegura el éxito.
– Lección: comprende el entorno y ajusta tu proceso a tu entorno
autobus las palmas aeropuerto cetona de frambuesa