viernes, 16 de noviembre de 2007
tareas de los diagramas y lo que me toco de la tarea en equipo
http://dl3u.savefile.com/55635093a048988e0402fe0c82555506/MaryCruz.rar
sábado, 13 de octubre de 2007
“ANALISTA”
El análisis se refiere a la habilidad de poder estudiar un problema de complejidad, descomponiendo el problema en subproblemas de menor complejidad.
El experto en el problema es el cliente por ello se hace necesario trabajar junto a él para realizar la especificación correctamente.
Los miembros del grupo que trabajan con el cliente son los analistas.
El análisis se divide en dos fases:
especificación de requisitos de usuario
especificación de requisitos de software
ACTIVIDADES Y METAS
El análisis se refiere a la habilidad de poder estudiar un problema de complejidad, descomponiendo el problema en subproblemas de menor complejidad.
El experto en el problema es el cliente por ello se hace necesario trabajar junto a él para realizar la especificación correctamente.
Los miembros del grupo que trabajan con el cliente son los analistas.
El análisis se divide en dos fases:
especificación de requisitos de usuario
especificación de requisitos de software
ACTIVIDADES Y METAS
Actividades
* Entrevistar al cliente, ayudándole a identificar sus Necesidades.
* Verificar si los requisitos especificados son los Correctos.
*Definir una estructura básica del sistema que incluya Fuentes de información, módulos de procesamiento De información, y resultados esperados.
* Realizar el análisis de los requisitos.
* Analizar la estructura básica del sistema.
Metas
* Determinar las necesidades esenciales y no Esenciales, así como las que son de segundo Nivel.
* Impedir la introducción de defectos Tempranamente en la construcción del sistema.
* Construir el documento de requisitos de usuario
* Establecer una estructura básica inicial del Sistema.
* Establecer interacciones, interrelaciones y sus Contextos en dicha estructura.
* Definir la especificación de la arquitectura del Sistema, en forma de un documento técnico Comprensible.
Los analistas deben ayudar al cliente a definir los objetivos del sistema, Determinando la información que desea obtener, la información que será suministrada al sistema, la funcionalidad del sistema y el rendimiento requerido. Los analistas deben determinar si cada uno de los requisitos especificados es o no esencial. Luego los analistas deben determinar información adicional requerida, tales como la evaluación de tecnología disponible para el desarrollo y las tecnologías disponibles para el cliente.
Metodologías de análisis
Durante el período de análisis, el analista se reunirá en forma sistemática con el cliente con el propósito de entender y especificar el problema a desarrollar. Dichas reuniones deben estar planificadas, con fecha de inicio y fecha de término.
. El analista podrá utilizar prototipos, encuestas, otros sistemas, etc., con el propósito de ayudar a estructurar y definir el problema del cliente. El proceso termina con el proceso de revisión de los requisitos de usuario RU/R, y luego, el hito de aceptación del documento de requisitos de usuario, DRU.
El analista debe además, transformar los requisitos de usuario en requisitos de
software, y producir el documento de requisitos de software, DRS. La intervención del cliente en esta etapa es menor, y su trabajo consistirá en resolver los conflictos detectados en los requisitos de usuario por el analista durante el proceso de transformación. El proceso de especificación de los requisitos de software produce el documento de requisitos de software, DRS. Luego, se realiza una revisión formal RS/R y termina con el hito de aprobación del DRS.
Relación con otros roles
• Administrador de proyecto: El analista debe interactuar con el administrador de proyecto para estudiar la viabilidad del sistema a desarrollar. Esto es, verificar la realización del sistema con los recursos disponibles. El administrador de proyecto le asignará a los analistas, la agenda con actividades a ser realizadas y sus fechas. Es claro que la asignación de actividades puede ir modificándose durante el proyecto.
• Diseñador: Los diseñadores deben interactuar con los analistas para determinar la factibilidad del proyecto, y establecer los objetivos del sistema para un buen diseño. Los analistas deben permanecer en contacto estrecho con los diseñadores debido a que utilizarán la arquitectura del sistema. Los diseñadores deben poder ayudarle a los analistas.
• Programador: Los analistas son apoyados por los programadores en el entendimiento y especificación de los requisitos de usuario y de software. Además, los apoyan en la construcción de prototipos rápidos.
• Téster: Los analistas participan junto con los tésters en la revisión de los documentos de análisis de requisitos.
• Asegurador de calidad: Debe revisar los documentos hechos por los analistas.
• Administrador de la configuración: Debe pedir los cambios pertinentes, evitando errores a futuro.
• Documentador: Los analistas deberán entregarles la información que servirá para la documentación del sistema.
Herramientas de apoyo
• Proyectores de diapositivas.
• Videograbadoras.
• Videocámaras, para grabar las reuniones para análisis posterior.
• Grabadoras de audio.
También debe considerarse herramientas para la creación de documentos, tales como procesador de texto, software para el diseño y dibujo de diagramas, e incluso, sistemas. CASE para realizar la estructura general del sistema.
Perfil de un analista
* Un analista debe ser una persona sociable, expresando sus ideas en forma clara en un lenguaje común con el cliente.
*Debe tener la capacidad de escuchar y entender al cliente
* Los analistas deben conocer y manejar perfectamente los métodos y las tecnologías de apoyo para realizar las fases de análisis.
* Deben estar familiarizados con las técnicas de diseño y diferentes lenguajes de programación
Plan de trabajo
• Preparar un documento con preguntas a realizar al cliente durante las
Entrevistas.
• Determinar las fechas de reunión con el cliente.
• Generar un documento de especificación de requisitos de usuario en base a los
acuerdos alcanzados en la primera reunión.
• Presentación del documento de especificación al cliente en la siguiente reunión.
• De ser necesario, realizar las modificaciones al documento de especificación de
requisitos de usuario y presentarlas al cliente en la próxima reunión. Repetir esta
actividad las veces que sea necesario.
• Estudiar la metodología de diseño.
• Explorar las herramientas CASE a utilizar.
• Generar los diagramas de arquitectura.
• Revisar los diagramas de arquitectura con los diseñadores.
• De ser necesario, realizar las modificaciones a los diagramas.
• Presentar los diagramas de arquitectura finales.
• Construir el documento de requisitos de software.
• Revisar el documento con los ingenieros de aseguramiento de la calidad y
Cliente, realizando modificaciones de ser necesario.
jueves, 11 de octubre de 2007
FUNCTIONAL ANALYST
El analista funcional se encarga de la arquitectura y los requisitos (análisis funcional). Alguien que baja de nivel los requerimientos para que después sean programados. Específicamente lo que realiza depende de cada empresa, en algunos casos lo unico que hacen es conversar con el cliente y escribir word, en otros llegan hasta diseñar tablas y UML. La constante es que no programan.
Analiza los procesos de "negocio", las reglas, casos escepcionales, documenta,
Se encarga del Relevamiento, entrevistas.
El analista funcional tiene conocimientos y experiencia en Metodologías de Desarrollo de Software.
Sólidos conocimientos de Sistemas de Información. Estos conocimientos proporcionan la base para la administración, organización y modelización de información y el proceso de comunicación asociado.
*PRINCIPALES RESPONSABILIDADES:
*Realizar tareas de Relevamiento, Análisis y diseño de los sistemas informáticos
*Adicionalmente, supervisión de la programación o realización la misma, documentación, actualización y mantenimiento de los sistemas informáticos.
*Efectuar el relevamiento de datos de los proyectos a desarrollar
*Diseñar las salidas, entradas, archivos y programas de cada sistema
*Supervisar las pruebas del programa
*Controlar el cumplimiento del cronograma de desarrollo del proyecto
ANALISIS FUNCIONAL:
Se considera el análisis funcional como el estudio de los espacios vectoriales normados completos sobre los reales o los complejos.
Es una técnica que se utiliza para identificar las competencias laborales inherentes a una función productiva.
El análisis funcional no es, en modo alguno, un método exacto. Es un enfoque de trabajo para acercarse a las competencias requeridas mediante una estrategia deductiva. Se inicia estableciendo el propósito principal de la función productiva o de servicios bajo análisis y se pregunta sucesivamente qué funciones hay que llevar a cabo para permitir que la función precedente se logre.
domingo, 7 de octubre de 2007
ELABORADO POR TODOS
MENOS
*JOSE LUIS GOMEZ PERALTA
*ROBERTO MENDOZA
MENOS
*JOSE LUIS GOMEZ PERALTA
*ROBERTO MENDOZA
SOFTWARE ANALYSIS: A ROADMAP
ABSTRACT
A lo largo del artículo se habla del ‘analisis’ como la información referente al comportamiento del software, representado como un modelo abstracto o código.
ANALISIS VS DESCRIPTION
Con respecto al análisis de los modelos de sistemas, nos dice que es recomendable aplicar el análisis, que desarrollar simplemente el sistema, ya que realizar un análisis, antes de introducir el código, nos sirve para detectar problemas que podrían causarnos dificultades y costarnos mucho más si no se descubren en ese momento.
Los investigadores que trabajan sobre modelos abstractos se pueden dividir en 2, unos son los desarrolladores de Z, quienes se centran en la forma de el modelo y consideran al análisis como algo secundario; por otro lado están los desarrolladores de la revisión del modelo simbólico, que se centran en el análisis y prestan menos atención a la manera en la que se expresa el modelo.
Por su parte los exponentes del análisis argumentan que la motivación principal para tomar decisiones sobre el diseño es explorando sus consecuencias por medio del análisis, diseñar un lenguaje sin un análisis en mente es como diseñar un lenguaje de programación que no puede ser compilado. Por otra parte los exponentes de la descripción o forma del modelo, dicen que en el desarrollo del software el obstáculo principal no es encontrar los fallos ocultos, si no más bien definir los pasos del desarrollo, con notas que expresen con precisión las intenciones del desarrollador y sólo eso.
GLOBAL VS LOCAL
Por lo regular nos encontraremos con que el método orientado a objetos se refiere a modelados de objetos que nos muestran qué objetos existen y cómo se encuentran relacionados y declaran diagramas de transición, que muestran los estados de los objetos y las transiciones entre ellos .
Existen 2 tipos de modelos que dominan la descripción abstracta del software.
El primer tipo de modelo nos dice que el modelado de objetos es estático y los diagramas de transición son dinámicos. El modelado de objetos, regularmente no es más que diagramas de clases, mostrando las clases, las subclases y las relaciones entre ellas. Un diagrama de clases es una representación parcial de la estructura sintáctica del código, y en ese sentido es estático en comparación a un diagrama de transición que describe estados de tiempo de ejecución.
El otro tipo de modelo dice que los modelados de objetos son ‘información intensiva’ y los diagramas de transición son ‘control intensivo.
Los 2 tipos de modelos anteriores también podrían ser vistos como ‘global’ y ‘local’.
El modelado de objetos, describe las relaciones de forma global entre los elementos del sistema, sus estados son las configuraciones globales de objetos y sus transiciones son los cambios globales que resultan de los objetos que vienen y van, así como de las relaciones que son cambiadas. Por otro lado el diagrama de transición describe los estados de un objeto individual y el protocolo de interacciones entre objetos.
En un modelo global, el estado del sistema, como un todo, es directamente expresado, en un modelo local, el estado global surge de las definiciones de los estados locales.
SIMULATION VS CHEKCING
El chequeo o comprobación de un modelo es mucho más efectivo que una simulación en la exposición de errores sutiles. Sin embargo la simulación es demasiado útil. Construyendo un modelo incrementalmente, es fácil cometer errores que la simulación expone fácilmente.
La mayor parte de los programadores, tienen más confianza en su código cuando han visto algunos ejemplos de ejecución, esto es un fenómeno muy común. La experiencia nos dice que un modelo que ha sido simulado tiene menos posibilidades se contener errores notorios.
Uno de los motivos por los que la simulación ha sido subvalorada es que la comprobación tiene mejores resultados. Los inventores de herramientas para la comprobación de modelos están obligados a exponer por lo menos un ejemplo de un error sutil que fue detectado en un sistema real.
La comprobación será crucial, no sólo asegurar que el modelo está correcto, si no también establecer una correspondencia entre el código y su modelo abstracto
VERIFICATION VS REFUTATION
Debido a que la comprobación raras veces puede ser automatizada, existen 2 opciones: verificación o refutación.
La verificación consiste en un análisis intentando encontrar una prueba para la propiedad dada. Si no se encuentra ninguna prueba, la propiedad aun puede ser válida, pero dichos análisis muy poco probablemente fallan, de modo que permiten al usuario determinar si es la estrategia de prueba o el modelo en si, lo que está fallando.
La refutación consiste en un análisis intentando refutar la propiedad dada encontrando un contraejemplo. Tales análisis por lo general emplean alguna forma de búsqueda en un espacio que ha sido artificialmente limitado. Si ningún contraejemplo es encontrado, entonces el límite era inapropiado (esto es, existen contraejemplos fuera del espacio buscado), o la propiedad no es válida.
DECLARATIVE VS OPERATIONAL STYLE
La mayor parte de lenguajes para modelos globales como Z, VDM y Larch son declarativos. En un lenguaje declarativo, constantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, como Statecharts y Promela, tienden a ser más operacionales, definiendo transiciones de una manera programática.
Los lenguajes operacionales corren el riesgo de las tendencias de ejecución, pero los modelos locales rara vez sufren de ello. La división del sistema como un todo en componentes que se comunican, es desde luego un paso de diseño intencional.
Los lenguajes declarativos traen varias ventajas a los modelos globales, para empezar, el modelo no tiene que determinar el comportamiento del sistema completamente. Para sistemas reactivos, esta forma a veces es vista como una deficiencia, pero en otros modelos es a menudo apropiado.
SOUND VS UNSOUND
Los análisis sólidos (sound) estáticos producen información que es garantizada para aguantar todas las ejecuciones de programas, los análisis sólidos dinámicos producen información que es garantizada para aguantar solamente la ejecución analizada.
Los análisis poco sólidos (unsound) no proporcionan tales garantías.
Un análisis sólido, para determinar los valores potenciales de las variables globales, por ejemplo, podría usar un análisis indicador para asegurar que modela correctamente el efecto de las asignaciones indirectas que ocurren vía indicadores de variables globales.
Un análisis poco sólido simplemente podría explorar el programa para localizar y analizar sólo las tareas que usan la variable global directamente, por nombre. Puesto que tal análisis ignora el efecto de tareas indirectas, puede fallar en calcular todos los valores potenciales de variables globales.
La solidez de un análisis puede depender de las características del lenguaje de programación, si el programa usa ciertas características o no.
Las ventajas más importantes de los análisis poco sólidos son la facilidad con que pueden ser puestos en práctica, así como su eficacia. Un análisis poco sólido puede ser capaz de analizar programas que simplemente van más allá del alcance de un análisis sólido, y puede ser implementado en poco tiempo y esfuerzo en comparación de un análisis sólido.
SPEED VS PRECISION
FLOW-SENSITIVE VS FLOW INSENTIVE
Los análisis sensibles a flujo (flow-sensitive) toman en cuenta la orden de ejecución de las declaraciones del programa. Normalmente usan alguna forma de análisis de flujo de datos iterativo para producir un resultado de análisis potencialmente diferente para cada punto de programa.
Los análisis insensibles a flujo (flor-insentive) no toman en cuenta la orden de ejecución de las declaraciones del programa y son por tanto incapaces de extraer cualquier propiedad que dependa de esta orden. Regularmente usan alguna forma de análisis de tipo basada en producir un resultado de análisis que es válido para el programa entero.
A la larga, se espera que los análisis sensibles a flujo, en combinación con la información de diseño, jueguen el papel principal en el análisis de sistemas de software infraestructurales. Considerando su eficiencia y la facilidad relativa de uso, los análisis insensibles a flujo serán destacados en contextos donde el ingeniero debe confiar principalmente o exclusivamente en el código.
CONTEXT-SENSITIVE VS CONTEXT-INSENTIVE
Un análisis de contexto insensible (context-insentive) produce un solo resultado que es usado directamente en todos los contextos. Un análisis de contexto sensible (sensitive-context) produce un resultado diferente para cada contexto de análisis diferente.
La sensibilidad del contexto es esencial para analizar programas modernos en los cuales las abstracciones son penetrantes. Por lo tanto la futura investigación en el campo, probablemente se enfoque en los análisis de contexto sensible.
MULTITHREADED VS. SINGLETHREADED
En un programa multithreaded (con múltiples hilos), las corrientes de instrucción de varios hilos se pueden intercalar de maneras diferentes. Los algoritmos de análisis de flujo de datos clásicos simplemente no fueron diseñados para este modelo de cómputo.
Considerando la importancia de los hilos (threads) en los lenguajes modernos, se cree que el análisis de programas con múltiples hilos (multithreaded) se hará un área de investigación activa. También se cree que los lenguajes de modelado jugaran un papel importante en este campo y preverá el desarrollo de lenguajes de diseño para expresar propiedades importantes de los programas multithreaded, como la política de sincronización y el compartir las propiedades de objetos y datos.
MODEL-DRIVEN CODE ANALYSIS
El análisis estático puede ayudar al modelado, el valor de los modelos será enormemente sostenido si su correspondencia al código puede ser firmemente establecida. Los modelos pueden ayudar al análisis estático también. Existe un tercer elemento crucial en este acercamiento, más allá del modelado y el análisis: trazar un mapa para conectar los 2.
MODULAR ANALYSIS BY INDUCTION
En vez de analizar el programa entero como una unidad monolítica, el análisis modular analizará el programa en la granualidad (extensión) de sus componentes.
El modelado de lenguajes se volverá una forma popular para los ingenieros para especificar las propiedades requeridas para análisis modulares. En vez de especificar las propiedades relevantes en un lenguaje lógico de uso general, los ingenieros usarán lenguajes de modelado con un destino especial que son optimizados para expresar aspectos específicos del diseño total del programa así como las relaciones referentes entre objetos o la secuencia del programa de acciones externamente visibles.
GIVING ENGINEERS CONTROL
Los ingenieros necesitan diferentes grados de precisión en distintas situaciones, en diferentes puntos en un programa y para estructuras de datos diferentes. La aplicación de un solo análisis a través de todo el programa es por lo tanto contra productivo. En cambio, los investigadores se moverán en la dirección de análisis que acepten dirección del ingeniero vía lenguaje modelado en cuanto al nivel requerido de precisión.
CONCLUSIONS
En la década pasada, una apreciación para la rentabilidad ha causado que los investigadores identifiquen más cuidadosamente la información que los ingenieros necesitan y encontrar el medio más eficaz para obtenerlo.
Análisis exactos y sólidos se han estado cayendo, ya que sus precios son altos y sus escalas suelen ser pobres. En el futuro varios factores pueden traer tales análisis a la delantera otra vez: la demanda del software confiable, la disponibilidad de bastos recursos computacionales y quizás mas considerablemente, la explotación de modelos abstractos, para enfocar el esfuerzo del análisis donde la rentabilidad sea mayor y permitir el razonamiento modular sobre una gran escala.
ABSTRACT
A lo largo del artículo se habla del ‘analisis’ como la información referente al comportamiento del software, representado como un modelo abstracto o código.
ANALISIS VS DESCRIPTION
Con respecto al análisis de los modelos de sistemas, nos dice que es recomendable aplicar el análisis, que desarrollar simplemente el sistema, ya que realizar un análisis, antes de introducir el código, nos sirve para detectar problemas que podrían causarnos dificultades y costarnos mucho más si no se descubren en ese momento.
Los investigadores que trabajan sobre modelos abstractos se pueden dividir en 2, unos son los desarrolladores de Z, quienes se centran en la forma de el modelo y consideran al análisis como algo secundario; por otro lado están los desarrolladores de la revisión del modelo simbólico, que se centran en el análisis y prestan menos atención a la manera en la que se expresa el modelo.
Por su parte los exponentes del análisis argumentan que la motivación principal para tomar decisiones sobre el diseño es explorando sus consecuencias por medio del análisis, diseñar un lenguaje sin un análisis en mente es como diseñar un lenguaje de programación que no puede ser compilado. Por otra parte los exponentes de la descripción o forma del modelo, dicen que en el desarrollo del software el obstáculo principal no es encontrar los fallos ocultos, si no más bien definir los pasos del desarrollo, con notas que expresen con precisión las intenciones del desarrollador y sólo eso.
GLOBAL VS LOCAL
Por lo regular nos encontraremos con que el método orientado a objetos se refiere a modelados de objetos que nos muestran qué objetos existen y cómo se encuentran relacionados y declaran diagramas de transición, que muestran los estados de los objetos y las transiciones entre ellos .
Existen 2 tipos de modelos que dominan la descripción abstracta del software.
El primer tipo de modelo nos dice que el modelado de objetos es estático y los diagramas de transición son dinámicos. El modelado de objetos, regularmente no es más que diagramas de clases, mostrando las clases, las subclases y las relaciones entre ellas. Un diagrama de clases es una representación parcial de la estructura sintáctica del código, y en ese sentido es estático en comparación a un diagrama de transición que describe estados de tiempo de ejecución.
El otro tipo de modelo dice que los modelados de objetos son ‘información intensiva’ y los diagramas de transición son ‘control intensivo.
Los 2 tipos de modelos anteriores también podrían ser vistos como ‘global’ y ‘local’.
El modelado de objetos, describe las relaciones de forma global entre los elementos del sistema, sus estados son las configuraciones globales de objetos y sus transiciones son los cambios globales que resultan de los objetos que vienen y van, así como de las relaciones que son cambiadas. Por otro lado el diagrama de transición describe los estados de un objeto individual y el protocolo de interacciones entre objetos.
En un modelo global, el estado del sistema, como un todo, es directamente expresado, en un modelo local, el estado global surge de las definiciones de los estados locales.
SIMULATION VS CHEKCING
El chequeo o comprobación de un modelo es mucho más efectivo que una simulación en la exposición de errores sutiles. Sin embargo la simulación es demasiado útil. Construyendo un modelo incrementalmente, es fácil cometer errores que la simulación expone fácilmente.
La mayor parte de los programadores, tienen más confianza en su código cuando han visto algunos ejemplos de ejecución, esto es un fenómeno muy común. La experiencia nos dice que un modelo que ha sido simulado tiene menos posibilidades se contener errores notorios.
Uno de los motivos por los que la simulación ha sido subvalorada es que la comprobación tiene mejores resultados. Los inventores de herramientas para la comprobación de modelos están obligados a exponer por lo menos un ejemplo de un error sutil que fue detectado en un sistema real.
La comprobación será crucial, no sólo asegurar que el modelo está correcto, si no también establecer una correspondencia entre el código y su modelo abstracto
VERIFICATION VS REFUTATION
Debido a que la comprobación raras veces puede ser automatizada, existen 2 opciones: verificación o refutación.
La verificación consiste en un análisis intentando encontrar una prueba para la propiedad dada. Si no se encuentra ninguna prueba, la propiedad aun puede ser válida, pero dichos análisis muy poco probablemente fallan, de modo que permiten al usuario determinar si es la estrategia de prueba o el modelo en si, lo que está fallando.
La refutación consiste en un análisis intentando refutar la propiedad dada encontrando un contraejemplo. Tales análisis por lo general emplean alguna forma de búsqueda en un espacio que ha sido artificialmente limitado. Si ningún contraejemplo es encontrado, entonces el límite era inapropiado (esto es, existen contraejemplos fuera del espacio buscado), o la propiedad no es válida.
DECLARATIVE VS OPERATIONAL STYLE
La mayor parte de lenguajes para modelos globales como Z, VDM y Larch son declarativos. En un lenguaje declarativo, constantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, como Statecharts y Promela, tienden a ser más operacionales, definiendo transiciones de una manera programática.
Los lenguajes operacionales corren el riesgo de las tendencias de ejecución, pero los modelos locales rara vez sufren de ello. La división del sistema como un todo en componentes que se comunican, es desde luego un paso de diseño intencional.
Los lenguajes declarativos traen varias ventajas a los modelos globales, para empezar, el modelo no tiene que determinar el comportamiento del sistema completamente. Para sistemas reactivos, esta forma a veces es vista como una deficiencia, pero en otros modelos es a menudo apropiado.
SOUND VS UNSOUND
Los análisis sólidos (sound) estáticos producen información que es garantizada para aguantar todas las ejecuciones de programas, los análisis sólidos dinámicos producen información que es garantizada para aguantar solamente la ejecución analizada.
Los análisis poco sólidos (unsound) no proporcionan tales garantías.
Un análisis sólido, para determinar los valores potenciales de las variables globales, por ejemplo, podría usar un análisis indicador para asegurar que modela correctamente el efecto de las asignaciones indirectas que ocurren vía indicadores de variables globales.
Un análisis poco sólido simplemente podría explorar el programa para localizar y analizar sólo las tareas que usan la variable global directamente, por nombre. Puesto que tal análisis ignora el efecto de tareas indirectas, puede fallar en calcular todos los valores potenciales de variables globales.
La solidez de un análisis puede depender de las características del lenguaje de programación, si el programa usa ciertas características o no.
Las ventajas más importantes de los análisis poco sólidos son la facilidad con que pueden ser puestos en práctica, así como su eficacia. Un análisis poco sólido puede ser capaz de analizar programas que simplemente van más allá del alcance de un análisis sólido, y puede ser implementado en poco tiempo y esfuerzo en comparación de un análisis sólido.
SPEED VS PRECISION
FLOW-SENSITIVE VS FLOW INSENTIVE
Los análisis sensibles a flujo (flow-sensitive) toman en cuenta la orden de ejecución de las declaraciones del programa. Normalmente usan alguna forma de análisis de flujo de datos iterativo para producir un resultado de análisis potencialmente diferente para cada punto de programa.
Los análisis insensibles a flujo (flor-insentive) no toman en cuenta la orden de ejecución de las declaraciones del programa y son por tanto incapaces de extraer cualquier propiedad que dependa de esta orden. Regularmente usan alguna forma de análisis de tipo basada en producir un resultado de análisis que es válido para el programa entero.
A la larga, se espera que los análisis sensibles a flujo, en combinación con la información de diseño, jueguen el papel principal en el análisis de sistemas de software infraestructurales. Considerando su eficiencia y la facilidad relativa de uso, los análisis insensibles a flujo serán destacados en contextos donde el ingeniero debe confiar principalmente o exclusivamente en el código.
CONTEXT-SENSITIVE VS CONTEXT-INSENTIVE
Un análisis de contexto insensible (context-insentive) produce un solo resultado que es usado directamente en todos los contextos. Un análisis de contexto sensible (sensitive-context) produce un resultado diferente para cada contexto de análisis diferente.
La sensibilidad del contexto es esencial para analizar programas modernos en los cuales las abstracciones son penetrantes. Por lo tanto la futura investigación en el campo, probablemente se enfoque en los análisis de contexto sensible.
MULTITHREADED VS. SINGLETHREADED
En un programa multithreaded (con múltiples hilos), las corrientes de instrucción de varios hilos se pueden intercalar de maneras diferentes. Los algoritmos de análisis de flujo de datos clásicos simplemente no fueron diseñados para este modelo de cómputo.
Considerando la importancia de los hilos (threads) en los lenguajes modernos, se cree que el análisis de programas con múltiples hilos (multithreaded) se hará un área de investigación activa. También se cree que los lenguajes de modelado jugaran un papel importante en este campo y preverá el desarrollo de lenguajes de diseño para expresar propiedades importantes de los programas multithreaded, como la política de sincronización y el compartir las propiedades de objetos y datos.
MODEL-DRIVEN CODE ANALYSIS
El análisis estático puede ayudar al modelado, el valor de los modelos será enormemente sostenido si su correspondencia al código puede ser firmemente establecida. Los modelos pueden ayudar al análisis estático también. Existe un tercer elemento crucial en este acercamiento, más allá del modelado y el análisis: trazar un mapa para conectar los 2.
MODULAR ANALYSIS BY INDUCTION
En vez de analizar el programa entero como una unidad monolítica, el análisis modular analizará el programa en la granualidad (extensión) de sus componentes.
El modelado de lenguajes se volverá una forma popular para los ingenieros para especificar las propiedades requeridas para análisis modulares. En vez de especificar las propiedades relevantes en un lenguaje lógico de uso general, los ingenieros usarán lenguajes de modelado con un destino especial que son optimizados para expresar aspectos específicos del diseño total del programa así como las relaciones referentes entre objetos o la secuencia del programa de acciones externamente visibles.
GIVING ENGINEERS CONTROL
Los ingenieros necesitan diferentes grados de precisión en distintas situaciones, en diferentes puntos en un programa y para estructuras de datos diferentes. La aplicación de un solo análisis a través de todo el programa es por lo tanto contra productivo. En cambio, los investigadores se moverán en la dirección de análisis que acepten dirección del ingeniero vía lenguaje modelado en cuanto al nivel requerido de precisión.
CONCLUSIONS
En la década pasada, una apreciación para la rentabilidad ha causado que los investigadores identifiquen más cuidadosamente la información que los ingenieros necesitan y encontrar el medio más eficaz para obtenerlo.
Análisis exactos y sólidos se han estado cayendo, ya que sus precios son altos y sus escalas suelen ser pobres. En el futuro varios factores pueden traer tales análisis a la delantera otra vez: la demanda del software confiable, la disponibilidad de bastos recursos computacionales y quizás mas considerablemente, la explotación de modelos abstractos, para enfocar el esfuerzo del análisis donde la rentabilidad sea mayor y permitir el razonamiento modular sobre una gran escala.
lunes, 1 de octubre de 2007
RESUMEN
Las personas en las metodologías de ingeniería del software
El desarrollo de software estaba al alcance de personas altamente capacitadas. Los avances en los campos del hardware y software trajeron como consecuencia mayor potencia computacional. Las metodologías XP, DSDM o SCRUM, se popularizaron a partir de principios del 2000, esta metodología se apoya en el valor individual de las personas.
Las personas al inicio de la informática: protoingenieria del software
Los “proingenieros de software” eran visionarios altamente calificados, generalmente adelantados a su tiempo.
Los cuatro mas distinguidos son:
Blas Pascal: invento la primera calculadora a la cual le llamo Pascaline.
Charles Babbage: diseño su Maquina Analítica que podía ser programada para solucionar problemas lógicos y computacionales.
John Von Newmann: el invento el concepto de Programa Almacenado, propuso al bit como unidad de información y resolvió el problema de la obtención de respuestas fiables con componentes no fiables, este fue conocido también como el padre de la vida artificial y a sus 23 años de edad fue maestro de la universidad de Berlín
.
Alan M. Turing:creador de la mMaquina de tiring, demostro que la base esencial de la informatica podia modelarse. Creo el primer ordenador teorico y propuso un metodo para determinar si una maquina es inteligente, el cual se le conoce como test de turing.
Metodologías pesadas.
Metodologías estructuradas clasicas.
Este concepto surge en 1975 de yourdon y meyers y se basa en la superacion y descomposición funcional de problemas en unidades ma pequeñas relacionadas entre si.
Las metodologías estructuradas hacen fuerte la separacion entre los datos y los procesos.Producen una gran cantidad de modelos y documentación que se basan en ciclos de vida en casacada.
Metodología orientada a objetos clasica
Con la orientación a objetos surgieron metodos, procesos y metodologías especificada como OMT, Objectori, RUP o metrica.
Ante las necedades de normalizar el proceso de desarrollo se propusieron unas metodologías que priman las faces, actividades y tareas antes que a las personas: lo mas importante es el rol que juega la persona en el proceo de desarrollo.Estos roles suelen ser muy similares en todos los procesos: administrador del proyecto, diseñador,progremador, entre otros.una de las ventajas de estos procesos es el intercambio de recursos fácilmente.
Las personas en Rup
Las personas en rup se denominan trabajadores, este define el comportamiento y las responsabilidades de un individuo.El hecho de que en un grupo no se tengan claros los roles genera problemas y puede que no se cubran los objetivos o que el trabajo de uno entre en conflicto con el otro, si las personas no se inbolucran las tareas de gestión, control y coordinación se multiplican.
Las personas en las metodologías agiles.
En los procesos agiles el éxito va en funcion a la participación de las personas en el mismo y buacan un mayor estado de bienestar para las personas que llevan a cabo el proceso de software a cambio de un mayor grado de compromiso.
Procesos agiles.
Los procesos agiles se vasan en principios tales como la temprana y continua entega de software de valor, la motivación individual de los integrantes del proyecto, la comunicación la excelencia técnica, la simplicidad, la comunicacio personal y la comunicacion.
Las personas en extreme programming (XP)
Xp les promete a los programadores que seran capaces de trabajar en cosas que realmente les importan. No tendran que enfrentarse solos a situaciones aterradoras. Podran provechar todas sus energias para hacer que todos sus sistema tengan éxito.
Conclusión
Analizado el rol de las personas en diferentes momentos de la ingenieria en softwareen funcion de este analisis el rol a variado significativamente con el paso del tiempo.
Categorías:
Irremplazable: la tarea solo puede ser realizada por una unica persona.
Difícil de reemplazar: las capacidades individuales de las personas tienen gran relevancia, lo cual hace que sean difíciles de remplazar.
Moderadamente reemplazable: si bien una persona puede ser remplazada por otra, puede existir consecuencias no deseadas que serán productos del reemplazo.
Fácilmente reemplazable: una persona puede ser reemplazada por otra sin ningún tipo de problemas.
El desarrollo de software estaba al alcance de personas altamente capacitadas. Los avances en los campos del hardware y software trajeron como consecuencia mayor potencia computacional. Las metodologías XP, DSDM o SCRUM, se popularizaron a partir de principios del 2000, esta metodología se apoya en el valor individual de las personas.
Las personas al inicio de la informática: protoingenieria del software
Los “proingenieros de software” eran visionarios altamente calificados, generalmente adelantados a su tiempo.
Los cuatro mas distinguidos son:
Blas Pascal: invento la primera calculadora a la cual le llamo Pascaline.
Charles Babbage: diseño su Maquina Analítica que podía ser programada para solucionar problemas lógicos y computacionales.
John Von Newmann: el invento el concepto de Programa Almacenado, propuso al bit como unidad de información y resolvió el problema de la obtención de respuestas fiables con componentes no fiables, este fue conocido también como el padre de la vida artificial y a sus 23 años de edad fue maestro de la universidad de Berlín
.
Alan M. Turing:creador de la mMaquina de tiring, demostro que la base esencial de la informatica podia modelarse. Creo el primer ordenador teorico y propuso un metodo para determinar si una maquina es inteligente, el cual se le conoce como test de turing.
Metodologías pesadas.
Metodologías estructuradas clasicas.
Este concepto surge en 1975 de yourdon y meyers y se basa en la superacion y descomposición funcional de problemas en unidades ma pequeñas relacionadas entre si.
Las metodologías estructuradas hacen fuerte la separacion entre los datos y los procesos.Producen una gran cantidad de modelos y documentación que se basan en ciclos de vida en casacada.
Metodología orientada a objetos clasica
Con la orientación a objetos surgieron metodos, procesos y metodologías especificada como OMT, Objectori, RUP o metrica.
Ante las necedades de normalizar el proceso de desarrollo se propusieron unas metodologías que priman las faces, actividades y tareas antes que a las personas: lo mas importante es el rol que juega la persona en el proceo de desarrollo.Estos roles suelen ser muy similares en todos los procesos: administrador del proyecto, diseñador,progremador, entre otros.una de las ventajas de estos procesos es el intercambio de recursos fácilmente.
Las personas en Rup
Las personas en rup se denominan trabajadores, este define el comportamiento y las responsabilidades de un individuo.El hecho de que en un grupo no se tengan claros los roles genera problemas y puede que no se cubran los objetivos o que el trabajo de uno entre en conflicto con el otro, si las personas no se inbolucran las tareas de gestión, control y coordinación se multiplican.
Las personas en las metodologías agiles.
En los procesos agiles el éxito va en funcion a la participación de las personas en el mismo y buacan un mayor estado de bienestar para las personas que llevan a cabo el proceso de software a cambio de un mayor grado de compromiso.
Procesos agiles.
Los procesos agiles se vasan en principios tales como la temprana y continua entega de software de valor, la motivación individual de los integrantes del proyecto, la comunicación la excelencia técnica, la simplicidad, la comunicacio personal y la comunicacion.
Las personas en extreme programming (XP)
Xp les promete a los programadores que seran capaces de trabajar en cosas que realmente les importan. No tendran que enfrentarse solos a situaciones aterradoras. Podran provechar todas sus energias para hacer que todos sus sistema tengan éxito.
Conclusión
Analizado el rol de las personas en diferentes momentos de la ingenieria en softwareen funcion de este analisis el rol a variado significativamente con el paso del tiempo.
Categorías:
Irremplazable: la tarea solo puede ser realizada por una unica persona.
Difícil de reemplazar: las capacidades individuales de las personas tienen gran relevancia, lo cual hace que sean difíciles de remplazar.
Moderadamente reemplazable: si bien una persona puede ser remplazada por otra, puede existir consecuencias no deseadas que serán productos del reemplazo.
Fácilmente reemplazable: una persona puede ser reemplazada por otra sin ningún tipo de problemas.
miércoles, 12 de septiembre de 2007
DESCRIPCION DEL PROBLEMA
Nuetros objetivos es que nuestro programa determine el salario de los trabajadores que laboran en nuestra empresa de acuerdo a las horas trabajadas y la maquinaria que maneja.
Suscribirse a:
Entradas (Atom)