diagrama de clases
TRANSCRIPT
1. Diagrama de clases
El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se
representa la estructura y el comportamiento de cada uno de los objetos del sistema y sus
relaciones con los demás objetos, pero no muestra información temporal.
2. Diagrama de estados
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una
aplicación, junto con los cambios que permiten pasar de un estado a otro. Mientras el
diagrama de clases muestra un cuadro estático de las clases y sus relaciones, lo diagramas
de estado se usan para modelar la conducta dinámica del sistema.
En un diagrama de estado encontramos dos estados especiales, el estado de arranque
"Start" y el estado de parada "Stop". El estado de arranque es representado por un punto
verde encerrado en un círculo, e indica el estado del objeto cuando es creado por primera
vez. El estado de parada es representada por un punto rojo encerrado en un círculo, y
muestra el estado del objeto justo antes de que se destruya.
3. Diagrama de componentes
El diagrama de componentes proporciona una visión física del modelo, Muestra la
organización de los componentes software, sus interfaces y las dependencias entre ellos.
Hay dos tipos de componentes en el diagrama: los componentes ejecutables y las
bibliotecas de código Un componente es un módulo de software que puede ser código
fuente, código binario, un ejecutable, o una librería con una interfaz definida. Una interfaz
establece las operaciones externas de un componente, las cuales determinan una parte del
comportamiento del mismo.
Además se representan las dependencias entre componentes o entre un componente y la
interfaz de otro, es decir uno de ellos usa los servicios o facilidades del otro.
4. Diagrama de despliegue
El objetivo de estos diagramas es mostrar la disposición de las particiones físicas del
sistema de información y la asignación de los componentes software a estas particiones. Es
decir, las relaciones físicas entre los componentes software y hardware en el sistema a
entregar.
2.2.3 MODELO CLIENTE – SERVIDOR
Esta arquitectura consiste básicamente en que un programa -el cliente- que realiza peticiones a
otro programa -el servidor- que le da respuesta. Aunque esta idea se puede aplicar a programas
que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo
multipersonal distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores,
aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la
gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño
del sistema.
Modelo 3 capas
El modelo de 3 capas es un método que se utiliza en la ingeniería de software, para
dividir una aplicación en diferentes capas, el modelo de tres capas se divide en: capa
cliente, capa intermedia o de aplicación y capa del servidor o datos del negocio.
El desarrollo del proyecto se realizara a través del modelo de tres capas el cual
proporcionará las siguientes ventajas.
1. Separación de funciones, todo lo relacionado con la interfaz del usuario va en
una capa, las reglas de negocio en otra y el manejo de datos en una tercera
capa.
2. Reutilización, el código perteneciente a una capa puede ser reutilizado, para
mejorar el modulo.
3. Escalabilidad, sabiendo donde está el código correspondiente a cada capa,
pueden realizarse modificaciones dentro de una capa para mejorar o aumentar
el tamaño del sistema, con un mismo impacto en las capas restantes.
4. Facilidad de mantenimiento, mediante esta división, es mucho más sencillo
localizar errores en el código o efectuar mejoras.
5.
2.2.4 BASE DE DATOS RELACIONAL
Existen varias formas de almacenar información en las computadoras, lo que genera distintos
modelos de organización de Bases de Datos: jerárquico, red, relacional y orientado a objetos.
Los sistemas relacionales son muy importantes, por que ofrecen muchos tipos de procesos de
datos como: simplicidad y generalidad, facilidad de uso para el personal final, periodos cortos de
aprendizaje y las consultas de información se especifican de forma sencilla.
Una base de datos relacional parte del "modelo relacional de base de datos", en el cual los datos
son ordenados jerárquicamente, mediante "ordenamiento de burbuja.
Una base de datos relacional es un conjunto de relaciones normalizadas. Para representar el
esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos
de éstas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves
ajenas.
Características
1. Una base de datos relacional se compone de varias tablas o relaciones.
2. No pueden existir dos tablas con el mismo nombre.
3. Cada tabla es a su vez un conjunto de registros, filas o tuplas.
4. Cada registro representa un objeto del mundo real.
5. Cada una de estos registros consta de varias columnas, campos o atributos.
6. No pueden existir dos columnas con el mismo nombre en una misma tabla.
7. Los valores almacenados en una columna deben ser del mismo tipo de dato.
8. Todas las filas de una misma tabla poseen el mismo número de columnas.
9. No se considera el orden en que se almacenan los registros en las tablas.
10. No se considera el orden en que se almacenan las tablas en la base de datos.
11. La información puede ser recuperada o almacenada por medio de sentencias llamadas
“consultas”.
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización,
el resultado de dicho proceso es un esquema que permite que la base de datos sea usada de
manera óptima.
2.3 MARCO TEÓRICO
2.3.1 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
El proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de
software es un conjunto de actividades necesarias para transformar los requisitos de un personal
en un sistema de Software.
El proceso Unificado no es tan sólo un proceso; es un marco de trabajo genérico que permite
especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación,
diferentes tipo de organizaciones, diferentes niveles de aptitud y diferentes tamaños de
proyectos.
El proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software
en construcción está formado por componentes software interconectados a través de interfaces
bien definidas.
El proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Lenguaje,
UML) para preparar todos los esquemas de software.
El proceso Unificado se define en tres aspectos claves: Dirigido por Casos de Uso, Centrado en
la Arquitectura y es Interactivo e Incremental.
El Proceso Unificado está dirigido por Casos de Uso, quiere decir que el proceso de desarrollo
sigue un hilo, es decir, avanza a través de una serie de flujos de trabajo que parten de los casos
de uso. Los casos de uso se especifican, se diseñan y los casos de uso finales son la fuente a
partir de la cual se construyen los casos de prueba.
El Proceso Unificado está centrado en la arquitectura, quiere decir que la arquitectura, en un
sistema de software se describe mediante vistas del sistema en construcción. Incluye también
los aspectos estáticos y dinámicos más significativos del sistema, reflejados en los casos de uso
y otros factores como la plataforma en que funcionará el software, sistema operativo, gestor de
bases de datos, herramientas case y otros.
El Proceso Unificado es Iterativo e Incremental, quiere decir que el desarrollo de un producto
software comercial supone un gran esfuerzo que podría durar 6 meses o hasta un año o más. Es
práctico dividir el trabajo en partes pequeñas o sub-proyectos. Cada sub-proyecto es una
iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de
trabajo y los incrementos al crecimiento del producto.
Estas iteraciones controladas traen muchos beneficios:
1. Reduce el coste del riesgo a los costes de un solo incremento.
2. Reduce el riego de no sacar al mercado el producto en el calendario previsto.
3. Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los
desarrolladores trabajan de manera eficiente para obtener resultados claros a corto
plazo.
4. Cada iteración persigue un objetivo concreto, reconoce una realidad que a menudo se
ignora.
1. GUÍA PARA LA INGENIERIA DE APLICACIONES RAPIDAS GRAPLLE
(GUIDELLNES FOR RAPID APPLLCATLON ENGINEERING)
La guía para la ingeniería de aplicaciones rápidas es un conjunto de ideas adaptables y flexibles,
es una herramienta para el UML dentro de un contexto, y no así una férrea metodología.
Consta de cinco segmentos, cada segmento consta de diversas acciones, cada acción trae
consigo un producto del trabajo, y cada acción es responsable de un jugador.
Se encausa a los sistemas orientados a objetos, por ello las acciones dentro de cada segmento
se orientan a crear productos de trabajo de una manera orientada a objetos, Utiliza los siguientes
segmentos:
1. Recopilación de necesidades
Consiste en la recolección de información y datos de la forma más estructurada posible. En
esta fase se establece la planificación del proyecto y su alcance. Para esto se describe los
procesos de negocio, se realiza un análisis de dominio, se identifican los sistemas
cooperativos, se describe las necesidades del sistema y se presenta la identificación del
producto. Los siguientes puntos ayudan la recopilación de necesidades.
1. Descubrir los procesos de negocio.
2. Realizar un análisis del dominio.
3. Describir las necesidades del sistema.
4. Representación de resultados
5. Análisis
En este segmento se profundiza la información obtenida en la Recopilación de necesidades,
el análisis del sistema se relazará con las siguientes etapas:
Comprensión del uso del sistema, en esta etapa se describirán los actores que iniciaran
cada caso de uso del sistema, comprendiendo el uso que el personal realizara en el sistema,
los actores son los diferentes usuarios y el rol que representan dentro del sistema.
Diagrama de casos de uso, un caso de uso representa todo lo que el personal puede
realizar dentro del sistema, en esta etapa se hace realidad los casos de uso, realizando las
secuencias de pasos para cada caso de uso. La notación es la siguiente:
Diagrama de clases, es una colección de elementos (estáticos) declarativos de un modelo,
en esta etapa se realiza el análisis, modelo y depuración de los diagramas de clases, se
debe de llenar los nombres de las asociaciones, clases abstractas, multiplicidades,
generalizaciones y agregación.
Analizar cambios de estado en los objetos (diagrama de estados), nos permiten
describir el comportamiento de un objeto, mostrando la secuencia de estados por la que
pasa a lo largo de su vida. En esta etapa se describen todos los estados posibles en los que
puede entrar un objeto en particular.
Definir la comunicación entre objetos (diagrama de secuencia), en esta etapa se modela
los objetos y permite ilustrar las acciones de los actores y las operaciones iniciadas por ellos.
Un diagrama de secuencia representa la interacción entre las clases, se modela para cada
caso de uso.
Analizar la integración con los diagramas de colaboración, en esta etapa se debe
describir todos los detalles específicos del sistema, de ser necesario realizar los diagramas
de distribución detallada, los diagramas de colaboración permiten modelar interacciones
entre objetos en el sistema y se centra a estudiar todos los efectos de un objeto durante un
escenario.
6. Diseño
En este segmento se trabaja con los resultados del segmento anterior para diseñar la
solución, las tareas a realizarse en esta etapa son:
1. Desarrollo y depuración de los diagramas de objetos, en esta etapa se debe dar vida
a los objetos mediante el análisis de cada operación y el desarrollo de un diagrama de
actividades.
2. Desarrollo de los diagramas de componentes, el producto de esta etapa son el
diagrama de componentes, los cuales distribuyen los elementos físicos del sistema y sus
relaciones. Muestran las opciones de realización incluyendo código fuente, binario y
ejecutable.
3. Planeación de la distribución, cuales muestran un despliegue de nodos (locales y
remotos), en la organización del sistema, mostrando el lugar donde se encuentran los
componentes.
4. Diseño y prototipos de la interfaz del sistema, en esta etapa se diseñan las
interfaces con que contara el producto final del proyecto.
5. Modelo y Diseño de la Base de datos
Los sistemas pueden dividirse en pequeños componentes o subsistemas, los cuales
colaboran y ayudan a comprender mejor el sistema general.
Para el diseño de Base de Datos se utiliza la técnica de conversión al modelo
Entidad/Relación, tomando la información de los diagramas de clases.
1. REQUERIMIENTO DE SOFTWARE Y HARDWARE
Para el desarrollo del siguiente proyecto se utilizaran, un conjunto de herramientas de software y
hardware, de manera que esta herramientas coadyuven en el desarrollo del sistema en sus
diferentes etapas, se hará uso de herramientas case, como Rational Rose para el diseño del
sistema y el entorno se desarrolla PHP y MySQL, para la programación del software y otras
herramientas que se describen en el siguiente capítulo de este documento.
2. IMPLEMENTACIÓN
Para realizar la implementación se debe agrupar todos los elementos que intervienen en el
desarrollo del sistema, incluyendo el manual del sistema, archivos de configuración, archivos de
datos, componentes de software, etc.
El manual del sistema tiene la finalidad de proporcionar la información del sistema, a nivel de
análisis de manera que permita realizar los cambios, codificaciones y eliminaciones.
La implementación es una colección de componentes y elementos del software, estos
componentes incluyen: ficheros ejecutables, ficheros de código fuente, y otros necesarios para la
implementación y despliegue del sistema.
En esta sección se realizara las siguientes tareas:
1. Generación de código.
2. Verificación de código.
3. Generación de interfaces del personal.
4. Manual de personal.
1. PRUEBAS
Las pruebas de software, es un proceso usado para identificar posibles fallas de implementación,
calidad o usabilidad del sistema. El objetivo de las pruebas es encontrar el mayor número de
posibles errores con una cantidad razonable de esfuerzo realizado, aplicando sobre un
determinado tiempo real.
En el presente proyecto se utilizaran las pruebas de estrategia del modelo espiral, por su
flexibilidad y por el máximo número de pruebas a realizar en el desarrollo del prototipo.
Fases del modelo espiral
1. Planteamiento de objetivos
2. Identificación y reducción de riesgos.
3. Desarrollo y validación.
4. Planeación.
1. MANTENIMIENTO DEL SISTEMA
El mantenimiento de software es una de las actividades más comunes en la ingeniería de
Software y es el proceso de mejora y optimización del software desplegado (es decir; revisión del
programa), así como también corrección de los defectos.
Tipos de mantenimiento
A continuación se señalan los tipos de mantenimientos existentes:
1. Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los
sistemas en cualquiera de sus aspectos: reestructuración del código, definición más
clara del sistema y optimización del rendimiento y eficiencia.
2. Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un
producto software para cubrir la expansión o cambio en las necesidades del personal.
3. Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema
opera, por ejemplo, cambios de configuración del hardware, software de base, gestores
de base de datos, comunicaciones, etc.
4. Correctivo: son aquellos cambios precisos para corregir errores del producto software.
1. CALIDAD DE SOFTWARE
La calidad de software es asegurar que los requerimientos del diseño estén satisfechos y que el
producto resultante cumpla los estándares funcionales y los requisitos funcionales.
Factores de calidad
Portabilidad, facilidad de transportar productos de software a varios ambientes de hardware. Se
mide probando el sistema en varios sistemas operativos.
Performance, es el desempeño con respecto al rendimiento de la computadora, un sistema
operativo o un programa. La evaluación se hace utilizando datos reprueba o reales, de manera
de verificar el rendimiento y los resultados del sistema.
Confiabilidad, es la certeza de que un componente, equipo o producto software realiza su
función prevista si incidentes por un periodo de tiempo. Para determinar la confiabilidad de
cualquier sistema es necesario definir, la función del sistema al igual que las situaciones o
condiciones que hacen perder la funcionalidad del sistema.
Funcionalidad, se refiere a representar la forma en que un componente, un dispositivo o un
equipo funciona; es decir, los mecanismos o secuencias de eventos que hacen que el objeto
realice cierta función.
La métrica del punto función, es un método para medir el tamaño del software. Pretende medir la
funcionalidad entregada al personal independientemente de la tecnología utilizada para la
construcción y explotación del software.
CAPITULO III
DESARROLLO DEL SISTEMA
3.1 INTRODUCCION
Este capítulo se enmarca en el flujo de trabajo fundamental, donde se especifican los
requerimientos del producto, desarrollo, construcción, implementación, pruebas, actividades de
mantenimiento y métricas del sistema.
3.2 RECOPILACION DE NECESIDADES
Se requiere optimizar el proceso de elaboración de control manual para que el funcionario
encargado de esta unidad lo pueda realizar en menor tiempo y sin riesgo de errores que se iban
cometiendo, como por ejemplo un mal cálculo en las horas trabajadas y con las horas de
tardanzas que efectúa.
R.R.H.H proporciona una planilla de asistencia a la Dirección Financiera (Unidad contable), para
la elaboración de planillas de pago, para el personal de planta planilla de sueldos y para el
personal que trabajo por contratos o consultorías planilla de salarios.
Los reportes son remitidas de la Dirección Financiera hacia R.R.H.H. para que cada funcionario
recoja su boleta, previa presentación de un informe de actividades mensuales, luego de recoger
las boletas se dirigen a caja para el cobro de su sueldo. En caso de contratos la Dirección
Financiera emite los cheques.
Los permisos por motivo de salud y cuenta vacación son registrados en R.R.H.H con 24 horas de
anticipación, en caso de problemas de salud si el funcionario no pudo solicitar su permiso de
salida; este puede regularizar su falta presentando el comprobante de baja médica de ESSALUD
o de SIS.
Las comisiones son registradas en un libro de actas donde se detalla la hora de salida, retomo,
destino y quien autoriza, el sistema propuesto tendrá un módulo que permita el registro de las
horas de entrada y salidas de comisión que será supervisado por el encargado de R.R.H.H
Descubrir los procesos de negocio
A continuación se descubren los cargos del personal encargado del control y elaboración de los
reportes.
1. Auxiliar contable, es el encargado de la elaboración de los reportes realizando una
tarea minuciosa, con los atrasos, faltas y aportes para luego efectuar el descuento según
el reglamento interno de la empresa.
2. Recursos Humanos, es el encargado del control de todo el personal, también se
encarga de las evaluaciones del personal, control de las vacaciones y permisos
3. Responsable de dirección administrativa, se encarga de la cotización y presupuesto
del nuevo personal según el cargo.
4. Personal de caja, se encarga de la emisión de cheques.
5. Responsable de contratos, realizan los contratos de personal que no son de planta, a
solicitud de los distintos departamentos según el trabajo a realizar.
Realizar un análisis del dominio
Descripción de actividades de la unidad de control del personal en la Universidades Nacional
José María Arguedas sede Administrativa
Las principales operaciones y funciones que desempeña la unidad de control de personal se
detalla a continuación.
1. Registro, cuando un nuevo personal es contratado, se registran todos sus datos
personales en un acta de contratos o acta de personal de planta.
2. Elaboración de las planillas de pago, la unidad contable realiza una planilla de
sueldos con los datos que proporciona la unidad de control, realiza una tarea minuciosa
en el cálculo de los descuentos que se realiza al personal ya sea por sanciones
(Tardanzas y Faltas) o los descuentos por aportes (ESSALUD, AFP Futuro, AFP-
BBVA).
3. Elaboración de boletas de salidas a comisión, recursos humano realiza las boletas
de salida cuando un personal es asignado a una comisión, también elabora las boletas
de cuenta vacación y permisos.
4. Control manual y marcador mecánico, el personal marca su hora de entrada y hora de
salida en un reloj digital, a la vez firma una planillas de asistencia, para la elaboración de
las planillas de pago.
Describir las necesidades del sistema
Luego del estudio preliminar, se identificó demora en la elaboración de control manual y la
información que brinda la unidad de control es poco fiable, esto porque no se cuenta con un
sistema de información que automatice los procesos y manejo de la información, por ello se
propone un sistema de control de personal que mejore los proceso que se realizan actualmente.
Identificación del producto
El software tiene como nombre Sistema de Control de Personal.
1. ¿Qué hará el sistema?
El sistema a desarrollarse tendrá los módulos de: registro de personal, generación de reportes,
evaluación del personal, control de vacaciones.
El sistema procesara automáticamente los cálculos necesarios para la elaboración de las
planillas como ser los descuentos al personal (Tardanzas, Faltas,ESSALUD, AFP Futuro, AFP-
BBVA).
1. Beneficios
Este producto software ayudara en las actividades básicas de la unidad de control y recursos
humanos, ayudará en el almacenamiento correcto de los datos del personal, además de brindar
información periódica y correcta de cada proceso.
3.3 ANÁLISIS
3.3.1 Análisis del sistema actual
Para obtener una visión completa de cómo se ejecuta el trabajo, es necesario realizar una
descripción de cada uno de los procesos que se realiza en la unidad de control del personal, de
la Universidades Nacional José María Arguedas sede Administrativa
Compresión del uso del sistema
La siguiente figura muestra los actores que intervienen en el actual sistema de la unidad de
control del personal.
Una de las técnicas utilizadas para recopilar la información acerca del funcionamiento de la
unidad de control, fue la entrevista, la cual proporciono información cualitativa, cabe mencionar
que sólo se entrevistó al personal que utilizara el sistema.
A continuación se detalla el funcionamiento, con las entrevistas realizadas. El resto del detalle se
encuentra el anexo B.