MIS PROYECTOS (EL NUESTRO Y EL MÍO)

El MIO
Dar un MANTENIMIENTO GENERAL a una base de datos (-ahora sé que en toda base de datos de SQL 2000 hay tablas en donde esta la definición de los campos y las tablas-) de verdad no se bien como hacerlo así que hasta nuevo aviso estoy tentado en aprender un poco de ficheros. Además de acuerdo con mi proyecto general, me serviría bastante tener un generador de store procedure. La idea de este generador de procedures es copiado de esas herramientas que te generan todo para darle mantenimiento a una base de datos específica o sea lo que quiero generar como mi proyecto.
Si como ya se habrán dado cuenta trata de reinventar la rueda ese es mi proyecto solo que esta rueda me parece un poco más útil reinventarla que usarla en cuanto a qué pueda aprender yo al reinventarla. Asumo que aprenderé algo del espacio de nombre (-ya iba a decir librería-) Ssystem.IO del cual no se más de que existe y que maneja I/O bueno entonces manos a la obra
O sea hacer que genere archivos con el código en transac para correrlo en la base de datos así ahorrarme unas tipeadas de mi programa

Eso por el momento con lo de armar mi generador de mantenimiento de tablas aunque el reto o mas bien el sueño es llegar a codificar un control personalizado de manera que este me haga la vida mas fácil tiene que incluir:

primary keys generadas por defecto (que es esto) bueno es algo así como esto:
en una base de datos usualmente tu necesitas tener ids (primaries key)que sean de la forma idalumno que tenga como ocurrencia esta: alu001, alu002,... por ejemplo aunque no se si sea un buen ejemplo
bueno pues el control tiene que rastrear estos constrains o restricciones en base de datos sin necesidad de que tenga que especificarlo en ningún lado o tal vez si pero muy someramente

De ahí tiene que mantener la integridad referencial es decir que se pueda conseguir que por ejemplo todos los registros que se van a agregar en campos de los que son claves foráneas se pueda escoger de los campos relacionados en las tablas ya creados es decir ya especificados en las demás tablas en caso de no encontrar el que deseemos para nuestro registro debemos de ingresarlo pero no en esta tabla ya que esta relacionada con la otra foráneamente tendríamos que generar un nuevo registro en la otra tabla a la que esta relacionada

O sea todo esto a lo que me refiero se puede hacer poco a poco control a control un label un combo un enlace a la otra tabla comprobando en base de dato y especificando programáticamente la generación de las entradas a la base de datos

NUESTRO PROYECTO
Ahora según la ultima reunión de la célula supuestamente tenemos que investigar de lo ultimo es decir de lo concerniente a WinFX como lo queremos llamar no con el engañoso titulo de Framework 3.0 bueno pues manos a la obra que esta búsqueda promete mas que una sorpresa prepárense para decir woaow como por el pase que me salio hoy en la pichanga pero alguien se la fallo

PD: Ronal hoy si no hice ningún autogol jugando de arquero estoy mejorando
lo malo es que si me metieron un gol pero solo uno BYE gente

Membership

Resulta que estaba llevando un curso que se llama TALLER DE INGENIERIA DE SOFWARE. La verdad no se si aun lo he pasado. Porque al llegar la hora me faltaba terminar de programar un formulario y me olvide de el, o sea el sistema funcionaba pero no habia una parte de creacion de usuarios en la WEB o sea no habia punto de inicio para un administrador del sistema que fuera nuevo y que no tuviera VS para crear los usuarios con la herramienta para eso

Tuve muchos problemas para tener la data de los usuarios registrados con membership ya que el sistema ya tenia unas tablas que administraban los usuarios ese fue un problema. Me dio miedo alterar las tablas que te genera el VS para manejar los roles y la membresia y relacionarlos via foreing key a la tabla que ya tenia de Usuarios con la de aspnet_users (generada) se me ocurrio hacerlo con un trigger que te actualize las dos tablas de ahi vi que como que era un poco replicar data y "a hacer eso no me enseñaron en mi cursito de MODELAMIENTO DE DATOS" pero lo tenia que hacer y como no se mucho de sql2005express en donde estaba mi sistema (aunque he corrido codigo para sql2000 en el 2005 y no pasa nada-el transact es universal) lo hice en los formularios con una clase que ejecuta los dos insert o update juntos.

CREO QUE LO DE LOS TRIGGERS ERA MEJOR OPCION ¿qué dice la gente?--aparte que soy un idiota claro

Hola gente celula

Hola gente celula justo recien estaba viendo lo de las versiones en español del sqlexpress a ver si puedo aprovechar eso que tiene todos los servicios del SQL 2005 express me interesaria bastante a ver como me las arreglo ya que necesito una interface diz que no hay interface express para administrar todos sus servicios, ya que son todos los del 2005 completo (que cuesta).
Bueno la verdad que eso es como un post repetido ya que esta en la pagina de comunidad universitaria con la unica diferencia que hay un service pack del sql2005express que aun no lo bajo.

caso de uso (visitar www.usecase.org)

FORMATO DE CASO DE USO EXTENDIDO con EJEMPLOS

Actor Principal: ocurre a los servicios del sistema para cumplir un objetivo

Ej.:
CAJERO

Personal Involucrado e intereses: el sistema funciona siguiendo un contrato entre el personal involucrado, donde los casos de uso detallan la parte del comportamiento del sistema en el contrato. Los casos de uso captura (trata) el comportamiento relacionado con la satisfacción de los intereses del personal involucrado

Ej.:
Cajero: quiere entradas precisas, rápidas y sin errores
Vendedor: quiere que las comisiones de las ventas estén actualizadas
Compañía: quiere registrar las transacciones con precisión y satisfacer los clientes. Quiere cierta tolerancia a fallos. Quiere actualizar automática y rápida de la contabilidad y del inventario

Precondiciones: establecen lo que siempre debe cumplirse antes de comenzar un escenario del caso de uso. No se prueban en el caso de uso sino que se asumen como verdaderos.

Ej.
El cajero se identifica y autentica

Normalmente implica un escenario de otro caso de uso que se ha completado con éxito

Post condiciones establecen que debe cumplirse cuando el caso de uso se completa con éxito la garantía debe satisfacer las necesidades de todo el personal involucrado

Ej.:
Se registra la venta. El impuesto se calcula de manera correcta. Se registran las comisiones. Se genera el recibo. Se registra las autorizaciones de pago aprobadas.

Escenario principal de éxito: describe el escenario principal de éxito típico que satisface los intereses del personal involucrado

Ej.: 96571356
1 el cliente llega al punto de venta con mercancías para cobrar
2 el cajero comienza una nueva venta
3 el cajero introduce el identificador del articulo
4 el sistema registra la línea de venta y presenta la descripción del articulo precio y suma parcial. El precio se calcula a partir de un conjunto de reglas de precio
-el cajero repite los pasos 3-4 hasta que se le indique-
5 el sistema presenta el total con los impuestos calculados
6 el cajero le dice que se le pague
7 el cliente paga y el sistema gestiona el pago
8 el sistema registra la venta completa y envía la información de la venta y el pago al sistema de contabilidad externo (para la contabilidad y las comisiones) y el pago al sistema de inventario (para actualizar el inventario)
9 el cliente se va con el recibo y las mercancías (si es el caso)

Extensiones: son muy importantes indican todos los escenarios o bifurcaciones tanto éxito como de fracaso. Es usualmente más extensa que el escenario principal

Cuestión metodológica del manejo de extensiones
-una primera extensión al paso 3 del escenario principal se etiqueta como 3a se menciona primero la condición (como algo que puede ser detectado por el sistema (Ej.: el sistema de pago externo falla VS el sistema "detecta" un fallo en la comunicación con el sistema de pago externo) y después la respuesta del sistema una siguiente extensión se etiqueta como 3b y así sucesivamente

3a identificador no valido:
1-el sistema señala el error y rechaza la entrada sigue con el flujo principal en el paso 3
3b hay muchos artículos de la misma categoría y tener en cuenta una única identidad del articulo y la cantidad
1 el cajero puede introducir el identificador de la categoría del articulo y la cantidad

- el manejo de las extensiones (respuesta) puede manejarse en uno o mas pasos

3-6a el cliente pide que se elimine uno o más artículos de la compra actual
1 el cajero introduce el identificador del articulo que va a ser eliminarlo de la compra
2 el sistema muestra la suma parcial actualizada

-cabe resaltar que al final del manejo de la extensión, por defecto se une de nuevo con el escenario de éxito a menos que la extensión diga otra cosa (como interrumpir el sistema)

Algunas veces el punto de extensión particular es bastante complejo, como en la extensión pago a crédito. Esto puede ser motivo para expresar la extensión como un caso de uso aparte. Si es deseable que se tenga una extensión que pueda ser posible durante cualquiera (o al menos la mayoría) de los pasos, se puede utilizar las etiquetas *a, *b

analizando la informacion del negocio

Analizando La Información

El proceso de análisis de la información es iterativo. Usted recoja algo de información y analícela. Indudablemente en el momento de analizar esta van a surgir interrogantes que usted puede indagar en otra entrevista. Obteniendo más nueva información usted puede ayudar al continuo análisis del negocio. Con esta manera se puede continuar durante el resto del ciclo de vida del proyecto aunque se desarrolla más esta actividad durante el comienzo del ciclo de vida del proyecto

Analice la arquitectura de información de la empresa
Describa los casos de uso usando escenarios
Elabore la documentación interna del proyecto

Arquitectura De La Información De La Empresa

Cuando se piensa en obtener la suficiente información del cliente usted puede pensar en una gran cantidad de información de la que determinar cual es la información relevante para el objetivo del negocio. Usted necesita sintetizar esta para elaborar una adecuada descripción del actual estado del negocio

Así como usted analiza la información también debe verificar que se tenga la suficiente información que describa el actual estado del negocio así como los requerimientos del producto incluyendo:

Necesidades de seguridad
Estructuras de soporte para la solución de esas características del producto
Cambios en la estructura del negocio que puedan afectar el diseño del producto
El rendimiento que los usuarios esperen o que el negocio necesite para permanecer competitivos
Aplicaciones existentes que puedan interactuar con el nuevo producto
Como el existente proceso de negocio afecta la solución

Se debe identificar cualquier brecha existente entre la información obtenida y la suficiente y si es necesario recabar más

Cuando el equipo de desarrollo realmente haga el producto final esta se necesitara para verificar los requerimientos conocidos que fueron establecidos durante esta fase. El equipo también pueda necesitar esa documentación para efectos de cuando el nuevo producto esté en un nuevo entorno en términos de requerimientos para el negocio como soporte mantenimiento o extensibilidad de uso. Los nuevos requerimientos también deben contener las restricciones que se documenten durante el análisis





Casos de Uso de alto nivel y escenarios de uso

Después de que se tengan sintetizadas la información usted puede desarrollar los casos de uso y escenarios de uso para documentar el negocio, el proceso de negocio y los requerimientos del usuario con más detalle. Los casos de uso y los escenarios de uso se desarrollan para proveer de una estructura para cuando el equipo diseñe la solución. Además los casos de uso o escenarios de uso pueden corresponder a uno o más requerimientos. Esta correspondencia permite asegurar que los requerimientos sean bien conocidos


Casos de Uso

Los casos de uso muestran la funcionalidad del sistema
Los propósitos de los casos de uso son:
Identificar todos los procesos de negocio y todas las actividades de comienzo a fin
Documentar el contexto y el entorno
Establecer la conexión entre necesidades de negocio y los requerimientos de los usuarios
Describir las necesidades y requerimientos en su contexto de uso
Enfocarse en el usuario y el equipo de desarrollo

Los casos de uso proporcionan los siguientes beneficios

Proveen el contexto para requerimientos
Facilitan el común entendimiento
Proporcionan las bases para los escenarios de uso
Facilitan la objetividad y consistencia en la evaluación de la sugerencia de usuario


Escenarios de uso

Los casos de uso describen las interacciones de alto nivel entre el individuo y el sistema. Los escenarios de uso proveen información adicional acerca de las actividades y la secuencia de tareas que constituyen el proceso. Juntos dan una descripción del flujo de trabajo


Borrador del documento de requerimientos

Luego de que el equipo haya obtenido la información de los clientes uno de los pasos siguientes es elaborar el borrador del documento de requerimientos. El documento incluye una lista preeliminar de requerimientos de la información obtenida por el equipo. El principal propósito de este documento es registrar cualquier posible requerimiento, haciendo esto se garantiza de que no se pierda información que sea necesaria. La información que sea recogida de diferentes fuentes incluye requerimientos y necesidades del negocio y las perspectivas del usuario. Los requerimientos indican lo que el producto o solución necesita para resolver los retos del negocio que son derivadas del negocio como de las perspectivas del usuario.

Las necesidades indican como los altos directivos y los usuarios puedan ver el producto final

Los requerimientos listados en el borrador no están refinados y pueden ser una mezcla entre requerimientos y necesidades. Estos requerimientos son refinados posteriormente en otras etapas de visionamiento y planeamiento cuando el equipo tenga más información de los usuarios

Tomado De: ANALYZING REQUIREMENTS AND DEFINING MICROSOFT.NET SOLUTION ARQUITECTURES PUBLISHED BYMicrosoft PressA Division of Microsoft CorporationOne Microsoft WayRedmond, Washington 98052-6399 Copyright © 2003 by Microsoft Corporation

Gestión de Requisitos

Comprensión de los Requisitos

En un estudio sobre costos en proyectos reales en diferentes empresas reveló que el 37% de ellos estaban relacionados con los requisitos. Entre los cuales figuran requisitos incompletos y cambios en los requisitos
El proceso unificado de desarrollo fomenta un conjunto de buenas prácticas una de las cuales es la gestión de requisitos. Lo cual no tiene que ver con desarrollo en cascada donde se definen plenamente los requisitos, sino que se asume a estos cambiantes y poco claros como en realidad lo son; "un enfoque sistemático para encontrar, documentar, organizar y seguir la pista de los requisitos cambiantes de un sistema".

Tipos de requisitos
El Proceso Unificado clasifica los requisitos con el modelo FURPS+ como una manera de clasificar los requisitos de esta manera reducir los riesgos al no considerar alguna faceta importante del sistema.

Funcional (functional) características, capacidades y seguridad
Facilidad de Uso (Usability) ayuda, documentación, etc.
Fiabilidad (Reliability) frecuencia de fallos, capacidad de recuperación y grado de previsión
Rendimiento (Performance) tiempos de respuesta, productividad, precisión, disponibilidad, uso de recursos
Soporte (Supportability) adaptabilidad facilidad de mantenimiento internacionalización y configurabilidad

El "+" del FURPS+ indica requisitos adicionales tales como:
Implementación, restricciones impuestas por el uso de lenguajes herramientas de hardware
Interfases, restricciones impuestas para la interacción con sistemas externos
Operaciones, gestión del sistema en tiempo de discusión
Empaquetamiento
Legales, como licencias

Modelo de casos de uso

Los requisitos funcionales se estudian en el modelo de caso de uso, los otros requisitos se pueden incluir en los casos de uso con los que estén relacionados con

ningyo hime (2do tema de cierre de Chobitts)

Bueno gente les cuento que me he vuelto un fanaticaso de Chobits. Es un anime de CLAMP no se de cuando (creo que del 2002) .Hace como 2 años o un poco más lo vi pero no terminé la serie me vaciló(-gustar en peruano-) porque en esos momentos me dedicaba a otras cosas.
Resulta que el jueves 8 de diciembre (feriado en Perú) mi pata (amigo en peruano) me prestó un DVD donde esta la serie completita -Gracias Loco te pasaste- y como que estoy dudando bastante en devolvérselo por lo menos no dentro de los proximos "N" años -mentira Loco un día de estos estaré por tu casa y te diré en tu cara que "no te los voy a devolver", hasta ese día ten esperanzas-. En si el anime es buenaso y la protagonista principal me tiene loco su manera de ser es la de la jerma (enamorada en peruano) que nunca nadie de nosotros podrá tener. CREO QUE LO ÚNICO MALO ES QUE ES UNA BEBE, pero es bellisima en si es un ángel; lo malo es que no es humana ella es una "perssocon" en la serie es algo asi como androides pero su forma es casi perfecta en la similitud que alcanzan con los humanos (hasta se diria que son mucho más lindas que las humanas, tratan de ser perfectas).

La serie no maneja ninguna trama apocalíptica de que los androides dominen a los humanos sino de la misma deshumanización de las personas en cuanto a que prefieran relacionarse con eso (como llaman a las perssocon en un libro que CHII la protagonista principal esta leyendo -recuerden que ella tambien es una perssocon-). Bueno gente aver si se animan a averiguar mas de esto y ojalá les vacile (-gustar en peruano-) si alguno de los que lee esto tiene acceso a mi de por si que por lo menos les prestaré los primeros capitulos en CD claro, ese DVD es miiiiiiiio SOLO MIO (-mentira Loco-).

GSUSLUYO

Ella es idéntica a ella, no es ella, es algo que tienes que enterarte viendo la serie pero en si la trama es bien pensada y hasta lo que voy viendo (cap 13) me deja muchas muchisimas dudas como para seguir viendolo hasta el final

Terminé de ver la serie bueno me falta un capítulo más que se llama Chibits en si parece que es como una continuación (-extensión seria la palabra-) de la serie. En si ya vi el final y me gustó, mas que todo el detalle de que los perscon fueran en si humanos (por un momento) en un solo brillo en los ojos tan fantástico como solo la animación japonesa lo puede hacer.

La serie estaba buenasa y creo no volver a ver un anime en un buen tiempo pues tengo la dicha de estudiar algo que me gusta y en si mi carrera es el motivo de este Blog en si lo del anime fue para probar lo del BLog (mi primer blog). Ya les contaré de lo que estoy investigando pero por el momento denme un toque que me voy a mi clase en la Facu BYE gente un gusto que lean mi Blog

GSUS