954
edits
Crisis del software: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
También se acuñó el término “ingeniería del software” para describir el conjunto de conocimientos que debía desarrollarse para dar solución a la situación. | También se acuñó el término “ingeniería del software” para describir el conjunto de conocimientos que debía desarrollarse para dar solución a la situación. | ||
Es en este contexto donde comienza a tener razón de ser el concepto de "proyecto de software". Según | Es en este contexto donde comienza a tener razón de ser el concepto de "proyecto de software". Según Roger Pressman: | ||
<blockquote>''[...] la gestión de proyectos implica la planificación, supervisión y control del personal, del proceso y de los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la implementación operacional. La gestión eficaz del proyecto de software se centra en las cuatro “P”: personal, producto, proceso y proyecto. El gestor que se olvida de que el trabajo de ingeniera del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacio.''</blockquote> | <blockquote>''[...] la gestión de proyectos implica la planificación, supervisión y control del personal, del proceso y de los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la implementación operacional. La gestión eficaz del proyecto de software se centra en las cuatro “P”: personal, producto, proceso y proyecto. El gestor que se olvida de que el trabajo de ingeniera del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacio.''<sup>2</sup></blockquote> | ||
==Bibliografía== | ==Bibliografía== | ||
Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en los 60 y 70: | Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en los 60 y 70: | ||
| Line 17: | Line 17: | ||
==Referencias== | ==Referencias== | ||
*<sup>1</sup>Bauer, F., Bolliet, L., & Helms, H. (1968): ''Software Engineering. Nato Software Engineering Conference'' (pág. 136). Garmisch: Peter Naur and Brian Randell. | *<sup>1</sup> Bauer, F., Bolliet, L., & Helms, H. (1968): ''Software Engineering. Nato Software Engineering Conference'' (pág. 136). Garmisch: Peter Naur and Brian Randell. | ||
*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill. | |||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||