Mostrando entradas con la etiqueta Análisis de Sistemas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Análisis de Sistemas. Mostrar todas las entradas

viernes, 25 de marzo de 2016



Enfoque al cliente, que da como resultado el cumplimiento de los requisitos de los clientes y el esforzarse por excederlos.

La ISO 9000 se basa en los 8 principios de gestión

Liderazgo, que apunta a crear un ambiente interno en el cual las personas estén totalmente involucradas.

Participación del personal, que es la esencia de una organización.

Enfoque basado en procesos, que da como resultado la mejora de la eficiencia para obtener los resultados deseados.

Enfoque de sistema para la gestión, que conduce a la mejora de la eficiencia y la eficacia por medio de la identificación, comprensión y gestión de procesos interrelacionados

Mejora continua, que se convierte en un objetivo permanente de la organización.

Enfoque basado en hechos para la toma de decisiones, basado en el análisis de datos e información, y

Relaciones mutuamente beneficiosas con el proveedor, basado en la comprensión de su interdependencia.

Para el manejo de una organización la ISO 9000 estimula la adopción del enfoque basado en procesos. Para el modelo de procesos revisado en la ISO 9000 se consideran cinco áreas principales:

  • Sistema de gestión de la calidad
  • Responsabilidad de la alta dirección 
  • Gestión de recursos 
  • Realización del producto 
  • Medición, análisis y mejora 

El modelo de proceso usado en las normas es completamente compatible con el bien conocido ciclo de: PLANEAR, HACER, VERIFICAR, ACTUAR

PRINCIPIOS DE LA GESTIÓN DE LA CALIDAD

By: serintec on: 19:56

lunes, 7 de marzo de 2016


.

¿Cuál es la diferencia entre Arquitectura de Software y Diseño de Software?

La arquitectura del software conlleva modularidad, es decir que divide el software en componentes identificables y tratables por separado, denominados módulos, que están integrados para satisfacer los requisitos del programa.

La arquitectura es la estructura jerárquica de los componentes del programa (módulos), la manera de interactuar de estos componentes, y la estructura de los datos, usados por estos componentes.

El diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema de ingeniería.


El diseño del software es un proceso iterativo mediante el cual los requisitos se traducen en un plano para desarrollar el software

1.       ¿Cuál es el origen de UML y en que métodos está basado?

UML es una consolidación de muchas de las notaciones y conceptos más usados orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares

UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 5 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1

UML se construyó sobre la semántica y notación de Booch, OMT, OOSE, y otras metodologías líderes.

CICLO DE VIDA DEL SOFTWARE


Nombre del ciclo de vida
Ventajas
Desventajas
Modelo de Ciclo de Vida de Cascada
-Etapas y actividades están bien definidas para facilitar la compresión.

-Estructura clara
-Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del diagrama.

-El cliente debe tener paciencia; hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa.
Modelo de Entregas Incrementales
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

- No es útil para productos basados en ROM

-El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

- Requiere de mucha planeación, tanto administrativa como técnica.

- Requiere de metas claras para conocer el estado del proyecto.

Modelo de Ciclo de Vida Evolutivo
· Usa realimentación del uso de las versiones anteriores

· Puede ser usado en un ambiente cambiante
-La primera iteración puede plantear los mismos problemas que en un modelo lineal secuencial
Entregas incrementales con prototipos
-Versión operativa cas desde el inicio
-Alta integración del usuario con el proceso de desarrollo

-  El sistema puede crecer desmedidamente
-       Se confunde el producto final con el prototipo
Espiral
-El cliente evalúa el trabajo en cada ciclo
-Se llega al sistema final muy rápido
-Aumento de costos.
-Es un modelo complicado de llevar a cabo porque exige una gestión concienzuda, atenta y unos conocimientos profundos

UML - DISEÑO DE SOFTWARE

By: serintec on: 5:11

martes, 16 de febrero de 2016

       1. Base de Datos

Se puede definir como una “Colección o depósito de datos integrados, almacenados en soporte secundario (no volátil) y con redundancia controlada. Los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de ellos, y su definición (estructura de la base de datos) única y almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir captar las interrelaciones y restricciones existentes en el mundo real. Los procedimientos de actualización y recuperación, comunes y bien determinados, facilitarán la seguridad del conjunto de los datos” (Piattini, 2006).
El contenido de una base de datos engloba a la información concerniente de una organización, de tal manera que los datos estén disponibles para los usuarios en tiempo real y sean compartidos con usuarios concurrentes, una finalidad de la base de datos es eliminar la redundancia o al menos minimizarla. Los tres componentes principales de un sistema de base de datos son el hardware, el software DBMS y los datos a manejar, así como el personal encargado del manejo del sistema.

1.1.  Arquitectura de las Bases de Datos

Un sistema de base de datos se encuentra dividido en módulos cada uno de los cuales controla una parte de la responsabilidad total de sistema. En la mayoría de los casos, el sistema operativo proporciona únicamente los servicios más básicos y el sistema de la base de datos debe partir de esa base y controlar además el manejo correcto de los datos. El diseño de un sistema de base de datos debe incluir la interfaz entre el sistema de base de datos y el sistema operativo. Los componentes funcionales de un sistema de base de datos, son los siguientes:

Gestor de Archivos: Gestiona la asignación de espacio en la memoria del disco y de las estructuras de datos usadas para representar la información. 

Manejador de Base de Datos: Sirve de interfaz entre los datos y los programas de aplicación.

Procesador de Consultas: Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Además convierte la solicitud del usuario en una forma más eficiente.
Compilador de DDL: Convierte las proposiciones DDL en un conjunto de tablas que contienen meta datos, estas se almacenan en el diccionario de datos.

Archivo de Datos: En él se encuentran almacenados físicamente los datos de una organización.
Diccionario de Datos: Contiene la información referente a la estructura de la base de datos.
Índices: Permiten un rápido acceso a registros que contienen valores específicos. Una forma gráfica de representar los componentes antes mencionados y la relación que existe entre ellos


1.2. Bases de datos relacionales

Las bases de datos relacionales (Relational Data Base) proporcionan estructuras de datos, independientemente del tipo de aplicaciones que acceden a éstos o de su estructura (Rodríguez Penin, Sistemas SCADA, 2nd ed. Marcombo, 2007).


Una base de datos relacional es un conjunto de tablas de datos que contienen campos. Éstos sirven como nexos de unión a través de los cuales se pueden establecer múltiples combinaciones. Las combinaciones posibles prácticamente son ilimitadas, todo depende de la configuración del método de búsqueda (consulta, Query), o el tipo de datos que se requiera consultar. Este tipo de organización permite el uso de la arquitectura Cliente/Servidor y con ello se simplifican la administración de los datos y las aplicaciones que los usan, se disminuye el espacio de almacenamiento y se reducen los problemas asociados a las bases de datos redundantes. Los usuarios y las aplicaciones pueden acceder a los datos de forma rápida y sencilla, ya que pueden personalizar sus propias consultas y obtener los datos de acuerdo a sus necesidades.

Base de Datos, Arquitectura y Bases de datos relacionales

By: serintec on: 8:06

viernes, 4 de septiembre de 2015

Diagramas Causales 

Por alguna razón, a todos nos gusta armar un rompecabezas, nos gusta ver surgir la imagen de la totalidad. Para apreciar la belleza de una persona, una flor o un poema, debemos ver la totalidad. Es interesante señalar que las palabras inglesas whole (“entero”, “totalidad”) y health (“salud”) derivan de la misma raíz (el inglés antiguo hal, presente en la palabra hale, “sano”). No es sorprendente que la poca salud de nuestro mundo actual guarde una proporción directa con nuestra incapacidad para verlo como una totalidad.  

Peter Senge Quinta Disciplina 

Como ya se ha comentado en los temas previos, los modelos juegan un rol importante en el estudio de una realidad determinada, dado que los mismos representan las características esenciales que se abstraen de ella.
En este sentido, es importante que el analista disponga de un lenguaje adecuado para representar en un modelo los elementos esenciales de la realidad en estudio.
Es así que los diagramas causales constituyen ese lenguaje adecuado que permite al analista contar con los elementos adecuados para realizar la descripción de una realidad determinada vista como un sistema.
Los diagramas causales nos permiten representar aspectos estructurales de una realidad vista como un sistema; entendiéndose como estructura de un sistema los elementos que lo componen así como las relaciones entre los mismos, tal como se muestra luego:


¿Qué representa un diagrama causal?
Básicamente, un diagrama causal representa la estructura de un sistema.
La estructura de un sistema hace referencia a los elementos componentes y las relaciones existentes entre los mismos.
En el ejemplo mostrado, se han identificado cuatro elementos componentes de la estructura que se representan como variables, así como también las relaciones que se dan entre ellas.

¿Qué elementos contiene un diagrama causal?
Los diagramas causales contienen:
Variables Cada uno de los elementos componentes de un diagrama causal constituye componentes variables que forman parte del sistema en estudio y que como resultado de la dinámica del sistema presentan patrones de comportamiento particulares.

Ejemplos:  
Ventas  
Producción  
Ingresos  
Utilidades  
Vendedores  
Publicidad  
Productividad

Los ejemplos mostrados se caracterizan por constituyen elementos que cambian en el tiempo como resultado de la dinámica en una empresa

Se debe tener en consideración que el comportamiento adoptado por cada una de las variables obedece a su interacción en el sistema con el resto de elementos.


Tal es el caso de la variable “Ventas”, cuyo comportamiento mostrado de manera gráfica en el cuadro, obedece al resultado de la sinergia entre esta variable y el resto de elementos. 

Relaciones  
La estructura de un sistema está representada por variables y relaciones, siendo éstas las que establecen las líneas de causa y efecto entre los diferentes elementos variables.  
Tal es el caso, según el ejemplo, de la variable “Vendedores” que afecta a la variable “Ventas”, por lo cual existe una línea de causalidad entre ambas  y cuya dirección va según lo mostrado en el gráfico en concordancia con la relación de causa y efecto. 


Las relaciones de causa y efecto pueden ser de dos tipos:  
- Relaciones directas - Relaciones inversas  
Si bien es cierto que las líneas en un diagrama causal expresan las relaciones de causa y efectos entre los elementos variables de un sistema, se ha hace necesario tener en consideración la forma sobre cómo afecta una variable a otra.   

El signo + mostrado en la línea de causalidad expresa un relación causal directa, la cual hace referencia para el caso mostrado que la variable “Vendedores” afecta directamente a la variable “Ventas”, lo cual implica que ambos elementos varían en la misma dirección.   


Diagramas Causales

By: serintec on: 9:05

lunes, 3 de agosto de 2015



1) Identificación de problemas, oportunidades y objetivos:
En esta primera fase el analista se ocupa de identificar los problemas, oportunidades y objetivos, esta etapa es crítica para el éxito del resto del proyecto.

2) Determinación de los requerimientos de información:
En esta fase el analista se encarga de determinar los requerimientos de información de un negocio se encuentran métodos interactivos como: las entrevistas, los muestreos, investigación de datos impresos, entre otros.


3) Análisis de las necesidades de sistemas:
En esta fase el analista cuenta con herramientas y técnicas especiales con el cual el analista determina el requerimiento.


4) Diseño del sistema recomendado:
En esta fase el analista utiliza la información recopilada anteriormente para el diseño lógico del sistema de información.

5) Desarrollo y documentación del software:
El analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario.


6) Pruebas y mantenimiento de sistema:
Antes de poner en funcionamiento el sistema es necesario probarlo. Es mucho menos costoso encontrar los problemas antes de que el sistema se entregue al usuario.


7) Implementación y evaluación del sistema:
En esta última fase se capacita al usuario en el manejo del sistema.

Siete fases del ciclo de vida del desarrollo de sistemas (SDLC).

By: serintec on: 14:22



Administración estratégica: Los gerentes estratégicos voltean hacia afuera de la organización para visualizar el futuro, tomando decisiones que conducirán a los gerentes de nivel medio y de operaciones en los meses y años venideros.

Planeación y control administrativo: Este sector toma decisiones de planeación y control a corto plazo respecto a cómo asignar de la mejor manera, los recursos para cumplir los objetivos de la organización. Sus decisiones van desde la elaboración de pronósticos sobre requerimientos futuros de recursos hasta la solución de problemas de los empleados que pongan en peligro la productividad. Podria decirse que las decisiones de este sector reside parcialmente en el ámbito de operaciones y parcialmente en el ámbito estratégico, con fluctuaciones constantes.

Control de Operaciones: Es la que se dedica a aplicar reglas predeterminadas que producen resultados predecibles, toman decisiones que influyen en la implementación de la calendarización del trabajo, el control de inventarios, el embarque, la recepción de materiales y el control de procesos como la producción. Así mismo supervisan los detalles de las operaciones de la organización.

Tres niveles principales de administración horizontal de las Organizaciones

By: serintec on: 14:10

martes, 14 de julio de 2015

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares. 

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan.





Hay varias metodologías existentes; entre las más populares se incluyen las siguientes:    

•  Catalysis: Un método orientado a objetos que fusiona mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas específicas para modelar componentes distribuidos.  

•  Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson.  

•  Shlaer/Mellor: El método para diseñar sistemas de tiempo real, puesto en marcha por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos, modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor countinúan actualizando su método continuamente (la actualización más reciente es el OOA96 report), y recientemente publicaron una guía sobre cómo usar la notación UML con Shlaer/Mellor.  

•  Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un método de diseño orientado a objetos estándar.  

•  OMT : La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseño y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un método que propone análisis y diseño ’iterative’, más centrado en el lado del análisis.  

•  Booch: Parecido al OMT, y también muy popular, la primera y segunda edición de "Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, With Applications), detallan un método ofreciendo también diseño y análisis ’iterative’, centrándoso en el lado del diseño. 

UML - Lenguaje Unificado de Modelado

By: serintec on: 20:19

 
Copyright © tics | Designed by Templateism.com | WPResearcher.com