Mariannys bermudez ensayo.pdf,

Mariannys bermudez ensayo.pdf,

• 1.
  REPÚBLICA BOLIVARIANA DEVENEZUELA INSTITUTO UNIVERSITARIO POLITÉCNICO “SANTIAGO MARIÑO” EXTENSIÓN PORLAMAR Sistemas I Bachiller: Mariannys Bermúdez Porlamar, 12 de marzo 2017
• 2.
  Modelo de Ciclode Vida en Cascada Desde el inicio el ciclo de vida de un plan software incluye todos los trabajos que se realizan sobre él desde que se especifican las particulares que debe tener, hasta que se conserva en operación. A veces (aunque no será éste nuestro caso) se contienen en el ciclo de vida las transformaciones que pueden ejecutar al sistema para acomodar a nuevas especificaciones. Podría pensarse que el ciclo de vida de un programa no tiene por qué seguir un desarrollo "lineal", entendiendo como tal una sucesión de etapas. Uno de estos modelos del ciclo de vida, quizás el más ampliamente utilizado, es el del desarrollo en cascada. En él, cada etapa deja el camino preparado para la siguiente, de forma que esta última no debe comenzar hasta que no ha acabado aquélla. De esta forma, se reduce mucho la complejidad de la gestión, ya que basta con no dar por terminada una etapa hasta que haya cumplido totalmente con sus objetivos. En cuantos los beneficios que se debe tener en cuenta que un proyecto sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. Para eso tenemos que ver el que no se siga una secuencia lineal, no es error del modelo, sino del garante de proteger. no suele establecer al principio todos los requisitos necesarios. Esto provoca que el modelo no se ajuste al gran número de nuevos requisitos y cambios en otros requisitos existentes, que se van a producir. Sí, vale, pero hay que matizar que la culpa no es del cliente. Un buen analista debe llegar a conocer el negocio del cliente, y debe extraer sus necesidades. Si nos tenemos que basar en lo que nos cuenta el cliente de forma exclusiva, estamos listos (y además, estamos pagando innecesariamente un analista). El modelo de ciclo de vida en cascada no nos indica nada acerca de la relación contractual existente entre el cliente y la organización encargada del desarrollo de software. Desde el punto de vista de una empresa de desarrollo de software, formalizar la firma de un contrato al final de la etapa de análisis, por ejemplo, puede ayudar a reducir el riesgo que supone elaborar un presupuesto cuando aún no se dispone de toda la información necesaria para que la estimación del esfuerzo requerido por el proyecto sea lo suficientemente precisa. Este tipo de contrato obliga a que el cliente se haga cargo de los costes adicionales ocasionados por cambios en los requerimientos, mientras que la empresa de desarrollo de software deberá asumir los gastos ocasionados si el producto finalmente entregado no cumple todas las condiciones pactadas a la firma del contrato. Un modelo contractual como el descrito en el párrafo anterior no siempre resulta aceptable para el cliente, que puede verse obligado a invertir dinero a cambio de nada. Esto podría pasar si, tras la etapa de análisis, el proyecto se desestima por no ser técnica o económicamente viable. Es más, si el cliente acepta a regañadientes la firma de un contrato al final de la etapa
• 3.
  de análisis, laimagen de la empresa desarrolladora de software puede verse seriamente deteriorada en cuanto surja cualquier tipo de problema. Para limar las asperezas que pueden surgir en la relación cliente- proveedor y mejorar el rendimiento del equipo del proyecto, hoy en día se suele recurrir a modelos iterativos como los que se describirán a continuación. El diseño de este tipo de ciclo es un proceso multipaso que se centra en cuatro atributos diferentes de los programas: estructura de datos, arquitectura del software, detalle del proceso y caracterización de las interfases. El proceso de diseño representa los requerimientos en una forma que permita la codificación del producto (además de una evaluación de la calidad previa a la etapa de codificación). Al igual que los requerimientos, el diseño es documentado y se convierte en parte del producto de software. El ciclo de vida clásico es el paradigma más viejo y el más ampliamente usado en la ingeniería del software. Sin embargo, su aplicabilidad en muchos campos ha sido cuestionada. Entre los problemas que aparecen cuando se aplica el modelo cascada están: Los proyectos raramente siguen el flujo secuencial que el modelo propone. La iteración siempre es necesaria y está presente, creando problemas en la aplicación del modelo. A menudo es difícil para el cliente poder especificar todos los requerimientos explícitamente. El modelo de vida del software clásico requiere esto y presenta problemas acomodando la incertidumbre natural que existe al principio de cualquier proyecto. El cliente debe ser paciente. Una versión funcional del sistema no estará disponible hasta tarde en la duración del desarrollo. Cualquier error o malentendido, si no es detectado hasta que el programa funcionando es revisado, puede ser desastroso. Cada uno de estos problemas es real. Sin embargo, el modelo clásico del ciclo de vida del software tiene un lugar bien definido e importante en los trabajos de ingeniería del software. Provee un patrón dentro del cual encajan métodos para el análisis, diseño, codificación y mantenimiento. La metodología de cascada ordena rigurosamente las etapas del ciclo del software, es decir en este modelo se tienen que terminar las fases en un orden, para poder pasar a la siguiente etapa. Este modelo es el mas usado en la actualidad; El modelo de cascada es exitoso cuando se tienen bien específicos los requerimientos del software y se conozcan las herramientas a utilizar. El modelo de cascada tarda mucho tiempo en resolver un software, ya que hasta que no se tenga bien el software, no se opera el software Lo que puedo mencionar es que el modelo cascada es una de las metodologías que al llevarse a cabo se debe de llevar a cabo fase por la fase el modelo de cascada nos permite realizar una organización más fácil de comprender tratando