TEMARIO.

MODULO I. SOFTWARE. 1.1 1.2 CARACTERSTICAS DEL SOFTWARE APLICACIONES DEL SOFTWARE

1.2.1 SOFTWARE DE SISTEMAS 1.2.2 SOFTWARE DE TIEMPO REAL 1.2.3 SOFTWARE DE GESTIN 1.2.4 SOFTWARE DE INGENIERA Y CIENTFICO 1.2.5 SOFTWARE EMPOTRADO 1.2.6 SOFTWARE DE COMPUTADORAS PERSONALES 1.2.7 SOFTWARE DE INGENIERA ARTIFICIAL PERSONAL MODULO II. EL SOFTWARE CON PROCESO. 2.1 INGENIERA DE SOFTWARE 2.2 EL PROCESO DE SOFTWARE 2.3 MODELOS DEL PROCESO DE SOFTWARE

MODULO III. PARADIGMAS DEL SOFTWARE. 3.1 PARADIGMA DEL CICLO DE VIDA 3.2 PARADIGMA DE CONSTRUCCIN DE PROTOTIPOS 3.3 PARADIGMA DE MODELO EN ESPIRAL 3.4 TCNICAS DE CUARTA GENERACIN 3.5 COMBINACIN DE PARADIGMAS MODULO IV. ANLISIS Y ESPECIFICACIN DE REQUISITOS.

4.1 IDENTIFICACIN DE LOS REQUISITOS DEL SOFTWARE 4.2 ANLISIS DE REQUISITOS 4.3 DEFINICIN DE LOS REQUISITOS FUNCIONALES 4.4 DEFINICIN DE LOS REQUISITOS NO FUNCIONALES 4.5 ESPECIFICACIN DE LOS REQUISITOS DEL SOFTWARE 4.6 REVISIN DE LA ESPECIFICACIN

MODULO V. VISIN GENRICA DE LA INGENIERA DE SOFTWARE. 5.1 DEFINICIN 5.2 DESARROLLO 5.3 MANTENIMIENTO

MODULO VI. ADMINISTRACIN DE PROYECTOS. 6.1 IMPORTANCIA DE LA ADMINISTRACIN DE PROYECTOS 6.2 FUNCIONES DE LA ADMINISTRACIN DE PROYECTOS 6.3 QUE ES EL ADMINISTRADOR DE PROYECTOS 6.3.1 FUNCIONES DEL ADMINISTRADOR DE PROYECTOS

MODULO VII. LAS MTRICAS DEL PROYECTO. 7.1 MTRICAS DEL SOFTWARE

7.1.1 MTRICAS ORIENTADAS AL TAMAO 7.1.2 MTRICAS ORIENTADAS A LA FUNCIN

MODULO VIII. ESTIMACIN DEL PROYECTO. 8.1 MODELOS DE ESTIMACIN 8.2 TCNICAS DE DESCOMPOSICIN 8.2.1 BASADO EN EL TAMAO 8.2.2 BASADO EN EL PROBLEMA 8.2.3 BASADO EN EL NMERO DE LNEAS DE (LDC) CDIGO 8.2.4 BASADO EN EL PROCESO

ANTOLOGA

UNIVERSIDAD DE GUADALAJARA

CENTRO UNIVERSITARIO DE LOS LAGOS

MATERIA: INGENIERA DE SOFTWARE I

ALUMN0S: ALEJANDRO FARIAS RAMIREZ EDUARDO GONZALEZ LUNA

LAGOS DE MORENO, JALISCO.

INTRODUCCIN En este trabajo se explican los paso comunes o bsicos a seguir para la generacin de un software de calidad, as como la los

pasos a seguir para ir generando un software sin errores y estable, por medio de pruebas. Con la construccin de prototipos se realizaran los cambios necesarios para un software de calidad, as completar los prototipos por medio de diferentes paradigmas o mtodos de construccin para el software.

Tambin se consideraran las mtricas que deben de llevar los programas para poder ofrecer un tiempo y costo del proyecto para su posterior venta ahora nosotros te preguntamos como desarrollador de software te preguntamos Cunto crees que vale tu tiempo?

MODULO 1: SOFTWARE 1.1 Software Se refiere al equipamiento lgico o soporte lgico de una computadora digital, y comprende el conjunto de los componentes lgicos necesarios para hacer posible la realizacin de tareas especficas; en contraposicin a los componentes fsicos del sistema, llamados hardware. 1.2 Caractersticas Del Software 1. El software se desarrolla o construye; no se manufactura en el sentido clsico. A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware, las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseo, la fase de manufactura del hardware puede incluir problemas de calidad existentes en el software. 2. El software no se desgasta. El software es inmune a los males ambientales que desgasten el hardware. Por lo tanto la curva de tasas de fallas para el software debera tener la forma de la curva idealizada. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen y la curva se aplana: el software no se desgasta, pero si se deteriora. 3. A pesar de que la industria tiene una tendencia hacia la construccin por componentes, la mayora del software aun se construye a la medida.

1.2.1 Software De Sistema En terminologa informtica el software de sistema, denominado tambin software de base, consiste en programas informticos que sirven para controlar e interactuar con el sistema operativo, proporcionando control sobre el hardware y dando soporte a otros programas; en contraposicin del llamado software de aplicacin. Como ejemplos cabe mencionar a las bibliotecas como por ejemplo OpenGL para la aceleracin grfica, PNG para el sistema grfico o demonios que controlan la temperatura, la velocidad del disco duro, como hdparm, o la frecuencia del procesador como cpudyn. Uno de los ms prominentes ejemplos de software de sistema se encuentra en el proyecto GNU, cuyas herramientas de programacin permitieron combinarse con el ncleo informtico basado en Unix denominado Linux, formando entre ambos las conocidas como distribuciones Linux. Estos programas realizan diversas tareas, como la transferencia de datos entre la memoria RAM y los dispositivos de almacenamiento (disco rgido, unidades de discos pticos, etc) entre otros. 1.2.2 Software De Tiempo Real El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al mbito del problema en un tiempo dictado por el mbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las caractersticas del sistema operativo, por los requisitos de la

aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo. La computadora en digital al se ha diaria convertido de todos en una maquina Las

omnipresente

vida

nosotros.

computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ltimas generaciones de coches y programar a nuestros aparatos. Todas estas interacciones con las computadoras 1.2.3 Software de Gestin Es un programa que sirve como herramienta la cual es

desarrollada especialmente para adecuarse a los diferentes requerimientos de las empresas. Es una solucin diseada para empresas medianas y grandes dinmicas con con necesidades de alta competitividad, que buscan la eficiencia en sus procesos internos y en la gestin con terceros Software de Gestin y Programacin. 1.2.4 Software De Ingeniera Y Cientfico Utiliza algoritmos de manejo de nmeros, simulacin de sistemas, utiliza software en tiempo real. Astronoma, clculo, Biologa molecular, Fabricacin automtica. 1.2.5 Software Empotrado Reside en memorias ROM y sirve para controlar productos y sistemas de los mercados industriales. Lavadoras, Microondas

1.2.6 Software Para PC Aplicaciones orientadas a usuarios individuales o multiusuario Procesadores de texto Hojas de clculo Juegos, Aplicaciones financieras, Gestores de base de datos 1.2.7 Software De Inteligencia Artificial Hace uso de algoritmos no numricos para resolver complejos para el que no son adecuados el clculo o el anlisis directo. Sistemas Expertos Reconocimiento de Patrones (OCR) Prueba de teoremas Redes neuronales artificiales 1.2.8 Problemas Del Software Defectos de diseo de programas Diseos con colores inapropiados para las personas que padecen daltonismo

Diseos que usan textos con tipografas de difcil lectura por su tamao o diseo. Diseos que fuerzan el uso del ratn o mouse sin dejar alternativas de teclado para personas con disfunciones motrices.

Diseos con implicaciones culturales, por ejemplo usando partes del cuerpo que en una determinada cultura sean objeto de vergenza o burla o smbolos con caractersticas de identidad cultural o religiosa.

Estimar que el equipo donde se instalar tiene determinadas caractersticas como la resolucin de la pantalla, la

velocidad

del

procesador,

la

cantidad

de

memoria

conectividad a internet Objetos intrusivos y obstrusivos como cuadros de dilogo modales al sistema o asistentes como "Clippy" (Clipo, en espaol) que impeda el uso uniforme de Office de Microsoft. Errores de programacin comunes]

Divisin por cero Ciclo infinito Problemas aritmticos como desbordamientos (overflow) o subdesbordamientos (underflow). Exceder el tamao del array Utilizar una variable no inicializada Acceder a memoria no permitida (Access violation) Prdida de memoria (memory leak) Desbordamiento o subdesbordamiento de la pila (estructura de datos) Buffer overflow Deadlock Indizado inadecuado de tablas en bases de datos.

Defectos de instalacin o programacin Eliminacin o sustitucin de bibliotecas comunes a ms de un programa o del sistema (DLL Hell).

Reiniciar arbitrariamente la sesin de un usuario para que la instalacin tenga efecto. Presuponer que el usuario tiene una conexin permanente a internet.

Cdigos de errores de lenguajes de programacin La mayor parte de los lenguajes de programacin presentan al menos dos tipos de errores que permiten a los programadores manejar las fallas de los programas de una manera eficiente y que no resulte agresiva con el usuario final. Dichos errores son de compilacin y errores en tiempo de ejecucin. MODULO2: SOFTWARE COMO PROCESO 2.1 Ingeniera De Software La ingeniera del software es el desarrollo, operacin y mantenimiento del software de forma sistemtica, disciplinada y cuantificable, y el estudio de dichos mtodos.

En otras palabras, es el estudio dedicado a la creacin de software de buena calidad, barato y fcil de desarrollar y mantener. Es la aplicacin de la ingeniera al software.

La ingeniera del software comienza a formalizarse a finales de la dcada del 1960. Con el transcurso de los aos se han desarrollado recursos que conforman la ingeniera del software, es decir, herramientas y tcnicas de especificacin, diseo e implementacin del software. 2.2 El Proceso Del Software Conjunto estructurado de actividades requeridas para

desarrollar un sistema de software. Especificacin. Diseo. Validacin.

 Evolucin. Las actividades varan dependiendo de la organizacin y del tipo de sistema a desarrollarse. Debe estar explcitamente modelado si va a ser bien administrado. Caractersticas Entendible Se encuentra el proceso bien definido y es entendible? Visible El proceso es visible al exterior? Soportable Puede el proceso ser soportado por herramientas CASE? Aceptable El proceso es aceptado por aquellos involucrados en el ?. Confiable Los errores del proceso son descubiertos antes de que se conviertan en errores del producto? Robusto Puede continuar el proceso a pesar de problemas inesperados? Mantenible Puede el proceso evolucionar para cumplir con los objetivos organizacionales ?

Rapidez Que tan rpido puede producirse el sistema? Problemas Normalmente, las especificaciones son incompletas o anmalas. No existe una distincin precisa entre la especificacin, el diseo y la manufactura Solo hasta que el sistema se ha producido se puede probar El software no se puede remplazar siempre durante el

mantenimiento

2.3 MODELOS DEL PROCESO DEL SOFTWARE Los estndares establecen los diferentes procesos implicados a la hora de desarrollar y mantener un sistema desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que stas se retiran de explotacin. Sin embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de vida) ni cmo realizar las diferentes actividades incluidas en cada proceso, por lo que cada empresa deber utilizar los mtodos, tcnicas y herramientas que considere oportuno. Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del software es una simplificacin o abstraccin de un proceso real. Podemos definir un modelo de procesos del software como una representacin abstracta de alto nivel de un proceso software. Cada modelo es una descripcin de un proceso software que se presenta desde una perspectiva particular. Alternativamente,

A veces se usan los trminos ciclo de vida y Modelo de ciclo de vida. Cada modelo describe una sucesin de fases y un encadenamiento entre ellas. Segn las fases y el modo en que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es ms adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de caractersticas de ste. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a continuacin. MODULO 3: PARADIGMAS DEL SOFTWARE 3.1. Paradigma Ciclo De Vida Del Software Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: anlisis, diseo, codificacin, prueba y mantenimiento.

Ingeniera y anlisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algn subconjunto de estos requerimientos al software; esta versin del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos. La ingeniera y anlisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequea cantidad de anlisis y diseo a nivel superior. Adems de un anlisis costo beneficio del sistema es decir si toda la inversin que se har para el sistema conviene a los beneficios que traer el mismo. Anlisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la informacin del software, as como la funcin, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente. Diseo. El diseo del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.

estructura de datos arquitectura de software detalle procedimental

El diseo traduce los requerimientos en una representacin del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificacin. Como los

requerimientos y el diseo que se documentan forman parte de la configuracin del software. Codificacin. El diseo debe traducirse en una forma legible. El paso de la codificacin ejecuta la tarea de establecer la etapa de diseo legible para la maquina, si el diseo se ejecuta de una manera detallada la codificacin puede realizarse mecnicamente. Prueba. Una vez que se ha generado el cdigo, comienza la prueba del programa, la prueba se enfoca sobre la lgica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producir los resultados que realmente se requieren. Mantenimiento. El software sufrir indudablemente cambios

despus que se le entregue al cliente los cambios ocurrirn debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos perifricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo. El ciclo de vida clsico es el ms viejo y ms ampliamente usado paradigma en la ingeniera de software. Sin embargo con el paso de unos cuantos aos se han producido criticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas veces cuando se aplica este paradigma se encuentran:

1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre ocurre iteraciones y se crea problemas en la aplicacin del paradigma. 2. Normalmente es difcil para el cliente establecer explcitamente el principio todos los requerimientos del sistema. El ciclo de vida clsico requiere esto y tiene dificultades para acomodar posibles incertidumbres que puedan existir al comienzo de dichos proyectos. 3. El cliente debe tener paciencia. Una versin funcional del programa no esta disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no detectado hasta que el programa este en funcionamiento puede ser desastroso. 4. Los responsables del desarrollo se retrasan innecesariamente. 3.2 Paradigma De Construccin De Prototipos. Este modelo tambin denominado modelo de desarrollo evolutivo. Para comprender este modelo, comenzaremos con la definicin de los objetivos globales para el software, despus identificaremos los requerimientos que conocemos y los sitios del diseo en donde es necesaria ms definicin. Entonces planteamos con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en forma de un diseo rpido). Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez ms completas del software. El diseo rpido se basa en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El

diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. CONSTRUCCION DE PROTOTIPOS A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humana mquina, entonces en este caso cuando utilizamos la construccin de prototipos.

El paradigma de construccin de prototipos se inicia con la comunicacin. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms definicin. Entonces se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en la forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario final. El diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer. Ventajas:

No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera. Desventajas A los usuarios la les gusta el de sistema real y se a los desarrolladores les gusta construir algo de inmediato. Sin embargo, construccin prototipos torna problemtica por las siguientes razones: El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema aun no ha sido construido. El desarrollador puede caer en la tentacin de aumentar el prototipo para tiene con el cliente. 3.3 Paradigma De Modelo En Espiral. Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones incremntales. Durante las primeras iteraciones. La versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez mas completas de ingeniera del sistema. Caractersticas:

construir el sistema final sin tener en

cuenta las obligaciones de calidad y de mantenimiento que

Es tambin al igual que el anterior un modelo evolutivo que combina el modelo clsico con el diseo de prototipos.

Incluye

la

etapa

de

anlisis

de

riesgos,

no

incluida

anteriormente.

Es ideal para crear productos con diferentes versiones mejoradas como se hace con el software moderno de microcomputadoras.

La ingeniera puede desarrollarse a travs del ciclo de vida clsico o el de construccin de prototipos. Este es el enfoque ms realista actualmente.

El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. Comunicacin con el cliente: las tareas requeridas para

establecer comunicacin entre el desarrollador y el cliente. Planificacin: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras informaciones relacionadas con el proyecto. Ingeniera: las tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluacin el cliente: las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementacin durante la etapa de instalacin.

Cuando empieza el proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificacin de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la regin de planificacin produce ajustes en el plan del proyecto. El coste y la planificacin se ajustan segn la reaccin ante la evolucin del cliente. Ventajas:

El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.

Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto.

Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en

problemticos. Pero al igual que otros paradigmas puede resultar difcil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. El modelo en s mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construccin de prototipos. Todava tendrn que pasar muchos aos antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma. La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a travs del cubo siguiente y se inicia un nuevo proyecto de desarrollo.

Problemas:

Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable. Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolucin

3.4 Paradigma De Tcnicas De Cuarta Generacin El termino de tcnicas de cuarta generacin (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas caractersticas de alto nivel. Luego la herramienta genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniera de software se orienta hacia la habilidad de especificar software a un nivel que

sea ms prximo al lenguaje natural o a una notacin que proporcione funciones significativas. Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generacin de informes, manipulacin de datos, interaccin y definicin de pantallas y generacin de cdigos, capacidades grficas de alto nivel y capacidad de hojas de clculo. Cada una de estas herramientas existen, pero solo son para dominios de aplicacin muy especficos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categoras de aplicaciones de software. El paradigma T4G para la ingeniera de software se describe en la siguiente figura:

3.5 Combinacin De Paradigmas Frecuentemente se describe a los paradigmas de la ingeniera de software tratados en las secciones anteriores como mtodos

alternativos, para la ingeniera de software en vez de los mtodos complementarios. En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un nico proyecto. La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recoleccin de requerimientos. El mtodo puede seguir el ciclo de vida clsico (ingeniera de sistemas anlisis de requerimiento de software) o puede ser la definicin menos formal del problema usada en la construccin de un prototipo, independientemente debe producirse la comunicacin cliente-realizador del software.

La naturaleza de aplicacin dictara la aplicabilidad del mtodo de construccin de prototipos. Si los requerimientos para la funcin y rendimiento del software ser estn razonablemente los mtodos bien de comprendidos pueden aplicables

especificacin recomendados para el ciclo de vida clsico. Por otra parte si la aplicacin del software exige una fuerte interaccin hombre-maquina o requiere algoritmos no probados o

tcnicas de control de salidas pueden regresarse a un prototipo. En tales casos puede usarse un lenguaje de cuarta generacin para el desarrollo de un prototipo. Una vez que se haya evaluado y reafinado el prototipo pueden aplicarse los pasos de diseo e implementacin del ciclo de vida clsico para desarrollar el software formalmente. MODULO 4: ANALISIS Y ESPECIFICACIN DE REQUISITOS

4.1 Identificacin De Requerimientos. Se identificaron cules son las funciones principales del sistema y se asign una prioridad. A travs de una descripcin de cada componente segn la visin de los usuarios finales (docentes, alumnos, administradores) que expresaron expectativas de la herramienta. htttp://penguien.ens.uabc.mx/~uvirtual/ Se pueden identificar dos formas de requisitos:

sus necesidades y

Requisitos de usuario: Los requisitos de usuario son frases en lenguaje natural junto a diagramas con los servicios que el sistema debe proporcionar, as como las restricciones bajo las que debe operar.

Requisitos de sistema: Los requisitos de sistema determinan los servicios del sistema y pero con las restricciones en detalle. Sirven como contrato.

Es decir, ambos son lo mismo, pero con distinto nivel de detalle. Ejemplo de requisito de usuario: El sistema debe hacer prstamos Ejemplo de requisito de sistema: Funcin prstamo: entrada cdigo socio, cdigo ejemplar; salida: fecha devolucin; etc.

Se clasifican en tres los tipos de requisitos de sistema:

Requisitos funcionales

Los requisitos funcionales describen:

Los servicios que proporciona el sistema (funciones). La respuesta del sistema ante determinadas entradas. El comportamiento del sistema en situaciones particulares. Requisitos no funcionales

Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema (ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.) Ejemplo 1. La biblioteca Central debe ser capaz de atender simultneamente a todas las bibliotecas de la Universidad Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s A su vez, hay tres tipos de requisitos no funcionales:

Requisitos del producto. Especifican el comportamiento del producto (Ej. prestaciones, memoria, tasa de fallos, etc.) Requisitos organizativos. Se derivan de las polticas y procedimientos de las organizaciones de los clientes y desarrolladores (Ej. estndares de proceso, lenguajes de programacin, etc.)

Requisitos externos. Se derivan de factores externos al sistema y al proceso de desarrollo (Ej. requisitos legislativos, ticos, etc.)

Requisitos del dominio.

Los requisitos del dominio se derivan del dominio de la aplicacin y reflejan caractersticas de dicho dominio. Pueden ser funcionales o no funcionales. Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos mediante el Lenguaje de Intercomunicacin de Bibliotecas de Espaa (LIBE). Ej. El sistema de biblioteca no podr acceder a bibliotecas con material censurado.

4.2 Anlisis De Requisitos Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza, y, segn el modelo de proceso adoptado, puede casi terminar para pasar a la prxima etapa (caso de Modelo Cascada Realimentado) o puede hacerse parcialmente para luego retomarla (caso Modelo Iterativo Incremental u otros de carcter evolutivo). En simple palabras y bsicamente, durante esta fase, se adquieren, renen y especifican las caractersticas funcionales y no funcionales que deber cumplir el futuro programa o sistema a desarrollar. Las bondades de las caractersticas, tanto del sistema o programa a desarrollar, como de su entorno, parmetros no funcionales y arquitectura dependen enormemente de lo bien lograda que est esta etapa. Esta es, probablemente, la de mayor importancia y una de las fases ms difciles de lograr certeramente, pues no es automatizable, no es muy tcnica y depende en gran medida de la habilidad y experiencia del analista que la realice.

Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy subjetivos y es difcil de modelar con certeza y/o aplicar una tcnica que sea "la ms cercana a la adecuada" (de hecho no existe "la estrictamente adecuada"). Si bien se han ideado varias metodologas, incluso software de apoyo, para captura, licitacin y registro de requisitos, no existe una forma infalible o absolutamente confiable, y deben aplicarse conjuntamente buenos criterios y mucho sentido comn por parte del o los analistas encargados de la tarea; es fundamental tambin lograr una fluida y adecuada comunicacin y comprensin con el usuario final o cliente del sistema. El artefacto ms importante resultado de la culminacin de esta etapa es lo que se conoce como especificacin de requisitos software o simplemente documento ERS. Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental; lo comn es que el cliente tenga un objetivo general o problema a resolver, no conoce en absoluto el rea (informtica), ni su jerga, ni siquiera sabe con precisin qu debera hacer el producto software (qu y cuantas funciones) ni, mucho menos, tiene cmo que debe operar. y En otros casos menos muy frecuentes, el cliente "piensa" que sabe precisamente lo que el software hacer, generalmente acierta parcialmente, pero su empecinamiento entorpece la tarea de licitacin. El analista debe tener la capacidad para lidiar con este tipo de problemas, que incluyen relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir una adecuada comunicacin y comprensin. Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo que requiere de su futuro sistema, este es el caso ms sencillo para el analista.

Las tareas relativas a captura, licitacin, modelado y registro de requerimientos, adems de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y metodologas para llevar a cabo este conjunto de actividades normalmente se las asume parte propia de la Ingeniera de Software, pero dada la antedicha complejidad, actualmente se habla de una Ingeniera en Requisitos[11] , aunque ella an no existe formalmente. Hay grupos de estudio e investigacin, en todo el mundo, que estn exclusivamente abocados a la idear modelos, tcnicas y procesos para intentar lograr la correcta captura, anlisis y registro de requerimientos. Estos grupos son los que normalmente hablan de la Ingeniera en Requisitos; es decir se plantea sta como un rea o disciplina pero no como una carrera universitaria en si misma. Algunos requisitos no necesitan la presencia del cliente, para ser capturados y/o analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar unilateralmente decisiones que considera adecuadas (tanto en requerimientos funcionales como no funcionales). Por citar ejemplos probables: Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o ligas entre la informacin (entre registros o tablas de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o de soporte necesarias para una mejor o ms sencilla operatividad; etc. La obtencin de especificaciones a partir del cliente (u otros actores intervinientes) es un proceso humano muy interactivo e iterativo; normalmente a medida que se captura la informacin, se

la analiza y realimenta con el cliente, refinndola, pulindola y corrigiendo si es necesario; cualquiera sea el mtodo de ERS utilizado. EL analista siempre debe llegar a conocer la temtica y el problema a resolver, dominarlo, hasta cierto punto, hasta el mbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad para comprender problemas de muy diversas reas o disciplinas de trabajo (que no son especficamente suyas); as por ejemplo, si el sistema a desarrollar ser para gestionar informacin de una aseguradora y sus sucursales remotas, el analista se debe compenetrar en cmo ella trabaja y maneja su informacin, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas, es decir gente que conoce profundamente el rea para la cual se desarrollar el software; evidentemente una nica persona (el analista) no puede abarcar tan vasta cantidad de reas del conocimiento. En empresas grandes de desarrollo de productos software, es comn tener analistas especializados en ciertas reas de trabajo. Contrariamente, no es problema del cliente, es decir l no tiene por qu saber nada de software, ni de diseos, ni otras cosas relacionadas; slo se debe limitar a aportar objetivos, datos e informacin (de mano propia o de sus registros, equipos, empleados, etc.) al analista, y guiado por l, para que, en primera instancia, defina el "Universo de Discurso", y con posterior trabajo logre confeccionar el adecuado documento ERS. Es bien conocida la presin que sufren los desarrolladores de sistemas informticos para comprender y/o rescatar las necesidades de los clientes/usuarios. Cuanto ms complejo es el contexto del problema ms difcil es lograrlo, a veces se fuerza a

los desarrolladores a tener que convertirse en casi expertos de los dominios que analizan. Cuando esto no sucede es muy probable que se genere un conjunto de requisitos[12] errneos o incompletos y por lo tanto un producto de software con alto grado de desaprobacin por parte de los clientes/usuarios y un altsimo costo de reingeniera y mantenimiento. Todo aquello que no se detecte, o resulte mal entendido en la etapa inicial provocar un fuerte impacto negativo en los requisitos, propagando esta corriente degradante a lo largo de todo el proceso de desarrollo e incrementando su perjuicio cuanto ms tarda sea su deteccin (Bell y Thayer 1976) (Davis 1993). 4.3 Definicin de Requisitos Funcionales En tecnologa de dotacin lgica, a requisito funcional define una funcin de a sistema de software o su componente. Una funcin se describe como sistema de entradas, del comportamiento, y de las salidas (vase tambin software). Los requisitos funcionales de pueden datos y ser el clculos, proceso y detalles la otra

tcnicos,

manipulacin

funcionalidad especfica que demuestran cmo a utilice el caso es ser satisfecho. Se apoyan cerca requisitos no funcionales, que imponen apremios ante el diseo o la puesta en prctica (tal como requisitos de funcionamiento, seguridad, o confiabilidad). Segn lo definido adentro ingeniera de requisitos, los requisitos funcionales especifican comportamientos particulares de un sistema. Esto se debe poner en contraste con requisitos no funcionales cules especifican caractersticas totales tales como coste y confiabilidad.

Tpicamente, un analista de los requisitos genera requisitos funcionales despus de construir utilice los casos. Sin embargo, esto puede tener excepciones puesto que el desarrollo del software es un proceso iterativo y requisitos a veces ciertos se conciben antes de la definicin de los casos del uso. Ambos artefactos (el uso encajona documentos y documentos de los requisitos) complemntese en un proceso bidireccional. Proceso Un requisito funcional tpico contendr un nombre y un nmero nico, un breve resumen, y un anlisis razonado. Esta informacin se utiliza para ayudar al lector a entender porqu el requisito es necesario, y a seguir el requisito con el desarrollo del sistema. 4.4 Definicin De Los Requisitos No Funcionales Un requisito no funcional (NFR) especifica los criterios que se deben usar para juzgar el funcionamiento de un sistema (operacin of a system), en lugar de un comportamientos especfico (specific behavior). En general, los requisitos funcionales definen lo que el sistema debera de hacer, mientras que los requisitos no funcionales verifican cmo un sistema debera de ser. Requisitos no funcionales son a menudo llamados las cualidades de un sistema. Puede dividirse en dos categoras: 1. Execution qualities: como por ejemplo la seguridad y facilidad de uso, que son observables en tiempo de ejecucin. 2. Evolution qualities, como por ejemplo el mantenibilidad, extensibilidad y escalabilidad, que estn ms vinculados a la estructura del sistema de software.

Algunos

ejemplos

de

requerimientos y control,

no

funcionales

son: de

Accesibilidad,

Auditora

Disponibilidad,

Copia

seguridad,

Capacidad

actual

previsiones,

Certificacin,

Recuperacin de Desastres, Eficiencia (consumo de recursos para la carga dada), Eficacia (resultante de rendimiento en relacin con el esfuerzo), Extensibilidad, Interoperabilidad, Mantenimiento, Operatividad, Rendimiento / Tiempo de respuesta (vase el rendimiento de Ingeniera), Portabilidad, Recuperacin, Fiabilidad (por ejemplo, Tiempo medio entre fallos MTBF), Las limitaciones de recursos (la velocidad del procesador, memoria, espacio en disco, ancho de banda de red etc.), Tiempo de respuesta, Robustez, Escalabilidad Seguridad, Una buena definicin de requerimientos no funcionales (NFR) es tan importante como los requisitos funcionales. Deben de ser apropiadamente definidos, analizados y trazados. 4.5 Especificacin De Requisitos Del Software Una especificacin de requisitos del software es una descripcin completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen no todas las (o interacciones que se prevn que los usuarios tendrn con el software. Tambin contiene requisitos funcionales suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseo o funcionamiento del sistema (tal como requisitos de funcionamiento, estndares de calidad, o requisitos del diseo). Las estrategias recomendadas para la especificacin de los requisitos del software estn descritas por IEEE 830-1998. Este estndar describe las estructuras posibles, contenido deseable, y calidades de una especificacin de requisitos del software. Los requisitos se dividen en tres: (horizontal, vertical), Seguridad, Estabilidad,

Funcionales: son los que el usuario necesita que efecte el software. Ej.: el sistema debe emitir un comprobante al asentar la entrega de mercadera.

No funcionales: son los "recursos" para que trabaje el sistema de informacin (redes, tecnologa). Ej.: el soporte de almacenamiento a usar debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual en el cual se implantar el sistema para conseguir un objetivo macro. Ej.: abaratar costos de expedicin.

4.6 Revisin De La Especificacin Personal involucrado: Cliente y analista Nivel macroscpico - Verificar que es completa, consistente y exacta : Metas y objetivos? : Interfaces? : Flujo y estructura de la informacin? Nivel macroscpico (II) : Inconsistencias, omisiones, redundancias? : Prototipo o manual de usuario? : Diagramas claros? Nivel detallado Conectores persuasivos (ciertamente, claramente, obviamente,...) Trminos imprecisos (algunos, a veces, normalmente, en la mayora de ....) Trminos de certidumbre (siempre, todos, nunca, ...) Nivel detallado (II) Rangos: (10..100) enteros, reales? Ejemplos para los clculos No ambigedad OBJETIVO / FINALIDAD Revisin -> Firma del documento ERS CONTRATO entre cliente y empresa Cambios en requisitos -> Ampliacin plazos fechas, costes y modificacin del mbito del sistema

MODULO 5: VISIN GENERICA DE LA INGENIERIA DE SOFTWARE 5.1 Definicin Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un producto diseado para un usuario". En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. 5.2 Desarrollo El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998].El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson 1998].

El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin. La concepcin define le alcance del proyecto y desarrolla un caso de negocio. La elaboracin define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. La construccin crea el producto y la transicin transfiere el producto a los usuarios. Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de informacin. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnologa de informacin OO. El OMG tiene como objetivo central la promocin, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnologa OO. Una de las especificaciones ms importantes es la adopcin en 1998 del Lenguaje de Modelado Unificado o UML (del ingls Unified Modeling Language) como un estndar, que junto con el Proceso Unificado estn consolidando la tecnologa OO. Etapas del proceso La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes: Anlisis de requisitos Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer

requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requisitos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software. La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est formalizada, ya se habla de la Ingeniera de Requisitos. La IEEE Std. 830-1998 normaliza la creacin de las

Especificaciones de Requisitos Software (Software Requirements Specification). Especificacin La Especificacin de Requerimientos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del xito de un proyecto de software radicar en la identificacin de las necesidades del negocio (definidas por la alta direccin), as como la interaccin con los usuarios funcionales para la recoleccin, clasificacin, identificacin, priorizacin y especificacin de los requerimientos del software. Entre las tcnicas utilizadas para la especificacin de

requerimientos se encuentran:

Casos de Uso, Historias de usuario,

Siendo los primeros ms rigurosos y formales, los segundas ms giles e informales. Arquitectura La integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas. La Arquitectura de Sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseo arquitectnico describe en general el cmo se construir una aplicacin de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases Diagramas de base de datos Diagramas de despliegue plegados Diagramas de secuencia multidireccional Diagramas de infraestructura qumica

Siendo los dos primeros los mnimos necesarios para describir la arquitectura de un proyecto que iniciar a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el

arquitecto elige qu diagramas elaborar. Entre las herramientas para disear arquitecturas de software se encuentran:

Enterprise Archit Microsoft Visio for Enterprise Architects

Programacin Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado. Prueba Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qu condiciones

puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara. Documentacin Todo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales tcnicos, etc.; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. 5.3 Mantenimiento Mantener y mejorar el software para enfrentar errores

descubiertos y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento. MODULO 6: ADMINISTRACIN DEL PROYECTO Es la planeacin, organizacin, direccin y control de los recursos para lograr un objetivo a corto plazo. Tambin se dice que la administracin de proyectos ocurre cuando se da un nfasis y una atencin especial para conducir actividades no repetitivas con el propsito de lograr un conjunto de metas. Esta actividad es llevada a cabo por un conjunto de

administradores que actan como agentes unificadores para

proyectos

particulares,

tomando

en

cuenta

los

recursos

existentes, tales como el tiempo, materiales, capital, recursos humanos y tecnologa. 6.1 Importancia De La Administracin De Proyectos La administracin de proyectos implica una gran importancia, por lo que es usada en una gran diversidad de campos; desde proyectos espaciales, en bancos, en desarrollo de sistemas en computadora, en procesamiento de hidrocarbono, en la industria petroqumica, en telecomunicaciones, en defensa nacional, etc. Los cambios tecnolgicos, la necesidad de introducir nuevos productos al mercado, las cambiantes exigencias de los consumidores de productos, entre otras cosas, incrementan el fluido de operaciones en una organizacin, provocando que los mtodos de administrativos convencionales sean inadecuados. Por esta razn la administracin de proyectos es importante, ya que ofrece nuevas alternativas de organizacin. Sirve para aprovechar de mejor manera los recursos crticos cuando estn limitados en cantidad y/o tiempo de disponibilidad. Tambin ayuda a realizar acciones concisas y efectivas para obtener el mximo beneficio. 6.2 Funciones De La Administracin De Proyectos La administracin procura siempre el mximo aprovechamiento de los recursos, mediante su utilizacin eficiente. Las principales funciones de la administracin se engloban en planeacin, organizacin, direccin y control. Durante la planeacin se decide anticipadamente qu, quin, cmo, cundo y por qu se har el proyecto. Las tareas ms importantes de la planeacin son determinar el status actual de la

organizacin, pronosticar a futuro, determinar los recursos que se necesitarn, revisar y ajustar el plan de acuerdo con los resultados de control y coordinar durante todo el proceso de planeacin. La organizacin realiza actividades en grupo, de asignacin y asesoramiento, y proporciona la autoridad necesaria para llevar a cabo las actividades. Dentro de esta etapa se identifica, define y divide el trabajo a realizar, se agrupan y definen los puestos, se proporcionan los recursos necesarios y se asignan los grados de autoridad. El siguiente paso es la direccin, la cual sirve para conducir el comportamiento humano hacia las metas establecidas. Aqu se comunican y explican los objetivos a los subordinados, se asignan estndares, se entrena y gua a los subordinados para llegar a los estndares requeridos, se recompensa el rendimiento y se mantiene un ambiente motivacional. Por ltimo se encuentra el control, que se encarga de medir el rendimiento obtenido en relacin a las metas fijadas. En caso de haber desviaciones, se determinan las causas y se corrige lo que sea necesario. 6.3 Que Es El Administrador De Proyectos El administrador de proyectos puede ser definido como el individuo que cumple con la tarea de integrar los esfuerzos dirigidos hacia la ejecucin exitosa de un proyecto especfico. Esta persona enfrenta un conjunto de circunstancias nico en cada proyecto. El administrador de proyectos es una extensin del administrador general de una organizacin.

6.3.1 Funciones Del Administrador De Proyectos El administrador de proyectos opera independientemente de la cadena de mando normal dentro de la organizacin. Debe dirigir y evaluar el proyecto; tambin planear, proponer e implementar polticas de administracin de proyectos, asegurar la finalizacin del proyecto mediante compromisos contractuales. Otras tareas que debe cumplir son desarrollar y mantener los planes del proyecto, darle una calendarizacin y financiamiento adecuados al proyecto y evaluar y reportar su avance. Debe resolver los problemas a travs de decisiones orientadas al objetivo. Adems, el administrador de proyecto debe resolver las siguientes preguntas: * Qu se va a hacer? * Cundo se va a hacer? * Por qu se va a hacer? * Cunto dinero est disponible para hacerlo? * Qu tan bien se est haciendo el proyecto?

MODULO 7: LAS METRICAS DEL PROYECTO

7.1 Mtricas Del Software. Cuando pueda medir lo que est diciendo y expresarlo con nmeros, ya conoce algo sobre ello; cuando no pueda medir, cuando no pueda expresar lo que dice con nmeros, su conocimiento es precario y deficiente; puede ser el comienzo del conocimiento, pero en tus pensamientos apenas ests avanzando hacia el escenario de la ciencia. Definiciones

Medida. Proporciona una indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto. Pueden ser directas, p.e. nmero de lneas de cdigo, nmero de errores encontrados, etc., o pueden ser indirectas, p.e. funcionalidad, calidad, complejidad, etc.

Medicin. Acto de determinar una medida. Mtrica. Es una medida cuantitativa del grado en que un sistema o proceso posee un atributo dado. Por lo general relaciona una o ms medidas, p.e. nmero de errores encontrados por cada mil lneas de cdigo.

Indicador. Es una mtrica o combinacin de mtricas que proporcionan una visin del proceso, del proyecto o del software en s, y poder hacer ajustes para que las cosas mejoren.

7.1.1 Mtricas Orientadas Al Tamao. Medidas

Lneas de cdigo (LOC). Esfuerzo en hombre-mes. Costo en pesos o dlares. Nmero de pginas de documentacin. Nmero de errores. Fallas detectadas antes de entregar el software al cliente. Nmero de defectos. Fallas detectadas despus de entregar el software al cliente. Nmero de personas en el proyecto.

Mtricas

Errores por KLOC (mil lneas de cdigo). Defectos por KLOC. Costo por KLOC. Pginas de documentacin por KLOC. Errores por hombre-mes. LOC por hombre-mes. Costo por pgina de documentacin.

Ventajas

Son fciles de calcular. Muchos modelos de estimacin de software usan LOC o KLOC como datos de entrada. Existen un amplio conjunto de datos y literatura basados en LOC.

Desventajas

Son dependientes del lenguaje de programacin. Perjudica a los programas cortos pero bien diseados.

Su uso en estimacin es difcil porque hay que estimar las LOC a producirse mucho antes de que se complete el anlisis y el diseo.

7.1.2 Mtricas Orientadas A La Funcin. La medida de punto de funcin se propuso en 1979 y trata de medir la funcionalidad o utilidad del software. Clculo del punto de funcin 1. Hay que completar la siguiente tabla de valores del dominio de la informacin: Factor de ponderacin Parmetro Cuenta Simple Medio Complejo Nmero de entradas de usuario Nmero de salidas usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces 7 10 15 3 4 6 de 4 5 7 3 4 6 Subtotal

10

Factor de ponderacin Parmetro Cuenta Simple Medio Complejo externas Total 2. donde:
o

Subtotal

Entradas de usuario. Son entradas que proporcionan diferentes datos a la aplicacin. No confundirlos con las peticiones de usuario. Salidas de usuario. Son reportes, pantallas o mensajes de error que proporcionan informacin. Los elementos de un reporte, no se cuentan de forma separada. Peticiones de usuario. Es una entrada interactiva que produce la generacin de alguna respuesta del software en forma de salida interactiva.

Archivos. Son los archivos que pueden ser parte de una base de datos o independientes. Interfaces externas. Son los archivos que se usan para transmitir informacin a otro sistema.

Indicaciones:
o o

Contar cada medida por separado. Asociar, de alguna manera, un valor de complejidad a cada medida. La siguiente tabla muestra una heurstica para decidir la complejidad de todo el sistema. Tipos archivos de Tipos de datos elementales 6-19 20+

referenciados 1-5 0-1

bajo bajo medio

Tipos archivos

de Tipos de datos elementales 6-19 20+

referenciados 1-5 2-3 4+

o

bajo medio alto medio alto alto

Para cada medida, multiplicar su cuenta por el factor de complejidad elegido y escribirlo en la columna de la extrema derecha. Sumar la columna de la extrema derecha y obtener un total T que indica el valor del dominio de la informacin.

3. Responder a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial. 1. Requiere el sistema copias de seguridad y de recuperacin fiables? 2. Requiere comunicacin de datos? 3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? 6. Requiere entrada de datos interactiva? 7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? 8. Se actualizan los archivos maestros de forma interactiva? 9. Son complejas las entradas, las salidas, los archivos o las peticiones? 10. Es complejo el procesamiento interno?

11. 12. 13. 14.

Se ha diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la Se ha diseado el sistema para soportar mltiples Se ha diseado la aplicacin para facilitar los

instalacin? instalaciones en diferentes organizaciones? cambios y para ser fcilmente utilizada por el usuario? Sumar los puntos asignados a cada respuesta y obtener un total F que indica un valor de ajuste de complejidad. El punto de funcin FP se calcula con la siguiente ecuacin: PF = T * (0.65 + 0.01 * F).

Mtricas
o o o o o

Errores por PF. Defectos por PF. Costo por PF. Pgina de documentacin por PF. PF por hombre-mes.

MODULO 8: ESTIMACIN DEL PROYECTO 8.1 Modelos De Estimacin La funcin bsica que utilizan los tres modelos es: E = a (Kl) b * m (X) donde: A y b son constantes con valores definidos en cada submodelo Kl son las lneas de cdigo (en miles) El resultado es en salarios/mes y horas-hombre.

M(X) Es un multiplicador que depende de 15 atributos. En la siguiente tabla se muestran los coeficientes para los diferentes modos 1.2 2.8 1.2 3.6 Empotrado 1.12 3.0 1.12 3.0 Semiencajado 1.05 3.2 1.05 2.4 Orgnico b i a i b i a i Intermedio Bsico Modelo Bsico Este modelo trata de estimar, de una manera rpida y ms o menos burda, la mayora de proyectos pequeos y medianos. Se consideran tres modos de desarrollo en este modelo: orgnico, semiencajado y empotrado. Modo orgnico Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo. El coste es Km = 2.4 Sk1.05 donde Km se expresa en personas-mes y Sk es el tamao expresado en miles de lneas de cdigo fuente. El tiempo de desarrollo se da por td = 2.5 Km0.38 donde Km se obtiene de la ecuacin anterior y td es el tiempo de desarrollo en meses. Estas ecuaciones se han obtenido por medio de ajustes de curvas realizado por Boehm en TRW sobre 63 proyectos. Modo Empotrado. En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con el procesador y el interface hardware. El problema a resolver es nico y es difcil basarse en la experiencia, puesto que puede no haberla. Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgnico, pero con diferentes constantes. As, el coste se da por Km = 3.6 Sk1.20 y el tiempo de desarrollo por Modo Semiencajado. td = 2.5 Km0.32 Es un modo intermedio entre los dos Modo

anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de personas experimentadas y no experimentadas. Las ecuaciones son por td = 2.5 Km0.35. Modelo Intermedio En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisin de la estimacin. Ecuaciones nominales de coste. Para cada modo de desarrollo, los 15 atributos del coste intervienen como multiplicadores en el coste nominal, Kn, para producir el coste ajustado. Las ecuaciones nominales de coste para el modelo intermedio son modo orgnico modo semiencajado modo empotrado Kn = 3.2 Sk1.05 Kn = 3.0 Sk1.12 Kn = 2.8 Sk1.20 Km = 3.0 Sk1.12 y el tiempo de desarrollo

Atributos de coste. Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de desarrollo. De un anlisis estadstico de ms de 100 factores que influencian el coste, Boehm retuvo 15 de ellos para COCOMO. Estos atributos se agrupan en cuatro categoras: atributos del producto, atributos del ordenador, atributos del personal y atributos del proyecto. Atributos del producto RELY: garanta de funcionamiento requerida al software

DATA: tamao de la base de datos CPLX: complejidad del producto

Atributos del ordenador TIME: restriccin de tiempo de ejecucin STOR: restriccin del almacenamiento principal VIRT: volatilidad de la mquina virtual TURN: tiempo de respuesta del ordenador

Atributos del personal ACAP: capacidad del analista AEXP: experiencia en la aplicacin PCAP: capacidad del programador VEXP: experiencia en mquina virtual LEXP: experiencia en lenguaje de programacin

Atributos del proyecto MODP: prcticas de programacin modernas TOOL: utilizacin de herramientas software SCED: plan de desarrollo requerido.

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo, bajo, nominal, alto, muy alto, extremadamente alto. Estos 15 valores se multiplican al Kn, y nos proporciona el esfuerzo ajustado al entorno. Modelo Detallado Presenta principalmente dos mejoras respecto al anterior: Los factores correspondientes a los atributos son

sensibles a la fase sobre la que se realizan las estimaciones, puesto que aspectos tales como la experiencia en la aplicacin, utilizacin de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y adems porque van variando de una etapa a otra. Establece una jerarqua de tres niveles de productos, de forma que los aspectos que representan gran variacin a bajo nivel, se consideran a nivel mdulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema. 8.2 TECNICAS DE DESCOMPOSICIN. Estimacin Basada En El Tamao.

Puede usarse LOC o PF para hacer estimaciones. Si se utiliza LOC, la descomposicin es esencial y a menudo debe ser a detalle. Si se utiliza PF, en vez de centrar la descomposicin en la funcin, se calcula el PF como se estudi en el captulo anterior, estimando de alguna forma, cada uno de los valores.

En ambos casos, mediante datos histricos o la intuicin, se estiman valores optimista (O), medio (M) y pesimista (P) para cada funcin o contador, y se calcula el valor esperado (E) con la siguiente frmula: E = (O + 4 * M + P) / 6

Ejemplo de estimacin basada en LOC. Supongamos que nos piden hacen un sistema que implemente las principales operaciones con matrices, que tenga una interface grfica y un reporteador. El primer paso es analizar el problema y descomponerlo en tareas que sean ms fciles de estimar. Digamos

que despus de un estudio a fondo, nos damos cuenta que necesitamos tres mdulos o tareas especficas:

Interface grfica. Rutinas matemticas para procesar matrices. Reportes

Y digamos que en base a datos histricos, de sistemas que hayamos realizado, obtenemos los siguientes estimados. LOC estimadas. Mdulo Optimista Medio Pesimista Esperado Interface grfica Rutinas matemticas Reportes Total

1,200

1,800 3,000

1,900

3,000

4,200 6,000

4,300

600

1,200 1,800

1,200 7,400

Si en base a los datos histricos sabemos que tenemos una productividad media de 500 LOC/hombre-mes, podemos calcular que el esfuerzo de desarrollar el sistema ser de (7,400 / 500) = 15 hombres-mes (siempre hay que redondear hacia arriba). Y si cada hombre-mes cuesta $10,000 (entre sueldos y gastos extras), entonces el costo del sistema ser de $150,000. Ejemplo de estimacin basada en PF. Si queremos hacer una estimacin del mismo sistema, pero usando ahora PF, en vez de tratar de estimar las LOC que tendr el sistema, tratamos de estimar cada uno de los valores necesarios

para calcular el PF. Digamos que despus del anlisis, llegamos a los siguientes valores: Valores del dominio de informacin Cuenta Peso Subtotal Optimista Medio Pesimista Esperado

Dominio

de

informacin

Nmero entradas Nmero salidas Nmero

de

10

32

de

25

de

peticiones Nmero archivos Nmero externas Total T de de

28

10

10

interfaces

102

Factores Factor Copia de seguridad y Valor

recuperacin

Factor

Valor

Comunicaciones de datos 2 Proceso distribuido Rendimiento crtico Entorno existente operativo 0 4

Entrada de datos en lnea 4 Transacciones de entrada en mltiples pantallas Archivos maestros

actualizados en lnea Complejidad de del dominio informacin Complejidad procesamiento interno Cdigo diseado para ser rehusado Conversin/instalacin en diseo Instalaciones mltiples del valores

de 5

Aplicacin diseada para 5

Factor el cambio Total F

Valor

51

Aplicando la frmula PF = T * (0.65 + 0.01 * F), se obtiene que PF = 118. Si los datos histricos indican que nuestra productividad es de 7 PF / hombre-mes, entonces el esfuerzo requerido ser de (118 / 7) = 17 hombres-mes, y si el costo por hombre-mes es de $10,000, entonces el costo del proyecto ser de $170,000. 8.2.2 BASADO EN EL PROBLEMA. Dicha estimacin puede basarse en:

Datos histricos Experiencia/intuicin

Con estos valores se calcula un valor esperado. VE = (Vo + 4Vm + Vp)/6 Una vez estimado el tamao se aplican los datos histricos de productividad LDC.

8.2.3 BASADO EN EL NMERO DE LNEAS DE (LDC) CDIGO. La mtrica de tamao tradicional para estimar el esfuerzo de desarrollo y productividad ha sido LOC (Lines Of Code) o SLOC (Source Lines Of Code). Se han propuesto varios modelos de estimacin, la mayora de ellos son funciones de las lneas de cdigo o de las miles de lneas de cdigo que tendr el software a

desarrollar. Generalmente, el modelo de estimacin de esfuerzo consiste de dos partes. La primera provee una base de estimacin como una funcin del tamao del software, y es de la siguiente forma: donde E es el esfuerzo estimado en meses hombre, A, B y C son constantes y KLOC es el tamao estimado del sistema final en miles de lneas de cdigo. La segunda parte del modelo modifica esta estimacin en base a cuantificar la influencia de factores de ambiente, por ejemplo la utilizacin de diferentes metodologas, habilidad del equipo de desarrollo y restricciones de hardware. La definicin de KLOC es importante si se quiere comparar los distintos modelos que se han propuesto en la literatura. Algunos de ellos incluyen lneas de comentarios, y otros no. Del mismo modo, la definicin del esfuerzo estimado E es tambin importante., ya que E puede representar slo el esfuerzo de codificacin, o en el otro extremo, el esfuerzo se total del torna anlisis, diseo, codificacin, test y mantencin. Por estas razones, comparar estos modelos complejo.

Los principales problemas de utilizar lneas de cdigo como mtrica para estimacin del esfuerzo son la falta de una definicin universal de lnea de cdigo, su dependencia con el lenguaje de desarrollo y la dificultad de estimar en fases tempranas del desarrollo la cantidad de lneas que tendr una aplicacin. Puntos de funcin

El anlisis por puntos de funcin es un mtodo para cuantificar el tamao y la complejidad de un sistema software en trminos de las funciones de usuario que este desarrolla (o desarrollar). Esto hace que la medida sea independiente del lenguaje o herramienta

utilizada

en

el

desarrollo

del

proyecto

[1].

El anlisis por puntos de funcin est diseado para medir aplicaciones de negocios; no es apropiado para otro tipo de aplicaciones como aplicaciones tcnicas o cientficas. Esas aplicaciones generalmente median con algoritmos complejos que el mtodo de puntos de funcin no est diseado para manejar [5]. El enfoque de puntos de funcin tiene caractersticas que permiten superar los principales problemas de utilizar lneas de cdigo como mtrica del tamao del software. Primero, los puntos de funcin son independientes del lenguaje, herramientas o metodologas utilizadas en la implementacin; por ejemplo, no tienen que considerar lenguajes de programacin, sistemas de administracin de bases de datos, hardware, o cualquier otra tecnologa de procesamiento de datos [4]. Segundo, los puntos de funcin pueden ser estimados a partir de la especificacin de requisitos o especificaciones de diseo, haciendo posible de este modo la estimacin del esfuerzo de desarrollo en etapas tempranas del mismo. Como los puntos de funcin estn ntimamente relacionados con la declaracin de requisitos, cualquier modificacin a sta, puede ser reflejada sin mayor dificultad en una re estimacin.

Tercero, como los puntos de funcin estn basados en una visin externa del usuario del sistema, los usuarios no tcnicos del software poseen un mejor entendimiento de lo que los puntos de funcin estn midiendo. El mtodo resuelve muchas de las inconsistencias que aparecen cuando se utiliza lneas de cdigo como mtrica del tamao del software.

En resumen, los puntos de funcin aparecen con ventajas substanciales por sobre las lneas de cdigo, para fines de

estimacin temprana del tamao del software, y por ende, del esfuerzo de desarrollo. Adems es una medida ampliamente utilizada, y con xito, en muchas organizaciones que desarrollan software Puntos en de forma masiva. Caracterstica.

Debido a que el anlisis por Puntos de Funcin fue diseado para software de negocios y no es fcil de generalizar a aplicaciones cientficas, de tiempo real y otras, Caper Jones [18] propuso ampliaciones a este mtodo, generando una mtrica que denomin Puntos de Caracterstica. sta da cabida a aplicaciones cuya complejidad algortmica es alta. Este mtodo considera los mismos elementos que considera Albrecht [1] en su anlisis por puntos de funcin, slo que aade la variable "nmero de algoritmos" y elimina los niveles de complejidad, as, cada cuenta es pesada por un valor nico para ese componente (es decir, se le asigna complejidad media).

8.2.4 BASADO EN EL PROCESO Mtricas del proceso Indicadores del proceso mejora en el proceso Si la gestin se basa en el personal, problema y proceso, por qu nos centramos en mejorar el proceso? Por qu el proceso es un factor clave y controlable para mejorar la calidad del software y el rendimiento de la organizacin. Mtricas privadas: ndices de defectos. Errores de desarrollo. Pblicas para el equipo: ndices de defectos.

 Errores de desarrollo. LDC. PF. Las mtricas del proceso pueden ser muy tiles, pero hay que saber interpretarlas Unas normas bsicas de interpretacin son - Utilizar el sentido comn al interpretar los datos. - Proporcionar una realimentacin regular a particulares y equipos. - No utilizar mtricas para evaluar a particulares. - Establecer mtricas claras y objetivos para alcanzarlas. No utilizar mtricas para amenazar a particulares o equipos. - Si una mtrica identifica un rea problemtica no se debera considerar como negativa. - Hay que interpretar todas las mtricas en su conjunto, y no primar una en particular. La utilizacin de mtricas e indicadores fiables da lugar a una mejora estadstica del proceso del software Esta mejora se basa en un anlisis de fallos que identifica la causa y origen de errores y defectos para varios proyectos de software - Error: fallo en un producto generado durante el proceso de IS que es detectado antes de la entrega al cliente. - Defecto: fallo detectado despus de la entrega al cliente. El anlisis de fallos funciona: 1. Se categorizan por origen todos los errores y defectos de varios proyectos. 2. Se registra el coste de corregir cada error o defecto. 3. El nmero de errores y de defectos de cada categora se cuentan y se ordenan decrecientemente 4. Se computa el coste global de errores y defectos de cada categora.

5. Los datos resultantes se analizan para detectar las categoras que producen el coste ms alto para la organizacin. 6. Se desarrollan planes para modificar el proceso con el intento de eliminar (o reducir la frecuencia de apariciones de) la clase de errores y defectos que sean ms costosos.