Grupo3-Practica2-Ingeniería de Procesos de Software-41033 PDF

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 7

Nombres

Yonaigris Matos (2020-0900)


Adrian Lebrón (2020-0672)
Jean Pierre Sam Rood (2018-1018)

Periodo académico
C3-2020
Profesor
Leandro Fondeur
Tema
Ingeniería de procesos del software
Fecha de entrega
12/09/2020
Practica 2 – Ingeniería de procesos del
software
Luego de leer el capítulo 2 del libro de texto (Libro - Ingeniería del Software; un enfoque
práctico 7ma. Edición), subrayar los conceptos centrales e investigar otras fuentes para
ampliar las ideas, realice las siguientes actividades en grupo:

1) En la introducción de este capítulo, Baetjer afirma que: "El proceso


genera interacción entre usuarios y diseñadores, entre usuarios y
herramientas cambiantes [tecnología].” Enliste cinco preguntas
que: (Yonaigris Matos)

a) Los diseñadores deben responder a los usuarios,

1 ¿Cuál es su funcionalidad?
2 ¿Es seguro?
3 ¿Cómo se emplearía?
4 ¿Cuál es el costo?
5 ¿Cuánto tiempo tomaría?

b) Los usuarios deben plantear a los diseñadores,

1 ¿Qué beneficios me facilitaría?


2 ¿Sera fácil de comprender?
3 ¿Se le estará dando mantenimiento después de instalarlo?
4 ¿Qué tan seguro sería?
5 ¿Cuánto tiempo duraría?

c) Los usuarios deben hacerse a sí mismos sobre el producto de software que ha


de elaborarse,

1 ¿Deje clara todas mis inquietudes?


2 ¿Exprese bien mis necesidades e ideas?
3 ¿El diseñador habrá entendido lo que necesito?
4 ¿Facilite toda la información necesaria?
5 ¿cumplirá con lo requerido?

d) Los diseñadores deben plantearse acerca del producto de software que va a


construirse y del proceso que se usará para ello.

1 ¿Tengo claro todo acerca del proyecto?


2 ¿El usuario me facilito toda la información necesaria que necesito?
3 ¿Como debería de desarrollarlo?
4 ¿Necesitare más del tiempo estimado?
5 ¿Qué modelo necesito emplear?
2) Trate de desarrollar un conjunto de acciones para la actividad de
comunicación. Seleccione una acción y defina un conjunto de tareas
para ella. (Yonaigris Matos)

Reunión, Contacto, Análisis, Planeación, Requerimientos, Restricciones, Negociación


y Aprobación.

Análisis:

1 pedirle a cada participante que enliste cuales necesidades quiere que el software
cubra
2 tomar notas
3 analizar qué es lo que necesita el cliente
4 realizar preguntas necesarias si hacen falta conocimientos
5 organizar las ideas
6 evaluar el problema
7 extraer una conclusión

3) Investigue un poco sobre el PPS y haga una breve presentación que


describa los tipos de mediciones que se pide hacer a un ingeniero
individual de software y la forma en la que pueden usarse para
mejorar la eficacia personal. (Yonaigris Matos)

Proceso Personal del Software (PPS), es una práctica disciplinaria que ayuda a los
programadores o ingenieros de software a tener un mejor manejo del tiempo y
mejorar su productividad personal. Esta práctica también hace que el profesional se
responsabilice con la planeación de un proyecto creando estimaciones y actividades.
Se enfatiza en la necesidad de poder detectar errores pronto y entender cuáles de
estos tipos se pueden cometer. También el profesional desarrolla habilidades para
trabajar en equipo.

Existen algunas mediciones que se le pide a un ingeniero individual de software


como: estimación de precisiones de tamaños y tiempo, tiempo en la fase de
distribución, productividad, distribución de defectos introducidos y corregidos, falla
de costo de calidad, evaluación, rendimiento, tasas de evaluaciones y fallos,
rendimiento de la fase, rendimiento del proceso, entre otros.

Estas mediciones se pueden usar en las siguientes actividades para mejorar la


eficiencia personal:

Planeación: el ingeniero usa su capacidad para dividir los requerimientos, hacer una
estimación del tamaño que tendrá el nuevo proyecto y crea una guía para el
proyecto. Las mediciones se registran en hojas de trabajo y estas informaciones se
usan para tareas de agendamiento, planeación y estimación.

Diseño de alto nivel: el ingeniero crea un diseño de componentes, realiza patrones


y reconoce aspectos sobresalientes. Creando especificaciones externas.
Revisión del diseño de alto nivel: Se llevan a cabo practicas para encontrar fallos en
el diseño. Las mediciones se mantienen para todas las tareas y resultados.

Desarrollo: se examina y perfecciona el diseño. El ingeniero aprende a evaluar y


mejorar su proceso.

Post mórtem: por medio de medidas y mediciones obtenidas, el ingeniero determina


la eficacia del proceso.

4) Conforme avanza hacia fuera por el flujo de proceso en espiral, ¿qué


puede decirse sobre el software que se está desarrollando o que
está en mantenimiento? (Jean Pierre Sam Rood)

El desarrollo de software según proceso en espiral se aprecia sobre todo para


proyectos grandes y complejos, donde el control presupuestario es de vital
importancia, tanto para el cliente como para la empresa desarrolladora. Esto podría
significar, por ejemplo, mejorar el rendimiento o ampliar la funcionalidad. Al mismo
tiempo, es necesario definir alternativas para la implementación (diseño A vs. diseño
B por ejemplo) y determinar el marco general así como los costos o el tiempo de
trabajo requerido. desarrollar la estrategia menos riesgosa y rentable, donde se
pueden emplear métodos como la creación de prototipos, simulaciones, pruebas de
calibración, modelos analíticos y encuestas de usuarios.

En cualquier caso, es de esperar que aumenten los costos, los esfuerzos adicionales
y un retraso en el lanzamiento del software, factores que pueden convertirse
rápidamente en un problema existencial, especialmente para las pequeñas
editoriales.

5) ¿Es posible combinar modelos de proceso? Justifique su respuesta


y dé ejemplos. (Jean Pierre Sam Rood)

Yo diría que en general sí es posible, en grandes sistemas donde el prototipo se crea


al inicio del software para aclarar primero las dudas. Suponiendo que de alguna
manera estén interrelacionados. La forma más sencilla es (esclavizar) el proceso
dependiente; es decir, tratar su comportamiento como un servicio con entradas y
puntos definidos en el proceso de llamada para recibir sus resultados. Luego, defina
un contrato de servicio (en términos de tiempo de respuesta, confiabilidad, etc.). Por
supuesto, es factible fusionar dos modelos de productos, pero puede haber muchas
razones organizativas para no hacerlo.

Por ejemplo, el proveedor de servicios dependiente existe para propósitos y


administración separados, o también se requiere para otros procesos. Las
situaciones de codependencia se pueden realizar de la misma manera, pero
requieren la negociación bilateral de los términos de servicio (también conocidos
como acuerdos de nivel de servicio).
6) El modelo de proceso concurrente define un conjunto de "estados”.
Describa con sus propias palabras qué es lo que representan, y
después indique cómo entran en juego dentro del modelo de
proceso concurrente. (Jean Pierre Sam Rood)

El modelo para el desarrollo simultáneo del procedimiento debe referirse al proceso


del proceso, y el sistema ejecuta instrucciones adicionales. espiral, prototipos,
análisis y diseño, etc. Los estados que componen el proceso son: en desarrollo,
cambios pendientes, en evaluación, en revisión, alcance mínimo. He completado
Cómo interactúan estos estados entre sí en el proceso concurrente, pero se explicará
brevemente en el siguiente ejemplo: (La actividad de comunicación termina con una
primera iteración al inicio de un proyecto y existe en el estado de esperando
cambios. La actividad de modelado que existía en el estado Inactivo hasta que se
complete la comunicación inicial, ahora pasa al estado de desarrollo. Sin embargo,
si el cliente indica que los cambios deberían ser necesarios, la actividad de modelado
cambiará al estado de desarrollo con los cambios pendientes).

término concurrente significa uno tras otro y el modelo de computación concurrente


funciona según este principio.

7) ¿Cuáles son las ventajas y desventajas de desarrollar software en el


que la calidad no es "suficientemente buena”? Es decir, ¿qué pasa
cuando se pone el énfasis en la velocidad de desarrollo sobre la
calidad del producto? (Adrian Lebron)

En la ocación de que el software sea desarrollado en un periodo de tiempo


sumamente corto podría carecer de funcionalidades esenciales, debido a esto,
probablemente solo obedecería a los requerimientos solicitados por el usuario,
cualquier necesidad imprevista que necesite el mismo dejaría en evidencia una o
varias vulnerabilidades en el software y con ello la capacidad de prevención del
programador para fortalecer su trabajo.

Explicado esto, mencionaremos las ventajas y desventajas de priorizar el tiempo de


desarrollo del software por encima de su calidad:

Ventajas:

• Se ha creado específicamente para cumplir con los requerimientos solicitados.

• Empezara a estar en funcionamiento en poco tiempo, como el cliente desea.

• Queda en evidencia la intención de el o los programadores en realizar el software


en el tiempo que el cliente lo ha solicitado.
Desventajas:

• Podrían obviarse procesos o funciones que si bien no fueron solicitados serian


fundamentales para garantizar el mejor rendimiento posible del software.

• También se podría apreciar que es más relevante para el equipo de


desarrolladores terminar el software rápidamente sin depurar su calidad y
funcionamiento que tomarse más tiempo en su desarrollo y asegurarse de que
su desempeño será el esperado.

• El hecho de no realizar los procedimientos de verificación de calidad apropiados


podría desencadenar uno o varios errores que pondrían en peligro todo el
software y tener que trabajar dos veces por enfocarse en el tiempo de desarrollo
y no en la eficiencia y calidad de este.

8) ¿Es posible demostrar que un componente de software, o incluso


un programa completo, es correcto? Entonces, ¿por qué no todos lo
hacen? (Adrian Lebron)

Si, mediante programas como los “compiladores de código” y otras herramientas es


posible identificar errores en la escritura del código fuente de un software
determinado, no obstante a esto, hay errores estructurales y lógicos de un software
en los que un compilador no podría intuir en si esta correcto o no, por ejemplo: “el
orden de un proceso para introducir mercancía en un supermercado y su venta en
el mismo, el compilador no sabe en qué orden deben estar los módulos del
software que harán esta tarea, de eso se encarga el programador, si colocamos los
módulos en el orden inverso pero la sintaxis del código no tiene errores, el
programa se ejecutara pero el resultado sería un desastre porque el pensamiento
lógico de el programador está ausente en este trabajo”.

Debido a lo anteriormente explicado, es por lo que no se lleva a cabo


apropiadamente la verificación de que el software cumple correctamente con los
requerimientos solicitados, es un arduo trabajo encontrar las fallas en la propia
manera pensar de un programador y más aún si el mismo está trabajando en
solitario en el proyecto, por esto es recomendable trabajar con un equipo, para que
mutuamente puedan identificarse los errores lógicos y estructurales en el
pensamiento de cada integrante en el grupo.
9) ¿Son lo mismo el proceso unificado y el UML? Explique su
respuesta. (Adrian Lebron)

No. Siendo cierto que ambos conceptos están demasiado relacionados, la diferencia
radica en que el “lenguaje modelado unificado” tiene como objetivo definir y
describir métodos o procesos. Es para demarcar un sistema, para detallar los
mecanismos en el sistema y para documentar y construir. Ósea, es el lenguaje en el
que está descrito el modelo y el “proceso unificado” está definido como una
metodología para el desarrollo de software que está fundamentado en
componentes e interacciones definidas, y junto con el Lenguaje Unificado de
Modelado (UML), conforma la metodología convencional más utilizada para la
revisión, instauración y documentación de sistemas. El proceso unificado no posee
pasos concretamente definidos, sino un conglomerado de metodologías ajustables
al contexto y necesidades de cada usuario.

Habiendo definido ambos conceptos y dejando clara su dependencia conceptual,


podemos ver que no son lo mismo, ya que ambos tienen tareas específicas que no
son exactamente iguales.

También podría gustarte