Está en la página 1de 10

FACULTAD DE CIENCIAS INFORMÁTICAS

CARRERA DE INGENIERÍA EN SISTEMAS DE


INFORMACIÓN

Materia:

Análisis Y Diseño De Sistemas (A19)

Tema:
Docencia 3
Trabajo del componente docencia.

Estudiante:

David René Quiroz Cárdenas

Docente:

Ing. Gabriel Cotera

Periodo académico:

Noviembre 2020 – Marzo 2021


Trabajo del componente docencia.
Calificación: 5 puntos
Metodología: revisar el material de clases disponible en el aula
virtual y el capítulo 6 del libro guía y responder las siguientes
interrogantes.

1. ¿Cuáles son los cuatro tipos de información que busca el analista por medio de la
creación de prototipos

 Prototipo de parches.
 Prototipo no funcional.
 Primer prototipo de una serie.
 Prototipo de características seleccionadas.

2. ¿Qué significa el término prototipo de parches?

Es un prototipo que se basa en la construcción de un sistema funcional que cumple las


expectativas pero que durante el proceso será reacondicionado o reformulado con los diversos
errores que se encuentren. En ingeniería, a esta metodología se le conoce como
“breadboarding”: crear un modelo funcional de un circuito integrado (cuya forma final será
microscópica) uniendo partes.

3. Defina un prototipo que sea un modelo a escala no funcional.

Es un prototipo para un sistema de información en que se muestran las entradas y salidas


necesarias, pero no el procesamiento, debido a que las aplicaciones requieren una codificación
demasiado extensa o costosa como para incluirla en el prototipo.

4. Dé un ejemplo de un prototipo que sea un primer modelo a escala completa.

El prototipo de un nuevo modelo de computadora.

5. Defina lo que significa un prototipo que es un modelo con ciertas características


esenciales, pero no todas.

Es un prototipo donde se presentan al usuario algunas de las características principales del


sistema y las mismas se mantienen a lo largo del desarrollo, durante este proceso existirá una
retroalimentación donde se añadirá o eliminará partes del sistema que se crean convenientes
hasta llegar a un producto final acorde a las necesidades y expectativas del usuario.

6. Haga una lista de las ventajas y desventajas de usar prototipos para sustituir el SDLC
tradicional.
DESVENTAJAS DE LA ELABORACIÓN DE PROTOTIPOS:

• Puede ser bastante difícil manejar la elaboración de prototipos como un proyecto en el


esfuerzo de sistemas más grandes.

• Los usuarios y los analistas podrían adoptar un prototipo como si fuera

un sistema final cuando de hecho es deficiente y su propósito nunca fue el de servir como
sistema terminado.

• El analista necesita considerar estas desventajas contra las ventajas conocidas al


decidir si hace el prototipo, cuándo lo hace y de qué partes del sistema lo hace.

VENTAJAS DE LA ELABORACIÓN DE PROTOTIPOS:

• La posibilidad de modificar el sistema en las primeras etapas del desarrollo.

• La oportunidad de suspender el desarrollo de un sistema que no sea

funcional (sistemas indeseables).

• La posibilidad de desarrollar un sistema que se acerque más a satisfacer las


necesidades y expectativas de los usuarios.

7. Describa cómo se pueden usar los prototipos para mejorar el SDLC tradicional.

La elaboración de prototipos puede utilizarse como un método adicional y especializado para


ayudar a la etapa de levantamiento de requerimientos. La primera preocupación es todo el
tiempo que se requiere para pasar por el ciclo de vida del desarrollo.
La segunda preocupación sobre el uso del SDLC es que los requerimientos del usuario cambian
a través del tiempo. Los requerimientos del usuario evolucionan durante el considerable
intervalo existente entre el análisis de los requerimientos del usuario y la fecha en que se
entrega el sistema final. En el SDLC tradicional, una vez que se entrega un sistema, con
frecuencia es demasiado tarde para modificarlo.
Para resolver estos problemas, algunos analistas proponen la elaboración de prototipos como
una alternativa al ciclo de vida del desarrollo de sistemas. Cuando la elaboración de prototipos
se usa de esta forma, el analista reduce

efectivamente el tiempo entre la determinación de los requerimientos de información y la


entrega de un sistema funcional.
Lo que un prototipo busca es desarrollar un sistema que se acerque más a satisfacer las
necesidades y expectativas de los usuarios, no usar un modelamiento lineal como el SDLC.

8. ¿Cuáles son los criterios para decidir si debemos crear el prototipo de un sistema?

Estimar los costos involucrados en la construcción de un módulo del sistema. Si los costos del
tiempo de los programadores y del analista, así como los costos del equipo están dentro del
presupuesto, se puede continuar con la construcción del prototipo.

9. Haga una lista de los cuatro lineamientos que debe observar el analista al desarrollar
un prototipo.
• Trabajar en módulos manejables.
• Construir rápidamente el prototipo
• Modificar el prototipo en iteraciones sucesivas
• Hacer énfasis en la interfaz de usuario.

10. ¿Cuáles son los dos principales problemas implicados en la creación de prototipos?

La primera preocupación es todo el tiempo que se requiere para pasar por el ciclo de vida del
desarrollo. Conforme aumenta la inversión de tiempo del analista, el costo del sistema
entregado se incrementa proporcionalmente.
La segunda preocupación sobre el uso del SDLC es que los requerimientos del usuario cambian
a través del tiempo. Los requerimientos del usuario evolucionan durante el considerable
intervalo existente entre el análisis de los requerimientos del usuario y la fecha en que se
entrega el sistema final. Por lo tanto, debido al extenso ciclo del desarrollo, el sistema
resultante podría ser criticado por abordar deficientemente los requerimientos de información
del usuario actual.

11. Haga una lista de las tres principales ventajas de usar prototipos.

• Poder cambiar el sistema durante modificar el sistema en las primeras etapas del
desarrollo.
• La oportunidad de suspender el desarrollo de un sistema que no sea funcional.
• La posibilidad de desarrollar un sistema que se acerque más a satisfacer las
necesidades y expectativas de los usuarios.

12. ¿Cómo puede un prototipo montado en un sitio Web interactivo facilitar el proceso
de creación del mismo? Responda en un párrafo.

El proceso de desarrollo de un sitio web incluye seleccionar una tarea que se relaciona
directamente a una característica deseada por el cliente que se basa en las historias del
usuario; escoger a un compañero de programación; seleccionar y escribir los casos de prueba
adecuados; escribir el código; aplicar los casos de prueba; depurar el código hasta que se
apliquen.

13. ¿Cuáles son las tres formas en que puede ayudar un usuario en el proceso de
creación del prototipo?

Hay tres formas principales en las que un usuario puede ayudar en la elaboración de
prototipos:
• Experimentando con el prototipo.
• Dando reacciones sinceras sobre el prototipo.
• Sugiriendo adiciones o eliminaciones al prototipo.
Los usuarios deben tener libertad para experimentar con el prototipo. En contraste con una
simple lista de características de sistemas, el prototipo permite a los usuarios la interacción
real. Una forma de facilitar esta interacción es instalar un prototipo en un sitio Web
interactivo.
14. Defina lo que significa RAD.

El desarrollo rápido de aplicaciones (RAD) es un enfoque orientado a objetos para el desarrollo


de sistemas que incluye un método de desarrollo, así como también herramientas de software.
Es lógico discutir RAD y la elaboración de prototipos en el mismo capítulo, debido a que están
conceptualmente muy unidos. Ambos tienen como meta la reducción del tiempo que
generalmente se

necesita en un SDLC tradicional entre el diseño y la implementación del sistema de


información. Finalmente, el RAD y la elaboración de prototipos se enfocan en satisfacer más de
cerca los requerimientos cambiantes de los negocios. Una vez que ha aprendido los conceptos
de la elaboración de prototipos, es mucho más fácil entender la esencia del RAD, que se puede
considerar como una implementación específica de la elaboración de prototipos.

15. ¿Cuáles son las tres fases del RAD?

Fase de planeación de requerimientos

En esta fase, usuarios y analistas se reúnen para identificar los objetivos de la aplicación o
sistema para identificar los requerimientos de información que surgen de dichos objetivos.
Esta fase requiere que ambos grupos se involucren intensamente; no se trata simplemente de
firmar una propuesta o documento.
Taller de diseño del RAD

El proceso de diseñar y refinar los prototipos se puede representar mejor como un taller.
Cuando imagina un taller, sabe que la participación es intensa, no pasiva, y que generalmente
se hace con las manos.
Fase de implementación

Tan pronto como sean convenidos estos aspectos del negocio o no técnicos del sistema y los
sistemas sean construidos y se refinen, los nuevos sistemas, o parte de ellos, son probados e
introducidos en la organización.

16. ¿Cuáles son los cuatro valores que deben compartir el equipo de desarrollo y los
clientes de la empresa al utilizar una metodología ágil?

La programación extrema (XP) es un enfoque de desarrollo de software que adopta lo que


generalmente designamos como prácticas de desarrollo de software aceptable y las lleva al
extremo. Por ejemplo, la retroalimentación es importante para los programadores, analistas,
diseñadores, usuarios y computadoras
La administración de proyectos es importante de tal manera que la programación extrema
intenta definir rápidamente un plan global del sistema,

desarrollar y liberar rápidamente el software y posteriormente revisarlo continuamente para


incorporarle características adicionales.
Pero la programación extrema no sólo se basa en los resultados. Se basa en los valores
principios y prácticas. Ahora examinaremos cómo los valores y principios de XP dan forma al
desarrollo de sistemas extremos.
17. ¿Qué son los principios ágiles? Mencione cinco ejemplos.

• Metodología de desarrollo
• Metodologías tradicionales
Metodologías ágiles

EJEMPLOS:
1. Es evidente que necesitamos una metodología de trabajo, unas pautas a seguir que
nos ayuden a
coordinar las complejas tareas que suponen el desarrollo de software.

2. Estos sistemas eran implementados por programadores, que no eran necesariamente


buenos
comunicadores, dificultando la comunicación con los usuarios. En esta etapa, los proyectos
software se
planteaban como pequeños ejercicios, los cuales se llevaban a cabo en cortos plazos de
tiempo y no se
pensaba en soluciones a largo plazo y bien planeadas.

3. Los usuarios raramente estaban satisfechos con la


solución presentada, la documentación era escasa (si existía), los cambios cada vez
requerían de mayor
tiempo a la vez que la aplicación se hacía más compleja y los programadores eran piezas
cotizadas, ya
que eran los únicos que sabían cómo funcionaban internamente estas aplicaciones.

4. Un gran número de nuevos enfoques surgieron como respuesta a las limitaciones de


SDLC, dando
lugar al inicio de la mencionada era de las metodologías. Podemos observar dos corrientes
diferentes a
seguir en este periodo de tiempo, una que decide mejorar el modelo waterfall y otra que
decide hacer
algo diferente.

5. Todas ellas cumplen las características que hemos enumerado en el


apartado anterior, pero como habréis apreciado, no damos demasiada información sobre
ellas, sino que
tan solo mencionamos aspectos que están muy extendidos y que podríamos llamar
“típicos tópicos” de
las metodologías tradicionales. La solución que hemos encontrado y que hemos llevado a
cabo, es
presentar dos metodologías tradicionales, la primera que fue acuñada como tal, Waterfall
y una de las
más conocidas y utilizadas actualmente, RUP.

18. ¿Cuáles son las cuatro prácticas básicas de la metodología ágil?

Codificar:
Se designa como una actividad dado que no es posible hacer nada sin
ella.
El proceso básicamente es esto: tenga un pensamiento,
codifíquelo, pruébelo y vea si ese pensamiento era lógico.
También se puede codificar para comunicar ideas que de
otra manera permanecerían borrosas o sin forma. Es
esencial para el desarrollo.

Probar:

La programación extrema da mucha importancia a las pruebas automatizadas. La


programación extrema apoya la generación de pruebas escritas para verificar la
codificación, la funcionalidad, el rendimiento y la conformidad con los objetivos.
XP se apoya en las pruebas automatizadas y existen grandes bibliotecas de
pruebas para la mayoría de los lenguajes de programación. Estas pruebas
necesitan ser actualizadas conforme sea necesario durante el progreso del
proyecto.

Escuchar:
En la programación extrema, esta actividad se lleva al
extremo. Los desarrolladores escuchan de manera activa
a sus compañeros de programación. En XP se depende
menos de la comunicación formal escrita y por ello
escuchar se vuelve una habilidad muy importante.
El desarrollador también escucha de manera activa al cliente.

Diseñar:
Lo cual es una forma de crear una estructura para
organizar toda la lógica en el sistema. Diseñar es una
actividad evolutiva, y por ello los sistemas que se diseñan
con un enfoque de la programación extrema se
conceptualizan como en constante evolución, siempre
diseñándose.
Con frecuencia un buen diseño es simple.
19. Mencione las cuatro variables de control de recursos que se utilizan en la
metodología ágil.

Codificar:

Se designa como una actividad dado que no es posible hacer nada sin ella.

Un autor afirma que la cosa más valiosa que recibimos de la codificación es el "aprendizaje".

El proceso básicamente es esto: tenga un pensamiento, codifíquelo, pruébelo y vea si ese


pensamiento era lógico. También se puede codificar para comunicar ideas que de otra manera
permanecerían borrosas o sin forma. Cuando veo su código, puedo generar un nuevo
pensamiento. El código fuente es la base para que un sistema sobreviva. Es esencial para el
desarrollo.

Probar:

La programación extrema da mucha importancia a las pruebas automatizadas. La


programación extrema apoya la generación de pruebas escritas para verificar la codificación, la
funcionalidad, el rendimiento y la conformidad con los objetivos. XP se apoya en las pruebas
automatizadas y existen grandes bibliotecas de pruebas para la mayoría de los lenguajes de
programación. Estas pruebas necesitan ser actualizadas conforme sea necesario durante el
progreso del proyecto.
Hay razones de corto y largo plazos para hacer pruebas. Probar a corto plazo le proporciona la
confianza extrema en lo que está construyendo. Si las pruebas se ejecutan perfectamente
usted puede seguir adelante con la confianza renovada. A largo plazo, probar mantiene vivo un
sistema, y le permite hacer muchos más cambios de los que serían posibles si ninguna prueba
fuera escrita o ejecutada.

Escuchar:

En la programación extrema, esta actividad se lleva al extremo. Los desarrolladores escuchan


de manera activa a sus compañeros de programación. En XP se depende menos de la
comunicación formal escrita y por ello escuchar se vuelve una habilidad muy importante.
El desarrollador también escucha de manera activa al cliente. Los desarrolladores asumen que
no saben nada acerca del negocio en el que están colaborando, y por lo tanto deben escuchar
cuidadosamente a los usuarios para obtener las respuestas a sus preguntas. El desarrollador
necesita entender la eficacia de escuchar. Si no escucha, no sabrá lo que debe codificar o lo
que debe probar.

Diseñar:

Lo cual es una forma de crear una estructura para organizar toda la lógica en el sistema.
Diseñar es una actividad evolutiva, y por ello los sistemas que se diseñan con un enfoque de la
programación extrema se conceptualizan como en constante evolución, siempre diseñándose.
Con frecuencia un buen diseño es simple. También, éste debe permitir la flexibilidad:
Diseñar bien permite agregar extensiones al sistema haciendo cambios en un solo lugar.
El diseño eficaz ubica la lógica cerca de los datos en que estará operando. Sobre todo, el
diseño debe ser útil para todos aquellos que lo necesitarán conforme avance el esfuerzo de
desarrollo, incluyendo a clientes y programadores.
20. Describa los pasos comunes en un episodio de desarrollo ágil.

1. Escuchar las historias de los usuarios por medio del cliente.


2. Dibujar un modelo del flujo de trabajo lógico para apreciar las decisiones de
negocios representadas en la historia de un usuario.
3. Crear historias de usuarios con base en el modelo lógico.
4. Desarrollar algunos prototipos de visualización. Para ello hay que mostrar a los
clientes el tipo de interfaz que tendrán.
5. Usar la retroalimentación de los prototipos y los diagramas del flujo de trabajo
lógico para desarrollar el sistema hasta crear un modelo físico de datos.

21. ¿Qué es una historia de usuario? ¿Debe ser escrita o hablada? Indique su opción y
después defienda su respuesta con un ejemplo.

Una historia de usuario es un listado de las diferentes acciones que son posibles en un
escenario específico. El desarrollo de la misma es principalmente hablado entre el
desarrollador y el usuario, pero debe quedar escrita para usarla de referencia en el desarrollo
del sistema.

Creación de una página web.

22. Haga una lista de las herramientas de software que pueden ayudar al desarrollador a
realizar una variedad de pruebas de código.

• Pruebas unitarias de código: SUnit y Junit.

• Probadores unitarios automatizados, probadores de aceptación y probadores de


GUI: JUnit, ComUnit, VBUnit, Nunit, httpUnit y Rational Visual Test Tools.
• Medición del sistema y desempeño de componentes: Jmeter, JUnitPerf, PerfMon,
TrueTime, RealTime y Microsoft Visual Studio Analyzer.
• Control del código fuente: CVS, Visual Source Safe y PVCS.
• Entornos de desarrollo: IBM VisualAge, Microsoft Visual Studio .NET y JBuilder.

23. ¿Qué es la scrum?

Un enfoque ágil se conoce como "melé". La palabra melé se toma de la posición de arranque
en rugby en la cual los equipos se ponen frente a frente y pelean por la posesión del balón. En
realidad, melé se refiere al trabajo en equipo, similar a lo que se necesita hacer en un juego de
rugby.
Tal como los equipos de rugby empezarán un juego con una estrategia global, los equipos de
desarrollo empiezan el proyecto con un plan de alto nivel que puede cambiarse sobre la
marcha conforme avance el "juego". Los miembros del equipo de desarrollo de sistemas
comprenden que el éxito del proyecto es más importante, y su éxito individual es secundario.
El líder del proyecto tiene alguna, pero no mucha, influencia en los detalles. Más bien, las
tácticas del juego se dejan a los miembros del equipo, como si estuvieran en el campo. El
equipo de sistemas trabaja dentro de un horario estricto (30 días para el desarrollo), así como
un equipo de rugby jugaría limitándose estrictamente al tiempo de un juego.
De hecho, melé es una metodología de alta intensidad. Es sólo uno de los enfoques que
adoptan la filosofía del modelado ágil.

24. Nombre las siete estrategias para mejorar la eficiencia en el trabajo del
conocimiento.

• Reducir el tiempo y los errores de la interfaz.

• Reducir el tiempo de aprendizaje del proceso y las pérdidas duales de


procesamiento.
• Reducir el tiempo y esfuerzo requeridos para estructurar las tareas y aplicar
formato a las salidas.
• Reducir la expansión improductiva del trabajo.

• Reducir el tiempo y costos del almacenamiento, la investigación de datos y del


conocimiento.
• Reducir el tiempo y costos de la comunicación y la coordinación.

• Reducir las pérdidas debido a la sobrecarga humana de información.

25. Identifique seis riesgos al adoptar una innovación organizacional.

• Derechos individuales
• Cultura de la Organización
• Sincronización
• Costo
• Medición del impacto
• Reacciones de los clientes

También podría gustarte