Daniel Alfredo Chamaidan Asencio

S4D
Programa de estudio

INGENIERIA EN SOFTWARE
Ing. Tana Peralta

Programa de Estudios

Unidad 1
mbitos generales de la ingeniera de software
1. Introduccin
1.1.

Qu es la ingeniera de software?

1.2.

Qu es un proceso de software?

1.3.

Cules son los mbitos de un buen software?

Segn (Sommerville, 2005 ) dice que la ingeniera del software es una disciplina de
la ingeniera que comprende todos los aspectos de la produccin de software desde
las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste
despus de que se utiliza. En esta definicin, existen dos frases clave:
1. Disciplina de la ingeniera. Los ingenieros hacen que las cosas
funcionen. Aplican teoras, mtodos y herramientas donde sean
convenientes, pero las utilizan de forma selectiva y siempre tratando de
descubrir soluciones a los problemas, aun cuando no existan teoras y
mtodos aplicables para resolverlos. Los ingenieros tambin saben que deben
trabajar con restricciones financieras y organizacionales, por lo que buscan
soluciones tomando en cuenta estas restricciones.
2. Todos los aspectos de produccin de software. La ingeniera del
software no slo comprende los procesos tcnicos del desarrollo de software,
sino tambin con actividades tales como la gestin de proyectos de software
y el desarrollo de herramientas, mtodos y teoras de apoyo a la produccin
de software.
En general, los ingenieros de software adoptan un enfoque sistemtico y organizado
en su trabajo, ya que es la forma ms efectiva de producir software de alta calidad.
Sin embargo, aunque la ingeniera consiste en seleccionar el mtodo ms apropiado
para un conjunto de circunstancias, un enfoque ms informal y creativo de
desarrollo podra ser efectivo en algunas circunstancias. El desarrollo informal es
apropiado para el desarrollo de sistemas basados en Web, los cuales requieren una
mezcla de tcnicas de software y de diseo grfico.

Un proceso del software es un conjunto de actividades y resultados asociados que

producen un produelo de software. Estas actividades son llevadas a cabo por los
ingenieros de software. Existen cuatro actividades fundamentales de procesos
(incluidas ms adelante en este libro) que son comunes para todos los procesos del
software. Estas actividades son:
1. Especificacin del software donde los clientes e ingenieros definen el
software a producir y las restricciones sobre su operacin.
2. Desarrollo del software donde el software se disea y programa.
3. Validacin del software donde el software se vlida para asegurar que es
lo que el cliente requiere.
4. Evolucin del software donde el software se modifica para adaptarlo a los
cambios requeridos por el cliente y el mercado.
Diferentes tipos de sistemas necesitan diferentes procesos de desarrollo. Por
ejemplo, el software de tiempo real en un avin tiene que ser completamente
especificado antes de que empiece el desarrollo, mientras que, en un sistema de
comercio electrnico, la especificacin y el programa normalmente son desarrollados
juntos. Por lo tanto, estas actividades genricas pueden organizarse de diferentes
formas y describirse en diferentes niveles de detalle para diferentes tipos de
software. Sin embargo, el uso de un proceso inadecuado del software puede reducir
la calidad o la utilidad del producto de software que se va a desarrollar y/o
incrementar los costes de desarrollo.

(Aparicio, Abril 2004)Describe el control y los datos a procesar, la funcin, el

rendimiento, las restricciones, las interfaces y la fiabilidad. Se evalan las funciones
descritas en la declaracin del mbito, y en algunos casos se refinan para dar ms
detalles antes del comienzo de la estimacin.
El mbito comprende:
Recoleccin de la informacin

Su objetivo es acercar al desarrollador y al cliente para establecer una

comunicacin, para lograr esto, se utiliza una tcnica muy comn que es una
reunin o una entrevista preliminar.
Esta reunin o entrevista debe involucrar los siguientes tipos de preguntas:
1. Preguntas de contexto libre: se centran en el cliente, en los objetivos
globales y en los beneficios. Estas preguntas deben llevar a un
entendimiento bsico del problema, las personas interesadas en la solucin
y la solucin que se desea.
2. Meta cuestiones: estas preguntas se centran en la efectividad de la reunin,
involucra preguntas para determinar si la persona es la apropiada para
responder a las preguntas, si sin relevantes las preguntas para el problema
en estudio, si las respuestas son oficiales, si existe algo que se debera
preguntar.
Tambin existe otra tcnica que permite la creacin de un equipo compuesto por los
clientes y los desarrolladores para identificar el problema, proponer elementos de
solucin, establecer enfoques y especificar un conjunto preliminar de requisitos
denominada TFEA (Facilitated application specification techniques) - Tcnica para
facilitar las especificaciones de la aplicacin.
Viabilidad
Se centra en preguntarse:
Se puede construir el software de acuerdo al mbito definido?
Es factible el proyecto?
La factibilidad del software tiene 4 dimensiones: Tecnologa, financiacin, Tiempo y
Recursos. Tanto el equipo de desarrollo y las dems personas involucradas en el
software deben determinar si puede ser construido dentro de las dimensiones
especificadas.
RECURSOS
Comprende la estimacin de los recursos necesarios para emprender el desarrollo
del software.
Los recursos de desarrollo son:
Recurso humano
Se debe establecer el perfil y las habilidades que se necesitan del personal que se
necesita para llevar a cabo el desarrollo del proyecto. Hay que especificar tanto la
posicin dentro de la organizacin como la especialidad.

Gestor

Ingeniero de software

Analista de sistemas
El nmero de personas requerido para un proyecto de software se determina
despus de hacer una estimacin del esfuerzo de desarrollo.
Recursos de software reutilizable
Se destaca la reutilizacin, esto es, la creacin y la reutilizacin de bloques de
construccin de software.
Se establecen 4 categoras de recursos de software que se deben tener en cuenta a
medida que se avanza con la planificacin:

Componentes ya desarrollados: componentes que ya han sido validados

totalmente se pueden utilizar e implementar en el desarrollo del proyecto
actual.

Componentes ya experimentados: se puede utilizar Especificaciones,

diseos, cdigo o datos de prueba existentes que ya han sido desarrollados
para proyectos anteriores.

Componentes con experiencia parcial: se puede utilizar Especificaciones,

diseos, cdigo o datos de prueba existentes que ya han sido desarrollados
para proyectos anteriores y que requieren una modificacin sustancial.

Componentes nuevos: componentes que el equipo de software requiere

construir especficamente para el proyecto.

2. Sistema socio-tcnicos
2.1.

Propiedades emergentes de los sistemas

Las complejas relaciones entre los componentes de un sistema indican que el sistema
es ms que simplemente la suma de sus partes. ste tiene propiedades que son
propiedades del sistema como un todo. Estas propiedades emergentes

(Checkland, 1981) no se pueden atribuir a ninguna parte especfica del sistema. Ms

bien, emergen slo cuando los componentes del sistema han sido integrados.
Algunas de estas propiedades pueden derivar directamente de las propiedades
comparables de los subsistemas. Sin embargo, ms a menudo, resultan de complejas
interrelaciones de los subsistemas que no pueden, en la prctica, derivarse de las
propiedades de los componentes individuales del sistema. En la Figura 2.1 se
muestran ejemplos de algunas propiedades emergentes.
Existen dos tipos de propiedades emergentes:
1. Las propiedades emergentes funcionales aparecen cuando todas las
partes de un sistema trabajan de forma conjunta para cumplir algn objetivo.
Por ejemplo, una bicicleta tiene la propiedad funcional de ser un instrumento
de transporte una vez que sus componentes se han conjuntado.
2. Las propiedades emergentes no funcionales se refieren al
comportamiento de los sistemas en su entorno operativo. Ejemplos de
propiedades no funcionales son la fiabilidad, el rendimiento, la seguridad y la
proteccin. A menudo son factores crticos para sistemas informticos, ya que
un fallo mnimo en estas propiedades puede hacer inutilizable el sistema.
Algunos usuarios puede que no necesiten ciertas funciones del sistema, por
lo que ste puede ser aceptable sin ellas. Sin embargo, un sistema no fiable o
demasiado lento es probablemente rechazado por todos los usuarios.
Para ilustrar la complejidad de las propiedades emergentes, considere la propiedad
de la fiabilidad del sistema. La fiabilidad es un concepto complejo que siempre debe
estudiarse en el nivel del sistema ms que en el de los componentes individuales. Los
componentes de un sistema son interdependientes, de tal forma que un fallo en uno
de ellos se puede propagar a travs del sistema y afectar a la operacin de otros
componentes. A veces es difcil predecir la manera en que las consecuencias de los
fallos de los componentes se propagan a travs del sistema. Por consiguiente, no se
pueden hacer buenas estimaciones de la fiabilidad en conjunto del sistema de los
datos de fiabilidad de los componentes del sistema.
Existen tres influencias conexas sobre la fiabilidad de un sistema:
1. Fiabilidad del hardware. Cul es la probabilidad de que un componente
hardware falle y cunto tiempo lleva reparar ese componente?
2. Fiabilidad del software. Qu probabilidad hay de que un componente
software produzca una salida incorrecta? Los fallos de funcionamiento del
software normalmente son distintos de los del hardware en el sentido de que
el software no se desgasta. Los fallos son normalmente transitorios por lo que
el sistema puede continuar funcionando despus de que se haya producido
un resultado incorrecto.
3. Fiabilidad del operador. Qu probabilidad existe de que un operador de
un sistema cometa un error?
Estas influencias estn fuertemente relacionadas. Los fallos de hardware pueden
generar falsas seales fuera del rango de las entradas esperadas por el software. El
software puede entonces comportarse de forma impredecible. Un error del operador
es ms probable en condiciones de tensin, como cuando ocurren fallos del sistema,
Estos errores del operador pueden afectar al hardware, causando ms fallos, y as
sucesivamente. Por lo tanto, el fallo inicial recuperable puede convertirse
rpidamente en un problema serio que requiera una parada completa del sistema.
Al igual que la fiabilidad. otras propiedades emergentes, como el rendimiento o la
usabilidad. Son difciles de valorar, pero se pueden medir despus de que el sistema
est en funcionamiento. Sin embargo, propiedades como la seguridad y la proteccin
presentan diversos problemas. Aqu, se tiene conexin no slo con un atributo
relacionado con el comportamiento total del sistema, sino con el comportamiento que
el sistema no debera mostrar. Un sistema seguro es aquel que no permite accesos
no autorizados a sus datos, pero es claramente imposible predecir todos los posibles
modos de acceso y prohibirlos de forma explcita. Por lo tanto, slo es posible valorar
estas propiedades por defecto. Esto es, slo se puede saber Que el sistema es
inseguro cuando alguien lo viola. (Sommerville, 2005 )

2.2.

Definicin de requerimiento del sistema

2.3.

Diseo del sistema

El diseo del sistema (Figura 2.4) se centra en proporcionar la funcionalidad del sistema a travs de sus
diferentes componentes. Las actividades que se realizan en este proceso son:
1. Dividir requerimientos. Analice los requerimientos y organcelos en grupos afines.
Normalmente existen varias opciones posibles de divisin, y puede sugerir varias alternativas en esta
etapa del proceso.
2. Identificar subsistemas. Debe identificar los diferentes subsistemas que pueden, individual o
colectivamente, cumplir los requerimientos. Los grupos de requerimientos estn normalmente
relacionados con los subsistemas, de tal forma que esta actividad y la de divisin de requerimientos se
pueden fusionar. Sin embargo, la identificacin de subsistemas se puede ver influenciada por otros
factores organizacionales y del entorno.
3. Asignar requerimientos a los subsistemas. Asigne los requerimientos a los subsistemas. En
principio, esto debe ser sencillo si la divisin de requerimientos se utiliza para la identificacin de
subsistemas. En la prctica, no existe igualdad entre las divisiones de requerimientos y la
identificacin de subsistemas. Las limitaciones de los subsistemas comerciales pueden significar que
tenga que cambiar los requerimientos para acomodarlos a estas restricciones.
4. Especificar la funcionalidad de los subsistemas. Debe enumerar las funciones especficas asignadas
a cada subsistema. Esto puede verse como parte de la fase de diseo del sistema o, si el subsistema es
un sistema de software, como parte de la actividad de especificacin de requerimientos para ese
sistema. Tambin debe intentar especificar las relaciones entre los subsistemas en esta etapa.
5. Definir las interfaces del subsistema. Defina las interfaces necesarias y requeridas por cada
subsistema. Una vez que estas interfaces se han acordado, es posible desarrollar estos subsistemas en
paralelo.

2.4.

Modelado de sistema

Durante la actividad de requerimientos y diseo del sistema, stos pueden ser modelados como un
conjunto de componentes y de relaciones entre estos componentes. Esto se puede ilustrar grficamente en
un modelo arquitectnico del sistema, el cual proporciona al lector una visin general de la organizacin
del sistema. La arquitectura del sistema puede ser presentada como un diagrama de bloques que muestra
los principales subsistemas y la interconexin entre ellos. Al dibujar un diagrama de bloque, debe
representar cada subsistema mediante un rectngulo, y debe mostrar las relaciones entre los subsistemas
usando flechas que unan estos rectngulos. Las relaciones pueden ser flujo de datos, utiliza / utilizado
por o algn otro tipo de relacin dependiente. Por ejemplo, la descomposicin de un sistema de alarma
contra intrusos en sus componentes principales. El diagrama de bloques debe complementarse con una
breve descripcin de cada subsistema. En este nivel de detalle, el sistema se descompone en un conjunto
de subsistemas que interactan. Cada uno de stos debe ser representado de forma similar hasta que el
sistema est dividido en componentes funcionales. stos son componentes que, cuando se ven desde la
perspectiva del subsistema, proporcionan una funcin nica. En contraste, un sistema comnmente es
multifuncional. Por supuesto, cuando se ve desde otra perspectiva (por ejemplo, desde los componentes
del fabricante), un componente funcional es un sistema. Histricamente, el modelo de arquitectura de
sistemas fue utilizado para identificar componentes de hardware y software que podan desarrollarse en
paralelo. Sin embargo, esta distincin hardware/software se ha hecho irrelevante. En la actualidad, la
mayora de los componentes incluyen algunas capacidades de cmputo. Por ejemplo, las mquinas para
enlazar redes consisten en cables fsicos, repetidores y gateways. stos incluyen procesadores y software
para manejar estos procesadores, as como componentes electrnicos especializados. En el nivel de la
arquitectura, es ms apropiado clasificar los subsistemas de acuerdo con su funcin antes de tomar
decisiones sobre el tipo de hardware/software. La decisin de proporcionar una funcin mediante
hardware o software depende de factores no tcnicos, como la disponibilidad de componentes comerciales

o el tiempo disponible para desarrollar el componente. Los diagramas de bloques se pueden utilizar para
sistemas de cualquier tamao. La muestra la arquitectura de un sistema de mayor tamao para el control
del trfico areo. Varios subsistemas principales mostrados son a su vez sistemas grandes. Las flechas que
conectan estos sistemas muestran el flujo de informacin entre estos subsistemas.

2.5.

Integracin del sistema

Durante el proceso de integracin del sistema, se toman los subsistemas desarrollados de forma
independiente y se conjuntan para crear el sistema completo. La integracin se puede hacer utilizando el
enfoque del big bang, que consiste en integrar todos los subsistemas al mismo tiempo. Sin embargo, a
efectos tcnicos y de administracin, el mejor enfoque es un proceso de integracin creciente donde los
sistemas se integran uno a uno, por dos razones:
1. Por lo general, es imposible confeccionar una agenda para el desarrollo de todos los subsistemas
de tal forma que todos terminen al mismo tiempo.
2. La integracin creciente reduce el costo en la localizacin de errores. Si varios subsistemas se
integran simultneamente, un error que surja durante las pruebas puede estar en cualquiera de
estos subsistemas. Cuando un nico subsistema se integra en un sistema en funcionamiento, los
errores que se produzcan estarn probablemente en el subsistema recin integrado o en las
interacciones entre los subsistemas existentes y el nuevo sistema.
Una vez que los componentes han sido integrados, tiene lugar un extenso programa de pruebas del
sistema. Estas pruebas pretenden probar las interfaces entre los componentes y el comportamiento del
sistema en su totalidad.
Los defectos de los subsistemas que son consecuencia de suposiciones invlidas en los otros subsistemas,
a menudo aparecen durante la integracin del sistema. Esto puede conducir a problemas entre los
diferentes contratistas responsables de los diferentes subsistemas.
Cuando se descubren problemas en la interaccin de subsistemas, los diferentes contratistas pueden
discutir sobre qu subsistema es el defectuoso. Las negociaciones de cmo solucionar el problema pueden
llevar semanas o meses.
Como cada vez ms los sistemas son construidos por la integracin de componentes hardware y software
COTS, la integracin de sistemas est adquiriendo una importancia creciente. En algunos casos, no hay
separacin en el desarrollo de subsistemas y la integracin es,
esencialmente, la fase de implementacin del sistema.

2.6.

Evolucin del sistema

Los sistemas grandes y complejos tienen un periodo de vida largo. Durante su vida, se cambian para
corregir errores en los requerimientos del sistema original y para implementar nuevos requerimientos que
surgen. Los sistemas de cmputo se reemplazan por nuevas mquinas ms rpidas. La organizacin que
utiliza el sistema puede reorganizarse y utilizar el sistema de forma diferente. El entorno externo del
sistema puede cambiar, forzando cambios en el sistema. La evolucin del sistema, como la del software,
es inherentemente costosa, por varias razones:
1. Los cambios propuestos tienen que analizarse cuidadosamente desde perspectivas tcnicas y de
negocios. Los cambios tienen que contribuir a los objetivos del sistema y no deben tener
simplemente una motivacin tcnica.
2. Debido a que los subsistemas nunca son completamente independientes, los cambios en uno
pueden afectar de forma adversa al funcionamiento o comportamiento de otros.
3. Por lo tanto, ser necesario cambiar estos subsistemas.
4. A menudo no se registran las razones del diseo original. Los responsables de la evolucin del
sistema tienen que resolver por qu se tomaron decisiones particulares de diseo.
5. Al paso del tiempo, su estructura se corrompe por el cambio de tal forma que se incrementan los
costos de cambios adicionales.

Referencias
Aparicio, I. A. (Abril 2004). INGENIERIA DE SOFTWARE. Obtenido de
http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEn
Linea.
Sommerville, I. ( 2005 ). INGENIERA DEL SOFTWARE. Sptima edicin.
Madrid.: PEARSON EDUCACIN, S.A.