UNIVERSIDAD NACIONAL AGRARIA DE LA

SELVA
FACULTAD DE INGENIERIA EN INFORMATICA Y SISTEMAS

MODELO TEORICO PARA EL DESARROLLO DEL PROTOTIPO DE UN

SISTEMA INFORMATICO PARA EL CONTROL DE ASISTENCIA Y HORARIOS
PARA LA FACULTAD DE INGENIERIA E INFORMATICA Y SISTEMAS.

ALUMNO :

Castillo Guerra, Gianny Warhol

DOCENTE :

MSc. Marco Canales Aguirre

CURSO :

SEMINARIO DE TESIS II

Tingo Maria Octubre Del

2015
 INDICE

INDICE........................................................................................................................... 2

1. INTRODUCCION.......................................................................................................3

2. OBJETIVOS.............................................................................................................. 4

2.1 OBJETIVO GENERAL...............................................................................................4

2.2 OBJETIVOS ESPECFICOS........................................................................................5

3. DESARROLLO DEL MODELO TEORICO................................................................5

3.1 DESCRIPCIN DE LA PROBLEMTICA:........................................................................5

3.2 ELEMENTOS IDENTIFICADOS PARA EL MODELO TERICO.............................................6
3.3 ELABORACIN SOBRE EL MARCO TERICO DEL DESARROLLO DEL PROTOTIPO DE UN
SISTEMA INFORMTICO PARA EL CONTROL DE ASISTENCIA Y HORARIOS PARA LA FACULTAD

DE INFORMTICA Y SISTEMAS......................................................................................10

3.3.1. Ingeniera de Software................................................................................10

3.3.1.1 El Software............................................................................................10
3.3.1.2 Caractersticas del Software..................................................................11
3.3.1.3 Aplicaciones del Software......................................................................11
3.3.1.4 Modelo de Desarrollo de Software........................................................12
3.3.1.5 Modelo de Desarrollo de Software en Cascada.....................................12
3.3.1.5.1. Definicin.......................................................................................12
3.3.1.5.2. Caractersticas...............................................................................12
3.3.1.5.3 Estructura.......................................................................................13
3.3.2. Arquitectura Cliente Servidor...................................................................14
3.3.2.1. Definicin..............................................................................................14
3.3.2.2. Caractersticas.....................................................................................15
3.3.2.3. Cliente..................................................................................................15
3.3.2.4. Servidor................................................................................................16
3.3.3 Base de Datos.............................................................................................16
3.3.3.1. Definicin de Base de Datos................................................................16
3.3.3.2. Caractersticas de Base de Datos........................................................17
3.3.3.3. Ventajas y Aplicaciones de Base de Datos...........................................17
3.3.3.4. Sistema Gestor de Base de Datos.......................................................18
3.3.3.4.1. Caractersticas de un SGBD..........................................................18
3.3.3.4.2. Arquitectura de SGBD....................................................................19
3.3.4. Herramientas de Desarrollo........................................................................20
3.3.4.1. Fundamentos de SQLSERVER............................................................20
 3.3.4.2. Fundamentos de Microsoft Visual Studio 2010.....................................21
3.3.4.3. Microsoft .Net Framework....................................................................22
3.3.4.4. C#.........................................................................................................22
3.3.5 Los Estndares de Calidad ISO para Desarrollo de Software ....................23
3.3.5.1 La Calidad en Ingeniera de Software...................................................23
3.3.5.2 La calidad desde el aspecto organizacional. La familia iso 9000...........24
3.3.5.3 El Concepto de Calidad del Software....................................................27
3.3.5.4 Mtricas de Calidad del Software..........................................................29
3.3.5.5 Las Diferentes Aproximaciones.............................................................30
3.3.5.5 La Verificacin y la Validacin del Software...........................................32
3.3.5.6. Las Revisiones del Software................................................................32
3.3.5.7. Metodologia de Desarrollo Agil Programacion Extrema(Xp).................34

4. BIBLIOGRAFIA.......................................................................................................37
1. INTRODUCCION

Para el desarrollo del prototipo de un sistema Informtico para el control de asistencia

y horarios para la facultad de ingeniera e informtica y sistemas se debe tener bien
fundamento el marco terico en el cual se va a desarrollar, para el cumplimiento del
desarrollo del curso de Seminario de Tesis 2, se describir con ms detalle la
realizacin sobre el marco terico, teniendo en cuenta el modelo de terico de
investigacin del proyecto, as mismo el informe describe los elementos que estn
incluidos en el modelo su relacin, interaccin u otros.
2. OBJETIVOS

2.1 Objetivo General

Desarrollar el modelo terico para el desarrollo del prototipo de un sistema informtico
para el control de asistencia y horarios para la facultad de informtica y sistemas.

2.2 Objetivos Especficos

Desarrollar el modelo terico en Microsoft Visio 2010.
Identificar los elementos que son afectados dentro y fuera del prototipo a
desarrollar.
Interrelacionar los elementos que estn dentro y fuera (Entorno y sistema en
estudio) del prototipo a desarrollar.
Describir todos los elementos fundamentando inclusin en el modelo terico.

3. DESARROLLO DEL MODELO TEORICO

Para el desarrollo del modelo terico del desarrollo del prototipo del sistema
informtico se necesita tener en cuenta la problemtica que existe dentro del objeto de
estudio para eso realizaremos una descripcin de lo mencionado, para luego
identificar los elementos que forman parte del modelo:

3.1 Descripcin de la problemtica:

En la actualidad la facultad de informtica y sistemas no cuenta con un sistema

para controlar las asistencia de profesores, alumnos y sobre el monitoreo del
cumplimiento de los slabos de los cursos que se realizan en cada semestre.

El sistema de control de asistencia a los profesores se da de forma manual en

la facultad de informtica y sistemas y se encuentra ubicado dentro de las
instalaciones de la facultad en la oficina del jefe de departamento, ubicacin
lejana a las aulas de los pabellones donde se dictan las clases. Como tambin
no se tiene un control sobre los alumnos que asisten a las clases de los
profesores y tampoco se tiene un control sobre el cumplimiento de los slabos
de los cursos para el semestre vigente.

De la misma manera los reportes se hacen de forma manual cuando se

necesita informacin sobre las asistencias de los profesores para sus
respectivos pagos mensuales.
De acuerdo a la investigacin realizada en la facultad de informtica y sistemas
se verifico que para consultar el horario de un saln se tiene que ir
directamente a OCDA.

La informacin que se requiere es limitada por que solo OCDA te lo puede

brindar.

En esta situacin la importancia de la informacin, motiva a realizar un

prototipo de sistema de informtico que brinde reportes sobre la disponibilidad
de los horarios, asistencia de los profesores y alumnos que estn dentro de un
curso dictados en las aulas de la universidad y sobre todo esta informacin
podr brindar los responsables de cada laboratorio como tambin la secretaria
de facultad u otros, ya que este sistema estar en un servidor de la Facultad de
Informtica y Sistemas, esto permitir que cualquier persona que necesita la
informacin (Disponibilidad de horarios de las aulas que utiliza la facultad,
costo de cursos extracurriculares, registro de notas de cursos extracurriculares,
asistencia de profesores y alumnos) podr acceder a ella y por sobre todo se
podr llevar una administracin eficiente de los horarios y un control sobre las
asistencias de los alumnos, profesores y monitorear el cumplimiento de los
slabos de los cursos de cada semestre.

3.2 Elementos identificados para el modelo terico

Los elementos que se identificaron son los siguientes:

1. La universidad nacional agraria de la selva:

Que es la entidad donde se est realizando el proyecto y este ser afectado
por que el desarrollo del prototipo tendr un impacto a futuro sobre la
Universidad.
2. Facultad de ingeniera e informtica y sistemas:
Que es la entidad que utilizara el prototipo de desarrollado para la mejora
en la administracin de los horarios, asistencias y monitoreo del
cumplimiento de los slabos de los cursos que se dictan.
3. Las dems facultades que se encuentran dentro de la Universidad
nacional agraria de la selva:

Son las entidades que forman parte del entorno del sistema y de una u otra
manera el desarrollo de este prototipo tendr un impacto en la estas
entidades.

4. Las empresas independientes, pequeas o grandes empresas,

organizaciones que desean dictar cursos en la facultad de sistemas:
 Son las entidades que forman parte del entorno del sistema que tendrn
mucha relacin con el sistema porque ellos sern los interesados
indirectamente por que buscaran informacin sobre los horarios disponibles
para dictar los cursos que tengan disponibles para los alumnos de la
facultad.
5. Las personas en general, comunidad de tingo mara, estudiantes de
otras facultades que tengan inters en matricularse a los cursos
dictados en la facultad de ingeniera e informtica y sistemas:
Es la entidad que forma parte del sistema ya que ellos accedern a los
cursos que se dictaran en la facultad.
6. El jefe de departamento:
En la entidad que necesita la informacin sobre las asistencias de los
alumnos y profesores como tambin sobre el monitoreo del cumplimiento
de los slabos de los cursos en cada semestre.
7. La secretaria que podr brindar a informacin sobre los horarios
disponibles de los cursos extracurriculares u otros cursos:
Es la entidad que usara el sistema informtico para brindar informacin
sobre disponibilidad de horario a las entidades que lo necesiten
Es
8. Los salones donde se registrara las asistencias de los profesores y
alumnos:
Es e lugar donde se registrara las asistencias de los profesores y alumnos
como tambin se registrara los temas de los slabos para el dictado de las
clases.
9. El registro de los temas dictados de los slabos para confirmar el
cumplimento de los slabos de los curso de la facultad de ingeniera e
informtica y sistemas:
El registro de los temas servir como indicador para la toma de decisiones.
10. La facultad de ingeniera e informtica y sistemas que se beneficiara
con el desarrollo del prototipo de sistema informtico:
Es la entidad beneficiada por el desarrollo del prototipo, esto servir para
poder realizar una implementacin del sistema.
11. Los alumnos de la facultad de informtica y sistemas.
Estas entidades tambin forman parte de las dimensiones del objeto de
estudio.
12. Los cursos:
Son las entidades que forman parte de las dimensiones del sistema.
As mismo ellos registraran su asistencia en el sistema.
13. Los profesores:
Son las entidades que forman parte de las dimensiones del sistema.
As mismo ellos registraran su asistencia en el sistema.
Organizacin que ser el objeto de estudio.
MODELO TEORICO
 3.3 Elaboracin sobre el marco terico del desarrollo del prototipo
de un sistema informtico para el control de asistencia y horarios
para la facultad de informtica y sistemas

3.3.1. Ingeniera de Software1

Segn Roger Pressman la Ingeniera del Software es el establecimiento y

uso de principios robustos de la ingeniera a fin de obtener econmicamente
software que sea fiable y que funcione eficientemente sobre mquinas
reales.

La Ingeniera de Software aplica de forma prctica el conocimiento cientfico

para disear y desarrollar software, adems de elaborar los procesos y
documentacin necesaria para poder mantenerlos funcionales. El proceso
de Ingeniera de Software est definido como un conjunto ordenado de
etapas con la intencin de cumplir un objetivo establecido, siendo ste
software de alta calidad.

3.3.1.1 El Software.

El software es una produccin inmaterial del cerebro humano y tal vez

una de las estructuras ms complicadas que la humanidad conoce. El
Software es el nico medio que permite entablar una comunicacin
entre el usuario y la mquina.

Software es el resultado de la aplicacin de tcnicas y conocimientos

cientficos y prcticos de la ingeniera conjuntamente con los principios
de la informtica, para crear un sistema computacional que este de
acorde a las especificaciones del cliente, satisfaciendo sus necesidades
y exigencias.

Cada da se utilizan nuevas tcnicas conceptuales y herramientas de

desarrollo que permiten crear un producto mucho ms acorde a las
tendencias tecnolgicas actuales, lo cual no solo permitir tener un
software de mayor calidad sino que se garantizar que se pueda

1 (DAVID, 2007) pag 25

 actualizar cada vez que se considere necesario un cambio ya sea
preventivo como correctivo.

3.3.1.2 Caractersticas del Software

Tanto para el desarrollo de un producto de software como para la

fabricacin de un producto que sea tangible se requiere de una
planificacin y diseo para que est de acorde con lo esperado. El
desarrollo abarca un diseo mucho ms enfocado en que los procesos
estn a la medida de lo solicitado, y en la fabricacin en cambio los
procesos se estandarizan y siguen un modelo previamente establecido.

El software al ser un producto intangible depende nica y

exclusivamente de s mismo, por lo cual no se deteriora, ya sea por
aspectos fsicos o de uso. Esto es una gran ventaja tanto para el
desarrollador que tendr que brindar un soporte enfocado solo al
funcionamiento procedimental del mismo como para el cliente final que
no tendr que preocuparse por mantenerlo limpio o no tener que
maltratarlo.

Un producto de software es desarrollado a medida de los

requerimientos y necesidades. sta es la mayor diferencia entre un
producto de software y un producto tangible. El software se desarrolla
en base a un proceso nico establecido por el cliente, esto garantizar
que el resultado sea el esperado y que no haya sorpresas inesperadas
al final.

3.3.1.3 Aplicaciones del Software

Un software puede ser aplicado en mltiples mbitos en los cuales exista

una planeacin previa siguiendo un conjunto ordenado de pasos. Debido a
la gran variedad de reas donde se puede aplicar el software se han
establecido categoras genricas que representen la aplicacin en cada una
de ellas.

Software de Sistemas: Comprende un conjunto de programas utilizados

para crear otros programas. La principal caracterstica es la notable
interaccin con el hardware para lograr resultados esperados.
 Software de Tiempo Real: Comprende una serie de programas que
controlan acontecimientos conforme stos ocurren, siendo la principal
caracterstica la velocidad de respuesta.

Software de Gestin: Comprende un conjunto de programas que

reestructuran datos existentes para facilitar operaciones y asesorar en la
toma de decisiones.

3.3.1.4 Modelo de Desarrollo de Software

Un modelo de desarrollo de software define la estructura de un proceso

de desarrollo racional y controlable, mismo que sirve como gua con
respecto al orden que debe seguirse para desarrollar un software de
calidad, lo cual significa que en el modelado de software se establece el
orden en el que se harn las actividades del proyecto, proveyendo de
requisitos de entrada y salida para cada proceso.

Los procedimientos que se involucran en el modelado de un software se

refieren a las diversas actividades que se realizan para la construccin,
liberacin y evolucin de un producto de software, comenzando con el
estudio de una idea y finalizando con el retiro final del sistema.

El modelo de proceso de Software es una estrategia de desarrollo que

acompaa a la Ingeniera del Software, ya que es una tecnologa
multicapa, la misma que debe apoyarse sobre un compromiso de
organizacin de calidad.

3.3.1.5 Modelo de Desarrollo de Software en Cascada

3.3.1.5.1. Definicin

Este modelo posee una secuencia ordenada de sus actividades, en la

cual el trabajo de una etapa anterior se transforma en la entrada de la
siguiente actividad lo cual provee y garantiza un gran control sobre las
fechas estimadas de entrega.

3.3.1.5.2. Caractersticas

El Modelo de Cascada es muy confiable cuando se tiene un producto

estable y se conoce la tecnologa disponible.
 Es un mtodo muy estructurado y provee estabilidad en los
requerimientos.

Para iniciar una nueva etapa dentro de los lineamientos de ste modelo
se debe necesariamente haber terminado la etapa anterior.

3.3.1.5.3 Estructura

Estructura del Modelo de Cascada

Fuente: elaboracin propia.

Ingeniera y Anlisis del Sistema: El trabajo comienza estableciendo los

requisitos de todos los elementos del sistema y luego asignando algn
subconjunto de estos requisitos al software.

Anlisis de los Requisitos: El desarrollador debe comprender el mbito

de la informacin del software, as como la funcin, el rendimiento y las
interfaces requeridas.

Diseo: Se enfoca en cuatro atributos distintos del programa: la estructura

de los datos, la arquitectura del software, el detalle procedimental y la
caracterizacin de la interfaz. Traduce los requisitos en una representacin
del software con la calidad requerida antes de que comience la codificacin.

Codificacin: Traduce en una forma legible para la mquina el diseo

previamente elaborado del sistema. Si el diseo se realiza de una manera
detallada la codificacin puede realizarse mecnicamente.
 Prueba: La prueba se centra en la lgica interna del software, y en las
funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.

Mantenimiento: Despus de la entrega del sistema al cliente se debern

realizar cambios, mismos que ocurrirn debido a errores encontrados, a
que el software deba adaptarse a cambios del entorno externo o debido a
que el cliente requiera ampliaciones funcionales o del rendimiento.

3.3.2. Arquitectura Cliente Servidor2

3.3.2.1. Definicin

Es una arquitectura distribuida que permite a los usuarios finales obtener

acceso a la informacin en forma transparente an en entornos
multiplataforma.

En el modelo cliente servidor, el cliente enva un mensaje solicitando un

determinado servicio a un servidor (hace una peticin), y este enva uno o
varios mensajes con la respuesta (provee el servicio. En un sistema
distribuido cada mquina puede cumplir el rol de servidor para algunas
tareas y el rol de cliente para otras.

Ilustracin Estructura Modelo Cliente Servidor

2 (DONOSO, 2013) pag 32

La arquitectura Cliente/Servidor es una extensin de programacin modular
en la que la base fundamental es separar una gran pieza de software en
mdulos con el fin de hacer ms fcil el desarrollo y mejorar su
mantenimiento.

Esta arquitectura permite distribuir fsicamente los procesos y los datos en

forma ms eficiente lo que en computacin distribuida afecta directamente
el trfico de la red, reducindolo grandemente.

3.3.2.2. Caractersticas

Combinacin de un cliente que interacta con el usuario, y un servidor que

interacta con los recursos compartidos. El proceso del cliente proporciona
la interfaz entre el usuario y el resto del sistema. El proceso del servidor
acta como un motor de software que maneja recursos compartidos tales
como bases de datos, impresoras, mdems, etc.

Las tareas del cliente y del servidor tienen diferentes requerimientos en

cuanto a recursos de cmputo como velocidad del procesador, memoria,
velocidad y capacidades del disco y dispositivos.

Existe una clara distincin de funciones basada en el concepto de

"servicio", que se establece entre clientes y servidores.

La relacin establecida puede ser de muchos a uno, en la que un servidor

puede dar servicio a muchos clientes, regulando su acceso a recursos
compartidos.

Los clientes corresponden a procesos activos en cuanto a que son stos

los que hacen peticiones de servicios a los servidores. Estos ltimos tienen
un carcter pasivo ya que esperan las peticiones de los clientes.

3.3.2.3. Cliente

Es el proceso que permite al usuario formular los requerimientos y pasarlos al

servidor, mismo que normalmente maneja todas las funciones relacionadas con
la manipulacin y despliegue de datos, por lo que estn desarrollados sobre
plataformas que permiten construir interfaces grficas de usuario, adems de
acceder a los servicios distribuidos en cualquier parte de una red.
 Las funciones principales que lleva a cabo el proceso cliente son:

Administrar la interfaz de usuario.

Interactuar con el usuario.

Procesar la lgica de la aplicacin y hacer validaciones locales.

Generar requerimientos de bases de datos.

Recibir resultados del servidor.

Formatear resultados.

3.3.2.4. Servidor

Es el proceso encargado de atender a mltiples clientes que hacen peticiones

de algn recurso administrado por l, mismo que normalmente maneja todas
las funciones relacionadas con la mayora de las reglas del negocio y los
recursos de datos.

Las funciones principales que lleva a cabo el proceso servidor son:

Aceptar los requerimientos de bases de datos que hacen los clientes.

Procesar requerimientos de bases de datos.

Formatear datos para trasmitirlos a los clientes.

Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases

de datos.

3.3.3 Base de Datos3

3.3.3.1. Definicin de Base de Datos

Se define una base de datos como una serie de datos organizados y

relacionados entre s, los cuales son recolectados y explotados por los
sistemas de informacin de una empresa o negocio en particular.

3 (DONOSO, 2013) pag 43

Una base de datos es un almacn que nos permite guardar grandes
cantidades de informacin de forma organizada para que luego podamos
encontrar y utilizar fcilmente.

3.3.3.2. Caractersticas de Base de Datos

Una base de datos proporciona a los usuarios el acceso a datos, que

pueden visualizar, ingresar o actualizar, en concordancia con los derechos
de acceso que se les hayan otorgado. Se convierte ms til a medida que la
cantidad de datos almacenados crece.

Independencia lgica y fsica de los datos.

Redundancia mnima.

Acceso concurrente por parte de mltiples usuarios.

Integridad de los datos.

Consultas complejas optimizadas.

Seguridad de acceso y auditora.

Respaldo y recuperacin.

Acceso a travs de lenguajes de programacin estndar.

3.3.3.3. Ventajas y Aplicaciones de Base de Datos

Independencia de los datos respecto a los tratamientos. Mejora su

disponibilidad y se produce mayor eficiencia en la recogida, codificacin y
entrada.

Coherencia de los resultados: En todos los tratamientos se utilizan los

mismos datos, por lo que los resultados de estos son coherentes y
comparables.
 Mejor disponibilidad de los datos para el conjunto de los usuarios: stos se
comparten entre las aplicaciones, existiendo una mayor disponibilidad y
transferencia.

Reduccin del espacio de almacenamiento: Disminucin de redundancias y

las tcnicas de compactacin hacen que disminuya el espacio en disco.

3.3.3.4. Sistema Gestor de Base de Datos

Un SGBD es una coleccin de datos relacionados entre s, estructurados y

organizados, y un conjunto de programas que acceden y gestionan esos
datos. Se compone de un lenguaje de definicin de datos, de un lenguaje
de manipulacin de datos y de un lenguaje de consulta. Un SGBD permite
definir los datos a distintos niveles de abstraccin y manipular dichos datos,
garantizando la seguridad e integridad de los mismos.

3.3.3.4.1. Caractersticas de un SGBD

Abstraccin de la informacin. Los SGBD ahorran a los usuarios detalles

acerca del almacenamiento fsico de los datos.

Independencia. La independencia de los datos consiste en la capacidad de

modificar el esquema (fsico o lgico) de una base de datos sin tener que
realizar cambios en las aplicaciones que se sirven de ella.

Redundancia mnima. Se evita la aparicin de informacin repetida o

redundante. De entrada, lo ideal es lograr una redundancia nula; no
obstante, en algunos casos la complejidad de los clculos hace necesaria
la aparicin de redundancias.

Consistencia. En aquellos casos en los que no se ha logrado esta

redundancia nula, ser necesario vigilar que aquella informacin que
aparece repetida se actualice de forma coherente.

Seguridad. Los SGBD deben garantizar que la informacin se encuentra

asegurada frente a usuarios malintencionados, que intenten leer
informacin privilegiada; frente a ataques que deseen manipular o destruir
la informacin; o simplemente ante las torpezas de algn usuario
autorizado pero despistado.
 Integridad. Se trata de proteger los datos ante fallos de hardware, datos
introducidos por usuarios descuidados, o cualquier otra circunstancia capaz
de corromper la informacin almacenada.

Respaldo y recuperacin. Los SGBD deben proporcionar una forma

eficiente de realizar copias de respaldo de la informacin almacenada en
ellos, y de restaurar a partir de estas copias los datos que se hayan podido
perder.

3.3.3.4.2. Arquitectura de SGBD

El comit ANSI-SPARC propuso una arquitectura de tres niveles para los

SGBD cuyo objetivo principal era el de separar los programas de
aplicacin de la BD fsica. En esta arquitectura el esquema de una BD
se define en tres niveles de abstraccin distintos:

Nivel interno o fsico: el ms cercano al almacenamiento fsico, es decir, tal

y como estn almacenados en el ordenador. Describe la estructura fsica de
la BD mediante un esquema interno. Este esquema describe los detalles de
cmo se almacenan fsicamente los datos.

Nivel externo o de visin: es el ms cercano a los usuarios, es decir, es

donde se describen varios esquemas externos o vistas de usuarios. Cada
esquema describe la parte de la BD que interesa a un grupo de usuarios en
este nivel se representa la visin individual de un usuario.

Nivel conceptual: describe la estructura de toda la BD para un grupo de

usuarios mediante un esquema conceptual. Este esquema describe las
entidades, atributos, relaciones, operaciones de los usuarios y
restricciones, ocultando los detalles de las estructuras fsicas de
almacenamiento.

Ilustracin. Arquitectura de un SGBD

 3.3.4. Herramientas de Desarrollo4

3.3.4.1. Fundamentos de SQLSERVER

Las bases de datos relacionales se han convertido en el mecanismo de
almacenamiento de datos ms comn para las aplicaciones computacionales
modernas. Los lenguajes de programacin como Java, C y COBOL, y los
lenguajes interpretados de programacin como Perl, VBScript y JavaScript muy
a menudo acceden a las fuentes de datos para poder recuperar o modificar los
datos. Muchas de estas fuentes de datos son administradas a travs de un
sistema de administracin de bases de datos relacionales (RDBMS), como
Oracle, Microsoft SQL Server, MySQL y DB2, que tiene como base el Lenguaje
de Consulta Estructurado (SQL) para crear y alterar los objetos de la base de
datos, agregar datos y eliminarlos de la base de datos, modificar datos que han
sido agregados a esa base de datos y, por supuesto, recuperar datos
almacenados en la base de datos para su desplegado y procesamiento.

SQL es el lenguaje ms ampliamente implementado para las bases de datos

relacionales. De la misma manera que las matemticas son el lenguaje de la
ciencia, SQL es el lenguaje de las bases de datos relacionales. SQL no
solamente permite administrar los datos dentro de la base de datos, sino
tambin manejar la base de datos en s.

4 (DONOSO, 2013) pag 49

Utilizando las instrucciones SQL, es posible acceder a una base de datos SQL
directamente al utilizar una aplicacin cliente interactiva o a travs de un
lenguaje de programacin de aplicacin o lenguaje interpretado. Sin importar
cul sea el mtodo que se utilice para acceder a una fuente de datos, es
obligatoria una buena base acerca de cmo escribir instrucciones SQL para
poder acceder a los datos relacionales. Fundamentos de SQL, tercera edicin,
le proporciona esa base. Se describen todos los tipos de instrucciones que
soporta SQL y se explica cmo son utilizadas para administrar bases de datos
y sus datos. A travs del trabajo con este libro, usted construir fuertes
cimientos en SQL bsico y obtendr un profundo entendimiento de cmo
utilizar SQL para acceder a los datos en su base de datos relacional.

Esta tercera edicin ha sido actualizada para incluir las disposiciones del
estndar ISO SQL:2006 adems de todos sus errores corregidos que se
publicaron en 2007. El captulo 18 ha sido incluido para cubrir SQL/XML, que
fue agregado al estndar SQL en 2006. Adems, las instrucciones SQL han
sido reformateadas y todos los nombres de objeto de la base de datos han sido
convertidos a maysculas para hacer ms fcil su lectura y conversin, a
travs de la amplia variedad de los productos RDBMS disponibles
comercialmente.

3.3.4.2. Fundamentos de Microsoft Visual Studio 2010

Microsoft Visual Studio es un Entorno de Desarrollo Integrado (IDE) que

asegura cdigo de calidad durante todo el ciclo de vida de la aplicacin, desde
el diseo hasta la implementacin. Permite a los desarrolladores crear
aplicaciones, sitios y aplicaciones web, as como servicios web en cualquier
entorno que soporte la plataforma .NET (a partir de la versin .NET 2002). As
se pueden crear aplicaciones que se intercomuniquen entre estaciones de
trabajo, pginas web y dispositivos mviles.

Microsoft Visual Studio 2010 viene acompaada por .NET Framework 4.0.
Es el paquete completo de herramientas de administracin del ciclo de vida
de las aplicaciones para equipos. Con este paquete puede garantizar la
calidad de los resultados, desde el diseo hasta la implementacin.
 3.3.4.3. Microsoft .Net Framework

Es un componente de software incluido en los sistemas operativos Microsoft

Windows. Provee un extenso conjunto de soluciones predefinidas para
necesidades generales de la programacin de aplicaciones, y administra la
ejecucin de los programas escritos especficamente con la plataforma.
Esta solucin es el producto principal en la oferta de Microsoft, y pretende
ser utilizada por la mayora de las aplicaciones creadas para la plataforma
Windows.

Microsoft desea que todas las aplicaciones creadas para la plataforma

Windows, sean basadas en el .NET Framework. Su objetivo es crear un
marco de desarrollo de software sencillo, reduciendo las vulnerabilidades y
aumentando la seguridad de los programas desarrollados.

3.3.4.4. C#

Es un lenguaje de programacin desarrollado por Microsoft como parte de

la plataforma .Net, orientado a objetos simple, seguro, moderno, de alto
rendimiento y con especial nfasis en internet y sus estndares (como
XML). Es tambin la principal herramienta para programar en la
plataforma .NET.

El lenguaje es muy sencillo, sigue el mismo patrn de los lenguajes de

programacin modernos. Incluye un amplio soporte de estructuras,
componentes, programacin orientada a objetos, manipulacin de errores,
recoleccin de basura, y que es construido sobre los principios de C++ y
Java.

C# es un lenguaje fuertemente tipeado lo cual quiere decir que el

programador debe definir a que tipo pertenece cada pedazo de informacin
o cada objeto que se crea.

5
3.3.5 Los Estndares de Calidad ISO para Desarrollo de Software

Habra que comenzar con una revisin de algunas definiciones acerca de lo que
significa calidad. Deming (1982) propuso la idea de la calidad como conformidad

5 (CATALDI, 200) pag 50.

con requisitos y confiabilidad en el funcionamiento. Juran (1995) dice brevemente:
Quality is fitness for use, o sea es la adecuacin del producto al uso, suponiendo
un producto libre de deficiencias, cuyas caractersticas permiten la satisfaccin del
usuario. Crosby (1979) pone nfasis en la prevencin y dice con defectos cero.
La norma ISO 8402 define la calidad como: Totalidad de caractersticas de un
producto o servicio que le confieren su aptitud para satisfacer unas necesidades
expresadas o implcitas. Estas necesidades especificadas, bien pueden estar en
un contrato o se deben definir explcitamente. El logro de la calidad puede tener
tres orgenes: calidad realizada, calidad programada y calidad necesaria. La
primera es la que es capaz de obtener la persona que realiza el trabajo, la
segunda es la que ha pretendido obtener y la tercera la que exige el cliente y que
le gustara recibir. La gestin de la calidad pretender que estas coincidan.

3.3.5.1 La Calidad en Ingeniera de Software

El software es un producto con caractersticas muy especiales, hay que tener

en cuenta que es un producto que se desarrolla y se centra su diseo, con una
existencia lgica de instrucciones sobre un soporte, siendo un producto que no
se gasta con el uso como otros y repararlo no significa restaurarlo al estado
original, sino corregir algn defecto de origen lo que significa que el producto
entregado posee defectos, que podrn ser solucionados en la etapa de
mantenimiento (Piattini, 1996).

El diccionario IEEE estndar de ingeniera del software (IEEE, 1990) dice que
son software: los programas de ordenador, los procedimientos y, posiblemente
la documentacin asociada y los datos relativos a la operacin del sistema
informtica, no limitndose al cdigo.

El estndar IEEE 6.10 -1990 (IEEE,1990) da la definicin de calidad como el

grado con el que un sistema, componente o proceso cumple con los requisitos
especificados y las necesidades o expectativas del cliente o usuario.

Pressman (1993) la define como concordancia del software con los requisitos
explcitamente establecidos, con los estndares de desarrollo expresamente
fijados y con los requisitos implcitos, no establecidos formalmente que desea
el usuario.

La aplicacin de estndares de desarrollo y de normas para el software

permitir lograr calidad tcnica del mismo. La calidad del software se puede ver
 a nivel empresa como implantacin de un sistema de calidad y a nivel de
proyecto aplicando las tcnicas de evaluacin y control de la calidad del
software a lo largo del ciclo de vida.

El interrogante que surge es: por dnde empezar el proyecto de mejora de la

calidad de los programas en general? Como respuesta a ello, se analizar
brevemente (ms adelante) los aportes de algunas de las instituciones estn
trabajando al respecto y que elaboraron algunos estndares como: IEEE, ISO y
SEI.6

Los requisitos explcitos, ya sean funcionales, de seguridad, de rendimiento, de

interface, son la culminacin de la etapa de anlisis y quedan establecidos en
el documento de especificacin de requisitos del software y es en la etapa de
anlisis donde muchos de los requisitos implcitos no expresados formalmente
por el usuario quedarn declarados en el documento de especificacin.

3.3.5.2 La calidad desde el aspecto organizacional. La familia iso

9000

La familia ISO 9000, es un conjunto de normas en las que se apoya el sistema

de calidad de una empresa. La norma ISO 9000 define al sistema de calidad
desde la perspectiva de la organizacin como: La estructura de organizacin,
de responsabilidades, de actividades, de recursos y de procedimientos que se
establecen para llevar a cabo la gestin de calidad (ISO- 9001: 1994).

6 IEEE. Institute of Electrican and Electronics Engineering. ISO: International Organization for
standarization.
SEI: Software Engineering Institute.
 Terminologa empleada

Desde esta posicin, se debe fijar la estructura organizativa ligada al sistema

de gestin de la calidad a travs de lneas jerrquicas y de comunicacin.

Entre las normas con la que las organizaciones cuentan para el logro del
aseguramiento de la calidad de los productos software, estn las de la familia
ISO 9000. (ISO 9000, 1991). Si bien esta familia en un principio se la dise
para aplicaciones industriales en general, existe una versin la 9000-3,
especfica para productos lgicos. (ISO 9000-3, 1991).

Bajo la denominacin de ISO SPICE (Konrad, Paulk y Graydon, 1995) se

desarrollaron para ISO e IEC7 un conjunto de estndares en un intento de
armonizar los diferentes esfuerzos en el mundo para conducir a la obtencin de
un proceso de software confiable.

Uno de los productos del proyecto es una gua para buenas prcticas de
direccin e ingeniera de software, similar a CMM8 del SEI y al Trillium de
Northern Telecom.

La idea central es crear un modo para medir la capacidad mientras se permite

un aproximacin a la mejora como los niveles de madurez del CMM, siendo

7 IEC: International Electrotechnical Comission.

8 CMM: Capability Madurity Model.

estas aproximaciones para medir la implementacin e institucionalizacin de
procesos especficos.

El estndar IEEE 1074-1991 define el conjunto de actividades requeridas para

llevar a cabo el desarrollo y el mantenimiento de un producto software, cuya
calidad sea confiable. La definicin de los procesos y de las actividades para
cada una de las etapas del ciclo de vida elegido permite obtener un producto
que se ajuste a los requerimientos. Desde esta perspectiva, cada actividad se
la define a partir de una descripcin de la misma y de las respectivas entrada y
salida.

Por otra parte, cuantificar la calidad significa tener que medirla. Para
cuantificarla se requiere de mediciones indirectas de algunas manifestaciones
de la misma, que se denominan mtricas.

El estndar IEEE 1061-1992, establece el propsito de las mtricas para

calidad del software, provee un sistema de mtricas y una provee de una
metodologa para el establecimiento de los requerimientos de calidad. No
prescribe mtricas especficas, pero si ejemplos de aplicacin del mismo.

Existen algunos modelos como el CMM (Capability Madurity Model)

desarrollado por Vctor Basili en el SEI (Software Engineering Institute) de la
Univesidad Carnegie Mellon (CMU), pensado para el Departamento de
Defensa (DoD) de los Estados Unidos, el cual se extendi rpidamente al
mbito empresarial.

Este modelo considera el grado de madurez del producto, teniendo en cuenta

cinco etapas bien diferenciadas. Estas etapas van desde un proceso inmaduro
e improvisado, con falta de rigurosidad metodolgica, hasta llegar a un proceso
totalmente maduro, que evidencia rigurosidad y consistencia en la
administracin de los recursos y adecuacin de los requerimientos con el
proceso.

Quizs la clave consiste en la mejora evolutiva, a partir de establecimiento y

claridad de los puntos de partida y de arribo en cada una de las etapas.

La evolucin a travs de los cinco niveles: inicial, repetible, definido,

administrado y optimizado, permiten establecer los controles requeridos para
gestionar los proyectos: planificar, administrar, controlar, supervisar (nivel 2),
para permitir (en el nivel 3) integrar los aspectos organizacionales con el
proyecto en s. Recin, en el nivel 4, se establece una administracin
cuantitativa del proceso y de la calidad del producto software y el ltimo, define
los aspectos a tener en cuenta para la prevencin de los defectos,
implementacin de mejoras y cambios.

Es un modelo aplicable a organizaciones que desarrollan proyectos, y que

permite luego comparar resultados, pero su aplicacin no garantiza el xito del
proyecto, tornando a la empresa en una estructura ms rgida.

Este modelo de mejora gradual los procesos de software y calidad del

producto, no es el nico y su aplicabilidad depende de las necesidades y
caractersticas de la organizacin. Si bien a travs de estos estndares (ISO
9000-3 y CMM) se intenta obtener una mejora continua, se centran
exclusivamente en los procesos y no en los procesos de pruebas, quedando
fuera de su alcance el plan de pruebas y la seleccin de las mismas, aunque
en la ISO se menciona la documentacin de las pruebas y no el proceso de
prueba especficamente, habra que ver tambin el estndar 820 de la IEEE
(IEEE, 1991).

Bender (1996) sugiere agregar al CMM, una rea clave de proceso (KPA, Key
Process Area), para la prueba y evaluacin del software. Burnstein, et al.
(1996) desarrollan un modelo que denominan TMM (Testing Madurity Model) a
modo de complemento al CMM, como un indicador de la madurez del proceso
de prueba, a fin de implementar las mejoras pertinentes. Se basa en niveles de
madurez y metas para cada uno, con cuestionarios de valoracin de
cumplimiento en cada nivel, como tambin entrenamiento del personal de
prueba y valoracin mediante de cuestionarios y entrevistas.

3.3.5.3 El Concepto de Calidad del Software

Boehm (1978) y McCall (1977) descomponen el concepto de calidad en

propiedades ms sencillas de medir y de evaluar. El modelo de McCall se basa
en la descomposicin del concepto de calidad en tres usos importantes de un
producto de software desde el punto de vista del usuario:

Caractersticas de operacin.

Capacidad para soportar cambios (ser modificado).

 Adaptabilidad a nuevos entornos.

Cada capacidad se descompone en una serie de factores a saber: facilidad de

uso, integridad, fiabilidad, correccin, flexibilidad, facilidad de prueba, facilidad
de mantenimiento, transportabilidad, reusabilidad e interoperabilidad.

Cada factor se descompone en criterios o propiedades internas del software

que determinan su calidad: facilidad de operacin, facilidad de comunicacin,
facilidad de formacin o aprendizaje, control de accesos, facilidad de auditora,
eficiencia de ejecucin, eficiencia de almacenamiento, exactitud o precisin,
consistencia, tolerancia a fallas, modularidad, simplicidad, completitud, facilidad
de traza, auto descripcin, capacidad de expansin, generalidad,
instrumentacin independencia entre sistema y software, independencia del
hardware, compatibilidad de comunicaciones y compatibilidad de datos.

Mc Call define el factor de calidad como FC, segn:

FC = c1 x m1 + c2 x m2 +... + cn x mn

Donde los ci son los coeficientes de regresin y los mi son las mtricas que
afectan al factor de la calidad.

Estos criterios pueden ser evaluados mediante un conjunto de mtricas, las

que se pueden calcular observando directamente el software. Para cada
criterio McCall propuso una serie de mtricas, aunque, muchas de ellas slo
pueden ser medidas en forma subjetiva. Las mtricas pueden estar en forma
de listas de comprobaciones, para obtener el grado de los atributos especficos
del software. McCall propuso un esquema de graduacin mediante una escala
que va de cero (bajo) a 10 (alto) y utiliza como mtricas los criterios o
propiedades internas del software citados anteriormente.

La norma IEEE 1061 propone un modelo de medicin muy parecido al de

McCall y la norma ISO 9126 (ISO, 1991) establece un modelo propio, similar al
de McCall.

En la dcada del ochenta, se comenz a usar modelos particulares de

evaluacin para cada empresa o proyecto, implantndose el concepto de
calidad relativa. Gilb (1988) propone la creacin de una especificacin de
requisitos de calidad a redactar conjuntamente el usuario y los analistas,
determinando as la lista de caractersticas que definan la calidad de cada
aplicacin. Este enfoque se ha asociado a la filosofa QFD (Quality Function
Deployment), o el despliegue de la funcin de la calidad que se aplica al mbito
de la gestin de la calidad industrial y en el que se han basado modelos
posteriores. Otros modelos son los de Basili y Rombach (1988) proponen el
paradigma GQM, (objetivopregunta mtrica o goal-question-metric) para
evaluar la calidad de cada proyecto.

Grady y Caswell (1987) presentan un enfoque de medicin inspirado en el

control estadstico de procesos aplicado a la industria convencional de
fabricacin, considerando a la calidad como la ausencia de defectos, que en
este caso pueden ser fallas, defectos o errores.

3.3.5.4 Mtricas de Calidad del Software

Para la evaluacin de la calidad es ms habitual referirse a medidas del

producto que en medidas del proceso. Una mtrica (Fenton, 1997) es una
asignacin de un valor a un atributo de una entidad de software, ya sea un
producto o un proceso. En todos los casos las mtricas representan medidas
indirectas de la calidad, ya que slo se miden las manifestaciones de ella.

Se pueden tener mtricas basadas en el texto del cdigo y mtricas basadas

en la estructura de control del cdigo.

MTRICAS BASADAS EN EL TEXTO DEL CDIGO: En general, se pueden

tomar la cantidad de lneas de cdigo, como un indicador de tamao, el nmero
de lneas de comentarios como un indicador de la documentacin interna, el
nmero de instrucciones, el porcentaje de lneas de cdigo o densidad de
documentacin, etc. Halstead (1975), propone sus mtricas dentro de este tipo,
denominadas: Ciencia del software".

MTRICAS BASADAS EN LA ESTRUCTURA DE CONTROL DEL CDIGO:

Pueden tomarse dos tipos de medidas: unas relacionadas con el control
intramodular, basada en el grafo de control y otras relacionadas con la
arquitectura en mdulos, basada en el grafo de llamadas o en el diagrama de
estructuras. Las mtricas de McCabe (McCabe, 1976) son del primer tipo y
constituyen un indicador del nmero de caminos independientes linealmente
basndose en conceptos matemticos que existen en un grafo.
 Yin y Winchester (1978) definen el fan-in y el fan-out de cada mdulo. Henry y
Kafura (1984) definen la complejidad del mdulo. Piattini (1996) sostiene que
los resultados parecen indicar que mejores valores de mtricas implican un
menor mantenimiento posterior debido a un menor nmero de defectos.

3.3.5.5 Las Diferentes Aproximaciones

Siguiendo a Fenton (1997), la medicin es un proceso por el cual, se debe

asignar nmeros o smbolos a atributos y entidades en el mundo real, de tal
modo de describirlas de acuerdo a reglas definidas claramente.

Recordando a DeMarco (1982) no se puede controlar lo que no se puede

medir, esto dara un idea acaba de cul es la necesidad primordial de efectuar
mediciones sobre un proceso, en un proyecto. Cada accin de medicin de
algo, debe estar motivada por un objetivo particular o necesidad definida
claramente. Si este razonamiento, se suma al principio de Gilb (1988), citado
por Fenton: los proyectos que no tienen objetivos claros, no arriban a metas
claras", queda explcita la necesidad de una metodologa y la adecuacin de lo
que se deba medir al tipo de software a desarrollar y su uso particular.

Para qu medir? Bien, para ayudarnos e entender qu est sucediendo

durante un desarrollo, analizando los desvos respecto de las lneas de base, o
para controlar lo que est sucediendo en el proyecto o programa respecto de
un lnea de base, o, por ltimo, para mejorar los procesos.

Si bien en los proyectos software empresarial, se miden esfuerzo, costo,

productividad, (COCOMO y COCOMO II), 9 capacidad y madurez, calidad (Mc
Call) confiabilidad, entre otras mtricas, no todos los modelos desarrollados
para este tipo de software, seran adecuados para los proyectos de programas
educativos.

Ya se describi sintticamente el modelo de tres niveles de Mc Call (1977),

llamado comnmente FCM (Factor Criteria Metric). Cada factor de calidad est
compuesto por un criterio, que es lo que realmente se mide, ya que son ms
fciles d entender. En un tercer nivel se describe el grado de pertinencia de las
relaciones entre factores, aclarando que....Dividir para conquistar.

9 (CATALDI, 2000) pag 55

 De acuerdo a Boehm (1978) y a Mc Call (1977) ambos definen atributos
externos: confiabilidad, usabilidad (utilidad) y mantenibilidad y eficiencia y
testeabilidad como internos. Dentro de los internos, tambin estaran la
estructurabilidad y la modularidad y estos se reflejan sobre los externos. A cada
uno se le asignan criterios y mtricas, posteriormente.

La duda que surge es: utilizar un modelo predefinido o definir un modelo

propio?. Ya que los anteriores son tpicos para modelos fijos, esta podra ser
una salida al problema, como sostiene Gilb (1977) o el COQUAMO
(constructive quality modelo) de Kitchenham y Walter (1989).

La ISO 9126 (1991) define calidad en trminos de atributos de inters para el

usuario del, producto de software, algunos internos y otros externos al mismo,
define seis factores y atributos. Se lo puede considerar la piedra angular en la
definicin de un proceso para evaluacin de la calidad del software.

Otros investigadores, miden portabilidad, integridad, densidad de defectos, no

habiendo consenso de qu es el defecto que se mide, por lo cual habra que
definirlo en cada caso.

Llegando al concepto de "utilidad (usability) del software" como la extensin

para la cual, el producto es conveniente y prctico, de un modo intuitivo se la
podra considerar como amigabilidad teniendo en cuenta su practicidad o valor
prctico10.

Fenton dice que se podra definir en trminos de la probabilidad de que un

operador de un sistema no experimente un problema en la interface de usuario
durante un perodo dado de operacin en condiciones normales de operacin o
cmo el usuario ineracta con la interface".

Por ah, sera conveniente remitirse a caractersticas internas ms simples que

conduzcan a una buena utilidad, como:

Por ah, sera conveniente remitirse a caractersticas internas ms simples que

conduzcan a una buena utilidad, como:

Buen uso de men y grficos.

10 Simon & Schusters. International Dictionary. McMillan, USA.

 Mensajes de error e informativos.

Funciones de ayuda.

Consistencia en la interface.

Manuales bien estructurados.

Este podra ser el concepto clave, buscado, especialmente para los programas
educativos y en l se har hincapi.

3.3.5.5 La Verificacin y la Validacin del Software

Otro aspectos a tener en cuenta, son las revisiones y las pruebas del software
como parte de del ciclo de vida, que se utilizan para detectar fallas en los
requisitos, en el diseo y en la implantacin y son procesos orientados a la
deteccin de defectos en el producto, dndole mucha importancia a las
revisiones

La verificacin y la validacin del software (VyV) incluyen un conjunto de

procedimientos, actividades, tcnicas y herramientas que se utilizan
paralelamente al desarrollo del software, para asegurar que el producto
resuelve correctamente el problema para el que fuera diseado. El objetivo es
prevenir las fallas desde los requerimientos hasta su implementacin.

La VyV acta sobre los productos intermedios intentando detectar y corregir

cuanto antes sus defectos y desviaciones del objetivo primigenio, si las
hubiera.

Respecto de las pruebas a realizar en el software, ellas pueden ser dinmicas

o estticas, de acuerdo a si se realizan o no sobre el cdigo. Entre las pruebas
dinmicas, estn las llamadas de caja blanca y las de caja negra, "testeando"
los procedimientos estructurales o las salidas. Y entre las estticas estn las
revisiones, las verificaciones, a fin de detectar problemas durante el proceso de
desarrollo.
3.3.5.6. Las Revisiones del Software

El estndar IEEE (1989), indica que para conseguir los objetivos de

aseguramiento de la calidad se disponen de los siguientes mtodos como se
puede ver en la tabla

Las revisiones y auditoras se pueden utilizar para revisar procedimientos de

gestin y productos. Un tipo de revisiones a considerar son las revisiones
tcnicas, cuyo objetivo es evaluar un producto intermedio de desarrollo para
comprobar que el producto se ajuste a las especificaciones y que se est
llevando a cabo de acuerdo a los planes y estndares.

Las inspecciones tienen por objetivo detectar y registrar los defectos del
producto intermedio, en forma rigurosa y formal, buscando que el producto
satisfaga las especificaciones y estndares. Estn pensadas como una medida
de ayuda al gestor.

Los walkthroughs se realizan para evaluar un producto en busca de defectos u

omisiones, como una medida de ayuda al desarrollador, considerando las
posibles alternativas de solucin cuyo objetivo es comprender bien el objeto.

Los mtodos citados anteriormente constituye el anlisis esttico ya que no se

necesita ejecutar el software: Una mencin especial dentro de los anlisis
dinmicos del software corresponde a las pueblas modulares y de integracin,
segn se detalla en el estndar IEEE-1012 (1986) y las pruebas pueden ser
funcionales o estructurales.

Las auditoras se realizan para determinar en forma objetiva que los productos
desarrollados se ajustan a los estndares. En el estndar IEEE (1984), se
recomienda realizar una cantidad determinada de revisiones y auditoras sobre
todo en software crtico.
 3.3.5.7. Metodologia de Desarrollo Agil Programacion Extrema(Xp) 11
XP (eXtreme Programino) nace como nueva disciplina de desarrollo de software
hace aproximadamente unos seis aos, y ha causado un gran revuelo entre el
colectivo de programadores del mundo. Kent beck, su autor, es un programador
que ha trabajado en mltiples empresas y que actualmente lo hace como
programador en la conocida empresa automovilstica DaimlerChrytel. Con sus
teoras ha conseguido el respaldo de gran parte de la industria del software y el
rechazo de otra parte. La programacin extrema se basa en la simplicidad, la
comunicacin y el reciclado continuo de cdigo, para algunos no es ms que
aplicar pura lgica.

La filosofa XP es satisfacer al completo las necesidades del cliente, por eso lo

integra como una parte ms del equipo de desarrollo.

XP fue inicialmente creada para el desarrollo de aplicaciones donde el cliente no

sabe muy bien lo que quiere, lo que provoca un cambio constante e los requisitos
que debe cumplir la aplicacin. Por este motivo es necesario una metodologa gil
como XP que se adapta a las necesidades del cliente y donde la aplicacin se va
revaluando en periodos de tiempo cortos.

En un proyecto usando programacin extrema se siguen ms o menos los

siguientes pasos:

El cliente junto al equipo de desarrollo definen que es lo que se quiere hacer. Para
ello utilizan las historias de usuario. Se evala para cada historia de usuario el
tiempo que puede llevar, que debe ser corto, de aproximadamente una semana.
Un programador puede estimar con cierta fiabilidad un trabajo que le lleve unos
das ms pero a estimacin es menos fiable si es de un plazo superior a una

11 (DAVID, 2007) PAG 18.

semana. Si es ms largo, hay que partir la historia en otras ms pequeas. Luego
se ordenan en el orden en que se van a desarrollar y se establecen las mini-
versiones, de forma que cada mini-versin implementa varias de las historias de
usuario.

Toda esta planificacin va a ser, por supuesto, inexacta. No se puede saber todo lo
que va a ser necesario ni evaluar los tiempos correctamente. La planificacin
deber revisarse y modificarse continuamente a lo largo de proyecto. Las historias
de usuario se modificaran, se quitaran o se aadirn nuevas sobre la marcha.
Puesto que el cliente estar presente da a da durante todo el proyecto, vera e
efecto y el esfuerzo necesario para las modificaciones pedidas y sabr evaluar si
merecen o no la pena.

Para las primeras historias que se van a implementar, se define una prueba para
ver si la versin cumple perfectamente con la historia. Estas pruebas deben ser
automticas, de forma que haya un programa de pruebas que ejecutemos y nos
diga si la mini-versin es o no correcta.

Los programadores se ponen por parejas (dos personas en el mismo ordenador)

para codificar esas historias. Primero codifican el programa de pruebas y ven que
falla.

Las parejas de programadores se intercambian con frecuencia, de forma que

todos acaban trabajando con todos. El trabajo por parejas haciendo intercambios
tienen la siguiente ventaja: cuatro ojos ven ms que dos. Al trabajar de dos en dos,
el cdigo ser de mayor calidad desde el mismo momento de crearlo y tendr
menos fallos.

Los programadores novatos aprendern de os expertos al emparejarse con ellos.

Si una pareja realiza un trozo de cdigo susceptible de ser reutilizado en el

proyecto, hay dos programadores que los aben y que lo reutilizan cuando puedan,
ensendole a sus nuevos compaeros. De esta manera el conocimiento de
cdigo ya hecho se propaga de forma natural entre todos los programadores.

El estilo de programacin tiende a unificarse.

Cuando una nueva pareja va a realizar un nuevo cdigo para una historia de
usuario, puede que uno de ellos recuerde haber hecho un trozo de cdigo en otro
lado y lo reutilizara, modificndolo si es necesario. Despus de modificarlo, deben
asegurarse que se siguen pasando las pruebas automticas que se hicieron en su
 momento, as como aadir nuevas pruebas para comprobar las modificaciones que
han hecho.

Si una pareja al reutilizar cdigo ya hecho ve que es mejorable, lo mejorar,

pasando las pruebas automticas despus. Si al reutilizar el cdigo ya hecho
descubren un error que las pruebas automticas no detectan, aaden pruebas
capaces de detectar el error y lo corrigen.

El cdigo por tanto no es de nadie. Cualquier pareja puede tocar el cdigo ya

hecho por otras personas si lo necesita, con la condicin de que despus de
tocarlo las pruebas automticas sigan pasndose correctamente y que aadan sus
propias pruebas automticas para las correcciones realizadas.

Todos los das se hace una pequea reunin a primera hora de la maana con el
todo el equipo en que se comentan problemas cdigo que se est realizando,
historias de usuarios terminadas, etc

Cada vez que se consigue codificar y que funcione una historia de usuario, se le
da al cliente para que la vea, lo pruebe y aada las posibles modificaciones para
las siguientes mini- versione. Cuando se realiza un mini-versin completa, incluso
se entrega al usuario final ara que empiece a trabajar con ella y reportar
incidencias o mejoras.

Este ciclo se va repitiendo una y otra vez hasta que el cliente se d por satisfecho
y cierre el proyecto. Como se ve, no se ha hecho documentacin. En algn sitio he
ledo que incluso la planificacin inicial debe hacerse escribiendo cada historia de
usuario en una tarjeta, haciendo dos montones, las que ya estn hechas y las que
ya hay. El nmero de tarjetas en cada montn nos da una idea exacta de cuanto
hay hecho del proyecto.

4. CONCLUSIONES:

Se logr desarrollar el modelo terico en Microsoft Visio 2010 indicando las entidades
que estn dentro y fuera del objeto de estudio as mismo de describe cada una de
ellas y sus las relaciones que tienen con el sistema.
5. RECOMENDACIONES

Para un buen desarrollo del modelo terico se tiene que definir correctamente el
planteamiento del problema, porque de ah se identifican las entidades que tiene
relacin con el sistema, su entorno, etc.

5. BIBLIOGRAFIA

CATALDI, Z. (2000). UNA METODOLOGA PARA EL DISEO, DESARROLLO

Y EVALUACIN DE SOFTWARE EDUCATIVO. ciudad de la plata.

DAVID, G. D. (2007). DESARROLLO DE N SOFTWARE DE CONTROL DE

ASISTENCIA DE PERSONAL PARA EL AREA DE PERSONAL DEL
HOSPITAL I ESSALUD TINGO MARIA. TINGO MARIA - PERU.

DONOSO, E. A. (2013). DESARROLLO E IMPLEMENTACIN DE UN

SISTEMA DE CONTROL DE ASISTENCIA PARA LOS ESTABLECIMIENTOS
EDUCATIVOS DE LA ZONA ESCOLAR No. 2 DE LA UTE No. 1 DEL CANTN
AMBATO DE LA PROVINCIA DE TUNGURAHUA. Ambato - Ecuador.

MYRIAM NATALY ULLOA ROMERO, M. C. (2011). SISTEMA INFORMTICO

PARA EL CONTROL DE ASISTENCIA DEL PERSONAL DOCENTE DEL
CENTRO DE EDUCACIN BSICA DR. NSTOR MOGOLLN LPEZ.
GRANMA, CUBA.