Please enable JavaScript.

Coggle requires JavaScript to display documents.

SOFTWARE, [1] Roger S. Pressman, Ingeniería del Software un enfoque…

- - - - Son aplicables a través de todo el proceso del software.
  - - - Crea un “bosquejo” del objeto por hacer, a fin de entender el panorama general, cómo se verá arquitectónicamente, cómo ajustan entre sí las partes constituyentes y muchas características más.
    - - Generación de código
    - - Describe las tareas técnicas por realizar, los riesgos probables, los recursos que se requieren, los productos del trabajo que se obtendrán y una programación de las actividades.
    - - Entrega al consumidor que lo evalúa.
    - - busca entender los objetivos de los participantes respecto del proyecto, y reunir los requerimientos que ayuden a definir las características y funciones del software.
  - - - Evalúa los productos del trabajo.
    - - Ayudar al equipo a entregar el software que satisfaga las necesidades de los participantes
    - - administra los efectos del cambio a
        lo largo del proceso del software.
    - - evalúa los riesgos que puedan afectar el resultado
    - - Define y ejecuta las actividades requeridas para garantizar la calidad del software.
    - - evalúe el progreso comparándolo con el plan del proyecto
    - - Agrupa las actividades requeridas
        para crear productos del trabajo
    - - define criterios para volver a usar el producto del
        trabajo
- - - - Entender el problema (comunicación y análisis).
        
        Planear la solución (modelado y diseño del software).
        
        Ejecutar el plan (generación del código).
        
        Examinar la exactitud del resultado (probar y asegurar la calidad).
    - - • ¿Quiénes tienen que ver con la solución del problema? Es decir, ¿quiénes son los participantes?
      - • ¿Cuáles son las incógnitas? ¿Cuáles datos, funciones y características se requieren para resolver el problema en forma apropiada?
      - • ¿Puede fraccionarse el problema? ¿Es posible representarlo con problemas más pequeños que sean más fáciles de entender?
      - • ¿Es posible representar gráficamente el problema? ¿Puede crearse un modelo de análisis?
    - - • ¿Ha visto antes problemas similares? ¿Hay patrones reconocibles en una solución potencial? ¿Hay algún software existente que implemente los datos, funciones y características que se requieren?
      - • ¿Ha resuelto un problema similar? Si es así, ¿son reutilizables los elementos de la solución?
      - • ¿Pueden definirse problemas más pequeños? Si así fuera, ¿hay soluciones evidentes para éstos?
    - - • ¿Se ajusta la solución al plan? ¿El código fuente puede apegarse al modelo del diseño?
      - • ¿Es probable que cada parte componente de la solución sea correcta? ¿El diseño y código se han revisado o, mejor aún, se han hecho pruebas respecto de la corrección del algoritmo?
    - - • ¿Puede probarse cada parte componente de la solución? ¿Se ha implementado una estrategia razonable para hacer pruebas?
      - • ¿La solución produce resultados que se apegan a los datos, funciones y características que se requieren? ¿El software se ha validado contra todos los requerimientos de los participantes?
  - - - Todas las decisiones
        deben tomarse teniendo esto en mente.
        
        ¿Esto agrega valor real al sistema? Si la respuesta es no, entonces no lo haga. Todos los demás principios apoyan a este.
    - - Todo diseño debe ser tan simple como sea posible, pero no más.
    - - Una visión clara es esencial para el éxito de un proyecto de software.
    - - Siempre establezca especificaciones, diseñe y
        implemente con la seguridad de que alguien más tendrá que entender lo que usted haga.
    - - Un sistema con larga vida útil tiene más valor.
    - - La reutilización ahorra tiempo y esfuerzo.
    - - Pensar en todo con claridad antes de emprender la acción casi siempre produce mejores resultados.