77nS
DA ARQUITECTURADE SOFWARE, ( Versión 2-2012)
"un poco de ciencia aleja de Di9s, pero mucha ciencia devuelve a Elto. ( Louis Pasteur)
ING. JOSUE OBED VETZAGA GONZALES
UNIVBRSIDAD AUTONOMA GABRIEL RENE MORENO tA COMPUTACION Y TELECOMUNICACIONE' CARRERA INGENIERIA INF'ORMATICA/SISTEMAS/REDES
FACULTAD DE INGENIERIA EN CIENCTA' DE
Nota: Observaciones al texto de este documento, favor hacer llegar a
[email protected]. El objetivo es mejorar y su aporte será de gran ayuda. Gracias
Introducción Las necesidades actuales que tienen las organización para el logro de sus objetivos, demandan la construcción de grandes y complejos sistemas de software que requierén de la combinación de diferentes tecnologías y plataformas de hardware y software para alcanzar un funcionamiento acorde con dichas necesidades. Lo anterior, exige de los profesionales dedicados al desarrollo de software poner especial atención y cuidado al diseño de la arquitectura, bajo la cual estará soportado el funcionamiento de sus sistemas.
Si una arquitectura de software se encuentra deficiente en su concepto o diseño, o en el peor de lo casos, no contamos con la del sistema que desarrollamos, tendremos grandes posibilidades de construir un sistema que no alcanzará el total de los requerimientos establecidos. Esto, indudablemente, nos generará un re-trabajo complicado o, peor aún, nos podrá llevar al fracaso del sistema de software cuando se encuentre en operación. De esta manera, es necesario conocer y comprender los elementos que deben atacarse al diseñar una arquitectura de software, entendida como un término que se ha venido perfilando en los últimos años por los profesionales de la industria, a pesar de que es un tópico que ha sido desarrollado por los expertos del campo de la ingeniería de software desde hace muchos años atrás. Son pocos los profesionales que conocen lo que en realidad abarca este tema y cómo debe diseñarse la arquitectura de un sistema de software, lo cual se debe al desconocimiento generalizado de esta importante etapa del ciclo de vida de un sistema. Regularmente, se pasa de la especificación de requerimientos a un diseño somero y a la codificación del sistema. Fnres
Ftujar
*r frrrhnj*
El*1¡nrarlúrr
fur¡i:Í*rnr,u¡f¡e&es
| {-.*n*{ru*:ri*n i Tl,:*llvirió,u it l. ¡r¡¡ if*r¡eiótz snln
f¡+qr l;lc' *:l* fu *r.:*q:*&n
T{cqni'xit**
Ar¡¡ilinir &iseÉ* nruple:m**rt
rciiin $K..,%* I
i
F¡'ne$rs
iler. I ri;r
Texto en revisión
Í
-#,** {ai:i!-
-
|
!rer. ;"a
Versión 2 -2012
ll{:sa:"
rttz*
[tr*r.
|
Ing. Josué O. Y eizaga Gonzales
En el flujo de trabajo de diseño aparte de realizar el diseño de la interfaz y el diseño de la base de datos, se realiza el diseño arquitectónico (también conocido como diseño de alto
nivel) y diseño detallado. El diseño de la arquitectura de software ocurre inmediatamente después de la especificación de los requerimientos de software y considera como elementos principales los siguientes: componentes de software, propiedades de dichos componentes y la comunicación entre ellos. El diseño detallado se lleva a cabo justo antes de la codificación, y forma parte de las primeras tareas del desarrollador; describe la lógica, el control jerárquico, estructura de datos, empacado de componentes, etcétera.
El desarrollo de la arquitectura de software es una de las etapas fundamentales y, en muchos casos, la más importante en el desarrollo de software, pues es aquí donde los profesionales aportan todos sus conocimientos, creatividad y experiencia para crear la mejor propuesta de solución que se dará al cliente que cumpla con los requerimientos funcionales y no funcionales establecidos para el sistema en desarrollo, así como sus preocupaciones principales de lo que esperan del sistema.
Texto en revisión
-
Versión 2 -2012
Ing. Josué O.Yeizaga Gonzales
TEMA I INTRODUCCION A LA ARQUITECTURA DE SOFTWARE
Presentación: En este tema se presenta conceptos básicos sobre que es arquitectura de software , que es 1o que hace un ingeniero de software en relación a un arquitecto. Como ve como producto y proceso el ingeniero y el arquitecto de software. También es importante mencionar en que parte del proceso de desarrollo de software se especifica la arquitectura. Finalizando la descripción de los requisitos funcionales, de calidad y los de restricción.
Contenido:
a o a
Definiciones de arquitectura de software Requisitos Funcionales Requisitos de calidad Requisitos de restricción
Texto en revisión
-
Versión 2 -
2012 3
Ins. Josué o.Yeizasa Gonzales
TEMA 1 Introducción a la Arquitectura de softwa re : conceptos Ing. Josué Obed Veizaga Gonzales MSc Universidad Autónoma Gabriel René Moreno Ing. Informática- Ing, De sistemas
o" -.et..ffi
rq u itectu ra... de q ué? o De Software. Involucra al diseño estructural
del software (únicamente) que forma parte de un sistema.
o
De Sistemas
Software. Involucra al diseño estructural de todo el sistema, entiéndase: Software, Datos, Usuarios, el Ambiente Operacional y de
Procedimientos.
Esto se debe a que muchas veces se utiliza la palabra software, como sinónimo de sistema de software.
softwa re? o
La arquitectura del software define el sistema en términos de sus componentes computacionales y de las relaciones entre ellos (Shaw &
Garlan, 1996)
¡
"Estructura o estructuras del sistema que comprende componentes de software, propiedades visibles de esos componentes y las relaciones entre ellos."
tectu ra o Ingeniero de software:
. . .
prgogupa de la parte estructural, y le preocupa poco .Se la estetlca. Se
preocupa de los costos, a corto y a largo plazo.
Sigueprocedimientos bien definidos, lo suyo es más lngenlerla que arte.
o Interactúa poco con el cliente, las revisiones apuntan más hacia él interior del equipo de trabajo.
. .
Trabaja en equipo.
Utiliza ciclos de trabajo medianos a largos.
o Construye en base a los requisitos funcionales.
ü
.
itectu ra dE
Arquitecto de software:
. .
Se
preocupa de la parte estéticay funcional (usabilidad).
No se preocupa de los costos asociados, ni de la parte estructural qüe no esté directamente relacionadá con su
trabaio.
.
No sigue procedimientos rígidos, lo suyo está más cerca del arte que qe la lngenlena.
¡ Interactúa mucho con el cliente. . Por lo general trabaja sólo o en grupos muy reducidos. . Utiliza ciclos de trabajo cortos. ¡ Construve en base a lo que al cliente/usuario le gusta....(requisitos no füncionales)
'i
Arquitectura de Software o La_división entre-el ingeliero y el arquitecto de software, es una línea'difusa. ' o Ambos roles son necesarios y son complementarios.... El problema es que l.ray que éer consciéntes de que un bgen lngenlero puecle no ser un buen arqurtecto, y
vlceversa.
o Debido a estas diferencias, la arquitectura como proceso o como producto,'puedé verse desde estos dos puntos cle vlsta.
o ... El desarrollo de software tradicional está más orientado al trabajo del ingeniero de software.
o
... El desarrollo de aplicaciones para Web está más orientado al trabajo tlel arquitecto de software.
.l
Qué es Arquitectura de Software
?
Como producto (según el ingeniero):
.
Un diseño de alto nivel.
o La estructura del sistema.
.
Los componentes de un.programa o sistema, sus relacionés, y los principiós que gobiernan su diseño y su evoluclon en el tlempo.
. Descomposición de la funcionalidad en grandes bloques. . Componentes, conectores, configuración y restricciones. . Selección entre distintas alternativas de arquitectura. . Es la clave del éxito a largo plazo.
Qué es Arquitectura de Software
?
Como Producto (según el Arquitecto):
. . . . . .
conjunto de patrones de: interfaz, estructura, navegación, y funcionalidad de un software. Interfaces y links. Un diseño que busca obtener una comprensión intuitiva del sistema a través de su interfaz. Es el
Páginas Web relacionadas.
Lo que el cliente/usuario desea. Es la clave del éxito a
corto plazo.
Qué es Arquitectura de Software
?
Como Proceso (según el Ingeniero):
. .
Es el proceso de diseño de los macrocomponentes del sistema y de sus relaciones. Es el proceso de diseño de la
funcionalidad básica del
sistema.
.
un proceso de diseño ingenieríl (paso a paso), basado en los requisitos. Es
. Es la entrada y la base para el diseño detallado. . Es el medio para probar las soluciones propuestas
para
alcanzar algunos de los requisitos.
Qué es Arquitectura de Software Como Proceso (según el Arquitecto)
?
:
. Es el proceso de definición de la imagen corporativa. . Es el proceso de diseño de la apariencia y usabilidad de un . .
. .
software. Es el proceso de captura/validación de las necesidades del
cliente/usuario. Es una forma de estructurar la informacióny la funcionalidad que ofrece un software. Es una forma de reduci¡ la ansiedad del cliente/usuario. Es una forma de que el cliente/usuario se sienta considerado dentro de un desarrollo.
ijencias de los partici
Funcionalidad Rendimiento otrgur rudu Seguridad
usabilidad
Bajo costl Rendimiento
(
.r'
,,/
.
soporte aPlicativo
--/.
"', -/^ooificab¡|idad
líder
de
Corto tiempo en mercado
mercadeo Bajo costo; ventajas con productos sim¡lares
tiempo
urrcr r(v Bajo costo y de entrega, que no camb¡e muy a menudo
*..-t..ffi:
Arq u itectu ra Vs. Diseño
La arquitéctura y el diseño difieren en tres áreas: Arquitectura Nivel de
Alto nivel
Bajo nivel. Enfoque específico en detalles
Planear subsistemas, interfaces con sistemas efernos.
Diseño detallado componentes.
servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectónico
Especificaciones de codificación
Abstracción Entregables
Areas de Enfoque
Diseño
Selección de tecnologías, Requerimientos no funcionales
(aoS), Manejo de riesgos
Requerimientos
funcionales
uitectura Requisitos
AnáIisis Diseño
Codificación
-
Diseño de la Base de datos Diseño de la
Prueba
Intefaz
Diseño de la Arquitectura de Software
ManténimiéntC
Diseño de detalle orocedimental
ncia de_le_€9€glcagi! a rq u Mejora la comunicación entre las personas involucradas. Brinda documentación temprana acerca de las decisiones de diseño. Brinda restricciones a la implementación. Premite la validación temprana del sistema,
¡tectu
ra-
Permite predecir las cualidades del sistema. Facilita la administración de la evolución. Podría derivar en las líneas de
productos compaften arquitectura. Establece una base para el entrenamiento de nuevo personal.
-H Distribución del Costo Oel Soffiraié
Programación
Mantenimiento
o ... diseñar buenas aquitecturas no sólo es rentable, también ayuda a mejorar la calidad del software obtenido. o Qué es calidad de software? e Qué significa la calidad de software, para el desarrollador, para el cliente y para el usuario? o Qué tiene que ver la arquitectura de software en este asunto? o Hay otras maneras de obtener calidad de software?
Aio-uite de Software o La mayoría de los requisitos de calidad pueden ser alcanzados, sólo si son considerados desde la Funcionalidad:
Usabilidad: Entendibilidad, Aprendibilidad,
Pertinencia, Precisión, Interoperabi lidad, Adherencia,
Operabilidad, Aceptación de Uso
Seguridad
Mantenibilidad:
Portabilidad:
Analizabilidad, Cambiabilidad,
Adaptabilidad, Instanciabilidad,
Estabilidad, Demostrabilidad
Adecuación, Reemplazabilidad
Eficiencia:
Confiabilidad:
Rendim¡ento,
Madurez, Tolerancia a Fallas,
Uso de Recursos
Recuperabilidad
La arquitectura de software define: . componentes - lugar de almacenamiento o cómputo: . filtros, bases de datos, objetos, TDAs, o conectores - mediadores entre componentes:
.
.
llamadas a procedimientos, pipes, broadcast,
propiedades - información para construcción y análisis del soffware:
.
pre/post condiciones, invariantes.
Un estilo o Datrón de arquitecturas una solución general a un problem'a recurre_nte, a partir del cual se obteñdrán arqüitecturas específicas pára los distintos problemas. Un estilo o patrón de arquitecturas define una familia, compuesta cle:
. componentes y conectores, . configuraciones, ¡
semántica de las restricciones.
i:
::
¿PaaaqHé Softwa re? o Las personas necesitan pensar, diseñar, codificar, y comunicarse en términos de grandes bloques. o Es necesario diseñar sistemas de larga vida. o Es necesario diseñar sistemas flexibles, extendibles, adaptables y ojalá de bajo costo de mantención. o En el caso de los sistemas para Web, deben soportar una velocidad de evolución altísima.
ra que o Reutilización de alto nivel: actualmente solamente se reutiliza el código y las estructuras de datos. o Atacar problemas del ciclo de vida del software: . modificabilidad, portabilidad, escalabilidad, eficiencia del proceso de desarrollo, seguridad. . A medida que el tamaño del sistema crece, las soluciones a estos problemas radican más en la arquitectura. o Tener un lenguaje común para diseñadores, desarrolladores y usuarios.... aunque aveces esto es sólo una expresión de deseo, mas que una realidad. o ..... Pero fundamentalmente, para poder cumplir con los "requisitos de calidad".
10
pleto
ámos el dibúo
Patrones
Arquitect - B.D. - Seguridad - Transaccionales - Web - Usuarios - etc.
... ala arquitectura del escenario
de trabajo,
también se la conoce como Arquitectura Física
¡.
^ LOnCtUSrOneS o Arquitectura de software y arquitectura de sistemas de software, son dos cosas distintas.
o No hay un concenso acerca de qué es y qué involucra la arquitectura de software. o ... Algunos sostienen que es complementaria a la ingeniería de software. o La arquitectura de software plantea desafíos que no han sido muy bien manejados por la ingeniería de software tradicional. o Diseñar una buena arquitectura no sólo es necesario, sino que además es una actividad rentable !!! o El ingeniero de software tradicional y el arquitecto de software, son dos roles complementarios y necesarios.
t1
TEMA 1 Introducción a la Arquitectura de SOftWa
fe : calidad, Requisitos funcionales y no funcionales
Ing. Josué Obed Yeizaga Gonzales MSc Universidad Autónoma Gabriel René Moreno Ing. Informática- Ing. De sistemas
Aspectos Relevantes en Calidad de Software Cuando se habla de "calidad de software", hay 2 aspectos que es necesario considerar:
-
Especificación de Requisitos: Trata toda la problemática asociada a la especificación de especificación de requisitos completos, sin ambigüedades, y verificables.
-
Procesos de Supervisión: Trata la problemática asociada al proceso de supervisión de procesos y productos.
En esta presentación nos abocaremos al primero de estos aspectos.
Ideas Relevantes..... La calidad es la clave del éxito en el negocio del software. Para mejorar la productividad del software construido, hay que mejorar su calidad. Para mejorar la calidad del producto, hay que mejorar la calidad del proceso.
-
La gestión es tanto o más impoftante que la tecnología.
Generalmente, lo que la gente entiende como calidad de software, tiene mucho que ver con diseño arquitectónico de sistemas.
eQué es Calidad
?
La calidad: "La totalidad de características y atributos de un producto o seruiciq que están relactonados con satisfacer necesídades expresas o implícitas'l
Calidad = Satisfacción La calidad depende de la expectativas...
"La calidad del software depende en gran medida del diseño arquitectónico realizado" .... Y el diseño arquitectónico depende de los requisitos de calidad.
aQué es Calidad
o
?
En esta presentación veremos qué es calidad desde el
punto de vista de los requisitos.
o o
Veremos qué significan los requisitos de calidad, para el proceso de diseño arquitectónico. Y cuál es la relación entre ellos.
ZPor qué Necesito Calidad ? La calidad:
-
Es un asunto de competitividad Es esencial para sobrevivir Es esencial para expoftar Es rentable
Retiene clientes y aumenta las utilidades
Fuentes de Baja Calidad Requisitos imprecisos, mal entendidos o incompletos. Defectos en el software construido.
Arquitecturas de sistema pobres o mal diseñadas. Defectos en el sopofte prestado. Falta de monitoreo del proceso y del producto. Etc.
Problemas de la Ing.de Soft. El principal problema pafte con la: " falta de claridad en los requisitos". Si queremos tener éxito debemos definir, debemos definir éxito en función de:
-
Costos Plazos Recursos
Satisfacción de Requisitos Etc.
objetivos no son claros, no los alcanzaremos claramente".
"Si los
Requisitos Vagos.... Ejemplos: "La funcionalidad del nuevo sistema debe ser mejor que la del sistema anterior". "El nuevo sistema debe tener una interfaz en Visual Basic que lo haga más fácil de usar, en pafticular sin las dificultades de uso del sistema actual". "El sistema brindará mejores repoÉes de modo que se pueda aprovechar al máximo la Base de Datos". "El sistema asegurará que los datos sean correctos".
Requisitos Vagos.... Consecuenc¡as:
- No podemos demostrar que hemos logrado los objetivos - No podemos demostrar que no los hemos logrado - No podemos diseñar la arquitectura sonbre requisitos incompletos o mal definidos.
- No podemos evaluar alternativas
de diseño
-
y no fines
Se termina especiflcando medios
Si hay más de una forma de expresar un objetivo, tal vez no es un objetivo, sino un medio para lograr algo. Por ej. la interfaz en VisualBasic
Tipos de Requisitos
o
Requistos de Usuario:
Expresan las necesidades del
usuario.
o
Requisitos de Software: Expresan las capacidades que debe tener el software, para poder satisfacer los requisitos del usuarios.
Por otra parte también están:
- Requistos Funcionales - Requisitos de Calidad - Requisitos de Restricción
Tipos de Requisitos
o Requisitos Funcionales:
indican éQué?.
Deben ser alcanzados si o sí.
o Requisitos de Calidad: indican écuán bien?. La calidad final dependerá del logro de estos objetivos
.
Requisitos de Restricción:
¡ndican éCuánto?.
En función de costos, tiempos, personal, etc.
- Los requisitos más difíciles de especificar son los req. de calidad.
- Los requisitos funcionales y los de restricción, se suelen especificar bien.
6
Tipos de Requisitos o de Usuario o o
de Funcionalidad de Restricción
de Software (o mas bien, de sistema) o
de Funcionalidad
o de Calidad o de Restricción
Requisitos ->Atributos del Soft. "todos los requísitos de calidad pueden y deben ser especificados sin a m big üedades" "/os requisitos determinan los atributos
del
software"
o Si un requisito está claramente expresado (por ej. terminar antes del31512001), se le da prioridad por sobre otros requisitos no tan claros ("más fácil", "mejor", "consistente", "amigableJ
o Si queremos que los datos sean consistentes (por ej.), debemos indicar a que le llamamos "consistente".
o Veamos el siguiente ejemplo...
7
Ejemplos de Requisitos de Calidad
o o
Estos atributos deberían ser revisados a la hora de especificar un sistema. Debido a que aparecen en Ia mayoría de ellos.
Entre los Requisitos de Calidad Trpicos figuran:
Funcionalidad: Peftinencia
Precisión
| | Usabilidad: | | Entendibilidad
I I ||
I Interoperabilidad I
Adherencia
Aprendibilidad Operabilidad Aceptación de Uso
Seguridad
Ejemplos de Requisitos de Calidad
(cont...)
o
Entre los Requisitos de Calidad Trpicos figuran: Mantenibilidad:
Poftabilidad:
Analizabilidad
Adaptabilidad
Cambiabilidad
Instanciabilidad
Estabilidad
Adecuación
Demostrabilidad
Reemplazabilidad
Eficiencia:
Confiabilidad:
Rendimiento
Madurez
Uso de Recursos
Tolerancia a Fallas Recuperabilidad
Requisitos Usuales Importantes Los requisitos de calidad antes mostrados, casi siempre deben ser especificados. Esa lista de requisitos debería formar parte de
la plantilla estándar.
- Asíse disminuye el riesgo de no especificar requisitos obvios
- Es más fácil acordarse de qué preguntar, o de
negociar con el cliente en caso de ser necesario.
- Los nuevos empleados pueden aprender de cómo hacemos las cosas aquí.
Requisitos Usuales Importantes
(cont...)
- Funcionalidad -Confiabilidad
- Usabilidad - Eficiencia - Mantenibilidad - Portabilidad o Estos requisitos son conocidos como las " ilidadel'de un software.
Funcionalidad
o Conjunto de requisitos referidos a la existencia las capacidades de un software.
o Las capacidades que satisfacen necesidades expresas o implícitas de los usuarios.
o Sus sub-requisitos Peftinencia:
son:
la existencia de funciones apropiadas para
las tareas especificadas.
Precisión:
la capacidad de entregar resultados correctos o con un grado de error acotado.
Funcionalidad (cont...) Interoperabilidad:
la habilidad de interactuar con determinados sistemas (No confundir con reemplazabilidad).
Adherencia:
la compatibilidad con estándares, convenciones o regulaciones.
Seguridad:
la habilidad de prevenir uso no autorizado, tanto intencional como accidental, de programas y datos.
t0
Confiabilidad La capacidad de mantener un nivel adecuado
de servicio, bajo cieftas condiciones y por cierto tiempo. Sus sub-requisitos son :
Madurez: atributos relacionados con la frecuencia de fallas por errores del software
Tolerancia a Fallas: habilidad de funcionar aún después de cieftas fallas
Recuperabilidad: capacidad, tiempo y costo para reestablecer un nivel de servicio, y recuperar datos después de una fallas
Usabilidad Atributos (o requisitos) relacionados con el esfuerzo de uso, y la evaluación del uso, realizada por los usuarios. Entre sus sub-requisitos están: Entendibilidad: posibilidad de que los usuarios reconozcan los conceptos y su aplicabilidad
Aprendibilidad: esfuerzo necesario para adquirir un determinado nivel de destreza
Operabilidad: esfuerzo necesario para operar y controlar la operación del software
Agrado de uso: evaluación subjetiva (encuesta) hecha por los usuarios
11
Mantenibilidad Atributos (o requisitos) relacionados con el esfuerzo de hacer modificaciones. Entre sus sub-requisitos están: Analizabilidad: esfuerzo de diagnosticar deficiencias o causas de fallas, o de identificar las partes modificar
a
Cambiabilidad: esfuerzo de hacer un cambio Estabilidad: riesgo de efectos inesperados por realizar un cambio
Demostrabilidad: esfuerzo de comprobar o validar la corrección
Portabilidad Habilidad de ser transferido de un ambiente a otro. Entre sus sub-requisitos están: Adaptabilidad: capacidad de adaptarse a otros ambientes usando los medios del software
Instalabilidad: esfuerzo de instalación en un determinado ambiente
Adecuación: adherencia a estándares o convenciones de poftabilidad
I2
Portabilidad (cont...) Reemplazabilidad: posibilidad de ser usado en lugar de otro software, en el ambiente del otro. NOTAS:
1- No debe confundirse con interoperabilidad (algunos llaman a ambos "compatibilidadJ 2- La reemplazabilidad está relacionada con la instalabilidad y la adaptabilidad. Debido a su impoftancia, se poner por separado.
Eficiencia
.
Relación entre el nivel de rendimiento, y la cantidad de recursos usados, bajo ciertas condiciones. Uso del Tiempo: requisitos relacionados con tiempos de respuesta, tiempos de procesamiento, o tasas de seruicio (throughput) Uso del Recursos: requisitos relacionados con el uso de recursos o Cantidad de recursos o Duración del uso
I3
Requisitos Críticos Muchas veces hay atributos tan impoftantes y conocidos, gu€ por obvios nadie los dice.
Principio de lo obvio: "Las cosas obvias, que todos saben, no se pueden dejar que se cuiden solas..."
Un atributo crítico es aquel que si está fuera de control, amenaza la viabilidad de la solución.
-
El olvidarse
de 1 sólo atributo crítico puede ser suficiente
para un desastre.
Un requisito crítico puede ser de calidad, funcional, o de restricción.
¿Qué Requisitos Especificamos? o Todos.... especialmente los críticos o A veces "los atributos dependen mucho del
problema" Normalmente debemos hacer una lista de atributos relevantes para cada proyecto Es importante revisar proyectos similares,
que hayamos hecho, para chequear si nos falta algo importante.
I4
Ventajas de Especificar Requisitos La utilización de métricas es engorrosa, pero tiene varias ventajas: Para los Clientes: Cefteza: Tiene más probabilidad de obtener lo que quiere
Comparación: Las ofeftas de distintos proveedores son comparables Clarificación: Se promueve una discusión temprana de los temas Demostrabilidad: Será más fácil determinar si los requisitos fueron o no cumplidos
Ventajas de Especificar Requisitos (cont. . . ) Para la Fuerza de Ventas: Cefteza: Menor probalibidad de perder una propuesta por no entender los requisitos
Sabremos antes que la competencia que es lo que se necesita
Imagen:
Se nos percibirá como realmente interesados en saber qué es lo que se necesita Riesgo: Sabemos qué ? y cuánto? se necesita
Control de Cambios: Podemos demostrar que nuevas solicitudes, deben ser tratada como cambios Claridad; Podemos hablar sin ambigüedades y sin doble sentido, sobre: - Las fortalezas de nuestra propuesta - Los resultados esperados, en lugar de promesas vagas.
15
Ventajas de Especificar Requisitos (cont...) Para Desarrolladores y Subcontratistasl
- Podemos basar las estimaciones en un -
entendimiento firme de los requisitos El cliente no nos puede sorprender con requisitos más exigentes, sin estar dispuesto a pagar/negociar la diferencia Podemos diseñar por objetivos, lo cual tiene más posibilidades de éxito, que hacer algo y ver si sirve.
- Puedo ejercer un "control de cambios". o Nosotros debemos
tener la sartén por el mango, no el cliente.
Conclusiones "Especificar la calidad" no significa que mi software (o mi sistema) será de "buena calidad". 'tEspecificar la calidad" significa que conozco lo que debo entregar al cliente. "Especificar Ia calidad" significa que el cliente sabe lo que debo entregar. "Especificar la calidad" significa que conozco mis limitaciones, por lo tanto puedo trabajar para superarlas. "Especificar la calidad" me ayuda a presentar presupuestos realistas, y a no perder dinero.
L6
Conclusiones No existe la posibilidad de desarrollar o comprar'tun software de calidad".
Siempre hay que especificar la calidad.... pero que eso no sea el centro de mi proyecto. a
No caer en una "parálisis por análisis".
o
Revisar los requisitos usuales, y preguntar por ellos !!!, siempre antes de entregar un presupuesto. No se permitan ambigüedades... el cliente puede ser más vivo que ustedes...
Un buen cumplimiento de los requisitos de calidad, generalmente está asociado a un buen diseño arquitectónico del sistema.
l7
