Miguel Matas Blog

Ingeniería y Arquitectura de Software, Proyectos IT, Programación, Personas, Problemas, Mejora Continua, la vida.

Archive for the 'Software' Category

Pen Computing

Hola,

Fantástico este video, no os lo perdáis.

Un abrazo.

Miguel.

No comments

Crisis y soluciones de software

El otro dí­a me preguntaban un grupo de personas que acaban de crear una pequeña empresa qué les podrí­a costar contratar una pequeña herramienta de gestión que les ayudara a automatizar el proceso de generación de informes que necesitan para su negocio.

La verdad es que es un poco tirarse piedras sobre el propio tejado, pero mi respuesta fue que no se volvieran locos, que por ahorrarse algo de tiempo al dí­a más barato les iba a salir, sobre todo en los inicios, que nunca sobra de nada, coger una hoja de cálculos y un editor de texto con un par de plantillas para solucionar su problema.

Y es que durante muchos años la gente se ha vuelto loca, y, sobre todo desde el ente píºblico se han gastado dinerales en construir aplicaciones web de gestión para llevar el control de cambios de bombillas en centros sociales y otras aplicaciones que no tienen ni un solo sentido desde el punto de vista de eficiencia económica (qué íºtil era que automatizara el enví­o del níºmero de serie del casquete de la bombilla que habí­an sustituido en el baño del centro…)

No os olvidéis, sobre todo ahora que no sobra de nada, que donde esté una hoja de cálculo, podréis solventar la mayorí­a de los problemas del dí­a a dí­a. La verdad es que después de unos años en este mundo, hemos visto a grandes empresas solucionar importantes problemas de gestión con una Excel; por lo que si ellos pueden, vosotros también.

Un saludo.

Miguel.

2 comments

Calidad Interna vs Calidad Externa (del Software)

Extraigo de los apuntos de la asignatura de “Calidad del Software” que estoy cursando actualmente (Itinerario de Adaptación a Grado de Informática para Ingenieros Técnicos), los siguientes conceptos asociados a Calidad Interna/Externa del Software.

Mucho ánimo a todos.

Un saludo.

1.2.3 View 3: Internal vs. External Quality

External Quality is the fitness for purpose of the software, i.e. does the software what it is supposed to
do?. The typical way to measure external quality is through functional tests and bugs measurement.
Some of the properties that determine the external quality of software are:

– Conformance to the product specifications and user expectations.

Reliability: Is the software working with the same level performance under different conditions
and during all the time.

Accuracy: Does the software do exactly what is supposed to do.

Ease of use and comfort: Is the software easy to use and responds in an amount time according
to user expectations?

Robustness: Does the software adapt to unforeseen situations, e.g. invalid input parameters,
connectivity lost…

Openness: Can the software be extended/adapted for future use cases.

Internal Quality is everything the software does not do. It’s the implementation, which the customer
never directly sees, and often does not want to spend time or money on. Ironically enough, it’s often
what determines whether projects succeed or not.

Internal quality is related with the design of the software and it is purely in the interest of development.

If Internal quality starts falling, the system will be less amenable to change in the future. Due to that,
code reviews, refactoring and testing are essential as otherwise the internal quality will slip. An
interesting analogy with debts and bad code design was developed by Ward [REF3].

Some of the properties that enable the process of product with good internal quality are:

Concision: The code does not suffer from duplication.

Cohesion: Each [module|class|routine] serves a particular purpose (e.g. it does one thing) and
does it well

Low coupling: Minimal inter-dependencies and interrelation between objects and modules.

Simplicity: The software is always designed in the simplest possible manner so that errors are
less likely to be introduced.

Generality: Specific solutions are only used if they are really needed.

Clarity: the code enjoys a good autodocumentation level so that it is easy to be maintained.

The external quality is sometimes compared with “Doing the right things” as opposed to “Doing the
things right” which should define what internal quality is.

External quality is checked through validation (usually through functional tests) while Internal quality is
checked through verification.

No comments

¿Cuál es el error?

Por favor, echadle una ojeada a este pequeño artí­culo, me he quedado encantado:

http://desdesarrollodesoftware.blogspot.com/2009/02/cual-es-el-error.html

Un poco más ampliado el sentido del artí­culo anterior, lo podéis encontrar en el artí­culo siguiente:

http://desdesarrollodesoftware.blogspot.com/2009/02/la-respuesta-cual-es-el-error-la.html

Saludos.

Miguel.

No comments

Diagnóstico Diferencial

Me hace mucha gracia, porque de vez en cuando veo algíºn capí­tulo de “House” en la 4, y hay una escena que se repite prácticamente en todos los capí­tulos, cuando House suelta su tí­pico “¡Diagnóstico Diferencial!” con todo el grupo de médicos alrededor intentando, a partir de algunos sí­ntomas lograr encontrar la fuente del problema.

Esta es una escena que, se repite también a diario en el mundo del software, sobre todo en fases de estabilización, o en herramientas que ya están trabajando en entornos de pre-producción y producción. De repente, algo falla en el sistema, ahí­ es cuando llega nuestro enfermo. El “sujeto” presenta algunos sí­ntomas, descritos en el error que mostró la aplicación cuando se produjo el problema, o la traza ampliada del error en el log, o el listado de conjunto de pasos que recuerda dar el usuario antes de que se diera el fallo, una captura de pantalla, etc.

A partir de aquí­, la misma escena, grupo de expertos que estudian los mensajes e intentan obtener a partir de la información con la que cuentan, la fuente del error. Se producen además las siguientes coincidencias:

1) Primera y básica, ambos funcionamos contra-reloj. El error puede estar bloqueando nuestro sistema, o creando inconsistencia de datos en el mismo. Hay que resolverlo en el menor tiempo posible, sobre todo dependiendo de la gravedad del problema.

2) Los mensajes, sí­ntomas, pueden dar pistas que ayuden a encontrar fácilmente el problema, aunque a veces son poco descriptivos y no dan mucha información, y otras, incluso dan información que no ayudan a encontrar el problemas, es más, te llevan a conclusiones erroneas que hacen perder mucho tiempo para encontrar la fuente.

3) Otra forma de buscar la solución es mediante radiografí­as, escáneres del enferno, en nuestro caso, empezamos a revisar el código fuente de la zona que creemos afectada, el conjunto de datos almacenado en la base de datos… intentando así­ haciendo pequeñas incisiones en la “cara interna” de nuestro paciente, logramos encontrar el problema.

4) Dependiendo de la zona afectada, consultamos con diferentes expertos, Administradores de Bases de Datos, Arquitectos de Software, Arquitectos de Sistema, Analistas Funcionales y Desarrolladores. Segíºn cuál sea además el problema, tendrán que actuar unos u otros para resolver.

Curioso cuanto menos.

Saludos!

Miguel.

No comments

Solid RAD

Recientemente he tenido la oportunidad de participar en una presentación de Solid RAD, la herramienta para el desarrollo rápido de aplicaciones, ofrecida bajo el sello y garantí­a de calidad del equipo de Solid Quality Mentors

Jesíºs López y Daniel Seara (con el cual he tenido nuevamente el placer de coincidir) han sido los dos mentores de Solid que realizaron la presentación de forma conjunta.

A partir de la propia arquitectura y orientación de Solid RAD, la cual podréis conocer consultando el video provisto en el siguiente enlace mms://solidq.com/SolidRad (copiar el link y ejecutar pegando en la barra de dirección de Internet Explorer), destacar la inmensa oportunidad que supone compartir durante parte de una mañana, y de forma directa y personalizada, de los conocimientos y opiniones de los dos mentores. Lo que ha dado una pequeña “discusión” sobre el uso de las transacciones es algo que me gustarí­a exponer en un próximo artí­culo. A mi la visión me ha parecido genial.

Destacar entre otras cosas de Solid RAD, otras ideas fantásticas, como las de partir de un modelo de objetos de negocio para exponer el conocimiento a otras capas, pero sin orientar el modelo de objetos directamente a las entidades de datos, tal como harí­a un ORM, si no a las vistas definidas sobre dichas entidades de datos. Es una idea simplemente genial combiándola al mismo tiempo con el generador de código de Solid RAD, que automatiza la generación de las entidades de transporte de datos a partir de las propiedades de cada una de las vistas sobre la que es accedida.

Saludos.

Miguel.

No comments

El dí­a a dí­a del modelado Entidad-Relación. Enunciado.

[Actualizado a 05/10/2008]

A continuación os planteo un tí­pico problema de modelo entidad-relación en base de datos, en el que se debe modelar una situación bastante comíºn en un desarrollo de software. Os pedirí­a que intentarais resolver el problema sin ver antes las tres soluciones que marco al “ejercicio” en la parte final del post, y comprobar así­ finalmente cuál ha sido el tipo de solución más habitual. Os agradecerí­a además que razonarais la respuesta. En el caso de que vuestra solución no se ajuste a ninguna de las tres descritas, por favor, enviadme un diagrama a info@miguelmatas.es para que pueda adjuntarla al artí­culo. Serí­a estupendo además que en el razonamiento de vuestra solución no se limitara a las razones estrí­ctamente del modelo y la base de datos, si no que estuviera acompañada de algíºn razonamiento relacionado con arquitectura de software, orientación al negocio, eficiencia a nivel de datos, protección del dato, etc. En el caso de que no queráis “perder” tanto tiempo, me doy por satisfecho si contestáis al post indicando si vuestra solución se acerca a una de las tres primeras o ha sido otra 🙂

Gracias!

Enunciado:

Una conocida empresa de Rent a Car quiere informatizar su sistema de gestión de vehí­culos. En esencia, dicha empresa alquila de forma temporal los coches de los que dispone, y, en un primer proceso de ingenierí­a necesita contar con una descripción técnica de cómo se almacenarí­an el repositorio de los diferentes coches con los que cuenta en cartera.

La empresa cuenta con diferentes tipos de coches, son realmente los tipos de coches que maneja lo que la diferencia de los Rent a Car al uso, ya que los usuarios tienen la oportunidad de alquilar coches anfibios, coches voladores y coches oficiales blindados. Estos tres tipos de coche tienen algunas caracterí­sticas en comíºn que se desean conocer, como son la matrí­cula, el níºmero de puertas y la marca. Además, de forma especí­fica se necesita conocer el máximo de nudos a la hora a la que puede navegar un coche anfibio, los milí­metros de blindaje y el tipo de blindaje de un coche oficial blindado, y la autonomí­a de horas de vuelo con las que cuenta un coche volador.

Posibles soluciones de modelado entidad-relación:

Os pedirí­a por favor que no consultarais las soluciones hasta que hayáis desarrollado vuestra propia solución, para así­ no interferir en el resultado.

Solución 1

Solución 2

Solución 3

Solución 4 [nuevo 05/10/2008]

Saludos y gracias 🙂

Miguel.

4 comments