HispaSWEBOK Borrador

Guía de la Ingeniería de Software
Cuerpo de conocimientos
Un hombre de paja Versión
Pierre Bourque, Universidad de Quebec en Montreal Robert
Dupuis, Universidad de Quebec en Montreal Alain Abran,
Universidad de Quebec en Montreal James W. Moore, La
Corporación MITRE Leonard Tripp, IEEE Computer Society
Karen Shyne, The Boeing Company Bryan Pflug, The Boeing
Company Marcela Maya, Universidad de Quebec en Montreal
individuo Tremblay, Universidad de Quebec en Montreal
de septiembre de de 1998
Guía de la Ingeniería de Software de Administración de Conocimiento - Un hombre de paja Versión yo
Resumen ejecutivo
Consenso sobre un cuerpo de conocimientos Core es crucial
La ingeniería de software no ha alcanzado el estado de una disciplina de ingeniería legítimo y una profesión reconocida. Desde 1993, el
IEEE Computer Society y la ACM han estado promoviendo activamente la ingeniería de software como una profesión, especialmente a
través de su participación en el Comité Consultivo de la IEEE Computer conjunta y ACM para el Establecimiento de Ingeniería de Software
como profesión. El logro de consenso por la profesión en un cuerpo de la base de conocimiento es un hito clave en todas las disciplinas y ha
sido identificado por el Comité Directivo como cruciales para la evolución de la ingeniería de software hacia un estatus profesional. Este
informe, escrito bajo los auspicios de este Comité, es el primer paso de un proyecto de cuatro años diseñado para llegar a este consenso.
Enfoque en el conocimiento Generalmente Aceptados
El swebok es un término inclusivo que describe la suma de conocimientos dentro de la profesión de la ingeniería de software. Ya que por lo
general no es posible poner el cuerpo lleno de conocimiento de incluso una disciplina emergente, como la ingeniería de software, en un solo
documento, hay una necesidad de una guía para la Ingeniería de Software de Administración de Conocimiento. Esta guía tratará de identificar y
describir ese subconjunto del conjunto de conocimientos que es generalmente aceptado, a pesar de que los ingenieros de software no sólo
deberá tener conocimiento de la ingeniería de software, sino también, por supuesto, en otros, las disciplinas relacionadas.
Guía de la Ingeniería de Software de Administración de Proyecto de Conocimiento
Los objetivos de la Guía para la Ingeniería de Software de Administración de Conocimiento del proyecto son, por tanto, a:
?? caracterizar el contenido de la Ingeniería de Software de Administración de Conocimiento
?? proporcionar un acceso tópica en la Ingeniería de Software de Administración de Conocimiento;
?? promover una visión coherente de la ingeniería de software en todo el mundo;
?? clarificar el lugar de, y establecer los límites de, ingeniería de software con respecto a otras disciplinas tales
como la informática, gestión de proyectos, ingeniería eléctrica y matemáticas;
?? proporcionar una base para el desarrollo curricular y la certificación individual y el material de la concesión de licencias. El público objetivo de la Guía
de la Ingeniería de Software de Administración de Conocimiento incluye: organizaciones públicas y privadas, la práctica de los ingenieros de software,
creadores de políticas públicas, sociedades profesionales, estudiantes y educadores, así como investigadores.
Se propone un enfoque de tres fases para el desarrollo de la Guía para la Ingeniería de Software de Administración de Conocimiento. Estas tres
fases se producen, respectivamente, el “hombre de paja”, “Hombre de Piedra” y las versiones de “Iron Man” de la Guía.
Fase 1: Paja Hombre Versión

Los objetivos de la primera fase se van a definir la estrategia, para entregar lo que se conoce como la versión del hombre de paja de la
Guía, y recoger el impulso en la profesión para el proyecto. El presente informe constituye esta versión del hombre de paja.
El objetivo principal de este informe inicial es proponer una lista de áreas de conocimiento de la Guía para la Ingeniería de Software de Administración de
Conocimiento (SWEBOK). Este informe también propone un proyecto de lista de las disciplinas que interactúan con la ingeniería de software. Como su
nombre lo indica, esta versión del hombre de paja está destinado a ser cuestionado y para estimular un debate vigoroso.
Las áreas de conocimiento son los principales componentes de una disciplina, o sub-campos de estudio. Disciplinas relacionadas son las otras
disciplinas con las que la ingeniería de software tiene una intersección no vacía o comparte una frontera común.
© IEEE Computer Society de septiembre de de 1998

Guía de la Ingeniería de Software de Administración de Conocimiento - Un hombre de paja Versión ii
Con el fin de proponer áreas de conocimiento y disciplinas relacionadas de “generalmente aceptado” el conocimiento y hacerlo sobre la base de
reconocidas fuentes, públicas y verificables de la información, se decidió que las tablas de contenido de los libros de texto de ingeniería de
software en general, los planes de estudios de pre y post grado programas de ingeniería de software, así como los criterios de admisión para los
programas graduados constituirían la entrada a nuestro análisis. Se examinaron un total de 24 libros de texto y 29 programas.
A los efectos de esta versión del hombre de paja, una zona potencial de conocimiento tuvo que ser mencionado en la tabla de contenido de al menos una cuarta
parte de los libros de texto de la muestra para calificar como un área de conocimiento propuesto. El 12207 norma ISO / IEC en procesos de ciclo de vida del
software se utiliza como la base y el vocabulario para la clasificación de los diferentes temas relacionados con el ciclo de la vida. También se consideraron una
serie de otros temas que no están relacionados con el ciclo de la vida.
La lista de áreas de conocimiento propuestos en base a la norma ISO / IEC 12207 es:
?? Proceso de desarrollo ?? Gestión de la configuración
?? Análisis de requerimientos ?? Seguro de calidad
?? Diseño detallado ?? Verificación y validación
?? Codificación ?? mejora de procesos
?? Pruebas
?? Proceso de mantenimiento
La lista de áreas de conocimiento propuestos que no convergen bien con la norma ISO / IEC 12207 es:
?? Los métodos de desarrollo de software ?? Entornos de desarrollo de software
- Orientado a objetos ?? Ingeniería de Software general y definición
- Métodos formales ?? Las métricas de medición /
- prototipado ?? La fiabilidad del software
La lista de propuestas disciplinas relacionadas es:
?? Ciencias de la Computación ?? administración
?? Gestión de proyectos ?? Ciencia
?? Ingenieria Eléctrica ?? Otras disciplinas de ingeniería
?? Matemáticas ?? Ciencias cognitivas
?? Telecomunicaciones / Redes
Fase 2: Hombre de Piedra Versión
Las entregas de la segunda fase (Hombre de Piedra) bajo la dirección del Consejo Asesor Industrial son:
?? una lista aprobada de Áreas de Conocimiento de la ingeniería de software;
?? una lista aprobada de temas y materiales de referencia relevantes para cada área de conocimiento;
?? una lista aprobada de disciplinas relacionadas con la ingeniería de software, y las áreas de conocimiento y temas
tumbado en el cruce de Ingeniería de Software y uno o más de estas disciplinas relacionadas. Para garantizar la pertinencia de la Guía,
para continuar la construcción de consensos y el impulso de la Guía y favorecer su absorción rápida en el mercado, tres componentes son
clave para la estrategia propuesta de la fase de piedra hombre: un Consejo Asesor Industrial, una serie de subcomités especializados y un
amplio proceso de recopilación de comentarios y la creación de consenso.
El Consejo Asesor Industrial incluirá los principales representantes de la industria, las principales asociaciones profesionales, organismos de normalización
internacionales y el mundo académico, así como autores de libros de texto ampliamente vendidos en

Guía de la Ingeniería de Software de Administración de Conocimiento - Un hombre de paja Versión iii
Ingeniería de software. Será responsable, entre otras cosas, para la estrategia general del proyecto, para los criterios de selección de las áreas de
conocimiento y las disciplinas relacionadas, así como los criterios de selección de los temas incluidos en cada área de conocimiento, para la
selección de los presidentes de los subcomités de cada área de conocimiento y para la promoción de la Guía para el SWEBOK.
Fase 3: Iron Man Versión

Una versión posterior del hombre del hierro debe ser completado aproximadamente dos años después de la versión de piedra hombre. El
desarrollo de esta versión, una vez más, probablemente implicará un Consejo Asesor Industrial y varios paneles de expertos. Sin embargo, un
proceso de revisión y consenso aún más exhaustivo para recoger comentarios y puntos de vista de los miembros de la profesión tendrá que
ser definido para esta fase del proyecto.
La participación de todas las partes es crítico
Se requerirá muchas horas de trabajo, debate y búsqueda de consenso para desarrollar el Hombre de Piedra y las posteriores versiones de Iron
Man de la Guía de la Ingeniería de Software de Administración de Conocimiento. El logro de un consenso sobre el cuerpo de la base de
conocimiento es un hito clave en todas las disciplinas y es fundamental para la evolución de la ingeniería de software hacia un estatus profesional.
La participación de todas las partes, la industria,
asociaciones profesionales, organismos de establecimiento de normas y el mundo académico, es fundamental para asegurar la relevancia y la credibilidad de los resultados, y
para una absorción rápida de los resultados.

Guía de la Ingeniería de Software de Administración de Conocimiento - Un hombre de paja Versión iv
TABLA DE CONTENIDO
Resumen ejecutivo ................................................ .................................................. ............................... i Agradecimientos .................
.................................................. .................................................. .............. 1
1. Introducción ............................................... .................................................. ....................................... 2
2. La Guía de la Ingeniería de Software de Administración de Proyecto Conocimiento ...................................... .............. 3
3. Contexto y Relaciones ............................................. .................................................. ................... 8
4. Metodología de Desarrollo para la identificación de áreas de conocimiento y disciplinas relacionadas ........................ 17
5. Áreas de Conocimiento propuestas ............................................. .................................................. .............. 23
6. Propuestas de disciplinas relacionadas con ............................................. .................................................. ............ 26
7. Resumen y próximos pasos ............................................ .................................................. ................... 27
8. Referencias ............................................... .................................................. ...................................... 30
9. Apéndices ............................................... .................................................. ..................................... 32
Apéndice A. Lista de libros de texto generales y tutoriales sobre Ingeniería de Software ............................ 33
Apéndice B. URL de los programas de grado y de postgrado en Ingeniería de Software ............... 34
Apéndice C. Los libros de texto generales y tutoriales sobre Ingeniería de Software - Clasificación
de la Tabla de Contenidos Entradas Según Áreas de Conocimiento potenciales ...................... 37
Apéndice D. Programas de Licenciatura en Ingeniería de Software - Clasificación de los cursos

De acuerdo con Áreas de Conocimiento potenciales ............................................. ..................... 54
Apéndice E. Programas de Licenciatura en Ingeniería de Software - Clasificación de los cursos por

La disciplina relacionada ................................................ .................................................. 59 ..
Apéndice F. Programas de Posgrado en Ingeniería de Software - Requisitos de Admisión

por disciplina relacionada ............................................... ................................................ 64
Apéndice G. Programas de Posgrado en Ingeniería de Software - Clasificación de los cursos

De acuerdo con Áreas de Conocimiento potenciales ............................................. ..................... 69
Apéndice H. Programas de Posgrado en Ingeniería de Software - Clasificación de los cursos

por disciplina relacionada ............................................... ................................................ 84
Apéndice I. Proyecto de Clasificación de conocimientos sobre métodos formal basado en la propuesta

Cuatro Categoría esquema .............................................. .............................................. 96
Apéndice J. Información adicional sobre otro cuerpo de Propuestas Conocimiento ............................... 105

Guía de la Ingeniería de Software de Administración de Conocimiento - Un hombre de paja Versión 1
Expresiones de gratitud
Los autores desean agradecer a los siguientes revisores para que nos proporciona valiosos comentarios y sugerencias sobre la
base de un borrador de este documento. A los críticos están en orden alfabético: Denis Bourdeau (Bell Canada), Gilles Gauthier
(Universidad de Quebec en Montreal), John Harauz (Ontario Hydro), David Longstreet (Longstreet Consulting), Stephen MacDonnell
(Universidad de Otago), Serge Oligny (Université du Québec à Montréal), Lyn Vanhoozer (El MITRE Corporation), Dolores Wallace
(Instituto Nacional de Estándares y Tecnología) y Laurie Werth (Universidad de Texas en Austin). Esto no implica, sin embargo, que
estos revisores o sus organizaciones están de acuerdo con las posiciones y propuestas presentadas en este documento.
La financiación de este trabajo fue proporcionado por el IEEE Computer Society y el Laboratorio de Investigación de Software de Gestión de
Ingeniería de la Universidad de Quebec en Montreal. Este laboratorio es apoyado a través de una asociación con Bell Canada. financiación
adicional para el laboratorio es proporcionada por las Ciencias Naturales e Ingeniería de Investigación de Canadá.

1. Introducción
A pesar de los millones de profesionales de software en todo el mundo y la presencia ubicua de software en nuestra sociedad, la ingeniería
de software no ha alcanzado el estado de una disciplina de ingeniería legítimo y una profesión reconocida.
Desde 1993, el IEEE Computer Society y la ACM han estado promoviendo activamente la ingeniería de software como una profesión y una
disciplina de ingeniería legítima, especialmente a través de su participación en el Comité Consultivo de la IEEE Computer conjunta y ACM para el
Establecimiento de Ingeniería de Software como profesión. Una versión preliminar de los criterios de acreditación de programas de ingeniería de
software universitarios [1] y un proyecto de Código de Ética para los ingenieros de software [2] ya se han producido.
El logro de consenso por la profesión en un cuerpo de la base de conocimiento es un hito clave en todas las disciplinas y ha sido identificado
por el Comité Directivo como cruciales para la evolución de la ingeniería de software hacia un estatus profesional. Este informe, escrito bajo
los auspicios de este Comité, es el primer paso de un proyecto de cuatro años diseñado para llegar a este consenso.
En otras disciplinas de la ingeniería, la acreditación de los programas de estudios universitarios y el otorgamiento de licencias y certificación de la práctica de
los profesionales se toman muy en serio 1. Estas actividades son vistos como críticos para la mejora constante de los profesionales y, por lo tanto, la mejora del
nivel de la práctica profesional. Reconocer un cuerpo de la base de conocimiento es fundamental para el desarrollo y la acreditación de los programas de
estudios universitarios y el otorgamiento de licencias y certificación de los profesionales.
El objetivo principal de este informe inicial es el de proponer un proyecto de lista de Áreas de Conocimiento de la Guía para la Ingeniería de Software de
Administración de Conocimiento (SWEBOK). Este informe también propone un proyecto de lista de las disciplinas que interactúan con la ingeniería de
software. Como su nombre lo indica, esta versión del hombre de paja está destinado a ser cuestionado y para estimular un debate vigoroso.
El informe comienza con una declaración de los objetivos del proyecto, su público objetivo y el desarrollo de tres fases propuesto y la creación
de consenso para la producción de los entregables. Capítulo 3 se analiza con más detalle el problema que se aborda y el razonamiento que
conduce a ella, otra agrupación de propuestas de conocimiento, así como el impacto previsto de los elementos subsecuentes. Esta es seguida
por una descripción en el capítulo 4 de la metodología utilizada para identificar las listas propuestas de áreas de conocimiento y disciplinas
relacionadas. Áreas de conocimiento y disciplinas relacionadas a continuación se proponen en los capítulos 5 y 6. En el informe se cierra con
algunas conclusiones breves y una discusión sobre los próximos pasos
1 Para una discusión más detallada sobre la acreditación de los programas de estudio universitario de ingeniería y el otorgamiento de licencias y certificación de
la práctica de los ingenieros, consulte los sitios web de la Junta de Acreditación de Ingeniería y Tecnología en www.abet.org o el Consejo Canadiense de Ingenieros Profesionales en
www.ccpe.ca

2. La Guía de la Ingeniería de Software de Administración de Proyecto de Conocimiento
Cuerpo de conocimientos
El swebok es un término inclusivo que describe la suma de conocimientos dentro de la profesión de la ingeniería de software. Al
igual que con otras profesiones como el derecho, la medicina y la contabilidad, el conjunto de conocimientos recae en los
profesionales y académicos que se aplican y hacerlo avanzar.
Guía para un conjunto de conocimientos
Ya que por lo general no es posible poner el cuerpo lleno de conocimiento de incluso una disciplina emergente, como la ingeniería de software, en un
solo documento, hay una necesidad de una guía para la Ingeniería de Software de Administración de Conocimiento. Esta guía tratará de identificar y
describir ese subconjunto del conjunto de conocimientos que es generalmente aceptado o, en otras palabras, el cuerpo de la base de conocimiento de
la disciplina.
swebok y
plan de estudios no son los mismos
Los ingenieros de software no sólo deberá tener conocimiento de lo que es específico de su disciplina, pero también, por supuesto, tienen que
saber mucho más. El objetivo de esta iniciativa no es, sin embargo, hacer un inventario de todo lo que los ingenieros de software deben saber,
sino para identificar lo que constituye el núcleo de la ingeniería de software. Es la responsabilidad de otras organizaciones e iniciativas implicadas
en la concesión de licencias y certificación de los profesionales y el desarrollo y la acreditación de los programas de estudio para definir lo que es
un ingeniero de software debe conocer la ingeniería de software fuera. Creemos que una distinción muy clara debe hacerse entre el swebok y el
contenido de los planes de estudio de ingeniería de software.
Objetivos del proyecto
Los objetivos de la Guía para la Ingeniería de Software de Administración de Conocimiento del proyecto son, por tanto, a:
• caracterizar el contenido de la Ingeniería de Software de Administración de Conocimiento;
• proporcionar un acceso tópica en la Ingeniería de Software de Administración de Conocimiento;
• promover una visión coherente de la ingeniería de software en todo el mundo;
• clarificar el lugar de, y establecer los límites de, ingeniería de software con respecto a otras disciplinas como la informática,
gestión de proyectos, ingeniería eléctrica y matemáticas;
• proporcionar una base para el desarrollo curricular y la certificación individual y el material de la concesión de licencias.
Público objetivo
El público objetivo de la Guía de la Ingeniería de Software de Administración de Conocimiento incluye:
• organizaciones públicas y privadas que deseen utilizar y promover una visión consistente de la ingeniería de software internamente, sobre todo en la
definición de la educación y la formación, la clasificación de puestos y las políticas de evaluación del desempeño;
• la práctica de los ingenieros de software que deseen mejorar sus competencias profesionales;
• creadores de políticas públicas que participan en la definición de reglas y directrices de concesión de licencias de ingeniería de software para los profesionales:
un consenso sobre una guía para la Ingeniería de Software de Administración de conocimiento es crucial para garantizar la coherencia de licenciamiento y
acreditación directrices y políticas a través de las fronteras nacionales y estatales;

• sociedades profesionales involucrados en la definición de pautas de acreditación de software programa universitario de ingeniería y normas de
certificación y directrices para los profesionales;
• estudiantes de ingeniería de software de aprendizaje de la disciplina;
• educadores y formadores que participan en la definición de programas de estudio y el contenido del curso;
• los investigadores que buscan un marco acordado cuando se habla de su trabajo.
Un enfoque de tres fases de desarrollo y de Consenso

Se propone el enfoque de tres fases descrito en la Figura 1 para desarrollar la Guía para la Ingeniería de Software de Administración de
Conocimiento. Se espera que la duración total de las tres fases de cuatro años. Estas tres fases se producen, respectivamente, el “hombre de
paja”, “Hombre de Piedra” y las versiones de “Iron Man” de la Guía.
Dos principios subyacen a este enfoque de tres fases:
- la transparencia: el proceso de desarrollo se publicó en sí y totalmente documentado;
- La creación de consenso: el proceso de desarrollo está diseñado para construir, con el tiempo, el consenso en la industria, entre las sociedades y los
organismos de normalización y en el mundo académico profesional.
Es en este espíritu que los canales de comunicación se mantienen constantemente abierta entre nuestro proyecto y el Grupo de Trabajo Conjunto
sobre Ingeniería de Software Plan de estudios que también se encuentra bajo los auspicios del Comité Directivo de la Sociedad IEEE Computer
conjunta y ACM para el Establecimiento de Ingeniería de Software como profesión.
Una fase de puesta en marcha para desarrollar una versión inicial de la Guía se inició al comienzo de 1998. Los objetivos de esta fase son
para definir la estrategia, para entregar lo que se conoce como la versión del hombre de paja de la Guía, y para tomar impulso en el profesión
para el proyecto. El presente informe constituye esta versión del hombre de paja. Como se describe en detalle en el capítulo 4, la
metodología adoptada utilizado para esta versión se basa en un análisis de un gran número de libros de texto de ingeniería de software,
ingeniería de programas de estudios de grado y de software de grado y los requisitos de admisión de graduados. Además, el marco utilizado
para analizar estos libros de texto y programas académicos es una norma conjunta ISO / IEC e IEEE sí que ha sido aprobada a través de un
proceso de consenso, revisión y votación rigurosa e internacional. En esencia, se puede decir que la versión del hombre de paja trata de
identificar donde ya hay consenso. La versión del hombre de paja servirá como entrada principal para la fase posterior “Hombre de Piedra”
del proyecto espera que termine a mediados de 1999. Los entregables de la fase de piedra hombre de este proyecto serán:
?? una lista de áreas de conocimiento de la ingeniería de software (áreas de conocimiento son los principales componentes de una
disciplina o subcampos de estudio).
?? una lista de temas y materiales de referencia relevantes para cada área de conocimiento;
?? una lista de las disciplinas relacionadas con la ingeniería de software, y las áreas de conocimiento y temas en el
cruce de Ingeniería de Software y uno o más de estas disciplinas relacionadas; Sin embargo, la versión de piedra El hombre no se apuntan a
cualquier material de referencia de una disciplina relacionada, a menos que se adapta específicamente a la ingeniería de software.
Para garantizar la pertinencia de la Guía, para continuar la construcción de consenso y el impulso de la Guía y favorecer su absorción rápida en
el mercado, son tres componentes clave de la estrategia propuesta de esta fase de piedra hombre. Son, como se muestra en la Figura 2, un
Consejo Asesor Industrial, una serie de subcomités especializados y un amplio proceso de recopilación de comentarios y la creación de
consenso.
El Consejo Asesor Industrial incluirá los principales representantes de la industria, las principales asociaciones profesionales, organismos internacionales
de normalización y el mundo académico, así como autores de libros de texto ampliamente vendidos en ingeniería de software. El proyecto de definición
de las responsabilidades del Consejo Asesor Industrial consiste en lo siguiente:
?? Revisar y aprobar la estrategia de alcance y desarrollo de la Guía para la Ingeniería de Software

Cuerpo de conocimientos;

?? Revisar y aprobar los criterios de selección de áreas de conocimiento;
?? Revisar y aprobar la lista de propuestas de áreas de conocimiento;
?? Revisar y aprobar los criterios de selección de las disciplinas relacionadas;
?? Revisar y aprobar la lista propuesta de disciplinas relacionadas;
?? Revisar y aprobar los criterios de selección y la lista de temas para cada área de conocimiento;
?? Revisar y aprobar los criterios de selección de materiales de referencia;
?? Revisar y aprobar la lista de presidentes de los subcomités;
?? Revisar y aprobar un amplio proceso de recopilación de comentarios y la creación de consenso para el Hombre de Piedra
versión;
?? Supervisar el amplio proceso de recopilación de comentarios y la creación de consenso para la versión de piedra hombre;
?? Ayudar en la promoción de la Guía para la Ingeniería de Software de Administración de Conocimiento. Se establecerá un número de
subcomités formados por expertos en la materia durante la fase de Piedra hombre y éstas se encargará de seleccionar el material de referencia
clave en la literatura de ingeniería de software existente, basado en criterios de selección de referencia predefinidos. Estas referencias podrían
ser capítulos de libros, artículos de revistas, informes públicos de la industria, etc. La incorporación de estos subcomités en el diseño de este
enfoque es un paso adicional en la construcción de consenso.
Para informar a los profesionales de ingeniería de software de la Guía, para promoverlo, para continuar la construcción de consenso y para
recoger los comentarios de una amplia muestra de profesionales, un amplio comentario proceso de recopilación y búsqueda de consenso también
serán llenados electrónicamente durante la fase de Piedra Hombre entre el miembros de la Sociedad de Computación y posiblemente otras
sociedades profesionales. El Consejo Asesor Industrial se asegurará de que el debido proceso es seguido con respecto a esta consulta y la etapa
de agrupamiento comentario-.
Una versión posterior del hombre del hierro debe ser completado aproximadamente dos años después de la versión de piedra hombre. El
desarrollo de esta versión, una vez más, probablemente implicará un Consejo Asesor Industrial y varios paneles de expertos. Sin
embargo, un proceso de revisión y consenso aún más exhaustivo para recoger comentarios y puntos de vista de los miembros de la
profesión tendrá que ser definido para esta fase del proyecto. Este proceso de revisión y consenso debe ser algo relacionado con el
proceso de desarrollo de estándares de ingeniería de software y revisión ya existente.
Para facilitar su amplia difusión, todas las versiones estarán disponibles sin costo en Internet.

Guía de la
SWEBOK
(Hombre de paja Version)
(Hombre de Piedra Version)
para la SWEBOK
Enfoque:
a-Recogida y Creación de Consenso
- Consejo Asesor Industrial
- Paneles de Expertos
- Guía del Proceso amplio comentario Guía de la SWEBOK
(Iron Man Version)
Enfoque:
- Los paneles de expertos
- Consejo Asesor Industrial

- CommentGathering exhaustiva y
Proceso de la concertación
1998 1999 2000 2001

»
Figura 1 un enfoque de tres fases para el desarrollo de la Guía para el SWEBOK

El hombre de paja Versión
Consejo Asesor Industrial El hombre de piedra Versión
Áreas de conocimiento y
disciplinas relacionadas
Integridad y cohesión
Revisión de Piedra en
progreso Subcomité de Especialistas
Versión hombre
Amplio Consenso proceso de

comentarios-Encuentro
Temas identificados y materiales
de referencia seleccionados
para cada área de
conocimiento
Figura 2 estrategia propuesta para el desarrollo del hombre Stone Version

3. Contexto y Relaciones
¿Qué es la ingeniería de software?
El IEEE Computer Society define como la ingeniería de software 2:
“(1) La aplicación de un enfoque disciplinado cuantificable sistemática, para el desarrollo, operación y mantenimiento de software; es
decir, la aplicación de la ingeniería de software.
(2) El estudio de los enfoques como en (1) “. [3]
¿Qué es una profesión reconocida?

Para la ingeniería de software que se conoce como una disciplina de ingeniería legítimo y una profesión reconocida, un consenso sobre un
cuerpo de la base de conocimiento es imprescindible. Este hecho está bien ilustrado por Starr [4] cuando define lo que puede considerarse una
disciplina legítima y una profesión reconocida. En su libro ganador Pulitzer-premio: en la historia de la profesión médica en los EE.UU., afirma
que:
“La legitimación de la autoridad profesional implica tres reclamaciones distintivos: en primer lugar, que el conocimiento y
competencia del profesional de haber sido validada por la comunidad de sus pares; en segundo lugar, que este conocimiento validado por
consenso se basa en fundamentos racionales, científicas; y en tercer lugar, que el juicio y el asesoramiento de los profesionales están orientados
a un conjunto de valores fundamentales, como la salud. Estos aspectos de la legitimidad se corresponden con los tipos de atributos - colegiales,
cognitivas y morales - por lo general citados en el término “profesión”. 3
La profesión de la ingeniería de software es aún inmaduro
El término “ingeniería de software” ahora ha estado en uso durante 30 años, desde que fue acuñado oficialmente en una conferencia de octubre 1968, celebrada en Garmisch,
Alemania [5]. Desde entonces, se han realizado considerables progresos. La evidencia de este progreso se puede encontrar en la lista de 24 libros de texto generales de
ingeniería de software que se encuentra en el Apéndice A. Además, el Apéndice B se enumeran 5 de pregrado y 24 programas de posgrado que se ofrecen ahora en ingeniería
de software y que fueron descritos encontrados en la World Wide Web. Una multitud de conferencias y talleres se dan en el tema de la ingeniería de software anual. A su vez, la
disciplina ha acumulado un número importante de normas nacionales e internacionales [6]. Este progreso no significa, por supuesto, implica que la ingeniería de software es,
como se practica actualmente por individuos o por organizaciones, a un nivel suficiente para asegurar resultados consistentes y fiables. La industria todavía está plagado de
costes y retrasos significativos. el software no fiable sigue siendo entregado, a menudo con consecuencias nefastas. Los proyectos se cancelan de forma regular o entregar sólo
un subconjunto de los beneficios esperados. Los costos de mantenimiento, mejor ejemplificadas por el insecto del año 2000, son muy a menudo prohibitivo. En 1996, Ford y
Gibbs [7] escribió un informe en profundidad sobre el nivel de madurez de la profesión de la ingeniería de software. Con el fin de analizar la madurez de una profesión de una
manera más objetiva y constructiva Los proyectos se cancelan de forma regular o entregar sólo un subconjunto de los beneficios esperados. Los costos de mantenimiento,
mejor ejemplificadas por el insecto del año 2000, son muy a menudo prohibitivo. En 1996, Ford y Gibbs [7] escribió un informe en profundidad sobre el nivel de madurez de la
profesión de la ingeniería de software. Con el fin de analizar la madurez de una profesión de una manera más objetiva y constructiva Los proyectos se cancelan de forma regular
o entregar sólo un subconjunto de los beneficios esperados. Los costos de mantenimiento, mejor ejemplificadas por el insecto del año 2000, son muy a menudo prohibitivo. En
1996, Ford y Gibbs [7] escribió un informe en profundidad sobre el nivel de madurez de la profesión de la ingeniería de software. Con el fin de analizar la madurez de una profesión de una manera más obj
2 Por supuesto, hay muchas otras definiciones de la ingeniería de software. Dado que este esfuerzo se origina a partir de un comité conjunto de la
ACM y la IEEE Computer Society y dado que esta definición fue acordada por un amplio consenso dentro de la Computer Society, parece razonable que comienzan de la misma. El
Consejo Asesor Industrial puede resultar inadecuada para los fines de la Guía para la Ingeniería de Software de Administración de Conocimiento o esta definición puede llegar a ser
insuficiente adelante en el proyecto
3
pag. 15.

y predecir mejor su evolución futura, empiezan proponiendo un modelo de su madurez en términos de ocho componentes de la
infraestructura. Estos componentes son:
- sistema de formación profesional inicial;
- Acreditación de los programas de educación profesional;
- Habilidades de los mecanismos de desarrollo para los profesionales que entran en la práctica;
- Certificación de los profesionales administrados por la profesión;
- La concesión de licencias de profesionales administrados por las autoridades gubernamentales;
- programas de desarrollo profesional para mantener la moneda de conocimientos y habilidades;
- Código ético;
- la sociedad profesional o sociedades.
Su informe indica que casi todos estos componentes han existido durante muchos años y están siendo continuamente mejorado para las
profesiones más establecidos como medicina, derecho, ingeniería, arquitectura y contabilidad. Luego analizan la profesión de la ingeniería
de software usando esta taxonomía de ocho componentes y llegan a la conclusión de que sólo los componentes de desarrollo y de la
sociedad profesional profesionales han avanzado más allá del nivel ad hoc. Por lo tanto, deducen que la profesión de la ingeniería de
software es aún inmaduro.
El creciente interés en la acreditación de programas, certificación y concesión de licencias
No es sin ninguna duda un creciente interés en la acreditación de programas universitarios y la concesión de licencias y la certificación de los
profesionales de software. El cortador de TI Diario publicado por Ed Yourdon dedicado recientemente un número entero a la certificación y
concesión de licencias de software profesionales [8]. En 1996, el Instituto de Ingenieros, Australia, comenzó a conceder la plena acreditación de
pregrado programas de ingeniería de software [9]. Algunos autores han declarado recientemente que nosotros en la industria del software mejor
que tomar estas cuestiones muy en serio, de lo contrario los funcionarios del gobierno hacerlo por sí mismos. Las siguientes citas de estos autores
ilustran su punto de vista así:
“Si la profesión no proporciona un mecanismo eficaz como la certificación para asegurar que sus practicantes están haciendo todo lo posible para
promover la seguridad y la seguridad, entonces el gobierno tratará de hacerlo con la concesión de licencias.” [7]
“En mi opinión, la concesión de licencias o certificación de al menos algunas de las especialidades de ingeniería de software (por ejemplo
seguridad- sistemas críticos, sistemas seguros) es inevitable. En el contexto actual, la concesión de licencias probablemente surgirá en primer
lugar. La única decisión que tenemos que tomar es si queremos ser parte de la solución o parte del problema”[10]
“Si la comunidad de software no puede organizarse para convertirse en una profesión reconocida, vamos a tener este hecho para nosotros por los
legisladores y otras personas sin los conocimientos técnicos necesarios y la comprensión de las cuestiones” [11]
“Si la comunidad de ingeniería de software no puede elevarse al nivel de convertirse en una profesión reconocida y una disciplina de ingeniería,
nos enfrentamos a un futuro incierto con perspectivas cada vez más crecientes de la legislación antipático y acciones de gobierno dañinos.” [12]
“... pero la sociedad podría creer que la regulación severa y concesión de licencias de actividades de software son la única manera de evitar una
repetición de la catástrofe del año 2000”. [13]

Es importante tener en cuenta que el 17 de junio de 1998, la Junta de Ingenieros Profesionales de Texas aprobó por unanimidad una propuesta de
reconocimiento de ingeniería de software como una disciplina de ingeniería legítima y para empezar a autorizar ingenieros profesionales en esta área 4.
Consenso sobre un cuerpo de núcleo de conocimiento es un primer paso ineludible
La figura 3 muestra que para abordar correctamente el desarrollo de los planes de estudio de ingeniería de software, la acreditación de los programas
de educación profesional y la concesión de licencias y certificación de los profesionales, el consenso de la profesión en un cuerpo de la base de
conocimiento es un paso ineludible. La necesidad de un consenso sobre un cuerpo básico de conocimientos cuando se habla de acreditación
profesional para el programa de educación y la concesión de licencias o certificación de los profesionales está bien ilustrado por estas dos citas:
“La disciplina de la ingeniería de software es todavía inmaduro, pero las presiones de las regiones donde los ingenieros tienen licencia agregará
urgencia de este problema. Claramente, se requiere algún juicio sobre material central para llevar a cabo una acreditación ...”[9]
“Si aceptamos que la concesión de licencias es inevitable, entonces creemos que es importante que la profesión esté preparado para asesorar a
las legislaturas de los estados sobre la naturaleza de la ingeniería del software y los contenidos adecuados de un examen de licencia.” [7].
Desarrollo de Ingeniería
de Software
Los planes de estudio
Inf
lue
s
cia
nci
en
as
lu
Consenso sobre un cuerpo de la

Inf
base de conocimiento
Desarrollo de criterios de certificación / Influencias Desarrollo de criterios del Programa de

licencias y exámenes Acreditación Universitaria
Figura 3 interrelaciones clave para un cuerpo de núcleo del conocimiento
4 ver http://www.main.org/peboard/sofupdt.htm

La informática es la disciplina subyacente de la ingeniería de software

La historia ha demostrado que una disciplina de ingeniería profesional surge cuando existe una base científica suficiente para que un
núcleo de profesionales formados para aplicar no sólo artesanía, experiencia y habilidad, sino también la teoría al análisis de
problemas y la síntesis de soluciones [14]. Para la mayoría de las disciplinas de ingeniería, esta aparición se produjo en el 18 º y 19 º siglos
con el aumento de la comprensión científica de nuestro mundo físico. Sobre la base de este criterio, Shaw [14] sostiene que, a pesar
de la ingeniería de software aún no ha madurado hasta el estado de una disciplina de ingeniería profesional, este es un objetivo
alcanzable. Baber [15] sostiene que la ingeniería de software se encuentra actualmente en una fase de “pre-ingeniería” de su
desarrollo, en muchos aspectos similar a las fases “pre-ingeniería” de la construcción naval, la construcción de puentes y la
tecnología eléctrica. La disponibilidad y el uso regular de los profesionales de los modelos de predicción que tienen una base
científica y matemática es una característica distintiva de la “ingeniería” de la práctica “pre-ingeniería”. La informática también ha
evolucionado significativamente en los últimos decenios. Los avances en las áreas de diseño de algoritmos, compiladores,
estructuras de datos, sistemas de gestión de bases de datos,
Parnas [16] es de la opinión de que es sobre todo debido a la madurez de la informática que ahora podemos ofrecer programas
universitarios de ingeniería de software. De hecho, argumenta que, debido a distintos objetivos fundamentales, que es en interés de ambas
comunidades para separar las disciplinas. Los precedentes de esta posición se han establecido en otras disciplinas de ingeniería, tales
como en la separación de la física y la ingeniería eléctrica.
Cuando se habla de la relación de la ingeniería de software para su ciencia subyacente, Maibaum [17] afirma:
“Está claro que la relación simbiótica importante entre el análisis, la física y la ingeniería que hemos experimentado durante más de
200 años se va a repetir en el próximo siglo entre la lógica, la ciencia de la computación teórica e ingeniería de software.”
distintos objetivos fundamentales de la informática y la ingeniería de software

Los objetivos fundamentales de la informática y la ingeniería de software difieren, así como los objetivos fundamentales de la ciencia y la
ingeniería. 5 La ciencia en su conjunto busca entender y explicar mejor los fenómenos distintos.
En esencia, el conocimiento es el producto de la ciencia. En su libro seminal titulado “¿Qué
Los ingenieros de saber y como saben son”[20], Vincenti declara‘Para los ingenieros, en contraste con los científicos, el conocimiento no es un fin en
sí mismo o el objetivo central de su profesión.’ 6 Luego pasa a decir que, para la ingeniería, la ciencia es “un medio para un fin utilitario.” Brooks
describe esta diferencia de objetivos muy claramente al afirmar: “Un científico construye con el fin de aprender; un ingeniero aprende con el fin de
construir “. 7 En esencia, los artefactos en lugar de conocimiento son, por tanto, el producto de la ingeniería, ya sean puentes, barcos, aviones,
refinerías de petróleo, los chips de computadora o software.
Un ejemplo de esta diferencia de objetivos es la importancia dada a la acreditación profesional para el programa de educación en la ingeniería y
en la ciencia. Sobre esta cuestión, Parnas [16] afirma:
“El trabajo de los científicos será generalmente juzgado por otros científicos, pero los ingenieros a menudo tratar con los clientes que no son ni
ingenieros ni los científicos. Por lo tanto, mientras que nadie ha sentido la necesidad de mantener la ciencia
5 Como se puede debatir los verdaderos fundamentos de ingeniería de la ingeniería de software por discutir, por ejemplo, el uso de cuantitativa
métodos, también se podría debatir los verdaderos fundamentos científicos de la informática por discutir, por ejemplo, su uso del método científico. En este informe se dejará estos
debates dignos a los demás. Para una excelente discusión de la aplicación del método científico en informática y en ingeniería de software, ver [18] y [19].
6
pag. 6
7 Citado en la pág. 21 de [7].

programas a rígidas normas, la acreditación ha sido siempre una consideración importante para los programas de ingeniería “.
Por lo tanto, la informática pretende comprender mejor y ampliar nuestros conocimientos en el área de la informática. Ampliando nuestro
conocimiento de software o la informática no es el objetivo fundamental de la ingeniería de software, sino más bien la aplicación de este
conocimiento para construir software.
Shaw [14] declara que, aunque hay muchas definiciones de la ingeniería que todos ellos comparten estos elementos comunes: la creación de soluciones
rentables a los problemas prácticos mediante la aplicación de conocimientos científicos para la construcción de cosas en el servicio de la humanidad. A
continuación, establece que, para el software, el problema es, apropiadamente, un problema de ingeniería.
La definición propuesta por el Grupo de Trabajo de la Sociedad ACM / IEEE Computer en el núcleo de la informática para el cálculo [21] es diferente
de la definición de la ingeniería de software 8. El Grupo de Trabajo establece que:
“La disciplina de la informática es el estudio sistemático de los procesos algorítmicos que describen y transforman la información:
su teoría, análisis, diseño, eficiencia, implementación y aplicación. La cuestión fundamental que subyace a toda la
informática es “¿Qué puede ser (eficientemente) automatizado?”
La ingeniería es mucho más que la ciencia aplicada
Vincenti en [20] argumenta en longitud que la ingeniería es mucho más que la ciencia aplicada. La siguiente cita del primer párrafo
de su libro ilustra su argumento:
“Conocimientos de ingeniería, aunque perseguido en la gran longitud y gastos en las escuelas de ingeniería, recibe poca atención por parte de los
estudiosos de otras disciplinas. La mayoría de estas personas, cuando prestan atención a la ingeniería en absoluto, tienden a pensar en él como
ciencia aplicada. ingenieros modernos son vistos como hacerse cargo de su conocimiento de los científicos y, por algún proceso en ocasiones
dramática, pero probablemente intelectualmente interesante, utilizando este conocimiento para artefactos materiales de la moda. Desde este punto
de vista, el estudio de la epistemología de la ciencia debe subsumir automáticamente el contenido de conocimientos de ingeniería. Los ingenieros
saben por experiencia que este punto de vista no es cierto ...” 9
Vincenti clasifica los elementos de conocimiento de ingeniería de diseño de la siguiente manera:
- conceptos fundamentales de diseño;
- Criterios y especificaciones;
- herramientas teóricas;
- Datos cuantitativos;
- Consideraciones prácticas;
- instrumentos de diseño.
A continuación pasa a clasificar las actividades de generación de conocimiento de ingeniería en siete categorías, de las cuales sólo una está directamente
vinculada a la ciencia subyacente. Las categorías son:
- Traslado de la ciencia;
8 Como se cita en la p. 8, la definición IEEE Computer Society de la ingeniería de software es “(1) la aplicación de un enfoque sistemático, disciplinado,
enfoque cuantificable al desarrollo, operación y mantenimiento de software; es decir, la aplicación de la ingeniería de software. (2) El estudio de los enfoques como en (1) “.
9
pag. 3

- Invención;
- la investigación en ingeniería teórica;
- Investigación de Ingeniería Experimental;
- la práctica del diseño;
- Producción;
- ensayo directo.
Estas dos listas ilustran bien que una disciplina de ingeniería tiene un cuerpo de conocimiento diferente del cuerpo de conocimiento de su ciencia
subyacente. Ellos, obviamente, interactuar fuertemente y con frecuencia tienen contenido de superposición. Sin embargo, sus respectivas categorías de
conocimiento y tipos de actividades generadoras de conocimiento difieren en gran medida. Como se discutió en el capítulo 7, una adaptación del esquema
de clasificación de Vincenti para el conocimiento de ingeniería de diseño se propone como un marco común para la estructuración de temas y materiales de
referencia dentro de áreas de conocimiento.
Otra agrupación de propuestas de conocimiento
Un número de grupos, sociedades profesionales y personas han propuesto una serie de puntos de vista con respecto a la swebok. Estas
propuestas se describen con más detalle en el Apéndice J. El Comité Directivo Conjunto de la IEEE Computer Society y de la ACM para el
Establecimiento de Ingeniería de Software como Profesión estableció un grupo de trabajo en 1996 para llevar a cabo trabajos de
exploración en el tema de un cuerpo de ingeniería de software del conocimiento. El grupo de trabajo diseñó y llevó a cabo un estudio piloto
en una muestra de tareas que podrían ser considerados como dentro del ámbito de la ingeniería de software 10. La encuesta se le preguntó
si se espera que cada tarea se describe a ser realizada por un “ingeniero de software novato”, un “ingeniero de software experto”, un
“especialista en ingeniería de software” o un “administrador” en la organización.
Algunas propuestas se incorporen en los programas de certificación, ya sea para un campo más amplio, como es el caso del programa de certificación
profesional de Informática del Instituto para la Certificación de Profesionales de Informática, o un campo más especializado relacionados con la
ingeniería de software, tales como el programa de software de Ingenieros de Calidad de la American Society for Quality, y el analista de Calidad
certificada y prueba de software certificado de programas ingeniero del Instituto de Garantía de Calidad.
Otras propuestas se están realizando dentro del contexto del desarrollo de los planes de estudio de ingeniería de software. Parnas
por ejemplo, al describir un nuevo programa de licenciatura en el campo, propone una lista de áreas de conocimiento relacionadas
con las tareas realizadas por los ingenieros de software. El Grupo de Trabajo sobre Ingeniería de Software Educación y Formación,
que incluye a miembros de la industria y el mundo académico, propone un conjunto de directrices para la educación en la primavera
pasada software que incluye su visión del cuerpo de la ingeniería de software de áreas de conocimiento y componentes de
conocimiento. La Sociedad Australiana también incluye 'Ingeniería de Software y metodologías' como un área de conocimiento
dentro de su cuerpo de la base de conocimiento para los profesionales de tecnología de la información. Finalmente,
Estas propuestas relativas a la swebok no pueden utilizarse en su totalidad o bien, debido a que:
?? la atención se centra más en el desarrollo curricular que en el cuerpo de la base de conocimiento de software
la ingeniería de sí mismo;
?? el foco no está directamente en la ingeniería de software, sino en disciplinas quizá más o menos amplia
tales como la informática, tecnología de la información, sistemas de información, ingeniería de la calidad del software y la ingeniería de prueba;
?? el proceso de creación de consenso no está documentada.
10 El informe sobre los resultados de la encuesta se puede encontrar en computer.org/tab/seprof/survey.htm

Sin embargo, estas propuestas son una excelente entrada en el Consejo Asesor Industrial para garantizar la solidez de la lista de áreas de
conocimiento y disciplinas relacionadas propuesto en la versión hombre de paja de la Guía de la Ingeniería de Software de Administración de
Conocimiento. Además, deben ser examinados en la identificación de los temas y seleccionar materiales de referencia para la versión de piedra
hombre.
Consenso sobre un conjunto de conocimientos es una necesidad
El Comité Directivo Conjunto IEEE Computer Society y ACM para el Establecimiento de Ingeniería de Software como profesión ha
reconocido que el cuerpo de conocimientos de la emergente disciplina de la ingeniería informática, y las otras disciplinas de
ingeniería, es un organismo autónomo de conocimiento distinta de la de la computadora ciencia. Este comité ha identificado que el
consenso de la profesión en este cuerpo de conocimiento es clave para la maduración de la disciplina, y la mejora en el nivel de la
práctica profesional.
Ofreciendo una visión mucho más detallada y completa, la Figura 4 nos permite comprender mejor cómo esta Guía para la Ingeniería de Software de
Administración de Conocimiento puede llegar a afectar a la educación y la formación, la gestión de los recursos humanos de la empresa, el desarrollo
profesional, las asociaciones profesionales y consejos de licenciatura en el campo de Ingeniería de software.

Las interrelaciones de la Ingeniería de Software cuerpo de conocimiento Las partes interesadas

Diagrama contextual
Recursos Humanos
Otros campos en los que se Educación y Desarrollo Sociedades Los consejos de
de la empresa
basa SWEBOK entrenamiento profesional profesionales licenciatura
administración
Educación inicial Establece Normas / Curriculum acreditación
Influencias
Influencias
Computación
Refinar
Ciencias de la Industria / Académico

Estrategias empresariales
Encuesta
Software Cuerpo de Código de ética (desarrollado por la
de Investigación Requisitos Nivel
Sociedad Profesional)
Ingeniería del define básica Proporciona
impartida a través
preguntas de la prueba
Las investigaciones
Influencias Conocimiento habilidades para marco para
Influencias Gestiona Sociedad Profesional Pruebas

educación y
Clasificaciones de empleo Aprendizaje
organizada como Formación
Proceso de dar un título

se centra
Mejora
Gestión de Materias Plan de estudios criterios de

Estandarizada a
proyectos Compensación través de la concesión de

Habilidades nación
comunidad de estándares debería garantizar: licencias que
conjuntos de expectativas para
enseñado a través de subyacente Científico
proporciona
Conceptos
oportunidades para Experiencia Mejora
Monitoreo /
recompensas
Ingenieria aptitudes de los empleados Las
Eléctrica Mecanismos sanciones civiles

Ejecución
asignaciones se acumula como
proporcionar una base para
de entrega
Principios
Actuación Inventario de habilidad fundamentales
asegurado a través
Requisitos de
educación evaluación /
revisión
acreditada
impartir formación Las capacidades habilitar
medido por
Matemáticas establecer el Reunió totales de habilidad
acreditación contexto de
Evaluación
Técnicas probadas La experiencia de
institucionalizado
mediante (validado empíricamente) proyectos
experiencia
Conocimiento específicos
realizado dentro de
permitir a un consenso sobre
Telecomunicaciones / adquirir
Prácticas profesionales con licencia en
redes normas
a través del estandarizada Mejor otro Estado
verificado a través de aprendizaje Prácticas

estudiantes prescribir (universalmente reconocido)
Años en la
profesión
proporcionar una base para
administración exámenes
La disciplina de maduración
mediante la aplicación Establece
Ciencia
Influencias y Avances Leyenda

Otras de datos
disciplinas de
de
ingeniería Proceso formas
Sentar las bases para
Documento
SWE =
Ciencias Ingeniería de
Software
cognitivas Base de datos

4. Metodología para el Desarrollo El conocimiento identificar

Las áreas y disciplinas relacionadas
Introducción
En este capítulo se describe la metodología utilizada para la identificación de las áreas de conocimiento y disciplinas relacionadas. Las áreas de
conocimiento son los principales componentes de una disciplina, o sub-campos de estudio. Disciplinas relacionadas son las otras disciplinas con las
que la ingeniería de software tiene una intersección no vacía o comparte una frontera común.
Los criterios utilizados en la selección de nuestra metodología de identificación
Los siguientes criterios fueron utilizados en la definición de la metodología para la identificación de áreas de conocimiento y disciplinas relacionadas:
?? La metodología de identificación tenido que basarse en fuentes públicas y verificables de la información y tenía
seguir un procedimiento bien documentado y reproducible. Los autores han tratado de hacer el menor número de decisiones editoriales como sea
posible.
?? La metodología de identificación tenía que ser lo más inclusivo posible. Para esta versión del hombre de paja, que era
considere mejor para sugerir demasiadas áreas de conocimiento y disciplinas relacionadas y para que puedan ser abandonada más tarde que a
la inversa.
El foco está en el conocimiento generalmente aceptado
Como se dijo anteriormente, la swebok es un término inclusivo que describe la suma de conocimientos dentro de la profesión de la ingeniería de
software. Sin embargo, la Guía para la Ingeniería de Software de Administración de Conocimiento busca identificar y describir ese subconjunto del
conjunto de conocimientos que es generalmente aceptado o, en otras palabras, el cuerpo de la base de conocimientos. Para ilustrar mejor lo que “el
conocimiento generalmente aceptado” es en relación con otros tipos de conocimiento, la Figura 5 se propone un proyecto de cuatro categorías
esquema para clasificar el conocimiento. A modo de ejemplo, el Apéndice I propone una clasificación de los conocimientos sobre los métodos
formales basados en este esquema.

Generalmente aceptado
las prácticas tradicionales establecidas utilizadas por

muchas organizaciones
Prácticas utilizados sólo para ciertos tipos

Avanzado
Especializado
de software
Prácticas innovadoras probados y utilizados solamente por
algunas organizaciones
Investigación
Conceptos sigue siendo desarrolladas y probadas en

organizaciones de investigación
» Figura 5 Categorías de conocimiento en el SWEBOK
El Instituto de Gestión de Proyectos en su Guía de los Fundamentos de la Dirección de Proyectos 11 [ 22] define “generalmente aceptadas”
conocimiento para la gestión de proyecto de la siguiente manera:
“Generalmente aceptado medios que el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos, la mayor parte del
tiempo, y que existe un amplio consenso sobre su valor y utilidad. Generalmente aceptados, no significa que el conocimiento y las prácticas
descritas son o deberían ser aplicados de manera uniforme en todos los proyectos; el equipo de gestión de proyectos es siempre responsable de
determinar lo que es apropiado para cualquier proyecto dado “. 12
11 Esta guía está actualmente adoptado como un estándar IEEE. Véase el capítulo 7 de [6].
12 pag. 3

Área de conocimiento y disciplina relacionada con la metodología de identificación
Con el fin de proponer áreas de conocimiento y disciplinas relacionadas de “generalmente aceptado” el conocimiento y hacerlo sobre la base de
reconocidas fuentes, públicas y verificables de la información, se decidió que las tablas de contenido de los libros de texto de ingeniería de software en
general, los planes de estudios de pre y post grado programas de ingeniería de software, así como los criterios de admisión para los programas
graduados constituirían la entrada a nuestro análisis. Ciertamente, nadie puede poner en duda que los libros de texto generales y los planes de estudio
son una excelente fuente de información para una mejor comprensión de cualquier disciplina.
Lista preliminar de las

Programas de -Posgrado
de Software enestudio
los planes de disciplinas relacionadas
Ingeniería de Software -
(Ciencias de la Computación
admisión Criteri un y otros)
planes de estudios en Ingeniería
Programas de Posgrado en
Ingeniería de Software - Lista de disciplinas
Programas de Licenciatura relacionadas
Lista preliminar de Ingeniería

Los libros de texto de software de Software
Ingenieria Áreas de conocimiento
Áreas de
Conocimiento de
ISO / IEC 12207 Ingeniería de Software
Tecnología de la propuestas
Información - Procesos del ciclo de
vida del software
Criteria de selección:
- Área de conocimiento debe ser

discutido en Ingeniería de Software
libros de texto generales
- Si Área de conocimiento proviene de

otra área, se incluye si se adaptan
específicamente a la Ingeniería de
Software
Figura 6 Área de Conocimiento e identificación relacionada Metodología disciplina
De hecho, se propone que un área de conocimiento debe ser discutido en un número significativo de los libros de texto de ingeniería de software en general
para ser considerado como “generalmente aceptado”.
libros de texto generales de ingeniería de software puede no ser la única fuente de conocimiento generalmente aceptado. Sin embargo, se espera que
los libros de texto para contener una síntesis de lo que se considera actualmente como el mejor pensamiento en un campo determinado. El Consejo
Asesor Industrial decidirá si esta colección de documentos es suficiente o si un espectro más amplio debe ser considerado. Además, los diversos
subcomités involucrados en la producción de la versión de piedra hombre ciertamente no se limitan a los libros de texto generales de ingeniería de
software en la identificación de los temas y seleccionar materiales de referencia dentro de cada área de conocimiento.

Además, se propone que si un área de conocimiento y subtemas siguientes están relacionados con una disciplina distinta de la ingeniería de
software, tienen que ser adaptados específicamente a la ingeniería de software para ser incluido en la Guía de la Ingeniería de Software de
Administración de Conocimiento. Por ejemplo, las estadísticas se utilizan en ingeniería de software, pero no hay un tipo específico de estadísticas
para esta disciplina. Por el contrario, la estimación del costo del proyecto es diferente en la ingeniería de software de la de la ingeniería eléctrica.
Otro ejemplo sería métodos formales, que tienen una fuerte relación con la informática y las matemáticas incluso, pero se crean específicamente
para resolver problemas de ingeniería de software.
La metodología general utilizada para identificar las áreas de conocimiento de ingeniería de software y disciplinas afines se ilustra en
la Figura 6. La parte izquierda muestra que se recogió información de primera fuente reconocida, pública y verificable:
los libros de texto de ingeniería de software en general y académica
programas. La parte del medio muestra que este material se sintetizó en listas de áreas de conocimiento y disciplinas relacionadas.
La parte de la derecha muestra que estos se organizaron utilizando otro estándar bien reconocido, ISO / IEC 12207 [23], donde sea
aplicable.
La información recopilada
El uso de Internet, se recogió la siguiente información:
?? Las tablas de contenido de libros de texto generales 13 en ingeniería de software, que presentan los autores
opiniones sobre lo que es la frontera de la ingeniería de software y sobre cómo clasificar los temas en Áreas de Conocimiento candidatos. Sin
embargo, estos libros rara vez se identifican explícitamente las disciplinas relacionadas, a pesar de que éstos revelan implícitamente opinión de
donde termina la disciplina de los autores.
?? Los planes de estudios de los programas de grado y posgrado en ingeniería de software, que son otra
fuente pública de información para identificar áreas de conocimiento. También proporcionan una excelente base para el establecimiento de
los límites de la ingeniería de software y la identificación de las disciplinas relacionadas. Software de ingeniería de los planes de estudio
incluyen no sólo los cursos de ingeniería de software, sino también los cursos en las otras disciplinas en las que un ingeniero de software
debe ser educado. Esto es especialmente cierto en el nivel licenciatura. Los programas de posgrado son generalmente mucho más centrado
en la propia disciplina. Información sobre los cursos obligatorios y electivos se recogió por separado, ya que se creía que los cursos
obligatorios sería una mejor base para identificar el cuerpo de la base de conocimientos de materias optativas y debido a la naturaleza muy
variada de cursos electivos, debido sobre todo a la cual la facultad y departamento ofrecido la programa.
?? Los criterios de admisión a los programas de ingeniería de software se gradúan también indican cuáles son las instituciones piensan
los estudiantes deben saber la ingeniería de software fuera. Esta información es útil para identificar las disciplinas relacionadas y para
establecer los límites de la ingeniería de software. Un total de veinticuatro ( 24) libros de texto generales, cinco ( 5) programas de
licenciatura y veinticuatro ( 24)
programas graduados en ingeniería de software se encontraron y se examinaron. Para los programas de grado y posgrado, solamente los que
tienen la lista de cursos requeridos en el sitio web se retuvieron. No hay ninguna razón para creer que no habría ninguna diferencia sustancial
entre los programas que tienen un sitio web y los que no lo hacen. Estos programas son ofrecidos por universidades en los Estados Unidos,
Canadá, Reino Unido, Australia y Suecia. Apéndice A se enumeran los libros de texto generales utilizados para el presente informe y en el
Apéndice B se enumeran las direcciones URL de los programas de grado y posgrado retenidas.
ISO / IEC 12207

Inicialmente, se esperaba que los diversos enfoques - paradigmas incluso - se pueden encontrar mediante el análisis de las tablas de contenido de los
libros de texto de ingeniería de software en general, pero ese no era el caso. Se encontró que los libros de texto por lo general presentan la mayor parte de
la materia de la ingeniería de software en torno a un modelo de ciclo de vida. A menudo, el material más avanzado o material pertinente para todo el ciclo
de la vida y no a una fase particular se presenta en los capítulos adicionales.
13 Estos tabla de contenidos se reunieron en www.amazon.com

Sin embargo, puesto que estos libros de texto no necesariamente comparten un modelo de ciclo de vida en común, se decidió que el 12207 norma ISO /
IEC en los procesos de ciclo de vida del software [23] se utiliza como la base y el vocabulario para la clasificación de los diferentes temas relacionados con
la el ciclo de vida 14.
ISO / IEC 12207 fue elegido por las siguientes razones:
?? Se considera el estándar clave en cuanto a la definición del proceso de ciclo de vida y ha sido adoptado por
los dos cuerpos principales de normalización en la ingeniería de software: ISO / IEC JTC1 SC7 y el IEEE
Comité de Normas de ordenador Sociedad de Ingeniería de Software 15.
?? Ha sido designada como la norma fundamental en torno al cual los Estándares de Ingeniería de Software
Comité (SESC) está actualmente armonizando toda su colección de normas [6].
?? Está diseñado para ser independiente de cualquier método de desarrollo de software específico o modelo de ciclo de vida.
En cuanto a la norma ISO / IEC 12207, Moore afirma en [6] que:
“La norma está destinada a ser independiente de las tecnologías y metodologías de desarrollo y útil para cualquier tipo de modelo de ciclo de
vida, por ejemplo, cascada, incrementales, espiral, etc. De hecho, una de las responsabilidades específicas de la función del proveedor es
seleccionar el modelo de ciclo de vida y asignar las exigencias de la norma a ese modelo “. dieciséis
?? Se cubre todo el ciclo de vida desde la concepción hasta la jubilación.
?? Proporciona funciones para el adquiriente, proveedor, desarrollador, operador y mantenedor.
Intermedio Pasos: Inventario de tablas preparadas

En el curso de la redacción de este informe, se prepararon varias tablas:
?? textooks generales sobre la ingeniería de software. En primer lugar, una lista de los temas tratados por los diversos autores era
producida. La mayoría de los libros presentan los diferentes temas usando un enfoque de ciclo de vida del software. Dentro de cada
categoría los temas específicos se enumeran de acuerdo con el número de libros que cubren el tema dado. La tabla resultante se presenta
en el Apéndice C.
?? programas de grado y posgrado en ingeniería de software. En primer lugar, una lista de los cursos que ofrece
los diferentes programas se producen. Una diferenciación entre los cursos requeridos (los que las instituciones consideran que es el
conocimiento básico) y se hizo cursos opcionales. Los cursos fueron clasificados de acuerdo a dos criterios: el software los procesos
del ciclo de vida, como se describe en la norma ISO / IEC
12207, y las disciplinas a las que se relacionan los cursos. Un total de cinco (5) tablas fueron producidos:
- Programas de grado en Ingeniería de Software - Clasificación de los cursos de acuerdo a

áreas de conocimiento potenciales en el Apéndice D.
14 Los autores son conscientes de que la Evaluación Proceso IEC TR-15504 Tecnología de la Información Software ISO / también define el ciclo de vida
procesos. Sin embargo, la norma ISO / IEC 12207 fue preferido por encima de ISO / IEC 15504 para los fines de esta versión del hombre de paja, ya que ha sido adoptado tanto por
IEEE / EIA e ISO / IEC y porque tiene el rango de norma mientras que la ISO / IEC TR 15504 tiene el estatus de un Informe Técnico de tipo 2. sin embargo, el Consejo Asesor
Industrial podría considerar como posibles áreas de conocimiento los siguientes procesos adicionales definidos en 15504, pero no incluidos en 12207 [24]:
- procesos primarios: Requisitos proceso de elicitación

- Procesos de soporte: proceso de reutilización proceso
de medición
- procesos de organización: Gestión de la calidad
proceso de gestión de riesgos proceso de
alineación organizacional
15
IEEE / EIA es una adaptación de la norma ISO / IEC 12207 con el mismo número y nombre.
dieciséis pag. 197

- Programas de grado en Ingeniería de Software - Clasificación de los cursos por

disciplina relacionada en el Apéndice E
- Programas de Posgrado en Ingeniería de Software - Requisitos de Admisión por

disciplina relacionada en el Apéndice F
- Programas de Posgrado en Ingeniería de Software -

Clasificación de los cursos de acuerdo a áreas de conocimiento potenciales en el Apéndice G
- Programas de Posgrado en Ingeniería de Software - Clasificación de los cursos por

disciplina relacionada en el Apéndice H.

5. Propuestas de Áreas de Conocimiento
Utilizando la metodología descrita en el capítulo anterior, una recopilación de los temas incluidos en las tablas de contenido de libros de texto
generales y en los planes de estudios universitarios de ingeniería de software se presenta en las Tablas 1, 2 y 3. Estas tablas, compilado a partir
Apéndice C, los Anexos D y G, muestran el número de libros de texto que cubre un tema determinado en el Tabla de contenido nivel, y el
número de programas que incluyen cursos requeridos y electivos sobre este tema.
Como se dijo anteriormente, un área de conocimiento propuesto debe ser cubierto en una número significativo de libros de texto para ser
considerado como “generalmente aceptado”. A los efectos de esta versión, este hombre de paja nu significativa mbre se ha fijado en 6, o una cuarta
parte de los libros de texto que figuran en el Apéndice A. Áreas potencial de conocimiento que cumplan este requisito y que convergen bien con el
estándar ISO / IEC 12207 están sombreados en la Tabla 1. Sin embargo, una serie de temas no convergen así con la norma ISO / IEC 12207. la
lista de posibles áreas de conocimiento que no convergen bien con el estándar ISO / IEC 12207, pero que reunirse el requisito de “generalmente
aceptado” se muestran en la Tabla 2. La lista de Áreas de Conocimiento potenciales que no convergen bien con la ISO / IEC 12207 estándar y que no
se vean el requisito de “generalmente aceptado” se muestran en la Tabla 3.
Dado que los programas universitarios de diferentes tipos (de grado y posgrado, profesional y de investigación, etc.) fueron encuestados, se
decidió no incluir esta información en el criterio de selección para considerar un área de conocimiento como “generalmente aceptado”. Además,
un número limitado de cursos se ofrecen a menudo en un programa, especialmente el nivel graduado. Esta información, sin embargo, puede ser
útil para el Consejo Asesor Industrial en su revisión y aprobación de las Áreas de Conocimiento. Los siguientes dos elementos donde tendrán en
cuenta en el establecimiento de la significativo número a 6, o una cuarta parte de los libros de texto:
- Como se señaló anteriormente, la metodología de identificación tenía que ser lo más inclusivo posible y se consideró mejor para sugerir
demasiadas áreas de conocimiento que muy pocos.
- muchos temas se tratan en un libro de texto sin que sean incluidos en la tabla de contenidos; un análisis más detallado
de los libros de texto seguramente sería más perspicaz y representaría mejor cada libro.
Además, estas limitaciones deben ser tenidas en cuenta en la interpretación de la lista propuesta de Áreas de Conocimiento:
- El estudio de los libros de texto sólo se considera tablas de contenido de libros de texto escritos en Inglés y accesibles a través de
Internet. Esto significa que es muy posible que muchos excelentes libros de texto que no figuran en la página web de la biblioteca en
línea se omitieron en este análisis, especialmente los libros de texto en idiomas distintos del Inglés. Esto es debido a que el objetivo en
este caso no era para estudiar de manera exhaustiva todos los manuales de ingeniería de software en general, sino más bien para
recoger una muestra representativa de ellos.
- Muchos programas universitarios excelentes que no se encuentran o no esté descrito en la Internet sin duda se han omitido de este
análisis, en especial los programas impartidos en idiomas distintos del Inglés.
- El análisis de los programas de ingeniería de software universidad se basa sólo en títulos de los cursos. Una vez más, un análisis
más detallado de los planes de estudio sin duda sería más perspicaz.
- Hay ocasiones se solapan, y algunos temas que pertenecen a más de una categoría se cuentan más de una vez. Por
ejemplo, métodos formales se presenta a veces en los Apéndices como un tema aparte, y a veces se incluye dentro de la
clasificación de ciclo de vida (por ejemplo, métodos formales / lenguajes de especificación, temas orientados a objetos,
etc.). Esta información se presenta de esta manera de evaluar mejor la cobertura de estos temas no crear redundancia.
- La importancia de algunos temas especializados (por ejemplo, con tolerancia a fallos de software, software de tiempo real, etc.) puede ser
subestimada ya que el análisis se basa en los libros de texto de ingeniería de software en general.

Clase proceso Los procesos y actividades del Los libros de texto Programas (29) con Programas (29) con
ciclo de vida (24) Cursos cursos opcionales
requeridos 17
Primario software de Adquisición 2 2

suministro de software
Proceso de desarrollo 11 (general) 18 9 (general)

Análisis de 22 22 10
requerimientos 19 20
Diseño 2
arquitectonico
Diseño detallado 21 23 14 14
Codificación 18 4 12
Integración 4
Pruebas dieciséis 9 7
Instalación 3
Apoyo a la aceptación 3
Proceso de operación
Operación del sistema 2
Soporte al usuario
Proceso de 14 4 5
mantenimiento 22
Secundario Gestión de la
Configuración de 10
documentación
Seguro de calidad 15 11 7
V&V 12 9 7
Revisión conjunta 5
auditorías 3
Los procesos de resolución de
problemas
Organizativo Proceso de gestión 20 20 10
Infraestructura
Proceso de Mejora
de Procesos dieciséis 5 2
Proceso de entrenamiento
Tabla 1 Propuesta de áreas de conocimiento basado en la norma ISO / IEC 12207 23
17
Incluye 24 graduados y 5 programas de licenciatura
18 Cursos discutiendo el proceso de desarrollo en general
19 La actividad titulada Implementación del proceso se omite en esta tabla ya no hay capítulos de libros o cursos se refieren directamente a esta
actividad.
20 Dado que en este informe no hemos querido participar en el debate digno de “ingeniería de sistemas” distintivos de “software
la ingeniería”, la actividad titulada‘Análisis de los requisitos del sistema’no aparece en esta tabla.
21 Tenga en cuenta que muchos de los temas en las tablas de contenido y títulos de los cursos que hemos asignado al diseño detallado podría posiblemente
ser asignado al diseño arquitectónico. Un análisis más detallado de los capítulos de libros ellos mismos y los planes de estudio permitiría una mejor asignación de estos temas y, a
menudo resolver las diferencias en el vocabulario.
22 El material en los libros de texto no está organizada de acuerdo con la ISO / IEC 12207 clasificación de las actividades de mantenimiento y
por lo tanto, ningún análisis se realiza en el nivel de actividad para el mantenimiento.

23 Áreas de Conocimiento propuestas consideradas generalmente aceptada están sombreados. Un área de conocimiento propuesto debe ser cubierto en una
número significativo de libros de texto para ser considerado como “generalmente aceptado”. A los efectos de esta versión, este hombre de paja
nu significativa mbre se ha fijado en 6, o una cuarta parte de los libros de texto incluido en el Apéndice A.

Áreas de Conocimiento potenciales Los libros de texto (24) Programas (29) Programas (29)
con con
Cursos requeridos Cursos opcionales
Los métodos de desarrollo de software 14 2
Orientado a objetos 14 4 14
Métodos formales 9 11 7
prototipado 9
Entornos de desarrollo de 13 1 3
software
Ingeniería de Software general y definición 11 11 5
Las métricas de medición / 9 4 9

La fiabilidad del software 6 1 5
» La Tabla 2 Áreas de Conocimiento potenciales para los no-ISO 12207 temas que Reunirse Los criterios de selección “generalmente aceptados”
Áreas de Conocimiento potenciales Los libros de texto (24) Programas (29) Programas (29)
con con
Cursos requeridos Cursos opcionales
Productos de software 5
La reutilización de software 5 2 4
Real-Time / software integrado 4 2 7
reingeniería 4 2
Factores humanos 3 5 10
normas 3
Software Tolerante a Fallos 2
Ética 1 1
Aspectos legales 2
El software de seguridad / Seguridad 2 7
» La Tabla 3 Áreas de Conocimiento potenciales para los no-ISO 12207 temas que No se vean Los criterios de selección para “generalmente
aceptados”

6. Propuestas de disciplinas relacionadas
Sobre la base de una síntesis de los cursos que se imparten en los programas de grado y postgrado en ingeniería de software y en los criterios de
admisión para los programas de posgrado, la Tabla 4 propone una lista de las disciplinas relacionadas con la ingeniería de software. La lista
completa de los cursos y los detalles de los criterios de admisión están listados en el Apéndice E, Apéndice H y el Apéndice F.
Tabla 4 se ordena en orden de número de cursos requeridos en la disciplina, a continuación, según el número de programas de posgrado que
requieren conocimientos en la disciplina como un criterio de admisión, seguido por el número de programas que contienen cursos opcionales en la
disciplina.
La tabla 4 muestra un fuerte sesgo hacia la Informática en la lista de cursos electivos. Esto se explica probablemente por el hecho de que la mayoría de los
programas de ingeniería de software son ofrecidos por los departamentos de informática. De ello se desprende que las materias optativas que se ofrecen
son muy a menudo un subconjunto de los cursos ofrecidos por estos departamentos. En consecuencia, el número relativamente pequeño de cursos en
ingeniería eléctrica y en “otras disciplinas de ingeniería” se debe probablemente al hecho de que algunos de estos programas se imparten en las escuelas
de ingeniería.
En la interpretación de la lista de propuestas disciplinas relacionadas, el lector debe tener siempre en cuenta las siguientes limitaciones:
?? Muchos programas universitarios excelentes no eran una entrada a esta encuesta, especialmente los que no se enseña en
Inglés. El propósito de esta encuesta es la construcción de una muestra representativa de los programas universitarios en ingeniería de software, no para
establecer una lista definitiva de los programas universitarios.
?? Análisis de los programas universitarios de ingeniería de software se basó en sólo títulos de los cursos, y un análisis
de sus planes de estudio sin duda proporcionará información adicional. Sin embargo, un análisis de este tipo además no estaba dentro del alcance de esta
fase hombre de paja.
Propuestas disciplinas relacionadas Cursos básicos Criterios de admisión Cursos electivos
Número de Número de Número de

programas / Número programas / 24 programas / número de
por supuesto cursos
(De un total de 29 (Sólo los programas (De un total de 29

graduados y sub de postgrado) programas de licenciatura y
programas de posgrado)
postgrado)
Ciencias de la Computación 24 19/67 17 23/190
Gestión de proyectos 19/24 10/14
Ingenieria Eléctrica 9/13 3 7/12
Matemáticas 8/21 11 4/9
Telecomunicaciones / Redes 7/12 1 11/29
administración 4/11 9/25
Ciencia 1/4
Otras disciplinas de ingeniería 1 1/4
Ciencias cognitivas 2/2
» Tabla 4 Lista propuesta de disciplinas relacionadas
24 La lista de temas que están incluidos en Informática aparece en los Apéndices. Aunque siempre hay espacio para la interpretación, esta
lista es similar a la utilizada por Glass [25], por ejemplo, que se deriva de la Curriculum CS de la ACM / IEEE-CS Grupo de Trabajo curricular conjunto de tareas. Para algunos,
Ingeniería de Software incluye todo lo relacionado con el desarrollo de software, incluyendo lenguajes de programación, por ejemplo. Esta no es la vista aquí, el objetivo preciso estar
en lugar de distinguir entre Ciencias de la Computación e Ingeniería de Software.

7. Resumen y próximos pasos
Dada la presencia generalizada de software en nuestra sociedad y el aumento de las preocupaciones sobre la necesidad de certificación y concesión de licencias, el
consenso sobre una Guía de la Ingeniería de Software de Administración de conocimiento es una necesidad.
Es fundamental que el liderazgo en esta importante cuestión sea a escala mundial, de lo contrario las futuras directrices de acreditación de programas
universitarios y reglas de certificación y concesión de licencias para los profesionales van a diferir ampliamente.
Un proyecto de tres etapas se ha iniciado el desarrollo de la Guía para la Ingeniería de Software de Administración de Conocimiento. Este informe
es el resultado de la primera fase y se escribió con la premisa de que una guía de este tipo debe contener “consensualmente validado”
conocimientos y prácticas y descansar sobre bases racionales. En consecuencia, se basa en el análisis de los libros de texto de ingeniería de
software en general y los programas universitarios que se ofrecen en el campo. La compilación se llevó a cabo tan objetivamente como sea posible
y de una manera reproducible. El proceso produce una lista de posibles áreas de conocimiento y disciplinas relacionadas. La lista de áreas de
conocimiento propuestos en base a la norma ISO / IEC 12207 es:
?? Proceso de desarrollo
- Análisis de requerimientos
- Diseño detallado
- Codificación
- Pruebas
?? Proceso de mantenimiento
?? Gestión de la configuración
?? Seguro de calidad
?? Verificación y validación
?? mejora de procesos
La lista de áreas de conocimiento propuestos que no convergen bien con la norma ISO / IEC 12207
?? Los métodos de desarrollo de software
- Orientado a objetos
- Métodos formales
- prototipado
?? Entornos de desarrollo de software
?? Ingeniería de Software general y definición
?? Las métricas de medición /
?? La fiabilidad del software
La lista de propuestas disciplinas relacionadas es:
?? Ciencias de la Computación
?? Gestión de proyectos
?? Ingenieria Eléctrica
?? Matemáticas
?? Telecomunicaciones / Redes

?? administración
?? Ciencia
?? Otras disciplinas de ingeniería
?? Ciencias cognitivas
Este informe, que está destinado a poner en marcha la segunda, o fase de piedra hombre, con toda seguridad, estimular un animado debate en
el Consejo Asesor Industrial. Los entregables de la fase de piedra hombre son:
?? una lista de áreas de conocimiento de la ingeniería de software;
?? una lista de temas y materiales de referencia relevantes para cada área de conocimiento;
?? una lista de las disciplinas relacionadas con la ingeniería de software, y las áreas de conocimiento y temas que yace en el
cruce de Ingeniería de Software y uno o más de estas disciplinas relacionadas. Para garantizar la integridad y cohesión de la versión de
piedra hombre, se requiere un marco común para la estructuración de áreas de conocimiento. La metodología de identificación utilizado en la
versión hombre de paja para proponer áreas de conocimiento y disciplinas relacionadas debe ser ampliado para ser apropiados para la
identificación de los temas y seleccionar materiales de referencia dentro de cada área de conocimiento. Esto se debe principalmente a:
?? el nivel variable de granularidad de las tablas de contenido de libros de texto;
?? la edad que oscila ampliamente de estos libros de texto;
?? los muy diversos tipos de programas universitarios encuestados para este informe;
?? el distinto número de cursos que se ofrecen dentro de cada programa;
?? el hecho de que los títulos de los cursos y de tabla de contenido se analizaron en lugar de los planes de estudio
y libros de texto capítulos.
Por lo tanto, se sugiere que una lista de temas se elaborará para cada subcomité sobre la base de una síntesis de los seis libros más recientes
de ingeniería de software en general que figuran en el Apéndice A 25. Estos proyectos de listas de temas se clasifican utilizando una versión
adaptada del esquema propuesto por Vincenti [20] para el conocimiento de ingeniería de diseño 26. entonces se pedirá a cada subcomité para
revisar y mejorar la lista de temas propuestos y seleccionar materiales de referencia para cada tema. Los subcomités volverían una versión
actualizada de la lista de temas propuestos para una determinada área del conocimiento y materiales de referencia pertinentes clasificadas
utilizando las categorías Vincenti adaptados.
Las categorías Vincenti de conocimientos de diseño de ingeniería se proponen como un marco para organizar los temas y materiales de referencia
debido a que:
?? que se basan en un análisis histórico detallado de una sucursal establecida de la ingeniería: areonautical
Ingenieria;
?? son vistos por Vincenti según sea aplicable a todas las ramas de la ingeniería 27;
25 Estos libros de texto son Behforooz y Hudson, 1996, Jalote, 1997, Pfleeger, 1998, Pressman, 1996, Sommerville, Ian, 1995 y
Dorfman y Thayer, un tutorial general sobre la ingeniería de software.

26 Según se cita en el capítulo 3 y propuesto por Vincenti, las categorías de conocimiento de ingeniería de diseño son:
- conceptos fundamentales de diseño;

- criterios y especificaciones;
- herramientas teóricas;
- datos cuantitativos;
- consideraciones prácticas;
- instrumentos de diseño.
27
En la introducción al capítulo que propone las categorías de conocimiento de ingeniería de diseño, Vincenti indica en la pág. 200: “A pesar de los casos todos vienen de la aeronáutica,
las generalizaciones de este capítulo están destinados a ser más universal. Diseño en otras ramas de la ingeniería (mecánica, eléctrica, etc.), aunque diferentes en detalle, procede de
la misma manera. Eso
por lo tanto, implica las mismas categorías generales de conocimientos y actividades que lo generan. Los detalles de mi experiencia y los estudios de otros suministran evidencia
ilustrativa para este hecho. Como se indicó en el capítulo 1, creo que las generalizaciones a las otras ramas llamarán para la adición y modificación en lugar de revisión fundamental “.

?? lagunas en la swebok dentro de ciertas categorías, así como los esfuerzos a

reducir estas brechas con el tiempo se hace evidente;
?? debido a la naturaleza genérica de las categorías, el conocimiento dentro de cada área de conocimiento podría evolucionar y
el progreso de manera significativa, mientras que el propio marco se mantendría estable;
Se requerirá muchas horas de trabajo, debate y búsqueda de consenso para desarrollar el Hombre de Piedra y las posteriores versiones de Iron
Man de la Guía de la Ingeniería de Software de Administración de Conocimiento. El logro de un consenso sobre el cuerpo de la base de
conocimiento es un hito clave en todas las disciplinas y es fundamental para la evolución de la ingeniería de software hacia un estatus profesional.
La participación de todas las partes, la industria,
asociaciones profesionales, organismos de normalización y el mundo académico, es fundamental para asegurar la relevancia y la credibilidad de los resultados, y para
una absorción rápida de los resultados.
Más tarde, en la pág. 236, afirma, tras presentar un cuadro resumen de las categorías de conocimiento y actividades generadoras de conocimiento: “Creo que la mesa y las ideas
detrás de él se aplican al diseño en todas las ramas (aeronáutica, mecánica, eléctrica, etc.), de la ingeniería moderna. Creo, además, aunque no he pensado en el asunto en
profundidad, que también pueden adaptarse sin mayor dificultad a la que se produce en la ingeniería de producción y operación.”

8. Referencias
[1] “Proyecto de Criterios de Acreditación de Ingeniería de Software” IEEE Computer, vol. 31, pp. 73-75, 77, 1998. [2]
D. Gotterbarn, K. Miller, y S. Rogerson, “Software Ingeniería Código de Ética, versión 3.0,” IEEE Computer, pp. 88-92, 1997.
[3]
“IEEE Standard Glosario de Terminología de Ingeniería de Software,” IEEE, Piscataway, NJ std 610.12-
1990, 1990.
[4] P. Starr, La transformación social de la medicina americana: BasicBooks, 1982. [5]
P. Naur y B. Randell, “Ingeniería de Software”, presentado en Informe sobre una conferencia patrocinada por el Comité de la
OTAN Ciencia, Garmisch, Alemania, 1968. [6]
JW Moore, Estándares de Ingeniería de Software, de un usuario de la Hoja de Ruta. Los Alamitos: IEEE Computer Society Press, 1998. [7]
G. Ford y NE Gibbs, “ Una Profesión maduro de Ingeniería de Software, ”Software Engineering Institute, Universidad Carnegie
Mellon, de Pittsburgh, Pennsylvania, Técnico CMU / SEI-96-TR-004, enero de 1996. [8]
“Número especial sobre concesión de licencias y certificación”, en Cortador de TI Diario, vol. 11, 1998, pp. 30. [9]
P. Dart, L. Johnston, C. Schmidt, y L. Sonenberg, “Desarrollo de un Programa de Ingeniería de Software Acreditado” IEEE
Software, vol. 14, 1997.
[10] NR Mead, “¿Vamos a pescar o cortar cebo? Licencias y Certificación de Software

Profesionales” Cortador de TI Diario, vol. 11, pp. 4-8, 1998.
[11] L. Werth, “Certificación y licencias de software para profesionales y organizaciones”, presentado en

11ª Conferencia sobre Software Engineering Education y Formación (CSEE & T 98), Atlanta, Georgia,
1998.
[12] C. Jones, “Challenge Software - Régimen jurídico de Ingeniería de Software” Computadora, vol. 28, pp. 98-
99, 1995.
[13] E. Yourdon, “¿Por qué necesitamos de la licencia? No es como si hubiéramos matado a nadie ...” Cortador de TI Diario,
vol. 11, pp. 26-30, 1998.
[14] M. Shaw, “la perspectiva de una disciplina de ingeniería de software” IEEE Software, pp. 930-940, 1990. [15] RL Baber,
“Comparación de la eléctrica "Ingeniería" de veces y software de Heaviside

"Ingeniería" de nuestro tiempo” IEEE Anales de la Historia de la computación, vol. 19, pp. 5-17, 1997. [16] DL Parnas, “ Programas
de software de ingeniería no son programas informáticos, ”

McMaster University, Hamilton, Ontario CRL número de informe. 361, abril de 1998.
[17] T. Maibaum, “Qué enseñamos Ingeniería de Software en la Universidad: ¿Tomamos Ingeniería

¿Seriamente?," ACM SIGSOFT, Ingeniería de Software Notas, vol. 22, pp. 40-50, 1997. [18] WF Tichy, “debería Computer
científicos Experimento Más ?,” Computadora, vol. 31, pp. 32-40, 1998. [19] MV Zelkowitz y D. Wallace, “Modelos experimentales para la
validación de la tecnología” Computadora, vol.

31, pp. 23-31, 1998.
[20] WG Vincenti, Lo que los ingenieros saber y como saben son - Estudios analíticos de Aeronáutica
Historia. Baltimore y Londres: Johns Hopkins, 1990.
[21] PJ Denning, DE Comer, D. Gries, MC Mulder, A. Tucker, AJ Turner, y PR Young,

“La computación como una disciplina” Communications of the ACM, vol. 32, pp. 9-23, 1989. [22] WR Duncan, “ Una guía para la
Dirección de Proyectos del Conocimiento, " Gestión de proyectos

Instituto, Upper Darby, PA 1996.

[23] “ Tecnología de la Información - Software Procesos del ciclo de vida, ”Norma Internacional ISO Técnico / IEC 12207: 1995 (E),
1995.
[24] TP Rout, “Problemas en el desarrollo de una Norma Internacional de Procesos de Software

Evaluación," Boletín de procesos de software, vol. 10, pp. 1-6, 1997.
[25] R. Glass, “Análisis comparativo de las áreas temáticas de Ciencias de la Computación, Ingeniería de Software,
y Sistemas de Información,” Diario de sistemas de software, vol. 19, pp. 277-289, 1992. [26] TB Hilburn, DJ Bagert, S. Mengel, y D.
Oexmann, “Al otro lado de Ingeniería de Software de Computación

Los planes de estudio,” 3 rd Conferencia Anual sobre integración de la tecnología en la enseñanza de computación - ITiCSE'98, Pp. 4, 1998.

9. Apéndices

Apéndice A. Lista de libros de texto generales y tutoriales sobre Ingeniería de Software
Behforooz, Ali y Frederick J. Hudson, 1996, Fundamentos de Ingeniería de Software, Prensa de la Universidad de Oxford.
Campana, Masa, Ian morrey y John Pugh, 1992, Ingeniería de Software, 2 Dakota del Norte Edición, Prentice Hall.
Blum, Bruce I., 1992, Ingeniería de Software: una visión holística, Prensa de la Universidad de Oxford.
Congrio, Sue A., 1993, La Ingeniería de software nuevo, Tecnología curso.
Dorfman, Merlin y Ricahrd H. Thayer, Editores, 1996, Ingeniería de software, IEEE Computer Society Press, Los Alamitos, California.
Fairclough, Jon, Editor, 1995, Guías de Ingeniería de Software, Prentice Hall.
Fairley, Richard E., 1985, Conceptos de Ingeniería de Software, McGraw Hill.
Vado, Neville J. y Mark Woodroffe, 1993, La introducción de Ingeniería de Software, Prentice Hall.
Ghezzi, Carlo, Mehdi Jazayeri y Dino Mandrioli, 1991, Fundamentos de Ingeniería de Software,
Prentice Hall.
Humphrey, Watts S., 1995, Una disciplina de Ingeniería de Software, Addison-Wesley.
Ince, D., 1989, Ingeniería de software, Prensa Internacional Thomson ordenador.
Jalote, Pankaj, 1997, Un enfoque integrado sobre Ingeniería de Software, Springer Verlag, Nueva York.
Jones, Gregory W., 1990, Ingeniería de software, John Wiley & Sons.
Mazza, C., J. Faircoulgh, SEGUNDO. Melton, RE. de Pablo, A. Sheffer y R. Stevens, 1994, Estándares de Ingeniería de Software, Prentice Hall.
Pfleeger, Shari Lawrence, 1998, Ingeniería de Software: Teoría y Práctica, Prentice Hall, Nueva Jersey.
Periodista, Roger S., 1988, Ingeniería de Software, Guía de un principiante, McGraw Hill.
Periodista, Roger S., 1996, Guía de un Gestor de Ingeniería de Software, McGraw Hill.
Periodista, Roger S., 1996, Ingeniería de Software: El enfoque de un practicante, 4 º Edición, McGraw Hill.
Sabio, Andrew P. y James D. Palmero, 1990, Software de Ingeniería de Sistemas, John Wiley & Sons.
Sallis, Philip, Tate Graham y Stephen McDonnell, 1995, Ingeniería de software: Práctica,
Gestión, Mejora, Addison-Wesley.
schach, Stephen R, 1993, Ingeniería de Software, 2 Dakota del Norte Edición, McGraw-Hill.
Sommerville, Ian, 1995, Ingeniería de Software, 5 º Edición, Addison-Wesley.
Thayer, Richard H. y Andrew D. McGettrick, Editores, 1993, Ingeniería de Software: una perspectiva europea, IEEE Computer Society
Press, Los Alamitos, California.
Van Vliet, Hans y Vrije Van Vliet, 1993, Ingeniería de Software: Principios y Práctica, John Wiley & Sons.

Apéndice B. URLs de los programas de grado y posgrado en Ingeniería de Software
Programas de Licenciatura en Ingeniería de Software
Se encontraron cinco programas de licenciatura en ingeniería de software en cuatro universidades:
?? La Universidad de Birmingham ofrece dos programas distintos, uno titulado Ingeniería de software y el
otro Ingeniería de Software con Estudios de Negocios - Birmingham, Reino Unido.
www.cs.bham.ac.uk/degreeregs/
?? Universidad de Londres - Colegio Imperial de Ciencia, Tecnología y Medicina de Birmingham, Reino

Reino
www.doc.ic.ac.uk/teaching/under/comp/regulations/mengse.html
?? Universidad de Nueva Gales del Sur, Australia
www.cse.unsw.edu.au/school/teaching/courses/bese.html
?? Universidad de Ottawa - Ottawa, Canadá
No hay URL disponible

Programas de postgrado yo Ingeniero n Software yo ng
Encontramos 24 programas de postgrado en 23 universidades:
?? Universidad Andrews - Berrien Springs, MI, EE.UU.

Maestría en Ingeniería de Software
http://www.andrews.edu/CS/cis-ms.html
?? Universidad Carnegie Mellon - Pittsburgh, PA, EE.UU.

http://www.cs.cmu.edu/afs/cs/project/mse/www/
?? Concordia - Montreal, QC
Master en Ciencias de la Computación - Software Opción Ingeniería
http://www.cs.concordia.ca/Graduate_Info/Graduate_Programs_M.html
?? Universidad DePaul - Chicago, IL, EE.UU.

Maestría en Ingeniería de Software (Una concentración en el desarrollo de software, el otro en Software de Gestión)
http://www.cs.depaul.edu/programs/Segrad.html
?? Embry-Riddle University - Daytona Beach, FL, EE.UU.

http://www.db.erau.edu/catalog/graduate/mse.html

?? Universidad Flinders de Australia del Sur, Australia

http://www.cs.flinders.edu.au/
?? Universidad del Estado de Kansas - Manhattan, KS, EE.UU.

http://www.ksu.edu/grad/catalog/cis.htm
?? Monmouth University, West Long Branch, Nueva Jersey, EE.UU.

MS en Ingeniería de Software
http://www.monmouth.edu/muse/stinfc97.html
?? Universidad Tecnológica Nacional - Fort Collings, CO, EE.UU.

http://www.ntu.edu/2/software.htm
?? Universidad Nacional - La Jolla, CA, EE.UU.

http://www.nu.edu/catalog/somt/msse.html
?? Universidad de Seattle - Seattle, WA, EE.UU.

http://www.seattleu.edu/~mse/mse97.html
?? Universidad Metodista del Sur - Dallas, TX, EE.UU.

http://www.seas.smu.edu/disted/se/
?? Texas Christian University - Fort Worth, TX, EE.UU.

http://www.cs.tcu.edu/grad/grad.html
?? Universidad de Quebec en Montreal - Montreal, QC, Canadá

M.Sc.A. en Ingeniería de Software
http://www.regis.uqam.ca/Programmes/3821.html
?? Universidad de Calgary - Calgary, AL, Canadá

Maestría con especialidad en Ingeniería de Software
http://ksi.cpsc.ucalgary.ca/SERN/SEMSc.html
?? Universidad de Colorado - Colorado Springs, CO, EE.UU.

Maestría en Ingeniería - Opción de Software Ingeniería de Sistemas
http://mepo-b.uccs.edu/software.html

?? Universidad de Houston - Clear Lake - Houston, TX, EE.UU.

http://www.cl.uh.edu/nas/applied/graduate/MSoftEngg.html
?? Universidad de Karlskrona / Ronneby - Suecia

http://www.hk-r.se/for/internationell/master.htm
?? Universidad de Maryland - College Park, Maryland, EE.UU.

http://www.cs.umd.edu/Grad/mswe.html
?? Universidad de Missouri-Kansas City, EE.UU.

Maestría en Ciencias de la Computación - Concentración de Ingeniería de Software
http://www.umkc.edu/umkc/catalog/html/cmp-sc/0000.html
?? Universidad de Scranton - Scranton, Pensilvania, EE.UU.

http://academic.uofs.edu/department/gradsch/gsofteng.htm
?? Universidad de St. Thomas - Minneapolis, Minnesota, EE.UU.

http://www.gps.stthomas.edu/ms.html
?? Universidad de Stirling - Stirling, Escocia, Reino Unido

http://www.cs.stir.ac.uk/~sbj/se-leaflet.html

Apéndice C.
Los libros de texto generales y tutoriales sobre Ingeniería de Software - Clasificación de la tabla de contenido entradas por áreas
de conocimiento potenciales

Proceso de adquisición
Otro
Proceso de desarrollo
Problema de software / Crisis
© IEEE Computer Society

Principios de ingeniería de software
Descripción general del software Ingeniería
Enfoque informal
Modelado de análisis
Análisis estructurado
Especificación de requisitos
Análisis de Datos Orientada
Análisis basado en el Método

Análisis Orientado a Objetos
ISO / IEC 12207 procesos primarios
Análisis orientado a los procesos

Análisis de función Orientada
Análisis orientado a Point View

Introducción a la Ingeniería de Software
Análisis de requisitos del sistema / software

Software / Hardware del sistema y Contratación
Requisitos / Problema / Análisis de Sistemas - Análisis

Ingeniería de Software: Teoría y Práctica - marzo de 1998 Enfoque Shari Lawrence Pfleeger
√
√
√
√
Integrado de Ingeniería de Software - 1997 Pankaj Jalote Ingeniería de Software - Sep. de 1996
Editado por Merlin Dorfman y Ricahrd H. Thayer Ingeniería de Software: Enfoque para
√
√
√
√
√
√
√
√
√
√ profesionales - 4ª Edición - Ago de 1996
√
√
√
√
√
√
√
√
√
Roger S.
Fundamentos de Ingeniería de Software - Julio de 1996 Ali Behforooz y Guía de
Pressam
√
√
√
√
√
Frederick J. Hudson A del gerente de Ingeniería de Software - Marzo de 1996
Roger S. Pressman Ingeniería de Software - 5ª Edición - 1995 Ian Sommerville
Software Guías de Ingeniería - 1995 Editado por Jon Fairclough
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Ingeniería de Software: Práctica, Gestión, Mejora - 1995 Philip Sallis, Graham y Stephen Tate
√
√
√
√
√
√
MacDonell una disciplina de Ingeniería de Software - Ene 1995 Estándares de Ingeniería de

Software Watts S. Humphrey - 1994
√
Guía de la Ingeniería de Software de Administración de Conocimiento - Un hombre de paja Versión
√
√
√
√
C. Mazza, J. Faircoulgh, B. Melton, D. de Pablo, A. Sheffer, R. Stevens
La introducción de Ingeniería de Software - Oct. de 1994 Neville
√
√
√
√
√
J. Ford y Mark Woodroffe Ingeniería de Software -2ª edición -

1993 Stephen R. Ajedrez El Nuevo Software Engineering - Dic
√
√
√
√
1993 Sue A. Conger

√
√
√
√
√
√
√
√
√
Ingeniería de Software: una perspectiva europea - Agosto 1993 Richard H. Thayer y

√
√
√
√
√
Andrew D. McGettrick Ingeniería de Software: Principios y Práctica - abril de 1993

Hans Van Vliet y Vrije Van Vliet Ingeniería de Software: una visión holística - Oct. de
√
√
√
√
1992 Bruce I. Blum software ingeniería - 1992 mayo de masa Bell, Ian Morrey y John
Pugh Fundamentos de ingeniería de Software - Ene de 1991 Carlo Ghezzi, Mehdi
√
√
√
√
√
√
Jazayeri y Dino Mandrioli ingeniería de Software - Marzo de 1990 Gregory W. Jones

Software Systems ingeniería - Marzo de 1990 Andrew P. Sage y James D . Palmer
√
√
√
Ingeniería de Software - 1989

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
D. Ince
Ingeniería de Software, una guía para principiantes - Feb. 1988 Conceptos
√
√
√
√
Roger S. Pressman Software Engineering - Ene de 1985 de Richard E.

38
Fairley
√
√
√
prototipado
Documento de diseño

Tipos de Requisitos
requisitos Evolución
El software de diseño detallado
Diseño Orientado a Objetos

requisitos de los documentos
Diseño de Procesos / Actividades

Métodos / técnicas
Real-Time Systems Design

El software de diseño arquitectónico
Requerimientos no funcionales
Desarrollo del Sistema de Jackson
Especificación algebraica
Herramientas de especificación
Requisitos del proceso / Actividades

Los atributos de la especificación
Requisitos de Identificación / Captura

Real-Time especificación de software
Animación de la especificación de requisitos
Especificación formal de especificación / Idiomas
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
profesionales - 4ª Edición - Ago de 1996
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√

√
1993 Sue A. Conger

√
√

√
√
√

√
√
√

√
√
√

√
√
√
√
√
√
D. Ince
√

39
Fairley
√
merise
Herramientas
Métodos formales
diseño de Mejora
Estrategias de diseño
La codificación de software
Diseño estructurado
Diseño de flujo de datos

Especificación de diseño
Datos de diseño orientado a
Conceptos y principios
Documentación interna
Diseño Humano / Interfaz
Programación estructurada
Diseño de la estructura de datos
Proceso de Diseño Orientado
Lenguajes de programación
Diseño Orientado a la función
Los métodos de diseño / Modelos
Estilo de programación / Técnicas

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√

√
√
1993 Sue A. Conger

√
√
√
√

√
√
√

√
√
√
√

√
√
√
√
√

√
√
√
√
D. Ince
√

40
Fairley
√
√
principios
Herramientas
otras pruebas
Plan de prueba
Manual de usuario
Prueba del sistema

plan de integración
Prueba de interfaz
Pruebas funcionales
Pruebas de integración
La programación lógica

Programación paralela
Los generadores de códigos
Unidad de Pruebas / Módulo

Testing System / Software
Prueba orientada a objetos

Programación funcional
Sistema / software de integración

Programación orientada a objetos
De arriba hacia abajo / abajo hacia arriba la programación
Fundamentos de prueba / Conceptos / Principios básicos

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
1993 Sue A. Conger

√

√

√
√
√
√
√

√
√
√
D. Ince
√

41
Fairley
Formación
mantenibilidad
Planificación
Documentación
Herramientas
Proceso de operación
depuración
Operación del sistema
Proceso de mantenimiento
Proceso de prueba
Instalación de software
Ensayos estructurales
Estrategias de prueba
Test de aceptación
Técnicas de ensayo

Pruebas de rendimiento
Documento de transferencia
La aceptación de soporte de software

Pruebas de software en tiempo real
De caja blanca / Negro-Box Testing
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
1993 Sue A. Conger

√

√
√
√
√
√
√
D. Ince
√

42
Fairley
√
Costo
Herramientas
Herramientas
Cambio de control
Building System
control de configuración
Gestión del cambio

Implementación de procesos
Implementación de procesos
Proceso de Aseguramiento de la Calidad

La identificación de configuración
Planes de Aseguramiento de Calidad

control de elemento / almacenamiento
Proceso de Gestión de la Configuración
Configuración de contabilidad Estado

Contabilidad y Auditoría de estado
Planes de Gestión de la Configuración
Versión y lanzamiento de Gestión

Gestión de la Entrega de configuración y entrega
ISO / IEC 12207 Apoyando los procesos de ciclo de vida
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
1993 Sue A. Conger
√

√
√
√

√
√
√
√

√
D. Ince
43
Fairley
auditorías
Comentarios
Tutoriales
Herramientas
trazabilidad
Proceso de auditoría
Revisiones de código
Revisiones de diseño
Verificación estática
Método para salas blancas
Proceso de evaluación conjunta

Atributos de calidad
requisito Comentarios
requisitos de Validación

Gestión de la calidad
Diseño Verificación / Validación

Producto / Proceso de Aseguramiento
Las inspecciones de software / Programa
Verificación y validación de los planes

Los procesos de verificación y validación
Proceso de Aseguramiento de la Calidad / Actividades
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
1993 Sue A. Conger

√

√
√

√

√
D. Ince
44
Fairley
√
técnicas
Riesgo
Planificación
Estimacion
Proceso de gestión
FPA
edificio
COCOMO

Conceptos / Principios
Actividades / Marco
Control de riesgo
tamaño Estimación
Gestión de riesgos
Iniciación y Definición del Alcance
Estimación de recursos
Costo / estimación de esfuerzo
Estimación de costos no laborales
Evaluación de Riesgos / Análisis

Estimacion
Duración / Horarios Estimación
ISO / IEC 12207 Procesos ciclo de vida organizacional
Modelos / Estimación
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
1993 Sue A. Conger

√

√
√
√
√

√
√
√
√
√
√

√
√
√
D. Ince
45
Fairley
√
√
√
√
informes
Herramientas
Productividad
Manejo tecnico
Ejecución y Control
Proceso / Actividades
La gestión de personas
proyecto de Presupuesto
Revisión y evaluación

Programación de proyectos
Análisis coste-beneficio
Modelo de riesgo
Herramientas de planificación
Las áreas de riesgo
Tabla de riesgo / Matrix
Recursos Evaluación y Mejora

Gestión de software contratada
Al frente del proyecto / Rol del Gerente
Control de Proyectos / Monitoreo / Seguimiento
El personal / Planificación de Personal / Recursos
En la gestión de la casa de desarrollo de software

√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
1993 Sue A. Conger

√
√

√
√
√
D. Ince
46
Fairley
CMM
ISO 9000
mejora de procesos
Madurez de procesos
Evaluación del proceso
La mejora de procesos
proceso de Selección

Establecimiento de procesos
Otros
Los procesos del ciclo de vida
Características del proceso

Análisis de Procesos / Modelado
prototipado
Modelos / Enfoques
Los modelos de proceso / Estructura

Modelo espiral
Modelo cascada
Evaluación del Proceso / Evaluación

Modelo evolutivo
modelo incremental
Modelo iterativo de mejora
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
1993 Sue A. Conger

√
√
√
√
√
√

√
√
√
√
√
√
√

√
√
√
√
√
D. Ince
47
Fairley
Herramientas
especia
Temas especiales
otras mediciones
Sistemas de Tiempo Real

Métricas / Medición
métricas de procesos
Recopilación de datos
Las métricas técnicas

Las métricas de calidad
Las métricas de tamaño
Los atributos de software

Las métricas de fiabilidad
Las métricas de productos
Parámetros de gestión
Las métricas de complejidad
Reingeniería / reingeniería

Las métricas orientadas a objetos
Real-Time Systems Design
Real-Time Systems Testing

Sistemas de Tiempo Real especificación de requisitos
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
1993 Sue A. Conger

√
√

D. Ince
48
Fairley
CASO
Definición
Ingeniería inversa
Métodos formales
Unix Medio Ambiente
Diseño formal
Entornos integrados
Integración de herramientas
CASO integrada

Clasificación de casos
Bancos de trabajo CASE
Enfoque Orientado a Objetos


Herramientas / conjuntos de herramientas
Entornos de desarrollo de software
Desarrollo Orientado a Objetos

Definiciones, conceptos, principios
Metodologías de desarrollo de software / Paradigmas
Especificación formal de especificación / Idiomas

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√

√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√

√
√
√

√
1993 Sue A. Conger

√
√
√
√
√
√

√
√
√
√

√
√
√
√
√
D. Ince
49
Fairley
definiciones
prototipado
Reglas de diseño
Productos de software
Tolerancia a fallos
La fiabilidad del software
La evitación de fallos
Manejo de excepciones
La programación defensiva
Datos enfoque centrado

Diseño y Prototipos
Función-Oriented Approach
Las técnicas de prototipado
Enfoque basado en el conocimiento
Productos de Software de Evaluación

Productos de Software Mejora

Interfaz de usuario de prototipos
Análisis de requisitos y Prototipos
Creación de prototipos en el proceso de desarrollo de software
Análisis sistemas estructurados y Método de Diseño (SSADM)

√
√
√
√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√ Ingeniería de Software: Práctica, Gestión, Mejora - 1995 Philip Sallis, Graham y Stephen Tate
√
√
√

√

1993 Sue A. Conger

√

√
√

√
√
D. Ince
50
Fairley
normas
Ética
modelos
Otros temas
Redundancia
Especificación
Servidor de cliente
Factores humanos
Sistemas expertos
Software crítico
Normas de calidad
La reutilización de software
la reutilización de código
Herramientas de software
Psicología de software
Software Tolerante a Fallos

Enseñanza de la Ingeniería de Software
Desarrollo de software para su reutilización
Ingeniería de Software para salas blancas

Desarrollo de Software con reutilización
Evaluación de Estándares de Ingeniería de Software

√
√
√
√
√
√
√
√
Roger S.
Pressam
√
√
√

√
√
√
√
√
√
√
√
√
√

√
√

1993 Sue A. Conger

√
√
√
√
√

√
√
√

√
√

√
√
D. Ince
51
Fairley
transición de la tecnología

Roger S.
Pressam
√
1993 Sue A. Conger

D. Ince
52
Fairley
Apéndice D.
Programas de grado en Ingeniería de Software - Clasificación de los cursos de acuerdo
a áreas de conocimiento potenciales

Universidad de Nueva Gales del Sur, Sydney, Australia Licenciatura

Universidad de Birmingham, Reino Unido Licenciado en Ciencias de la Computación
Universidad de Londres, Reino Unido Imperial College de Ciencia,

Tecnología y Medicina Meng Informática (Ingeniería de Software)
Universidad de Birmingham, Reino Unido Licenciado en Ciencias de la
Computación / Ingeniería de Software con Estudios de Negocios
Graduación BASc. en Ingeniería de Software

Universidad de Ottawa, Ontario
en Ingeniería de Software
/ Ingeniería de Software
Los cursos obligatorios de Ingeniería de
Software Introducción 2 2 6 1
Ingeniería de Software / ES Ingeniería √ √ √ √ √√√√√√ √
ISO / IEC 12207 procesos primarios 1 1 2 3 7
Proceso de desarrollo 1 1 2 3 7
Los sujetos generales 2
Desarrollo de software √
Fundación de Desarrollo de software √
Análisis de requisitos del sistema / software 2 1
Análisis √
Análisis Orientado a Objetos √
Ingeniería de requisitos √
El software de diseño detallado 1 1 2 1 4
Diseño √ √ √ √ √
Human Interface / User √ √ √
Diseño Orientado a Objetos / Modelado √
ISO / IEC 12207 Apoyando los procesos de ciclo de vida 1
Proceso de Aseguramiento de la Calidad 1
Calidad √
ISO / IEC 12207 Procesos ciclo de vida organizacional 1 1
Proceso de gestión 1 1
Proyectos / Software de Gestión √
Gestión de la información √
Temas especiales 3
En tiempo real Software / Sistemas Embebidos √
reingeniería √
El software de seguridad / Seguridad √
Otros cursos 11 15 18 20 28
Contabilidad √
Álgebra √
algoritmos √ √ √
Inteligencia artificial √
Administración de Empresas √ √ √
C ++ √ √ √ √
Cálculo √ √
Química √
Habilidades de Comunicación y Asuntos Profesionales √ √
Los compiladores √




Métodos Computacionales / Computing √ √ √
Arquitectura de Computadores √ √ √ √
Gráficos de computadora √ √ √
Ciencias de la Computación √ √
Sistemas concurrentes / Programación √
Bases de datos / Gestión de Datos √ √ √ √ √ √
Datos Strucutres / Organización de datos √ √
Organización Digital Computer √ √
DISCRET Matemáticas √ √ √ √ ½
Economía √ √ √
Ética √
Gestión de archivos √
Fundamentos de Ciencias de la Computación √
Hardware √ √
Human Interface / User √
Factores Humanos / Recursos Humanos √
Lógica √ √ √ ½ ½
Márketing √
Matemáticas √ √
Mecánica √
Los microprocesadores √
Redes / Redes √ √ √
Sistemas operativos √ √ √ √
Física √ √
Programación √ √
Reutilizar ½
Semántica √
Simulación √
Taller de software √ √ √ √
Estadística √ √ √
Comunicación técnica y escritura √
Telecomunicaciones / Sistemas de Comunicación √ √ √
Cursos opcionales
ISO / IEC 12207 procesos primarios 7 6 1
Proceso de desarrollo 7 6 1
Análisis de requisitos del sistema / software 1
Los métodos formales / lenguajes de especificación √
El software de diseño detallado 1 1




Human Interface / User √ √
La codificación de software 4 4 1
Programación comercial √ √
Comparación de los lenguajes de programación √ √
Programación √
Lenguajes de Programación Principios √ √
Métodos de programación √ √
Testing System / Software 1 1
Verificación, validación y pruebas √ √
ISO / IEC 12207 Apoyando los procesos de ciclo de vida 1 1
Proceso de Verificación y Validación 1 1
Verificación y validación √ √
ISO / IEC 12207 Procesos ciclo de vida organizacional 2 2
Proceso de gestión 2 2
Planificación de proyectos √ √
Gestión estratégica √ √
Temas especiales 1
Otros cursos 29 21 2 14
Contabilidad √ √
Álgebra √
Inteligencia artificial √√√√√ ½ √ √ ½ √
Teoría de autómatas √
Cálculo √
Ciencia cognitiva √ √
Los compiladores √ √ √
Estructuras de ordenador √
Tendencias en Informática √
Bases de datos / Gestión de Datos √ √
Sistemas distribuidos √
Computación evolutiva √ √
Sistemas expertos ½ ½
Idioma extranjero √
Procesamiento de imágenes √ √ √
Internet √
Negocios Internacionales √ √
Lógica √ √




Márketing √ √ √
ML (lenguaje de programación) √ √
Redes / Redes √
Métodos numéricos √
La optimización combinatoria √ √
Reconocimiento de patrones √
Sistemas paralelos √ √ √
Prólogo √ √
robótica √
Simulación √
Estadística √
Telecomunicaciones / Sistemas de Comunicación √
Realidad virtual √ √
Opcional especificado (número) 1 3
Opcional especificado (créditos) 120 120
no opcional especificado (número) dieciséis 5 3
no opcional especificado (créditos) 20
Proyecto / Estudio (créditos) √ (40) √ (40) √ √ √

Resumen



Cursos opcionales disponibles

Cursos obligatorios
Cursos obligatorios
Cursos obligatorios
Cursos obligatorios
Cursos obligatorios
Ingeniería de Software Introducción 2 2 6 1
ISO / IEC 12207 procesos primarios 1 7 1 6 2 4 7 1
Proceso de desarrollo 1 7 1 6 2 3 7 1
Los sujetos generales 2
Análisis de requisitos del sistema / software 1 2 1
El software de diseño detallado 1 1 1 1 2 1 4
La codificación de software 4 4 1
Pruebas de software 1 1
ISO / IEC 12207 Apoyando los procesos de ciclo de vida 1 1 1
Proceso de Aseguramiento de la Calidad 1
Proceso de Verificación y Validación 1 1
ISO / IEC 12207 Procesos ciclo de vida organizacional 2 2 1 1
Proceso de gestión 2 2 1 1
Temas especiales 1 3
Otros cursos 11 29 15 21 18 2 20 28 14

Apéndice E.
Programas de grado en Ingeniería de Software - Clasificación de
los cursos por disciplina relacionada


Computación / Ingeniería de Software con Estudios de Negocios de la
Universityof Nueva Gales del Sur, Sydney, Australia Licenciatura en


Ingeniería de Software
Cursos obligatorios
Comunicación 1 1 1
Habilidades de Comunicación y Asuntos Profesionales √ √
Comunicación técnica y escritura √
Ciencias de la Computación 8 8 11 10 7
algoritmos √ √ √
Inteligencia artificial √
C ++ √ √ √ √
Los compiladores √
Métodos Computacionales / Computing √ √ √
Ciencias de la Computación √ √
Sistemas concurrentes / Programación √

Bases de datos / Gestión de Datos √ √ √ √ √ √
Estructuras de Datos / Organización de datos √ √
Gestión de archivos √
Fundamentos de Ciencias de la Computación √

Programación √ √
Semántica √
Simulación √
Taller de software √ √ √ √
Ingenieria Eléctrica 1 1 3 1 3
Arquitectura de Computadores √ √ √ √
Organización Digital Computer √ √

Hardware √ √
Los microprocesadores √
administración 5 4
Contabilidad √
Administración de Empresas √ √ √
Economía √ √ √
Márketing √
Matemáticas 2 1 3 5 7
Álgebra √
Cálculo √ √
Matemáticas discretas √ √ √ √ ½
Lógica √ √ √ ½ ½
Matemáticas √ √
Estadística √ √ √
Gestión de proyectos 1
Proyectos / Software de Gestión √

Ciencia 4
Química √
Mecánica √
Física √ √




Telecomunicaciones / Redes 1 2 3
Redes / Redes √ √ √
Telecomunicaciones / Sistemas de Comunicación √ √ √
Cursos opcionales dominios

de aplicación 1
Ciencia cognitiva 1 1
Ciencia cognitiva √ √
Comunicación 1
Idioma extranjero √
Ciencias de la Computación 24 20 1 13
Inteligencia artificial √√√√√ ½ √ √ ½ √

Teoría de autómatas √
Programación comercial √ √
Comparación de los lenguajes de programación √ √
Los compiladores √ √ √
Estructuras de ordenador √
Tendencias en Informática √
Bases de datos / Gestión de Datos √ √
Sistemas distribuidos √
Computación evolutiva √ √
Sistemas expertos ½ ½
Human Interface / User √ √
Procesamiento de imágenes √ √ √
Internet √
ML (lenguaje de programación) √ √
Sistemas paralelos √ √ √
Reconocimiento de patrones √
Prólogo √ √
Programación √
Lenguajes de Programación Principios √ √

Métodos de programación √ √
robótica √
Simulación √
Realidad virtual √ √
administración 5 4
Contabilidad √ √
Negocios Internacionales √ √
Márketing √ √ √
Gestión estratégica √ √
Matemáticas 4 2 2
Álgebra √
Cálculo √




La optimización combinatoria √ √
Lógica √ √
Métodos numéricos √
Estadística √
Gestión de proyectos 1 1
Planificación de proyectos √ √
Ingeniería de software 2 1
Los métodos formales / lenguajes de especificación √
Verificación, validación y pruebas √ √
Telecomunicaciones / Redes 1 1
Redes / Redes √
Telecomunicaciones / Sistemas de Comunicación √
Opcional especificado (número) 1 3
Opcional especificado (créditos) 120 120
Proyecto / Estudio (créditos) √ (40) √ (40) √ √ √

Ética
Ciencia

Matemáticas
administración
Comunicación
Ciencia cognitiva
Ingenieria Eléctrica
Gestión de proyectos
Ciencias de la Computación
Telecomunicaciones / Redes
no opcional especificado (créditos)

no opcional especificado (número)
2
1
1
Cursos obligatorios
20
1
1
4
5
1
1
Tabla de resumen
1
5
1
1
Cursos obligatorios
8 24 8 20 11 1 10
1
2
4
1
1 Cursos opcionales disponibles
1
3
3
Cursos obligatorios Universidad de Londres, Reino Unido Imperial College de Ciencia,
Tecnología y Medicina Ing Informática (Ingeniería de Software)
1
dieciséis
2
5
1
1
Cursos obligatorios
5
3
7
4
1
4
3
1
Cursos obligatorios
7 13
13
1
2
63
Apéndice F.
Programas de Posgrado en Ingeniería de Software - Requisitos
de Admisión por disciplina relacionada

Específico
Necesario
grados
Matemáticas
algoritmos
algoritmos
Matemáticas
Programación
Estructuras de datos
Experiencia requerida
de grado) No especificado
Ingeniería de software
La compilación de técnicas
Mantenimiento del software
Desarrollo de software
Análisis de requerimientos
Graduate Record Exam
Organización de computadoras

De licenciatura
Licenciado en Informática o equivalente
Programación comparativos Idiomas

Experiencia (puede ser utilizado para la aceptación en lugar
Cursos / Conocimiento
3
2
Universidad Andrews - Michigan Maestría en Ingeniería de Software de
√
√
√
√
√
Carnegie Mellon University - Pittsburgh, PA Maestro de SE Concordia -
Montreal, QC Master en Ciencias de la Computación - Universidad
√
√
√
O*
O*
Opción SE DePaul Chicago, IL - MS en SE - Concentración de
desarrollo de software Embry-Riddle University - Daytona Beach , FL
3
√
Maestro de SE Flinders University of South Australia, Australia Maestría
en la Universidad del Estado de Kansas SE - Manhattan, KS Maestría
1
1
1
√
√
√
en la Universidad de Monmouth SE, West Long Branch, Nueva Jersey
MS en el SE
√
√
1
1
3
√
√
√
√
√
√
3,0 2,5 a
√
√
√
√
3.0
Universidad Tecnológica Nacional - Fort Collings, CO

MS en SE
8
Universidad Nacional - La Jolla, CA MS en la Universidad SE Seattle
√
√ o
- Seattle, WA Maestro de SE Universidad Metodista del Sur - Dallas,
1
TX MS en el sureste de Texas Christian University - Fort Worth, TX
√
√
√
Maestro de SE Universidad de Quebec en Montreal - Montreal, QC
√ o√o
√
√
4.0
3,0 /
2
√
√
√
3,0 3,0 /
√
√
√
√
4.3
M.Sc.A. en la Universidad SE de Calgary - Calgary, AL maestría con
especialización en en la Universidad SE de Colorado - Colorado

2
√
√
√
3.0
Springs, CO Maestro de Engineerig con la opción en la Universidad
SE de Houston - Clear Lake - Houston, TX MS en la Universidad SE

2
de Karlskrona / Ronneby - Suecia MS en SE

1
√
√
√
Universidad de Maryland - College Park, Maryland Maestría en la

1
√
√
4.0
3,0 /
Universidad de Missouri-SE Kansas City MS en Ciencias de la
Computación - SE Concentración Universidad de Scranton - Scranton,

7
√
√
Pensilvania MS en el SE
3,0 3,0 /
3
√
√
√
4.0
√ o
Universidad de St. Thomas - Minneapolis, Minnesota MS en la

√
√
2.7
Universidad de Stirling SE - Stirling, Escocia MS en el SE

1
√
√
sesenta y cinco
Unix
Cálculo
Matemáticas
Estadística
Bases de datos
Matemáticas
Programación
Álgebra lineal
Ingeniería general
Análisis de los datos
Computación digital
Sistemas operativos
Estructuras discretas
Ingeniería general
Circuitos y Dispositivos
Procesamiento de archivos
Matemáticas discretas
Métodos de programación
Arquitectura de Computadores

La interacción persona-ordenador
Probabilidad / Procesos estocásticos

Principios de la Organización de hardware
3
√
√
√
√
√
√
√
√
√
O*
O*
√ √ √
√
√
MS en el SE
√
√
√
√

MS en SE
2

√
√
√
√
√
√
√
√ √

√
√
√
√
√
√
√
√

√
√

1
√
√
√

1
√
√

√

2
4
√
√
√
√
√
√
√
√ √
√ √
√ √
1
1
√
√
√
√
√

66
√
redes
Métodos formales

dos
* Se requieren

1
MS en el SE
1

MS en SE

1

1

1

1

67
Matemáticas
Ingeniería general
Resumen

Cursos requeridos / Conocimiento
3
Universidad Andrews - Michigan MS en
327
Experiencia opcional Ingeniería de Software
1
Carnegie Mellon University - Pittsburgh, PA Maestro de SE
Experiencia opcional
3
Concordia - Montreal, QC Master en Ciencias de la
Experiencia opcional Computación - Opción SE
1
DePaul Universidad de Chicago, IL - MS en el
11
11
Experiencia opcional SE

Embry-Riddle University - Daytona Beach, FL Maestro de SE

Universidad Flinders de Australia del Sur, Australia Maestro de SE

Universidad del Estado de Kansas - Manhattan, KS Maestro de
11
11
34
Monmouth University, West Long Branch, Nueva Jersey MS en el SE

Experiencia opcional MS en SE

2
8
Universidad Nacional - La Jolla, CA MS en el


1
Universidad de Seattle - Seattle, WA Maestro

Experiencia opcional de SE

1
Universidad Metodista del Sur - Dallas, TX MS en el SE


2
Texas Christian University - Fort Worth, TX Maestro de SE

3
2
Universidad de Quebec en Montreal - Montreal, QC

Experiencia opcional M.Sc.A. en el sureste

1
2
Universidad de Calgary - Calgary, AL maestría con

Experiencia opcional especialización en en el SE

1
1
2
Universidad de Colorado - Colorado Springs, CO Maestro de

Experiencia opcional Engineerig con la opción de SE

1
1
1
Universidad de Houston - Clear Lake - Houston, TX


1
Universidad de Karlskrona / Ronneby - Suecia MS en el sureste


1
Universidad de Maryland - College Park, Maryland Maestro de SE


2
4
7
Universidad de Missouri-Kansas City MS en Ciencias de la

Experiencia opcional Computación - SE Concentración

3
1
1
Universidad de Scranton - Scranton, Pensilvania MS en el SE

Universidad de St. Thomas - Minneapolis, Minnesota

1
Universidad de Stirling - Stirling, Escocia MS en el SE

68
Apéndice G.
Programas de Posgrado en Ingeniería de Software -
Clasificación de los cursos de acuerdo a áreas de conocimiento potenciales

grados
créditos
C ++
Diseño
Cursos básicos
Los sujetos generales

Human Interface / User

Métodos de desarrollo / Metodologías

Diseño Orientado a Objetos / Modelado

Análisis de Requerimientos / Especificaciones
Ingeniería de Software / ES Ingeniería
Los métodos formales / lenguajes de especificación

Entornos y herramientas de desarrollo de software
r)
2
2
2
2
Universidad Andrews - Michigan Maestría en Ingeniería de Software de la
48
√ √
√ √
(quarte
Universidad Carnegie Mellon - Pittsburgh, PA Maestro de SE Concordia -
créditos
1
1
2
2
?
√
√
Opción SE DePaul Chicago, IL - MS en SE - Concentración de desarrollo
√
1
1
3
4
de software de DePaul University - Chicago, IL EM en la SE -
√
45
1
Concentración de Gestión de Proyectos de la Universidad Embry-Riddle -
Daytona Beach, FL Maestro de SE Flinders University of South Australia,
1
2
2
1
6
6
1
?
√
√
√
√
√
2,5 /
½½
Australia Maestría en la Universidad del Estado de Kansas SE -
½½½
Manhattan, KS Maestría en la Universidad de Monmouth SE, West Long
1
2
1
1
5
5
1
?
√
√
√
√
4,0 2,5 / 4.0
Branch, Nueva Jersey MS en el SE

36
1
1
2
2
1
√
√
crédito)
(horas de
33
1
1
1
1
√
√
crédito)
(horas de
1
2
4
4
√
√
√
36
33
1
1
2
2
7
7
√
√
√
√
√
(SEM.
Créditos)
MS en SE
60
1
1
2

√
√
3.0
quarte r)
(unidades

45
1
1
3
3
1
√
√
(Grad.
Créditos)
30
1
2
2
1
√
√
4.0
(SEM.
Hrs de
3,0 /
crédito).
1
2
3
1
31
½
√
(SEM.
Horas)
1
2
4
5
√
√
√
45
M.Sc.A. en la Universidad de Calgary SE - Calgary, AL maestría con
especialización en la Universidad de SE de Colorado - Colorado

2
2
2
?
√ √
Springs, CO Maestro de Engineerig con la opción en la Universidad de
Houston SE - Clear Lake - Houston, TX MS en el SE

1
2
3
4
√
√
√
3.0
√√
√
36
1
2
4
4
2
4
crédito)
(horas de
√3
1
1
3
3

40
√
√
pts
1
1
2
2
1

√
√
√
36

√
√
1
1
2
2
1
√
3.0
1
2
1
4
4
√
√
√
√
36
1
1
1
3
3

√
½
½
42

70
Pruebas
Confiabilidad
Estimacion
Productividad
Mantenimiento
Gestión de TI
Proceso de gestión
Implementación
mejora de procesos
Seguro de calidad
Modelos de Ciclo de Vida

Economía software
Planificación de proyectos

Verificación y validación
Procesos de Software / Sistemas

Proyectos / Software de Gestión
Proceso de Verificación y Validación

1
1
√
1
1
√
√
√
√
2
2
2
3
1
1 de software de DePaul University - Chicago, IL EM en la SE -
√
√
2
2
2
√ √
2
2
2
√
½
1
1
1
√
√
1
1
√
1
1
1
1
1
√
√
√
1
2
3
1
1
1
2
√
√
√
√
√
√
√
MS en SE
1
1
1
1
1
½
√
√

1
1
1
1
√
√
√
2
2
1
2
1
½
½
½
½½½
½½½
1
1
1
1
1
1
½
√
1
1
2
1
1
1
1
√
½1
½1

1
1
1
1
√
√

2
2
1
1
1
√
√
√
√
1
1
1
2
1
1
1
√
√
√ √
√ √
4
4
2
2
2
1
1
1

½
½
√
√
√
1
3

√
√
√
1
1
√
1
1
1
1

√
√

71
CASO
Reutilizar
Otros cursos
Temas especiales
algoritmos
reingeniería
Matemáticas
Redes / Redes
Inteligencia artificial
Sistemas distribuidos
Seguridad de información
Sistemas concurrentes
Las métricas de medición /

El software de seguridad / Seguridad
El análisis de artefactos de software
Análisis de datos y Regresión

Bases de datos / Gestión de Datos
Hardware y software para la integración

Fundamentos de Ciencias de la Computación / SI
Las tendencias actuales en Ingeniería de Software
En tiempo real Software / Sistemas Embebidos
Corriente / especiales / Temas avanzados en el sureste

4
√
√
√
2
√
√
1
√
1
1-2
√ √ √
3
1
√ √
1
3
√ √
1
1

√
MS en SE
7
√
√
√
√
√ √
5

½
√
½
1
√
√
1
1-3

2

√
2
√
√
√
2
2
√
√
√
√
1
1
1
2-3
2-3
3
½4
½2
½4
½2
√3
√4
1

√

√

4
√
√
2
√
√
2

√
√

72
Software
Inalámbrico
protocolos

Análisis de los datos

la Ingeniería de Software
Sistemas operativos
Proceso de investigación
software de Adquisición
Enfoque cuantitativo
Gestión organizacional

Los métodos de desarrollo de software

Comunicación técnica y escritura

Arquitectura de Software / IS Arquitecturas

- Cursos electivos especificados Introducción a
Telecomunicaciones / Sistemas de Comunicación
a la Ingeniería
√
√
2
1
6
6
√
1
√2
3
3
1
√
√
√
√
√
√
12
13
√ √
3
3
1
√
√
√
12
13
√ √
√ √
1
1
3
3
½
√
√
1
3
3
√1
√
1
1
1
√
1

MS en SE
½
1
4
5
√
√
√
1
3
1
5
1
√
√
√
3
3
√
√
1

1
2
8
8
√
√
√
½

1
1
1
√
√

1
2

√

2
2
√
1
1
1
2
6
6

√
√ √

73
2
1
6
6
√
√
Diseño
Pruebas
Confiabilidad
Estimacion
Mantenimiento
Gestión de TI
Proceso de gestión
Implementación
Seguro de calidad


Verificación y validación

Los procesos de verificación y validación
Factores Humanos / Recursos Humanos


1
1
2
√2
√2
√1
√1
√1
3
3
1
3
1
2
2
2
2
√
√
√
√
√
√
½
√ √
√ √
1
1
1
3
1
2
2
2
2
√
√
√
√
√
√
√ √
√ √
1
3
1
√
√
1
1
1
√2
√2
√1
1
1
1
1
1
√
½

MS en SE

1
1
2

√
√
√ √
1
2
√
√
√
2
2
1
2
½
½
√
√
√

4
6
1
4
√
√
√
½
√ √

1
1
1
1
√
√

4
4
1
2
1
1

√
√
√ √

2
√ √
1
√
1
2

√
√
√ √

74
1
1
1
1
1
2
√
√
√
√
½
ADA
CASO
Reutilizar
Otros cursos
Temas especiales
algoritmos
Los compiladores
Control de Proyecto
mejora de procesos
Economía software
Gestión estratégica
Teoría computacional
Sistemas cliente-servidor
Herramientas de productividad

Geometría Computacional
Riesgo / Análisis coste-beneficio
Modelado de Procesos de Software

Mejora de Procesos de Software

7
1
√
√
4
2
√
√
√
7
1
√
√
5
5
2
√
√
√
√
√
√ √ √
4
2
√2
√1
8
4
√
√
√ √
7
√
√
MS en SE
6
3
√
√
√
√
1
1
√
√
2
½
½
√
√
10
4

2
1
2
√
√
½
½
√ √

√
31
√ √
√ √

7
1

√
√
√
√

√
1
19
√ √ √
1
3
√
√
√
2

√
√
√
14
√ √

75
7
2
√
√
√
√
Multimedia
Matemáticas
Redes / Redes
Sistemas digitales
Sistemas expertos
Sistemas de control
Análisis de dominio
Visión por computador
Los microprocesadores
Nuevas tecnologías
Gráficos de computadora
Adquisición de hardware
Tecnologia computacional
El rendimiento del equipo

Aspectos legales del software
Sistemas basados en el conocimiento
Procesamiento de Lenguaje de ordenadores
Ordenador / Optimización de Ingeniería
Gestión y Ciencias del Comportamiento


√
√
√
√
√
√
√
√
√
√
√1
√ √1
√
√
√
√1
√1 √2
√
√ √ √
√
√
√
√
√
MS en SE

√
√
√
√
√
√
√
√
√
√
√
√
√
√
1
1
1
1

√

√
√
√
√
√
√
√ √
√ √
√ √
√ √ √

√
√

√
√
√
√
√
√ √
√√√√
√

√
√
√
√ √
√ √

76
√
√
½
½
Unix
idiomas
robótica
protocolos
Simulación
Número a elegir
Los créditos para satisfacer

Semiconductores
Sistemas paralelos
Ingeniería Nuclear
Sistemas operativos
Ingeniería Química
Ingeniería Industrial
Sistemas de información
Ingeniería mecánica

Administración de gestión
Diseño (no diseño de software)
Electivas - Disciplinas especificada
Las bases de datos orientadas a objetos
Telecomunicaciones / Sistemas de Comunicación

√
√
√
√
√
√
√
√ :? -
√ yo: 1
√
5 √: 4 -
√1
√ 1: 1
√
6-9
√
√
√
√
√
√
√2
√ 2: 1
√ 1: 2 -
5
√
√ √ √
√
MS en SE

9

hrs.
3
4
√
√
√

2
√

?
√
√
√
√ √
√ √ √
√ √ √

3

√
√

√
*4
√ √ √

√
√
√
√
√

E: E 5: 8
77
√
½
√:
Información
Necesario
Número a elegir
Proyecto - Tesis
Ciencias Sociales
Tesis (créditos)
Filosofía / Ética
Maestría en Ciencias
½: Parte de un curso EM:
Optativas - para no especificados
Proyecto / Estudio (créditos)

Número de cursos para elegir

Psicología / Ciencia Cognitiva
M.Sc.A .: Master en Ciencias Aplicadas ES:

Sistemas de Información TI: Tecnología de la
4
24
√ √
√
1
2:
√
√
√
√
30%
(8) √ ( 40%) √ ( 9) √ ( 1
)
curso
√ (?)
La especialización de Control de Calidad

s
1
+1
curso
√ : La especialización del sistema artchitecture

Master
o
6-9
√ (9)
√ (3)
2
1
√ (6) √ ( 6) o
√ (6)
2
2

√
MS en SE

√ : opción de Telecomunicaciones
√ √

(?) √ ( 9)

3
√
cursos)
(2
√
2:
1
√
2√2

√ : opción SI

Opción de integración
(12) √ (?) √ (?) √ ( 6

√
3
2:
1
hrs) o
horas)
√ (6
√
pts)

(1020
√ : Pista de seguridad

Reutilización / reingeniería de pista

√ :Pista Gestión de la Información
√ ( 3) √ (?)
o

√ (?)
√ (6) √ ( 6)

78
* Dependen de la concentración elegida

√3
meses
Análisis
Software del sistema

Resumen


requisitos
2
2
2
2
Cursos requeridos Universidad Andrews - Berrien Springs, MI Maestría en Ingeniería de
cursos electivos
Software de la Universidad Carnegie Mellon - Pittsburgh, PA Maestro
disponibles cursos
1
1
2
2
requeridos cursos de SE Concordia - Montreal, QC Master en Ciencias de la
electivos disponibles
Computación - Universidad Opción SE DePaul Chicago, IL - MS en SE
cursos requeridos
cursos electivos - Universitario de Software Concentración Desarrollo DePaul -
11
disponibles cursos
Chicago , IL MS en SE - Concentración de Gestión de Proyectos de la
requeridos cursos
electivos disponibles Universidad Embry-Riddle - Daytona Beach, FL Maestro de SE
11313
12222211
12231311
2
cursos requeridos
3 6 6 12 5 12 2 3
4 6 6 13 5 13 2 3
1212
11111
cursos electivos
disponibles cursos
2
requeridos cursos
cursos requeridos
1
cursos electivos
disponibles cursos
requeridos cursos Universidad Flinders de Australia del Sur, Australia Maestro de SE
cursos requeridos
1
1
cursos electivos Universidad del Estado de Kansas - Manhattan, KS Maestro de
1
disponibles cursos SE
11
11
13417
13417
requeridos cursos
2
electivos disponibles Monmouth University, West Long Branch, Nueva Jersey MS en el SE
1
Cursos requeridos
11
cursos electivos
1
1
2
2
disponibles cursos Universidad Tecnológica Nacional - Fort Collings, CO
requeridos cursos MS en SE
1
1
1
2
cursos requeridos Universidad Nacional - La Jolla, CA MS en la
cursos electivos
Universidad SE Seattle - Seattle, WA Maestro
disponibles cursos
de SE
11
12
requeridos cursos
1111
cursos requeridos
1
3423234
3525335
cursos electivos Universidad Metodista del Sur - Dallas, TX MS en el SE
111
1
disponibles cursos
requeridos cursos
1
2121
electivos disponibles Texas Christian University - Fort Worth, TX Maestro de SE
1
cursos requeridos
cursos electivos
1
2
disponibles cursos Universidad de Quebec en Montreal - Montreal, QC
requeridos cursos M.Sc.A. en la Universidad de Calgary SE - Calgary, AL maestría con
cursos requeridos
especialización en la Universidad de Colorado, SE - Colorado
212
1
2
cursos electivos Springs, CO Maestría en Ingeniería - opción SE Universidad de

41
28314
28414
disponibles cursos
requeridosCursos
Houston - Clear Lake - Houston, TX MS en el SE
12
cursos requeridos
1
1
cursos electivos
disponibles cursos
requeridos cursos
1
1
1
3
3
electivos disponibles Universidad de Karlskrona / Ronneby - Suecia MS en el sureste

cursos requeridos
cursos electivos
1
1
1
disponibles cursos Universidad de Maryland - College Park, Maryland Maestría en la

1
1
requeridos cursos
21224
1
1
1

22224136
1
2
1
1
12
11
12
36
Universidad de St. Thomas - Minneapolis, Minnesota MS en el SE

1
79

1
2
2
1
6
6
procesos
procesos
Otros cursos
Temas especiales
ISO / IEC 12207 Org.
Proceso de gestión
mejora de procesos
ISO / IEC 12207 Supp.

Resumen

Proceso de Verificación y Validación
Ciclo vital
Ciclo vital
1
1
4
Universidad Andrews - Berrien Springs, MI Maestría en Ingeniería de
Software de la Universidad Carnegie Mellon - Pittsburgh, PA Maestro de
1
1
2
SE Concordia - Montreal, QC Master en Ciencias de la Computación -
Universidad Opción SE DePaul Chicago, IL - MS en SE - Universitario
2
2
2
1
11
11
31
de Software Concentración Desarrollo DePaul - Chicago , IL MS en SE -
Concentración de Gestión de Proyectos de la Universidad Embry-Riddle
1-2 7 4 4 3 7 1 5
- Daytona Beach, FL Maestro de SE Flinders University of South
2
1
3
1
Australia, Australia Maestro de SE Universidad Estatal de Kansas -
211
Manhattan, KS Maestría en la Universidad SE Monmouth, West Long
32111
32113
2
1
Branch, Nueva Jersey EM en el sureste

11
31
5
2
1
1
2
11
438
1
1112
112
41
11
12
1
1

MS en SE
77
1
1
1
1

1
1
1
1
56

3
1

2
2
1
1
2
11
1
1
1
122
2
21
1
1
1
1
1 1 10 1-3 4 2 2 2 31 2-3

1
1

12
Springs, CO Maestría en Ingeniería - opción SE Universidad de

16212
1
4211
Houston - Clear Lake - Houston, TX MS en la Universidad SE de

11
111
Karlskrona / Ronneby - Suecia MS en SE

1
1
1 2-3
2
2
1
1
2
2
14
34

1
1
2

2 7 4 19 2 1 2 14
1
1
1
3
1
1
1
1
1

2

80
7
1
1
1
1
1
Apéndice H.
Programas de Posgrado en Ingeniería de Software - Clasificación
de los cursos por disciplina relacionada

grados
créditos
C ++
Comunicación
protocolos
algoritmos
Cursos Básicos de
Implementación
Sistemas operativos
Seguridad de información
Sistemas concurrentes

Humano / Interfaz de usuario / Interacción

Comunicación técnica y escritura
Fundamentos de Ciencias de la Computación / SI

r)
1
3
48
√
√
√
(quarte
créditos
?
√
√
45
1
2-4
4
?
√
4.0
2,5 /
√ √ √
3
?
√
4.0
2,5 /
√ √
36
crédito)
(horas de
72
33
crédito)
unidades (horas de
1
36
33
Universidad Tecnológica Nacional - Fort Collings, CO MS en la Universidad
√
(SEM.
Créditos)
Nacional SE - La Jolla, CA MS en la Universidad SE Seattle - Seattle, WA

60
1
3
Maestro de SE Universidad Metodista del Sur - Dallas, TX MS en el

√
3.0
√ √
quarte r)
(unidades
sureste de Texas Christian University - Fort Worth, TX Maestro de SE

45
3
1

½
√
√
½
(Grad.
Créditos)
30
4.0
(SEM.
3,0 /
Créditos)
1
31
√
(SEM.
Horas)
√
√
45
1
1-2

?
Springs, CO Maestría en Ingeniería con la opción en la Universidad
de Houston SE - Clear Lake - Houston, TX MS en el SE

1
√
3.0
√
En 1 a 3
√
√
√
√
36
1
1
1
3
crédito)
√3
(horas de

40
pts

√
36

3
√
√
3.0
1
√
36

1
1
√
√
42

82
CASO
Diseño
Matemáticas
administración
Inalámbrico
Estimacion
Productividad
Matemáticas
Mantenimiento
Gestión de TI
Modelos de Ciclo de Vida

Economía software


El análisis de artefactos de software
Análisis de datos y Regresión

Hardware y software para la integración

4
1
√
√
4
1
√
√
√
√
√
√
4-5
2
√
½½½
6
2
1
½
√
√
½
5
1
2
1
√
√
√
√
√
1
√
√
√
√
√
10
4
1

½
√
√

4
1
1
√
√
√
4
2
½
½
1
½
½
√
√
2
1
√
√
√
1
1
½1
6 abril-5 julio

√

√
1
1
√
√
√
√
√
√
2
√√
1
√4
√3
4 mayo hasta 5 agosto
2

½
√
√
5
1

√
√
√

√
2
4
1
1
√
√
√
√

5
1
√
√

83
Otros
Reutilizar
Confiabilidad
reingeniería
Redes / Redes
Orientado a objetos
Seguro de calidad

Electivas - cursos específicos
Métodos SE / metodologías


Verificación, validación y pruebas

Enfoque cuantitativo de Ingeniería

Telecomunicaciones / Comm. sistemas

Entornos de desarrollo y herramientas
√ √
√ √
√
√
√
√
√
1
√
1
1
2
√ √
2
√
√
√
√
½½
√
√
√
√
√
√
1
2
√
√
√
√ √
1
√
√
√
√
√
√
1
1
√
√
√
√
½

√
√
√
½
√
√
½½½
√
½
√
½1

1
√
√
√
√ √

√
√
1
√
√
√
√
4
½4
½2
½4
½2
√ √
4

½
√
√
√

√
√
√
√

√
√
√
√
√
√

√
√

84
ADA
algoritmos
Los compiladores
Sistemas expertos
Los dominios de aplicación
Sistemas de control
Análisis de dominio
Visión por computador

Gráficos de computadora

Teoría computacional
Tecnologia computacional
Sistemas cliente-servidor
El rendimiento del equipo

Geometría Computacional
Los sistemas basados en el conocimiento

Procesamiento de Lenguaje de ordenadores
Ordenador / Optimización de Ingeniería
Análisis de datos y software estadístico


8
√
√
√
√
√
√

9
½
√
√
√
√
√ √

9
√
√
√
√
√ √1
9
√
√
√
√
8
√
√
√ √ √
5
√1
√1 √2
4
√
3
√
√
√

8
√
√
√
√
√
√ √
3
√
√
√
½
√
√
√
√
√
√
10
√
√
3
1
1

2
1
√ √

√
√
√
√
√
21
√ √
√ √
√ √
√ √

4

√
√
√

√
√
12
√ √
√ √ √
3
√
√

√
√
√
15
√ √
√ √

85
√
√
√
√
√
½
Unix
administración
robótica
protocolos
Simulación
Multimedia
Programación
Gestión de TI
Sistemas digitales
Semiconductores
Ética / Aspectos Legales

Sistemas paralelos
Los microprocesadores
Nuevas tecnologías
Sistemas operativos

Aspectos legales del software

Las bases de datos orientadas a objetos
Factores Humanos / Recursos Humanos
Gestión y Ciencias del Comportamiento

√
√
√
√
√
√
√1
√
√
√
√ √ √
√
√
√ √
√2
√2
√
√ √
2
√
1
√
√
√
1
√
1
1
½
√
√
√
√
√
√
1
1
1

2
√
√

1
3
√
√
√
√
√
√ √
√ √
√ √ √

3
√
√ √

√
√
√
√
√ √
√

3
√
√
√
√
√
√
√
√ √
√ √

86
√
½
CASO
Diseño
Matemáticas
Estimacion
Matemáticas
Mantenimiento
Control de Proyecto
Implementación
Orientado a objetos
Seguro de calidad
Economía software
Gestión estratégica
Herramientas de productividad

Riesgo / Análisis coste-beneficio



√
√2
√1
√1
3 Daytona Beach, FL Maestro de SE Flinders University of South Australia,
√
√
√
√
√
√
√
½
12

1
√
√
√
√
13
√ √
√
√
√
√
6
√
√
√
3
√1
√1
5
1
√
√
½
√
1

5
√
√
√
√
2
√
√
√
4
½
√
√
1

9
3
√
√
√
√
½
½
½
½

3
√
√

4
1

√
√
√

√
1
3
√
√
3
1

√
√
√

87
6
1
√
√
√
√
√
√
Otros
especificado
Reutilizar
Confiabilidad
Número a elegir
Redes / Redes


Modelado de Procesos de Software
Telecomunicaciones / Comm.
Mejora de Procesos de Software
Los métodos de desarrollo de software
Herramientas para la Ingeniería de Software
Verificación, validación y pruebas


Optativas - Disciplinas de las Ciencias del ordenador

Líneas de Investigación en Ingeniería de Software
√
√
√2
√1
√ :? -
√ yo: 1
√
√
√
√
√
√ √
5 √: 4 -
1
√
√
√
√
√1
√ √
√ √
√ 1: 1
√
√
6-9 27
√
√
√
unidades
1
√
√2
√1
√ 2: 1
√ 1: 2 -
5
6
½
√
√
√ √ √
√ √ √
1
√
9
√
hrs.
3
1
√
√
4
1
½

2
√
√
√ √

?
6
√
√ √ √
√ √ √

3
1

2
√
√
½
½
½
½

8
√
√√√√
√ √ √
4
√
5
1

√
√

88
8
2
√
½
½
idiomas
Tesis (créditos)
administración
Número a elegir
Proyecto - Tesis
Ciencias Sociales

Proyecto / Estudio (créditos)

Ingeniería Nuclear
Optativas - para no especificados

Ingeniería Química
Ingeniería Industrial
Sistemas de información
Ingeniería mecánica

Número de cursos para elegir
Diseño (no diseño de software)
Psicología / Ciencia Cognitiva

Otras disciplinas de ingeniería
√√
√
4-24 30%
(8) √ ( 40%
)
√
√
√
√
√
√
√
√
√
1:
√
(9)
)
curso
√ (1
√ (? )
+1
curso
Master
√
o
6-9
Arquitectura del Sistema Especialización

(9)
√ (3)
√√
(?)
√ √
2
6
√
√
√
√
√
(?) √ ( 6) √ ( 6)
o
√
√ (6)
1:
2
2
√
√√
(?) √ ( 9)
opción de Telecomunicaciones
3
)
platos
√ (2
1
√
(12)
2√2
√ : opción SI
√ (? )

√

(?)
1
√
horas)
(6
horas) o
√ (6
pts)

√ (1020

√ ( 3)

√

O
√ (?)
(?)
√
√ : Pista de seguridad √ 2: Reutilización / reingeniería de pista

√(6)

(6)

89
√ 3
meses
Información
Maestría en Ciencias
½: Parte de un curso EM:

M.Sc.A .: Master en Ciencias Aplicadas ES:
Sistemas de Información TI: Tecnología de la


2

√ : La especialización de Control de Calidad

2

√ : Opción de integración

√ 3: Pista de Gestión de Información √ 4: Procesos de Software Pista
90
Otros
Diseño
Cognitiva
idiomas
ingeniería
Matemáticas
administración
Comunicación
Ciencias Sociales
Otras disciplinas de
Psicología / Ciencia
Los dominios de aplicación

Resumen

4
1
1
Cursos requeridos
3D
cursos electivos
disponibles cursos
1
requeridos cursos
re
re
re
re
re
re
D1
cursos requeridos
1
2
cursos electivos
disponibles cursos
Computación - Opción SE
D 2-4 8 4 9 3 9
requeridos cursos
1
4 D 4-5 6 6 12 6 13 5 6
DePaul Universidad de Chicago, IL - MS en SE - Concentración de
cursos requeridos
desarrollo de software
cursos electivos
3211
disponibles cursos
DePaul Universidad de Chicago, IL - MS en SE - Gestión de
requeridos cursos
1
Proyectos Concentración
cursos requeridos
cursos electivos
1
9
disponibles cursos
requeridos cursos
8
cursos requeridos
1
cursos electivos
disponibles cursos
re
5D
SE
D1
requeridos cursos
126
6 2 3 5 5 10 D 4
Cursos requeridos
11
cursos electivos
disponibles cursos
12
413D3
requeridos cursos
1
1
MS en SE
1
1
1
cursos requeridos
cursos electivos
SE
disponibles cursos
1
1
1
requeridos cursos
38

1
de SE
cursos requeridos
2
cursos electivos
4 5 4 2 4 4 6-7
disponibles cursos
1
3
requeridos cursos
1
1
cursos requeridos
1
1
11
cursos electivos
disponibles cursos
21
01 al 02 10 3

requeridos cursos
1
M.Sc.A. en el sureste
1
1
cursos requeridos
cursos electivos
1
especialización en en el SE
31
disponibles cursos
211
5 9 5 3 4-8
requeridosCursos
2 1 21 1-3
6
3
Engineerig con la opción de SE

cursos requeridos
1
cursos electivos
Universidad de Houston - Clear Lake - Houston, TX MS en el SE
disponibles cursos
requeridos cursos
5
2
cursos requeridos
cursos electivos
disponibles cursos
11

requeridos cursos
2
3
128
21

54214353
2 4 3 12 1 3 1 15
Computación - SE Concentración
1
1

1
11

1
3
91

2
6
1
8
Resumen


Computación - Opción SE
1
DePaul Universidad de Chicago, IL - MS en SE - Concentración de
desarrollo de software
DePaul Universidad de Chicago, IL - MS en SE - Gestión de

Proyectos Concentración

SE

MS en SE
1

SE

de SE

1

M.Sc.A. en el sureste
1

especialización en en el SE

Engineerig con la opción de SE
Universidad de Houston - Clear Lake - Houston, TX MS en el SE

1
1

Computación - SE Concentración

92

Apéndice I.
Proyecto de Clasificación de conocimientos sobre métodos formales basados en la propuesta de esquema de cuatro categorías

Introducción
Como una ilustración de cómo el tema de un área de conocimiento podría ser dividido en Generalmente aceptado, Avanzado, Investigación y Especializado,
presentamos en las páginas siguientes algunas áreas clave de los métodos formales. Para esta presentación, estos temas también se desglosan en
función de las principales fases del ciclo de vida, sin necesidad de utilizar el vocabulario 12207. Los diversos temas incluidos fueron identificados a
partir de un estudio de la literatura informal realizado durante los últimos años (véase más adelante para las referencias que se examinaron) y que
dieron lugar a una bibliografía anotada (las anotaciones están en francés) que contiene actualmente más de 500 entradas. Esta bibliografía sobre
métodos formales se encuentra disponible en la siguiente dirección, donde se puede buscar:
http://www.info.uqam.ca/~tremblay/chercher-reference.cgi
La categorización en general aceptado, se obtuvo avanzada, Investigación y Especializada, Grosso modo, como sigue:
?? Generalmente aceptado: Un tema discutido en una serie de libros de texto de ingeniería (corriente principal) de software.
?? Avanzado: Un tema discutido en numerosos métodos formales libros o documentos relacionados. Tenga en cuenta que este
categoría también incluye un tema (la derivación del programa y verificación) discutido en numerosos libros, incluso las más básicas de programación, pero
rara vez se utiliza en la práctica.
?? Investigación: Un tema discutido en unos pocos (más de 1) los papeles formales de investigación métodos.
?? Especializado: Un tema relevante a sólo ciertos tipos de software.
Las referencias se obtuvieron principalmente, pero no exclusivamente, entre los siguientes:
?? Libros: Principales libros de ingeniería de software y libros dirigidos específicamente a procedimientos formales.
?? revistas: ACM Computing Surveys, CACM, Avisos ACM SIGPLAN, ACT TOPLAS, Computadora
Redes y sistemas RDSI, IEEE Computer, IEEE Software, IEEE Trans. en suave. Eng, Diario de sistemas y software, Ciencias de
Programación, Software -. La práctica y la experiencia, The Computer Journal.
?? conferencias: CONCUR, FME, VDM, AMAST, Verificación asistida por ordenador, Intl. Conf. en suave. Eng.,
Especificación del protocolo, la prueba y verificación, TAPSOFT, ZUM.
Análisis de requerimientos y especificación

• especificación formal del comportamiento abstracto de un sistema (especificación funcional cuadro negro) usando un modelo abstracto o
especificaciones axiomáticas, con pre / post-condiciones (por ejemplo, VDM, Z, Alerce enfoque doble escalón) [Lam88, Pre92, GH93, Som95,
Pfl98].
Avanzado
• La verificación de la consistencia interna de una especificación mediante la generación y descarga de apropiado

prueba obligaciones (utilizando riguroso inspección y/o formal
pruebas) [Jon86, Sha95, BDMW97].
Investigación
• Las especificaciones formales de la conducta abstracta de un sistema usando varios enfoques, por ejemplo, las afirmaciones sobre rastros
[BP78, Jan97], redes de Petri [Rei87, Fur93, BOP97], StateCharts [Har88, HG97], etc.

• Animación de las especificaciones y / o el uso de especificaciones formales para la creación de prototipos formales con el fin de validar los
requisitos [HI88, BM93, WP94, BDMW97].
• especificación formal de interfaces (hormigón) persona-máquina [Ale90, KB97].
• Integración de métodos formales con los requisitos existentes y los enfoques de análisis (por ejemplo, OO se acerca [CHB92,
CA93, AS97, HG97], análisis estructurado [PvKP91, SFD92, GP95]).
Especializado
• el diseño del protocolo de Telecomunicaciones, telefonía, diseño de hardware: especificación formal del comportamiento abstracto,
externo de un sistema (estado finito) (por ejemplo SDL, Lotos, CCS / CSP) + especificación formal de algunas propiedades importantes
que se requieren y / o que se espera del sistema usando modal, temporal
lógica + Verificación de aquellos propiedades utilizando modelo-
comprobar [CES86, Tur93, CWa96, Bru97].
Diseño arquitectonico
• Especificación formal del comportamiento de los módulos por medio de enfoques basados en modelos o máquina abstracta (por ejemplo, VDM,
Z, B) [ Lam88, ALN + 91, Pre92, Som95, Pfl98]. Especificación de tipos de datos abstractos utilizando enfoques algebraicas (por ejemplo, Alerce,
ACT-ONE)
[Som95, Lam88, dMRV92, GH93].
Avanzado
• La verificación de la consistencia interna de una especificación del módulo mediante la generación y descarga de prueba apropiado
obligaciones (utilizando riguroso inspección y / o formal pruebas)
[Jon86, Sha95, BDMW97].
Investigación
• especificación formal de estilos arquitectónicos y los patrones [GA94, Gar95, CM97].
Diseño detallado
Avanzado
• Verificación del refinamiento de los módulos mediante la generación y descarga de obligaciones de prueba apropiados [Jon86,
Sha95, BDMW97, TTOV97].
Codificación y pruebas
Avanzado
• Programa de derivación y formal ( en-el-pequeño) verificación de programas [Gri81, Dro89, AI91].
Investigación
• Derivación de casos de prueba en función de la especificación formal de un módulo (prueba de la unidad de recuadro negro) [DF93, SC96,
NB92, FJJ + 96, Den96, BDMW97].
• transformación automática o semi-automática de especificación para sintetizar software y / o generar código ejecutable
[PAR90, Jul93, SH94].

pruebas de calificación
Investigación
• Derivación de casos de prueba en base a la especificación formal (funcional) de un sistema (pruebas de recuadro negro) [DF93, SC96,
NB92, FJJ + 96, Den96, BDMW97].
referencias
GA94
R. Allen y D. Garlan.
La formalización de la conexión arquitectónica. En Proc. 16a Int'l Conf. Software Eng., páginas 71-80. IEEE Computer
Society Press, 1994.
AI91
D. Andrews y D. Ince.
métodos formales prácticas con VDM.
La Serie Internacional McGraw-Hill en Ingeniería de Software, 1991.
Ale90
H. Alexander.
diálogos utilizando la estructuración de CSP. En Métodos formales en Interacción Persona-Ordenador, capítulo 9, páginas 273-295. Cambridge
University Press, 1990.
ALN + 91
Sr. R. Abrial, MKO Lee, DS Neilson, PN Scharbach, e IH Sorensen. El B-método. En VDM '91: Formales métodos de
desarrollo de software, páginas 398-405. Springer-Verlag, LNCS-552,
1991.
AS97
K. Achatz y W. Schulte.
Un método OO formal, inspirada en la fusión y Object-Z. En ZUM '97: El Z especificación formal de notación, páginas 92-111.
Springer-Verlag, LNCS-1212, 1997.
BDMW97
J. Bicarregui, J. Dick, B. Matthews, y E. Woods.

Aprovechando al máximo la especificación formal a través de la animación, los ensayos y pruebas.
Ciencia de la programación informática, 29 (1): 53-78, 1997.
BM93
P. Borba y S. Meira.
A partir de las especificaciones de VDM a prototipos funcionales.
J. Sistemas de Software, 21 (3): 267-278, marzo de 1 993.
BOP97
L. Baresi, A. Orso, y M. Pezze.

La introducción de métodos de especificación formal en la práctica industrial. En CISE '97
(Intl. Conf. De Soft. Esp.), páginas 56-66, 1997.

BP78
W. Bartussek y DL Parnas.
El uso de afirmaciones sobre los rastros de escribir especificaciones abstractas para módulos de software. En Cooperación
europea en Informática, páginas 211-236. Springer-Verlag, LNCS-65, 1978.
Bru97
G. Bruns.
Distribuido Análisis de Sistemas con CCS.
Serie Internacional en Ciencias de la Computación. Prentice-Hall, 1997.
CA93
E. Casais y al.
Métodos formales y orientación a objetos.
HERRAMIENTAS tutorial en Europa 1993, 1993.
CES86
EM Clarke, EA Emerson, y AP Sistla.

La verificación automática de sistemas concurrentes de estados finitos utilizando especificaciones lógica temporal.
ACM TOPLAS, 8 (2): 244-263, 1986.
CHB92
D. Coleman, F. Hayes, y S. Bear.

La introducción de objectcharts o cómo utilizar gráficos de estado en el diseño orientado a objetos.
IEEE Trans. en suave. Eng., 18 (1): 9-18, enero de 1 992.
CM97
P. Ciancarini y C. Mascolo.
Analizar y perfeccionar un estilo arquitectónico. En ZUM '97: El Z especificación formal de notación, páginas 349-368.
Springer-Verlag, LNCS-1212,
1997.
CWa96
EM Clarke, WM ala, y col.

Los métodos formales: Estado del arte y las direcciones futuras.
ACM Computing Surveys, 28 (4): 626-643, 1996.
Den96
R. Denney.
Una comparación de los estilos de especificación del modelo-base y algebraicas como base para la especificación de la prueba.
Suave. Ing. notas, 21 (5): 60-65, 1996.
DF93
J. Dick y A. Faivre.
La automatización de la generación y secuenciación de casos de prueba de especificaciones basadas en el modelo. En FME '93: potencia
industrial Métodos formales, páginas 268-284. Springer-Verlag, LNCS-670, 1993.

dMRV92
Jan de Meer, Rudolf Roth, y Son Vuong.

Introducción a las especificaciones algebraicas en base a la Ley de idiomas UNO.
Redes de Computadores y Sistemas ISDN, 23 (5): 363-392, 1992.
Dro89
G. Dromey.
Programa de Derivación - El desarrollo de programas de las especificaciones.
Addison-Wesley Publishers Ltd., 1989.
FJJ + 96
J.-C. Fernandez, C. Jard, T. Jeron, L. Nedelka, y C. Viho.

Un experimento en la generación automática de bancos de pruebas de protocolos con la tecnología de verificación. Informe Técnico
2923, INRIA, Rocquencourt, Juin 1996.
Fur93
U. Fürbach.
métodos de especificación formal de sistemas reactivos.
J. Sistemas de Software, 21 (2): 129-139, febrero de 1 993.
Gar95
D. Garlan.
direcciones de investigación en arquitectura de software.
ACM Computing Surveys, 27 (2): 257-261, 1995.
GH93
JV Guttag y JJ Horning.
Alerce: Idiomas y herramientas para la especificación formal.
Springer-Verlag, 1993.
GP95
C. Gaskell y R. Phillips.
Un formalismo análisis estructurado con la semántica de ejecución para permitir una interpretación modelo inequívoca. En Ingeniería de
Software - ESEC '95, páginas 235-253, 1995.
Gri81
D. Gries.
La ciencia de la programación.
Springer-Verlag, 1981.
Har88
D. Harel.
En formalismos visuales.
Comm. de la ACM, 31 (5): 514-530, mayo de 1988.
HG97
D. Harel y E. Gery.
modelado de objetos ejecutable con Statecharts.
IEEE Computer, 30 (7): 31-42, 1997.

HI88
S. Hekmatpour y D. Ince.
Prototipos Software, Métodos Formales y VDM.
Addison-Wesley Publishing Co., 1988.
Jan97
R. Janicki.
Fundamentos del método de trazo afirmación de la especificación de interfaz de módulo. Informe
Técnico CRL 348, McMaster University, 1997.
Jon86
CB Jones.
Desarrollo de Software sistemática usando VDM.
Serie Internacional de Prentice-Hall en Informática, 1986.
Jul93
RK Jullig.
La aplicación de software de síntesis formal.
IEEE Software, 10 (3): 11-22, mayo de 1993.
KB97
JC Caballero y SS brillante.
Evaluación preliminar de una especificación formal de especificación de interfaz de usuario. En ZUM '97: El Z especificación formal
de notación, páginas 329-346. Springer-Verlag, LNCS-1212,
1997.
Lam88
DA Cordero.
Ingeniería de software: Planificación para el cambio.
Prentice-Hall, 1988.
NB92
K. Naik y Sarikaya. protocolos de

comunicación B. pruebas.
IEEE Software, 9 (1): 27-37, enero de 1 992.
PAR90
HA Partsch.
Especificación y transformación de programas: un enfoque formal para el desarrollo de software.
Springer, 1990.
Pfl98
SL Pfleeger.
Ingeniería de Software - Teoría y Práctica.
Prentice-Hall, Inc., 1998.

Pre92
RS Pressman.
Ingeniería de Software - Un enfoque de la practicante (Tercera Edición).
McGraw-Hill, Inc., 1992.
PvKP91
N. Plat, J. van Katwijk, y K. Pronk. Un caso para el diseño de análisis formal / estructurado. En VDM '91: Formales métodos de
desarrollo de software, páginas 81-105. Springer-Verlag, LNCS-551,
1991.
Rei87
W. Reisig.
Redes de Petri en ingeniería de software. En Redes de Petri: Aplicaciones y relaciones con otros modelos de concurrencia, páginas
63-96. Springer, LNCS-255, 1987.
SC96
P. Stocks y D. Carrington.
Un marco para las pruebas basadas en la especificación.
IEEE Trans. en suave. Eng., 22 (11): 777-793, 1996.
SFD92
LT Semmens, RB Francia, y GTT estibador. análisis estructurado integrada y

técnicas de especificación formales.
El Diario del ordenador, 35 (6): 600-610, 1992.
SH94
AC Storey y HP Haughton.
Una estrategia para la producción de código verificable utilizando el método B. En FME 94: Beneficios industriales de métodos
formales, páginas 346-365. Springer-Verlag, LNCS-873,
1994.
Sha95
N. Shankar.
Asistido por ordenador de computación. En Oller Bernhard M ", editor, Matemáticas del Programa de Construcción '95, número 947 en Lecture
Notes in Computer Science, páginas 50-66. Springer-Verlag, 1995.
Som95
I. Sommerville.
Ingeniería de Software (quinta edición).
Addison-Wesley, 1995.
TTOV97
S. Taouil-Traverson, P. Ozello, y S. Vignes.

Développement Formel de logiciel de Sécurité: la utilización de la méthode B a la SNCF.
Técnica et Sciences Informatique, 16 (9): 1187-1209, 1997.

Tur93
KJ Turner.
El uso de técnicas de descripción formal: una introducción a Estelle, LOTOS y SDL.
series Wiley en sistemas de comunicación y distribuido, 1993.
WP94
Y. Wang y DL Parnas.
Simulando el comportamiento de los módulos de software de reescritura rastro.
IEEE Trans. en suave. eng, 20 (10): 750-759, 1994.

Apéndice J.
Información adicional sobre otro cuerpo de Propuestas Conocimiento

El Comité Directivo Conjunto de la IEEE Computer Society y de la ACM para el Establecimiento de Ingeniería de Software como
profesión establecieron un grupo de trabajo en 1996 para llevar a cabo trabajos de exploración en el tema de la swebok. El grupo de
trabajo diseñado y llevado a cabo un estudio piloto en una muestra de tareas que podrían considerarse dentro del ámbito de la
ingeniería de software 28. La encuesta se le preguntó si se espera que cada tarea se describe a ser realizada por un “ingeniero de
software novato”, un “ingeniero de software experto”, un “especialista en ingeniería de software” o un “administrador” en la
organización.
El Instituto para la Certificación de Profesionales de Informática (CIPC) 29, una organización sin ánimo de lucro, ofrece un programa de
certificación para los profesionales de software titulado Certificado de Informática Profesional (CCP). El CIPC afirma que actualmente hay
50.000 titulares de certificados. Para obtener este certificado, el candidato debe tener al menos 48 meses de experiencia directa de
tiempo completo en los sistemas de información basados en computadoras. Una parte de este requisito de experiencia puede estar
sustituido con educación post-secundaria. Además, los candidatos deben pasar con éxito tres exámenes, uno de los cuales se ha de
escoger entre varios temas diferentes, incluyendo la ingeniería de software. Los temas tratados en el examen de la ingeniería de software
son: ingeniería de sistemas, planificación de proyectos de software, requisitos de software, diseño de software, lenguajes de programación
y codificación, software de control de calidad, técnicas de pruebas de software,
El programa de software de Ingenieros de Calidad (SQE) es un programa de certificación de la American Society for Quality (ASQ) 30. La obtención de
este certificado también requiere experiencia, que puede ser en parte renunciado a la educación post-secundaria y al pasar un examen de 4 horas,
160 preguntas. El “cuerpo del examen de conocimientos” sigue a esta tabla de contenido:
?? conocimientos generales, la conducta y la ética;
?? gestión de la calidad del software;
?? procesos de software;
?? gestión de proyectos de software;
?? métricas de software, la medición y métodos analíticos;
?? la inspección de software, pruebas, verificación y validación;
?? auditorías de software;
?? gestión de configuración de software.
El Instituto de Garantía de Calidad ofrece dos programas de certificación especializados relacionados con la ingeniería de software: Analista
Certificado de Calidad (CQA) y el ingeniero de software de prueba Certificado (CSTE) 31. La obtención del certificado de CQA requiere una licenciatura,
que se puede renunciar con un grado asociado y / o experiencia, referencias, así como superar con éxito un período de cuatro horas, cuatro examen
parcial. El “cuerpo común de conocimientos para el Aseguramiento de la Calidad Sistemas de Información profesión” se proporciona como material de
estudio para este examen. En él se describen los conocimientos en las siguientes áreas:
28 El informe sobre los resultados de la encuesta se puede encontrar en computer.org/tab/seprof/survey.htm

29 ver http://www.iccp.org/profess.html
30 ver http://www.asq.org/about/divtech/softdiv/topcert.htm
31 ver www.qaiusa.com

- Auditoría y Control
- Gestión del cambio
- comunicaciones
- Recuperación de desastres
- Principios de Recursos Humanos
- Técnicas de gestión
- Principios de I / S
- Seguro de calidad
- Las técnicas de control de calidad
- Gestión de la calidad
- Métodos cuantitativos
- Comentarios
- normas
- Pruebas
- Formación y desarrollo
- control de proveedor
Para obtener el certificado de ingeniero de pruebas de software certificado (CSTE), los candidatos deben tener experiencia directa en las
pruebas de software y deben ser capaces de demostrar dominio de las destrezas de seis pruebas de software a través de un curriculum vitae y
otros documentos de apoyo. Los candidatos deben, a partir de enero de 1999, pasar con éxito un examen en el cuerpo común de conocimientos
CSTE. Este conjunto de conocimientos incluye dieciséis dominios de conocimiento agrupados en cuatro categorías:
- Gestión de pruebas: la comunicación, el desarrollo profesional, los conceptos de prueba y entornos de prueba;
- planificación de las pruebas: análisis de riesgos, métodos de desarrollo y medio ambiente, métodos de prueba y técnicas, y proceso
de planificación;
- Ejecución de la prueba: métodos de verificación, herramientas de prueba, diseño de la prueba de los casos y la realización de pruebas;
- análisis de los resultados de pruebas y presentación de informes: el seguimiento de defectos y la gestión, la evaluación de resultados de pruebas,
los métodos cuantitativos y los informes de prueba.
Parnas propone en [16] que el desarrollo de un cuerpo de conocimientos en ingeniería de software debe comenzar con la identificación
de las tareas realizadas por los ingenieros de software. A continuación pasa a proponer una lista de nueve tareas:
- Analizar la aplicación prevista para determinar los requisitos que deben cumplirse, y registrar estos requisitos
en un documento precisa, bien organizado y fácil de usar.
- Participar en el diseño de la configuración del sistema de ordenador, para determinar qué funciones se pueden
implementar en hardware y que funciones se implementan en software, y la selección de los componentes
básicos de hardware y software.
- Analizar el rendimiento de un diseño propuesto (ya sea analítica o por simulación) para asegurarse de que el sistema
propuesto puede cumplir con los requisitos de la aplicación.
- Diseñar la estructura básica del software, su división en módulos, las interfaces entre estos módulos y la estructura
de los programas individuales, mientras que documentan con precisión todas las decisiones de diseño de software.

- Analizar la estructura de software para la integridad, la consistencia y la idoneidad para el uso previsto.
- Implementar el software como un conjunto de programas bien estructurado y bien documentados.
- Integrar el nuevo software con el software existente, o “fuera de la plataforma”.
- Realizar pruebas sistemáticas y estadística del software y sistema informático integrado.
- Revisar y mejorar los sistemas de software, manteniendo su integridad conceptual y conservación de los
documentos completos y exactos.
Parnas también señala que muchos otros temas importantes para los ingenieros de software, tales como la gestión de
proyectos, son el núcleo de la ingeniería en su conjunto y por lo tanto no deben ser incluidos en el swebok. Hilburn et al. en [26]
propuesto recientemente un cuerpo de conocimiento para la ingeniería de software dividido en cuatro grandes áreas de
conocimiento, que luego se dividen en componentes de conocimiento. Estos son:
?? área de conocimiento de la base:
- Requisitos de Software
- Diseño de software
- construcción de software
- gestión de proyectos de software
- La evolución del software
• área de fundaciones:
- fundamentos de computación
- Factores humanos
- Los dominios de aplicación
?? área que se repite:
- Ética y profesionalismo
- procesos de software
- La calidad del software
- modelado de software
- métricas de software
- Herramientas y entornos
- Documentación
?? área de reparto: esta área incluye otros campos de estudio que completan la formación de los ingenieros de software
tales como “educación general”, matemáticas, ciencias naturales y estudios de negocios.
“Ingeniería de Software y metodologías” también se ha incorporado como un “área de conocimiento” o unidad en el cuerpo de la base
de conocimiento para los profesionales de Tecnología de la Información 32 publicado por la Sociedad Australiana. Los temas tratados en
esta unidad son:
?? Fundamentos de Ingeniería de Software
- análisis de requerimientos
32 http://www.acs.org.au/national/pospaper/bokpt1.htm

- especificaciones funcionales y técnicas
- proceso, datos y modelos de orientación a objetos
- normas de documentación
- pruebas de software
- mantenimiento del software
- aseguramiento de la calidad del software
- métodos de especificación formal
- gestión de configuración de software
?? Gestión de proyectos
- la planificación de proyectos, estimación y control
- técnicas de evaluación y control de proyectos
- construcción y gestión de equipos
- principios de la gestión de proyectos de software
- prototipado
Un plan de estudios modelo y directrices para los programas de licenciatura en sistemas de información con derecho IS97 33 Recientemente
se ha publicado después de pasar por una muy grave recopilación y revisión del proceso comentario-. Este modelo curricular se
produce a través de un esfuerzo de colaboración de la Association for Computing Machinery (ACM), la Asociación de Sistemas de
Información (AIS) y la Asociación de Profesionales de Tecnología de la Información (AITP). El proyecto de plan de estudios fue
revisado en once encuentros nacionales e internacionales que participaron más de 1.000 personas de la industria y el mundo
académico. Un cuerpo de conocimiento de los sistemas de información que incluye muchos elementos de ingeniería de software se
propone en IS97.
33 ver http://webfoot.csom.umn.edu/faculty/gdavis/curcomre.pdf

HispaSWEBOK Borrador

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

HispaSWEBOK Borrador

Enviado por

Direitos autorais:

Formatos disponíveis

Guía de la Ingeniería de Software

Un hombre de paja Versión

Pierre Bourque, Universidad de Quebec en Montreal Robert

Dupuis, Universidad de Quebec en Montreal Alain Abran,

Universidad de Quebec en Montreal James W. Moore, La

Corporación MITRE Leonard Tripp, IEEE Computer Society

Karen Shyne, The Boeing Company Bryan Pflug, The Boeing

Company Marcela Maya, Universidad de Quebec en Montreal

individuo Tremblay, Universidad de Quebec en Montreal

Enfoque en el conocimiento Generalmente Aceptados

Guía de la Ingeniería de Software de Administración de Proyecto de Conocimiento

?? caracterizar el contenido de la Ingeniería de Software de Administración de Conocimiento

?? proporcionar un acceso tópica en la Ingeniería de Software de Administración de Conocimiento;

?? promover una visión coherente de la ingeniería de software en todo el mundo;

Fase 1: Paja Hombre Versión

© IEEE Computer Society de septiembre de de 1998

?? Proceso de desarrollo ?? Gestión de la configuración

?? Análisis de requerimientos ?? Seguro de calidad

?? Diseño detallado ?? Verificación y validación

?? Codificación ?? mejora de procesos

?? Los métodos de desarrollo de software ?? Entornos de desarrollo de software

- Orientado a objetos ?? Ingeniería de Software general y definición

- Métodos formales ?? Las métricas de medición /

- prototipado ?? La fiabilidad del software

La lista de propuestas disciplinas relacionadas es:

?? Ciencias de la Computación ?? administración

?? Gestión de proyectos ?? Ciencia

?? Ingenieria Eléctrica ?? Otras disciplinas de ingeniería

?? Matemáticas ?? Ciencias cognitivas

Fase 2: Hombre de Piedra Versión

?? una lista aprobada de Áreas de Conocimiento de la ingeniería de software;

© IEEE Computer Society de septiembre de de 1998

Fase 3: Iron Man Versión

La participación de todas las partes es crítico

© IEEE Computer Society de septiembre de de 1998

Resumen ejecutivo ................................................ .................................................. ............................... i Agradecimientos .................

.................................................. .................................................. .............. 1

1. Introducción ............................................... .................................................. ....................................... 2

2. La Guía de la Ingeniería de Software de Administración de Proyecto Conocimiento ...................................... .............. 3

3. Contexto y Relaciones ............................................. .................................................. ................... 8

4. Metodología de Desarrollo para la identificación de áreas de conocimiento y disciplinas relacionadas ........................ 17

5. Áreas de Conocimiento propuestas ............................................. .................................................. .............. 23

6. Propuestas de disciplinas relacionadas con ............................................. .................................................. ............ 26

7. Resumen y próximos pasos ............................................ .................................................. ................... 27

8. Referencias ............................................... .................................................. ...................................... 30

9. Apéndices ............................................... .................................................. ..................................... 32

Apéndice B. URL de los programas de grado y de postgrado en Ingeniería de Software ............... 34

Apéndice D. Programas de Licenciatura en Ingeniería de Software - Clasificación de los cursos

Apéndice E. Programas de Licenciatura en Ingeniería de Software - Clasificación de los cursos por

Apéndice F. Programas de Posgrado en Ingeniería de Software - Requisitos de Admisión

Apéndice G. Programas de Posgrado en Ingeniería de Software - Clasificación de los cursos

Apéndice H. Programas de Posgrado en Ingeniería de Software - Clasificación de los cursos

Apéndice I. Proyecto de Clasificación de conocimientos sobre métodos formal basado en la propuesta

© IEEE Computer Society de septiembre de de 1998

© IEEE Computer Society de septiembre de de 1998

© IEEE Computer Society de septiembre de de 1998

2. La Guía de la Ingeniería de Software de Administración de Proyecto de Conocimiento

Guía para un conjunto de conocimientos

Objetivos del proyecto

• caracterizar el contenido de la Ingeniería de Software de Administración de Conocimiento;

• proporcionar un acceso tópica en la Ingeniería de Software de Administración de Conocimiento;

• promover una visión coherente de la ingeniería de software en todo el mundo;

© IEEE Computer Society de septiembre de de 1998