Soporte Tecnico Y Programador WEB

La “M CASE” ó la middle CASE se compone de la U-CASE y de la L-CASE. Esta herramienta tiene 3 principales objetivos como son:

Análisis detallado.

Diseño detallado.

Implementación.

Empezamos con la parte del análisis. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o en si contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, esta estructura puede ser definida por varios estándares, tales como la captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una de las partes más importantes, ya que cada fase conlleva a otra, y si alguna de estas falla todo el proyecto no es ambiguo; esta etapa depende en gran medida el logro de los objetivos finales siempre y cuando buscando ser eficaces y logrando hacerlo en el menor tiempo posible para así satisfacer al cliente

La etapa del diseño detallado. Ésta etapa se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, el software, etc. Se definen los casos de uso para cubrir y ver las funciones de cada persona dentro de la empresa que realizara el sistema y se transformaran las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo así un modelo cercano a la programación orientada a objetos, tales como java, C#, etc.

Y por último, la muy importante etapa de la implementación. Esta etapa trata más que nada en reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga. El grado de dificultad y la duración de esta etapa está íntimamente ligada al o a los lenguajes de programación utilizados.

Hemos examinado los significados diferentes de los modelos de análisis que podemos encontrar dentro de esta herramienta. Es bastante frecuente confundir estas concepciones. En cambio, sería bueno ver la tarea de análisis como aquélla en la que se construyen ambos modelos, estrechamente relacionados y a la vez adecuadamente distinguidos entre si. Si tiene que utilizar la palabra “análisis” en el modo que el ingeniero de software, escoja el sentido que prefiera, pero sea consciente de su elección y de los posibles malentendidos con el cliente y los desarrolladores.

(2010, 9).HERRAMIENTAS CASE, 2012, de http://www.ecured.cu/index.php/Herramienta_CASE#Tecnolog.C3.ADa_de_las_herramientas_CASE

...