uNidad 2

Unidad 2Equipo 2:Juan Carlos Martnez RamosErik Ivn Mancilla RomeroCristian SuarezLuis ngel SantiagoAlex Joshua Serrano2.2 Tcnicas de la Ingeniera de RequisitosTcnicas utilizadas en la actividades de IRExisten varias tcnicas para la IR, sin embargo, en este documento se van a estudiar slo algunas de ellas. Cada tcnica puede aplicarse en una o ms actividades de la IR; en la prctica, la tcnica ms apropiada para cada actividad depender del proyecto que est desarrollndose.Este anlisis de tcnica vs. actividad ser discutido en el captulo IV. Por el momento slo mencionaremos en qu consiste cada tcnica.Entrevistas y CuestionariosLas entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.Por lo comn, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por l.

2.2 Tcnicas de la Ingeniera de RequisitosLas preguntas que deben realizarse en esta tcnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener informacin sobre aspectos globales del problema del usuario y soluciones potenciales.Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar unproceso o problema. Este tipo de preguntas son siempre apropiadas, adems que ayudan a entender la perspectiva del afectado y no estn influenciadas por el conocimiento de la solucin.Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. Tipos de preguntas abiertas.Del UsuarioQuin es elcliente?Quin es el usuario?Son sus necesidades diferentes?Cules son sus habilidades, capacidades,ambiente?Del ProcesoCul es la razn por la que se quiere resolver este problema?Cul es elvalorde una solucin exitosa?Cmo usted resuelve el problema actualmente?Qu retrasos ocurren o pueden ocurrir?Del ProductoQuproblemaspodra causar esteproductoen el negocio?En qu ambiente se usar el producto?Cules son sus expectativas para los conceptos fcil de usar, confiable, rendimiento?Qu obstculos afectan laeficienciadel sistema?

Lluvia de Ideas Este mtodo comenz en el mbito de las empresas, aplicndose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos mtodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendi a otros mbitos, incluyendo el mundo de desarrollo de sistemas; bsicamente se busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introduccin de los principios cretivos.A esta tcnica se le conoce tambin como torbellino de ideas, tormenta de ideas, desencadenamiento de ideas, movilizacin verbal, bombardeo de ideas, sacudidas de cerebros, promocin de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras.

Principios de la lluvia de ideasAplazar el juicio y no realizar crticas, hasta que no agoten las ideas, ya que actuara como un inhibidor. Se ha de crear una atmsfera de trabajo en la que nadie se sienta amenazado.Cuantas ms ideas se sugieren, mejores resultados se conseguirn: "la cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo de produccin de ideas, ser ms fcil que encontremos las soluciones y tendremos ms variedad sobre la que elegir.La produccin de ideas en grupos puede ser ms efectiva que la individual.Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, sern asociadas de manera distinta por cada miembro, y har que aparezcan otras por contacto.

Como se conforma un equipo de lluvia de ideas?El Director: es la figura principal y el encargado de dirigir la sesin. Debe ser un experto en pensamiento creador. Su funcin es formular claramente el problema y que todos se familiaricen con l. Cuando lo haga, debe estimular ideas y hacer que se rompa el hielo en el grupo. Es el encargado de que se cumplan las normas, no permitiendo las crticas. Debe permanecer callado e intervenir cuando se corte la afluencia de ideas, por lo que le ser til llevar ya un listado de ideas. Debe hacer que todos participen y den ideas. Adems, es la persona que da concede la palabra y da por finalizada la sesin. Posteriormente, clasificar las ideas de la lista que le proporciona el secretario. Ejemplo de una lluvia de ideas

PrototiposLos prototipos permiten al desarrollador crear unmodelodelsoftwareque debe ser construido.Al igual que todos los enfoques al proceso de desarrollo del software, el prototipo comienza con la captura de requerimientos. Desarrolladores y clientesse renen y definen losobjetivosglobales del software, identifican todos los requerimientos que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las definiciones. Luego de esto, tiene lugar un "diseorpido". El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un prototipo. El prototipo es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Tipos de prototiposPrototipo rpido (o concept prototipe): El prototipo rpido es un mecanismo para lograr la validacin pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseo especfico. En este sentido, el prototipo puede ser visto como una aceptacin tcita de que los requerimientos no son totalmente conocidos o entendidos antes del diseo y la implementacin. El prototipo rpido puede ser usado como un medio para explorar nuevos requerimientos y as ayudar a "controlar" su constanteevolucin.Prototipo evolutivo: Desde una perspectiva diferente, todo elciclo de vidade un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida est dividido en dos fases distintas: desarrollo ymantenimiento. La experiencia ha demostrado que esta distincin es arbitraria y va en contra de la realidad ya que la mayor parte delcostodel software ocurre despus de que el producto se ha entregado. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos ms maduros. Este proceso contina hasta que se haya desarrollado el producto final. Laadopcinde estapticaelimina la distincin arbitraria entre desarrollo y mantenimiento, resultando en un importantecambiode mentalidad que afecta lasestrategiaspara la estimacin decostos, enfoques de desarrollo y adquisicin de productos.

Proceso de Anlisis Jerrquico (AHP)Esta tcnica tiene porobjetivoresolver problemas cuantitativos, para facilitar el pensamiento analtico y las mtricas. Consiste en una serie de pasos a saber:Encontrar los requerimientos que van a ser priorizados.Combinar los requerimientos en las filas y columnas de lamatrizn x n de AHP.Hacer algunas comparaciones de los requerimientos en la matrizSumar las columnasNormalizar la suma de las filasCalcular los promediosEstos pasos pueden aplicarse fcilmente a una cantidad pequea de requerimientos, sin embargo, para unvolumengrande, esta tcnica no es la ms adecuada.

Un ejemplo claro

ConclusinEs una parte importantsima en el desarrollo del software ya que esta es una de las herramientas fundamentales al constituir una visin previa del software mediante tcnicas como la lluvia de ideas y otras ms, y es uno de los factores que facilitan y reducen el tiempo que normalmente se lleva comnmente al desarrollar un software.Referenciashttp://www.soi.city.ac.uk/~gespan/sw_group_pub.htmlPublicaciones de Elsevier Science. http://www.elsevier.nl/Oberg, Roger; Probasco Leslee; Ericsson, Maria. "Applying Requirements Management with Use Cases". Rational Software Corporation. 1998.Hofmann, Hubert. "Requirements Engineering". Institute for Informatics University of Zurich. 1993.