Selección de tecnicas de ingenieria de software

1,834 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,834
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Selección de tecnicas de ingenieria de software

  1. 2. ¿Existe alguna diferencia entre programa, software y aplicación? Describa la definición de cada uno de estos términos, relaciónelos y posteriormente encuentre las diferencias (si las hay), o las similitudes (si las hay) <ul><li>Un programa informático es un conjunto de instrucciones que una vez ejecutadas realizarán una o varias tareas en una computadora . </li></ul><ul><li>Una aplicación es un tipo de programa informático diseñado como herramienta para permitir a un usuario realizar uno o diversos tipos de trabajo. </li></ul><ul><li>Software se refiere al equipamiento lógico o soporte lógico de una computadora digital, y comprende el conjunto de los componentes lógicos necesarios para hacer posible la realización de tareas específicas. </li></ul>
  2. 3. Las Diferencias. <ul><li>Las diferencias entre Programa, Aplicación y Software es que un programa son simplemente instrucciones que al ejecutarlas realizaran una actividad, una aplicación es un tipo de programa que permite realizar diversos tipos de trabajo y software es todo el equipamiento lógico de una computadora es decir todo lo que necesita para realizar diversas tareas especificas. </li></ul>
  3. 4. ¿Qué es ingeniería? <ul><li>Es el conjunto de conocimientos y técnicas aplicadas, que se dedica a la solución u optimización de los problemas que afectan a la humanidad. </li></ul>
  4. 5. ¿Qué es ingeniería de software? <ul><li>Es una disciplina o área de la informática que se encarga de proporcionar métodos y técnicas para poder desarrollar y mantener software de calidad </li></ul>
  5. 6. ¿Por qué se dice que “el software no se crea ni se construye, si no se desarrolla”? <ul><li>se dice porque desde la idea se comienza luego pasamos a la planeación, y a medida que se avanza en el desarrollo el software puede tener cambios y modificaciones es más aun después de estar ya implementado dicho software puede tener modificaciones quiere decir que ese software sigue en desarrollo casi permanentemente. </li></ul>
  6. 7. ¿ Qué es calidad? <ul><li>Calidad es la capacidad de un producto de satisfacer necesidades de manera correcta e irreprochable. </li></ul>
  7. 8. ¿Qué es calidad de software? <ul><li>Calidad de software es aquel que supla las necesidades del usuario para el que fue desarrollado en pocas palabras que cumpla con los siguientes requerimientos: mantenible, confiable y aceptable. </li></ul>
  8. 9. ¿Por qué se dice “no hay software terminado”? <ul><li>Porque siempre el software necesitara corrección de errores y actualizaciones en sus funciones para adaptarse a las necesidades del usuario . </li></ul>
  9. 10. ¿En qué consiste un proyecto de desarrollo de software? <ul><li>Consiste en establecer claramente el tiempo que durara el proyecto, las fechas en que se realizara cada etapa y el personal que será necesario para llevar a cabo con éxito dicho proyecto. </li></ul>
  10. 11. ¿Cuáles son las etapas del desarrollo de software? <ul><li>Análisis de requisitos </li></ul><ul><li>Extraer los requisitos de un producto de software es la primera etapa para crearlo. 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 contradictorios </li></ul>
  11. 12. <ul><li>Especificación </li></ul><ul><li>La Especificación de Requerimientos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requerimientos del software. </li></ul>
  12. 13. <ul><li>Arquitectura </li></ul><ul><li>La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura </li></ul>
  13. 14. <ul><li>. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validadoUn diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo: </li></ul><ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de base de datos </li></ul><ul><li>Diagramas de despliegue plegados </li></ul><ul><li>Diagramas de secuencia multidireccional </li></ul><ul><li>Diagramas de infraestructura quimica </li></ul><ul><li>Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. </li></ul>
  14. 15. <ul><li>Programación. </li></ul><ul><li>Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado. </li></ul>
  15. 16. <ul><li>Prueba </li></ul><ul><li>Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas . </li></ul>
  16. 17. <ul><li>El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría. </li></ul>
  17. 18. <ul><li>Documentación </li></ul><ul><li>Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones ( UML ), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. </li></ul>
  18. 19. <ul><li>Mantenimiento </li></ul><ul><li>Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs . La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento. </li></ul>
  19. 20. ¿Cuál es la diferencia entre el termino ingeniería de software y el simple desarrollo o producción de software? <ul><li>El desarrollo de software (si bien es parte de los objetivos de la ingeniería del software), hace referencia solamente a la programación de software. No incluye todos los procesos inherentes a la ingeniería del software. </li></ul>
  20. 21. <ul><li>Y en la ingeniería de software se llevan a cabo cuidadosamente todas y cada una de las etapas del desarrollo de software para crear software de calidad </li></ul>
  21. 22. ¿Cuáles son los modelos de desarrollo de software? <ul><li>Definición </li></ul><ul><li>Representación abstracta de un modelo de software que se utiliza para explicar diferentes enfoques del desarrollo de software . </li></ul>
  22. 23. <ul><li>Modelo cascada: </li></ul><ul><li>Una etapa después de la otra de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. </li></ul><ul><li>Un ejemplo de una metodología de desarrollo en cascada es: </li></ul><ul><li>Análisis de requisitos </li></ul><ul><li>Diseño del Sistema </li></ul><ul><li>Diseño del Programa </li></ul>
  23. 24. <ul><li>Codificación </li></ul><ul><li>Pruebas </li></ul><ul><li>Implantación </li></ul><ul><li>Mantenimiento </li></ul><ul><li>De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado </li></ul>
  24. 25. <ul><li>Modelo en Espiral </li></ul><ul><li>El desarrollo en espiral es un modelo utilizado generalmente en la Ingeniería de software . Las actividades de este modelo se conforman en una espiral , en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior. </li></ul>
  25. 26. <ul><li>En cada vuelta o iteración hay que tener en cuenta </li></ul><ul><li>Los Objetivos: Que necesidad debe cubrir el producto. </li></ul><ul><li>Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: </li></ul><ul><li>Características: experiencia del personal, requisitos a cumplir, etc. </li></ul><ul><li>Formas de gestión del sistema. </li></ul><ul><li>Riesgo asumido con cada alternativa. </li></ul><ul><li>Desarrollar y Verificar: Programar y probar el software. </li></ul>
  26. 27. <ul><li>Desarrollo por etapas </li></ul><ul><li>El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código. </li></ul>
  27. 28. <ul><li>Pueden distinguirse las siguientes fases: </li></ul><ul><li>Especificación conceptual </li></ul><ul><li>Análisis de requerimientos </li></ul><ul><li>Diseño inicial </li></ul><ul><li>Diseño detallado, codificación, depuración y liberación </li></ul><ul><li>Estas diferentes fases se van repitiendo en cada etapa del diseño. </li></ul>
  28. 29. <ul><li>Desarrollo iterativo y creciente (o incremental) </li></ul><ul><li>Es una repetición de varios ciclos de vida en cascada y al final de cada ciclo presenta una versión parcial del software. </li></ul><ul><li>Este modelo fue creado en respuesta a las debilidades del modelo tradicional de cascada. </li></ul>
  29. 30. <ul><li>Desarrollo rápido de aplicaciones (RAD) </li></ul><ul><li>El desarrollo rápido de aplicaciones o RAD ( acrónimo en inglés de ( rapid application development ) es un proceso de desarrollo de software El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering) . Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. </li></ul>
  30. 31. <ul><li>Ventajas y desventajas </li></ul><ul><li>El desarrollo rápido tiene dos ventajas primarias: </li></ul><ul><li>Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE. </li></ul><ul><li>Calidad: según lo definido por el desarrollo rápido de aplicaciones, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño. </li></ul>
  31. 32. <ul><li>El desarrollo rápido de aplicaciones tiene dos desventajas primarias: </li></ul><ul><li>Características reducidas. </li></ul><ul><li>Escalabilidad reducida: debido a que el desarrollo rápido de aplicaciones se desarrolló como prototipo </li></ul>
  32. 33. <ul><li>Modelo de desarrollo concurrente. </li></ul><ul><li>El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera. </li></ul>
  33. 34. <ul><li>El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización. </li></ul>
  34. 35. <ul><li>En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad . </li></ul>
  35. 36. <ul><li>Proceso Unificado de Rational (RUP) </li></ul><ul><li>El Proceso Unificado de Racional ( Rational Unified Process en inglés, habitualmente resumido como RUP ) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. </li></ul>
  36. 37. <ul><li>El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. </li></ul>
  37. 38. <ul><li>El RUP está basado en 6 principios clave que son: </li></ul><ul><li>Adaptar el proceso </li></ul><ul><li>El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal. </li></ul><ul><li>Equilibrar prioridades </li></ul><ul><li>Los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos . Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro. </li></ul>
  38. 39. <ul><li>Demostrar valor iterativamente </li></ul><ul><li>Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas . En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados </li></ul><ul><li>Colaboración entre equipos </li></ul><ul><li>El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc. </li></ul>
  39. 40. <ul><li>Elevar el nivel de abstracción </li></ul><ul><li>Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML. </li></ul>
  40. 41. <ul><li>Enfocarse en la calidad </li></ul><ul><li>El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. </li></ul>
  41. 42. <ul><li>Proceso Unificado. </li></ul><ul><li>El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. </li></ul>
  42. 43. <ul><li>El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational , también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. </li></ul>

×