VISION GENERAL DE LA INGENIERIA DE SISTEMAS

La ingeniera es el anlisis, diseo, construccin, verificacin y gestin de entidades tcnicas. El trabajo que se asocia a la ingeniera del software se puede dividir en tres fases, con independencia del rea de aplicacin, tamao o complejidad del proyecto. 1. Fase de definicin. Se centra sobre el qu. Identificar qu informacin ha de ser procesada, que funcin y rendimiento se desea, qu comportamiento del sistema, qu interfaces van a ser establecidas, qu restricciones de diseo existen, y qu criterios de validacin se necesitan para definir un sistema correcto. Identificar los requisitos del sistema y del software. Las tareas especficas de esta fase son: Ingeniera de Sistemas o de informacin. Planificacin del proyecto software. Anlisis de requerimientos.

2. Fase de desarrollo. Se centra en el cmo. Definir cmo han de disearse las estructuras de datos, cmo ha de implementarse la funcin dentro de una arquitectura de software, cmo ha de implementarse los detalles procedimentales, cmo han de caracterizarse interfaces, cmo ha de traducirse el diseo en un lenguaje de programacin y cmo ha de realizarse la prueba. Las tareas especficas de esta fase son: Diseo del software. Generacin de cdigo. Prueba del software.

3. Fase de mantenimiento. Se centra en el cambio. Correccin de errores. Adaptaciones requeridas a medida que evoluciona el entorno del software. Cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Se encuentran cuatro tipos de cambio: o Correccin o Adaptacin o Mejora o prevencin

METADATO
Titulo Descripcin Modelos de Proceso de Software El presente Objeto de Aprendizaje, presenta los modelos de proceso para la ingeniera del software segn la naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse, los controles y entregas que se requieren, detallando cada proceso, para orientar al estudiante en esta fase de seleccin y finalizando con ejemplos del tema. Espaol Modelo, Proceso, Paradigma, Software Jairo Martnez Banda UNAD 1.0 Free Noviembre 2 de 2008 HTML Cargar a un servidor web con Soporte de Macromedia Flash Cualquier navegador de internet 1.5 MB 0 free Ingeniera, Arquitectura, Urbanismo y afines Ingenieria de Sistemas

Idioma Palabras Claves Autor Entidad Versin Licencia Fecha Formato Instrucciones de instalacin Requerimientos Tamao Costo Licencia Fuente de clasificacin reas de Conocimiento Sub-rea de Conocimiento

Tipo de Formacin Campo de formacin Nombre del curso Nombre del Programa

Ingenieria Aplicada Disciplinar Ingeniera de Software Ingenieria de Sistemas

El Proceso de Desarrollo del Software

Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Dicho proceso, en trminos globales se muestra en la Figura 1. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un producto software en s es complejo, es prcticamente inviable conseguir un 100% de confiabilidad de un programa por pequeo que sea. Un producto software es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares.

Figura 1: proceso de desarrollo de software. El proceso de desarrollo de software no es nico. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos: 1.Especificacin de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2.Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin.

3.Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4.Evolucin: El software debe evolucionar, para adaptarse a las necesidades del cliente. Roger Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 2. Los elementos involucrados se describen a continuacin: Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamao o complejidad. Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividadesdel marco de trabajo se adapten a las caractersticas del proyecto de software y los requisitos del equipo del proyecto. Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 2: Elementos del proceso del software

[1]

Pressman, R, Ingeniera del Software: Un enfoque prctico, McGraw Hill 1997.

MODELOS DE PROCESO DE SOFTWARE

Modelo Lineal Secuencial o en Cascada

El modelo en cascada consta de las siguientes fases: 1.Definicin de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definicin en detalle. 2.Diseo de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3.Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de software. Se realizan pruebas de cada unidad. 4.Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.

5.Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es puesto en marcha y se realiza la correccin de errores descubiertos. Se realizan mejoras de implementacin. Se identifican nuevos requisitos. La interaccin entre fases puede observarse en la Figura 1. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior ygeneralmente se incluye la correccin delos problemas encontrados en fases previas. En la prctica, este modelo no es lineal, e involucra varias iteraciones e interaccin entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: Las iteraciones son costosas e implican rehacer trabajo debido a la produccin y aprobacin de documentos. Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases. Los problemas se dejan para su posterior resolucin, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante. Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto. Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difcil responder a cambios en los requisitos. Este modelo slo debe usarse si se entienden a plenitud los requisitos. An se utiliza como parte de proyectos grandes.

Figura 1: Modelo de desarrollo en cascada.

Desarrollo Evolutivo
La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 1 se observa cmo las actividades concurrentes: especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el

usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del

usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. Entre los puntos favorables de este modelo estn:

La especificacin puede desarrollarse de forma creciente. Los usuarios y desarrolladores logran un mejor entendimiento del sistema.

Esto se refleja en una mejora de la calidad del software.

Es ms efectivo que el modelo de cascada, ya que cumple con las

necesidades inmediatas del cliente. Desde una perspectiva de ingeniera y administracin se identifican los siguientes problemas:

Proceso no Visible: Los administradores necesitan entregas para medir el

progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema.

Sistemas pobremente estructurados: Los cambios continuos pueden ser

perjudiciales para la estructura del software haciendo costoso el mantenimiento.

Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan

herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. Este modelo es efectivo en proyectos pequeos (menos de 100.000 lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con poco tiempo para su desarrollo y sin generar documentacin para cada versin. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento ms estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

Desarrollo Formal de Sistemas

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

La Figura 1 ilustra un paradigma ideal de programacin automtica. Se distinguen dos fases globales: especificacin (incluyendo validacin) y transformacin. Las caractersticas principales de este paradigma son: la especificacin es formal y ejecutable constituye el primer prototipo del sistema), la especificacin es validada mediante prototipacin. Posteriormente, a travs de transformaciones formales la especificacin se convierte en la implementacin del sistema, en el ltimo paso de transformacin se obtiene una implementacin en un lenguaje de programacin determinado. El mantenimiento se realiza sobre la especificacin (no sobre el cdigo fuente), la documentacin es generada automticamente y el mantenimiento es realizado por repeticin del proceso (no mediante parches sobre la implementacin). Observaciones sobre el desarrollo formal de sistemas: Permite demostrar la correccin del sistema durante el proceso de transformacin. As, las pruebas que verifican la correspondencia con la especificacin no son necesarias. Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

Desarrollo basado en Reutilizacin

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este modelo consta de 4 fases ilustradas en la Figura 1. A continuacin se describe cada fase: 1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes ms adecuados (fase 1). 3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este marco. 4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integracin es parte del desarrollo en lugar de una actividad separada. Las ventajas de este modelo son: Disminuye el costo y esfuerzo de desarrollo. Reduce el tiempo de entrega. Disminuye los riesgos durante el desarrollo.

Desventajas de este modelo: Los compromisos en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente. Las actualizaciones de los componentes adquiridos no estn en manos de los desarrolladores del sistema.

Procesos iterativos
A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el soporte de las iteraciones: Desarrollo Incremental. Desarrollo en Espiral.

Desarrollo Incremental El enfoque incremental de desarrollo se sugiri como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Es una combinacin del Modelo de Cascada y Modelo Evolutivo. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Figura 1: Modelo de desarrollo iterativo incremental. Entre las ventajas del modelo incremental se encuentran: Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos. Algunas de las desventajas identificadas para este modelo son: Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas). Cada incremento debe aumentar la funcionalidad. Es difcil establecer las correspondencias de los requisitos contra los incrementos. Es difcil detectar las unidades o servicios genricos para todo el sistema.

Desarrollo en Espiral El modelo de desarrollo en espiral (ver Figura 2) es actualmente uno de los ms conocidos y fue propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: 1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso

y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. 3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es una actividad importante en la administracin del proyecto.

El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

Actividad Actividad 1

Propsito Identificar las fases del trabajo de la Ingeniera de Software

Descripcin Realizar la siguiente actividad para identificar las fases del trabajo asociado a la Ingeniera de Software. Actividad 1.

Actividad 2

Conocer las caractersticas atribuibles al proceso de desarrollo de software

Actividad 3

Identificar las diferencias, ventajas y desventajas de los diferentes modelos de proceso de software.

Reconocimiento de los elementos involucrados en el proceso de desarrollo de software mediante un ejemplo e indagacin sobre las causas que originaron la etapa denominada Crisis del Software Realizacin de Cuadro comparativo entre los diferentes modelos de proceso de software bajo los siguientes parmetros:

Funciona con requisitos y arquitectura no predefinidos

Produce software altamente fiable Gestin de riesgos Permite correcciones sobre la marcha

Visin del progreso por el Cliente y el Jefe del proyecto

ACTIVIDAD EVALUATIVA . QUIZ

Esta actividad busca evaluar las competencias interpretativa adquiridas por el estudiante sobre el tema de los Modelos de Proceso de Software. Consta de 10 preguntas de seleccin multiple con nica respuesta y con mltiple respuesta. Cada pregunta tiene un valor de 50 puntos. La actividad se aprueba con un mnimo de 400 puntos. quisingsw.htm

UNIDAD 2

Resumen
Se presenta una variacin al mtodo de estimacin de tamao y esfuerzo basado en los Puntos Funcin, para proyectos de software con Reutilizacin de componentes objetuales.

El mtodo establecido define los elementos a considerar y su importancia a partir de datos experimentales. ste representa una primera aproximacin a un modelo que refleje el problema analizado, el resultado obtenido muestra adecuadamente el impacto o ajuste necesario en la estimacin del esfuerzo en proyectos de desarrollo de aplicaciones Internet/Intranet con desarrollo utilizando UML.

Introduccin
En el complejo mundo del desarrollo de Sistemas de Informacin, resalta como principal mtrica de tamao el indicador Punto Funcin (PF). No cabe duda, que la informacin entregada por el citado

indicador es importante al momento de realizar una estimacin en el desarrollo de productos software, pero actualmente este desarrollo ha incorporado innumerables mecanismos que facilitan la Reutilizacin de componentes de Software, lo que induce a pensar que este indicador puede estar requiriendo de mejoras que lo acerquen ms a la realidad actual en esta rea de la ingeniera de software y desarrollo de sistemas. Puntos de Funcin fue desarrollado por Albrecht (1984). En 1986 se cre el International Function Point User Group, que se comprometi a difundir esta metodologa, publicando peridicamente un Manual Prctico, cuya versin 4.1 ha aparecido en marzo de 1999. De este modo la metodologa del Punto Funcin se ha convertido en el Estndar ISO/IEC 14.143-1 Software Measurement Functional size measurement publicado en 1998. La tcnica de anlisis de Punto Funcin entrega una estimacin del tamao del software independiente de la tecnologa utilizada para su desarrollo y dependiente, nicamente de la funcionalidad del sistema. Esta definicin pareciera resolver la inquietud que presenta este documento, pues habla de la independencia de la tecnologa utilizada, pero ser que la tecnologa actual, merece el mismo tratamiento que la de hace una dcada?, Considera efectivamente la enorme posibilidad de Reutilizacin que proporcionan las nuevas tecnologas y metodologas de desarrollo basadas en la Orientacin a objeto?. Si ambas preguntas, encontraran sus respectivas respuestas en el indicador PF, entonces por qu los proyectos de desarrollo de software presentan slo un 1,75% de uso sin modificacin?(ver figura1). Diversos estudios demuestran que gran parte de los fracasos en los proyectos de desarrollo de software se deben precisamente a una de las primeras etapas de este proceso como es el Anlisis de Requerimientos, el que depende directamente del usuario y se encuentra estrechamente ligado a tal indicador. La realidad presentada en la figura1 nos lleva a hacer, la siguiente pregunta Es Punto Funcin la tcnica de estimacin que requiere el desarrollo de software actual?. La respuesta a la pregunta anterior es, s, el Punto Funcin sigue siendo hoy una tcnica vlida para la estimacin de esfuerzo en un proyecto de desarrollo de software, sin embargo es necesario que este mtodo deba ser modificado para destacar la importancia del concepto de reutilizacin en el desarrollo de aplicaciones Intranet/Internet.

Proyectos con Reutilizacin de Componentes

MEJORA A LA TCNICA DE PUNTO FUNCIN: CASOS DE APLICACIN EN PROYECTOS CON REUTILIZACIN DE COMPONENTES La pregunta que habra que plantearse al momento de sugerir una mejora en los resultados proporcionados por este indicador es Cmo es posible estimar el porcentaje de Reutilizacin en un proyecto de desarrollo de software?. La respuesta a esta pregunta es la base para la incorporacin de una mejora a la tcnica actual. No resulta tan evidente como se otorga un valor numrico a los factores que formaran parte de nuestra respuesta, y por otro lado, cmo este valor afectara a la estimacin inicial realizada con la tcnica de PF tradicional. He aqu entonces, donde se plantea a partir de casos prcticos nuestra metodologa de estimacin de proyectos de software con utilizacin de componentes reusables y enfocada a desarrollos con tecnologas de Intranet/Internet. Se presenta inicialmente el marco conceptual de los sistemas que evaluaremos as como tambin una breve descripcin de la metodologa de desarrollo y plataforma tecnolgica empleada para su realizacin.

A partir de dos productos de software: Sistema de Gestin Acadmica y Sistema de Gestin Contable, denotados por P1y P2 respectivamente, se ha construido un tercer producto, Sistema de Gestin para Egresados, el que denominaremos P3 con componentes reusables provenientes de ambos proyectos iniciales. Todos los productos utilizan la misma metodologa de desarrollo bajo una plataforma Intranet/Internet. Se entregar lo que podra considerarse una mejora para el modelo de estimacin de PF, que sin duda puede ser un interesante punto de partida para estudios posteriores a este. A continuacin se presenta un breve resumen con los antecedentes necesarios para comprender los conceptos utilizados en la estimacin de los proyectos. Requerimientos Funcionales para los Proyectos en Estudio Requerimientos Funcionales Sistema de Gestin Acadmica (P1) Lograr obtener informacin precisa y oportuna referente a: Total alumnos inscritos por actividad y/o cursos para un rango de fechas determinado. Bsqueda de alumnos por regin, empresa, profesin, cargo, edad o rango de edad, gnero, pas Cursos que componen un diploma, un Posttulo o una actividad especfica Cursos que ha dictado un profesor Evaluacin recibida desde los alumnos a un profesor para un curso determinado Evaluacin recibida desde los alumnos a un curso y/o actividad Histrico de inscripciones por curso para una actividad determinada Consulta de personas por situacin (activa, ausente, desinscrito, etc.) Reporte de calificacin(notas finales) del curso o por programa (faltas de entrega) Reporte de calificaciones (nota final) pendientes por curso y/o actividad Alumnos por concluir una actividad especfica en un periodo prximo Alumnos finalizados por actividad Cantidad de alumnos diplomados a la fecha por actividad Cantidad de profesores con actividades vigentes (para un rango de fecha dada).

Requerimientos Funcionales Sistema de Gestin Contable (P2) Lograr obtener informacin precisa y oportuna referente a: Deuda de Alumnos por conceptos de matrcula, escolaridad, bibliografa, fotocopias, videos, materiales, etc. Pagos totales (Ingresos al sistema), por alumnos, empresas, para una actividad, rango de fecha. Ingresos por conceptos de: Matrcula, arancel, capacitacin, seminarios y otros, por actividad, alumno y rango de fechas Ingresos por tipos de pagos Saldo presupuestario a la fecha por tems o por actividad (disponible, contable) Gasto de un tem determinado para un periodo de tiempo y actividad determinada Cantidad total por recibir por distintos conceptos tem de presupuesto y de transacciones en un periodo determinado.

Requerimientos Funcionales Sistema de Gestin Egresados (P3) Lograr obtener informacin precisa y oportuna referente a:

Administracin de Personas, Empresas, Movimientos Contables y Cierre Mensual. Mantencin de informacin referente a: Isapre, AFP, Cargos, Calidad, Cuenta Corriente, Idioma, Giro, Item de Presupuesto, Banco, Plaza, Tipos de pago, Campus USM, Carreras USM, Universidades y/o Institutos, etc. Consultas con relacin a: Listado General de Egresados, Pginas Amarillas y Listado de Empresas, Oferta Laboral, Listado Demanda Laboral, Listado de cobranza, Estado de cuentas corrientes socios Servicios: Publicacin de Actividades y/o cursos, Demanda de Trabajo, Compra, Venta, Biblioteca

Metodologa y Arquitectura de Desarrollo Los sistemas mencionados se desarrollaron bajo un enfoque de Orientacin a Objetos (OO), el que toma elementos reales existentes, los analiza y les da un modelado semntico, con lo cual se logra concretar un software ms cercano y acorde a la realidad cotidiana. Por ello, las actuales herramientas de desarrollo procuran ocupar las potencialidades de la OO, es as que se construyen mdulos o libreras Reutilizables (como por ejemplo, archivos DLL), con lo que hay un importante ahorro de cdigo escrito. La metodologa considera un desarrollo iterativo, de tal forma de refinar el trabajo y obtener mejores resultados finales en forma cclica. En el desarrollo de los sistemas tambin se considera el Unified Modeling Languaje (UML) (Lenguaje Unificado de Modelado). El que se define como un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software. La Arquitectura Cliente/Servidor es, en su esencia, una arquitectura de procesos, en donde se definen claramente dos roles: los procesos llamados Clientes, que solicitan servicios y datos; y los procesos llamados Servidores, cuyo papel es atender estas solicitudes. Clientes y Servidores; son independientes entre s, debido a que un proceso servidor puede atender requerimientos de cualquier proceso cliente, sin importar el ambiente de hardware o software en que residen ambos procesos. Los sistemas presentan una arquitectura Cliente/Servidor en tres niveles la que se encuentra orientada a diseo de aplicaciones basadas en arquitecturas multicapas, la que se utiliza para separar responsabilidades en diferentes componentes de los sistemas de informacin. Cada capa corresponde a un conjunto de componentes (clases, controles, servicios de base de datos, etc.) que ofrecen servicios hacia componentes de otras capas (o de la misma), o hacia el usuario final. Los servicios que una capa coloca a disposicin de otras equivalen a los puntos de entrada a esa capa. Es posible utilizar las mismas reglas del negocio para diferentes aplicaciones, corriendo sobre distintas plataformas. La lgica, en trminos de reglas del negocio, se asla de los elementos de interfaz y de la forma de almacenamiento de los objetos. Bajo este tipo de arquitectura, es posible separar fsicamente los componentes del negocio, pudindose centralizar en servidores especializados, a travs del uso de monitores transaccionales como Microsoft Managment Transaction Server (MTS). Consideraciones especiales de los proyectos En el desarrollo de los casos presentados participa el mismo equipo de trabajo, por lo que no se requiere un tiempo previo de aprendizaje en la metodologa de desarrollo para enfrentar un nuevo proyecto. La decisin de Reutilizacin es la nica estrategia viable en P3, dada las severas restricciones de tiempo impuestas al proyecto y es aplicada desde el inicio en cada uno de los tres proyectos. DATOS EXPERIMENTALES: CLCULO PUNTOS FUNCIN Clculo de PF tericos para los proyectos en estudio Resumen de clculo de Punto Funcin para los tres proyectos:

Clculo de PF real para P3 Para calcular cual fue el PF real para P3, debemos saber de antemano cual es la productividad con la cual se desarrollaron estos proyectos,. Para ello tomaremos los datos de PF de P1 y P2, en los cuales el esfuerzo promedio fue de 1,3 HM y considerando los plazos de ejecucin respectivos. De esta forma se tiene:

Para calcular el PF real de P3 se obtiene a partir de operar con la productividad promedio alcanzada en los proyectos P1 Y P2 que es de 13,5 PF/HM y el esfuerzo efectivamente realizado para obtener P3 (6,5 HM). PF(P3) real = 13.5[pf/HM] * 6.5[HM] = 88[pf] (1) Impacto de la reusabilidad en el desarrollo de P3 El valor de P3 terico (ver Tabla 5) no considera que este software se desarroll a partir de P1 y P2; el enfoque que tuvieron estos desarrollos nos da un indicio de los posibles factores que pueden influir directamente en la Reutilizacin. Estos factores se han clasificado en tres categoras que se describen a continuacin:

Actividad
Como ejercicio, se debe presentar la incorporacin de estos factores al resultado anterior. Se debe Indicar las ocurrencias de cada uno de estos factores en el nuevo proyecto, considerando los componentes reusables en forma independiente segn provengan del proyecto P1 o de P2.

Se recomienda trabajarlo en parejas para incurrir en el debate. Una vez realizada esta actividad, confrontarla con la solucin presente en el link: http://contents.unadvirtual.org/moodle/file.php/140/DocumentosAct/EstimacionDeProyecto s.pdf

Ejercicio Tomado de: Lautaro Guerra Genskowsky Universidad Tcnica Federico Santa Mara, Valparaso, Chile - lguerra@uv.utfsm.cl Pamela Hermosilla Monckton Universidad Tcnica Federico Santa Mara, Valparaso, Chile - phermosi@uv.utfsm.cl

Gestin de Proyectos Software Mtricas

(esta en pdf)

Unidad 3

Aseguramiento de la Calidad del Software

La garanta o aseguramiento de la calidad del software es una actividad de proteccin que se aplica a cada paso del proceso de software y que comprende: procedimientos, mtodos y herramientas, revisiones tcnicas formales, tcnicas y estrategias de prueba, procedimientos de garanta de ajustes y mecanismos de medida e informacin.

Introduccin
La garanta de calidad del software (SQA, Software Quality Assurance GCS, Gestin de calidad del software) es una actividad de proteccin que se aplica a lo largo de todo el proceso del software.
Antes del siglo veinte, la garanta de calidad era responsabilidad nica de la persona que construa el producto. La primera funcin de control y de garanta de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendi rpidamente por todo el mundo de las manufacturas. Hoy en da, cada compaa tiene un mecanismo que asegura la calidad de sus productos de hecho,

durante la pasada dcada, se han usado ampliamente como tcticas de mercado la declaracin explcita de mensajes que ponan de manifiesto la calidad ofrecida por las compaas. La historia de la garanta de calidad en el desarrollo de software ha sido paralela a la historia en la fabricacin de hardware. Durante los primeros aos de informacin (los 50 y los 60), la calidad era responsabilidad nicamente del programador. Durante los aos 70 se introdujeron estndares de garanta de calidad para el software en los contratos militares de desarrollo de software y sean extendido rpidamente en los desarrollos de software del mundo comercial.

La SQA forma parte de una funcin ms amplia de garanta de calidad y engloba las siguientes actividades: 1. 2. 3. 4. Un enfoque de gestin de calidad. Mtodos y herramientas Revisiones tcnicas formales Documentacin

La calidad del software es importante porque: Se reduce la repeticin de actividades o tareas. Supone costos ms bajos de desarrollo. Se mejora el proceso del software y por ende el producto.

Actividad
Por favor, observar detenidamente el siguiente video sobre Aseguramiento de la Calidad del Software. Una vez visto el video con detenimiento, realice una tabla donde se plasme el conjunto de tareas y acciones sistemticas y planificadas que permitan asegurar la calidad del software para cada una de las aplicaciones del Software vistas en la primera unidad.Recuerde que para determinar la naturaleza de una aplicacin de software, hay dos factores importantes que se deben considerar: el contenido y el determinstico de la informacin. El contenido se refiere al significado y a la forma de la informacin de entrada y salida. El determinstico de la informacin se refiere a la predecibilidad del orden y del tiempo de llegada de los datos. Debata con algunos compaeros su trabajo y por ltimo, escriba las conclusiones a que haya lugar. http://www.youtube.com/watch?feature=player_embedded&v=WW6vXq7ueMk