PROCESO SOFTWARE

Viernes 14 de NoviembrePROCESO SOFTWARE Profesor: Gerzon Eliud Gmez Cruz

Viernes 14 de NoviembrePROCESO SOFTWARE Profesor: Gerzon Eliud Gmez Cruz

CAB CANCHE ALBA MARIA RODRIGUEZ CARRILLO JOSE RAULBASTO GONZALEZ ANGEL ISMAELPENICHE ROMERO RODRIGOUBALDO INFANTE ENRIQUEMAY HERNANDEZ CHRISTOPHER IVANCASTILLO PINKUS LUIS GERARDO

NDICENDICE1INTRODUCCION3Procesos tecnicos5De que se trata los Requisitos?6Requerimientos cuantificables8Requerimientos de sistema y requerimientos de software.8Modelos de proceso9Elicitacin9Anlisis9Negociacin9Especificacin9Validacin9Actores de procesos10Descubrimiento de requisitos.11Obtencin de requisitos11 Diseo en el contexto del software21Segn el SWEBOK el diseo de software consta de dos definiciones: Es el proceso de definir una arquitectura, componentes, interfaces y otras caractersticas de un sistema o componente y tambin es el resultado de ese proceso. Si nos guiamos por la primera definicin, diseo del software es la parte de todo ciclo de vida de desarrollo software en la cual se analizan y se traducen para crear una descripcin detallada que servir como base para construir el software. Cabe notar que el diseo software es la primera de las 3 actividades tcnicas, siendo la generacin de cdigo y pruebas las otras 2, que se requieren para construir y verificar el software.21El diseo software sirve no slo como base para la posterior codificacin del mismo, si no que tambin permite hacer negociaciones de recursos con el o los clientes, sirve para planear actividades de verificacin y validacin (ya que en el diseo original se debe describir exactamente cmo ha de funcionar el SW), sirve como documentacin para el posterior mantenimiento del software y permite la reutilizacin de componentes y sistemas para la solucin de problemas similares.21El proceso del diseo del software normalmente se ve dividido en 2 partes:21Arquitectura y estructura de Software25Diseo de la Interfaz de Usuario26Anlisis y evaluacin de la calidad en el diseo software29Notaciones del diseo software30Herramientas para el diseo software32Fundamentos35Minimizar la complejidad35La aplicacin de las normas de desarrollo externo o interno durante la construccin ayuda a lograr los objetivos de un proyecto para la seguridad, eficiencia, la calidad y el costo.36Modelos de ciclo de vida36Planificacin en la construccin36codificacin37fundamentos de ingenieria en software44Cundo surge el mantenimiento software?44P: Con que fin se realiza el mantenimiento software?44Caracteristicas para comprender las actividades de mantenimiento:44El objetivo del mantenimiento software es modificar el software existente conservando su integridad44Aspectos clave en el mantenimiento software45Cul es el proceso del mantenimiento software?46Modelo Quick Fix48Modelo Osbornes49Modelo de mejora iterativa49Modelo orientado a la reutilizacin49cUALES SON LAS TECNICAS DEL MANTENIMIENTO SOFTWARE?49Comprensin de programas49Ingeniera inversa50Reingeniera del Software51Migracin del software.- A fin de que migrara un nuevo entorno, el mantenimiento tiene que determinar las acciones necesarias para llevar a cabo la migracin y, a continuacin, desarrollar y documentar los pasos necesarios para efectuar la migracin en un plan de migracin que cubre los requisitos de migracin, herramientas de migracin, conversin del producto y de datos, ejecucin, verificacin y apoyo.51Retiro.- Una vez que el software ha alcanzado el final de su til la vida, debe ser retirado.51Herramientas del mantenimiento de software52Procesos de gestin53La primer parte de la gestin de ingenieria de software54Ahora nos centramos en la planificacion.55Qu es calidad?60En la calidad es importante tener en cuenta los Requisitos No Funcionales(RNF).60REQUISITOS NO FUNCIONALES60PROCESO DE GESTION DE CALIDAD61herramientas de calidad de software62pruebas62REFERENCIAS63

INTRODUCCION

Este docuemto contiene una sintesis de los procesos tecnico y de gestion necesaios para la realizacion de un proyecto software, los cules se nos ayudaran a obtener un mejor producto software con mayor calidad, eficiencia e inclso podria facilitarnos la realizacion de un proyecto software, este documento esta dividido en procesos tecnicos y de gestion para una mayor organizacin y comprencion de losprocesos.

Procesos tecnicos

requisitos software

Desarrollo del ProcesoLos Requisitos de software expresan las necesidades y limitaciones impuestas a un producto de software que contribuyen a la solucin de algunos problemas del mundo real.De que se trata los Requisitos?El rea de conocimiento de los requisitos software tratar acerca del anlisis , especificacin y validacin de los requisitos software, as como su gestin durante todo el ciclo de vida del producto software. Es bastante conocido entre los investigadores y los practicantes en la industria que los proyectos software son crticamente vulnerables cuando las actividades relacionadas con los requisitos son ejecutadas deficientemente.El trmino "ingeniera de requisitos" es ampliamente utilizado en la campo para denotar la manipulacin sistemtica de requisitos. El rea de conocimientos de requisitos de software est estrechamente relacionada con el Diseo de Software, las pruebas de Software, el mantenimiento de Software, gestin de la configuracin Software, ingeniera de procesos Software, modelos y mtodos de software y calidad de software.

Descomposicin de tpicos de requisitos software

Requisitos de producto y procesos.Un requisito producto es una necesidad o restriccin en el software a ser desarrollado. Un requisito proceso es esencialmente una restriccin en el desarrollo del software.Algunos requisitos de software generan requisitos implcitos del proceso. Los requisitos de proceso tambin se pueden imponer directamente por la organizacin de desarrollo, el cliente, o un tercero, como un regulador de la seguridad.

Requerimientos funcionales y no funcionales.

Requisitos funcionales describen las funciones que el software debe ejecutar; a veces se conocen como capacidades o caractersticas. Un requisito funcional tambin se puede describir como un requisito para el cual se puede escribir un conjunto finito de pasos de prueba para validar su comportamiento.

Requisitos no funcionales son aquellos que actan para restringir la solucin. Los requisitos no funcionales son conocidos como restricciones o requisitos de calidad. Se pueden clasificar en requisitos de rendimiento, los requisitos de mantenimiento, requisitos de seguridad, requisitos de fiabilidad, requisitos de seguridad, requisitos de interoperabilidad, etc.

Requerimientos cuantificables

Los requisitos de software deben expresarse claramente y con poco ambigua como sea posible, y debe ser apropiado que sean cuantificables. Es importante evitar los requisitos de vagos y no verificables que su interpretacin depende de un juicio subjetivo, esto es particularmente importante para los requisitos no funcionales.

Requerimientos de sistema y requerimientos de software.

En este tpico la palabra sistema significa: una combinacin de elementos que interactan para lograr un objetivo definido. Estos incluyen hardware, software, firmware, personas, la informacin, las tcnicas, instalaciones, servicios, y otros elementos de apoyo. Los requisitos del sistema son los requisitos para el sistema como un todo. En un sistema que contiene componentes de software, requisitos de software son derivado de los requisitos del sistema.Los requisitos del sistema, por el contrario, abarcan necesidades de los usuarios, requisitos de otras partes interesadas (como las autoridades reguladoras), y los requisitos sin un fuente humana identificable.

Proceso de Requisitos de SoftwareEl proceso de requisitos software est dividido en tres partes importantes que son:

Los modelos de procesos.Los actores del procesos.Calidad y mejora del proceso.

Modelos de procesoCon los modelos de procesos software nos referimos a las actividades de elicitacin (educcin),anlisis, negociacin, especificacin y validacin las cuales se configuran para los diferentes tipos proyectos.ElicitacinEs una actividad fundamentalmente humana, en la que se identifican los interesados (stakeholders) y se establecen relaciones entre el equipo de desarrollo y los clientes.AnlisisEl anlisis de requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo de software. El anlisis de requerimientos permite al ingeniero de sistemas especificar las caractersticas operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.NegociacinDurante esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y lmites del sistema. De forma iterativa los requisitos se priorizan, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes.EspecificacinLa especificacin es el producto de trabajo final que genera la ingeniera de requisitos. Sirve como base para las actividades de ingeniera de software subsecuentes.Describe la funcin y el desempeo de un sistema basado en computadora y las restricciones que regirn su desarrollo.ValidacinLa validacin de requisitos examina la especificacin para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos, y que los producto de trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto.

Actores de procesosEste tema presenta las funciones de las personas que participar en el proceso de requisitos. este proceso es fundamentalmente interdisciplinario, y la especialista requisitos tiene que mediar entre el dominio de la parte interesada y el ingeniero de software. A menudo hay mucha gente involucrado adems del especialista en requisitos, de los cuales tiene una participacin en el programa. los grupos de inters variarn entre proyectos, pero siempre deben incluir usuarios / operadores y clientes .

Los ejemplos tpicos de grupos de inters de software incluir (pero no se limitan a) lo siguiente: Usuarios: Este grupo comprende a los que se operar el software. A menudo es una heterognea grupo de involucrar a las personas con diferentes funciones y requisitos. Clientes: Este grupo comprende a los que han encargado el software o que representen el mercado objetivo del software. Los analistas de mercado: Un producto de mercado masivo no tendr un cliente puesto en marcha, la gente de marketing son a menudo necesarios para establecer cules son las necesidades del mercado y de actuar como clientes de proxy. Reguladores: Muchos dominios de aplicacin, tales como la banca y el transporte pblico, se encuentran regulados. Software en estos mbitos debe cumplir con los requisitos de la reglamentacin autoridades. Los ingenieros de software: Estos individuos tienen un inters legtimo en aprovecharse de desarrollo el por software, por ejemplo, reutilizando componentes o de otros productos.

A los grupos de inters se le conoce como stakeholders.

Calidad y mejora del procesoEste tema se refiere a la evaluacin de la calidad y la mejora del proceso de la ingeniera de software. Su objetivo es hacer hincapi en el papel clave que tiene el proceso de requisitos para la satisfaccin del cliente.

Proceso Aunque cada organizacin cuenta con su propio proceso especfico de obtencin de requisitos, el paso ms importante es el de descubrimiento de requisitos.

Descubrimiento de requisitos.Se interacta con los clientes y usuarios del sistema para recopilar los requerimientos, as como el dominio y la documentacin.

Obtencin de requisitosConsiste en recopilar informacin sobre el sistema propuesto y existentes, as como extraer los requisitos de los usuarios. Estas fuentes de informacin incluyen la documentacin, stakeholders y especificaciones de otros sistemas parecidos. Los ingenieros de software se deben relacionar con los stakeholders para poder extraer de ellos los requisitos que ellos necesitan que tenga el sistema a desarrollar. Para hacer esto, se cuentan con algunas tcnicas para que los usuarios puedan expresar los requerimientos de la aplicacin.Puntos de vistaEste enfoque reconoce varias perspectivas y ayuda a descubrir los conflictos que puedan surgir entre los requisitos propuestos por distintos usuarios.Puntos de vista de los interactuadores.Este punto de vista representa a todas las personas, u otros sistemas externos, que van a interactuar directamente con la aplicacin.Puntos de vista indirectos.Representa a todos los stakeholders que no interactan con el sistema directamente pero que tienen alguna influencia sobre los requisitos del mismo.Puntos de vista del dominio.Son todas las caractersticas y restricciones del dominio que pueden influir en los requisitos que pueda cumplir el sistema.

A veces, definir todos los puntos de vista en tres clasificaciones puede ser difcil, y para facilitar el proceso se pueden definir otros puntos de vista ms especficos que despus pueden ser vistos como partes que en conjunto van a formar las tres categoras anteriores.

EntrevistasLas entrevistas forman parte de la mayora de los procesos de obtencin de requisitos. Durante las entrevistas, ya sean formales o informales, los ingenieros le hacen preguntas a los stakeholders sobre el sistema que usan y el sistema a desarrollar.Entrevistas cerradas donde hay un conjunto definido de preguntas que los stakeholders deben contestar.Entrevistas abiertas donde las preguntas se van generando al examinar distintas cuestiones.

Los principales problemas con los que se puede topar una entrevista es que los stakeholders estn tan inmersos en el dominio que les resulta difcil hablar sobre l sin utilizar terminologa muy especfica, la cual puede ser malinterpretada por los ingenieros. De igual manera, este conocimiento les es tan familiar o lo encuentran tan evidente (por la misma familiaridad) que piensan que algunos detalles son muy obvios como para mencionarlos.Aunque las entrevistas pueden ser la nica manera de sacar cierta informacin para obtener ciertos requisitos, no deben ser usadas como la nica herramienta para hacerlo, ya que en algunos casos no son los mas eficientes, de hecho pueden resultar incluso confusas.EscenariosPara la mayora de los stakeholders es ms fcil dar ejemplos sobre el uso del sistema en la vida real que un ejemplo abstracto, ya que pueden imaginar un caso real en el que se encuentren usando el sistema.Los escenarios son particularmente tiles para agregarle detalle a descripciones vagas de los requisitos. Cada escenario debe abarcar una o ms interacciones posibles que tenga el usuario con el sistema, de esta manera se puede obtener informacin con distintos niveles de detalle sobre el sistema.En trminos generales los escenarios consisten de varias partes que ayudan a los usuarios a definir los requerimientos.Una descripcin de lo que esperan el sistema y los usuarios cuando empieza el escenario.Una descripcin del flujo de eventos en el escenario.Una descripcin de lo que puede salir mal y cmo se debe maneja.Informacin sobre otras actividades que se pueden llevar a cabo al mismo tiempo.Una descripcin del estado del sistema cuando termina el escenario.

Al igual que las entrevistas, los escenarios se pueden llevar a cabo de manera formal o informal al trabajar con los stakeholders. Los escenarios se pueden documentar como texto, diagramas, capturas de pantalla, o cualquier alternativa.

Casos de usoLos casos de uso son una tcnica basada en los escenarios que hoy han pasado a ser una caracterstica fundamental de la notacin UML. En su forma ms simple, los casos de usa muestran el tipo de interaccin y los actores involucrados. Por lo general un caso de uso envuelve varios escenarios que se pueden llevar a cabo.Los casos de uso identifican diversas interacciones que se puede tener con el sistema. Al igual que los escenarios, los casos de uso pueden ser documentados de diversas maneras, aunque las ms comunes son modelos UML y diagramas de secuencia ya que stos pueden aadir informacin adicional a un caso de uso. En ellos se muestra los actores involucrados, los objetos con los que interacta y las operaciones asociadaNegociacin de requisitosOtro trmino comnmente usado para este subtema es la resolucin de conflictos con requisitos donde los conflictos ocurren entre requisitos funcionales y no funcionales.

La negociacin de requisitos tiene por objetivo cumplir con:

Discutir los requisitos conflictivosEstablecer prioridades en los requisitosCompromiso final sobre el conjunto de requisitos Especificacin de Requisitos

El trmino especificacin en el contexto de un sistema basado en computadoras significa distintas cosas. Puede ser un documento escrito, un modelo grfico, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o una combinacin de lo anteriormente mencionado.

Una especificacin de requisitos de software se refiere tpicamente a la produccin de un documento, o a su equivalente electrnico, que debe estar sistemticamente revisado, evaluado, y aprobado. Para los sistemas complejos, particularmente sos que implican componentes hardware, se elaboran tres tipos de documentos: definicin del sistema, requisitos del sistema, y requisitos del software. Para sistemas simples, solamente el tercero de stos es requerido

1. Doc. Definicin del Sistema (Documento de Requerimientos del Usuario):Este documento registra los requerimientos del software. Se definen los requerimientos del sistema en un nivel alto desde la perspectiva del dominio. Los lectores de este incluyen a los usuarios/clientes. Este lista los requerimientos del sistema junto con informacin de trasfondo sobre los objetivos generales para el sistema, el ambiente en el que se desenvolver, restricciones, asunciones y requerimientos no funcionales. 2. Doc. Especificaciones de Requerimientos del Sistema:Es una coleccin estructurada de informacin que incorpora los requerimientos de un sistema. Es de donde se derivan los requerimientos del software. 3. Doc. Especificacin de Requisitos de Software(ERS):Documento en donde se establece las bases de un acuerdo entre los clientes y los contratistas sobre lo que el software debe y no debe de realizar.- Provee una base realista para estimar el costo, riesgos y tiempos de entregadel producto.- Puede ser usado desarrollar planes de verificacin y planeacin efectivos.- Provee las bases para la mejora del software.- Reduce el esfuerzo en el desarrollo del software.- Provee las bases para desarrollar el diseo del software.

Los componentes del SRS son:

Requerimientos Funcionales: Describen las relaciones entre las entradas y las salidas del sistema. Especifica:o El comportamiento esperado del sistema, que salidas se deben obtener con ciertas entradas.o Lo que el sistema debe de realizar en caso de que ciertas situaciones ocurran.o Como debe de comportarse el sistema en situaciones anormales como entradas no vlidas.

Requerimientos del Desempeo: Especifica las restricciones del desempeo en el sistema software. Hay dos tipos:o Estticos: Son los que no ponen restricciones en las caractersticas de ejecucin del sistema. (Ej: n Usuarios simultneos)o Dinmicos: Son los que si ponen restricciones en las caractersticas de ejecucin del sistema. (Ej: Tiempo de respuesta).

Restricciones del Diseo: Estndares que se deben seguir, lmites de los recursos, el ambiente de operacin, la confiabilidad y los requerimientos de seguridad todos ellos tienen un impacto en el diseo del sistema. Interfaz Externa: Son las especificaciones de todas las interacciones que el software tendr con personas, hardware y otros software. Especifica las interfaces de otros software que el sistema usar o que usarn al sistema.

Estructura del ERS:

El estndar ms ampliamente conocido es el IEEE/ANSI 830-1998. Este estndar sugiere la siguiente estructura para los documentos de requerimientos:

1. Introduccina. Propsito del documentob. Alcance del productoc. Definiciones, acrnimos y abreviaturasd. Referenciase. Descripcin del resto del documento2. Descripcin generala. Perspectiva del productob. Funciones del productoc. Caractersticas del usuariod. Restricciones generalese. Suposiciones y dependencias3. Requerimientos especficos: incluyen los requerimientos funcionales, no funcionales y de interfaz.4. Apndice5. ndice

Validacin de Requisitos

La actividad de validacin tiene como entrada el documento de requisitos, los estndares relacionados y el conocimiento de la organizacin, y como salida se obtiene una lista de problemas y una lista de acciones recomendada.

La validacin de los requisitos se lleva a cabo por medio de ciertos mtodos, nos centraremos en los siguientes tres:RevisinPrototipadoPruebas de aceptacin

RevisinEn esta etapa de la validacin se hace nfasis a la revisin de los documentos se asignan un grupo de revisores en un escrito para buscar errores, asunciones confundidas, la carencia de la claridad, y la desviacin de la costumbre, con ello solamente se puede validar la correcta interpretacin de la informacin transmitida. Ms difcil es verificar consistencia de la documentacin o informacin faltante. La composicin del grupo que conduce la revisin es importante (por lo menos un representante del cliente debe ser incluido para un proyecto cliente-conducido, por ejemplo), y puede ayudar a proporcionar la direccin en qu buscar bajo listas de comprobacin.

La revisin de requisitos es uno de los mejores mtodos de validacin de requisitos. Generalmente hablando, las revisiones de requisitos permiten: Descubrir una gran cantidad de defectos en los requisitos. Reducir los costos de desarrollo entre un 25% y un 30%. Reducir el tiempo de pruebas entre un 50% y un 90%.

Las revisiones de requisitos consisten en una o varias reuniones planificadas, donde se intenta confirmar que los requisitos poseen los atributos de calidad deseados.

Las reuniones de revisin se realizan habitualmente siguiendo un procedimiento compuesto por seis pasos:

Preparar el plan de la revisin. Este plan debera incluir al menos lo siguiente: Las tareas a realizar (esto es, las que se indican a continuacin), la planificacin temporal y las personas que participarn en la revisin. Distribuir los documentos a revisar. Habitualmente, el nico documento a revisar ser el documento de especificacin. Junto con este documento, tambin es necesario remitir a los participantes en la revisin todos aquellos documentos que ayuden a comprender adecuadamente el documento de especificacin. Tpicamente, tales documentos son los documentos referenciados y los anexos a la especificacin. Preparar la reunin. Esta tarea es muy distinta, dependiendo de quien la realice:Para el analista promotor de la reunin, esta tarea es fundamentalmente logstica. Bsicamente consiste en reservar una sala donde realizar la revisin, solicitar los materiales que sean necesarios (desde papel y lpiz a caones de proyeccin), preparar justificantes del tiempo empleado por el personal participante, (en caso de que sea preciso), etc.

Para los analistas participantes, la preparacin de la reunin es, probablemente, las ms importante de las tareas de revisin. Durante esta tarea se deben leer cuidadosamente los documentos recibidos y anotar todas aquellos defectos con la finalidad de ponerlos de manifiesto durante la reunin posterior. Realizar la reunin de revisin. Bsicamente, El formato de esta reunin puede ser muy diverso: Puede oscilar desde una total falta de control hasta grupos muy formalizados y sujetos a protocolos de actuacin. Identificar los defectos y acciones a realizar. La lista de defectos y acciones recomendadas es el documento final obtenido en las revisiones de requisitos.Realizar las correcciones que sean precisas a los documentos revisados. El analista promotor de la reunin (esto es, el analista encargado del documento de especificacin) debe evaluar y, si lo estima conveniente, llevar a cabo, las acciones recomendadas que han surgido de la reunin de revisin. Informar de las modificaciones realizadas a los participantes en la reunin. Una vez que los defectos en la especificacin han sido subsanados, debera enviarse un breve informe de las tareas realizadas, y una copia corregida de los documentos de especificacin, a los participantes en la reunin para su visto bueno.

PrototipadoEl mtodo del prototipado consiste en construir una maqueta del futuro sistema software a partir de los requisitos recogidos en la especificacin. Esta maqueta ser evaluada por el cliente y usuarios para comprobar su correccin y completitud.

Por lo general este tipo de mtodo utilizado para la validacin se tiene que especificar al cliente que lo que el esta viendo no es el sistema terminado sino que se trata solamente de un prototipo para que el entienda el esquema de las interfaces de cmo se estn entendiendo los requisitos ya documentados anteriormente.

Los prototipos son un mtodo de validacin ampliamente utilizado en muchas disciplinas, y en todos los casos, los principios subyacentes son los mismos: el prototipado consiste en la creacin de una maqueta o versin del producto final. Los objetivos de los prototipos varan en funcin de la disciplina. En el caso de la actividad de requisitos, los prototipos se utilizan, fundamentalmente, para comprobar la correccin y completitud de la especificacin de requisitos.

Existen varios tipos de prototipos, cada uno de los cuales permite la realizacin de un tipo determinado de pruebas y con un determinado nivel de realismo. En ingeniera de requisitos, los prototipos ms comunes son los siguientes: Mock-ups. Se trata de pantallas, tpicamente dibujadas a mano en papel, que representan un aspecto concreto del sistema. El soporte que proporcionan a la validacin es muy limitado, con la excepcin, quizs, de aclarar el interfaz grfico deseado en casos complejos.Storyboards. Son una evolucin de los mock-ups, ya que adems del interfaz, se muestra la secuencia de acciones, o escenarios, que se deben realizar con el programa. Maquetas. Una maqueta es una versin simplificada del sistema software deseado. Tpicamente, una maqueta representa nicamente el interfaz del sistema y, opcionalmente, las conexiones entre pantallas mediante la utilizacin de elementos activos como los botones. Si fuera necesaria mayor fidelidad, podran codificarse partes del sistema, de tal modo que adems, del interfaz, el software pudiera ofrecer algunos resultados reales. Ello es lo que se conoce como prototipo funcional.

Pruebas de Aceptacin

Uno de los atributos de calidad de los requisitos es que sean verificables. Existen dos razones para ello. La primera, que es normalmente la que enuncia, es que los requisitos deben ser verificables para poder determinar su cumplimiento o ausencia durante las pruebas de sistema y aceptacin.

Existe, sin embargo, una segunda razn: Adems de lo indicado anteriormente, la verificabilidad exige que los requisitos estn muy bien enunciados, sean consistentes y estn razonablemente completos. Por ello, comprobar que los requisitos sean verificables implica indirectamente una cierta confianza en la calidad de los requisitos.

El nico mtodo existente para comprobar la verificabilidad de un requisito es que sea posible definir uno o varios casos de prueba para dicho requisito. Los casos de prueba son artefactos bien definidos en el contexto de la prueba del software. En dicho contexto, un caso de prueba es la descripcin de una accin bien definida que se debe realizar con el software. Por bien accin bien definida, debe entenderse que estn perfectamente descritos tanto los datos de entrada como las tareas a realizar y los resultados esperados. Durante la validacin de requisitos, los casos de prueba se utilizan del mismo modo que durante la prueba del software: es necesario poder describir, como se ha indicado anteriormente, tanto los datos de entrada como las tareas a realizar y los resultados esperados, para lo cual es necesario que estn perfectamente descritos los requisitos.

Por lo peculiar este mtodo se lleva de la mano con los prototipos ya que se verifican lo requisitos redactados con las pantallas de flujo de los prototipos anteriormente mencionados, si los requisitos cumplen en su totalidad con la descripcin del documento, entonces ese requisito es un requisito validado por medio de los casos de uso.

DISEO SOFTWARE

Concepto general de diseoEl diseo se puede definir como una representacin significativa de ingeniera de algo que se va a construir. Belady dice que el diseo tiene dos fases importantes: la diversificacin, la cual consiste en la adquisicin de un repertorio de alternativas para la solucin de un problema, y la convergencia, que sirve para evaluar cada una de las alternativas y elegir o crear una de estas para enfrentar nuestro problema de la manera ms conveniente.Diseo arquitectnic.o Diseo en el contexto del softwareSegn el SWEBOK el diseo de software consta de dos definiciones: Es el proceso de definir una arquitectura, componentes, interfaces y otras caractersticas de un sistema o componente y tambin es el resultado de ese proceso. Si nos guiamos por la primera definicin, diseo del software es la parte de todo ciclo de vida de desarrollo software en la cual se analizan y se traducen para crear una descripcin detallada que servir como base para construir el software. Cabe notar que el diseo software es la primera de las 3 actividades tcnicas, siendo la generacin de cdigo y pruebas las otras 2, que se requieren para construir y verificar el software.El diseo software sirve no slo como base para la posterior codificacin del mismo, si no que tambin permite hacer negociaciones de recursos con el o los clientes, sirve para planear actividades de verificacin y validacin (ya que en el diseo original se debe describir exactamente cmo ha de funcionar el SW), sirve como documentacin para el posterior mantenimiento del software y permite la reutilizacin de componentes y sistemas para la solucin de problemas similares.Proceso del diseo del software.El proceso del diseo del software normalmente se ve dividido en 2 partes:Diseo arquitectnico: Es el proceso inicial del diseo, donde se describe como el software se va a conformar por distintos componentes, as como la comunicacin que tendrn entre ellos. Es tambin llamado diseo de alto nivel ya que no se adentra tanto en los detalles de cada uno de los componentes. Este diseo se puede encontrar en forma de esquemas sencillos de cajas y lineas, donde las cajas representan diversos subsistemas y las lineas representan las interacciones y codependencias. Diseo detallado: Este tipo de diseo expone el comportamiento deseado de cada uno de los componentes y engloba al diseo de datos, el diseo de la interfaz y el diseo de componentes. El diseo de datos consiste en descubrir y definir a profundidad los tipos de datos que sern usados por el software, as como sus caractersticas. El proceso de diseo de datos incluye la identificacin de los mismos, la definicin de tipos de datos y mecanismos de almacenamiento concretos, y la tarea de garantizar la integridad de los datos mediante el uso de reglas de empresa y otros mecanismos de exigencia en tiempo de ejecucin. Tambin se encuentra dentro del diseo detallado el diseo de interfaz, el cual no est solamente limitado al diseo de la interfaz del usuario como normalmente se piensa, si no que consiste en disear y definir todos los protocolos y maneras por las cuales los componentes del software se comunican entre s y con las personas que lo utilizan. Una interfaz implica un flujo de informacin, ya sea de un componente a otro o del sistema hacia afuera, por lo que hay que cuidar que esos datos sean tiles e interpretables por quien los recibe.Por ltimo est el diseo a nivel de componentes que transforma los elementos estructurales de la arquitectura del software en una descripcin procedimental de los componentes del software. Dentro de la definicin de cada componente se tiene que hablar de la lgica del procesamiento que este tiene (es decir los trabajos que hace ese componente expresados normalmente en forma de algoritmos), las estructuras internas de datos necesarios para implementar dicha lgica y una interfaz que permita la invocacin del componente y el paso de los datos.Principios del diseo de software As como la ingeniera del software tiene principios, el diseo del software tambin tiene un conjunto de conceptos y nociones bsicas que se usan para desarrollar y entender los diferentes mtodos de diseo de SW. Existen 7 principios del diseo software:1.- Abstraccin: Es separar por medio de una operacin intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o nocin. Es una manera de enfrentar un problema nos permite trabajar en trminos familiares sin tener que preocuparnos por detalles menores o insignificantes al inicio. 2.- Acoplamiento y cohesin: El acoplamiento es la medida en la que cada componente de un software depende de los otros para realizar su funcin. Como nocin general, un alto grado de acoplamiento es malo mientras que una baja cantidad de este es algo bueno, ya que un mayor grado de independencia entre componentes hace que el flujo de datos sea menor, aumenta la eficiencia de cada componente y hace que los fallos o modificaciones que se hacen en un mdulo o subsistema no afecte a los dems. 3.- Descomposicin y modularizacin: este principio se refiere a la prctica de dividir un software en componentes ms pequeos, con funciones e interfaces bien definidas que les permitan interaccionar con los dems componentes. Esto se hace con la finalidad de repartir las funciones del software en cada uno de estos mdulos, haciendo que el cdigo fuente del software sea ms entendible y logrando que el problema que busca solucionar el sistema sea percibido como una suma de problemas ms pequeos y fciles de entender.4.- Encapsulacin y Ocultacin de informacin: Primeramente la encapsulacin se refiere a agrupar un conjunto de ideas relacionadas entre s hasta formar una unidad (o cpsula), a la cual nos podemos referir con un mismo nombre. Un buen ejemplo de la encapsulacin es la creacin y empleo de funciones en los lenguajes de programacin, por medio de estas los desarrolladores no tienen que preocuparse por cada uno de los procesos que se llevan a cabo para realizar el trabajo de una funcin, slo ven a una unidad funcional la cual tiene una interfaz y arroja un resultado basado en ciertos datos de entrada. 5.- Separacin de la interfaz y la implementacin: este principio es similar al de la ocultacin de la informacin y consiste en hacer una interfaz pblica, la cual no cambia, es conocida por los clientes y es independiente de la implementacin y la estructura de un componente. Esto hace que los usuarios de ese mdulo o software no se tengan que ver abrumados por los detalles de como funciona el software, pero puedan usarlo sin tener que conocerlo a fondo. 6.- Suficiencia, completez y primitivismo: Los primeros dos conceptos estn ntimamente relacionados; suficiencia se refiere a si el diseo captura los detalles necesarios para ser representativo de la solucin y ser til a la hora de ser traducido en cdigo, mientras que la completez se puede definir como la presencia de todas las partes que son absolutamente necesarias para el funcionamiento de un software.

7.- Separacin de preocupaciones: Este ltimo principio propone que cada elemento de un sistema debe de tener un conjunto de responsabilidades que le conciernen slo a el y no es ayudado por los dems componentes en sus responsabilidades, de tal manera que cada componente slo se preocupa de sus propias tareas. Este principio ayuda a simplificar el problema dado al dividirlo en una lista de responsabilidades que se distribuyen por el sistema. Problemas y aspectos clave en el diseo de softwareHay una serie de aspectos que se tienen que considerar cuando se disea cualquier tipo de software. Algunos de estos estn orientados hacia el problema de la calidad del software, otros estn enfocados a la descomposicin organizacin y combinacin de componentes software y tambin estn los aspectos y problemas que no se encuentran directamente relacionados con la composicin y aplicacin del software, pero an afectan la manera en la que este opera ya que son parte del sistema en el que este se ejecuta.1.- ConcurrenciaLa concurrencia es la tendencia que tienen 2 o ms acciones o procesos de suceder al mismo tiempo en un sistema. Debido a que en muchos casos el software es manipulado por sucesos o impulsos externos los cuales pueden suceder en cualquier momento, un sistema no puede darse el lujo de trabajar con un solo proceso a la vez e ignorar todo lo dems. Para que un sistema software pueda manejar la concurrencia de manera adecuada debe de poder coordinar todos sus procesos y su orden, de manera que la ejecucin de uno no afecte a los dems y se pueda responder a cada uno de estos procesos en el menor tiempo posible. 2.-Control y manejo de eventosUn evento o interrupcin es un mecanismo que permite parar la ejecucin de un programa, ejecutar un bloque de instrucciones y luego reanudar la ejecucin del programa principal. Utilizando este mecanismo un sistema software puede parar su ejecucin para atender una necesidad o circunstancia urgente de la computadora y luego continuar con su ejecucin normal. Este aspecto del diseo software puede afectar la manera en la que se da el flujo y organizacin de datos, dependiendo de que tan bien declaradas estn las formas de tratar a los eventos el software puede ser ms o menos fiable o eficiente. El SWEBOK menciona dos mtodos para el manejo de eventos:Invocacin implcita: La idea en este mtodo es que en vez se invocar un proceso de manera directa, un componente puede anunciar a todo el sistema que han sucedido uno o ms eventos. Los otros componentes en el sistema pueden registrar un inters en este evento si tienen asociado un proceso con la ocurrencia del evento. De esta manera cuando un evento se anuncia a todo un sistema se invoca la ejecucin implcita de todos los procesos registrados para ese evento.Callbacks: En este mtodo lo que se hace es que a lo largo del programa se ponen un conjunto de llamadas a funciones las cuales se ejecutan slo si se da el evento que las ejecute. Se puede ver como el mtodo contrario de la invocacin implcita, ya que cuando se declara una funcin callback en programa se tiene que poner explcitamente mdulos se van a usar para ese evento.3.-Persistencia de datosSe dice que un conjunto de datos es persistente cuando se mantienen guardados y utilizables despus de que un programa ha terminado su ejecucin. Es deseable que ciertos datos puedan ser consultados por un programa o por el usuario cuando una instancia del programa ha terminado, por lo que hay que discernir entre los datos que se desean guardar y los que no, con la finalidad de hacer un uso lo ms eficiente de los dispositivos de almacenamiento disponibles. Es conveniente incorporar una estructura de seguridad que guarde de manera peridica informacin sobre el estado, variables y resultados del programa4.-Distribucin de componentesEste aspecto del diseo software presenta el problema de cmo distribuir los componentes de un sistema software a travs del hardware disponible. Si se disea un software sencillo el cual se va a correr en una sola computadora, entonces la distribucin es un problema ms fcil de solucionar, ya que slo hay que conectar las necesidades de los mdulos con sus requerimientos en cuanto a hardware de computadora. Decidir que tipo de componentes debern de ser manejados por los servidores y que componentes deben quedarse en los diversos equipos de los clientes presenta un desafo para el diseo de software, sobre todo si ya existe una infraestructura previa a la que nuestro software debe de adaptarse. Poner demasiados componentes y responsabilidad en los clientes complica la implementacin de estos y las interfaces que usan para comunicarse entre ellos. El problema de la distribucin puede resolverse si se da la abstraccin apropiada de los componentes a un punto en el cual sus necesidades puedan definir por si solas el lugar en el que necesita estar dicho componente. 5.-Manejo de errores, excepciones y tolerancia de fallasUna excepcin es un tipo de evento el cual sucede durante la ejecucin de un programa y hace que el flujo normal este se pare completamente o cambie el orden en el que se siguen las instrucciones. Una excepcin se crea normalmente a base de un error, por lo que la excepcin normalmente recolecta informacin sobre el error y lo que estaba haciendo el programa cuando este ocurri. A base de esta informacin el programa busca un bloque de cdigo el cual le diga qu tipo de mtodo se debe usar para manejar la excepcin. Si el programa encuentra la manera de manejar esa excepcin el sistema puede seguir operando, si no encuentra una solucin el programa finaliza su ejecucin. El problema que se plantea aqu es similar al del control y manejo de eventos; Cmo puedo preparar a mi software para afrontar todos los posibles errores que pueden ocurrir durante su ejecucin?. Aunque parezca imposible hay ciertas excepciones que se pueden anticipar, como la lectura de un archivo corrupto, la falta de un periferal, el uso de un componente hardware daado, etc. Estos potenciales errores se pueden detectar con slo preguntarnos Cual sera un caso extraordinario o poco comn bajo el cual mi programa podra fallar?, tomando en cuenta que un error slo ocurre cuando una funcin no puede ejecutarse de manera plena y por lo tanto no puede devolver datos vlidos al resto del programa.6.-Interaccin y presentacinEste concepto se centra principalmente el problema de cmo estructurar y organizar las interacciones con los usuarios y como presentarles la informacin generada por el software. Este problema es causado en parte por el alto conocimiento que tienen los ingenieros en software de su propio programa y de cmo funciona, por lo que puede interactuar de maneras menos intuitivas con el mismo y obtener resultados. Para alivianar este problema se cre el MVC (Modelo-Vista-Controlador) el cual es una forma de modularizar las partes de un software con la finalidad de que los componentes que se agrupan bajo la vista slo les importe manejar la manera en la que se muestra la informacin, el controlador slo le interese los cambios en las entradas de informacin y el modelo se encargue de responder a las necesidades de las otras dos partes, las cuales pueden requerir informacin del estado del software (que normalmente viene de la vista) o requerir cambios en el estado del software (que normalmente vienen del controlador). 7.-SeguridadEste ltimo aspecto del diseo software se refiere a la prevencin de la creacin, copia, modificacin o negacin de acceso a la informacin generada o utilizada por el sistema software sin autorizacin. Tambin se incluye en este aspecto la tolerancia que nuestro sistema tiene contra ataques maliciosos, buscando mecanismos que aminoren el dao que se puede hacer, mantengan el servicio y propicien una recuperacin rpida y segura del software.El SWEBOK menciona dos mecanismos que se usan para el manejo de la seguridad de un sistema. Primero est el control de acceso, el cual como su nombre lo indica se usa para determinar quin puede acceder los recursos del sistema y que tanto puede hacer con ellos. Un ejemplo bsico de esto es la diferenciacin que hace Windows entre usuarios regulares y administradores, sin embargo el control de acceso no slo se aplica a usuarios, sino tambin a aplicaciones. Si tenemos un sistema que tiene varios programas corriendo en el, podemos (y debemos) disear una jerarqua de acceso, donde se especifica los tipos de recursos a los que pueden acceder cada uno.El segundo mecanismo mencionado en el SWEBOK es el uso de la criptologia, que es la prctica y el estudio de tcnicas de cifrado y descifrado de informacin, es decir, de tcnicas para codificar un mensaje hacindolo ininteligible (cifrado) y recuperar el mensaje original a partir de esa versin ininteligible (descifrado). La criptologa se usa principalmente para proteger informacin sensible en un sistema, como contraseas, reportes de resultados, medios de comunicacin, etc. Arquitectura y estructura de SoftwareE La arquitectura de software es un conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construccin de un software, permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma lnea de trabajo y cubrir todos los objetivos y restricciones de la aplicacin. Es considerada el nivel ms alto en el diseo de la arquitectura de un sistema puesto que establecen la estructura, funcionamiento e interaccin entre las partes del software. Una arquitectura de software consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construccin del software para un programa.Estructuras y puntos de vistaLa estructura de software puede ser descrita y documentadas en distintas facetas. Cada faceta podemos observarla para identificar las propiedades de esta. Cada observacin que se haga puede tener diferentes influencias para el software como que veamos de:Forma lgica.- es satisfacer la funcionalidades de requerimientos.Proceso.- problemas de concurrencia.Fsico.- la distribucin del software.Desarrollo.- como el diseo puede implementarse.Estilo arquitectnicoLos estilos arquitectnicos son las especificaciones estructuradas del software en el que se est trabajando, es la descripcin detallada del software, estos estilos se utilizan para tener un mayor control en el software. Hay diferentes estructuras las cuales pueden ser:La estructura general.- como su nombre lo dice se trata de un diseo general y organizado del software.Sistema de distribucin.- Se basa en la existencia de dos tipos de aplicaciones ejecutndose de forma independienteSistema de interaccin.- es en donde se puede interactuar con el software.Sistema adaptable.- donde se puede adaptar a la situacin.Entre otros.Diseo de patronesLos diseos de patrones son muy parecidos a los de estilo arquitectnico, solo que estos son ms flexibles y los usan para problemas pequeos, ya que no exigen una descripcin detallada. Los diseos de patrones pueden incluir:Creacin de patrones.- podemos decir el esqueleto del software.Estructura de patrones.- en que estructura se utilizara el software.Ambiente de patrones.- en qu ambiente se trabajara el software.Familias de programas y estructurasEste es un enfoque ms all en la reutilizacin de software. Para que la reutilizacin de programas se a ms factible se recomienda que estos programas se creen en grupos o familias, es decir, que tengan un atributos parecidos entre s como una familia de verdad en donde los hermanos pueden llegar a ser compatibles entre s, en software a eso se trata de llegar en que debes organizarlos en familias. En software la relacin importante y donde se puede sacar ms la reutilizacin es en la estructura o el esqueleto de software, ya que con esa base se puede mejorar de distintas maneras.Diseo de la Interfaz de UsuarioEl diseo de interfaz se puede ver como los planos de construccin de una casa, esta no se encuentra completo sin la representacin de puertas, ventanas, conexiones de agua, electricidad y telefono, entre otros. Es el area de diseo que crea un medio de comunicacin entre el hombre y la mquina. Para que el software alcanze su potencial completo, la interfaz de usuario deber estar diseada para compararse con las habilidades, experiencias y expectativas de su anticipado usuario. El diseo de la interfaz se centra en tres reas de inters:1.- El diseo de la interfaz entre los componentes del software2.- El diseo de las interfaces entre el software y los otros productores y consumidores de informacin no humanos3.- El diseo de la interfaz entre el usuario y la computadora.La importancia de la interfaz de usuario gira en torno a como el usuario percibe el software y en cmo este le facilita la tarea, lo evita a cometer errores, etc.Principios generales del diseo de Interfaz de UsuarioAs como la diseo de software tiene sus propios principios, por su parte, el diseo de interfaz de usuario tambien tiene un conjunto de principios que se usan para comprender y desarrollar diferentes mtodos de interfaz de usuario. Estos son los siete principios:1.- Comprehensin: Se define al rpido entendimiento por parte del usuario para que este pueda empezar a trabajar lo antes posible. Esta caracterstica habla de uno de los atributos de usabilidad, estos son una serie de atributos que se soportan en el esfuerzo necesario para su uso. 2.- Familiaridad del usuario: Este principio habla de que la interfaz debe usar conceptos y trminos recogida por las experiencias de las personas que usarn el software, esto en otras palabras quiere decir que el usuario no se debe de sentir sorprendido o confundido por trminos palabras que no conoce, esto se encuentra muy ligado al primer principio, donde el usuario deber de ser capaz de empezar a trabajar con el software lo antes posible y para ello requiere que la interfaz no sea le ajena.3.- Consistencia: Como su nombre lo dice, las actividades comparables dentro de la interfaz debern ser efectuadas de una forma idntica, esto para evitar que el usuario sufra confusin de cmo funcionan los elementos dentro de la interfaz, ya sea desde formas diferentes en las cuales se despliegan los submenes a hipervnculos con el mismo nombre que redirigen a diferentes locaciones.4.- Sorpresa Mnima: Todos estos principios se encuentran entrelazados de cierta manera, este principio se refiere a que el comportamiento del software no deber sorprender al usuario, es decir, deber presentar una consistencia entre elementos homlogos, claro, cuando una funcin nueva se presenta al usuario esta no deber serle de difcil comprensin al usuario, es decir, se sentir familiarizado con la funcin lo ms rpido posible.5.- Recuperabilidad: Este principio se refiere a la funcin de la interfaz que deber presentarle al usuario para que este sea capaz de recuperarse de los errores. Es decir regresar al sistema a un estado previo antes de que ocurriera la accin, dicho esto, es conveniente tener varios niveles de recuperabilidad, ya que los usuarios en la mayora de las ocasiones no sern capaces de reconocer los errores de manera inmediata. Otra forma en la cual se puede presentar este principio es que los usuarios confirmen la eliminacin de la informacin antes de que se destruya. 6.- Guia al usuario: La interfaz deber proveer al usuario con una realimentacin apropiada cuando ocurran errores, tambin se deber proveer con ayuda relacionada y contextualizada para ayudar al usuario, esto viene siendo parte de la familiarizacin del usuario con la interfaz y sus funciones lo que provee al usuario con ayudas para evitar la repeticin de dichos errores.7.- Diversidad de usuarios: Esto habla ms que nada de como la interfaz deber proveer al usuario facilidades de interaccin para la diversidad de usuarios y para usuarios con diferentes cpacidades que se pudiesen presentar. Por ejemplo, si se tiene un sistema de colores para transimitir informacin, se debe tomar en cuenta que cerca de un 10% de los hombres adultos sufren de daltonismo, entonces la interfaz deber contar con la opcin de una modalidad para daltnicos, ya sea cambiando elsistema de colores por escalas de grices o etiquetas de texto que ayuden al usuario.El diseo de las modalidades de interaccin del usuarioLa interaccin involucra emitir comandos y proveer data asociada al software. Los estilos de interaccin de usuario pueden ser clasificados en los siguientes estilos primarios:1.-Pregunta-Respuesta: Esta interaccin esta esencialmente restringida a un simple intercambio de pregunta-respuesta entre el usuario y el software. El usuario provee una pregunta al software, y el software regresa la respuesta a la pregunta en cuestin.2.-Manipulacin directa: El usuario interacta con objetos en la pantalla de la computadora. La manipulacin directa muchas veces incluye un dispositivo tipo puntero, como un ratn, una track-ball o dedos en una pantalla tctil, esto manipula un objeto e invoca una accin que especifica que es lo que se tiene que hacer con ese objeto.3.-Seleccin de menes: El usuario selecciona un comando de un men de listas de comandos.4.-Forma de llenado: El usuario llena en los campos de una forma. En ocasiones estos campos incluyen menes, en cuyo caso la forma tiene botones de accin para que el usuario inicialize una accin.5.-Comandos por lenguaje: El usuario emite un comando y proven parametros relacionados para dirigir al software a lo que debe de hacer.6.-Lenguaje natural: El usuario emite comandos en lenguaje natural. Esto es, que el lenguaje natural es el frente a un lenguaje de comandos que es analizado y traducido a comandos del software.El Diseo de la presentacin de la informacinLa informacin presentada, por naturaleza, puede ser del tipo textual o grfica. Un buen diseo mantiene la presentacin de la informacin separada de la informacin misma. El acercamiento de tipo MVC (Modelo-Visin-Controlador por sus siglas en ingls) es una forma efectiva de mantener la presentacin de la informacin separada de la informacin misma.Los ingenieros en software tambin deben considerar el tiempo de respuesta del software y la realimentacin en el diseo de la presentacin de la informacin. El tiempo de respuesta es usualmente medido desde el punto en el cual el usuario ejecuta cierta accin de control hasta que el software atienda con la respuesta. De acuerdo con el estilo de la presentacin de la informacin, los diseadores tambin pueden usar colores para resaltar de la interfaz. Existen cantidades de importantes guas a considerar:Limitar el nmero de colores a usarUsar cambios de color para mostrar el cambio de estatus del softwareUsar cdigos de color para apoyar las tareas de usuarioUsar cdigos de color de manera concienzuda y consistente Usar colores que facilite el uso a personas daltnicas No depender nicamente del color para transmitir informacin a los usuarios con capacidades diferentes

Proceso del diseo de interfaz de usuarioEl diseo de interfaces de usuario es un proceso iterativo; prototipos de interfaz se usan con frecuencia para determinar caractersticas, organizacin y la visualizacin de la interfaz de usuario del software. Este proceso incluye tres actividades ncleo:1.- Anlisis del usuario: En esta fase el diseador analiza las tareas del usuario, el ambiente de trabajo, otros softwares que utiliza el usuario y como los usuarios interactan con otras personas.2.- Prototipificacin del software: Desarrollar prototipos del software ayuda a los usuarios a guiar la evolucin de la interfaz.3.- Evaluacin de la interfaz: Los diseadores pueden observar las experiencias de los usuarios con la evolucin de la interfaz. Localizacin e internacionalizacin El diseo de la interfaz de usuario muchas veces debe considerar la internacionalizacin y la localizacin, que son medios de adaptacin del software a los diferentes lenguajes, diferencias regionales y los requerimientos tcnicos de un pblico especfico. Localizacin e internacionalizacin deben considerar factores tales como smbolos, nmeros, moneda, tiempo y unidades de medida.Metforas y modelos conceptualesLos diseadores de la interfaz de usuario pueden usar metforas y modelos conceptuales para preparar un diagrama entre el software y algunos sistemas de referencia conocidos por los usuarios en la vida real, los cuales, pueden ayudar a los usuarios a aprender de forma ms fcil al uso de las interfaces. Por ejemplo, la operacin Borrar Archivo puede ser transformada en una metfora usando el icono de un bote de basura.Anlisis y evaluacin de la calidad en el diseo softwarePara asegurar que la calidad del diseo cumple los requisitos dados deber primero ser analizado: una serie de revisiones de diseo por parte de los desarrolladores para determinar la calidad del producto. Existen diversos mtodos formales e informales para encontrar los puntos donde necesiten mejora, desde la prueba de interfaz de un usuario hasta una investigacin estadstica avanzada.Seguidamente ser evaluado con el propsito de cumplir los requisitos dados para ser de calidad. La importancia en este punto para el proyecto es crtica: si existe un error en el diseo este se ver directamente reflejado en el cdigo o producto final, el consumo de recursos por errores futuros. El propsito de este paso es detectar errores. Para complementar la idea de evaluacin se deben de tener en cuenta dos trminos que abarca: verificacin y evaluacin. De acuerdo al IEEE sus definiciones son las siguientes:Verificacin: Proceso de determinar si los productos de una determinada fase del desarrollo de software cumplen o no los requisitos establecidos durante la fase anterior.Validacin: Proceso de evaluacin del software al final del proceso de desarrollo para asegurar el cumplimiento de las necesidades del cliente.

Una de las tcnicas para evaluar un diseo es a travs del anlisis esttico el cual no es ms que analizar el cdigo o diseo de manera no activa. Dentro de esta metodologa existen tipos de clasificaciones:Automtico: El anlisis es realizado mediante software lo que reduce la complejidad de detectar errores.Manual: Anlisis realizado por personal humano para detectar problemas concretos.Para anlisis formales se emplean modelos matemticos para determinar si el diseo tendr xito o no, entre otros.Mtrica.Empezando por su definicin, podemos decir que es el mtodo de medicin para medir la calidad del software. Podemos definir mtrica como: La aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo de Software y sus productos, para producir una informacin de gestin significativa y a tiempo.As mismo, se pueden dividir en dos subcategoras:Mtricas basadas en la funcin:Mtrica en la cual se pueden obtener medidas en base a previos resultados del anlisis. Su primer paso es evaluar los siguientes pasos con base al diagrama de flujo de datos previo:Nmero de entradas de usuarioNmero de salidas de usuarioNmero de consultas del usuarioNmero de archivosNmero de interfaces externas

Una vez obtenido los datos, se puede determinar las lneas de cdigo que se necesitarn desarrollar para cada funcin.Mtricas Orientados a Objetos:Se centran en mtricas que se pueden aplicar a las caractersticas de encapsulamiento, ocultamiento de informacin, herencia y tcnicas de abstraccin de objetos que hagan nica a esa clase. Su propsito es comprender mejor la calidad del producto, estimar la efectividad del proceso y mejorar la calidad del trabajo realizado a nivel del proyecto. Notaciones del diseo softwareExisten muchas notaciones para representar artefactos de diseo de software. Algunos representan la estructura de organizacin, otros el comportamiento. El diseo de software se logra usando mltiples notaciones. Aqu se han categorizado a notaciones para describir el enfoque estructural (esttico) y el de proceso (dinmico).Descripcin estructural (enfoque esttico)Lenguajes de descripcin de arquitecturas: Lenguaje de computadora. Textuales y frecuentemente formales, sirven para describir la arquitectura de software en trminos de componentes y conectores.Diagramas de objetos y clases: Usados para representar un conjunto de clases (y objetos) y sus interrelaciones. Muestra los atributos de un sistema en un tiempo determinado.Diagramas de componentes: Usados para representar un conjunto de componentes (partes fsicas y reemplazables que proveen la realizacin de interfaces) y sus interrelaciones. Tarjeta de clase-colaboracin-responsabilidad: Una herramienta para la lluvia de ideas. Consiste en una tarjeta donde se indique en la parte de arriba la clase, en medio las responsabilidades que esa clase tiene, y en el lado las clases con las que colabora.}Diagrama de despliegue: Representan el despliegue fsico de artefactos en los nodos. Por ejemplo, para describir un sitio web, el diagrama mostrara los componentes de hardware que habran (nodos), como el servidor web, servidor de base de datos, servidor de aplicacin; muestra tambin los componentes de software (artefactos) que se ejecutaran en cada nodo (la aplicacin web, base de datos, etc), y cmo se conecta cada pieza.Diagramas (modelos) de entidad-relacin: Modelo de datos que representa las entidades relevantes de un sistema de informacin y sus interrelaciones y propiedades o atributos. Las entidades se conectan cada una mediante las relaciones que tienen entre ellas.Lenguaje de descripcin de interface: Lenguaje de especificacin que sirve para describir la interface de un componente software en un lenguaje neutral, lo cual permite la comunicacin entre componentes de software desarrollados en diferentes lenguajes. Por ejemplo, entre componentes escritos en C++ y componentes escritos en Java.Diagramas de estructura: Diagrama que muestra el desglose de un sistema hasta los niveles manejables ms bajos. Se usan en la programacin de estructuras para ordenar los mdulos del programa en un rbol.

Descripcin de procesos (enfoque dinmico)Estas notaciones y lenguajes se usan para describir el proceso dinmico de sistemas de software y de componentes. Diagramas de actividad: Se usan para mostrar el control de flujo en actividad tras actividad. Puede representar actividades concurrentes. Diagramas de comunicacin: Usado para representar las interacciones que se presentan entre grupos de objetos. Puede ayudar a mostrar qu elementos se relacionan mejor entre ellos. Hace nfasis entre los mismos objetos, sus conexiones y los mensajes que transmiten en esas conexiones.Diagramas de flujo de datos: Es la representacin grfica del flujo de datos a travs de un sistema de informacin. Es usado para el anlisis de seguridad, ya que permiten identificar posibles vas de ataques y vulnerabilidad en el manejo de los datos confidenciales. Es la visualizacin del procesamiento de los datos. Tablas y diagramas de decisin: Las tablas de decisin son un modo preciso pero compacto de modelar lgica complicada. Asocian condiciones con las acciones a realizar, pero de una manera ms elegante que un diagrama de flujo. Los diagramas de decisin, conocidos mejor como diagramas de influencia, es la representacin matemtica, grfica y compacta de una situacin de decisin. Reemplazan a los rboles de decisin dado que estos ltimos solan extenderse demasiado. Tienen la misma funcin de las tablas de decisin, pero representadas de forma distinta (y ms complejo).Diagramas de flujo: Representan un algoritmo, flujo de trabajo o proceso, mostrando los pasos en cajas, y el orden que siguen (mediante flechas). Ilustran y representan los pasos a seguir para la solucin de un problema designado. Diagramas de secuencia: Diagrama de interaccin que muestra cmo los procesos operan uno con otro y en qu orden. Muestra las interacciones de objetos con cierto orden de tiempo.Diagramas de transicin de estado: Describe el comportamiento de un sistema, los cambios de estado por los que pasa, y las acciones que le hacen cambiar. Muestran el control de flujo en la transicin de cada estado.Lenguajes formales de especificacin: Lenguajes textuales con nociones bsicas de las matemticas para definir rigurosa y abstractamente las interfaces de los componentes de software y su comportamiento/proceso. Se les dice formales porque tienen una sintaxis y semntica. Pseudocdigo y lenguajes de diseo de programas: Es una descripcin de alto nivel compacta e informal del principio operativo de un programa informtico o algoritmo. Utiliza las convenciones estructurales de un lenguaje de programacin real, pero ha sido diseado de modo que pueda ser ms comprensible para la lectura humana.

Estrategias del diseo de software El mtodo de diseo de Software es definido como la aproximacin sistemtica para llevar a cabo un diseo y describe una secuencia de pasos para producir diseo de software. Hay muchas maneras de disear software, pero el ingeniero debe saber cul utilizar. Segn el Swebook, existen varios mtodos y estrategias para ayudar al diseo de software.Criterios para evaluar un diseoExactitud: El diseo de software es correcto si es construido de acuerdo a los requerimientos del sistemaEficiencia: El diseo usa con eficiencia los escasos recursosSustentabilidad y simplicidad: Que tan simple es el diseo de entenderCosto: El sistema ayuda a reducir costos en fases posteriores del desarrollo de software

Estrategias generales:Existen varias estrategias, que, aunque no son tan especficas como los mtodos, se pueden aplicar a ms problemas.Arriba-abajo: consiste en ir descendiendo en las soluciones abstractas hasta llegar a una ms concreta, sin volver a subir. Abajo-arriba: Es la aproximacin que consiste en juntar varios sistemas para dar pie a soluciones ms complejas.Patrn de diseo: Segn Christopher Alexander, se refiere a un problema que ocurre varias veces en el entorno de desarrollo, describiendo su solucin de tal manera que se pueda solucionar un milln de veces, sin hacerlo del mismo modo dos vecesDividir y conquistar: idealmente, el sistema puede partirse en piezas ms pequeas, que pueden ser resueltas o modificadas por separado.

Diseo orientado a funciones: Es uno de los mtodos clsicos de diseo de software, donde la descomposicin se centra en identificar las funciones importantes del software, para luego elaborarlas y pulirlas en una jerarqua de arriba-abajo. Es soportado directamente por la mayora de los lenguajes de programacin.Es generalmente usado despus del anlisis estructurado, produciendo (entre otras cosas) diagramas de flujo de datos. Se han propuesto varias estrategias para transformar el DFD en arquitectura de software normalmente representada en un una grfica de estructura.Diseo orientado a objetos: Usa objetos que son cajas negras para enviar y recibir mensajes. Estos objetos contienen cdigo, adems de datos. Los objetos son definidos por las clases, que son la manera de agrupar objetos basado en las caractersticas y operaciones del objeto. Los componentes principales son la encapsulacin, la herencia, polimorfismo y la tranferencia de mensajes.Encapsulacin: Es el proceso de esconder los detalles del objeto que no contribuyen a las caractersticas esenciales Herencia: Es la forma de generar nuevas clases a partir de las ya existentes, a veces llamadas clases derivadasPolimorfismo: Es la habilidad de asignar mltiples significados a algo en diferentes contextos.Transferencia de mensajes: Permite a los objetos comunicarse el uno con el otro.

La mayor ventaja del diseo orientado a objetos es que es reutilizable.

Diseo centrado a estructura de datos: Empieza desde la estructura de datos que manipula un programa en vez de la funcin que realiza. Aunque hay varios tipos de mtodos de diseo, teniendo cada uno su propio acercamiento y notacin, todos tienen propiedades en comn. Primero, ayudan en identificar informacin, objetos y operaciones clave. Luego, asume que la estructura de la informacin es jerrquica. Adems, proporciona una serie de pasos para catalogar una estructura de datos jerrquicos al programa.

Diseo basado en componentes: Una unidad de software es una unidad independiente, teniendo interfaces bien definidas y dependencias que pueden ser compuestas y desplegadas independientemente. Este mtodo se centra en los problemas relacionado con proporcionar, desarrollar e integrar dichos componentes para as incrementar su reso. Software reusado debe cumplir con los mismos requerimientos de seguridad que el software completamente nuevo.Herramientas para el diseo softwareLas Herramientas de Ayuda al Desarrollo de Software, surgieron para intentar dar solucin a los problemas inherentes a los proyectos de aplicaciones informticas como: plazos y presupuestos incumplidos, insatisfaccin del usuario, escasa productividad y baja calidad de los desarrollos.

Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE (Computer Aided Software Engineering-Ingeniera de Software Asistida por Ordenador) y otras dirigidas a mejorar la productividad durante la fase de construccin: lenguajes de cuarta generacin.

Estas aplicaciones informticas tienen como propsito principal aumentar la productividad en el desarrollo de software, reduciendo el costo de las mismas en trminos de tiempo y de dinero. Adems son de mucha utilidad en todos los aspectos del ciclo de vida de desarrollo del software, en tareas como: el proceso de realizar un diseo del proyecto, clculo de costos, compilacin automtica, documentacin o deteccin de errores, entre muchas actividades ms.

Herramientas de Apoyo al Proceso de Diseo de SoftwareLas herramientas CASE nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software, en tareas como el proceso de realizar un diseo del proyecto, clculo de costos, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras.

Las herramientas del CASE seran una familia de mtodos favorablemente estructurados para planeamiento, anlisis y diseo. Esto llevara a la generacin automtica de cdigo para desarrollo de software mediante una especificacin formalmente diseada. Esto traera como beneficio:Una mejora en la calidad, fiabilidad, utilidad y rendimiento.El entorno de produccin de documentacin para software mejora la comunicacin, mantenimiento y actualizacin.Hace el trabajo de diseo de software ms fcil y agradable.La promesa futura de reemplazar realmente a los ingenieros de software especializados.Reduccin del costo de produccin de software.

Para explicar algunas herramientas ms usadas para el diseo y desarrollo de software es importante tener claros estos conceptos. Entorno de desarrollo integrado. Definicin de IDE: Un IDE es un entorno de programacin que ha sido empaquetado como un programa de aplicacin, es decir, consiste en un editor de cdigo, un compilador, un depurador y un constructor de interfaz grfica (GUI). Los IDEs pueden ser aplicaciones por s solas o pueden ser parte de aplicaciones existentes.

Licencia BSD:Es la licencia de software otorgada principalmente para los sistemas Berkeley Software Distribucin. Es una licencia de software libre permisiva como la Esta licencia tiene menos restricciones en comparacin con otras como la GPL estando muy cercana al dominio pblico. La licencia BSD al contrario que la GPL permite el uso del cdigo fuente en software no libre.

Licencia Pblica General (GLP) de GNU.Conocida por su nombre en ingls GNU General Public License o simplemente sus siglas del ingls GNU GPL, es una licencia creada por la Free Software Foundation en 1989 (la primera versin), y est orientada principalmente a proteger la libre distribucin, modificacin y uso de software. Su propsito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiacin que restrinjan esas libertades a los usuarios.

Herramientas ms utilizadas (IDEs)

1. Microsoft Visual Studio: Es un entorno de desarrollo integrado (IDE, por sus siglas en ingls) para sistemas operativos Windows. Soporta varios lenguajes de programacin tales como Visual C++, Visual C#, Visual J#, ASP.NET y Visual Basic .NET, aunque actualmente se han desarrollado las extensiones necesarias para muchos otros.

2. NetBeans: Es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programacin Java. Existe adems un nmero importante de mdulos para extenderlo. NetBeans IDE1 es un producto libre y gratuito sin restricciones de uso.

3. Eclipse: Es un entorno de desarrollo integrado de cdigo abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, tpicamente ha sido usada para desarrollar entornos de desarrollo integrados (del ingls IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados tambin para desarrollar el mismo Eclipse).

CONSTRUCCIN SOFTWARe

La construccin de software se refiere a la creacin detallada de software que trabaja a travs de una combinacin de codificacin, verificacin, pruebas unitarias, pruebas de integracin, y la depuracin.FundamentosEl rea de conocimiento Construccin de Software (KA) est vinculado a todos los dems Kas, pero est ms estrechamente relacionada con el diseo de software y pruebas de software debido a que el proceso de construccin de software consiste en el diseo de software y pruebas. El proceso utiliza los resultados del diseo y proporciona una entrada para la prueba ("diseo" y "pruebas" en este caso se refiere a las actividades, no la KAS). Las fronteras entre el diseo, la construccin y las pruebas (si las hay) pueden variar en funcin de los procesos del ciclo de vida del software que se utilizan en un proyecto.Aunque algunos detalles del diseo se pueden realizar antes de la construccin, ya que tanto el trabajo de diseo se realiza durante la actividad de construccin.A lo largo de la construccin, los ingenieros de software, tanto de prueba de unidad e integracin realizan variedad de pruebas a su trabajo. La construccin de software normalmente producen el mayor nmero de elementos de configuracin que se deben gestionar en un proyecto de software (archivos de cdigo fuente, documentacin, casos de prueba, y as sucesivamente). Si bien la calidad del software es importante en todos los Kas, el cdigo es la clave dentro de un proyecto software.Desde la construccin de software requiere el conocimiento de algoritmos y de las prcticas de codificacin, esta est estrechamente relacionada con los Fundamentos Informticos KA, que se ocupa de los fundamentos informticos que apoyan el diseo y construccin de productos de software. Tambin est relacionada con la gestin de proyectos, en la medida en la gestin de la construccin puede presentar retos considerables.

Minimizar la complejidadLa necesidad de reducir la complejidad esencialmente se aplica a todos los aspectos de la construccin de software y es particularmente crtico para las pruebas de las construcciones de software. En la construccin de software, complejidad reducida se logra a travs enfatizando la creacin de cdigos que son simples y fciles de leer en vez de uno que necesite un esfuerzo para comprenderlos.Anticiparse al cambioLos cambios en los entornos en los que opera el software tambin afectan al software de diversas maneras.Anticipando el cambio ayuda a los ingenieros de software a construir software extensible, lo que significa que pueden mejorar un producto de software sin interrumpir la estructura subyacente.Construccin para la verificacinConstruir para la verificacin significa construir el software de tal manera que las fallas se pueden encontrar fcilmente por los ingenieros de software que lo construyen, as como por los probadores y usuarios durante las pruebas independientes y las actividades operacionales.ReutilizacinLa reutilizacin se refiere a la utilizacin de los activos existentes en la solucin de diferentes problemas. En la construccin de software, los activos tpicos que se reutilizan incluyen bibliotecas, mdulos, componentes, cdigo fuente, y comercial off-the-shelf (COTS) activos.La reutilizacin es el ms practicado sistemticamente, de acuerdo con un proceso repetible bien definido. Reutilizacin sistemtica puede permitir la productividad significativa software, la calidad y mejora de los costes.La aplicacin de las normas de desarrollo externo o interno durante la construccin ayuda a lograr los objetivos de un proyecto para la seguridad, eficiencia, la calidad y el costo.Modelos de ciclo de vidaEn la construccin de software la gestin juega un papel importante desde el comienzo del proyecto, por ejemplo, se tiene que decidir qu rumbo, forma de trabajo y sistema de desarrollo se llevar a cabo. Un punto importante dentro de la gestin en la construccin de software es el modelo de ciclo de vida que se utilizar para el desarrollo del proyecto. Los ciclos de vida son sistemas que permiten llevar un mtodo o forma de trabajo a la hora de codificar, existen diversos modelos de ciclos de vida para cada tipo de proyecto que se quiere llevar a cabo, basndose en factores como su extensin, complejidad, plazos de tiempo, presupuesto, calidad esperada, entre otros.

Es muy importante escoger el modelo de ciclo de vida adecuado para cada proyecto, ya que de eso dependern factores como la calidad y/o el tiempo de desarrollo, si se elige el modelo adecuado se pueden ahorrar recursos a la hora de la codificacin y del proceso de depuracin.Planificacin en la construccinLa planificacin abarca muchos aspectos en el desarrollo del producto software, es de vital importancia la planificacin adecuada de un proyecto antes de comenzar, por lo que se recomienda al personal encargado de esto, analizar los pros y los contras a la hora de tomar decisiones como el modelo de ciclo de vida, el sistema de desarrollo, la calendarizacin de actividades, los roles de trabajo, el personal, entre otras cosas.Un factor importante en la planificacin es intentar reducir los riesgos tanto como sea posible, es decir, encontrar el camino ms seguro para que el proyecto tenga un desarrollo estable y no haya problemas que se pudieron predecir que sucederan desde la planificacin. Otra parte importante de la planificacin son los recursos humanos, es importante que cada miembro tenga asignada una lista de actividades definidas que caigan dentro de sus capacidades, el encargado de la planeacin del proyecto tiene que conocer bien a los miembros del equipo de trabajo a la hora de asignar los roles y actividades.codificacinConsideraciones a aplicar en el momento de la codificacin:Las tcnicas para crear cdigo fuente comprensible, incluyendo estndares para el nombramiento de las variables.El uso de clases, tipos enumerados, variables, constantes y otras entidades similares.El uso de estructuras de control.La reaccin en condiciones que normalmente daran un error.La prevencin de infracciones de seguridad en el nivel de cdigo.La utilizacin de la va de recursos de mecanismos de exclusin y disciplina en el acceso seriado a recursos reutilizables.La organizacin del cdigo fuente.La documentacin del cdigo.La sintonizacin de cdigo.Pruebas durante la construccinLa construccin implica dos formas de hacer pruebas:Prueba de unidadesPrueba de integracinEl propsito de la construccin de pruebas es reducir la brecha entre el tiempo en el que las faltas son introducidas y el tiempo en el que esas faltas son detectadas y gracias a eso reducir el costo que tendr repararlas. Los casos de prueba pueden escribirse ya sea antes o despus de que el cdigo sea escrito.

IntegracinConsiste en la integracin de rutinas, clases, componentes y subsistemas construidos individualmente en un sistema nico. Adems, un sistema de software particular puede requerir ser integrado con otros sistemas de software o hardware.Las preocupaciones relacionadas con la integracin de la construccin incluyen la planeacin de la secuencia en la cual los componentes sern integrados, identificando que hardware es necesario, creando andamios para soportar las versiones interinas del software, determinando el grado de calidad del trabajo realizado en componentes antes de que sean integrados y determinando los puntos del proyecto en donde las versiones interinas del software son probadas.MEDICINExiste una numerosa cantidad de actividades o elementos durante el proceso de construccin que pueden ser medidos, la mayora de ellos relacionados con la codificacin, la cul es la tarea en el que el proyecto se materializa mediante la transcripcin de instrucciones a un lenguaje que el procesador sea capaz de leer, entender y ejecutar. El propsito de esta medicin es cuantificar el progreso obtenido en algn aspecto de la construccin en un momento especfico. Esto puede ser de gran utilidad ya que asegura la calidad al momento de construir y mejora el proceso de construccin.Medicin del proceso y producto softwareAntes que un nuevo proceso sea implementado o modificado, se deben obtener mediciones acerca de la situacin actual para brindar una referencia que sirva para comparar la situacin actual con la situacin esperada o deseada. Por ejemplo, antes de comenzar con el proceso de inspeccin de software, el esfuerzo usado para detectar y corregir errores en el proceso de testeo debe ser medido. Con esfuerzo no se refiere al concepto en el ms estricto sentido de la palabra, sino que es un trmino que se explicar ms adelante. Una vez que se haya incursionado en la inspeccin es ahora primordial medir el esfuerzo utilizado en el testeo y la inspeccin combinados y compararlo con el esfuerzo utilizado nicamente durante la etapa de testeo. El proceso software y la medicin del producto se basan en determinar la eficiencia y efectividad en alguna actividad o tarea de software. La eficiencia es la cantidad de recursos usados comparados con la cantidad de recursos que se esperaba o en su defecto deseaba usar. Esfuerzo (o costo equivalente) es la medicin neta de recursos utilizados para la mayora de los procesos software, generalmente es medida con unidades como horas/personas o algn equivalente monetario como dlares o euros. Efectividad es un concepto que se refiere a la comparacin de los resultados arrojados por el proceso con los resultados esperados. Por ejemplo, numero de errores detectados y corregidos comparados con el nmero de errores que se esperaba detectar y corregir. Ntese que como en este caso, la medicin de la efectividad del proceso requiere la medicin de atributos relevantes. Se debe ser cauteloso al medir atributos del producto para determinar la efectividad de un proceso software ya que en algunos casos puede llevar a resultados errneos o poco precisos para su uso en la comparacin. (Esto puede suceder cuando el software tiene una calidad ms alta que la usual o cuando un recientemente implementado proceso de inspeccin reduce la cantidad de defectos.)Algunas medidas del producto que son fundamentales relacionadas con la efectividad son la complejidad del producto, cantidad total de defectos, densidad de defectos, calidad de los requisitos y documentacin del diseo, entre otros. Es importante recalcar que efectividad y eficiencia son conceptos independientes el uno del otro. Un proceso de software efectivo puede no lograr el resultado deseado en un proceso; por ejemplo, la cantidad de esfuerzo usado en detectar y corregir errores puede ser demasiada alta y por consiguiente resultar en una eficiencia baja comparada con las expectativas. Un proceso eficiente puede ser inefectivo en lograr la transformacin deseada del trabajo de entrada al trabajo de salida del producto; por ejemplo, cuando se falla en detectar y corregir el nmero suficiente de errores durante el testeo.Algunas de las causas que ocasionan una baja eficiencia o efectividad a la hora de trabajar en el proceso de construccin pueden incluir algunas de las siguientes; productos con trabajo de entrada deficiente, personal inexperimentado, falta de las herramientas o infraestructura necesaria, estar aprendiendo un nuevo proceso, que el software sea demasiado complejo o que se est familiarizado. La eficiencia y efectividad del proceso de construccin tambin pueden ser afectadas (positiva o negativamente) por factores de otra ndole tales como: cambios de personal, cambios de itinerario, un nuevo representante por parte del cliente o cambios en la poltica interna de la organizacin.En ingeniera de software, productividad se define por resultados producidos divididos entre los recursos consumidos. Un ejemplo de esto sera el nmero de errores corregidos divididos entre el nmero de personal y horas que fueron requeridas para obtener los resultados deseados. el esfuerzo requerido para corregir los errores detectados ser incluido en los datos utilizados para el clculo de la productividad si el equipo fue capaz de corregir dichos errores. Ntese que se refiere a la productividad obtenida por equipos y no por individuos. Esto se debe a que la productividad calculada por individuos puede no ser precisa debido a los mltiples factores que pueden influir en la productividad individual de los ingenieros de software. Definiciones estandarizadas y reglas de conteo para la medicin de proceso software son necesarias para mediciones estandarizadas en los proyectos de una organizacin, con el fin de crear un historial de datos que pueda ser analizada para identificar que procesos pueden ser mejorados y construir modelos predictivos basados en los datos analizados. Calidad de los resultados en la medicinLos resultados de la medicin del producto y la calidad del proceso son primariamente determinados por la confiabilidad y validez de los resultados medidos. Las mediciones que no cumplen con estos criterios de calidad pueden dar lugar a interpretaciones incorrectas e iniciativas para la mejora de los procesos software defectuosos. Tcnicas para la medicin del proceso software:Las tcnicas para la medicin del proceso son usadas para recolectar datos del proceso y del trabajo del producto para transformarlas en informacin til, y analizar la informacin para identificar las actividades del proceso que son candidatas a ser modificadas para su mejora. En algunos casos se requerirn nuevos procesos de software. De igual forma estas tcnicas nos brindan la informacin necesaria para medir los efectos de las iniciativas de mejoras para los procesos. Es decir, se usan para recolectar informacin cualitativa y cuantitativa.Tcnicas para la medicin cuantitativa del procesoEl propsito de estas tcnicas es recolectar, transformar y analizar datos de procesos cuantitativos que pueden ser usados para indicar donde son necesarias las mejoras de procesos y para asentar los resultados de las iniciativas de mejora de procesos. Analizan datos de carcter numrico en los cuales pueden ser aplicados tcnicas de estadstica y matemticas.Tcnicas para la medicin cualitativa del procesoEntre estas se encuentran las entrevistas, cuestionarios, y la crtica experta. Tcnicas del consenso de grupo, como la tcnica de Delphi, puede ser usada para obtener el consenso entre los inversores.

PRUEBAS SOFTWARE

Sobre las pruebas de softwareHacer pruebas es una actividad que tiene el objetivo de evaluar y mejorar la calidad del producto, identificando defectos y problemas. Las pruebas del software consisten en verificar el comportamiento de un programa dinmicamente a travs de un grupo finito de casos de prueba, debidamente seleccionados del, tpicamente, mbito de ejecuciones infinito, en relacin al comportamiento esperado. Categoras de tcnicas de pruebas de software.FUNDAMENTOS DE PRUEBAS DE SOFTWARE

Se usan comnmente en el lenguaje de ingeniera de software, avera, fallo y error para definir un mal funcionamiento. Es esencial distinguir claramente entre la causa de un fallo de funcionamiento (para el que se utilizar el trmino fallo) y un efecto no deseado observado en el sistema de servicio prestado (que se llamar error).

Qu conceptos deben considerarse al realizar las pruebas de software?

Criterios de seleccin de prueba: Medio para seleccionar los casos de prueba que sean suficientes para un programa. Ayuda a decidir cuando las pruebas sern suficientes o cuando se ha logrado la verificacin.

Pruebas de efectividad/ objetivos de la prueba: La eficacia se determina mediante el anlisis de una serie de ejecuciones del programa. La seleccin de las pruebas a ejecutar se puede guiar por diferentes objetivos.

Pruebas para descubrimientos de defectos: Una prueba exitosa es aquella que hace que el sistema falle. Esto es muy diferente para las pruebas para demostrar que el software cumple con las especificaciones u otras propiedades deseadas.

El problema del Oracle: Un Oracle es cualquier ser humano o agente mecnico que decide si un programa se comport correctamente en una prueba determinada y por tanto da un veredicto de aprobado.

Limitaciones tericas y prcticas de las pruebas: Los resultados de las pruebas consolidadas suelen ser negativos, ya que la prueba nunca se comparar con la realidad por ende se debe conducir en funcin del riesgo.

El problema de caminos no factibles: Los caminos factibles son trayectorias de flujo de control que pueden ser ejercidos por cualquier dato de entrada, en cambio los caminos no factibles no pueden ser ejercidos por ningn dato, por lo cual no son verificables.

Comprobabilidad: El trmino capacidad de prueba de software tiene dos vertientes. La primera, se refiere a la facilidad de que el dato de entrada obtiene una salida satisfactoria. Y segundo, la probabilidad que un conjunto de casos de prueba se exponga un fallo, si el software es defectuoso.

Relacin de pruebas para otras actividades: Las pruebas de software se relacionan, con las tcnicas de gestin de calidad del software, pruebas de correccin, depuracin y construccin de programas.

CUALES SON LOS NIVELES DE PRUEBA DE SOFTWARE?Pruebas unitarias: Revisa los errores que se pueden encontrar en el cdigo o mdulos que puedan contener el programa.