IntroduccinUNIDAD I :INTRODUCCIN A LA INGENIERA DE SOFTWARE

a)Presentacin y contextualizacin

El anlisis, fundamentos conceptuales y el desarrollo en la ingeniera de software. Son el primer paso, tan importante que hay que entender para la creacin de proyectos informticos Por ello, conocer y entendercoherentemente un tipo de metodologa implica la aplicacin de diferentes tipos de conceptos. Los requerimientos dentro de un proyecto de softwarey el tipo de paradigma a aplicar en un proyecto constituyen un respaldo que se lleva a cabo a travs de una serie de etapas, las cuales se deben seguir para lograr proyectos que puedan cumplir con una serie de necesidades por parte del cliente.

b)Competencia

Conoce metodologas y enfoques para la creacin de un proyecto ylos aspectos fundamentales tericos de la ingeniera de software.

c)Capacidades

1.Identifica los conceptos, procesos y solucin en la construccin de un proyecto a nivel de software partiendo de sus fases principales de creacin.2.Reconoce el enfoque de Objetos a travs de sus paradigmas y conceptos.3.Conoce las fases de solucin como metodologa de creacin de un proyecto de software.4.Identifica y emplea adecuadamente el uso de los requerimientos vlidos en la obtencin de informacin.

d)Actitudes

Valora los conceptos y tipos de metodologa como un medio privilegiado.Asume una actitud positiva en la creacin de un proyecto.Respeta los puntos de vista distintos a los suyos.

e)Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 01: Introduccin a la Ingeniera de Software, comprende el desarrollo de los siguientes temas:

TEMA 01:Definicin, Objetivos y Procesos.TEMA 02:Paradigma de la Programacin Orientada a Objetos.TEMA 03:Metodologas.TEMA 04:Requerimientos e Ingeniera.

UNIDAD I :INTRODUCCIN A LA INGENIERA DE SOFTWARE

Tema 01: Definicin, Objetivos y Procesos

La Ingeniera de Software es la rama de la ingeniera queaplicalos principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos.

OBJETIVOS Y PROCESOS

Alcances:

El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de lograr un objetivo.

El proceso de desarrollo de software requiere por un ladoun conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin.

Fases:

1.ConcepcionLa concepcin define el alcance del proyecto y desarrolla un caso de negocio.

2.ElaboracionLa elaboracin define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura.

3.ConstruccionLa construccin crea el producto a travs de una herramienta de desarrollo o tambin conocido como lenguaje de programacin. Preferentemente deber ser el lenguaje que dominio tenga

4.TransicionLa transicin transfiere el producto a los usuarios. Esta fase tambinse encarga de actualizar la solucin propuesta, ante problemas o nuevos requerimientos que se presenten en el periodo de uso,unavez instalada la solucin en las oficinas del cliente.

OBJETIVOS DE LA INGENIERA DE SOFTWARE

vMejorar la calidad de los productos de softwarevAumentar la productividad y trabajo de los ingenieros del software.vFacilitar el control del proceso de desarrollo de software.vSuministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

Objetivos

Para que los proyectos se cumplan en las empresas se debern de cumplir las 5 C:1.Capacidad2.Costo3.Control4.Comunicacin5.Competitividad

Tema 02:Paradigmas de la Programacin Orientada a Objetos

Programacin Orientada a Objetos (OOP por sus siglas en ingls de Object Oriented Programming) como paradigma, "es una forma de pensar ETAPAS:

Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodologa (coleccin de caractersticas para la ingeniera de software) no es la misma cosa.

La Programacin Orientada a Objetos desde el punto de vista computacional "es un mtodo de implementacin en el cul los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarqua de clases unidas va relaciones de herencia" Greiff 1994.

FUNDAMENTOS DEL TRMINO ORIENTADO A OBJETOS

El paradigma orientado a objeto se basa en el concepto de objeto.Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodologa (coleccin de caractersticas para la ingeniera de software) no son la misma cosa.

Qu es unobjeto?

Es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn.

DIFERENCIA ENTRE OBJETO Y CLASE

ObjetoUn objeto es una entidad concreta que existe en tiempo y espacio.ClaseRepresenta una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto.Una clase tambin se define como un conjunto de objetos y mtodos.

PRINCIPIOS DEL MODELO O.O

vAbstraccinvEncapsulacinvModularidadvJerarqua,vTipificacinvConcurrenciavExistencia

NotaBooch 1986 dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

PRINCIPIOS DEL MODELO ORIENTADO A OBJETOSAbstraccin.Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.Encapsulacin.En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales.Modularidad.Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes.Jerarqua o herencia.Es el orden de las abstracciones organizado por niveles.

Tipificacin.Es la definicin precisa de un objeto de tal formaque objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.Concurrencia.Es la propiedad que distingue un objeto que est activo de uno que no lo est.Persistencia.Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).

BENEFICIOS DE LA POOPrimero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programacin basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, [ y recientemente Java] .Segundo, el uso del modelo OO alienta el uso no solo del software, sino de diseos completos.Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

ANLISIS ORIENTADO A OBJETOSSegn Booch 1986, el Diseo Orientado a Objetos "es un mtodo de diseo abarcando el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos lgico y fsico tal como los modelos estticos y dinmicos del sistema bajo diseo"

Tema 03:Metodologas

Un objetivo de dcadas ha sido el encontrar procesos y metodologas, que sean sistemticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

ETAPAS DEL PROCESOLa ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas como son las siguientes:1.Anlisis de requerimientos2.Especificacin3.Arquitectura4.Programacin5.Prueba6.Mantenimiento

ANLISIS DE REQUERIMIENTOSExtraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del anlisis de requerimientos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software.La captura, anlisis y especificacin de requerimientos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines.

Aunque an no est formalizada, ya se habla de la Ingeniera de requerimientos, por ejemplo en dos captulos del libro de Sommerville "Ingeniera del Software" titulados "Requerimientos del software" y "Procesos de la Ingeniera de Requerimientos".La IEEE Std. 830-1998 normaliza la creacin de las Especificaciones de Requerimientos de Software (Software Requirements Specification).

EspecificacinLa Especificacin de Requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del xito de un proyecto de software radicar en la identificacin de las necesidades del negocio (definidas por la alta direccin), as como la interaccin con los usuarios funcionales para la recoleccin, clasificacin, identificacin, priorizacin y especificacin de los requisitos del software.Entre las tcnicas utilizadas para la especificacin de requisitos se encuentran:Casos de Uso,Historias de usuario,Siendo los primeros ms rigurosos y formales, los segundas ms giles e informales.

ArquitecturaLa integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas. La Arquitectura de Sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura.

Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clasesDiagramas de base de datosDiagramas de despliegue plegadosDiagramas de secuencia multidireccional

Siendo los dos primeros los mnimos necesarios para describir la arquitectura de un proyecto que iniciar a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qu diagramas elaborar. Entre las herramientas para disear arquitecturas de software se encuentran:Rational Rose, Enterprise Architect, Microsoft Visio for Enterprise Architects

ProgramacinReducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamentelas tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas.

En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara.

DocumentacinTodo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

MantenimientoMantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento.

Tema 04:Requerimientos e Ingeniera

REQUISITOS:

Descripcin de los servicios que debe brindar un sistema y sus restricciones.

Ingeniera de Requisitos

Proceso de descubrir, analizar, documentar y verificar esos servicios y restriccionesRequisitos definen el Qu (el problema) del sistema.El Diseo define el Cmo (la solucin).

Los Requisitos estn comprendidos en 2 Tipos:

Funcionales:

Servicios o funciones que proveer el sistema.Describen lainteraccin entre el sistema y su entorno.Ejemplos:Se deben ingresar cdula, nombre y telfono de cada cliente.Se quiere un listado de los clientes por zona.

No-funcional:

Restricciones a los servicios o funciones ofrecidos por el sistema.Describen restricciones que limitan las elecciones para construir una solucin.Ejemplos:Las consultas deben resolverse en menos de 3 segundos.El lenguaje de programacin debe ser Java.

Ingeniera de Requisitos

Proceso de Requisitos

Participantes en el proceso de requisitos

Cliente y UsuariosRequisitos adecuados a sus necesidadesDiseadoresComprenderlos para lograr diseo que los satisfagaSupervisores del Contrato, sugieren:

Hitos de Control, cronogramasGerentes del Negocio, entienden:Impacto en la OrganizacinVerificadoresComprenderlos para poder verificar si el sistema los satisface

Procesos de Requisitos

Obtencin y Anlisis de Requisitos

Se trabaja en conjunto con los usuarios y clientesProblemas comunes:

No saben lo que quieren del sistema, slo en trminos generales, no conocen el costo de sus peticionesLos requisitos estn en sus trminos y con conocimiento implcito de su propio trabajoDistintos usuarios tienen distintos requisitos, se deben encontrar todas las fuentes

Especificacin

El resultado del trabajo realizado es una consecuencia de la ingeniera de requisitos (especificacin el sistema e informacin relacionada) y es evaluada su calidad en la fase de validacin

Validacin

Examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos in ambigedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estndares establecidos para el proceso, el proyecto y el producto.