Archivo de la etiqueta: desarrollo

STORM Methodology – Metodología STORM – Software Development – Desarrollo de Software


Strategic and Tactical Objectives by Role Methodology (STORM) is a new software development methodology create by Matías Creimerman.

In the next posts I will describe and explain the concepts and the steps of this new methodology.

La Metodología de Estrategia y Táctica de Objetivos por Roles es la nueva metodología de desarrollo creada por Matías Creimerman.

En los próximos posts, describiré y explicaré los conceptos y los pasos de esta nueva metodología.

electric-bolt

Autor: Matías Creimerman

Personal Website
Linkedin Profile

Blog
GitHub
Facebook
Twitter
Google+
Youtube
Asp.Net Member Profile
MVA Profile
MCP Profile (Microsoft Certifications)

electric-bolt

Matías Creimerman

Matías Creimerman Certifications

Matias Creimerman

 

Anuncios

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría

Manifiesto del desarrollo de software en equipo


1. No ser conformistas.

2. Ser autenticos e incentivar la autenticidad en el grupo, para que cada uno con su forma y manera de ser, realice sus tareas a gusto y no sobre base de consignas rígidas impartidas.

3. Trasmitir el QUÉ por sobre el CÓMO. Es más importante saber QUÉ hay que hacer y no CÓMO hacerlo.

4. Incentivar la autogestión. Dejar que cada uno investigue y trate de resolver los problemas por su cuenta. Dar soporte y guíar a los compañeros por sobre obligarlos a hacer algo en particular.

5. Fortalecer nuestras misiones, tanto las personales como las grupales.

6. Explotar nuestras fortalezas y ponerlas al servicio del equipo y del cliente. Tratar de dar a conocer nuestras fortalezas o buscarlas.

7. Adaptemos las tareas según las fortalezas de cada integrante. Si alguien no puede o no le gusta realizar una tarea, buscar complementarla o asignarla al más adecuado.

8. Preguntar siempre “Por qué” y ofrecer un “Y si…”.  Cuestionemos las cosas y las personas para la evolución continua.

9. Entender que no todo es perfecto, ni la empresa, ni el cliente, ni el equipo, ni las personas.

10. Buscar desafíos, proponerlos o pedirlos, para nuestro progreso personal.

11. Tratar de buscar la innovación y de inyectarla en nuestras tareas.

12. Buscar nuestro progreso personal con la capacitación y la mejora continua.

13. Asumir responsabilidades y cargos con actitud.

14. Abrirse a nuevos puntos de vista y fomentarlos. Ver los problemas desde distintos puntos de vista.

15. Poner al equipo por delante de las personas.

16. Ser prácticos.

17. Animar a las opiniones disidentes.

18. Apoyar la discrepancia para evaluar alternativas.

19. Apoyar al equipo.

20. Lograr los objetivos.

Deja un comentario

Archivado bajo Filosofía de Equipo

LINQ UNION-ADDRANGE DIFFERENCE – DIFERENCIA


Hoy me preguntaron si no era lo mismo hacer un AddRange en una colección que un Union de LINQ y claramente la respuesta es NO!.

Por qué no es lo mismo hacer un AddRange que hacer un Union y asignar a la misma colección?

Porque el AddRange repite información en cambio el Union no agrega datos repetidos (salvo que sean instancias distintas con colecciones de objetos).


Today a developer asked me if using AddRange over a collection was the same that using LINQ’s UNION, and as a matter of fact the answer was “NO!”.

Why is not the same to do AddRange or to do Union and assign to same collection?

Because the AddRange repeats information, on the other hand, UNION does not add repeated data (unless they are different instances with object collections).

Veamos código (Let’s check out code)…

class Program
{
static void Main(string[] args)
{
Console.WriteLine(“*******************************”);
Console.WriteLine(“Probando Union y AddRange”);
Console.WriteLine(“*******************************”);

Console.WriteLine(“Agrego a la lista nros del 1 al 10”);
List list = GetNewList(0, 10);

Console.WriteLine(“Creo otra lista de nros del 1 al 10”);
List list2 = GetNewList(0, 10);

Console.WriteLine(“Hago un Union y muestro”);
list = list.Union(list2).ToList();

foreach (var l in list)
{
Console.WriteLine(“Nro: {0}”, l);
}

Console.WriteLine(“Reinicio listas, hago AddRange y muestro”);
list = GetNewList(0, 10);
list.AddRange(list2);

foreach (var l in list)
{
Console.WriteLine(“Nro: {0}”, l);
}

Console.ReadKey();
}

static List GetNewList(int baseNumber, int length)
{
List rv = new List();
for (int i = baseNumber; i < length; i++)
{
rv.Add(i);
}
return rv;
}
}

unionaddrange

Deja un comentario

Archivado bajo Código

No utilices debug=”true” en ambientes productivos en websites ASP.NET- Don’t use debug=”true” in production environments on ASP.NET websites


Prohibido utilizar debug=”true” en ambientes productivos

Not use debug=”true” in production environments

Por qué no hacerlo?

  1.  La compilación de las páginas lleva mucho más tiempo, ya que se deshabilitan algunas optimizaciones.
  2. El código se ejecuta más lentamente ya que algunas ejecuciones en debug, ejecutan más código.
  3. Todo lo descargado por WebResources.axd no se almacena en el caché del navegador, lo que ocasiona más solicitudes entre cliente y servidor.
  4. Se cargan símbolos de depuración.
  5. Puede permitir algunas vías de ataques y la capacidad de detectarse de forma remota.
  6. Se generan más archivos temporales de ASP.NET y la compilación por lotes se desactivará, incluso si el atributo de lote es verdadero en el elemento .
  7. El System.Diagnostics.DebuggableAttribute se agrega a todo el código generado que hace que el rendimiento se degrade. El DebuggableAttribute se agrega a todo el código generado.
  8. Se utiliza dentro de la aplicación en tiempo de ejecución mucha más memoria.

 

Why don’t do it?

  1. The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled).
  2. Code can execute slower (since some additional debug paths are enabled).
  3. Scripts and images downloaded from the WebResources.axd handler are not cached by the browser, resulting in more requests between client and server.
  4. Compiled with debug symbols are loaded.
  5. Debug mode may open some pathways to other exploits based on the performance overhead it places on the app and the ability to remotely detect it.
  6. You will see a lot more files in Temporary ASP.NET files folder
    Batch compilation will be disabled even if the batch attribute is true in the element.
  7. The System.Diagnostics.DebuggableAttribute gets added to all generated code which causes performance degradation.Basically, when you have debug=true, the DebuggableAttribute gets added to all generated code.
  8. Much more memory is used within the application at runtime.

Deja un comentario

Archivado bajo Buenas Prácticas, Uncategorized

BASM – Broken Authentication and Session Management -Evitarla en ASP.NET Webforms


Normalmente se cree que una sesión de usuario de una aplicación ASP.NET en webforms con IIS, no puede “quebrarse” o ser interceptada por otro cliente, pero esto no es realmente así. Solución

Hace unos años me pidieron que solucione este problema en una aplicación que estaba siendo vulnerada.

La aplicación estaba programada de la siguiente manera (no pondré los nombres reales, utilizaré ejemplos):

Web.Config:

Evento de logout:

Membership.DeleteUser(Membership.GetUser(true).UserName, true);
MembershipProvider.SignOut(MembershipLogoutMethods.CloseButton);
FormsAuthentication.SignOut();
Session.Abandon();
Response.Cookies[“ASP.NET_SessionId”].Expires = DateTime.Now.AddSeconds(-30);
Response.Cookies.Add(new HttpCookie(“ASP.NET_SessionId”,””));

Los programadores cuando hacian las pruebas, no detectaban ninguna falencia y probaban agregar distintas alternativas o lineas de código similares para “matar” y cerrar la sesión, pero seguían con el problema.

Inmediatamente analicé la situación y comencé a probar, con algunas herramientas, intercepté los request desde mi navegador y cambiaba los parametros. Efectivamente podía ingresar a la aplicación y “quebrar” su seguridad, hasta podía utilizar distintos usuarios.

Entonces, cuál era el problema?

Muy pocos saben que las sesiones de ASP.NET tienen un tiempo de vida “extra” en el IIS.
Por lo qué pude ver alguna vez decompilando las librerias de .NET, el IIS, da un tiempo más de vida a las sesiones en el servidor para evitar (por lo que supongo al ver el código) que tenga problemas de performance el servidor. Pero lo que claramente se puede observarse es que no “mata” la sesión. Entonces uno puede enviar la cookie de autenticación desde otro cliente y sigue “logueado” a la aplicación.

Cuál es la solución?

Siempre hay que crear una variable de sesión que se inicialice en el login y se elimine en el logout.

En el global.asax, para cada request que ingrese a la aplicación, hay que verificar que esa variable siga vigente (con valor o con un valor particular, cómo por ejemplo, el ID de usuario), en caso contrario, el request es cancelado.

También se podría para fortalecer esta práctica, crear además otra cookie de autenticación customizada y que se valide con la variable del servidor y verificar ambas en cada request.

También conviene realizar una rutina que “mate” todas las sesiones abiertas que no tengan request o actividad durante cierto tiempo, porque sino, si el usuario no hace logout, la vulnerabilidad sigue vigente hasta que el IIS “mate” la sesión, se reinicie la aplicación o se recicle el pool de aplicación.

Autor: Matías Creimerman

Matías Creimerman – Consultor IT – IT Consultant

Linkedin:

http://ar.linkedin.com/in/matiascreimerman

Microsoft ASP.Net Member:

http://forums.asp.net/members/matyvegan.aspx

Microsoft Virtual Academy Profile:

https://www.microsoftvirtualacademy.com/Profile.aspx?alias=824999

About Me:

https://about.me/matiascreimerman

GitHub Repository:

https://github.com/mcrei/

certifications

mcsdlogo weblogo

Matias Creimerman

Deja un comentario

Archivado bajo Buenas Prácticas, Código, Seguridad

.NET Buenas Prácticas – Clases, estructuras e interfaces


Las clases y estructuras deben usar nomenclatura Pascal y deben tener nombre de sustantivos o frases de sustantivos, por ejemplo: “Car” o “CarType”.
De esta forma se diferencian de los métodos que son frases verbales.

Las interfaces deben usar nombres de frases de adjetivo, o de vez en cuando con nombres o frases nominales. Sustantivos y compuestos deben ser utilizados en raras ocasiones ya que podrían indicar que el tipo debe ser una clase abstracta, y no una interfaz. Por ejemplo: “IFormatable”.

No usar prefijos en ningún caso. Solo las interfaces deben incluir el prefijo “I”, por ejemplo: “IComparable”

En la mayoría de las ocasiones se recomienda terminar el nombre con el de la base clase, por ejemplo: “ArgumentOutOfRangeException”. De esta forma se da claridad y relación, pero hay ocasiones en las cuales no debería usarse (la clase Button es de tipo Control, pero no por eso se la denomina ButtonControl). Queda a consideración de cada uno si lo incluye o no, pero en muchas ocasiones es mejor agregar la clase base al nombre.

Nomenclatura para tipos que heredan de tipos base

Atributos (System.Attribute): Agregar sufijo “Attribute”

Delegados (System.Delegate): Agregar sufijo “EventHandler” para los eventos y “Callback” para los que no son eventos. Nunca usar “Delegate”.

Argumentos de Eventos (System.EventArgs): Agregar sufijo “EventArgs”.

Enumeradores (System.Enum): Nunca usar prefijos ni sufijos como por ejemplo “Enum” o “Flag”.

Excepciones (System.Exception): Usar sufijo “Exception”.

Colecciones (IEnumerable, ICollection, IList, IEnumerable, ICollection, IList): Usar sufijo “Collection”.

Flujos (System.Stream): Usar sufijo “Stream”.

Permisos (CodeAccessPermission, IPermission): Usar sufijo “Permission”.

Enumeradores

Utilizar un nombre de tipo singular para una enumeración a menos que sus valores son campos de bits.

Utilizar un nombre de tipo plural para una enumeración con campos de bits como valores, o los denominados “banderas/flags”.

Nunca usar el sufijo ni prefijo “Enum” o “Flag”.

Nunca utilizar ningún tipo de prefijo.

1 comentario

Archivado bajo Buenas Prácticas, Código

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.

Deja un comentario

Archivado bajo Teoría