Principios de la Ingeniería de Software - fing.edu.uy

1 Principios de la ingenier a de Software Introduccci n ..1 Rigor y formalidad:..1 Separaci n de intereses: ..2 Modularidad:..3 Abstracci n:..3 Anticipaci n al cambio:..4 Generalidad: ..4 Incrementalidad: ..5 Introduccci n En este documento se presentan algunos Principios generales de importancia, que son centrales para desarrollar Software en forma exitosa, y que tratan tanto del proceso de ingenier a de Software como del producto final. El proceso adecuado ayudar a desarrollar el producto deseado, pero tambi n el producto deseado afectar la elecci n del proceso a utilizar.

2 Un problema tradicional de la ingenier a de Software es poner el nfasis en el proceso o en el producto excluyendo al otro, sin embargo, ambos son importantes. Estos Principios son suficientemente generales para ser aplicados a lo largo del proceso de construcci n y gesti n del Software , sin embargo no son suficientes para guiar el desarrollo ya que describen propiedades deseables de los procesos y productos de Software ; para aplicarlos es necesario contar con m todos apropiados y t cnicas espec ficas. Los m todos son gu as generales que gobiernan la ejecuci n de alguna actividad, presentan enfoques rigurosos, sistem ticos y disciplinados, por otro lado, las t cnicas son m s mec nicas y se refieren a aspectos m s t cnicos que los m todos y tienen aplicaci n restringida.

3 Una metodolog a es un conjunto de m todos y t cnicas cuyo prop sito es promover cierto enfoque para la resoluci n de un problema mediante ese conjunto seleccionado. Las herramientas son desarrolladas para apoyar la aplicaci n de t cnicas, m todos y metodolog as. Los Principios son la base de todos los m todos, t cnicas, metodolog as y herramientas. Rigor y formalidad: En cualquier proceso creativo existe la tendencia a seguir la inspiraci n del momento de forma no estructurada, sin ser precisos; el desarrollo de Software es de por s una actividad creativa.

4 Por otro lado, el rigor es un complemento necesario de la creatividad en todas las actividades de la ingenier a; nicamente a trav s de un enfoque riguroso podr n producirse productos m s confiables, controlando sus costos e incrementando el grado de confianza en los mismos. El rigor no tiene por qu restringir la creatividad, por el contrario, puede potenciar la creatividad aumentando la confianza del ingeniero en los resultados de la misma, una vez que estos son analizados a la luz de evaluaciones rigurosas. Parad jicamente el rigor es una cualidad intuitiva que no puede ser definida en forma rigurosa, pero s pueden alcanzarse varios niveles de rigurosidad siendo el m s alto la formalidad.

5 La formalidad es un requerimiento m s fuerte que el rigor: requiere que el proceso de Software sea guiado y evaluado por leyes matem ticas. Obviamente formalidad implica rigor pero no a la inversa: se puede ser riguroso incluso informalmente. En todos los campos de la ingenier a el proceso de dise o sigue una secuencia de pasos bien definidos, establecidos en forma precisa y posiblemente probados, siguiendo en cada paso alg n m todo o aplicando alguna t cnica. Estos m todos y t cnicas estar n basados en alguna combinaci n de resultados te ricos derivados de un modelado formal de la realidad, ajustes emp ricos que tienen en cuenta fen menos no presentes en el modelo, y m todos pr cticos de evaluaci n que dependen de la experiencia pasada ( rules of thumb ).

6 Un ingeniero debe saber c mo y cu ndo ser formal si es requerido, entendiendo el nivel de rigor y formalidad que debe ser alcanzado dependiendo de la dificultad conceptual de la tarea y su criticidad, lo que puede variar para diferentes partes del mismo sistema. Por ejemplo, partes cr ticas pueden requerir una descripci n formal de las funciones esperadas y un enfoque formal para su evaluaci n mientras que partes est ndares o bien entendidas requerir n enfoques m s simples. Esto aplica tambi n en el caso de la ingenier a de Software , por ejemplo en el caso de la especificaci n del Software la cual puede establecerse de forma rigurosa utilizando lenguaje natural o tambi n puede darse formalmente mediante una descripci n formal en un lenguaje de sentencias l gicas.

7 La ventaja de la formalidad sobre el rigor es que puede ser la base para la mecanizaci n del proceso, por ejemplo si se quiere utilizar la descripci n formal para crear el programa si ste no existe, o para mostrar que el programa se corresponde con las especificaciones establecidas si tanto el programa como las especificaciones existen. Tradicionalmente es en la fase de codificaci n donde se utiliza un enfoque formal ya que los programas son objetos formales: son escritos en un lenguaje cuya sintaxis y sem ntica est n completamente definidas.

8 Los programas son descripciones formales que son manipuladas autom ticamente por los compiladores que chequean su correctitud y las transforman en una forma equivalente en otro lenguaje (assembler o lenguaje de m quina), todo lo cual es posible gracias a la utilizaci n de la formalidad en la programaci n. La aplicaci n del principio de rigor y formalidad tiene influencia beneficiosa en la obtenci n de cualidades del Software como la confiabilidad, verificabilidad, mantenibilidad, reusabilidad, portabilidad, comprensibilidad e interoperabilidad.

9 Por ejemplo, una documentaci n del Software rigurosa o incluso formal puede mejorar todas estas cualidades sobre una documentaci n informal que puede ser ambigua, inconsistente e incompleta. El principio de rigor y formalidad tambi n se aplica al proceso de Software ; la documentaci n rigurosa del proceso ayuda a que ste sea reutilizado en proyectos similares y tambi n ayuda a mantener un producto existente permitiendo que las modificaciones se realicen partiendo del nivel intermedio apropiado, en lugar de hacerlo solamente sobre el c digo final.

10 Si el proceso de Software est especificado en forma rigurosa, los gerentes podr n controlar su adecuaci n y evaluar su oportunidad para mejorar la productividad. Separaci n de intereses: Este principio permite enfrentarse a los distintos aspectos individuales de un problema de forma de concentrarse en cada uno por separado. En el desarrollo de un producto de Software deben tomarse muchas decisiones como las funciones que ser n ofrecidas, la confiabilidad esperada, eficiencia de tiempo y espacio, relaciones con el ambiente como recursos de Software o hardware especial, interfaces de usuario, entre otras.