Continuando con los aspectos a tener en cuenta a la hora de hacer el planning de soluciones de SharePoint, es necesario tener en cuenta que en los proyectos de SharePoint como en los de otro tipo vamos a tener una serie de especificaciones funcionales que tenemos que saber interpretar. Estas especificaciones funcionales se derivan de los requisitos de negocio que a su vez se componen de requisitos funcionales y no funcionales. Los primeros son los que se obtienen a partir de lo que el cliente necesita para su negocio. Los segundos son los que están implícitos en la funcionalidad demandada. Toda estos requisitos se determinan a partir de las planning worksheets para MOSS.
Requisitos funcionales
Como sabéis, una función viene a ser aquel aspecto de una solución con la que el usuario interactuará de manera segura. Esto nos lleva a que los requisitos funcionales para una aplicación MOSS incluyan aspectos como:
- Funciones de negocio.
- Interfaces de usuario.
- Interfaces de programación.
- Capacidades.
- Interacción.
- Apariencia.
- Interoperabilidad.
- Navegación.
- Arquitectura de contenidos.
Muchos de estos requisitos aplican a varios tipos de aplicaciones y no son exclusivos de soluciones MOSS. Sin embargo, hay uno especial que aplica a SharePoint y que no es típica de las aplicaciones web tradicionales: la arquitectura de contenidos. Este requisito implica que los stakeholder claves y el equipo de diseño determinen que tipos de contenidos se podrían almacenara en cada uno de los siguientes niveles propios de SharePoint:
- Colección de sitios.
- Sitio.
- Página.
- Lista y biblioteca de documentos.
- carpetas y subcarpetas en listas y bibliotecas de documentos.
- Documentos.
- Elementos de lista.
Es importante destacar que es fundamental un buen diseño de la estructura de contenidos ya que esta afecta a la eficiencia de los trabajadores, la gestión de la solución, la escalabilidad, la seguridad, la funcionalidad de contenidos y la funcionalidad de búsquedas.
Requisitos No-Funcionales
Los requisitos no-funcionales aparecen normalmente bajo los requisitos tecnológicos o los requisitos de negocio. Por ejemplo, para una solución de negocio crítica es clave asegurar durante el diseño continuidad en los procesos de negocio. Por otra parte, normalmente los usuarios de negocio van a querer que la aplicación esté siempre disponible. Por lo tanto, nuestra misión como diseñadores de la solución pasa por identificar el nivel de continuidad de negocio que requieren los usuarios. ¿Cómo lo determinamos? Pues preguntando a estos usuarios e identificando a partir de sus respuestas agregadas que infraestructura y plataforma puede soportar los requisitos de disponibilidad de negocio solicitada.
Entre los requisitos no-funcionales que nos encontraremos en el planning de soluciones SharePoint tenemos:
- Seguridad.
- Gobernanza.
- Niveles de servicio.
- Continuidad de negocio.
- Capacidad.
- Rendimiento.
- Integridad de datos.
- Help Desk.
- Mantenimiento.
De esta lista, es destacable el requisito de seguridad puesto que en SharePoint vamos a tener usuarios con acceso remoto, acceso desde dispositivos móviles, ….lo que implicará la aparición de issues relacionados con autenticación y acceso a la solución. Y hasta aquí llega este segundo post sobre planning de soluciones SharePoint.
