4 Modulo Teoria-1-43

DESARROLLO DE SOFTWARE
Módulo IV – Apunte Teórico

Contenido
1. Definición del Módulo. .................................................................................................................... 2
2. Introducción. ................................................................................................................................... 4
2. Desarrollo de Software. ................................................................................................................... 9
2.1. Disciplinas implicadas en el desarrollo de software. ................................................................. 9
2.1.1. Procesos de desarrollo definidos y empíricos. ................................................................... 9
2.1.2. Procesos de desarrollo y modelos de proceso. Criterios para elección de ciclos de vida en
función de las necesidades del proyecto y las características del producto. ............................. 16
2.1.3. Disciplinas técnicas, de gestión y de soporte que conforman la ingeniería de software. 22
2.1.4. Gestión de configuración de software. ............................................................................ 25
2.1.5. Testing y revisiones técnicas al software. ........................................................................ 36
2.2. Gestión de proyectos. ............................................................................................................. 49
2.2.1. Gestión tradicional y ágil de proyectos. ........................................................................... 49
2.2.2. Introducción a los métodos ágiles. Manifiesto Ágil.......................................................... 53
2.2.3. Requerimientos en ambientes ágiles. .............................................................................. 54
2.2.4. User Stories...................................................................................................................... 58
2.2.5. Métodos Ágiles: SCRUM, XP, TDD. ................................................................................... 62
3. Bibliografía. .................................................................................................................................... 85
1
1. Definición del Módulo.

El módulo específico de Desarrollo de Software tiene como propósito general, contribuir a la
formación de los estudiantes del ámbito de la Formación Profesional en sujetos que se integrarán a
equipos de desarrollo, dado que el desarrollo de software es una actividad esencialmente de trabajo
en equipo.
Este módulo selecciona un conjunto de conocimientos vinculados con la disciplina de Ingeniería de

Software, particularmente en los aspectos de gestión y soporte de los proyectos de desarrollo de
software.
Este módulo se orienta al desarrollo de las siguientes capacidades profesionales, estando estas
articuladas con las funciones que se describen en el alcance del perfil profesional:
• Integrar un equipo en el contexto de un Proyecto de Desarrollo de Software.
El desarrollo de software es una actividad social, que se desarrolla principalmente en equipo, en

consecuencia, el Programador debe poder integrarse en un equipo de trabajo, sea este un contexto
de proyecto de gestión tradicional o de gestión ágil.
Debe poder manejar su entorno personal y el entorno laboral donde se insertará.
• Dimensionar su trabajo en el contexto del proyecto de desarrollo de software.
El Programador como parte integrante de un equipo de proyecto debe poder estimar el esfuerzo que
necesita para realizar un trabajo que le fue asignado. Para ello deberá procurarse la información que
necesite para dimensionar el trabajo, considerando la utilización de recursos de los que disponga
para ser productivo, por ejemplo, utilización de bibliotecas de componentes, aplicación de patrones,
entre otros.
El objetivo general de este módulo es:
La formación de capacidades como sujetos que integrarán equipos de desarrollo, dado que el
desarrollo de software es esencialmente, trabajo en equipo; haciendo hincapié en el desarrollo de
habilidades interpersonales.
Los objetivos de aprendizaje son:
• Identificar las disciplinas que conforman la Ingeniería de Software y las técnicas y

herramientas relacionadas.
• Desarrollar habilidades interpersonales necesarias para integrar equipos de trabajo.
• Conocer los tipos de procesos y los modelos de procesos más adecuados para el desarrollo
de software en cada situación particular.
• Introducir los enfoques de gestión de proyectos tradicional y ágil.
• Conocer los principales métodos de desarrollo y gestión ágil.
• Valorar la relación existente entre el Proceso, el Proyecto y el Producto de Software a
construir.
2
• Reconocer la importancia de la Gestión de Configuración de Software.

• Conocer técnicas y herramientas para realizar pruebas y revisiones técnicas al software.
• Integrar por medio de casos prácticos concretos los conocimientos adquiridos en la parte
teórica, empleando así las técnicas y herramientas de aplicación de la ingeniería de software.
Los contenidos del módulo se resumen seguidamente:
• Proceso de Desarrollo definidos y empíricos.

• Procesos de Desarrollo y Modelos de Proceso. Criterios para elección de ciclos de vida en
función de las necesidades del proyecto y las características del producto.
• Disciplinas que conforman la Ingeniería de Software: disciplinas técnicas, disciplinas de
gestión y de soporte.
• Introducción a los temas, que se constituyen en un aprendizaje transversal que se
desarrollará a lo largo de todo el curso.
• Habilidades Interpersonales:
o Importancia de la comunicación. Representación de situaciones de mala
comunicación (actuación).
o Habilidades comunicacionales.
o Herramientas para mejorar la comunicación personal.
o Comunicación grupal. Trabajo en equipo. Dinámica de trabajo en equipo - escucha
activa.
• Introducción a la Gestión de Configuración:
o Creación de repositorios en GitHub.
o Operaciones sobre repositorios.
• Testing de Software.
• Revisiones técnicas al software.
• Introducción a los Métodos Ágiles.
• Manifiesto Ágil.
• Requerimientos en ambientes ágiles - User Stories.
• Métodos Ágiles: SCRUM, XP y TDD.
3
2. Introducción.
El software en su origen era la parte insignificante del hardware, lo que venía como añadidura, casi
como regalo, no pasó mucho tiempo de su evolución y se generó una idea de software: igual
programa; y en breve tiempo adquirió una entidad propia, la cual desde el comienzo fue acompañada
de complejidad (dificultad de…), por ser un producto difícil de entender, difícil de explicar, difícil de
construir y difícil de mantener, es decir, un producto difícil, un producto intangible, maleable y con
diversas representaciones, en constante cambio y evolución. El software se ha convertido en ubicuo,
está inserto en la mayoría de las actividades de la persona humana, en su cotidianeidad. Por lo
anterior, es importante no subestimarlo.
En el diccionario bilingüe Longman, se define el término software como el conjunto de programas

que controlan la operación de una computadora. Pressman, define que el software se forma con:
1. Las instrucciones (programas de computadoras) que al ejecutarse proporcionan las

características, funciones y el grado de desempeño.
2. Las estructuras de datos que permiten que los programas manipulen la información de
manera adecuada.
3. Los documentos que describen la operación y el uso de los programas.
Por su parte, Freeman caracteriza al software como “el alma y cerebro de la computadora, la
corporización de las funciones de un sistema, el conocimiento capturado acerca de un área
de aplicación, la colección de los programas, y los datos necesarios para convertir a una
computadora en una máquina de propósito especial diseñada para una aplicación particular,
y toda la información producida durante el desarrollo de un producto de software”.
El software no sólo hace referencia a los programas ejecutables sino también representa
diversas cosas, las cuales difieren en el tiempo, con las personas y principalmente en cómo
se lo va a emplear. El software viabiliza el producto más importante de nuestro tiempo: la
información.
Características del software
El software es un elemento lógico, no físico, para comprender mejor al software es importante

conocer las características que lo distinguen de otros productos que construye el hombre.
Sumado a lo antes dicho, recordemos que “hacemos software con software”. Esto no sólo dificulta el
proceso de diseño en nuestra mente, sino que dificulta severamente la comunicación entre las
mentes.
Robert Cochram, utiliza las siguientes características para describir lo que es único y especial en el
software:
1. El software es intangible.
2. Tiene alto contenido intelectual.
4
3. Generalmente, no es reconocido como un activo por los Contadores, por lo que no está en
los balances.
4. Su proceso de desarrollo es humano intensivo, basado en equipos y construido en proyectos.
5. El software no exhibe una separación profunda entre I&D y producción.
6. El software puede ser potencialmente modificado, en forma permanente.
Pressman, expresa las características del software haciendo énfasis en la diferencia que éste tiene
con el hardware:
1. El software no se manufactura, se desarrolla.

2. El software no se desgasta.
3. A pesar de la tendencia de la industria a desarrollar por componentes, gran parte del
software aún se construye a medida.
Pese a la diversidad de opiniones que expresan los autores respecto a las características del software,
todos coinciden en su complejidad. Según Basili, el software es intangible y su intangibilidad es lo que
contribuye fuertemente a su complejidad. El software es complejo, complejo de construir, complejo
de entender, complejo de explicárselo a otros. Esta característica inherente del software, junto al
hecho de que el software es, desarrollado y no construido y la falta de principios y componentes bien
definidos hace de él un producto diferente a cualquier otro, con el que se haya tratado antes.
La existencia de pedidos de cambio y evolución constante de su función y/o estructura, su desarrollo

propenso a errores, la dificultad para su estimación, la falta de comprensión de las implicancias que
trae aparejado el cambio, son algunas de las razones que fundamentan su complejidad.
Sistema Informático y la Ingeniería para su desarrollo
Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su

producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha
actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de
cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su
construcción y resultados han sido históricamente cuestionados debido a los problemas asociados,
entre ellos podemos destacar los siguientes:
• Los sistemas no responden a las expectativas de los usuarios.

• Los sistemas “fallan” con cierta frecuencia.
• Los costos del software son difíciles de prever y normalmente superan las estimaciones.
• La modificación del software es una tarea difícil y costosa.
• El software se suele presentar fuera del plazo establecido y con menos prestaciones de las
consideradas inicialmente.
• Normalmente, es difícil cambiar de entorno de hardware usando el mismo software.
• El aprovechamiento óptimo de los recursos no suele cumplirse.
El primer reconocimiento público de la existencia de problemas en la producción de software tuvo

lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch
(Alemania), dicha situación problemática se denominó crisis del software. En esta conferencia, así
5
como en la siguiente realizada en Roma en 1969, se estipuló el interés hacia los aspectos técnicos y
administrativos del desarrollo y mantenimiento de productos software.
Se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer, lo
que se necesitaba era “establecer y usar principios de ingeniería orientados a obtener software de
manera económica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta definición
marcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería
aplicables al desarrollo de software? ¿Cómo construimos el software económicamente para que sea
fiable? ¿Qué se necesita para crear software que funcione eficientemente?
Ingeniería de Software
El “IEEE Standard Glossary of Software Engineering Terminology” ha desarrollado una definición más
completa para ingeniería del software: “La aplicación de un enfoque sistemático, disciplinado y
cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de la
ingeniería al software”.
El objetivo principal que busca la ingeniería de software es convertir el desarrollo de software en un

proceso formal, con resultados predecibles, que permitan obtener un producto final de alta calidad;
que satisfaga las necesidades y expectativas del cliente. Generalmente a partir de un complejo
esquema de comunicación en el que interactúan usuarios y desarrolladores, el usuario brinda una
concepción de la funcionalidad esperada y el desarrollador especifica esta funcionalidad a partir de
esta primera concepción mediante aproximaciones sucesivas. Este ambiente de interacción motiva
la búsqueda de estrategias robustas para garantizar que los requisitos del usuario serán descubiertos
con precisión y que además serán expresados en una forma correcta y sin ambigüedad, que sea
verificable, trazable y modificable.
El estudio de enfoques en Pressman caracteriza la Ingeniería de Software como “una tecnología

multicapa”, ilustrada en la Figura 1.
Figura 1: Capas de la Ingeniería de Software.
Dichas capas se describen a continuación:
• Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre
un esfuerzo de organización de calidad. La gestión de calidad y las filosofías similares
6
fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de

enfoques cada vez más robustos para la ingeniería del software.
• El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco
de trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión
de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos,
se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se
gestiona adecuadamente.
• Los métodos de la ingeniería de software indican cómo construir técnicamente el software.
Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño,
construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un
conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen
actividades de modelado y otras técnicas descriptivas.
• Las herramientas de la ingeniería de software proporcionan un soporte automático o semi-
automático para el proceso y los métodos, a estas herramientas se les llama herramientas
CASE (Computer-Aided Software Engineering), lo que significa Ingeniería de Software Asistida
por computadoras.
Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad

(tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos
y herramientas.
Disciplinas de la Ingeniería de Software
Considerando que el propósito de la Ingeniería de Software es obtener productos de software de

calidad, se apoya en un grupo de campos de estudio, llamados comúnmente disciplinas, que aportan
un desarrollo y estudio organizado de saberes. Dada la diversidad de campos de estudio que abarca
la Ingeniería de Software, se las puede clasificar según su propósito en disciplinas Técnicas, disciplinas
de Gestión y disciplinas de Soporte.
Las disciplinas denominadas Técnicas son las relacionadas directamente con la construcción del
producto de software. Las disciplinas de Gestión están relacionadas con el proyecto, que tal como se
profundizará más adelante en este apunte, es el medio que se utiliza para guiar la construcción de
software. Las disciplinas de Soporte, también conocidas como disciplinas protectoras, son las que
brindan herramientas que ayudan a obtener calidad para el software que se va a desarrollar:
7
Figura 2: Principales Disciplinas de la Ingeniería de Software.
8
2. Desarrollo de Software.
2.1. Disciplinas implicadas en el desarrollo de software.
2.1.1. Procesos de desarrollo definidos y empíricos.
El desarrollo de software en una mirada
El desarrollo de software se trata de desarrollar y entregar gran software. Un software es un gran

software cuando complace a quienes lo necesitan, a quienes lo pidieron, a quienes lo usarán.
Un gran desarrollo de software entrega lo que se necesita, a tiempo y dentro del presupuesto. Cada
pieza de software comienza con una idea de un cliente. Es tu trabajo como desarrollador de software
es dar vida a esa idea. Sin embargo, tomar una idea vaga y transformarla en software funcionando,
software que satisfaga a su cliente, no es una tarea trivial. El propósito de este apunte es poder
introducirlos en el mundo del desarrollo de software, y llegar a entregar el software que se necesita,
a tiempo y dentro del presupuesto definido.
Figura 3: Una mirada al Desarrollo de Software.
9
▪ Desarrollar Software → Dejar contento al Cliente
El desarrollo de Software es una actividad cuyo propósito es transformar ideas, necesidades y

recursos en un producto de software.
El software se desarrolla por personas, que deben estar motivadas y capacitadas para hacer su
trabajo. Debe emplear un proceso que guía la transformación; y ayudarse con herramientas que
faciliten el trabajo.
A continuación, vamos a hacer un recorrido por las actividades principales, involucradas en el

Desarrollo de Software.
▪ Recolectar Requerimientos → Saber que quiere el Cliente
En el ámbito del desarrollo de software se define un requerimiento cómo una característica que el
producto que se va a construir debe satisfacer.
Esa característica puede está relacionada con algún comportamiento o con alguna capacidad, que el
Cliente/Usuario espera encontrar en el producto de Software.
De todas las actividades involucradas en el desarrollo de software, la más difícil de todas es

precisamente esta: acordar qué software es el que se quiere construir.
▪ Planificar → Definir la hoja de ruta para el viaje
Un plan es a un proyecto lo que una hoja de ruta a un viaje.
Planificar es definir qué es lo que haremos, cuándo lo haremos, cómo vamos a hacerlo y quién lo
hará.
La planificación establece compromisos que esperamos cumplir, y si bien con frecuencia los planes
pueden están equivocados, si no se planifica, no se puede responder las preguntas básicas antes
mencionadas.
Si no sabemos planificar, lo mejor que podemos hacer es planificar con más frecuencia.
▪ Estimar → ¿Cuán grande será? ¿Cuánto costará? ¿Cuándo estará terminado?
Estimar es predecir el tiempo y el costo que llevará desarrollar un producto de software, basándonos
es el tamaño de lo que queremos construir.
Las estimaciones tienen asociada una probabilidad, y esa probabilidad está relacionada con la
información con la que contamos al momento de predecir.
El problema con las estimaciones es que se las requiere muy pronto, y es difícil hacer predicciones,
especialmente sobre el futuro.
10
▪ Diseñar → Crear el Software
Diseñar es crear, diseñar es tomar decisiones respecto de cuál es la mejor forma de satisfacer los
requerimientos definidos para el producto.
Durante el diseño se aplican varias técnicas y principios, para crear modelos que especificarán el
producto a construir. Al diseñar software se crean representaciones que visualizan diferentes partes
del mismo, a saber: su arquitectura, sus procesos, sus bases de datos y la forma en la que el software
interactuará con sus usuarios.
La profundización de los conceptos, principios, técnicas y herramientas relacionadas con el Diseño

de Software están fuera del alcance de este material.
▪ Programar → Construir el Software
Programar es escribir código, que permitirá controlar lo que una computadora hará.
Se transforman diseños utilizando uno o varios lenguajes de programación, obteniendo un producto

que implementa los requerimientos acordados.
El resultado de este proceso es lo que se instala en las computadoras de los usuarios.
Los conceptos, principios, técnicas y herramientas relacionadas con la Programación en general, y

con el paradigma Orientado a Objetos en particular, son abordados en el Módulo de Programación
Orientada a Objetos.
▪ Revisar Técnicamente → Verificar con un colega lo que hicimos
Las revisiones técnicas del software tienen por objetivo detectar tempranamente errores que se
comenten al desarrollar.
Dado que el software es invisible, y lo desarrollamos en nuestra mente, es esperable que

comentamos errores.
Si mostramos y explicamos a otros el trabajo que hicimos es muy probable que esos errores sean
identificados y puedan corregirse antes que se hagan mayores, impacten en otros artefactos; y que
sea más costoso corregirlos.
▪ Probar → ¿Construimos el producto adecuado? ¿Funciona correctamente?
La prueba del software, en inglés testing, es un proceso que tiene por objetivo encontrar defectos,
que se asume de ante mano que está allí.
Durante la prueba debemos poder validar que el producto que se está probando es el que el usuario
quería, y verificar que el producto funciona correctamente.
11
▪ Controlar la Configuración → Cuidar y defender lo que desarrollamos
Una de las características del software es que es fácil de modificar, maleable y dado que vamos a
necesitar cambiarlo muchas veces, es necesario crear mecanismos que nos ayuden a controlar el
software a lo largo de su ciclo de vida.
El control de la configuración del software protege la integridad del producto que construimos de
pérdidas de componentes o de cambios realizados a los componentes, evita superposición de
cambios y esfuerzos duplicados de mantenimiento.
▪ Monitorear → ¿Cómo vamos en el viaje? ¿Podemos decirlo con números?
El monitoreo y control compara los planes realizados con el avance real de un proyecto. Nos da
visibilidad respecto de la situación del proyecto en un momento de tiempo, cuánto hicimos, cuánto
nos falta para terminar, cuánto gastamos, cuanto tiempo consumimos.
Si a esas preguntar podemos responderlas con números será más fácil interpretar el estado real del
proyecto y poder tomar decisiones acertadas respecto de cómo continuar.
Desarrollar Software
El Software como producto se desarrolla de manera gradual, cada versión del software es única y se
obtiene como resultado de la ejecución de un Proyecto. Cada proyecto involucra personas que son
responsables de la transformación de los requerimientos en el producto final. El proyecto utiliza un
proceso que define las actividades que se llevarán a cabo para alcanzar los objetivos.
Figura 4: Las 4 “P” en el desarrollo de Software.
12
▪ PERSONAS: ¿QUIÉN HACE QUE?
El factor humano es fundamental para el éxito del proyecto.
Las personas son los principales autores de un proyecto de Software, que asumen diferentes roles
tales como analistas de sistemas, diseñadores, programadores, arquitectos, analistas de prueba,
líderes de proyecto, revisores técnicos, entre otros. Estas personas conformarán lo que se denomina
Equipo de Desarrollo.
Algunos de los factores que deben considerarse al momento de la conformación de un Equipo de

Desarrollo son:
• Experiencia en el dominio de la aplicación.

• Experiencia en la plataforma y el lenguaje de programación.
• Habilidad para resolver problemas.
• Habilidad de comunicación.
• Adaptabilidad.
• Actitud.
• Personalidad.
Un equipo de desarrollo para ser eficaz deberá maximizar capacidades y habilidades de cada persona,
teniendo en cuenta las características de la organización, la cantidad de personas que integran el
equipo, el grado de habilidad de los integrantes y la dificultad del problema a resolver.
El Equipo de Desarrollo debe interactuar con otros participantes que también están involucrados en
la obtención del software, que es importante mencionar: Gerentes de Proyecto, Gerentes de
Producto, Clientes, Usuarios Finales.
▪ PROCESO: CÓMO SE HACEN LAS COSAS
Un proceso de software define un conjunto completo de actividades necesarias para transformar los
requerimientos de un usuario en un producto.
El proceso proporciona un marco de trabajo, una estructura que puede tomarse como referencia
para definir el plan que guiará el proyecto para el desarrollo del software.
Un proceso de desarrollo de software contiene además de la definición de las actividades,

procedimientos y métodos, la identificación de las herramientas que permitan la automatización de
las actividades y facilite el trabajo.
Finalmente, las personas, que, en el desarrollo de software, son lo más importante, ya que la materia
prima para su creación es la mente y el trabajo de las personas que integrarán el equipo.
13
Figura 5: Elementas que conforman un proceso de desarrollo de Software.
La definición completa del proceso contiene actividades relacionadas con las disciplinas técnicas, de
gestión y de soporte o protectoras, mencionadas con anterioridad en este apunte. El proceso define
además de las actividades que deben realizarse, las entradas que necesita, las salidas que produce,
los roles responsables de la realización de las actividades, la definición de las herramientas que se
necesitan y la forma de medir y controlar si las actividades efectivamente se realizaron.
Sin embargo, un pequeño número de actividades es aplicable a todos los proyectos de software, sin
importar su tamaño o complejidad. Otros conjuntos de tareas permiten que las actividades del
proceso se adapten a las características del proyecto de software, así como a los requisitos del equipo
del proyecto y a las características del Producto.
Vinculado al concepto de proceso está el concepto de Modelo de Proceso o Ciclo de Vida del Proceso
de Desarrollo, el cual se define como una representación de un proceso. El modelo de proceso grafica
una descripción del proceso desde una perspectiva particular, indicando fases para el proceso y el
orden en el que las mismas se llevarán a cabo.
Hay diferentes tipos de modelos de procesos. Algunos, denominados secuenciales, plantean que las
fases del proceso deben ejecutarse en forma completa y en orden, avanzando con el cien por ciento
de los artefactos que deben construirse en cada fase antes de poder pasar a la siguiente.
Otros modelos de proceso denominados iterativos, por el contrario, plantean que puede avanzarse
con una porción del producto que debe construirse, evolucionando a través de cada una de las etapas
hasta obtener una versión completa, para una parte del producto y luego repetir el proceso hasta
terminar el desarrollo completo. Se abordará este tema con más detalle en la última sección del
apunte.
El mismo proceso puede ser utilizado con diferentes modelos de proceso en cada proyecto que se
realizará, según las características particulares de cada proyecto.
14
▪ PROYECTO: UNA EJECUCIÓN ÚNICA
Es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único, en
este caso un producto de software.
El proyecto integra personas, utiliza un proceso y herramientas para obtener como resultado un
producto de software.
Al inicio del proyecto debe decidirse que conjunto de actividades definidas en el proceso, aplican
para el proyecto, es decir adaptar el proceso al proyecto. Así como también el modelo de proceso o
ciclo de vida más conveniente para utilizar en el proyecto.
Un proyecto tiene las siguientes características:
• Temporal: esto significa que tiene una fecha de comienzo y fin definidos. Un proyecto
termina cuando se alcanza el/los objetivo/s o cuando queda claro que no podrán alcanzarse
por la razón que sea. Una línea de producción que obtiene productos en masa, no es un
proyecto.
• Productos, Servicios o Resultados únicos: Los resultados que se obtienen de los proyectos
por similares que sean tienen características que los hacen únicos. La presencia de elementos
repetitivos no cambia la condición fundamental de obtener resultados “únicos”.
• Orientado a Objetivos: Los proyectos están dirigidos a obtener resultados y ello se refleja a
través de objetivos. Los objetivos guían al proyecto. Los objetivos que se definen deben ser
claros y alcanzables. Un objetivo es claro cuando todas las personas que están involucradas
en el proyecto comprenden lo que hay que lograr. Un objetivo es alcanzable cuando lo
definido como expectativa a alcanzar es factible de hacerse.
• Elaboración Gradual: Desarrollo en pasos que aumenta mediante incrementos. Debe

coordinarse cuidadosamente con el alcance del proyecto. El alcance del proyecto se define
como todo el trabajo y solo el trabajo que debe realizarse para cumplir con el objetivo
definido. La elaboración gradual de las actividades del proyecto debe mantenerse alineada
con el alcance definido para el mismo.
▪ PRODUCTO: EL RESULTADO
El producto de software es el conjunto de artefactos o componentes que se obtienen como salida de

cada una de las actividades definidas en un proceso, que se ejecutan en un proyecto.
El producto de software se obtiene como consecuencia de una evolución y refinamiento continuo de

los modelos, que parten desde los requerimientos del usuario y/o cliente.
El Producto es más que código, en el contexto del desarrollo de software, el producto que se obtiene
es un sistema software. El termino producto aquí hace referencia al sistema entero, y no sólo al
código ejecutable que se entrega al cliente.
15
Un sistema software es la sumatoria de todos los artefactos que se necesitan para representarlo en
una forma comprensible para las máquinas, los trabajadores y los interesados.
Una versión de un Producto de Software puede incluir entre otras cosas: código, bases de datos,
manuales de usuario, manuales de configuración, modelos del diseño, documentos de arquitectura,
documentos de requerimientos, casos de prueba.
El término Artefacto, se utiliza para referenciar cualquier información creada, producida, cambiada
o utilizada por las personas en el desarrollo del sistema.
Básicamente, hay dos tipos de artefactos: artefactos de ingeniería y artefactos de gestión. Los de
ingeniería son creados durante la ejecución de las disciplinas técnicas (Requerimientos, Análisis,
Diseño, Implementación, Prueba y Despliegue).
Los artefactos de gestión tienen un tiempo de vida corto, lo que dura la vida del proyecto; A este
conjunto pertenecen artefactos como el plan de proyecto.
2.1.2. Procesos de desarrollo y modelos de proceso. Criterios para elección de ciclos de vida
en función de las necesidades del proyecto y las características del producto.
El software se desarrolla para algún cliente en particular o para un mercado en general. Para el diseño
y desarrollo de productos de software se aplican metodologías, modelos y técnicas que permiten
resolver los problemas. En los años 50 no existían metodologías de desarrollo, el desarrollo estaba a
cargo de los propios programadores.
Los resultados eran impredecibles, no se sabía la fecha exacta en que concluiría un proyecto de
software, no había forma de controlar las actividades que se estaban desarrollando. Tampoco se
contaba con documentación estandarizada. El nacimiento de técnicas estructuradas es lo que da
origen al desarrollo de aplicaciones aplicando técnicas, métodos y herramientas de ingeniería.
La informática aporta herramientas y procedimientos que se apoyan en la ingeniería de software con

el fin de mejorar la calidad de los productos de software, aumentar la productividad y trabajo de los
desarrolladores de software, facilitar el control del proceso de desarrollo de software y suministrar a
los desarrolladores las bases para construir software de alta calidad en una forma eficiente. En
definitiva, aporta lineamientos para conformar un “proceso” para estructurar el desarrollo del
software.
Desde 1985 hasta el presente, aparecen constantemente, herramientas, metodologías y tecnologías

que se presentaban como la solución definitiva al problema de la planificación, previsión de costos y
aseguramiento de la calidad en el desarrollo de software. La dificultad propia de los nuevos sistemas,
y su impacto en las organizaciones, ponen de manifiesto las ventajas, y en muchos casos la necesidad,
de aplicar una metodología formal para llevar a cabo los proyectos de este tipo.
Una parte importante de la ingeniería de software es el desarrollo de metodologías y modelos.

Muchos esfuerzos que se encaminan al estudio de los métodos y técnicas para lograr una aplicación
16
más eficiente de las metodologías y lograr sistemas más eficientes y de mayor calidad con la
documentación necesaria en perfecto orden y en el tiempo requerido.
Una metodología define una forma disciplinada para desarrollar software con el objetivo de hacerlo
más predecible y eficiente. Una metodología contiene representaciones que facilitan la manipulación
de modelos, y la comunicación e intercambio de información entre todas las personas involucradas
en la construcción de un sistema.
La experiencia ha demostrado que los proyectos exitosos son aquellos que son administrados
siguiendo una serie de procesos que permiten organizar y luego controlar el proyecto. Es necesario
destacar la importancia de los métodos, pero el éxito del proyecto depende más de la comunicación
efectiva con los interesados, el manejo de las expectativas y el nivel de involucramiento y motivación
de las personas que participan en el proyecto.
Existen diferentes metodologías que han sido en los últimos años herramientas de apoyo para
el desarrollo del software. Sommerville (2005), menciona que:
• Metodología de desarrollo de software: es un enfoque estructurado para el desarrollo de

software que incluye modelos de sistemas, notaciones, reglas, sugerencias de diseño y guías
de procesos.
En este sentido, Jacobson (2000), aporta el concepto de Proceso de Desarrollo, con la intención que
sirva para hacer operativo y concreto, lo expuesto en una metodología, definiéndolo como:
• Proceso de Desarrollo de Software define quién está haciendo qué, cuándo y cómo alcanzar
un determinado objetivo. En la ingeniería de software, el objetivo es construir un producto
de software o mejorar uno existente. Es necesario que el proceso sirva de guía a los
participantes (clientes, usuarios, desarrolladores, diseñadores, líderes de proyectos, por
mencionar algunos ejemplos).
Procesos de Control
Cuando trabajamos en el desarrollo de software, utilizando proyectos, podemos elegir dos enfoques
muy diferentes de procesos de control. Esta elección determinará la forma en la que se realizará el
trabajo en el contexto del proyecto y las decisiones que se tomen, por consecuencia afectará la forma
en la que se obtendrán y presentarán los productos resultantes.
▪ PROCESO PREDICTIVO DE CONTROL
El proceso predictivo de control asume que es posible detallar las principales variables de un proyecto
(requisitos, tareas, recursos, costos y tiempos) y predecir su comportamiento a largo plazo.
Adicionalmente a esta predicción, se crea una cadena de actividades donde cada una recibe una
entrada, ejecuta una serie de tareas preestablecidas y produce una salida esperada. Cada una de
estas tareas está asociada a un determinado rol que posee ciertas habilidades para transformar la
entrada en una salida. Otro supuesto fundamental de este enfoque de control, es que la
17
responsabilidad sobre un ítem en progreso se traspasa entre los roles que se ocupan de las diferentes
actividades, quedando en el rol destinatario del traspaso la responsabilidad de la aceptación del ítem.
Dado que cada actividad requiere diferente cantidad de esfuerzo, el control se realiza midiendo el
esfuerzo incurrido contra el estimado.
El supuesto de que el flujo de trabajo está prediseñado y predefinido nos lleva a la conclusión de que
la predictibilidad se puede asegurar en cualquier momento durante el proyecto.
▪ PROCESO E MPÍRICO DE CONTROL
A diferencia del proceso Predictivo de Control, el proceso Empírico acepta la complejidad y en vez de
pretender controlar la realidad, su propósito es medir constantemente los resultados y adaptar el
comportamiento en consecuencia. Bajo este paradigma, las variables del proyecto se pueden
predecir, pero con un horizonte temporal acotado.
Manteniendo entonces un intervalo de tiempo pequeño y constante, el control puede ser bastante
granular al revisar sistemáticamente el resultado del trabajo realizado durante ese intervalo de
tiempo y ajustando las variables del contexto y permitiendo así una constante estabilización y
optimización del sistema.
El rol del equipo de trabajo es fundamental en un proceso empírico ya que los individuos dejan de
ser percibidos como agentes independientes y pasan a ser parte de un conjunto interdependiente de
personas que forman un equipo, donde el éxito o el fracaso es colectivo y no individual.
Creer que los procesos predictivos, por más detallados y definidos que estén (predictivos que sean),
son más confiables y seguros que las personas que los ejecutan, es desde la perspectiva de gran parte
de la industria de software, una falacia. Los procesos predictivos no aprenden. Los procesos
predictivos no piensan. Las personas son las que piensan, aprenden y crean cosas nuevas.
Los procesos predictivos son extremadamente valiosos y eficientes para ejecutar tareas repetitivas
en contextos predecibles. ¿Alguna vez te sentaste frente a una hoja por un rato para "ser creativo"?
¿Alguna vez trabajaste en un proceso predictivo con un paso donde había que crear algo nuevo?
¿Cómo te ha ido? Los procesos predictivos son racionales, lógicos. Los procesos empíricos dan lugar
a la creatividad. Los procesos predictivos se basan en experiencias pasadas e intentan repetirlas, pero
debemos vivir mirando hacia el futuro, hacia la innovación.
Del paradigma de los procesos empíricos de control, surgen las metodologías ágiles para el desarrollo
de software.
Al final de este apunte se describen los fundamentos y principios de las metodologías ágiles; el
manifiesto ágil y se introducen algunas de las metodologías ágiles más conocidas.
18
Modelos de proceso para el desarrollo de software
Tal como se mencionó antes, un modelo de proceso o ciclo de vida, es una representación abstracta
de un proceso. Cada modelo representa un proceso desde una perspectiva particular y así
proporciona información parcial sobre el proceso. Estos modelos generales no son descripciones
definitivas de los procesos del software, más bien son abstracciones de los procesos que se pueden
utilizar para el desarrollo del software. Puede pensarse en ellos como marcos de trabajo del proceso,
que definen detalles de cómo trabajar con los procesos. Un proceso en particular puede utilizarse
con distintos modelos de proceso, en proyectos diferentes, en función de las situaciones particulares
de esos proyectos.
A continuación, se mencionan algunos modelos de proceso utilizados en los proyectos de desarrollo

de software, existen muchos más:
▪ MODELO DE PROCESO EN C ASCADA
Este modelo de proceso de tipo secuencial, que considera las actividades del proceso de desarrollo:
Requerimientos, Análisis, Diseño, Implementación y Prueba, como fases separadas del proceso,
asumiendo que se deben realizar en forma completa cada una de ellas antes de comenzar con la
siguiente. En este modelo de proceso, la retroalimentación del cliente, respecto del producto
construido, no llega sino hasta el final. Esto es muy costoso en el caso que el producto presentado al
cliente no sea el producto correcto, lo que implica costos muy altos para cambiarlo, dado que se
desarrollaron todas las etapas del proyecto basadas en una asunción de necesidades que no eran las
correctas.
La siguiente figura muestra la representación gráfica del modelo de proceso en Cascada.
Figura 6: Modelo de Proceso o Ciclo de Vida en Cascada.
19
▪ MODELO DE PROCESO EN C ASCADA CON SUBPROYECTOS
Este modelo de proceso surge como una evolución del anterior, donde se deja la totalidad de la
definición del producto de software a construir al principio del proyecto y luego se divide la totalidad
de los requerimientos en partes que se resolverán en “subproyectos”. Dentro de cada subproyecto
se realiza análisis y diseño detallado de la porción del sistema asignada como alcance a ese
subproyecto y Prueba, haciendo al final la integración de cada subsistema y la prueba del sistema
completo. Se puede llevar adelante subproyectos en paralelo si hay gente disponible para hacerlo. La
siguiente figura muestra la representación gráfica del modelo de proceso en Cascada con
Subproyectos.
Figura 7: Modelo de Proceso o Ciclo de Vida en Cascada con Subproyectos.
▪ MODELO DE PROCESO INCREMENTAL
Este es un modelo de proceso o ciclo de vida que plantea que, el software se desarrolla gradualmente,
por funcionalidades que al terminarse incrementan las capacidades del producto. Es una repetición
del ciclo de vida en cascada, aplicándose a una porción del producto cada vez. Al finalizar cada ciclo,
le entregamos una versión al cliente que contiene nuevas funcionalidades. Este modelo permite
entregas al cliente antes de finalizar completamente el proyecto.
20
Figura 8: Modelo de Proceso o Ciclo de Vida Incremental.
▪ MODELO DE PROCESO ITERATIVO
Este modelo de proceso o ciclo de vida, también derivado del modelo de cascada, busca reducir el
riesgo que surge de brechas entre las necesidades del usuario y el producto final, debido a malos
entendidos durante la etapa de requerimientos.
Es la iteración de varios ciclos de vida en cascada, donde al final de cada iteración se le entrega al
cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quién luego
de cada iteración, evalúa el producto, lo corrige o propone mejoras. Estas iteraciones se repetirán
hasta que se obtenga un producto que satisfaga al cliente. Este modelo de proceso suele utilizarse
en proyectos en los que los requerimientos no están claros de parte del usuario.
Figura 9: Modelo de Proceso o Ciclo de Vida Iterativo.
21
2.1.3. Disciplinas técnicas, de gestión y de soporte que conforman la ingeniería de software.
¿Qué es la Ingeniería de Software?
Haciendo una recopilación de todos los conceptos que se han dado sobre la Ingeniería de software,
la podemos definir como la disciplina o área de la informática, que hace uso razonable de los
principios de ingeniería con el objetivo de obtener soluciones informáticas económicamente factible
y que se adapte a las necesidades de las empresas reales, tomando en cuenta los procesos de
producción y mantenimiento de software que son desarrollados y modificados en el tiempo y con los
costos estimados.
Esta ingeniería trata con áreas muy diversas de la informática y de las Ciencias de la Computación,
tales como construcción de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet,
abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información
y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística,
banca, etc.).
Algunas definiciones, dadas a través del tiempo son:
• “Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y

mantenimiento de sistemas de software” (Zelkovitz, 1978).
• “Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y
construcción de programas de computadora y a la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o
Producción de Software” (Bohem, 1976).
• “Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería
a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales”
(Bauer, 1972).
• “Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo,
operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software”
(IEEE, 1993).
En conclusión, podemos decir que los cuatro autores anteriores, de manera diferente describen en
si el principal objetivo de la ingeniería de software, la cual es el establecimiento y puesta en práctica
de los principios y metodologías que nos lleven a un desarrollo eficiente de software en todas las
etapas desde sus inicios hasta su implementación y mantenimiento.
Paradigmas de la Ingeniería del Software
La ingeniería de software es reconocida como una disciplina legítima, digna de tener una
investigación seria, un estudio cuidadoso y generando una gran controversia. En la industria el
ingeniero del software ha sustituido al programador como título de trabajo preferente. Los modelos
de procesos de software, métodos de ingeniería de software y herramientas se han adoptado con
éxito en el amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la
necesidad de un enfoque más disciplinado del software.
22
Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, que

permite producir programas con una directriz específica, tales como: estructura modular, fuerte
cohesión, alta rentabilidad, etc.
Existen tres categorías de paradigmas de programación:
a. Los que soportan técnicas de programación de bajo nivel.

b. Los que soportan métodos de diseño de algoritmos.
c. Los que soportan soluciones de programación de alto nivel.
Los paradigmas relacionados con la programación de alto nivel se agrupan en tres categorías de
acuerdo con la solución que aportan para resolver el problema:
a. Solución procedimental u operacional. Describe etapa a etapa el modo de construir la

solución. Es decir, señala la forma de obtener la solución.
b. Solución demostrativa. Es una variante de la procedimental. Especifica la solución
describiendo ejemplos y permitiendo que el sistema generalice la solución de estos ejemplos
para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir
resultados muy diferentes a ésta, hace que sea tratada como una categoría separada.
c. Solución declarativa. Señala las características que debe tener la solución, sin describir cómo
procesarla. Es decir, señala qué se desea obtener, pero no cómo obtenerlo.
Objetivos de la Ingeniería del Software
Los objetivos principales de la ingeniería de software son los siguientes:
• Identificar las principales metodologías disponibles para la recolección y manejo de

requerimientos que deben cumplir los sistemas en desarrollo.
• Conocer las principales herramientas de verificación y validación de software y su utilidad en
las diferentes fases del desarrollo de sistemas.
• Diseñar aplicaciones informáticas que se ajusten a las necesidades de las organizaciones.
• Dirigir y coordinar el desarrollo de aplicaciones complejas.
• Intervenir en todas las fases del ciclo de vida de un producto.
• Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
• Hacer el seguimiento de costes y plazos.
• Dirigir equipos de trabajo de desarrollo software.
• Organizar la realización de pruebas que verifiquen el correcto funcionamiento de los
programas y que se ajustan a los requisitos de análisis y diseño.
• Diseñar, construir y administrar bases de datos.
• Dirigir y asesorar a los programadores durante el desarrollo de aplicaciones.
• Introducir procedimientos de calidad en los sistemas, evaluando métricas e indicadores y
controlando la calidad del software producido.
• Organizar y supervisar el trabajo de su equipo de los técnicos de mantenimiento y los
ingenieros de sistemas y redes.
23
Hoy en día, los productos de software se construyen con un nivel de urgencia que no se veía en años
anteriores. La prioridad más alta de las compañías es reducir el tiempo de salida al mercado, que es
la base del desarrollo rápido.
La ingeniería de software es percibida por algunos como demasiado formal, que consume demasiado
tiempo y demasiado estructurada para la flexibilidad necesaria durante el desarrollo de hoy en día.
Las personas que hacen estas críticas exponen que no se pueden permitir la formalidad de un
enfoque de ingeniería para construir software porque necesitan desarrollar productos de forma
rápida. Las personas que lanzan tales objeciones ven la ingeniería como una disciplina estática y
piensan que no se puede adaptar a las necesidades cambiantes del negocio y la industria. La verdad
es, sin embargo, que la ingeniería del software es adaptativa y por lo tanto, relevante para cualquiera
que construya un producto software.
La ingeniería del software es adaptativa y no una metodología rígida. Es una filosofía que puede ser
adaptada y aplicada a todas las actividades y dominios de aplicación del desarrollo de software.
La ingeniería del software proporciona una amplia colección de opciones que los profesionales
pueden elegir para construir productos de alta calidad. Sin embargo, no hay un enfoque de ingeniería
individual o un conjunto de procesos, métodos o herramientas de ingeniería del software para
construir un producto software.
El enfoque de ingeniería del software, incluyendo los procesos, métodos y herramientas puede y
debería ser adaptada al producto, la gente que lo construye y el entorno del negocio.
Todo este conjunto de ideas y opiniones llevaron a lo que hoy en día son las metodologías ágiles.
Entre los principios más destacados de la ingeniería del software, podemos señalar los siguientes:
• Haz de la calidad la razón de trabajar.

• Una buena gestión es más importante que una buena tecnología.
• Las personas y el tiempo no son intercambiables.
• Seleccionar el modelo de ciclo de vida adecuado.
• Entregar productos al usuario lo más pronto posible.
• Determinar y acotar el problema antes de escribir los requisitos.
• Realizar un diseño.
• Minimizar la distancia intelectual.
• Documentar.
• Las técnicas son anteriores a las herramientas.
• Primero hazlo correcto, luego hazlo rápido.
• Probar, probar y probar.
• Introducir las mejoras y modificaciones con cuidado.
• Asunción de responsabilidades.
• La entropía del software es creciente.
• La gente es la clave del éxito.
• Nunca dejes que tu jefe o cliente te convenza para hacer un mal trabajo.
• La gente necesita sentir que su trabajo es apreciado.
24
• La educación continua es responsabilidad de cada miembro del equipo.

• El compromiso del cliente es el factor más crítico en la calidad del software.
• Tu mayor desafío es compartir la visión del producto final con el cliente.
• La mejora continua de tu proceso de desarrollo de software es posible y esencial.
• Tener procedimientos escritos de desarrollo de software puede ayudar a crear una cultura
compartida de buenas prácticas.
• La calidad es el principal objetivo; la productividad a largo plazo es una consecuencia de una
alta calidad.
• Haz que los errores los encuentre un colaborador, no un cliente.
• Una clave en la calidad en el desarrollo de software es realizar iteraciones en todas las fases
del desarrollo excepto en la codificación.
• La gestión de errores y solicitud de cambios es esencial para controlar la calidad y el
mantenimiento.
• Si mides lo que haces puedes aprender a hacerlo mejor.
• Haz lo que tenga sentido; no recurras a los dogmas.
• No puedes cambiar todo de una vez. Identifica los cambios que se traduzcan en los mayores
beneficios, y comienza a implementarlos.
2.1.4. Gestión de configuración de software.
La necesidad de gestionar la configuración surge del hecho que el software evoluciona

constantemente.
El desarrollo del software siempre es progresivo y dadas las características de maleabilidad propias
del software, es necesario mantener organizados y controlados los cambios que se realizarán al
software a lo largo del tiempo.
Los cambios en el software tienen su origen en:
• Cambios del negocio y nuevos requerimientos.

• Soporte de cambios de productos asociados.
• Reorganización de las prioridades de la empresa por crecimiento.
• Cambios en el presupuesto.
• Defectos encontrados, a corregir.
• Oportunidades de mejora.
Un producto de software tiene integridad cuando:
• Satisface las necesidades del usuario;

• puede ser fácil y completamente rastreado durante su ciclo de vida;
• satisface criterios de performance y cumple con sus expectativas de costo.
El propósito de la disciplina de Administración de Configuración de Software es establecer y mantener

la integridad de los productos de software a lo largo de su ciclo de vida.
25
Involucra para la configuración:
• Identificarla en un momento dado,

• controlar sistemáticamente sus cambios y
• mantener su integridad y origen.
La Administración de Configuración de Software es una disciplina protectora, transversal a todo el

proyecto, que implica:
• Identificar y documentar las características funcionales y físicas de los ítems de configuración.

• Controlar los cambios a tales características.
• Reportar el proceso de tales cambios y su estado de implantación.
El objetivo es maximizar la productividad minimizando los errores. Dado a que el cambio puede
ocurrir en cualquier momento, las actividades de la administración de configuración de software son
desarrolladas para identificar el cambio, controlar el cambio, asegurar que el cambio está siendo
apropiadamente implantado, e informar del cambio a aquellos que les interesa.
Algunos conceptos relacionados con la Administración de Configuración del Software
▪ CONFIGURACIÓN
Se define como configuración del software al conjunto de ítems de configuración con su

correspondiente versión en un momento determinado.
Una configuración es el conjunto de todos los componentes fuentes que son compilados en un
ejecutable consistente, más todos los componentes, documentos e información de su estructura que
definen una versión determinada del producto en un momento de tiempo.
Una configuración cambia porque se añaden, retiran o modifican elementos. También hay que
contemplar la posibilidad de que los mismos elementos se reorganicen de forma diferente, sin que
cambien individualmente.
El control de configuración se refiere a la evolución de un conjunto de ítems de configuración.
La evolución del sistema consiste en: añadir, suprimir, modificar ítems de configuración; o bien,
reorganizar la estructura. Se llama:
• Evolución temporal: revisiones o Son cambios a lo largo del tiempo.

• Evolución espacial: variantes o Son versiones (configuraciones) simultáneas.
▪ REPOSITORIO
Un repositorio es un espacio de almacenamiento que contiene los ítems de configuración. Ayuda a

mantener la historia de cada ítem de configuración, con sus atributos y relaciones. Pueden estar
conformado por una o varias bases de datos. El repositorio permite centralizar el almacenamiento
26
de los ítems de configuración (IC) de un mismo sistema o producto de software, incluyendo las
distintas versiones de cada IC.
El repositorio permite ahorrar espacio de almacenamiento, evitando guardar por duplicado

elementos comunes a varias versiones o configuraciones. Para conseguir ese ahorro hay que disponer
de un sistema de representación especializado para las versiones.
El repositorio facilita el almacenamiento de información de la evolución del sistema (historia), no sólo

de los IC en sí. La siguiente figura muestra un modelo típico de trabajo con un repositorio.
Figura 10: Modelo Check in – Check out de un repositorio.
Puede haber dos tipos base de repositorios:
Repositorio Centralizado
• Un servidor contiene todos los archivos con sus versiones.

• Los administradores tienen mayor control sobre el repositorio.
• Falla el servidor y nadie puede trabajar.
27
Figura 11: Repositorio Centralizado.
Repositorio Distribuido
• Cada cliente tiene una copia exactamente igual del repositorio completo.
• Si un servidor falla sólo es cuestión de “copiar y pegar”.
• Posibilita otras formas de trabajo no disponibles en el modelo centralizado.
Figura 12: Repositorio Distribuido.
28
▪ ÍTEM DE CONFIGURACIÓN
Se llama ítem de configuración (IC) a todos y cada uno de los artefactos que forman parte del
producto o del proyecto, que pueden sufrir cambios o necesitan ser compartidos entre los miembros
del equipo y sobre los cuales necesitamos conocer su estado y evolución.
Ejemplos de ítems de configuración pueden ser: documentos de requerimientos, documentos de

diseño, código fuente, código ejecutable, plan de proyecto, etc.
Figura 13: Ejemplo de ítem de configuración.
▪ C AMBIO
El cambio en este contexto se define como el paso de una versión de la línea base a la siguiente.
Puede incluir modificaciones del contenido de algún componente, o modificaciones de la estructura
del sistema, añadiendo, eliminando y/o reorganizando componentes.
▪ VERSIÓN
Una versión se define, desde el punto de vista de la evolución, como la forma particular de un
artefacto en un instante o contexto dado.
También hay que contemplar la posibilidad de que coexistan versiones alternativas de un mismo
artefacto un instante dado. Es necesario disponer de un método para identificar unívocamente las
diferentes versiones de manera sistemática u organizada.
El control de versiones se refiere a la evolución de un único ítem de configuración (IC), o de cada IC

por separado.
La evolución puede representarse gráficamente en forma de grafo, en el que los nodos son las
versiones y los arcos corresponden a la creación de una nueva versión a partir de otra ya existente.
29
El siguiente gráfico muestra las revisiones sucesivas de un componente, que dan lugar a una simple
secuencia lineal.
Figura 14: Ejemplo de evolución lineal de un ítem de configuración.
Esta forma de evolución no presenta problemas desde el punto de vista de organización del
repositorio. Las versiones se pueden designar simplemente mediante números correlativos, como en
la figura.
▪ VARIANTE
Una variante es una versión de un ítem de configuración (o de la configuración) que evoluciona por
separado. Las variantes representan configuraciones alternativas. Un producto de software puede
adoptar distintas formas (configuraciones) dependiendo del lugar donde se instale. Por ejemplo,
dependiendo de la plataforma (máquina + S.O.) que la soporta, o de las funciones opcionales que
haya de realizar o no.
Cuando hay variantes, es decir, cuando existen simultáneamente varias versiones de un ítem de
configuración, el grafo de evolución ya no es una secuencia lineal, sino que adopta la forma de un
árbol. Si queremos seguir numerando las versiones se necesitará ahora una numeración a dos niveles.
El primer número designa la variante (línea de evolución), y el segundo la versión particular (revisión)
a lo largo de dicha variante, como podemos ver en la siguiente figura.
Figura 15: Variante de un ítem de configuración.
30
▪ EJEMPLO DE EVOLUCIÓN DE UNA CONFIGURACIÓN
Se presenta un ejemplo de evolución simple (secuencia temporal lineal). Las revisiones del conjunto
se han numerado correlativamente (Rev.1, Rev.2, ...). Cada configuración contiene una colección de
elementos, no siempre los mismos. Pueden crearse o eliminarse elementos entre una revisión y la
siguiente. Los cambios individuales de un componente se indican con flechas. Los componentes que
se mantienen sin cambios se marcan con dos líneas paralelas (como el signo = en vertical).
Figura 16: Ejemplo de evolución de una Configuración.
▪ LÍNEA B ASE
Una línea base es una configuración que ha sido revisada formalmente y sobre la que se ha llegado a
un acuerdo. Sirve como base para desarrollos posteriores y puede cambiarse sólo a través de un
procedimiento formal de control de cambios.
El propósito principal de la creación y administración de líneas es la posibilidad de ir atrás en el tiempo

y recuperar una versión de un producto en un momento dado del proyecto
Una definición más formal, dada por el Estándar IEEE 610.12-1990, dice: “Línea Base es una
especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo,
y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse
solamente a través de procedimientos formales de control de cambios”
31
Figura 17: Representación de Líneas Base.
Las Líneas Base pueden ser:
• De especificación: es decir contienen sólo documentación (Requerimientos, diseño, planes)

• Operacional: es decir que contiene una versión del producto que han pasado por un control
de calidad previamente definido.
▪ COMITÉ DE CONTROL DE CAMBIOS
El Comité de Control de Cambios es la autoridad responsable de la aprobación de la incorporación de

cambios a una Línea Base. Y posteriormente debe verificar que los cambios implementados sean los
que fueron autorizados.
El Comité de Control de Cambios debe tener definido el procedimiento que se utilizará para realizar
esta tarea, de manera de garantizar que todos los interesados que deban ser informados, se enteren
de la ocurrencia de un cambio.
Está formado por representantes de todas las áreas que se vean afectadas por el cambio propuesto,
ejemplos de roles de un equipo de desarrollo que pueden formar parte de un Comité de Control de
Cambios:
• Líder de Proyecto.
• Arquitecto.
• Analista Funcional.
• Gestor de Configuración de Software.
• Desarrolladores.
• Analistas de Prueba.
• Representante del Cliente.
32
Actividades Fundamentales de la Administración de Configuración de Software
El siguiente esquema presenta las 4 actividades principales que conforman la disciplina de

Administración de Configuración de Software (SCM: Software Configuration Management).
Figura 18: Actividades Principales de la Administración de Configuración de Software.
▪ IDENTIFICACIÓN DE ÍTEMS
Se trata de establecer estándares de documentación y un esquema de identificación unívoca para los

ítems de configuración que se administrarán.
▪ CONTROL DE CAMBIOS
La ingeniería de software recomienda realizar el desarrollo de manera disciplinada. Las herramientas

de control de versiones no garantizan un desarrollo razonable si cualquier miembro del equipo puede
realizar los cambios que quiera e integrarlos en el repositorio sin ningún tipo de control.
El control de cambios consiste en la evaluación y registro de todos los cambios que se hagan a la
configuración del software. Está relacionado con la naturaleza evolutiva del desarrollo de software;
creando por medio de cambios sucesivos realizados de una manera disciplinada. La evolución de un
producto de software, puede verse como la evolución de sus líneas base.
▪ AUDITORÍAS DE CONFIGURACIÓN
Sirven, junto con las revisiones técnicas para garantizar que el cambio se ha implementado
correctamente.
33
Hay dos tipos de auditorías a la configuración del software
• Auditoría de configuración física: Asegura que lo que está indicado para cada IC en la línea
base o en la actualización se ha alcanzado realmente. Evaluación independiente de los IC
para verificar que el software y su documentación son internamente consistentes y están
listos para ser entregados al cliente.
• Auditoría configuración funcional: Evaluación independiente de los productos de software,

verificando que la funcionalidad y performance reales de cada ítem de configuración sean
consistentes con la especificación de requerimientos de software.
Ambos tipos de auditoría se hacen a una línea base específica del producto de software en un
momento de tiempo determinado. Uno de los aspectos principales que se controla en estas
auditorías es la trazabilidad del producto de software, razón por la cual la Matriz de Trazabilidad es
una herramienta muy útil al momento de auditar, tal como se representa en el siguiente esquema.
La trazabilidad plantea la incorporación de vínculos entre los ítems de configuración que nos
permiten detectar si todos los requerimientos que fueron comprometidos están siendo satisfechos,
el estado de avance de cada requerimiento, como así también vínculos hacia el origen y la razón de
la incorporación de esos requerimientos en el producto de software.
Figura 19: Tipos de Auditorías de Configuración.
▪ GENERACIÓN DE INFORMES
Se ocupa de mantener los registros de la evolución del sistema. Maneja mucha información y salidas
por lo que se suele implementar dentro de procesos automáticos, cuyo soporte depende de la
herramienta de administración de configuraciones que se utilice.
Algunos reportes que se pueden obtener son:
• Momento de incorporación o actualización de una línea base.

• Estado de cada cambio propuesto.
• Momento en que se incorpora un cambio de configuración de software.
• Estado de la documentación administrativa o técnica.
34
• Deficiencias detectadas durante la auditoría de configuración.

• Información descriptiva de cada cambio propuesto.
• Reportes de rastreabilidad de todos los cambios realizados a las líneas base durante el ciclo
de vida.
▪ PLAN DE GESTIÓN DE CONFIGURACIÓN
Como todas las actividades vinculadas al desarrollo de software, las actividades vinculadas con la
administración de configuración de software también deben planificarse. En el caso particular de
estas actividades es deseable que la planificación se haga lo más tempranamente posible.
El Plan de Administración de Configuración debería incluir al menos los siguientes ítems:
• Definición de los ítems de configuración (IC) que se administrarán.

• Reglas de nombrado de los IC.
• Herramientas a utilizar para la administración de configuración.
• Responsabilidades e integrantes del Comité de Control de Cambios.
• Procedimiento formal de cambios.
• Procesos de Auditoría.
▪ ALGUNAS HERRAMIENTAS PARA ADMINISTRACIÓN DE CONFIGURACIÓN DE SOFTWARE
• MicroFocus - PVCS Dimensions.

• Platinum - CCC/Harvest.
• Rational - ClearCase.
• Microsoft - Team Fundation.
• Accurev - Accurev.
• Borland - StarTeam.
Herramientas de software libre para control de configuración:
• TortoiseSVN.
• Subversion.
• Git.
▪ ALGUNOS TIPS RELACIONADOS CON LA ADMINISTRACIÓN DE CONFIGURACIÓN DE SOFTWARE
• Hacer de la Administración de Configuración de Software (ACS), el trabajo de todos.

• Crear un ambiente y un proceso de ingeniería que permita la Administración de
Configuración.
• Definir y documentar el proceso de Administración de Configuración/Ingeniería, luego
seleccionar la/las herramientas que le den soporte al proceso.
• El personal de ACS debe contar con Individuos con conocimientos técnicos para dar soporte
al desarrollo y mantenimiento del producto.
• Los procedimientos y el Plan de ACS deben realizarse en las etapas iniciales del proyecto.
35
2.1.5. Testing y revisiones técnicas al software.
Revisar Técnicamente el Software
Las revisiones técnicas surgen a partir de la necesidad de producir software de alta calidad. Algunos
grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez
que se ha generado el código. ¡Error! El Aseguramiento de la calidad del software es una actividad de
protección que se aplica a lo largo de todo el proceso de construcción del software.
Es un proceso de revisión cuyo propósito es llegar a detectar lo antes posible, errores o desviaciones
en los productos que se van generando a lo largo del desarrollo. Esto se fundamenta en el hecho que
el trabajo debe ser revisado; debido a que hay errores que son percibidos más fácilmente por otras
personas que por los creadores.
Objetivos de las revisiones técnicas:
• Descubrir errores en la función, lógica o implementación de cualquier representación del

software.
• Verificar que el software bajo revisión alcanza sus requerimientos.
• Garantizar el uso de estándares predefinidos.
• Conseguir un desarrollo uniforme del software.
• Obtener proyectos que hagan más sencillo los trabajos técnicos (análisis que permitan
buenos diseños, diseños que permitan implementaciones sencillas, mejores estrategias de
pruebas).
Ventajas de las revisiones técnicas:
• Reducción sustancial del costo del software, evitando re-trabajo.

• Gran valor educativo para los participantes.
• Sirve para comunicar la información técnica.
• Fomenta la seguridad y la continuidad.
Directrices para la revisión:
• Revisar el producto y no al productor.

• Hacer foco en los problemas no en la forma de resolverlos.
• Indicar los errores con tino, tono constructivo.
• Fijar agenda y mantenerla.
• Enunciar problemas no resueltos.
• Limitar el debate y las impugnaciones.
• Limitar el número de participantes.
• Desarrollar una lista de comprobaciones para cada producto que pueda ser revisado.
• Disponer de recursos y planificación de tiempos.
• Entrenar los participantes.
• Reparar las revisiones anteriores.
36
• El problema debería ser resuelto por el autor.
Si bien cualquier producto de trabajo puede ser revisado técnicamente. Suele requerirse esta práctica
para una muestra de artefactos, si el producto es muy grande y esto podría afectar los compromisos
del proyecto. La siguiente tabla muestra ejemplos de artefactos de software que pueden ser
revisados y que roles podrían participar de una revisión:
Artefacto de Software Revisores sugeridos

Arquitecto, analista de requerimientos, diseñador, líder de
Arquitectura o Diseño de alto nivel
proyecto, analista de prueba.
Diseño detallado Diseñador, arquitecto, programadores, analista de prueba.
Líder de proyecto, representante de ventas o marketing,
Planes de proyecto
líder técnico, representante del área de calidad.
Analista de requerimientos, líder de proyecto, arquitecto,
Especificación de requerimientos diseñador, analistas de prueba, representante de ventas
y/o marketing.
Programador, diseñador, analista de prueba, analista de
Código fuente
requerimientos.
Analistas de prueba, programador, arquitecto, diseñador,
Plan de testing representante del área de calidad, analista de
requerimientos.
Tabla 1: Ejemplo de artefactos y revisores sugeridos.
El trabajo técnico necesita ser revisado por una simple razón: errar es humano. Otra razón por la que
son necesarias las revisiones técnicas es que, aunque la gente es buena descubriendo algunos de sus
propios errores, algunas clases de errores se le pasan más fácilmente al que los origina que a otras
personas.
El proceso de revisión es, por lo tanto, la respuesta a la plegaria de Robert Burns:
¡Qué gran regalo sería poder vernos como nos ven los demás!
Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:
• Señalar la necesidad de mejoras en el producto hecho por una sola persona o un equipo.
• Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.
• Conseguir un trabajo de mayor calidad maximizando los criterios de corrección y completitud
principalmente.
Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la
ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un
café es una forma de revisión, si se discuten problemas técnicos. Una presentación formal de un
diseño de software a una audiencia amplia y variada es una forma de revisión. La más formal de las
técnicas se llama Inspección de Software, se describirá en forma resumida un poco más adelante en
esta sección.
37
▪ IMPACTO DE LOS DEFECTOS DEL SOFTWARE EN EL COSTO
Dentro del contexto de desarrollo de software, los términos "defecto" y "falla" son sinónimos. Ambos
implican un problema de calidad descubierto después de entregar el software a los usuarios finales.
El objetivo primario de las revisiones técnicas es encontrar errores durante el proceso para evitar que
se conviertan en defectos después de la entrega del software. El beneficio obvio de estas revisiones
es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso
de desarrollo del software.
Figura 20: Clasificación de fallas en el software.
Se ha demostrado que las revisiones de software son efectivas en un 75% a la hora de detectar
errores.
Con la detección y la eliminación de un gran porcentaje de errores, el proceso de revisión reduce

substancialmente el costo de los pasos siguientes en las fases de desarrollo y mantenimiento.
Para ilustrar el impacto sobre el costo de la detección anticipada de errores, supongamos que un
error descubierto durante el diseño cuesta corregirlo 1 unidad monetaria. De acuerdo a este costo,
el mismo error descubierto justo antes de que comience la prueba costará 6,5 unidades; durante la
prueba 15 unidades; y después de la entrega, entre 60 y 100 unidades.
Se puede resumir los beneficios comprobados al aplicar revisiones técnicas en:
• Reducción de los defectos en el uso del software.

• Reducción de los recursos de desarrollo, sobre todo en las etapas de codificación y prueba.
• Reducción en los costos de mantenimiento correctivo.
38
▪ EL PROCESO DE INSPECCIÓN DE SOFTWARE
Podemos ver a las inspecciones de software como un repaso detallado y formal del trabajo en
progreso. Pequeños grupos de trabajadores (4 o 5) estudian el "producto de trabajo"
independientemente y luego se reúnen para examinar el trabajo en detalle.
El "producto de trabajo" puede ser: líneas de código, requerimientos, diseño y/o cualquier otro
artefacto. Los productos de trabajo son considerados “en progreso” hasta que la inspección y las
correcciones necesarias estén completas.
Grupos de inspección: Se recomienda formar grupos entre 3 y 6 personas [IEEE STD 1028-1988].
Dentro de este grupo debe incluirse al autor de los productos de trabajo.
Roles involucrados en una inspección de software:
Rol Responsabilidad
• Creador o encargado de mantener el producto que va a ser inspeccionado.
• Inicia el proceso asignando un moderador y designar junto al moderador el resto
Autor de los roles.
• Entrega el producto a ser inspeccionado al moderador.
• Reporta el tiempo de re trabajo y el nro. Total de defectos al moderador.
• Planifica y lidera la revisión.
• Trabaja junto al autor para seleccionar el resto de los roles.
• Entrega el producto a inspeccionar a los inspectores con tiempo (48 hs.) antes
Moderador
de la reunión.
• Coordina la reunión asegurándose que no hay conductas inapropiadas.
• Hacer seguimiento de los defectos reportados.
Lector Lee el producto a ser inspeccionado.
Anotador Registra los hallazgos de la revisión.
Examina el producto antes de la reunión para encontrar defectos. Registra sus
Inspector
tiempos de preparación.
Tabla 2: Roles involucrados en la Inspección de Software.
La inspección consiste en seis pasos [Fagan 1986]:
• Planificación: Cuando el autor completa un "producto de trabajo", se forma un grupo de

inspección y se designa un moderador. El moderador asegura que el "producto de trabajo"
satisfaga el criterio de inspección. Se le asignan diferentes roles a las personas que integran
el grupo de inspección, así como la planificación de tiempos y recursos necesario.
• Revisión General: Si los inspectores no están familiarizados con el software que se está
desarrollando, una vista general es necesaria en este momento. Este es un paso opcional,
pero no menos importante ya que en esta etapa se dará al grupo de inspección introducción
y contexto requeridos para actuar durante las inspecciones.
39
• Preparación: Los inspectores se preparan individualmente para la inspección en la reunión,

estudiando los productos de trabajo y el material relacionado. Aquí es aconsejable la
utilización de listas de chequeo para ayudar a encontrar defectos comunes. El tiempo que
pueda llevar esta etapa va a depender de cuan familiarizado esté el inspector con el trabajo
que debe analizar.
• Reunión: En esta etapa, los inspectores se reúnen para analizar su trabajo individual en forma
conjunta. El moderador deberá asegurarse que todos los inspectores están suficientemente
preparados. La persona designada como lector presenta el "producto de trabajo",
interpretando o parafraseando el texto, mientras que cada participante observa en busca de
defectos. Es recomendable que este examen no dure más de 2 horas ya que la atención en
busca de defectos va disminuyendo con el tiempo. Al terminar con la reunión, el grupo
determina si el producto es aceptado o debe ser re trabajado para una posterior inspección.
Los dos resultados principales deben ser: Una lista de defectos a corregir, y un reporte de
inspección que describa que es lo que se inspeccionó, quien inspeccionó qué y el número de
defectos encontrados.
• Re trabajo: El autor corrige todos los defectos encontrados por los inspectores.
• Seguimiento: El moderador chequea las correcciones del autor. Si el moderador está

satisfecho, la inspección está formalmente completa, y el "producto de trabajo" aceptado.
• El proceso de inspección debe ser llevado a cabo por personas que conozcan tanto del
dominio específico, del producto de software, así como la tecnología aplicada a las soluciones
que serán objeto de la inspección. A partir de este conocimiento en el equipo de inspección,
deberán respetarse las etapas planteadas precedentemente, creando las condiciones
necesarias para maximizar la sinergia que se produzca sobre todo en la etapa de "examen".
▪ PUNTOS C LAVE PARA TENER EN CUENTA :
• Revisar al producto… no al productor.

• Fijar una agenda y cumplirla.
• Limitar el debate y las impugnaciones.
• Enunciar las áreas de problemas, pero no tratar resolver cualquier problema que se
manifieste.
• Tomar notas escritas.
• Limitar el nro. de participantes e insistir en la preparación por anticipado.
• Desarrollar una lista de revisión.
• Disponer recursos y una agenda.
• Entrenamiento.
• Repasar revisiones anteriores.
• Aprender sobre inspecciones y convencer al proyecto de utilizarlas.
• Determinar en qué parte del proyecto deben ser utilizadas.
• Definir para cada proyecto cómo se realizarán las revisiones técnicas.
40
Probar el Software - Testing
La prueba de software, más conocida por su nombre en inglés: “testing de software” pertenece a una
actividad o etapa del proceso de producción de software denominada Verificación y Validación -
usualmente abreviada como V&V.
V&V es el nombre genérico dado a las actividades de comprobación que aseguran que el software
respeta su especificación y satisface las necesidades de sus usuarios. El sistema debe ser verificado y
validado en cada etapa del proceso de desarrollo utilizando los documentos (descripciones)
producidas durante las etapas anteriores. Cómo vimos en la sección anterior no sólo el código debe
ser sometido a actividades de V&V sino también todos los artefactos generados durante el desarrollo
del software.
Si bien estos términos en su uso cotidiano pueden llegar a ser sinónimos, para la Ingeniería de
Software tienen significados diferentes y cada uno tiene una definición precisa.
• Validación: ¿estamos construyendo el producto correcto?

• Verificación: ¿estamos construyendo el producto correctamente?
En este sentido, la verificación consiste en corroborar que el programa respeta su especificación,

mientras que validación significa corroborar que el programa satisface las expectativas del usuario.
El testing es una actividad desarrollada para controlar la calidad del producto, al identificar defectos
y problemas. El testing de software consiste en la verificación dinámica del comportamiento de un
programa sobre un conjunto finito de casos de prueba, apropiadamente seleccionados, en relación
con el comportamiento esperado. Es una técnica dinámica en el sentido de que el programa se
verifica poniéndolo en ejecución de la forma más parecida posible a como se ejecutará cuando esté
en producción.
El programa se prueba ejecutando sólo unos pocos casos de prueba dado que por lo general es física,
económica y/o técnicamente imposible ejecutarlo para todos los valores de entrada posibles. De aquí
la frase de Dijkstra: “Si uno de los casos de prueba detecta un error el programa es incorrecto, pero
si ninguno de los casos de prueba seleccionados encuentra un error no podemos decir que el
programa es correcto (perfecto)”.
Esos casos de prueba son elegidos siguiendo alguna regla o criterio de selección.
Se determina si un caso de prueba ha detectado un error o no comparando la salida producida con

la salida esperada para la entrada correspondiente, la salida esperada debería estar documentada en
la especificación del programa.
Las limitaciones antes mencionadas no impiden que el testing se base en técnicas consistentes,
sistemáticas y rigurosas (e incluso, como veremos más adelante, formales). Sin embargo, en la
práctica industrial, como ocurre con otras áreas de Ingeniería de Software, usualmente se considera
sólo una parte mínima de dichas técnicas tornando a una actividad razonablemente eficaz y eficiente
en algo útil y de escaso impacto.
41
▪ ALGUNOS CONCEPTOS BÁSICOS SOBRE EL TESTING
Testear un programa significa ejecutarlo bajo condiciones controladas tales que permitan observar
su salida o resultados.
Se definirán en primer lugar algunos conceptos:
• Falta (Failure): cuando un programa funciona mal.

• Falla (Fault): existe en el código del programa. Puede provocar una falta.
• Error: Acción humana que resulta en software que contiene una falla.
La primera lección a aprender es que no se puede probar que el sistema no tenga una falta, sí que
esté libre de fallas. El propósito de la prueba es encontrar fallas
La prueba es un proceso destructivo, tener que indagar sobre lo que hicimos para detectar lo que
hicimos mal.
Es conocido que la corrección de una falla provoca fallas adicionales, en consecuencia, si una falla
aparece debemos probar todo el software nuevamente.
▪ PRINCIPIOS DEL TESTING DE SOFTWARE
• Un programador debería evitar probar su propio código.

• Una unidad de programación no debería probar sus propios desarrollos.
• Examinar el software para probar que no hace lo que se supone que debería hacer.
• Examinar el software para detectar que hace lo que no se supone que debería hacer.
• No planificar el esfuerzo de testing sobre la suposición de que no se van a encontrar defectos.
• El testing es una tarea extremadamente creativa e intelectualmente desafiante.
• Testing temprano, lo más temprano posible.
• La paradoja del pesticida: Si las pruebas se repiten una y otra vez, con el tiempo el mismo
conjunto de casos de prueba ya no encuentran nuevos errores. Para superar esta “paradoja
del pesticida”, los casos de prueba deben ser examinados y revisadas periódicamente.
• El testing es dependiente del contexto: Las pruebas se realizan de manera diferente en
diferentes contextos. Por ejemplo, la seguridad del software será testeada de forma
diferente en un sitio de comercio electrónico que en uno donde se comparten fotografías.
No todos los sistemas de software llevan el mismo nivel de riesgo y no todos los problemas
tienen el mismo impacto cuando se producen.
• Falacia sobre la ausencia de errores: que no encontremos errores no significa que no estén
ahí.
▪ TIPOS DE PRUEBAS (TESTS)
Las pruebas (tests) se hacen para verificar y validar tanto requerimientos funcionales como
requerimientos no funcionales.
42

4 Modulo Teoria-1-43

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

4 Modulo Teoria-1-43

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE SOFTWARE

Módulo IV – Apunte Teórico

1. Definición del Módulo.

Este módulo selecciona un conjunto de conocimientos vinculados con la disciplina de Ingeniería de

• Integrar un equipo en el contexto de un Proyecto de Desarrollo de Software.

El desarrollo de software es una actividad social, que se desarrolla principalmente en equipo, en

• Dimensionar su trabajo en el contexto del proyecto de desarrollo de software.

El objetivo general de este módulo es:

Los objetivos de aprendizaje son:

• Identificar las disciplinas que conforman la Ingeniería de Software y las técnicas y

• Reconocer la importancia de la Gestión de Configuración de Software.

Los contenidos del módulo se resumen seguidamente:

• Proceso de Desarrollo definidos y empíricos.

En el diccionario bilingüe Longman, se define el término software como el conjunto de programas

1. Las instrucciones (programas de computadoras) que al ejecutarse proporcionan las

Características del software

El software es un elemento lógico, no físico, para comprender mejor al software es importante

1. El software no se manufactura, se desarrolla.

La existencia de pedidos de cambio y evolución constante de su función y/o estructura, su desarrollo

Sistema Informático y la Ingeniería para su desarrollo

Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su

• Los sistemas no responden a las expectativas de los usuarios.

El primer reconocimiento público de la existencia de problemas en la producción de software tuvo

El objetivo principal que busca la ingeniería de software es convertir el desarrollo de software en un

El estudio de enfoques en Pressman caracteriza la Ingeniería de Software como “una tecnología

Figura 1: Capas de la Ingeniería de Software.

Dichas capas se describen a continuación:

fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de

Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad

Disciplinas de la Ingeniería de Software

Considerando que el propósito de la Ingeniería de Software es obtener productos de software de

Figura 2: Principales Disciplinas de la Ingeniería de Software.

2.1. Disciplinas implicadas en el desarrollo de software.

2.1.1. Procesos de desarrollo definidos y empíricos.

El desarrollo de software en una mirada

El desarrollo de software se trata de desarrollar y entregar gran software. Un software es un gran

Figura 3: Una mirada al Desarrollo de Software.

▪ Desarrollar Software → Dejar contento al Cliente

El desarrollo de Software es una actividad cuyo propósito es transformar ideas, necesidades y

A continuación, vamos a hacer un recorrido por las actividades principales, involucradas en el

▪ Recolectar Requerimientos → Saber que quiere el Cliente

De todas las actividades involucradas en el desarrollo de software, la más difícil de todas es

▪ Planificar → Definir la hoja de ruta para el viaje

Un plan es a un proyecto lo que una hoja de ruta a un viaje.

▪ Estimar → ¿Cuán grande será? ¿Cuánto costará? ¿Cuándo estará terminado?

▪ Diseñar → Crear el Software

La profundización de los conceptos, principios, técnicas y herramientas relacionadas con el Diseño

▪ Programar → Construir el Software

Se transforman diseños utilizando uno o varios lenguajes de programación, obteniendo un producto

El resultado de este proceso es lo que se instala en las computadoras de los usuarios.

Los conceptos, principios, técnicas y herramientas relacionadas con la Programación en general, y

▪ Revisar Técnicamente → Verificar con un colega lo que hicimos

Dado que el software es invisible, y lo desarrollamos en nuestra mente, es esperable que

▪ Probar → ¿Construimos el producto adecuado? ¿Funciona correctamente?

▪ Controlar la Configuración → Cuidar y defender lo que desarrollamos

▪ Monitorear → ¿Cómo vamos en el viaje? ¿Podemos decirlo con números?

Figura 4: Las 4 “P” en el desarrollo de Software.

▪ PERSONAS: ¿QUIÉN HACE QUE?

El factor humano es fundamental para el éxito del proyecto.

Algunos de los factores que deben considerarse al momento de la conformación de un Equipo de

• Experiencia en el dominio de la aplicación.

▪ PROCESO: CÓMO SE HACEN LAS COSAS

Un proceso de desarrollo de software contiene además de la definición de las actividades,