Ingeniería de Software

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Ingeniería de Software por Mind Map: Ingeniería de Software

1. Primera Fase

1.1. Programar no es una tarea diferenciada del diseño de una máquina

1.2. Uso de lenguaje máquina y ensamblador

2. 2000-Presente

2.1. Utiliza algunos requisitos de las eras anteriores

2.2. Aumenta la omnipresencia de la web

2.3. Aumenta la omnipresencia de la web

2.4. Componentes de software

3. 1972-1985

3.1. Nuevo concepto; Sistemas distribuidos

3.2. Aparecen: Redes de área local y global.

4. 1985-1995

4.1. Redes de información

4.2. Tecnologías orientadas a objetos

4.3. Redes neuronales

4.4. Sistemas expertos

4.5. SW de inteligencia artificial

5. 1965-1972

5.1. Se busca simplificar código

5.2. Aparición de multiprogramación

5.3. Sistemas de tiempo real apoyan la toma de decisiones

5.4. Aparición de software como producto

5.5. Inicio de la crisis del software

6. 1946-1967

6.1. No existía un planteamiento previo

6.2. No existía documentación de ningún tipo

6.3. Pocos métodos

6.4. Desarrollo a base de prueba y error

7. PROCESOS

7.1. Comunicación

7.1.1. Comunicación y colaboración con el cliente y los participantes del proyecto, para entender los objetivos y requerimientos que ayuden a definir los características y funciones del software.

7.2. Planeación

7.2.1. Creación de un plan del proyecto de software- que define el trabajo de ingeniería de software al describir 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.

7.3. Modelado

7.3.1. Crear modelos a fin de entender mejor los requerimientos del software y el diseño que los satisfará a fin de entender el panorama general.

7.4. construcción

7.4.1. Esta actividad combina la generación de código y las pruebas que se requieren para descubrir errores en éste.

7.5. Despliegue

7.5.1. El software (como entidad completa o como un incremento parcialmente terminado) se entrega al consumidor que lo evalúa y que le da retroalimentación, misma que se basa en dicha evaluación.

8. PRÁCTICAS

8.1. Entender el problema

8.1.1. comunicación y análisis

8.1.1.1. ¿Quiénes tienen que ver con la solución del problema? ¿Cuáles son las incógnitas? ¿Puede fraccionarse el problema? ¿Es posible representargr4ficamente el problema?

8.2. Planear la solución

8.2.1. modelado y diseño del software

8.2.1.1. ¿Ha visto antes problemas similares? ¿Ha resuelto un problema similar? ¿Pueden definirse problemas más pequeños? ¿Es capaz de representar una solución en una forma que lleve a su implementación eficaz?

8.3. Ejecutar el plan

8.3.1. generación del código

8.3.1.1. ¿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?

8.4. Examinar el resultado

8.4.1. generación del código

8.4.1.1. ¿Puede probarse cada parte componente de la solución? ¿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?

9. PRINCIPIOS

9.1. Primer principio

9.1.1. La razón de que exista todo

9.1.1.1. Tener siempre en cuenta que un sistema de software existe por una razón: dar valor a sus usuarios. Todas las decisiones deben tomarse teniendo esto en mente.

9.2. Segundo principio

9.2.1. MSE (Mantenlo sencillo, estúpido ... )

9.2.1.1. Todo diseño debe ser tan simple como sea posible, un sistema que sea comprendido más fácilmente y que sea susceptible de recibir mantenimiento. Los diseños más elegantes por lo general son los más simples. Con frecuencia se requiere mucha reflexión y trabajo con iteraciones múltiples para poder simplificar.

9.3. Tercer principio

9.3.1. Mantener la visión

9.3.1.1. Una visión clara es esencial. Sin integridad conceptual, un sistema está amenazado de convertirse en algo equivocado y hará que colapsen incluso los sistemas bien diseñados. Tener un arquitecto que pueda para mantener la visión y que obligue a su cumplimiento garantiza un proyecto de software muy exitoso.

9.4. Cuarto principio

9.4.1. Otros consumirán lo que usted produce

9.4.1.1. Establezca especificaciones, diseñe e implemente con la seguridad de que alguien más tendrá que entender lo que usted haga. Elabore especificaciones con la mirada puesta en los usuarios. Diseñe con los implementadores en mente. Codifique pensando en aquellos que deben dar mantenimiento y ampliar el sistema.

9.5. Quinto principio

9.5.1. Ábrase al futuro

9.5.1.1. Los sistemas deben ser fáciles de adaptar a cambios. Los sistemas que lo logran son los que se diseñaron para ello desde el principio. Nunca diseñe sobre algo iniciado. Prepárese para todas las posibilidades del sistema, no sólo uno específico. esto lleve a volver a usar un sistema completo.

9.6. Sexto principio

9.6.1. Planee por anticipado la reutilización

9.6.1.1. La reutilización ahorra tiempo y esfuerzo. Al desarrollar un sistema de software, La reutilización del código y de los diseños se ha reconocido como uno de los mayores beneficios de usar tecnologías orientadas a objetos.

9.7. Séptimo principio

9.7.1. ¡Piense!

9.7.1.1. Pensar en todo con claridad antes de emprender la acción casi siempre produce mejores resultados. Cuando se piensa en algo es más probable que se haga bien. Asimismo, también se gana conocimiento al pensar cómo volver a hacerlo bien. Cuando en un sistema se han puesto pensamientos claros el valor se manifiesta. La aplicación de los primeros seis principios requiere pensar con intensidad, por lo que las recompensas potenciales son enormes.

10. PRIMERA ERA

11. SEGUNDA ERA

12. TERCERA ERA

13. CUARTA ERA

14. QUINTA ERA

15. Es el estudio de los principios y metodologías con un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software; que es la suma total de los programas de ordenador, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema y particularmente a un sistema computacional

16. Segunda Fase

16.1. Era posible hacer casi todo

16.2. Aparecen multitud de lenguajes

17. Tercera Fase

17.1. Desarrollo inacabable de grandes programas

17.2. Ineficiencia, errores, coste impredecible

17.3. Nada es posible

18. Cuarta Fase

18.1. Metodologías de diseño

18.2. Verificación de programas

18.3. Fundamentos de programación

19. Quinta Fase.

19.1. Entornos de programación

19.2. Especificación formal

19.3. Programación automática