Mito vs Realidad

Relacionar Columnas

Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante
los primeros años del desarrollo del software. Hoy la mayoría de los profesionales competentes
consideran a los mitos como actitudes erróneas que han causado serios problemas, siendo éstos hábitos
difíciles de modificar.
Examinemos algunos de ellos:

Descarga la versión para jugar en papel

Duplicar

Crear reto

Sobre Relacionar Columnas

Tecnología

11º - Secundaria

preubas

tecnologías de la información y comunicación

Edad recomendada: 15 años

8 veces realizada

Creada por

CRISTIAN EMILIO DIOZA ZAMBRANO

Colombia

Top 10 resultados

1

anon

8 de Mayo de 2021

05:09

tiempo

98

puntuacion

¿Quieres aparecer en el Top 10 de este juego?

Inicia sesión

para identificarte.

Crea tu propio juego gratis desde nuestro creador de juegos

Crear relacionar columnas

Compite contra tus amigos para ver quien consigue la mejor puntuación en esta actividad

Crear reto


Relacionar Columnas Mito vs Realidad Versión en línea Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. Hoy la mayoría de los profesionales competentes consideran a los mitos como actitudes erróneas que han causado serios problemas, siendo éstos hábitos difíciles de modificar. Examinemos algunos de ellos: por CRISTIAN EMILIO DIOZA ZAMBRANO 1 Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. (Podemos detallar mas adelante). 2 Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas; después de todo, les compramos las computadoras más nuevas. 3 Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido. 4 Tenemos ya un libro que está lleno de estándares y procedimientos para construir software. ¿No le proporciona ya a mi gente todo lo que necesita saber? 5 Hasta que no tengo el programa “ejecutándose” realmente no tengo forma de comprobar su calidad. 6 Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. 7 Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado 8 Lo único que se entrega al terminar el programa funcionando. Se necesita mucho más que el último modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE), aunque no se usen la mayoría, son más importantes que el hardware para conseguir buena calidad y productividad. Un programa que funciona es solo una parte de una configuración del software que incluye todos los elementos tales como el Análisis, Diseño, Documentación del sistema, etc. Es verdad que los requisitos del software cambian pero el impacto del cambio varia según el momento en que se introduzca. Entre mas temprano se realicen mejor. Está muy bien que el libro exista, pero ¿Se usa? ¿Conocen los trabajadores su existencia? ¿Refleja las prácticas modernas de desarrollo de software? ¿Es completo? En muchos casos, la respuesta a todas estas preguntas es "no"?. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software (Revisión de Técnica formal). La revisión del Software es un "filtro de calidad" que se ha comprobado que es mas efectivo que la prueba, para encontrar ciertas clases de defectos en el software. Una mala definición inicial es la causa principal del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, rendimiento, etc. Y todas estas características sólo se pueden determinar después de una exhaustiva comunicación entre cliente y analista. Alguien dijo una vez: "Cuando mas pronto se comience a escribir código, mas se tardará en terminarlo". Datos industriales indican que entre el 50 y el 70 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez. El desarrollo de software no es un proceso mecánico como la fabricación. Brooks dice: "Añadir gente a un proyecto de software retrasado lo retrasa aun más". Ya que cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero de una manera planificada y bien coordinada.

Relacionar Columnas

Mito vs Realidad Versión en línea

Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. Hoy la mayoría de los profesionales competentes consideran a los mitos como actitudes erróneas que han causado serios problemas, siendo éstos hábitos difíciles de modificar. Examinemos algunos de ellos:

por CRISTIAN EMILIO DIOZA ZAMBRANO

Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. (Podemos detallar mas adelante).

Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas; después de todo, les compramos las computadoras más nuevas.

Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido.

Tenemos ya un libro que está lleno de estándares y procedimientos para construir software. ¿No le proporciona ya a mi gente todo lo que necesita saber?

Hasta que no tengo el programa “ejecutándose” realmente no tengo forma de comprobar su calidad.

Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible.

Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado

Lo único que se entrega al terminar el programa funcionando.

Se necesita mucho más que el último modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE), aunque no se usen la mayoría, son más importantes que el hardware para conseguir buena calidad y productividad.

Un programa que funciona es solo una parte de una configuración del software que incluye todos los elementos tales como el Análisis, Diseño, Documentación del sistema, etc.

Es verdad que los requisitos del software cambian pero el impacto del cambio varia según el momento en que se introduzca. Entre mas temprano se realicen mejor.

Está muy bien que el libro exista, pero ¿Se usa? ¿Conocen los trabajadores su existencia? ¿Refleja las prácticas modernas de desarrollo de software? ¿Es completo? En muchos casos, la respuesta a todas estas preguntas es "no"?.

Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software (Revisión de Técnica formal). La revisión del Software es un "filtro de calidad" que se ha comprobado que es mas efectivo que la prueba, para encontrar ciertas clases de defectos en el software.

Una mala definición inicial es la causa principal del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, rendimiento, etc. Y todas estas características sólo se pueden determinar después de una exhaustiva comunicación entre cliente y analista.

Alguien dijo una vez: "Cuando mas pronto se comience a escribir código, mas se tardará en terminarlo". Datos industriales indican que entre el 50 y el 70 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez.

El desarrollo de software no es un proceso mecánico como la fabricación. Brooks dice: "Añadir gente a un proyecto de software retrasado lo retrasa aun más". Ya que cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero de una manera planificada y bien coordinada.

Mito vs Realidad

Usa estas credenciales para integrar el juego en un LMS compatible con LTI 1.1 como Canvas, Moodle, o Blackboard. De esta manera podrás guardar las puntuaciones automáticamente en el libro de calificaciones de esa plataforma.

Mito vs Realidad

Relacionar Columnas

Descarga la versión para jugar en papel

Creada por

Top 10 resultados

Top juegos

Relacionar Columnas

La ruta del nombre.

Relacionar Columnas

Las 7 maravillas del mundo

Relacionar Columnas

Identificar definiciones

Relacionar Columnas

FACTORES DE CONVERSIÓN

Relacionar Columnas

Estilos de música

Relacionar Columnas

Mito vs Realidad Versión en línea

por CRISTIAN EMILIO DIOZA ZAMBRANO

Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. (Podemos detallar mas adelante).

Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas; después de todo, les compramos las computadoras más nuevas.

Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido.

Tenemos ya un libro que está lleno de estándares y procedimientos para construir software. ¿No le proporciona ya a mi gente todo lo que necesita saber?

Hasta que no tengo el programa “ejecutándose” realmente no tengo forma de comprobar su calidad.

Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible.

Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado

Lo único que se entrega al terminar el programa funcionando.