INSTITUTO TECNOLOGICO

SUPERIOR DE ALVARADO
Campus Medelln

INGENIERA
SISTEMAS COMPUTACIONALES
Materia:
Fundamentos de Ingenieria de Software.
Semestre - Grupo - Sistema:
5 Semestre - ISC Escolarizado.
Producto Acadmico:
Caracteristicas del software y mitos del software

Alumno:
Hector Antonio Martinez Martinez

Docente:
ISC.Fernando Mayorga Guittins

MEDELLIN DE BRAVO, VER. AGOSTO. DICIEMBRE. 2015

ndice
ndice.................................................................................................................. 2
Introduccin........................................................................................................ 3
Propsito............................................................................................................. 4
1.2.1. Caractersticas del software......................................................................5
1.4 Mitos del Software......................................................................................... 7
Conclusin........................................................................................................ 11
FUENTES........................................................................................................... 12

Introduccin
Hoy en da el software tiene un doble papel. Es un producto, pero
simultneamente es el vehculo para hacer entrega de un producto. Como
producto permite el uso del hardware, ya sea, por ejemplo, un ordenador
personal, un telfono mvil. Como vehculo utilizado para hacer entrega del
producto, acta como base de control, por ejemplo un sistema operativo, o un
sistema gestor de redes. El software hace entrega de lo que se considera como
el producto ms importante del siglo veintiuno, LA INFORMACION.

El software transforma datos personales para que sean ms tiles en un

entorno local, gestiona informacin comercial para mejorar la competitividad,
proporciona el acceso a redes a nivel mundial, y ofrece el medio de adquirir
informacin en todas sus formas.
A continuacin se presenta una definicin de software y sus caractersticas.

Propsito
El presente trabajo pretende ensear

sobre los mitos

del software que

anteriormente se crean , adems que se tratara sobre las caractersticas del

mismo.

1.2.1. Caractersticas del software

Para poder comprender lo que es el software (y consecuentemente la
ingeniera del software), es importante examinar las caractersticas del
software que lo diferencian de otras cosas que los hombres pueden construir.
Cuando se construye hardware, el proceso creativo humano (anlisis, diseo,
construccin,

prueba)

se

traduce

finalmente

en

una

forma

fsica.

Si

construimos una nueva computadora, nuestro boceto inicial, diagramas

formales de diseo y prototipo de prueba, evolucionan hacia un producto fsico
(chips, tarjetas de circuitos impresos, fuentes de potencia, etc.).
El software es un elemento del sistema que es lgico, en lugar de fsico. Por
tanto el software tiene unas caractersticas considerablemente distintas a las
del hardware:
1. El software se desarrolla
Aunque existen similitudes entre el desarrollo del software y la construccin
del hardware, ambas actividades son fundamentalmente diferentes. En ambas
actividades la buena calidad se adquiere mediante un buen diseo, pero la fase
de construccin del hardware puede introducir problemas de calidad que no
existen (o son fcilmente corregibles) en el software.
Ambas actividades dependen de las personas, pero la relacin entre las
personas dedicadas y el trabajo realizado es completamente diferente para el
software (vase el Captulo 7). Ambas actividades requieren la construccin de
un producto pero los enfoques son diferentes.
Los costes del software se encuentran en la ingeniera.
Esto significa que los proyectos de software no se pueden gestionar como si
fueran proyectos de fabricacin.
2. El software no se estropea.
La Figura 1.1 describe, para el hardware, la proporcin de fallos como una
funcin del tiempo. Esa relacin, denominada frecuentemente curva de
baera, indica que el hardware exhibe relativamente muchos fallos al
principio de su vida (estos fallos son atribuibles normalmente a defectos del

diseo o de la fabricacin); una vez corregidos los defectos, la tasa de fallos

cae hasta un nivel estacionario (bastante bajo, con un poco de optimismo)
donde permanece durante un cierto periodo de tiempo. Sin embargo, conforme
pasa el tiempo, el hardware empieza a desgastarse y la tasa de fallos se
incrementa.
El software no es susceptible a los males del entorno que hacen que el
hardware se estropee. Por tanto, en teora, la curva de fallos para el software
tendra la forma que muestra la Figura 1.2. Los defectos no detectados harn
que falle el programa durante las primeras etapas de su vida. Sin embargo,
una vez que se corrigen (suponiendo que no se introducen nuevos errores) la
curva se aplana, como se muestra. La curva idealizada es una gran
simplificacin de los modelos reales de fallos del software (vase ms
informacin en el Captulo 8). Sin embargo la implicacin es clara, el software
no se estropea. Pero se deteriora!
Esto que parece una contradiccin, puede comprenderse mejor considerando
la curva actual mostrada en la Figura 1.2. Durante su vida, el software sufre
cambios (mantenimiento). Conforme se hacen los cambios, es bastante
probable que se introduzcan nuevos defectos, haciendo que la curva de fallos
tenga picos como se ve en la Figura 1.2. Antes de que la curva pueda volver al
estado estacionario original, se solicita otro cambio, haciendo que de nuevo se
cree otro pico. Lentamente, el nivel mnimo de fallos comienza a crecer -e1
software se va deteriorando debido a los cambios-.
Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el
software. Cuando un componente de hardware se estropea se sustituye por
una pieza de repuesto.
No hay piezas de repuesto para el software. Cada fallo en el software indica un
error en el diseo o en el proceso mediante el que se tradujo el diseo a cdigo
mquina ejecutable. Por tanto, el mantenimiento del software tiene una
complejidad considerablemente mayor que la del mantenimiento del hardware.
3. Aunque la industria tiende a ensamblar componentes, la mayora del
software se construye a medida.

Consideremos la forma en la que se disea y se construye el hardware de

control para un producto basado en computadora. El ingeniero de diseo
construye un sencillo esquema de la circuitera digital, hace algn anlisis
fundamental para asegurar que se consigue la funcin adecuada y va al
armario donde se encuentran los catlogos de componentes digitales.
Despus de seleccionar cada componente, puede solicitarse la compra.
A medida que la disciplina del software evoluciona, se crea un grupo de
componentes de diseo estndar. Tornillos estndar y circuitos integrados
preparados para la venta son solamente los dos mil componentes estndar que
utilizan ingenieros mecnicos y elctricos cuando disean nuevos sistemas. Los
componentes reutilizables se han creado para que el ingeniero pueda
concentrarse en elementos verdaderamente innovadores de un diseo, por
ejemplo, las partes del diseo que representan algo nuevo. En el mundo del
hardware, la reutilizacin de componentes es una parte natural del proceso de
ingeniera.
En el mundo del software es algo que slo ha comenzado a lograrse en una
escala amplia.
El componente de software debera disearse e implementarse para que pueda
volver a ser reutilizado en muchos programas diferentes. En los aos 60, se
construyeron bibliotecas de subrutinas cientficas reutilizables en una amplia
serie de aplicaciones cientficas y de ingeniera. Esas bibliotecas de subrutinas
reutilizaban de forma efectiva algoritmos bien definidos, pero tenan un
dominio de aplicacin limitado.
Hoy en da, hemos extendido nuestra visin de reutilizacin para abarcar no
slo los algoritmos, sino tambin estructuras de datos. Los componentes
reutilizables modernos encapsulan tanto datos como procesos que se aplican a
los datos, permitiendo al ingeniero del software crear nuevas aplicaciones a
partir de las partes reutilizables. Por ejemplo, las interfaces grficas de usuario
de hoy en da se construyen frecuentemente a partir de componentes
reutilizables que permiten la creacin de ventanas grficas, de mens
desplegables y de una amplia variedad de mecanismos de interaccin.

1.4 Mitos del Software

Muchas de las causas de la crisis del software se pueden encontrar en una
mitologa que surge durante los primeros aos del desarrollo del software. A
diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres
lecciones dignas de tener en cuenta, los mitos del software propagaron
informacin errnea y confusin. Los mitos del software tienen varios atributos
que los hacen insidiosos: por ejemplo, aparecieron como declaraciones
razonables de hechos (algunas veces conteniendo elementos verdaderos),
tuvieron un sentido intuitivo y frecuentemente fueron promulgados por
expertos que estaban al da.
Esta terminologa fue sugerida por el profesor Daniel Tiechrow de la
Universidad de Michigan en una conferencia impartida en Ginebra, Suiza, Abril,
1989.
Mitos de gestin. Los gestores con responsabilidad sobre el software, como los
gestores en la mayora de las disciplinas, estn normalmente bajo la presin de
cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la
calidad. Igual que se agarra al vaco una persona que se ahoga, un gestor de
software se agarra frecuentemente a un mito del software, aunque tal creencia
slo disminuya la presin temporalmente.
Mito. Tenemos ya un libro que est lleno de estndares y procedimientos para
construir software, no le proporciona ya a mi gente todo lo que necesita
saber?
Realidad. Est muy bien que el libro exista, pero se usa?. Conocen los
trabajadores su existencia?, refleja las prcticas modernas de desarrollo de
software?, es completo?, est diseado para mejorar el tiempo de entrega
mientras mantiene un enfoque de calidad? En muchos casos, la respuesta a
todas estas preguntas es no.
Mito. Mi gente dispone de las herramientas de desarrollo de software ms
avanzadas, despus de todo, les compramos las computadoras ms modernas.

Realidad. Se necesita mucho ms que el ltimo modelo de computadora

grande o de PC para hacer desarrollo de software de gran calidad. Las
herramientas de ingeniera del software asistida por computadora (CASE) son
ms

importantes

que

el

hardware

para

conseguir

buena

calidad

productividad, aunque la mayora de los desarrolladores del software todava

no las utilicen eficazmente.
Mito. Si fallamos en la planificacin, podemos aadir ms programadores y
adelantar el tiempo perdido (el llamado algunas veces concepto de la horda
Mongoliana).
Realidad. El desarrollo de software no es un proceso mecnico como la
fabricacin. En palabras de Brooks [BR075]: ...aadir gente a un proyecto de
software retrasado lo retrasa an ms. Al principio, esta declaracin puede
parecer un contrasentido. Sin embargo, cuando se aaden nuevas personas, la
necesidad de aprender y comunicarse con el equipo puede y hace que se
reduzca la cantidad de tiempo gastado en el desarrollo productivo.
Puede aadirse gente, pero slo de una manera planificada y bien coordinada.
Mitos del Cliente. Un cliente que solicita una aplicacin de software puede ser
una persona del despacho de al lado, un grupo tcnico de la sala de abajo, el
departamento de ventas o una compaa exterior que solicita un software bajo
contrato. En muchos casos, el cliente cree en los mitos que existen sobre el
software, debido a que los gestores y desarrolladores del software hacen muy
poco para corregir la mala informacin. Los mitos conducen a que el cliente se
cree una falsa expectativa y, finalmente, quede insatisfecho con el que
desarrolla el software.
Mito. Una declaracin general de los objetivos es suficiente para comenzar a
escribir los programas podemos dar los detalles ms adelante-.
Realidad. Una mala definicin inicial es la principal causa del trabajo baldo en
software. Es esencial una descripcin formal y detallada del mbito de la
informacin, funciones, comportamiento, rendimiento, interfaces, ligaduras del
diseo y criterios de validacin. Estas caractersticas pueden determinarse slo
despus de una exhaustiva comunicacin entre el cliente y el analista.

Mito. Los requisitos del proyecto cambian continuamente, pero los cambios
pueden acomodarse fcilmente, ya que el software es flexible.
Es verdad que los requisitos del software cambian, pero el impacto del cambio
vara segn el momento en que se introduzca. La Figura 1.3 ilustra el impacto
de los cambios. Si se pone cuidado al dar la definicin inicial, los cambios
solicitados al principio pueden acomodarse fcilmente. El cliente puede revisar
los requisitos y recomendar las modificaciones con relativamente poco impacto
en el coste. Cuando los cambios se solicitan durante el diseo del software, el
impacto en el coste crece rpidamente. Ya se han acordado los recursos a
utilizar y se ha establecido un marco de trabajo del diseo. Los cambios
pueden producir trastornos que requieran recursos adicionales e importantes
modificaciones del diseo; es decir, coste adicional. Los cambios en la funcin,
rendimiento, interfaces u otras caractersticas, durante la implementacin
(codificacin y prueba) pueden tener un impacto importante sobre el coste.
Cuando se solicitan al final de un proyecto, los cambios pueden producir un
orden de magnitud ms caro que el mismo cambio pedido al principio.
Mitos de los desarrolladores. Los mitos en los que an creen muchos
desarrolladores se han ido fomentando durante 50 aos de cultura informtica.
Durante los primeros das del desarrollo del software, la programacin se vea
como un arte. Las viejas formas y actitudes tardan en morir.
Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro
trabajo ha terminado.
Realidad. Alguien dijo una vez: cuanto ms pronto se comience a escribir
cdigo, ms se tardar en terminarlo. Los datos industriales [LIE80, JON91,
PUT971 indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado
a un programa se realizar despus de que se le haya entregado al cliente por
primera vez.
Mito. Hasta que no tengo el programa ejecutndose, realmente no tengo
forma de comprobar su calidad.

Realidad. Desde el principio del proyecto se puede aplicar uno de los

mecanismos ms efectivos para garantizar la calidad del software: la revisin
tcnica formal.
La revisin del software (descrito en el Captulo 8) es un filtro de calidad que
se ha comprobado que es ms efectivo que la prueba, para encontrar ciertas
clases de defectos en el software.
Mito. Lo nico que se entrega al terminar el proyecto es el programa
funcionando.
Realidad. Un programa que funciona es slo una parte de una configuracin del
software que incluye muchos elementos. La documentacin proporciona el
fundamento para un buen desarrollo y, lo que es ms importante, proporciona
guas para la tarea de mantenimiento del software.
Muchos profesionales del software reconocen la falacia de los mitos descritos
anteriormente.

Lamentablemente,

las

actitudes

mtodos

habituales

fomentan una pobre gestin y malas prcticas tcnicas, incluso cuando la

realidad dicta un mtodo mejor. El reconocimiento de las realidades del
software es el primer paso hacia la formulacin de soluciones prcticas para su
desarrollo.

Conclusin
El software se ha convertido en el elemento clave de la evolucin de los
sistemas y productos informticos. En los pasados 50 aos, el software ha
pasado de ser una resolucin de problemas especializada y una herramienta de
anlisis de informacin, a ser una industria por s misma. Pero la temprana
cultura e historia de la programacin ha creado un conjunto de problemas
que persisten todava hoy. El software se ha convertido en un factor que limita
la evolucin de los sistemas informticos. El software se compone de
programas, datos y documentos. Cada uno de estos elementos compone una
configuracin que se crea como parte del proceso de la ingeniera del software.
El intento de la ingeniera del software es proporcionar un marco de trabajo
para construir software con mayor calidad.

FUENTES
PDF Ingeniera de software- pressman 5 th- 23/08/15.