Ingenieria de Software XV

MAPA MENTAL

2009-05-21T15:52:00.001-07:00

Tópicos Avanzados en la Ingeniería de Software

2009-05-14T11:06:00.000-07:00

REINGENIERÍA DE SOFTWARE

Reingeniería de Software es una forma de modernización para mejorar las capacidades y/o mantenibilidad de los sistemas de información heredados mediante la aplicación de tecnologías y practicas modernas. La Reingeniería de Software ofrece una disciplina de preparación para migrar un sistema de información heredado hacia un sistema evolucionable. El proceso aplica principios de ingeniería para un sistema existente para encontrar nuevos requerimientos.

"El Instituto de Ingeniería de software (SEI) desarrollo una definición de Reingeniería como: Reingeniería es la transformación sistemática de un sistema existente dentro de una nueva forma de realizar mejoramientos de calidad en unas operaciones, capacidad del sistema, funcionabilidad, rendimiento o evolucionabilidad a bajo costo, agendas o riesgos para el cliente." [Till 95]

El propósito de la reingeniería es que los sistemas existentes tomen ventajas de las nuevas tecnologías y habilitar el nuevo esfuerzo de desarrollo para que aproveche las ventajas de reutilizar sistemas existentes. La reingeniería tiene el potencial de mejorar la productividad y calidad del software a través de todo el ciclo de vida.La reingeniería casi siempre implica cambiar la forma de un programa y mejorar su documentación. En este caso, la funcionabilidad del programa no es cambiada; sólo su forma es modificada. En otros casos, la reingeniería va más allá de la forma e incluye rediseñar para cambiar la funcionabilidad del programa para buscar mejores requerimientos de usuario.

Los objetivos de la reingeniería son:

Proporcionar asistencia automatizada para el mantenimiento.
Reducir los errores y costos del mantenimiento.
Incrementar la intercambiabilidad del grupo de mantenimiento.
Hacer sistemas fáciles de entender, cambiar y probar.
Habilitar la conversión y migración de sistemas.
Reforzar el apego a estándares.
Mejorar la respuesta a peticiones de mantenimiento.
Mejorar el estado de ánimo del grupo de mantenimiento.
Proteger y extender la vida del sistema.
Usar CASE para apoyar sistemas existentes
Re-usar componentes de sistema existentes.

La reingeniería puede ayudar a entender sistemas existentes y descubrir los componentes de software que son comunes en todo el sistema. Estos componentes comunes pueden ser re-usados en el desarrollo (o redesarrollo) de sistemas y así reducir el tiempo y riesgos del desarrollo de sistemas.

La reingeniería requiere tiempo; implica un coste de dinero enorme y absorbe recursos que de otro modo se podrían emplear en preocupaciones más inmediatas. Por todo esto, la reingeniería no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos años. La reingeniería de sistemas de información es una actividad que absorberá recursos de las tecnologías de la información durante muchos años.

2.3 LA IMPORTANCIA DE APLICAR REINGENIERÍA DE SOFTWARE

Las Viejas Aplicaciones

Mucha gente al ver las grandes y viejas mansiones queda asombrado de su belleza, pero no se preguntan que tan bien se puede vivir en ellas. Las personas que lo hacen dicen que es una pesadilla mantenerlas. Todas ellas fueron construidas con viejas tecnología estándar. Sus paredes externas no tienen aislamiento. El alambrado eléctrico tiene limitaciones y claramente es inadecuada para las necesidades de energía de hoy y su cableado decadente crea un severo peligro eléctrico.

Los viejos sistemas son muy similares a los grandes y viejos edificios. Ellos tienen los mismos problemas de mantenimiento, un hecho en gran parte irreconocible por parte de la comunidad corporativa. Muchos de esos edificios son demolidos por que no son mantenibles y ya no sirven para las necesidades de sus ocupantes.

Las viejas computadoras tal vez se puedan ver solamente en museos. Pero en muchos casos, software escrito para viejos modelos de computadora están ejecutándose hoy en día. Un caso extremo es el de un software escrito para una IBM 1401 Autocoder. Cuando la compañía remplazó la 1401 con una IBM 360/40, compraron un emulador de la 1401 para poder ejecutar el software. Esa aplicación hoy día corre en una PC – la compañía compro otro emulador.

Los clientes demandan que las nuevas capacidades sean agregadas al código escrito en sus viejos sistemas. Casi siempre, las empresas encuentran que no pueden modificar su código – el programador que lo mantenía murió recientemente o nadie sabe programar en el lenguaje en el que fue escrito. Por lo que la funcionalidad de ese programa quedará así para siempre.

La siguiente lista son las razones por las que es aplicable la reingeniería a los sistemas de información heredados:

Frecuentes fallas de producción (fiabilidad cuestionable).
Problemas de rendimiento.
Tecnología obsoleta.
Problemas de integración del sistema.
Código de calida pobre.
Dificultad (peligroso) al cambio.
Dificultad para probar.
Mantenimiento caro.
Incremento de problemas del sistema.

Estas razones pueden ser solucionadas al aplicar un proceso de mantenimiento de software, pero cuando dicho mantenimiento deja de ser viable, entonces se toma la decisión de aplicar reingeniería.

Nuevas Ideas, Nuevo Software

Aunque la reingeniería se usa principalmente durante el mantenimiento del software, va mas allá de una simple ayuda para el mantenimiento. La reingeniería es el puente desde viejas tecnologías hacía nuevas tecnologías que las organizaciones deben usar en la actualidad para responder al cambio de requerimientos del negocio.

Los viejos programas representan la tecnología del ayer. Ahora sabemos que los años tienen cuatro dígitos y no dos, que los datos pueden ser manejados mejor en bases de datos y que tenemos nuevos diseños de construcción y lenguajes de programación que permiten diseñar programas notablemente mantenibles.

Cuando el costo de mantener viejos edificios es altamente excesivo, se remplazan estos edificios. Nosotros deberíamos hacer lo mismo con los programas. Los programas no se hacen obsoletos al paso del tiempo ya que fueron escritos para hardware y sistemas operativos que ya no existen, muchos están llenos de características y parches no documentados.Sólo cuando hayamos aprendido a que es mejor invertir en nuevo hardware y nuevos edificios podremos reconocer el valor de remplazar los viejos sistemas raquíticos.

2.4 COSTES Y BENEFICIOS DE LA REINGENIERÍA.

Antes de reconstruir un sistema en uso, es altamente recomendable analizar las diversas alternativas disponibles:

Dejar el producto como está.
Adquirir uno en el mercado que realice la misma función.
Reconstruirlo.

Evidentemente, elegiremos la opción que mejor relación coste/beneficio nos ofrezca. Para calcular los costes de un proyecto de reingeniería, Harry Sneed [Snee 95] propone un modelo basado en cuatro etapas:

Justificación del proyecto de reingeniería.
Análisis de la cartera de aplicaciones.
Estimación de costes.
Análisis de costes / beneficios.

2.4.1 Justificación Del Proyecto De Reingeniería.

Para justificar un proyecto de reingeniería se requiere de un análisis del software existente, de los procesos de mantenimiento actuales y del valor de negocio que tienen las aplicaciones; todo esto con el objeto de hacer una evaluación en posibles aumentos de valores sobre estos tres factores.La mayoría de las organizaciones sólo toman en consideración los procesos de reingeniería cuando el coste de un nuevo desarrollo es demasiado alto. En cualquier caso, y aunque a primera vista parezca la única o la mejor alternativa, es necesario confirmar la necesidad de reconstruir el sistema.

Existen cuatro operaciones que nos pueden dar una idea de los costes del proyecto y del valor del software actual dentro del negocio:

Introducción de un sistema de evaluación de los costes del mantenimiento. Es recomendable que esta tarea la lleve a cabo la organización anticipándose con suficiente anticipación al momento en que se percibe la necesidad de aplicar reingeniería.Análisis de la calidad del software actual, para lo cual pueden utilizarse auditores de código automáticos que proporcionan datos del tamaño, complejidad y métricas de calidad del código fuente. Estos valores son incorporados a una base de datos que es utilizada por otra herramienta para realizar comparaciones y obtener resultados.

Análisis de los costes de mantenimiento: Se proponen tres métricas para medir los procesos de mantenimiento: "Dominio del impacto" o proporción de instrucciones y elementos de datos afectados por una tarea de mantenimiento con respecto al total de instrucciones y elementos de datos del sistema; "Esfuerzo empleado", que es el número de horas dedicadas a tareas de mantenimiento, con lo que se puede obtener una media del número de horas por tarea de mantenimiento; y "Tasa de errores de segundo nivel", que es el número de errores causados por acciones de mantenimiento. Si se observa que estas tres medidas se incrementan, es muy probable que los costes de mantenimiento se incrementen con el tiempo.

para más información ver: http://www.monografias.com/trabajos17/reingenieria-software/reingenieria-software.shtml

Tópicos Avanzados en la Ingeniería de Software

2009-05-14T10:19:00.000-07:00

Ingenieria Web

Roger Pressman[PRE98] moderó una mesa redonda virtual con representantes de la ingeniería software tradicional y del desarrollo software basado exclusivamente en Internet. El debate principalmente se centró en discutir si valía la pena aplicar un proceso de ingeniería a las aplicaciones con base en internet, o qué características tenían éstas que justificaran el no utilizarlo. La conclusión general fue que aplicar un proceso de ingeniería nunca es una mala idea pero que éste debería adaptarse alos requerimientos de cambio continuo y rapidez siempre presentes en el proceso de desarrollo Web. De iniciativas como ésta y de otras como la organización de congresos y talleres especializados en el desarrollo para la Web, surge el nacimiento de una nueva disciplina denominada Ingeniería Web.

Qué es la Ingeniería Web?

Murugesan et al. [MUR01],promotores iniciales del establecimiento, dan la siguiente definición:“Web Engineering is the establishment and use of sound scientific, engineering and managementprinciplesanddisciplinedandsystematic approaches to the successfuldevelopment,deploymentandmaintenance of high quality Web-basedsystems and applications.”Y que escuetamente podemos “traducir” como el proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad. Esta breve definición nos lleva a abordar un aspecto clave de cualquier proyecto como es determinar que tipo de proceso es más adecuado en función de las características del mismo.

El Proceso de Ingeniería Web

Características como inmediatez y evolución y crecimiento continuos, nos llevan a un proceso incremental y evolutivo, que permite que el usuario se involucre activamente, facilitando el desarrollo de productos que se ajustan mucho lo que éste busca y necesita.Según Pressman [PRE00], las actividades que formarían parte del marco de trabajo incluirían las tareas abajo enumeradas. Dichas tareas serían aplicables a cualquier aplicación Web,independientemente del tamaño y complejidad de la misma.Las actividades que forman parte del proceso son:formulación,planificación análisis, modelización,generación de páginas, test y evaluacióndel cliente.

La Formulación identifica objetivos y establece el alcance de la primera entrega. La Planificación generala estimación del coste general delproyecto, la evaluación de riesgos y elcalendario del desarrollo y fechas deentrega.

El Análisis especifica los requerimientos e identifica el contenido.La Modelización se compone de dossecuencias paralelas de tareas. Una consiste en el diseño y producción del contenido que forma parte de la aplicación. La otra, en el diseño de la arquitectura, navegación e interfaz de usuario. Es importante destacar laimportancia del diseño de la interfaz.Independientemente del valor delcontenido y servicios prestados, unabuena interfaz mejora la percepción queel usuario tiene de éstos. En laGeneración de páginas se integra contenido, arquitectura, navegación e interfaz para crear estática o dinámicamente el aspecto más visible delas aplicación, las páginas. El Test busca errores a todos lo niveles: contenido,funcional, navegacional, rendimiento,etc. El hecho de que las aplicacionesresidan en la red, y que interoperen enplataformas muy distintas, hace que elproceso de test sea especialmente difícil. Finalmente, el resultado essometido a la evaluación del cliente.

2.2 Control y Garantía de la Calidad

Una de las tareas colaterales queforman parte del proceso es el Control y Garantía de la Calidad (CGC). Todas las actividades CGC de la ingeniería software tradicional como son:establecimiento y supervisión deestándares, revisiones técnicas formales,análisis, seguimiento y registro deinformes, etc, son igualmente aplicablesa la Ingeniería Web. Sin embargo, en la Web toman especial relevancia para valorar la calidad aspectos como:Usabilidad, Funcionabilidad, Fiabilidad,Seguridad, Eficiencia y Mantenibilidad[OLS01].

2.3 Control de la Configuración

Establecer mecanismos adecuados de control de la configuración para la Ingeniería Web es uno de los mayores desafíos a los que esta nueva disciplina se enfrenta. La Web tiene características únicas que demandan estrategias y herramientas nuevas. Hay cuatro aspectos importantes a tener en cuenta en el desarrollo de tácticas de control de la configuración para la Web [DAR99]:

Contenido:Considerando la dinamicidad con la que el contenido segenera, es tarea compleja organizarracionalmente los objetos que forman laconfiguración y establecer mecanismosde control.

Personal: Cualquiera realizacambios. Hay mucho personal no especializado que no reconoce laimportancia que tiene el control delcambio.

Escalabilidad: Es comúnen contrar aplicaciones que de un día para otro crecen considerablemente. Sin embargo, las técnicas de control no escalan de forma adecuada. Política:¿Quién posee la información? ¿Quién asume la responsabilidad y coste de mantenerla?

2.4 La Gestión del Proceso

En un proceso tan rápido como es el proceso de Ingeniería Web, donde los tiempos de desarrollo y los ciclos de vida de los productos son tan cortos,¿merece la pena el esfuerzo requerido por la gestión? La respuesta es que dada su complejidad es imprescindible. Entre los aspectos que añaden dificultad a la gestión destacamos: - alto porcentaje de contratación a terceros, - el desarrollo incluye una gran variedad de personal técnico y no técnico trabajando en paralelo, - el equipo de desarrollo debe dominar aspectos tan variopintos como,software basado en componentes, redes,diseño de arquitectura y navegación,diseño gráfico y de interfaces, lenguajesy estándares en Internet, test deaplicaciones Web, etc, lo que hace que elproceso de búsqueda y contratación depersonal sea arduo.

3. ¿Qué marca la diferencia?A modo de breve resumen enumeramos las siguientes diferencias: -Confluencia de disciplinas: Sistemas de Información, Ingeniería Software y Diseño Gráfico que requiere equiposmultidisciplinares y polivalentes. –Ciclos de vida y tiempo de desarrollo muy cortos - Cambio continuo:Necesidad de soluciones que permitan flexibilidad y adaptación conforme el proyecto cambia. – Requisitos fuertes deSeguridad, Rendimiento y Usabilidad.

4. ¿Por qué es necesaria?La Web evoluciona y crece sin diseño alguno. Prácticas tan pobres de calidad pueden introducir defectos que dejen al efecto 2000 como un juego de niños. Es deber de todos proporcionar cimientos firmes a una tecnología que“mágicamente” nos permite acceder acualquier hora a cualquier punto del planeta para obtener bienes tan valiosos como son los Servicios y la Información.

para más información ver:

http://www.informandote.com/jornadasIngWEB/articulos/jiw01.pdf

Tópicos Avanzados en la Ingeniería de Software

2009-05-13T09:50:00.000-07:00

Ingenieria Web

¿Qué es?Los sistemas y aplicaciones(WebApps) basados en Web hacen posibleque una población extensa de usuariosfinales dispongan de una granvariedad de contenido y funcionalidadLa ingeniería Web no es un clónico perfectode la ingeniería del software, perotoma prestado muchos de los conceptosy principios básicos de la ingenieríadel software, dando importancia alas mismas actividades técnicas y degestión. Existen diferencias sutiles enla forma en que se llevan a cabo estasactividades, pero la filosofía primordiales idéntica dado que dicta un enfoquedisciplinado para el desarrollo de unsistema basado en computadora.

¿Quiénlo hace? Los ingenieros Web ylos desarrolladores de contenido notécnicos crean las WebApps.

¿Por qué es importante? A medidaque las WebApps se integran cada vezmás en grandes y pequeñas compañías(por ejemplo, comercio electrónico),y cada vez es más importante lanecesidad de construir sistemas fiables,utilizables y adaptables. Esta esla razón por la que es necesario unenfoque disciplinado para el desarrollode WebApps.

¿Cuáles son los pasos a seguir? Aligual que cualquier disciplina de ingeniería,la ingeniería Web aplica. unenfoque genérico que se suaviza conestrategias, tácticas y métodos especializados.El proceso de ingenieríaWeb comienza con una formulación delproblema que pasa a resolverse conlas WebApps. Se planifica el proyecto y se analizan los requisitos de l aWebApp, entonces se lleva a cabo eldiseño de interfaces arquitectónico y del navegador. El sistema se implementautilizando lenguajes y herramientasespecializados asociados conla Web, y entonces comienzan las prues.Dado que las WebApps están ennte evolución, deben de estaelos mecanismos para el controlde configuraciones, garantía decalidad y soporte continuado.

¿Cuál es el producto obtenido? La elaboración de una gran variedad deproductos de trabajo de ingenierfa Web(por ejemplo, modelos de análisis.modelos de diseño, procedimientos depruebas). Y como producto final laWebApp operativa.

¿Cómo puedo estar seguro de quelo he hecho correctamente? Aplicandolas mismas prácticas SQA que seaplican en todos los procesos de ingenieríadel software -las revisiones técnicasformales valoran los modelos deanálisis y diseño-; las revisiones especializadas tienen en consideración la usabilidad y la comprobación se aplicapara descubrir errores en el contenido,funcionalidad y compatibilidad.

Tópicos Avanzados en la Ingeniería de Software

2009-05-13T09:47:00.000-07:00

Ingeniería asistida por computadora

Ingeniería asistida por computadora o por ordenador (CAE, del inglés Computer Aided Engineering) es el conjunto de programas informáticos que permiten analizar y simular los diseños de ingeniería realizados con el ordenador, o creados de otro modo e introducidos en el ordenador, para valorar sus características, propiedades, viabilidad y rentabilidad. Su finalidad es optimizar su desarrollo y consecuentes costos de fabricación y reducir al máximo las pruebas para la obtención del producto deseado.

La mayoría de ellas se presentan como módulos o extensiones de aplicaciones CAD, que incorporan:

· Análisis cinemático.

· Análisis por el método de elementos finitos (FEM, Finite Elements Method).

· Maquinado por control numérico CNC (Computered Numeric Control).

· De exportación de ficheros "Stl" (Estereolitografía) para máquinas de prototipado rápido.

Herramientas Case

De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, lastécnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas.

Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:

Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos.

Herramientas de diseño para dar apoyo al análisis de datos.

Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas concep

tual y lógico.

Herramientas para desarrollar los prototipos de las aplicaciones.

El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos.

Historia

En la década de los setenta el proyecto ISDOS desarrolló un lenguaje llamado "Problem Statement Language" (PSL) para la descripción de losproblemas de usuarios y las necesidades de solución de un sistema de información en un diccionario computarizado. Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relación de problemas y necesidades.

Pero la primera herramienta CASE como hoy la conocemos fue "Excelerator" en 1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT. (Monografías.com)

Tecnología Case

La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo desistemas de información y se plantean los siguientes objetivos:

Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo.

Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.

Simplificar el mantenimiento de los programas.

Mejorar y estandarizar la documentación.

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilización de componentes software.

Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.

Automatizar:

Ø El desarrollo del software

Ø La documentación

Ø La generación del código

Ø El chequeo de errores

Ø La gestión del proyecto

Permitir:

Ø La reutilización del software

Ø La portabilidad del software

Ø La estandarización de la documentación

Componentes de una herramienta case

De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos:

Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.

Meta modelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.

Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.

Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.

Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.

Estructura general de una herramienta case

La estructura CASE se basa en la siguiente terminología:

CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.

CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.

CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.

Estado Actual

En las últimas décadas se ha trabajado en el área de desarrollo de sistemas para encontrar técnicas que permitan incrementar la productividad y elcontrol de calidad en cualquier proceso de elaboración de software, y hoy en día la tecnología CASE (Computer Aided Software Engineering) reemplaza al papel y al lápiz por el ordenador para transformar la actividad de desarrollar software en un proceso automatizado.

La tecnología CASE supone la –informatización de la informática—es decir –la automatización del desarrollo del software--, contribuyendo así a elevar la productividad y la calidad de en el desarrollo de los sistemas de información de forma análoga a lo que suponen las técnicas CAD/CAM en el área de fabricación.

En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos:

<<> Permitir la aplicación práctica de metodologías, lo que resulta muy difícil sin emplear herramientas.

<<> Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.

<<> Simplificar el mantenimiento del software.

Mejorar y estandarizar la documentación.

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilización de componentes de software

Permitir un desarrollo y un refinamiento (visual) de las aplicaciones, mediante la utilización de controles gráficos (piezas de código reutilizables).

Integración de las herramientas case en el futuro

Las herramientas CASE evolucionan hacia tres tipos de integración:

La integración de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos.

La integración de presentación confiere a todas las herramientas CASE el mismo aspecto.

La integración de herramientas permite disponer de herramientas CASE capaces de invocar a otras CASE de forma automática.

Clasificación de las herramientas case

No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:

- Las plataformas que soportan.

- Las fases del ciclo de vida del desarrollo de sistemas que cubren.

- La arquitectura de las aplicaciones que producen.

- Su funcionalidad.

CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo :

1. Las herramientas permiten automatizar el proceso de desarrollo del software.

2. Las metodologías definen los procesos automatizar.

Una primera clasificación del CASE es considerando su amplitud :

TOOLKIT: es una colección de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas.

WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.

Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan:

UPPER CASE: Planificación estratégica, Requerimientos de Desarrollo Funcional de Planes Corporativos.

MIDDLE CASE: Análisis y Diseño.

LOWER CASE: Generación de código, test e implantación

para más información visitar:http://prof.usb.ve/lmendoza/Documentos/PS-6117%20(Laboratorio)/Transparencias%20PS6117%20(Lab)%20HC.pdfhttp://www.virtual.unal.edu.co/cursos/sedes/manizales/4100010/Lecciones/Cap5/HtasCASE.htm
http://www.monouml.org/docs/formal/spanish/x176.html

Tópicos Avanzados en la Ingeniería de Software

2009-05-13T09:40:00.000-07:00

Ingenieria del software del comercio electronico

La computación cliente/servidor es un intento de equilibrar el proceso de una red hasta que se comparta la potencia de procesamiento entre computadoras que llevana cabo servicios especializados tales como accedera bases de datos (servidores), y aquellos que llevan a cabotareas tales como la visualización IGU que es más adecuadopara el punto final dentro de la red. Por ejemplo,permite que las computadoras se ajusten a tareas especializadastales como el procesamiento de bases de datosen donde se utilizan hardware y software de propósitoespecial para proporcionar un procesamiento rápido dela base de datos comparado con el hardware que se encuentra en las mainframes que tienen que enfrentarsecon una gran gama de aplicaciones.

Comercio Electrónico

Para ilustrar la apariencia de un sistema distribuido examinaremosun ejemplo tomado de un área de aplicaciónconocida como comercio electrónico. En un sentidoamplio, el término «comercio electrónico» (Ecommerce)se puede definir como la aplicación de la tecnologíade sistemas distribuidos que apoya las operaciones comerciales.A continuación, se detallan algunos de dichos sistemas:

Sistemas para vender algunos artículos o serviciosutilizando Internet, donde los clientes interactúancon el sistema que utiliza navegadores. Entre lossistemas típicos de comercio electrónico de estacategoría se incluyen los que venden libros, ropay CDs.

Sistemas para simular alguna actividad comercial entiempo real utilizando tecnología de red. Un buenejemplo de este tipo de sistemas es una subasta en lared.Un sistema de subasta típico solicitaría artículosa los usuarios de Internet, ubicaría los datos enuna página Web y entonces comenzaría la oferta para ese artículo. Normalmente la compañía de subastasespecificaría un período de oferta para así darla porfinalizada.

Sistemas que proporcionan algún servicio basado e nred para usuarios. Probablemente los más conocidos son los que ofrecen cuentas de correo gratis, donde los ingresos de dicha empresa probablemente procedan de la publicidad en las páginas Web que se utilizan para ese sitio Web. Estas son compañías quemediante un honorario monitorizan su sitio Web y leenvían un mensaje, normalmente por correo electrónicoo mediante un buscador si han detectado unproblema, como el mal funcionamiento del servidor que se utiliza para el sitio Web.

Sistemas que proporcionan servicios de asesoramiento.Los sistemas típicos de este tipo son los que procesan una descripción de artículos, como un CD,para los que establecerán el mejor precio, despuésde haber explorado un número de sistemas de ventaen la red.

Sistemas internos que el cliente no ve, pero que dansoporte a más actividades comerciales convencionales.Por ejemplo, un sistema que apoya el suministrode mercancías a un comerciante minorista de la calle.Muchos de los ingresos delcomercio electrónico proceden de la publicidad enlínea. Muchas páginas Web asociadas a las aplicaciones de comercio electrónico contendrán pequeñosespacios publicitarios conocidos como banners.Estos anuncios se pueden «pinchar», conduciendoasí al usuario del navegador a un sitio Web el cualnormalmente vende algún producto o servicio.

Los sistemas de publicidad son una forma particular desistemas de comercio electrónico que llevan a cabofunciones tales como vender un banner (espaciopublicitario), monitorizando el éxito de estos anuncios y la administración del pago de los honorariosde publicidad.

Tópicos Avanzados en la Ingeniería de Software

2009-05-13T09:32:00.000-07:00

Métodos Formales

¿Qué es? Estos métodos permiten al ingenierodel software crear una especificaciónsin ambigüedades que sea máscompleta y constante que las que seutilizan en los métodos convencionalesu orientados a objetos. La teoría deconjuntos y las notaciones lógicas seutilizan para crear una sentencia clarade hechos (o de requisitos). Esta especificación matemática entonces sepuede analizar para comprobar quesea correcta y constante. Como esta especificación se crea utilizando notaciones matemáticas. inherentementees menos ambigua que los ncdos informales de presentación.

¿Quién lo hace? Un ingeniero del softwareespecializado crea una especificación formal.

¿Por qué es imporiante? En sistemascríticos para la misión y para la seguridad,un fallo puede pagarse muycaro. Cuando la computadora falla sepueden perder vidas o incluso tenergraves consecuencias económicas. Endichas situaciones es esencial descubrirlos errores antes de poner en operaciónla computadora. Los métodosformales reducen drásticamente los errores de especificación, y consecuentemente son la base del softwareque tiene pocos errores una vez que elcliente comienza a utilizarlo.

¿Cuáles son los pasos? El primer paso en la aplicación de los métodos formaleses definir el invariante de datos, el estado y las operaciones para el funcionamiento de un sistema.El invariante de datos es una condición que se verifica mediante la ejecución de una función que contiene un conjunto de datos. Los datos almacenados forman el estado en donde una función puede acceder y alterar; y las operaciones son las acciones que tienenlugar en un sistema a medida quelee o escribe datos en un estado. Una operación se asocia a dos condiciones:una precondición y una postcondición.La notación y la heurística asociados con los conjuntos y especificaciones constructivas operadores de conjuntos, operadores lógicos y sucesiones- forman la base de losmétodos formales.

¿Cuál es el producto obtenido?Cuando se aplican métodos formalesse produce una especificación representadaen un lenguaje formal como Zo VDM.

¿Cómo puedo estar seguro de quelo he hecho corredamente? Debido a que los métodos formales utilizan la matemática discreta como mecanismo de especificación, para demostrar que una especificación es correcta,se pueden aplicar pruebas lógicas acada función del sistema

Tópicos Avanzados en la Ingeniería de Software

2009-05-13T09:31:00.000-07:00

Métodos Formales

Los métodos formales que se utilizan para desarrollar sistemasde computadoras son técnicas de base matemática paradescribir las propiedades del sistema. Estos métodos formalesproporcionan marcos de referencia en el seno de los cuales laspersonas pueden especificar, desarrollar y verificar los sistemasde manera sistemática, en lugar de hacerlo ad hoc.Se dice que un método es formal si posee una base matemáticaestable, que normalmente vendrá dada por un lenguajeformal de especificación. Esta base proporciona una formade definir de manera precisa nociones tales como la consistenciay completitud, y, lo que es aun más relevante, la especificación,la implementación y la corrección.

La consistencia se asegura mediante una demostración matemática de que los hechos iniciales sepueden hacer corresponder formalmente (mediantereglas de inferencia) con sentencias posteriores existentesdentro de la especificación.

La completitud es difícil de lograr, aun cuando se utilicenmétodos formales. Cuando se está creando la especificaciónse pueden dejar sin definir algunos aspectosdel sistema; quizás otras características se omitan a propósitopara ofrecer a los diseñadores una cierta libertada la hora de seleccionar un enfoque de implementación;además es imposible considerar todos los escenariosoperacionales en un sistema grande y complejo.

Matemáticas en el desarrollo del software

Las matemáticas poseen muchas propiedades útiles paraquienes desarrollan grandes sistemas. Una de las propiedadesmás útiles es que pueden describir de formasucinta y exacta una situación física, un objeto o el resultadode una acción. La situación ideal sería que un ingenierodel software estuviera en la misma situación queun matemático dedicado a la matemática aplicada. Sedebería presentar una especificación matemática de unsistema, y elaborar la solución en base a una arquitecturade software que implemente la especificación.La propiedad fundamental de las

matemáticas es queadmite la abstracción y es un medio excelente para elmodelado. Dado que es un medio exacto, hay pocasprobabilidades de ambigüedad, y las especificacionesse pueden verificar matemáticamente para descubrircontradicciones e incompletitud; y, por último, la vaguedaddesaparece completamente. Además, las matemáticasse pueden utilizar para representar niveles deabstracción en la especificación de sistema de formaorganizada.

Las matemáticas constituyen una herramienta idealpara el modelado. Hacen posible exhibir el esquemafundamental de la especificación y ayudan al analista yespecificador del sistema a verificar una especificaciónpara su funcionalidad, sin problemas tales como el tiempode respuesta, las directrices de diseño, las directricesde implementación y las restricciones del proyectoque siempre estorban. También ayuda al diseñador, porquela especificación de diseño del sistema muestra laspropiedades del modelo, y ofrece tan sólo los detalles suficientes para hacer posible llevar a cabo la tarea quetengamos entre manos.

Para aplicar de forma eficiente los métodos formales,el ingeniero del software debe de tener un conocimientorazonable de la notación matemática asociada a losconjuntos y a las sucesiones, y a la notación lógica quese emplea en el cálculo de predicados.

PARA MAS INFORMACIÓN VER: http://cs.uns.edu.ar/~ads/data/apuntes/ADS-mod%2021.pdf

http://campusvirtual.unex.es/cala/epistemowikia/index.php?title=Introducción_a_los_Métodos_Formales

Tópicos Avanzados en la Ingeniería de Software

2009-05-13T08:17:00.000-07:00

Ingeniería del Software de Sala Limpia

La ingeniería del Software de sala limpia es un enfoque formal para el desarrollo del Software, que pueda dar lugar a un Software que posea una calidad notablemente alta. Emplea la especificación de estructura de cajas (o métodos formales) para el modelado de análisis y diseño, y hace hincapié en la verificación de la corrección, más que en la comprobación, como mecanismo fundamental para hallar y eliminar errores. Se aplica una comprobación estadística de utilización para desarrollar la información de tasa de fallos necesaria para certificar la fiabilidad del Software proporcionado.
La filosofía de sala limpia es un enfoque riguroso de la ingeniería del Software. Se trata de un modelo de proceso del Software que hace hincapié en la verificación matemática de la corrección, y en la certificación de la fiabilidad del Software. El resultado final son unas tasas de fallo extremadamente bajas, que sería difícil o imposible de conseguir empleando unos métodos menos formales.

Tareas de Sala Limpia

La sucesión de tareas de sala limpia para cada incremento, se manifiesta mediante unos requisitos globales del sistema o producto que se van desarrollando empleando los métodos de ingeniería de sistemas. Una vez que se han asignado una funcionalidad al elemento de Software del sistema el tubo de la sala limpia comienza sus incrementos y se producen las siguientes tareas.

- Planificación de Incrementos. La planificación incremental permite calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras el desarrollo progresa. El acercamiento incremental evita los riesgos inherentes integración tardía en el ciclo de desarrollo.

- Recolección de requisitos. El propósito del proceso del análisis de requisitos es 1) definir requisitos para el producto de software, incluyendo función, uso, ambiente, y funcionamiento, y 2) obtener un acuerdo con el cliente en los requisitos como la base para la función y especificación del uso.

- Especificación de la estructura de cajas. Tres tipos especiales de funciones matemáticas son importantes en el desarrollo a Sala limpia, debido a su correspondencia y correlación en el proceso de descomposición y verificación. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposición, además se puede incluir funcionabilidad y orientación a objeto.

- Diseño Formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Dan los objetivos, los participantes, los criterios de entrada, las tareas, la verificación, las medidas y los criterios comunes de la salida en los procesos, así como elementos de proceso común.

- Verificación de Corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección aplicadas primero al diseño y después al código. El propósito del proceso de la verificación de la corrección, es verificar la corrección del incremento del software usando técnicas matemáticas.

- Generación de Código, inspección y verificación. Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen la lengua de programación mas adecuado.

- Planificación de la comprobación estadística, Comprobación estadística de utilización y Certificación. El propósito del proceso estadístico de prueba y de certificación es demostrar la aptitud del software para el uso en un experimento estadístico formal. La "aptitud para el uso" se define con respecto a los modelos de uso y a las metas de la certificación empleados en el proceso de prueba. Las metas de certificación, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en términos tales como índice de confiabilidad del software.

Cajas de Sala Limpia

Una caja encapsula el sistema con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para formar una jerarquía en la cual cada caja tiene una transferencia. Para esto se utilizan tres tipos de cajas:

- Caja Negra. Especifica el comportamiento del sistema, o de una parte de un sistema.

- Caja de Estado. Esta caja encapsula los datos de estados y de servicios (operaciones) de forma análoga a los objetos. En esta vista de especificación, se representan las entradas de la caja de estados y sus salidas.

- Caja Transparente. Las funciones de transición que están implicadas en la caja de estados se definen en la caja transparente.

Verificación de diseño

El diseño que se utiliza en la ingeniería del Software de sala limpia hace mucho uso de la filosofía de programación estructurada. Son realmente las funciones básicas de procesamiento, se refinan ahora utilizando una expansión progresiva de funciones matemáticas en estructuras de conectivas lógicas.

Comprobación de la sala limpia

La técnica y estrategia de la comprobación de la sala limpia es algún fundamentalmente distinto de los enfoques convencionales de comprobación. Los métodos convencionales derivan de un conjunto de casos de prueba para descubrir errores de diseño y codificación.

Diferenciar de Sala Limpia

Existen diversos métodos o paradigmas que nos reflejan la diferencia notoria de que sea sala limpia.

- Hace uso explícito del control estadístico de calidad.

- Verifica la especificación del diseño empleando una demostración de corrección basada en las matemáticas.

- Hace mucho uso de la comprobación estadística de utilización para descubrir errores de especial incidencia.

Métricas, Estimación y Planificación en Proyectos

2009-05-12T17:18:00.000-07:00

Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad.

¿Qué es? El proceso del software y las métricas del producto son una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software y de los proyectos que dirigen utilizando el proceso como un marco de trabajo. Se reúnen los datos básicos de calidad y productividad. Estos datos son entonces analizados, comparados con promedios anteriores, y evaluados para determinarlas mejoras en la calidad y productividad.Las métricas son también utilizadas para señalar áreas con problemas de manera que se puedan desarrollar los remedios y mejorar el proceso del software.

¿Quién lo hace? Las métricas del software son analizadas y evaluadas por los administradores del software. A menudo las medidas son reunidas por los ingenieros del software.

¿Por qué es importante? Si no mides, sólo podrás juzgar basándote en una evaluación subjetiva. Mediante la medición,se pueden señalar las tendencias(buenas o malas), realizar mejores estimaciones,llevar a cabo una verdadera mejora sobre el tiempo.

¿Cuáles son los pasos? Comenzar definiendo un conjunto limitado de medidas de procesos, proyectos y productos que sean fáciles de recoger. Estas medidas son a menudo normalizadas utilizando métricas orientadas al tamaño o la función.El resultado se analiza y se compara con promedios anteriores de proyectos similares realizados con la organización. Se evalúan las tendencias y se generan las conclusiones.

¿Cuál es el producto obtenido? Es un conjunto de métricas del software que proporcionan una visión profunda del proceso y de la comprensión del proyecto.

¿Cómo puedo estar seguro de que lo he hecho correctamente? Aplicando un plan de medición sencillo pero consistente, que nunca utilizaremos para evaluar, premiar o castigar el rendimiento individual.

Métricas, Estimación y Planificación en Proyectos

2009-05-11T17:53:00.000-07:00

Métricas del proyecto

Las métricas del proceso de software se utilizan para propósitos estratégicos. Las medidas del proyecto de software son tácticas. Esto es, las métricas de proyectos y los indicadores derivados de ellos los utilizan un gestor de proyectos y un equipo de software para adaptar el flujo del trabajo del proyecto y las actividades técnicas.La primera aplicación de métricas de proyectos en

la mayoría de los proyectos de software ocurre durante la estimación. Las métricas recopiladas de proyectos anteriores se utilizan como una base desde la que se realizan las estimaciones del esfuerzo y del tiempo para el actual trabajo del software. A medida que avanza un proyecto, las medidas del esfuerzo y del tiempo consumido se comparan con las estimaciones originales (y laplanificación de proyectos). El gestor de proyectos utiliza estos datos para supervisar y controlar el avance.

Se miden los índices de producción representadosmediante páginas de documentación, las horas de revisión,los puntos de función y las líneas fuente entregadas.Además, se sigue la pista de los erroresdetectados durante todas las tareas de ingeniería del software. Cuando va evolucionando el software desde la especificación al diseño, se recopilan las métricas técnicas para evaluar la calidad del diseño y para proporcionar indicadores que influirán en el enfoque tomado para la generación y prueba del código.A medida que mejora la calidad, se minimizan los defectos, y al tiempo que disminuye el número de defectos,la cantidad de trabajo que ha de rehacerse también se reduce. Esto lleva a una reducción del coste global del proyecto.

Mediciones de Software

Las mediciones del mundo físico se pueden categorizar de dos maneras; medidas directas (por ejemplo: la longitud de un tomillo) y medidas indirectas (por ejemplo:la «calidad» de los tomillos producidos, medidos contando los artículos defectuosos). Las métricas del software se pueden categorizar de forma similar.Entre las medidas directas del proceso de la ingeniería del software se incluyen el coste y el esfuerzo aplicados. Entre las medidas directas del producto se incluyen las líneas de código (LDC) producidas, velocidadde ejecución, tamaño de memoria, y los defectos informados durante un período de tiempo establecido.Entre las medidas indirectas se incluyen la funcionalidad,calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento y muchas otras «capacidades» .E l coste y el esfuerzo requerido para construir el software,el número de líneas de código producidas, y otras medidas directas son relativamente fáciles de reunir,mientras que los convenios específicos para la medición se establecen más adelante. Sin embargo, la calidad y funcionalidad del software, o su eficiencia o mantenimientoson más difíciles de evaluar y sólo pueden ser medidas indirectamente.El dominio de las métricas del software se dividenen métricas de proceso, proyecto y producto.

Métricas, Estimación y Planificación en Proyectos

2009-05-10T18:31:00.000-07:00

MÉTRICAS DEL SOFTWARE

Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad,eficiencia.

MÉTRICAS TÉCNICAS: Se centran en lasa características de software pro ejemplo: lacomplejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo esta hecho.

MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a losrequisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema seadapte a los requisitos que me pide el cliente.

MÉTRICAS DE PRODUCTIVIDAD: Se centran en el rendimiento del proceso de la ingeniería delsoftware. Es decir que tan productivo va a ser el software que voy a diseñar.

MÉTRICAS ORIENTADAS A LA PERSONA: Proporcionan medidas e información sobre laforma que la gente desarrolla el software de computadoras y sobre todo el punto de vistahumano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mipersonal que va hará el sistema.

MÉTRICAS ORIENTADAS AL TAMAÑO: Es para saber en que tiempo voy a terminar elsoftware y cuantas personas voy a necesitar. Son medidas directas al software y el proceso porel cual se desarrolla, si una organización de software mantiene registros sencillos, se puedecrear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:

La tabla lista cada proyecto del desarrollo del software de los últimos años correspondientes,datos orientados al tamaño de c/u. Refiriéndonos a la entrada de la tabla del proyecto 999-01 sedesarrollaron 12.1 KLDC (miles de líneas de código) con un esfuerzo de 24personas mes y uncosto de 168 mil dólares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en latabla incluyen todas las actividades de la ingeniería de software como son análisis, diseño,codificación y prueba. Otra información del proyecto 222-01 indica que se desarrollaron 365 paginas mientras que se encontraron 29 errores tras entregárselo al cliente, dentro del primeraño de utilización también sabemos que trabajaron 3 personas en el desarrollo del proyecto.En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puededesarrollar, para cada proyecto un conjunto de métricas sencillas de productividad y calidadorientadas al tamaño. Se obtienen las siguientes formulas:

Productividad = KLDC/persona-mes

Calidad = errores/KLDC

Documentación = pags. Doc/ KLDC

Costo = $/KLDC

· persona-mes es el esfuerzo

MÉTRICAS ORIENTADAS A LA FUNCIÓN:

Son medidas indirectas del software y del procesopor el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función secentran en la funcionalidad o utilidad del programa.Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Lospuntos de función que obtienen utilizando una función empírica basando en medidascuantitativas del dominio de información del software y valoraciones subjetivos de la complejidaddel software.Los puntos de función se calculan rellenando la tabla como se muestra en la siguiente figura:Calculo de métricas de punto de función.

Se determinan 5 características del ámbito de la información y los cálculos aparecen en laposición apropiada de la tabla. Los valores del ámbito de información están definidos de la siguiente manera.

1. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al

software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas

de las peticiones que se contabilizan por separado.

2. Numero de salida del usuario: se encuentra cada salida que proporciona la usuario

información orientada ala aplicación. En este contexto las salidas se refieren a informes,

pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe

se encuentran por separado.

3. Números de peticiones al usuario: una petición esta definida como una entrada

interactiva que resulta de la generación de algún tipo de respuesta en forma de salida

interactiva. Se cuenta cada petición por separado.

4. Numero de archivos: se cuenta cada archivo maestro lógico, o sea una agrupación

lógica de datos que puede ser una parte en una gran base de datos o un archivo

independiente.

5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina

por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir

información a otro sistema.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cadacuenta. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios paradeterminar si una entrada es denominada simple, media o compleja. No obstante ladeterminación de la complejidad es algo subjetivo.Para calcular los puntos de función se utiliza la siguiente relación.

PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]

Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.

Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las

respuestas a las cuestiones señaladas de la siguiente tabla.

Evaluar cada factor en escala 0 a 5.

Seguir leyendo en: http://www.willydev.net/InsiteCreation/v1.0/descargas/willydev_planeasoftware.pdf

Métricas ampliadas de punto de función

La medida de punto de función se diseñó originalmentepara aplicarse a aplicaciones de sistemas de informaciónde gestión. Para acomodar estas aplicaciones,se enfatizó la dimensión de datos (los valores de dominiosde información tratados anteriormente) para laexclusión de dimensiones (control) funcionales y decomportamiento. Por esta razón, la medida del punto defunción era inadecuada para muchos sistemas de ingenieríay sistemas empotrados (que enfatizan función ycontrol). Para remediar esta situación se ha propuestoun número de extensiones a la métrica del punto de funciónbásica.8%CLAVEla extensión de los puntos de función se utilizaen la ingeniería, en las aplicaciones de tiempo realy en las aplicaciones orientadas al control.Una extensión del punto de función es la llamadapuntos de características [JON9 11; es una ampliaciónde la medida del punto de función que se puede aplicara sistemas y aplicaciones de ingeniería del software. Lamedida de punto de característica acomoda a aplicacionesen donde la complejidad del algoritmo es alta.Las aplicaciones de software de tiempo real, de controlde procesos, y empotradas tienden a tener alta complejidadde algoritmos y por lo tanto son adecuadas parael punto de característica. Además,la métrica del punto de característica cuenta una característicanueva del software -los algoritmos-. Un algoritmo se define como un problema de cálculo limitado que se incluye dentro de un programa de computadoraespecífico. Invertir una matriz, decodificaruna cadena de bits o manejar una interrupción son ejemplos de algoritmos.

Leer más en : http://www.willydev.net/InsiteCreation/v1.0/descargas/willydev_planeasoftware.pdf

Métricas para la calidad de software

2009-05-09T19:16:00.000-07:00

El objetivo primordial de la ingeniería del software es producirun sistema, aplicación o producto de alta calidad.Para lograr este objetivo, los ingenieros del software debenaplicar métodos efectivos junto con herramientas modernasdentro del contexto de un proceso maduro de desarrollode software. Además, un buen ingeniero del software(y buenos gestores de la ingeniería del software) debenmedir si la alta calidad se va a llevar a cabo.La calidad de un sistema, aplicación o producto estan bueno como los requisitos que describen el problema,el diseño quc modcla la solución, el código que conducea un programa ejecutable, y las pruebas queejercitan el software para detectar errores. Un buen ingenierodel software utiliza mediciones que evalúan lacalidad del análisis y los modelos de diseño, el códigofuente, y los casos de prueba que se han creado al aplicarla ingeniería del software. Para lograr esta evaluaciónde la calidad en tiempo real, el ingeniero debe utilizar medidas técnicas que evalúa nla calidad con objetividad, no con subjetividad.Se puede encontrar una excelente fuente de informociónsobre la calidad del software y ternos relacionados(incluyendo métricas) en: www.quol¡tyworld.comEl gestor de proyectos también debe evaluar la calidad objetivamente, y no subjetivamente. A medida que el proyecto progresa el gestor del proyecto también debeevaluar la calidad. Las métricas privadas recopiladas poringenieros del software particulares se asimilan para proporcionarresultados en los proyectos. Aunque se puedenrecopilar muchas medidas de calidad, el primer objetivoen el proyecto es medir errores y defectos. Las métricasque provienen de estas medidas proporcionan una indicaciónde la efectividad de las actividades de control y de la garantía de calidad en grupos o en particulares.

Medida de la calidad

Aunque hay muchas medidas de la calidad de software,la corrección, facilidad de mantenimiento, integridad,y facilidad de uso proporcionan indicadores Útilespara el equipo del proyecto. Gilb [GIL881 ha sugeridodefiniciones y medidas para cada uno de ellos.Corrección. Un programa debe operar correctamenteo proporcionará poco valor a sus usuarios. Lacorrección es el grado en el que el software lleva acabo su función requerida. La medida más común decorrección es defectos por KLDC, en donde undefecto se define como una falta verificada de conformidadcon los requisitos.Facilidad de mantenimiento. El mantenimientodel software cuenta con más esfuerzo que cualquierotra actividad de ingeniería del software. La facilidadde mantenimiento es la facilidad con la que sepuede corregir un programa si se encuentra un error,se puede adaptar si su entorno cambia, o mejorar siel cliente desea un cambio de requisitos. No hayforma de medir directamente la facilidad de mantenimiento;por consiguiente, se deben utilizar medidasindirectas. Una simple métrica orientada altiempo es el tiempo medio de cambio (TMC), es decirel tiempo que se tarda en analizar la petición de cambio,en diseñar una modificación adecuada, en implementarel cambio, en probarlo y en distribuir elcambio a todos los usuarios. Como media, los programasque se pueden mantener tendrán un TMCmás bajo (para tipos equivalentes de cambios) quelos programas que no son más fáciles de mantener.Hitachi [TAJS 11] ha utilizado una métrica orientadaal coste para la capacidad de mantenimiento llamada«desperdicios» -e1 coste en corregir defectosencontrados después de haber distribuido el softwarede un sistema para resistir ataques (tanto accidentalescomo intencionados) contra su seguridad. El ataquese puede realizar en cualquiera de los tres componentesdel software: programas, datos y documentos.Para medir la integridad, se tienen que definirdos atributos adicionales: amenaza y seguridad.Amenaza es la probabilidad (que se puede estimaro deducir de la evidencia empírica) de que un ataquede un tipo determinado ocurra en un tiempodeterminado. La seguridad es la probabilidad (quese puede estimar o deducir de la evidencia empírica)de que se pueda repeler el ataque de un tipodeterminado. La integridad del sistema se puededefinir como:integridad = C [( 1 - amenaza) x (1 - seguridad)]donde se suman la amenaza y la seguridad para cadatipo de ataque.Facilidad de uso. El calificativo «amigable con elusuario» se ha convertido en omnipresente en las discusionessobre productos de software. Si un programano es «amigable con el usuario», frecuentemente estáabocado al fracaso, incluso aunque las funciones querealice sean valiosas. La facilidad de uso es un intentode cuantificar «lo amigable que puede ser con el usuario» y se puede medir en función de cuatro características:(1) habilidad intelectual y/o física requeridapara aprender el sistema; (2) el tiempo requerido parallegar a ser moderadamente eficiente en el uso del sistema;(3) aumento neto en productividad (sobre elenfoque que el sistema reemplaza) medida cuandoalguien utiliza el sistema moderadamente y eficientemente;y (4) valoración subjetiva (a veces obtenidamediante un cuestionario) de la disposición de losusuarios hacia el sistema.Los cuatro factores anteriores son sólo un ejemplode todos los que se han propuesto como medidas de lacalidad del software.

Factores económicos y humanos de la Ingeniería de Software

2009-04-12T14:30:00.000-07:00

Peopleware: El Individuo

De forma telegráfica:

- Ya hemos visto los perfiles preferidos de trabajadores.

-Tener un bajo CI es casi sinónimo de fracaso en la vida económica y de trabajos mal pagados.

- Pero un alto CI no es predictor de éxito, excepto en el ámbito académico occidental puro. De hecho, hay un elevado porcentaje de fracasos en la vida de los reputados como más "inteligentes", es algo que se comprueba cotidianamente.

Los fracasos en la vida no significan solamente fracasos en el trabajo ,si no fracaso en las relaciones humanas, ansiedad, depresión, y otros problemas sociales.

-Sin llegar a hablar de fracasos , ¿no estamos cansados de ver cómo con mucha frecuencia los mejores ingenieros, médicos, artistas, hombres de negocios, etc., no eran en la escuela o universidades ni mucho menos los mejores? Y viceversa.

¿Qué factores le faltan al CI?

Capacidad de motivarnos a nosotros mismos
capacidad de perseverar en el empeño por encima de frustraciones.
Capacidad de controlar inpulsos.
Capacidad de diferir las gratificaciones.
Capacidad de regular nuestros estados de ánimos.
Capacidad de evitar la angustia interfiera con nuestras facultades racionales.
Capacidad de Empatizar con los demás.
Capacidad de resolver conflictos.
Capacidad de "leer" la situación social.
Etc.

Inteligencia racional

Recordemos: La teoría factorial de la inteligencia (incluye capacidades en los campos psicomotor y perceptivo, no estrictamente relacionados con lo racional, aunque todas con el neocórtex).

-Lo racional tiene que ver sobre todo con las aptitudes verbales y lógico-matemáticas, núcleo del paradigma de inteligencia en la cultura occidental.

-Las tres erres, en el mundo anglosajón, representan el trío de aptitudes verbales y matemáticas(lectura,escritura,cálculos). que constituyen la base de la educación tradicional y occidental.

Pensamiento convergente/pensamiento divergente

Los factores que forman el campo del razonamiento (que algunos llaman Inteligencia Formal), o sea el factor R, el de deducción (D), el de Inducción (I) y alguno más en el modelo factorial, constituyen el pensamiento convergente.Son los que facilitan las actividades intelectuales en que se buscan soluciones habituales, previsibles y lógicamente necesarias, dadas determinadas premisas. Existe otro ámbito, llamado por Guilford pensamiento divergente, que incluiría factores, todavía mal conocidos que apuntan hacia aptitudes para descubrir nuevos modos de concebir las cosas, para ser original. Entre otros, puede citarse:

fluidez
flexibilidad
creatividad
Originalidad.

¿Tiene relaciones los factores de pensamientos divergentes con algunas zonas del hemisferio cerebral derecho, el menos usado y ejercitado? Parece que sí.

Inteligencia emocional

Según Goleman, la inteligencia emocional es la aptitud maestra, la que abre/cierra y potencia/bloquea todas las demás aptitudes. Goleman no es el descubridor de la I.E pero es su mayor divulgador.

• El nombre de inteligencia emocional fue propuesto por Peter Salovey, de la Universidad de Yale, hacia 1990. Que el concepto de inteligencia -por otro lado, nunca cerrado para la ciencia en general y para la psicología en particular- es más amplio de lo que hasta hace pocos años se reconocía, se recoge en este extracto de José Antonio Marina "Teoría de la Inteligencia Creadora", Anagrama, 1993: "La inteligencia es mucho más que hacer razonamientos o resolver problemas formales. Dirigir la motivación, construir la propoia libertad, llevar habilmente la negociación con nuestras limitaciones, todo eso es inteligencia humana".

Factores económicos y humanos de la Ingeniería de Software

2009-04-12T12:27:00.000-07:00

Peopleware: el Grupo

Cuatro arquetipos organizativos de los equipos de proyectos

Las técnicas de gestión de equipos humanos han adquirido extremada importancia, debido a la forma actual de trabajar.Por ejemplo, uno de los conceptos más conocidos es cómo afecta el estilo de mando de un jefe de equipo formado por un grupo pequeño de componentes humanos (inferior a 10) al comportamiento del grupo. El experimento más divulgado es el que considera tres estilos de mando del jefe (responsable de la cohesión y dirección del equipo) y extrae sus respectivas consecuencias sobre los resultados de la actividad conjunta y las relaciones de sus componentes.

Mando: Autoritario.

Comportamiento grupo: Agresivo/rebelde o apático/sumiso, según caracteres de sus componentes

Resultados: Mejora de rendimiento a corto plazo. Formación de objetivos propios de los individuos. Descenso de rapidez y calidad. Malestar psíquico.

Mando: Democrático.

Comportamiento grupo: Personal y más amistoso. Se valoran cualidades individuales y aceptan intereses comunes.

Resultados: Se mantiene nivel de actividad aún sin jefe presente. Decisiones más vinculantes. Se favorece el desarrollo personal.

Mando: Pasota (laissez faire)

Comportamiento grupo: Mejora creatividad. Desarrollo individualismo. Falta de responsabilidad.

Resultados: Favorece creatividad e imaginación. Desaparece conciencia de grupo. Relega trabajo duro. Surge líder.

Modelo de Constantine

Un arquetipo es un modelo idealizado que reúne un conjunto de características en estado puro. La realidad siempre presentará situaciones mixtas de varios de estos arquetipos, convertidos así en elementos referenciales que ayudan a comprender mejor la realidad.

Lo que nos interesa resaltar en este modelo es el tipo de formas de coordinación y control (incluyendo el tipo de liderazgo), que, aplicadas sobre unos componentes humanos adecuados al arquetipo, tienen la capacidad de desarrollar unos procesos productivos encaminados a unos determinados requerimientos de proyecto. Dicho con otras palabras, cada arquetipo tiene (o requiere) una estructura de componentes humanos y un estilo de mando (liderazgo, en general, métodos, estilos y objetivos de decisión, de coordinación y trabajo) y genera un tipo de proyecto. En un sentido constructivo, esta proposición se puede formular al revés: Los requerimientos de cada proyecto determinan unos requerimientos para diseñar el equipo adecuado, elegir el arquetipo más conveniente o un híbrido.

La conclusión es que cada proyecto concreto requiere diseñar la arquitectura humana del equipo encargado, y ésa es una función que compete al jefe del equipo. Cada proyecto de software es distinto, pero por lo general implica capacidades de solución de problemas complejos, con dosis de innovación y creatividad, pero también considerables dosis de rutina y administración. Un proyecto real tiene varias fases, en las que se involucran distintos equipos con características diferenciadas.

Chief Programmer Team

Es un ejemplo clásico de diseño de arquitectura humana, que se conoce por las siglas CPT. Se utilizó en un proyecto muy técnico y muy famoso de IBM para el New York Times. El equipo va cambiando en su composición numérica a medida que se desarrollan las fases del proyecto, pero siempre alrededor de una estructura fija, gráficamente expresada en el esquema.

Consta de los siguientes elementos:

1. Un programador jefe y el programador jefe reserva. El primero es el responsable del proyecto, del diseño total del sistema y de la programación de los principales programas. El segundo supervisa el trabajo del anterior y revisa completamente su programación. Le sustituye en caso de ausencia.

2. Un administrador del proyecto, que descarga al programador jefe de las tareas administrativas.

3. Un instrumentalista, responsable de poner a punto las herramientas de software necesarias para soportar el proyecto.

4. Un editor de documentación, que toma la documentación del proyecto escrita por el programador jefe y su reserva y la prepara para publicación.

5. Un experto en los lenguajes y sistemas utilizados en el proyecto, cuyo papel consiste en aconsejar a los jefes sobre la forma de optimizar su uso.

6. Un probador, que genera casos de prueba para validar el trabajo del programador jefe.

7. Uno o más programadores de soporte, encargados de codificar diseños preparados por el programador jefe. Estos programadores son necesarios siempre, dado que la escala de cualquier proyecto implica que el programador jefe y su reserva no pueden cargar con toda la programación requerida.

Fácilmente se ve que esta astuta solución, en la que se han repartido papeles de forma que se aprovechan mejor las capacidades que normalmente se manifiestan en personas de perfiles diferentes, no encaja con ninguno de los arquetipos vistos. En todo caso podría parecer una arquitectura híbrida entre los modelos abierto y cerrado, con más dosis del primero que del segundo, pero sin olvidar que el equipo contiene una jerarquía muy fuerte (técnica y de mando, a la vez), que se materializa en la misma persona.

Aspectos sobre la coordinación

Hay muchos motivos por los que los proyectos de software pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendoa complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incertidumbrees corriente, dando como resultado un continuo flujo de cambios que impactan al equipo del proyecto.La interoperatividad se ha convertido en una característicaclave de muchos sistemas. El software nuevo debecomunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.

Factores económicos y humanos de la Ingeniería de Software

2009-04-12T12:07:00.000-07:00

Orgware, manageware, peopleware

Hoy, la actividad de las empresas tiende a organizarse en forma de procesos. Los procesos productivos, que en la jerga empresarial a menudo se llaman procesos de negocio, integran procesos tecnológicos y éstos a su vez se montan por el trabajo, la aplicación de conocimientos y la cooperación de individuos organizados en maneras diversas. Todos estos últimos elementos constituyen los que pudieran denominarse procesos psico-socio-económicos.

Puestos a poner nombres a los distintos tipos de recursos que constituyen el capital intelectual explícito de una empresa que usa y gestiona esta pirámide de procesos, resulta bastante nemotécnico llamar Orgware al conjunto de recursos que forman los procesos psicosocioeconómicos, Hardware y Software a los recursos para los procesos tecnológicos (o técnicos) y Produware a los recursos que se aplican para crear y actualizar los procesos productivos. Unos minutos de reflexión nos convencerán de que todos los recursos citados deberían constituir el objeto de una compleja tarea de Gestión del Conocimiento, que va mucho más allá de una mera base de datos sobre cualificaciones del personal.

Según como se miren las cosas, en el orgware pueden distinguirse convencionalmente otros dos aspectos, tales como el manageware, que se ocupa más específicamente de tareas de gestión, planificación y gestión, tareas compuestas por un variado abanico de técnicas y métodos, y como el peopleware, cuya atención está más polarizada al factor humano propiamente dicho, tanto en su versión de grupo como de individuo. Al peopleware, reducido a su faceta intelectual, se le podía llamar brainware, aunque esa sería una visión reduccionista ignorante de sus facetas de ser social. El peopleware, por tanto, resumiría los conocimientos y técnicas enfocados a lo que, desde el punto de vista empresarial, es el capital humano: en términos prácticos, la selección, formación y gestión de personal.

Un ejemplo de perfil de empleado más buscado

En el año 1998, el grupo Europa 500 y el IESE elaboraron mediante encuestas un perfil del trabajador más buscado y de más éxito para una empresa moderna (no tecnológica). Véase:

• Formación general y conocimientos informáticos (34).

• Capacidades de comunicación (40).

•Habilidad para resolver problemas (42).

•Capacidad para trabajar en equipo (52).

•Iniciativa personal (54).

•Lealtad (57).

•Orientación al cliente (58).

Llaman la atención varios aspectos. Ahora parecen interesar más capacidades que no entran en el concepto de cociente intelectual. Se enfatiza mucho la capacidad de integrarse en grupos de trabajo. El cliente es el rey, todo el poder reside en una mentalidad orientada al mercado.

Para más información: http://api.ning.com/files/1hjSKWZVcZyhHIsOcGjfdtCPcvLP62Kc1WQDxB2HOxLZbIGdcFfItBxWQtIcb5BCAjSSxJDATqjBKBzDwbgpxIPpE62MTWMI/ingenieria_del_software_factores_economicos_y_humanos.pdf

Factores económicos y humanos de la Ingeniería de Software

2009-04-12T11:47:00.000-07:00

Gestión del Conocimiento

La gestión de los conocimientos, al igual que la innovación, tiene que ser una actividad importante en una empresa, según palabras de Peter Drucker. Requiere un cambio cultural profundo en la empresa, además de un soporte tecnológico adecuado. Por lo tanto, es un proceso lento y requiere cierto tiempo para conseguir resultados. Es decir, debe ser considerado más como un camino a seguir que como una solución rápida. Hoy, están de moda en el campo de la gestión de empresas las organizaciones basadas en el conocimiento ya que vamos hacia una sociedad del conocimiento .

El conocimiento como activo. Capital intelectual.

Las cinco organizaciones con mayor cotización en Wall Street tienen un valor, en media, 13 veces superior a su valor contable. Esta aparente paradoja se explica fácilmente teniendo en cuenta que en el valor contable tradicional de la empresa no se incluyen ciertas capacidades ocultas de la organización.

El conocimiento, o capital intelectual, es considerado como activo y por eso podríamos llamarlo brainware- presenta una serie de características diferenciadoras del resto de recursos que hacen que su desarrollo no tenga perspectivas de estancarse. Dichas características son:

El conocimiento explícito es abundante.
No está limitado por modos ni formas.
No está limitado por el espacio.
No es consumido por su uso.

El conocimiento explícito es abundante.

•No está limitado por modos ni formas.

•No está limitado por el espacio.

•No es consumido por su uso.

La aparición del conocimiento como recurso fundamental abre las puertas de la que se ha dado en llamar la Sociedad del Conocimiento, claramente diferenciada del período anterior en el que el conocimiento era mucho menos reconocido y valorado. Lógicamente, cada día que pasa los humanos han de saber más cosas para ocupar cualquier puesto de trabajo o desarrollar cualquier función social. Este recurso tan abundante y que crece por momentos necesita, para ser operativo, de un proceso de explotación, y este proceso es la gestión del conocimiento.

Llegados a este punto, después de ver la importancia del capital intelectual como activo, nos podemos preguntar, ¿pero qué es exactamente el capital intelectual?.

Como definición un tanto generalista podríamos decir que es la suma de lo que toda la gente en una compañía sabe y que puede darle a dicha empresa un perfil competitivo. Esta definición es muy generalista, porque, como se verá enseguida, será preciso incluir varios otros factores que, en la terminología de Edvinsson, se agrupan bajo el rótulo de “capital estructural”.

El significado de cada capital es el siguiente:

• Capital Intelectual: “Conocimiento convertido a valor (mercado)”.

•Capital Humano: “La competencia y las capacidades de los empleados”.

•Capital Estructural: “Lo que queda cuando los empleados se van a casa”. Por ejemplo, bases de datos, marca y estructura organizativa.

•Capital de Clientes: “El valor de las relaciones de la compañía con los clientes”.

•Capital Organizativo: “Competencia y capacidades sistematizadas o empaquetadas”.

• Capital de Innovación: “Propiedad intelectual, derechos comerciales, otros activos intangibles”.

• Capital de Procesos: “El valor combinado de los procesos que crean sistemas”.

Para más Información:http://api.ning.com/files/1hjSKWZVcZyhHIsOcGjfdtCPcvLP62Kc1WQDxB2HOxLZbIGdcFfItBxWQtIcb5BCAjSSxJDATqjBKBzDwbgpxIPpE62MTWMI/ingenieria_del_software_factores_economicos_y_humanos.pdf

Factores económicos y Humanos de la Ingeniería de Software

2009-04-11T08:53:00.000-07:00

Complejidad del Software

El tamaño de los problemas resueltos por software ha ido evolucionando desde los pequeños hasta los muy grandes, y este cambio de escala ha traído importantes cambios de complejidad, que, por un lado, afectan sin duda a las técnicas, pero que van mucho más allá y comprenden desde la naturaleza misma de los problemas, hasta la variedad multidisciplinar de los aspectos y áreas involucrados en los procesos DDE.

Años 60: Programación a pequeña escala: Programas comprensibles. Uso de lenguajes de alto nivel.

Años 70: Programación a gran escala: Persisten las dificultades de la programación a pequeña escala, a las que se une un incremento del orden de magnitud de la complejidad. Necesidad de organizar largos proceso de desarrollo. Herramientas.

Años 80 y 90: Programas-componentes de sistemas heterogéneos y Programas-delegados: Se construyen piezas de software integrables en sistemas formados por toda clase de componentes físicos y humanos, diferentes lenguajes, constricciones temporales o materiales, etc. Porciones creativas del proceso del desarrollo y control de los sistemas de software son delegadas en ciertas funciones de software.

En los primeros años de los 80, cuando estaba en pleno auge la programación a gran escala y cuando ya se aceptaba que era necesario desarrollar y potenciar un conjunto de técnicas agrupadas bajo la denominación de “Ingeniería del Software”, se hizo una encuesta muy completa para resaltar la importancia de su parcela gerencial (management). Los resultados se publicaron en un informe y diversos artículos con el título de “El reto de la gestión de proyectos de ingeniería del software (S.E.P.M.: Software Engineering Project Management). Algunos de los problemas al tiempo más importantes y para las que los responsables de proyectos se sentían más desasistidos fueron:

- Definir requisitos del sistema

- Establecer criterios de éxito en el proceso de desarrollo

- Planificar proyectos de desarrollo

- Estimar costes

- Definir calendario de actividades

- Fijar estructura de rendición de cuentas y responsabilidades

- Seleccionar jefes de proyectos o subproyectos

- Establecer (definir, elegir) técnicas de control de fiabilidad del software

- Establecer (definir, elegir) técnicas y estándares de medida de la cantidad/calidad de producción de programadores y analistas.

Modelo CMM

El Capability Maturity Model es una norma de calidad y experiencia técnica y de gestión de los equipos y organizaciones dedicadas al desarrollo de software. Ha sido elaborado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (U.S.A.). Sólo a partir del nivel 2 puede decirse que se entra en un nivel de profesionalidad. En U.S.A., para conseguir contratos de desarrollo con departamentos de la Administración es imprescindible que las empresas o equipos aspirantes tengan reconocido un nivel especificado del CMM.

Código ACM de ética y práctica profesional

Creemos que todo ingeniero de software debería leer este código y reflexionar sobre él. El código ACM/IEEE-CS, elaborado, tras muchas reuniones, consultas y versiones, por un selecto grupo de profesionales convocados por las dos sociedades profesionales más importantes, contiene 8 principios deontológicos, que desarrollan una serie de puntos cada uno de ellos. El código no tiene ningún poder regulador, su fuerza reside en su aceptación práctica como guía de sus actividades por parte de los profesionales de estas técnicas.

Fíjese el lector que incluso el apartado de Gestión contiene aspectos relacionados con la ética.

Link:http://api.ning.com/files/1hjSKWZVcZyhHIsOcGjfdtCPcvLP62Kc1WQDxB2HOxLZbIGdcFfItBxWQtIcb5BCAjSSxJDATqjBKBzDwbgpxIPpE62MTWMI/ingenieria_del_software_factores_economicos_y_humanos.pdf

Factores económicos y Humanos de la Ingeniería de Software

2009-04-10T13:58:00.000-07:00

Software Capital Intelectual de la empresa

Hoy, más que nunca, la economía más productiva depende de la infraestructura y los sistemas técnicos. Dentro de este panorama, la infotecnología, por ella misma y por su papel instrumental en las demás tecnologías, juega un rol principal. Y dentro de la infotecnología, el software siempre está presente.

Hay una forma brutal de comprender esta función, mirando su lado oscuro, observando por ejemplo lo que sucede cuando alguna pieza de software, por error, avería o sabotaje, decae bruscamente, falla, se interrumpe o se bloquea. Las consecuencias económicas pueden ser muy importantes, cuando no desastrosas, valorables en miles de millones de dólares en todo el mundo, monto que no hace más que aumentar debido a la creciente capilaridad de la informática.

Pero, más allá del plano económico, lo peor es que, a veces, las consecuencias afectan a una parte más general del flujo de actividades sociales, incluyendo pérdidas de vidas humanas, lo que demuestra la trascendental clase de rol que juega el software en las sociedades desarrolladas.

el conjunto de conocimientos precisos para desarrollar software es algo difícilmente disponible y por ello el proceso de acopiarlo, estructurarlo e implementarlo es un proceso de descubrimiento y de diálogo, es decir, de aprendizaje. No es éste un proceso individual, sino un entramado de procesos individuales, porque interviene mucha gente con diferentes intereses y especialidades, trabajando generalmente en grupos, que intercambian conocimientos, aprendiendo unos de otros.

• Se requiere un diálogo entre el equipo de diseño y los usuarios, entre otras cosas para descubrir y definir los requisitos. Es preciso que los usuarios se apliquen a comprender mejor lo que necesitan.

•

Planteando que el diseño mismo ha de ser evolutivo, debería haber un diálogo entre el equipo de diseño y el diseño propiamente dicho, lo mismo que entre los usuarios y el diseño

Los desarrolladores deben trabajar para comprender mejor cómo construir sus sistemas de forma efectiva.

•

El aprendizaje se potencia en la medida en que las herramientas de desarrollo ayuden a diseñadores y programadores a comprender mejor lo que están haciendo. Estas herramientas deberían estar construidas como herramientas para pensar.

•

Al mismo tiempo, se requieren herramientas que contribuyan al proceso de comunicación interpersonal, puesto que estamos comprometidos en un proceso social de aprendizaje o construcción colectiva de conocimiento.

Desde un punto de vista económico, mantener software significa aportar esfuerzos (costes) para conservar y, si es posible, acrecentar el valor de este bien de capital. Pero dado que, como se dijo, la estructura del capital de producción cambia constantemente, el diseño de bienes de capital debe evolucionar para encajar con las nuevas estructuras del capital, y, aún mejor, debería contener el embrión de los cambios previsibles. Esta estrategia del embrión es imprescindible para minimizar los esfuerzos (tiempo, costes) necesarios para hacer evolucionar el software.

En el caso del software, una parte importantísima de la estructura de capital es la tecnología conexa: sistemas operativos, plataformas de hardware, capacidades de red, otros sistemas y herramientas de software, los progresos de orden metodológico, etcétera. Sus cambios implican un cambio del entorno propio del ciclo de vida del software. Así, el cambio del software es coevolutivo con su entorno propio y en buena medida es impredecible. Tome nota el lector de que un peligro difícil de evitar es el de buscar la optimización del software desarrollado con respecto a algún apartado muy concreto del entorno, por ejemplo, el sistema de gestión de base de datos. Tal proceder puede ir en contra de la evolutividad de este software, teniendo en cuenta que el software es un bien duradero, de desarrollo lento y muy costoso.

Link:http://api.ning.com/files/1hjSKWZVcZyhHIsOcGjfdtCPcvLP62Kc1WQDxB2HOxLZbIGdcFfItBxWQtIcb5BCAjSSxJDATqjBKBzDwbgpxIPpE62MTWMI/ingenieria_del_software_factores_economicos_y_humanos.pdf

Historia de la gestión de Proyectos

2009-04-10T13:53:00.000-07:00

En la década del 50 no se tenía metodología. La computación era incipiente. Neos diferenciaba bien entre software y hardware. Esta situación continúo hasta comenzada la siguiente década

En la década del 60 ocurre la primera gran crisis de la gestión de proyectos de software: la crisis del OS/360. La nueva línea de computadores de IBM, la líneas/360 planteo, por primera vez. La realización de un paquete de programación de tamaño mediano. Hasta este momento puede decirse que todos los proyectos eran pequeños, o si bien eran medianos se habían hecho en ambientes universitarios sin preocuparse por plazos y costos.

Con el sistema operativo de /360 IBM desborda todos los plazos y costos imaginables. De este primer gran atraso (que no fue el único atraso en la entrega de software,) nace la gestión de proyectos.

La década del 70 se caracteriza por la realización de los grandes estudios empíricos. La difusión de las computadoras y la aparición de las minicomputadoras hacen que se disponga de muchos proyectos medianos y grandes. Con todo este material empírico se hacen gran cantidad de estudios. De estos estudios nacen modelos y metodologías

La década de 80 es el periodo de confrontación de los modelos e metodología con los grandes proyectos de software. Es paradojal, pero la difusión de las computadoras personales hace que los proyectos sean más complejos y exigentes. De todas estas tecnologías sobreviven solamente unas pocas de la confrontación con la realidad.

La década del 90, es la época de normalización de las metodologías. Ya se ha separado lo útil de la teórico, lo bueno de lo malo y se procede a normalizar las metodologías

Gestión de Proyectos

2009-04-10T13:50:00.000-07:00

Tamaño de los proyectos

Los proyectos de software son diferentes por la sola razón de su tamaño. Por lo que existen tres categorías diferenciadas de proyectos con problemas diferentes cada una:

Proyectos pequeños: conciten solamente en implementación. No tienes costos indirectos importantes.

Proyectos grandes: posees implementación, pero hay más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera información para mercadeo.

Proyectos medianos: es un caso intermedio entre los otros dos.

Un error clásico en la historia de la gestión de proyectos fue no advertir la existencia de tres categorías diferentes. Todavía hoy se sigue pensando que la información o la experiencia adquirida en proyectos pequeños pueden servir para proyectos medianos o grandes. Este es uno de los orígenes del los resultados catastróficos en la gestión de proyectos

Gestión de Proyectos de Software

2009-04-10T13:31:00.000-07:00

Dentro de la Ingeniería la gestión o control de proyecto básicamente engloba las mismas características independientemente de la rama que se escoja o el ángulo desde el cual se mire, Los primero es determinar cual es el objetivo que es lo que queremos alcanzar con tales fines, y luego que ha finalizado, lo que se quiere es analizar que sucedió con el proyecto ya finalizado.

Y las preguntas o interrogantes numérica cuáles son? Las mismas básicamente para todos los casos.

1.- En cuanto tiempo estará listo?

2.- Que personal y cuantos en total necesito?

3.- Cuanto me cuesta eso?

Ahora bien en el plano particular de la gestión de proyectos de software, es una rama de la ingeniería de Software, que posee su propia metodología además de la generales de la ingeniería normal.

Las gestiones dentro de un proyecto de software deben realizarse según el tipo de proyecto que se plantee, entre los cuales se encuentran:

Los proyectos nuevos: es por supuesto el más complicado por todo lo que implica un proyecto nuevo.

Replanteo de proyectos viejos: se busca corregir y actualizar la metodología de estimación.

Extensión o ampliación de un proyecto existente: para esta tipo de proyecto lo que se busca es tener buena precisión entre costos y plazos de ejecución.

Introducción a la Ingenería de Software

2009-02-19T13:04:00.000-08:00

Tecnología de Procesos

Las herramientas de tecnología de procesos permiten que una organización de software construya un modelo automatizado del marco de trabajo común de proceso, conjuntos de tareas y actividades de protección. Una vez que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de tecnología de procesos para asignar, supervisar e incluso controlar todas las tareas de ingeniería del software definidas como parte del modelo de roceso. Cada uno de los miembros de un equipo de proyecto de software puede utilizar tales herramientas para desarrollar una lista de control de tareas de trabajo a realizarse, productos de trabajo a producirse, y actividades de garantía de calidad a conducirse.

Introducción a la Ingeniería de Software

2009-02-19T11:48:00.000-08:00

Técnicas de Cuarta Generación

El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al ingeniero del softwarela especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa. Esta técnica esta enfocada con la finalidad de especificar el softwre usando lenguajes especializados o notaciones gráficas que describa el problema que hay que resolver en términos que los entienda el cliente.

T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. debido a que el cliente puede que no esté seguro de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos, y puede que no sea capaz o no esté dispuesto a especificar la información en la forma en que puede aceptar una herramienta T4G. Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G). Sin embargo, es necesario un mayor esfuerzo para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G.Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar con sentido una documentación y ejecutar el resto de las actividades de integración que son también requeridas requeridas por otros paradigmas de ingeniería del software. Además, el software desarrollado con T4G debe ser construido de forma.Este modelo tiene ventajas y desvantajas.Los detractores ducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido portales herramientas es «ineficiente» y que el mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.
Sin embargo, posee algunos méritos como lo son:

1. El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación, T4G
ofrece una solución fiable a muchos problemas del software.
2.El uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del software), para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación.

Cuando se combinan con enfoques de ensamblaje de componentes el paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.

Introducción a la Ingeniería de Software

2009-02-12T13:58:00.000-08:00

El modelo de métodos Formales

El modelo de métodos formales comprende un conjunto de actividades que conducen a las especificaciones matemática del software de computadora. Cuando se utilizan métodos formales durante el desarrollo, proporcionan un mecanismo para eliminar muchos de los problemas que son difíciles de superar con paradigmas de la ingeniería del software. La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente mediante la aplicación del análisis matemátic. Este método le permite al ingeniero de software descubrir y corregir errores que de otra manera no se pudiesen detectar, Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de un software libre de defectos.
Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de un software libre de defectos, No obstante es posible que el enfoque a través de métodos formales tenga más partidarios entre los desarrolladores del software que deben construir software de mucha seguridad (por ejemplo: los desarrolladores de aviónica y dispositivos médicos), y entre los desarrolladores que pasan grandes penurias económicas alaparecer errores de software.