Conversor online de VB a C#

Cuantas veces dentro de un proyecto o simple aplicativo hemos querido rapidamente obtener el codigo equivalente en VB o C# de todo o parte del codigo fuente para reciclarlo en otros proyectos.

Pues este aplicativo convierte rapidamente todo el codigo que se le solicite.
Disponible en el Toolbox del sitio developerFusion, pruebalo Aqui

Esta basado en el proyecto #develop editor, alternativa free open source al Visual Studio .NET de Microsoft; ademas de soportar sintaxis de para NET 3.5 y NET2.0 .

Creando un reporte con Crystal Report desde una Aplicacion ASP.NET

Arquitecturas empresariales de soluciones .NET

Que es una Arquitectura de Software?

La arquitectura es el esqueleto de un sistema, el conjunto de pilares que soportaran la construcción, para eso el arquitecto debe ser multifacético, conocer sobre requerimientos, diseño de sistemas, garantizar que la implementación satisfaga las expectativas y asegurarse globalmente que los usuarios obtengan lo que realmente necesitan, el cual no es necesariamente lo que inicialmente aceptaron y pagaron.

La arquitectura de software tiene precondiciones ( principios de diseño )

El rol de un arquitecto es primeramente responsable por el conocimiento de requerimiento, diseño del sistema, y comunicación del diseño al equipo de desarrollo.

La comunicación esta a menudo basada en bosquejos UML.El arquitecto aplica primero principios generales de ingeniería de software, después principios de diseño orientado a objetos, para romper el sistema dentro de pequeñas piezas en un intento de separar que es arquitectura y que no. Uno de los propósitos del diseño orientado a objetos es hacer tu código fácil de mantener y desarrollar- y también fácil de leer y entender.

El arquitecto conoce el mantenimiento, seguridad y las pruebas necesarias a ser incluidas al sistema desde el comienzo.

PRINCIPIOS

Conocerás la perfección del diseño, no cuando no tengas algo que agregar, sino cuando no tengas nada que quitar.

Antoine de Saint-Exupery

El propósito de la Ingeniería de Software, es controlar la complejidad, no crearla.

Dr Pamela Zave

¿Qué es una arquitectura de Software, en todo caso?

Herman Melville, el autor inolvidable de Moby Dick, alguna vez dijo que los hombres piensan que articulando palabras duras pueden entender cosas duras.

En software, la “dura” palabra Arquitectura fue introducida originalmente en este campo para simplificar la transmisión y la comprensión de una clave y ” dura” guía de consulta.

La guía de consulta era ésta: Más (mucho) cuidado sobre el diseño de sistemas informáticos que comprendías en el pasado; cuidado con esto al punto de dirigir el desarrollo de un sistema informático de forma similar a dirigir el desarrollo de un edificio.

Es una cosa dura de hacer y probablemente más allá de las capacidades de muchos Desarrolladores. Pero daremos un intento. Intentemos aclarar que es una “arquitectura de los software” o, por lo menos, qué pensamos que sea.


Definición de sistema desde un punto de vista estándar


Un sistema informático se entiende universalmente como una colección de componentes compuestos e integrados para lograr un conjunto específico de funciones.
Un sistema vive en un entorno; y este entorno influye al diseño del sistema conduciendo a algunas decisiones de desarrollo y operacionales. Un sistema existe para solucionar un problema y para alcanzar su misión completamente respecto a lo concerniente de los "Stakeholders". Todo lo concerniente de los "Stakeholders" incluyen requisitos funcionales y no funcionales así como aspectos del sistema tales como seguridad, posibilidad de prueba, funcionamiento, confiabilidad, y extensibilidad.
Aunque prevea al sistema como una composición de componentes interconectados, una arquitectura también establece algunos puntos que son duros de modificarse más adelante.
De manera que, la expresión del desarrollo de software en términos de arquitectura concluye en la generacion de algunas decisiones importantes que afectan el ciclo vital del desarrollo y, en última instancia, a la calidad del sistema resultante.

El cuadro 1 ilustra los lazos entre el sistema, la configuración, y los "Stakeholders" según lo identificado por el estándar 1471 de ANSI/IEEE. El contenido del cuadro 1-1 es realmente una adaptación de una de las figuras en el documento.

Procesos del testing de un software

El Proceso de Testing

El proceso para testear bloques de la aplicación se muestran abajo. Los pasos listados deberan ser utilizados independientemente de la metodologia de testing.

Entrada de información (Input's)

La entrada de información siguiente se requiere para testear una aplicación:

• Especificaciones funcionales
• Requerimientos
• Objetivos de funcionamiento
• Escenarios de despliegue

Pasos

El cuadro muestra los pasos en el proceso de testing para una aplicación.

• Crear los planes de prueba.

Crear la documentación del plan de prueba con una lista prioritaria de Casos de Prueba y de detalles de la ejecución.

• Revizar el diseño.

Revisar el diseño para asegurarse de que trata todos los escenarios de despliegue y los requerimientos. También asegurar la adherencia a las mejores practicas para el funcionamiento, seguridad, globalización, manteniabilidad, y así sucesivamente.

• Revisar la implementacion.

Revizar el código para asegurarse de que las mejores prácticas están seguidas.

• Realizar la prueba de la caja negra.

Probar el código desde una perspectiva de usuario final ejecutando todos los escenarios.

• Realizar la prueba de la caja blanca.

Analizar el código para escenarios fallidos y simularlos pasando datos inválidos usando el test harnesses customizado.


Paso 1: Crear los planes de prueba

Los planes de prueba documentan los Casos de Prueba que usted utilizará para testear la aplicación. Los casos de prueba cubren todos los aspectos de la prueba, incluyendo la revisión de diseño, la revisión de código, el profiling, la prueba del despliegue, y la prueba de carga. Los planes de prueba ayudan a asegurarse de que usted pruebe todas las características y escenarios de uso de una aplicación.

La documentación del plan de prueba consiste en dos documentos:

El documento del plan de prueba detallado (DTP) .

El documento detallado del plan de prueba enumera los casos de prueba en una orden prioritaria (Alta, media, y baja). Las descripciones del caso de prueba en este documento resumen abreviadamente los escenarios de uso y las características que se testearan. Para cada caso de prueba, usted asigna un nivel de prioridad basado en la importancia del caso y su impacto total del caso en las metas a cumplir, planeadas estas por los objetivos y los requisitos deseados.

El documento de casos de prueba detallado (DTC).

El documento de casos de prueba detallados asocia al documento detallado del plan de prueba. Este documento describe los pasos que el usuario debe realizar para ejecutar cada caso de prueba que este listao en el documento DTP. También enumera los datos que se requiriran para la prueba y describe los resultados previstos de esta prueba.

Se actualizaran los documentos DTP y DTC a través del ciclo de vida del desarrollo. Por ejemplo, usted debera actualizar estos documentos si las especificaciones funcionales o los requisitos cambian, o si usted tiene una información (input) adicional. Usted también los actualizara si agrega más adelante en el ciclo del desarrollo casos de prueba o si modifica la prioridad de los casos de prueba existentes a razon de escenarios de usos o pruebas funcionales adicionales .