PARA LA ASIGNATURA SE REVISARA EL CUADERNO DE LA ASIGNATURA QUE DEBERA CONTENER APUNTES DE CLASE O COMPLEMENTOS NECESARIOS PARA APOYAR EL AVANCE.

LAS PRESENTES DIAPOSITIVAS SON SOLO UNA GUA PARA EL AVANCE DE LA ASIGNATURA NO OLVIDE QUE LAS PREGUNTAS DEL EXAMEN SON DE LA BIBLIOGRAFIA.

INTRODUCCIN A LA INGENIERA DE SOFTWARE

introducir al alumno en los conceptos fundamentales de la ingeniera del software revisando la evolucin , aplicaciones , proceso , modelos , mtodos y atributos del software

Roger Pressman 5ta Ed. Capitulo I - El Producto Capitulo II El Proceso Roger Pressman 6ta Ed. Capitulo I - Software e Ingeniera de software Capitulo II El Proceso. Una visin general.

En este capitulo se plantean las siguientes cuestiones que el finalizar el tema debemos ser capaces de responder: Qu es software ? Por qu es importante? Cules son los pasos? Quin lo hace? Cul es el producto obtenido? Cmo sabe que lo ha hecho correctamente?

Aportacin del software a la economa de EE.UU

Principal fuente de supervit por exportaciones en la balanza comercial. 24.000 millones de dlares de ingresos por exportaciones de software y 4.000 millones gastados en importaciones, arrojan un supervit anual de 20.000 millones de dlares.

(Datos tomados de: Software Conspiracy, Mark Minasi, McGraw Hill, 2000). Papel del software en la infraestructura:
no slo tiene un papel importante en Internet; tambin en sectores como transportes, energa, medicina y finanzas.

El software se halla cada vez ms presente como elemento incorporado a otros mecanismos arraigados. Los automviles modernos, por ejemplo, poseen entre 10 y 100 procesadores para dirigir todo tipo de funciones, desde el reproductor de msica hasta el sistema de frenado.

 Fallos en el desarrollo. Accidentes. Software de baja calidad.

Estudio llevado a cabo por IBM en el ao 1994: El 55% de los sistemas costaron ms de lo previsto. El 68% excedieron el tiempo previsto para su desarrollo. El 88% se tuvo que volver a disear por completo. Departamento de Estadstica Laboral (1997) 2 de cada seis nuevos sistemas que se ponen en funcionamiento sufren cancelaciones. Los grandes sistemas tienen aproximadamente un 50% de probabilidad de ser cancelados. La media de tiempo empleado en un proyecto se excede en un 50% con respecto al plazo previsto.

La mayor parte de los expertos coinciden en sealar que la manera ms probable de destruir el mundo es por accidente. Y aqu es donde entramos en juego nosotros, los profesionales de la informtica: nosotros somos los que provocamos los accidentes". Nathaniel Borenstein, creador de MIME en: Programming as if People

Mattered: Friendly Programs, Software Engineering and Other Noble Delusions, Princeton University Press, Princeton, NJ, 1991.

Caso Therac-25 (1985-87) Se trataba de un aparato de radioterapia dotado de controlador de software. Se retir el interbloqueo del hardware, pero el software no tena dispositivo de interbloqueo. El software fall al mantener las constantes vitales: un flujo de electrones o bien un flujo ms intenso de radiacin mediante placa para generar rayos X. A consecuencia de ello se produjeron varias muertes por quemaduras. El programador no tena experiencia en programacin concurrente. Vase: http://sunnyday.mit.edu/therac-25.html

Servicio de Ambulancias de Londres (1992) Prdida de llamadas, doble servicio por llamadas duplicadas. Mala seleccin del programador: experiencia insuficiente. Visite la web: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las.html

El desastre del Servicio de Ambulancias de Londres se debi en realidad a fallos de gestin. Los informticos que desarrollaron el software pecaron de ingenuidad y aceptaron una oferta de una empresa desconocida que era bastante peor que las de otras compaas ms acreditadas. Cometieron el terrible error de saltar a la red repentinamente, sin pararse a contrastar la ejecucin del sistema nuevo y la del ya existente.

"La demanda de software ha crecido mucho ms rpido que nuestra capacidad para crearlo. Adems, el pas requiere un tipo de software ms prctico, fiable y robusto que el que se est desarrollando hoy en da. Nos hemos hecho peligrosamente dependientes de los grandes sistemas de software, cuyo comportamiento no es del todo comprensible, y que a menudo fallan de forma imprevista".

Investigacin en tecnologa de la informacin: Invirtiendo en nuestro futuro Comit Consultor en Tecnologa de la Informacin del Presidente (PITAC) Informe al Presidente,

Definicin El software se forma de 1. las instrucciones , que al ejecutarse proporcionan las caractersticas , las funciones y el grado de desempeo deseado. 2. las estructuras de datos, que permiten al programa manipule la informacin 3. Los documentos que describen la operacin y el uso de los programas

NO SE MANUFACTURA Depende de las personas Enfoques diferentes entre hardware y software.

Curva de fallas Software inmune a males ambientales Durante su vida el software experimenta cambios lo que hace variar la curva

Trmino que aparece en 1968 La produccin de programas debe abordarse como una ingeniera ms. (Boehm) La Ingeniera del Software es la aplicacin prctica y sistemtica del conocimiento cientfico a: la produccin de programas correctos, que se desarrollan a tiempo y dentro de las estimaciones de presupuesto, y a la correspondiente documentacin para desarrollarlos, usarlos y mantenerlos. La Ingeniera del Software se fundamenta en tcnicas relacionadas con: ciencia de la computacin, programacin, ingeniera, administracin, matemticas, economa, etc. Forma parte de la Ingeniera de Sistemas

La ISW es el establecimiento y uso de principios slidos de ingeniera, orientados a obtener software econmico que sea fiable y trabaje de manera eficiente en mquinas reales (Fritz Bauer). ISW: (1) La aplicacin de un enfoque sistemtico, disciplinado y cuantificable para el desarrollo, la operacin y el mantenimiento del software; es decir, la aplicacin de la ingeniera al software; (2) El estudio de enfoques como en (1) (Glosario Estndar de Trminos de Ingeniera del Software de IEEE, 1998). Una disciplina que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste despus de que se utiliza (Sommerville 2002).

El software evoluciona a travs del tiempo , sin importa su dominio de aplicacin, tamao complejidad . El cambio (mantenimiento) conduce este proceso y se presenta cuando corrigen errores Adapta nuevo ambiente Cuando el cliente solicita Experimenta reingenieria

En los ltimos 30 aos: Ley del cambio continuo Ley de la complejidad creciente Ley de la autorregulacin Ley de la conservacin de estabilidad organizacional Ley de la conservacin e familiaridad Ley de crecimiento continuo Ley de calidad decreciente Ley de sistema de retroalimentacin

En la actualidad existen 7 grandes categorias del software de computadora.

Software de sistemas Software de aplicacin Software cientfico y de ingeniera Software empotrado Software de lnea de productos Aplicaciones basadas en la Web Software de Inteligencia Artificial

Revisar y realizar un resumen de los Mitos y realidades del software + su punto de vista acerca de al menos 2.

Roger Pressman 6ta Ed. Capitulo II El Proceso. Una visin general. Roger Pressman 6ta Ed. Capitulo 26 Gestin de Calidad

En esta parte del capitulo se estudiara de manera introductoria el proceso que proporcionara un marco de trabajo para la practica de la ingeniera. del software. Y con la ayuda del presente y el siguiente capitulo podremos responder a las siguientes cuestiones:

Qu es el proceso de software? Cules son las actividades de marco general de presentes en todos los procesos del software ? Cules son los modelos del proceso de software?

La base de la ISW es el estrato del proceso . El proceso de la ingeniera de software es el elemento que mantiene junto con los estratos de la tecnologa que permite el desarrollo racional y a tiempo del software.

El proceso define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnologa de la ISW. El proceso forma la base del control de la gestin de los proyectos de software el establece el contexto el cual se aplican los mtodos , se generan los productos (modelos, documentacin, etc)y se establecen los fundamentos de calidad.

PROCESO ENFOQUE DE CALIDAD

Los mtodos proporcionan el como construir software , abarcan las tareas que incluyen , la comunicacin, el anlisis,. Las herramientas de la ISW proporcionan el soporte automatizado o semi-automatizado para el proceso y los mtodos.

HERRAMIENTAS

MTODOS PROCESO ENFOQUE DE CALIDAD

El marco de trabajo establece la base para un proceso de software completo al identificar un numero de actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su tamao p su complejidad.

Proceso del software

Nota. En el texto se le denomina actividades sombrilla alas actividades de proteccion.

El siguiente marco de trabajo genrico se puede aplicar a la mayora de los proyectos software. Comunicacin: investigacin , clientes Planeacin: plan de trabajo, requisitos Modelado : modelos Construccin: cdigo , pruebas Despliegue: entrega a cliente , evaluacin de producto

Incluyen Seguimiento y control del proyecto software Gestin del riesgo Aseguramiento de la calidad Revisiones tcnicas formales Medicin Gestin de la configuracin Gestin de la reutilizacin Preparacin y produccin de producto de trabajo.

Lineal secuencial Construccin de prototipos DRA Incremental Espiral

Los mtodos indican como construir de manera tcnica el software. Los mtodos abarcan una gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas , pruebas y mantenimiento. Todos los mtodos dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras descriptivas. Por ejemplo: RUP, OMT, metriva V3, OOHDM, HDM, XP, WSDM, modelos agiles(PE,DAS,MDSD,DCC).

El american Heritage Dictionary define como: Calidad. Una caracterstica o atributo de algo Hace referencia a caractersticas mensurables como por ejemplo longitud, tamao , color, etc. En tanto que en el software se puede considerar la complejidad ciclomatica, cohesin, numero de puntos funcin, lneas de cdigo, etc.

Cuando se examina un elemento con base en sus caractersticas se puede encontrar dos tipos de calidad. Calidad de diseo y calidad de concordancia. Calidad de diseo: se refiere a las caractersticas que los diseadores especifican para un elemento. Calidad de concordancia: es el grado en que las especificaciones de diseo se aplican durante la fabricacin.

Otro parecer menciona que la calidad del software se puede evaluar en relacin a : Satisfaccion del usuario= producto maleable + buena calidad+ entrega dentro de presupuestos y tiempo

Serie de inspecciones

Conjunto de funciones de auditoria e informacin que evalan la efectividad y que tan completas son las actividades de control.

Calidad de software se define de la siguiente manera. Concordancia con los requisitos funcionales y de desempeo explcitamente establecidos , estndares de desarrollo explcitamente documentados, y caractersticas implcitas que se esperan de cualquier software desarrollado profesionalmente.

Para garantizar la calidad del software se define un grupo SQA, este grupo funciona como representante de la casa del cliente. Este grupo SQA realiza una variedad de tareas asoiciadas con dos integrantes , los Ing. De Software y un grupo SQA que se encarga de planificar, supervisar, guardar registros, analizar , reportar la garanta de calidad.

Las revisiones son un FILTRO Se purifica el software

Investigar sobre las metodologas de desarrollo de software, mencionadas en clase y otras que estn surgiendo en nuestro medio..

La estimacin del costo y el esfuerzo nunca ser una ciencia exacta, por la cantidad de variables Sin embargo esta practica oscura se podra transformar a pasos sistemticos Para obtener estas estimaciones tenemos las siguientes opciones:

1. 2. 3. 4.

demorar la estimacin hasta mas tarde en el proyecto Basar las estimaciones en proyectos similares Emplear tcnicas de descomposicin relativamente simples Utilizar uno o mas modelos empiricos

La PRIMERA es atractiva pero no practica La segunda opcin puede funcionar razonablemente si el proyecto a afrontar es similar a anteriores y otras influencias . Por desgracia no siempre es un buen indicador Las siguientes son opciones mas viables

Realizar la estimacin de un proyecto en una sola pieza resulta complejo por esta razn descomponer el problema en problemas mas pequeos.

La precisin de la estimacin de un proyecto software se manifiesta en varios factores 1. el grado en el cual es planificador a estimado adecuadamente el tamao 2. habilidad para traducirla estimacin del tamao en esfuerzo humano, programa de trabajo y dinero. 3.el grado en el cual el plan de proyecto refleja las habilidades del equipo de software 4. la estabilidad de los requisitos de los requisitos del producto

El tamao representas el primer gran desafo. tamao: se refiere al a un resultado cuantificable del proyecto de software. Si se asume un enfoque directo el tamao es medir las lneas de cdigo , si se elige un enfoque indirecto el tamao representa como puntos funcin.

Por ejemplo: considere un paquete de software destinado a componentes mecnicos . El software debe tener interfaz con varios perifricos que incluyen ratn, digitalizador, monitor de color de alta resolucin e impresora laser. PAG 701.

Se elabora una tabla de estimacin Segn la siguiente formula S=(Sopt+4Sm+Spes)/6 Por ejemplos para anlisis geomtrico 3D optimista es 4600, mas probable es 6900, pesimista es 8600. por lo que se obtiene 6800

En este caso se centran en los valores del dominio de informacin mas que en las funciones e software. En este caso se considera: entradas Salidas Consultas archivos lgicos archivos de interfaz

La tcnica mas comn para estimar un proyecto es basar la estimacin en el proceso que se empleara . Este proceso se descompone en un conjunto relativamente pequeo de tareas y se estima el esfuerzo requerido para lograr cada tarea.

Como los casos de uso permiten a equipo comprender el mbito del software y los requisitos se puede dar pero son alguna s complicaciones.

Modelo COCOMO II Estacin para POO

Investigar la aplicacin en un ejemplo claro de COCOMO II.

Estimacin de desarrollo gil Estimacin para proyectos de Ingeniera web DECISIN DESARROLLAR O COMPRAR SUBCONTRATACIONES.

El reto de la heterogeneidad: Es cuando se debe de construir el software lo ms confiable y flexible para adecuarse a esta heterogeneidad El reto de la entrega: Poder reducir el tiempo de entrega de los programas sin reducir su calidad El reto de la confianza: Poder construir software que sean totalmente confiables para el usuario.

Esta carrera se lleva a cabo dentro de un marco legal y social que limita la libertar de los ingenieros. Los ingenieros en software deben comprender que su trabajo es de suma importancia. Los ingenieros en software deben comportarse de una forma tica y moral responsable. No basta con poseer estndares normales de honestidad e integridad. No debera utilizar su capacidad y sus habilidades para comportarse de forma deshonesta. Existen reas donde los estndares de comportamiento aceptable no estn acotados por las leyes, sino por la responsabilidad profesional.

ALGUNAS DE STAS SON: *Confidencialidad. Respetar la confidencialidad de sus empleados. *Competencia. No se debe de facilitar el nivel de competencia de los ingenieros en software *Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes y el copyright. * Uso inapropiado de las computadoras. No debe emplear sus habilidades tcnicas para utilizar de forma inapropiada las computadoras de otras personas. Desde los relativamente triviales (utilizar juegos en la mquina de un empleado, por ejemplo) hasta los extremadamente serios (difusin de virus). *Las sociedades e instituciones profesionales desempean un papel importante en el establecimiento de estndares ticos. *Organizaciones como la ACM (Association for Computing Machinery), el IEEE (Instituto de Ingenieros Elctricos y Electrnicos) y la British Computer Society publican un cdigo de conducta profesional o de tica. *Los miembros de estas organizaciones se comprometen a cumplir ese cdigo cuando se inscriben en ellas.

ACM y el IEEE *El cdigo contiene ocho principios relacionados con el comportamiento hechos por ingenieros de software profesionales, incluyendo practicantes, educadores, administradores, supervisores y creadores de polticas, as coma aprendices y estudiantes de la profesin.

*Los principios identifican las relaciones ticas en las que los individuos, grupos y organizaciones participan, y las obligaciones primarias dentro de estas relaciones.

*Las clusulas de cada principio son ilustraciones de algunas de las obligaciones incluidas en estas relaciones.

Cdigo de tica (ACM/IEEE) Los ingenieros de software debern comprometerse consigo mismos en convertir el anlisis, especificacin, diseo, desarrollo, prueba y mantenimiento de software en una profesin respetable y beneficiosa. Principios del cdigo 1.-PBLICO: Los Ingenieros de Software debern actuar consistentemente con el inters pblico. 2.-CLIENTE Y EMPLEADOR: Los Ingenieros de Software debern actuar de una forma determinada que est en los mejores intereses de su cliente y empleador. 3.-PRODUCTO: Los Ingenieros de Software debern asegurar que sus productos logren el ms alto estndar profesional posible. 4.-JUICIO:Los Ingenieros de Software debern mantener integridad e independencia al emitir su juicio profesional 6.-GERENCIA: Los gerentes y lderes de Ingeniera de Software debern suscribirse y promocionar un enfoque tico para la gerencia de desarrollo y mantenimiento de software. 7.-PROFESIN: Los Ingenieros de Software debern fomentar la integridad y reputacin de la profesin. 8.-COLEGA: Los Ingenieros de Software debern ser justos y comprensivos con sus colegas. 9.- INTERS PROPIO Los ingenieros de software debern participar en el aprendizaje de por vida del ejercicio de su profesin y debern promover un enfoque tico para el ejercicio de la misma.

ESCRIBIR UN RESUMEN SOBRE LA INTEGRACION DE CAPACIDAD DE MADUREZ (IMCM). Y RESPONDER A LA SIGUIENTE PREGUNTA SEGN EL GRUPO EN QUE NIVEL DE MADUREZ CONSIDERA QUE SE ENCUENTRA NUESTRO SISTEMA DE SEGUIMIENTO ACADEMICO?

PRACTICA DE CAPITULO. RESOLVER EL CUESTIONARIO PLANTEADO.