UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec/bitstream/redug/20335/1/TESIS FINAL... · 2018. 11. 19. · Este proyecto tiene como objetivo analizar y diseñar un sistema de distribución

I

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS ADMINISTRATIVAS

TESIS PRESENTADA COMO REQUISITO PARA OPTAR POR EL

TITULO DE: INGENIERIA EN SISTEMAS ADMINISTRATIVOS

COMPUTARIZADOS

TEMA: “ANÁLISIS Y DISEÑO DE UN SISTEMA DE

DISTRIBUCIÓN DE CARGAS HORARIAS PARA LOS

DOCENTES DE LA CARRERA I.S.A.C, UNIVERSIDAD DE

GUAYAQUIL.”

AUTORAS: SANDY PAMELA BARCIA GUZMÁN

GABRIELA ESTEFANIA CHILIQUINGA CASTILLO

TUTOR DE TESIS:

ING. RAUL HUREL GUZMÁN

GUAYAQUIL, NOVIEMBRE 2015

II

REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA

FICHA DE REGISTRO DE TESIS

TÍTULO “ANÁLISIS Y DISEÑO DE UN SISTEMA DE DISTRIBUCIÓN DE CARGAS HORARIAS PARA LOS DOCENTES

DE LA CARRERA I.S.A.C, UNIVERSIDAD DE GUAYAQUIL.”

REVISORES:

INSTITUCIÓN: Universidad de Guayaquil FACULTAD: Ciencias Administrativas

CARRERA: Ingeniería en Sistemas Administrativos Computarizados

FECHA DE PUBLICACIÓN: N° DE PÁGS.: 121

ÁREA TEMÁTICA: Sistemas

PALABRAS CLAVES: Indicadores

RESUMEN

Este proyecto tiene como objetivo analizar y diseñar un sistema de distribución de cargas horarias para los docentes de la

carrera ISAC de la Facultad de Ciencias Administrativas de la Universidad de Guayaquil, con el cual se pretende mejorar el

proceso mediante el uso de herramientas tecnológicas. Se pudo realizar el presente proyecto con la observación directa y la

información levantada. Concluimos que si se implementa el sistema de distribución de cargas horarias adaptando las

necesidades y realidades de la carrera se reducirá el tiempo de búsqueda de la información, generara los horarios

designados a los docentes, se iniciará la apertura y finalización de los ciclos en las fechas indicadas y bases de datos

actualizadas.

N° DE REGISTRO(en base de datos): N° DE CLASIFICACIÓN:

Nº

DIRECCIÓN URL (tesis en la web):

ADJUNTO PDF

SI

NO

CONTACTO CON AUTORES:

Sandy Pamela Barcia Guzmán

Gabriela Estefanía Chiliquinga Castillo

Teléfono:

0984793716

0985719848

E-mail:

[email protected]

[email protected]

CONTACTO DE LA INSTITUCIÓN Nombre:

Teléfono:

III

ÍNDICE GENERAL

UNIVERSIDAD DE GUAYAQUIL ................................................... I

ÍNDICE GENERAL ........................................................................ III

CERTIFICACIÓN DEL TUTOR .................................................... IV

CERTIFICACIÓN DE GRAMATÓLOGA ....................................... V

DEDICATORIA .............................................................................. VI

AGRADECIMIENTO ................................................................... VIII

RENUNCIA DE DERECHOS DE AUTOR ..................................... X

RESUMEN ..................................................................................... XI

ABSTRACT .................................................................................. XII

INDICE DE CONTENIDOS ......................................................... XIII

INDICE DE TABLAS .................................................................. XVI

INDICE DE FIGURAS ............................................................... XVII

IV

CERTIFICACIÓN DEL TUTOR

HABIENDO SIDO NOMBRADO, Ing. Raúl Hurel Guzmán MBA. , COMO

TUTOR DE TESIS DE GRADO COMO REQUISITO PARA OPTAR POR

TITULO DE Ingeniería en Sistemas Administrativos Computarizados

PRESENTADO POR LOS EGRESADOS: Sandy Pamela Barcia Guzmán

CON C.I # 0925025876, Gabriela Estefanía Chiliquinga Castillo CON C.I #

0928585942.

TEMA: “ANÁLISIS Y DISEÑO DE UN SISTEMA DE DISTRIBUCIÓN DE

CARGAS HORARIAS PARA LOS DOCENTES DE LA CARRERA I.S.A.C,

UNIVERSIDAD DE GUAYAQUIL.”

CERTIFICO QUE: HE REVISADO Y APROBADO EN TODAS SUS

PARTES, ENCONTRÁNDOSE APTO PARA SU SUSTENTACIÓN.

Ing. Raúl Hurel Guzmán

TUTOR DE TESIS

V

CERTIFICACIÓN DE GRAMATÓLOGA

QUIEN SUSCRIBE EL PRESENTE CERTIFICADO, SE PERMITE

INFORMAR QUE DESPUÉS DE HABER LEÍDO Y REVISADO

GRAMATICALMENTE EL CONTENIDO DE LA TESIS DE GRADO DE

Sandy Pamela Barcia Guzmán y Gabriela Estefanía Chiliquinga Castillo

CUYO TEMA ES: “ANÁLISIS Y DISEÑO DE UN SISTEMA DE

DISTRIBUCIÓN DE CARGAS HORARIAS PARA LOS

DOCENTES DE LA CARRERA I.S.A.C, UNIVERSIDAD DE

GUAYAQUIL.”

CERTIFICO QUE ES UN TRABAJO DE ACUERDO A LAS NORMAS

MORFOLÓGICAS, SINTÁCTICAS Y SIMÉTRICAS VIGENTES

ATENTAMENTE

Ing. Víctor Hugo Carrillo Pérez

VI

DEDICATORIA

Dedico este trabajo a mi familia, por haberme dado la oportunidad de tener

una buena educación e inculcado los valores de perseverancia y paciencia

para alcanzar mis logros personales y profesionales.

Pamela Barcia

VII

DEDICATORIA

Dedico este trabajo a mi hija Ashley quien es el motor de mi vida que con

cada palabra, sonrisa me da fuerzas y fortaleza necesaria de seguir

adelante y luchar por cada uno de mis sueños.

Gabriela Chiliquinga

VIII

AGRADECIMIENTO

Quiero agradecer a Dios, por darme salud, sabiduría y perseverancia para

culminar este proyecto.

A mi familia que me brindo todo el apoyo, comprensión y paciencia que

invertí para ser cada día mejor.

A mi tutor Ing. Raúl Hurel Guzmán MBA, por cada consejo y apoyo, quien

estuvo siempre presto para guiarnos en el buen desarrollo de la tesis.

A cada uno de los docentes, cuyas enseñanzas me acercaron cada vez a la

terminación de la carrera, y a mis amigos que han sido de gran apoyo.

Pamela Barcia

IX

AGRADECIMIENTO

Agradezco a Dios por darme salud, perseverancia y guiarme en cada paso

que doy y estar siempre conmigo y poder cumplir con una más de mis

metas.

A mi mamá y papá por su apoyo incondicional y por cada consejo que me

brindaron.

A mi prima Lady quién fue de gran ayuda en los momentos más difíciles y

quien me motivo para cumplir esta meta.

A mi tutor Ing. Raúl Hurel Guzmán MBA., quien ha sido de gran apoyo en

este proyecto.

Finalmente a Cristian y mi hija, por contar siempre con su apoyo, no tengo

palabras para describir todo lo que he sacrificado para culminar con una de

mis metas.

Gabriela Chiliquinga

X

RENUNCIA DE DERECHOS DE AUTOR

POR MEDIO DE LA PRESENTE CERTIFICO QUE LOS CONTENIDOS

DESARROLLADOS EN ESTA TESIS SON DE ABSOLUTA PROPIEDAD Y

RESPONSABILIDAD DE SANDY PAMELA BARCIA GUZMÁN, CON C.C.

# 092502587-6 Y GABRIELA ESTEFANIA CHILIQUINGA CASTILLO, CON

C.C.# 0928585942, CUYO TEMA ES:

“ANÁLISIS Y DISEÑO DE UN SISTEMA DE DISTRIBUCIÓN DE

CARGAS HORARIAS PARA LOS DOCENTES DE LA

CARRERA I.S.A.C, UNIVERSIDAD DE GUAYAQUIL.”

DERECHOS QUE RENUNCIAMOS A FAVOR DE LA UNIVERSIDAD DE

GUAYAQUIL, PARA QUE HAGA USO COMO A BIEN TENGA.

SANDY PAMELA BARCIA GUZMÁN C.I. #092502587-6

GABRIELA ESTEFANIA CHILIQUINGA CASTILLO C.I. #092858594-2

GUAYAQUIL, NOVIEMBRE 2015

XI

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS ADMINISTRATIVAS

TESIS PRESENTADA COMO REQUISITO PARA OPTAR POR EL TITULO

DE INGENIERO EN SISTEMAS ADMINISTRATIVOS COMPUTARIZADOS.

TEMA: “ANÁLISIS Y DISEÑO DE UN SISTEMA DE DISTRIBUCIÓN DE

CARGAS HORARIAS PARA LOS DOCENTES DE LA CARRERA I.S.A.C,

UNIVERSIDAD DE GUAYAQUIL.”

AUTORES: SANDY PAMELA BARCIA GUZMÁN C.I. # 092502587-6 Y

GABRIELA ESTEFANIA CHILIQUINGA CASTILLO C.I. # 092858594-2

RESUMEN

Este proyecto tiene como objetivo analizar y diseñar un sistema de

distribución de cargas horarias para los docentes de la carrera ISAC de la

Facultad de Ciencias Administrativas de la Universidad de Guayaquil en un

entorno de escritorio, con el cual se pretende mejorar el proceso mediante el

uso de herramientas tecnológicas. Se pudo realizar el presente proyecto con

la observación directa y la información levantada. Concluimos que si se

implementa el sistema de distribución de cargas horarias adaptando las

necesidades y realidades de la carrera se reducirá el tiempo de búsqueda de

la información, generara los horarios designados a los docentes, se iniciará

la apertura y finalización de los ciclos en las fechas indicadas y bases de

datos actualizadas.

XII

ABSTRACT

This project aims to analyze and design a system of distribution of time for

the ISAC Career Teachers Faculty of Administrative Sciences at the

University of Guayaquil in desktop environment loads, with which it is

intended to improve the process by using technological tools. It could make

this project with direct observation and raised information. We conclude that

if the Distribution System is implemented teaching loads matching the needs

and realities of the career search time information is reduced, designated

times to generate Teachers, opening and ending cycles began in dates

indicated and updated databases.

XIII

INDICE DE CONTENIDOS

INTRODUCCIÓN............................................................................ 1

CAPÍTULO 1 PRESENTACIÓN DEL PROYECTO....................... 3

1.1 ANTECEDENTES .................................................................................... 3

1.2 ANÁLISIS DE LA SITUACIÓN ACTUAL .................................................. 3

1.3 FORMULACIÓN Y SISTEMATIZACIÓN DEL PROBLEMA ..................... 3

1.4 OBJETIVOS DE LA INVESTIGACIÓN ..................................................... 4

1.5 JUSTIFICACIÓN ...................................................................................... 5

CAPÍTULO 2 ENTORNOS TEÓRICOS Y DE CONTEXTO .......... 7

2.1 MARCO TEÓRICO .................................................................................. 7

2.1.1 MARCO TECNOLÓGICO ...................................................................... 8

2.1.1.1 Marco tecnológico conceptual:............................................................ 8

2.1.2 MARCO METODOLÓGICO ................................................................ 10

2.1.2.1 Metodologías ágiles .......................................................................... 11

2.1.2.2 Características de las metodologías ................................................. 12

2.1.2.3 El Manifiesto Ágil .............................................................................. 12

2.1.2.4 Las principales diferencias entre las metodologías ágiles con

respecto a las tradicionales. ......................................................................... 15

2.1.2.5 Clasificación de las metodologías ..................................................... 16

2.1.2.5.1 Metodologías estructuradas ........................................................... 16

2.1.2.6 Metodologías de desarrollo de software más populares ................... 19

2.1.2.7 Tipos de metodologías ágiles ........................................................... 20

2.1.2.7.1 Programación Extrema o XP (Extreme Programming) ................... 20

2.1.2.7.2 Metodología cristal (Crystal methodologies) .................................. 21

2.1.2.7.3 Método de desarrollo de sistema dinámico (Dynamic system

development method). .................................................................................. 22

2.1.2.7.4 Desarrollo de software adaptable (Adaptive software

development). ............................................................................................... 23

2.1.2.7.5 Desarrollo basado en funciones (Feature-Driven development) .... 24

XIV

2.1.2.7.6 Metodología Lean (Lean Development) ......................................... 25

2.1.2.7.7 Scrum. ............................................................................................ 25

2.1.2.8 Características del proceso de scrum ............................................... 26

2.1.2.9 Componentes de scrum .................................................................... 30

2.1.2.10 Las historias de los usuarios .......................................................... 33

2.1.2.11 Desarrollo de las fases de un proyecto en scrum .......................... 38

2.1.2.12 Proceso de la metodología scrum .................................................. 55

2.1.2.13 Ventajas de la metodología scrum ................................................. 56

2.1.3 MARCO ANDRAGÓGICO ................................................................... 56

2.2 MARCO CONTEXTUAL ......................................................................... 57

2.3 HIPÓTESIS ............................................................................................ 57

CAPÍTULO 3 PROBLEMÁTICA .................................................. 58

3.1 ANTECEDENTES DE LA CARRERA ISAC .......................................... 58

3.1.1 MISIÓN………….. ............................................................................... 58

3.1.2 VISIÓN….. ........................................................................................... 59

3.1.3 UBICACIÓN GEOGRÁFICA ................................................................ 59

3.2 SITUACIÓN ACTUAL DE LA PROBLEMATICA .................................... 60

3.2.1 ESTRUCTURA ORGANIZACIONAL DE ISAC .................................... 60

3.2.2 PERSONAL QUE LABORA EN ISAC ................................................. 61

3.3 FORMULACIÓN DEL PROBLEMA ........................................................ 61

3.3.1 DESCRIPCIÓN DEL PROBLEMA ....................................................... 61

3.3.2 ANÁLISIS DE LA SITUACIÓN DEL PROBLEMA ................................ 62

3.3.3 DIAGRAMA CAUSA-EFECTO DEL PROBLEMA................................ 63

3.3.4 DEFINICIÓN DEL PROBLEMA ........................................................... 64

3.3.5 FORMULACIÓN DEL PROBLEMA ..................................................... 64

3.4 REUNIONES CON EL CLIENTE ............................................................ 65

3.4.1 REQUERIMIENTOS DEL SISTEMA. ................................................... 65

CAPÍTULO 4 PROPUESTA......................................................... 69

4.1 SOLUCIÓN PROPUESTA ..................................................................... 69

4.2 DETERMINACIÓN DE FACTIBILIDAD DE LA PROPUESTA................ 69

4.2.1 FACTIBILIDAD TÉCNICA ................................................................... 70

XV

4.2.1.1 Requerimientos de software ............................................................. 70

4.2.1.2 Requerimientos de hardware ............................................................ 70

4.2.2 FACTIBILIDAD ECONÓMICA ............................................................. 71

4.2.3 FACTIBILIDAD OPERACIONAL ......................................................... 71

4.3 ANÁLISIS ESTRUCTURADO ................................................................ 72

4.3.1 DIAGRAMAS DE CASOS DE USO ..................................................... 72

4.3.2 DIAGRAMAS DE FLUJO DE DATOS (DFD) ....................................... 78

4.3.3 DIAGRAMA DE BASE DE DATOS...................................................... 79

4.4 DICCIONARIO DE DATOS .................................................................... 80

4.5 DISEÑO DE LAS PANTALLAS DEL SISTEMA ...................................... 84

4.6 PLAN DE PROYECTO BAJO LA METODOLOGÍA SCRUM .................. 98

CONCLUSIONES Y RECOMENDACIONES .............................. 99

CONCLUSIONES ......................................................................................... 99

RECOMENDACIONES ............................................................................... 100

BIBLIOGRAFÍA .......................................................................... 101

XVI

INDICE DE TABLAS

CAPÍTULO 2

TABLA 2.1 DIFERENCIAS ENTRE LA METODOLOGÍA AGIL Y LA

TRADICIONAL .............................................................................................. 15

CAPÍTULO 3

TABLA 3.1 PERSONAL ADMINISTRATIVO ................................................. 61

CAPÍTULO 4

TABLA 4.1 REQUERIMIENTOS DE SOFTWARE ........................................ 70

TABLA 4.2 REQUERIMIENTOS DE HARDWARE ....................................... 71

TABLA 4.3 DICCIONARIO DE DATOS ........................................................ 80

XVII

INDICE DE FIGURAS

CAPÍTULO 2

FIGURA 2.1 CICLO DEL DESARROLLO ÁGIL ........................................... 29

FIGURA 2.2 CICLO PRINCIPAL DEL SCRUM ............................................ 30

FIGURA 2.3 CICLO DE DESARROLLO SCRUM ........................................ 33

FIGURA 2.4 EJEMPLO DE HISTORIA DE USUARIO .................................. 34

FIGURA 2.5 EJEMPLO DE UN PRODUCT BACKLOG ................................ 36

FIGURA 2.6 EJEMPLO DE SPRINT BACKLOG .......................................... 36

FIGURA 2.7 ENTRADAS Y SALIDAS DE UN PLANNING MEETING .......... 43

FIGURA 2.8 EJEMPLO DE UN GRAFICO DE AVANCE DE UN SPRINT ... 45

FIGURA 2.9 EJEMPLOS DE SCRUM TASK BOARD ................................. 46

FIGURA 2.10 DIAGRAMA DETALLADO DE LAS FASES DE SCRUM....... 54

CAPÍTULO 3

FIGURA 3.1 UBICACIÓN ............................................................................. 59

FIGURA 3.2 DIAGRAMA CAUSA-EFECTO DEL PROBLEMA .................... 64

CAPÍTULO 4

FIGURA 4.1 DIAGRAMA DE CASO DE USO ADMINISTRADOR ............... 72

FIGURA 4.2 DIAGRAMA DE CASO DE USO ADMINISTRADOR-

DOCENTE ................................................................................................... 73

FIGURA 4.3 DIAGRAMA DE CASO DE USO ADMINISTRADOR-

ASIGNATURA ............................................................................................. 73

FIGURA 4.4 DIAGRAMA DE CASO DE USO ADMINISTRADOR -

ACTIVIDAD ................................................................................................... 74


HORARIO ..................................................................................................... 74

FIGURA 4.6 DIAGRAMA DE CASO DE USO ADMINISTRADOR-CARGA

HORARIA ..................................................................................................... 75

FIGURA 4.7 DIAGRAMA DE CASO DE USO ADMINISTRADOR-ASIGNA

ACTIVIDAD ................................................................................................... 76

XVIII


INVITADO ..................................................................................................... 76

FIGURA 4.9 DIAGRAMA DE CASO DE USO ADMINISTRADOR-INVITADO-

CONSULTA .................................................................................................. 77

FIGURA 4.10 DIAGRAMA DE FLUJO DE DATOS ....................................... 78

FIGURA 4.11 MODELO ENTIDAD RELACIÓN ........................................... 79

FIGURA 4.12 PANTALLA PRINCIPAL-INGRESO AL SISTEMA ................. 85

FIGURA 4.13 PANTALLA DE MENÚ DEL SISTEMA ................................... 85

FIGURA 4.14 PANTALLA DEL MENÚ DE DOCENTES ............................... 86

FIGURA 4.15 PANTALLA DEL REGISTRO DEL DOCENTE ....................... 86

FIGURA 4.16 PANTALLA DEL MENÚ DE DOCENTES-CONSULTAS ........ 87

FIGURA 4.17 PANTALLA DE CONSULTA POR TÍTULO ............................ 87

FIGURA 4.18 PANTALLA DEL MENÚ DE DOCENTES-CONSULTAS POR

DOCENTES .................................................................................................. 88

FIGURA 4.19 PANTALLA DE CONSULTA POR DOCENTES ..................... 88

FIGURA 4.20 PANTALLA DEL MENÚ MATERIAS ...................................... 89

FIGURA 4.21 PANTALLA DEL REGISTRO DE LAS MATERIAS ................ 89

FIGURA 4.22 PANTALLA DEL MENÚ DE MATERIAS-CONSULTAS POR

NOMBRE ...................................................................................................... 90

FIGURA 4.23 PANTALLA DE BUSQUEDA POR NOMBRE DE LA

MATERIA ...................................................................................................... 90

FIGURA 4.24 PANTALLA DEL MENÚ DE MATERIAS-CONSULTAS POR

MATERIAS ................................................................................................... 91

FIGURA 4.25 PANTALLA DE BUSQUEDA POR TODAS LAS MATERIAS . 91

FIGURA 4.26 PANTALLA DEL MENÚ ACTIVIDADES ................................. 92

FIGURA 4.27 PANTALLA DE REGISTRO DE ACTIVIDADES ..................... 92

FIGURA 4.28 PANTALLA DEL MENÚ ACTIVIDADES-CONSULTA ............ 93

FIGURA 4.29 PANTALLA DE CONSULTA DE ACTIVIDADES .................... 93

FIGURA 4.30 PANTALLA DEL MENÚ CARGAS HORARIAS ...................... 94

FIGURA 4.31 PANTALLA DE ASIGNACIÓN DE CARGAS HORARIAS

DOCENTE .................................................................................................... 94

FIGURA 4.32 PANTALLA DEL MENÚ CARGAS HORARIAS- MATERIA .... 95

FIGURA 4.33 PANTALLA DE ASIGNACIÓN DE MATERIAS ...................... 95

FIGURA 4.34 PANTALLA DEL MENÚ CARGAS HORARIAS- ACTIVIDAD . 96

XIX

FIGURA 4.35 PANTALLA DE ASIGNACIÓN DE ACTIVIDADES ................. 96

FIGURA 4.36 PANTALLA DEL MENÚ CONSULTAS ................................... 97

FIGURA 4.37 PANTALLA DONDE SE GENERA EL HORARIO DEL

DOCENTE .................................................................................................... 97

ANÁLISIS Y DISEÑO DE UN SISTEMA DE DISTRIBUCIÓN DE CARGAS HORARIAS

PARA LOS DOCENTES DE LA CARRERA I.S.A.C, UNIVERSIDAD DE GUAYAQUIL.

1 INTRODUCCIÓN

INTRODUCCIÓN

Actualmente en todas las unidades educativas se maneja cierta cantidad de

información que requiere la gestión de determinados procesos para el

desenvolvimiento en las respectivas áreas, deben contar con sistemas y

herramientas tecnológicas para estar en constante desarrollo.

En la mayoría de las unidades educativas ha ido introduciendo la tecnología

como una herramienta de apoyo, ya que en la actualidad es una necesidad

contar con ellas para no estar obsoletos en el mercado correspondiente,

facilitan muchas tareas en los diferentes procesos que se realicen.

La constante evolución que se da día a día en la tecnología, hace que se

desarrollen nuevas aplicaciones, sistemas y diseños innovadores

dependiendo de las necesidades que se requieran.

La carrera de Ingeniería de Sistemas Administrativos computarizados de la

Universidad de Guayaquil realiza de forma manual la distribución de cargas

académicas, preparación de clases y tutorías.

Este proyecto tiene como finalidad presentar una solución mediante el

análisis y diseño de un sistema informático que permitirá al director de la

carrera mejorar la gestión del proceso ahorrando tiempo y aprovechando las

herramientas con que cuentan y los recursos que se tienen destinados para

lograr el objetivo.

CAPÍTULO 1: PRESENTACIÓN DEL PROYECTO.- Se desarrollo el

planteamiento del problema a resolver, mediante la formulación y

sistematización, se definió los objetivos que guiarán el proceso de

investigación para el desarrollo de análisis y diseño del proyecto.



2 INTRODUCCIÓN

CAPÍTULO 2: ENTORNOS TEÓRICOS Y DE CONTEXTO.- Nos centramos

en los conceptos y teorías que se utilizaron para formular y desarrollar la

tesis. El tipo de metodologías ágiles que se utilizó para el desarrollo del

análisis y diseño del sistema.

CAPÍTULO 3: PROBLEMÁTICA.- Se analizó los antecedentes, la situación

actual de la problemática de la carrera, la formulación, la descripción del

problema, definición del problema y los requerimientos que debe tener el

sistema.

CAPÍTULO 4: PROPUESTA.- Se da a conocer la solución de la propuesta,

la factibilidad de implementar el sistema, un análisis estructurado diagramas

de caso de uso, de flujo de datos, el modelo de la base de datos, el diseño

de las pantallas del sistema.

CONCLUSIONES Y RECOMENDACIONES.- Se presentará las

conclusiones y recomendaciones de la investigación del proyecto, para llevar

a cabo la implementación el análisis y diseño del sistema propuesto.



3 CAPITULO 1

PRESENTACIÓN DEL PROYECTO

CAPÍTULO 1


1.1 ANTECEDENTES

Desde el inicio de la carrera de Ingeniería en Sistemas Administrativas

Computarizados de la Facultad de Ciencias Administrativas de la

Universidad de Guayaquil ha venido haciendo los procesos de distribución

manualmente ya que la Universidad no cuenta con los recursos

necesarios para la utilización de sistemas o herramientas tecnológicas.

1.2 ANÁLISIS DE LA SITUACIÓN ACTUAL

La situación actual de la carrera de Ingeniería en Sistemas

Administrativos Computarizados no cuentan con un sistema o herramienta

que ayude hacer el proceso de distribución de las cargas horarias de los

docentes, por el cual utilizan una herramienta de office que es difícil de

mantener actualizada por los cambios que se realizan continuamente,

debido a que es un método empírico ocasionando pérdida de tiempo,

cruce de docentes.

1.3 FORMULACIÓN Y SISTEMATIZACIÓN DEL PROBLEMA

¿Es posible lograr la optimización de los recursos, procesos y mejorar la

explotación de la información en la carrera Ingeniería en Sistemas



4 CAPITULO 1


Administrativos Computarizados para cumplir con los tiempos

programados?

¿Se podrá realizar la distribución en un tiempo determinado sin retraso

alguno?

¿Con esta herramienta se puede apoyar los procesos de la distribución de

las cargas horarias de los docentes?

¿Se contará con una base de datos actualizada?

¿Se contará con una herramienta de fácil manejo para el usuario?

1.4 OBJETIVOS DE LA INVESTIGACIÓN

a) Objetivo general

Manejar eficazmente la distribución de las cargas horarias de los

docentes de la carrera de Ingeniería en Sistemas Administrativas

Computarizados para: iniciar sin retraso, reportes de las cargas

horarias de docentes, manejo de la base de datos, seguimiento a

los docentes y disponibilidad de información para la parte

administrativa.

b) Objetivos específicos

I. Contar con un software que nos permita controlar el tiempo

productivo en la carrera Ingeniería en Sistemas

Administrativos Computarizados (ISAC).

II. Recopilar y consignar una base de datos de cada uno de los

docentes con su respectivo horario y perfil académico.



5 CAPITULO 1


III. Realizar un levantamiento de la información del proceso

manual que permita formar una idea clara de los

requerimientos del sistema y en base a ello, realizar los

diagramas respectivos que se van a utilizar para el punto de

vista funcional.

IV. Diseñar las interfaces que permitan interactuar con el

usuario de la manera más fácil.

1.5 JUSTIFICACIÓN

a) Justificación teórica

El diseño elegido como software previo a la obtención del título de

Ingeniería en Sistemas Administrativos Computarizados se debe a

los avances tecnológicos ya que existen en algunas carreras de la

Universidad de Guayaquil que no cuentan con un software para

poder realizar las cargas horarias de sus docentes de una manera

eficaz y eficiente.

El diseño de este software será en Microsoft Visual Studio 2013

herramientas de actualidad y con una base de datos SQL Server,

ya que facilitaran el mejor diseño del software.

El diseño de este software nos permitirá plasmar cada uno de los

conocimientos adquiridos en clases de esta manera también

adquirir nuevos conocimientos a través de la investigación e

implementación.

b) Justificación metodológica

El diseño de un software que forma parte del presente proyecto,

inicia con un diagnóstico de la situación actual de los procesos de



6 CAPITULO 1


distribución de cargas horarias de los docentes, al fin de obtener

las actividades que cumple cada uno de ellos.

La base de datos con la que contaremos permitirá la visualización

de toda la información del docente, de tal forma se sabrá qué

materia pueden impartir y toda el área administrativa podrá tener

dicha información con sus respectivas distribuciones.

c) Justificación práctica

Un software es de suma importancia en toda institución académica,

ya que ayuda a tener una información oportuna, real y disponible

diariamente. Ayuda a la toma de decisiones a nivel académico las

cuales son de gran importancia para el crecimiento y desarrollo de

la institución, enfocándose en el horario de cátedra y actividad

extracurriculares de los docentes.



7 CAPITULO 2

ENTORNOS TEÓRICOS Y DE CONTEXTO

CAPÍTULO 2


2.1 MARCO TEÓRICO

A lo largo del tiempo el desarrollo de software ha sido una difícil tarea.

Prueba de esto es que existen varias metodologías que inciden en las

distintas fases del proceso de desarrollo. Por una parte, están aquellas

metodologías tradicionales que se basan especialmente en el control del

proceso, estableciendo rigurosamente las actividades involucradas y las

herramientas que se usaran.

Hoy en día existen nuevas metodologías de las cuales se basan en el

manifiesto para el desarrollo de un software ágil.

“Scrum es un marco de trabajo estructurado para dar soporte al desarrollo

de productos complejos. Scrum consiste en los equipos scrum y en sus

roles, eventos, artefactos y reglas asociadas. Cada componente dentro

del marco de trabajo sirve a un propósito específico y es esencial para el

éxito de scrum y para su uso.” (Ken Schwaber y Jeff Sutherland 1991-

2011)



8 CAPITULO 2


2.1.1 MARCO TECNOLÓGICO

2.1.1.1 Marco tecnológico conceptual:

Software: Es un término informático que hace referencia a un programa o

conjunto de programas de cómputo que incluye datos, procedimientos y

pautas que permite realizar distintas tareas en un sistema informático.

SIGNIFICADOS.COM/SOFTWARE/

Base de Datos: Es el conjunto de datos informativos organizados en un

mismo contexto para su uso y vinculación. Se llaman así a los bancos de

información que contienen datos relativos a diversas temáticas y

categorizados de distinta manera, pero que comparten entre si algún tipo

de vinculo o relación que busca ordenarlos y clasificarlos en conjunto.

DEFINICIONABC.COM/TECNOLOGIA/BASE-DE-DATOS.PHP

Programa: Conjunto de instrucciones que son impartidos hacia el

ordenador indicando las instrucciones que incluyen el paso por paso para

poder llegar a un resultado determinado, debiendo para ello tener una

organización especifica y seguir los pasos de una estructura, teniendo

entonces predefinidas una serie de acciones que son seguidas para

obtener el resultado esperado. MASTERMAGAZINE.INFO/TERMINO/6390.PHP

Heurística: Es la capacidad que ostenta un sistema determinado para

realizar de manera inmediata innovaciones positivas para sí mismo y sus

propósitos. DEFINICIONABC.COM/GENERAL/HEURISTICA.PHP

C#: Es un lenguaje de programación orientado a objetos creado por

Microsoft. DESARROLLOWEB.COM/ARTICULOS/561.PHP

http://www.significados.com/software/

http://www.definicionabc.com/tecnologia/base-de-datos.php

http://www.mastermagazine.info/termino/6390.php

http://www.definicionabc.com/general/heuristica.php

http://www.desarrolloweb.com/articulos/561.php



9 CAPITULO 2


Sql Server: Es un sistema de gestión de bases de datos relacionales de

Microsoft que está diseñado para el entorno empresarial.

SEARCHDATACENTER.TECHTARGET.COM/ES/DEFINICION/SQL-SERVER

Visual Studio: Es un conjunto completo de herramientas de desarrollo

para la generación de aplicaciones web ASP.NET, Servicios Web XML,

aplicaciones de escritorio y aplicaciones móviles. MSDN.MICROSOFT.COM/ES-

ES/LIBRARY/FX6BK1F4(V=VS.90).ASPX

Memoria RAM: Es la memoria principal de un dispositivo donde se

almacena programas y datos informáticos. SIGNIFICADOS.COM/MEMORIA-RAM/

GB o Gigabyte: Se trata de una unidad de medida y puede tener distintas

equivalencias de acuerdo a su uso. DEFINICION.DE/GIGABYTE/

Pc o Personal Computer: Es una maquina programable. Son

ordenadores modernos son eléctricos y digitales.

MASADELANTE.COM/FAQS/ORDENADOR

Cpu o Unidad de Procesamiento Central: Es la parte central de toda

computadora ya que es la que cumple la tarea de procesamiento de

todas las funciones así como también de almacenamiento de la

información. DEFINICIONABC.COM/TECNOLOGIA/CPU.PHP

Multidisciplinar: Es un proceso mediante el cual varias disciplinas

coinciden para cumplir un determinado objetivo.

FIDO.PALERMO.EDU/SERVICIOS_DYC/BLOG/DOCENTES/

Eficaz: Que tiene la virtud de producir el efecto deseado.

ES.THEFREEDICTIONARY.COM/EFICAZ

Sistema: Es un modulo ordenado de elementos que se encuentran

interrelacionados y que interactúan entre sí. DEFINICION.DE/SISTEMA/

http://searchdatacenter.techtarget.com/es/definicion/SQL-Server

https://msdn.microsoft.com/ES-ES/LIBRARY/FX6BK1F4(V=VS.90).ASPX

https://msdn.microsoft.com/ES-ES/LIBRARY/FX6BK1F4(V=VS.90).ASPX

http://www.significados.com/memoria-ram/

http://definicion.de/gigabyte/

https://www.masadelante.com/faqs/ordenador

http://www.definicionabc.com/TECNOLOGIA/CPU.PHP

http://fido.palermo.edu/SERVICIOS_DYC/BLOG/DOCENTES/

http://es.thefreedictionary.com/EFICAZ

http://definicion.de/sistema/



10 CAPITULO 2


Herramientas tecnológicas: Son programas, aplicaciones o simplemente

instrucciones usadas para efectuar otras tareas de modo más sencillo.

MASTERMAGAZINE.INFO/TERMINO/5234.PHP

Optimización: La mejor forma de hacer algo. Más eficiencia en el

desempeño de alguna tarea. SIGNIFICADOS.COM/OPTIMIZAR/

Procesos: Un conjunto de acciones o actividades sistematizadas que se

realizan o tienen un lugar con un fin.

DEFINICIONABC.COM/GENERAL/PROCESO.PHP

Diagrama: Es un grafico que representa un proceso o refleja relaciones

entre datos números que han sido tabulados previamente.

DEFINICION.MX/DIAGRAMA/

Interface: Representa a la comunicación entre actores mediante un

protocolo determinado, realizando una conexión física para realizar una

función determinada tanto entre dos dispositivos como bien entre dos

sistemas completamente diferentes, realizando así una comunicación.

MASTERMAGAZINE.INFO/TERMINO/5400.PHP

Eficiente: Que consigue un propósito empleado los medios idóneos.

WORDREFERENCE.COM/DEFINICION/EFICIENTE

2.1.2 MARCO METODOLÓGICO

El Marco metodológico se encarga de revisar los procesos a realizar para

el proyecto, no solo analiza que pasos se deben seguir para la optima

resolución del problema, también lo determina, las herramientas que se

van a emplear, ayudarán de manera factible a solucionar el problema.


http://www.significados.com/optimizar/

http://www.definicionabc.com/general/proceso.php

http://definicion.mx/diagrama/


http://www.wordreference.com/definicion/eficiente



11 CAPITULO 2


Esto se refiere a la serie de pasos o métodos que se deben plantear, para

saber cómo seguir con el proyecto.

En un proceso de proyecto que es necesario tener en cuenta todos los

factores que influyen en el problema, como su contexto, condiciones,

cambios y principios.

2.1.2.1 Metodologías ágiles

Tras una reunión en Utah-EEUU en febrero del 2001 nace el término “ágil”

aplicado en el desarrollo de software. Su objetivo fue esbozar los valores

y principios que deberían permitir a los equipos desarrollar software

rápidamente y respondiendo a los cambios que puedan surgir a lo largo

del proyecto.

Con esto se ofrece una alternativa a los procesos de desarrollo de

software tradicionales, caracterizados por ser rígidos y dirigidos por la

documentación que se genera en cada una de las actividades.

Después de esa reunión se creó The Agile Alliance

AGILEMANIFESTO.ORG/HISTORY.HTMl una organización sin ánimo de lucro,

dedicada a promover los conceptos relacionados con el desarrollo ágil de

software y ayudar a las organizaciones para que adopten dichos

conceptos. Partiendo desde el manifiesto ágil.

El desarrollo ágil de software, no es más que una metodología de gestión

de proyectos adaptiva, que permite llevar a cabo proyectos de desarrollo

de software adaptándose a los cambios y evolucionando en forma

conjunta.

http://www.agilemanifesto.org/history.html



12 CAPITULO 2


2.1.2.2 Características de las metodologías

Existen varias características que debe tener una metodología de

desarrollo, estas varía de acuerdo al modelo propuesto por cada una, la

mayoría utiliza parámetros que nos llevan a cumplir estándares de calidad

son las siguientes:

Reglas predefinidas

Verificaciones en cada etapa

Planificación y control

Comunicación efectiva entre desarrolladores y usuarios

Soporte de herramientas automatizadas

2.1.2.3 El Manifiesto Ágil ISSI.DSIC.UPV.ES/ARCHIVES/F-1069167248521/ACTAS.PDF

Según el Manifiesto se valora:

“Al individuo y las interacciones del equipo de desarrollo

sobre el proceso y las herramientas. La gente es el principal

factor de éxito de un proyecto software, es más importante

construir un buen equipo que construir el entorno. Muchas veces se

comete el error de construir primero el entorno y esperar que el

equipo se adapte automáticamente, es mejor crear el equipo y este

que configure su propio entorno de desarrollo en base a sus

necesidades.”

“Desarrollar software que funciona más que conseguir una

buena documentación. La regla a seguir es “no producir

http://issi.dsic.upv.es/ARCHIVES/F-1069167248521/ACTAS.PDF



13 CAPITULO 2


documentos a menos que sean necesarios de forma inmediata

para tomar una decisión importante”, estos documentos deben ser

cortos y centrarse en lo fundamental.”

“La colaboración con el cliente más que la negociación de un

contrato. Se propone que exista una interacción constante entre el

cliente y el equipo de desarrollo, esta colaboración entre ambos

será la que marque la marcha del proyecto y asegure su éxito.”

“Responder a los cambios más que seguir estrictamente un

plan. La habilidad de responder a los cambios que puedan surgir a

lo largo del proyecto (cambios en los requisitos, tecnología, en el

equipo, etc.) determina también el éxito o fracaso del mismo, por lo

tanto la planificación no debe ser estricta sino flexible y abierta.”

Los valores mencionados inspiran los doce principios del manifiesto. Son

características que diferencian un proceso ágil de uno tradicional. Los dos

primeros principios son generales y resumen gran parte del espíritu ágil, el

resto tiene que ver con el proceso a seguir y con el equipo de desarrollo,

en cuanto a metas a seguir y organización del mismo.

Principios:

1. La prioridad es satisfacer al cliente mediante tempranas y

continuas entregas de software que le aporte un valor.

2. Dar la bienvenida a los cambios, se capturan los cambios para

que el cliente tenga una ventaja competitiva.

3. Entregar frecuentemente software que funciones desde un par de

semanas a un par de meses, con el menor intervalo de tiempo

posible entre entregas.



14 CAPITULO 2


4. La gente del negocio y los desarrolladores deben trabajar juntos a

los largo del proyecto.

5. Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir

finalizar el trabajo.

6. El dialogo cara a cara es el método más eficientes y efectivo para

comunicar información dentro del equipo de desarrollo.

7. El software que funciona es la medida principal del progreso.

8. Los procesos ágiles promueven un desarrollo sostenible, los

promotores desarrolladores y usuarios deberían ser capaces de

mantener una paz constante.

9. La atención continua a la calidad técnica y al buen diseño mejora

la agilidad.

10. La simplicidad es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de los

equipos organizados por sí mismo.

12. En intervalos regulares, el equipo reflexiona respecto a cómo

llegar a ser más efectivo y según esto ajusta su comportamiento.



15 CAPITULO 2


2.1.2.4 Las principales diferencias entre las metodologías ágiles con

respecto a las tradicionales. ISSI.DSIC.UPV.ES/ARCHIVES/F-

1069167248521/ACTAS.PDF

Estas diferencias que afectan no solo al proceso en sí, sino también al

contexto del equipo así como a su organización.

TABLA 2.1

DIFERENCIAS ENTRE LA METODOLOGÍA ÁGIL Y LA TRADICIONAL

METODOLOGIAS ÁGILES METODOLOGIAS TRADICIONALES

Basadas en heurísticas

provenientes de prácticas de

producción de código.

Basadas en normas provenientes de

estándares seguidos por el entorno de

desarrollo.

Especialmente preparados para

cambios durante el proyecto. Cierta resistencia a los cambios.

Proceso menos controlado, con

pocos principios.

Proceso mucho más controlado, con

numerosas políticas/normas.

No existe contrato tradicional o al

menos es bastante flexible. Existe un contrato prefijado.

El cliente es parte del equipo de

desarrollo.

El cliente interactúa con el equipo de

desarrollo mediante reuniones.

Grupos pequeños <10 integrantes

y trabajando en el mismo sitio.

Pocos artefactos.

Grupos grandes y posiblemente

distribuidos.

Más artefactos.

Pocos roles. Más roles.

Menos énfasis en la arquitectura

del software.

La arquitectura del software es esencial

y se expresa mediante roles.

FUENTE: ISSI.DSIC.UPV.ES/ARCHIVES/F-1069167248521/ACTAS.PDF

Tener metodologías diferentes para aplicar de acuerdo con el proyecto

que se desarrolle resulta una idea interesante. Estas metodologías

pueden involucrar prácticas ágiles como tradicionales. De esta manera

podríamos tener una metodología para cada proyecto.

Es importante tener en cuenta que el uso de un método ágil no es para

todos. Sin embargo, una de las principales ventajas de métodos ágiles es

su peso inicialmente ligero y por eso las personas que no estén






16 CAPITULO 2


acostumbradas a seguir procesos encuentran estas metodologías

bastante agradables.

2.1.2.5 Clasificación de las metodologías

2.1.2.5.1 Metodologías estructuradas

Los problemas en la estructura y composición de un proyecto pueden ser

dirigidos por una metodología de desarrollo estructurada ya que esta

permite una descomposición funcional de problemas en unidades más

pequeñas que se relacionan entre sí, las mismas que pueden ser

representadas en flujos de datos y de manera jerárquica con la finalidad

de tener una visión más clara del proyecto.

Los proyectos implementados utilizando estas metodologías, utilizan

mucho la manipulación de datos de los procesos basándose en ciclos de

vida en cascada.

Metodologias Agiles

Estructuradas

Orientada a procesos

Orientada a datos

Mixtas

No estructuradas

Orientada a Objetos

Sistema de tiempo real



17 CAPITULO 2


Su principio fundamental es examinar el sistema desde las funciones y

tareas, mientras que en las metodologías orientadas a objetos modelan el

sistema examinando el dominio del problema como un conjunto de

objetos que interactúan entre sí.

Orientadas a procesos

Se funda en el modelo básico: Entrada/proceso/salida. Enfoca la

parte del proceso. Generalmente las especificaciones se basan en:

1. Diagrama de flujo de datos

2. Diccionario de datos.

3. Especificaciones de procesos.

4. Realizar diagrama de flujo de datos del sistema.

5. Realizar diagrama de estructuras.

6. Evaluar el diseño.

7. Preparar el diseño para implantación.

Orientadas a datos

Con la aparición de los procedimientos de la orientación a objetos

surgieron métodos, procesos y metodologías específicas como

OMT (Object Modeling Technique), RUP o Microsoft Solution

Framework, entre otras.

Ante la necesidad de normalizar el proceso de desarrollo se

empezaron a tomar en cuenta las metodologías en las que priman;

las fases, actividades y tareas antes que a las personas; lo más



18 CAPITULO 2


importante es el rol que juega la persona dentro del proceso de

desarrollo. Esto se ha justificado históricamente argumentando que

el desarrollo de software es una actividad compleja que debe estar

dirigida por un proceso y debe llevarse a cabo en grupos.

Para cubrir todas las fases se necesitan distintos y diversos

perfiles, que no se encuentran en una sola persona. El rol se

asigna dependiendo de la experiencia, formación y capacidades de

cada individuo.

Los roles de los implicados pueden ser similares entre todos pero

cada uno cumple una función específica en todos los procesos:

administrador de proyecto, analista, diseñador, programador,

asegurador de calidad, documentalista, ingeniero de validación y

verificación, administrador de la configuración. En un nuevo

proyecto no siempre es necesario que estén todos los actores del

desarrollo eso varía de acuerdo a la complejidad de cada proyecto.

Los roles de cada perfil está compuesto por los objetivos y las

actividades que se necesitan para cumplir con dicho objeto, para

esto interactúan entre ellos y la herramientas a utilizar, además del

perfil de las personas en ese rol y un plan de trabajo.

Una de las ventajas de estos procesos es que el intercambio de un

recurso es relativamente fácil: cuanto más identificadas se tengan

las tareas que realiza un rol, más fácil es formar a una persona en

esas tareas especificas.

Jerárquicas

La estructura de datos del programa tiene un nivel jerárquico que

se deriva según los datos del programa y la importancia de cada

uno de ellos. Para el diseño de este modelo se tiene en cuenta la



19 CAPITULO 2


estructura de datos de entrada y salida estructurada en forma

jerárquica y después desarrollar una lógica de desarrollo que se

ajuste a la estructura.

No Jerárquicas

Las metodologías no jerárquicas utilizan primero una arquitectura

de la información que seria para cualquier tipo de proyectos y una

forma de hacer coincidir esta arquitectura con los objetivos.

Después vendría un análisis donde se trazan los requisitos del

sistema y por último un diseño donde ya se enfoca en el sistema

requerido por el usuario pero que este acorde a la tecnología

existente.

Mixta para sistemas de tiempo real

Se basan en un control de los procesos de la información más que

en los datos en sí, priorizando procesos de comunicación entre

tareas y acceso simultaneo de datos iguales.

2.1.2.6 Metodologías de desarrollo de software más populares

La finalidad de las metodologías desde sus inicios por el año de 1960 es

ayudar a los profesionales con pautas para realizar y documentar cada

etapa del desarrollo. Existen metodologías que han quedado atrás porque

no funcionan, están obsoletas desde casi todos los puntos de vista de los

entendidos entre estos se pueden mencionar.

Desarrollo de sistemas de Jackson (JSD), de los años 80.

Structured System Analysis and Design Method (SSADM).

También de los 80. Muy popular en Europa, ya que tiene su origen

el Reino Unido Entre otras.



20 CAPITULO 2


Solo algunas metodologías tradicionales han sido revisadas y adaptadas

y su funcionalidad suele ser utilizada en proyectos muy innovadores como

RUP, MSF es por eso que para esta investigación se han tomado en

cuenta las metodologías más populares.

2.1.2.7 Tipos de metodologías ágiles

2.1.2.7.1 Programación Extrema o XP (Extreme Programming) WELLS, D.

(2009) PROGRAMACIÓN EXTREMA.

Creado por Kent Beck es una metodología ágil centrada en potenciar las

relaciones interpersonales como clave para el éxito en desarrollo de

software, promoviendo el trabajo en equipo, preocupándose por el

aprendizaje de los desarrolladores, y propiciando un buen clima de

trabajo. Se basa en realimentación continua entre el cliente y el equipo de

desarrollo, comunicación fluida entre todos los participantes, simplicidad

en las soluciones implementadas y coraje para enfrentar los cambios, se

define como especialmente adecuada para proyectos con requisitos

imprecisos y muy cambiantes en donde existe un alto riesgo técnico.

Características

Conseguir la máxima satisfacción del cliente en forma rápida y

eficiente ante los cambios de requisitos.

Se centra en potenciar las relaciones interpersonales como clave

para el éxito en desarrollo de software, promoviendo el trabajo en

equipo, preocupándose por el aprendizaje de los desarrolladores y

propiciando un buen clima de trabajo.



21 CAPITULO 2


Se basa en retroalimentación continua entre el cliente y el equipo

de desarrollo, comunicación fluida entre los participantes,

simplicidad en las soluciones implementadas y coraje para

enfrentar los cambios.

Propone realizar diseños simples, códigos simples y proporcionar

rápida respuesta de lo requerido y lograr un cliente contento.

Se sustituye la documentación escrita por la comunicación directa

entre clientes y desarrolladores o entre los propios desarrolladores.

2.1.2.7.2 Metodología cristal (Crystal methodologies)

ISSI.DSIC.UPV.ES/ARCHIVES/F-1069167248521/ACTAS.PDF

Se trata de un conjunto de metodologías para el desarrollo de software

caracterizadas por estar centradas en las personas que componen el

equipo y la reducción al máximo del número de artefactos producidos; han

sido desarrolladas por Alistair Cockburn. Se considera un juego

corporativo de invención y comunicación limitado por los recursos a

utilizar. El equipo de desarrollo es un factor clave, por lo que se deben

invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener

políticas del trabajo en equipo definidas. Estas políticas dependerán del

tamaño del equipo, estableciéndose una clasificación por colores, Crystal

Clear de 3 a 8 miembros y Crystal Orange de 25 a 50 miembros.

Características

Cuando el número de personas aumenta, también aumenta la

necesidad de coordinar.

Cuando el potencial de daños se incrementa, la tolerancia a

variaciones se ve afectada.




22 CAPITULO 2


La sensibilidad del tiempo en que se debe estar en el mercado

varía: a veces este tiempo debe acortarse al máximo y se toleran

defectos, otras se enfatiza la auditoria, confiabilidad, protección

legal, entre otras.

Las personas se comunican mejor cara a cara, con la pregunta y la

respuesta en el mismo espacio de tiempo.

El factor más significativo es comunicación.

2.1.2.7.3 Método de desarrollo de sistema dinámico (Dynamic system

development method) ISSI (2003). METODOLOGÍAS ÁGILES EN EL

DESARROLLO DE SOFTWARE.

Define el marco para desarrollar un proceso de producción de software.

Nace en 1994 con el objetivo de crear una metodología RAD unificada.

Sus principales características son: es un proceso interactivo e

incremental, el equipo de desarrollo y el usuario trabajan juntos. Propone

cinco fases: estudio viabilidad, estudio de negocio, modelado funcional,

diseño y construcción e implementación.

Características

Usa un ciclo de vida iterativo, prototipos y herramientas de CASE

(Cumputer Aided Software Engineering).

Dedica a entender las mejores prácticas en el desarrollo de

aplicaciones y codificándola de tal forma que fuera ampliamente

ensenando e implementando.

Contempla el ciclo de vida iterativo e incremental, involucra

continuamente al usuario y la adaptación al cambio.



23 CAPITULO 2


Incorpora disciplinas de la administración de proyecto y provee

mecanismos para asegurar que los beneficios del proyecto sean

claros, que sea factible la solución propuesta y que haya solidas

bases antes de comenzar con el trabajo detallado.

2.1.2.7.4 Desarrollo de software adaptable (Adaptive software

development) ISSI (2003). METODOLOGÍAS ÁGILES EN EL DESARROLLO DE

SOFTWARE.

Su impulsor es Jim Highsmith sus principales características son: iterativo,

orientado a los componentes software más que a las tareas y tolerante a

los cambios. El ciclo de vida que propone tiene tres fases esenciales:

especulación, colaboración y aprendizaje. La primera se inicia el proyecto

y se planifican las características del software, la segunda desarrolla las

características y finalmente en la tercera se revisa la calidad y se entrega

al cliente.

Características

Es iterativo.

Orientado a los componentes de software.

Tolerante a los cambios.

Guía por los riesgos.

La revisión de los componentes sirve para aprender de los errores

y volver a iniciar el ciclo de desarrollo.



24 CAPITULO 2


2.1.2.7.5 Desarrollo basado en funciones (Feature-Driven development)

ISSI (2003). METODOLOGÍAS ÁGILES EN EL DESARROLLO DE SOFTWARE.

Define un proceso iterativo que consta de 5 pasos. Las iteraciones son

cortas hasta de 2 semanas. Se centra en las fases de diseño e

implementación del sistema partiendo de una lista de características que

debe reunir el software. Sus creadores son Jeff De Luca y Peter Coad.

Características

Se preocupa por la calidad, por lo que incluye un monitoreo

constante del proyecto.

Ayuda a contrarrestar situaciones como el exceso en el

presupuesto, fallas en el programa o el hecho de entregar menos

de lo deseado.

Propone tener etapas de cierre cada dos semanas. Se obtiene

resultados periódicos y tangibles.

Se basa en un proceso iterativo con iteraciones cortas que

producen un software funcional que el cliente y la dirección de la

empresa pueden ver y monitorear.

Define claramente entregas tangibles y formas de evaluación del

progreso del proyecto.

No hace énfasis en la obtención de los requerimientos sino en

cómo se realizan las fases de diseño y construcción.



25 CAPITULO 2


2.1.2.7.6 Metodología Lean (Lean Development) METODOLOGÍAS ÁGILES EN

EL DESARROLLO DE SOFTWARE.

Definida por Bob Charette’s a partir de su experiencia en proyectos con la

industria japonesa del automóvil en los años 80 y utilizada en numerosos

proyectos de telecomunicaciones en Europa. Los cambios se consideran

riesgos, pero si se manejan adecuadamente se pueden convertir en

oportunidades que mejoren la productividad del cliente. Su principal

característica es introducir un mecanismo para implementar dichos

cambios.

Características

Se enfoca en la creación de software tolerante a cambios.

Incorpora la noción de escalabilidad dinámica la cual como Scrum

abarca caos controlado.

Satisfacer al cliente es la más alta prioridad.

Siempre proveer el mejor valor por el precio.

El éxito depende en la participación activa del cliente.

2.1.2.7.7 Scrum METODOLOGÍAS ÁGILES EN EL DESARROLLO DE SOFTWARE.

Desarrollado por Ken Schwaber, Jeff Sutherland y Mike Beedle, define un

marco para la gestión de proyectos que se ha utilizado con éxito durante

los últimos 10 años. Esta especialmente indicada para proyectos con un

rápido cambio de requisitos, sus principales características se pueden

resumir en dos, el desarrollo de software se realiza mediante iteraciones,



26 CAPITULO 2


denominados sprint con una duración de 30 días y las reuniones a lo largo

del proyecto entre ellas destaca la reunión diaria de 15 minutos del equipo

de desarrollo para coordinación e integración.

2.1.2.8 Características del proceso de scrum

Scrum recoge algunas prácticas reconocidas como buenas para el

desarrollo ágil del software y las utiliza para crear su metodología entre

estas tenemos:

Desarrollo de software iterativo e incremental: En Scrum, la

planificación del proyecto maneja los requerimientos del cliente, y

se realiza un análisis de los mismos en función del valor que

proporcionan al cliente y su coste de desarrollo.

Orientación a personas: En Scrum tanto el equipo como el cliente

tienen responsabilidad y autoridad, porque forman un equipo

multidisciplinar.

Planificación con tiempo, tareas y personas: Cada iteración del

producto, es asignada por tareas y tiempos para cada miembro, las

cuales son detectadas por el equipo en conjunto, siendo así más

fiables, ya que se basan en las experiencias e información de todos

los miembros del equipo.

Control del progreso del proyecto: En Scrum, es el equipo el que se

compromete a informar diariamente del progreso de las tareas que

el mismo se ha asignado en las reuniones, informando del avance

de las mismas así como de los problemas que vayan surgiendo.



27 CAPITULO 2


Gestión de cambio: Los cambios están permitidos y aceptados en

el inicio de cada iteración, considerándose como algo natural, y

permitiendo al cliente presentarlos una vez demostrados los

resultados de cada iteración.

Retrospectivas y análisis post mortem, las retrospectivas se hacen

al final de cada iteración permitiendo que un mejor aprendizaje por

parte del equipo, que puede ser de esta manera más productivo a

la hora de desarrollar el proyecto.

Scrum es adecuado para aquellas empresas en las que el desarrollo de

los productos se realiza en entornos que se caracterizan por tener: TRIGAS

GALLEGO, M. (2012)

1. Incertidumbre: Sobre esta variable se plantea el objetivo que se

quiere alcanzar sin proporcionar un plan detalla del producto.

Esto genera un reto de una autonomía que sirve para generar una

“tensión” adecuada para la motivación de los equipos.

2. Auto-Organización: Los equipos son capaces de organizarse por

sí solos, no necesitan roles para la gestión pero tienen que reunir

las siguientes características:

Autonomía: Son los encargados de encontrar la solución

usando la estrategia que encuentren adecuada.

Auto-superación: Las soluciones iniciales sufrirán mejoras.

Auto-enriquecimiento: Al ser equipos multidisciplinares se

ven enriquecidos de forma mutua, aportando soluciones que

puedan complementarse.



28 CAPITULO 2


3. Control moderado: Se establecerá un control suficiente para

evitar descontroles. Se basa en crear un escenario de “autocontrol

entre iguales” para no impedir la creatividad y espontaneidad de los

miembros del equipo.

4. Transmisión del conocimiento: Todo el mundo aprende de todo

el mundo. Las personas pasan de unos proyectos a otros y así

comparten sus conocimientos a lo largo de la organización.

Para entender el ciclo de desarrollo de Scrum es necesario conocer las 5

fases que definen el ciclo de desarrollo ágil:

1. Concepto: Se define de forma general las características del

producto y se asigna el equipo que se encargara de su desarrollo.

2. Especulación: En esta fase se hacen disposiciones con la

información obtenida y se establecen los límites que marcaran el

desarrollo del producto, tales como costes y agendas. Se construirá

el producto a partir de las ideas principales y se comprueban las

partes realizadas y su impacto en el entorno.

Esta fase se repite en cada iteración y consiste, en rasgos

generales, en:

Desarrollar y revisar los requisitos generales.

Mantener la lista de las funcionalidades que se esperan.

Plan de entrega. Se establece las fechas de las versiones,

hitos e iteraciones. Medirá el esfuerzo realizado en el

proyecto.



29 CAPITULO 2


3. Exploración: Se incrementa el producto en el que se añaden las

funcionalidades de la fase de especulación.

4. Revisión: El equipo revisa todo lo que se ha construido y se

contrasta con el objetivo deseado.

5. Cierre: Se entregara en la fecha acordada una version del

producto deseado. Al tratarse de una version, el cierre no indica

que se ha finalizado el proyecto, sino que seguirá haciendo

cambios, denominados “mantenimiento”, que hará que el producto

final se acerque al producto final deseado.

FIGURA 2.1

CICLO DEL DESARROLLO ÁGIL

FUENTE: TRIGAS GALLEGO, M. (2012)

ELABORADO POR: SANDY BARCIA, GABRIELA CHILIQUINGA

ITERACIONES

Concepto

Especulación

Exploración Revisión

Cierrre



30 CAPITULO 2


FIGURA 2.2

CICLO PRINCIPAL DEL SCRUM



2.1.2.9 Componentes de scrum

Scrum se puede dividir de forma general en 3 fases, que podemos

entender como reuniones. Las reuniones forman parte de los artefactos

de esta metodología junto con los roles y elementos que lo forman.

LAS REUNIONES

1. Planificación del backlog

Se definirá un documento en el que se reflejan los requisitos del

sistema por prioridades.

En esta fase se definirá también la planificación del sprint 0, en la

que se deducirá cuales van a ser los objetivos y el trabajo que hay

que realizar para esa iteración.

Se obtendrá además en esta reunión un sprint backlog, que es la

lista de tareas y que es el objetivo más importante del sprint.



31 CAPITULO 2


2. Seguimiento del sprint

En esta fase se hacen reuniones diarias en las que las 3 preguntas

principales para evaluar el avance de las tareas serán:

¿Qué trabajo se realizó desde la reunión anterior.

¿Qué trabajo se hará hasta una nueva reunión?

Inconvenientes que han surgido y que hay que solucionar

para poder continuar.

3. Revisión del Sprint

Cuando se finaliza el sprint se realiza una revisión del incremento

que se ha generado. Se presentaran los resultados finales y un

demo o version, esto ayudara a mejorar el feedback con el cliente.

LOS ROLES

Los roles se dividen en 2 grupos: cerdos y gallinas, esto surge en el chiste

sobre un cerdo y una gallina y su intención de poner un restaurante.

1. Los cerdos

Son las personas que están comprometidas con el proyecto y el

proceso de scrum.

Product owner: Es la persona que toma las decisiones, y

es la que realmente conoce el negocio del cliente y su visión

del producto. Se encarga de escribir las ideas del cliente, las

ordena por prioridad y las coloca en el product backlog.

Scrum master: Es el encargado de comprobar que el

modelo y la metodología funciona; eliminará todos los



32 CAPITULO 2


inconvenientes que hagan que el proceso no fluya e

interactuara con el cliente y con los gestores.

Equipo de desarrollo: Suele ser un equipo pequeño de

unas 5-9 personas y tienen autoridad para organizar y tomar

decisiones para conseguir su objetivo, está involucrado en la

estimación del esfuerzo de las tareas del backlog.

2. Las gallinas

Aunque no son parte del proceso de scrum, es necesario que parte

de la retroalimentación de la salida del proceso y así poder revisar

y planear cada sprint.

Usuarios: Es el destinatario final del producto.

Stakeholders: Las personas a las que el proyecto les

producirá un beneficio. Participan durante las revisiones del

sprint.

Managers: Toma las decisiones finales participando en la

selección de los objetivos y de los requisitos.

Product backlog: Lista de tareas priorizadas que se

realizan en un sprint.

Incremento: Parte añadida o desarrollada en un sprint, es

una parte terminada y totalmente operativa.



33 CAPITULO 2


FIGURA 2.3

CICLO DE DESARROLLO SCRUM



2.1.2.10 Las historias de los usuarios

Son las descripciones de las funcionalidades que va a tener el software.

Estas historias de usuario, serán el resultado de la colaboración entre el

cliente y el equipo, e irán evolucionando durante toda la vida del proyecto.

Las historias de usuarios se componen de tres fases denominadas “las 3

C”:

Card: Será una breve descripción escrita que servirá como

recordatorio.

Conversation: Es una conversación que servirá para asegurarse

de que se ha entendido bien todo, y concretar el objetivo.

Confirmation: Test funcionales para fijar detalles que sean

relevantes e indicar cuál va a ser el límite.



34 CAPITULO 2


En cuanto al formato, un modelo podría ser como el que se muestra a

continuación:

FIGURA 2.4

EJEMPLO DE HISTORIA DE USUARIO

FUENTE: HTTP://DEVNETTIPS.BLOGSPOT.COM.ES


ID: Identificador de la historia de usuario.

Título: Título descriptivo de la historia de usuario.

Descripción: Descripción sintetizada de la historia de usuario.

Estimación: Evaluación del coste de implementación en unidades

de desarrollo. Estas unidades representarán el tiempo teórico

(desarrollo/hombre) que se haya estimado al comienzo del

proyecto.

Prioridad: Prioridad en la implementación de la historia de usuario

respecto al resto de las historias de usuario, a mayor número,

mayor prioridad; otra aproximación a la priorización de tareas se

hace a través del método MoSCoW:

http://devnettips.blogspot.com.es/



35 CAPITULO 2


M-Must, Se debe completar este requerimiento para finalizar

el proyecto.

S-Should, Se debe completar este proyecto por todos los

medios, pero el éxito del proyecto no depende de él.

C-Could, Se debería completar este requerimiento si su

implementación no afecta a la consecución de los objetivos

principales del proyecto.

W-Would, Se puede completar este requerimiento si sobra

tiempo de desarrollo (o en futuras versiones del mismo).

Dependencia: Una historia de usuario no debería ser dependiente

de otra historia, pero a veces es inevitable. En este apartado se

indicarían los IDs de las tareas de las que depende una tarea.

Formato de la pila del producto (Product backlog)

En scrum, la preferencia por tener documentación en todo momento es

menos estricta. Se encuentra más necesario al mantener una

comunicación directa con el equipo, por eso se usa como herramienta el

backlog.

Aunque no hay ningún producto especial a la hora de confeccionar la lista,

es conveniente que incluya información relativa a:

Identificador para la funcionalidad.

Descripción de la funcionalidad.

Sistema de priorización u orden.

Estimación.



36 CAPITULO 2


FIGURA 2.5

EJEMPLO DE UN PRODUCT BACKLOG



Sprint backlog

Es la lista de tareas que elabora el equipo durante la planificación de un

sprint. Se asignan las tareas a cada persona y el tiempo que queda para

terminarlas,

De esta manera el proyecto se descompone en unidades más pequeñas y

se puede determinar o ver en qué tareas no se está avanzando e intentar

eliminar el problema.

FIGURA 2.6

EJEMPLO DE SPRINT BACKLOG

FUENTE: TRIGAS GALLEGO, M. (2012) GESTIÓN DE PROYECTOS

INFORMÁTICOS.



37 CAPITULO 2


Cómo funciona la lista:

Es una lista ordenada por prioridades para el cliente.

Puede haber dependencias entre una tarea y otra, por lo tanto se

tendrá que diferenciar de alguna manera.

Todas las tareas tienen que tener un coste semejante que será

entre 4-16 horas.

Formato de la lista

Hay 3 opciones:

Hojas de cálculo.

Pizarras

Herramientas colaborativas.

Generalmente, las tareas a completar se suelen gestionar mediante el

scrum taskboard, a cada objetivo se le asignan las tareas necesarias para

llevarlo a cabo, se usan post-its que se van moviendo de una columna a

otra para cambiar el estado.

Se debe incluir:

Lista de tareas.

Persona responsable de cada tarea, el estado en el que se

encuentra y el tiempo que queda por terminarla.

Permite la consulta diaria del equipo.

Permite tener una referencia diaria del tiempo que le queda a cada

tarea.



38 CAPITULO 2


Incremento

Representa los requisitos que se han completado en una iteración y que

son perfectamente operativos.

Según los resultados que se obtengan, el cliente puede ir haciendo los

cambios necesarios y replanteados el proyecto.

2.1.2.11 Desarrollo de las fases de un proyecto en scrum

Preparación del proyecto

Conocida como Sprint 0, es la fase inicial en la que se intenta comprender

el caso de negocio con la finalidad de tomar decisiones que agreguen

valor al producto.

Durante esta fase se producen gran número de inexactitudes con las

estimaciones, pero es lógico, debido a que se hacen a alto nivel, por lo

tanto es aconsejable no perder tiempo en buscar las estimaciones

exactas, es mejor invertir ese tiempo en el desarrollo del producto. De

esta manera el backlog del producto usará como unidad de tiempo “días”.

Las tareas a realizar en el sprint 0 son:

Definir el proyecto: Se debería de indicar de forma clara el

propósito del proyecto, no es necesario entrar en detalle pero sí

que todo el equipo sea capaz de entender cuáles son las

necesidades del producto y del cliente.

Definir “terminado”: Marcará el punto en el que se va a

considerar que la tarea está terminada.



39 CAPITULO 2


Definición del backlog inicial: Se comienza la creación del

backlog del producto para que el sprint siguiente contenga

elementos de la lista suficientes para comenzar a trabajar. Esta

lista de elementos será marcada por el product owner, que tendrá

como responsabilidad priorizar las funcionalidades que, al

desarrollarlas e implementarlas cumplan las especificaciones

consiguiendo además que su beneficio supere a su coste.

Definición de los entregables: Una vez que se tiene el backlog

con las funcionalidades, es necesario establecer criterios para

hacer pequeñas entregas “entregable” del producto y así obtener

su valor y un feedback temprano.

El plan de entregables puede sufrir modificaciones, muchas de ellas

propiciadas por:

Cambia el entorno y aparecen nuevas oportunidades para el

negocio.

Se encuentran nuevas funcionalidades y estas proporcionan un

valor si se pusiese en producción.

Replanteamiento del entregable.

El plan de entregas lo determinará el negocio, que será el encargado de

marcar qué funciones, calidad y coste va a tener.

De la misma manera, estará sujeto a unas determinadas condiciones

determinadas por el equipo de trabajo que serán:

Tiempo para un entregable.



40 CAPITULO 2


La estimulación inicial.

Selección del backlog del producto.

Constitución del equipo

Se hace una reunión inicial con todos los roles del equipo para tratar:

Dimensión del proyecto.

Revisiones del backlog.

Organización del equipo y horario para establecer reuniones de

control.

Las estimaciones del backlog

Antes de la primea reunión de la planificación el equipo tiene que conocer

cuál va a ser su velocidad inicial y su factor de dedicación.

Para poder realizar las estimaciones, primeramente hay que decidir que

historias incluir en la pila del sprint.

La forma en la que se podrá decidir qué historias poner o no se puede

realizar mediante 2 técnicas:

De forma aproximada.

Realizando cálculos de velocidad.

1. De forma aproximada:

En la estimación aproximada, el equipo debate el número de

historias a introducir hasta llegar a un acuerdo; suele funcionar de

forma correcta si los sprints son cortos.



41 CAPITULO 2


2. Realizando los cálculos de velocidad:

Esta técnica se realiza en dos pasos:

Seleccionar la velocidad estimada.

Calcular el número de historias que se pueden añadir sin

pasar la velocidad estimada.

La manera más adecuada de estimar la velocidad, es revisar el historial

del equipo, de esta manera, basándonos en sprints anteriores se podrá

deducir que será muy similar.

Para poder realizar esta técnica, es necesario que los equipos tengan un

historial, que vayan hacer los próximos sprints de la misma manera,

mismo tamaño de equipo y las mismas condiciones de trabajo. La técnica

se conoce como “el tiempo que hizo ayer”.

1.- Se calcula el número de días – hombre disponible, este es un valor

poco real porque influyen factores externos de ahí que tengamos que usar

el “factor de dedicación”.

Velocidad estimada

(Días – Hombres disponibles) * (Factor de dedicación) = VELOCIDAD

ESTIMADA



42 CAPITULO 2


El factor de dedicación se basa en estimar el estado del equipo, si es bajo

entonces se espera encontrar dificultades.

La forma más adecuada para determinar factores de dedicación

razonables es el estado de los últimos sprints.

Factor de dedicación

(Factor de dedicación) = Velocidad Real / (Días – hombres disponibles)

Velocidad real = suma de las estimaciones iniciales que se realizaron

completamente en el último sprint.

De esta manera se obtendrán la velocidad estimada por el siguiente

sprint.

Si el equipo fuese nuevo, se puede mirar el factor de dedicación de otros

equipos con lo que fijarte y de no haberlo, se podrían un valor aproximado

para empezar por defecto. El factor que se suele usar es de 70%.

Planificar un sprint

Denominado también “Sprint Planning Meeting”, tiene como finalidad

realizar una reunión, en la que participan el product owner, el scrum

master y el equipo, con la intención de seleccionar de la lista backlog del

producto las funcionalidades sobre las que se va a trabajar, y que darán

valor al producto.



43 CAPITULO 2


FIGURA 2.7

ENTRADAS Y SALIDAS DE UN PLANNING MEETING



Antes de comenzar la reunión el product owner tendrá que preparar el

backlog.

La reunión se realiza en con time-box de ocho horas que se dividen en 2

partes de 4 horas.

Primera parte de la reunión:

El equipo selecciona los ítems para transformarlos en entregables.

El equipo hace sugerencias, pero es el product owner el que

decidirá si formarán parte del sprint.

El equipo seleccionará el elemento a implementar, de los

seleccionados por el product owner para ese sprint.

Sprint Planning

Meeting

Pro

du

ct

Ow

ner

Scru

m

Team

Cu

sto

mers

Man

ag

em

en

t

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Goal

Sprint Backlog



44 CAPITULO 2


Segunda parte de la reunión:

El equipo hará las preguntas necesarias que tengan sobre el

product backlog al product owner.

El equipo se encargará de encontrar la solución adecuada para

transformar la parte seleccionada de una funcionalidad entregable.

El resultado de la segunda parte de la reunión es una lista denominada

“Sprint Backlog” con las tareas estimaciones y las asignaciones de trabajo

al equipo para poder empezar a desarrollar la funcionalidad.

Las características del backlog del producto serán las siguientes:

La estimación será entre 4 y 16 horas, si son mayores a este valor,

se descompondrán.

Las tareas del sprint deben de ser como consecuencia de la

necesidad de un requerimiento del backlog del producto.

El progreso de las tareas en las que se mide la velocidad y el

progreso del sprint con respecto a las horas, se realizará mediante

gráficos burndown chart.



45 CAPITULO 2


FIGURA 2.8

EJEMPLO DE UN GRAFICO DE AVANCE DE UN SPRINT


INFORMÁTICOS.


El soporte en el que se presentan el sprint backlog puede ser:

Hojas de cálculo.

Pizarras

Herramientas colaborativas de red.

La herramienta como soporte quizás más utilizada es el (Scrum

taskboard) en la que en una pizarra se crea una tabla con la siguiente

información:

1ra fila: Tareas que no se han planificado pero que son necesarias

de hacer por su urgencia (errores, cambios importantes decididos

por el cliente, etc.).

2da fila: Mejora continúa. Se ponen las tareas de retrospectivas

anteriores que se quieren analizar en ese sprint.



46 CAPITULO 2


Columna tareas no empezadas: Se pondrán todas las tareas que

se han especificado en la reunión del sprint planning.

En curso: Tareas que se están realizando y que deberían ser

mínimas y resueltas de arriba abajo.

Hecho: Tarea realizada completamente.

Impedimento: Lista de obstáculos que impedirán continuar de

forma adecuada el proyecto. Hay que indicar quien será el

responsable de solucionarlos.

Retrospectiva: Sirve para anotar que partes están bien durante la

iteración y cuáles mal. Se reflejan con un “+” y un “-“.

FIGURA 2.9

EJEMPLOS DE SCRUM TASK BOARD



47 CAPITULO 2



INFORMÁTICOS.


LA ESTIMACIÓN DEL SPRINT

Planificación de póker

Realizar las estimaciones para los ítems seleccionados, es una tarea que

deberá involucrar a todos los miembros en el equipo. Para poder hacer

una estimación y que los miembros del equipo no estén condicionados

por la estimación de los compañeros se usara, la técnica de planning

póker.

1. Cada miembro del equipo tendrá una baraja de 13 cartas.

2. Se propone una historia, el miembro del equipo selecciona una

carta y la coloca boca abajo. Esta carta representará su estimación

para la historia propuesta.



48 CAPITULO 2


3. Cuando todos los miembros han seleccionado su carta, se le da la

vuelta al mismo tiempo.

4. Se comprueban las estimaciones, y si hay muchas discrepancias

se discute sobre esas diferencias y se ponen en común las ideas

sobre la naturaleza del trabajo. Este proceso se repetirá hasta que

las estimaciones sean parejas o aproximadas.

5. Se comprueban las estimaciones y si hay muchas discrepancias se

discute sobre esas diferencias y se ponen en común las ideas

sobre la naturaleza del trabajo. Este proceso se repetirá hasta que

las estimaciones sean parejas o aproximadas.

6. El tiempo estimado es para el desarrollo de toda la historia, por ese

motivo la secuencia de números no lineal, y por ejemplo, hay un

salto entre 40 y 100. De esta manera se evita sensaciones falsas

para estimaciones grandes.

Si las estimaciones fuesen más detalladas las historias se podrían dividir

en historias más pequeñas.

Hay 3 cartas especiales:

O “Esta historia ya está hecha” o requiere poco tiempo de

trabajo.

¿ No hay idea de cuánto puede ser la estimación.

Taza de café: Realizar un descanso para retomar después la

estimación.



49 CAPITULO 2


Mantener el backlog del sprint

El equipo tiene que mantener actualizado el backlog del sprint para poder

tener el feedback y tomar cualquier decisión de manera rápida.

Es necesario además para que el grafico de burndown del sprint también

este actualizado.

El desarrollo del sprint

En los sprints, el equipo trabajo para conseguir un incremento del

producto, que será productivo para el producto owner y los stakeholders.

El tiempo más conveniente está entre 2 y 4 semanas, o 30 días

consecutivos como máximo. Estos intervalos de tiempo, son los que se

consideran más apropiados para que el stakeholders no pierda el interés.

Reuniones del sprint

Durante la ejecución del sprint se van a realizar 3 reuniones:

Reunión de planificación (Sprint planning meeting)

Definirá que tareas se tienen que realizar y cuáles son los

objetivos.

Una vez definidos, el equipo comienza su desarrollo, pero teniendo

en cuenta una serie de normas:

El equipo puede realizar consultas de agenda fuera del

sprint.

No se permite a nadie gobernar al equipo durante el sprint.

El equipo se autogestionará.



50 CAPITULO 2


Si durante el desarrollo del sprint no se puede realizar,

porque no es viable, se puede realizar una nueva

planificación para realizar un nuevo sprint.

Si el equipo no puede comprometerse a cumplir todo el

backlog, realizará una consulta con el producto owner para

decidir que ítems eliminar.

Si de la misma manera, el equipo se ve capaz de realizar

más ítems del backlog durante el sprint, que el indicado

inicialmente, consultara también con el product owner que

ítems se podrán añadir.

Teniendo en cuenta estas características, a lo largo del desarrollo, se

producirán además, reuniones diarias.

Reunión diaria (Scrum daily meeting)

En esta reunión, los componentes del equipo comparten

información relativa al desarrollo y colaboración para hacer las

adaptaciones necesarias, aumentando así su productividad.

También se tendrá como referencia el backlog del sprint y el equipo

grafico burn-down con la información de la reunión anterior y,

además, que tareas hizo cada persona del equipo. La reunión no

podrá consumir más de 15 minutos y contestara a tres preguntas

básicas:

¿Qué se ha hecho de nuevo con respecto a la última reunión

diaria?

¿Qué será lo siguiente a realizar?



51 CAPITULO 2


¿Qué problema hay para realizarlos?

Se usará como herramienta de apoyo, con la lista de tareas del

sprint actualizada y con el esfuerzo pendiente de cada tarea.

También se tendrá un grafico con las tareas pendientes en la

iteración.

Reunión Revisión del Sprint (Sprint review meeting)

En esta reunión, los desarrolladores presentan el producto

entregable que han implementado y los gestores, clientes, usuarios

y producto owner analizan esa entrega y escuchan al equipo sobre

los problemas que han tenido durante el proceso.

Esta reunión servirá para tomar decisiones que ayuden a escoger

el camino más adecuado para alcanzar las metas.

Las características de esta reunión se limitan a:

Máximo 4 horas.

Se presenta el producto “completado” entendiendo como tal

la definición acordada con el producto owner y los

stakeholders.

Si la funcionalidad no está completa no se puede presentar.

Artefactos que no son funcionalidades, no se presentan para

no equivocar a los stakeholders.

Se presenta la funcionalidad en equipos que pertenezcan a

los desarrolladores. Siempre se hará desde un servidor lo

más parecido posible al de producción.



52 CAPITULO 2


El sprint review transcurre siguiendo el siguiente proceso:

o El scrum master determina cuantas personas asistirán al sprint

review meeting.

o Al final de la reunión, el scrum master anuncia al product owner y a

los stakeholders la próxima reunión.

Estas reuniones son beneficiosas para todos, puesto que se comprueba:

Si el equipo ha cumplido las expectativas.

Y si el equipo ha entendido al cliente.

Se produce entonces una satisfacción personal al comprobar y ver

funcionando la entrega.

Reunión de retrospectiva (Sprint retrospective meeting)

En esta reunión, el equipo debatirá temas relacionados con el sprint

recientemente finalizado y los cambios que podrían hacer para mejorar el

próximo sprint y que sea más productivo.

Comentan la presentación.

Critican los incrementos de

funcionalidades.

Identifican que funcionalidades

se pueden añadir y cuáles no han

sido entregadas.

Presentación de Metas.

- De Sprints. - De Product Backlog

comprometido. - De Product Backlog

Completado.



53 CAPITULO 2


Generalmente, será el scrum master quien realiza esta reunión y tendrá

una duración máxima de 3 horas.

Las características generales de la reunión serán:

Asistirán el scrum master, el equipo y el product owner.

La reunión girara entorno a dos preguntas básicas: ¿Qué ha ido

bien durante el último sprint?, ¿Qué será mejorado para el

siguiente sprint?.

El scrum master toma nota de las respuestas del equipo en un

formulario.

El equipo hablara de las posibles mejoras que se puedan realizar,

indicando cuales van a tener mayor preferencia.

El scrum master ayudara a entrar mejores vías de apoyo, para las

mejoras indicadas por el equipo.

Si hay puntos que merezca atención se añadirán para el siguiente

sprint, considerándolo como un backlog no funcional, pero de alta

prioridad.



54 CAPITULO 2


FIGURA 2.10

DIAGRAMA DETALLADO DE LAS FASES DE SCRUM


INFORMÁTICOS.




55 CAPITULO 2


2.1.2.12 Proceso de la metodología scrum



56 CAPITULO 2


2.1.2.13 Ventajas de la metodología scrum

El cliente tiene la oportunidad ver los resultados desde el primer

momento.

Se ahorra tiempo que en las metodologías tradicionales se dedica

en conseguir especificaciones y documentación exhaustivamente.

Se hace equipo de comunicación continua reportando

seguidamente los éxitos conseguidos.

El cliente tiene la oportunidad de ser participe y opinar en el

desarrollo del proyecto.

Se reducen los riesgos por retrasos acumulados, entregas que

difieren de lo que el cliente esperaba, por lo tanto influye de

manera decisiva en el éxito del proyecto.

2.1.3 MARCO ANDRAGÓGICO

Es la ciencia y el arte de la educación para los adultos, facilita el proceso

de su enseñanza-aprendizaje donde va hacer un ciudadano proactivo,

abierto al cambio, creativo, reflexivo, critico, innovador, auto formado, con

calidad personal que le permite desarrollar convicciones profundas con

coherencia entre lo que piensa y lo que hace. WWWANDRAGOGIA-FRANCISCO-

M.BLOGSPOT.COM/

Este proyecto está enfocado para personas adultas de la Universidad de

Guayaquil, quienes van a estar utilizando la herramienta para la

organización de sus actividades académicas con este sistema de apoyo

para la distribución de cargas horarias de la carrera ISAC.



57 CAPITULO 2


2.2 MARCO CONTEXTUAL

El diseño de un software para las cargas horarias de los docentes que

será realizado en la carrera de Ingeniería en Sistemas Administrativos

Computarizados que se encuentra en la Universidad de Guayaquil

Facultad de Ciencias Administrativas abarca los elementos necesarios

para cotejar las cargas horarias, tal como base de datos de los docentes,

materias que dictan, horarios disponibles en la cual los docentes pueden

dictar su cátedra.

Existe una necesidad urgente de incorporar un software en la carrera de

Ingeniería en Sistemas Administrativos Computarizados, como prueba de

ello tenemos la falta de coordinación a la hora de hacer las cargas

horarias a los docentes en la cual existen cruces de horarios en los

paralelos.

En un ambiente de evolución tecnológica constante, el reto es lograr que

los usuarios aprovechen todas las opciones disponibles para producir

eficiencia e innovación en su trabajo cotidiano.

2.3 HIPÓTESIS

El diseño de un software que mejora el proceso de cargas horarias de los

docentes de la carrera de ISAC con la reducción de tiempos y un mayor

control en la parte administrativa.

Variable Independiente:

El proceso de cargas horarias de los docentes de la carrera de

ISAC.

Variable Dependiente:

El inicio a tiempo de las actividades académicas en ISAC.



58 CAPITULO 3

PROBLEMATICA

CAPÍTULO 3

PROBLEMÁTICA

3.1 ANTECEDENTES DE LA CARRERA ISAC

En la ciudad de Guayaquil en el sector Norte en La Ciudadela

Universitaria Avenida Kennedy y Avenida Delta se encuentra ubicada la

Universidad de Guayaquil, dentro de ella está la Facultad de Ciencias

Administrativas que consta de la Carrera de Ingeniería en Sistemas

Administrativos Computarizados (ISAC).

La Carrera ISAC tiene algunos procesos que se los hace de forma manual

y al momento no existen herramientas o sistemas informáticos que los

ayuden a agilizar los procesos y a disminuir los tiempos, con los avances

tecnológicos que se van dando.

Nos hemos centrado en el proceso de la Distribución de Cargas Horarias

de los Docentes, porque de este proceso ya que por ser una carrera de

Sistemas, deberían tener una herramienta tecnológica para hacer dicha

actividad, y así poder eliminar tiempos muertos.

3.1.1 MISIÓN WWW.FCA.UG.EDU.EC/?PAGE_ID=100

“La carrera de Ingeniería en Sistemas Administrativos Computarizados,

forma profesionales con conocimiento de la tecnología computacional en

el área administrativa, impulsando el emprendimiento y la invención de

comercios autosustentables en vías de la informática con valores éticos,

http://www.fca.ug.edu.ec/?PAGE_ID=100



59 CAPITULO 3

PROBLEMATICA

morales y cívicos, logrando niveles de calidad en la vinculación con la

sociedad.”

3.1.2 VISIÓN WWW.FCA.UG.EDU.EC/?PAGE_ID=100

“Al 2015, la carrera de Ingeniería en Sistemas Administrativos

Computarizados se proyecta como líder regional en la formación de

profesionales con conocimientos en sistemas informáticos, con valores

éticos, morales y cívicos que contribuyen al acrecentamiento humano y

tecnológico – empresarial y llegar a niveles de excelencia en

productividad.”

3.1.3 UBICACIÓN GEOGRÁFICA

FIGURA 3.1

UBICACIÓN

FUENTE: GOOGLE MAP

CARRERA

ISAC

http://www.fca.ug.edu.ec/?page_id=100



60 CAPITULO 3

PROBLEMATICA

3.2 SITUACIÓN ACTUAL DE LA PROBLEMATICA

Actualmente la carrera de Ingeniería en Sistemas Administrativos

Computarizados al inicio de cada semestre académico el Director y/o

Coordinar son los encargados del proceso de asignación de cargas horarias

de los docentes, donde se presentan problemas en el manejo distributivo de

cursos y materias de cada docente ya que la asignación es de forma manual

ocasionando inconvenientes y demoras en la distribución de paralelos.

Esta asignación de forma manual se la hace por medio de la herramienta de

microsoft office excel como base y se actualiza manualmente todas las hojas

de cálculo.

Siendo esto un inconveniente en la planificación de la distribución de aulas

con sus respectivos docentes y cada error que se comete se tengan que

hacer un ciclo repetitivo de actualización de todo el trabajo elaborado,

causando una demora en lo planificado.

3.2.1 ESTRUCTURA ORGANIZACIONAL DE ISAC

DIRECTOR DE CARRERA

COORDINADOR JEFES DE AREA

JEFE DE AREA LEGAL Y

HUMANISTICA

DOCENTES LEGAL Y

HUMANISTICA

JEFE DE AREA MATEMATICAS Y

ESTADISTICA

DOCENTES MATEMATICAS Y

ESTADISTICA

JEFE DE AREA CONTABILIDAD,

FINANZAS Y ADMINISTRACION

DOCENTES CONTABILIDAD,

FINANZAS Y ADMINISTRACION

JEFE DE AREA DESARROLLO DE

SISTEMAS

DOCENTES DESARROLLO DE

SISTEMAS

JEFE DE AREA INFRAESTRUCTURA Y ADMNISTRACION

TECNOLOGICA

DOCENTES INFRAESTRUCTURA Y

ADMINISTRACION TECNOLOGICA.



61 CAPITULO 3

PROBLEMATICA

3.2.2 PERSONAL QUE LABORA EN ISAC

En la Carrera ISAC labora un total de 33 personas detallada en la Tabla 3.1

se presentan los puestos que forman parte de la estructura organizativa de

ISAC y la cantidad de personas que se desempeñan en dichos puestos.

TABLA 3.1

PERSONAL ADMINISTRATIVO

CARGO # DE PERSONAS

DIRECTOR 1

COORDINADOR 2

JEFES DE AREA 5

DOCENTES 25

FUENTE: COORDINACIÓN ISAC


3.3 FORMULACIÓN DEL PROBLEMA

3.3.1 DESCRIPCIÓN DEL PROBLEMA

Hasta la actualidad se han presentado diversos problemas con los procesos

que se utilizan en la Dirección de la Carrera ISAC ya que no cuentan con

algún sistema o herramienta tecnológica para un ágil y eficaz manejo de la

información, estos problemas se los puede detectar en los procesos de: La

distribución de cargas horarias, seguimientos a graduados, registro de tesis,

datos sobre los estudiantes; estos procesos se los guarda en hojas de excel

como bases de datos, por lo que la búsqueda de la información es lenta.

Las cargas horarias de los docentes se registran, procesan y almacenan en

una hoja de excel, lo que repercute en un deficiente manejo, ocasionando

que la búsqueda y consolidación de información sean difíciles de realizar,



62 CAPITULO 3

PROBLEMATICA

careciendo de información actualizada en la base de datos de los docentes,

lo que causa retrasos al iniciar el periodo lectivo.

Esta solución puntual propuesta forma parte de un conglomerado de

herramientas tecnológicas que tendría por finalidad cubrir todas las

necesidades específicas de gestión de información de la administración

académica de ISAC y que asegure el correcto procesamiento de los datos,

logrando un soporte ágil de la información de manera que sea eficiente y

oportuna. Identificar estas necesidades específicas puede convertirse en

material para nuevos estudios.

Este análisis y diseño de sistema será una herramienta tecnológica de fácil

manejo, actualización de los datos, reportes y búsqueda de información más

rápida de las cargas horarias de los docentes.

El alcance de este proyecto es utilizable para todas las carreras de la

Facultad de Ciencias Administrativas.

3.3.2 ANÁLISIS DE LA SITUACIÓN DEL PROBLEMA

La investigación realizada en la carrera ISAC se obtuvo una perspectiva de

lo que está ocurriendo actualmente en la administración académica.

Se identificaron aquellos factores que contribuyen a que el proceso de

administración académica no se logre lo deseado.



63 CAPITULO 3

PROBLEMATICA

Se determino las causas que originan la problemática, se describen a

continuación:

Con respecto a los docentes

Se debe considerar su perfil académico, conocimiento que tenga para

dictar una asignatura, disponibilidad de tiempo y tipo de contrato.

Con respecto a la planificación

Se debe hacer la programación para que un docente pueda dictar su

cátedra y que no genere retrasos en las clases, cruce de horario de

docentes, cátedras sin docentes, jornadas de clases fuera de horario,

que repercuten en que la ejecución del programa académico.

Con respecto a los cursos

La apertura de los cursos se debe dar con el número de docentes que

existen para impartir una materia.

3.3.3 DIAGRAMA CAUSA-EFECTO DEL PROBLEMA

El diagrama causa – efecto nos permitirá presentar de forma grafica las

causas que originan la problemática en la distribución de cargas horarias de

la carreara ISAC.



64 CAPITULO 3

PROBLEMATICA

FIGURA 3.2

DIAGRAMA CAUSA-EFECTO DEL PROBLEMA


3.3.4 DEFINICIÓN DEL PROBLEMA

¿En que nos serviría el desarrollo de un sistema para la designación de

cargas horarias académicas en la carrera ISAC, ayudará a optimizar el uso

de los recursos necesarios y agilizar el correcto procesamiento de la

información?

3.3.5 FORMULACIÓN DEL PROBLEMA

Analizando el diagrama de Causa-Efecto de la designación de cargas

horarias se encontró que:

En Equipo faltan Herramientas Tecnológicas.

En Personal falta de docentes.



65 CAPITULO 3

PROBLEMATICA

En Planificación poca coordinación.

En Materias la apertura.

En Procedimiento se realiza de forma manual.

3.4 REUNIONES CON EL CLIENTE

Se reunió con el personal de la Carrera ISAC donde estuvieron presentes:

Director de la carrera

Coordinador de la carrera

Docentes

Donde se hablo de lo que debería tener el sistema al momento de su

desarrollo, como van a estar diseñadas las pantallas y las consultas con sus

respectivos reportes.

3.4.1 REQUERIMIENTOS DEL SISTEMA.

Usuarios:

Se necesitara dos tipos de usuarios:

Administrador: Quién va a tener acceso a todo el sistema.

Usuario Invitado: Va a tener restricciones solo podrá hacer consultas e

imprimir los reportes.

Docentes:

Se hará el registro de un nuevo docente, actualización de datos, consultas.



66 CAPITULO 3

PROBLEMATICA

Llevaran estos campos donde se podrán ingresar la siguiente información:

Cedula

Nombres

Apellidos

Teléfono

Estado civil

Dirección

Sexo

Correo electrónico

Titulo

Dedicación si es tiempo completo o medio tiempo.

Área donde se desempeña.

La consulta se hará de dos formas:

El titulo del docente

Por todos los docentes

Materias:

Se hará el registro de materia, modificación y consulta.

Llevara los siguientes campos:

Código se los registrará con el código y año de la malla 101-2008

Nombre de la materia

Área de la materia

Créditos de la materia

La consulta se la hará por:

Nombre de la materia

Todas las materias

Actividades:

Se ingresaran las actividades no áulicas que se asignarán a los docentes:



67 CAPITULO 3

PROBLEMATICA

Código de actividad

Nombre de la actividad

Preparación de clases.

Tutorías.

Acreditación

Vinculación con la sociedad.

Investigación

Rediseño curricular.

Seguimiento a graduados.

La consulta se la hará por:

Todas las actividades

Cargas Horarias:

Se asignaran los horarios, asignatura, actividad y consulta a impartir para

cada docente.

Asignación de horario llevara los siguientes:

Se busca el docente

Selección de día y hora

Se guarda

Se modifica

Se elimina

Asignación de las materias llevara lo siguiente:

Se busca el docente

Se busca la materia

Selección de semestre

Selección de paralelo

Ingresa periodo

Ingresa ciclo

Selección de horario y día que ya están ingresados por el docente.



68 CAPITULO 3

PROBLEMATICA

Se guarda

Se modifica

Se elimina

Asignación de las actividades llevara lo siguiente:

Se busca el docente

Se busca la actividad

Ingresa periodo

Ingresa ciclo

Selección de horario y día que ya están ingresados por el docente.

Se guarda

Se modifica

Se elimina

Consulta de carga horaria:

Generar reporte



69

CAPITULO 4

PROPUESTA

CAPÍTULO 4

PROPUESTA

4.1 SOLUCIÓN PROPUESTA

Para mejorar la gestión académica de la carrera de Ingeniería en

Sistemas Administrativas Computarizados se propone desarrollar un

sistema como una herramienta de ayuda tecnológica para agilizar y

automatizar los procesos de la distribución de cargas horarias de los

docentes.

4.2 DETERMINACIÓN DE FACTIBILIDAD DE LA

PROPUESTA

Un proyecto es factible cuando se logra determinar que existen los

recursos disponibles para desarrollarlo. El éxito fundamental de un

proyecto es el grado de factibilidad que presenta en los siguientes

aspectos:

Factibilidad técnica

Factibilidad económica

Factibilidad operativa



70

CAPITULO 4

PROPUESTA

4.2.1 FACTIBILIDAD TÉCNICA

El proyecto es técnicamente factible cuando se puede identificar las áreas

del conocimiento del recurso humano, el hardware y el software requerido

para realizar de manera eficiente y eficaz el proceso de desarrollo e

implementación.

Tales requerimientos se agrupan en tres categorías:

Requerimiento de software

Requerimiento de hardware

Requerimiento de recursos humanos

4.2.1.1 Requerimientos de software

A continuación se detallan los requerimientos del software:

TABLA 4.1

REQUERIMIENTOS DE SOFTWARE

HERRAMIENTA SOFTWARE VERSIÓN

Gestor de Base de Datos SQL-Server 2005

Lenguaje de Programación C# 2013

Entorno de desarrollo Visual Studio 2013


4.2.1.2 Requerimientos de hardware

Una PC que contenga las siguientes características:



71

CAPITULO 4

PROPUESTA

o Sistema operativo windows 7.

o Mouse.

o Teclado.

o Impresora.

TABLA 4.2

REQUERIMIENTOS DE HARDWARE

MARCA PROCESADOR DISCO DURO MEMORIA MONITOR

HP INTEL CORE I3 500GB 4RAM HP

FUENTE: DIRECCIÓN ISAC


4.2.2 FACTIBILIDAD ECONÓMICA

Se realizará un análisis cuyo resultado determinará si el desarrollo e

implementación del sistema de distribución de cargas horarias de la

Carrera ISAC es factible económicamente es decir, se agilitará el proceso

y reducirá el tiempo que este lleva a cabo.

4.2.3 FACTIBILIDAD OPERACIONAL

El sistema será desarrollado de manera que ayude como herramienta

tecnológica a reducir el tiempo que se lleva en la distribución de cargas

horarias, así como también el registro de cada docente con sus

respectivas materias.



72

CAPITULO 4

PROPUESTA

Su interfaz será de fácil uso y amigable para el usuario, es factible de

realizarse operacionalmente, se cuenta con el apoyo de todo el personal

de la carrera, quienes nos brindan la información que se requiera.

4.3 ANÁLISIS ESTRUCTURADO

4.3.1 DIAGRAMAS DE CASOS DE USO

FIGURA 4.1

DIAGRAMA DE CASO DE USO ADMINISTRADOR




73

CAPITULO 4

PROPUESTA

FIGURA 4.2

DIAGRAMA DE CASO DE USO ADMINISTRADOR-DOCENTE


FIGURA 4.3

DIAGRAMA DE CASO DE USO ADMINISTRADOR-ASIGNATURA




74

CAPITULO 4

PROPUESTA

FIGURA 4.4

DIAGRAMA DE CASO DE USO ADMINISTRADOR-ACTIVIDAD


FIGURA 4.5

DIAGRAMA DE CASO DE USO ADMINISTRADOR-HORARIO




75

CAPITULO 4

PROPUESTA

FIGURA 4.6

DIAGRAMA DE CASO DE USO ADMINISTRADOR-CARGA HORARIA




76

CAPITULO 4

PROPUESTA

FIGURA 4.7

DIAGRAMA DE CASO DE USO ADMINISTRADOR-ASIGNA

ACTIVIDAD


FIGURA 4.8

DIAGRAMA DE CASO DE USO ADMINISTRADOR-INVITADO




77

CAPITULO 4

PROPUESTA

FIGURA 4.9

DIAGRAMA DE CASO DE USO ADMINISTRADOR-INVITADO-

CONSULTA




78

CAPITULO 4

PROPUESTA

4.3.2 DIAGRAMAS DE FLUJO DE DATOS (DFD)

FIGURA 4.10

DIAGRAMA DE FLUJO DE DATOS




79

CAPITULO 4

PROPUESTA

4.3.3 DIAGRAMA DE BASE DE DATOS

FIGURA 4.11

MODELO ENTIDAD RELACIÓN




80

CAPITULO 4

PROPUESTA

4.4 DICCIONARIO DE DATOS

TABLA 4.3

DICCIONARIO DE DATOS

Descripción: Base de datos que contendrá la tabla USUARIO

Campo Tamaño Tipo de Dato Descripción

NOMBRE 10 CARÁCTER Nombre del registro para acceder al sistema

CONTA 8 CARACTER Clave única del registro

NIVEL 15 CARACTER Nivel de accesibilidad del registro

CAMPO CLAVE

NOMBRE

Descripción: Base de datos que contendrá la tabla PROFESOR


IDPROFE 11 CARACTER Cedula del docente

NOMPRO 35 CARACTER Nombres del Docente

APELLIDPRO 35 CARACTER Apellidos del Docente

TELEFONO 11 CARACTER Teléfono del docente

ESTCIVIL 1 CARACTER Estado Civil del Docente

DIRECCION 55 CARACTER Dirección domiciliaria del Docente

SEXO 1 CARACTER Sexo del Docente

CORREO 35 CARACTER Correo personal o institucional del docente

TITULOMBA 35 CARACTER Titulo último que obtuvo el docente

TIPOCON 1 CARACTER Tiempo de desempeño del docente

AREA 55 CARACTER Área en la que va a desempeñar el docente

RELACIONES CAMPO CLAVE

ESTCIVIL con COMBOCIVIL (IDCI) IDPROFE

SEXO con COMBOSEXO (IDSE)

TIPOCON con COMBOCONTRATO (IDCON)



81

CAPITULO 4

PROPUESTA

Descripción: Base de datos que contendrá la tabla MATERIA


IDMAT 12 NUMERO Código de la materia

NOMATE 45 CARACTER Nombre de la materia

ARE 55 CARACTER Área que pertenece la materia

CREDITO 5 NUMERO Crédito que tiene la materia

CAMPO CLAVE

IDMAT

Descripción: Base de datos que contendrá la tabla ACTIVIDAD


CODIGO 3 NUMERO Código único de la actividad

NOMBRE 30 CARACTER Nombre de la actividad

CAMPO CLAVE

CODIGO

Descripción: Base de datos que contendrá la tabla COMBOSEXO


IDSE 1 NUMERO Código único del sexo

NOM 2 CARACTER Nombre del sexo

CAMPO CLAVE

IDSE

Descripción: Base de datos que contendrá la tabla COMBOCONTRATO


IDCON 1 NUMERO Código único de desempeño

NOMC 15 CARACTER Nombre del tiempo de desempeño del docente

CAMPO CLAVE IDCON

Descripción: Base de datos que contendrá la tabla COMBOCIVIL


IDCI 1 NUMERO Código único del estado civil

CIV 15 CARACTER Nombre del estado civil

CAMPO CLAVE IDCI



82

CAPITULO 4

PROPUESTA

Descripción: Base de datos que contendrá la tabla COMBOSEMESTRE


IDS 1 NUMERO Código único

SEC 2 NUMERO Número del semestre

CAMPO CLAVE

IDS

Descripción: Base de datos que contendrá la tabla COMBOPARALELO


IDP 1 NUMERO Código único

PA 2 NUMERO Número del paralelo

CAMPO CLAVE

IDP

Descripción: Base de datos que contendrá la tabla HORARIO


IDH INT NUMERICO

Número de registro se incrementa internamente

HPRO 11 CARACTER Cédula del Docente

HORARIO 17 CARACTER

Se guarda las horas que va a tener el Docente

LUNES 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

MARTES 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

MIERCOLES 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

JUEVES 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

VIERNES 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

SABADO 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

ESTADO 6 CARACTER Se guarda A si selecciona toda la fila de los checkbox que asiste a clases caso contrario N

RELACIÓN CAMPO CLAVE

HPRO con PROFESOR (IDPROFE) IDH



83

CAPITULO 4

PROPUESTA

Descripción: Base de datos que contendrá la tabla DOHORARIO


IDDP INT NUMERICO


IDDOC 11 CARACTER Cedula del Docente

IDMA 12 CARACTER Nombre de la Asignatura

SEMESTRE INT NUMERICO Semestre que corresponda

PARALELO INT NUMERICO Paralelo que corresponda

CICLO 2 CARACTER Ciclo al que va pertenecer

PEERIODO 17 CARACTER Periodo del año lectivo

HORA 17 CARACTER


LU 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

MA 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

MI 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

JU 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

VI 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

SA 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

ESTADO 6 CARACTER Se guarda A si selecciona toda la fila de los checkbox que asiste a clases caso contrario N


IDDOC con PROFESOR (IDPROFE) IDDP

IDMA con MATERIA (IDMAT)

SEMESTRE con COMBOSEMESTRE (IDS)

PARALELO con COMBOPAALELO (IDP)

Descripción: Base de datos que contendrá la tabla ACTIHORARIO


IDDAC INT NUMERICO


ACDO 11 CARÁCTER Cedula del Docente

IDAC 3 CARACTER Nombre de la Asignatura



84

CAPITULO 4

PROPUESTA

CI 2 CARACTER Ciclo al que va pertenecer

PERIODO 17 CARACTER Periodo del año lectivo

HORA 17 CARACTER


LUN 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

MAR 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

MIE 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

JUE 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

VIE 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

SAB 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no

EST 6 CARACTER Se guarda si en la tabla si se selecciona en el checkbox caso contrario no


ACDO con PROFESOR (IDPROFE) IDDAC

IDAC con ACTIVIDAD (CODIGO)


4.5 DISEÑO DE LAS PANTALLAS DEL SISTEMA

A continuación se muestran las pantallas de cómo quedaría el sistema al

momento de que se vaya a implementar.



85

CAPITULO 4

PROPUESTA

FIGURA 4.12

PANTALLA PRINCIPAL-INGRESO AL SISTEMA


FIGURA 4.13

PANTALLA DE MENÚ DEL SISTEMA




86

CAPITULO 4

PROPUESTA

FIGURA 4.14

PANTALLA DEL MENÚ DE DOCENTES


FIGURA 4.15

PANTALLA DEL REGISTRO DEL DOCENTE




87

CAPITULO 4

PROPUESTA

FIGURA 4.16

PANTALLA DEL MENÚ DE DOCENTES-CONSULTAS


FIGURA 4.17

PANTALLA DE CONSULTA POR TÍTULO




88

CAPITULO 4

PROPUESTA

FIGURA 4.18

PANTALLA DEL MENÚ DE DOCENTES-CONSULTAS POR

DOCENTES


FIGURA 4.19

PANTALLA DE CONSULTA POR DOCENTES




89

CAPITULO 4

PROPUESTA

FIGURA 4.20

PANTALLA DEL MENÚ MATERIAS


FIGURA 4.21

PANTALLA DEL REGISTRO DE LAS MATERIAS




90

CAPITULO 4

PROPUESTA

FIGURA 4.22

PANTALLA DEL MENÚ DE MATERIAS-CONSULTAS POR NOMBRE


FIGURA 4.23

PANTALLA DE BUSQUEDA POR NOMBRE DE LA MATERIA




91

CAPITULO 4

PROPUESTA

FIGURA 4.24

PANTALLA DEL MENÚ DE MATERIAS-CONSULTAS POR MATERIAS


FIGURA 4.25

PANTALLA DE BUSQUEDA POR TODAS LAS MATERIAS




92

CAPITULO 4

PROPUESTA

FIGURA 4.26

PANTALLA DEL MENÚ ACTIVIDADES


FIGURA 4.27

PANTALLA DE REGISTRO DE ACTIVIDADES




93

CAPITULO 4

PROPUESTA

FIGURA 4.28

PANTALLA DEL MENÚ ACTIVIDADES-CONSULTA


FIGURA 4.29

PANTALLA DE CONSULTA DE ACTIVIDADES




94

CAPITULO 4

PROPUESTA

FIGURA 4.30

PANTALLA DEL MENÚ CARGAS HORARIAS


FIGURA 4.31

PANTALLA DE ASIGNACIÓN DE CARGAS HORARIAS DOCENTE




95

CAPITULO 4

PROPUESTA

FIGURA 4.32

PANTALLA DEL MENÚ CARGAS HORARIAS- MATERIA


FIGURA 4.33

PANTALLA DE ASIGNACIÓN DE MATERIAS




96

CAPITULO 4

PROPUESTA

FIGURA 4.34

PANTALLA DEL MENÚ CARGAS HORARIAS- ACTIVIDAD


FIGURA 4.35

PANTALLA DE ASIGNACIÓN DE ACTIVIDADES




97

CAPITULO 4

PROPUESTA

FIGURA 4.36

PANTALLA DEL MENÚ CONSULTAS


FIGURA 4.37

PANTALLA DONDE SE GENERA EL HORARIO DEL DOCENTE




98

CAPITULO 4

PROPUESTA

4.6 PLAN DE PROYECTO BAJO LA METODOLOGÍA

SCRUM



99

CONCLUSIONES Y RECOMENDACIONES


CONCLUSIONES

Se aplico la Metodología Ágil Scrum para el análisis y desarrollo de este

proyecto, utilizando un entorno de Desarrollo en Visual Studio 2013 con un

lenguaje de programación en C# con una Base de Datos SQL Sever 2005 en

un entorno de escritorio.

Es factible la implementación de este Sistema de Cargas Horarias, ya que a

futuro permitirá automatizar y agilizar una parte del Área Administrativa de la

Carrera ISAC, aportando con el crecimiento tecnológico de la Carrera.

Los procesos utilizados manualmente, serán sustituidos para los procesos

automatizados, disminuyendo tiempos al momento de generar los horarios

de los docentes, haciendo que el sistema sea amigable con la persona que

va a manejarlo.

El personal de la Carrera ISAC, ha brindado la información necesaria que ha

servido de gran utilidad para la culminación del Análisis y Diseño del

Sistema.



100


RECOMENDACIONES

Si se implementará el sistema se tendrá datos actualizados guardados en

una base de datos, para proveer una información oportuna y confiable.

Se recomienda utilizar el modelo matemático con restricciones en la

distribución o asignación de las cargas horarias de los docentes en un

ambiente para desarrollo web.

Sugerir que las personas encargadas del manejo del sistema de distribución

de cargas horarias digan las posibles mejoras que se puedan realizar, de

esta manera tener un sistema que este ajustado a los requerimientos del

Usuario.

Impulsar que se implemente el sistema en las demás carreras de la Facultad

para promover el desarrollo tecnológico y poner en funcionamiento los

proyectos de software que realizan los egresados para finalizar su carrera,

dando un espacio que puedan ser útiles para la administración de las

carreras.



101

BIBLIOGRAFÍA

BIBLIOGRAFÍA

ISSI (2003). METODOLOGÍAS ÁGILES EN EL DESARROLLO DE

SOFTWARE. RECUPERADO DE:

HTTP://ISSI.DSIC.UPV.ES/ARCHIVES/F-1069167248521/ACTAS.PDF

WELLS, D. (2009) PROGRAMACIÓN EXTREMA.

RECUPERADO DE: HTTP://WWW.EXTREMEPROGRAMMING.ORG

TRIGAS GALLEGO, M. (2012) GESTIÓN DE PROYECTOS

INFORMÁTICOS. “METODOLOGIA SCRUM” (TESIS DE GRADO,

UNIVERSIDAD OBERTA DE CATALUNYA) RECUPERADO DE:

HTTP://OPENACCESS.UOC.EDU/WEBAPPS/O2/BITSTREAM/10609/17

885/1/MTRIGASTFC0612MEMORIA.PDF

PÁGINA WEB SIGNIFICADOS RECUPERADO DE:

HTTP://WWW.SIGNIFICADOS.COM

PÁGINA WEB DEFINICIÓN ABC, RECUPERADO DE:

HTTP://WWW.DEFINICIONABC.COM

PÁGINA WEB MASTERMAGAZINE, RECUPERADO DE:

HTTP://WWW.MASTERMAGAZINE.INFO

PÁGINA WEB DEFINICIÓN.DE, RECUPERADO DE:

HTTP://DEFINICION.DE

PÁGINA WEB DESARROLLO WEB, RECUPERADO DE:

HTTP://WWW.DESARROLLOWEB.COM


http://www.extremeprogramming.org/

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf

http://www.significados.com/

http://www.definicionabc.com/

http://www.mastermagazine.info/

http://definicion.de/

http://www.desarrolloweb.com/



102

BIBLIOGRAFÍA

PÁGINA WEB SEARCH DATA CENTER, RECUPERADO DE:

HTTP://SEARCHDATACENTER.TECHTARGET.COM

PÁGINA WEB MICROSOFT, RECUPERADO DE:

HTTPS://MSDN.MICROSOFT.COM

PÁGINA WEB MAS ADELANTE, RECUPERADO DE:

HTTPS://WWW.MASADELANTE.COM

PÁGINA WEB UNIVERSIDAD DE PALERMO, RECUPERADO DE:

HTTP://FIDO.PALERMO.EDU

PÁGINA WEB THE FREE DICTIONARY, RECUPERADO DE:

HTTP://ES.THEFREEDICTIONARY.COM

PÁGINA WEB WORD REFERENCE, RECUPERADO DE:

HTTP://WWW.WORDREFERENCE.COM

PÁGINA WEB DEVNETTIPS, RECUPERADO DE:

HTTP://DEVNETTIPS.BLOGSPOT.COM.ES

PÁGINA WEB BLOGSPOT, RECUPERADO DE:

HTTP://WWW.ANDRAGOGIA-FRANCISCO-M.BLOGSPOT.COM/

PÁGINA WEB FACULTAD DE CIENCIAS ADMINISTRATIVAS-

UNIVERSIDAD DE GUAYAQUIL, RECUPERADO DE:

HTTP://WWW.FCA.UG.EDU.EC/?PAGE_ID=100

http://searchdatacenter.techtarget.com/

https://msdn.microsoft.com/

https://www.masadelante.com/

http://fido.palermo.edu/

http://es.thefreedictionary.com/

http://www.wordreference.com/

http://devnettips.blogspot.com.es/

http://www.andragogia-francisco-m.blogspot.com/

http://www.fca.ug.edu.ec/?page_id=100

Documents

UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec/bitstream/redug/20335/1/TESIS FINAL... · 2018. 11. 19. · Este proyecto tiene como objetivo analizar y diseñar un sistema de distribución