Ingeniería del software

Presentación del tema: "Ingeniería del software"— Transcripción de la presentación:

1 Ingeniería del software
Prof. Norka Pareles

2 El ciclo de vida que permite el desarrollo de un software involucra:
Comprensión de los requerimientos Análisis de los requerimientos Diseño del sistema Implementación Prueba Mantenimiento.

3 El éxito de un desarrollo de software depende de:
La total compresión de los requerimientos del software. No importa lo bien codificado y estructurado que este un programa si no se ha analizado correctamente, pues defraudara al usuario y frutara al desarrollador

4 La tarea del análisis Es un proceso de descubrimiento, refinamiento, modelado y especificación. Se crean modelos de requerimientos de datos, flujo de información y control y del comportamiento operativo. Se analizan soluciones alternativas y se asignan a diferentes elementos del software.

5 Herramientas para determinar requerimientos de sistemas
Actividades en la determinación de requerimientos Actividad Descripción Anticipación de los requerimientos Preveer las características del sistema con base en la experiencia previa. Esto puede llevar al análisis a investigar áreas y aspectos que de otra forma no serian tomados en cuenta. Investigación de los requerimientos Estudio y documentación del sistema actual utilizando para ello técnicas para halar hechos, análisis de flujo de datos y análisis de decisión. Especificación de los requerimientos Análisis de los datos que describen el sistema para determinar qué requerimientos se deben satisfacer y las estrategias para alcanzarlos.

6 Papel del Analista de Sistemas
El analista requiere tener habilidades de trato para cualquier tipo de persona, así como también tener la debida experiencia en el manejo de computadoras. El analista protagoniza numerosos papeles, y en ocasiones, se ve obligado a mantener un equilibrio, al asumir simultáneamente mas de uno. Kendall y kendall “análisis y diseño de sistemas” 1991

7 Ciclo de vida de desarrollos de los sistemas
Identificación del problema oportunidades y objetivos. Determinación de requerimientos de información. Análisis de las necesidades del sistema. Diseño del sistema recomendado. Desarrollo y documentación del software. Prueba y mantenimiento del sistema. Implementación y evaluación del sistema. Kendall y kendall “análisis y diseño de sistemas” 1991

8 Identificación del problema oportunidades y objetivos
La identificación de objetivos también es un componente importante en esta primera fase. En primera instancia el analista deberá descubrir lo que la empresa desea realizar. Y luego, estará en posibilidad de determinar si el uso de los sistemas de información apoyaría a la empresa para alcanzar sus metas, el encaminarlas a problemas u oportunidades especificas. Kendall y kendall “análisis y diseño de sistemas” 1991

9 Determinación de requerimientos de información
Para identificar los requerimientos de información dentro de la empresa, pueden utilizarse diversos instrumentos, los cuales incluye: el muestreo, el estudio de los datos y formas usadas por la organización, la entrevista, los cuestionarios; la observación de conducta de quien toma la decisiones, así como de su ambiente; y también el desarrollo de prototipos. Kendall y kendall “análisis y diseño de sistemas” 1991

10 Análisis de las necesidades del sistema
La siguiente etapa que ejecuta el análisis de sistema consiste en analizar las necesidades propias del sistema. Una vez mas, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas. Estas incluyen el uso de los diagramas de flujo de datos que cuentan con una técnica estructurada para presentar en forma grafica la entrada de los datos de la empresa los procesos y salidas de la información. Kendall y kendall “análisis y diseño de sistemas” 1991

11 Diseño del sistema recomendado
En esta etapa, el analista de sistema usa la información que recolecto con anterioridad y elabora el diseño lógico del sistema de información. El analista diseña el procedimiento preciso de captura de datos, con el fin de que los datos que se introducen al sistema sean correctos. El analista también diseña accesos efectivos al sistema de información, mediante el uso de las técnicas de diseño de formas y de pantallas. Kendall y kendall “análisis y diseño de sistemas” 1991

12 Desarrollo y documentación del software
Durante esta fase, el analista también colabora con los usuarios para desarrollar la documentación indispensable del software, incluyendo los manuales de procedimiento. La documentación le dirá a los usuarios como operar el software, y así también, que hacer en caso de presentarse algún problema. Kendall y kendall “análisis y diseño de sistemas” 1991

13 Prueba y mantenimiento del sistema
El sistema de información debe de probarse antes de utilizarlo. El costo es menor si se detectan los problemas antes de la entrega del sistema. El programador realiza alguna pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista del sistema. En un principio se hace una serie de pruebas , con datos tipo, para identificar las posibles fallas del sistema; mas adelante, utilizando los datos del sistema real. Kendall y kendall “análisis y diseño de sistemas” 1991

14 Implementación y evaluación del sistema
En esta ultima etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de información. Esto incluye el adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales, la supervisión del adiestramiento es una responsabilidad del analista de sistema. Más aún, el analista necesita plantear la suave transición que trae consigo un cambio de sistema. Kendall y kendall “análisis y diseño de sistemas” 1991

15 Que son el análisis y el diseño?
Análisis: investigación. El análisis se concentra en al investigación del problema, no en la manera de definir una solución. Por ejemplo, si se desea un nuevo sistema de información computarizada de la biblioteca ¿Cuáles procesos de la institución se relacionan con su uso? Diseño: solución. El diseño pone de relieve una solución lógica: como el sistema cumple con los requerimientos. He ahí un ejemplo: ¿ de que manera el software del sistema de información de la biblioteca capturara y registrara los prestamos de los libros?. En definitiva, los diseños se implantan en software y hardware Craig Larman “UML Y PATRONES” 1999

16 Que son el análisis y el diseño orientado a objetos?
Análisis orientado a objetos: ¿conceptos?. Consiste en situar el dominio de un problema y una situación lógica dentro de la perspectiva de los objetos (cosas, conceptos o entidades). Diseño orientado a objetos: ¿objetos de software?. Durante el análisis orientado a objeto se procura ante todo identificar y describir los objetos o concepto, dentro del dominio del problema. Por ejemplo, en el caso del sistema de información de la biblioteca, alguno de los conceptos son libros, biblioteca y clientes. Craig Larman “UML Y PATRONES” 1999

17 Un ejemplo del análisis y del diseño orientado a objetos
Ejemplo simple: “juego de dados” en que un jugador lanza dos dados. Si el total es 7, gana y de lo contrario pierde. Definir casos de uso Definir el modelo conceptual Definir los diagramas de colaboración Definir los diagramas de Diseño de clases

18 Definición de los casos de uso
Los casos de uso no son propiamente un elemento de análisis orientado a objetos; se limitan a describir procesos y pueden ser igualmente eficaces en un proyecto de tecnologia no orientada a objeto. No obstante, constituye un paso preliminar muy util porque describen las especificaciones de un sistema. Definir casos de uso Definir el modelo conceptual Definir los diagramas de colaboración Diseño de clases Craig Larman “UML Y PATRONES” 1999

19 Ejemplo. Caso de uso: juega un juego Participantes: jugador
Descripción: este caso de uso comienza cuando el jugador recoge y hace rodar los dados. Si los puntos suman 7, gana y pierde si suma cualquier otro numero. Craig Larman “UML Y PATRONES” 1999

20 Definición de un modelo conceptual
El análisis orientado a objetos tiene por finalidad estipular una especificación del dominio del problema y los requerimientos desde la perspectiva de la clasificación por objetos y desde el punto de vista de entender los términos empleados en el dominio. Para descomponer el dominio del problema hay que identificar los conceptos, los atributos y las asociaciones del dominio que se juzgan importantes Definir casos de uso Definir el modelo conceptual Definir los diagramas de colaboración Definir los diagramas de Diseño de clases Craig Larman “UML Y PATRONES” 1999

21 Ejemplo. Como se aprecia en la siguiente figura en el dominio del juego de dados, una parte del modelo conceptual muestra los conceptos jugador, dados, y juegodedados, sus asociaciones y atributos Jugador Nombre Dados valormostrado Juegodedados Lanzar 2 1 Juega 2 Incluye El modelo conceptual no es una descripción de los componentes del software; representa los conceptos en el dominio del problema en el mundo real. Craig Larman “UML Y PATRONES” 1999

22 Definición de los diagramas de colaboración
El diseño orientado a objeto tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales, basándose en la descomposición por clases de objetos. Un paso esencial de esta fase es la asignación de responsabilidades entre los objetos y mostrar cómo interactúan a través de mensajes, expresados en diagramas de colaboración. Definir casos de uso Definir el modelo conceptual Definir los diagramas de colaboración Definir los diagramas de Diseño de clases Craig Larman “UML Y PATRONES” 1999

23 Ejemplo. Supongamos que se desea una simulación en el software del juego de dados. El diagrama de colaboración. Como se muestra en el siguiente diagrama, muestra gráficamente el paso esencial del juego, enviando el mensaje a las instancias de clases jugador y dados. Jugar() :jugador 1: r1 := lanzar d1:Dado 2: r2 := lanzar d2:Dado Craig Larman “UML Y PATRONES” 1999

24 Definición del diseño de clases
Para definir una clase es preciso contestar varias preguntas: Como se conectan unos objetos a otros? Cuales son los métodos de una clase? Definir casos de uso Definir el modelo conceptual Definir los diagramas de colaboración Definir los diagramas de Diseño de clases Craig Larman “UML Y PATRONES” 1999