Arquitectura cliente - servidor 

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes.

Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

Arquitectura de software

El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo.

Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.

La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema.

Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estatura de un sistema mostrando sus clases y atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejara que el sistema, y los elementos se encargaran del funcionamiento y la relación entre uno y otro.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clases: atributos, métodos, visibilidad.

Relaciones: herencia, composición, agregación, asociación  y uso

Atributos:

Los atributos y características  de una clase pueden ser de tres tipos,  los que definen el grado de comunicación y visibilidad de ellos con el entorno, estas son:

Public: indica que el atributo será visible tanto dentro  como fuera de la clase, es decir, que es accesible desde todos lados.

Private: indica que el atributo solo será accesible desde dentro de la clase  (solo sus métodos pueden accesar).

Protected: indica que el atributo no será accesible desde  fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven(herencia).

Relaciones entre las clases:

Bueno ya definido el concepto de clase,  es necesario explicar  como se pueden interrelacionar dos o mas clases (cada uno con características y objetivos diferentes).

Antes es necesario el concepto de cardinalidad de las relaciones: En UML la cardinalidad de las relaciones indica el grado y el nivel  de dependencia se anotan en cada extremo de la relación y  estas pueden ser: 

Uno a muchos: 1..*(n..1).

 0 o muchos:0..(0..n).

Numero fijo: m (m denota el numero). 

Agregación: Para modelar objetos completos, no bastan los tipos de datos básicos que proveen de lenguajes: enteros, reales y secuencia de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación tenemos do posibilidade.

Por valor: es un tipo de relación estática, en donde el tiempo  de vida del objeto esta condicionado por  el  tiempo de vida del que lo incluye. este tipo de relación es comúnmente  llamada  composición  (el objeto base se construye a partir de objeto incluido, es decir, “parte/todo”).

 Por referencia: es un tipo de relación dinámica, en donde el tiempo de vida del objeto es independiente del que lo incluye.

Agregación: (el objeto base  utiliza al incluido por funcionamiento).

DIAGRAMA DE SECUENCIA

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de

caso de uso permite el modelado de una vista ’business’ del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar

el escenario, y mensajes pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una Un estudio a fondo de UML secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.

CERTIFICADO MICROSOFT

¿Qué son las certificaciones oficiales de Microsoft?

Consisten en exámenes exigentes orientados a las necesidades reales de los diversos puestos de trabajo que te certifican de forma oficial para casi cualquier área de especialización TI dentro de las tecnologías Microsoft, tanto para desarrolladores como para profesionales de sistemas. Toda la información sobre las certificaciones de desarrollo en nuestra página específica de certificación.


¿Cuáles son los exámenes que tengo que aprobar para conseguir una certificación?
Cada especialidad exige el aprobado de unos exámenes concretos. En esta página puedes ver toda la información sobre los exámenes que tienes que aprobar si quieres ser MCTS y MCPD en el área de desarrollo.


¿Qué es un MCTS?
MCTS es el acrónimo de Microsoft Certified Technology Specialist. Puedes ser MCTS en cualquiera de estas áreas:

Windows Applications (examen 70-511)
Service Communication Applications (examen 70-513)
Web Applications (examen 70-515)
Data Access (examen 70-516)
Silverlight (examen 70-506)


¿Qué es un MCPD?
MCPD es el acrónimo de Microsoft Certified Professional Developer. Puedes ser MCPD en cualquiera de estas áreas:

Windows Developer (examen 70-518)
Web Developer (examen 70-519)
Windows Azure Platform (examen 70-583)
Para ser MCPD primero has de aprobar los exámenes que te certifiquen como MCTS y luego aprobar los propios para ser Professional Developer.

Diagrama de Casos de Uso

Otras de las formas mas rapida y sencilla de aprender algo es viendo por videos, por si aun no entienden muy bien el tema dejo dos vídeos en donde explican los diagramas de casos de uso utilizando el programa Rational Software. otro video de ayuda para compartir :)

Herramientas UML

El lenguaje Unificado de Modelado, son un conjunto de herramientas gráficas que permiten: visualizar, especificar, construir y documentar un sistema de información. UML ofrece un estándar para el modelado de un sistema con tres características fundamentales:

- Es gráfico, todas las herramientas tienen su propia representación gráfica, con sus propias reglas de uso, lo que estandariza el lenguaje de representación e interpretación, tanto para los usuarios como para el equipo de desarrollo, y algo muy fundamental - evita la ambiguedad del lenguaje natural.

- Es particionable, UML aborda el problema en fases o etapas y para cada una dispone de las herramientas adecuadas. Permite modelar el sistema desde varias perspectivas, por componentes o subsistemas, simplificando la complejidad de un proyecto en unidades más fáciles de gestionar.

- De lo general a lo específico, es decir nos permite ver el proyecto desde una concepción global y general, y gradualmente adentrarnos en los detalles del proyecto, sin perder el control de la correspondencia de un modelo con otro.

De las herramientas más usuales que hacen a UML, tenemos:

a. Diagrama de Casos de Uso
b. Diagrama de Clases
c. Diagrama de Secuencia
d. Diagrama de Colaboración
e. Diagrama de Estados
f. Diagrama de Actividades
g. Diagrama de Implementación
h. Diagrama de Componentes

Algo que es importante señalar, UML no es una metodología de análisis y diseño de sistemas de información, son un conjunto de herramientas que ayudan al modelado de sistemas.

Para las personas que le llaman mucho la atención aprender como hacer diagramas de clases, pongo un vídeo donde explica como hacerlo.

caso de uso

Casos de Uso (Use Case)

El diagrama 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 
• caso de uso
• relaciones de uso, herencia y comunicación.

Elementos

• 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.
• Caso 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 o Instanciación 
    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 (<<uses>>) o deHerencia (<<extends>>).
    Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
    extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
    uses: Se recomienda utilizar cuando se tiene un conjunto de características que
    son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
    
    De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

NOTA: Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

El ciclo de vida de un sistema de información está ligado al ciclo de vida del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de vida de desarrollo del software. 

Las etapas típicas del ciclo de vida de desarrollo del software son: planificación, recolección y análisis de los requisitos, diseño (incluyendo el diseño de la base de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. El método del ciclo de vida para el desarrollo de sistemas consta de 6 etapas:

1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. 

3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. 

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

UML

• quinto blog

¿QUE ES UML?

Es El Lenguaje Unificado de Modelad prescribe 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. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

• Mejores tiempos totales de desarrollo (de 50 % o más).

• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.

• Establecer conceptos y artefactos ejecutables.

• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

• Mejor soporte a la planeación y al control de proyectos.

• Alta reutilización y minimización de costos.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

Diagramas de Casos de Uso para modelar los procesos 'business'.

Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

Diagramas de Colaboración para modelar interacciones entre objetos.

Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.

Diagramas de Clases para modelar la estructura estática de las clases en el sistema.

Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.

Diagramas de Componentes para modelar componentes.

Diagramas de Implementación para modelar la distribución del sistema.

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.

En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. 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 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. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
• Establecer conceptos y artefactos ejecutables.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.

TÉCNICAS PARA DEFINIR LOS REQUERIMIENTOS

cuarto blog

La importancia de aplicar correctamente la tecnicas de recoleccion de informacion es que son vitales y ademas de esto facilitan la busqueda y definicion de los requerimientos necesarios de un sistema de informacion .Aplicando estas tecnicas,podemos ir mas alla y asi detectar los requerimientos necesarios,las técnicas como el chequeo,la observación, el método delfil , la sesión de grupo entrevista,muestreo documental son técnicas que cada una de ellas aplican métodos diferentes para identificar requerimientos diferentes. Por esta razón es muy importante que estas técnicas de recolección de información  sean aplicadas de la manera mas correcta posible para así concluir con buenos requerimientos para la creación del software.

Dentro de los objetivos de esta fase se encuentran el entender el dominio de la aplicación, las necesidades del negocio, las restricciones del sistema, a los participantes del sistema y al problema en si, para entender de manera inicial lo que se debe desarrollar.

Algunas de las técnicas y herramientas más importantes para llevar a cabo la recolección de requerimientos son:

Entrevistas: La entrevista es un método para descubrir hechos y opiniones que tienen los posibles usuarios y otros participantes dentro del sistema que se está desarrollando.

Observación y análisis social: Este método es muy útil cuando se busca estudiar las actividades y procesos que se están llevando a cabo en una organización en el momento. La observación permite a los investigadores observar lo que los usuarios hacen actualmente en un determinado contexto.

Lluvia de Ideas: Las lluvias de ideas son sesiones donde todos los participantes brindan sus ideas para obtener una solución a una problemática.

entre otros.

SOFTWARE COMO PRODUCTO.

• TERCER BLOG

Para comenzar, según lo que e investigado a cerca del software con la recopilación  de mis conocimientos e logrado destacar que  el software como producto es la unión de componentes lógicos que permiten al usuario realizar tareas especificas, con la ayuda de componentes. físicos llamados hardware. Si reside dentro de un teléfono celular u opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo información que puede ser tan simple como un solo bit, o tan complejo como una presentación en multimedia. Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes) y la creación y control de otros programas (herramientas de software y otros). 

Considerando este punto de vista  de lo anterior, el software como producto  va más allá de los programas de computación en sus distintos estados: código fuente, binario o ejecutable; también su documentación, los datos a procesar e incluso la información de usuario forman parte del software: es decir, abarca todo lo intangible, todo lo 'no físico' relacionado.

NOTA: gracias por su atención acepto criticas.

Roles del Analista de sistemas

El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente producción de información, con el propósito de mejorar los procesos de una organización. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de sistemas de información computarizados. Esta definición pone énfasis en un enfoque sistemático y metódico para analizar en consecuencia mejorar lo que sucede en el contexto específico creado por un negocio.

Mi definición de analista de sistemas es amplia. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El analista desempeña diversos roles, en ocasiones varios de ellos al mismo tiempo. Los cuatro roles principales del analista de sistemas son el de consultor, especialista de apoyo, agente de cambio y lenguaje de programación.

AUDITORES DE SISTEMAS

• NOTA:

EN MI PUNTO DE VISTA PARA COMENZAR TENEMOS QUE PREGUNTARNOS ¿QUE ES AUDITORIA DE SISTEMAS? COMO BIEN SABEMOS LA AUDITORIA DE SISTEMAS DE INFORMACIÓN SE DEFINE COMO CUALQUIER AUDITORIA QUE ABARCA LA REVISIÓN Y EVALUACIÓN DE TODOS LOS ASPECTOS (O DE CUALQUIER PORCIÓN DE ELLOS) DE LOS SISTEMAS AUTOMÁTICOS DE PROCESAMIENTO DE LA INFORMACIÓN INCLUIDOS LOS PROCEDIMIENTOS NO AUTOMÁTICOS RELACIONADOS CON ELLOS Y LAS INTERFACES CORRESPONDIENTES. 

¿QUE ES AUDITORIA DE SISTEMAS?

La auditoria en informática es la revisión y la evaluación de los controles, sistemas, procedimientos de informática; de los equipos de cómputo, su utilización, eficiencia y seguridad, de la organización que participan en el procesamiento de la información, a fin de que por medio del señalamiento de cursos alternativos se logre una utilización más eficiente y segura de la información que servirá para una adecuada toma de decisiones.

La auditoria en informática deberá comprender no sólo la evaluación de los equipos de cómputo, de un sistema o procedimiento específico, sino que además habrá de evaluar los sistemas de información en general desde sus entradas, procedimientos, controles, archivos, seguridad y obtención de información.

La auditoria en informática es de vital importancia para el buen desempeño de los sistemas de información, ya que proporciona los controles necesarios para que los sistemas sean confiables y con un buen nivel de seguridad. Además debe evaluar todo (informática, organización de centros de información, hardware y software).