Guia ST

7/30/2019 Guia ST

1/70

GUA DE DISEO DE LASOLUCIN TCNICA

Laboratorio Nacional de Calidad delSoftware

Noviembre 2009

7/30/2019 Guia ST

2/70

Gua de Gua de Diseo de la Solucin Tcnica 2

El Instituto Nacional de Tecnologas de la Comunicacin, S.A. (INTECO), es unasociedad estatal adscrita al Ministerio de Industria, Turismo y Comercio a travs de laSecretara de Estado de Telecomunicaciones y para la Sociedad de la Informacin.

INTECO tiene la vocacin de ser un centro de desarrollo de carcter innovador y de interspblico a nivel nacional que constituye una iniciativa enriquecedora y difusora de las nuevastecnologas en Espaa en clara sintona con Europa.

Su objetivo fundamental es servir como instrumento para desarrollar la Sociedad de laInformacin, con actividades propias en el mbito de la innovacin y el desarrollo deproyectos asociados a las Tecnologas de la Informacin y la Comunicacin (TIC),basndose en tres pilares fundamentales: la investigacin aplicada, la prestacin deservicios y la formacin.

La misin de INTECO es aportar valor e innovacin a los ciudadanos, a las PYMES, a lasAdministraciones Pblicas y al sector de las tecnologas de la informacin, a travs deldesarrollo de proyectos que contribuyan a reforzar la confianza en los servicios de laSociedad de la Informacin en nuestro pas, promoviendo adems una lnea de participacininternacional.

Para ello, INTECO desarrolla actuaciones en las siguientes lneas:

Seguridad Tecnolgica: INTECO est comprometido con la promocin de servicios de laSociedad de la Informacin cada vez ms seguros, que protejan los datos personales de losinteresados, su intimidad, la integridad de su informacin y eviten ataques que pongan enriesgo los servicios prestados. Y por supuesto que garanticen un cumplimiento estricto de lanormativa legal en materia de TIC. Para ello coordina distintas iniciativas pblicas en torno ala seguridad de las TIC, que se materializan en la prestacin de servicios por parte delObservatorio de la Seguridad de la Informacin, el Centro Demostrador de Tecnologas deSeguridad, el Centro de Respuesta a Incidentes de Seguridad en Tecnologas de laInformacin (INTECO-CERT) y la Oficina de Seguridad del Internauta (OSI), de los que sebenefician ciudadanos, PYMES, Administraciones Pblicas y el sector tecnolgico.

Accesibilidad: INTECO promueve servicios de la Sociedad de la Informacin msaccesibles, que supriman las barreras de exclusin, cualquiera que sea la dificultad ocarencia tcnica, formativa, etc., incluso discapacidad, que tengan sus usuarios. Y quefaciliten la integracin progresiva de todos los colectivos de usuarios, de modo que todosellos puedan beneficiarse de las oportunidades que ofrece la Sociedad de la Informacin.Asimismo desarrolla proyectos en el mbito de la accesibilidad orientados a garantizar elderecho de ciudadanos y empresas a relacionarse electrnicamente con las AA.PP.

Calidad TIC. INTECO promueve unos servicios de la Sociedad de la Informacin que cadavez sean de mayor calidad, que garanticen unos adecuados niveles de servicio, lo cual setraduce en una mayor robustez de aplicaciones y sistemas, un compromiso en ladisponibilidad y los tiempos de respuesta, un adecuado soporte para los usuarios, una

informacin precisa y clara sobre la evolucin de las funcionalidades de los servicios, y en

7/30/2019 Guia ST

3/70

Gua de Diseo de la Solucin Tcnica 3

resumen, servicios cada vez mejores. En esta lnea impulsa la competitividad de la industriadel Software a travs de la promocin de la mejora de la calidad y la certificacin de las

empresas y profesionales de la ingeniera del software.

Formacin: la formacin es un factor determinante para la atraccin de talento y para lamejora de la competitividad de las empresas. Por ello, INTECO impulsa la formacin deuniversitarios y profesionales en las tecnologas ms demandadas por la industria.

7/30/2019 Guia ST

4/70


NOTA DE EDICINEsta gua ha sido desarrollada por el Laboratorio Nacional de Calidad del Software deINTECO. Esta primera versin ha sido editada en Noviembre del 2009.

Copyright 2009 Instituto Nacional de Tecnologas de la comunicacin (INTECO)

El presente documento est bajo la licencia Creative Commons Reconocimiento-No comercial-Compartir Igual versin2.5 Espaa.Usted es libre de:- copiar, distribuir y comunicar pblicamente la obra- hacer obras derivadas

Bajo las condiciones siguientes:- Reconocimiento. Debe reconocer los crditos de la obra de la manera especificada por el autor o el licenciador

(pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).- No comercial. No puede utilizar esta obra para fines comerciales.- Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, slo puede

distribuir la obra generada bajo una licencia idntica a sta.

Al reutilizar o distribuir la obra, tiene que dejar bien claro los trminos de la licencia de esta obra.Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autorNada en esta licencia menoscaba o restringe los derechos morales del autor.Esto es un resumen legible por humanos del texto legal (la licencia completa) disponible enhttp://creativecommons.org/licenses/by-nc-sa/2.5/es/

El presente documento cumple con las condiciones de accesibilidad del formato PDF (Portable Document Format).

Se trata de un documento estructurado y etiquetado, provisto de alternativas a todo elemento no textual, marcado deidioma y orden de lectura adecuado.

Para ampliar informacin sobre la construccin de documentos PDF accesibles puede consultar la gua disponible en laseccinAccesibilidad > Formacin > Manuales y Guasde la pginahttp://www.inteco.es.
http://creativecommons.org/licenses/by-nc-sa/2.5/es/http://creativecommons.org/licenses/by-nc-sa/2.5/es/http://www.inteco.es/Accesibilidad/Formacion_6/Manuales_y_Guiashttp://www.inteco.es/Accesibilidad/Formacion_6/Manuales_y_Guiashttp://www.inteco.es/Accesibilidad/Formacion_6/Manuales_y_Guiashttp://www.inteco.es/http://www.inteco.es/http://www.inteco.es/http://www.inteco.es/http://www.inteco.es/Accesibilidad/Formacion_6/Manuales_y_Guiashttp://creativecommons.org/licenses/by-nc-sa/2.5/es/

7/30/2019 Guia ST

5/70


AVISO LEGAL

- CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por laUniversidad Carnegie Mellon.

- Las distintas normas ISO mencionadas han sido desarrolladas por la InternationalOrganization for Standardization.

Todas las dems marcas registradas que se mencionan, usan o citan en la presente guason propiedad de los respectivos titulares.

INTECO cita estas marcas porque se consideran referentes en los temas que se tratan,buscando nicamente fines puramente divulgativos. En ningn momento INTECO busca con

su mencin el uso interesado de estas marcas ni manifestar cualquier participacin y/oautora de las mismas.

Nada de lo contenido en este documento debe ser entendido como concesin, porimplicacin o de otra forma, y cualquier licencia o derecho para las Marcas Registradasdeben tener una autorizacin escrita de los terceros propietarios de la marca.

Por otro lado, INTECO renuncia expresamente a asumir cualquier responsabilidadrelacionada con la publicacin de las Marcas Registradas en este documento en cuanto aluso de ninguna en particular y se eximen de la responsabilidad de la utilizacin de dichasMarcas por terceros.

El carcter de todas las guas editadas por INTECO es nicamente formativo, buscando entodo momento facilitar a los lectores la comprensin, adaptacin y divulgacin de lasdisciplinas, metodologas, estndares y normas presentes en el mbito de la calidad delsoftware.

7/30/2019 Guia ST

6/70


NDICE

1. INTRODUCCIN 10

2. SOLUCIN TCNICA DENTRO DE CMMI 11

2.1. Metas y Prcticas especficas 11

2.2. reas de proceso relacionadas 12

3. SELECCIN DE LA SOLUCIN 13

3.1. Desarrollo soluciones alternativas y criterios de seleccin 13

3.1.1. Asignacin de requisitos a la solucin 14

3.1.2. Evaluacin del uso de productos COTS 15

3.2. Seleccin de soluciones 16

4. DESARROLLO DEL DISEO 18

4.1. Disear el producto o componente de producto 18

4.1.1. Diseo preliminar 18

4.1.2. Diseo detallado 22

4.1.3. Documentacin de diseo 23

4.1.4. Mtodos de diseo 25

4.2. Paquete de datos tcnicos 27

4.3. Diseo de interfaces 29

4.4. Realizar los anlisis sobre si desarrollar, comprar o reutilizar 30

4.4.1. Anlisis make-or-buy 31

5. IMPLEMENTACIN DEL DISEO DEL PRODUCTO 32

5.1. Mtodos para la implementacin 33

5.2. Pruebas unitarias 34

5.3. Documentacin de soporte 355.3.1. Estndares de documentacin 36

6. ANEXOS:ARTEFACTOS RELACIONADOS CON LA SOLUCIN TCNICA 38

6.1. Proceso para el Diseo 38

6.1.1. Objetivos 38

6.1.2. Alcance 38

6.1.3. Criterios de entrada 38

6.1.4. Entradas 38

6.1.5. Descripcin del proceso 38

7/30/2019 Guia ST

7/70


6.1.6. Recomendaciones 41

6.1.7. Adaptaciones permitidas 41

6.1.8. Medidas 41

6.1.9. Validaciones 41

6.1.10. Registros de calidad 42

6.1.11. Criterios de salida 42

6.1.12. Referencias 42

6.1.13. Matriz de perfiles en el proceso 43

6.2. Lista de control para el diseo preliminar 44

6.3. Lista de control para el diseo detallado 46

6.4. Plantilla de diseo preliminar 496.4.1. Visin General del proyecto 49

6.4.2. Representacin de la Arquitectura 50

6.4.3. Vista de Casos de Uso 52

6.4.4. Vista Lgica 52

6.4.5. Vista de Interaccin 53

6.4.6. Vista de Seguridad 53

6.4.7. Vista del proceso 53

6.4.8. Vista del Despliegue 53

6.4.9. Vista de Implementacin 54

6.4.10. Vista de Datos 54

6.4.11. Vista de Administracin 54

6.4.12. Caractersticas Generales de Calidad 55

6.5. Plantilla de diseo detallado 55

6.5.1. Introduccin 55

6.5.2. Descripcin general 56

6.5.3. Especificacin de la arquitectura del software 59

6.5.4. Especificacin de la interfaz 616.5.5. Especificacin orientada a la funcin 61

6.5.6. Especificacin orientada a objetos 63

6.5.7. Especificacin orientada a datos 64

6.5.8. Caractersticas generales sobre calidad 66

6.5.9. Incidencias, asuntos y temas abiertos 67

7. GLOSARIO 68

8. REFERENCIAS 70

7/30/2019 Guia ST

8/70


NDICE DE FIGURAS

Figura 1. Enfoque tradicional ................................................................................................20

Figura 2. Enfoque evolutivo ..................................................................................................21

7/30/2019 Guia ST

9/70


NDICE DE TABLAS

Tabla 1. Beneficios y desventajas del uso de productos COTS ............................................16

Tabla 2. Tareas de definicin de la arquitectura ...................................................................19

Tabla 3. Consideraciones del desarrollo interno y externo ...................................................31

Tabla 4. Roles del proceso de diseo ...................................................................................43

Tabla 5. Componentes y frameworks reutilizados ................................................................51

Tabla 6. Componentes y frameworks reutilizables ................................................................52

Tabla 7. Mapeo del diseo a los requisitos I .........................................................................60

Tabla 8. Mapeo del diseo a los requisitos II ........................................................................61

Tabla 9. Mapeo del diseo a los requisitos III .......................................................................63

Tabla 10. Mapeo del diseo a los requisitos IV ....................................................................64

Tabla 11. Mapeo del diseo a los requisitos V .....................................................................66

Tabla 12. Mapeo del diseo a los requisitos VI ....................................................................67

Tabla 13. Registro de incidencias .........................................................................................67

7/30/2019 Guia ST

10/70


1. INTRODUCCIN

La gua de Diseo de la Solucin Tcnica est orientada al rea de proceso de CMMI deSolucin Tcnica. Pretende ser una gua de apoyo a la implementacin de dicha rea deproceso y de sus metas y actividades.

En la primera parte de la misma se definir y situar esta rea de proceso dentro del modelode CMMI y se ver la relacin que tiene con otras reas de proceso del modelo.

El resto de la gua se centrar en la implementacin de todas las metas y actividades quepropone el modelo, resaltando en muchos casos los mtodos, estndares y herramientasque se pueden utilizar para la implementacin de dichas metas y actividades.

Por ltimo, se han incluido en el apartado de anexos, una serie de artefactos que puedenayudar en la implementacin de dicha rea de proceso.

7/30/2019 Guia ST

11/70


2. SOLUCIN TCNICA DENTRO DE CMMI

El propsito de la solucin tcnica es disear, desarrollar e implementar soluciones para losrequisitos. Las soluciones, los diseos y las implementaciones engloban productos,componentes de producto y procesos del ciclo de vida asociados al producto,individualmente o en combinacin, segn sea apropiado.

Esta rea de proceso es aplicable en cualquier nivel de la arquitectura de producto y a cadaproducto, componente de producto y proceso del ciclo de vida asociado al producto.

La solucin tcnica se centra en:

- Evaluar y seleccionar soluciones que potencialmente satisfacen un conjunto de

requisitos asignados.

- Desarrollar diseos detallados para las soluciones seleccionadas.

- Implementar los diseos.

Cuando el rea de proceso de solucin tcnica no se gestiona como es debido puedesuceder lo siguiente:

- Que se elija una solucin que no sea efectiva.

- Que los productos no cumplan los requisitos de rendimiento tcnico o las

necesidades de los usuarios.

- Que se incrementen las pruebas y el retrabajo para resolver cuestiones relacionadas

con el diseo.

- Que el producto no se adapte a mejoras en la tecnologa o a un crecimiento futuro.

2.1. METAS Y PRCTICAS ESPECFICAS

El rea de proceso de CMMI Solucin Tcnica seala las siguientes metas y prcticasespecficas:

SG1. Seleccionar soluciones para los componentes de producto.

SP1.1 Desarrollar soluciones alternativas y criterios de seleccin.

SP1.2 Seleccionar soluciones para los componentes de producto.

SG2. Desarrollar el diseo.

SP2.1 Disear el producto o componente de producto.

7/30/2019 Guia ST

12/70


SP2.2 Establecer un paquete de datos tcnicos.

SP2.3 Disear las interfaces utilizando criterios.

SP2.4 Analizar las opciones de desarrollo, compra o reutilizacin.

SG3. Implementar el diseo del producto.

SP3.1 Implementar el diseo.

SP3.2 Desarrollar la documentacin de soporte del producto.

2.2. REAS DE PROCESO RELACIONADAS

Las metas y actividades que forman parte del rea de proceso Solucin Tcnica (TS) estnrelacionadas con metas y actividades de otras reas de proceso de CMMI. A lo largo de lagua se van a ir comentando algunas de estas relaciones, aunque en este apartado se harun pequeo resumen de las mismas.

Una de las reas con la que est relacionada es Desarrollo de Requisitos (RD), ya que enambas se llevan a cabo actividades relacionadas con la asignacin de requisitos, elestablecimiento de un concepto operacional y la definicin de los requisitos de interfaz quese han de disear en esta rea de proceso.

Durante la implementacin de algunas de las metas hay que llevar a cabo revisiones entrepares y verificaciones del producto y componentes de producto, para lo que se puedeobtener ms informacin en el rea de proceso de Verificacin (VER).

En esta rea de proceso se llevan a cabo una serie de evaluaciones y toma de decisionesque se pueden apoyar en el rea de proceso de Anlisis de decisiones y resolucin (DAR).

Algunas prcticas especficas del rea de proceso de Gestin de requisitos (REQM) serealizan interactivamente con las del rea de proceso de Solucin tcnica, por lo quetambin se ha de revisar.

Y por ltimo, para obtener ms informacin sobre la mejora de la tecnologa de laorganizacin, se puede consultar el rea de proceso Innovacin y despliegue en laorganizacin (OID).

7/30/2019 Guia ST

13/70


3. SELECCIN DE LA SOLUCIN

Qu es lo que hace que consideremos un producto o servicio exitoso? El coste, soporte,tiempo de respuesta, fiabilidad, etc.? Estas caractersticas se consiguen a travs de unaidentificacin y evaluacin concienzuda de diferentes soluciones alternativas.

Hay que considerar las soluciones alternativas y los beneficios asociados para poderseleccionar la mejor solucin. Para la seleccin de dicha solucin hay que tener en cuentarequisitos clave, cuestiones de diseo, restricciones, caractersticas arquitectnicas,

Se han de tomar decisiones en cuanto a la arquitectura, al desarrollo frente al uso deproductos COTS (Commercial off-the-shelf) y la modularizacin de componentes de

producto, entre otras.Las soluciones alternativas no son slo formas diferentes de tratar los mismos requisitos,sino que tambin reflejan una asignacin diferente de los requisitos a los componentes deproducto que abarcan la solucin. A la hora de definir o evaluar una solucin alternativa, sehan de tratar los componentes de forma conjunta. Por ejemplo, no hay que seleccionar unproducto COTS o una tecnologa prometedora sin considerar los impactos y los riesgos.

3.1. DESARROLLO SOLUCIONES ALTERNATIVAS Y CRITERIOS DE

SELECCIN

Se han de identificar y analizar soluciones alternativas para permitir la seleccin de unasolucin equilibrada en trminos de coste, planificacin, rendimiento y calidad.

A la hora de seleccionar la solucin es importante que se involucre a las partes implicadasen el negocio. Se han de considerar un amplio rango de soluciones alternativas. Lainvolucracin de las personas con diferentes habilidades y conocimientos puede ayudar alos equipos a identificar y tratar las suposiciones, restricciones y prejuicios. Se puedenrealizar sesiones de brainstormingpara estimular alternativas innovadoras.

Para poder seleccionar una solucin de entre las alternativas que se han desarrollado habrque contar con una serie de criterios de seleccin que tambin se han de definir. Durante la

seleccin de criterios hay que tener en cuenta el coste, la planificacin, el rendimiento y losriesgos. La forma en la que se definirn estos criterios en detalle depender de losrequisitos.

Entre las consideraciones a tener en cuenta para la seleccin de las soluciones alternativasy los criterios de seleccin se incluyen las siguientes:

- Coste de desarrollo, fabricacin, compra, mantenimiento y soporte, etc.

- Rendimiento de las soluciones.

7/30/2019 Guia ST

14/70


- Complejidad de los componentes de producto y los procesos del ciclo de vida

relacionados con el producto.

- Robustez del funcionamiento del producto y las condiciones de uso, modos de

operacin, entornos y variaciones en los procesos del ciclo de vida relacionados con

el producto.

- Expansin y crecimiento del producto.

- Limitaciones de la tecnologa.

- Riesgos.

- Evolucin de los requisitos y de la tecnologa.

- Retirada del producto.

- Capacidades y limitaciones de los usuarios finales y los operadores.

- Caractersticas de los productos COTS.

Estas son consideraciones bsicas que las organizaciones debern refinar para que sean

consistentes con los objetivos de su negocio.Una vez que se han seleccionado los distintos criterios que se van a tener en cuenta a lahora de seleccionar la mejor solucin alternativa, hay que ver de qu manera se va apuntuar cada uno de estos criterios para cada una de las posibles soluciones. Para realizaresta seleccin se pueden asignar distintos pesos a los criterios, en base a las circunstanciasdel proyecto y de esta manera obtener una puntuacin ponderada para cada una de lassoluciones. De esta manera se obtendr un ranking de todas las soluciones.

3.1.1. Asignacin de requisitos a la solucin

La asignacin de requisitos se trata en una de las prcticas especficas del Desarrollo deRequisitos, la cual describe la asignacin de requisitos una vez que se ha seleccionado unasolucin. Sin embargo, tambin se puede realizar una asignacin provisional antes de laseleccin para ayudar en la comprensin de los beneficios relacionados con una solucinalternativa.

Como se coment al principio del apartado, las soluciones reflejan la asignacin de losrequisitos a los componentes del producto y se ha de ver como un conjunto. El objetivo esoptimizar dicho conjunto como un todo.

La asignacin de requisitos debera quedar registrada en algn documento que permita

mantener la trazabilidad de los requisitos con los componentes de producto.

7/30/2019 Guia ST

15/70


3.1.2. Evaluacin del uso de productos COTS

En este apartado se explicar qu son los productos COTS y cmo se puede llevar a cabola evaluacin de su uso para la seleccin de la solucin.

COTS (Commercial off-the-shelf), es un adjetivo que describe productos software ohardware listos para usarse y disponibles para la compra por el pblico general. Losproductos COTS estn diseados para ser implementados fcilmente en sistemasexistentes sin necesidad de muchas modificaciones. Los productos COTS se pueden utilizarcon o sin modificacin, cosa que tambin hay que decidir en el momento de realizar laseleccin. Muchas veces cuando se usan productos COTS hace falta que se modifiquenaspectos como pueden ser las interfaces.

Si la decisin es adquirir un producto COTS, los requisitos deberan tenerse en cuenta paraestablecer el acuerdo con proveedores.

Al nivel ms abstracto, se pueden considerar tres tareas a gran escala que habra querealizar al evaluar productos COTS:

- Planificar la evaluacin (definir el problema, valorar los riesgos de la decisin,

identificar a las personas involucradas en el negocio, identificar las alternativas,)

- Disear el mecanismo de evaluacin (especificar los criterios de evaluacin, definir el

enfoque de la evaluacin, seleccionar las tcnicas,)

- Aplicar el mecanismo de evaluacin.

Entre los beneficios y desventajas que se pueden obtener del uso de productos COTSpodemos encontrar:

7/30/2019 Guia ST

16/70


Tabla 1. Beneficios y desventaj as del uso de pr oductos COTS

Beneficios Desventajas

Reduccin de los costes de desarrollo

Adaptacin ms rpida a las nuevastecnologas

Reduccin del tiempo de desarrollo

Reduccin de los riesgos de desarrollo

Integracin de productos COTS con otroscomponentes

No disponibilidad de las caractersticas a tiempo(vaporware)

Con frecuencia la correccin de errores slo estdisponible en versiones tardas

Algunas caractersticas no conocidas del productoCOTS pueden impactar en el sistema

Algunas caractersticas no requeridas puedenaumentar los requisitos de recursos

Soporte a largo plazo de productos COTS(supervivencia de los proveedores, evolucin decaractersticas)

3.2. SELECCIN DE SOLUCIONES

Una vez que se cuenta con distintas soluciones alternativas y con los criterios de seleccinadecuados hay que hacer la eleccin de la solucin que mejor satisfaga los criteriosestablecidos. Ninguna solucin ser la mejor para todos los criterios. Habr que seleccionaruna solucin que proporcione un equilibrio entre coste, planificacin, rendimiento y riesgosdurante el ciclo de vida del producto.

Elegir una solucin alternativa puede requerir un proceso de evaluacin formal que se centreen las alternativas identificadas contra los criterios establecidos. El rea de proceso deCMMI DAR puede ayudar en la seleccin de la mejor solucin alternativa que satisfaga lasnecesidades de la solucin tcnica del proyecto. DAR propone una buena toma de

decisiones mediante:

- Seleccin de una tcnica y nivel de estructura de la toma de decisin.

- Identificacin de criterios que sern la base de la decisin:

El criterio debera tratar el diseo de cuestiones de la vida del producto, talescomo provisiones para una insercin fcil de nuevas tecnologas o lacapacidad de utilizar mejor los productos comerciales existentes.

7/30/2019 Guia ST

17/70


Los criterios necesarios para las tcnicas de toma de decisiones van desdedecisiones basadas en consenso hasta el uso de modelos de probabilidad y

teoras de decisin.

- Identificacin de alternativas.

- Evaluacin de las alternativas contra los criterios.

La seleccin final de una alternativa debera estar acompaada de:

- La tcnica, los criterios y las alternativas de seleccin.

- El fundamento de la seleccin de la solucin final.

- El fundamento de no seleccionar las otras soluciones alternativas.

Hay que establecer y mantener la documentacin de las soluciones, evaluaciones y lasrazones de la seleccin. Esto ayudar a la hora de querer examinar posteriormente por quse seleccion una solucin en particular.

Aunque siempre se debera considerar el uso de tcnicas de anlisis de decisin formales,las pautas siguientes pueden ayudar a la hora de decidir si utilizar tcnicas de decisionesformales.

Se deberan utilizar tcnicas de decisiones formales en los siguientes casos:

- Cuando una decisin est directamente relacionada con cuestiones evaluadas con

un riesgo medio o alto.

- Cuando una decisin est relacionada con productos de trabajo que se encuentran

inmersos en un proceso de cambio y que se encuentran bajo gestin de la

configuracin.

- Cuando una decisin pudiera causar retrasos en la planificacin.

- Cuando una decisin tiene un impacto en la capacidad de conseguir los objetivos del

proyecto.

Si durante la evaluacin se concluye que los criterios de seleccin no son suficientementecompletos o detallados para diferenciar adecuadamente las soluciones alternativas, setendr que volver a definir dichos criterios y volver a empezar con la seleccin.

7/30/2019 Guia ST

18/70


4. DESARROLLO DEL DISEO

Una vez que se ha seleccionado la solucin, habr que pasar al desarrollo del diseo. Undiseo describe los componentes de un producto y sus interconexiones. Adems, gua lasactividades de un amplio rango de personas involucradas en el negocio, incluyendodesarrolladores, tcnicos de pruebas, instaladores y personal encargado del mantenimiento.

4.1. DISEAR EL PRODUCTO O COMPONENTE DE PRODUCTO

Los diseos de los productos o componentes de producto deben proporcionar el contenidoapropiado para llevar a cabo las distintas fases del ciclo de vida del producto:implementacin, modificacin, mantenimiento, sustento e instalacin. El diseo del productoconsiste en dos amplias fases que se pueden superponer durante la ejecucin: diseopreliminar y diseo detallado.

Al final de la gua se han incluido una serie de anexos en los que se pueden encontrardistintos artefactos que pueden ayudar a la hora de llevar a cabo las actividadesrelacionadas con la Solucin Tcnica. El primero de estos artefactos es un posible Procesopara el Diseo.

Una vez que se ha desarrollado el diseo habr que comprobar que es adecuado. Para ellose puede hacer uso de listas de comprobacin para revisar que tanto el diseo preliminarcomo el detallado son completos. En el anexo podemos ver un ejemplo de dichaslistas de

comprobacin.

4.1.1. Diseo preliminar

El diseo preliminar establece las capacidades del producto y la arquitectura del producto osistema, incluyendo identificaciones de componentes de producto, estados y modos delsistema, interfaces,

La definicin de la arquitectura requiere que:

- Existan una serie de procesos que deben llevarse a cabo para que el sistema cumpla

las funciones definidas.

- Los procesos individuales transformen los datos que fluyen a travs de ellos.

- Los procesos, actividades u operaciones sigan las reglas que establecen las

condiciones bajo las que tienen que ocurrir.

- Se describan los componentes que implementarn el diseo (hardware, software,

personal e instalaciones)

7/30/2019 Guia ST

19/70


La definicin de la arquitectura est conducida por un conjunto de requisitos arquitectnicosdesarrollados durante el proceso de desarrollo de requisitos. La arquitectura define los

elementos estructurales y los mecanismos de coordinacin que satisfarn los requisitos amedida que los detalles del diseo del producto se establecen.

La utilizacin de estndares organizacionales puede ayudar a conseguir consistencia ycompletitud en el diseo.

Son muchas las tareas que hay que realizar dentro de la definicin de la arquitectura. Acontinuacin, se muestra una tabla con algunas de ellas:

Tabla 2. Tareas de definicin de la arquitect ura

Definicin de la arquitectura

Identificar las interfaces internas importantes y todas las interfaces externas

Identificar los componentes de productos y las interfaces entre ellos

Definir los mecanismos de coordinacin

Establecer las capacidades y los servicios de infraestructura

Desarrollar plantillas y frameworksde los componentes de productos

Establecer reglas de diseo y la autoridad para la toma de decisiones

Definir un modelo de proceso/flujo de ejecucin

Definir el despliegue del software al hardware

Identificar las principales fuentes y enfoques de reutilizacin

Para la realizacin del diseo se pueden utilizar conceptos y escenarios operativos quepermiten generar casos de uso y escenarios de calidad para refinar la arquitectura. Tambinse utilizan como medio para evaluar la idoneidad de la arquitectura para su uso previsto.Esta revisin se lleva a cabo durante las evaluaciones de la arquitectura, que se realizan deforma peridica durante el diseo del producto.

Un escenario es una secuencia de eventos que pueden ocurrir durante la utilizacin delproducto, y que se utiliza para hacer explcitas las necesidades de las personasinvolucradas en el negocio. Por el contrario, un concepto operativo para un productodepende normalmente de la solucin de diseo y del escenario. Debido a que las soluciones

alternativas normalmente no se han definido cuando se preparan los conceptos operativos

7/30/2019 Guia ST

20/70


iniciales, se desarrollan soluciones conceptuales para usarlas cuando se analizan losrequisitos. Los conceptos operativos se refinan a medida que se toman las decisiones de las

soluciones y a medida que se desarrollan los requisitos detallados, a un nivel ms bajo.

Al igual que una decisin para un producto se puede convertir en un requisito decomponentes de producto, los conceptos operativos pueden convertirse en escenarios(requisitos) de componentes de productos. Los conceptos y escenarios operativos sedesarrollan para facilitar la seleccin de soluciones de componentes de producto, quecuando se implementen, satisfarn el uso previsto del producto. Los conceptos y escenariosoperativos documentan la interaccin de los componentes de producto con el entorno, losusuarios y otros componentes de producto.

Los escenarios pueden incluir secuencias operativas, siempre que tales secuencias sean

una expresin de los requisitos del cliente ms que conceptos operativos.

4.1.1.1. Enfoque tradicional de la arquitectura de sistemas

Como se ha mencionado al inicio del apartado, durante el diseo preliminar se establece laarquitectura del producto. En este apartado y en el que viene a continuacin se tratarntanto un enfoque tradicional como uno evolutivo de la arquitectura de sistemas.

Se han desarrollado muchas metodologas para el soporte de un modelo de desarrollo desistemas tradicional. Los pasos consisten normalmente en la definicin de requisitos, laconsideracin de varias opciones y la obtencin de un diseo bien definido a travs de un

proceso de eliminacin. Esto se ilustra es la siguiente figura:

Figura 1 . Enfoque tr adicional

Tiempo

OPCIO

NES

DISE

O

El enfoque tradicional es efectivo cuando los requisitos estn bien definidos y se mantienenconstantes durante el periodo de desarrollo del sistema. Si la implementacin del sistema eslarga, los requisitos pueden evolucionar debido a cambios y a nuevas tecnologas que

7/30/2019 Guia ST

21/70


ofrezcan una serie de alternativas y oportunidades que el enfoque tradicional no puedemanejar.

4.1.1.2. Enfoque evolutivo de la arquitectura de sistemas

Otro enfoque de la arquitectura de sistemas es el enfoque evolutivo y est orientado a tratarla incertidumbre de requisitos y de la tecnologa, especialmente para sistemas con untiempo de desarrollo y una vida til del producto largos. Este enfoque se ilustra en la figuraque aparece a continuacin. Al contrario que con el enfoque anterior, con ste se permiteque:

- Los requisitos sean ms abstractos y por lo tanto, estn sujetos a interpretacin.

- Las soluciones alternativas se exploren y se busquen tan lejos como estndisponibles las opciones de nuevas tecnologas.

- Los diseos intermedios se guarden y algunos de ellos se implementen comoprototipos, pero no se implementen de forma operativa. Otros son implementados deforma tradicional.

En cualquier momento del proceso de desarrollo, cuando hay una necesidad de construir unsistema, se selecciona e implementa la solucin disponible que mejor cumpla los requisitosactuales usando cualquier enfoque de ingeniera de sistemas.

Figura 2. Enfoque evolutivo

P

R

O

B

L

E

MA

S

O

L

U

C

I

O

NE

S

Tiempo

Soluciones que llevan al diseo

La arquitectura puede incluir estndares y reglas de diseo gobernando el desarrollo de loscomponentes de producto y sus interfaces, as como sirviendo de gua para losdesarrolladores del producto. En el contexto de los requisitos arquitectnicos, se puedendesarrollar y analizar mltiples arquitecturas para el soporte de soluciones alternativas paradeterminar las ventajas y desventajas.

7/30/2019 Guia ST

22/70


4.1.2. Diseo detallado

Durante el diseo detallado, se finalizan los detalles de la arquitectura del producto y sedefinen completamente los componentes del producto y las interfaces. Los desarrolladorespueden evaluar el uso de productos heredados o productos COTS. A medida que el diseomadura, se hace un seguimiento de los requisitos asignados a componentes de producto denivel ms bajo para asegurar que dichos requisitos se satisfacen.

Con frecuencia se establecen criterios de diseo para asegurar que el producto ocomponentes de producto tienen uno o ms de los siguientes atributos de calidad:

- Capacidad de mantenimiento: facilidad que presenta un sistema o software paraproceder a su mejora y optimizacin, as como a la correccin de sus defectos y

prevencin, tras su entrega al usuario final.

- Claridad: caracterstica que representa la facilidad de un sistema para sercomprendido, expresado o percibido.

- Eficiencia: capacidad para lograr un fin empleando los mejores medios posibles;representa la relacin entre los resultados obtenidos o la utilidad sistema y losrecursos empleados o costes incurridos.

- Escalabilidad: propiedad de un sistema de cambiar su tamao o configuracin paraadaptarse a circunstancias cambiantes; indica la habilidad de un sistema para

extender su margen de operaciones sin perder calidad, manejar el crecimientocontinuo de trabajo de manera fluida, o estar preparado para hacerse ms grande sinperder calidad en los servicios ofrecidos.

- Fiabilidad: probabilidad de que un sistema o dispositivo desarrolle una determinadafuncin bajo ciertas condiciones y durante un perodo de tiempo determinado.

- Modularidad: capacidad que tiene un sistema de ser estudiado, visto o entendidocomo la unin de varias partes que interactan entre s y que trabajan para alcanzarun objetivo comn, realizando cada una de ellas una tarea necesaria para laconsecucin de dicho objetivo; cada una de esas partes en que se encuentre dividido

el sistema recibe el nombre de mdulo. Idealmente un mdulo debe poder cumplirlas condiciones de caja negra, es decir, ser independiente del resto de los mdulos ycomunicarse con ellos (con todos o slo con una parte) a travs de unas entradas ysalidas bien definidas.

- Portabilidad: caracterstica de un software para ejecutarse en diferentesplataformas; a mayor portabilidad menor es la dependencia del software conrespecto a la plataforma. Un prerrequisito para la misma es la abstraccingeneralizada entre la aplicacin lgica y las interfaces del sistema.

- Seguridad: cualidad de un sistema de estar libre y exento de todo dao, peligro o

riesgo, permitiendo asegurar que los recursos del sistema son utilizados de la

7/30/2019 Guia ST

23/70


manera que se decidi y que el acceso a la informacin all contenida, as como sumodificacin, slo sea posible a las personas que se encuentren acreditadas y

dentro de los lmites de su autorizacin.

- Usabilidad: facilidad con que las personas pueden utilizar un sistema o herramientaparticular con el fin de alcanzar un objetivo concreto.

Estos factores de calidad se pueden definir siguiendo el paradigma Goal-Question-Metric.Los criterios que definen los factores de calidad y las mtricas que ayudan a medir elalcance de los productos o componentes de producto exponen qu caractersticas o factoresde calidad deben usarse para propsitos de diseo. Este paradigma se puede usar paraverificar que los factores de calidad se incluyen en los productos o componentes deproducto y para validar que el producto opera en el entorno operativo. GQM define una

meta, refina esta meta en preguntas y define mtricas que intentan dar informacin pararesponder a estas preguntas. Las preguntas ayudarn a medir si se est alcanzando la metadefinida, por lo tanto se considerarn preguntas que sean potencialmente medibles. Params informacin sobre este paradigma se puede consultar la Gua de Mejores Prcticas deCalidad de Producto de INTECO.

En la ingeniera del software el diseo detallado se centra en el desarrollo de componentesde producto software. Se define la estructura interna de los componentes de producto, segeneran los esquemas de datos, se desarrollan los algoritmos y se establecen heursticaspara proporcionar las capacidades del componente de producto que satisfarn los requisitosasignados.

En la ingeniera del hardware el diseo detallado se centra en el desarrollo de productoselectrnicos, mecnicos, electro-pticos, y otros productos hardware y sus componentes. Sedesarrollan esquemas elctricos y diagramas de interconexin, se generan modelos demontaje mecnicos y pticos, y se desarrollan los procesos de fabricacin y ensamblaje.

4.1.3. Documentacin de diseo

En este apartado se ver la documentacin de diseo que se puede desarrollar y sepropondrn distintas plantillas para su desarrollo.

Un documento de diseo es una forma de comunicar cules son las decisiones de diseo ypor qu tales decisiones son buenas. Un documento de diseo de software es unadescripcin escrita de un producto software, que escribe el diseador para que sirva de guaal equipo de desarrollo sobre la arquitectura del proyecto. Un documento de diseo ha deser una referencia estable que seale todas las partes del software y cmo funcionan.

La documentacin es un componente crucial en la planificacin e implementacin exitosa deun producto, as que es importante que se desarrolle y distribuya de la forma ms efectivaposible. Una buena organizacin, informacin completa y una escritura clara son factoresclave para el xito de cualquier documento de diseo, pero hay otros factores menos obvios

7/30/2019 Guia ST

24/70


que se pueden utilizar para hacer que los documentos sean ms fciles de leer ycomprender:

- Saber quin va a ser la audiencia. A la hora de escribir documentacin de diseoefectiva hay que estar seguro de que ayude a satisfacer las necesidades de laaudiencia. Por lo tanto es importante saber a quin va a ir dirigido el documento ycules son sus necesidades. Hay que conocer si la audiencia fundamental van a serprogramadores, jefes de proyecto, ejecutivos, personal de marketing Puede sercomplicado satisfacer a todos con un mismo documento, por lo que seraaconsejable organizar el documento de tal forma que cada uno lea solo lassecciones que le apliquen.

- Contar una historia. Uno de los objetivos de la documentacin de diseo,

especialmente en las etapas tempranas de un proyecto, es educar a los lectoressobre el valor del diseo y convencerles de que merece la pena construir el producto.Una forma efectiva de ayudar a la gente a entender el documento de diseo espresentarlo en forma narrativa en vez de entenderlo como una simple coleccin deespecificaciones, descripciones, ilustraciones y diagramas bien organizados.

- Usar personajes. Los personajes principales de la documentacin pueden ser laspersonas que representan los objetivos y necesidades del uso del diseo. Algo tansimple como una descripcin bsica de las caractersticas de los usuarios objetivo,acompaado de un nombre, puede ser bastante convincente.

- Usar escenas. Dos buenas formas de presentar el diseo son escenarios y walk-throughs. Los escenarios son como historias cortas: comunican la situacin de unapersona y describen sus motivaciones, expectativas y objetivos, sin entrar en losdetalles del diseo. Los escenarios son especialmente tiles en las etapastempranas de un proyecto. Los walk-throughs son buenas herramientas decomunicacin a menor nivel. Son procedimientos que explican paso a paso cmo lapersona interacta con el producto, cada accin que realiza y cada respuesta queobtiene del sistema. Son tiles para la explicacin de comportamientos de interfaces.Ambas herramientas funcionan mejor cuando se acompaan de ilustraciones oimgenes del diseo, pero hay que tener cuidado con los documentos basados ennarrativas, ya que no son apropiados para todas las situaciones. Algunosdocumentos de diseo se utilizan como guas de referencia para desarrolladores, porello, dichos documentos deben presentar la informacin de forma clara y sencilla,que facilite a los programadores encontrar lo que necesitan.

- Describir el fundamento e implicaciones del diseo. Cuando se documenta undiseo, puede ser tentador explicar slo el funcionamiento del producto y mostrarcmo es. Sin embargo, para algunas audiencias esto no es suficiente. En algunoscasos querrn saber tambin el por qu de lo que aparece en el diseo (por qu seha incluido cierta caracterstica, por qu cierto elemento se comporta de una formadeterminada). Se puede explicar cmo satisfarn los objetivos las decisiones

7/30/2019 Guia ST

25/70


tomadas. El diseo tambin se puede describir en trminos de los requisitos denegocio que satisface.

- Diseo del documento en s. Una cosa que a veces se pasa por alto es el diseodel documento en s. Hay documentos que son imposibles de leer por su distribucindesordenada. El formato del documento debe de ser claro y consistente.

- Usar el presente y la voz activa. Si se est realizando documentacin de diseo, elproducto es lo que se escribe y el tono de la escritura debera reflejarlo. El uso de lavoz activa hace la escritura ms llamativa, directa y concisa. En la documentacin,se debera escribir como si el producto ya existiera.

Una vez que se ha desarrollado un documento de diseo, es importante que el documento

sea revisado antes de distribuirlo.

En el anexo se ha incluido unaplantilla de un diseo de alto nivel o preliminary otra de undiseo detallado. Ambas plantillas son slo ejemplos por lo que deberan adaptarse a lasnecesidades del proyecto y la propia organizacin.

4.1.3.1. IEEE 1016 Prctica recomendada para la descripcin de los diseossoftware

El estndar IEEE 1016 es una prctica recomendada para la descripcin de los diseossoftware. Este estndar especifica la informacin necesaria y la organizacin recomendada

para desarrollar la descripcin del diseo del software. Dicha descripcin es unarepresentacin del sistema software que se utiliza como medio para la comunicacin deinformacin sobre el diseo.

En base a esta prctica, el diseo del software se debe basar en los requisitos del softwarey debe proporcionar la informacin necesaria para permitir la implementacin del software.

La descripcin del diseo del software muestra como se estructurar el sistema parasatisfacer los requisitos identificados en la especificacin de requisitos. Es una traduccin delos requisitos en una descripcin de la estructura del software, los componentes delsoftware, las interfaces y los datos necesarios para la fase de implementacin.

IEEE Std. 1016 asegura que los diseos software se documentan de forma sistemtica yexhaustiva. La implementacin de este estndar puede ayudar a mejorar el proceso dedesarrollo de software dentro de una organizacin.

4.1.4. Mtodos de diseo

En este apartado se ver la eleccin de mtodos, lenguajes y herramientas de diseoefectivos.

Un mtodo de diseo (o lenguaje o herramienta de diseo) permite al diseador describir las

entidades que componen un diseo y sus conexiones, analizar atributos de inters, probar el

7/30/2019 Guia ST

26/70


diseo contra los casos o escenarios de uso y revisar el diseo para reflejar decisionestomadas.

Es necesario identificar, desarrollar o adquirir los mtodos de diseo apropiados para elproducto. Para evaluar los distintos mtodos de diseo podemos contar con los siguientescriterios:

- Capacidad de descomposicin en componentes: el mtodo ayuda a descomponerun problema nuevo en varios sub-problemas?

- Capacidad de composicin: el mtodo ayuda a construir nuevos sistemas a partirde componentes software?

- Capacidad de entendimiento de los componentes: se pueden entender loscomponentes de forma separada?

- Compatibilidad de componentes: estn los componentes bien definidos y cuentancon interfaces bien definidas y/o uniformes?

Los mtodos de diseo efectivos pueden abarcar un amplio rango de actividades,herramientas y tcnicas descriptivas. Si un mtodo dado es efectivo o no depende de lasituacin particular en la que se aplique. Un mtodo de diseo puede ser efectivo en variascompaas y no serlo en otra con caractersticas diferentes. Adems, hay que seleccionarlos mtodos apropiados en funcin de las caractersticas de los productos y de las

habilidades de las personas, ya que por ejemplo, por muy sofisticado que sea un mtodo, silas personas que lo tienen que llevar a cabo no tienen la formacin adecuada, puede quedicho mtodo no sea efectivo. Tambin hay que tener en cuenta la ayuda que seproporciona al diseador y la efectividad de dicha ayuda en relacin con el coste de lamisma. Se deben establecer y mantener criterios para poder determinar la efectividad de losmtodos de diseo. Los mtodos altamente sofisticados no son necesariamente efectivos enlas manos de diseadores que no han sido formados en el uso de los mtodos.

Ejemplos de tcnicas y mtodos que facilitan el desarrollo de diseos efectivos incluyen:

- Prototipos. Los prototipos son versiones incompletas del producto o componente de

producto que se est desarrollando. Un prototipo tpicamente simula slo unos pocosde los aspectos del producto y puede ser completamente diferente de laimplementacin final. El propsito convencional de un prototipo es permitir evaluardiferentes propuestas del diseo del producto final. El prototipado es una tcnicaimportante que puede ayudar a descubrir deficiencias de diseo.

- Modelos estructurales. Un modelo estructural es el mapa arquitectnico de unsistema o familia de sistemas, que puede facilitar el diseo de productos.

- Diseo orientado a objetos. El diseo orientado a objetos es el proceso deplanificar un sistema de objetos que interactan, con el propsito de solucionar un

problema. El diseo orientado a objetos es la disciplina que define los objetos y sus

7/30/2019 Guia ST

27/70


interacciones para resolver un problema de negocio que fue identificado ydocumentado durante el anlisis orientado a objetos.

- Modelos de entidad-relacin. El modelo entidad-relacin es el modelo conceptualms utilizado para el diseo conceptual de bases de datos. El modelo entidad-relacin est formado por una serie de conceptos que permiten describir la realidadmediante un conjunto de representaciones grficas y lingsticas.

- Reutilizacin de diseos. La reutilizacin de diseos es la inclusin decomponentes diseados previamente en software o hardware. La reutilizacin dediseos hace ms rpido y barato el diseo y construccin de un nuevo producto, yaque los componentes no slo estn ya diseados, sino tambin probados.

- Patrones de diseo. Un patrn de diseo es una solucin general reutilizable a unproblema en diseo de software. No es un diseo terminado que se puedatransformar directamente en cdigo. Es una descripcin o plantilla de cmosolucionar un problema, que puede usarse en situaciones diferentes.

Una vez que se ha desarrollado el diseo, se pueden utilizar mtodos de verificacin queayuden a asegurar que el diseo se adhiere a estndares y criterios aplicables. Talesmtodos de verificacin incluyen revisiones entre pares, simulaciones de diseos y uso deprototipos.

Ejemplos de estndares de diseo incluyen los siguientes (algunos de estos estndares

pueden ser criterios de diseo, particularmente en circunstancias donde los estndares nose hayan establecido):

- Estndares de interfaz de operador.

- Escenarios de pruebas.

- Estndares de seguridad.

- Restricciones de diseo (compatibilidad con sistemas operativos).

- Restricciones de produccin.- Tolerancias de diseo.

- Estndares de piezas (desechos y residuos de la produccin).

4.2. PAQUETE DE DATOS TCNICOS

Un paquete de datos tcnicos es la documentacin de diseo completa de un producto ocomponente de producto y la informacin adicional necesaria para el soporte de su usoefectivo.

7/30/2019 Guia ST

28/70


Un paquete de datos tcnicos proporciona al desarrollador una descripcin exhaustiva delproducto o componente de producto a medida que se desarrolla.

El diseo debera ser registrado en un paquete de datos tcnicos durante el desarrollo deldiseo preliminar para documentar la definicin de la arquitectura, y debera mantenersedurante la vida del producto para registrar los detalles esenciales del diseo del producto. Elpaquete de datos tcnicos proporciona la descripcin de un producto o componente deproducto, incluyendo los procesos del ciclo de vida relacionados con el producto. Incluyedibujos, listas asociadas, descripciones de diseo, bases de datos de diseo, estndares,requisitos de rendimiento, disposiciones para el aseguramiento de la calidad y detalles deempaquetado. Adems proporciona una descripcin de la solucin alternativa seleccionada.

Un paquete de datos tcnicos es una coleccin de elementos que puede incluir la siguiente

informacin, siempre que sta sea apropiada para el tipo de producto o componente deproducto (p.ej. requisitos materiales y de fabricacin no sern tiles para componentes deproducto asociados con servicios o procesos software):

- Descripcin de la arquitectura del producto.

- Requisitos asignados.

- Descripciones de los componentes de producto.

- Descripciones de procesos del ciclo de vida relacionados con el producto.

- Caractersticas clave del producto.

- Caractersticas y restricciones fsicas requeridas.

- Requisitos de interfaz.

- Requisitos de materiales.

- Requisitos de fabricacin y de produccin.

- Criterios de verificacin usados para asegurar que se han conseguido los requisitos.

- Condiciones de uso y escenarios de operacin/uso, modos y estados de operacin,soporte, formacin, manufactura, retirada del producto y verificaciones durante elciclo de vida del producto.

- Fundamento de las decisiones y caractersticas (p.ej. requisitos, asignacin derequisitos y elecciones de diseo)

Un paquete de datos tcnicos contiene mucha informacin. Para incrementar su usabilidad yutilidad, hay que definir una serie de criterios para definir qu incluir, organizar los datos deacuerdo a la arquitectura del producto y proporcionar puntos de vista relevantes, como

7/30/2019 Guia ST

29/70


pueden ser: clientes, requisitos, el entorno, funcional, lgica, seguridad, datos,estados/modos, construccin, gestin,

4.3. DISEO DE INTERFACES

Adems de llevar a cabo el diseo del producto o componente de producto, hay que diseartambin las interfaces de los componentes de producto usando para ello una serie decriterios establecidos previamente. Hay que identificar interfaces asociadas con otroscomponentes del producto, con elementos externos y con los procesos del ciclo de vidarelacionados con el producto. Ejemplos de tales interfaces incluyen interfaces conequipamiento de pruebas, sistemas de transporte, sistemas de soporte, Se deben tratarlas interfaces con los entornos tales como integracin de producto, verificacin y validacin,as como de operacin, mantenimiento y soporte.

Las interfaces son uno de los tems de configuracin ms importantes a identificar ycontrolar durante el ciclo de vida del proyecto. Los proyectos deben desarrollardescripciones de interfaces detalladas durante el refinamiento del producto y los requisitosde producto y durante la seleccin de soluciones alternativas. Cuando un elemento externoes un producto COTS, la descripcin del producto COTS se convierte en un requisito al quetodos los otros componentes del producto que interacten con el producto COTS se debenadherir.

Los diseos de interfaces incluyen la definicin de:

- Origen.

- Destino.

- En el caso del software: caractersticas de datos, mtodos y eventos.

- En el caso del hardware: caractersticas elctricas, mecnicas y funcionales.

- Protocolos de comunicacin.

Los criterios para las interfaces reflejan con frecuencia parmetros crticos que se deben

definir o al menos investigar para averiguar su aplicabilidad. Estos parmetros son, confrecuencia, caractersticos de un tipo de producto dado (p.ej. software, mecnico,elctrico) y se suelen asociar con seguridad, durabilidad y caractersticas de misin crtica.

El diseo de interfaces puede seguir muchas veces un proceso de evaluacin formalbasado en: establecer criterios para la correccin de una interfaz, identificar alternativas dediseo, etc., como el que se puede llevar a cabo en el diseo del producto. Para el uso deprocesos de evaluacin formal se puede consultar el rea de proceso DAR.

Para llevar a cabo un control de las interfaces, se definen documentos de control deinterfaces que definen interfaces en trminos de elementos de datos aprobados, protocolos

7/30/2019 Guia ST

30/70


utilizados en la interaccin, etc. Estos documentos son especialmente tiles en el control delos componentes de producto que se estn construyendo por equipos diferentes.

Se han de documentar los diseos de interfaces seleccionados de entre todas lasalternativas de diseo de la interfaz y los fundamentos para dicha seleccin. Los diseos deinterfaces se deberan documentar en el paquete de datos tcnicos. Los datos de lasinterfaces son todos los datos asociados con las interfaces de los componentes de producto,incluyendo requisitos, diseos y descripciones de interfaces.

Para saber qu interfaces describir, mantener y revisar de forma peridica, es recomendablepreparar una tabla que relacione las interfaces entre componentes de producto (o entrecomponentes de producto y entornos). El objetivo es conseguir cobertura y completitud detodas las interfaces.

4.4. REALIZAR LOS ANLISIS SOBRE SI DESARROLLAR, COMPRAR

O REUTILIZAR

Como ya se trat en apartados anteriores, a la hora de seleccionar las distintas alternativasde diseo hay que tener en cuenta la posible adquisicin de productos COTS. Adems deesta eleccin, hay que evaluar si los componentes de los productos deberan desarrollarse,comprarse o reutilizarse en base a unos criterios establecidos.

La determinacin de qu productos o componentes de producto se adquirirn se conoce confrecuencia como un anlisis make or buy y se basa en un anlisis de las necesidades delproyecto. Este anlisis se ha de llevar a cabo en etapas tempranas del ciclo de vida, durantela primera iteracin del diseo, continuando durante el proceso de diseo y completando conla decisin de desarrollar, adquirir o reutilizar el producto.

Entre los factores que pueden afectar a la decisin de desarrollar o adquirir se incluyen lossiguientes:

- La funcionalidad que proporcionan los productos y cmo esas funciones encajarnen el proyecto.

- Recursos y habilidades del proyecto disponibles.

- Costes de adquirir contra costes de desarrollar el producto internamente.

- Fechas crticas de entrega e integracin.

- Alianzas de negocio estratgicas, incluyendo requisitos de negocio de alto nivel.

- Estudios de mercado de productos disponibles, incluyendo productos COTS.

- Funcionalidad y calidad de los productos disponibles.

- Habilidades y capacidades de los proveedores potenciales.

7/30/2019 Guia ST

31/70


- Impacto en las competencias clave.

- Licencias, garantas, responsabilidades y limitaciones asociadas a los productos quese van a adquirir.

- Disponibilidad de productos.

- Reduccin de riesgos.

La decisin de si comprar o desarrollar se puede llevar a cabo siguiendo un enfoque deevaluacin formal.

4.4.1. Anlisis make-or-buy

La decisin sobre si desarrollar o comprar es el acto de hacer una eleccin estratgica entredesarrollar un producto o componente de producto de forma interna o adquirirlo de unproveedor externo (outsourcing).

Entre las consideraciones que pueden hacer que el desarrollo sea interno o externopodemos encontrar:

Tabla 3. Consideraciones del desarrollo interno y ext erno

Desarrollo interno Desarrollo externo

Consideraciones de coste.

Necesidad de ejercer un control directo sobre eldesarrollo y/ o la calidad.

Mejor control de calidad.

Proveedores poco fiables.

Proveedores no competentes.

Razones polticas, sociales o del entorno.

Falta de habilidades.

Consideraciones de coste.

Insuficiente capacidad para el desarrollo.

Componentes no esenciales para la estrategia de laempresa.

Consideraciones indirectas de control de gerencia.

En ambos casos, una de las consideraciones ms importantes es la del coste, por lo quehay que tener en cuenta todos los elementos que le puedan afectar.

7/30/2019 Guia ST

32/70


5. IMPLEMENTACIN DEL DISEO DEL PRODUCTO

Una vez que se ha desarrollado el diseo y todo lo que ello conlleva, hay que implementarlos componentes de productos y la documentacin de soporte asociada en base a dichodiseo. La implementacin normalmente incluye la ejecucin de pruebas unitarias sobre loscomponentes de producto. Las caractersticas de la implementacin dependen del tipo decomponente de producto.

Entre los ejemplos de caractersticas de la implementacin (tanto a nivel de software comode hardware) que propone CMMI se encuentran:

- El software es codificado.

- Los datos son documentados.

- Los servicios son documentados.

- Los procesos son documentados.

- Las partes elctricas y mecnicas son fabricadas.

- Las instalaciones son montadas.

- Los materiales son producidos.

- Los procesos de fabricacin se ponen en operacin.

A la hora de implementar el diseo de los componentes de producto, las organizaciones sepueden adherir a estndares y criterios aplicables. Dichos estndares y criterios deimplementacin dependern del tipo de producto que se implemente. La organizacin puedeestablecer sus propios estndares y criterios de implementacin.

Algunos ejemplos de estndares de implementacin que se pueden utilizar son lossiguientes:

- Estndares de lenguaje (estndares para lenguajes de programacin de software ylenguajes de descripcin de hardware).

- Requisitos de planos.

- Listas de piezas estandarizadas.

- Piezas manufacturadas.

- Estructura y jerarqua de los componentes de productos software.

7/30/2019 Guia ST

33/70


- Estndares de procesos y de calidad.

Algunos ejemplos de criterios de implementacin que se pueden tener en cuenta para laimplementacin:

- Modularidad: capacidad que tiene un sistema de ser estudiado, visto o entendidocomo la unin de varias partes que interactan entre s y que trabajan para alcanzarun objetivo comn, realizando cada una de ellas una tarea necesaria para laconsecucin de dicho objetivo.; cada una de esas partes en que se encuentredividido el sistema recibe el nombre de mdulo..

- Claridad: facilidad de un sistema para ser comprendido, expresado o percibido.

- Simplicidad: cualidad de ser claro y conciso, resultado de un trabajo consciente ydirigido a la minimizacin simultnea de las partes que constituyen el sistema y delas relaciones que existen entre ellas; sin sacrificar la esencia o concepto,respetando las partes imprescindibles y eliminando lo superfluo.

- Fiabilidad: probabilidad de que un sistema o dispositivo desarrolle una determinadafuncin bajo ciertas condiciones y durante un perodo de tiempo determinado.

- Seguridad: cualidad de un sistema de estar libre y exento de todo dao, peligro oriesgo, permitiendo asegurar que los recursos del sistema son utilizados de lamanera que se decidi y que el acceso a la informacin all contenida, as como su

modificacin, slo sea posible a las personas que se encuentren acreditadas ydentro de los lmites de su autorizacin.

- Capacidad de mantenimiento: facilidad que presenta un sistema o software paraproceder a su mejora y optimizacin, as como a la correccin de sus defectos yprevencin, tras su entrega al usuario final.

5.1. MTODOS PARA LA IMPLEMENTACIN

A la hora de llevar a cabo la implementacin del diseo hay que escoger mtodos efectivos.La eleccin de un mtodo u otro depender del tipo de componente de producto que se est

implementando. Una organizacin puede establecer sus propios mtodos deimplementacin.

Para la ingeniera del software se pueden utilizar los siguientes mtodos de codificacin desoftware:

- Programacin estructurada: impone una estructura lgica en la escritura de unprograma para hacerlo ms eficiente y fcil de entender y modificar. Las rutinaslargas se descomponen en rutinas ms pequeas, rutinas modulares.

- Programacin orientada a objetos: es un mtodo de programacin en el que los

programadores no slo definen los tipos y las estructuras de datos, sino tambin las

7/30/2019 Guia ST

34/70


operaciones (funciones) que se pueden aplicar a las estructuras de datos. Laestructura de datos se convierte en un objeto que incluyen tanto datos como

funciones. Adems, los programadores pueden crear relaciones entre objetos.

- Generacin de cdigo automtica: mtodo que se basa en la utilizacin deherramientas que permitan la generacin automtica de cdigo.

- Reutilizacin de cdigo: se basa en la reutilizacin de cdigo existente para laconstruccin de software nuevo.

Para la ingeniera del hardware se pueden utilizar los siguientes mtodos deimplementacin del hardware:

- Sntesis de nivel de puertas.

- Esquema de la tarjeta de circuitos (lugar y ruta).

- Diseo asistido por ordenador.

- Simulacin del post-layout.

- Mtodos de fabricacin.

5.2. PRUEBAS UNITARIAS

Como se ha comentado previamente, las pruebas unitarias suelen formar parte de laimplementacin de los componentes de producto. Adems, hay que realizar revisiones entrepares que permitan comprobar que los componentes de producto estn disponibles para laintegracin del producto.

Las pruebas unitarias se encargan de buscar defectos y verificar el funcionamiento de loscomponentes de producto que se puedan probar de forma separada. Las pruebas unitariasse deben realizar de forma aislada al resto del sistema.

Las pruebas unitarias no slo se llevarn a cabo sobre el cdigo, sino tambin sobre otroscomponentes del producto. Los mtodos de pruebas unitarias que se utilizarn, dependerndel tipo de componente de producto que se est implementando.

Para el caso de la ingeniera del software, podemos encontrar los siguientes mtodos depruebas unitarias:

- Pruebas de cobertura de sentencia: se trata de probar todas las sentenciasexistentes en la parte de cdigo que se est probando.

- Pruebas de cobertura de decisin: se evalan tanto la salida si como la no detodas las estructuras de control.

7/30/2019 Guia ST

35/70


- Pruebas de cobertura de predicados: se ejecutan todas las expresiones booleanastanto la opcin si como la opcin no (no implica la cobertura de decisin).

- Pruebas de cobertura de caminos: se ejecutan todas las rutas posibles.

- Pruebas de valores lmite: se basa en probar los valores que se encuentran en lasfronteras tanto de las particiones de entrada como de salida.

- Pruebas de valores especiales: este tipo de pruebas se basan en utilizar elconocimiento en el dominio y la experiencia de las personas que desarrollan laspruebas.

Para el caso de la ingeniera del hardware, podemos encontrar los siguientes mtodos de

pruebas unitarias:

- Pruebas funcionales.

- Pruebas de inspeccin de radiacin.

- Pruebas de entorno.

Para ms informacin sobre pruebas unitarias se puede consultar la Gua de MejoresPrcticas de Calidad de Producto de INTECO.

5.3. DOCUMENTACIN DE SOPORTEEn este apartado se tratar el desarrollo y mantenimiento de la documentacin que se usarpara instalar, operar y mantener el producto.

Aunque el foco de la Solucin Tcnica est en la arquitectura, diseo e implementacin, esimportante apuntar que esta rea no est completa hasta que la documentacin relacionadacon la instalacin, administracin, operacin y mantenimiento del producto est desarrolladay revisada. Es recomendable que en el proyecto se desarrollen versiones preliminares de ladocumentacin en las etapas tempranas del ciclo de vida y se revisen por todas laspersonas involucradas en el negocio.

La documentacin de usuario describe cada caracterstica del programa y ayuda alusuario en el uso del mismo. Una buena documentacin de usuario puede tambinproporcionar ayuda en la resolucin de problemas. Es muy importante que los documentosde usuario no sean confusos y que estn actualizados. Los documentos de usuario notienen por qu tener una organizacin concreta, pero es muy importante que tengan unndice correcto.

Los usuarios de un sistema no son todos iguales. La documentacin se debe desarrollarpensando en las diferentes tareas de los usuarios y los distintos niveles de experiencia. Sedeben realizar distintos documentos ya que instaladores, operadores y usuarios tienendiferentes necesidades. Es particularmente importante distinguir entre los usuarios finales ylos administradores de sistema. Los usuarios finales utilizan el producto para que les ayude

7/30/2019 Guia ST

36/70


en alguna tarea y necesitan saber de qu manera lo va a hacer. En cambio losadministradores de sistemas son responsables de la gestin de los productos utilizados por

los usuarios finales.

La documentacin puede tratarse como un tipo de componente de producto para el que hayque seleccionar, disear e implementar una solucin. Por ello, existen mtodos y guas deestilos para la documentacin, como pueden ser:

- Compatibilidad con los procesadores de texto designados.

- Fuentes aceptables.

- Numeracin de pginas, secciones y prrafos.

- Consistencia con un manual de estilo designado.

- Uso de abreviaturas.

- Marcas de clasificacin de seguridad.

- Requisitos de internacionalizacin.

Una vez que la documentacin est desarrollada se ha de revisar a medida que seanecesario. Entre los factores que pueden hacer necesaria esta revisin estn los siguientes:

- Cambios en los requisitos.

- Cambios de diseo.

- Cambios en el producto.

- Identificacin de errores en la documentacin.

- Identificacin de correcciones a soluciones temporales.

5.3.1. Estndares de documentacin

Existen distintos estndares que se pueden aplicar a la hora de desarrollar ladocumentacin de usuario. Entre ellos podemos destacar los siguientes:

- BS-7649 The Design and Preparation of Documentation for user of Applicationsoftware (El Diseo y Preparacin de Documentacin para usuarios de software de

Aplicaciones): proporciona informacin sobre la informacin que necesitan losusuarios, la forma de presentar dicha informacin

- IEEE 1063 Software User Documentation (Documentacin de Usuarios de Software):este estndar proporciona los requisitos mnimos de la estructura, contenido y

7/30/2019 Guia ST

37/70


formato de la documentacin de usuario, incluyendo tanto documentos impresoscomo electrnicos.

- ISO/IEC 26514:2008 Systems and software engineering -- Requirements fordesigners and developers of user documentation (Ingeniera de software y de

sistemas: Requisitos para diseadores y desarrolladores de documentacin de

usuario):proporciona los requisitos para el diseo y desarrollo de documentacin deusuario de software como parte de los procesos del ciclo de vida. Define el procesode documentacin desde el punto de vista del desarrollador de la documentacin.Especifica la estructura, contenido y formato de la documentacin de usuario yproporciona guas en el estilo de la documentacin. Aplica tanto a documentacinimpresa como electrnica.

- ISO/IEC TR 9294:2005 Information technology -- Guidelines for the management ofsoftware documentation (Tecnologa de la Informacin Pautas para la gestin de

documentacin software): ofrece orientacin en la gestin de la documentacinsoftware con la intencin de ayudar a que se desarrolle documentacin efectiva enlas organizaciones.
http://www.iso.org/iso/rss.xml?csnumber=37460&rss=detailhttp://www.iso.org/iso/rss.xml?csnumber=37460&rss=detailhttp://www.iso.org/iso/rss.xml?csnumber=43073&rss=detail

7/30/2019 Guia ST

38/70


6. ANEXOS: ARTEFACTOS RELACIONADOS CON LA SOLUCIN

TCNICAA continuacin se muestran una serie de artefactos que pueden proporcionar ayuda a lahora de implementar las actividades relacionadas con la Solucin Tcnica.

6.1. PROCESO PARA EL DISEO

6.1.1. Objetivos

Llegar a un diseo a partir del cual el sistema / software pueda ser construido y conforme a

las especificaciones de requisitos software / sistema (SRS) establecidos en la lnea base.

6.1.2. Alcance

Aplicable para el desarrollo y mejora de proyectos que conlleve diseo software/ sistema.

6.1.3. Criterios de entrada

- Lnea base del SRS (Documento de especificacin de requisitos software/sistema)

- Peticin de cambio (para mejoras en el mantenimiento de los proyectos)

6.1.4. Entradas

- Propuesta

- SRS

- Mtodo de diseo y estndares elegidos

- Peticin de cambio aprobada

6.1.5. Descripcin del proceso

El diseo se estructura en dos fases, una llamada preliminar o diseo de alto nivel y la otra,diseo a bajo nivel dependiendo de la complejidad del sistema y los requisitos. El diseo dealto nivel y el de bajo nivel, se pueden combinar en un diseo completo.

- Diseo de alto nivel (Sistema /Arquitectura Software): nos permite conocer laorganizacin fundamental del sistema atendiendo a sus componentes, sus relacionesy el entorno, as como los principios que gobiernan el diseo y su evolucin. Estoincluye particiones del sistema, identificacin de componentes, estado del sistema y

modos, interfaces entre componentes, e interfaces con sistemas externos.

7/30/2019 Guia ST

39/70


- Diseo a bajo nivel: define la estructura y las capacidades de los componentes delsistema (por ejemplo: detalles internos de implementacin).

6.1.5.1. Seleccionar la arquitectura ptima

Cuando el diseador llega a este criterio, evala la arquitectura, que incluye:

- Coste

- Rendimiento

- Complejidad

- Robustez- Expansin del producto y crecimiento

- Limitaciones tecnolgicas

- Riesgos

- Evolucin de la tecnologa

- Habilidades de los usuarios finales y operadores

El diseador identifica las propuestas alternativas a evaluar.

El experto tcnico evala las alternativas y selecciona la ms ptima, haciendo uso si esposible, de procesos para el anlisis de decisiones.

La arquitectura seleccionada se evala por los arquitectos lderes en revisiones de gestintecnolgica.

6.1.5.2. Desarrollar el diseo de alto nivel (sistema / arquitectura software).

El diseador descompone el sistema en mdulos o componentes software e identifica las

funcionalidades de cada componente atendiendo a un principio de independencia funcional(un mdulo un propsito). El propsito de hacer esto es: comprobar la existencia deposibles mdulos reutilizables, generar la flexibilidad requerida para aadir futurasfuncionalidades, interconexin con un cliente o producto, problemas de rendimiento debidosa una excesiva interconexin entre mdulos, etc.

El diseador identifica la interfaz interna principal y todas las interfaces externas del sistema/ software.

El diseador modela el comportamiento dinmico del sistema a nivel de componente,describiendo los mensajes intercambiados, las pre-post condiciones para cada operacin

7/30/2019 Guia ST

40/70


(Ej.: diagramas de estado), las posibles restricciones en la composicin de componentes,cmo se instancian los componentes y por ltimo, las excepciones generadas.

En el caso de sistemas distribuidos o concurrentes, el diseador mapea los componentes alos procesos fsicos del sistema. El diseador evala las diferentes configuraciones posiblescontra los requisitos, como puede ser el rendimiento o la escalabilidad.

El diseador identifica los principales elementos reutilizables de la organizacin obtenidos,en el caso de estar disponible, de una base de datos de histricos de elementos reutilizados.

El diseador identifica los componentes candidatos a ser reutilizados del paso anterior parasu incorporacin en el proyecto.

El equipo de diseo optimiza el anlisis de realizar / adquirir / reutilizar para loscomponentes del producto usando alguna plantilla para la toma de decisiones de la formaapropiada.

6.1.5.3. Desarrollo de diseo a bajo nivel

El diseador identifica, desarrolla o adquiere mtodos y herramientas de diseo apropiadaspara el sistema / software.

El diseador conecta las interfaces entre los componentes en trminos de control del flujo dedatos; la estructura de los datos que pasan a travs de las interfaces tambin se describe en

esta etapa.El diseador describe las interfaces externas en trminos de Interfaz de programacin deaplicaciones (API), considerando los parmetros pasados y los valores de retorno, laestructura de datos, etc.

El diseador describe la estructura de datos usada por cada modulo para el procesamientointerno en trminos de definicin de los datos y estructura y las relaciones entre ellos. Eldiseador define cada elemento de la estructura de datos en trminos de tipo y tamao. Eldiseador tambin identifica los eventos que afectan a esa estructura de datos y susefectos. La base de datos de diseo se debe alinear con los requisitos acerca de los datos,

el crecimiento de los mismos, el rendimiento, y otros criterios especificados en el SRS.

El diseador traslada el modelo estructural del mdulo de software en procedimental (si seha adoptado la aproximacin al diseo estructural) describiendo la lgica de procesamiento(secuencia de pasos) y la interfaz de usuario (UI) en cada modulo. El pseudocdigo y losdiagramas de flujo se utilizan para representar la lgica.

El diseador actualiza el documento SRS basado en los requisitos derivados de la solucinde diseo adoptada, si existen.

El diseador documenta los estndares, criterios, componentes propietarios, frameworks, y

APIs que sern utilizados para la construccin del sistema / software.

7/30/2019 Guia ST

41/70


Tras la aprobacin del diseo de bajo nivel, el jefe de proyecto prepara el plan de pruebasde integracin y los casos de prueba de integracin.

6.1.5.4. Actualizar la matriz de trazabilidad de requisitos (RTM)

El equipo de diseo actualiza la matriz de trazabilidad de requisitos para realizar latrazabilidad del diseo de bajo nivel al de alto nivel, y la trazabilidad del diseo de alto nivelcon el documento SRS.

6.1.5.5. Revisin de diseo, validacin y lnea base

El equipo de diseo realiza una revisin por pares del documento de diseo. Los defectosencontrados son registrados y se realiza un seguimiento hasta su cierre. (En este punto es

importante apoyarse en una gua para la clasificacin de defectos y su categorizacin).

Los documentos de diseo son revisados por otras personas (por ejemplo el equipo depruebas si es necesario).

El diseador valida el diseo con el cliente y se establece un lnea base que se alinea conla matriz de trazabilidad de requisitos.

6.1.5.6. Actualizaciones del plan

El jefe de proyecto vuelve a revisar la planificacin y realiza nuevas estimaciones y

actualizaciones si son necesarias.

6.1.6. Recomendaciones

Mostrar al cliente las posibles soluciones alternativas e incluso involucrarle en la evaluacinde las mismas.

6.1.7. Adaptaciones permitidas

Exponer las adaptaciones permitidas para este proceso.

6.1.8. Medidas

- Esfuerzo realizado en actividades de diseo (Planificado vs Actual).

- Porcentaje de reutilizacin.

6.1.9. Validaciones

- Revisiones de la arquitectura del sistema / software

- Revisiones de los documentos

7/30/2019 Guia ST

42/70


- Revisiones en determinados puntos de verificacin

6.1.10. Registros de calidad

- Checklistpara el diseo de alto nivel

- Checklistpara el diseo de bajo nivel

- Registro de las revisiones de diseo

- Informe sobre los puntos de verificacin

- Registro de revisiones acerca de la tecnologa a utilizar (cuestionarios, informes,

scorecard, etc.)

6.1.11. Criterios de salida

- Documentos de diseo bajo la lnea base (diseo de alto nivel y diseo de bajo nivel)

- Punto de verificacin de diseos completados

6.1.12. Referencias

- Plantilla de especificacin de requisitos software / sistema.- Plantilla de diseo de alto nivel

- Plantilla de diseo de bajo nivel

- Plantilla de matriz de trazabilidad de requisitos

- Plantilla para el anlisis y toma de decisiones

- Plantilla de informe de puntos de verificacin

- Checklistde diseo de alto nivel

- Checklistde diseo de bajo nivel

- Guas de arquitectura y diseo

- Proceso de revisin de la arquitectura desde un punto de vista tecnolgico

- Gua para la clasificacin de defectos

7/30/2019 Guia ST

43/70


6.1.13. Matriz de perfiles en el proceso

Roles

- PM - Jefe de proyecto

- RM - Gerente

- PL - Jefe de equipo

- SQA Responsable aseguramiento de calidad del software

- PT - Equipo de proyecto (equipo de diseo)

- CCB Equipo de control de configuracin

- DBA - Analista de base de datos

Tabla 4. Roles del proceso de diseo

Actividad Responsabilidad Salidas

Preparacin Revisin Aprobacin Responsabilidad

Desarrollaraproximacionesalternativas yseleccionar laptima

Diseador ExpertosTcnicos ExpertosTcnicos Diseador Documento detoma dedecisiones

Dividir enmdulos elsistema.Identificar laarquitectura delsistema

Diseador Por pares Arquitectolder

Diseador Diseo de altonivel

Realizar elanlisis realizar

/comprar/reutilizar

Diseador Por pares Cliente, RM Diseador Documento detoma dedecisiones

Crear diseo dela base de datos

DBA /Diseador

Por pares Por pares DBA / Diseador Diseo de bajonivel

Crear el diseode interfaces

Diseador Por pares Por pares Diseador Diseo de bajonivel

7/30/2019 Guia ST

44/70


Crear elprocedimiento de

diseo

Diseador Por pares Por pares Diseador Diseo de bajonivel

Actualizar lamatriz detrazabilidad derequisitos

Diseador SQA PM PM Matriz detrazabilidad derequisitos

Verificar y validarel diseo. Cierredel mismo.

Diseador Por pares /

Cliente

Cliente PM Documentos dediseo, registrosde revisin.

Establecer unalnea base para eldiseo y la matrizde trazabilidad derequisitos.

Diseador SQA PM Documentos dediseo bajo lneabase, al igual quela matriz detrazabilidad derequisitos.

Preparacin delplan de pruebas ylos casos deprueba

PT / PL Por pares PM PM Plan de pruebasde integracin,casos de pruebade integracin

6.2. LISTA DE CONTROL PARA EL DISEO PRELIMINAR

Para controlar que el diseo preliminar se ha desarrollado de la forma correcta se puedeutilizar una lista de control con una serie de preguntas que nos permitan valorar el estado dedicho diseo.

A continuacin se muestran una serie de preguntas que podran formar parte de una lista deeste tipo. Para cada una de ellas habra que valorar el estado y sealar los posiblescomentarios que puedan surgir.

- El diseo general implementa todos los requisitos explcitos y cumple con todos losrequisitos implcitos?

- Se ha desarrollado la matriz de trazabilidad de requisitos?

- Se han seguido todos los estndares/metodologas aplicables?

- Es viable el diseo en cuanto a planificacin, presupuesto y tecnologa?

- El diseo es correcto y no ambiguo?

- Estn identificados de forma clara los objetivos principales del sistema?

7/30/2019 Guia ST

45/70


- Se han tenido en cuenta todas las decisiones de compra y construccin?

- Se ha realizado un anlisis de la arquitectura sobre la decisin de diseo?

- Se han documentado las alternativas y la solucin final decidida para el proceso deDAR (Anlisis y resolucin de la decisin)?

- Se han utilizado herramientas de diseo?

- El diseo es modular y procura incorporar elementos reutilizables?

- La arquitectura considera todas las restricciones existentes?

- Se ha asegurado de que la arquitectura no contenga redundancia innecesaria?- Est representada la arquitectura de forma clara incluyendo flujos de datos, flujos

de control e interfaces?

- Se han identificado los riesgos debidos a consideraciones de arquitectura y diseo?

- Todas las partes de la arquitectura estn dentro del alcance de lasespecificaciones?

- La arquitectura est diseada para introducir cambios con alta probabilidad deocurrir de forma sencilla?

- La arquitectura proporciona una base adecuada para los diseos a alto nivel?

- Se han documentado incidencias, problemas y cuestiones abiertas?

- Todas las interfaces son claras y estn bien definidas?

- Todas las estructuras de datos estn divididas de forma clara?

- Se han diseado todas las condiciones de seguridad?

- Se han considerado todos los requisitos de fiabilidad y rendimiento?

- Se han tratado todas las cuestiones relacionadas con el mantenimiento?

- El diseo proporciona la suficiente informacin para el diseo de casos de prueba?

- Estn clasificados todos los componentes de la interfaz?

- Estn definidas todas las interfaces internas y externas?

- Est definida la descripcin de la interfaz?

- Se ha identificado la secuencia de integracin de componentes?

7/30/2019 Guia ST

46/70


6.3. LISTA DE CONTROL PARA EL DISEO DETALLADO

Para controlar que el diseo detallado se ha desarrollado de la forma correcta se puedeutilizar una lista de control con una serie de preguntas que nos permitan valorar el estado dedicho diseo.

A continuacin se muestran una serie de preguntas que podran formar parte de una lista deeste tipo. Para cada una de ellas habra que valorar el estado y sealar los posiblescomentarios que puedan surgir.

- General:

Se han pensado en alternativas de diseo?

Se han documentado las alternativas y la solucin decidida siguiendo elproceso de toma de decisiones?

Se han seguido todos los estndares y metodologas de diseo aplicables?

Se ha completado el diseo detallado, p.ej. estn completamenteimplementados los requisitos y el diseo de alto nivel?

Para mejorar el cdigo existente, el diseo detallado muestra qu cdigohay que cambiar y de qu forma cambiarlo?

El diseo es viable?

Se han documentado todos los asuntos o temas abiertos?

Se ha documentado el diseo detallado junto con los riesgos conocidos?

Se han documentado todas las suposiciones, restricciones, decisiones ydependencias del diseo?

Se han identificado todas las cuestiones relacionadas con la capacidad demantenimiento?

Todas las partes del diseo estn relacionadas con los requisitos de losdocumentos de negocio, usuario y sistema?

- Funciones:

Estn especificadas todas las funciones de forma clara?

Son todas las funciones lgicamente independientes?

7/30/2019 Guia ST

47/70


Las especificaciones de cada mdulo implementan completamente lafuncionalidad requerida en la documentacin de ms alto nivel?

Se ha realizado un diseo modular de tal manera que se puedan reutilizarcomponentes?

Proporciona el diseo una base adecuada para la escritura de cdigo y sumantenimiento?

Se ha documentado el propsito de todos los componentes, funciones yprocesos?

- Interfaces:

Estn todas las interfaces bien definidas y son claras?

Son consistentes todas las interfaces entre s, con otros mdulos y con losrequisitos documentados a alto nivel?

Las comunicaciones entre procesos estn correctamente especificadas?

Se ha descrito y j

Guia ST

Documents

Transcript of Guia ST