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.

MESH: El Primer Tablet PC Chileno, Hará su estreno en China durante la feria Computex 2010

Este dispositivo, apoyado por Microsoft, verá la luz dentro de los próximos días de la mano del propio director ejecutivo Steve Ballmer en el stand “Lider and Innovation Notebook Circle”.

Pese a que aún no realiza su estreno, desde CHW dieron algunas pistas de lo que traerá el nuevo gadget criollo que estararía disponible a finales de julio en territorio nacional:

1.- Sistema operativo Windows 7 Home Premium.

2.- Disco duro sólido (SSD).

3.- Pantalla multi-táctil de 10.1 pulgadas.

4.- Procesador Intel Atom N450.

5.- Conectividad Bluetooth.

6.- Internet inalámbrica.

7.- Cámara web de 5 megapixeles.

8.- Tecnología 3G.

9.- Peso: aproximadamente 1 kilo.

10.- Duración independiente de 6 horas.

Vendrá disponible en varios colores.

Si te preguntas qué opinan los desarrolladores chilenos de este logro, Juan Antonio Barriga -CEO de Ubicuos- comentó que “ Poder exhibir nuestro producto en una de las ferias tecnológicas más importantes de Asia y el mundo, es la prueba de que los chilenos también podemos salir al mercado con nuestros productos innovadores”.

Además, desde la otra vereda la representante de Microsoft Chile, Ximena Verdaguer, dijo que “Mostrar este nuevo producto, ideado, desarrollado y presentado por chilenos, es un gran orgullo para la industria nacional de tecnología”.

Ahora, sólo basta esperar a que durante los próximos días se tengan más detalles sobre MESH y el valor al que se venderá en el mercado.

Microsoft Office 2010 ,“La suite ofimática del futuro”

Cada nueva versión de Office supone una pequeña revolución. Microsoft Office 2010 no es para menos. Asociada al nuevo Windows 7, la suite ofimática más conocida se ha puesto las pilas para no perder el tren de la innovación.

Todas las aplicaciones de Microsoft Office 2010 usan ahora la conocida interfaz ribbon, introducida en la versión 2007. El aspecto es más sobrio, ligero y coherente. El Botón Office, al mismo tiempo, se ha renovado por completo. En lugar de un menú, abre un panel que ocupa toda la ventana del programa.

Los cambios que introduce Microsoft Office 2010 son muchos y bastante llamativos. La previsualización de pegado te permite ver cómo quedará el texto antes de insertarlo, mientras que las herramientas de traducción y captura de pantalla te ayudarán a mejorar tus documentos.

Microsoft Office 2010 rebosa de novedades por doquier. En Excel aparecen los minigráficos, pequeños diagramas de resumen que se integran fácilmente en el texto. Outlook agrupa las conversaciones como G-Mail y tiene un botón para eliminar texto redundante, mientras que PowerPoint puede insertar vídeos con un reproductor integrado.

La verdadera estrella de Microsoft Office 2010, con todo, será la versión web gratuita de sus aplicaciones, la cual se integrará a la perfección con la versión de Escritorio. Versión que, a pesar de estar incompleta, demuestra un potencial enorme. Además, Microsoft Office 2010 es más estable y ligero, algo que muchos usuarios agradecerán.

Microsoft Office 2010 soporta los siguientes formatos:

DOC, DOCX, XLS, XLSX, PPT, PPTX, MDB, ACCDB, PUB, RTF, TXT, HTM, JPG, PNG, TIF, EMF, WMF, XML, WRI, ODT, ODP, ODS, WMV, AVI, PDF

Microsoft presenta software empresarial basado en "la nube", Windows Azure

El director ejecutivo de Microsoft, Steve Ballmer, hizo hoy en Bogotá la presentación para Latinoamérica de un nuevo producto de comunicación y colaboración empresarial basado en el concepto de "computación en nube", un modelo de provisión de servicios informáticos por Internet.

Microsoft Online Services permitirá por ahora a clientes de Brasil, Chile, Colombia, Costa Rica, México, Perú, Puerto Rico y Trinidad y Tobago utilizar las ventajas de la "computación en nube" para acceder a servicios de mensajería, calendarios, colaboración, comunicación y conferencias web.

"Hasta la fecha más de 3.000 empresas están probando gratuitamente estas aplicaciones en la región", dijo Ballmer en una conferencia de prensa.

Entre los servicios que se ofrecen están el correo electrónico y colaboración a través de MS Exchange Online y MS SharePoint Online, además de una solución de mensajería instantánea corporativa con Office Communicatios Online y conferencias web a través de MS Office Live Meeting, paquete que se ofrece por US$ 10 mensuales.

La "computación en nube" es un servicio informático que se ofrece en una nueva escala en internet, la cual, según Ballmer, permite que los usuarios accedan a los datos que están disponibles por demanda y se almacenan en los centros fuera de las instalaciones o en el centro de datos "in situ" de la organización.

El ejecutivo indicó además que el gigante de software está ofreciendo la más amplia gama de soluciones en la "computación en nube" al dar a los clientes "la flexibilidad de elegir el modelo que mejor se adapte a sus necesidades, desde un esquema tradicional a un esquema híbrido".

"El cliente escoge que parte de sus negocios va a la 'nube' y que parte queda en los servidores propios, hasta un esquema con el 100% de los servicios en la 'nube'", aclaró.

Chile

Microsoft espera que, al colocar los servicios de infraestructura de software en la 'nube', las empresas dejen de preocuparse por el gasto y administración en tecnología, ya que ellos mismos serán los encargados de mantener actualizado el sistema.


Como ejemplo, Ballmer indicó que una empresa chilena debió enfrentar la catástrofe por elterremoto del pasado 27 de febrero que destruyó su infraestructura tecnológica y por eso decidieron comenzar a hacer pruebas con Microsoft Online Services.


"Decidimos escuchar a nuestra contraparte enMicrosoft Chile y llevar nuestra operación a la 'nube'. En dos días, no sólo fuimos capaces de reiniciar nuestras actividades, sino también apoyamos a nuestros clientes", aseguró, por su lado, el gerente de la firma chilena IT Solutions, Rodrigo Lozano.


"La 'computación en nube' transformará la manera en que las empresas grandes entregan servicios a sus clientes y ayudará a las compañías más pequeñas a adoptar tecnología para expandir sus negocios", sostuvo Ballmer.


El ejecutivo explicó además que este sistema incluye hardware, software y servicios que permiten a sus clientes optimizar su desempeño empresarial "con la sencillez de oprimir un botón y con el costo más bajo posible de propiedad".


El representante de Microsoft también tiene previsto reunirse con desarrolladores de software colombianos, así como con el presidente del país, Álvaro Uribe, antes de finalizar, hoy mismo, su visita a la nación suramericana.

“Nuestro primer enfoque será simplificar la llegada de las nuevas aplicaciones a la nube”, explica Amitabh Srivastava, vicepresidente señor de la nueva división de Servidores y Nubes de Microsoft, en alusión al trabajo que se extiende más allá de la plataforma Windows Azure. Según este responsable, “el cambio que estamos viendo es hacia donde se dirigen nuestros esfuerzos. Si hay un lugar donde tenemos que llevar nuestras aplicaciones, éste es la nube”. 

Metologias Modernas del Software

Metologia Agile: Se entiende como desarrollo ágil de software a un paradigma de desarrollo de software basado en procesos ágiles, también conocidos anteriormente como metodologías livianas. Estos intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.
Los Métodos de desarrollo ágil de software evolucionaron a mediados de los años 1990 como parte de una reacción contra los métodos de "peso pesado", muy estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación.




Programación Extrema (XP): es un enfoque de la ingeniería de software formulado por Kent Beck, se considera el más destacado de los procesos ágiles de desarrollo de software, se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback), coraje y respeto. El quinto valor fue añadido en la segunda edición de Extreme Programming Explained.




Metodología Scrum: se define como un "framework" o conjunto de herramientas, para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Este modelo de referencia que define un conjunto de prácticas y roles, puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores.

Metologias Clasicas del Software

Cascada Puro: fue propuesto por Winston Royce en el año 1970, este permite iteraciones contrariamente a un ciclo de vida secuencial, después de cada etapa se realiza una o varias revisiones para ver si se puede pasar a la siguiente, Es un modelo rígido poco flexible y con muchas restricciones.



Ciclo de Vida en V: Fue diseñado por Alan Davis y contiene las etapas que la metodología cascada pura, a diferencia de aquel a este se le agregaron 2 sub-etapas de retroalimentación entre las etapas de análisis y mantenimiento, y entre la de diseño y debuggin (depuración).



Ciclo de vida tipo prototipos: Esta metodología se utiliza en la práctica para validar los requerimientos de los usuarios en cualquier ciclo de vida. Si no se conoce exactamente como desarrollar un determinado producto o cuáles son las especificaciones de forma precisa suele recurrirse a definir especificaciones iníciales para hacer un prototipo, ósea un producto parcial y provisional.



Ciclo de vida espiral: esta metodología es una variación del modelo con prototipado, fue diseñado por Boehm en el año 1988. Este modelo se basa en una serie de ciclos repetitivos para ir ganando madures en el producto final. Tiene los mismos beneficios que el de tipo prototipo.

Presentación del Grupo EZ-TURNO

Somos un grupo de estudiantes de la Universidad Central de Chile, nos encontramos en la asignatura de ingenieria de software y tenemos que hacer un sistema de toma de turno para empaquetadores de un supermercado llamado 'tottus'.

Los integrantes de este grupo son:

Ariel Bustos
Ivan Contreras
Nicolas Fredes
Marcelo Vera