Bienvenida

Te damos la ms cordial bienvenida a la unidad de aprendizaje Ingeniera de software bsica, cuyo objetivo es brindarte conocimientos para la aplicacin de los principios fundamentales de la ingeniera de software como indicador de la calidad del software. Los fundamentos que aqu vers te servirn para que, al concluir tus estudios, cuentes con las bases necesarias para desarrollar y aplicar las competencias aprendidas. Por lo que, esperamos que al explorar juntos estos conocimientos obtengas xito al desempearte en tu vida laboral. La ingeniera de software es una disciplina que est estrechamente relacionada con otras, como la economa, ingeniera, gestin, informtica, administracin y psicologa. Esto debido a que para el desarrollo de un software, no slo se realiza la programacin, tambin hay que realizar la documentacin, incluir datos y dar mantenimiento. En este sentido, idealmente un software despus de la entrega debe de continuar con un fallo estable hasta el final de su ciclo de vida. Por lo cual, el desarrollo de software implica que al tener un problema o necesidad, se aplique ingeniera de software a travs de un proceso para el desarrollo y as obtener la solucin. La aplicacin de software debe ser rentable, fiable, con calidad, eficiente y satisfaciendo los requisitos del cliente. Todos estos elementos estn involucrados en la ingeniera de software bsica de forma significativa y profunda. De esta manera, esta unidad de aprendizaje te dar nuevas perspectivas y ventajas competitivas para el desarrollo de aplicaciones web con calidad. Te conviene saber

Competencias

Temario

Unidad I. Generalidades de la ingeniera de software

Tema 1. Generalidades de la ingeniera de software
1.1 Evolucin de la ingeniera de software
a) Preguntas frecuentes sobre la ingeniera del software b) Ingeniera de software contra ingeniera de sistemas

1.2 Sistemas de informacin: sus propiedades y su organizacin

a) Sistema de informacin b) Propiedades emergentes de los sistemas

Tema 2. Ingeniera aplicada a sistemas

2.1 Factores de la ingeniera de software
a) El proceso de software b) Los requerimientos del sistema c) Diseo del sistema d) Desarrollo de los subsistemas

e) Integracin del sistema f) Evolucin del sistema g) Desmantelamiento del sistema

2.2 Organizaciones, personas y sistemas informticos

a) Procesos organizacionales b) Sistemas heredados

Unidad II. Aplicaciones de la ingeniera web

Tema 1. Elementos de la ingeniera web
1.1 Atributos de los sistemas y aplicaciones en web 1.2 Proceso de la ingeniera web
a) Definicin y refinamiento del marco de trabajo b) Mejores prcticas de la ingeniera web c) Peores prcticas para proyectos webapps

1.3 Estratos de la ingeniera webapps

Tema 2. Formulacin y planeacin de la ingeniera web

2.1 Formulacin de sistemas basados en web 2.2 Planeacin de proyectos de ingeniera web 2.3 Equipo de ingeniera web 2.4 Medicin para la ingeniera web y webapps

Tema 3. Modelado de anlisis para aplicaciones web

3.1 Requisitos de anlisis para aplicaciones web 3.2 Modelado de anlisis para webapps
a) Anlisis de contenido b) Anlisis de interaccin c) Anlisis funcional d) Anlisis de configuracin

3.3 Anlisis relacin-navegacin

Tema 4. Modelado para el diseo de aplicaciones web

4.1 Temas de diseo para la ingeniera web 4.2 Pirmide para el diseo web
a) Diseo de la interfaz b) Diseo esttico c) Diseo de contenido d) Diseo arquitectnico

e) Navegacin f) Diseo al nivel de componentes

4.3 Patrones de diseo hipermedia 4.4 Mtodo de diseo hipermedia orientado a objetos 4.5 Mtricas de diseo para webapps

Tema 5. Pruebas para aplicaciones web

5.1 Prueba de conceptos para webapps 5.2 El proceso de prueba
a) Prueba de contenido b) Prueba de la interfaz de usuario c) Prueba de navegacin d) Prueba del nivel de componentes e) Prueba de seguridad f) Prueba de configuracin g) Prueba de desempeo

Unidad III. Gestin de proyecto

Tema 1. Gestin del personal
1.1 Seleccin del personal y motivacin
a) Seleccin del personal b) Motivacin

1.2 Gestin de grupos

a) Comunicaciones del grupo b) Organizacin del grupo c) Entornos de trabajo

1.3 Modelo de madurez de la capacidad del personal (CMM)

Tema 2. Estimacin de costos del software

2.1 Productividad y tcnicas de estimacin
a) Productividad b) Tcnicas de estimacin

2.2 Modelado algortmico de costes 2.3 Modelo COCOMO 2.4 Modelos algortmicos de costes en la planificacin 2.5 Duracin y personal del proyecto

Tema 3. Mejora de los procesos de software

3.1 Mejora de procesos 3.2 Calidad de producto y de proceso 3.3 Clasificacin de los procesos 3.4 Medicin del proceso 3.5 Anlisis y modelado de los procesos 3.6 Excepciones del proceso 3.7 Cambio en los procesos 3.8 Marco de trabajo para mejora de procesos CMMI
a) Modelo CMMI en etapas b) Modelo CMMI continuo

Metodologa

La unidad de aprendizaje Ingeniera de software bsica est conformada con actividades que te permitirn aplicar los conocimientos de los temas abordados. En los contenidos de esta unidad se maneja un lenguaje claro para su mejor comprensin, aunque tambin encontrars el propio del Tcnico en Desarrollo del Software, es decir, palabras y conceptos que te sern de utilidad para el ejercicio de esta profesin. La metodologa utilizada tiene un enfoque constructivista, es decir, que te permitir vincular tus conocimientos previos a los nuevos para poder solucionar ejercicios representativos en el rea de ingeniera de software bsica dentro del mbito laboral o en situaciones diversas, esto con el fin de promover tu aprendizaje significativo y capacitarte para que seas capaz de aplicarlo en distintas situaciones, no slo en tu vida acadmica. Adems est orientada, en algunas actividades, con la metodologa de anlisis de casos, la cual permite al estudiante la aplicacin de los conocimientos tericos relacionados con una situacin hipottica y a su vez permite el desarrollo de algunas de las principales habilidades demandadas por el entorno

laboral actual, es decir, que el estudiante se situar frente a algunas de las demandas tpicas que recibe el tcnico en desarrollo de software respecto a la ingeniera de software bsica. En esta unidad de aprendizaje encontrars el siguiente tipo de actividad:

Actividades de aprendizaje. Estas actividades permiten la aplicacin de lo aprendido en los temas, tienen un valor definido para tu calificacin final. Algunas actividades las realizars individualmente y otras en equipo. Es importante que te organices para realizarlas, pues los valores de cada actividad son importantes para tu evaluacin final.

Por ltimo, para que adquieras los conocimientos de esta unidad de aprendizaje te sugerimos que tomes en cuenta los siguientes puntos:

Cuando ingreses y revises los temas, procura tener siempre a la mano un cuaderno y un lpiz para que elabores tus propias anotaciones.

Imprime y ten siempre a la mano tu agenda de actividades y la tabla de evaluacin, as podrs organizar tus tiempos de estudio y elaborar las actividades, las cuales debers entregar puntualmente.

Las tres unidades que integran Ingeniera de software bsica tienen una introduccin y mapa de conceptos. Te sugerimos leerlos con atencin, ya que ah encontrars el panorama general de lo que aprenders.

Recuerda que para lograr una mejor comprensin, es necesario que leas atentamente. Quiz algunos temas, por su complejidad, requieran que los repases varias veces.

Estudia ordenadamente, como lo establece el temario. No debes omitir ningn tema ni subtema ya que, de hacerlo, podra ocasionarte algunos problemas, por ejemplo, que pierdas la secuencia del curso y retrases tu aprendizaje.

Ten presente que tu asesor y tu tutor estarn acompandote. Ellos te apoyarn resolviendo tus dudas las veces que sea necesario.

Desarrollando tus actividades demostrars lo que aprendiste. Lee detenidamente las instrucciones y sguelas correctamente. Si tienes alguna duda acude a tu asesor, l te apoyar. En esta modalidad de aprendizaje el xito depende de tu capacidad para organizar tu tiempo y los conocimientos que adquieras. El buen manejo de stos se ver reflejado en tus evaluaciones.

UNIDAD 1 Introduccin
La ingeniera de software nace como un arte y no como una disciplina, pero a medida que ha evolucionado, se ha fortalecido y se ha perfeccionado como tal, haciendo uso del conocimiento e innovando apoyos para aplicarla en el rea que se requiera. En esta unidad estudiars su evolucin, adems de algunos otros elementos que debes tener presentes para conocer sus implicaciones tecnolgicas, econmicas y sociales as como otras cuestiones importantes que intervienen para obtener un software de calidad. Antes de continuar revisa el siguiente mapa de contenidos, el cual te ayudar a visualizar los temas y conceptos clave que te servirn en el estudio de esta primera unidad temtica.

1. Generalidades de la ingeniera de software

La ingeniera de software abarca las etapas de desarrollo de todos los sistemas de software para tratar de suministrar un marco de trabajo en el que se pueda llevar a cabo software con mayor calidad, y as conquistar todos los mbitos de nuestro entorno. Los mtodos, procesos, tcnicas y herramientas tanto para desarrollar como para mantener el software son aportaciones de la ingeniera de software, porque es una disciplina que se ocupa de ello, tal como lo vers a continuacin.

1.1 Evolucin de la ingeniera de software

En la ingeniera del software se ha avanzado al aplicar lenguajes ms refinados y elegantes, al madurar sus procesos, tambin se han desarrollado sistemas ms complejos, a tal grado que todo nuestro entorno se mueve alrededor del

software, ya sea desde una simple solucin de un problema hasta toda una industria. As, la ingeniera de software se afianz por las necesidades que se presentaron al ir desarrollando software, su evolucin puede apreciarse en el siguiente esquema.

Tambin, las tcnicas de desarrollo de software han evolucionado, en un principio se present una programacin elaborada sin cualidades ni restricciones, para luego hacerla ms especializada comenzando a pequea escala y terminando en gran proporcin. Para tener una idea ms clara de lo qu es la ingeniera de software y de la importancia que sta tiene, es necesario remontarse varios aos. Observa e interacta con la siguiente lnea de tiempo.

Consulta la siguiente informacin web en Para saber ms con la que ampliars tus conocimientos acerca de la evolucin de la ingeniera de software: http://docente.ucol.mx/victorc/public_html/fime/docs/Pres01_IngSoftware.pdf En este sentido la ingeniera de software se enfrenta a varios desafos, todos emanados de la cultura que se posee de la misma, stos son:

los objetivos del proyecto, las tcnicas, las actividades individuales y las preferencias de administracin.

Todos refuerzan la cultura de la ingeniera de software que al mismo tiempo ayuda a fijar prioridades de gestin, que es el cimiento de las acciones individuales y define los objetivos del proyecto. Entonces, por lo que se ha dicho hasta este momento podemos decir que la ingeniera de software se define como: La aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la ingeniera en el rea del software. La ingeniera de software se nos presenta como una tecnologa multicapa, en la que tenemos varios elementos involucrados:

En este concepto, los procedimientos manejan tanto a los mtodos como a las herramientas, las cuales se suelen combinar, para generar mejores resultados. Por otro lado, las tcnicas con las que contamos son abstracciones (modelos de ciclo de vida, principios de las distintas fases), representaciones (notaciones: diagramas, lenguajes) y evaluaciones (mediciones sobre el proceso, el producto y el proyecto). A continuacin se dar respuesta a algunas de las incgnitas que surgen en torno a la ingeniera de software. a) Preguntas frecuentes sobre la ingeniera del software Para comprender mejor debes tener presentes los elementos que emplea la ingeniera de software que ya has manejado y conocido en otras unidades de aprendizaje.

Profundizando un poco ms en el concepto del software tenemos que ste puede ser un producto genrico o a medida, su diferencia fundamental es que los requerimientos son controlados, en el primer caso, por la empresa desarrolladora, y en el segundo, por el cliente. Por ello sabemos que el desarrollo de una aplicacin de software no consiste solamente en programar, por el contrario es una actividad de solucin de problemas. Cuando tenemos la necesidad o problema, aplicamos el proceso de software (desarrollo, control, gestin, operacin) y obtenemos un producto que resulta un software que debe cubrir lo solicitado. Pero, cul es la importancia de la ingeniera de software para el desarrollo de software? En nuestros das se ha extendido el desarrollo de software, ya que la gran mayora de las actividades de lo que est en nuestro alrededor usa computadoras y evidentemente un software de aplicacin. Al emplear la ingeniera de software en stos se ha elevado la productividad y ha favorecido el crecimiento econmico; por otro lado, socialmente ha renovado la cultura al innovar formas de comunicacin (mail, videoconferencia, chat); e infinidad de empresas como tiendas, bancos, instituciones gubernamentales han mejorado sus servicios a travs de la ingeniera de software. De esta forma las economas de los pases dependen en mayor parte del software, pues cada da se suman ms sistemas controlados por ste, apoyndose para su desarrollo en tcnicas, mtodos, procesos y herramientas de la ingeniera de software.

b) Ingeniera de software contra ingeniera de sistemas En un contexto amplio se percibiran todos los aspectos involucrados en el desarrollo de software reconociendo a la ingeniera de software como un elemento ms entre stos. La ingeniera de software tiene como objetivo reducir costos de desarrollo y mantenimiento de las aplicaciones de software. Es decir, slo le atae el desarrollo de sistemas o productos de software. Por otro lado, los ingenieros de sistemas tienen como funcin la especificacin del sistema, el establecimiento de la arquitectura, la integracin de las partes que conforman el sistema, enfocndose ms al diseo general. Pero qu diferencia hay entre ingeniera de software e ingeniera de sistemas? Bsicamente es que la ingeniera de software se usa como herramienta en la ingeniera de sistemas. Por lo que, de manera integral los ingenieros de software adems de poseer conocimientos tcnicos, sociales y profesionales, deben tener tica en lo referente a la confidencialidad, la competencia, los derechos de autor y el uso de la computadora de forma adecuada. Te invitamos a que descargues y leas el siguiente documento PDF titulado: Cdigo de tica para los ingenieros de software.

Las sociedades profesionales publican cdigos de conducta que especifican los estndares de comportamiento deseado por sus miembros. Es importante tomar en cuenta todos los aspectos en la preparacin de los profesionales de la ingeniera de software, ya que sta se enfrenta a varios retos, entre los cuales destacan:

Poco tiempo para desarrollar el sistema.

Elevadas capacidades de procesamiento y de memoria.

Mantenimiento de sistemas heredados y sistemas heterogneos.

El software puede ser desarrollado para su venta en el mercado o hecho a medida, al respecto, el software para comercializar tiene una gran inversin mientras que el software a medida requiere de mucho esfuerzo. Por otro lado, el software debe tener las siguientes caractersticas para su venta:

Mantenibilidad. Est en constante evolucin y debe de cumplir requerimientos.

Confiabilidad. No origina perjuicios de ningn tipo.

Eficiencia. No desaprovecha recursos.

Manejo correcto. Interfaz apropiada con su documentacin.

La importancia de las caractersticas depende del mbito y tipo de aplicacin para la que fue desarrollado, por ejemplo, si fue un sistema de pagos, la seguridad es vital y las caractersticas sobresalientes sern confiabilidad y eficiencia. Por cada atributo potencializado del software aumenta estratosfricamente los costos. Adems se debe tomar en cuenta que el software, aplicacin o sistema de informacin tiene caractersticas intrnsecas: se desarrolla, se deteriora, es lgico e intangible. Puedes darte una idea de cmo se emplean estas caractersticas tanto en el software como en las aplicaciones, ya que anteriormente has estudiado estos conceptos, sin embargo, a continuacin conocers ms acerca de qu es y cmo se compone un sistema de informacin.

1.2 Sistemas de informacin: sus propiedades y su organizacin

El software es la clave de la evolucin de los sistemas y es el componente de un sistema ms grande, por lo general. Esta visin toma importancia cuando el software es vinculado a otro, o tambin a un hardware, base de datos o a las personas. La labor inicia estableciendo requerimientos para cada uno de los elementos del sistema y asignando un programa (software) para un conjunto de requerimientos.

La informacin comprende tanto los requerimientos estratgicos, a nivel empresarial, como las solicitudes, a nivel negocio. El entorno en el que est inmerso el software determina el control, los datos a procesar, la funcin, el rendimiento, las restricciones, las interfaces y la confiabilidad. Los sistemas de informacin son utilizados para recuperar informacin, apoyar la toma de decisiones y hacer el proceso de las operaciones diarias, adems deben dar respuesta a todos los niveles de la empresa, aqu todo interacta para conseguir los objetivos de la empresa. Esto significa que la aplicacin de software tiene impacto en la empresa, as la seleccin y el uso de las tecnologas de informacin, si se hace con cuidado y asertivamente, ser de gran utilidad para establecer los requerimientos de informacin que necesita la empresa y crear un modelo de informacin para soporte y anlisis. Y finalmente, para explotar al mximo la informacin, con los efectos previstos por la misma, convirtindose en un factor clave para su xito, evolucin y permanencia. a) Sistema de informacin Un sistema de informacin puede definirse como: Un conjunto de procesos que operan sobre una coleccin de datos segn las necesidades de la organizacin (empresa). Recopilan, elaboran y distribuyen la informacin necesaria para las operaciones de dicha empresa y para las actividades de direccin y control; para desempear su actividad de acuerdo con su estrategia de negocio. El objetivo del Sistema de Informacin (SI) es proporcionar informacin de calidad. Los elementos que componen un sistema bsicamente son:

Los datos son la parte principal de los sistemas de informacin, presentan ms estabilidad que los procesos que se les aplica. Cada sistema que se desarrolle contar con las mismas caractersticas, como veremos en el siguiente tema. b) Propiedades emergentes de los sistemas Los sistemas tienen propiedades como un todo, algunas derivan de los subsistemas, pero normalmente, se deben a las interrelaciones entre los componentes del sistema. Hay dos tipos de propiedades emergentes en los sistemas: las funcionales y las no funcionales. Las propiedades emergentes funcionales son visibles al usar el sistema en conjunto. Las propiedades emergentes no funcionales son los comportamientos que presenta el sistema en su ambiente de operacin. Frecuentemente son elementos crticos que cuando presentan un fallo, a veces puede hacer intil al sistema de software, quin desea un sistema lento o digno de duda? Todos los componentes del sistema son interdependientes, por lo cual, una falla en alguno, puede hacer fallar a otro(s).

Una propiedad importante es la fiabilidad del sistema. La fiabilidad completa del sistema est vinculada a: la fiabilidad del hardware; la fiabilidad del software y a la fiabilidad del operador. Debido a esta vinculacin, un fallo en hardware crea intervalos fuera de dominio de las entradas del software, generndose comportamientos inadecuados en el sistema. El error humano puede presentarse ms comnmente causado por la presin produciendo tambin errores en el sistema de hardware o software. En consecuencia un fallo incipiente recuperable se puede transformar en un fallo crtico con paro total del sistema. En el siguiente esquema o cuadro, se muestran ejemplos de propiedades emergentes:

Algunas propiedades emergentes como el rendimiento o la usabilidad son complejas de estimar, pero se pueden evaluar con mtricas cuando el sistema completo entra en funcin. A pesar de todo lo que hay para medir, otras propiedades no se pueden determinar claramente, este es el caso de la seguridad, slo sabemos que es inseguro cuando alguien accede sin autorizacin, pues es imposible predecir

todos y cada uno de los accesos, y prohibirlos, aunado a que esta propiedad est relacionada, no slo con el comportamiento predecible, sino con el que no debera presentar. Para poder desarrollar un software hay que hacer previamente su modelo, esto se consigue con la aplicacin de algn proceso de desarrollo, en la etapa de diseo. Los modelos como abstraccin de la realidad o representacin abstracta estn constituidos por una agrupacin de entidades y sus interrelaciones. La ingeniera de software se enfoca en el proceso, dado que considera que si se tiene un buen proceso se obtiene un buen producto. Esto es parte de lo que veremos en el tema que sigue.

2. Ingeniera aplicada a sistemas

En este tema estudiars la importancia de la ingeniera aplicada a los sistemas en cada una de sus etapas (requerimientos, diseo, desarrollo, integracin, evolucin y desmantelamiento) a partir de los factores de la ingeniera de software; tambin vers su relacin con otros elementos como es la efectividad de los recursos humanos de una organizacin, y de los sistemas informticos que estn vinculados a los sistemas.

2.1 Factores de la ingeniera de software

La ingeniera de software abarca tres factores clave, que son: herramientas, mtodos y procesos, para desarrollar software con calidad. En esta parte nos enfocaremos en el tercero de estos factores, ya que, se considera que si se tiene un buen proceso se obtiene un buen producto. a) El proceso de software El proceso de software se define como: diversas actividades organizadas para desarrollar un sistema de software. Esto se ilustra a continuacin.

El proceso es alterable, varia adecundose a la organizacin o empresa y al tipo de software a desarrollar. Por lo que debe ser muy explcito para poder llevar una adecuada gestin. De manera genrica todo proceso lleva: especificacin, diseo, desarrollo, pruebas, implementacin (segura operacionalidad) y mantenimiento (reparacin de fallos). El proceso debe ser claro, bien definido, soportable, visible, aceptable, confiable, robusto, mantenible y rpido. Existen varias metodologas de desarrollo de software:

Modelo en cascada Modelo basado en prototipos Modelo incremental o evolutivo Modelo espiral Modelo RUP Modelo DRA Modelo basado en componentes Modelo OO Modelo cascada con sub - proyectos Modelo entrega por etapas

Ya conoces todos los conceptos anteriores, excepto los ltimos dos, que vers a continuacin. El modelo cascada con sub proyectos lo puedes observar en el siguiente diagrama:

Como puedes observar se tiene una primera etapa donde se obtienen los requerimientos, una segunda, donde se lleva a cabo el anlisis, para continuar con el diseo integral del sistema a desarrollar. De aqu se puede dividir este diseo total en partes, para desarrollarlos como subsistemas, mdulos o subproyectos, con el fin de cubrir la totalidad de requerimientos solicitados por el cliente.

Tal como se aprecia en la ilustracin se desarrollan a la par y una vez concluidos se pasa a la etapa de pruebas e integracin para finalmente obtener el software final. A continuacin se ilustra el modelo entrega por etapas.

En este modelo se obtienen los requerimientos, se analizan y se realiza el diseo integral, el cual es particionado con base en funcionalidades prioritarias o determinadas por el cliente, llevando el desarrollo del software en etapas de acuerdo con lo estipulado por ambas partes. El producto que se obtiene en cada etapa es una parte funcional del todo, en cada etapa se lleva el diseo detallado de lo que se va a desarrollar: codificacin, pruebas, depuracin y la entrega.

Cuando se tiene un sistema, son varias las representaciones que se consigue hacer de l, las herramientas que se usarn y el personal requerido, cada modelo debe de identificar las entidades que se involucran. La primera etapa de cualquier tipo de proceso que se elija para el desarrollo de software es la definicin de requerimientos. Los requerimientos son el centro y eje de cualquier desarrollo, sin el debido tratamiento y cuidado en la especificacin de estos se corre el riesgo fatal de fracaso en el proyecto. Por ello, se debe hacer hincapi en ellos. b) Los requerimientos del sistema Recuerda que los requerimientos son una capacidad o condicin solicitada para cubrir un objetivo, resolver un problema, satisfacer una norma o documento oficial. Y deben cumplir con caractersticas como: estar completo, ser consistente, verificable, correcto, no ambiguo, modificable, que sea trazable, independiente del diseo, con prioridad y probabilidad de cambio; donde se debe de observar quin pide, qu es lo que solicita, sobre qu lo requiere y la condicin o restriccin que presenta. Por lo que, el ingeniero de software debe trabajar en equipo, analizar, estudiar los problemas, trabajar bajo presin, con recursos y costos limitados, interactuar con los clientes, tomar decisiones, realizar las actividades de desarrollo, de control, de administracin y de operacin, l decide qu hacer, cmo hacerlo, llevarlo a cabo, probar el producto, usar el producto y darle mantenimiento. En cada etapa del desarrollo de software se llevan varias tareas, en el anlisis se estudia la viabilidad, se extraen los requerimientos, se analizan; en el modelado del sistema se llevan a cabo todos los diseos (de arquitectura, el detallado, la GUI, de datos, entre otros); en el desarrollo se crea la codificacin, documentacin, depuracin, etc., y finalmente, elabora mantenimiento en todas las etapas, se prueba, validando y verificando. Para asegurar la calidad se calculan las mtricas, se administra la configuracin y se garantiza la calidad. La administracin que se hace en este aseguramiento de calidad es planificar, estimar y darle seguimiento al proyecto. En la etapa de operacin se entrega instalando la aplicacin de software, lo pone en ambiente productivo y capacita a los usuarios. Por lo que el ingeniero de software se debe dar a la tarea de delimitar, clarificar y concretar las necesidades que cubrir el desarrollo del software, a travs de tcnicas que pueden ayudar a puntualizar los requerimientos, una de estas, es la entrevista.

Otra de las tcnicas que se usan son: JAD, lluvia de ideas y los casos de uso de UML. Con estas ltimas dos tcnicas tambin ya ests familiarizado, por lo cual, slo se har mencin de la tcnica JAD. JAD (JoinedApplication Development): Proceso de recopilacin de datos rpidos donde usuarios y analistas concurren en una extensa reunin para precisar los requerimientos de los usuarios. En esta reunin se crean modelos, mismos que los participantes avalarn al terminar. Los roles de los participantes son:

Moderador (es el lder de JAD). Como caracterstica necesaria para este rol debe contar con conocimientos amplios de la metodologa del trabajo, comportamiento, etctera. Promotor. Es la persona que promueve el desarrollo. Jefe de proyecto. Es el responsable de la implantacin. Especialista en modelizacin. Es la persona responsable de construir los modelos. Desarrolladores. Las personas que garantizan que los modelos son correctos y cumplen con los requisitos especificados. Usuarios. Las personas responsables de detallar los requisitos y validarlos.

Todos los integrantes deben ser responsables. El proceso para la obtencin de requerimientos est establecido por:
1. Obtener la factibilidad,

2. Extraer y analizar los requerimientos,

3. Especificarlos y

4. Finalmente validarlos.

As lo que obtenemos al final es el documento de requerimientos. Los requerimientos estn clasificados bsicamente en dos tipos: funcionales y no funcionales. Aunque puede haber muchos otros como requerimientos de sistema y requerimientos de comunicaciones. Los requerimientos funcionales ya los has trabajado y ests familiarizado con ellos, por lo que se puntualizar en los no funcionales. Los requerimientos no funcionales son las restricciones que se determinan ms all de las funciones, no vinculados a los servicios que el software debe cumplir, como el hardware, el software a usar, comunicaciones, atributos de calidad (como mantenibilidad, portabilidad, etc.), robustez, seguridad,

privacidad, arquitectura, diseo, implementacin, desempeo, documentacin, licencias, elementos de internacionalizacin (moneda, medidas, idioma), estndares, reglas de negocio. La eleccin del modelo de desarrollo depende de las caractersticas del sistema como qu tan completos o cambiantes estn los requerimientos, si el proyecto es similar a otros ya realizados, si se requiere una versin rpida del sistema o de la duracin del proyecto. c) Diseo del sistema Para disear hay que modelar. Entonces es necesario elaborar una jerarqua en detalle, podemos crear un diagrama de contexto del sistema, estableciendo los lmites de informacin entre el sistema y el entorno en el que se implementar. Por lo tanto, el diseo del sistema consiste en abstraer el problema y modelar la solucin para despus implementarla. Estos son algunos tipos de modelos en el diseo del sistema:

Para el modelado, tambin podemos hacer uso de los diagramas UML, los estructurales y los de comportamiento. Por otro lado, tenemos modelos para datos los cuales se enfocan en el flujo de movimiento y transformacin de stos, a travs del sistema. De esta manera se tiene el diseo de datos con las estructuras de datos para el sistema, para ello usamos el Diagrama Entidad Relacin y el diccionario de datos.

El diseo de interfaz (usuario, interna y externa), describe la comunicacin con otros sistemas, con el usuario, entre usuario y PC. Para una interfaz amigable se recomienda:

El diseo orientado a objetos se divide en la capa de subsistemas, capa de clases y objetos, capa de mensajes, y la capa de responsabilidades. Actualmente, cuando se est desarrollando un sistema de informacin o un software de aplicacin es muy comn la utilizacin de algn componente de terceros que nos ayude o simplifique de alguna manera el desarrollo, los tiempos y los costos, como se aprecia en el siguiente tema. d) Desarrollo de los subsistemas Cuando se desarrollan subsistemas se hace ingeniera de software para cada uno de los sistemas que lo conforman, haciendo uso del proceso de desarrollo de software. Los subsistemas ocupados en el desarrollo de un sistema a veces se compran, para integrarse al sistema que se est desarrollando, ya que resulta ms barato que desarrollar uno de propsito especfico. Estos subsistemas adquiridos pueden no ajustarse totalmente y entonces hay que llevar a cabo esta adecuacin mediante la ingeniera de software. Es normal que los subsistemas se desarrollen a la par. Cuando las adecuaciones que se deben de realizar sobrepasan los lmites del mismo, se hacen peticiones de cambio del sistema, pero si el sistema ya va muy

avanzado, resultara muy caro, sobre todo si no se desarroll el software con diseo para el cambio, implementndose nuevos requerimientos sin costos adicionales. e) Integracin del sistema Esta integracin se lleva acabo cuando se juntan los subsistemas desarrollados en un slo sistema. La integracin puede ser de forma big bang, que consiste en la integracin de todos los subsistemas al mismo tiempo. O bien, para cuestiones administrativas y tcnicas, es mejor la integracin creciente, que es cuando se integran uno por uno, pues no todos los subsistemas se terminan al mismo tiempo, de esta forma se localizan ms fcilmente los errores, ahorrando costos. Una vez conformado el sistema se da paso a las pruebas. En esta etapa, se prueban las interfaces entre componentes y el comportamiento del sistema completo. Al descubrir errores en alguno, los distintos contratistas pueden juntarse y ver la forma de solucionar el problema presentado, entonces se hacen negociaciones. En la actualidad los sistemas desarrollados son constituidos por componentes de hardware o software que se compran, debido a esto, la integracin est tomando ms fuerza, convirtindose en esencial. Algunas veces, el desarrollo de subsistemas y la integracin no es de forma independiente. f) Evolucin del sistema Los sistemas de software, complicados y considerables, tienen un ciclo de vida amplio durante el cual sufren cambios para adaptar los requerimientos o adicionar nuevos. En consecuencia, la evolucin es costosa pues incluye costos tcnicos y de negocio. El cambio no tiene que deberse slo a aspectos tcnicos, sino a propsitos especficos de los sistemas. Y un cambio en un subsistema puede desencadenar una serie de cambios en otros. En muchas ocasiones las razones para un diseo no son documentadas, por lo que los responsables de la evolucin del software deben resolver la toma de decisin del diseo en particular. Es natural que al paso del tiempo la estructura del sistema de software se envicie por diversas modificaciones y se requiera de cambios que incrementan costos adicionales. Este tema lo vers en la Unidad de aprendizaje Soporte de software.

g) Desmantelamiento del sistema Se mencion anteriormente que el software se deteriora con el paso del tiempo, por lo que necesita mantenimiento, pero cuando ya no se puede realizar el mantenimiento requerido, para continuar cubriendo los requerimientos o cuando los costos son elevados y la empresa, a travs de un estudio de costo beneficio, determina que no es viable, se inclina la toma de decisin por el desmantelamiento del sistema. A esta decisin tambin se puede llegar por medio de un anlisis en el que se decide la sustitucin de un sistema por otro. Se habla de desmantelamiento cuando el sistema de software es sacado del ambiente operativo, terminando su vida til. De forma fsica, el software no tiene ninguna complicacin para su salida, pero se puede hacer uso de algn otro software para tal desmantelamiento. De esta manera, se pueden detectar los componentes en estado adecuado y hacer una reutilizacin en otros sistemas, como los datos que podran tener algn valor para la empresa y ser utilizados en otro, pero tal reutilizacin involucra un costo cuando la estructura de datos est comprometida, as, es conveniente llevar a cabo un estudio de los datos, sus estructuras y entonces reorganizar las estructuras demandadas por el nuevo sistema. La organizacin, empresa o institucin cuando emplea algn tipo de sistema de informacin o una aplicacin de software tiene impacto en sta y repercute en sus funciones como veremos en el tema que contina.

2.2 Organizaciones, personas y sistemas informticos

La empresa puede ser reorganizada, por la inclusin de un sistema de software o el medio ambiente puede originar un cambio al software. Los sistemas con fines de apoyar objetivos organizacionales o de negocio son de tipo socio-tcnico, influenciados por los procedimientos, normas, reglas, polticas y cultura de la empresa. Al desarrollar un sistema de este tipo, es indispensable entender el negocio, de lo contrario, se corre el riesgo de no cubrir todas las necesidades y que sea rechazado el sistema. El diseo del sistema se influencia por elementos humanos y empresariales de su ambiente, como los procesos, los cuales al cambiar requieren de capacitacin, eliminacin de puestos o manejo de resistencia al cambio. Tambin puede ser afectado por la forma de laborar, pues no son bienvenidas las nuevas formas de hacer el trabajo, o bien, puede afectar jerarquas en cuanto a nivel de autoridad; y de manera organizacional, en cuanto a estructuras de mando, pues adquieren importancia las personas que saben operar el sistema de la empresa.

Todos estos elementos determinan a menudo si un sistema cumple o no sus objetivos, de forma exitosa. Para comprender los sistemas en las organizaciones, se tienen metodologas como la sociotcnica de Mumford y la metodologa de sistemas suaves de Checkland y Scholes. Por lo que es deseable que en la documentacin se incluya el conocimiento de la empresa o del negocio, para que se considere en el diseo. Normalmente los diseadores hacen suposiciones basadas en diseos anteriores y su sentido comn, por lo que, si son incorrectas el sistema no ser el adecuado o el funcionamiento se ver afectado con comportamientos inesperados. Tambin puede ser que en la empresa haya objetivos contradictorios entre las personas y entonces el sistema desarrollado, origine insatisfaccin en alguno. a) Procesos organizacionales Dado que los sistemas estn en un contexto organizacional o empresarial, es necesario tener nociones de lo que implica. El ingeniero de software debe ocuparse del software a desarrollar, conocer cmo interacta con otros sistemas o un hardware y la manera de emplearlo, de optimizar su diseo y participar como un integrante ms en un grupo de ingeniera de sistemas, es decir, entender y aplicar todo el alcance de un software. De esta manera, el proceso de desarrollo est vinculado al proceso de adquisicin del sistema, al proceso de uso y operacin del sistema como se observa en la siguiente imagen:

El proceso de desarrollo de software no slo se compone de sus propias actividades, existen tareas implicadas en el proceso de la ingeniera de sistemas.

Proceso de adquisicin. Este proceso es el que tiene el cliente en su empresa para comprar los sistemas, normalmente dirigidos por la toma de decisiones sobre la ptima manera de comprar el sistema o determinar los mejores proveedores. Los grandes y complicados sistemas se constituyen habitualmente por componentes o subsistemas comerciales o por el desarrollo especfico de componentes. Simplemente porque resulta muy til la reutilizacin de componentes, lo que se traduce en ahorro, que no es mucho, pues al ser adquirido, o de otro componente desarrollado, no cumple de manera exacta los requerimientos que se necesitan y hay que invertir. Algunas cuestiones importantes del proceso de adquisicin son mostradas en el siguiente diagrama:

Al elegir los componentes que se van a comprar se debe elegir el que est ms cerca de cubrir el requerimiento. Proceso de desarrollo. Una vez seleccionado quin desarrollar el sistema, hay un periodo de negociacin del contrato, el cual puede incluir costos adicionales por cambios. Escasas organizaciones tienen la posibilidad de desarrollar y probar todos los componentes de un sistema extenso y dificultoso, por lo que se puede dar el subcontratar a otro para desarrollar algn subsistema, o componente del mismo, para despus llevar a cabo la integracin. El subcontrato puede darse libremente o de acuerdo con una lista previa.

Procesos operativos. Son los procesos concernientes al uso del sistema. Son determinados y documentados durante el desarrollo de un sistema. Los problemas que se presentan durante su uso pueden deberse a requerimientos no especificados o con algn error. Tambin las funciones pueden no ajustarse al entorno operativo real y, por consiguiente, los usuarios del sistema no lo operarn como se esperaba. Los procesos operativos pueden modificarse para adaptarse al nuevo sistema o incluir algunos, necesitando que el personal se capacite. Los usuarios del sistema se enfrentan a situaciones reales e inesperadas, que el diseador pudo no contemplar y solamente la pericia y eficiencia de la persona salvaguarda el adecuado funcionamiento, aunque represente no llevar en forma el proceso, ya que ellos mismos lo adaptan o lo mejoran. As, los diseadores deben de tomar en cuenta esto y realizar procesos que sean flexibles y adaptables. El sistema no debe reducirse por no seguir un proceso especfico del negocio. Es comn que las reglas, polticas, normas o procesos cambien, y por ende se piense en remplazar un sistema, pero hay que ser meticuloso en este aspecto y ver el impacto de tal decisin, sobre todo si se trata de un sistema heredado. b) Sistemas heredados Los sistemas heredados se refieren a sistemas considerados como crticos dependientes de hardware o software obsoletos. Pero se mantienen por el riesgo catastrfico de remplazo. Estos se tratarn en la Unidad de aprendizaje de Soporte de software.

Conclusin
La ingeniera de software est inmersa en un entorno competitivo y cambiante, es la disciplina que crea software de calidad. As las empresas, organizaciones o instituciones aparte de estar a la vanguardia con su software permanecern y crecern gracias a l. El ingeniero de software debe buscar siempre nuevas tcnicas, mtodos, procesos y herramientas para cumplir con su objetivo ya que tiene un gran impacto en la economa.

UNIDAD 2
Actualmente la mayora de los sistemas y aplicaciones de software que se desarrollan se basan en tecnologas web. Sin embargo, a pesar de que este tipo de aplicaciones requieren ser desarrolladas en periodos cortos necesitan un proceso de creacin que involucra diferentes actividades. Por ello, en los siguientes temas conocers los sistemas y aplicaciones basados en web. Revisa el siguiente mapa de contenidos, el cual te ayudar a visualizar los temas y conceptos clave de esta unidad temtica II.

1. Elementos de la ingeniera web

En la unidad temtica anterior conociste los conceptos y elementos bsicos de la ingeniera de software as como la diferencia que tiene con la ingeniera de sistemas. Ahora es momento de que conozcas cmo aplicar estos conceptos en sistemas basados en tecnologa web, es decir, conocers los principales elementos que componen este tipo de aplicaciones. Podemos llamar a los sistemas y aplicaciones basados en la web con el trmino: webapps, el cual es la forma abreviada de las palabras en ingls: web applications.
Las webapps van desde pginas web que promocionan un producto hasta sistemas empresariales que gestionan grandes procesos de negocio de toda una corporacin.

1.1 Atributos de los sistemas y aplicaciones en web

Una vez que has identificado qu son las aplicaciones y sistemas basados en web, cabe sealar que existe una amplia gama de ellas y para conocer ms acerca de stas sealamos sus atributos a continuacin:

Con base en lo que acabamos de leer, nos damos cuenta de que los atributos de una webapp son muy obvios, sin embargo, desarrollar una aplicacin web que cumpla con todos los atributos anteriores es una tarea compleja, pero con ayuda de la ingeniera web podrs crearla. Sigue leyendo para saber cmo es posible lograrlo.

1.2 Proceso de la ingeniera web

Las webapps adems de contar con atributos tienen un proceso de creacin, el cual representamos en el siguiente esquema:

Como puedes observar, este proceso es iterativo, el ciclo se repite desde la formulacin y termina en la entrega obteniendo un nuevo incremento por cada iteracin. Pero, de qu trata cada actividad del proceso de ingeniera web? Despliega la siguiente ventana, lee e imagina al mismo tiempo lo que ah se te expone: Proceso de la ingeniera web odo comienza con la formulacin del problema, debemos comprender qu? y por qu? se crear la webapp. Ya que hemos encontrado las respuestas pasaremos a crear un programa de trabajo en funcin del tiempo y de los recursos disponibles. Es decir, vamos a planear el proyecto de creacin de una webapp.

El proyecto ya fue planeado, ahora es tiempo de comenzarlo. Pero recuerda que no debes codificar sin hacer antes un anlisis y diseo, esto sera un grave error. Ms adelante se te explicar el por qu, sin embargo, vale la pena que le dediques tiempo a estas actividades ya que te respondern la siguiente pregunta cmo se crea la webapp? Ahora que reflexionaste y creaste un buen modelado de anlisis y diseo, utiliza la tecnologa y las tcnicas de programacin para construir tu sistema a partir del diseo que creaste. Sin embargo, esto no te lo explicaremos, porque ya lo conoces e incluso lo dominas. Ya que terminaste la construccin de la webapp, sera un error entregarla sin hacer pruebas. Dedica un poco ms de tiempo para que pruebes y te cerciores que va de acuerdo con tu modelo. Ahora que has probado y corregido los errores que encontraste, puedes entregarlo. Felicidades ya tienes un incremento de software! Ahora esperemos la retroalimentacin del cliente.
Toma en cuenta que el proceso que se propone en esta unidad temtica es de tipo incremental, sin embargo, cuando el tiempo del que se dispone para la creacin de la webapp es muy reducido, podemos hacer uso de algn mtodo gil de programacin.

Como pudiste notar, el proceso de ingeniera web no es tan difcil de entender como aparenta. Durante esta unidad temtica estudiaremos las actividades del proceso de ingeniera web, con excepcin de la construccin y de la entrega. A continuacin te presentamos ms elementos del proceso de la ingeniera web que es necesario que conozcas antes de comenzar el estudio de las actividades que integran el proceso. a) Definicin y refinamiento del marco de trabajo Las actividades de un proyecto para la creacin de una webapp conforman lo que conocemos como marco de trabajo. Independientemente del tamao del proyecto la definicin de un adecuado marco de trabajo ser fundamental para su xito. La organizacin del equipo encargado del proyecto, los protocolos de comunicacin entre los integrantes del mismo -inclusive con el cliente-, las actividades de ingeniera de software, la gestin de la informacin del proyecto, los mtodos y tcnicas para entregar productos de calidad; se deben adaptar a

las necesidades de los usuarios, en cuanto a recursos humanos, tcnicos, tecnolgicos y sobre todo a los tiempos establecidos. Al definir el marco de trabajo para las webapps debemos tomar en cuenta tres aspectos:

Cuando se van adaptando las actividades a las exigencias del proyecto del cliente o del equipo mismo de ingeniera web, le llamamos refinamiento del marco de trabajo. En el refinamiento pueden surgir nuevas actividades, eliminarse otras o extenderse algunas. b) Mejores prcticas de la ingeniera web Antes de continuar conociendo ms acerca de la ingeniera web, es importante mencionarte algunas de las mejores prcticas para la misma que te sern de gran ayuda y que su aplicacin te ahorrar muchos problemas. Para ello descarga la Presentacin en Power Point titulada: Mejores prcticas.

Como habrs notado, las buenas prcticas mencionadas en esta seccin, tal vez puedan parecer obvias, sin embargo, muchas veces se olvidan y es cuando el proyecto se complica an ms. c) Peores prcticas para proyectos webapps En el inciso anterior conocimos acerca de las mejores prcticas para proyectos basados en web. De igual forma que existe este tipo de prcticas, tambin encontramos las antagonistas en los proyectos. Para conocerlas descarga la Presentacin en Power Point titulada: Peores prcticas.

Es importante que pongas atencin en el documento anterior que aborda las peores prcticas, ya que te ayudar a evitarlas o detectarlas cuando se cometan en los proyectos en los que te involucres y as puedas ejecutar las medidas necesarias para corregirlas o para evitarlas en el proceso de creacin. Pero no todo en la ingeniera web es el proceso y las buenas prcticas. Veamos ms conceptos.

1.3 Estratos de la ingeniera de webapps

La ingeniera de webapps est basada en estratos, cuya base es el proceso que, como vimos anteriormente, es el conjunto de actividades para el desarrollo de software. Adems del proceso, se establecen los mtodos, los cuales generan productos de trabajo como documentos, modelos, reportes, entre otros; y que ayudarn a construir el software. Por ltimo, encontramos el estrato de las herramientas y la tecnologa, que brinda un soporte automatizado o semiautomatizado para los estratos anteriores. A continuacin se muestra un diagrama con algunas caractersticas de cada estrato de la ingeniera web.

Como puedes observar en la imagen los estratos nos permiten concebir de una manera ms clara el alcance de la ingeniera web. Las herramientas y tecnologa son importantes, sin embargo si no contamos con mtodos, el proceso de ingeniera web no sera posible. Es como si quisiramos hacer ciencia sin un mtodo cientfico.

Durante los siguientes temas y subtemas de esta unidad de aprendizaje tendrs la oportunidad de conocer ms acerca de algunos conceptos presentados en la imagen anterior. De igual forma, revisaremos ms a fondo las tareas de modelado de una webapp.

2. Formulacin y planeacin de la ingeniera web

En los aos 90 con la comercializacin masiva de Internet a nivel mundial, las webapps comenzaron a desarrollarse aun cuando no tenan una razn de ser, ni un nicho de mercado o inclusive clientes potenciales. Muchos empresarios jvenes tuvieron xito y otros tantos fracasaron. El argumento del desarrollo de estas aplicaciones web era que ya no se requera ms de los procesos de ingeniera de software tradicionales y que se poda comenzar a construir y despus a conseguir a los clientes que compraran el producto. Hoy en da nos damos cuenta de que esto ya no funciona as y que, a pesar de necesitar procesos giles de desarrollo no podemos ignorar las primeras actividades de un proyecto desoftware: la formulacin del problema y la planeacin del proyecto, en este caso para webapps.

2.1 Formulacin de sistemas basados en web

La formulacin de sistemas basados en web est conformada por una serie de actividades de la ingeniera que van desde la identificacin de las necesidades del negocio, la descripcin de los objetivos de la webapp y la obtencin de requerimientos, con el fin de conducirlos al anlisis. Segn Roger Pressman, podemos ayudarnos para la formulacin buscando la respuesta a tres preguntas sencillas:

Las respuestas a estas interrogantes son las siguientes:

Otra tarea de la formulacin es establecer metas, las cuales pueden ser categorizadas en: informativas y aplicables. Las primeras aaden informacin de la webapp al usuario final. Las segundas, describen una tarea dentro de la webapp. Por ejemplo: una webapp creada para la venta de telfonos celulares en una tienda departamental, tiene como meta informativa que la aplicacin brinde informacin de tarifas y equipos al vendedor. Por otro lado, la meta aplicable sera que el usuario eligiera el plan tarifario y el equipo deseado para lo cual la aplicacin le har una cotizacin a 12 y a 18 meses. El siguiente paso es identificar a los posibles usuarios de la aplicacin y desarrollarles un perfil. El perfil es una descripcin de las caractersticas y preferencias del usuario. Ten presente que al inicio seguramente slo tendrs un cliente que utilizar el sistema, pero que hay mucha probabilidad de que tu nmero de clientes crezca, as como el nmero de usuarios y de perfiles requeridos para la webapp.

Una vez establecidas las metas y los perfiles de usuario, tendremos que determinar el mbito del software, con base en el contexto en que se desarrolla, los objetivos de informacin, las funciones que cumplir y su desempeo. Pressman sugiere que se formulen preguntas que determinen el mbito y que stas sean respondidas con enunciados claros y comprensibles. La siguiente tabla muestra algunas de estas cuestiones:

El objetivo de determinar el mbito de la webapp es anotar los datos cuantitativos, obtener restricciones y limitaciones e identificar factores de riesgo. Definido el mbito del software nos enfocaremos en recopilar los requerimientos para la webapp. Existen cuatro cursos de accin para lograrlo:

Como puedes observar, los cursos de accin mencionados son muy tiles e inclusive imprescindibles, por ejemplo, en la obtencin de requerimientos de los clientes, con el fin de desarrollar un sistema o aplicacin basada en web. Algunos otros son necesarios para continuar con el proceso de ingeniera web, como la categorizacin de usuarios y desarrollo de casos de uso. Ms adelante veremos por qu.

2.2 Planeacin de proyectos de ingeniera web

Recuerda que en la planeacin del proyecto se debe estimar el trabajo, los recursos, y el tiempo. Observa el siguiente cuadro en el que se representan las tareas que implica la planeacin de proyectos de ingeniera web.

En sntesis, al planear el proyecto de ingeniera web estamos estableciendo el marco de trabajo, haciendo estimaciones sobre costos, recursos y tiempos. El equipo de ingeniera de software deber adaptarse al plan del proyecto. Sin embargo, el plan debe ser flexible y actualizable a medida que el proyecto avanza.

2.3 Equipo de ingeniera web

Hemos mencionado el equipo de ingeniera web y para ahondar ms en l a continuacin veremos algunas caractersticas de este equipo de desarrollo. El equipo de ingeniera web debe ser capaz de combinar talento, entusiasmo y trabajo bajo presin. Esto no es fcil, sin embargo, parte del xito o fracaso de la planeacin de un proyecto depende del recurso humano destinado para l. Observa la siguiente tabla, la cual describe a los integrantes del equipo de ingeniera web.

Tal vez sea fcil construir un equipo de ingeniera, pero lo difcil es mantenerlo. Por lo que, a continuacin te sugerimos los siguientes puntos clave para mantener el equipo de ingeniera web durante un proyecto:

Establecer las reglas del juego. Para evitar malos entendidos en el equipo, es necesario establecer las directrices que se deben cumplir durante el proyecto. Algunas de ellas son, la forma de trabajar, la forma de comunicarse, a quin recurrir en caso de algn conflicto, etctera.

Definir un lder de equipo. El lder ser el gua del equipo de ingeniera. El lder debe tratar de mantener al equipo unido y es el responsable del mismo. Esto no quiere decir que l har todo, sino que encaminar los esfuerzos del grupo para conseguir el objetivo.

Hacer sinergia. Esto es la suma de las fortalezas y talentos individuales en un equipo, la cual ser siempre mayor que si cada miembro del equipo trabajara por separado. Es decir, como lo has visto a travs de la experiencia en esta carrera, cuando todo el equipo trabaja en conjunto se logra concluir el trabajo en el menor tiempo.

Comprometerse. No slo basta con los talentos individuales, en un equipo de ingeniera web necesitamos el compromiso de todos los miembros del equipo para desempear sus funciones de la mejor manera posible. Si no existe compromiso por parte de los integrantes, difcilmente se podr concluir el proyecto de acuerdo con la planeacin realizada.

Mantener el espritu de equipo. Muchos proyectos comienzan con un equipo motivado, durante el proyecto algunos integrantes se van desmotivando o perdiendo el inters por el proyecto. Estas situaciones, entre otras afectan al equipo. Es responsabilidad del lder de proyecto detectar cuando un miembro est menguando el espritu de equipo y aplicar los cursos de accin pertinentes para recuperarlo.

Como puedes darte cuenta, un equipo de ingeniera web es otro tipo de equipo de trabajo, en el cual las actividades y funciones deben distribuirse de acuerdo con el perfil que tenga cada integrante para explotar sus talentos individuales y optimizar los tiempos.

2.4 Medicin para la ingeniera web y webapps

La medicin del software en general sirve para mejorarlo, rastrearlo y aumentar su calidad. En una webapp adems puede mejorarse la manejabilidad, el desempeo y la satisfaccin del cliente. Segn Pressman, la medicin en la ingeniera web tiene tres objetivos:

Entre las mediciones que proporcionan indicadores de calidad, encontramos que este mismo autor sugiere las siguientes mtricas para estimar el esfuerzo que realizan los ingenieros web.

Adems de medir el esfuerzo, otro de los objetivos es saber el xito que tiene o tendr la aplicacin web en el campo empresarial para mejorar su rentabilidad. Para ello, una de estas mediciones es la Web Quality Model (WQM) la cual es un modelo tridimensional dividido de la siguiente manera: 1. Componentes del sitio web. Los componentes considerados en esta dimensin son presentacin, navegacin y contenido.

2. Caractersticas de calidad. Toma en cuenta mediciones para: funcionalidad, fiabilidad, usabilidad, eficiencia, portabilidad y mantenibilidad.

3. Procesos de ciclo de vida. Se hacen estimaciones sobre los siguientes procesos: desarrollo, explotacin, mantenimiento, esfuerzo y reutilizacin.

Cuando se utiliza WQM, se forma un cubo, en el cual se pueden detectar regiones donde exista carencia de mtricas. Una vez detectado este tipo de regiones, hay que implementar las mtricas en nuestra webapp ya sea para aumentar la calidad, el rendimiento o disminuir fallos en la misma. Adems de las mtricas mencionadas en esta seccin, existen herramientas de software que nos ayudarn a medir nuestra webapp. Algunas de estas herramientas son: Clicktracks, Marketforce, Web Metrics, WebTrends, entre otras. Hasta el momento hemos identificado los elementos a considerar para las dos primeras actividades del proceso de ingeniera web, como son la formulacin y la planeacin. De igual forma hemos aprendido acerca del equipo de trabajo que participa en un proyecto de creacin de una webapp. Una webapp implica mucho ms que eso, por ello te invitamos a que sigas leyendo los siguientes temas.

3. Modelado de anlisis para aplicaciones web

A pesar de que una de las caractersticas en la realizacin de las webapps es la inmediatez, la cual demanda ciclos cortos de desarrollo, el anlisis de la webapp debe hacerse y modelarse. En el tema anterior vimos cmo formular y planear una aplicacin basada en web. Entre los productos finales de esa fase encontramos la creacin de casos de uso donde se representa cmo el usuario va a interactuar con el sistema. Entonces, partiendo del caso de uso y de los requerimientos obtenidos para la aplicacin web comenzaremos a modelar el anlisis de la webapp.

3.1 Requisitos de anlisis para aplicaciones web

La intencin de realizar un anlisis para una aplicacin web es lograr comprender la razn por la cual se construir sta, quines la usarn y qu funciones proveer a los usuarios. Por ejemplo:

Antes de comenzar a modelar el anlisis necesitamos cumplir con los siguientes requisitos: jerarquizar a los usuarios y desarrollar casos de uso. Para llegar a los requisitos anteriores se debe realizar una obtencin de requerimientos de la webapp y tambin crear categoras de usuario. Si an no comprendes por qu, te sugerimos volver a leer el tema anterior antes de continuar. En la siguiente tabla se muestran los requisitos necesarios para dar inicio al modelado del anlisis de las webapps.

El sistema de venta de celulares con el que se dan estos ejemplos, y en adelante, es un sistema web para venta de celulares en una tienda departamental. Existe una versin de este sistema para realizar la venta desde un CallCenter. No es un portal B2C como el que usan las compaas de telefona celular, donde los clientes finales pueden utilizarlo. Es para uso exclusivo de los vendedores.

3.2 Modelado de anlisis para webapps

Basndonos en los casos de uso podemos disear un modelo para el anlisis de nuestra webapp, este modelo ser entregado a los diseadores de la misma para que continen con el proceso. El modelado bsico para una webapp incluye cuatro tipos de anlisis . Observa la siguiente animacin:

En los siguientes subtemas trataremos ms a fondo cada tipo de anlisis. a) Anlisis de contenido El contenido de una webapp es toda aquella informacin preexistente que se presenta al usuario final. El contenido dentro de una aplicacin basada en web puede ser desarrollado antes de que se cree la aplicacin, durante su creacin o incluso despus de su implementacin. Por ejemplo, el contenido de esta unidad de aprendizaje fue desarrollado previamente a la programacin de los vnculos de la misma y puede ser actualizado cuando cambie el programa de estudios. Los contenidos siempre deben analizarse previamente.

El anlisis de contenido nos ayudar a identificar los objetos de contenido con que contar la webapp, el cual va desde simple texto hasta contenido multimedia. Los productos finales de este anlisis son un rbol de datos y un diagrama de clases con los elementos extrados de los casos de uso. Un objeto de contenido es cualquier aspecto de informacin cohesiva que se presente al usuario final. Por ejemplo, puede ser un archivo de texto, una imagen, una cancin en formato mp3 o un video. En las pginas web que se ilustran abajo, al igual que en cualquier otra por la que navegues, se encuentran una gran variedad de objetos de contenido. Es ms, el mismo texto que ests leyendo en este preciso momento es un objeto de contenido.

Los objetos de contenido se extraen de los casos de uso. Y stos pueden identificarse al realizar un rbol de datos, en el cual se representa una jerarqua de informacin de la descripcin de un componente. Observa el siguiente rbol de datos para un producto.

En el diagrama puedes ver que un producto consta de nmero de serie, modelo, descripcin y precio. Los rectngulos que no estn sombreados representan datos simples o compuestos. Por otro lado, los rectngulos sombreados representan los objetos de contenido. De esta forma la descripcin del producto puede representarse mediante diferentes objetos de contenido como una fotografa, una descripcin de especificaciones tcnicas o un video. Las clases de anlisis son las entidades visibles para el usuario, que se crean o manipulan cuando l mismo interacta con la aplicacin. stas se obtienen al examinar los enunciados de casos de uso, lo que ya has venido realizando tambin en otras unidades de aprendizaje. Sin embargo, te recordaremos de manera breve cmo hacerlo. Los enunciados del caso de uso se analizan gramaticalmente buscando los sustantivos que se encuentran en ellos, subrayndolos de ser posible. Una vez que hemos subrayado los sustantivos debemos categorizarlos y elegir las clases candidatas con base en los siguientes rubros:

Elementos tangibles: telfono mvil, tarjeta SIM, etctera. Roles: vendedor, cliente, entre otros. Eventos: registro, validacin. Interacciones: compra, cancelacin, etctera.

Luego, se debe hacer un refinamiento de las clases candidatas tomando en cuenta los siguientes criterios:

Redundancia. Cuando a una clase ya se le ha dado un nombre previamente. Por ejemplo, supongamos que se identificaron tres clases candidatas: Cliente, ClienteWeb y ClienteMostrador, se podran eliminar las ltimas dos clases, quedndonos nicamente con Cliente.

Recordando la jerarquizacin de usuarios los otros dos seran tipos de clientes. Imprecisin. Cuando no sabemos el significado de la clase, o existe ambigedad en ella. Por ejemplo en la claseRegistro, podemos preguntarnos Registro de qu cliente, compra o venta? Cules seran los atributos, o los mtodos? Es difcil determinarlo no crees? Por eso es importante que tomes en cuenta este aspecto. Un evento. Si es algo que se hace en el sistema. Por ejemplo la clase Validacin es un caso de uso requerido para la ejecucin de otro. Es decir, se debe cumplir el evento validacin para registrar a un cliente. Fuera del alcance del sistema. Cuando la clase no hace relevancia a los elementos del sistema. Un atributo. Es parte de una clase, mas no la clase misma.

Cuando hemos obtenido las clases candidatas hay que identificar los atributos y mtodos de cada una. Posteriormente para establecer las relaciones entre las clases podemos hacer un anlisis CRC (Clase Responsabilidad Colaborador). Una vez obtenidas las clases de anlisis y sus relaciones slo hay que representarlas en un diagrama de clases de UML. Ahora s ya tenemos el anlisis de contenido.

b) Anlisis de interaccin El modelo de interaccin nos permitir representar cmo ser la comunicacin entre los usuarios y la webapp. Est integrado por los siguientes elementos: diagramas de casos de uso, diagramas de secuencia y diagramas de estado. Adems de un cuarto elemento que nos permitir mostrar un gran avance a nuestro cliente; el prototipo de la interfaz de usuario. Veamos de qu trata cada elemento de este modelo.

Diagrama de casos de uso Tal vez te parezca redundante que todava en esta instancia del proceso de ingeniera de software te sigamos hablando de los diagramas de casos de uso, pero sern necesarios durante todo el proyecto de ingeniera web. En la formulacin obtuvimos los diagramas de casos de uso, los refinamos agrupndolos por paquetes funcionales. Ahora es turno de volverlo a ocupar para generar el siguiente diagrama del modelo de interaccin. Y es que no slo basta con un diagrama de casos de uso, ya que conforme avancemos en el modelado se requerirn ms niveles de detalle. Diagramas de secuencia Como puedes recordar, un diagrama de secuencia muestra la siguiente informacin:

Los actores y objetos que participan en la interaccin. La secuencia de mensajes intercambiados.

Los principales elementos del diagrama son los actores con sus lneas de vida, los objetos o instancias de las clases y los mensajes intercambiados en forma secuencial. Colocando primero los objetos que interactan entre ellos. Debido a estas caractersticas se trata de un tipo de diagrama muy importante y sencillo para representar la interaccin entre los actores y la webapp. Es recomendable realizar un diagrama de secuencia por cada caso de uso que se tenga. Observa el siguiente ejemplo:

En este diagrama puedes observar una sencilla interaccin y la secuencia de acciones que una instancia de vendedor tiene con los diferentes objetos disponibles en el inventario para realizar un contrato de venta de un plan de telefona mvil. Cabe mencionar que la interaccin puede ser ms detallada o que podemos incluir el nombre de los mtodos en lugar de frases. Por ejemplo podramos sustituir la frase consulta planes disponibles por el mtodo consultaPlanes( ). Diagramas de estado Los diagramas de estado complementan una dimensin ms del diagrama de interaccin. Indica las acciones que se requieren para mover un objeto de un estado a otro, el procesamiento que ocurre dentro de un estado y la condicin de salida que provoca las transicin de un estado a otro. El siguiente es un diagrama de estados por los cuales pasa el producto de telefona mvil desde que se carga en el sistema hasta que se activa.

Prototipo de interfaz de usuario Por ltimo, se crea un entregable para el usuario, que es su propia interfaz. Esto se realiza con base en las categoras de usuario, de tal forma que los usuarios obtengan la sensacin de que ya se est trabajando el producto final de sus requerimientos. La interfaz de usuario tambin se puede dejar para la fase de diseo. Sin embargo en la fase de anlisis, es muy til para recibir retroalimentacin de lo que esperan ver los usuarios. El producto de este anlisis es un bosquejo de pantallas o incluso algunas interfaces programadas en HTML que no contienen funcionalidad ni lgica de negocio.

c) Anlisis funcional Los modelos anteriores describen el contenido y la interaccin con el usuario, pero todava desconocemos los procesos que se manejarn para que esto sea posible. El modelo de anlisis funcional nos permitir representar en diferentes niveles de abstraccin las operaciones de las clases de anlisis.

El objetivo es obtener un modelo para la implementacin de los mtodos identificados para cada clase de anlisis. Estas operaciones sern representadas con un pseudocdigo y diagramas UML de actividades. La razn por la cual la representacin es en diferentes niveles de abstraccin es porque al estar modelando podemos dejar algunos detalles de implementacin de las operaciones para la fase de diseo. Revisemos alguna informacin relevante acerca del pseudocdigo y de los diagramas de actividades. En los primeros semestres de tu carrera como tcnico en desarrollo de software, te solicitaban hacer programas pero antes de ellos haba que hacer un algoritmo y escribirlo, como buena prctica, con instrucciones que no estuvieran relacionadas completamente a la sintaxis de algn lenguaje de programacin en especial. A estas instrucciones le llamamospseudocdigo y lo utilizaremos para describir las operaciones de las clases de anlisis. Adems de escribir el algoritmo, lo representbamos grficamente en un diagrama de flujo con smbolos muy particulares pero descriptivos. En nuestro modelo ocuparemos un diagrama muy similar a este tipo de diagramas para representar el pseudocdigo de manera grfica, a ste se le conoce como diagrama de actividades UML. Un diagrama de actividades tambin es un diagrama de flujo que muestra el flujo de control entre actividades. Algunas diferencias notables son:

La disminucin de smbolos utilizados en el diagrama. Podemos representar actividades concurrentes utilizando barras de sincronizacin. Utilizacin de carriles para diagramas por zonas.

A continuacin te presentamos un diagrama de actividades genrico que se utiliza en este tipo de diagramas:

El diagrama representa una actividad genrica, con diferentes opciones de condicin de guarda, si se cumple la condicin 1, ejecutar otra actividad genrica y por ltimo finalizar. Sin embargo, si se cumple la condicin de guarda 2, se ejecutarn dos actividades en forma paralela y al final cada una de ellas se sincronizar para dar pie a una ltima actividad antes de finalizar. Al finalizar el modelado del anlisis funcional entonces sabremos adems de qu se hace y quin lo hace; el cmo se hace. d) Anlisis de configuracin Una webapp debe adaptarse a diferentes ambientes tanto del lado del servidor como del cliente. El objetivo de este anlisis es tener una visin ms amplia de los posibles entornos de ejecucin del sistema basado en web.

La webapp puede residir en un servidor o en varios servidores conectados en red. En este modelo, tambin deben contemplarse los sistemas operativos donde se podr ejecutar la aplicacin, as como el hardware en el que correr. Tambin los aspectos de interoperabilidad deben considerarse. Es decir, si se requiere de conexiones a bases de datos distribuidas a otros sistemas empresariales, se deben especificar los protocolos que se utilizarn y las interfaces para esta interoperabilidad. Del lado del cliente, se debern mencionar los navegadores soportados por la webapp, el software o plugins necesarios para descargar y ver el contenido, entre otros aspectos. El resultado final del modelo de configuracin es un listado de atributos y caractersticas para la operacin de la aplicacin tanto del lado del cliente como del servidor. En algunas aplicaciones ms complejas o grandes, se recomienda complementar el modelo con un diagrama de despliegue UML.

3.3 Anlisis relacin-navegacin

En un sistema basado en web, la navegacin es muy importante. De lo contrario, se puede llegar a dar el caso, en el que el usuario tenga que salir de la aplicacin y volver a entrar debido a que lleg a un punto en el que no haba forma de regresar ni al men principal, lo cual resulta muy molesto.

Para evitar este tipo de problemas, debemos realizar un anlisis relacinnavegacin que nos ayudar a establecer los vnculos adecuados entre los objetos de contenido y los elementos funcionales de la webapp. Un anlisis de este tipo se puede efectuar en los siguientes pasos: 1. 2. 3. 4. Categorizacin y jerarquizacin de usuarios. Anlisis de objetos de contenido y elementos funcionales. Anlisis de relaciones. Anlisis de navegacin.

Los primeros dos pasos ya los hemos estudiado. Ahora nos enfocaremos en los siguientes pasos de este tipo de anlisis. El anlisis de relaciones se realizar por cada objeto de contenido o elemento funcional identificado en el modelo de anlisis. Una tcnica para hacer el anlisis de relaciones es a travs de preguntas sobre los elementos. Roger Pressman retoma de J. Yoo y Bieber las siguientes preguntas:

Puedes formular otras preguntas que creas necesarias, recuerda que el objetivo es posicionar el objeto de contenido, o elemento funcional, dentro de la webapp y establecer sus relaciones con otros. Una vez que hemos determinado las relaciones entre los elementos, el ltimo paso es definir de manera general cmo ser la navegacin de cada categora de usuario, identificada en el paso 1, a travs de estos elementos. De nueva cuenta, un conjunto de preguntas por cada categora de usuario nos ayudarn a definir la navegacin.

Una vez respondidas estas preguntas y finalizado el anlisis, podemos realizar un sencillo mapa que describa de manera general la navegacin, o lo podemos hacer detalladamente hasta la siguiente actividad del proceso de ingeniera de software; el diseo. Mientras avance el proyecto de software, te dars cuenta de que las actividades del proceso de ingeniera de software son iterativas y el anlisis no es la excepcin. As que no debemos negarnos a realizar nuevamente un anlisis cuando sea necesario, y esto posiblemente sea despus de crear un incremento de software y recibir la retroalimentacin del cliente o el usuario.

4. Modelado para el diseo de aplicaciones web

Cuando tratamos con webapps es muy difcil lograr conjuntar la funcionalidad, la arquitectura y la esttica, sobre todo cuando se tiene poco tiempo para crearla. En algunas aplicaciones web se invierte el tiempo pertinente en el modelado del anlisis, pero no as en el diseo. Muchas de ellas han fracasado y otras tantas, a pesar de que contienen la lgica del negocio o del dominio, dejan mucho que desear a los usuarios.

4.1 Temas de diseo para la ingeniera web

Durante el transcurso de tu carrera como Tcnico en Desarrollo de Software has estudiado algunos conceptos acerca de la calidad del software, incluso has conocido algunas mtricas para determinar si un software cuenta con estos

estndares. En este caso, la calidad se utiliza para las aplicaciones y sistemas basados en web. Si una webapp no es de calidad fracasar. Pero cmo disear una webapp de calidad? La mejor manera sera preguntarles a los usuarios que la utilizarn, ya que el concepto de una buena webapp es muy subjetivo. Mientras algunos usuarios prefieren las webapps con animaciones as como con contenidos de audio y video; a otros, les gusta que tengan suficiente informacin y ligas hacia sitios externos; a unos ms, que tengan widgets para entretenerse; y otros simplemente buscan la funcionalidad esperada. Sin embargo, independientemente de lo que les guste a los usuarios, una webapp de calidad debe reunir ciertas caractersticas. Observa la siguiente animacin que representa el rbol de la calidad de una webapp:

Puedes formular otras preguntas que creas necesarias, recuerda que el objetivo es posicionar el objeto de contenido, o elemento funcional, dentro de la webapp y establecer sus relaciones con otros. Una vez que hemos determinado las relaciones entre los elementos, el ltimo paso es definir de manera general cmo ser la navegacin de cada categora de usuario, identificada en el paso 1, a travs de estos elementos. De nueva cuenta, un conjunto de preguntas por cada categora de usuario nos ayudarn a definir la navegacin.

Como podrs notar algunas caractersticas de calidad de la webapp son semejantes a los atributos de las webapps presentados al inicio de esta unidad temtica. Esto se debe a que una webapp forzosamente debe ser de calidad. De lo contrario estamos perdiendo el tiempo al construirla. Y siguiendo nuestro rbol de calidad, surgen algunas metas que debemos alcanzar con el diseo de la webapp, para conocerlas observa la siguiente animacin:

Como puedes observar, una webapp por s sola es exigente, pero solamente el usuario final ser el juez de la calidad de nuestra webapp. Sin embargo, podemos anticiparnos a ganar algunos puntos en su calificacin final si evaluamos la webapp con algunas preguntas para determinar la calidad del contenido que presentaremos al usuario. Por ejemplo, algunas de estas interrogantes son:

Las preguntas anteriores nos las formulamos implcitamente cada que navegamos a travs de diferentes sitios web en busca de informacin. Tomamos lo que nos sirve y desechamos lo que no. No permitas que esto ltimo pase con el software que disees.

4.2 Pirmide para el diseo web

El diseo de una aplicacin basada en web es una mezcla de esttica, contenido y tecnologa, pero la mezcla vara dependiendo de la naturaleza de la webapp. Podemos conceptualizar el diseo web a travs de un conjunto de actividades estratificadas que forman una pirmide en cuya base se encuentra el diseo de componentes y en la punta el diseo de la interfaz. Sin embargo, todas las dems actividades de la pirmide son importantes para obtener un buen diseo. Coloca el ratn sobre cada estrato de la pirmide para ver su descripcin.

Como puedes notar, los modelos de diseo estn fuertemente relacionados con los modelos de anlisis, si an no te queda clara esta relacin, te sugerimos darle un repaso al tema anterior sobre el modelado de anlisis para webapps. Una vez aclarando este punto, ahora s es momento de emprender nuestro viaje a travs de la pirmide del diseo web. a) Diseo de la interfaz Una de las actividades bsicas del diseo es precisamente la interfaz del usuario, ya que a travs de ella el usuario podr interactuar con la webapp. La interfaz debe ser intuitiva, es decir, que sea fcil de utilizar sin necesidad de un manual de referencia. Pero su diseo no slo debe cumplir este objetivo, revisemos algunos otros:

Establecer una ventana congruente con el contenido, las funciones que brinda y los requerimientos del negocio. El diseo esttico que veremos en el siguiente tema, nos ayudar a comprender mejor este objetivo.

Guiar la interaccin del usuario con la webapp. Una tcnica para lograrlo consiste en establecer metforas en la interfaz. Las metforas hacen que el usuario experimente la sensacin de que est trabajando con un objeto del mundo real. Por ejemplo, cuando utiliza los controles de un reproductor multimedia, los cuales son muy parecidos a los de su reproductor de audio y video de bolsillo.

Organizar las opciones de navegacin y contenido. Para lograr esto, debemos recurrir a mecanismos de control de la interfaz, como los que se muestran a continuacin en la siguiente tabla.

Ahora que conoces los objetivos de una interfaz y los recursos con los que puedes disearla es importante que establezcamos un flujo de trabajo para su diseo. Este flujo ir desde la identificacin de los usuarios y sus necesidades hasta el refinamiento del modelo de diseo de la interfaz. A continuacin, te proponemos un flujo para el diseo de la interfaz.

Para concluir con este tema, nos gustara darte algunas sugerencias que el autor Keneth Kendall propone para el diseo de interfaces web, esto podrs revisarlo en el siguiente PDF titulado: Diseo de pginas de intranet e Internet.

b) Diseo esttico Recordemos que uno de los objetivos del diseo de la interfaz consiste en establecer una ventana congruente con el contenido, las funciones que brinda y los requerimientos del negocio. Esto no sera posible, sin ayuda del diseo esttico de la webapp. Si conseguimos que una aplicacin basada en web sea esttica y funcional, lograremos que los usuarios adquieran un vnculo emocional con ella y, por lo tanto, sean ms productivos. Por esta y otras razones, debemos invertir recursos en el diseo grfico de una webapp. Tambin, el diseo, en este caso el esttico, estar en funcin de la jerarqua de usuarios que se hizo en la fase de anlisis. Una pregunta sencilla, pero muy importante, nos facilitar esta actividad: qu desea ver el usuario?

De igual forma que el diseo de la interfaz, el diseo esttico tambin tiene un conjunto de tareas que van desde la distribucin de la plantilla, eleccin del color, tipo de fuente, estilos, etctera.

Una pgina web tiene una cantidad limitada de espacio para acomodar los elementos visuales de la misma. Por ello, es importante que tomes en cuenta algunos aspectos para aprovechar este espacio, sin saturarlo de tal forma que cause desagrado al usuario. Veamos algunas recomendaciones sobre la distribucin de la plantilla en la siguiente animacin:

La eleccin del color es otro aspecto fundamental del diseo esttico, los colores muy contrastantes en todos los planos de la pantalla son desagradables, cansan la vista y dificultan la ubicacin del contenido.

Ejemplo de un mal diseo

Para evitar una mala eleccin del color, como en la pantalla del ejemplo, lee el siguiente PDF titulado: Uso del color en el diseo de pantallas, tomado del libro de Kendall & Kendall.

Existen otras cuestiones de diseo esttico que debes tomar en cuenta, de hecho podramos desarrollar una o varias unidades de aprendizaje para tratarlas. Sin embargo, si te interesa conocer ms sobre diseo esttico, en Internet se encuentra una amplia gama de sitios que puedes consultar, como los que se muestran a continuacin en Para saber ms. www.graphic-design.com www.dtg-forums.com

www.grantasticdesigns.com www.wpdfd.com c) Diseo de contenido El diseo de contenido est estrechamente relacionado con el anlisis de contenido. De hecho, se ocupan los objetos que se identificaron en dicho anlisis. El objetivo es crear un diseo de contenido para que otros especialistas como publicistas, escritores, autores de contenido y diseadores grficos lo desarrollen. El principal elemento de este tipo de diseo es el objeto de contenido, el cual tiene atributos que se identifican tanto en la fase de anlisis y otros tantos durante la fase de diseo. Adems de trabajar con los atributos de los objetos de contenido tambin seguimos trabajando con las relaciones que existen entre ellos. El producto final de este diseo ser un diagrama de clases parecido al diagrama que obtuvimos del anlisis, pero ms refinado y detallado. Observa el siguiente diagrama de clases que representa el diseo de contenido.

El nmero de objetos de contenido que se presentan en una pgina individual est en funcin de las necesidades del usuario, as como el ancho de banda para descarga y la tolerancia al desplazamiento vertical del usuario que la utilizar. d) Diseo arquitectnico Hasta ahora se han obtenido los objetos de contenido y diseo, incluso tal vez hasta se han desarrollado. Pero no slo basta con eso, es necesario crear una estructura para colocarlos. De igual forma, se necesita una estructura que

soporte a nuestra aplicacin basada en web, de eso se ocupa el diseo arquitectnico. Por lo que, los dos tipos de diseo arquitectnico que se deben realizar son:

Diseo arquitectnico del contenido Diseo arquitectnico de la webapp

El diseo arquitectnico del contenido trata de la estructura general que soportar el contenido. Existen cuatro tipos de estructuras para ello. Observa la siguiente tabla:

Ahora que conoces los tipos de estructuras arquitectnicas, es importante mencionar que no es forzoso que se utilice slo una, stas se pueden combinar para aprovechar las bondades de las mismas para nuestra aplicacin basada en web. Por otro lado, el diseo arquitectnico de webapps debe permitir alcanzar los objetivos empresariales utilizando una infraestructura como la que se describe en el prrafo siguiente, que Roger Pressman toma de D. Jacyntho:

Las aplicaciones deben construirse con el empleo de capas en las que se tomen en cuenta distintas preocupaciones; en particular, los datos de la aplicacin de los contenidos de sta (modos de navegacin), y de stos, a su vez, deben separarse con toda claridad del aspecto y la sensacin de la interfaz (pginas). De la cita anterior, podemos resaltar el trmino: construccin por capas, pero qu significa esto? La arquitectura de un software se distingue segn la organizacin de los elementos en capas. Por ejemplo, si se tiene un grupo de objetos para el manejo de la funcionalidad y del acceso a las bases de datos y otro para interactuar con el usuario, se dice que la arquitectura es de dos capas. Muchas aplicaciones web estn diseadas de esta forma. Sin embargo, la ingeniera de software para ingeniera web propone una tercera capa de tal forma que desacople la interfaz, de la lgica del negocio y del acceso a los datos. Esta arquitectura de la que hablamos es el conocido MVC (Model-View-Control) o Modelo-Vista-Controlador muy utilizado en la programacin con Smalltalk. La primera capa, el modelo corresponde a la informacin; la segunda, la vista corresponde a la presentacin de la informacin o interaccin con el usuario; la tercera, el controladorcorresponde al comportamiento, la lgica del negocio o la manipulacin de la informacin.

Arquitectura MVC de una webapp

Si una aplicacin est diseada con una arquitectura MVC, al modificar una capa, no deber afectar a las otras dos, por lo tanto, la construccin de cada capa de la webapp podra darse en diferentes momentos y por diferentes especialistas o incluso concurrentemente. e) Navegacin La navegacin define las rutas por las que los usuarios acceden al contenido y a las funciones de una aplicacin basada en web. Adems de la forma en cmo se realizar este acceso. Del prrafo anterior logramos identificar dos elementos del diseo de la navegacin: semntica y sintaxis. La semntica se refiere al diseo de estructuras de informacin y navegacin relacionadas que colaboran en el cumplimiento de un subconjunto de requisitos de los usuarios que interactan con la webapp. Dichas estructuras se conocen como Unidades Semnticas de Navegacin o USN. De igual forma que otros tipos de diseo, las USN se obtienen de los casos de uso y de la jerarquizacin de usuarios, ya que la forma de navegacin para cada usuario es distinta. Una USN est compuesta por Formas de Navegacin (FdN), las cuales representan la mejor ruta de navegacin para que un usuario, con cierto perfil, logre su meta o submetadeseada. A su vez, las FdN estn formadas por nodos de navegacin conectados por vnculos de navegacin. As que, se debe crear una USN por cada caso de uso de los usuarios identificados en la jerarquizacin. Por otro lado, la sintaxis de navegacin define los mecanismos utilizados para la misma. Algunos de ellos te los mostramos en la siguiente tabla:

Existen otros auxiliares de navegacin como botones tridimensionales, efectos de audio, identificacin de vnculos ya visitados, etc. El uso de estos auxiliares le da una apariencia amigable a la webapp. f) Diseo al nivel de componentes Para hablar de este diseo, es importante comenzar recordando qu es un componente? Por lo que podemos definir a un componente desde tres enfoques, como lo muestra la siguiente tabla:

Los anteriores enfoques nos ayudan a definir un componente como: un elemento de software modular, desplegable, reemplazable y reutilizable que encapsula su implementacin y expone un conjunto de interfaces. Cuando diseamos por componentes tenemos que tener presentes dos aspectos: alta cohesin y bajo acoplamiento. La cohesin se refiere al grado en que las partes o clases que forman al componente estn estrechamente relacionadas entre s. Por otro lado, el acoplamiento se refiere al grado en que los componentes se conectan y son interdependientes de otros. A continuacin te sugerimos un flujo de trabajo para el diseo a nivel de componentes:

Segn Roger Pressman, los componentes para aplicaciones basadas en web deben tener algunas de las siguientes capacidades:

Proveer capacidad de contenido y navegacin. Capacidad de procesamiento de datos para el dominio del negocio. Proporcionar accesos a bases de datos. Establecer interfaces. Es importante que no confundas las interfaces de un componente con las interfaces de usuario. Las primeras proveen los mtodos para comunicarse con el componente; las segundas proveen los elementos para la interaccin con el usuario.

Los puntos anteriores nos llevan a reflexionar acerca de la necesidad de tomar en cuenta el diseo de contenido y el funcional, pero a nivel componente. El primero se centra, como bien hemos visto, en objetos de contenido y en la forma en que se empaquetan para su representacin al usuario. El segundo, en el procesamiento y la lgica del negocio.

4.3 Patrones de diseo hipermedia

Antes de comenzar con este subtema, recordemos qu es un patrn de diseo. Un patrn de diseo es una estructura de conocimiento que brinda una solucin probada a un problema de diseo dentro de cierto contexto y con ciertas condiciones dadas. Del prrafo anterior podemos inferir que el diseo basado en patrones busca reutilizar elementos de diseo que fueron exitosos en el pasado. Sin embargo, esto no quiere decir que utiliza exactamente el mismo diseo, sino que lo adapta. Cuando hablamos de patrones de diseo hipermedia nos estamos refiriendo a los patrones de diseo que podemos aplicar para las aplicaciones basadas en web. Podemos distinguir los siguientes tipos:

Existen muchos otros patrones de diseo que puedes encontrar en Internet. La siguiente es una liga muy til, es de un sitio de patrones de diseo para webapps en Java. Vale la pena que la revises, da clic en la liga de la seccin Para saber ms. http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

4.4 Mtodo de diseo hipermedia orientado a objetos

El mtodo de diseo hipermedia orientado a objetos mejor conocido como MDHOO fue propuesto por Daniel Schwabe. Este mtodo est compuesto por cuatro actividades: diseo conceptual, diseo de navegacin, diseo abstracto de la interfaz e implementacin. La siguiente animacin representa un resumen de las actividades mencionadas en el prrafo anterior.

4.5 Mtricas de diseo para webapps

Actualmente las mtricas para diseo de aplicaciones basadas en web se continan desarrollando y, por lo tanto, no estn totalmente validadas para formar un estndar que pueda ser utilizado para todas las webapps. Sin embargo, podemos definir las nuestras auxilindonos con algunas preguntas como:

En Internet podrs encontrar ms informacin sobre mtricas, las cuales te ofrecern una visin de la calidad del diseo de una webapp o por qu no? disear unas nuevas. Como habrs notado el diseo de una webapp es muy interesante e implica conocer y comprender lo que quiere ver el usuario y cmo lo desea ver. Sin embargo, el diseo necesita creatividad y perspicacia para

lograr una aplicacin basada en web que sea atractiva para el cliente y adems funcional.

5. Pruebas para aplicaciones web

Cuando desarrollamos aplicaciones web, adems de invertir tiempo en anlisis y diseo, tambin lo debemos hacer para probar la aplicacin una vez que ya fue construida y antes de que salga a produccin y que sea el usuario final el que la pruebe. Lo anterior, se realiza con un nico objetivo en mente: encontrar errores y corregirlos, para mejorar la calidad de la webapp. De esta manera, los errores se buscarn a travs de diferentes modelos de anlisis y diseo ya implementados, comenzando desde lo ms visible para el usuario hasta lo menos visible pero importante para nuestro sistema o aplicacin basada en web.

5.1 Prueba de conceptos para webapps

Como ya se ha dicho, una prueba es el proceso de ejercitar al software con la finalidad de encontrar errores y corregirlos. En el caso de las webapps, el reto es mayor debido a las variables que afectarn los resultados como el uso de diferentes navegadores y plataformas. Por esta razn, debemos tomar en cuenta algunos conceptos antes de comenzar el proceso de prueba: la calidad de la webapp, los errores naturales, la estrategia y la planeacin de las pruebas. El primer concepto, la calidad, busca evaluar si el diseo de la webapp es bueno. Recuerdas el rbol de calidad? Si es as, podrs notar que los elementos de calidad evaluados en el proceso de pruebas son semejantes. En otro caso, te sugerimos que regreses a la primera seccin del tema anterior. Para continuar, observa la siguiente tabla:

Como habrs observado, cada uno de estos factores que se evalan en una webapp, permitirn aumentar su calidad. El segundo concepto, son los errores que se derivan de la naturaleza misma de las webapps. Estos pueden surgir en las siguientes circunstancias:

El error se hace presente en el lado del cliente. Sin embargo, muchas veces puede que el origen no sea dnde se manifiesta.

Debido a que una webapp se ejecuta en diferentes ambientes y configuraciones, puede ser difcil o incluso imposible reproducir el error fuera de las condiciones en las que se produjo.

Cuando se construye la aplicacin generalmente se cometen errores en la codificacin, sobre todo si no se utiliza un estndar.

Los errores de ambiente operativo pueden ser estticos (en la configuracin especfica en la que se aplica la prueba) o dinmicos (relacionados con diferentes cargas o tiempos de ejecucin).

El tercer concepto es la estrategia que se utilizar para probar el sistema o la aplicacin basada en web. A continuacin te sugerimos una, que consiste en los siguientes puntos:

El cuarto concepto, y ltimo, es la creacin de un plan que definir el conjunto de pruebas que se aplicarn, los productos de trabajo que se obtendrn y la forma en que se registrarn y evaluarn los resultados. El plan tambin incluye un cronograma donde se establecen tiempos, tareas y responsables. As es, una vez ms tiene lugar la grfica de Gantt.

Ahora que has identificado los puntos que debes poner a prueba en la webapp, conocers el proceso para llevarlas a cabo.

5.2 El proceso de prueba

Como te comentbamos en la introduccin a este tema, el proceso de prueba es un conjunto de actividades destinadas a detectar errores y que comienza desde las partes visibles para el usuario hasta las menos visibles. En efecto, este proceso comienza con las pruebas de contenido y funcionalidad de la interfaz y posteriormente contina sobre la navegacin. Movindose hacia aspectos ms tcnicos, como los componentes y la seguridad. Y terminando en aspectos tecnolgicos, como la configuracin y el desempeo. La siguiente imagen muestra este proceso:

Sigue leyendo para conocer ms acerca de cada prueba involucrada en este proceso. a) Prueba de contenido Las pruebas de contenido intentan descubrir errores tipogrficos, equvocos gramaticales, errores de inconsistencia, inexactitudes en las grficas, referencias incorrectas, errores semnticos as como violacin de derechos de autor. Para realizar estas tareas se utiliza la ayuda de un especialista en contenido; el corrector de estilo. Estas pruebas incluyen tambin la evaluacin de contenido generado dinmicamente cuyos datos fueron suministrados por bases de datos.

b) Prueba de la interfaz de usuario Las pruebas de la interfaz evalan vnculos, formatos, scripts, cdigo HTML, pop-ups, cookies, sesiones, etctera; en general aquellos mecanismos de interaccin de la interfaz de usuario en busca de errores que sean corregidos antes de que el usuario los encuentre. Estas pruebas son realizadas por ingenieros de software, diseadores, as como grupos de usuarios piloto.

Adems de evaluar los aspectos mencionados en el prrafo anterior, las pruebas de interfaz de usuario tambin evalan la esttica y la usabilidad de la interfaz. c) Prueba de navegacin Las pruebas de navegacin buscan errores que impidan completar los casos de uso para cada usuario definidos durante el modelo de anlisis. De esta forma, se busca evaluar los mecanismos de navegacin para garantizar que todos ellos llevarn al usuario a su objetivo, adems de que cada unidad semntica de navegacin sea alcanzada para la categora de usuario para la que fue diseada.

d) Prueba del nivel de componentes La prueba del nivel de componentes evala las unidades funcionales dentro de las webapps. Entindase por unidad funcional, una pgina web, la cual encapsula contenido, vnculos de navegacin y lgica de procesamiento. De igual forma, un componente, puede ser considerado como un elemento que proporciona un servicio al usuario final o a la misma webapp.

Las pruebas se realizan de la misma forma en que se prueban los componentes convencionales, con la diferencia de que muchas veces se requiere que un formulario proporcione los datos de entrada. f) Prueba de seguridad Las pruebas de seguridad buscan vulnerabilidades en el ambiente del lado del cliente, las comunicaciones de red y el ambiente de servidor que puedan ser explotadas por hackers, empleados descontentos, competidores deshonestos y cualquier otro ente que desee robar informacin confidencial, modificar el contenido, disminuir el desempeo, denegar el servicio, o causar algn dao a la webapp.

Para las pruebas mencionadas en el prrafo anterior se contratan los servicios de personal experto en seguridad, ya que muchas veces los intrusos estn ms avanzados en conocimientos informticos que les permiten explotar las vulnerabilidades de un sistema y comprometerlo. Incluso, algunas compaas contratan los servicios de los mismos hackers. g) Prueba de configuracin Las pruebas de configuracin buscan descubrir los errores especficos del lado del cliente o del servidor con un ambiente en particular. Se definen diferentes configuraciones para sistemas operativos, navegadores, plataformas y protocolos. No se prueban todas las configuraciones posibles, ya que nunca se terminara, slo se prueban las ms utilizadas en el mercado, adems de las especificadas en los requerimientos del sistema.

h) Prueba de desempeo Las pruebas de desempeo buscan evaluar la respuesta de la webapp al aumentar la carga de usuarios que solicitan un servicio, as como detectar cules componentes tienden a degradarse por esta carga y qu caractersticas son responsables de dicha degradacin. Tambin evalan el impacto sobre los objetivos y requisitos de la webapp.

Las tcnicas para probar aplicaciones web no se tratan en este tema, debido a que ya las estudiaste en algunas materias relacionadas con ingeniera de pruebas. Las tcnicas que conociste en esas unidades de aprendizaje tambin te servirn para probar webapps. Algunas de estas tcnicas son pruebas de unidad, pruebas de integracin, pruebas de regresin, etctera.

Conclusin
Como puedes observar, probar una aplicacin o sistema basado en web, requiere de un proceso de pruebas, el cual se reflejar en un plan. Al desarrollar nuestro plan y ponerlo en marcha, debemos tener siempre presente nuestro objetivo encontrar errores y corregirlos antes de que el usuario lo haga y prescinda del servicio que le ests brindando. A lo largo de esta segunda unidad denominada Aplicaciones de la ingeniera web, has identificado que se trata de un conjunto de ta reas complejas, razn por la cual necesita cumplir con las exigencias para su desarrollo, desde la identificacin de sus elementos, su formulacin y planeacin, as como el modelado tanto del anlisis como el del diseo para aplicaciones web, adems de las pruebas para obtener una webapp que cumpla con todos sus atributos y cuya calidad sea ptima.

UNIDAD 3
Todos los proyectos de software deben tener una organizacin, ser planeados y determinar el tiempo de actividades y tareas, pero adems, es necesario incluir otros elementos que estn vinculados al proyecto como los recursos humanos y costos implicados; esto debido a que la ingeniera de software se supedita a las condiciones de la empresa u organizacin en los aspectos tiempo y costo. Por lo tanto, la gestin de un proyecto se concentra en el personal, el producto, el proceso y en el mismo proyecto, en ese orden de importancia. Y su fin es disminuir tanto el costo como el tiempo de desarrollo, as como incrementar la calidad de la aplicacin de software. Antes de seguir conociendo acerca de la gestin del proyecto te sugerimos que revises el siguiente mapa de contenidos de esta ltima unidad.

Si bien, la gestin est definida como: las actividades y las tareas que la(s) persona(s) hacen con el objeto de planificar, dar seguimiento y controlar las tareas de otros; entonces la gestin de proyectos de software se define como: El proceso de planificar, organizar, proveer de personal, monitorizar, controlar y liderar un proyecto software

La gestin de este tipo de proyectos abarca actividades que estn orientadas a planificar y realizar tanto el seguimiento como el control para que el proyecto se entregue en tiempo y forma, satisfaciendo los requerimientos estipulados por el cliente. Es importante que consideres que al administrar un proyecto no estar exento de falla, pero si no se realiza es seguro que fallar. Para llevar a cabo la gestin del proyecto es primordial que conozcas su ciclo, a continuacin te lo presentamos:

Como primera actividad en este ciclo se realiza la planificacin, la cual se plasmar en un documento que ya es familiar para ti, se trata de la plantilla de MoProSoft, donde se describen los recursos humanos, materiales y de infraestructura. Adicionalmente, se colocan los tiempos de cada actividad que se harn en el proyecto, el personal y la secuencia que tendrn. ste es el plan estratgico llamado: GN_A1.10PlanEstratgico.doc, que ya alguna vez haz requisitado y en el que tambin se agregan los costos estimados para el proyecto. El plan debe ser revisado y evaluado. Toma en cuenta que todo proyecto conlleva un riesgo, el cual es tratado por la gestin del riesgo, lo inesperado puede suceder y es indispensable dar solucin a las contingencias.

Los planes del proyecto suelen tipificarse de la siguiente manera:

Del anterior esquema ya conoces el plan de desarrollo y algunas etapas del proceso de la gestin. Por el momento, nos enfocaremos al activo principal de las empresas, en este caso, especialmente el de la industria del software: el personal, al cual es importante motivar, capacitar, planificar, y organizar para asegurar que el equipo de trabajo realice su labor perfectamente. Por tal motivo el siguiente tema aborda la gestin de personal.

1. Gestin del personal

Para toda empresa, es importante el recurso humano, debido a esto no es una buena estrategia el explotar al personal, sino por el contrario, hay que brindarles respeto, premiar su esfuerzo y compromiso as como asignarles funciones de acuerdo con sus capacidades. Todo esto encaminado a una buena relacin laboral en la que puedan trabajar conjuntamente los gestores con su personal. En la gestin del personal hay cuatro crticos: objetividad, respeto, incorporacin y honestidad. elementos

Con lo que se ha dicho hasta aqu queda claro que lo importante son las personas, pues bien, cada individuo desempea sus actividades de acuerdo a su rol, con un determinado nivel de autoridad y cada tarea debe tener un seguimiento y control. Estas tareas son designadas delegando algunas cuestiones para un mejor manejo por parte del nivel de mando o gerencial y as obtener una gestin de proyecto adecuada.

La coordinacin del equipo de trabajo se especifica de acuerdo con la organizacin que se tenga en la empresa, como ya lo has visto en otros temas. De tal forma que existen diversos tipos de estructura para el equipo de desarrollo y son los siguientes:

Como parte de la gestin del personal, es importante reconocer el lugar que cada persona ocupa dentro de la estructura de la empresa, pero hay otros aspectos que tambin deben tomarse en cuenta y que conocers a lo largo de este tema.

1.1 Seleccin del personal y motivacin

Debido a la, ya mencionada, relevancia del personal que labora en una organizacin, el proceso de seleccin de los integrantes de este equipo de trabajo es igual de importante, as como las acciones que deben llevarse a cabo para mantenerlos con la disposicin para colaborar con la empresa y hacer un buen trabajo. Por eso en este subtema se hablar de la seleccin y motivacin del personal. a) Seleccin del personal De inicio, las personas que participarn en el proyecto de seleccin deben responder a la informacin y los requisitos solicitados por los candidatos, luego se someten a una entrevistapara obtener la visin de cada uno y por ultimo se toman en cuenta las recomendaciones. Los elementos que influyen en la eleccin de algn prospecto se observan en la siguiente imagen:

Como puedes observar en la tabla anterior, es importante que se consideren todas las habilidades y conocimientos que posee el candidato, ya que es muy comn en las empresas que cuando el personal va progresando y sube de estatus, los tcnicos dejen a un lado sus habilidades para enfocarse ms en cuestiones administrativas. En cuanto a la eleccin del lder de proyecto, se sugiere el modelo MOI (Motivacin, Organizacin, Ideas o Innovacin). Esto significa que el elegido para este cargo debe contar con la capacidad de motivar al personal para obtener la productividad al nivel de sus capacidades; la de amoldar procesos existentes y la de motivar para generar creatividad. Para un administrador de proyecto (lder) se sugiere basar su estilo de gestin en la resolucin de problemas y al respecto sobresalen cuatro aspectos para tomar en cuenta:

Una vez seleccionado el personal y conociendo el lugar que ha de ocupar, as como la labor a desempear, debes conocer la importancia de otro elemento que tiene relacin directamente con el personal: la motivacin. b) Motivacin Los gestores de proyecto deben incentivar al personal a su cargo, organizar el trabajo y propiciar un adecuado ambiente laboral para inducir a las personas a trabajar de manera efectiva. Con base en la pirmide de necesidades de Maslow, a las personas que trabajan en empresas desarrolladoras de software, se les debe asegurar la

satisfaccin de necesidades sociales, de autoestima y de autorrealizacin. Tal como se muestra en la siguiente animacin:

Al respecto de este tema, diversos estudios de motivacin han arrojado la siguiente clasificacin de profesionales:

Ahora veamos de qu manera un grupo puede contribuir eficazmente a los fines empresariales, que es una actividad trascendental de la gestin.

1.2 Gestin de grupos

Normalmente el desarrollo del software se realiza en equipos que van desde los que trabajan en pares hasta los grupos que se componen de cientos de individuos. Estos ltimos equipos, por ser tan grandes, se deben fraccionar a su vez en equipos ms pequeos que trabajarn un subsistema y obtendrn un subproyecto. Sin embargo, los grupos de ingeniera de software se componen con no ms de 10 personas.

Tambin hay elementos que afectan de alguna manera el trabajo en grupo, como:

La composicin del grupo, en la que debe prevalecer el equilibrio del que se hizo mencin en el prrafo anterior. La cohesin implica pensar ms como equipo. La comunicacin del grupo entre s. La organizacin del grupo, que cada uno se sienta valorado y satisfecho con su rol en el grupo.

Cuando dentro de un grupo de trabajo mayor los diferentes equipos en los que se divide tienen distintas percepciones de cmo solucionar un problema al que se enfrentan, motivado por el tipo de trabajo que cada uno realiza, pueden surgir varios problemas. Por lo que, un grupo con personalidades complementarias puede trabajar mejor que uno conformado por sus capacidades tcnicas.

Entre las problemticas que pueden presentarse en los grupos est la imposicin de un lder (quien tiene la funcin de llevar la gua y administracin del proyecto) causando tensiones y provocando llegar incluso a no respetarlo o perder la lealtad hacia el grupo. Esto se presenta habitualmente en la ingeniera de software al tener nuevos miembros con mejor preparacin e incluso ms actualizados que el lder experimentado del grupo. De igual manera, los individuos con mayor experiencia pueden estar inconformes por el establecimiento de un lder joven con ideas innovadoras. Sin embargo, las personas que conforman un grupo con cohesin, son fieles al grupo, se identifican con los objetivos del grupo y dems integrantes, por lo que lo protegen de estas problemticas. Dando como resultado grupos fuertes, capaces de sobrellevar problemas y situaciones inesperadas.

Entonces, las ventajas que se tienen son:

el uso de un estndar de calidad por consenso; los integrantes trabajan juntos, aprendiendo unos de otros, hay una programacin prctica sin ego, y la propiedad del cdigo se reconoce como propiedad del grupo.

En resumen, la responsabilidad del software se comparte entre los integrantes de los grupos con cohesin lo que mejora la calidad de los diseos, programas, documentos y comunicacin, es decir, hay cooperacin entre grupos.

Como puedes darte cuenta, la cohesin del grupo es importante y depende de elementos como la cultura que hay en la organizacin y las personalidades del grupo. Los administradores o gestores pueden fomentar la cohesin organizando eventos sociales o estableciendo sentido de identidad del grupo, as como realizando actividades conjuntas como deportes o juegos, pese a ello, la manera ms efectiva es garantizar que cada individuo sea tratado como responsable, confiable y que se le proporcione acceso a la informacin de forma completa. Tambin existen inconvenientes en los grupos con cohesin, como: la resistencia irracional al cambio y liderazgo cuando se reemplaza al lder con alguien externo, lo que provoca que se d una prdida de productividad; y el pensamiento de grupo, en el que las habilidades se corrompen por lealtad al grupo. Para evitar que sucedan este tipo de situaciones y que al mismo tiempo se conserve la unin del grupo es importante que la empresa mantenga contacto con su personal y que al interior de los grupos haya las condiciones adecuadas para comunicarse. a) Comunicaciones del grupo La buena comunicacin entre los integrantes del grupo es primordial ya que fortalece la cohesin.

Sin embargo, tambin hay elementos que afectan la comunicacin, stos son los siguientes:

El tamao del grupo: determinndose el nmero de vnculos de comunicacin en una direccin como n*(n-1), donde n es el tamao del grupo.

La estructura del grupo: es mejor una estructura informal, puesto que en la formal se omiten ciertos niveles o grupos, como en la estructura jerrquica en la que en un mismo nivel no hay comunicacin.

La composicin del grupo: las personas con la misma personalidad chocan entre s y esto relega la comunicacin, los grupos son mejores si se integran por personas de ambos sexos.

El entorno fsico de trabajo: la organizacin del ambiente de trabajo puede contribuir o afectar las comunicaciones

Una vez que se conocen los elementos que intervienen en el factor comunicacin, y dando por hecho que est presente en el grupo de trabajo, se puede proceder a la organizacin del mismo, tal como lo veremos a continuacin. b) Organizacin del grupo En grupos con pocos integrantes la manera de organizarse es informal, el lder se involucra con todo y todos, as se logra una comunicacin efectiva. El

trabajo es adecuadamente repartido de acuerdo con las capacidades, conocimiento y experiencia, se aumenta la productividad y cohesin, la toma de decisiones es democrtica, la condicin es que los integrantes estn experimentados y sean muy competentes, de lo contrario suele ser un caos.

Como regla se debe considerar aumentar el tamao del grupo con especialistas, as los desarrolladores inexpertos aprenden y se desarrollan conforme se avanza en el proyecto. La seleccin debe iniciar con gente de capacidades genricas como comunicacin y solucin de problemas, para posteriormente agregar expertos. Sin embargo, la ptima estructura del equipo obedece a la forma de gestin de una empresa u organizacin, el nmero de personas que formar el equipo, sus niveles de conocimientos y la complejidad general del problema. Hay tres organigramas de equipo genricos y stos son:

Adems de elegir una de las formas anteriores para organizarse en grupo, los elementos para considerar al planear la constitucin del equipo de ingeniera de software son los siguientes:

Tambin al constituir un determinado equipo, se identificarn diferentes caractersticas que lo formarn, stas son:

Habitualmente el tener equipos pequeos centralizados es mejor que slo un equipo grande. De esta forma los tipos de organizacin de los equipos son diferentes de acuerdo con el tipo y caractersticas del mismo, a continuacin se describe esto:

Independientemente del tipo de organizacin a usar se busca que los equipos de ingeniera de software sean de alto rendimiento. Para ello:

Los integrantes del equipo deben tener mutua confianza. Las destrezas deben ajustarse al problema. Los integrantes inadaptados tienen que ser excluidos del equipo en pro de la unin.

El propsito para los gestores de proyecto es favorecer la generacin de un equipo que muestre cohesin. Ya que stos son productivos, motivados y comparten metas y cultura. Sin embargo, un equipo se puede contaminar y los factores que intensifican un medio ambiente daino para el equipo son los siguientes:

En resumen, los fallos que ocurran en el equipo hay que corregirlos en lugar de ponerse a culpar y desconfiar de alguien. Se debe ser capaz de reconocer que existen diferencias. Por otro lado, las caractersticas del software actual como la interoperabilidad, la escalabilidad e incertidumbre son enfrentadas por los equipos de ingeniera de software a travs de mtodos para coordinar los trabajos del equipo de desarrollo, establecindose mecanismos de comunicaciones, tanto formales como informales, entre los integrantes como entre los equipos. En la siguiente tabla puedes ver ejemplos.

Es relevante destacar que las redes interpersonales han sido clasificadas como las tcnicas de mayor valor de coordinacin y de comunicacin. Recuerda que anteriormente se mencion al entorno de trabajo como un factor para mantener la productividad del personal. c) Entornos de trabajo Es un hecho que si las personas son felices en su entorno de trabajo, son ms productivas y estn ms satisfechas, tienen una permanencia ms estable, en consecuencia hay menos costos por contrataciones y capacitacin.

Por lo que, la comunicacin del grupo se ve afectada por la distribucin de los espacios de trabajo y la arquitectura del edificio.

Se considera que los elementos importantes del entorno son:

Privacidad, para concentrarse y trabajar sin interrupcin. Repercusin del exterior, tener luz natural y un agradable panorama. Personalizacin, decoracin particular.

Lamentablemente es frecuente el trabajar con restricciones impuestas por la arquitectura del edificio, limitando los espacios o no pudindolos adecuar a las necesidades. Sin embrago, los grupos de desarrollo necesitan reas donde todos los integrantes se puedan comunicar y reunir como equipo, en una estructura formal o informal. El que cada quien tenga oficinas individuales aumenta la productividad, por lo que la solucin es agrupar oficinas individuales alrededor de las grandes salas de reunin. Con lo cual pueden trabajar satisfactoriamente a solas o en grupo. Ahora conocers otro recurso que de igual manera es til a la empresa para la administracin de su personal.

1.3 Modelo de madurez de la capacidad del personal (CMM)

El Modelo de Madurez de la Capacidad (CMM) es un marco de trabajo propuesto para mejorar la manera en que la empresa u organizacin administra sus recursos humanos y consta de cinco niveles los cuales son:

Los objetivos estratgicos de este modelo son:

De este modo, el CMM en una empresa constituye una buena herramienta de tipo prctico para apreciar, estandarizar y mejorar el rea del personal, enfocndose al individuo con el propsito de incentivar su desarrollo de habilidades, sin embargo, puede ser que en algunas organizaciones sea innecesario aplicar el modelo completo, an as es una gua de importantes

optimizaciones en las habilidades de la empresa para desarrollar software de calidad. A lo largo de este tema has podido estudiar cmo seleccionar al personal para realizar un trabajo especfico con relacin al desarrollo de software, cmo organizarlo en grupo y favorecer el trabajo en equipo motivndolo y mediante una buena comunicacin y entorno laboral. Es muy posible que algunas cuestiones tratadas en este tema te sean familiares o incluso obvias, pero es sumamente importante puntualizarlas y darles el lugar que tienen para lograr tener un enfoque de ingeniera en el desarrollo de software. En el siguiente tema podrs estudiar un aspecto que se ha destacado en el desarrollo del software: su costo.

2. Estimacin de costos del software

Cuando se planea el proyecto se debe incluir el costo, sin embargo, es necesario adems de precisar el costo real tambin predefinir un costo estimado del proyecto a desarrollar. Una estimacin preliminar establece el presupuesto destinado al proyecto. Este clculo involucra los siguientes parmetros:

El gestor de proyecto, a medida que avanza el proyecto debe ir ajustando las estimaciones de tiempo y coste realizadas, incorporando recursos o modificando actividades. La determinacin del costo de software no es simple, requiere de contemplar varios factores que se muestran en la siguiente ilustracin:

Tomando en cuenta los parmetros ya mencionados y estos factores, hay que ser muy objetivos y tratar de dar un costo de desarrollo de software real.

2.1 Productividad y tcnicas de estimacin

Es necesario valuar el proyecto para conocer el costo del software que se est desarrollando, esto incluye la estimacin de la productividad de los ingenieros de software en el proceso. Hay que valorar los procesos y las mejoras tecnolgicas apoyados en algunas tcnicas para obtener una estimacin lo ms apegada a la realidad. La relacin entre el costo de software y su precio

resulta complicada de estimar, as que ayuda mucho el considerar en dicho presupuesto la productividad y el uso de tcnicas. a) Productividad El clculo de la productividad de un proyecto se basa en la medicin de caractersticas del software, como las siguientes:

Relacionadas al tamao: son el nmero de lneas de cdigo fuente entregadas, nmero de instrucciones de cdigo objeto o nmero de pginas de la documentacin.

Relacionadas con la funcin: funcionalidad til producida en un periodo especfico, como los puntos de funcin o los puntos objeto.

Una mtrica usada para medir la productividad son las lneas de cdigo fuente por programador/mes. Aunque puede resultar engaoso debido al tipo de lenguaje de programacin utilizado, debido a que una misma funcin puede requerir ms lneas de cdigo variando de un lenguaje de programacin a otro y produciendo una productividad errnea. Calcular la productividad a travs del punto de funcin puede ser ms verdico, dado que la funcionalidad es independiente del lenguaje de programacin. Aqu se formula la productividad por el nmero de puntos de funcin implementados por persona/mes. Y se calcula estimando lo siguiente:

Entradas y salidas exteriores Interacciones con el usuario Interfaces externas Archivos usados por el sistema

Dada la complejidad de los elementos anteriores, las mtricas de puntos funcin toman esto en consideracin y multiplican las estimaciones de puntos de funcin inicial por un factor de complejidad, por lo que se debe calcular cada una de estas cuestiones y asignarles un valor de peso (3 para entradas externas simples y hasta 15 para archivos internos complejos), lo anterior se hace empleando los pesos propuestos por Allan Albrecht. Esto se representa de la siguiente manera:

Donde:

Nmero de elementos de un tipo = contar dentro de un tipo, por ejemplo, las entradas y salidas externas, es decir, suponiendo 3 entradas y 5 salidas, la caracterstica es = 8. Y suponiendo que se tiene un peso de 3, por ser entradas simples, el primer factor de los 4 que son, tiene un valor de 8 x 3 = 24. Los puntos objeto son usados para lenguajes 4GL y basados en script, stos son una estimacin de:

Nmero de pantallas independientes que se despliegan (peso de 1 a 3) Nmero de informes que se generan (de peso: 2, 5 y 8) Nmero de mdulos en lenguajes como Java o C++ para programacin de la base de datos (10)

Todos son usados en el modelo COCOMO II, que se explicar ms adelante. La productividad obtenida con puntos objeto indica que se puede tener desde 4 puntos objeto hasta 50 por mes, dependiendo de las herramientas de apoyo y la capacidad del programador. El inconveniente con estos clculos es que no toman en cuenta los requerimientos no funcionales del software como el mantenimiento, por lo que surge la necesidad de ver otras tcnicas de estimacin. b) Tcnicas de estimacin La dificultad para llevar a cabo una estimacin precisa de los costos ha suscitado que en ocasiones se fundamente en la experiencia para concretar todos los factores que se involucran en el costo, que se ve afectada por: sistemas orientados a objetos y distribuidos, uso de servicios web, uso de sistemas basados en BD, uso de subsistemas o programas de terceros, reutilizacin de componentes, desarrollo usando lenguajes script y uso de herramientas CASE. Al no manejar tcnicas la experiencia previa no ser de utilidad. En la siguiente tabla se aprecian las tcnicas para estimar los costos.

En proyectos grandes se suele calcular los costos con distintas tcnicas con el fin de que converjan y determinarlos con ms precisin. Las tcnicas son aplicables si se tienen los requerimientos del software a desarrollar y de sistema. A continuacin veremos un poco ms sobre una de las tcnicas de estimacin de costes de software modelado algortmico de costes.

2.2 Modelado algortmico de costes

Este tipo de modelado predice los costos del proyecto de software a desarrollar con base en valoraciones de su tamao, nmero de ingenieros de software y atributos del sistema final, sin embargo, tambin es empleado para valuar estrategias alternativas para calcular riesgos, toma de decisiones por reutilizacin, reorganizacin o subcontratacin, as como para estimaciones para investigadores en empresas de software.

Una estimacin algortmica de costes se formula de la siguiente manera:

En donde:

Los modelos algortmicos conllevan diversos problemas, como la dificultad para hacer una estimacin preliminar del proyecto de manera precisa; esto debido a que los factores de la frmula son valoraciones realizadas de manera subjetiva. Por ejemplo, es complicado determinar el tamao al inicio del proyecto, pues no se sabe a ciencia cierta cuntas lneas posee en su totalidad el proyecto, este factor, tambin depende del lenguaje de programacin empleado, en algunos lenguajes para implementar una funcin se necesitan ms lneas de cdigo que en otros. Es por ello que cuando se aplica este tipo de modelado es deseable tener un intervalo de estimaciones, en lugar de slo una y utilizar la frmula del costo en cada intervalo. La precisin en las estimaciones del costo del software es generada cuando se sabe la clase de software que se va a desarrollar, se ha definido el lenguaje de programacin y el hardware, as como de la informacin disponible del sistema. Obviamente entre ms cerca est el sistema de ser concluido ms preciso ser el costo estimado. Un modelo del tipo algortmico es COCOMO, mismo que abordaremos a continuacin.

2.3 Modelo COCOMO

Este modelo fue creado por Barry Boehm en 1981. Su nombre significa Constructive Cost Model (en espaol: Modelo Constructivo de Costo) y por sus siglas es conocido comoCOCOMO. Es de tipo emprico, se genera a partir de diversos proyectos grandes de los que se recopilaron datos, los cuales se analizaron para enunciar la frmula que mejor se apegaba a las consideraciones. Este modelo incluye en sus frmulas el tamao del sistema, del producto, sus factores, y el esfuerzo del personal involucrado. COCOMO est bien documentado, es de dominio pblico y lo apoyan las herramientas comerciales. Es aplicado y evaluado ampliamente, adems tiene una amplia prctica desde su primera versin en 1981, que atraviesa por un perfeccionamiento para el desarrollo de software en ADA, hasta llegar a la versin ms reciente, COCOMO II, publicada en el 2000. Los modelos COCOMO son claros, con un gran nmero de parmetros, los cuales pueden tomar valores de un rango predeterminado. A continuacin podrs conocer ms detalladamente algunas de las versiones de este modelo. COCOMO 81 fue el primer modelo con tres niveles, que detallan el anlisis de la estimacin del costo. Los niveles de los que se compone, sern descritos a continuacin.

Nivel bsico (o llamado tambin COCOMO bsico): proporciona una estimacin preliminar a grosso modo. Se determina el esfuerzo usando la frmula:

Estas frmulas se relacionan de acuerdo con el tipo de software (son tres), sealados en la tabla siguiente con el encabezado Modo de desarrollo, primero se calcula el esfuerzo y luego la duracin con base en ste. Por ejemplo si se tiene un sistema semiacoplado la frmula para calcular el esfuerzo sera el segundo rengln, dependiendo del tamao en lneas de cdigo fuente, digamos 4500, entonces aplicamos la frmula de Esfuerzo= 3x45001.12. Para la duracin c es igual a 2.5 es fijo e invariable, para este nivel, y d es: d= 0.33+0.2*(B-1.01), y calculado de acuerdo con la experiencia para cada tipo de software, toma el valor que se indica en la tabla como una constante invariable.

A continuacin se observa en la tabla la frmula bsica de COCOMO en los tipos de proyectos, donde M es el Multiplicador compuesto.

Ejemplo

De esta forma, la respuesta al ejercicio es: el proyecto tendr un esfuerzo de 10 hombres-mes, con una duracin de seis meses y se involucrarn dos personas.

Segundo Nivel (o llamado tambin COCOMO intermedio): transforma la estimacin obtenida del primer nivel recurriendo a una serie de multiplicadores de proyecto y proceso. Estos multiplicadores toman seis valores posibles:

Por lo cual, tomando en cuenta estos multiplicadores se agregan a la frmula ya vista en el nivel anterior, quedando: Esfuerzo = A x TamaoB * M (son los multiplicadores) Ejemplo Tomando el mismo escenario pero agregando los multiplicadores, tenemos:

Por lo que M es:

Sustituyendo valores:

El esfuerzo ya fue calculado anteriormente como: Esfuerzo=9,8950624058952617330192721225239 Agregando M queda: Esfuerzo=9,8950624058952617330192721225239*0.8 Esfuerzo= 7.9160499247162093864154176980191 Esfuerzo=8 personas mes. Esto, evidentemente modifica la duracin y por ende afecta la decisin de personas involucradas.

Tercer Nivel (o llamado tambin COCOMO detallado): nivel ms minucioso que obtiene estimaciones para las diversas fases del proyecto.

Aqu el multiplicador M muestra caractersticas del producto, del proyecto y del personal. Ejemplo Tomemos el mismo escenario, veamos qu pasa en este nivel. Ahora consideremos que el personal es de recin ingreso, sin experiencia, pero con conocimientos y habilidades altas en la fase de codificacin. Los factores de M son de producto, Hw, personal y proyecto como se indica a continuacin:

M=1*1*1*1*1*1.2*1*1*1.2*1*1.2*0.5*0.5*0.5*0.5*0.8*0.5 M=0.0432 Por lo que el esfuerzo: Esfuerzo= 9.8950624058952617330192721225239*0.0432 Esfuerzo= 0.42746669593467530686643255569303 Esto significa que el factor de altas capacidades redujo enormemente el esfuerzo invertido, por lo que slo se necesitara de una persona-mes. Por ltimo, y con respecto a COCOMO 81 es importante decir que este modelo considera que el software se desarrolla con un modelo en cascada, con lenguajes de programacin procedurales como Pascal.

Y pasando a la versin ms reciente de este modelo tenemos a COCOMO II que distingue varios modelos para el desarrollo de software como el de construccin de prototipos, el basado en componentes, el manejo de programacin con bases de datos y el de espiral. Adems contiene diversos niveles que originan estimaciones especficas de manera incremental. En la siguiente ilustracin se observan los niveles de COCOMO II y sus sugerencias de aplicacin.

Ahora se explicarn ms detalladamente estos niveles, los cuales podrs ejemplificar y ejercitar en un software que se explicar ms adelante.

Nivel de construccin de prototipos: supone que el sistema fue desarrollado con componentes reutilizables, scripts y programacin de base de datos. Hace estimaciones de desarrollo de prototipos y sus estimaciones de tamao del software tienen base en puntos objeto. Usa una frmula sencilla (tamao/productividad) para estimar el esfuerzo requerido, sta es la siguiente:

La ltima variable relativa a la productividad se puede observar en la tabla siguiente:

Nivel de diseo inicial: se aplica en fases iniciales de diseo del sistema, con requerimientos fijados. Sus estimaciones se basan en puntos de funcin, los cuales se cambian a nmero de lneas de cdigo; tiene siete multiplicadores y pretende realizar una estimacin cercana a lo real sin demasiado esfuerzo. Est sustentada en la frmula de estimacin algortmica de costes antes vista (Esfuerzo = A x TamaoB x M).

En este nivel los valores son A=2.79, B entre 1.1 y 2.4 y M (M= PERS X RCPX x RUSE x PDIF x PREX x FClL x SCED) y es compuesto por los factores de:

Cada factor se mide sobre una escala de seis puntos donde 1 es un valor muy bajo y 6 un valor muy alto.

Nivel de reutilizacin: se emplea para calcular el esfuerzo necesitado para integrar componentes reutilizables y/o el cdigo que es automticamente creado por herramientas de diseo o programas de traduccin. Se emplea con el nivel de post-arquitectura. COCOMO II contempla dos clases de cdigo a reutilizar. El cdigo de caja negra y el cdigo de caja blanca.

La frmula para estimar el esfuerzo es:

En este nivel las estimaciones que se tienen son ASLOC (ya especificado) y ESLOC que es el nmero de lneas de cdigo nuevo, calculado como:

Nivel de post-arquitectura. Es el nivel ms detallado del modelo, diseado el sistema usa la frmula estndar para la estimacin del coste explicada anteriormente. sta contiene 17 multiplicadores que muestran las destrezas del personal y las caractersticas del producto y del proyecto.

Cuando un sistema est compuesto por varias partes, con desarrollos en diferentes tecnologas, y no sea obligatorio valorar todas las partes con igual nivel de precisin, se puede emplear el modelo conveniente para cada parte del sistema y mezclar los resultados para establecer una estimacin del sistema completo. El esfuerzo en este nivel est determinado por la siguiente frmula, que ya se especific antes:

Pero aqu, habr de ser ms precisa, por lo que se usan 17 atributos de producto, proceso y organizacin. El nmero de lneas de cdigo se calcula usando tres componentes:

Nmero total de lneas nuevas de cdigo a desarrollar Nmero de lneas de cdigo fuente equivalentes (ESLOC) calculadas empleando el nivel de reutilizacin Nmero de lneas de cdigo a cambiarse por modificacin en los requerimientos

Estas tres estimaciones se incrementan para obtener el tamao total del cdigo (KSLOC) que ocuparemos en la frmula. En este nivel el exponente B, es calculado con base en cinco factores:

La suma de estos valores es 16, por lo que el exponente debe tomar un valor de 1.17 (0.16 + 1.01). Ahora te mostramos una tabla de acuerdo con CMM para calcular la Madurez del Proceso (PMAT):

Estos factores pueden tener los valores de 0 a 5. Los valores se suman, se dividen entre 100 y al resultado se le suma 1,01 para tener el exponente a usar. M, en este nivel de COCOMO se puede fraccionar en cuatro tipos:

Los atributos de M, se observan en la siguiente imagen:

Conductores del coste del proyecto

El modelo COCOMO II, tiene un software que se puede distribuir libremente y se puede descargar en la siguiente liga: http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html Para saber cmo instalar este software sigue las instrucciones que a continuacin se proporcionan en el PDF: Instalando COCOMO II. Da clic para descargar este documento.

Antes de aplicar este programa veamos los modelos algortmicos de costos en la planificacin, que ayudarn a visualizar la reduccin de costos del proyecto.

2.4 Modelos algortmicos de costes en la planificacin

Este tipo de modelos nos apoyan para evaluar los riesgos en las opciones que se tienen para la administracin del proyecto, y los gastos con las distintas decisiones. Los costos a considerar en un proyecto son:
a. El hardware que ejecuta el sistema b. La plataforma para desarrollar el sistema c. El esfuerzo necesitado para desarrollar el software

En la siguiente imagen se observan posibles opciones a considerar como gastar ms en el hardware para disminuir los costos del software o invertir en mejores herramientas de desarrollo.

Las opciones de A a la F se muestran en la imagen siguiente imagen:

En las imgenes anteriores se observa lo siguiente: 1. Los costos de hardware aadidos son admitidos cuando el sistema es especializado y no se desarrolla en masa.

2. La opcin A considera el costo del desarrollo del sistema de acuerdo con los recursos y personal que posee.

3. RELY=1.39 en todas las opciones, ya que considera que se realiza un esfuerzo adicional para fiabilidad. Ahora, supongamos que el esfuerzo de una persona/mes cuesta en promedio: $15,000. De esta forma el costo del software es calculado as:

La opcin D brinda los costos ms pequeos de todas las estimaciones bsicas, pero se obliga a reclutar nuevo personal para el proyecto. Si hay gente disponible en la empresa, tal vez sea la mejor opcin. La opcin E ofrece un ahorro sin riesgo alguno. Los administradores conservadores quiz seleccionaran esta opcin en vez de la audaz opcin D. Las comparaciones denotan la influencia que tiene la experiencia del personal como un multiplicador, en la determinacin del costo, ya que su prdida tiene un efecto de derroche. De esta manera, se debe estimar el personal necesario involucrado en el proyecto, porque se vincula con el tiempo y esfuerzo invertido en este, que no es lineal.

2.5 Duracin y personal del proyecto

Los administradores de proyectos deben estimar cunto tardar el desarrollo del software (duracin del proyecto), as como el personal que se requiere en el proyecto.

Las empresas necesitan que sus productos se coloquen en el mercado lo antes posible para tener ventaja sobre sus competidores, lo que origina que los proyectos reduzcan su duracin. En el modelo COCOMO hay una frmula que es igual para todos los niveles para calcular el tiempo de calendario (TDEV) necesario para cumplir un proyecto:

Puede ser que la duracin planeada con la duracin necesitada por el proyecto no sean iguales, limitndose la duracin como:

Una aportacin del modelo COCOMO es ver que el tiempo para concluir el proyecto est en relacin al esfuerzo invertido en l, o sea, que incluir ms personas en un proyecto no ayudar a terminarlo ms pronto. El incremento del personal en un proyecto, en etapas iniciales sobre todo, se relaciona con retrasos en la duracin del proyecto. Por lo que el esfuerzo puede determinarse por la curva de Rayleigh y la estimacin de Putnam. En este ltimo, radica otro factor que toma relevancia, nos referimos al tiempo, donde se aprecia que si ste se reduce aumenta exponencialmente el esfuerzo. Para conocer ms acerca de estos dos conceptos descarga el PDF de la curva de Rayleigh y la estimacin de Putnam.

Ya que se vieron todos los conceptos (esfuerzo, duracin, personal, factores que influyen determinados por M, nmero de lneas de cdigo, constantes determinadas por la experiencia, tipos de proyecto, niveles del modelo, y frmulas) hay que aplicarlos en el software descargado. Para ejecutar COCOMO II da click en inicio, luego todos los programas, y busca la carpeta donde se instal.

Ahora veamos cmo puede aplicar este software. Para ello descarga el PDF: Usando COCOMO II.

En este tema pudiste conocer que la determinacin del costo implica diversos factores como el esfuerzo y el personal, as como el tipo de proyecto y modelo a utilizar. Por lo cual, debes de tenerlos presentes a la hora de calcular el costo de cualquier proyecto.

3. Mejora de los procesos de software

Al inicio de esta unidad de aprendizaje se mencion que la ingeniera de software se centra en el proceso, ya que se relaciona estrechamente con el software, de tal forma que si se mejora un proceso se obtiene un mejor software. Es por ello, que toma importancia la mejora de procesos y es necesaria verla en ingeniera de software, puesto que eleva la calidad del mismo, reduce costos, disminuye el tiempo de desarrollo y minimiza los defectos del software.

3.1 Mejora de procesos

La mejora de procesos implica comprender los procesos vigentes y transformarlos para optimizarlos.

Cada proceso cuenta con algn grado de dificultad y numerosas tareas, stos son sus atributos. Estas caractersticas no se alteran simultneamente, pues algunas tienen efectos sobre otras, por ejemplo, un proceso que requiera mucho control y seguimiento haciendo uso de su atributo de apoyo necesariamente se har ms pausado; otro ejemplo es que si un proceso necesita tener un desarrollo rpido se tendr que reducir su atributo de visibilidad. Para que comprendas mejor esto a continuacin puedes observar los atributos de los procesos.

La mejora de procesos es una actividad a largo plazo e involucra polticas, normas y estndares que la empresa adopta; adems de varios procesos. No es comn que cambiando un slo proceso se tenga xito, siendo una actividad recurrente. Los procesos necesariamente tienen que evolucionar y responder al cambio del entorno, esta mejora consta de los estados que podrs conocer en la siguiente animacin:

Y como ya se mencion, si hay mejora en el proceso necesariamente lo habr en el producto, lo cual debemos identificar a continuacin.

3.2 Calidad de producto y de proceso

Con el proceso de mejora de Deming que ya conoces, se introdujeron varios conceptos con un control estadstico de calidad basndose en los defectos para cuantificar el nivel de calidad del producto, as, si un producto presenta defectos stos se vinculan con los de su proceso. El ciclo de mejora se repite hasta que sea predecible el proceso y se minimicen sus defectos. Este ltimo ciclo, se fija como un estndar e inicia el ciclo de mejora de calidad, lo cual es aplicable a las tcnicas de la ingeniera de software. El enlace entre el producto y el proceso en el software no es tan evidente, debido a que el software es intangible y a que tambin es producto de un proceso que es intelectual: el diseo, donde el recurso humano es determinante. As la calidad del software depende del diseo. Los principales factores que afectan la calidad del producto son cuatro y se muestran en la siguiente ilustracin.

Al analizar los factores determinantes en la calidad, se aprecia que bsicamente depende de dos factores, que inciden en un factor determinante, al que a su vez se le atribuye la calidad. Esto lo puedes identificar en el siguiente esquema:

En este sentido, existen problemas en este tipo de proyectos de software, tales como: la integracin, la administracin y las comunicaciones. Adems los

equipos de trabajo son voltiles debido al gran tiempo que se llevan los procesos, de tal forma que las personas con aptitudes y destrezas especficas, por lo regular, no tienen una consecuencia absoluta en el tiempo de vida del proyecto, sin embargo, plantemonos qu pasa si difiere el factor tamao de equipo, veamos:

Como observamos, la calidad del equipo de desarrollo toma relevancia y el proceso, aunque sea bueno, slo puede reducir daos pero no lleva a un software de calidad ptima. Por ello, en cuanto al factor tecnolgico, en este escenario es preciso tener buena tecnologa para desarrollo, y si el equipo de trabajo es pequeo los integrantes no pueden dedicar tiempo a cuestiones administrativas, ya que la mayor parte de los ingenieros de software se ocupan de disear y codificar, por lo que las herramientas influyen en la productividad, aunque habitualmente no tienen relevancia en grandes proyectos, donde las personas se ocupan ms en comunicarse y entender las partes del sistema, stos forman el factor relevante que afecta la productividad. Finalmente, la calidad del producto se ve afectada independientemente de todos los factores anteriores, si no tiene presupuesto suficiente o se planea mal, dejando tiempos ficticios, pudiendo ser rescatado slo por personas excelentes, pero si es demasiada la merma, el software saldr con calidad muy baja. Solamente con recursos suficientes se podr implementar y se desarrollar el proceso de modo eficaz.

Es importante considerar que el origen de la mala calidad del software es por la competitividad entre empresas, que dan mayor importancia a la firma de contratos y crean software de manera precipitada con mala valoracin de esfuerzo, muchas veces por ello se aniquila la calidad.

3.3 Clasificacin de los procesos

Los procesos con que cuentan las empresas dependen del grado de formalizacin, de la clase de producto y del tamao de la empresa, dando origen a varios tipos:

Esta clasificacin es til para la mejora de procesos que va de acuerdo con el tipo de proceso, de esta manera se perfecciona la metodologa de capacitacin, las herramientas CASE, el diseo, entre otros aspectos. Y se percata de que el proceso es importante en la calidad del software pero no es concluyente. Cmo se pueden aplicar los tipos de procesos a un proyecto de software, se muestra en la siguiente imagen.

Los procesos de mejora no aparecen en la figura, ya que todo proceso puede ser de mejora. Sin embargo, las clases de sistemas pueden combinarse y por lo tanto, aplicarse varios tipos de proceso. Por ejemplo: Los sistemas pequeos a los que se les aplica reingeniera se pueden desarrollar utilizando un proceso metodolgico. Los sistemas grandes siempre necesitan un proceso gestionado. Sin embargo, los mismos mtodos de diseo no son recomendables para todo tipo de aplicaciones y los sistemas grandes constan de subsistemas de diferentes tipos. Por lo tanto, los sistemas grandes se desarrollan empleando un proceso gestionado que no se basa en mtodos de diseo particulares. Lo comn es que los procesos de software tengan el apoyo de herramientas CASE, aunque pueden ser herramientas de otro tipo. En la siguiente figura se muestran las herramientas que usan los procesos de acuerdo con su tipo.

La eficacia de una herramienta en el proceso est relacionada con su tipo. Por ejemplo, las herramientas CASE son las ms eficientes para anlisis y diseo con un proceso metodolgico, y las especializadas para actividades individuales.

3.4 Medicin del proceso

Las mediciones que se pueden realizar en el proceso son cuantitativas, y son necesarias para la mejora del proceso, como el esfuerzo o tiempo dedicado, pero tambin son importantes las mediciones del producto, porque las anteriores, por s mismas no pueden determinar si la calidad del producto se ha optimizado. As, las mtricas del producto se relacionan con las actividades del proceso. En cuanto a mediciones usadas para descubrir si las modificaciones en el proceso mejoran su eficiencia estn las siguientes:

El problema que se presenta en la medicin del proceso es conocer qu medir y para determinar esto, y saber cmo usar las mediciones, se usa el paradigma GQM (Goal-QuestionMetric), propuesto por Basili y Rombach en 1988. ste hace una identificacin de los siguientes puntos:

Este enfoque beneficia en la mejora de procesos al fragmentar los puntos organizacionales de los asuntos especficos del proceso, es decir, las metas de las preguntas.

Este paradigma se concentra en el acopio de datos e indica que estos se tienen que analizar de diversos modos, dependiendo de la pregunta que se pretenda contestar. As se logra apreciar que la mejora de procesos se puede basar en mediciones.

3.5 Anlisis y modelado de los procesos

El anlisis y modelado de procesos implica el conocimiento de los procesos existentes y llevar a cabo un modelo abstracto de stos, que fije sus particularidades vitales. Los modelos tienen la funcin de comunicar y entender el proceso. Para llegar al proceso de anlisis primero hay que tener un proceso de medicin, aunque en realidad se hacen de forma enlazada, y el anlisis se crea antes y despus de las mediciones; antes, para saber qu medir, y despus, para entender el proceso de medicin. En el proceso de anlisis se reflejarn las relaciones entre las diferentes secciones del proceso. De inicio, se usa algn modelo de procesos formales, normalmente asignado por el cliente, delimitando las actividades crticas y el ciclo de vida del software a desarrollar. Estos modelos de proceso son muy abstractos y no incluyen detalle, se puntualizan las actividades del proceso primordial, no reflejan la realidad. De esta forma los procesos reales que se siguen distan de los modelos de procesos formales. Para hacer un correcto anlisis de procesos se siguen las dos tcnicas que a continuacin se mencionan:

Ambas tcnicas tienen ventajas y desventajas:

Los modelos de proceso son perspectivas abreviadas de los procesos de software, que develan las actividades y las salidas del proceso, y en muchas empresas son los mismos por lo general, pero con diferentes instancias dependiendo del software a desarrollar y del entorno empresarial. Estos modelos que detallan el proceso no son transferibles de una empresa a otra. Para el anlisis se requiere de informacin de las actividades, los productos para proporcionar, las personas, las comunicaciones, la duracin y otros procesos empresariales que influyen en el proceso de desarrollo. Para hacer un modelo de procesos detallado se abarcan varios factores que se observan a continuacin.

En un modelo de procesos adems se anota el tiempo y las dependencias entre las actividades, los productos a entregar y las comunicaciones. Las actividades en algunas ocasiones se hacen en paralelo o secuencia. Un ejemplo de modelo de proceso, se muestra en la siguiente figura, las actividades se hacen de izquierda a derecha y las actividades en paralelo se representan de forma vertical.

Los modelos de procesos detallados son intensamente complicados. A continuacin se muestran varios.

Hay cuatro series de actividades:

Preparar los datos de prueba Redactar un cdigo de pruebas para un mdulo Ejecutar las pruebas Hacer informes de prueba

En la figura se tiene informacin acerca de las pre y postcondiciones del proceso y sobre las entradas y salidas del proceso, que hace que el modelo sea complicado y difcil de entender. Por lo que se puede optar por realizar diversos modelos en distintos niveles de abstraccin, relacionados por elementos comunes en las actividades y software para entregar.

3.6 Excepciones del proceso

Cuando los procesos del software se representan en un modelo se muestra una situacin ideal, pero en la realidad se enfrenta a dificultades no previstas, y deben modificarse para solucionarlas. Por lo que, los tipos de excepciones a las que se enfrenta un administrador de proyectos son:

Es complejo predecir todos los imprevistos e incorporarlos en un modelo de proceso formal, por lo cual, son irremediablemente incompletos y el administrador del proyecto responsable de tratar estos imprevistos debe adaptar el proceso como se pida.

3.7 Cambio en los procesos

El cambio en el proceso representa hacer reformas en el proceso existente, metiendo nuevas prcticas, mtodos o herramientas, permutando el orden de las actividades, implantando o excluyendo entregas del proceso, o insertando nuevos roles y responsabilidades. Deben fijarse metas para la mejora del proceso, que deben conducir el cambio en el proceso y se deben usar para evaluar el avance. Existen cinco etapas clave en el proceso de cambio de procesos:

Con cada cambio el proceso se repite haciendo un anlisis en el que se identifican dificultades en el proceso y se sugieren mejoras. No se deben hacer cambios al mismo tiempo, pues entonces no se ver ni evaluar el efecto de cada cambio. Es normal que algunas personas se sientan amenazadas por el cambio, preocupadas por perder su trabajo o sean incapaces de adaptarse a las nuevas formas de trabajar, es ah donde el administrador debe interesarlos e involucrarlos en el proceso de cambio.

3.8 Marco de trabajo para mejora de procesos CMMI

El Modelo de Capacidad etapas y continuo. Integrado (CMMI), tiene dos instancias: en

ste pretende ser un marco de trabajo para la mejora del proceso que sea aplicable en un amplio abanico de compaas, ya que permite un desarrollo del sistema de la empresa, la administracin de procesos para evaluar y su asignacin a un nivel de madurez entre 1 y 5. Su versin continua permite una clasificacin detallada con 24 reas de procesos en una escala de 1 a 6. El modelo es muy complejo por lo que se te presenta de manera abreviada a continuacin:

El CMMI sabe que lo importante es la meta, por lo que las empresas pueden seguir cualquier prctica para alcanzarlas; las metas y las prcticas estn relacionadas con la institucionalizacin de las buenas prcticas que estn en funcin de la madurez de la empresa. As una empresa nueva se hallar en una etapa inicial del desarrollo de la madurez y suinstitucionalidad ser la persecucin de planes y procedimientos instaurados en una con ms madurez. La estimacin de un CMMI involucra reconocer los procesos en una empresa y clasificarlos en una escala de seis puntos que manifiestan el nivel de madurez en cada rea del proceso. La asignacin a un proceso del nivel dentro de la escala de seis puntos se indica a continuacin:

Esto es una resea reducida de los niveles de capacidad, las mediciones que se hagan del proceso y producto dirigirn la estandarizacin del proceso para transformarlo y mejorarlo. a) Modelo CMMI en etapas Suministra una forma de estimar la capacidad del proceso de una organizacin clasificndola en uno de cinco niveles, as mismo detalla las metas que se deben lograr en cada uno de estos niveles. La mejora de procesos se lleva a cabo implementando prcticas en cada nivel, escalando desde el nivel inferior hasta el superior del modelo.

En cada nivel de madurez se tiene asociado un conjunto de reas de proceso y metas genricas.

b) Modelo CMMI continuo Los modelos de madurez continuos no catalogan a las empresas en niveles discretos, consideran las prcticas individuales, grupos de stas y sus

evaluaciones. La estimacin de la madurez es un conjunto de valores que exponen la madurez de la empresa para cada proceso o grupo de procesos. El modelo CMMI continuo evala cada rea de proceso (que se observan en la imagen de abajo), asignando un nivel de valoracin entre 1 y 6 a cada rea del proceso.

Ahora, en la siguiente figura se exhibe un trozo de un perfil de capacidad donde vemos distintos procesos con diversos niveles de capacidad:

La ventaja importante del modelo continuo es que las empresas pueden seleccionar procesos de mejora en concordancia con sus propias necesidades y requerimientos. Por experiencia se sabe que distintos tipos de organizaciones tienen diferentes requerimientos en su mejora de procesos. As las empresas manejan diferentes niveles de madurez en distintas reas de proceso. Por lo que, el resultado de una evaluacin con el modelo CMMI continuo es un perfil de capacidad que evidencia a cada rea de proceso con su correspondiente estimacin de capacidad.

Conclusin
En cualquier esfuerzo por mejorar la calidad del software es necesario, desde el punto de vista de la ingeniera de software, saber mejorar el proceso; esto implica un anlisis de procesos, una estandarizacin, las mediciones y las modificaciones, comprender cul es el ciclo de mejora y establecer metas. Se pueden usar mtricas de proceso como las de tiempo, de uso de recursos y de eventos, esto nos da una evaluacin cuantitativa. Tenemos modelos que captan las caractersticas de los procesos y un modelo a usar puede ser el CMMI que se ha descrito para concluir este tema.