SlideShare una empresa de Scribd logo
Unidad 3 Los modelos de procesos de software 
Los modelos de procesos de software 
Para resolver los problemas reales de una industria, un ingeniero del software debe incorporar una 
estrategia de desarrollo que acompañe al proceso, métodos y tenga herramientas. Esta estrategia se 
llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de 
proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los 
métodos y las herramientas a utilizarse, los controles y entregas que se requieren. 
Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva 
particular. Alternativamente, a veces se usan los términos ciclo de vida y Modelo de ciclo de vida. 
Cada modelo describe una sucesión de fases y un encadenamiento entre ellas así como un bucle de 
resoluciones de problemas y estos se encuentran en distintas etapas. Según las fases y el modo en 
que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es más 
adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de características de 
éste. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a 
continuación. 
MODELO LINEAL SECUENCIAL (CASCADA) 
También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen en el "Modelo de 
cascada" ingeniado por Winston Royce, aunque omite los muchos bucles de este último. El Modelo 
Lineal Secuencial sugiere un enfoque sistemático o más bien secuencial del desarrollo de software 
que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y 
mantenimiento. El Modelo Lineal Secuencial acompaña las siguientes actividades: 
 Análisis de los requerimientos del software:Es la fase en la cual se reúnen todos los requisitos 
que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta 
y repasa dichos requisitos.
 Diseño:Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las 
representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un 
esbozo de lo solicitado y se documenta haciéndose parte del software. 
 Generación del código:Es la etapa en la cual se traduce el diseño para que sea comprensible 
por la máquina. Esta etapa va a depender estrechamente de lo detallado del diseño. 
 Pruebas:Esta etapa se centra en los procesos lógicos internos del software, asegurando que 
todas las sentencias se han comprobado, y en la detección de errores. 
 Mantenimiento:Debido a que el programa puede tener errores, puede no ser del completo 
agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto 
quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan 
algunos cambios. 
 Los responsables del desarrollo de software siempre se retrasan innecesariamente. Todo lo 
anteriormente expuesto es cierto pero este paradigma tiene un lugar bien definido e importante en 
el trabajo de la Ingeniería de Software aparte de proporcionar una plantilla en la que se encuentran 
métodos para análisis, diseño, codificación, pruebas y mantenimiento. Con todo y sus errores, sigue 
siendo el paradigma más utilizado en el desarrollo del software, siendo mucho mejor que un 
enfoque al azar. 
Características del modelo 
 Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre 
al modelo. 
 Cada fase genera documentación para la siguiente. Esta documentación debe ser aprobada. 
 Una fase no comienza hasta que la anterior ha terminado. 
 Requiere disponer de unos requisitos completos y precisos al principio del desarrollo. 
 Se disponga de unos requisitos completos y consistentes al principio del desarrollo. 
 Sea un proyecto pequeño, en el que el período de congelación de los requisitos es corto, o 
un proyecto con unos requisitos bastante estables. 
Ventajas: 
 Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que 
ninguno. 
 Facilita la gestión del desarrollo. 
Desventajas:
 En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito 
inalcanzable, Los usuarios no pueden imaginarse lo que quieren hasta que no ven un sistema 
funcionando. 
 Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo 
cambia. 
 El usuario debe esperar mucho tiempo hasta ver los resultados 
 Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases siguientes 
con un efecto conocido como bola de nieve. 
 Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y 
éste recae, en su mayor parte. 
Este modelo es ampliamente utilizado en los sistemas gubernamentales de gran tamaño, en especial 
en el Departamento de Defensa de los Estados Unidos (DOD). 
Modelo Incremental 
El proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la 
producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas 
otras formas de programación. Con esto se mantiene al cliente en constante contacto con los 
resultados obtenidos en cada incremento.Es el mismo cliente el que incluye o desecha elementos al 
final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso 
se repite hasta que se elabore el producto completo. 
De esta forma el tiempo de entrega se reduce considerablemente. 
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva 
pero se diferencia de aquellos en que al final de cada incremento se entrega un producto 
completamente operacional. 
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal 
suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada 
incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear
para gestionar riesgos técnicos. 
El Modelo Incremental se puede ver aquí en forma grafica: 
 Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. 
 El usuario se involucra más. 
 Difícil de evaluar el coste total. 
 Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como 
un todo. 
 Requiere gestores experimentados. 
 Los errores en los requisitos se detectan tarde. 
 El resultado puede ser muy positivo. 
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus 
desventajas sólo al ámbito de cada incremento. 
 · Permite entregar al cliente un producto más rápido en comparación del modelo de cascada. 
 · Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos. 
 · Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo 
como técnico. 
Desventajas: 
 El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto 
nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos. 
 Requiere de mucha planeación, tanto administrativa como técnica. 
 Requiere de metas claras para conocer el estado del proyecto. 
El Proceso Unificado de Desarrollo de Software (RUP) 
El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran 
cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos. 
Provee un enfoque disciplinado en la asignación de tareas y resposabilidades dentro de una 
organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que 
satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. 
El Proceso Unificado tiene dos dimensiones : 
 Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del 
proceso a lo largo de su desenvolvimiento 
 Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera 
lógica de acuerdo a su naturaleza. 
 La primera dimensión representa el aspecto dinámico del proceso conforme se va 
desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones). 
 La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en 
términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. 
El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en 
construcción está hecho de componentes de software interconectados por medio de interfaces bien 
definidas (well-defined interfaces).El Proceso Unificado usa el Lenguaje de Modelado Unificado 
(UML) en la preparación de todos los planos del sistema. De hecho, UML es una parte integral del 
Proceso Unificado, fueron desarrollados a la par. 
El Proceso Unificado es dirigido por casos de uso. 
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema 
exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos. El término usuario 
se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término 
usuario representa algo o alguien que interactúa con el sistema por desarrollar. 
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de 
valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos 
constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este 
modelo reemplaza la tradicional especificación funcional del sistema. Una especificación funcional 
tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La 
estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por 
cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en
términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que 
tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los 
requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen 
el proceso de desarrollo. 
Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son 
desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura 
del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al 
arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. 
Proceso de Software Personal 
Proceso de Software Personal. Se puede considerar como la guía de trabajo personal para ingenieros 
de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad 
de procesos que implica la medición cualitativa y mejora de procesos. El Personal Software Process, 
conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto 
de Ingeniería del Software(SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les 
permite mejorar la forma en la que construyen software. Considerando aspectos como la 
planeación, calidad, estimación de costos y productividad, PSP es una metodología que vale la pena 
revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de 
software que desarrolla dentro de un contexto de trabajo individual. 
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso 
de desarrollo de un producto de software, están puntualmente definidas en un conjunto de 
documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace 
mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito 
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará 
en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de 
PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada 
uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus
debilidades, y crecer a través de un proceso de autoaprendizaje y auto mejora. 
La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos que el producto 
de software contiene. 
En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de software, dentro 
de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicación y 
coordinación de los equipos de trabajo. 
ventajas y desventajas 
 PSP es una alternativa, de las muchas que han surgido recientemente, para mejorar el 
proceso de desarrollo de software. Más que clasificar un conjunto de sentencias como ventajas o 
desventajas, a continuación se citan algunas características: 
 PSP es una metodología basada en estimación. La estimación permite saber cuándo y cómo 
se desarrollan las tareas de un proceso, por lo que podría citarse como un aspecto importante de 
esta metodología el estar basada en métricas y estimaciones. 
 La información de las métricas y estimaciones se utiliza para evaluar y mejorar procesos 
futuros. PSP parte de la premisa que, si el ingeniero de software conoce sus fortalezas y debilidades, 
puede establecer las acciones necesarias para erradicar o explotar los aspectos identificados en la 
forma en que desarrolla software.Aunque lo mencionado en el punto anterior podría sonar bastante 
atractivo, la forma de llegar a ese auto conocimiento puede resultar tediosa y, en el peor de los casos, 
una pesadilla para el desarrollador. Salvo muy pocas excepciones, los ingenieros de software nunca 
realizan procedimientos formales para conocer la forma en que trabajan, no saben con exactitud 
cuántas líneas de código generan por hora, cuánto tiempo invierten al corregir un error, cuánto 
tiempo invierten en pruebas, etcétera. 
 Los pasos de registro de información a detalle en el nivel de medición pueden resultar 
frustrantes cuando se tiene presión de tiempo. 
 Aún no existe una herramienta automatizada que facilite el registro y análisis de datos 
generados por la aplicación de PSP. 
Conclusion: 
En este temas comprendi y apendi a como poder implementar un método adecuado para el 
desarrollo de un software. Ya que el desarrollo del software al igual que la codificación es muy 
importante ya que conello podremos seguir de manera adecuada el procesó de su desarrollo.
Publicado por andhy h palma en 11:29

Más contenido relacionado

La actualidad más candente

Curso Uml 3.2 Proceso Unificado
Curso Uml   3.2 Proceso UnificadoCurso Uml   3.2 Proceso Unificado
Curso Uml 3.2 Proceso Unificado
Emilio Aviles Avila
 
Modelo De Cascada
Modelo De CascadaModelo De Cascada
Modelo De Cascada
weysiba
 
El proceso unificado
El proceso unificadoEl proceso unificado
El proceso unificado
Pablo D. Torres D.
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
Juan Pablo Bustos Thames
 
Modelo xp para desarrollo de proyecto
Modelo xp para desarrollo de proyectoModelo xp para desarrollo de proyecto
Modelo xp para desarrollo de proyecto
Johita Guerrero
 
Modelos de Desarrollo
Modelos de DesarrolloModelos de Desarrollo
Modelos de Desarrollo
ALLSOFT
 
MODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWAREMODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWARE
Rocio Castellanos
 
Jhostin vasquez modelos de software
Jhostin vasquez   modelos de softwareJhostin vasquez   modelos de software
Jhostin vasquez modelos de software
jhostinvasquez
 
Modelos de desarrollo rápido de software
Modelos de desarrollo rápido de softwareModelos de desarrollo rápido de software
Modelos de desarrollo rápido de software
Juan Pablo Bustos Thames
 
Proceso ( software )
Proceso ( software )Proceso ( software )
Proceso ( software )
em3marquez
 
Modelos Prescriptivos del Desarrollo del Sistema de Información
Modelos Prescriptivos del Desarrollo del Sistema de InformaciónModelos Prescriptivos del Desarrollo del Sistema de Información
Modelos Prescriptivos del Desarrollo del Sistema de Información
Isaias Toledo
 
Grupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwareGrupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-software
PrimoLaura
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
mendez45
 
Metodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacionMetodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacion
caroyu
 
4. Desarrollo ágil de software
4. Desarrollo ágil de software4. Desarrollo ágil de software
4. Desarrollo ágil de software
Coesi Consultoria
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
angelicasolishernnde
 
Modelo de prototipo
Modelo de prototipoModelo de prototipo
Modelo de prototipo
yanezcabrera
 
Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software
Juan C. S. Suárez
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
Radel Fuentes
 
Modelos concurrentes
Modelos concurrentesModelos concurrentes
Modelos concurrentes
Juan Acevedo Solis
 

La actualidad más candente (20)

Curso Uml 3.2 Proceso Unificado
Curso Uml   3.2 Proceso UnificadoCurso Uml   3.2 Proceso Unificado
Curso Uml 3.2 Proceso Unificado
 
Modelo De Cascada
Modelo De CascadaModelo De Cascada
Modelo De Cascada
 
El proceso unificado
El proceso unificadoEl proceso unificado
El proceso unificado
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
 
Modelo xp para desarrollo de proyecto
Modelo xp para desarrollo de proyectoModelo xp para desarrollo de proyecto
Modelo xp para desarrollo de proyecto
 
Modelos de Desarrollo
Modelos de DesarrolloModelos de Desarrollo
Modelos de Desarrollo
 
MODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWAREMODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWARE
 
Jhostin vasquez modelos de software
Jhostin vasquez   modelos de softwareJhostin vasquez   modelos de software
Jhostin vasquez modelos de software
 
Modelos de desarrollo rápido de software
Modelos de desarrollo rápido de softwareModelos de desarrollo rápido de software
Modelos de desarrollo rápido de software
 
Proceso ( software )
Proceso ( software )Proceso ( software )
Proceso ( software )
 
Modelos Prescriptivos del Desarrollo del Sistema de Información
Modelos Prescriptivos del Desarrollo del Sistema de InformaciónModelos Prescriptivos del Desarrollo del Sistema de Información
Modelos Prescriptivos del Desarrollo del Sistema de Información
 
Grupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwareGrupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-software
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
 
Metodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacionMetodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacion
 
4. Desarrollo ágil de software
4. Desarrollo ágil de software4. Desarrollo ágil de software
4. Desarrollo ágil de software
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
 
Modelo de prototipo
Modelo de prototipoModelo de prototipo
Modelo de prototipo
 
Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
 
Modelos concurrentes
Modelos concurrentesModelos concurrentes
Modelos concurrentes
 

Similar a Unidad 3 los modelos de procesos de software

Modelos de Desarrollo del Software
Modelos de Desarrollo del SoftwareModelos de Desarrollo del Software
Modelos de Desarrollo del Software
GianlucaCastellano1
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
Jazmin Cr
 
prueva
pruevaprueva
prueva
1081913395
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
BibliotecaenlineaUNI
 
SDLC.pptx
SDLC.pptxSDLC.pptx
SDLC.pptx
Andrés Campos
 
Trabajo de sistemas de software
Trabajo de sistemas de softwareTrabajo de sistemas de software
Trabajo de sistemas de software
JhonJairoPerez
 
Metodología de desarrollo de software
Metodología de desarrollo de softwareMetodología de desarrollo de software
Metodología de desarrollo de software
Abner Garcia
 
AMSI
AMSIAMSI
Modelos de proceso del software
Modelos de proceso del softwareModelos de proceso del software
Modelos de proceso del software
Diego Llusco
 
Ciclo de Vida de un Software.pdf
Ciclo de Vida de un Software.pdfCiclo de Vida de un Software.pdf
Ciclo de Vida de un Software.pdf
Instituto Profesional Inacap
 
ciclo_de_vida_software
ciclo_de_vida_softwareciclo_de_vida_software
ciclo_de_vida_software
ArielAlexanderRavest
 
Proceso del software (Metodos Agiles)
Proceso del software (Metodos Agiles)Proceso del software (Metodos Agiles)
Proceso del software (Metodos Agiles)
Ares Atzarel Hernández Rodríguez
 
Proceso del software
Proceso del softwareProceso del software
Proceso del software
Juan Avendaño
 
metodologia
metodologia metodologia
metodologia
germaniabetty
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
Alejandro Silva
 
Modelos de Desarrollo de Software
Modelos de Desarrollo de SoftwareModelos de Desarrollo de Software
Modelos de Desarrollo de Software
PabloMiguelVillamiza
 
Presentación 162 modelos de proceso de software
Presentación 162 modelos de proceso de softwarePresentación 162 modelos de proceso de software
Presentación 162 modelos de proceso de software
Reset_the_cover
 
Modelos del desarrollo del software gabriela brito
Modelos del desarrollo del software   gabriela britoModelos del desarrollo del software   gabriela brito
Modelos del desarrollo del software gabriela brito
GabBrito
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_software
Miguel Castro
 

Similar a Unidad 3 los modelos de procesos de software (20)

Modelos de Desarrollo del Software
Modelos de Desarrollo del SoftwareModelos de Desarrollo del Software
Modelos de Desarrollo del Software
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
 
prueva
pruevaprueva
prueva
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
 
SDLC.pptx
SDLC.pptxSDLC.pptx
SDLC.pptx
 
Trabajo de sistemas de software
Trabajo de sistemas de softwareTrabajo de sistemas de software
Trabajo de sistemas de software
 
Metodología de desarrollo de software
Metodología de desarrollo de softwareMetodología de desarrollo de software
Metodología de desarrollo de software
 
AMSI
AMSIAMSI
AMSI
 
Modelos de proceso del software
Modelos de proceso del softwareModelos de proceso del software
Modelos de proceso del software
 
Ciclo de Vida de un Software.pdf
Ciclo de Vida de un Software.pdfCiclo de Vida de un Software.pdf
Ciclo de Vida de un Software.pdf
 
ciclo_de_vida_software
ciclo_de_vida_softwareciclo_de_vida_software
ciclo_de_vida_software
 
Proceso del software (Metodos Agiles)
Proceso del software (Metodos Agiles)Proceso del software (Metodos Agiles)
Proceso del software (Metodos Agiles)
 
Proceso del software
Proceso del softwareProceso del software
Proceso del software
 
metodologia
metodologia metodologia
metodologia
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
 
Modelos de Desarrollo de Software
Modelos de Desarrollo de SoftwareModelos de Desarrollo de Software
Modelos de Desarrollo de Software
 
Presentación 162 modelos de proceso de software
Presentación 162 modelos de proceso de softwarePresentación 162 modelos de proceso de software
Presentación 162 modelos de proceso de software
 
Modelos del desarrollo del software gabriela brito
Modelos del desarrollo del software   gabriela britoModelos del desarrollo del software   gabriela brito
Modelos del desarrollo del software gabriela brito
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_software
 

Más de Andhy H Palma

Paradigmas de la ingeniería de software
Paradigmas de la ingeniería de softwareParadigmas de la ingeniería de software
Paradigmas de la ingeniería de software
Andhy H Palma
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
Andhy H Palma
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
Andhy H Palma
 
Unidad 5 graficación
Unidad 5 graficaciónUnidad 5 graficación
Unidad 5 graficación
Andhy H Palma
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficación
Andhy H Palma
 
Unidad 3 graficacion
Unidad 3 graficacionUnidad 3 graficacion
Unidad 3 graficacion
Andhy H Palma
 
generacion de números pseudoaleatorios tecnicas
generacion de números  pseudoaleatorios tecnicasgeneracion de números  pseudoaleatorios tecnicas
generacion de números pseudoaleatorios tecnicas
Andhy H Palma
 
Modelo de procesos
Modelo de procesosModelo de procesos
Modelo de procesos
Andhy H Palma
 
Paradigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwareeParadigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwaree
Andhy H Palma
 

Más de Andhy H Palma (9)

Paradigmas de la ingeniería de software
Paradigmas de la ingeniería de softwareParadigmas de la ingeniería de software
Paradigmas de la ingeniería de software
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
 
Unidad 5 graficación
Unidad 5 graficaciónUnidad 5 graficación
Unidad 5 graficación
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficación
 
Unidad 3 graficacion
Unidad 3 graficacionUnidad 3 graficacion
Unidad 3 graficacion
 
generacion de números pseudoaleatorios tecnicas
generacion de números  pseudoaleatorios tecnicasgeneracion de números  pseudoaleatorios tecnicas
generacion de números pseudoaleatorios tecnicas
 
Modelo de procesos
Modelo de procesosModelo de procesos
Modelo de procesos
 
Paradigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwareeParadigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwaree
 

Último

El uso de las tics en la vida cotidiana y en otros hábitos
El uso de las tics en la vida cotidiana y en otros  hábitosEl uso de las tics en la vida cotidiana y en otros  hábitos
El uso de las tics en la vida cotidiana y en otros hábitos
241560435
 
Actividad integradora 6 curso multimedia
Actividad integradora 6 curso multimediaActividad integradora 6 curso multimedia
Actividad integradora 6 curso multimedia
AliiIxh
 
APLICACIONES DE INTERNET-INFORMATICA.pptx
APLICACIONES DE INTERNET-INFORMATICA.pptxAPLICACIONES DE INTERNET-INFORMATICA.pptx
APLICACIONES DE INTERNET-INFORMATICA.pptx
cpadua713
 
SLIDESHARE, qué es, ventajas y desventajas
SLIDESHARE, qué es, ventajas y desventajasSLIDESHARE, qué es, ventajas y desventajas
SLIDESHARE, qué es, ventajas y desventajas
ruthechepurizaca
 
Encuentra ese factor X que te haga mejorar como SEO #SOB24
Encuentra ese factor X que te haga mejorar como SEO  #SOB24Encuentra ese factor X que te haga mejorar como SEO  #SOB24
Encuentra ese factor X que te haga mejorar como SEO #SOB24
MJ Cachón Yáñez
 
COMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNET
COMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNETCOMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNET
COMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNET
Kevin Aguilar Garcia
 
Análisis de Crowdfunding con el maestro Tapia de Artes
Análisis de Crowdfunding con el maestro Tapia de ArtesAnálisis de Crowdfunding con el maestro Tapia de Artes
Análisis de Crowdfunding con el maestro Tapia de Artes
al050121024
 
Sesión N°10 / Monografía sobre la inteligencia artifical
Sesión N°10 / Monografía sobre la inteligencia artificalSesión N°10 / Monografía sobre la inteligencia artifical
Sesión N°10 / Monografía sobre la inteligencia artifical
Angeles del Rosario Escobar Mendoza
 
extraccion-de-alcaloides-de-la-planta-de-coca.pdf
extraccion-de-alcaloides-de-la-planta-de-coca.pdfextraccion-de-alcaloides-de-la-planta-de-coca.pdf
extraccion-de-alcaloides-de-la-planta-de-coca.pdf
JENNYMARITZAHUILLCAR
 
LA NUBE YULIANA GABRIELA CORI NINARAQUE.pdf
LA NUBE YULIANA GABRIELA CORI NINARAQUE.pdfLA NUBE YULIANA GABRIELA CORI NINARAQUE.pdf
LA NUBE YULIANA GABRIELA CORI NINARAQUE.pdf
YulianaCori
 
TRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdf
TRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdfTRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdf
TRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdf
anacruztone06
 
Encuentra ese factor X que te haga mejorar como SEO #SOB24
Encuentra ese factor X que te haga mejorar como SEO  #SOB24Encuentra ese factor X que te haga mejorar como SEO  #SOB24
Encuentra ese factor X que te haga mejorar como SEO #SOB24
ssuser82c1d6
 
aplicaciones de internet Google.20240pdf
aplicaciones de internet Google.20240pdfaplicaciones de internet Google.20240pdf
aplicaciones de internet Google.20240pdf
jordanovillacorta09
 
COMO EVOLUCIONO LAS WEB EN PLENO 2024.docx
COMO EVOLUCIONO LAS WEB EN PLENO 2024.docxCOMO EVOLUCIONO LAS WEB EN PLENO 2024.docx
COMO EVOLUCIONO LAS WEB EN PLENO 2024.docx
Jean Apellidos
 
- El Cerebro Femenino como se desarrolla
- El Cerebro Femenino como se desarrolla- El Cerebro Femenino como se desarrolla
- El Cerebro Femenino como se desarrolla
BERTILAARTEAGATOLENT1
 
importancia de la organizacion moderna jjj
importancia de la organizacion moderna jjjimportancia de la organizacion moderna jjj
importancia de la organizacion moderna jjj
gallegoscarneronelso
 
Oruam, el pequeño y el gran carismatico mago
Oruam, el pequeño y el gran carismatico magoOruam, el pequeño y el gran carismatico mago
Oruam, el pequeño y el gran carismatico mago
ChichipeSevillaJhost
 
Herramientas de la web 2.0.pptx
Herramientas    de     la    web    2.0.pptxHerramientas    de     la    web    2.0.pptx
Herramientas de la web 2.0.pptx
anittaeunice
 
USOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdf
USOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdfUSOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdf
USOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdf
politamazznaa
 
Copia de LaHoja_20240527_200357_0000.pptx
Copia de LaHoja_20240527_200357_0000.pptxCopia de LaHoja_20240527_200357_0000.pptx
Copia de LaHoja_20240527_200357_0000.pptx
jcoloniapu
 

Último (20)

El uso de las tics en la vida cotidiana y en otros hábitos
El uso de las tics en la vida cotidiana y en otros  hábitosEl uso de las tics en la vida cotidiana y en otros  hábitos
El uso de las tics en la vida cotidiana y en otros hábitos
 
Actividad integradora 6 curso multimedia
Actividad integradora 6 curso multimediaActividad integradora 6 curso multimedia
Actividad integradora 6 curso multimedia
 
APLICACIONES DE INTERNET-INFORMATICA.pptx
APLICACIONES DE INTERNET-INFORMATICA.pptxAPLICACIONES DE INTERNET-INFORMATICA.pptx
APLICACIONES DE INTERNET-INFORMATICA.pptx
 
SLIDESHARE, qué es, ventajas y desventajas
SLIDESHARE, qué es, ventajas y desventajasSLIDESHARE, qué es, ventajas y desventajas
SLIDESHARE, qué es, ventajas y desventajas
 
Encuentra ese factor X que te haga mejorar como SEO #SOB24
Encuentra ese factor X que te haga mejorar como SEO  #SOB24Encuentra ese factor X que te haga mejorar como SEO  #SOB24
Encuentra ese factor X que te haga mejorar como SEO #SOB24
 
COMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNET
COMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNETCOMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNET
COMUNIDADES DE APRENDIZAJE EN EL CURSO DE APLICACIONES PARA INTERNET
 
Análisis de Crowdfunding con el maestro Tapia de Artes
Análisis de Crowdfunding con el maestro Tapia de ArtesAnálisis de Crowdfunding con el maestro Tapia de Artes
Análisis de Crowdfunding con el maestro Tapia de Artes
 
Sesión N°10 / Monografía sobre la inteligencia artifical
Sesión N°10 / Monografía sobre la inteligencia artificalSesión N°10 / Monografía sobre la inteligencia artifical
Sesión N°10 / Monografía sobre la inteligencia artifical
 
extraccion-de-alcaloides-de-la-planta-de-coca.pdf
extraccion-de-alcaloides-de-la-planta-de-coca.pdfextraccion-de-alcaloides-de-la-planta-de-coca.pdf
extraccion-de-alcaloides-de-la-planta-de-coca.pdf
 
LA NUBE YULIANA GABRIELA CORI NINARAQUE.pdf
LA NUBE YULIANA GABRIELA CORI NINARAQUE.pdfLA NUBE YULIANA GABRIELA CORI NINARAQUE.pdf
LA NUBE YULIANA GABRIELA CORI NINARAQUE.pdf
 
TRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdf
TRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdfTRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdf
TRABAJO APLICACIONES EN INTERNET - Ana cruz tone.pdf
 
Encuentra ese factor X que te haga mejorar como SEO #SOB24
Encuentra ese factor X que te haga mejorar como SEO  #SOB24Encuentra ese factor X que te haga mejorar como SEO  #SOB24
Encuentra ese factor X que te haga mejorar como SEO #SOB24
 
aplicaciones de internet Google.20240pdf
aplicaciones de internet Google.20240pdfaplicaciones de internet Google.20240pdf
aplicaciones de internet Google.20240pdf
 
COMO EVOLUCIONO LAS WEB EN PLENO 2024.docx
COMO EVOLUCIONO LAS WEB EN PLENO 2024.docxCOMO EVOLUCIONO LAS WEB EN PLENO 2024.docx
COMO EVOLUCIONO LAS WEB EN PLENO 2024.docx
 
- El Cerebro Femenino como se desarrolla
- El Cerebro Femenino como se desarrolla- El Cerebro Femenino como se desarrolla
- El Cerebro Femenino como se desarrolla
 
importancia de la organizacion moderna jjj
importancia de la organizacion moderna jjjimportancia de la organizacion moderna jjj
importancia de la organizacion moderna jjj
 
Oruam, el pequeño y el gran carismatico mago
Oruam, el pequeño y el gran carismatico magoOruam, el pequeño y el gran carismatico mago
Oruam, el pequeño y el gran carismatico mago
 
Herramientas de la web 2.0.pptx
Herramientas    de     la    web    2.0.pptxHerramientas    de     la    web    2.0.pptx
Herramientas de la web 2.0.pptx
 
USOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdf
USOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdfUSOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdf
USOS_Y_TIPOS_DE_APLICACIONES_MOVILES_removed.pdf
 
Copia de LaHoja_20240527_200357_0000.pptx
Copia de LaHoja_20240527_200357_0000.pptxCopia de LaHoja_20240527_200357_0000.pptx
Copia de LaHoja_20240527_200357_0000.pptx
 

Unidad 3 los modelos de procesos de software

  • 1. Unidad 3 Los modelos de procesos de software Los modelos de procesos de software Para resolver los problemas reales de una industria, un ingeniero del software debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y tenga herramientas. Esta estrategia se llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, los controles y entregas que se requieren. Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva particular. Alternativamente, a veces se usan los términos ciclo de vida y Modelo de ciclo de vida. Cada modelo describe una sucesión de fases y un encadenamiento entre ellas así como un bucle de resoluciones de problemas y estos se encuentran en distintas etapas. Según las fases y el modo en que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es más adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de características de éste. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a continuación. MODELO LINEAL SECUENCIAL (CASCADA) También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen en el "Modelo de cascada" ingeniado por Winston Royce, aunque omite los muchos bucles de este último. El Modelo Lineal Secuencial sugiere un enfoque sistemático o más bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. El Modelo Lineal Secuencial acompaña las siguientes actividades:  Análisis de los requerimientos del software:Es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos.
  • 2.  Diseño:Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta haciéndose parte del software.  Generación del código:Es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina. Esta etapa va a depender estrechamente de lo detallado del diseño.  Pruebas:Esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en la detección de errores.  Mantenimiento:Debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios.  Los responsables del desarrollo de software siempre se retrasan innecesariamente. Todo lo anteriormente expuesto es cierto pero este paradigma tiene un lugar bien definido e importante en el trabajo de la Ingeniería de Software aparte de proporcionar una plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebas y mantenimiento. Con todo y sus errores, sigue siendo el paradigma más utilizado en el desarrollo del software, siendo mucho mejor que un enfoque al azar. Características del modelo  Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre al modelo.  Cada fase genera documentación para la siguiente. Esta documentación debe ser aprobada.  Una fase no comienza hasta que la anterior ha terminado.  Requiere disponer de unos requisitos completos y precisos al principio del desarrollo.  Se disponga de unos requisitos completos y consistentes al principio del desarrollo.  Sea un proyecto pequeño, en el que el período de congelación de los requisitos es corto, o un proyecto con unos requisitos bastante estables. Ventajas:  Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno.  Facilita la gestión del desarrollo. Desventajas:
  • 3.  En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable, Los usuarios no pueden imaginarse lo que quieren hasta que no ven un sistema funcionando.  Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo cambia.  El usuario debe esperar mucho tiempo hasta ver los resultados  Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases siguientes con un efecto conocido como bola de nieve.  Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y éste recae, en su mayor parte. Este modelo es ampliamente utilizado en los sistemas gubernamentales de gran tamaño, en especial en el Departamento de Defensa de los Estados Unidos (DOD). Modelo Incremental El proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear
  • 4. para gestionar riesgos técnicos. El Modelo Incremental se puede ver aquí en forma grafica:  Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.  El usuario se involucra más.  Difícil de evaluar el coste total.  Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.  Requiere gestores experimentados.  Los errores en los requisitos se detectan tarde.  El resultado puede ser muy positivo. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.  · Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.  · Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.  · Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. Desventajas:  El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.  Requiere de mucha planeación, tanto administrativa como técnica.  Requiere de metas claras para conocer el estado del proyecto. El Proceso Unificado de Desarrollo de Software (RUP) El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de
  • 5. organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos. Provee un enfoque disciplinado en la asignación de tareas y resposabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. El Proceso Unificado tiene dos dimensiones :  Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento  Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza.  La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).  La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en construcción está hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces).El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par. El Proceso Unificado es dirigido por casos de uso. Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos. El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término usuario representa algo o alguien que interactúa con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación funcional del sistema. Una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en
  • 6. términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo. Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. Proceso de Software Personal Proceso de Software Personal. Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos. El Personal Software Process, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software(SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad, PSP es una metodología que vale la pena revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo individual. En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus
  • 7. debilidades, y crecer a través de un proceso de autoaprendizaje y auto mejora. La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos que el producto de software contiene. En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de software, dentro de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicación y coordinación de los equipos de trabajo. ventajas y desventajas  PSP es una alternativa, de las muchas que han surgido recientemente, para mejorar el proceso de desarrollo de software. Más que clasificar un conjunto de sentencias como ventajas o desventajas, a continuación se citan algunas características:  PSP es una metodología basada en estimación. La estimación permite saber cuándo y cómo se desarrollan las tareas de un proceso, por lo que podría citarse como un aspecto importante de esta metodología el estar basada en métricas y estimaciones.  La información de las métricas y estimaciones se utiliza para evaluar y mejorar procesos futuros. PSP parte de la premisa que, si el ingeniero de software conoce sus fortalezas y debilidades, puede establecer las acciones necesarias para erradicar o explotar los aspectos identificados en la forma en que desarrolla software.Aunque lo mencionado en el punto anterior podría sonar bastante atractivo, la forma de llegar a ese auto conocimiento puede resultar tediosa y, en el peor de los casos, una pesadilla para el desarrollador. Salvo muy pocas excepciones, los ingenieros de software nunca realizan procedimientos formales para conocer la forma en que trabajan, no saben con exactitud cuántas líneas de código generan por hora, cuánto tiempo invierten al corregir un error, cuánto tiempo invierten en pruebas, etcétera.  Los pasos de registro de información a detalle en el nivel de medición pueden resultar frustrantes cuando se tiene presión de tiempo.  Aún no existe una herramienta automatizada que facilite el registro y análisis de datos generados por la aplicación de PSP. Conclusion: En este temas comprendi y apendi a como poder implementar un método adecuado para el desarrollo de un software. Ya que el desarrollo del software al igual que la codificación es muy importante ya que conello podremos seguir de manera adecuada el procesó de su desarrollo.
  • 8. Publicado por andhy h palma en 11:29