Unidad 1 Análisis

Unidad 1 Análisis Equipo 1 INTEGRANTES: - Ma Manu nuel el Alf Alfre redo do Góm Gómez ez Zep Zeped edaa - Ju Juan an Dan anie iell Así Asíss Ort Orteg egaa - De Deme metr trio io Gar Garccía Zuñ Zuñig igaa PROFESOR: - Ma Marc rco o Anto Antoni nio o Vázq Vázque uezz Rome Romero ro

Fecha de entrega: 04/Septiembre/2017

Índice Introducción ........................................................................... ........................................................................................................................................................... ..................................................................................3 ..3 1.1 Revisión de especificaciones de requisitos ......................................................................................... ........................................................................................................4 ...............4 1.1.1 Norma IEEE830 ...............................................................................................................................................7 ................................................................................................................................ ...............7 1.1.2 Trazabilidad de requisitos .................................................................................... ...............................................................................................................................8 ...........................................8 1.2 Descripción de procesos ................................................................................................................................. ................................................................................................................................. 10 1.3 Diagramas UML ...................................................................................................................... ............................................................................................................................................... ......................... 11 1.4 Estudio de factibilidad................................................................... ..................................................................................................................................... .................................................................. 15 1.5 Análisis Costo-Beneficio ......................................................................................................... .................................................................................................................................. ......................... 19 Comentarios y Conclusiones ............................................................................ ................................................................................................................................. ..................................................... 21 Bibliografías ...................................................................................................... ........................................................................................................................................................... ..................................................... 21

Introducción La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software. Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos –  un conjunto de actividades que son denominadas análisis –  El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador. El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy  probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software  puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”. El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

1.1 Revisión de especificaciones de requisitos El análisis global de los requisitos de una aplicación es un proceso de conceptualización y formulación de los conceptos que involucra de forma concreta. Es una parte fundamental del proceso de desarrollo de una aplicación, la mayor parte de los defectos encontrados en el software entregado se originan en la fase de análisis de requisitos, y además son los más caros de reparar. Siempre se ha discutido quién es el dueño de los requisitos: el cliente o el desarrollador. Para gestionar esto, es habitual presentar el análisis de requisitos en dos secciones: •Requisitos de cliente: documentan los deseos y necesidades de los clientes y se expresan en lenguaje claro para él. •Requisitos detallados: Determina los requisitos de manera específica y estructurada y están destinadas específicamente hacia los desarrolladores. Los objetivos de este tema son: •Distinguir entre requisitos de clientes y requisitos detallados. •Disponer de recursos para formular de forma clara y sistemática los requisitos del cliente. -Casos de uso -Diagramas de actividad -Diagramas de interacciones, colaboraciones y flujo de datos. -Descripción de las interfaces de usuario y sus protocolos de uso. •Ser capaz de describir los documentos de la especificación de requisitos de software. El resultado del proceso es el documento “Especificación de Requisitos Software”

Para construir algo primero debe entenderse lo que debe ser ese algo. El proceso de entender y documentar una aplicación software se llama “Análisis de requisitos”. En general los requisitos expresan qué se supone

debe hacer una aplicación y no intentan expresar como logra estas funciones. El análisis inicial de un sistema debe tratar de descubrir los requerimientos del producto final que se desarrolla en detalle. Unos de los principales objetivos de UML es hacer que este análisis sea lo suficientemente intuitivo para que los clientes y expertos en el dominio que solicitan el producto puedan comprenderlo, y lo suficientemente formal y riguroso para que se establezca una formulación no ambigua que pueda ser utilizada por los técnicos que la desarrollan. Los aspectos básicos que deben tratarse en esta fase son: •Determinar los paquetes de funcionalidad y de la calidad de servicio del producto, formulados de una forma

independiente de su implementación, y refinar y detallar estas especificaciones hasta que den lugar a una especificación no ambigua del producto que se desarrolla. •Identificar los factores externos al sistema que interactúan con la aplicación de forma relevante. •Identificar la semántica y las características de los mensajes que intercambian los actores con el sistema que

se desarrolla. •Refinar los protocolos de interacción que usan los actores para llevar a cabo las diferentes transacciones que

se pueden realizar con el sistema. El análisis de requisitos es una necesidad, no un lujo. Para apoyarlo considérese su efecto sobre las pruebas del producto concluido. Si alguien le proporciona una caja negra con un cable rojo, rosa y morado que sale de ella, sería imposible probarlo. No se sabe qué hace, para que sirve.

El proceso de análisis de requisitos requiere diferentes actividades de alto nivel y que son desarrollados por múltiples agentes (usuarios, expertos de dominio, expertos de marketing, programadores, etc.) Para la formulación de las especificaciones existen diferentes estándar, el más conocido es el estándar ANSI, IEEE 830-1993. Para todas las etapas se pueden utilizar métricas tales como: •

Tiempo dedicado a su análisis.

•

Cantidad producida (páginas de requisitos, minutos de interacción con el cliente, etc.)

•

Calidad deducida de la autoevaluación (Tasas de defectos en las inspecciones).

1.1.1 Norma IEEE830 El análisis y desarrollo de requerimientos tiene como producto final: un acuerdo documentado entre el cliente y el grupo de desarrollo acerca del producto a ser construido. Estos documentos tienen por finalidad reunir los requisitos completos del cliente tal de desarrollar un software de acuerdo a las exigencias del mismo. El documento es conocido como: Especificación de Requerimientos del Software, Especificación Funcional o Especificación del Sistema. Documentos ERS El documento ERS establece con precisión las funciones y capacidad del software así como sus restricciones. El ERS es la base para toda subsecuente planificación, diseño, y codificación, así como para las pruebas del software y documentación del usuario. El ERS debe comprender la totalidad de los requerimientos. Los desarrolladores y clientes no deben realizar presunción alguna. Si cualquier requerimiento funcional o no funcional no es identificado en el ERS, no es parte del acuerdo y por lo tanto nadie debe esperar que aparezca en el producto final. IEEE Std 830 - Prácticas recomendadas para la Especificación de Requerimientos del Software El estándar 830-1998 fue generado por un equipo de trabajo del IEEE, su finalidad es la integración de los requerimientos del sistema desde la perspectiva del usuario, cliente y desarrollador. La 830 se encarga de poner las pautas para identificar y esquematizar los requerimientos de software. como parte integral del desarrollo de software, sino también como base fundamental de este, todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la creación de una solución, producto o software; incurriendo en gastos o cambios producto de una mal análisis de requerimientos. Objetivos: Ya conociendo lo que es un ERS se debe establecer que función ubicada en el contexto de desarrollo de software por esto se plantea lo siguiente: - Un cliente describa claramente lo que quiere - Un proveedor entienda claramente lo que el cliente quiere - Se establezcan bases para un contrato de desarrollo (o de compra-venta) - Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos) Actores De los estándares este es uno de los que mayor importancia lleva ya que este es el que define que hará la herramienta de software o solución planteada. - Un cliente/usuario que vaya a definir requerimientos (características) de un software que necesite - Un desarrollador (interno/externo) que haga software “a la medida” mediante proyecto

1.1.2 Trazabilidad de requisitos La Trazabilidad de requisitos es la asociación de un requisito con otros requisitos y las diferentes instancias o artefactos con que se relaciona, así como la habilidad de describir y seguir el ciclo de vida completo de un requisito, desde su origen, pasando por su desarrollo y especificación y finalizando con su despliegue.

Es importante identificar y establecer el nivel de detalle que se requiere hacia los diferentes casos de uso, reglas de negocio, características y atributos. Es necesario seleccionar aquellas asociaciones que son de interés relevante para el análisis, para su posterior análisis ante un posible cambio en los elementos que se puedan ver afectados. Debido a esto, resulta fundamental que la trazabilidad siempre esté actualizada y refleje la realidad del proyecto en tiempo real. Disponer de una buena trazabilidad de requisitos nos permite realizar el control y apoyo para la toma de decisiones en el proyecto . Por ejemplo, una de las ventajas principales que nos ofrece la trazabilidad es poder determinar si todos los requisitos han sido considerados y si las instancias que han sido generadas pueden asociarse con un requisito válido. Gracias a la trazabilidad de requisitos tenemos la posibilidad de identificar el origen de cada requisito y realizar el seguimiento de cada cambio que se realice sobre el mismo. Además, al trazar los requisitos con otros artefactos como pruebas, casos de uso, código, etc., será posible responder a los cambios de forma más controlada y con más información, y en consecuencia anticiparnos a lo que un cambio puede significar. Una de las técnicas más utilizadas para recoger la información bi-direccional de trazas, son las  matrices de trazabilidad. Éstas muestran diversos elementos en filas y columnas (por ejemplo requisitos y pruebas) indicando en cada celda de la matriz si los elementos están o no trazados y en qué dirección. Este tipo de técnicas permite un análisis gráfico de la trazabilidad de requisitos y la gestión de su impacto ante posibles cambios.

Trazabilidad de requisitos en CMMI

En el modelo CMMI es una de las prácticas específicas del área de proceso de Gestión de requisitos (REQM). Es necesaria, fundamentalmente, para evaluar el impacto del cambio de los requisitos en las actividades y productos de trabajo del proyecto. Permite mostrar las relaciones e interdependencias entre los requisitos, proporcionar visibilidad a la gerencia sobre el avance en el desarrollo de los entregables y el cumplimiento de los requisitos, demostrar la satisfacción de los requisitos con los componentes y pruebas y es de gran ayuda para los que realicen mantenimientos y actualizaciones posteriores. En la creación de la trazabilidad es importante considerar el alcance de aplicación de la traza, los elementos y relaciones que se deben considerar y la forma en que se llevara la trazabilidad. Normalmente se piensa en la traza vertical hacia las instancias que se van creando a partir de los requisitos iniciales, pero en ciertos contextos es importante conocer la traza hacía componentes del mismo nivel en forma horizontal, como son las interfaces. Consideraciones en la trazabilidad de requisitos

Los requisitos están relacionados entre sí. Es importante identificar y establecer el nivel de detalle que se requiere hacia los diferentes casos de uso, reglas de negocio, funcionalidades, características y atributos de calidad. Se deben seleccionar aquellas asociaciones que son de interés para el análisis, que en caso de cambios permitan identificar fácilmente los elementos que se afectan. Hay que tomar en cuenta que la trazabilidad de requisitos es un elemento de control, no es la definición en sí de los requisitos que se puede establecer o documentar de manera independiente. Los requisitos se asocian con los entregables que son desarrollados como componentes de diseño, archivos de código, casos de prueba, manuales de usuario, procedimientos y componentes del producto. Se deben considerar aquellos elementos de interés para el diseño y las pruebas que permitan confirmar que los requisitos han sido adecuadamente cubiertos. En particular, es de especial apoyo para los equipos que posteriormente deban realizar el mantenimiento del producto y puedan identificar fácilmente los componentes de diseño, código o pruebas que se afectan por el cambio de requisito. Existen diferentes herramientas especializadas que facilitan la definición y control de la trazabilidad de los requisitos, aunque no necesariamente se requiere una herramienta sofisticada para esta actividad. La herramienta en sí no hace nada. Los que utilizan la herramienta, y que estén familiarizados con la misma, son los que pueden llevar esa traza. Para ello se requiere capacitación y práctica para lograr el resultado de manera efectiva. Normalmente existe una persona responsable de estudiar y utilizar la herramienta para gestionar los requisitos en el proyecto. La trazabilidad es un apoyo para la evolución del producto y permite controlar el flujo de requisitos hasta la conclusión del desarrollo. La profundidad y el detalle de su aplicación depende de cada situación, lo que es importante y no debe olvidarse es que para ser útil debe estar actualizada y reflejar la realidad del proyecto en tiempo.

1.2 Descripción de procesos Procesos Software Naturaleza y Elementos

-

Un Proceso es Un conjunto de actividades interrelacionadas que transforman entradas en salidas (ISO 12207/UNE 77104)

• Un Proceso Software (PS) es Un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software. (Fugetta, 2000)

Procesos Software

Naturaleza y Elementos

Tipos de elementos para modelar/representar un Proceso Software Tiene sub

Tiene sub

Tiene entrada Actividad

Producto

Tiene intermedio Tiene salida Utiliza

Desarrollador

Herramienta

 Necesita Juega

Obedece Tiene sub Norma

Actividad

Recurso

Producto

Organización

1.3 Diagramas UML DEFINICIÓN Y CONCEPTO DE UML UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un estándar que se

ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).

¿QUÉ ES Y PARA QUÉ SIRVE UML? El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no

es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen cómo se debe representar algo. UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática. Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar. Supongamos que vamos a definir un estándar llamado “LMAPR” o lenguaje de modelado de aprenderaprogramar .com. Ahora definimos dentro de nuestro estándar estas normas: Un animal debe representarse con su nombre escrito enteramente en minúsculas enmarcado dentro de un rectángulo doble. Encima del nombre debe etiquetarse el tipo de animal así: . Por ejemplo, . Si un animal envía un mensaje a otro animal deben conectarse los dos animales con una línea punteada terminada en flecha encima de la cual debe figurar el texto msg(“Contenido del mensaje”).

 Ahora supongamos que tenemos dos gatos, uno de los cuales le dice al otro “Caza un ratón y tráemelo aquí por favor”.  Veamos formas de representar esto:

Esta es una forma de representación. Sin embargo, no se adapta al estándar que hemos definido por varios motivos: no indica encima de los nombres de los animales, no escribe los nombres en minúsculas, no representa los animales con un rectángulo, etc.  Veamos la representación que sí se adaptaría al estándar definido:

Con este ejemplo sencillo hemos tratado de hacer explícito qué es y para qué sirve UML: un conjunto de normas que nos dicen cómo hay que representar esquemas de software. En el caso del software orientado a objetos, en vez de gatos tendremos clases u objetos instanciados, y dispondremos de numerosos tipos de esquemas y diagramas para representar distintas cosas. Un esquema que cumple las normas UML podría tener este aspecto:

O también este otro:

¿Por qué si ambos esquemas cumplen con UML tienen un aspecto tan distinto? Porque UML define normas para construir muchos tipos de esquemas, no esquemas de un solo tipo.

¿Quién usa UML? UML lo suelen usar las empresas o medianos o grandes equipos de desarrollo software con el objetivo de planificar y documentar cómo se construyen los programas informáticos complejos. Los usuarios individuales o pequeños equipos de desarrollo de 2 ó 3 personas no suelen usar herramientas UML. UML es un término que se relaciona mucho con “Ingeniería del software”. Al igual que un proyecto de edificio requiere la participación d e un arquitecto y unos plantos, un proyecto software requiere la participación de ingenieros informáticos y una planificación y documentación.

¿CUÁLES SON LAS VERSIONES DE UML? Los antecedentes de UML se sitúan en la década de los 90 con distintos estándares para modelado de software, no obstante podemos hablar de dos grandes versiones: UML 1.X (comprende UML 1.1, 1.2, 1.3, 1.4, 1.5): desde finales de los 90 se empezó a trabajar con el estándar UML. En los años sucesivos fueron apareciendo nuevas versiones que introducían mejoras o ampliaban a las anteriores. UML 2.X (comprende UML 2.1 hasta UML 2.5, 2.6, etc.): en torno a 2005 se difundió una nueva versión de UML a la que podemos denominar UML 2.X. Comprenden varias revisiones. UML 3.X: evolución que se espera para UML 2.X.

Hay que tener en cuenta que UML es un conjunto muy amplio de normas. Prácticamente nadie l as conoce todas. Según la empresa o universidad, institución o centro de trabajo se usan determinados programas para crear diagramas y se conocen ciertas partes de UML, pero no el conjunto de UML. ¿Qué versión usar? Para generar diagramas UML se usan programas informáticos. Usa un programa actualizado pero no te preocupes en exceso por qué versión de UML usar, lo importante es que en tu grupo de trabajo o personas a las que se les vaya a enviar documentación sobre un proyecto software sepan interpretar lo que se les envía. A nivel profesional no se le presta demasiada atención a que se cumpla estrictamente con las normas de una determinada versión de UML, sino a que los esquemas estén bien construidos y razonados.

1.4 Estudio de factibilidad Factibilidad: se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos: Operativo. Técnico. Económico.   

El éxito de un proyecto está 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 decisión, si procede su estudio, desarrollo o implementación.

Objetivos de un Estudio de Factibilidad.  Auxiliar a una organización a lograr sus objetivos. Cubrir las metas con los recursos actuales en las áreas técnicas, económicas y operativas.

 

DEFINICIÓN DE OBJETIVOS DEL PROYECTO: La investigación de factibilidad en un proyecto que consiste en descubrir cuáles son los objetivos de la organización, luego determinar si el proyecto es útil para que la empresa logre sus objetivos. La búsqueda 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 genéricos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos. Estos objetivos son los siguientes: Reducción de errores y mayor precisión en los procesos. Reducción de costos mediante la optimización o eliminación de recursos no necesarios. Integración de todas las áreas y subsistemas de la empresa.  Actualización y mejoramiento de los servicios a clientes o usuarios.  Aceleración en la recopilación de datos. Reducción en el tiempo de procesamiento y ejecución de tareas.  Automatización u optimización de procedimientos manuales. Reinversión social de sus excedentes, con igualdad sustantiva entre sus integrantes.        

2. Recursos de los estudios de Factibilidad: La determinación de los recursos para un estudio de factibilidad sigue el mismo patrón considerado por los objetivos vistos anteriormente, el cual deberá revisarse y evaluarse si se llega a realizar un proyecto, estos recursos se analizan en función de tres aspectos:

a. Factibilidad Operativa: Se refiere a todos aquellos recursos donde interviene algún tipo de actividad (Procesos), depende de los recursos humanos que participen durante la operación del proyecto. Durante esta etapa se identifican todas aquellas actividades que son necesarias para lograr el objetivo y se evalúa y determina todo lo necesario para llevarla a cabo.

b. 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 técnicos actuales son suficientes o deben complementarse.

c. Factibilidad Económica: Se refiere a los recursos económicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos básicos que deben considerarse son el costo del tiempo, el costo de la realización y el costo de adquirir nuevos recursos. Generalmente la factibilidad económica es el elemento más importante ya que a través de él se solventan las demás carencias de otros recursos, es lo más difícil de conseguir y requiere de actividades adicionales cuando no se posee.

3. Presentación de un estudio de Factibilidad: Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organización, 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 presentación del estudio:

a. Requisitos Óptimos: se refiere a presentar un estudio con los requisitos óptimos que el proyecto requiera, estos elementos deberán ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la máxima eficacia.

b. Requisitos Mínimos: consiste en un estudio de requisitos mínimos, mínimos necesarios que el proyecto debe tener para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la empresa para minimizar cualquier gasto o adquisición adicional. Un estudio de factibilidad debe representar gráficamente los gastos y los beneficios que acarreará la puesta en marcha del sistema, para tal efecto se hace uso de la curva costo-beneficio.

CONTENIDO DEL ESTUDIO DE FACTIBILIDAD 1. INTRODUCCIÓN 2. RESUMEN EJECUTIVO 3. SITUACIÓN ACTUAL 4. ESTUDIO DE FACTIBILIDAD: La viabilidad del proyecto es analizada a través de los siguientes estudios:

4.1. Objetivo del estudio: Determinar la viabilidad económica, financiera, ambiental, técnica y de mercado, de la Consolidación de:

4.2. Característica del Proyecto: 4.2.1. Naturaleza del proyecto 4.2.2. Importancia 4.2.3. Localización 4.3. Políticas Económicas e Industriales que favorecen o limitan el desarrollo del proyecto. 4.4. ESTUDIO DE MERCADO 4.4.1. EL PRODUCTO 4.4.1.1. Identificación del producto 4.4.1.2. Especificaciones técnicas del producto 4.4.1.3. Durabilidad 4.4.1.4. Productos sustitutivos o similares 4.4.1.5. Productos complementarios (para la comercialización, cajas, envoltorios, estantería de exhibición)

4.4.2. LA DEMANDA 4.4.2.1. Distribución y tipología de los consumidores 4.4.2.2. Comportamiento Actual 4.4.2.3. Series Estadísticas Básicas 4.4.2.4. Metodología para la evaluación de los datos 4.4.2.5. Determinación de la curva de la demanda 4.4.2.6. Determinación de la Demanda Actual y Futura. 4.4.2.7. Fracción de la Demanda que Atenderá el Proyecto 4.4.2.8. Factores que Condicionan la Demanda Actual y Futura 4.4.3. LA OFERTA 4.4.3.1. Distribución y Tipología de los Oferentes 4.4.3.2. Comportamiento Actual 4.4.3.3. Importaciones 4.4.3.4. Series Estadísticas Básicas 4.4.3.5. Determinación de la Oferta Actual y Futura. 4.4.3.6. Metodología para la evaluación de los datos 4.4.3.7. Factores que Condicionan la Oferta Futura 4.4.3.8. Capacidad Instalada y Ociosa de los Oferentes 4.4.3.9. Planes y Proyectos de Ampliación de la Capacidad Instalada de los Oferentes 4.4.3.10. Nuevos Proyectos a Desarrollar

4.4.4. PRECIOS DEL PRODUCTO 4.4.4.1. Series Históricas de Precios 4.4.4.2. Análisis y Evaluación de Datos 4.4.4.3. Comercialización 4.5. ESTUDIO TÉCNICO 4.5.1. Capacidad de la Empresa 4.5.1.1. Factores que Condicionan el Tamaño de la Empresa. 4.5.1.2. Capacidad Instalada o a Instalarse 4.5.1.3. Capacidad Utilizada 4.5.2. Programa de producción y ventas 4.5.2.1. Programa de Producción 4.5.2.2. Programa de Ventas 4.5.3. Procesos y tecnología 4.5.3.1. Descripción del Proceso Productivo 4.5.3.2. Flujograma del Proceso 4.5.3.3. Maquinarias, Equipos y Herramientas 4.5.3.4. Descripción de las Instalaciones Necesarias 4.5.3.5. Distribución Física (cuadro de áreas) 4.5.3.6. Factores que determinan la Localización 4.5.4. INSUMOS REQUERIDOS 4.5.4.1. Requerimiento de Insumos y Precio 4.5.4.2. Disponibilidad de Insumos 4.5.4.3. Origen de los Insumos. 4.5.4.4. Insumos Sustitutivos. 4.5.4.5. Desperdicio. 4.5.5. REQUERIMIENTO DE PERSONAL Y COSTO. 4.5.6. ORGANIZACIÓN 4.6. ESTUDIO FINANCIERO 4.6.1. NECESIDADES totales de capital 4.6.1.1. Requerimiento Total de Activos 4.6.1.1.1. Activos Fijos Tangibles 4.6.1.2. Activos Fijos Intangibles 4.6.1.2.1. Capital de Trabajo 4.6.1.3. Modalidad de Financiamiento 4.6.1.4. Fuentes de Financiamiento 4.6.1.4.1. Condiciones del Crédito 4.6.1.5. Amortización de la Deuda 4.6.1.6. Inversión Anual durante la Vida del Proyecto 4.6.1.7. Depreciación y Amortización de la Inversión 4.6.1.8. Otros Gastos de Fabricación 4.6.1.9. Otros Gastos de Administración y Ventas 4.6.2. ESTRUCTURA DE COSTO CON FINANCIAMIENTO 4.6.3. ESTADO DE GANANCIAS Y PERDIDAS CON FINANCIAMIENTO 4.6.4. FLUJO DE CAJA CON FINANCIAMIENTO 4.6.5. INGRESOS TOTALES ANUALES 4.6.6. CAPACIDAD DE PAGO 4.6.7. ÍNDICES DE EVALUACIÓN DEL PROYECTO 4.6.7.1. Valor Actual Neto (VAN) 4.6.7.2. Tasa Interna de Retorno (TIR) 4.6.7.3. Período de Recuperación del Capital (PRC) 4.6.7.4. Relación Beneficio-Costo (RBC) 4.6.7.5. Inversión por Empleo 4.6.7.6. Punto de Equilibrio (PE) 4.6.7.7. Costos Unitarios 4.6.8. ANÁLISIS DE SENSIBILIDAD 4.7. CRONOGRAMA de EJECUCIÓN 4.8. ASPECTOS LEGALES 4.8.1. Marco Legal

4.8.1.1. La Norma Constitucional 4.8.1.2. Otras Leyes 4.8.2. Ordenamiento Jurídico Interno. 4.8.3. Aspectos Legales que Favorecen o Limitan el Proceso. 4.9. ASPECTOS AMBIENTALES 4.10. ASPECTOS DE HIGIENE Y SEGURIDAD INDUSTRIAL 4.11. CONCLUSIONES Y RECOMENDACIONES. 4.11.1. ASPECTOS SOCIALES 4.11.2. ASPECTOS TÉCNICOS 4.11.3. ASPECTOS ECONÓMICOS – FINANCIEROS.

1.5 Análisis Costo-Beneficio ¿Qué es? El Análisis Costo / Beneficio es el proceso de colocar cifras en dólares en los diferentes costos y beneficios de una actividad. Al utilizarlo, podemos estimar el impacto financiero acumulado de lo que queremos lograr.

¿Cuándo se utiliza? Se debe utilizar el Análisis Costo / Beneficio al comparar los costos y beneficios de las diferentes decisiones. Un Análisis de Costo / Beneficio por si solo puede no ser una guía clara para tomar una buena decisión. Existen otros puntos que deben ser tomados en cuenta, ej. la moral de los empleados, la seguridad, las obligaciones legales y la satisfacción del cliente.

¿Cómo se utiliza? El Análisis de Costo / Beneficio involucra los siguientes 6 pasos: 1. Llevar a cabo una Lluvia de Ideas o reunir datos provenientes de factores importantes relacionados con cada una de sus decisiones. 2. Determinar los costos relacionados con cada factor. Algunos costos, como la mano de obra, serán exactos mientras que otros deberán ser estimados. 3.

Sumar los costos totales para cada decisión propuesta.

4.

Determinar los beneficios en dólares para cada decisión.

5. Poner las cifras de los costos y beneficios totales en la forma de una relación donde los beneficios son el numerador y los costos son el denominador: BENEFICIOS COSTOS 6. Comparar las relaciones Beneficios a Costos para las diferentes decisiones propuestas. La mejor solución, en términos financieros es aquella con la relación más alta beneficios a costos.

Ejemplo: Análisis Costo / Beneficio Un equipo de trabajadores de un restaurante decidió aumentar las ventas agregando una nueva línea de comida en el menú. La nueva línea consistía en cocina gourmet italiana y requería que se contratara un chef adicional. El  Análisis de Costo / Beneficio del equipo para el primer año es el siguiente.

Costos

Beneficios

Chef Italiano Salario anual

Mayor Negocio $40,000

De nuevos clientes italianos

$200,000

Comisión del intermediario

5,000

Transporte desde Italia a Estados Unidos

5,000

De nuevos clientes no italianos

100,000

25,000  

De clientes actuales quienen vendrán más a menudo

100,000

 Asistente del Chef

Nuevos libros de cocina

1,000

Clases de Italiano para el resto del personal

5,000

Publicidad para el nuevo menú

10,000

Pérdida de clientes a quienes no les gusta el nuevo menú

Costo Totales

200,000

$291,000

Beneficios Totales

$400,000

Este análisis hizo que el equipo hiciera una pausa para pensar. Estaban muy entusiasmados con la idea de tener comida italiana en el restaurante, y los cálculos demostraban un beneficio substancial para el primer año ($109,000). Sin embargo, la relación de beneficios a costos era de $1.37 de retorno por cada dólar gastado ($400,000/$291,000). Este sería un retorno positivo, pero ¿valía la pena el esfuerzo que este gran cambio implicaba para el restaurante? ¿Qué haría usted si fuera parte del equipo?

Consejos para la construcción/ interpretación : 



Aunque es deseable que los beneficios sean más grandes que los costos, no existe una respuesta única de cuál es la relación ideal de beneficio a costo. Como se indicó anteriormente, los beneficios tales como la moral de los empleados, las responsabilidades legales, y la seguridad pueden ser beneficios escondidos que no son evidentes en el análisis original.

Relación con otras herramientas: Un Análisis de Costo / Beneficio normalmente se relaciona con: 

Gráfica de Pareto



Cuadrícula de Selección



Matriz de Planeación de Acciones



Análisis del Campo de Fuerzas



Checklist para la Reunión de Datos

Información adicional con respecto a esta herramienta puede obtenerse consultando el siguiente material de referencia: Foundations

in

Quality,

ASQ,

1997

Quality Action Teams, Organization Dynamics, Inc., 1995

Comentarios y Conclusiones El tema de análisis de una ingeniería de software es el primer paso para poder realizar una aplicación, para poder conocer a detalle que es lo que tenemos que tener en mente a la hora de realizar un proyecto, existen procesos y normas que nos permiten realizar el análisis para ver si es factible o no, así como también que es lo que los usuarios necesitan, ya que mayormente a ellos va dirigidos los programas, ya sabiendo esto uno puede empezar a realizar los siguientes pasos para realizar la aplicación o proyecto.

Bibliografías Gregory Michel (2001). “Net Present Value Analysis: A Primer for Finance Officers,” Government Finance Review

(Febrero). En: www.gfoa.org/services/dfl/budget/.../NetPresentValueAnalysis.pdf . Treasury Board of Canada Secretariat (1998) . Benefit-Cost An a l y s i s Gui de ( J u l i o ) . En: https://www.tbs-sct.gc.ca/tbs-sct/index-eng.asp.  Alejo Villarreal (1995). El Análisis Costo-Beneficio y la Viabilidad de los Proyectos en el Sector Público. En: https://www.educoas.org/Portal/bdigital/contenido/interamer/BkIACD/Interamer/Interamerh tml/Riverahtml/ riv_zav_villa.htm

[BRUEGGE, 2002]

Ingeniería de Software Orientado a Objetos Bruegge, Bernd y Dutoit, Allen Prentice-Hall, 2002 ISBN: 970-26-0010-3

[ISURJC]

Curso de Ingeniería del Software I Universidad Rey Juan Carlos http://kybele.escet.urjc.es/asignatura.asp?Nombre1=ISI