AUTOEVALUACION DE IMPLEMENTACION
ANIMA
Hace 13 años
RECUPERACION QUIZ
¿QUE ES DIAGRAMA DE COLABORACION?
Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales, ... ) y ciclos en la ejecución. Se toma como ejemplo el caso de uso PedirProducto ya descrito como diagrama de secuencia. Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales, ... ) y ciclos en la ejecución. Se toma como ejemplo el caso de uso PedirProducto ya descrito como diagrama de secuencia.
Rqerimiento de informacion
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 requerimientosLas 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 requerimientosLos 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.
¿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 requerimientosLas 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 requerimientosLos 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.
Analisis:Distinción y separación de las partes de un todo hasta llegar a conocer sus principios, elementos, etc.Diseño:Actividad creativa y técnica encaminada a idear objetos útiles y estéticos que puedan llegar a producirse en serie.Sistema:Un sistema es un conjunto de partes o elementos organizadas y relacionadas que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen (salida) información, energía o materia.
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.
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.
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.
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 objetivos
3. Determinación de los requerimientos de información
4. Análisis de las necesidades de sistemas
5. Diseño del sistema recomendado
6. Desarrollo y documentación del software
7. 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 analista
2. La mejora de la comunicación entre analistas y usuarios
3. 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.
Suscribirse a:
Entradas (Atom)
