1. UNIVERSIDAD TECNOLÓGICA DEL ESTADO DE ZACATECAS
UNIDAD ACADÉMICA DE PINOS
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
TEMA:
ESTANDARES Y NORMAS DE CALIDAD EN SITEMAS DE TI
UNIDAD
UNIDAD I. “NORMAS Y ESTÁNDARES EN PROYECTOS DE T.I.”
MATERIA:
SISTEMAS DE CALIDAD EN TI
DOCENTE:
IDS. LUCIA GONZÁLEZ HERNÁNDEZ
ALUMNOS:
CARLOS EDUARDO SÁNCHEZ MARTÍNEZ
ARTURO MORALES RUÍZ
CARRERA:
INGENIERÍA EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
GRADO Y GRUPO
7° CUATRIMESTRE “B”
3. INTRODUCCIÓN
En el presente documento se conocerá los conceptos de estándares y normas y las diferencias de cada uno de ellos, lo que es un norma iso y algunas normas y estándares más importantes que se aplican al desarrollo de software ya que cada una de las normas y estándares nos darán a conocer ciertas reglas a seguir para poder desarrollar software de calidad, hoy en día la calidad es importante para poder satisfacer a los clientes que pidan un sistema de calidad y cada vez hay mucho mayor competitividad en este mundo de la informática lo cual hace que cada uno de los desarrolladores busque opciones del como poder desarrollar software de calidad y en ello se han creado desde hace mucho tiempo atrás los estándares que hoy en día rigen en torno a este mundo para el desarrollo correcto de aplicaciones de calidad cumpliendo con sus normas y parámetros en la que se conseguirá la ansiada calidad, y en este trabajo hablaremos específicamente de estándares y normas aplicados al desarrollo de software y esos son: ISO SPICECMMI, IEEE, PSP, TSP, Moprosoft. Y encontraremos un cuadro comparativo de las normas y estándares más conocidas para el desarrollo de software.
Estándar
Es un conjunto de reglas que deben cumplir los productos, procedimientos o investigaciones que afirmen ser compatibles con el mismo producto. Los estándares ofrecen muchos beneficios, reduciendo las diferencias entre los productos y generando un ambiente de estabilidad, madurez y calidad en beneficio de consumidores e inversores. Los esfuerzos que se están realizando y los ya realizados han perseguido distintos objetivos que van desde la definición de API(Interface de Programación de Aplicaciones), los formatos de los ficheros con la información de parámetros biométricos, la encriptación de la información biométrica, la interacción entre dispositivos biométricos diferentes, etc.
Normas
Son reglas de conductas que nos imponen un determinado modo de obrar o de abstenernos. Las normas pueden ser establecidas desde el propio individuo que se las auto impone, y en este caso son llamadas normas autónomas, como sucede con las éticas o morales. Así, una persona ayuda a un necesitado porque se lo ordena su propia conciencia, y cuyo castigo también es personal, y está dado por el remordimiento.
Una norma es una regla que debe ser respetada y que permite ajustar ciertas conductas o actividades. Las normas se enfocan más en los procesos por los que tienen que pasar los productos y los estándares especifican la calidad con la que debe contar los productos.
4. TABLA COMPARATIVA DE NORMAS Y ESTANDARES DE CALIDAD EN SISTEMAS DE TI
ESTANDAR QUIEN LO NORMALIZA DESCRIPCIÓN VENTAJAS Y BENEFICIOS EJEMPLO DE APLICACIÓN
IEEE 754
IEEE
Es el estándar más extendido para las computaciones en coma flotante, y es seguido por muchas de las mejoras de CPU y FPU. El estándar define formatos para la representación de números en coma flotante (incluyendo el cero) y valores desnormalizados, así como valores especiales como infinito y NaN, con un conjunto de operaciones en coma flotante que trabaja sobre estos valores. También especifica cuatro modos de redondeo y cinco excepciones (incluyendo cuándo ocurren dichas excepciones y qué sucede en esos momentos).
Formato simple de 32 bits de la IEEE 754, con exponente sesgado, con sesgo de 127.
Se utilizan representación para:
Números normalizados positivos.
Números normalizados negativos.
Cero positivo.
Cero negativo.
Infinito positivo.
Infinito negativo.
NaN silencioso.
Estas representaciones no solo se utilizan como resultado de una operación, sino que se los puede utilizar también como operando de cualquiera de las operaciones, como se detallará mas adelante.
El desbordamiento a cero (underflow) se toma, dependiendo
Codifiquemos el número decimal - 118,625 usando el sistema IEEE coma flotante.
Necesitamos obtener el signo, el exponente y la fracción.
Dado que es un número negativo, el bit de signo es "1".
Primero, escribimos el número (sin signo, es decir 118,625) usando notación binaria. Consulta el sistema de numeración binario para ver cómo hacer esto. El resultado es 1110110,101.
Ahora, movamos la coma decimal a la izquierda, dejando sólo un 1 a su izquierda.
1110110,101=1,110110101·26 Esto es un número en coma flotante normalizado.
El significante es la parte a la derecha de la coma decimal, rellenada con ceros a la derecha hasta que obtengamos todos los 23 bits. Es decir
5. del signo, como cero positivo o negativo.
El desbordamiento (overflow) se toma, dependiendo del signo, como infinito positivo o negativo.
No se utilizan bits de guarda
Se utiliza la representación del redondeo al más próximo.
No se utilizan números denormalizados.
11011010100000000000000.
El exponente es 6, pero necesitamos convertirlo a binario y desplazarlo (de forma que el exponente más negativo es 0, y todos los exponentes son solamente números binarios no negativos). Para el formato IEEE coma flotante, el desplazamiento es 127, así es que 6 + 127 = 133. En binario, esto se escribe como 10000101.
Poniendo todo junto:
1 8 23 <-- tamaño en bits
+-+--------+----------- ------------+
|S| Exp | Significante |
|1|10000101|11011010100000000000000|
+-+--------+----------- ------------+
31 30 23 22 0 <-- índice del bit (0 a la derecha)
desplazado +127
ISO/IEC 12207
ISO
ISO/IEC 12207 Information Technology / Software Life Cycle Processes, es el estándar para los procesos de ciclo de vida del software de la organización ISO.
* Integración con otras normas ISO del sector TIC, como son: ISO 27001 de seguridad, ISO 20000 de servicios de IT e ISO 9000. * Utiliza un modelo actualizado y específico del ciclo de vida del software (ISO 12207:2008). * Evalúa por niveles de madurez, la
El método presentado en esta entrada puede ser utilizado en una empresa que es responsable de la creación y el mantenimiento de un producto de software para un cliente. Sobre todo cuando la empresa decide crear una aplicación desde cero y que el
6. evaluación más extendida entre los modelos de mejora. * Normalmente, tiene un menor coste de certificación Entidades certificadoras AENOR PATHFINDER Objetivos generales por lo que las organizaciòn implantan ISO/IEC 15504 y ISO/IEC 12204 •Obtener ventaja competitiva. •Establecer una cultura organizativa. •Aumentar la satisfacción del cliente. •Mejorar la productividad.
mantenimiento y la asistencia en la operación también se realiza por la empresa desarrolladora.
ISO/IEC 20000
ISO
La serie ISO/IEC 20000 - Service Management normalizada y publicada por las organizaciones ISO (International Organization for Standardization) e IEC (International Electrotechnical Commission) el 14 de diciembre de 2005, es el estándar reconocido internacionalmente en gestión de servicios de TI (Tecnologías de la Información). La serie 20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad de normalización británica, la British Standards Institution (BSI).
Demuestra que se tienen procedimientos y controles adecuados in situ para proporcionar un servicio de calidad de TI coherente y a un coste efectivo.
Los suministradores de servicios de TI se han vuelto cada vez más sensibles y responsables con los servicios que prestan más que de la tecnología que puedan proporcionar.
Los proveedores externos de servicios pueden usar la certificación como un elemento diferenciador y acceder a nuevos clientes, ya que esto cada vez más se convierte en una exigencia contractual.
Permite seleccionar, gestionar y proporcionar un servicio externo
Las empresas pueden usar ambas partes como ayuda para desarrollar herramientas para la gestión de los servicios, productos y sistemas en soporte de la gestión de los servicios basados en las mejores prácticas. Es importante tener en cuenta que es virtualmente imposible auditar en forma eficaz según la norma ISO/IEC 20000-1 sin tener un conocimiento y comprensión exhaustivos de la correspondiente ISO/IEC 20000-2. Esta segunda norma establece lineamientos y principios generales y el código de práctica para la GSTI.
7. más efectivo.
Ofrece oportunidades para mejorar la eficiencia, fiabilidad y consistencia de sus servicios de TI que impactan positivamente tanto en los costes como en el servicio.
IEEE 1008
IEEE
El objetivo principal de este estándar es especificar un modo común de realizar las pruebas de unidad al software, el cual puede ser utilizado como base para buenas prácticas de la ingeniería del software. otro objetivo es describir los conceptos de la ingeniería de software y las suposiciones de prueba sobre las que se basa el enfoque de este estándar.
Los destinatarios principales de esta norma, son los testers de unidad y supervisores de unidades de prueba. Este estándar fue desarrollado para ayudar a aquellos que proporcionan la entrada a, ejecutar, supervisar, monitorear y evaluar las pruebas unitarias. AUDIENCIA ANSI / IEEE 829-1983. En él se describe un plan de prueba como: "Un documento que describe el alcance, el enfoque, los recursos y el calendario de actividades de prueba previstos. Identifica los elementos de prueba, las características para ser probadas, las tareas de prueba, que va a hacer cada tarea, y los riesgos que requieren planes de contingencia. " RELACIÓN CON OTROS ESTÁNDARES DE INGENIERÍA DE SOFTWARE Terminología en esta norma es consistente con la norma ANSI / IEEE Std. 729-1983, Norma IEEE Glosario de Terminología de Ingeniería de Software.
Basándose en la información sobre el diseño de la unidad, como se requiere actualizar la arquitectura del conjunto de ensayo, identificar los flujos de control y los cambios en los datos internos que deben ser registrados. Anticipar Dificultades de grabaciones especiales que puedan surgir, por ejemplo, de la necesidad de rastrear el flujo de control en algoritmos complejos o de una necesidad de rastrear los cambios en las estructuras de datos internos (por ejemplo, las pilas o los árboles). Cuando sea necesario, solicitud de mejora de la unidad de diseño (por ejemplo, una estructura de formato de datos de capacidad de volcado) para aumentar la capacidad de prueba de la unidad. 4.5 AUMENTAR, SEGÚN SEA NECESARIO, EL CONJUNTO DE ESPECIFICACIONES DE CASOS DE PRUEBA, BASADO EN LA INFORMACIÓN DE DISEÑO. 5.1 Implement Inputs.
8. POSIX
IEEE
POSIX (Interfaz de sistema operativo portable) es una norma escrita por la IEEE.
Dicha norma define una interfaz estándar del sistema operativo y el entorno, incluyendo un intérprete de comandos (o "shell"), y programas de utilidades comunes para apoyar la portabilidad de las aplicaciones a nivel de código fuente. El nombre POSIX surgió de la recomendación de Richard Stallman, que por aquel entonces en la década de 1980 formaba parte del comité de IEEE.
Una serie de pruebas acompañan al estándar POSIX. Son llamadas "PCTS" en alusión al acrónimo
"Posix Conformance Test Suite". Desde que la IEEE empezó a cobrar altos precios por la documentación de POSIX y se ha negado a publicar los estándares, ha aumentado el uso del modelo Single Unix Specification. Este modelo es abierto, acepta entradas de todo el mundo y está libremente disponible en Internet. Fue creado por The Open Group
Crear un programa con dos hilos
El primer hilo lee un mensaje del teclado, lo escribe en una variable protegida con mutex, y avisa al segundo hilo señalando una variable condicional
El segundo hilo espera en la variable condicional y, cuando es señalizado, lee el mensaje y lo pinta en pantalla
El proceso se repite indefinidamente. Es decir, no se trata de hilos periódicos, sino de que cada hilo se activa una sola vez, y su código consiste en un bucle indefinido.
VHDL
IEEE
Es el acrónimo que representa la combinación de VHSIC y HDL, donde VHSIC es el acrónimo de Very High Speed Integrated Circuit y HDL es a su vez el acrónimo de Hardware Description Language.
Es un lenguaje definido por el IEEE (Institute of Electrical and Electronics Engineers) (ANSI/IEEE 1076-1993) usado por ingenieros para describir circuitos digitales. Otros
Dentro del VHDL hay varias formas con las que podemos diseñar el mismo circuito y es tarea del diseñador elegir la más apropiada.
Funcional: Describimos la forma en que se comporta el circuito. Esta es la forma que más se parece a los lenguajes de software ya que la descripción es secuencial. Estas sentencias secuenciales se encuentran dentro de los llamados procesos en VHDL. Los procesos son ejecutados en paralelo entre sí,
El VHDL permite descripciones que no son sintetizables, es decir, que no se pueden implementar directamente en un circuito electrónico digital. Este tipo de descripciones son útiles en simulación. Un ejemplo de este tipo de descripciones son las que incluyen mensajes que notifican al diseñador si se ha cumplido alguna condición durante la simulación.
El código siguiente mostraría el mensaje "hola mundo" durante la
9. métodos para diseñar circuitos son la captura de esquemas (con herramientas CAD) y los diagramas de bloques, pero éstos no son prácticos en diseños complejos. Otros lenguajes para el mismo propósito son Verilog y ABEL.
Aunque puede ser usado de forma general para describir cualquier circuito se usa principalmente para programar PLD (Programable Logic Device - Dispositivo Lógico Programable), FPGA (Field Programmable Gate Array), ASIC y similares.
y en paralelo con asignaciones concurrentes de señales y con las instancias a otros componentes.
Flujo de datos: describe asignaciones concurrentes (en paralelo) de señales.
Estructural: se describe el circuito con instancias de componentes. Estas instancias forman un diseño de jerarquía superior, al conectar los puertos de estas instancias con las señales internas del circuito, o con puertos del circuito de jerarquía superior.
Mixta: combinación de todas o algunas de las anteriores.
En VHDL también existen formas metódicas para el diseño de máquinas de estados, filtros digitales, bancos de pruebas etc.
simulación:
use std.textio.all; -- bibliotecas
entity hola is
end entity hola;
architecture Wiki of hola is
constant mensaje: string := "hola mundo"; -- el mensaje
begin
process is -- proceso -> secuencial
variable L: line;
begin
write(L, mensaje);
writeline(output, L); -- escribe todo lo anterior
wait;
end process;
end architecture Wiki;
Es importante señalar que esta descripción no es sintetizable en un circuito electrónico digital, y que la descripción equivalente en VHDL al programa Hola Mundo sería encender un led
.
IEEE 1394
IEEE
(conocido como FireWire por Apple Inc. y como i.Link
Alcanza una velocidad de 400 megabits por segundo,
La edición de vídeo digital con IEEE 1394 ha permitido la incorporación
10. por Sony) (pirocable en español) es un tipo de conexión para diversas plataformas, destinado a la entrada y salida de datos en serie a gran velocidad. Suele utilizarse para la interconexión de dispositivos digitales como cámaras digitales y videocámaras a computadoras. Existen cuatro versiones de 4, 6, 9 y 12 pines. Su escasa
manteniéndola de forma bastante estable.
Flexibilidad de la conexión y la capacidad de conectar un máximo de 63 dispositivos.
Acepta longitudes de cable de hasta 425 cm.
Respuesta en el momento. FireWire puede garantizar una distribución de los datos en perfecta sincronía.
Alimentación por el bus de hasta 25 VDC. Existe un tipo de puerto Firewire que no suministra alimentación, tan sólo da servicio de comunicación de datos. Este puerto tiene sólo 4 contactos, en lugar de los 6 que tiene un puerto Firewire alimentado.
Conexiones de enchufar y listo, conocidas como plug & play.
Conexión en caliente (permite conectar dispositivos con el PC encendido).
de FireWire en cámaras de vídeo de bajo costo y elevada calidad lo cual permite la creación de vídeo profesional en las plataformas Macintosh y PC. La interfaz IEEE 1394 permite la captura de vídeo directamente de cámaras de vídeo digital con puertos FireWire incorporados y de sistemas analógicos mediante conversores de audio y vídeo.
IEEE 802.11
IEEE
El estándar 'IEEE 802.11' define el uso de los dos niveles inferiores de la
802.11g tiene la ventaja de poder coexistir con los estándares 802.11a y 802.11b, esto debido a
Suponiendo que se tiene un punto de acceso que trabaja con 802.11g, y actualmente se encuentran
11. arquitectura OSI (capas física y de enlace de datos), especificando sus normas de funcionamiento en una WLAN. Los protocolos de la rama 802.x definen la tecnología de redes de área local y redes de área metropolitana.
que puede operar con las Tecnologías RF DSSS y OFDM. Sin embargo, si se utiliza para implementar usuarios que trabajen con el estándar 802.11b, el rendimiento de la celda inalámbrica se verá afectado por ellos, permitiendo solo una velocidad de transmisión de 22 Mbps. Esta degradación se debe a que los clientes 802.11b no comprenden OFDM.
conectados un cliente con 802.11b y otro 802.11g, como el cliente 802.11b no comprende los mecanismos de envío de OFDM, el cual es utilizados por 802.11g, se presentarán colisiones, lo cual hará que la información sea reenviada, degradando aún más nuestro ancho de banda.
PSP
ISO
El Personal Software Process, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad.
PSP es una metodología basada en estimación. La estimación permite saber cuándo y cómo se desarrollan las tareas de un proceso, por lo que podría citarse como un aspecto importante de esta metodología el estar basada en métricas y estimaciones.
La información de las métricas y estimaciones se utiliza para evaluar y mejorar procesos futuros. PSP parte de la premisa que, si el ingeniero de software conoce sus fortalezas y debilidades, puede establecer las acciones necesarias para erradicar o explotar los aspectos identificados en la forma en que desarrolla software.
TSP
ISO
Team Software Process (TSP) es un método de establecimiento y mejora del trabajo en equipo para
Miembros expertos en papeles de
En este proyecto se aplica TSP (Team Software Process) para el desarrollo de software en el contexto de una metodología
12. procesos software.
liderazgo y pertenencia.
Relaciones tranquilas y establecidas entre los miembros.
Los miembros se sienten atraídos por el grupo y son fieles.
Los valores y metas del grupo son los de sus integrantes.
Los miembros están motivados por hacer lo que puedan por el grupo.
La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro a adquirir su pleno potencial.
Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.
Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
Existe una atmósfera de creatividad.
El grupo conoce el “conformismo constructivo” y se sirve de él.
Existe gran motivación para iniciar y recibir las comunicaciones.
estándar de desarrollo de software, se especifican los fundamentos, técnicas y procesos de TSP, se define el uso de TSP dentro de un proyecto de desarrollo de software y se desarrolla un caso de estudio aplicando la combinación del TSP y del Proceso Unificado de Desarrollo RUP. En el presente trabajo, se crea la combinación de los flujos de RUP (Modelado del Negocio, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Distribución, Gestión de Configuración y Cambios, Gestión de Proyectos y Ambiente) y los procesos de TSP (Lanzamiento del Proyecto de Equipo, Desarrollo de la Estrategia, Desarrollo del Plan, Definición de Requerimientos, Diseño con Equipos, Implementación del Producto, Pruebas de Integración y del Sistema y Postmortem), como resultado se obtienen los flujos: Gestión de Proyectos, Modelado del Negocio, Requerimientos, Análisis, Diseño, Implementación, Pruebas, Postmortem y Distribución. Al desarrollar productos de software utilizando los flujos de la combinación de RUP y TSP se obtendrá como resultado un producto con calidad de manera eficiente.
13. Los miembros son flexibles y adaptables en sus metas y actitudes.
Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al entender la filosofía de la operación.
14. CONCLUSIONES Y RESULTADOS
Gracias a las normas y estándares aplicados a proyectos TI y de calidad para el desarrollo de software hoy en día se nos puede facilitar la realización de los proyectos ya que con las normas podemos seguir ciertos pasos para que los proyectos sean más eficientes y más fáciles de realizarlos paso a paso y los estándares nos especifican que el desarrollo de un proyecto debe ser de calidad, el cual debe satisfacer las necesidades del cliente o de la empresa a la que se le esté desarrollando dicho software. También gracias importantes estándares como el proceso de software personal es de gran ayuda para los ingenieros involucrados en el proyecto ya que les permite mejorar la forma en que trabajan y controlar los tiempos mediante formatos de tiempo para cada una de las actividades y que el software desarrollado sea de calidad. Por otra parte el CMMI nos ayuda a mejorar los procesos de construcción de software y de proyectos de TI, el estándar IEEE nos brinda una serie de documentación el desarrollo de software y proyectos de TI Y el TSP se enfoca más en la mejora de trabajo en equipo para los procesos de software. Por último la aplicación de una norma o estándar los podemos aplicar en nuestros proyectos de acuerdo a la necesidades de dicho proyecto.
BIBLIOGRAFÍA
http://es.wikipedia.org/wiki/VHDL
http://es.wikipedia.org/w/index.php?title=IEEE_830&action=edit&redlink=1
https://www.google.com.mx/search?q=EJEMOLO+DE+USO+DE+TSP&ie=utf-8&oe=utf- 8&aq=t&rls=org.mozilla:es-MX:official&client=firefox-a&channel=fflb&gfe_rd=cr&ei=- 7I8VO7lKoaR8QfykIDwBw#rls=org.mozilla:es- MX:official&channel=fflb&q=EJEMPLO+DE+USO+DE+TSP&spell=1
http://bibdigital.epn.edu.ec/handle/15000/554
http://misaelutec.wordpress.com/caracteristicas-de-los-modelos-cmmipsptsp-e-ieee-para-dante/
http://karron10.wordpress.com/2013/04/14/normas-y-estandares-en-proyectos-de-ti-2/