Mayo-agosto 2018

Decanato de ingeniería e informática

Trabajo de la materia fundamento de ingeniería de software

Sustentantes:
Anthony C. Reynoso 2017-2077
Luis J. Ceballos 2017-1947
Edward Terrero 2017-1787
Kevin Cosme 2017-2100
José F. Bonilla Sánchez 2017-2125

Profesor:
Eduardo Leandro G. Foundeur

Tema:
Ingeniería de Procesos de Software
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:
o a) Los diseñadores deben responder a los usuarios,
o b) Los usuarios deben plantear a los diseñadores,
o c) Los usuarios deben hacerse a sí mismos sobre el
producto de software que ha de elaborarse,
o d) Los diseñadores deben plantearse acerca del
producto de software que va a construirse y del proceso
que se usará para ello.

a) ¿Qué desea? ¿Cómo lo desea? ¿En qué tiempo desea

que esté listo? ¿Cuánto puede invertir? ¿Desea ver una
prueba cuando esté avanzado?

b) ¿Pueden hacerlo? ¿Puede lucir de esta manera? ¿En

cuánto tiempo estará listo? ¿Cuánto tendré que invertir?
¿Podrían mostrarme una prueba cuando hayan avanzado?

c) ¿Qué es lo que verdaderamente quiero? ¿cómo lo quiero?

¿cuánto puedo invertirá? ¿Cuánto tiempo les puedo dar?
¿Qué seguridad tengo de que funcionara?

d) ¿Estoy seguro de lo que quiere el usuario? ¿Tengo las

herramientas para hacerlo? ¿qué flujo de desarrollo tendré
que seguir? ¿Qué modelo cumple mejor con las
necesidades de este proyecto?
 Diga tres ejemplos de proyectos de
software que podrían realizarse con el
modelo incremental. Sea específico.
• Un sistema operativo.
• Un software para procesar textos.
• Software de recursos humanos.

¿Son lo mismo el proceso unificado y el UML? Explique su

respuesta.

Las dos tecnologías están estrechamente relacionadas y pueden ser fácilmente

confundidos. Ambos se asociaron con la línea de productos de Rational, y
ambos utilizan la palabra "unificada" de la marca de la tecnología. En lo que
difieren es en su propósito. El Proceso Unificado es un marco de desarrollo,
que abarca todos los aspectos de la ingeniería de software. El Unified Modeling
Language es un conjunto de anotaciones que describen diferentes aspectos del
proceso de desarrollo. UML se puede considerar parte del proceso unificado,
pero UML también puede valerse por sí misma.
El proceso unificado
Como la mayoría de las tecnologías, ambos todavía encontrar usos en la
industria, pero se han adaptado a las necesidades actuales. gubernamentales y
grandes proyectos de misión crítica a menudo eligen el proceso unificado o sus
derivados para hacer frente a sus necesidades de análisis y documentos
pesados. La mayoría de los desarrolladores se han trasladado a algún tipo de
modelo ágil que utiliza muchos de los conceptos del proceso unificado, pero sin
el modelado y artefactos.
UML
diagramas UML todavía tienen un lugar en el desarrollo de software, pero se
encuentran principalmente en libros técnicos y pizarras blancas. Los diagramas
de clases e interfaces se pueden encontrar en algunas de las herramientas de
desarrollo de gama alta, pero la mayoría de los desarrolladores del núcleo duro
prefieren trabajar en el código, no en el modelado. Al igual que el diagrama de
flujo, diagramas de funcionar bien para conceptualizar las ideas, pero el
producto final de desarrollo de software tiene que ser un código de programa,
no bonitas imágenes.
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.

Primera actividad:

Este caso trata de un pequeño proyecto de software que es solicitado por una
persona con requerimientos sencillos, para la activada de comunicación
bastara con una llamada por teléfono, entonces las tareas a realizar serán las
siguientes:
1- Hacer contacto con el cliente por vía telefónica.
2- Tomar apunte y analizar los requerimientos pedidos.
3- Organizar las anotaciones de forma escrita y cuales son de mayor prioridad.
4- Enviar un correo electrónico al cliente para que verifique y apruebe.

Segunda actividad:

En este caso se tratará un proyecto de software más complejo, con más

clientes y cada uno con distintos requerimientos, para la actividad de
comunicación se invitarán a los clientes a una reunión formal y las tareas
definirán a continuación:

1- Hacer un listado de todos los clientes o los que participarán.

2- Hacerle entrevista a cada participante por separado, con el fin de saber
cuáles son los deseos y necesidades de cada uno.
3- Hacer una lista en función a las necesidades y deseos de cada participante.
4- Realizar una serie de reuniones para hacer más fácil el proceso de la
elaboración y aclara dudas.
5- Hacer un nuevo listada con las peticiones y necesidades de los
participantes.
6- Asignar las prioridades a los requerimientos, cuáles serán más importantes.
7- Organizar los requerimientos de manera tal que pueden estar de una
creciente.
8- Identificar las restricciones y limitaciones que tendrá el sistema.
9- Revisar y analizar todo para la validación.
¿Es posible demostrar que un componente de
software, o incluso un programa completo, es
correcto? Entonces, ¿por qué no todos lo hacen?

Si es posible comprobarlo gracias a los diferentes modelos que me permiten en

cada etapa saber cómo voy en el proyecto y conocer los errores, muchos no lo
aplican por falta de conocimiento en la etapa de requisitos y no saben cómo
ponerlo en práctica.