HERRAMIENTAS
Las herramientas suministran un soporte automático para los métodos.„ Existen herramientas para soportar cada uno de los métodos mencionados anteriormente
„Un entorno con integración de diferentes herramientas. Se denomina un sistema CASE
(Ingenieria del Software Asistida por Ordenador).
Son útiles que facilitan la realización de las tareas de producción. Distinguiremos dos
tipos de herramientas:
– de representación o modelización: son notaciones, gráficas o de escritura, que facilitan la representación del software o de la realidad.
– automáticas de ayuda: son programas que ayudan en la realización de las tareas.
Las Herramientas de Ayuda al Desarrollo de sistemas de informacion, surgieron para intentar dar solución a los problemas inherentes a los proyectos de generación de aplicaciones informáticas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos, entre otros. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE.
Actualmente existe un gran desarrollo y una gran cantidad de este tipo de herramientas, por lo que se hace difícil la elección de una de ellas para el trabajo, tanto personal como corporativo.
En el presente trabajo se describen las funcionalidades y características más relevantes de las principales herramientas CASE existentes en la actualidad, entre ellas: Microsoft Project, Rational Rose, JDeveloper, Magic Draw, Visual Paradigm, Microsoft Visio, BoUML.
Este trabajo puede servir de apoyo a la hora de seleccionar e implantar una herramienta CASE.
Herramientas CASE
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del ciclo de vida de desarrollo de un Software.
Otras definiciones:
Las Herramientas CASE son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información completamente o en alguna de sus fases.
La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.
Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:
- Análisis de datos y procesos integrados mediante un repositorio.
- Generación de interfaces entre el análisis y diseño.
- Generación del código a partir del diseño.
- Control de mantenimiento
Tipos de Herramientas CASE
No existe una única clasificación de herramientas CASE, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:
- Las plataformas que soportan.
- Las fases del ciclo de vida del desarrollo de sistemas que abarca.
- La arquitectura de las aplicaciones que produce.
- Su funcionalidad.
Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:
Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
Las herramientas I-CASE se basan en una metodología Tienen un repositorio y aportan técnicas estructuradas para todas las fases del ciclo de vida. Estas son las características que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de prototipo.
Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
Una estrategia posible es utilizar una U-CASE para análisis y diseño, combinada con otras herramientas más modernas para las fases de construcción y pruebas. En este caso, habría que vigilar cuidadosamente la integración entre las distintas herramientas.
PROCESO
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado
plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, productos del trabajo y puntos de garantía de calidad- permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión de la configuración del software y medición- cubren el modelo de proceso.
Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.
Proceso del software
Conjunto estructurado de actividades y resultados asociados requeridos para desarrollar un sistema de software
• Especificación: establecer los requisitos y restricciones del sistema
• Diseño: Producir un modelo en papel del sistema
• Implementación: construcción del sistema de software
• Validación: verificar (por ejemplo mediante pruebas) que el sistema cumple con las especificaciones requeridas
• Instalación: entregar el sistema al usuario y asegurar su operacionalidad
• Evolución y mantenimiento: cambiar/adaptar el software según las demandas; reparar fallos en el sistema cuando sean descubiertos.Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollar
Debe estar explícitamente modelado si va a ser bien administrado
El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para los clientes que han solicitado el producto y la gente que realizará el trabajo; las características del producto en sí, y el entorno del proyecto en el que trabaja el equipo de software.
Maduración del producto y del proceso: La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:
· Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente- tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.
Descomposición del proceso: Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.
Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.
PARADIGMA
Esquemas (métodos, herramientas, procedimientos) que aplicados correctamente conducen a la construcción de un producto de software con una perspectiva ingenieril.
Paradigma por default: ensayo y error.
Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, que permite producir programas con unas directrices específicas, tales como: estructura modular, fuerte cohesión, alta rentabilidad, etc.
Para algunos puede resultar sorprendente que existan varios paradigmas de programación. La mayor parte de los programadores están familiarizados con un único paradigma, el de la programación procedimental. Sin embargo hay multitud de ellos atendiendo a alguna particularidad metodológica o funcional, como por ejemplo el basado en reglas de gran aplicación en la ingeniería del conocimiento para el desarrollo de sistemas expertos, en que el núcleo del mismo son las reglas de producción del tipo "if then"; el de programación lógica, basado en asertos y reglas lógicas que define un entorno de programación de tipo conversacional, deductivo, simbólico y no determinista; el de programación funcional, basado en funciones, forma funcionales para crear funciones y mecanismos para aplicar los argumentos, y que define un entorno de programación interpretativo, funcional y aplicativo, el de programación heurística que aplica para la resolución de los problemas "reglas de buena lógica" que presentan visos de ser correctas aunque no se garantiza su éxito, modelizando el problema de una forma adecuada para aplicar estas heurísticas atendiendo a su representación, estrategias de búsqueda y métodos de resolución; el de programación paralela; el basado en restricciones; el basado en el flujo de datos; el orientado al objeto, etc.
Un paradigma de programación es una colección de modelos conceptuales que juntos modelan el proceso de diseño y determinan, al final, la estructura de un programa.
Esa estructura conceptual de modelos está pensada de forma que esos modelos determinan la forma correcta de los programas y controlan el modo en que pensamos y formulamos soluciones, y al llegar a la solución, ésta se debe de expresar mediante un lenguaje de programación. Para que este proceso sea efectivo las características del lenguaje deben reflejar adecuadamente los modelos conceptuales de ese paradigma.
Cuando un lenguaje refleja bien un paradigma particular, se dice que soporta el paradigma, y en la práctica un lenguaje que soporta correctamente un paradigma, es difícil distinguirlo del propio paradigma, por lo que se identifica con él.
Tipos de paradigmas
tres categorías de paradigmas de programación:
a) Los que soportan técnicas de programación de bajo nivel (ej.: copia de ficheros frente estructuras de datos compartidos)
b) Los que soportan métodos de diseño de algoritmos (ej.: divide y vencerás, programación dinámica, etc.)
c) Los que soportan soluciones de programación de alto nivel, como los descritos en el punto anterior lo diferentes que resultan los lenguajes de programación que soportan cada una de estas categorías de paradigmas.
Se agrupan en tres categorías de acuerdo con la solución que aportan para resolver el problemaa) Solución procedimental u operacional. Describe etapa a etapa el modo de construir la solución. Es decir señala la forma de obtener la solución.
b) Solución demostrativa. Es una variante de la procedimental. Especifica la solución describiendo ejemplos y permitiendo que el sistema generalice la solución de estos ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir resultados muy diferentes a ésta, hace que sea tratada como una categoría separada.
c) Solución declarativa. Señala las características que debe tener la solución, sin describir cómo procesarla. Es decir señala qué se desea obtener pero no cómo obtenerlo.
Paradigmas procedimentales u operacionales
La característica fundamental de estos paradigmas es la secuencia computacional realizada etapa a etapa para resolver el problema. Su mayor dificultad reside en determinar si el valor computado es una solución correcta del problema, por lo que se han desarrollado multitud de técnicas de depuración y verificación para probar la corrección de los problemas desarrollados basándose en este tipo de paradigmas.
Pueden ser de dos tipos básicos: Los que actúan modificando repetidamente la representación de sus datos (efecto de lado); y los que actúan creando nuevos datos continuamente (sin efecto de lado).
Los paradigmas con efecto de lado utilizan un modelo en el que las variables están estrechamente relacionadas con direcciones de la memoria del ordenador. Cuando se ejecuta el programa, el contenido de estas direcciones se actualiza repetidamente, pues las variables reciben múltiples asignaciones, y al finalizar el trabajo, los valores finales de las variables representan el resultado.
Los paradigmas procedimentales definen la secuencia explícitamente, pero esta secuencia se puede procesar en serie o en paralelo. En este segundo caso el procesamiento paralelo puede ser asíncrono (cooperación de procesos paralelos) o síncrono (procesos simples aplicados simultáneamente a muchos objetos).
Paradigmas declarativos
En este tipo, un programa se construye señalando hechos, reglas, restricciones, ecuaciones, transformaciones y otras propiedades derivadas del conjunto de valores que configuran la solución.
A partir de esta información el sistema debe de proporcionar un esquema que incluya el orden de evaluación que compute una solución. Aquí no existe la descripción de las diferentes etapas a seguir para alcanzar una solución, como en el caso anterior.
Estos paradigmas permiten el uso de variables para almacenar valores intermedios, pero no para actualizar estados de información.
Dado que estos paradigmas especifican la solución sin indicar cómo construirla, en principio eliminan la necesidad de probar que el valor calculado es el valor solución. En la práctica, mientras que muchos de los paradigmas secuencia de control y efecto de lado que requiera la noción de estado, las soluciones son todavía producidas como construcciones más bien que cómo especificaciones. Por lo que los paradigmas resultantes y los lenguajes que los soportan no son verdaderamente declarativos, sino pseudodeclarativos. En este grupo se encuentran: el funcional, el lógico y el de transformación.
En principio, los paradigmas declarativos no son soluciones inherentes de tipos serie o paralelo, ya que no dirigen la secuencia de control y no pueden alterar el natural no paralelismo del algoritmo. No obstante, los paradigmas pseudodeclarativos requieren al menos un limitado grado de secuencia, y por lo tanto admiten versiones en serie y paralelo.
Paradigmas demostrativos
Cuando se programa bajo un paradigma demostrativo (también llamada programación por ejemplos), el programador no especifica procedimentalmente cómo construir una solución. En su lugar, presentan soluciones de problemas similares y permite al sistema que generalice una solución procedimental a partir de estas demostraciones. Los esquemas individuales para generalizar tales soluciones van desde simular una secuencia procedimental o inferir intenciones.
Los sistemas que infieren, intentan generalizar usando razonamiento basado en el conocimiento. Una solución basada en la inferencia intenta determinar en qué son similares un grupo de datos u objetos, y, a partir de ello, generalizar estas similaridades.
Otra solución es la programación asistida: el sistema observa acciones que el programador ejecuta, y si son similares o acciones pasadas, intentará inferir cuál es la próxima acción que hará el programador. Las dos principales objeciones al sistema de inferencia son:
Si no se comprueban exhaustivamente pueden producir programas erróneos que trabajan correctamente con los ejemplos de prueba, pero que fallen posteriormente en otros casos
La capacidad de inferencia es tan limitada, que el usuario debe de guiar el proceso en la mayoría de los casos.Los resultados más satisfactorios de los sistemas de inferencia son en áreas limitadas, donde el sistema tenía un conocimiento semántico importante de la aplicación.
El mayor problema que se presenta con estos sistemas, es conocer cuándo un programa es correcto. En el caso de los sistemas procedimentales, se consigue estudiando el algoritmo y el resultado de juegos de ensayo apropiados.
En el caso de los sistemas demostrativos el algoritmo se mantiene en una representación interna, y su estudio se sale del ámbito de estos sistemas. Por lo que la veracidad de la decisión se debe hacer exclusivamente sobre la base de la eficiencia del algoritmo sobre los casos específicos de prueba.
La programación demostrativa es del tipo "bottom-up" y se adapta bien a nuestra capacidad de pensar. Sin embargo en la mayor parte de los paradigmas la resolución del problema se efectúa aplicando métodos abstractos "top-down".
"ESPECTRO DE LA GESTION"
El espectro de la gestión
La gestión eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.
Personal
El <<factor humano>> es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) <<para aumentar la preparación de organizaciones del software.
El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo.
Producto
El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).
Proceso
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.
Proyecto
Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.
GESTION
Gestión hace referencia a la acción y a la consecuencia de administrar o gestionar algo. Al respecto, hay que decir que gestionar es llevar a cabo diligencias que hacen posible la realización de una operación comercial o de un anhelo cualquiera.
La gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar y controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto de alta calidad.
La gestión de un proyecto de software se centra en tres partes como son:
Personal
Problema
Proceso
BIBLIOGRAFIA
Maduración del producto y del proceso: La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:
· Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente- tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.
Descomposición del proceso: Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.
Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.
PARADIGMA
Esquemas (métodos, herramientas, procedimientos) que aplicados correctamente conducen a la construcción de un producto de software con una perspectiva ingenieril.
Paradigma por default: ensayo y error.
Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, que permite producir programas con unas directrices específicas, tales como: estructura modular, fuerte cohesión, alta rentabilidad, etc.
Para algunos puede resultar sorprendente que existan varios paradigmas de programación. La mayor parte de los programadores están familiarizados con un único paradigma, el de la programación procedimental. Sin embargo hay multitud de ellos atendiendo a alguna particularidad metodológica o funcional, como por ejemplo el basado en reglas de gran aplicación en la ingeniería del conocimiento para el desarrollo de sistemas expertos, en que el núcleo del mismo son las reglas de producción del tipo "if then"; el de programación lógica, basado en asertos y reglas lógicas que define un entorno de programación de tipo conversacional, deductivo, simbólico y no determinista; el de programación funcional, basado en funciones, forma funcionales para crear funciones y mecanismos para aplicar los argumentos, y que define un entorno de programación interpretativo, funcional y aplicativo, el de programación heurística que aplica para la resolución de los problemas "reglas de buena lógica" que presentan visos de ser correctas aunque no se garantiza su éxito, modelizando el problema de una forma adecuada para aplicar estas heurísticas atendiendo a su representación, estrategias de búsqueda y métodos de resolución; el de programación paralela; el basado en restricciones; el basado en el flujo de datos; el orientado al objeto, etc.
Un paradigma de programación es una colección de modelos conceptuales que juntos modelan el proceso de diseño y determinan, al final, la estructura de un programa.
Esa estructura conceptual de modelos está pensada de forma que esos modelos determinan la forma correcta de los programas y controlan el modo en que pensamos y formulamos soluciones, y al llegar a la solución, ésta se debe de expresar mediante un lenguaje de programación. Para que este proceso sea efectivo las características del lenguaje deben reflejar adecuadamente los modelos conceptuales de ese paradigma.
Cuando un lenguaje refleja bien un paradigma particular, se dice que soporta el paradigma, y en la práctica un lenguaje que soporta correctamente un paradigma, es difícil distinguirlo del propio paradigma, por lo que se identifica con él.
Tipos de paradigmas
tres categorías de paradigmas de programación:
a) Los que soportan técnicas de programación de bajo nivel (ej.: copia de ficheros frente estructuras de datos compartidos)
b) Los que soportan métodos de diseño de algoritmos (ej.: divide y vencerás, programación dinámica, etc.)
c) Los que soportan soluciones de programación de alto nivel, como los descritos en el punto anterior lo diferentes que resultan los lenguajes de programación que soportan cada una de estas categorías de paradigmas.
Se agrupan en tres categorías de acuerdo con la solución que aportan para resolver el problemaa) Solución procedimental u operacional. Describe etapa a etapa el modo de construir la solución. Es decir señala la forma de obtener la solución.
b) Solución demostrativa. Es una variante de la procedimental. Especifica la solución describiendo ejemplos y permitiendo que el sistema generalice la solución de estos ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir resultados muy diferentes a ésta, hace que sea tratada como una categoría separada.
c) Solución declarativa. Señala las características que debe tener la solución, sin describir cómo procesarla. Es decir señala qué se desea obtener pero no cómo obtenerlo.
Paradigmas procedimentales u operacionales
La característica fundamental de estos paradigmas es la secuencia computacional realizada etapa a etapa para resolver el problema. Su mayor dificultad reside en determinar si el valor computado es una solución correcta del problema, por lo que se han desarrollado multitud de técnicas de depuración y verificación para probar la corrección de los problemas desarrollados basándose en este tipo de paradigmas.
Pueden ser de dos tipos básicos: Los que actúan modificando repetidamente la representación de sus datos (efecto de lado); y los que actúan creando nuevos datos continuamente (sin efecto de lado).
Los paradigmas con efecto de lado utilizan un modelo en el que las variables están estrechamente relacionadas con direcciones de la memoria del ordenador. Cuando se ejecuta el programa, el contenido de estas direcciones se actualiza repetidamente, pues las variables reciben múltiples asignaciones, y al finalizar el trabajo, los valores finales de las variables representan el resultado.
Los paradigmas procedimentales definen la secuencia explícitamente, pero esta secuencia se puede procesar en serie o en paralelo. En este segundo caso el procesamiento paralelo puede ser asíncrono (cooperación de procesos paralelos) o síncrono (procesos simples aplicados simultáneamente a muchos objetos).
Paradigmas declarativos
En este tipo, un programa se construye señalando hechos, reglas, restricciones, ecuaciones, transformaciones y otras propiedades derivadas del conjunto de valores que configuran la solución.
A partir de esta información el sistema debe de proporcionar un esquema que incluya el orden de evaluación que compute una solución. Aquí no existe la descripción de las diferentes etapas a seguir para alcanzar una solución, como en el caso anterior.
Estos paradigmas permiten el uso de variables para almacenar valores intermedios, pero no para actualizar estados de información.
Dado que estos paradigmas especifican la solución sin indicar cómo construirla, en principio eliminan la necesidad de probar que el valor calculado es el valor solución. En la práctica, mientras que muchos de los paradigmas secuencia de control y efecto de lado que requiera la noción de estado, las soluciones son todavía producidas como construcciones más bien que cómo especificaciones. Por lo que los paradigmas resultantes y los lenguajes que los soportan no son verdaderamente declarativos, sino pseudodeclarativos. En este grupo se encuentran: el funcional, el lógico y el de transformación.
En principio, los paradigmas declarativos no son soluciones inherentes de tipos serie o paralelo, ya que no dirigen la secuencia de control y no pueden alterar el natural no paralelismo del algoritmo. No obstante, los paradigmas pseudodeclarativos requieren al menos un limitado grado de secuencia, y por lo tanto admiten versiones en serie y paralelo.
Paradigmas demostrativos
Cuando se programa bajo un paradigma demostrativo (también llamada programación por ejemplos), el programador no especifica procedimentalmente cómo construir una solución. En su lugar, presentan soluciones de problemas similares y permite al sistema que generalice una solución procedimental a partir de estas demostraciones. Los esquemas individuales para generalizar tales soluciones van desde simular una secuencia procedimental o inferir intenciones.
Los sistemas que infieren, intentan generalizar usando razonamiento basado en el conocimiento. Una solución basada en la inferencia intenta determinar en qué son similares un grupo de datos u objetos, y, a partir de ello, generalizar estas similaridades.
Otra solución es la programación asistida: el sistema observa acciones que el programador ejecuta, y si son similares o acciones pasadas, intentará inferir cuál es la próxima acción que hará el programador. Las dos principales objeciones al sistema de inferencia son:
Si no se comprueban exhaustivamente pueden producir programas erróneos que trabajan correctamente con los ejemplos de prueba, pero que fallen posteriormente en otros casos
La capacidad de inferencia es tan limitada, que el usuario debe de guiar el proceso en la mayoría de los casos.Los resultados más satisfactorios de los sistemas de inferencia son en áreas limitadas, donde el sistema tenía un conocimiento semántico importante de la aplicación.
El mayor problema que se presenta con estos sistemas, es conocer cuándo un programa es correcto. En el caso de los sistemas procedimentales, se consigue estudiando el algoritmo y el resultado de juegos de ensayo apropiados.
En el caso de los sistemas demostrativos el algoritmo se mantiene en una representación interna, y su estudio se sale del ámbito de estos sistemas. Por lo que la veracidad de la decisión se debe hacer exclusivamente sobre la base de la eficiencia del algoritmo sobre los casos específicos de prueba.
La programación demostrativa es del tipo "bottom-up" y se adapta bien a nuestra capacidad de pensar. Sin embargo en la mayor parte de los paradigmas la resolución del problema se efectúa aplicando métodos abstractos "top-down".
"ESPECTRO DE LA GESTION"
El espectro de la gestión
La gestión eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.
Personal
El <<factor humano>> es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) <<para aumentar la preparación de organizaciones del software.
El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo.
Producto
El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).
Proceso
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.
Proyecto
Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.
GESTION
Gestión hace referencia a la acción y a la consecuencia de administrar o gestionar algo. Al respecto, hay que decir que gestionar es llevar a cabo diligencias que hacen posible la realización de una operación comercial o de un anhelo cualquiera.
La gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar y controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto de alta calidad.
La gestión de un proyecto de software se centra en tres partes como son:
Personal
Problema
Proceso
BIBLIOGRAFIA
S. Pressman, Roger: "Ingeniería del Software, un enfoque práctico";
tercera edición.
No hay comentarios:
Publicar un comentario