10

Ingeniería de
software

Fundamentos de Ciencias de la Computación • Aprendizaje Cengage

10.1
 objetivos
Después de estudiar este capítulo, el estudiante debe ser capaz de:

• Entender el concepto del ciclo de vida del software en la ingeniería de software.

• Describe dos tipos principales de proceso de desarrollo, la cascada y modelos

incrementales.

• Comprender la fase de análisis y describir dos enfoques separados en la fase de análisis:

procedimiento - análisis orientado y objeto - análisis orientado.

• Entender la fase de diseño y describir dos enfoques distintos en la fase de diseño:

Procedimiento - diseño orientado a objetos y - diseño orientado.

• Describir la fase de implementación y reconocer los problemas de calidad en esta fase.

• Describir la fase de prueba y distinguir entre el vidrio - la prueba de caja y las pruebas de caja negra.

• Reconocer la importancia de la documentación en ingeniería de software y distinguir entre la

documentación del usuario, documentación del sistema y documentación técnica.

10.2
 10-1 EL CICLO DE VIDA DEL SOFTWARE

Un concepto fundamental en Ingeniería de software es el

ciclo de vida del software . Software, como muchos otros productos, pasa por
un ciclo de repetición de fases (Figura 10.1).

Figura 10.1 El ciclo de vida del software

10.3
modelos de procesos de desarrollo

Aunque la ingeniería de software involucra a los tres procesos en la figura

10.1, en este capítulo que sólo la discutimos
proceso de desarrollo , Que se muestra fuera del ciclo en la figura 10.1.

El proceso de desarrollo en el ciclo de vida del software consta de cuatro fases: an

, diseño , implementación y pruebas .

Existen varios modelos para el proceso de desarrollo. Se discuten los dos

más comunes aquí: la modelo de cascada y el modelo incremental .

10.4
El modelo de cascada
En este modelo, el proceso de desarrollo fluye en una sola dirección. Esto
significa que una fase no puede iniciarse hasta que se complete la fase
anterior.

Figura 10.2 El modelo de cascada

10.5
El modelo incremental
En el modelo incremental, el software se desarrolla en una serie de pasos.

Figura 10.3 El modelo incremental

10.6
 FASE 10

El proceso de desarrollo comienza con la fase de análisis .

Esta fase da lugar a un documento de especificación que muestra lo
que el software hará sin especificar cómo se va a hacer .

La fase de análisis puede utilizar dos enfoques separados , Dependiendo de si

la fase de implementación se realiza mediante una lenguaje de programación
procedimental o un a objetos lenguaje orientado .

10.7
análisis orientado Procedimiento

Procedimiento - orientado análisis - también llamado análisis estructurado o análisis

clásico - es el proceso de análisis utilizado si la fase de implementación del sistema
utilizará un lenguaje de procedimientos.

La especificación en este caso puede utilizar varias herramientas de modelado, pero

hablar sólo unos pocos de ellos aquí.

10.8
diagramas de flujo de datos

diagramas de flujo de datos muestran el movimiento de datos en el sistema.

Figura 10.4 Un ejemplo de un diagrama de flujo de datos

10.9
diagramas entidad
Otra herramienta de modelado utilizado durante la fase de análisis es la
relación diagrama de entidad . Desde este diagrama también se utiliza en el diseño de la base

de datos, lo discutimos en el capítulo 12.

diagramas de estado

diagramas de estado (véase el Apéndice B) proporcionan otra herramienta útil que se

utiliza normalmente cuando el estado de las entidades en el sistema cambiará en
respuesta a eventos.
Como un ejemplo de un diagrama de estado, se muestra el funcionamiento de un
ascensor de un pasajero. Cuando se oprime un botón del piso, el ascensor se
mueve en el sentido solicitado. No responde a ninguna otra solicitud hasta que
llegue a su destino.

10.10
 Figura 10.5 Un ejemplo de un diagrama de estado

10.11
análisis orientado a objetos

análisis orientado a objetos es el proceso de análisis utilizado si la aplicación

utiliza un lenguaje orientado a objetos. El documento de especificación en este
caso puede utilizar varias herramientas, pero hablar sólo unos pocos de ellos
aquí.

10.12
Los diagramas de casos

Un diagrama de casos de uso da la usuario ' vista s de un sistema: muestra cómo los
usuarios se comunican con el sistema. Un diagrama de casos de uso utiliza cuatro
componentes: del sistema, casos de uso, actores y relaciones . Un sistema, que se muestra
mediante un rectángulo, realiza una función.

Figura 10.6 Un ejemplo de diagrama de casos de uso

10.13
Los diagramas de clases

El siguiente paso en el análisis es crear un diagrama de clases para el sistema.

Por ejemplo, podemos crear un diagrama de clases para nuestro ascensor de estilo
antiguo. Para ello, tenemos que pensar en las entidades que participan en el sistema.

Figura 10.7 Un ejemplo de un diagrama de clases

10.14
gráfico de Estado

Después se finaliza el diagrama de clases, un diagrama de estado se puede preparar para

cada clase en el diagrama de clases.

UNA gráfico de estado en análisis orientado a objetos juega el mismo papel que la diagrama

de estado en el análisis orientado al procedimiento .

10.15
 FASE 10

La fase de diseño define cómo el sistema va a lograr lo que se

define en la fase de análisis.

En la fase de diseño, se definen todos los componentes del sistema.

10.16
diseño orientado Procedimiento
En diseño orientado al procedimiento, tenemos ambos procedimientos y datos para el diseño.

Discutimos una categoría de métodos de diseño que se concentran en los procedimientos.

En el diseño de procedimientos orientados , Todo el sistema se divide en un conjunto de

procedimientos o módulos .

10.17
los diagramas de estructura

Una herramienta común para ilustrar la relaciones entre los módulos en el diseño orientado al

procedimiento es un diagrama de estructura. Por ejemplo, el sistema de ascensor, cuyo

diagrama de estados se muestra en la figura 10.5 puede ser diseñado como un conjunto de

módulos que se muestran en el diagrama de estructura en la figura 10.8. los diagramas de

estructura se discuten en el Apéndice D.

Figura 10.8 Un diagrama de estructura

10.18
Modularidad
La modularidad significa romper un proyecto grande en partes más pequeñas

que se pueden entender y manejar fácilmente.

El diagrama de estructura discutido en la sección anterior muestra la modularidad en
el sistema de ascensor.
Hay dos principales preocupaciones cuando un sistema se divide en módulos: acoplam
y cohesión .

El acoplamiento es una medida de la fuerza con dos módulos están unidos el uno al otro .

yo

El acoplamiento entre módulos en un sistema de software

debe ser minimizado.

10.19
 La cohesión es una medida de cuán estrechamente los módulos en un sistema están
relacionados . Tenemos que tener la máxima cohesión posible entre módulos en un
sistema de software.

聯結力( acoplamiento) : 如果 一個 模組 內 的 組成 元件 之間 緊密 的 結合 在一起 而且 彼

此 的 相依 性 很高 那 我們 說 這個 模組 的 聯結 力 很 高 在 系統 設計 時 我們 要求 模組
的 聯結 力 愈低 愈好 . ( cohesión): 如果 一個 模組 內 的 組成 元件 之間 的 相關 性 很高
而且 都是 為了 完成 同一 目標 而 組成 的 那 我們 說 這個 模組 的 內 聚 力 很高 在 系統
設計 時 我們 要求 模組 的 內聚力 愈高 愈好 .

yo

Cohesión entre módulos en un sistema de software

debe ser maximizada.
10.20
diseño orientado a objetos
En el diseño orientado a objetos la fase de diseño continúa mediante la elaboración de los

detalles de las clases. Una clase está hecho de un conjunto de variables (atributos) y un

conjunto de métodos.

La fase de diseño orientado a objetos enumera los detalles de estos atributos y

métodos .

La figura 10.9 muestra un ejemplo de los detalles de nuestras cuatro clases que se utilizan
en el diseño del ascensor de estilo antiguo.

Figura 10.9 Un ejemplo de las clases con atributos y métodos

10.21
 FASE DE EJECUCIÓN 10

En el modelo de cascada, una vez finalizada la fase de diseño, la fase de

implementación puede comenzar.

En esta fase los programadores escriben el código de los módulos en el diseño

orientado al procedimiento, o escriba las unidades de programa para
implementar clases de diseño orientado a objetos .

Hay varias cuestiones que tenemos que mencionar en cada caso.

10,22
Elección de la lengua

En un desarrollo orientado al procedimiento, el equipo del proyecto tiene que elegir

un idioma o un conjunto de lenguas de entre las lenguas de procedimiento discutido
en el capítulo 10.
Aunque algunos lenguajes como C ++ se consideran ser tanto un procedimiento y un
objeto - lenguaje orientado - normalmente una implementación utiliza un lenguaje
puramente de procedimiento tales como C. En el objeto - caso orientado, tanto C ++ y
Java son comunes.

10.23
La calidad del software

La calidad del software creado en la fase de implementación es un tema muy

importante.

Un sistema de software de alta calidad es aquella que satisface al usuario ' s

requisitos, cumple con las normas de funcionamiento de la organización, y se ejecuta
de manera eficiente en el hardware para el que se desarrolló.

Sin embargo, si queremos lograr un sistema de software de alta calidad, hay que
ser capaz de definir algunos atributos de calidad .

10,24
factores de calidad de software

La calidad del software se puede dividir en tres amplias medidas:

operabilidad , mantenibilidad y transferibilidad . Cada una de estas medidas se
puede romper más abajo como se muestra en la figura 10.10.

Figura 10.10 Los factores de calidad

10.25
 10-5 PRUEBA DE FASE

El objetivo de la fase de pruebas es encontrar errores.

Hay dos tipos de pruebas: caja de vidrio y caja negra

(Figura 10.11).

Figura 10.11 Pruebas de software

10.26
pruebas de caja de vidrio

pruebas de caja de vidrio ( pruebas de caja blanca ) se basa en el conocimiento de la

estructura interna del software.

El objetivo es la prueba para determinar si todos los componentes del software de

hacer lo que están diseñados para . pruebas de caja de vidrio que asume el
probador sabe todo sobre el software . En este caso, el software es como una caja
de cristal en la que todo está dentro de la caja visible .

pruebas de caja de vidrio se realiza por el ingeniero de software o un equipo dedicado .

Varias metodologías de ensayo han sido diseñadas en el pasado. Se discuten

brevemente dos de ellos: las pruebas de ruta de base y
control de comprobación de estructura .

10,27
las pruebas de ruta de base

las pruebas de ruta de base fue propuesto por Tom McCabe.

Este método crea un conjunto de casos de prueba que se ejecuta cada instrucción en el
software al menos una vez.

yo

las pruebas de ruta de base es un método en el que se ejecuta al

menos una vez cada declaración en el software.

10,28
 Ejemplo 10.1
Para dar a la idea de la prueba de ruta de base y la búsqueda de los caminos
independientes en parte de un programa, se supone que un sistema se compone de un solo
programa y que el programa es un solo bucle con el diagrama de UML muestra en la figura
10.12.

Figura 10.12 Un ejemplo de las pruebas de ruta de base

10.29
pruebas de estructura de control

las pruebas de estructura de control es más amplio que las pruebas de ruta de base
y lo incluye.

Este método utiliza las distintas categorías de pruebas que se enumeran a continuación.

• las pruebas de condición

• pruebas de flujo de datos

• comprobación de bucle

10.30
las pruebas de recuadro negro

pruebas de caja negro recibe su nombre por el concepto de pruebas de software

sin saber lo que está dentro de él y sin saber cómo funciona . En otras palabras,
el software es como una caja de negro en el que la probador no puede ver .

las pruebas de recuadro negro prueba la funcionalidad del software en términos

de lo que se supone que el software para llevar a cabo, tales como sus entradas
y salidas. Varios métodos se utilizan en pruebas de caja negro

10.31
Las pruebas exhaustivas

El mejor método de prueba de recuadro negro es probar el software para todos los
valores posibles de entrada en el dominio . Sin embargo, en software complejo el
dominio de entrada es tan grande que a menudo es práctico hacerlo.

Las pruebas al azar

En las pruebas al azar, un subconjunto de valores en el dominio de entrada se

selecciona para la prueba . Es muy importante que el subconjunto ser elegido de tal
manera que los valores se distribuyen sobre la entrada de dominio. El uso de
generadores de números aleatorios puede ser muy útil en este caso.

10.32
 las pruebas de valores en la frontera

Los errores ocurren a menudo cuando se encontraron con los valores límite.

Por ejemplo, si un módulo define que una de sus entradas debe ser mayor que
o igual a 100, es muy importante que el módulo de ser probado para el valor
límite 100. Si el módulo falla a este valor límite, es posible que alguna
condición en el módulo de ' código de s tales como x ≥ 100 se escribe como x>
100.

10.33
 10

Para el software que se utiliza adecuadamente y se mantiene de manera eficiente, se requiere

documentación. Generalmente, Tres conjuntos separados de la documentación se preparan

para el software:

documentación 1.User
documentación 2.system
documentación 3.Technical

yo

La documentación es un proceso continuo.

10,34
Documentación del usuario

Para ejecutar el sistema de software correctamente, los usuarios necesitan

documentación, tradicionalmente llamado guía del usuario , que muestra cómo utilizar el
software paso a paso. Guías de usuario por lo general contiene una sección tutorial para
guiar al usuario a través de cada característica del software.

Una buena guía del usuario puede ser una muy poderosa herramienta de marketing: la

importancia de la documentación del usuario en la comercialización no puede dejar de

enfatizarse. guías de usuario deben ser escritas para el principiante y los usuarios expertos, y

un sistema de software con una buena documentación del usuario sin duda aumentará las

ventas.

10.35
La documentación del sistema

La documentación del sistema define el propio software. Debe ser escrito para
que el software se puede mantener y modificada por personas distintas de los
desarrolladores originales.

La documentación del sistema debe existir para las cuatro fases del desarrollo del
sistema.

10,36
Documentación técnica

documentación técnica describe la instalación y el servicio del sistema

de software.

documentación de instalación define la forma en que el software debe ser

instalado en cada equipo, por ejemplo, servidores y clientes. documentación de
servicio define la forma en que el sistema debe ser mantenido y actualizado si es
necesario.

10,37