Embed Size (px)
Citation preview
MODULO IMODULO I
Ingeniería de SoftwareINF - 163
1.2 EL PROCESO
Resumen preparado por Miguel Cotaña20/08/091
La construcción del software deordenador es un proceso iterativode aprendizaje y el resultado esuna materialización deluna materialización delconocimiento recolectado,depurado y organizado conformeel proceso estuvo en ejecución
2
Tres aspectos del procesoTres aspectos del proceso
1.- Definición del procesoUn proceso debe estar definido (documento queespecifica actividades y procedimientos delproceso)
2.- Aprendizaje del proceso2.- Aprendizaje del procesoEl conocimiento del proceso debe sertransferido a las personas (agentes) que loejecutarán
3.- Resultados del procesoManifestación de los productos, como resultadode la ejecución de las actividades definidas porel proceso
3
NecesidadesEspecificación de
Diseño Codigo
Ciclos de vidaProceso
Sistema Software
ObtenerRequisitos
NecesidadesRequisitos
Diseño Codigo
DiseñarSistema
Codificar Probar
Sistema Software
4
Proceso internalizado y proceso institucionalizadoProceso internalizado y proceso institucionalizado
Cuando un proceso es desarrolladoprofesional y naturalmente por unapersona, se dice que el proceso esta“internalizado” por la persona.
En las organizaciones los procesosson comunes a grupos de personas.Para obtener disciplina en los procesos,estos deben ser establecidos como“institucionalizados” en laorganización.
5
Completitud y disciplina en los procesosCompletitud y disciplina en los procesos
Un proceso es incompleto si:a) El documento de definición existepero no todos saben de su existencia;b) El documento de definición existe,pero no hay capacitación en el proceso.pero no hay capacitación en el proceso.Se deja a iniciativa del equipo aprenderel proceso;c) El documento de definición existe,existe capacitación, pero no haymonitoreo y el proceso NO es forzado asu cumplimiento. Algunos lo siguen yotros no.
6
Un proceso es disciplinado solo si secumplen las siguientes condiciones:a) El proceso esta debidamentedocumentado;b) Existe y se realiza capacitación formalb) Existe y se realiza capacitación formalsobre el proceso;c) Las personas siguen lo establecidopor el proceso como una manera naturalde desempeñar sus actividades;d) El proceso es monitoreado y sucumplimiento es obligatorio.
7
Ingenieria del softwareIngenieria del software
[Ingeniería de software es] elestablecimiento y uso de principiosde ingeniería adecuados para obtener
teoria practica
DefinicionDefinicion
de ingeniería adecuados para obtenereconómicamente software que seaconfiable y trabaje eficientemente enmáquinas reales (Fritz Bauer)
Resolucion
de
problemas
Administracion
y gestion
Pruebas y
control de
calidad
8
Ingenieria del software: tecnologia estratificadaIngenieria del software: tecnologia estratificada
Definicion segun el IEEEDefinicion segun el IEEE
La ingenieria de software es laaplicación de un enfoque sistemático,disciplinado y cuantificable aldisciplinado y cuantificable aldesarrollo, operación y mantenimientodel software; es decir, la aplicación dela ingeniería al software
9
El enfoque de calidad, soporta a los estratos de la I.S.El enfoque de calidad, soporta a los estratos de la I.S.
Software EngineeringIngeniería de Software
herramientasherramientas
enfoque de “calidad”enfoque de “calidad”
modelo de procesomodelo de proceso
métodosmétodos
10
La base de la I.S. es elestrato del proceso. Elproceso es el elemento que
Modelo de procesoModelo de proceso
proceso es el elemento quemantiene juntos los estratosde la tecnologia y que permiteel desarrollo racional y atiempo del software.
11
El proceso del software forma labase para el control de la gestiónde los proyectos de software yestablece el contexto en el cualse aplican los métodos técnicos,se aplican los métodos técnicos,se generan los productos deltrabajo (modelos, documentos,datos, reportes, formatos), seestablecen los fundamentos, seasegura la calidad, y el cambio semaneja de manera apropiada.
12
Los métodos de la I.S., proporcionan los“cómo” técnicos para construir software.Abarcan un amplio espectro de tareas queincluyen la:� Comunicación,� El análisis de requisitos,
MétodosMétodos
� El análisis de requisitos,� El modelado del diseño,� La construccion del programa,� La realizacion de pruebas,� El soporte
Los métodos se basan en un conjunto deprincipios básicos que gobierna cada área dela tecnologia.
13
Las herramientas de la I.S., proporcionanel soporte automatizado osemiautomatizado para el proceso y losmétodos.
Cuando las herramientas se integran de
HerramientasHerramientas
Cuando las herramientas se integran deforma que la información que cree una deellas pueda usarla otra, se dice que se haestablecido un sistema para el soporte deldesarrollo del software, que confrecuencia se denomina “ingeniería delsoftware asistida por ordenador”
14
MARCO DE TRABAJO PARA EL PROCESOMARCO DE TRABAJO PARA EL PROCESO
Un marco de trabajo establece la base
para un proceso de software completo al
identificar un numero pequeño de
actividades del marco de trabajo
aplicables a todos los proyectos deaplicables a todos los proyectos de
software, sin importar su tamaño y
complejidad.
Abarca un conjunto de actividades
sombrilla aplicables a lo largo del
proceso del software.15
Cada actividad dentro del marco de
trabajo contiene un conjunto de
acciones de ingeniería del software; es
decir, una serie de tareas relacionadas
que produce un producto del trabajo enque produce un producto del trabajo en
la I.S. (por ejemplo, el diseño es una
acción de la I.S.).
Cada acción la forman tareas de trabajo
individuales que completan alguna parte
del trabajo implicado por la acción.16
Marco de trabajo del proceso de softwareMarco de trabajo del proceso de software
Actividades sombrilla
Marco de trabajo del proceso
Actividad del marco de trabajo #1
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Accion de la ingenieria de software # 1.k
Accion de la ingenieria de software # 1.1
Conjunto
de tareas
.
Conjunto
de tareasPuntos de aseguramiento
Fundamentos del proyecto.
.
Actividad del marco de trabajo #n
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Accion de la ingenieria de software # n.m
Accion de la ingenieria de software # n.1
Conjunto
de tareas
.
Conjunto
de tareas
.
.
17
Aplicacion del marco de trabajo en proyectosAplicacion del marco de trabajo en proyectos
Comunicación. Esta actividad del marco detrabajo implica una intensa colaboración ycomunicación con los clientes; además, abarca lainvestigación de requisitos y otras actividadesrelacionadas.Planeación. Esta actividad establece un planPlaneación. Esta actividad establece un planpara el trabajo de la ingeniería del software.Describe las tareas técnicas que deben realizarse,los riesgos probables, los recursos que seránrequeridos, los productos del trabajo que han deproducirse y un programa de trabajo.Modelado. Abarca la creación de modelos quepermiten al desarrollador y al cliente entendermejor los requisitos del software y el diseño quelogrará satisfacerlos.
18
Construcción. Esta actividad combina lageneración del codigo (ya sea manual oautomatizado) y la realización de pruebasnecesarias para descubrir errores en elcódigo.código.
Despliegue. El software (como una entidadcompleta o un incremento completado demanera parcial) se entrega al cliente, quiénevalua el producto recibido y proporcionainformación basada en su evaluación.
19
Recopilacion de requisitosRecopilacion de requisitos
Ocurre durante la actividad de comunicación, y
puede ser:
Hacer una lista de los clientes para el proyecto;
Invitar a todos los clientes a una reunión informal;Invitar a todos los clientes a una reunión informal;
Pedir a cada cliente que haga una lista de
características y funciones requeridas;
Establecer un debate sobre los requisitos y elaborar
una lista final;
Priorizar los requisitos;
Advertir las áreas de incertidumbre.
20
Recopilacion de requisitos para proyecto complejoRecopilacion de requisitos para proyecto complejo
Hacer una lista de los clientes para el proyecto;
Entrevistar a c/u de los clientes, por separado, para
determinar de manera general sus deseos y necesidades;
Elaborar una lista preliminar de las funciones y
características basadas en la información que ofrezcan los
clientes;clientes;
Hacer un programa de reuniones para recopilar los
requisitos;
Conducir las reuniones;
Producir escenarios informales de los usuarios como
parte de cada reunión;
21
Refinar escenarios de los usuarios con base en el
intercambio de información con los clientes;
Elaborar una lista revisada de los requisitos de los
clientes;
Utilizar técnicas de despliegue de funciones de calidad
para jerarquizar los requisitos;para jerarquizar los requisitos;
Empaquetar los requisitos para que puedan entregarse
de manera incremental;
Observar las restricciones que serán puestas en el
sistema;
Debatir métodos para validar el sistema.
22
Actividades sombrillaActividades sombrilla
Seguimiento y control del proyecto desoftware: permite que el equipo de softwareevalue el progreso comparandolo con el plan delproyecto y así tomar las acciones necesarias paramantener el programa;Gestión de riesgos: evalua los riesgos queGestión de riesgos: evalua los riesgos quepudiera afectar los resultados del proyecto o lacalidad del producto;Aseguramiento de la calidad del software:define y conduce las actividades requeridas paraasegurar la calidad del software;Revisiones técnicas formales: evalua losproductos del trabajo de la I.S., en un esfuerzoencaminado a descubrir y eliminar los erroresantes de que éstos se propaguen;
23
Medición: define y recolecta mediciones delproceso, el proyecto y el producto para ayudar alequipo a entregar software que satisfaga lasnecesidades del cliente;Gestión de la configuración del software:maneja los efectos del cambio a través delmaneja los efectos del cambio a través delproceso del software;Gestión de la reutilización: define los criteriospara la reutilización de productos del trabajo (seincluyen componentes del software) y establecemecanismos para la creación de componentesreutilizables;Preparación y producción: abarca lasactividades requeridas para crear productos deltrabajo como modelos, documentos, registros.
24
INTEGRACION DEL MODELO DE CAPACIDAD DE MADUREZINTEGRACION DEL MODELO DE CAPACIDAD DE MADUREZ
El instituto de Ingeniería del Software (SEI)
ha desarrollado un modelo completo de un
amplio proceso basado en un conjunto de
capacidades de software y de sistemas que
deben estar presentes conforme lasdeben estar presentes conforme las
organizaciones alcanzan diferentes grados
de capacidad y madurez del proceso. Una
organización debe crear un modelo de
proceso que se ajuste a las directrices
establecidas por la integración del modelo
de capacidad de madurez (IMCM)
25
El modelo IMCM (integración del modelo de
capacidad de madurez), es el modelo más
utilizado en la industria del software.
“Mide la capacidad del “Mide la capacidad del
proceso para desarrollar
software con calidad”ad.(predictibilidad en costos, duración, y niveles de calidad previstos)
26
La IMCM representa un modelo completo de
proceso en dos formas diferentes:
1.- Como un modelo continuo
2.- Como un modelo discreto PP Planeación del proyecto
5
4
3
2
1
0PP GR MA GC ACPP otros
GR Gestión de requisitos
MA Medición y análisis
GC Gestión de configuración
ACPP Aseguramiento de la calidad del producto y el proceso
27
Clasificación de acuerdo con niveles de capacidadClasificación de acuerdo con niveles de capacidad
Gestionado
Mejorado
Los procesos están estabilizados y existe una gesti ón cuántitativa. El área de proceso se controla y mejo ra mediante mediciones y evaluacion cuantitativa.
La mejora de procesos es una actividad consistente y establecida en la organización. Se adapta y mejora mediante el uso de medios cuantitativos (estadísticos)
Nivel Características
Realizado
Administrado
Definido
Todas las metas específicas del área del proceso ha n sido satisfechas. Las tareas de trabajo requeridas han s ido realizadas
Todos los criterios del nivel han sido satisfechos. Todas las tareas de trabajo y productos estan monitoreados, controla dos y revisados y son evaluados.
Procesos organizativos, tanto técnicos como de gest ión, están claramente definidos.
incompletoEl área de proceso aún no se realiza o todavia no a lcanza todas las metas y objetivos definidos para el nivel 1 de capacidad
28
La IMCM define cada área del proceso en
función de “metas especificas” (ME)y de
las “prácticas especificas” (PE)
requeridas para alcanzar dichas metas.
Las ME establecen las características queLas ME establecen las características que
deben existir para que las actividades
implicadas por un área de proceso sean
efectivas.
Las PE convierten una meta en un conjunto
de actividades relacionadas con el proceso.
http://www.sei.cmu.edu/cmmi/
29
El modelo discreto de la IMCM define las
mismas áreas, metas y prácticas del
proceso que el modelo continuo. La
principal diferencia es que el modelo
discreto establece cinco niveles dediscreto establece cinco niveles de
madurez, en vez de cinco niveles de
capacidad.
Para lograr un nivel de madurez se deben
conseguir metas y prácticas especificas
relacionadas con un conjunto de áreas del
proceso.
30
Relacion entre niveles de madurez y las areas del procesoRelacion entre niveles de madurez y las areas del proceso
NIVEL ENFOQUE AREAS DEL PROCESO
De optimizacion
Mejora continuadel
Proceso
Innovacion organizacional y despliegueAnalisis causal y resolucion
Gestionadode modo
cuantitativo
Gestion Cuantitativa
Eejecucion del proceso organizacionalGestion cuantitativa del proyecto
definido EstandarizacionDel proceso
Desarrollo de requisitosSolucion tecnicaDel proceso Solucion tecnicaIntegracion del productoVerificacionValidacionEnfoque del proceso organizacionalCapacitacion organizacionalGestion de riesgos
Gestionado Gestionbasica delProyecto
Gestion de requisitosPlaneacion del proyectoMonitoreo y control del proyectoGestion de acuerdos del proveedorMedicion y analisisAseguramiento de calidad del producto y procesoGestion de la configuracion
Ejecutado31
PATRONES DEL PROCESOPATRONES DEL PROCESO
El proceso de software puede definirse como una
colección de patrones que definen un conjunto
de actividades, acciones, tareas de trabajo o
comportamientos relacionados que requiere el
desarrollo de un software para ordenador.desarrollo de un software para ordenador.
Un patrón de proceso ofrece una plantilla: un
método consistente para describir una
característica importante del proceso de
software. Mediante la combinación de patrones,
un equipo de software puede construir un
proceso que satisfaga las necesidades de un
proyecto.32
Los patrones pueden definirse en cualquier
grado de abstracción. En algunos casos se puede
utilizar un patrón para describir un proceso
completo (prototipo).completo (prototipo).
En otras situaciones se utilizan los patrones para
describir una actividad del marco de trabajo
importante (como la plantación) o una tarea
dentro de una actividad del marco de trabajo
(por ejemplo, la estimación de un proyecto)
33
Plantilla para describir un patron de procesoPlantilla para describir un patron de proceso
Nombre del patrón. Al patrón se leasigna un nombre significativo(comunicación con el cliente).Propósito. Se describe con brevedadel objetivo del patrón. Por ejemplo, elel objetivo del patrón. Por ejemplo, elobjetivo de la comunicación con elcliente es “establecer una relación decolaboración con el cliente” en unesfuerzo encaminado a definir elalcance del proyecto y requisitos delnegocio.
34
Tipo. Se especifica el tipo de patrón.(Ambler) sugiere tres tipos:
Los patrones de tarea definen una acción dela I.S., o una tarea de trabajo que es parte delproceso y relevante para una práctica exitosa dela I.S. (por ejemplo, la recopilación dela I.S. (por ejemplo, la recopilación derequisitos es un patrón de tarea.
Los patrones de escenario, incorpora multiplespatrones de tarea relevantes. Un ejemplo, es lacomunicación.
Los patrones de fase definen la secuencia deactividades del marco de trabajo. Un ejemplo,modelo en espiral o de construcción deprototipos.
35
Contexto inicial. Se describen lascondiciones en las cuales se aplica elpatrón.Problema. Se describe el problemaque debe resolver el patrón.que debe resolver el patrón.Solución. Se describe la implantaciondel patrón.Contexto reultante. Se describen lascondiciones que habra una vez que elpatrón haya sido implementado conéxito.
36
Patrones relacionados. Seproporciona una lista de todos lospatrones de proceso directamenterelacionados con este, en formarelacionados con este, en formajerárquica o de alguna otra forma.Usos conocidos/ejemplos. Seindican los ejemplos específicos en loscuales el patron es aplicable.
37
EVALUACION DEL PROCESOEVALUACION DEL PROCESO
La existencia de un proceso de software
no es garantía de que este será
entregado a tiempo, de que satisfará las
necesidades del cliente, o de que
mostrara las características técnicas que
conducirán a características de calidad a
largo plazo.
Los patrones de proceso deben ir
acompañados de una practica sólida de la
I.S.38
Relacion entre proceso y métodos aplicado para evaluaciónRelacion entre proceso y métodos aplicado para evaluación
Evaluacion del
Proceso del Sw
Identifica
modificaciones a
Identifica capacidades
y riesgos de
Es examinado por
Evaluacion del
Proceso de SW
Mejoramiento del
Proceso de Sw
Determinacion
de la capacidad
Conduce a Conduce a
motiva
39
MODELOS DE PROCESO PERSONALES Y EN EQUIPOMODELOS DE PROCESO PERSONALES Y EN EQUIPO
El mejor proceso de software es el que
esta cerca de la gente que realizará el
trabajo. Si un modelo de proceso de
software ha sido desarrollado en un
ámbito corporativo, puede ser efectivo
sólo si es en gran medida adaptable para
satisfacer las necesidades del equipo del
proyecto, que es el que en realidad lleva
a cabo el trabajo de I.S.
40
PROCESO DE SOFTWARE PERSONAL (PSP)PROCESO DE SOFTWARE PERSONAL (PSP)
El modelo PSP define 5 actividades del
marco de trabajo:
Planeación. Esta actividad selecciona
requisitos y, con base en estos, desarrolla
el tamaño y la estimación de recursos.el tamaño y la estimación de recursos.
Además, se estiman los defectos. Todas
las mediciones se registran en hojas de
trabajo o en plantillas.
Diseño de alto nivel. Se construyen
prototipos. Todos los elementos se
registran y rastrean.41
Revisión del diseño de alto nivel. Los
métodos formales de verificación se aplican a
errores descubiertos en el diseño. Las
mediciones se mantienen para todas las
tareas importantes.
Desarrollo. El diseño al nivel deDesarrollo. El diseño al nivel de
componente se refina y revisa. Se genera,
revisa, compila y prueba el código. Las
mediciones de mantienen.
Análisis de resultados. Mediante las
mediciones y medidas recolectadas se
determina la efectividad del proceso.42
PROCESO DE SOFTWARE EN EQUIPO (PSE)PROCESO DE SOFTWARE EN EQUIPO (PSE)
La meta del PSE es construir un equipo de
proyecto “autodirigido” que se organice
para producir software de alta calidad.
Humphrey define los siguientes objetivos:
Construir equipos autodirigidos queConstruir equipos autodirigidos que
planeen y tengan un seguimiento de su
trabajo, establezcan metas y posean sus
procesos y planes.
Mostrar a los jefes como preparar y
motivar a sus equipos y como ayudarlos a
sostener un alto desempeño.43
Acelerar el mejoramiento del proceso
de software al realizar, con el
comportamiento normal y esperado.
Ofrecer una guía de mejoramiento a
organizaciones de alta madurez.
Facilitar la enseñanza de habilidades de
equipo de calidad.
44
El PSE reconoce que los mejores equipos
de software son autodirigidos. Los
miembros del equipo plantean los
objetivos del proyecto, adaptan el
proceso para cubrir sus necesidades,
controlan el programa y la medición y el
análisis de las medidas recolectadas;
además, trabajan de manera continua
para mejorar el enfoque del equipo
respecto de la I.S.45
Un profesional del software creativo debe
sentir tanta satisfacción del proceso como
del producto terminado.
El trabajo que realiza la gente de software
Si el proceso es debil, el producto final sufrira las consecuenciasSi el proceso es debil, el producto final sufrira las consecuencias
El trabajo que realiza la gente de software
cambiará en los años que siguen. La
dualidad del producto y el proceso es un
elemento importante para mantener a la
gente creativa comprometida mientras
finaliza la transición desde la programación
hasta la Ingeniería de Software.46
