Un proceso de software es: Una serie de actividades relacionadas que conduce a la elaboración de un producto de software Las actividades pueden incluir el desarrollo de software desde cero en un lenguaje de programación estándar como Java o C. Definición de requisitos.
El nuevo software empresarial con frecuencia Se desarrolla extendiendo y modificando los sistemas existentes Configurando e integrando el software comercial o componentes del sistema.
Existen muchos diferentes procesos de software, pero todos deben incluir cuatro actividades que son fundamentales para la ingeniería de software: Especificación del software Diseño e implementación del software Validación del software Evolución del software Definición del negocio.
Una con una línea según corresponda el concepto: Especificación del software Diseño e implementación del software Validación del software Evolución del software .
Las actividades del proceso de Software son complejas en sí mismas e incluyen subactividades tales como la validación de requerimientos, el diseño arquitectónico, la prueba de unidad, etcétera. También existen actividades de soporte al proceso, como la documentación y el manejo de la configuración del software Verdadero Falso.
Las descripciones de los procesos deben incluir: Productos Roles Precondiciones y postcondiciones Nivel de Seguridad Evolución del Software.
Las descripciones de los procesos deben incluir: Productos Roles Precondiciones y postcondiciones.
No existe un proceso ideal, sin embargo para: sistemas críticos sistemas empresariales.
Los procesos de software se clasifican como: Procesos dirigidos Procesos àgiles Procesos rígidos Procesos no rígidos.
Los procesos dirigidos, son: Son aquellos donde todas las actividades del proceso se planean por anticipado y el avance se mide contra dicho plan. La planeación es incremental y es más fácil modificar el proceso para reflejar los requerimientos cambiantes del cliente. .
Los procesos ágiles, son: Son aquellos donde todas las actividades del proceso se planean por anticipado y el avance se mide contra dicho plan. La planeación es incremental y es más fácil modificar el proceso para reflejar los requerimientos cambiantes del cliente. .
Los procesos de software pueden mejorarse con la estandarización de los procesos, donde se reduce la diversidad en los procesos de software en una organización. Esto conduce a mejorar la comunicación, a reducir el tiempo de capacitación, y a que el soporte de los procesos automatizados sea más económico Verdadero Falso.
Algunos modelos de proceso muy generales en ocasiones se les llama “paradigmas de proceso” Verdadero Falso.
Los modelos del proceso son: El modelo en cascada (waterfall) Desarrollo incremental Ingeniería de software orientada a la reutilización Ingeniería de software orientada a objetos.
El modelo en cascada (waterfall) Éste enfoque toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los representa como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Este enfoque vincula las actividades de especificación, desarrollo y validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión añade funcionalidad a la versión anterior Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en la integración de estos componentes en un sistema, en vez de desarrollarlo desde cero.
El modelo de Desarrollo incremental Éste enfoque toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los representa como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Este enfoque vincula las actividades de especificación, desarrollo y validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión añade funcionalidad a la versión anterior Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en la integración de estos componentes en un sistema, en vez de desarrollarlo desde cero.
El modelo de Ingeniería de Software orientada a la reutilización Éste enfoque toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los representa como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Este enfoque vincula las actividades de especificación, desarrollo y validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión añade funcionalidad a la versión anterior Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en la integración de estos componentes en un sistema, en vez de desarrollarlo desde cero.
Los modelos no son mutuamente excluyentes y con frecuencia se usan en conjunto, sobre todo para el desarrollo de grandes sistemas Verdadero Falso.
El modelo en cascada se conoce también como ciclo de vida del Software Verdadero Falso.
El modelo en cascada es un ejemplo de un proceso dirigido por un plan; en principio, usted debe planear y programar todas las actividades del proceso, antes de comenzar a trabajar con ellas Verdadero Falso.
Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo: Análisis y definición de requerimientos Diseño del sistema y del software Implementación y prueba de unidad Integración y prueba de sistema Operación y mantenimiento .
Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:
Análisis y definición de requerimientos, se refiera a: Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema Asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. Implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones. Se real iza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente. Por lo general, es fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.
Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:
Diseño del sistema y del software, se refiera a: Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema Asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. Implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones. Se real iza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente. Por lo general, es fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.
Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:
Implementación y prueba de unidad , se refiera a: Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema Asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. Implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones. Se real iza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente. Por lo general, es fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.
Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:
Integración y prueba de sistema , se refiera a: Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema Asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. Implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones. Se real iza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente. Por lo general, es fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.
Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:
Operación y mantenimiento, se refiera a: Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema Asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. Implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones. Se real iza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente. Por lo general, es fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.
En principio, el resultado de cada fase consiste en uno o más documentos que se autorizaron (“firmaron”). La siguiente fase no debe comenzar sino hasta que termine la fase previa Verdadero Falso.
El proceso de software no es un simple modelo lineal, sino que implica retroalimentación de una fase a otra. Entonces, es posible que los documentos generados en cada fase deban modificarse para reflejar los cambios que se realizan. Verdadero Falso.
Durante la fase final del ciclo de vida (operación y mantenimiento), el software se pone en servicio. Se descubren: Los errores y las omisiones en los requerimientos originales del software. Surgen los errores de programa y diseño Se detecta la necesidad de nueva funcionalidad.
El sistema debe evolucionar para mantenerse útil. Hacer tales cambios (mantenimiento de software) puede implicar la repetición de etapas anteriores del proceso. Verdadero Falso.
El modelo en cascada es consecuente con otros modelos del proceso de ingeniería y en cada fase se produce documentación. Esto hace que el proceso sea visible, de modo que los administradores monitoricen el progreso contra el plan de desarrollo. Su principal problema es la partición inflexible del proyecto en distintas etapas. Tienen que establecerse compromisos en una etapa temprana del proceso, lo que dificulta responder a los requerimientos cambiantes del cliente. Verdadero Falso.
Una variación importante del modelo en cascada es el desarrollo de sistemas formales, donde se crea un modelo matemático para una especificación del sistema. Después se corrige este modelo, mediante transformaciones matemáticas que preservan su consistencia en un código ejecutable. Verdadero Falso.
Los procesos basados en transformaciones formales se usan por lo general sólo en el desarrollo de sistemas críticos para protección o seguridad. Requieren experiencia especializada. Para la mayoría de los sistemas, este proceso no ofrece costo/beneficio significativos sobre otros enfoques en el desarrollo de sistemas Verdadero Falso.
El desarrollo incremental se basa en la idea de diseñar una implementación inicial, exponer ésta al comentario del usuario, y luego desarrollarla en sus diversas versiones hasta producir un sistema adecuado Verdadero Falso.
En el modelo de desarrollo incremental, que actividades están entrelazadas en vez de separadas? Especificación Desarrollo Validación Implementación.
El desarrollo de software incremental, que es una parte fundamental de los enfoques ágiles, es mejor que un enfoque en cascada para la mayoría de los sistemas empresariales, de comercio electrónico y personales. Verdadero Falso.
El desarrollo incremental refleja la forma en que se resuelven problemas. Verdadero Falso.
En el desarrollo de software incremental rara vez se trabaja por adelantado una solución completa del problema, más bien se avanza en una serie de pasos hacia una solución y se retrocede cuando se detecta que se cometieron errores. Al desarrollar el software de manera incremental, resulta más barato y fácil realizar cambios Verdadero Falso.
Cada incremento o versión del sistema incorpora algunas de las funciones que necesita el cliente. Por lo general, los primeros incrementos del sistema incluyen la función más importante o la más urgente. Esto significa que el cliente puede evaluar el desarrollo del sistema en una etapa relativamente temprana, para constatar si se entrega lo que se requiere. Verdadero Falso.
El desarrollo incremental tiene tres beneficios: Se reduce el costo de adaptar los requerimientos cambiantes del cliente. La cantidad de análisis y la documentación que tiene que reelaborarse son menores Es más sencillo obtener retroalimentación del cliente sobre el trabajo de desarrollo que se realizó. Los clientes pueden comentar las demostraciones del software y darse cuenta de cuánto se ha implementado. Los clientes encuentran difícil juzgar el avance a partir de documentos de diseño de software. Es posible que sea más rápida la entrega e implementación de software útil al cliente, aun si no se ha incluido toda la funcionalidad. Los clientes tienen posibilidad de usar y ganar valor del software más temprano de lo que sería posible con un proceso en cascada. El proceso no es visible. Los administradores necesitan entregas regulares para medir el avance. La estructura del sistema tiende a degradarse conforme se tienen nuevos incrementos. .
El enfoque incremental tiene dos problemas: El proceso no es visible. Los administradores necesitan entregas regulares para medir el avance La estructura del sistema tiende a degradarse conforme se tienen nuevos incrementos. La incorporación de más cambios de software se vuelve cada vez más difícil y costosa. El desarrollo incremental ahora es en cierta forma el enfoque más común para el desarrollo de sistemas de aplicación. Este enfoque puede estar basado en un plan, ser ágil.
Los problemas del desarrollo incremental se tornan particularmente agudos para sistemas grandes, complejos y de larga duración, donde diversos equipos desarrollan diferentes partes del sistema. Los grandes sistemas necesitan de un marco o una arquitectura estable y es necesario definir con claridad, las responsabilidades de los distintos equipos que trabajan en partes del sistema. Verdadero Falso.
Los enfoques orientados a la reutilización se apoyan en una gran base de componentes de software reutilizable y en la integración de marcos para la composición de dichos componentes. En ocasiones, tales componentes son sistemas por derecho propio (sistemas comerciales, off-the-shelf o COTS) que pueden mejorar la funcionalidad específica Verdadero Falso.
Cuáles son las etapas del proceso basado en la reutilización? Especificación de requerimientos Análisis de componentes Modificación de requerimientos Diseño de sistema con reutilización Desarrollo e integración Validación del Sistema Implementación de los requerimientos.
La etapa de: Análisis de componentes, se refiere a: Dada la especificación de requerimientos, se realiza una búsqueda de componentes para implementar dicha especificación. Por lo general, no hay coincidencia exacta y los componentes que se usan proporcionan sólo parte de la funcionalidad requerida. Se analizan los requerimientos usando información de los componentes descubiertos. Luego se modifican para reflejar los componentes disponibles. Donde las modificaciones son imposibles, puede regresarse a la actividad de análisis de componentes para buscar soluciones alternativas. Se diseña el marco conceptual del sistema o se reutiliza un marco conceptual existente. Los creadores toman en cuenta los componentes que se reutilizan y organizan el marco de referencia para atenderlo. Es posible que deba diseñarse algo de software nuevo, si no están disponibles los componentes reutilizables. Se diseña el software que no puede procurarse de manera externa, y se integran los componentes y los sistemas COTS para crear el nuevo sistema. La integración del sistema, en este modelo, puede ser parte del proceso de desarrollo, en vez de una actividad independiente.
La etapa de: Modificación de requerimiento, se refiere a: Dada la especificación de requerimientos, se realiza una búsqueda de componentes para implementar dicha especificación. Por lo general, no hay coincidencia exacta y los componentes que se usan proporcionan sólo parte de la funcionalidad requerida. Se analizan los requerimientos usando información de los componentes descubiertos. Luego se modifican para reflejar los componentes disponibles. Donde las modificaciones son imposibles, puede regresarse a la actividad de análisis de componentes para buscar soluciones alternativas. Se diseña el marco conceptual del sistema o se reutiliza un marco conceptual existente. Los creadores toman en cuenta los componentes que se reutilizan y organizan el marco de referencia para atenderlo. Es posible que deba diseñarse algo de software nuevo, si no están disponibles los componentes reutilizables. Se diseña el software que no puede procurarse de manera externa, y se integran los componentes y los sistemas COTS para crear el nuevo sistema. La integración del sistema, en este modelo, puede ser parte del proceso de desarrollo, en vez de una actividad independiente.
La etapa de: Diseño de sistema con reutilización , se refiere a: Dada la especificación de requerimientos, se realiza una búsqueda de componentes para implementar dicha especificación. Por lo general, no hay coincidencia exacta y los componentes que se usan proporcionan sólo parte de la funcionalidad requerida. Se analizan los requerimientos usando información de los componentes descubiertos. Luego se modifican para reflejar los componentes disponibles. Donde las modificaciones son imposibles, puede regresarse a la actividad de análisis de componentes para buscar soluciones alternativas. Se diseña el marco conceptual del sistema o se reutiliza un marco conceptual existente. Los creadores toman en cuenta los componentes que se reutilizan y organizan el marco de referencia para atenderlo. Es posible que deba diseñarse algo de software nuevo, si no están disponibles los componentes reutilizables. Se diseña el software que no puede procurarse de manera externa, y se integran los componentes y los sistemas COTS para crear el nuevo sistema. La integración del sistema, en este modelo, puede ser parte del proceso de desarrollo, en vez de una actividad independiente.
La etapa de: Desarrollo e integración , se refiere a: Dada la especificación de requerimientos, se realiza una búsqueda de componentes para implementar dicha especificación. Por lo general, no hay coincidencia exacta y los componentes que se usan proporcionan sólo parte de la funcionalidad requerida. Se analizan los requerimientos usando información de los componentes descubiertos. Luego se modifican para reflejar los componentes disponibles. Donde las modificaciones son imposibles, puede regresarse a la actividad de análisis de componentes para buscar soluciones alternativas. Se diseña el marco conceptual del sistema o se reutiliza un marco conceptual existente. Los creadores toman en cuenta los componentes que se reutilizan y organizan el marco de referencia para atenderlo. Es posible que deba diseñarse algo de software nuevo, si no están disponibles los componentes reutilizables. Se diseña el software que no puede procurarse de manera externa, y se integran los componentes y los sistemas COTS para crear el nuevo sistema. La integración del sistema, en este modelo, puede ser parte del proceso de desarrollo, en vez de una actividad independiente.
Existen tres tipos de componentes de software que pueden usarse en un proceso orientado a la reutilización: Servicios Web que se desarrollan en concordancia para atender servicios estándares y que están disponibles para la invocación remota. Colecciones de objetos que se desarrollan como un paquete para su integración con un marco de componentes como .NET o J2EE. Sistemas de software independientes que se configuran para usar en un entorno particular.
La ingeniería de software orientada a la reutilización tiene la clara ventaja de: Reducir la cantidad de software a desarrollar Disminuir costos y riesgos Entregas más rápidas del software Sistemas estables y ágiles.
En la ingeniería de software orientada a la reutilización son inevitables los compromisos de requerimientos y esto conduciría hacia un sistema que no cubra las necesidades reales de los usuarios. Más aún, se pierde algo de control sobre la evolución del sistema, conforme las nuevas versiones de los componentes reutilizables no estén bajo el control de la organización que los usa. Verdadero Falso.
|
