# data[].attributes.body
Se define la ingeniería de software como el establecimiento y el uso de principios fundamentales de la ingeniería que tienen como finalidad el desarrollo en forma económica, a través de un software que sea confiable y que funcione de forma eficiente en máquinas reales.

También existe otra definición empleada por Blum en el año 1966, y define a la ingeniería de la siguiente manera: "la aplicación de las herramientas, métodos y disciplinas para la producción y el mantenimiento da soluciones automáticas a problemas del mundo real"

# data[].attributes.body
El alcance del sistema incluye para los diferentes módulos, las siguientes funcionalidades:

Alta de cargas de forma manual.

Seguimiento de cargas en tránsito.

Informes básicos de soportes a la administración.

De la misma manera, aparece el alcance de:

Administración de Clientes.

Administración automática de cargas (contenedores por tipo, itinerarios según criterios y organización de volúmenes).

Facturación de servicios.

Integración con transporte de terceros.

Informes complejos.

# data[].attributes.body
1.- ¿El software Powrtrak concede a Black & Veatch una ventaja competitiva estratégica? ¿Por qué sí o por qué no?
El software Powrtrak concede a Black & Veatch una ventaja competitiva estratégica, ya que permite distribuir los tiempos de trabajo con mayor precisión, como así también la observación de distintos componentes de un proyecto, lo que permite lograr una mayor verificación del trabajo realizado. Además, esta base de datos permite una alta precisión en distintas áreas como así también el control de costos.

2.- ¿Es posible que compañías de mayor tamaño, como RayTheon y Bechtel, dispongan de instrumentos similares pero no extraigan de ellos servicios tan valiosos como los que consigue Black & Veatch? ¿A qué podría deberse esto?
Si, es posible que dispongan de instrumentos similares, ya que son grandes compañías con grandes recursos que desarrollan habilidades de gran importancia. Pero a diferencia de Black & Veatch, este se enfoca en desarrollar servicios que permitan una mejor comunicación con una consultoría de ingeniería más pequeña, comparado con grandes compañías como Raytheon y Bechtel que tienen sistemas de gran tamaño y mayor cantidad de herramientas.

Fuente: Adaptado de la página web de Black & Veatch, en www.bv.com, visitada el 18 de abril de 1998: The Art of Innovation, en InformationWeek, 1º de diciembre de 1997, pp. 36-64.

# data[].attributes.body
1.- ¿Qué cree que signifique el comentario de Karten de que “de los que muchas organizaciones no se dan cuenta es de que si no controlan el aspecto administrativo de un cambio tecnológico, se exponen a fracasar aún si tienen éxito en el aspecto tecnológico”? ¿Cómo se aplica este juicio al caso de Liz Claiborne?
Según el comentario de Karten, tanto las áreas administrativas como tecnológicas son importantes, como es importante el motivo del uso tecnológico, que incluye:

La capacitación de cada uno de sus empleados.

El asesoramiento a los clientes utilizando nuevas herramientas tecnológicas que permitan la adaptación al sistema.

El caso de Liz Claiborne al nuevo sistema es de lograr una nueva adaptación en el aspecto tecnológico, y que también sus tiendas sean online, a través de la página web ahorrando tiempo y dinero a nivel mundial. También tenemos que tener en cuenta que el cliente ya no tiene la misma fidelidad a la marca, sino que se adaptan a estos nuevos tiempos.

2.- Liz Claiborne ha hecho una importante inversión en actualizar sus sistemas de información. Si Usted tuviera que justificar esa inversión frente al consejo de administración de la compañía, ¿Qué diría?
En el caso que tuviera que justificar dicha inversión, diría que en la actualidad estamos incorporando nuevos cambios a la situación actual para lograr un mayor crecimiento y reducir los costos. Asimismo, se puede aprovechar una interconexión con la actualización de los sistemas de información, y para ello es necesario enfocarse en la infraestructura de la compañía.

Fuente: Adaptado de Jaikumar Vijayan, IT Overhaul My Boost Fashion Profit”, en Computerworld, 13 de abril de 1998, pp. 55-56; Tom Stein, “Going Global”, en Information Week, 2 de febrero de 1998, pp. 84.85 y página Web de Liz Claiborne: www.lizclaiborne.com, consultada el 15 de abril de 1998.

# data[].attributes.body
Análisis comparativo de cada una de las metodologías (Word)

# data[].attributes.attachment_link.title
METODOLOGIAS DE DESARROLLO DE SOFTWARE - ENZO PASTRANA

# data[].attributes.headline
Clasificación de la Ingeniería de Software

# data[].attributes.subject
Clasificación de la Ingeniería de Software

# data[].attributes.body
Las metodologías de desarrollo de software hacen referencia a una forma de trabajo para estructurar, planear y controlar el proceso de desarrollo en sistemas de información. A continuación nombramos las siguientes 7 metodologías:

# data[].attributes.body
Es un proceso secuencial de fácil desarrollo, en el que los pasos de desarrollo son vistos de forma descendente (como en una cascada) a través de las fases de análisis de las necesidades, el diseño, implementación, pruebas, la integración y el mantenimiento.

Los principios básicos del modelo en cascada son:
a- El proyecto está dividido en fases secuenciales, con cierta suposición y splashback aceptable entre fases.
b- Se hace hincapié en la planificación, los horarios, fechas, presupuesto y ejecución de todo un sistema de una sola vez.
c- Un estricto control se mantiene durante la vida de un proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff hechas por el usuario y la gestión de área TI al final de la mayoría de las fases y antes de comenzar la fase

# data[].attributes.body
El modelo de prototipos pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo usando los programas adecuados y no se deben utilizar muchos recursos.

Las etapas del modelo de prototipos son:

Comunicación

Plan rápido

Modelado, diseño rápido

Construcción del prototipo

Desarrollo, entrega y retroalimentación

Entrega del desarrollo final

# data[].attributes.body
Es un proceso de desarrollo de software creado en respuesta a las habilidades del modelo tradicional de cascada.

Este modelo se basa en dos premisas:

Los usuarios nunca saben bien qué es lo que necesitan para satisfacer sus necesidades.

En el desarrollo, los procesos tienen que cambiar.

El proceso consiste en:

Etapa de inicialización

Etapa de iteración

Lista de control de proyecto

# data[].attributes.body
Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizando generalmente en la ingeniería de Software.

En cada iteración se tiene en cuenta:

Los objetivos: qué necesidad de cubrir el producto.

Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:

Características: experiencia del personal, requisitos a cumplir, etc.

Formas de gestión del sistema.

Desarrollar y verificar: Programar y probar el software.

En el caso de que el resultado no sea el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificarán los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola, y mantiene dos dimensiones: la radial y la angular.

Angular: Indica el avance del proyecto del software dentro de un ciclo.

Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.

# data[].attributes.body
Es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos. Es desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software e introducido por James Martin en 1991.

# data[].attributes.body
Su uso nos induce a desarrolladores y programadores pensar en términos de objetos, y no en procedimientos, cuando planifican el código.
- En esta metodología, un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La "interfaz de objeto" son las formas de interactuar con el objeto, que son definidas en esta etapa.

# data[].attributes.body
Son estrategias de procedimiento de información características de las ciencias de la información, especialmente en lo relativo al software. Por extensión se aplican también a otras ciencias sociales y exactas.

En el modelo top-down se formula un resumen del sistema, sin especificar detalles. Cada parte nueva es entonces redefinida, cada vez con mayor detalle, hasta que la especificación completa es lo suficientemente detallada por validar el modelo.

En el modelo Bottom-Up, las partes individuales se diseñan con detalle y luego se enlazan para formar componentes más grandes, que a su vez se enlazan hasta que se forma el sistema completo. Las estrategias basadas en el flujo de información "bottom-up", se basan en el conocimiento de todas las variables que pueden afectar los elementos del sistema.

# data[].attributes.headline
Herramientas de la Ingeniería de Software

# data[].attributes.subject
Herramientas de la Ingeniería de Software

# data[].attributes.body
Las herramientas de la Ingeniería de Software proporcionan un apoyo automatizado o semiautomatizado para el proceso y los métodos. Cuando se integran las herramientas de modo que la información creada por una pueda ser utilizada por otra, queda establecido un sistema llamado Ingeniería de Software asistido por computadora que apoya el desarrollo de software.

En la evolución del software no es la excepción; en este caso los instrumentos se han llamado CASE (Ingeniería de Software Asistido por computadora).

CASE: es la adaptación de procesos y tecnología que dan rendimiento a los programas, a través de otros, procesos y su correspondiente documentación.

IRQA: es la que posibilita y determina la relación entre el cliente, el distribuidor y los diferentes miembros del equipo que está desarrollando el proyecto.

También facilita la adquisición, constitución y estudio de las condiciones, así como la determinación de la solución al apoyo metodológico adaptada al cliente.

CONTROLA: Es una herramienta de soporte de proceso de ingeniería de software en pequeñas empresas. Fue creada debido al desarrollo del mercado y a la creación de grandes y pequeñas empresas, que requerían una herramienta para la evolución de sus proyectos.

OSRMT: En la práctica, los principios determinan los valores y reglamento que servirán para el momento de investigar o estudiar un problema; luego se buscará y diseñará la solución, se reparará, se probará y al estar listo, se distribuirá entre la comunidad de usuarios.

# data[].attributes.headline
Breve Historia de la Ingeniería de Software

# data[].attributes.subject
Breve Historia de la Ingeniería de Software

# data[].attributes.body
1940- Se producen los primeros fundamentos de la computación moderna, en 1960 es la década que se identifica con la década del origen de la ingeniería de software, ya que se desarrollaron softwares de aplicaciones relativamente globales.
Además en esos años existían pocos conocimientos sobre cómo desarrollar grandes proyectos de software, ya que se centraba en el software y la poca fiabilidad del hardware y del software dominaba sobre el proceso del diseño.

# data[].attributes.body
La tecnología podía soportar grandes desarrollos, pero la dificultad surgía en organizar y coordinar las actividades de programación de estos proyectos lo que produjo la denominada "crisis del software".

# data[].attributes.body
El Comité Científico de la OTAN patrocinó una conferencia en Alemania, cuyo fin fue identificar, clasificar y discutir los problemas que se producían en el desarrollo de grandes proyectos. El resultado de la misma fue constatar que el desarrollo de software es una tarea de ingeniería (que no es muy diferente de otros tipos de ingeniería), cuyo fin era la producción industrial de programas eficientes, fiables y robustos, elaborados con el mínimo coste y tiempos posibles.

# data[].attributes.body
Se impuso un enfoque de desarrollo de software, incorporado por Winston Royce, a través de un "ciclo de vida en cascada". Este método modela el ciclo convencional de la ingeniería de software, aplicando un enfoque sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.

# data[].attributes.body
Son diversas las aplicaciones informáticas destinadas a aumentar la productividad en el Desarrollo de Software reduciendo el coste de estas en término de tiempo y dinero. La primera plataforma fue Excelator que se trabaja en una pc.

# data[].attributes.body
Se popularizó el uso de la programación orientada a objetos a principios de la década de 1990 y el desarrollo en JAVA.

# data[].attributes.body
Google y Youtube toman gran importancia, se crea Facebook, Windows 8 se lanza en 2012, Windows 10 se lanza en 2015, mientras que JAVA es el lenguaje más utilizado en 2018.

# data[].attributes.body
A continuación enumeramos que no es Ingeniería de Software.

1. Arquitectura de Software

2. Desarrollo de Software

3. Ingeniería de computación o Ingeniería informática

# data[].attributes.body
1) https://books.google.com.ar/books?id=rXU-WS4UatYC&printsec=frontcover&dq=ingenier%C3%ADa+del+software&hl=es&sa=X&ved=0ahUKEwiwoMW53MzoAhVuIbkGHRG9B0gQ6AEITjAF#v=onepage&q=ingenier%C3%ADa%20del%20software&f=false

# data[].attributes.attachment_link.title
Introducción a la Ingeniería del software

# data[].attributes.body
2) https://prezi.com/p/z5dz8r1suc0k/historia-de-la-ingenieria-de-software/

# data[].attributes.attachment_link.description
Historia de la Ingeniería de Software. FORTRAN Lenguaje de programación utilizado principalmente en matemáticas y en aplicaciones de cálculo científico. Fue el primer lenguaje de programación de alto nivel que fue creado. Iniciales: FORmula TRANslating 1970 -Se identifican las

# data[].attributes.body
3) https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

# data[].attributes.attachment_link.readable_text
Ingeniería de software

Campo de aplicación

Desarrollo de software de aplicación,
Desarrollo de software de sistema,
Desarrollo web, Desarrollo de aplicaciones móviles,
Desarrollo de software de gráficos,
Desarrollo de aplicaciones de escritorio,
Desarrollo de bot conversacional,
Desarrollo de cadena de bloques,
Desarrollo de software de física computacional,
Desarrollo de software de química computacional,
Desarrollo de visión artificial,
Desarrollo de software robótico,
Desarrollo de software biomédico,
Desarrollo de software operativo industrial, Desarrollo de software de ingeniería,
Aplicaciones de la inteligencia artificial

Subárea de

Ciencias de la computación

La Ingeniería de Software es una de las ramas de las ciencias de la computación que estudia la creación de software confiable y de calidad, basándose en métodos y técnicas de ingeniería, y brindando soporte operacional y de mantenimiento. El campo de estudio de la ingeniería de software​ integra ciencias de la computación, ciencias aplicadas y las ciencias básicas en las cuales se encuentra apoyada la ingeniería.​

Se citan las definiciones más reconocidas, formuladas por los siguientes prestigiosos autores:

Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978).

Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).

La ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación, y mantenimiento del software. Standard Glossary of Software Engineering Terminology​

En 2004, la U. S. Bureau of Labor Statistics (Oficina de Estadísticas del Trabajo de Estados Unidos) contó 760 840 ingenieros de software de computadora.​[actualizar]

El término "ingeniero de software", sin embargo, se utiliza de manera genérica en el ambiente empresarial, y no todos los que se desempeñan en el puesto de ingeniero de software poseen realmente títulos de ingeniería de universidades reconocidas.​

Algunos autores consideran que "desarrollo de software" es un término más apropiado que "ingeniería de software" para el proceso de crear software. Personas como Pete McBreen (autor de Software Craftmanship) cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos "ingeniería de software" o "ingeniería del software"; aunque menos común también se suele referenciar como "ingeniería en software".​​​ En Hispanoamérica los términos más comúnmente usados son los dos primeros.

La creación del software es un proceso intrínsecamente creativo y la ingeniería del software trata de sistematizar este proceso con el fin de acotar el riesgo de fracaso en la consecución del objetivo, por medio de diversas técnicas que se han demostrado adecuadas sobre la base de la experiencia previa.

La ingeniería de software se puede considerar como la ingeniería aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la aplicación de ellos de la manera más eficiente para la obtención de resultados óptimos; objetivos que siempre busca la ingeniería. No es solo de la resolución de problemas, sino más bien teniendo en cuenta las diferentes soluciones, elegir la más apropiada.

Cuando aparecieron las primeras computadoras digitales en la década de 1940,​ el desarrollo de software era algo tan nuevo que era casi imposible hacer predicciones de las fechas estimadas de finalización del proyecto y muchos de ellos sobrepasaban los presupuestos y tiempo estimados. Los desarrolladores tenían que volver a escribir todos sus programas para correr en máquinas nuevas que salían cada uno o dos años, haciendo obsoletas las ya existentes.

El término ingeniería del software apareció por primera vez a finales de la década de 1950. La ingeniería de software fue estimulada por la crisis del software de las décadas de entre 1960 y 1980. La ingeniería del software viene a ayudar a identificar y corregir mediante principios y metodologías los procesos de desarrollo y mantenimiento de sistemas de software.

Aparte de la crisis del software de las décadas de entre 1960 y 1980, la ingeniería de software se ve afectada por accidentes que conllevaron a la muerte de tres personas; esto sucedió cuando la máquina de radioterapia Therac-25 emite una sobredosis masiva de radiación y afecto contra la vida de estas personas.​ Esto remarca los riesgos de control por software,​ afectando directamente al nombre de la ingeniería de software.

A principios de los 1980,​ la ingeniería del software ya había surgido como una genuina profesión, para estar al lado de las ciencias de la computación y la ingeniería tradicional. Antes de esto, las tareas eran corridas poniendo tarjetas perforadas como entrada en el lector de tarjetas de la máquina y se esperaban los resultados devueltos por la impresora.

Debido a la necesidad de traducir frecuentemente el software viejo para atender las necesidades de las nuevas máquinas, se desarrollaron lenguajes de orden superior. A medida que apareció el software libre, las organizaciones de usuarios comúnmente lo liberaban.

Durante mucho tiempo, solucionar la crisis del software fue de suma importancia para investigadores y empresas que se dedicaban a producir herramientas de software.

Para la década de 1980, el costo de propiedad y mantenimiento del software fue dos veces más caro que el propio desarrollo del software, y durante la década de 1990, el costo de propiedad y mantenimiento aumentó 30 % con respecto a la década anterior. En 1995, muchos de los proyectos de desarrollo estaban operacionales, pero no eran considerados exitosos. El proyecto de software medio sobrepasaba en un 50 % la estimación de tiempo previamente realizada, además, el 75 % de todos los grandes productos de software que eran entregados al cliente tenían fallas tan graves, que no eran usados en lo absoluto o simplemente no cumplían con los requerimientos del cliente.

Algunos expertos argumentaron que la crisis del software era debido a la falta de disciplina de los programadores.

El auge del uso del Internet llevó a un vertiginoso crecimiento en la demanda de sistemas internacionales de despliegue de información en la World Wide Web. Los desarrolladores se vieron en la tarea de manejar ilustraciones, mapas, fotografías y animaciones, a un ritmo nunca antes visto, con casi ningún método para optimizar la visualización y almacenamiento de imágenes. También fueron necesarios sistemas para traducir el flujo de información en múltiples idiomas extranjeros a lenguaje natural humano, con muchos sistemas de software diseñados para uso multilenguaje, basado en traductores humanos.

La ingeniería de software contribuyó alrededor de 90 000 millones de dólares por año, ya que entró en juego el Internet. Esto hace que los desarrolladores tuviesen que manejar imágenes mapas y animaciones para optimizar la visualización/almacenamiento de imágenes (como el uso de imágenes en miniatura). El uso de los navegadores y utilización de lenguaje HTM L cambia drásticamente la visión y recepción de la información.

Las amplias conexiones de red causaron la proliferación de virus informáticos y basura o spam en los correos electrónicos ( Correo electrónico). Esta situación puso en una carrera contra el tiempo a los desarrolladores con el fin de crear nuevos sistemas de bloqueo o seguridad de dichas anomalías en la informática, ya que se volvían sumamente tediosas y difíciles de arreglar

Después de una fuerte y creciente demanda surge la necesidad de crear soluciones de software a bajo costo, lo que conlleva al uso de metodologías más simples y rápidas que desarrollan software funcional. Cabe señalar que los sistemas más pequeños tenían un enfoque más simple y rápido para poder administrar el desarrollo de cálculos y algoritmos de software.

Entre los objetivos de la ingeniería de software están:

Mejorar el diseño de aplicaciones o software de tal modo que se adapten de mejor manera a las necesidades de las organizaciones o finalidades para las cuales fueron creadas.

Promover mayor calidad al desarrollar aplicaciones complejas.

Brindar mayor exactitud en los costos de proyectos y tiempo de desarrollo de los mismos.

Aumentar la eficiencia de los sistemas al introducir procesos que permitan medir mediante normas específicas, la calidad del software desarrollado, buscando siempre la mejor calidad posible según las necesidades y resultados que se quieren generar.

Una mejor organización de equipos de trabajo, en el área de desarrollo y mantenimiento de software.

Detectar a través de pruebas, posibles mejoras para un mejor funcionamiento del software desarrollado.​

Es el entorno de las aplicaciones ( software y hardware) el hardware proporciona el medio físico para desarrollar las aplicaciones ( software), este recurso es indispensable.​

En los Estados Unidos, el software contribuyó a una octava parte de todo el incremento del PIB durante la década de 1990 (alrededor de 90 000 millones de dólares por año), y un noveno de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33.000 millones de dólares estadounidenses por año). La ingeniería de software contribuyó a US$ 1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el contribuye al crecimiento económico de maneras similares, aunque es difícil de encontrar estadísticas fiables. [cita requerida]

Además, con la industria del lenguaje está hallando cada vez más campos de aplicación a escala global.

La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico (e-mail), la WWW y la mensajería instantánea permiten a la gente interactuar de nuevas maneras. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a GNU/Linux, el software del transbordador espacial, los cajeros automáticos y muchos otros.

Es un lenguaje de modelado muy reconocido y utilizado actualmente que se utiliza para describir o especificar métodos. También es aplicable en el desarrollo de software.

Las siglas UML significan lenguaje unificado de modelado esto quiere decir que no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado.​

Un lenguaje de modelado consta de vistas, elementos de modelo y un conjunto de reglas sintácticas, semánticas y pragmáticas que indican cómo utilizar los elementos.

En esta materia nos encontramos con varios diagramas que se pueden usar tales como: casos de uso, de clases, componentes, despliegue, etc.

El objetivo de la notación para el modelado de procesos de negocios es proporcionar de una manera fácil de definir y analizar los procesos de negocios públicos y privados simulando un diagrama de flujo. La notación ha sido diseñada específicamente para coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes del mismo, con un conjunto de actividades relacionadas. Características básicas de los elementos de BPMN

Objetos de flujo: eventos, actividades, rombos de control de flujo (gateways).

Objetos de conexión: flujo de secuencia, flujo de mensaje, asociación.

Swimlanes (carriles de piscina): pool, lane.

Artefactos: objetos de datos, grupo, anotación.​

Un diagrama de flujo de datos permite representar el movimiento de datos a través de un sistema por medio de modelos que describen los flujos de datos, los procesos que transforman o cambian los datos, los destinos de datos y los almacenamientos de datos a la cual tiene acceso el sistema.

Su inventor fue Larry Constantine, basado en el modelo de computación de Martin y Estrin: flujo gráfico de datos. Con los diagramas de flujo de datos determina la manera en que cualquier sistema puede desarrollarse, ayuda en la identificación de los datos de la transacción en el modelo de datos y proporciona al usuario una idea física de cómo resultarán los datos a última instancia.​

Las Herramienta CASE son herramientas computacionales ( software) que están destinadas a asistir en los procesos de ciclo de vida de un software, facilitan la producción del software, varias se basan principalmente en la idea de un modelo gráfico.​

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software, en pocas palabras, determina los pasos a seguir y como realizarlos para finalizar una tarea.

La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en etapas, al conjunto de estas etapas se le denomina ciclo de vida. Las etapas comunes a casi todos los modelos de ciclo de vida son las siguientes:

Se debe identificar sobre qué se está trabajando, es decir, el tema principal que motiva el inicio del estudio y creación del nuevo software o modificación de uno ya existente. A su vez identificar los recursos que se tienen, en esto entra el conocer los recursos humanos y materiales que participan en el desarrollo de las actividades. Es importante entender el contexto del negocio para identificar adecuadamente los requisitos.

Se tiene que tener dominio de la información de un problema, lo cual incluye los datos fuera del software (usuarios finales, otros sistemas o dispositivos externos), los datos que salen del sistema (por la interfaz de usuario, interfaces de red, reportes, gráficas y otros medios) y los almacenamientos de datos que recaban y organizan objetos persistentes de datos (por ejemplo, aquellos que se conservan de manera permanente).

También hay que ver los puntos críticos, lo que significa tener de una manera clara los aspectos que entorpecen y limitan el buen funcionamiento de los procedimientos actuales, los problemas más comunes y relevantes que se presentan, los motivos que crean insatisfacción y aquellos que deben ser cubiertos a plenitud. Por ejemplo: ¿El contenido de los reportes generados, satisface realmente las necesidades del usuario? ¿Los tiempos de respuesta ofrecidos, son oportunos?, etc.

Hay que definir las funciones que realizará el software ya que estas ayudan al usuario final y al funcionamiento del mismo programa.

Se tiene que tener en cuenta cómo será el comportamiento del software ante situaciones inesperadas como lo son por ejemplo una gran cantidad de usuarios usando el software o una gran cantidad de datos entre otros.

Extraer los requisitos de un producto software es la primera etapa para crearlo. Durante la fase de análisis, el cliente plantea las necesidades que se presenta e intenta explicar lo que debería hacer el software o producto final para satisfacer dicha necesidad mientras que el desarrollador actúa como interrogador, como la persona que resuelve problemas. Con este análisis, el ingeniero de sistemas puede elegir la función que debe realizar el software y establecer o indicar cuál es la interfaz más adecuada para el mismo.​

El análisis de requisitos puede parecer una tarea sencilla, pero no lo es debido a que muchas veces los clientes piensan que saben todo lo que el software necesita para su buen funcionamiento, sin embargo se requiere la habilidad y experiencia de algún especialista para reconocer requisitos incompletos, ambiguos o contradictorios. Estos requisitos se determinan tomando en cuenta las necesidades del usuario final, introduciendo técnicas que nos permitan mejorar la calidad de los sistemas sobre los que se trabaja.​

El resultado del análisis de requisitos con el cliente se plasma en el documento ERS (especificación de requisitos del sistema), cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de entidad/relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos metódicos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la ingeniería de requisitos.

La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requisitos de software (Software Requirements Specification).

Finalidades del análisis de requisitos:

Brindar al usuario todo lo necesario para que pueda trabajar en conjunto con el software desarrollado obteniendo los mejores resultados posibles.

Tener un control más completo en la etapa creación del software, en cuanto a tiempo de desarrollo y costos.

Utilización de métodos más eficientes que permitan el mejor aprovechamiento del software según sea la finalidad de uso del mismo.

Aumentar la calidad del software desarrollado al disminuir los riesgos de mal funcionamiento.​

No siempre en la etapa de "análisis de requisitos" las distintas metodologías de desarrollo llevan asociado un estudio de viabilidad y/o estimación de costes. El más conocido de los modelos de estimación de coste del software es el modelo COCOMO

Limitaciones​

Los software tienen la capacidad de emular inteligencia creando un modelo de ciertas características de la inteligencia humana pero solo posee funciones predefinidas que abarcan un conjunto de soluciones que en algunos campos llega a ser limitado. Aun cuando tiene la capacidad de imitar ciertos comportamientos humanos no es capaz de emular el pensamiento humano porque actúa bajo condiciones.

Otro aspecto limitante de los software proviene del proceso totalmente mecánico que requiere de un mayor esfuerzo y tiempos elevados de ejecución lo que lleva a tener que implementar el software en una máquina de mayor capacidad.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales.

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto.

El arquitecto de software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas.

La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de software.

Lo principal en este punto es poner en claro los aspectos lógicos y físicos de las salidas, modelos de organización y representación de datos, entradas y procesos que componen el sistema, considerando las bondades y limitaciones de los recursos disponibles en la satisfacción de las pacificaciones brindadas para el análisis.

Hay que tener en consideración la arquitectura del sistema en la cual se va a trabajar, elaborar un plan de trabajo viendo la prioridad de tiempo y recursos disponibles. En los diseños de salidas entra los que es la interpretación de requerimientos lo cual es el dominio de información del problema, las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases de requerimientos que agrupa los objetos del negocio con los métodos que les dan servicio.

Los diagramas de clases y de base de datos son los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Dependiendo del alcance del proyecto, complejidad y necesidades, el arquitecto elegirá cuales de los diagramas se requiere elaborar.

Las herramientas para el diseño y modelado de software se denominan CASE ( Computer Aided Software Engineering) entre las cuales se encuentran:

Enterprise Architect

Microsoft Visio for Enterprise Architects

Implementar un diseño en código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Para el desarrollo de la aplicación es necesario considerar cinco fases para tener una aplicación o programa eficiente, estas son:

Desarrollo de la infraestructura: Esta fase permite el desarrollo y la organización de los elementos que formaran la infraestructura de la aplicación, con el propósito de finalizar la aplicación eficientemente.

Adaptación del paquete: El objetivo principal de esta fase es entender de una manera detallada el funcionamiento del paquete, esto tiene como finalidad garantizar que el paquete pueda ser utilizado en su máximo rendimiento, tanto para negocios o recursos. Todos los elementos que componen el paquete son inspeccionados de manera detallada para evitar errores y entender mejor todas las características del paquete.

Desarrollo de unidades de diseño de interactivas: En esta fase se realizan los procedimientos que se ejecutan por un diálogo usuario-sistema. Los procedimientos de esta fase tienen como objetivo principal:

1. Establecer específicamente las acciones que debe efectuar la unidad de diseño.

2. La creación de componentes para sus procedimientos.

3. Ejecutar pruebas unitarias y de integración en la unidad de diseño.

Desarrollo de unidades de diseño batch: En esta fase se utilizan una serie de combinación de técnicas, como diagrama de flujo, diagramas de estructuras, tablas de decisiones, etc. Cualquiera a utilizar será beneficioso para plasmar de manera clara y objetiva las especificaciones y que así el programador tenga mayor comprensión a la hora de programar y probar los programas que le corresponden.

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica es probar por separado cada módulo del software ( prueba unitaria), y luego probarlo de manera integral ( pruebas de integración), para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes maneras de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta manera se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

De acuerdo con Roger S. Pressman, el proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales, es decir, la realización de pruebas para la detección de errores. Se requiere poder probar el software con sujetos reales que puedan evaluar el comportamiento del software con el fin de proporcionar realimentación a los desarrolladores. Es importante que durante el proceso de desarrollo del software no se pierda contacto con los interesados o solicitantes del desarrollo de software, de esta manera los objetivos del proyecto se mantendrán vigentes y se tendrá una idea clara de los aspectos que tienen que probarse durante el período de pruebas.​

Una implementación es la realización de una especificación técnica o algoritmos con un programa, componente software, u otro sistema de cómputo. Muchas especificaciones son dadas según a su especificación o un estándar. Las especificaciones recomendadas según el World Wide Web Consortium, y las herramientas de desarrollo del software contienen implementaciones de lenguajes de programación. El modelo de implementación es una colección de componentes y los subsistemas que contienen. Componentes tales como: ficheros ejecutables, ficheros de código fuente y todo otro tipo de ficheros que sean necesarios para la implementación y despliegue del sistema.

La etapa de implementación del diseño de software es el proceso de convertir una especificación del sistema en un sistema ejecutable. Siempre implica los procesos de diseño y programación de software, pero, si se utiliza un enfoque evolutivo de desarrollo, también puede implicar un refinamiento de la especificación del software. Esta etapa es una descripción de la estructura del software que se va a implementar, los datos que son parte del sistema, las interfaces entre los componentes del sistema, y algunas veces los algoritmos utilizados.​

Es todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones ( UML), diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto​ está dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.

El mantenimiento de software, según la investigación de Lehman, el 80% del mantenimiento no son acciones correctivas. Son mejoras de funcionalidad (e incorporación de nuevos requisitos), según Lehman el software evoluciona con el tiempo. Teniendo en cuenta eso, la etapa de mantenimiento en sí misma puede incluir las etapas anteriores entre el despliegue de cada nueva versión, reutilizando el software ya existente, reformandolo y adaptandolo.

Facilitar la tarea de seguimiento del proyecto

Optimizar el uso de recursos

Facilitar la comunicación entre usuarios y desarrolladores

Facilitar la evaluación de resultados y cumplimiento de objetivos

Desde el punto de vista de los ingenieros de software

Ayudar a comprender el problema

Permitir la reutilización

Facilitar el mantenimiento del producto final

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

Garantizar el nivel de calidad del producto final

Obtener el ciclo de vida adecuado para el proyecto

Confianza en los plazos del tiempo mostrados en la definición del proyecto

Modelos y ciclos de vida del desarrollo de software

La ingeniería de software, con el fin de ordenar el caos que era anteriormente el desarrollo de software, dispone de varios modelos, paradigmas y filosofías de desarrollo, estos los conocemos principalmente como modelos o ciclos de vida del desarrollo de software, esto incluye el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema y representa todas las actividades y artefactos (productos intermedios) necesarios para desarrollar una aplicación.​

El ciclo de vida de un software contiene los siguientes procedimientos:

Integración: para garantizar que los diferentes módulos se integren con la aplicación. Este es el propósito de la prueba de integración que está cuidadosamente documentada.​

Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.​

Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.​

Implementación

Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).​

En ingeniería de software el modelo en cascada ―también llamado desarrollo en cascada o ciclo de vida clásico― se basa en un enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, esto sugiere una aproximación sistemática secuencial hacia el proceso de desarrollo del software, que se inicia con la especificación de requisitos del cliente y continúa con la planificación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.​

En ingeniería de software, el modelo de prototipos pertenece a los modelos de desarrollo evolutivo. Este permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta manera minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.

Este modelo principalmente se aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la manera en que interactúa el hombre y la máquina.

Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.​

El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada, es decir, cuando se aplica este modelo, el software se desarrolla en una serie de entregas evolutivas (ciclos o iteraciones), cada una de estas entregando prototipos más completas que el anterior, todo esto en función del análisis de riesgo y las necesidades del cliente. Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y por lo cual su uso en el ámbito real es muy escaso.​

Es un modelo en el que el software se muestra al cliente en etapas refinadas sucesivamente. Con esta metodología se desarrollan las capacidades más importantes reduciendo el tiempo necesario para la construcción de un producto; el modelo de entrega por etapas es útil para el desarrollo de la herramienta debido a que su uso se recomienda para problemas que pueden ser tratados descomponiéndolos en problemas más pequeños y se caracteriza principalmente en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.

En este modelo pueden distinguirse las siguientes fases:

Especificación conceptual.

Análisis de requisitos.

Diseño inicial.

Diseño detallado (codificación, depuración, prueba y liberación).

Cuando es por etapas, en el diseño global estas fases pueden repetirse según la cantidad de etapas que sean requeridas.

Entre sus ventajas tenemos:

Detección de problemas antes y no hasta la única entrega final del proyecto.

Eliminación del tiempo en informes debido a que cada versión es un avance.

Estimación de tiempo por versión, evitando errores en la estimación del proyecto general.

Cumplimiento a la fecha por los desarrolladores.

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada, es decir, este modelo aplica secuencias lineales como el modelo en cascada, pero de una manera iterativa o escalada según como avance el proceso de desarrollo y con cada una de estas secuencias lineales se producen incrementos (mejoras) del software.​

Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos, ya que como se mencionó anteriormente, este tipo de modelo es iterativo por naturaleza, sin embargo se diferencia en que este busca la entrega de un producto operacional con cada incremento que se le realice al software.

Este modelo ―como su nombre lo indica― utiliza las técnicas del diseño estructurado o de la programación estructurada para su desarrollo, también se utiliza en la creación de los algoritmos del programa. Este formato facilita la comprensión de la estructura de datos y su control.​ Entre las principales características de este modelo se encuentran las siguientes:

Generalmente se puede diferenciar de una manera más clara los procesos y las estructuras de datos.

Existen métodos que se enfocan principalmente en ciertos datos.

La abstracción del programa es de un nivel mucho mayor.

Los procesos y estructuras de datos son representados jerárquicamente.​

Este modelo también presenta sus desventajas entre las cuales podemos mencionar algunas:

Se podía encontrar datos repetidos en diferentes partes del programa.​

Cuando el código se hace muy extenso o grande su manejo se complica demasiado.​

En el modelo estructurado las técnicas que comúnmente se utilizan son:

Estos modelos tienen sus raíces en la programación orientada a objetos y como consecuencia de ella gira en torno al concepto de clase, también lo hacen el análisis de requisitos y el diseño. Esto además de introducir nuevas técnicas, también aprovecha las técnicas y conceptos del desarrollo estructurado, como diagramas de estado y transiciones. El modelo orientado a objetos tiene dos características principales, las cuales ha favorecido su expansión:

Permite la reutilización de software en un grado significativo.

Su simplicidad facilita el desarrollo de herramientas informáticas de ayuda al desarrollo, el cual es fácilmente implementada en una notación orientada a objetos llamado UML.​

El RAD ( rapid application development: 'desarrollo rápido de aplicaciones'), es un modelo de proceso de software incremental, desarrollado inicialmente por James Maslow en 1980, que resalta principalmente un ciclo corto de desarrollo.

Esta es una metodología que posibilita la construcción de sistemas computacionales que combinen técnicas y utilidades CASE (Computer Aided Software Engineering), la construcción de prototipos centrados en el usuario y el seguimiento lineal y sistemático de objetivos, incrementando la rapidez con la que se producen los sistemas mediante la utilización de un enfoque de desarrollo basado en componentes.​

Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite que un equipo de desarrollo cree un producto completamente funcional dentro de un periodo muy limitado de tiempo sin reducir en lo más mínimo la calidad del mismo.​

El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo. Este tipo de modelo se puede representar a manera de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera. Este modelo de desarrollo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización.

La concurrencia se logra de dos maneras:

Las actividades del sistema y de componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente;

Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.

Proceso unificado del desarrollo de software

El proceso unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.

Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.​

El proceso unificado tiene dos dimensiones:

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento

Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo con su naturaleza.

La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).

La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.

El refinamiento más conocido y documentado del proceso unificado es el RUP (proceso unificado racional).

El proceso unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma manera, el proceso unificado de rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del proceso unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.​

El software se ha convertido en algo muy necesario en nuestra sociedad actual, es la máquina que conduce a la toma de decisiones comerciales, sirve para la investigación científica moderna, es un factor clave que diferencia productos y servicios modernos. Esto se da porque el software está inmerso en sistemas de todo tipo alrededor de nosotros.

El software de computadora es el producto que diseñan y construyen los ingenieros de software. Esto abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura, después de estar construido casi cualquier persona en el mundo industrializado, ya sea directa o indirectamente.

Los productos se pueden clasificar en:

Productos genéricos: Son los producidos por una organización para ser vendidos al mercado.

Productos hechos a medida: Sistemas que son desarrollados bajo pedido a un desarrollador específico.

Estos productos deben cumplir varias características al ser entregados, estas son:

Mantenibles: El software debe poder evolucionar mientras cumple con sus funciones.

Confiabilidad: No debe producir daños en caso de errores.

Eficiencia: El software no debe desperdiciar los recursos.

Utilización adecuada: Debe contar con una interfaz de usuario adecuada y su documentación.

Lo que constituye el producto final es diferente para el ingeniero y los usuarios, para el ingeniero son los programas, datos y documentos que configuran el software pero para el usuario el producto final es la información que de cierto modo soluciona el problema planteado por el usuario.

Naturaleza de la ingeniería de software

La ingeniería de software es una disciplina que está orientada a aplicar conceptos y métodos de ingeniería al desarrollo de software de calidad.

Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.

Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que se encuentran en la IS.

El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administración se debe tener una clara visión y capacitación en gestión de proyectos.

Para el desarrollo de un sistema de software es necesaria la colaboración de muchas personas con diversas competencias, capacidades e intereses. Al conjunto de personas involucradas en el proyecto se les conoce como participantes.

Al conjunto de funciones y responsabilidades que hay dentro del proyecto o sistema se le conoce como roles o papeles. Los roles están asociados a las tareas que son asignadas a los participantes, en consecuencia, una persona puede desempeñar uno o múltiples roles, así también un mismo rol puede ser representado por un equipo.​

Es frecuente el uso de los términos "usuarios", "usuarios finales" y "clientes" como sinónimos, lo cual puede provocar confusión; estrictamente, el cliente (persona, empresa u organización) es quién especifica los requisitos del sistema,​ en tanto que el usuario es quien utiliza u opera finalmente el producto software, pudiendo ser o no el cliente.

Esta clase de participantes están relacionados con todas las facetas del proceso de desarrollo del software. Su trabajo incluye la investigación, diseño, implementación, pruebas y depuración del software.​

En el contexto de ingeniería de software, el gestor de desarrollo de software es un participante, que reporta al director ejecutivo de la empresa que presta el servicio de desarrollo. Es responsable del manejo y coordinación de los recursos y procesos para la correcta entrega de productos de software, mientras participa en la definición de la estrategia para el equipo de desarrolladores, dando iniciativas que promuevan la visión de la empresa.​

El usuario final es quien interactúa con el producto de software una vez es entregado.​ Generalmente son los usuarios los que conocen el problema, ya que día a día operan los sistemas.

Código ético de un ingeniero de software

Un ingeniero de software debe tener un código donde asegura, en la medida posible, que los esfuerzos realizados se utilizarán para realizar el bien y deben comprometerse para que la ingeniería de software sea una profesión benéfica y respetada. Para el cumplimiento de esta norma, se toman en cuenta ocho principios relacionados con la conducta y las decisiones tomadas por el ingeniero; donde estos principios identifican las relaciones éticamente responsables de los individuos, grupos y organizaciones donde participen. Los principios a los que deben sujetarse son sobre la sociedad, cliente y empresario, producto, juicio, administración, profesión, colegas y por último el personal.

Sociedad: Los ingenieros de software deben actuar de manera congruente con el interés social, aceptando la responsabilidad total de su trabajo, moderando los intereses con el bienestar social, aprobando el software solamente si se tiene una creencia bien fundamentada, cooperando en los esfuerzos para solucionar asuntos importantes de interés social, ser justo y veraz en todas las afirmaciones relativas al software o documentos asociados.

Cliente y empresario: Se debe actuar de manera tal que se llegue a conciliar los mejores intereses de los clientes y empresarios, congruentemente con el interés social. Estos deberán prestar servicios en sus áreas de competencia, siendo honestos y francos sobre las limitaciones, no utilizar un software que se obtenga ilegalmente o sin ética, usar la propiedad de los clientes o empresarios de manera autorizada, mantener secreto cualquier documento de información confidencial.

Producto: Hay que asegurarse que los productos y sus modificaciones cumplan con los estándares profesionales más altos posibles, procurando la alta calidad, costos aceptables y una agenda razonable asegurando que los costos y beneficios sean claros y aceptados por el empresario y el cliente. Asegurar que las metas y objetivos de cualquier proyecto sean adecuados y alcanzables.

Juicio: Se debe mantener una integridad e independencia en el juicio profesional, moderando todo juicio técnico por la necesidad de apoyar y mantener los valores humanos, mantener la objetividad profesional con respecto a cualquier software o documento relacionado, no involucrarse en prácticas financieras fraudulentas.

Administración: Se deberá asegurar una buena administración para cualquier proyecto en el cual se trabaje, utilizando procedimientos efectivos para promover la calidad y reducir riesgos, asegurándose también que se conozcan las políticas y procedimientos del empresario para proteger contraseñas, archivos e información confidencial.

Profesión: Se debe incrementar la integridad y reputación de la profesión en conjunto con el interés social, ayudando al desarrollo de un ambiente organizacional favorable para actuar, promoviendo el conocimiento público de la ingeniería de software, extendiendo el conocimiento de la ingeniería de software por medio de participaciones en organizaciones, reuniones y publicaciones profesionales.

Colegas: Cada ingeniero deberá apoyar y ser justos con los colegas, motivando a sus colegas sujetándose al código, ayudando también a su desarrollo profesional, reconocer los trabajos de otros y abstenerse a atribuirse de méritos indebidos, revisar los trabajos de manera objetiva, sincera y propiamente documentada.

Personal: Los ingenieros de software participaran toda su vida en el aprendizaje con la práctica y promoverán un enfoque ético de la profesión, mejorando su conocimiento de los avances en el análisis, especificación, diseño, desarrollo, mantenimiento, pruebas del software y documentos relacionados en conjunto con administración del proceso de desarrollo.​

1. executive editors, Alain Abran, James W. Moore; editors, Pierre Bourque, Jonathan Aguilar, Robert Dupuis. (2004). Pierre Bourque and Robert Dupuis, ed. SWEBOK Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. pp. 1-1. .

2. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.

3. Bureau of Labor Statistics, U.S. Department of Labor, (USDL 05-2145: Occupational Employment and Wages, November 2004 enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última)., Table 1.

4. Leondes (2002). intelligent systems: technology and applications. CRC Press. .

5. Sommerville, Ian (1985) [1982]. Software Engineering (en inglés). Addison-Wesley. . "Software engineering... has recently emerged as a discipline in its own right. "

6. Universidad Politécnica de Madrid. "Objetivos de ingeniería del software".

7. Pressman, Roger S. (2003). "El proceso". Ingeniería del software, un enfoque práctico. México: Mc Graw Hill, quinta edición.

8. Monografias.com. "Ingenieria de Software UML".

9. "Limitaciones de los software", artículo en el sitio web Mundo Kramer.

10. "Unidad 2: Fundamentos de la ingeniería del software" Archivado el 13 de abril de 2014 en Wayback Machine., artículo en el sitio web Ing Software.

11. Ingeniería de software: ciclos de vida y metodologías, artículo publicado en el sitio web de la Facultad de Ingeniería de la Universidad de Los Andes.

12. ↑ Diseño estructurado, artículo en el sitio web Slide Share.

13. Campderrich Falgueras, Benet (2002): Ingeniería de software. Barcelona: Editorial UOC, 2002. 320 páginas.

14. [5] Archivado el 24 de agosto de 2014 en Wayback Machine., What is Rapid Application Development?

15. "Proceso unificado del desarrollo de software" Archivado el 29 de marzo de 2014 en Wayback Machine., artículo en el sitio web Yaqui.

16. Bernd Bruegge & Allen H.Dutoit. Object-Oriented Software Engineering, Prentice Hall, Pag. 11.

17. "O*NET Code Connector - Software Developers, Systems Software - 15-1133.00". Onetcodeconnector.org.

18. "Software Development Manager Position Description". interfacing.com.

# data[].attributes.attachment_link.title
Ingeniería de software - Wikipedia, la enciclopedia libre

# data[].attributes.attachment_link.description
Ingeniería de software Campo de aplicación Desarrollo de software de aplicación, Desarrollo de software de sistema, Desarrollo web, Desarrollo de aplicaciones móviles, Desarrollo de software de gráficos, Desarrollo de aplicaciones de escritorio, Desarrollo de bot conversacional, Desarrollo de cadena de bloques, Desarrollo de software de física computacional, Desarrollo de software

# data[].attributes.body
4) https://books.google.com.ar/books?id=a8j2DQAAQBAJ&pg=PT516&dq=alcance+ingenier%C3%ADa+del+software&hl=es&sa=X&ved=0ahUKEwi2pveLmdPoAhUmILkGHW2bBX4Q6AEIMTAB#v=onepage&q=alcance%20ingenier%C3%ADa%20del%20software&f=false

# data[].attributes.attachment_link.description
El lector encontrará en sus páginas los temas fundamentales para la formación de un ingeniero de software, tratados en un nivel que busca balancear la inclusión y el detalle; los temas se presentan según el estado actual de la tecnología expuestos con un nivel de complejidad necesario para establecer las bases, sin embargo no es un libro informativo ya que los conceptos expuestos son fundamentales, simples en esencia pero que necesitan de experimentación para terminar de ser aprendidos.

# data[].attributes.body
5) https://masteringenieriasoft.blogspot.com/2012/04/metodologias-de-desarrollo-de-software.html

# data[].attributes.attachment_link.readable_text
Desarrollar software implica muchas cosas, desde su planificación hasta la puesta en marcha se deben de seguir un sinnúmero de pasos o actividades. Hoy en día existen diversas metodologías para hacerlo, sin embargo es necesario definir primero la naturaleza del software antes de elegir un determinado ciclo de vida.

En el presente trabajo se detallan los dos grandes enfoques, tanto metodologías tradicionales y metodologías ágiles, las primeras están pensadas para el uso exhaustivo de documentación durante todo el ciclo del proyecto mientras que las segundas ponen vital importancia en la capacidad de respuesta a los cambios, la confianza en las habilidades del equipo y al mantener una buena relación con el cliente. Se verán diferencias, ventajas, desventajas y cual puede encajar en un proyecto de software para interés del lector.

Palabras Claves Metodología, RUP, MSF AUP, Scrum, Metodología Tradicional, Metodología Ágil

Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la concepción y fundamentos de metodologías existentes en otras áreas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptación contenía el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software.

Entre las principales metodologías tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y centran su atención en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las características importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solución para proyectos donde el entorno es volátil.

Las metodologías tradicionales (formales) se focalizan en documentación, planificación y procesos. (Plantillas, técnicas de administración, revisiones, etc.), a continuación se detalla RUP uno de los métodos más usados dentro de los métodos tradicionales

Rational Unified Process (RUP)

Proceso Unificado Rational

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo.

Nuestro cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él.

Microsoft Solution Framework (MSF)

MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.

Todo proyecto es separado en cinco principales fases:

Microsoft Operation Framework.-

El modelo de proceso MOF está formado por cuadrantes, revisiones de la administración de las operaciones y revisiones de la administración de los servicios. En la figura 1 se muestra el funcionamiento del ciclo de MOF.

Ciclo de Microsoft Operations Framework

En la figura, se observa que el modelo de proceso MOF se desplaza en sentido de las agujas del reloj y se divide en los cuatro cuadrantes integrados siguientes:

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Diferencias entre Metodología Tradicionales y Ágiles

Ø El uso de metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software

Ø Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre donde el entorno es volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.

# data[].attributes.attachment_link.title
METODOLOGIAS DE DESARROLLO DE SOFTWARE TRADICIONALES VS AGILES

# data[].attributes.attachment_link.description
Desarrollar software implica muchas cosas, desde su planificación hasta la puesta en marcha se deben de seguir un sinnúmero de pasos o actividades. Hoy en día existen diversas metodologías para hacerlo, sin embargo es necesario definir primero la naturaleza del software antes de elegir un determinado ciclo de vida.

# data[].attributes.body
Regular las expectativas del cliente: El cliente comprueba de manera regular si se van cumpliendo según sus expectativas. Se ahorra esfuerzo y tiempo al evitar hipótesis.

Flexibilidad y adaptación: el cliente redirige el proyecto en función de sus nuevas prioridades.

Productividad y calidad: El equipo va mejorando y simplificando su forma de trabajar.

Adaptación entre cliente y equipo: Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos.

Equipo motivado: Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo.

# data[].attributes.body
Scrum es una metodología o marco de gestión de proyectos ágil utilizado principalmente para proyectos de desarrollo de software hardware, software embebido y redes de funciones interactivas.

Scrum está indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

# data[].attributes.body
1- Dueño del producto (Product Owner): En el nivel más básico, el propietario de un producto es el líder responsable de maximizar el valor de los productos creados por un equipo de desarrollo de Scrum.

Pero para hacer esto, el propietario de un producto asume varios roles, incluido el de estratega de negocios, diseñador de productos, analista de mercado, enlace con el cliente y el gerente de proyectos.

2- Scrum Master: Muchos consideran que el Scrum Master es el líder del proyecto, y gestiona las acciones en cada iteración, es el encargado de mantener en contacto al equipo de trabajo con el cliente. Otras de sus funciones más destacadas son:

Resolver los conflictos que obstaculicen el ritmo normal del proyecto.

Incentivar y motivar al equipo de trabajo.

Fomentar la autogestión de sus colaboradores durante el proceso.

Negociar y renegociar las condiciones con el cliente.

Evitar la intromisión de terceros en las labores.

3- Scrum Team: Hace referencia al equipo de trabajo que lleva a cabo las acciones propias de cada iteración: programadores, diseñadores, arquitectos, personal de servicio, entre otros. Lo principal es que deben estar organizados como un grupo o equipo y desempeñar roles concretos dentro de él. Se ocupan básicamente de cosas como las siguientes:

Desarrollar cada una de las tareas incluidas en el plan de trabajo.

Poner al servicio del proyecto sus conocimientos y técnicas.

# data[].attributes.headline
4) ¿Qué es un Sprint? Describe y de un ejemplo.

# data[].attributes.subject
4) ¿Qué es un Sprint? Describe y de un ejemplo.

# data[].attributes.body
Un sprint es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “terminado” utilizable y potencialmente desplegable.

Los Sprints están limitados a un mes calendario. Cuando el horizonte de un Sprint es demasiado grande la definición de lo que se está construyendo podría cambiar, la complejidad podría incrementarse y el riesgo podría aumentar.

Los Sprints habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al menos en cada mes calendario. Los Sprints también limitan el riesgo al costo de un mes calendario.

# data[].attributes.headline
5) ¿Qué es un Product List? De un ejemplo.

# data[].attributes.subject
5) ¿Qué es un Product List? De un ejemplo.

# data[].attributes.body
Un product list o “lista de Producto” es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.

1. Una Lista de Producto nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos.

2. La Lista de Producto evoluciona a medida que el producto y el entorno en el que se usará también lo hacen.

3. La Lista de Producto es dinámica y cambia constantemente, para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Si un producto existe, su Lista de Producto también existe.

Ejemplo: La Lista de Producto enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a realizarse sobre el producto para entregas futuras. Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor. Los elementos de La Lista de Producto muchas veces incluyen descripciones de las pruebas que demostrarán la completitud de tales elementos cuando estén “Terminados”.

# data[].attributes.body
El Equipo de Desarrollo es el responsable de proporcionar todas las estimaciones. El dueño del producto podría influenciar al equipo ayudándoles a entender y seleccionar sus compromisos, pero las personas que harán el trabajo son las que hacen la estimación final. Se realizan estimaciones más precisas basándose en la mayor claridad y detalle; cuanto más bajo es el orden, menor es el detalle.

# data[].attributes.headline
7- ¿Cómo se hace la reflexión sobre el método?

# data[].attributes.subject
7- ¿Cómo se hace la reflexión sobre el método?

# data[].attributes.body
1. En scrum se promueve la reflexión colectiva a través de la retrospectiva, una vez finalizado el sprint.

2. Las reuniones retrospectivas necesitan un ambiente positivo y de confianza.

3. No deben quedarse sólo en el análisis de problemas, deben convertirse en un auténtico acelerador del cambio.

La reflexión hará que las personas del equipo se sientan más cercanas entre sí. Se profundizará en el espíritu tribal, la conciencia de grupo, la lucha por un propósito común. La confianza nos llevará a que no sea necesario llegar al final de un sprint para destapar la caja de Pandora. Con la reflexión constante la retrospectiva se convertirá en una herramienta realmente poderosa.

# data[].attributes.attachment_link.title
Product List - Prototipo de auto de juguete

# data[].attributes.headline
Enzo Pastrana - Arduino - Ejercicio1 (Encender un Led)

# data[].attributes.subject
Enzo Pastrana - Arduino - Ejercicio1 (Encender un Led)

# data[].attributes.attachment_link.title
Clase 7 -  Calidad de Software - Enzo Pastrana