teoria de procesos

1Teora del Proceso

Toda organizacin puede representarse como una compleja red de elementos que realizan actividades que les permiten interrelacionarse unas con otras para alcanzar los fines (misin) del conjunto. Cada una de estas interrelaciones puede representarse y gestionarse como un proceso.

1

2Teora del Proceso

1.- Cuestiones bsicas del proceso2.- El proceso del software3.- El Ciclo de Vida (Modelos)4.- Elementos del Proceso5.- Establecimiento del Proceso6.- Modelos de Proceso7.- Aplicacin a un Plan de Proyecto

Teora del Proceso

2

33

1.Organizacin racional de personas, materiales, energa, equipos y procedimientos en actividades concebidas para producir un resultado final especfico.

Qu es un Proceso?

Mejora del Proceso

Teora del Proceso

Cuestiones bsicas del proceso

2.Conjunto de operaciones o actividades que se realizan sucesivamente, con el objeto de transformar una serie de entradas (insumos) especficas en salidas (resultados, productos o servicios) aadiendo valor.

3.Grupo de actividades que se desarrollan en una serie de etapas secuenciales y que buscan un fin, resultado especfico o un grupo coherente de resultados

Que es un Proceso?-Un proceso es un conjunto de prcticas ejecutadas para alcanzar un objetivo dado; puede incluir herramientas, mtodos, materiales, y/o personas.Existen varias definiciones de proceso, en lo que se refiere a la actividad de fabricacin de productos de software. Un proceso segn el SEI es:(Conjunto de actividades, mtodos, prcticas y transformaciones que la gente usa para desarrollar y mantener software y los productos de trabajo asociados (planes de proyecto, diseo de documentos, cdigo, pruebas y manuales de usuario) [SEI, 1995].Otras definiciones del proceso de software, se realizan en trminos muy similares como:Es todo el conjunto de actividades necesarias para transformar los requisitos del usuario en software (Humphrey-90).Propsito del proceso software:

Definir orden de actividades Definir criterios para la transicin entre actividades Comunicar procedimientos

Para un mejor entendimiento de que es un proceso de software, sirva como ejemplo las actividades que sera necesario realizar para adquirir un sistema CRM (Gestin de relaciones con los clientes)

Que va a resolver Que hay en el mercado Como funciona (Demo) Que se necesita Como se adquiere Como se implanta Como se forma a los responsables Como se mide su eficacia Como se actualiza Como se compromete al proveedor etc.,

44

Quin interviene en un proceso?

Habilidades,Formacin,

Motivacin yGestin

Herramientasy Tecnologa

Relaciones de todaslas tareas

AB

CD

Mejora del Proceso

Teora del Proceso


Quien interviene en un proceso?- Para que un proceso pueda tener lugar es necesario la intervencin de tres entidades, lo mismo ocurre con el conjunto de procesos que son necesarios para la concepcin desarrollo y funcionamiento de un sistema informtico.Personas.-Los implicados que de una u otra forma interactan con los sistemas informticos, en todas las fases de su existencia.

Los Usuarios/Cliente, que marcan sus preferencias y necesidades Los Directivos que definen las polticas y estrategias Los Gestores que definen y dirigen los planes de actuacin Los Tcnicos que asesoran, disean, desarrollan, implantan, forman y mantienen

los sistemasTodos ellos necesitan tienen y/o necesitan formacin en sus respectivas reas de responsabilidad, por tanto, deben tener aptitudes para dirigir equipos, compartir responsabilidades dentro de los equipos y saber plasmar sus conocimientos en los productos y servicios que componen los sistemas informticos.Herramientas.- Consideramos a aquellos elementos fsicos y lgicos, que son necesarios para la construccin de los sistemas informticos, sin ser exhaustivos, se mencionan:

Equipos, redes y la lgica de base necesaria para su inicializacin. Lenguajes y rutinas para la programacin. Aplicaciones de ayuda al desarrollo, control y seguimiento de procesos y

planificacin.Tareas.- La gua que nos indica los pasos y actuaciones que es necesario llevar a cabo desde que se detecta la necesidad de realizar un determinado proyecto informtico, hasta que es necesaria su sustitucin.

55

Mejora del Proceso

Teora del Proceso


Funcional-JerrquicaAparecen los procesos pero predominan las funciones

Proceso 1

Proceso 2

Proceso 3

Proceso 4

Los procesos orientan el negocio

Gestin por procesosLa gestin de las organizaciones est sometida a los cambios que de forma permanente se producen el mundo debido a la evolucin de las ideas, los comportamientos y las tecnologas. La mayor parte de los dirigentes de las organizaciones pblicas y privadas, consideran la gestin desde el punto de vista funcional (departamentos), por tanto tendern a dirigirlas tambin funcionalmente, considerando cada departamento como independiente de los dems. Los objetivos se establecern para cada funcin por separado. Las reuniones entre los distintos departamentos se limitarn a informar de cmo van las cosas.En esta situacin, los responsables de cada rea funcional tienden a considerar a las otras reas funcionales como adversarios, en lugar de verlas como miembros de un mismo equipo. Alrededor de los departamentos se levantan unas estructuras impermeables. Estas estructuras normalmente impiden que las cuestiones entre departamentos se puedan resolver entre empleados de igual rango de los niveles inferiores. Todo asunto que afecta a varias reas funcionales, como el establecimiento de calendarios o normas de produccin y entregas, asciende hasta la cima de la pirmide departamental, para que el responsable de un rea trate de esos asuntos con el responsable de las otras, y busquen una solucin. Despus, ambos responsables comunicarn la resolucin en sentido descendente hasta el nivel en el que se debe realizar el trabajo.La realidad actual obliga a la mayora de las organizaciones a competir en un mercado de compradores o de electores, en el que los individuos pueden, salvo en caso de monopolio o seudo democracia, demandar unos mejores productos y/o serviciosAhora se necesita una forma diferente de enfocar, de analizar, y de dirigir las organizaciones. Se debe dirigir una organizacin considerndola como un sistema integrado de procesos.La gestin por procesos es esta nueva forma diferente de dirigir las orga-nizaciones. Se pasa de una visin vertical de la organizacin a una visin hori-zontal que permite gestionar la organizacin no como un grupo de fun-cio-nes heterogneas (departamentos), sino como un sistema formado por flujos, pro-cesos, que satisfacen y superan las necesidades y expectativas razo-na-bles de los destinatarios de los mismos, los clientes y ciudadanos.De la Organizacin Jerrquica a la de ProcesosEl paso de una visin jerrquica de la organizacin a una visin de procesos no se realiza de forma brusca, si no que pasa por diferentes estadios. Existe un primer estadio en el que dominan las funciones, la organizacin por depar-tamentos. En un segundo estadio se comienza a reconocer que los procesos dentro de la organizacin son importantes, pero todava dominan las funciones. Finalmente, en el tercer estadio, se reconoce la supremaca de los procesos sobre las funciones y se trabaja con una visin horizontal de la organizacin.La gestin por procesos consiste en entender la organizacin como un con-jun-to de procesos que traspasan horizontalmente las funciones verticales de la organizacin. Permite asociar objetivos a estos procesos, de tal manera que se cumplan los objetivos de los departamentos para conseguir finalmente los obje-tivos de la organizacin. Los objetivos de los procesos deben correspon-der-se con las necesidades y expectativas de los clientes.

66

Mejora del Proceso

Porqu Enfocar sobre el Proceso?Teora del Proceso


La calidad del producto viene determinada por la calidad del proceso empleado en su desarrollo y evolucin

Enfocar el desarrollo de los productos y servicios mediante el diseo de su proceso proporciona una visin de conjunto altamente ventajosa.

El esfuerzo personal y las tecnologas aplicados sin un adecuado esquema de encaminamiento, no terminaren un resultado significativo.

Porque enfocar sobre el proceso?La calidad del producto, en este caso el software, viene determinada por la cali-dad del proceso empleado en su desarrollo y evolucin.El Proceso proporciona un enfoque constructivo que es adaptable y mejorable, en funcin a los cambios en el entorno y al avance de las tecnologasEsto se traduce en que un trabajo ms intensivo de las personas no conduce a una mejor calidad final, esta se alcanza con una utilizacin ms inteligente del esfuerzo humanoLa tecnologa por si sola no conduce tampoco a la obtencin de productos eficaces y de calidad, es necesario el mapa de carretera para obtener un resultado significativo.Una utilizacin eficaz de la tecnologa se consigue con un diseo apropiado de los procesos mapa.

77

Contrato

Memoria de ProyectoEstudio de Viabilidad

Plan

Cliente

Ingeniero Concepto

AnlisisInvestigacindel Sistema

Planos Detallados

- instalaciones- construccin

Diseo

ComprobacionesClculos de pilares,vigas, ...de electricidad Planta Alzado

Equipo deIngenieros

Mediciones y Supuestos

Pliego deCondiciones Construccin

Mantenimiento - Mejoras- Reparacin

Comprobacionesde desviaciones,mediciones, ...

Pruebas

Oficiales y Albailes

Jefe de Obra

Teora del Proceso


Planos

Memoria de Calidades

La figura anterior muestra el ciclo de vida por el que pasa la construccin de una casa. Al igual que el ciclo de vida de cualquier producto de ingeniera, en este caso una casa, en el software, como se ver ms adelante, ocurre lo mismo. Las etapas de construccin de forma resumida pueden ser: concepto, anlisis, diseo, construccin, pruebas y mantenimiento.

88

Teora del Proceso


9Teora del Proceso

Teora del Proceso


9

10

10

Mejora del Proceso

Teora del Proceso

El proceso del software

Es todo el conjunto de actividades necesarias para transformar los requisitos del usuario en software (Humphrey-90).

Definir orden de actividadesDefinir criterios para la transicin entre actividadesComunicar procedimientos

El Proceso proporciona un enfoque constructivo que es adaptable y mejorable, en funcin a los cambios en el entorno y al avance de las tecnologas

11

11

Cuando un Proceso es?Inmaduro

Mejora del Proceso

Teora del Proceso


Ad hoc; proceso improvisado por los profesionales y su direccinNi seguido ni impuesto rigurosamenteSumamente dependiente de los profesionales actualesDificultad para predecir la calidad del productoPosibilidad de problemas de coste y planificacin debido a una estimacin ineficazLa funcionalidad del producto y la calidad a menudo estn comprometidas para cumplir el planUtilizacin de una nueva y arriesgada tecnologa.

12

12

Codificary corregir

Entrega(imprevisible)

Especificacindel sistema(posibles)

Teora del Proceso


Tradicionalmente el desarrollo de aplicaciones informticas se llevaba a cabo de forma individualizada, a base de codificar (generar lneas de cdigo) y probar lo realizado cuanto antes. La misma persona escriba el cdigo, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificacin previa y sin que soliese existir documentacin alguna. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estara all cuando se produjese algn fallo. En principio, el hecho de que desde un primer momento se vaya generando cdigo, podra considerarse como un sntoma de enorme progreso, pero puede suponer posteriormente un gran retroceso e incluso la necesidad de desechar una gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a cabo las modificaciones necesarias para subsanarlos (por ejemplo si al 90% del cdigo se descubre que el diseo de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que no sea codificacin pura y dura no se realiza (como por ejemplo, actividades de planificacin, de documentacin, de aseguramiento de la calidad) [CALVO-MANZANO, 2001].Esta forma de desarrollar es muy comn en muchas organizaciones y, generalmente, se utiliza esta forma de desarrollo de aplicaciones cuando no se elige o sigue un enfoque de desarrollo (ciclo de vida) concreto y/o apenas se realiza la actividad de planificacin. Adems, otro factor que juega a favor de este enfoque de codificar y probar, es que requiere poca experiencia y cualquier persona podr fcilmente familiarizarse con l [MCCONNEL, 1997].

13

Teora del Proceso


Dedicar todo el esfuerzo a codificar, lanzar lneas de cdigo y probar cuanto antes.Trabajar con un nivel de requisitos de usuario mnimo y suponer el resto.Convencer al usuario que el producto obtenido es la mejor solucin a su problema. Corregir los fallos sobre el mismo cdigo operativo.No establecer ningn tipo de normativaCarecer de documentacin concordante con el cdigo operativo

13

14

14

Cuando un Proceso es?Maduro

Mejora del Proceso

Teora del Proceso


Es consistente, definido, documentado e innovado

Los esfuerzos son apoyados claramente por los involucrados.

La organizacin es ms importante y no dependiente

Se efectan mediciones de productos y procesos

Se realiza un uso racional y disciplinado de la tecnologa

El proceso una vez realizado es controlado y auditado

15

Teora del Proceso

Teora del Proceso


15

16

Las funciones principales de un ciclo de vida software son: Determinar el orden de las fases y procesos involucrados en el desarrollo del software y su evolucin (teniendo en cuenta el modelo de procesos que se utilice como referencia). Establecer los criterios de transicin para pasar de una fase a la siguiente (productos intermedios). Todo ello, incluye los criterios para la terminacin de la fase actual y los criterios para seleccionar e iniciar la fase siguiente.Algunas de las ventajas se seguir un enfoque basado en un ciclo de vida son: Documentacin simultnea al desarrollo, formalizada y estandarizada, lo que permite una comunicacin fcil (en el equipo, con usuarios, ...) y da visibilidad y posibilidad de control para la gestin del proyecto. Asegura un desarrollo progresivo, con controles sistemticos y deteccin precoz de defectos, siempre y cuando se cuente con las correspondientes etapas de revisin. Se controla el sobrepasar plazos de entrega y los costes excesivos, siempre y cuando se realice las actividades de seguimiento correspondientes. Gua para personal de desarrollo, ya que nos indica las tareas que hay que realizar Minimiza el rehacer el trabajo y los problemas de puesta a punto, teniendo en cuenta que detectamos antes los errores.

16

Teora del Proceso

El Ciclo de Vida (Modelos)

Conjunto de fenmenos transcurridos entre un momento dado de una generacin de un organismo y el mismo de

la generacin siguiente

17

17

Teora del Proceso


18

18

ConceptoContrato Viabilidad yplazos

Funciones

Diseo

Interaccinusuario/analista

Modelos de diseo (datos,funciones, interfaz)

ERS

DFDPrototipos

Anlisis

Programadores

Analistas orgnicosDiseadores

Personal de aseguramiento de calidad

Comprobaciones

Mundo y lenguajedel usuario:abstracciny lgica de usuario

Mundo y lenguajedel ordenador:lgica informtica

Pruebas

Explotacin y Mantenimiento

ProgramacinCdigo, programas,bases de datos

Teora del Proceso


La figura anterior muestra el ciclo de vida por el que pasa la construccin de software. Al igual que en el ciclo de vida de cualquier producto de ingeniera, recurdese el ejemplo de la casa, en el software, las etapas de construccin de forma resumida pueden ser: concepto, anlisis, diseo, construccin o programacin, pruebas y mantenimiento.

19

Secuencia uniforme y ordenada de los pasos de desarrollo No se adapta a cambios

Dificultad para el usuario de establecer todos los requisitos al principio

Producto disponible al final del desarrollo del proyecto

19

Anlisis derequisitos

Especificacinde requisitos

Diseopreliminar

Diseodetallado

Programaciny pruebas

Explotacin ymantenimiento

Teora del Proceso


CASCADA

Anlisis

Diseo

Codificacin

Pruebas

Mantenimiento

La versin original del modelo en cascada del ciclo de vida fue propuesta por Royce [ROYCE, 1970] y, desde entonces, han aparecido numerosos refinamientos y variaciones de dicho modelo: por ejemplo, [BOEHM, 1981], [SOMMERVILLE, 1985], [SIGWART, 1990]. El nmero de fases o etapas que se proponen en este ciclo suele variar, aunque suelen ser: anlisis de requisitos del sistema, anlisis de requisitos del software, diseo preliminar, diseo detallado, codificacin, pruebas, explotacin y mantenimiento.Algunas caractersticas de este ciclo son: Cada fase empieza cuando se ha terminado la fase anterior [HAWRYSZKIEWYCZ, 1990]. Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa [BOEHM, 1981]. Para ello, se realiza una revisin al final de la fase. Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados. Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto.Es fcil de comprender, planificar y seguir.Aunque es el ciclo de vida ms antiguo y el ms ampliamente utilizado, debido a las facilidades que da a los gestores para controlar el progreso de los sistemas, ha recibido numerosas crticas (vase, por ejemplo, [McCRACKEN y JACKSON, 1982]).Algunas de las crticas del modelo en cascada son: No refleja el proceso "real" de desarrollo de software. Los proyectos reales raramente siguen este flujo secuencial, puesto que siempre hay iteraciones. Aunque en este modelo la iteracin estpermitida en etapas contiguas [MACRO, 1990], en la vida real normalmente la iteracin abarca ms de una etapa. Un caso tpico es la redefinicin de los requisitos cuando se est codificando la aplicacin. Es decir, exige una definicin completa de todos los requisitos desde el principio. Se tarda mucho tiempo en pasar por todo el ciclo, dado que hasta que no se finalice una fase no se pasa a la siguiente. As, se podra dar el caso de no salir nunca de la fase de anlisis de requisitos software. Acenta el fracaso de la industria del software con el usuario final. En este caso, el usuario debe tener paciencia [PRESSMAN, 2002], ya que el sistema en funcionamiento no estar disponible hasta la fase final del proyecto.Se recomienda este ciclo de vida cuando: El proyecto es similar a alguno que se haya realizado anteriormente con xito. Los requisitos sean estables y estn bien comprendidos. El diseo y la tecnologa est probada y madura. La duracin del proyecto sea relativamente corta.

20

20

Teora del Proceso


INCREMENTAL



Diseopreliminar

DiseoDetallado 1

Programaciny pruebas 1

Explotacin yMantenimiento

1

DiseoDetallado n

Programaciny pruebas nExplotacin y

Mantenimienton

El modelo incremental [LEHMAN, 1984] corrige la necesidad de una secuencia no lineal de pasos de desarrollo. En el modelo incremental se va creando el sistema software aadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el sistema con nuevas funcionalidades o requisitos, es decir, cada versin o refinamiento parte de una versin previa y le aade nuevas funciones [AMESCUA et al, 1995]. El sistema software ya no se ve como una nica entidad monoltica con una fecha fija de entrega, sino como una integracin de resultados sucesivos obtenidos despus de cada iteracin.El modelo incremental se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones, diseos, etc., al comenzar el sistema, ya que cada refinamiento amplia los requisitos y las especificaciones derivadas de la fase anterior.El modelo incremental constituy un avance sobre el modelo en cascada, pero tambin presenta problemas. Aunque permite el cambio continuo de requisitos, an existe el problema de determinar si los requisitos propuestos son vlidos. Los errores en los requisitos se detectan tarde y su correccin resulta tan costosa como en el modelo en cascada.Las ventajas de este ciclo de vida son: Reduce los riesgos de retrasos, de cambios de requisitos y problemas de aceptacin. Los entregables intermedios facilitan la realimentacin para los subsiguientes entregables. Permiten al usuario validar al sistema a medida que se construye.Por el contrario tiene como desventajas: Es sensible a la planificacin de los entregables. No tiene xito si no hay una implicacin del usuario. Requiere una gestin de configuracin muy estricta.Se recomienda este ciclo de vida cuando: Se han realizado proyectos similares anteriormente. El diseo y la tecnologa estn probadas. La duracin del proyecto es mayor de un ao o el usuario necesita versiones intermedias.

21

Facilitan comunicacin con usuarios

Sistemas se desarrollan ms rpidamente

Sistemas ms fciles de aprender y utilizar por los usuarios finales

Desatencin a la tarea de anlisis (Rpido y sucio)

Incorrectas expectativas del usuario

21

Teora del Proceso


PROTOTIPO



DiseoPrototipo

ProgramacinY

pruebas

Prototipo

Evaluacin

DiseoDetallado

Programaciny pruebasExplotacin y

Mantenimiento

En este modelo de ciclo de vida se desarrolla el sistema a medida que avanza el proyecto. Normalmente se comienza desarrollando los aspectos ms visibles del sistema, y luego se continua el desarrollo del prototipo basndose en la realimentacin que se recibe del cliente.Como principal ventaja se tiene que se proporciona funcionalidad til al cliente antes de entregar el producto final completo.Por el contrario, se pueden crear incorrectas expectativas al usuario acerca de que el producto completo se finalizar antes de lo previsto.

22

22

Teora del Proceso


Determinar UsabilidadValidar

Recoger necesidadesValidar

Planificacin y DiseoValidar

Desarrollar UnidadesProbar

IntegrarVerificar

Entregar e ImplementarExplotar

EVOLUTIVO

El ciclo de vida evolutivo desarrolla tambin un sistema en distintas fases. El modelo de Ciclo de Vida Evolutivo se diferencia del Ciclo de Vida Incremental por que se reconoce que las necesidades de usuario no son completamente comprendidas ni estn completas. Y ello requiere una vuelta a planificar y disear despus de cada implantacin de los entregables.Las ventajas de este ciclo de vida son: No se necesita conocer todos los requisitos al comienzo. Al igual que en el incremental, los entregables intermedios facilitan la realimentacin para la subsiguientes entregables. Las tcnicas de prototipado permiten a los desarrolladores demostrar la funcionalidad a los usuarios con un mnimo esfuerzo.Por el contrario tiene como desventajas: Es difcil estimar el esfuerzo final necesario. Es difcil medir el progreso. No tiene xito si no hay una implicacin del usuario. Se tiene el riesgo de no acabar nunca. Se esta continuamente incluyendo nuevas versiones con mejoras (gold plating) y nunca se da por finalizado ni se entrega el producto.Se recomienda este ciclo de vida cuando: Los requisitos o el diseo no estn completamente definidos y es posible que haya grandes cambios. Se estn probando o introduciendo nuevas tecnologas. Las capacidades del sistema pueden ser demostradas por medio de la evaluacin de los usuarios. Existen grupos de usuarios diversos con diferentes intereses.

23

23

Diseodetallado

CdigoPruebasunitarias

Integraciny pruebaPrueba de

aceptacinImple-menta-cin

PrototipoOperativo

Plan deIntegraciny Pruebas

DiseoProductoSw

V & V deldiseo

Prototipo 3

Validacin deRequisitos

RequisitosSw

Plan deDesarrollo

Desarrollar y verificar el producto en el siguiente nivel

Plan de Requisitos

Plan del C.V.Planificar lasfases siguientes

Determinarobjetivos,alternativas,restricciones

Evaluar alternativas,identificar y resolverlos riesgos

Prototipo 2

Concepto deOperacin

Simulaciones, modelos, benchmarks

Teora del Proceso


Prototipo 1

Anlisis deRiesgos

ESPIRAL

Con el fin de paliar los inconvenientes del modelo en cascada [BOEHM, 1988], propuso el modelo en espiral, que consta de una serie de ciclos. Cada uno empieza identificando los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado, empezar a plantear el prximo.Una caracterstica importante del modelo en espiral es que cada ciclo se completa con una revisin en la que participan las principales personas u organizaciones que tienen relacin con el producto. Esta revisin cubre todos los productos desarrollados durante el ciclo anterior, incluyendo los planes para el siguiente y los recursos necesarios para llevarlos a cabo. La revisin de los principales objetivos sirve para asegurar que todas las partes involucradas estn de acuerdo respecto al mtodo de trabajo para la siguiente fase.Los planes para las fases sucesivas pueden tambin incluir una particin del producto en incrementos (para desarrollos sucesivos), o en componentes (para ser desarrollados por organizaciones individuales o personas). En este ltimo caso, se pueden prever una serie de ciclos en paralelo, uno por cada componente, aadiendo as una tercera dimensin al concepto de modelo en espiral. Por ejemplo, las espirales separadas pueden aparecer a partir de componentes software separados.Las principales diferencias [WOLFF, 1989] entre el modelo en espiral y los mtodos ms tradicionales son las siguientes:Existe un reconocimiento explcito de las diferentes alternativas para alcanzar los objetivos de un proyecto. La identificacin de riesgos asociados con cada una de las alternativas y las diferentes maneras de resolverlos son el centro del modelo. Con los mtodos tradicionales, es habitual dejar las partes ms difciles para el final y empezar con las ms fciles y de menor riesgo, obteniendo as la ilusin de un gran avance. La divisin de los proyectos en ciclos, cada uno con un acuerdo al final de cada ciclo, implica que existe un acuerdo para los cambios que hay que realizar o para terminar el proyecto, en funcin de lo que se ha aprendido desde el inicio del proyecto. El modelo se adapta a cualquier tipo de actividad, incluidas algunas que no existen en otros mtodos (por ejemplo, consulta de asesores expertos o investigadores ajenos) que son muy tiles para la consecucin de los objetivos de un proyecto.El modelo en espiral puede aplicarse en la mayora de las ocasiones. Sin embargo, en algunos casos hay que resolver ciertas dificultades [BOEHM, 1988]: Trabajo con software contratado. El modelo en espiral trabaja bien en los desarrollos internos, pero necesita un ajuste posterior para adaptarlo a la subcontratacin de software. En el desarrollo interno existe una gran flexibilidad y libertad para ajustarse a los acuerdos etapa por etapa, para aplazar acuerdos de opciones especficas, para establecer miniespirales para resolver caminos crticos, para ajustar niveles de esfuerzo, o para acomodar prcticas como prototipado, desarrollo evolutivo, uso de mtodos de diseo ajustado al coste. En el desarrollo de software bajo contrato no existe esta flexibilidad y libertad, por lo que es necesario mucho tiempo para definir los contratos, ya que los entregables no estarn previamente definidos de forma clara. Necesidad de expertos en evaluacin de riesgos para identificar y manejar las fuentes de riesgos de un proyecto. Normalmente, un equipo sin experiencia puede producir una especificacin con una gran elaboracin de los elementos de bajo riesgo bien comprendidos, y una pequea y pobre elaboracin de los elementos de alto riesgo. A no ser que se realice una inspeccin por expertos, en este tipo de proyecto se tendr la ilusin de progresar durante un perodo, y, sin embargo, se encuentra dirigido directamente hacia el desastre. Otro aspecto a tener en cuenta es que una especificacin dirigida por riesgos es tambin dependiente del personal. Por ejemplo, un diseo producido por un experto puede ser implantado por inexpertos. Sin embargo, lo contrario es muy difcil llevarlo a cabo.

24

Teora del Proceso


ESPIRAL

Reutilizacin del Software existente

Eliminacin de errores y alternativas psimas de forma temprana

No distingue entre desarrollo y mantenimiento

Necesidad de expertos en evaluacin de riesgos

Dependencia del personal

24

25

25

Teora del Proceso


Documentacin simultnea al desarrollo, formalizada y estandarizada

Comunicacin fcil (en el equipo, con usuarios, ...) Visibilidad y posibilidad de control para la gestin del

proyecto Asegura un desarrollo progresivo, con controles

sistemticos y deteccin precoz de defectos Se controla el sobrepasar plazos de entrega y los

costes excesivos Gua para personal de desarrollo, marcando las

tareas a realizar Minimiza el rehacer el trabajo y los problemas de

puesta a punto

Las funciones principales de un ciclo de vida software son: Determinar el orden de las fases y procesos involucrados en el desarrollo del software y su evolucin (teniendo en cuenta el modelo de procesos que se utilice como referencia). Establecer los criterios de transicin para pasar de una fase a la siguiente (productos intermedios). Todo ello, incluye los criterios para la terminacin de la fase actual y los criterios para seleccionar e iniciar la fase siguiente.Algunas de las ventajas se seguir un enfoque basado en un ciclo de vida son: Documentacin simultnea al desarrollo, formalizada y estandarizada, lo que permite una comunicacin fcil (en el equipo, con usuarios, ...) y da visibilidad y posibilidad de control para la gestin del proyecto. Asegura un desarrollo progresivo, con controles sistemticos y deteccin precoz de defectos, siempre y cuando se cuente con las correspondientes etapas de revisin. Se controla el sobrepasar plazos de entrega y los costes excesivos, siempre y cuando se realice las actividades de seguimiento correspondientes. Gua para personal de desarrollo, ya que nos indica las tareas que hay que realizar Minimiza el rehacer el trabajo y los problemas de puesta a punto, teniendo en cuenta que detectamos antes los errores.

26

26

Teora del ProcesoCiclo Econmico del Software


Ingresos: Ventas Licencias

Desarrollo: Personas Equipo Licencias

Mantenimiento: Instalacin Distribucin Soporte

Parar venta

Retirada

Tiempo

Ingresos

Gastos

Como se muestra en la figura del ciclo de muerte del software, existe una primera parte en que todo son gastos, debido principalmente al desarrollo del producto, y cuando el producto se pone en explotacin comienzan los ingresos, principalmente de venta del producto a travs de licencias, lo que genera un resultado neto positivo.Finalmente, llega un momento en que los gastos de mantenimiento superan los beneficios del producto relativos a su venta, y entonces se decir su retirada.

27

Teora del Proceso

Teora del Proceso


27

28

Mejora del Proceso

Teora del ProcesoEl proceso del software

Niveles abstraccin

Tipo nfasis EjemplosCiclo vida del producto Vista de pjaro Cascada

EspiralDesarrollo rpido

Proceso Qu pasa? Planificacin, seguimiento y control del proyectoRevisiones por ParesGestin de configuracin

Procedimiento Como ocurre una actividad de proceso?

Estimando tamaoInspecciones cdigo; walkthroughsRevisando compromiso externo con la alta direccin

29

29

Teora del Proceso

Elementos del Proceso

30

30

Teora del Proceso


Un proceso describe que pasaUn proceso describe acontecimientos o fases sobre lo que el lector necesita estar enteradoLos procesos generalmente carecen del nivel de especificidad requerido para que el lector ejecute las tareas descritas

Un procedimiento describe como ocurre algoEl procedimiento al igual que el proceso implica una serie de elementos que suceden de forma secuencial. Sin embargo un procedimiento describe los pasosque una persona ha de realizar

Las ActividadesSon las acciones que crean o alcanzan un producto del trabajo

Productos del trabajoSon el resultado de las actividades. Pueden ser tangibles o servicio

PersonasLos roles de la organizacin o proyecto que logran o crean el producto del trabajo

31

31

Teora del Proceso


Las ActividadesSon las acciones que crean o alcanzan un producto del trabajo

Productos del trabajoSon el resultado de las actividades. Pueden ser tangibles o servicio

PersonasLos roles de la organizacin o proyecto que logran o crean el producto del trabajo

Que ocurre?

Quin lo hace?

Qu se crea?

32

32

Teora del Proceso


Cuestin clave Elemento de informacin del proceso

Qu productos van a ser obtenidos? Lista de productos del trabajo

Que actividades van a ser ejecutadas? Lista de actividades

En que orden se ejecutarn? Secuencia de actividades

Porqu se ejecuta una actividad? Propsito de la actividad

Quin ejecuta una actividad especifica Actividad es ejecutada por

33

33

Teora del Proceso


Cuestin clave Elemento de informacin del procesoCundo empieza y termina una actividad?

Requisitos de la actividad

Cules son los productos del trabajo requeridos por una actividad especfica?

Entradas de la actividad

Cules son los productos del trabajo generados por una actividad especfica?

Salidas de la actividad

Cmo son implementadas las actividades?

Subactividades y procedimientos

Cmo se mide el rendimiento de la actividad?

Mtricas de la actividad

34

34

Teora del Proceso

Trminos del proceso

Trminos del proceso DescripcinActividades Son las etapas o pasos intermedios de un

proceso

Secuencia de actividad El orden de la actividad

Rol Actividades son realizadas por las personas. Las personas parte del proceso se describe como: Un rol Una organizacin, unidad o funcin Alguna extensin de una persona, tal como una herramienta

Propsito actividad Una sentencia clara y concisa que describe los objetivos y razn de la actividad

Requisitos Establecen que es necesario para realizar la actividad. Se expresan como atributos del producto presentes antes que se complete la actividad. Expresados en trminos medibles

35

35

Teora del Proceso

Trminos del proceso

Trminos del proceso Descripcin

Entrada Es el recurso que es transformado por la actividad en una salida (producto o servicio)

Referencia Usada como fuente de informacin que es utilizada para dirigir o guiar la actividad, pero la referencia no es transformada directamente por la actividad

Estimulo Dispara el arranque de una actividad. No es transformado por la actividad

Salidas Son los productos o servicios que resultan de la actividad. Salidas intermedias son entrada a otras actividades del proceso. El propietario de la actividad debe asegurarse que la salida est conforme con los requisitos de la actividad

Subactividades Son particiones de una actividad en partes subordinadas. Ayuda a definir la complejidad de gestin del proceso

Procedimiento Proporcionar instrucciones paso por paso sobre como actuar con la informacin

Medida Define como la ejecucin de la actividad es evaluada

Qu es un procedimiento?

36

Componentes clave Informacin soportePropsito

Diagrama de contexto mostrando como los procedimientos se adaptan en el proceso global

Cuando se ejecuta el procedimiento

Quien ejecuta el procedimiento

Entradas

Salidas

Requisitos

Pasos de accin y de decisin

Como medir el xito

Razonamiento (cuando apropiado)

Diagrama de flujo del procedimiento

Definicin de trminos

Ejemplos

Polticas relevantes

Como reportar un informe de problema asociado con el procedimiento

Como obtener ayuda

Plantillas o listas de comprobacin

Historia del cambio

Mejora del Proceso

Teora del Proceso

Componentes

36

37

Actividades

Decisin

Subproceso

Documento

Conector

Flecha

Simbologa bsicaTeora del Proceso

Representacin del Proceso

38

38

Teora del Proceso


39

39

Teora del Proceso

Descomposicin inicialDivisin de cada actividad en tres a seis subactividades principales


40

40

Teora del Proceso


41


Teora del Proceso


Cul es el propsito de esta actividad?Quin participa en esta actividad?Cules son las entradas necesarias para ejecutar esta actividad?Cules son los productos del trabajo que se generan por esta actividad?Cmo sabe cuando deber comenzar esta actividad?Cmo sabe cuando esta actividad ha sido completada con xito?Qu hace para completar esta actividad?.Cules son las tres a seis subactividades que ejecuta para completar esta actividad?Cmo determina o mide la ejecucin de esta actividad?Qu actividad es ejecutada antes y despus de esta?

Cuestiones clave de cada actividad

Actividad 2

Actividad 3

Actividad 1

41

Ejemplo:El propsito de probar la confiabilidad de la ingeniera es resolver cualquier aspecto residual de confiabilidad antes de entregar el producto para las pruebas de integracin

42

Teora del Proceso


Propsito de la actividad

Es una sentencia clara y concisa que describe los objetivos y la razn de la actividad

Una sentencia de propsito, mejora la comprensin y soporta la adaptacin y reuso de definiciones de proceso

42

La secuencia actividades es el orden de las actividades

43

Teora del Proceso


Actividades A.B y C ocurren en serie

En base al resultado deLa Actividad B la Actividad C comienzao el proceso itera atrs a la actividad A

En base al resultado deLa actividad A la actividadB o C comienza

Cuando la actividad A termina las actividadesB y C se realizan

concurrentemente

Secuencia de actividades

Las actividades son ejecutadas por genteLa gente parte del proceso, puede ser descrita

como: Un rol

Una organizacin, unidad o funcin

Alguna extensin de una persona como una herramienta automtica

44

Teora del Proceso


Ejecucin de actividades

44

Los requisitos de la actividad establecen lo que es necesario para ejecutar la actividad con xito.

En muchos casos los requisitos son expresados como atributos de los productos del trabajo de la actividadque deben estar presentes antes de concluir la actividad

Los requisitos deben expresarse en trminos medibles que puedan ser probados y evaluados

45

Teora del Proceso


Requisitos

45

Entradas son recursos que son transformados por la actividad como consecuencia de su propsito Salidas son los productos del trabajo o los servicios producidos por una actividad

46

Requisitosdel producto

Actividad 1Plan de desarrollo del producto

Plan de desarrollo del producto aprobado

Actividad 2 Actividad 3

Teora del Proceso


Entradas y salidas

Productos intermedios son cualquiera de las entradas o salidasde una actividad

46

47

47

Teora del Proceso


Estimulo

Entrada (recurso) Actividad 1

Referencia

Salida

Materiales de referencia y estmulos de una actividad, son componentes de la actividad, que no son transformadas por ella, pero que en determinadas circunstancias son necesarias para cumplir con el propsito de la actividad

Estmulo y referencia

Disposicin LegalLa referencia es usada como fuente de informacin que se utiliza para dirigir o guiar la actividad. La referencia no es directamente transformada por la actividad

El estmulo dispara el arranque de una actividad. Un estmulo no es transformado por el proceso

Se convierten en entradas de otra actividad del proceso. La actividad propietaria debe asegurar que la salida estconforme a los requisitos de la actividad

48

Actividad 1

Actividad 2

Salida

Entrada Salida

Referencia

Estmulo

Teora del Proceso


Salidas intermedias

48

Son particiones adicionales de una actividad en partes subordinadas. Estas particiones adicionales ayudan a definir el proceso de gestin de la complejidad del proceso

49

Actividad 1

Subactividad 1.1

Subactividad 1.1.1

Subactividad 1.2 Subactividad 1.3

Subactividad 1.1.2 Subactividad 1.1.3

Teora del Proceso


Subactividades

49

50

50

Teora del Proceso


Procedimiento

Subactividad 1.2 Subactividad 1.1

Subactividad 1.1.1Subactividad 1.1.2

Subactividad 1.1.3

Paso 2Paso 3

El procedimiento proporciona instrucciones paso a paso del tratamiento al que hay que someter a la informacin

Actividad 1

Subactividad 1.1

Paso 1Procedimiento

Definen como es evaluada la ejecucin de la actividad

Ejemplos Atributos de requisitos de la actividad (Calidad) Esfuerzo Tiempo calendario

51

Teora del Proceso


Medidas de la actividad

51

Lista de criterios de entrada Productos del trabajo Mtricas Establecer descripciones de tareas Procedimientos de validacin Lista de criterios de salida Productos del trabajo

52

Teora del Proceso


Lista de comprobacin

52

53

53

Teora del Proceso


Productos del trabajoResultados deseados

Comprender qu productos del trabajo van a ser generados es un prerrequisito para comprender cmo el proceso cumplir los resultados requeridos

Proceso

Productosdel trabajofinales

54

Teora del Proceso

Teora del Proceso


54

55

Planificacin colaborativaRecoger informacin del procesoMaqueta del proceso Organizacin de la documentacinRealimentar y refinarDocumentarArchivo y recuperacin

Teora del Proceso

Establecimiento del Proceso

55

56

Enfocar una planificacin colaborativa con los miembros del proyecto

Teora del Proceso


Planificacin colaborativa

Grupo de Proceso Grupo Tcnico de Trabajo

Compaero proyecto

57

Teora del Proceso



Funciones del Grupo de Proceso (GP)

57

El Grupo Tcnico de Trabajo, es una unidad organizativa de carcter temporal creada para el desarrollo de un programa concreto de Mejora de Procesos

58

El Grupo Tcnico de Trabajo (TWG)

Teora del Proceso



58

59

El Grupo Tcnico de Trabajo (TWG)

Teora del Proceso



Detectan problemas e identifican soluciones Formulan las soluciones. Revisan el Plan de Accin para ajustar la solucin seleccionada. Plantean las posibles soluciones a el rgano de gerencia Seleccin del grupo del prototipo. Comienzan el prototipo. Evalan los resultados del prototipo. Revisan el plan de accin de acuerdo a los resultados del prototipo.

59

60

Teora del Proceso


Papel de consultora del PGEl PG juega un rol de consultor y soporte para instrumentar una ayuda eficaz al TWG (Grupo de Trabajo Tcnico).Para que el TWG, arranque correctamente con la actividad de definicin del proceso, la ayuda, que debe ser de carcter intensivo, se debe acompaar con intervenciones de formacin y entrenamiento.

El nfasis siempre se enfocar sobre la consultora para el desarrollo


60

61

Teora del Proceso


Miembros del PG son los facilitadores del desarrollo

Tipo DescripcinConsultora bsica El grupo espera del consultor que mantenga

el enfoque en problemas sustantivos El grupo usa al consultor para mejorartemporalmente su proceso en orden aresolver un problema

El grupo espera que el consultor gue y dirija el proceso del grupo

Consultora para el desarrollo

El consultor comparte la responsabilidad de la direccin del proceso del grupo con sus miembros El consultor ayuda permanentemente al grupo a mejorar su proceso


61

62

Teora del Proceso



Naturaleza iterativa de la planificacin

62

63

Teora del Proceso



Naturaleza iterativa de la planificacin

El plan del TWG incluye subtareas Desarrollar borrador de detalle del plan y calendario; Revisar borrador con personal del proyecto Negociar calendariosRevisar los planes requeridos y Comunicar los resultados (aMSG y otros)

63

64

Teora del Proceso


Recoger informacin del proceso

Consideraciones de planificacin

El consultor del PG trabaja con el TWG para planificar una sesin de recogida de datos efectiva. Los aspectos ms importantes incluyen lo siguiente:

64

65

Teora del Proceso


Gestin Contrato

IngenieraSistemas

Ingeniera Software

ServicioCliente

Proyecto


65

66

Teora del Proceso


mtodos

Datosmedicin

procedimientos

plantillas

Polticasrelevantes

Diagramas proceso

formularios

Documentosbasados en mtricas


67

Teora del Proceso



67

68

Teora del Proceso



68

69

Teora del Proceso



Dirige el flujode cuestiones

Consultor

Escritor principal

Controlador del Tiempo

Crea un registroPblico con la informacin

de la entrevista

Mantiene a todos informados del tiempo planificado y del que se lleva consumido

El Consultor del PG ensea tcnicas de entrevista y sirve como modelo de rol para la sesin de recogida de datos inicial. Luego, otros miembros del TWG asumen el rol dirigidos por el consultor.

69

70

Teora del Proceso



Registran informacin de las entrevistas y proporcionan soporte cuando se necesite al consultor

Otros miembros del TWG

70

71

Teora del Proceso



Esta propuesta implica usar una combinacin de dos tcnicas para obtener la descripcin del proceso.

71

72

72

Teora del Proceso


Establecer una atmsfera relajada. Asegurarse que no hay percepcin de que la reunin es una auditoriaSea un oyente bueno y cuidadoso Use su texto de facilitacin Recuerde que la gente le estar observando y puede estar formndose una impresin inicial sobre el esfuerzo de PI basndose en su organizacin y efectividad. Comenzar a la hora y terminar a la hora (5 minutos antes)

No usar un lenguaje que pueda ser confuso para el que escucha (trminos CMMI)

Qu hacer

Qu no


73

Teora del Proceso


Desarrollo de la MaquetaMaqueta del proceso

Durante esta actividad el equipo de trabajo utiliza los resultados de la recogida de datos para hacer una Maqueta del proceso existenteQu es una Maqueta del proceso?

Una maqueta de proceso es cualquier representacin de un proceso. La maqueta de proceso pueden basarse en texto o grficos

La mayor parte de las notaciones normalmente emplean una combinacin de texto y grficosLa Maqueta de proceso se utiliza cuando una descripcin exhaustiva y completa del proceso es indeseable o no prctica

La maqueta de proceso sirve de ayuda en el anlisis y comprensin del proceso

73

74

74

Diagrama de flujo

Un diagrama de flujo proporciona informacin sobre:

Dnde comienza el proceso de trabajo. -Input.Todas las actividades necesarias para que el proceso de trabajo sea completado - tareas.La relacin entre las diferentes actividades - Flechas de direccin.Los pasos a dar en el proceso de trabajo, donde se toman decisiones. Puntos de decisin.Donde el proceso de trabajo es detenido hasta que otra actividad sea completada. - Puntos de Espera.Donde termina el proceso. - Output.

Teora del Proceso


Maqueta del proceso

Comenzar con un grfico de flujo o diagrama de bloques

75

2 esfuerzoestimado

Use una clusula de verbo corta que indique claramente el objetivo de la actividad. Numere cada caja

Dibuje un diagrama fcil de comprenderQue muestre

Principales actividades Puntos de decisin y bifurcacin Secuencia de las actividades

Mejora del Proceso

Teora del Proceso


Maqueta del proceso

75

76

76

Funciones y Responsabilidades

Actividades

Organizacin Funcin

Teora del Proceso


Responsable

Suministra datos

Notifica

R

I

N

Clave

Maqueta del proceso Plantillas de proceso

Relaciona para cada actividad identificada en el diagrama de flujo quienes son sus participantes, que papel desempean en la misma y a que organizacin pertenecen.Este cuadro complementa en parte la informacin del diagrama de flujo

77

77

Actividades

FUNCIONCliente

Jefe deProyecto Calidad

GestorEjecutivo

Jefe Diseo

JefeDesarrollo

P= Participar

A=Autorizar

N= Notificar

P A P N

A P P

A P

A P NN

A P NN

A P NNN

A P NN

P P NAN

P P NANN

1.0 Definir el Proyecto

2.0 Revisar Proyectos Pendientes

3.0 Seleccionar equipo

8.0 DesarrolloDiseo Tcnico

9.0 Realizar el Sistema

7.0 DesarrolloDiseo del Sistema

10.0 Comprobar

4.0 DefinirRequisitos

5.0 Plan de Proyecto6.0 Desarrollo

Diseo Conceptual A P NNN

Teora del Proceso


Maqueta del proceso

78

78

Productos

Actividades Tecnologas

Productos del trabajo y tecnologas

EntradaSalidaEstimulo

I O S

CLAVE

ReferenciaR


Teora del Proceso

Especifica los productos del trabajo, los califica de acuerdo a la clave y los relaciona con las actividades identificadas en el diagrama de flujo.Si es necesario se determinan las tecnologas utilizadas para el cumplimiento de la actividadEste cuadro complementa en parte la informacin del diagrama de flujo

Maqueta del proceso Plantillas de proceso

79

79

Actividades InformacinClienteSituacin

Trabajo (SOW) TecnologaComprobarRequisitos

Esquemadel Plan

RevisarPlan

I= Entrada

O=Salida

R= Referencia

S= Estmulo

e-mail

HojaCalculo

DBSQL

Planif.

O

I O

I/O I

S O

R R I O

R I/O R I/O

Origen Externo

1.0 Establecer Proyecto

6.O DesarrollarDiseo Conceptual

2.0 Revisar Proyec-tos Pendientes

3.0 Seleccionar equipo

4.0 Definir Requisitos

5.0 Plan Proyecto I I/O

Teora del Proceso


Maqueta del proceso

80

80

Actividades Requisitos Medida de rendimientos

Mtodo de medicin

Requisitos y Medidas

Teora del Proceso


Maqueta del proceso

Plantillas de proceso

Que requisitos son necesarios para poder desarrollar la actividad, o como consecuencia de ella.Si procede, establecer el rendimiento de la actividad, y cual fue el mtodo empleado para determinar el rendimiento.

81

81

Propsito del grupo de actividades y de cada sub-actividad

Actividades Propsito Sub-actividad

Teora del Proceso


Maqueta del proceso

Informa sobre el mvil que persigue la actividad, e indica todas las sub-actividades que se comprenden en la actividad principal

82

Mejora del Proceso

Teora del Proceso


Organizacin de la Documentacin

Escribir para el lector no para uno mismo

82

83

Mejora del Proceso

Teora del Proceso



Escribir para el lector no para uno mismo

83

Escribir procedimientos utilizablesCuando escriba procedimientos dese cuenta que el lector necesitar

ser capaz de contestar diferentes cuestiones rpidamente.

84

Mejora del Proceso

Teora del Proceso



84

Escribir procedimientos utilizables

85

Mejora del Proceso

Teora del Proceso



Cuando escriba procedimientos dese cuenta que el lector necesitarser capaz de contestar diferentes cuestiones rpidamente.

El procedimiento deber estar enfocado sobre la informacin que necesitar tener a mano para cumplir la tarea.

Demasiado a menudo, los escritores logran llegar al nivel de detalle al escribir sobre detalles que conocen. Dejan las tareas de resolver las cuestiones anteriores al lector

85

Ejemplos: cosas a evitarDescripciones de acciones que son demasiado vagas o generalesTerminologa que puede ser confusa para el lectorProcedimientos descritos en demasiado detalle, una moda para el

lectorNinguna accin o informacin no directiva incluida en un paso del

procedimientoAcrnimos indefinidos o sobre uso de acrnimosReferencias a terminologa desde su modelo de referencia (ej. CMMI),

porque el lector no entendera y es improbable que esta informacin les ayude con la tarea entre manos

Referencias a otros documentos que no son requeridos para completar la tarea entre manos

86

Mejora del Proceso

Teora del Proceso

Ayudas

86

Principios para trazar el mapa de informacinMtodo para escribir el mapa de informacin est basado en mas de

veinte aos de investigacin sobre como la gente lee y comprende la informacin.

El mtodo para escribir el mapa de informacin se basa en siete principios bsicos de comunicacin.

Los principios aseguran un estilo de escritura basado en el lector y orientado a la tarea que satisface las necesidades de ambos lectores y escritores.

87

DescomposicinRelevanciaEtiquetadoConsistencia

Grficos integradosDetalle accesibleJerarqua de

descomposicin y etiquetado

Principios para trazar el mapa de informacin

1234

567

Mejora del Proceso

Teora del Proceso

Principios trazado mapa informacin

87

El principio de descomposicinLos escritores debern agrupar la informacin en unidades pequeas y

manejables Una unidad manejable de informacin es una consistente en no

mas de nueve piezas de informacin Investigacin sugiere que la gente procesa y recuerda de forma

optima no mas de siete mas menos dos (7 + 2) piezas, o unidades de informacin al mismo tiempo.

Descomponiendo la informacin, el escritor mejora la comprensin del lector, el acceso y la velocidad de recuperacin

Puesto que los lectores no pueden retener mas de cinco a nueve piezas de informacin en la memoria inmediata, comprenden mas rpida y completamente el material que ha descompuesto

Como la complejidad de la informacin incrementa, el limite de descomposicin disminuye.

88

1

Mejora del Proceso

Teora del Proceso


88

Ejemplo: el principio de descomposicinUn escritor cre este borrador:

Diferencial ambiental es un cierto porcentaje basado en lo pagado de salario hora a los empleados cuando trabajan en situacin peligrosa. Cuando requerimos a nuestros empleados de mantenimiento trabajaren andamios, les pagamos este diferencial ambiental por las horas que estn haciendo este trabajo

El escritor not que aunque el borrador no era excesivamente grande, estaba presentando dos aspectos diferentes (1) definiendo un termino y (2) dando un ejemplo del termino en el mismo componente

Aplicando el principio de descomposicin, el prrafo fue rehecho en dos componentes: Diferencial ambiental es un cierto porcentaje sobre lo pagado en el

salario hora a los empleados cuando trabajan en situaciones peligrosas Cuando requerimos a nuestros empleados de mantenimiento trabajar

en andamios, les pagamos el diferencial ambiental por las horas que han estado haciendo ese trabajo

89

Mejora del Proceso

Teora del Proceso


89

El principio de relevancia

Los escritores deben estar seguros que toda la informacin en un componente se relaciona con un punto principal basado sobre ese propsito o funcin de la informacin para el lector

Los escritores deben asegurarse que los componentes contienen una clase limitada de informacin. Todas las sentencias o diagramas en un componente deben pertenecer a un nico tpico. Si hay nicamente una clase de informacin en un componente, los lectores no tendrn que cambiar de herramientas mientras leen una unidad de informacin.

Lo ms importante, los escritores deben dejar la informacin irrelevante fuera. Poner sentencias de transicin, hace que ello fluya o agradable de saber en otro componente

Si informacin irrelevante es incluida los lectores tienen que resolver porque el material extrao est all, que hacer con l y a donde pertenece. Esto es un trabajo extra y ralentiza la velocidad del lector

Emplear el principio de relevancia ayuda en la comprensin y en el tiempo

90

22

Mejora del Proceso

Teora del Proceso


90

El principio de etiquetadoDespus de organizar las sentencias relacionadas en unidades

manejables, los escritores deben proporcionar una etiqueta para cada unidad de informacin.

Porque etiquetar Etiquetado facilita la comprensin y recuperacin de informacin

Previo Investigacin indica que la gente comprende y accede a la informacin ms rpidamente cuando tienen un previo de lo que va a llegar. Una etiqueta proporciona un previo breve de cada unidad de informacin. Es un adelanto del organizador para el lector

Examen La etiqueta tambin destaca en el texto para permitir un rpido examen. Los lectores pueden usar las etiquetas para encontrar la informacin que necesitan rpidamente

91

3

Mejora del Proceso

Teora del Proceso


91

Ejemplo: el principio de etiquetado

92

Definicin Diferencial ambiental es un cierto porcentaje sobre lo pagado en el salario hora a los empleados cuando trabajan en situaciones peligrosas

Ejemplo Cuando requerimos a nuestros empleados de mantenimiento trabajar en andamios, les pagamos el diferencial ambiental por las horas que han estado haciendo ese trabajo

Mejora del Proceso

Teora del Proceso


92

El principio de consistenciaPara asuntos con similares objetivos, los escritores deben usar

palabras, etiquetas, formatos, organizaciones y secuencia similares.Consistencia ahorra tiempo a los lectores porque ellos pueden Encontrar la informacin que necesitan rpidamente Localizar informacin similar, incluso evitar la ambigedad Enfocar sobre el contenido ms que sobre la formaMuchos retricos tradicionales animan a los escritores a usar variedad

para entretener a los lectores. Sin embargo en escritura tcnica y de diseo, el valor est en la capacidad del lector en usar el documento para hacer el trabajo

Variedad es frecuentemente distraccin y consumidora de tiempo, mas que entretenimiento

93

4

Mejora del Proceso

Teora del Proceso


93

El principio de grficos integradosEscritores debern usar diagramas, tablas, dibujos, etc., como una

parte integral del texto, no como una ocurrencia aadida cuando la escritura est completa. Investigacin indica que aproximadamente el 50% de la poblacin

adulta aprende mejor desde dibujos y otros grficos que desde palabras

Si los grficos, tales como tablas, diagramas y dibujos son una parte integral del texto, los lectores no tendrn que ir adelante y atrs a travs de un documento para encontrar lo que necesitan

94

5

Mejora del Proceso

Teora del Proceso


94

Ejemplo: principio de grficos integradosEn la escritura tradicional dos o ms sentencias IF-THEM generalmente

aparecen en forma de prrafo. Aqu hay un ejemplo.

Ofrecemos crdito a clientes establecidos que han realizado pedidos con nosotros en el pasado. Si un nuevo pedido es de 25,00$ o menos, esperamos el pago inmediato del pedido porque nuestro coste de preparacin es demasiado alto para justificar una garanta de crdito. Si hay facturas pendientes, retenemos el crdito. Pedidos de 26,00$ a 500,00$ pueden ser cumplimentados a crdito si no hay facturas pendientes. Pedidos de mas de 500,00& debern ser remitidos a su supervisor.

Use esta tabla para determinar como aprobar o desaprobar un pedido

95

Aproximacin tradicional

Aproximacin a grficos integrados

SI LA CANTIDAD DE PEDIDO ES

Y HAY ENTONCES

25,00$ o menos - Negar crdito

Entre 25,00$ y 500,00$ No facturas pendientes Extender crdito

Facturas pendientes Negar crdito

Ms de 500,00$ - Llame a su supervisor

Mejora del Proceso

Teora del Proceso


95

El principio de detalle accesibleEscritores deben escribir al nivel de detalle que

proporciona la informacin que el lector necesita, fcilmente accesible y que es usable por todos los lectores. Poner lo que el lector necesita donde lo necesita Incluir etiquetado claramente visin global, descripciones,

diagramas y ejemplos para todas las presentaciones en abstracto. Coloque los diagramas y ejemplos junto al texto que los ilustra.

El procesador de informacin humano, el cerebro, trabaja mejor cuando principios abstractos, conceptos y procedimientos estansoportados y explicados por ejemplos ejemplos concretos.

Evitar forzar a los lectores a otras partes del documento y a otros documentos para ejecutar la tarea que es el propsito del documento.

96

6

Mejora del Proceso

Teora del Proceso


96

Principio de jerarqua de descomposicin y etiquetadoEscritores debern organizar pequeas y relevantes unidades de informacin

en una jerarqua y proporcionar grupos mayores que han creado con una etiqueta.

Como el nmero de cualquier grupo de elementos crece mas all del lmite de descomposicin(7+ 2) los lectores tendrn de nuevo dificultad para comprender y recordar la informacin.

Los investigadores indican que la gente comprende y recuerda mejor grandes cantidades de informacin si esa informacin est organizada en grupos relacionados de 5 a 9 elementos cada uno.

Lectores tambin aprenden ms rpido y recuperan informacin ms rpidamente si cada uno de los elementos est etiquetado.

97

7

Mejora del Proceso

Teora del Proceso


97

Ejemplo: principio de jerarqua de descomposicin y etiquetadoUn escritor cre un procedimiento para desarrollar un plan

de desarrollo de producto (PDP). Cuando el procedimiento estuvo completo el gestor del proyecto (usando el procedimiento) tena que seguir 28 pasos.

El escritor se dio cuenta que el material exceda el lmite de descomposicin y que sera difcil para los lectores comprender la informacin.

Por tanto el escritor busco relaciones entre los pasos individuales, reagrupo las unidades separadas (los pasos) en varios diferentes procedimientos y dio a cada nuevo procedimiento una etiqueta de modo que as los lectores podan encontrar informacin especfica

98

Mejora del Proceso

Teora del Proceso


98

Ejemplo: principio de jerarqua de descomposicin y etiquetado2

99

Desarrollar un plan de desarrollo del producto

Determinar aproximacinY alcance del proyecto

Conducir trabajo de plan del producto

Estimar recursos del proyecto y calendario

Mejora del Proceso

Teora del Proceso


99

Ejemplo: principio de jerarqua de descomposicin y etiquetado3

100

Esto es como podra estar organizado el documento

Mejora del Proceso

Teora del Proceso


100

101

101

Teora del Proceso


Paquete de descripcin del procesoOrganizar la informacin en un documento que puede ser revisado por colegas

El documento deber ser: jerrquico modular una combinacin de texto narrativo, diagramas y tablasOrganizar las secciones del documento por actividadProporcionar suficiente informacin y contexto para facilitar la

comprensinIncluir artefactos del modelo de proceso como apndices a la seccin

principal del documento

102

102

Teora del Proceso


Obtener realimentacin y refinar

Obtener realimentacin y refinar

103

En el proceso de revisin y realimentacin, los practicantes son arrastrados en el esfuerzo de mejora como verdaderos socios.Desde el punto de vista de transicin de tecnologa, impulsar a la organizacin en el esfuerzo de mejora en este primer paso, paga dividendos reales, minimizando la resistencia de los miembros de la organizacin en el eventual cambio de proceso.

Descripcinproceso

Revisin

Realimentacin

Personalproyecto

Mejora del Proceso

Teora del Proceso


103

Desarrollar otros componentes de la solucinLa gua del proceso es solo un elemento de la solucin del producto

completaConsidere la necesidad de Entrenar en el proceso Entrenador/mentor Formatos, plantillas, listas de comprobacin y otras ayudas al

trabajo

104

Un sistema de realimentacin del proceso (sistema de sugerencias y proceso de reporte de problemas) Un mecanismo de mantenimiento para la gua del proceso Seguimiento del rendimiento del proceso (mtricas) Mecanismo para control de configuracin de la gua del proceso

Mejora del Proceso

Teora del Proceso

Otros componentes

104

Conducir revisiones

105

adaptar componentes del producto completo

Revisin estructurada del GP y del EGT

Revisiones por pares con usuarios del proceso

Pilotar los materiales y ver que funciona y que necesita cambiar

No trate de crear la solucin perfecta la primera vez. Use sus colegas como consejo sonda y conduzca revisiones para obtener ideas de mejora.

Pilotando el producto completo los componentes proporcionan informacin valiosa que puede utilizar para mejorar la solucin.

Debe darse cuenta de que a pesar de sus esfuerzos, es imposible desarrollar la solucin perfecta la primera vez. Revisando y pilotando los la nueva solucin del producto completo los componentes siempre ponen al descubierto errores que deben ser fijados.

Planee sobre ello

Mejora del Proceso

Teora del Proceso

Revisiones

105

Obtener una rpida realimentacin arrastrando a otros en el esfuerzo

106

Borrador deDescripcin Del proceso

Qu piensa denuestro proceso para conducir revisiones estructuradas?Alguna sugerencia?

Mejora del Proceso

Teora del Proceso

Revisiones

106

Establecer una biblioteca de activos del proceso

107

El GP establece la biblioteca de activos del proceso de la organizacin. Esta biblioteca es un repositorio central para todos los procesos relevantes de los proyectos. Contiene copias maestras de las descripciones de los procesos, polticas, etc.

Un miembro del GP se convierte en el bibliotecario oficial Los activos se mantienen usando gestin de configuracin

El GP prepara los mecanismos adecuados para operar la biblioteca(Web, Lotus Notes, herramientas de vendedor, copias duras, etc.

La biblioteca proporciona un mecanismo de comunicacin valioso y fomenta el aprendizaje de la organizacin

Mejora del Proceso

Teora del Proceso

Biblioteca de activos

107

108

Mejora del Proceso

Teora del Proceso


Comunicar los resultados

La ms poderosa herramienta que tienen en la gestin del cambio el PG y el TWG es la comunicacin

El PG y el TWG preparan un informe final para el MSG y otro afectados relevantes de la gestin

El equipo de PI deber dar seminarios para mantener informados a los individuos interesados

108

109

Teora del Proceso

Teora del Proceso


109

110

110

Mejora del Proceso

Qu es un Modelo de Procesos?Teora del Proceso

Modelo proceso

Una coleccin estructurada de elementos que describen las caractersticas de los procesos efectivos.

Proporciona:

un punto de arranque el beneficio de experiencias previas de la comunidadun lenguaje comn y una visin compartidaun marco de trabajo para priorizar acciones

111

Mejora del Proceso

Teora del Proceso

Modelo proceso

Una coleccin estructurada de elementos que describen las caractersticas de los procesos efectivos.

Proporciona:

un punto de arranque el beneficio de experiencias previas de la comunidadun lenguaje comn y una visin compartidaun marco de trabajo para priorizar acciones

111

Porqu es importante un modelo? Un modelo proporciona:

un punto de arranque el beneficio de experiencias previas de la

comunidad un lenguaje comn y una visin compartida un marco de trabajo para priorizar acciones

112

Mejora del Proceso

Teora del Proceso

Modelo proceso

112

113

Mejora del Proceso

Teora del Proceso

Modelo proceso

. Cmo es usado un Modelo?

Un modelo es usado

para ayudar a establecer objetivos de mejora de proceso y prioridades, mejorar procesos, y proporcionar una gua para asegurar procesos estables, capaces y maduros

como una gua para mejorar procesos de la organizacin

113

114

Describen los procesos que PODRAN utilizarse para adquirir, suministrar, desarrollar, explotar, soportar y mantener el software IEEE 1074 Estndar para el Desarrollo de Procesos

del Ciclo de Vida Software Instituto de Ingenieros Elctricos y Electrnicos

ISO 12207-1 Proceso del Ciclo de Vida Software Organizacin Internacional de Estndares

Capability Maturity Model Integrated (CMMI) Instituto de Ingeniera del Software (SEI)

114

Teora del Proceso

Modelo proceso

Modelos de Referencia I

Las organizaciones profesionales y los organismos internacionales se han venido ocupando de los procesos universales de ingeniera del software que son fundamentales para realizar un buen desarrollo de un sistema de informacin y que cubren las actividades de mejoras prcticas (aquellas que proporcionan buenos resultados). As, han desarrollado modelos de referencia que describen los procesos que una empresa podra utilizar a la hora de la adquisicin, suministro, desarrollo, explotacin, soporte y mantenimiento de software.El Instituto de Ingeniera del Software (SEI) ha desarrollado el Modelo de Madurez de la Capacidad (Capability Maturity Model, CMM) [CMMI Team, 2006], el cual proporciona a las organizaciones software una orientacin sobre cmo hacerse con el control de sus procesos de desarrollo y mantenimiento de software, y cmo evolucionar hacia una cultura de ingeniera del software y de gestin por excelencia.Los organismos IEEE e ISO/IEC han publicado sendas normas denominadas, respectivamente, IEEE-1074 [IEEE, 1991], e ISO/IEC 12207-1 [ISO, 1994]. Actualmente, ISO/IEC ha desarrollado dentro del marco de Evaluacin del Proceso Software un nuevo informe tcnico alineado con el anterior, ISO/IEC TR 15504-2 [ISO, 1998].

115

Establecen los procesos implicados para desarrollar SI, desde que surge la idea hasta que se retira

No imponen La utilizacin de un Modelo de CVS (Ciclo de Vida Software)

especfico El uso de una metodologa de desarrollo / tcnicas /

herramientas software especfica Una estructura de organizacin para un proyecto de desarrollo

software Cada empresa debera seleccionar, para cada proyecto,

los procesos que considere necesario realizar (con las actividades que crea conveniente) y establecer sus propios CVS

115

Teora del Proceso

Modelo proceso

Modelos de Referencia II

Todos estos modelos de referencia establecen los diferentes procesos implicados a la hora de desarrollar sistemas informticos, desde que surge la idea o necesidad de desarrollar las aplicaciones informticas hasta que stas se retiran de explotacin.Sin embargo, ninguno de estos modelos impone la utilizacin de un modelo de ciclo de vida o mtodo de desarrollo concreto, sino que cada empresa debera seleccionar, para cada proyecto, los procesos que considere necesario realizar (incluyendo las actividades que crea conveniente), y as establecer sus propios ciclos de vida software.Estos modelos tampoco imponen cmo implementar o realizar las diferentes actividades incluidas en cada uno de los procesos, por lo que cada empresa debera utilizar las tcnicas, mtodos y herramientas que considere oportuno.

116

Marco de referencia que contiene (ISO 12207-1) Procesos Actividades Tareas

involucradas en el desarrollo, explotacin y mantenimiento de un producto software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso

Aproximacin lgica a la adquisicin, suministro, desarrollo, explotacin y mantenimiento del software (IEEE 1074)

Modelo de proceso Determinan qu procesos han de realizarse para desarrollar software

CV determina en qu orden y cules son las actividades y tareas a realizar

116

Teora del Proceso

Ciclos de Vida

El estndar ISO/IEC 12207-1 entiende por modelo de ciclo de vida "un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso". El estndar IEEE 1074 entiende por ciclo de vida software una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software. Ambas consideran una actividad como un conjunto de tareas y una tarea como una accin que transforma entradas en salidas. Conviene destacar que los modelos de proceso determinan qu procesos se han de realizar para desarrollar el software, mientras que el ciclo de vida determina en qu orden y cules son las actividades y tareas que se han de realizar.A lo largo de la historia se han propuesto diferentes paradigmas o ciclos de vida para el software: desde el ciclo en cascada, pasando por el modelo en espiral de Boehm, hasta los ms recientes ciclos de vida orientados al objeto.El ciclo de vida software es la descripcin de las distintas formas de desarrollo de un proyecto o aplicacin informtica, es decir, la orientacin que debe seguirse para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. Tambin puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.

117

117

Procesos principales Procesos de soporte

Procesos de la organizacin

SUP. 1 Documentacin

SUP.2 Gestin de configuracin

SUP.8 Resolucin de problemas

SUP.3 Aseguramiento de calidad

SUP.4 Verificacin

SUP.5 Validacin

SUP.7 Auditora

SUP.6 Revisin conjunta

CUS.2 SuministroCUS.1 AdquisicinPreparacin de adquisicinSeleccin del suministradorSupervisin del suministradorAceptacin del cliente CUS.4 Explotacin

Uso operativoSoporte del clienteCUS.3

Educcin de requisitos

ENG.2 Mantenimiento del sistema y software

ENG.1 DesarrolloAnlisis y diseo de los Construccin softwarerequisitos del sistema Integracin softwareAnlisis de los requisitos Pruebas del softwaresoftware Integracin y pruebasDiseo software del sistema

MAN. 1 GestinMAN.2 Gestin del proyectoMAN.3 Gestin de la calidadMAN.4 Gestin del riesgo

ORG. 1 Alineamiento con la organizacinORG.2 MejoraEstablecimiento, Evaluacin y Mejora del proceso

ORG.3 Gestin de recursos humanosORG.4 InfraestructuraORG.5 Medida ORG. 6 Reutilizacin

El estndar ISO/IEC 12207-1 muestra los procesos del ciclo de vida software que pueden emplearse para adquirir, suministrar, desarrollar, explotar y mantener el software. Tambin incluye los procesos para definir, controlar y mejorar los procesos del ciclo de vida software.La categora de proceso Cliente-Suministrador (CUS) consiste en los procesos que impactan directamente al cliente, soportando el desarrollo y la transicin del software al cliente, y estipula la explotacin y uso correcto del producto software o servicio.La categora de proceso de Ingeniera consta de los procesos que directamente especifican, implementan o mantienen el producto software, su relacin con el sistema y su documentacin del cliente.La categora de proceso de Soporte consta de los procesos que pueden emplearse por cualquier otro proceso (incluyendo otros procesos de soporte) en varios puntos del ciclo de vida software.La categora de proceso de Gestin consta de los procesos que contienen prcticas de naturaleza genrica que pueden ser utilizadas por cualquiera que gestione cualquier tipo de proyecto o proceso dentro de un ciclo de vida software.La categora de proceso de Organizacin consta de los procesos que establecen los objetivos del negocio de la organizacin y desarrollan el proceso, el producto y los valores de recursos, los cuales, cuando se utilizan por los proyectos en la organizacin, ayudarn a la organizacin a lograr sus objetivos de negocio. Aunque las operaciones de la organizacin en general tienen un alcance mucho ms amplio que el de procesos software, los procesos software se implementan en un contexto de negocio y, para ser eficaz, requieren un entorno organizativo apropiado.

118

Continuo Etapas

Soporte Gestin del Proyecto

Gestin del Proceso

Ingeniera

5 CAR OID

4 QPM OPP

3 DAR IPM + IPPD, RSKM

OPD + IPPD, OPF, OT

PI, RD, TS, VAL, VER

2 CM, MA, PPQA

PMC, PP, SAM

RM

118

Teora del Proceso

CMMI: Organizacin de las reas de proceso

El modelo de procesos CMMI tiene dos representaciones: la representacin continua y la representacin por etapas. Ambas representaciones constan de los mismos procesos, la diferencia estriba en la forma de interpretarlos.Los procesos involucrados en el modelo continuo estn clasificados en 4 categoras: Soporte, Gestin del Proyecto, Gestin del Proceso e Ingeniera. En el modelo por etapas los procesos estn clasificados por niveles de madurez. Estos conceptos sern ampliados en el Captulo de Mejora de Procesos.

119

Decision Analysis and Resolution Requirements Development

System Product Deliveries

Project Planning

Supplier AgreementManagement

Product Control

Products

Outcome & FeedbackProduct

Verification ValidationMeasurementand Analysis

Deficiencies

Directives, Constraints,

Contracting Activity Planning

Requirements DefinitionBudgeting Priority

Assessment & Certification

Integrated ProjectManagement

Project Monitoringand Control

Risk Management

TechnicalSolution

ProductIntegration

RequirementsManagement

ConfigurationManagement

Quality Assurance

Program ManagementTechnical Execution

ProcessFocus

ProcessDefinition Training

QuantitativeMgmt

ProcessPerformance

Innovation andDeployment

Process Maturation

Organizational Process Management

Mission Area Planning

ConcurrentFront-EndActivities

Causal Analysisand Resolution

Life Cycle Relationships

Mission Shortfalls

Integrated SupplierManagement

Integrated Teaming

Environment for

Integration

119

120

Teora del Proceso

Teora del Proceso


120

121

121

Ejemplo de teora de procesos

Proceso de Planificacin de TSP

Mejora del ProcesoMejora del ProcesoMejora del Proceso

Teora del Proceso

Aplicacin a un Plan de Proyecto

El propsito de este ejemplo, es presentar una descripcin detallada de un proceso. El proceso presentado es el proceso de planificacin del TSP. Se ha seleccionado por ser parte central de la asignatura.

121

122122

122

Ciclo de Vida TSP

122

Lanzamiento Ciclo 1

Estrategia 1Plan 1

Requisitos 1Diseo 1

Implementacin 1Pruebas 1

Post-Mortem 1

Lanzamiento Ciclo 2

Estrategia 2Plan 2

Requisitos 2Diseo 2


Post-Mortem 2

Declaracin de Necesidaddel Producto


Teora del Proceso

Ejemplo

La figura muestra como el TSPi utiliza varios ciclos de desarrollo para obtener el producto final. El ciclo 1 comienza con una presentacin, en la que el instructor describe los objetivos totales del producto. El equipo entonces completa los siete pasos del proceso del TSPi: estrategia, planificacin, requisitos, diseo, implementacin, prueba, y anlisis de resultados. En el ciclo 2, los ingenieros repiten los mismos pasos, pero esta vez mejorando el producto bsico obtenido en el ciclo 1. Si hubiese tiempo, ellos pueden aadir nuevas mejoras en ciclos posteriores.La Estrategia de Desarrollo CclicoCuando usted comienza una estrategia de desarrollo cclico, el mejor plan es empezar con la versin del producto viable. Al decidir el tamao y contenido de cada ciclo, usted debera considerar las restricciones siguientes.1. Cada ciclo producir una versin verificable que es un subconjunto adecuado del producto final.2. Cada ciclo ser lo suficientemente pequeo para que sea fcilmente desarrollado y probado en el tiempo disponible.3. Cuando se combinen, los productos del ciclo originarn el deseado producto final.El TSPi comienza por tener equipos que produzcan la estrategia de desarrollo. Se comienza tomando la mnima base razonable a desarrollar durante el primer ciclo. Luegose estima el tamao de las funciones que usted planea aadir en cada ciclo posterior. Este enfoque casi garantiza que usted completar el subconjunto inicial suficiente. Con los datos de este ciclo inicial, usted planificar ePactamente lo que aade en cada ciclo posterior. No diferenciar demasiado las funciones en los ciclos 2 y 3, no obstante, debido a que el calendario del curso proporciona menos tiempo para estos ciclos ms tardos.

123

123

Subactividades de Planificacin

Estrategia 1Plan 1

Requisitos 1Diseo 1


Post-Mortem 1

Lanzamiento Ciclo 1


Teora del Proceso

Ejemplo

La figura contiene los siguientes elementos de informacin.

A la izquierda las fases que componen un ciclo, segn TSP. A la derecha la representacin del proceso, en este caso de planificacin del primer ciclo.La representacin d

teoria de procesos

Documents