Procesos ingeniería software Cmmi 1.3 mario-monsalve-2011-06-02

Mario Javier Monsalve Hazbón Gerente de Proyectos & Consultor en CMMi, Arquitectura Empresarial, SOA, BPM, ITIL, COBIT & ISO 27001

CONTEXTO ACTUAL DE MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3

Bogotá, Junio 2 de 2011

MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3 Presentación Preparada por: Mario Javier Monsalve Hazbón ( [email protected]) Diapositiva 2

Quiénes Somos?

• Raginwald Consulting fué fundada en mayo de 2007,

con el propósito de fortalecer la productividad y

competitividad de la organizaciones mediante

estrategias innovadoras que involucren mejores

prácticas de negocio y tecnologías de apoyo.

www.raginwald.com

mailto:[email protected]


Portafolio de servicios

SERVICIOS

Consultoría Tecnológica

Aseguramiento de Calidad de Software (CMMi)

Arquitectura de Software

Gobernabilidad de TI

Consultoría Gerencial

Arquitectura Empresarial

Gerencia de Proyectos

Gerencia de Procesos de Negocio

Gestión del Conocimiento

Gestión del Cambio

Formación de Competencias

Temas de Formación: ITIL, COBIT, Gerencia de Proyectos, SGCI, CMMi,

SOA, BPM, TOGAF



MARIO JAVIER MONSALVE HAZBÓN [email protected] (57)300-210-98-46

Consultor Empresarial, Especializado en las áreas Organizacional y Tecnológica, con estudios en Estados Unidos en técnicas de optimización de procesos industriales y nuevas tecnologías habilitadoras.

Ingeniero de Sistemas Cum Laude de la Universidad Industrial de Santander con especialización en Ingeniería de Software.

Áreas de Competencia:

Arquitectura Empresarial,Gestión Estratégica Corporativa y Balanced ScoreCard, Planeación Estratégica de TICs, Gobernabilidad de TI

Aseguramiento de la Calidad en Ingeniería de Software (CMMi) Gerencia de Proyectos (PMO, PMI, Prince2), Soluciones BPM & SOA (Con Tecnologías IBM, Oracle, BizAgi)

Gestión de Asimilación del Cambio, Implementación de Soluciones ERP, CRM & HCM

Adopción de Modelos de Mejores Prácticas (CMMi, ITIL, Cobit, BSI7799, eTOM)

Sistemas de Gestión ( Iso 9001, Iso 20000, Iso 38500, Iso 9126 e Iso 27001)

Actualmente CEO, Gerente de Consultoría de la Firma Raginwald Consulting

Ha sido director de departamentos de tecnología informática y de sistemas de varias compañías Colombianas.

Miembro de la Asociación Colombiana de Ingenieros de Sistemas y ha sido socio de negocios y consultor de varias firmas de Consultoría Gerencial y Tecnológica entre ellas IBM. GBM, Brown & Root Energy Services, Halliburton, Vania Technology, Oracle de Colombia, Prosistemas, Assist IT Business Solutions, Amazing Global Technologies, Avilan Santos Solutions, ConCalidad, Heinsohn Business Technology, BusinessMind.

Fue durante 6 años Director de Control de Calidad de Software de la División de Sistemas Corporativos del GRUPO AVAL.

Asesor de Varias Compañías y participante en proyectos de implementación de nuevas tecnologías de las siguientes Empresas: CitiCOLFONDOS, ICONTEC, UNIVERSIDAD JORGE TADEO LOZANO, COMCEL, AV-VILLAS, DATA TOOLS, SUPERINTENDENCIA DE SERVICIOS PUBLICOS, ATH, ETB, CERREJON, PRACO-DIDACOL, BANCO DE BOGOTA, BANCO POPULAR, CARULLA-VIVERO, TEXACO GAS UNIT, LABORATORIOS BAXTER, SECRETARIA DE HACIENDA DISTRITAL, SHELL, HOCOL, PORVENIR, JABONERIAS HADA, TERPEL, LASMO OIL, LINALCA, CONGRUPO, FEDESOFT, INCUBADORA SANTANDER, GASORIENTE, CENTRO MEDICO DANIEL PERALTA, SANTANDEREANA DE ACEITES, CENFER, CAMARA DE COMERCIO DE BUCARAMANGA, INDUSTRIAS WONDER.

Profesor Invitado de Varias Universidades: ANDES, JAVERIANA, UNINORTE, UIS, UNIVALLE, UNAB, USTA, UNICAUCA, UNILIBRE en programas de Postgrado y Maestrías




AGENDA 1. Contexto de las actuales prácticas de ingeniería de software

2. Modelos de procesos que orientan la Ingeniería de software

3. La brecha que existe entre las tradicionales prácticas de la

ingeniería de software y las que se deberían tener

4. Las consecuencias de la inmadurez y poca capacidad de los

procesos de la ingeniería de software

5. Los beneficios de adoptar las mejores prácticas de procesos en

ingeniería de software

6. El modelo de madurez y capacidad de los procesos de ingeniería

de software propuesto por el SEI (Software Engineering Institute) CMMi

7. Las mejoras que se han dado en el modelo de procesos de

desarrollo de software de CMMi en la última versión 1.3 de

Noviembre de 2010

8. Un camino de adopción de las prácticas de CMMi Dev 1.3



Justificación

La practica de la Ingeniería de Software a

nivel mundial carece de buen nivel de

calidad y cumplimiento de estándares y

buenas practicas para ejercerla, por ello

desde 1990 se viene sensibilizando y

desafiando a los profesionales para que el

software se desarrolle controladamente a

la luz de los modelos y estándares

internacionales de calidad que lo rigen



MEJORAMIENTO DE PROCESOS DEL SOFTWARE

OBJETIVO:

Mostrar los mas recientes y exitosos

modelos y metodologías para la gestión de

del proceso de desarrollo profesional de

software y efectuar un análisis

comparativo con los métodos tradicionales

para crear un marco integral del proceso

de desarrollo de software que asegure el

cumplimiento de alcances, tiempos y

costos.



Recursos más Relevantes Bibliografía

Modelo CMMi del Instituto de Ingeniería de Software

SWEBOK

PMBOK

Ingeniería de Software de Roger S Pressman

Ingeniería de Software de Ian Somerville

Sitios Web www.sei.cmu.edu

www.pmi.org

www.construx.com



Contexto e

Introducción



Contexto de la Ingeniería de

Software a nivel mundial y de

Colombia Ciencia o Arte ?

Moda o Requerimiento ?

Herramienta ?

Negocio ? Industria ?

Solución o Problema ?



Definición de Ingeniería de Software

Ingeniería de software es la disciplina o área

de la Ingeniería que ofrece métodos y

técnicas para desarrollar y mantener

software.

La creación del software es un proceso

intrínsecamente creativo y la Ingeniería del

Software trata de sistematizar este proceso

con el fin de acotar el riesgo del fracaso en la

consecución del objetivo creativo por medio

de diversas técnicas que se han demostrado

adecuadas en base a la experiencia previa.



Ingeniería de Software

Esta ingeniería trata con áreas muy diversas de la

informática y de las ciencias de la computación, tales

como:

Construcción de compiladores, sistemas operativos,

o desarrollos Intranet/Internet

Abordando todas las fases del ciclo de vida del

desarrollo de cualquier tipo de sistemas de

información y aplicables a infinidad de áreas: • Negocios

• Investigación científica

• Medicina

• Producción

• Logística

• Banca & Finanzas

• Control de tráfico

• Meteorología

• Derecho

• Internet, Intranet, etc.



CAPAS DE LA INGENIERIA DE SOFTWARE

La Ing.Software es una tecnología multicapa Enfoque de Calidad

Proceso

Métodos

Herramientas

MARCO DE CALIDAD Contexto de Negocios

Satisfacción de Necesidades de los Stakeholders

Organización, Orden, Transparencia, Controles

Estándares Internacionales de mejores prácticas



CAPAS DE LA INGENIERIA DE SOFTWARE

PROCESOS

Fases del Ciclo de Vida del Software

Asegurando un Producto Excelente

METODOLOGÍAS

Orientaciones sobre como manejar el desarrollo a

traves del ciclo de vida del software

HERRAMIENTAS

Uso de tecnologías para asistir el desarrollo del

software y asegurar el cumplimiento de los objetivos

del software

Enfoque automático / semiautomático



Características diferenciadoras del

Software

El software desempeña un papel cada vez más

importante en la sociedad actual.

Sin embargo los productos de software se

diferencian de los otros productos.

Cada vez más Complejo

Debe cumplir Conformidades (Normas y Estándares)

Variabilidad (Debe poder personalizarse)

Invisible

Tendencia de no ser Producto sino un Servicio



Características que debe tener el software

Económico

Confiable

Flexible

Portable

Mantenible

EL PRODUCTO DE LA INGENIERÍA DEL SOFTWARE



REQUERIMIENTOS DE CALIDAD QUE DEBE SATISFACER EL

SOFTWARE



ATRIBUTOS DE CALIDAD DEL SOFTWARE

Cumplir con los siguientes atributos: Seguro, Fiable, Tolerante a fallas

Comprensible, Fácil de usar

De complejidad baja,

Fácil de aprender a manejar

Mantenibilidad

Fácil de probar

Auditable

Extensibilidad

Homogeneidad, Adaptable, Modular, Reutilizable

Eficaz, Preciso, Exacto

Compatible, Portable y Acorde al contexto Tecnológico vigente

Viable financieramente (Costos de Adquisición y Mantenimiento Vs Beneficios

en generación de Valor)

Life Time

Performance ROI

Capacity

Availability

Security

Fault tolerance

Functionality

Cost Compatibility



Software Quality Assurance

Aseguramiento de la Calidad del Software

Revisiones Técnicas

Formales

SQA

Planeación

de las

Pruebas e

Inspecciones Mediciones

Análisis

&

Reportes

Definición de

Procesos &

Estandraes



PARA QUÉ SE HIZO

EL SOFTWARE ?



CUAL ES LA NECESIDAD QUE EL SOFTWARE DEBE

SATISFACER ?

Ser el medio (herramienta) que permita contribuir a “poner en orden la organización”

Que problema puede resolver: Mejor gobernabilidad de los procesos de negocio

Mejorar el ambiente colaborativo y los Niveles de Satisfacción de sus Stakeholders

• Clientes

• Accionistas

• Empleados

• Aliados de Negocios

• Proveedores

Métricas (Indicadores de Desempeño)

Posición Competitiva



PROPOSITO DEL SOFTWARE

MEJORAR LA PRODUCTIVIDAD DE LAS

ORANIZACIONES Y LOS NEGOCIOS

MEJORAR LA CALIDAD DEL VIDA DEL

SER HUMANO (CONTRARRESTAR LO

TEDIOSO, RIESGOSO, INCOMODO, ETC)



ADMINISTRAR LA COMPLEJIDAD DE LAS ORGANIZACIONES

CON HERRAMIENTAS IDONEAS

Jefe de Producción

Superintendente

Distriro

Jefe de

Mantenimiento

Jefe de

Materiales

OP CH “A”

OP CH “B”

OP Ballena

OP Riohacha

Ingenierosde

Producción

HSE

Cuad.

Datos de calibr.

P&T

Bodega

Banco

Proveedores

Materiales

Gobierno

Guajira

Técnicos

Manto.

Promigas &

Centrogas

Compañía

Comtratista

Cia. Corrosión

y Quimicos

Marina

Gobierno, Autoridad

y Marina

Contratista del

Barco

Dpto. Ing

Petróleos

Proyectos

Banco

Oficina General

Soldador

Compañía

Comtratista

Ministerio de

Minas & Energía

Bogotá Jefe

Ecopetrol

Houston

ITD

Legal

Recursos

Humanos

Contaduria

HSE

- Informe Escrito

- Informe Verbal

- Instrucción Escrita

- Instrucción Verbal

Pruebas de polos

Rep

etir Pru

eba

Datos producc. Pedidos Materiales

Promedios

Control de A

rena

Info

rme d

e

Manto

.

Ord

en

de tra

bo

jo, a

pro

b.

Ap

rob

ació

n

Fis

cal

izació

n p

rog

reso

de

pro

du

cció

n y

pru

eb

as

1/D

Rec

om. y

Con

trol

de

Are

na e

n G

enra

l.

Factu

ras de G

as

Presu

puesto

Fiscalización

Fiscal

P de T

Rep

ort

. co

rrosi

ón, fa

llas

seg

uri

dad

y q

uim

ico d

osi

fic.

Req. compras nacionale e internacionales

Pedidos de servicios

Co

ntab

ilidad

- No

rmas

Fiscalización mensual

Normas Auditorías

Inspec. y Recomendaciones

Tareas Reportes diarios .

Rep. Corrosión y Seguridad

Instruc. y proced.

Rep

ort

e P

rod

. p

ozo

x p

ozo

Actas de calibración y correcciones

Gastos

Rep

po

rtes

Orden de Trabajo

Facturas

Listado fallas de equipos nuevos

Reporte diario

y semanal

Pedidos > 20,000

USD

Sop

orte

Téc

nico

Co

ntrato

s

17 R

Pro

med

ios D

ato

s

Pruebas de P

ozos

Fiscalia

Info

rmació

n

. Instrcc. cierre ó apertura pozosy reporte diario

Rep

ort

es

Tra

baj

os

com

ent.

y p

reg

un

t. d

e p

rod

.

Ex

cep

cio

nes

Reco

men

dació

n

Pro

ceso p

rueb

as esp

eciales.

Ev

alu.estu

dio

s

Info

r. act

ivid

s. 1/m

es

Aprobación de

Compra

Co

ntra

t. min

uto

s pd

os d

e trab

ajo

Factu

ras de G

as

Rep

ort

e del

dia

Oblea & Fallas 1/d

Rd

e dia

1/sem.

Trabajos realiz.

Servicio de fallo

P/6

Ped

ido

s Trab

ajo

RQ

S

Sim

ulacro

s de S

egu

ridad

Producc. Rqs

Entreg. y Recibos Mats.

Contr

atos

Lineasde conección

Alteraciones, Puntos de

Presión, Inhibidores de

Presión, Pruebas de

valvula subsuelo

Decadas de Producción

Firma Centro Gas

& Promigas

Ofic. Producción

Banco de la Republica

Facturas

Factu

ras

M aterialesM antenimiento

Producc. Pedidos

Rec

om

en

da

c.

Info

rmes

Pro

gra

ma

s



REFLEXION !

EL SOFTWARE Y LA

INGENIERIA DE

SOFTWARE ESTAN

CUMPLIENDO EL

PROPOSITO ?



LA CRISIS DEL SOFTWARE !

Bajos niveles de

productividad

Demasiados reprocesos

Sobrecostos

Tiempos de entrega

inoportunos

Complejidad en el proceso

de mejora continua



EL ESTADO DEL DESARROLLO DE SOFTWARE

La mayoría de los proyectos de desarrollo de software fallan

Qué significa fallar?

No cumplir los cronogramas

No cumplir el presupuesto

No satisfacer la funcionalidad requerida

Demasiados defectos una vez en producción

Demasiado frágil a los cambios

...



¿Qué tipo de Problemas Surgen?

Retrasos en los proyectos.

Falta de calidad.

Incumplimiento con la funcionalidad acordada.

Desarrolladores que improvisan permanentemente

Exceso de requerimientos y funcionalidad.

Falta de una planificación responsable

Motivación débil, Falta de participación.

No existe gestión de riesgos.

ALLSOFT, S.A.. de C.V., 2002



Fuente: Standish Group International

Exitosos

29% Cuestionables

53%

Fallidos

18%

Miles de Millones USD de Desperdicio

DESEMPEÑO DE LOS PROYECTOS DE INGENIERIA DE SOFTWARE



EL ESTADO DEL DESARROLLO DE SOFTWARE

Proyectos

cancelados

antes de

terminarse

31.1%

Proyectos

terminados

68.9%

Standish Group International Report, “Chaos” Open Computing



EL ESTADO DEL DESARROLLO DEL SOFTWARE

Proyectos

dentro de los

tiempos y

costos

previstos

16%

84%

Standish Group International Report, “Chaos”, Open Computing



El estado del desarrollo del software

Cuestan

190% más

que el valor

estimado

57%

43%




EL ESTADO DEL DESARROLLO DEL SOFTWARE

Proyectos

que

satisfacieron

totalmente

los

requerimeint

os

42%

58%




LA GESTION TRADICIONAL EN LA INGENIERIA DE

SOFTWARE



LA GESTION EN LA INGENIERIA DE SOFTWARE



EL DESBALANCE ENTRE LA OFERTA & DEMANA DE

SOFTWARE

CADA VEZ LAS ORGANIZACIONES DEMANDAN MAS APOYO

TECNOLOGICO

LA ERA POST-INDUSTRIAL o DIGITAL

NEW ECONOMY

LOS RECURSOS TECNOLOGICOS NO SOLO REQUIEREN DINERO,

SINO CAPACIDAD DE GESTION

DISPONIBILIDAD DE EXCELENTES TECNOLOGIAS DE BASE

INFRAESTRUCTURA CRECIENTE

TENDENCIA GLOBALIZADA (INTERNET,WEB 2.0 & e-BUSINESS)



REVISION DEL MARCO GENERAL DE LA INGENIERIA DE

SOFTWARE

"La calidad de un

producto es

ampliamente gobernada

por la calidad del

proceso usado para

construirlo“

Mark C. Paulk



REFLEXION



REFLEXIÓN

QUÉ AJUSTES LE DEBEMOS

PRACTICAR A NUESTROS

PROCESOS DE DESARROLLO

DE SOFTWARE PARA QUE

ESTÉN ALINEADAS A LOS

RETOS Y DESAFÍOS DE

NEGOCIO y CAPITALICE EL

POTENCIAL DE LAS TIC´s ?



EL DINAMISMO DE LAS ORGANIZACIONES

DIMENSIONANDO EL CAMBIO DE ESCENARIOS Y

EL CAMINO DE TRANSICION

SITUACION ACTUAL

SITUACION DESEABLE Y

VIABLE



PONER LA CASA EN ORDEN



EL SOFTWARE DEBE

ASEGURAR LA

OBTENCIÓN DE LOS

BENEFICIOS DE NEGOCIO

A UNOS COSTOS

RAZONABLES



CALIDAD

Es un conjunto de propiedades asociadas a un objeto

que le confieren capacidad para satisfacer necesidades

implícitas o explícitas.

La calidad de un producto o servicio es la percepción

que el cliente tiene del mismo, es una fijación mental

del consumidor que asume conformidad con dicho

producto o servicio y la capacidad del mismo para

satisfacer sus necesidades.

La calidad significa aportar valor al cliente, esto es,

ofrecer unas condiciones de uso del producto o servicio

superiores a las que el cliente espera recibir y a un

precio accesible



ASEGURAMIENTO

Son las medidas preventivas

que se toman paso a paso

durante un proceso para evitar

que el resultado final no sea

defectuoso

Diferente de Control de

Calidad

No es solo la Revisión al final del

proceso

No es solo enfocado al cliente



PANORAMA DE

LA INDUSTRIA

DE SOFTWARE

EN COLOMBIA



ACTIVIDADES DE LA INDUSTRIA



INVERSION DE LOS SECTORES ECONOMICOS EN T.I.



MACRO TENDENCIAS DE CRECIMIENTO



PANORAMA DE LA INDUSTRIA DE SOFTWARE EN COLOMBIA



NO ALCANZAMOS A FIGURAR EN

POSICIONAMIENTO DEL MERCADO DE SW



Cambio esperado en la participación del mercado

mundial de software



PANORAMA DE LA INDUSTRIA DE SOFTWARE EN COLOMBIA



Panorama mundial de la Ing. Software “La Muralla China del Software”



Panorama mundial de la Ing. Software

El Modelo de Software & Servicios de la India




El Modelo de Software & Servicios de la India




Costo de $(1 ingeniero USA) = $(2.5 ingenieros Colombianos) =

$(5 ingenieros de India) = $(8 ingenieros de China)

Si nuestra industria de software no se fortalece aplicando

modelos y mejores practicas que internacionalmente sean

reconocidos (Cmmi, ISO´s, IEEE, etc) y se capitalicen las

tecnologías disponibles ;los grandes negocios (> 500mUsd) se

los llevaran las potencias del Software

El Pez Grande se come al pez Chico !



REFLEXION

“Tuvimos que pelear dos batallas para triunfar.

La primera fue en nuestra mente !”



Modelos de

Procesos de

Ing. Software



EL PROCESO DE SOFTWARE

OBJETIVOS Satisfacer una necesidad de negocio mediante una solución asistida por

Computador.

Producir el mantenimiento del software hasta el fin de su vida útil.

BENEFICIOS Definir una estructura de proyectos manejable.

Definir un esquema para planificar, organizar, asignar personal, coordinar, presupuestar, y dirigir las actividades de la construcción de software.

Encadenar las tares y actividades del proceso software de una determinada forma.

Determinar la entrega y producción de la documentación guía para el usuario.

Determinar que herramientas, técnicas y metodologías de Ingeniería de Software serán más apropiadas.



LOS MODELOS CONTRARRESTAN LOS MITOS

Mitos de Gestión

Resistencia al cambio en la gestión de proyectos

Con un libro de estándares es suficiente

Computadores modernos = Buen entorno de desarrollo

Mitos de Gestión

Experiencia para saltarse las metodologías

Incapacidad de los usuarios para comunicar sus necesidades

Mitos del Cliente

Ideas genéricas al principio, detalles al final

Requisitos en continua evolución

Mitos del Desarrollador

El trabajo acaba cuando se ha escrito el programa y funciona

Hasta que no se ejecuta el programa no puede comprobarse su calidad

Sólo se entrega un programa funcionando

Lo que uno crea sólo debe entenderlo él



LA ESTRATEGIA DE SALVAMENTO DE LA INGENIERIA DE

SOFTWARE EN LAS ORGANIZACIONES

NUEVOS

PROCESOS + NUEVAS

TECNOLOGIAS = ORGANIZACIÓN

MAS EFECTIVA + PERSONAL

COMPETENTE CON LA

ACTITUD ADECUADA Y

ALINEADA A LAS

METAS DEL NEGOCIO

Asegurables



EL ÉXITO EN DESARROLLO DE SOFTWARE



LA CORRECTA APLICACIÓN DE LA TECNOLOGIA EN UN e-BUSINESS

NUEVOS

PROCESOS



UN ANTI-EJEMPLO DE UTILIZACION DE LAS

TECNOLOGIAS



UN ANTI-EJEMPLO DE UTILIZACION DE LAS TECNOLOGIAS…

CONTINUACION



DOS ENFOQUES DE GESTION EN LOS PROCESOS

Orquestado

Bien Diseñado

Monitoreado

Improvisado

Fruto de la

Inspiración

Centrado en Héroes


http://www.tamborygaita.com/sPfilm.html


EL PROPOSITO DE LOS MODELOS ES EL DE

CONTRARRESTAR LAS MALAS PRACTICAS

Todo empieza con optimismo y

entusiasmo !



CONTRARRESTANDO LAS MALAS PRACTICAS

Pero muchas de las iniciativas de gestion

de la calidad fracasan !




Los problemas empiezan en las practicas gerenciales del

proceso tecnológico (algunas veces el exceso de confianza)




No se le da la importancia sino a la ultima capa del software,

ignorando sus fundamentos



EN EL DESARROLLO DE SOFTWARE

El éxito no es cuestión de suerte, es

cuestión de actitud profesional.



LO MEJOR

EN SU CLASE.

“CLASE MUNDIAL”

LAS MEJORES PRACTICAS

MEJORA DE LAS PRACTICAS ACTUALES

IGUAL O INFERIOR A LAS PRACTICAS CORRIENTES

Esquema Universal de Mejores Practicas

NO IGNORAR LAS MEJORES PRACTICAS



Las Mejores Prácticas: Estándares de IT



MAPA DE MODELOS QUE ORIENTAN LA GESTION T.I.



CAPITALIZANDO LAS NUEVAS TECNOLOGIAS EN LA INGENIERIA

DE SOFTWARE

NUEVAS

TECNOLOGIAS



Contexto de tendencias

en Ingeniería de

Software



PANORAMA DE LAS GENERACIONES DE T.I.



INGENIERIA DE SOFWARE ASISTIDA POR HERRAMIENTAS

Herramientas de Modelamiento & Arquitectura

EA-TOOLS: Troux, Rational Systema Architect, Enterprise Architect, Power Designer, Visio

Herramientas para gestión de requerimientos

Requisite Pro, Doors, Gforge, RedMine

Herramientas para Gestión de la Configuración

SubVersion, CVs, Clearcase

Herramientas para Especificación de Casos de prueba

TestLink

Herramientas para gestión de defectos

Mantis, Elementtool

Herramientas para Planeación y Control de Proyectos

Project, EPM, RPM, Gforge, Web2Project, Project.net, Primavera, PlanView

Automatización de Pruebas Rational SQA Test, Robot, WinRunner, Remedy

Herramientas para gestión de contenido Life Ray

Herramientas para generación de código Genexus, RationalRose

Herramientas de Gestión de Flujos de Trabajo (WF) e Incidentes (Service Desk)



Algunos Estándares de Calidad



¿ Qué se busca al implantar un estándar de

Calidad de Software ?

# E

rro

res

/ K

LO

CS

Tiempo

Control de calidad

Proceso de mejoramiento

Nivel X

Nivel Y



Sistema de Calidad de Software

Estándares

Revisiones

Pruebas

Análisis de defectos

Administración de la configuración

Seguridad

Educación

Administración de contrataciones

Las personas responsables por los proyectos del software son sólo quienes pueden ser responsable por calidad. El papel de SQA es supervisar la manera en que estos

grupos ejecutan sus responsabilidades. Humphrey



LAPSO NORMAL ENTRE ORIGEN Y APARICION DE DEFECTOS

Origen

Aparición

Requerim. Diseño Program. Document. Testing Mantenimiento


Zona de Caos



Origen

Aparición

LAPSO ENTRE ORIGEN Y APARICION DE DEFECTOS EN UN PROCESO CONTROLADO





GOBERNANDO EL CICLO DE VIDA DE UNA SOLUCION DE SOFTWARE

1. DIMENSIONAMIENTO ESTRATEGICO (FORMULAR Y

VIABILIZAR EL PROYECTO)

As-Is & To-Be (Alto Nivel)

2. ANALISIS DETALLADO DE LA SITUACION

ACTUAL (As-IS)

(Ingeniería de Requerimientos)

7. ALISTAMIENTO DE LOS SISTEMAS DE INFORMACION

SATELITES Y LOS SERVICIOS DE NEGOCIO

3. DISEÑO -ARQUITECTURA DEL

ESCENACIO DESEABLE Y VIABLE &

PLANEACION DEL PROYECTO

To-Be

11. PREPARACION DEL PERSONAL (COMPETENCIAS)

8. ORGANIZACIÓN DE LA INFORMACION A MIGRAR

12. PRUEBAS PILOTO / SIMULACROS

13.ADAPTACIONES FINALES

14. CHEQUEO DE

CONDICIONES

PREVIAS A LA PUESTA

EN MARCHA

18. SEGUIMIENTO AL DESEMPEÑO

16. ESTABILIZACION & SOPORTE

19. MEJORAMIENTO CONTINUO

15. PUESTA EN MARCHA

5. ADQUISICION & ALISTAMIENTODE LA INFRAESTRUCTURA TECNOLOGICA

10. PREPARACION DOCUMENTACION

4. CONSECUCION DE RECURSOS

6. DESARROLLO/PERSONALIZACION DEL SOFTWARE Y PRUEBAS TECNICAS

17. GESTION INCIDENTES

9. CONFIGURAR & PARAMETRIZAR APLICACION



El proceso de Software: Modelo IDEAL

[McFeeley 96]



CMM: Marco de Trabajo Capability Maturity Model - SEI

Marco de trabajo del proceso común en la Organización

Actividades del Marco de Trabajo

Conjunto de Tareas

Tareas

Hitos, entregas

Puntos SQA

Actividades de Protección

Optimizado

Inicial

Repetible

Definido

Dirigido 5 Niveles de Madurez

18 Áreas Clave en el CVS


MEJORA A LOS PROCESOS DE INGENIERÍA DE SOFTWARE SEGÚN EL MODELO CMMi v 1.3 Presentación Preparada por: Mario Javier Monsalve Hazbón ( [email protected]) Diapositiva 88 CAPABILITY MATURITY MODEL (CMM)

El 70% o mas de los problemas en

Ingeniería de Software están

relacionados con el proceso.

El 30% relacionados con otros

aspectos

Las estadísticas muestran que ….



Categorías de los procesos en CMMi



CATEGORIAS & AGRUPACIÓN x NIVELES



ACRONIMOS DE LOS PROCESOS CMMi



PROYECTO SPICE, ISO/IEC TR 15504 Software Process Improvement and Capability dEtermination

Proceso

Valoración

del

ProcesoDeterminar

Nivel de

Madurez

Mejora

del

Proceso

Sujeto a Puede

Conducir a

Conduce a

Conduce a

Identifica

Cambios a

Está

sometido a



TEMA 4: EL MODELO

INTEGRADO DE MADUREZ DE LA

CAPACIDAD DEL SOFTWARE

CMMi



MARCO DE MODELOS PARA MEJORAR CALIDAD DEL

SOFTWARE



Implementación y Valoración de CMMI

CMMi – Capability Maturity Model Integration

Optimizado

Inicio

Gestionado

Definido

Administrado

cuantitativamente

Enfoque mejoramiento procesos

Proceso medido y controlado

Proceso caracterizado por la

organización y pro actividad

Proceso caracterizado por

proyectos y son usualmente reactivos

Proceso impredecible,

pobremente controlado y reactivo

2

1

3

4

5

NIVELES DE MADUREZ



Categorías de los procesos en CMMi



ACRONIMOS DE LOS PROCESOS CMMi



COMPAÑIAS VALORADAS EN NIVELES CMMi



ESTADISTICAS DE CMMi (2010)



Empresas con evaluación CMMi



EL RETO:

DISCIPLINAR EL

PROCESO DE

SOFTWARE

Nivel 2 - Repetible



AREAS CLAVES DE PROCESO CMMi

Nivel 2: 1. PP- Planeación de Proyectos de Software

2. PMC- Control y Seguimiento de Proyectos de Software

3. REQM- Administración de Requerimientos

4. CM- Administración de la Configuración de los Componentes del Software

5. SAM- Gestión de Terceros en el Proceso de Desarrollo de Software

6. PPQA- Aseguramiento de estándares de calidad en el software (Producto & Proceso)

7. MA- Definición de Métricas y Análisis del Desempeño de los Procesos de Software



Proceso Consistente y Estándar

REPETICIÓN DE EXPERIENCIAS EXITOSAS

El objetivo son los proyectos

Repetir los éxitos logrados con proyectos similares

Control gerencial básico y disciplina en el proceso

Se establecen políticas y procesos básicos de Administración de

proyectos

Se fija y controla la obtención de los requerimientos de software

Se definen y se siguen estándares para los proyectos de desarrollo de

software

El proceso es disciplinado

Proyectos exitosos son frecuentes

Repetición de

Experiencias Exitosas

LOS CINCO NIVELES DE LA MADUREZ DEL PROCESO DE SOFTWARE

(Nivel 2: REPETIBLE)



Apagados los incendios,

defina procesos y opere a

nivel de organización

Nivel 3 - Definido



NIVEL 3 DE CMMi

Nivel 3:

RD- Desarrollo de los Requerimientos

TS- Soluciones Técnicas

VAL- Validación (Pruebas)

VER- Verificación (Proceso)

OPF- Enfocar a la Organización a Operar x Procesos

OT- Programa de adiestramiento

IPM- Integración Gerencia Proyecto e Ingeniería de S/W

PI- Ingeniería de productos de S/W

RSKM- Gestión de Riesgos

DAR- Análisis de Decisiones y Resolución



Proceso Predecible

DEFINICIÓN DEL PROCESO ESTANDAR

El objetivo es la organización

Los aspectos claves del proceso son conocidos y

utilizados en toda la organización

El proceso de desarrollo y mantenimiento de software es

estandarizado

El proceso estándar es una integración de las actividades

administrativas y de ingeniería de software

Todos los proyectos usan y ajustan a sus necesidades, el

estándar aprobado para mantener o desarrollar el

software.

Definición del

Proceso Estándar

LOS CINCO NIVELES DE LA MADUREZ DEL

PROCESO DE SOFTWARE



Conozca sus procesos

cuantitativamente

Nivel 4 - Administrado



Proceso Mejorándose Contínuamente

GESTIÓN EFECTIVA

Se recolectan medidas detalladas de la calidad,

tanto del proceso de desarrollo mismo como del

software

El proceso de desarrollo y los productos

obtenidos son comprendidos y controlados

cuantitativamente

La productividad de los procesos también es

medida y controlada

El proceso de desarrollo es predecible

Gestión

Efectiva

LOS CINCO NIVELES DE LA MADUREZ DEL

PROCESO DE SOFTWARE

ÁREAS CLAVES Gestión de la calidad del software

Gestión cuantitativa del proceso



Mejore constante y

permanentemente

Nivel 5 - Optimización



“

Organización Madura

“Una organización madura, en contraste,

posee habilidad a través de toda la

compañía para desarrollar y mantener

software. Posee habilidad para transmitir

tanto a los nuevos como a los empleados

actuales el proceso de software y lleva a

cabo las actividades de acuerdo con los

planes. Los procesos están documentados,

se utilizan y son consistentes con la forma

real de trabajo. ”



“

Organización Madura

“Las definiciones de procesos se actualizan

cuando es necesario y las mejoras se

desarrollan a través de pruebas piloto y

análisis de costo - beneficio. Los roles y

responsabilidades son claros en los procesos

y a través de toda la organización... En

general, las organizaciones maduras siguen

un proceso disciplinado consistentemente

porque todos los participantes entienden el

valor de hacerlo así ”.



5

GENERALIDADES

DE CADA UNA DE

LAS AREAS DE

PROCESOS DE

CMMi



AREA DE PROCESOS DE PROYECTOS



AREA DE PROCESOS DE INGENIERIA



AREA DE PROCESOS DE SOPORTE



AREA DE PROCESOS DE GESTION X PROCESOS



METAS DE CADA AREA DE PROCESO



AREAS AVANZADAS DE PROYECTOS



AREAS AVANZADAS DE SOPORTE



AREAS AVANZADAS DE GESTION X PROCESOS



RD- Desarrollo de los Requerimientos

El propósito del Desarrollo de requerimientos (RD) es producir y analizar

los requerimientos de cliente, de producto y de componente del producto.

Identifica las necesidades del cliente y traduce dichas necesidades en

requerimientos del producto. El conjunto de requerimientos del producto

se analiza para producir una solución conceptual de alto nivel. Este

conjunto de requerimientos se asigna entonces para establecer un

conjunto inicial de requerimientos de componentes del producto.

Otros requerimientos que ayudan a definir el producto se derivan y asignan

a componentes del producto. Este conjunto de requerimientos del

producto y de componentes del producto describe de manera clara la

ejecución del producto, las características del diseño, los requerimientos

de verificación, etcétera, de tal modo que el desarrollador pueda

comprender y usar.

Este proceso va desde la identificación de los requerimientos de software

hasta dejarlos generados y aprobados por los involucrados para que el

proceso de administración (REQM) los custodie y controle los cambios que

surjan.



RD-DESARROLLO DE LOS REQUERIMIENTOS

IEEE Std 830-1998



RD-DESARROLLO DE REQUERIMIENTOS

Metas específicas para Desarrollo de

Requerimientos (SG-RD)

SG 1 Establecer los requisitos del cliente • Las Necesidades de los interesados, expectativas, limitaciones, y

las interfaces son recogidos y traducidos a los requerimientos del

cliente.

SG 2: Desarrollar los requisitos del producto • Los requerimientos del cliente son refinados y elaborados para

desarrollar los requisitos del producto y el producto de los

componentes.

SG 3 Analizar y validar los requisitos • Los requisitos son analizados y validados, y una definición de la

funcionalidad requerida desarrollados.




El propósito de la Solución técnica (TS) es diseñar, desarrollar e implementar

soluciones para los requerimientos. Las soluciones, los diseños y las

implementaciones engloban productos, componentes de producto y procesos

del ciclo de vida asociados al producto, individualmente o en combinación,

según sea apropiado.

El área de proceso se enfoca en:

Evaluar y seleccionar soluciones (referidas a veces como “planteamiento

de diseño”, “conceptos de diseño” o “diseños preliminares”) que

potencialmente satisfacen un conjunto apropiado de requerimientos

asignados.

Desarrollar diseños detallados para las soluciones seleccionadas

(detallados en el contexto de contener toda la información necesaria para

fabricar, codificar o, de otra manera, implementar el diseño como un

producto o componente de producto).

Implementar los diseños como un producto o componente de producto.



Resumen de metas y prácticas específicas

SG 1 Seleccionar las soluciones de componentes de producto. SP 1.1 Desarrollar las soluciones alternativas y los criterios de selección.

SP 1.2 Seleccionar las soluciones de componentes de producto.

SG 2 Desarrollar el diseño. SP 2.1 Diseñar el producto o el componente de producto.

SP 2.2 Establecer un paquete de datos técnicos.

SP 2.3 Diseñar las interfaces usando criterios.

SP 2.4 Realizar los análisis sobre si hacer, comprar o reutilizar.

SG 3 Implementar el diseño de producto. SP 3.1 Implementar el diseño.

SP 3.2 Desarrollar la documentación de soporte de producto.




PP- Planeación de Proyectos de Software

El proceso PP tiene como propósito el Desarrollar y mantener los

planes del proyecto, los compromisos adquiridos por parte de los

participantes del proyecto y gestiona las partes interesadas del

proyecto

El proceso de PP se desagrega en los siguientes subprocesos:

Planificación del Alcance (G. Alcance).

Definición del Alcance (G. Alcance).

Creación de EDT(WBS) (G. Alcance).

Definición de Actividades (G. Tiempo).

Establecimiento de Secuencia de Actividades (G. Tiempo).

Estimación de Recursos (G. Tiempo).

Estimación de la Duración de las Actividades (G. Tiempo).

Desarrollo del Cronograma (G. Tiempo).



PP-PLANEACION DE PROYECTOS

Practicas específicas para Planeación de proyectos (SP-PP)

SG 1. Establecer estimaciones

• SP 1.1 Establecer el alcance del proyecto

• SP 1.2 Establecer y mantener estimaciones para los atributos de trabajo y los

atributos de las tareas

• SP 1.3 Definir el ciclo de vida del proyecto

• SP 1.4 Determinar estimaciones de esfuerzo de trabajo y costo

SG 2. Desarrollar un plan de proyecto

• SP 2.1 Establecer un presupuesto y un cronograma

• SP 2.2 Identificar los riesgos de proyecto

• SP 2.3 Planear la administración de los datos

• SP 2.4 Planear los recursos para llevar a cabo el proyecto

• SP 2.5 Planear para las necesidades de conocimiento y habilidades

• SP 2.6 Planear la participación de los interesados en el proyecto

• SP 2.7 Establecer el plan del proyecto

SG 3. Obtener compromisos hacia el plan

• SP 3.1 Revisar los planes que afecten el desarrollo del proyecto

• SP 3.2 Conciliar el trabajo y el nivel de recursos

• SP 3.3 Obtener un plan de compromisos



PMC- Control y Seguimiento de Proyectos de Software

El proceso de monitoreo y control de proyectos (PMC)

tiene como propósito el proveer un entendimiento del

avance del proyecto a fin de que las acciones

correctivas sean tomadas en el momento en el que el

proyecto se desvié significativamente del plan

Es muy importante tener en cuenta, para el monitoreo

y el control del proyecto, la documentación del

proyecto y la estructura de desglose de trabajo (EDT)

como medida de control del proyecto para tomar las

acciones correctivas necesarias en caso de que el

proyecto se desvié significativamente del plan.



PMC

Gestión de Integración

Supervisión y control del trabajo del proyecto

Control integrado de cambios

Gestión de Alcance

Verificación de alcance

Control de alcance

Gestión de Tiempo

Control del cronograma

Gestión de Costos/Presupuesto

Control de Costos/Presupuesto

Gestión de la Calidad

Control de la calidad

Gestión de Recurso Humano

Gestión del equipo del proyecto

Gestión de las Comunicaciones

Informe de rendimiento

Gestión a los interesados

Gestión de los Riesgos

Seguimiento y control de riesgos



PMC

Practicas específicas para Monitoreo y control de proyectos (SP-PMC)

SG 1. Monitoreo del proyecto contra el plan

SP 1.1 Monitoreo de los parámetros del plan del proyecto

SP 1.2 Monitoreo de compromisos

SP 1.3 Monitoreo de los riesgos del proyecto

SP 1.4 Monitoreo de la gestión de la información

SP 1.5 Monitoreo del involucramiento del Stakeholder

SP 1.6 Revisar periódicamente el progreso del proyecto, el rendimiento y los problemas

SP 1.7 Revisión de los logros y resultados en los hitos del proyecto seleccionado

SG 2. Administración de las acciones correctivas al cierre

SP 2.1 Análisis de los inconvenientes

SP 2.2 Toma de acciones correctivas

SP 2.3 Administración de las acciones correctivas



REQM- Administración de Requerimientos

Mantiene los requerimientos de software que fueron generados por

el proceso de Desarrollo de Requerimientos (RD).

Describe las actividades para obtener y controlar los cambios a los

requerimientos, y asegurar que otros planes y datos relevantes se

mantengan actualizados. Proporciona la trazabilidad de los

requerimientos desde el cliente al producto y de éste a sus

componentes.

La Gestión de requerimientos asegura que los cambios a los

requerimientos se reflejan en los planes, actividades y productos

de trabajo del proyecto. Este ciclo de cambios puede afectar a

todas las otras áreas de proceso de Ingeniería; así, la Gestión de

requerimientos es una secuencia de eventos dinámica y a menudo

recursiva. El área de proceso de Gestión de requerimientos es

fundamental para un proceso de diseño de ingeniería controlado y

disciplinado.




Este proceso de administración de los

requerimientos de software cubre la recepción

de los requerimientos generados por el proceso

de Desarrollo de Requerimientos (RD) y

controla la gestión de cambios de los mismos

Se Desagrega en:

Administrar el sistema de información de los

requerimientos

Obtener una comprensión de los requerimientos

Obtener el compromiso sobre los requerimientos

Gestionar los cambios de los requerimientos

Mantener la trazabilidad bidireccional de los

requerimientos




ADMINISTRAR EL SISTEMA DE INFORMACIÓN DE LOS REQUERIMIENTOS

Recepción de requerimientos aprobados

Registrar los estados del requerimiento

Registrar Fecha y Hora de la modificación

Registrar responsables

Registrar la descripción de los cambios

OBTENER UNA COMPRENSION DE LOS REQUERIMIENTOS

Establecer los criterios para distinguir a los proveedores apropiados de requerimientos.

Establecer los criterios objetivos para la evaluación y la aceptación de los

requerimientos.

Analizar los requerimientos para asegurar que se cumplen los criterios establecidos.

Alcanzar una comprensión de los requerimientos con el proveedor de requerimientos

para que los participantes del proyecto puedan comprometerse con ellos.

OBTENER EL COMPROMISO SOBRE LOS REQUERIMIENTOS

Evaluar el impacto de los requerimientos sobre los compromisos existentes

Negociar y registrar los compromisos



GESTIONAR LOS CAMBIOS DE LOS REQUERIMIENTOS

Documentar todos los requerimientos y los cambios a los requerimientos que

son dados o generados por el proyecto.

Mantener la historia de cambios de requerimientos con la razón del cambio.

Poner los requerimientos y los datos de los cambios disponibles para el

proyecto.

MANTENER LA TRAZABILIDAD BIDIRECCIONAL DE LOS REQUERIMIENTOS

Mantener la trazabilidad de los requerimientos.

Mantener la trazabilidad de los requerimientos desde un requerimiento a sus

requerimientos derivados

Generar la matriz de trazabilidad de los requerimientos.

Revisar los planes, las actividades y los productos de trabajo del proyecto en cuanto a la

consistencia con los requerimientos y los cambios realizados a ellos.

Identificar la fuente de la inconsistencia y la razón.

Identificar los cambios que necesitan realizarse a los planes y a los productos de trabajo

resultantes de los cambios a la línea base de los requerimientos.

Iniciar las acciones correctivas

REQM



CM- Administración de la Configuración de los

Componentes del Software

El propósito de la Gestión de configuración (CM) es establecer y

mantener la integridad de los productos de trabajo utilizando la

identificación de configuración, el control de configuración, el

registro del estado de configuración y las auditorías de

configuración.

El área de proceso de Gestión de configuración implica:

Identificar la configuración de los productos de trabajo

seleccionados que componen las líneas base en puntos

determinados en el tiempo.

Controlar los cambios a los elementos de configuración.

Construir o proporcionar especificaciones para construir los

productos de trabajo a partir del sistema de gestión de

configuración.

Mantener la integridad de las líneas base.

Proporcionar a los desarrolladores, usuarios finales y clientes

datos del estado exacto y de la configuración actual.





Es un área Transversal a los demás

procesos

Es común en RUP, ITIL, COBIT





Algunos ejemplos de productos de trabajo que pueden

ponerse bajo gestión de configuración son:

Planes.

Descripciones de proceso.

Requerimientos.

Datos de diseño.

Dibujos.

Especificaciones de producto.

Código.

Compiladores.

Ficheros de datos de producto.

Publicaciones técnicas de producto.



CM Administración de la Configuración de los


Administración de la

configuración

SG1/ Establecer

Líneas base

SG2/ Seguimiento y

control de cambios

SG3/ Establecer la

integridad

SP1.1/ Identificar

artículos de la

configuración

SP1.2/ Establecer

SCM

SP1.3/ Crear o

liberar líneas base

SP2.1/ Seguimiento

a las solicitudes de

cambios

SP2.2/ Controlar

los artículos de la

configuración

SP3.1/ Establecer

registro de

administración de

la configuración

SP3.2/ realizar

auditorias



SAM- Gestión de Terceros/Contratistas en el Proceso de

Desarrollo de Software

El propósito de la SAM (Administración de Acuerdo con

Proveedores) es administrar la adquisición de productos

de proveedores.

El área de proceso SAM involucra:

Determinar el tipo de adquisición que será usado para los

productos a ser adquiridos

Seleccionar el tipo de proveedores.

Seleccionar y mantener • acuerdos con proveedores.

Ejecutar el acuerdo de proveedores.

Monitorear el proceso de proveedores seleccionados.

Evaluar el trabajo de los productos del proveedor seleccionado.

Aceptar la entrega de productos adquiridos.

Trasladar productos adquiridos al proyecto



SAM- Gestión de Terceros/Contratistas en el Proceso de

Desarrollo de Software

SG1 Establecer acuerdos con los proveedores

SP 1.1 Determinar el tipo de adquisición

SP 1.2 Seleccionar proveedores

SP 1.3 Establecer acuerdos con los proveedores

SG2 Satisfacer acuerdos con los proveedores

SP 2.1 Ejecutar el acuerdo con el proveedor

SP 2.2 Monitorear los procesos del proveedor seleccionado

SP 2.3 Evaluar el trabajo del producto del proveedor

seleccionado

SP 2.4 Aceptar el producto adquirido

SP 2.5 Transición de productos



PPQA- Aseguramiento de estándares de calidad en el

software (Producto & Proceso)

El objetivo del proceso PPQA es proveer a los miembros

de la organización una información objetiva obtenida

de evaluaciones en las que se revisan las actividades

sobre los procesos y los productos de trabajo.

El área de proceso PPQA Involucra:

Evaluación objetiva de procesos realizados, productos de

trabajo y servicios, frente a los descripciones de trabajo,

estándares y procedimientos.

Identificación y documentación de no-conformidades.

Proporcionar retroalimentación al equipo (Staff) de proyectos

sobre los resultados de actividades de garantía y de calidad.

Aseguramiento del re-direccionamiento de las no-

conformidades.



PPQA

Puntos Clave de PPQA:

Garantizar la adherencia a los Procesos de CMMi en la

organización

Despliegue consistente

Retroalimentación Objetiva

Proveer una Mejora Continua en los procesos de la Organización



PPQA

PPQA/Plantillas

Reporte de no conformidad.doc

Plan de evaluacion.doc

Instructivo de evaluacion.doc

Informes de evaluacion.doc

Informe Final de evaluacion.doc

Informe de Tendencias de calidad.doc

Informe de no conformidades.doc

Informe de acciones correctivas.doc

Matriz de control de no conformidades.xls



MA- Definición de Métricas y Análisis de los Procesos de

Software

El propósito de la Medición y análisis (MA) es desarrollar y sustentar una

capacidad de medición que se utiliza para poder dar soporte a las

necesidades de información de la gerencia.

El área de proceso de Medición y análisis involucra:

Especificar los objetivos de medición y análisis de modo que estos estén

alineados con las necesidades de información y los objetivos identificados.

Especificar las medidas, las técnicas de análisis y los mecanismos para la

recogida de datos, almacenamiento de datos, informes y realimentación.

Implementar la recogida, almacenamiento, análisis e informes de los datos.

Proporcionar resultados objetivos que puedan utilizarse en la toma de

decisiones informadas y en la toma de acciones correctivas apropiadas.

La integración de las actividades de medición y análisis en los procesos del

proyecto da soporte a:

La planificación y estimación objetivas.

El seguimiento del rendimiento real frente a los planes y objetivos

establecidos.

La identificación y resolución de problemas relativos al proceso.

El suministro de una base para incorporar la medición en procesos adicionales

en el futuro.



MA- Definición de Métricas y Análisis de los Procesos de

Software

Resumen de Metas y prácticas específicas

SG 1 Alinear las actividades de medición y análisis.

SP 1.1 Establecer los objetivos de medición.

SP 1.2 Especificar las medidas.

SP 1.3 Especificar los procedimientos de recogida y de

almacenamiento de datos.

SP 1.4 Especificar los procedimientos de análisis.

SG 2 Proporcionar los resultados de la medición.

SP 2.1 Recoger los datos de la medición.

SP 2.2 Analizar los datos de la medición.

SP 2.3 Almacenar los datos y los resultados.

SP 2.4 Comunicar los resultados.



PI- Integración de producto de S/W

El propósito de Integración de producto (PI) es ensamblar el producto a

partir de sus componentes, asegurar que el producto, una vez integrado,

funciona correctamente, y entregar el producto.

Esta área de proceso trata la integración de los componentes de producto

dentro de componentes de producto más complejos o de productos

completos.

El alcance de esta área de proceso es lograr la integración del producto

completo a través de un ensamblaje progresivo de los componentes, en

una etapa o en etapas incrementales, de acuerdo a una secuencia y

procedimientos de integración definidos. En todas las áreas de proceso-,

donde usamos los términos de producto y componente de producto, su

significado previsto engloba también a los servicios y a sus componentes.

Un aspecto crítico de la integración de producto es la gestión de

interfaces internas y externas de los productos y de los componentes de

producto, para asegurar la compatibilidad entre las interfaces. Se debe

poner atención a la gestión de la interfaz a lo largo de todo el proyecto.

La integración de producto es más que un ensamblaje de una vez de

componentes de producto a la finalización del diseño y la fabricación.



PI- Integración de producto de S/W


SG 1 Preparar para la integración de producto. SP 1.1 Determinar la secuencia de integración.

SP 1.2 Establecer el entorno de integración de producto.

SP 1.3 Establecer los procedimientos y los criterios de integración de producto.

SG 2 Asegurar la compatibilidad de la interfaz SP 2.1 Revisar la completitud de las descripciones de la interfaz.

SP 2.2 Gestionar las interfaces.

SG 3 Ensamblar los componentes de producto y entregar el producto.

SP 3.1 Confirmar la disponibilidad de los componentes de producto para su

integración.

SP 3.2 Ensamblar los componentes de producto.

SP 3.3 Evaluar los componentes de producto ensamblados.

SP 3.4 Empaquetar y entregar el producto o el componente de producto.




El objetivo del proceso VAL es demostrar que un

producto o componentes del producto cumplen su uso

planeado cuando es ubicado en su planeado ambiente.




La validación asegura que “se construye la cosa

correcta”.

La verificación asegura que “se construye correctamente”.

El área de proceso VAL Involucra:

Seleccionar los productos a validar.

Establecer el entorno de validación.

Establecer los procedimientos y los criterios de validación.

Preparar la Validación

Seleccionar los productos a validar

Validar el producto o los componentes del producto

Realizar la validación.

Analizar los resultados de la validación.



VAL- VALIDACION



VAL – VALIDACION SELECCIONAR LOS PRODUCTOS O COMPONENTES A VALIDAR

Se Listan los productos o entregables del proyecto desglosados en sus componentes, estableciendo prioridad y su nivel de impacto según las

necesidades del usuario.

Se evalúa los datos de la lista y se seleccionan los de mayor ponderado.

Establecer el alcance de la validación.

Seleccionar los métodos de validación.

ESTABLECER EL ENTORNO DE VALIDACION Se identifican los requerimientos de entorno de validación

Se identifican los productos suministrados por el cliente

Se identifican los elementos de reutilización.

Se identifican el equipamiento y las herramientas de prueba.

Se identifican los recursos de validación que están disponibles para reutilización y modificación.

Se planifica en detalle la disponibilidad de los recursos.

ESTABLECER LOS PROCEDIMIENTOS Y LOS CRITERIOS DE VALIDACIÓN Se revisan los requerimientos del producto y se resuelven los problemas que afectan la validación.

Se documenta el entorno, escenario operacional, procedimientos, entradas, salidas y criterios para la validación

Se evalúa el diseño a medida que madura el entorno de validación, para identificar problemas de validación.

REALIZAR LA VALIDACION Asigna Grupo Tester

Capacita Grupo Tester

Realiza la Validación

Documenta los resultados

Revisa y registra los informes de Validación.

ANALIZAR LOS RESULTADOS DE LA VALIDACION Se comparan los resultados reales con los resultados esperados.

Identificar los productos/componentes que no funcionan adecuadamente en sus entornos operacionales previstos.

Analizar los datos de la validación en cuanto a defectos.

Registrar los resultados de análisis e identificar los problemas.

Usar los resultados de la validación para comparar las mediciones y el rendimiento reales para el uso previsto



VER- Verificación

El propósito de la Verificación (VER) es asegurar que los

productos de trabajo seleccionados cumplen sus

requerimientos especificados.

VER involucra la verificación del producto o servicios y

artefactos intermedios con respecto a los

requerimientos seleccionados, incluyendo

requerimientos del cliente, del producto o servicio y

componentes del producto o servicio.

VER es un proceso incremental porque se aplica al

desarrollo del producto y artefactos, comenzando con

la verificación de los requerimientos, pasando por la

verificación de artefactos y terminando con la

verificación del producto completo.



VER- Verificación

El área de proceso de Verificación implica: preparación

de la verificación, realización de la verificación e

identificación de acciones correctivas.

La verificación incluye la verificación del producto y de

los productos de trabajo intermedios frente a todos los

requerimientos seleccionados, incluyendo

requerimientos del cliente, del producto y del

componente de producto. En todas las áreas de

proceso, donde se usan los términos producto y

componente de producto, su significado previsto

engloba también a los servicios y a sus componentes.



VER- Verificación (Proceso)


SG 1 Preparar la verificación. SP 1.1 Seleccionar los productos de trabajo a verificar.

SP 1.2 Establecer el entorno de verificación.

SP 1.3 Establecer los procedimientos y los criterios de verificación.

SG 2 Realizar revisiones entre pares. SP 2.1 Preparar las revisiones entre pares.

SP 2.2 Llevar a cabo las revisiones entre pares.

SP 2.3 Analizar los datos de la revisión entre pares.

SG 3 Verificar los productos de trabajo seleccionados. SP 3.1 Realizar la verificación.

SP 3.2 Analizar los resultados de la verificación.




El propósito de Formación organizativa (OT) es desarrollar las

habilidades y el conocimiento de las personas para que puedan

realizar sus roles eficaz y eficientemente.

Formación organizativa incluye la formación para dar soporte a los

objetivos del negocio de la organización y para cumplir las necesidades

tácticas de formación comunes a los proyectos y grupos de soporte.

Las necesidades específicas de formación identificadas por proyectos y

grupos de soporte individuales se tratan a nivel de proyecto y de grupo de

soporte, y están fuera del alcance de Formación organizativa. Los

proyectos y grupos de soporte son responsables de identificar y de tratar

sus necesidades específicas de formación.

Un programa de formación organizativa implica: Identificar las necesidades de formación de la organización.

Obtener y proporcionar formación para tratar esas necesidades.

Establecer y mantener la capacidad de formación.

Establecer y mantener los registros de formación.

Evaluar la eficacia de la formación.





SG 1 Establecer una capacidad de formación

organizativa. SP 1.1 Establecer las necesidades de formación estratégicas.

SP 1.2 Determinar qué necesidades de formación son

responsabilidad de la organización.

SP 1.3 Establecer un plan táctico de formación organizativa.

SP 1.4 Establecer la capacidad de formación.

SG 2 Proporcionar la formación necesaria. SP 2.1 Impartir la formación.

SP 2.2 Establecer los registros de formación.

SP 2.3 Evaluar la eficacia de la formación.



IPM- Gestión integrada de proyecto

El propósito de la Gestión integrada de proyecto (IPM) es establecer y

gestionar el proyecto y la involucración de las partes interesadas

relevantes de acuerdo a un proceso integrado y definido que se adapta

a partir del conjunto de procesos estándar de la organización.

Para IPPD, la Gestión integrada de proyecto + IPPD también cubre el

establecimiento de una visión compartida para el proyecto y el

establecimiento de equipos integrados que llevarán a cabo los objetivos

del proyecto.

La Gestión integrada de proyecto implica: Establecer el proceso definido del proyecto al inicio del mismo, mediante la adaptación del conjunto de procesos

estándar de la organización.

Gestionar el proyecto utilizando el proceso definido del proyecto.

Establecer el entorno de trabajo para el proyecto, basándose en los estándares del entorno de trabajo de la

organización.

Utilizar y contribuir a los activos de proceso de la organización.

Permitir que las inquietudes de las partes interesadas relevantes sean identificadas, consideradas, y, cuando sea

apropiado, tratadas durante el desarrollo del producto.

Asegurar que las partes interesadas relevantes realizan sus tareas de una forma coordinada y oportuna (1) para tratar

los requerimientos del producto y de los componentes del producto, los planes, los objetivos, los problemas y los

riesgos; (2) para satisfacer sus compromisos; y (3) para identificar, seguir y resolver los problemas de coordinación.



IPM- Gestión integrada de proyecto


SG1 Utilizar el proceso definido del proyecto. SP 1.1 Establecer el proceso definido del proyecto.

SP 1.2 Utilizar los activos de proceso de la organización para planificar las actividades del proyecto.

SP 1.3 Establecer el entorno de trabajo del proyecto.

SP 1.4 Integrar los planes.

SP 1.5 Gestionar el proyecto utilizando los planes integrados.

SP 1.6 Contribuir a los activos de proceso de la organización.

SG 2 Coordinar y colaborar con las partes interesadas relevantes. SP 2.1 Gestionar la involucración de las partes interesadas.

SP 2.2 Gestionar las dependencias.

SP 2.3 Resolver los problemas de coordinación.

SG 3 Aplicar los principios de IPPD. SP 3.1 Establecer la visión compartida del proyecto.

SP 3.2 Establecer la estructura del equipo integrado.

SP 3.3 Asignar los requerimientos a los equipos integrados.

SP 3.4 Establecer los equipos integrados.

SP 3.5 Asegurar la colaboración entre los equipos interconectados.




El propósito de la Gestión de riesgos (RSKM) es identificar los problemas

potenciales antes de que ocurran para que las actividades de tratamiento de

riesgos puedan planificarse e invocarse según sea necesario a lo largo de la vida

del producto o del proyecto para mitigar los impactos adversos para alcanzar los

objetivos.

La gestión de riesgos es un proceso continuo, orientado a evaluar el futuro, y una parte

importante de la gestión. La gestión de riesgos debería tratar los aspectos que podrían poner en

peligro el logro de los objetivos críticos. Una aproximación de gestión de riesgos continua se

aplica para anticipar y mitigar eficazmente los riesgos que puedan tener un impacto crítico

sobre el proyecto.

La gestión de riesgos eficaz incluye la identificación temprana y agresiva de cada riesgo a

través de la colaboración y la involucración de las partes interesadas relevantes, tal y como se

describió en el plan para la involucración de las partes interesadas tratado en el área de

proceso de Planificación de proyecto. Es necesario un fuerte liderazgo entre las partes

interesadas relevantes para establecer un entorno para la libre y abierta divulgación y discusión

de los riesgos.

La gestión de riesgos debe considerar fuentes tanto internas como externas para riesgos de

coste, de calendario y de rendimiento, así como de otros tipos. La detección temprana y

agresiva del riesgo es importante porque normalmente es más fácil, menos costoso y menos

perjudicial hacer los cambios y corregir los esfuerzos de trabajo durante las fases más

tempranas del proyecto, en lugar de en fases posteriores.

La gestión de riesgos puede dividirse en tres partes: definir una estrategia de gestión de

riesgos, identificar y analizar los riesgos, y manejar los riesgos identificados, incluyendo la

implementación de los planes de mitigación de riesgo, cuando sea necesario.





SG 1 Preparar la gestión de riesgos.

SP 1.1 Determinar las fuentes y las categorías de los riesgos.

SP 1.2 Definir los parámetros de los riesgos.

SP 1.3 Establecer una estrategia de gestión de riesgos.

SG 2 Identificar y analizar los riesgos.

SP 2.1 Identificar riesgos.

SP 2.2 Evaluar, categorizar y priorizar los riesgos.

SG 3 Mitigar los riesgos.

SP 3.1 Desarrollar los planes de mitigación de riesgo.

SP 3.2 Implementar los planes de mitigación de riesgo.



QPM- Gerencia cuantitativa de proyectos

El propósito de la Gestión cuantitativa de proyecto (QPM) es gestionar

cuantitativamente el proceso definido del proyecto para alcanzar los

objetivos establecidos de calidad y de rendimiento del proceso del

proyecto.

El área de proceso de Gestión cuantitativa de proyecto implica:

Establecer y mantener los objetivos de calidad y de rendimiento del proceso en el proyecto.

Identificar los subprocesos adecuados que constituyen el proceso definido del proyecto en base a los

datos históricos de estabilidad y de capacidad encontrados en las líneas base o los modelos del

rendimiento del proceso.

Seleccionar los subprocesos del proceso definido del proyecto a ser gestionados estadísticamente.

Monitorizar el proyecto para determinar si los objetivos de calidad y de rendimiento del proceso en el

proyecto están siendo satisfechos, e identificar la acción correctiva apropiada.

Seleccionar las medidas y las técnicas analíticas a usarse en la gestión estadística de los subprocesos

seleccionados.

Establecer y mantener una comprensión de la variación de los subprocesos seleccionados usando las

medidas y las técnicas analíticas seleccionadas.

Monitorizar el rendimiento de los subprocesos seleccionados para determinar si son capaces de

satisfacer sus objetivos de calidad y de rendimiento del proceso, e identificar la acción correctiva.

Registrar los datos de gestión estadística y de calidad en el repositorio de medición de la

organización.



QPM- Gerencia cuantitativa de proyectos


SG 1 Gestionar cuantitativamente el proyecto.

SP 1.1 Establecer los objetivos del proyecto.

SP 1.2 Componer el proceso definido.

SP 1.3 Seleccionar los subprocesos que serán gestionados

estadísticamente.

SP 1.4 Gestionar el rendimiento del proyecto.

SG 2 Gestionar estadísticamente el rendimiento del

subproceso.

SP 2.1 Seleccionar las medidas y las técnicas analíticas.

SP 2.2 Aplicar los métodos estadísticos para comprender la variación.

SP 2.3 Monitorizar el rendimiento de los subprocesos seleccionados.

SP 2.4 Registrar los datos de gestión estadística.



OPP- Gestión del desempeño de los procesos de la

organización

El propósito del Rendimiento de procesos de la organización (OPP) es establecer y mantener

una comprensión cuantitativa del rendimiento del conjunto de procesos estándar de la

organización en apoyo de los objetivos de calidad y de rendimiento de procesos, y

proporcionar datos, líneas base y modelos de rendimiento de los procesos para gestionar

cuantitativamente los proyectos de la organización.

El rendimiento de los procesos es una medida de los resultados reales logrados mediante el

seguimiento de un proceso. El rendimiento de los procesos se caracteriza mediante medidas

del proceso (p. ej., esfuerzo, tiempo de ciclo y eficacia de la eliminación de defectos) y

medidas del producto (p. ej., fiabilidad, densidad de defectos, capacidad, tiempo de

respuesta y costes).

Cuando la organización tiene medidas, datos y técnicas analíticas relacionadas a las

características críticas del proceso, del producto y del servicio, es capaz de hacer lo

siguiente:

Determinar si los procesos se comportan consistentemente o tienen tendencias estables (es decir, son

predecibles).

Identificar los procesos donde el rendimiento está dentro de los límites naturales que son consistentes en

todos los equipos que están implementando el proceso.

Establecer los criterios para identificar si un proceso o subproceso debería gestionarse estadísticamente, y

determinar las medidas y las técnicas analíticas pertinentes que deben utilizarse en dicha gestión.

Identificar los procesos que muestran un comportamiento inusual (p. ej., esporádico o impredecible).

Identificar cualquier aspecto de los procesos que pueda mejorarse en el conjunto de procesos estándar de la

organización.

Identificar la implementación de un proceso que se ejecuta de la mejor manera



OPP- Gestión del desempeño de los procesos de la

organización


SG 1. Establecer las líneas base y los modelos de

rendimiento.

SP 1.1 Seleccionar los procesos.

SP 1.2 Establecer las medidas de rendimientos del

proceso.

SP 1.3 Establecer los objetivos de calidad y de

rendimiento de procesos.

SP 1.4 Establecer las líneas base de rendimiento del

proceso.

SP 1.5 Establecer los modelos de rendimiento de

procesos.



EL PROCESO DE VALORACION CMMi

La Acreditación de cumplimiento con las

prácticas del modelo se efectúa a través

de una guía llamada SCAMPI (Standard

CMMI Appraisal Method for Process

Improvement)

Las Valoraciones (Assessment / Appraisal)

Para cada área de proceso tiene una guía de

auditoría que persigue evaluar el

cumplimiento de las exigencias del modelo



DEFINICIÓN DE ASSESSMENT

El acto de juzgar o evaluar (valorar) una persona, situación o evento.

Es un instrumento de alta especificidad técnica para la evaluación de potencial de las personas.

Permite obtener información objetiva acerca de cómo se actuaría en diferentes circunstancias y tareas.



ASSESSMENT - CMM

En el contexto que abarca el estándar de Capability Maturity Model (CMM), se entiende por assessment como una medida coordinada y objetiva de las fortalezas y debilidades encontradas en el programa de mejora de procesos de software.



VARIANTES DE SCAMPI

SCAMPI ofrece

una gran

flexibilidad de uso

a través de sus

tres variantes:

clases A, B y C.



CMMI DEV v1.3

PRIMERA VERSIÓN 93 CMM 2002 CMMi 2006 1.2 2010 1.3

CAMBIOS LIGEROS DE CMMi DEV 1.3

PROYECCIÓN DE CAMBIOS AL MÉTODO DE EVALUACIÓN SCAMPI

CAMBIOS DE ENFOQUE Y ESPECIALIZACIÓN EN CONSTELACIÓN

(DESARROLLO, ADQUISICIÓN, SERVICIOS)

HOMOGENEIZAR Y MEJORAR CONTEXTO DE PRACTICAS Y

TERMINOLOGÍAS

LOS PRINCIPALES CAMBIOS ESTÁN EN LOS NIVELES 4 y 5, LAS MAS

CUESTIONADAS POR EL SEI

ALTA MADUREZ QUE INCORPOREN SIX SIGMA Y OTRAS PRACTICAS

PARA NIVELES 4 Y 5, CONTROL ESTADÍSTICO

REDUCIR GENERALIDADES DE LAS PRACTICAS GENÉRICAS (MAS

LIBERTAD Y MAS AMBIGÜEDAD)

MEJORAR EFICIENCIA EVALUACIONES SCAMPI, MAS VALOR Y

CONSISTENCIA



CMMi v1.3

DAR COBERTURA A TEMAS DE SEGURIDAD

REDUCIR EL TAMAÑO DEL LIBRO

NO AFECTAR LOS PROYECTOS EN MARCHA

INNOVACIÓN & DESPLIEGUE ORGANIZACIÓN PASA A

MEJORA DE DESEMPEÑO

CORTA DE RAÍZ NIVELES DE CAPACIDAD EN 4 Y 5

LOS TRES MODELOS COMPARTEN 16 ÁREAS Y ESTOS SE

CONSERVAN (NÚCLEO)

ALGUNAS COINCIDENCIAS CON METODOLOGÍAS AGILES

(CM, PI, RD, RSK, TS, VER)

VARIOS EQUIPOS: ARQUITECTURA, DESARROLLO,

VALIDACIÓN



UN CAMINO DE

ADOPCIÓN DEL

MODELO DE CMMi

1.3



HABRA ALGUN PROCESO DE LA ING. SOFTWARE QUE

MEJORAR?

INFORMATICA & SISTEMAS

EL ENFOQUE DE LAS APLICACIONES ES ESTRATEGICO PARA LA EMPRESA

ESTA LA TECNOLOGIA INFORMATICA AUTOMATIZANDO EL ESFUERZO Y EL CONOCIMIENTO DE LOS PROCESOS

DE LA EMPRESA.

POSEEMOS INFORMACION UTIL PARA TOMAR DECISIONES ACERTADAS O SOLO DATOS CON LOS CUALES

EXPERIMENTAR

TENEMOS USUARIOS DE T.I. O CLIENTES DE T.I (NIVEL DE SATISFACCION)

QUE TAN MADURA ESTA NUESTRA ORGANIZACION EN TECNOLOGIA INFORMATICA

COMO ESTAN LOS TIEMPOS DE RESPUESTA DE SOLUCIONES INFORMATICAS A LAS NECESIDADES CAMBIANTES

DEL NEGOCIO

TENEMOS UNA TRAYECTORIA EXITOSA DE PROYECTOS DE SOFTWARE

ESTAMOS CAPITALIZANDO EL POTENCIAL DE LA TERCERIZACION (SaaS, IaaS, PaaS, Cloud, Offshore)

ESTAMOS APROVECHANDO LA POTENCIALIDAD DE LA ARQUITECTURA WEB 2.0 (INTERNET/INTRANET/J2EE,

REDES SOCIALES, COLABORACION, SOA, BPM, BI, LDAP/SSO)

PROGRAMAMOS APLICACIONES O DISEÑAMOS E IMPLEMENTAMOS SOLUCIONES

LA TECNOLOGIA INFORMATICA ES UNA VENTAJA COMPETITIVA PARA EL NEGOCIO O ES PARTE DE LA BASE

OPERATIVA

CUAL HA SIDO EL RETORNO DE LA INVERSION EN TECNOLOGIA INFORMATICA Y CUAL SU TIEMPO DE VIDA

UTIL/RECUPERACION



GENERALIDADES DE LOS PROYECTOS

DE MEJORA INSTITUCIONAL

DIMENSIONANDO EL CAMBIO DE

ESCENARIOS Y EL CAMINO DE

TRANSICION

SITUACION ACTUAL

SITUACION DESEABLE Y

VIABLE



QUE DEBE CONTENER COMO MINIMO UNA ESTRATEGIA DE

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

Una Determinación Corporativa

Crear un área que lidere y coordine el proceso de aseguramiento de la calidad del

software

Una Preparación del Personal que pertenece a los procesos de desarrollo de

software en el contexto del aseguramiento de la calidad del software para que

adquiera “el sentido de urgencia” del cambio.

Una puesta en común de la necesidad de Enfocar los esfuerzos en asegurar la

calidad del software CON UN PROPÓSITO organizacional

Enfocarse en procesos (Identificarlos y bosquejarlos)

Contemplar la alternativa de “Valorar/Certificar los Procesos” por un ente avalado

internacionalmente.

Tener un marco de referencia para cada proceso (Mejor Practica)

Efectuar un diagnostico de las debilidades, fortalezas y el impacto que esta

teniendo en la organización cada uno de los actuales procesos según la óptica del

Modelo de Referencia seleccionado

Priorizar los procesos que se van a mejorar y definir metas de logro



QUE DEBE CONTENER COMO MINIMO UNA ESTRATEGIA DE

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

Identificar las herramientas de apoyo tecnológico que “disciplinen” los

procesos (Requerimientos, Control Cambios, Automatización de Pruebas,

Documentación, Gestion de Proyectos, Estimación de Esfuerzos)

Ajustar las agendas del personal para que simultáneamente con su

actividad diaria avance en el mejoramiento de los procesos

Establecer un plan integrado de mejora

Iniciar la ejecución del plan y asignar los recursos que ello demanda

Efectuar el seguimiento al plan hasta garantizar el logro de los planeado

Evaluar objetivamente los logros y retroalimentar el plan

Efectuar una auditoria externa que certifique los logros

Formular la siguiente Iteración del proceso de mejora



PLAN DE IMPLEMENTACION

PREPARATIVOS &

SENSIBILIZACIÓN

VALORACIÓN &

ANALISIS DE

BRECHAS

REDISEÑO DE

PROCESOS &

ROLES

DESPLIEGUE &

GESTIÓN DEL

CAMBIO

IMPLEMENTACIÓN

NUEVOS

PROCESOS

MONITOREO Y

EVALUACIÓN DE

CUMPLIMIENTO

Procesos

Tecnologías

Competencias

VALORACIÓN MEJORA

CONTINUA


COMENTARIOS E INQUIETUDES ?


OBJETIVO DE LA CONFERENCIA

Mostrar un modelo de gobernabilidad

para la Arquitectura Empresarial

(Enterprise Architecture Governance

Model) que garantice que la AE se afiance

en una organización y logre cumplir su

propósito de construir solidez, desarrollo

sostenible, competitividad, control y

productividad



La ingeniería de software se ejerce por medio de procesos que se

desarrollan a través de todo el ciclo de vida del software, desde

que se concibe la iniciativa o proyecto hasta que el

producto/solución se estabiliza en el ambiente de producción.



En Colombia y en el mundo aún se sigue desarrollando

el software de una manera casi artesanal que no le da

la importancia a los modelos de procesos que

desarrollan el ciclo de vida del software y por ello

vemos que el gran potencial de las tecnologías de

información no se ha podido canalizar en beneficios de

productividad y competitividad que tanto demandan las

organizaciones del mundo de los negocios. Las prácticas

tradicionales de ingeniería de software manejan altos

niveles de desperdicio, representados en reprocesos

que además de generar sobrecostos deterioran las

condiciones de los proyectos de software generando

insatisfacción y pérdida de credibilidad en las partes

interesadas en los proyectos que habilita el software.



Varias instituciones (SEI, ISO, IEEE y otras) han venido

aportando desde hace más de 20 años modelos que

orientan los procesos de la ingeniería de software y

cuando nos damos a la tarea de conocer esos modelos

encontramos que el problema del desperdicio en la

ingeniería de software no es por falta de definiciones,

estándares, conocimiento o fuentes de información

pues en estos modelos hay muchas recomendaciones

sobre cómo abordar con éxito el ciclo de vida de

software, el problema está en la indisciplina que reina

en las prácticas de desarrollo de soluciones de

ingeniería de software.



Es responsabilidad de nuestra asociación

enfatizar en la importancia de madurar

nuestras prácticas/procesos de ingeniería

de software para que como gremio nos

posicionemos mejor nacional e

internacionalmente en un mercado donde

los profesionales y firmas de servicios de

Ingeniería de software de otras naciones

ya lo han hecho exitosamente (India,

China, USA).



El modelo CMMi propuesto por el Instituto de Ingeniería de

software (SEI) es uno de los más completos para dar un marco de

referencial sobre el deber ser de los procesos de software. Y en

Noviembre de 2010 publicó la versión 1.3 del modelo para

desarrollo de software en el cual de una manera muy consistente

presenta como manejar las principales fases del ciclo de vida de la

ingeniería, los proyectos de software, las actividades de soporte y

como preparar a la organización de software para desarrollar los

procesos de negocio.


Procesos ingeniería software Cmmi 1.3 mario-monsalve-2011-06-02

Business

Transcript of Procesos ingeniería software Cmmi 1.3 mario-monsalve-2011-06-02