Desarrollo de software

El desarrollo de software es el proceso de concebir, especificar, diseñar, programar , documentar , probar y corregir errores involucrados en la creación y mantenimiento de aplicaciones , marcos u otros componentes de software. El desarrollo de software es un proceso de escritura y mantenimiento del código fuente , pero en un sentido más amplio, incluye todo lo que está involucrado desde la concepción del software deseado hasta la manifestación final del software, a veces en unprocesoplanificado y estructurado . ^[1]Por lo tanto, el desarrollo de software puede incluir investigación, nuevo desarrollo, creación de prototipos, modificación, reutilización, reingeniería, mantenimiento o cualquier otra actividad que dé como resultado productos de software. ^[2]

El software se puede desarrollar para una variedad de propósitos, los tres más comunes son para satisfacer las necesidades específicas de un cliente / negocio específico (el caso del software personalizado ), para satisfacer una necesidad percibida de algún conjunto de usuarios potenciales (el caso de los y software de código abierto ), o para uso personal (por ejemplo, un científico puede escribir software para automatizar una tarea mundana). El desarrollo de software integrado , es decir, el desarrollo de software integrado , como el que se utiliza para controlar los productos de consumo, requiere que el proceso de desarrollo se integre con el desarrollo del producto físico controlado. El software del sistema es la base de las aplicaciones y el proceso de programación en sí, y a menudo se desarrolla por separado.

La necesidad de un mejor control de calidad del proceso de desarrollo de software ha dado lugar a la disciplina de la ingeniería de software , que tiene como objetivo aplicar el enfoque sistemático ejemplificado en el paradigma de la ingeniería al proceso de desarrollo de software.

Hay muchos enfoques para la gestión de proyectos de software , conocidos como modelos, metodologías, procesos o modelos del ciclo de vida del desarrollo de software. El modelo en cascada es una versión tradicional, en contraste con la innovación más reciente de desarrollo ágil de software .

Metodologías

Un proceso de desarrollo de software (también conocido como metodología, modelo o ciclo de vida de desarrollo de software) es un marco que se utiliza para estructurar , planificar y controlar el proceso de desarrollo de sistemas de información . Una amplia variedad de estos marcos ha evolucionado a lo largo de los años, cada uno con sus propias fortalezas y debilidades reconocidas. Hay varios enfoques diferentes para el desarrollo de software: algunos adoptan un enfoque más estructurado y basado en la ingeniería para desarrollar software, mientras que otros pueden adoptar un enfoque más incremental, donde el software evoluciona a medida que se desarrolla pieza por pieza. Una metodología de desarrollo de sistemas no es necesariamente adecuada para todos los proyectos. Cada una de las metodologías disponibles se adapta mejor a tipos específicos de proyectos, basándose en diversas consideraciones técnicas, organizativas, de proyecto y de equipo. ^[3]

La mayoría de las metodologías comparten alguna combinación de las siguientes etapas de desarrollo de software:

• Analizando el problema
• Investigación de mercado
• Recopilación de requisitos para el software propuesto
• Elaborar un plan o diseño para el software
• Implementación (codificación) del software
• Probando el software
• Despliegue
• Mantenimiento y corrección de errores

Estas etapas a menudo se denominan colectivamente ciclo de vida de desarrollo de software o SDLC. Diferentes enfoques de desarrollo de software pueden llevar a cabo estas etapas en diferentes órdenes, o dedicar más o menos tiempo a diferentes etapas. El nivel de detalle de la documentación producida en cada etapa del desarrollo del software también puede variar. Estas etapas también pueden llevarse a cabo a su vez (un enfoque basado en "cascada"), o pueden repetirse en varios ciclos o iteraciones (un enfoque más "extremo"). El enfoque más extremo generalmente implica menos tiempo dedicado a la planificación y documentación, y más tiempo dedicado a la codificación y el desarrollo de pruebas automatizadas . Los enfoques más "extremos" también promueven las pruebas continuas a lo largo del ciclo de vida del desarrollo, además de tener un producto en funcionamiento (o libre de errores) en todo momento. Los enfoques más estructurados o basados ​​en " cascada " intentan evaluar la mayoría de los riesgos y desarrollar un plan detallado para el software antes de que comience la implementación (codificación), y evitan cambios de diseño significativos y la codificación en etapas posteriores de la planificación del ciclo de vida del desarrollo del software. .

Existen ventajas y desventajas significativas en las diversas metodologías, y el mejor enfoque para resolver un problema utilizando software a menudo dependerá del tipo de problema. Si el problema se comprende bien y el trabajo se puede planificar eficazmente con anticipación, el enfoque más basado en "cascada" puede funcionar mejor. Si, por otro lado, el problema es único (al menos para el equipo de desarrollo) y la estructura del software no se puede imaginar fácilmente, entonces un enfoque incremental más "extremo" puede funcionar mejor.

Actividades de desarrollo de software

Identificación de necesidad

Las fuentes de ideas para productos de software son abundantes. Estas ideas pueden provenir de estudios de mercado, incluidos los datos demográficos de nuevos clientes potenciales, clientes existentes, prospectos de ventas que rechazaron el producto, otro personal interno de desarrollo de software o un tercero creativo. Las ideas para productos de software generalmente son evaluadas primero por el personal de marketing para determinar su viabilidad económica, su adecuación a los canales de distribución existentes, los posibles efectos en las líneas de productos existentes, las características requeridas y el ajuste con los objetivos de marketing de la empresa. En una fase de evaluación de marketing, se evalúan los supuestos de costo y tiempo. Se toma una decisión al principio de la primera fase sobre si, basándose en la información más detallada generada por el personal de marketing y desarrollo, el proyecto debe continuar. ^[4]

En el libro "Grandes debates sobre software" , Alan M. Davis afirma en el capítulo "Requisitos" , subcapítulo "La pieza que falta en el desarrollo de software"

Los estudiantes de ingeniería aprenden ingeniería y rara vez están expuestos a las finanzas o el marketing. Los estudiantes de marketing aprenden marketing y rara vez están expuestos a las finanzas o la ingeniería. La mayoría de nosotros nos convertimos en especialistas en una sola área. Para complicar las cosas, pocos de nosotros conocemos a personas interdisciplinarias en la fuerza laboral, por lo que hay pocos roles que imitar. Sin embargo, la planificación de productos de software es fundamental para el éxito del desarrollo y requiere absolutamente el conocimiento de múltiples disciplinas. ^[5]

Debido a que el desarrollo de software puede implicar comprometer o ir más allá de lo requerido por el cliente, un proyecto de desarrollo de software puede desviarse hacia preocupaciones menos técnicas como recursos humanos , gestión de riesgos , propiedad intelectual , presupuestos , gestión de crisis , etc. función del desarrollo empresarial para superponerse con el desarrollo de software.

Proceso de planificación

La planificación es un objetivo de todas y cada una de las actividades, donde queremos descubrir cosas que pertenecen al proyecto. Una tarea importante en la creación de un programa de software es extraer los requisitos o el análisis de requisitos . ^{[6] Los} clientes suelen tener una idea abstracta de lo que quieren como resultado final, pero no saben qué debería hacer el software . Los ingenieros de software calificados y experimentados reconocen requisitos incompletos, ambiguos o incluso contradictorios en este punto. La demostración frecuente de código en vivo puede ayudar a reducir el riesgo de que los requisitos sean incorrectos.

"Aunque se pone mucho esfuerzo en la fase de requisitos para garantizar que los requisitos sean completos y consistentes, rara vez ese es el caso; dejando la fase de diseño de software como la más influyente cuando se trata de minimizar los efectos de requisitos nuevos o cambiantes. Volatilidad de requisitos es un desafío porque impactan los esfuerzos de desarrollo futuros o ya en marcha ". ^[7]

Una vez que se recopilan los requisitos generales del cliente, se debe determinar y establecer claramente un análisis del alcance del desarrollo. A esto se le suele llamar documento de alcance.

Diseño

Una vez establecidos los requisitos, el diseño del software puede establecerse en un documento de diseño de software . Esto implica un diseño preliminar o de alto nivel de los módulos principales con una imagen general (como un diagrama de bloques ) de cómo encajan las piezas. El idioma, el sistema operativo y los componentes de hardware deben conocerse en este momento. Luego, se crea un diseño detallado o de bajo nivel, tal vez con prototipos como prueba de concepto o para confirmar los requisitos.

Implementación, prueba y documentación

La implementación es la parte del proceso en la que los ingenieros de software realmente programan el código para el proyecto.

La prueba de software es una fase integral e importante del proceso de desarrollo de software. Esta parte del proceso asegura que los defectos se reconozcan lo antes posible. En algunos procesos, generalmente conocidos como desarrollo impulsado por pruebas, las pruebas se pueden desarrollar justo antes de la implementación y sirven como guía para la corrección de la implementación.

La documentación del diseño interno del software con el fin de realizar un mantenimiento y una mejora futuros se realiza durante todo el desarrollo. Esto también puede incluir la escritura de una API , ya sea externa o interna. El proceso de ingeniería de software elegido por el equipo de desarrollo determinará cuánta documentación interna (si corresponde) es necesaria. Los modelos basados ​​en planes (por ejemplo, Waterfall ) generalmente producen más documentación que los modelos ágiles .

Despliegue y mantenimiento

La implementación comienza directamente después de que el código se prueba adecuadamente, se aprueba para su lanzamiento y se vende o distribuye de otro modo en un entorno de producción. Esto puede implicar instalación, personalización (por ejemplo, mediante el establecimiento de parámetros a los valores del cliente), pruebas y posiblemente un período prolongado de evaluación. ^{[ cita requerida ]}

La capacitación y el soporte del software son importantes, ya que el software solo es efectivo si se usa correctamente. ^{[ cita requerida ]}

Mantener y mejorar el software para hacer frente a las fallas o los requisitos recién descubiertos puede requerir mucho tiempo y esfuerzo, ya que los requisitos no cumplidos pueden obligar a rediseñar el software. ^{[ cita requerida ]} . En la mayoría de los casos, se requiere un mantenimiento periódico para solucionar los problemas notificados y mantener el software en funcionamiento.

Subtemas

Ver modelo

La matriz de puntos de vista y perspectivas de TEAF .

Un modelo de vista es un marco que proporciona los puntos de vista sobre el sistema y su entorno , para ser utilizados en el proceso de desarrollo de software . Es una representación gráfica de la semántica subyacente de una vista.

El propósito de los puntos de vista y puntos de vista es permitir que los ingenieros humanos comprendan sistemas muy complejos y organicen los elementos del problema en torno a dominios de experiencia . En la ingeniería de sistemas físicamente intensivos, los puntos de vista a menudo corresponden a capacidades y responsabilidades dentro de la organización de ingeniería. ^[8]

Las especificaciones del sistema más complejas son tan extensas que ninguna persona puede comprender completamente todos los aspectos de las especificaciones. Por otra parte, todos tenemos intereses diferentes en un sistema dado y diferentes razones para examinar el sistema de 's especificaciones . Un ejecutivo de negocios hará diferentes preguntas sobre la estructura de un sistema de las que haría un implementador de sistemas. El concepto de marco de puntos de vista, por lo tanto, es proporcionar puntos de vista separados en la especificación de un sistema complejo dado. Cada uno de estos puntos de vista satisface a una audiencia con interés en algún conjunto de aspectos del sistema. Asociado con cada punto de vista hay un lenguaje de puntos de vista que optimiza el vocabulario y la presentación para la audiencia de ese punto de vista.

Modelado de datos y procesos de negocio

La representación gráfica del estado actual de la información proporciona un medio muy eficaz para presentar información tanto a los usuarios como a los desarrolladores del sistema .

ejemplo de la interacción entre procesos de negocio y modelos de datos. ^[9]

• Un modelo de negocio ilustra las funciones asociadas con el proceso de negocio que se está modelando y las organizaciones que realizan estas funciones. Al representar las actividades y los flujos de información, se crea una base para visualizar, definir, comprender y validar la naturaleza de un proceso.
• Un modelo de datos proporciona los detalles de la información que se almacenará y es de uso principal cuando el producto final es la generación de código de software de computadora para una aplicación o la preparación de una especificación funcional para ayudar en la decisión de hacer o comprar un software de computadora . Consulte la figura de la derecha para ver un ejemplo de la interacción entre el proceso empresarial y los modelos de datos. ^[9]

Por lo general, un modelo se crea después de realizar una entrevista, lo que se conoce como análisis comercial . La entrevista consiste en un facilitador que hace una serie de preguntas diseñadas para extraer la información requerida que describe un proceso. El entrevistador se denomina facilitador para enfatizar que son los participantes quienes brindan la información. El facilitador debe tener algún conocimiento del proceso de interés, pero esto no es tan importante como tener una metodología estructurada mediante la cual se le hacen las preguntas al experto en el proceso. La metodología es importante porque, por lo general, un equipo de facilitadores recopila información en toda la instalación y los resultados de la información de todos los entrevistadores deben coincidir una vez completados. ^[9]

Los modelos se desarrollan definiendo el estado actual del proceso, en cuyo caso el producto final se denomina modelo de instantánea "tal cual", o una colección de ideas de lo que debe contener el proceso, lo que da como resultado un "qué se puede -ser "modelo. La generación de modelos de procesos y datos se puede utilizar para determinar si los procesos y sistemas de información existentes son sólidos y solo necesitan modificaciones o mejoras menores, o si se requiere una reingeniería como acción correctiva. La creación de modelos comerciales es más que una forma de visualizar o automatizar su proceso de información. El análisis se puede utilizar para remodelar fundamentalmente la forma en que su empresa u organización realiza sus operaciones. ^[9]

Ingeniería de software asistida por computadora

La ingeniería de software asistida por computadora (CASE), en el campo de la ingeniería de software , es la aplicación científica de un conjunto de herramientas y métodos de software para el desarrollo de software que da como resultado productos de software de alta calidad, libres de defectos y mantenibles. ^[10] También se refiere a métodos para el desarrollo de sistemas de información junto con herramientas automatizadas que se pueden utilizar en el proceso de desarrollo de software. ^[11] El término "ingeniería de software asistida por computadora" (CASE) puede referirse al software utilizado para el desarrollo automatizado de software de sistemas , es decir, código de computadora. Las funciones CASE incluyen análisis, diseño y programación. Las herramientas CASE automatizan los métodos para diseñar, documentar y producir código informático estructurado en el lenguaje de programación deseado . ^[12]

Dos ideas clave de la ingeniería de sistemas de software asistida por computadora (CASE) son: ^[13]

• Fomentar la asistencia informática en los procesos de desarrollo y mantenimiento de software , y
• Un enfoque de ingeniería para el desarrollo y mantenimiento de software.

Existen herramientas CASE típicas para la gestión de la configuración , el modelado de datos , la transformación de modelos , la refactorización y la generación de código fuente .

Entorno de desarrollo integrado

Anjuta , un IDE de C y C ++ para el entorno GNOME

Un entorno de desarrollo integrado (IDE), también conocido como entorno de diseño integrado o entorno de depuración integrado, es una aplicación de software que proporciona instalaciones completas a los programadores informáticos para el desarrollo de software. Un IDE normalmente consta de:

• Editor de código fuente ,
• Compilador o intérprete ,
• Cree herramientas de automatización y
• Depurador (normalmente).

Los IDE están diseñados para maximizar la productividad del programador al proporcionar componentes muy unidos con interfaces de usuario similares . Normalmente, un IDE está dedicado a un lenguaje de programación específico , para proporcionar un conjunto de características que se asemeje más a los paradigmas de programación del lenguaje.

Lenguaje de modelado

Un lenguaje de modelado es cualquier lenguaje artificial que se puede usar para expresar información o conocimiento o sistemas en una estructura que está definida por un conjunto consistente de reglas. Las reglas se utilizan para interpretar el significado de los componentes de la estructura. Un lenguaje de modelado puede ser gráfico o textual. ^{[14] Los} lenguajes de modelado gráfico utilizan técnicas de diagrama con símbolos con nombre que representan conceptos y líneas que conectan los símbolos y que representan relaciones y varias otras anotaciones gráficas para representar restricciones. Los lenguajes de modelado textual suelen utilizar palabras clave estandarizadas acompañadas de parámetros para crear expresiones interpretables por computadora.

Ejemplos de lenguajes de modelado gráfico en el campo de la ingeniería de software son:

• La notación de modelado de procesos de negocio (BPMN, y la forma XML BPML) es un ejemplo de un lenguaje de modelado de procesos .
• EXPRESS y EXPRESS-G (ISO 10303-11) es un lenguaje de modelado de datos de uso general estándar internacional .
• El lenguaje de modelado empresarial extendido (EEML) se usa comúnmente para el modelado de procesos de negocios en todas las capas.
• El diagrama de flujo es una representación esquemática de un algoritmo o un proceso paso a paso,
• Lenguaje de modelado Fundamental Modeling Concepts (FMC) para sistemas intensivos en software.
• IDEF es una familia de lenguajes de modelado, los más notables de los cuales incluyen IDEF0 para modelado funcional, IDEF1X para modelado de información e IDEF5 para modelado de ontologías.
• LePUS3 es un lenguaje de descripción de diseño visual orientado a objetos y un lenguaje de especificación formal que es adecuado principalmente para modelar grandes programas y patrones de diseño orientados a objetos ( Java , C ++ , C # ) .
• El lenguaje de especificación y descripción (SDL) es un lenguaje de especificación destinado a la especificación y descripción inequívocas del comportamiento de sistemas reactivos y distribuidos.
• El lenguaje de modelado unificado (UML) es un lenguaje de modelado de propósito general que es un estándar de la industria para especificar sistemas con uso intensivo de software. UML 2.0, la versión actual, admite trece técnicas de diagrama diferentes y tiene un amplio soporte de herramientas.

No todos los lenguajes de modelado son ejecutables, y para aquellos que lo son, usarlos no significa necesariamente que los programadores ya no sean necesarios. Por el contrario, los lenguajes de modelado ejecutables están destinados a amplificar la productividad de los programadores expertos, de modo que puedan abordar problemas más difíciles, como la computación paralela y los sistemas distribuidos .

Paradigma de programación

Un paradigma de programación es un estilo fundamental de programación de computadoras , que generalmente no está dictado por la metodología de gestión de proyectos (como cascada o ágil). Los paradigmas difieren en los conceptos y abstracciones utilizados para representar los elementos de un programa (como objetos, funciones, variables, restricciones) y los pasos que componen un cálculo (como asignaciones, evaluación, continuaciones, flujos de datos). A veces, los conceptos afirmados por el paradigma se utilizan de forma cooperativa en el diseño de la arquitectura del sistema de alto nivel; en otros casos, el alcance del paradigma de programación se limita a la estructura interna de un programa o módulo en particular.

Un lenguaje de programación puede soportar múltiples paradigmas . Por ejemplo, los programas escritos en C ++ u Object Pascal pueden ser puramente procedimentales , o puramente orientados a objetos , o contener elementos de ambos paradigmas. Los diseñadores y programadores de software deciden cómo utilizar esos elementos paradigmáticos. En la programación orientada a objetos , los programadores pueden pensar en un programa como una colección de objetos que interactúan, mientras que en la programación funcional, un programa puede considerarse como una secuencia de evaluaciones de funciones sin estado. Al programar computadoras o sistemas con muchos procesadores, la programación orientada a procesos permite a los programadores pensar en las aplicaciones como conjuntos de procesos concurrentes que actúan sobre estructuras de datos compartidas lógicamente .

Así como diferentes grupos en ingeniería de software abogan por diferentes metodologías , los diferentes lenguajes de programación abogan por diferentes paradigmas de programación . Algunos lenguajes están diseñados para admitir un paradigma ( Smalltalk admite programación orientada a objetos, Haskell admite programación funcional), mientras que otros lenguajes de programación admiten múltiples paradigmas (como Object Pascal , C ++ , C # , Visual Basic , Common Lisp , Scheme , Python , Ruby y Oz ).

Muchos paradigmas de programación son tan conocidos por los métodos que prohíben como por los que permiten. Por ejemplo, la programación funcional pura prohíbe el uso de efectos secundarios ; la programación estructurada prohíbe el uso de sentencias goto . En parte por esta razón, los nuevos paradigmas a menudo son considerados doctrinarios o demasiado rígidos por quienes están acostumbrados a estilos anteriores. ^{[ cita requerida ]} Evitar ciertos métodos puede hacer que sea más fácil probar teoremas sobre la corrección de un programa, o simplemente comprender su comportamiento.

Ejemplos de paradigmas de alto nivel incluyen:

• Desarrollo de software orientado a aspectos
• Modelado específico de dominio
• Ingeniería basada en modelos
• Metodologías de programación orientadas a objetos
  • Grady Booch 's orientado a objetos de diseño (OOD), también conocido como análisis orientado a objetos y diseño (OOAD). El modelo de Booch incluye seis diagramas: clase, objeto, transición de estado, interacción, módulo y proceso. ^[15]
• Ingeniería de software basada en búsquedas
• Modelado orientado a servicios
• Programación estructurada
• Diseño de arriba hacia abajo y de abajo hacia arriba
  • Programación descendente : desarrollada en la década de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth ) en programación estructurada desarrollada .

Reutilización de software

Una definición de reutilización de software es el proceso de creación de software a partir de componentes de software predefinidos. Un enfoque de reutilización de software busca aumentar o maximizar el uso de artefactos de software existentes en el ciclo de vida del desarrollo de software .
Los siguientes son algunos métodos comunes de reutilización de software:

• Un marco de software es un diseño o implementación reutilizable para un sistema o subsistema de software.
• La ingeniería de software basada en componentes implica la integración de componentes existentes para crear una aplicación.
• Las arquitecturas orientadas a servicios o la programación orientada a servicios se basan en el concepto de componentes para proporcionar servicios en red, como los servicios web .
• Las líneas de productos de software buscan desarrollar software basado en un conjunto común de activos y procesos "centrales", con el fin de producir una gama de productos (o "aplicaciones") para un mercado en particular.
• API ( Interfaz de programación de aplicaciones , establece un conjunto de " definiciones de subrutinas, protocolos y herramientas para crear software de aplicaciones " que se pueden utilizar en futuras versiones.
• La documentación de código abierto, a través de bibliotecas como GitHub , proporciona código gratuito para que los desarrolladores de software lo reutilicen e implementen en nuevas aplicaciones o diseños.

Ver también

• Integración continua
• Software personalizado
• DevOps
• Especificacion funcional
• Programación de productividad
• Plano de software
• Diseño de software
• Estimación del esfuerzo de desarrollo de software
• Proceso de desarrollo de software
• Gestión de proyectos de software
• Lenguaje de especificación y descripción
• Experiencia de usuario
• Industria del software

Roles e industria

• Licenciatura en Ciencias en Tecnología de la Información
• Programador
• Ingeniero de software consultor
• Desarrollo de software offshore
• Desarrollador de software
• Ingeniero de software
• Editor de software

Aplicaciones especificas

• Desarrollo de videojuegos
• Desarrollo de aplicaciones web
• Ingeniería web
• Desarrollo de aplicaciones móviles

Referencias

1. "Desarrollo de aplicaciones (AppDev) definido y explicado" . Bestpricecomputers.co.uk. 2007-08-13 . Consultado el 5 de agosto de 2012 .
2. Asociados de DRM (2002). "Glosario de desarrollo de nuevos productos" . Consultado el 29 de octubre de 2006 .
3. Metodologías de desarrollo de sistemas para comercio electrónico habilitado para la web: un marco de personalización Linda V. Knight (Universidad DePaul, EE. UU.), Theresa A. Steinbach (Universidad DePaul, EE. UU.) Y Vince Kellen (Blue Wolf, EE. UU.)
4. Joseph M. Morris (2001). Contabilidad de la industria del software . p.1.10
5. Alan M. Davis. Great Software Debates (8 de octubre de 2004), págs: 125-128 Wiley-IEEE Computer Society Press
6. Ralph, P. y Wand, Y. Una propuesta para una definición formal del concepto de diseño . En, Lyytinen, K., Loucopoulos, P., Mylopoulos, J. y Robinson, W., (eds.), Ingeniería de requisitos de diseño: una perspectiva de diez años: Springer-Verlag, 2009, págs. 103-136
7. Otero, Carlos. "Desafíos del diseño de software" . Mejora del rendimiento de TI . Taylor & Francis LLC . Consultado el 19 de octubre de 2017 .
8. Edward J. Barkmeyer ea (2003). Conceptos para la automatización de la integración de sistemas NIST 2003.
9. Paul R. Smith y Richard Sarfaty (1993). Creación de un plan estratégico para la gestión de la configuración utilizando herramientas de Ingeniería de Software Asistida por Computadora (CASE). Documento para 1993 DOE nacional / Grupo de usuarios de CAD / CAE de contratistas e instalaciones.
10. Kuhn, DL (1989). "Seleccionar y utilizar eficazmente una herramienta de ingeniería de software asistida por ordenador". Simposio anual de computadoras Westinghouse; 6-7 de noviembre de 1989; Pittsburgh, PA (Estados Unidos); Proyecto DOE.
11. P. Loucopoulos y V. Karakostas (1995). Ingeniería de Requisitos del Sistema . McGraw-Hill.
12. CASE Archivado el 18 de febrero de 2012 en la definición de Wayback Machine en: Telecom Glossary 2000 Archivado el 22 de noviembre de 2005 en Wayback Machine . Consultado el 26 de octubre de 2008.
13. K. Robinson (1992). Poniendo la Ingeniería de Software en CASE . Nueva York: John Wiley and Sons Inc.
14. Xiao él (2007). " Un metamodelo para la notación de lenguajes de modelado gráfico ". En: Congreso de Software y Aplicaciones Informáticas, 2007. COMPSAC 2007 - Vol. 1. 31st Annual International , Volumen 1, Edición, 24-27 de julio de 2007, págs. 219-224.
15. Merx, Georges G .; Norman, Ronald J. (2006). Ingeniería de software unificada con Java . Prentice-Hall, Inc. pág. 201 . ISBN 0130473766.

Otras lecturas

• Kit, Edward (1992). Pruebas de software en el mundo real . Addison-Wesley Professional. ISBN 0201877562.
• McCarthy, Jim (1995). Dinámica del desarrollo de software . Microsoft Press. ISBN 1556158238.
• Conde, Dan (2002). Gestión de productos de software: Gestión del desarrollo de software desde la idea hasta el producto, desde el marketing hasta las ventas . Libros Aspatore. ISBN 1587622025.
• Davis, AM (2005). Gestión de requisitos suficiente: donde el desarrollo de software se encuentra con el marketing . Dorset House Publishing Company, Incorporated. ISBN 0932633641.
• Hasted, Edward (2005). Software que vende: una guía práctica para desarrollar y comercializar su proyecto de software . Wiley Publishing. ISBN 0764597833.
• Hohmann, Luke (2003). Más allá de la arquitectura de software: creación y mantenimiento de soluciones ganadoras . Addison-Wesley Professional. ISBN 0201775948.
• John W. Horch (2005). "Dos orientaciones sobre cómo trabajar con objetos". En: Software IEEE . vol. 12, no. 2, págs. 117-118, marzo de 1995.
• Rittinghouse, John (2003). Gestión de entregables de software: una metodología de gestión de desarrollo de software . Prensa digital. ISBN 155558313X.
• Wiegers, Karl E. (2005). Más sobre los requisitos de software: cuestiones espinosas y consejos prácticos . Microsoft Press. ISBN 0735622671.
• Wysocki, Robert K. (2006). Gestión eficaz de proyectos de software . Wiley. ISBN 0764596365.