lunes, 14 de noviembre de 2011

Debian y Ubuntu

Debian o Proyecto Debian es una comunidad conformada por desarrolladores y usuarios, que mantiene un sistema operativo GNU basado en software libre. El sistema se encuentra precompilado, empaquetado y en un formato deb para múltiples arquitecturas de computador y para varios núcleos.
Nació como una apuesta por separar en sus versiones el software libre del software no libre. El modelo de desarrollo del proyecto es ajeno a motivos empresariales o comerciales, siendo llevado adelante por los propios usuarios, aunque cuenta con el apoyo de varias empresas en forma de infraestructuras. Debian no vende directamente su software, lo pone a disposición de cualquiera en Internet, aunque sí permite a personas o empresas distribuirlo comercialmente mientras se respete su licencia.
La comunidad de desarrolladores del proyecto cuenta con la representación de Software in the Public Interest, una organización sin ánimo de lucro que da cobertura legal a varios proyectos de software libre.
La primera adaptación del sistema Debian, siendo también la más desarrollada, es Debian GNU/Linux, basada en el núcleo Linux, y como siempre utilizando herramientas de GNU. Existen también otras adaptaciones con diversos núcleos: Hurd (Debian GNU/Hurd); NetBSD (Debian GNU/NetBSD) y FreeBSD (Debian GNU/kFreeBSD).

Historia de Debian

El proyecto Debian fue fundado en el año 1993 por Ian Murdock, después de haber estudiado en la Universidad de Purdue. Murdock escribió el Manifiesto de Debian que utilizó como base para la creación de la distribución Linux debian. Dentro de este texto los puntos destacables son: tener de la distribución de manera abierta, coherente al espíritu de Linux (núcleo) y de GNU.
El nombre del proyecto se basa en la combinación del nombre de su entonces novia (actual ex esposa) Deborah con su propio nombre Ian, formando el portmanteau Debian, pronunciado como las sílabas correspondientes de estos nombres, en inglés estadounidense: /dɛbˈiːjən/.
El proyecto creció lentamente al principio y lanzó sus primeras versiones 0.9x en 1994 y 1995. Las primeras portabilidades a otras arquitecturas fueron a comienzos de 1995, siendo la primera versión 1.x de Debian lanzada en 1996.
En 1996, Bruce Perens substituyó a Ian Murdock como el líder de proyecto. Por sugerencia del desarrollador Ean Schuessler, dirigió el proceso de actualización del Contrato Social de Debian y de las pautas del software de debian libremente, definiendo los puntos fundamentales para el desarrollo de la distribución. También inició la creación de la licencia de software legal de la organización.
Bruce Perens se retiró en 1998, antes del lanzamiento de la primerra versión de Debian basada en glibc, la 2.0. El proyecto procedió a elegir a nuevos líderes y a hacer dos revisiones de la versión 2.x, cada uno incluyendo más versiones para otras arquitecturas y más paquetes. Conveniente fue lanzada durante este período y la primera portabilidad a un núcleo no basado en el núcleo Linux, naciendo así debian GNU/Hurd, utilizando el núcleo de Hurd proveniente del proyecto GNU. Las primeras distribuciones Linux basadas en Debian (Corel Linux y la Stormix's Linux de Stormix), fueron comenzadas en 1999. Aunque estuvieron desarrolladas no por mucho tiempo, estas distribuciones fueron las primeras de muchas que se basarían en Debian.
A finales de 2000, el proyecto realizó el mayor cambio a la estructura de los archivos y la organización de las versiones, reorganizando procesos de liberación de paquetes del software con el nuevo "package pools" (del inglés depósito de paquetes), y creando un rama de prueba, relativamente estable para el lanzamiento siguiente. En 2001, los desarrolladores comenzaron a reunirse en una conferencia anual llamada Debconf con discusiones y talleres para desarrolladores y usuarios técnicos.

Ubuntu es un sistema operativo mantenido por Canonical y la comunidad de desarrolladores. Utiliza un núcleo Linux, y su origen está basado en Debian. Ubuntu está orientado en el usuario promedio, con un fuerte enfoque en la facilidad de uso y mejorar la experiencia de usuario. Está compuesto de múltiple software normalmente distribuido bajo una licencia libre o de código abierto. Estadísticas web sugieren que el porcentaje de mercado de Ubuntu dentro de "distribuciones linux" es de aproximadamente 49%, y con una tendencia a subir como servidor web.
Su patrocinador Canonical, es una compañía británica propiedad del empresario sudafricano Mark Shuttleworth que en vez de vender Ubuntu con fines lucrativos, se financia por medio de servicios vinculados al sistema operativo y vendiendo soporte técnico. Además, al mantenerlo libre y gratuito, la empresa es capaz de aprovechar los desarrolladores de la comunidad en mejorar los componentes de su sistema operativo. Canonical también apoya y proporciona soporte para las derivaciones de Ubuntu: Kubuntu, Xubuntu, Edubuntu, Lubuntu y la versión de Ubuntu orientada a servidores (Ubuntu Server).
Su eslogan es Linux for human beings (‘Linux para seres humanos’) y su nombre proviene de la ideología sudafricana Ubuntu («Igualdad/Lealtad hacia otros.»).
Cada seis meses se publica una nueva versión de Ubuntu la cual recibe soporte por parte de Canonical, durante dieciocho meses, por medio de actualizaciones de seguridad, parches para bugs críticos y actualizaciones menores de programas. Las versiones LTS (Long Term Support), que se liberan cada dos años, reciben soporte durante tres años en los sistemas de escritorio y cinco para la edición orientada a servidores.

Historia y proceso de desarrollo

Ubuntu es una bifurcación del código base del proyecto Debian. El objetivo inicial era el de lanzar una nueva versión de Ubuntu cada seis meses, resultando en un sistema más actualizado. Su primer lanzamiento fue el 20 de octubre de 2004.
Los lanzamientos de Ubuntu están sincronizados para realizarse un mes después que las del entorno de escritorio GNOME. Ubuntu usa primariamente software libre haciendo excepciones para varios controladores privativos además del firmware y software no libre incluido en el kernel Linux y el software no libre presente en sus repositorios.
Los paquetes de Ubuntu están basados en la rama inestable de Debian: ambas distribuciones usan el formato de paquete de software deb y las herramientas de administración de paquetes APT, dpkg, más algunos front-ends. Los paquetes Debian y Ubuntu no son necesariamente compatibles binariamente; algunas veces los paquetes deb pueden necesitar ser recompilados desde el código fuente para ser usados en Ubuntu. Muchos desarrolladores de Ubuntu también mantienen paquetes clave en Debian. Ubuntu coopera con Debian devolviendo cambios y mejoras en el código, aunque existen críticas sobre los escasos aportes. En el pasado, Ian Murdock, fundador de Debian, expresó su preocupación por el potencial cambio de los paquetes de Ubuntu con respecto a los de Debian ya que podrían llegar a ser completamente incompatibles.
Antes de cada lanzamiento, se lleva a cabo una importación de paquetes, desde Debian, aplicando las modificaciones específicas de Ubuntu. Un mes antes del lanzamiento, comienza un proceso de congelación de importaciones, ayudando a que los desarrolladores puedan asegurar que el software sea suficientemente estable.
Desde el inicio del proyecto, Shuttleworth proporcionó el soporte económico gracias a los beneficios obtenidos después de vender su empresa Thawte a VeriSign, por unos 575 millones de dólares estadounidenses.
El 8 de julio de 2005, Mark Shuttleworth y su empresa Canonical Ltd. anunciaron la creación de la Fundación Ubuntu y aportaron 10 millones de dólares como presupuesto inicial. El propósito de la fundación es el de asegurar soporte y desarrollo para todas las futuras versiones de Ubuntu.
El 12 de marzo de 2009, Ubuntu anunció soporte para plataformas externas de administración de computación en nube, como Amazon EC2.
A principios de 2009 los ingenieros y diseñadores de Canonical se dan cuenta de que la gestión de paquetes e instalación de aplicaciones es demasiado fragmentada y hasta compleja, por ende se planifica la creación de una aplicación central para el manejo e instalación de aplicaciones. En octubre de 2009 Canonical lanza oficialmente el Centro de software de Ubuntu (Ubuntu Software Center), permite buscar, instalar, desinstalar aplicaciones, y además permite agregar repositorios de terceros. En octubre de 2010 se introduce la venta de aplicaciones por medio de pagos en línea en el Centro de software de Ubuntu.
El 3 de junio de 2010, Mark Shuttleworth anuncia el trabajo en conjunto con el proyecto Linaro y su desarrollo de código abierto para Linux en procesadores con tecnología ARM. A fines de septiembre se da a conocer antes del lanzamiento de Ubuntu 10.10, que esta versión incluiría un mejor y más estable soporte para procesadores ARM.
En octubre y noviembre de 2010, se anuncian drásticos e importantes cambios en el escritorio de Ubuntu, la inclusión de la interfaz de usuario Unity (creada por Canonical), la cual será utilizada en la versión de escritorio de Ubuntu. También Mark Shuttleworth anuncia que en futuras versiones de Ubuntu, Unity se implementará en el servidor gráfico Wayland, y no en el servidor gráfico X (como se hacía habitualmente).
El 18 de enero de 2011, Mark Shuttleworth anuncia la inclusión de aplicaciones creadas en Qt para ser lanzadas a partir de "Natty+1" (después del lanzamiento de Ubuntu 11.04) y en futuras versiones de Ubuntu. Una de las metas de esta decisión es facilitar la integración al sistema de aplicaciones Qt, en comparación con las típicas aplicaciones desarrolladas en GTK que lucen nativas en la interfaz de usuario de Ubuntu. Para terminar con las dificultades técnicas de configuración y preferencias del sistema entre Qt y GTK, se crearán enlaces dconf para las aplicaciones Qt, con lo que se pretende centralizar la configuración del sistema, ya sea GTK o Qt, en un solo lugar.
El 9 de marzo de 2011, Canonical anuncia la discontinuidad de 'Ubuntu Netbook Edition', debido a la integración de la interfaz Unity en su versión de escritorio a partir de Ubuntu 11.04, y así eliminar la redundancia de sus versiones con un mismo escritorio. Canonical también anuncia que los nombres 'Ubuntu Desktop Edition' y 'Ubuntu Server Edition' se eliminan, dejando solamente el nombre 'Ubuntu' para uso en todo tipo de computadoras, y 'Ubuntu Server' para su uso en servidores.
El 31 de octubre de 2011, durante la presentación del Ubuntu Developer Summit, Mark Shuttleworth anuncia la integración de Ubuntu en varios otros dispositivos, tales como Tablets, Smart TVs, Smartphones, y pantallas de automóviles. Todo esta integración llegará en la versión 14.04, en abril de 2014.





martes, 8 de febrero de 2011

Requerimientos o requisitos del software

Diagrama de uso

 

 Breve Resumen del proceso
El personal del centro asistencial del seguro social (Servidor Publico Responsable) se dirige a la oficinas administrativas del seguro social para  realiza la entrega de relación y soportes de las pacientes que asisten al ambulatorio del seguro social, realiza la entrega al personal encargado de las prestaciones el mismo valida que los recaudos estén completos para proceder ha realizar el registro de dichos pacientes y realizar el kárdex (Forma 14-88) realizan el calculo de los días que se deben se liquidad  validando si los el paciente posee algún otro reposo que sea sucesivo para sumar esos días a su liquidación, luego  de registrar los datos genera una planilla de los pacientes que asistieron ese mes para realizar en envío de esta planilla al personal administrativo del área de prestaciones y liquidación.

Diagrama de Clases

Básicamente para el diagrama de clase expresamos las tablas principales que se deben tener al momento de generar la base de datos, aquí especificamos el nombre de las clases de las cueles tenemos las siguientes atributos y eventos:




 
Sistema para  llevar el control de Liquidación de las Indemnizaciones Diarias de los pacientes de Instituto Venezolano de los Seguros Sociales ubicado en Calabozo Estado Guárico
El desarrollo de la siguiente propuesta consiste en plantear un sistema de control de Liquidaciones de Indemnizaciones Diarias de los asegurados del IVSS, ya que este procedimiento actualmente se realiza de manera manual donde los asegurados que asisten al Centro Asistencial del IVSS ubicado en la urbanización Misión de Arriba en Calabozo estado Guárico. El asegurado entrega en el Centro Asistencial (Unidad de Prestaciones) los siguientes recaudos:
·        Fotocopia de la Cedula de Identidad.
·        Certificado de Incapacidad validada (Forma 14-73).
·        Comprobante de Consignación de Datos (Forma 14-52).
·        Planilla de Inscripción (Forma 14-02).
·        Cuenta Individual.
                  Una vez que se reciben estos recaudos se procede a liquidar.

Requerimiento del entorno
El diseño se presenta primeramente como una propuesta bajo el lenguaje de programación PHP, soportado en la base de datos de MySQL ya que el mismo funciona con el sistema operativo que se utiliza actualmente en el IVSS, como lo es el Microsoft Windows XP, en dicha institución se cuenta con diversos equipos. Ha continuación indicaremos las características del equipo donde se realizar ejecución del sistema en el departamento de afiliación este equipo presenta posee las siguientes condiciones:
  •   Hardware
Lenovo ThinkCentre E50
·        Memoria RAM 1 GB Expandible hasta 2 GB
·        Disco Duro 80GB
·        Procesador Intel pentium 4 CPU 3.07 GHz.
·        Unidad de CD ROM 48X
·        Unidad de diskette 3,5” 1,44 MB
·        Teclado en español y mouse óptico
·        Módem 56 Kbps
·        Procesador de video integrado “Intel Extreme Graphics”
·        Audio SoundMax con cornetas externas
·        Tarjeta Ethernet 10/100
·        Puertos: 6 USB, Serial, Paralelo, de entrada para micrófono y de salida para audio
·        Monitor SVGA 15”

Impresora Epson Stylus Photo T22

  • Software
Sistema Operativo Windows XP Home programas, Office 2007, Antivirus McAfee, entre otros

Nota: Información suministrada por departamento de informativa del Seguro Social de Calabozo Estado Guárico.
Requerimientos ergonómicos
            El IVSS cuenta con un espacio acorde con sus necesidades ya que su espacios se ajusta ha la cantidad de procesos y público que se dirige a dicha Institución, en el departamento de Afiliación que es donde se ejecuta el proceso de Liquidación cuenta con su equipo completo incluyendo impresora, intranet, escritorio de oficina, silla cómoda para el uso del empleado, aire acondicionado, el ambiente se ajusta a las necesidades del empleado, publico y sistema que se maneja en dicha entidad, por ende certificamos que no es necesario la remodelación o adquisición de equipo ya que la mismas se encuentra en optimas condiciones para la implantación del sistema.
Requerimientos de interfase
Actualmente el IVSS maneja un sistema interno donde se vinculan datos vía online para que el público y empresas puedan realizar ciertas operaciones y consultas  a continuación presentamos la interfase  de acceso al  público y del empleado:
Acceso Público


            Acceso Interno


Pantallas del sistema a realizar

Pantalla Principal


Ingreso de pacientes

Búsqueda de Pacientes


Listado de pacientes


Cambio de Clave


Ayuda
Salida del sistema

Requerimientos funcionales
La propuesta se realiza con el fin de agilizar el proceso de liquidación que se realiza en el IVSS, ya que la herramienta utilizada actualmente para este proceso retraza el proceso de los cálculos de Liquidación de las Indemnizaciones Diarias. Esta propuesta trabajaría con una Historia de Asegurados ya existente la cual contiene: Código de Diagnostico, Periodo de incapacidad del asegurado, Días de incapacidad del asegurado, Nº de Relación y Fecha de Liquidación.
Requerimiento de desempeño
El sistema se realiza bajo la misma interfase que tiene el sistema del IVSS, donde solo se podrá realizar un proceso a la vez por seguridad de registro de los procesos y adicional del sistema, pero aun así el sistemas será  rápido solo se necesita tener acceso a la intranet y de acuerdo al mismo se vera la rapidez del sistema, donde podrán ingresar los distintos empleados ya que cada uno de acuerdo a su clave podrá acceder por región y la misma no generara inconvenientes con ingresos simultaneo a la misma operación y podrá ser ejecutado desde cualquier sede donde se tenga acceso ha la intranet del IVSS, la ejecución del mismo requiere de un buen equipo por la base de datos que en la misma se maneja y dicha institución cuenda con los requisitos necesarios para el desempeño correcto y veraz del sistema a realizar.
Requerimiento de disponibilidad
El sistema ha realizar será de durabilidad ya que contaría con el manteniendo que se le realiza ha los sistemas periódicamente en el IVSS, no se degradaría ya que de igual manera siempre se están actualizando y mejorando los procesos que en dicha institución se realizan, se podrá implantar no solo en esta institución si no en otras áreas donde se realizar cálculos o liquidaciones tomando en cuenta el procesos y será ajustando  el sistema a las necesidades de otras áreas ó empresas así que podrá ser ejecutado bajo cualquier plataforma.
Requerimiento de entrenamiento:

El personal que labora en el IVSS de calabozo Estado Guárico cuenta con la experiencia necesaria acerca del manejo de computadoras y sistema, ya que dicho personal es un personal profesional , mas sin embargo se contara con un manual de ayuda cargado en el mismo sistema este manual contara no solo con la información de cada campo sino con un demo anexado en el manual de ayuda donde se muestra gráficamente como se debe realizare el vaciado de información y proceso del mismo , cada uno del campos tendrá su nombre e indicaras su utilidad esto en su respectivo idioma en este caso el español, ahora bien al cargar esta información la mismas e debe mostrar vía online en la pagina de acceso  el publico del IVSS, donde de igual manera tendrá en este caso un link con un demo de ayuda para el publico, es decir el sistema contara con 2 manuales un apara el empleado y otro para el publico, dicho manual adicional se entregada en CD  serán  gráficos y visuales.
Requerimiento estricciones de diseño
Hasta el momento en el desarrollo de esta investigación no se han  tenido limitantes paras su realización, mas bien hemos contado con el apoyo de esta institución para la elaboración del mismo nos han suministrado  la información necesaria para la elaboración de dicho sistema.
Materiales
La entrega del sistema se relazara en un CD  donde el mismo  tendrá si instalador y manual para ejecutar la instalación del mismo.

-------------------------------------------------------------------------------------------------------------------------





7.4. Exponer algunos de los problemas que pueden surgir cuando los requisitos deben obtenerse de tres o cuatro clientes.

A la hora de obtener los requisitos de un software se ven involucrados muchos clientes, complicando así la tarea del ingeniero de software debido a que cada persona o cliente interesado en el sistema tiene una visión diferente comparada con el resto del grupo. Esto ocurre porque los requisitos del software se explotan desde muchos puntos de vista.

Cuando hay tantas personas involucradas en el proceso de obtención de información es lógico que no se llegue a un acuerdo único y preciso de lo que en realidad debe hacer el sistema y que debería tener, dificultando el trabajo del ingeniero encargado del proceso de recolección de información porque cada departamento que contribuye para la elaboración del software ve como necesidad prioritaria algo que optimice y facilite sus tareas haciendo casi imposible obtener requisitos que coincidan entre si.
           
A continuación se presentan algunos problemas que pueden surgir cuando existen muchos clientes en el proceso de recolección de requisitos:
  • Es muy difícil llegar a un acuerdo específico.
  • Los puntos de vistas difieren muchos entre si.
  • Se hace difícil determinar lo que es necesario para el sistema.
  • Podría generar conflictos y pleitos internos.
  • Cada persona va a pretender un sistema con características con las cualas ya estén familiarizadas.

7.17. ¿Qué se cree que suceda cuando la validación de requisitos descubre un error? ¿Quién es el indicado para corregir el error?
7.11.b. Desarrolle un caso de uso en el cual se utilice una tarjeta de crédito para una comida en un restaurante.



               Puede haber imprecisión en los requisitos de software, inconsistencia, omisiones y/o errores. Se tendría que revisar todas los procesos que ocurren antes de llegar a la revisión técnica para saber que se hizo mal, que se pudo haber omitido o donde hay un error que no permite un funcionamiento optimo del sistema a realizar.
              
El indicado para corregir el error son todos aquellas personas que participaron en la recolección de información y requisitos, es decir, toda persona que interactúa con el sistema a construir (Ingenieros de sistemas y clientes).

__________________________________________________________________________________________ 

UNIDAD I

Los requerimientos del software podemos definirlos como la característica, condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Aun que parece simple determinar los requerimientos o requisitos de un software, es un proceso complejo ya que trata de sistematizar un procediendo  con el fin de acortar el riesgo del fracaso en el logro del objetivo por medio de diversas técnicas. En ocasiones dar con estos requerimientos no es tan sencillo por que el cliente que necesita el sistema no tiene una idea clara de que es lo que quiere o que es lo que el software debería tener.

Los requerimientos del software cumplen un papel primordial en el proceso de la creación del software, ya que se basa  en un área fundamental para lo que se desea producir o elaborar. Su principal atribución consiste en la generación de especificaciones análisis y detalles que describan con claridad,  en forma consistente y precisa, el comportamiento del sistema o su proceso por lo que estos requisitos, nos proporcionan un mecanismo apropiado para la elaboración de un software con el fin de minimizar los problemas relacionados al desarrollo de sistemas.

Necesidades, objetivos y actores relacionados con los  requisitos del software

Es necesario y fundamental ya que facilita el entendimiento, la elaboración, diseño y funcionamiento de un sistema para  trabajaran en la solución del mismo  minimizando así  los riesgos asociados en la construcción del software.

El objetivo de los requisitos de software es hacer que los mismos logren un estado óptimo antes de alcanzar la fase de diseño en un proyecto ya que al entender las verdaderas necesidades del proceso disminuyen los conflictos que se pueden presentar en la elaboración del software.

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas teniendo como diversos objetivos
1.       La mejora de la calidad de los productos de software
2.       Aumentar la productividad y trabajo del software.
3.       Facilitar el control del proceso de desarrollo de software.
4.       Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
5.       Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

Los actores relacionados con la elaboración de un software son todas aquellas  las personas, maquinas y proceso involucrados que adicional interactúan con el ambiente que rodea el sistema que se esta desarrollando, teniendo en cuenta que estos actores pueden ser internos o externos.

Importancia de la ingeniería de  requisitos en la práctica

La ingeniería de requisitos en la práctica proporciona un mecanismo completamente apropiado para entender lo que un cliente quiere. Permite analizar las necesidades, ver si es factible buscar soluciones razonables y conseguir una solución única y especifica.

La ingeniería de requisitos nos ayuda a entender mucho mejor un problema. Analizando los procesos del sistema para ir formando detalles y estructuras que nos hacen ver y  comprender que es lo que el  cliente quiere en realidad  y que es lo que el software debe llevar adicional de verificar  cual será el impacto del software y como interactuaran los todos usuario en la construcción el software.

Levantamiento y recolección de requerimientos.

Cuando se estudia una organización, ante la incógnita de conocer todas las interrelaciones (Sobre todo en las personas), que se dan en ella, se recurre al estudio de los procesos de investigacion, que permita estudiar una característica o un conjunto de los procesos que se realizan para poder elaborar el diseño del software.

Entre las técnicas mas utilizadas en la actividades de ingeniería de requisitos se encuentran las entrevistas y los cuestionarios se emplean para reunir informacion proveniente de personas o de grupos, adicional a estas técnicas  también se encuentran técnica JAD  y la FAP que son una metodologías usadas  para definirlos requerimientos y de diseño de la interfaz de usuario. Es un proceso estructurado para la recopilación y negociación de los requerimientos.
A continuación se presentan detalladamente las técnicas JAD Y FAP

Técnica   JAD

* Permite a los usuarios, diseñar sistemas en forma conjunta, en sesiones grupales.
* Promueve la cooperación, el entendimiento y el trabajo grupal entre distintos grupos de usuarios.
Roles del JAD
* Líder de la sesión.
* Representante de los usuarios.
* Especialista.
* Analista.
* Representante de SS.
Líder de Sesión
* Facilitador de JAD.
* Dirige el proceso.
* Facilita el debate y la preparación de documentos.
* Trata con el sponsor de JAD para acordar quién debe asistir las reuniones.
* Acordar la agenda con los participantes.
Plan JAD
El líder de la sesión guía a los participantes a lo largo de ocho tareas predefinidas. Ellas son:
Orientación.
* Definición de requerimientos de alto nivel.
* Límites y alcances del sistema.
* Identificar y estimar tiempos de los Diseños JAD.
* Identificar los participantes de los Diseños JAD.
* Programar días y horarios para los Diseños JAD.
*Acordar los puntos y consideraciones de la documentación a generar del Plan JAD.
Diseño JAD. Sesión de Diseño
*Orientación. Revisión y refinación de los requerimientos y alcance del Plan JAD.
*Desarrollar diagrama de flujo del trabajo.
*Desarrollar descripción del flujo de trabajo.
*Identificar funciones y grupos de datos del sistema.
*Especificar los requerimientos de procesamiento.
*Acordar los puntos y consideraciones de la documentación a generar del Diseño JAD.
Libros de Trabajo
*Formas predefinidas para los grupos, para que sean completadas durante la sesión.
*Formularios de participantes.
*Formularios de resultados.
*Formularios de estimaciones.
*Formularios de salidas por pantalla.
*Formularios de reportes.
*Formularios de descripción de interfaces y de descripción de funciones.
 JAD y el proceso de Requerimientos
*La articulación del concepto de producto, requerimientos, medición de resultados.
*Análisis de problemas.
*Estudios de factibilidad y análisis de opciones de costo-beneficio.
*Análisis y modelado.
*La documentación de requerimientos.
JAD y la comunicación humana
*La identificación de varios puntos de vista.
*La conciliación de los puntos de vista.
*La revisión por parte del usuario de los modelos desarrollados.
*El análisis de los propios problemas del usuario y la identificación de la necesidad de cambio.
Tecnica(FPA)
o      Mide el tamaño del software desde el punto de vista del usuario. Medir la funcionalidad del producto.
o      Es independiente de la tecnología usada para el desarrollo e implementación.
o      Se aplica a partir de los documentos de requerimientos y a lo largo del ciclo de vida del software.
o      Los enfoques para estimar Puntos Función (FunctionPoints - FP) facilitan la estimación temprana de un proyecto de software (costo, esfuerzo, cronograma) cuando los requerimientos no están completamente definidos.
Medición
o      Es una práctica de administración Probada en el tiempo.
o      No se puede administrar lo que no se puede medir.
o      Herramienta para determinar el tamaño del requerimiento, extrapolar la productividad y la calidad.
o      Se mide para entender y mejorar procesos.
Clases de medición
o      Medición: Cuantificación directa.
Estatura de una persona.
Cálculo: Cuantificación indirecta.
A partir de la combinación de medidas se obtiene el valor del atributo de interés.
Ejemplo: medir la velocidad a partir de la distancia y el tiempo.
Medición del Software
o      Se miden las características para saber si los requerimientos son consistentes y completos.
o      Los administradores de proyectos miden procesos y productos para determinar tiempos de entrega y costos.
o      Incluyen las siguientes actividades:
Estimación de costo y esfuerzo.
Medidas de productividad.
Recolección de datos.
Medidas de calidad y confiabilidad.
Complejidad.
Métodos y herramientas.
Beneficios de la medición
o      Entender que está ocurriendo en el desarrollo y mantenimiento para mejorar las relaciones entre actividades.
o      Control de lo que ocurre en el proyecto, para predecir lo que ocurrirá y los cambios a realizar.
o      Mejorar los procesos y productos, aumentando las revisiones del diseño se incrementa la calidad.
Medición del tamaño del sistema
Tamaño del procesamiento de información
o      Entradas
o      Salidas.
o      Otros
Requerimientos técnicos.
o      Performance.
o      Facilidad de uso.
o      otros
Tamaño del sistema desde los requerimientos del usuario
Beneficios del FPA
o      Mejorará la definición de los requerimientos.
o      Comunicar requerimientos funcionales.
o      Estimar esfuerzo, agenda y costos basado en requerimientos.
o      Evaluar la factibilidad de un proyecto.
o      Administrar los cambios.
o      Mejorará el mantenimiento y soporte.
o      Medir la productividad.
o      Verificar la completitud.