martes, 31 de enero de 2012

Ingeniería de Requerimientos

Condición o capacidad requerida por el usuario para resolver un problema o alcanzar un objetivo.

Condición o capacidad que debe satisfacer o poseer un sistema o un componente del sistema para satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto.

Definición según IEEE.


Rama de la Ingeniería del Software que trata con el establecimiento de los objetivos y restricciones de los sistemas de software.

Asimismo, se ocupa de la relación entre estos factores con el objetivo de establecer especificaciones precisas.

Definición según Zave.


Es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema.

Definición según Bohem.


Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y cooperativo de análisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido.

Definición según Loucopoulos.


Es el proceso mediante el cual se intercambian puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos.

Definición según Leite.


En requerimiento es una condición o una capacidad a la que el sistema (siendo construido) debe conformar.

Un requerimiento de software puede ser definido como:

  • Una capacidad de software necesaria por el usuario para resolver un problema o alcanzar un objetivo.
  • Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato, especificación, estándar u otra documentación formal.

Definición general.


  • Los Requerimientos del usuario son declaraciones en lenguaje natural y en diagramas de servicios que se espera que el sistema proporcione y las restricciones bajo las cuales debe funcionar.
  • Los Requerimientos del sistema establece con detalle las funciones, servicios y restricciones operativas del sistema.
  • El Documento de Requerimientos debe ser preciso; debe definir exactamente qué es lo que se va a implementar.
  • Los Requerimientos Funcionales son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares y su comportamiento en estas situaciones. En algunos casos se indica lo que el sistema NO debe hacer.
  • Los Requerimientos No Funcionales son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, proceso de desarrollo y estándares.
  • Los Requerimientos de Dominio provienen del dominio de aplicación del sistema y reflejan las características y restricciones de ese dominio. Pueden ser Funcionales o No Funcionales.

martes, 24 de enero de 2012

Ciclo de Vida Genérico

Extraído de las páginas del libro "Successful Software Development", comparto este esquema de un ciclo de vida genérico para el Desarrollo de Sistemas de Software.

Todo el Desarrollo gira sobre la Administración del Proyecto y un área denominada Garantía de Producto.

  • El WHAT especifica el qué es lo que el software tiene que hacer.
  • El HOW especifica el cómo el software hará lo que tiene que hacer.
  • El BUILD construye el código implementando las especificaciones del HOW.
  • El USE es la implementación operacional del software ejecutando el WHAT.

Espero seguir publicando con mayor frecuencia

viernes, 20 de enero de 2012

Guiado por unos tutoriales de Yii

Después de tomar un tiempo para leer y hacer unas pruebas, guiado obviamente por unos tutoriales de Yii, tal parece que tendré que intentar usarlo para el desarrollo de mi aplicación personal.

Ya platicaré en futuras publicaciones de cómo me fue y espero sobre todo que la curva de aprendizaje no sea tan prolongada. Los ejercicios de prueba me dieron una impresión de que al menos no es tan difícil el uso de los modelos.

Cualquier duda u opinión será bien recibida.

miércoles, 18 de enero de 2012

Para no olvidarme de PHP

Ayer nació una necesidad personal de elaborar una aplicación para uso personal. Decidí desarrollarla con PHP. De modo que vi una buena oportunidad para intentar usar un framework de PHP.

Hace poco más de 18 meses intente usar Zend. Resultado: Por mi falta de experiencia de uso de frameworks, fue complicado, no comprendí como funciona Zend. Siguiente intento fue CakePHP. Más o menos le entendí a los tutoriales aunque no veía como trabajar con este framework. Estos últimos 6 meses nuestro Equipo de Desarrollo de Aplicaciones Web trabajó con el framework de Django (Python) debido a que un compañero de nuestro equipo ya tiene experiencia con el uso del framework. Muy bueno Django, pero tal vez ahora que estoy algo ya familiarizado con la implementación de este framework puedo deducir que será más intuitivo tratar de aprender algún framework de PHP. Es como los lenguajes de programación: cuando ya sabes hacer funcionalidades con código de un lenguaje, al migrar a otro lenguaje solo investigas como hacer aquellas funcionalidades en este nuevo lenguaje.

De modo que después de una pequeña investigación seleccioné el framework Yii y estoy dando mis primeros pasos.

Este es el sitio del framework Yii para que lo consultes por si he logrado despertar algún interés sobre este framework. Y por qué no, tal vez podríamos intercambiar dudas y experiencias sobre el mismo para reducir la curva de aprendizaje sobre el mismo.

Próximamente compartiré experiencias sobre Yii, desde luego.

martes, 17 de enero de 2012

Leyendo... (Success Software Development, Cap. 1)

Un poco del libro Success Software Development.

Capítulo 1. Business Case.

Modelo de Madurez de Capacidades (CMM)

El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:

  • Definidas en un procedimiento documentado
  • Provistas (la organización) de los medios y formación necesarios
  • Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
  • Medidas
  • Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.

Los niveles son:

  1. Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.
  2. Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
  3. Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
  4. Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
  5. Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

(Fuente: wikipedia)

lunes, 16 de enero de 2012

¿Aventura o Reto?

Más allá de tener un blog, me he establecido un sencillo pero nada fácil reto: tener un espacio en el cual registrar mis experiencias como Desarrollador de Aplicaciones Web con Entornos Tecnológicos Open Source.

¿Aventura? Por el hecho de que no considerarme un profesional con experiencia en el área. De modo que el objetivo es recopilar toda información que haya sido de beneficio para mejorar dentro de el mundo del desarrollo de aplicaciones Web.

Acepto preguntas y sugerencias.