CONTENIDO SISTEMA DE INFORMACION 1

Unidad 1 Contexto organizacional del anlisis 1.1 Observacion del comportamiento y del ambiente 1.1.1 Actividades de Toma de Decisiones 1.1.2 Muestreo de Tiempos y Eventos 1.1.3 Diagrama del Contexto 1.2 Identificacion de problemas y oportunidades 1.3 Identificacion de objetivos 1.3.1 Identificacion 1.3.2 Clasificacion 1.3.3 Redaccion 1.4 Formulacion de los estudios de factibilidad tecnica, economica y operativa del proyecto Unidad 2 Determinacin de requerimientos 2.1 Identificacion de requerimientos 2.2 Tecnicas y medios para la recoleccin de requerimientos 2.3 Tipos de requerimientos 2.4 Herramientas de software para la determinacin de requerimientos Unidad 3 Tcnicas para el anlisis de requerimientos 3.1 Tecnicas estructuradas para el analisis de requerimientos 3.1.1 Caracteristicas del Analisis Estructurado 3.1.2 Especificacion Formal de Datos 3.1.2.1 Diagrama de Flujo y Control de Datos 3.1.2.2 Diccionario de Datos 3.1.3 Especificacion de Procesos 3.1.3.1 Lenguaje natural 3.1.3.2 Lenguaje estructurado 3.1.3.3 Tablas de decision 3.1.3.4 Arboles de decision 3.2 Tecnicas Orientadas a Objetos para Analisis de Requerimientos

3.2.1 Caracteristicas Analisis Orientado a Objetos 3.2.2 Especificacion Formal de Objetos 3.2.2.1 Casos de uso 3.2.2.2 Modelado de Clases Responsabilidades y Colaboraciones 3.2.2.3 Definicion de Atributos 3.2.2.4 Definicion de Servicios 3.2.3 Prototipos Rapidos en determinacion de Requerimientos 3.3 Tecnicas Basadas en Componentes 3.3.1 Ingenieria del Dominio 3.3.2 Identificacion Clasificacion Componentes Reutilizables 3.3.3 Caracterizacion de Componentes 3.4 Otras tcnicas Unidad 4 Mtricas para la evaluacin del anlisis 4.1 Metricas Modelo de Analisis 4.1.1 Metricas Basadas en Funcion 4.1.2 La Metrica Bang 4.1.3 Metricas de Calidad de Especificacion 4.2 Revisiones Tecnicas Formales 4.2.1 La Reunion de Revision 4.2.2 Registro Informe de Revision 4.2.3 Directrices para la revision Unidad 5 Documentacin del anlisis del sistema 5.1 Estandares Documentacion Analisis 5.2 Preparacion del reporte escrito del analisis 5.3 Presentacion de la propuesta

1.1.1 Actividades de toma de decisiones. Es el proceso durante el cual la persona debe escoger entre dos o ms alternativas. Todos y cada uno de nosotros pasamos los das y las horas de nuestra vida teniendo que tomar decisiones. Algunas decisiones tienen una importancia relativa en el desarrollo de nuestra vida, mientras otras son gravitantes en ella. Para los administradores, el proceso de toma de decisin es sin duda una de las mayores responsabilidades. La toma de decisiones en una organizacin se circunscribe a una serie de personas que estn apoyando el mismo proyecto. Debemos empezar por hacer una seleccin de decisiones, y esta seleccin es una de las tareas de gran trascendencia. Con frecuencia se dice que las decisiones son algo as como el motor de los negocios y en efecto, de la adecuada seleccin de alternativas depende en gran parte el xito de cualquier organizacin. Una decisin puede variar en trascendencia y connotacin. Los administradores consideran a veces la toma de decisiones como su trabajo principal, porque constantemente tienen que decidir lo que debe hacerse, quin ha de hacerlo, cundo y dnde, y en ocasiones hasta cmo se har. Sin embargo, la toma de decisiones slo es un paso de la planeacin, incluso cuando se hace con rapidez y dedicndole poca atencin o cuando influye sobre la accin slo durante unos minutos. La penetracin de la toma de decisiones La toma de decisiones en una organizacin invade cuatro funciones administrativas que son: planeacin, organizacin, direccin y control. Funciones administrativas dentro de la organizacin al tomar decisiones: La Planeacin: Seleccin de misiones y objetivos as como de las acciones para cumplirlas. Esto implica "Toma de decisin". Cules son los objetivos de la organizacin, a largo plazo? Qu estrategias son mejores para lograr este objetivo? Cules deben ser los objetivos a corto plazo? Cun altas deben ser las metas individuales? Organizacin: Establecimiento de la estructura que desempean los individuos dentro de la organizacin. Cunta centralizacin debe existir en la organizacin? Cmo deben disearse los puestos? Quin est mejor calificado para ocupar un puesto vacante? Cundo debe una organizacin instrumentar una estructura diferente? Direccin: Esta funcin requiere que los administradores influyan en los individuos para el cumplimiento de las metas organizacionales y grupales. Cmo manejo a un grupo de trabajadores que parecen tener una motivacin baja? Cul es el estilo de liderazgo ms eficaz para una situacin dada? Cmo afectar un cambio especfico a la productividad del trabajador? Cundo es adecuado estimular el conflicto? Control: Es la medicin y correccin del desempeo individual y organizacional de manera tal que se puedan lograr los planes.

Qu actividades en la organizacin necesitan ser controladas? Cmo deben controlarse estas actividades? Cundo es significativa una desviacin en el desempeo? Cundo la organizacin est desempendose de manera efectiva? Importancia de la toma de decisiones Es importante por que mediante el empleo de un buen juicio, la Toma de Decisiones nos indica que un problema o situacin es valorado y considerado profundamente para elegir el mejor camino a seguir segn las diferentes alternativas y operaciones. Tambin es de vital importancia para la administracin ya que contribuye a mantener la armona y coherencia del grupo, y por ende su eficiencia. En la Toma de Decisiones, considerar un problema y llegar a una conclusin vlida, significa que se han examinado todas las alternativas y que la eleccin ha sido correcta. Dicho pensamiento lgico aumentar la confianza en la capacidad para juzgar y controlar situaciones. Uno de los enfoques mas competitivos de investigacin y anlisis para la toma de las decisiones es la investigacin de operaciones. Puesto que esta es una herramienta importante para la administracin de la produccin y las operaciones. La toma de decisiones, se considera como parte importante del proceso de planeacin cuando ya se conoce una oportunidad y una meta, el ncleo de la planeacin es realmente el proceso de decisin, por lo tanto dentro de este contexto el proceso que conduce a tomar una decisin se podra visualizar de la siguiente manera: Elaboracin de Identificacin de Evaluacin alternativas en trminos de la Eleccin de una alternativa, es decir, tomar una decisin. 1.1.2 Muestreo de tiempos y eventos. 1.1.3 Diagrama del contexto. Se pueden usar diagramas de flujos de datos para representar el sistema a cualquier nivel de abstraccin. El diagrama de flujo de dato de nivel 0 se llama diagrama de contexto y en l el sistema esta representado por un solo proceso, que identifica cual es la funcin principal del sistema, mostrando adems, los flujos de informacin que lo relacionan con otros sistemas: las entidades externas. El diagrama de contexto tiene una gran importancia puesto que resume el requisito principal del sistema de recibir ciertas entradas, procesarlas de acuerdo con determinada funcin y generar ciertas salidas. A partir del diagrama de contexto se puede ir construyendo nuevos diagramas que vayan definiendo con mayor nivel de detalle lo flujos de datos y procesos de transformacin que ocurren en el sistema, de forma que al final obtenemos una jerarqua de diagramas. premisas. alternativas. meta deseada.

1.2 Identificacion de problemas y oportunidades

1. 1.2 Identificacin de problemas y oportunidades Es la primera etapa del ciclo de desarrollo de sistemas, el analista se involucra en la identificacin de los problemas, de las oportunidades y de los objetivos. Esta fase es crucial para el proyecto, pues nadie estar dispuesto a desperdiciar su tiempo dedicndolo al problema equivocado. 2. La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organizacin, har notar los problemas. Muchas veces esto ya fue realizado previamente; y por ello es que se llega a invitar al analista. 1.2 Identificacin de problemas y oportunidades 3. 1.2 Identificacin de problemas y oportunidades Las oportunidades son aquellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de los sistemas de informacin computarizados. Al aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o llegar a establecer un estndar industrial.

1.2 Identificacion de problemas y oportunidades Esta etapa suele ser la primera y la ms difcil de todo el proceso del ciclo de vida debido a que se encarga del reconocimiento de las fallas o problemas que una organizacin puede enfrentar. Tradicionalmente han sido los usuarios y los directivos de las empresas quienes impulsan la mayora de los proyectos. Por su parte, los analistas estn encargados de descubrir mejoras dentro de la organizacin; por lo tanto el analista debe identificar los problemas, las oportunidades y las normas y objetivos que rigen a la empresa. Problema es una situacin no deseable que impide que la organizacin pueda alcanzar plenamente sus propsitos metas y objetivos. Una oportunidad es toda posibilidad de mejorar el sistema o lograr la ausencia de problemas especficos. Una norma es todo requisito impuesto por la direccin, las instituciones gubernamentales o cualquier influencia externa. Si una oportunidad no es usada en su momento, sta a la larga puede convertirse en un problema ya que esto pudiera implica el no usar situaciones favorables tanto para el analista como para la organizacin. Con relacin a las normas que se aplican en una organizacin, stas representan problemas, pues implican el cambio de actividades o porcesos internos dentro del tratamiento de informacin. Los problemas se dan a notar de diversas formas; es decir, stos pueden estar presentes en la organizacin y tomarse como prcticas normales de trabajo y depende en gran parte del usuario (directivos) poder descubrir estos problemas

y del analista para determinarlos. La mayora de los problemas dentro de las organizaciones se refieren al desempeo (ausentismo, falta de compromiso por parte de los empleados, alta rotacin de personal). Sin olvidar a los clientes o proveedores del sistema ya que ellos ejercen el tipo de retroalimentacin que el sistema est recibiendo. Considere como retroalimentacin las quejas o sugerencias que se reciben, as como ventas no consolidadas o canceladas, etc, adems del reflejo al momento de medir los resultados contra los objetivos planeados. Estos son sntomas que deben ser tomados en cuenta para iniciar de inmediato el anlisis del sistema.

1.3 Identificacion de objetivos

1.3.1 Identificacin. Definicin de objetivo: Es un parmetro de evaluacin a nivel de educacin. En el campo de la educacin, podemos decir, que un objetivo es el resultado que se espera logre el alumno al finalizar un determinado proceso de aprendizaje. Finalidad de los objetivos: Los objetivos no constituyen un elemento independiente dentro del proceso educativo, sino que forman parte muy importante durante todo el proceso , ya que son el punto de partida para seleccionar, organizar y conducir los contenidos, introduciendo modificaciones durante el desarrollo del proceso de enseanza - aprendizaje , adems de que son la gua para determinar qu enseanza y cmo ensearlo, nos permiten determinar cul ha sido el progreso del alumno y facilitar al docente la labor de determinar cules aspectos deben ser reforzados con su grupo de nios . 1.3.2 Clasificacin. De acuerdo a los fines que se desean lograr, los objetivos pueden ser de mayor o menor amplitud y en cada caso existen procedimientos y recursos especficos para alcanzarlos. La clasificacin que se hace entre objetivos generales y especficos es relativa, ya que cada uno de ellos puede ser considerado como general o especifico segn la forma como sean interpretados y de la relacin que tengan con otros objetivos. A continuacin se exponen un ejemplo que ilustra lo sealado anteriormente: Ejemplo: A travs de la implementacin del programa "X", se espera:

1. Facilitar en los nios el desarrollo de su expresin verbal. 2. Que los nios aumenten el nmero de palabras que integran su vocabulario. 3. Que los nios utilicen adecuadamente los tiempos pasados y futuros de por lo menos 5 verbos. 4. Que los nios articulen correctamente las palabras que contengan la letra "rr". En estos casos, el objetivo b) es especfico con respecto a a), pero general con respecto a c). Igualmente, el objetivo c) es especfico con respecto a b), pero general con respecto a d). En cualquier caso, al formular objetivos, es importante que el docente tome en consideracin los siguientes aspe

El objetivo general de la accin educativa en el rea de preescolar , debe ser el de facilitar en el nio el desarrollo de sus potencialidades en la forma ms espontnea posible. En la prctica vemos que en muchas oportunidades no se dan todos los procesos esperados para un nivel de edad; en forma espontnea. En estos casos es necesario que el docente planifique en forma especfica los objetivos a lograr con su grupo . Recordemos que estos nios que ahora estn en preescolar en uno dos aos ingresaran a la Escuela Bsica y para lograr xito dentro de un proceso de aprendizaje formal necesitan un adecuado nivel en todas sus reas de desarrollo. Por lo tanto los procesos que no se den de forma espontnea deben ser reforzados por el docente. Con mucha frecuencia los objetivos generales son de de tal amplitud que resultan muy difcil evaluarlos en una forma vlida. Estos objetivos generales debemos dividirlos en objetivos ms especficos que puedan ser evaluados con mayor facilidad. Los objetivos deben estar formulados desde el punto de vista del nio y no del docente, destacando lo que el alumno debe ser capaz de realizar a travs del proceso de aprendizaje. Los objetivos especficos deben ser redactados en trminos de conductas observables con el fin de que posteriormente puedan ser evaluados.

Ejemplo: Conductas Observables Conductas no Observables

Al finalizar el trimestre se espera que Al finalizar el trimestre se espera que el nio: el nio: -Establezca objetos. correspondencia entre -Desarrolle el concepto de nmero.

-Ordene objetos de mayor a menor. -Identifique los nmeros del 1 al 5.

Cada objetivo debe contener una sola conducta en su enunciado.

Ejemplo: Correcto Incorrecto

-Identificar tres figuras geomtricas -Identificar, nombrar y reproducir tres (circulo, cuadrado y triangulo). figuras geomtricas (crculo, cuadrado y tringulo). -Nombrar tres figuras geomtricas (crculo, cuadrado y tringulo). -Reproducir tres figuras geomtricas (crculo, cuadrado y tringulo). Los objetivos contenidos en la planificacin del docente deben necesariamente tener una estrecha relacin con las necesidades e intereses de su grupo de nios, de all que deben variar de un grupo a otro en algunos aspectos as sean nios de las mismas edades. Los ideal es que sean establecidos despus de hacer un diagnostico previo del grupo, de tal manera que lo mas factible es que sea necesario planificar actividades y objetivos diferentes para varios subgrupos de acuerdo a las dificultades, necesidades e interese de los nios. Tambin es muy importante que la accin educativa est enmarcada dentro de los objetivos que rigen la Educacin Preescolar , los cuales en lneas generales son los siguientes:

Favorecer el desarrollo psicomotor del nio brindndole la estimulacin necesaria y el ambiente adecuado para lograrlo. Brindar al nio las experiencias necesarias para que logre un adecuado desarrollo cognitivo y estimular su pensamiento hasta la formacin de estructuras lgicas. Estimular el lenguaje del nio y favorecer su adecuada utilizacin como medio de expresin y comunicacin , a travs del contacto con otros nios y adultos. Favorecer las experiencias de tipo social brindndole al nio la oportunidad de establecer relaciones adecuadas con adultos y nios, que sirvan para su normal desarrollo socioemocional. Crear en el nio hbitos de aseo, alimentacin , cortesa, et., que le faciliten su incorporacin en la sociedad . Brindar al nio la posibilidad de que sus dificultades (motrices, de lenguaje , etc), sean detectadas tempranamente y recibir la orientacin y atencin adecuadas para poder superarlas.

OBJETIVO GENERAL = RESULTADOS + OBJETIVOS ESPECIFICOS = OBJETIVO GENERAL RESULTADOS La suma de los objetivos especficos es igual al objetivo general y por tanto a los resultados esperados.

1.3.3 Redaccin. CMO DEBEN SER LOS OBJETIVOS? - FACTIBLES: Que puedan ser alcanzados por un alumno de capacidad media en el tiempo previsto y con los recursos y condicionantes de los que se parte. - EVALUABLES : Que su consecucin pueda ser evaluada de alguna forma. Esto es ms complicado en el caso de los objetivos de competencias. Convendr pensar sistemas que nos permitan evaluar, aunque sea de forma genrica, si los alumnos han logrado o no desarrollar tales competencias. A TENER EN CUENTA EN SU REDACCIN: - Redactarlos desde el punto de vista del alumno . - ( Bien ) El alumno deber adquirir una perspectiva sociolgica que le capacite para una cabal comprensin de los hechos sociales. - ( Mal ) Dotar al alumno de la perspectiva sociolgica que le capacite para una cabal comprensin de los hechos sociales. - Que su formulacin sea detallada , en la medida de lo posible. Ejemplos - ( Bien ) Que el alumno sea capaz de definir los principales elementos estructurales de la direccin de los centros educativos: el ideario, los objetivos generales, los reas de actividad y la definicin de funciones. - ( Mal ) Profundizar en el conocimiento del centro educativo como organizacin. - Que su redaccin sea precisa (evitar los trminos innecesarios) y concreta (evitar verbos y adjetivos de significacin vaga). Conviene evitar verbos demasiado genricos como conocer , saber , estudiar , etc. Y utilizar verbos ms concretos como definir , seleccionar , demostrar , distinguir , relacionar , valorar , interpretar , dominar, comprender , etc. que definen la conducta concreta del alumno. - ( Bien ) Que el estudiante sea capaz de manejar adecuadamente los conceptos de relaciones estequiomtricas y expresiones de la concentracin - ( Mal ) Conocer los conceptos de relaciones estequiomtricas y expresiones de la concentracin. EJEMPLOS DE OBJETIVOS CORRECTAMENTE FORMULADOS Objetivos de conocimientos

Que el alumno sea capaz de: - Comprender la Mecnica Newtoniana , siendo capaz de establecer los principios de conservacin de los momentos lineal, angular, de masa y energa. - Nombrar y formular correctamente las molculas orgnicas - Manejar adecuadamente los conceptos clsicos del Anlisis Matemtico - Adquirir una visin global e integrada de la historia de la educacin espaola. - Leer con detenimiento el Pentateuco y los libros Histricos del Antiguo Testamento, de modo que se llegue a conocer bien su contenido. - Comprender los precedentes de las actuales instituciones polticoadministrativas espaolas y de las fuentes del Derecho Espaol, desde los pueblos prerromanos hasta la poca constitucional. Objetivos de competencias Que el alumno llegue a: - Desarrollar el espritu crtico y cientfico al estudiar los problemas medioambientales - Desarrollar habilidades sociales participativas y comunicativas. - Entender, asimilar, relacionar y explicar los fenmenos naturales de experiencia personal cotidiana con arreglo a los criterios cientficos. - Utilizar de modo adecuado las diversas herramientas Estadsticas. - Interiorizar unos hbitos de autocorreccin y de cuidado por la lengua. - Relacionar las diferentes partes de la asignatura. - Profundizar en todas las fases compositivas de textos periodsticos avanzados. - Adquirir un hbito de trabajo continuado a lo largo del tiempo. ALGUNOS VERBOS A UTILIZAR EN LA FORMULACIN DE OBJETIVOS: 1. Cuando el objetivo persigue la MEMORIZACIN por parte del estudiante, se puede redactar con verbos como los siguientes: definir, sealar, describir, nombrar, identificar, narrar, indicar, mencionar. 2. Cuando el objetivo persigue la COMPRENSIN de determinados contenidos, es decir, que el estudiante entienda la informacin: traducir, resumir, expresar, discutir.

3. Cuando el objetivo hace referencia a la APLICACIN de los conocimientos a situaciones concretas: demostrar, practicar emplear, solucionar, usar, operar, emplear, dramatizar, aplicar. 4. Cuando el objetivo es el ANLISIS : diferenciar, relacionar, inferir, discriminar, distinguir, analizar, criticar, contrastar. 5. Cuando el objetivo es la SINTESIS : organizar, disear, elaborar, reconstruir, proponer, reordenar. 6. Cuando el objetivo es la EVALUACIN , es decir la capacidad de juzgar los contenidos en funcin de criterios externos o internos: juzgar, evaluar, apreciar, revisar, corregir, seleccionar, justificar, valorizar.

1.4 Formulacion de los estudios de factibilidad tecnica, economica y operativa del proyecto Determinacin de la Factibilidad Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas sealados, la factibilidad se apoya en 3 aspectos bsicos:

Operativo. Tcnico. Econmico.

El xito de un proyecto esta determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores. Estudio de Factibilidad. Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisin, si procede su estudio, desarrollo o implementacin. Objetivo de un Estudio de Factibilidad. 1.- Auxiliar a una organizacin a lograr sus objetivos. 2.- Cubrir la metas con los recursos actuales en las siguientes areas. a). Factibilidad Tcnica. - Mejora del sistema actual. - Disponibilidad de tecnologa que satisfaga las necesidades. b).- Factibilidad Econmica.

- Tiempo del analista. - Costo de estudio. - Costo del tiempo del personal. - Costo del tiempo. - Costo del desarrollo / adquisicin. c).- Factibilidad Operativa. - Operacin garantizada. - Uso garantizado. DEFINICIN DE OBJETIVOS. La investigacin de factibilidad en un proyecto que consiste en descubrir cuales son los objetivos de la organizacin, luego determinar si el proyecto es til para que la empresa logre sus objetivos. La bsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar. En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos. Estos objetivos son los siguientes:

Reduccin de errores y mayor precisin en los procesos. Reduccin de costos mediante la optimizacion o eliminacin de recursos no necesarios. Integracin de todas la areas y subsistemas de la empresa. Actualizacin y mejoramiento de los servicios a clientes o usuarios. Aceleracin en la recopilacin de datos. Reduccin en el tiempo de procesamiento y ejecucin de tareas. Automatizacin optima de procedimientos manuales.

Recursos de los estudios de Factibilidad La determinacin de los recursos para un estudio de factibilidad sigue el mismo patron considerado por los objetivos vistos anteriormente, el cual deber revisarse y evaluarse si se llega a realizar un proyecto. estos recursos se analizan en funcin de tres aspectos:

Operativos. Tcnicos. Econmicos.

Factibilidad O perativa . Se refiere a todos aquellos recursos donde interviene algn tipo de actividad ( Procesos ), depende de los recursos humanos que participen durante la operacin del proyecto. Durante esta etapa se identifican

todas aquellas actividades que son necesarias para lograr el objetivo y se evala y determina todo lo necesario para llevarla a cabo. Factibilidad T cnica . Se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, etc., que son necesarios para efectuar las actividades o procesos que requiere el proyecto. Generalmente nos referimos a elementos tangibles ( medibles ). El proyecto debe considerar si los recursos tcnicos actuales son suficientes o deben complementarse. Factibilidad E conmica . Se refiere a los recursos econmicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos bsicos que deben considerarse son el costo del tiempo, el costo de la realizacin y el costo de adquirir nuevos recursos. Generalmente la factibilidad econmica es el elemento mas importante ya que a travs de el se solventan las dems carencias de otros recursos, es lo mas difcil de conseguir y requiere de actividades adicionales cuando no se posee. Presentacin de un estudio de Factibilidad Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organizacin, pero sin descuidar ninguno de los elementos necesarios para que el proyecto funcione. Para esto dentro de los estudios de factibilidad se complementan dos pasos en la presentacin del estudio:

Requisitos Optimos. Requisitos Mnimos.

El primer paso se refiere a presentar un estudio con los requisitos ptimos que el proyecto requiera, estos elementos debern ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la mxima eficacia. El segundo paso consiste en un estudio de requisitos mnimos, el cual cubre los requisitos mnimos necesarios que el proyecto debe ocupar para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la empresa para minimizar cualquier gasto o adquisicin adicional. Un estudio de factibilidad debe representar grficamente los gastos y los beneficios que acarrear la puesta en marcha del sistema, para tal efecto se hace uso de la curva costo-beneficio .

Unidad 2 Determinacin de requerimientos 2.1 Identificacion de requerimientos El objetivo del anlisis de sistemas es comprender situaciones, no resolver problemas, por lo que es necesario conocer cmo opera el sistema e identificar los requerimientos que tienen los usuarios para proponer la modificacin a un sistema. Una vez comprendido el sistema, los analistas estn en posicin de analizarlo y generar recomendaciones para el diseo del sistema.

La forma en que se realiza la investigacin es la que determina si se reune la informacin apropiada, y sta influye en la calidad de la aplicacin. Es el estudio de un sistema para conocer cmo trabaja y dnde es necesario efectuar mejoras. Los estudios de sistemas dan como resultado una evaluacin de la forma de cmo trabajan los mtodos empleados y si es necesario realizar ajustes.

Un requerimiento es una caracterstica que debe incluirse en un nuevo sistema. Esta forma puede ser la forma de capturar, procesar datos, producir informacin., controlar una actividad de una empresa o brindar soporte a la gerencia. Es as, como la determinacin de requerimientos vincula el estudio de un sistema existente con la recopilacin de detalles relacionados con l.

Cabe considerar que los analistas de sistemas, no trabajan con los empleados del sistema, carecen de los mismos conocimientos, hechos y detalles que los usuarios de stas reas. Por lo que es necesario como primer paso, comprender la situacin; esto puede realizarse conociendo los requerimientos fundamentales que casi son comunes en todas las situaciones. Es importante reconocer los requerimientos bsicos de aquellos que tienen que ver con sistemas de transacciones, toma de decisiones, etc. 2.2 Tecnicas y medios para la recoleccin de requerimientos Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

Entrevistas

Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Los requerimientos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o

limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requerimientos. En sistemas muy complejos stos pueden tener centenares de pginas. Objetivos mensurables Los requerimientos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto.

Prototipos

Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. R.EDER.WJ!! TEC DE VILLAHERMOSA, TAB!!+ Cuestionario Un cuestionario es un conjunto de preguntas que deben ser contestadas por escrito por una determinada poblacin, generalmente esta poblacin es amplia. Segn el contenido de los cuestionarios podemos clasificarlos en los siguientes tipos: 1. Abiertos: Las respuestas no estn delimitadas, esto permite mayor libertad de expresin. 2. Cerrados: Se fuerza a respuestas concretas. Un mismo tipo de pregunta puede formularse para obtener diferente rango de respuestas: Eleccin exclusiva (respuestas del tipo si/no). Por ejemplo: Cree que existen muchos circuitos integrados defectuosos? Escala cualitativa

(acuerdo/desacuerdo). Por ejemplo: Existen muchos circuitos integrados defectuosos. Las posibles respuestas son: de acuerdo, totalmente de acuerdo, no estoy seguro, en desacuerdo, totalmente en desacuerdo. Cantidad, es decir, la pregunta requiere como respuesta una determinada cantidad. Por ejemplo: De cada 100 circuitos integrados cuntos son defectuosos? Rango o escala cuantitativa, donde la respuesta es un rango de valores. Por ejemplo: De cada 100 circuitos integrados son defectuosos (05, 610, >50, etc.) Seleccin de respuestas limitadas. Por ejemplo: Las causas ms frecuentes de circuitos integrados defectuosos son: a) Fallo en la impresin de la pista. b) Fallo en la conexin de las patillas. c) Fallo en el encapsulado de plstico. 3. Mixtos: una combinacin de los anteriores Los buenos cuestionarios no solo se escriben sino que se disean. Una buena elaboracin acompaada de una prueba previa, tanto del formato como de las preguntas, son la base de una recopilacin de datos significativa a travs del cuestionario. Introduciremos una serie de pautas que ayudarn en la formulacin de un cuestionario: 1. Determinar qu datos necesitan recabarse y qu personas son las ms calificadas para proporcionarlos. Si hay otros grupos que pueden proporcionar datos variantes y mayor visin tambin se identificarn. 2. Seleccionar el tipo de cuestionario a utilizar (abierto, cerrado o mixto). 3. Desarrollar un grupo de preguntas para incluirlas en el cuestionario. Las preguntas extras que son intencionalmente redundantes, pueden ser tiles al asegurar respuestas consistentes por parte de quien responda. 4. Examinar el cuestionario para encontrarle fallos y defectos, como: a) Interrogantes innecesarias. b) Preguntas que pueden ser mal interpretadas debido a su enfoque o forma de escritura. c) Preguntas que el sujeto posiblemente no pueda responder, dado que desconoce la respuesta. d) Preguntas que estn escritas de forma que se escoger la respuesta preferida. e) Preguntas que se interpretarn de forma diferente dependiendo del marco de referencia de cada entrevistado. f) Preguntas que no proporcionan opciones adecuadas de respuesta. g) Un ordenamiento no adecuado de las preguntas o respuestas. 5. Probar previamente el cuestionario en un grupo pequeo de personas, para detectar otros problemas posibles. As no solamente se describen los problemas en cuanto a su escritura, espaciado, ortografa, y mtodos de registro de respuestas, sino tambin proporciona una indicacin del tipo de respuestas que se recopilarn en un grupo mayor. Si existen muchas respuestas inesperadas, se captarn durante la prueba previa. Hay que asegurar que la muestra de prueba sea comparable al grupo mayor que recibir el cuestionario.

6. Analizar las respuestas del grupo de prueba para asegurar que el anlisis de los datos que se busca puede llevarse a cabo con el tipo de datos recopilados. Si estos datos no revelan algo que los analistas no reconocen y no necesitan verificar, el cuestionario puede no ser necesario en su forma actual. 7. Realizar cambios finales de edicin, correcciones de mecanografa y ajustes en la forma; entonces imprimir el cuestionario en una forma limpia y legible. 8. Distribuir el cuestionario. Cuando sea posible, anotar el nombre de cada persona. Ventajas 1. En su mayora, los cuestionarios pueden ser contestados con rapidez. Los encuestados pueden completar y remitir los cuestionarios cuando mejor les convenga. 2. Los cuestionarios ofrecen un medio relativamente econmico para recoger datos de un amplio nmero de personas. 3. Los cuestionarios permiten a las personas mantener el anonimato. Por consiguiente, es ms probable que stas informen de los hechos reales, en vez de decir lo que piensan que su jefe aprobara que dijera. 4. Las respuestas pueden incluirse en tablas y analizarse rpidamente. Inconvenientes 1. El nmero de encuestados es, a menudo, insuficiente. 2. No existe garanta de que los encuestados respondan o expliquen todas las preguntas. 3. Los cuestionarios suelen ser poco flexibles. Impiden que el analista de sistemas obtenga informacin voluntaria de las personas o replantee preguntas que puedan haber sido malinterpretadas. 4. El analista de sistemas no tiene la posibilidad de observar y analizar el lenguaje corporal del encuestado. 5. No existe una oportunidad inmediata para aclarar respuestas vagas o incompletas a una pregunta. 6. Los buenos cuestionarios son difciles de preparar. 2.3 Tipos de requerimientos Requerimientos bsicos. Los analistas deben estructurar su investigacin sobre la organizacin de acuerdo con las siguientes cuatro preguntas: Cul es el proceso bsico de la empresa? -Qu datos utiliza o produce este proceso?

-Cules son los lmites impuestos por el tiempo y la carga de trabajo? -Qu controles de desempeo utiliza? Estas preguntas tendrn respuesta considerando los siguientes puntos: 1. Comprensin del proceso: siempres se debe comenzar con lo bsico. Por lo regular los analistas hacen preguntas que cuando reciben respuestas proporcionan antecedentes de los detalles fundamentalesrelacionados con el sistema y sirvenpara describirlo. Las siguientes preguntas son de utilidad para adquirir la comprensin necesaria: -Cul es la finalidad de esta actividad dentro de la empresa? -Qu pasos se siguen para llevarla a cabo? -Dnde se realizan estos pasos? -Quin los realiza? -Cunto tiempo tardan en efectuarlos? -Con cunta frecuencia lo hacen? -Quines emplean la informacin resultante? Esta es la clase de respuestas que el analista debe hacer para cualquier sistema que estudie. Las respuestas a estas preguntas proporcionan un conocimiento amplio de todo lo relacionado con la actividad y muestra el objetivo del proceso. Estos resultados son los antecedentes que le permitirn al analista formular preguntas detalladas. 2. Identificacin de datos empleados e informacin generada: una vez terminada la comprensin del proceso es necesario detectar qu datos utiliza para llevar a cabo la actividad. Por otra parte, muchas transacciones del sistema producen informacin til para los gerentes y analistas dependiendo del contexto en que la ubique. 3. Frecuencia y volumen del proceso: la frecuencia es un elemento importante para conocer el tiempo entre una transaccin y otra dentro de la empresa. Por lo tanto los analistas deben investigar con cunta frecuencia se repite una actividad, eso le permite al analista considerar ms preguntas para determinar la razn de la frecuencia y su efecto sobre las operaciones o actividades de la empresa. sto es posible cuando se ha identificado el objetivo de la actividad, es decir, cul es la causa de la actividad?. Es indispensable que el analista determine la causa directa como la funcin de iniciacin de la actividad. Estas actividades pueden ser iniciadas por los clientes, por sucesos y por el tiempo. Un riesgo que corren los analistas es no comprender adecuadamente la razn de una actividad y darle mayor o menor importancia de la que tienen en el sistema, a menos de que conozca qu es lo que inicia la actividad. Existen actividades que tienen una duracin pequea o muy corta, otras ocurren con muy poca frecuencia, pero cuando se presentan pueden tomar bastante tiempo para finalizarla. Hay que considerar que el tiempo, como nico factor para llevar a cabo una actividad, no determina la importancia de sta, pero tiene un efecto en cmo el analista evala los diferentes pasos para realizarla.

La cantidad de pasos totales de que consta una actividad, puede generar problemas especiales para el estudio queefecta el analista an cuando la actividad ocurra con muy poca frecuencia. 4. Identificacin de controles: los controles son un elemento importante dentro del sistema, ya que de ellos depender conocer si la actividad se ha realizado en forma adecuada. Los analistas deben examinar los mtodos de control durante la etapa del anlisis, considerando las siguientes preguntas: -Existen estndares especficos de desempeo? -Quin se encarga de comparar el desempeo contra los estndares? -Cmo se detectan los errores? -Cmo se corrigen los errores? -Se cometen varios errores? La falta o debilidad de los controles son elementos importantes de considerar en una investigacin de sistemas. Requerimientos de las transacciones de los usuarios. Los sistemas a nivel de transacciones, capturan procesan y almacenan datos por alguna razn.Los analistas seleccionados para trabajar en un sistema de procesamiento transaccional, deben conocer todo lo relacionado con la forma en que se procesan estas transacciones. Para conocer y entender los requerimientos de las transacciones, los analistas sin lugar a dudas formulan preguntas como: -Qu es lo que forma parte de la transaccin que est siendo procesada? -Qu es lo que inicia la transaccin? -Quin inicia la transaccin? -Con qu propsito? -Con que frecuencia ocurre? -Qu volumen esta asociado a la transaccin? -Existen diferentes condiciones que pueden afectar la forma en que se procesan las transacciones? -Qu detalles son necesarios para procesar la transaccin? -Qu informacin se genera? -Qu datos se guardan? Estas preguntas deben ser consideradas, no sin antes haber determinado cul es la transaccin o transacciones principales de la organizacin. Hay que considerar que un sistema de procesamiento de transacciones debe cubrir los siguientes puntos: Bien estructuradas. Siguen rutinas definidas. Ocurren con frecuencia. -Son muy predecihies. Cambian con poca frecuencia. Presentan necesidades de datos muy estructurados. -Tratan con eventos reales

Capturan - Hacen hincapi en los detalles

procesan

datos

Requerimientos de decisin de los usuarios. A diferencia de las actividades de transaccin, las relacionadas con las decisiones no siguen un procedimiento especifico. Las rutinas no son muy claras y es posible que los controles sean vagos. Las decisiones se toman al integrar la informacin en forma tal que los gerentes saben qu acciones emprender. Muchos de los sistemas sobre decisiones deben comprender situaciones o decisiones pasadas, presentes y futuras o bien relacionarse con sucesos ocurridos en esos tiempos, algunos de estos sistemas brindan servicios a decisiones recurrentes, mientras que otros son menos recurrentes y nicos. Los sistemas sobre decisiones utilizan datos que se originan dentro de la empresa, como lo son aquellos que generan los sistemas transaccionales o bien datos que estn fuera de la organizacion. En algunos casos se procesan estos datos para la toma de decisiones. L.os analistas que investigan los sistemas para el soporte de las decisiones deben formular las mismas preguntas sobre frecuencia y volumen, pero debern considerar otras para determinar los requerimientos de las decisiones: -Que informacin se utiliza para tomar una decisin? -Cul es la fuente de ms informacin? -Qu sistema transaccional produce datos utilizados en el proceso de la decisin? -Qu otros datos son necesarios y no es posible obtener del proceso transaccional? -Que datos originan las fuentes externas a la organizacin? -Cmo se deben procesar los datos para producir informacin necesaria? -Cmo debe presentarse la infomacin? Estas preguntas reflejan la relacin entre los sistemas transaccionales y de las decisiones, esto significa que: - Los analistas que investigan sistemas para el soporte de decisiones deben considerar los sistemas de procesamiento de transacciones. - Que los sistemas eficaces para el soporte de las decisiones requieren primero de procedimientos adecuados para el procesamiento de transacciones. Requerimientos de la organizacin. Cuando los analistas estudian sistemas para u departamento tambin deben evaluar las implicaciones con los dems departamentos que intracta el sistema en investigacin. Algunas veces estos sistemas abarcan el trabajo de varios departamentos, por lo tanto es respinsabilidad del analista identificar las dependencias entre departamentos y determinar cmo los afectos de un proyecto. Esta actividad puede ser posible cuando el analista se auxilia de una herramienta como lo es el diagrama de flujo de datos.

ENFOQUE DEL FLUJO DE DATOS. El enfoque del flujo de datos tiene cuatro ventajas principales de la forma en que se mueven los datos a travs del sistema, estas son: 1. Libertad para realizar en forma muy temprana la implementacin tcnica del sistema. 2. Comprensin de las interrelaciones de los sistemas y subsistemas. 3. Comunicacin del conocimiento del sistema actual a los usuarios por medio del diagrama de flujo de datos. 4. Anlisis de un sistema propuesto para determinar si han sido definidos los datos y procesos necesarios. Los smbolos utilizados en el diagrama son: -Rectngulo: representa una entidad. -Flecha: representa el flujo de datos. -Rectngulo dividido horizontalmente: representa un proceso -Rectngulo dividido verticalmente sin el extremo derecho: representa almacenamiento de datos. 2.4 Herramientas de software para la determinacin de requerimientos Tres tipos de requerimientos.

Un requerimiento funcional puede ser una descripcin de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar. Un requerimiento no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cmo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc. Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuacin a leyes o regulaciones aplicables al producto

Una coleccin de requerimientos describe las caractersticas o atributos del sistema deseado. Se omite el cmo debe lograrse su implementacin, ya que esto debe ser decidido en la etapa de diseo por los diseadores. Herramientas para la determinacin de requerimientos

USO DE PROTOTIPOS. Un proceso interactivo del desarrollo de sistemas en el cual los requerimientos son convertidos en un sistema que trabaja, y que es continuamente revisado a travs de un trabajo conjunto entre un analista y los usuarios. JOINT APPLICATION DESIGN (JAD). Un proceso estructurado en el cual los usuarios, gerentes y analistas, trabajan juntos varios das en una serie de reuniones intensivas para especificar o revisar requerimientos de sistemas.

HERRAMIENTAS ENGINEERING).

CASE

(COMPUTER-AIDED

SOFTWARE

Uso de herramientas para la ingeniera de software asistida por computadora para aumentar la productividad, comunicarse ms efectivamente con los usuarios e integrar el trabajo que realizan los analistas en el sistema, desde el principio hasta el fin del ciclo de vida.

Unidad 3 Tcnicas para el anlisis de requerimientos 3.1 Tecnicas estructuradas para el analisis de requerimientos 3.1.1 Caractersticas del anlisis estructurado. Las tcnicas estructuradas utilizadas en el desarrollo de los Proyectos de Sistemas, buscaron superar el fracaso en muchos desarrollos convencionales. Los proyectos estructurados se caracterizan por mejores herramientas para expresar los requisitos del usuario, nfasis en el proyecto de calidad, sistemas de desarrollo top-down. CICLO DE VIDA ESTRUCTURADO

3.1.2 Especificacin formal de datos.

3.1.2.1 Diagrama de flujo y control de datos. El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre s por "conductos" y "tanques de almacenamiento" de datos. Siendo ste, una de las herramientas ms comnmente usadas, sobre todo por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son ms complejos que los datos que ste maneja. Es importante tener en mente: los DFD no slo se pueden utilizar para modelar sistemas de sistemas de proceso de informacin, sino tambin como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeacin estratgica y de negocios. Los componentes de un diagrama tpico de flujo de datos:

Proceso. Flujo. Almacn. Terminador.

Gua para la construccin de DFD. Adems de la regla bsica que existen para la elaboracin de DFD tal como, los componentes bsicos de DFD son: proceso(burbuja) flujo, almacenes y terminadores. Existen otras reglas adicionales que nos permitirn no elaborar DFD errneos y gratos a la vista de los usuarios. Las reglas incluyen las siguientes: 1. Escoger nombres con significado para los procesos, flujos, almacenes y terminadores. 2. Numerar los procesos. 3. Evitar los DFD excesivamente complejos 4. Redibujar el DFD tantas veces como sea necesario estticamente. 5. Asegurarse de que el DFD sea lgicamente consistente y que tambin sea con cualesquiera DFD relacionados con l. 6. Extensiones del DFD para sistemas de tiempo real 3.1.2.2 Diccionario de datos. Contiene las caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, alias, contenido y organizacin. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo. Razones para su utilizacin:

 Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de datos. Los sistemas al sufrir cambios continuos, es muy difcil manejar todos los detalles. Por eso se registra la informacin, ya sea sobre hoja de papel o usando procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseados especficamente para el anlisis y diseo de software. Para asignarle un solo significado a cada uno de los elementos y actividades del sistema. Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema y registrando detalles adicionales relacionadas con el flujo de datos en el sistema, de tal manera que todo pueda localizarse con rapidez. Para documentar las caractersticas del sistema, incluyendo partes o componentes as como los aspectos que los distinguen. Tambien es necesario saber bajo que circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren. Produciendo una comprensin mas completa. Una vez que las caractersticas estn articuladas y registradas, todos los participantes en el proyecto tendrn una fuente comn de informacin con respecto al sistema. Para facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas y determinar donde efectuar cambios en el sistema. Determina si son necesarias nuevas caractersticas o si estn en orden los cambios de cualquier tipo. Se abordan las caractersticas: * Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo mientras se emplea el sistema. * Preguntas: solicitudes para la recuperacin o procesamiento de informacin para generar una respuesta especifica. * Archivos y bases de datos: detalles de las transacciones y registros maestros que son de inters para la organizacin. * Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar transacciones y datos 5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un informe. Aun en los manuales, se revelan errores. Contenido de un registro del diccionario

El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los elementos datos y estructura de datos. Elemento dato: son los bloques bsicos para todos los dems datos del sistema, por si mismos no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos. Descripcin: Cada entrada en el diccionario consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema. Cada uno esta identificado con: Un nombre: para distinguir un dato de otro. Descripcin: indica lo que representa en el sistema. Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso este dato. Longitud: porque es de importancia de saber la cantidad de espacio necesario para cada dato. Valores de los datos: porque en algunos procesos solo son permitidos valores muy especficos para los datos. Si los valores de los datos estn restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario. Estructura de datos: es un grupo de datos que estn relacionados con otros y que en conjunto describen un componente del sistema. Descripcin: Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes combinaciones ya sea individualmente o en conjuncin con alguna otra. Relacin secuencial: define los componentes que siempre se incluyen en una estructura de datos. Relacin de seleccin: (uno u otro), define las alternativas para datos o estructuras de datos incluidos en una estructura de datos. Relacin de iteracin: (repetitiva), define la repeticin de un componente. Relacin opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteracin. Notacin Los analistas usan smbolos especiales con la finalidad de no usar demasiada cantidad de texto para la descripcin de las relaciones entre datos y mostrar

con claridad las relaciones estructurales. En algunos casos se emplean trminos diferentes para describir la misma entidad (alias) estos se representan con 3.1.3 Especificacin de procesos. 3.1.3.1 Lenguaje natural. 3.1.3.2 Lenguaje estructurado. El lenguaje estructurado se basa en: 1) la lgica estructurada, o en instrucciones que se organizan en procesos agrupados y cclicos; y en 2) planteamientos sencillos del idioma espaol tales como sumar, multiplicar, mover y otros similares. El ejemplo anterior de la Compaa de Seguros Fortress hace uso del lenguaje estructurado, esto lo podemos observar en la tabla 1. En ella se ordenan con una secuencia las reglas de decisiones y a todo lo largo se hace uso de la clusula (S - ENTONCES- DE LO CONTRARIO). TABLA 1: EJEMPLO DE LA COMPAIA DE SEGUROS FORTRESS Calcular la prima IF la construccin de tabique base THEN deducir 10 % del total ENDIF IF se elige la opcin de reemplazo THEN agregar 10% de la base al subtotal ENDIF IF el propietario elige un deducible de $100 THEN aumentar 15% del subtotal al total ENDIF IF la casa cuenta con alarma THEN deducir 5% del subtotal ajustado al subtotal ajustado ENDIF Con el fin de escribir en lenguaje estructurado, es conveniente apegarse a las siguientes convenciones:

1. Exprese toda la lgica, en trminos de estructuras secuenciales, estructuras de decisin, estructuras case (decisin mltiple) o iteraciones (como ejemplo, vase la figura 1). 2. Utilice y aproveche trminos tales como: IF, THEN, ELSE, DO, DO WHILE, DO UNTIL, y PERFORM (S, ENTOCES, DE LO CONTRARIO, EJECUTE, EJECUTE MIENTRAS, EJECUTE HASTA QUE y REALICE). 3. Para mostrar con claridad la jerarqua (anidando), utilice sangras en los bloques de proposiciones. 4. Cuando la palabra o frase utilizadas hayan sido definida en un diccionario de datos, destaque tales palabras o frases para indicar que tienen una connotacin reservada y especializada. 5. Sea cuidadoso cuando utilice los operadores lgicos "y" (and) y "o" (or), evitando la confusin al distinguir entre "mayor que" e "igual que" de relaciones similares. Aclare los planteamientos lgicos en el momento y no espere hasta la etapa de codificacin del programa. 3.1.3.3 Tablas de decisin. Una tabla de decisiones es una tabla de renglones y columnas que contiene cuatro cuadrantes.El cuadrante superior izquierdo contiene la condicin, el cuadrante superior derecho opciones a la condicin. La mitad inferior de la tabla contiene las acciones que se van a tomar (en el extremo izquierdo) y las reglas para ejecutar las acciones (en el derecho). Cuando una tabla de decisiones se utiliza para determinar las acciones que se llevaron a cabo, la lgica sigue el sentido del reloj, comenzando en el extremo superior izquierdo. TABLA DE DECISIONES Condiciones y acciones Reglas Condiciones Alternativas de la condicin Acciones Registro de las acciones Para construir tablas de decisin, el analista necesita definir el tamao mximo de la tabla, eliminar cualquier situacin imposible, inconsistencia o redundancia y simplificar la tabla mejor posible. Los siguientes pasos proveen al analista de un mtodo sistemtico para el desarrollo de tablas de decisiones: 1. Determine el nmero de condiciones que pudieran afectar la decisin. Combine renglones que se sobrepongan. El nmero de condiciones ser igual al nmero de renglones presentes en la mitad superior de la tabla de decisiones. 2. Determine el nmero de acciones posibles que puedan realizarse. Este ser igual al nmero de renglones de la parte inferior de la tabla de decisiones. 3. Determine el nmero de opciones para cada condicin. En la forma ms sencilla, habr dos alternativas (S o N) para cada condicin. En una tabla de tipo extendida, puede llegar a haber muchas opciones para cada condicin. 4. Calcule el nmero mximo de columnas de la tabla de decisiones multiplicando el nmero de alternativas para cada condicin. Si fueran

cuatro condiciones y dos alternativas (S o N) para cada una de las condiciones, habra diecisis posibilidades: Condicin 1: 2 alternativas Condicin 2: X 2 alternativas Condicin 3: X 2 alternativas Condicin 4: X 2 alternativas ---------------------- 16 posibilidades 1. Llene las alternativas de la condicin. Comience con la primera condicin y divida el nmero de columnas con el nmero de alternativas para tal condicin. En el ejemplo, al haber 16 columnas y 2 opciones (S y N), 16 entre 2, 8. Luego, elija una de las opciones y escriba S en cada una de las 8 columnas. Concluya anotando N en las 8 columnas restantes, tal y como sigue: Condicin 1 SSSSSSSNNNNNNNN Repita lo anterior para cada una de las condiciones, utilizando un subconjunto de la tabla: Condicin 1 SSSSSSSSNNNNNNNN Condicin 2 SSSSNNNN Condicin 3 SSNN Condicin 4 SN Y contine el patrn para cada condicin: Condicin 1 SSSSSSSSNNNNNNNN Condicin 2 SSSSNNNNSSSSNNNN Condicin 3 SSNNSSNNSSNNSSNN Condicin 4 SNSNSNSNSNSNSNSN 1. Concluya la tabla insertando una X donde las reglas sugieran cierta accin. 2. Combine las reglas donde se aparenta que una alternativa no implique diferencias en la salida; por ejemplo: Condicin 1 S S Condicin 2 S N --------------------------------- Accin 1 X X lo cual puede expresarse como: Condicin 1 S Condicin 2 __ ------------------------------------ Accin 1 X El guin ( __ ) significa que la condicin 2 puede ser S o N y la accin an as podr llevarse a cabo. 1. Verifique la tabla para situaciones imposibles, contradicciones y redundancias. 2. Vuelva arreglar las condiciones y las acciones (o an las reglas) si esto redunda en una mayor compresin. La tabla 1 es un ejemplo de una tabla de decisiones que se desarroll por medio de los pasos planteados con anterioridad. En este ejemplo una compaa intenta mantener una significativa lista de correos de sus clientes. El objetivo es enviar catlogos a aquellos clientes que adquiran mercanca.

TABLA 1: EJEMPLO DE UNA TABLA DE DECISIONES Condiciones y acciones Reglas 12345678 SSSSNNNN

El cliente ordena del catlogo de otoo

El cliente ordena del catlogo de invierno S S N N S S N N El cliente ordena del catlogo especial SNSNSNSN Envo del catlogo de Navidad de este ao X X X X Envo del catlogo especial Envo de ambos catlogos XX XX

La tabla de decisiones contempla tres condiciones (C1: clientes que ordenan del catlogo de otoo, C2: clientes que ordenan del catlogo de Navidad y C3: clientes que ordenan del catlogo de especialidades). Cada uno de ello tiene dos opciones (S o N). Hay tres acciones que realizar: A1:enviar el catlogo de navidad del presente ao; A2: enviar el nuevo catlogo de especialidades; A3: enviar ambos catlogos. La tabla de decisiones se examinar para ver si es posible reducirla. Es posible combinar algunas de las reglas, tal y como se muestra en la figura3. Las reglas 2, 4, 6, y 8 pueden combinarse, ya que todas ellas tienen dos cosas en comn: 1. Nos indica que enviemos el catlogo de Navidad para este ao (accin 1) 2. La opcin para la condicin 3 siempre es N. TABLA 2:TABLA REDUCIDA Condiciones y acciones

Reglas 1' 2' 3' ---

El cliente ordena del catlogo de otoo

El cliente ordena del catlogo de invierno S - El cliente ordena del catlogo especial SNN Envo del catlogo de Navidad de este ao X Envo del catlogo especial Envo de ambos catlogos X X

Es esencial certificar la integridad y la precisin de las tablas de decisiones. En el desarrollo de las tablas de decisiones se pueden presentar cuatro problemas principales: tablas incompletas, situaciones imposibles, contradicciones y redundancias.

Un ejemplo de una situacin imposible se muestra en la tabla 5.3.3. La regla 1 no es factible, ya que una persona no puede ganar ms de $50.00 por ao y menos de $2.00 al mismo tiempo. TABLA 3:EJEMPLO DE UNA SITUACION IMPOSIBLE Condiciones y acciones Reglas 1234 SSNN SNSN

Salario > $50.00/ao Salario<$2.00/mes Accin 1 Accin 2

Figura 4: Ejemplo de una tabla de decisiones imposible. Las contradicciones se presentan cuando las reglas sugieren acciones distintas, pero satisfacen las mismas condiciones. Las contradicciones ocurren con frecuencia si los guiones (--) se insertan de manera incorrecta en la tabla. La redundancia ocurre cuando un conjunto idntico de alternativas requieren exactamente de la misma accin. 3.1.3.4 rboles de decisin. Cuando un proceso de decisin estructurada se integra con ramificaciones complejas, entonces se hace uso de los rboles de decisiones. Los rboles de decisiones se dibujan sobre un plano horizontal, con la raz del rbol al lado izquierdo del papel y las ramas hacia la derecha. Esto permite al analista describir las condiciones de acciones sobre las ramas. Cuando se dibujan los rboles de decisiones es til distinguir entre las condiciones y las acciones. Para este propsito, el uso de un nodo cuadrado indica una accin y un crculo representa una condicin, tal y como se representa en la figura 1. El uso de esta notacin hace ms accesible el rbol de decisiones s uno piensa que un crculo significa IF (SI), mientras que cuadrado significa THEN (ENTONCES).

Figura 1: rbol de decisiones

El rbol de decisiones tiene tres ventajas principales sobre la tabla de decisiones: Primera , es que toma las ventajas de la estructura consecutiva de las ramas del rbol de decisiones, de tal forma que se identifican de manera inmediata el orden de verificacin de las condiciones y las acciones que se deben llevar a cabo. Segundo , las condiciones y acciones del rbol de decisiones se encuentran en ciertas ramas pero no en otras, a diferencia de las tablas de decisiones, donde todas forman parte de la misma tabla. Tercero , al compararse con las tablas los rboles de decisiones se entienden con ms facilidad en una organizacin y son apropiados como un mtodo de comunicacin.

3.2 Tecnicas Orientadas a Objetos para Analisis de Requerimientos

Introduccin. Modelo de Objetos: captura la estructura esttica del sistema, mostrando:

objetos relaciones entre objetos atributos operaciones

Es el ms importante, puesto que el sistema se construye alrededor de los objetos. Conceptos, notacin y ejemplos. Objetos y clases. Objeto:

Concepto, abstraccin o cosa con fronteras definidas y significado para nuestro problema. Permite una mejor comprensin del mundo y proporciona la base para una implementacin sobre el ordenador. No existe una representacin exacta. Todos los objetos tienen una identidad y son distinguibles.

Clase:

Describe grupos de objetos con propiedades (atributos) similares, comportamiento (operaciones) comunes, relaciones con otros objetos y semntica comn. Cada objeto sabe cul es su clase, ya que es una instancia de la misma.

Elemento esencial para la abstraccin y generalizacin. Diagrama de objetos. Notacin grfica para modelar los objetos, clases y sus relaciones. Dos clase de diagramas:

de clases de objetos (instancias)

Diagrama de clases: esquema, patrn o plantilla para describir muchos casos posibles de datos. Describe clases de objetos. Diagrama de objetos: describe cmo se relacionan un grupo particular de objetos entre s. Notacin de clases y objetos.

3.2.2 Especificacin formal de objetos. 3.2.2.1 Casos de uso. Los casos de uso representan requisitos funcionales del sistema. Se describen como conjuntos de secuencias. Cada una de estas secuencias refleja la interaccin entre los elementos externos al sistema y el propio sistema (se trata de la descripcin de escenarios o situaciones posibles donde se pone de relieve el comportamiento del sistema ante su uso por parte del usuario). As pues, los objetivos principales de la realizacin de casos de uso son: Definir el lmite entre el sistema a desarrollar y los elementos externos a ese sistema (actores usuarios del sistema). Capturar el conjunto de funcionalidades y comportamientos del sistema a desarrollar.

Cada caso de uso se documenta mediante una representacin grfica y un texto con la descripcin de las situaciones o escenarios ante los que el usuario se pueda encontrar en su interaccin con el sistema. En el modelado de casos de uso debemos tener en cuenta dos conceptos bsicos: Actores. Los actores pueden ser personas, software o hardware; el trmino actor representa el rol genrico de usuario del sistema. El nombre que se le d a un actor deber reflejar el papel que tendr para el sistema. Identificar los actores nos permite: Definir los lmites del sistema (qu forma parte del sistema y qu no). Desarrollar un sistema orientado al usuario que contemple todas las funcionalidades esperadas por los diferentes actores. Casos de uso. Reflejan el uso que harn los actores del sistema; se muestran a travs de ellos tanto las funcionalidades que ofrecer el sistema, como los diferentes comportamientos posibles inherentes a las situaciones contempladas para cada una de estas. Los casos de uso se escriben con el fin de expresar lo que debe hacer el sistema a desarrollar, sin tener en cuenta cmo debe hacerlo. Diagramas de casos de uso. Los casos de uso pueden estar relacionados con actores o con otros casos de uso; grficamente una relacin vendr dada por una lnea entre los casos de uso y/o actores relacionados, siendo que el extremo de dicha lnea depender del tipo de relacin; en principio tenemos cuatro tipos posibles: Comunicacin (relacin entre un actor y un caso de uso con el que interacta; se representa smplemente con una lnea). Uso (include, includes, uses; se representa por una flecha apuntando en el sentido de la relacin). Extensin (extend, extends; grficamente la representacin es la misma que para "uso"). Generalizacin (se trata del concepto de herencia, habitual en los diagramas de clases, pero aplicado entre casos de uso, e incluso entre actores; se representa por una flecha con un tringulo vaco por punta sealando en el sentido de la relacin).

Por ahora nos centraremos en las relaciones de uso y extensin . Relacin << include >> . Es una simple relacin de inclusin, es decir, los escenarios o situaciones posibles detalladas en un caso de uso estn incluidas en otro caso de uso (aquel del que, grficamente, parte la flecha). Relacin << extend >> . Este tipo de relacin refleja situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro. En la descripcin del caso de uso que es extendido debe haber una forma de indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensin); esto se representa mediante una "etiqueta" (un texto significativo entre parntesis) como referencia del lugar donde entrara a formar parte del caso de uso extendido. Una vez expuestos los principales tipos de relacin que vamos a encontrar en los diagramas de casos de uso es buen momento para hacer referencia a la descripcin que acompaa a cada caso de uso. Hasta aqu hemos tenido en cuenta principalmente la representacin grfica, sin embargo, aparte de esta, un diagrama de casos de uso llevar asociada una descripcin textual, en forma de flujos de eventos , de cada caso de uso representado. Surgen aqu dos tipos de apartado a tener en consideracin: Flujo de eventos principal Se trata de una descripcin de los eventos que van aconteciendo en el uso habitual, es decir, cuando no se presenta ningn tipo de problema (es el denominado happy path). Flujo de eventos excepcional Podemos encontrar tantos apartados de este tipo como situaciones excepcionales se puedan plantear, siendo que para cada uno de estos escenarios atpicos se definir el flujo de eventos correspondiente. 3.2.2.3 Definicin de atributos. Los atributos presentan las siguientes caractersticas: Valor de un dato dentro de un objeto. Cada atributo tiene un valor para cada objeto. El nombre de un atributo es nico dentro de una clase. Debera ser un dato puro', no un objeto (no tiene identidad): si un objeto necesita otro objeto habr que modelarlo como asociacin.

Adems del nombre podemos especificar el Tipo y el Valor por defecto. Los identificadores de objetos explcitos no se necesitan en el Modelo de Objetos. Notacin de atributos.

3.2.2.4 Definicin de servicios. Operaciones y Mtodos. Funcin o transformacin que se aplica a' o por' los objetos en una clase. Tienen un objeto destino como argumento implcito (el objeto actual). Polimorfismo: la misma operacin puede aplicarse a clases diferentes dentro de una jerarqua de herencia. Mtodo: implementacin de una operacin para una clase. Las operaciones con mtodos en varias clases deben compartir la misma signatura (tipos de sus argumentos y valor que devuelven). Notacin de Operaciones y Mtodos.

3.2.3 Prototipos Rapidos en determinacion de Requerimientos

3.3 Tecnicas Basadas en Componentes Diseo de Componentes Un componente es un grupo de objetos o componentes ms pequeos que interaccionan entre ellos y se combinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios del componente se especifican por su interface o interfaces, sin ofrecer concimiento del diseo e implementacin internas del componente. El desarrollo basado en componentes es el proceso de ensamblar la combinacin correcta de componentes en la configuracin correcta para llevar acabo la funcionalidad deseada para un sistema. Los componenetes se representan en el diagrama de clases de UML especificando la interfaz de una clase o paquete. Hay dos notaciones para mostrar una interfaz - una es mostrar la interfaz como una 'regular class symbol' con el estereotipo "interfz", con una lista de operaciones soportadas por esta interfaz, detalladas en el 'operation department' (departamento de operacin). 'The alternate, shortcut notation' es mostrar la interfaz como un circulo pequeo junto con la clase con una lnea slida, con el nombre de la interfaz en el crculo. El ejemplo de la Figura 9 muestra que la clase 'Pasajero' ofrece la operacin move(x coord, y coord) para su apariencia en un GUI, a travs de su interfaz 'Displayable'. Ambas notaciones UML de interfaz, se muestran en la figura. Adems, la clase Pasajero tambin ofrece una opcin save(store at) a travs de su interfaz Persistente. Una clase de o componente para conectar con una base de datos podra usar esta interfaz.

Figura 9: Diseo de Componentes: Especificando la Interfaz de la Clase

3.3.1 Ingenieria del Dominio 3.1 TCNICAS ESTRUCTURADAS PARA EL ANLISIS DE REQUERIMIENTOSLas tcnicas son un mtodo que aplica herramientas y reglas especficas para completar una o ms fases del ciclo de vida del desarrollo de Sistemas. Las tcnicas estructuradas utilizadas en el desarrollo de los Proyectos de Sistemas, buscaron superar el fracaso en muchos desarrollos convencionales, como son las siguientes tcnicas: Y Anlisis estructurado y Diseo estructurado Y Programacin estructurada y Desarrollo TOP-DOWN y Equipos de programacin Y Revisiones estructuradas ANALISIS ESTRUCTURADO El Anlisis se refiere al "extremo inicial" de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados. El Anlisis estructurado introduce el uso de las herramientas de documentacin grficas para producir un tipo diferente de especificacin funcional: "la especificacin estructurada". Herramientas de documentacin del Anlisis Estructurado Y Diagramas de flujo de datos (DFDs) y Diccionario de Datos (DD) y Diagramas de Entidad-Relacin (ER) Y Diagramas de Transicin de Estado (DTEs) y Especificaciones de procesos .DISEO ESTRUCTURADO Durante el desarrollo se determinan "qu mdulos, interconectados de qu forma, solucionarn mejor un problema definido. Elementos del Diseo Estructurado: y Tcnicas de documentacin y Criterios de evaluacin del Diseo y Heursticas del diseo y Estrategias del Diseo DESARROLLO TOP-DOWN Es una estrategia de proyecto que divide sucesivamente los problemas grandes y complejos en problemas menores y menos complejos, hasta 3.3.2 Identificacion Clasificacion Componentes Reutilizables Tamao El tamao de los componentes puede ser medido por medio de las mtricas utilizadas en diseo orientado a objetos. Esto significa que la medicin del tamao de un componente puede ser medido a travs de: Lneas de Cdigo (LDC) Orientadas a Funcin Complejidad En algunas ocasiones, son utilizadas mtricas de tamao para evaluar la complejidad, pero es recomendable hacer uso de otro tipo de mtricas. Si un componente es demasiado trivial no podr sacrsele mayor provecho en su reutilizacin, y si el componente es demasiado complejo ser difcil asegurar su

calidad. Mtricas de Complejidad

Complejidad Ciclomtica, este mtodo mide el nmero de decisiones lgicas en un segmento de cdigo: CPC (Component Plain Complexity): Mide la complejidad del componente por medio de la suma de clases, clases abstractas e interfaces, la complejidad de clases y mtodos. CSC (Component Static Complexity): Se centra en la estructura interna del componente por medio de una visin esttica del mismo, utilizando variables como la relacin entre las clases y el peso e cada relacin. CDC (Component Dynamic Complexity): Se centra en el nmero de mensajes que pasan dentro del componente por medio de una visin dinmica, evaluando variables como la frecuencia en el intercambio de mensajes entre clases y la complejidad de los mensajes. CCC (Component Cyclomatic Complexity): Esta medida de complejidad es utilizada cuando el componente ya ha sido finalizado. Utiliza como variables el cdigo desarrollado, la suma de las clases, interfaces, mtodos definidos en cada una de las interfaces. Mantenibilidad La Mantenibilidad de un sistema es la facilidad con la cual puede ser modificado frente a cambios en el ambiente, requerimientos funcionales o especificaciones funcionales. Reusabilidad La reusabilidad de un componente se puede medir a partir de dos diferentes perspectivas, estas son: Cmo puede un componente ser reutilizado: Este tipo de medida tiene en cuenta las siguientes variables: El nmero de cada mtodo de interface que puede proveer funciones en comn entre varias aplicaciones en un dominio, el nmero de mtodos declarados en la interface que pertenecen al componente. Cmo es re - usado un componente en una aplicacin particular: Las variables que se miden para este objetivo en particular son: Las lneas de cdigo re - utilizadas por el componente en una aplicacin, el total de lneas entregados en la aplicacin. La combinacin de estas dos variables resulta el porcentaje de funcionalidad que aporta el componente dentro de toda la aplicacin Frecuencia de reuso El nmero de veces que ha sido utilizado un componente dentro de distintas aplicaciones, es sin lugar a dudas el mejor indicador de frecuencia de re uso. Cabe anotar que este atributo puede ser solo medido en componentes que ya han sido expuestos al mercado. Confiabilidad

Es la probabilidad de fall en el funcionamiento del componente dentro de cierto escenario operacional.

3.3.3 Caracterizacion de Componentes Caracterizacin de los componentes: Identificable: Debe tener una identificacin que permita acceder fcilmente a sus servicios y que permita su clasificacin. Auto contenido: Un componente no debe requerir de la utilizacin de otros para finiquitar la funcin para la cual fue diseado. Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore. Con acceso solamente a travs de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementacin. Sus servicios no varan: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementacin s. Bien Documentado:

Un componente debe estar correctamente documentado para facilitar su bsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc. Es Sus genrico: aplicaciones. mente: aplicacin. plataforma:

servicios

debe

servir

para

varias

Reutilizado Puede ser

cargado

en

dinmica tiempo de ejecucin de la

en

una

Independiente Hardware, Software, S.O. Caracterizacin de

los

componentes

requerimientos

Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

 Completo: Un requerimiento esta completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la Informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas

3.4

Otras

tcnicas

El desarrollo de un sistema de informacin, independientemente de su tamao y complejidad, requiere muchas actividades coordinadas y el empleo de una diversidad de herramientas y modelos. La metodologa de desarrollo de sistemas es una forma estndar de organizar y coordinar estas actividades. El anlisis de sistemas llega a la raz del problema o a la necesidad y define los requerimientos de los usuarios. Prototipeo: Prototipo de requerimientos: En este caso se comienza con una serie de requerimientos iniciales los cuales se van modificando de acuerdo a lo que el usuario necesite, para posteriormente para a construir el producto de software Prototipo de Interfaz de usuario: Para este caso se elaboran las ventanas principales del producto, para posteriormente ser mostradas al usuario, y que este a su vez realice las modificaciones que crea convenientes. Tambin observamos lo relacionado a los enfoques de prototipaje: Prototipo desechable: Es una especie de muestra, que nos sirve para probar determinados requerimientos, pero la caracterstica de este enfoque, es que no puede ser transformado en el producto final. Prototipo Evolutivo: Este prototipo trabaja sobre el sistema final en donde se va a implantar el producto de software, tambin este prototipo se va mejorando de la mano del usuario y desarrollador, hasta llegar a obtener el producto final.

Unidad 4 Mtricas para la evaluacin del anlisis 4.1 Metricas Modelo de Analisis

4.1.1 Mtricas basadas en la funcin. 4.1.2 La mtrica bang. Estas ayudan a evaluar el anlisis y diseo, proporcionan medidas de la complejidad, y ayudan a disear pruebas ms efectivas. Estas mtricas se dividen en : Medidas del anlisis, medidas de especificacin, medidas de diseo. 4.1.3 Mtricas de la calidad de la especificacin. El concepto de mtrica es el trmino que describe muchos y muy variados casos de medicin Siendo una mtrica una medida estadstica (no cuantitativa como en otras disciplinas ejemplo fsica ) que se aplica a todos los aspectos de calidad de software , los cuales deben ser medidos desde diferentes puntos de vista como el anlisis , construccin , funcional, documentacin , mtodos , proceso, usuario, entre otros. Para iniciar los elementos de medicin, para nuestro caso se desarrollan tres diferentes tipos de medicin, mtricas tcnicas , mtricas Bang y mtricas de punto de funcin . Mtricas Tcnicas . Estas se presentan en el libro de Ingeniera del software de Pressman pgina 58. Estas mtricas se derivan de una relacin emprica segn las medidas contables del dominio de informacin del software y de evaluaciones de complejidad. Ejemplo, Nmero de entradas usuario cada una de las entradas de datos . Nmero de salidas usuario cada una de las salidas de datos . Nmero de peticiones usuario cada generacin de un evento. Nmero de archivos cada tabla, archivo , Nmero de interfaces externas son interfaces, discos, copias de seguridad , transmisiones de datos. Estas mtricas poseen un modelo de valoracin entre cero (0) y cinco (5), y por decisin del equipo de trabajo, se puede asumir una valoracin en porcentajes como se muestra en la tabla siguiente as : 0 1 2 3 4 5 No influencia Ninguna Incidental Insignificante Moderado Moderada Medio Media Significativo Significativa Esencial Fuerte 0% 1 - 20% 21 - 40% 41 60% 61 80% 81 100% 0 10% 11 20% 21 30% 31 40% 41 50% > 50%

Esta valoracin es usada para calificar 15 puntos de evaluacin : 1. Facilidad de operacin. Valoracin 0 12 34 5 Pregunta: Requiere el sistema copias de seguridad y de recuperacin fiables? No se especifican por parte del usuario consideraciones especficas de operacin. Se requieren, proporcionan y prueban procesos de arranque, backup y recuperacin. Adems la aplicacin minimiza la necesidad de actividades manuales , tales como instalacin de cintas y papel . La aplicacin se disea para operacin sin atencin .

1. Comunicacin de los datos . Los datos o informacin de control que la aplicacin utiliza se enva o recibe a travs de las facilidades de comunicacin . Valoracin 0 12 35 3 5 Pregunta: Se requiere de comunicacin de datos? Aplicacin es batch exclusivamente Impresin o entrada de datos remota Teleproceso (TP) interactivo TP interfaces a un proceso batch La aplicacin es interactiva predominantemente

1. Funcin distribuida . "Distribuida" significa que los componentes (o los datos) de la aplicacin estn distribuidos en dos o ms procesadores diferentes (esto incrementa el factor anterior). Valoracin 0 Pregunta: Existen funciones de procesamiento distribuido? La aplicacin no ayuda a la transferencia de datos o a la funcin de procesamiento entro los componentes del sistema . La aplicacin prepara datos para el usuario final de otro procesador . Los datos se preparan para transferencia, se transfieren y se procesan en otro componente del sistema. Las funciones de procesamiento se realizan dinmicamente en el componente ms apropiado del sistema.

1 24 5

1. Rendimiento . Referido a la importancia de respuesta dentro de todo el sistema. Valoracin 03 Pregunta: Es crtico el rendimiento? Anlisis y diseo de las consideraciones del rendimiento son estndar. No se precisan requerimientos especiales por

4 5

parte del usuario. En la fase de diseo se incluyen tareas del anlisis del rendimiento para cumplir los requerimientos del usuario. Adems se utilizan herramientas de anlisis del rendimiento en el diseo, desarrollo e instalacin. 1. Configuracin utilizada masivamente . Referente a la importancia del entorno. Esto es, si hay restricciones de memoria o del hardware .

Valoracin 03 4 5

Pregunta: Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? La aplicacin corre en una maquina estndar sin restricciones de operacin. Restricciones de operacin requieren caracter sticas especficas de la aplicacin en el procesador central. Adems hay restricciones especficas a la aplicacin en los componentes distribuidos del sistema.

1. Tasas de transaccin . Una alta llegada de transacciones provoca problemas ms all de los de las caracter sticas. Valoracin 03 4 5 Pregunta : Las tasas son tales que las consideraciones de anlisis de rendimiento son estndares. En la fase de diseo se incluyen tareas de anlisis de rendimiento para verificar las altas tasas de transacciones. Adems se utilizan herramientas de anlisis del rendimiento.

1. Entrada de datos On-line . Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones ? Valoracin 02 34 5 Pregunta: Requiere el sistema entrada de datos interactiva? Hasta el 15% de las transacciones tienen entrada interactiva. 15% al 30% tienen entrada interactiva. 30% al 50% tienen entrada interactiva.

1. Diseo para la eficiencia de usuario final . Valoracin 03 4 5 Pregunta : No se especifican requerimientos especiales Se incluyen tareas de diseo para la consideracin de factores humanos Adems se utilizan herramientas especiales o de prototipado para promover la eficiencia .

1. Actualizacin on-line . Valoracin 0 12 3 4 5 Pregunta: Se actualizan los archivos maestros de forma interactiva? Nada Actualizacin on-line de los archivos de control . El volumen de actualizacin es bajo y la recuperacin fcil. Actualizacin on-line de la mayora de los archivos internos lgicos. Adems es esencial la proteccin contra la prdida de datos. Adems se considera el costo de recuperacin de volmenes elevados.

1. Complejidad del procesamiento . Esto es, complejidad interna ms all de la media en lo referente a la entrada, salida o lgica de procesamiento. Qu caractersticas tiene la aplicacin? Mucho procesamiento matemtico y lgico Procesamiento complejo de las entradas Procesamiento complejo de las salidas Muchas excepciones de procesamiento, muchas transacciones incompletas y mucho procesamiento de las transacciones. Procesamiento de seguridad y/o control sensitivo. Valoracin Pregunta: Son complejas las entradas, las salidas, los archivos o las peticiones? y Es complejo el procesamiento interno? No aplica nada de esto Se aplica algn elemento. Se aplican dos elementos. Se aplican tres elementos. Se aplican cuatro elementos. Se aplica todo.

0 1 2 3 4 5

1. Utilizable en otras aplicaciones . El cdigo se disea para que sea compartido o utilizable por otras aplicaciones. Valoracin 01 2-3 Pregunta: Se ha diseado el cdigo para ser reutilizado? Una aplicacin local que responde a las necesidades de una organizacin usuaria. La aplicacin utiliza o produce mdulos comunes que consideran ms necesidades que las del usuario.

45

Adems, la aplicacin se "empaqueto" y documento con el propsito del fcil reutilizacin.

1. 1. Facilidad de instalacin. 2. puestos mltiples Valoracin 01 23 Pregunta: Estn incluidas en el diseo la conversin y la instalacin? No se requieren por parte del usuario facilidades especiales de conversin e instalacin. Los requerimientos de conversin e instalacin fueron descritos por el usuario y se proporcionaron guas de conversin e instalacin. Adems se proporcionaron y probaron herramientas de conversin e instalacin.

45

1. 1. Puestos mltiples . Valoracin 0 13 45 Valoracin 0 13 45 Pregunta: Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario? El usuario no requiere la consideracin de ms de un puesto. Se incluyeron necesidades de varios puestos en el diseo. Se proporciona documentacin y plan de apoyo para soportar la aplicacin en varios lugares. Pregunta: Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones ? No hay requerimientos especiales del usuario para minimizar o facilitar el cambio . Se proporciona capacidad de consulta flexible Datos importantes de control se mantienen en tablas que son actualizadas por el usuario a travs de procesos on-line interactivos.

1. 1. Facilidad de Cambio . Esfuerzo especifico de diseo para facilitar cambios futuros. Estas valoraciones dadas a cada uno de estos puntos permiten aproximar una medida del sistema a travs de la siguiente ecuacin: PF = Cuenta_total * [0,65 + 0,01*?(Fi)], cuenta total es la valoracin para cada uno de las preguntas, y la sumatoria representa el total generado por toda la valoracin.

4.1.1 Metricas Basadas en Funcion 4.1.1 Mtricas basadas en la funcin La mtrica de punto de funcin (PF) se puede usar como medio para predecir el tamao de un sistema que se va a obtener de un modelo de anlisis. Para instruir el empleo de la mtrica PF. En donde se representa un diagrama de flujo de datos, de una funcin de una aplicacin de software llamada Hogar Seguro. La funcin administra la interaccin con el usurario, aceptando una contrasea de usuario para activar/ desactivar el sistema y permitiendo consultas sobre el estado de las zonas de seguridad y varios censores de seguridad. La funcin muestra una serie de mensajes de peticin y enva seales apropiadas de control a varios componentes del sistema de seguridad. El diagrama de flujo de datos se evala para determinar las medidas claves necesarias para el clculo de al mtrica de PF.: -nmero de entradas de usuario -nmero -nmero -nmero -nmero de de salidas consultas de de interfaces de del usuario usuario archivos externas

Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del programa. Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un acercamiento a la medida de la productividad denominado mtodo del punto de funcin. Los puntos de funcin que obtienen utilizando una funcin emprica basando en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivos de la complejidad del software. Los puntos de funcin se calculan rellenando la tabla como se muestra en la siguiente figura: Calculo de mtricas de punto de funcin.

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada de la tabla. Los valores del mbito de informacin estn definidos de la siguiente manera.

1. Nmeros de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicacin. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado. 2. Numero de salida del usuario: se encuentra cada salida que proporciona la usuario informacin orientada ala aplicacin. En este contexto las salidas se refieren a informes, pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe se encuentran por separado. 3. Nmeros de peticiones al usuario: una peticin esta definida como una entrada interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva. Se cuenta cada peticin por separado. 4. Numero de archivos: se cuenta cada archivo maestro lgico, o sea una agrupacin lgica de datos que puede ser una parte en una gran base de datos o un archivo independiente. 5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir informacin a otro sistema.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetivo. Para calcular los puntos de funcin se utiliza la siguiente relacin. PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]

4.1.2 La Metrica Bang Estas ayudan a evaluar el anlisis y diseo, proporcionan medidas de la complejidad, y ayudan a disear pruebas ms efectivas. Estas mtricas se dividen en: Medidas del anlisis, medidas de especificacin, medidas de diseo. 4.1.3 Mtricas de la calidad de la especificacin. El concepto de mtrica es el trmino que describe muchos y muy variados casos de medicin. Siendo una mtrica una medida estadstica (no cuantitativa como en otras disciplinas ejemplo fsic ) que se aplica a todos los aspectos de calidad de software , los cuales deben ser medidos desde diferentes puntos de vista como el anlisis , construccin , funcional, documentacin , mtodos , proceso, usuario, entre otros. Para iniciar los elementos de medici , para nuestro caso se desarrollan tres diferentes tipos de medicin, mtricas tcnicas , mtricas Bang y mtricas de punto de funcin .

Mtricas Tcnicas . Estas se presentan en el libro de Ingeniera del software de Pressman pgina 58. Estas mtricas se derivan de una relacin emprica segn las medidas contables del dominio de informacin del software y de evaluaciones de complejidad. Ejemplo, Nmero de entradas usuario cada una de las entradas de datos. Nmero de salidas usuario cada una de las salidas de datos. Nmero de peticiones usuario cada generacin de un evento. Nmero de archivos cada tabla, archivo, Nmero de interfaces externas son interfaces, discos, copias de seguridad , transmisiones de datos. Estas mtricas poseen un modelo de valoracin entre cero (0) y cinco (5), y por decisin del equipo de trabajo, se puede asumir una valoracin en porcentajes como se muestra en la tabla siguiente as : 0 1 2 3 4 5 No influencia Ninguna Incidental Insignificante Moderado Moderada Medio Media Significativo Significativa Esencial Fuerte 0% 1 - 20% 21 - 40% 41 60% 61 80% 81 100% 0 10% 11 20% 21 30% 31 40% 41 50% > 50%

Esta valoracin es usada para calificar 15 puntos de evaluacin: 1. Facilidad de operacin. Valoracin 0 12 34 5 Pregunta: Requiere el sistema copias de seguridad y de recuperacin fiables? No se especifican por parte del usuario consideraciones especficas de operacin. Se requieren, proporcionan y prueban procesos de arranque, backup y recuperacin. Adems la aplicacin minimiza la necesidad de actividades manuales, tales como instalacin de cintas y papel. La aplicacin se disea para operacin sin atencin.

1. Comunicacin de los datos. Los datos o informacin de control que la aplicacin utiliza se enva o recibe a travs de las facilidades de comunicacin. Valoracin 0 Pregunta: Se requiere de comunicacin de datos? Aplicacin es batch exclusivamente

12 35 3 5

Impresin o entrada de datos remota Teleproceso (TP) interactivo TP interfaces a un proceso batch La aplicacin es interactiva predominantemente

1. Funcin distribuida . "Distribuida" significa que los componentes (o los datos) de la aplicacin estn distribuidos en dos o ms procesadores diferentes (esto incrementa el factor anterior). Valoracin 0 Pregunta: Existen funciones de procesamiento distribuido? La aplicacin no ayuda a la transferencia de datos o a la funcin de procesamiento entro los componentes del sistema . La aplicacin prepara datos para el usuario final de otro procesador . Los datos se preparan para transferencia, se transfieren y se procesan en otro componente del sistema. Las funciones de procesamiento se realizan dinmicamente en el componente ms apropiado del sistema.

1 24 5

1. Rendimiento Referido a la importancia de respuesta dentro de todo el sistema. Valoracin 03 Pregunta: Es crtico el rendimiento? Anlisis y diseo de las consideraciones del rendimiento son estndar. No se precisan requerimientos especiales por parte del usuario. En la fase de diseo se incluyen tareas del anlisis del rendimiento para cumplir los requerimientos del usuario. Adems se utilizan herramientas de anlisis del rendimiento en el diseo, desarrollo e instalacin.

4 5

1. Configuracin utilizada masivamente . Referente a la importancia del entorno. Esto es, si hay restricciones de memoria o del hardware . Valoracin 03 4 5 Pregunta: Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? La aplicacin corre en una maquina estndar sin restricciones de operacin. Restricciones de operacin requieren caracter sticas especficas de la aplicacin en el procesador central. Adems hay restricciones especficas a la aplicacin en los componentes distribuidos del sistema.

1. Tasas de transaccin . Una alta llegada de transacciones provoca problemas ms all de los de las caracter sticas.

Valoracin 03 4 5

Pregunta : Las tasas son tales que las consideraciones de anlisis de rendimiento son estndares. En la fase de diseo se incluyen tareas de anlisis de rendimiento para verificar las altas tasas de transacciones. Adems se utilizan herramientas de anlisis del rendimiento.

1. Entrada de datos On-line . Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones ? Valoracin 02 34 5 Pregunta: Requiere el sistema entrada de datos interactiva? Hasta el 15% de las transacciones tienen entrada interactiva. 15% al 30% tienen entrada interactiva. 30% al 50% tienen entrada interactiva.

1. Diseo para la eficiencia de usuario final . Valoracin 03 4 5 Pregunta : No se especifican requerimientos especiales Se incluyen tareas de diseo para la consideracin de factores humanos Adems se utilizan herramientas especiales o de prototipado para promover la eficiencia .

1. Actualizacin on-line . Valoracin 0 12 3 4 5 Pregunta: Se actualizan los archivos maestros de forma interactiva? Nada Actualizacin on-line de los archivos de control . El volumen de actualizacin es bajo y la recuperacin fcil. Actualizacin on-line de la mayora de los archivos internos lgicos. Adems es esencial la proteccin contra la prdida de datos. Adems se considera el costo de recuperacin de volmenes elevados.

1. Complejidad del procesamiento . Esto es, complejidad interna ms all de la media en lo referente a la entrada, salida o lgica de procesamiento. Qu caractersticas tiene la aplicacin? Mucho procesamiento matemtico y lgico Procesamiento complejo de las entradas

Procesamiento complejo de las salidas Muchas excepciones de procesamiento, muchas transacciones incompletas y mucho procesamiento de las transacciones. Procesamiento de seguridad y/o control sensitivo. Valoracin Pregunta: Son complejas las entradas, las salidas, los archivos o las peticiones? y Es complejo el procesamiento interno? No aplica nada de esto Se aplica algn elemento. Se aplican dos elementos. Se aplican tres elementos. Se aplican cuatro elementos. Se aplica todo.

0 1 2 3 4 5

1. Utilizable en otras aplicaciones . El cdigo se disea para que sea compartido o utilizable por otras aplicaciones. Valoracin 01 2-3 45 Pregunta: Se ha diseado el cdigo para ser reutilizado? Una aplicacin local que responde a las necesidades de una organizacin usuaria. La aplicacin utiliza o produce mdulos comunes que consideran ms necesidades que las del usuario. Adems, la aplicacin se "empaqueto" y documento con el propsito del fcil reutilizacin.

1. 1. Facilidad de instalacin. 2. puestos mltiples Valoracin 01 23 Pregunta: Estn incluidas en el diseo la conversin y la instalacin? No se requieren por parte del usuario facilidades especiales de conversin e instalacin. Los requerimientos de conversin e instalacin fueron descritos por el usuario y se proporcionaron guas de conversin e instalacin. Adems se proporcionaron y probaron herramientas de conversin e instalacin.

45

1. 1. Puestos mltiples .

Valoracin 0 13 45 Valoracin 0 13 45

Pregunta: Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario? El usuario no requiere la consideracin de ms de un puesto. Se incluyeron necesidades de varios puestos en el diseo. Se proporciona documentacin y plan de apoyo para soportar la aplicacin en varios lugares. Pregunta: Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones ? No hay requerimientos especiales del usuario para minimizar o facilitar el cambio. Se proporciona capacidad de consulta flexible Datos importantes de control se mantienen en tablas que son actualizadas por el usuario a travs de procesos on-line interactivos.

1. 1. Facilidad de Cambio. Esfuerzo especifico de diseo para facilitar cambios futuros. Estas valoraciones dadas a cada uno de estos puntos permiten aproximar una medida del sistema a travs de la siguiente ecuacin: PF = Cuenta_total * [0,65 + 0,01*?(Fi)], cuenta total es la valoracin para cada uno de las preguntas, y la sumatoria representa el total generado por toda la valoracin. 4.2 Revisiones Tecnicas Formales MTRICAS DEL MODELO DE ANLISIS En esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el tamao del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionados. MTRICAS BASADAS EN LA FUNCIN La mtrica del punto de funcin (PF) se puede utilizar como medio para predecir el tamao de un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el clculo de la mtrica de punto de funcin: Nmero de entradas del usuario Nmero de salidas del usuario

 Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas La cuenta total debe ajustarse utilizando la siguiente ecuacin: PF = cuenta-total x (0,65 + 0,01 x Fi) Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los valores de ajuste de complejidad. Para el ejemplo descrito en la figura 9.2 se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56

Factor de ponderacin Parmetro de medicin Cuenta Simple Media Compl. Nmero de entradas del usuario 3 X 3 4 6 = 9 Nmero de salidas del usuario 2 X 4 5 7 = 8 Nmero de consultas del usuario 2 X 3 4 6 = 6 Nmero de archivos 1 X 7 10 15 = 7 Nmero de interfaces externas 4 X 5 7 10 = 20 Cuenta total 50 Basndose en el valor previsto del PF obtenido del modelo de anlisis, el equipo del proyecto puede estimar el tamao global de implementacin de las funciones de interaccin. Asuma que los datos de los que se dispone indican que un PF supone 60 lneas de cdigo (se utilizar un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos histricos proporcionan al gestor del proyecto una importante informacin de planificacin basada en el modelo de anlisis en lugar de estimaciones preliminares Mtricas de la Calidad de Especificacin Existe una lista de caractersticas para poder valorar la calidad del modelo de anlisis y la correspondiente especificacin de requisitos: Especificidad, correccin, complecin, comprensin, capacidad de verificacin, consistencia externa e interna, capacidad de logro, concisin, traza habilidad, capacidad de modificacin, exactitud y capacidad de reutilizacin. Aunque muchas de las caractersticas anteriores pueden ser de naturaleza cuantitativa, Davis [Pressman98] sugiere que todas puedan representarse usando una o ms mtricas. Por ejemplo asumimos que hay ni requisitos en una especificacin,

tal como ni = nf + nnf (4.8) Donde nf es el nmero de requisitos funcionales y nnf es el nmero de requisitos no funcionales (por ejemplo, rendimiento).Para determinar la especificidad de los requisitos, Davis [Pressman 98] sugiere una mtrica basada en la consistencia de la interpretacin de los revisores para cada requisito: Q1 = nui / nr (4.9) Donde nui es el nmero de requisitos para los que todos los revisores tuvieron interpretaciones idnticas. Cuanto ms cerca de uno este el valor de Q1 menor ser la ambigedad de la especificacin. La complecin de los requisitos funcionales puede terminarse calculando la relacin Q2 = nu / (ni * ns) (4.10) 82 donde nu es el nmero de requisitos de funcin nicos, ni es el nmero de entradas (estmulos) definidos o implicados por la especificacin y ns es el nmero de estados especificados. La relacin Q2 mide porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no trata los requisitos no funcinales. Para incorporarlos a una mtrica global completa, debemos considerar el grado de validacin de los requisitos: Q3 = nc / (nc + nnv) (4.11) donde nc es el nmero de requisitos que se han validados como correctos y nnv el nmero de requisitos que no se han validado todava REVISIONES TECNICAS FORMALES Objetivos: descubrir errores en la funcin, lgica o implementacin de cualquier representacin del software. Verificar el cumplimiento de los requisitos Garantizar el cumplimiento de los estndares. Conseguir un desarrollo uniforme del software Obtener proyectos que hagan ms sencillo los trabajos tcnicos (anlisis que permitan buenos diseos, diseos que permitan implementaciones sencillas, estrategias de pruebas que faciliten stas,) RTFs: son un filtro que permite purificar las actividades de ingeniera de software. se aplican en diversos momentos del desarrollo para detectar defectos. Diseo: entre el 50 y el 60% de los errores del desarrollo. Aprovecha la diversidad de un grupo de personas para: sealar la necesidad de mejoras en el producto de ingeniera (diagramas del anlisis, diccionario de datos, diseo, cdigo, estrategia de pruebas,)Confirmar las partes en las que no es necesaria una mejora. Conseguir un trabajo tcnico de calidad ms uniforme. Efectividad: se calcula que son efectivas en un 75%. Tcnicas Estticas: anlisis y chequeo de documentos de requisitos, diagramas de diseo, cdigo fuente, etc. dinmicas: pruebas sobre implementacin real (slo pueden Usarse cuando ya se tiene cdigo ejecutable). Revisiones Tcnicas Formales Se eliminan errores en forma relativamente temprana (barato y fcil de corregir) Cada revisin se conduce en forma de una reunin cuidadosamente planeada y controlada

La reunin de revisin Entre 3 y 5 personas (grupo pequeo) Preparacin previa (2 horas por persona) Especificacin precisa (formal o informal) Estndares de codificacin Duracin mxima 2 horas (lento pero cansado) Foco en un segmento especfico Participan los revisores y el productor Directrices para la revisin Revisar el producto y no al productor Indicar los errores con tino, tono constructivo Mantenerse estrictamente dentro de la agenda No irse por las ramas Limitar el debate Algunos asuntos pueden dejarse para discusin posterior Enunciar problemas no resolverlos Problema debera ser resuelto por el productor Tomar notas (pizarra deseable)

4.2.1 La Reunion de Revision La reunin de revisin Entre 3 y 5 personas (grupo pequeo) Preparacin previa (2 horas por persona) Especificacin precisa (formal o informal). La persona o el equipo ha desarrollado este mdulo especfico o producto ntimos del producto es completa y un examen puede tener lugar. Entonces el jefe de proyecto hacia adelante la solicitud a la lder de revisin que tambin informa a los revisores que llevan a cabo la tarea. Los miembros de la reunin de examen son los encuestados que realizan la tarea. Los miembros de la reunin de examen son los encuestados, los desarrolladores lderes de revisin, producto (o el lder mdulo solo) y no uno de los encuestados toma el trabajo de la grabadora y anota todas las cuestiones importantes planteadas en la reunin.

Al final de cada reunin de revisin, la decisin debe ser tomada por los asistentes a la FTR (formal de Revisin Tcnica) sobre si aceptar el producto sin ninguna otra modificacin o rechazar el producto debido a errores graves o aceptar el producto con carcter provisional. Todos los FTR (formal de Revisin Tcnica) asistentes firmar cualuier decisin adoptada. Al final de la revisin de una lista de examinar las cuestiones y un resumen de revisin es el informe se genera. 4.2.2 Registro Informe de Revision

4.2.3 Directrices para la revision Directrices para la revisin Revisar el producto no el productor. Fijar una agenda y mantenerla. Limitar el debate y las impugnaciones. Enunciar reas de problemas Tomar notas escritas. Limitar el nmero de participantes e insistir en la preparacin anticipada. Llevar a cabo un entrenamiento adecuado de los revisores. Repasar las revisiones anteriores.

METRICAS DE LA CALIDAD DEL SOFTWARE

METRICAS PARA LA EVALUACIN DEL ANLISIs4.1. METRICAS DEL MODELO DE ANALISIS Empezaremos por definir los posibles trminos que se encuentran encerrados en la palabra Mtrica, porque es muy comn asociarla con las palabras medicin y medida, aunque estas tres son distintas. La medicin es el proceso por el cual los nmeros o smbolos son asignados a atributos o entidades en el mundo real ta l como son descritos de acuerdo a reglas claramente definidas [Fenton 91]. Una medida proporciona una indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto[Pressman98]. El IEEE .Standard Glosary of Software Engering Terms define como mtrica como una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado [Len O. Ejiogo91] Qu son las mtricas de software? Michael [99] define las mtricas de software como La aplicacin continua de mediciones basadas en tcnicas para el proceso de desarrollo del software y sus productos para suministrar informacin relevante a tiempo, as el administrador junto con el empleo de ests tcnicas mejorar el proceso y sus productos. Las mtricas de software proveen la informacin necesaria para la toma de decisiones tcnicas. En la figura 2.1 se ilustra una extensin de esta definicin para incluir los servicios relacionados al software como la respuesta a los resultados del cliente: En esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el "tamao" del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionadas.

Unidad 5 Documentacin del anlisis del sistema UNIDAD V: Documentacin del anlisis del sistema Documentacin del anlisis del sistema La documentacin de sistemas es el conjunto de informacin que nos dice qu hacen los sistemas, cmo lo hacen y para quin lo hacen. La documentacin consiste en material que explica las caractersticas tcnicas y la operacin de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para ensear a los usuarios como interactuar con el sistema y a los operados como hacerlo funcionar. Existen varios tipos de documentacin. La de programas, que explica la lgica de un programa e incluye descripciones, Diagramas de flujo, listados de programas y otros documentos; la del usuarios en forma general la naturaleza y capacidades del sistema y cmo usarlo. Muchas organizaciones tienen lo que se conoce como un programa de documentacin, el cual consiste en una poltica formal cuya documentacin se muestra como algo que debe prepararse en forma rutinaria para cada programa de cmputo, archivo y nuevos sistemas. Importancia De La Documentacin De Sistemas La importancia de la documentacin bien podra ser comparada con la importancia de la existencia de una Pliza de Seguro; mientras todo va bien no

existe la precaucin de confirmar si nuestra Pliza de Seguros est o no vigente. La documentacin adecuada y completa, de una aplicacin que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Informacin, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atencin. Si la documentacin del sistema es incompleta el diseador continuamente estar involucrado y no podr moverse a otra asignacin. 5.1 Estndares en la documentacin del anlisis. Estandarizacin Significa que los smbolos convencionales se usan en todos los diagramas de flujo para prescribir el sistema y que en la documentacin se usen formas estandarizadas. An cuando las normas de documentacin varan de una instalacin a otra, es esencial que dentro de una organizacin, se utilice un solo mtodo. El uso de procedimientos y documentacin estandarizada proporciona la base de una comunicacin clara y rpida, adiestramiento menos costoso del personal de sistemas, reduccin de costos de almacenamiento, y otros. Ventajas De La Estandarizacin Ayuda al entrenamiento del nuevo personal dentro y fuera de la organizacin de Sistemas. Es til para cualquiera que tenga la responsabilidad del mantenimiento de los sistemas. Ayuda a los analistas y diseadores de sistemas en el trabajo de integracin de sistemas. Asegura que el sistema opere correctamente. Se utilizan eficientemente los recursos que se dispongan. Estndares Bsicos De Documentacin Toda documentacin que se relacione con un sistema, ya sea manual o por computadora, sencillo o complejo debe reunir los siguientes requisitos bsicos:

Debe ser rotulada con claridad y bien organizada, con secciones claramente indicadas, almacenarlas en carpetas e ndice. Los diagramas debern ser claros, no aglomerados y la escritura manuscrita deber ser legible. La documentacin deber ser completa.

Se incluir una leyenda o explicacin de los trminos utilizados. La documentacin siempre se conserva actualizada.

Normalizacin Asegrese de que los estndares sean completos, actualizados, documentados y legibles. Auditar permanentemente para que se cumplan los estndares. Evaluar si los estndares establecidos son los requeridos y hacer los cambios necesarios para que dichos estndares sean los apropiados. 5.2 Preparacin del reporte escrito del Anlisis. Reporte de terminacin del anlisis de sistemas Quizs es la comunicacin la ms importante de todas, que describe los hallazgos del anlisis de sistemas. El formato y contenido de este reporte incluye lo siguiente: Una nueva exposicin de la razn y alcance del anlisis. Una lista de los principales problemas identificados. Una presentacin de todos los requerimientos de los usuarios. Un planteamiento de todas las suposiciones crticas hechas por el analista durante el anlisis. Una proyeccin de los recursos requeridos y los costos esperados Que estarn involucrados en el diseo de cualquier nuevo sistema o en la modificacin del sistema actual. Cualquier recomendacin requerimientos. Preparacin oral del reporte La simple entrega de los reportes de sistemas no es suficiente. Es necesaria una presentacin oral para una comunicacin clara del trabajo realizado. Cuatro mtodos para la presentacin oral de los reportes de sistemas son la memorizacin, la presentacin improvisada, la lectura, y el mtodo extemporneo.

referente

al

sistema

propuesto

sus

Memorizada

Una presentacin memorizada es eficaz en cierta forma y le proporciona a uno un sentimiento de seguridad, pero a costa de una libertad y frescura, incluso en

la presentacin memorizada, se necesita tener un bosquejo para el caso en que uno se pierde.

Improvisada

El mtodo improvisado es una presentacin sin ensayo y no se recomienda en absoluto para la presentacin de los reportes del sistema. Debido a que uno es el autor de estos reportes, se podra considerar que no es necesario revisarlos; sin embargo, si no se hace, se olvidarn los puntos principales y se tender a divagar.

Lectura

La lectura de los reportes puede describirse en una palabra arrullo; es una pastilla para dormir la lectura de los reportes, adems de la incapacidad para mantener un contacto visual.

Extempornea

El mtodo extemporneo es la mejor forma de presentar los reportes. Si uno ha hecho su tarea y conoce sus reportes de pies a cabeza, entonces ste es el mtodo de entrega ms verstil y expresiva. Se es espontneo y enrgico. Uno se puede adaptar fcilmente a tpicos y situaciones que no estaban planeadas. Alternativas de solucin

Parar el trabajo.- Este resultado significa que ya no se va a realizar ms trabajo y que el trabajo en sistemas y los recursos debern dirigirse hacia otros trabajos. Este resultado podra presentarse debido a que una propuesta no cumple las consideraciones de factibilidad, debido a un cambio en las decisiones de la gerencia o del solicitante, o debido a un reordenamiento de las prioridades de los sistemas. Estado de espera.- Este resultado es bastante comn y generalmente se da por una falta de fondos o una actitud conservadora de la gerencia. Modificar.- Este resultado significa que la gerencia decide que algunos aspectos de la propuesta se deben cambiar o combinar con otros subsistemas. Proceder bajo condicin.- Este resultado significa que el trabajo en sistemas proseguir segn se propuso, pero que la propuesta del diseo final antes de la implementacin tendr que justificarse en base a la factibilidad. Proceder sin condiciones.- Muchas propuestas de sistemas o subsistemas son autorizadas por la gerencia con un conocimiento total de que los costos superaron los beneficios medibles.

5.3 Preparacin de la propuesta Presentacin de la propuesta Documentacin del anlisis preliminar

El reporte est dirigido a dos receptores diferentes. Primeramente, el gerente para determinar si el analista ha realizado un trabajo competente. El segundo lugar a la gerencia general y a la gerencia de los usuarios para determinar si el analista ha considerado o no todos los requerimientos de la organizacin. Para proporcionar un reporte significativo a estas dos partes interesadas, el analista deber esforzarse por ser conciso pero completo al preparar el reporte. Los requerimientos debern cuantificarse y explicarse de manera especfica. El analista deber evitar en el reporte el lenguaje tcnico y los acrnimos. Debern anexarse exposiciones y los documentos de trabajo que se utilizaron en el anlisis de sistemas.