Expoicioningenieria del software eddy

  • 558 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
558
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1.
    • INGENIERIA DEL SOFTWARE
    • EXPOSICION POR:
    • YASMIN GARZON
    • EDDY G BENAVIDES
  • 2. Ciclo de vida clásico y construcción de prototipos
  • 3. Método del ciclo de vida clásico
    • El método del ciclo de vida para desarrollo de sistemas, es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información.
  • 4.
    • EL MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CONSTA DE LAS SIGUIENTES ACTIVIDADES
  • 5. Investigación preliminar
    • La solicitud para recibir ayuda de un sistema de información pueden originarse por una persona, cuando se formula la solicitud comienza la primera actividad del sistema. Esta actividad tiene tres partes:
  • 6. aclaración de la solicitud
    • Antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe examinarse para determinar con precisión lo que el solicitante desea; ya que muchas solicitudes que provienen de empleados y usuarios no están formuladas de manera clara.
  • 7. Estudio de factibilidad
    • En la investigación preliminar un punto importante es determinar que el sistema solicitado sea factible. Existen tres aspectos relacionados con el estudio de factibilidad, que son realizados por los general por analistas capacitados o directivos.
  • 8. Factibilidad técnica.
    • Estudia si el trabajo para el proyecto, puede desarrollarse con el software y el personal existente, y si en caso de necesitar nueva tecnología, cuales son las posibilidades de desarrollarla (no solo el hardware).
  • 9. Factibilidad económica.
    • Investiga si los costos se justifican con los beneficios que se obtienen, y si se ha invertido demasiado, como para no crear el sistema si se cree necesario.
  • 10. Factibilidad operacional
    • Investiga si será utilizado el sistema, si los usuarios usaran el sistema, como para obtener beneficios.
  • 11. Aprobación de la solicitud
    • Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes.
    • Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal
  • 12. Determinación de los requisitos del sistema.
    • Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de un cliente para dar respuesta a ciertas preguntas claves.
    • Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa.
    • Cuando no es posible entrevistar, en forma personal a los miembros de grupos grandes dentro de la organización, se emplean cuestionarios para obtener esta información.
    • Reunidos los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema.
  • 13. Diseño del sistema.(diseño lógico)
    • El diseño de un sistema de información responde a la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis.
    • Es común que los diseñadores hagan un esquema del formato o pantalla que esperan que aparezca cuando el sistema esta terminado, se realiza en papel o en la pantalla de una terminal utilizando algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.
  • 14. Desarrollo de software (diseño físico). Los encargados de desarrollar software pueden instalar software comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Los programadores son responsables de la documentación de los programas y de explicar su codificación, esta documentación es esencial para probar el programa y hacer el mantenimiento.
  • 15. Prueba de sistemas.
    • Durante esta fase, el sistema se emplea de manera experimental para asegurarse que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema, para que los analistas observen si tratan de emplearlo en formas no previstas, antes de que la organización implante el sistema y dependa de él.
    • En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribió los programas originales; para asegurarse de que las pruebas sean completas e imparciales y, por otra, que el software sea más confiable.
  • 16. Implantación y evaluación.
    • La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.
    • Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.
    • Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso de constante evolución.
    • La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones.
    •  
    •  
  • 17. MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado. Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas: estándares para describir y documentar el sistema en forma correcta y completa. Diseño Estructurado : El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.
  • 18.
    • Análisis de flujo de datos : Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.
    • Herramientas: Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.
    • Diagrama de flujo de datos: Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes.
  • 19. MÉTODO DEL PROTOTIPO DE SISTEMAS
    • El método del prototipo de sistemas consta de 5 etapas:
    • 1). Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es tan importante para el método de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado.
    • 2). Desarrollo de un modelo de trabajo: Es fácil comenzar el procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interacción es de gran ayuda.
    • a). El lenguaje para el dialogo o conversación entre el usuario y el
    • sistema.
    • b). Pantallas y formatos para la entrada de datos.
    • c). Módulos esenciales de procesamiento.
    • d). Salida del sistema
  • 20.
    • 3). Utilización del prototipo: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación.
    • 4). Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.
    • 5). Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
  • 21. CONSTRUCCION DE PROTOTIPOS
    • A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humana – máquina, entonces en este caso cuando utilizamos la construcción de prototipos.
  • 22.  
  • 23. VENTAJAS
    • Ø      No modifica el flujo del ciclo de vida.
    • Ø      Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
    • Ø      Reduce costos y aumenta la probabilidad de éxito.
    • Ø      Exige disponer de las herramientas adecuadas.
    • Ø      No presenta calidad ni robustez.
    • Ø      Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.
  • 24. DESVENTAJAS
    • A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos se torna problemática por las siguientes razones:
    • Ø      El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “chicle y cable para embalaje”, y puede decepcionarse al indicarle que el sistema aun no ha sido construido.
    • Ø      El desarrollador puede caer en la tentación de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.
    •  
  • 25. Los pasos necesarios para la construcción de prototipos son los siguientes
    • I. Evaluar la solicitud del software para determinar si el sistema es candidato para la construcción de un prototipo. Considerando si es necesario presentar la interacción usuario-sistema y tomando en cuenta la complejidad del desarrollo del propio prototipo.
    • II. Elaborar una representación abreviada de los requisitos. Utilizando alguno de los modelos mencionados anteriormente.
    • III. Crear un conjunto de especificaciones de diseño para el prototipo. Centrandose en los aspectos de mas alto nivel y no en el detalle.
    • IV. Crear y probar el software del prototipo. De ser posible utilizar herramientas automatizadas para tal efecto, como lenguajes de cuarta generación, módulos de código reusables, herramientas RAD o paquetes especializados en prototipos.
    • V. Presentar el prototipo al usuario y orientarlo a que sea él quien lo “opere”. Aquí es donde el usuario podrá validar sus propios requerimientos y sugerir las modificaciones necesarias.
    • VI. Repetir los pasos IV y V hasta que todos los requisitos queden formalizados.
  • 26.