ACTUALIZACIÓN:

Más de cuatro años después, esta es la entrada más comentada del blog de Oposiciones TIC, aunque se ha desviado mucho del tema original: la convocatoria de unas oposiciones a un cuerpo de la Junta de A, convirtiéndose en el eterno debate sobre competencias de Ingenieros en Informática vs Ingenieros en Telecomunicaciones.

La verdad es que esa batalla en la Junta está totalmente ganada para los Ingenieros de Telecomunicaciones. Partimos de una injusticia en sí (que el cuerpo de Ing. en Telecomunicación tenga requisito de titulación, mientras que el de Informática no), que se ha trasladado, una vez dentro de la Junta, a los requisitos para poder cubrir ciertas plazas (prácticamente todas las plazas de la Dirección General de Telecomunicaciones y Sociedad de la Información están reservadas a Ingenieros en Telecomunicación, de forma que se han "apropiado" de la competencia sobre Sociedad de la Información). De hecho, el poder del lobby es tal, que hay numerosísimos casos de Directores Generales que son Ingenieros en Telecomunicación (dejamos para otra entrada una enumeración de los mismos), mientras que en el otro lado serían meras excepciones.



=========================================
En el Boletín Oficial de la Junta de Andalucía número 138, de 15 de Julio de 2011 se ha publicado la convocatoria del proceso selectivo, por el sistema de acceso libre, para el ingreso en el Cuerpo Superior Facultativo,opción Ingeniería de Telecomunicaciones (A1.2026), correspondiente a la Oferta de Empleo Público 2010.

El plazo para la presentación de solicitudes acaba el día 8 de Agosto, así que todavía os encontráis a tiempo de presentar la solicitud.

La principal novedad respecto de otros años está en que se introduce un nuevo ejercicio que consistirá en desarrollar por escrito, durante un tiempo máximo de 3 horas, dos temas de entre los comprendidos en el Programa del Anexo II de esta Resolución: un tema del Temario Común de materias elegido por cada aspirante de entre tres extraídos al azar, y un tema del Temario Específico de materias, elegido por cada aspirante de entre tres extraídos al azar.

Para la preparación de este nuevo exámen, os será de utilidad la sección "Exámen de desarrollo" de este blog, así como la sección de cálculo de probabilidades de que te caigan los temas estudiados en función del número de temas a escoger al azar.



Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.

Más sobre sueldos

En el excelente blog Administración 2.0 se ha publicado un excelente post: "Cuanto ganan los funcionarios en España",cuya información entiendo que complementa perfectamente los dos posts publicados en este blog con anterioridad: el sueldo de un funcionario TIC y el sueLdo de un funcionario TIC - II, en el que resumía los datos aportados en el primer post, e introducía otros factores a tener en cuenta, como el coste de la vida en la ciudad de destino.

El post de Administración 2.0 expone los datos publicados en el BOE (y que cambian anualmente, todos los años para bien, veremos a ver si este año con la crisis no lo hacen para mal) como son las retribuciones básicas, o el complemento de destino, que viene vinculado al nivel del puesto.

Me parece muy interesante comparar los ejemplos expuestos en mi primer post con los expuestos en el post de Administración 2.0:

Un auxiliar administrativo (subgrupo C2) de la última promoción, nivel 14, sin productividad, soltero y sin hijos:
Sueldo base: 598,95 €
Complemento de destino: 320,09 €
Complemento específico: 211,12 €
Antiguedad: 0 €
Productividad: 0 €
Retención IRPF (8,47%): -95,72 €
Cuota Muface: -22,16 €
Cuota Derechos Pasivos: -50,61 €
Total neto: 961,67 €/mes

Un titulado medio (subgrupo A2), nivel 22, con 2 trienios, con 2 tardes a la semana, casado y con 1 hijo:
Sueldo base: 982,64 €
Complemento de destino: 535,06 €
Complemento específico: 342,83 €
Antiguedad: 71,24 €
Productividad: 200 €
Retención IRPF (15,64%): -333,41 €
Cuota Muface: -36,47 €
Cuota Derechos Pasivos: -83,30 €
Total neto: 1678,59 €/mes

Un jefe de área (subgrupo A1), nivel 28, con 5 trienios, 4 tardes a la semana, casado y con 2 hijos:
Sueldo base: 1.157,82 €
Complemento de destino: 873,58 €
Complemento específico: 1024,37 €
Antiguedad: 222,55 €
Productividad: 500 €
Retención IRPF (22,22%): -839,54 €
Cuota Muface: -46,34 €
Cuota Derechos Pasivos: -105,84 €
Total neto: 2786,60€ / mes
Está claro que quien decide preparar una oposición no lo hace por dinero. La motivación que hace falta para recorrer el duro camino de opositar no se consigue solo pensando en alcanzar un determinado nivel retributivo. Además, no nos engañemos, si lo que buscas es ganar dinero te has equivocado de camino. En mi opinión, para alcanzar esa meta el camino a seguir -no menos duro, por cierto- es el de ser emprendedor (porque trabajando por cuenta ajena, no nos engañemos, por muy bien que te paguen el dinero lo ganarán especialmente otros). Ahora bien, sí es cierto que el trabajo de funcionario te permite alcanzar un adecuado equilibro entre retribución, seguridad y estabilidad, independencia de pensamiento, autonomía y calidad de vida.

No obstante, una pregunta típica de aquel que se plantea opositar, sobretodo si tiene un puesto de trabajo en la empresa privada es ¿Cuanto gana un funcionario TIC?
Es lógico y natural que quieras saber una de las variables de la ecuación que con tanto esfuerzo e interés estás tratando de resolver, la ecuación de ser funcionario.

Las retribuciones de un funcionario vienen establecidas por el Estatuto Básico del Empleado Público (EBEP)(y antes de éste, por la legislacíon vigente con carácter básico sobre función pública en el estado español). Estas retribuciones se actualizan anualmente en el BOE, pues deben incluir las revisiones anuales salariales pactadas con los sindicatos. Los conceptos retributivos considerados por el EBEP son:


  • Retribuciones básicas: sueldo y trienios

  • Retribuciones complementarias: el EBEP dice que cada Administración deberá desarrollar una ley que las establezca, para premiar el esfuerzo, dificultad, dedicación etc del puesto desarrollado. Como esto todavía no ha sucedido, se siguen aplicando las de la ley anterior: complemento de destino y complemento específico

Os preguntareis ¿qué es eso del complemento de destino? Es una cantidad del salario que depende del nivel de la plaza que desempeña un funcionario. A más nivel, más complemento. Es decir, el complemento de destino de un nivel 30 (subdirector general) evidentemente será mucho más alto que el de un funcionario de nivel 12 (auxiliar administrativo). Puede haber más de 10.000 euros de diferencia entre uno y otro.

¿Y el complemento específico? En este caso, lo que se trata de retribuir es la dificultad o penosidad concreta de un puesto de trabajo concreto (por eso lo de "específico"). Este es el factor de más peso en el nivel retributivo de un funcionario. Como veremos con algunos ejemplos, dos funcionarios de igual grupo y prácticamente igual nivel pueden tener grandes diferencias salariales por este complemento. Un funcionario de nivel 30 puede tener más de 20000 euros de complemento específico, por los 2000 euros de un funcionario de nivel 14.

Llegados a este punto, posiblemente sigais sin tener claro cuanto gana un funcionario TIC. Al fin y al cabo, esto de los complementos está muy bien, pero uno lo que entiende de verdad es lo que le llega al bolsillo mes a mes (o en todo caso, una cantidad bruta anual). A continuación os pongo los niveles retributivos de algunas plazas TIC de las dos administraciones de las que tengo más conocimiento: Administración General del Estado y Junta de Andalucía. Como vereis, hay importantes diferencias retributivas entre una administración y otra. Si conoceis de más casos (otras administraciones autonómicas, diputaciones, ayuntamientos) por favor, hacednoslo llegar a través de los comentarios de esta entrada o al correo info@oposicionestic.es

Comunidad Autónoma Andaluza.Fuente: relación de puestos de trabajo de la Consejería de Presidencia. Web del empleado público.

Grupo A1
coordinador/subdirector 30
jefe de servicio de informatica nivel 28 complemento especifico 20.961
adjunto al jefe de servicio 27 18.867,96
departamento de desarrollo y mantenim. 26 15.738,00
titulado superior 22 5300

Grupos A1/A2
tecnico de sistemas 25 15008,40
jefe de proyecto 25 13263,40
asesor tecnico 25 12905
analista funcional 23 9500
titulado medio 18 5038

Grupos A2/C1
asesor tecnico microinformatica 20 8787
programador 20 8787
ayudante tecnico 15 4500

C1/C2
operador de consola 16 7800
grabador de datos 15 5400


Hablando en sueldo neto mensual, un Coordinador (N30) viene a ganar unos 3100 euros al mes. Un jefe de servicio de informática (N28) en torno a los 2800 euros, y un adjunto/jefe de gabinete (N27) unos 2600. Un jefe de departamento (N26) sobre los 2400, y un técnico de sistemas (N25) unos 2300 si es grupo A1, y en torno a los 2100 si es grupo A2. Un analista funcional (N23) viene a ganar unos 1850 euros si es grupo A1, y 1700 euros si es grupo A2. Un titulado superior (grupo A1 base, N22) gana sobre los 1600 euros al mes y un titulado de grado medio (grupo A2 básico, N18) en torno a 1400 euros al mes. Un ayudante técnico (C1 N15) gana unos 1200 euros largos, pudiendo desempeñar puestos de analista funcional (1600 euros largos).


Administración General del Estado. Fuente: nombramientos en el BOE tanto para nuevo ingreso como para concursos de provisión de puestos.

B
5.793,90 ANALISTA PROGRAMADOR NIVEL 18
7074,00 TECNICO GRADO MEDIO 18
4100,00 TECNICO N18 NIVEL 18
5793 TECNICO DE REDES INFORMATICAS NIVEL 18

A
10964,00 26 TECNICO SUPERIOR PROYECTO INFORMATICO
13564,00 26 TECNICO SUPERIOR INFORMATICO ENTRADA AEAT

25536,00 30 jefe de unidad informatica en muface
20,500 29 adjunto jefe de ud. informatica

C
4730,00 17 PROGRAMADOR DE PRIMERA
2949,00 15 TECNICO AUXILIAR
3400,00 15 PROGRAMADOR DE SEGUNDA
4000,00 16 OPERADOR ESPECIALISTA


Un jefe de servicio (N26) viene a ganar en torno a los 2250 euros al mes si es grupo A1, doscientos euros menos si es grupo A2. Si llega a subdirector (N30) rondará los 3000 euros (más productividades). Un grupo A2 base (analista / programador N18) gana sobre los 1300 euros al mes, y un grupo C1 base (N15) los 1100 largos.

Como podreis apreciar, en este caso los complementos específicos son sensiblemente más bajos (en torno a 6000 euros menos por puesto en el Estado frente a la Junta de Andalucía). En contrapartida, en el Estado se cobra un mayor número de conceptos variables (con el peligro de que exista arbitrariedad en su asignación). Estos conceptos son el complemento de productividad y las gratificaciones extraordinarias. El complemento de productividad es una partida limitada. A la hora de elaborar los presupuestos, cada centro dispone de una cantidad al año, que se puede distribuir de diversas maneras (café para todos, solo cobran productividad unos pocos de mi confianza, etc.). Lo habitual es que su percepción esté ligada a trabajar una, dos o tres tardes a la semana. En Madrid la gran mayoria de funcionarios TIC de la AGE que lo deseen pueden cobrar productividad. En ocasiones es obligatorio. Esta cantidad puede oscilar desde 100 euros hasta más de 1000 (no os hagais ilusiones, yo solo he visto cobrar 1000 euros de productividad a cargos directivos como Secretarios Generales).

Las gratificaciones extraordinarias son algo parecido. Un amigo que trabajó en la Agencia Tributaria de grupo A2 me comentaba que allí cobraban 300 euros al mes de productividad (ligados a trabajar dos tardes) y 400 euros cada tres meses de gratificación extraordinaria. Yo eso no lo he disfrutado nunca (sí es cierto que la Agencia Tributaria es uno de los centros con mayor presupuesto TIC). Otro ejemplo de gratificación extraordinaria (este yo si lo he "catado") es la bufanda. Consiste en una segunda paga adicional que se da en Navidad (de ahí lo de "bufanda"), en concepto de gratificación. La cuantía suele variar (como la de la productividad). Yo cobré 150 euros un año, 600 otro (según lo contentos que estén tus jefes contigo).

Como podeis ver, el sueldo de un funcionario TIC es un sueldo competitivo (sobretodo si se tiene en cuenta el factor sueldo/horas trabajadas, o sueldo/presión), si bien no es ni mucho menos un sueldo puntero dentro del rango de salarios de puestos equivalentes. Por poner un ejemplo, un subdirector de una PYME gana seguramente mucho más que un funcionario de N30 (que tiene muchísimas personas a su cargo, y la presión de poder ser cesado en cualquier momento). Conforme bajamos en el escalafón, el sueldo del funcionario se va haciendo cada vez más competitivo si comparamos con la privada.
En un post reciente veíamos de un modo detallado cual es el sueldo de un funcionario TIC en el Estado y en una comunidad autónoma.
Puesto que salió una entrada demasiado extensa, en esta trataré de resumir toda esta información de un modo más sintético.

De un modo aproximado, en la Administración General del Estado (que engloba todos los ministerios, organismos autónomos, delegaciones provinciales, seguridad social, INEM, etc.) los rangos salariales vienen a ser los siguientes:


  • Grupo A1: entre los 2100 largos de un nivel 26 (técnico superior o jefe de servicio) y los 3000 largos de un nivel 30 (subdirector general). Evidentemente, muy pocos llegarán al nivel 30 (y casi exclusivamente en Madrid). A modo de ejemplo, en la Agencia Tributaria hay 5 subdirecciones generales de Informática.

  • Grupo A2: entre los 1300 largos de un nivel 18 (analista programador o técnico de grado medio) y los 2000 largos de un nivel 26 (jefe de servicio). A igual nivel que un grupo A1, un grupo A2 viene a cobrar entre 100 y 180 euros menos al mes.

  • Grupo C1: entre los 1000 euros largos de un nivel 15 y los 1500 euros largos de un nivel 22.

A todas estas cantidades, habría que sumar los conceptos variables: gratificaciones y complemento de productividad. No todo el mundo las cobra, y su cuantía depende del centro y del nivel (no cobra la misma productividad un nivel 26 que un 15). Además, suelen estar sujetos a la obligación de trabajar dos o tres tardes a la semana.

En las comunidades autónomas se puede cobrar de 150 a 300 euros más de sueldo fijo, pero los conceptos variables son totalmente testimoniales.

En los ayuntamientos, esto es otro cantar. Dependerá del ayuntamiento en cuestión: en unos los sueldos serán altísimos, en otros más modestos (en general, la transparencia del mecanismo de ingreso en las administraciones local es muy mejorable).

Otro factor muy a tener en cuenta es el del coste de la vida en la ciudad donde finalmente te destinen. Por poner un ejemplo: en Madrid un grupo C1 entraría cobrando de partida 1100 euros al mes...si consigues una plaza de maestro en un pueblo de Ciudad Real de 400 habitantes, en el que el alquiler de una casa (sin comillas) te puede costar 250 euros al mes, entras ganando 1500 euros largos. Que cada cual eche sus propias cuentas.
En el BOA (Boletín Oficial de Aragón) se ha publicado la oferta de empleo público 2014. Hay 10 plazas del grupo A2 de Informática. Suerte a los interesados.
Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.

Curso gratis de Bases de Datos y funciones geográficas

Interesante curso sobre bases de datos espaciales PostGIS (PostgreSQL) y MySQL y sus funciones geográficas. Además de una revisión general, desde un punto de vista práctico, de las estructuras de datos que tanto PostgreSQL como MySQL proporcionan para trabajar con información geográfica, también describe los fundamentos teóricos y conceptuales: el modelo abstracto de clases del Open Geospatial Consortium (REQUIERE REGISTRO EN LISTA DE CORREO). Interesante para contestar las 2 o 3 preguntas de GIS que siempre caen en las oposiciones TIC.
Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico.
Para los tiempos que corren, de gran escasez en las oposiciones de Informática, el gobierno de Aragón ha publicado la convocatoria de múltiples plazas de grupos A1, A2 y C1, concurso oposición, de informáticos del Servicio Aragonés de Salud. Más información en los correspondientes boletines oficiales de Aragón....
En el Boletín Oficial del Estado del Miércoles 22 de mayo de 2013  se ha publicado la convocatoria de una plaza, mediante el sistema de provisión del concurso-oposición libre, de Ingeniero Técnico Informático.

Si alguien se anima, y vive por la zona, suerte, por probar no se pierde nada y de vez en cuando puede sonar la flauta....aunque ojo, se trata de una "consolidación de empleo temporal". Este tipo de cosas me indignan mucho, y se hacen en connivencia con los sindicatos, porque tanto derecho tiene la persona que ahora mismo ocupa esa plaza de forma temporal de llegar a la función pública como personal laboral fijo que cualquier otra persona que pague esas tasas y se presente al proceso selectivo....

Seguid leyendo para consultar donde podeis ver las bases del concurso-oposición, sobre todo para ver cuanto se valora la experiencia en el puesto que se saca para cobertura definitiva....me parecería para rajarse las vestiduras que el 80% o el 60% de la puntuación sea el haber trabajado ya en ese puesto, de tal forma que sacando un 10 en la oposición aun así no hubiese nada que hacer.....

 
En el BOE del pasado 23 de Marzo se publicó la oferta de empleo público 2013, en la que nos hemos llevado la grata sorpresa de la inclusión de plazas de cuerpos TIC y de Informática.
Convocada plaza de Ingeniero en Informática (grupo A1) en la Diputación Provincial de Cáceres, en régimen de contratación laboral en prácticas por tiempo determinado.

En el BOP de la provincia de Cáceres de 17 de Abril se ha convocado una plaza de Ingeniero en Informática, grupo A1.

grupo a1 informatica ayuntamiento Cadiz

Publicada en BOE de 15 de Abril plaza del grupo A1 de Informática en el ayuntamiento de Cádiz.

METRICA EVS: Estudio de Viabilidad del Sistema


El objeto del subproceso EVS del proceso de Desarrollo de Sistemas de Información de la metodología METRICA v3 es analizar las necesidades y proponer una solución a corto plazo, basada en criterios económicos, técnicos, legales y operativos.
Mientras que el Plan de Sistemas de Información tiene como objetivo proporcionar un marco estratégico que sirva de referencia para los Sistemas de Información de un ámbito concreto de una organización, el objetivo del Estudiode Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas.


Un pilar básico del Sistema UNIX es el sistema de archivos jerárquico, con estructura de árbol. El sistema de archivos proporciona una forma potente y flexible de organizar y gestionar los datos contenidos en el ordenador. Aunque muchas de las características del sistema de archivos se inventaron originalmente para el Sistema UNIX, su estructura ha resultado ser tan útil que se ha adoptado por muchos otros sistemas operativos.

El desarrollo de software es una tarea compleja. Las organizaciones necesitan habitualmente herramientas software de tamaño medio o grande, y la complejidad para llevar a cabo con éxito dichos desarrollos crecre exponencialmente con el tamaño del producto. Se hace por tanto necesaria una disciplina para poder realizar dichos desarrollos con éxito.
Dicha disciplina es la gestión de proyectos, encargada de organizar y administrar recursos de manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo, y coste definidos.
Un proyecto es un esfuerzo temporal, único y progresivo, emprendido para crear un producto o un servicio también único. Si el objetivo del proyecto es la construcción de un producto software es denominado proyecto informático, y a la disciplina de organización y control, gestión de proyectos informáticos
En este tema veremos las fases de la gestión de proyectos, profundizando a continuación en cada una de ellas.


Los objetivos del Centro de Servicios (Service Desk) son, según el marco ITIL, los siguientes:
El proceso de Desarrollo de Métrica versión 3 contiene todas las actividades y tareas que se deben llevar a cabo para desarrollar un sistema, cubriendo desde el análisis de requisitos hasta la instalación del software. Además de las tareas relativas al análisis, incluye dos partes en el diseño de sistemas: arquitectónico y detallado. También cubre las pruebas unitarias y de integración del sistema, aunque siguiendo la norma ISO 12.207 no propone ninguna técnica específica y destaca la importancia de la evolución de los requisitos.

El objetivo de este proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.
Al ser MÉTRICA Versión 3 una metodología que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común.
En la primera actividad, Definición del Sistema (ASI 1), se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo
a seguir.



INTRODUCCIÓN AL PROCESO ANÁLISIS DE SISTEMAS DE INFORMACIÓN (ASI).

El objetivo de este proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.
Al ser MÉTRICA Versión 3 una metodología que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común.
En la primera actividad, Definición del Sistema (ASI 1), se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo
a seguir.
La definición de requisitos del nuevo sistema se realiza principalmente en la actividad Establecimiento de Requisitos (ASI 2). El objetivo de esta actividad es elaborar un catálogo de requisitos detallado, que permita describir con precisión el sistema de información, y que además sirva de base para comprobar que es completa la especificación de los modelos obtenidos en las actividades Identificación de Subsistemas de Análisis (ASI 3), Análisis de Casos de Uso (ASI 4), Análisis de Clases (ASI 5), Elaboración del Modelo de Datos (ASI 6), Elaboración del Modelo de Procesos (ASI 7) y Definición de Interfaces de Usuario (ASI 8). Hay que hacer constar que estas actividades pueden provocar la actualización del catálogo, aunque no se refleja como producto de salida en las tareas de dichas actividades, ya que el objetivo de las mismas no es crear el catálogo sino definir modelos que soporten los requisitos.
Para la obtención de requisitos en la actividad Establecimiento de Requisitos (ASI 2) se toman como punto de partida el catálogo de requisitos y los modelos elaborados en la actividad Definición del Sistema (ASI 1), completándolos mediante sesiones de trabajo con los usuarios.
Estas sesiones de trabajo tienen como objetivo reunir la información necesaria para obtener la especificación detallada del nuevo sistema. Las técnicas que ayudan a la recopilación de esta información pueden variar en función de las características del proyecto y los tipos de usuario a
entrevistar. Entre ellas podemos citar las reuniones, entrevistas, Joint Application Design (JAD), etc. Durante estas sesiones de trabajo se propone utilizar la especificación de los casos de uso como ayuda y guía en el establecimiento de requisitos. Esta técnica facilita la comunicación
con los usuarios y en el análisis orientado a objetos constituye la base de la especificación. A continuación se identifican las facilidades que ha de proporcionar el sistema, y las restricciones a que está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y control de
accesos, etc. Toda esta información se incorpora al catálogo de requisitos.
En la actividad Identificación de Subsistemas de Análisis (ASI 3), se estructura el sistema de información en subsistemas de análisis, para facilitar la especificación de los distintos modelos y la traza de requisitos.
En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso de análisis estructurado, se procede a la elaboración y descripción detallada del modelo de datos y de procesos, y en el caso de un análisis orientado a objetos, se elaboran el modelo
de clases y el de interacción de objetos, mediante el análisis de los casos de uso. Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, diálogos, formatos de informes y formularios de entrada.
En la actividad Análisis de Consistencia y Especificación de Requisitos (ASI 9), se realiza la verificación y validación de los modelos, con el fin de asegurar que son:
  • Completos, puesto que cada modelo obtenido contiene toda la información necesaria recogida en el catálogo de requisitos.
  • Consistentes, ya que cada modelo es coherente con el resto de los modelos.
  • Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relación a la técnica utilizada, calidad de diagramas, elección de nombres, normas de calidad, etc.).
En la actividad Especificación del Plan de Pruebas (ASI 10), se establece el marco general del plan de pruebas, iniciándose su especificación, que se completará en el proceso Diseño del Sistema de Información (DSI).
La participación activa de los usuarios es una condición imprescindible para el análisis del sistema de información, ya que dicha participación constituye una garantía de que los requisitos identificados son comprendidos e incorporados al sistema y, por tanto, de que éste
será aceptado. Para facilitar la colaboración de los usuarios, se pueden utilizar técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo.
La siguiente figura muestra la sucesión temporal de las actividades que componen el subproceso análisis de sistemas de información. Como se puede apreciar, el análisis del comportamiento (casos de uso, procesos) y de la estructura estática del sistema (clases, datos) se realiza en paralelo, tanto en enfoques estructurados como orientados a objetos.
METRICA-ASI-1.JPG
La siguiente figura muestra los artefactos de entrada al proceso (generados durante el proceso EVS -Estudio de viabilidad del Sistema- o en procesos anteriores -Plan de Sistemas de Información) y los artefactos o entregables generados en este proceso, siguiendo un enfoque de desarrollo estructurado.
METRICA-ASI-2.JPG
Esta otra figura muestra los artefactos de entrada y de salida en el proceso ASI siguiendo un enfoque orientado a objetos.
METRICA-ASI-2B.JPG

ASI 1: DEFINICIÓN DEL SISTEMA.

Esta actividad tiene como objetivo efectuar una descripción del sistema, delimitando su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios representativos. Las tareas de esta actividad se pueden haber desarrollado ya en parte en el proceso de Estudio de Viabilidad del Sistema (EVS), de modo que se parte de los productos obtenidos en dicho proceso para proceder a su adecuación como punto de partida para definir el sistema de información.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-3.JPG

ASI 2: ESTABLECIMIENTO DE REQUISITOS.

En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de la información facilitada por el usuario, completándose el catálogo de requisitos obtenido en la actividad Definición del Sistema (ASI 1).
El objetivo de esta actividad es obtener un catálogo detallado de los requisitos, a partir del cual se pueda comprobar que los productos
generados en las actividades de modelización se ajustan a los requisitos de usuario. Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden, exige continuas realimentaciones y solapamientos, entre sí y con otras tareas realizadas en paralelo. No es necesaria la finalización de una tarea para el comienzo de la siguiente. Lo que se tiene en un momento determinado es un catálogo de requisitos especificado en función de la progresión del proceso de análisis.
Se propone como técnica de obtención de requisitos la especificación de los casos de uso de la orientación a objetos, siendo opcional en el caso estructurado. Dicha técnica ofrece un diagrama simple y una guía de especificación en las sesiones de trabajo con el usuario.
METRICA permite el uso de la técnica de especificación de los casos de uso para desarrollos estructurados (siendo opcional su uso) por su gran potencial como herramienta de comunicación entre usuarios y analistas de software.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-4.JPG

ASI 3: IDENTIFICACIÓN DE SUBSISTEMAS DE ANÁLISIS.

El objetivo de esta actividad, común tanto para análisis estructurado como para análisis orientado a objetos, es facilitar el análisis del sistema de información llevando a cabo la descomposición del sistema en subsistemas. Se realiza en paralelo con el resto de las actividades de generación de modelos del análisis. Por tanto, se asume la necesidad de una realimentación y ajuste continuo con respecto a la definición de los subsistemas, sus dependencias y sus interfaces.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-5.JPG

PARA ENFOQUES ESTRUCTURADOS

ASI 6: ELABORACIÓN DEL MODELO DE DATOS.

El objetivo de esta actividad que se lleva a cabo únicamente en el caso de Análisis Estructurado es identificar las necesidades de información de cada uno de los procesos que conforman el sistema de información, con el fin de obtener un modelo de datos que contemple todas las entidades, relaciones, atributos y reglas de negocio necesarias para dar respuesta a dichas necesidades.
El modelo de datos se elabora siguiendo un enfoque descendente (top-down). A partir del modelo conceptual de datos, obtenido en la tarea Determinación del Alcance del Sistema (ASI 1.1), se incorporan a dicho modelo todas las entidades que vayan apareciendo, como resultado de las funcionalidades que se deban cubrir y de las necesidades de información del usuario. Es necesario tener en cuenta el catálogo de requisitos y el modelo de procesos, productos que se están generando en paralelo en las actividades Establecimiento de Requisitos (ASI 2), Identificación de Subsistemas de Análisis (ASI 3) y Elaboración del Modelo de Procesos (ASI 7).
Una vez construido el modelo conceptual y definidas sus entidades, se resuelven las relaciones complejas y se completa la información de entidades, relaciones, atributos y ocurrencias de las entidades, generando el modelo lógico de datos. Como última tarea en la definición del modelo, se asegura la normalización hasta la tercera forma normal para obtener el modelo lógico de datos normalizado. Finalmente, si procede, se describen las necesidades de migración y carga inicial de los datos. Esta actividad se realiza en paralelo, y con continuas realimentaciones, con otras tareas realizadas en las actividades Establecimiento de Requisitos (ASI 2), Identificación de Subsistemas de Análisis (ASI 3), Elaboración del Modelo de Procesos (ASI 7) y Definición de Interfaces de Usuario (ASI 8).
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-8.JPG

ASI 7: ELABORACIÓN DEL MODELO DE PROCESOS.

El objetivo de esta actividad, que se lleva a cabo únicamente en el caso de Análisis Estructurado, es analizar las necesidades del usuario para establecer el conjunto de procesos que conforma el sistema de información. Para ello, se realiza una descomposición de dichos procesos siguiendo un enfoque descendente (top-down), en varios niveles de abstracción, donde cada nivel proporciona una visión más detallada del proceso definido en el nivel anterior.
Con el fin de facilitar el desarrollo posterior, se debe llegar a un nivel de descomposición en el que los procesos obtenidos sean claros y sencillos, es decir, buscar un punto de equilibrio en el que dichos procesos tengan significado por sí mismos dentro del sistema global y a su
vez la máxima independencia y simplicidad. Esta actividad se lleva a cabo para cada uno de los subsistemas identificados en la
actividad Identificación de Subsistemas de Análisis (ASI 3). Las tareas de esta actividad se realizan en paralelo y con continuas realimentaciones con otras tareas ejecutadas en las actividades Establecimiento de Requisitos (ASI2), Elaboración del Modelo de Datos (ASI 6) y Definición de Interfaces de Usuario (ASI 8).
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-9.JPG

PARA ENFOQUES ORIENTADOS A OBJETOS

ASI 4: ANÁLISIS DE CASOS DE USO.

El objetivo de esta actividad, que sólo se realiza en el caso de Análisis Orientado a Objetos, es identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interacción dichos objetos.
Esta actividad se lleva a cabo para cada uno de los casos de uso contenidos en un subsistema de los definidos en la actividad Identificación de Subsistemas de Análisis (ASI 3). Las tareas de esta actividad no se realizan de forma secuencial sino en paralelo, con continuas
realimentaciones entre ellas y con las realizadas en las actividades Establecimiento de Requisitos (ASI 2), Identificación de Subsistemas de Análisis (ASI 3), Análisis de Clases (ASI 5) y Definición de Interfaces de Usuario (ASI 8).
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-6.JPG

ASI 5: ANÁLISIS DE CLASES.

El objetivo de esta actividad que sólo se realiza en el caso de Análisis Orientado a Objetos es describir cada una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas. Para esto, se debe tener en cuenta la normativa establecida en la tarea Especificación de Estándares y Normas (ASI 1.3), de forma que el modelo de clases cumpla estos criterios, con el fin de evitar posibles inconsistencias en el diseño.
Teniendo en cuenta las clases identificadas en la actividad Análisis de los Casos de Uso (ASI 4), se elabora el modelo de clases para cada subsistema. A medida que avanza el análisis, dicho modelo se va completando con las clases que vayan apareciendo, tanto del estudio de los casos de uso, como de la interfaz de usuario necesaria para el sistema de información.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-7.JPG

ASI 8: DEFINICIÓN DE INTERFASES DE USUARIO.

En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, diálogos, e informes, principalmente. El objetivo es realizar un análisis de los procesos del sistema de información en los que se requiere una interacción del usuario, con el fin de crear una interfaz que satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quiénes va dirigido.
Al comienzo de este análisis es necesario seleccionar el entorno en el que es operativa la interfaz, considerando estándares internacionales y de la instalación, y establecer las directrices aplicables en los procesos de diseño y construcción. El propósito es construir una interfaz de usuario acorde a sus necesidades, flexible, coherente, eficiente y sencilla de utilizar, teniendo en cuenta la facilidad de cambio a otras plataformas, si fuera necesario.
Se identifican los distintos grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y habilidades que poseen, y características del entorno en el que trabajan. La identificación de los diferentes perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos.
Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en línea). Para cada proceso en línea se especifica qué tipo de información requiere el usuario para completar su ejecución realizando, para ello, una descomposición en diálogos que refleje la secuencia de la interfaz de pantalla tipo carácter o pantalla gráfica. Finalmente, se define el formato y contenido de cada una de las interfaces de pantalla especificando su comportamiento dinámico.
Se propone un flujo de trabajo muy similar para desarrollos estructurados y orientados a objetos, coincidiendo en la mayoría de las tareas, si bien es cierto que en orientación a objetos, al identificar y describir cada escenario en la especificación de los casos de uso, se hace un avance muy significativo en la toma de datos para la posterior definición de la interfaz de usuario.
Como resultado de esta actividad se genera la especificación de interfaz de usuario, como producto que engloba los siguientes elementos:
  • Principios generales de la interfaz.
  • Catálogo de perfiles de usuario.
  • Descomposición funcional en diálogos.
  • Catálogo de controles y elementos de diseño de interfaz de pantalla.
  • Formatos individuales de interfaz de pantalla.
  • Modelo de navegación de interfaz de pantalla.
  • Formatos de impresión.
  • Prototipo de interfaz interactiva.
  • Prototipo de interfaz de impresión.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-A.JPG

ASI 9: ANÁLISIS DE CONSISTENCIA.

El objetivo de esta actividad es garantizar la calidad de los distintos modelos generados en el proceso de Análisis del Sistema de Información, y asegurar que los usuarios y los Analistas tienen el mismo concepto del sistema. Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones:
  • Verificación de la calidad técnica de cada modelo.
  • Aseguramiento de la coherencia entre los distintos modelos.
  • Validación del cumplimiento de los requisitos.
Esta actividad requiere una herramienta de apoyo para realizar el análisis de consistencia. También se elabora en esta actividad la Especificación de Requisitos Software (ERS), como producto para la aprobación formal, por parte del usuario, de las especificaciones
del sistema.
La Especificación de Requisitos Software se convierte en la línea base para los procesos posteriores del desarrollo del software, de modo que cualquier petición de cambio en los requisitos que pueda surgir posteriormente, debe ser evaluada y aprobada
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-B.JPGMETRICA-ASI-B2.JPGMETRICA-ASI-B3.JPG

ASI 10: ESPECIFICACIÓN DEL PLAN DE PRUEBAS.

En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad.
El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba. El plan se inicia en el proceso Análisis del Sistema de Información (ASI), definiendo el marco general, y estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de requisitos.
Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software, Diseño del Sistema de Información (DSI), Construcción del Sistema de Información (CSI) e Implantación y Aceptación del Sistema (IAS).
Se plantean los siguientes niveles de prueba:
  • Pruebas unitarias.
  • Pruebas de integración.
  • Pruebas del sistema.
  • Pruebas de implantación.
  • Pruebas de aceptación.
En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Con la información disponible, es posible stablecer los criterios de aceptación de las pruebas incluidas en dicho nivel, al poseer la información sobre los requisitos que debe cumplir
el sistema, recogidos en el catálogo de requisitos.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-C.JPG

ASI 11: PRESENTACIÓN Y APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN.

Se realiza la presentación del análisis del sistema de información al Comité de Dirección, para la aprobación final del mismo.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
METRICA-ASI-D.JPG

PARTICIPANTES Y TÉCNICAS Y PRÁCTICAS DEL PROCESO DE ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI).

La siguiente figura muestra los participantes en las diferentes actividades del proceso ASI de METRICA V3.
METRICA-ASI-E.JPG
Las técnicas y prácticas utilizadas en el proceso ASI aparecen reflejadas en la siguiente figura:
METRICA-ASI-F.JPG

BIBLIOGRAFÍA Y ENLACES EXTERNOS.

UML Distilled. Martin Fowler.
Planning Extreme Programming.


Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.
Introducción a la arquitectura en 2 niveles

La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en donde el cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra aplicación para proporcionar parte del servicio.

Introducción a la arquitectura en 3 niveles

En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura generalmente está compartida por:
1. Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de usuario (generalmente un navegador Web) para la presentación
2. El servidor de aplicaciones (también denominado software intermedio), cuya tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo
3. El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere


Comparación entre ambos tipos de arquitecturas


La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la que el servidor es polivalente, es decir, puede responder directamente a todas las solicitudes de recursos del cliente.

Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor son descentralizadas de uno a otro, es decir, cada servidor se especializa en una determinada tarea, (por ejemplo: servidor web/servidor de bases de datos).

La arquitectura en 3 niveles permite:
• Un mayor grado de flexibilidad
• Mayor seguridad, ya que la seguridad se puede definir independientemente para cada servicio y en cada nivel
• Mejor rendimiento, ya que las tareas se comparten entre servidores
Arquitectura de niveles múltiples
En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para proporcionar su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente una arquitectura en N-niveles
  


Compendio de enlaces sobre sistemas distribuidos, arquitectura cliente/servidor, arquitectura SOA, y servicios web.



Introducción al procesamiento cooperativo.

La arquitectura cliente/servidor. Tipología, componentes e Interoperabilidad.

Introducción al concepto de SOA (Service Oriented Architecture).

Tecnología de Servicios Web (Web Services).





Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.
El hardware de un ordenador es el conjunto de componentes físicos que lo componen.
Externamente, un ordenador es una caja con una fuente de alimentación, con ciertos conectores tanto en la parte trasera como en la delantera, y con, por lo general, un CD/DVD-ROM en la parte frontal.
Conectados a esta caja están una serie de dispositivos que le acompañan, como el teclado, el ratón, el monitor, los altavoces, la impresora, el escanner, ecétera.
Si abrimos dicha caja, observamos que el ordenador está compuesto de una placa que prácticamente tiene el tamaño de la caja, y en la cual están conectados otra serie de dispositivos como el microprocesador, la memoria, el disco duro, otras tarjetas, ecétera.
Esta placa es la llamada placa base o tarjeta madre y es la columna vertebral física y lógica de todo el sistema.
Aparte de los MDT, como SIG de relieve, y las aplicaciones meteorológicas y oceanográficas tenemos numerosos campos de aplicación de los SIG.
top