ESQUEMA PARA ELABORAR EL INFORME DEL PROYECTO SOCIOTECNOLOGICO (CAPTULOS I, II Y III)

CAPITULO I EL PROYECTO SOCIO TECNOLOGICO

El captulo I del informe de proyecto Socio Tecnolgico, est comprendido en dos parte, la parte A que comprende el diagnostico de la comunidad donde se aplicara el proyecto y la parte B que comprende el diagnostico del planteamiento del problema. A continuacin de define lo que debe contener cada parte del captulo I: A. LA COMUNIDAD

Nombre de la comunidad Descripcin de la comunidad Ubicacin geogrfica (Mapa de la comunidad) Misin y Visin de la comunidad Descripcin del rea geogrfica donde se desarrollara el proyecto

B. PLANTEAMIENTO DEL PROBLEMA

Contexto y descripcin de la necesidad tecnolgica Objetivo General y Especficos Justificacin e Importancia Alcance y Limitaciones

Contexto y descripcin de la necesidad tecnolgica: Consiste en describir de manera amplia la situacin objeto de estudio, ubicndola en un contexto que permita comprender su origen y relaciones. Durante la redaccin, es conveniente que los juicios emitidos sean avalados con datos o cifras provenientes de estudios anteriores. Se debe exponer el contexto pertinente (geogrfico, econmico, social, tecnolgico, cultural, etc.) de la necesidad tecnolgica o problema y de las relaciones de ste con otros aspectos de la realidad actual y proyectada, es decir, indicar el alcance de la necesidad tecnolgica ubicndola en tiempo, espacio y condiciones, y describirla. Posteriormente definir la solucin buscada. Al plantear el problema, se recomienda dar respuesta a las siguientes Interrogantes: Cules son los elementos del problema: datos, situaciones y conceptos relacionados con el mismo? Cules son los hechos anteriores que guardan relacin con el problema? Cul es la situacin actual? Cul es la relevancia del problema? Conscientes de la dificultad que representa la identificacin de un problema de investigacin, se ofrecen algunas fuentes que pueden dar origen a interrogantes cientficas: a) Observacin de problemas de tipo prctico en cualquier mbito: laboral, estudiantil, comunitario, etc. b) Revisin exhaustiva de la bibliografa y las investigaciones sobre el tema. c) Consulta a expertos en el rea. d) Lneas de investigacin establecidas por instituciones.

Objetivo General y Especficos: Los objetivos de investigacin son metas que se traza el investigador en relacin con los aspectos que desea indagar y conocer. Estos expresan un resultado o "producto de la labor investigativa." (Ramrez 1996, p. 61). En cuanto a su redaccin, los objetivos... "traducirn en forma afirmativa, lo que expresaban las preguntas inciales." (Sabino, 1994, p. 108). Para ello se ha de utilizar verbos en infinitivo, por ejemplo: conocer, caracterizar, determinar, establecer, detectar, diagnosticar, etc. Objetivo General: Segn Arias (2006), es un enunciado que expresa lo que se desea indagar y conocer para responder a un problema planteado (p. 43)

VERBO INFINITIVO + VARIABLE + UNIDAD DE ANLISIS + CONTEXTO

Ejemplo: Analizar el impacto de la crisis en Venezuela, referida a los niveles de pobreza en los patrones alimentarios de los nios, en edades comprendidas entre cero y seis aos, que acuden al hospital Dr. Domingo Luciani del Instituto Venezolano de los Seguros Sociales.

Objetivos Especficos: Estn relacionados con el objetivo general, pero se define en trminos ms operacionales. Se elaboran de manera organizada y jerarquizada, tomando en consideracin los aspectos o dimensiones que se propone lograr. A travs de qu mtodos (actividades) se puede conocer lo que se aspira. Conjunto de soluciones para cada una de las causas del problema.

Justificacin e Importancia: En esta seccin deben sealarse las razones por las cuales se realiza el proyecto, y sus posibles aportes desde el punto de vista terico o prctico. Para su redaccin, recomendamos responder las siguientes preguntas: Por qu se hace? Cules sern sus Aportes? A quines pudiera beneficiar?

Alcance y Limitaciones: Alcance: Debe especificar con claridad y precisin hasta donde se pretende llegar y profundizar en el PST. Debe ser realista y concreto en cuanto a: QU: necesidades encontradas. QUIN: comunidad beneficiada. CUNDO: tiempo estimado para el desarrollo. DNDE: descripcin de la comunidad.

Limitaciones: Son obstculos que eventualmente pudieran presentarse durante el desarrollo del proyecto.

La falta de cooperacin de los encuestados al suministrar la informacin es un ejemplo de una limitacin u obstculo.

CAPITULO II MARCO TEORICO TECNOLOGICO

Este captulo est comprendido de la siguiente manera: Antecedentes Marco Terico y Tecnolgico. Fundamentos Legales

Antecedentes: Son investigaciones realizadas anteriormente y que pueden tener vinculacin directa o indirecta con el problema. Se refiere a los estudios previos y tesis de grado relacionadas con el problema planteado, es decir, investigaciones realizadas anteriormente y que guardan alguna vinculacin con el problema en estudio. Debe evitarse confundir los antecedentes de la investigacin con la historia del objeto de estudio en cuestin. En este punto se deben sealar, adems de los autores y el ao en que se realizaron los estudios, los objetivos y principales hallazgos de los mismos. Estructura: I. Presentar un prrafo de inicio de todos los antecedentes sealando la relacin de stos con su investigacin y la utilidad o aporte II. Presentar los antecedentes en orden cronolgico y vigentes, precisar los siguientes datos : 1. Autor. 2. Fecha. 3. Ttulo . 4. Objetivos. 5. Metodologa. 6. Conclusiones III. Presentar un prrafo de cierre al final de todos los antecedentes o despus de cada uno, sealando la relacin de stos con su investigacin y la utilidad o aporte.

Marco Terico y Tecnolgico: Se fundamenta en aspectos tericos y tecnolgicos pertenecientes al problema. Comprenden un conjunto de conceptos y proposiciones que constituyen un punto de vista o enfoque determinado, dirigido a explicar el fenmeno o problema planteado. Esta seccin puede dividirse en funcin de los tpicos que integran la temtica tratada o de las variables

que sern analizadas. Para elaborar las bases tericas de la investigacin se sugiere considerar los siguientes aspectos: Ubicacin del problema en un enfoque terico determinado. Relacin entre la teora y el objeto de estudio. Posicin de distintos autores sobre el problema u objeto de investigacin. Adopcin de una postura por parte del investigador, la cual debe ser justificada. Ejemplo de un esquema de bases tericas para una investigacin sobre los factores que inciden en el rendimiento acadmico: 2.2.1. Concepto de rendimiento acadmico. 2.2.2. Variables relacionadas con el rendimiento. 2.2.2.1. Variables personales. 2.2.2.2. Variables familiares. 2.2.2.3. Variables acadmicas. 2.2.3. Evaluacin y prediccin del rendimiento acadmico. 2.2.3.1. Conceptos de evaluacin y medicin del rendimiento. 2.2.3.2. Instrumentos de medicin del rendimiento. 2.2.3.3. La prediccin educativa y sus tipos.

Definicin de Trminos Bsicos: Consiste en dar el significado preciso y segn el contexto a los conceptos principales, expresiones o variables involucradas en el problema formulado. Segn Tamayo (1993), la definicin de trminos bsicos "es la aclaracin del sentido en que se utilizan las palabras o conceptos empleados en la identificacin y formulacin del problema." (p. 78). Ejemplo: El trmino "proyeccin", en un estudio econmico significara el comportamiento a futuro de determinadas variables, mientras que en una investigacin sobre psicologa, "proyeccin" puede referirse a la transmisin de procesos psquicos al mundo exterior. Errneamente, se tiende a confundir esta seccin con un glosario, por tal razn se establecieron las siguientes diferencias: DEFINICIN DE BSICOS Contiene slo los vocablos o expresiones inmersas en el problema. Puede ubicarse luego de la formulacin del problema o en el marco terico. GLOSARIO TRMINOS Contiene los vocablos de difcil comprensin en una obra. Se ubica al final de la obra.

Fundamentos Legales: Es el contexto de normativa jurdica relacionado con el problema objeto de estudio

CAPITULO II DISEO TECNOLOGICO

Este captulo est comprendido de la siguiente manera: - Metodologa utilizada para el desarrollo del Proyecto Socio tecnolgico: Tipo de la Investigacin Diseo de la Investigacin -La comunidad y el Proyecto Socio tecnolgico Poblacin y muestra Tcnicas e instrumentos de recoleccin de datos. Tcnica de anlisis Anlisis de resultados Estudio de factibilidad y Recursos Plan de actividades (accin) del proyecto. (Diagrama de Gantt) - Metodologa para el desarrollo del software (etapas)

Metodologa utilizada para el desarrollo del Proyecto Socio tecnolgico:

Se refiere al medio a travs del cual el investigador obtiene la informacin necesaria que le permita lograr los objetivos del PST. Incluye los niveles y diseos de la investigacin que sern utilizados para llevar a cabo la indagacin. Niveles de Investigacin o Tipos de investigacin: El nivel de investigacin se refiere al grado de profundidad con que se aborda un objeto o fenmeno. Aqu se indicar si se trata de una investigacin exploratoria, descriptiva o explicativa. En cualquiera de los casos es recomendable justificar el nivel adoptado. Segn el nivel, la investigacin se clasifica en: Investigacin Exploratoria: es aquella que se efecta sobre un tema u objeto poco conocido o estudiado, por lo que sus resultados constituyen una visin aproximada de dicho objeto. Ejemplos: Las primeras investigaciones acerca del SIDA. Por ser una nueva enfermedad, no se conocan sus causas ni formas de transmisin. Estudios sobre Realidad Virtual. Investigacin Descriptiva: consiste en la caracterizacin de un hecho, fenmeno con el fin de establecer su estructura o comportamiento. Los estudios descriptivos miden de forma independiente las variables, y aun cuando no se formulen hiptesis, las primeras aparecern enunciadas en los objetivos de investigacin. Ejemplos: Anlisis de la poblacin estudiantil universitaria. Censos Nacionales. Investigacin Explicativa: se encarga de buscar el por qu de los hechos mediante el establecimiento de relaciones causa-efecto. Ejemplos: Indagacin de las causas que generan la corrupcin. Estudio de los efectos de una estrategia de enseanza sobre el rendimiento estudiantil. Diseo de Investigacin: El diseo de investigacin es la estrategia que adopta el investigador para responder al problema planteado. En esta seccin se definir y se justificar el tipo de investigacin segn el diseo o estrategia por emplear. En atencin al diseo, la investigacin se clasifica en: Investigacin Documental: es aquella que se basa en la obtencin y anlisis de datos provenientes de materiales impresos u otros tipos de documentos. Ejemplo: Estudio sobre la historia del Computador, realizado mediante la consulta de material bibliogrfico y hemerogrfico. Investigacin de Campo: consiste en la recoleccin de datos directamente de la realidad donde ocurren los hechos, sin manipular o controlar variable alguna. Ejemplo:

Sondeo de opinin en el que se consulta directamente al consumidor acerca de un producto. Investigacin Experimental: proceso que consiste en someter a un objeto o grupo de individuos a determinadas condiciones o estmulos (variable independiente), para observar los efectos que se producen (variable dependiente). Se diferencia de la investigacin de campo por la manipulacin y control de variables. Ejemplo: Sometimiento de un grupo de alumnos a una determinada estrategia, para observar los efectos sobre el rendimiento de stos.

La comunidad y el Proyecto Socio tecnolgico: Poblacin y Muestra La poblacin o universo se refiere al conjunto para el cual sern vlidas las conclusiones que se obtengan: a los elementos o unidades (personas, instituciones o cosas) involucradas en la investigacin. (Morles, 1994, p. 17). Se refiere al conjunto de elementos o unidades (personas, instituciones o cosas) para el cual se realizar el PST La muestra es un "subconjunto representativo de un universo o poblacin." (Morles, 1994, p. 54). La cual se determina en el caso de que las poblaciones sean excesivas, y se dificulte estudiar todas ellas.

Tcnicas e instrumentos de recoleccin de datos Las tcnicas de recoleccin de datos son las distintas formas o maneras de obtener la informacin. Son ejemplos de tcnicas; la observacin directa, la encuesta en sus dos modalidades (entrevista o cuestionario), el anlisis documental, anlisis de contenido, etc. Los instrumentos son los medios materiales que se emplean para recoger y almacenar la informacin. Ejemplo: fichas, formatos de cuestionario, guas de entrevista, lista de cotejo, grabadores, escalas de actitudes u opinin, etc. En esta parte se indicarn las tcnicas e instrumentos que sern utilizados en la investigacin. Tcnica de anlisis En este punto se describen las distintas operaciones a las que sern sometidos los datos que se obtengan: clasificacin, registro, tabulacin y codificacin si fuere el caso. Se refiere a la tcnica, que se va a utilizar para el anlisis de los resultados, por ejemplo: Tabla de frecuencia Diagrama de torta Anlisis de resultados Una vez aplicados los instrumentos para recolectar la informacin, se procede a realizar el anlisis de los mismos. Cabe sealar que el anlisis se realiza para cada pregunta o tem.

El anlisis se divide en dos pasos: 1.- Aplicacin de tcnica de anlisis (tabla de frecuencias, representacin grfica) 2.- La interpretacin terica de los resultados. Ejemplo: Item 1.- Est usted de acuerdo en implementar un Sistema de Informacin que permita? SI = 40 PERSONAS 1. NO= 10 PERSONAS

Tabla de frecuencias: si no

TEM 1

F 40

% 80

F 10

% 20

2. Representacin Grafica:

3. Interpretacin de los resultados

Los anteriores resultados del tem 1 inherente a la disponibilidad de utilizar un nuevo sistema reportaron que un 80% de los Docentes a quienes se les aplic el cuestionario, estn de acuerdo con su implementacin, mientras que un 20% no estuvieron de acuerdo , lo que indica una aceptacin de la mayora de la muestra.

Estudio de Factibilidad y recursos

Determinacin de la Factibilidad Factibilidad: se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas sealados, la factibilidad se apoya en 3 aspectos bsicos: Operativo. Tcnico. Econmico. El xito de un proyecto est determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores. Estudio de Factibilidad: Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisin, si procede su estudio, desarrollo o implementacin. Recursos de los estudios de Factibilidad: La determinacin de los recursos para un estudio de factibilidad sigue el mismo patrn considerado por los objetivos vistos anteriormente, el cual deber revisarse y evaluarse si se llega a realizar un proyecto, estos recursos se analizan en funcin de tres aspectos: a. Factibilidad Operativa: Se refiere a todos aquellos recursos donde interviene algn tipo de actividad (Procesos), depende de los recursos humanos que participen durante la operacin del proyecto. Durante esta etapa se identifican todas aquellas actividades que son necesarias para lograr el objetivo y se evala y determina todo lo necesario para llevarla a cabo. b. Factibilidad Tcnica: Se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, etc., que son necesarios para efectuar las actividades o procesos que requiere el proyecto. Generalmente nos referimos a elementos tangibles (medibles). El proyecto debe considerar si los recursos tcnicos actuales son suficientes o deben complementarse. c. Factibilidad Econmica: Se refiere a los recursos econmicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos bsicos que deben considerarse son el costo del tiempo, el costo de la realizacin y el costo de adquirir nuevos recursos. Generalmente la factibilidad econmica es el elemento ms importante ya que a travs de l se solventan las dems carencias de otros recursos, es lo ms difcil de conseguir y requiere de actividades adicionales cuando no se posee.

Plan de actividades (accin) del proyecto. (Diagrama de Gantt)

Esquema bsico donde se distribuye y organiza en forma de secuencia temporal el conjunto de experiencias y actividades diseadas a lo largo de un periodo de tiempo. Es un Calendario de trabajo Ventajas Gran organizacin. Permite mantener un ritmo de trabajo. Es posible constatar por escrito lo que cada paso involucra. Los asesores pueden programar sus revisiones.

Inconvenientes Provoca que se lleve todo el tiempo medido para cualquier actividad y no atiende a imprevistos. Lleva un gran control sobre el tiempo de quin lo realiza y, en el caso de que se produzca un desajuste por cualquier circunstancia, es muy complicado reajustarse al tiempo previsto. Pasos para realizar un cronograma: Presentar los objetivos que el cronograma nos va a aportar, organizndolos por su grado de importancia. Proponer las actividades necesarias para llevar a cabo estos objetivos. Establecer el grado de obligatoriedad de cada actividad. Establecer los materiales necesarios para llevar a cabo las actividades propuestas. Estimar el tiempo que debe durar cada una de las actividades propuestas. (En caso de un grupo)Distribuir las actividades entre sus componentes. Tener un registro para contabilizar si los objetivos de las actividades se estn cumpliendo. Anular o reducir el riesgo de atraso de las actividades ms complejas. Finalmente adaptar el cronograma al calendario real.

Metodologa para el desarrollo del software (etapas) En esta fase se debe definir la metodologa que se utilizar para la elaboracin del PST, entre estas se encuentran: Metodologa Cascada. Metodologa en Espiral. Metodologa Prototipo.

Programacin Extrema (XP) Metodologa de Proceso Unificado Racional (RUP)

Modelo de Cascada Algunas veces llamado ciclo de vida clsico, sugiere un enfoque sistemtico secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y continua con la planeacin, el modelado, la construccin y despliegue para culminar el soporte del software terminado. El modelo de la cascada es uno de los primeros modelos empleados en el desarrollo de software, se popularizo en 1970 y an est vigente en algunos desarrollos. ste modelo se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisin bien definidos, es decir, se codifica y reparan los errores; es un proceso continuo de codificacin y reparacin. Sus caractersticas principales son: Es lineal. Las actividades estn relacionadas secuencialmente. Cada etapa tiene una entrada y una salida. Es rgido y sistemtico: La entrada de una actividad es la salida de la etapa anterior, por lo cual no se puede dar inicio a la siguiente fase. Es monoltico: Existe una nica fecha de entrega. La implementacin se pospone hasta que no se comprendan los objetivos. Los documentos a entregar rigen el proceso de software. Es til como control de fechas de entregas. Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto. El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniera y Anlisis del Sistema Anlisis de los Requisitos Diseo Codificacin Prueba

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor 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 del software: el proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas. Diseo: el diseo del software 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. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin. Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente.

Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. 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: el software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debidos a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

Ventajas Impone la necesidad de mucha disciplina planificacin y administracin, en el proceso de desarrollo de software, venciendo as la filosofa de los procesos de codificar y probar Impone la necesidad de que la realizacin del producto debe ser pospuesta hasta que los objetivos sean bien entendidos.

Desventajas Retrasa la deteccin de errores hasta el final por lo cual es muy difcil realizar cambios cuando el proceso est en las ltimas fases. Toma mucho tiempo ver los resultados Es difcil mantener la trazabilidad entre los requerimientos iniciales y el cdigo final. Cuando los requerimientos no estn bien definidos no es posible aplicar ste modelo pues ello incrementara los riesgos y retrasara el proceso. Si los requerimientos del usuario varan es muy difcil satisfacerlo si el proceso se encuentra en las ltimas fases.

El costo de detectar errores en etapas avanzadas es muy alto dado que ello modificara todo lo que se ha desarrollado. El modelo de cascada ha introducido mucha disciplina en el proceso de desarrollo de software, pero sta disciplina est acompaada de rigidez. sta rigidez, introduce nuevos problemas al proceso, especialmente cuando el software es desarrollado con una pobre comprensin de los requerimeintos. Entre los problemas asociados con la rigidez del modelo estn:

Es dificil estimar con exactitud los recursos cuando solo esta disponible informacin limitada. El modelo de la cascada con frecuencia forza la estimacin de costos y la planificacin del proyecto a ocurrir despus de que una cantidad limitada de anlisis ha sido ejecutado. La especificacin de requerimientos se plasma en un documento que describe los requerimientos. Pero no importa cuan precisa es la descripcin, es muy dificil para el usuario anticipar si el sistema final ser construido de acuerdo a las especificaciones que espera. El usuario no sabe, con frecuencia, o no conoce los requerimientos exactos de la aplicacin. El modelo de la cascada no contempla la necesidad de anticipar los cambios. Al contrario, la filosofa subyacente es que nosotros deberamos esforzarnos para mantener la linealidad congelando todo como sea posible en las tempranas etapas.. El modelo hace cumplir las normas que estn basadas en la produccin de ciertos documentos en determinados momentos. De hecho, caracterizamos el proceso como el conducio por documentos. Este nfasis conduce a un estilo algo burocrtico de trabajo, donde se requiere que muchas formas sean llenadas y aprobadas y el ingeniero de

software est inclinado a prestar ms atencin a la sintaxis impuesta en el estndar que a su semntica. [1]

Modelo en espiral La meta del modelo espiral del proceso de produccin del software es proporcionar un marco para disear tales procesos, dirigido por los niveles de riesgo en el proyecto actual. En comparacin con los actuales modelos, el modelo espiral se puede ver como meta modelo, porque puede acomodar cualquier modelo de proceso del desarrollo. El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniera del software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis de riesgos, comenzando por el bucle anterior. Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de esfuerzos y tiempo que se consume en hacer productos software; y modelos de ciclo de vida, ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: el Modelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgos ms asumibles y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo. Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modelo en cascada. El modelo en espiral est pensado para proyectos largos, caros y complicados. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un sistema operativo La caracterstica principal del modelo espiral es que es cclico y no lineal como el modelo de la cascada. Cada ciclo del espiral consiste en cuatro etapas, y cada etapa es representada por un cuadrante del plano cartesiano. El radio del espiral representa el coste acumulado hasta ahora en el proceso; la dimensin angular representa el progreso en el proceso. El modelo espiral permite obtener mayor robustez en el proceso de desarrollo del software. Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos. Tareas: Para cada ciclo habr cuatro actividades: 1. Determinar o fijar objetivos: a. Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. b. Fijar las restricciones

c. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos d. Hay una cosa que solo se hace una vez: planificacin inicial o previa 2. Anlisis del riesgo: a. Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos 3. Desarrollar, verificar y validar (probar): a. Tareas de la actividad propia y de prueba b. Anlisis de alternativas e identificacin de resolucin de riesgos c. Dependiendo del resultado de la evaluacin de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. 4. Planificar: a. Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. El proceso empieza en la posicin central. Desde all se mueve en el sentido de las agujas del reloj.

Las cuatro regiones del grfico son: 1 La tarea de planificacin: para definir recursos, responsabilidades, hitos y planificaciones

2 La tarea de determinacin de objetivos: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas 3 La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin 4 La tarea de ingeniera: para disear e implementar uno o ms prototipos o ejemplos de la aplicacin 1 Ventajas

El anlisis de riesgos se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Entre ellos: 1 2 3 Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con el modelo, ya que el ciclo de vida no es rgido ni esttico. Mediante este modelo se produce software en etapas tempranas del ciclo de vida y suele ser adecuado para proyectos largos de misin crtica. 1 Inconvenientes

Es un modelo que genera mucho trabajo adicional. Al ser el anlisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos (es bastante difcil). Esto puede llevar a que sea un modelo costoso. Adems, no es un modelo que funcione bien para proyectos pequeos.

Modelo de Prototipos Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de adaptacin de un sistema operativo, o de la forma en que debera tomarse la interaccin hombre-mquina. En estas y en otras muchas situaciones, un paradigma de construccin de prototipos puede ofrecer el mejor enfoque. La construccin de prototipos representa una estrategia de desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo interactivo o en continua evolucin, donde el usuario participa de forma directa en el proceso. Este mtodo contiene condiciones nicas de aplicacin, en donde los encargados del desarrollo tienen poca experiencia o informacin, o donde los costos y riesgos de que se cometa un error pueden ser altos. As mismo este mtodo resulta til para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseo de un sistema o examinar el uso de una aplicacin

El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente. El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer

El mtodo del prototipo de sistemas consta de 5 etapas: 1). Identificacin de requerimientos conocidos: La determinacin de los requerimientos de una aplicacin es tan importante para el mtodo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o anlisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer. 2). Desarrollo de un modelo de trabajo: Es fcil comenzar el proceso de construccin del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interaccin es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes: a). El lenguaje para el dialogo o conversacin entre el usuario y el sistema. b). Pantallas y formatos para la entrada de datos. c). Mdulos esenciales de procesamiento. d). Salida del sistema 3). Utilizacin del prototipo: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus caractersticas y operacin. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, as como las caractersticas inadecuadas 4). Revisin del prototipo: Durante la evaluacin los analistas de sistemas desean capturar informacin sobre los que les gusta y lo que les desagrada a los usuarios. Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones. 5). Repeticin del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas estn de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las caractersticas necesarias. Ventajas Entre las ventajas que ofrece este modelo se pueden destacar las siguientes: Ofrece visibilidad del producto desde el inicio del ciclo de vida con el primer prototipo. Esto puede ayudar al cliente a definir mejor los requisitos y a ver las necesidades reales del producto. Permite introducir cambios en las iteraciones siguientes del ciclo. Permite la realimentacin continua del cliente. El prototipo es un documento vivo de buen funcionamiento del producto final. El cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar, que no sobre una especificacin escrita. Este modelo reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduccin de tiempo y de costos, incrementos en la aceptacin del nuevo sistema.

Inconvenientes

Entre los inconvenientes que se han observado con este modelo est el hecho de que puede ser un desarrollo lento. Adems se hacen fuertes inversiones en un producto desechable ya que los prototipos se descartan. Esto puede hacer que aumente el coste de desarrollo del producto. Con este modelo pueden surgir problemas con el cliente que ve funcionando versiones del prototipo pero puede desilusionarse porque el producto final an no ha sido construido. El desarrollador puede caer en la tentacin de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

Programacin Extremo o Xp Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto. La programacin extrema (XP) es un enfoque de la ingeniera del software formulado por Kent Beck. Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y aplicarlo de manera dinmica durante el ciclo de vida del software. XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en la realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. A Kent Beck se le considera el padre de XP. Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre. Elementos de la metodologa 0 Las historias de usuario: son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el

sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarlas en unas semanas. Las historias de usuario se descomponen en tareas de programacin y se asignan a los programadores para ser implementadas durante una iteracin Roles XP: los roles de acuerdo con la propuesta de Beck son: o Programador: el programador escribe las pruebas unitarias y produce el cdigo del sistema o Cliente: escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en apoyar mayor valor al negocio. o Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para las pruebas. o Encargado de seguimiento (tracker): proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin. o Entrenador (coach): es el responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. o Consultor: es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas. o Gestor (big boss): es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. Proceso XP: el ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar 2. El programador estima el esfuerzo necesario para su implementacin 3. El programador construye ese valor 4. Vuelve al paso 1 5. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse de que el sistema tenga el mayor valor de negocio posible. El ciclo de vida ideal de XP consisten en 6 fases: exploracin, planificacin de la entrega, iteraciones, produccin, mantenimiento y muerte del proyecto.

Caractersticas: Metodologa para un gil desarrollo de software. Programacin basada en los deseos del cliente. El equipo lo conforman los jefes de proyecto, desarrolladores y el cliente.

Se rige por valores y principios.

Valores de XP Comunicacin: Crear software requiere de sistemas comunicados. Simplicidad: Empezar con lo necesario y requerido y trabajar desde ah. Retroalimentacin: Del sistema, del cliente, y del equipo. Valenta: Programa para hoy y no para maana. Respeto: El equipo debe trabajar como uno, sin hacer decisiones repentinas

Actividades Codificacin: La parte mas importante de XP. Pruebas: Nunca se puede estar seguro de algo hasta haberlo probado. Escuchar: Escuchar los requisitos del cliente acerca del sistema a crear. Diseo: Crear una estructura del diseo para evitar problemas.

Ventajas Programacin organizada. Menor taza de errores. Satisfaccin del programador. Cambios en los objetivos y prioridades son naturales. Sin sobrecarga al equipo de desarrollo El cliente desde las primeras etapas tiene software que puede usar y probar. En cualquier momento puede parar el desarrollo, quedndose con un producto que representa lo invertido hasta esa fecha. Desventajas: Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar Es necesario un representante del cliente en todo momento del desarrollo Todo el proceso de desarrollo se basa en la comunicacin, si la misma es costosa o lenta perjudica enormemente el tiempo y costo del desarrollo No sirve para proyectos grandes debido a sus requerimientos de comunicacin Beneficios El cliente tiene el control sobre las prioridades. Se hacen pruebas continuas durante el proyecto. La XP es mejor utilizada en la implementacin de nuevas tecnologas donde los requerimientos cambian rpidamente

Metodologa RUP

El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniera de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodologa de desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el manejo de la arquitectura.

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad especfica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visin y el mismo proceso acerca de cmo desarrollar software. CICLO DE VIDA

En el ciclo de vida RUP veremos una implementacin del desarrollo en espiral. Con el ciclo de vida se establecen tareas en fases e iteraciones. El RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una base de inicio FASES FASE DE INICIO Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las actividades de modelamiento de la empresa y en sus requerimientos. Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones. FASE DE ELABORACIN

Durante esta fase de elaboracin, las iteraciones se centran al desarrollo de la base de la diseo, encierran ms los flujos de trabajo de requerimientos, modelo de la organizacin, anlisis, diseo y una parte de implementacin orientada a la base de la construccin. Los casos de uso seleccionados para desarrollarse en esta fase permiten definir la arquitectura del sistema, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar del problema y comienza la ejecucin del plan de manejo de riesgos, segn las prioridades definidas en l. Al final de la fase se determina la viabilidad de continuar el proyecto y si se decide proseguir, dado que la mayor parte de los riesgos han sido mitigados, se escriben los planes de trabajo de las etapas de construccin y transicin y se detalla el plan de trabajo de la primera iteracin de la fase de construccin FASE DE CONSTRUCCIN Durante esta fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se redefine su anlisis y diseo y se procede a su implantacin y pruebas. En esta fase se realiza una pequea cascada para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva implementacin del producto. El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar el cambio de los artefactos construidos, ejecutar el plan de administracin de recursos y mejoras en el proceso de desarrollo para el proyecto. FASE DE TRANSICIN Durante esta fase de transicin busca garantizar que se tiene un producto preparado para su entrega al usuario. El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto al inicio del mismo. PRINCIPALES CARACTERISTICAS

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso).

Implementacin del RUP para el proyecto La metodologa RUP es ms apropiada para proyectos grandes (Aunque tambin pequeos), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de