1. programación orientada a objetos
1.1. componentes
1.1.1. Herencia: permite definir nuevas clases partiendo de otros ya existentes.
1.1.2. Abstracción: es un termino externo al objeto que controla la forma en que es visto por los demás.
1.1.3. Objetos: atributos y operaciones
1.1.4. Polifomirsmo: la posibilidad de una referencia a objetos de una clase, pueda concretarse con objetos de descendientes de esta.
1.1.5. clases: están conformados por variable de clase y ,métodos de clase.
2. PROCESO PARA EL DESARROLLO
2.1. Modelo de requisitos: es el primer paso a desarrollar, mediante el modelo de casos se desarrolla el de requerimientos, el cual se desarrolla en cooperación con otros modelos.
2.2. Análisis: la funcionalidad por el modelo de casos de uso, se estructura en modelos de analisís, que es estable con respecto a cambios, lo que lo hace un modelo logico independiente del ambiente implementado.
2.3. Diseño: la funcionalidad del caso de usos, ya estructurada por el análisis, el modelo de diseño, adaptándose al ambiente de implementación.
2.4. Pruebas: los casos de uso se comprueban a través de las pruebas de componente y de integración.
2.5. Documentación: el modelo de caso de uso, se debe registrar a lo largo de los diversas actividades, dando lugar a distintos documentos, como los manuales de usuario.
3. MODELOS DE SOFTWARE
3.1. Modelo de cascada: s una metodología secuencial para la gestión de proyectos que se divide en fases, las cuales son:
3.1.1. Fase de análisis: Planificación, análisis y especificación de los requisitos.
3.1.2. Fase de diseño: Diseño y especificación del sistema.
3.1.3. Fase de impciólementación: Programación y pruebas unitarias.
3.1.4. Fase de Verificación: Integración de sistemas, pruebas de sistema e integración.
3.1.5. Fase de implementación: Despliegue de Sistemas
3.1.6. Fase de mantenimiento: Entrega, mantenimiento y mejora.
4. Modelo espiral
4.1. Modelo de desarrollo de software en el que las actividades se crean en espiral y se llevan a cabo en el orden en que se eligen en función del análisis de riesgo.
4.1.1. Fase de planificación: El paso inicial es identificar y establecer objetivos y metas a alcanzar. Luego, como alternativas, presentan las mejores formas potenciales de satisfacer los objetivos.
4.1.2. Fase de análisis de riesgos: Al planificar y finalizar la estrategia de reducción de riesgos, se identifican los posibles peligros. Cada peligro destacado se somete a un examen exhaustivo. Se pueden crear prototipos para eliminar la posibilidad de requisitos ambiguos
4.1.3. Fase de ingeniería: Implica la codificación, prueba e implementación del software. Tras una evaluación de riesgos, se adopta el modelo de desarrollo. El modelo a utilizar está determinado por el nivel de riesgo que se ha reconocido para esa fase.
4.1.4. Fase de evaluación: Valoración del cliente sobre el programa. Se decide si repetir o no el ciclo. Aquí se está planificando la siguiente fase del proyecto.
5. Modelo V
5.1. También conocido como el modelo de cuatro niveles, es un concepto utilizado en una variedad de procesos de desarrollo, como el desarrollo de software.
5.1.1. Análisis de requisitos: El paso inicial de la fase de verificación es comprender las expectativas de los clientes sobre nuestros productos mediante una amplia comunicación con los clientes.
5.1.2. Diseño de sistemas: Después de la identificación de los requisitos de los clientes y las expectativas de nuestros productos, se debe desarrollar el sistema de diseño detallado para el desarrollo del producto.
5.1.3. Diseño arquitectónico: El diseño del sistema se segrega en diferentes módulos según sus funcionalidades. Se reconoce la transferencia de datos entre los módulos internos y otros sistemas.
6. Modelo incremental e iterativo
6.1. Es una técnica de desarrollo de software basada en un patrón cíclico de lanzamiento y actualización y un aumento constante en la adición de funciones.
6.1.1. Fase de Iniciación: La fase de iniciación de un proyecto se ocupa del alcance, las necesidades y los peligros a un nivel superior.
6.1.2. Fase de Elaboración: Crea una arquitectura viable que mitiga los riesgos identificados en la primera fase y cumple con los criterios no funcionales.
6.1.3. Fase de transición: Entregar el sistema al entorno operativo de producción durante la fase de transición.