Documentos de Académico
Documentos de Profesional
Documentos de Cultura
C Reg Case Study V2.01.en - Es PDF
C Reg Case Study V2.01.en - Es PDF
Versión 4.0.2
VERSIÓN 2.0.1
Agosto de 2018
Tabla de contenido
1 ACERCA DE ESTE ESTUDIO DE CASO 4
1.1 Introducción 4
2 REGISTRADORES Y PROFESORES 7
2.2 de medición 12
2.4 respuestas 17
3 REGISTRADORES Y ESTUDIANTES 20
3.3 respuestas 28
4 REGISTRADORES 30
4.3 respuestas 36
6 C-REG 39
APÉNDICE 40
1.1 Introducción
Este estudio de caso presenta los resultados de la aplicación del método de medición de tamaño funcional COSMIC v4.0.2 (ISO / IEC 19761:
2017) a los requisitos del sistema de software de registro del curso ('C-Reg') como se describe en los capítulos 2 a 4.
Este estudio de caso pretende ser adecuado para nuevos usuarios del método COSMIC que al menos han leído el documento
'Introducción al método COSMIC' o han recibido alguna formación introductoria en el método, e idealmente han leído el Manual de
medición [1].
También asumimos que el lector generalmente está familiarizado con las declaraciones de requisitos para el software de aplicaciones comerciales. Los
requisitos están escritos como texto sin formato, por lo que no se necesita ningún conocimiento de ningún sistema específico o método de análisis de
datos para comprender los requisitos. Para ayudar al lector a comprender el caso, describimos no solo los requisitos de C-Reg, sino también la
información que normalmente estaría disponible más adelante cuando se iniciara el diseño del software (como menús y diseños de pantalla).
Después de describir los requisitos generales y el contexto del C-Reg en la sección 1.3, los requisitos y sus respectivos análisis
y mediciones se tratan en tres Capítulos, de interés para:
2 Registradores y profesores 3
Registradores y estudiantes 4
Registradores
Recomendamos que los lectores de este estudio de caso intenten comprender los requisitos, el análisis y los resultados de medición del
Capítulo 2 en su totalidad antes de pasar a los requisitos de los Capítulos 3 y 4.
El caso C-Reg tiene como objetivo apoyar los siguientes puntos de enseñanza sobre el método COSMIC:
● Determinar los diversos parámetros de la fase de Estrategia de Medición, incluido el establecimiento de un diagrama de contexto
que muestre los usuarios funcionales del software a medir.
● Identificar procesos funcionales dentro de los requisitos.
● Identificación de los objetos de interés en requisitos.
● Cómo los nombres de los atributos de los datos en los requisitos pueden ser engañosos. Deben analizarse cuidadosamente para asegurar la
correcta identificación de los grupos de datos.
● Identificar los movimientos de datos de un proceso funcional, incluyendo que las rutas de procesamiento alternativas pueden conducir o no a
identificar movimientos de datos adicionales.
● La necesidad de reconocer que un proceso funcional de consulta puede ser idéntico a un proceso de "preguntar antes de
actualizar" o "preguntar antes de eliminar"; dicho proceso debe contarse solo una vez por solicitud.
● Identificar los movimientos de datos involucrados en las comunicaciones entre sistemas de software.
Nota: Los comentarios sobre los requisitos destinados a ayudar al lector a comprender fácilmente el estudio de caso se muestran en
cursiva entre corchetes.
NOTA
Estos requisitos tienen como objetivo ser fáciles de entender, autónomos (pero no completos) y libres de defectos para que puedan usarse para
enseñar la medición del tamaño funcional COSMIC.
(Casi todos los requisitos del mundo real están incompletos y tienen ambigüedades, etc., por lo que se necesitan interpretación y
suposiciones para medir un tamaño funcional. Estos deben documentarse para rastrear la aplicación de las reglas de medición a los
requisitos incompletos y ambiguos. Requisitos desarrollados iterativamente, por ejemplo, utilizando métodos ágiles, nunca son
'perfectos' hasta que el usuario firma el software).
Si es nuevo en la medición del tamaño funcional, tenga la seguridad de que los medidores experimentados utilizan el método COSMIC con
regularidad para medir los requisitos del mundo real, incluso muy temprano en un proyecto de software cuando los requisitos están
evolucionando, se deben hacer suposiciones sobre algunos detalles y el tamaño aproximado puede tiene que ser utilizado. Pero para llegar a
esta etapa, debe comprender los principios y reglas básicos de medición. Estudiar este caso C-Reg le ayudará en este camino.
Los requisitos del sistema a continuación describen la funcionalidad del software que será desarrollado por un proyecto que reemplazará el
Sistema de Registro de Cursos (CRS) existente con un sistema en línea ("C-Reg") que permite a los estudiantes y profesores acceder a través de
clientes de PC.
El sistema CRS actual se ha utilizado desde hace varios años y carece de la capacidad para manejar al estudiante y la carga de cursos
proyectada para el futuro. Además, el sistema actual utiliza tecnología de mainframe obsoleta, que solo admite el acceso a través de
los empleados de la Oficina de Registro. C-Reg permitirá que todos los profesores y estudiantes accedan al sistema, además de los
empleados de la Oficina de Registro, a través de computadoras conectadas a la red informática de Wylie College y a través de
cualquier computadora personal conectada a Internet.
C-Reg continuará interactuando con el sistema de catálogo de cursos que mantiene la lista de cursos y los detalles de los cursos que se ofrecerán
para el próximo semestre (conocido como 'Ofertas de cursos'). CReg seguirá interactuando con el sistema de facturación de los estudiantes y el
sistema de correo electrónico; consulte la Figura 1. La forma en que se cargan y almacenan los datos en el sistema de catálogo de cursos está fuera
del alcance de este estudio de caso.
Todos los usuarios humanos de C-Reg (es decir, registradores, profesores y estudiantes) acceden a su funcionalidad a través de un menú de 'Formulario
principal' (ver Figura 2a). La forma en que el sistema controla la seguridad de acceso y la funcionalidad disponible para cada tipo de usuario está más allá del
alcance de estos requisitos.
[Nota: en todos los requisitos siguientes, donde se escribe "él", esto puede significar "él" o "ella". De manera similar, 'su' puede significar 'su' o
'ella'.]
Este grupo de requisitos permite a los registradores mantener datos sobre cualquier profesor en C-Reg.
Cada profesor se identifica mediante una identificación única (o 'ID') en la forma [apellido, número de serie], Ejemplo: 'Smith3'. [ Para
simplificar los requisitos, asumimos que al realizar cualquier consulta, un registrador conoce la identificación de todos los
profesores y que cada profesor conoce su propia identificación única.]
C-Reg debe permitir que un registrador realice cualquiera de las tareas 'Agregar profesor,' Modificar profesor ',' Eliminar profesor 'o' Consultar
sobre profesor '.
[Suponemos que C-Reg se implementará con un sistema de menú, como se ilustra en la Figura 2. Por lo tanto, para este grupo de requisitos, un
registrador debe seleccionar primero 'Mantener profesor' en el formulario principal como en 2a) y luego elegir el subprograma adecuado. -opción como
en 2b).]
(un) (segundo)
un) Cuando un registrador desea ingresar datos sobre un nuevo profesor, selecciona la subopción "Agregar
Profesor."
segundo) C-Reg muestra una pantalla formateada en blanco para la entrada de datos del profesor.
C) El Registrador ingresa los siguientes datos para el Profesor: DNI, nombre y dirección, seguridad social
número, departamento, cualificaciones y datos de contacto y pulsa 'Guardar'. (Consulte la Figura 3a) para ver una pantalla de ejemplo que muestra
los datos ingresados).
re) C-Reg valida los datos para garantizar los formatos adecuados y verifica si un profesor de esa identificación
ya existe. Si los datos ingresados son válidos, C-Reg crea un registro para el nuevo profesor y.
mi) Alternativamente, si los datos ingresados no son válidos, C-Reg muestra uno o más mensajes de error, por ejemplo:
'Se desconoce la identificación del profesor', el nombre del profesor ya existe ', "Datos del profesor no válidos". El Registrador puede entonces cambiar
o corregir los datos o cancelar la operación.
Los pasos a) ae) pueden repetirse para cada profesor que el Registrador desee agregar al C-Reg.
(un) (segundo)
un) Cuando un Registrador desea informarse sobre los detalles de un Profesor, primero debe seleccionar la subopción
'Consultar sobre un profesor' como en 2.1.1.2 e introducir la identificación del profesor
segundo) C-Reg busca un profesor con la identificación especificada y muestra el nombre y la dirección del profesor
y otros detalles, como en la Figura 3 (b).
un) Si un registrador desea modificar los detalles de un profesor, primero debe recuperar los detalles del profesor
como en 2.1.1.3 'Preguntar a un profesor'
segundo) El registrador presiona 'Modificar'.
C) El Registrador puede entonces cambiar uno o más de los elementos de datos del profesor mostrados (excepto el
ID de profesor). Cuando se completan los cambios, el registrador presiona "Guardar" y C-Reg actualiza los datos del profesor.
re) Alternativamente, si los datos ingresados no son válidos, C-Reg muestra un mensaje de error, "Datos del profesor no válidos".
El Registrador puede entonces corregir los datos o cancelar la operación.
un) Si un registrador desea eliminar a un profesor del C-Reg, primero debe recuperar los datos del profesor como
en 2.1.1.3 'Consultar a un profesor'
segundo) El registrador presiona 'Eliminar'.
C) C-Reg pregunta en el catálogo de cursos si el profesor tiene alguna oferta de cursos que haya
comprometido a enseñar. El catálogo de cursos responde al C-Reg con una indicación de "sí / no".
re) Si el profesor no tiene compromisos docentes de oferta de cursos, C-Reg muestra un mensaje preguntando
el Registrador para confirmar la eliminación.
mi) Si el registrador selecciona 'sí', los datos del profesor se eliminan del C-Reg.
F) Alternativamente, si el registrador selecciona 'no', la operación se cancela.
gramo) Si el profesor se compromete a impartir cursos ofrecidos, no se permite la eliminación, C-Reg muestra
un mensaje de error y el Registrador debe abandonar la operación. [ Nota: la forma en que el registrador trata este conflicto está fuera
del alcance de este estudio de caso].
El Catálogo de cursos contiene las fechas, horas y ubicaciones de todos los cursos que Wylie College ofrece a los estudiantes en el próximo
semestre (conocido como "Ofertas de cursos").
Este grupo de requisitos para el sistema C-Reg permite a un profesor informarse sobre las ofertas de cursos que puede desear enseñar y
comprometerse (es decir, agregar su ID) a enseñar una oferta de cursos, o modificar o eliminar compromisos de enseñanza existentes. El
catálogo de cursos contiene datos sobre las calificaciones necesarias para enseñar cada curso.
El catálogo de cursos también contiene el 'indicador de disponibilidad' para cada oferta de cursos. Este indicador puede tener valores:
● 'no disponible' (lo que significa que hasta ahora ningún profesor se ha comprometido a impartir la oferta del curso),
● 'disponible' (lo que significa que un profesor se ha comprometido a enseñar la Oferta del curso y los estudiantes pueden inscribirse)
● 'completo' (lo que significa que una Oferta de curso está 'disponible' pero los Estudiantes no pueden inscribirse porque la Oferta de curso está totalmente suscrita),
● 'cancelado' (para una oferta de curso que estaba 'disponible' pero ahora ha sido cancelada),
● 'cerrado' (lo que significa que los profesores ya no pueden cambiar su compromiso y los estudiantes ya no pueden inscribirse en esta oferta
de cursos (consulte la sección 4.1.2 'Cerrar inscripción')
un) Cuando un profesor desea informarse sobre los cursos que puede impartir, primero debe seleccionar 'Mantener
Ofertas de cursos 'en el formulario principal y luego' Consultar sobre ofertas de cursos (profesor) 'en el submenú.
re) C-Reg obtiene del catálogo de cursos y muestra (como se muestra en la Figura 4) la lista de cursos
Ofertas para el Departamento de Profesores que él está calificado para enseñar y que no están 'disponibles', es decir, ningún otro
profesor se ha comprometido a enseñar la Oferta en el próximo semestre. El mes programado y el espacio para cada oferta de curso
también se muestran para que un profesor pueda seleccionar compromisos que no entren en conflicto en la fecha o el lugar.
mi) Alternativamente, si no hay ofertas de cursos que el profesor pueda comprometerse a enseñar en el
próximo semestre. C-Reg mostrará un mensaje de error. El profesor reconoce el mensaje y abandona la operación.
un) Cuando un profesor desea asumir su primer conjunto de compromisos docentes, primero debe indagar y
mostrar las ofertas de cursos como en 2.1.2.2 y, a continuación, seleccione una subopción "Crear oferta de cursos".
segundo) El profesor selecciona las ofertas de cursos de las que se muestran en el paso a) a las que se comprometerá
enseñar para el próximo semestre agregando su identificación a las selecciones.
C) C-Reg devuelve cada oferta de curso seleccionada que el profesor se ha comprometido a impartir en el curso.
Catalogar.
re) El catálogo de cursos comprueba si las ofertas de cursos seleccionadas entran en conflicto con la fecha o el lugar (en caso de
El profesor cometió un error) y devuelve un mensaje a C-Reg que contiene:
mi) Si Cualquier oferta de cursos entra en conflicto con la fecha o el lugar, C-Reg indica los ID de los pares en conflicto en la pantalla de
ofertas de cursos, con un mensaje de error. El profesor puede entonces resolver el conflicto anulando la selección de una o más
ofertas de cursos y seleccionando otras nuevas, o cancelando la operación, en cuyo caso se perderán las selecciones.
F) C-Reg envía los detalles de cualquier oferta de cursos modificada al catálogo de cursos según el paso
C).
Los pasos c) af) pueden repetirse hasta que el profesor esté satisfecho con la selección o cancele.
un) Si un profesor desea modificar alguno de sus compromisos docentes, primero debe investigar y mostrar
las Ofertas de cursos disponibles para su Departamento que él puede enseñar y cualquiera que ya se haya comprometido a enseñar como en
2.1.2.2 y luego seleccione una subopción “Modificar curso para enseñar”.
segundo) Luego, el profesor modifica las ofertas de cursos de las que se muestran en el paso a) que compromete
para enseñar para el próximo semestre agregando o quitando su identificación de las Ofertas de cursos, según sea necesario.
C) C-Reg devuelve cada oferta de cursos modificada al catálogo de cursos. Pasos d), e) yf) de 2.1.2.3
se repiten hasta que el profesor esté satisfecho con esta selección presionando 'Guardar', o cancela. (El Catálogo de cursos puede
cambiar el estado de las Ofertas de cursos seleccionadas de 'no disponible' a 'disponible', o viceversa, según las decisiones del
profesor).
re) C-Reg envía datos para cada oferta de curso modificada a todos los estudiantes a través de un correo electrónico de difusión. ( Nota:
la forma en que el sistema de correo electrónico transmite esta información está fuera del alcance del estudio de caso. Los estudiantes deben tomar
medidas si una Oferta de curso que estaba 'disponible' y para la que se habían inscrito ahora se ha vuelto 'no disponible'; consulte 3.1.2 a continuación.]
un) Si un profesor desea eliminar todos sus compromisos docentes, primero debe investigar y mostrar
las Ofertas de cursos que ya se ha comprometido a enseñar como en 2.1.2.2, y luego seleccione una subopción "Eliminar ofertas
de cursos".
segundo) El profesor vuelve a ingresar su identificación.
C) C-Reg muestra un mensaje pidiendo al profesor que confirme que quiere borrar todos sus
compromisos.
re) Si el profesor selecciona 'sí', C-Reg envía los datos de oferta de cursos al catálogo de cursos, que
cambia su estado a "no disponible" (para que los estudiantes se inscriban).
Nota: Los parámetros de la estrategia de medición son los mismos para los requisitos de los capítulos 2, 3 y 4, por
lo que esta sección no se repite en los siguientes capítulos 3 y 4.
El propósito es demostrar a los nuevos usuarios del método COSMIC cómo medir el tamaño funcional de los requisitos, como se
indicó, del software C-Reg, que es una aplicación comercial típica. Los requisitos no están pensados para ser completos o
adecuados para construir un sistema real.
El alcance de la medición son todos los requisitos funcionales del usuario (FUR) del sistema C-Reg. Existe una única capa de software
para este conjunto de requisitos, la capa de aplicación.
Los requisitos no mencionan intercambios entre el cliente de PC y el servidor web, es decir, el sistema C-Reg debe medirse
'como un todo', ignorando que físicamente tiene dos componentes.
Los usuarios funcionales humanos del sistema C-Reg son los empleados de la oficina de registro (denominados 'Registradores') y los profesores
(consulte la sección 2.1) y los estudiantes (consulte la sección 3.1.2).
También hay otros dos usuarios funcionales: el sistema de catálogo de cursos y el sistema de facturación (consulte la sección 4.1.2). La Figura 4 es un
diagrama de contexto para el sistema C-Reg que muestra todos sus usuarios funcionales.
(El sistema de correo electrónico también puede parecer un usuario funcional, pero no lo es. Consulte 4.3.)
Los usuarios funcionales del sistema C-Reg identificados en los requisitos son seres humanos individuales y aplicaciones de software.
Los requisitos de los Capítulos 2 y 3 a veces describen grupos de eventos, como 'Mantener los datos del profesor', pero todos se
desglosan a un nivel de granularidad en el que ocurren eventos únicos a los que CReg debe responder, como un Registrador que
desea consultar, agregar, modificar o eliminar datos sobre un
Por razones prácticas, esta sección también contiene el resultado de la medición, la fase de mapeo se combina con la fase de
medición.
A partir de las descripciones textuales de los requisitos, los siguientes eventos desencadenantes y procesos funcionales se identifican como se
enumeran en la Tabla 1.
2.1.1.3 preguntar sobre los detalles de un profesor modificar Consultar los detalles de un profesor Modificar los
2.1.1.4 los detalles de un profesor eliminar los detalles de un detalles de un profesor Eliminar los detalles de un
2.1.1.5 profesor profesor
Un profesor necesita:
2.1.2.2 consultar sobre ofertas de cursos Consultar sobre ofertas de cursos (profesor) Crear
2.1.2.3 crear compromisos de oferta de cursos modificar los compromisos de oferta de cursos Modificar compromisos
2.1.2.4 compromisos de oferta de cursos eliminar de oferta de cursos Eliminar compromisos de oferta de
2.1.2.5 compromisos de oferta de cursos cursos
A partir de los requisitos de las secciones 1.3 y 2.1, podemos identificar los siguientes objetos de interés y el sistema que contiene datos
sobre el objeto de interés.
Fuente Objeto de interés Sistema que almacena datos sobre el objeto de interés
2.1.2.3, Todos contradictorio Curso (No se almacenan datos sobre este objeto de interés, pero uno de sus
2.1.2.4 Ofreciendo selecciones atributos, el recuento de todas las selecciones de ofertas de cursos en conflicto, se
envía en un mensaje desde el catálogo de cursos al C-Reg.)
2.1.1.2 Errores (No almacenado. Usamos 'errores' como el nombre del objeto de interés para todos los
mensajes de error emitidos por C-Reg.)
Nota: un registrador también es potencialmente un objeto de interés, pero los requisitos establecidos no especifican ningún dato que describa a ningún
registrador, por lo que un objeto de interés no figura en la lista de un registrador.
A continuación se muestra una lista de los objetos de interés y sus atributos de datos almacenados que conocemos hasta ahora de los requisitos.
Profesor: Una persona que está registrada en Wylie College que puede ofrecer una oferta de cursos para uno de los cursos de su departamento.
Clave: (ID del profesor). Otros atributos: nombre, dirección, fecha de nacimiento, número de seguro social, calificaciones, departamento, teléfono,
correo electrónico
La siguiente tabla muestra los procesos funcionales identificados en la sección 2.3.1, incluyendo todos sus movimientos de grupos de datos (cada uno
de los cuales describe un objeto de interés identificado en la sección 2.3.2). Los números de requisitos en la columna más a la izquierda se refieren a
los números de párrafo en la sección de requisitos 2.1.
(Nota: este diseño del análisis de los procesos funcionales está diseñado para fines de entrenamiento COSMIC. No sería una forma
eficiente de registrar los resultados de las mediciones reales).
En lo que sigue, "Errores" significa cualquiera de los mensajes de error mencionados en los requisitos para el proceso funcional en
cuestión.
Exigir- Proceso Funcional Descripción del subproceso Nombre de Objeto de CFP de datos
ment no. descripciones usuario Grupo de datos interés de Moverse
detalles
C-Reg recupera el Profesor R 1
Detalles del profesor detalles
Registrador C-Reg muestra el Profesor Profesor X 1
Detalles del profesor detalles
Ofrecimiento
compromiso
estado
C-Reg solicita al Rápido - -
Registrador para confirmar la Controlar
eliminación Mando
El Registrador confirma o cancela Confirmación - -
la eliminación. Controlar
Mando
C-Reg elimina al profesor Profesor Profesor W 1
detalles
Registrador Mostrar mensajes de error Error Errores X 1
Mensajes
Total 5
Exigir- Proceso Funcional Subproceso Descripción Nombre de los datos Objeto de CFP de datos
ment no. descripciones usuario Grupo interés de Moverse
Ofrecimiento
trozos escogidos
trozos escogidos
trozos escogidos
hay), o Ofrecimiento
de cursos Ofrecimiento
trozos escogidos
trozos escogidos
Estudio de caso del sistema de registro de cursos v2.0.1. © COSMIC 2018 dieciséis
Ofertas de cursos de Ofrecimiento
Ofrecimiento
correo electrónico
compromisos
C-Reg solicita al Rápido - -
Profesor para confirmar la Controlar
eliminación. Mando
El profesor confirma o cancela la Confirmación - -
supresión Controlar
Mando
Curso C-Reg envía los ID de las ofertas de Curso Curso X 1
Catalogar cursos eliminadas al catálogo de cursos ID de oferta Ofrecimiento
Ofrecimiento
correo electrónico
Suponga que C-Reg genera una identificación de profesor en lugar de, como se especifica actualmente, un registrador debe ingresar una identificación de
profesor en este proceso. ¿Cuál sería el efecto sobre el análisis de este proceso funcional?
Responder
● Aunque no se indica en los requisitos actuales, lógicamente C-Reg mostraría el ID de profesor recién creado, lo que
implicaría una salida adicional.
● Como los registradores ahora no mantendrían una lista de ID de profesor fuera del C-Reg, es casi seguro que necesitarían un proceso funcional
de consulta adicional para ingresar un apellido de profesor y mostrar todas las ID que coincidan con ese nombre (si corresponde), por ejemplo,
'Smith1', 'Smith2', 'Smith3', etc. Este proceso funcional agregaría 4 CFP al tamaño C-Reg.
Pregunta 1 con respecto a 2.1.1.2 'Agregar los detalles de un profesor y 2.1.1.4' Modificar 'los detalles de un profesor
Los requisitos no establecen cómo se representan los nombres de departamentos ingresados y, por lo tanto, cómo se puede validar un
Departamento ingresado. Suponga que el sistema C-Reg contiene una tabla de nombres de departamentos válidos, y que al ingresar datos para
'Agregar' o 'Modificar' los detalles del profesor, existe el requisito de mostrar una lista desplegable de nombres de departamentos válidos de los
que el registrador seleccione un nombre válido. ¿Cuál sería el efecto sobre el análisis de estos procesos funcionales?
Responder
No afectaría el tamaño de estos dos procesos funcionales porque un Departamento no es un objeto de interés para estos procesos.
(No se requeriría que el C-Reg almacenara ningún dato que describa un Departamento que no sea su nombre). Ver [2], sección
4.1.7.
Una solución alternativa para validar los nombres de departamentos ingresados (en lugar de mantener una tabla de nombres de departamentos válidos
en C-Reg) sería que C-Reg envíe un nombre ingresado al Catálogo de cursos para su validación. Esto requeriría un par de Salida / Entrada adicional en
cada uno de los procesos funcionales de 'Agregar' o 'Modificar' los detalles del profesor
¿La respuesta dada anteriormente a la 'Pregunta 1 con respecto a 2.1.1.2' depende de si la tabla de nombres en C-Reg está codificada en el
software o está almacenada en una tabla de nombres que puede ser mantenida por un administrador del sistema?
Responder
No importa el tamaño de los procesos funcionales Agregar y modificar detalles del profesor cómo se almacenan los nombres de los
departamentos. El departamento no es objeto de interés para estos procesos funcionales, por lo que no es necesario Leer para acceder a los
nombres.
Sin embargo, si los nombres de los departamentos se almacenan en una tabla que puede mantener un administrador del sistema, entonces
"Departamento" es un objeto de interés para el administrador. Claramente, necesitará procesos funcionales para mantener los nombres de los
departamentos y estos se sumarían al tamaño del C-Reg.
¿Puede un evento desencadenante (el registrador selecciona la actividad “Mantener profesor” del formulario principal) desencadenar más de un
proceso funcional (Agregar, modificar, eliminar y consultar a un profesor)?
Responder
No hay tal evento desencadenante como 'Profesor de mantenimiento' en este estudio de caso. En el mundo real de un registrador hay eventos
como:
● Un nuevo profesor comienza a trabajar, por lo que sus datos deben agregarse al C-Reg;
● Algo cambia para un profesor, por ejemplo, su dirección, por lo que los datos almacenados sobre él deben cambiarse;
Pregunta re 2.1.2.3 e)
¿Por qué la solución dada para el requisito 2.1.2.3 e) no muestra todos los movimientos de datos que permiten a un profesor cambiar la (s) selección
(es) para resolver cualquier conflicto que haya encontrado el Catálogo de cursos?
Responder
Las acciones del profesor después de la notificación de un conflicto para anular la selección de una de las ofertas de cursos en conflicto y
enviar sus nuevas opciones de vuelta al catálogo de cursos involucran los grupos de datos idénticos que se han movido anteriormente en el
proceso. Repetir el ciclo del requisito 2.1.2.3 e) implica repetir
ocurrencias de los mismos movimientos de datos. De acuerdo con la regla de 'Unicidad del movimiento de datos' (ver [1], sección 3.5.7), estos
movimientos de datos deben identificarse solo una vez.
Pregunta re 2.1.1.5
En el análisis de los requisitos 2.1.1.5, 'Eliminar un profesor', un Registrador ingresa un comando de eliminación, que se identifica como una
Entrada. ¿Por qué el comando de eliminación se identifica como una entrada y no como un comando de control? El comando de eliminación
simplemente dice "eliminar el profesor cuyos detalles se muestran"; no transmite datos sobre un profesor. Este mismo comentario se aplica a
varios procesos funcionales.
Responder
El comando de eliminación SÍ transmite datos sobre un objeto específico de interés, el ID de profesor del profesor ya identificado y
mostrado, por lo que debe identificarse como una Entrada. Es posible que el registrador no deba volver a ingresar físicamente ningún
atributo, como un ID de profesor específico, pero el ID mostrado ciertamente está implícito en este comando. Esto es bastante diferente
de un comando de control 'real' (como se define en la sección 3.5.10 del Manual de medición v4.0.2 [1]), como 'página arriba' o 'página
abajo'. Este mismo fenómeno ocurre en muchos de los procesos funcionales.
3.1.2 Mantener los elementos del horario del estudiante (por cualquier estudiante)
Este grupo de requisitos permite al registrador mantener datos sobre los estudiantes, seleccionando primero la actividad "Mantener estudiante"
en el formulario principal.
Cada estudiante se identifica mediante una identificación única (o "ID"). [ Para simplificar los requisitos, asumimos que al hacer cualquier consulta, un
Registrador conoce la identificación de todos los Estudiantes y que cada Estudiante conoce su propia identificación.]
un) Cuando un registrador desea ingresar datos sobre un nuevo estudiante, selecciona la subopción "Agregar estudiante".
segundo) C-Reg muestra una pantalla formateada en blanco para la entrada de datos del estudiante.
C) El Registrador ingresa los siguientes detalles para el estudiante: nombre, fecha de nacimiento, número de seguro social,
estado y fecha de graduación.
re) C-Reg valida los datos para garantizar los formatos adecuados. Si los datos son válidos, C-Reg crea un nuevo
estudiante registra y asigna una identificación única generada por el sistema, que se muestra.
mi) Alternativamente, si se ingresan datos no válidos, C-Reg muestra un mensaje de error, "Datos del estudiante no válidos".
El Registrador puede entonces corregir los datos o cancelar la operación.
un) Cuando un Registrador desea preguntar sobre los detalles de un Estudiante en particular, primero debe seleccionar el
subopción "Preguntar sobre un estudiante" y luego ingrese una identificación de estudiante.
segundo) C-Reg busca un estudiante con la identificación especificada. Si la identificación es válida, el C-Reg muestra el
nombre, fecha de nacimiento, estado, fecha de graduación.
C) Alternativamente, si no se encuentra la identificación del estudiante, C-Reg muestra un mensaje de error, "Estudiante no encontrado".
El registrador puede ingresar una identificación diferente o cancelar la operación.
un) Si un Registrador desea modificar los detalles de un Estudiante, primero debe recuperar los detalles del Estudiante como
en 3.1.1.3 y luego seleccione la subopción "Modificar estudiante".
segundo) El Registrador puede modificar uno o más de los elementos de datos del estudiante mostrados (pero no el Estudiante
CARNÉ DE IDENTIDAD). Cuando se completan los cambios, el registrador presiona "Guardar".
C) C-Reg valida los datos para garantizar los formatos adecuados y, si es correcto, actualiza los datos del Estudiante.
re) Alternativamente, si se ingresan datos no válidos, C-Reg muestra un mensaje de error, "Datos del estudiante no válidos".
El Registrador puede entonces corregir los datos o cancelar la operación.
un) Si un Registrador desea eliminar los detalles de un Estudiante, primero debe recuperar los detalles del Estudiante como
en 3.1.1.3 y luego seleccione la subopción "Eliminar estudiante".
segundo) C-Reg verifica si el estudiante tiene un horario de estudiante (ver 3.1.2 a continuación).
Este grupo de requisitos permite a un estudiante crear su 'horario de estudiante' personal para el próximo semestre al inscribirse en hasta
seis cursos ofrecidos. Cada elemento en un horario de estudiante se identifica de forma única por la identificación del estudiante y la
identificación de la oferta del curso.
El estudiante también puede consultar, modificar o eliminar ofertas de cursos en su horario, siempre que los cambios se realicen antes de
que se cierre la inscripción al curso (ver 4.1.2 Cerrar inscripción).
Como ya se dijo, el Catálogo de cursos contiene las ofertas de cursos para el próximo semestre. También contiene cualquier 'Prerrequisito' para
cada Oferta de Curso. Para cualquier curso 'X', un prerrequisito es cualquier uno otro curso 'Y' para el cual un estudiante debe haber obtenido
resultados satisfactorios en los exámenes antes de poder inscribirse en el curso 'X'.
● su "Programa" de hasta seis cursos ofrecidos (conocidos como "elementos del programa del estudiante") a los que desea asistir durante el
próximo semestre;
● sus resultados de exámenes completados con éxito para cada curso en semestres anteriores.
un) Cuando un estudiante desea consultar sobre ofertas de cursos, primero debe seleccionar 'Mantener estudiante
Programar 'en el formulario principal y luego' Consultar sobre ofertas de cursos (estudiante) 'en el submenú.
C) C-Reg recupera los detalles de todas las ofertas de cursos (fecha / hora y ubicación, y su disponibilidad
estado) del Catálogo de cursos, así como la ID de un curso prerrequisito (si lo hubiera) para cada oferta de curso.
re) C-Reg muestra los detalles de la oferta de cursos y la identificación de estudiante ingresada.
un) Cuando un estudiante desea crear su horario seleccionando cursos ofrecidos por primera vez,
primero debe recuperar las ofertas de cursos como en 3.1.2.2 y luego seleccionar la subopción "Crear horario de estudiantes".
segundo) El estudiante selecciona como máximo seis ofertas de cursos disponibles de la lista que se muestra para su horario.
Una vez que se completan las selecciones, el estudiante selecciona "Enviar", lo que da como resultado su identificación y las selecciones que se
ingresan [ El estudiante debe verificar manualmente que no haya conflictos en la fecha / hora de las ofertas de cursos seleccionadas. C-Reg solo
aceptará la selección de una oferta de curso que tenga el estado "disponible".]
mi) Luego, el estudiante puede seleccionar una oferta de curso alternativa y enviar su selección nuevamente, o
cancelar toda la operación (en cuyo caso no se guarda ningún programa).
F) C-Reg almacena los elementos del Programa del estudiante si se cumplen todos los requisitos previos.
gramo) C-Reg envía los ID de las ofertas de cursos añadidas al catálogo de cursos para que este último pueda
actualizar la cantidad de estudiantes inscritos para cada oferta de cursos.
un) Si un estudiante desea modificar las ofertas de cursos en su horario, primero debe recuperar el curso
Ofertas como en 3.1.2.2 y luego seleccione "Modificar horario del estudiante".
segundo) C-Reg recupera los elementos del programa actual del estudiante, tanto 'inscrito' como 'seleccionado' (consulte 3.1.2.6
a continuación) y agrega este estado a cada una de las Ofertas de cursos mostradas que están 'disponibles'.
re) C-Reg comprueba si el alumno ha alcanzado el requisito previo necesario para cada curso
Oferta que el Estudiante ha seleccionado ahora para la inscripción. Si la verificación es correcta, C-Reg actualiza la Oferta de cursos
seleccionada en el Programa, con el estado "inscrito".
mi) Alternativamente, si C-Reg determina que el Estudiante no ha satisfecho el requisito previo necesario para un
curso seleccionado en particular, se muestra un mensaje de error.
F) El estudiante puede seleccionar una oferta de curso alternativa y enviar su selección nuevamente, o
cancelar toda la operación (en cuyo caso el Programa modificado no se guarda, es decir, el Programa original no se modifica).
h) C-Reg envía los ID de las ofertas de cursos modificadas, si las hubiera, al catálogo de cursos para que el
Este último puede actualizar el número de estudiantes inscritos para cada oferta de curso.
un) Si un alumno desea eliminar su horario, primero debe seleccionar 'Mantener horario del alumno' en el
Formulario principal y luego seleccione la subopción "Eliminar horario".
segundo)
El estudiante ingresa su identificación.
C) C-Reg recupera y muestra los elementos del Programa de estudiantes (su lista de ofertas de cursos inscritos y / o seleccionados).
re) C-Reg solicita al estudiante que verifique la eliminación; el estudiante verifica la eliminación. C-Reg elimina los
mi) elementos del Programa y emite un mensaje de confirmación.
F) C-Reg envía los ID de las Ofertas de cursos eliminadas al Catálogo de cursos para que este último pueda actualizar el número de
estudiantes inscritos en cada curso.
C-Reg emite un mensaje de error en caso de que no se encuentre el horario del estudiante.
gramo)
Si C-Reg no puede comunicarse con el catálogo de cursos después de tres intentos, C-Reg mostrará un mensaje de error al
estudiante. El Alumno reconoce el mensaje de error y el Alumno debe abandonar la operación.
A partir de las descripciones textuales de los requisitos, se identifican los siguientes eventos desencadenantes y procesos funcionales según se
enumeran en la Tabla 2.
Sección Evento desencadenante Proceso funcional
Un registrador debe:
3.1.1.2 agregar los detalles de un estudiante Agregar los detalles de un estudiante
3.1.1.3 consultar los detalles de un estudiante modificar los Consultar los detalles de un estudiante Modificar los
3.1.1.4 detalles de un estudiante eliminar los detalles de un detalles de un estudiante Eliminar los detalles de un
Un estudiante necesita:
3.1.2.2 consultar sobre ofertas de cursos crear un Consultar sobre ofertas de cursos (estudiante) Crear un
3.1.2.3 horario de estudiante modificar un horario horario para estudiantes
3.1.2.4 de estudiante eliminar un horario de Modificar un horario
3.1.2.5 estudiante Eliminar un horario de estudiante
Esta lista de objetos de interés en 3.2.2 debe ampliarse ahora para incluir el hecho de que en 3.1 2 1 se nos dice que C-Reg contiene los
resultados de exámenes anteriores para cada alumno de cada curso. [ Los requisitos no especifican cómo se cargan estos resultados de
exámenes anteriores para cada estudiante.]
Fuente Objeto de interés Sistema que almacena datos sobre el objeto de interés
La lista de los objetos de interés y sus atributos de datos almacenados que conocemos hasta ahora de los requisitos también se amplía ahora como se
muestra a continuación.
Curso: Una serie estándar de conferencias, etc. sobre un tema específico del catálogo de cursos. Clave: (ID del curso).
Otros atributos (asumidos): Nombre del curso, descripción, Departamento.
Oferta de cursos: Un curso que se ofrece a los estudiantes durante el próximo semestre
Clave: (ID del curso, ID del semestre). Otros atributos: fechas, ubicaciones de las conferencias, etc., indicador de disponibilidad (no disponible, disponible,
completo, cancelado, cerrado), prerrequisito de la identificación del curso, identificación del profesor asignado, número de estudiantes inscritos, número
máximo de estudiantes que pueden inscribirse .
Profesor: Una persona que está registrada en Wylie College que puede ofrecer una oferta de cursos para uno de los cursos de su departamento.
Clave: (ID del profesor). Otros atributos: nombre, dirección, fecha de nacimiento, número de seguro social, calificaciones, departamento, teléfono,
dirección de correo electrónico
Estudiante: Una persona que está registrada en Wylie College y que puede inscribirse en una oferta de cursos.
Clave: (ID de estudiante). Otros atributos: nombre, fecha de nacimiento, número de seguro social, fecha de graduación, dirección de correo electrónico.
Elemento del horario del estudiante: Un registro de cada estudiante para cada uno de sus cursos seleccionados o inscritos.
Clave: (ID de estudiante, ID de oferta de cursos). Otros atributos: estado (inscrito o seleccionado)
Estudiante / Curso: Un registro para cada estudiante de los resultados de sus exámenes para los cursos a los que asistió anteriormente. Clave: (identificación del
estudiante, identificación del curso, identificación del semestre). Otros atributos (asumidos): Grado de examen.
La siguiente tabla muestra los procesos funcionales identificados en la sección 3.2.1, incluyendo todos sus movimientos de grupos de datos (cada uno
de los cuales describe un objeto de interés identificado en la sección 3.2.2). Los números de requisitos en la columna más a la izquierda se refieren a
los números de párrafo en la sección de requisitos 3.1.
En lo que sigue, "Errores" significa cualquiera de los mensajes de error mencionados en los requisitos para el proceso funcional en
cuestión.
3.1.1.2 Agrega un Registrador El registrador ingresa al estudiante Detalles del estudiante Detalles del estudiante mi 1
Del estudiante
detalles
C-Reg crea un nuevo registro de Datos del estudiante Estudiante W 1
estudiante
Registrador C-Reg muestra el Identificación del Estudiante Estudiante X 1
identificación de estudiante generada
detalles
C-Reg obtiene el Datos del estudiante Estudiante R 1
Datos del estudiante
detalles
C-Reg almacena el Datos del estudiante Estudiante W 1
detalles modificados
3.1.2.2 Consultar sobre Estudiante El estudiante ingresa su identificación Identificación del Estudiante Estudiante mi 1
Curso y 'Pregunte en
Ofrendas
Curso C-Reg recibe curso Pedido Curso mi 1
Catalogar Ofreciendo detalles, incl. Curso Ofrecimiento
Curso
Ofrendas
C-Reg comprueba si el Estudiante Estudiante/ R 1
estudiante cumple con examen anterior Curso
requisitos de seleccionados resultados
Oferta de cursos
Curso Curso validado Curso que ofrece el curso X 1
Catalogar Los ID de oferta se envían a ID del Ofrecimiento
artículos detalles
Estudiante C-Reg agrega los estados del Estudiante Estudiante X 1
artículo (inscrito o Programar elemento Programar elemento
seleccionado) al detalles
curso mostrado
Ofrendas
Estudiante El estudiante modifica su Modificado Estudiante mi 1
curso mostrado Estudiante Programar elemento
detalles
C-Reg comprueba si el Estudiante Estudiante/ R 1
estudiante cumple con examen anterior Curso
requisitos de modificado resultados
Oferta de cursos
"Enviar" Estudiante de calificaciones C-Reg Estudiante Estudiante W 1
Programar elementos como Programar elemento Programar elemento
'inscrito' y hace
ellos persistentes
3.1.2.6 "Salvar" Estudiante de calificaciones C-Reg Estudiante (Igual -
un) Programar elementos como Programar elemento como para
de cursos
Estudiante Mostrar mensaje de error Mensajes de error Errores X 1
8
3.1.2.5 Eliminar un Estudiante El estudiante selecciona el 'Eliminar horario' del Estudiante mi 1
Estudiante estudiante
Calendario comando y se ingresa su ID
artículos detalles
Estudiante C-Reg muestra el Estudiante Estudiante X 1
Horario del estudiante Programar artículo Programar elemento
artículos detalles
C-Reg solicita al Controlar - -
Estudiante para verificar la Mando
eliminación
detalles
Curso C-Reg envía el Curso que ofrece curso X 1
Catalogar Eliminación de la oferta del curso elimina las ID Ofrecimiento
del curso
Catalogar
Estudiante Mostrar mensaje de error Mensajes de error Errores X 1
6
El proceso funcional “Eliminar los detalles de un estudiante” tiene un requisito: “C-Reg solicita al Registrador que verifique la eliminación”.
Confirmaciones como esta aparecen en otros procesos funcionales como Delete a Professor. ¿Por qué estos 'mensajes de confirmación' no se
identifican como movimientos de datos?
Responder
En las Directrices de aplicación empresarial [2], la regla se da en 4.4.1 de que hacer clic en 'Aceptar' para confirmar algunos datos
ingresados debe ignorarse, ya que es un comando de control. El comando no mueve datos que describen un objeto de interés.
Los requisitos para estos dos procesos funcionales ('Crear' y 'Modificar' un horario de estudiante) no especifican que el estudiante debe ingresar su
identificación al inicio del proceso, pero el análisis muestra que se identifica una entrada para la identificación del estudiante. ¿Por qué?
Responder
Los requisitos establecen que estos dos procesos funcionales solo se pueden iniciar después de ejecutar un proceso de 'Consulta sobre ofertas de
cursos (estudiante)'. El resultado de este último proceso mostrará la identificación del estudiante que ingresó, así como las ofertas de cursos
recuperadas. Esta pantalla se convertirá en la pantalla de entrada de datos para los procesos funcionales 'Crear' o 'Modificar' un horario de
estudiante si están seleccionados.
Cuando el estudiante ha realizado sus selecciones de oferta de cursos, presiona 'Enviar' (o 'Guardar') y los datos en la pantalla cruzan el límite del usuario
funcional del estudiante para ingresar al proceso funcional 'Crear' o 'Modificar'. Por lo tanto, debemos identificar una Entrada para la entrada de la
identificación del estudiante. Es posible que el estudiante no necesite volver a ingresar físicamente su identificación, pero los procesos funcionales 'Crear' y
'Modificar' necesitan esta identificación de estudiante en su pantalla de entrada.
El requisito 3.1.2.3 “Crear un horario de estudiante” establece que el estudiante 'envía' sus elementos de horario y luego que
C-Reg 'guarda' el horario. El requisito de flujo alternativo 3.1.2.6 establece que el estudiante puede 'guardar' un horario sin
enviarlo. Esto parece indicar que hay hasta tres escrituras. ¿Cómo se aplica aquí la regla de "unicidad de movimiento de
datos"?
Responder
El 'Enviar' es la acción final de ingresar datos que se miden como una Entrada. Después de que el estudiante presiona 'Enviar', C-Reg hace que su
horario de estudiante sea persistente (es decir, almacenado) con el estado 'inscrito' para cada oferta de curso. La acción de un estudiante para
'guardar' su horario de estudiante, es el mismo movimiento de datos, pero con el estado 'seleccionado'. El grupo de datos movido - 'Elemento de
horario del estudiante' - es del mismo tipo, independientemente del valor del atributo de datos 'estado'. Solo se necesita un movimiento de datos de
escritura para satisfacer todos estos requisitos.
En la sección 3.1.2.4, 'Modificar las ofertas de cursos en el horario de un alumno', después de que se hayan mostrado las ofertas de cursos
actuales y el alumno presione 'Modificar ofertas de cursos', C-Reg recupera los elementos del horario del alumno actual y agrega su estado
(inscrito o seleccionado) a las Ofertas de cursos mostradas. El alumno ahora puede modificar su selección. ¿Por qué se identifica una salida
para esta actualización de las ofertas de cursos mostradas?
Responder
Responder
'Horario del estudiante' es un nombre que le damos por comodidad a una colección de hasta seis elementos del Horario del estudiante. No hay datos
almacenados o movidos que describan la colección de 'Horario del estudiante'; Los datos se almacenan solo sobre los elementos individuales del Programa
de estudiantes. Por tanto, el "horario del estudiante" no es un objeto "de interés".
Pregunta re 3.2.2
"Departamento" se muestra como un atributo de los objetos de interés "Profesor" y "Oferta de cursos". ¿Cómo puede ser esto cierto?
Responder
El significado del atributo de Oferta de cursos que se denomina "Departamento" es "el Departamento que ofrece esta Oferta de
cursos".
Por tanto, estos dos atributos deberían llamarse de forma diferente. Una buena convención para nombrar atributos es formar el
nombre del objeto de interés que describe el atributo, seguido de un nombre que distinga el atributo; estos dos están unidos por
un guión bajo '_'. Para estos dos atributos, los nombres podrían ser:
Profesor_Departamento
Oferta de cursos_Departamento
En la práctica, como en este estudio de caso, los atributos suelen enumerarse en declaraciones de requisitos, y en pantallas y en los títulos de los
informes, con nombres breves y sencillos cuyos significados son claros en el contexto.
Los medidores deben conocer estas prácticas si los objetos de interés y los grupos de datos deben distinguirse correctamente. Consulte [2] la sección
4.2.1 'Advertencia sobre nombres de atributos engañosos'.
Este grupo de requisitos permite al Registrador monitorear el progreso en las inscripciones del curso mediante un informe y una Consulta, y
cerrar la inscripción, es decir, evitar más inscripciones.
un) Cuando un Registrador desea verificar el progreso de la inscripción a la Oferta de cursos, selecciona el menú
subopción 'Supervisar la inscripción en la oferta de cursos'.
segundo) C-Reg solicita del catálogo de cursos y recibe todas las ofertas de cursos, incluida su actual
estado, el nombre del Departamento que 'posee' el Curso, el número de estudiantes matriculados y el número máximo de
estudiantes que pueden matricularse.
C) C-Reg ordena las ofertas de cursos recibidas por nombre de departamento y genera un informe (consulte la Figura
5) mostrando, en la fecha mostrada:
● Para cada departamento (por nombre), una lista de cursos ofrecidos, cada uno con su estado; el número real de
estudiantes matriculados; el número máximo que puede inscribirse; y el 'porcentaje de matrícula' (= real / máximo)
● Para cada departamento, el número real de estudiantes matriculados; el número máximo que puede inscribirse; y el porcentaje
de matrícula promedio para todas las ofertas de cursos del Departamento
● Para todo Wylie College, el número real de estudiantes inscritos; el número máximo que puede inscribirse; y el
porcentaje de inscripción promedio para todas las ofertas de cursos.
un) Cuando un Registrador desea verificar el progreso en la inscripción del Programa de Estudiantes, selecciona el menú
subopción 'Supervisar los horarios de los estudiantes'.
segundo) C-Reg recupera los elementos del horario del estudiante para cada estudiante y los nombres de todos los estudiantes que
no se ha inscrito ni seleccionado ninguna oferta de cursos.
C) C-Reg muestra, en la fecha del informe:
● el nombre de cada estudiante que no se ha inscrito ni seleccionado ninguna oferta de cursos, es decir, que no tiene elementos de horario de estudiantes
● el porcentaje general de inscripciones en los horarios de los estudiantes (= el total de inscripciones reales en los horarios
como porcentaje del número máximo posible de inscripciones en un horario, donde el último es seis por estudiante) para
Wylie College.
Este requisito permite al Registrador cerrar los procesos de registro, cambiando el estado de cada Oferta de curso (es decir, el valor de
su campo indicador de disponibilidad) de "disponible" o "completo" a "cancelado" o "cerrado". Como no se puede realizar un proceso de
registro cercano si hay un registro en curso, el Registrador anuncia con anticipación la fecha de cierre a las personas interesadas. [ Este
anuncio no forma parte del alcance de la medición.] Las ofertas de cursos que no tienen suficientes estudiantes se cancelan. C-Reg se
ocupa de las consecuencias del cierre o cancelación del curso para la facturación de los estudiantes y sus horarios.
un) Cuando un Registrador desea cerrar todos los procesos de registro, selecciona la subopción del menú "Cerrar
Registro".
segundo) C-Reg obtiene las ofertas de cursos del catálogo de cursos que están 'disponibles' o 'completos'.
C) C-Reg realiza el siguiente procesamiento:
● Para cada oferta de cursos que tenga menos de 3 estudiantes inscritos, C-Reg establece el estado de la oferta de cursos en 'cancelado'.
● Para todas las demás ofertas de cursos, C-Reg establece el estado en "cerrado".
re) C-Reg devuelve los datos de la oferta de cursos al catálogo de cursos para que pueda actualizar la oferta de cursos.
estados en sus archivos.
mi) Para cada combinación de estudiante inscrito y oferta de curso cerrado, C-Reg envía la identificación del estudiante
y el ID de oferta del curso en el sistema de facturación.
F) C-Reg prepara y emite correos electrónicos anunciando ofertas de cursos cancelados que se enviarán a cada
Estudiante afectado a través del sistema de correo electrónico. El sistema de correo electrónico requiere que un mensaje tenga tres campos: Para (dirección de
correo electrónico), Asunto (encabezado), Mensaje (cuerpo). La dirección de correo electrónico debe cumplir con los estándares normales de Internet; el
encabezado y el cuerpo pueden ser texto no estructurado.
gramo) C-Reg actualiza los elementos del horario del estudiante cuando es necesario.
Hay dos procesos funcionales desencadenados por la necesidad de un registrador de monitorear el progreso en las inscripciones en las ofertas de
cursos y por estudiante en sus horarios.
Hay un proceso funcional desencadenado por la necesidad de que un registrador cierre el registro.
Los dos procesos de 'Información de gestión' producen datos que describen los objetos de interés que se muestran en la tabla siguiente.
Nota: no se almacenan datos acerca de un 'Departamento' o acerca de 'Wylie College'. Pero son " cosas en el mundo del usuario
funcional que se identifican en los Requisitos funcionales del usuario, sobre las cuales se requiere que el software procese .... datos ”(Según
la definición de objeto de interés). 'Departamento' y 'Wylie
Fuente Objeto de interés Sistema que almacena datos sobre el objeto de interés
4.1.1.2 c) Departamento No se almacenan datos sobre este objeto de interés en C-Reg. C-Reg
genera datos transitorios sobre el departamento.
4.1.1.2 c) y Wylie College No se almacenan datos sobre este objeto de interés en C-Reg. C-Reg
4.1.1.3 c) genera datos transitorios sobre el departamento.
La lista de los objetos de interés y sus atributos de datos de los requisitos de la sección 4.1 es la siguiente.
Oferta de cursos: Un curso que se ofrece a los estudiantes durante el próximo semestre
Clave: (ID del curso, nombre del semestre). Otros atributos: mes, código de sala de las conferencias, etc., indicador de disponibilidad (no
disponible, disponible, completo, cancelado, cerrado), cédula de profesor asignado, número de alumnos matriculados, número máximo de
alumnos matriculados.
Departamento: Una parte de Wylie College con responsabilidades específicas de investigación y enseñanza.
Clave: (nombre del departamento). Otros atributos (derivados): el número real de estudiantes matriculados; el número máximo que puede
inscribirse; y el porcentaje de inscripción promedio para todas las ofertas de cursos del Departamento, todas en la fecha que se muestra.
Estudiante: Una persona que está registrada en Wylie College y que puede inscribirse en una oferta de cursos.
Clave: (ID de estudiante). Otros atributos: nombre, fecha de nacimiento, número de seguro social, estado, fecha de graduación y dirección de correo electrónico.
Elemento del horario del estudiante: Un registro de cada estudiante para cada uno de sus cursos seleccionados o inscritos.
Clave: (ID de estudiante, ID de oferta de cursos). Otros atributos: estado (inscrito o seleccionado)
Clave: (nombre de Wylie College). Otros atributos (derivados): el número real de estudiantes matriculados; el número máximo que puede
inscribirse y el porcentaje promedio de inscripción para todas las ofertas de cursos; el porcentaje general de inscripciones en Horarios de
estudiantes y el porcentaje general de selecciones en Horarios de estudiantes, todo en la fecha que se muestra.
El proceso de 'Cerrar registro' no introduce nuevos objetos de interés. La lista de objetos de interés relevantes para este proceso
es, por tanto, la misma que en la sección 4.2.2.
La siguiente tabla muestra los procesos funcionales identificados en la sección 4.2.1, incluyendo todos sus movimientos de grupos de datos (cada uno
de los cuales describe un objeto de interés identificado en la sección 4.2.2). Los números de requisitos en la columna más a la izquierda se refieren a
los números de párrafo en la sección de requisitos 4.1.
En los siguientes 'Mensajes' se entiende cualquiera de los 'Mensajes de error / confirmación' mencionados en los requisitos para el
proceso funcional en cuestión.
Exigir- Proceso Funcional Subproceso Nombre de los datos Objeto de CFP de datos
ment descripciones usuario Descripción Grupo movido interés de Moverse
de cursos
Total 6
4.1.1.3 Monitor Registrador El registrador selecciona 'Monitor Student Student Estudiante mi 1
Estudiante Schedule Calendario Programar elemento
datos
o curso seleccionado
Ofrendas
Registrador C-Reg muestra el Universidad Wylie Universidad Wylie X 1
% total de matriculaciones Estudiante
en Horarios de estudiantes para Schedule Wylie
College datos de inscripción
Total 5
Cerrar registro
4.1.2.2 Cerca Registrador El registrador selecciona Fecha de cierre Curso mi 1
Registro subopción "Cerrar Ofrecimiento
registro"
Curso C-Reg solicita curso Curso que ofrece curso X 1
Catalogar Ofreciendo datos (con Solicitud de datos Ofrecimiento
numero de estudiantes
inscrito, etc.) del Catálogo de
cursos
Curso Datos de oferta de cursos Curso que ofrece curso mi 1
Catalogar recibido Datos Ofrecimiento
mensaje
C-Reg actualiza al estudiante Estudiante Estudiante W 1
Programar elementos para Programar elemento Programar elemento
En el proceso funcional 'Cerrar registro', el requisito 4.1.2.2 e) establece: 'Para cada oferta de curso cerrada y combinación de estudiante inscrito,
C-Reg envía la identificación del estudiante y la identificación de la oferta del curso al sistema de facturación.
El tamaño de este requisito se ha dado como una salida en el análisis de 4.1.2. El objeto de interés del grupo de datos movido es 'un elemento de Programación
del estudiante' y su identificador único (o clave) es [ID de estudiante, ID de oferta de curso]. Los requisitos no especifican ningún otro atributo de datos. El grupo
de datos se producirá una vez por cada combinación de ID de oferta de curso e ID de estudiante inscrito, por lo que este es un grupo de datos movido en una
salida.
En la práctica, si el sistema de facturación va a producir una factura para el estudiante, necesitará algo más que una identificación de estudiante; también
necesitará su nombre y dirección. El sistema de facturación podría, por supuesto, acceder al sistema CReg para obtener esos datos.
Sin embargo, suponga como una alternativa al requisito 4.1.2.2 e), que el C-Reg debe enviar el nombre y la dirección del estudiante, así como la
identificación del estudiante y la identificación de la oferta del curso al sistema de facturación, ¿cómo afectaría eso el tamaño de este proceso de
función?
Responder
El nombre y la dirección de un alumno son dos atributos de datos del objeto de interés del 'alumno' (esto se fija de forma bastante independiente de
si el alumno está matriculado o no en alguna oferta de curso). Los atributos de ID de estudiante, nombre y dirección forman un grupo de datos que
ocurre una vez para cada 'Estudiante'.
Esta diferencia en la frecuencia de ocurrencia nos dice que C-Reg debe generar dos grupos de datos diferentes para cumplir con este requisito,
es decir, habría dos salidas al sistema de facturación. (Consulte el Capítulo 2 de la 'Guía para dimensionar el software de aplicación
empresarial', v1.2, [2].
¿Por qué el mensaje enviado por C-Reg sobre ofertas de cursos canceladas al sistema de correo electrónico para su transmisión a los estudiantes
afectados se mide como dos salidas cuando el sistema de correo electrónico requiere solo tres campos? Estos tres campos podrían interpretarse como
atributos de un objeto de interés 'Correo electrónico'
Responder
C-Reg ensambla un mensaje de correo electrónico para cumplir con los estándares de formato del sistema de correo electrónico. Estos especifican que cualquier
mensaje debe tener tres campos, a saber, 'Para' (una dirección de correo electrónico estándar), 'Asunto' (texto del encabezado), 'Mensaje' (texto del cuerpo). Desde
el punto de vista del sistema de correo electrónico, estos son claramente tres atributos del único objeto de interés 'Correo electrónico' (por lo que procesaría el
mensaje como una Entrada).
Sin embargo, el sistema de correo electrónico NO es el usuario funcional del sistema C-Reg para este requisito. El usuario funcional (el 'destinatario
previsto' de los datos) es el Estudiante identificado en el campo 'Para' del correo electrónico. Esto debe quedar claro a partir de los requisitos que
establecen que el mensaje de correo electrónico debe incluir la dirección de correo electrónico y el nombre del estudiante ('John Doe' en el ejemplo).
Este Requisito de Usuario Funcional tiene dos componentes: a) la información requerida por el Estudiante, y
b) el formato de la información transmitida debe cumplir con el estándar del Sistema de correo electrónico.
C-Reg, que ensambla el mensaje, genera la dirección de correo electrónico y el nombre del estudiante (atributos del objeto de interés del
estudiante) y la lista de una o más ofertas de cursos canceladas, según el ejemplo de la pregunta 1 anterior. Desde el punto de vista de C-Reg,
está generando datos que describen dos objetos de interés (Estudiante y Oferta de curso), por lo tanto, está generando dos salidas.
En el proceso funcional 'Cerrar registro', C-Reg envía un grupo de datos de 'Estudiante inscrito / Oferta de curso' al sistema de facturación y un
grupo de datos de 'Mensaje de elemento de horario de estudiante cancelado' al Estudiante en el correo electrónico. Cada uno de estos dos grupos
de datos describe el mismo objeto de interés, un elemento de Programación del estudiante, es decir, una combinación de Oferta de curso y
estudiante. La única diferencia es que un grupo de datos es para Estudiantes matriculados, el otro es para Estudiantes cuya oferta de cursos ha sido
cancelada; esta es una diferencia del valor del atributo de estado.
Dado que la salida al sistema de facturación y al sistema de correo electrónico describe el mismo objeto de interés, ¿por qué identificar dos salidas?
Responder
Los grupos de datos que se deben enviar al sistema de facturación y al estudiante en el correo electrónico no son idénticos. La salida del
grupo de datos al Estudiante contiene información en forma de texto (que genera C-Reg) que no ocurre en la salida al Sistema de
Facturación. Además, el sistema de facturación y el estudiante son dos usuarios funcionales diferentes.
Estas dos diferencias - de grupos de datos y de usuarios funcionales receptores - satisfacen las condiciones de la regla b) 'Unicidad de
datos y posibles excepciones', sección 3.5.7 del Manual de Medición [1], por lo que debemos identificar dos Salidas diferentes.
Importante
Los resultados de las mediciones anteriores se basan en la información disponible a nivel de Requisitos. Es factible que se agregue
más información al nivel de Especificaciones que agregaría más grupos de datos; esto sin duda afectaría el tamaño funcional.
También es plausible que las especificaciones detalladas conduzcan a procesos funcionales adicionales y / o la adición de
subprocesos. Nuevamente, esto podría llevar a cambios en el tamaño funcional para tener en cuenta estas adiciones.
Todos los documentos COSMIC están disponibles para su descarga gratuita desde www.cosmic-sizing.org .
[1] 'El método de medición de tamaño funcional COSMIC v4.0.2: Manual de medición. (El COSMIC
Guía de implementación para ISO / IEC 19761: 2017) 'Diciembre de 2017.
[2] 'Directriz para dimensionar el software de aplicaciones empresariales', v1.3, mayo de 2017
2003 IBM La versión original de este estudio de caso se documentó en Rational Unified
Process (versión RUP
2003.06.00.65) documento como ejemplo de un sitio web
Más reciente Muchos revisores La primera versión de este estudio de caso se publicó el 26 th
actualización de Agosto de 2004, copyright de la École de Technologie Supérieure, Montreal,
versión 1: Canadá. Esta versión pasó por varias actualizaciones sucesivas, la última
fechada el 23 rd
2008-02-23
Febrero de 2008, todos los cuales fueron publicados el
www.cosmicon.com .
Versión 2.0 Arlan Lesterhuis, Alain Actualizado para cumplir con v4.0.1 del método COSMIC, y reescrito
diciembre Abran, Charles Symons parcialmente para simplificar los requisitos y hacer que todo el documento sea
Measurement
Comité de Prácticas Se eliminaron algunos requisitos de versiones anteriores y se agregaron
Especialistas en métricas de algunos requisitos nuevos (en el capítulo
Versión 2.0.1 Arlan Lesterhuis, Alain Actualizado para cumplir con v4.0.2 del método COSMIC.
Abril de 2018 Abran, Charles Symons Sin cambios sustanciales. La fuente cambió de 10 a 11 puntos.
Especialistas en métricas de
Capgemini Reino Unido
Cuando el lector crea que hay un defecto en el texto, una necesidad de aclaración o que algún texto necesita mejorarse, envíe un correo electrónico a: mpc-chair@cosmic-siz
. Puedes usar el foro en cosmic-sizing.org/forums para publicar sus preguntas y recibir respuestas de nuestra comunidad mundial. La calidad de las
respuestas dependerá del conocimiento y la experiencia del miembro de la comunidad que escriba la respuesta; el MPC no puede garantizar la exactitud.
Existen organizaciones comerciales que pueden brindar capacitación y consultoría o herramientas de apoyo para el método. Por favor consulte el www.cosmic-sizing.org
sitio web para más detalles.