miércoles, 26 de mayo de 2010
RECUPERACION QUE ES DIAGRAMA DE COLABORACION
Que es diagrama de colaboración:
Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de comunicación muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de comunicación muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
lunes, 10 de mayo de 2010
CODIFICACION
Autoevaluación
1. Qué es un lenguaje de programación?
Aunque es en apariencia una cuestión académica, el diseño de lenguajes es de vital importancia para el ingeniero de software. Los lenguajes de programación son sus instrumentos básicos, y debe retroalimentar información sobre la confiabilidad y utilidad de los lenguajes de programación a los diseñadores de los lenguajes de programación a los diseñadores de los lenguajes. El ingeniero de software debe tener conocimiento de los lenguajes de programación para poder tomar decisiones razonadas sobre el lenguaje mas adecuado a sus aplicaciones particulares
2. ¿Cómo debe ser el estilo de codificación?
Una vez generado el código fuente, la función de un módulo debe ser clara sin necesidad de referirse a ningún diseño, el código debe ser comprensible(debe mezclarse la simplicidad con la claridad). Entre los elementos de estilo se encuentran la documentación interna(a nivel código fuente), los métodos de declaración de datos, enfoque de construcción de sentencias y las técnicas de entrada y salida.
3. ¿Cuáles son los criterios que se aplican para la evaluación de lenguajes disponibles?
Los requisitos del contratista del sistema
Disponibilidades de compiladores del lenguaje
Disponibilidad de instrumentos de software para apoyar el desarrollo de los programas.
Tamaño del proceso.
Conocimiento del personal de programación existente.
Lenguaje de programación utilizado en proyecto previos
Necesidad de transportar el software.
La aplicación que se esta programando
Autoevaluación
1. ¿Cómo debe ser la documentación del código?
La documentación comienza con la elección de los nombres de los identificadores(variables y etiquetas), continúa con la localización y composición de los comentarios y termina con la organización visual del programa.
2. ¿Qué es la documentación interna?
El software debe contener documentación interna. Los comentarios permiten al programador comunicarse con otros lectores de código fuente. Los comentarios pueden también resultar una clara guía de comprensión durante la última fase de la ingeniería de software –el mantenimiento.
3. ¿Cuáles son las carácteristicas que deben contener los comentarios descriptivos?
Los comentarios descriptivos se incluyen en el cuerpo del código fuente y se usan para describir las funciones del procesamiento. "los comentarios deben proporcionar algún extra no solamente parafrasear el código"
Describir los bloques de código en vez de describir cada línea.
Usar líneas en blanco o tabulaciones de forma que sean fácilmente distinguibles del código.
Que sean correctos, un comentario incorrecto o que se pueda interpretar mal es peor
que no ponerlo.
1. Qué es un lenguaje de programación?
Aunque es en apariencia una cuestión académica, el diseño de lenguajes es de vital importancia para el ingeniero de software. Los lenguajes de programación son sus instrumentos básicos, y debe retroalimentar información sobre la confiabilidad y utilidad de los lenguajes de programación a los diseñadores de los lenguajes de programación a los diseñadores de los lenguajes. El ingeniero de software debe tener conocimiento de los lenguajes de programación para poder tomar decisiones razonadas sobre el lenguaje mas adecuado a sus aplicaciones particulares
2. ¿Cómo debe ser el estilo de codificación?
Una vez generado el código fuente, la función de un módulo debe ser clara sin necesidad de referirse a ningún diseño, el código debe ser comprensible(debe mezclarse la simplicidad con la claridad). Entre los elementos de estilo se encuentran la documentación interna(a nivel código fuente), los métodos de declaración de datos, enfoque de construcción de sentencias y las técnicas de entrada y salida.
3. ¿Cuáles son los criterios que se aplican para la evaluación de lenguajes disponibles?
Los requisitos del contratista del sistema
Disponibilidades de compiladores del lenguaje
Disponibilidad de instrumentos de software para apoyar el desarrollo de los programas.
Tamaño del proceso.
Conocimiento del personal de programación existente.
Lenguaje de programación utilizado en proyecto previos
Necesidad de transportar el software.
La aplicación que se esta programando
Autoevaluación
1. ¿Cómo debe ser la documentación del código?
La documentación comienza con la elección de los nombres de los identificadores(variables y etiquetas), continúa con la localización y composición de los comentarios y termina con la organización visual del programa.
2. ¿Qué es la documentación interna?
El software debe contener documentación interna. Los comentarios permiten al programador comunicarse con otros lectores de código fuente. Los comentarios pueden también resultar una clara guía de comprensión durante la última fase de la ingeniería de software –el mantenimiento.
3. ¿Cuáles son las carácteristicas que deben contener los comentarios descriptivos?
Los comentarios descriptivos se incluyen en el cuerpo del código fuente y se usan para describir las funciones del procesamiento. "los comentarios deben proporcionar algún extra no solamente parafrasear el código"
Describir los bloques de código en vez de describir cada línea.
Usar líneas en blanco o tabulaciones de forma que sean fácilmente distinguibles del código.
Que sean correctos, un comentario incorrecto o que se pueda interpretar mal es peor
que no ponerlo.
AUTOEVALUCION
DISEÑO ORIENTADO A OBJETOS
Autoevaluación
1. ¿En que se basa el enfoque de diseño orientado a objetos?
Este enfoque de diseño orientado al objeto que se basa en una descripción del problema el lenguaje natural parece ser útil en algunas circunstancias. Sin embargo, no está claro como se puede aplicar al diseño de sistemas grandes y complejos. Cuando un sistema es complejo y con muchas funciones en relación reciproca, es en verdad muy difícil producir una descripción del lenguaje natural y de manera concisa y completa. Por lo tanto, es probable que se presenten errores, omisiones e inconsistencias en la descripción informal de un problema.
2. ¿Cuáles son los tipos de datos abstractos?
Dada esta descripción, se extraen nombres comunes, con fechas, mensajes, documentos, diccionarios, etc., y se consideran tipos de datos abstractos.
3. En que se basa el diseño orientado a objeto
El diseño orientado a objetos se basa en la idea de utilizar ocultamiento de información como principal criterio de descomposición y en la noción de los tipos de datos abstractos. Esta metodología ha sido adoptada de manera entusiasta de algunos desarrolladores y educadores. Abbot ha llegado a decir que "los programas bien escritos en Ada suelen ser orientados al objeto", no está bien escrito. Tales generalizaciones sin comprobar no son de ayuda, y es poco probable que haya alguna metodología de diseño que sea superior a todas las circunstancias.
DISEÑO DE LA SALIDA
Autoevaluación
1. ¿Cuál es el diseño de salida?
Diseñar la salida para que sirva al propósito deseado.
Diseñar la salida para que se ajuste al usuario.
Entregar la cantidad adecuada de salida.
Asegurarse de que la salida se encuentra donde se necesita.
Entregar la salida a tiempo.
Seleccionar el método de salida adecuado.
2. ¿Cómo seleccionar la tecnología de salida?
El producir diferentes tipos de salida requiere el uso de diferentes tecnologías para la salida de la computadora impresa. Las opciones incluyen impresoras de impacto o no. Para la salida en pantalla las opciones incluyen tubos de rayos catódicos conectados o aislados o pantallas de cristal líquido. La salida de audio puede ser amplificada y emitida por un altavoz o escuchada por medio de bocinas pequeñas en una PC. Las microformas de salida son creadas por cámaras especialmente equipadas y películas en microficha o microfilm.
3. ¿Cómo debe ser la relación del contenido de la salida con el método de salida?
El contenido de la salida de los sistemas de información debe considerarse interrelacionado con el método de salida. Cada vez que se diseña una salida, es necesario pensar sobre cómo la función influencia la forma y cómo el propósito influencia la salida que se escoge. Se debe pensar en forma general sobre la salida, para que en cualquier información que salga del sistema de cómputo y que sea útil de alguna forma a las gentes, pueda ser considerada la salida.
4. ¿Cuáles son los factores a considerar cuando se selecciona la tecnología de salida?
¿Quién usara la salida? Descubrir quien usara la salida es importante, debido a que los requerimientos de trabajo ayudan a indicar cuál es el medio de salida es adecuado. También se aplican diferentes estándares, dependiendo si el receptor de la salida es interno (clientes, vendedores, accionistas y agencias reglamentadoras) requerirán diferente salida que los usuarios internos del negocio.
DISEÑO DE ENTRADA
Autoevaluación
1. ¿Cuál es el diseño de entrada?
La calidad de la entrada de un sistema determina la calidad de la salida del sistema.
Es vital que las formas y pantallas de entrada sean diseñadas con esta relación crítica en mente.
Al asistir en entrada bien diseñada, el analista de sistemas está reconociendo que la entrada pobre plantea preguntas sobre la confiabilidad del sistema completo.
2. ¿Cuales son algunas desventajas del uso de formas especiales?
3. ¿Cómo debe ser el diseño de formas atractivas?
Para ser atractivas, las formas deben solicitar la información en el orden esperado, las convenciones indican que se pida el nombre, la calle, la ciudad, estado y el código postal y el país, en caso necesario.
4. ¿Cuáles son las secciones de una pantalla?
· La parte superior de la pantalla tiene una sección de encabezado, parte de la cual está escrita en el software para describir al usuario en que parte del paquete se encuentra.
· La sección media es llamada el cuerpo de la pantalla. Este puede ser usado para la captura de datos, y es organizado de izquierda a derecha y de arriba hacia abajo.
· La tercera sección de la pantalla es la sección de comentarios e instrucciones: esta sección puede desplegar un menú corto de comandos que recuerden al usuario los puntos básicos, tales como cambiar pantallas o funciones, guardar el archivo o terminar la captura. La inclusión de estos puntos básicos puede hacer que los usuarios sin experiencia se encuentren mucho más seguros acerca de su habilidad para operar la computadora sin causar un error fatal.
DISEÑO DE BASES DE DATOS
Autoevaluación
1. ¿Cuál es el diseño de base de datos?
Primero, los datos tienen que estar disponibles cuando el usuario quiere usarlos. Segundo, los datos deben ser precisos y consistentes (deben poseer integridad). Aparte de esto, los objetivos del diseño de base de datos incluyen el almacenamiento eficiente de los datos, así como su eficiente actualización y recuperación. Por último, es necesario que la recuperación de información tenga un propósito. La información obtenida de los datos almacenados debe estar en un formato útil para la administración, planeación, control o toma de decisiones.
2. ¿Qué son las bases de datos?
Es una fuente central de datos que está pensada para que sea compartida por muchos usuarios con una diversidad de aplicaciones.
3. ¿cuáles son los tipos de archivos?
Los archivos maestros y los archivos de tablas son usados para guardar datos durante un periodo largo. Los archivos temporales son llamados, por lo general, archivos de transacciones, archivos de trabajo o archivos de reporte.
4. ¿En qué consiste la organización secuencial?
Cuando los registros están físicamente en orden en un archivo se dice que el archivo es un archivo secuencial. Cuando es actualizado un archivo secuencial es necesario recorrer todo el archivo. Debido a que los registros no pueden ser insertados en la parte media del archivo, el archivo secuencial es por lo general, copiado durante el proceso de actualización.
5. ¿Cuáles son las listas encadenadas?
Cuando se guardan archivos en dispositivos de acceso directo, tales como disco o tambor, las opciones se expanden. Los registros pueden ser ordenados en forma lógica, en vez de física, usando listas encadenadas. Las listas encadenadas se logran usando un juego de apuntadores para dirigirse al siguiente registro lógico que se encuentre ubicado en cualquier parte del archivo.
DISEÑO DE LA INTERFAZ HOMBRE-MAQUINA
Autoevaluación
1. ¿Qué es el diseño de la interfaz hombre-máquina?
El diseño de la interfaz hombre-máquina es la función en donde se definen las tareas orientadas al hombre y a la maquina, requeridas para conseguir la función del sistema
2. ¿Para qué sirven los modelos de diseño de interfaz?
Sirven para saber en qué aspectos se puede mejorar el diseño desde la perspectiva del usuario y el diseñador.
3. ¿Cuáles son los 4 aspectos comunes del diseño que casi siempre emergen a medida que evoluciona el diseño de la interfaz del usuario?
El tiempo de respuesta del sistema, las facilidades de ayuda al usuario, la manipulación de la información de errores y el etiquetado de órdenes.
4. ¿Cuál es el papel del diseñador de interfaces?
Conocer las necesidades del usuario y satisfacerlas.
Autoevaluación
1. ¿En que se basa el enfoque de diseño orientado a objetos?
Este enfoque de diseño orientado al objeto que se basa en una descripción del problema el lenguaje natural parece ser útil en algunas circunstancias. Sin embargo, no está claro como se puede aplicar al diseño de sistemas grandes y complejos. Cuando un sistema es complejo y con muchas funciones en relación reciproca, es en verdad muy difícil producir una descripción del lenguaje natural y de manera concisa y completa. Por lo tanto, es probable que se presenten errores, omisiones e inconsistencias en la descripción informal de un problema.
2. ¿Cuáles son los tipos de datos abstractos?
Dada esta descripción, se extraen nombres comunes, con fechas, mensajes, documentos, diccionarios, etc., y se consideran tipos de datos abstractos.
3. En que se basa el diseño orientado a objeto
El diseño orientado a objetos se basa en la idea de utilizar ocultamiento de información como principal criterio de descomposición y en la noción de los tipos de datos abstractos. Esta metodología ha sido adoptada de manera entusiasta de algunos desarrolladores y educadores. Abbot ha llegado a decir que "los programas bien escritos en Ada suelen ser orientados al objeto", no está bien escrito. Tales generalizaciones sin comprobar no son de ayuda, y es poco probable que haya alguna metodología de diseño que sea superior a todas las circunstancias.
DISEÑO DE LA SALIDA
Autoevaluación
1. ¿Cuál es el diseño de salida?
Diseñar la salida para que sirva al propósito deseado.
Diseñar la salida para que se ajuste al usuario.
Entregar la cantidad adecuada de salida.
Asegurarse de que la salida se encuentra donde se necesita.
Entregar la salida a tiempo.
Seleccionar el método de salida adecuado.
2. ¿Cómo seleccionar la tecnología de salida?
El producir diferentes tipos de salida requiere el uso de diferentes tecnologías para la salida de la computadora impresa. Las opciones incluyen impresoras de impacto o no. Para la salida en pantalla las opciones incluyen tubos de rayos catódicos conectados o aislados o pantallas de cristal líquido. La salida de audio puede ser amplificada y emitida por un altavoz o escuchada por medio de bocinas pequeñas en una PC. Las microformas de salida son creadas por cámaras especialmente equipadas y películas en microficha o microfilm.
3. ¿Cómo debe ser la relación del contenido de la salida con el método de salida?
El contenido de la salida de los sistemas de información debe considerarse interrelacionado con el método de salida. Cada vez que se diseña una salida, es necesario pensar sobre cómo la función influencia la forma y cómo el propósito influencia la salida que se escoge. Se debe pensar en forma general sobre la salida, para que en cualquier información que salga del sistema de cómputo y que sea útil de alguna forma a las gentes, pueda ser considerada la salida.
4. ¿Cuáles son los factores a considerar cuando se selecciona la tecnología de salida?
¿Quién usara la salida? Descubrir quien usara la salida es importante, debido a que los requerimientos de trabajo ayudan a indicar cuál es el medio de salida es adecuado. También se aplican diferentes estándares, dependiendo si el receptor de la salida es interno (clientes, vendedores, accionistas y agencias reglamentadoras) requerirán diferente salida que los usuarios internos del negocio.
DISEÑO DE ENTRADA
Autoevaluación
1. ¿Cuál es el diseño de entrada?
La calidad de la entrada de un sistema determina la calidad de la salida del sistema.
Es vital que las formas y pantallas de entrada sean diseñadas con esta relación crítica en mente.
Al asistir en entrada bien diseñada, el analista de sistemas está reconociendo que la entrada pobre plantea preguntas sobre la confiabilidad del sistema completo.
2. ¿Cuales son algunas desventajas del uso de formas especiales?
3. ¿Cómo debe ser el diseño de formas atractivas?
Para ser atractivas, las formas deben solicitar la información en el orden esperado, las convenciones indican que se pida el nombre, la calle, la ciudad, estado y el código postal y el país, en caso necesario.
4. ¿Cuáles son las secciones de una pantalla?
· La parte superior de la pantalla tiene una sección de encabezado, parte de la cual está escrita en el software para describir al usuario en que parte del paquete se encuentra.
· La sección media es llamada el cuerpo de la pantalla. Este puede ser usado para la captura de datos, y es organizado de izquierda a derecha y de arriba hacia abajo.
· La tercera sección de la pantalla es la sección de comentarios e instrucciones: esta sección puede desplegar un menú corto de comandos que recuerden al usuario los puntos básicos, tales como cambiar pantallas o funciones, guardar el archivo o terminar la captura. La inclusión de estos puntos básicos puede hacer que los usuarios sin experiencia se encuentren mucho más seguros acerca de su habilidad para operar la computadora sin causar un error fatal.
DISEÑO DE BASES DE DATOS
Autoevaluación
1. ¿Cuál es el diseño de base de datos?
Primero, los datos tienen que estar disponibles cuando el usuario quiere usarlos. Segundo, los datos deben ser precisos y consistentes (deben poseer integridad). Aparte de esto, los objetivos del diseño de base de datos incluyen el almacenamiento eficiente de los datos, así como su eficiente actualización y recuperación. Por último, es necesario que la recuperación de información tenga un propósito. La información obtenida de los datos almacenados debe estar en un formato útil para la administración, planeación, control o toma de decisiones.
2. ¿Qué son las bases de datos?
Es una fuente central de datos que está pensada para que sea compartida por muchos usuarios con una diversidad de aplicaciones.
3. ¿cuáles son los tipos de archivos?
Los archivos maestros y los archivos de tablas son usados para guardar datos durante un periodo largo. Los archivos temporales son llamados, por lo general, archivos de transacciones, archivos de trabajo o archivos de reporte.
4. ¿En qué consiste la organización secuencial?
Cuando los registros están físicamente en orden en un archivo se dice que el archivo es un archivo secuencial. Cuando es actualizado un archivo secuencial es necesario recorrer todo el archivo. Debido a que los registros no pueden ser insertados en la parte media del archivo, el archivo secuencial es por lo general, copiado durante el proceso de actualización.
5. ¿Cuáles son las listas encadenadas?
Cuando se guardan archivos en dispositivos de acceso directo, tales como disco o tambor, las opciones se expanden. Los registros pueden ser ordenados en forma lógica, en vez de física, usando listas encadenadas. Las listas encadenadas se logran usando un juego de apuntadores para dirigirse al siguiente registro lógico que se encuentre ubicado en cualquier parte del archivo.
DISEÑO DE LA INTERFAZ HOMBRE-MAQUINA
Autoevaluación
1. ¿Qué es el diseño de la interfaz hombre-máquina?
El diseño de la interfaz hombre-máquina es la función en donde se definen las tareas orientadas al hombre y a la maquina, requeridas para conseguir la función del sistema
2. ¿Para qué sirven los modelos de diseño de interfaz?
Sirven para saber en qué aspectos se puede mejorar el diseño desde la perspectiva del usuario y el diseñador.
3. ¿Cuáles son los 4 aspectos comunes del diseño que casi siempre emergen a medida que evoluciona el diseño de la interfaz del usuario?
El tiempo de respuesta del sistema, las facilidades de ayuda al usuario, la manipulación de la información de errores y el etiquetado de órdenes.
4. ¿Cuál es el papel del diseñador de interfaces?
Conocer las necesidades del usuario y satisfacerlas.
lunes, 26 de abril de 2010
lunes, 19 de abril de 2010
lunes, 12 de abril de 2010
lunes, 5 de abril de 2010
requerimientos funcionales y no funcionales
¿Qué son Requerimientos funcionales y no funcionales?
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.Conciso: Un requerimiento es conciso si es fácil de leer y entender. Suredacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona lainformación suficiente para su comprensión.Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difíciles de expresar en palabras (ellenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.Conciso: Un requerimiento es conciso si es fácil de leer y entender. Suredacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona lainformación suficiente para su comprensión.Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difíciles de expresar en palabras (ellenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
domingo, 21 de marzo de 2010
LENGUAJE MODELADO
Lenguajes de modelado
El modelado de sistemas software es una técnica para tratar con la complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir. Además, los modelos de un nivel de abstracción mayor pueden utilizarse para la comunicación con el cliente. Por último, las herramientas de modelado y las de Ingeniería de Software Automatizada. pueden ayudar a verificar la corrección del modelo.El lenguaje de modelado de objetos es un conjunto estandarizado de símbolos y de modos de disponerlos para modelar (parte de) un diseño de software orientado a objetos.Algunas organizaciones los usan extensivamente en combinación con una metodología de desarrollo de software para avanzar de una especificación inicial a un plan de implementación y para comunicar dicho plan a todo un equipo de desarrolladores. El uso de un lenguaje de modelado es más sencillo que la auténtica programación, pues existen menos medios para verificar efectivamente el funcionamiento adecuado del modelo. Esto puede suponer también que las interacciones entre partes del programa den lugar a sorpresas cuando el modelo ha sido convertido en un software funcionante.Algunos metodólogos del software orientado a objetos distinguen tres grandes "generaciones" cronológicas de técnicas de modelado de objetos:- En la primera generación, tecnólogos aislados y grupos pequeños desarrollaban técnicas que resolvían problemas que se encontraban de primera mano en los proyectos de desarrollo orientado a objetos. En esta generación se incluye a autores y técnicas como Rumbaugh, Jacobson, Booch, los métodos formales, Shlaer-Mellor y Yourdon-Coad.- En la segunda generación se reconoció que muchas de las mejores prácticas pertenecían a diferentes métodos del fragmentado terreno de la metodología orientada a objetos. Se realizaron múltiples intentos para integrar dichas técnicas en marcos coherentes tales como FUSION. En cualquier caso, la comunidad del software orientado a objetos empezaba a reconocer los beneficios que la standarización de las técnicas conllevaría: abandono de las "buenas" formas de hacer las cosas en favor de "la" manera adecuada, que permitiría un lenguaje y unas prácticas comunes entre los diferentes desarrolladores.- La tercera generación consiste en intentos creíbles de crear dicho lenguaje unificado por la industria, cuyo mejor ejemplo es UMLObtenido de "http://es.wikipedia.org/wiki/Lenguaje_de_modelado_de_objetos"
El modelado de sistemas software es una técnica para tratar con la complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir. Además, los modelos de un nivel de abstracción mayor pueden utilizarse para la comunicación con el cliente. Por último, las herramientas de modelado y las de Ingeniería de Software Automatizada. pueden ayudar a verificar la corrección del modelo.El lenguaje de modelado de objetos es un conjunto estandarizado de símbolos y de modos de disponerlos para modelar (parte de) un diseño de software orientado a objetos.Algunas organizaciones los usan extensivamente en combinación con una metodología de desarrollo de software para avanzar de una especificación inicial a un plan de implementación y para comunicar dicho plan a todo un equipo de desarrolladores. El uso de un lenguaje de modelado es más sencillo que la auténtica programación, pues existen menos medios para verificar efectivamente el funcionamiento adecuado del modelo. Esto puede suponer también que las interacciones entre partes del programa den lugar a sorpresas cuando el modelo ha sido convertido en un software funcionante.Algunos metodólogos del software orientado a objetos distinguen tres grandes "generaciones" cronológicas de técnicas de modelado de objetos:- En la primera generación, tecnólogos aislados y grupos pequeños desarrollaban técnicas que resolvían problemas que se encontraban de primera mano en los proyectos de desarrollo orientado a objetos. En esta generación se incluye a autores y técnicas como Rumbaugh, Jacobson, Booch, los métodos formales, Shlaer-Mellor y Yourdon-Coad.- En la segunda generación se reconoció que muchas de las mejores prácticas pertenecían a diferentes métodos del fragmentado terreno de la metodología orientada a objetos. Se realizaron múltiples intentos para integrar dichas técnicas en marcos coherentes tales como FUSION. En cualquier caso, la comunidad del software orientado a objetos empezaba a reconocer los beneficios que la standarización de las técnicas conllevaría: abandono de las "buenas" formas de hacer las cosas en favor de "la" manera adecuada, que permitiría un lenguaje y unas prácticas comunes entre los diferentes desarrolladores.- La tercera generación consiste en intentos creíbles de crear dicho lenguaje unificado por la industria, cuyo mejor ejemplo es UMLObtenido de "http://es.wikipedia.org/wiki/Lenguaje_de_modelado_de_objetos"
lunes, 8 de marzo de 2010
sábado, 6 de marzo de 2010
jueves, 4 de marzo de 2010
miércoles, 17 de febrero de 2010
Analisis
En analisis de sistemas es el primer paso, en este proceso en Analista se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.
martes, 16 de febrero de 2010
Analisis De Sistema
Es un conjunto o disposición de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Información.
Publicado por zerox2014 en 11:10 0 comentarios
Diseño
Utilizado habitualmente en el contexto de las artes aplicadas, ingeniería, arquitectura y otras disciplinas creativas, diseño se define como el proceso previo de configuración mental, "pre-figuración", en la búsqueda de una solución en cualquier campo.
Representada gráficamente del futuro, lo hecho es la obra, lo por hacer es el proyecto, el acto de diseñar como prefiguración es el proceso previo en la búsqueda de una solución o conjunto de las mismas. Plasmar el pensamiento de la solución mediante esbozos, dibujos, bocetos o esquemas trazados en cualquiera de los soportes, durante o posteriores a un proceso de observación de alternativas o investigación.
El acto intuitivo de diseñar podría llamarse creatividad como acto de creación o innovación si el objeto no existe, o es una modificación de lo existente inspiración abstracción, síntesis, ordenación y transformación.
Representada gráficamente del futuro, lo hecho es la obra, lo por hacer es el proyecto, el acto de diseñar como prefiguración es el proceso previo en la búsqueda de una solución o conjunto de las mismas. Plasmar el pensamiento de la solución mediante esbozos, dibujos, bocetos o esquemas trazados en cualquiera de los soportes, durante o posteriores a un proceso de observación de alternativas o investigación.
El acto intuitivo de diseñar podría llamarse creatividad como acto de creación o innovación si el objeto no existe, o es una modificación de lo existente inspiración abstracción, síntesis, ordenación y transformación.
lunes, 15 de febrero de 2010
Diseño De Sistema
El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado.
Publicado por zerox2014 en 11:05 0 comentarios
Publicado por zerox2014 en 11:05 0 comentarios
sábado, 13 de febrero de 2010
El Papel De La Informacion
El objetivo global de la ingeniería de la información es aplicar tecnología de información de la mejor manera que satisfaga las necesidades generales del negocio. Para conseguirlo la ingeniería de la información debe empezar por analizar los objetivos y metas del negocio, después debe definir las necesidades de la información de cada área de negocio y del negocio en su totalidad. Solo después de hacer esto la ingeniería de la información hace la transición al dominio más técnico de la ingeniería de software; el proceso, donde los sistemas de información, aplicaciones y programas son analizados, diseñados y construidos.
Publicado por zerox2014 en 11:00 0 comentarios
Publicado por zerox2014 en 11:00 0 comentarios
jueves, 11 de febrero de 2010
El Papel Del Analista
El analista de sistemas generalmente valora la manera que funcionan los negocios examinando la entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los procesos organizacionales.Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso de sistemas de información computarizados. Esta definición enfatiza un enfoque sistemático y metódico para analizar, y posiblemente mejorar, lo que esta sucediendo con el contexto especifico creado por un negocio.Se requiere que los analistas de sistemas desempeñen muchos paquetes en el curso de su trabajo. Algunos de estos papeles son: 1. Consultores externos para negocios.2. Experto de soporte dentro de un negocio.3. Agente de cambio en situaciones tanto internas como externas.Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional. Los analistas de sistemas requieren habilidades de comunicación que les permitan relacionarse en forma significativa con muchos tipos de gente diariamente, así como habilidades de computación. Para su éxito es necesario que se involucre el usuario final.Los analistas proceden sistemáticamente. El marco de referencia para su enfoque sistemático es proporcionado por lo que es llamado el ciclo de vida del desarrollo de sistemas (SDLC). Este puede ser dividido en siete fases secuenciales, aunque en realidad las fases están interrelacionadas y frecuentemente se llevan a cabo simultáneamente. Las siete fases son:1. Identificación de problemas.2. Oportunidades y objetivos3. Determinación de los requerimientos de información4. Análisis de las necesidades de sistemas5. Diseño del sistema recomendado6. Desarrollo y documentación del software7. Prueba y mantenimiento del sistema e implementación del mismo.Los paquetes de software basados en microcomputadora automatizado para el análisis y diseño de sistemas son llamados herramientas CASE. Las cuatro razones para la adopción de herramientas CASE son:1. El incremento de la productividad del analista2. La mejora de la comunicación entre analistas y usuarios3. La integración de actividades del ciclo de vida y el análisis.4. La valoración del impacto de los cambios por mantenimiento.Los analistas también usan enfoque CARE (Reingeniería Asistida por Computadora) para hacer ingeniería inversa y reingeniería de software para extender la vida del software legado.Un enfoque nuevo y diferente al análisis y diseño de sistemas es el análisis y diseño de sistemas orientados a objetos (O-O). Estas técnicas están basadas en conceptos de programación orientada a objetos en los cuales los objetos, que son creados incluyen no solamente código acerca de los datos sino también instrucciones acerca de las operaciones que se pueden realizar con ellos.Cuando la situación organizacional lo demanda, el analista puede apartarse del SDLC para intentar una metodología alterna, tal como la elaboración de prototipos, ETHICS, el enfoque de campeón de proyecto, la metodología Soft Systems o Multiview.
Publicado por zerox2014 en 10:50 0 comentarios
Suscribirse a: Entradas (Atom)
Publicado por zerox2014 en 10:50 0 comentarios
Suscribirse a: Entradas (Atom)
Suscribirse a:
Entradas (Atom)
