Por qu la

Ingeniera de
Software es
Alumno : Daniel Amaro Villajulca
Codigo : 09200137
Escuela : EAPSW
Curso : Arquitectura de Software
Profesor : Hugo Cordero.

2014

Por qu es importante la Ingeniera de

Software ?
Examinaremos una serie de razones porque la ingeniera de software es importante :
2.1 La activacin de Atributos de Calidad del Sistema
Un sistema ser capaz de exhibir sus atributos de calidad se determina
sustancialmente por su arquitectura. Una buena arquitectura es necesaria, pero no
suficiente para asegurar la calidad. Los atributos de calidad que debe considerados
en todo el diseo, implementacin y despliegue. Ningn atributo de calidad es
totalmente dependiente de diseo, ni tampoco es totalmente dependiente de la
aplicacin o implementacin. Los resultados satisfactorios son una cuestin de
conseguir una buena imagen(arquitectura), as como los detalles (implementacin)
correctos.

2.2 Razonando acerca y gestin del cambio

Decidir cuando los cambios son esenciales, determinar qu cambios caminos tiene el menor riesgo,
la evaluacin de las consecuencias de los cambios propuestos, y el arbitraje de secuencias y
prioridades para los cambios solicitados, requieren un amplio conocimiento de las relaciones, el
desempeo y comportamiento de los elementos de software del sistema, estas actividades se
encuentran en la descripcin del trabajo de un arquitecto. Razonando acerca de la arquitectura y el
anlisis de la arquitectura puede proporcionar el conocimiento necesario para tomar decisiones sobre
los cambios previstos.
2.3 Prediccin de Calidades
La arquitectura no slo impregna sistemas con cualidades, pero lo hace de una manera predecible.
Es posible hacer predicciones de calidad de un sistema basado exclusivamente en una evaluacin de
su arquitectura. Si sabemos que ciertos tipos de decisiones arquitectnicas conducen a ciertos
atributos de calidad en un sistema, entonces podemos tomar esas decisiones, y con razn, sino para
ser recompensado con los atributos de calidad asociados. Despus del hecho, cuando examinamos
una arquitectura podemos mirar para ver si se han hecho esas decisiones y confiadamente predecir
que la arquitectura exhibir las cualidades asociadas.
Esto no es diferente de cualquier disciplina de ingeniera madura donde el anlisis de diseo es una
parte estndar del proceso de desarrollo. Cuanto antes se puede encontrar un problema en su diseo,
es ms barato, ms fcil y menos perjudicial arreglar el problema.
2.4 Mejorar la comunicacin entre las partes interesadas
Arquitectura de software representa una abstraccin comn de un sistema en la mayora, no todos,
los actores del sistema pueden utilizarse como base para la creacin de la comprensin mutua de

negociacin, formacin de consenso, y se comunican entre s. Cada parte interesada del sistema se
ocupa de diferentes caractersticas del sistema :
El usuario le preocupa que el sistema es rpido, fiable y disponible cuando sea necesario.
El cliente le preocupa que la arquitectura se puede implementar a tiempo y de acuerdo al
presupuesto.
El director est preocupado (adems de las preocupaciones sobre el costo y el horario) que la
arquitectura permitir a los equipos trabajar de manera muy independiente, interactuando en formas
disciplinadas y controladas.
El arquitecto est preocupado acerca de las estrategias para alcanzar todos esos objetivos.
2.5 Llevar decisiones tempranas del diseo
Arquitectura de software es una manifestacin de las primeras decisiones de diseo sobre un
sistema y esto lleva a que tiene una suma importante en las fases de desarrollo , despliegue y
mantenimiento. Un diseo de la arquitectura puede ser visto como un conjunto de decisiones. Las
primeras decisiones del diseo limitan las decisiones que siguen, y el cambio de estas decisiones
tienen enormes consecuencias, a veces la arquitectura debe hacerse para poder ser rediseado pero
esto no es muy fcil que digamos.
2.6 Definicin de restricciones en una implementacin
Una aplicacin con una arquitectura si se ajusta a las decisiones de diseo establecidas por la
arquitectura .Esto significa que la aplicacin debe ser implementada como el conjunto de elementos
prescritos, estos elementos deben interactuar unos con otros de la manera prescrita, y cada
elemento debe cumplir con su responsabilidad a los otros elementos segn lo dictado por la
arquitectura. Los arquitectos no tienen que ser expertos en todos los aspectos de diseo de
algoritmos o las complejidades del lenguaje de programacin , a pesar de que ciertamente deben
saber lo suficiente para no disear algo que es difcil de construir pero ellos son los responsables de
establecer, analizar y hacer cumplir las compensaciones arquitectnicos. Cada una de estas recetas
es una limitacin para el implementador.
2.7 Influenciando a la Estructura Organizacional
El mtodo normal para dividir la labor en un proyecto grande es asignar porciones de grupos
diferentes del sistema a construir. Esto es llamado el desglose de trabajo de la estructura de un
sistema. Debido a que la arquitectura incluye la ms amplia descomposicin del sistema, esto es
tpicamente usado como base para el desglose de trabajo de la estructura. El desglose de trabajo de
la estructura a su vez determina las unidades de planificacin, programacin y presupuesto; canales
de comunicacin entre equipos; control de la configuracin y organizacin del sistema de archivos;
integracin y planes de prueba y procedimientos e incluso pequeos detalles de proyectos tales
como la forma en la que la intranet del proyecto est organizada . Un efecto secundario de
establecer la estructura de desglose de trabajo es congelar algunos aspectos de la arquitectura de

software, si estas responsabilidades se han formalizado en una relacin contractual, el cambio de

responsabilidades podran llegar a ser costosas o incluso litigiosas.

2.8 Permitiendo la creacin de prototipos evolutivos

Una vez una arquitectura se haya definido, esta puede ser analizada y prototipada como un sistema
esqueltico. Un sistema esqueltico es aquel en el que al menos parte de la infraestructura - como
los elementos inicializar, comunicarse, datos compartidos, recursos de acceso, errores de informe,
registro de actividad, y as sucesivamente - se construye antes de que gran parte de la funcionalidad
del sistema se haya creado. Este enfoque ayuda al proceso de desarrollo porque el sistema es
ejecutable temprano en el ciclo de vida del producto. La funcionalidad del sistema aumenta como
talones sean instanciados, o partes del prototipo son sustituidos. Estos beneficios reducen el riesgo
potencial en el proyecto. Adems, si la arquitectura es parte de una familia de sistemas relacionados,
el coste de crear un framework para la creacin de prototipos puede ser distribuido en el desarrollo
de muchos sistemas, versiones completas de estas partes del software, este enfoque permite
identificar temprano los problemas potenciales de rendimiento en el ciclo de vida del producto.
2.9 La mejora de las estimaciones de costos y cronograma
Las estimaciones de costos y programacin son herramientas importantes para el director del
proyecto, tanto para adquirir los recursos necesarios y para evaluar su progreso en el proyecto, para
saber cuando un proyecto est en problemas.
Uno de los deberes de un arquitecto es ayudar al director del proyecto a crear las estimaciones de
costos y programar al principio del ciclo de vida del proyecto. Como hemos dicho, la estructura de
desglose de la organizacin y el trabajo de un proyecto casi siempre se basa en su arquitectura.
Cada equipo o individuo responsable de un elemento de trabajo podrn h acer ms estimaciones
precisas.
2.10 El suministro de un modelo reutilizable Transferible
Mientras ms temprano en el ciclo de vida del software la reutilizacin se aplica, mayor ser el
beneficio que se puede lograr. Mientras que la reutilizacin de cdigo proporciona un beneficio, la
reutilizacin de arquitecturas ofrece una tremenda ventaja para los sistemas con requisitos similares.
Una lnea de productos de software o de la familia es un conjunto de sistemas de software que estn
todos construidos utilizando el mismo conjunto de activos reutilizables. El principal de los activos
es la arquitectura que fue diseado para manejar las necesidades de toda la familia de software.
Arquitectos de la lnea de producto eligen una arquitectura que servir a todos los miembros
previstos de la lnea de productos. La arquitectura define lo que se fija para todos los miembros de
la lnea de productos y lo que es variable.
2.11 Permitir que la incorporacin de componentes desarrollados independientemente

Con el progreso se mide en lneas de cdigo, arquitectura , desarrollo a menudo se centra en

componer
elementos que puedan haberse desarrollado por separado, incluso de forma
independiente, el uno del otro montaje. Esta composicin es posible porque la arquitectura define
los elementos que pueden ser incorporados en el sistema. Las limitaciones de arquitectura da
posibles reemplazos de acuerdo con la forma en que interactan con su entorno, cmo reciben y
renuncian al control, los datos que la consumen y producen, cmo acceder a los datos, y qu
protocolos se utilizan para la comunicacin y el intercambio de recursos.
Algunas ventajas que nos brindan :
* Disminucin del tiempo de mercado
* Aumento de la Fiabilidad
* Menor coste
* Flexibilidad

2.12 Restringir el vocabulario de las alternativas de diseo

Como patrones arquitectnicos tiles son colecciones, se pone de manifiesto aunque los elementos
de software se pueden combinar de formas, hay algo que ganar voluntariamente restringimos a un
nmero relativamente pequeo de opciones de elementos y sus interacciones.
Al hacer esto se minimiza la complejidad del diseo de la que estamos construyendo.
2.13 Proporcionar una base para la formacin
La arquitectura, incluyendo una descripcin de cmo los elementos interactan entre s para llevar a
cabo el comportamiento requerido, puede servir como la primera introduccin al sistema para los
nuevos miembros del proyecto. Esto refuerza nuestro punto de que uno de los usos importantes de
la arquitectura de software es apoyar y fomentar la comunicacin entre las distintas partes
interesadas. La arquitectura es un punto de referencia comn.