Guia de Estudio Sobre Calidad de Software

7/25/2019 Guia de Estudio Sobre Calidad de Software

1/10

Calidad de software

Parcial 1

Parte I

1. Principales requerimientos manejados por TSP (Tipo relacionado con).

Tipo de requerimientos Relacionado con

Funcionales Entradas, salidas, clculos y casos de uso.

De vinculacin del sistema con el exterior Usuarios, hardware, software, comunicacin conotras computadoraso dispositivos.

De software Manejadores de ases de datos, len!uajes,instalacin, etc.

De dise"o Estndares, compatiilidad, inte!racin con otrossistemas, etc.

#tros $e!uridad, mantenimiento, portailidad, etc.

%. FURPS (Funcionalit! Usa"ilit! Relia"ilit! Performance! Supporta"ilit)

Funcionalidad, Usailidad, &onfiailidad, 'endimiento, capacidad de soporte. factores

#tri"utos Su"atri"utos

Funcionalidad &onjunto de caracter(sticas &apacidades

)eneralidad $e!uridad

Facilidad de uso Factores humanos Est*tica

&onsistencia Documentacin

Fiailidad Frecuencia+$everidad de falla 'ecuperailidad redictailidad

recisin -iempo promedio de falla

'endimiento elocidad Eficiencia &onsumo de recursos

-hrou!hput -iempo de respuesta

&apacidad de soporte &apacidad de pruea Extensailidad /daptailidad Manteniilidad &ompatiilidad

&onfi!urailidad &apacidad de servicio &apacidad de instalacin &apacidad de locali0acin

$.#cti%idades que in%olucra la calidad del producto de software

/dministracin de la calidad

Uso de tecnolo!(a de 1n!enier(a de $oftware eficiente

/plicacin de t*cnicas formales a lo lar!o de todo el proceso de desarrollo

Minimi0acin de las variaciones entre productos


2/10

erificacin y prueas formales en las diferentes etapas del desarrollo

&ontrol de la documentacin

&orrecto mantenimiento y servicios de post2venta

&. 'isciplinas que in%olucra CI

1n!enier(a de sistema3 &ure la construccin de un sistema con o sin software

1n!enier(a de software3 &ure la construccin de soluciones software 1nte!racin de productos y procesos de desarrollo3 &ure la relacin a lar!o pla0o con el cliente

'elacin con proveedores3 &ure los procesos relacionados con la sucontratacin de partes delsistema

. #cti%idades a desarrollar en cada uno de los ciclos de TSP

Estrate!ia.

&rear un dise"o conceptual del producto

Estalecer la estrate!ia de desarrollo Estalecer el plan de administracin de la

confi!uracin

laneacin.

4acer una planificacin semanal

4acer un plan de calidad

/si!nar tareas a los miemros del e5uipo

'e5uerimientos.

Especificar re5uerimientos

/nali0ar necesidades del cliente

Desarrollar el documento dere5uerimientos

Dise"o.

&rear un dise"o de alto nivel

Especificar el dise"o 1nspeccionar el dise"o

1mplementacin.

Usar $ para implementar mdulos

-rasladar el dise"o al cdi!o

'evisar el cdi!o

-est.

roducir documentacin de los usuarios &rear prueas e inte!rarlas al sistema

ostmorten.

Escriir un reporte del ciclo

roducir evaluacin de las personas

Parte II

. Factores que determinan la calidad del software

Caracter*stica +om"re 'escripci,n#perativas &orreccin alorar si el software hace lo 5ue se espera de *l.

#perativas eficiencia $e utili0an ptimamente los recursos de la computadora.

#perativas Facilidad de uso 6a aplicacin ofrece una interfa0 adecuada al usuario.

#perativas 1nte!ridad Es se!uro con respecto a los datos.

$oporte a camios Facilidad demantenimiento

Estimar en 5u* medida el pro!rama es susceptile de sercorre!ido.

$oporte a camios Flexiilidad En 5u* medida el pro!rama es susceptile a ser camiado.


3/10

$oporte a camios Facilidad de pruea $i resulta fcil hacer prueas de su funcionamiento.

/daptailidad anuevos camios

'eusailidad 4asta 5u* punto se podr(a volver a usar parte de dichosoftware en otro proyecto.


Facilidad deinteroperacin

alorar si el software puede interactuar con otros sistemasinformticos.


ortailidad $i se puede usar en otra m5uina 5ue utilice un procesadordistinto.

Parte III

-. # randes rasos la calidad en el proeso de desarrollo se o"ser%a de la siuiente manera/

&alidad en el dise0o3 $e asa en definir un listado de especificaciones a se!uir7 involucra la

descripcin de los procesos de desarrollo, tareas y responsa"ilidadesde los e5uipos de desarrollo.Dichos procesos pueden estar estandari0ados.

&alidad en la implementaci,n/$e enfoca al !rado de cumplimientode los re5uerimientos de dise"o.

$i los re5uerimientos estn ien definidos y especificados, el cumplimiento de la calidaden esta faseno dee tornarse dif(cil.

&alidad en la satisfacci,n3 Es la medida de calidad apreciada por los usuarios finales de los

productos de software. 8o puede esperarse calidad en esta fase si no huo preocupacin por ella en las

etapas anteriores.

Parte I

2. +i%eles de C

+i%el 'escripci,n9. 1nicial roceso improvisado y a veces catico.

unto ase sin valor. 6a #r! opera sin procesos formali0ados. El *xito depende de las hailidades, conocimientos y motivacin

personal.6a capacidad es una cualidad de las personas, no de la or!ani0acin. $ealcan0a el propsito de manera inconsistente, no es planeado ni lleva unse!uimiento.

%. 'epetile rocesos sicos de !estin para manejar costos, crono!ramas y

funcionalidad estalecidos. 6a disciplina del proceso permite la repeticin de *xitos anteriores en

proyectos similares. 6a fuer0a de la or!ani0acin est dada por la existencia de experiencia

en desarrollo de procesos similares pero existen ries!os al presentarsenuevos desaf(os.

El proceso tiene disciplina por 5ue existe planeacin y se!uimiento, esdocumentado, es estale pero a:n as( no hay m*tricas para servicio, solo paraproductos.

;. Definido El proceso para !erentes e in!enieros est documentado e inte!rado en


4/10

un proceso estndar para la or!ani0acin. -odos los proyectos usan una versin aproada y adaptada del proceso

estndar de la or!ani0acin. Un !rupo de proceso de in!enier(a de software ha sido estalecido para

focali0ar y liderar esfuer0os de mejora.8ivel estndar y consistente !racias a las prcticas de in!enier(a de software yadministracin de proyectos, el proceso es estale y repetile.

si ? 8o@, lo 5ue no permite re!istrar losmatices de la realidad. >cr(ticas a &MM@

1:.9n C los niveles de madure0 no !aranti0an el *xito. Existen proyectos existosos en el nivel 9 yfracasos en niveles superiores. >cr(ticas a &MM@

otras cr*ticas a C

6a aplicacin del modelo re5uiere una inversin importante.

&ompara or!ani0aciones !randes con pe5ue"as favoreciendo a las primeras.

1$. CIproporciona compatiilidad con los principios, re5uisitos y recomendaciones de na nueva norma

1$# ABBB3%BBB >Mejora de &MM1@

otras mejoras de &MM1

Especial *nfasis sore la capacidad de los procesos y madure0 de la or!ani0acin en su conjunto >noexclusivamente en el rea de 1.$.@


5/10

Cnfasis sore las mejoras mediles y cuantificales para alcan0ar los ojetivos del ne!ocioempresarial.

1&. PSP es un re5uisito previo para la planificacin de una or!ani0acin para introducir el -$..

1. En la !estin ersonal de la calidad >PSP : :.1@ el ojetivo es encontrar y eliminar todos los defectosantes de lle!ar a la primera ejecucin.

1-. ;erramientas de apoo! :a


6/10

:. Propiedades de las m=tricas $implicidad3 la definicin y uso de la m*trica ha de ser simple. #jetividad3 diferentes personas han de darle valores id*nticos. Esto le da consistencia y evita

interpretaciones individuales. Facilidad de recoleccin3 el coste y esfuer0o para otener la medida ha de ser ra0onale. 'ouste03 la m*trica ha de ser insensile a camios irrelevantes. Esto permite reali0ar :tiles

comparaciones. alide03 la m*trica ha de medir lo 5ue se supone 5ue mide. Esto da fiailidad a la medida.

$. =tricas de tama0o M*tricas de tama"o

6#&3 6(neas de cdi!o 6(neas escalales en un m*todo Evalua

facilidad de comprensin, reutili0acin y facilidad de mantenimiento

su!erencia para descurir m*todos a dividir %< loc en & loc en $malltal

!ranularidad3 m*todo, clase, pro!rama, sistema

ciclo de vida3 implementacin 8o es recomendale para sistemas ## 8o es aceptale universalmente para medir el proceso de software

8:mero de mensajes enviados Mide n:mero de mensajes enviados en un m*todo

unarios inarios clave

$u!erencia3 umral de A mensajes


7/10

!ranularidad3 m*todo Ciclo de %ida/ Implementaci,n

&. >ndice de especiali?aci,n por clase (Specialisation Inde@ per ClassASIBA) Doren? Eidd! 177&

Muestra en 5u* medida las suclases redefinen el comportamiento de sus superclases Un valor de 9=G

. Da %isi,n de un componente como pro%eedor de ser%icios resalta dos caracter*sticas/ 9. El componente es una entidad ejecutale independiente. El cdi!o fuente no esta disponile por lo

5ue no hay 5ue compilarse antes de usarse. %. 6os servicios ofertados estn disponiles a trav*s de una interfa0 y las interacciones son a trav*s de

ella. $u estado interno nunca se muestra.-. Propiedades de un sistema "asado en CGTS

#dapta"le3 Un sistema deer(a tener una confi!uracin de componentes adaptales 5ue permita a loscomponentes una fcil incorporacin, eliminacin o ser reempla0ados.

#udita"le3 Un sistema es auditale si los inte!radores y !estores son capaces de ver y monitori0ar sucomportamiento interno

#"ierto3 Es a5uel 5ue ha sido construido acorde a estndares y tecnolo!(as aiertas lo cual permite5ue sea extendido e inte!rado.

Seuro3 6a se!uridad dee ser considerada a nivel ar5uitectnico donde deen implementarse laspol(ticas apropiadas.2. Incompati"ilidades de interfaces

9@ De parmetros3 6as operaciones tienen el mismo nomre pero los tipos o numero de parmetros sondistintos

%@ De operaciones3 6os nomres de las operaciones de las interfaces son diferentes. ;@ #peraciones incompletas3 6a interfa0 proporciona de un componentes es suconjunto de interfa0

re5uiere o viceversa.3. 'iccionario de datos

roporcionar un enfo5ue or!ani0ado para representar las caracter(sticas de cada ojeto de datos yelemento de control.

Es un listado or!ani0ado de todos los elementos de datos 5ue son pertinentes para el sistema, condefiniciones precisas y ri!urosas 5ue permiten 5ue el usuario y el analista del sistema ten!an una mismacomprensin de las entradas, salidas, de las componentes de los almacenes y tami*n de los clculosintermedios. &ontiene3

8omre3 el nomre principal del elemento de datos o de control, del almac*n de datos, o de unaentidad externa.

/lias3 otros nomres usados para la primera entrada. Dnde se usa+cmo se usa3 un listado de los procesos 5ue usan el elemento de datos o de control y

cmo lo usan >entrada al proceso, salida del proceso, almac*n de datos, entidad externa@.

Descripcin del contenido3 el contenido representado mediante una notacin. 1nformacin adicional3 otra informacin sore los tipos de datos, los valores impl(citos >si se

conocen@, las restricciones o limitaciones,7. Tipos de interfaces de un componente

1) Proporciona/ Es el /1 y define los servicios, se indican con un c(rculo al final de una l(nea desdeel icono del componente.

%@ Requiere3 5ue especifica 5ue servicios deen ser proporcionados por otros componentes, nocompromete la independencia o desplie!ue ya 5ue no se re5uiere un componente especifico, seindican con un semic(rculo.

=tricas internas son aquellas que no dependen de la ejecuci,n del software (medidas estHticas).


8/10

=tricas e@ternas son aquellas aplica"les al software en ejecuci,n.Parte II

Identificaci,n de los o"jetos clases Dos o"jetos se manifiestan de aluna de las siuientes formas/

9ntidades e@ternas3 otros sistemas, dispositivos, personas7 5ue producen o consumeninformacin a usar por un sistema computacional7

Cosas3 informes, presentaciones, cartas, se"ales7 5ue son parte del dominio de informacin del

prolema7 Gcurrenciasosucesos3 una transferencia de propiedad o la terminacin de una serie de movimientos

en un root7 5ue ocurren dentro del contexto de una operacin del sistema7 Papelesoroles3 director, in!eniero, vendedor7 desempe"ados por personas 5ue interact:an con el

sistema7 Unidadesorani?acionales3 divisin, !rupo, e5uipo7 5ue son relevantes en una aplicacin7 Duares3 planta de produccin o muelle de car!a7 5ue estalecen el contexto del prolema y la

funcin !eneral del sistema7 9structuras3 sensores, veh(culos de cuatro ruedas o computadoras7 5ue definen una clase de ojetos

o, en casos extremos, clases relacionadas de ojetos.Parte III

Coad ourdon suieren seis caracter*sticas de selecci,n a usar cada %e? que un analista considerasi inclue o no un o"jeto potencial en el modelo de anHlisis/ Informaci,n retenida3 el ojeto potencial ser de utilidad durante el anlisis solamente si la

informacin acerca de *l dee recordarse para 5ue el sistema funcione. Ser%icios necesarios3 el ojeto potencial dee poseer un conjunto de operaciones identificales 5ue

pueden camiar de al!una manera el valor de sus atriutos. #tri"utos m4ltiples/durante el anlisis de re5uisitos, se dee centrar la atencin en la informacin

principal >un ojeto con un solo atriuto puede, en efecto, ser :til durante el dise"o, pero se!uramenteser mejor presentado como un atriuto de otro ojeto durante la actividad de anlisis@7

#tri"utos comunes/puede definirse un conjunto de atriutos para el ojeto potencial, los cuales son

aplicales a todas las ocurrencias del ojeto. Gperaciones comunes/puede definirse un conjunto de operaciones para el ojeto potencial, lascuales son aplicales a todas las ocurrencias del ojeto7

Requisitos esenciales/entidades externas 5ue aparecen en el espacio del prolema y producen oconsumen informacin esencial para la produccin de cual5uier solucin para el sistema, sern casisiempre definidas como ojetos en el modelo de re5uisitos.

Parte I


9/10

Parte Componentes comerciales

aterial9@tra


10/10

Documents

Guia de Estudio Sobre Calidad de Software