Bueno la verdad el tema de Control de Calidad del software no se lo ve mucho (sino es nada) en la Universidad. Pero en el mundo real los testers (QE) son parte importante del desarrollo para asegurar la calidad de un producto de software.

Ahora bien que tiene que ver un developer con un tester, pues mucho. La verdad que muchas veces tienes que sermuy bueno para detectar errores (especialmente los rebuscados), entonces para ser un buen developer, previamente deberias conocer muchas cosas de las que verifican los testers en tus programas, asi te adelantas y envias a control de calidad la menor cantidad de errores, de tal forma que se tenga un producto de mejor calidad.

Sin embargo ya lo deciamos con mi compañeros desde primer semestre, un software nunca va a terminarse, y  siempre, pero siempre tiende a tener errores, nunca un developer puede ser perfecto. Algo que me llamo mucho la atención es lo que menciona Manfred Ratzmann, Clinton de Young [1] , en cuanto al proceso que debe seguir el control de calidad: planificacion de testeo, diseño, especificación, procesos, ejecucion, reportes, regresion y bueno ahi regresa al developer, o sea el ser un buen tester tampoco es tarea tan sencilla, aunque supongo que sigue siendo más sencilla que la de un developer, quizás cuando pruebe ser tester o alguien de automatización :).

Algunos puntos para las empresas que deben considerar para el control de calidad de sus propios productos, los desarrollados en la misma empresa:

1. Ese software no debe ser testeado dentro la misma empresa.

2. La comunicación entre análisis de negocio, developers y testeo es sumamente importante, de vida o muerte.

3. Un desarrollador no es el indicado para asegurar que su producto tiene calidad. (Asi de duro :) )

4. No se debe testear aquello que no ha sido implementado.

5. Donde se encontraron errores, es más probable que luego existan mas.

 

 De donde saco el punto 4 que no parece tener sentido, como voy a probar algo que no ha sido implementado ?. Bueno esto puede suceder por la falta de comunicación, sucede en la vida real que, yo developer tengo un documento de especificación de requerimientos, analizo, diseño, implemento, y hago la entrega de mi programa a los de control de calidad. Sucede que cuando estoy haciendo la entrega a control de calidad, análisis de negocio me dice: "Bueno hace unos días surgieron cambios en los requerimientos aprobados por el cliente" (ese documento Control de Calidad ya lo tiene desde hace "algunos dias"). Entonces supondra que el programa que entregue contempla dichos cambios, entonces sucede que, control de calidad muy enojado dice "El programa no sirve" (critica nada constructiva), entonces todos se enojan y bueno .. se desencadena en un montón de situaciones (estoy exagerando un poco mi experiencia para mostrar las cosas que podrian pasar :) ).

Bueno espero les sirva un poquito todo esto que lo saque de un libro, la parte que comenta Manfred Ratzmann, Clinton de Young y el resto de mi experiencia :).

 

PD. Ahora entiendo porque muchos developers muchas veces tienen que pasar primero por control de calidad, aunque no sea una regla, lo puedo comprender mejor. Pero a veces hacemos las cosas al revés :( , pero bueno .. ahora estoy informándome y viviendo al respecto.

 

[1] : Software Testing and Internationalization: Manfred Ratzmann, Clinton de Young

Bueno, retomando algunos conceptos. Recorde otro: Mixins En POO, un mixin es una "clase", que declara atributos y firmas de métodos. No representa como tal una especialización, y bueno también un mixin no "funciona" por si solo, necesita que los método cuyas firmas declara, sean implementados en clases derivadas. En cierta forma permiten definir interfaces, muchas veces utilizados en arquitecturas de software por capas, servicios y otros. Donde lo que importa es conocer los servicios que se ofrecen y poder utilizarlos. Lo más próximo a un mixin en Java son las interfaces, donde se declaran firmas de métodos que deben sobre-escribirse en clases que "implementen" de dica interface, en Java también se pueden declarar "atributos", variables :) .. constantes. Bueno también se puede tener una buena estructura para manejar Mixins en Java en base al combinando interfaces con POA (Programación Orientada a aspectos), tema del que estaremos hablando más adelante :) .... (AspectJ)

Bueno desde hace un tiempo empece a interesarme por aprender nuevos terminos en mi vocabulario, y bueno salio la palabra REFLEXIÓN. Definiciones: En Óptica se refiere al fenómeno por el cual un rayo de luz que incide sobre una superficie es reflejado..... En mecánica ondulatoria y acústica hay un fenómeno idéntico al de la reflexión óptica. En este caso, lo que se absorbe o refleja, ya no es luz, sino ondas... En Geometría es el proceso de trasladar o copiar todos los puntos de una figura a otra posición equidistante de una recta denominada eje de simetría... En Filosofía se refiere al proceso de meditar. En Informática es una característica de algunos lenguajes de programación como Java que permite obtener información de los componentes de un programa durante su ejecución. [1] mmm .. bueno el que nos interesa es el último, más bien del que voy a hablarles esta vez. Bueno sucede que en la actualidad los lenguajes de programación la estructura del programa es sumamente importante, sin embargo "algunos" lenguajes cuando se compila un programa y se va bajando a un código de bajo nivel se va perdiendo dicha estructura. Pero bueno existen lenguajes de programación que utilizan máquinas virtuales (por supuesto Java .. JVM) que no necesitan bajar hasta código de bajo nivel para ejecutar sus programas (bytecodes que son interpretados por por la JVM-JRE), entonces estos lenguajes a momento de compilar sus programas no pierden la estructura del mismo, por lo que a partir de ello se puede reconstruir el código original (los clásicos decompiladores). Entonces decimos que si un lenguaje permite reflexión es porque en "algún" lugar del código compilado mantiene información sobre la estructura misma del programa, es imporante mencionar que la reflexión por lo general es dinámica (tiempo de ejecución), aunque también existen algunos lenguajes que suceden de manera estática (tiempo de compilación). Para más detalle pueden revisar: es.wikipedia.org/wiki/Reflexión_%28programación%29 No olviden la reflexión del día :) [1]: http://es.wikipedia.org/wiki/Reflexión

Nullable Types (bueno tampoco existe en Java) Un tipo Nullable puede representar el rango normal de valores del tipo de dato al que hace referencia en su parámetro, pero además permite un valor null en la variable que se este utilizando. Por ejemplo si queremos utilizar un entero tendriamos algo como esto: Int32 x;, lo cual almacena valores entre [-2147483648 a 2147483647], pero si hacemos lo siguiente: Nullable x; se podrá almacenar el mismo rango de valores pero además un valor de null, lo mismo pasa con los otros tipos de dato (por ej: bool [true, false, null], tres valores) Bueno alguien puede preguntar y esto para que sirve, bueno en realidad su aplicación se ve cuando se está trabajando con BD, cuando utilizamos un framework por ejemplo, podremos decir "que campos son obligatorios, cuales no" :). Ya habiamos hablado antes de esto con un docente, mencionando que en los lenguajes hasta entonces (por lo general) no tenían una forma de especificar en una clase, con relación a la BD, podrian ser obligatorios, cuales llaves foráreas, cuales llaves, etc. Es cierto que esto se define en los mapeos a la BD, sin embargo cuando se trabaja con varias personas (lo que es casi obligatorio hoy en día), muchas veces los desarrolladores se encargan de una parte del desarrollo en la que no tiene porque ver más alla de donde trabaja, es decir solo conocer los servicios de otros componentes, módulos y subsistemas. Entonces para conocer que campos se deben registrar, cuales son obligatorios para el control, etc. uno debe bajar a ver el diseño de la BD :). Bueno creo la cosa va por ese camino, desde mi punto de vista me parece excelente cuando se hace un mapeo a la BD desde clases y este mapeo ya genera los campos no null o los que si pueden ser :).

Bueno soy algo nuevo en C#, algo que quiero compartir es lo siguiente (no se tiene en Java :( ) Las palabras clave contextuales se utilizan para proporcionar un significado concreto en el código. Pero estas no son palabras reservadas como tal en C#. get Define un método de descriptor de acceso para una propiedad o un indizador. (Supongo esto por la estandarización de los mutator y accesor, setters y getters) partial Define clases parciales, estructuras e interfaces a lo largo de la misma unidad de compilación. Las definiciones de tipo parcial permiten dividir la definición de una clase, estructura o interfaz en varios archivos. (No hay en JAVA :( ) Bueno lo que también se pueden mencionar aqui es: En Java se pueden definir varias clases dentro un solo archivo, recordando que solo una de las clases puede ser pública. (No es una buena práctica de programación). En C# se permite tener varias clases públicas en un mismo archivo :(. Este último no me gusto mucho. set Define un método de descriptor de acceso para una propiedad o un indizador. IDEM get where Agrega restricciones a una declaración genérica. Bueno esto va con lo que es genericidad restringida, ejemplo en Java y C# JAVA public class MiClase C# public class MiClase where T:IComparable yield Se utiliza en un bloque de iteradores para devolver un valor al objeto de enumerador o también para señalar el final de iteración. value Se utiliza para establecer los descriptores de acceso y para agregar o quitar los controladores de eventos. Bueno la equivalencia va mas o menos asi en los setters y getters: JAVA: public void setNombre( String nombre ) { this.nombre = nombre; } public String getNombre() { return this.nombre; } C#: public string Nombre { set{nombre=value} get{return nombre} } Bueno son algunas cosas que pude estar viendo sobre C# .Net

Bueno ... no se que opinarán ustedes, pero creo muchos se desanimarán de comprar una MAC (por el precio), obviamente habra quienes que conocen la calidad de una máquina MAC se mantendrán en ella :). Escuche que estan sacando más sobre sistemas MAC para PCs, eso tendre que verlo para creerlo :), creo es una característica que tiene Leopard.

Pero esto me parece mmmmmmm .no se.. bueno .. me deja pensado, quizás la noticia es antigua (para mi nueva). Intentare probar la instalación, ahi les dejo el link. Instalar Mac OS X en un PC Intel x86

He estado viendo algunas empresas donde ya se han automatizado los procesos, es decir ya tienen un sistema que les ayuda a administrar desde compras, ventas, personal, asistencia, etc.

He vivido materias en la universidad donde se nos ha inculcado la elegancia del software, donde hemos pasado horas analizando segmentos de código para mejorar la estructura, la eficiencia y otros aspectos relacionados a calidad en el código de los programas. El hecho es que en la vida real no se ve mucho esto, así que me pregunte por qué ?. Bueno entonces el hecho es el siguiente: he clasificado en tres grupos a los desarrolladores de software:

1) Desarrolladores de aplicaciones

2) Desarrolladores de sistemas

3) "Cientificos" del desarrollo

El primer grupo obviamente no le interesa mucho los temas de fondo del software, simplemente hacer un sistema que se utilice, que importa si más adelante se podrá mantenerlo, la cosa es que se utilice y sea pagado. Creo aquí entran los analistas de sistemas y personas que salen de institutos. (No todos)

El segundo grupo aquellos que realmente hacen sistemas "de verdad", sistemas bien estructurados, muchos programados en lenguajes de bajo nivel, etc. Creo aqui encajan las personas que se educaron en una universidad. (No todos)

El tercer grupo, en si no desarrollan, pero aportan a como seria mejor no solo la implementación de un sistema, sino todo el proceso de desarrollo del mismo. (Masters, Doctores, también auniversidades)

Sin embargo haciendo referencia al principio del post, uno se puede sorprender al ver sistemas utilizandose implementados en VB, Fox Pro, Access, y digamos lo que digamos, son sistemas que en este momento se utilizan (duele un poco). Ahora bien puede haber otro criterio: "yo no no me voy a ensuciar con eso". Pero vamos al objetivo inicial de un desarrallador de software, facilitar la vida de los humanos. Obviamente puede que este objetivo haya cambiado con el tiempo, ahora queremos hacer las cosas "bien", pues bien, creo que debemos hacerlo :).

He escuchado muchos comentarios de que la competencia para personas relacionadas a las ciencias de la computación son los analitas y quienes salen de institutos... mmmmmm .. lo dudo.

Durante este fin de año 2007 y principios del 2008, he exprimentado, investigado, visto muchas cosas respecto a este tema. Mis conslusiones:

1) Linux (usuarios linux) inician la guerra.

2) Software libre, muchos lo dicen, pocos lo practican.

3) Linux es mejor, para muchas cosas, pero otras Windows es mejor.

4) Windows se paga, Linux no. Pero hay "lucha" entre ellos, me pregunto como serían las cosas si Win no se pagara, habria lucha?

5) A la mayoría (si no todos) nos ha servido Win para inciar en la computadora, después por diversas razones, algunos se migraron a Linux por completo, y otros somos mixtos.

6) Es mejor utilizar cada sistema donde corresponde, es decir voy construir una pequeña habitación, necesito un ingeniero,un arquitecto, muchos albañiles, mucho material ?.Bueno quizás solo dos albañiles... o bueno mejor lo pienso mejor.

7) Win hace muchas cosas por ti, inclusive las que no necesitas. Linux, todo lo tienes que hacer, inclusive buscar los driver de tu modem en internet, pero que macana como no tengo el driver de mi modem, no puedo conectarme a internet. Entonces ire a un cafe internet, donde un amigo o en el trabajo, o mejor, primero inicio Windows, descargo el driver y luego inicio Linux para instalar mi driver :)

8) Para mi no hay "lucha", el hecho es aprovechar de la mejor manera lo que tenemos a nuestro alcance.

 

Quiero aclarar que no estoy favor de Linux, ni de Windows :)

Hola a todos, veo que AJAYU ya esta funcionando después de algún tiempo. Esperemos este más estable :), uno extraña poder expresarse por este medio.

Bueno, hoy escribire sobre algo que me toco ver de cerca en terceras personas, la esquizofrenia (Y por ende aprendi mucho). 

La esquizofrenia es una enfermedad mental, en nuestro medio no es algo que se conozca a pronfundidad, generalmente cuando vemos en la televesión unos hombres de blanco que se llevan a una persona en una camisa de fuerza, lo primero que se viene a la mente es "esta loco"  :). Bueno sucede que cualquiera podría volverse "loco", todo depende de muchas circunstancias, veamos algunas:

1)   Los traumas de la infancia. (Ver un accidente, ver a alguien morir, o situaciones familiares un tanto "feas" ) . Esto va evolucionando en el subconciente y derivan a que el organismo desde pequeños vaya acumulando ciertos quimicos en la cabeza que pronto derivan en esquizofrenia.

2)   Cuando nos suceden cosas inexplicables. (La muerte de un ser querido, acciones que uno hace y no las esperaba, fracaso, descepción). Esto se parece a las computadoras, pues después de que sucede un evento muchas veces el cerebro no encuentra una explicación y nos encerramos en buscar el por que de las cosas, pero seguimos buscando y no se encuentra solución ni respuesta, entonces el cerebro entra a un vacio (se cuelga).

3)   Hereditario. A mi me sorprendio mucho que ciertos problemas mentales se pueden heredar, pero recorde, es una enfermedad, entonces, si puede heredarse.

Que sucede cuando uno padece de esquizofrenia, pues pierde la razón, nada tiene sentido ni siquiera la vida, aquelo que uno disfrutaba hacer no sirve, no vale. Entonces cualquier influencia, cualquier pensamiento (por ejemplo de la televesión) afecta enormemente, es ahi donde mucha gente se suicida, o mata a otros, bueno y cosas un tanto feas. Una persona con esquizofrenía es sensible a cualquier estímulo, bueno o malo, y reacciona de acuerdo a ese estímulo.

Hay cura ?. Bueno como casi en todas las enfermedades, hay grados de esquizofrenía, en algunos casos hay tratamientos, terapias, medicamentos y otros. Quízas estas cosas sean tema de conversación más adelante como lo es en otros países. 

 

Desde hace algún tiempo me he dedicado a escribir mi documento de proyecto final, y para ello consulte algunas páginas de internet, revise algunos documentos de las carreras de Sistemas e Informática (algunas con mucho asombro ;) ). El hecho es que en algunos casos estos documentos hablaban únicamente de todas las actividades realizadas en el desarrollo del proyecto (voy a referirme especificamente a los documentos que reflejan el trabajo realizado para obtener la titulacion, no tanto asi a una tesis), otras sin embargo parecian ser copia fiel de algunas páginas en internet o de algunos libros.Revisando algunos documentos me sorprendio encontrar tambien encontrar en sus capitulos, un monton de diagramas con una explicacion bastante técnica, pero bueno .... Desde mi punto de vista un documento de proyecto final, debe contener una introduccion, el problema al cual se esta enfoncando, la solucion planteada, las actividades realizadas, lor problemas a los que se enfrentaron y la manera como se solucionaron, haciendo uso de elementos computacionales u otros, la organizacion, algun tipo de aporte social y tecnológico, y por supuesto las conclusiones. Todo esto respaldado por citas bibliográficas, si alguien tiene sugerencias o críticas al respecto se los agradecería mucho :). En mi caso considere los siguientes aspectos para mi documento: Introducción, Proceso de desarrollo, Análisis – Requerimientos, Diseño funcional – Patrones de diseño, Diseño de interfaz grafica, Diseño 2D – 3D – VRML, Implementación, Librerías – Frameworks – Herramientas, Aplicación del sistema, Aportes, Conclusiones – Recomendaciones – Extensiones, juntamente con algunos otros aspectos, pero creo que estos temas abarcan de manera general el contenido de mi documento.