- Arquitectura: Diseño básico del microprocesador. Puede incluir tecnología de proceso así como otras mejoras en la arquitectura.
- Caché (Mb/Kb): Se trata del almacenamiento temporal para los datos a los que se acaba de acceder o a los que se accede con frecuencia. El almacenamiento de determinados datos en caché acelera el funcionamiento del ordenador. El tamaño de la caché se mide en megabites (Mb) o en kilobites (Kb).
- Bus del sistema:La vía de conexión entre el procesador y otros componentes esenciales como el hub de la controladora de memoria. La velocidad del bus del sistema se mide en GHz o MHz.
- Velocidad de reloj: La velocidad del reloj interno del procesador quedetermina la rapidez con la que puede procesar los datos. La velocidad de reloj se mide normalmente en gigahercios (GHz) o miles de millones de ciclos por segundo.
viernes, 27 de junio de 2008
Definiciones útiles
Proyecto: SICI "Sistema Informatico de Contratos por Internet"
Entrevista con el cliente.
1. ¿Cual es el nombre de su empresa?
Cliente: “Siblings Roar Sound”
2. ¿Cuál es el giro de su empresa?
Cliente: nos dedicamos a la musicalización de eventos sociales; es decir somos, como popularmente nos llaman, un sonido.
3. ¿Cuál es su función dentro de la empresa?
Cliente: Soy el propietario y administrador, el encargado de la logística, servicio técnico, ventas y publicidad.
4. ¿Cuantos empleados tiene y a que se dedica cada uno?
Cliente: Tengo a tres o mas personas bajo mi mando, una de ellas es mi socio, quien aporta la mitad de mitad del equipo en los eventos y es el encargado, la mayoría de las veces, de las relaciones publicas y contratos. Los otros dos son cargadores e instaladores o staff, que son empleados temporales y que muchas veces varían.
5. ¿Cómo es la operación, manual o automatizada?
Cliente: Totalmente manual.
6. ¿Cuáles son los problemas mas comunes?
Cliente: La falta de energía eléctrica que se soluciona contratando a una persona que presta el servicio de un generador, necesito tener a la mano su teléfono el cual esta apuntado en una agenda.
Descomposturas en el equipo, que se soluciona llamando a un técnico del cual tengo su número telefónico guardado de igual manera en la libretita (agenda).
Transporte, necesito solo en ocasiones contratar un transportista al cual contacto por teléfono (anotado en la misma agenda).
7. ¿Qué información le gustaría tener a salvo y al instante en un sistema informático?
Cliente: Los contratos, que estos además puedan llenarlos los clientes desde Internet.
Manuales de uso de cada aparato, en caso de fallas o contrataciones de DJ de último minuto que no sepan usar nuestro equipo.
Los datos completos de mis clientes pasados para ofrecerles promociones, y que además pueda agregar sus sugerencias y opiniones en texto.
Los datos de empleados eventuales para contratarlos nuevamente en el momento que los necesite.
Y los de varios transportistas para contratar el servicio que este disponible.
Si voy a hacer uso de un equipo de cómputo, que este tenga y organice mi música, para dejar de usar discos.
Que soporte un mapa de la ciudad (estilo Guía Roji) para localizar el lugar del evento.
Algo que me seria muy útil es una página Web que contenga los datos de mi empresa y pueda realizar un contrato en línea con depósito en el banco.
8. ¿Cómo es un día normal de operaciones?
Cliente: Primero el cliente me contacta por teléfono y pregunta por nuestros precios, el cliente acepta la tarifa y nos aparta la fecha del evento para no tener dos eventos el mismo día y lo apunto en la agenda-calendario.
Luego el cliente me da su dirección, lo visito y hago que firme el contrato, recibo un adelanto del 50% en efectivo.
Contrato por llamada telefónica a los “cargadores” (empleados eventuales), y al transportista.
Llegado el día del evento cobro el resto del pago y comienzo la instalación del equipo.
Durante el evento es constante el cambio de discos para poner canciones varias que están catalogadas por género.
Al final compruebo la conformidad de mi cliente con el servicio y me retiro.
Definición de tablas “B-D” de SiCI (Sistema de Contratos por Internet)
Normalización de las tablas.
Distribución original:
CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TelefonoMovil, Dirección, E-mail)
CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, Contratante, Cláusulas)
EVENTO: (ID de Evento, Numero de Contrato, Fecha del Evento, Tipo de Evento, Hora de inicio, Hora de finalización)
CLAUSULAS: (Cláusula).
1) Primera Forma Normal (1FN).
1.a) CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
La tabla cliente cumple con que cada atributo tiene un solo valor para cada registro.
1.b) CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas). La tabla contrato cumple con que cada atributo tiene un solo valor para cada registro.
1.c) EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Tipo de Evento, Hora de inicio, Hora de finalización)
La tabla evento cumple con que cada atributo tiene un solo valor para cada registro.
1.d) CLAUSULAS: (Cláusula). La tabla cláusula cumple con que cada atributo tiene un solo valor para cada registro.
1.e) TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento). La tabla tipo de evento cumple con que cada atributo tiene un solo valor para cada registro.
1.f) FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización). La tabla de fecha cumple con que cada atributo tiene un solo valor para cada registro.
2) Primera Forma Normal (2FN). Todo atributo no llave depende completamente de la llave primaria.
2.a) CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
La tabla cliente cumple con que todo atributo no llave depende completamente de la llave primaria.
2.b) CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas). La tabla contrato cumple con que atributo no llave depende completamente de la llave primaria.
2.c) EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Tipo de Evento, Clave de Tipo de Evento, Hora de inicio, Hora de finalización) el atributo tipo de evento no depende del atributo clave, por eso se creo la tabla e de tipos de evento con el atributo Clave de Tipo de Evento que si depende del atributo clave, además, se creo esta tabla por que cada registro tipo de evento será único y predeterminado.
2.d) CLAUSULAS: (Cláusula). La tabla cláusula cumple con que cada atributo no llave depende completamente de la llave primaria.
2.e) TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento). La tabla tipo de evento cumple con que cada atributo no llave depende completamente de la llave primaria.
2.f) FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización). La tabla de fecha cumple con que cada atributo no llave depende completamente de la llave primaria.
3) Primera Forma Normal (3FN). Todo atributo no llave debe ser independiente de los otos atributos no llave.
3.a) CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
La tabla cliente cumple con que cada atributo tiene un solo valor para cada registro.
3.b) CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas). La tabla contrato cumple con que cada atributo tiene un solo valor para cada registro.
3.c) EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Clave de Tipo de Evento, Hora de inicio, Hora de finalización)
Los atributos hora de inicio y hora de finalización de la tabla evento dependen de la fecha del evento, por lo que se crea la tabla f fecha para cumplir con que cada atributo no llave no tenga depende transitiva.
3.d) CLAUSULAS: (Cláusula). La tabla cláusula cumple con que cada atributo tiene un solo valor para cada registro.
3.e) TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento). La tabla tipo de evento cumple con que cada atributo tiene un solo valor para cada registro.
3.f) FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización). La tabla de fecha cumple con que cada atributo tiene un solo valor para cada registro.
Distribución final:
CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas).
EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Clave de Tipo de Evento)
CLAUSULAS: (Cláusula).
TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento).
FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización).
Definición de tablas “B-D” de SICI (Sistema Informático de Contratos por Internet)
Desarrollo:
Después de considerar las facilidades de Microsoft Access, como la posibilidad de manejar datos de tipo fecha y de tipo hora, las entidades y sus relaciones quedaron como se muestra en la siguiente tabla.
1. Estructura de la base de datos.
2. Datos cargados en las tablas:
3. Formularios
4. Reportes
1. ¿Cual es el nombre de su empresa?
Cliente: “Siblings Roar Sound”
2. ¿Cuál es el giro de su empresa?
Cliente: nos dedicamos a la musicalización de eventos sociales; es decir somos, como popularmente nos llaman, un sonido.
3. ¿Cuál es su función dentro de la empresa?
Cliente: Soy el propietario y administrador, el encargado de la logística, servicio técnico, ventas y publicidad.
4. ¿Cuantos empleados tiene y a que se dedica cada uno?
Cliente: Tengo a tres o mas personas bajo mi mando, una de ellas es mi socio, quien aporta la mitad de mitad del equipo en los eventos y es el encargado, la mayoría de las veces, de las relaciones publicas y contratos. Los otros dos son cargadores e instaladores o staff, que son empleados temporales y que muchas veces varían.
5. ¿Cómo es la operación, manual o automatizada?
Cliente: Totalmente manual.
6. ¿Cuáles son los problemas mas comunes?
Cliente: La falta de energía eléctrica que se soluciona contratando a una persona que presta el servicio de un generador, necesito tener a la mano su teléfono el cual esta apuntado en una agenda.
Descomposturas en el equipo, que se soluciona llamando a un técnico del cual tengo su número telefónico guardado de igual manera en la libretita (agenda).
Transporte, necesito solo en ocasiones contratar un transportista al cual contacto por teléfono (anotado en la misma agenda).
7. ¿Qué información le gustaría tener a salvo y al instante en un sistema informático?
Cliente: Los contratos, que estos además puedan llenarlos los clientes desde Internet.
Manuales de uso de cada aparato, en caso de fallas o contrataciones de DJ de último minuto que no sepan usar nuestro equipo.
Los datos completos de mis clientes pasados para ofrecerles promociones, y que además pueda agregar sus sugerencias y opiniones en texto.
Los datos de empleados eventuales para contratarlos nuevamente en el momento que los necesite.
Y los de varios transportistas para contratar el servicio que este disponible.
Si voy a hacer uso de un equipo de cómputo, que este tenga y organice mi música, para dejar de usar discos.
Que soporte un mapa de la ciudad (estilo Guía Roji) para localizar el lugar del evento.
Algo que me seria muy útil es una página Web que contenga los datos de mi empresa y pueda realizar un contrato en línea con depósito en el banco.
8. ¿Cómo es un día normal de operaciones?
Cliente: Primero el cliente me contacta por teléfono y pregunta por nuestros precios, el cliente acepta la tarifa y nos aparta la fecha del evento para no tener dos eventos el mismo día y lo apunto en la agenda-calendario.
Luego el cliente me da su dirección, lo visito y hago que firme el contrato, recibo un adelanto del 50% en efectivo.
Contrato por llamada telefónica a los “cargadores” (empleados eventuales), y al transportista.
Llegado el día del evento cobro el resto del pago y comienzo la instalación del equipo.
Durante el evento es constante el cambio de discos para poner canciones varias que están catalogadas por género.
Al final compruebo la conformidad de mi cliente con el servicio y me retiro.
Propuestas de solución a los requerimientos del cliente:
1. A las necesidades del cliente de mantener almacenada la música en su computadora y desde ahí ejecutarla, en sus eventos musicales, se recomienda una solución comercial que cuenta con una interfaz gráfica apropiada para un DJ, desarrollada por la compañía Sun Microsystems.
Este software se llama “UltraMixer” que puede ser descargado de la siguiente página web: http://www.ultramixer.com/index.php?c=cHJvZHVjdHM=; y cuenta con tres diferentes versiones con sus respectivas características y costos.
UltraMixer Advanced Edition, que tiene un costo de $219 usd, es la versión mas completa, puede reproducir archivos en MP3, WMA, OGG, WAV y hasta CD’s en tiempo real y cuenta con un controlador de puerto y formato MIDI para entrada y salida de sonido. Herramienta de uso profesional y licenciada para eventos masivos comerciales o privados.
UltraMixer Basic Edition, Una versión menos robusta que con menos funciones; pero que permite las básicas de reproducción y mezcla de archivos MP3, WMA, OGG y WAV. Su licencia de tipo no comercial tiene un costo de $99 USD.
UltraMixer Free Edition, Es una versión mas restrictiva pero de licencia gratuita.
Se distribuye la versión gratuita de este software al usuario para su evaluación.
2. Para la agenda electrónica que permita almacenar los datos personales de los clientes, empleados y transportistas puede usarse la agenda proporcionada gratuitamente por el correo electrónico Yahoo (http://mx.yahoo.com/), así como opcines freeware como: Ajour V5.63 (http://www.micro-sys.dk/) una opción practica, funcional y en español;
Aztec Contact Manager V. 1.2.01 (http://www.aztec.f9.co.uk/) Es una agenda que permite guardar eventos y genera una notificación o alarma con el sonido que el usuario prefiera, no contiene calendario pero contiene una lista de alarmas, y es necesario soportar ventanas con publicidad.
eQit (http://www.eqdigital.co.uk) es una herramienta parecida a la de Aztec, solo que es un poco mas compleja y con mas vista. Incluye herramientas extras como atajos a programas principales y programas de usuario, la alarma no es funcional.
De los software anteriores se le proporcionó una copia al usuario para que él los evalue.
3. Para la parte de contratos y cobranza se propone el desarrollo de un sistema informático que permita las altas de clientes y sus datos personales, el llenado de contratos, guardar datos de los pagos realizado por medio de deposito bancario y por ende la generación de “eventos musicales”, que contengan la fecha, el tipo de evento y los datos relacionados con estos. La finalidad de este sistema, es que estos datos puedan ser llenados por el cliente a través de Internet. Para lograr este objetivo el sistema estará basado en los siguientes diagramas.
Este sistema será identificado de ahora en adelante en este proyecto como SiCI (Sistema de Contratos por Internet).
Nota: al referirse a contratos se hace alusión a los contratos efectuados entre el usuario de este sistema y su cliente, no para los contratos dados entre el usuario y sus empleados o transportistas resuelto en el punto 2.
Definición de tablas “B-D” de SiCI (Sistema de Contratos por Internet)
Normalización de las tablas.
Distribución original:
CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TelefonoMovil, Dirección, E-mail)
CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, Contratante, Cláusulas)
EVENTO: (ID de Evento, Numero de Contrato, Fecha del Evento, Tipo de Evento, Hora de inicio, Hora de finalización)
CLAUSULAS: (Cláusula).
1) Primera Forma Normal (1FN).
1.a) CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
La tabla cliente cumple con que cada atributo tiene un solo valor para cada registro.
1.b) CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas). La tabla contrato cumple con que cada atributo tiene un solo valor para cada registro.
1.c) EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Tipo de Evento, Hora de inicio, Hora de finalización)
La tabla evento cumple con que cada atributo tiene un solo valor para cada registro.
1.d) CLAUSULAS: (Cláusula). La tabla cláusula cumple con que cada atributo tiene un solo valor para cada registro.
1.e) TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento). La tabla tipo de evento cumple con que cada atributo tiene un solo valor para cada registro.
1.f) FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización). La tabla de fecha cumple con que cada atributo tiene un solo valor para cada registro.
2) Primera Forma Normal (2FN). Todo atributo no llave depende completamente de la llave primaria.
2.a) CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
La tabla cliente cumple con que todo atributo no llave depende completamente de la llave primaria.
2.b) CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas). La tabla contrato cumple con que atributo no llave depende completamente de la llave primaria.
2.c) EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Tipo de Evento, Clave de Tipo de Evento, Hora de inicio, Hora de finalización) el atributo tipo de evento no depende del atributo clave, por eso se creo la tabla e de tipos de evento con el atributo Clave de Tipo de Evento que si depende del atributo clave, además, se creo esta tabla por que cada registro tipo de evento será único y predeterminado.
2.d) CLAUSULAS: (Cláusula). La tabla cláusula cumple con que cada atributo no llave depende completamente de la llave primaria.
2.e) TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento). La tabla tipo de evento cumple con que cada atributo no llave depende completamente de la llave primaria.
2.f) FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización). La tabla de fecha cumple con que cada atributo no llave depende completamente de la llave primaria.
3) Primera Forma Normal (3FN). Todo atributo no llave debe ser independiente de los otos atributos no llave.
3.a) CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
La tabla cliente cumple con que cada atributo tiene un solo valor para cada registro.
3.b) CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas). La tabla contrato cumple con que cada atributo tiene un solo valor para cada registro.
3.c) EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Clave de Tipo de Evento, Hora de inicio, Hora de finalización)
Los atributos hora de inicio y hora de finalización de la tabla evento dependen de la fecha del evento, por lo que se crea la tabla f fecha para cumplir con que cada atributo no llave no tenga depende transitiva.
3.d) CLAUSULAS: (Cláusula). La tabla cláusula cumple con que cada atributo tiene un solo valor para cada registro.
3.e) TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento). La tabla tipo de evento cumple con que cada atributo tiene un solo valor para cada registro.
3.f) FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización). La tabla de fecha cumple con que cada atributo tiene un solo valor para cada registro.
Distribución final:
CLIENTE: (ID del cliente., Password, Nombre(s), Apellidos, TeléfonoCasa, TeléfonoMovil, Dirección, E-mail)
CONTRATO: (Numero de contrato, Fecha del Contrato, Horas contratadas, Costo del Servicio, Deposito Bancario, ID del cliente, Cláusulas).
EVENTO: (ID de Evento, Número de Contrato, Fecha del Evento, Clave de Tipo de Evento)
CLAUSULAS: (Cláusula).
TIPO DE EVENTO: (Clave de tipo de evento, Tipo de Evento).
FECHA: (Día, Mes, Año, Hora de inicio, Hora de finalización).
Definición de tablas “B-D” de SICI (Sistema Informático de Contratos por Internet)
Desarrollo:Después de considerar las facilidades de Microsoft Access, como la posibilidad de manejar datos de tipo fecha y de tipo hora, las entidades y sus relaciones quedaron como se muestra en la siguiente tabla.
1. Estructura de la base de datos.
2. Datos cargados en las tablas:
3. Formularios
4. Reportes
viernes, 13 de junio de 2008
MOPROSOFT
NYCE (Normalización y Certificación Electrónica A. C.), es una asociación civil sin fines de lucro creada en noviembre de 1994 por un grupo de empresas líderes de los sectores de Electrónica, Telecomunicaciones y Tecnologías de Información de México, convencidas de la necesidad de contar con un organismo de jurisdicción nacional que tomara en cuenta sus necesidades, en la certificación del cumplimiento con las Normas Oficiales Mexicanas aplicables a los productos de la rama.
NYCE nace al amparo de la Ley Federal sobre Metrología y Normalización ( LFMN ) , que promulgada en 1992 conformándose como un organismo privado que realiza actividades de certificación y verificación, las cuales anteriormente sólo eran llevadas a cabo por dependencias gubernamentales.
NYCE forma parte del Sistema Mexicano de Metrología, Normalización y Evaluación de la Conformidad (SISMENEC), que está integrado por organizaciones de tercera parte, de normalización, de certificación de producto, de certificación de sistemas, de certificación de personas, de verificación, de pruebas, de metrología y de acreditación, así como por las dependencias que conforme a la propia LFMN deben abocarse a estos aspectos.
La norma NMX-I-059-NYCE-2005 (MoProSoft) tiene su origen en el Programa para el Desarrollo de la Industria del Software (PROSOFT). Plan de la Secretaría de Economía Mexicana que forma parte del Plan Nacional de Desarrollo 2001-2006. PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos". Al comenzar el desarrollo de esta línea estratégica se evaluó la adopción de los modelos: ISO 9000, ISO 15504, SW-CMM. Determinando que estos estándares o modelos no cumplen con los requisitos de la industria nacional, y se decidió elaborar un modelo adecuado para las características de las empresas mexicanas, que se basaría en los modelos evaluados.
La Secretaría de Economía encargó la elaboración de dicho modelo a la Asociación Mexicana para la Calidad en Ingeniería de Software (AMSIS) en colaboración con la Universidad Nacional Autónoma de México (UNAM), creando la norma NMX-I-059-NYCE-2005 con base en el modelo MoProSoft y especificando el método de evaluación.
Actualmente NYCE A.C. es el único organismo acreditado para la verificación de la conformidad y certificación de evaluadores de esta norma, por medio de su unidad de Verificación de Tecnologías de Información.
Parte de la labor de NYCE es masificar o difundir el conocimiento y uso esta norma, para lo cual desarrollo un curso e-learning (http://tecnyceweb.coursehost.com) dirigido a estudiantes del área de software y personal de empresas dedicadas al desarrollo y mantenimiento de software, logrando además involucrar a los participantes en el contexto de los modelos de capacidades de software, dando a conocer las generalidades de su implementación y verificación.
NMX-I-059-NYCE-2005
En la norma se pone en claro su lineamiento con base en los siguientes criterios:
· La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por las organizaciones de la industria del software (alta dirección, gestión y operación)
· La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotor del buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua del modelo.
· El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización.
· El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software.
· El modelo integra con claridad y consistencia los elementos indispensables para la definición de los procesos y las relaciones entre ellos.
· El modelo integra los elementos para realizar la administración de proyectos desde un sólo proceso.
· El modelo integra los elementos para realizar la ingeniería de productos de software en un único marco que incluya los procesos precisos de soporte (verificación, validación, documentación y control de la documentación)
· El modelo destaca la importancia de la gestión de recursos, con especial relevancia en aquellos que componen el conocimiento de la organización: productos generados por proyectos, datos de los proyectos, mediciones, documentación de procesos y datos cosechados a partir del uso y de las lecciones aprendidas.
· Moprosoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de procesos de los niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y conceptos de PMBOKY SWEBOK.
De los cuales se desprenden las siguientes categorías que son los elementos a evaluar dentro de la empresa.
Ø Categoría alta dirección (DIR)
Gestión de negocio
Ø Categoría Gerencia (GER)
Gestión de procesos
Gestión de proyectos
Gestión de recursos
Recursos humanos y ambiente de trabajo
Bienes servicios e infraestructura
Conocimiento de la organización
Ø Categoría Operación (OPE)
Administración de proyectos específicos
Desarrollo y mantenimiento de software
Categoría de alta dirección (DIR) Aborda las prácticas de la alta dirección relativas a la gestión del negocio. Proporciona alineación a los procesos de la categoría de gerencia (GER) y se retroalimenta de la información que éstos generan.
Categoría de Gerencia (GER) Aborda las prácticas de gestión de procesos, proyectos y recursos en función de las alineaciones establecidas a través de los procesos de alta dirección (DIR). Proporciona los elementos para el funcionamiento de los procesos de la siguiente categoría (Operación), recibe y evalúa la información que generan, y comunica los resultados a los procesos de alta dirección.
Categoría de Operación (OPE) Aborda las prácticas para los proyectos de desarrollo y mantenimiento de software. Los procesos de esta categoría realizan las actividades de acuerdo con los elementos proporcionados por los de gerencia, y remite a ésta la información y los productos generados.
Conclusión:
La norma NMX-I-059-NYCE-2005 (MoProSoft) es el resultado de un proyecto muy ambicioso y un tanto precipitado que surgió de la presión que la secretaria de economía tenia fijada en el plan nacional de desarrollo 01-06 que consistía en la construcción de una economía solida y mas competitiva impulsando a todos los sectores de la producción incluidos el de servicios, donde se ubica el desarrollo de sistemas informáticos, el proyecto fue finalizado, entregado y reconocido como norma oficial justo un año antes del cambio de administración.
La norma se encuentra en su etapa de difusión con la esperanza de lograr los objetivos de hacer más competitiva la industria mexicana de Sistemas de Información.
NYCE nace al amparo de la Ley Federal sobre Metrología y Normalización ( LFMN ) , que promulgada en 1992 conformándose como un organismo privado que realiza actividades de certificación y verificación, las cuales anteriormente sólo eran llevadas a cabo por dependencias gubernamentales.
NYCE forma parte del Sistema Mexicano de Metrología, Normalización y Evaluación de la Conformidad (SISMENEC), que está integrado por organizaciones de tercera parte, de normalización, de certificación de producto, de certificación de sistemas, de certificación de personas, de verificación, de pruebas, de metrología y de acreditación, así como por las dependencias que conforme a la propia LFMN deben abocarse a estos aspectos.
La norma NMX-I-059-NYCE-2005 (MoProSoft) tiene su origen en el Programa para el Desarrollo de la Industria del Software (PROSOFT). Plan de la Secretaría de Economía Mexicana que forma parte del Plan Nacional de Desarrollo 2001-2006. PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos". Al comenzar el desarrollo de esta línea estratégica se evaluó la adopción de los modelos: ISO 9000, ISO 15504, SW-CMM. Determinando que estos estándares o modelos no cumplen con los requisitos de la industria nacional, y se decidió elaborar un modelo adecuado para las características de las empresas mexicanas, que se basaría en los modelos evaluados.
La Secretaría de Economía encargó la elaboración de dicho modelo a la Asociación Mexicana para la Calidad en Ingeniería de Software (AMSIS) en colaboración con la Universidad Nacional Autónoma de México (UNAM), creando la norma NMX-I-059-NYCE-2005 con base en el modelo MoProSoft y especificando el método de evaluación.
Actualmente NYCE A.C. es el único organismo acreditado para la verificación de la conformidad y certificación de evaluadores de esta norma, por medio de su unidad de Verificación de Tecnologías de Información.
Parte de la labor de NYCE es masificar o difundir el conocimiento y uso esta norma, para lo cual desarrollo un curso e-learning (http://tecnyceweb.coursehost.com) dirigido a estudiantes del área de software y personal de empresas dedicadas al desarrollo y mantenimiento de software, logrando además involucrar a los participantes en el contexto de los modelos de capacidades de software, dando a conocer las generalidades de su implementación y verificación.
NMX-I-059-NYCE-2005
En la norma se pone en claro su lineamiento con base en los siguientes criterios:
· La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por las organizaciones de la industria del software (alta dirección, gestión y operación)
· La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotor del buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua del modelo.
· El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización.
· El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software.
· El modelo integra con claridad y consistencia los elementos indispensables para la definición de los procesos y las relaciones entre ellos.
· El modelo integra los elementos para realizar la administración de proyectos desde un sólo proceso.
· El modelo integra los elementos para realizar la ingeniería de productos de software en un único marco que incluya los procesos precisos de soporte (verificación, validación, documentación y control de la documentación)
· El modelo destaca la importancia de la gestión de recursos, con especial relevancia en aquellos que componen el conocimiento de la organización: productos generados por proyectos, datos de los proyectos, mediciones, documentación de procesos y datos cosechados a partir del uso y de las lecciones aprendidas.
· Moprosoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de procesos de los niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y conceptos de PMBOKY SWEBOK.
De los cuales se desprenden las siguientes categorías que son los elementos a evaluar dentro de la empresa.
Ø Categoría alta dirección (DIR)
Gestión de negocio
Ø Categoría Gerencia (GER)
Gestión de procesos
Gestión de proyectos
Gestión de recursos
Recursos humanos y ambiente de trabajo
Bienes servicios e infraestructura
Conocimiento de la organización
Ø Categoría Operación (OPE)
Administración de proyectos específicos
Desarrollo y mantenimiento de software
Categoría de alta dirección (DIR) Aborda las prácticas de la alta dirección relativas a la gestión del negocio. Proporciona alineación a los procesos de la categoría de gerencia (GER) y se retroalimenta de la información que éstos generan.
Categoría de Gerencia (GER) Aborda las prácticas de gestión de procesos, proyectos y recursos en función de las alineaciones establecidas a través de los procesos de alta dirección (DIR). Proporciona los elementos para el funcionamiento de los procesos de la siguiente categoría (Operación), recibe y evalúa la información que generan, y comunica los resultados a los procesos de alta dirección.
Categoría de Operación (OPE) Aborda las prácticas para los proyectos de desarrollo y mantenimiento de software. Los procesos de esta categoría realizan las actividades de acuerdo con los elementos proporcionados por los de gerencia, y remite a ésta la información y los productos generados.
Conclusión:
La norma NMX-I-059-NYCE-2005 (MoProSoft) es el resultado de un proyecto muy ambicioso y un tanto precipitado que surgió de la presión que la secretaria de economía tenia fijada en el plan nacional de desarrollo 01-06 que consistía en la construcción de una economía solida y mas competitiva impulsando a todos los sectores de la producción incluidos el de servicios, donde se ubica el desarrollo de sistemas informáticos, el proyecto fue finalizado, entregado y reconocido como norma oficial justo un año antes del cambio de administración.
La norma se encuentra en su etapa de difusión con la esperanza de lograr los objetivos de hacer más competitiva la industria mexicana de Sistemas de Información.
CREACION DE BASE DE DATOS EN MYSQL
Definición del problema: La fiesta nacional.
Una asociación de ámbito nacional de aficionados a la Fiesta Nacional –Las lidias de los toros- desea desarrollar un sistema de información que permita tener informados a sus afiliados, tanto de los festejos taurinos que se van a producir en cada temporada, como los ya realizados en temporadas precedentes.
Es interesante, para esta asociación, mantener información de las plazas en las que se realizan festejos taurinos, los toreros que intervinieron o van a intervenir, las cuadrillas de subalternos, los premios que obtuvieron, los toros que se lidiaron, las ganaderías participantes, etc. En definitiva toda la información correspondiente y relevante en cada uno de estos acontecimientos, tanto en lo referente a la fiesta en sí, como el precio de las entradas y asistencia de público a los mismos.
Se trata de un problema complejo en el cual se necesita la introducción de siguientes supuestos semánticos para definirlos más claramente.
Supuesto 1: Se van a considerar únicamente las fiestas taurinas que se celebran en México, en cualquier localidad del territorio nacional, y no aquellas que se celebren o puedan celebrar fuera de nuestras fronteras.
Supuesto 2: Solo interesa conocer aquellas plazas, ganaderías, toreros y subalterno0s que hayan participado en alguna fiesta sobre la cual se tenga información.
Supuesto 3: Cada plaza de toros tiene asignada una categoría, tiene un nombre único, está ubicada en una localidad y tiene un aforo y un apoderado que la dirige.
Supuesto 4: El aforo de la plaza está dividido, en cada una de ellas, por zonas, de forma que los asientos o localidades de cada zona tienen, en cada festejo, un precio determinado. Generalmente, las zonas son de sol y sombra, y dentro de estas, existe división en función de la distancia del asiento a la arena en la que se realiza la lidia de toros.
Supuesto 5: Las fiestas pueden ser de varias categorías: toros, novillos con o sin picador, rejoneo y mixtas, pudiendo variar en cada una de ellas el número de reces que se lidian y el numero de matadores que intervienen.
Supuesto 6: El número de ganaderías que presentan los toros en cada fiesta puede variar de una fiesta a otra.
Supuesto 7: Una res pertenece a una sola ganadería. Cada res tiene asignado un nombre por la ganadería, aun que distintas ganaderías pueden dar el mismo nombre a sus reses. No es usual que una ganadería repita el nombre que le asigna a las suyas.
Supuesto 8: Cada res tiene asignado un número que puede repetirse en reses lidiadas en distintas plazas. Cuando se lidia una res, es interesante conocer su peso, color y una serie de características que aportan información sobre su nobleza y su bravura.
Supuesto 9: Cada ganadería tiene un nombre único, pertenece a un único propietario o sociedad, tiene unos colores o enseña y un hierro diferente para marcar sus reses.
Supuesto 10: Cada matador tiene una cuadrilla de subalternos que participan con él en la lidia de las reses. Los subalternos están catalogados en banderilleros, quitadores y picadores. Un matador puede tener, en su cuadrilla, un número variable de subalternos de cada tipo, siendo interesante conocer la cuadrilla actual de cada matador así como la que participó con él en las fiestas sobre las que se tiene información, pues en ocasiones, no es la cuadrilla actual.
Supuesto 11: En cada fiesta un matador puede lidiar un número variable de reses, alcanzado, o no, un premio en cada una de las lidias que realiza. Los premios más usuales que se les da a los toreros son: pitos, silencio (no son premios muy buenos), aplausos, vuelta al ruedo, petición de oreja, oreja, dos orejas, dos orejas y rabo, entre otros. Además, por la labor global en la fiesta, a los matadores se les puede sacar a hombros y por la puerta grande de la plaza como premio.
Supuesto 12: Cada matador tiene un apoderado, que gestiona las apariciones del mismo. Los subalternos no tienen apoderado.
Supuesto 12+1: No se celebra el mismo día mas de una lidia de toros en una misma plaza, aun que sí en plazas diferentes.
Supuesto 14: El número máximo de reses que se puede lidiar en una fiesta es seis. Si excepcionalmente se lidiaran más, se deberá tener información del resto de los toros.
Supuesto 15: Aunque solo se lidien seis reses en una fiesta, es necesario conocer información sobre las reses sobreras o reservas que están disponibles, y a veces, se lidian en sustitución de las reses principales.
Supuesto 16: Las reses de reserva que no se lidien en una fiesta pueden ser lidiadas, o ser sobreras, o no, en alguna otra fiesta. Las reses que sean lidiadas en una fiesta, no se lidiaran en ninguna otra aunque no se les haya dado muerte.
PSEUDOCODIGO
INSTALACION DE MYSQL PARA PROGRAMAR BD
INICIO DE PROGRAMACION EN MYSQL
ENTIDADES CREADAS EN MYSQL
Una asociación de ámbito nacional de aficionados a la Fiesta Nacional –Las lidias de los toros- desea desarrollar un sistema de información que permita tener informados a sus afiliados, tanto de los festejos taurinos que se van a producir en cada temporada, como los ya realizados en temporadas precedentes.
Es interesante, para esta asociación, mantener información de las plazas en las que se realizan festejos taurinos, los toreros que intervinieron o van a intervenir, las cuadrillas de subalternos, los premios que obtuvieron, los toros que se lidiaron, las ganaderías participantes, etc. En definitiva toda la información correspondiente y relevante en cada uno de estos acontecimientos, tanto en lo referente a la fiesta en sí, como el precio de las entradas y asistencia de público a los mismos.
Se trata de un problema complejo en el cual se necesita la introducción de siguientes supuestos semánticos para definirlos más claramente.
Supuesto 1: Se van a considerar únicamente las fiestas taurinas que se celebran en México, en cualquier localidad del territorio nacional, y no aquellas que se celebren o puedan celebrar fuera de nuestras fronteras.
Supuesto 2: Solo interesa conocer aquellas plazas, ganaderías, toreros y subalterno0s que hayan participado en alguna fiesta sobre la cual se tenga información.
Supuesto 3: Cada plaza de toros tiene asignada una categoría, tiene un nombre único, está ubicada en una localidad y tiene un aforo y un apoderado que la dirige.
Supuesto 4: El aforo de la plaza está dividido, en cada una de ellas, por zonas, de forma que los asientos o localidades de cada zona tienen, en cada festejo, un precio determinado. Generalmente, las zonas son de sol y sombra, y dentro de estas, existe división en función de la distancia del asiento a la arena en la que se realiza la lidia de toros.
Supuesto 5: Las fiestas pueden ser de varias categorías: toros, novillos con o sin picador, rejoneo y mixtas, pudiendo variar en cada una de ellas el número de reces que se lidian y el numero de matadores que intervienen.
Supuesto 6: El número de ganaderías que presentan los toros en cada fiesta puede variar de una fiesta a otra.
Supuesto 7: Una res pertenece a una sola ganadería. Cada res tiene asignado un nombre por la ganadería, aun que distintas ganaderías pueden dar el mismo nombre a sus reses. No es usual que una ganadería repita el nombre que le asigna a las suyas.
Supuesto 8: Cada res tiene asignado un número que puede repetirse en reses lidiadas en distintas plazas. Cuando se lidia una res, es interesante conocer su peso, color y una serie de características que aportan información sobre su nobleza y su bravura.
Supuesto 9: Cada ganadería tiene un nombre único, pertenece a un único propietario o sociedad, tiene unos colores o enseña y un hierro diferente para marcar sus reses.
Supuesto 10: Cada matador tiene una cuadrilla de subalternos que participan con él en la lidia de las reses. Los subalternos están catalogados en banderilleros, quitadores y picadores. Un matador puede tener, en su cuadrilla, un número variable de subalternos de cada tipo, siendo interesante conocer la cuadrilla actual de cada matador así como la que participó con él en las fiestas sobre las que se tiene información, pues en ocasiones, no es la cuadrilla actual.
Supuesto 11: En cada fiesta un matador puede lidiar un número variable de reses, alcanzado, o no, un premio en cada una de las lidias que realiza. Los premios más usuales que se les da a los toreros son: pitos, silencio (no son premios muy buenos), aplausos, vuelta al ruedo, petición de oreja, oreja, dos orejas, dos orejas y rabo, entre otros. Además, por la labor global en la fiesta, a los matadores se les puede sacar a hombros y por la puerta grande de la plaza como premio.
Supuesto 12: Cada matador tiene un apoderado, que gestiona las apariciones del mismo. Los subalternos no tienen apoderado.
Supuesto 12+1: No se celebra el mismo día mas de una lidia de toros en una misma plaza, aun que sí en plazas diferentes.
Supuesto 14: El número máximo de reses que se puede lidiar en una fiesta es seis. Si excepcionalmente se lidiaran más, se deberá tener información del resto de los toros.
Supuesto 15: Aunque solo se lidien seis reses en una fiesta, es necesario conocer información sobre las reses sobreras o reservas que están disponibles, y a veces, se lidian en sustitución de las reses principales.
Supuesto 16: Las reses de reserva que no se lidien en una fiesta pueden ser lidiadas, o ser sobreras, o no, en alguna otra fiesta. Las reses que sean lidiadas en una fiesta, no se lidiaran en ninguna otra aunque no se les haya dado muerte.
PSEUDOCODIGO
INSTALACION DE MYSQL PARA PROGRAMAR BD
INICIO DE PROGRAMACION EN MYSQL
ENTIDADES CREADAS EN MYSQL
lunes, 2 de junio de 2008
Suscribirse a:
Entradas (Atom)
Entradas
