UNIVERSIDAD TECNOLÓGICA DE SANTIAGO

(UTESA)

ESTUDIANTE:
YORLENY ENCARNACION FELIZ

MATRICULA:
2-18-6641

TEMA:
UNIDAD III Y IV

ASIGNATURA:
INGERNIERIA DE SOFWARE

PROFESOR:
SAUL ESTEVEZ

FECHA: 22/03/2023
 TEMARIO

● INTRODUCCIÓN

● UNIDAD III

● UNIDAD IV

● CONCLUSIÓN
 INTRODUCCIÓN

En este trabajo tendremos una visualización de los temas de la unidad III y IV.
La unidad III El modelo de procesos de software, esta habla de los diferentes
modelos, y sus características, rasgos técnicos, ventajas y desventajas y proceso
unificado de desarrollo de software entre otros.

La unidad IV Análisis del proyecto de software, trata de los diferentes pasos para
ejecutar un análisis de proyecto de software.
UNIDAD 3 LOS MODELOS DE PROCESOS DE SOFTWARE LOS
MODELOS DE PROCESOS DE SOFTWARE :

Para resolver problemas prácticos en la industria, los ingenieros de software deben

incorporar estrategias de desarrollo que acompañen a los procesos y métodos.

Y hay herramientas. Esta estrategia se denomina modelo de proceso o paradigma de

ingeniería de software. Se elige un modelo de proceso de ingeniería de software en
función de la naturaleza del proyecto y la aplicación, los métodos y herramientas que se
utilizarán, los controles que se probarán y los entregables requiere que cada modelo sea
una descripción de un proceso de software presentado desde cierto ángulo.

Los términos ciclo de vida y modelo de ciclo de vida a veces se usan alternativamente.

Vida. Cada modelo describe una serie de etapas y las cadenas entre ellas y el ciclo de
resolución de problemas que se encuentran en diferentes etapas. Según la etapa y la
forma en que se produzca esta conexión, disponemos de diferentes modelos de
procesos. Dependiendo del conjunto de características del proyecto, un modelo es más
adecuado para el desarrollo del proyecto que el otro. Hay varios modelos diferentes,
incluidos los que se describen a continuación:

Modelo lineal secuencial:

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

seacomprensible 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 deerrores.

Mantenimiento: Debido a que el programa puede tener errores, puede no ser

delcompleto 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 periodo 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
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.

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 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.

RIESGOS TÉCNICOS:
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 solo 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 responsabilidades
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 el 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
termino usuario
se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este
contexto, el termino 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 tengan. 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 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, la 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 generara 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 estos, 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 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 al 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 cuantas 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.

UNIDAD IV ANÁLISIS DEL PROYECTO DE SOFTWARE

Modelado: análisis, diseño, documentación.

Análisis:
Pressman establece que la tarea del análisis de requisitos es un proceso de
descubrimiento, refinamiento, modelado y especificación. Se refina en detalle el
ámbito del software y se crean modelos de los requisitos datos, flujo de
información y control y del comportamiento operativo. Se realizan soluciones
alternativas y se asignan a diferentes elementos del software.
El análisis de requisitos permite al desarrollador o desarrolladores especificar la
función y el rendimiento del software, indica la interfaz del software con otros
elementos del sistema y establece las restricciones que debe cumplir el software.
Puede dividirse en cinco áreas de esfuerzo que son:
•Reconocimiento del problema
•Evaluación y síntesis
•Modelado
•Especificación
•Revisión
Diseño:
Es cuando se traducen los requerimientos funcionales y no funcionales en una
representación de software. El diseño es el primer paso en la fase de desarrollo o
cualquier producto o sistema de ingeniería. De acuerdo con Pressman el objetivo
del diseño es producir un modelo o representación de una entidad que va a
construir posteriormente.

De acuerdo con McGlaughlin hay tres características que sirven como

parámetros generales para la evaluación de un buen diseño:

El diseño debe implementar todos los requerimientos explicados obtenidos en la

etapa de análisis.

El objetivo debe ser una guía que puedan leer y entender los que construyen el
código y los prueban y mantienen el software.

El diseño debe proporcionar una idea completa de lo que es el software.

Documentación:

Se presenta en base a los métodos orientados a objetos propuestos por Martin y

Odell. Se utilizan las siguientes técnicas para documentar los componentes más
relevantes de la herramienta de software:

Diagramas de eventos: Para ilustrar la manera en que el usuario del software

interactúa con los eventos virtuales.

Diagramas de contexto: Para ubicar el campo de acción que abarca el software.

Tarjetas CRC: Utilizadas para representar todas las clases dentro de un diseño.

Construcción: codificación, pruebas y evaluación, manual del usuario, manual

técnico.
Construcción:
Es la creación detallada de software operativo.
Lenguajes de construcción pueden ser varias clases:
De configuración.
De Toolkits.
De programación.
Los principios fundamentales de la construcción de software son:
•Minimizar la complejidad
•Anticipar los cambios
•Pensar en la verificación posterior
•Aplicar estándares
Codificación:
La escritura del código fuente es el principal esfuerzo de construcción de
software:
•Aplicar técnicas para crear código fuente comprensible
•Manejar condiciones de error.

Prevenir brechas de seguridad a nivel de código •Uso eficiente de recursos

escasos
•Organizar el código fuente
•Documentar el código

Pruebas:

Frecuentemente realizadas por los mismos que escriben el código. El propósito

de estas pruebas es reducir el tiempo entre el momento en el que los fallos se
insertan en el código y el momento en el que son detectados

Implica la ejecución del programa permite: Evaluar la calidad de un producto.

Mejorarlo identificando defectos y problemas. 4.3. Medida, métrica e indicador.

Medida:

Proporciona una indicación cuantitativa de la cantidad, dimensiones o tamaño

de algunos atributos de un producto.

Se debe medir el software para: Indicar la calidad del producto.

Evaluar la productividad del agente que desarrolla el producto.

Evaluar los beneficios en términos de productividad y calidad mediante el uso

de nuevos métodos y herramientas de ingeniería de software.

Establecer una línea de base para la estimación.

Ayudar a justificar el uso de nuevas herramientas o de formación adicional.

 CONCLUSIÓN

Hoy en día se considera que el uso de la ingeniería del software como mecanismo
para la aplicación y evaluación de la eficiencia y calidad de desempeño de los
sistemas funcionales críticos es la determinación de criterios de desempeño bajo
las condiciones y restricciones determinadas por las características externas del
sistema y el ambiente externo.