Desarrollo del Software visto

como Ingeniera
Ayachi Mlaga Jhon Lee

Chanduvi Antonio Arnaldo Jairo

Oliveros Choque Andry German

Chvez Vasquez Jorge Maxwell | Ing. Del Software | 13 de junio de 2017

 EL DESARROLLO DE SOFTWARE VISTO COMO INGENIERIA DE
SOFTWARE

1. INTRODUCCIN

Cuando se entrevista a candidatos para puestos de trabajo en programacin, una de las

preguntas favoritas es: "Cmo describira su enfoque del desarrollo de software?". Algunos
candidatos usualmente dicen que se ven a s mismos como cientficos. Los programadores
con amplia experiencia dicen que se ven como soldados o como miembros de un equipo SWAT,
pero existe una respuesta bastante certera que dice lo siguiente: "Durante el diseo del
software, soy un arquitecto; cuando estoy diseando la interfaz de usuario, soy un artista;
durante la construccin, soy un artesano; y durante las pruebas unitarias soy, como mnimo, un
hijo de puta!".

Deberamos plantearnos las siguientes preguntas porque constituyen una cuestin fundamental
en nuestro campo de investigacin: Cul es la mejor manera de pensar acerca del desarrollo
de software? Es ciencia? Es arte? Es un oficio? Es algo completamente distinto? Preguntas
a las que trato de responder en el resto del contenido de este trabajo.

2. ES vs. DEBERA

En las Ciencias Computacionales tenemos una larga tradicin debatiendo acerca de si el

desarrollo de software es arte o ciencia. Hace ms de cuarenta aos, Donald Knuth comenz a
escribir una serie de siete volmenes acerca de esta cuestin. Los primeros tres volmenes
contienen alrededor de 2200 pginas, lo que sugiere que el total de los siete podra ascender a
ms de 5000. Si eso es a lo que se parece el arte del desarrollo de software, no estoy seguro
de querer saber a qu se parecer como ciencia!

Las personas que defienden al desarrollo de software como arte lo hacen desde el punto de
vista de sus aspectos estticos y argumentan que la ciencia no permite esta inspiracin y libertad
creativa. Las personas que lo defienden como ciencia lo hacen desde el punto de vista de que
la mayora de los programas tiene altas tasas de error y argumentan que esa baja confiabilidad
es una libertad creativa intolerable que debe ser condenada. Ambos puntos de vista son
incompletos y ambos hacen la pregunta equivocada. El desarrollo de software es arte, es ciencia,
o es un oficio como la arqueologa, el derecho, la sicologa, la sociologa, la comunicacin social
y otras actividades. Es no-profesional en algunos sectores y profesional en otros. Tiene que ver
con muchas y diferentes cosas, ya que existen muchas personas diferentes desarrollando. Pero
la pregunta correcta no es "Qu es actualmente el desarrollo de software?" sino "Qu debera
ser el desarrollo profesional de software? En mi opinin, la respuesta a esa pregunta es clara:
El desarrollo profesional de software debera ser ingeniera. Actualmente es as? No, pero
debera serlo? Sin lugar a dudas que S.
 3. INGENIERA vs. CIENCIA

Con slo un 40% de los desarrolladores de software con ttulos en Ciencias Computacionales y
prcticamente ninguno en Ingeniera de Software, no debera sorprendernos encontrar
personas confundidas acerca de la diferencia entre Ingeniera de Software y Ciencias
Computacionales. La distincin entre estos campos es la misma que en otros campos. Los
cientficos aprenden lo que es verdadero, cmo probar hiptesis y cmo ampliar el
conocimiento en su campo; los Ingenieros aprenden lo que es verdadero, lo que es til y cmo
aplicar el conocimiento bien comprendido para resolver problemas prcticos. Los cientficos
deben estar actualizados con las ltimas investigaciones; los ingenieros deben estar
familiarizados con el conocimiento que ha demostrado ser fiable y eficaz.

Cuando el cientfico hace ciencia puede darse el lujo de ser especfico y especializado; cuando
se hace ingeniera es necesario tener un amplio conocimiento de todos los factores que afectan
al producto que se disea. Los cientficos no tienen que ser regulados, porque ellos deben
rendirles cuentas a otros cientficos; los ingenieros tienen que ser regulados, porque ellos tienen
que rendirles cuentas a la sociedad. Una formacin cientfica de pregrado prepara a los
estudiantes para continuar sus estudios; una formacin en ingeniera de pregrado prepara a los
estudiantes para su inmediata incorporacin al mercado laboral, despus de terminar sus
estudios.

Las universidades otorgan ttulos en Ciencias Computacionales y normalmente esperan que sus
egresados se desempeen en puestos de trabajo en desarrollo de software, en el que iniciarn
de inmediato la resolucin de problemas del mundo real. Slo una pequea fraccin de los
estudiantes en Ciencias Computacionales contina sus estudios de postgrado, en entornos de
investigacin acerca de los nuevos avances en el estado del conocimiento en el campo del
software y/o los computadores. Esto pone a los estudiantes de Ciencias Computacionales en
una tierra tecnolgica de nadie. Son llamados cientficos, pero en su trabajo realizan funciones
que tradicionalmente las ejecutan los ingenieros, pero sin el beneficio de una formacin en
ingeniera. El efecto sera ms o menos el mismo que si se le asignara a un Ph.D. en fsica el
diseo de equipos elctricos para venta comercial. El fsico puede comprender mejor los
principios elctricos que los ingenieros con los que est trabajando, pero su experiencia en
construccin de equipos se reduce a la creacin de prototipos que se utilizan para progresar en
el estado del conocimiento en un laboratorio. l no tiene experiencia ni est capacitado en el
diseo de los equipos robustos y econmicos que ofrecen soluciones prcticas en entornos
reales. Es de esperar que el equipo diseado por el Ph.D. funcione, pero tal vez carezca de la
solidez que haga posible su utilizacin por fuera del ambiente seguro de un laboratorio; o el
equipo puede usar materiales que son aceptables para un prototipo, pero que son un
extravagante derroche cuando las unidades se fabrican por miles.

Situaciones parecidas a este simple ejemplo de fsica se producen por montones en lo que tiene
que ver con el software. Cuando los empleados, formados como cientficos computacionales,
comienzan a trabajar en sistemas de produccin, a menudo disean y construyen software que
es demasiado frgil para usar en produccin, o que es inseguro. Se concentran estrecha y
profundamente en consideraciones de menor importancia y excluyen otros factores que son
ms importantes. Pueden invertir das ajustando a mano un algoritmo de ordenacin en lugar
de horas usando una librera de cdigo o copiando un algoritmo adecuado de un libro. El tpico
graduado de Ciencias Computacionales suele necesitar varios aos de entrenamiento en el
puesto de trabajo para acumular suficiente conocimiento prctico para, mnimamente,
desarrollar software de produccin satisfactorio.

La falta de un desarrollo profesional no es culpa slo de los desarrolladores de software. El

mundo del software se ha convertido en vctima de su propio xito. El mercado laboral del
software ha estado creciendo ms rpido que la infraestructura formativa necesaria para
apoyarlo, por lo que ms de la mitad de las personas que ocupan puestos en desarrollo de
software han sido formados en otros campos relacionados. Los empleadores no les pueden
exigir a estas personas que, en sus horas libres, obtengan un ttulo equivalente a un pregrado
en ingeniera. Incluso si pudieran, la mayor parte de los cursos disponibles son para Ciencias
Computacionales, no para Ingeniera de Software. La infraestructura formativa se ha quedado a
la zaga de las necesidades de la industria.

4. MS QUE UNA MODA

Algunas personas piensan que "Ingeniera de Software" es slo una palabra de moda que
significa lo mismo que "programacin de computadores". Es cierto que la Ingeniera de Software
ha sido usurpada, pero un trmino puede ser objeto de abuso y todava tener un significado
legtimo. La definicin del diccionario para "Ingeniera" es: Aplicacin de principios cientficos
y matemticos con fines prcticos, y es lo que la mayora de los programadores tratan de hacer.

Los ingenieros de software aplicamos algoritmos desarrollados cientficamente y definidos

matemticamente, mtodos de diseo funcional, mtodos de aseguramiento de calidad y otras
prcticas para desarrollar productos software y servicios.

Como David Parnas seala, en otros campos tcnicos de la profesin ingenieril se inventaron y
asignaron personeras jurdicas y certificaciones para que sus clientes conocieran que estaban
calificados para construir productos tcnicos. Los clientes del software no se merecen menos.

Algunas personas piensan que tratar como ingeniera al desarrollo de software significa que
todos tendremos que usar mtodos formales para escribir programas como pruebas
matemticas. El sentido y la experiencia comn nos dice que eso es demasiado para muchos
proyectos. Otros objetan que el software comercial es demasiado dependiente de las
cambiantes condiciones del mercado como para darse el lujo de invertir tiempo en ingeniera.
Estas objeciones se basan en una idea estrecha y errnea acerca de la ingeniera. La ingeniera
es la aplicacin de principios cientficos con fines prcticos y, si no se hace as, es mala ingeniera.
Tratar de aplicar mtodos formales a todos los proyectos de software es tan mala idea como
tratar de aplicar code-and-fix para desarrollar todos los proyectos.

Tratar al desarrollo de software como ingeniera clarifica la idea de que para diferentes
proyectos son apropiados diferentes objetivos de desarrollo. Cuando se disea un edificio, los
materiales de construccin deben ser adecuados para el propsito de la construccin. Es posible
construir una bodega amplia para guardar vehculos agrcolas con un metal delgado y sin hoja
de aislamiento, pero una casa no se construira de la misma manera; pero, a pesar de que la casa
sea resistente y clida, de ninguna manera nos referimos a la bodega como de inferior calidad
que la casa. La bodega se dise adecuadamente para un fin previsto y, si hubiera sido
construida de la misma manera que la casa, incluso podra criticarse por tener "ms ingeniera
de la necesaria" un juicio segn el cual los diseadores despilfarran recursos en las
construcciones y que por lo tanto no aplican la ingeniera necesaria.

En software, un proyecto bien ejecutado se gestiona para que cumpla alguno de los siguientes
objetivos del producto:

Defectos mnimos
Mxima satisfaccin de usuarios
Tiempo de respuesta mnimo
Buena mantenibilidad
Buena extensibilidad
Robustez
Alta correctitud

Cada equipo del proyecto software debe definir explcitamente la importancia relativa de cada
caracterstica; luego, el equipo completo, debe conducir el proyecto de forma que logre sus
objetivos.

Los proyectos software son diferentes de los proyectos de ingeniera que utilizan materiales
fsicos. En otro tipo de ingeniera, el costo de los materiales puede llegar al 50% o ms del costo
total del proyecto.

Algunas empresas de ingeniera reportan que consideran automticamente como de alto riego
a los proyectos cuya mano de obra constituye ms del 50% de su costo. En un proyecto
tpico de software, los costos de mano de obra pueden llegar casi al 100% del costo total.
La mayora de proyectos de ingeniera se centran en optimizar los objetivos del producto
y los costos de diseo son relativamente insignificantes.

Debido a que los costos de mano de obra constituyen gran parte del total de los costos del ciclo
de vida del software, los proyectos software necesitan enfocarse ms en optimizar los objetivos
del proyecto que lo que hacen otros tipos de ingenieras. Por lo tanto, adems de trabajar en
pro de los objetivos del producto, un equipo de software tambin debe trabajar para lograr
alguno de los siguientes objetivos del proyecto:

Calendario cort
Fecha de entrega predecible
Bajo costo
Equipo pequeo
Flexibilidad para ejecutar los proyectos aunque los requisitos cambien

Cada proyecto software debe encontrar un equilibrio entre los diferentes objetivos del proyecto
y los del producto. No queremos pagar US$5000 por un procesador de texto, ni queremos que
se bloquee cada 15 minutos.

En cules de estas caractersticas especficas del producto y del proyecto hace hincapi un
equipo de trabajo para determinar si un proyecto es o no verdadera "Ingeniera de Software"?
Algunos proyectos necesitan producir software con defectos mnimos y correctitud casi
perfecta, software para equipos mdicos, aviacin, viajes espaciales y as sucesivamente.
Muchas personas estaran de acuerdo en que estos proyectos son un dominio apropiado para
la Ingeniera de Software a gran escala. Otros proyectos necesitan entregar su software con una
fiabilidad adecuada, pero con bajos costos y calendarios cortos. Pertenecen estos proyectos al
dominio de la Ingeniera de Software? Una definicin informal de ingeniera es "hacer con un
centavo lo que cualquier persona puede hacer con un dlar. Muchos de los actuales
programadores de software estn haciendo con un dlar lo que cualquier buen ingeniero de
software puede hacer con un centavo. El desarrollo econmico tambin es dominio de la
Ingeniera de Software.

La actual dependencia generalizada del desarrollo code-and-fix y el exceso en costos y

calendario que implica, no es el resultado de una estimacin de la Ingeniera de Software, sino
de poca formacin y entrenamiento en las prcticas de la Ingeniera de Software.

5. IMPACTO DEL MAL SOFTWARE EN LA SOCIEDAD

Qu en un mal software?

Un mal software no es aquel que no cumple con los objetivos, sino aquel que su funcionalidad
depende de una serie de licencias, llaves, actualizaciones, y paquetes complementarios que solo
funcionan con ms licencias. El objetivo del uso de software es optimizar y trabajar ms rpido
(y en el fondo para trabajar menos), entonces eso supone la utilizacin de herramientas
informticas que sean verstiles para todos los usuarios en la mayora de computadoras.

Por qu es tan malo el software actual?

Como el software se vuelve cada vez ms importante, el potencial impacto del cdigo malo
aumentar a la altura, en opinin de Peter G. Neumann, un cientfico informtico miembro del
SRI International, centro privado de I + D en Menlo Park, CA. En los ltimos 15 aos, defectos de
software han destruido proyectos como el lanzamiento europeo de un satlite, han retrasado
un ao la apertura del aeropuerto de Denver, han destruido una misin de la NASA a Marte, ha
matado a 4 marines en un accidente de helicptero, ha provocado que un barco de la US Navy
destruyese un vuelo civil y ha desactivado los sistemas de ambulancias en Londres, provocando
ms de 30 muertes. Y debido a nuestra creciente dependencia de la Red, Neumann dice,
"Estamos mucho peor de lo que lo estbamos hace cinco aos. Los riesgos son peores y las
defensas no son tan buenas. Estamos yendo hacia atrs y eso es motivo de preocupacin. "

Pero a medida que los ordenadores se extendan, las actitudes iban cambiando. En lugar de una
planificacin meticulosa de su cdigo, los programadores se pasaban las noches en sesiones de
hacking cargadas de cafena. Cada vez que el compilador devolva mensajes de error, los
programadores deban corregir los errores uno por uno hasta que el software compilara
correctamente. La actitud actual es que t puedes escribir cualquier chapuza de pieza de cdigo
y el compilador te lo resolver, deca SRIs Neumann. Si no devolviera un mensaje de error, las
cosas se haran de un modo ms correcto, verdad?.

Los programas iban creciendo en tamao y complejidad, sin embargo, los lmites entre cdigo y
correccin se iban aproximando. De media, los programadores profesionales cometen entre 100
y 150 errores en todos los miles de lneas de cdigo que escriben, segn un estudio realizado a
13.000 programadores por Humphrey, del Carnegie Mellon University. Por ejemplo, el Sistema
Operativo Windows NT 4, con sus 16 millones de lneas de cdigo, se escribi con alrededor de
2 millones de fallos. La mayora seguramente fueran pequeos y no causaron ningn efecto,
pero algunos (unos cuantos miles) pudieron haber causado serios problemas. Naturalmente,
Microsoft examin exhaustivamente Windows NT 4 antes de su lanzamiento, pero en casi
cualquier fase de pruebas solo vas a encontrar menos de la mitad de los defectos deca
Humphrey. Si Microsoft ha realizado alrededor de 4 rondas de pruebas, un procedimiento caro
y muy costoso en cuanto a tiempo se refiere, la empresa debe haber encontrado al menos 15
bugs de 16. Esto te es permitido con algo as como 5 defectos por cada mil lneas de cdigo
dice Humphrey. Lo cual es muy bajo. Pero el software puede seguir teniendo algo as como
80.000 errores.

6. EL NEGOCIO OCULTO DE HACER SOFTWARE MALO

Veamos las enormes ventajas competitivas y econmicas de hacerlo mal:

1. Ahorro de costes en personal.

Frente a una empresa profesional que tiene un correcto proceso de desarrollo software, si haces
software malo, con un proceso malo, lo lgico es que tengas gente poco cualificada, poco
experta o con poco conocimiento, lo que es ostensiblemente ms econmico.

Te ahorrars en formacin, en que te pidan aumentos de sueldo, bajas la rotacin de la empresa,

etc.

No es todo tan fcil, porque normalmente los que hacen mal software se caracterizan por
intentar suplir sus carencias metiendo mucha gente. Pero eso suele aparecer cuando ya las cosas
van muy mal, al principio esto con 4 becarios sale.

2. Fidelizacin de clientes.

Hacer software rematadamente malo genera que pocos, ms all de quienes lo programaron (y
a veces ni eso), sean capaces de mantenerlo, tocarlo, evolucionarlo, etc. Es por ello que muchos
clientes que compraron un desarrollo software mal hecho ya no pueden prescindir del
proveedor Slo l puede mantener tal monstruo y ah se queda por aos.

3. Aumento de las tarifas.

Creme, no cuento nada que no haya visto yo, y varias veces. Por motivos como el anterior, llega
un momento que el proveedor de desarrollo toma consciencia de que ningn otro proveedor,
nadie de la competencia, se atrever a intentar quitarle el proyecto nadie quiere ese
problemn y el que quiera entrar cobrar ms para poder hacerse con ello.

Entonces le sube las tarifas al cliente. As, podrs ver gente y empresas rematadamente malas
cobrando tarifas que te produciran escalofros, diciendo, adems, que ellos son los nicos que
saben de ese software y por ello cobran tanto (te repito, lo he escuchado, y muchas veces).

4. Las ofertas ms competitivas del mercado

Hacerlo mal genera la paradoja de prometer hacerlo en menos tiempo pero en la realidad
tardar el doble, o ms, de tiempo de lo que alguien que se sabe dira que lo hara.

Y lo anterior es una gran ventaja competitiva. Es lo que todo cliente quiere escuchar el menor
tiempo. Y si al menor tiempo le unes que, debido al apunto 1 de esta lista, eres el proveedor que
tiene personal menos cualificado y por ello menos costoso adems de ser el que lo hace en
menos tiempo eres el que lo hace en menor precio. As no falla, te llevas el proyecto.

5. Aumento del tiempo de proyecto

A raz del punto anterior, aquello de prometer menos tiempo de proyecto del posible y
necesario, crea otra gran ventaja competitiva (adems de ganar el proyecto).
Lo normal es que la presin del inocente cliente engaado, para que el mal proveedor cumpla
las fechas, que ya sabemos son imposibles, provocar que el proveedor, para quitarse
problemas y los, les entregue un trabajo mal terminado.

Una vez entregado, ms que en procesos tan caticos, esos en los que nadie tiene claro
exactamente qu era lo que haba que entregar, se dar por buena la entrega y empezar la
mal llamada fase de mantenimiento (realmente, fase de terminar lo que no dio tiempo).

7. POR QU SE COMPRA SOFTWARE MALO?

El usuario es un usuario principiante de software: El profesional promedio tiene
conocimientos y dominio bsico de computadoras y de software. Sus capacidades no
pasan del uso de Windows y del Office, y dependen del servicio tcnico si algn
problema ocurre con el equipo. Entonces, ante un entorno de mediocridad informtica
no hay un concepto claro del software que deberan manejar o conocer, o el software
que les permita hacer mejor su trabajo.
El criterio de compra y uso de software no es tcnico: En contexto emergentes, las
necesidades son todas y las tareas pendientes son muchas. Debido a que tanta falta
hacer, entonces no hay criterio para priorizar el gasto en software y el hecho que un
software sea utilizado es ms por el juicio/opinin del jefe de turno que basado en
opiniones tcnicas y planificacin del uso de software.
El software libre no se licita: Ante la discusin de usar software libre/comercial se
debera preguntar: si existe software libre, por qu se sigue comprando software
comercial? Bueno, es que el software libre no se licita, no cuesta, por lo cual no hay
comisiones y beneficios para los funcionarios. Estos beneficios no siempre son dinero,
sino pueden ser becas, viajes u otros incentivos no tcnicos que motivan el uso y el pago
de software y licencias.

Ejemplos de mal software

o El 4 de junio de 1996 la Agencia Espacial Europea lanz el cohete Ariane 5. Un
error de programacin en el mdulo de gestin provoc la autodestruccin del
cohete 37 segundos despus del despegue.
o Un error de programacin de la unidad de control de la mquina de radioterapia
Therac-25 caus entre 1985 y 1987 al menos seis accidentes en los que los
pacientes recibieron sobredosis masivas de radiacin.
o En 2013, un error de programacin provoc el caos en la compaa de aviacin
American Airlines. La unin de dos sistemas como resultado de la fusin de
varias compaas areas origin un fallo en el sistema de reserva de pasajes.
o En 1993 en la intrincada carrera entre empresas productoras de
microprocesadores, Intel sac al mercado un procesador con un error en la
unidad de punto flotante, al descubrir el error se hizo necesario recoger toda la
produccin entregada y reemplazarla por procesadores no defectuosos. Esta
operacin tuvo un costo de 475 millones de dlares.
8. SOFTWARE MALICIOSO MALWARE
El malware (del ingls malicious software), tambin llamado badware, cdigo maligno,
software malicioso, software daino o software malintencionado, es un tipo de software
que tiene como objetivo infiltrarse o daar una computadora o sistema de informacin
sin el consentimiento de su propietario. El trmino malware es muy utilizado por
profesionales de la informtica para referirse a una variedad de software hostil,
intrusivo o molesto.1 Antes de que el trmino malware fuera acuado por Yisrael Radai
en 1990, el software malicioso se agrupaba bajo el trmino "virus informticos".

El software se considera malware en funcin de los efectos que provoque en un

computador. Malware no es lo mismo que software defectuoso; este ltimo contiene
bugs peligrosos, pero no de forma intencionada.

Tipos
o Malware infeccioso: virus y gusanos: Los tipos ms conocidos de malware, virus
y gusanos, se distinguen por la manera en que se propagan, ms que por otro
comportamiento particular.

El trmino "virus informtico" se usa para designar un programa que, al

ejecutarse, se propaga infectando otros softwares ejecutables dentro de la
misma computadora. Los virus tambin pueden tener un payload9 que realice
otras acciones a menudo maliciosas, por ejemplo, borrar archivos. Por otra
parte, un gusano es un programa que se transmite a s mismo, explotando
vulnerabilidades en una red de computadoras para infectar otros equipos. El
principal objetivo es infectar a la mayor cantidad posible de usuarios, y tambin
puede contener instrucciones dainas al igual que los virus.

Ntese que un virus necesita de la intervencin del usuario para propagarse

mientras que un gusano se propaga automticamente.
o Malware ocultos:
Puertas traseras o backdoors: Un backdoor o puerta trasera es un
mtodo para eludir los procedimientos habituales de autenticacin al
conectarse a una computadora. Una vez que el sistema ha sido
comprometido (por uno de los anteriores mtodos o de alguna otra
forma), puede instalarse una puerta trasera para permitir un acceso
remoto ms fcil en el futuro.
Drive-by downloads: El trmino puede referirse a las descargas de
algn tipo de malware que se efecta sin consentimiento del usuario,
lo cual ocurre al visitar un sitio web, al revisar un mensaje de correo
electrnico o al entrar a una ventana pop-up, la cual puede mostrar un
mensaje de error. Sin ser su verdadera intencin, el usuario consiente
la descarga de software indeseable o de malware, y estas
vulnerabilidades se aprovechan.
Rootkits: Las tcnicas conocidas como rootkits modifican el sistema
operativo de una computadora para permitir que el malware
permanezca oculto al usuario. Por ejemplo, los rootkits evitan que un
proceso malicioso sea visible en la lista de procesos del sistema o que
sus ficheros sean visibles en el explorador de archivos.
o Malware para obtener beneficios:
Mostrar publicidad: Spyware, Adware: Los programas spyware son
creados para recopilar informacin sobre las actividades realizadas por
un usuario y distribuirla a agencias de publicidad u otras organizaciones
interesadas. Por otra parte, los programas adware muestran publicidad
al usuario de forma intrusiva en forma de ventana emergente (pop-up)
o de cualquier otra forma.
Robar informacin personal: Keyloggers y Stealers:
Los keyloggers monitorizan todas las pulsaciones del teclado y las
almacenan para un posterior envo al creador. Por ejemplo al introducir
un nmero de tarjeta de crdito el keylogger guarda el nmero,
posteriormente lo enva al autor del programa y este puede hacer pagos
fraudulentos con esa tarjeta. Los stealers tambin roban informacin
privada pero solo la que se encuentra guardada en el equipo.
Ataques distribuidos: Botnets: Las botnets son redes de computadoras
infectadas, tambin llamadas zombis, que pueden ser controladas a
la vez por un individuo y realizan distintas tareas.
Otros tipos: Rogue software y Ransomware: Los rogue software
hacen creer al usuario que la computadora est infectada por algn
tipo de virus u otro tipo de software malicioso, los ransomware
tambin llamados criptovirus o secuestradores, son programas que
cifran los archivos importantes para el usuario, hacindolos
inaccesibles, y piden que se pague un rescate para poder recibir la
contrasea que permite recuperar los archivos.
9. PRINCIPIOS TICOS DE LA ING. DEL SOFTWARE
Recomendada por la "IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and
Professional Practices

Cdigo de Ingeniera de Software de tica y Prctica Profesional fue desarrollado por el

grupo de trabajo conjunto ACM / IEEE-CS de tica Software Ingeniera y Prcticas
Profesionales (SEEPP).

Esta versin 5.2 est vigente a partir de enero de 2008. Fue aprobado conjuntamente
por la ACM y la IEEE-CS como el estndar para la enseanza y la prctica de la
ingeniera de software

Los ingenieros de software debieran obligarse a hacer del anlisis, especificacin, diseo,
desarrollo, pruebas y mantenimiento del software una profesin respetada y beneficiosa.
Debido a su posicin en el desarrollo de sistemas software, los ingenieros del software
tienen suficientes oportunidades para causar beneficio o generar dao

En concordancia con la obligacin con el bienestar, salud y seguridad de la sociedad, los

ingenieros del software debieran adherirse a los Ocho Principios siguientes:

I. Sociedad
Los ingenieros del software actuarn de manera consistente con el inters general.
En particular, los ingenieros de software debern, adecuadamente:

1. Aceptar completa responsabilidad por su trabajo.

2. Moderar los intereses del ingeniero del software, el empresario, el cliente y los
usuarios con los del bienestar pblico.
3. Dar el visto bueno al software slo si se tiene fundada creencia de que es seguro,
cumple las especificaciones, ha pasado las pruebas pertinentes y no disminuye la
calidad de la vida, disminuye la confidencialidad o daa al medio ambiente. El
efecto ltimo del trabajo debiera ser el bienestar pblico.
4. Mostrar a las personas o autoridades correspondientes cualquier peligro real o
potencial para el usuario, la sociedad o el medio ambiente, que consideren, de
manera razonable, que est asociado con el software, o documentos relacionados.
5. Cooperar en las materias relacionadas con las preocupaciones graves causadas
por el software, su instalacin, mantenimiento, soporte o documentacin.
6. Ser justo y veraz en todas las afirmaciones, especialmente en las que sean
pblicas, relativas al software o documentos relacionados, mtodos y
herramientas.
7. Considerar las cuestiones de discapacidades fsicas, asignacin de recursos,
desventajas econmicas y otros factores que puedan disminuir el acceso a los
beneficios del software.
8. Estar dispuesto a donar las capacidades profesionales para buenas causas y
contribuir a la educacin del pblico en general con respecto a esta disciplina.
 II. Cliente y Empresario
Los ingenieros de software debern actuar de maneras en que se representen los mejores
intereses para sus clientes y empresarios, consistentemente con el inters general. En
particular los ingenieros de software debern, adecuadamente:

1. Proporcionar servicios slo en las reas de su competencia, siendo honestos y francos

acerca de cualquiesquiera limitaciones en su experiencia o educacin.
2. No utilizar conscientemente software obtenido o retenido de manera ilegal o no tica.
3. Utilizar la propiedad de un cliente o patrn slo en maneras adecuadamente
autorizadas, y con el conocimiento y consentimiento de los mismos.
4. Garantizar que cualquier documento en el que se confa ha sido aprobado, cuando as
se requiera, por alguien con autoridad para hacerlo.
5. Mantener como privada cualquier informacin confidencial obtenida mediante el
trabajo profesional, siempre que tal confidencialidad no sea inconsistente con los
aspectos de inters general y con la ley.
6. Identificar, documentar, recoger evidencia e informar con prontitud al cliente o
empresario si, en su opinin, es probable que fracase un proyecto, que se demuestre
demasiado caro, que viole la legislacin sobre propiedad intelectual, o que sea
problemtico.
7. Identificar, documentar e informar al empresario o cliente sobre cualquier asunto de
inters social, o del que se tenga conocimiento, acerca del software o documentos
relacionados.
8. No aceptar trabajo externo que vaya en detrimento del trabajo que se desarrolle para
su principal contratante.
9. No representar inters contrario al del empresario o cliente, a menos que se
comprometa otro valor tico ms elevado; en este ltimo caso se informar al
empresario o a otra autoridad adecuada acerca de esa preocupacin tica.

III. Producto
Los ingenieros de software debern garantizar que sus productos y las modificaciones
relacionadas cumplen los estndares ms elevados posibles. En particular, los
ingenieros de software debern, segn sea adecuado:

1. Promover mxima calidad, coste aceptable, y un plazo razonable, garantizando que

quedan claros los compromisos significativos al respecto, y que los aceptan el
empresario y el cliente, y que estn disponibles para consideracin por el usuario y el
pblico en general.

2. Garantizar objetivos adecuados y alcanzables para cualquier proyecto en el que

trabajen o lo vayan a hacer.
3. Identificar, definir, y examinar temas ticos, econmicos, culturales, legales y
medioambientales relacionados con cualquier proyecto.
4. Garantizar que estn cualificados, mediante una adecuada combinacin de educacin,
adiestramiento y experiencia, para cualquier proyecto en el que trabajen o lo vayan a
hacer.
 5. Garantizar una metodologa adecuada para cualquier proyecto en el que trabajen o lo
vayan a hacer.
6. Trabajar para seguir los estndares de la industria, si disponibles, que sean los ms
adecuados para las tareas, desvindose de los mismos slo cuando est justificado
tica o tcnicamente.
7. Esforzarse para entender completamente las especificaciones del software que estn
desarrollando.
8. Garantizar que las especificaciones para el software sobre el que trabajan han sido
bien documentadas, satisfacen los requisitos del usuario y tienen las aprobaciones
adecuadas.
9. Garantizar estimaciones cuantitativas realistas de coste, plazos, personal, y resultados
de cualquier proyecto en el que trabajen o vayan a hacerlo, y proporcionar una
evaluacin de la incertidumbre de esas estimaciones.
10. Garantizar unas adecuadas pruebas, depuraciones y revisiones del software y de los
documentos relacionados en los que se trabaje.
11. Garantizar una adecuada documentacin, incluyendo problemas significativos
descubiertos y las soluciones adoptadas, para cualquier proyecto en el que trabajen.
12. Trabajar para desarrollar software y documentos relacionados que respeten la
confidencialidad de aquellos que van a verse afectados por ese software.
13. Ser cuidadosos para utilizar slo datos precisos, obtenidos mediante medios legales y
ticos, y utilizarlos slo de maneras adecuadamente autorizadas.
14. Mantener la integridad de los datos, siendo sensible a aquellos que estn obsoletos u
equivocados.
15. Tratar todas las formas del mantenimiento del software con la misma profesionalidad
que los nuevos desarrollos.

IV. Juicio
Los ingenieros de software debern mantener integridad e independencia en su valoracin
profesional. En particular, los ingenieros del software debern, adecuadamente:

1. Moderar todos los juicios tcnicos por la necesidad de amparar y mantener valores
humanos.
2. Firmar slo los documentos preparados bajo su supervisin o dentro de sus reas de
competencia, y con los que se est de acuerdo.
3. Mantener objetividad profesional con respecto a cualquier software o documentos
relacionados para los que se les pida evaluacin.
4. No involucrarse en prcticas financieras engaosas, tales como sobornos, dobles
facturaciones u otras prcticas impropias.
5. Comunicar a todas las partes los conflictos de inters que no puedan evitarse
razonablemente.
6. Rechazar la participacin, como miembros o asesores, en organismos privados,
gubernamentales o profesionales vinculados con temas de software, en los que
tengan, o sus patronos o clientes, potenciales conflictos de inters no revelados.
 V. Gestin
Los gestores y lderes en ingeniera del software suscribirn y promovern un enfoque
tico a la gestin del desarrollo y mantenimiento del software. En particular, aquellos
ingenieros de software en funciones de direccin o liderazgo debern,
adecuadamente:

1. Garantizar una buena gestin en cualquier proyecto en los que trabajen,

incluyendo procedimientos efectivos para promover calidad y reduccin del
riesgo.
2. Garantizar que se informa a los empleados de los estndares antes de
adherirse a ellos.
3. Garantizar que los empleados conocen las polticas y procedimientos del
empresario para la proteccin de las claves de acceso, ficheros y otra
informacin que sea confidencial para el empresario o para otros.
4. Asignar trabajo slo despus de tener en cuenta la educacin y experiencia,
moderados con el deseo de mejorar tal educacin y experiencia.
5. Garantizar unas estimaciones cuantitativas realistas del coste, plazo, personal,
calidad y productos en cualquier proyecto en el que trabajen o tengan
intencin de hacerlo, y proporcionar una valoracin de la incertidumbre de
esas estimaciones.
6. Atraer empleados slo mediante una descripcin completa y precisa de las
condiciones del empleo.
7. Ofrecer una adecuada y justa remuneracin.
8. No impedir injustamente a otro obtener una mejor posicin para la que est
cualificado.
9. Garantizar que hay un acuerdo correcto en lo referente a la propiedad de
cualquier software, procesos, investigacin, escritos, o cualquier otra
propiedad intelectual a la que el ingeniero del software ha contribuido.
10. Proporcionar los medios correspondientes en caso de alegaciones de
incumplimiento de la poltica del empresario o de este Cdigo.
11. No pedir a un ingeniero del software hacer algo inconsistente con este Cdigo.
12. No castigar a nadie por expresar preocupaciones ticas sobre un proyecto.

VI. Profesin
Los ingenieros de software debern progresar en la integridad y reputacin de la profesin,
consistentemente con el inters general. En particular, los ingenieros de software debern, en
la medida de lo posible:

1. Ayudar a desarrollar un ambiente organizativo favorable a un comportamiento tico.

2. Promover el conocimiento general de la ingeniera del software.
3. Diseminar el conocimiento de ingeniera del software mediante la participacin en
organizaciones profesionales, reuniones y publicaciones.
4. Apoyar, como miembros de una profesin, a otros ingenieros de software que se
esfuercen en seguir este Cdigo.
5. No promover el inters propio a costa de la profesin, el cliente o el empresario.
6. Obedecer todas las leyes que gobiernen su trabajo, a menos que, en circunstancias
excepcionales, tal cumplimiento sea inconsistente con el inters general.
 7. Ser preciso en la descripcin de las caractersticas del software en el que se trabaja,
evitando no slo falsas declaraciones, sino tambin declaraciones que podran
razonablemente suponerse especulativas, vacas, decepcionantes, engaosas o
dudosas.
8. Tener la responsabilidad de detectar, corregir e informar errores en el software y
documentos asociados en los que se trabaje.
9. Asegurarse que los clientes, patronos y gerentes conocen la obligacin del ingeniero
de software con respecto a este Cdigo de tica, y las ramificaciones subsecuentes de
tal obligacin.
10. Evitar asociaciones con empresas y organizaciones que estn en conflicto con este
cdigo.
11. Considerar que las inobservancias de este Cdigo son inconsistentes con ser un
ingeniero de software profesional.
12. Expresar las preocupaciones a las personas implicadas cuando se detecten
incumplimientos significativos de este Cdigo, a menos que sea imposible,
contraproducente o peligroso.
13. Informar sobre las vulneraciones de este Cdigo a las autoridades pertinentes cuando
est claro que consultar a las personas implicadas en estas inobservancias es
imposible, contraproducente o peligroso.

VII. Compaeros
Los ingenieros de software sern justos y sern soporte de sus compaeros. En particular, los
ingenieros de software debern, adecuadamente:

1. Animar a los compaeros a adherirse a este Cdigo.

2. Ayudar a los compaeros en el desarrollo profesional.
3. Reconocer completamente el trabajo de otros y abstenerse de atribuirse mritos no
reconocidos.
4. Revisar el trabajo de otros de forma objetiva, sincera y adecuadamente documentada.
5. Tratar justamente las opiniones, preocupaciones o quejas de un compaero.
6. Ayudar a los compaeros en el conocimiento completo de los estndares de trabajo,
incluyendo polticas y procedimientos para proteger las claves de acceso, ficheros y
otra informacin confidencial, y medidas de seguridad en general.
7. No interferir injustamente en la carrera profesional de cualquier compaero; sin
embargo, la preocupacin por el empresario, el cliente o el inters pblico puede
forzar, con buena voluntad, a cuestionar la competencia de un compaero.
8. En las situaciones fuera de las reas de competencia personales, consultar las
opiniones de otros profesionales que tengan competencia en esa rea.

VIII. Persona
Los ingenieros de software debern participar en el aprendizaje continuo de la prctica de su
profesin y promovern un enfoque tico en la prctica de la profesin. En particular, los
ingenieros de software debern continuamente preocuparse de:

1. Mejorar su conocimiento de los avances en el anlisis, especificacin, diseo,

desarrollo, mantenimiento y pruebas del software y documentos relacionados, junto
con la gestin del proceso de desarrollo.
2. Mejorar su capacitacin para crear software de calidad, seguro, fiable y til con un
coste razonable y en un plazo razonable.
 3. Mejorar su capacidad para producir documentacin precisa informativa y
correctamente escrita.
4. Mejorar su comprensin del software y documentos relacionados en los que se trabaja
y del entorno en el que se utilizarn.
5. Mejorar su conocimiento de los estndares pertinentes y de las leyes que regulan el
software y los documentos relacionados en los que trabajan.
6. Mejorar su conocimiento de este Cdigo, su interpretacin y su aplicacin al trabajo.
7. No dar un tratamiento injusto a nadie por prejuicios irrelevantes.
8. No influenciar a otros para tomar accin alguna que conlleve un incumplimiento de
este Cdigo.
9. Reconocer que las inobservancias personales de este Cdigo son inconsistentes con
ser un ingeniero de software profesional.

10. CONCLUSIONES

El desarrollo de software, como se practica comnmente hoy en da, no se parece mucho a

ingeniera, pero podra lograrse. Una vez que dejemos de hacer la pregunta equivocada de
"Qu es actualmente el desarrollo de software?" y empecemos a hacer la pregunta correcta de
"El desarrollo de software debera ser ingeniera?" podremos empezar a responder las
preguntas realmente interesantes: Cul es el cuerpo base de conocimiento de la Ingeniera de
Software? Qu necesitan hacer los desarrolladores profesionales de software antes de que
puedan utilizar ese conocimiento? Qu tanta es la recuperacin de la inversin desde la
prctica de desarrollo de software como una disciplina de ingeniera? Cules son las normas de
conducta profesional apropiadas para los desarrolladores de software? Para las organizaciones
de software? Se debe reglamentar a los desarrolladores de software? Si es as, en qu medida?
Y, tal vez la pregunta ms interesante de todas: Cmo ser la industria del software despus
que todas estas cuestiones hayan sido resueltas?

11. REFERENCIAS

D. Knuth. The Art of Computer Programming: Volumes 1-4. USA: Addison-Wesley Professional.
1998.

D. L. Parnas. Software Engineering Programs Are Not Computer Science Programs. IEEE
Software, Vol. 16, No 6, pp. 1-16. 1999.

E. Serna M. (2010). Mtodos Formales e Ingeniera de Software. Revista Virtual Universidad

Catlica del Norte, No. 30, pp. 1-20.

D. L. Parnas. Software Engineering: An Unconsummated Marriage. Communications of the

ACM. Vol. 40, No. 9, pp. 128. 1997.

R. Baines. Across Disciplines: Risk, Design, Method, Process, and Tools. IEEE Software, Vol. 15,
No. 4, pp. 61-64. 1998.
El Cdigo de tica y Prctica Profesional de Ingeniera del Software, recomendada por la "IEEE-
CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices