CARACTERSTICAS DEL SOFTWARE

Para poder comprender lo que es el software (y consecuentemente la ingeniera del software), es importante
examinar las caractersticas del software que lo diferencian de otras cosas que los hombres pueden construir. Cuando
se construye hardware, el proceso creativo humano (anlisis, diseo, construccin, prueba) se traduce finalmente en
una forma fsica. Si construimos una nueva computadora, nuestro boceto inicial, diagramas formales de diseo y
prototipo de prueba,evolucionan hacia un producto fsico (chips, tarjetas de circuitos impresos, fuentes de
potencia,etc.).El software es un elemento del sistema que es lgico, en lugar de fsico. Por tanto el software tiene
unas caractersticas considerablemente distintas a las del hardware:
1. El software se desarrolla, 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 (vase el Captulo 7).
Ambas actividades requieren la construccin de un producto pero los enfoques son diferentes. Los costes del
software se encuentran en la ingeniera. Esto significa que los proyectos de software no se pueden gestionar como si
fueran proyectos de fabricacin.
2. El software no se estropea.
La Figura 1.1 describe, para el hardware, la proporcin de fallos como una funcin del tiempo. Esa relacin,
denominada frecuentemente curva de baera, indica que el hardware exhibe relativamente muchos fallos al
pnncipio 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 caehasta un nivel estacionario (bastante bajo, con un poco de optimismo)
donde permanece duranteun cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, el hardware empieza
adesgastarse y la tasa de fallos se incrementa.El software no es susceptible a los males del entorno que hacen que el
hardware se estropee. Portanto, en teora, la curva de fallos para el software tendra la forma que muestra la Figura
1.2. Losdefectos no detectados harn que falle el programa durante las primeras etapas de su vida. Sin embargo, una
vez que se corrigen (suponiendo que no se introducen nuevos errores)la curva se aplana, como se muestra. La curva
idealizada es una gran simplificacin de los modelos reales defallos del software. Sin embargo la implicacin es
clara, el software no se estropea. Pero sedeteriora!Esto que parece una contradiccin, puede comprenderse mejor
considerando la curva actualmostrada en la Figura 1.2. Durante su vida, el software sufre cambios
(mantenimiento). Conformese hacen los cambios, es bastante probable que se introduzcan nuevos defectos, haciendo
que lacurva de fallos tenga picos como se ve en la Figura 1.2.
Antes de que la curva pueda volver alestado estacionario original, se solicita otro cambio, haciendo que de nuevo se
cree otro pico.Lentamente, el nivel mnimo de fallos comienza a crecer -e1 software se va deteriorando debido alos
cambios-. Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software.Cuando un componente
de hardware se estropea se sustituye por una pieza de repuesto. No haypiezas 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, elmantenimiento del software
tiene una complejidad considerablemente mayor que la delmantenimiento del hardware.
3. Aunque la industria tiende a ensamblar componentes, la mayora del software se construye amedida.
Consideremos la forma en la que se disea y se construye el hardware de control para unproducto basado en
computadora. El ingeniero de diseo construye un sencillo esquema de lacircuitera digital, hace algn anlisis
fundamental para asegurar que se consigue la funcinadecuada y va al armario donde se encuentran los catlogos de
componentes digitales.Despus de seleccionar cada componente, puede solicitarse la compra.
Amedida que la disciplina del software evoluciona, se crea un grupo de componentes de diseoestndar. Tornillos
estndar y circuitos integrados preparados para la venta son solamente losdos mil componentes estndar que utilizan
ingenieros mecnicos y elctricos cuando diseannuevos sistemas. Los componentes reutilizables se han creado para
que el ingeniero puedaconcentrarse en elementos verdaderamente innovadores de un diseo, por ejemplo, las
partesdel diseo que representan algo nuevo. En el mundo del hardware, la reutilizacin decomponentes es una parte
natural del proceso de ingeniera.En el mundo del software es algo que slo ha comenzado a lograrse en una escala
amplia. Elcomponente de software debera disearse e implementarse para que pueda volver a serreutilizado en
muchos programas diferentes. En los aos 60, se construyeron bibliotecas desubrutinas cientficas reutilizables en
una amplia serie de aplicaciones cientficas y de ingeniera.Esas bibliotecas de subrutinas reutilizaban de forma
efectiva algoritmos bien definidos, perotenan un dominio de aplicacin limitado. Hoy en da, hemos extendido
nuestra visin dereutilizacin para abarcar no slo los algoritmos, sino tambin estructuras de datos.
Loscomponentes reutilizables modernos encapsulan tanto datos como procesos que se aplican a losdatos,
permitiendo al ingeniero del software crear nuevas aplicaciones a partir de las partesreutilizables. Por ejemplo, las
interfaces grficas de usuario de hoy en da se construyenfrecuentemente a partir de componentes reutilizables que
permiten la creacin de ventanasgrficas, de mens desplegables y de una amplia variedad de mecanismos de
interaccin.
1.2.2. Aplicaciones del software
Software de sistemas.
Software de tiempo real.
Software de gestin
Software de ingeniera y cientfico
Software empotrado.
Software de computadoras personales

Software basado en Web Software de inteligencia artificial.
Mitos del Software
Muchas de las causas de la crisis del software se pueden encontrar en una mitologa que surge durante los primeros
aos del desarrollo del software.
A diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta,
los mitos del software propagaron informacin errnea y confusin. Los mitos del software tienen varios atributos
que los hacen insidiosos: por ejemplo, aparecieron como declaraciones razonables de hechos (algunas veces
conteniendo elementos verdaderos), tuvieron un sentido intuitivo y frecuentemente fueron promulgados por expertos
que estaban al da.
Mitos de gestin.
Los gestores con responsabilidad sobre el software, como los gestores en la mayora de las disciplinas, estn
normalmente bajo la presin de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.
Igual que se agarra al vaco una persona que se ahoga, un gestor de software se agarra frecuentemente a un mito del
software, aunque tal creencia slo disminuya la presin temporalmente
.Mito
.Tenemos ya un libro que est lleno de estndares y procedimientos para construir software, no le proporciona ya a
mi gente todo lo que necesita saber?
Mito
.Mi gente dispone de las herramientas de desarrollo de software ms avanzadas, despus de todo, les compramos las
computadoras ms modernas
.Mito.
Si fallamos en la planificacin, podemos aadir ms programadores y adelantar el tiempo perdido (el llamado
algunas veces concepto de la horda Mongoliana)
.Mitos del Cliente.
Un cliente que solicita una aplicacin de software puede ser una persona deldespacho de al lado, un grupo tcnico
de la sala de abajo, el departamento de ventas o unacompaa exterior que solicita un software bajo contrato. En
muchos casos, el cliente cree en losmitos que existen sobre el software, debido a que los gestores y desarrolladores
del softwarehacen muy poco para corregir la mala informacin. Los mitos conducen a que el cliente se creeuna falsa
expectativa y, finalmente, quede insatisfecho con el que desarrolla el software.
Mito.
Una declaracin general de los objetivos es suficiente para comenzar a escribir los programas -podemos dar los
detalles ms adelante-
.Mito.
Los requisitos del proyecto cambian continuamente, pero los cambios pueden a como darse fcilmente, ya que el
software es flexible.

Los mitos en los que an creen muchos desarrolladores se han ido fomentando durante50 aos de cultura
informtica. Durante los primeros das del desarrollo del software, laprogramacin se vea como un arte. Las viejas
formas y actitudes tardan en morir.
Mito.
Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.Realidad.
Alguien dijo una vez: cuanto ms pronto se comience a escribir cdigo, ms se tardaren terminarlo. Los datos
industriales [LIE80, JON91, PUT971 indican que entre el 60 y el 80 porciento de todo el esfuerzo dedicado a un
programa se realizar despus de que se le hayaentregado al cliente por primera vez.
Mito
.Hasta que no tengo el programa ejecutndose, realmente no tengo forma de comprobar su calidad.
Mito
.Lo nico que se entrega al terminar el proyecto es el programa funcionando.
capas de la ingenieria de software
martes 25 de septiembre de 2007
Ingenieria de Software
Es la suma total de los programas de computadora, procedimientos, reglas, la documentacin
asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto
de software es un producto diseado para un usuario". En este contexto, la Ingeniera de Software
(SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin,
mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de
Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las
matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los
problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos
correctos, utilizables y costo-efectivos"
Capas Ingeniera De Software
La ingeniera de software es una tecnologa multicapa, cualquier enfoque de ingeniera debe
apoyarse sobre un compromiso de organizacin de calidad.
El fundamento de la ingeniera de software es la capa del proceso. El proceso de la ingeniera de
software es la unin que mantiene juntas las capas de tecnologa y que permiten un desarrollo
racional y oportuno de la ingeniera de software.
El proceso define un marco de trabajo para un conjunto de reas clave de proceso que se deben
establecer para la entrega de la tecnologa de la ingeniera de software.
Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo,
construccin de programas, pruebas y mantenimiento.
Las herramientas de la ingeniera de software proporcionan un enfoque automtico o
semiautomtico para el proceso y para los mtodos.
Enfoque en capas
Herramientas.- proporcionan un soporte automtico o semi automtico a los procesos y
a los mtodos.
Mtodos.- indican cmo construir tcnicamente el software
Procesos.-son el fundamento de la ingeniera de software.
Un enfoque de Calidad.- son la base o cimientos de la ingeniera de software.

Coordinador de Investigacin: ING. JOSE ANTONIO FLORES LARA


Tecnologico ITSZO el diseo de software se realiza a tres niveles: conceptual, lgico y
fsico.


Figura 2. Arquitectura lgica de tres capas de una aplicacin cliente/servidor
Para mayor informacin consulta las siguiente direccin electrnica:
Herramientas de Ingeniera de Software Aqu encontrars informacin sobre las
herramientas lderes que implementan la ingeniera de software, desde el modelado de
sistemas con UML hasta el proceso unificado que tiene que ver con la administracin de
proyectos.
SourceForge.net Es una base de datos de proyectos de software de cdigo abierto u
open source software.
Un ingeniero de software necesita de herramientas, entre ellas las herramientas de
Rational son las ms avanzadas, pero son muy costosas. Tambin puede utilizar las
herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas
de ellas son de cdigo abierto y an estn de desarrollo. Utiliza las que ms te sean de
utilidad.
Diseo Conceptual
El diseo conceptual se considera como un anlisis de actividades y consiste en la
solucin de negocios para el usuario y se expresa con los casos de uso. El diseo
lgico es la solucin del equipo de proyecto del negocio y consiste de las siguientes
tareas:
Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la informacin
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa
Una forma de obtener estos requerimientos es construir una matriz usuarios-
actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal
manera que se obtenga quin, qu, cundo, dnde y por qu de la solucin.
Diseo Lgico
El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un
conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte
en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es
independiente de la tecnologa. El diseo lgico refina, organiza y detalla la solucin de
negocios y define formalmente las reglas y polticas especficas de negocios.
Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades
esenciales de algo de inters.
Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo
siguiente:
Ser seguro, lo que equivale a un uso correcto y con autorizacin
Ser vlido, qu tareas o reglas se pueden aplicar
Manejar excepciones, informando al cliente
Contar con un catlogo de servicios que constituye un repositorio de servicios.
Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los
mdulos operen como unidades completas de trabajo. Las tareas de verificacin
incluyen:
Una verificacin independiente:
o Pre y post condiciones
o Lgica y funcionalidad individual
Una verificacin dependiente:
o Verificacin de dependencias
o Que operan como una unidad especfica de trabajo
El diseo lgico comprende las siguientes tareas:
Identificar y definir los objetos de negocio y sus servicios
Definir las interfases
Identificar las dependencias entre objetos
Validar contra los escenarios de uso
Comparar con la arquitectura de la empresa
Revisar y refinar tanto como sea necesario
Para definir los objetos de negocios y sus servicios se puede usar la tcnica de anlisis
nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-
verbo-objeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos
a objetos de negocio y los verbos activos son los candidatos a servicios.
Una interfase tiene las siguientes partes:
Nombre
Precondiciones, lo que debe estar presente antes de ejecutarse
Postcondiciones, estado final
Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica)
Dependencias
La tarea de identificar las dependencias entre objetos permite identificar eventos,
sucesos o condiciones que permitan la realizacin de tareas de negocios
coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:
Identificar los eventos disparadores (triggers)
Determinar cualquier dependencia (existencial o funcional)
Determinar cualquier problema de consistencia o secuencia
Identificar cualquier regulacin de tiempo crtica
Considerar algn problema organizacional (transacciones)
Identificar y auditar los requerimientos de control
Determinar lugares y dependencias a travs de la ubicacin
Determinar cuando el servicio que controla la transaccin es dependiente de los
servicios contenidos en otros objetos de negocio
La validacin del modelo lgico debe ser tal que ste sea:
Completo debe representar todos los escenarios de uso,
Correcto el comportamiento lgico debe corresponder con el comportamiento
conceptual, y
Claro los objetos de negocio y servicios no deben ser ambiguos
En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de
que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa
cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de
usuario, servicios de negocio y servicios de datos.
Los servicios de usuario (user services) controlan la interaccin. Un servicio de
usuario son personas, aplicaciones, otros servicios o la combinacin de stos.
Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual
(mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin.
El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar
la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar
al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la
comunicacin.
Los servicios de negocio (bussines services) convierten datos recibidos de los
servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden
usar otros servicios de negocio para completar su tarea.
Las tareas de los servicios de negocio son:
Dar formato a los datos
Obtener y mover datos desde y hasta los servicios de datos
Transformar los datos en informacin
Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada
la transaccin.
Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los
servicios de negocio y son de una amplia gama de categoras como las siguientes:
Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado,
SQL, APIs)
Respaldo y recuperacin (recuperacin de datos si un evento falla)
Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes,
formacin de un conjunto de resultados)
Insercin, actualizacin y borrado (procesar modificaciones consistentemente
transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva
integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez
completada, sta sobrevive).
Bloqueo (permite al acceso concurrente a los datos)
Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar
el estado de los datos antes de aceptarlos, manejo de errores)
Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y
servicios)
Administracin de la conexin (mecanismos bsicos para establecer una sesin de los
servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin
y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional,
transaccional, multiusuario, monousuario).
Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin,
bases de datos heterogneas, segn la topologas de la red).
Diseo fsico
El diseo fsico traduce el diseo lgico en una solucin implementable y costo-
efectiva o econmica.
El componente es la unidad de construccin elemental del diseo fsico. Las
caractersticas de un componente son:
Se define segn cmo interacta con otros
Encapsula sus funciones y sus datos
Es reusable a travs de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes
En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser
tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda
proveer de una funcionalidad compleja pero de control genrico) y la agregacin y
contencin (un componente puede reusar utilizando tcnicas de agregacin y
contencin, sin duplicar cdigo).
El diseo fsico debe involucrar:
El diseo para distribucin debe minimizarse la cantidad de datos que pasan como
parmetros entre los componentes y stos deben enviarse de manera segura por la red.
El diseo para multitarea debe disearse en trminos de la administracin concurrente
de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos
de un mismo proceso)
El diseo para uso concurrente el desempeo de un componente remoto depende de
si est corriendo mientras recibe una solicitud.
El diseo con el manejo de errores y prueba de eventos:
o Validando los parmetros- a la entrada antes de continuar con cualquier
proceso.
o Protegiendo recursos crticos manejar excepciones para evitar la falla o
terminacin sin cerrar archivos, liberar objetos sincronizados o memoria.
o Protegiendo datos importantes contar con una excepcin a la mitad de la
actuacin en las bases de datos.
o Debugging crear una versin para limpiar errores.
o Proteccin integral de transacciones de negocios los errores deben regresarse
al componente que llama.

o
Figura 3. Arquitectura fsica de tres capas de la aplicacin cliente/servidor
El diseo fsico comprende las siguientes tareas:
Definir los componentes
Refinar el empaquetamiento y distribucin de componentes
Especificar las interfases de los componentes
Distribuir los componentes en la red
Distribuir los repositorios fsicos de datos
Examinar la tolerancia a fallas y la recuperacin de errores
Validar el diseo fsico
De las tareas anteriores la ms importante es la distribucin de los datos que pueden
ser centralizados, una particin, un extracto o una rplica.
Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar
central. No hay copias de los datos.
Una particin de datos es una segmentacin de la base de datos maestra. Es til
cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con
cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal
cada hilera existe en una sola base de datos. En una particin vertical cada columna es
contenida en una y solo una base de datos.
Un extracto de datos es una copia de toda o una porcin de la base de datos maestra.
No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar
qu tan viejos son los datos.
Una rplica de datos es un fragmento de la bases de datos maestra que se puede
actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio
local. No se permiten actualizaciones en la base de datos rplica y en la base de datos
maestra a la vez, por lo que debe de haber sincronizacin entre ambas.
El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada
evolucin tecnolgica es importante considerar los estndares del momento y las
tendencias ya que una mala decisin implicar un costo enorme (en dinero y en
tiempo) al actualizarse a otra plataforma distinta.
La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un
servidor robusto multitareas y multithreading y el front-end como un cliente muy
delgado que no acapare al servidor comunicndose entre s en una plataforma internet
con protocolos estndar en redes heterogneas.
BIBIBLIOGRAFIA:
[Booch 1998] Booch G. 1998. Software Architecture and the UML. Presentacin disponible en:
http://www.rational.com/uml como arch.zip.
[Booch 1986] Booch, G. 1988. Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12.
Num. 2. Feb. 1986. pp. 211-221.
[Conallen 1999A] Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999
Disponible en:
http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm
[Conallen 1999B] Conallen, J. "UML Extension for Web Applications 0.91" Drafted Conallen, Inc.
22-Mar-1999 Disponible en:
http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm
[Cota 1994] Cota A. 1994 "Ingeniera de Software". Soluciones Avanzadas. Julio de 1994.
pp. 5-13.
[Greiff 1994] Greiff W. R. Paradigma vs Metodologa; El Caso de la POO (Parte II).
Soluciones Avanzadas. Ene-Feb 1994. pp. 31-39.
[Jacobson 1998] Jacobson, I. 1998. "Applying UML in The Unified Process" Presentacin.
Rational Software. Presentacin disponible en http://www.rational.com/uml como
UMLconf.zip
[Jacobson 1992] Jacobson, I. et. al. 1992. Object-Oriented Software Engineering; A Use Case
Driven Aproach. ACM Press. Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus.
pp. 465-493.
[Lewis 1994] Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp.
1-10.
[Microsoft 1997] Microsoft 1997. Microsoft Solutions Framework 1.0. Microsoft Corporation. USA.
[M&R 1998] Microsoft y Rational 1998. A White Paper on the Benefits of Integrating Microsoft
Solutions Framework and The Rational Process. Rational Software Corporation
y Microsoft Corporation. Documento msfratprocs.doc Disponible en
http://www.rational.com/uml/papers.
[OMG 1999] Object Management Group. 1999. OMG Unified Modeling Language
Specification (Draft). Versin 1.3. alfa R5, marzo de 1999. Disponible en:
http://www.rational.com/uml
[Zavala 2000] Zavala R. 2000. Diseo de un Sistema de Informacin Geogrfica sobre
internet. Tesis de Maestra en Ciencias de la Computacin. Universidad
Autnoma Metropolitana-Azcapotzalco. Mxico, D.F. En prensa.
Links:
http://www.mitecnologico.com/Main/CapasIngenieriaDeSoftware
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#fig2



Publicado por Erick en 14:17 1 comentarios

Calidad del software: es el desarrollo de software basado en estndares con la funcionalidad y
rendimiento total que satisfacen los requerimientos del cliente.
Calidad del Software
Procesos de desarrollo, artifacts, gestin de proyectos, anlisis y diseo, especificacin de
requerimientos, arquitectura, son solo algunos de los componentes que se aglomeran para
conformar la ingeniera de software (IS) como disciplina para la creacin y mantenimiento de
software. Dentro de sta, existe un subconjunto de teoras, herramientas y mtodos orientados a
lo que se denomina la calidad del software. Para resumir de alguna manera la amplitud de este
concepto, se puede decir que la calidad de software ha sido usada desde un simple argumento de
venta, hasta verdaderos estudios formales y usos de mtricas para el desarrollo de software.
Extraamente dentro de la IS, la calidad del software es muy complicada de definir y de
enmarcar en un simple concepto terico, por lo que en esta nota, me concentrar solo en las
diversas caractersticas que permiten describirla y en los elementos que importan
especficamente al diseador de software.
Una idea general sobre un software de calidad es aquel que debiera cumplir con los
requerimientos funcionales y de performance adems de ser mantenible, confiable y aceptable.
Veamos cada uno de las principales caractersticas que hacen a un software de calidad.
Mantenibilidad: el software debe ser diseado de tal manera, que permita ajustarlo a los cambios
en los requerimientos del cliente. Esta caracterstica es crucial, debido al inevitable cambio del
contexto en el que se desempea un software.
Confiabilidad: incluye varias caractersticas adems de la confiabilidad, como la seguridad,
control de fallos, etc.
Eficiencia: tiene que ver con el uso eficiente de los recursos que necesita un sistema para su
funcionamiento.
Usabilidad: el software debiera ser utilizado sin un gran esfuerzo por los usuarios para los que
fue diseado, documentado, etc.
Como puede observarse, las diversas caractersticas con las que se desea que cumpla un software
de calidad varan ampliamente. Algunas tienen que ver con el usuario que interacta con el
sistema, otras con el lder de proyecto y diseadores, otras caractersticas parecen muy abstractas
y hasta indefinidas, etc.
Para ordenar este aparente caos de indefiniciones y caractersticas abstractas, con el fin de poder
medirlas, estimarlas e implementarlas, la IS ha desarrollado desde los primeros das de su
existencia, diferentes procesos de desarrollo. Esta bsqueda para poder controlar y medir la
calidad del software, es tal vez una de las principales causas que han inspirado el estudio y
definicin de un sinnmero de metodologas, tcnicas y herramientas de la IS.
Como resultado de mi experiencia personal y lo extrado de otras lecturas, me animo a decir que
no es necesario el uso de un gran esfuerzo ni dedicacin de gran cantidad de recursos para lograr
software de calidad. Las empresas y equipos de desarrollo deben saber que con la adopcin de
solo algunas prcticas de la IS, ya es suficiente para estar en el buen camino. Bien, qu se
necesita entonces?
Como ya lo expresara en un post previo, toda empresa o equipo de desarrollo de software
debe adoptar un proceso de desarrollo. Cul?, como mnimo EL QUE LE CONVENGA.
Hay una gran variedad de procesos de donde tomar los elementos ms convenientes para alinear
los desarrollos con algunas caractersticas de la calidad del software vistas previamente.
Tambin se necesita coherencia desde el principio de cada proyecto. En ese momento
deben definirse, cuantificarse y/o especificarse las caractersticas de calidad a cumplirse
en ese producto.
Tambin se requieren las herramientas necesarias que ayuden al equipo para llevar
adelante todas las tareas necesarias en relacin a alcanzar los objetivos de calidad
planteados.
Es muy importante tambin, disponer de personas preparadas tcnicamente y liderados
por al menos un profesional con experiencia, que formen un equipo con la capacidad de
adaptarse y mejorar continuamente.
Como puede observarse, tomar por el camino del desarrollo de software de calidad no significa
disponer de grandes inversiones, sino de alinear los recursos disponibles, prepararlos y
coordinarlos adecuadamente. Llegado el momento de escalar, o desear el logro de alguna
certificacin para ampliar mercados, o sencillamente buscar ser una empresa que logre
desarrollar productos de calidad, ser mucho mejor y ms simple, si las empresas siguieran estos
lineamientos mnimos para cuando llegue ese momento.

PROCESO DEL SOFTWARE PERSONAL (PSP)
Cada desarrollador usa distintos procesos para construir un software, estos pueden ser no
eficientes o exitosos o tambin pueden cambiar a diario, pero existe un proceso.
WATTS HUMPHREY dice que para cambiar un proceso inefectivo se tiene que pasar por cuatro
fases y estas requieren capacitacin e instrumentacin. PSP resalto la medida personal al
profesional de la planeacin, tambin hace responsables al profesional de la planeacin del
proyecto y la calidad de todos los productos.
Existen 5 actividades de marco de trabajo que son:
1. Planeacin: Aqu se selecciona los requisitos y se desarrolla el tamao y la estimacin de los
recursos. Estas mediciones se anotan en las plantillas y al final se identifican las tareas de
desarrollo y se crea un programa del proyecto.
2. Diseo de alto nivel: Se analizan los factores externos y se construyen prototipos cuando hay
incertidumbre.
3. Revisin del diseo de alto nivel: Se aplican los mtodos de verificacin a los errores que se
descubrieran en el diseo.
4. Desarrollo: Se refina y revisa el diseo y se verifica el cdigo y se compila, adems todas las
mediciones se guardan para los resultados de trabajo.
5. Anlisis de resultados: Aqu se determina la efectividad del proceso, analizando todos los
datos que se tienen.
El PSP destaca que cada ingeniero tiene la necesidad de identificar los errores y de entender la
importancia y los tipos de errores que suelen cometerse.
Factores de calidad y productividad
La calidad del software desarrollado, as como la productividad del programador son factores de
difcil, pero no imposible, medida. Existen una serie de factores que inuyen en la calidad y
productividad, que son los siguientes y que ayudan a realizar dicha medida:
La capacidad individual.- En este fctor intervienen la competencia del individuo y su
familiaridad con el rea de la aplicacin.
La comunicacin entre los miembros del equipo.- Es un factor importante, ya que el traba jo en
la mayor parte de las ocasiones no es individual y debe integrarse con el que ha sido desarrollado
por otros miembros del equipo.
La complejidad del producto.- Este factor depende del tipo de aplicacin a desarrollar y es de
difcil estimacin, ya que muchas veces hasta la fase de desarrollo no es posible comprender en
toda su perspectiva las complicaciones que conlleva su realizacin.
Utilizacin de una notacin adecuada.- Este factor es de gran importancia para facilitar la
comunicacin entre las partes involucradas (incluido el usuario).
Empleo de mtodos sistemticos.- Es importante que se empleen tcnicas que sean de amplio
consenso y bien conocidas por los integrantes del equipo de desarrollo de la aplicacin. Tambin
es fundamental que estas tcnicas se empleen de manera sistemtica sobre todas las aplicaciones
de caractersticas semejantes con objeto de facilitar el anlisis de coste y tiempo, y tambin para
poder observar la trayectoria profesional de los miembros del equipo.
Conocer el tiempo disponible.- Este factor esta vinculado a otros anteriores, ya que es bsico
conocer el tiempo que puede aportar cada miembro del equipo y en que plazos, sobre todo en
funcin de las tareas a realizar y de la mejor o peor productividad de determinados miembros en
cada una de ellas.
Existencia de facilidades y recursos externos.- Este factor, es determinante en la medida en que
se conozcan productos o herramientas (automticas o no) que faciliten las labores de desarrollo e
integracin de la aplicacin. En mayor medida cuando se conocen aplicaciones parecidas de fcil
trasportabilidad y modicacin que puedan servir de base a la que hay que realizar.
Como en el resto de las actividades industriales, en el desarrollo de software, tambin es
importante realizar una buena planicacin del trabajo y una buena asignacin de recursos a los
distintos miembros del equipo. Una mala planicacin termina con una mala aplicacin o una
aplicacin terminada a destiempo (disgusto del peticionario), lo cual supone un fracaso. Varios
fracasos consecutivos de este mismo estilo suponen la ruina para la mayor parte de las empresas
del sector, debido a la competencia existente.
ITCC Cuauhtemoc Chih.