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.
Una buena área de recursos humanos es un componente esencial, si no crítico, de cualquier negocio, independientemente del tamaño de la organización. Se enfoca en maximizar la productividad de los empleados y proteger a la empresa de cualquier problema que pueda surgir de la fuerza laboral. Las responsabilidades de RRHH. Incluyen compensación y beneficios, reclutamiento, despido y mantenerse al día con cualquier ley que pueda afectar a la organización y quienes dependen de ella.
Los diferentes sectores de recursos humanos realizan estrategias de gestión de recursos humanos. Se trata de un enfoque estratégico e integral para administrar a los empleados y la cultura organizacional y el entorno. Se centra en el reclutamiento, la gestión y la dirección general de las personas que trabajan en una organización. Los recursos humanos también están más involucrados en mejorar la fuerza laboral de la organización al recomendar procesos, enfoques y soluciones comerciales en el área administrativa.
Notación para el modelado de procesos de negocios
La llamada notación de modelado de procesos comerciales (por sus siglas internacionales conocido como BPMN) es un método de diagrama de flujo que modela los pasos de un proceso comercial planificado de principio a fin. Una clave para la Gestión de Procesos de Negocio, representa visualmente una secuencia detallada de actividades de negocios y flujos de información necesarios para completar un proceso cualquiera dentro de una empresa.
Tiene como fin último modelar formas de mejorar la eficiencia, dar cuenta de nuevas circunstancias u obtener una ventaja competitiva. El método ha experimentado un impulso de estandarización en los últimos años y ahora a menudo se lo llama con un nombre ligeramente diferente: Modelo de proceso de negocio y notación, todavía usando el acrónimo BPMN. Se diferencia del lenguaje de modelado unificado (LUM) utilizado en el diseño de software previamente.
Esta área fue desarrollada por la Iniciativa de gestión de procesos empresariales (BPMI) y ha pasado por una serie de revisiones. En 2005, ese grupo se fusionó con el llamado Object Management Group (OMG), que se hizo cargo de la iniciativa. En 2011, OMG lanzó BPMN en su segunda versión y cambió el nombre del método a su nombre actual. Creó un estándar más detallado para el modelado de procesos de negocios, utilizando un conjunto más rico de símbolos y notaciones para diagramas de procesos de negocios.
A partir de 2014, BPMN también se ha complementado con un método de diagrama de flujo de decisión llamado Modelo de decisión y estándar de notación, ya que BPMN no se presta naturalmente a los flujos de todas las decisiones empresariales.
En la parte mas alta de la estructura, BPMN está dirigido a los participantes y otras partes interesadas en un proceso comercial para obtener comprensión a través de una representación visual fácil de entender de los pasos. En un nivel más complicado, está dirigido a las personas que implementarán el proceso, brindando detalles suficientes para permitir una implementación correcta.
Otorga un lenguaje estándar y común para todas las partes interesadas, ya sean técnicas o no técnicas: analistas de negocios, participantes en procesos, gerentes y desarrolladores técnicos, así como equipos y consultores externos. Idealmente, cierra la brecha entre la intención del proceso y la implementación al proporcionar suficiente detalle y claridad en la secuencia de actividades empresariales o con fines de lucro.
La forma de crear los diagramas puede ser mucho más fácil de entender de lo que sería el texto narrativo. Permite una comunicación y colaboración más fáciles para alcanzar el objetivo de un proceso eficiente que produzca un resultado de alta calidad. También ayuda con la comunicación que conduce a documentos XML (Lenguaje de marcado extensible) necesarios para ejecutar varios procesos. Un estándar XML principal se llama BPEL o BEPEL4WS, que significa Business Process Execution Language utilizado este último para servicios en internet.
Este tipo de modelado puede variar desde diagramas simples y dibujados a mano hasta diagramas más involucrados con elementos expandibles para proporcionar detalles de implementación suficientes. En su forma más sofisticada, BPMN es conducido por analistas acreditados. El Object Management Group (OMG) proporciona cinco certificaciones en BPMN 2.0 llamado, que significa OMG-Certified Expert en BPM 2.0.
Una parte de este campo está orientada a los negocios, y la otra es técnica. OMG tiene la intención de que BPMN 2.0 estandarice el modelado de procesos comerciales de la misma manera que el modelado de software estandarizado Unified Modeling Language (o por sus siglas internacionales UML).
El llamado BPMN requiere un compromiso de tiempo y energía, pero la recompensa en comprensión y mejora puede ser enorme. La versión 2.0 se basa en versiones anteriores al proporcionar un conjunto estándar más rico de símbolos y anotaciones, lo que permite más detalles para aquellos que lo requieren con urgencia.
La iniciativa detrás de Business Process Management es crear un ciclo de vida de mejora continua. Los pasos son modelar, implementar, ejecutar, monitorear y optimizar. Los diagramas BPMN juegan un papel muy importante en eso.
Diagramas de Flujo de Datos
Algunas veces llamados DFD, los diagramas de flujo de datos se utilizan para representar gráficamente el flujo de datos en un sistema de información empresarial. DFD describe los procesos que están involucrados en un sistema para transferir datos desde la entrada al almacenamiento de archivos y la generación de reportes comunes.
Estos se pueden dividir en lógicos y físicos. El diagrama de flujo de datos lógicos describe el flujo de datos a través de un sistema para realizar ciertas funciones de una empresa. El diagrama de flujo de datos físicos describe la implementación del flujo de datos que es considerado más lógico.
El llamado DFD representa gráficamente las funciones o procesos que capturan, manipulan, almacenan y distribuyen datos entre un sistema y su entorno y entre los componentes de un sistema. La representación visual lo convierte en una buena herramienta de comunicación entre el usuario y el diseñador del sistema. La estructura de DFD permite comenzar desde una visión general amplia y expandirla a una jerarquía de diagramas detallados.
El conocido como DFD a menudo se ha utilizado debido a el Flujo lógico de información del sistema, la determinación de los requisitos de construcción del sistema físico, la simplicidad de notación y el establecimiento de requisitos de sistemas manuales y aquellos automatizados o no manuales.
Estos gráficos se clasifican como lógicos o físicos. Un diagrama de flujo de datos lógico se enfoca en el negocio y cómo opera el negocio. No le preocupa cómo se construirá el sistema. Podemos ignorar los detalles específicos de la implementación, como la configuración de la computadora, la tecnología de almacenamiento de datos, los métodos de comunicación o de paso de mensajes al enfocarnos en las funciones realizadas por el sistema, como la recopilación de datos, la transformación de datos a información y la información en si misma.
Este modelo muestra cómo se implementará el sistema, incluido el hardware, el software, los archivos y las personas en el sistema. Se desarrolla de tal manera que los procesos descritos en los diagramas de flujo de datos lógicos se implementan correctamente para lograr el objetivo empresarial.
Beneficios del diagrama de flujo de datos lógico
Cuando se representa un diagrama lógico de la información comercial actual y se centra en las actividades comerciales, que lo convierte en una herramienta de comunicación ideal cuando se usa para comunicarse con los usuarios de un emprendimiento. El DFD lógico se basa en eventos comerciales e independiente de la tecnología particular o la disposición física, lo que hace que el sistema resultante sea mas eficaz.
El DFD de este tipo permite al analista comprender el negocio que se está estudiando e identificar la razón detrás de los planes de implementación. Los sistemas implementados basados en DFD lógico serán más fáciles de mantener porque las funciones comerciales no están sujetas a cambios frecuentes.Muy a menudo, el DFD lógico no contiene almacenes de datos que no sean archivos o una base de datos, lo que lo hace menos complejo que el DFD físico y es más fácil de desarrollar. El DFD físico se puede formar fácilmente modificando un DFD de otro tipo.
Beneficios del diagrama de flujo de datos físicos
Este permite Aclarar qué procesos son manuales y cuáles son automáticos, los procesos manuales requieren documentación detallada y los procesos automatizados requieren el desarrollo de programas informáticos, Describir los procesos con más detalle que los DFD lógicos, ya que describe todos los pasos para el procesamiento de datos o informaciones.
Mejoras en el procesos de secuenciar que deben realizarse en un orden particular, se describe la secuencia de actividades que conducen a un resultado significativo. Por ejemplo, la actualización debe realizarse antes de producir un informe resumido. Identificación del almacenamiento temporal de datos: se describe el almacenamiento temporal, como un archivo de transacción de venta para un recibo (informe) del cliente en una tienda cualquiera.
Permite la Especificación de nombres reales de archivos e impresiones: los diagramas de flujo de datos lógicos describen nombres e informes de archivos reales, de modo que los programadores puedan relacionarlos con el diccionario de datos durante la fase de desarrollo del proceso.
Adicionalmente permite Agregar controles para garantizar que los procesos se realicen correctamente: Estas son condiciones o validaciones de datos que deben cumplirse durante la entrada, actualización, eliminación y otro procesamiento de archivos.
Herramienta Case
Las llamadas herramientas CASE son un conjunto de programas de aplicación de software, que se utilizan para automatizar las actividades SDLC. Los administradores de proyectos de software, analistas e ingenieros utilizan herramientas CASE para desarrollar un sistema de software cualquiera.
Existen en el mercado diversas herramientas CASE disponibles para simplificar varias etapas del ciclo de vida del desarrollo de software, como herramientas de análisis, herramientas de diseño, herramientas de gestión de proyectos, herramientas de gestión de bases de datos, herramientas de documentación, por nombrar algunas. El uso de herramientas CASE acelera el desarrollo del proyecto para producir el resultado deseado y ayuda a descubrir fallas antes de avanzar con la siguiente etapa en el desarrollo de un sistema de este tipo.
Herramientas de diagrama
Estas instrumentos se utilizan para representar los componentes del sistema, los datos y el flujo de control entre varios componentes de software y la estructura del sistema en forma gráfica. Por ejemplo, la herramienta Flow Chart Maker para crear diagramas de flujo con las ultimas innovaciones.
Herramientas de modelado de procesos
Construir modelos de procesos es un método para crear un modelo de proceso de software, que se utiliza para desarrollar el software. Las herramientas de modelado de procesos ayudan a los gerentes a elegir un modelo de proceso o modificarlo según los requisitos del producto de software. Por ejemplo, el conocido como EPF Composer.
Herramientas de gestión de proyectos
Este tipo de sistema se utiliza para la planificación de proyectos, la estimación de costos y esfuerzos, la programación de proyectos y la planificación de recursos. Los gerentes deben cumplir estrictamente la ejecución del proyecto con cada paso mencionado en la gestión de proyectos de software. Las herramientas de gestión de proyectos ayudan a almacenar y compartir información del proyecto en tiempo real en toda la organización. Por ejemplo, Creative Pro Office, Trac Project, o uno de los más famosos Basecamp.
Herramientas de documentación
La etapa de documentación en un proyecto de software comienza antes del proceso del software, abarca todas las fases del SDLC y después de la finalización del emprendimiento en el que se trabaja.
Los sistemas de documentación generan documentos para usuarios técnicos y usuarios finales. Los usuarios técnicos son en su mayoría profesionales internos del equipo de desarrollo que se refieren al manual del sistema, manual de referencia, manual de capacitación, manuales de instalación, etc. Los documentos del usuario final describen el funcionamiento y procedimientos del sistema, como el manual del usuario. Por ejemplo, Doxygen, DrExplain, todos con documentación fácil de usar.
Herramientas de análisis
Estos medios ayudan a reunir los requisitos, comprueban automáticamente cualquier inconsistencia, inexactitud en los diagramas, redundancias de datos u omisiones erróneas. Por ejemplo, Accept 360, Accompa, Case Complete para análisis de requisitos, o el llamado Visible Analyst para un análisis mas completo.
Herramientas de diseño
Estos sistemas ayudan a los diseñadores de software a diseñar la estructura de bloques del software, que puede desglosarse en módulos más pequeños utilizando técnicas de refinamiento. Estas herramientas proporcionan detalles de cada módulo e interconexiones entre módulos. Por ejemplo, en un software animado en la etapa de creación.
Herramientas de gestión de configuración
Se procede como una instancia de software en una versión. Las herramientas de gestión de configuración se ocupan de Gestión de versiones y revisiones., Gestión de configuración de línea de base, Gestión de control de cambios Las herramientas CASE ayudan en esto mediante el seguimiento automático, la gestión de versiones y la gestión de versiones. Por ejemplo, Fossil, Git, entre muchos otros
Cambiar herramientas de control
Estos sistemas se consideran parte de las herramientas de administración de configuración. Se ocupan de los cambios realizados en el software después de que se fija su línea de base o cuando se lanza el software por primera vez. Las herramientas CASE automatizan el seguimiento de cambios, la administración de archivos, la administración de códigos y más. También ayuda a hacer cumplir la política de cambio de una empresa.
Herramientas de programación
Estas trabajan en entornos de programación como IDE (Integrated Development Environment), biblioteca de módulos incorporados y herramientas de simulación. Estas herramientas proporcionan una ayuda integral en la creación de productos de software e incluyen características para simulación y pruebas. Por ejemplo, Cscope para buscar código en C, entre muchos otros similares.
Herramientas de prototipos
El conocido como prototipo de software es una versión simulada del producto de software previsto. Prototype proporciona una apariencia inicial del producto y simula pocos aspectos del producto final.
Los sistemas de creación de prototipos CASE vienen esencialmente con bibliotecas gráficas. Pueden crear interfaces de usuario y diseño independientes del hardware. Estas herramientas nos ayudan a construir prototipos rápidos basados en la información existente. Además, proporcionan simulación de prototipo de software. Por ejemplo, el compositor prototipo de Serena, Mockup Builder entre otros varios.
Herramientas de desarrollo web
Estos sistemas ayudan a diseñar páginas web con todos los elementos aliados como formularios, texto, guiones, gráficos, etc. Las herramientas web también proporcionan una vista previa en vivo de lo que se está desarrollando y cómo se verá una vez finalizado. Por ejemplo, Fontello, Adobe Edge Inspect, Foundation 3, entre muchos similares.
Herramientas de aseguramiento de calidad
Esta etapa en una organización de software consiste en monitorear el proceso de ingeniería y los métodos adoptados para desarrollar el producto de software a fin de garantizar la conformidad de la calidad según los estándares de la organización. Las herramientas de control de calidad consisten en herramientas de configuración y control de cambios y herramientas de prueba de software. Por ejemplo, SoapTest, AppsWatch, y otros muchos similares.
Herramientas de mantenimiento
El llamado mantenimiento del software incluye modificaciones en el producto de software después de que se entrega. El registro automático y las técnicas de informe de errores, la generación automática de tickets de error y el análisis de causa raíz son pocas herramientas CASE, que ayudan a la organización del software en la fase de mantenimiento de SDLC. Por ejemplo, Bugzilla para el seguimiento de defectos, entre otros parecidos.
Metodología
Los que se consideran proyectos exitosos se gestionan bien. Para administrar un proyecto de manera eficiente, el gerente o el equipo de desarrollo debe elegir la metodología de desarrollo de software que funcione mejor para el proyecto en cuestión. Todas las metodologías tienen diferentes fortalezas y debilidades y existen por diferentes razones. Aquí hay una descripción general de las metodologías de desarrollo de software más utilizadas y por qué existen diversas formas para actuar:
Metodología de desarrollo ágil
Aquí se utiliza la metodología de desarrollo ágil para minimizar el riesgo (como errores, sobre costos y requisitos cambiantes) al agregar nuevas funcionalidades. En todos los métodos ágiles, los equipos desarrollan el software en interacciones que contienen minie incrementos de la nueva funcionalidad. Hay muchas formas diferentes del método de desarrollo ágil, incluyendo scrum, crystal, programación extrema (XP) y desarrollo basado en funciones (o por sus siglas internacionales FDD).
La ventaja mas grande del desarrollo ágil de software es que permite que el software se libere en interacciones. Los lanzamientos iterativos mejoran la eficiencia al permitir que los equipos encuentren y reparen defectos y alineen las expectativas desde el principio. También permiten a los usuarios obtener beneficios de software antes, con frecuentes mejoras que se van incrementando.
Este sistema de desarrollo ágiles dependen de la comunicación en tiempo real, por lo que los nuevos usuarios a menudo carecen de la documentación que necesitan para ponerse al día. Requieren un gran compromiso de tiempo por parte de los usuarios y requieren mucho trabajo porque los desarrolladores deben completar completamente cada característica dentro de cada interacción para la aprobación del beneficiado.
Esta forma de proceder es similares al desarrollo rápido de aplicaciones y pueden ser ineficientes en grandes organizaciones. Los programadores, gerentes y organizaciones acostumbrados al método de cascada pueden tener dificultades para adaptarse a un SDLC ágil. Por lo tanto, un enfoque híbrido a menudo funciona bien para el momento adecuado.
Metodología de implementación de DevOps
Se trata no solo una metodología de desarrollo, sino también un conjunto de prácticas que respaldan una cultura organizacional. La implementación de DevOps se centra en el cambio organizacional que mejora la colaboración entre los departamentos responsables de los diferentes segmentos del ciclo de vida del desarrollo, como el desarrollo, el aseguramiento de la calidad y la gestión de operaciones.
Este sistema se enfoca en mejorar el tiempo de comercialización, reducir la tasa de fallas de los nuevos lanzamientos, acortar el tiempo de espera entre arreglos y minimizar las interrupciones al tiempo que maximiza la confiabilidad.
Para lograr esto, las organizaciones DevOps tienen como objetivo automatizar la implementación continua para garantizar que todo suceda de manera fluida y confiable. Las empresas que utilizan los métodos DevOps se benefician al reducir significativamente el tiempo de comercialización y mejorar la satisfacción del cliente, la calidad del producto y la productividad y eficiencia de los miembros de la organización
A pesar de sus beneficios, DevOps tiene algunos inconvenientes: algunos clientes no desean actualizaciones continuas de sus sistemas, algunas industrias tienen regulaciones que requieren pruebas exhaustivas antes de que un proyecto pueda pasar a la fase de operaciones. Si diferentes departamentos usan diferentes entornos, los problemas no detectados pueden pasar al área de manufactura. Ciertos atributos de calidad requieren interacción humana, lo que ralentiza el proceso de distribución.
Método de desarrollo de la cascada
Algunas fuentes consideran que el método de cascada es el método de desarrollo de software más tradicional. El método de cascada es un modelo lineal rígido que consta de fases secuenciales (requisitos, diseño, implementación, verificación, mantenimiento) que se centran en objetivos distintos. Cada fase debe estar 100% completa antes de que pueda comenzar la siguiente fase. Por lo general, no hay ningún proceso para volver a modificar el proyecto a su estado originaol.
Se cree que la naturaleza lineal del método de desarrollo en cascada hace que sea fácil de entender y administrar. Los proyectos con objetivos claros y requisitos estables pueden utilizar mejor el método de cascada. Los gerentes de proyecto y los equipos de proyecto menos experimentados, así como los equipos cuya composición cambia con frecuencia, pueden beneficiarse más del uso de la metodología de desarrollo de este tipo.
Este sistema de desarrollo en cascada a menudo es lento y costoso debido a su estructura rígida y controles estrictos. Estos inconvenientes pueden llevar a los usuarios del método en cascada a explorar otras metodologías diferentes mas convenientes.
Desarrollo rápido de aplicaciones
El llamado desarrollo rápido de aplicaciones (o RAD por sus siglas internacionales) es un proceso de desarrollo condensado que produce un sistema de alta calidad con bajos costos de inversión. Este proceso RAD permite a los desarrolladores adaptarse rápidamente a los requisitos cambiantes en un mercado acelerado y en constante cambio. La capacidad de ajustar rápidamente es lo que permite un costo de inversión que es relativamente menor.
Este procedimiento de desarrollo rápido de aplicaciones contiene cuatro fases: planificación de requisitos, diseño del usuario, construcción y corte. Las fases de diseño y construcción del usuario se repiten hasta que el usuario confirma que el producto cumple con todos los requerimientos mínimos.
Este sistema de aplicaciones es más efectivo para proyectos con un objetivo comercial bien definido y un grupo de usuarios claramente definido, pero que no son computacionalmente complejos. RAD es especialmente útil para proyectos pequeños a medianos que son sensibles a variaciones temporales.
Este procedimiento requiere una composición de equipo estable con desarrolladores y usuarios altamente calificados que tengan un profundo conocimiento del área de la aplicación. El conocimiento profundo es esencial en un crono-grama de desarrollo condensado que requiere aprobación después de cada fase de construcción. Es poco probable que las organizaciones que no cumplan con estos requisitos se beneficien de un sistema con estas características.
Las 4 metodologías de desarrollo de software son las más dominantes en el desarrollo de software. Cada uno tiene sus propias fortalezas y debilidades y trabaja de manera efectiva en diferentes situaciones. Al elegir su metodología de desarrollo, piense en combinar los elementos de cada método que funcionen mejor para su equipo y su proyecto actual. De esta forma, puede crear una metodología de desarrollo híbrido que lo llevará a la producción de forma eficaz y rápida.
Modelos de Desarrollo de Software
Para los diferentes ciclos de vida de un software se han establecido algunos modelos comunes entre los que encontramos:
Modelo Clásico
El llamado modelo Clásico o de cascada fue el primer modelo de proceso que se introdujo. Es muy simple de entender y usar. En un modelo de Cascada, cada fase debe completarse antes de que pueda comenzar la siguiente fase y no haya superposición en las fases. El modelo en cascada es el primer enfoque SDLC que se utilizó para el desarrollo de estos procesos.
En este enfoque todo el proceso de desarrollo de software se divide en fases separadas. El resultado de una fase actúa como entrada para la siguiente fase secuencialmente. Esto significa que cualquier fase del proceso de desarrollo comienza solo si se completa la fase anterior. El modelo de cascada es un proceso de diseño secuencial en el que se ve que el progreso fluye constantemente hacia abajo (como una cascada) a través de las fases de Concepción, Iniciación, Análisis, Diseño, Construcción, Prueba, Producción / Implementación y finalmente el Mantenimiento.
Debido a que este modelo ilustra el proceso de desarrollo de software en un flujo secuencial lineal; por lo tanto, también se conoce como un modelo de ciclo de vida esencialmente lineal en su forma.
Modelo de Prototipo
Se define como una muestra, modelo o lanzamiento temprano de un producto creado para probar un concepto o proceso. Es un término utilizado en una variedad de contextos, incluida la semántica, el diseño, la electrónica y la programación de software. Un prototipo está diseñado para probar y probar un nuevo diseño para mejorar la precisión por parte de los analistas y usuarios del sistema. La creación de prototipos sirve para proporcionar especificaciones para un sistema real y de trabajo en lugar de uno mas conceptual.
El fundamento básico aquí es que, en lugar de congelar los requisitos antes de que un diseño o codificación pueda continuar, se construye un prototipo desechable para comprender los requisitos. Este prototipo se desarrolla en base a los requisitos actualmente conocidos. Al usar este prototipo, el cliente puede obtener un modelo o muestra del producto. Las interacciones con el prototipo pueden permitir al cliente comprender mejor los requisitos del sistema deseado.
La elaboración de prototipos es una idea atractiva para sistemas complicados y grandes para los que no existe un proceso manual o un sistema existente para ayudar a determinar los requisitos. El prototipo generalmente no es un sistema completo y muchos de los detalles no están integrados en el prototipo. El objetivo es proporcionar un sistema con funciones amplias.
Algunas veces resulta útil demostrar el concepto a los posibles inversores para obtener fondos para el proyecto. Reduce el riesgo de falla, ya que los riesgos potenciales se pueden identificar temprano y se pueden tomar medidas correctivas.
La iteración entre el equipo de desarrollo y el cliente proporciona un entorno muy bueno y conductivo durante el proyecto. Dado que en este método se proporciona un modelo de trabajo del sistema, los usuarios obtienen una mejor comprensión del sistema que se está desarrollando y pueden sugerir cambios y alteraciones de importancia.
Los requerimientos de los usuarios están disponibles en una etapa temprana que conduce a una mejor solución.Si se requieren demasiados cambios en el producto de muestra o modelo, puede alterar el ritmo del equipo de desarrollo.Esta metodología puede aumentar la complejidad del sistema ya que el alcance del sistema puede expandirse más allá de los planes originales.
La creación de prototipos generalmente se realiza a costa del desarrollador. Por lo tanto, debe hacerse con recursos mínimos. A veces, el costo inicial de construir el equipo de desarrollo, enfocado en hacer prototipos, pudiera resultar elevado.
Modelo en Espiral
Se define como una combinación del modelo de desarrollo iterativo y el modelo de cascada con un énfasis muy alto en el análisis de riesgos. Permite lanzamientos incrementales del producto, o refinamiento incrementa a través de cada interacción alrededor de este sistema.
Este proceso se utiliza mejor para proyectos grandes que implica mejoras continuas. Hay actividades específicas que se realizan en una interacción (espiral) donde la salida es un pequeño prototipo del software grande. Las mismas actividades se repiten para todas las espirales hasta que se construye todo lo necesario.
Fases del modelo espiral
Este sistema en espiral tiene cuatro fases. Un proyecto de software pasa repetidamente por estas fases en interacciones conocidas comúnmente como espirales.
Planificación: los requerimientos identificados se estudian y se reúnen en esta fase. Incluye estimar el costo, el cronograma y los recursos para las espirales. A medida que el producto madura, la identificación de los requisitos del sistema y los requisitos de la unidad se realizan en esta parte del proceso.
Análisis de riesgos: Esta etapa abarca la identificación, la estimación y el seguimiento de la viabilidad técnica y los riesgos de gestión, como el retraso del cronograma y el sobrecosto. Una vez que se identifican los riesgos, la estrategia de mitigación de riesgos se planifica y concreta definitivamente.
Ingeniería: esta etapa incluye la producción del producto de software real en cada espiral. El desarrollo y las pruebas reales del software tienen lugar en esta fase. Incluye pruebas, codificación e implementación de software en el sitio del cliente. Un POC (Prueba de concepto) se desarrolla en esta fase para obtener recomendaciones de los interesados.
Evaluación: finalmente después de probar la compilación, en la primera fase, el cliente evalúa el producto y proporciona sus recomendaciones ultimas.
Ventajas:
El cálculo de los costos se vuelve fácil a medida que la construcción del prototipo se realiza en segmentos pequeños. El desarrollo se puede dividir en partes más pequeñas y las partes más riesgosas se pueden desarrollar antes, lo que ayuda a una mejor gestión de riesgos. El desarrollo es rápido y las características se agregan de manera sistemática. Siempre hay espacio para comentarios de los clientes y los cambios se implementan con mayor rapidez.
Desventajas
Se cree que este sistema actúa mejor solo para proyectos grandes y podría ser costoso para proyectos pequeños. El análisis de riesgos es una fase importante, por lo que requiere personas expertas para la evaluación de riesgos. La documentación es más, ya que tiene una gran cantidad de fases intermedias para su protocolo de modelo espiral de operación sin problemas que debe seguirse rigurosamente.
Se recomienda seguir el modelo en espiral siempre en los siguientes casos: para proyectos medianos y grandes. Para proyectos de alto riesgo. Los usuarios no están seguros de sus necesidades. Los requisitos son complejos. Si los requisitos son más complicados. Si se requieren cambios frecuentes en el emprendimiento de lo planificado.
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: