Diagramas del proyecto

Respuesta De La Autoevaluación (Codificación)

diagrama del ejercicio

Definicion de casos de uso

Representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de
la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
-Actor.
-Casos de Uso.
-Relaciones de Uso, Herencia y Comunicación.

ACTOR
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar
el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en
particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con
respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

CASOS DE USO

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un
actor o bien desde la invocación desde otro caso de uso.

RELACIONES

ASOCIACIÓN:
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de
uso). Dicha relación se denota con una flecha simple.

DEPENDENCIA:
Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia
(se crea). Dicha relación se denota con una flecha punteada.

GENERALIZACIÓN:
Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que
puede ser de Uso o de Herencia.

Casos de uso

Requerimientos

Definicion de requerimientos
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan muchos participantes del proyecto para:
*Planear el proyecto y los recursos que se usarán en él. Los lideres de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.
*Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se esta tratando de alinearse a cierta norma oficial o estándar.
*Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.
*Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.

Mapa conceptual de UML

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 UML
Obtenido de "http://es.wikipedia.org/wiki/Lenguaje_de_modelado_de_objetos"

mapa de recoleccion de datos

Analisis Y Diseño De Software

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.

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.

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.

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.

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 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.

Formato de blog y proyecto

Mapa Conceptual de TGS