Category Archive

Regresando de a poco a la actividad blogger, les hago participes de este emprendimiento que necesito que funcione no solamente por que una materia lo exige, sino que ya ando con ganas de generar mi propio dinero, si al principio será poco, pero el chiste está en invertir lo que ganas, como los chinitos, por algo on grandes o no?.

Pues bueno, este emprendimiento cuenta con la colaboración de Alex Lojan, Michael Freire y Juan Pablo Angamarca, ya tenemos varias semanas tratando de equilibrarnos, cuesta pero le estamos dando.

Por fin se va a llevar a cabo un acto que vale la pena, este se realizará en el edificio Octogono de nuestra universidad, lo chevere es que habran conferencias (o mejor microconferencias) sobre los aspt{ectos web2.0 es una actividad ideada por los bloggers de la U, entre ellos, calu, palulo, gabby, que expondrá microbloggin (asi creo que se escribe) y otros temitas cheveres. Mejor dicho, caramba, no se pueden perder este acto si existe el deseo de aprender algo más sobre web2.0

La agenda y mayor información se puede encontrar en el blog de la escuela más bcan de la U.

Los ingenieros en sistemas la gran mayoría tiene cierta aversión a la IR, ¿Por que?, pues si bien es cierto que la IR es aburrida y a veces hasta tediosa, pero tampoco deja de ser cierto que la IR es hoy en día la base para elaborar cualquier sistema, aunque puede dejarse de lado (no tanto) en sistemas muy pequeños. En nuestra segunda clase de Ingeniería de Requisitos hablamos de este tema. La clase pues, que decir, pues muy diferente a las demás, se llevó el tema más como una discusión entre los estudiantes, analizando, corrigiendo, es decir aportando que es lo que se busca con este nuevo sistema. ¿Por que se originan las necesidades?. Si bien es cierto que el programador plasma lo que el papel dice en código, pero ¿como se obtiene aquello? Para que un sistema tome forma primero debe existir la necesidad de mejorar o crear algo nuevo por parte del cliente o del visionario que vea necesidad donde otros vean problemas y nada más.

Un requisito es una necesidad del usuario que quiere que se implemente en el sistema. Un punto que se aclaro fue la Tarea de la Ingeniería de Requisitos la cual proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, administrar los requisitos. Este proceso se lleva acabo durante siete funciones las cuales son: inicio, obtención, elaboración, negociación, especificación, validación y gestión.

Estas funciones ayudan a que el Ing. De requisitos de software establezca una base solida respecto al diseño y la construcción.

Otro punto que se trato es el de Inicio del proceso de la ingeniería de requisitos

Este punto hablamos sobre aquellas personas que se benefician del sistema en forma directa o indirecta (stakeholders) y como las distintas personas (stakeholders) ven los requerimientos desde distintos punto de vista. También proporcionamos algunas preguntas formuladas para que el Ing. de software se relacione con el usuario y empiece a obtener los requerimientos. Para poder identificar cada usuario y identificar el escenario de cada usuario.

This is a video proof of nmap on a PC, there are some errors into the video but I want give you a very simple way for meeting vulnerabilities in a PC.

Sorry, my english is not too good

El siguiente video es solamente una prueba que hice sobre una maquina utilizando Umit, hay algunos errores de edición que espero sepan perdonar.