Laboratorios Evaluacion de Sistemas Computacionales

Descarga de Documento
http://db.tt/FQ29b0c

Modelo Fisico Zoo

en el zoologico hay muchos tipos de animales (mamiferos, anfibios,..),asi como tambien hay muchos "especies de animales" (leones, garzas, chimpanses,...) y cada especie es de un unico tipo.

los ejemplares de los animales siempre son de una especie y de cada uno de ellos se sabne: fecha de nacimiento, nombre, num unico de identificacion, cantidad de patas, cantidad de plumas, cant. de pelos, cant de cuernos, canti. de colas(o rabos), el genero de animal (entre los tres disponibles) y del continente o los continentes del cual es originario.

El zoológico tiene varias sucursales en distintas ciudades de distintos países y cada animal vive en una sucursal y podría solicitar su traslado a otra en algún momento

2.- indique un query para cambiar o trasladar un animal

select id_especie from ejemplar

where id_sucursal in (select id_sucursal from sucursal

where id_solicitud = (select id_solicitud from solicitud where descripcion= 'traslado') )

3.- indique un query para detectar a los animales cojos

select a.* from ejemplar as a, especie_animal as b

where a.id_especie= b.id_especie and a.cant_patas <> b.cant_patas

4.- indique un query para informar cuantos animales de cada especie hay en cada sucursal del zoo.

select count(id_ejemplar), id_especie, id_sucursal from ejemplar

group by id_sucursal, id_especie

5.- indique un query para detectar que especie de animales no están presentes en alguna sucursal

select * from ejemplar where id_sucursal is null

6.- “   ” para ingresar el nacimiento de un animal

insert into ejemplar (id_ejemplar, fecha_nac)

values (1004, CONVERT(datetime, '2007-05-03', 105))

7.- un query para detectar el tipo de animal mas cornudo

select id_ejemplar from ejemplar

where cant_cuernos in (select max(cant_cuernos)from ejemplar)

8.- query cantidad promedio plumas por especie

select id_especie, avg(cant_plumas) as prom_especie from ejemplar

group by id_especie

9.- un query para listar los animales de cumpleaños este mes

select * from ejemplar where Datepart(mm,fecha_nac)in (select datepart(month,getdate()))

10.- un query para listar los animales de De cumpleaños este dia

select * from ejemplar where Datepart(dd,fecha_nac)in (select datepart(day,getdate()))

Presentación de Avance de Auditoria

Adjunto el link de las diapositivas
Presentación

Revisiones e Inspecciones de software

Una inspección es una de las clases mas comunes de prácticas de la revisión encontradas en proyectos del software. La meta de la inspección está para que todos los inspectores alcancen consenso en un producto del trabajo y lo aprueben para el uso en el proyecto. Los productos comúnmente examinados del trabajo incluyen especificaciones de requisitos del software yplanes de prueba. En una inspección, un producto del trabajo se selecciona para la revisión y recolectan a un equipo para una inspección que se reúne para repasar el producto del trabajo. Un asesor se elige para moderar la reunión. Cada inspector se prepara para la reunión leyendo el producto del trabajo y observando cada defecto. La meta de la inspección es identificar defectos. En una inspección, un defecto es cualquier parte del producto del trabajo que guardará a inspector de aprobarla. Por ejemplo, si el equipo está examinando una especificación de requisitos del software, cada defecto será texto en el documento con el cual un inspector discrepa.

El proceso

El proceso de la inspección fue desarrollado por Michael Fagan en los mediados de los años setenta y se ha ampliado y se ha modificado más adelante.

El proceso debe tener criterios de una entrada que se determina si el proceso de la inspección es listo comenzar. Esto evita que los productos inacabados del trabajo incorporen el proceso de la inspección. Deletrear-se han comprobado los criterios de la entrada pudieron ser una lista de comprobación incluyendo artículos tales como “el documento”.

Las etapas en el proceso de las inspecciones son: Reunión del planeamiento, de la descripción, reunión de la preparación, de la inspección, reanudación y carta recordativa. La reunión de la preparación, de la inspección y las etapas de la reanudación pudieron ser iteradas.

• Planeamiento: La inspección es planeada por el asesor.
• Reunión de la descripción: El autor describe el fondo del producto del trabajo.
• Preparación: Cada inspector examina el producto del trabajo para identificar defectos posibles.
• Reunión de la inspección: Durante esta reunión el lector lee a través del producto del trabajo, parte por la parte y los inspectores precisan los defectos para cada partición.
• Reanudación: El autor hace changs al producto del trabajo según los planes de acción de la reunión de la inspección.
• Carta recordativa: Los cambios del autor se comprueban para cerciorarse de que todo esté correcto.

El proceso es terminado por el asesor cuando satisface algunos criterios predefinidos de la salida.

Papeles de la inspección

Durante una inspección se utilizan los papeles siguientes.

• Autor: La persona que creó el producto del trabajo que era examinado.
• Asesor: Éste es el líder de la inspección. El asesor planea la inspección y la coordina.
• Lector: La lectura a través de los documentos, un artículo de la persona a la vez. Los otros inspectores entonces precisan defectos.
• Registrador: La persona que documenta los defectos que se encuentran durante la inspección.

Tipos relacionados de la inspección

Revisión de código

A revisión de código puede ser hecho como clase especial de inspección en la cual el equipo examine una muestra del código y fije cualquier defecto en él. En una revisión de código, un defecto es un bloque del código que no pone correctamente sus requisitos en ejecución, que no funciona como el programador pensó, o que no es incorrecto pero podría ser mejorado (por ejemplo, podría ser hecha más legible o su funcionamiento se podría mejorar). Además de los equipos que ayudan encuentre y fije los insectos, las revisiones de código son útiles para ambos programadores del cruz-entrenamiento en el código que es repasado y para ayudar los reveladores menores aprenden nuevas técnicas de programación.

Revisiones de par

Las revisiones de par se consideran una mejor-práctica de la industria para detectar defectos del software temprano y aprender sobre los artefactos del software. Las revisiones de par se componen de walkthroughs del software y las inspecciones del software y son integrales a las actividades de la ingeniería del producto de software. Una colección de conocimiento, de habilidades, y de comportamientos coordinados facilita la práctica mejor de las revisiones de par. Los elementos de las revisiones de par incluyen el proceso estructurado de la revisión, estándar de las listas de comprobación del producto de la excelencia, el papeles definida de participantes, y las formas y los informes.

Las inspecciones del software son la forma más rigurosa de revisiones de par y utilizan completamente estos elementos en la detección de defectos. Los walkthroughs del software dibujan selectivamente sobre los elementos en asistir al productor para obtener la comprensión más profunda de un artefacto y alcanzar un consenso entre participantes. Los resultados medidos revelan que las revisiones de par producen una vuelta en la inversión atractiva obtenida con aprender acelerado y la detección temprana del defecto. Para los mejores resultados, las revisiones de par se ruedan hacia fuera dentro de una organización a través de un programa definido de elaborar una política y un procedimiento, de médicos de entrenamiento y de encargados, definiendo medidas y poblando una estructura de la base de datos, y sosteniendo la infraestructura del rodillo hacia fuera.

PPT de trazabilidad

A continuación la presentacion realizada el martes 26 de octubre sobre trazabilidad:

Presentacion de trazabilidad

Walkthrough del software

En tecnología de dotación lógica, a walkthrough o caminar-por es una forma de revisión de par del software “en cuál pregunta a preguntas y hace un diseñador o los miembros de los plomos del programador del equipo del desarrollo y de otros partidos interesados a través de un producto de software, y los participantes comentarios sobre errores posibles, la violación de estándares del desarrollo, y otros problemas”^[1].

El “producto de software” refiere normalmente a una cierta clase de documento técnico. Según lo indicado por la definición de IEEE, esto pudo ser un documento o un programa del diseño del software código de fuente, pero utilice los casos, proceso del negocio definiciones, pruebe el caso las especificaciones, y una variedad de la otra documentación técnica se pueden también caminar a través.

Un walkthrough diferencia de revisiones técnicas del software en su franqueza de la estructura y de su objetivo del conocimiento. Diferencia de la inspección del software en su capacidad de sugerir alteraciones directas al producto repasado, su carencia de un foco directo en el entrenamiento y la mejora de proceso, y su omisión del proceso y de la medida del producto.

Contenido 1 Objetivos y participantes 2 Proceso 3 Vea también 4 Referencias

Objetivos y participantes

Un walkthrough tiene generalmente uno o dos objetivos generales: para ganar la regeneración sobre la calidad o el contenido técnica del documento; y/o para familiarizar a las audiencias con el contenido.

Un walkthrough es organizado y dirigido normalmente por el autor del documento técnico. Cualquier combinación del personal interesado o técnico cualificado (de dentro o fuera del proyecto) se puede incluir como se parece apropiado.

IEEE 1028^[1] recomienda tres papeles del especialista en un walkthrough:

• Autor, que presenta el producto de software de la manera paso a paso en caminar-por la reunión, y es probablemente responsable de terminar la mayoría de los artículos de acción;
• Líder de Walkthrough, que conduce el walkthrough, maneja tareas administrativas, y asegura conducta ordenada (y que es a menudo el autor); y
• Registrador, que observa todos anomalías (defectos potenciales), decisiones, y artículos de acción identificados durante la reunión del walkthrough.

Proceso

Un walkthrough puede ser absolutamente informal, o puede seguir el proceso detallado en IEEE 1028 y contorneado en el artículo encendido revisiones del software.

Qué Es El PMBOK® Y Cómo Usarlo

La Guía de los fundamentos de la dirección de proyectos (más conocida como PMBOK) es el estándar más ampliamente reconocido para manejar y administrar proyectos.  Se trata de una obra realizada por personas con un agudo sentido práctico, y que tiene incorporada la concepción de que un proyecto exitoso va a ser resultado de la colaboración (y los conflictos) .

Para citar uno de los párrafos introductorios del PMBOK: «“Buenas prácticas” no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado.»

Desde su misma Introducción, el PMBOK deja muy claro su carácter y finalidad: el conjunto de conocimientos (the body of knowledge) para dirigir un proyecto “residen en los practicantes y académicos que los aplican y los desarrollan”; en otras palabras, estos conocimientos representan un conjunto vivo, extraordinariamente amplio, producto tanto de la experiencia como del estudio y del desarrollo sistemáticos. Este conjunto de conocimientos se encuentra distribuido en miles de personas, organizaciones y textos; por ende, el lector no debe esperar tal cosa como un manual que le vaya a explicar los “nueve pasos fáciles para hacer de su proyecto un éxito”.

La finalidad del PMBOK, entonces, no es la de exponer las disciplinas, técnicas y experiencias aplicables a la dirección de proyectos, sino simplemente la de identificar el subconjunto de éstas que es generalmente reconocido como buenas prácticas. 
Para que estas buenas prácticas sean asequibles, el PMBOK divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo proyecto (así como sus distintas fases e iteraciones) tiene que transitar por una serie de actividades de INICIO, PLANEACIÓN, EJECUCIÓN Y CIERRE, bajo el gobierno de un grupo de procesos más general de supervisión y cierre.

Estos grupos de procesos no representan fases rígidas ni recetas, sino que, grosso modo, equivalen al modelo “planear, hacer, revisar y actuar”:

El meollo del PMBOK, sin embargo, lo representan las nueve áreas de conocimiento, y que son propiamente las que contienen las técnicas para poder realizar los proyectos. Las nueve áreas de conocimiento son:

Para cada una de estas áreas de conocimiento, el PMBOK recomienda la realización de una serie de procesos. Por ejemplo, la Gestión del alcance comprende los procesos Planificar alcance, Definición del alcance, Crear estructura de desglose de tareas, Verificación de alcance y Control de alcance. Podemos apreciar los primeros tres de éstos en el siguiente diagrama:

Para cada uno de estos procesos de las áreas de conocimiento, el PMBOK plantea o sugiere una serie de entradas, técnicas y salidas. Como ya se ha explicado, el PMBOK identifica las mejores prácticas que son generalmente aceptadas para la realización de cada uno de estos procesos. 
Aunque muchas de las descripciones de estos procesos contienen valiosas observaciones, el lector no deberá considerarlas como un manual de técnicas, sino más bien como la descripción del estándar para manejo de proyectos. Las técnicas mismas están contenidas en textos de diversos autores, en cursos y en la práctica misma de las organizaciones dedicadas a manejo de proyectos.