1.

1Introduccin General
Qu es Software? Son los programas que se ejecutan dentro de una computadora de cualquier tamao y arquitectura. Son las instrucciones que al ejecutarse proporcionan caractersticas, funciones y desempeo deseados, mediante estructuras de datos para manipular la informacin y los documentos que describen la operacin y el uso de los programas. Quin lo hace? Los ingenieros de software lo construyen y lo mantienen. Por qu es importante? Porque afecta de forma cercana nuestra vida, en comercios, hogar, industria, etc. Cmo se construye? Mediante la aplicacin de un proceso que conduzca a un resultado de alta calidad que satisfaga las necesidades de la gente que usara el producto. Qu producto? El producto obtenido lo forman los programas, el contenido (datos) y los documentos que constituyen el software, mejorando el mundo del usuario. Qu es un proceso de software? Un conjunto de actividades cuya meta es el desarrollo o evolucin del software. Qu es un modelo de procesos de software? Una representacin simplificada de un proceso de software, presentada desde una perspectiva especifica. Cules son los costos de la ingeniera de software? En general el 60% son de desarrollo y el 40% restante de pruebas, si es software personalizado, los costos de evolucin suelen ser mas que los de desarrollo. Cules son los atributos de un buen software? El software debe tener la funcionalidad y el rendimiento requeridos por el usuario, adems de ser mantenible, confiable y fcil de utilizar En software podemos tener productos: Genricos: son aquellos que se producen por alguna organizacin de desarrollo y que estn enfocados al mercado abierto, como procesador de palabras, bases de datos, paquetes de dibujos, todo para las PCs Personalizados: son los que se hacen a la medida de un cliente especifico, ejemplo para procesos especficos, control de instrumentos, etc.

Cmo ha sido la evolucin del software? A partir de la dcada de los 50 el software se convierte en una tecnologa indispensable en los negocios, la ciencia y la ingeniera, permitiendo la creacin y expansin de nuevas tecnologas: Ingeniera gentica Telecomunicaciones Industria de la impresin Internet Permitiendo el desarrollo de software relacionado con todo tipo de sistemas como: mdicos, transporte, militares, industriales, entrenamiento, mquinas para oficinas, etc., y que se pudieran comprar los productos empaquetados en los centros comerciales. Al mismo tiempo tantos programas necesitaran de corregirse, adaptarse y mejorarse conforme pasa el tiempo, teniendo que absorber mas gente y recursos para lograr estas actividades de mantenimiento. A medida que la importancia del software a crecido, se ha intentado desarrollar tecnologas que hagan ms fcil, ms rpida y menos cara la construccin y el mantenimiento de programas de computadora de alta calidad. Como producto ofrece la potencia del Hardware, sin importar donde resida el software en un celular o dentro de una computadora, siendo este un transformador de informacin, realizando el manejo, la adquisicin, la modificacin, el despliegue o la transmisin de la informacin

Software (papel dual)

En su papel de vehculo para la entrega de un producto, el software acta como la base de control de la computadora, como sistemas operativos, redes, utilera, ambientes. En la actualidad el software se ha convertido en un factor dominante en la economa del mundo industrializado Se ha evolucionado de un programador solitario a especialistas de software para el desarrollo de aplicacines complejas.

Caractersticas del software V.S. Hardware

1. El software se desarrolla o se construye; no se manufactura 2. El software no se desgasta 3. A pesar de que la industria tiene una tendencia hacia la construccin de componentes, la mayora del software aun se construye a la medida.

T a s a d e f a l l a s

Mortalidad infantil

Desgaste

T a s a d e f a l l a s

La tasa de fallas se incrementa debido a los efectos colaterales

Cambio

Curva real

Curva ideal Tiempo

Tiempo

El hardware es alto en fallas al inicio de su vida debido a defectos de manufactura o de diseo, se corrige y la tasa de fallas baja hasta un nivel estable, pero pasa el tiempo y debido al polvo, vibraciones temperaturas, etc. Comienza a desgastarse

El Software sufre cambios durante su vida, por lo que pueden existir errores, que ocasiona que la curva de fallas tenga un pico y antes de regresar a un estado estable puede existir otro cambio provocando un nuevo pico, de esta manera el nivel de fallas comienza a elevarse haciendo que el software se deteriore.

Naturaleza cambiante del software

En la actualidad existen siete categoras del software:

1.Software emportado 2.Software de sistemas 3.Software de lnea de productos 4.Software de aplicacin 5.Software cientfico y de ingeniera 6.Aplicaciones basadas en Web 7.Software de inteligencia artificial

( ) ( ) ( )

Diseado para proporcionar una capacidad especifica y la utilizacin de muchos clientes diferentes (procesadores de palabras, hojas de clculo, multimedia, grficos, manejo de bases de datos, finanzas, recursos humanos, etc. Se caracteriza por algoritmos, abarca desde astronoma, vulcanologa, dinmica orbital, biologa molecular hasta manufactura automotriz. Este software utiliza algoritmos no numricos en la resolucin de problemas complejos donde se pueden abordar por un anlisis directo, incluyen la robtica, sistemas expertos, reconocimiento de patrones (voz, imagen), redes neuronales, comprobacin de teoremas y juegos en computadora. Este software es una coleccin de programas escritos para servir a otros programas como: compiladores, editores, utileras para la administracin de archivos, componentes del sistema operativo ( controladores, software de red, procesadores para telecomunicaciones) Este software se caracteriza por la interaccin intensa con el hardware, mltiples usuarios, comparticin de recursos, estructuras de datos complejas y mltiples interfaces externas. Este software consiste en programas independientes que resuelven una necesidad negocios especifica, procesando mediante aplicaciones datos tcnicos o empresariales que facilitan la operacin del negocio o la toma de decisiones, (SAP, el procesamiento de transacciones en los puntos de venta y control de procesos de manufactura en tiempo real) Diseado dentro de la memoria de solo lectura del sistema y con el se implementan y controlan caractersticas y funciones para el usuarios final, ejemplo teclado del horno de microondas, funciones digitales del auto, etc.

( )
( ) ( ) ( )

Las WebApps engloban un amplio campo de aplicaciones, estas son un poco mas que un conjunto de archivos de hipertexto ligados que presentan informacin mediantes texto y graficas.

Qu es la Ingeniera de software:? La ingeniera de software es una disciplina de la ingeniera que comprende todos los aspectos de la produccin de software, desde las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste despus de que se utiliza. Los ingenieros aplican teoras, mtodos y herramientas tratando de hacer que las cosas funciones, buscando soluciones al problema a pesar de restricciones que pudieran existir, esto es disciplina de la ingeniera. La Ingeniera de software no slo comprende los procesos tcnicos del desarrollo del software sino todos los aspectos de produccin de software como: gestin de proyectos, desarrollo de herramientas, mtodos y teoras de apoyo ara la produccin del software. Cul es la diferencia entre ingeniera de software y ciencia de la computacin? La ciencia de la computacin comprende la teora y los fundamentos y la Ingeniera de software comprende las formas practicas para desarrollar y entregar un software til. Los ingenieros de software requieren ciertos conocimientos de ciencia de la computacin, de la misma forma que los ingenieros electrnicos requieren conocimientos de fsica. Cul es la diferencia entre ingeniera de software e ingeniera de sistemas? La ingeniera de sistemas se refiere a todos los aspectos del desarrollo de sistemas informticos, incluyendo hardware, software, polticas, distribucin de sistemas e ingeniera de procesos, la ingeniera de software es parte de ese procesos. Los ingenieros de sistemas estn involucrados en la especificacin del sistema, definicin de arquitectura, etc., La ingeniera de sistemas es ms antigua que la del software, por ms de 100 aos se han creado sistemas industriales, plantas qumicas, etc. Incrementando el p orcentaje de software en los sistemas. Cules son los mtodos de la ingeniera de software? Enfoques estructurados para el desarrollo de software que incluye modelos de sistemas, notaciones, reglas, sugerencias de diseo y guas de procesos. Qu es CASE (Ingeniera del software asistida por ordenador)? Son sistemas de software que intentan proporcionar ayuda automatizada a las actividades del proceso del software. Los sistemas CASE a menudo se utilizan como apoyo al mtodo. Cules son los retos fundamentales a los que se enfrenta la ingeniera de software? Enfrentarse a la creciente diversidad, las demandas para reducir los tiempos de entrega y el desarrollo de software fiable. Tales como: El desarrollo de software de sistemas y de aplicacin que permita que dispositivos pequeos, computadoras personales, y sistemas de empresas se comuniquen a travs de grandes redes(blackberry que te permite correo electrnico, telefona mvil, SMS, navegacin web), crear aplicaciones para la planeacin de finanzas personales alrededor del mundo, crear fuente abierta.

La ingeniera de software consta de 10 reas:

1. Requerimientos de software 2. Diseo de software 3. Construccin de software 4. Prueba de software 5. Mantenimiento de software 6. Administracin de la configuracin del software 7. Administracin de la ingeniera de software 8. Procesos de la ingeniera de software 9. Herramientas y mtodos de la ingeniera de software 10. Calidad de software

Un proceso de software es un conjunto de actividades y resultados asociados que producen un producto de software. Estas actividades son llevadas a cabo por los ingenieros de software. Existen cuatro actividades fundamentales de procesos: 1. Especificacin del software donde los clientes e ingenieros definen el software a producir y las restricciones de su operacin 2. Desarrollo del software donde el software se disea y se programa 3. Validacin del software donde el software se valida para asegurar que es lo que el cliente quiere 4. Evolucin del software donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado

1.2Ingeniera de sistemas basados en computadoras

Qu es un sistema? Un sistema es una coleccin de componentes interrelacionados que trabajan conjuntamente para cumplir algn objetivo. Qu es la ingeniera de sistemas? Es una disciplina que identifica, analiza, especifica, modela, valida y gestiona los requisitos operacionales de un sistema, donde intervienen personas, hardware, software, bases de datos, procedimientos, etc. Los sistemas que incluyen software pueden ser: Tcnico-informtico: son sistemas que incluyen componentes hardware y software, pero no procedimientos y procesos, ejemplo, televisiones, telfonos mviles, software de computadoras personales. Socio-tcnico: comprende uno o ms sistemas tcnicos, incluyendo el conocimiento de cmo debe usarse el sistema para alcanzar un objetivo ms amplio. Sistemas basados en computadoras: es un conjunto o una disposicin de elementos que estn organizados para cumplir una meta predefinida al procesar informacin. Es posible que la meta sea apoyar una funcin del negocio o desarrollar un producto que pueda venderse para generar beneficios. Para cumplir la meta, un sistema basado en computadora emplea varios elementos del sistema:
Bases de Datos. Una extensa y organizada recopilacin de informacin a la cual se tiene acceso a travs de software y que persiste a travs del tiempo.

Software: programas de computadora, estructuras de datos y documentacin que sirven para hacer efectivo el mtodo

Personas: Usuarios hardware y software

operadores

del

Hardware: Dispositivos electrnicos que proporcionan capacidad de clculo, dispositivos de interconexin, conmutadores de red, dispositivos de telecomunicacin.

Documentacin: informacin descriptiva, ejemplo modelos, manuales, especificaciones, archivos de ayuda en lnea, sitios Web, que detallan el uso y operacin del sistema.

Procedimientos: Los pasos que definen el uso especifico de cada elemento del sistema o el contexto de procedimiento en que reside el sistema.

Una caracterstica complicada de los sistemas basados en computadora es que tal vez constituye un macroelemento de un sistema aun mayor. El macroelemento es un sistema basado en computadora que es parte de un sistema mayor basado tambin en computadora.

La Jerarqua de la ingeniera de sistemas:

Dominio de inters VG= {D1,D2,D3, ,Dn}

Cada elemento se implementa al especificar los componentes Ej={C1,C2,C3,Ck}

Elemento del sistema Di={E1,E2,E3,,Em}

El proceso de la ingeniera de sistemas comienza con una visin global examinando el dominio entero del negocio o producto para asegurarse de que se puede establecer el contexto tecnolgico o de negocio apropiado. La visin global es refinada para enfocarse totalmente a un dominio especfico de interes, analizando la necesidad de elementos del sistema como: informacin, software, hardware, personas, etc., al final se inicia l anlisis, diseo y la construccin del elemento del sistema deseado. En la parte alta de la jerarqua se establece un contexto amplio y en la parte baja se conduce actividades detalladas, realizadas por la disciplina de ingeniera correspondiente(ingeniera de software o hardware)

Procesos de la ingeniera de sistemas

Las definiciones de requerimientos del sistema especifican que es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables El diseo del sistema es proporcionar la funcionalidad del sistema a travs de sus diferentes componentes, las actividades que deben realizarse en este proceso son: El desmantelamiento del sistema significa poner fuera de servicio a dicho sistema despus de que termina su periodo de utilidad operativa, sea hardware o software.

Durante el desarrollo de los subsistemas, se implementan los que se hayan identificado durante el diseo del sistema, esto significa comenzar otro proceso de la ingeniera de sistemas para los subsistemas individuales, o, si el subsistema es software, un proceso de software que comprende requerimientos, diseo, implementacin y pruebas. Ocasionalmente, todos los subsistemas son desarrollados, normalmente son comerciales (COTS), los cuales pueden integrarse en el sistema.

Los sistemas grandes y complejos tienen un periodo largo de vida, en el cual se cambian para corregir errores en los requerimientos del sistema original y para implementar nuevos requerimientos que van surgiendo, al igual que los equipos de computo, etc.

Durante el proceso de integracin del sistema, se toman los subsistemas desarrollados de forma independiente y se conjuntan para crear el sistema completo.

Modelado del sistema

Durante la actividad de requerimientos y diseo del sistema, estos pueden ser modelados como un conjunto de componentes y de relacin entre esos componentes, sin importar que el enfoque est en la visin global o en la visin detallada. El ingeniero crea modelos que:
Definen los procesos que satisfacen las necesidades de la visin que se considera Representa el comportamiento de los procesos y los supuestos en los que se basa el comportamiento Definen las entradas exgenas y endgenas de informacin Representan todas las uniones, incluidas las salidas que permitan al ingeniero entender mejor la visin. Al construir un modelo del sistema el ingeniero debe considerar algunas restricciones: 1. Supuestos sobre lo que debe ser real (representacin tridimensional , supuestos de movimientos) 2. Simplificaciones (entradas de orden pedidos cerveza, internas, externas) 3. Limitaciones(limitaciones de cantidades de cerveza) 4. Restricciones(infraestructura tecnolgica) 5. Preferencias(arquitectura preferida para todos los datos funcionales y tecnolgica ejemplo BDD)

Debido a que un sistema puede representarse con diferentes grados de visin, los modelos de sistemas tienden a ser jerrquicos o estratificados.

Modelado Hatley-Pirbhai: representa la entrada, el procesamiento y la salida junto con la. interfaz del usuario y el mantenimiento/autocomprobacin (no estn presentes en sistemas basados en computadora, pero son comunes) Para desarrollar el modelo de sistema, se emplea un esquema del modelado del sistema. El ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del esquema: (1) interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4) salida y (5) mantenimiento y autocomprobacin.

En el nivel ms alto de la jerarqua esta el diagrama de contexto del sistema(DCS), los subsistemas principales se definen con un diagrama de flujo del sistema (DFS)que se obtiene del (DCS).

Modelado del sistema con UML

El UML (Unified Modeling Language) proporciona una gran variedad de diagramas que pueden utilizarse para el anlisis y diseo a nivel de software y de sistema. En el nivel de sistema el hardware se puede modelar mediante un diagrama de despliegue de UML. Cada caja muestra un elemento del hardware que forma parte de la arquitectura fsica del sistema.

Diagrama de despliegue del hardware

UML ofrece varias formas de modelar los elementos de software. Los aspectos de procedimiento se pueden representar por medio de un diagrama de actividad. Esta notacin es similar al diagrama de flujo y sirve para representar lo que sucede mientras el sistema realiza sus funciones.

Otra notacin UML que puede utilizarse para modelar el software es el diagrama de clase. En el nivel de ingeniera del sistema las clases se extraen en un enunciado del problema. Cada clase encapsula un conjunto de atributos que representa toda la informacin necesaria acerca de la clase.

Para representar la forma en que los actores interactan con el sistema pueden utilizarse los casos de uso En stos, cada valo etiquetado dentro de la caja implica un caso de uso, un escenario escrito que describe una interaccin con el sistema.

Simulacin del sistema Muchos sistemas basados en computadora interactan con el mundo real de forma reactiva. Es decir, el hardware y el software que componen el sistema monitorean los acontecimientos del mundo real, y basndose en ellos, el sistema aplica su control sobre las mquinas, procesos e incluso las personas que generar los sucesos. Ejemplos de sistemas reactivos son los sistemas de tiempo real y sistemas empotrados. Si estos sistemas fallan, podran ocurrir prdidas econmicas o humanas significativas. Por este motivo, se utilizan herramientas software para el modelado y simulacin de sistemas para ayudar a eliminar sorpresas cuando se construyen sistemas reactivos basados en computadora. Estas herramientas se aplican durante el proceso de ingeniera de sistemas, mientras se estn especificando las necesidades del hardware, software, bases de datos y de personas. Las herramientas de modelado y simulacin capacitan al ingeniero de sistemas para probar una especificacin del sistema. INGENIERA DE PROCESO DE NEGOCIO: UNA VISIN GENERAL El objetivo de la ingeniera de proceso de negocio (IPN) es definir arquitecturas que permitan a las empresas emplear la informacin eficazmente. Se deben analizar y disear tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocio: arquitectura de datos arquitectura de aplicaciones infraestructura de la tecnologa La arquitectura de datos proporciona una estructura para las necesidades de informacin de un negocio o de una funcin de negocio. Una vez definido el conjunto de datos, se identifican sus relaciones. Una relacin indica como los objetos estn conectados. Los objetos de datos fluyen entre las funciones de negocio, estn organizados dentro de una base de datos y se transforman para proveer informacin que sirva a las necesidades del negocio. La arquitectura de aplicacin comprende aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algn propsito del negocio. La arquitectura de aplicacin puede incorporar el papel de las personas (transformadores y usuarios de informacin) y procedimientos de negocios que no han sido automatizados. La infraestructura tecnolgica proporciona el fundamento de las arquitecturas de datos y de aplicaciones. La infraestructura comprende el hardware y el software empleados para dar soporte a las aplicaciones y datos. Esto incluye computadoras y redes de computadora, enlaces de telecomunicaciones, tecnologas de almacenamiento y la arquitectura (por ejemplo, cliente/servidor) diseada para implementar estas tecnologas.

La jerarqua de la ingeniera del proceso del negocio.

INGENIERA DE PRODUCTO : UNA VISIN GENERAL La meta de la ingeniera de producto es traducir el deseo de un cliente, de un conjunto de capacidades definidas, a un producto operativo. Para conseguir esta meta, la ingeniera de producto debe crear una arquitectura y una estructura. La arquitectura comprende cuatro componentes de sistema distintos: software, hardware, datos (bases de datos) y personas. Se establece una infraestructura de soporte e incluye la tecnologa requerida para unir los componentes y la informacin (por ejemplo, documentos, CD-ROM, vdeo) que se emplea para dar soporte a los componentes. La visin global se consigue a travs de la ingeniera de requisitos. Los requisitos generales del producto se obtienen del cliente. Estos requisitos comprenden necesidades de informacin y control, funcionalidad del producto y comportamiento, rendimiento general del producto, diseo, restricciones de la interfaz y otras necesidades especiales. Una vez que se conocen estos requisitos, la misin del anlisis del sistema es asignar funcionalidad y comportamiento a cada uno de los cuatro componentes mencionados anteriormente. Una vez que se ha hecho la asignacin, comienza la ingeniera de componentes del sistema. sta consiste en un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de los componentes del sistema: la ingeniera del software, ingeniera de hardware, ingeniera humana e ingeniera de bases de datos. Cada una de estas disciplinas de ingeniera toma una vista de dominio especfica, pero deben establecer y mantener una comunicacin activa entre ellas.

La jerarqua de la ingeniera de productos

1.3El contexto de la Ingeniera de software, inicio, presente y futuro.

Inicio: A partir de la dcada de 1950 el software comienza hacer una tecnologa indispensable para diferentes actividades y organizaciones y a medida que la importancia del software ha crecido se ha intentado desarrollar tecnologas que hagan ms fcil, ms rpida y menos costosa la construccin y el mantenimiento de programas de computadora de alta calidad. La nocin de ingeniera del software fue propuesta inicialmente en 1968 en una conferencia para discutir la crisis del software y nace como disciplina de la ingeniera alrededor de 1970 como respuesta a la crisis que en ese momento atravesaba el software, esto debido al incremento en magnitud y complejidad, as como el hecho de que los programas no eran entregados en tiempo ni forma, convirtindose el software en costoso ms aun que el hardware, as como difciles de mantener y con un desempeo pobre.

Por todo lo anterior se necesitaba urgentemente de tcnicas y mtodos para controlar la complejidad de los sistemas grandes, la ingeniera de software es el resultado de esa bsqueda que incluye un proceso, un conjunto de mtodos y una serie de herramientas para la concepcin del software y que en la actualidad son ampliamente utilizadas, sin embargo cuanto ms crezca la capacidad de producir software, tambin la complejidad de los sistemas solicitados.
Es cierto que a partir de 1968 se ha dado pasos importantes al desarrollo del software gracias a la ingeniera de software, debido a que comprendemos mejor las actividades involucradas en este proceso, se han desarrollado mtodos efectivos de especificacin, diseo e implementacin del software, as como el concepto de calidad y de estndares que nos ayudan a lograrla. El inicio de la Ingeniera del software a sido un paso agigantado para todos los desarrolladores que parten ahora de una base y fundamentos aunque existan diversidad de sistemas grandes y complejos.

Presente: Actualmente tenemos cientos de miles de programas de computadoras que pertenecen a una de las siete categoras del software, algunos de estos son de vanguardia pero otros son muy muy viejos. Estos programas viejos son denominados como software heredado, siendo un foco rojo desde 1960 hasta hoy en da, debido a que fueron desarrollado hace dcadas y han sido modificados en forma continua para cumplir con los requerimientos del negocio y de las plataformas de computo, siendo un dolor de cabeza para las organizaciones debido al costoso mantenimiento y riesgo en su evolucin. Los sistemas heredados soportan las funciones centrales del negocio y son indispensables para la empresa, siendo entonces sus caractersticas la longevidad y el ser critico para el negocio. Puntos de la calidad del software heredado: Diseos imposibles de extender Cdigo complicado Documentacin escasa o inexistente Casos de prueba y resultados no archivados Un historial de cambios pobre tc Porqu pueden evolucionar? El software debe adaptarse para satisfacer las necesidades de los nuevos ambientes y tecnologas El software debe mejorarse para implementar los nuevos requerimientos del negocio El software debe extenderse para hacerlo operable con sistemas y bases de datos ms modernos El software debe redisearse para hacerlo ms viable dentro de un ambiente de red

Futuro: La Ingeniera de software tiene para el futuro grandes retos: La heterogeneidad: Cada vez ms se requiere operacin de sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes sistemas de soporte, as como la integracin de software nuevo con sistemas heredados y con diferentes lenguajes de programacin, de ah que el reto sea desarrollar tcnicas para construir software confiables y flexible para adecuarse a la heterogeneidad. La entrega: La ingeniera de software tiene muchas tcnicas que consumen demasiado tiempo para producir software de calidad, sin embargo hoy en da los negocios tienen una capacidad de respuesta y de cambio mucho ms rpida, por lo que el software tambin debe cambiar con esa rapidez, de ah que el reto sea reducir los tiempos de entrega para sistemas grandes y complejos sin poner en riesgo la calidad del sistema La confianza: Es indispensable que podamos confiar en el software ya que es parte de alguna actividad de nuestra vida, por ejemplo en sistemas remotos, acceso a pginas Web, interfaces o servicios Web, el reto entonces ser desarrollar tcnicas que demuestren que los usuarios pueden confiar en el software. La Construccin de cdigo descriptivo: Esto para que los clientes puedan hacer modificaciones locales, as como se desarrollar tcnicas que permitan tanto a los clientes como diseadores conocer los cambios realizados y la forma en que se manifiesta dentro del software. Responsabilidad Profesional y tica: Los ingenieros de software deben comprender las responsabilidades que lleva la concepcin del software, comportndose de una forma tica y moral si desean ser respetados como profesionales. Deben ser honestos e ntegros utilizando sus capacidades y habilidades para honrar la profesin que tienen. Debern cumplir con algunas que la propia ley y polticas de las organizaciones tales como: Confidencialidad Competencia Derechos de propiedad intelectual Uso inapropiado de computadoras Las sociedades e instituciones profesionales como ACM el IEEE (Instituto de Ingenieros Elctricos y Electrnicos) y la British Computer Society publican un cdigo de conducta profesional o de tica, el cual los miembros de estas organizaciones se comprometen a cumplir.

1.4Procesos de software

Qu es un Procesos de Software? Es un conjunto de actividades y resultados asociados que producen un producto de software, estas actividades son llevadas a cabo por los ingenieros de software. Por qu es importante? Porque nos ayuda a tener estabilidad, control y organizacin a una actividad que puede volverse catica. Cul es el producto obtenido? Desde el punto de vista del ingeniero de software los productos obtenidos son los programas, documentos, datos que se producen como consecuencia de esas actividades y tareas definidas en el proceso. La ingeniera de software consta de 10 reas: 1. Requerimientos de software 2. Diseo de software 3. Construccin de software 4. Prueba de software 5. Mantenimiento de software 6. Administracin de la configuracin del software 7. Administracin de la ingeniera de software 8. Procesos de la ingeniera de software 9. Herramientas y mtodos de la ingeniera de software 10. Calidad de software Actividades del proceso de software: 1. Especificacin del software 2. Desarrollo del software 3. Validacin del software 4. Evolucin del software

La ingeniera de software es una tecnologa estratificada

Herramientas Mtodos Proceso Un enfoque de calidad

La gestin de la calidad total, 6 sigma (99.99 % libre de defectos) y enfoques similares fomentan una cultura de mejora continua del proceso siendo esta la base que soporta a la ingeniera de software.
El proceso es el elemento que permite el desarrollo racional y a tiempo del software de computadora, por lo que es la base principal de la de la ingeniera de software, este define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnologa de la ingeniera de software, adems forma la base para el control de la gestin de proyectos, establece el contexto en el cual se aplican los mtodos tcnicos, se generan los productos del trabajo como: modelo, documentos, datos, reportes, formatos, etc., , por lo que el proceso es el elemento que mantiene juntos a todos los estratos. Los mtodos proporcionan los como tcnicos para construir software, estos se basan en principios bsicos para cada rea que incluye actividades de modelado y otras tcnicas descriptivas. Las herramientas proporcionan el soporte automatizado o semiautomatizado para el proceso y mtodos.

Un marco de trabajo de trabajo establece la base para un proceso de software completo, al identificar un nmero pequeo de actividades del marco de trabajo, aplicables a todos los proyectos de software, sin importar su tamao o complejidad , tambin abarca un conjunto de actividades sombrilla (estas ocurren a lo largo del proceso y se enfocan en la gestin, rastreo y control del proyecto)aplicables a lo largo del proceso del software. Proceso del software

Marco de trabajo del proceso

Actividades sombrillas
Comunicacin Planeacin Modelado Construccin Despliegue

Especificacin del software Desarrollo del software Validacin del software Evolucin del software

Para llevar a cabo esas actividades del marco de trabajo es importante: Seguimiento y control del proyecto de software Gestin del riesgo Aseguramiento de la calidad del software Revisiones tcnicas formales Medicin Gestin de la configuracin del software Gestin de la reutilizacin, preparacin y produccin del producto de trabajo

Actividades del marco de trabajo #1 Accin de la ingeniera de software#1.1 Conjunto de tareas . . . Accin de la ingeniera de software #1.k Conjunto de tareas . . . Actividades del marco de trabajo #n Accin de la ingeniera de software#n.1 Conjunto de tareas . . . Accin de la ingeniera de software #n.m Conjunto de tareas . . .

Un conjunto de tareas define el trabajo real que debe realizarse para cumplir los objetivos de una accin de la ingeniera del software, por ejemplo en requerimientos del software que ocurre durante la actividad de comunicacin o especificacin del software se podran hacer ciertas tareas como: hacer lista de clientes Hacer una junta con ellos Pedir una lista de funciones, y as sucesivamente.

La aplicacin de cualquier modelo de proceso del software debe reconocer que la adaptacin al problema, proyecto, equipo y cultura organizacional, es esencial para el xito de esta actividad. Los modelos de proceso pueden diferir en: El flujo de actividades y tareas El grado en el cual las tareas de trabajo estn definidas dentro de cada actividad del marco de trabajo La forma en que se aplican las actividades de seguimiento y control La forma en que se aplican las actividades de aseguramiento de calidad El detalle que describe el proceso El compromiso de los clientes Autonoma del equipo del proyecto La organizacin y responsabilidades Los modelos del proceso que enfatizan la definicin, la identificacin y la aplicacin detallada de las actividades del proceso han sido aplicados durante 30 aos. El Instituto de ingeniera del software (SEI) ha desarrollado un modelo completo de un amplio proceso basado en un conjunto de capacidades de software y de sistemas que deben estar presentes conforme las organizaciones alcanzan diferentes grados de capacidad y madurez del proceso. El SEI sostiene que para lograr estas capacidades una organizacin debe crear un modelo de proceso que se ajuste a las directrices establecidas por la integracin del modelo de capacidad de madurez (IMCM)

MODELO DE CAPACIDAD DE MADUREZ (IMCM) Nivel 0: Incompleto. El rea del proceso (por ejemplo, la gestin de requisitos) an no se realiza o todava no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad. Nivel 1: Realizado. Todas las metas especficas de rea del proceso (como las defini la IMCM) han sido satisfechas. Las tareas de trabajo requeridas para producir el producto especfico han sido realizadas. Nivel 2: Administrado. Todos los criterios del nivel 1 han sido satisfechos. Adems, todo el trabajo asociado con el rea de proceso se ajusta a una poltica organizacional definida; toda la gente que ejecuta el trabajo tiene acceso a recurso adecuados para realizar su labor; los clientes estn implicados de manera activa en el rea de proceso, cuando esto se requiere; todas las tareas de trabajo y productos estn monitoreadas, controlados y revisados; y son evaluados en apego a la descripcin del proceso Nivel 3: Definido. Todos loa criterios del nivel 2 se han cumplido. Adems, el proceso esta adaptado al conjunto de procesos de estndar de la organizacin, de acuerdo con las polticas de adaptacin de esta misma, y contribuye a la informacin de los productos del trabajo, mediciones y otras mejoras del proceso para los activos del proceso organizacional. Nivel 4: Administrativo en forma cuantitativa. Todos los criterios del nivel 3 han sido cumplidos. Adems, el rea del proceso se controla y mejora mediante mediciones y evaluacin cuantitativa. Los objetivos cuantitativos para la calidad y el desempeo del proceso estn establecidos y se utilizan como un criterio para administrar el proceso. Nivel 5: Mejorado. Todos loa criterios del nivel 4 han sido satisfechos. Adems, el rea del proceso se adapta y mejora mediante el uso de medios cuantitativos (estadsticos) para conocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del rea del proceso que se est considerando.

Un modelo de proceso del software es una descripcin simplificada de un proceso del software que presenta una visin de eses proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniera de software, algunos de estos tipos de modelos que se pueden producir son: Modelo de flujo de trabajo: Muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y dependencias, las actividades en este modelo representan acciones humanas. Modelo de flujo de datos o de actividad: Representa el proceso un conjunto de actividades, cada una de las cuales realiza alguna transformacin en los datos. Tiene como entrada al proceso una especificacin y la transforma en un salida como diseo. Estas transformaciones pueden ser por personas o por computadoras. Modelo de rollaccin: Representa los roles de las personas involucradas en el proceso de software y las actividades de las que son responsables. La mayor parte de los modelos de procesos del software se basan en uno de los tres modelos generales o paradigmas de desarrollo de software: Enfoque cascada: considera las actividades anteriores y las representa como fases de procesos separados, como requerimientos, diseo, implementacin, etc., despus de que cada etapa queda definida, se sigue con el desarrollo de la siguiente etapa. Desarrollo iterativo (evolutivo): Este enfoque entrelaza las actividades de especificacin, desarrollo y validacin. Un sistema inicial se desarrolla rpidamente a partir de especificaciones abstractas y va refinndose de acuerdo a los que el cliente necesita. Ingeniera de software basada en componentes (CBSE) esta tcnica supone que las partes del sistema existen. El proceso de desarrollo del sistema se enfoca en la integracin de estas partes ms que desarrollarlas desde el principio. Estos son los nicos modelos? Se han propuesto todo tipo de variantes de estos procesos genricos y pueden ser usados en algunas organizaciones. La variante ms importante es probablemente el desarrollo formal de sistemas, donde se crea un modelo formal matemtico de un sistema. Este modelo se transforma entonces, usando transformaciones matemticas que preservan su consistencia, en cdigo ejecutable. El ejemplo mas conocido de un proceso de desarrollo formal es el de sala limpia, desarrollado por IBM, en este cada incremento del software se especifica formalmente y esta especificacin se transforma en una implementacin . Las correcciones del software se demuestran utilizando un enfoque formal, no hay pruebas para defectos en el proceso, y las pruebas del sistema se centran en evaluar su fiabilidad.

El modelo cascada:
Los servicios y restricciones y metas se definen a partir de las consultas con el usuario, definindose en detalle y sirve como especificacin del sistema

Definicin de Requerimientos

En este se divide los requerimientos en hardware o software y se establece una arquitectura completa del sistema, el diseo de software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

Diseo del Software y del Sistema

Durante esta etapa el diseo del software se lleva a cabo como un conjunto o unidades de programas, las prueba de unidades implica verificar que cumpla cada una sus especificacin. Aqu los programas o las unidades individuales de programas se integran y prueben como un sistema completo para asegurar que se cumplan los requerimientos del software, despus de estas pruebas el sistema se entrega al cliente.

Implementacin y Prueba de unidades

Integracin y Prueba del Sistema

Funcionamiento y Mantenimiento
Por lo general esta es la fase mas larga del ciclo de vida, el sistema se instalas y se pone en funcionamiento, el mantenimiento implica corregir errores no descubiertos en las etapas anteriores, as como mejorar la implementacin de las unidades del sistema y resaltar los servicios del sistema una vez que se descubre nuevos requerimientos.

Ventajas del modelo en cascada:

Hace el proceso de desarrollo mas estructurado. Expresa la interaccin entre las fases subsecuentes. Su sencillez ya que sigue los pasos intuitivos necesarios para la hora de desarrollar el software, la documentacin se produce en cada fase Es bajo el riesgo para desarrollos bien comprendidos y tecnologa conocida.
Desventajas:

Es muy raro que proyectos reales sigan el flujo secuencial que propone el modelo Con frecuencia es difcil que el cliente establezca todos los requisitos de manera explicita El cliente debe de tener paciencia, una versin que funcione de los programas estar disponible cuando el proyecto este muy avanzado. Tiene alto riego para sistemas nuevos, debido a problemas en las especificaciones y diseo. El modelo original es estrictamente secuencial. Esto significa que cada fase debe terminar para que la siguiente pueda comenzar. El punto crtico es que una fase no ha terminado hasta que la documentacin y/o otros productos asociados con esa fase hayan sido completados. Por lo tanto dos fases no se pueden empalmar en el tiempo. No establece retroalimentacin entre fases, ni redefinicin de fases anteriores.

El modelo evolutivo Se basa en desarrollar una implementacin inicial, exponindola a los comentarios del usuario y refinndola a travs de las diferentes versiones hasta que se desarrolla el sistema adecuado. Existen dos tipos de desarrollo evolutivo: El exploratorio: donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final, el desarrollo empieza con las partes del sistema que se comprenden mejor y evoluciona agregando nuevos atributos propuestos por el cliente Prototipos desechables: donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definicin mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Actividades Concurrentes
Versin Inicial

Especificacin

Descripcin del sistema

Desarrollo

Versiones Intermedias

Validacin

Versin Final

Ventajas del modelo evolutivo: Es aplicable a sistemas interactivos pequeos o medianos, as como en partes de sistemas grandes como en la interfaz de usuario y para sistemas de corta vida. (Lotus notes- National, cartera de clientes, cuentas por pagar, etc.) En la produccin de sistemas un enfoque evolutivo suele ser mas efectivo que el enfoque cascada ya que satisface las necesidades inmediatas del cliente. Es que la especificacin se puede desarrollar de forma creciente y tan pronto los usuarios tengan mejor entendimiento de su problema este se puede reflejar en el sistema de software Desventajas: Poca visibilidad en el proceso, es decir que los administradores tienen que hacer entregas regulares para medir el progreso. Los sistemas estn pobremente especificados, tienen una estructura deficiente, por lo que los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en el sistema es una tarea difcil y costosa. Se requiere habilidades especiales.

La ingeniera de software basada en componentes En la mayora de los proyectos de software existe reutilizacin de software, en este enfoque se basa la ingeniera de software basada en componentes(CBSE). Este enfoque basado en la reutilizacin se compone de una gran base de componentes software reutilizables y de algunos marcos de trabajo de integracin para stos. Algunas veces los componentes son sistemas por s mismos (COTS o sistemas comerciales) que se pueden utilizar para proporcionar una funcionalidad especifica, como dar formato al texto o efectuar clculos numricos.
Se buscan los componentes para implementar la especificacin En esta etapa los requerimientos se analizan utilizando informacin acerca de los componentes descubiertos, entonces esos componentes se modifican para reflejar los componentes disponibles, pero si las modificaciones no son posibles, la actividad de anlisis de componentes se puede llevar acabo nuevamente para buscar soluciones alternativas. En esta fase se disea o reutiliza un marco de trabajo para el sistema, los diseadores tienen en cuenta los componentes que se reutilizan y organizan el marco de trabajo para que los satisfaga, si no estn disponibles los componentes reutilizables, tendr que disear un nuevo software.

Para crear el sistema, el software que no se puede adquirir se desarrolla externamente y los componentes y los sistemas COTS se integran. En este modelo, la integracin de sistemas es parte del proceso de desarrollo, ms que una actividad separada

Ventajas de la ingeniera basada en componentes: La reutilizacin del software, reduciendo la cantidad de software a desarrollarse y as reducir costos y riesgos. Por lo general permite una entrega ms rpida del software. Desventajas: Los compromisos en los requerimientos son inevitables y esto puede dar lugar a un sistema que no cumpla las necesidades reales de los usuarios Si las nuevas versiones de los componentes reutilizables no estn bajo el control de la organizacin que los utiliza, se pierde el control sobre la evolucin del sistema. La CBSE tiene mucho en comn con el enfoque que esta surgiendo para el desarrollo de sistemas que se basa a integracin de servicios Web de ciertos proveedores.

Iteracin de los procesos. Los cambios son inevitables en todos los proyectos, los requerimientos pueden cambiar cuando el negocio lo hace por exigencias del mercado, as que las prioridades cambian, o cuando se crean nuevas tecnologas cambian los diseos y la implementacin, esto significa que el proceso del software se repite de acuerdo a las peticiones de cambio. El desarrollo iterativo se puede realizar a partir de dos modelos:

1. Entrega incremental: La especificacin, el diseo y la implementacin del software se dividen en una serie de incrementos, los cuales se desarrollan por turno 2. Desarrollo en espiral: El desarrollo del sistema gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con el desarrollo final del mismo.
Desventaja: Que la especificacin se desarrolla junto con el software, creando conflictos cuando dicha especificacin es parte del contrato del mismo.

Entrega incremental El modelo en cascada requiere que los clientes de un sistema cumplan con requerimientos antes del diseo y el diseador cumpla con estrategias antes de la implementacin, por lo que los cambios significan rehacer el trabajo de todo. En contraste el modelo evolutivo permite el rastreo de los requerimientos y diseo pero origina un software dbil y difcil de entender. La entrega incremental es un enfoque intermedio que combina las ventajas de estos modelos.

En este modelo los clientes identifican rasgos y servicios que proporcionara el sistema, definiendo entonces la importancia de estos para definirlos en varios incrementos, donde cada uno proporciona una parte de la funcionalidad del sistema.

Ventajas: Los clientes no tienen que esperar hasta que el sistema este completo para sacra provecho de l, siendo que el primer incremento satisface los requerimientos ms crticos de forma que pueda el software utilizarse inmediatamente. Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los requerimeintos de los incrementos posteriores. Existe bajo riesgo en un fallo total del proyecto Puesto que los servicios de alta prioridad se entregan primero, puede que sea a los que se les haga ms pruebas, esto significa que hay menor probabilidad de fallas en el funcionamiento del software. Desventajas: Los incrementos deben ser pequeos (no ms de 20000lneas de cdigo) y debe entregar una funcionalidad del sistema. Puede ser difcil la adaptacin de los requerimientos del cliente a incrementos de tamao apropiado. Debido a que los requerimientos se definen a detalle hasta que un incremento se implementa, puede ser difcil identificar los recursos comunes para diferentes partes del sistema.

Modelo en espiral (Boehm, 1988) En este modelo cada ciclo en espiral representa una fase del proceso de software. Cada ciclo de la espiral se divide en cuatro sectores:

En esta fase se definen objetivos, identifican restricciones y riesgos por lo que se traza un plan detallado de gestin y se plantean estrategias.

Se lleva a cabo un anlisis detallado para cada riesgo del proyecto identificado y se definen pasos para reducir esos riesgos.

En esta etapa el proyecto se revisa y se toma la decisin de si se debe continuar con el ciclo posterior de la espiral,

Despus de la evaluacin de riesgos, se elige un modelo para desarrollar el sistema, por ejemplo para la interfaz de usuario se puede utilizar la construccin de prototipos evolutivos., si los riesgos de seguridad son los principales convendra un modelo formal como el de sala limpia, o cascada cuando el riesgo es la integracin de subsistemas, y as sucesivamente.

Ventajas: Centra su atencin en la reutilizacin de componentes y eliminacin de errores en informacin descubierta en fases iniciales. Los objetivos de calidad son el primer objetivo. Integra desarrollo con mantenimiento. Provee un marco de desarrollo de hardware/software. Desventajas: El desarrollo contractual especifica el modelo del proceso y los resultados a entregar por adelantado. Requiere de experiencia en la identificacin de riesgos. Requiere refinamiento para uso generalizado.

Costos generalmente 60% desarrollo y 40% Pruebas

Actividades del proceso: Especificacin del software : Es el proceso de comprensin y definicin de los servicios que requiere el sistema y de identificacin de las restricciones de funcionamiento y desarrollo del mismo. Es aqu donde la ingeniera de requerimientos lleva acabo las siguientes actividades en el proceso de requerimientos.
Se estima si las necesidades del usuario se pueden satisfacer con tecnologas actuales y si ser rentable para el negocio, teniendo como resultado si se debe continuar o no con un anlisis ms detallado. Es el proceso donde a partir de la observacin, entrevistas, discusin, anlisis de tareas de los usuarios y proveedores s e obtienen los requerimientos del sistema Es la actividad donde se realiza el documento que define los requerimientos tanto del usuario como del sistema, detallando su funcionalidad.

Aqu se comprueba la veracidad, consistencia y completitud de los requerimientos.

El anlisis de requerimientos continua durante la definicin, especificacin y a lo largo del proceso surge nuevos requerimientos, por lo tanto, las actividades de anlisis, definicin y especificacin se entrelazan.

Diseo e implementacin del software: En esta etapa se convierte una especificacin del sistema en un sistema ejecutable, siempre implica los procesos del diseo y programacin de software, pero si se utiliza un enfoque evolutivo de desarrollo, tambin puede implicar un refinamiento de la especificacin del software. Un diseo de software es una descripcin de la estructura del software que se va a implementar, los datos que son parte del sistema, las interfaces entre los componentes del sistema y algunas veces los algoritmos utilizados, los diseadores no llegan a un diseo detallado, trabajan a travs de varias versiones.

1. Diseo arquitectnico: los subsistemas que forman el sistema y sus relaciones se identifican y documentan 2. Especificacin abstracta: para cada subsistema se produce una especificacin abstracta de sus servicios y las restricciones bajo las cuales debe funcionar 3. Diseo de la interfaz: para cada subsistema se disea y documenta la interfaz con otros subsistemas 4. Diseo de componentes: se asignan servicios a los componentes y se disea sus interfaces 5. Diseo de la estructura de datos: se disea el detalle y especifica la estructura de datos utilizada en la implementacin del sistema 6. Diseo de algoritmos: se disean en detalle y especifican los algoritmos utilizados para proporcionar los servicios

Sin embargo en la realidad este modelo del proceso de diseo puede ser adaptado de tal manera que en algunos casos: Las dos ultimas etapas se pueden retrasar hasta la etapa de implementacin Si se utiliza un enfoque exploratorio de diseo, las interfaces se pueden disear despus de que se definan las estructuras de datos. Se puede omitir la etapa de especificacin abstracta, aunque es parte fundamental del diseo de sistemas crticos Cuando se utilizan mtodos giles las salidas del proceso de diseo no sern documentos de especificacin separados, sino que estarn representadas en el cdigo del programa y una vez diseada la arquitectura de un sistema, las etapas posteriores del diseo son incrementales y cada incremento es representado como cdigo del programa en lugar de un modelo de diseo. Un enfoque opuesto es el de mtodos estructurados que se basan en la produccin de modelos grficos del sistema, el mtodo estructurado incluye un modelo de proceso de diseo, notaciones que representan el diseo, formato de informes, reglas y pautas de diseo, estos mtodos se pueden ayudar de los siguientes modelos: Un modelo de objetos, que muestra las clases de objetos y sus dependencias Un modelo de secuencias, que muestra como interactan los objetos del sistema cuando este se ejecuta Un modelo de transicin de estados, que muestra los estados del sistema Un modelo estructural donde se documentan los componentes del sistema y sus agregaciones Un modelo de flujo de datos, donde los datos se transforman cuando se procesan. El desarrollo de un programas se sigue de manera natural sobre el diseo, depende del programador, no hay un proceso general que se deba seguir, normalmente los programadores llevan a cabo algunas pruebas del cdigo que han desarrollado, aqu pueden aparecer defectos que deben eliminarse, a esto se le denomina depuracin.

La validacin del software: Se utiliza para verificar y validar que un sistema se ajusta a sus especificaciones y que cumple con las expectativas del usuario que lo comprar, implica procesos de comprobacin as como inspecciones y revisiones.

Las etapas del proceso de pruebas son: Prueba de componentes: Se prueban individualmente los componentes para asegurarse de que funcionan correctamente Prueba del sistema: Los componentes se integran para formar el sistema este proceso comprende encontrar errores que son el resultado de interacciones no previstas entre los componentes y su interfaz. Valida que el sistema cumpla con losa requerimientos funcionales y no funcionales as como propiedades emergentes. Prueba de aceptacin es la prueba final donde el sistema funciona con datos que el cliente proporciona, algunas veces puede tener errores debido a que se usaron datos simulados. Generalmente el desarrollo de componentes y las pruebas se entrelazan, los programadores definen sus propios datos de prueba y de forma incremental prueban el cdigo que se va desarrollando. Las pruebas de aceptacin se pueden denominar alfa para un cliente nico y beta cuando el sistema se comercializara como un producto de software (ejemplo antivirus gratis- pruebas, costo)

Evolucin del software: En esta etapa es donde se lleva a cabo el mantenimiento del software, donde se pueden generar cambios y actualizaciones importantes en el software, debido a nuevas tecnologas, al crecimiento o desarrollo del negocio o cambios en los requerimientos y necesidades de los usuarios.

Existe el Proceso Unificado Rational (RUP)que es un ejemplo de modelo de proceso moderno que proviene del trabajo en el UML y el asociado Proceso Unificado de Desarrollo de Software, este es un proceso hibrido que rene elementos de todos los modelos de procesos genricos y de las iteraciones de apoyo, ilustra buenas practicas en la especificacin y el diseo. Este modelo usa tres perspectivas: Dinmica: mostrando fases del modelo sobre el tiempo Esttica: mostrando las actividades del proceso que representan Prctica: sugiriendo buenas practicas durante el proceso.

Aqu se establece un caso de negocio que interactuara con el sistema, viendo si tiene sentido o no seguir con el proyecto

En esta etapa es la comprensin del dominio del problema, establecer un marco de trabajo arquitectnico para el sistema, desarrollar el plan del proyecto e identificar los riesgos, al termino se debe tener un modelo de los requerimientos del sistema , una descripcin arquitectnica y un plan de desarrollo de software.

Esta comprende el diseo del sistema, la programacin y las pruebas, al finalizar se debe tener un sistema software operativo y la documentacin para el usuario

Es la etapa final donde el sistema trabaja en un entorno real ante la comunidad del usuario, al finalizar se debe tener un sistema software funcionando correctamente y bien documentado.

La perspectiva prctica en el RUP describe buenas prcticas de la ingeniera del software como: 1. Desarrollo del software en forma iterativa, planificando incrementos del sistema basado en las prioridades del usuario y entregando las caractersticas del sistema de ms prioridad al inicio del proceso de desarrollo.

2. Gestin de requerimientos, hay que documentar explcitamente los requerimientos del cliente y mantenerse al tanto de los cambios analizando su impacto antes de aceptarlos.
3. Utilizar arquitecturas basada en componentes 4. Modelar el software visiblemente utilizando modelos grficos UML 5. Verificar la calidad del software, asegurarse que se cumplan los estndares de calidad organizacionales. 6. Control de cambios de software, hay que gestionar los cambios usando procedimientos y herramientas que nos ayuden a mantener el control.

Consultar Captulo 5 de Pressman para ms recomendaciones en la buena prctica de la ingeniera de software.

Qu es CASE? Ingeniera del Software Asistida por Computadora: son programas que se utilizan para ayudar a las actividades del proceso del software, actualmente todos los mtodos viene con tecnologa CASE asociada, como los editores para las notaciones del mtodo, mdulos de anlisis de modelos y generadores de informes para poder crear la documentacin del sistema, algunas incluyen un generador de cdigo que lo automticamente lo genera a partir del modelo del sistema, depuracin de programas, la conversin de programas a una versin ms reciente del lenguaje, etc. Sin embargo se puede estar limitadas estas herramientas debido a que: El diseo es parte de la creatividad del diseador y CASE automatizan las actividades rutinarias La ingeniera de software es una actividad en equipo y CASE no proporciona ayuda para esto.

1.5Administracin de Proyectos

Cualquier proyecto de software se inicia por alguna necesidad de negocios, la necesidad de corregir un defecto en una aplicacin existente o la adaptacin de un sistema heredado a un ambiente de negocios cambiante , etc. La administracin Mito: Ya se tiene un libro lleno de estndares y procedimientos para la construccin de software Esto proporcionara a mi gente todo el conocimiento? Realidad: Puede que el libro exista pero Se usa? Se sabe de su existencia? El libro refleja la practica actual de la ingeniera de software?Esta completo? Es adaptable?Se dirige a tiempos de entrega cuidando la calidad de software? Mito: Si se esta atrasado es posible contratar mas programadores para as terminar a tiempo Realidad: Si es planeado y coordinado si, de lo contrario se necesitara tiempo para ensear a los nuevos integrantes retrasando mas el proyecto. Mito: Si subcontrato puedo relajarme y dejar a la empresa que contrate para hacerlo.? Realidad: Si no se administra y controla el proyecto por parte de la administracin de la organizacin, puede entrar en conflictos al subcontratar. El cliente Mito: Un enunciado general de los objetivos es suficiente para comenzar a escribir los programas y detallar despus Realidad: solo se logra mediante la continua comunicacin entre cliente y desarrollador. Mito: Los requerimientos pueden cambiar se puede ajustar esos cambios porque el software es flexible? Realidad: Los cambios deben ser solicitados en etapas tempranas, en cuanto ms pasa el tiempo estos cambios generan dificultades y costos cuando el proyecto esta avanzado en el diseo e implementacin debido al ajuste en los recursos.

El desarrollador Mito: Una vez que el programa ha sido escrito y puesto a funcionar, el trabajo esta terminado Realidad: Entre el 60 y 80% del esfuerzo aplicado en el software se realizar despus de que el software haya sido entregado al cliente por primera vez.

Mito: mientras el programa no se este ejecutando no hay forma de evaluar su calidad Realidad: El aseguramiento de la calidad se puede realizar desde el inicio del proyecto utilizando revisiones tcnicas formales.
Mito: El nico producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa funcionando Realidad: El programa es una parte, la documentacin de este es sumamente importante para una exitosa ingeniera de software.

Mito: La ingeniera de software har tener documentacin voluminosa retrasando el proceso Realidad: la ingeniera de software esta enfocada a la calidad, donde la documentacin forma parte de ella conduciendo a la reduccin de trabajos redundantes que ayuda a la disminucin en los tiempos de entrega.
Administracin de Proyectos Por todo lo anterior es importante es importante la gestin de proyectos que nos ayuda en la planificacin, supervisin control de personal, ajuste en presupuesto, tiempos, en el proceso y los eventos que ocurren mientras el software evoluciona de inicio hasta la implementacin operativa. La buena gestin no asegura el xito del proyecto pero la mala si el fracaso del mismo. Muchos de los problemas son: El producto es intangible es decir no se puede tocar, no visible como una obra en construccin, los gestores no ven el progreso No existen procesos del software estndar, solo prueba y verifica La mayora de las veces los proyectos grandes son nicos, dificulta en la experiencia del gestor quien tiene que entrarse al negocio.

Actividades de la gestin de proyectos: Estas actividades son las que un gestor responsable debiera realizar sin embargo depende tambin de la organizacin y del software a desarrollar: Redaccin de la propuesta(objetivos y como debera de llevarse a cabo, justificaciones, estimaciones de tiempo y costos) Planificacin y Calendarizacin del proyecto(identificacin de tareas, hitos y entregas del proyecto, recursos) Estimacin de costes del proyecto (tomar en cuenta la productividad del negocio, apoyarse en alguna tcnica de estimacin o de los modelos algortmicos de costes (obtener el costo a partir del tamao del proyecto), o del modelo COCOMO, que se refieren a estimacin por medio del tamao, duracin, personal y producto) Supervisin y revisin del proyecto(Debe ser continua, el gestor debe saber del progreso y comparar con lo planificado, al igual que los costos y recursos) Seleccin y evaluacin del personal (El gestor forma su equipo de trabajo tomando en cuenta las restricciones como presupuesto, experiencia, disponibilidad) Es importante tomar en cuenta la motivacin, cohesin donde es ms importante el grupo mas que el individuo, comunicacin y organizacin del grupo, entornos de trabajo (ubicacin y privacidad), Existe el modelo creado por la SEI PCMM que brinda un marco de trabajo para la organizacin en recursos humanos. Redaccin y presentacin de informes(el gestor es responsable de informar al cliente y contratistas sobre el proyecto mediante documentos coherentes y concisos, debe ser buen comunicador tanto oral como escrita)

Planificacin del proyecto: La gestin efectiva de un proyecto de software comprende de la planificacin del progreso del proyecto, adelantndose a los problemas y soluciones de estos que puedan existir, un plan es el conductor para el proyecto.

El plan del proyecto: fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo, teniendo el siguiente orden: Introduccin: describe objetivos y restricciones Organizacin del proyecto: Describe los roles de la gente involucrada y como esta organizado el equipo de trabajo. Requerimientos de hardware y software: Describe el hardware y software de ayuda para el desarrollo, y si es necesario comprar debe incluir estimaciones de precios y fechas de entrega (algn servidor, etc.) Divisin del trabajo, describe la divisin del proyecto en actividades, identificando los hitos y productos a entregar. Programa del proyecto: describe la dependencia entre actividades , el tiempo estimado para alcanzar cada hito y la asignacin de la gente. Hitos y entregas: Estos se deben establecer cuando se planifica el proyecto, en cada uno debe existir una salida formal como un informe corto de los logros en una actividad del proyecto.
Un hito es una tarea de duracin cero que simboliza el haber conseguido un logro importante en el proyecto. Los hitos son una forma de conocer el avance del proyecto sin estar familiarizado con el proyecto y constituyen un trabajo de duracin cero porque simbolizan un logro, un punto, un momento en el proyecto. En el cronograma de nuestro proyecto deberan existir varios hitos que informen la fecha estimada en que pensamos cumplirlos, y que luego en la ejecucin compararemos con la fecha real. En muchos proyectos, se hace mencin solamente de los hitos y es muy comn que slo los hitos le interesen a un comit de directores que revisa proyectos en una gran organizacin. En tal sentido, los hitos son la forma ms abarcativa de monitorear la ejecucin de un proyecto. Si alguien se est construyendo una casa, inmediatamente toda la familia habla de los hitos y no del cronograma: el lunes completaron los cimentos, la semana que viene terminan de colocar los pisos, ese da estar finalizada la instalacin de gas, etc. Dentro de los consejos tpicos, se recomienda colocar algunos hitos dentro del plan solamente como seal de que llegamos a un punto importante en el proyecto. Estos hitos servirn como herramientas de comunicacin para los patrocinadores y dems involucrados. De esa manera se define un tablero de control para todos los proyectos, en el cual se indican, por ejemplo, los hitos que hemos atravesado, cul se encuentra cerca, cul est atrasado, etc.

Calendarizacin del proyecto: Esta es una de las tareas ms difcil de los gestores de proyectos, ya que estiman tiempos y recursos requeridos para completar las actividades y organizarlas de manera coherente. Esta difiere para nuevos proyectos debido de que pueden utilizarse diferentes mtodos de diseo o lenguajes de implementacin diferentes. Por lo general el calendario del proyecto se representa grficamente, mostrando la divisin del trabajo, las dependencias de actividades y la asignacin del personal, ayudndose de herramientas como Microsoft Project.

Grficas de barras y las redes de actividades son notaciones grficas que se utilizan para ilustrar la calendarizacin del proyecto. Las de barra (Gant)muestran quien es responsable de cada actividad as como cuando comenzarla y cuando debe terminarla. Las redes de actividad muestran las dependencias entre actividades Estas se generan a partir de una base de datos y una herramienta para la administracin de proyectos.

Gestin de riesgos: Esta tarea es importante para el gestor del proyecto ya que debe anticipar los riesgos que podras afectar la programacin del proyecto o la calidad del software a desarrollar y emprender las acciones necesarias para evitar esos riesgos, sin embargo puede existir algunos que son inevitables (Influenza, Dlar(financiero, prever un colchn)
Valorar las probabilidades y consecuencias de estos riesgos, si son altos, moderados o bajos y pueden ser insignificantes, serios o catastrficos. Por ejemplo: tecnologa, de personal, de requerimientos, de herramientas, organizacionales o de estimacin

Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto, tales como estrategias de prevencin, de minimizacin, planes de contingencia (financieros)

Pueden existir riesgos:

Del proyecto: que se vaya un diseador Del producto: que se afecte la calidad o rendimiento por ejemplo comprar un servidor que no de la capacidad esperada Del negocio: que la competencia gane mercado

Valorar los riesgos de forma constante y revisar los planes para la mitigacin de riesgos tan pronto como la informacin de estos este disponible.