Tag Archives: requerimientos

ISO/IEC 27001

ISO/IEC 27001 es un estándar para la seguridad de la información (Information technology - Security techniques - Information security management systems - Requirements) aprobado y publicado como estándar internacional en octubre de 2005 por International Organization for Standardization y por la comisión International Electrotechnical Commission. Especifica los requisitos necesarios para

Scrum

Scrum es un modelo de desarrollo ágil caracterizado por: Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados. Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una

Herramientas gratuitas para UML

Existen herramientas gratuitas de buena caliadad para UML. Tanto Netbeans como Eclipse soportan esta funcionalidad con el ciclo completo de desarrollo desde generación de código hasta reingenieria. Esto, claro, si se quiere trabajar en Java. En .Net no he encontrado este grado de funcionalidad en herramientas Open Source. Una opción de bajo costo, relativo a RUP y similares, es Visual UML. Visual Paradigm tiene una edición limitada sin costo, Smart Development Environment Community Edition for Visual Studio.

UML, ejemplo sencillo sobre Modelado de un Proyecto Introducción a UML

Herramientas gratuitas para UML

Existen herramientas gratuitas de buena caliadad para UML. Tanto Netbeans como Eclipse soportan esta funcionalidad con el ciclo completo de desarrollo desde generación de código hasta reingenieria. Esto, claro, si se quiere trabajar en Java. En .Net no he encontrado este grado de funcionalidad en herramientas Open Source. Una opción de bajo costo, relativo a RUP y similares, es Visual UML. Visual Paradigm tiene una edición limitada sin costo, Smart Development Environment Community Edition for Visual Studio.

UML, ejemplo sencillo sobre Modelado de un Proyecto Introducción a UML

Levantamiento de requerimientos

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocio que serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance. El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.

Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:

  • Los usuarios no saben que es lo que quieren
  • Los usuarios no aceptan como un compromiso los requerimientos escritos
  • Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.
  • Los usuarios no están disponibles y la comunicación con ellos es lenta
  • Los usuarios no participan en revisiones de avance.
  • Los usuarios no entienden el proceso de desarrollo y no les interesa.

Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar.

Una guía simple en términos de la complejidad del sistema:

  • Aplicación mono usuario
    • Diagrama de casos de uso.
    • Diagrama de clases.
    • Diagrama de interacción.
  • Aplicación mono usuario, con manejo de eventos:
    • Añadir: Diagrama de estados.
  • Aplicación cliente servidor:
    • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
  • Aplicación compleja distribuida:
    • Todos.

Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo. Se puede extender la colección de elementos base de UML utilizando estereotipos.

Referencias:

Levantamiento de requerimientos

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocioque serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance.


El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.

Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:

  • Los usuarios no saben que es lo que quieren

  • Los usuarios no aceptan como un compromiso los requerimientos escritos

  • Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.

  • Los usuarios no están disponibles y la comunicación con ellos es lenta

  • Los usuarios no participan en revisiones de avance.

  • Los usuarios no entienden el proceso de desarrollo y no les interesa.


Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar.

Una guía simple en términos de la complejidad del sistema:

  • Aplicación monousuario

    • Diagrama de casos de uso.

    • Diagrama de clases.

    • Diagrama de interacción.



  • Aplicación monousuario, con manejo de eventos:

    • Añadir: Diagrama de estados.



  • Aplicación cliente servidor:

    • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.



  • Aplicación compleja distribuida:

    • Todos.




Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos.

El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo.

Se puede extender la colección de elementos base de UML utilizando estereotipos.

Referencias:

Database answers es un repositorio con más de 450 esquemas de datos para diferentes aplicaciones. Algunos usados como referencia en la documentación de Micorsoft SQL Server 2005

En el caso de .Net, Design patterns,  AJAX Design Patterns, and .NET training , tiene ejemplos en C# y VB

https://www6.software.ibm.com/developerworks/education/r-rsmvisual/

http://www.programacion.net/tutorial/uml/

http://www.clikear.com/manuales/uml/

http://odl-skopje.etf.ukim.edu.mk/uml-help/