Pracicas de Ingenieria de Software
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Pracicas de Ingenieria de Software

on

  • 10,457 views

 

Statistics

Views

Total Views
10,457
Views on SlideShare
10,428
Embed Views
29

Actions

Likes
2
Downloads
278
Comments
0

2 Embeds 29

http://www.slideshare.net 28
http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Pracicas de Ingenieria de Software Presentation Transcript

  • 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
    • Sólo 17 de las 32 empresas que existen en Ecuador se sometieron al estudio de las siguientes estadísticas
    Fuente: Tesis de Ingeniería de Gestión Universidad Santa Maria-Campus Guayaquil
  • 3. INTRODUCCIÓN
    • La práctica es una colección de conceptos, principios, métodos y herramientas a las que un ingeniero de software recurre a diario
    • La práctica transforma un enfoque fortuito en algo más organizado, más efectivo y con más probabilidades de alcanzar el éxito.
      • ¿Quién lo hace?
      • ¿Por qué es importante?
      • Cuáles son los pasos?
      • ¿Cómo puedo estar seguro de que lo he hecho correctamente?
  • 4. PRÁCTICA DE LA INGENIERÍA DE SOFTWARE
    • Los pasos considerados para solucionar un problema:
      • Entender el problema (comunicación y análisis)
      • Planear una solución (modelado y diseño de software)
      • Llevar a cabo el plan (generación de código)
      • Examinar el resultado para probar la precisión (realización de pruebas y aseguramiento de la calidad)
  • 5. PRINCIPIOS ESENCIALES
      • La razón por la que todo existe: ofrecer un valor a sus usuarios
      • MS (mantenerlo simple): todo el diseño debe ser tan simple como sea posible, simple no significa rápido y malo.
      • Mantener la visión: una visión clara es esencial para el éxito de un proyecto de desarrollo.
      • Lo que uno produzca, otros lo consumirán: el hecho de facilitar el trabajo a otro agrega valor al sistema.
      • Estar abierto al futuro: un sistema con una larga vida tiene más valor.
      • Planear para la reutilización: ahorra tiempo y esfuerzo.
      • Pensar: pensamiento claro y completo antes de la acción
  • 6. PRÁCTICA DE COMUNICACIÓN
    • Todos los requisitos deben recopilarse por medio de la comunicación:
    • Escuchar
    • Prepararse antes de comunicar
    • Alguien debe facilitar la actividad
    • La comunicación cara a cara es lo mejor
    • Tomar nota y documentar las decisiones
    • Buscar la colaboración
    • Conservar el enfoque, examinar un módulo a la vez
    • Si algo no está claro, se hace un dibujo
    • Una vez que se llega a un acuerdo de debe continuar
    • La negociación no es un concurso o un juego
  • 7. PRÁCTICAS DE LA PLANEACIÓN
    • La actividad de planeación permite definir el camino mientras se tiene presente una meta estratégica y unos objetivos.
    • Entender los alcances del proyecto
    • Involucrar al cliente en la actividad de planeación
    • Reconocer que la actividad es iterativa
    • Estimar con base en el conocimiento disponible
    • Considerar el riesgo cuando se define el plan
    • Ser realista
    • Ajustar la granularidad mientras se define el plan
    • Definir como se intentará asegurar la calidad
    • Definir como se pretende incluir el cambio
    • Adaptar el plan a menudo y hacer ajustes cuando estos se requieran
  • 8. PRINCIPIO W5HH
    • Why, what, when, who, where, how, how
    • 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.
      • ¿Por qué está en desarrollo este sistema?
      • ¿Qué se hará?
      • ¿Cuándo se terminará?
      • ¿Quién es el responsable de una función?
      • ¿En donde se ubica dentro de la organización?
      • ¿Cómo se realizará el trabajo en los sentidos técnico y de gestión?
      • ¿Cuánto se necesita de cada recurso?
  • 9.
    • Los modelos se crean para obtener un mejor entendimiento de la realidad. Existen dos modelos en la Ingeniería de Software:
    • Modelo de Análisis
    • Modelo de Diseño
    PRÁCTICAS DE MODELADO
  • 10. MODELO DE ANÁLISIS
    • Representar los requisitos del cliente en tres dominios: dominio de la información, dominio funcional y dominio del comportamiento
    • Representación conceptual correspondiente al problema y modelo de requisitos (conjunto de clases) cada clase aporta para lograr la arquitectura deseada
    • No se considera el ambiente de implementación
  • 11. MODELO DE DISEÑO
    • Como el plano para la construcción de una casa
    • Refinamiento y formalización adicional del modelo de análisis tomando en cuenta los detalles de implementación
    • 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
    • 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
  • 12. PRINCIPIOS DEL MODELADO DEL ANÁLISIS
    • El dominio de información de un problema debe representarse y entenderse.
    • Definir las funciones que ejecuta el software.
    • Se debe representar el comportamiento del software.
    • 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”.
    • La tarea del análisis debe moverse de la información esencial hacia el detalle de la implementación
  • 13. PRINCIPIOS DE MODELADO DE DISEÑO
    • Como el plano de una casa, proporciona diferentes vistas del sistema
    • El diseño debe ser rastreable hasta el modelo de análisis.
    • Siempre se debe considerar la arquitectura del sistema que se va a construir.
    • El diseño de datos es tan importante como el diseño de funciones de procesamiento.
    • Las interfaces deben diseñarse con cuidado.
    • El diseño de interfaz de usuario debe ajustarse a las necesidades del usuario final.
  • 14.
    • Los componentes deben estar apareados entre sí en forma mínima y vinculados con el ambiente externo
    • Las representaciones del diseño deben ser fácilmente comprensibles
    • El diseño debe desarrollarse de manera iterativa. En cada iteración el diseñador debe buscar la mayor simplicidad
    • Cuando se tienen presente los principios antes mencionados se logra que los clientes puedan observar velocidad, confiabilidad, y facilidad de uso
  • 15. PRÁCTICA DE LA CONSTRUCCIÓN
    • 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
    • Las pruebas con frecuencia se las realiza a nivel de componentes, llamadas pruebas de unidad
    • También existen pruebas de validación (lo que requiere el cliente), integración, aceptación (facilidad de manejo de software)
  • 16. PRINCIPIOS Y CONCEPTOS DE CODIFICACIÓN
    • Principios de preparación.- antes de codificación, entender el problema, elegir el lenguaje de programación, crear un conjunto de pruebas de unidad
    • 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
    • Principios de validación.- realizar pruebas de unidad, corregir errores descubiertos, refabricación de l código
  • 17. PRINCIPIOS DE PRUEBAS
    • Una prueba exitosa es aquella que logra encontrar errores con un gasto mínimo de tiempo y esfuerzo
    • Todas las pruebas deben ser rastreables hasta los requisitos del cliente
    • Las pruebas deben planearse mucho antes de que empiece el proceso de pruebas
    • El principio de Pareto es aplicable para las pruebas de software
    • Las pruebas deben comenzar “en lo pequeño” y progresar hacia “lo grande”.- primero enfocadas a componentes, luego a nivel de componentes integrados
    • Las pruebas exhaustivas no son posibles .- imposible ejecutar cada combinación de rutas para las pruebas
  • 18. PRÁCTICAS DE DESPLIEGUE
    • Entrega, soporte y retroalimentación, como el software es evolutivo se tienen varios despliegues
    • Se deben administrar las expectativas que el cliente tiene del software.- no dar a pensar más de lo que se puede entregar
    • Se debe ensamblar y probar un paquete de entrega completo
    • Se debe establecer un régimen de soporte antes de entregar el software
  • 19.
    • Se debe proporcionar un material instructivo apropiado a los usuarios finales.- diferencia entre cada incremento
    • El software con errores se debe arreglar primero y entregar después.- no entregar incrementos de baja calidad
    • 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
  • 20. CONCLUSIONES
    • 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
    • Para cada actividad del marco de trabajo de desarrollo de software existen principios de práctica
    • Existen prácticas de comunicación, planeación, modelado, construcción y despliegue
  • 21. BIBLIOGRAFÍA
    • PRESSMAN ROGER S: Ingeniería del Software (Un enfoque práctico): Sexta Edición.
    • WEITZENFELD ALFREDO: Ingeniería de Software Orientado a objetos con UML , Java e internet
    • ftp://ftp.itam.mx/pub/alfredo/OBJETOS/OMT/Modobi.pdf
    • http://www.usm.edu.ec/tesis/gestion-de-calidad/pdf/cap_2.pdf