Guia ST

GUA DE DISEO DE LA SOLUCIN TCNICA
Laboratorio Nacional de Calidad del Software
Noviembre 2009
El Instituto Nacional de Tecnologas de la Comunicacin, S.A. (INTECO), es una sociedad estatal adscrita al Ministerio de Industria, Turismo y Comercio a travs de la Secretara 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 inters pblico a nivel nacional que constituye una iniciativa enriquecedora y difusora de las nuevas tecnologas en Espaa en clara sintona con Europa. Su objetivo fundamental es servir como instrumento para desarrollar la Sociedad de la Informacin, con actividades propias en el mbito de la innovacin y el desarrollo de proyectos asociados a las Tecnologas de la Informacin y la Comunicacin (TIC), basndose en tres pilares fundamentales: la investigacin aplicada, la prestacin de servicios y la formacin. La misin de INTECO es aportar valor e innovacin a los ciudadanos, a las PYMES, a las Administraciones Pblicas y al sector de las tecnologas de la informacin, a travs del desarrollo de proyectos que contribuyan a reforzar la confianza en los servicios de la Sociedad de la Informacin en nuestro pas, promoviendo adems una lnea de participacin internacional. Para ello, INTECO desarrolla actuaciones en las siguientes lneas: Seguridad Tecnolgica: INTECO est comprometido con la promocin de servicios de la Sociedad de la Informacin cada vez ms seguros, que protejan los datos personales de los interesados, su intimidad, la integridad de su informacin y eviten ataques que pongan en riesgo los servicios prestados. Y por supuesto que garanticen un cumplimiento estricto de la normativa legal en materia de TIC. Para ello coordina distintas iniciativas pblicas en torno a la seguridad de las TIC, que se materializan en la prestacin de servicios por parte del Observatorio de la Seguridad de la Informacin, el Centro Demostrador de Tecnologas de Seguridad, el Centro de Respuesta a Incidentes de Seguridad en Tecnologas de la Informacin (INTECO-CERT) y la Oficina de Seguridad del Internauta (OSI), de los que se benefician ciudadanos, PYMES, Administraciones Pblicas y el sector tecnolgico. Accesibilidad: INTECO promueve servicios de la Sociedad de la Informacin ms accesibles, que supriman las barreras de exclusin, cualquiera que sea la dificultad o carencia tcnica, formativa, etc., incluso discapacidad, que tengan sus usuarios. Y que faciliten la integracin progresiva de todos los colectivos de usuarios, de modo que todos ellos puedan beneficiarse de las oportunidades que ofrece la Sociedad de la Informacin. Asimismo desarrolla proyectos en el mbito de la accesibilidad orientados a garantizar el derecho de ciudadanos y empresas a relacionarse electrnicamente con las AA.PP. Calidad TIC. INTECO promueve unos servicios de la Sociedad de la Informacin que cada vez sean de mayor calidad, que garanticen unos adecuados niveles de servicio, lo cual se traduce en una mayor robustez de aplicaciones y sistemas, un compromiso en la disponibilidad 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
Gua de Gua de Diseo de la Solucin Tcnica
resumen, servicios cada vez mejores. En esta lnea impulsa la competitividad de la industria del 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 la mejora de la competitividad de las empresas. Por ello, INTECO impulsa la formacin de universitarios y profesionales en las tecnologas ms demandadas por la industria.
Gua de Diseo de la Solucin Tcnica
NOTA DE EDICIN
Esta gua ha sido desarrollada por el Laboratorio Nacional de Calidad del Software de INTECO. 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 versin 2.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 autor Nada 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 http://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 de idioma y orden de lectura adecuado. Para ampliar informacin sobre la construccin de documentos PDF accesibles puede consultar la gua disponible en la seccin Accesibilidad > Formacin > Manuales y Guas de la pgina http://www.inteco.es.
en
AVISO LEGAL
CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad Carnegie Mellon. Las distintas normas ISO mencionadas han sido desarrolladas por la International Organization for Standardization.
Todas las dems marcas registradas que se mencionan, usan o citan en la presente gua son 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/o autora de las mismas. Nada de lo contenido en este documento debe ser entendido como concesin, por implicacin o de otra forma, y cualquier licencia o derecho para las Marcas Registradas deben tener una autorizacin escrita de los terceros propietarios de la marca. Por otro lado, INTECO renuncia expresamente a asumir cualquier responsabilidad relacionada con la publicacin de las Marcas Registradas en este documento en cuanto al uso de ninguna en particular y se eximen de la responsabilidad de la utilizacin de dichas Marcas por terceros. El carcter de todas las guas editadas por INTECO es nicamente formativo, buscando en todo momento facilitar a los lectores la comprensin, adaptacin y divulgacin de las disciplinas, metodologas, estndares y normas presentes en el mbito de la calidad del software.
NDICE
1. 2. INTRODUCCIN SOLUCIN TCNICA DENTRO DE CMMI 2.1. 2.2. 3. Metas y Prcticas especficas reas de proceso relacionadas 10 11 11 12 13 13 14 15 16 18 18 18 22 23 25 27 29 30 31 32 33 34 35 36 38 38 38 38 38 38 38
SELECCIN DE LA SOLUCIN 3.1. Desarrollo soluciones alternativas y criterios de seleccin 3.1.1. 3.1.2. 3.2. Asignacin de requisitos a la solucin Evaluacin del uso de productos COTS
Seleccin de soluciones
4.
DESARROLLO DEL DISEO 4.1. Disear el producto o componente de producto 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.2. 4.3. 4.4. Diseo preliminar Diseo detallado Documentacin de diseo Mtodos de diseo
Paquete de datos tcnicos Diseo de interfaces Realizar los anlisis sobre si desarrollar, comprar o reutilizar 4.4.1. Anlisis make-or-buy
5.
IMPLEMENTACIN DEL DISEO DEL PRODUCTO 5.1. 5.2. 5.3. Mtodos para la implementacin Pruebas unitarias Documentacin de soporte 5.3.1. Estndares de documentacin
6.
ANEXOS: ARTEFACTOS RELACIONADOS CON LA SOLUCIN TCNICA 6.1. Proceso para el Diseo 6.1.1. 6.1.2. 6.1.3. 6.1.4. 6.1.5. Objetivos Alcance Criterios de entrada Entradas Descripcin del proceso
6.1.6. 6.1.7. 6.1.8. 6.1.9. 6.1.10. 6.1.11. 6.1.12. 6.1.13. 6.2. 6.3. 6.4.
Recomendaciones Adaptaciones permitidas Medidas Validaciones Registros de calidad Criterios de salida Referencias Matriz de perfiles en el proceso
41 41 41 41 42 42 42 43 44 46 49 49 50 52 52 53 53 53 53 54 54 54 55 55 55 56 59 61 61 63 64 66 67 68 70
Lista de control para el diseo preliminar Lista de control para el diseo detallado Plantilla de diseo preliminar 6.4.1. 6.4.2. 6.4.3. 6.4.4. 6.4.5. 6.4.6. 6.4.7. 6.4.8. 6.4.9. 6.4.10. 6.4.11. 6.4.12. Visin General del proyecto Representacin de la Arquitectura Vista de Casos de Uso Vista Lgica Vista de Interaccin Vista de Seguridad Vista del proceso Vista del Despliegue Vista de Implementacin Vista de Datos Vista de Administracin Caractersticas Generales de Calidad Introduccin Descripcin general Especificacin de la arquitectura del software Especificacin de la interfaz Especificacin orientada a la funcin Especificacin orientada a objetos Especificacin orientada a datos Caractersticas generales sobre calidad Incidencias, asuntos y temas abiertos
6.5.
Plantilla de diseo detallado 6.5.1. 6.5.2. 6.5.3. 6.5.4. 6.5.5. 6.5.6. 6.5.7. 6.5.8. 6.5.9.
7. 8.
GLOSARIO REFERENCIAS
NDICE DE FIGURAS
Figura 1. Enfoque tradicional ................................................................................................20 Figura 2. Enfoque evolutivo ..................................................................................................21
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
1.
INTRODUCCIN
La gua de Diseo de la Solucin Tcnica est orientada al rea de proceso de CMMI de Solucin Tcnica. Pretende ser una gua de apoyo a la implementacin de dicha rea de proceso y de sus metas y actividades. En la primera parte de la misma se definir y situar esta rea de proceso dentro del modelo de 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 que propone el modelo, resaltando en muchos casos los mtodos, estndares y herramientas que 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 pueden ayudar en la implementacin de dicha rea de proceso.
10
2.
SOLUCIN TCNICA DENTRO DE CMMI
El propsito de la solucin tcnica es disear, desarrollar e implementar soluciones para los requisitos. 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 cada producto, 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 puede suceder 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 prcticas especficas: 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.
11
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) estn relacionadas con metas y actividades de otras reas de proceso de CMMI. A lo largo de la gua se van a ir comentando algunas de estas relaciones, aunque en este apartado se har un pequeo resumen de las mismas. Una de las reas con la que est relacionada es Desarrollo de Requisitos (RD), ya que en ambas se llevan a cabo actividades relacionadas con la asignacin de requisitos, el establecimiento de un concepto operacional y la definicin de los requisitos de interfaz que se han de disear en esta rea de proceso. Durante la implementacin de algunas de las metas hay que llevar a cabo revisiones entre pares y verificaciones del producto y componentes de producto, para lo que se puede obtener 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 decisiones que 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) se realizan interactivamente con las del rea de proceso de Solucin tcnica, por lo que tambin se ha de revisar. Y por ltimo, para obtener ms informacin sobre la mejora de la tecnologa de la organizacin, se puede consultar el rea de proceso Innovacin y despliegue en la organizacin (OID).
12
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 una identificacin y evaluacin concienzuda de diferentes soluciones alternativas. Hay que considerar las soluciones alternativas y los beneficios asociados para poder seleccionar la mejor solucin. Para la seleccin de dicha solucin hay que tener en cuenta requisitos clave, cuestiones de diseo, restricciones, caractersticas arquitectnicas, Se han de tomar decisiones en cuanto a la arquitectura, al desarrollo frente al uso de productos 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 de producto que abarcan la solucin. A la hora de definir o evaluar una solucin alternativa, se han de tratar los componentes de forma conjunta. Por ejemplo, no hay que seleccionar un producto 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 una solucin equilibrada en trminos de coste, planificacin, rendimiento y calidad. A la hora de seleccionar la solucin es importante que se involucre a las partes implicadas en el negocio. Se han de considerar un amplio rango de soluciones alternativas. La involucracin de las personas con diferentes habilidades y conocimientos puede ayudar a los equipos a identificar y tratar las suposiciones, restricciones y prejuicios. Se pueden realizar sesiones de brainstorming para estimular alternativas innovadoras. Para poder seleccionar una solucin de entre las alternativas que se han desarrollado habr que 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 los riesgos. La forma en la que se definirn estos criterios en detalle depender de los requisitos. Entre las consideraciones a tener en cuenta para la seleccin de las soluciones alternativas y los criterios de seleccin se incluyen las siguientes: Coste de desarrollo, fabricacin, compra, mantenimiento y soporte, etc. Rendimiento de las soluciones.
13
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 la hora de seleccionar la mejor solucin alternativa, hay que ver de qu manera se va a puntuar cada uno de estos criterios para cada una de las posibles soluciones. Para realizar esta seleccin se pueden asignar distintos pesos a los criterios, en base a las circunstancias del proyecto y de esta manera obtener una puntuacin ponderada para cada una de las soluciones. 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 de Requisitos, la cual describe la asignacin de requisitos una vez que se ha seleccionado una solucin. Sin embargo, tambin se puede realizar una asignacin provisional antes de la seleccin para ayudar en la comprensin de los beneficios relacionados con una solucin alternativa. Como se coment al principio del apartado, las soluciones reflejan la asignacin de los requisitos a los componentes del producto y se ha de ver como un conjunto. El objetivo es optimizar 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.
14
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 cabo la evaluacin de su uso para la seleccin de la solucin. COTS (Commercial off-the-shelf), es un adjetivo que describe productos software o hardware listos para usarse y disponibles para la compra por el pblico general. Los productos COTS estn diseados para ser implementados fcilmente en sistemas existentes sin necesidad de muchas modificaciones. Los productos COTS se pueden utilizar con o sin modificacin, cosa que tambin hay que decidir en el momento de realizar la seleccin. Muchas veces cuando se usan productos COTS hace falta que se modifiquen aspectos como pueden ser las interfaces. Si la decisin es adquirir un producto COTS, los requisitos deberan tenerse en cuenta para establecer el acuerdo con proveedores. Al nivel ms abstracto, se pueden considerar tres tareas a gran escala que habra que realizar 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 COTS podemos encontrar:
15
Tabla 1. Beneficios y desventajas del uso de productos COTS
Beneficios Integracin de componentes
Desventajas productos COTS con otros
No disponibilidad de las caractersticas a tiempo (vaporware) Reduccin de los costes de desarrollo Adaptacin tecnologas ms rpida a las nuevas Con frecuencia la correccin de errores slo est disponible en versiones tardas Algunas caractersticas no conocidas del producto COTS pueden impactar en el sistema Algunas caractersticas no requeridas pueden aumentar los requisitos de recursos Soporte a largo plazo de productos COTS (supervivencia de los proveedores, evolucin de caractersticas)
Reduccin del tiempo de desarrollo Reduccin de los riesgos de desarrollo
3.2.
SELECCIN DE SOLUCIONES
Una vez que se cuenta con distintas soluciones alternativas y con los criterios de seleccin adecuados hay que hacer la eleccin de la solucin que mejor satisfaga los criterios establecidos. Ninguna solucin ser la mejor para todos los criterios. Habr que seleccionar una solucin que proporcione un equilibrio entre coste, planificacin, rendimiento y riesgos durante el ciclo de vida del producto. Elegir una solucin alternativa puede requerir un proceso de evaluacin formal que se centre en las alternativas identificadas contra los criterios establecidos. El rea de proceso de CMMI DAR puede ayudar en la seleccin de la mejor solucin alternativa que satisfaga las necesidades 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, tales como provisiones para una insercin fcil de nuevas tecnologas o la capacidad de utilizar mejor los productos comerciales existentes.
16
Los criterios necesarios para las tcnicas de toma de decisiones van desde decisiones 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 las razones de la seleccin. Esto ayudar a la hora de querer examinar posteriormente por qu se 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 decisiones formales. 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 suficientemente completos o detallados para diferenciar adecuadamente las soluciones alternativas, se tendr que volver a definir dichos criterios y volver a empezar con la seleccin.
17
4.
DESARROLLO DEL DISEO
Una vez que se ha seleccionado la solucin, habr que pasar al desarrollo del diseo. Un diseo describe los componentes de un producto y sus interconexiones. Adems, gua las actividades de un amplio rango de personas involucradas en el negocio, incluyendo desarrolladores, 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 contenido apropiado para llevar a cabo las distintas fases del ciclo de vida del producto: implementacin, modificacin, mantenimiento, sustento e instalacin. El diseo del producto consiste en dos amplias fases que se pueden superponer durante la ejecucin: diseo preliminar y diseo detallado. Al final de la gua se han incluido una serie de anexos en los que se pueden encontrar distintos artefactos que pueden ayudar a la hora de llevar a cabo las actividades relacionadas con la Solucin Tcnica. El primero de estos artefactos es un posible Proceso para el Diseo. Una vez que se ha desarrollado el diseo habr que comprobar que es adecuado. Para ello se puede hacer uso de listas de comprobacin para revisar que tanto el diseo preliminar como el detallado son completos. En el anexo podemos ver un ejemplo de dichas listas de comprobacin.
4.1.1.
Diseo preliminar
El diseo preliminar establece las capacidades del producto y la arquitectura del producto o sistema, incluyendo identificaciones de componentes de producto, estados y modos del sistema, 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)
18
La definicin de la arquitectura est conducida por un conjunto de requisitos arquitectnicos desarrollados durante el proceso de desarrollo de requisitos. La arquitectura define los elementos estructurales y los mecanismos de coordinacin que satisfarn los requisitos a medida que los detalles del diseo del producto se establecen. La utilizacin de estndares organizacionales puede ayudar a conseguir consistencia y completitud en el diseo. Son muchas las tareas que hay que realizar dentro de la definicin de la arquitectura. A continuacin, se muestra una tabla con algunas de ellas:
Tabla 2. Tareas de definicin de la arquitectura
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 frameworks de 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 que permiten generar casos de uso y escenarios de calidad para refinar la arquitectura. Tambin se 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 de forma peridica durante el diseo del producto. Un escenario es una secuencia de eventos que pueden ocurrir durante la utilizacin del producto, y que se utiliza para hacer explcitas las necesidades de las personas involucradas en el negocio. Por el contrario, un concepto operativo para un producto depende 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
19
iniciales, se desarrollan soluciones conceptuales para usarlas cuando se analizan los requisitos. 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 de componentes de producto, los conceptos operativos pueden convertirse en escenarios (requisitos) de componentes de productos. Los conceptos y escenarios operativos se desarrollan para facilitar la seleccin de soluciones de componentes de producto, que cuando se implementen, satisfarn el uso previsto del producto. Los conceptos y escenarios operativos documentan la interaccin de los componentes de producto con el entorno, los usuarios 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 la arquitectura del producto. En este apartado y en el que viene a continuacin se tratarn tanto un enfoque tradicional como uno evolutivo de la arquitectura de sistemas. Se han desarrollado muchas metodologas para el soporte de un modelo de desarrollo de sistemas tradicional. Los pasos consisten normalmente en la definicin de requisitos, la consideracin 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 tradicional
O P C I O N E S
D I S E O
Tiempo
El enfoque tradicional es efectivo cuando los requisitos estn bien definidos y se mantienen constantes durante el periodo de desarrollo del sistema. Si la implementacin del sistema es larga, los requisitos pueden evolucionar debido a cambios y a nuevas tecnologas que
20
ofrezcan una serie de alternativas y oportunidades que el enfoque tradicional no puede manejar. 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 tratar la incertidumbre de requisitos y de la tecnologa, especialmente para sistemas con un tiempo de desarrollo y una vida til del producto largos. Este enfoque se ilustra en la figura que aparece a continuacin. Al contrario que con el enfoque anterior, con ste se permite que: Los requisitos sean ms abstractos y por lo tanto, estn sujetos a interpretacin. Las soluciones alternativas se exploren y se busquen tan lejos como estn disponibles las opciones de nuevas tecnologas. Los diseos intermedios se guarden y algunos de ellos se implementen como prototipos, pero no se implementen de forma operativa. Otros son implementados de forma tradicional.
En cualquier momento del proceso de desarrollo, cuando hay una necesidad de construir un sistema, se selecciona e implementa la solucin disponible que mejor cumpla los requisitos actuales usando cualquier enfoque de ingeniera de sistemas.
Figura 2. Enfoque evolutivo
Soluciones que llevan al diseo P R O B L E M A S O L U C I O N E S Tiempo

La arquitectura puede incluir estndares y reglas de diseo gobernando el desarrollo de los componentes de producto y sus interfaces, as como sirviendo de gua para los desarrolladores del producto. En el contexto de los requisitos arquitectnicos, se pueden desarrollar y analizar mltiples arquitecturas para el soporte de soluciones alternativas para determinar las ventajas y desventajas.
21
4.1.2.
Diseo detallado
Durante el diseo detallado, se finalizan los detalles de la arquitectura del producto y se definen completamente los componentes del producto y las interfaces. Los desarrolladores pueden evaluar el uso de productos heredados o productos COTS. A medida que el diseo madura, se hace un seguimiento de los requisitos asignados a componentes de producto de nivel ms bajo para asegurar que dichos requisitos se satisfacen. Con frecuencia se establecen criterios de diseo para asegurar que el producto o componentes de producto tienen uno o ms de los siguientes atributos de calidad: Capacidad de mantenimiento: facilidad que presenta un sistema o software para proceder 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 ser comprendido, 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 los recursos empleados o costes incurridos. Escalabilidad: propiedad de un sistema de cambiar su tamao o configuracin para adaptarse a circunstancias cambiantes; indica la habilidad de un sistema para extender su margen de operaciones sin perder calidad, manejar el crecimiento continuo de trabajo de manera fluida, o estar preparado para hacerse ms grande sin perder calidad en los servicios ofrecidos. Fiabilidad: probabilidad de que un sistema o dispositivo desarrolle una determinada funcin bajo ciertas condiciones y durante un perodo de tiempo determinado. Modularidad: capacidad que tiene un sistema de ser estudiado, visto o entendido como la unin de varias partes que interactan entre s y que trabajan para alcanzar un objetivo comn, realizando cada una de ellas una tarea necesaria para la consecucin 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 cumplir las condiciones de caja negra, es decir, ser independiente del resto de los mdulos y comunicarse con ellos (con todos o slo con una parte) a travs de unas entradas y salidas bien definidas. Portabilidad: caracterstica de un software para ejecutarse en diferentes plataformas; a mayor portabilidad menor es la dependencia del software con respecto a la plataforma. Un prerrequisito para la misma es la abstraccin generalizada 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
22
manera 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 y dentro de los lmites de su autorizacin. Usabilidad: facilidad con que las personas pueden utilizar un sistema o herramienta particular 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 el alcance de los productos o componentes de producto exponen qu caractersticas o factores de calidad deben usarse para propsitos de diseo. Este paradigma se puede usar para verificar que los factores de calidad se incluyen en los productos o componentes de producto 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 para responder a estas preguntas. Las preguntas ayudarn a medir si se est alcanzando la meta definida, por lo tanto se considerarn preguntas que sean potencialmente medibles. Para ms informacin sobre este paradigma se puede consultar la Gua de Mejores Prcticas de Calidad de Producto de INTECO. En la ingeniera del software el diseo detallado se centra en el desarrollo de componentes de producto software. Se define la estructura interna de los componentes de producto, se generan los esquemas de datos, se desarrollan los algoritmos y se establecen heursticas para proporcionar las capacidades del componente de producto que satisfarn los requisitos asignados. En la ingeniera del hardware el diseo detallado se centra en el desarrollo de productos electrnicos, mecnicos, electro-pticos, y otros productos hardware y sus componentes. Se desarrollan esquemas elctricos y diagramas de interconexin, se generan modelos de montaje 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 se propondrn distintas plantillas para su desarrollo. Un documento de diseo es una forma de comunicar cules son las decisiones de diseo y por qu tales decisiones son buenas. Un documento de diseo de software es una descripcin escrita de un producto software, que escribe el diseador para que sirva de gua al equipo de desarrollo sobre la arquitectura del proyecto. Un documento de diseo ha de ser 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 de un producto, as que es importante que se desarrolle y distribuya de la forma ms efectiva posible. Una buena organizacin, informacin completa y una escritura clara son factores clave para el xito de cualquier documento de diseo, pero hay otros factores menos obvios
23
que se pueden utilizar para hacer que los documentos sean ms fciles de leer y comprender: Saber quin va a ser la audiencia. A la hora de escribir documentacin de diseo efectiva hay que estar seguro de que ayude a satisfacer las necesidades de la audiencia. Por lo tanto es importante saber a quin va a ir dirigido el documento y cules son sus necesidades. Hay que conocer si la audiencia fundamental van a ser programadores, jefes de proyecto, ejecutivos, personal de marketing Puede ser complicado satisfacer a todos con un mismo documento, por lo que sera aconsejable organizar el documento de tal forma que cada uno lea solo las secciones 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 lectores sobre 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 es presentarlo en forma narrativa en vez de entenderlo como una simple coleccin de especificaciones, descripciones, ilustraciones y diagramas bien organizados. Usar personajes. Los personajes principales de la documentacin pueden ser las personas que representan los objetivos y necesidades del uso del diseo. Algo tan simple 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 walkthroughs. Los escenarios son como historias cortas: comunican la situacin de una persona y describen sus motivaciones, expectativas y objetivos, sin entrar en los detalles del diseo. Los escenarios son especialmente tiles en las etapas tempranas de un proyecto. Los walk-throughs son buenas herramientas de comunicacin a menor nivel. Son procedimientos que explican paso a paso cmo la persona interacta con el producto, cada accin que realiza y cada respuesta que obtiene del sistema. Son tiles para la explicacin de comportamientos de interfaces. Ambas herramientas funcionan mejor cuando se acompaan de ilustraciones o imgenes del diseo, pero hay que tener cuidado con los documentos basados en narrativas, ya que no son apropiados para todas las situaciones. Algunos documentos de diseo se utilizan como guas de referencia para desarrolladores, por ello, 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 un diseo, puede ser tentador explicar slo el funcionamiento del producto y mostrar cmo es. Sin embargo, para algunas audiencias esto no es suficiente. En algunos casos querrn saber tambin el por qu de lo que aparece en el diseo (por qu se ha incluido cierta caracterstica, por qu cierto elemento se comporta de una forma determinada). Se puede explicar cmo satisfarn los objetivos las decisiones
24
tomadas. El diseo tambin se puede describir en trminos de los requisitos de negocio que satisface. Diseo del documento en s. Una cosa que a veces se pasa por alto es el diseo del documento en s. Hay documentos que son imposibles de leer por su distribucin desordenada. El formato del documento debe de ser claro y consistente. Usar el presente y la voz activa. Si se est realizando documentacin de diseo, el producto es lo que se escribe y el tono de la escritura debera reflejarlo. El uso de la voz 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 una plantilla de un diseo de alto nivel o preliminar y otra de un diseo detallado. Ambas plantillas son slo ejemplos por lo que deberan adaptarse a las necesidades del proyecto y la propia organizacin. 4.1.3.1. IEEE 1016 Prctica recomendada para la descripcin de los diseos software
El estndar IEEE 1016 es una prctica recomendada para la descripcin de los diseos software. Este estndar especifica la informacin necesaria y la organizacin recomendada para desarrollar la descripcin del diseo del software. Dicha descripcin es una representacin del sistema software que se utiliza como medio para la comunicacin de informacin sobre el diseo. En base a esta prctica, el diseo del software se debe basar en los requisitos del software y debe proporcionar la informacin necesaria para permitir la implementacin del software. La descripcin del diseo del software muestra como se estructurar el sistema para satisfacer los requisitos identificados en la especificacin de requisitos. Es una traduccin de los requisitos en una descripcin de la estructura del software, los componentes del software, las interfaces y los datos necesarios para la fase de implementacin. IEEE Std. 1016 asegura que los diseos software se documentan de forma sistemtica y exhaustiva. La implementacin de este estndar puede ayudar a mejorar el proceso de desarrollo 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 diseo efectivos. 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
25
diseo contra los casos o escenarios de uso y revisar el diseo para reflejar decisiones tomadas. Es necesario identificar, desarrollar o adquirir los mtodos de diseo apropiados para el producto. Para evaluar los distintos mtodos de diseo podemos contar con los siguientes criterios: Capacidad de descomposicin en componentes: el mtodo ayuda a descomponer un problema nuevo en varios sub-problemas? Capacidad de composicin: el mtodo ayuda a construir nuevos sistemas a partir de componentes software? Capacidad de entendimiento de los componentes: se pueden entender los componentes de forma separada? Compatibilidad de componentes: estn los componentes bien definidos y cuentan con 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 la situacin particular en la que se aplique. Un mtodo de diseo puede ser efectivo en varias compaas y no serlo en otra con caractersticas diferentes. Adems, hay que seleccionar los 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, si las personas que lo tienen que llevar a cabo no tienen la formacin adecuada, puede que dicho mtodo no sea efectivo. Tambin hay que tener en cuenta la ayuda que se proporciona al diseador y la efectividad de dicha ayuda en relacin con el coste de la misma. Se deben establecer y mantener criterios para poder determinar la efectividad de los mtodos de diseo. Los mtodos altamente sofisticados no son necesariamente efectivos en las 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 pocos de los aspectos del producto y puede ser completamente diferente de la implementacin final. El propsito convencional de un prototipo es permitir evaluar diferentes propuestas del diseo del producto final. El prototipado es una tcnica importante que puede ayudar a descubrir deficiencias de diseo. Modelos estructurales. Un modelo estructural es el mapa arquitectnico de un sistema o familia de sistemas, que puede facilitar el diseo de productos. Diseo orientado a objetos. El diseo orientado a objetos es el proceso de planificar 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
26
interacciones para resolver un problema de negocio que fue identificado y documentado durante el anlisis orientado a objetos. Modelos de entidad-relacin. El modelo entidad-relacin es el modelo conceptual ms utilizado para el diseo conceptual de bases de datos. El modelo entidadrelacin est formado por una serie de conceptos que permiten describir la realidad mediante un conjunto de representaciones grficas y lingsticas. Reutilizacin de diseos. La reutilizacin de diseos es la inclusin de componentes diseados previamente en software o hardware. La reutilizacin de diseos hace ms rpido y barato el diseo y construccin de un nuevo producto, ya que los componentes no slo estn ya diseados, sino tambin probados. Patrones de diseo. Un patrn de diseo es una solucin general reutilizable a un problema en diseo de software. No es un diseo terminado que se pueda transformar directamente en cdigo. Es una descripcin o plantilla de cmo solucionar un problema, que puede usarse en situaciones diferentes.
Una vez que se ha desarrollado el diseo, se pueden utilizar mtodos de verificacin que ayuden a asegurar que el diseo se adhiere a estndares y criterios aplicables. Tales mtodos de verificacin incluyen revisiones entre pares, simulaciones de diseos y uso de prototipos. Ejemplos de estndares de diseo incluyen los siguientes (algunos de estos estndares pueden ser criterios de diseo, particularmente en circunstancias donde los estndares no se 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 o componente de producto y la informacin adicional necesaria para el soporte de su uso efectivo.
27
Un paquete de datos tcnicos proporciona al desarrollador una descripcin exhaustiva del producto o componente de producto a medida que se desarrolla. El diseo debera ser registrado en un paquete de datos tcnicos durante el desarrollo del diseo preliminar para documentar la definicin de la arquitectura, y debera mantenerse durante la vida del producto para registrar los detalles esenciales del diseo del producto. El paquete de datos tcnicos proporciona la descripcin de un producto o componente de producto, incluyendo los procesos del ciclo de vida relacionados con el producto. Incluye dibujos, listas asociadas, descripciones de diseo, bases de datos de diseo, estndares, requisitos de rendimiento, disposiciones para el aseguramiento de la calidad y detalles de empaquetado. 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 de producto (p.ej. requisitos materiales y de fabricacin no sern tiles para componentes de producto 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 el ciclo de vida del producto. Fundamento de las decisiones y caractersticas (p.ej. requisitos, asignacin de requisitos y elecciones de diseo)
Un paquete de datos tcnicos contiene mucha informacin. Para incrementar su usabilidad y utilidad, hay que definir una serie de criterios para definir qu incluir, organizar los datos de acuerdo a la arquitectura del producto y proporcionar puntos de vista relevantes, como
28
pueden ser: clientes, requisitos, el entorno, funcional, estados/modos, construccin, gestin,
lgica, seguridad, datos,
4.3.
DISEO DE INTERFACES
Adems de llevar a cabo el diseo del producto o componente de producto, hay que disear tambin las interfaces de los componentes de producto usando para ello una serie de criterios establecidos previamente. Hay que identificar interfaces asociadas con otros componentes del producto, con elementos externos y con los procesos del ciclo de vida relacionados con el producto. Ejemplos de tales interfaces incluyen interfaces con equipamiento de pruebas, sistemas de transporte, sistemas de soporte, Se deben tratar las 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 y controlar durante el ciclo de vida del proyecto. Los proyectos deben desarrollar descripciones de interfaces detalladas durante el refinamiento del producto y los requisitos de producto y durante la seleccin de soluciones alternativas. Cuando un elemento externo es un producto COTS, la descripcin del producto COTS se convierte en un requisito al que todos los otros componentes del producto que interacten con el producto COTS se deben adherir. 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, con frecuencia, 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 formal basado en: establecer criterios para la correccin de una interfaz, identificar alternativas de diseo, etc., como el que se puede llevar a cabo en el diseo del producto. Para el uso de procesos 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 de interfaces que definen interfaces en trminos de elementos de datos aprobados, protocolos
29
utilizados en la interaccin, etc. Estos documentos son especialmente tiles en el control de los componentes de producto que se estn construyendo por equipos diferentes. Se han de documentar los diseos de interfaces seleccionados de entre todas las alternativas de diseo de la interfaz y los fundamentos para dicha seleccin. Los diseos de interfaces se deberan documentar en el paquete de datos tcnicos. Los datos de las interfaces 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 recomendable preparar una tabla que relacione las interfaces entre componentes de producto (o entre componentes de producto y entornos). El objetivo es conseguir cobertura y completitud de todas 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 alternativas de diseo hay que tener en cuenta la posible adquisicin de productos COTS. Adems de esta 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 con frecuencia como un anlisis make or buy y se basa en un anlisis de las necesidades del proyecto. Este anlisis se ha de llevar a cabo en etapas tempranas del ciclo de vida, durante la primera iteracin del diseo, continuando durante el proceso de diseo y completando con la decisin de desarrollar, adquirir o reutilizar el producto. Entre los factores que pueden afectar a la decisin de desarrollar o adquirir se incluyen los siguientes: La funcionalidad que proporcionan los productos y cmo esas funciones encajarn en 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.
30
Impacto en las competencias clave. Licencias, garantas, responsabilidades y limitaciones asociadas a los productos que se van a adquirir. Disponibilidad de productos. Reduccin de riesgos.
La decisin de si comprar o desarrollar se puede llevar a cabo siguiendo un enfoque de evaluacin formal.
4.4.1.
Anlisis make-or-buy
La decisin sobre si desarrollar o comprar es el acto de hacer una eleccin estratgica entre desarrollar un producto o componente de producto de forma interna o adquirirlo de un proveedor externo (outsourcing). Entre las consideraciones que pueden hacer que el desarrollo sea interno o externo podemos encontrar:
Tabla 3. Consideraciones del desarrollo interno y externo Desarrollo interno Desarrollo externo
Consideraciones de coste. Falta de habilidades. Necesidad de ejercer un control directo sobre el desarrollo y/ o la calidad. Mejor control de calidad. Proveedores poco fiables. Proveedores no competentes. Consideraciones indirectas de control de gerencia. Razones polticas, sociales o del entorno. Consideraciones de coste. Insuficiente capacidad para el desarrollo. Componentes no esenciales para la estrategia de la empresa.
En ambos casos, una de las consideraciones ms importantes es la del coste, por lo que hay que tener en cuenta todos los elementos que le puedan afectar.
31
5.
IMPLEMENTACIN DEL DISEO DEL PRODUCTO
Una vez que se ha desarrollado el diseo y todo lo que ello conlleva, hay que implementar los componentes de productos y la documentacin de soporte asociada en base a dicho diseo. La implementacin normalmente incluye la ejecucin de pruebas unitarias sobre los componentes de producto. Las caractersticas de la implementacin dependen del tipo de componente de producto. Entre los ejemplos de caractersticas de la implementacin (tanto a nivel de software como de 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 se pueden adherir a estndares y criterios aplicables. Dichos estndares y criterios de implementacin dependern del tipo de producto que se implemente. La organizacin puede establecer sus propios estndares y criterios de implementacin. Algunos ejemplos de estndares de implementacin que se pueden utilizar son los siguientes: Estndares de lenguaje (estndares para lenguajes de programacin de software y lenguajes de descripcin de hardware). Requisitos de planos. Listas de piezas estandarizadas. Piezas manufacturadas. Estructura y jerarqua de los componentes de productos software.
32
Estndares de procesos y de calidad.
Algunos ejemplos de criterios de implementacin que se pueden tener en cuenta para la implementacin: Modularidad: capacidad que tiene un sistema de ser estudiado, visto o entendido como la unin de varias partes que interactan entre s y que trabajan para alcanzar un objetivo comn, realizando cada una de ellas una tarea necesaria para la consecucin de dicho objetivo.; cada una de esas partes en que se encuentre dividido 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 y dirigido a la minimizacin simultnea de las partes que constituyen el sistema y de las 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 determinada funcin bajo ciertas condiciones y durante un perodo de tiempo determinado. 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 manera 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 y dentro de los lmites de su autorizacin. Capacidad de mantenimiento: facilidad que presenta un sistema o software para proceder a su mejora y optimizacin, as como a la correccin de sus defectos y prevencin, 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 de implementacin. Para la ingeniera del software se pueden utilizar los siguientes mtodos de codificacin de software: Programacin estructurada: impone una estructura lgica en la escritura de un programa para hacerlo ms eficiente y fcil de entender y modificar. Las rutinas largas 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
33
operaciones (funciones) que se pueden aplicar a las estructuras de datos. La estructura 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 de herramientas que permitan la generacin automtica de cdigo. Reutilizacin de cdigo: se basa en la reutilizacin de cdigo existente para la construccin de software nuevo.
Para la ingeniera del hardware se pueden utilizar los siguientes mtodos de implementacin 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 la implementacin de los componentes de producto. Adems, hay que realizar revisiones entre pares que permitan comprobar que los componentes de producto estn disponibles para la integracin del producto. Las pruebas unitarias se encargan de buscar defectos y verificar el funcionamiento de los componentes de producto que se puedan probar de forma separada. Las pruebas unitarias se deben realizar de forma aislada al resto del sistema. Las pruebas unitarias no slo se llevarn a cabo sobre el cdigo, sino tambin sobre otros componentes del producto. Los mtodos de pruebas unitarias que se utilizarn, dependern del tipo de componente de producto que se est implementando. Para el caso de la ingeniera del software, podemos encontrar los siguientes mtodos de pruebas unitarias: Pruebas de cobertura de sentencia: se trata de probar todas las sentencias existentes en la parte de cdigo que se est probando. Pruebas de cobertura de decisin: se evalan tanto la salida si como la no de todas las estructuras de control.
34
Pruebas de cobertura de predicados: se ejecutan todas las expresiones booleanas tanto 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 las fronteras tanto de las particiones de entrada como de salida. Pruebas de valores especiales: este tipo de pruebas se basan en utilizar el conocimiento en el dominio y la experiencia de las personas que desarrollan las pruebas.
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 Mejores Prcticas de Calidad de Producto de INTECO.
5.3.
DOCUMENTACIN DE SOPORTE
En este apartado se tratar el desarrollo y mantenimiento de la documentacin que se usar para instalar, operar y mantener el producto. Aunque el foco de la Solucin Tcnica est en la arquitectura, diseo e implementacin, es importante apuntar que esta rea no est completa hasta que la documentacin relacionada con la instalacin, administracin, operacin y mantenimiento del producto est desarrollada y revisada. Es recomendable que en el proyecto se desarrollen versiones preliminares de la documentacin en las etapas tempranas del ciclo de vida y se revisen por todas las personas involucradas en el negocio. La documentacin de usuario describe cada caracterstica del programa y ayuda al usuario en el uso del mismo. Una buena documentacin de usuario puede tambin proporcionar ayuda en la resolucin de problemas. Es muy importante que los documentos de usuario no sean confusos y que estn actualizados. Los documentos de usuario no tienen por qu tener una organizacin concreta, pero es muy importante que tengan un ndice correcto. Los usuarios de un sistema no son todos iguales. La documentacin se debe desarrollar pensando en las diferentes tareas de los usuarios y los distintos niveles de experiencia. Se deben realizar distintos documentos ya que instaladores, operadores y usuarios tienen diferentes necesidades. Es particularmente importante distinguir entre los usuarios finales y los administradores de sistema. Los usuarios finales utilizan el producto para que les ayude
35
en alguna tarea y necesitan saber de qu manera lo va a hacer. En cambio los administradores 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 hay que seleccionar, disear e implementar una solucin. Por ello, existen mtodos y guas de estilos 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 sea necesario. 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 la documentacin de usuario. Entre ellos podemos destacar los siguientes: BS-7649 The Design and Preparation of Documentation for user of Application software (El Diseo y Preparacin de Documentacin para usuarios de software de Aplicaciones): proporciona informacin sobre la informacin que necesitan los usuarios, 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
36
formato de la documentacin de usuario, incluyendo tanto documentos impresos como electrnicos. ISO/IEC 26514:2008 Systems and software engineering -- Requirements for designers 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 de usuario de software como parte de los procesos del ciclo de vida. Define el proceso de documentacin desde el punto de vista del desarrollador de la documentacin. Especifica la estructura, contenido y formato de la documentacin de usuario y proporciona guas en el estilo de la documentacin. Aplica tanto a documentacin impresa como electrnica. ISO/IEC TR 9294:2005 Information technology -- Guidelines for the management of software documentation (Tecnologa de la Informacin Pautas para la gestin de documentacin software): ofrece orientacin en la gestin de la documentacin software con la intencin de ayudar a que se desarrolle documentacin efectiva en las organizaciones.
37
6.
ANEXOS: ARTEFACTOS RELACIONADOS CON LA SOLUCIN TCNICA
A continuacin se muestran una serie de artefactos que pueden proporcionar ayuda a la hora de implementar las actividades relacionadas con la Solucin Tcnica.
6.1.
6.1.1.
PROCESO PARA EL DISEO

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 de alto nivel y el de bajo nivel, se pueden combinar en un diseo completo. Diseo de alto nivel (Sistema /Arquitectura Software): nos permite conocer la organizacin fundamental del sistema atendiendo a sus componentes, sus relaciones y el entorno, as como los principios que gobiernan el diseo y su evolucin. Esto incluye particiones del sistema, identificacin de componentes, estado del sistema y modos, interfaces entre componentes, e interfaces con sistemas externos.
38
Diseo a bajo nivel: define la estructura y las capacidades de los componentes del sistema (por ejemplo: detalles internos de implementacin). Seleccionar la arquitectura ptima
6.1.5.1.
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 es posible, de procesos para el anlisis de decisiones. La arquitectura seleccionada se evala por los arquitectos lderes en revisiones de gestin tecnolgica. 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 de posibles mdulos reutilizables, generar la flexibilidad requerida para aadir futuras funcionalidades, interconexin con un cliente o producto, problemas de rendimiento debidos a 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
39
(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 a los procesos fsicos del sistema. El diseador evala las diferentes configuraciones posibles contra 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 para su incorporacin en el proyecto. El equipo de diseo optimiza el anlisis de realizar / adquirir / reutilizar para los componentes del producto usando alguna plantilla para la toma de decisiones de la forma apropiada. 6.1.5.3. Desarrollo de diseo a bajo nivel
El diseador identifica, desarrolla o adquiere mtodos y herramientas de diseo apropiadas para el sistema / software. El diseador conecta las interfaces entre los componentes en trminos de control del flujo de datos; 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 de aplicaciones (API), considerando los parmetros pasados y los valores de retorno, la estructura de datos, etc. El diseador describe la estructura de datos usada por cada modulo para el procesamiento interno en trminos de definicin de los datos y estructura y las relaciones entre ellos. El diseador define cada elemento de la estructura de datos en trminos de tipo y tamao. El diseador tambin identifica los eventos que afectan a esa estructura de datos y sus efectos. 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 se ha 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 los diagramas de flujo se utilizan para representar la lgica. El diseador actualiza el documento SRS basado en los requisitos derivados de la solucin de diseo adoptada, si existen. El diseador documenta los estndares, criterios, componentes propietarios, frameworks, y APIs que sern utilizados para la construccin del sistema / software.
40
Tras la aprobacin del diseo de bajo nivel, el jefe de proyecto prepara el plan de pruebas de 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 la trazabilidad del diseo de bajo nivel al de alto nivel, y la trazabilidad del diseo de alto nivel con 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 defectos encontrados 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 de pruebas si es necesario). El diseador valida el diseo con el cliente y se establece un lnea base que se alinea con la 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 evaluacin de 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
41
Revisiones en determinados puntos de verificacin
6.1.10.
-
Registros de calidad
Checklist para el diseo de alto nivel Checklist para 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 Checklist de diseo de alto nivel Checklist de 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
42
6.1.13.
Roles -
Matriz de perfiles en el proceso
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 Preparacin Desarrollar aproximaciones alternativas y seleccionar la ptima Dividir mdulos sistema. Identificar arquitectura sistema en el la del Diseador
Responsabilidad Revisin Expertos Tcnicos Aprobacin Expertos Tcnicos Responsabilidad Diseador
Salidas
Documento toma decisiones
de de
Diseador
Por pares
Arquitecto lder
Diseador
Diseo nivel
de
alto
Realizar el anlisis realizar /comprar /reutilizar Crear diseo de la base de datos Crear el diseo de interfaces
Diseador
Por pares
Cliente, RM
Diseador
Documento toma decisiones
de de
DBA Diseador Diseador
Por pares
Por pares
DBA / Diseador
Diseo nivel Diseo nivel
de
bajo
Por pares
Por pares
Diseador
de
bajo
43
Crear el procedimiento de diseo Actualizar matriz trazabilidad requisitos la de de
Diseador
Por pares
Por pares
Diseador
Diseo nivel
de
bajo
Diseador
SQA
PM
PM
Matriz trazabilidad requisitos
de de
Verificar y validar el diseo. Cierre del mismo. Establecer una lnea base para el diseo y la matriz de trazabilidad de requisitos.
Diseador
Por pares / Cliente
Cliente
PM
Documentos de diseo, registros de revisin. Documentos de diseo bajo lnea base, al igual que la matriz de trazabilidad de requisitos. Plan de pruebas de integracin, casos de prueba de integracin
Diseador
SQA
PM
Preparacin del plan de pruebas y los casos de prueba
PT / PL
Por pares
PM
PM
6.2.
LISTA DE CONTROL PARA EL DISEO PRELIMINAR
Para controlar que el diseo preliminar se ha desarrollado de la forma correcta se puede utilizar una lista de control con una serie de preguntas que nos permitan valorar el estado de dicho diseo. A continuacin se muestran una serie de preguntas que podran formar parte de una lista de este tipo. Para cada una de ellas habra que valorar el estado y sealar los posibles comentarios que puedan surgir. El diseo general implementa todos los requisitos explcitos y cumple con todos los requisitos 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?
44
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 de DAR (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 las especificaciones? La arquitectura est diseada para introducir cambios con alta probabilidad de ocurrir 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?
45
6.3.
LISTA DE CONTROL PARA EL DISEO DETALLADO
Para controlar que el diseo detallado se ha desarrollado de la forma correcta se puede utilizar una lista de control con una serie de preguntas que nos permitan valorar el estado de dicho diseo. A continuacin se muestran una serie de preguntas que podran formar parte de una lista de este tipo. Para cada una de ellas habra que valorar el estado y sealar los posibles comentarios que puedan surgir. General:
Se han pensado en alternativas de diseo? Se han documentado las alternativas y la solucin decidida siguiendo el proceso de toma de decisiones? Se han seguido todos los estndares y metodologas de diseo aplicables? Se ha completado el diseo detallado, p.ej. estn completamente implementados los requisitos y el diseo de alto nivel? Para mejorar el cdigo existente, el diseo detallado muestra qu cdigo hay 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 y dependencias del diseo? Se han identificado todas las cuestiones relacionadas con la capacidad de mantenimiento? Todas las partes del diseo estn relacionadas con los requisitos de los documentos de negocio, usuario y sistema?
Funciones:
Estn especificadas todas las funciones de forma clara? Son todas las funciones lgicamente independientes?
46
Las especificaciones de cada mdulo implementan completamente la funcionalidad requerida en la documentacin de ms alto nivel? Se ha realizado un diseo modular de tal manera que se puedan reutilizar componentes? Proporciona el diseo una base adecuada para la escritura de cdigo y su mantenimiento? Se ha documentado el propsito de todos los componentes, funciones y procesos?
Interfaces:
Estn todas las interfaces bien definidas y son claras? Son consistentes todas las interfaces entre s, con otros mdulos y con los requisitos documentados a alto nivel? Las comunicaciones entre procesos estn correctamente especificadas? Se ha descrito y justificado una estrategia para el manejo de entradas y salidas? La interfaz facilita la localizacin y resolucin de problemas? Se ha minimizado el nmero y complejidad de interfaces? Se han descrito las caractersticas funcionales de la interfaz? Se ha representado el flujo de datos entre las funciones internas?
Estructuras de datos:
Estn divididas de forma clara las estructuras de datos? El diseo de la base de datos soporta la funcionalidad? Las estructuras de datos contienen todos los atributos definidos en el modelo de anlisis? Se han escogido las estructuras de datos mnimas necesarias para hacer el trabajo? Se pueden implementar directamente las estructuras de datos en el lenguaje de programacin elegido?
47
Estn bien definidas todas las estructuras de datos? Est especificado el contenido y la organizacin de la base de datos? Se ha descrito de forma clara la gestin y el uso de datos compartidos y almacenados? Se han descrito los elementos de datos del nivel ms bajo? Se han especificado rangos de valor?
Manejo de errores:
El diseo mantiene deteccin y recuperacin de errores? Se incluye una estrategia consistente para el manejo de errores? Las situaciones inusuales se manejan de forma razonable y no destructiva? Se han especificado todas las condiciones de error de forma completa y precisa? Los mensajes de error son nicos y con sentido?
Revisiones:
El documento de diseo de alto nivel se ha revisado, aprobado y se ha establecido una lnea base del mismo? Ha participado el equipo de pruebas en la revisin del documento del diseo detallado? En el caso de que hubiera alguna observacin en la revisin del diseo detallado, se han cerrado? El equipo de diseo forma parte del equipo de revisin?
Integracin:
Se ha preparado, revisado, aprobado y se ha hecho una lnea base del plan de pruebas de integracin despus de la aprobacin del diseo detallado? Se ha preparado, revisado, aprobado y se ha hecho una lnea base de los casos de prueba de integracin despus de la aprobacin del diseo detallado?
48
6.4.
6.4.1.
6.4.1.1.
PLANTILLA DE DISEO PRELIMINAR

Visin General del proyecto
Introduccin
La introduccin proporciona una visin general que incluye los propsitos, definiciones, acrnimos, abreviaturas, referencias 6.4.1.2. Propsito
Esta seccin define el rol o propsito del documento, y describe brevemente la estructura del documento. Se identifican las audiencias especficas para el documento con una descripcin de cmo se espera que se usen. 6.4.1.3. Alcance
Se describe el alcance general del esfuerzo del diseo. Mucha informacin se obtiene del documento de especificacin de requisitos software e incluye los objetivos del sistema y los requerimientos principales del software, restricciones y limitaciones del diseo. 6.4.1.4. Definiciones y Abreviaturas
Se describe cualquier trmino, acrnimo y abreviatura requerido para entender este documento. 6.4.1.5. Listado de Referencias
Proporcionar una lista completa de documentos a los que se hace referencia en el diseo de alto nivel. Se pueden incluir tanto documentos internos como proporcionados por el cliente. Por ejemplo: Plan de gestin del proyecto Especificacin de requisitos Informes de investigacin Notacin
6.4.1.6.
Describe el tipo de notacin para los diagramas que se ha utilizado para representar las vistas de la arquitectura. Se recomienda el uso del lenguaje de modelado unificado (UML). Si no se utiliza UML, entonces se debe proporcionar una leyenda detallada en esta seccin para todos los smbolos y semntica utilizada.
49
6.4.2.
Representacin de la Arquitectura
Describe de forma genrica la arquitectura del software para el sistema. 6.4.2.1. Metas y Restricciones de la Arquitectura
Describir los requisitos y objetivos del software que tienen un impacto significativo sobre la arquitectura; por ejemplo, seguridad, privacidad, portabilidad, distribucin, rendimiento, escalabilidad, reutilizacin. Esta seccin debera tambin capturar restricciones especiales que se debieran aplicar: estrategias de diseo e implementacin, herramientas de desarrollo, estructura del equipo, planificacin, etc. 6.4.2.2. Desarrollar diseos alternativos de la arquitectura
Desarrollar otros diseos que puedan satisfacer los requisitos del cliente y puedan obtener buen rendimiento, seguridad, privacidad, portabilidad, distribucin, escalabilidad, reutilizacin y una tasa baja de errores en el desarrollo de la aplicacin. Se debe crear una nueva seccin para cada solucin alternativa desarrollada y proporcionar la suficiente informacin para ser capaz de aplicar criterios de seleccin para elegir la ms apropiada. Este proceso debe estar documentado y se deben incluir los componentes del producto desarrollados, comprados o reutilizados segn criterios establecidos. Si aplica, se debe proporcionar un enlace a las recomendaciones de los documentos de anlisis y resolucin de decisiones (DAR) utilizados para identificar la solucin. 6.4.2.2.1. 6.4.2.2.2. 6.4.2.3. Solucin A Solucin B Requisitos y Visin de la Arquitectura
Se debe representar una visin de por qu se ha escogido una arquitectura en particular y cmo se alinea con los requisitos del software especificados adems de cumplir con la estrategia y metas corporativas. Esta visin debe explicar cmo la arquitectura permite futuras integraciones con otras aplicaciones y cmo se adapta a posibles cambios en la tecnologa. 6.4.2.4. Conformidad con Estndares Abiertos
Listado de todos los estndares abiertos y los nmeros de las versiones que la arquitectura cumple. 6.4.2.5. Soluciones Especficas de Vendedores
Listado de vendedores especficos, protocolos propietarios y APIs utilizados en esta arquitectura.
50
6.4.2.6.
Reutilizacin
Si se utiliza programacin orientada a objetos (OO), se debe proporcionar una ligera visin de cmo puede beneficiar al proyecto la incorporacin de componentes reutilizables, frameworks y patrones de diseo. Identificar las reas funcionales o componentes de negocio para los que la reutilizacin de componentes debe ser utilizada o adquirida. Identificar el lugar donde se deben aplicar los patrones de diseo. A la hora de reutilizar un componente se deben analizar aquellos que mejor se adapten a nuestras necesidades y que estarn en muchos casos en la base de datos del histrico de nuestra organizacin. 6.4.2.7. Componentes y frameworks reutilizados por el proyecto
Listado de los componentes del producto y frameworks a ser reutilizados por el proyecto incluyendo el nombre de vendedor y nombre del producto. Detallar cualquier beneficio tangible o intangible para el proyecto causado por la reutilizacin de los componentes y frameworks.
Tabla 5. Componentes y frameworks reutilizados Framework o componente reutilizable Nombre y versin Proveedor Lista de beneficios Repositorio donde se ubican
Vendedor, proyecto, abierto, etc.
otro cdigo
Beneficios proyecto.
para
el
URL donde encontrar informacin sobre los componentes/frameworks a reutilizar.
6.4.2.8.
Mecanismos para la Evaluacin de Componentes Reutilizables
Describir el mecanismo de evaluacin para los componentes reutilizables existentes. 6.4.2.9. Componentes y Frameworks Reutilizables
Identificar los componentes del negocio funcionales que son candidatos para la generalizacin. Proporcionar detalles (ej.: JAVADOC, modelo UML, etc.) sobre esos componentes y resumir las tareas requeridas para generalizarlos y que pueden ser reutilizados. Indicar la razn para crear un componente nuevo y la librera de componentes que lo contiene.
51
Tabla 6. Componentes y frameworks reutilizables Componentes candidatos Nombre Funcin de negocio o servicio que presta Nombre y/o identificacin Generalizacin Localizacin
Vistazo general de las extensiones que se necesitan para activar la reutilizacin general y el modelo del componente actual.
URL donde encontrar informacin sobre el componente existente.
6.4.3.
Vista de Casos de Uso
Listar aquellos casos de uso o escenarios procedentes del modelo de casos de uso (creado como parte de la especificacin de requisitos del sistema) que representan una funcionalidad significativa o principal del sistema final, o bien aquellos que cubren gran parte de la arquitectura. Incluir los casos de uso que utilizan elementos de la arquitectura o bien si sobrecargan o muestran un punto delicado de la arquitectura. La lista de casos de uso debe ser considerada para una arquitectura ejecutable. La notacin preferida para la vista de los casos de uso es UML. 6.4.3.1. Comprensin de los Casos de Uso
Mostrar cmo funciona el software para un determinado caso de uso (o escenario). Explicar cmo se configura la arquitectura para que permita que los casos de uso se cumplan.
6.4.4.
Vista Lgica
Describe la descomposicin funcional de la aplicacin basndose en una ordenacin lgica de los requisitos de la aplicacin. Los aspectos de la aplicacin con una funcionalidad similar se deben agrupar en un subsistema. Se deben representar las dependencias entre los subsistemas. Si se incluye desarrollo orientado a objetos (OO), entonces se deben describir las partes significativas de la arquitectura del modelo de diseo, como su descomposicin en subsistemas y paquetes. Para cada paquete significativo, mostrar su descomposicin en clases o interfaces. Presentar las clases significativas de la arquitectura y describir sus responsabilidades, as como las relaciones importantes basadas en la arquitectura, operaciones y atributos. La notacin preferida para la vista lgica es UML.
52
6.4.5.
Vista de Interaccin
Lista las distintas interacciones con las que cuenta la aplicacin. Estas interacciones pueden incluir interfaces de usuario, de software o hardware. 6.4.5.1. Interfaces de Usuario
Lista y describe las interfaces de usuario de la aplicacin. 6.4.5.2. Interfaces Software
Lista y describe las interfaces software de la aplicacin. 6.4.5.3. Interfaces hardware
Lista y describe las interfaces hardware de la aplicacin.
6.4.6.
Vista de Seguridad
Describir los distintos elementos y sistemas de seguridad con los que cuenta el software.
6.4.7.
Vista del proceso
Describir la descomposicin del sistema en procesos ms ligeros (hilos individuales de control) y procesos ms pesados (grupos de procesos ligeros). Organizar la seccin por grupos de procesos de negocio que se comunican o interactan. Si se incluye el desarrollo orientado a objetos (OO), entonces se debe representar la informacin solicitada utilizando diagramas de secuencia especficos del proyecto (diagramas de interaccin de objetos), preferiblemente utilizando la notacin UML. Donde sea posible, los diagramas explican el proceso de interaccin requerido por los casos de uso principales.
6.4.8.
Vista del Despliegue
Describir la configuracin de la plataforma fsica (procesador/almacenamiento) en la que el software va a ser desplegado. Si el sistema se va a desplegar en varios sitios, proporcionar una vista de despliegue para cada sitio diferente. Como mnimo, para cada configuracin, se deben indicar los nodos fsicos (ej.: ordenadores, CPUs, memorias) que ejecutan el software y sus interconexiones (ej.: bus, topologa LAN, punto a punto, WAN). Incluir un mapeo entre los procesos de la vista de proceso y los nodos fsicos. La notacin preferida es UML para la vista de despliegue.
53
6.4.9.
Vista de Implementacin
Describe la estructura general del modelo de implementacin y la descomposicin del sistema en capas y subsistemas como vimos en la perspectiva de desarrollo del software. Indicar cmo se ensamblarn los subsistemas a medida que aumenta el progreso de implementacin del proyecto. Esta seccin tambin proporciona una vista de los paquetes/ componentes que gua en el desarrollo del software y el ensamblado del sistema de acuerdo al plan de proyecto. 6.4.9.1. Vista General de las Capas
Nombrar y definir las distintas capas y su contenido, las reglas que gobiernan una determinada capa, y los lmites entre las mismas. Incluir un diagrama de componentes que muestre la relacin entre las capas. 6.4.9.2. Paquetes/Componentes
Describir el modo principal de comunicacin entre los procesos del sistema operativo, como el paso de mensajes, interrupciones, colas y protocolos. Indicar cmo se gestiona la concurrencia y la sincronizacin. Indicar cmo se optimizar el rendimiento (ej.: qu parmetros se deben modificar para que impacten en las operaciones (procesos/hilos)). Si se incluye el desarrollo orientado a objetos, entonces, para cada implementacin de un paquete/componente, incluir una subseccin con su nombre, descripcin y diagrama. 6.4.9.3. Interfaz
El diseador identifica las interfaces internas principales y todas las interfaces externas del sistema/software. Describa de forma breve la especificacin de las interfaces de los componentes, la descripcin de los componentes que forman las interfaces y las guas que se han seguido. Hacer referencia a guas de diseo de interfaces. 6.4.9.4. Criterios para la interfaz
Identificar los criterios de la interfaz de los componentes, funciones o aplicaciones.
6.4.10.
Vista de Datos
Describir el modelo lgico de los datos.
6.4.11.
Vista de Administracin
Describe las distintas opciones de la administracin del software.
54
6.4.12.
6.4.12.1.
Caractersticas Generales de Calidad

Fiabilidad
Describir las caractersticas/elementos de diseo relativos a la fiabilidad. Ej.: Medidas para asegurar una buena operatividad, mejorar la tasa de errores/tiempo, etc. 6.4.12.2. Usabilidad
Describir los elementos de usabilidad del diseo que aadan facilidades y funciones estndar. Ej.: Estndares GUI, tolerancia a errores del operador, etc. 6.4.12.3. Portabilidad, mantenibilidad
Describir los elementos de portabilidad y mantenibilidad del diseo que aaden independencia al sistema operativo y al hardware, permiten la planificacin de la frecuencia de mantenimiento y duracin, modularidad del diseo, etc. 6.4.12.4. Rendimiento
Describir los elementos del diseo que impactan en las caractersticas de rendimiento. Ej.: medidas para mejorar la potencia de la CPU, tasa de transacciones a disco, etc. 6.4.12.5. Seguridad
Describir las medidas de diseo tomadas para mejorar e incorporar los requisitos de seguridad. Ej.: Proteccin de datos y control de acceso, controles de seguridad relativos a polticas de sistemas, etc. 6.4.12.6. Capacidad de Prueba
Describir las medidas de diseo identificadas que mejoren la capacidad de prueba del sistema. 6.4.12.7. Disponibilidad y Escalabilidad
Describir el clustering, la tolerancia a los fallos y los mecanismos de redundancia utilizados para alcanzar la disponibilidad y escalabilidad necesarios en el sistema. Se incluyen concesiones entre el rendimiento y la escalabilidad.
6.5.
6.5.1.
PLANTILLA DE DISEO DETALLADO

Introduccin
A lo largo de este documento se deberan hacer referencia a documentos relevantes. En planes de diseo multinivel, cada plan de bajo nivel debera hacer referencia al plan siguiente de alto nivel. El proceso de diseo del sistema interacta con otros procesos de
55
proyectos. Cuando algunos de los aspectos de un plan de diseo del sistema estn relacionados con la documentacin de otro proyecto, tales documentos deberan estar incluidos en el plan de pruebas del sistema por referencia. Documentando las decisiones de proyecto de forma consistente y slo en un sitio, la documentacin de proyecto ser ms consistente y fcil de mantener. 6.5.1.1. Finalidad
Describe los objetivos globales del diseo detallado del proyecto. Esta seccin debera tratar criterios de diseo especficos y desafos. 6.5.1.2. Descripcin general
Describe el enfoque general y los resultados del diseo detallado. 6.5.1.3. Definiciones y abreviaturas
Describe cualquier trmino, acrnimo y abreviatura requeridos para entender este documento. 6.5.1.4. Lista de referencias
Proporciona una lista completa de documentos a los que se hace referencia dentro del diseo detallado. Puede incluir: Plan de gestin de proyecto Especificacin de requisitos Diseo del sistema Planes de pruebas Descripcin general de la estructura y contenido del documento
6.5.1.5.
Proporciona una visin general del documento de diseo detallado incluyendo la organizacin del documento.
6.5.2.
6.5.2.1.
Descripcin general
Requisitos del sistema
Describe los requisitos de software y hardware generales del sistema que se va a construir. Esta seccin puede incluir: Referencias o fragmentos de la especificacin de requisitos
56
Descripcin de las relaciones/dependencias del sistema SW con otros productos Visin general de las funciones y componentes del SW, normalmente en la forma de un diagrama de bloques Cualquier HW que sea requerido Lista de restricciones y limitaciones tecnolgicas Perfil del sistema
6.5.2.2.
Describe los escenarios operacionales caractersticos del sistema que se va a construir. Esta seccin puede incluir: Funciones requeridas Referencias o fragmentos de la especificacin de requisitos Visin general de las funciones, funcionalidad Caractersticas del usuario
6.5.2.3.
Describe las caractersticas de todos los grupos de usuarios del sistema. Esta seccin puede incluir: Referencias o fragmentos de la especificacin de requisitos Facilidades y restricciones del usuario Requisitos de formacin del usuario Interfaces e interacciones
6.5.2.4.
Describe las interfaces internas (interfaces entre componentes grandes) y externas (interfaces con sistemas existentes) e interacciones del sistema que se va a construir. Esta seccin puede incluir: Referencias o fragmentos de la especificacin de requisitos Facilidades y su entorno Interacciones con otros sistemas
57
6.5.2.5.
Restricciones generales
Describe las restricciones para el desarrollo y funcionamiento del sistema que se va a construir. Esta seccin puede incluir: Restricciones fundamentales Estndares a seguir Restricciones operacionales Dependencias
6.5.2.6.
Describe las principales dependencias para el diseo, desarrollo y funcionamiento del sistema. Esta seccin puede incluir: Referencias o fragmentos de la especificacin de requisitos Requisitos que no estn claros Dependencias de funciones, funcionalidad que tendr que estar disponible durante el funcionamiento Anlisis de recuperacin del sistema
6.5.2.7.
Describe la recuperacin automatizada y manual que necesita el sistema que se va a construir. El sistema de recuperacin propuesto deber cumplir los requisitos mnimos de disponibilidad del sistema en la especificacin de requisitos. Esta seccin puede incluir: Referencias o fragmentos de la especificacin de requisitos Conversin de las secciones apropiadas de la especificacin de requisitos a un requisito de recuperacin. Exposicin de nuevos requisitos de recuperacin basados en el anlisis funcional.
58
6.5.3.
6.5.3.1.
Especificacin de la arquitectura del software

Modelo del proceso
Describe el modelo de proceso para el sistema que se va a desarrollar. Se pueden introducir en esta seccin diagramas de flujo de proceso de las herramientas de diseo elegidas para este proyecto. Esta seccin puede incluir: Alcance Interfaces Comunicacin Modelo de datos
6.5.3.2.
Describe el modelo de datos del sistema que se va a desarrollar. Se pueden introducir en esta seccin diagramas de datos de proceso de las herramientas de diseo elegidas para esta parte. Esta seccin puede incluir: Estructura de informacin Estructura de datos Gestin de errores
6.5.3.3.
Describe el proceso de manejo de errores del sistema que se va a desarrollar. Se pueden introducir en esta seccin diagramas de flujo de errores de las herramientas de diseo elegidas para esta parte. Esta seccin puede incluir: Especificacin de manejo de errores general Interfaz de usuario Respuesta a abortos de procesos, funciones, etc. debidos a fallos de HW. Configuracin
6.5.3.4.
Describe la especificacin detallada de la configuracin del sistema que se va a entregar.
59
6.5.3.5.
Instalacin
Describe la especificacin detallada del procedimiento de instalacin. 6.5.3.6. Restricciones de diseo
Describe las restricciones de diseo del sistema que se va a desarrollar. Esta seccin puede incluir: Lenguaje de programacin que se va a usar Estndares que hay que cumplir Restricciones operacionales Seguridad de datos Configuracin HW Configuracin SW Restricciones fsicas Restricciones de tiempo y dinero Requisitos cubiertos en esta seccin
6.5.3.7.
Se puede utilizar una tabla como la siguiente para mapear el diseo a los requisitos descritos en la especificacin de requisitos.
Tabla 7. Mapeo del diseo a los requisitos I
Seccin del diseo
Identificadores de requisitos
Comentarios
60
6.5.4.
6.5.4.1.
Especificacin de la interfaz
Interfaz de usuario
Describe la especificacin detallada de la interfaz de usuario. 6.5.4.2. Interfaz de hardware
Describe la especificacin detallada de todas las interfaces de hardware. 6.5.4.3. Interfaces de software
Describe la especificacin detallada de todas las interfaces de software. 6.5.4.4. Interfaces de comunicaciones de datos/red
Describe la especificacin detallada de todas las interfaces de comunicacin de datos/red. Esta seccin puede tratar tambin el diseo de la seguridad de las comunicaciones. 6.5.4.5. Requisitos cubiertos en esta seccin
Tabla 8. Mapeo del diseo a los requisitos II
Seccin del diseo
Comentarios
6.5.5.
Especificacin orientada a la funcin
Esta seccin debera ser incluida como una alternativa a o de forma complementaria a la especificacin orientada a datos o especificacin orientada a objetos. Si no se usa, o si se usa un documento de especificacin funcional separada, esta seccin se debera omitir.
61
6.5.5.1.
Especificacin detallada de la funcionalidad
Describe la especificacin detallada de toda la funcionalidad del sistema. Esta seccin debera usar una representacin consistente con las herramientas de diseo elegidas. Cada elemento funcional debera, por lo menos, especificar entradas, procesamiento, y salidas y las interconexiones lgicas entre elementos funcionales. 6.5.5.2. Adecuacin al modelo de proceso
Describe cmo las funciones diseadas para el sistema que se va a construir satisfarn los requisitos de proceso de la especificacin de requisitos. 6.5.5.3. Datos
Describe los detalles de los modelos de datos y los diagramas de flujo de datos. La notacin y los diagramas usados en esta seccin deberan ser consistentes con las herramientas de diseo elegidas. Se harn referencias a la especificacin orientada a datos cuando sea necesario. 6.5.5.4. Gestin de errores
Describe el modelo funcional para el manejo de errores incluyendo escenarios de errores, anuncio de errores, registro de errores y medidas de recuperacin de errores. 6.5.5.5. Restricciones de diseo
Describe un anlisis adicional de las restricciones del diseo para la identificacin de restricciones en funciones individuales. 6.5.5.6. Recuperacin
Describe las medidas de recuperacin relevante de cada funcin, sacadas de los requisitos de recuperacin. 6.5.5.7. Capacidades de mantenimiento
Describe las medidas asumidas para hacer que el producto sea ms fcil de mantener. 6.5.5.8. Capacidad para pruebas
Describe las medidas asumidas para hacer que el producto sea ms fcil de probar. 6.5.5.9. Instalacin
Describe la especificacin detallada para la instalacin del sistema completo.
62
6.5.5.10.
Requisitos cubiertos en esta seccin
Tabla 9. Mapeo del diseo a los requisitos III
Seccin del diseo
Comentarios
6.5.6.
Especificacin orientada a objetos
Esta seccin debera ser incluida como una alternativa a o de forma complementaria a la especificacin orientada a datos o especificacin orientada a funciones. Si no se usa, o si se usa un documento de especificacin funcional separada, esta seccin se debera omitir. 6.5.6.1. Especificacin de objetos, mtodos y datos
Describe todos los objetos, mtodos y datos. La notacin debera ser consistente con las herramientas de diseo elegidas. 6.5.6.2. Descripcin de clases de objetos
Describe todas las clases de objetos. La notacin debera ser consistente con las herramientas de diseo elegidas. 6.5.6.3. Adecuacin al modelo del proceso
Describe cmo los objetos, mtodos y datos diseados para el sistema que se va a construir satisfarn los requisitos de proceso de la especificacin de requisitos. 6.5.6.4. Gestin de errores
Describe los mtodos especficos que se desarrollarn para el manejo de errores.
63
6.5.6.5.
Restricciones del diseo
Describe un anlisis adicional de las restricciones del diseo para la identificacin de restricciones en objetos individuales. 6.5.6.6. Recuperacin
Describe medidas de recuperacin relevantes a cada objeto, extrados de los requisitos de recuperacin. 6.5.6.7. Capacidad de mantenimiento
Describe la especificacin detallada para la instalacin del sistema completo. 6.5.6.10. Requisitos cubiertos en esta seccin
Tabla 10. Mapeo del diseo a los requisitos IV
Seccin del diseo
Comentarios
6.5.7.
Especificacin orientada a datos
Esta seccin debera ser incluida como una alternativa a o de forma complementaria a la especificacin orientada a objetos o especificacin orientada a funciones. Si no se usa, o si se usa un documento de especificacin funcional separada, esta seccin se debera omitir.
64
6.5.7.1.
Especificacin del modelo conceptual
Describe todas las entidades, relaciones y atributos. La notacin debera ser consistente con las herramientas de diseo elegidas. 6.5.7.2. Relacin con la funcionalidad
Describe la relacin de las entidades de datos y sus atributos con las especificaciones funcionales. Si la especificacin funcional es un documento externo entonces hay que proporcionar los puntos de referencia correspondientes. 6.5.7.3. Adecuacin del modelo del proceso
Describe cmo el modelo de datos y las funciones diseadas para el sistema que se va a construir satisfarn los requisitos de proceso de la especificacin de requisitos. 6.5.7.4. Gestin de errores
Describe las tcnicas especficas que se desarrollarn para el manejo de errores. 6.5.7.5. Restricciones de diseo
Describe un anlisis adicional de las restricciones del diseo para la identificacin de restricciones en el modelo de datos. 6.5.7.6. Recuperacin
Describe medidas de recuperacin especficas, extradas de los requisitos de recuperacin. 6.5.7.7. Capacidad de mantenimiento
Describe la especificacin detallada para la instalacin del sistema completo. 6.5.7.10. Requisitos cubiertos en esta seccin
65
Tabla 11. Mapeo del diseo a los requisitos V
Seccin del diseo
Comentarios
6.5.8.
6.5.8.1.
Caractersticas generales sobre calidad

Fiabilidad
Describe los elementos de fiabilidad del diseo incluyendo operatividad, tiempo medio entre fallo, recuperacin despus de un fallo, etc. 6.5.8.2. Capacidad de utilizacin
Describe los elementos de usabilidad del diseo incluyendo facilidades de ayuda, funciones estndares (p.ej. copiar/pegar, etc.), etc. 6.5.8.3. Portabilidad y capacidad de mantenimiento
Describe los elementos de portabilidad y de capacidad de mantenimiento del diseo incluyendo independencia entre el hardware y el sistema operativo, programacin de la frecuencia y duracin del mantenimiento, modularidad del diseo, etc. 6.5.8.4. Rendimiento
Describe los elementos de rendimiento del diseo incluyendo caractersticas de rendimiento (p.ej. potencia de la CPU). 6.5.8.5. Seguridad
Describe los elementos de seguridad del diseo incluyendo proteccin de datos y control de acceso. 6.5.8.6. Capacidad para pruebas
Describe las estrategias de pruebas que se usarn para asegurar la calidad del diseo. Si estas estrategias se describen con suficiente detalle en la documentacin de pruebas, se debera hacer una referencia apropiada en este apartado.
66
6.5.8.7.
Requisitos cubiertos en esta seccin
Tabla 12. Mapeo del diseo a los requisitos VI
Seccin del diseo
Comentarios
6.5.9.
Incidencias, asuntos y temas abiertos
Describe incidencias y preocupaciones relacionadas con cuestiones y/o interpretaciones de la especificacin de requisitos. Cuando el diseo a alto nivel se ha basado en algunos supuestos, hay que indicar cules son esos supuestos.
Tabla 13. Registro de incidencias
Incidencia
Descripcin (incluida la asignacin a requisitos subyacente)
Resolucin
Estado (Abierto/Cerrado)
67
7.
-
GLOSARIO
Brainstorming: hace referencia a un proceso de pensamiento lateral y es una excelente forma de desarrollar distintas soluciones creativas para un problema. Consiste en centrarse en un problema y presentar todas las soluciones posibles. Se disea para ayudar a romper con unos patrones de pensamiento y encontrar nuevas formas de mirar a ese problema. Intenta abrir posibilidades y desechar suposiciones errneas sobre el lmite del problema y no contempla crticas a las ideas propuestas. Todas las ideas se evalan una vez que la sesin de brainstorming ha finalizado y estas soluciones se pueden explorar o analizar usando enfoques convencionales. COTS (Commercial off-the-shelf): es un adjetivo que describe productos software o hardware listos para usarse y disponibles para la compra por el pblico general. Diseo: describe los componentes de un producto y sus interconexiones. Diseo preliminar: establece las capacidades del producto y la arquitectura del producto o sistema, incluyendo particiones del producto, identificaciones de componentes de producto, estados y modos del sistema, interfaces, Escenarios: secuencia de eventos que pueden ocurrir en el uso del producto, que se utilizan para hacer explcitas las necesidades de las personas involucradas en el negocio. Interfaces: aquellos vnculos, ya sean de sistemas, personas o procesos, que existen entre un sistema o solucin. Outsourcing: se define como la contratacin de servicios profesionales externos para satisfacer necesidades empresariales especficas. Paquete de datos tcnicos: documentacin de diseo completa de un producto o componente de producto y la informacin adicional necesaria para el soporte de su uso efectivo. Patrn de diseo: solucin general reutilizable a un problema en el software. diseo de
Prototipos: son versiones incompletas del producto o componente de producto que se est desarrollando. Pruebas unitarias: pruebas que se encargan de buscar defectos y verificar el funcionamiento de los componentes de producto que se pueden probar de forma separada. Vaporware: trmino peyorativo utilizado para denominar al software o hardware anunciado por un desarrollador mucho antes de realizar el desarrollo, y que despus no llega a emerger, ni a tener un ciclo de desarrollo ms o menos estable.
68
Walkthrough: tcnica de anlisis esttico en la que el diseador o programador dirige a los miembros del equipo de desarrollo u otras partes interesadas a travs del producto, y los participantes plantean cuestiones y realizan comentarios sobre posibles errores, desviaciones de los estndares de desarrollo u otros problemas observados.
69
8.
REFERENCIAS
[1] INTECO, Gua de Mejores Prcticas de Calidad de Producto, Junio 2008 [2] Schmidt M., Implementing the IEEE Software Engineering Standards, Sams 2000. [3] Software Engineering Institute, CMMI for Development, Version 1.2 CMMI- ACQ. V1.2, 2007. [4] Software Engineering Institute, CMMI, Gua para la Integracin de Procesos y la Mejora de Productos, Pearson Education, 2009. Enlaces: [5] BSI (British Standards Institution) group: http://www.bsigroup.com/ [6] IEEE (Institute of Electrical and Electronics Engineers): http://www.ieee.org/portal/site [7] ISO (International Organization for Standardization): http://www.iso.org/iso/home.htm
70

Guia ST

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Guia ST

Загружено:

Авторское право:

Доступные форматы

GUA DE DISEO DE LA SOLUCIN TCNICA

Laboratorio Nacional de Calidad del Software

Gua de Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

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

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

SOLUCIN TCNICA DENTRO DE CMMI

METAS Y PRCTICAS ESPECFICAS

Gua de Diseo de la Solucin Tcnica

REAS DE PROCESO RELACIONADAS

Gua de Diseo de la Solucin Tcnica

DESARROLLO SOLUCIONES ALTERNATIVAS Y CRITERIOS DE SELECCIN

Gua de Diseo de la Solucin Tcnica

Asignacin de requisitos a la solucin

Gua de Diseo de la Solucin Tcnica

Evaluacin del uso de productos COTS

Gua de Diseo de la Solucin Tcnica

Tabla 1. Beneficios y desventajas del uso de productos COTS

Beneficios Integracin de componentes

Desventajas productos COTS con otros

Reduccin del tiempo de desarrollo Reduccin de los riesgos de desarrollo

Gua de Diseo de la Solucin Tcnica

Identificacin de alternativas. Evaluacin de las alternativas contra los criterios.

Gua de Diseo de la Solucin Tcnica

DESARROLLO DEL DISEO

DISEAR EL PRODUCTO O COMPONENTE DE PRODUCTO

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Soluciones que llevan al diseo P R O B L E M A S O L U C I O N E S Tiempo

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

PAQUETE DE DATOS TCNICOS

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

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

lgica, seguridad, datos,

Gua de Diseo de la Solucin Tcnica

REALIZAR LOS ANLISIS SOBRE SI DESARROLLAR, COMPRAR O REUTILIZAR

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

IMPLEMENTACIN DEL DISEO DEL PRODUCTO

Gua de Diseo de la Solucin Tcnica

Estndares de procesos y de calidad.

MTODOS PARA LA IMPLEMENTACIN

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

Gua de Diseo de la Solucin Tcnica

ANEXOS: ARTEFACTOS RELACIONADOS CON LA SOLUCIN TCNICA

PROCESO PARA EL DISEO

Descripcin del proceso

Gua de Diseo de la Solucin Tcnica