• No se han encontrado resultados

MAESTRÍA EN SISTEMAS COMPUTACIONALES

N/A
N/A
Protected

Academic year: 2022

Share "MAESTRÍA EN SISTEMAS COMPUTACIONALES"

Copied!
20
0
0

Texto completo

(1)

DI D I RE R EC CC CI ÓN N D DE E P PO OS SG GR RA A DO D O E E I IN NV V ES E ST TI IG GA AC CI ÓN N

M AESTRÍA EN S ISTEMAS C OMPUTACIONALES

M

ATERIA

: C

ONTROLES EN EL

D

ESARROLLO DE

S

ISTEMAS

P

ROFESOR

: M

ARIO

F

ARÍAS

E

LINOS

T

EMA

:

ISO/IEC TR 12182:1998

I

NFORMACIÓN

T

ECNOLÓGICA

– C

ATEGORIZACIÓN DE

S

OFTWARE

Alumnos:

J

UAN

C

ARLOS

A

GUILAR

F

RANCO

A

DRIÁN

G

ÓMEZ

G

ALLARDO

JUNIO DEL 2002

(2)

ULSA 2

INDICE

C

ONTENIDO

P

ÁGINA

1. Introducción 4

2. Alcance

2.1 Campo de Aplicación 5

2.2 Audiencia y Propósito 5

2.3 Limitaciones 5

3. Referencias Normativas 6

4. Términos y Definiciones

4.1 Esquema de Categorización 7

4.2 Vista 7

4.3 Categoría 7

5. Concepto de Categorización de Software

5.1 Estructura de Vistas 8

5.2 Selección de Vistas y Categorías 9

6. Esquema de Categorización

6.1 Función del Software 10

6.2 Área de Aplicación del Sistema de Información 10

6.3 Modo de Operación 11

6.4 Escala de Software 11

6.5 Representación de Datos 11

(3)

ULSA 3

6.6 Lenguaje Primario 12

6.7 Integridad del Software 12

6.8 Tipo de Usuario 13

6.9 Estabilidad del Software 13

6.10 Disponibilidad de productos del Software 13

6.11 Utilización de los datos del Software 14

6.12 Requerimientos de Desempeño 14

6.13 Requerimientos de Seguridad 14

6.14 Requerimientos de Fiabilidad 15

6.15 Sistemas de Cómputo y Ambiente 16

6.16 Requerimientos de Recursos de la Cómputo 16

7. Aplicación del Esquema

7.1 Aplicación al Alcance de los Estándares 17

7.2 Aplicación a Estándares 17

7.3 Aplicación a Paquetes de Software 18

7.4 Ejemplo de Categorización de: Procesador de Texto 18

(4)

ULSA 4

1. I

NTRODUCCIÓN

Este reporte técnico tiene diferentes propósitos que están dirigidos hacia diferentes audiencias: la comunidad de ingenieros en software; los usuarios de los estándares de ingeniería de software, especialmente a aquellos desarrollados mediante ISO/IEC JTC 1/SC 7; y desarrolladores de estándares de ingeniería de software, primordialmente SC 7.

Para la comunidad de ingeniería de software, este documento puede identificar los tipos de software y los estándares específicos de ingeniería de software que son aplicables. Esto puede ayudar al ingeniero de software a establecer el criterio de planeación del riesgo, el modelo de ciclo de vida a aplicar, el esfuerzo específico requerido para las fases específicas del ciclo de vida, y las herramientas necesarias.

Para los usuarios y desarrolladores de estándares de ingeniería de software, puede establecer un marco para discutir e identificar estándares de ingeniería de software candidatos basados en el esquema de categorización de software y para usar el esquema en software relacionado y estándares de ingeniería de software.

Específicamente para SC 7, este documento técnico provee y añade auxilia al posicionamiento de los estándares de ingeniería de software y los temas de trabajo dentro de la estructura del SC 7 y pretende que los nuevos proyectos, trabajos de anteproyectos, comités de anteproyectos, y anteproyectos de estándares internacionales puedan encontrar el objetivo de la categorización relevante en el área de aplicación. Es sobreentendido que en algunos documentos, solo parte de este reporte técnico puede dirigirse específicamente a la categorización.

(5)

ULSA 5

2. A

LCANCE

El alcance de este reporte técnico corresponde a las categorías de software (incluyendo desarrollos relevantes de productos de software y datos) que son producidas mediante procesos de ingeniería de software. Describe un esquema de categorización para el software que abarca diferentes puntos de vista y características significantes y atributos que describen y definen al software y sus categorías.

2.1 Campo de Aplicación

El campo de aplicación de la categorización de software incluye la ingeniería de software y los estándares, software, datos y metodologías asociadas.

2.2 Audiencia y Propósito

Este reporte técnico está primordialmente dirigido hacia diversas audiencias: la comunidad de ingenieros en software; los usuarios de los estándares de ingeniería de software, especialmente a aquellos desarrollados mediante ISO/IEC JTC 1/SC 7; y desarrolladores de estándares de ingeniería de software, primordialmente SC 7.

El propósito del uso de la categorización del software es la identificación de las categorías de software, identificando los estándares de ingeniería para el software y determinando las relaciones de las tareas del software, procesos o productos con los estándares de ingeniería de software.

El uso de la categorización de software está definida como la generación de una entrada justificable para cada elemento del esquema de categorización para el software o en un mapeo del estándar de ingeniería de software. En algunas circunstancias un elemento nulo puede ser apropiado.

2.3 Limitaciones

Desde que la ingeniería de software ha sido un campo sumamente cambiante, los usuarios deben utilizar su juicio cuando sea utilizado a las aplicaciones. El esquema de la categorización es empírico en naturaleza. Su formulación no está basada en necesidades del usuario predefinidas. El esquema no ha sido validado en pruebas de campo.

(6)

ULSA 6

3. R

EFERENCIAS

N

ORMATIVAS

No existen referencias normativas dentro de la Categorización de Software.

(7)

ULSA 7

4. T

ÉRMINOS Y

D

EFINICIONES

Este apartado provee definiciones de los términos utilizados en este reporte técnico. No define conceptos que son explicados en el cuerpo del documento. No define términos que no son específicos tema de la materia y son usados de acuerdo con su uso ordinario en el lenguaje Inglés.

Para los propósitos de este reporte técnico, son aplicables los siguientes términos y definiciones.

4.1 Esquema de Categorización

Combinación ordenada de vistas y categorías relacionadas al software.

4.2 Vista

Juego de categorías relacionadas.

4.3 Categoría

División definida específicamente o agrupamiento de software basado en uno o más atributos o características.

(8)

ULSA 8

5. C

ONCEPTO DE

C

ATEGORIZACIÓN DE

S

OFTWARE

El concepto de la categorización del software está representada gráficamente por la figura 1.

Tal como se aprecia en la figura, la categorización de software está compuesta por un número de vistas de software y cada vista contiene categorías relevantes de la misma. Las diversas vistas serán discutidas en el Esquema de Categorización. La selección de categorías está sujeta a la discrecionalidad del usuario.

Debe hacerse notar que una categoría existe en más de una vista y, en varias instancias, el dominio de una categoría se sobrepone a otra.

5.1 Estructura de Vistas

El Esquema de Categorización consta de 16 vistas. Las vistas deben ser agrupadas de acuerdo a las siguientes categorías:

Internas

o Modo de operación o Escalabilidad del software o Estabilidad del software

Categoría Categoría

Categoría

Software

Vista

Vista

Vista

(9)

ULSA 9 o Funcionalidad

§ Función del software

§ Requerimientos de seguridad o Requerimientos de fiabilidad

o Rendimiento requerido o Lenguaje primario

Ambiente

o Área de aplicación del sistema de información o Sistema de la computadora y ambiente o Clase o tipo de usuario

o Requerimientos de recursos de la computadora o Software crítico

o Disponibilidad de productos de software

Datos

o Representación de datos

o Utilización de los datos del software

5.2 Selección de Vistas y Categorías

Para cualquier instancia dada, como cuando el esquema de categorización es aplicado a otros estándares de ingeniería de software, el uso de todas las vistas puede no ser requerida. En esos casos, una vista o un juego de vistas seleccionadas con categorías específicas puede ser suficiente para caracterizar el software. Para las aplicaciones es deseable incluir para la caracterización del software: estándares específicos de ingeniería de software, selección de estándares de ingeniería de software apropiados, selección de métodos, definición del ciclo de vida, determinación de la estructura del documento y valoración de la calidad.

Cuando sea aplicable el esquema de caracterización a aplicaciones, se deberán utilizar preferentemente todas las vistas relevantes y categorías relacionadas. Por ejemplo, si un software va a ser caracterizado con respecto a su ambiente, se deberán utilizar todas las vistas agrupadas en el juego de ambiente. Dependiendo de las circunstancias particulares de la aplicación, podrá ser necesario incluir vistas adicionales tales como los requerimientos de seguridad o los requerimientos de fiabilidad.

En algunas aplicaciones del esquema de caracterización, la caracterización con respecto a una vista primaria podrá ser suficiente. Por ejemplo, el grado crítico del software puede ser la vista primaria para los estándares de calidad.

Para otros casos de utilización del esquema de categorización, varias vistas con categorías especificas pueden ser combinadas para representar más específicamente las características del software. Por ejemplo, la función del software y clase de usuario deberán ser usadas para determinar la estructura del documento.

(10)

ULSA 10

6. E

SQUEMA DE

C

ATEGORIZACIÓN

Asociado con la descripción de cada vista del esquema de categorización, se encuentra la lista de categorías relevantes de las vistas.

Las categorías relevantes de las vistas no son necesariamente mutuamente exclusivas. Mientras en ciertas aplicaciones solamente una de estas categorías puede aplicar, en otras aplicaciones pueden ser todas aplicables.

De manera similar, las categorías relevante a una vista no están necesariamente al mismo nivel de abstracción.

Los usuarios del esquema de categorización deben aplicar su juicio al momento de seleccionar las categorías apropiadas o relevantes para una determinada aplicación o para un área de aplicación.

6.1 Función del Software

Para la vista de función del software, las categorías deben ser definidas por el tipo de función a la cual está orientada.

Algunos ejemplos de categorías de software con respecto a su función son:

Procesamiento de transacciones de negocios

Compilador

Cálculos científicos

Procesador de texto

Sistemas médicos

Sistemas de control

6.2 Área de Aplicación del Sistema de Información

Para la vista de área de aplicación, las categorías deberán ser definidas por el tipo o clase de sistemas externos en los cuales se encuentra contenido.

Por ejemplo, el software que es un elemento de sistemas de control de procesos deberá ser categorizado como una facilidad de software de control de procesos y el software que es un elemento de un sistema de gestión de redes deberá ser categorizado como un sistema de control de gestión de red.

Ejemplos de las categorías por área de aplicación:

Científica

Aparato casero

(11)

ULSA 11

Equipamiento

Facilidad de control de procesos

Negocios empresariales

Sistemas de gestión de redes

6.3 Modo de Operación

Por la vista de modo de operación, las categorías deberán ser definidas por la técnica de procesamiento específica o por el tipo adoptado por el sistema de software.

Ejemplos de las categorías por modo de operación:

Procesamiento por lotes

Procesamiento en tiempo real

Procesamiento en tiempo compartido

Procesamiento paralelo

Procesamiento concurrente

6.4 Escala de Software

Para la vista de escala de software, las categorías deberán definirse ya sea por el tamaño o por la complejidad del software.

Por ejemplo, el tamaño puede ser determinado por el número de líneas de código excluyendo comentarios y ajustes por el nivel de lenguaje. La complejidad puede determinarse por la complejidad en el flujo de datos.

Ejemplos:

Pequeño

Mediano

Grande

Debe ser entendido que los rangos para estas categorías pueden no ser interpretadas estrictamente.

Las categorías deben considerarse como de rangos aproximados o difusos.

6.5 Representación de Datos

Para la representación de datos, las categorías deberán ser definidas por el tipo de objeto de datos, tipos, y estructuras.

(12)

ULSA 12 Ejemplos:

Secuencial

Relacional

Indexado

Gestión de redes

Objeto

Entidad

Archivo formateado

6.6 Lenguaje Primario

Debido a que el lenguaje primario usado en el desarrollo de software generalmente representa o una influencia significante de características en el software, se deberá proporcionar una indicación del tipo de lenguaje primario.

Ejemplos:

Tradicional (COBOL, FORTRAN, etc.)

Procedural (C o equivalente)

Funcional (Lisp o equivalente)

Orientado a objetos (C++ o equivalente)

6.7 Integridad del Software

Para la vista de integridad del software, las categorías deberán ser definidas por el nivel de integridad del producto con la fuente de la valoración especificada y el significado o implicación de la valoración indicada. Alternativamente, las categorías pueden ser especificadas por el grado de influencia (global, internacional, etc.) o por su impacto en la sociedad (individual, grupo, negocios, etc.) por si el sistema del software falla. La falla del software puede tener implicaciones de seguridad (vida humana, propiedad, etc.) o un propósito (juego, procesador de texto, contabilidad, etc.).

Ejemplos:

Seguridad nacional

Vida humana

Pánico o caos social

Seguridad organizacional

Recursos privados

Privacidad

(13)

ULSA 13

6.8 Tipo de Usuario

Para la vista de tipo de usuario, las categorías deberán ser definidas por el nivel de habilidades o características de las pretensiones de cada clase de usuario.

Un usuario no necesariamente debe de ser un humano.

Ejemplos:

Novato

Intermedio

Experto

Frecuente

Ocasional

Otro sistema de software

Hardware

6.9 Estabilidad del Software

El software debe ser categorizado por sus aspectos evolucionarios intrínsecos, o por su estabilidad, en términos de características de un sistema del cual es parte.

Ejemplos:

Cambio continuo

Cambio incremental

Cambio improbable

6.10 Disponibilidad de productos del Software

Para la vista de disponibilidad de productos del Software, las categorías deberán ser definidas por los tipos de disponibilidad del software.

Ejemplos:

Propietario

Público

Por costumbre

(14)

ULSA 14

Sin existencia

6.11 Utilización de los Datos del Software

Para ver los datos usados, las categorías deben ser definidas por el tipo de uso, para que los datos del software sea pensado.

Los ejemplos de categorías para el uso de los datos son:

• Usuario solo (Individual)

• Múltiples Usuarios secuenciales

• Competencia mutuamente exclusivo

6.12 Requerimientos de desempeño

Para ver los requerimientos del desempeño, las categorías deben ser definidas por la velocidad del software en términos de capacidad, tiempo de respuesta, reapunte, donde cada categoría es el rango según el grado o nivel.

Los ejemplos de categorías para la velocidad requerida son:

• Capacidad o Alta o Media o Baja

• Tiempo de Respuesta o Rápido

o Moderado o Despacio

• Rendimiento total o Pesado o Mediano o Ligero

6.13 Requerimientos de Seguridad

Para ver los requerimientos de la seguridad, el software debe categorizarse por el nivel de protección contra acceso no autorizado, referencia de auditoria y robustez proporcionada.- Pueden especificarse categorías adicionales de requisitos de seguridad.

Los ejemplos de categorías para el requisito de seguridad son:

(15)

ULSA 15 Fuerte Mediano Débil

Protección contra acceso no autorizado

Referencia de auditoría

Protección del programa y datos

6.14 Requerimientos de Fiabilidad

Para ver los requisitos de fiabilidad, el software debe categorizarse por el nivel de fiabilidad requerida incluyendo la madurez, tolerancia a fallas y recobrabilidad.

Los ejemplos de categorías para el requisito de fiabilidad son indicados son:

Fuerte Mediano Débil

Madurez

Tolerancia a fallas

Recobrabilidad

(16)

ULSA 16

6.15 Sistemas de Cómputo y Ambiente

Para ver los sistemas de cómputo, el software debe identificarse con el sistema de cómputo en específico con el cual opera.

Los ejemplos de categorías de sistemas de computación son:

• Microprocesador( Incluyendo estaciones de trabajo y personal, PC portátil )

• Mainframe

• Micro-programación dedicada

• Sistema Operativo

• Sistema de Tiempo Real

6.16 Requerimientos de Recursos de Cómputo

Para ver requisitos de recursos de cómputo, el software debe de identificarse con respecto los requerimientos de cómputo. Pueden declararse en términos de la cantidad requerida.

Ejemplos:

• Requerimientos de la Unidad Central de Procesamiento

• Requerimientos de la Memoria Principal

• Requerimientos de la Memoria Externa

• Requerimientos de Disco

• Requerimientos de un (LAN) Local Area Network

(17)

ULSA 17

7. A

PLICACIÓN DEL

E

SQUEMA

Esta cláusula proporciona ejemplos de esquemas de aplicaciones para la categorización de software a algunas posibles áreas de aplicación.

7.1 Aplicación al Alcance de los Estándares

Pueden desarrollarse normas de la documentación, para especificar Escalas de Software, como para aplicaciones grandes de sistemas (ISO 6592) y para los tipos específicos de Disponibilidad de Software, como el Software empaquetado ( ISO 9127)

7.2 Aplicación a Estándares

En algunos casos, los volúmenes específicos identifican una norma o vistas a aplicaciones específicas o categorías de software. Para ilustrar esto podemos observar en el siguiente cuadro, como se relacionan las seis características contenidas en ( ISO 9126), también se puede observar la categorización. En la Tabla las relaciones se identifican como primario (P) y secundario (S).

Categorización

de vistas Func Relia Usab Effic Maint Port

Software

Function P

Operation

Mode P

Application

Area of IS P S

Scale of

Software P P S

Data

Representation P S

Software

Criticality P S

User Class P

Required

Performance P

Software

Stability P S

Security

Requirement P

Reliability Requierement

Computer

System S P S

Computer S S

(18)

ULSA 18

Categorización

de vistas Func Relia Usab Effic Maint Port

Resource Req.

Software Product Availability

S P S

Usage of Data P S

Primary

language P S P

7.3 Aplicación a paquetes de Software

Una aplicación común del esquema de categorización es para la categorización de paquetes específicos de software. El siguiente ejemplo provee la hipotética categorización de un paquete de procesador de palabras. Las anotaciones entre paréntesis incluidas proporcionan información sobre la razón de la categorización del paquete y son ilustrativos de la justificación que podría ser aplicable en un sistema actual.

7.4 Ejemplo categorización de : Paquete Procesador de Palabras

Función del Software

• Procesador de Palabras Modo de Operación

• Proceso interactivo (El usuario del software teclea el texto o ordena comando que se procesan por el software.

Aplicación Áreas de Sistemas de Información

• Negocios / Personal Empresas (El ambiente destino es una empresa de Negocios, pero el programa es útil para aplicaciones personal u otras).

Escala de Software

• Pequeño/Mediano (menor, en SLOC, que la mayoría de los paquetes similares; adicionó un poco de complejidad.

Representación de datos

• Objeto (Para Operación de Comandos) y Preparación de Archivos ( Para Operación de Comandos, textos Entrada / Salida, y almacenamiento de datos).

Software Critico

• Recurso (Tiempo) y Convivencia Individual

(19)

ULSA 19 Clases de Usuarios

• Intermediario (El usuario Origen es un Mecanógrafo hábil y con experiencia en el procesador de palabras, pero el programa es utilizado por un novato).

Requerimientos de velocidad

• Capacidad Media / Alta ( El tamaño del documento solo esta limitado por los recursos del equipo de Cómputo)

• Turnaround / Tiempo de Respuesta Rápido (Acepta el ingreso de datos > a 50 cps con una rápida pantalla de actualización).

• Throughput Alto ( Un documento a tiempo ) Estabilidad del Software

• Cambios Controlados( Actualizaciones frecuentes y nuevas versiones) Requisitos de Seguridad

Fuerte Mediano Débil

Protección contra

acceso no autorizado X

Referencia de auditoría X

Protección del programa

y datos X

Requisitos de Fiabilidad

Fuerte Mediano Débil

Madurez X

(20)

ULSA 20 Tolerancia a fallas X

Recobrabilidad X

Sistemas de Computacionales

• Microprocesador Controlado (personal/ laptop/ notebook deben proporcionar tipos, modelos y clases).

Requerimientos de Recursos de Computadora

• Memoria Principal RAM (Debe proporcionar las cantidades mínimas y el recomendable).

• Memoria Externa Almacenamiento Masivo (Deben proporcionarse las cantidades y tipos mínimos y recomendable).

Disponibilidad del Software (Producto)

• Comercial; Propietario Uso de los Datos del Software

• El caso normal es un solo usuario, pero múltiples usuarios en secuencia es posible que exista sin degradación.

Lenguaje Primario

• C++

Referencias

Documento similar

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

No había pasado un día desde mi solemne entrada cuando, para que el recuerdo me sirviera de advertencia, alguien se encargó de decirme que sobre aquellas losas habían rodado

Después de una descripción muy rápida de la optimización así como los problemas en los sistemas de fabricación, se presenta la integración de dos herramientas existentes

Se llega así a una doctrina de la autonomía en el ejercicio de los derechos que es, en mi opinión, cuanto menos paradójica: el paternalismo sería siempre una discriminación cuando

Luis Miguel Utrera Navarrete ha presentado la relación de Bienes y Actividades siguientes para la legislatura de 2015-2019, según constan inscritos en el

d) que haya «identidad de órgano» (con identidad de Sala y Sección); e) que haya alteridad, es decir, que las sentencias aportadas sean de persona distinta a la recurrente, e) que

La siguiente y última ampliación en la Sala de Millones fue a finales de los años sesenta cuando Carlos III habilitó la sexta plaza para las ciudades con voto en Cortes de

Las probabilidades de éxito de este procedimiento serán distintas en función de la concreta actuación del reclamante antes de que se produjera la declaración de incons-.. En caso