Vous êtes sur la page 1sur 6

Universidad Don Bosco

Centro de Estudios de Postgrados Maestra en Arquitectura de Software Ingeniera de Software

Docente: Ing. Luis Garca.

Ensayo 1 Levantamiento de requerimientos, diseo y construccin de software

Estudiante: Henry Marquina Cruz

27 de Noviembre de 2012

Levantamiento de Requerimientos, Diseno y Construccion de Software


Requerimientos y Especificaciones
La mayora de profesional de la informtica en El Salvador que ha tenido que desarrollar una solucin software para un cliente, sin lugar a duda se ha visto enfrentado con la realidad de gestionar y definir requerimientos de sistema. Sabemos de acuerdo a la teora que este es un factor determinante del xito o fracaso de nuestros proyectos. Sin embargo, y sin desmerecer nuestra labor local como tecnlogos, aun son demasiadas las empresas que atesoran los mitos que rodean la disciplina de levantar requerimientos y especificaciones. Como ejemplo coloco el caso de la empresa donde desempeo un rol de analista desde hace un par de aos, la cual se dedica al sector financiero (esto es importante recalcarlo, ya que una empresa que no tiene como giro principal la tecnologa, no maneja la misma perspectiva con relacin a los procesos tecnolgicos, al contario de una empresa que se dedica exclusivamente a crear soluciones informticas). Algunos lderes de proyectos y tecnlogos en mi experiencia tenemos la falsa percepcin que la definicin de los requerimientos y el plasmado de las especificaciones es una tarea sencilla, y por lo tanto no se planifican tiempos adecuados para esta etapa, Donald Gause and Gerald Weinberg exponen en su libro [explorando requerimientos: calidad antes de diseo.] Las ambigedades, las dificultades en las personas para lograr entendimiento y las pequeas cosas que debe hacer la persona que escribe los requisitos, entendiendo completamente la intencin del usuario. No es difcil, el problema est en saber si lo que esta pidiendo es lo que realmente quiere. Bajo esta premisa es obvio que para conocer cmo pensar acerca de los requisitos?, cmo entender lo que est diciendo el usuario? y cmo escuchar lo que realmente se est diciendo?, es necesario mucho mas esfuerzo. Pero creo que el legado duradero de esta reflexin inicial es la capacidad que tengamos como profesionales de la informtica para reconocer francamente cmo la recopilacin de requerimientos no es tarea fcil. Apreciando esta etapa inicial como un reto para los analistas y sus usuarios, de hecho para todas las partes interesadas. Por otra parte esta ciencia requiere de personas con las cualidades necesarias para expresar de forma clara cada una de las especificaciones en un documento, de tal manera que este sea lo suficientemente completo y fcil de asimilar, a fin que las siguientes etapas durante el ciclo de desarrollo tengan mejor fluidez. Comparto la experiencia de trabajo donde para esta etapa tan importante se tiene como norma que un analista funcional se rena con el usuario que requiere un desarrollo nuevo, una mejora de mantenimiento o la atencin de algn incidente, a fin de que esta figura de analista funcional o administrador funcional traduzca lo deseos del usuario en un documento de requerimientos. Luego de este paso estos requerimientos son distribuidos a las reas competentes, las cuales efectan un anlisis tcnico para determinar las posibles ambigedades dentro de las especificaciones de los requerimientos del usuario.

Este ciclo de retroalimentacin nos permite poder tener un documento inicial mejor depurado y que las partes interesadas estn en sintona sobre lo que se requiere, asegurando una sola interpretacin, no dando lugar a que se actu bajo suposiciones. En muchas ocasiones como analistas nos hemos topado con requerimientos demasiado ambiguos o especificaciones que no tienen clara las mtricas para determinar su cumplimiento, por ejemplo, frases como: el botn debe funcionar adecuadamente, o la sesin debe permanecer activa durante un tiempo prudencial, los tiempos de respuestas deben ser ptimos, etc. Estas y otras mas son muestras de requerimientos que tienen bien definidos sus mecanismos de medicin, por ello es necesario que el levantamiento de requerimientos sea una labor conjunta que permita la participacin de todos los interesados a fin de evitar vacos conceptuales y problemas de diseo posteriores. Las tcnicas para la captura de los requerimientos y la definicin de los requisitos tambin es una tarea ardua que nos garantiza que estamos considerando capturar todas las necesidades desde el punto de vista del negocio, del usuario y del sistema. La recomendacin personal y que me ha servido durante algunos aos desarrollando, es partir de lo general hacia lo especifico, primero tener bien claro la visin general del problema si no puedo atacar el problema de forma general, voy subdividiendo en pequeas secciones para atacar el problema de manera modular y as sucesivamente. Para esto es de mucha importancia que se documenten de forma correcta los casos de uso del sistema o software. Es claro que a pesar del esfuerzo que podamos invertir en este paso es probable que suframos cambios en nuestros requerimientos aunque en menor escala, es algo con lo que tenemos que convivir, en realidad el reto no es llegar a tener cero cambios, sino mas bien saber gestionarlos, controlarlos, priorizarlos y estimar su impacto en nuestros desarrollos. En lo personal lo mas valioso para un profesional de la informtica, no es su conocimiento profundo sobre la tecnologa, sino el saber integrar una solucin tecnolgica en las necesidades del negocio, por ello es que el conocimiento del negocio es el que hace que las partes involucradas lleguen a acuerdos de requerimientos viables y esta experiencia ayuda a desarrollar de manera mas fluida. A pesar de la madurez en los procesos de la organizacin donde laboro es comn escuchar que algunos consideran que la gestin de los requerimientos es bsicamente documentarlo, cuando en realidad esto es solo una actividad, en lo personal la gestin de los requerimientos es muy difcil sobre los documentos, en nuestro caso muchos documentos son llenados de forma colaborativa, esto en ambientes bajo norma ralentiza el flujo del ciclo, por otra parte la gestin de cambio individualizada del requisito, la gestin y anlisis de trazabilidad y las validaciones iniciales sobre esos cambios son difcilmente realizables cuando se trabajo con documentos. Esto tiene partes buenas porque descarga de responsabilidad a parte de los autores, sin embargo plantea latencias dentro del ciclo de desarrollo, mas aun en organizaciones donde las polticas del ciclo de desarrollo son cambiantes. Finalmente hay una postura derrotista con relacin a los requerimientos, algunos tienen arraigado que siempre los requerimientos tendrn alguna carencia, este tipo de percepcin hace mas propensos los proyectos a enfrentarse a problemas crticos por malas definiciones de requerimientos y sus especificaciones, ya que no se proporciona el mejor esfuerzo en la elaboracin de estos y bsicamente se plantean a dar en primer paso a ciegas esperando estabilizar en la marcha. La industria del software es relativamente joven y algunos creen que esa falta de madures es la razn de las malas estadsticas que persiguen este sector en cuanto a proyectos, pero eso no implica que dejemos de apuntar a la excelencia, la industria del software es la mas dinmica del mercado y la que

mas metamorfosis sufre, por lo tanto los buenos resultados en desarrollo de software no vienen en libros sino que son ganados con experiencia.

Diseo de Software
El diseo del software es bsicamente la aplicacin de varias tcnicas para definir un software con el suficiente detalle para que este se pueda construir, en otras palabras traduce lo que se quiere con los requisitos, en el como se har en el sistema. Los documentos que estn ligados en esta etapa, hacen uso de representaciones, diagramas, descripciones, etc., que permitirn al desarrollador obtener los detalles necesarios para implementar la solucin requerida. (Para esta etapa el UML juega un papel determinante) En la teora esta es una tarea de un agente o rol que debera estar desligado de la codificacin, sin embargo es nuestra realidad, eso no es as, en mi caso particular, en ocasiones tengo que levantar requerimientos, plantear los diseos de la solucin, desarrollar la codificacin de los mismos y por si fuera poco tambin probarlos e implementarlos. Retomando la frase de Jack W. Reeves en el articulo What Is Software Design? Publicado el 23 de febrero de 2005 en el sitio http://www.developerdotstar.com/mag/articles/reeves_design.html, cito la traduccin al castellano: la programacin no se trata de construir software, la programacin se trata de disear software., este punto es de gran relevancia en este an lisis ya que el diseo del software es en muchas ocasiones visto con poca importancia, pensando errticamente que la codificacin es la parte central. En mi experiencia como analista de soluciones para la banca, he aprendido que un buen diseo es aquel que no importa quien lo retome para codificarlo, el resultado siempre ser el mismo. Las organizaciones con reas de tecnologa con mayor madurez tienen muy clara la importancia de un buen diseo debidamente documentado y que abarque todas las reas respectivas (datos, interfaces, integracin con la arquitectura y los procedimientos). Por esa razn este rol es ejecutado por una figura en particular que no tiene relacin con los equipos que se encargan de codificar. Es otras palabras el diseo de software requiere la aplicacin correcta de la lgica computacional en la soluciones de los problemas del negocio, en poder aplicar de forma correcta el patrn de diseo adecuado mediante una abstraccin coherente sobre la arquitectura donde operara nuestro software. He tenido la oportunidad de trabajar en proyectos donde se cuenta con la figura del arquitecto de software para tratar lo relacionado a la integracin del software a desarrollarse con el software operante, ya sea ncleos o perifricos, asimismo con la participacin de los dbas de la institucin para cotejar de la mejor forma los esquemas de las bases de datos y hasta que punto se puede optimizar su uso con instrucciones nativas del dbms, y finalmente la participacin del diseador encargado en algunos casos de la definicin procedimental y como el agente consolidador de la idea de solucin, encargado de presentar el documento de diseo. En el caso de la compaa con la que trabajo es responsabilidad de los analista la generacin de un documento que maneja el diseo funcional y el diseo tcnico en dos secciones separadas luego de consensuar con las reas de tecnologa que estn involucradas. Es decir en el apartado de diseo funcional explicamos que se busca o debe conseguir con el proyecto o mantenimiento solicitado, adems de especificar cuales son los requerimientos solicitados por el usuario y que debe realizar el producto terminado en cada momento o etapa de operacin del software. Esta etapa entre ms detallada y menos compleja de entender mejor. En cambio con el diseo tcnico se persigue explicar como se realizaran los requerimientos anteriormente detallados para obtener los

resultados requeridos. En esta parte detallamos de forma minuciosa los objetos a desarrollar su interaccin y comunicacin con el sistema, las entidades que sufrirn modificacin, los algoritmos a desarrollar, etc. Actualmente las herramientas CASE (Ingeniera de Software Asistida por Computadora, en su traduccin al castellano) agilizan y facilitan la creacin software, sin embargo la nica manera de obtener el mayor beneficio de estas herramientas es a travs de buenos diseos. Esta tendencia poco a poco a dejado en evidencia que el diseo del software en una las fases medulares en la ingeniera de software y por lo tanto requiere de los mejores elementos trabajando en ello. La premisa ms importante de este anlisis es que si el diseo de software es la base sobre la cual se pretende construir una solucin, la robustez y la estabilidad de esta solucin ser determinada por el esfuerzo que se dedique a esta etapa.

Construccin de Software
Actualmente existe una analoga que en lugar de ayudar a entender y mejorar el desarrollo de software ha venido a introducir un grado de confusin sobre esta disciplina. Esta analoga es la de tratar de asemejar la construccin de software con la construccin de edificios. Y el problema es simple, radica en que no existe tal analoga, ya que el software es un producto inmaterial e intelectual y un edificio es algo fsico y ms rgido. No tiene nada que ver el tiempo que se tarda una mezcla de cemento en secar que el tiempo que le puede tomar a un programador codificar en un botn en un lenguaje. Segn un articulo publicado en el sitio colaborativo sobre tecnologa y cultura Kuro5hin.org publicado el 14 de marzo de 2003, con el titulo La analoga de la construccin de software est rota en su traduccin al castellano, existe una alternativa que muy prometedora en la Programacin Extrema y el Scrump, esto debido a que estos modelos, descabelladlos para muchos, plantean propuestas de desarrollo considerando la naturaleza cambiante de los requerimientos y la flexibilidad requerida de en los sistemas de software en la actualidad. Adems plantean la introduccin de elementos radicales en la forma de desarrollar proyectos como la codificacin en parejas que plantea el beneficio de codificar y discutir la solucin en paralelo a fin de obtener la menor prdida de productividad. En mi caso persona no he tenido experiencias con este tipo de modelos de desarrollo, esto por una parte es debido a que la mayora de organizaciones que desean implementar este tipo de modelos tienen que hacer cambios estructurales y culturales radicales en sus poltica y procesos de desarrollo internos, por lo que en instituciones donde la estabilidad es lo mas importante como el sector financiero o los desarrollos a largo plazo esto suele ser muy difcil de implementar. En mi experiencia la codificacin resulta se mucho mas mecnica, cada vez es menos difcil construir software y mas complejo disear software, los paradigmas plasmados por los diferentes patrones de diseo han dado lugar a que los desarrolladores puedan hacer uso de soluciones de cajn, y centrar sus esfuerzos de codificacin sobre aquello que implica algo novedoso y no sobre los elementos comunes de una aplicacin. En cuanto desarrollo es importante contar con una buena practica documental de parte del programador, donde todo lo que se codifique quede registrado de forma coherente y explicado para futuras optimizaciones o modificacin. En este punto toman un papel importante las herramientas de versionamiento, y de distribucin de tareas de desarrollo, esto agiliza los procesos de pruebas unitarias y las pruebas de calidad del equipo de desarrolladores, permitiendo mejores estndares de software.

Reducir 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. Fundacin Wikimedia, Inc. (26 nov 2012). Ingeniera de software. [ONLINE] Available at:
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software. [Last Accessed 27 nov 2012].

Conclusin
La Ingeniera de software es la aplicacin de muchas disciplinas debidamente enfocadas que consideran principios y metodologas para el desarrollo y mantenimiento de sistemas software. Algunos como el Ingeniero Informtico estadounidense Barry Boehm podran definir a la Ingeniera de software como la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software En palabras simples no es nada ms que el proceso de crear software, tan simple como eso para conceptualizarlo, pero lo suficientemente complejo para implementarse que requiere de los mejores en las ramas tecnolgicas para obtener resultados positivos. No me arriesgara en aseverar que la mayora de profesionales de la informtica considera la ingeniera de software una ciencia peculiar, donde no existen las soluciones nicas, solo diferentes formas de llegar al mismo punto, el reto radica en encontrar el ms optimo, es decir, el mas elegante.

Vous aimerez peut-être aussi