Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

INSTITUTO TECNOLOGICO DE NOGALES ISC

FUNDAMENTOS DE DESARROLLO DE SISTEMAS

NOMBRE: ERICK BURGOS AGUILAR

PROFESOR: ERIK MORALES ROMERO

UNIDAD IV: MODELOS DE PROCESO DE SOFTWARE

H. NOGALES SONORA A 16 DE NOVIEMBRE DEL 2011

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

Contenido
MODELO DE CASCADA ................................................................................... 3 MODELO ESPIRAL ........................................................................................... 7 MODELO INCREMENTAL............................................................................... 11 MODELO UNIFICADO..................................................................................... 13 Desarrollando aplicaciones informticas con el Proceso de Desarrollo Unificado (RUP) .................................................................................................... 15 PROCESO DEL SOFTWARE PERSONAL ..................................................... 18 BIBLIOGRAFIA ................................................................................................ 24

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

MODELO DE CASCADA
Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal secuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. La Figura 2.4 muestra el modelo lineal secuencial para la ingeniera del software. Modelado segn el ciclo de ingeniera convencional, el modelo lineal secuencial comprende las siguientes actividades: Ingeniera y modelado de Sistemas/Informacin. Como el software siempre forma parte de un sistema ms grande (o empresa), el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algn subgrupo de estos requisitos. Esta visin del sistema es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos. La ingeniera y el anlisis de sistemas comprenden los requisitos que se recogen en el nivel del sistema con una pequea parte de anlisis y de diseo. La ingeniera de informacin abarca los requisitos que se recogen en el nivel de empresa estratgico y en el nivel del rea de negocio.
1

Anlisis de los requisitos del software. El proceso de reunin de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero (analista ) del software debe comprender el dominio de informacin del software (descrito en el Captulo 1 l), as como la funcin requerida, comportamiento, rendimiento e interconexin.
1

Ingeniera de Software un enfoque practico (pressman), pg. 20

Fundamentos de Desarrollo de Sistemas Diseo.

Modelos de proceso de software

El diseo del software es realmente un proceso de muchos pasos que centra en cuatro atributos distintos de programa: estructura de datos, arquitectura software, representaciones de interfaz y detalle procedimental (algoritmo). proceso del diseo traduce requisitos en una representacin del software donde pueda evaluar su calidad antes de que comience la codificacin. Generacin de cdigo.

se de El se

El diseo se debe traducir en una forma legible por la mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo de una forma detallada, la generacin de cdigo se realiza mecnicamente. Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento. El software indudablemente sufrir cambios despus de ser entregado al cliente (una excepcin posible es el software empotrado). Se producirn cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o dispositivo perifrico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo. El modelo lineal secuencial es el paradigma ms antiguo y ms extensamente utilizado en la ingeniera del software. Sin embargo, la crtica del paradigma ha puesto en duda su eficacia [HAN95]. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial se incluyen:

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

1. Los proyectos reales raras veces siguen el modelo secuencial que Propone el modelo. Aunque el modelo lineal puede acoplar interaccin, lo hace indirectamente. Como resultado, los cambios pueden causar confusin cuando el equipo del proyecto comienza. 2. A menudo es difcil que el cliente exponga explcitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos. 3. El cliente debe tener paciencia. Una versin de trabajo del (los) programa(s) no estar disponible hasta que el proyecto est muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

MODELO ESPIRAL
El modelo en espiral, propuesto originalmente por Boehm [BOE88], es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En el modelo nieria del cliente espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteracciones, la version incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado.
2

El modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas regiorzes de tareas. Generalmente, existen entre tres y seis regiones de tareas. La Figura 2.8 representa un modelo en espiral que contiene seis regiones de tareas: ms sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto. El coste y la planificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de itecomunicacin con el cliente- las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente. planificacin- las

Ingeniera de Software un enfoque practico (pressman), pg. 24

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto. Anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos y de gestin. ingeniera- las tareas requeridas para construir una o ms representaciones de la aplicacin. construccin y accin- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentacin y prctica) evaluacin del cliente- las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.

Cada una de las regiones estn compuestas por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las caractersticas del proyecto que va a emprenderse. Para proyectos pequeos, el nmero de tareas de trabajo y su formalidad es bajo. Para proyectos mayores y ms crticos cada regin de tareas contiene areas de trabajo que se definen para lograr un nivel ms alto de formalidad. En todos los casos, se aplican las actividades de proteccin (por ejemplo: gestin de configuracin del software y garanta de calidad del software). Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificacin de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto. El coste y la planificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para completar el software. Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar difcil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la evaluacin del riesgo, y cuenta con esta habilidad para el xito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. Finalmente, el modelo no se ha utilizado tanto como los paradigmas lineales secuenciales o de construccin de prototipos. Todava tendrn que pasar muchos aos antes de que se determine con absluta certeza la eficacia de este nuevo e importante paradigma.

Fundamentos de Desarrollo de Sistemas software El modelo espiral WINWIN

Modelos de proceso de

El modelo en espiral tratado en la Seccion 2.7.2 sugiere una actividad del marco de trabajo que aborda la comunicacin con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar. Desgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociacin, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o caractersticas del sistema frente al coste y al tiempo de comercializacin. Las mejores negociaciones se esfuerzan en obtener victoria-victoria. Esto es, el cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista. El modelo en espiral WINWIN de Boehm [BOE98] define un conjunto de actividades de negociacin al principio de cada paso alrededor de la espiral. Ms que una simple actividad de comunicacin con el cliente, se definen las siguientes actividades: 1. Identificacin del sistema o subsistemas clave de los directivos. 2. Determinacin de las condiciones de victoria de los directivos. 3. Negociacin de las condiciones de victoria de los directivos para reunirlas en un conjunto de condicionesvictoria-victoria para todos los afectados (incluyendo el equipo del proyecto de software).

Ingeniera de Software un enfoque practico (pressman), pg. 26

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

Conseguidos completamente estos pasos iniciales se logra un resultado victoria-victoria, que ser el criterio clave para continuar con la definicin del sistema y del software. El modelo en espiral WINWIN se ilustra en la Figura 2.9.

Adems del nfasis realizado en la negociacin inicial, el modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin [BOE96], que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisin antes de continuar el proyecto de software. En esencia, los puntos de fijacin representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral. El primer punto de fijacin, llamado objetivos del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de ingeniera del software. Como ejemplo, de una parte de OCV, un conjunto de objetivos asociados a la definicin de los requisitos del producto/sistema del nivel ms alto. El segundo punto de fijacin, llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema. Como ejemplo, de una parte de la ACV, el equipo del proyecto de software debe demostrar que ha evaluado la funcionalidad de los componentes del software reutilizables y que ha considerado su impacto en las decisiones de arquitectura. La capacidad operativa inicial (COI) es el tercer punto de fijacin y representa un conjunto de objetivos asociados a la preparacin del software para la instalacin/distribucin, preparacin del lugar previamente a la instalacin, y la asistencia precisada de todas las partes que utilizar o mantendr el software.

10

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

MODELO INCREMENTAL
El modelo incrernental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos. Como muestra la Figura 2.7, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software [MDE93]. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podra extraer funciones de gestin de archivos bsicos y de produccin de documentos en el primer incremento; funciones de edicin ms sofisticadas y de produccin de documentos en el segundo incremento; correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de pgina en el cuarto. Se debera tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin detallada). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.
4

Ingeniera de Software un enfoque practico (pressman), pg. 23

11

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

El modelo de proceso incremental, como la construccin de prototipos (Seccin 2.5) y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la Construccin de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin. El desarrollo incremental es particularmente til cuando la dotacin de personal no est disponible para una implementacin completa en la fecha lmite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas.

12

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

MODELO UNIFICADO
Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un modelo de proceso basado en componentes para la ingeniera del software. El paradigma orientado a objetos enfatiza la creacin de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora. El modelo de desarrollo basado en componentes (Fig. 2.11) incorpora muchas de las caractersticas del modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un enfoque iterativo para la creacin del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software examinando los datos que se van a manejar por parte de la aplicacin y el algoritmo que se va a aplicar para conseguir el tratamientoI2. Los datos y los algoritmos correspondientes se empaquetan en una clase. Las clases creadas en los proyectos de ingeniera del software anteriores, se almacenan en una biblioteca de clases o diccionario de datos. Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya existen. En caso de que as fuera, se extraen de la biblioteca se vuelven a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los mtobos orientados a objetos (Captulos 2 1-23). Se compone as la primera iteracin de la aplicacin a construirse, mediante las clases extradas de la biblioteca y las clases nuevas construidas para cumplir las necesidades nicas de la aplicacin. El flujo del proceso vuelve a la espiral y volver a introducir por ltimo la iteracin ensambladora de componentes a travs de la actividad de ingeniera. El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste del proyecto y un ndice de productividad del 26.2, comparado con la norma de industria del 16.9 [YOU94]. Aunque estos resultados estn en funcin de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de software.
5

Ingeniera de Software un enfoque practico (pressman), pg. 28

13

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

El proceso unificado de desarrollo de software [JAC99] representa un nmero de modelos de desarrollo basados en componentes que han sido propuestos en la industria. Utilizando el Lenguaje de Modelado Unijcado (UML), el proceso unificado define los componentes que se utilizarn para construir el sistema y las interfaces que conectarn los componentes. Utilizando una combinacion del desarrollo incremental e iterativo, el proceso unificado define la funcin del sistema aplicando un enfoque basado en escenarios (desde el punto de vista de1 usuario). Entonces acopla la funcin con un marco de trabajo arquitectnico que identifica la forma que tomar el software.

14

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

Desarrollando aplicaciones informticas con el Proceso de Desarrollo Unificado (RUP)

Durante varios aos se ha utilizado el modelo tradicional en cascada, demostrando en la practica que no refleja en la realidad la complejidad inherente al proceso de desarrollo de software. Este problema es derivado de la naturaleza implcita de la estructura de este modelo, definido por una secuencia de grandes etapas que requieren alcanzar hitos que deben ser concluidos antes de continuar con la siguiente fase. Como una alternativa de solucin a este problema, se definieron posteriormente los modelos iterativos e incrementales que trabajan adecuadamente con niveles altos de riesgo, y permiten entregar liberaciones de software en etapas tempranas; tal es el caso del Proceso Unificado propuesto por IBM, que incluye prcticas claves y aspectos relacionados a la planeacin estratgica y administracin de riesgos; y actualmente guan de forma natural el proceso de desarrollo de software complejo por lo que ha sido considerado como un estandar el desarrollo de software en las empresas. El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentacin, garantizando el cumplimiento de ciertos estndares de calidad. Aunque con el inconveniente de generar mayor complejidad en los controles de administracin del mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo invertido en este aspecto. El proceso de desarrollo constituye un marco metodolgico que define en trminos de metas estratgicas, objetivos, actividades y artefactos (documentacin) requerido en cada fase de desarrollo. Esto permite enfocar esfuerzo de los recursos humanos en trminos de habilidades, competencias y capacidades a asumir roles especficos con responsabilidades bien definidas.

15

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

Estructura del ciclo de vida del proceso de desarrollo unificado

Fase de concepcin Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potenciales asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones. Fase de elaboracin En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Fase de construccin El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de transicin El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

16

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

Este tipo de metodologa no ha sido aplicada probablemente por su complejidad de administracin o desconocimiento de la misma, desaprovechando sus considerables ventajas respecto a los mtodos tradicionales. Por esto, es necesario entonces desarrollar mecanismos de apropiacin tecnolgica ms eficaces, que permitan mantener actualizadas las prcticas organizacionales y los marcos de referencia aqu mencionados. Es aqu, donde es necesario considerar que el conocimiento de la metodologa y desarrollo de habilidades de los analistas, programadores, administradores de bases de bases de datos y dems miembros del equipo de desarrollo, comienzan desde su preparacin universitaria donde es necesario conocer este enfoque y aplicarlo en proyectos en donde utilicen las guas de trabajo definidas en el RUP y desarrollen los artefactos asociados. De esta manera en la asignatura de anlisis y diseo de sistemas de informacin II, que se imparte a los estudiantes del programa educativo de Tecnologas de la informacin y comunicacin, se desarrolla un proyecto de simulacin tipo basado en la metodologa de trabajo del Proceso Unificado Rational, utilizando la herramienta CASE Rational Unified Process que es un sitio WEB en lnea que los alumnos consultan para entender los trminos en que debe ser realizada la documentacin y diseo de los programas informticos que construyen. Con el objetivo de promover el conocimiento de la estructura metodologa del RUP y en complemento al uso de herramienta CASE descrita anteriormente, se diseo una Tecnologa Educativa de Alto Impacto (TEAI) en su modalidad de material didctico que permite que los alumnos conozcan, comprendan y analicen la naturaleza iterativa de desarrollo de proyectos con el proceso unificado en relacin al avance estatus del proyecto y la evolucin de los artefactos generados. Con esta (TEAI) se busca que los estudiantes manipulen directamente la estructura del ciclo de vida del RUP, mediante el manejo de piezas adheribles al pizarrn le permiten identificar roles o artefactos por fases o por disciplinas disminuyendo la complejidad que resulta el trabajar por primera vez con procesos evolutivos promoviendo de la misma manera la participacin activa del alumno en la asimilacin de su propio conocimiento.

17

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

PROCESO DEL SOFTWARE PERSONAL

INTRODUCCIN Y ANTECEDENTES Entre las principales causas para que el proceso de desarrollo de software falle pueden ser: El personal de desarrollo no se involucra lo suficiente. No esta consciente de la verdadera importancia del proyecto. No se cuentan con los recursos necesarios Las practicas establecidas no son buenas. Esta claro que la produccin de software debe convertirse en un proceso disciplinado y aceptado por todos. En los aos 70 y 80 era popular la estrategia Prueba y arregla en la industria estadounidense. En estos aos se establece el control de procesos, que desde aqu ha ido enfocando todo avance en el enfoque de la calidad. Modelo de Capacidad de Maduracin (CMM) en 1987.

PROCESO DE SOFTWARE PERSONAL En el ao de 1995 el PSP fue propuesto por Watts Humphrey, este inicialmente estaba dirigido para estudiantes. Para 1997 con el lanzamiento del libro "An Introduction to the Personal Software Process" el PSP ya estaba destinado a los ingenieros. PSP se concentra en las prcticas de trabajo de los ingenieros en una forma individual. El PSP se caracteriza porque es de uso personal y se aplica a programas pequeos de menos de 10.000 lneas de cdigo. El PSP sirve para producir software de calidad, donde cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad. El PSP se centra en la administracin del tiempo y en la administracin de la calidad a travs de la eliminacin temprana de defectos. El PSP busca proporcionar un marco de trabajo para el personal involucrado en el proceso de desarrollo de software. PSP demuestra cmo manejar la calidad desde el principio del trabajo.

18

Fundamentos de Desarrollo de Sistemas software PRINCIPIOS DEL PSP

Modelos de proceso de

Cada ingeniero es esencialmente diferente (Cada uno se encarga de su trabajo). Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos. Los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos, esto mejorar la calidad. OBJETIVOS DE PSP Lograr una disciplina de mejora continua en el proceso de desarrollo. Medir, estimar, planificar, seguir y controlar el proceso de desarrollo. Mejorar la calidad del proceso de desarrollo. En general, PSP provee calidad y productividad. El tiempo ahorrado en el testeo en base a una mejor calidad ahorra entre un 20 a 40 % del desarrollo PRINCIPIOS DEL PSP Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes. Es ms eficiente prevenir defectos que encontrarlos y arreglarlos. La manera correcta de hacer las cosas es siempre la manera ms rpida y ms barata de hacer un trabajo. DESVENTAJAS DE APLICAR PSP El tiempo requerido para conocerlo El costo emocional por mantener una disciplina El ego del cambio en las costumbres VENTAJAS DE APLICAR PSP La idea de que ganamos en talento y habilidad La estimulacin por nuevas ideas Una estructura de trabajo de mejoramiento personal Tomar control del propio trabajo La sensacin de logro Una base mejorada para el trabajo en grupo (TSP) La conviccin de que es lo mejor que se puede hacer

19

Fundamentos de Desarrollo de Sistemas NIVELES PSP

Modelos de proceso de software

Para recalcar: PSP tiene un marco de proceso de evolucin similar al que tiene CMM. En el CMM un nivel de madurez slo se alcanza si se logran cumplir todas las KPAs (reas de procesos claves) que exige cada nivel. PSP solamente cubre de manera parcial estas KPAs debido a que es un complemento de CMM. Al PSP es ideal utilizarlo junto con CMM (no es obligatorio).

El PSP define cinco actividades del marco de trabajo: PLANEACIN. DISEO DE ALTO NIVEL REVISIN DEL DISEO DE ALTO NIVEL DESARROLLO ANLISIS DE RESULTADOS

20

Fundamentos de Desarrollo de Sistemas software Planeacin

Modelos de proceso de

Esta actividad selecciona requisitos, con base en ellos desarrolla el tamao y la estimacin de los recursos. Estimacin de los defectos. Creacin de un programa del proyecto. La planificacin proporciona una slida base para comprometerse a unas fechas de entrega. Estimacin del tiempo necesario. Diseo de Alto Nivel Se elabora especificaciones externas para los componentes construidos. Diseo de componentes. Construccin de prototipos si hay incertidumbre. Los elementos se registran y se rastrean. Desarrollo Diseo a nivel de componentes se refina y revisa. Se genera, revisa, compila y prueba el cdigo. Mediciones para todas las tareas importantes y los resultados de trabajo. Puede medirse en LOC (lneas de cdigo). Esto exige tener una forma normalizada de contar LOC, o de codificar.

21

Fundamentos de Desarrollo de Sistemas

Modelos de proceso de software

22

Fundamentos de Desarrollo de Sistemas software

Modelos de proceso de

23

Fundamentos de Desarrollo de Sistemas CONCLUSIONES

Modelos de proceso de software

La disciplina en el proceso de desarrollo de software es, sin lugar a dudas, uno de los elementos fundamentales para tal propsito debemos comenzar a entenderla y aplicarla desde el primer ao de la carrera. Con la introduccin de PSP desde los primeros aos y de forma gradual, los futuros ingenieros informticos del pas inferirn la necesidad de saber gestionar correctamente sus tiempos y compromisos, no solo para el trabajo que desempearn sino para otras facetas de su vida. Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. Los buenos productos no se obtienen por azar, sino como consecuencia de un esfuerzo positivo para hacer un trabajo de calidad.

BIBLIOGRAFIA
Ingenieria de software un enfoque practico Autor: pressman Edicin: quinta edicion

24