Análisis y Diseño de Sistemas Orientado a Objetos

Diagrama de Clases y Diagrama de Objetos

mar.jorie1991@hotmail.com (Marjorie ) — Mon, 13 Aug 2012 21:03:00 +0000

El diagrama de clases es utilizado para modelar la vista diseño estática del sistema, es la base para el diagrama de componentes y despliegue, consta de clases, interfaces y relaciones.

Una clase es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

Nombre de una clase: una clase debe tener un nombre que la distingue de las otras, un nombre calificado consta del nombre de la clase precedido dl nombre del paquete en el que se encuentra.

Normalmente se pone en mayúscula la primera letra de cada palabra como en Credito o SensorDeTemperatura

Atributos: es una propiedad de una clase identificada, que describe un rango de valores que pueden tomar las instancias de la propiedad. Un atributo representa una propiedad del elemento que se está modelando que es compartida por todos los objetos de esa clase.

El nombre de un atributo se pone en mayúscula la primera letra de cada palabra excepto la primera letra, como en numeroTdCredito

Operación: Una operación es la implementación de un servicio, que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento.

El nombre tiene la misma estructura que el de los atributos.

Técnicas de modelado

Las clases se utilizan para modelar abstracciones extraídas dl problema a resolver, cada abstracción es la parte del vocabulario del sistema, es decir que representan elementos importantes para el sistema.

RELACIONES

Una relación es una conexión entre elementos. Las tres relaciones más importantes son las de Dependencias, generalizaciones y asociaciones. Gráficamente se representan con diferentes tipos d líneas.

Dependencia: una dependencia es una relación que indica que un elemento utiliza la información y los servicios de otro elemento, pero no necesariamente a la inversa

Generalización: es una relación entre un elemento general llamado padre o superclase y otro elemento más específico llamado hijo o subclase que hereda propiedades y operaciones de la superclase.

Un objeto de la clase hija puede asociar una variable o un parámetro cuyo tipo venga dado por el padre, pero no a la inversa.

Cuando una clase hijo implementa una misma operación de la clase padre (con el mismo nombre y atributos) se denomina Polimorfismo.

Asociación: s una relación estructural que especifica que los objetos de un elemento están conectados a los objetos de otro elemento.

Multiplicidad: Representan cuantos objetos pueden conectarse a través de una asociación. Puede existir multiplicidad uno (1), cero o uno (0..1), muchos (0..*) uno o más (1..*)

Agregación: es una relación todo/parte en la cual una clase representa un todo que consta de elementos más pequeños.

Características avanzadas de las clases

Visibilidad: Indica si los atributos y operaciones pueden ser usados por otros clasificadores

Public (+) Indica que cualquier clase extrna con visibilidad a la clase puede utilizar la caractristica.

Protected (#) Indica que cualquier decendiente de la clase pued utilizar la caracteristica.

Private (-) indica que solo el propio clasificador puede utilizar la caracteristica.

Package (~) indica que solo los clasificadores declarados en el mismo paquete pueden utilizar la caacteristica.

Ejemplo de un Diagrama de clases del Glottone S.A

Relación Entre Paquetes

Se ha utilizado paquetes para organizar las clases que intervienen, la utilización de paquetes es opcional (se puede o no utilizar) podemos observar los nombres calificados de cada una de las clases y la relación entre paquetes.

Nota: en la figura se muestran los atributos y operaciones más importantes de cada clase.

A continuación se detalla la relación entre las clases de un mismo paquete.

Diagrama de clases de paquete Registro

Existe una relación de asociación

Podemos definir los atributos y operaciones en una hoja de clase de la siguiente manera:

Clase: Producto

Atributos:

codProducto

nombreProducto

precioProducto

descripciónProducto

unidadMedida

imagen

videoEnlace

stock

Operaciones

Registrar Nuevo Producto

ingresarProducto(codProducto, nombreProducto, precioProducto , descripciónProducto ,unidadMedida,umagen, videoEnlace,stock)

Actualizar Producto

modificarProducto(codProducto, nombreProducto, precioProducto , descripciónProducto ,unidadMedida,umagen, videoEnlace,stock)

Eliminar Producto

eliminarProducto(codProducto)

Diagrama de clases de paquete Negocio

Existe una relación de dependencia, entre las clases.

Diagrama de Objetos

Este diagrama muestra un conjunto de objetos y sus relaciones, son iguales que los diagramas de clase pero con casos reales o prototipos, ejemplo

Conceptos Básicos para Modelar

mar.jorie1991@hotmail.com (Marjorie ) — Mon, 13 Aug 2012 03:44:00 +0000

Antes de dar paso a la realización de nuevos diagramas indispensables para el análisis y diseño de sistemas, considero necesario detallar los conceptos importantes para poder desarrollar diseños de software.

Los diseños que se presentaran estarán realizados en el Lenguaje UML.

UML es un lenguaje para Visualizar, Especificar, Construir y Documentar los artefactos de un sistema con gran cantidad de software. Es un lenguaje de modelado que se centra en la representación conceptual y física de un sistema.

Visualizar: un modelo explicito facilita la comunicación.

Especificar: Significa construir modelos precisos y completos, permite especificar todas las decisiones del análisis

Construir: UML permite realizar la ingeniería directa e inversa, es decir que es posible establecer correspondencias desde un modelo UML a código de programación y viceversa.

Documentar: UML cubre la documentación de la arquitectura del sistema y todos sus detalles.

Modelo conceptual de UML

Ø Elementos Estructurales: Son los nombres de los modelos, partes estáticas, estos se denominan clasificadores:

Clase: es un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

Una interfaz muestra el comportamiento completo o parcial de una clase.

Colaboración: proporciona un comportamiento cooperativo mayor a la suma de comportamiento de sus elementos.

Caso de uso: descripción de un conjunto de secuencias de acciones que ejecuta un sistema.

Clase activa: sus objetos tienen uno o ms procesos o hilos de ejecución

Componente: es una parte reemplazable de un sistema que conforma y proporciona la implementación de un conjunto de interfaces (clases, librerías).

Artefacto: Es una parte física y reemplazable de un sistema que contiene información física (bits) hay tipos de artefactos como: código fuente, ejecutables y scripts.

Nodo: Es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que, generalmente, tiene alguna memoria y, a menudo capacidad de procesamiento.

Ø Elementos de comportamiento: Son las partes dinámicas de los modelos UML

Interacción: Es una conexión entre objetos, comprende mensajes intercambiados entre un conjunto de objetos

Máquinas de estado: es un comportamiento que especifica las secuencias de estados por las que pasa u objeto o interacción durante su vida en respuesta a eventos.

Actividad: Comportamiento que especifica una secuencia de pasos que ejecuta el proceso computacional. Una actividad es una acción.

Ø Elementos de agrupación: Son las partes organizativas de los modelos.

Paquete: sirve para organizar el propio diseño, en él se pueden incluir los elementos estructurales, comportamiento e incluso otros elementos de agrupación.

Ø Elementos de anotación: son las partes explicativas del modelo

Nota: Es un símbolo para mostrar restricciones y comentarios junto a un elemento o colección de elementos

Las relaciones y diagramas lo veremos en las siguientes publicaciones.

¿Qué se entiende por arquitectura de un sistema?

Un sistema con gran cantidad de software requiere ser visto desde diferentes perspectivas (usuarios). La arquitectura permite manejar los diferentes puntos de vistas y controlar el desarrollo del sistema.

Se describe con 5 vistas interrelacionadas

Vista de casos de uso: Describen el comportamiento del sistema tal y como es percibido por usuarios finales, analistas y encargados de pruebas.

Vista de diseño: Comprende clases, interfaces y colaboraciones, forman el vocabulario y solución.

Vista de interacción: Muestra el flujo de control de diversas partes, incluyendo mecanismos de concurrencia y sincronización.

Vistas de Implementación: Comprende artefactos utilizados para ensamblar y poner en producción el sistema físico.

Vista de despliegue: Contiene los nodos que forman la topología del hardware sobre la que se ejecuta el sistema.

¿Qué son los diagramas?

Un diagrama es la representación gráfica de un conjunto de elementos, los cuales se crean para visualizar un sistema desde diferentes perspectivas, representa una vista resumida.

Existen diagramas que permiten representar la parte estática de un sistema y otros que representan la parte dinámica.

DIAGRAMAS ESTÁTICOS	DIAGRAMAS DINÁMICOS
Ø Diagramas de clases Ø Diagramas de componentes Ø Diagramas de estructura compuesta Ø Diagramas de objetos Ø Diagramas de despliegue Ø Diagramas de artefactos	Ø Diagramas de Casos de uso Ø Diagramas de secuencia Ø Diagramas de comunicación Ø Diagramas de estados Ø Diagramas de actividades

MODELO CONCEPTUAL

mar.jorie1991@hotmail.com (Marjorie ) — Sun, 12 Aug 2012 01:36:00 +0000

Al realizar un estudio o análisis para construir un sistema de software, una parte primordial, constituye la construcción de un modelo conceptual del problema como también de la solución.

El modelo conceptual del problema ayuda a conocer el estado actual del lugar en el cual vamos a implementar el sistema e identificar el problema o las necesidades para proporcionar una solución que guiará la correcta construcción del software. Sirve para conocer el dominio del problema.

El modelo conceptual de la solución se realiza cuando se ha logrado comprender que es lo que se requiere implementar, es una solución al problema presentado.

A continuación se presenta un ejemplo de Modelo conceptual del problema de Glottone S.A

Como se puede observar la estrategia para realizar un modelo conceptual consiste en extraer los conceptos principales (palabras claves) del enunciado.

Ejemplo de Diagrama de Casos de Uso y Casos de Usos Expandidos

mar.jorie1991@hotmail.com (Marjorie ) — Sun, 12 Aug 2012 01:31:00 +0000

Con la finalidad de que la información publicada acerca de los Casos de uso , se comprenda mejor, a continuación proporciono un ejemplo sencillo dictado en clases, éste consta del diagrama de casos de uso y caso de uso expandido.

GLOTTONE S.A

GLOTTONE S.A es una cadena de comisariato tipo Gourmet. Su selecta clientela (de la alta sociedad), no le gusta hacer grandes columnas. El dueño de la cadena Mr. Tak-nhonni considera utilizar altas tecnologías para agilizar el proceso de facturación. La alta sociedad no usa dinero. Mr. Tak-nhonni desea utilizar geoposicionamiento, realidad aumentada y códigos Qr para cumplir con su objetivo.

Diagrama de Casos de Uso

En este diagrama, podemos observar una relación de tipo <<include>> entre el caso de uso ”Vender Productos ” y “Facturar Productos ” lo cual representa un llamado obligatorio a “Facturar Productos”

Nota: Pueden existir casos de uso con relación de tipo Extend lo cual indica que un caso de uso puede llamar a otro solo en ciertas circunstancias, pero no en todas.

A continuación se presenta el desarrollo de caso de uso extendido para “Vender Productos”

Caso de Uso Expandido

Caso de uso:	Vender Productos
Actores:	Cliente
Propósito:	Registrar una nueva venta de productos.
Resumen:	El Cliente al capturar la imagen del código Qr de un producto, puede visualizar toda la información del mismo y elegirlo para su compra.
Tipo:	Primario
Pre condiciones:	Deben estar ingresados los productos y los clientes
Curso Normal de Eventos
Acción del Autor	Respuestas del Sistema
1. Este caso de uso empieza cuando el cliente captura el código del producto, el cual lo direcciona al formulario de ventas. 3. Escoge la opción Agregar para comprar el producto. 4. Si no desea seguir agregando productos, escoge la opción Facturar	2. Muestra toda la información del producto. 5 .Genera el formulario facturar
Línea 4. Ver Sección Facturar Productos
Sección Facturar Productos
Acción del Autor	Respuestas del Sistema
2. El cliente verifica que la información generada para la transacción esté correcta 3. Acepta la facturación	1. Carga los datos de la venta y determina el IVA, descuento y precio total. 4. Registra la nueva factura.
Flujo Alterno
Línea 3: Si no desea comprar producto, escoger cancelar.

Datos Relacionados:

Casos de usos Relacionados:

Registrar cliente

Registrar Productos

Diseño de Formulario:

Operaciones y Validaciones:

Operaciones:

Calcular IVA

Calcular descuento

Calcular precio total

Experiencia al realizar trabajo acerca del sistema para la cadena de comisariatos

mar.jorie1991@hotmail.com (Marjorie ) — Fri, 29 Jun 2012 20:44:00 +0000

GLOTTONE S.A

Al empezar a leer el enunciado, lo primero que me llamó la atención fueron las tecnologías mencionadas, códigos QR, del cual imaginé que era algún tipo de código de programación, en cuanto a la realidad aumentada, no había escuchado éste término y al principio pensé que se trataba de algo similar a la inteligencia artificial.

Una vez leido varias veces el problema, empecé a investigar sobre los códigos qr, y me fijé que sí había visto las imágenes en varias ocaciones, pero no sabía que eran códigos QR, fue en ese momento que organicé un poco mis ideas, pues ya cuando conocí que se trataba de códigos que permiten almacenar información que puede ir desde una simple descripción hasta contener una dirección a una página web, videos y fotos, pudiendo imprimirlos en stikers y puestos en productos, hacer publicidad etc. Pero lo que más me llamó la atención, apartándose un poco del tema, fue que en paises como Japón ademas de usarlos para hacer publicidad y vender productos, también los ponen en lápidas para guardar hasta poemas.

Lo siguiente a descubrir fue ¿Cómo pueden ser leídos este tipo de códigos? Algo que ni me imaginaba…. Con teléfonos inteligentes ¿teléfonos inteligentes? Sí, son un tipo de teléfonos que tienen incluidos un lector interno de códigos qr , llamados smartphone y con una simple foto que se capture del código qr, mediante un enlace a internet se puede acceder a la información contenida.

Una vez, entendida la primera parte, empecé con la realidad aumentada, y descubrí que es una tecnología que combina elementos reales y virtuales, entonces la relación que hice fue “la implementación de un código qr con información como videos y fotos combina una realidad (productos con códigos) con información virtual”, y seguí investigando más y era cierta la relación que había establecido, además que descubrí que existen más usos como es el caso de que en una imagen real se puede superponer datos virtuales, para una mejor ubicación correspondiente al sitio de la imagen, lo cual me llevo a relacionar el problema con respecto a las tecnologias anteriores y el geoposicionamiento.

Mientras más investigaba, más cosas nuevas encontraba, muchas de las cuales no tenían relación con el problema (como en el caso de las lápidas, o la existencia de tiendas de ropa con realidad aumentada, que permiten medirse prendas vía web) , pero sin embargo, me permitieron aclarar más las ideas de “hasta donde puede llegar la realidad aumentada”, y el “hasta donde” se volvió infinito ya que ésta se aplica en muchos campos, hasta en la medicina.

Una vez claro el funcionamiento de estas tecnologías, y varias ideas acerca del paradigma de la refrigeradora , empece a analizar las necesidades requeridas (clientes de alta sociedad que no usan dinero, nadie se detiene a pagar ni empaquetar), y empecé a desarrollar un proceso que cumpla con las necesidades usando dichas tecnologías, lo cual quedó de manera resumida de la siguiente forma:

El cliente se acerca al comisariato, si algo le gusta solo captura una foto del código con los dispositivos smartphone, observa la información del producto y si desea la compra virtulmente mediante el portal web, cuando termina la selección de productos, si desea paga con tarjeta de crédito o se le descuenta al banco, se retira, y en el sistema queda la compra para procesarla, empacarla y entregarla a domicilio utilizando geoposicionamiento.

CASOS DE USO

mar.jorie1991@hotmail.com (Marjorie ) — Tue, 19 Jun 2012 23:00:00 +0000

Frederick P. Brooks [Brooks87], dice: “La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas, y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal. Ninguna es tan difícil de corregir mas adelante... Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto”

Los casos de uso son un método que, ayudan al Ingeniero de Software a llevar adelante esta parte del desarrollo de un sistema de software.

¿Qué es un caso de uso?

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Es una narración descriptiva de un proceso.

Elementos fundamentales de casos de uso

Actores

Un actor es una agrupación de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo. Por ejemplo, para una empresa que recibe pedidos en forma telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, son considerados un único actor: Empleado de Ventas.

Los casos de uso tienen las siguientes características:

1) Están expresados desde el punto de vista del actor.

2) Se documentan con texto informal.

3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción.

4) Son iniciados por un único actor.

Formatos

Para realizar los casos de usos existen dos formatos

Formato de alto nivel

ü Se enfoca más al propósito del caso de uso.

ü Ignoramos detalles sobre la forma de la interacción entre el actor y el sistema.

ü Sólo incluimos las alternativas más relevantes

Partes básicas

ü El nombre de un caso de uso se expresa con un verbo en infinitivo.

ü Los casos de uso se representan gráficamente con óvalos con el nombre del caso en su interior,

Formato Expandido

Este tipo de formato ademas de las partes básicas del formato de alto nivel tambien incluye detalles de la implementación.

Esta enfocado interacción del actor con el sistema.

Su implementación puede ser :

Real :factibilidad técnica alcanzable, seguridad de implementación con respecto a los recursos tecnicos ya existentes, o

Esencial: factibilidad técnica en estudio, en duda

Este formato incluye tipos según la prioridad

Primaria: Comprende la esencia del sistema, los casos que agregan valor al negocio, lo que beneficia.

Secundaria: casos que no agregan valor al negocio, pero que son el soporte de los primarios y cuya ejecución sólo es necesaria para que el sistema funcione

normalmente.

Opcional: Son aquellos que sirven solo para darle mejoras al sistema, pero si no estan implementados no afecta en nada al sistema.

Tmbien incluye flujos de eventos los cuales solo se inician si las pre-condiciones (lo que tiene que estar para que se efectue el caso de uso) son completadas.

Estos contienen una ruta Normal o Alterna.

Flujos de Eventos Normales

En general, se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema.

Tienen una vía normal, sin inconvenientes, presentan condiciones favorables que permite concluir en caso de uso.

Flujos de Eventos Alternos

Durante la ejecución de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo, mientras se ingresa un pedido, el cliente puede solicitar un producto que está discontinuado. El sistema deberá en este caso informar esta situación al empleado que ingresa el pedido. Esas desviaciones del curso normal del caso de uso se llaman eventos alternativos

Estos eventos son condiciones no favorables que pueden abortar el caso de uso y no concluirlo o coger otra alternativa y llegar al fin del caso.

Dentro del formato expandido se incluye información adicional

Datos relacionados: Tiene que ver con la información necesaria para efectuar el caso de uso. Informacíon que se encuentra en base de datos, por ello en este punto es necesario mostrar las tablas que participan en el caso de uso.

Casos de Usos relacionados: Se refiere a que un caso de uso o funcionalidad del sitema sea accedida a partir de varios casos de uso, Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto.

Es decir que un caso de uso llama a otro para realizarse completamente.

Diseño de formulario: son aquellos en que se detalla la información de los casos de uso.

Descripción de Operaciones y validaciones

Corresponde a todas las validaciones de datos existente, como fecha, cédula. Descripción de funciones numericas que se realizan en los casos de uso

Planeación del Proyecto Integrador (Versión 2)

mar.jorie1991@hotmail.com (Marjorie ) — Thu, 14 Jun 2012 19:48:00 +0000

Universidad Técnica Estatal de Quevedo

Facultad de Ciencias de la Ingeniería

Escuela de Informática

Carrera Ingeniería en Sistemas

Marjorie Zorrilla Castillo

Tema: Sistema de Evaluación de la Gestión Academica Universitaria utilzando indicadores del (CEAACES)

AMBITO DEL PROYECTO (NECESIDADES)

El sistema de evaluación de la gestión universitaria tiene como principio guía colocar al estudiante como protagonista y al aprendizaje como el objetivo principal, se trata de valorar lo que el estudiante aprende efectivamente

El CEAACES presenta los elementos centrales del Modelo de Evaluación.

Los dos grandes componentes a evaluarse:

1. Entorno de Aprendizaje

2. Resultados de Aprendizaje.

La necesidad radica en poder evaluar la gestión académica, la misma que está comprendida en el entorno de aprendizaje donde se encuentran los árboles de criterios, sub-criterios e indicadores.

El árbol del entorno de aprendizaje es el siguiente:

El sistema de evaluación universitaria a desarrollar, conforme a los indicadores del CEAACES requiere evaluar solo la Gestión Académica, que comprende la Calidad Docente y la Carrera Docente de acuerdo a objetivos educacionales, lo que implica que el profesional debe demostrar una competencia general y una variedad de capacidades que le permitan desenvolverse ética y satisfactoriamente en un entorno cada vez más competitivo y cuyo alcance no solo comprende el ámbito local sino el global. Esta evaluación también implica que la Institucion de Educacion Superior tenga un alto nivel academico teniendo elementos capaces y competentes, que la carga horaria sea muy bien distribuida, etc

Dentro de éstos dos subcriterios se necesita evaluar los siguientes indicadores:

Calidad Docente

Carrera Docente

INFORMACIÓN DE INDICADORES: CRITERIO ACADEMIA

CRITERIOS		INDICADORES	EVIDENCIAS NECESARIAS	CALCULO DEL INDICADOR Y ESCALA
CALIDAD DOCENTE		Denominación (Descriptor)	EVIDENCIAS NECESARIAS	CALCULO DEL INDICADOR Y ESCALA
	DEDICACIÓN	Carga Horaria TC Número promedio de horas semanales de clase dictadas por profesor a tiempo completo. Se considera un docente a tiempo completo aquel que tiene una relación laboral de 40 horas semanales con la IES, y tiene al menos 10 horas de docencia a la semana, a excepción de autoridades de la IES	Informe sobre el número promedio de horas semanales de clase de los Docentes a TC.	Carga horaria TC = Suma de los promedios de horas de clase a la semana dictada por un profesor a tiempo completo en el periodo t / Número total de profesores a tiempo completo, en el periodo t Se considera como niveles satisfactorio de 10 a 14 horas de clase por semana. la valoración decrece rápidamente hasta el nivel de 18 horas por semana, de allí en adelante la valoración es nula.
		Carga Horaria TP Número promedio de horas semanales de clase dictadas por los docentes remunerados por horas. El CEAACES considera que los profesores a tiempo parcial deben ser, en lo posible, profesionales que se encuentran ejerciendo efectivamente su profesión y, por lo tanto, aportan a la formación de los estudiantes con sus conocimientos prácticos.	Informe sobre el número promedio de horas semanales de clases de los docentes a tiempo parcial.	Carga horaria TP = Suma de los promedios de horas de clase a la semana dictada por un profesor a tiempo parcial en el periodo t / Número total de profesores a tiempo parcial en el periodo t Un rango de 2 a 6 horas promedio de clase por semana se considera un nivel aceptable de carga horaria para docentes a tiempo parcial. Una carga horaria superior a 15 horas semanales se considera inadmisible.
		Disponibilidad Evalúa la relación entre el número de estudiantes de la IES y el número de docentes a tiempo completo. Este indicador mide la disponibilidad de tiempo de los profesores de la IES para dedicarlo a actividades de consultas o tutorías en beneficio de sus estudiantes.	Calculo de la relación entre el número de horas empleadas en actividades académicas (no dedicadas clases) y el número de horas de dictado de clases del cuerpo docente.	Disponibilidad = (Número de estudiantes de la IES, en el período t) / (Número total de profesores a tiempo completo de la IES en el período t) Se considera máximo 12 estudiantes por docente a tiempo completo como un nivel óptimo. Se asume que la contribución del indicador a la calidad de la docencia para valores superiores a 45 estudiantes `por docente a tiempo completo es nula.
		Docentes TC Evalúa el número de profesores de la IES a tiempo completo, en relación con el total de docentes. Se asume que la calidad de la enseñanza es mejor cuanto mayor sea el porcentaje de docentes a tiempo completo.	Informe sobre el porcentaje de profesores a Tiempo Completo.	Docentes TC = 100*(Número de docentes a tiempo completo de la IES en el período t) / (Número total de docentes de la IES en el período t) El indicador es satisfactorio cuando el 50% de la planta docente de la IES son profesores a tiempo completo.
	FORMACIÓN	*Docentes MS* Evalúa el porcentaje de profesores de la IES que cuentan con título de maestría.	Porcentaje de Docentes cuyo grado más alto es Magister, en relación con el total de Docentes con Posgrado.	Porcentaje de docentes cuyo diploma más alto es "Magister" Docentes MS = 100*(Número total de docentes de la IES que tienen título de maestría, en un período de tiempo t ) / (Número total de docentes de la IES, en un período de tiempo t ) El nivel de satisfacción es satisfactorio cuando el 60% de los docentes de la IES tienen título de maestría.
	FORMACIÓN	Docentes PHD Evalúa el porcentaje de docentes de la IES que cuentan con título de doctorado, PhD.	Porcentaje de Docentes cuyo grado más alto es Doctor (PhD), en relación con el total de Docentes con posgrado.	Porcentaje de docentes cuyo diploma más alto es "Doctorado" Docentes PhD = 100*(Número de docentes de la IES que cuentan con título de doctor (PhD) en el período t ) / (Número total de docentes de la IES en el período t ) El indicador es satisfactorio cuando el 5% de los docentes de la IES tienen título de doctor, PhD.
	PERTINENCIA	Cobertura carreras Evalúa la suficiencia de docentes a tiempo completo, en relación con el número de carreras o menciones que ofrece la IES.	Informe sobre el número de carreras en el periodo lectivo t.	Cobertura Carreras = (Número de profesores a TC , en un periodo de tiempo t ) / (Número de carreras o menciones en el periodo de tiempo t ) Un índice de cobertura de 5 docentes por carrera o mención se considera como satisfactorio.
	PERTINENCIA	Especialización Porcentaje de docentes con título de maestría o PhD que ejercen la cátedra en el área de conocimiento de su postgrado.	Porcentaje de Docentes cuyo grado más alto es Doctor (PhD), en relación con el total de Docentes con posgrado, que ejercen la cátedra en el área de conocimiento.	Especialización = 100*(Número total de profesores con títulos de maestría o PhD que dictan clases (al menos el 60% de su tiempo de docencia) en el área de conocimiento de su postgrado, en un periodo de tiempo t) / (Número total de profesores de la IES con título de maestría o PhD, en un período de tiempo t)
CARRERA DOCENTE	CONTRATACION	Escalafón Porcentaje de docentes amparados bajo el reglamento de escalafón o normas de carrera docente de la IES.	Informe documentado sobre la forma de aplicación del reglamento de escalafón docente.	Escalafón = 100(Número total de profesores amparados por un reglamento de escalafón y carrera docente en el período t ) / (Número total de profesores de la IES en el período t )* Este llega a su máximo valor cuando el 80% de docentes están amparados por un reglamento de escalafón docente.
	CONTRATACION	Selección Porcentaje de docentes que han ingresado o han sido contratados por la IES mediante concurso de merecimientos.	Informe documentado sobre la forma de aplicación del reglamento de escalafón docente.	Selección = 100*(Número total de profesores que ingresaron a la IES por concurso de merecimientos en un período de tiempo t) / (Número total de profesores ingresados a la IES en el período de tiempo t)
	DERECHOS DOCENTES	Cargos de dirección Los cargos de dirección considerados son: rector/a, vicerrector/a, decano/a, subdecano/a y jefe/a departamental académico.	Informe sobre documentado sobre los cargos de dirección.	Número total de cargos de dirección académica de la IES, en un período de tiempo t
		Actualización Porcentaje de docentes de la IES que recibieron algún tipo de auspicio (económico, licencia, etc.) para realizar cursos, seminarios, eventos de actualización en su especialidad	Informe sobre el porcentaje de docentes Que recibieron algún tipo de auspicio	Actualización = 100*Número total de docentes de la IES que recibieron algún tipo de auspicio para actualización, en un período de tiempo t ) / (Número total de docentes de la IES, en un período de tiempo t) Se considera el valor de 10% como el nivel superior de satisfacción del indicador.
		Cogobierno Evalúa el nivel de participación de los docentes en los órganos de dirección de la IES. Indicador de carácter cualitativo que valora la existencia y aplicación de reglamentos claros y precisos sobre la participación de los docentes en los órganos de dirección de la institución como son: consejo universitario, consejo politécnico, consejo de facultad y demás órganos de dirección académica y administrativa de la IES	Informe documentado sobre la aplicación de normas reglamentarias y la participación de los Docentes en los organismos de gobierno.	1. No tiene reglamento NO tiene reglamento de participación de docentes, aprobado por el Consejo Universitario/Consejo Politécnico. 2. Tiene reglamento pero no se aplica Tiene reglamento de participación de docentes, pero no lo aplica. 3. Tiene reglamento ambiguo Tiene reglamento de participación de docentes pero no es muy claro ni preciso: no se especifica claramente la forma de participación de los docentes, ni sus funciones, atribuciones o limitaciones. 4. Tiene reglamento y se aplica Tiene reglamento de participación de docentes y está perfectamente definida su forma de participación, los perfiles que se requieren para cada miembro, sus funciones, atribuciones y limitaciones.
		Género Dirección Evalúa la participación femenina en los cargos de dirección de orden académico de la IES. Los cargos de dirección considerados son: rector/a, vicerrector/a, decano/a, subdecano/a y jefe/a departamental académico.	Informe documentado sobre la participación femenina en los cargos de dirección de orden académico de la IES.	Género Dirección = 100*(Número de docentes mujeres de la IES que ocupan un cargo de dirección académica de la IES, en un período de tiempo t ) / (Número total de cargos de dirección académica de la IES, en un período de tiempo t)
		Género Docencia Evalúa la participación femenina en el cuerpo docente de la IES.	Informe documentado sobre la participación femenina en el cuerpo docente.	Género Docencia = 100*(Número de docentes mujeres de la IES, en un período de tiempo t ) / (Número total de docentes de la IES, en un período de tiempo t) Se logra la equidad cuando el indicador llega al 50%. Valores inferiores al 15% no tienen ningún aporte al indicador.
		Promoción Docentes Porcentaje de docentes promovidos/ascendidos de acuerdo a los reglamentos/normas de promoción y ascensos de la IES.	Porcentaje promedio anual de docentes ascendidos de categoría en el periodo t	Promoción Docentes = 100*(Número total de docentes de la IES, en un período de tiempo t (no se consideran los docentes que ya están ubicados en la máxima categoría de la escala institucional) ) / (Número total de docentes de la IES, en un período de tiempo t ) Se considera el valor de 8% como el nivel superior de satisfacción del indicador.
	REMUNERACIÓN	Remuneración TC Remuneración mensual promedio de un docente a tiempo completo de la IES.	Informe documentado de la remuneración mensual promedio de un docente a tiempo completo de la IES.	El cálculo es sobre la hora Remuneración TC = (Suma de las remuneraciones mensuales pagadas por la IES a sus profesores a tiempo completo en el mes t) / (Número de profesores a tiempo completo de la IES en el mismo mes t)
	REMUNERACIÓN	Remuneración TP Evalúa la remuneración por hora de clase dictada por un docente a tiempo parcial de la IES.	Promedio de la remuneración por horas (60 min.) de trabajo de los profesores a tiempo parcial.	El cálculo es sobre la hora Remuneración TP = (Suma de las remuneraciones percibidas por hora de clase por los profesores a tiempo parcial de la IES en el período t / Número total de profesores a tiempo parcial en el periodo t )

El proceso sería el siguiente:

La información requerida es suministrada directamente al sistema. El sistema debe tener en su base de datos la información básica de cada uno de los docentes de la Institución de Educación Superior (Nombres, Apellidos, Cédula). Antes de empezar con el proceso evaluativo cada docente recibe una clave de acceso, luego se procede a un llenado de un formulario en el cual el docente pueda completar su información personal, dentro de ésta información encontraremos:

Luego se procede a la realización de la evaluación el mismo que contará con preguntas de acuerdo a cada indicador.

El sistema debe recoger evidencias de cada una de las preguntas, una vez que ha terminado el proceso de envío de información, ésta deberá ser valorada de acuerdo a la forma establecida en los indicadores, luego es registrada en un archivo correspondiente, sin que exista ninguna posibilidad de que la información pueda ser modificada.

De acuerdo con las necesidades explicadas los objetivos planteados son:

Objetivo

· Desarrollar e implementar un sistema informático que permita evaluar la gestión académica universitaria siguiendo los indicadores de calidad del modelo del Consejo de Evaluación, Acreditación y Aseguramiento de la Calidad de la Educación Superior (CEAACES)

Especificos

· Analizar detalladamente los indicadores de gestión academica empleados por el CEAACES.

· Estudiar detenidamente como se calculan los indicadores de calidad.

· Implementar los modelos generales que permitan evaluar la gestión académica.

ESTIMACIÓN DE LOS RECURSOS REQUERIDOS

v Técnicos

El sistema informático a diseñar deberá contar con componentes tanto de hardware como de software que apoyen al desarrollo de la solución del problema y proporcione correcto funcionamiento del sistema.

Hardware

ü Computadores personales para el manejo de la información del sistema

ü Impresora para generación de los reportes.

ü Scaner para captura de documentos que se encuentren en papel.

ü Pendrive

ü Webcam

Software

ü Sistema operativo Windows xp

ü Sistema de administración y gestión de base de datos MySql para el manejo de la información requerida

ü Herramienta web para el desarrollo del software

ü Software Utilitario; Microsoft Office 2010: Word, Power Point, Exel.

Otros Recursos:

ü Internert

De Oficina

ü Hojas

ü Lapiceros

ü Carpetas

ü Grapadora

ü Anillados

ü Suministro eléctrico continuo y protecciones eléctricas

ü Otros por determinar más adelante

v Económicos (Costo de desarrollo)

Costo de Hardware

Producto	Valor x unidad	Cantidad	Total
Pc	1.200,00	3	3.600
Impresora Multifunción	120,00	1	120
Pendrive	16,00	3	48
Webcam	25,00	1	25
Total			$3793

Recurso Humano

Personal	Horas semanales	Cantidad Horas totales	Valor x hora	Total
Zorrilla Marjorie (Desarrollador-Investigador)	10	160	$5	800
Carriel Ruddy (Desarrollador-Redactor)	10	160	$5	800
Troya Roselyn (Desarrollador-Investigador)	10	160	$5	800
Total				$2400

Otros costos

Rubro	Costo Unitario	Unidades	Costo Total
Hojas	3.00	1	3,00
Lapiceros	0.40	3	1.20
Carpetas	0.50	5	2.50
Grapadora	3.00	1	3.00
Anillados	1.00	3	3.00
Impresiones	0.10 x H	500	50.00
Internet	0.80 x hora	64 c/d	51.20
Total			$113,90

Tabla Resumen

Recurso	Costo Total
Hardware	$3793,00
Software	0.00
Recurso Humano	$2400
Otros	$113,90
Costo total	6.306.2

El costo para el desarrollo del software tendría un valor aproximado de 6.306.2

ANÁLISIS DE FACTIBILIDAD DEL PROYECTO

ü Factibilidad Técnica

Con respecto a los requerimientos de hardware, existe en el mercado la totalidad de los equipos y componentes requeridos para la implementación de una solución con características definidas.

En cuanto a requerimientos de software existen en el mercado productos especializados para desarrollar este proyecto y que pueden ser gratuitos.

En lo que refiere al factor humano, es completamente factible el desarrollo del mismo.

En consecuencia, dado que satisfacen los requerimientos mínimos mencionados en el estudio técnico, es posible, técnicamente hablando, la realización de este sistema informático.

ü Factibilidad Económica

El costo del sistema Informático dado en el periodo de desarrollo inicial (Flexible a cambios) es de $6.306.2 En caso que no existan los recursos necesarios, se deben buscar alternativas de prestaciones de equipos.

En consecuencia, existe la factibilidad económica para la realización de este proyecto.

ü Factibilidad Organizacional

El objetivo es que el proyecto tenga una aceptable acogida, de acuerdo a la existencia de los recursos técnicos y económicos se podrá desarrollar el sistema de evaluación académica universitaria e implementarlo de una manera adecuada, en la UTEQ-Departamento de evaluación interna operando como un sistema que permita familiarizarse con las evaluaciones realizadas por el CEAACES ,permitir evaluar la gestión académica mediante el sistema y así tener una idea clara del nivel académico de nuestra institución con respecto a la acreditación.

El conjunto de actividades a realizar para cumplir con el objetivo es:

Personal que realiza cada actividad

PLAN DE TRABAJO

El plan es flexible a cambios de fechas de acuerdo al cronograma proporcionado por el coordinador.

Pasos a seguir para la realización del proyecto
Actividades	Descripción	Fecha
Entrevista con Coordinador general	Explicación general del Proyecto	06/06/2012
Investigación	Capacitación personal -comprensión el tema a desarrollar	07/06/12 – 11/06/12
Entrevista con personal del departamento de evaluación Interna de la UTEQ	Recolectar toda la información necesaria correspondiente al proceso evaluativo de la gestión académica.	12/06/12-14/06/12
Reunión de Equipo	Discusión de la explicación general	14/06/12
Entrevista con tutor	Explicación especifica del proyecto	14/06/12
Reunión de Equipo	Formulación, Descripción del problema, Objetivos, Hipótesis, Justificación	18/06/12 - 05/07/12
Entrevista con tutor y Coordinador general	Análisis de los avances realizados	06/07/12
Investigación	Capacitación personal - diseños del sistema	07/07/12
Reunión de Equipo	Análisis y Elaboración de diseños del sistema	09/07/12
Entrevista con Tutor	Revisión de diseños realizados	12/07/12
Investigación y Reunión de Equipo	Capacitación personal –Definiciones generales–Indicadores aplicables, Elaboración de Marco Teórico y Desarrollo de la aplicación	13/07/12 - 13/07/12
Entrevista con tutor y Coordinador general	Revisión de Documento y de inicios de la aplicación	17/07/2012
Reunión de Equipo	Desarrollo de la aplicación	18/07/12 – 28/08/12
Entrevista con tutor y Coordinador general	Revisión avanzada de la aplicación, prueba de la aplicación	29/08/12
Reunión de Equipo	Análisis de los resultados.	30/08/12
Reunión de Equipo	Elaboración de la Introducción , Conclusiones, Recomendaciones (Informe final)	05/09/2012
Reunión en equipo	Desarrollo del sistema Ajuste Finales	06/09/12 – 01/10/12
Reunión de Equipo	Implementación proyecto	3/10/12

EQUIPO

ü Desarrolladores

Carriel Muñoz Ruddy Maritza

Troya Mera Roselyn Vanessa

Zorrilla Castillo Marjorie Cesivel

ü Tutor:

Ing. Ariosto Vicuña

ü Coordinador

Ing. Freddy Triana

MÉTODOS Y TÉCNICAS

Proyectándonos en obtener resultados satisfactorios, se seguiran un conjunto de pasos sistemáticos y analíticos que permitan:

ü Determinar los objetivos.

ü Desarrollar el principio teórico-metodológico, con la finalidad de adquirir con conocimientos teóricos estrechamente relacionados con el proyecto.

ü Realizar entrevistas con personal especializado

ü Realizar Cuestionarios de encuestas

ü Aplicar encuestas

ü Estudiar los medios que hagan viable el cumplimiento de las actividades.

ü Designar responsabilidaes a cada uno de los miembros del equipo.

Informacion Adicional

Ø Requirimientos por parte de:

Departamento de Evaluación Interna de la UTEQ.

Ø Directivos del CEAACES

Presidente

Guillaume Long, Ph.D.

Consejo

María Luisa Granda Kuffó, Ph.D.

José Antonio Figueroa Pérez, Ph.D.

Mariana Lima Bandeira, Ph.D.

Fernando Espinoza Fuentes, Ph.D.

Holger Aníbal Capa Santos, Ph.D.

Planeación del Proyecto Integrador

mar.jorie1991@hotmail.com (Marjorie ) — Mon, 11 Jun 2012 07:03:00 +0000

Universidad Técnica Estatal de Quevedo

Facultad de Ciencias de la Ingeniería

Escuela de Informática

Carrera Ingeniería en Sistemas

Marjorie Zorrilla Castillo

Tema: Sistema de Evaluación de la Gestión Academica Universitaria utilzando indicadores del (CEAACES)

AMBITO DEL PROYECTO (NECESIDADES)

El sistema de evaluación universitaria conforme a los indicadores del CEAACES requiere evaluar la Gestión Académica de acuerdo a objetivos eduacionales lo que implica que el profesional recién egresado (sujeto a evaluación) debe demostrar desde el principio una competencia general y una variedad de capacidades que le permitan desenvolverse ética y satisfactoriamente en un entorno cada vez más competitivo y cuyo alcance no solo comprende el ámbito local sino el global.

Los resultados o logros del aprendizaje describen, lo que el alumno será capaz de conocer, comprender y de hacer al término de un proceso de aprendizaje y/o de sus estudios de la carrera.

INDICADORES

Indicadores	Descriptor	Cálculo del indicador y escala
Denominación	Correspondencia entre la denominación del título profesional que otorga la carrera y sus similares a nivel nacional e internacional	Corresponde - No corresponde
Misión y Visión	Estar claramente establecidos y ser asequibles a la comunidad universitaria y al entorno social.	(0.8)(Porcentaje de docentes que conocen la misión y la visión)+ (0.2)(Porcentaje de estudiantes que conocen la misión y la visión)
Perfil Consultado	Demostrar que el perfil de egreso y el perfil profesional han sido definidos en base a estudios y análisis de las necesidades del entorno	Alto: Ha sido establecido de acuerdo a los avances científicos-tecnológicos Medio: La investigación de los avances científicos no es sistemática ni periódica Bajo: Los objetivos de la formación son establecidos de manera discrecional.
Perfil Publicado	Ser consistente con la misión institucional, la misión y visión de la carrera	Porcentaje de estudiantes de la carrera que conocen el perfil de egreso.
Sistema de seguimiento a graduados	Debe tener un sistema que permita monitorear el cumplimiento del perfil de egreso.	Alto: tiene un responsable del monitoreo y cuenta con facilidades desarrolladas para la recolección y procesamiento de la información Medio: El sistema tiene un responsable del monitoreo pero no cuenta con las facilidades desarrolladas para la recolección y procesamiento de la información. Bajo: La carrera no cuenta con un sistema de monitoreo.
Evaluación por Pares	Evalúa el contenido de cada una de las materias, la especificidad de las carreras y su adecuación a los objetivos educacionales, misión y visión y pertinencia con el entorno.	Alto: Existe un reglamento parala evaluación de los contenidos de las materias por pares y se ha aplicado la evaluación de por lo menos el veinte por ciento de estas. Medio: Existe un reglamento para la evaluación por pares y la evaluación se ha aplicado a menos del veinte por ciento de los contenidos. Bajo: No existe un reglamento para la evaluación.

El proceso sería el siguiente:

La información requerida es suministrada directamente al sistema. Cada Institucion de Educacion Superior recibe una clave de acceso y, una vez que ha terminado el proceso de envío de información, ésta es registrada en un archivo correspondiente, sin que exista ninguna posibilidad de que la información pueda ser modificada.

Se verifica la información suministrada por la IES.

Un nuevo archivo de datos es generado y una vez finalizado el proceso de verificación, cualquier modificación u observación queda registrada, una vez finalizada la verificación, no existe posibilidad de introducir cambios.

La información verificada es sometida a pruebas de consistencia y coherencia.

Objetivo

Desarrollar un sistema informatico que permita evaluar la gestión académica universitaria siguiendo los indicadores de calidad del modelo del Consejo de Evaluación, Acreditación y Aseguramiento de la Calidad de la Educación Superior (CEAACES)

Especificos

Analizar detalladamente los indicadores de calidad de gestión academica empleados por el CEAACES.
Conocer e implementar los modelos generales que permitan evaluar la gestión académica.

ESTIMACIÓN DE LOS RECURSOS REQUERIDOS

Técnicos

El sistema informático a diseñar deberá contar con componentes tanto de hardware como de sorftware que apoyen al desarrollo de la solución del problema y proporcione correcto funcionamiento del sistema.

Hardware

ü Computadores personales para el manejo de la información del sistema

ü Impresora para generación de los reportes.

ü Scaner para captura de documentos que se encuentren en papel.

ü Pendrive

Software

ü Sistema operativo windows

ü Sistema de administración y gestión de base de datos

ü Herramienta para el desarrollo del software

ü Software Utilitario; Microsoft Office 2010: Word, Power Point, Exel.

Otros Recursos:

ü Internert

ü Hojas

ü Lapiceros

ü Carpetas

ü Grapadora

ü Anillados

ü Suministro eléctrico continuo y protecciones eléctricas

ü Otros por determinar más adelante

Económicos (Costo de desarrollo)

Costo de Hardware

Producto	Valor x unidad	Cantidad	Total
Pc	1.200,00	3	3.600
Impresora Multifunción	120,00	1	120
Pendrive	16,00	3	48
Total			$3768

Otros costos

Rubro	Costo Unitario	Unidades	Costo Total
Hojas	3.00	1	3,00
Lapiceros	0.40	3	1.20
Carpetas	0.50	5	2.50
Grapadora	3.00	1	3.00
Anillados	1.00	3	3.00
Impresiones	0.10 x H	500	50.00
Total			$62,70

Tabla Resumen

Recurso	Costo Total
Hardware	3.768,00
Software	0.00
Otros	62.70
Costo total	3.830,70

ANÁLISIS DE FACTIBILIDAD DEL PROYECTO

ü Factibilidad Técnica

Con respecto a los requerimientos de hardware, existe en el mercado la totalidad de los equipos y componentes requeridos para la implementación de una solución con características definidas.

En cuanto a requerimientos de software existen en el mercado productos especializados para desarrollar este proyecto y que pueden ser gratuitos. En lo que refiere al factor humano, es completamente factible el desarrollo del mismo.

En consecuencia, dado que satisfacen los requerimientos mínimos mencionados en el estudio técnico, es posible, técnicamente hablando, la realización de este sistema informático.

ü Factibilidad Económica

El costo del sistema Informático dado en el periodo de desarrollo inicial (Flexible a cambios) es de $3.830,70 En caso que no existan los recursos necesarios, se deben buscar alternativas de prestaciones de equipos.

En consecuencia, existe la factibilidad económica para la realización de este proyecto.

ü Factibilidad Organizacional

PLAN DE TRABAJO

El plan es flexible a cambios de fechas de acuerdo al cronograma proporcionado por el coordinador.

Pasos a seguir para la realización del proyecto
Actividades	Descripción
Entrevista con Coordinador general	Explicación general del Proyecto
Reunión de Equipo	Discusión de la explicación general
Investigación	Capacitación personal -comprensión el tema a desarrollar
Entrevista con tutor	Explicación especifica del proyecto
Reunión de Equipo	Formulación, Descripción del problema, Objetivos, Hipótesis, Justificación
Entrevista con tutor y Coordinador general	Análisis de los avances realizados
Investigación	Capacitación personal - diseños del sistema
Reunión de Equipo	Análisis y Elaboración de diseños del sistema
Entrevista con tutor y Coordinador general	Revisión de diseños realizados
Investigación	Capacitación personal – Definiciones generales –Indicadores aplicables
Reunión de Equipo	Elaboración de Marco Teórico
Reunión de Equipo	Desarrollo de la aplicación
Entrevista con tutor y Coordinador general	Revisión de Documento y de inicios de la aplicación
Investigación	Capacitación personal – Definiciones generales –Indicadores aplicables
Investigación	Capacitación personal acerca del sistema
Reunión de Equipo	Desarrollo de la aplicación
Entrevista con tutor y Coordinador general	Revisión avanzada de la aplicación, prueba de la aplicación
Reunión de Equipo	Análisis de los resultados.
Reunión de Equipo	Elaboración de la Introducción , Conclusiones, Recomendaciones
Reunión de Equipo	Elaboración de detalles finales del proyecto

EQUIPO

ü Desarrolladores

Carriel Muñoz Ruddy Maritza

Troya Mera Roselyn Vanessa

Zorrilla Castillo Marjorie Cesivel

ü Tutor:

Ing. Ariosto Vicuña

ü Coordinador

Ing. Freddy Triana

MÉTODOS Y TÉCNICAS

Proyectándonos en obtener resultados satisfactorios, se seguiran un conjunto de pasos sistemáticos y analíticos que permitan:

ü Determinar los objetivos.

ü Desarrollar el principio teórico-metodológico, con la finalidad de adquirir con conocimientos teóricos estrechamente relacionados con el proyecto.

ü Estudiar los medios que hagan viable el cumplimiento de las actividades.

ü Designar responsabilidaes a cada uno de los miembros del equipo.

Primer Elemento del Desarrollo de Sistemas

mar.jorie1991@hotmail.com (Marjorie ) — Mon, 11 Jun 2012 06:50:00 +0000

Planeación de un proyecto

El proceso de gestión de un proyecto de software comienza con un conjunto de actividades que, globalmente, se denominan planeación del proyecto.

"No podemos pedir exactitud a la fase de planificación, es solo una idea de cómo van a transcurrir las cosas. Hay que planificar el trabajo, los recursos humanos y la tecnología. Planificar es estimar."

OBJETIVO DE LA PLANIFICACIÓN DEL PROYECTO:

Es proporcionar un marco de trabajo que permita al gestor del proyecto hacer estimaciones razonables de recursos, coste y planificación temporal.

Las estimaciones se hacen dentro de un tiempo limitado al comienzo de un proyecto software, y deberían actualizarse con el progreso de este. Además, se deben definir escenarios del mejor y del peor caso para limitar los resultados del proyecto.

Actividades en la Planeación

· Establecer las necesidades

Para la obtención de la información necesaria o sea para acercar al cliente y al desarrollador (ingeniero del software, analista), y para hacer que comience el proceso de comunicación es necesario establecer una reunión o entrevista preliminar se sugiere que el analista comience haciendo preguntas de que lleven a un entendimiento básico del problema.

El primer conjunto de cuestiones se centran en el cliente, en los objetivos globales y en los beneficios. (Idea)

El siguiente conjunto de cuestiones permiten que el analista comprenda mejor el problema y que el cliente exprese sus percepciones sobre una solución.

El planificador del proyecto examina la especificación de las necesidades y se extraen las funciones importantes (DESCOMPOSICIÓN).

Estimación de los recursos requeridos

La segunda tarea en la planeación, es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo software y ver las factibilidades del mismo.

Factibilidad Técnica: Indica si se dispone de los conocimientos y habilidades en el manejo métodos, procedimientos y funciones requeridas para el desarrollo e implantación del proyecto. Además indica si se dispone del equipo y herramientas para llevarlo a cabo.

Factibilidad Económica: Se refiere a que se de financiamiento necesario para invertir en el desarrollo del proyecto,

Factibilidad Organizacional: Determina si existe una estructura funcional que apoyen y faciliten las relaciones entre personal, de tal manera que provoquen un mejor aprovechamiento de los recursos especializados. Determina la funcionalidad del sistema.

Si el proyecto es factible técnica, económica y organizacionalmente se procede a crear el plan de trabajo que es una estructura de las tareas a realizar dentro del proyecto, definiendo la duración y el orden de ejecución de las mismas.

Una vez definidas y descritas las actividades, es preciso analizar cuánto va a durar la ejecución de cada una de ellas, y sobre todo en qué orden se van a abordar.

La duración de cada actividad vendrá dada por múltiples factores como, la complejidad, el esfuerzo requerido, las personas disponibles, el tiempo del que dispongamos etc.

Luego para cumplir con esa programación o cronograma de actividades es necesario establecer el equipo de trabajo que no es otra cosa que el recurso humano que va a hacer factible el proyecto.

En cuanto los métodos y técnicas a aplicarse se recomienda hacer un análisis del trabajo.

· Analizar detalladamente el trabajo a realizar

· Pre-asignar recursos de personal, materiales y temporales a la ejecución de cada tarea.

· Formalizar los requisitos previos y los resultados a obtener de cada tarea.

· Asignar un responsable a cada tarea.

Fases de planeación

Resumen de UML

mar.jorie1991@hotmail.com (Marjorie ) — Thu, 31 May 2012 13:55:00 +0000