lunes, 26 de abril de 2010
martes, 13 de abril de 2010
martes, 6 de abril de 2010
INGENIERIA DE REQUISITOS
En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
Fases de implementación
Desde un punto de vista conceptual, las actividades son de 5 clases.
-Obtener requisitos: A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
-Analizar requisitos: Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
-Documentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.
-Verificar los requisitos: Consiste en comprobar el correcto funcionamiento de un requisito en la aplicación
-Validar los requisitos: Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.
Técnicas principales
Entrevistas:
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización
Talleres:
pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas.
Forma de contrato :
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles:
Los requisitos formulados por los usuarios se toman como objetivos generales,a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno
Prototipos:
Un prototipo es una pequeña muestra, de funcionalidad limitada.
Casos de uso:
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas.
Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
Fases de implementación
Desde un punto de vista conceptual, las actividades son de 5 clases.
-Obtener requisitos: A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
-Analizar requisitos: Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
-Documentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.
-Verificar los requisitos: Consiste en comprobar el correcto funcionamiento de un requisito en la aplicación
-Validar los requisitos: Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.
Técnicas principales
Entrevistas:
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización
Talleres:
pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas.
Forma de contrato :
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles:
Los requisitos formulados por los usuarios se toman como objetivos generales,a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno
Prototipos:
Un prototipo es una pequeña muestra, de funcionalidad limitada.
Casos de uso:
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas.
REQUERIMIENTO (sistemas)
En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.
En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.
¿Que es un requerimiento?
-Condición o capacidad que un usuario necesita para poder resolver un problema o
lograr un objetivo (IEEE).
-Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un
contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
-Una condición o capacidad que debe ser conformada por el sistema (RUP).
-Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).
Requerimientos en ingeniería de software y sistemas
En ingeniería de sistemas existen tres tipos de requerimientos.
-Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar.
-Un requerimiento no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
-Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.
Características
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
-Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
-No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
-Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
-Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
-Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
-Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
-Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.
En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.
¿Que es un requerimiento?
-Condición o capacidad que un usuario necesita para poder resolver un problema o
lograr un objetivo (IEEE).
-Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un
contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
-Una condición o capacidad que debe ser conformada por el sistema (RUP).
-Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).
Requerimientos en ingeniería de software y sistemas
En ingeniería de sistemas existen tres tipos de requerimientos.
-Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar.
-Un requerimiento no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
-Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.
Características
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
-Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
-No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
-Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
-Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
-Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
-Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
-Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.
lunes, 22 de marzo de 2010
martes, 16 de marzo de 2010
MODELADO DE DATOS
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un modelo de datos permite describir:
- Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
- Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.
- Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.
TIPOS DE MODELADO DE DATOS
1. Modelos de Datos Conceptuales
Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.
2. Modelos de Datos Lógicos
Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).
3. Modelos de Datos Físicos
Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.
Sublenguajes de un Modelo de Datos
- Un Lenguaje de Definición de Datos o DDL (Data definition Language), orientado a describir de una forma abstracta las estructuras de datos y las restricciones de integridad.
- Un Lenguaje de Manipulación de Datos o DML (Data Manipulation Language), orientado a describir las operaciones de manipulación de los datos.
A la parte del DML orientada a la recuperación de datos, usualmente se le llama Lenguaje de Consulta o QL (Query Language).
Suscribirse a:
Entradas (Atom)