COCOMO

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado. 

La función básica que utilizan los tres modelos es:

E = a(Kl)^b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo

Kl es la cantidad de líneas de código, en miles.

m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:

• Modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).

• Modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.

• Modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

Modelo básico: Se utiliza para obtener una primera aproximación rápida del esfuerzo, y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:

MODO	a	b	c	d
Orgánico	2.40	1.05	2.50	0.38
Semilibre	3.00	1.12	2.50	0.35
Rígido	3.60	1.20	2.50	0.32

Estos valores son para las fórmulas:

• Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Kl^b)

• Tiempo de desarrollo del proyecto (TDEV) = c*(MM^d)

• Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV

• Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal.

 Modelo intermedio: Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación. Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar. Los valores de las constantes a reemplazar en la fórmula son:

MODO	a	b
Orgánico	3.20	1.05
Semilibre	3.00	1.12
Rígido	2.80	1.20

Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos: Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).

El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:

Atributos	Valor
	Muy bajo	Bajo	Nominal	Alto	Muy alto	Extra alto
Atributos de software
Fiabilidad	0,75	0,88	1,00	1,15	1,40
Tamaño de Base de datos		0,94	1,00	1,08	1,16
Complejidad	0,70	0,85	1,00	1,15	1,30	1,65
Atributos de hardware
Restricciones de tiempo de ejecución			1,00	1,11	1,30	1,66
Restricciones de memoria virtual			1,00	1,06	1,21	1,56
Volatilidad de la máquina virtual		0,87	1,00	1,15	1,30
Tiempo de respuesta		0,87	1,00	1,07	1,15
Atributos de personal
Capacidad de análisis	1,46	1,19	1,00	0,86	0,71
Experiencia en la aplicación	1,29	1,13	1,00	0,91	0,82
Calidad de los programadores	1,42	1,17	1,00	0,86	0,70
Experiencia en la máquina virtual	1,21	1,10	1,00	0,90
Experiencia en el lenguaje	1,14	1,07	1,00	0,95
Atributos del proyecto
Técnicas actualizadas de programación	1,24	1,10	1,00	0,91	0,82
Utilización de herramientas de software	1,24	1,10	1,00	0,91	0,83
Restricciones de tiempo de desarrollo	1,23	1,08	1,00	1,04	1,10

Modelo Detallado: Presenta principalmente dos mejoras respecto al anterior:

• Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además van variando de una etapa a otra.

• Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.

Métricas del Software

Las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso se mide para intentar mejorarlo, el producto para intentar aumentar su calidad. Las métricas se clasifican en:


1) Orientadas al tamaño: Son medidas directas del software y del proceso.

kldc= cantidad de líneas de código.

productividad	kldc/ personas- mes.
calidad	errores/kldc.
costo	Dólares/kldc.
documentación	Páginas de documentación/kldc.

2) Orientadas a la función:  Son medidas indirectas del software se centran en la funcionalidad o utilidad del programa. Miden la cantidad de funciones que se van a lograr para lo que se precisa un excelente relevamiento, precisiones estables.Se calculan los puntos de función: número de entradas, número de salidas, números de peticiones, números de archivos.

Una vez calculados los puntos de función: PF=puntos de función

productividad	PF/pers-mes
calidad	errores/PF
costo	Dólares/PF
documentación	pág. de doc./PF

3) Orientadas a la persona:  Analizan en relación a las herramientas de desarrollo, el grado de capacitación en el uso de la herramienta y la complejidad estimada de la tarea.

Métricas de Calidad: Las métricas a posteriori incluyen :

• Corrección: Grado con que el software realiza la función requerida.
• Facilidad de mantenimiento: Facilidad con la que se puede corregir el programa. Se utilizan medidas indirectas y se calcula el tiempo medio entre cambios.
• Integridad: Habilidad de un sistema para resistir ataques contra seguridad. Se mide en base a una probabilidad de recibir ataque y la probabilidad de repelerlo.
• Facilidad de uso: Es un intento de cuantificar la amistad con el usuario. Se mide en función a la habilidad y tiempo requeridos para aprender el sistema, al aumento neto de productividad y la disponibilidad del usuario hacia el sistema.

 
Ver màs en: http://www.monografias.com/trabajos15/ingenieria-software/ingenieria-software2.shtml

Conceptos del espectro de gestión

El espectro de la gestión

La gestión eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.

Personal

El <<factor humano>> es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) <<para aumentar la preparación de organizaciones del software.

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo.

Producto

El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).

Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.

Proyecto

Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.

PERSONAL

Los participantes: El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de estas cinco categorías:

1.- Gestores superiores,que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
2.- Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
3.- Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
4.- Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.
5.- Usuarios finales, que interaccionan con el software una vez que ha entregado para la producción.

Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.

Los jefes de equipo:Weinberg sugiere que el éxito de los gestores de proyecto se basa en aplicar un estilo de gestión en la resolución de problemas. Es decir, un gestor de proyectos de software debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y, mucho más importante, con hechos) que la calidad es importante y que no debe verse comprometida.

El equipo de software:Existen casi tantas estructuras de organización de personal para el desarrollo de software como organizaciones que se dedican a ello. Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k años:

1. n individuos son asignados a m diferentes tareas funcionales, tiene lugar relativamente poco trabajo conjunto.
2. n individuos son asignados a m diferentes tareas funcionales (m<n) de manera que se establecen <<equipos>> informales.
3. n individuos se organizan en t equipos; a cada equipo se le asignan una o más tareas funcionales.

La <<mejor>> estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Mantei sugiere tres organigramas de equipo genéricos:

Descentralizado democrático (DD): Este equipo de ingeniería del software no tiene un jefe permanente. Más bien, <<se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas>>.

Descentralizado controlado (DC): Este equipo de ingeniería de software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas.

Centralizado controlado (CC): El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo.

Mantei describe siete factores de un proyecto que deberían considerarse cuando se planifica el organigrama de equipos de ingeniería del software:

· La dificultad del problema que hay que resolver.
· El tamaño del programa(s) resultante(s) en líneas de código o puntos de función.
· El tiempo que el equipo estará junto (tiempo de vida del equipo).
· El grado en que el problema puede ser modularizado.
· La calidad requerida y fiabilidad del sistema que se va a construir.
· La rigidez de la fecha de entrega.
· El grado de sociabilidad (comunicación) requerido para el proyecto.

Los equipos CC y DC producen menos defectos que los equipos DD, pero estos datos tienen mucho que ver con las actividades específicas de garantía de calidad que aplica el equipo. Los equipos descentralizados requieren generalmente más tiempo para completar un proyecto que un organigrama centralizado y al mismo tiempo son mejores cuando se precisa una gran cantidad de comunicación.

Constantine sugiere cuatro <<paradigmas de organización>> para equipos de ingeniería del software:

1.- Un paradigma cerrado estructura a un equipo con una jerarquía tradicional de autoridad (similar al equipo CC).

2.- El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo.

3.- El paradigma abierto intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero también utiliza el paradigma aleatorio.

4.- El paradigma sincronizado se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Constantine propone una variación en el equipo descentralizado democrático defendiendo a los equipos con independencia creativa cuyo enfoque de trabajo podría ser mejor llamado <<anarquía innovadora>>. Para conseguir un equipo de alto rendimiento:

· Los miembros del equipo deben confiar unos en otros.
· La distribución de habilidades debe adecuarse al problema.
· Para mantener la unión del equipo, los inconformistas tienen que ser excluidos del mismo.

Aspectos sobre la coordinación y la comunicación

Hay muchos motivos por los que los proyectos de software pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incertidumbre es corriente, dando como resultado un continuo flujo de cambios que impactan al equipo del proyecto. La interoperatividad se ha convertido en una característica clave de muchos sistemas. El software nuevo debe comunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.

Estas características del software moderno, son aspectos de la vida. Para enfrentarse a ellos eficazmente, un equipo de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el trabajo. Para lograr esto se deben establecer mecanismos de comunicación formales e informales entre los miembros del equipo y entre múltiples equipos.

PRODUCTO

El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.

Ámbito del software: El ámbito se define respondiendo a las siguientes cuestiones:

Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultados del contexto?

Objetivos de información: ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?

Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?

Descomposición del problema: La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición se aplica en dos áreas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se empleará para entregarlo.

PROCESO

El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo de software. 

Maduración del producto y del proceso: La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:

· Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente- tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.

Descomposición del proceso: Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.

Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.

PROYECTO

Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:

1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.

EL PRINCIPIO W5HH

El principio WWWWWHH conducen a la definición de las características clave del proyecto y el plan del proyecto resultante:

¿Por qué se desarrolla el sistema?. Dicho de otra forma, ¿justifica el propósito del negocio el gasto en personal, tiempo y dinero?

¿Qué se realizará y cuándo?. La respuesta a estas preguntas ayuda al equipo a establecer la planificación del proyecto identificando las tareas clave del proyecto y los hitos requeridos por el cliente.

¿Quién es el responsable de una función?

¿Dónde están situados organizacionalmente? No todos los roles y responsabilidades residen en el equipo de software. El cliente, los usuarios, y otros directivos también tienen responsabilidades.

¿Cómo estará realizado el trabajo desde el punto de vista técnico y de gestión?. Una vez establecido el ámbito del producto, se debe definir una estrategia técnica y de gestión para el proyecto.

¿Qué cantidad de cada recurso se necesita?. La respuesta a esta pregunta se deriva de las estimaciones realizadas basadas en respuestas a las preguntas anteriores.

Ej 1: Resolver Caso de Estudio Fundación FES aplicando las métricas

Actualmente la fundación Fredick Ebert Stiftung está pretendiendo automatizar sus actividades, a fin de mejorar la gestión de fondos asignados a los diversos programas que ejecutan en Nicaragua. Lo prioritario es la agenda de eventos (lugar, fecha, cant. de participantes, invitaciones, confirmaciones y llenado de datos, expositores, temas, documentos, materiales de apoyo, refrigerio entre otros), posteriormente realizan informes, resumen de temas, incorporan fotos y publican comentarios para hacer encuestas y gráficos.

 

Para la solución del caso de estudio Fundación FES se escogió el modelo básico semilibre porque el equipo de trabajo es principiante, es decir, no tiene mucha experiencia en el desarrollo de software y sus métricas. También se escogió este modelo porque en el equipo de trabajo hay quienes les gusta compartir trabajo y otros que proponen ideas. A la vez se utilizó la metodología orientada a objetos por ser la más actualizada, adecuada al caso y útil para el equipo de trabajo.

               Entidades y atributos de los sub objetivos

 

Local (id_local, id_evento, nombre_local, dirección_local, telf._local, correo_local)

Exponencias (id_exponencia, id_evento, nombre_exponente, apellido_exponente, dirección_exponente, telf_exponente, correo_exponente,tema_exponente)

Evento(id_evento, id_participante, id_exponencia, id_local)

Participante (id_participante, id_evento, id_invitación, id_confirmación, id_alimentos, id_mat_apoyo, nombre_participante, apellido_participante, empresa, correo_participante, telf._participante)

Alimentos (id_alimento, id_participante, nombre_alimento, cant_alimento, proveedor)

Invitación (id_invitación, id_participante, fecha/hora_evento, lugar_evento)

Confirmación ( id_confirmación, id_participante)

Material de Apoyo (id_mat_apoyo, id_participante, tipo_material, cant_material, proveedor)

1.   Recolecta de datos y cálculos de indicadores

      

2.     

Modelos de la Ingenieria del Software

La ingeniería de software tiene varios modelos, paradigmas o filosofías de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

• Modelo en cascada o Clásico (modelo tradicional): es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. Un ejemplo de una metodología de desarrollo en cascada es: 1. Análisis de requisito
  2.Diseño del Sistema 
  3.Diseño del Programa 
  4.Codificación 
  5.Pruebas 
  6.Implantación 
  7.Mantenimiento
  
  
  
  
  
• Modelo de prototipos: Pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.

Etapas 

1.Plan rápido

2. Modelado, diseño rápido

3. Construcción del Prototipo

4. Desarrollo, entrega y retroalimentación

5. Comunicación 

• Modelo en espiral (modelo evolutivo): Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

 

• Desarrollo por etapas: El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código. Pueden distinguirse las siguientes fases:

1.Especificación conceptual

2.Análisis de requerimientos

3.Diseño inicial

4.Diseño detallado, codificación, depuración y liberación

• Desarrollo iterativo y creciente o Iterativo e Incremental:Es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.
  Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.
  
  
  
  
  
• RAD (Rapid Application Development):El desarrollo rápido de aplicaciones o RADacrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. 

El proceso del Software

Producto del Software

El software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo.

Características del Software  

1. El software se desarrolla o construye; no se manufactura en el sentido clásico: A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware, las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseño, la fase de manufactura del hardware puede incluir problemas de calidad existentes en el software.

2. El software no se estropea: El aoftware es inmune a los males ambientales que desgasten el hardware. Por lo tanto la curva de tasas de fallas para el software debería tener la forma de la “curva idealizada”. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen y la curva se aplana: el software no se desgasta, pero si se deteriora. 

3. A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la mayoría del software aun se construye a la medida: Un componente de software se debe diseñar e implementar de forma que puede utilizarse en muchos programas diferentes.Los componentes reutilizables modernos encapsulan tanto los datos como el proceso se aplican a estos, lo que permite al ingeniero de software crear nuevas aplicaciones nuevas a partir de partes reutilizables. 

Aplicaciones del Software

1.      1. Software de sistemas: El software de sistemas es  un conjunto de programas que han sido escritos para servir a otros programas. Ej: compiladores, editores y utilidades de gestión de archivos que procesan estructuras de información compleja pero determinada. 

1.      2. Software de tiempo real: El software que coordina/analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo.

 

1   3.Software de gestión: El proceso de la información comercial constituye la mayor de las áreas de aplicación del software. Los «sistemas» discretos (por ejemplo: nóminas, cuentas de haberes-débi.tos, inventarios, etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG) que accede a una o más bases de datos que contienen información comercial.

2.      4.Software de ingeniería y científico: El software de ingeniería y científico está caracterizado por los algoritmos de «manejo de números». Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática.

3.      5.Software empotrado: Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el con- trol de las teclas de un horno de microondas).

4.      6.Software de computadoras personales: El mercado del software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

 

6.      7. Software de inteligencia artificial: El software d e inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo.