SlideShare a Scribd company logo
1 of 18
MATERIA:

            ADMINISTRACION Y ORGANIZACIÓN DE DATOS

                        CATEDRÁTICO:

        LIC. MARIA DE LOS ANGELES MARTINEZ MORALES

                          UNIDAD: 2

                 ROLES Y FUNCIONES DE:

         UN PROYECTO DE DESARROLLO DE UN SISTEMA

UN EQUIPO DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

                  UNA UNIDAD INFORMATICA




                        4TO SEMESTRE

                           EQUIPO:

               FRANCISCO RODRIGUEZ MARISOL.

                 FELICIANO PATRICIO BEATRIZ.

             LORENZO RITA YOLANDA GUADALUPE.




SAN JUAN BAUTISTA TUXTEPEC, OAX., A 12 DE MARZO DEL 2012
Roles y Funciones 2012
                                       ÍNDICE




Introducción………………………………………………………………………………………3

Roles y funciones de un proyecto de desarrollo de un sistema……………………………4

Roles y funciones en un equipo de aseguramiento de la calidad del
software…………………………………………………………………………………………..9

Roles y funciones en una unidad informática……………………………………………....14

Conclusión……………………………………………………………………………..……….17

Referencias……………………………………………………………………………….……18




                                                                           2
Roles y Funciones 2012


                                  INTRODUCCION

Este trabajo de investigación nos hablara sobre los roles y funciones que desempeñan
algunas empresas como en un proyecto de desarrollo de un sistema, la calidad de un
software y en la unidad informática. Así como también veremos la definición de cada
uno de estos temas y nos explica cada una de las funciones y roles.




                                                                                       3
Roles y Funciones 2012

ROLES Y FUNCIONES DE UN PROYECTO DE DESARROLLO DE UN
SISTEMA

EL PROYECTO DE DESARROLLO DE UN SISTEMA

A menos que el proyecto de sistemas sea lo más tradicional o muy básico, los usuarios
no siempre podrán definir sus requerimientos en forma adecuada y precisa o
simplemente no pueden especificar los requerimientos de manera previa, sino que se
deben descubrirlo. Prototipo es un vocablo usado por docentes, profesionales pero a
que proyecto se debe emplear. Este trabajo pretende

a.   Establecer los factores que llevan al uso de los prototipos.
b.   Establecer los propósitos del prototipo
c.   Determinar en que etapa del Desarrollo puedo usar prototipos.
d.   Determinar los roles que desempeña tanto los usuarios como los profesionales
de sistema al usar Prototipos.
e.   Determinar las Ventajas y Desventajas al usar prototipos.

Importancia de Definir su Objetivo
Siempre se debe establecer cual es su objetivo, ya que un prototipo puede ser útil en
diferentes fases del proyecto, por ello su objetivo debe ser claro. Durante la fase
de análisis se usa para obtener los requerimientos del usuario. En la fase de diseño se
usa para ayudar a evaluar muchos aspectos de la implementación seleccionada.

Propósitos del Prototipo
En la fase de Análisis de un proyecto, su principal propósito es obtener y validar los
requerimientos esenciales, manteniendo abiertas, las opciones de implementación. Esto
implica que se debe tomar los comentarios de los usuarios, pero debemos regresar a
sus objetivos para no perder la atención.
En la fase de Diseño, su propósito, basándose en los requerimientos previamente
obtenidos, es mostrar las ventanas, su navegación, interacción, controles y botones al
usuario y obtener una retroalimentación que nos permite mejorar el Diseño de Interfaz.




                                                                                          4
Roles y Funciones 2012
Características de los Prototipos
El proceso de desarrollo y empleo de prototipos tiene las siguientes características:

     El prototipo es una aplicación que funciona
     Los prototipos se crean con rapidez
     Los prototipos evolucionan a través de un proceso iterativo
     Los prototipos tienen un costo bajo de desarrollo




Información Obtenida con el uso del Prototipo
Reacciones Iniciales del Usuario
El profesional de Sistema por medio de la observación, evaluación y la
retroalimentación, obtendrá como reaccionan los usuarios al trabajar con el prototipo, y
que tan conveniente es el acoplamiento entre las necesidades y las características
modeladas en el sistema. A través de la recopilación de tales reacciones, el profesional,
irá descubriendo nuevas perspectivas del prototipo, incluso si los usuarios se
encuentran satisfechos con él, o si habrá dificultades para vender o implantar el
sistema.

Sugerencias
Las sugerencias son el fruto de la relación de los usuarios con el prototipo, las
sugerencias aportadas por el usuario indican al profesional porque caminos dirigirse
para refinar el prototipo, modificarlo o depurarlo, de forma que satisfaga mejor las
necesidades de los usuarios.

Innovaciones
Las innovaciones son aquellas características nuevas del sistema que no fueron
contempladas previamente a la interacción con el prototipo.

Prioridades
La información que se obtiene con el uso de prototipos permite al profesional establecer
prioridades y reorientar sus planes de una manera menos costosas y con un mínimo de
contratiempo.



                                                                                            5
Roles y Funciones 2012
Una de las peores cosas que le puede pasar a un profesional es diseñar e implantar un
sistema que el usuario no necesita, ni desean.



Desarrollo de Prototipo

Problemas Candidatos
Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de
Información, el profesional considera los siguientes factores:

     Problemas no estructurado, novedosos y complejos, de información personalizada
del usuario, ya que sus salidas no son predecibles y definidas
     Problemas de ambiente Inestable, el profesional también debe evaluar el contexto
del sistema
     Experiencia en diseños similares
     No se conocen los requerimientos, la naturaleza del sistema es tal que existe poca
información con respecto a las características que debe tener el nuevo sistema para
satisfacer las necesidades del usuario
     Los requerimientos deben evaluarse, se conocen los requerimientos aparentes de
información pero es necesario verificarlos y evaluarlos
     Costos altos, donde la inversión involucra gran cantidad de recursos financieros y
humanos.
     Altos riesgo, la evaluación inexacta de los requerimientos o el desarrollo incorrecto
ponen en peligro a la organización
     El usuario, donde no está dispuesta examinar modelos en papel, o no sabe lo que
quiere pero lo reconocerá cuando lo vea.
     Tecnologías Nuevas, la falta de experiencia en el uso de dichas tecnologías, junto
con el deseo de instalar nuevas tecnología hace que sea propicio el uso del prototipo.




Roles


                                                                                             6
Roles y Funciones 2012
Rol del Usuario
El papel del usuario con el prototipo puede resumirse en compromiso y honestidad. Si
carece de compromiso pocos son los motivos para desarrollar un prototipo, ya que el
usuario es el pivote del proceso de desarrollo y evaluación. Los usuarios interactuan
con el prototipo teniendo las siguientes responsabilidades:

     Utilizar y evaluar el prototipo las veces que sea necesario
     Identificar mejoras
     Sugerir las característica no deseadas
     Describir los requerimientos de datos
     Describir la salida deseada

Rol del Profesional de Sistema
El papel del profesional de sistema no solo debe contruir el prototipo sino tambien que
debe:

     Crear el clima adecuado al usuario para que este se exprese sin temor alguno
     Familiarizar al usuario con el prototipo
     Crear el plan para el desarrollo del prototipo
     Contruir la versión inicial
     Evaluar las reacciones del usuario y plasmar las modificaciones en una nueva
versión

Ventajas y Desventajas

Existen ventajas relevantes en el uso del Prototipo:

     Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso
del prototipo depende de qué tan pronto y con que frecuencia se reciba la
retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades
actuales. Los cambios iniciales durante el desarrollo de un proyecto son menos
costosos que si se realizan en etapas tardías, como el prototipo puede cambiar varias
veces la flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la
retroalimentación, la cual nos permite conocer la opinión del usuario sobre cambios a la


                                                                                           7
Roles y Funciones 2012
entrada o salida de un proceso, que al evaluarla nos permite obtener los requerimientos
y mejorar el sistema.

El desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre pero
siempre es menor a la del sistema completo. Los problemas y descuidos de sistemas
son más fáciles de detectar en un prototipo.

     Eliminación de sistemas indeseables: Por permitir recopilar información nos
permite eliminar un sistema que no llegó a ser lo que esperaban de él los usuarios. La
inversión de tiempo y dinero se destaca pero es menor que la del sistema completo. Se
toma esta decisión cuando el sistema no es útil o no satisface los objetivos que se
propuso el equipo de desarrollo, es una decisión dificil pero evita seguir gastando dinero
y tiempo en un proyecto inservible.
     Diseño de Sistemas acorde a las necesidades y expectativas de los usuarios: El
uso del prototipo hace que los sistemas se ajusten a las necesidades de los usuarios.
Se reduce el intervalo de tiempo desde que se relevan los requerimientos y el sistema
concluido. Permite que los usuarios se involucren desde el principio y lo hace participar
en forma activa, de esta forma hacen suyo el proyecto, siendo los principales
promotores del éxito.

El prototipo cuenta con las siguientes desventajas:

     Administración dificil: Dicha dificultad radica en manejar el prototipo como un
proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era sus
propósito.
     Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden
considerar al prototipo como el sistema final cuando aún es imcompleto e inadecuado.




                                                                                             8
Roles y Funciones 2012
  ROLES Y FUNCIONES EN UN EQUIPO DE ASEGURAMIENTO DE LA CALIDAD
                                    DEL SOFTWARE

La calidad es el conjunto de propiedades inherentes a una entidad, que permiten juzgar
su valor. Está cuantificada por el valor que se le da al conjunto de propiedades
seleccionadas. De esta manera la calidad es subjetiva y, como dice James Bach, es
circunstancial. Es subjetiva porque depende de los atributos elegidos para medirla y es
circunstancial porque el conjunto de atributos elegidos puede variar en situaciones
diferentes.
Cuando aplicamos el concepto de calidad al software, éste deja de ser subjetivo porque
se determinan cuales son los atributos de calidad del software. Pero no deja de ser
accidental ya que en ciertas situaciones, un determinado conjunto de características de
calidad puede ser más importante que en ciertas otras.
Resumiendo, la calidad del software es medible y varía de un sistema a otro o de un
programa a otro.


Calidad del software
Hablamos todo el tiempo de problemas relacionados con la calidad del software pero no
tenemos una definición precisa de lo que ésta significa. Sin una definición clara, concisa
y medible de lo que es la calidad del software, no podemos tomar buenas decisiones de
negocio respecto del uso de los recursos, ni en que áreas mejorar la calidad, ni que
herramientas y técnicas utilizar para mejorar la calidad.
Hay diferentes puntos de vista para definir calidad de software. Desde el punto de vista
del cumplimiento de los requerimientos Roger Pressman define la calidad de software
como:
“El cumplimiento de los requerimientos funcionales y de performance explícitamente
definidos, de los estándares de desarrollo explícitamente documentados y de las
características implícitas esperadas del desarrollo de software profesional.”




Desde el punto de vista del cliente o usuario Watts Humphrey dice:


                                                                                             9
Roles y Funciones 2012
“El foco principal de cualquier definición de calidad de software debería ser las
necesidades del cliente. Crosby al igual que Pressman define la calidad como
conformidad con los requerimientos. Mientras uno puede discutir la diferencia entre
requerimientos, necesidades y deseos, la definición de calidad debe considerar la
perspectiva de los usuarios. Entonces las preguntas claves son ¿Quiénes son los
usuarios?, ¿Qué es importante para ellos? Y ¿Cómo sus prioridades se relacionan con
la manera en que se construye, empaqueta y se da soporte al producto?”


Al Davis define calidad del software como:
“La calidad no se trata de tener cero defectos o una mejora medible de la proporción de
defectos, no se trata de tener los requerimientos documentados. No es mas ni menos
que satisfacer las necesidades del cliente (por mas que las necesidades estén o no
correctamente documentadas)”


Finalmente, desde estas dos perspectivaspara la ingeniería de software define la
calidad del software como:
“El grado con el cual un sistema, componente o proceso cumple con los requerimientos
y con las necesidades y expectativas del usuario.”
Mas allá de cómo definamos la calidad del software, para que la definición tenga
sentido esta debe ser medible. Para poder controlar la calidad del software es
necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que,
como bien plantea Tom De Marco, "no se puede controlar lo que no se puede medir".


Para poder identificar los costos y beneficios del software se definieron los atributos de
calidad. La intención es separar el software en atributos que puedan ser medidos o
cuantificados (en términos de costo beneficio). Ejemplos de estos atributos son
confiabilidad, adaptabilidad, usabilidad y funcionalidad.


La obtención de un software con calidad implica la utilización de metodologías o
procedimientos estándares para el análisis, diseño, programación y prueba del software
que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad,

                                                                                             10
Roles y Funciones 2012
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la
labor de desarrollo como para el control de la calidad del software.
Cuando no se cumplen los estándares o procesos de la organización o del proyecto se
dice que estamos frente a una no conformidad. Lo esperable es la ausencia de no
conformidades (conformidad)
El costo de conformidad (calidad) no es despreciable pero es menor que el costo de su
alternativa (Costo de no conformidad). Crosby describe el costo de la no conformidad
como aquel costo en el que se incurre porque el producto o servicio no se desarrolló de
forma apropiada la primera vez.
Entonces uno de los propósitos que guían el aseguramiento de la calidad es que es
mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta
que un problema se manifieste a través de las quejas del usuario.


Los principios básicos del concepto de calidad del software son:
1)    No alcanza en pensar en calidad a la hora hacer las revisiones y pruebas sino
quedebe ser una preocupación durante todo el ciclo de vida del software.
2)    Sólo se alcanza con la contribución de todas las personas involucradas.
3)    La calidad debe ser planificada y gestionada con eficacia.
4)    Dirigir esfuerzos a prevención de defectos.
5)    Reforzar los sistemas de detección y eliminación de defectos durante lasprimeras
fases.
6)    La calidad es un parámetro importante del proyecto al mismo nivel que losplazos
de entrega, costo y productividad.
7)    Es esencial la participación de la dirección, que ha de propiciar la calidad.

El rol del SQA es auditar que los distintos equipos de la organización, inclusive el de
SQC siguen los procedimientos, estándares y procesos establecidos. El equipo de SQA
debería establecer métricas para medir la efectividad del proceso. Como complemento
el rol de SQC es tomar una actitud activa de verificación y validación del resultado o
salida del proceso implementado.




                                                                                            11
Roles y Funciones 2012
      Describir los diferentes roles que puede jugar el equipo de SQA en una organización
      nos dará una visión clara de las funciones que puede llevar a cabo.


      “Como policía del proceso”: el trabajo del equipo de SQA es asegurar que el desarrollo
      sigue el proceso establecido. Entre sus funciones en este rol se encuentran:
 I.        Auditar los productos del trabajo para identificar deficiencias.
II.        Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de
      desarrollo de software.
III.       Juzgar el proceso y no el producto.

      “Como abogado del cliente”: el trabajo del equipo de SQA es representar al cliente.
      Entre sus funciones en este rol se encuentran:
      a)   Identificar la funcionalidad que al cliente le gustaría encontrar.
      b)   Ayudar a la organización a sensibilizarse con las necesidades del cliente.
      c)   Actuar como un cliente de prueba para obtener una alta satisfacción delcliente.


      “Como analista” el trabajo del equipo de SQA es recabar información. Entre sus
      funciones en este rol se encuentran:
      1.   Juntar muchos datos sobre todos los aspectos del producto y del proceso.
      2.   Con esta información ayudar a mejorar los procesos y los productos.


      “Como proveedor de información” el trabajo del equipo de SQA es revisar qué es lo que
      esté hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la
      gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este rol
      se encuentran:
      1)   Proveer información técnica objetiva para que la gerencia pueda usarlapara tomar
      mejores decisiones.
      2)   Proveer información apropiada de las clases de productos y de losriesgos
      asociados con estos.
      3)   Concentrarse más en la reducción de los riesgos que en el cumplimientodel
      proceso.


                                                                                               12
Roles y Funciones 2012


“Como responsable de la elaboración del proceso” el trabajo del equipo de SQA es
participar en la definición de los planes, procesos, estándares y procedimientos para
asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para
realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las políticas
de la organización. Para cumplir este rol el aseguramiento de la calidad debería
comenzar en las fases tempranas del proyecto.




                                                                                            13
Roles y Funciones 2012

          ROLES Y FUNCIONES EN UNA UNIDAD INFORMATICA

El centro de documentación es una unidad de información que reúne, gestiona y
difunde la documentación de un área del conocimiento determinado o la producida por
un organismo o institución a la que se circunscribe. Surge para hacer frente a la
explosión documental, principalmente de contenido científico-técnico. Presenta
similitudes con la biblioteca especializada y se caracteriza por profundizar algunas de
sus funciones, en especial el análisis documental de contenido, para lograr una mejor
recuperación de la información, utilizando lasnuevas tecnologías de la información.

En resumen podríamos decir que se trata de unidad de información

especializada adscrita a un organismo (propietario de este centro), donde se
encuentran conservados y almacenados los documentos necesarios para el
funcionamiento de un servicio o una actividad de la propia institución o empresa, y cuya
finalidad es servir de referencia y ayuda a los profesionales o investigadores.

Funciones
Un centro de documentación tiene como funciones seleccionar, analizar, recuperar y
difundir la información. Utiliza las nuevas tecnologías para realizar el tratamiento de la
información y para el acceso en línea a otras bases de datos y documentos
electrónicos.

La Unidad de Informática es una Gestión imprescindible, dada la importancia de las
labores desarrolladas por el IMN, el sistema tan tecnificado con que cuenta para realizar
todos sus trabajos y dar una continuidad a las labores realizadas. Debe contar con
personal informático con disponibilidad de atender y dar soporte a todo el personal,
tanto para oficinas centrales como para aeropuertos todos los días del año.
Por medio de la red interna y la interconexión con Internet, el Instituto Meteorológico
Nacional hace disponible a todo el público los productos obtenidos, cuando se corren
los modelos numéricos, imágenes de satélite, así como las informaciones que ponen a
disposición de los centros de pronósticos como el centro de Huracanes en Miami, la
NOAA, etc., para realizar los pronósticos locales y regionales, especialmente cuando se
suscitan eventos extremos como huracanes, tormentas tropicales, etc. Debido a esto

                                                                                             14
Roles y Funciones 2012
los servicios que brinda la Unidad de Informática deben tener una amplia disponibilidad,
teniendo cuenta niveles de contingencia, operacionalidad, personal debidamente
capacitado y disponibilidad.


Los servicios brindados por dicha unidad de Staff, tienen un alcance local e
internacional, ya que los productos obtenidos y suministrados por los servidores que se
administran, proveen información e imágenes de alta resolución al IMN, diferentes
instituciones locales y a todo Centroamérica.
Funciones principales de la Unidad de Informática
Coordinar las labores pertinentes a la administración y buen funcionamiento de los
servidores y de nuestra red LAN, WAN, Intranet e Internet de las oficinas centrales del
IMN y de las oficinas destacadas en los diferentes Aeropuerto Nacionales e
Internacionales, así como los servicios prestados a las diferentes torres de control de
dichos aeropuertos.
Organizar y coordinar el rol de asistencia a las diferentes emergencias o eventualidades
informáticas que se presentan con todo lo relacionado con la información meteorológica
cedida a las diferentes entidades que necesitan dicha información para su quehacer
diario o en emergencias.
Realizar labores de recuperación, y/o reinstalación de programas, productos o modelos
necesarios      para   que   el   personal   profesional   del   IMN   realice   sus   labores
correspondientes. Esto implica mantener una disposición, dado que somos un ente de
servicio a muchos organismos de emergencias, medios periodísticos, público en
general, etc.
Planear e implementar políticas de seguridad informática para la Institución.
Desarrollar proyectos de análisis, desarrollo e implementación de software para el
quehacer meteorológico y Administrativo.
Mantener y actualizar el sitio Web del IMN
Dar soporte en la programación transmisión de datos y buen funcionamiento de la red
de estaciones meteorológica automáticas ubicadas en todo el país.




                                                                                                 15
Roles y Funciones 2012
Administrar la base de datos climáticos del IMN, la cual tienen datos de más de
100 años en algunas estaciones.




                                                                                  16
Roles y Funciones 2012
                                         CONCLUSION

El profesional de sistema se encuentra ante una excelente técnica de relevamiento de
información,   obteniendo    Reacciones      del   Usuario,   Sugerencias,   Innovaciones,
Prioridades.
Los resultados de un acoplamiento estrecho entre el usuario, el profesional de sistema
y los modelos reducen el vacío entre lo que los usuarios piensan de los sistemas y lo
que realmente obtiene. Al usuario se lo introduce directamente en el desarrollo de
manera que la aplicación se convierta en su proyecto, comunicando mejor sus
requerimientos, reduciendo la habilidad del profesional de sistema en traducir los
requerimientos.

El usuario prueba algo, ve lo que sucede, luego lo modifica, esta interacción
proporciona una retroalimentación instantánea y le permite ver al usuario ver
inmediatamente sus resultados y modificar el modelo tantas veces como sea necesario
antes de su terminación. Los pasos de análisis, diseño y construcción se convinan en
un flujo interactivo que es el paso clave.




                                                                                             17
Roles y Funciones 2012


                                      REFERENCIAS



                BURCH J. G. y GRUDNITSKI G.,1997, Diseño de Sistemas de Información.
Megabyte Noriega Asociados, 985 p.
                KENDALL, K. E. y KENDALL J. E.,1991, Análisis y Diseño de Sistema.
Prentice –Hall Hispanoamericana S.A., 881 p.
                RUBLE,     D.   A.,    1998,   Análisis    y   Diseño    Práctico   de
Sistemas Cliente/Servidor con GUI. Prentice Hall, 514 p.
                SENN, J. A., 1992, Análisis y Diseño de Sistemas de Información. McGraw
–Hill, 942 p.
                YOURDON, E., 1989, Análisis Estructurado Moderno. Prentice –Hall
Hispanoamericana S.A., 735 p.

     http://www.imn.ac.cr/sobreimn/area_informatica.html




                                                                                          18

More Related Content

What's hot

Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónYare LoZada
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del softwareGiovani Ramirez
 
Metodolgias de desarrollo (evolutivo)
Metodolgias de desarrollo (evolutivo)Metodolgias de desarrollo (evolutivo)
Metodolgias de desarrollo (evolutivo)Griiselda Martiinez
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosFranklin Parrales Bravo
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASAlcoverify
 
Especificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de softwareEspecificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de softwareJesús E. CuRias
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMiguel Rodríguez
 
Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Juan C. S. Suárez
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosFranklin Parrales Bravo
 
Ciclo de vida por prototipos
Ciclo de vida por prototiposCiclo de vida por prototipos
Ciclo de vida por prototiposMay Rodriguez
 
Metodología xp
Metodología xpMetodología xp
Metodología xpPiskamen
 
Mobile D (programacion dispositivos moviles)
Mobile D (programacion dispositivos moviles)Mobile D (programacion dispositivos moviles)
Mobile D (programacion dispositivos moviles)David Hernandez
 
Metodología Incremental
Metodología IncrementalMetodología Incremental
Metodología Incrementalandreilouis
 

What's hot (20)

Diseño caso de pruebas
Diseño caso de pruebasDiseño caso de pruebas
Diseño caso de pruebas
 
3. modelos prescriptivos de proceso
3. modelos prescriptivos de proceso3. modelos prescriptivos de proceso
3. modelos prescriptivos de proceso
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del software
 
Metodolgias de desarrollo (evolutivo)
Metodolgias de desarrollo (evolutivo)Metodolgias de desarrollo (evolutivo)
Metodolgias de desarrollo (evolutivo)
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientos
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
 
Especificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de softwareEspecificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de software
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y Emergentes
 
Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software Metodologías tradicionales: Desarrollo de Software
Metodologías tradicionales: Desarrollo de Software
 
Prototipos
PrototiposPrototipos
Prototipos
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitos
 
Ciclo de vida por prototipos
Ciclo de vida por prototiposCiclo de vida por prototipos
Ciclo de vida por prototipos
 
Metodología xp
Metodología xpMetodología xp
Metodología xp
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Mobile D (programacion dispositivos moviles)
Mobile D (programacion dispositivos moviles)Mobile D (programacion dispositivos moviles)
Mobile D (programacion dispositivos moviles)
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Metodología Incremental
Metodología IncrementalMetodología Incremental
Metodología Incremental
 
Metodología ICONIX
Metodología ICONIXMetodología ICONIX
Metodología ICONIX
 

Viewers also liked

037 15 metodologiadelaprendizaje-3
037 15 metodologiadelaprendizaje-3037 15 metodologiadelaprendizaje-3
037 15 metodologiadelaprendizaje-3Sandra Villalobos
 
Enfoque cognositivo
Enfoque cognositivoEnfoque cognositivo
Enfoque cognositivoVERKYTH
 
Preámbulo de la loe
Preámbulo de la loePreámbulo de la loe
Preámbulo de la loedanyeducaT
 
Fundamentos de investigación
Fundamentos de investigaciónFundamentos de investigación
Fundamentos de investigacióntecnologico
 
40 días ayuno. mt 4,1 11
40 días ayuno. mt 4,1 1140 días ayuno. mt 4,1 11
40 días ayuno. mt 4,1 11josezarra
 
La educación en finlandia
La educación en finlandiaLa educación en finlandia
La educación en finlandiaRosa Alfaro
 
Dia del libro 4ºB
Dia del libro 4ºBDia del libro 4ºB
Dia del libro 4ºBguest4b4152
 
Ilusiones Arriba Y Abajo
Ilusiones Arriba Y AbajoIlusiones Arriba Y Abajo
Ilusiones Arriba Y AbajoLorian
 
Explotació infantil marques esportives
Explotació infantil marques esportivesExplotació infantil marques esportives
Explotació infantil marques esportivesEVT
 
Convenio cub ven
Convenio cub venConvenio cub ven
Convenio cub venteiler
 

Viewers also liked (20)

037 15 metodologiadelaprendizaje-3
037 15 metodologiadelaprendizaje-3037 15 metodologiadelaprendizaje-3
037 15 metodologiadelaprendizaje-3
 
Enfoque cognositivo
Enfoque cognositivoEnfoque cognositivo
Enfoque cognositivo
 
Preámbulo de la loe
Preámbulo de la loePreámbulo de la loe
Preámbulo de la loe
 
Fundamentos de investigación
Fundamentos de investigaciónFundamentos de investigación
Fundamentos de investigación
 
Aristo
AristoAristo
Aristo
 
40 días ayuno. mt 4,1 11
40 días ayuno. mt 4,1 1140 días ayuno. mt 4,1 11
40 días ayuno. mt 4,1 11
 
GuíA39 59
GuíA39 59GuíA39 59
GuíA39 59
 
Dot Cvfmggdeltron 2009.Doc
Dot Cvfmggdeltron 2009.DocDot Cvfmggdeltron 2009.Doc
Dot Cvfmggdeltron 2009.Doc
 
La educación en finlandia
La educación en finlandiaLa educación en finlandia
La educación en finlandia
 
Dia del libro 4ºB
Dia del libro 4ºBDia del libro 4ºB
Dia del libro 4ºB
 
Assignment 11
Assignment 11Assignment 11
Assignment 11
 
Ilusiones Arriba Y Abajo
Ilusiones Arriba Y AbajoIlusiones Arriba Y Abajo
Ilusiones Arriba Y Abajo
 
El documento 2
El documento 2El documento 2
El documento 2
 
Posters 0910
Posters 0910Posters 0910
Posters 0910
 
Examen ofimatica i 2011
Examen ofimatica i  2011Examen ofimatica i  2011
Examen ofimatica i 2011
 
Codigo de etica
Codigo de eticaCodigo de etica
Codigo de etica
 
Explotació infantil marques esportives
Explotació infantil marques esportivesExplotació infantil marques esportives
Explotació infantil marques esportives
 
Huawei
HuaweiHuawei
Huawei
 
Convenio cub ven
Convenio cub venConvenio cub ven
Convenio cub ven
 
Padre manjón
Padre manjónPadre manjón
Padre manjón
 

Similar to Roles y funciones...

Similar to Roles y funciones... (20)

Prototipado del software
Prototipado del softwarePrototipado del software
Prototipado del software
 
Prototipado del software
Prototipado del softwarePrototipado del software
Prototipado del software
 
Modelo de prototipo
Modelo de prototipoModelo de prototipo
Modelo de prototipo
 
Expoicioningenieria del software eddy
Expoicioningenieria del software eddyExpoicioningenieria del software eddy
Expoicioningenieria del software eddy
 
Expoicioningenieria del software eddy
Expoicioningenieria del software eddyExpoicioningenieria del software eddy
Expoicioningenieria del software eddy
 
Prototipos
PrototiposPrototipos
Prototipos
 
Presentacion de sistemas
Presentacion de sistemasPresentacion de sistemas
Presentacion de sistemas
 
Prototipos
PrototiposPrototipos
Prototipos
 
Unidad iv alternativas de adquisición de sistemas de
Unidad iv alternativas de adquisición de sistemas deUnidad iv alternativas de adquisición de sistemas de
Unidad iv alternativas de adquisición de sistemas de
 
Presentacion de sistemas
Presentacion de sistemasPresentacion de sistemas
Presentacion de sistemas
 
Manejo de prototipos
Manejo de prototiposManejo de prototipos
Manejo de prototipos
 
Manejo de prototipos
Manejo de prototiposManejo de prototipos
Manejo de prototipos
 
Manejo de prototipos
Manejo de prototiposManejo de prototipos
Manejo de prototipos
 
Manejo de prototipos
Manejo de prototiposManejo de prototipos
Manejo de prototipos
 
Modelo de prototipos
Modelo de prototiposModelo de prototipos
Modelo de prototipos
 
Sistemas De Informacion IV
Sistemas De Informacion IVSistemas De Informacion IV
Sistemas De Informacion IV
 
metodologia de prototipos
metodologia de prototiposmetodologia de prototipos
metodologia de prototipos
 
Sistemas Unidad IV
Sistemas Unidad IVSistemas Unidad IV
Sistemas Unidad IV
 
Manejodeprototipos 111015092536-phpapp02
Manejodeprototipos 111015092536-phpapp02Manejodeprototipos 111015092536-phpapp02
Manejodeprototipos 111015092536-phpapp02
 
Ciclo de vida_clasicos_y_paradigma_tradicional_de
Ciclo de vida_clasicos_y_paradigma_tradicional_deCiclo de vida_clasicos_y_paradigma_tradicional_de
Ciclo de vida_clasicos_y_paradigma_tradicional_de
 

More from yolanda guadalupe (20)

Proyecto yolgua-control
Proyecto yolgua-controlProyecto yolgua-control
Proyecto yolgua-control
 
Proyecto yolgua-control
Proyecto yolgua-controlProyecto yolgua-control
Proyecto yolgua-control
 
Evaluacion de proyectos evidencia 7
Evaluacion de proyectos evidencia 7Evaluacion de proyectos evidencia 7
Evaluacion de proyectos evidencia 7
 
Evaluacion de proyectos evidencia 7
Evaluacion de proyectos evidencia 7Evaluacion de proyectos evidencia 7
Evaluacion de proyectos evidencia 7
 
Evidencia 6
Evidencia 6Evidencia 6
Evidencia 6
 
Proyecto yolgua
Proyecto yolguaProyecto yolgua
Proyecto yolgua
 
Planificacion de accion
Planificacion de accionPlanificacion de accion
Planificacion de accion
 
Planificacion de accion
Planificacion de accionPlanificacion de accion
Planificacion de accion
 
Presentacion consultoria
Presentacion consultoriaPresentacion consultoria
Presentacion consultoria
 
Propuesta de curso en línea para la formación de competencias docentes del i...
Propuesta de curso en línea  para la formación de competencias docentes del i...Propuesta de curso en línea  para la formación de competencias docentes del i...
Propuesta de curso en línea para la formación de competencias docentes del i...
 
Mandato del proyecto
Mandato del proyectoMandato del proyecto
Mandato del proyecto
 
Unidad3
Unidad3Unidad3
Unidad3
 
Unidad3
Unidad3Unidad3
Unidad3
 
Unidad3
Unidad3Unidad3
Unidad3
 
Slide1
Slide1Slide1
Slide1
 
Proyecto
ProyectoProyecto
Proyecto
 
Resumen
ResumenResumen
Resumen
 
Lecturas1
Lecturas1Lecturas1
Lecturas1
 
Cuadro coparativo tipos de investigacion
Cuadro coparativo tipos de investigacionCuadro coparativo tipos de investigacion
Cuadro coparativo tipos de investigacion
 
Fortalezas
FortalezasFortalezas
Fortalezas
 

Roles y funciones...

  • 1. MATERIA: ADMINISTRACION Y ORGANIZACIÓN DE DATOS CATEDRÁTICO: LIC. MARIA DE LOS ANGELES MARTINEZ MORALES UNIDAD: 2 ROLES Y FUNCIONES DE: UN PROYECTO DE DESARROLLO DE UN SISTEMA UN EQUIPO DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE UNA UNIDAD INFORMATICA 4TO SEMESTRE EQUIPO: FRANCISCO RODRIGUEZ MARISOL. FELICIANO PATRICIO BEATRIZ. LORENZO RITA YOLANDA GUADALUPE. SAN JUAN BAUTISTA TUXTEPEC, OAX., A 12 DE MARZO DEL 2012
  • 2. Roles y Funciones 2012 ÍNDICE Introducción………………………………………………………………………………………3 Roles y funciones de un proyecto de desarrollo de un sistema……………………………4 Roles y funciones en un equipo de aseguramiento de la calidad del software…………………………………………………………………………………………..9 Roles y funciones en una unidad informática……………………………………………....14 Conclusión……………………………………………………………………………..……….17 Referencias……………………………………………………………………………….……18 2
  • 3. Roles y Funciones 2012 INTRODUCCION Este trabajo de investigación nos hablara sobre los roles y funciones que desempeñan algunas empresas como en un proyecto de desarrollo de un sistema, la calidad de un software y en la unidad informática. Así como también veremos la definición de cada uno de estos temas y nos explica cada una de las funciones y roles. 3
  • 4. Roles y Funciones 2012 ROLES Y FUNCIONES DE UN PROYECTO DE DESARROLLO DE UN SISTEMA EL PROYECTO DE DESARROLLO DE UN SISTEMA A menos que el proyecto de sistemas sea lo más tradicional o muy básico, los usuarios no siempre podrán definir sus requerimientos en forma adecuada y precisa o simplemente no pueden especificar los requerimientos de manera previa, sino que se deben descubrirlo. Prototipo es un vocablo usado por docentes, profesionales pero a que proyecto se debe emplear. Este trabajo pretende a. Establecer los factores que llevan al uso de los prototipos. b. Establecer los propósitos del prototipo c. Determinar en que etapa del Desarrollo puedo usar prototipos. d. Determinar los roles que desempeña tanto los usuarios como los profesionales de sistema al usar Prototipos. e. Determinar las Ventajas y Desventajas al usar prototipos. Importancia de Definir su Objetivo Siempre se debe establecer cual es su objetivo, ya que un prototipo puede ser útil en diferentes fases del proyecto, por ello su objetivo debe ser claro. Durante la fase de análisis se usa para obtener los requerimientos del usuario. En la fase de diseño se usa para ayudar a evaluar muchos aspectos de la implementación seleccionada. Propósitos del Prototipo En la fase de Análisis de un proyecto, su principal propósito es obtener y validar los requerimientos esenciales, manteniendo abiertas, las opciones de implementación. Esto implica que se debe tomar los comentarios de los usuarios, pero debemos regresar a sus objetivos para no perder la atención. En la fase de Diseño, su propósito, basándose en los requerimientos previamente obtenidos, es mostrar las ventanas, su navegación, interacción, controles y botones al usuario y obtener una retroalimentación que nos permite mejorar el Diseño de Interfaz. 4
  • 5. Roles y Funciones 2012 Características de los Prototipos El proceso de desarrollo y empleo de prototipos tiene las siguientes características: El prototipo es una aplicación que funciona Los prototipos se crean con rapidez Los prototipos evolucionan a través de un proceso iterativo Los prototipos tienen un costo bajo de desarrollo Información Obtenida con el uso del Prototipo Reacciones Iniciales del Usuario El profesional de Sistema por medio de la observación, evaluación y la retroalimentación, obtendrá como reaccionan los usuarios al trabajar con el prototipo, y que tan conveniente es el acoplamiento entre las necesidades y las características modeladas en el sistema. A través de la recopilación de tales reacciones, el profesional, irá descubriendo nuevas perspectivas del prototipo, incluso si los usuarios se encuentran satisfechos con él, o si habrá dificultades para vender o implantar el sistema. Sugerencias Las sugerencias son el fruto de la relación de los usuarios con el prototipo, las sugerencias aportadas por el usuario indican al profesional porque caminos dirigirse para refinar el prototipo, modificarlo o depurarlo, de forma que satisfaga mejor las necesidades de los usuarios. Innovaciones Las innovaciones son aquellas características nuevas del sistema que no fueron contempladas previamente a la interacción con el prototipo. Prioridades La información que se obtiene con el uso de prototipos permite al profesional establecer prioridades y reorientar sus planes de una manera menos costosas y con un mínimo de contratiempo. 5
  • 6. Roles y Funciones 2012 Una de las peores cosas que le puede pasar a un profesional es diseñar e implantar un sistema que el usuario no necesita, ni desean. Desarrollo de Prototipo Problemas Candidatos Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Información, el profesional considera los siguientes factores: Problemas no estructurado, novedosos y complejos, de información personalizada del usuario, ya que sus salidas no son predecibles y definidas Problemas de ambiente Inestable, el profesional también debe evaluar el contexto del sistema Experiencia en diseños similares No se conocen los requerimientos, la naturaleza del sistema es tal que existe poca información con respecto a las características que debe tener el nuevo sistema para satisfacer las necesidades del usuario Los requerimientos deben evaluarse, se conocen los requerimientos aparentes de información pero es necesario verificarlos y evaluarlos Costos altos, donde la inversión involucra gran cantidad de recursos financieros y humanos. Altos riesgo, la evaluación inexacta de los requerimientos o el desarrollo incorrecto ponen en peligro a la organización El usuario, donde no está dispuesta examinar modelos en papel, o no sabe lo que quiere pero lo reconocerá cuando lo vea. Tecnologías Nuevas, la falta de experiencia en el uso de dichas tecnologías, junto con el deseo de instalar nuevas tecnología hace que sea propicio el uso del prototipo. Roles 6
  • 7. Roles y Funciones 2012 Rol del Usuario El papel del usuario con el prototipo puede resumirse en compromiso y honestidad. Si carece de compromiso pocos son los motivos para desarrollar un prototipo, ya que el usuario es el pivote del proceso de desarrollo y evaluación. Los usuarios interactuan con el prototipo teniendo las siguientes responsabilidades: Utilizar y evaluar el prototipo las veces que sea necesario Identificar mejoras Sugerir las característica no deseadas Describir los requerimientos de datos Describir la salida deseada Rol del Profesional de Sistema El papel del profesional de sistema no solo debe contruir el prototipo sino tambien que debe: Crear el clima adecuado al usuario para que este se exprese sin temor alguno Familiarizar al usuario con el prototipo Crear el plan para el desarrollo del prototipo Contruir la versión inicial Evaluar las reacciones del usuario y plasmar las modificaciones en una nueva versión Ventajas y Desventajas Existen ventajas relevantes en el uso del Prototipo: Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso del prototipo depende de qué tan pronto y con que frecuencia se reciba la retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades actuales. Los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizan en etapas tardías, como el prototipo puede cambiar varias veces la flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la retroalimentación, la cual nos permite conocer la opinión del usuario sobre cambios a la 7
  • 8. Roles y Funciones 2012 entrada o salida de un proceso, que al evaluarla nos permite obtener los requerimientos y mejorar el sistema. El desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre pero siempre es menor a la del sistema completo. Los problemas y descuidos de sistemas son más fáciles de detectar en un prototipo. Eliminación de sistemas indeseables: Por permitir recopilar información nos permite eliminar un sistema que no llegó a ser lo que esperaban de él los usuarios. La inversión de tiempo y dinero se destaca pero es menor que la del sistema completo. Se toma esta decisión cuando el sistema no es útil o no satisface los objetivos que se propuso el equipo de desarrollo, es una decisión dificil pero evita seguir gastando dinero y tiempo en un proyecto inservible. Diseño de Sistemas acorde a las necesidades y expectativas de los usuarios: El uso del prototipo hace que los sistemas se ajusten a las necesidades de los usuarios. Se reduce el intervalo de tiempo desde que se relevan los requerimientos y el sistema concluido. Permite que los usuarios se involucren desde el principio y lo hace participar en forma activa, de esta forma hacen suyo el proyecto, siendo los principales promotores del éxito. El prototipo cuenta con las siguientes desventajas: Administración dificil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era sus propósito. Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar al prototipo como el sistema final cuando aún es imcompleto e inadecuado. 8
  • 9. Roles y Funciones 2012 ROLES Y FUNCIONES EN UN EQUIPO DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE La calidad es el conjunto de propiedades inherentes a una entidad, que permiten juzgar su valor. Está cuantificada por el valor que se le da al conjunto de propiedades seleccionadas. De esta manera la calidad es subjetiva y, como dice James Bach, es circunstancial. Es subjetiva porque depende de los atributos elegidos para medirla y es circunstancial porque el conjunto de atributos elegidos puede variar en situaciones diferentes. Cuando aplicamos el concepto de calidad al software, éste deja de ser subjetivo porque se determinan cuales son los atributos de calidad del software. Pero no deja de ser accidental ya que en ciertas situaciones, un determinado conjunto de características de calidad puede ser más importante que en ciertas otras. Resumiendo, la calidad del software es medible y varía de un sistema a otro o de un programa a otro. Calidad del software Hablamos todo el tiempo de problemas relacionados con la calidad del software pero no tenemos una definición precisa de lo que ésta significa. Sin una definición clara, concisa y medible de lo que es la calidad del software, no podemos tomar buenas decisiones de negocio respecto del uso de los recursos, ni en que áreas mejorar la calidad, ni que herramientas y técnicas utilizar para mejorar la calidad. Hay diferentes puntos de vista para definir calidad de software. Desde el punto de vista del cumplimiento de los requerimientos Roger Pressman define la calidad de software como: “El cumplimiento de los requerimientos funcionales y de performance explícitamente definidos, de los estándares de desarrollo explícitamente documentados y de las características implícitas esperadas del desarrollo de software profesional.” Desde el punto de vista del cliente o usuario Watts Humphrey dice: 9
  • 10. Roles y Funciones 2012 “El foco principal de cualquier definición de calidad de software debería ser las necesidades del cliente. Crosby al igual que Pressman define la calidad como conformidad con los requerimientos. Mientras uno puede discutir la diferencia entre requerimientos, necesidades y deseos, la definición de calidad debe considerar la perspectiva de los usuarios. Entonces las preguntas claves son ¿Quiénes son los usuarios?, ¿Qué es importante para ellos? Y ¿Cómo sus prioridades se relacionan con la manera en que se construye, empaqueta y se da soporte al producto?” Al Davis define calidad del software como: “La calidad no se trata de tener cero defectos o una mejora medible de la proporción de defectos, no se trata de tener los requerimientos documentados. No es mas ni menos que satisfacer las necesidades del cliente (por mas que las necesidades estén o no correctamente documentadas)” Finalmente, desde estas dos perspectivaspara la ingeniería de software define la calidad del software como: “El grado con el cual un sistema, componente o proceso cumple con los requerimientos y con las necesidades y expectativas del usuario.” Mas allá de cómo definamos la calidad del software, para que la definición tenga sentido esta debe ser medible. Para poder controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "no se puede controlar lo que no se puede medir". Para poder identificar los costos y beneficios del software se definieron los atributos de calidad. La intención es separar el software en atributos que puedan ser medidos o cuantificados (en términos de costo beneficio). Ejemplos de estos atributos son confiabilidad, adaptabilidad, usabilidad y funcionalidad. La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, 10
  • 11. Roles y Funciones 2012 mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Cuando no se cumplen los estándares o procesos de la organización o del proyecto se dice que estamos frente a una no conformidad. Lo esperable es la ausencia de no conformidades (conformidad) El costo de conformidad (calidad) no es despreciable pero es menor que el costo de su alternativa (Costo de no conformidad). Crosby describe el costo de la no conformidad como aquel costo en el que se incurre porque el producto o servicio no se desarrolló de forma apropiada la primera vez. Entonces uno de los propósitos que guían el aseguramiento de la calidad es que es mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta que un problema se manifieste a través de las quejas del usuario. Los principios básicos del concepto de calidad del software son: 1) No alcanza en pensar en calidad a la hora hacer las revisiones y pruebas sino quedebe ser una preocupación durante todo el ciclo de vida del software. 2) Sólo se alcanza con la contribución de todas las personas involucradas. 3) La calidad debe ser planificada y gestionada con eficacia. 4) Dirigir esfuerzos a prevención de defectos. 5) Reforzar los sistemas de detección y eliminación de defectos durante lasprimeras fases. 6) La calidad es un parámetro importante del proyecto al mismo nivel que losplazos de entrega, costo y productividad. 7) Es esencial la participación de la dirección, que ha de propiciar la calidad. El rol del SQA es auditar que los distintos equipos de la organización, inclusive el de SQC siguen los procedimientos, estándares y procesos establecidos. El equipo de SQA debería establecer métricas para medir la efectividad del proceso. Como complemento el rol de SQC es tomar una actitud activa de verificación y validación del resultado o salida del proceso implementado. 11
  • 12. Roles y Funciones 2012 Describir los diferentes roles que puede jugar el equipo de SQA en una organización nos dará una visión clara de las funciones que puede llevar a cabo. “Como policía del proceso”: el trabajo del equipo de SQA es asegurar que el desarrollo sigue el proceso establecido. Entre sus funciones en este rol se encuentran: I. Auditar los productos del trabajo para identificar deficiencias. II. Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de desarrollo de software. III. Juzgar el proceso y no el producto. “Como abogado del cliente”: el trabajo del equipo de SQA es representar al cliente. Entre sus funciones en este rol se encuentran: a) Identificar la funcionalidad que al cliente le gustaría encontrar. b) Ayudar a la organización a sensibilizarse con las necesidades del cliente. c) Actuar como un cliente de prueba para obtener una alta satisfacción delcliente. “Como analista” el trabajo del equipo de SQA es recabar información. Entre sus funciones en este rol se encuentran: 1. Juntar muchos datos sobre todos los aspectos del producto y del proceso. 2. Con esta información ayudar a mejorar los procesos y los productos. “Como proveedor de información” el trabajo del equipo de SQA es revisar qué es lo que esté hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este rol se encuentran: 1) Proveer información técnica objetiva para que la gerencia pueda usarlapara tomar mejores decisiones. 2) Proveer información apropiada de las clases de productos y de losriesgos asociados con estos. 3) Concentrarse más en la reducción de los riesgos que en el cumplimientodel proceso. 12
  • 13. Roles y Funciones 2012 “Como responsable de la elaboración del proceso” el trabajo del equipo de SQA es participar en la definición de los planes, procesos, estándares y procedimientos para asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las políticas de la organización. Para cumplir este rol el aseguramiento de la calidad debería comenzar en las fases tempranas del proyecto. 13
  • 14. Roles y Funciones 2012 ROLES Y FUNCIONES EN UNA UNIDAD INFORMATICA El centro de documentación es una unidad de información que reúne, gestiona y difunde la documentación de un área del conocimiento determinado o la producida por un organismo o institución a la que se circunscribe. Surge para hacer frente a la explosión documental, principalmente de contenido científico-técnico. Presenta similitudes con la biblioteca especializada y se caracteriza por profundizar algunas de sus funciones, en especial el análisis documental de contenido, para lograr una mejor recuperación de la información, utilizando lasnuevas tecnologías de la información. En resumen podríamos decir que se trata de unidad de información especializada adscrita a un organismo (propietario de este centro), donde se encuentran conservados y almacenados los documentos necesarios para el funcionamiento de un servicio o una actividad de la propia institución o empresa, y cuya finalidad es servir de referencia y ayuda a los profesionales o investigadores. Funciones Un centro de documentación tiene como funciones seleccionar, analizar, recuperar y difundir la información. Utiliza las nuevas tecnologías para realizar el tratamiento de la información y para el acceso en línea a otras bases de datos y documentos electrónicos. La Unidad de Informática es una Gestión imprescindible, dada la importancia de las labores desarrolladas por el IMN, el sistema tan tecnificado con que cuenta para realizar todos sus trabajos y dar una continuidad a las labores realizadas. Debe contar con personal informático con disponibilidad de atender y dar soporte a todo el personal, tanto para oficinas centrales como para aeropuertos todos los días del año. Por medio de la red interna y la interconexión con Internet, el Instituto Meteorológico Nacional hace disponible a todo el público los productos obtenidos, cuando se corren los modelos numéricos, imágenes de satélite, así como las informaciones que ponen a disposición de los centros de pronósticos como el centro de Huracanes en Miami, la NOAA, etc., para realizar los pronósticos locales y regionales, especialmente cuando se suscitan eventos extremos como huracanes, tormentas tropicales, etc. Debido a esto 14
  • 15. Roles y Funciones 2012 los servicios que brinda la Unidad de Informática deben tener una amplia disponibilidad, teniendo cuenta niveles de contingencia, operacionalidad, personal debidamente capacitado y disponibilidad. Los servicios brindados por dicha unidad de Staff, tienen un alcance local e internacional, ya que los productos obtenidos y suministrados por los servidores que se administran, proveen información e imágenes de alta resolución al IMN, diferentes instituciones locales y a todo Centroamérica. Funciones principales de la Unidad de Informática Coordinar las labores pertinentes a la administración y buen funcionamiento de los servidores y de nuestra red LAN, WAN, Intranet e Internet de las oficinas centrales del IMN y de las oficinas destacadas en los diferentes Aeropuerto Nacionales e Internacionales, así como los servicios prestados a las diferentes torres de control de dichos aeropuertos. Organizar y coordinar el rol de asistencia a las diferentes emergencias o eventualidades informáticas que se presentan con todo lo relacionado con la información meteorológica cedida a las diferentes entidades que necesitan dicha información para su quehacer diario o en emergencias. Realizar labores de recuperación, y/o reinstalación de programas, productos o modelos necesarios para que el personal profesional del IMN realice sus labores correspondientes. Esto implica mantener una disposición, dado que somos un ente de servicio a muchos organismos de emergencias, medios periodísticos, público en general, etc. Planear e implementar políticas de seguridad informática para la Institución. Desarrollar proyectos de análisis, desarrollo e implementación de software para el quehacer meteorológico y Administrativo. Mantener y actualizar el sitio Web del IMN Dar soporte en la programación transmisión de datos y buen funcionamiento de la red de estaciones meteorológica automáticas ubicadas en todo el país. 15
  • 16. Roles y Funciones 2012 Administrar la base de datos climáticos del IMN, la cual tienen datos de más de 100 años en algunas estaciones. 16
  • 17. Roles y Funciones 2012 CONCLUSION El profesional de sistema se encuentra ante una excelente técnica de relevamiento de información, obteniendo Reacciones del Usuario, Sugerencias, Innovaciones, Prioridades. Los resultados de un acoplamiento estrecho entre el usuario, el profesional de sistema y los modelos reducen el vacío entre lo que los usuarios piensan de los sistemas y lo que realmente obtiene. Al usuario se lo introduce directamente en el desarrollo de manera que la aplicación se convierta en su proyecto, comunicando mejor sus requerimientos, reduciendo la habilidad del profesional de sistema en traducir los requerimientos. El usuario prueba algo, ve lo que sucede, luego lo modifica, esta interacción proporciona una retroalimentación instantánea y le permite ver al usuario ver inmediatamente sus resultados y modificar el modelo tantas veces como sea necesario antes de su terminación. Los pasos de análisis, diseño y construcción se convinan en un flujo interactivo que es el paso clave. 17
  • 18. Roles y Funciones 2012 REFERENCIAS BURCH J. G. y GRUDNITSKI G.,1997, Diseño de Sistemas de Información. Megabyte Noriega Asociados, 985 p. KENDALL, K. E. y KENDALL J. E.,1991, Análisis y Diseño de Sistema. Prentice –Hall Hispanoamericana S.A., 881 p. RUBLE, D. A., 1998, Análisis y Diseño Práctico de Sistemas Cliente/Servidor con GUI. Prentice Hall, 514 p. SENN, J. A., 1992, Análisis y Diseño de Sistemas de Información. McGraw –Hill, 942 p. YOURDON, E., 1989, Análisis Estructurado Moderno. Prentice –Hall Hispanoamericana S.A., 735 p. http://www.imn.ac.cr/sobreimn/area_informatica.html 18