Archivo mensual: mayo 2012

La parte más dificil de desarrollar un sistema, es decidir qué desarrollar


“La parte más dificil de desarrollar un sistema es decidir qué desarrollar… ninguna otra parte hace fallar tanto el sistema resultante si se hace mal. Ninguna otra parte es más difícl de rectificar después”.

La experiencia acumulada a lo largo de los años de ejecutar proyectos indica que los proyecto exitosos son aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar al proyecto.

Es sin dudas un objetivo fundamental de los diseñadores de software alcanzar y mantener un nivel técnico en los sistemas, acorde con el desarrollo actual en la automatización de la información para la gestión y la dirección, y es conocida la importancia de la ingeniería de software para elevar la productividad y la calidad en diseños de sistemas automatizados a partir de un examen detallado de las metodologías existentes.

La rama de la metodología, dentro de la ingeniería de software, se encarga de elaborar estrategias de desarrollo de software que promuevan prácticas adaptativas en vez de predictivas; centradas en las personas o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicación intensiva y que requieren implicación directa del cliente.

Muchos investigadores en sus estudios acerca del tema de las metodologías de desarrollo de software se han detenido a definir el concepto de metodología, algunas de estas definiciones se muestran a continuación.

En el trabajo “Una Metodología para el desarrollo de Base de Datos” se dice que una metodología es un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de un producto de software.

Una metodología define:

• Estados, etapas o fases de un desarrollo, junto con los criterios de transición entre ellos.

• Tareas, actividades, etc.

• Roles, con sus skills necesarios y las interacciones entre ellos.

• Artefactos o entregables.

• Herramientas de control, seguimiento, medición y perfeccionamiento.

• Principios, criterios para tomar decisiones, estrategias para manejar distintos tipos de situaciones, herramientas de manejo de riesgos, etc.

La dificultad propia del desarrollo de software, y su impacto en el negocio, han puesto de manifiesto las ventajas, y en muchos casos la necesidad, de aplicar una metodología formal para llevar a cabo los proyectos de este tipo.

El objetivo es convertir el desarrollo de software en un proceso formal, con resultados predecibles, que permitan obtener un producto de alta calidad, que satisfaga las necesidades y expectativas del cliente. Atrás queda el modo de trabajar artesanal, que a menudo requiere grandes esfuerzos para obtener el resultado final, con los consecuentes desfases de fechas y coste, y es más que probable el desgaste personal del equipo de proyecto. Por lo que utilizar las metodologías implica mejoras en los procesos de desarrollo, en el producto y en la satisfacción del cliente.

Mejoras de los procesos de desarrollo

• Todos los integrantes del equipo del proyecto trabajan bajo un marco común.

• Estandarización de conceptos, actividades y nomenclatura.

• Actividades de desarrollo apoyadas por procedimientos y guías.

• Resultados de desarrollo predecibles.

• Uso de herramientas de ingeniería de software.

• Planificación de las actividades en base a un conjunto de tareas definidas y a la experiencia en otros proyectos.

• Recopilación de mejores prácticas para proyectos futuros.

Mejoras de los productos

• Se asegura que los productos cumplen con los objetivos de calidad propuestos.

• Detención temprana de errores.

• Se garantiza la trazabilidad de los productos a lo largo del proceso de desarrollo.

Mejoras en las relaciones con el cliente

• El cliente percibe el orden en los procesos.

• Facilita al cliente el seguimiento de evolución del proyecto.

• Se establecen mecanismos para asegurar que los productos desarrollados cumplan con las expectativas del cliente.

En ocasiones, el diseñador al escoger entre la variedad de lenguajes, técnicas, métodos y otros, prefiere hacer las cosas como mejor le convenga y sacar el diseño lo más pronto posible lo cual resulta ser una decisión nada acertada, que más que ayudar en tener un sistema lo más pronto posible funcionando resulta un sistema poco funcional donde abundará la generación posterior de errores.

Una mala práctica en el desarrollo de software, es comenzar a intentar desarrollar sin

realizar ningún tipo de análisis, tratando de partir del modelo de datos; esto generalmente

tiene drásticas consecuencias ya que no existe un orden para solucionar el problema. Surge la necesidad de seguir un proceso ordenado, esta es la Metodología.

La Metodología es definida como el conjunto de procedimientos basados en principios lógicos que son utilizados para alcanzar un objetivo. Seguir un proceso estructurado que se adapte a una situación específica al momento de desarrollar un software incrementa la probabilidad de éxito, ya que estas metodologías han sido probadas bajo ciertos factores en un contexto específico y han resultado exitosas, por lo que integrarla al proyecto consiste en identificar que metodología se acopla más a la situación y utilizarla.

Documentar el software es necesario independientemente de la estrategia de desarrollo que sigamos. Una buena documentación nos va a permitir mantener una visión completa del software, ayudándonos a comprender las características del sistema y a modificarlo en caso de que sea necesario. La documentación no se realiza para uno mismo, sino para los demás, ayudando a eliminar la dependencia de las personas.

Por lo tanto, documentar un software siempre será útil, aunque en un principio pueda no parecerlo. Tener una buena documentación, proporcional al tamaño del software desarrollado, puede ser tan importante como tener un buen software.

Uno de los grandes problemas que enfrenta el desarrollo de software, es la poca utilización de metodologías, la pequeña y mediana empresa creen que el uso de las metodologías es solo para las grandes, la postura de las empresas ante el mercado, es que se desea el producto completo lo más rápido posible, por lo que no consideran la necesidad de una metodología, como no miran el avance a corto plazo, lo siente una pérdida de tiempo y prefieren empezar a desarrollar lo antes posible sin dedicarle tiempo al análisis y diseño del software. La poca aceptación y la ignorancia es uno de los mayores retos hacia las metodologías ya que no se comprende la importancia fundamental en el desarrollo de software, al no ser utilizadas las consecuencias pueden ser catastróficas, el software en vez de ser una solución al problema, se convierte en otro problema que resolver. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.

Los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño donde se tardan muchas iteraciones en tener una parte importante del mismo en funcionamiento o más todavía, aquellos que siguen un ciclo de vida en escala, sufren importantes contingencias que pueden provocar que el mismo se vaya de las manos, por mucho empeño que se tenga y por mucho esfuerzo que se invierta.

¿Contingencias? Entre ellas es muy típico encontrarnos con el caso de algunas, como por ejemplo: funcionalidades mal definidas o implementadas, priorización deficiente de los desarrollos, procesos que antes eran de una forma, después son de otras y más tarde se vuelven a modificar, etc… que después nadie quiere hacerse responsable y todavía más si después nos encontramos con responsables funcionales que se van y luego vienen otros con otras ideas o enfoque y a los que le ha tocado continuar con los trabajos.

Al final, cuando los plazos se echan encima y/o el presupuesto empieza a agotarse, vienen las prisas y se empiezan a pedir responsabilidades generalmente al lado equivocado, el de los desarrolladores. Llegado a este punto, sobre todo si se piden explicaciones en niveles superiores de la jerarquía, llega la crisis.

¿Esto por qué no está?, ¡me he gastado tanto y no tengo resultados!, yo pensaba que esto estaba más avanzado y todavía le queda mucho, ¡lo necesito para ya!, y todo ese largo etcétera que estamos acostumbrados a escuchar.

Las crisis no se arreglan gritando o presionando más, sino que requieren un trabajo ordenado y el mismo empieza asumiendo cada parte que existe un problema y el papel que ha desempeñado en que se produzca. Eso realmente es lo más importante y difícil para solventar la crisis, reconocer que hay un problema y que se ha sido parte de él.

No se trata de hacer tabula rasa con lo que ha pasado. Quien se ha equivocado debe asumir las decisiones que ha tomado y el trabajo que ha realizado (o si no ha sido culpa directa suya, hacer como propias las decisiones de sus antecesores en su rol) y asumir las consecuencias de la misma. No obstante, eso es algo que cuando mejor corresponda al proyecto se deberá tener en cuenta.

Una vez que se reconoce el problema, se asumen decisiones y errores, ya queda el camino despejado y el esfuerzo liberado para comenzar a realizar las acciones necesarias para reconducir el proyecto, algo que por otra parte tampoco será fácil.

Anuncios

Deja un comentario

Archivado bajo Teoría

Controllers MVC


Fecha en que se escribió el post: 2009-05-20

Los Controllers son los encargados de “controlar” los request que se realizan hacia la aplicacion. Cada request es mapeado a un controlador particular encargado de dar el response al mismo.

Cada Controller se define en una clase que hereda de la clase System.Web.Mvc.Controller:

public class EmployeeController : Controller    { …

A su vez cada definicion de Controller para cada caso particular expone una serie de acciones. Que son estas Acciones? Las acciones son metodos expuestos por el Controller para atender cada request segun corresponda. Si por ejemplo hago un request a esta URL: http://localhost/Employee/Detalle/3 el metodo Detalle() del Controller Employee con el parametro 3, se ejecutara.

Todos los metodos deben ser publicos para poder atender los request. Hay que ser cuidadosos con que metodos exponemos o darle seguridad a cada uno para poder ser ejecutados (lo veremos más adelante). Las acciones expuestas por el Controller no pueden ser sobrecargadas y no deben ser estaticas.

Estas acciones dan un resultado o sea un response que son denominadas Action Result.

Los action result heredan de la clase ActionResult

Los action result mas comunes son:

  • Resultado HTML denominado ViewResult
  • Resultado vacio: EmptyResult
  • Redireccionamiento: RedirectResult
  • Resultado en JSON: JsonResult
  • Resultado JavaScript: JavaScriptResult
  • Resultado en texto: ContentResult
  • Descarga de archivo con contenido Binario: FileContentResult
  • Descarga de archivo con path: FilePathResult
  • Descarga de archivo con su stream: FIleStreamResult

Se puede llamar a los metodos de la clase base Controller para devolver un resultado desde la acción:

  • View que retorna un ViewResult
  • Redirect que retorna un RedirectResult
  • RedirectToAction que retorna un RedirectToRouteResult
  • RedirectToRoute que retorna un RedirectToRouteResult
  • Json que retorna un JsonResult
  • JavaScriptResult que retorna un JavaScriptResult
  • Content que retorna un ContentResult
  • File que retorna un FIleContentResult, un FilePathResult o un FileStreamResult

Cualquier valor que se quiera retornar que no sea un ActionResult se devolvera como un ContentResult.

Deja un comentario

Archivado bajo Teoría

ASP .Net Routing MVC


Fecha en que se escribió el post: 2009-05-14

Las aplicaciones ASP .NET MVC son aplicaciones centradas en logica y no en contenidos como en ASP .NET. Esto se debe a que los requests estan mapeados a acciones de los controladores y no a paginas como en ASP .NET.

Este mapeo a acciones de los controladores se denomina Routing. El routing utiliza una tabla de ruteo para mapear las acciones. Esta tabla se crea cada vez que se inicia la aplicacion. La definicion de la tabla se crea en el archivo Global.asax al momento de ejecutarse el metodo Application_Start(). El metodo MapRoute() del objeto RouteTable agrega una ruta a la tabla de ruteos. Por default una aplicacion MVC ejecuta el metodo de la siguiente forma:

RouteTable.MapRoute(“Default”,”{controller}/{action}/{id}”,new { controller = “Home”, action = “Index”, id = “” });

Esto significa que la ruta por default de la aplicacion (Default) sera igual a: domain/Home/. Esta ruta esta controlada por el controller Home y ejecutara el metodo Index con el parametro id igual a “”.

El routing debe configurarse, por default cuando creamos una aplicacion MVC se configura automaticamente.

Deja un comentario

Archivado bajo Teoría

Proceso de ejecución de una aplicación MVC en .NET


Fecha en que se escribió el post: 2009-05-10

Los request en una aplicacion basada en el framework ASP.NET MVC realizan acciones diferentes a las de una aplicacion ASP .NET.
Este es el orden de ejecución:

  1. Al primer Request desde el archivo Global.asax, los objetos Route (objetos que implentan RouteBase) son agregados al objeto RouteTable
  2. El modulo UrlRoutingModule (Un modulo HTTP) usa el primer objeto Route en el objeto RouteTable para crear un objeto RouteData el cual se usa para crear el objeto RequestContext (IHttpContext) e inicia el ruteo.
  3. Se crea un controlador de requests MVC. El objeto MvcRouteHandler crea una instancia de la clase MvcHandler y le pasa una instancia de RequestContext.
  4. El objeto MvcHandler usa la instancia del RequestContext para identificar el objeto IControllerFactory para crear el controlador.
  5. El MvcHandler llama al metodo Execute del controlador.
  6. El controlador determina a que metodo de que clase controladora debe llamar. Como la mayoria de todas las clases controladores heredan de la clase base Controller puede hacerlo determinandolo desde el ControllerActionInvoker. Así invoca al metodo correspondiente del request iniciado.
  7. El metodo invocado desde el controlador realiza su funcionalidad y retorna uno de estos tipos que se pueden retornar: ViewResult, RedirectToRouteResult, RedirectResult, ContentResult, JsonResult o EmptyResult.
  8. Si el request no coincide con ninguna ruta el UrlRoutingModule no hace nada y le pase el request al proceso habitual de ASP .NET o al procesamiento de solicitudes IIS.

Deja un comentario

Archivado bajo Teoría

Qué es la programación? (Parte 1)


Fecha en que se escribió el post: 2009-05-07

Programar es la tarea de crear las instrucciones necesarias para generar funcionalidades que un dispositivo pueda interpretar. Por ejemplo, para que un televisor funcione, fue necesario “programarlo” para que pueda prestar las funcionalidades para las que fue creado. En la mayoría de los casos los dispositivos electronicos son programables. Pero la programación adquirió un significado más importante desde que existen las computadoras, ya que estos dispositivos fueron creados para realizar multiples tareas que las realizan según el “software” que tengan instalado. Y qué es el software? es el conjunto de todos los aplicativos y programas que tiene un computador. Cada programa y aplicativo es un conjunto de instrucciones que han sido programadas para dar distintas funcionalidades.
Cada instruccion indica que paso debe tomar el computador para llevar a cabo una determinada tarea. Para realizar una tarea particular que puede ser un paso de otra tarea mayor, se agrupan las instrucciones dentro de “funciones”. Por ejemplo, una tarea que realiza el hombre habitualmente es la de comer. Para comer, el hombre realiza pequeñas funciones que dan como resultado esta tarea (abir la boca, morder, masticar, salivar, mover la lengua, tragar, etc). Y por qué la programacion necesita identificar estas “funciones”? porque algunas son reiterativas y se realizan de la misma forma, con lo cual, identificarlas nos permite programarlas una sola vez y reutilizarlas (por ejemplo abrir la boca no solo se realiza en la tarea de comer, sino tambien en la de hablar y otras más).
De qué forma se programa? cada tarea y sus funciones, están constituidas de una forma lógica, que se genera a partir de “algoritmos” y “estructuras de datos”.
Qué es un algoritmo? un algoritmo son las operaciones ordenadas para llegar a un determinado objetivo o solución. Existen muchisimos algoritmos, algunos son de indole cientifica y otros se llevan acabo frecuentemente en la vida cotidiana, desde las operaciones que debemos realizar para hacer nuestro trabajo hasta los calculos que realizamos en la escuela para llegar a una solución. No hay que confundir un algoritmo con un programa, aplicativo o sistema (algo que suele pasar) ya que el algoritmo es la definicion de ese método y un programa ejecutable en un computador es el conjunto de codigo escrito por el programador que luego se compila para ser entendido por el computador o dispositivo (el codigo se transforma a otro codigo que puede interpretar el computador o dispositvo, llamado codigo maquina).
El algoritmo no puede ejecutarse. La implementacion de ese algoritmo es la que se ejecuta, ya sea, desde un codigo de programacion o un circuito electronico, entre otros. Para que un algoritmo se implemente, necesita “procesar” o “computar” la informacion. Esta informacion es la “estrucura de datos” (variables, propiedades, valores, clases, objetos) que identifican la forma de agrupar logicamente los datos para manipularlos, de forma que existiendo “estructuras de datos” de entrada se lleguen a “estructuras de datos” de salida. Cuando se procesan las estructuran de datos, se las crean, se las modifican, se las eliminan, se las ordena, se las busca, etc.
Existen distintas estructuras de datos para definir tipos comunes que nos permiten utilizarlos de distintas formas para distintos casos. Por ejemplo, no es lo mismo una estructura de texto, que una numerica, que una de listas, que un conjunto, que una tabla…

CONTINUARÁ…

Deja un comentario

Archivado bajo Teoría

Hello world!


Ahora un blog de desarrollo y arquitectura de software.

😀

1 comentario

Archivado bajo Uncategorized