Qué significa que un software es "Eficiente"?
Que es seguro
Que trabaja correctamente siempre, sin fallos
Que hace su trabajo con los recursos disponibles
Que hace Io que se requiere según las especificaciones
Definición de modelo:
Es un prototipo funcional que aun no ha sido validado ni documentado
Es un prototipo no funcional de un sistema
ciclo de vida de construcción o desarrollo de un sistema real
Es una representación abstracta y comprensible, de un sistema real que sirve para entender dicho sistema
Sobre "los modelos", se puede afirmar que:
Un buen modelo debe mostrar toda la complejidad del sistema real completo para que este se pueda construir correctamente
Un modelo muestra una simplificación de un sistema complejo mostrando únicamente algunos aspectos de este
Demasiada abstracción es mala ya que si no se diseñan los detalles la construcción final será de mala calidad
Cuando son correctos la implernentación final será correcta
¿Cuál de estas cuestiones es importante desde el punto de vista del mantenimiento del software?
¿Se puede manejar fácilmente?
¿Se puede actualizar?
¿Es íntegro (seguro)?
¿Sigue un diseño modular?
Un ciclo de vida del software es:
La planificación en cascada de cada tarea que es preciso realizar para desarrollar aplicaciones software
La planificación en espiral de cada tarea que es preciso realizar para desarrollar aplicaciones software
La planificación incremental de cada tarea que es preciso realizar para desarrollar aplicaciones software
El conjunto de tareas que es necesario hacer junto con la planificación de cuando hay que hacerlas para desarrollar aplicaciones software
¿El modelado de un sistema puede requerir de la realización de varios modelos?
No, muchos modelos complican la comprensión del sistema
Sí, habrá un modelo por cada miembro del equipo de desarrollo
Sí, cada modelo puede mostrar diferentes visiones y aspectos del problema
No, un solo modelo que contenga todos los detalles facilitará la construcción
Ventaja/as de los ciclos de vida iterativos con respecto a los clásicos:
Fuerzan a que el cliente proporcione todas las especificaciones desde el principio y así el desarrollo es más rápido
No requieren de grandes equipos de trabajo, con una o dos personas es posible desarrollar cualquier proyecto software
Ofrece versiones parciales del producto que pueden ser evaluadas de forma temprana
No existen tales ventajas, los ciclos de vida itenativos, debido a dichas interacciones son más lentos
La especificación de requisitos:
Consiste en identificar las necesidades del negocio y la interacción con los usuarios
Es la implementación de los primeros prototipos del sistema aptos para su validación
Es el conjunto de documentos que especifica cómo realizar el mantenimiento del sistema
Es el conjunto de diagramas que determinan como debe realizarse la implementación de cada módulo del sistema final
¿Cuál de los siguientes hechos requiere una tarea de mantenimiento?
Incluir en el sistema opciones que permitan hacer pruebas
Incluir en el sistema funcionalidades que sabemos que van a ser necesarias en el futuro
Incluir un sistema ayuda On-line para sus usuarios finales
lncluir en el sistema toda la documentación del mismo
¿Por qué ocurrió la denominada "Crisis del Software" en los años 60 y 70?
Por no existencia en la época de lenguajes de alto nivel con los que poder mejorar la abstracción de los módulos implementados para los programas desarrollados en aquellos años
El precio del hardware bajó haciendo que muchas empresas de informática cerraran al ver reducidos sus beneficios por el escaso margen de los productos que comercializaban
Los nuevos equipos informáticos eran más barato y potentes, lo que permitió desarrollar programas de mayor tamaño, pero no existía una buena metodología para realizar ese tipo de desarrollos
El hardware experimentó una fuerte bajada en sus precios y esto motivó que muchas personas "no profesionales" empezaran a desarrollar software, siendo este de muy mala calidad
En la ingeniería de requisitos, la gestión de requisitos se realizará
Al final, cuando durante el mantenimiento, además de corregir errores, pudiera necesitarse hacer modificaciones mayores por nuevos requerimientos de la empresa
Al principio, cuando se capturan los requerimientos
Simultáneamente con la etapa de implementación, para adaptar mejor la programación del producto con los cambios de requisitos que puedan surgir en ese momento
Desde el mismo comienzo del proyecto hasta su finalización, incluyendo la etapa de mantenimiento
¿Por qué es difícil capturar los requisitos de un sistema?:
No siempre será fácil para el analista y asimilar el lenguaje y los conceptos del cliente y vicerversa
Porque esta tarea no suele estar contemplada en los ciclos de vida que se aplican en los procesos de desarrollo
No existen herramientas CASE que faciliten esta tarea
Por la dificultad para plasmarlos en gráficos y diagramas
Todo requisito debe cumplir que...
Debe ser enteramente compatible con Ios objetivos del sistema y ha de tener el visto bueno de Ios desarrolladores
Debe ser enteramente compatible con los objetivos del sistema y estar correctamente plasmado en diagramas de diseño
Debe ser enteramente compatible con los objetivos del sistema y ha de poderse validar una vez desarrollado el producto
Debe ser enteramente compatible con los objetivos del sistema y con las herramientas de desarrollo que se vayan a emplear
¿Cuál de las siguientes características NO es deseable en "Revisión Técnica Formal" de validación de requisitos?:
Debe realizarse por un grupo reducido de personas, que sea ágil y operativo
Debe prepararse y planificarse previamente en no demasiado tiempo
Debe durar todo el tiempo que sea necesario, hasta limar todos los detalles tratados aportando soluciones a los problemas detectados
Debe tratar un objetivo muy concreto y delimitado
Un cambio en los requisitos de un software se aceptará...
Siempre a posteriori, después de haber terminado el desarrollo propuesto originalmente, durante la etapa de mantenimiento, y con la condición de que el cliente de el visto bueno al sobrecoste económico que suponga realizar el cambio
Siempre a posteriori, después de haber terminado el desarrollo propuesto originalmente, durante Ia etapa de mantenimiento
Si es compatible con el resto de funcionalidades del sistema, si no hay inconvenientes económicos o técnicos para su realización y si no implica reprogramar algún módulo importante de Ia aplicación
Si se comprueba que no es incompatible con el resto de funcionalidades del sistema y si tampoco hay inconvenientes económicos o técnicos para su realización
¿Qué significa que los requerimientos del sistema están negociados?:
Que el cliente los conoce y está en proceso de negociación con sus empleados (usuarios finales)
Que no son ambiguos
Que analista y cliente los han tratado y los consideran aptos
Que han sido capturados por el analista y este los ha discutido y validado con su equipo de desarrollo
Requerimientos no funcionales :
Especifican cosas como las características técnicas de las herramientas CASE de diseño o de desarrollo
Especifican cosas como cuántos operarios deberá haber en cada departamento, qué formación técnica deben tener, etc..
Especifican cosas como la accesibilidad del sistema, su seguridad, cómo deben ser los tiempos de respuesta, etc..
Especifican cosas como qué operaciones hace el sistema, cómo es el tratamiento de los datos, etc..
¿Qué se obtiene al identificar los requisitos de un sistema?:
La funcionalidad esperada del sistema
La planificación óptima del resto de tareas del ciclo de vida
Los actores que intervienen en el sistema y sus manuales de usuario
La funcionalidad que necesitarán tener las herramientas de desarrollo
En el proceso de Revisión Técnica Formal ...
El producto revisado se acepta si no hay errores, se acepta provisionalmente si hay errores y, en este caso, se plantean soluciones para resolverlo
El producto revisado se acepta si no hay errores o directamente se rechaza si se detectan errores, en cuyo caso hay que rehacer todo el trabajo de nuevo
El producto revisado se acepta si no hay errores, o entre el responsable del mismo y los revisores, se arreglan los problemas encontrados durante la propia reunión
El producto revisado se acepta si no hay errores, se acepta provisionalmente si hay errores o se rechaza si hay errores graves
¿Qué es la "abstracción"?:
Considerar conjuntamente tanto el "qué" son las cosas y el "cómo" están hechas para poder reproducirlas
Considerar los detalles de las cosas para entenderlas mejor
Considerar la posición que ocupan las cosas dentro de un sistema superior con el que interactuan
Considerar la esencia de las cosas, su concepto general sin entrar a considerar sus detalles
Diferencia entre análisis y diseño:
El análisis describe formalmente las necesidades del cliente y el diseño define el ciclo de vida y plantea como desarrollar la aplicación que satisfaga dichas necesidades
El análisis describe formalmente las necesidades del cliente junto con el ciclo de vida y el diseño plantea como desarrollar la aplicación que satisfaga dichas necesidades
El análisis describe formalmente las necesidades del cliente y define los algoritmos más complejos, y el diseño define el ciclo de vida y plantea como desarrollar la aplicación que satisfaga dichas necesidades
El análisis describe formalmente las necesidades del cliente y el diseño plantea como desarrollar la aplicación que satisfaga dichas necesidades
En una caja negra...
Debe estar muy bien definida su operativa interna
Debe estar muy bien definida su interfaz, es decir, sus entradas, salidas y detalles de funcionamiento
Debe estar muy bien definida su interfaz, es decir, sus entradas y salidas
Debe estar muy bien definido su diseño modular
"Encapsular" en Ingeniería del Software es...
Ocultar la interfaz de un módulo mostrando solo sus detalles
Ocultar el diseño y la interfaz de un módulo mostrando sólo sus detalles
Ocultar los detalles de un módulo mostrando su interfaz y su diseño
Ocultar los detalles de un módulo mostrando sólo su interfaz
Sobre el diseño modular...
Es recomendable que cada módulo tenga su propia interfaz oculta al resto de módulos
Es recomendable que cada módulo interactúe con d resto cuanto más mejor para facilitar la comunicación entre módulos
Es recomendable que cada módulo resuelva cuantos más problemas, mejor
Es recomendable que cada módulo este asociado a un problema concreto
Si consideramos un ordenador como un sistema, su capa de abstracción sería ...
El procesador y la memoria RAM
El teclado, el monitor y el ratón
El procesado, la memoria RAM, los buses y los sistemas de almacenamiento
El teclado, el monitor, el ratón y el procesador
¿Por qué es importante encapsular el software?
Para evitar que un usuario realice operaciones que puedan colgar el programa
Para evitar que un usuario manipule indebidamente la interfaz de un módulo o una clase
Para evitar que un usuario manipule indebidamente configuraciones internas de un módulo produciendo errores de funcionamiento
Para evitar que un usuario inexperto realice pruebas en el software
¿Por qué es importante hacer un buen diseño al desarrollar software?:
Porque si no se capturan correctamente los requerimientos del cliente, todo el proceso de desarrollo será más lento y costoso y el producto final no cumplirá bien las necesidades de este
Porque de lo contrario la implementación posterior será más compleja y probablemente tendrá más errores
Porque no es recomendable acometer el desarrollo de un producto software sin antes haber definido el ciclo de vida más adecuado
Porque la definición posterior de los módulos de la aplicación será de mejor calidad que sin un diseño previo adecuado
El proceso de refinamiento modular...
Genera una jerarquía de módulos de no más de 4 niveles
Genera una jerarquía de módulos de varios niveles, dependiendo del tipo de problema
Genera una jerarquía de módulos en la que el nivel más bajo contiene los módulos con mayor nivel de abstracción
Genera una jerarquía de módulos donde cada uno se subdivide en no másde 4 en el siguiente nivel
¿Cuándo finaliza el proceso de refinamientos sucesivos?:
Cuando los requerimientos del cliente lo determinen
Cuando el coste de desarrollar los módulos sea mínimo
Cuando los módulos sean tan pequeños que su implementación sea abordable, pero no tantos como para complicar en exceso la conexión de todos ellos
Cuando las pruebas de cada módulo detecten los primeros erróneos o incompatibles
¿Qué especifican los requisitos funcionales?
Especifican cosas como qué operaciones hace el sistema, cómo es tratamiento de los datos, etc...
Especifican cosas como el funcionamiento de las herramientas CASE de diseño o de desarrollo