Concepto de diseño

1. Cuando se “escribe” un programa, ¿se diseña software? ¿En qué difieren el diseño de software y la codificación?

No. En el diseño de software se “está dando forma” al producto final a entregar, es una planeación más que nada. Y la codificación es transformar en código todo lo planeado anteriormente.

1. Si el diseño del software no es un programa (y no lo es), entonces, ¿qué es? Una planeación del producto a entregar, donde se definen las características e incluso la interfaz del producto.

1. ¿Cómo se evalúa la calidad del diseño del software? Realizando una serie de revisiones técnicas, donde se evalúa el producto ya realizado con una serie de pruebas, que a la vez están regidas por lineamientos de calidad.

1. Estudie el conjunto de tareas presentado para el diseño. ¿Dónde se evalúa la calidad en dicho conjunto? Antes de la implementación de dicho diseño, haciendo una revisión técnica.

1. ¿Cómo se logra? ¿Cómo se consiguen los atributos de calidad estudiados en la sección 8-2-1? Al momento de empezar a realizar el diseño. Se estudia la estructura y los componentes del diseño, y al final se recurre a la revisión.

1. Dé ejemplos de tres abstracciones de datos y de las abstracciones de procedimiento que se usan para manipularlas.

Cuando en un hospital alguien pide una consulta, y se le registra en una base de datos.

Cuando vas a una gasolinera a que llenen el tanque del vehículo.

Cuando vas al banco a retirar dinero de tu cuenta, o incluso solicitar un préstamo.

1. Describa con sus propias palabras la arquitectura de software.

Es la manera en que está compuesto un sistema y/o producto, con todos sus componentes implantados y checando la manera en que estos “conviven” o hacen sus labores.

1. Sugiera un patrón de diseño que encuentre en una categoría de objetos cotidianos (por ejemplo, electrónica de consumo, automóviles, aparatos, etc.). Describa el patrón en forma breve.

Puede sonar un poco rebuscado: en mis experiencias con productos inteligentes (televisores, celulares y equipos de cómputo) siempre ha habido una regla “infalible” para “resolver” problemas que se presenten de manera esporádica, la regla del ingeniero en sistemas. Forzar el reinicio de estos equipos para que un problema pase a segundo plano o en golpe de suerte se vaya. Y si el problema persiste, consultar en internet de páginas confiables alguna solución más “ortodoxa”, y si hay persistencia, consultar con un profesional.

1. Describa con sus propias palabras la separación de problemas. ¿Hay algún caso en el que no sea apropiada la estrategia de divide y vencerás? ¿Cómo afecta esto al argumento a favor de la aplicación de modularidad?

Se presenta un problema grande para un solo trabajador o para todo el equipo. ¿Qué hacer? Trocearlo en partes más pequeñas y hacerlo más fácil y manejable. No he sabido casos en donde esta maravilla de regla no sea aplicable, pero puede que exista algún caso. Pero también es cierto que dividir todo para tener muchas más cosas pequeñas termina siendo un problema y un error grave, porque, ok, todo resulta “fácil” pero son demasiadas divisiones para el equipo y terminas perdiendo tiempo y recursos. Lo mejor es dividir hasta una cantidad aceptable donde tiempo y recursos lo permitan, y trabajar sobre lo que haya.

...