vtortola.NET Logo
Pensando en asíncrono - BlogEngine.Core.Category

Ya soy MCPD Windows Developer...

por vtortola jueves, 31 de enero de 2008

Pues eso, ya lo tengo... xD Uno sale del examen y no sabe si reir ó llorar... supongo que reir.

Esperemos que para las nuevas certificaciones del .NET Framework 3.5 la cosa cambie...

Actualmente calificado 5.0 por 3 persona(s)

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

MCPD | WinApps

Evaluando el diseño

por vtortola martes, 18 de septiembre de 2007

Antes de empezar a desarrollar una aplicación, es conveniente revisar el diseño lógico para asegurar que es esta completo y correcto. Esto viene a ser evaluar el diseño en los siguientes terminos:

  • Evaluación de ejecución:
    • Rendimiento.
    • Escalabilidad.
    • Disponibilidad.
    • Recuperación.
    • Seguridad.
  • Evaluación de la arquitectura:
    • Mantenibilidad.
    • Extensibilidad.
  • Evaluación de los requerimientos:
    • Casos de uso.

Leer el artículo completo...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

MCPD | WinApps

Creando modelos para desarrolladores

por vtortola domingo, 16 de septiembre de 2007

Siguiendo con el tema del modelado del software en capas, es el turno de crear modelos físicos más precisos para los programadores que han de escribir el código. Los modelos físicos indican como los programadores deberían desarrollar la aplicación.

Un diagrama de componentes indica los componentes ó paquetes de los que se compondrá la aplicación y las dependencias de estos. Un componente es un conjunto de clases relacionadas formando una unidad distribuible, como una DLL, un control ó un Webservice. Los componentes se representan por rectangulos con dos pequeños rectangulos a su izquierda, en el nombre se indica la capa a la que pertenecen separados con dos dobles puntos ('::'). Otros rectangulos mayores que agrupan varios componentes simbolizan un contenedor de distribución llamado nodo, que suele indicar una separación física, como estar en distinto hardware.

Leer el artículo completo...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

MCPD | WinApps

Modelado en capas.

por vtortola jueves, 13 de septiembre de 2007

El modelado en capas de un sistema representa como se planea dividir el código en partes lógicas ó grupos. La abstracción del código en capas permite mejorar, reparar y reemplazar partes de la aplicación de forma sencilla y sin que afecte a las demás. Además provee una representación lógica y clara de la aplicación.

El modelo en capas más comun es el de tres capas, presentación, lógica de negocio y base de datos. El model n-capas extiende este modelo de forma que cualquier capa puede dividirse en subcapas, aportando así mayor claridad.

La capa más alta es en la que se interactua con el usuario, la capa más baja donde los datos son almacenados/recuperados y las capas intermedias son las encargadas de realizar el procesado de datos, el movimiento de estos de la base de datos al usuario y el control del estado de la aplicación.

Leer el artículo completo...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

MCPD | WinApps

Definir objetos y sus relaciones

por vtortola martes, 11 de septiembre de 2007

Un modelo lógico representa los conceptos reales que ha de cubrir la aplicación y permite asegurar que el software cubrirá dichos conceptos.

El modelado de funciones de objetos (Object Role Modeling - ORM) es el proceso de representar conceptos del mundo real que definen ó influyen en el software. Los diagramas ORM incluyen unos objetos primarios llamados entidades, las relaciones entre esas entidades y los atributos que definen esos objetos. Estos diagramas se crean descomponiendo los requerimientos de usuario y los casos de uso en entidades, relaciones y atributos.

Leer el artículo completo...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

MCPD | WinApps

Prototipos y pruebas de concepto

por vtortola lunes, 10 de septiembre de 2007

Después de evaluar los requerimientos y el diseño previo de una aplicación, el siguiente paso es realizar un prototipo.

Un prototipo tiene el propósito de cubrir los huecos  que quedan entre la teoría y la práctica, es decir, entre los requerimientos junto el diseño y la implementación real.

Las maquetas se usan para proponer y validar interfaces de usuario y la navegación por el sistema. Se pueden crear desde con papel y lapiz a herramientas como Microsoft Visio. También se conocen como prototipos horizontales y verifican el cumplimiento de los requerimientos y casos de uso a través de una serie de formularios clave.

Los prototipos de prueba de concepto prueban la arquitectura propuesta con todas sus capas, se conoce también como arquitectura de referencia. Se deben crear con las tecnologías propuestas ó aproximadas. También se conocen como prototipos verticales (por lo de que influyen todas las capas).

Leer el artículo completo...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

MCPD | WinApps

Requerimientos y diseño de un proyecto.

por vtortola lunes, 10 de septiembre de 2007

Los requerimientos de un proyecto deberían ser definidos desde múltiples perspectivas:  

  • Requerimientos del negocio: Definidos por los gerentes y comerciales. Exponen que puntos se consideran importantes para el éxito del proyecto.
  • Requerimientos de usuario: Definidos por los futuros usuarios. Exponen que tareas deben ser capaces de realizar con la aplicación para cumplir los objetivos de su trabajo.
  • Requerimientos funcionales ó especificaciones funcionales: Definidos por el lider técnico ó el arquitecto. Definen las caracteristicas que se deben desarrollar para cumplir los requerimientos anteriores. Son definidos mejor a través de herramientas de modelado, sin tener que hacer por un lado un documento de requerimientos y por otro el modelado de dichos requerimientos.
  • Requerimientos de calidad de servicio: Definen requerimientos sobre el rendimiento, escalabilidad y estandares a cumplir, no sobre aspectos funcionales ó problemas específicos.

Unos requerimientos bien expuestos no deberian presentar ambiguedad. No deben exponer metas a conseguir, si no cosas que se pueden hacer y estimar. No deben dar lugar a malas interpretaciones.

Leer el artículo completo...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

MCPD | WinApps

Powered by BlogEngine.NET 1.1.1.8
This theme is a variation of Mads Kristensen by Valeriano Tórtola

Valeriano Tórtola

Personal Ver perfil
E-mail Enviar correo
LinkedIn LinkedIn
Fotos Fotos
MCPD

Publicidad

Posts recientes

Disclaimer

Las opiniones mostradas aqui son mis opniones y no representan el punto de vista de mi empresa en ninguna forma.

Creative Commons License

Esta obra está bajo una licencia de Creative Commons

Locations of visitors to this page

© Copyright 2008

Sign in

Calendario

<<  octubre 2008  >>
lumamijuvido
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

Ver en calendario extendido