1. Especificación del software
1.1. Es
1.1.1. Una descripción completa del comportamiento del sistema que se va a desarrollar.
1.1.1.1. Tipos de requisitos:
1.1.1.1.1. ¿Cuáles son los beneficios de tener una especificación de requisitos?
1.1.1.2. Requisitos de Usuarios
1.1.1.3. Requisitos del Sistema
1.1.1.4. Requisitos Funcionales
1.1.1.5. Requisitos No Funcionales
2. Notación
2.1. Es
2.1.1. Una de las ramas de las ciencias de la computación que estudia la creación de software confiable y de calidad, basándose en métodos y técnicas de ingeniería, y brindando soporte operacional y de mantenimiento.
2.1.1.1. Objetivos:
2.1.1.1.1. Promover mayor calidad al desarrollar aplicaciones complejas.
2.1.1.1.2. Brindar mayor exactitud en los costos de proyectos y tiempo de desarrollo de los mismos.
2.1.1.1.3. Una mejor organización de equipos de trabajo, en el área de desarrollo y mantenimiento de software.
2.1.1.1.4. Detectar a través de pruebas, posibles mejoras para un mejor funcionamiento del software desarrollado.
2.1.2. Ventajas:
2.1.2.1. Desde el punto de vista de gestión
2.1.2.1.1. Facilitar la tarea de seguimiento del proyecto.
2.1.2.1.2. Optimizar el uso de recursos.
2.1.2.1.3. Facilitar la comunicación entre usuarios y desarrolladores.
2.1.2.2. Desde el punto de vista de los ingenieros de software
2.1.2.2.1. Ayudar a comprender el problema.
2.1.2.2.2. Permitir la reutilización.
2.1.2.2.3. Facilitar el mantenimiento del producto final.
2.1.2.3. Desde el punto de vista de cliente o usuario final
2.1.2.3.1. Garantizar el nivel de calidad del producto final.
2.1.2.3.2. Obtener el ciclo de vida adecuado para el proyecto.
2.1.2.3.3. Confianza en los plazos del tiempo mostrados en la definición del proyecto.
3. Análisis
3.1. Es
3.1.1. El proceso automatizado de analizar el sistema para el comportamiento del software.
3.1.1.1. Algunas de las técnicas usadas para llevar a cabo estos análisis son:
3.1.1.1.1. Análisis de control del flujo y análisis de flujo de datos
3.1.1.1.2. Análisis de restricción
3.1.1.1.3. Interpretación abstracta
3.1.1.1.4. Verificación de tipos y efectos
3.1.1.1.5. Rebanamiento estático
3.1.1.1.6. Model checking.
3.1.2. ¿Para qué sirve un análisis de requisitos?
3.1.2.1. Ayuda a que los proveedores proporcionen un presupuesto más acertado. Muchas veces, no queda del todo claro cuáles son los requisitos, y el proveedor puede no incluir dentro del presupuesto un elemento que la empresa sí que pensaba que se iba a incluir.
3.1.2.1.1. ejemplo:
4. Modelaje
4.1. Es
4.1.1. Una técnica para tratar con la complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir.
4.1.1.1. Clasificación de los modelos de proceso
4.1.1.1.1. Modelos tradicionales.
4.1.1.1.2. Modelos evolutivos.
4.1.1.1.3. Modelos para sistemas orientados a objetos.
4.1.1.1.4. Modelos basados en reutilización.
4.1.1.1.5. Procesos ágiles.
4.1.1.1.6. Modelos para sistemas web.
4.1.2. Ventajas:
4.1.2.1. 1. Genera una buena comunicación con los clientes. 2. Recomendado para proyectos de pequeño y mediano alcance.
4.1.3. Desventajas:
4.1.3.1. 1. Las planificaciones pudieran sufrir cambios. 2. Dificultades para mantener el sistema en proyectos grandes y en la respuesta a cambios en los requisitos del usuario. 3. Períodos de desarrollo largos.
5. Especificación formal
5.1. Es
5.1.1. Un área de investigación activa en la ingeniería de software de este siglo, en la que se aplica en diversas configuraciones y técnicas, y aunque su uso industrial todavía es limitado, la comunidad científica tiene actualmente una comprensión diferente acerca de su utilidad y necesidad.
5.1.1.1. Ventajas de la formalizacion:
5.1.1.1.1. Generar contraejemplos de las afirmaciones de una especificación declarativa.
5.1.1.1.2. Producir animaciones de la especificación para comprobar si es adecuada.
5.1.1.1.3. Generar casos de prueba y oráculos desde la especificación.
5.1.2. La Especificación Formal en contexto
5.1.2.1. Cada año se incrementa el número de casos de éxito al utilizar especificaciones formales en sistemas reales, lo que se refleja en trabajos de reingeniería y de desarrollo de sistemas.
5.1.3. EL FUTURO DE LA ESPECIFICACIÓN FORMAL
5.1.3.1. Las técnicas y herramientas para la Especificación Formal que se desarrollan actualmente y que se propondrán en el futuro, deberán incorporar los siguientes requisitos y retos para que la especificación formal logre sus objetivos y para que los productos de la ingeniería de software logren el nivel de calidad que se espera de ellos.
6. Definición
6.1. F. Bauer Conferencia de la OTAN, 1969.
6.1.1. El establecimiento y uso de principios de ingeniería robustos, orientados a obtener económicamente software que sea fiable y funcione eficientemente sobre máquinas reales.
6.2. B. Boehm 1976.
6.2.1. La Ingeniería del Software incluye la aplicación practica del conocimiento científico en el diseño y construcción de los programas y la documentación requerida para su desarrollo, operación y mantenimiento.
6.3. Glosario IEEE 1983.
6.3.1. El enfoque sistemático para el desarrollo, operación, mantenimiento y eliminación del software, definiendo como software los programas, procedimientos, reglas y documentación.
6.4. Software Engineering Institute (SEI) 1990.
6.4.1. Esa forma de ingeniería que aplica los principios de la informática y las matemáticas para conseguir soluciones rentables a problemas software.
6.5. Ian Sommerville Software Engineering, 5ª edición 1996.
6.5.1. La especificación, desarrollo, gestión y evolución de sistemas software. No está limitado por materiales sujetos a leyes físicas o procesos de fabricación manual.
7. Especificación de requerimientos
7.1. Es
7.1.1. Un documento que describe las necesidades específicas de un proyecto o sistema. La especificación de requisitos es importante porque sirve como base para todo el trabajo futuro en el proyecto.
7.1.1.1. Que debe de tener a especificacion de requerimientos:
7.1.1.1.1. Una introducción.
7.1.1.1.2. Los requisitos funcionales.