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.