CAPÍTULO 12 ECONOMÍA DE LA INGENIERÍA DE SOFTWARE INTRODUCCIÓN La economía de ingeniería de software se trata de tomar decisiones relacionadas con la ingeniería de software en un contexto empresarial. El éxito de un producto de software, es su servicio, y la solución depende de una buena gestión empresarial. Sin embargo, en muchas empresas y organizaciones, las relaciones comerciales de software para el desarrollo de software e ingeniería siguen siendo nulas. Esta área de conocimiento (KA) proporciona una visión general sobre la economía de ingeniería de software. La economía es el estudio de la relación calidad-precio, costos, recursos, y su relación en un contexto o situación dada. En la disciplina de la ingeniería de software, las actividades tienen costos, pero el software resultante tiene atributos económicos. La economía de ingeniería de software proporciona una manera de estudiar los atributos de los procesos de software y software de una manera sistemática que los relaciona con las medidas económicas. Estas medidas económicas pueden ser pesadas y analizadas cuando se toman decisiones que están dentro del alcance de una organización de software y los que están dentro del alcance integral de toda una producción o adquisición de negocios. La economía de ingeniería de software se ocupa de la alineación de las decisiones técnicas de software con los objetivos de negocio de la organización. En todos los tipos de organizaciones, ya sea "con fines de lucro", " o sin fines de lucro," o gubernamental, esto se traduce en forma sostenible permanecer en el negocio. En las organizaciones con fines de lucro esto se refiere además a la consecución de un

retorno tangible de los invertidos en capital a activos y el capital empleado. Esta KA ha sido formulada de una manera para hacer frente a todo tipo de organizaciones independientes de las restricciones de enfoque, la cartera de productos y servicios, o la propiedad del capital y de impuestos. Decisiones como "¿Hay que utilizar un componente específico?" Puede parecer fácil desde un punto de vista técnico, pero puede tener graves consecuencias sobre la viabilidad empresarial de un proyecto de software y el producto resultante. A menudo, los ingenieros se preguntan si estas preocupaciones se aplican en absoluto, ya que son "sólo los ingenieros." Análisis económico y la toma de decisiones son importantes consideraciones de ingeniería porque los ingenieros son capaces de evaluar las decisiones tanto a nivel técnico como desde una perspectiva de negocio. El contenido de esta área de conocimiento son temas importantes para los ingenieros de software a tener en cuenta, incluso si nunca en realidad están involucrados en las decisiones concretas de negocios; que tendrán una visión cabal de las cuestiones de negocios y el papel desempeñan las consideraciones técnicas en la toma de decisiones de negocio. Muchas de las propuestas de ingeniería y decisiones, tales como hacer frente a comprar, tienen profundos impactos económicos intrínsecos que deben tenerse en cuenta de manera explícita. Esta KA cubre primero los cimientos, la terminología clave, conceptos básicos y las prácticas comunes de la ingeniería económica de software para indicar la forma en la toma de decisiones en ingeniería de software incluye o debe incluir una perspectiva de negocio. A continuación, proporciona una perspectiva de ciclo de vida, destaca la gestión del riesgo y la incertidumbre, y muestra cómo se utilizan los métodos de análisis económicos.

Algunas consideraciones prácticas finalizar el área de conocimiento.

DISTRIBUCIÓN DE TEMAS PARA ECONOMÍA INGENIERÍA DE SOFTWARE El desglose de los temas de la Ingeniería de Software Economía KA se muestra en la figura 12.1. 1. Software de Ingeniería económica fundamentos 1.1. Financiar Finanzas es la rama de la economía que se ocupan de cuestiones tales como la asignación, administración, adquisición, y la inversión de los recursos. La financiación es un elemento de todas las organizaciones, incluidas las organizaciones de ingeniería de software. El campo de las finanzas se ocupa de los conceptos de tiempo, dinero, riesgo, y cómo se relacionan entre sí. También se ocupa de cómo se gasta el dinero y presupuestado. Finanzas corporativas se ocupa de proporcionar los fondos para las actividades de una organización. En general, se trata de equilibrar el riesgo y la rentabilidad, al intentar maximizar la riqueza de una organización y el valor de sus acciones. Esto es válido sobre todo para las organizaciones "con fines de lucro", pero también se aplica a los "sin fines de lucro" organizaciones. Esta última etapa requiere recursos financieros para garantizar la sostenibilidad, aunque no es la orientación de beneficio tangible. Para ello, una organización debe:

• Identificar los objetivos de la organización, los horizontes de tiempo, factores de riesgo, las consideraciones fiscales, y las limitaciones financieras;

• Identificar e implementar la estrategia de negocio apropiado, tal como el que las decisiones de cartera y de inversión a tomar, cómo gestionar el flujo de caja, y dónde obtener la financiación;

• Medir el rendimiento financiero, tales como el flujo de caja y el retorno de la inversión (véase la sección 4.3, Retorno de la Inversión), y tomar acciones correctivas en caso de desviación de los objetivos y la estrategia.

1.2. Contabilidad La contabilidad es parte de las finanzas. Permite a las personas cuyo dinero está siendo utilizado para ejecutar una organización para conocer los resultados de su inversión: sacaron los beneficios que se esperaban? En las organizaciones "con fines de lucro", esto se relaciona con el retorno de la inversión tangible (Ver sección 4.3, Retorno de la Inversión), mientras que en "Sin fines de lucro" y organizaciones gubernamentales, así como organizaciones "con fines de lucro", que se traduce en forma sostenible permanecer en el negocio. El primario papel de la contabilidad es para medir el rendimiento financiero real de la organización y comunicar la información financiera de una entidad de negocio para las partes interesadas, como los accionistas, auditores financieros e inversores. La comunicación es generalmente en la forma de estados financieros que muestran en términos monetarios los recursos económicos que se desea controlar. Es importante seleccionar la información correcta que es pertinente y confiable para el usuario. La información y su distribución están parcialmente rigen por las políticas de gestión de riesgos y de gobierno. Los sistemas de contabilidad son también una rica fuente de datos históricos para estimar. 1.3. Controlador El controlador es un elemento de las finanzas y la contabilidad. El Controlador consiste en medir y corregir el desempeño de las finanzas y la contabilidad. Se asegura de que los objetivos y planes de la organización se llevan a cabo. El control de costos es una rama especializada de controlar utilizado

para detectar las variaciones de los costes reales de los costes previstos. 1.4. Flujo de fondos El flujo de caja es el movimiento de dinero que entra o sale de un negocio, proyecto o producto financiero durante un período determinado. Los conceptos de instancias de flujo de caja y las corrientes de flujo de efectivo se utilizan para describir la perspectiva de negocio de una propuesta. Para tomar una decisión de negocios significativa sobre ninguna propuesta concreta, tendrá que ser evaluado desde una perspectiva empresarial dicha propuesta. En una propuesta para desarrollar y lanzar el producto X, el pago por nuevas licencias de software es un ejemplo de una instancia de flujo de caja saliente. Tendría que gastarse para llevar a cabo esta propuesta dinero. Los ingresos por ventas de producto X en el mes 11 después de su lanzamiento al mercado es un ejemplo de una instancia de flujo de caja entrante

El dinero iba a venir a causa de la realización de la propuesta. El flujo de caja término se refiere al conjunto de instancias de flujo de efectivo con el tiempo que son causados por la realización de alguna propuesta determinada. El flujo de caja es, en efecto, el cuadro financiero completo de esa propuesta. ¿Cuánto dinero se apaga? ¿Cuándo se apaga? ¿Cuánto dinero entra? ¿Cuándo se presenta?

Simplemente, si la corriente de flujo de efectivo de Propuesta A es más deseable que la corriente de flujo de caja para la Propuesta B, entonces todo lo demás permanece igual, la organización es mejor llevar a cabo la propuesta A de la Propuesta B. Por lo tanto, la corriente de flujo de caja es un insumo importante para la toma de decisiones de inversión. Una instancia de flujo de caja es una cantidad específica de dinero que entra y sale de la organización en un momento específico, como consecuencia directa de alguna actividad. Un diagrama de flujo de caja es una imagen de una corriente de flujo de efectivo. Se le da al lector una visión general de la situación financiera de la organización tema o proyecto. La figura 12.2 muestra un ejemplo de un diagrama de flujo de caja para una propuesta. 1.5. Proceso de toma de decisiones Si asumimos que las soluciones candidatas a resolver un problema técnico determinado igualmente bien, ¿por qué se elige el cuidado de la organización cuál? La respuesta es que por lo general hay una gran diferencia en los costes e ingresos de las diferentes soluciones. Un comercial, fuera de plataforma, objeto de solicitud producto intermediario podría costar varios miles de dólares, pero el esfuerzo para desarrollar un servicio en casa, que da la misma funcionalidad fácilmente podría costar varios cientos de veces esa cantidad. Si las soluciones candidatas resolver todos adecuadamente el problema desde un punto de vista técnico, la selección de la alternativa más adecuada debe basarse en factores comerciales tales como la optimización de coste total de propiedad (TCO) o maximizar el rendimiento a corto plazo de la inversión (ROI). Los costos del ciclo de vida tales como la corrección de defectos, servicio de campo, y la duración de apoyo también son consideraciones pertinentes. Estos costos tienen que tenerse en cuenta al seleccionar entre los enfoques técnicos aceptables, ya

que son parte del retorno de la inversión de por vida (ver sección 4.3, Retorno de la Inversión). Un proceso sistemático para la toma de decisiones será lograr la transparencia y permitir la justificación posterior. Criterios de gobierno en muchas organizaciones exigen la selección de al menos dos alternativas. Un proceso sistemático se muestra en la figura 12.3. Se inicia con un desafío de negocios a la mano y se describen los pasos para identificar soluciones alternativas, definir los criterios de selección, evaluar las soluciones, implementar una solución seleccionada, y monitorear el desempeño de esa solución. La figura 12.3 muestra el proceso paso a paso que en su mayoría y en serie. El proceso real es más fluido. A veces, los pasos se pueden realizar en un orden diferente y, a menudo varios de los pasos se pueden realizar en paralelo. Lo importante es estar seguro de que ninguno de los pasos se omite o reducirse. También es importante entender que este mismo proceso se aplica a todos los niveles de toma de decisiones: a partir de una decisión tan grande como la determinación de si un proyecto de software se debe hacer en absoluto, a un decidir sobre una estructura de algoritmo o de datos a utilizar en un módulo de software. La diferencia es la forma económicamente significativa es la decisión y, por lo tanto, la cantidad de esfuerzo debe ser invertido en la toma de esa decisión. La decisión a nivel de proyecto es económicamente significativa y probablemente justifica un nivel relativamente alto de esfuerzo para tomar la decisión. La selección de un algoritmo es a menudo mucho menos económicamente importante y garantiza un nivel mucho más bajo de lo posible para tomar la decisión, a pesar de que el mismo proceso de toma de decisiones de base está siendo utilizada.

Más a menudo que no, una organización puede llevar a cabo más de una propuesta si así lo quisiera, y por lo general no son relaciones importantes entre las propuestas. Tal vez Propuesta Y sólo puede ser llevada a cabo si la propuesta X también se lleva a cabo. O tal vez Propuesta P no puede llevarse a cabo si Propuesta Q se lleva a cabo, ni podía Q llevarse a cabo si P fuera. Las opciones son mucho más fáciles de hacer cuando hay caminos -por ejemplo que se excluyen mutuamente, ya sea A o B o C o lo que sea que se elija. En la preparación de las decisiones, se recomienda convertir cualquier conjunto de propuestas, junto con sus diversas interrelaciones, en un conjunto de alternativas mutuamente excluyentes. La elección puede hacerse entonces entre estas alternativas. 1.6. Valuación En un sentido abstracto, la toma de decisiones sea procesamiento toma de decisiones financieras o de otra se trata de maximizar el valor. La alternativa que maximiza el valor total siempre debe ser elegida. Una base financiera para la comparación basada en el valor está comparando dos o más flujos de efectivo. Varias bases de comparación están disponibles, incluyendo

• Valor actual • Valor futuro • Anual equivalente • Tasa interna de retorno • (descontado) Periodo de

recuperación. Basado en el tiempo-valor del dinero, dos o más flujos de caja son equivalentes sólo cuando son iguales a la misma cantidad de dinero en un punto común en el tiempo. La comparación de los flujos de caja sólo tiene sentido cuando se expresan en el mismo período de tiempo.

Tenga en cuenta que el valor no siempre se puede expresar en términos de dinero. Por ejemplo, si un elemento es un nombre de marca o no puedan alterar significativamente su valor percibido. Valores relevantes que no se pueden expresar en términos de dinero todavía necesitan ser expresado en términos similares para que puedan ser evaluados de forma objetiva. 1.7. Inflación La inflación se describe las tendencias a largo plazo de los precios. La inflación significa que las mismas cosas cuestan más que antes. Si el horizonte de planificación de una decisión de negocios es más que unos pocos años, o si la tasa de inflación es más de un par de puntos porcentuales por año, puede causar cambios notables en el valor de una propuesta. Por tanto, el valor de tiempo actual necesita ser ajustado por inflación y las tasas también para las fluctuaciones del tipo de cambio. 1.8. Depreciación La depreciación implica la difusión del costo de un activo tangible a través de una serie de períodos de tiempo; que se utiliza para determinar cómo las inversiones en activos capitalizados son cargadas a resultados a lo largo de varios años. La depreciación es una parte importante de la determinación después de impuestos de flujo de caja, que es fundamental para abordar con precisión los beneficios y los impuestos. Si un producto de software se va a vender después de que los costes de desarrollo se incurren, los costos deben ser capitalizados y se amortizan durante períodos de tiempo posteriores. El gasto de depreciación para cada período de tiempo es el costo capitalizado de desarrollar el software dividida a través del número de periodos en los que se venderá el software. Una propuesta de proyecto de software puede ser comparado con otro software y propuestas sin software o para opciones alternativas de inversión, por lo que es importante determinar cómo esas otras

propuestas se amortizan y cómo se calculan las ganancias. 1.9. Impuestos Los gobiernos cobran impuestos con el fin de financiar los gastos que la sociedad necesita, pero que ninguna organización invertiría en. Las empresas tienen que pagar impuestos sobre la renta, que puede tomar una porción sustancial de la utilidad bruta de una corporación. Un análisis de decisión que no tiene en cuenta los impuestos pueden conducir a la elección equivocada. Una propuesta con una alta ganancia antes de impuestos no se parecerá casi tan rentable en términos posttax(después de impuestos. Sin tener en cuenta los impuestos también puede conducir a expectativas poco realistas sobre lo rentable podría ser un producto propuesto. 1.10. Valor temporal del dinero Uno de los conceptos más fundamentales en las finanzas y, por tanto, en los negocios decisiones- es que el dinero tiene valor temporal: su valor cambia con el tiempo. Una cantidad específica de dinero en este momento casi siempre tiene un valor diferente de la misma cantidad de dinero en algún otro momento. Este concepto ha existido desde la historia humana registrada más temprana y es comúnmente conocida como valor del tiempo. Con el fin de comparar las propuestas o elementos de cartera, deberían ser normalizados en los costos, el valor y el riesgo para el valor actual neto. Las variaciones de cambio de divisas a través del tiempo hay que tener en cuenta sobre la base de los datos históricos. Esto es particularmente importante en la evolución transfronteriza de todo tipo. 1.11. Eficiencia La eficiencia económica de un proceso, actividad o tarea que es la relación entre los recursos consumidos efectivamente a los recursos previstos para ser consumidos o deseado para ser consumidos en el

cumplimiento del proceso, actividad o tarea. Eficiencia significa "hacer las cosas bien." Un comportamiento eficiente, como un comportamiento efectivo, ofrece resultados, pero mantiene el esfuerzo necesario a un mínimo. Los factores que pueden afectar la eficiencia en ingeniería de software incluyen la complejidad del producto, los requisitos de calidad, la presión del tiempo, la capacidad del proceso, la distribución de equipo, interrupciones, la rotación característica, las herramientas y lenguaje de programación. 1.12. Eficacia La eficacia es acerca de tener impacto. Es la relación entre los objetivos alcanzados con los objetivos definidos. Eficacia significa "hacer las cosas bien." La eficacia sólo se fija en si se alcanzan los objetivos definidos, y no en la forma en que se alcanzan. 1.13. Productividad La productividad es la relación entre la producción sobre la entrada desde una perspectiva económica. La salida es el valor entregado. Entrada abarca todos los recursos (por ejemplo, esfuerzo) pasaron para generar la salida. Productividad combina eficiencia y eficacia desde una perspectiva orientada hacia los valores: la maximización de la productividad es sobre la generación de mayor valor con menor consumo de recursos. 2. La vida de ciclo Economía 2.1. Producto Un producto es un bien económico (o salida) que se crea en un proceso que transforma los factores del producto (o insumos) a una salida. Cuando se vende, el producto es un entregable que crea un valor y una experiencia para sus usuarios. Un producto puede ser una combinación de sistemas, soluciones, materiales, y servicios entregados internamente (por ejemplo, en la casa solución IT) o externamente (por ejemplo, la aplicación de software), o bien

como está o como un componente para otro producto (por ejemplo, software integrado). 2.2. Proyecto Un proyecto es "un esfuerzo temporal emprendido para crear un producto único, servicio o resultado". En la ingeniería de software, diferentes tipos de proyectos se distinguen (por ejemplo, el desarrollo de productos, servicios de terceros, mantenimiento de software, creación de servicios, etc.). Durante su ciclo de vida, un producto de software puede requerir muchos proyectos. Por ejemplo, durante la fase de concepción del producto, un proyecto podría llevarse a cabo para determinar los requisitos de necesidad del cliente y del mercado; durante el mantenimiento, un proyecto podría llevarse a cabo para producir una próxima versión de un producto. 2.3. Programa Un programa es "un grupo de proyectos relacionados, subprogramas y actividades del programa que gestiona de manera coordinada para obtener beneficios que no están disponibles desde la gestión de ellos individualmente." Los programas se utilizan a menudo para identificar y gestionar las diferentes entregas a un solo cliente o mercado a través de un horizonte de tiempo de varios años. 2.4. Portafolio Los portafolios son "proyectos, programas, subcarteras, y las operaciones gestionadas como un grupo para alcanzar los objetivos estratégicos." carteras se utilizan para agrupar y gestionar simultáneamente todos los activos dentro de una línea de negocio u organización. Mirando a la totalidad de una cartera se asegura de que los impactos de las decisiones se consideran, por ejemplo, la asignación de recursos a un proyecto específico, lo cual significa que los mismos recursos no están disponibles para otros proyectos.

2.5. Ciclo de vida del producto Un ciclo de vida del producto de software (SPLC) incluye todas las actividades necesarias para definir, construir, operar, mantener y retirar un producto o servicio software y sus variantes. Las actividades SPLC de "operar" "Mantener" y "retirarse" suelen ocurrir en un período de tiempo mucho más largo que el desarrollo inicial del software (software de vida de desarrollo del ciclo de SDLC-ver el ciclo vital del Software Los modelos de la Ingeniería de Procesos de Software KA). Asimismo, la operación-Mantener-retire actividades de una SPLC consumen generalmente más esfuerzo total y otros recursos de las actividades SDLC (ver La mayoría de los costos de mantenimiento en el software Mantenimiento KA). El valor aportado por un producto de software o servicios asociados se puede determinar objetivamente durante el marco de "operar y mantener el" tiempo. Software de ingeniería de la economía debe estar preocupado con todas las actividades de SPLC, incluyendo las actividades después de la liberación inicial del producto. 2.6. Ciclo de Vida del Proyecto Las actividades del ciclo de vida del proyecto implican típicamente cinco grupos de iniciación de procesos, Planificación, Ejecución, seguimiento y control, y cierre (véase el KA , administración de ingeniería Software). Las actividades dentro de un ciclo de vida del proyecto de software son a menudo intercalada, se superponen, y repetir en diversas formas (véase el Software Ingeniería de Procesos KA). Por ejemplo, el desarrollo de productos ágil dentro de un SPLC implica múltiples iteraciones que producen incrementos de software entregable. Un SPLC debe incluir la gestión de riesgos y la sincronización con diferentes proveedores (si lo hay), mientras que el suministro de información de toma de decisiones auditable (por ejemplo, que cumpla con las

necesidades de responsabilidad de productos o las reglas de gobierno). El ciclo de vida del proyecto de software y el software de ciclo de vida del producto están relacionados entre sí; un SPLC puede incluir varios SDLCs. 2.7. Propuestas Tomar una decisión de negocios comienza con la noción de una propuesta. Las propuestas se refieren a alcanzar un objetivo de negocio-en el proyecto, producto o nivel de la cartera. Una propuesta es una opción única, separada que se está considerando, como llevar a cabo un proyecto de desarrollo de software en particular o no. Otra propuesta podría ser para mejorar un componente de software existente, y todavía podría ser otra que volver a desarrollar mismo software desde cero. Cada propuesta representa una unidad de elección, ya sea que usted puede elegir para llevar a cabo esta propuesta o puede optar por no hacerlo. Todo el propósito de la toma de decisiones de negocio es averiguar, dadas las circunstancias actuales del negocio, que las propuestas deben llevarse a cabo y cuáles no. 2.8. Decisiones de inversión Los inversores toman decisiones de inversión para gastar dinero y recursos en la consecución de un objetivo de destino. Los inversores están ya sea en el interior (por ejemplo, las finanzas, la placa) o fuera (por ejemplo, bancos) de la organización. El objetivo se relaciona con algunos criterios económicos, tales como el logro de un alto retorno de la inversión, el fortalecimiento de las capacidades de la organización, o de mejorar el valor de la empresa. Aspectos intangibles como la buena voluntad, la cultura, y las competencias deben ser considerados. 2.9. Horizonte de Planificación Cuando una organización decide invertir en una propuesta en particular, el dinero está

amarrado en el que propuesta- los llamados "activos congelados." El impacto económico de los bienes congelados tiende a comenzar y disminuye con el tiempo. Por otro lado, los costos de operación y mantenimiento de los elementos asociados con la propuesta tienden a comenzar baja, pero aumentará con el tiempo. El costo total de la propuesta, es decir, poseer y operar un producto es la suma de estos dos costos. Al principio, los costos de los activos congelados dominan; más tarde, los costos de operación y mantenimiento dominan. Hay un punto en el tiempo donde se minimiza la suma de los costes; esto se denomina la vida útil de coste mínimo. Para comparar adecuadamente una propuesta con una vida útil cuatro años a una propuesta con una vida útil de seis años, los efectos económicos de cualquiera de cortar la propuesta de seis años por dos años o invertir los beneficios de la propuesta de cuatro años por otros dos años necesitan ser dirigido. El horizonte de planificación, a veces conocido como el período de estudio, es el marco de tiempo constante durante los cuales se consideran propuestas. Tendrán que tenerse en cuenta en el establecimiento de un horizonte de planificación efectos como tiempo de vida del software. Una vez establecido el horizonte de planificación, varias técnicas están disponibles para presentar propuestas con diferentes períodos de la vida en ese horizonte de planificación. 2.10. Precio y precios Un precio es lo que se paga a cambio de un bien o servicio. El precio es un aspecto fundamental de la modelización financiera y es una de las cuatro P de la comercialización mixta. Las otras tres p son producto, promoción y lugar. El precio es el único elemento que genera ingresos entre las cuatro P; el resto son los costos. El precio es un elemento de finanzas y marketing. Es el proceso de determinar lo que una empresa recibirá a cambio de sus

productos. Factores de fijación de precios incluyen los costes de fabricación, colocación en el mercado, la competencia, las condiciones del mercado, y la calidad del producto. La fijación de precios se aplica a los precios de productos y servicios basados en factores tales como cantidad fija, rotura cantidad, promoción o campaña de ventas, cita específica del proveedor, el envío o la fecha de la factura, la combinación de varios pedidos, ofertas de servicios, y muchos otros. Las necesidades del consumidor se pueden convertir en la demanda sólo si el consumidor tiene la voluntad y la capacidad para comprar el producto. Por lo tanto, la fijación de precios es muy importante en la comercialización. Los precios se realizaron inicialmente en la fase inicial del proyecto y es una parte de la toma de decisiones "ir". 2.11. Costo y costeo Un coste es el valor del dinero que se ha utilizado para producir algo y, por lo tanto, no está disponible para su uso nunca más. En economía, un coste es una alternativa que se da como resultado de una decisión. Un costo hundido es los gastos antes de un cierto tiempo, normalmente se utiliza para decisiones abstractas de los gastos en el pasado, lo que puede causar obstáculos emocionales en el futuro. Desde un punto de vista económico tradicional, los costos hundidos no deben ser considerados en la toma de decisiones. El costo de oportunidad es el coste de uno alternativo que deben ser sacrificados con el fin de seguir otra alternativa. Cálculo de costos es parte de la financiación y gestión de productos. Es el proceso para determinar el costo basado en los gastos (por ejemplo, la producción, ingeniería de software, distribución, rehace) y sobre el costo objetivo de ser competitivos y exitosos en un mercado. El costo de destino puede estar por debajo del costo estimado real. La planificación y el

control de estos costos (llamada de gestión de costes) es importante y siempre deben ser incluidos en los costos. Un concepto importante en los costes es el coste total de propiedad (TCO). Esto es válido especialmente para el software, porque hay muchos costos no tan obvias relacionadas con las actividades de SPLC después del desarrollo inicial del producto. TCO para un producto de software se define como el costo total de la adquisición, activar y mantener ese producto en funcionamiento. Estos costos pueden agruparse como los costes directos e indirectos. TCO es un método de contabilidad que es crucial en la toma de decisiones económicas. 2.12. Medición del desempeño La medición del desempeño es el proceso mediante el cual una organización establece y mide los parámetros utilizados para determinar si los programas, inversiones y adquisiciones están logrando los resultados deseados. Se utiliza para evaluar si realmente se cumplen los objetivos de rendimiento; para controlar los presupuestos, los recursos, los avances y decisiones; y para mejorar el rendimiento. 2.13. Gestión del valor ganado Gestión del valor ganado (EVM) es una técnica de gestión de proyectos para medir el progreso basado en el valor creado. En un momento dado, los resultados obtenidos hasta la fecha en un proyecto se comparan con el presupuesto proyectado y el progreso calendario previsto para esa fecha. El progreso se refiere ya los recursos consumidos, y ha logrado resultados en un punto dado en el tiempo con los respectivos valores previstos para la misma fecha. Ayuda a identificar los posibles problemas de rendimiento en una etapa temprana. Un principio clave en la EVM es el seguimiento de las variaciones del coste y del horario a través de la comparación de los programada versus planificación real y el presupuesto frente a los costos reales. Seguimiento EVM

da una visibilidad mucho más temprano a las desviaciones y por lo tanto permite correcciones antes de lo clásico y el costo de seguimiento horario que sólo se basa en documentos y productos entregados. 2.14. Las decisiones de terminación El cese significa poner fin a un proyecto o producto. La terminación puede ser planificada de antemano para el final de una larga vida del producto (por ejemplo, cuando previendo que un producto llegue a su vida) o puede venir en lugar espontáneamente durante el desarrollo de productos (por ejemplo, cuando no se logran los objetivos de rendimiento del proyecto). En ambos casos, la decisión debe ser cuidadosamente preparada, teniendo en cuenta siempre las alternativas de continuidad versus terminación. Los costos de las diferentes alternativas deben estimarse que cubre temas tales como el reemplazo, la recopilación de información, los proveedores, las alternativas, los activos y los recursos que utilizan para otras oportunidades. Los costos hundidos no deben ser considerados en dicha toma de decisiones, ya que se han gastado y no volverá a aparecer como un valor.

2.15. Las decisiones de recambio y jubilación Una decisión de reemplazo se establece cuando una organización que ya tiene un activo en particular y que están considerando la posibilidad de su sustitución por otra cosa; por ejemplo, decidir entre mantener y apoyar un producto de software legado o volver a desarrollar desde el principio. Las decisiones de reemplazo utilizan el mismo proceso de decisión de negocios como se ha descrito anteriormente, pero hay retos adicionales: costo hundido y valor de rescate. Las decisiones de retiro son también trata de salir de una actividad en conjunto, por ejemplo, cuando una empresa de software no considera la venta de un producto de software más o un fabricante de hardware no considera la construcción y venta de un determinado modelo de equipo por más tiempo. Decisión retiro puede estar influenciada por factores de bloqueo en la tecnología como la dependencia y los altos costos de salida. 3. Riesgo e Incertidumbre 3.1. Metas, estimaciones, y Planes Goles en la economía de ingeniería de software son en su mayoría los objetivos de negocio (u objetivos de negocio). Uno de los objetivos de negocio se refiere necesidades empresariales (como el aumento de la rentabilidad) a los recursos de inversión (tales como iniciar un proyecto o el lanzamiento de un producto con un determinado presupuesto, contenido y el tiempo). Objetivos se aplican a la planificación operativa (por ejemplo, para llegar a un determinado hito en una fecha determinada o para ampliar las pruebas de software por un cierto tiempo para conseguir una calidad de nivel ver Cuestiones claves deseadas en el Software Prueba de KA) y para el nivel estratégico (como llegar a una cierta rentabilidad o la cuota de mercado en un período de tiempo establecido).

Una estimación es una evaluación fundada de recursos y el tiempo que serán necesarios para lograr los objetivos establecidos (ver Esfuerzo, Calendario, y Estimación de Costos en la Gestión de Ingeniería de Software KA y mantenimiento Estimación de costes en el mantenimiento del software KA). Una estimación de software se utiliza para determinar si los objetivos del proyecto se puede lograr dentro de las restricciones sobre los atributos programación, presupuesto, características y calidad. Las estimaciones son típicamente generadas internamente y no son necesariamente visibles externamente. Las estimaciones no deben ser conducidas exclusivamente por los objetivos del proyecto, ya que esto podría hacer una estimación demasiado optimista. La estimación es una actividad periódica; estimaciones deben ser revisados continuamente durante un proyecto. Un plan describe las actividades e hitos que son necesarias para alcanzar los objetivos de un proyecto (véase el software de planificación en el KA administración de ingeniería de Software). El plan debe estar en línea con el objetivo y la estimación, que no es necesariamente fácil y obvio- por ejemplo, cuando un proyecto de software con los requisitos dados tomaría más tiempo que la fecha límite prevista por el cliente. En tales casos, los planes exigen una revisión de los objetivos iníciales, así como las estimaciones y las incertidumbres e imprecisiones subyacentes. Soluciones creativas con los fundamentos del sistema de lograr una posición de ganar-ganar se aplican para resolver conflictos. Para ser de valor, la planificación debe incluir el examen de las limitaciones del proyecto y los compromisos con los grupos de interés. La figura 12.4 muestra cómo se definen los objetivos inicialmente. Los cálculos se realizan sobre la base de los objetivos iníciales. El plan intenta hacer coincidir los objetivos y las estimaciones. Este es un proceso iterativo, debido a una estimación

inicial normalmente no cumple con los objetivos iníciales. 3.2. Las técnicas de estimación Las estimaciones se utilizan para analizar y pronosticar los recursos o el tiempo necesario para implementar los requisitos (ver Esfuerzo, Calendario, y Estimación de Costos de la Ingeniería de Software de Gestión de KA y Estimación de Costos de mantenimiento en el software Mantenimiento KA). Existen cinco familias de técnicas de estimación:

• La opinión de expertos • Analogía • Estimación de las piezas • Los métodos para métricos • Métodos de estadística. •

Ninguna técnica de estimación única es perfecta, por lo que el uso de la técnica de estimación múltiple es útil. La convergencia entre las estimaciones producidas por diferentes técnicas indica que las estimaciones son probablemente exactas. Difusión entre las estimaciones indican que ciertos factores pueden haber sido pasados por alto. La búsqueda de los factores que causaron la propagación y luego volver a estimar de nuevo para producir resultados que convergen podría conducir a una mejor estimación. 3.3. La incertidumbre de direccionamiento Debido a los muchos factores desconocidos durante la iniciación y planificación de proyectos, las estimaciones son inciertas; que la incertidumbre debe tratarse en las decisiones de negocios. Las técnicas para hacer frente a la incertidumbre incluyen:

• Considerar rangos de estimaciones • Analizar la sensibilidad a los cambios

de las hipótesis • Retardo de las decisiones finales.

3.4. Priorización

Priorización implica alternativas de clasificación basada en criterios comunes para ofrecer el mejor valor posible. En los proyectos de ingeniería de software, requisitos de software a menudo se priorizan con el fin de ofrecer el mayor valor para el cliente dentro de las limitaciones de programación, presupuesto, recursos y tecnología, o para proporcionar para la construcción de incrementos de productos, donde los primeros incrementos proporcionan el valor más alto de la al cliente (ver Requisitos de clasificación y la Negociación en los requisitos de software y software KA Modelos de Ciclo de Vida de la Ingeniería de Software Proceso KA). 3.5. Decisiones en el ámbito de Riesgos Las decisiones técnicas de bajo riesgo se utilizan cuando el tomador de decisiones puede asignar probabilidades a los diferentes resultados posibles (véase Gestión de Riesgos en el KA administración Software). Las técnicas específicas incluyen

• Toma de decisiones valor esperado • Variación de la expectativa y la toma

de decisiones • Análisis de Monte Carlo • Arboles de decisión • Valor esperado de la información

perfecta.

• 3.6. Las decisiones bajo incertidumbre Las decisiones bajo incertidumbre técnicas se utilizan cuando el tomador de decisiones no puede asignar probabilidades a los diferentes resultados posibles porque la información necesaria no está disponible (véase Gestión de Riesgos en el KA administración de ingeniería de Software). Las técnicas específicas incluyen:

• Regla de Laplace • Regla Maximin • Regla Maximax • Regla Hurwicz • Regla Pesar Minimax. •

4. Métodos de Análisis Económico 4.1. Con fines de lucro Análisis de Decisiones La figura 12.5 describe un proceso para identificar la mejor alternativa de un conjunto de alternativas mutuamente excluyentes. Los criterios de decisión dependen de los objetivos de negocio y por lo general incluyen ROI (Ver sección 4.3, Retorno de la Inversión) o Retorno sobre el capital empleado (ROCE) (ver sección 4.4, Retorno sobre el capital empleado).

Para fines de lucro técnicas de toma no se aplican a las organizaciones gubernamentales y sin fines de lucro. En estos casos, las organizaciones tienen diferentes objetivos, lo que significa que se necesita un conjunto diferente de las técnicas de toma, como el coste-beneficio o análisis de coste-efectividad. 4.2. Tasa de retorno mínima aceptable La tasa mínima aceptable de rendimiento (TREMA) es la tasa interna de retorno más bajo de la organización consideraría como una buena inversión. En términos generales, no sería inteligente de invertir una actividad con un rendimiento del 10% cuando no hay otra actividad que se sabe que devolver el 20%. La TREMA es una declaración de que una organización confía en que puede lograr al menos que la tasa de rendimiento. La TREMA representa el costo de oportunidad de la organización para las inversiones. Al elegir a invertir en algún tipo de actividad, la organización está decidiendo explícitamente a no invertir ese mismo dinero en otro lugar. Si la organización es ya confía en que puede conseguir un poco de velocidad conocida de retorno, otras alternativas deben elegirse sólo si su tasa de rendimiento es por lo menos tan alto. Una forma sencilla de dar cuenta de que el costo de oportunidad es utilizar la TREMA como la tasa de interés en las decisiones empresariales. Valor actual de una alternativa evaluada en el TREMA muestra cuánto más o menos (en términos de efectivo presente- día) que vale la pena alternativa es que la inversión en la TREMA. 4.3. Retorno de la Inversión Retorno de la inversión (ROI) es una medida de la rentabilidad de una unidad de empresa o negocio. Se define como la relación entre el dinero ganado o perdido (realizadas o no realizadas) en una inversión con respecto a la cantidad de dinero invertido. El propósito del retorno de la inversión varía e incluye, por ejemplo, proporcionando una base para

futuras inversiones y decisiones de adquisición. 4.4. Rendimiento del capital invertido El retorno sobre el capital empleado (ROCE) es una medida de la rentabilidad de una unidad de empresa o negocio. Se define como la relación de un beneficio bruto antes de impuestos e intereses (EBIT) para el total de activos menos pasivos corrientes. En él se describe el rendimiento del capital utilizado. 4.5. Análisis coste-beneficio El análisis de costo-beneficio es uno de los métodos más utilizados para evaluar las propuestas individuales. Cualquier propuesta con una relación beneficio-costo de menos de 1,0 por lo general puede ser rechazada sin más análisis porque costaría más que el beneficio. Las propuestas con una proporción más alta necesidad de tener en cuenta el riesgo asociado de una inversión y comparar los beneficios con la opción de invertir el dinero a una tasa de interés garantizada (ver sección 4.2, tasa aceptable de retorno mínima). 4.6. Análisis coste-efectividad Análisis coste-efectividad es similar al análisis de costo-beneficio. Hay dos versiones de análisis de coste-efectividad: la versión de costos fijos maximiza el beneficio dado alguna cota superior en el precio; la versión de la eficacia fija minimiza el costo necesario para lograr un objetivo fijo. 4.7. Punto de equilibrio de análisis El análisis del punto de equilibrio identifica el punto en que los costos de desarrollo de un producto y los ingresos que se generen son iguales. Tal análisis se puede utilizar para elegir entre diferentes propuestas a diferentes costos estimados y los ingresos. Teniendo en cuenta los costes e ingresos de dos o más propuestas se estima, el análisis del punto de equilibrio ayuda a la hora de elegir entre ellos.

4.8. Modelo de Negocio El modelo de negocio es la información consolidada resumir y explicar una propuesta de negocio desde diferentes perspectivas para un tomador de decisiones (costo, beneficios, riesgos, y así sucesivamente). A menudo se utiliza para evaluar el valor potencial de un producto, que puede ser utilizado como base en el proceso de toma de decisiones de inversión. A diferencia de un mero cálculo perdida de los beneficios, el modelo de negocio es un "caso" de los planes y análisis que es propiedad de la gerente de producto y se utiliza en apoyo de la consecución de los objetivos de negocio. 4.9. Evaluación Atributo múltiple Los temas tratados hasta ahora se utilizan para tomar decisiones basadas en un único criterio de decisión: el dinero. La alternativa con el mejor valor actual, el mejor retorno de la inversión, y así sucesivamente es la seleccionada. Aparte de viabilidad técnica, el dinero es casi siempre el criterio de decisión más importante, pero no es siempre el único. Muy a menudo hay otros criterios, otros "atributos", que deben ser considerados, y esos atributos no pueden ser emitidos en términos de dinero. Técnicas de toma de atributos múltiples permiten otros criterios, no financieros a ser un factor en la decisión. Hay dos familias de múltiples técnicas de toma de atributos que difieren en la forma en que utilizan los atributos en la decisión. Una familia es la "compensación" o sobredimensionados individuales, técnicas. Esta familia se derrumba todos los atributos en un único factor de mérito. La familia está llamada compensatoria, ya que, para cualquier alternativa dada, una puntuación más baja en un atributo puede ser compensada por objeto de comercio frente una puntuación más alta en otros atributos. Las técnicas de compensación incluyen

• Escala dimensional • Ponderación aditiva

• Proceso analítico jerárquico. Por el contrario, la otra familia es el "no compensatorios," o totalmente dimensionado, técnicas. Esta familia no permite concesiones entre los atributos. Cada atributo es tratado como una entidad separada en el proceso de decisión. Las técnicas no compensatorias incluyen

• Dominio • Satisfaciente(satisfacción y suficiente

término empleado por Herbert simón)

• Lexicografía. 4.10. Análisis de optimización El uso típico de análisis de optimización es el estudio de una función de coste en un rango de valores para encontrar el punto en el que el rendimiento general es mejor. Clásico equilibrio espacio-tiempo de software es un ejemplo de optimización; un algoritmo que se ejecuta más rápido a menudo utilizará más memoria. Optimización equilibra el valor del tiempo de ejecución más rápida contra el costo de la memoria adicional. El análisis de opciones reales se puede usar para cuantificar el valor de opciones de proyectos, incluyendo el valor de retrasar una decisión. Esas opciones son difíciles de calcular con precisión. Sin embargo, la conciencia de que las opciones tienen un valor monetario proporciona la penetración en el calendario de las decisiones tales como el aumento de personal del proyecto o alargando el tiempo de comercialización para mejorar la calidad. 5. Consideraciones prácticas 5.1. El "suficientemente buen" Principio A menudo los proyectos de ingeniería de software y productos no son precisos acerca de los objetivos que se deben alcanzar. Requisitos de software se expresan, pero el valor marginal de agregar un poco más de funcionalidad no se pueden medir. El

resultado podría ser la entrega tardía o demasiado alto costo. El "suficientemente bueno" principio se relaciona valor marginal al coste marginal y proporciona una guía para determinar los criterios cuando un entregable es "suficientemente bueno" para ser entregados. Estos criterios dependen de los objetivos del negocio y en la priorización de las distintas alternativas, tales como la clasificación de los requisitos de software, los atributos de calidad medibles, o relativas a la programación de contenido y coste del producto. El principio RACE (reducir los accidentes y la esencia de control) es un gobierno popular hacia un buen software suficiente. Accidentes implican gastos innecesarios como la sobre regulación y reproceso debido a la eliminación de defectos tarde o demasiado muchos cambios requisitos. La esencia es lo que los clientes pagan por. La economía de ingeniería de software proporciona los mecanismos para definir los criterios que determinan cuándo un entregable es "suficientemente bueno" para ser entregados. También destaca que ambas palabras son relevantes "bueno" y "lo suficiente." Insuficiente calidad o cantidad insuficiente no es lo suficientemente bueno. Los métodos ágiles son ejemplos de "suficientemente bueno" que tratan de optimizar el valor mediante la reducción de la sobrecarga de la reanudación tardía y el chapado de oro que resulta de la adición de características que tienen valor marginal baja para los usuarios (ver Métodos ágiles en los modelos de ingeniería de software y métodos KA y Software Modelos de Ciclo de vida del Software Ingeniería de Procesos KA). En los métodos ágiles, planificación detallada y largas fases de desarrollo son reemplazadas por una planificación progresiva y la entrega frecuente de pequeños incrementos de un producto

concreto que se ponen a prueba y evaluadas por representantes de los usuarios. 5.2. La Fricción Economía Libre La fricción económica es todo lo que mantiene a los mercados de tener competencia perfecta. Se trata de distancia, el costo de la entrega, las regulaciones restrictivas, y / o información imperfecta. En los mercados de alta fricción, los clientes no tienen muchos proveedores entre los que elegir. Después de haber sido en un negocio por un tiempo o ser propietario de una tienda en una buena ubicación determina la posición económica. Es difícil para nuevos competidores para iniciar negocios y competir. El mercado se mueve lentamente y de manera previsible. Mercados libres de fricción son justo lo contrario. Surgen nuevos competidores y los clientes son rápidos en responder. El mercado es cualquier cosa menos predecible. En teoría, el software y TI son libres de fricción. Las nuevas empresas pueden crear fácilmente los productos y a menudo lo hacen a un costo mucho más bajo que las empresas establecidas, ya que no tendrá que considerar cualquier legado. Marketing y ventas se pueden hacer a través de Internet y las redes sociales, y, básicamente, los mecanismos de distribución gratuita pueden habilitar una rampa hasta un negocio global. La economía de ingeniería de software tiene como objetivo proporcionar una base para juzgar cómo un negocio de software lleva a cabo y cómo libre de fricción de un mercado que realmente es. Por ejemplo, la competencia entre los desarrolladores de aplicaciones de software se inhibe cuando las aplicaciones deben ser vendidas a través de una tienda de aplicaciones y cumplen con las reglas de ese almacén. 5.3. Ecosistemas Un ecosistema es un entorno compuesto por todas las partes interesadas mutuamente

dependientes, unidades de negocio y empresas que trabajan en un área particular. En un ecosistema típico, hay productores y consumidores, en los que los consumidores agregan valor a los recursos consumidos. Tenga en cuenta que un consumidor no es el usuario final, sino una organización que utiliza el producto para mejorarla. Un ecosistema de software es, por ejemplo, un proveedor de una aplicación trabajando con las empresas que hacen la instalación y el apoyo en las diferentes regiones. Ninguno de los dos podría existir sin el otro. Los ecosistemas pueden ser permanentes o temporales. La economía de ingeniería de software proporciona los mecanismos para evaluar alternativas en el establecimiento o la ampliación de una instancia ecosistema para, evaluar si trabajar con un distribuidor específico o tener la distribución realizada por una empresa que realiza el servicio en un área. 5.4. La deslocalización y la externalización La deslocalización significa la ejecución de una actividad de negocio más allá de las ventas y la comercialización fuera del país de origen de una empresa. Las empresas típicamente tienen sus ramas deslocalización de bajo coste o países que piden las empresas especializadas en el extranjero para llevar a cabo la actividad respectiva. La deslocalización tanto, no debe confundirse con la externalización. La deslocalización dentro de una empresa se llama deslocalización cautiva. La subcontratación es la relación pragmático con un proveedor que realiza actividades de negocio de una empresa, siempre, tradicionalmente, esas actividades fueron ejecutadas dentro de la empresa. La externalización es un sitio independiente. El proveedor puede residir en la vecindad de la empresa o en alta mar (deslocalización subcontratado). La economía de ingeniería de software proporciona los criterios básicos y las herramientas de negocio para evaluar

diferentes mecanismos de aprovisionamiento y controlar su rendimiento. Por ejemplo, el uso de un proveedor de externalización para el desarrollo y mantenimiento de software podría reducir el coste por hora de desarrollo de software, pero aumentar el número de horas y gastos de capital debido a una mayor

necesidad de seguimiento y comunicación. (Para obtener más información sobre la deslocalización y la externalización, consulte "externalización" en cuestiones de gestión en el mantenimiento del software KA).

LECTURAS

Una guía para la Dirección de Proyectos

Conocimiento, La Guía PMBOK ® proporciona

directrices para la gestión de proyectos

individuales y define conceptos relacionados

con la gestión de proyectos. También se

describe el ciclo de vida del proyecto de

gestión y sus procesos relacionados, así

como el ciclo de vida del proyecto. Es una

guía reconocida a nivel mundial para la

profesión de gestión de proyectos.

Software de Extensión de la Guía para la

Dirección de Proyectos del Conocimiento

(SWX).

SWX ofrece adaptaciones y ampliaciones de

las prácticas genéricas de gestión de

proyectos documentados en la Guía PMBOK

® para la gestión de proyectos de software.

La principal contribución de esta extensión

de la Guía del PMBOK® es la descripción de

los procesos que son aplicables para la

gestión de proyectos de software de ciclo de

vida de adaptación.

B. W. Boehm, Software Economía Ingeniería.

Este libro es la lectura de clásicos de

economía, ingeniería de software.

Proporciona una visión general del

pensamiento empresarial en ingeniería de

software.

Aunque los ejemplos y figuras son

anticuados, todavía vale la pena leer.

C. y R. Ebert Dumke, de software de

medición

Este libro ofrece una visión general sobre los

métodos cuantitativos en la ingeniería de

software, comenzando con la teoría de la

medida y se dirijan hacia la gestión del

rendimiento y la toma de decisiones de

negocio.

DJ. Reifer, En defensa de Business Software:

Mejora por los números.

Este libro es una lectura clásica en la

fabricación de un modelo de negocio en las

empresas de software y de TI. Muchos

ejemplos útiles ilustran cómo el modelo de

negocio se formula y se cuantifica.

Referencias

[1 *] S. Tockey, el rendimiento de software:

Maximizar el retorno de la inversión en

software, Addison-Wesley, 2004.

[2 *] J.H. Allen et al., Seguridad Software

Ingeniería: Una guía para los gestores de

proyectos, Addison-Wesley, 2008.

[3 *] R.E. Fairley, Gestión y líder Los

proyectos de software, Wiley-IEEE Computer

Society Press, 2009.

[4] Project Management Institute, Guía a la

Dirección de Proyectos (PMBOK (R) Guía), 5ª

ed., Project Management Institute, 2013.

[5] Instituto de Gestión de Proyectos e IEEE

Computer Society, software de la extensión

la Guía PMBOK quinta edición, ed: Project

Management Institute, 2013.

[6] B.W. Boehm, Ingeniería de Software

Economía, Prentice-Hall, 1981.

[7] C. y R. Ebert Dumke, Software Medición,

Springer, 2007.

[8] D.J. Reifer, la empresa fabricante de

software Caso: Mejoramiento por los

números, Addison Wesley, 2002.

CAPÍTULO 13 FUNDAMENTOS DE INFORMATICA INTRODUCCIÓN El alcance de la zona Fundamentos de computación conocimiento (KA) abarca el desarrollo y el medio ambiente operacional en el que el software evoluciona y ejecuta. Debido a que ningún software puede existir en un vacío o correr sin un ordenador, el núcleo de un entorno de este tipo es el ordenador y sus diversos componentes. El conocimiento acerca de la computadora y

sus principios subyacentes de hardware y software sirve como un marco en el que se ancla la ingeniería de software. Por lo tanto, todos los ingenieros de software deben tener una buena comprensión de los Fundamentos de computación KA. En general se acepta que la ingeniería de software se basa en la parte superior de la informática. Por ejemplo, "Ingeniería de Software 2004: Plan de estudios Directrices para la Licenciatura Los programas en Ingeniería de Software " establece claramente," Un aspecto particularmente importante es que la ingeniería de software se basa en la informática y las matemáticas "(la cursiva es nuestra).

Steve Tockey escribió en su libro Retorno de Software: Ambas tratan de ciencias de la computación e ingeniería de software con ordenadores, computación y software. La ciencia de la computación, como un conjunto de conocimientos, está en el centro de ambos.13-2, Ingeniería de software se ocupa de la aplicación de las computadoras, informática y software para fines prácticos, en concreto el diseño, construcción y operación de sistemas de software eficiente y económico. Por lo tanto, en el centro de ingeniería de software es una comprensión de la informática. Aunque pocas personas negarán la

informática juegos de rol en el desarrollo de la ingeniería de software, tanto como disciplina y como un conjunto de conocimientos, la importancia de la informática para la ingeniería de software no se puede exagerar; por lo tanto, este Fundamentos de computación KA está siendo escrito. La mayoría de los temas tratados en los Fundamentos de computación KA también son temas de discusión en los cursos básicos que figuran en los programas de grado y posgrado de la informática. Dichos cursos incluyen la programación, estructura de datos, algoritmos, organización de computadores, sistemas operativos, compiladores, bases de datos, redes,

sistemas distribuidos, y así sucesivamente. Por lo tanto, cuando rompiendo tópicos, puede ser tentador para descomponer los Fundamentos de computación KA acuerdo con estas divisiones a menudo se encuentran en-cursos pertinentes. Sin embargo, una división basada curso-puramente de temas sufre graves inconvenientes. Por un lado, no todos los cursos de informática están relacionados o igualmente importantes para la ingeniería de software. Por lo tanto, algunos de los temas que de otra forma estarían cubiertos en un curso de informática no están cubiertos en este KA. Por ejemplo, los gráficos de ordenador, mientras que un curso importante en un programa de grado de la informática, no se incluye en este KA. En segundo lugar, algunos de los temas tratados en esta directriz no existen como cursos independientes de programas informáticos de grado y posgrado. En consecuencia, dichos temas no pueden ser cubiertos adecuadamente en un desglose basado curso de pureza. Por ejemplo, la abstracción es un tema incorporado en varios cursos de informática diferentes; no está claro qué abstracción curso deben pertenecer a una avería basada en el transcurso de los temas. El Fundamentos de computación KA se divide en diecisiete temas diferentes. Utilidad directa de un tema para los ingenieros de software es el criterio utilizado para la selección de temas para su inclusión en este KA (véase la figura 13.1). La ventaja de esta distribución basada en el tema es su fundamento en la creencia de que la computación fundaciones- si ha de ser agarrada firmemente-debe considerarse como una colección de temas conectadas lógicamente la ingeniería de software en general y ciñendo la construcción de software en particular. El Fundamentos de computación KA está relacionado estrechamente con el Diseño de Software, Software de construcción,

Pruebas de software, mantenimiento de software, Calidad del Software, y las fundaciones Kas matemáticos. DISTRIBUCIÓN DE TEMAS PARA FUNDAMENTOS DE INFORMATICA El desglose de los temas de los Fundamentos de computación KA se muestra en la figura 13.1. Fundamentos de computación 13-3 1. Técnicas de Resolución de Problemas Los conceptos, nociones y terminología introducida aquí constituyen una base fundamental para el conocimiento de la función y el alcance de las técnicas de resolución de problemas. 1.1. Definición de resolución de problemas La resolución de problemas se refiere a la forma de pensar y actividades que se realizan para responder o derivar una solución a un problema. Hay muchas maneras de abordar un problema, y cada trayecto emplea diferentes herramientas y utiliza diferentes procesos. Estas diferentes formas de abordar los problemas y poco a poco ampliar definen a sí mismos y, finalmente, dan lugar a diferentes disciplinas. Por ejemplo, la ingeniería de software se centra en la resolución de problemas utilizando ordenadores y software. Si bien los distintos problemas garantizan soluciones diferentes y pueden requerir diferentes herramientas y procesos, la metodología y las técnicas utilizadas en la solución de problemas hacen seguir algunas directrices y, a menudo se pueden generalizar como las técnicas de resolución de problemas. Por ejemplo, una pauta general para la resolución de un problema de ingeniería genérica es utilizar el proceso de tres pasos que figura a continuación.

• Formular el problema real. • Analizar el problema. • Diseñar una estrategia de búsqueda

de solución.

1.2. Formular el problema real Gerard Voland escribe: "Es importante reconocer que un problema específico debe formularse si uno va a desarrollar una solución específica". Esta formulación se llama el planteamiento del problema, que especifica explícitamente lo tanto el problema como el resultado deseado son. Aunque no hay forma universal de la que indica un problema, en general un problema debe expresarse de una manera tal como para facilitar el desarrollo de soluciones. Algunas técnicas generales para ayudar a uno formular el problema real incluyen la declaración re expresión, determinar el origen y la causa, la revisión de la declaración, analizando el estado actual y el deseado, y utilizando el enfoque del ojo fresco. 1.3. Analizar el problema Una vez que el planteamiento del problema se encuentra disponible, el siguiente paso es analizar el planteamiento del problema o situación para ayudar a estructurar nuestra búsqueda de una solución. Cuatro tipos de análisis incluyen análisis de la situación, en la que se identifican en primer lugar los aspectos más urgentes o importantes de una situación; análisis de problemas, en la que se debe determinar la causa del problema; análisis de decisión, en el que la acción necesaria (s) para corregir el problema o eliminar su causa debe ser determinada; y análisis del problema potencial, en el que necesita la acción (s) para prevenir cualquier recurrencia de el problema o el desarrollo de nuevos problemas debe ser determinado. 1.4. Diseñar una estrategia de búsqueda de soluciones Una vez que el análisis de los problemas es completo, podemos centrarnos en la estructuración de una estrategia de búsqueda para encontrar la solución. Con el

fin de encontrar la "mejor" solución (en este caso, "mejor" puede significar cosas diferentes para personas diferentes, tales como rápido, más barato, más usables diferentes capacidades, etc.), necesitamos eliminar caminos que no conducen a la viabilidad soluciones, las tareas de diseño de una manera que proporciona la mayor orientación en la búsqueda de una solución, y utilizan diversos atributos del estado de solución final para guiar nuestras decisiones en el proceso de resolución de problemas. 1.5. La resolución de problemas Utilización de programas La singularidad de software de ordenador da la resolución de problemas un sabor que es distinta de la ingeniería general la resolución de problemas. Para resolver un problema utilizando las computadoras, hay que responder a las siguientes preguntas.

• ¿Cómo podemos averiguar qué decirle al equipo?

• ¿Cómo nos convertimos el planteamiento del problema en un algoritmo?

• ¿Cómo podemos convertir el algoritmo en instrucciones de máquina?

La primera tarea en la solución de un problema mediante un ordenador es determinar qué decirle a la computadora que hacer. Puede haber muchas maneras de contar la historia, pero todos deben tener la perspectiva de un equipo de tal manera que el equipo con el tiempo puede resolver el problema. En general, un problema debe expresarse de una manera tal como para facilitar el desarrollo de algoritmos y estructuras de datos para la solución de la misma. El resultado de la primera tarea es una declaración del problema. El siguiente paso es convertir el planteamiento del problema en los algoritmos que resuelven el problema. Una

vez que se encuentra un algoritmo, el paso final convierte el algoritmo en instrucciones de máquina que forman la solución final: software que resuelve el problema. En abstracto hablando, la resolución de problemas utilizando un ordenador puede ser considerado como un proceso de problema de la transformación, en otras palabras, la transformación paso a paso de una declaración del problema en una solución problema. Para la disciplina de la ingeniería de software, el objetivo último de la resolución de problemas es transformar un problema expresado en lenguaje natural en electrones que se ejecutan en un circuito. En general, esta transformación se puede dividir en tres fases: a) El desarrollo de algoritmos de la declaración del problema. b) La aplicación de algoritmos para el problema. c) Transformación de algoritmos para el código del programa. La conversión de un planteamiento del problema en los algoritmos y algoritmos en códigos de programa generalmente sigue un "refinamiento paso a paso" (descomposición a.k.a sistemática) en el que se comienza con una declaración del problema, vuelva a escribir como una tarea, y de forma recursiva descomponer la tarea en unos sub-tareas más simples hasta que la tarea es tan sencilla que las soluciones a que son sencillas. Hay 3 maneras básicas de descomposición: secuenciales, condicionales, e iterativos. 2. Abstracción La abstracción es una técnica indispensable asociado a la resolución de problemas. Se refiere tanto al proceso y el resultado de la generalización mediante la reducción de la información de un concepto, un problema, o un fenómeno observable de manera que uno puede centrarse en el "cuadro grande". Una de las habilidades más importantes en cualquier empresa de ingeniería que se

enmarca la niveles de abstracción apropiadamente. "A través de la abstracción", según Voland, "Vemos el problema y sus posibles vías de solución a partir de un mayor nivel de comprensión conceptual. Como resultado, podemos estar mejor preparados para reconocer posibles relaciones entre los diferentes aspectos del problema y por lo tanto generar más soluciones de diseño creativo". Esto es particularmente cierto en informática en general (tales como hardware vs. software) y en ingeniería de software, en particular (estructura de datos vs. flujo de datos, y así sucesivamente). 2.1. Los niveles de abstracción Cuando la abstracción, nos concentramos en un "nivel" de la gran imagen a la vez con la confianza de que podemos conectar eficazmente con niveles por encima y por debajo. Aunque nos centramos en una sola planta, la abstracción no significa sin saber nada acerca de los niveles vecinos. Niveles de abstracción no se corresponden necesariamente con componentes discretos en la realidad o en el dominio del problema, sino para bien definido de interfaces estándar como las API de programación. Las ventajas que proporcionan interfaces estándar incluyen la portabilidad, la integración de software / hardware más fácil y un uso más amplio. 2.2. La encapsulación La encapsulación es un mecanismo utilizado para implementar la abstracción. Cuando estamos tratando con un nivel de abstracción, la información relativa a los niveles por debajo y por encima de ese nivel se encapsula. Esta información puede ser el concepto, problema o fenómeno observable; o puede ser las operaciones permitidas en estas entidades relevantes. La encapsulación por lo general viene con un cierto grado de ocultación de la información

en la que todos o algunos de los detalles subyacentes están ocultos desde el nivel por encima de la interfaz proporcionada por la abstracción. A un objeto, la ocultación de información significa que no necesitamos saber los detalles de cómo se representa el objeto o cómo se implementan las operaciones sobre dichos objetos. 2.3. Jerarquía Cuando usamos la abstracción en nuestra formulación y solución de problemas, podemos utilizar diferentes abstracciones en diferentes momentos, en otras palabras, con las que trabajamos en diferentes niveles de abstracción como la situación lo requiere. La mayoría de las veces, estos diferentes niveles de abstracción se organizan en una jerarquía. Hay muchas maneras de estructurar una jerarquía particular y los criterios utilizados para determinar el contenido específico de cada capa en la jerarquía varían en función de las personas que realizan el trabajo. A veces, una jerarquía de abstracción es secuencial, lo que significa que cada capa tiene una y sólo una predecesor capa (inferior) y una y sólo un sucesor (superior) capa, excepto la capa planifiquen (que no tiene un sucesor) y la capa inferior (que no tiene predecesor). A veces, sin embargo, la jerarquía está organizada en una estructura de árbol, que significa que cada capa puede tener más de una capa predecesor, pero sólo una capa sucesor. De vez en cuando, una jerarquía puede tener unos muchos a muchas estructuras, en la que cada capa puede tener múltiples predecesores y sucesores. En ningún momento, habrá ningún bucle en una jerarquía. Una jerarquía a menudo se forma naturalmente en la descomposición de tareas. A menudo, un análisis de tareas se puede descomponer de forma jerárquica, a partir de las tareas y objetivos de la organización de mayor tamaño y romper cada uno de ellos

hacia abajo en subtareas más pequeñas que una vez más se pueden subdividir Esta división continua de tareas en otros más pequeños produciría un jerárquica la estructura de las tareas de subtareas. 2.4. Las abstracciones alternos A veces es útil tener múltiples abstracciones alternativas para el mismo problema por lo que uno puede mantener diferentes perspectivas en mente. Por ejemplo, podemos tener un diagrama de clases, un diagrama de estado, y un diagrama de secuencia para el mismo software en el mismo nivel de abstracción. Estas abstracciones alternativas no forman una jerarquía, sino más bien se complementan entre sí para ayudar a la comprensión del problema y su solución. Aunque beneficiosos, es como tiempos difíciles para mantener abstracciones alternativas sincronizadas. 3. Fundamentos de programación La programación se compone de las metodologías o actividades para la creación de programas informáticos que realizan una función deseada. Es una parte indispensable en la construcción de software. En general, la programación puede ser considerada como el proceso de diseño, la escritura, pruebas, depuración, y mantener el código fuente. Este código fuente está escrito en un lenguaje de programación. El proceso de escribir código fuente a menudo requiere experiencia en muchas áreas, incluyendo sujetos diferentes conocimientos del dominio de aplicación, estructuras de datos apropiadas, algoritmos especializados, diversas construcciones del lenguaje, buenas técnicas de programación, e ingeniería de software. 3.1. El proceso de programación La programación consiste en el diseño, la escritura, pruebas, depuración y mantenimiento. El diseño es la concepción o la invención de un sistema para convertir una

necesidad del cliente para el software de la computadora en el software operativo. Es la actividad que une los requisitos de aplicación a la codificación y depuración. La escritura es la codificación real del diseño en un lenguaje de programación adecuado. La prueba es la actividad para verificar que el código se escribe en realidad hace lo que se supone que debe hacer. La depuración es la actividad de encontrar y corregir errores (fallos) en el código fuente (o diseño). El mantenimiento es la actividad de actualizar, corregir y mejorar los programas existentes. Cada una de estas actividades es un tema enorme y, a menudo garantiza que la explicación de toda una KA en la Guía SWEBOK y muchos libros. 3.2. Los paradigmas de programación La programación es muy creativa y de este modo un tanto personal. Diferentes personas escriben a menudo diferentes programas para los mismos requisitos. Esta diversidad de la programación provoca mucha dificultad en la construcción y mantenimiento de software complejo grande. Diversos paradigmas de programación se han desarrollado a lo largo de los años para poner un poco de la normalización técnica en esta actividad altamente creativa y personal. Cuando uno programas, él o ella pueden usar uno de varios paradigmas de programación para escribir el código. Los principales tipos de paradigmas de programación se discuten a continuación. La programación no estructurada: En la programación estructurada, un programador sigue a su / su corazonada para escribir el código de la manera que él / ella le gusta, siempre y cuando la función está operativa. A menudo, la práctica es escribir código para cumplir una utilidad específica sin tener en cuenta cualquier otra cosa. Los programas escritos de esta manera no presentan ninguna estructura-particular, de ahí el nombre de "programación estructurada". La programación no estructurada también a veces se llama la programación ad hoc.

Estructurada / Procedimiento / programación imperativa: Una característica distintiva de la programación estructurada es el uso de estructuras de control bien definidos, incluyendo los procedimientos (y / o funciones) de cada procedimiento (o función) que realizan una tarea específica. Existen interfaces entre los procedimientos para facilitar el correcto y buen funcionamiento de los programas llamando. En virtud de la programación estructurada, los programadores a menudo siguen los protocolos y reglas generales establecidas al escribir código. Estos protocolos y normas pueden ser numerosas y cubrir casi todo el ámbito de programación que van desde el tema más simple (por ejemplo, cómo nombrar variables, funciones, procedimientos, etc.) a las cuestiones más complejas (como la forma de estructurar una interfaz, cómo manejar excepciones, y así sucesivamente). Programación orientada a objetos: Durante la programación procedimental organiza programas en torno a los procedimientos, la programación orientada a objetos (POO) organizar un programa alrededor de los objetos, que son estructuras de datos abstractos que combinan tanto los datos y métodos utilizados para acceder o manipular los datos. Las características primarias de la programación orientada a objetos es que los objetos que representan diversas entidades abstractas y concretas son creados y estos objetos interactúan entre sí para cumplir de forma colectiva las funciones deseadas. Orientada a Aspectos de programación: programación orientada a aspectos (AOP) es un paradigma de programación que se construye en la parte superior de la programación orientada a objetos. AOP tiene como objetivo aislar a funciones secundarias o de apoyo de la lógica de negocio del programa principal, centrándose en las secciones transversales (preocupaciones) de los objetos.

La principal motivación para AOP es resolver el enredo objeto y de dispersión asociado con la programación orientada a objetos, en el que las interacciones entre los objetos se convierten en muy compleja. La esencia de AOP es la separación de las preocupaciones en gran medida subrayado, que separa las preocupaciones funcionales no esenciales o lógica en varios aspectos. Programación Funcional: Aunque menos popular de programación, funcional es tan viable como los otros paradigmas en la resolución de problemas de programación. En la programación funcional, todos los cálculos se tratan como la evaluación de funciones matemáticas. En contraste con el de programación imperativo que enfatiza los cambios en el estado; programación funcional hace hincapié en la aplicación de funciones, evita los datos del estado y mutables, y proporciona transparencia referencial. 4. Fundamentos de lenguajes de programación El uso de las computadoras para resolver problemas implica programación que está escribiendo y organizando instrucciones que le indican a la computadora qué hacer en cada paso. Los programas deben ser escritos en algún lenguaje de programación con el cual ya través del cual se describen los cálculos necesarios. En otras palabras, que utilizan las facilidades proporcionadas por un lenguaje de programación para describir los problemas, el desarrollo de algoritmos, y la razón acerca de las soluciones de problemas. Para escribir cualquier programa, hay que entender al menos un lenguaje de programación. 4.1. Lenguaje de Programación general Un lenguaje de programación está diseñado para expresar los cálculos que se pueden realizar por un ordenador. En un sentido práctico, un lenguaje de programación es una notación para escribir programas y por lo tanto debe ser capaz de

expresar la mayoría de las estructuras de datos y algoritmos. Algunas, pero no todas, las personas restringen el término "lenguaje de programación" a aquellas lenguas que pueden expresar todos los algoritmos posibles. No todos los idiomas tienen la misma importancia y popularidad. Los más populares son a menudo definidos por un documento de especificación establecida por una organización bien conocida y respetada. Por ejemplo, el lenguaje de programación C es indicado por la norma ISO denominado ISO / IEC 9899. Otros lenguajes, como Perl y Python, no disfrutan de dicho tratamiento y con frecuencia tienen una aplicación dominante que se utiliza como referencia. 4.2. Sintaxis y semántica de programación idiomas Al igual que las lenguas naturales, muchos lenguajes de programación tienen algún tipo de especificación por escrito de su sintaxis (forma) y semántica (significado). Estas especificaciones incluyen, por ejemplo, los requisitos específicos para la definición de las variables y constantes (en otras palabras, la declaración y tipos) y requisitos de formato para las propias instrucciones. En general, un lenguaje de programación es compatible con las construcciones tales como variables, tipos de datos, constantes, literales, instrucciones de asignación, las sentencias de control, procedimientos, funciones y comentarios. La sintaxis y la semántica de cada construcción deben estar claramente especificadas. 4.3. Bajo Programación y Lenguajes Lenguaje de programación se pueden clasificar en dos clases: los lenguajes de bajo nivel y lenguajes de alto nivel. Lenguajes de bajo nivel pueden ser entendidos por un ordenador sin o con un mínimo de ayuda y por lo general incluyen lenguajes de máquina y lenguajes

ensambladores. Un lenguaje de máquina utiliza unos y ceros para representar instrucciones y variables, y es directamente comprensible por un ordenador. Un lenguaje ensamblador contiene las mismas instrucciones como un lenguaje máquina, pero las instrucciones y variables tienen nombres simbólicos que son más fáciles para los seres humanos a tener en cuenta. Los lenguajes ensambladores no se pueden entender directamente por un ordenador y deben traducirse en un lenguaje de máquina por un programa de utilidad denominado un ensamblador. A menudo existe una correspondencia entre las instrucciones de un lenguaje ensamblador y un lenguaje de máquina, y la traducción del código ensamblador a código máquina es sencilla. Por ejemplo, "poner R1, R2, R3" es un conjunto de instrucciones para añadir el contenido del registro R2 y R3 y almacenar la suma en el registro R1. Esta instrucción puede ser fácilmente traducido a código de máquina "0001 0001 0010 0011." (Suponga que el código de operación de adición es 0001, véase la figura 13.2).

Figura 13.2. Asamblea-a-binario Traducciones Un rasgo común compartido por estos dos tipos de lenguaje es su estrecha asociación con las características específicas de un tipo de arquitectura de ordenador Conjunto de instrucciones (ISA). 4.4. -Programación y Lenguajes Un lenguaje de programación de alto nivel tiene una fuerte abstracción de los detalles de ISA de la computadora. En comparación con los lenguajes de programación de bajo nivel, a menudo utiliza elementos de lenguaje natural y es por tanto mucho más fácil de entender para los humanos. Tales lenguajes permiten nombres simbólicos de

variables, proporcionan expresividad, y permiten la abstracción del hardware subyacente. Por ejemplo, mientras que cada uno tiene su propio microprocesador ISA, el código escrito en un lenguaje de programación de alto nivel suele ser portable entre muchas plataformas de hardware diferentes. Por estas razones, la mayoría de los programadores utilizar y la mayoría del software están escritas en lenguajes de programación de alto nivel. Ejemplos de lenguajes de programación de alto nivel incluyen C, C ++, C # y Java. 4.5. Declarativa frente a la programación imperativa idiomas La mayoría de los lenguajes de programación (de alto nivel o de bajo nivel) permiten a los programadores especificar las instrucciones individuales que un equipo se va a ejecutar. Tales lenguajes de programación son llamados lenguajes de programación imperativos porque uno tiene que especificar claramente cada paso a la computadora. Sin embargo, algunos lenguajes de programación permiten a los programadores sólo para describir la función a realizar, sin especificar las secuencias de instrucciones exactas para ser ejecutados. Tales lenguajes de programación son llamados lenguajes de programación declarativos. Los lenguajes declarativos son lenguajes de alto nivel. La implementación real de la computación escrito en un lenguaje de este tipo es oculta a los programadores y por lo tanto no es una preocupación para ellos. El punto clave a tener en cuenta es que la programación declarativa sólo describe lo que el programa debe lograr sin describir cómo lograrlo. Por esta razón, muchas personas creen que la programación declarativa facilita el desarrollo de software más fácil. Lenguajes de programación declarativos incluyen Lisp (también un lenguaje de programación funcional) y Prolog, mientras que los lenguajes de

programación imperativos incluyen C, C ++ y Java. 5. Herramientas de depuración y Técnicas Una vez que un programa se codifica y se compila (compilación será discutido en la sección 10), el siguiente paso es la depuración, que es un proceso metódico de encontrar y reducir el número de errores o fallos en un programa. El propósito de la depuración es averiguar por qué un programa no funciona o produce un resultado o salida equivocada. Excepto en los programas muy simples, la depuración es siempre necesaria. 5.1. Tipos de error Cuando un programa no funciona, a menudo es debido a que el programa contiene errores o errores que pueden ser tanto los errores sintácticos, errores lógicos o errores en los datos. Los errores lógicos y de datos de errores también se conocen como dos categorías de "fallos" en la terminología de ingeniería de software (ver tema 1.1, Terminología Pruebas relacionada, en el KA Pruebas de Software). Los errores de sintaxis son simplemente cualquier error que impide que el traductor (compilador / intérprete) a partir de analizar con éxito el comunicado. Cada instrucción de un programa debe ser capaz de analizar y dividir antes de su significado puede ser entendido e interpretado (y, por lo tanto, ejecutado). En los lenguajes de programación de alto nivel, los errores de sintaxis son capturados durante la compilación o la traducción del lenguaje de alto nivel en código máquina. Por ejemplo, en el C / C ++ lenguaje de programación, la declaración "123 = constante;" contiene un error de sintaxis que será capturado por el compilador durante la compilación. Los errores lógicos son los errores semánticos que resultan en cálculos incorrectos o comportamientos del programa.

Su programa es legal, pero se equivoca! Por lo que los resultados no coinciden con el planteamiento del problema o expectativas de los usuarios. Por ejemplo, en el lenguaje de programación C / C ++, la función en línea "int f (int x) {return f (x-1);}" para el cálculo de x factorial! es legal, pero lógicamente incorrecto. Este tipo de error no puede ser atrapado por un compilador durante la compilación y, a menudo se descubre a través de rastreo de la ejecución del programa (damas estáticos modernos hacen identificar algunos de estos errores. Sin embargo, el punto es que estos no son verificables máquina en general). Los errores de datos son los errores de entrada que resultan ya sea en datos de entrada que es diferente de lo que espera el programa o en el tratamiento de los datos erróneos. 5.2. Las técnicas de depuración Depuración implica muchas actividades y puede ser estático, dinámico o post mortem. Depuración estática por lo general toma la forma de revisión de código, mientras que la depuración dinámica por lo general toma la forma de rastreo y está estrechamente asociado con la prueba. Depuración postmortem es el acto de depurar el vaciado de memoria (volcado de memoria) de un proceso. Los vaciados de memoria se generan a menudo después de un proceso ha terminado debido a una excepción no controlada. Las tres técnicas se utilizan en diversas etapas del desarrollo del programa. La principal actividad de depuración dinámica está trazando, que está ejecutando el programa de una pieza a la vez, el examen de los contenidos de los registros y la memoria, con el fin de examinar los resultados en cada paso. Hay tres modos de buscar un programa.

• Un solo paso a paso: ejecutar una instrucción a la un tiempo para asegurarse de que cada instrucción

se ejecuta correctamente. Este método es tedioso, pero útil para verificar cada pasó de un programa.

• Los puntos de ruptura: decirle al programa para detener la ejecución cuando se llega a una instrucción específica. Esta técnica permite una rápida ejecutar secuencias de código seleccionados para obtener una visión general de alto nivel del comportamiento de ejecución.

• Los puntos de reloj: decirle al programa que parar cuando un registro o memoria ubicación cambia o cuando es igual a un valor específico. Esta técnica es útil cuando uno no sabe dónde ni cuándo se cambia un valor y cuando este cambio de valor de las posibles causas del error.

5.3. Herramientas de depuración La depuración puede ser compleja, difícil y tediosa. Al igual que la programación, depuración también es muy creativa (a veces más creativa que la programación). De este modo la ayuda de herramientas está en orden. Para la depuración dinámica, depuradores son ampliamente utilizados y permiten al programador para supervisar la ejecución de un programa, detener la ejecución, reiniciar la ejecución, establecer puntos de interrupción, valores de cambio en la memoria, e incluso, en algunos casos, volver atrás en el tiempo. Para la depuración estática, hay muchas herramientas de análisis de código estático, que buscan un conjunto específico de problemas conocidos dentro del código fuente. Existen dos herramientas comerciales y gratuitas en varios idiomas. Estas herramientas pueden ser extremadamente útiles para comprobar muy grandes árboles de código fuente, donde no es práctico hacer tutoriales de código. El programa de pelusa UNIX es un ejemplo temprano.

6. Estructura de Datos y Representación Programas de trabajo en los datos. Pero los datos se expresan y organizan dentro de los equipos antes de ser procesados por los programas. Esta organización y expresión de datos para su uso programas 'es el tema de la estructura de datos y representación. En pocas palabras, una estructura de datos trata de almacenar y organizar los datos en un ordenador de tal manera que los datos puedan ser utilizados de manera eficiente. Hay muchos tipos de estructuras de datos y cada tipo de estructura es adecuada para algunos tipos de aplicaciones. Por ejemplo, B / B + árboles son muy adecuadas para la implementación de sistemas de archivos y bases de datos masivas. 6.1. Presentación de la estructura de datos Las estructuras de datos son representaciones informáticas de datos. Las estructuras de datos se utilizan en casi todos los programas. En un sentido, ningún programa significativo puede ser construido sin el uso de algún tipo de estructura de datos. Algunos métodos de diseño y lenguajes de programación, incluso organizan todo un sistema de software alrededor de las estructuras de datos. Fundamentalmente, las estructuras de datos son abstracciones definidas en un conjunto de datos y sus operaciones asociadas. A menudo, las estructuras de datos están diseñadas para mejorar la eficiencia del programa o algoritmo. Ejemplos de tales estructuras de datos incluyen pilas, colas, y los montones. En otras ocasiones, las estructuras de datos se utilizan por la unidad conceptual (resumen tipo de datos), tal como el nombre y dirección de una persona. A menudo, una estructura de datos puede determinar si un programa se ejecuta en unos pocos segundos o en unas pocas horas o incluso unos pocos días. Desde la perspectiva de orden físico y lógico, una estructura de datos es o bien lineal o no lineal. Otras perspectivas dan lugar a

diferentes clasificaciones que incluyen homogénea vs. heterogénea, estático vs. dinámico, persistente vs. transitoria, externa vs. interna, primitivo vs. agregado, recursiva vs. no recursiva; pasiva contra activo; y las estructuras con estado vs sin estado. 6.2. Tipos de Estructura de Datos Como se mencionó anteriormente, los diferentes puntos de vista se pueden utilizar para clasificar las estructuras de datos. Sin embargo, la perspectiva predominante utilizada en la clasificación se centra en la ordenación física y lógica entre elementos de datos. Esta clasificación divide las estructuras de datos en las estructuras lineales y no lineales. Estructuras lineales organizan los elementos de datos en una única dimensión en la que cada entrada de datos tiene una (físico o lógico) predecesor y sucesor una con la excepción de la primera y última entrada. La primera entrada no tiene predecesor y la última entrada no tiene sucesor. estructuras no lineales organizan los elementos de datos en dos o más dimensiones, en cuyo caso, una entrada puede tener varios predecesores y sucesores. Ejemplos de estructuras lineales incluyen listas, pilas y colas. Ejemplos de estructuras no lineales incluyen montones, tablas hash, y los árboles (tales como árboles binarios, árboles de equilibrio, los árboles B, y así sucesivamente). Otro tipo de estructura de datos que se encuentra a menudo en la programación es la estructura del compuesto. Una estructura de datos compuesto se acumula en la parte superior de los otros (más primitivos) estructuras de datos y, de alguna manera, se puede ver como la misma estructura que la estructura subyacente. Ejemplos de estructuras de compuestos incluyen juegos, gráficos y particiones. Por ejemplo, una partición puede ser vista como un conjunto de conjuntos. 6.3. Las operaciones sobre Estructuras de Datos

Todas las estructuras de datos admiten algunas operaciones que producen una estructura y un orden específico, o recuperar los datos relevantes de la estructura, almacenar datos en la estructura, o borrar los datos de la estructura. Operaciones básicas con el apoyo de todas las estructuras de datos incluyen crear, leer, actualizar y eliminar (CRUD).

• Crear: Insertar una nueva entrada de datos en la estructura.

• Leer: Recuperar una entrada de datos de la estructura.

• Actualización: Modificar una entrada de datos existente.

• Eliminar: Eliminar una entrada de datos de la estructura.

Algunas estructuras de datos también apoyan las operaciones adicionales:

• Buscar un elemento en particular en la estructura.

• Ordenar elementos todos de acuerdo con algún orden.

• Atravesar todos los elementos en un orden específico.

• Reorganizar o reequilibrar la estructura.

Diferentes estructuras de apoyo diferentes operaciones con diferentes eficiencias. La diferencia entre la eficiencia de la operación puede ser significativa. Por ejemplo, es fácil para recuperar el último elemento insertado en una pila, pero encontrar un elemento particular dentro de una pila es bastante lento y tedioso. 7. Algoritmos y Complejidad Los programas no son al azar piezas de código: están escritos meticulosamente para realizar acciones a la esperada por el usuario. La guía uno utiliza para componer programas son algoritmos, que organizan varias funciones en una serie de pasos y tienen en cuenta el dominio de aplicación, la estrategia

de solución, y las estructuras de datos que se utiliza. Un algoritmo puede ser muy simple o muy complejo. 7.1. Descripción general de Algoritmos Abstractamente hablando, algoritmos guían las operaciones de computadoras y consisten en una secuencia de acciones compuestas para resolver un problema. Definiciones alternativas incluyen, pero no se limitan a:

• Un algoritmo es cualquier procedimiento de cálculo bien definido que tiene algún valor o conjunto de valores como entrada y produce un cierto valor o conjunto de valores como de salida.

• Un algoritmo es una secuencia de pasos de cálculo que transforman la entrada a la salida.

• Un algoritmo es una herramienta para la solución de un problema de cálculo bien específico.

Por supuesto, las diferentes definiciones se ven favorecidas por diferentes personas. Aunque no existe una definición universalmente aceptada, existe cierto acuerdo en que un algoritmo tiene que ser correcta, finita (en otras palabras, terminan con el tiempo o uno debe ser capaz de escribir en un número finito de pasos), y sin ambigüedades. 7.2. Atributos de Algoritmos Los atributos de algoritmos son muchas e incluyen a menudo la modularidad, la corrección, el mantenimiento, la funcionalidad, robustez, facilidad de uso (es decir, fácil de ser entendido por personas), el tiempo de programador, simplicidad y extensibilidad. Un atributo común subrayado es "rendimiento" o "eficiencia" por lo que entendemos tanto tiempo y eficiencia de los recursos, mientras que en el uso general, haciendo hincapié en el eje del tiempo. Hasta cierto punto, la eficiencia determina si un algoritmo es factible o práctico. Por ejemplo,

un algoritmo que toma cien años de terminar es prácticamente inútil y se considera incluso incorrecta. 7.3. Análisis algorítmico Análisis de algoritmos es el estudio teórico de rendimiento programa de ordenador y el uso de recursos; en cierta medida, se determina la bondad de un algoritmo. Este tipo de análisis generalmente abstrae los detalles particulares de un equipo específico y se centra en el análisis asintótico, independiente de la máquina. Hay tres tipos básicos de análisis. En el análisis del peor caso, se determina la duración máxima del tiempo o los recursos requeridos por el algoritmo en cualquier entrada de tamaño n. En el análisis en el caso promedio, se determina el tiempo esperado o los recursos requeridos por el algoritmo sobre todas las entradas de tamaño n; en la realización de análisis en el caso promedio, a menudo se tiene que hacer suposiciones sobre la distribución estadística de los insumos. El tercer tipo de análisis es el análisis mejor de los casos, en el que se determina el tiempo mínimo o los recursos requeridos por el algoritmo en cualquier entrada de tamaño n. Entre los tres tipos de análisis, el análisis en el caso promedio es el más relevante, pero también el más difícil de realizar. Además de los métodos de análisis básicos, también hay el análisis amortizado, en el que uno determina el tiempo máximo requerido por un algoritmo más de una secuencia de operaciones; y el análisis de la competencia, en el que se determina el mérito relativo rendimiento de un algoritmo contra el algoritmo óptimo (que no puede ser conocido) de la misma categoría (por las mismas operaciones). 7.4. Estrategias de diseño algorítmico El diseño de algoritmos sigue generalmente una de las siguientes estrategias: la fuerza bruta, divide y vencerás, programación

dinámica, y la selección codiciosos. La estrategia de la fuerza bruta es en realidad una estrategia no. Se trata exhaustivamente todas las formas posibles para hacer frente a un problema. Si un problema tiene una solución, esta estrategia está garantizada para encontrarlo; sin embargo, el gasto de tiempo puede ser demasiado alto. La estrategia de divide y vencerás mejora en la estrategia de fuerza bruta dividiendo un gran problema en problemas más pequeños y homogéneos. Se resuelve el gran problema por resolver de forma recursiva los problemas más pequeños y peinado de las soluciones a los problemas más pequeños para formar la solución al gran problema. El supuesto subyacente de divide y vencerás es que los problemas más pequeños son más fáciles de resolver. La estrategia de programación dinámica mejora en la estrategia de dividir y conquistar al reconocer que algunos de los sub-problemas producidos por la división puede ser el mismo y por lo tanto evita la solución de los mismos problemas una y otra vez. Esta eliminación de subproblemas redundantes puede mejorar dramáticamente la eficiencia. La estrategia de selección codiciosa mejora aún más en programación dinámica, al reconocer que no todos los sub-problemas contribuyen a la solución del gran problema. Al eliminar todos menos una sub-problema, la estrategia de selección codiciosa logra la más alta eficiencia entre todas las estrategias de diseño de algoritmos. A veces, el uso de la asignación al azar puede mejorar en la estrategia de selección codiciosa al eliminar la complejidad en la determinación de la elección codiciosa través de lanzar la moneda o la asignación al azar. 7.5. Estrategias de análisis algorítmico Las estrategias de análisis de algoritmos incluyen el análisis de recuento de base, en el que uno realmente cuenta el número de pasos de un algoritmo necesario para completar su tarea; análisis asintótico, en el

que uno sólo considera el orden de magnitud del número de pasos de un algoritmo necesario para completar su tarea; análisis probabilístico, en el que se hace uso de las probabilidades para analizar el rendimiento promedio de un algoritmo; amortizado análisis, en el que uno utiliza los métodos de agregación, potencial, y la contabilidad para analizar el peor rendimiento de un algoritmo en una secuencia de operaciones; y análisis de la competencia, en la cual se utilizan métodos como el potencial y la contabilidad para analizar el rendimiento relativo de un algoritmo para el algoritmo óptimo. Para problemas complejos y algoritmos, uno puede tener que utilizar una combinación de las estrategias de análisis antes mencionados. 8. Concepto básico de un sistema De Ian Sommerville escribe, "un sistema es una colección propósito de componentes interrelacionados que trabajan juntos para lograr un objetivo". Un sistema puede ser muy simple e incluir sólo unos pocos componentes, como una pluma de tinta, o más bien complejo, como un avión. Dependiendo de si los seres humanos son parte del sistema, los sistemas se pueden dividir en sistemas basados en computadoras técnicas y sistemas socio-técnicos. Un técnico funciones del sistema basado en computadora sin intervención humana, tales como televisores, teléfonos móviles, termostato, y algún tipo de software; un sistema socio-técnico no funciona sin la intervención humana. Ejemplos de tales sistemas son los vehículos tripulados espaciales, chips embebidos dentro de un ser humano, y así sucesivamente. 8.1. Propiedades del sistema emergente Un sistema es más que simplemente la suma de sus partes. Por lo tanto, las propiedades de un sistema no son simplemente la suma de las propiedades de sus componentes. En

cambio, un sistema a menudo exhibe propiedades que son propiedades del sistema como un todo. Estas propiedades se denominan propiedades emergentes porque se desarrollan sólo después de la integración de las partes constituyentes en el sistema. Propiedades emergentes del sistema pueden ser funcionales o no funcionales. Propiedades funcionales describen las cosas que hace un sistema. Por ejemplo, las propiedades funcionales de un avión incluyen la flotación en el aire, llevando a las personas o carga, y su uso como arma de destrucción masiva. Propiedades no funcionales describen cómo se comporta el sistema en su entorno operativo. Estos pueden incluir cualidades tales como la consistencia, capacidad, peso, seguridad, etc.

8.2. Ingeniería de Sistemas "La ingeniería de sistemas es el enfoque interdisciplinario que rige el esfuerzo técnico y de gestión total que se requiere para transformar un conjunto de necesidades de los clientes, las expectativas y limitaciones en una solución y para apoyar esa solución lo largo de su vida.". Las fases del ciclo de vida de la ingeniería de sistemas varían en función del sistema que se está construyendo, pero, en general, incluye los requisitos del sistema definición, diseño de sistemas, desarrollo de sub-sistema, integración de sistemas, las pruebas del sistema, la instalación del sistema, la

evolución del sistema, y el desmantelamiento del sistema. Muchas directrices prácticas se han producido en el pasado para ayudar a las personas en la realización de las actividades de cada fase. Por ejemplo, el diseño del sistema se puede dividir en tareas más pequeñas de identificación de subsistemas, la asignación de los requisitos del sistema a los subsistemas, la especificación de la funcionalidad del subsistema, definición de las interfaces del subsistema, y así sucesivamente. 8.3. Visión general de un sistema informático Entre todos los sistemas, uno que es obviamente importante para la comunidad de ingeniería de software es el sistema informático. Una computadora es una máquina que ejecuta programas o software. Se compone de una colección con propósito de los componentes mecánicos, eléctricos y electrónicos con cada componente realiza una función de pre ajuste. Conjuntamente, estos componentes son capaces de ejecutar las instrucciones que se dan por el programa. Abstractamente hablando, un ordenador recibe alguna entrada, almacena y manipula algunos datos, y proporciona una salida. La característica más distintiva de un ordenador es su capacidad para almacenar y ejecutar secuencias de instrucciones llamados programas. Un fenómeno interesante en relación con el ordenador es la equivalencia universal en funcionalidad. De acuerdo con Turing, todos los equipos con una cierta capacidad mínima son equivalentes en su capacidad para realizar tareas de cálculo. En otras palabras, dado el tiempo y la memoria suficiente, todos los computadores -que van desde un netbook a un superordenador- son capaces de calcular exactamente las mismas cosas, independientemente de la velocidad, tamaño, costo, o cualquier otra cosa. La mayoría de los sistemas de ordenador tienen una estructura que se conoce como el

"modelo de von Neumann", que consta de cinco componentes: una memoria para almacenar instrucciones y datos, una unidad central de procesamiento para realizar operaciones aritméticas y lógicas, una unidad de control para la secuenciación y la interpretación de instrucciones, entrada para conseguir información externa en la memoria, y la salida para la producción de resultados para el usuario. Los componentes básicos de un sistema informático basado en el modelo de von Neumann se representan en la figura 13.3. 9. Organización de Computadores Desde la perspectiva de un ordenador, existe una gran diferencia semántica entre su comportamiento previsto y el funcionamiento de los dispositivos electrónicos subyacentes que realmente hacen el trabajo dentro del equipo. Este desfase se cierra mediante una organización ordenador, que engrana varios dispositivos eléctricos, electrónicos y mecánicos en un solo dispositivo que forma un equipo. Los objetos que se ocupa de la organización de ordenador son los dispositivos, las conexiones y controles. La abstracción construida en la organización del equipo es el equipo. 9.1. Organización General Del Ordenador Un equipo consiste generalmente en una CPU, memoria, dispositivos de entrada, y los dispositivos de salida. Abstractamente hablando, la organización de un equipo se puede dividir en cuatro niveles (Figura 13.4). El nivel de arquitectura macro es la especificación formal de todas las funciones de una máquina particular puede llevar a cabo y que se conoce como la arquitectura del conjunto de instrucciones (ISA). El nivel de arquitectura de micro es la implementación de la Ley de Seguridad en una CPU específica, en otras palabras, la forma en que las especificaciones del ISA se llevan a cabo realmente. El nivel de los circuitos lógicos es el nivel en el que cada

componente funcional de la micro arquitectura se construye de circuitos que toman decisiones basadas en reglas simples. El nivel de dispositivos es el nivel en el que, finalmente, cada circuito lógico es en realidad construida de dispositivos electrónicos tales como semiconductores complementarios de óxido metálico (CMOS), n canal con semiconductores de óxido metálico (NMOS), o el arseniuro de galio (GaAs) transistores, y por lo adelante.

Figura 13.4. Niveles arquitectura de la máquina Cada nivel proporciona una abstracción al nivel superior y depende en el nivel inferior. Para un programador, la abstracción más importante es la ISA, que especifica las cosas tales como los tipos de datos nativos, instrucciones, registros, modos de direccionamiento, la arquitectura de memoria, interrumpen y el manejo de excepciones, y las E / S. En general, el ISA especifica la capacidad de un ordenador y qué se puede hacer en el equipo con la programación. 9.2. Sistemas digitales En el nivel más bajo, los cálculos se llevaron a cabo por los dispositivos eléctricos y electrónicos dentro de un ordenador. El equipo utiliza circuitos y memoria para contener los cargos que representan la presencia o ausencia de tensión. La presencia de tensión es igual a un 1 mientras que la ausencia de tensión es un cero. En el disco de la polaridad de la tensión está representada por 0 y 1 que a su vez representa los datos almacenados. Todo, incluyendo la instrucción y los datos se expresa o codificada usando ceros digitales y

unos. En este sentido, un ordenador se convierte en un sistema digital. Por ejemplo, el valor decimal 6 puede ser codificado como 110, la instrucción de adición puede ser codificada como 0001, y así sucesivamente. El componente del ordenador, tales como la unidad de control, ALU, memoria y E / S usa la información para calcular las instrucciones. 9.3. Lógica digital Obviamente, se necesitan lógicas para manipular los datos y para controlar el funcionamiento de las computadoras. Esta lógica, que está detrás de la función apropiada de un ordenador, se llama lógica digital, ya que se ocupa de las operaciones de ceros digitales y unos. Lógica digital especifica las reglas tanto para la construcción de diversos dispositivos digitales de los elementos más simples (tales como transistores) y para que rige el funcionamiento de los dispositivos digitales. Por ejemplo, la lógica digital detalla cuál será el valor si un cero y uno es con AND, un OR o un OR exclusivo juntos. También especifica cómo construir decodificadores, multiplexores (MUX), memoria y complementos que se utilizan para montar el equipo. 9.4. Expresión de datos del ordenador Como se mencionó antes, una computadora expresa de datos con señales eléctricas digitales o ceros y unos. Puesto que hay sólo dos diferentes dígitos utilizados en la expresión de datos, un sistema de este tipo se denomina un sistema de expresión binario. Debido a la naturaleza inherente de un sistema binario, el valor numérico máximo expresable por un código binario de n bits es 2n - 1. Específicamente, el número binario anan−1…a1a0 corresponde a un a a… + a a Por lo tanto, el valor numérico de la expresión binaria de 1011 es

Expresar un valor no numérico, tenemos que decidir el número de ceros y unos de usar y el orden en que están dispuestos los ceros y unos. Por supuesto, hay diferentes maneras de hacer la codificación, y esto da lugar a diferentes esquemas de expresión de datos y subsistemas. Por ejemplo, los números enteros se pueden expresar en la forma de, el complemento a uno, o complemento sin signo de dos. Para los personajes, hay ASCII, Unicode y normas EBCDIC de IBM. Para los números de punto flotante, hay IEEE-754 FP 1, 2 y 3 estándares. 9.5. La Unidad Central de Procesamiento (CPU) La unidad central de procesamiento es el lugar donde las instrucciones (o programas) que se ejecutan realmente. La ejecución por lo general toma varias medidas, entre ellas ir a buscar la instrucción de programa, la decodificación de la instrucción, ir a buscar operandos, la realización de operaciones aritméticas y lógicas de los operandos, y almacenar el resultado. Los principales componentes de una CPU consisten en registros donde las instrucciones y los datos son a menudo leer y escribir a la unidad aritmética y lógica (ALU) que realiza la aritmética real (tales como suma, resta, multiplicación y división) y la lógica (por ejemplo, como los autobuses que enlazan los componentes juntos y datos de transporte desde y hacia las operaciones AND, OR, desplazamiento, etc.), la unidad de control que se encarga de producir las señales apropiadas para el control de las operaciones, y varios (datos, dirección y control) estos componentes. 9.6. Organización del sistema de memoria La memoria es la unidad de almacenamiento de un ordenador. Se refiere al montaje de un sistema de memoria a gran escala a partir de unidades más pequeñas y de almacenamiento de un solo dígito. Los

principales temas tratados en la arquitectura del sistema de memoria se incluyen los siguientes:

• Las células de memoria y chips • Los módulos y los módulos de

memoria • Jerarquía de memoria y la memoria

caché • La memoria como un subsistema del

equipo. Las células de memoria y chips se ocupan de almacenamiento único digital y el montaje de unidades de un solo dígito en matrices de memoria de una sola dimensión, así como el montaje de matrices de almacenamiento unidimensionales en los chips de memoria de almacenamiento multi-dimensionales. Tablas y módulos de memoria se refieren al montaje de chips de memoria en los sistemas de memoria, con el foco que está en la organización, el funcionamiento y la gestión de los chips individuales en el sistema. Jerarquía de memoria caché y se utilizan para apoyar las operaciones de memoria eficientes. La memoria como un sub-sistema se ocupa de la interfaz entre el sistema de memoria y otras partes de la computadora. 9.7. De entrada y salida (E / S) Una computadora es inútil sin E / S. dispositivos de entrada más comunes son el teclado y el ratón; dispositivos de salida comunes incluyen el disco, la pantalla, la impresora y altavoces. Diferentes dispositivos de E / S operan a diferentes velocidades de datos y fiabilidades. ¿Cómo se conectan los ordenadores y administrar varios dispositivos de entrada y salida para facilitar la interacción entre computadoras y seres humanos (u otros equipos) es el foco de los temas de E / S. Los principales problemas que deben ser resueltos en la entrada y la salida son las formas de E / S puede y debe ser realizada.

En general, E / S se realizan tanto a nivel de hardware y software. Hardware de E / S se puede realizar en cualquiera de las tres formas. E / S dedicada dedica a la CPU para las operaciones de entrada y salida reales durante la I / O; trata de E / S mapeada en memoria I / O operaciones como operaciones de memoria; y híbrido E / S combina dedicado de E / S y la memoria de E / S mapeada en un solo modo de operación de E / S holística. Coincidentemente, el software de I / O también se puede realizar en una de tres maneras. E / S programada permite a la espera de la CPU mientras que el dispositivo de E / S está haciendo I / O; dirigida por interrupciones de E / S deja para el manejo de la CPU de E / S ser impulsado por el dispositivo de E / S; y el acceso directo a memoria (DMA) permite E / S ser manejado por una CPU secundaria incrustado en un dispositivo DMA (o canal). (Excepto durante la configuración inicial, la CPU principal no se altera durante una operación de DMA I / O). Independientemente de los tipos de esquema de E / S que se utiliza, las principales cuestiones relacionadas con la E / S incluyen E / S de direccionamiento (que se ocupa de la cuestión de cómo identificar el dispositivo de E / S para una operación específica de E / S), la sincronización (que se ocupa de la cuestión de cómo hacer que la CPU y e / S dispositivo funcione en armonía durante la I / O), y detección y corrección de errores (que se ocupa de la ocurrencia de errores de transmisión). 10. Fundamentos del compilador 10.1. Compilador / intérprete general Los programadores suelen escribir programas en código de lenguaje de alto nivel, que la CPU no puede ejecutar; por lo que este código fuente tiene que ser convertido en código de máquina para ser entendido por un ordenador.

Debido a las diferencias entre los diferentes NIA, la traducción debe hacerse para cada ISA o lenguaje de máquina específica bajo consideración. La traducción se realiza generalmente por una pieza de software llamado un compilador o un intérprete. Este proceso de traducción de un lenguaje de alto nivel a un lenguaje máquina se llama compilación, o, a veces, la interpretación. 10.2. Interpretación y compilación Hay dos maneras de traducir un programa escrito en un lenguaje de alto nivel en código de máquina: interpretación y compilación. Interpretación traduce el código fuente de una instrucción a la vez en el lenguaje de máquina, lo ejecuta en el lugar, y luego regresa para otro comunicado. Tanto el código fuente de nivel-lenguaje de alto y el intérprete se requieren cada vez que se ejecuta el programa. Compilación traduce el código de nivel de lengua fuente alta en todo un programa en lenguaje de máquina (una imagen ejecutable) por un programa que se llama un compilador. Después de la compilación, sólo se necesita la imagen ejecutable para ejecutar el programa. La mayoría del software de aplicación se vende en esta forma. Mientras tanto la compilación e interpretación convertir código de lenguaje de alto nivel en código de máquina, hay algunas diferencias importantes entre los dos métodos. En primer lugar, un compilador hace que la conversión sólo una vez, mientras que un intérprete convierte típicamente cada vez que se ejecuta un programa. En segundo lugar, la interpretación de código es más lento que ejecuta el código compilado, ya que el intérprete debe analizar cada sentencia en el programa cuando se ejecuta y luego realizar la acción deseada, mientras que el código compilado solo realiza la acción dentro de un contexto fija determinada por la compilación.

En tercer lugar, el acceso a las variables también es más lento en un intérprete porque la asignación de identificadores a ubicaciones de almacenamiento debe hacerse varias veces en tiempo de ejecución, no en tiempo de compilación. Las tareas principales de un compilador pueden incluir pre-procesamiento, análisis léxico, análisis sintáctico, análisis semántico, generación de código, y la optimización de código. Fallas del programa causados por el comportamiento del compilador incorrecto pueden ser muy difíciles de localizar. Por esta razón, los ejecutores del compilador invierten mucho tiempo, garantizar la exactitud de su software. 10.3. El proceso de compilación La compilación es una tarea compleja. La mayoría de los compiladores dividen el proceso de compilación en muchas fases. Una composición típica es la siguiente:

• Análisis léxico • Análisis de sintaxis o de análisis • Análisis semántico • Código de GENERACION

Análisis léxico divide el texto de

entrada (el código fuente), que es una secuencia de caracteres, en observaciones separadas, que son para ser ignorado en las acciones posteriores, y los símbolos básicos, que tienen significados léxicos. Estos símbolos básicos deben corresponder a algunos símbolos terminales de la gramática del lenguaje de programación en particular. Aquí símbolos terminales se refieren a los símbolos elementales (o fichas) en la gramática que no se pueden cambiar.

Análisis de sintaxis se basa en los resultados del análisis de léxico y

descubre la estructura en el programa y determina si o no un texto se ajusta a un formato esperado. ¿Es este un programa textualmente correcta C ++? o ¿Es esta entrada textualmente correcta? son las típicas preguntas que pueden ser respondidas por el análisis de sintaxis.

Análisis sintáctico determina si el código fuente de un programa es correcto y lo convierte en una representación (árbol de análisis sintáctico) más estructurado para el análisis o la transformación semántica.

El análisis semántico añade información semántica al árbol de análisis sintáctico construido durante el análisis sintáctico y construye la tabla de símbolos. Se realiza varias comprobaciones semánticas que incluyen la comprobación de tipos, objeto de enlace (que asocian variables y funciones referencias con sus definiciones), y la asignación definitiva (que requieren todas las variables locales que ser inicializado antes de su uso). Si se encuentran errores, las sentencias de programa semánticamente incorrectos son rechazados y marcados como errores.

Una vez que el análisis semántico se ha completado, la fase de generación de código comienza y transforma el código intermedio producido en las fases anteriores a la lengua de máquina nativo de la computadora en cuestión. Esto implica recursos y almacenamiento de decisiones-tales como decidir qué variables para encajar en los registros y la memoria y la selección y programación de instrucciones de máquina adecuados, junto con sus modos de direccionamiento asociados.

A menudo es posible combinar múltiples fases en una sola pasada sobre el código en una implementación compilador. Algunos compiladores también tienen una fase de pre-procesamiento al principio o después del análisis léxico que realiza un trabajo de limpieza necesaria, tales como el procesamiento de las instrucciones del programa para el compilador (directivas). Algunos compiladores proporcionan una fase de optimización opcional al final de toda la compilación para optimizar el código (por ejemplo, el reordenamiento de la secuencia de instrucción) para la eficiencia y otros objetivos deseables solicitados por los usuarios. 11. Fundamentos de Sistemas Operativos Cada sistema de complejidad significativa debe ser gestionado. Un ordenador, como un sistema eléctrico-mecánicos más bien compleja, necesita su propio gestor de la gestión de los recursos y actividades que tienen lugar en él. Eso se denomina administrador de un sistema operativo (OS). 11.1. Descripción general de funcionamiento Sistemas Los sistemas operativos es una colección de software y firmware, que controla la ejecución de los programas de ordenador y proporciona servicios tales como la asignación de recursos del ordenador, control de trabajos, entrada / salida de control y gestión de archivos en un sistema informático. Conceptualmente, un sistema operativo es un programa informático que gestiona los recursos de hardware y hace que sea más fácil de usar por las aplicaciones mediante la presentación de buenas abstracciones. Esta abstracción agradable a menudo se llama la máquina virtual e incluye cosas tales como procesos, memoria virtual y sistemas de archivos. Un sistema operativo oculta la complejidad del hardware subyacente y se encuentra en todas las computadoras modernas.

Las principales funciones desempeñadas por los sistemas operativos son la gestión y la ilusión. Gestión se refiere a la gestión del sistema operativo (asignación y recuperación) de los recursos físicos entre varios usuarios / aplicaciones / tareas que compiten. La ilusión se refiere a las buenas abstracciones del sistema operativo proporciona. 11.2. Las tareas de un sistema operativo Las tareas de un sistema operativo difieren significativamente dependiendo de la máquina y el tiempo de su invención. Sin embargo, los sistemas operativos modernos han llegado a un acuerdo en cuanto a las tareas que deben ser realizadas por un sistema operativo. Estas tareas incluyen la gestión de la CPU, la gestión de memoria, gestión de disco (sistema de archivos), I / O de gestión de dispositivos, y la seguridad y protección. Cada tarea OS maneja un tipo de recurso físico. En concreto, ofertas de gestión de la CPU con la asignación y la liberación de la CPU entre los programas de la competencia (llamados procesos / hilos en la jerga OS), incluyendo el propio sistema operativo. La abstracción principal proporcionada por la administración de la CPU es el modelo de proceso / hilo. Ofertas de gestión de memoria con la asignación y liberación de espacio de memoria entre procesos competidores, y la principal abstracción proporcionada por la gestión de memoria es la memoria virtual. gestión de disco se refiere a la puesta en común de los discos de estado magnéticos u ópticos o sólidos entre varios programas / usuarios y su abstracción principal es el sistema de archivos. E / S ofertas de gestión de dispositivos con la asignación y las liberaciones de varios dispositivos de E / S entre los procesos que compiten.

Seguridad y protección de acuerdo con la protección de los recursos informáticos de uso ilegal. 11.3. Las abstracciones Sistema Operativo El arsenal de sistemas operativos es la abstracción. Correspondiente a las cinco tareas físicas, OSs utilizar cinco abstracciones: proceso / hilo, la memoria virtual, sistemas de archivos de entrada / salida, y dominios de protección. La abstracción general OS es la máquina virtual. Para cada área de tareas de OS, hay tanto una realidad física y una abstracción conceptual. La realidad física se refiere a la gestión de recursos hardware bajo; la abstracción conceptual se refiere a la interfaz del sistema operativo presenta a los usuarios / programas anteriores. Por ejemplo, en el modelo de rosca de la OS, la realidad física es la CPU y la abstracción es varias CPU. De este modo, el usuario no tiene que preocuparse acerca de compartir la CPU con otros cuando trabajan en la abstracción proporcionada por un sistema operativo. En la abstracción de la memoria virtual de un sistema operativo, la realidad física es la memoria RAM física o ROM (lo que sea), la abstracción es el espacio de memoria ilimitada múltiple. De este modo, el usuario no tiene que preocuparse acerca de compartir la memoria física con otros o sobre el tamaño de la memoria física limitada. Abstracciones pueden ser virtuales o transparentes; en este contexto virtual se aplica a algo que parece estar allí, pero no es (como memoria utilizable allá de lo físico), mientras transparente se aplica a algo que está ahí, pero parece no estar allí (como ir a buscar contenido de la memoria desde el disco o la memoria física). 11.4. Clasificación operativo Sistemas Los diferentes sistemas operativos pueden tener una implementación diferente funcionalidad. En los primeros días de la era de los ordenadores, sistemas operativos eran relativamente simples. A medida que pasa el

tiempo, la complejidad y sofisticación de los sistemas operativos aumenta significativamente. Desde una perspectiva histórica, un sistema operativo puede ser clasificado como uno de los siguientes.

• Preparación de lotes OS: organiza y procesos de trabajo en lotes. Ejemplos de tales sistemas operativos incluyen FMS de IBM, IBSYS, y Universidad de UMES de Michigan.

• Sistema operativo de procesamiento por lotes multiprogramados: añade capacidad de realizar múltiples tareas anteriores en forma de dosificación sencilla sistemas operativos. Un ejemplo de un sistema operativo de este tipo es de IBM OS / 360.

• Tiempo compartido OS: agrega multi-tarea y capacidades interactivas en el sistema operativo. Ejemplos de tales sistemas operativos incluyen UNIX, Linux y NT.

• Sistema operativo en tiempo real: añade sincronización previsibilidad en el sistema operativo mediante la programación de las tareas individuales de acuerdo con los plazos de realización de cada tarea. Ejemplos de este tipo de sistema operativo incluyen VxWorks (WindRiver) y DART (EMC).

• OS Distributed: añade la capacidad de gestión de una red de computadoras en el sistema operativo.

• Embedded OS: tiene una funcionalidad limitada y se utiliza para sistemas embebidos, tales como automóviles y PDAs. Ejemplos de tales sistemas operativos como Palm OS, Windows CE, y del PRIMERO.

Como alternativa, un sistema operativo se puede clasificar por su aplicable objetivo de la máquina / medio ambiente en lo siguiente.

• Sistema operativo de la unidad central: se ejecuta en los ordenadores centrales e incluyen OS / 360, OS / 390, AS / 400, MVS y VM.

• Sistema operativo de servidor: se ejecuta en estaciones de trabajo o servidores e incluye sistemas como UNIX, Windows, Linux y VMS.

• OS multicomputer: se ejecuta en varios equipos y se incluyen ejemplos tales como Novell Netware.

• Ordenadores personales OS: se ejecuta en computadores personales e incluyen ejemplos tales como DOS, Windows, Mac OS y Linux.

• OS dispositivo móvil: se ejecuta en dispositivos personales como teléfonos móviles, iPad e incluyen ejemplos de este tipo de iOS, Android, Symbian, etc.

12. Conceptos básicos de bases de datos y la gestión de datos Una base de datos consiste en una colección organizada de datos para uno o más usos. En cierto sentido, es una base de datos una generalización y ampliación de las estructuras de datos. Pero la diferencia es que una base de datos externa es generalmente a programas individuales y permanentes en existencia en comparación con las estructuras de datos. Las bases de datos se utilizan cuando el volumen de datos es relaciones grandes o lógicas entre los elementos de datos son importantes. Los factores considerados en el diseño de bases de datos incluyen el rendimiento, concurrencia, la integridad, y la recuperación de fallos de hardware. 12.1. Entidad y de esquema Las cosas una base de datos intenta modelar y almacenar se denominan entidades. Las entidades pueden ser objetos del mundo

real, como las personas, coches, casas, etc., o pueden ser conceptos abstractos tales como las personas, salario, nombres, y así sucesivamente. Una entidad puede ser primitiva, tales como un nombre o un compuesto tal como un empleado que consiste en un nombre, número de identificación, el salario, la dirección, y así sucesivamente. El concepto más importante en una base de datos es el esquema, que es una descripción de toda la estructura de la base de la cual se construyen todas las demás actividades de base de datos. Un esquema define las relaciones entre las diferentes entidades que componen una base de datos. Por ejemplo, un esquema de un sistema de nómina de la compañía consistiría en cosas tales como la identificación de empleado, nombre, tipo de salario, dirección, y así sucesivamente. Software de base de datos mantiene la base de datos de acuerdo con el esquema. Otro concepto importante en la base de datos es el modelo de base de datos que describe el tipo de relación entre las diversas entidades. Los modelos utilizados comúnmente incluyen relacional, la red y modelos de objetos. 12.2. Sistemas de Gestión de Bases de Datos (DBMS) Sistema de gestión de base de datos (DBMS) componentes incluyen aplicaciones de bases de datos para el almacenamiento de datos estructurados y no estructurados y las funciones de gestión de base de datos necesarios para visualizar, recoger, almacenar y recuperar datos de las bases de datos. Un DBMS controla la creación, mantenimiento y uso de la base de datos y por lo general se clasifica de acuerdo con el modelo de base de datos que da soporte, tales como el relacional, red o modelo de objetos. Por ejemplo, un sistema de gestión de bases de datos relacionales (RDBMS) implementa características del modelo relacional. Un sistema de gestión de base de

datos de objeto (ODBMS) implementa las características del modelo de objetos. 12.3. Base de datos de lenguaje de consulta Los usuarios / aplicaciones interactúan con una base de datos a través de un lenguaje de consulta de base de datos, que es un lenguaje de programación especializado adaptados a la utilización de bases de datos. El modelo de base de datos tiende a determinar los lenguajes de consulta que están disponibles para acceder a la base de datos. Un lenguaje de consulta de uso general para la base de datos relacional es el lenguaje de consulta estructurado, más comúnmente abreviado como SQL. Un lenguaje de consulta común para las bases de datos de objetos es el lenguaje de consulta de objetos (abreviado como NCO). Hay tres componentes de SQL: Lenguaje de definición de datos (DDL), Lenguaje de manipulación de datos (DML) y el Lenguaje de control de datos (DCL). Un ejemplo de una consulta DML puede ser similar al siguiente: SELECT Component_No, Cantidad DE COMPONENTE DONDE Item_No = 100 La consulta anterior se selecciona todo el Component_No y su cantidad correspondiente de un componente de tabla de base de datos llamada, donde el Item_No es igual a 100. 12.4. Tareas de paquetes de DBMS Un sistema DBMS proporciona las siguientes capacidades:

• Las bases de datos se utiliza para definir y organizar el contenido, las relaciones, y la estructura de los datos necesarios para construir una base de datos.

• Base de datos de interrogación se utiliza para acceder a los datos en

una base de datos para la recuperación de información y generación de informes. Los usuarios finales pueden recuperar de forma selectiva y mostrar información y producir informes impresos. Esta es la operación que la mayoría de los usuarios saben acerca de las bases de datos.

• Mantenimiento de base de datos se utiliza para añadir, eliminar, actualizar y corregir los datos en una base de datos.

• Desarrollo de aplicaciones se utiliza para desarrollar prototipos de pantallas de entrada de datos, consultas, formularios, informes, tablas y etiquetas para una aplicación prototipo. También se refiere a la utilización del lenguaje o aplicación generadores de 4ta Generación de desarrollar o generar código de programa.

12.5. Gestión de datos Una base de datos debe gestionar los datos almacenados en ella. Esta gestión incluye tanto la organización y almacenamiento. La organización de los datos reales en una base de datos depende del modelo de base de datos. En un modelo relacional, los datos se organizan en forma de tablas con diferentes tablas que representan entidades o relaciones diferentes entre un conjunto de entidades. El almacenamiento de datos se ocupa de la conservación de estas tablas de base de datos en discos. Las formas más comunes para lograr esto es utilizar los archivos. Secuencial, indexada, y los archivos de hash se utiliza en todo este fin con diferentes estructuras de archivos que proporcionan un rendimiento diferente acceso y comodidad. 12.6. La minería de datos A menudo se tiene que saber qué buscar antes de consultar una base de datos. Este

tipo de "localización de" acceso no hace un uso completo de la gran cantidad de información almacenada en la base de datos, y de hecho reduce la base de datos en una colección de registros discretos. Para sacar el máximo provecho de una base de datos, se puede realizar el análisis estadístico y el patrón de descubrimiento sobre el contenido de una base de datos utilizando una técnica llamada minería de datos. Tales operaciones se pueden utilizar para apoyar una serie de actividades comerciales que incluyen, pero no se limitan a, la comercialización, la detección del fraude, y el análisis de tendencias. Numerosas formas para llevar a cabo la extracción de datos se han inventado en los últimos diez años e incluyen técnicas comunes como la descripción de la clase, la discriminación de clase, análisis de conglomerados, análisis de asociación, y el análisis de valores atípicos. 13. Conexión de red básica de comunicación Una red de ordenadores conecta un conjunto de equipos y permite a los usuarios de los diferentes ordenadores para compartir recursos con otros usuarios. Una red facilita las comunicaciones entre todos los ordenadores conectados y puede dar la ilusión de un único equipo, omnipresente. Cada ordenador o un dispositivo conectado a una red se denominan un nodo de red. Una serie de paradigmas de computación han surgido para beneficiarse de las funciones y capacidades proporcionadas por las redes de ordenadores. Estos paradigmas incluyen la computación distribuida, , la informática de Internet y la computación en nube. 13.1. Tipos de Red Las redes de ordenadores no todos son iguales y pueden clasificarse de acuerdo a una amplia variedad de características, incluyendo el método de conexión a la red, tecnologías cableadas, las tecnologías

inalámbricas, la escala, la topología de red, funciones, y la velocidad. Sin embargo, la clasificación que es familiar para la mayoría se basa en la escala de las redes.

• Personal Área Network Inicio / Home Network es una red de ordenador utilizado para la comunicación entre la computadora (s) y los dispositivos tecnológicos de información diferente cerca de una persona.

Los dispositivos conectados a dicha red pueden incluir ordenadores, faxes, agendas electrónicas y televisores. Esta es la base sobre la cual se construye el Internet de las cosas.

• Red de Área Local (LAN) conecta ordenadores y dispositivos en un área geográfica limitada, como un campus de la escuela, sala de ordenadores, edificio de oficinas, o grupo de cerca posicionado de edificios.

• Campus Red es una red informática compuesta de una interconexión de redes de área local (LAN) dentro de un área geográfica limitada.

• Red de área amplia (WAN) es una red de computadoras que cubre una gran área geográfica, como una ciudad o país o incluso a través de distancias intercontinentales. Una WAN limitado a una ciudad a veces se llama una red de área metropolitana.

• Internet es la red mundial que conecta equipos de muchos (tal vez todos) los países.

Otras clasificaciones pueden dividir las redes en las redes de control, redes de almacenamiento, redes privadas virtuales (VPN), redes inalámbricas, redes punto a punto, y Internet de los objetos. 13.2. Componentes de la Red Básica

Todas las redes se componen de los mismos componentes básicos de hardware, incluyendo ordenadores, tarjetas de interfaz de red (NIC), puentes, concentradores, conmutadores y routers. Todos estos componentes se denominan nodos en la jerga de las redes. Cada componente realiza una función distintiva que es esencial para el embalaje, la conexión, la transmisión, la amplificación, el control, desembalaje, y la interpretación de los datos. Por ejemplo, un repetidor amplifica las señales, un switch realiza muchos-a-muchos conexiones, un concentrador realiza uno-a-muchos conexiones, una tarjeta de interfaz está conectado al ordenador y realiza el embalaje y transmisión de datos, un puente conecta una red con otro, y un router es un ordenador en sí y realiza el análisis de datos y control de flujo para regular los datos de la red. Las funciones realizadas por diversos componentes de la red corresponden a las funciones especificadas por uno o más niveles del modelo de redes de siete capas Sistemas abierto Interconexión (OSI), que se discute a continuación. 13.3. Protocolos de red y Estándares Las computadoras se comunican entre sí a través de protocolos, que especifican el formato y la normativa utilizada para empacar y datos no-carga. Para facilitar más fácil la comunicación y la mejor estructura, los protocolos de red se dividen en diferentes capas y cada capa se trata de un aspecto de la comunicación. Por ejemplo, las capas físicas se ocupan de la conexión física entre las partes que se van a comunicar, las ofertas de la capa de enlace de datos con la transmisión de datos en bruto y control de flujo, y las ofertas de la capa de red con el embalaje y ONU-empaquetamiento de datos en una determinada formato que sea entendible por las partes pertinentes. El modelo de red OSI más comúnmente utilizado organiza protocolos de red en siete capas, como se representa en la figura 13.5.

Una cosa a tener en cuenta es que no todos los protocolos de red implementan todas las capas del modelo OSI. Por ejemplo, el protocolo TCP / IP implementa ni la capa de presentación, ni la capa de sesión. No puede haber más de un protocolo para cada capa. Por ejemplo, UDP y TCP Ambos trabajan en la capa de transporte por encima de la capa de red de IP, proporcionando de mejor esfuerzo, el transporte no fiable (UDP) vs. función de transporte confiable (TCP). Capa física protocolos incluyen Token Ring, Ethernet, Fast Ethernet, Gigabit Ethernet y Ethernet inalámbrico. Datos protocolos de capa de enlace incluyen frame relay, asíncrono el modo de transferencia (ATM), y Punto a (PPP). Protocolos de capa de aplicación incluir canal de fibra, interfaz de sistema para pequeñas computadoras (SCSI), y Bluetooth. Para cada capa o incluso cada protocolo individual, puede haber normas establecidas por nacionales o internacionales organizaciones para guiar el diseño y desarrollo de los protocolos correspondientes.

Figura 13.5. El modelo OSI de siete capas de redes 13.4. La Internet El Internet es un sistema mundial de interconectados gubernamental, académico, empresarial, público y redes de ordenadores privados. En el acceso al dominio público a Internet es a través de organizaciones conocidas como proveedores de servicios de Internet (ISP). El ISP mantiene uno o más centros de conmutación denominan un punto de presencia, que en realidad se conecta a los usuarios a Internet.

13.5. Internet de las Cosas El Internet de las cosas se refiere a la interconexión de los objetos cotidianos -tales como los automóviles, teléfonos celulares, PDAs, televisores, refrigeradores, e incluso edificios: el uso de las tecnologías de redes cableadas o inalámbricas. La función y el propósito de la Internet de los objetos es interconectar todas las cosas para facilitar la vida autónoma y mejor. Las tecnologías utilizadas en la Internet de los objetos incluyen RFID, inalámbricas y redes cableadas, tecnología de sensores, software y mucho, por supuesto. A medida que el paradigma de Internet de las cosas todavía está tomando forma, se necesita mucho trabajo para la Internet de los objetos para ganar la aceptación de amplia difusión. 13.6. Red Privada Virtual (VPN) Una red privada virtual es una conexión virtual planificada de antemano entre los nodos de una red LAN / WAN o Internet. Permite al administrador de la red para separar el tráfico de red en los grupos de usuarios que tienen una afinidad común por los demás, como todos los usuarios de la misma organización, o grupo de trabajo. Este tipo de circuito puede mejorar el rendimiento y la seguridad entre los nodos y permite un mantenimiento más fácil de circuitos para solucionar problemas. 14. Computación Paralela y Distribuida La computación paralela es un paradigma de computación que surge con el desarrollo de unidades multi-funcionales dentro de un ordenador. El principal objetivo de computación en paralelo es para ejecutar varias tareas simultáneamente en diferentes unidades funcionales y por lo tanto mejorar el rendimiento o la respuesta o ambos. La informática distribuida, por otra parte, es un paradigma de computación que surge con el desarrollo de las redes de ordenadores. Su principal objetivo es o bien hacer uso de varios ordenadores en la red para llevar a

cabo las cosas de otra manera no es posible dentro de un único equipo o mejorar la eficiencia de cálculo mediante el aprovechamiento de la potencia de múltiples ordenadores. 14.1. Computación Paralela y Distribuida Visión de conjunto Tradicionalmente, la computación paralela investiga formas de maximizar la concurrencia (la ejecución simultánea de múltiples tareas) dentro de los límites de un ordenador. Estudios de sistemas de computación distribuida, que consiste en varios equipos autónomos que se comunican a través de una red de ordenadores distribuidos. Alternativamente, la informática distribuida también puede referirse a la utilización de sistemas distribuidos para resolver problemas de cálculo o transaccionales. En la definición anterior, la computación distribuida investiga los protocolos, mecanismos y estrategias que constituyen la base para el cálculo distribuido; en la última definición, la informática distribuida estudia las formas de dividir un problema en muchas tareas y la asignación de estas tareas a varios equipos implicados en el cálculo. Fundamentalmente, la computación distribuida es otra forma de computación en paralelo, aunque en una escala más grande. En la computación distribuida, las unidades funcionales no son ALU, FPU, o núcleos separados, pero los ordenadores individuales. Por esta razón, algunas personas consideran la computación distribuidos por ser la misma que la computación paralela. Debido a que ambas distribuidas y computación paralela implican alguna forma de concurrencia, que son a la vez también llamada computación concurrente. 14.2. Diferencia entre Paralela y Distribuida Informática A pesar de la computación paralela y distribuida se parecen entre sí en la

superficie, hay una distinción sutil pero real entre ellos: la computación en paralelo no se refiere necesariamente a la ejecución de programas en diferentes Computadores - lugar, que se pueden ejecutar en diferentes procesadores en un único ordenador . De hecho, el consenso entre los profesionales de la informática limita el alcance de la computación paralela al caso en una memoria compartida es usada por todos los procesadores que participan en el cómputo, mientras que la computación distribuida se refiere a cálculos donde existe memoria privada para cada transformador implicado en los cálculos. Otra diferencia sutil entre la computación paralela y distribuida es que la computación paralela hace necesario la ejecución simultánea de varias tareas mientras computación distribuida no tiene esta necesidad. Sobre la base de la discusión anterior, es posible clasificar los sistemas concurrentes como "paralelo" o "distribuido", basada en la existencia o no existencia de memoria compartida entre todos los procesadores: ofertas de computación en paralelo con cálculos en una sola computadora; distribuido ofertas de computación con los cálculos dentro de un conjunto de equipos. De acuerdo con este punto de vista, la computación multinúcleo es una forma de computación en paralelo. 14.3. Computación Paralela y Distribuida Modelos Desde múltiples ordenadores / procesadores / núcleos están involucrados en la computación distribuida / paralelo, es necesario algún tipo de coordinación entre las partes involucradas para garantizar un comportamiento correcto del sistema. Las diferentes formas de coordinación dan lugar a diferentes modelos de computación. Los modelos más comunes en este sentido son el modelo de memoria compartida

(paralelo) y el modelo de paso de mensajes (distribuido). En un modelo de memoria compartida (paralela), todos los equipos tienen acceso a una memoria central compartida donde se utilizan cachés locales para acelerar la capacidad de procesamiento. Estos cachés utilizan un protocolo para asegurar que el dato localizado es fresco y hasta la fecha, por lo general el protocolo MESI. El diseñador algoritmo elige el programa para su ejecución por cada equipo. El acceso a la memoria central puede ser síncrono o asíncrono, y que debe coordinarse de tal manera que se mantiene la coherencia. Diferentes modelos de acceso se han inventado para tal fin. En un modelo de paso de mensajes (distribuido), todos los equipos que ejecutan algunos programas que permitan alcanzar colectivamente algún propósito. El sistema debe trabajar correctamente con independencia de la estructura de la red. Este modelo se puede clasificar aún más en cliente-servidor (C / S), el navegador-servidor (B / S), y los modelos de n niveles. En el modelo C / S, el servidor proporciona servicios y los servicios de cliente solicita desde el servidor. En el B / S modelo, el servidor proporciona servicios y el cliente es el navegador. En el modelo de n niveles, cada nivel (es decir, la capa) proporciona servicios a la capa inmediatamente superior y solicitudes de servicios desde el nivel inmediatamente inferior. De hecho, el modelo de n niveles puede ser visto como una cadena de modelos cliente-servidor. A menudo, los niveles entre el nivel más inferior y el nivel superior se llaman middleware, que es un objeto independiente de estudio en su propio derecho. 14.4. Principales Problemas en Computación Distribuida La coordinación entre todos los componentes en un entorno de computación distribuida es a menudo compleja y requiere mucho tiempo. A medida que el número de

núcleos / CPU / ordenadores aumenta, la complejidad de la computación distribuida también aumenta. Entre los muchos problemas que enfrentan, la coherencia de la memoria y el consenso entre todos los equipos son los más difíciles. Muchos paradigmas de computación se han inventado para resolver estos problemas y son los principales puntos de discusión en la computación distribuida / paralela. 15. Los factores humanos básicos de los usuarios El software se desarrolla para satisfacer deseos o necesidades humanas. Por lo tanto, todo el diseño y desarrollo de software deben tener en cuenta factores-usuario humano consideración por ejemplo, cómo las personas utilizan software, software de cómo la gente ve, y lo que los humanos esperan de software. Hay numerosos factores en la interacción hombre-máquina, e ISO 9241 serie de documentos definen todas las normas detalladas de tales interacciones. Sin embargo, los factores básicos para el usuario humano considerados aquí incluyen entrada / salida, el manejo de mensajes de error, y el robustez del software en general. 15.1. Entrada y salida La entrada y salida son las interfaces entre los usuarios y el software. El software es inútil sin entrada y salida. Seres humanos software de diseño para procesar alguna entrada y producir una salida deseable. Todos los ingenieros de software deben tener en cuenta la entrada y salida como una parte integral del producto de software que ingeniero o desarrollan. Los temas considerados para la entrada incluyen (pero no se limitan a):

• ¿Qué se requiere de entrada? • ¿Cómo se pasa de la entrada de los

usuarios a los ordenadores?

• ¿Cuál es la manera más conveniente para los usuarios entrar en la entrada?

• ¿En qué formato requiere el equipo de los datos de entrada?

El diseñador debe solicitar los datos mínimos de la intervención humana, sólo cuando los datos aún no están guardados en el sistema. El diseñador debe formatear y editar los datos en el momento de la entrada para reducir los errores derivados de la introducción de datos incorrectos o maliciosos. Para la salida, debemos tener en cuenta lo que los usuarios desean ver:

• ¿En qué formato se desea ver los usuarios de salida?

• ¿Cuál es la manera más agradable para mostrar la salida?

Si la parte que interactúa con el software no

es humana sino otro software o sistema

informático o de control, entonces tenemos

que considerar el tipo de entrada / salida y el

formato que el software debe producir para

asegurar el intercambio de datos entre los

sistemas adecuada.

Hay muchas reglas de oro para los

desarrolladores a seguir para producir el bien

de entrada / salida para un software.

Estas reglas de oro incluir un diálogo sencillo

y natural, hablando el lenguaje de los

usuarios, lo que minimiza la carga de

usuarios de la memoria, la coherencia, la

mínima sorpresa, la conformidad con las

normas (si aceptó o no: por ejemplo, los

automóviles tienen una interfaz estándar

para acelerador, frenos, dirección).

15.2. Error de mensajes

Es comprensible que la mayoría del software

contiene errores y no de vez en cuando. Sin

embargo, los usuarios deben ser notificados

si hay algo que impide la correcta ejecución

del programa.

Nada es más frustrante que una terminación

inesperada o desviación del comportamiento

del software sin ninguna advertencia o

explicación. Para ser fácil de usar, el software

debe comunicar todas las condiciones de

error a los usuarios o aplicaciones de nivel

superior de manera que hasta cierto punto

se puede tomar para rectificar la situación o

para salir con gracia. Existen varias pautas

que definen lo que constituye un buen

mensaje de error: mensajes de error deben

ser claros, hasta el punto, y oportuna.

En primer lugar, los mensajes de error deben

explicar claramente lo que está sucediendo

para que los usuarios sepan lo que está

pasando en el software. En segundo lugar,

los mensajes de error deben determinar la

causa del error, si es posible, por lo que las

acciones adecuadas se pueden tomar.

En tercer lugar, los mensajes de error deben

mostrarse justo cuando se produce la

condición de error. Según Jakob Nielsen, "Los

buenos mensajes de error deben expresarse

en un lenguaje sencillo (sin códigos), indica

con precisión el problema, y

constructivamente proponer una solución".

En cuarto lugar, los mensajes de error no

deben sobrecargar los usuarios con

demasiada información y hacer que se

ignoran los mensajes de todos juntos.

Sin embargo, los mensajes relacionados con

errores de acceso de seguridad no deben

proporcionar información adicional que

ayude a las personas no autorizadas minan.

15.3. La robustez del software

Robustez Software se refiere a la capacidad

del software para tolerar las entradas

erróneas. Software se dice que es robusta si

sigue funcionando incluso cuando se dan las

entradas erróneas. Por lo tanto, es

inaceptable para el software se bloquee,

simplemente, cuando se encuentra con un

problema de entrada ya que esto puede

provocar consecuencias inesperadas, como

la pérdida de datos valiosos. Software que

exhibe tal comportamiento se considera que

carecen de robustez.

Nielsen da una descripción más simple de

robustez software: "El software debe tener

una baja tasa de error, por lo que los

usuarios hacen pocos errores durante el uso

del sistema y de manera que si lo hacen

cometer errores que pueden recuperarse

fácilmente de ellos. Además, errores

catastróficos no deben ocurrir”.

Hay muchas maneras de evaluar la robustez

del software y al igual que muchas maneras

de hacer el software más robusto. Por

ejemplo, para mejorar la robustez, uno debe

siempre comprobar la validez de las entradas

y valores de retorno antes de progresar aún

más; uno siempre debe lanzar una excepción

cuando ocurre algo inesperado, y uno nunca

debe salir de un programa sin antes dar a los

usuarios / aplicaciones una oportunidad para

corregir la condición.

16. Desarrollador básica sobre factores

humanos

Factores humanos desarrolladores se

refieren a las consideraciones de factores

humanos tomadas en el desarrollo de

software. El software se desarrolla por los

seres humanos, leído por los seres humanos,

y mantenido por los seres humanos. Si algo

está mal, los seres humanos son

responsables de corregir esos errores. Por lo

tanto, es esencial para escribir software de

una manera que es fácilmente comprensible

por los seres humanos o, al menos, por otros

desarrolladores de software. Un programa

que es fácil de leer y entender la legibilidad

exposiciones.

Los medios para asegurar que el software de

cumplir con este objetivo son numerosos y

van desde la arquitectura adecuada a nivel

macro al estilo de codificación particular y

uso de variables a nivel micro.

Pero los dos factores importantes son la

estructura (o programa) y los diseños de los

comentarios (documentación).

16.1. Estructura

Programas bien estructurados son más

fáciles de entender y modificar. Si un

programa no está bien estructurado,

entonces ninguna cantidad de explicación o

indicación es suficiente para que sea

comprensible. Las formas de organizar un

programa son numerosas y van desde el uso

adecuado de los espacios en blanco, la

sangría, y los paréntesis de buenos arreglos

de agrupaciones, líneas en blanco, y los

apoyos. Sea cual sea el estilo que se elija,

debe ser consistente a través de todo el

programa.

16.2. Comentarios

Para la mayoría de la gente, la programación

es la codificación. Estas personas no se dan

cuenta de que la programación también

incluye comentarios que escriben y que los

comentarios son una parte integral de la

programación. Es cierto que los comentarios

no son utilizados por el ordenador y, desde

luego, no constituyen las últimas

instrucciones para el equipo, pero mejoran la

legibilidad de los programas, explicando el

significado y la lógica de los estados o

secciones de código. Debe recordarse que los

programas no sólo están hechos para

computadoras, también se leen, escriben, y

modificados por los seres humanos.

Los tipos de comentarios incluyen la

repetición del código, explicación del código,

marcador del código, resumen del código,

descripción de la intención del código, y la

información que no puede ser expresado por

el propio código. Algunos comentarios son

buenos, algunos no lo son. Los buenos son

los que explican la intención del código y

justificar por qué este código es la forma en

que lo hace. Los malos son la repetición del

código, e indicando la información

irrelevante. Los mejores comentarios son

autodocumentados en código. Si el código

está escrito de manera clara y precisa que su

significado se autoproclamada, entonces no

se necesita ningún comentario. Pero esto es

más fácil decirlo que hacerlo. La mayoría de

los programas no son fáciles de entender y

son a menudo difíciles de leer y entender si

no se dan los comentarios.

Aquí hay algunas pautas generales para la

escritura de comentarios:

• Los comentarios deben ser

coherentes en todo el programa.

• Cada función debe estar asociado

con los comentarios que explican el

propósito de la función y su papel en

el programa general.

• Dentro de una función, los

comentarios se deben dar por cada

sección lógica de codificación para

explicar el significado y propósito

(intención) de la sección.

• Los comentarios deben estipular lo

que hace la libertad (o no) los

programadores que mantienen tener

con respecto a realizar cambios en el

código.

• Los comentarios son rara vez

necesarios para los estados

individuales. Si necesita una

declaración comentarios, se debe

reconsiderar el comunicado.

17. Desarrollo de software seguro y

Mantenimiento

Debido al aumento de las actividades

maliciosas dirigidas a los sistemas

informáticos, la seguridad se ha convertido

en un problema importante en el desarrollo

de software. Además de la exactitud y

fiabilidad de costumbre, los desarrolladores

de software también deben prestar atención

a la seguridad del software que desarrollan.

Desarrollo de software seguro se basa en la

seguridad del software siguiendo un

conjunto de reglas y prácticas establecidas y

/ o recomendadas en el desarrollo de

software.

Mantenimiento de software seguro

complementa el desarrollo de software

seguro asegurando se introducen los

problemas de seguridad durante el

mantenimiento de software.

Una vista en relación con la seguridad del

software generalmente aceptada es que es

mucho mejor para el diseño de seguridad en

el software de parchear que después se

desarrolló el software. Diseñar la seguridad

en el software, hay que tener en cuenta

todas las etapas del ciclo de vida de

desarrollo de software. En particular, el

desarrollo de software seguro implica la

seguridad requisitos de software, la

seguridad de diseño de software, la

seguridad de la construcción de software, la

seguridad y pruebas de software.

Además, la seguridad también debe tenerse

en cuenta al realizar el mantenimiento de

software como fallas de seguridad y lagunas

pueden ser ya menudo se introducen

durante el mantenimiento.

17.1. Requisitos de software de seguridad

Requisitos de software ofertas de seguridad

con la clarificación y la especificación de la

política y objetivos de seguridad en los

requisitos de software, que sienta las bases

para las consideraciones de seguridad en el

desarrollo de software. Los factores a

considerar en esta fase incluyen los

requisitos de software y amenazas / riesgos.

El primero se refiere a las funciones

específicas que se requieran para el bien de

la seguridad; el último se refiere a las

posibles formas en que se ve amenazada la

seguridad del software.

17.2. Diseño de Software de Seguridad

Ofertas de software de seguridad de diseño

con el diseño de módulos de software que

encajan entre sí para cumplir con los

objetivos de seguridad especificadas en los

requisitos de seguridad. Este paso aclara los

detalles de las consideraciones de seguridad

y desarrolla los pasos específicos para su

implementación. Los factores considerados

pueden incluir marcos y modos de acceso

que se instalan las estrategias de seguridad

de supervisión / aplicación general, así como

los mecanismos de aplicación de políticas

individuales.

17.3. El software de seguridad de

construcción

La seguridad de la construcción de software

se refiere a la cuestión de cómo escribir

código de programación real para

situaciones específicas tales que las

consideraciones de seguridad son atendidas.

El término "Construcción de Software de

Seguridad" puede significar cosas diferentes

para diferentes personas. Puede significar la

forma en que una función específica está

codificada, de manera que la codificación en

sí es seguro, o puede significar la codificación

de seguridad en el software.

La mayoría de las personas se enredan los

dos juntos sin distinción. Una de las razones

para tal enredo es que no está claro cómo se

puede garantizar que una codificación

específica sea segura. Por ejemplo, en el

lenguaje de programación C, la expresión de i

<1 (desplazar la representación binaria del

valor de i a la izquierda de un bit) y 2 * i

(multiplicar el valor de la variable I por la

constante 2) significan lo mismo

semánticamente, pero no tienen la misma

ramificación de seguridad?

La respuesta podría ser diferente para

diferentes combinaciones de las NIA y

compiladores. Debido a esta falta de

entendimiento, la construcción de software

seguridad- en su estado actual de existencia

se refiere, sobre todo con el segundo

aspecto mencionado anteriormente: la

codificación de seguridad en el software.

Codificación de seguridad en el software se

puede lograr siguiendo las reglas

recomendadas. Unas dichas reglas a

continuación:

• Estructurar el proceso de modo que

todas las secciones que requieren

privilegios adicionales son módulos.

Los módulos deben ser lo más

pequeña posible y se deben realizar

sólo aquellas tareas que requieren

esos privilegios.

• Asegúrese de que los supuestos en el

programa son validados. Si esto no

es posible, documentarlas para los

instaladores y mantenedores para

que sepan que los supuestos

atacantes tratarán de invalidar.

• Asegúrese de que el programa no

comparte objetos en la memoria con

cualquier otro programa.

• El estado de error de cada función

debe ser comprobado. No trate de

recuperar a menos que ni la causa

del error ni sus efectos afectan a las

consideraciones de seguridad. El

programa debe restaurar el estado

del software al estado que tenía

antes de que comenzara el proceso,

y luego terminar.

17.4. El software de seguridad Prueba

Las pruebas de software de seguridad

determinan que el software protege los

datos y mantiene la especificación de

seguridad como se indica. Para obtener más

información, consulte la Prueba de Software

KA.

17.5. Construir Seguridad en Ingeniería de

Procesos de Software

El software es tan fuerte como su proceso de

desarrollo va. Para garantizar la seguridad

del software, la seguridad debe ser

incorporada en el proceso de ingeniería de

software. Una tendencia que surge a este

respecto es el concepto asegurar el

desarrollo del ciclo de vida (SDL), que es un

modelo en espiral clásica que toma una

visión integral de la seguridad desde la

perspectiva del ciclo de vida del software y

asegura que la seguridad es inherente en el

diseño y desarrollo de software, no es una

idea de último momento después de la

producción. El proceso SDL se demanda para

reducir los costes de mantenimiento de

software y aumentar la fiabilidad del

software en relación con los fallos

relacionados con la seguridad de software.

17.6. Guía de seguridad de software

Aunque no hay maneras a prueba de balas

para el desarrollo de software seguro,

existen algunas pautas generales que se

pueden utilizar para ayudar a tales esfuerzos.

Estas directrices abarcan todas las fases del

ciclo de vida de desarrollo de software.

Algunas pautas de buena reputación son

publicadas por la computadora de

emergencia.

Equipo de Respuesta (CERT) y por debajo son

las 10 mejores prácticas de seguridad de

software (los detalles se pueden encontrar

en:

1. Validar entrada.

2. Haga caso de las advertencias del

compilador.

3. El arquitecto y el diseño de las políticas de

seguridad.

4. Debe ser sencillo.

5. denegación predeterminada.

6. Respetar el principio de privilegios

mínimos.

7. Los datos Higienice enviados a otro

software.

8. La práctica de defensa en profundidad.

9. Utilizar técnicas de garantía de calidad

eficaz.

10. Adoptar un estándar de seguridad de

construcción de software.

Referencias [1] Grupo de Trabajo Conjunto sobre Computación planes de estudio, IEEE Computer Society y la Asociación for Computing Machinery, Software Ingeniería 2004: Lineamientos Curriculares Para estudiantes de pregrado en los programas de grado Ingeniería de Software, 2004; http: // sites. computer.org/ccse/SE2004Volume.pdf. [2 *] G. Voland, Ingeniería de Diseño, 2ª ed., Prentice Hall, 2003. [3 *] S. McConnell, código completo, 2ª ed., Microsoft Press, 2004. [4 *] J.G. Brookshear, Ciencias de la Computación: Una visión general, 10ª ed, Addison-Wesley, 2008.. [5 *] E. Horowitz et al., Algoritmos informáticos, 2ª ed., Silicon Press, 2007.

[6 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [7] ISO / IEC / IEEE 24765: 2010 Sistemas y Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010. [8 *] L. y J. Null Lobur, Lo Esencial de la Organización de Computadores y Arquitectura, 2ª ed., Jones and Bartlett Publishers, 2006. [9 *] J. Nielsen, Ingeniería de usabilidad, Morgan Kaufmann, 1993. [10] ISO 9241-420: 2011 Ergonomía de la interacción humano-sistema, la norma ISO 2011. [11 *] M. Bishop, Computer Security: Arte y Ciencia, Addison-Wesley, 2002. [12] R. C. Seacord, el CERT c Fije Codificación Estándar, Addison-Wesley Professional

2008.0’