Anda di halaman 1dari 2

Instituto Politcnico Nacional

Unidad Profesional Interdisciplinaria de


Ingeniera y Ciencias Sociales y
Administrativas

Prototipado

Abarca Lpez Emmanuel


Ngera Anguiano Ana Fernanda
Snchez Jurez Guillermo
Snchez Rosales Irvin Yael
Sanpedro Torres Janine Guadalupe

2CM41

Prototipado: Online Records


Equipo 3

Introduccin:
Cualquier actividad en el desarrollo de un sistema inevitablemente cambia las condiciones del
entorno en el que el sistema va a funcionar. Las metodologas de desarrollo de sistemas deben tener
en cuenta que el usuario, sus necesidades y contexto, cambian durante el proceso
Daniel D. McCracken y Michael A. Jackson, 1982
No solo el contexto en el que se desarrolla el sistema puede variar por circunstancias externas, sino
que el propio desarrollo de software cambia ese contexto. Y es absolutamente razonable, ya que
introduce en el problema una variable ms que es el propio sistema y plantea un elemento nuevo en
el entorno que modifica las condiciones en que el rea usuaria puede interpretar sus procesos y la
forma y herramientas que utilizan para ejecutarlos.

Historia
Daniel D. McCracken y Michael Anthony Jackson desarrollaron varios mtodos para desarrollar
sistemas, ellos planteaban que los requisitos del sistema no siempre se pueden afirmar totalmente de
antemano porque el usuario no los conoce, y afirmar lo contrario es ignorar el hecho de que el propio
proceso de desarrollo cambia la percepcin del usuario de lo que es posible, aumenta sus
conocimientos del entorno de la aplicacin e incluso a menudo cambia el entorno por s mismo.
Jugando a predecir lo que realmente quiere el usuario y construyendo grandes sistemas que despus
requieren ser ajustados y no existe ni tiempo ni presupuesto para poder hacerlo de manera
adecuada.

Las metodologas clsicas pueden ser ms cmodas, no tienen la intensidad de las basadas en
desarrollos iterativos e incrementales de ciclos cortos, pero no son efectivas y la comodidad se
convierte en desgaste cuando el usuario empieza a cambiar requisitos en fases tardas del desarrollo
o tras la entrega.

Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales
para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento
y salida, es decir cuando el responsable no est seguro de la eficacia de un algoritmo, de la
adaptabilidad del sistema o de la forma en que interacta el hombre y la mquina. Este modelo se
encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera
cul ser el resultado de la construccin cuando los requisitos estn satisfechos

Herramientas Automatizadas

2CM41

Anda mungkin juga menyukai