Mito vs Realidad

Matching Pairs

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:

Download the paper version to play

Duplicate

Create challenge

About Matching Pairs

Tecnología

11º - Secundaria

preubas

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

Recommended age: 15 years old

8 times made

Created by

CRISTIAN EMILIO DIOZA ZAMBRANO

Colombia

Top 10 results

1

anon

May 8, 2021

05:09

time

98

score

Do you want to stay in the Top 10 of this game?

to identify yourself.

Make your own free game from our game creator

Make matching pairs

Compete against your friends to see who gets the best score in this game

Make challenge


Matching Pairs Mito vs Realidad Online version 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: by CRISTIAN EMILIO DIOZA ZAMBRANO 1 Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado 2 Hasta que no tengo el programa “ejecutándose” realmente no tengo forma de comprobar su calidad. 3 Lo único que se entrega al terminar el programa funcionando. 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 Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. 6 Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas; después de todo, les compramos las computadoras más nuevas. 7 Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido. 8 Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. (Podemos detallar mas adelante). 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. 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"?. 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. 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. 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. 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.

Matching Pairs

Mito vs Realidad Online version

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:

by CRISTIAN EMILIO DIOZA ZAMBRANO

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

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

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

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?

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

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.

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

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.

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

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.

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.

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.

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.

Mito vs Realidad

Use these credentials to integrate the game into an LMS compatible with LTI 1.1 such as Canvas, Moodle, or Blackboard. This way, the scores will be automatically saved into the platform’s gradebook.

Mito vs Realidad

Matching Pairs

Download the paper version to play

Created by

Top 10 results

Top Games

Matching Pairs

Cell Cycle Memory

Matching Pairs

The Bill of Rights

Matching Pairs

appendicular skeleton

Matching Pairs

Balance Sheet & P & L

Matching Pairs

Cranial Nerves

Matching Pairs

Mito vs Realidad Online version

by CRISTIAN EMILIO DIOZA ZAMBRANO

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

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

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

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?

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

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.

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