Organizacion.

Capitulo 26

1. En las primeras paginas de este capitulo  se anoto que “el control de la variación es el corazón del control de calidad” dado que cualquier programa que se crea es diferente de todos los otros programas, ¿Cuáles son las variaciones que se buscan y como se le controla?

            FALTA   RESPUESTA………………………….RESPUESTA LIBRO

1. ¿es posible valorar la calidad de software si el cliente cambia con frecuencia lo que se supone debe hacer?

No es posible ya que la calidad comprende los requisitos ,especificaciones y diseño del sistema por lo tanto si el cliente no tiene claro las funciones del software es muy difícil determinar los requerimientos y es asi como no se puede evaluar la calidad.

1. La calidad y la fiabilidad son conceptos relacionados pero fundamentalmente diferentes en varias formas coméntense.

Fiabilidad: la probabilidad de que no se produzcan fallos de un programa.
Calidad: Caracteristicas que debe cumplir el software con los requerimientos hechos por el cliente y los definidos por el ingeniero de software.

La fiabilidad abarca un espacio en la calidad , ésta comprende el diseño del software con los elementos a utilizar,el rendimiento de estos elementos y los niveles que manejan .
La fiabilidad solo muestra la probabilidad de que estos elementos unidos presentesn fallos , sin interesarse en sus caracteristicas , parte que si cumple la calidad.
Ademas la calidad para poder ser considerada alta debe presebrae una implementacion ajustada al diseño , la fiabilidad asi se haya tomado en cuenta a la hora de considerar el tiplo de implementacion podra presentar fallos,por otro lado si la implementacion es inadecuada se presentaran los fallos calculados , más una nueva cifra.
Por ultimo la satisfacción del usuario en la composición de la calidad , pues no se considera igual si el cliente esta inconforme , la fiabilidad es un aspecto muy importante para el usuario a la hora de calificar en que nivel de calidad se encuentra (desde su vision), pero no es lo unico.

1. ¿puede un programa ser correcto y aun asi no ser fiable? Expliquese.

Un programa puede ser correcto en la medida en que cumpla las especificaciones de diseño durante su realización ; el nivel de cumplimiento de los requisitos y diseño del software no garantizan un nivel de fiabilidad alto, ya que aunque tengan todas las funciones que se esperan puede presentar un numero de fallos considerables.

1. ¿puede un programa ser correcto y aun asi no mostrar buena calidad? Expliquese.

Un programa es correcto en la medida en que los requisitos y diseño del software sigan con la especificación establecida , pero lo que determina la calidad es los materiales con los que se realizo ese trabajo, su nivel de rendimiento y los procesos con os que fue efectuado , por lo tanto el programa puede presentar las funciones exigidas y aun asi no tener alta calidad.

1. ¿Por qué con frecuencia existen tensión entre un grupo de ingeniería de software y un grupo independiente de aseguramiento de la calidad del software?¿esto es saludable?

FALTA RESPUESTAA…….

1. A usted le han dado la responsabilidad de mejorar la calidad del software por medio de su organización ¿Qué es lo primero que debe hacer?¿que seria lo siguiente?

Lo primero que haria es mirar si el software de mi organización tiene todos los requerimientos pedidos anteriormente ,esto se mira en la documentación del software. Por tanto si no cumple con estos requerimientos lo que haria seria implementar las solicitudes de usuario o cliente que hacen falta en el software.
Lo segundo seria mirar la fiabilidad del software, observar y detectar todos los fallos para luego corregirlos y asi subir el nivel de calidad.

1. Además de contar errores y defectos, ¿existen otras características contables del software que impliquen calidad?¿cuales son y como se pueden medir directamente?

Sí hay mas caractericas claras del software que impliquen calidad:
Fiabilidad: en terminos estadisticos como la probabilidad de operación libre de fallos de un programa en un entorno determinado y durante un tiempo especifico.
Se puede medir asi:
TMEF=TMDF+TMDR
TMEFè tiempo medio entre fallo
TMDFètiempo medio de fallo
TMDRètiempo medio de reparacion
Disponibilidad: es la probabilidad de que un programa funciones de acuerdo con los requisitos en un momento dado.
DISPONIBILIDAD=[TMDF/TMEF]*100

1. Una revisión técnica formal solo es eficaz si todos se han ´preparado por anticipado. ¿Cómo reconoce en la revisión a un participante  que no esta preparado?¿que hace si usted es el jefe de revisión?

1. Si no recibio o no sabe de que se trata las copias del producto
   2. Que no presente notas del producto
   3. Que no comparta ideas en el momento de la exposición
   4. Que no haya encontrado ningun error o contratiempo.
   Si alguno de los integrantes no esta preparado le pediria que saliera ya que en ninguna revision se esta en posición de perder tiempo explicando de que se trata el producto.
   Ademas este tiempo se tuvo que haber tomado antes de manera individual para generar las notas que son expuestas en la revision y que son de gran importancia en el analisis del producto.
   Para que esto no pasara haria que los revisores me enviaran sus notas para anexarlas al archivo de presentacion , de esta manera se sabe de antemano quien esta enterado y quien no.

1. Algunas personas argumentan que una RTF debe valorar el estilo de programación, asi como la corrección. ¿esta es una buena idea?¿por que?

Sí , porque de esta manera se podrian estructurar habitos de programación , como la documentación de las lineas de codigo , descubrir errores de programación y que se sigan standares predefinidos , todo en un ambiente de cordialidad. Esto se puede hacer siempre y cuando se sigan con las ideas RTF que consisten en revisar el producto y no al productor, ya que al revisar el estilo de programación , se estaria mirando la forma particular de pensar del productor , dejando de lado el objetivo de la revision.

...