Ingeniero en Software ¡Lo que hace el profesional!

El profesional llamado Ingeniero en software debe desarrollar y entrenarse en diversas disciplinas y conocer tanto la teoría como la practica de diversos campos de estudio, que por su complejidad y amplitud no están al alcance de todos los individuos, para entender este principio básico deben analizarse diversos elementos con cuidado antes de aventurarse a estudiar una carrera universitaria que presenta tantos y tan variados desafíos.

Ingeniero en software

La llamada ingeniería de software se define como un proceso de analizar los requisitos del usuario y luego diseñar, construir y probar aplicaciones de software que satisfagan determinados requerimientos. Se han identificados diversas definiciones para lo que es ingeniería de software:

Ciertas fuentes conocidas definen la ingeniería de software como la aplicación de un enfoque sistemático, disciplinado, que es computable para el desarrollo, operación y mantenimiento de software. Saber que hace un ingeniero en software puede ser complejo de definir en muchos casos.

El Experto Fritz Bauer lo definió como el establecimiento y utilizó principios de ingeniería estándar. Le ayuda a obtener, económicamente, un software que es confiable y funciona eficientemente en la maquinaria real.
Otro academico de renombre, Boehm define la ingeniería de software, como la que implica la aplicación práctica del conocimiento científico al diseño creativo y la construcción de programas informáticos. También incluye la documentación asociada necesaria para desarrollarlos, gestionarlos y mantener su funcionamiento.

La mayoría coincide en que  generalmente comienza con un  primer paso como una iniciación de solicitud del usuario para una tarea específica o una salida. Presenta su requisito a una organización proveedora de servicios. El equipo de desarrollo de software segrega los requisitos del usuario, los requisitos del sistema y los requisitos funcionales.

El requisito se recopila realizando entrevistas a un usuario, refiriéndose a una base de datos, estudiando el sistema existente, etc. Después de reunir los requisitos, el equipo analiza si el software se puede hacer para cumplir con todos los requisitos del usuario. El desarrollador luego decide una hoja de ruta elaborando una planificación.

El estudio correcto del sistema también incluye una comprensión de las limitaciones del producto de software. Según el requisito y el análisis, se realiza un diseño de software. La implementación del diseño de software comienza en términos de escribir código de programa en un lenguaje de programación adecuado.

Los desarrolladores realizan las pruebas de software mientras los desarrolladores codifican y los expertos realizan pruebas exhaustivas en varios niveles de código, tales como pruebas de módulos, pruebas de programas, pruebas de productos, pruebas internas y pruebas del producto con la participación y retroalimentación de las partes interesadas.

Historia

Generalmente se entiende que a fines de la década de 1960 fue cuando muchos proyectos de software fallaron.
Muchos programas se volvieron más caros en su presupuesto. La salida era un software poco confiable que es costoso de gestionar,

Un software de mayor capacidad era difícil y bastante costoso de mantener. Una gran cantidad de software no puede satisfacer los crecientes requisitos del cliente. La complejidad de los proyectos de software aumentaba cada vez que aumentaba su capacidad de hardware. La demanda de nuevo software aumentó más rápido en comparación con la capacidad de generar nuevo software. Todos los problemas anteriores conducen a lo que se conoció como la crisis del software.

Una alternativa al problema fue transformar el esfuerzo de codificación desorganizado en una disciplina de ingeniería de software. Estos modelos de ingeniería ayudaron a las empresas a racionalizar las operaciones y entregar software que satisface los requisitos de las partes interesadas.

Hacia la parte final de la década de los 1970 se vieron los usos generalizados de los principios de ingeniería de software. En la década de 1980, se vio la automatización del proceso de ingeniería de software y el crecimiento de la ingeniería de software asistida por computadora. La década de 1990 ha visto un mayor énfasis en los aspectos de ‘gestión’ de los estándares de calidad y procesos de proyectos. Existen razones importantes detrás de la popularidad de la ingeniería de software y sus derivados:

*Software grande: en la vida real, es bastante más cómodo construir un muro que una casa o edificio. De la misma manera, a medida que el tamaño del software aumenta, la ingeniería de software lo ayuda a edificar un  software.
*La Escalabilidad: si el proceso de desarrollo de software se fundamenta en conceptos científicos y de ingeniería, es más fácil recrear un nuevo software para escalar uno que ya existe.
*La Adaptabilidad: se habla de esta cuando el proceso del software se basó en la ciencia y la ingeniería, es fácil recrear un nuevo software con la ayuda de la ingeniería de software en muchos casos.
*El Costo: la industria del hardware ha demostrado sus habilidades y la gran fabricación ha reducido el costo de la computadora y del denominado hardware electrónico.
*La Naturaleza dinámica: se cree que siempre crece y se adapta la naturaleza del software. Depende del entorno en el que labora el beneficiado.
*Gestión de calidad: Se dice que ofrece un mejor método de desarrollo de software para proporcionar productos de software considerados  muy buenos.

La suma del conjunto de estos elementos conducen a muchos a preguntarse cuanto gana un ingeniero en software debido a la importancia de las actividades que realiza.

Objetivos

1. La Mantenibilidad: se refiere ala facilidad con la que cambia en una unidad funcional y se puede realizar para Cumplir con los requisitos previamente establecidos.
2. La Corrección: se trata de la medida en que el software cumple con los requisitos  mínimos solicitados.
3. Reutilización: se conoce con este termino ala medida en que un módulo puede ser utilizado en múltiples situaciones.

4. Testabilidad: termino para referirse a la medida en que el software facilita tanto el establecimiento de prueba criterios como la evaluación del software con respecto a los mismos.
5. Fiabilidad: así se llama a un atributo del software calidad. La medida en que un programa se puede esperar que realice su intención función, durante un período de tiempo indeterminado.

6. Portabilidad: así de habla de la facilidad con la que el software se puede transferir desde una computadora sistema o entorno a otro totalmente distinto.
7. Adaptabilidad: cuando se reconoce la facilidad con la que el software permite un sistema diferente y el usuario puede que necesite ser satisfecho haciendo cambios en el software que usa.

Relación de la ingeniería de software con otras disciplinas

Informática: es aquella que proporciona la base científica para el software, ya que la ingeniería eléctrica depende principalmente de la física, una área clave.
Ciencia de gestión: se refiera a que la ingeniería de software es un trabajo intensivo en mano de obra que exige control técnico y de gestión. Por lo tanto, es ampliamente utilizado en ciencias de este tipo

Economía: En esta área la ingeniería de software  ayuda en la estimación de recursos y el control de costos. Se debe desarrollar un sistema de computación y los datos deben mantenerse regularmente dentro de un presupuesto determinado.
Ingeniería del sistema:  la mayor parte del software es un componente de un sistema mucho más grande. Por ejemplo, el software en un sistema de monitoreo de la industria o el software de vuelo en un avión. Los métodos de ingeniería de software deben aplicarse al estudio de este clasificación de sistemas.

Desafíos de la ingeniería de software

Existe muchos, pero en áreas críticas para la seguridad, como el espacio, la aviación, las centrales nucleares, son muy relevantes, ya que el costo de la falla del software puede ser enorme porque hay vidas que peligran sino se hace correctamente. Existen ademas Mayores demandas del mercado para tiempos de respuesta mas veloces. Enfrentando la creciente complejidad de la necesidad de software para nuevos problemas.

Características del buen software

Un buen software debe juzgarse por lo que ofrece y cuáles son los métodos que lo ayudan a que funcione correctamente, es por eso que se considera que todo software debe satisfacer los siguientes atributos:

Ser operacional: Es esta característica la que nos permite saber qué tan bien funciona el software en las operaciones que se pueden medir en: Presupuesto, Eficiencia, Usabilidad, Confianza, Exactitud, Funcionalidad y área como la seguridad.

Ser transicional:  Se trata de un aspecto esencial cuando el software se mueve de una plataforma a otra: con Interoperabilidad, Reusabilidad, Portabilidad y aspectos como la Adaptabilidad.

De fácil Mantenimiento: Este termino se refiere a sobre qué tan bien el software tiene la capacidad de adaptarse en el entorno que cambia rápidamente en Flexibilidad, Mantenibilidad, Modularidad y elementos como la Escalabilidad.

Arquitectura

La mayoría de los productos de software son una combinación de rutinas de software, procedimientos, módulos u objetos que proporcionan alguna funcionalidad. El software, como sustancia para el desarrollo de productos, no presenta características físicas.

El software es en realidad un lenguaje que se transforma en corrientes eléctricas dentro de una unidad de procesamiento que permite cálculos matemáticos. Los comandos de software se traducen, lo que permite manipulaciones de datos o, para ser precisos, funciones que representan una operación básica de una computadora que produce un solo resultado cuando se solicita su intervención.

Debido a esto, es esencial que el producto de software esté diseñado para abordar el conjunto completo de comportamientos funcionales que debe mostrar el producto final. La arquitectura del software representa la descomposición de los requisitos en las funciones y subfunciones que son necesarias para proporcionar el comportamiento especificado y las características de rendimiento. La arquitectura de software se refiere al arte y la ciencia de diseñar e implementar productos de software. Se trata de tres elementos fundamentales:

1) Conocer los requisitos del producto; 2) Determinar la llamada arquitectura funcional, que exhibe características funcionales, de rendimiento y de utilización de variados recursos; y 3) y por último la arquitectura física que establece la configuración estructural del producto de software y las relaciones entre los conocidos como elementos estructurales.

Se cree que la arquitectura del software es análoga al conjunto de dibujos y diagramas de ingeniería para un edificio. La construcción del edificio no comienza hasta que se haya redactado el conjunto de dibujos y diagramas; se demuestra que cumplen con los códigos establecidos de Construcción Uniforme, Mecánica y Plomería, y Eléctricos Nacionales; y han sido aprobados por la agencia encargada por la ley de cada país.

De igual manera, la implementación (diseño, codificación y prueba de módulos, etc.) de un producto de software no debe comenzar hasta que la arquitectura del software esté completa, se pueda demostrar que es consistente con los requisitos del software y haya sido autorizada por el proyecto conducir a entrar en la etapa de implementación del desarrollo. No es aconsejable comenzar la construcción sin comprender el alcance total de la responsabilidad que tienen los encargados.

Recursos Humanos

Con este término se conoce a las personas que trabajan y operan una organización, en contraste con los recursos financieros y materiales de una organización.Un recurso humano es una sola persona o empleado dentro de su organización. Los recursos humanos se refieren a todas las personas que emplea.

Recursos humanos también es la función en una organización que se ocupa de las personas y los asuntos relacionados con las personas, tales como compensación y beneficios, reclutamiento y contratación de empleados, incorporación de empleados, gestión del desempeño, capacitación y desarrollo y cultura empresarial.

El grupo de personas que trabajan en Recursos Humanos también es responsable de asesorar al personal superior sobre el impacto en las personas (los recursos humanos) de sus decisiones financieras, de planificación y de desempeño. Los gerentes rara vez discuten el efecto de sus decisiones sobre las personas en las organizaciones. A menudo es predecible que las decisiones sean impulsadas por procesos más fáciles de medir, como las finanzas empresariales y la contaduría.

Este campo evolucionó a partir del término inicial del personal, como funciones del campo, fue más allá de pagar a los empleados y administrar los beneficios de los empleados.La evolución de la función de recursos humanos dio crédito al hecho de que las personas son el recurso más importante de una organización. Las personas son el activo más importante de un emprendimiento y deben ser protegidas.

Ya que son la parte más importante de una organización, los empleados deben ser contratados, satisfechos, motivados, desarrollados y retenidos. Es así cómo los nuevos roles de los empleados de Recursos Humanos han evolucionado para satisfacer mejor estas prioridades.

Modelo RAD

Se trata de un modelo incremental. En el modelo RAD, los componentes o funciones se desarrollan en paralelo como si fueran minie proyectos o prototipos. Un prototipo es un modelo de trabajo que es funcionalmente equivalente a un componente del producto. Los desarrollos son empaquetados en el tiempo, entregados y luego ensamblados en un prototipo que funcione de acuerdo a  lo requerido.

Funciona como un método de desarrollo de software que utiliza una planificación mínima a favor de la creación rápida de prototipos. Los módulos funcionales se desarrollan simultáneamente como prototipos y se integran para hacer el producto completo para una entrega más rápida del producto. El cliente obtiene visibilidad temprana en el software y puede proporcionar comentarios sobre el diseño, la entrega y otras necesidades.

Debido a que no hay una planificación previa detallada, facilita la incorporación de los cambios dentro del proceso de desarrollo. Los proyectos RAD siguen el modelo iterativo e incrementan y tienen pequeños equipos compuestos por desarrolladores, expertos en dominios, representantes de clientes y otros recursos de TI que trabajan progresivamente en su componente o prototipo. El aspecto más importante para que este modelo tenga éxito es asegurarse de que los prototipos desarrollados puedan ser utilizados en el futuro.

Fases del modelo RAD:

Este sistema se puede ajustar a diferentes tipos de modelado entre los que se pueden citar:

Modelado comercial: Un tipo de modelo empresarial para el producto está diseñado y el flujo de información se identifica entre varias funciones comerciales. Se realiza un análisis comercial completo para encontrar la información vital para el negocio y también cómo se puede conseguir lo que se busca.

Modelado de datos: Los datos que son reunidos del modelado empresarial se utiliza para definir los objetos de datos necesarios para el negocio. La relación entre estos objetos de datos se establece y define en detalle en relación con el modelo empresarial usado.

Modelado de procesos: Los resultados  en el modelado de datos se convierten para lograr el flujo de información comercial para lograr algún objetivo comercial específico. El modelo de proceso para cualquier cambio o mejora en los conjuntos de objetos de datos se define en esta etapa del proceso.

Generación de aplicaciones: Se refiere al sistema real que se construye y la codificación que se realiza mediante el uso de herramientas de automatización para convertir los procesos y los modelos de datos en prototipos reales. Pruebas y rotación: el flujo de datos y las interfaces entre todos los componentes deben probarse exhaustivamente con una cobertura de prueba completa. Como la mayoría de los componentes de programación ya han sido probados, reduce el riesgo de problemas significativos que se pueden presentar.

Ventajas: Se cree que disminuye el tiempo de desarrollo ya que todos los prototipos se crean en paralelo. Aumenta la reutilización de los componentes. Se realizan revisiones iniciales rápidas. Fomenta los comentarios de los clientes a medida que el cliente obtiene visibilidad temprana. La reutilización de los componentes ayuda a acelerar la creación de lo requerido.

Desventajas
Generalmente es dependiente de un equipo sólido y de desempeños individuales para identificar los requisitos del negocio. RAD puede ser útil solo en los productos que se pueden dividir en módulos funcionales. Requiere desarrolladores y/o diseñadores altamente calificados.No se puede usar para proyectos más baratos, ya que el costo del modelado y la generación automática de código pueden resultar significativamente elevados.

Modelo Incremental

Se refiere a un método de desarrollo de software en el que el producto se diseña, implementa y prueba de forma incremental. Poco más se agrega cada vez hasta que el producto esté terminado. Implica tanto desarrollo como mantenimiento. Esto también se conoce como el Modelo o sistema iterativo.

Lo qu se obtiene se descompone en varios componentes, cada uno de los cuales está diseñado y construido por separado. Aquí tienen lugar múltiples ciclos de desarrollo, lo que hace que el ciclo de vida sea un ciclo de «múltiples cascadas». Los ciclos se dividen en módulos más pequeños y más fáciles de administrar. Cada módulo pasa por los requisitos, el diseño, la implementación y las fases de prueba.

La primera parte es a menudo un producto central donde se abordan los requisitos básicos y se agregan características adicionales en los siguientes incrementos. Una vez que el cliente analiza el producto principal, hay un plan de desarrollo para el próximo incremento. Cada versión posterior del módulo agrega función a la versión anterior. El proceso continúa hasta que se logra terminar todo lo que se necesita.

Ventajas:
Se cree que permite la utilización parcial del producto y evita un largo tiempo de desarrollo. Genera software de trabajo de forma rápida y temprana durante el ciclo de vida del software. Este modelo es más flexible y menos costoso para cambiar el alcance y los requisitos.

Es más fácil probar y depurar, ya que se realizan cambios más pequeños durante cada interacción. En este modelo, el cliente puede responder a cada construcción. Como las pruebas se realizan después de cada interacción, los elementos defectuosos del software se pueden identificar rápidamente porque se realizan pocos cambios dentro de una sola oportunidad.

Desventajas
Entre más se agrega funcionalidad adicional al producto en cada etapa, pueden surgir problemas relacionados con la arquitectura del sistema que no era evidente en las etapas anteriores. Necesita buena planificación y diseño en cada paso.

Necesita una definición clara y completa de todo el sistema antes de que se pueda desglosar y construir de forma de incrementar. El costo total es más alto que en otros sistemas parecidos.

Modelos estructurales

Estos sistemas de software muestran la organización de un sistema en términos de los componentes que conforman ese sistema y sus relaciones. Los modelos estructurales pueden ser modelos estáticos, que muestran la estructura del diseño del sistema o modelos dinámicos, que muestran la organización del sistema cuando se está ejecutando. Estas no son las mismas cosas: la organización dinámica de un sistema como un conjunto de hilos interactivos puede ser muy diferente de un modelo estático de los componentes de un todo.

Puede llegar a crear modelos estructurales de un sistema cuando  se debata y diseñe la arquitectura del sistema. El diseño arquitectónico es un tema particularmente importante en la ingeniería de software y los diagramas de implementación, paquete y componentes UML se pueden usar al presentar modelos arquitectónicos. Los detalles más profundos sobre el modelado arquitectónico se tratarán en el próximo capítulo. Aquí nos centramos en la creación de diagramas de clase de nivel de análisis solo que son útiles para una mejor comprensión de la situación.

Los denominados dominios representan los diferentes temas que necesitamos entender para construir un sistema. Un dominio es un mundo autónomo, real, hipotético o abstracto habitado por un conjunto de entidades conceptuales que se comportan de acuerdo con reglas y políticas particulares.

Al generar tales abstracciones llamadas clases, ignoramos la mayoría de las cosas ya que nuestro objetivo es dejar de lado los detalles y concentrarnos solo en los aspectos importantes. Las cosas restantes se agrupan de acuerdo con algunas percepciones sobre lo que significa ser igual a.

Se considera mas adecuado especificar en exceso un modelo de dominio con muchas clases conceptuales detalladas que subespecificarlo. No se piensa que un modelo de dominio es mejor si tiene menos clases conceptuales; todo lo contrario tiende a ser algo verdadero.

A veces se pueden perder elementos conceptuales durante el paso de identificación inicial y descubrirlas más tarde durante la consideración de atributos o asociaciones, o durante el trabajo de diseño. Es por eso que este trabajo debe realizarse en interacciones. Cuando se encuentra una nueva clase conceptual, el modelo de dominio debe aumentarse.

Los principios de diseño de bases de datos relacionales probablemente no sean los mejores para seguir, ya que al modelar el dominio, incluso las clases sin atributos pueden ser importantes para incluir, ya que describen un papel puramente conductual en el dominio en lugar de desempeñar un papel de información.

Una forma común utilizada para la identificación de clase es buscar las frases nominales en la descripción general del proyecto. En nuestro estudio de caso, teníamos sustantivos como cliente, pedido, pago, categoría, libro, DVD, producto, nombre, dirección, etc. Estos sustantivos serán clases y atributos que se utilizaran en potencia.

Para la toma de decisiones de un nombre dado describe una clase o un atributo, podemos aplicar la siguiente directriz: si tiene una identidad en el dominio, entonces es una clase, de lo contrario es un atributo. En este último caso, por supuesto, también necesitamos encontrar su clase. Esa es la razón por la que ejecutamos este proceso en integraciones. Primero, solo nos concentramos en las clases, luego en una nueva interacción asignamos atributos a las clases. La tercera fase debería ser encontrar atributos adicionales que no aparecieron en las etapas previas.

Modelo orientado a objetos

Este proceso constructivo toma los objetos como base. Para esto, primero se observa y analiza el sistema a desarrollar y los requisitos se definen como en cualquier otro método de desarrollo del sistema. Una vez que esto se hace a menudo, se identifican los objetos en el sistema requerido. Por ejemplo, en el caso de un sistema bancario, un cliente es un objeto, una chequera es un objeto e incluso una cuenta es sera considerado un mero objeto.

Este procedimiento enfocado a objetos emplea una estrategia cuyo objetivos principales son: Análisis orientado a objetos, Diseño orientado a objetos, Programación orientada a objetos. El análisis orientado a objetos desarrolla un modelo orientado a objetos del dominio de la aplicación. El diseño orientado a objetos desarrolla un modelo orientado a objetos del sistema de software. La programación orientada a objetos realiza el diseño del software con un lenguaje de programación orientado a objetos que admite la implementación directa de objetos, clases y otros elementos clave.

Proceso unificado

Este sistema se basa en la ampliación y el refinamiento de un sistema a través de múltiples interacciones, con retroalimentación cíclica y adaptación. El sistema se desarrolla de forma incremental a lo largo del tiempo, interacción por interacción y, por lo tanto, este enfoque también se conoce como desarrollo de software iterativo e incremental. Las interacciones se extienden en cuatro fases donde cada fase consta de una o más etapas:

Inicio: La considerada parte más corta del proyecto. Se utiliza para preparar la base para el proyecto, incluida la preparación del caso de negocio, establecer el alcance del proyecto y establecer límites, delinear los requisitos clave y la posible solución de arquitectura junto con las compensaciones de diseño, identificar riesgos y desarrollar el plan inicial del proyecto: cronograma con hitos principales y cálculo de los costes.

Si la parte con la que se comienza dura demasiado, es como un indicador que indica que la visión y los objetivos del proyecto no están claros para los interesados. Sin metas y visión claras, lo más probable es que el proyecto esté condenado al fracaso. En este escenario, es mejor hacer una pausa al comienzo del proyecto para refinar la visión y los objetivos. De lo contrario, podría provocar cambios de imagen innecesarios y retrasos en la programación en fases que se encontraran mas adelante.

Elaboración: En este período se espera que el equipo del proyecto capture la mayoría de los requisitos del sistema (por ejemplo, en forma de casos de uso), realice un análisis de riesgos identificado y elabore un plan de gestión de riesgos para reducir o eliminar su impacto en el cronograma final y producto, para establecer el diseño y la arquitectura (por ejemplo, utilizando diagramas de clase básicos, diagramas de paquetes y diagramas de implementación), para crear un plan (cronograma, estimaciones de costos e hitos alcanzables) para la siguiente fase de este procedimiento.

Construcción: la parte mas dilatada y más grande dentro del Proceso Unificado. Durante esta fase, el diseño del sistema se finaliza y refina y el sistema se construye utilizando la base creada durante la fase de elaboración. La fase de construcción se divide en múltiples iteraciones, para que cada iteración dé como resultado una versión ejecutable del sistema. La iteración final de la fase de construcción libera el sistema completamente completado que se implementará durante la fase final.

Transición: la parte conclusiva del proyecto que entrega el nuevo sistema a sus usuarios finales. La fase de transición incluye también la migración de datos de sistemas heredados y capacitaciones de las personas interesadas.

Cada etapa de este proceso consiste en un conjunto de actividades predefinidas. El Proceso Unificado describe las actividades laborales como disciplinas: una disciplina es un conjunto de actividades y artefactos relacionados en un área temática (por ejemplo, las actividades dentro del análisis de requisitos). Las disciplinas descritas por este método son las siguientes:

Modelado empresarial: Es aquel que se basa en objetos de dominio y modelado dinámico de los procesos empresariales, requiere un análisis de requisitos del sistema bajo consideración. Incluye actividades como escribir casos de uso e identificar requisitos no funcionales. En el Análisis y diseño cubre aspectos del diseño, incluida la arquitectura general, y al momento de implementar requiere programación y creación del sistema.

Seguidamente esta la prueba que implica actividades de prueba como planificación de pruebas, desarrollo de escenarios de prueba, pruebas alfa y beta, pruebas de regresión, pruebas de aceptación y finalmente se implementan las actividades del sistema desarrollado.

Las distintas partes del proceso unificado se dan donde las fases son columnas y las disciplinas son filas. Muestra claramente que el esfuerzo relativo en todas las disciplinas cambia con el tiempo de interacción en interacción, por ejemplo, las interacciones iniciales aplican un mayor esfuerzo relativo en los requisitos y el diseño, mientras que el último, más en pruebas y su implementación final.

Producto

Para este tema es un sistema complejo que se compone de muchas partes colaboradoras. No es suficiente simplemente descomponer los requisitos de software y asignarlos a componentes y unidades de software. El IPPD de software debe resolver los desafíos y la complejidad del diseño estableciendo la arquitectura del producto. El desarrollo de la arquitectura funcional aborda el flujo de control de software, el intercambio de datos, el rendimiento, la utilización de recursos y la detección y respuesta a condiciones de partes que no funcionan.

La composición  física aborda la manera en que las unidades y componentes estructurales de software colaboran y se integran para formar el producto de software final. La arquitectura de software representa el diseño del producto de software con información suficiente para permitir que se especifiquen unidades estructurales y comportamientos de componentes. Ya se propusieron familias de productos de software en 1976. Hay conferencias anuales sobre ingeniería sobre lineas que aplican esta metodología.

Entre algunas iniciativas de estandarización que incorporan muchos de los conceptos de modelado presentados ha sido la iniciativa OMG para CVL, el lenguaje de variabilidad común. Desafortunadamente, debido a disputas de patentes, esta estandarización no se pudo completar. Sin embargo, la mayoría de los conceptos ahora son generalmente reconocidos e implementados por las herramientas actuales de ingeniería para este tipo de sistemas alrededor del mundo.

Naturaleza de la ingeniería de software

Para poder entender la naturaleza de la ingeniería de software, es útil comprender la naturaleza de la ingeniería en general. La ingeniería tiene sus raíces en dos actividades humanas importantes: ciencias y artesanías. Las siguientes dos secciones describen la naturaleza de estas actividades. La siguiente sección describe la naturaleza de la ingeniería en términos de sus relaciones conceptuales con las ciencias y la artesanía. La última sección analiza las características de la ingeniería de software que no son comunes a todas las áreas de este campo de estudio.

Ciencias

Se refiere a un cuerpo de conocimiento causal sobre un tema, organizado en teorías. Las teorías proporcionan explicaciones de las relaciones entre las características de los objetos cubiertos por el tema y el comportamiento de esos objetos.

La comprensión científica comienza con una comprensión de cómo se comportan las cosas. Más tarde, una ciencia se centra más en por qué se comportan como lo hacen. En algunas áreas de la ciencia, esta comprensión se puede utilizar para predecir el comportamiento, lo que lleva a un valor utilitario para la ciencia. Sin embargo, una ciencia bien desarrollada tiene un núcleo que se preocupa por comprender automáticamente.

El cerebro de un individuo no maneja bien una gran colección de hechos. Para satisfacer las necesidades humanas, los hechos deben organizarse en teorías, con una sola teoría que abarque y explique una gran cantidad de hechos. A menudo, una buena explicación requiere nuevos conceptos. Aunque nuestra percepción es la fuente principal de conocimiento, los conceptos perceptivos primitivos pueden ser solo indicaciones indirectas de factores que causan cambios. Los nuevos conceptos identifican esos elementos esenciales.

Generalmente las ciencias intentan cuantificar los conceptos relevantes si es práctico. En algunas ciencias bien desarrolladas, como la física y la química, la cuantificación juega un papel central, lo que resulta en una teoría matemática en el corazón de la ciencia. En algunas áreas de la ciencia, como la teoría de la evolución en biología, la medición no siempre es práctica y la teoría matemática adecuadamente presentada.

Otras áreas

En ciertas situaciones, un emprendimiento también se preocupa por el mantenimiento de los productos. Como una ciencia, un oficio implica un cuerpo de conocimiento. En parte, el conocimiento se refiere al comportamiento de los productos y sus partes básicas. Además, un oficio requiere el desarrollo de herramientas y técnicas involucradas en la producción. Esto implica un segundo tipo de conocimiento. Este es el «saber hacer» de un oficio: habilidades involucradas en el uso de las herramientas y diversas tecnologías.

En la parte ultima, un producto se produce por su valor. El valor de un producto puede ser estético, se valora como un fin en sí mismo o puede ser utilitario, es un medio para otro fin. En cualquier caso, practicar un oficio requiere un conocimiento de valores y medios para lograrlos. Sin embargo, el conocimiento por sí solo no garantiza el logro del valor. Se necesita práctica para desarrollar hábitos en el uso de las herramientas y técnicas. Estos hábitos automatizan parcialmente el logro de valor, liberando la mente para lidiar con problemas más complejos que puedan aparecer en el camino.

La identificación de los valores junto con los hábitos practicados conforman la ética de trabajo de un oficio. Como en la ciencia, la cuantificación puede ser importante en un oficio. La cuantificación de las propiedades físicas de las materias primas puede ser esencial en la construcción de un producto terminado. Sin embargo, generalmente no se necesita una teoría matemática demasiado compleja.

Así como en la ciencia, practicar un oficio es un esfuerzo creativo, y la creatividad es una cualidad importante que distingue a los profesionales expertos de los profesionales promedio. Se necesita imaginación para juntar las materias primas de nuevas maneras para crear un producto de valor. Se necesita imaginación para usar herramientas y técnicas de nuevas maneras para mejorar el resultado final de lo obtenido.

Ingeniería

Generalmente se considera que las disciplinas de ingeniería surgen de la artesanía a medida que sus bases de conocimiento evolucionan hacia las ciencias. Las razones y el impacto de esta evolución se describen en esta sección.

La presentación no pretende ser históricamente correcta. Es aproximadamente correcto para la ingeniería civil, pero otras disciplinas de ingeniería varían considerablemente del patrón. A pesar de las diferencias históricas, diferentes disciplinas de ingeniería abordan problemas similares y esos problemas tienen un efecto similar en lo que se conseguirá.

Cuando un emprendimiento está produciendo un producto utilitario, entonces existe una demanda de mayor funcionalidad del producto, mayor calidad en el producto y mayores cantidades del producto. Satisfacer estas demandas resulta en una mayor complejidad en el producto, en el proceso de producción, o en ambos. Para hacer frente a las mayores demandas y la mayor complejidad, un proyecto debe cambiar en varias formas trascendentales.

En una fase inicial, en las primeras etapas de desarrollo de un oficio, es fundamental comprender cómo se comportan las cosas; entender por qué es de importancia secundaria. Con productos y procesos de producción más complejos, solo saber cómo se comportan las cosas no es suficiente. También hay una mayor necesidad de comprender las relaciones causales: las respuestas a las preguntas de porque se produce esto.

La acción que corresponde a estas preguntas a menudo tienen un poder predictivo que es esencial para desarrollar nuevas técnicas y metodologías de diseño y producción. Cuando el conocimiento sobre el comportamiento del producto y sus componentes está bien desarrollado, se transforma en algo para estudiar.

En una etapa  posterior,   la producción de productos con mayor funcionalidad o mayor calidad requiere una mayor comprensión de los valores. Esto lleva a una teoría del valor que se ocupa de los factores involucrados en la calidad de un producto, medios para cuantificar los factores, conceptos que identifican las características controlables de un producto que afectan su calidad y principios que centran la atención en cuestiones importantes de diseño de productos relacionados con el valor.

La ética del trabajo se ocupa de cuestiones causales más profundas: causas que afectan el valor. Cuando la ética de trabajo del oficio está bien desarrollada, obtiene relevancia.

Finalmente se considera que  la producción de productos complejos, grandes cantidades de productos y productos más funcionales requieren una gran cantidad de planificación. Cuando el producto es complejo o tiene una mayor funcionalidad, la planificación se centra en el diseño del producto. Cuando se producen grandes cantidades de un producto, la planificación se centra en diseñar un proceso productivo normal.

Generalmente se necesita un esfuerzo significativo para diseñar tanto el producto como su proceso de producción. La magnitud de este esfuerzo puede requerir que las personas involucradas desarrollen habilidades especializadas.Algunos continúan con la producción real, otros están involucrados en el diseño de productos y procesos de producción. Aquellos que participan en el diseño se convierten en parte de una nueva disciplina que requiere un estudio detallado.

Esta creación se basa en las mismas bases de conocimiento que un oficio, pero han madurado en ciencias. Una disciplina de ingeniería también tiene herramientas y técnicas al igual que un oficio. Sin embargo, estas herramientas y técnicas se desarrollan dentro de la disciplina de ingeniería más como ayudas para el diseño que como producción. Como en un oficio, se necesita práctica para desarrollar hábitos en su uso.

La automatización parcial del logro de los valores es aún más importante porque un ingeniero tiene problemas más complejos con los que lidiar. El conocimiento de los valores junto con los hábitos practicados conforman la ética de trabajo que se requiere para trabajar en este campo.

La fabricación de productos complejos agrega otra nueva dimensión a la tarea de un ingeniero. La producción de productos complejos requiere el uso de equipos de ingenieros para hacer el diseño. Cuando se trata con mucha gente, es importante tener un proceso de diseño bien definido. También es importante tener una estructura de gestión para guiar a las personas a través del proceso, identificar los riesgos involucrados y asignar los recursos que son requeridos.

Para manejar todo de manera efectiva, los gerentes deben comprender la disciplina de la ingeniería. Los gerentes de un proceso de diseño son generalmente ingenieros con experiencia sustancial en diseño. Para preparar a los ingenieros para este rol, la administración es una parte importante en la pedagogía.

Ingeniería de software

Gran parte  de la naturaleza de la ingeniería de software está implícita en su clasificación como disciplina de ingeniería. Esta sección discute algunas de sus características y problemas únicos. La singularidad aquí no implica que las características y los problemas no se puedan encontrar en otras disciplinas de ingeniería. Solo significa que no son comunes a todas las disciplinas de ingeniería, o significativamente más importantes en esta área de estudio.

Algunas clases se distinguen por el tipo de producto y / o el tipo de componentes que forman la materia prima para el producto. La ingeniería de software se caracteriza por su producto principal, que es el software: programas que dirigen a una computadora para realizar alguna tarea. En ingeniería de software, existe una ciencia bien desarrollada, informática, que cubre, entre otras cosas, conceptos de lenguajes de programación, algoritmos, estructuras de datos y aspectos importantes de sistemas de hardware y software que se crean.

La mayoría de las áreas temáticas de informática tratan con productos de software. Debido a esto, la frontera entre la informática y la ingeniería de software es difícil de definir. En particular, los valores de la ingeniería de software son un elemento importante de la computación general.

En ciertas áreas de ingeniería donde la producción en grandes cantidades es un objetivo, las cantidades introducen una gran complejidad en el proceso de producción. Reproducir software es relativamente fácil, una vez que ha sido diseñado. Los problemas de ingeniería que surgen también son de una naturaleza muy diferente a los problemas de diseño de software. Son problemas manejados por otras disciplinas de ingeniería. La ingeniería de software se ocupa casi exclusivamente del diseño del producto y no del proceso productivo como tal.

Pese a que existe una categoría clara que describe el producto de la ingeniería de software, la funcionalidad de ese producto es extremadamente amplia. Una indicación de esto es el hecho de que cualquier proceso de ingeniería podría automatizarse para que se convierta, en parte, en un proyecto de ingeniería de software. De manera más general, el software se puede aplicar a la automatización de cualquier tarea humana. Esto tiene algunas consecuencias que se consideran de relevancia.

En primera instancia no existe un dominio único de conocimiento que cubra el comportamiento de todos los productos de software. La ingeniería de software no tiene un solo cuerpo de teoría que nos diga cómo especificar y medir el comportamiento de sus productos. La informática trata con los componentes del software y algunas de las herramientas y técnicas involucradas en su construcción, pero no trata y no puede tratar con todos los tipos de comportamiento exhibidos por el sistema.

En una segunda parte los valores de la ingeniería de software están dirigidos por clientes que tienen una gama ilimitada de necesidades. Una clasificación de la amplia gama de valores es una tarea prácticamente imposible. Incluso donde hay valores comunes, varían considerablemente en importancia. Un valor que no es importante en un producto de software puede ser crucial en otro. Por estas razones, el lado ético y orientado al valor de la ingeniería de software adquiere un desempeño mas destacado.

La gran diversidad de funcionalidades y valores de software puede tratarse de tres maneras. Primero, los ingenieros de software pueden especializarse. Hasta cierto punto, esto ya ha sucedido. Hay algunas empresas de desarrollo de software, por ejemplo, que se especializan en software de negocios y contabilidad. Un modo más común de especialización es el desarrollo interno de los sistemas.

Una organización  que emplea mucho software a menudo tendrá un departamento dedicado al desarrollo de software. Los ingenieros de software que trabajan en ese departamento desarrollarán automáticamente una especialización adaptada a las necesidades del emprendimiento.

No obstante existen numerosas áreas donde la demanda no garantiza una especialización. Una segunda opción es que las personas capacitadas en el área de aplicación desarrollen habilidades de programación. Esta es una opción viable para software relativamente simple. Para un software más complejo, la pérdida en la comprensión de la construcción del software puede ser mayor que la ventaja de estar familiarizado de todos procesos.

Una respuesta mas generalizada al problema es modificar el proceso de desarrollo de software. La idea básica es asignar una cantidad significativa de tiempo temprano en el desarrollo del análisis de dominio. El análisis de dominio implica comunicarse con expertos en el área de aplicación, observando conceptos importantes y sus vínculos con otras áreas.

A lo largo del estudio de dominio, los desarrolladores de software crean un modelo de dominio que se puede convertir fácilmente en software. Otro cambio importante en el proceso consiste en construir el producto en etapas y obtener comentarios del cliente sobre los ejemplos o muestras iniciales.

Mantenimiento

A diferencia de otras disciplinas de ingeniería, en ingeniería de software, el mantenimiento no se ocupa principalmente del deterioro de un producto con el tiempo. En cambio, su objetivo es mejorar el software. Existen tres tipos generales de mantenimiento de software, definidos por los tipos de mejoras.

A continuación algunos enlaces de artículos que podrían interesarle:

Requisitos para trabajar en Google ( vacantes en España)

¿Cómo trabajar en correos de España?