MAESTRÍA EN SISTEMAS COMPUTACIONALESmario.elinos.org.mx/docencia/ctrldesa/ISO12182.pdf · Para la...

DDIIRREECCCCIIÓÓNN DDEE PPOOSSGGRRAADDOO EE IINNVVEESSTTIIGGAACCIIÓÓNN

MAESTRÍA EN SISTEMAS COMPUTACIONALES

MATERIA: CONTROLES EN EL DESARROLLO DE SISTEMAS PROFESOR: MARIO FARÍAS ELINOS

TEMA:

ISO/IEC TR 12182:1998 INFORMACIÓN TECNOLÓGICA – CATEGORIZACIÓN DE SOFTWARE

Alumnos:

JUAN CARLOS AGUILAR FRANCO ADRIÁN GÓMEZ GALLARDO

JUNIO DEL 2002

Controles en el Desarrollo de Software ISO/IEC TR 12182:1998

ULSA 2

INDICE

CONTENIDO 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


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


ULSA 4

1. INTRODUCCIÓ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.


ULSA 5

2. ALCANCE 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.


ULSA 6

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


ULSA 7

4. TÉRMINOS Y DEFINICIONES 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.


ULSA 8

5. CONCEPTO DE CATEGORIZACIÓN DE SOFTWARE 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


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.


ULSA 10

6. ESQUEMA DE CATEGORIZACIÓ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


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.


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


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


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:


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:


Madurez

Tolerancia a fallas

Recobrabilidad


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


ULSA 17

7. APLICACIÓN DEL ESQUEMA 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


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


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


Protección contra acceso no autorizado X

Referencia de auditoría X

Protección del programa y datos

X

Requisitos de Fiabilidad


Madurez X


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++

MAESTRÍA EN SISTEMAS COMPUTACIONALESmario.elinos.org.mx/docencia/ctrldesa/ISO12182.pdf · Para la...

Documents

Transcript of MAESTRÍA EN SISTEMAS COMPUTACIONALESmario.elinos.org.mx/docencia/ctrldesa/ISO12182.pdf · Para la...