1.
UNIVERSIDAD TECNICA PARTICULAR DE LOJA INGENIERÍA DE SOFTWARE PRÁCTICA DE LA INGENIERÍA DEL SOFTWARE UNA VISIÓN GENERAL “ La Universidad Católica de Loja “ Elba Encalada Margarita Nero

2.
CÓMO SE ENCUENTRA EL DESARROLLO DE SOFTWARE EN ECUADOR <ul><li>Sólo 17 de las 32 empresas que existen en Ecuador se sometieron al estudio de las siguientes estadísticas </li></ul>Fuente: Tesis de Ingeniería de Gestión Universidad Santa Maria-Campus Guayaquil

3.
INTRODUCCIÓN <ul><li>La práctica es una colección de conceptos, principios, métodos y herramientas a las que un ingeniero de software recurre a diario </li></ul><ul><li>La práctica transforma un enfoque fortuito en algo más organizado, más efectivo y con más probabilidades de alcanzar el éxito. </li></ul><ul><ul><li>¿Quién lo hace? </li></ul></ul><ul><ul><li>¿Por qué es importante? </li></ul></ul><ul><ul><li>Cuáles son los pasos? </li></ul></ul><ul><ul><li>¿Cómo puedo estar seguro de que lo he hecho correctamente? </li></ul></ul>

4.
PRÁCTICA DE LA INGENIERÍA DE SOFTWARE <ul><li>Los pasos considerados para solucionar un problema: </li></ul><ul><ul><li>Entender el problema (comunicación y análisis) </li></ul></ul><ul><ul><li>Planear una solución (modelado y diseño de software) </li></ul></ul><ul><ul><li>Llevar a cabo el plan (generación de código) </li></ul></ul><ul><ul><li>Examinar el resultado para probar la precisión (realización de pruebas y aseguramiento de la calidad) </li></ul></ul>

5.
PRINCIPIOS ESENCIALES <ul><ul><li>La razón por la que todo existe: ofrecer un valor a sus usuarios </li></ul></ul><ul><ul><li>MS (mantenerlo simple): todo el diseño debe ser tan simple como sea posible, simple no significa rápido y malo. </li></ul></ul><ul><ul><li>Mantener la visión: una visión clara es esencial para el éxito de un proyecto de desarrollo. </li></ul></ul><ul><ul><li>Lo que uno produzca, otros lo consumirán: el hecho de facilitar el trabajo a otro agrega valor al sistema. </li></ul></ul><ul><ul><li>Estar abierto al futuro: un sistema con una larga vida tiene más valor. </li></ul></ul><ul><ul><li>Planear para la reutilización: ahorra tiempo y esfuerzo. </li></ul></ul><ul><ul><li>Pensar: pensamiento claro y completo antes de la acción </li></ul></ul>

6.
PRÁCTICA DE COMUNICACIÓN <ul><li>Todos los requisitos deben recopilarse por medio de la comunicación: </li></ul><ul><li>Escuchar </li></ul><ul><li>Prepararse antes de comunicar </li></ul><ul><li>Alguien debe facilitar la actividad </li></ul><ul><li>La comunicación cara a cara es lo mejor </li></ul><ul><li>Tomar nota y documentar las decisiones </li></ul><ul><li>Buscar la colaboración </li></ul><ul><li>Conservar el enfoque, examinar un módulo a la vez </li></ul><ul><li>Si algo no está claro, se hace un dibujo </li></ul><ul><li>Una vez que se llega a un acuerdo de debe continuar </li></ul><ul><li>La negociación no es un concurso o un juego </li></ul>

7.
PRÁCTICAS DE LA PLANEACIÓN <ul><li>La actividad de planeación permite definir el camino mientras se tiene presente una meta estratégica y unos objetivos. </li></ul><ul><li>Entender los alcances del proyecto </li></ul><ul><li>Involucrar al cliente en la actividad de planeación </li></ul><ul><li>Reconocer que la actividad es iterativa </li></ul><ul><li>Estimar con base en el conocimiento disponible </li></ul><ul><li>Considerar el riesgo cuando se define el plan </li></ul><ul><li>Ser realista </li></ul><ul><li>Ajustar la granularidad mientras se define el plan </li></ul><ul><li>Definir como se intentará asegurar la calidad </li></ul><ul><li>Definir como se pretende incluir el cambio </li></ul><ul><li>Adaptar el plan a menudo y hacer ajustes cuando estos se requieran </li></ul>

8.
PRINCIPIO W5HH <ul><li>Why, what, when, who, where, how, how </li></ul><ul><li>Principio de Barry Boehm, se basa en una serie de pregunta que conducen a una definición de características claves del proyecto y el plan de proyecto resultante. </li></ul><ul><ul><li>¿Por qué está en desarrollo este sistema? </li></ul></ul><ul><ul><li>¿Qué se hará? </li></ul></ul><ul><ul><li>¿Cuándo se terminará? </li></ul></ul><ul><ul><li>¿Quién es el responsable de una función? </li></ul></ul><ul><ul><li>¿En donde se ubica dentro de la organización? </li></ul></ul><ul><ul><li>¿Cómo se realizará el trabajo en los sentidos técnico y de gestión? </li></ul></ul><ul><ul><li>¿Cuánto se necesita de cada recurso? </li></ul></ul>

9.
<ul><li>Los modelos se crean para obtener un mejor entendimiento de la realidad. Existen dos modelos en la Ingeniería de Software: </li></ul><ul><li>Modelo de Análisis </li></ul><ul><li>Modelo de Diseño </li></ul>PRÁCTICAS DE MODELADO

10.
MODELO DE ANÁLISIS <ul><li>Representar los requisitos del cliente en tres dominios: dominio de la información, dominio funcional y dominio del comportamiento </li></ul><ul><li>Representación conceptual correspondiente al problema y modelo de requisitos (conjunto de clases) cada clase aporta para lograr la arquitectura deseada </li></ul><ul><li>No se considera el ambiente de implementación </li></ul>

11.
MODELO DE DISEÑO <ul><li>Como el plano para la construcción de una casa </li></ul><ul><li>Refinamiento y formalización adicional del modelo de análisis tomando en cuenta los detalles de implementación </li></ul><ul><li>El resultado del modelo de diseño son especificaciones mucho más detalladas en cuanto a que se incluyen operaciones y atributos de los objetos </li></ul><ul><li>Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficientemente formal para alcanzar el código fuente </li></ul>

12.
PRINCIPIOS DEL MODELADO DEL ANÁLISIS <ul><li>El dominio de información de un problema debe representarse y entenderse. </li></ul><ul><li>Definir las funciones que ejecuta el software. </li></ul><ul><li>Se debe representar el comportamiento del software. </li></ul><ul><li>Los modelos que representan información, función, y comportamiento deben partirse de forma que descubran el detalle de una manera estratificada.- “divide y vencerás”. </li></ul><ul><li>La tarea del análisis debe moverse de la información esencial hacia el detalle de la implementación </li></ul>

13.
PRINCIPIOS DE MODELADO DE DISEÑO <ul><li>Como el plano de una casa, proporciona diferentes vistas del sistema </li></ul><ul><li>El diseño debe ser rastreable hasta el modelo de análisis. </li></ul><ul><li>Siempre se debe considerar la arquitectura del sistema que se va a construir. </li></ul><ul><li>El diseño de datos es tan importante como el diseño de funciones de procesamiento. </li></ul><ul><li>Las interfaces deben diseñarse con cuidado. </li></ul><ul><li>El diseño de interfaz de usuario debe ajustarse a las necesidades del usuario final. </li></ul>

14.
<ul><li>Los componentes deben estar apareados entre sí en forma mínima y vinculados con el ambiente externo </li></ul><ul><li>Las representaciones del diseño deben ser fácilmente comprensibles </li></ul><ul><li>El diseño debe desarrollarse de manera iterativa. En cada iteración el diseñador debe buscar la mayor simplicidad </li></ul><ul><li>Cuando se tienen presente los principios antes mencionados se logra que los clientes puedan observar velocidad, confiabilidad, y facilidad de uso </li></ul>

15.
PRÁCTICA DE LA CONSTRUCCIÓN <ul><li>Abarca lo que es la actividad de generación de código y la realización de pruebas antes de que es software sea entregado </li></ul><ul><li>Las pruebas con frecuencia se las realiza a nivel de componentes, llamadas pruebas de unidad </li></ul><ul><li>También existen pruebas de validación (lo que requiere el cliente), integración, aceptación (facilidad de manejo de software) </li></ul>

16.
PRINCIPIOS Y CONCEPTOS DE CODIFICACIÓN <ul><li>Principios de preparación.- antes de codificación, entender el problema, elegir el lenguaje de programación, crear un conjunto de pruebas de unidad </li></ul><ul><li>Principios de codificación.- entender la arquitectura, crear interfaces acordes con la misma, mantener la lógica tan simple como sea posible, nombres de variables significativas, documentación del código, configuración lineal </li></ul><ul><li>Principios de validación.- realizar pruebas de unidad, corregir errores descubiertos, refabricación de l código </li></ul>

17.
PRINCIPIOS DE PRUEBAS <ul><li>Una prueba exitosa es aquella que logra encontrar errores con un gasto mínimo de tiempo y esfuerzo </li></ul><ul><li>Todas las pruebas deben ser rastreables hasta los requisitos del cliente </li></ul><ul><li>Las pruebas deben planearse mucho antes de que empiece el proceso de pruebas </li></ul><ul><li>El principio de Pareto es aplicable para las pruebas de software </li></ul><ul><li>Las pruebas deben comenzar “en lo pequeño” y progresar hacia “lo grande”.- primero enfocadas a componentes, luego a nivel de componentes integrados </li></ul><ul><li>Las pruebas exhaustivas no son posibles .- imposible ejecutar cada combinación de rutas para las pruebas </li></ul>

18.
PRÁCTICAS DE DESPLIEGUE <ul><li>Entrega, soporte y retroalimentación, como el software es evolutivo se tienen varios despliegues </li></ul><ul><li>Se deben administrar las expectativas que el cliente tiene del software.- no dar a pensar más de lo que se puede entregar </li></ul><ul><li>Se debe ensamblar y probar un paquete de entrega completo </li></ul><ul><li>Se debe establecer un régimen de soporte antes de entregar el software </li></ul>

19.
<ul><li>Se debe proporcionar un material instructivo apropiado a los usuarios finales.- diferencia entre cada incremento </li></ul><ul><li>El software con errores se debe arreglar primero y entregar después.- no entregar incrementos de baja calidad </li></ul><ul><li>El equipo de software debe recopilar y registrar la retroalimentación para poder hacer cambios en el siguiente incremento o en el mismo incremento si es necesario </li></ul>

20.
CONCLUSIONES <ul><li>La práctica de la Ingeniería del Software nos orienta como debemos llevar cada una de las actividades principales dentro del marco de trabajo definido para el desarrollo de software </li></ul><ul><li>Para cada actividad del marco de trabajo de desarrollo de software existen principios de práctica </li></ul><ul><li>Existen prácticas de comunicación, planeación, modelado, construcción y despliegue </li></ul>

21.
BIBLIOGRAFÍA <ul><li>PRESSMAN ROGER S: Ingeniería del Software (Un enfoque práctico): Sexta Edición. </li></ul><ul><li>WEITZENFELD ALFREDO: Ingeniería de Software Orientado a objetos con UML , Java e internet </li></ul><ul><li>ftp://ftp.itam.mx/pub/alfredo/OBJETOS/OMT/Modobi.pdf </li></ul><ul><li>http://www.usm.edu.ec/tesis/gestion-de-calidad/pdf/cap_2.pdf </li></ul>