CAPTULO 2. Ingeniera de SoftwarePara comenzar veamos lo que ya
sabeRecuperacin de informacin inicial Qu es la ingeniera? Defina el
concepto de software Defina que es la calidad Qu es la
informtica?Definicin de Ingeniera de Software.IngenieraLa historia
de la ingeniera, por su misma naturaleza intrnseca, estuvo presente
en toda la historia de la humanidad y es muy anterior a las
ciencias. Desde los tiempos iniciales del ser humano bajo su
configuracin actual, el hombre hizo cosas tcnicas que fueron las
ingenieras de su tiempo. No tuvo que esperar que hicieran su
aparicin las ciencias, para producir lo que necesitaba. La
ingeniera siempre estuvo adelante. Luego vinieron las explicaciones
rigurosas de los cientficos.Dos han sido las actividades que han
caracterizado al hombre, que se sealan con sus habituales
denominaciones:Conocer, que equivale a decir, homo
sapiensConstruir, que equivale a decir, homo faber.El hombre comenz
sus invenciones con el hacha de slex y el punzn de hueso,
precursoras de las hoy sofisticadas mquinas-herramienta accionadas
en forma automtica por control numrico y de los robots que
ensamblan automviles, todo al conjuro de la informtica asociada a
la mquina. As naci la ingeniera, el ingeniero de hoy es ese homo
faber de nuestro tiempo. (Sobrevila, 2011)INGENIERA es el arte de
tomar una serie de decisiones importantes, dado un conjunto de
datos incompletos e inexactos, con el fin de obtener, para un
cierto problema, aquella entre las posibles soluciones, la que
funcione de manera ms satisfactoria. (Cross, 1953)
Quien haya ejercido efectivamente la ingeniera sabe muy bien la
verdad de Hardy Cross. Los datos de que se dispone nunca son todos,
ni son enteramente confiables. La ingeniera no es ciencia exacta
como la astronoma. Es un arte. Adems, el ingeniero vive decidiendo
entre varias soluciones, es decir, tomando decisiones, lo que
implica la aplicacin de criterios, que involucran a la voluntad de
las personas. Arte, criterio y voluntad son la base del trabajo del
ingeniero. (Sobrevila, 2011)Para el ABET, (Acreditation Board for
Engineering and Technology ), Ingeniera es:La profesin en la que el
conocimiento de las ciencias matemticas y naturales adquiridas
mediante el estudio, la experiencia y la prctica, se aplica con
buen juicio a fin de desarrollar formas en que se puedan utilizar,
de manera econmica, los materiales y las fuerzas de la naturaleza
en beneficio de la humanidad.Sunny Auyang defini ingeniera de la
siguiente manera:La ingeniera es la ciencia de la produccin, la
cual, junto a la reproduccin, es la fundamental de las actividades
humanas (Auyang, 2004)La anterior definicin habla de la ingeniera
en general, y no de las diversas ingenieras concretas. Si se
estudian las diferentes ingenieras concretas, cada una de las
cuales tiene un objeto concreto y definido, que han evolucionado
hasta alcanzar el reconocimiento como profesin, es relevante el
entorno en que stas se desarrollan. Es importante porque el
ejercicio de toda profesin debe ser regulado por un marco
jurdico-normativo especfico. (Sanchez , Sicilia, & Rodrguez,
2012)La estructuracin de las diferentes ingenieras como disciplinas
profesionales reconocidas se puede encontrar en el trabajo seminal
de Paul Starr (1982), donde se enuncian los tres elementos que
constituyen una disciplina profesional: Aspecto colegial: El
conocimiento y competencia del profesional debe haber sido validado
por la comunidad de sus pares. Aspecto cognitivo: Ese conocimiento
y competencia consensualmente validada debe descansar en criterios
racionales y cientficos. Aspecto moral: El juicio y los consejos
profesionales deben orientarse a un conjunto de valores
sustantivos.La ingeniera como actividad humana es la aplicacin del
conocimiento y los mtodos cientficos al diseo y la produccin de
productos complejos.SoftwareEl trmino software se suele atribuir a
John W. Tukey quien, en un artculo publicado en 1957 en la revista
American Mathematical Monthly, introdujo por vez primera el trmino.
La idea de software de los aos 50 era prcticamente un sinnimo del
trmino programa de computadora.Esta definicin es, en la actualidad,
demasiado especfica. Una definicin ms amplia es la que proporciona
el diccionario Merriam-Webster: Software es el conjunto completo de
programas, procedimientos y documentacin relacionada que se asocia
con un sistema, y especialmente con un sistema de computadora. En
sentido especfico, software son los programas de computadora.Un
aspecto adicional del software es el hecho de que en su mayora, est
destinado a evolucionar. Y de hecho, si no lo hace quedar obsoleto
con el tiempo, al no adaptarse a las cambiantes necesidades del
usuario. La evolucin implica generalmente aadir nuevas
funcionalidades o modificar las existentes, si bien la evolucin del
software es diferente a la de los diseos de otros artefactos
ingenieriles.
Complejidad inherente al softwareEn 1987, Frederick Brooks
public un artculo que ha adquirido una notable popularidad. En
dicho artculo, cuyo ttulo puede traducirse como No existen balas de
plata Esencia y accidente en la Ingeniera del software, Brooks
preconizaba que no existira ninguna herramienta o metodologa que
consiguiese un incremento notable de la productividad en el
desarrollo de software en la dcada siguiente. Aparte de la ancdota
sobre la prediccin, lo importante de este artculo es que establece
el concepto de complejidad como caracterstica esencial al software,
entendiendo esencial en su sentido de inherente, es decir, propia
de la naturaleza del software. (Sanchez , Sicilia, & Rodrguez,
2012)La Ingeniera del SoftwareTrmino acuado en la conferencia de la
OTAN de 1968, al definir la necesidad de una disciplina cientfica
que, como ocurre en otras reas, permita aplicar un enfoque
sistemtico, disciplinado y cuantificable al desarrollo operacin y
mantenimiento del software; es decir, la aplicacin de la ingeniera
al software. El trmino se adjudica a F. L. Bauer, aunque
previamente haba sido utilizado por EDSGER en su obra The Humble
Programmer.El proyecto ms consensuado hasta la fecha para definir
las reas de conocimiento que comprenderan una ingeniera del
software es el SWEBOK. (Sanchez , Sicilia, & Rodrguez,
2012)
La crisis del softwareDurante los primeros aos de la era de la
computadora, el software se contemplaba como un aadido. La
programacin de computadoras era un "arte de andar por casa" para el
que existan pocos mtodos sistemticos. El desarrollo del software se
realizaba virtualmente sin ninguna planificacin, hasta que los
planes comenzaron a descalabrarse y los costes a correr. Los
programadores trataban de hacer las cosas bien, y con un esfuerzo
heroico, a menudo salan con xito. El software se diseaba a medida
para cada aplicacin y tena una distribucin relativamente pequea. La
mayora del software se desarrollaba y era utilizado por la misma
persona u organizacin. La misma persona lo escriba, lo ejecutaba y,
si fallaba, lo depuraba. El diseo era un proceso implcito,
realizado en la mente de alguien y, la documentacin normalmente no
exista. La segunda era en la evolucin de los sistemas de
computadora se extienden desde la mitad de la dcada de los sesenta
hasta finales de los setenta. La multiprogramacin y los sistemas
multiusuario introdujeron nuevos conceptos de interaccin hombre -
mquina. Tambin se caracteriz por el establecimiento del software
como producto y la llegada de las "casas del software". Los
patronos de la industria, del gobierno y de la universidad se
aprestaban a "desarrollar el mejor paquete de software" y ganar as
mucho dinero. La tercera era en la evolucin de los sistemas de
computadora comenz a mediados de los aos setenta y contino ms all
de una dcada. El sistema distribuido, mltiples computadoras, cada
una ejecutando funciones concurrentes y comunicndose con alguna
otra, increment notablemente la complejidad de los sistemas
informticos. Las redes de rea local y de rea global, las
comunicaciones digitales de alto ancho de banda y la creciente
demanda de acceso "instantneo" a los datos, supusieron una fuerte
presin sobre los desarrolladores del software. La conclusin de la
tercera era se caracteriz por la llegada y amplio uso de los
microprocesadores. El microprocesador ha producido un extenso grupo
de productos inteligentes, desde automviles hasta hornos
microondas, desde robots industriales a equipos de diagnsticos de
suero sanguneo. Podramos decir que de 1965 a 1985 la identificacin
del problema de la crisis del software se convierte en el tema
central de la disciplina.Desarrollo de competencias. Actividad para
el portafolio de evidenciasActividad individual: Entrar a la
direccin: www.chihuahuaitpros.org. Consultar y leer el artculo No
hay balas de plata: Lo esencial y lo accidental en la Ingeniera del
Software de Frederick P. Brooks, Jr. Actividad colaborativa: En
triadas comentar con sus compaeros el artculo No hay balas de
plata: Lo esencial y lo accidental en la Ingeniera del Software.
Elegir una estrategia didctica para explicar el artculo, dichas
estrategias se pueden consultar en www.chihuahuaitpros.org . La
presentacin de la estrategia terminada es libre. La estrategia
terminada ser entregada al docente.
Ciencias de la Computacin e Ingeniera de SoftwareLas diferentes
ramas o disciplinas en el rea de ingeniera difieren en el objeto de
produccin, pero existen en ellas aspectos en comn: La ciencia de la
ingeniera, que se ocupa de los principios y mecanismos subyacentes
de la disciplina. Procesos de diseo, que en general incluyen una
fase de conceptualizacin, y una fase de diseo detallado Aspectos de
gestin y organizacin, pues la tecnologa que se produce implica
tanto a las personas como a las organizaciones. Adems, las propias
personas que crean tecnologa no suelen trabajar aisladas, sino en
equipos y organizaciones.En el caso de la Ingeniera de Software,
las actividades de diseo seran asimilables a lo que normalmente
conocemos como desarrollo. Ahora bien, Cul es la ciencia de la
ingeniera que nos interesa cuando estudiamos la Ingeniera del
Software? Evidentemente, la ciencia de la computacin est asociada a
esta ingeniera, pues abarca los principios matemticos y fsicos, de
los sistemas basados en computadora. Es importante distinguir
claramente la diferencia entre Ciencia de la Computacin y la
Ingeniera del Software, ya que lo especfico de esta ltima es lo
concerniente al diseo y uso de software, utilizando el conocimiento
que es el objeto de la Ciencia de la Computacin. Ver Figura 6.
(Sanchez , Sicilia, & Rodrguez, 2012)Teoras: Compiladores
Autmatas Algoritmia SeguridadProblema
Ingeniera de Software
Fundamentos de fsica Fundamentos matemticosCiencias de la
ComputacinSolucin
Herramientas ProcesosEstndares
Figura 6. Relacin entre las ciencias de la computacin y la
Ingeniera del software
La ciencia de la computacin est asociada a la Ingeniera del
Software pues abarca los principios matemticos y fsicos, en su
sentido ms amplio, de los sistemas basados en computadora. No
obstante, es importante distinguir claramente entre ciencia de la
computacin e Ingeniera del Software, ya que lo especifico de esta
ltima es lo concerniente al diseo y uso del software, utilizando el
conocimiento que es el objeto de la ciencia de la computacin.
Desarrollo de competencias. Actividad para el portafolio de
evidenciasActividad colaborativa: Realizar una lnea del tiempo
donde figure la crisis del software. La actividad es libre en
cuanto al material a utilizar en la lnea del tiempo. Entregar el
resultado de la actividad al docente.
Elementos de la Ingeniera del Software como disciplina
profesionalEn muchas disciplinas de ingeniera, la acreditacin de
los profesionales y la existencia de directrices comunes para la
elaboracin de currculos y planes de estudio son asuntos a los que
se presta especial atencin. El reconocimiento de un cuerpo de
conocimiento para la Ingeniera del Software, as como la creacin de
mecanismos de acreditacin, era una asignatura pendiente hasta que
las dos organizaciones ms activas y relevantes en el rea, ACM e
IEEE Computer Society, comenzaron a promover activamente su puesta
en prctica. Estas dos organizaciones, reconocidas a nivel
internacional, incluyen dentro de su mbito de inters la Ingeniera
del Software. Estas dos organizaciones aunaron esfuerzos para
desarrollar una recomendacin curricular conjunta para titulaciones
de Ingeniera del Software, conocida como CCSE (Computing Curriculum
Software Engineering) y oficialmente denominada SE2004 (Software
Engineering 2004). SE2004 complementa a la gua SWEBOK, no orientada
al diseo de programas universitarios, sino a delimitar los
conocimientos necesarios para el ejercicio profesional ms all de la
educacin formal.Desarrollo de competencias. Actividad para el
portafolio de evidenciasActividad individual: Investigar sobre la
recomendacin curricular SE2004: Definicin y elementos Investigar
sobre SWEBOK: Definicin y objetivosActividad colaborativa En
triadas comenten la informacin investigada de forma individual.
Preparar una exposicin oral de 10 minutos con la informacin
consultada, de preferencia incluir una estrategia extra en la
exposicin. Entregar la informacin consultada de manera escrita al
docente.
Caractersticas y mitos del software.Tomando en cuenta que el
hardware que es la parte fsica del sistema de cmputo y el software
es la parte lgica, sus caractersticas son considerablemente
distintas: El software se desarrolla, no se fabrica en un sentido
clsico. 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.
El software no se estropea. 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. La
implicacin es clara, el software no se estropea. Pero se deteriora!
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. 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 con sigue la funcin
adecuada y va al armario donde se encuentran los catlogos de
componentes digitales. Despus de seleccionar cada componente, puede
solicitarse la compra. 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. (Pressman R. S.,
2002)
Capas de la Ingeniera de Software.Independientemente de la
complejidad del sistema y de su rea de aplicacin la Ingeniera del
Software puede considerarse una tecnologa multicapa. Ver Figura
7
Figura 7. Capas de Ingeniera de Software El fundamento de la
Ingeniera del Software es la capa proceso. El proceso de la
Ingeniera del Software es la unin que mantiene juntas las capas de
tecnologa y que permite un desarrollo racional y oportuno de la
Ingeniera del Software (Pressman R. S., 2002).
ProcesoUn proceso, entendido de manera general, es una serie de
pasos que incluyen actividades, restricciones y recursos que
resultan en un producto determinado con ciertas caractersticas.Otra
definicin general de proceso es la que proporciona el glosario IEEE
de Trminos de Ingeniera del Software: Un proceso es una secuencia
de pasos que se lleva a cabo para un propsito determinado. (Sanchez
, Sicilia, & Rodrguez, 2012)
Definicin de proceso softwareUn proceso de software es un
conjunto coherente de polticas, estructuras organizativas,
tecnologas, procedimientos y artefactos que se necesitan para
concebir, desarrollar, implantar y mantener un producto de
software. (Sanchez , Sicilia, & Rodrguez, 2012)MtodosLos
mtodos, o modelos, de la Ingeniera de Software indican como
realizar los pasos necesarios del ciclo de vida (cada uno con un
enfoque distinto). As pues, est el Modelo de Construccin de
Prototipos, el Modelo de Desarrollo Rpido de Aplicaciones, el
Modelo de Procesos Evolutivos que se divide en el Modelo
Incremental, en Modelo Espiral, de Ensamblaje de Componentes y de
Desarrollo Concurrente el Modelo de Mtodos Formales, y por ltimo
las Tcnicas de Cuarta Generacin. (Pressman R. S.,
2002)HerramientasLas herramientas ayudan a organizar tareas de
trabajo, controlar y supervisar los progresos y administrar la
calidad tcnica. Su objetivo principal es proporcionar un soporte
automtico o semiautomtico, para los procesos y para los mtodos.
Cuando las herramientas de software se aplican a la propia tarea de
desarrollar software, se habla entonces de herramientas CASE. Este
trmino, acrnimo del ingls Computer Aided Software Engineering,
puede traducirse por Ingeniera del software Asistida por
Computadora.Una herramienta CASE es una herramienta software que se
utiliza en una o ms fases del desarrollo de un producto software
para apoyo de alguna tarea especfica de Ingeniera del Software.
(Sanchez , Sicilia, & Rodrguez, 2012)Enfoque de calidadLa
ingeniera del software es un grupo de caractersticas que representa
la efectividad y la eficiencia de un sistema de informacin. Es
importante enfatizar en dos puntos: Un Software de Calidad debe ser
eficaz, es decir, que debe realizar las funciones establecidas,
debe ser amigable. Un usuario debe utilizar el software porque
produce resultados confiables, realiza todas las operaciones que se
requieren, ejecuta las operaciones en un tiempo aceptado y es
fcilmente usado por el grupo de usuarios a quien est dirigido. Un
Software de Calidad debe ser eficiente, es decir el costo de su
desarrollo tomando todos los recursos y el costo de su operacin
debe ser tal que las organizaciones involucradas en su desarrollo y
uso obtengan el mximo beneficio o por lo menos un beneficio
aceptable en un perodo de tiempo establecido. (Sanchez , Sicilia,
& Rodrguez, 2012)
Definicin de Software de Calidad.Mirando la Ingeniera del
Software desde una perspectiva histrica, hasta la dcada de los aos
1960 estaramos en la era funcional, los aos 70 fueron la era de la
planificacin, los 80 la era de los costes y a partir de los 90 la
era de la calidad y la eficiencia. Stephen K. KanLa calidad es un
trmino del que todos tenemos una nocin clara, y sin embargo nos
resulta difcil definirla con palabras. Tiene adems muchos aspectos,
pues es un concepto aplicable a prcticamente cualquier objeto,
proceso o accin. As, nos referimos a una tela de calidad, a una
enseanza de calidad, e incluso, a una jugada de futbol de gran
calidad individual. Existen agencias dedicadas a velar por la
calidad, a certificarla o a acreditar que un proceso o producto
cumple unos ciertos parmetros de calidad pero Qu es en realidad la
calidad?La definicin de Raymond Paul es una referencia importante a
la hora de estudiar este concepto desde la perspectiva de la
Ingeniera del Software:La caracterstica que distingue el grado de
excelencia o superioridad de un proceso, producto o servici o.Una
forma sencilla de evaluar la calidad de un producto es identificar
aquellos atributos que diferencian a un objeto de calidad de uno
que no la tiene. Si el producto en cuestin posee dichos atributos,
entonces se considera que tiene calidad y en caso contrario, se
considera que no la tiene. As, cuando hablamos del software, la
calidad se identifica a menudo con la ausencia de fallos. (Sanchez
, Sicilia, & Rodrguez, 2012)Cultura y tica de la calidadEn el
libro Creacin de una cultura de la Ingeniera del Software, Karl
Wiegers hace un detallado catlogo de aquellos elementos que
contribuyen al xito de un proyecto de software, poniendo un nfasis
especial en la mejora de la cultura de la calidad en una
organizacin. Esta cultura de la Ingeniera del Software se podra
definir como el compromiso de los ingenieros del software de una
organizacin con las metas de calidad de su organizacin y
particularmente, con aquellas que tienen que ver con la obtencin de
Software de Calidad.Adems de la importancia que tiene ser
conscientes de lo que significa la cultura de la Ingeniera del
Software, las consideraciones ticas tambin tienen un papel en la
calidad del software. En las ciencias de la computacin y la
Ingeniera del Software, las dos asociaciones ms relevantes y con
mayor nmero de miembros (la IEEE Computer Society y la ACM) han
desarrollado conjuntamente un cdigo deontolgico que enumera los
principios morales bsicos, as como los derechos y responsabilidades
de los profesionistas del rea. La ACM marca los siguientes
principios en su cdigo de tica. (Gotterbarn , Miller, &
Rogerson, 1999)Ingeniera de SoftwareCdigo de tica y Prctica
Profesional 5.2Versin cortaPREMBULOLa versin corta del cdigo resume
las aspiraciones a un alto nivel de abstraccin; las clusulas que se
incluyen en la versin completa proporcionan ejemplos y detalles
acerca de cmo estas aspiraciones modifican nuestra manera de actuar
como profesionales de la Ingeniera de Software. Sin las
aspiraciones los detalles pueden convertirse en tediosos y
legalistas; sin los detalles las aspiraciones pueden convertirse en
altisonantes pero vacas; juntas, las aspiraciones y los detalles
forman un cdigo cohesivo.Los ingenieros de software debern
comprometerse a convertir el anlisis, especificacin, diseo,
implementacin, pruebas y mantenimiento de software en una profesin
respetada y benfica. De acuerdo a su compromiso con la salud,
seguridad y bienestar social, los ingenieros de software debern
sujetarse a los ocho principios siguientes:Sociedad. Los ingenieros
de software actuarn en forma congruente con el inters social.
Cliente y empresario. Los ingenieros de software actuarn de manera
que se concilien los mejores intereses de sus clientes y
empresarios, congruentemente con el inters social. Producto. Los
ingenieros de software asegurarn que sus productos y modificaciones
correspondientes cumplen los estndares profesionales ms altos
posibles. Juicio. Los ingenieros de software mantendrn integridad e
independencia en su juicio profesional. Administracin. Los
ingenieros de software, gerentes y lderes promovern y se suscribirn
a un enfoque tico en la administracin del desarrollo y
mantenimiento de software. Profesin. Los ingenieros de software
incrementarn la integridad y reputacin de la profesin
congruentemente con el inters social. Colegas. Los ingenieros de
software apoyarn y sern justos con sus colegas. Personal. Los
ingenieros de software participarn toda su vida en el aprendizaje
relacionado con la prctica de su profesin y promovern un enfoque
tico en la prctica de la profesin.
Desarrollo de competencias. Actividad para el portafolio de
evidenciasActividad individual: Entrar al sitio
http://www.acm.org/about/se-code-s , ah encontrar el cdigo de tica
en su versin completa Leer y realizar en una cuartilla su reflexin
sobre la importancia de este cdigo
Mltiples aspectos de la calidadDavid Garvin uno de los ms
influyentes estudiosos de la calidad de software, afirm en 1982 que
la calidad es un concepto complejo y con diferentes facetas, y que
en consecuencia debe ser estudiado desde diferentes perspectivas.
Tras analizar campos tan diferentes como la filosofa, la economa o
el marketing, Garvin identific las siguientes cinco perspectivas
desde las cuales la calidad puede ser definida y entendida: La
visin trascendental de la calidad, tambin denominada calidad
relativa. Hace referencia al hecho de que la calidad es fcil de
percibir y reconocer, pero difcil de definir. Segn esta
perspectiva, todos tenemos un concepto similar de lo que es la
calidad del software, algo as como un ideal que habra que alcanzar.
Se reconoce, no obstante, que es difcil que el software, una vez
construido, tenga la perfeccin de un software ideal que sirviese al
mismo fin. La perspectiva del usuario, segn la cual la calidad se
entiende como conformidad con aquello que el cliente espera recibir
y que fue establecido en las especificaciones del software. A
diferencia de la perspectiva anterior, la perspectiva del usuario
permite medir la calidad en trminos concretos: cuanto mayor sea el
grado de cercana entre las necesidades de los usuarios y las
caractersticas proporcionadas por el software, mayor ser su
calidad. Ntese cmo esa visin de la calidad vara en funcin del
contexto, ya que el mismo producto, dirigido a diferentes mercados
o tipos de usuarios, tendr diferentes percepciones de calidad
global. La perspectiva de la produccin identifica la calidad del
producto con la calidad de los procesos de produccin y post-venta.
Segn esta perspectiva, todo producto fabricado de acuerdo con
estndares regulados de calidad podr ser considerado un producto de
calidad, posiblemente mejor que otros que no hayan sido fabricados
segn este tipo de criterios. Esta es la visin de la calidad del
estndar ISO 9001 y del modelo de madurez CMM. La perspectiva del
producto relaciona la calidad con ciertas caractersticas de ste,
tales como la facilidad de mantenimiento, la funcionalidad o su
fiabilidad. A diferencia de las anteriores, que observan la calidad
del software tal y como es percibida exteriormente, esta
perspectiva apunta la calidad interna del software. Es la
perspectiva que recoge, por ejemplo, el estndar IEEE 1061-1992,
donde se enuncian un conjunto de atributos a estudiar en el
software construido. La perspectiva del valor establece una relacin
entre la cantidad de dinero que el cliente est dispuesto a pagar y
la calidad del producto. Se trata de una forma pragmtica de
entender la calidad, pues llegado un punto donde existe un
conflicto entre lo que el cliente est dispuesto a pagar y el coste
real de lo que solicita, los gestores del desarrollo tendrn que
decidir qu nivel de calidad puede implementarse para satisfacer las
necesidades del cliente, pero teniendo en cuenta que dicho cliente
no est dispuesto a asumir los costes de la mejor de las
implementaciones posibles. (Sanchez , Sicilia, & Rodrguez,
2012)Conocer que la calidad puede ser vista desde perspectivas tan
diferentes resulta esencial para comprender mejor la nocin de
calidad de software. Todo ello hace que en numerosas ocasiones
surjan conflictos entre los diferentes actores por cuestiones
relacionados con la calidad, ya que cada uno tiene, como hemos
visto, diferentes perspectivas de la misma. El software como
producto de calidadLa calidad del software viene definida segn el
grado de observancia de un conjunto de criterios de calidad
prestablecidos y medibles. Esta es, por ejemplo, la definicin de
calidad de software que adopta el estndar IEEE 1061-1998 (IEEE,
1998b). Ver Figura 8
Figura 8. Software de CalidadLa anterior definicin coincide con
la nocin de calidad de los modelos ms clsicos como el de McCall, el
de Bohm o el que define el estndar de calidad ISO/IEC 9126.Factores
de calidad y productividadCalidad del productoEl modelo de calidad
de McCallEl Modelo de calidad de McCall fue creado para las fuerzas
areas norteamericana con la intencin de acercar las visiones de
calidad de los desarrolladores y los usuarios. Es de especial
importancia por ser histricamente el primero y la base de esfuerzos
posteriores, y se organiza en torno a tres tipos de caractersticas
de calidad. (Sanchez , Sicilia, & Rodrguez, 2012). Ver Figura
9Criterios de calidadFactores de calidadMtricas de calidad
Figura 9 .Tipos de caractersticas de calidad
Este modelo define tres perspectivas desde las que deben
estudiarse los once factores que en total se computan en la medida
de la calidad de un producto de software. Ver Figura 10
Calidad
Figura 10. Las tres perspectivas del modelo de calidad de
McCall
Estas perspectivas son las siguientes: Revisin del producto.
Esta perspectiva estudia la capacidad del producto para adaptarse a
los cambios. Se tienen en cuenta aquellos factores que influyen en
la capacidad de adaptacin del producto, tales como la facilidad de
mantenimiento (disposicin para ser modificado para ser corregido,
adaptado o ampliado), la flexibilidad (capacidad para introducir
cambios en funcin de las necesidades de negocio) y la facilidad de
evaluacin (capacidad de validar los requisitos establecidos para el
software. Transicin del producto. Esta perspectiva identifica los
factores de calidad que influyen la capacidad que tienen un cierto
software para adaptarse a distintos contextos de operacin. As,
tienen en cuenta factores tales como la reusabilidad, la
portabilidad o la interoperabilidad. Operacin del producto. Esta
perspectiva identifica aquellos factores de calidad que tienen que
ver con la forma en que el software lleva a cabo sus
funcionalidades, y la medida en la cual cumple con sus
especificaciones. As, tiene en cuenta la correccin (que las
funcionalidades solicitadas en su especificacin se encuentren
disponibles), la fiabilidad (qu fallos tiene el sistema en
operacin), la eficiencia en trminos de uso de recursos, la
integridad (proteccin contra accesos no autorizados a la
informacin) y la usabilidad. (Sanchez , Sicilia, & Rodrguez,
2012)Los once factores de calidad apuntados por McCall estn
organizados en las tres perspectivas mencionadas anteriormente. Ver
Figura 11
Figura 11. Factores de calidad del modelo de McCall
Para evaluar la calidad de un software, ser necesario medir
dichos factores, para lo cual el modelo establece el siguiente
proceso: Especificar los requisitos de calidad del producto
software a desarrollar, seleccionando aquellos aspectos que tengan
relacin con la calidad deseada. Establecer los factores de calidad
(de entre los once descritos) sobre los que aplican los requisitos
de calidad establecidos para el proyecto. Evaluar los factores
seleccionados mediante los criterios que el mtodo proporciona para
cada factor. (Sanchez , Sicilia, & Rodrguez, 2012)
Desarrollo de competencias. Actividad para el portafolio de
evidenciasActividad individual: Investigar las perspectivas y los
factores del modelo de calidad de McCall en otra fuente de
informacin.Actividad colaborativa: En triadas organizar la
informacin de las tres perspectivas con sus respectivos factores,
utilizar una estrategia didctica que les permita mostrar de la
mejor manera la informacin. Entregar la estrategia didctica
terminada al docente.
El modelo de BohmEl modelo de Bohm (1978) es otro modelo de
calidad basado en la identificacin de un cierto nmero de
caractersticas de calidad para el software. Posterior al modelo de
McCall, su aportacin fundamental es la definicin de lo que Bohm
denomina utilidades principales, un reconocimiento explcito de que
para ser considerado de calidad, un sistema de software debe ser
fundamentalmente til. Bohm plantea un modelo jerrquico en el que se
definen tres utilidades de alto nivel, que seran los requisitos
bsicos del software. Dichas utilidades son las siguientes: Utilidad
tal y como est, que representa hasta qu punto el software tal y
como est en este momento es fcil de usar, fiable y eficiente.
Facilidad de mantenimiento, que se concreta en la facilidad para
identificar qu es necesario modificar, as como la facilidad de
modificacin o de ejecucin de las pruebas sobre el elemento
modificado. Portabilidad, esto es, la facilidad para utilizar el
software en un nuevo entorno, distinto a aquel en que se est
utilizando en este momento.Estas tres utilidades representan el
primer nivel de la jerarqua del modelo. En el segundo nivel, se
identifican siete factores de calidad que se asocian con los tres
usos del primer nivel. (Sanchez , Sicilia, & Rodrguez, 2012).
Ver Figura 12Estos factores son los siguientes: Portabilidad, que
como ya se ha indicado, representa la facilidad para utilizar el
software en nuevos entornos (sistemas operativos, bases de datos,
etc.) Fiabilidad, que viene indicada por la ausencia de defectos.
Eficiencia, es decir, mnimo uso de recursos durante el correcto
funcionamiento del sistema. Usabilidad, entendida desde el punto de
vista de la ingeniera humana y la ergonoma, aunque comnmente se
resume como la facilidad de uso del software. Facilidad de
evaluacin, en concreto, la validacin de que el software cumple con
los requisitos establecidos. Comprensibilidad, o facilidad para
entender el propsito y estructura del software. Flexibilidad, esto
es, facilidad para modificar el software ante cambios en los
requisitos o aparicin de otros nuevos.
Utilidad general
Figura 12. Jerarqua del modelo de calidad de BohmAl igual que en
el modelo de McCall, el objetivo final es medir la calidad desde
los elementos de ms bajo nivel del modelo, y utilizar estas medidas
para mejorar los productos desarrollados. (Sanchez , Sicilia, &
Rodrguez, 2012)
Calidad del procesoEl Modelo CMMIEl Modelo CMMI, acrnimo del
ingls Capability Madurity Model Integration, es una evolucin de un
modelo anterior denominado CMM inicialmente desarrollado por el
Software Engineering Institute (SEI) de la Universidad Carnegie
Mellon. El SEI llev a cabo el encargo de desarrollar un modelo de
calidad que sirviera como base para establecer un sistema de
capacitacin de las compaas que suministraban software al gobierno
de los Estados Unidos. Dicho modelo fue definido como:Un enfoque
para la mejora de procesos que proporciona a una organizacin los
elementos esenciales para llevar a cabo sus procesos de manera
efectiva. Puede utilizarse para guiar la mejora de procesos en un
proyecto, en un departamento, o en una organizacin completa. CMMI
ayuda a integrar funciones de la organizacin tradicionalmente
separadas, a establecer prioridades y objetivos en la mejora de
procesos, proporciona guas para los procesos de calidad y sirve
como referencia para la evaluacin de los procesos actuales.
(Sanchez , Sicilia, & Rodrguez, 2012)CMMI no es un proceso de
desarrollo de software, son ms bien una gua que describe las
caractersticas que hacen efectivo a un proceso. CMMI se interesa
por la mejora de los procedimientos y mtodos (procesos) que las
personas de una organizacin llevan a cabo con ayuda de la tecnologa
y otras herramientas ya que, si los procesos no estn correctamente
definidos, son maduros y ampliamente conocidos, ni las personas ms
cualificadas sern capaces de rendir a su mejor nivel aun
disponiendo de las mejores herramientas. Ver Figura 13Figura 13. El
Modelo CMMIPara comprender lo que significa CMMI, es necesario
definir el concepto de modelo de madurez, nocin sobre la que CMMI
se asienta firmemente. Un modelo de madurez no es sino un conjunto
de caractersticas que describen ciertos aspectos de equilibrio,
experiencia y formalidad en una organizacin. Los modelos de
madurez, se emplean como referencia para la comparacin o la mejora.
El modelo de madurez de capacidades CMMI, se emplea para comparar
(y mejorar) el proceso de desarrollo de software de una organizacin
describiendo una progresin continua en cinco niveles Ver Figura
14Cada uno de los niveles define, por un lado, la escala de medida
de la capacidad de los procesos de la organizacin, y por otro, los
objetivos que ayudarn a la organizacin a ordenar sus esfuerzos de
cara a mejorar sus procesos. En el nivel ms bajo dela escala se
encuentran aquellas organizaciones sin procesos repetibles, donde
gran parte del trabajo se realiza sin procedimientos prestablecidos
y a medida (ad hoc) para cada proyecto al que se enfrentan. En el
nivel ms alto, las organizaciones que usan procesos definidos y
repetibles, que aplican mtricas para la mejora continua de sus
procesos y que, en definitiva, estn continuamente en busca de hacer
las cosas mejor. (Sanchez , Sicilia, & Rodrguez,
2012)OptimizacinGestionadoDefinidoRepetibleInicial
Figura 14. Niveles de madurez en CMMICMMI sirve adems para
certificar el nivel en el que se encuentra una organizacin o rea de
procesos, lo cual es interesante desde el punto de vista de las
organizaciones, tanto para su prestigio como entidades certificadas
CMMI en los niveles ms altos, como para optar a contratos en cuyos
pliegos de condiciones se solicite como requisito de concurso la
demostracin de un nivel determinado. Representacin por etapas. En
este modo de representacin mediante niveles de madurez CMMI define
cinco niveles en los que una organizacin puede categorizarse de
acuerdo con la disposicin global de sus procesos internos. Es
decir, no se enfoca a un rea en particular como la representacin
mediante niveles de capacitacin, sino que se refiere a mltiples
reas de procesos. Los cinco niveles que define CMMI son los
siguientes: Nivel 1 (inicial), en este nivel se encuentran aquellas
organizaciones en las que no existen reas de proceso y en las que,
por lo tanto, los procesos no estn definidos. Aunque este nivel, a
menudo, se etiqueta como nivel de procesos ad hoc o caticos, esto
no quiere decir que no haya procesos en la organizacin que se
lleven a cabo de manera controlada, sino simplemente que no estn
definidos de antemano y que, por tanto, no puede sumirse que
siempre se realizarn de manera predecible. En estas organizaciones
es frecuente, o al menos ms probable que en organizaciones que se
sitan en niveles superiores, el abandono de un proceso en momentos
de crisis o la incapacidad para repetir xitos anteriores. Nivel 2
(Repetible), la organizacin ha establecido las actividades de
gestin de proyectos, lo que le confiere la capacidad de repetir
procesos con resultados consistentes. Sin embargo, los procesos
pueden no repetirse para todos los proyectos de la organizacin ya
que no existe una disciplina rigurosa sobre los mismos. Nivel 3
(Definido), las organizaciones que se encuentran en el nivel 3
tienen documentados y estandarizados todos sus procesos de
desarrollo y mantenimiento de software, y dichos procesos estn
sujetos a algn tipo de mejora continua. Todos los proyectos de la
organizacin se llevan a cabo de acuerdo con los procedimientos
establecidos. Nivel 4 (gestionado), las organizaciones tienen un
programa detallado y organizado de medicin de procesos de
desarrollo de software. Los procedimientos de gestin para ajustar y
adaptar los procesos a las particularidades de cada proyecto que se
aborde son pblicos y estn documentados. Nivel 5 (optimizacin),
describe a aquellas organizaciones que tienen completamente
implementado un proceso de mejora continua para todos sus procesos,
recopilan datos de todos sus proyectos, y el estudio de dichos
datos lo emplean en la mejora e innovacin de los propios procesos
de la organizacin.Los diferentes niveles de madurez descritos estn
estrechamente relacionados con lo que CMMI denomina reas de
proceso. (Sanchez , Sicilia, & Rodrguez, 2012)Representacin
contina. La representacin mediante niveles de capacitacin consiste
en la definicin de objetivos y prcticas generales para cada rea de
procesos. Estos niveles pueden considerarse, por tanto, un medio
para mejorar progresivamente los procesos de una cierta rea. CMMI
define seis niveles de capacitacin, etiquetados de 0 a 5: Nivel 0
(Incompleto), un proceso que no se lleva a cabo, o que se lleva a
cabo parcialmente Nivel 1 (Realizado), proceso que satisface los
objetivos especficos del rea a que pertenece Nivel 2 (Gestionado),
el proceso se planifica y ejecuta de acuerdo con ciertas
reglamentaciones, emplea personal cualificado, se monitoriza y
controla. Nivel 3 (Definido), el proceso se ajusta a los estndares
de la organizacin y proporcionan, tanto medidas de la produccin
como otras informaciones valiosas desde la perspectiva de la mejora
de procesos. Nivel 4 (Gestionado cuantitativamente), un proceso
definido que adems, es controlado mediante tcnicas cuantitativas o
estadsticas. Nivel 5 (En optimizacin), un proceso gestionado
cuantitativamente sujeto a mejoras basadas en la comprensin de las
causas de la variabilidad inherente al propio proceso.CMMI es hoy
en da un modelo prestigios y ampliamente difundido, por lo que la
certificacin en cualquiera de los niveles, especialmente en los ms
altos, es exhibida por las organizaciones como un importante
marchamo de calidad. (Sanchez , Sicilia, & Rodrguez, 2012)El
estndar ISO 9000Los estndares de la familia ISO 9000. El
calificativo genrico ISO 9000 designa a un conjunto de estndares
para sistemas de gestin de la calidad. Aunque, desde sus inicios en
los aos 1980, algunas de las normas originales han desaparecido por
pura evolucin natural, las ms relevantes y conocidas han
permanecido, aunque no siempre sus actuales nombres significan lo
mismo que significaban anteriormente. Hoy en da existen dos normas
en esta familia: el estndar ISO 9000 publicado en 2000, y el
estndar ISO 9001 publicado en 2005. ISO 9000 cubre los fundamentos
de los sistemas de gestin de calidad y define los trminos
relacionados con la misma ISO 9001 especifica los requisitos de un
sistema de gestin de la calidad dentro de una organizacin.Las
normas dela serie ISO 9000 tienen como meta ayudar a las
organizaciones a definir y mantener sistemas de calidad. Es
importante apuntar que, a diferencia del Modelo CMMI, la familia de
normas ISO 9000 no tiene nada que ver con programas de
aseguramiento de la calidad. Estas normas han sido diseadas , por
el contrario, para definir los requisitos que debe cumplir una
organizacin con un buen sistemas de gestin de la calidad, aunque no
se especifica qu deben hacer las organizaciones para alcanzar tales
fines. Su objetivo primordial es por tanto la consistencia en la
calidad de los productos y servicios, junto con una continua mejora
en la satisfaccin del cliente y en la disminucin de los ratios de
error. Ver Figura 15Gestin de recursos
CLIENTERequisitosSatisfaccinCLIENTE
Responsabilidad de la gestin
Gestin del sistemaMejora del anlisis de medidas
Realizacin de productos y servicios
SalidasEntradas
Figura 15. Sistema de gestin de calidad segn la norma ISO
9000
Dado que se trata de normas genricas, aplicables, por tanto, a
un amplio abanico de organizaciones, la forma y los mtodos de
implementar el sistema de calidad pueden variar tremendamente de
unas organizaciones a otras. No obstante todas deben compartir los
siguientes principios: Orientacin al cliente. Las organizaciones
dependen de sus clientes y por tanto, deben luchar por colmar e
inclusive superar sus expectativas. Liderazgo. Los niveles
superiores de gestin de la organizacin deben definir polticas de
calidad y crear un entorno en el cual el personal se comprometa
completamente con los objetivos de calidad. Implicacin de los
empleados. Los trabajadores, el mayor capital con que cuenta una
organizacin, solo emplearn todas sus capacidades y aptitudes en
beneficio de la organizacin si estn completamente involucrados en
el proceso de calidad. Modelo de procesos. Los resultados esperados
solo se alcanzarn si las actividades y los recursos pertinentes se
gestionan y controlan como procesos. Modelo de gestin orientado a
sistemas. Las organizaciones en las que es claramente reconocido,
gestionado y controlado el enlace entre los procesos que conforman
el sistema completo, estn mejor situadas para alcanzar sus
objetivos eficientemente. Mejora continua. La mejora continua del
rendimiento global de la organizacin es el objetivo ltimo. Enfoque
a la toma de decisiones objetiva. Las decisiones se basan en el
anlisis de datos e informacin. Relaciones con los proveedores
mutuamente interdependientes. La organizacin depende de sus
proveedores, por lo que las relaciones debern basarse en el mutuo
beneficio. (Sanchez , Sicilia, & Rodrguez, 2012)Las
organizaciones certificadas de acuerdo a los estndares de calidad
ISO 9000 pueden lucir el distintivo que reconoce su consistencia,
fiabilidad, valor y servicio al cliente de cara al exterior. Se
trata de un distintivo muy ampliamente difundido y conocido, y cuya
obtencin suelen ostentar las organizaciones, en general, como
marchamo de calidad ante sus clientes y pblico en general. Todos
los requisitos y recomendaciones de esta familia de estndares son
genricos y por tanto, aplicables a cualquier tipo de organizacin,
independientemente de su tamao, tipo y sector productivo.Otros
modelos, estndares y especificaciones. Adems de los anteriormente
reseados, existen otros mtodos, estndares y especificaciones de
algn u otro modo relacionados con la calidad en el software.
ITILITIL. Information Technology Infraestructure Library, es el
modelo de gestin de servicios de tecnologas de la informacin ms
aceptado actualmente. Est formado por un conjunto de documentos de
buenas prcticas para facilitar la implementacin de un marco de
gestin de este tipo de servicios. Inicialmente creado por el
gobierno del Reino Unido a travs de su Oficina de Comercio (OGC),
en la actualidad se utiliza en todo el mundo. (Sanchez , Sicilia,
& Rodrguez, 2012)
ITIL comprende cinco volmenes, cada uno de ellos dedicado a una
disciplina especifica dentro de la gestin de servicios de
tecnologas de la informacin. As, uno define la estrategia del
servicio, otro el diseo del servicio, otro la transicin de
servicios, y los dos restantes se dedican a la operacin de los
servicios y a la mejora continua de los mismos,
respectivamente.ITIL divide la gestin de servicios en dos reas
principales: Los servicios de soporte estn formados por las
prcticas que permiten la presentacin de los servicios de tecnologas
de la informacin, y sin las cuales sera imposible proporcionar
dichos servicios. Engloba la gestin de la configuracin, la gestin
de incidencias, la gestin de cambios, el soporte tcnico al usuario,
el control de versiones y la gestin de problemas. La prestacin de
servicios tiene que ver con los servicios que las organizaciones
requieren de sus proveedores para as poder dar a su vez servicios
de negocio a sus usuarios. Engloba la gestin de los niveles de
servicio, la gestin de la capacidad y de la continuidad de la
prestacin de servicio, la gestin de la disponibilidad y finalmente
la gestin financiera.
El proceso de software personal (PSP). PSP es un proceso de
mejora de procesos de software diseado para controlar, gestionar y
mejorar la forma de trabajo individual de los ingenieros del
software. Aplicacin de las ideas de CMMI al trabajo individual, fue
creada por Watts Humphrey a partir de sus investigaciones y su
experiencia en la aplicacin de los principios de CMMI. Su conclusin
ms importante fue que los principios del modelo son aplicables, no
slo a las reas o a las organizaciones en su conjunto, sino tambin a
los individuos. (Sanchez , Sicilia, & Rodrguez, 2012)El
principal objetivo de PSP es introducir disciplina en el proceso de
desarrollo de software de cada individuo, para lo cual describe
prcticas para el desarrollo individual de programas pequeos, desde
la asignacin del problema hasta las pruebas de unidad.La lgica
fundamental que gua el modelo PSP es que una persona entiende mejor
lo que hace cuando define claramente el proceso que lleva a cabo,
mide y controla su propio trabajo, se evala y aprende de la propia
experiencia. El modelo se basa en los siguientes cinco principios:
Un proceso definido y estructurado mejora la eficiencia en el
trabajo. El proceso personal definido debe alinearse con las
habilidades y preferencias del individuo. Cada persona se debe
involucrar en la definicin de su proceso. El proceso de cada
persona debe evolucionar segn evolucionan sus habilidades y
capacidades. La mejora continua del proceso se consigue si existe
una retroalimentacin rpida y explcita.Un ejemplo concreto de estos
estudios es la disminucin del retraso de un proyecto (medido en
meses) respecto al calendario inicialmente previsto, en funcin del
modelo de procesos empleados por la organizacin que lleva a cabo el
desarrollo. Ver Figura 16
Figura 16. PSP en combinacin con CMMI (Fuente: AIS, Advanced
Information System)
Team Software Process (TSP).Team Software Process (TSP). Si el
objetivo del PSP es hacer que los profesionales del software tomen
conciencia y control de su trabajo, los objetivos del TSP (proceso
de software para equipos, creado tambin por Watts Humphrey) son
proporcionar un entorno de trabajo en equipo de soporte al proceso
de software personal y que ayude a construir y mantener equipos de
trabajo autodirigidos.PSP y TSP se constituyen, pues, en dos
potentes metodologas orientadas fundamentalmente a alcanzar mejores
resultados en la produccin de software y, en definitiva, a
proporcionar a los individuos y equipos el grado de compromiso y
formacin necesarios para realizar con xito proyectos de
software.Los objetivos de mejora continua de procesos segn Humphrey
deben enfocarse en paralelo desde tres niveles distintos: La
organizacin, para lo cual lo ideal es utilizar CMMI Los equipos de
trabajo, para lo cual propone TSP Los ingenieros del software, para
lo cual propone PSPTSP est enfocado principalmente a la formacin y
gestin de los equipos de trabajo. Utilizando este modelo, una
organizacin debe construir equipos autnomos que planifiquen y hagan
seguimiento de su trabajo, estableciendo sus propios objetivos y
gestionando sus procesos.El funcionamiento integrado de PSP y TSP
se resume en lo siguiente: si se desea tener equipos con las
habilidades necesarias para auto gestionar sus procesos, sus
miembros deben contar con ciertas habilidades individuales. La
formacin dentro de los equipos es, por tanto, esencial. Adems, la
creacin de mdulos de software es una tarea individual, si bien la
elaboracin y posterior entrega de mdulos integrados es una labor de
equipo, no slo de codificacin, sino tambin de integracin,
verificacin, etc. En definitiva, el software es producto del
trabajo de un equipo cuya capacidad, disciplina y compromiso son
claves para el xito del proyecto. (Sanchez , Sicilia, &
Rodrguez, 2012). Ver Figura 17TSPPSP
Figura 17. Elementos de PSP y TSP para la mejora continua de
procesos
Desarrollo de competencias. Actividad para el portafolio de
evidenciasActividad Colaborativa En triadas investigar a nivel
mundial, nacional y regional cuales empresas en el rea de sistemas
cumple con El Modelo CMMI y cul es el nivel que cumple. Realizar
una estrategia didctica para representar la informacin
investigada.Actividad Individual Consultar la pgina
www.chihuahuaitpros.org. Lee el documento: Mitos, creencias y
supersticiones sobre la calidad del software y de su enseanza el
autor Adolfo Guzmn-Arenas. Elaborar un ensayo sobre el documento
ledo del autor Adolfo Guzmn-Arenas.
Enfoque de la Ingeniera dentro de la informtica.La Ingeniera
Informtica como conceptoLa Ingeniera Informtica es una de las ramas
ms recientemente desarrolladas de la Ingeniera. El propsito de
cualquier ingeniera es la aplicacin de las ciencias a la resolucin
de problemas reales. El conocimiento y los mtodos cientficos son ms
una herramienta para la Ingeniera que un fin en s mismos. En sus
primeros balbuceos all por los aos treinta y cuarenta del siglo XX
la informtica surgi como respuesta a necesidades de otras ramas de
la ciencia y la ingeniera, de modo que ha ido movindose en un
terreno prximo a ellas, intentando al mismo tiempo afianzar su
propia naturaleza. Por esta razn es habitual encontrar varios
puntos de enfoque para definir la misma dependiendo de su
proximidad a una u otra.Tecnologa de los sistemas fsicos en
informticaLa evolucin histrica de la Ingeniera Informtica ha
influido poderosamente en la visin de los fundamentos fsicos de la
misma, que han ido reorientando paulatinamente su perfil desde el
punto de vista temtico. La Ingeniera pretende dar un soporte
explicativo, constructivo y aplicativo a la Informtica. Las
diferentes ramas de la Ingeniera presentan un claro perfil comn:
entender claramente el problema a resolver, conocer las
herramientas adecuadas para su resolucin, demostrar maestra y
puesta al da en el uso de las mismas, especificar claramente los
objetivos de la solucin a aplicar, saber planificar las soluciones,
gestionar, seguir y desarrollar el proyecto acorde al plan de
trabajo y coste, evaluar, redisear y mantener. La eficiencia y la
eficacia, junto con la sencillez, compactacin y economa de las
soluciones son al mismo tiempo las lneas gua y los marchamos que
definen la calidad de cualquier solucin aportada. El perfil de
ingeniera que la Informtica demanda aparece en varios niveles. Es
detectable en la especificacin, implementacin y mantenimiento de
servicios y aplicaciones informticas complejas. Est presente en las
metodologas de desarrollo de programas. Aparece en la concepcin
arquitectnica y estructural de los sistemas informticos. (Gmez
Vilda, 2006)Desde un punto de vista fsico, la Tecnologa de los
Sistemas Informticos se basa en el conocimiento de los fenmenos
electromagnticos que permiten el funcionamiento de los circuitos de
procesado y de los sistemas de almacenamiento de la informacin.
Desde un punto de vista tecnolgico, el enfoque se orienta hacia los
materiales soporte, los mtodos constructivos, el anlisis del todo a
la parte (top-down), la sntesis de la parte al todo (bottom-up), la
validacin, el anlisis de prestaciones, y la aplicabilidad de los
sistemas.
Tendencias en la Ingeniera de Software.La investigacin y el
desarrollo de tcnicas y mtodos de ingeniera del software son
constantes y suelen suponer interesantes avances en la resolucin de
problemas de desarrollo de software. Sin embargo, es habitual que
en la prctica diaria profesional no se incluya prcticamente ninguna
de las recomendaciones ms elementales de la ingeniera del software.
De hecho, las evaluaciones de los procesos productivos de software
realizadas a raz de los modelos de procesos de software (Por
ejemplo, con CMM) confirman que el desarrollo de software suele
estar bsicamente en estado catico. Y no slo en, como uno podra
pensar, pequeas organizaciones de un pas como el nuestro sino en
tambin en las empresas adjudicatarias de interesantes contratos de
defensa de pases avanzados como Estados Unidos o Japn. Si bien
estos modelos de evaluacin an acumulan distintas acusaciones de
rigidez o falta de contraste emprico, los resultados obtenidos en
sus evaluaciones resultan consistentes con la sensacin de constante
apagafuegos que suelen sufrir los profesionales del software.
Tambin suelen revelar la prctica despreocupacin de los responsables
de las organizaciones de software por la mejora de la calidad de
sus procesos de trabajo o de sus productos. (Fernndez Sanz,
2000).Lamentablemente, la gestin de los requisitos y de la
planificacin no se realiza en las mejores condiciones para los
analistas y jefes de proyecto. Por otra parte, actualmente las
empresas se quejan de la carencia de profesionales cualificados
para cubrir sus necesidades de personal (que, en muchos casos, se
ha disparado con la explosin de Internet).As, el informe de IDC
para Microsoft indica la falta de hasta 1,200.000 profesionales
relacionados con las TIC (Tecnologas de la Informacin y de las
Comunicaciones) . Otras informes manejados por Cisco tambin
confirman esta tendencia. Es de esperar que las necesidades de
personal no fomenten precisamente que todos los nuevos
profesionales lleguen a la empresa con los conocimientos apropiados
de ingeniera del software para solventar los problemas de
desarrollo de aplicaciones. De hecho, habr que incluir personas que
prcticamente no cuenten con casi ningn tipo de formacin informtica
y a quienes ser difcil transmitir ciertas tcnicas y recomendaciones
para un buen desarrollo de software.Es necesario que el ingeniero
de software sea, ante todo, ingeniero y que sea capaz de trasladar
con sentido prctico los conocimientos cientficos de la informtica
al desarrollo y mantenimiento de software. Esto obliga a que el
ingeniero de software aporte soluciones reales a los problemas
diarios de las organizaciones de software, lo que puede suponer
agregar a los conocimientos estrictamente tcnicos, habilidades y
formacin en aspectos de gestin, economa, legislacin, etc.
Evidentemente el proyecto SWEBOK (Software Engineering Body of
Knowledge: http://www.swebok.org) actualmente en marcha con el
apoyo del IEEE y de la ACM puede ayudar a determinar mejor el
conjunto de conocimientos de la ingeniera del software y constituir
una base de trabajo para la formacin de profesionales.La tendencia
actual se orienta a la formulacin de guas generales que requieren
de la experiencia y la capacidad de anlisis de los ingenieros de
software para su adaptacin a cada proyecto o situacin concreta. En
el caso del proceso de desarrollo, las metodologas se entienden ms
como indicaciones genricas que como rgidos esquemas como los
propuestos en los aos ochenta. As, hablamos sobre todo de procesos
(por ejemplo, el Unified Process y ciclos de vida genricos y
flexibles (por ejemplo, ciclos iterativos) y de la organizacin de
los procesos mediante grandes lneas de evaluacin y mejora (por
ejemplo, SPICE). En el caso de las tcnicas de desarrollo, la
tendencia apunta a heursticas y guas formuladas ms como patrones y
frameworks que como mtodos con pasos muy detallados. En definitiva,
se sigue ms bien el esquema de identificar buenas prcticas (best
practices) genricas cuya aplicacin inteligente depende de los
ingenieros de software y los jefes de proyecto. (Fernndez Sanz,
2000)
Un futuro ideal para los desarrolladores de software, podra ser
en el que: La planificacin de los proyectos se hace con rigor y est
bien ajustada a la complejidad y tamao de las aplicaciones y de sus
requisitos. Las especificaciones son el producto de un exhaustivo y
slido trabajo de interaccin con el cliente/usuario y cuentan con su
aprobacin, incluido el acuerdo sobre los criterios de aceptacin de
la aplicacin. Se cuenta con colecciones de componentes, funciones,
etc. realmente controlados, especificados y gestionados que
solventan buena parte de la generacin del cdigo, pasando los
ingenieros de software a efectuar tareas de diseo ms relacionadas
con la arquitectura del software. En todo el desarrollo, el jefe de
proyecto cuenta con una cuidada seleccin de medidas e indicadores
que le permiten conocer y controlar en todo momento el estado real
del trabajo. Y tantas ideas ms que identificamos con hacer bien las
cosas y que a todos nos gustara disfrutar ya porque son factibles.
(Fernndez Sanz, 2000)
Actividad Individual Consultar el blog
www.portinos.com/9308/siemens-plm-amplia-su-alcance, analizar su
contenido. Realizar un ensayo con la lectura incluida en el
blog.
