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....
Oposición Diplomado Informática en Ubrique, Cádiz
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.....
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.....
Oferta Empleo Público 2013 AGE: Plazas de Informática
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.
1 plaza de contrato en prácticas de Ingenieros en Informática para la Diputación de Cáceres
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.
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.
Unix sistema de archivos
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.
Gestión y control de proyectos informáticos. Estimación de recursos. Planificación temporal y organizativa. Seguimiento
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.
ITIL service desk
Los objetivos del Centro de Servicios (Service Desk) son, según el marco ITIL, los siguientes:
METRICA: El proceso de desarrollo de sistemas de información
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.
METRICA ASI: ANALISIS DE SISTEMAS DE INFORMACIÓN
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.
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.
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.
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.
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.
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.
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.
Esta otra figura muestra los artefactos de entrada y de salida en el proceso ASI siguiendo un enfoque orientado a objetos.
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.
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.
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.
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.
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.
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).
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.
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).
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.
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.
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.
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.
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.
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.
el sistema, recogidos en el catálogo de requisitos.
Las tareas que componen esta actividad aparecen reflejadas en la siguiente figura.
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.
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.
Las técnicas y prácticas utilizadas en el proceso ASI aparecen reflejadas en la siguiente figura:
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.
Arquitectura cliente/servidor. Modelo de 2 capas. Modelo de 3 capas. Servicios Web
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.
Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.
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.
Hardware de un ordenador: componentes
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.
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.
Aplicaciones practicas de los Sistemas de Información Geográfica
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.
Calidad del software. Factores y métricas. Estrategias de prueba.
Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son enormes.
Es complicado realizar un buen software, y muchos de los productos que se construyen tienen calidad insuficiente, además de no acertar con las estimaciones de tiempo y recursos inexactos para la construcción de los mismos.
Es complicado realizar un buen software, y muchos de los productos que se construyen tienen calidad insuficiente, además de no acertar con las estimaciones de tiempo y recursos inexactos para la construcción de los mismos.
Todos los métodos, herramientas y procedimientos que constituyen la Ingeniería del Software van orientados a un único fin: producir software de calidad.
En este tema introduciremos el concepto de calidad de software, primero a un nivel general como concepto y procesos a nivel de organización, viendo después cuáles son los factores que influyen en la calidad del software, cómo medirlos, y por último qué estrategias podemos utilizar para conseguir un software de mayor calidad.
Aunque en el siguiente apartado se trata de la calidad del software a nivel de empresa, haré referencia en el tema principalmente a calidad de software a nivel de proyecto (factores, métricas y estrategias)
Temario del Cuerpo Superior de Sistemas e Informática de la Administración General del Estado
Relación de temas del temario del grupo A1 del cuerpo TIC del Estado (Superior de Sistemas e Informática de la AGE) con enlaces a las entradas de este blog donde se desarrollan, en el caso de que existan.
El principio de riesgo y ventura del contratista
La problemática de la aplicación de este principio no es tan simple como pudiera parecer de la lectura del texto de la LCSP, pues entra en conflicto (o digamos más bien que existe un "equilibrio inestable") con el principio de equilibrio económico
METRICA v3: El proceso de Diseño de Sistemas de Información (DSI)
El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información.
A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial,
éstos últimos cuando proceda.
Bases de cotización o de cómo seguir financiandote a costa del sueldo de los Funcionarios
Como funcionario del grupo A1 de la Junta de Andalucía, en los dos últimos años he experimentado una rebaja de sueldo superior al 15 % (sumando el tijeretazo de Zapatero con la supresión de la paga extra de Rajoy, supresión que en 2013 nos aplican a los funcionarios andaluces el dúo Griñán - DiegoValderas). No obstante, éste no es el único concepto del que nos recortan, porque está claro que el sueldo de los funcionarios es una fuente de financiación muy cómoda para nuesros político
Incompatibilidades de funcionarios públicos
Recientemente, un amable lector al que desde ya pedimos disculpas por la tardanza en contestar (lamentablemente no corren tiempos buenos para los blogs sobre oposiciones) nos pidió información sobre el régimen de incompatibilidades. La verdad, es que con una bajada de sueldo del 15% en dos años para los funcionarios del grupo A1, a la que se debe sumar la inflacción (en torno al 8%) y otros conceptos, parece razonable pensar en una segunda fuente de ingresos, si no fuera porque puede parecer ciencia ficción el encontrarla en un país con 26% de paro y 6 millones de personas desempleadas.