Características para el desarrollo de software Para poder comprender lo que es el software (y consecuentemente la Ingeniería del Software), es importante examinar las características característi cas del software que lo diferencian de otras cosas q ue los hombres pueden construir.
l software es un elemento del sistema que es l!gico, en lugar de físico. Por lo tanto el software tiene unas características considerablemente distintas a las del hardware"
1.
Aunque ue El sof softwa tware re se des desarr arroll olla, a, no se fab fabric rica a en un sen sentid tido o cl clási ásico co. Aunq existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calida ca lidad d se adq adquie uiere re med median iante te un bue buen n dis diseño eño,, per pero o la fas fase e de co const nstrucc rucción ión del hardware puede introducir problemas de calidad que no existen (o son fcilmente corre!ibles" en el software. Ambas actividades dependen de las personas, pero la relac re lación ión ent entre re las per person sonas as ded dedica icadas das y el tra traba# ba#o o re reali$ ali$ado ado es com comple pletam tament ente e diferente para el software. Ambas actividades requieren de la construcción de un producto, pero los m%todos son diferentes. #os costes del software se encuentran en la ingeniería. sto significa que los proyectos de software no se pueden gestionar como si si fueran proyectos de fabricaci!n. fabricaci!n.
&.
El software no se estropea . El software no es susceptible a los males del entorno que hacen que el hardware se estropee. 'tro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software. uando un componente se estropea, se sustituye por una pie$a de repuesto. )o hay pie$a de repuesto para el software. ada fallo en el software indica un error en el diseño o en el proceso mediante el que se tradu#o tra du#o el dis diseño eño a cód códi!o i!o maq maquin uina a e#e e#ecut cutabl able. e. *o *orr tan tanto, to, el man manten tenimie imiento nto del software tiene una comple#idad considerablemente mayor que la del mantenimiento del hardware.
+.
La ma mayo yoría ría del sof softwa tware re se con constr struye uye a med medida ida,, en vez de ens ensam ambla blar r componentes existentes. )o existen catlo!os de componentes de software. e puede comprar software ya desarrollado, pero solo como una unidad completa, no como componentes que pueden reensamblarse en en nuevos pro!ramas. -mportante para un componente de software de alta calidad. El componente debera diseñarse
es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software. Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.
Se pueden citar otras definiciones enunciadas por prestigiosos autores:
•
Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (el!o"it#, $%&'
•
Ingeniería de software es la aplicación práctica del conocimiento científico al dise)o y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambi*n como desarrollo de software o producción de software (+oem, $%&-.
•
Ingeniería de software trata del establecimiento de los principios y m*todos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabae en máquinas reales (+auer, $%&/
0etodología: 12n obeti"o de d*cadas a sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de meorar la producti"idad en el desarrollo y la calidad del producto software. Etapas del proceso: 13a ingeniería de software requiere lle"ar a cabo numerosas tareas agrupadas en etapas, al conunto de estas etapas se le denomina ciclo de "ida. 3as etapas comunes a casi todos los modelos de ciclo de "ida son las siguientes: 4nálisis de requisitos: 1E5traer los requisitos de un producto de software es la primera etapa para crearlo. 0ientras que los clientes piensan que ellos saben lo que el software tiene que acer, se requiere abilidad y e5periencia para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento E6S, Especificación de Requisitos del Sistema, cuya estructura puede "enir definida por "arios estándares, tales como 700I. 4simismo, se define un diagrama de Entidad86elación, en el que se plasman las principales entidades que participarán en el desarrollo del software. 3a captura, análisis y especificación de requisitos (incluso pruebas de ellos, es una parte crucial9 de esta etapa depende en gran medida el logro de los obeti"os finales. Se an ideado modelos y di"ersos procesos de trabao para estos fines. 4unque an no está formali#ada, ya se abla de la Ingeniería de requisitos. 3a IEEE Std. ';<=$%%' normali#a la creación de las especificaciones de requisitos de software (Software 6equirements Specification. >o siempre en la etapa de ?análisis de requisitos? las distintas metodologías de desarrollo lle"an asociado un estudio de "iabilidad y8o estimación de costes. El más conocido de los modelos de estimación de coste del software es el modelo 7@7@0@ Especificación: 3a especificación de requisitos describe el comportamiento esperado en el software una "e# desarrollado. Aran parte del *5ito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección, así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priori#ación y especificación de los requisitos del software. Entre las t*cnicas utili#adas para la especificación de requisitos se encuentran:
•
7aso de uso,
•
Bistorias de usuario,
Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales. 4rquitectura: 13a integración de infraestructura, desarrollo de aplicaciones, bases de datos y erramientas gerenciales, requieren de capacidad y lidera#go para poder ser conceptuali#ados y proyectados a futuro, solucionando los problemas de oy. El rol en el cual se delegan todas estas acti"idades es el del 4rquitecto. El arquitecto de software es la persona que a)ade "alor a los procesos de negocios gracias a su "alioso aporte de soluciones tecnológicas. 3a arquitectura de sistemas en general, es una acti"idad de planeación, ya sea a ni"el de infraestructura de red y ardware, o de software. 3a arquitectura de software consiste en el dise)o de componentes de una aplicación (entidades del negocio, generalmente utili#ando patrones de arquitectura. El dise)o arquitectónico debe permitir "isuali#ar la interacción entre las entidades del negocio y además poder ser "alidado, por eemplo por medio de diagramas de secuencia. 2n dise)o arquitectónico describe en general el cómo se construirá una aplicación de software. Cara ello se documenta utili#ando diagramas, por eemplo:
•
Diagramas de clases
•
Diagramas de base de datos
•
Diagrama de despliegue
•
Diagrama de secuencia
Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, compleidad y necesidades, el arquitecto elige qu* diagramas elaborar. 3as erramientas para el dise)o y modelado de software se denominan 74SE, (Computer Aided Software Engineering entre las cuales se encuentran:
•
Enterprise 4rcitect
•
0icrosoft isio for Enterprise 4rcitects
Crogramación: 6educir un dise)o a código puede ser la parte más ob"ia del trabao de ingeniería de software, pero no necesariamente es la que demanda mayor trabao y ni la más complicada. 3a compleidad y la duración de esta etapa está íntimamente relacionada al o a los lenguaes de programación utili#ados, así como al dise)o pre"iamente reali#ado. Crueba: 7onsiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. 2na t*cnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al obeti"o. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas9 sin peruicio de lo
anterior el programador debe acer sus propias pruebas. En general ay dos grandes formas de organi#ar un área de pruebas, la primera es que est* compuesta por personal ine5perto y que descono#ca el tema de pruebas, de esta forma se e"ala que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software ace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con e5periencia, personas que saben sin mayores indicaciones en qu* condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal ine5perto no consideraría. Documentación: Fodo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (203,diagramas de casos de uso, pruebas, manuales de usuario, manuales t*cnicos, etc9 todo con el propósito de e"entuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. 0antenimiento: Gase dedicada a mantener y meorar el software para corregir errores descubiertos e incorporar nue"os requisitos. Esto puede lle"ar más tiempo incluso que el desarrollo del software inicial. 4lrededor de /8; del tiempo de ciclo de "ida de un proyectoH está dedicado a su mantenimiento. 2na peque)a parte de este trabao consiste eliminar errores (bugs9 siendo que la mayor parte reside en e5tender el sistema para incorporarle nue"as funcionalidades y acer frente a su e"olución.
