Un diagrama de clases sirve para
visualizar las relaciones entre las clases que involucran el sistema, las
cuales pueden ser asociativas, de herencia, de uso y de contenido.
Un diagrama de clases está
compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
Elementos
Clase
Es la unidad básica que encapsula toda la
información de un Objeto (un objeto es una instancia de una clase). A través de
ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta
Corriente, etc.).
En UML, una clase es representada por un rectángulo
que posee tres divisiones:
En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser prívate, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).
Vídeo: Aquí te muestra una breve explicación sobre el diagrama de clases .
En este otro vídeo veras un ejemplo de este diagrama:
El
diagrama de casos de uso representa la forma en como un Actor opera
con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactúan.
Un
diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos
de Uso.
Relaciones
de Uso, Herencia y Comunicación.
Elementos
Actor: rol que un usuario juega con respecto al sistema. Es importante destacar el
uso de la palabra rol, pues con esto se especifica que un Actor
no necesariamente representa a una persona en particular, sino más bien la
labor que realiza frente al sistema.
Caso de
Uso: Es una operación/tarea específica que
se realiza tras una orden de algún agente externo, sea desde una petición de un
actor o bien desde la invocación desde otro caso de uso.
Relaciones:
Asociación: Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación
se denota con una flecha simple.
Dependencia o Instanciación: Es una forma muy particular de relación entre
clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
Dicha relación se denota con una flecha punteada.
Generalización : Este tipo de relación es uno de los más utilizados,
cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>)
o de Herencia (<<extends>>).
Vídeo
breve explicación sobre los diagramas de casos de uso
Una especificación de
requisitos del software es una descripción completa del comportamiento del
sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas
las interacciones que se prevén que los usuarios tendrán con el software.
También contiene requisitos no funcionales. Los requisitos no funcionales son
los requisitos que imponen restricciones al diseño o funcionamiento del sistema
(tal como requisitos de funcionamiento, estándares de calidad, o requisitos del
diseño).
Requerimientos
funcionales
Son declaraciones de
los servicios que debe proporcionar el sistema, de la manera en que éste debe
reaccionar a entradas particulares y de cómo se debe comportar en situaciones
particulares. Los
requerimientos funcionales de un sistema describen lo que el sistema debe
hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de
los posibles usuarios del software y del enfoque general tomado por la
organización al redactar requerimientos. Cuando se expresan como requerimientos
del usuario, habitualmente se describen de una forma bastante abstracta. Sin
embargo. Los requerimientos funcionales del sistema describen con detalle la
función de éste, sus entradas y salidas, excepciones, etcétera.
Requerimientos
no funcionales
Son restricciones de
los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no
funcionales a menudo se aplican al sistema en su totalidad.
Normalmente apenas se
aplican a características o servicios individuales del sistema. Los
requerimientos no funcionales, como su nombre sugiere, son aquellos
requerimientos que no se refieren directamente a las funciones específicas que
proporciona el sistema, sino a las propiedades emergentes de éste como la
fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.
Factibilidad: Los estudios
de factibilidad, se completan durante la fase de diseño de sistemas, en general
durante la consideración de la evaluación de las diferentes alternativas de
solución propuestas. Los estudios de factibilidad consideran la factibilidad
técnica, económica y operacional de cada alternativa, así como si el proyecto
es o no apropiado dados los factores políticos y otros del contexto
institucional.
Factibilidad
Operacional: Esta factibilidad comprende una determinación de la
probabilidad de que un nuevo sistema se use como se supone. Deberían
considerarse tres aspectos de la factibilidad operacional por lo menos.
1.Un nuevo sistema puede ser
demasiado complejo para los usuarios de la organización o los operadores del
sistema.
2.Un sistema puede hacer que los
usuarios se resistan a él como consecuencia de una técnica de trabajo, miedo a
ser desplazados, intereses en el sistema antiguo u otras razones.
3.Un nuevo sistema puede introducir
cambios demasiado rápido para permitir al personal adaptarse a él y aceptarlo.
Un cambio repentino que se ha anunciado, explicado y “vendido” a los usuarios
con anterioridad puede crear resistencia.
Factibilidad
Técnica: El análisis de factibilidad técnica evalúa si el equipo y
software están disponibles (o, en el caso del software, si puede
desarrollarse) y si tienen las capacidades técnicas requeridas por cada
alternativa del diseño que se esté considerando. Los estudios también
consideran las interfaces entre los sistemas actuales y nuevos.
Factibilidad
Económica: Los estudios de factibilidad económica incluyen análisis de
costos y beneficios asociados con cada alternativa del proyecto. Con
análisis de costos/beneficio, todos los costos y beneficios de adquirir y
operar cada sistema alternativo se identifican y se hace una comparación
de ellos.
Viabilidad;Analizar laviabilidad de un proyectoes más
importante que planificar y para poder concluirlo resulta imprescindible llevar
a cabo una investigación completa, que conduzca al conocimiento de si realmente
el proyecto aportará los beneficios que se esperan de él. No es una simple
formalidad burocrática, sino que es una herramienta necesaria para la toma de decisiones
estratégica.
Para
llevar a cabo el estudio de viabilidad de un proyecto se precisa
recopilar información suficiente para:
Identificar
las limitaciones, restricciones y supuestos.
Detectar
las oportunidades.
Analizar
el modo actual de funcionamiento de la organización.
Definir
los requisitos que configuran el proyecto.
Evaluar
las distintas alternativas.
Llegar
a un acuerdo sobre la línea de acción.
Viabilidad
Técnica:
Estudios de
viabilidad técnica que tienen que ver con temas de tecnología e
infraestructura. Un estudio técnico de viabilidad se puede ver en los costos y
beneficios potenciales de las nuevas tecnologías, o para investigar la cantidad
de espacio necesario para construir un nuevo edificio.
Viabilidad
Cultural:
Estudios de
viabilidad aspecto cultural a las cuestiones culturales que puedan derivarse de
la búsqueda de ciertas oportunidades de negocio.
Viabilidad
Legal:
Estudios de
viabilidad jurídica destinada a evaluar si un proyecto traería cargos legales
irrazonables. Los bufetes de abogados de viabilidad se pueden hacer para los
productos que se encuentran en alto riesgo.
Scrum
es una metodología ágil y flexible para gestionar el desarrollo de software,
cuyo principal objetivo es maximizar el retorno de la inversión para su empresa
(ROI). Se basa en construir primero la funcionalidad de mayor valor para el
cliente y en los principios de inspección continua, adaptación, auto-gestión e
innovación.
Con
la metodología Scrum el cliente se entusiasma y se compromete con el proyecto
dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier
momento realinear el software con los objetivos de negocio de su empresa, ya
que puede introducir cambios funcionales o de prioridad en el inicio de cada
nueva iteración sin ningún problema.
Esta
metódica de trabajo promueve la innovación, motivación y compromiso del equipo
que forma parte del proyecto, por lo que los profesionales encuentran un ámbito
propicio para desarrollar sus capacidades.
Las
metodologías de desarrollo de software son un conjunto de procedimientos,
técnicas y ayudas a la documentación para el desarrollo de productos software.
Las
actividades a realizar para lograr el producto informático deseado, indicando
además qué personas deben participar en el desarrollo de las actividades y qué
papel deben de tener. Además detallan la información que se debe producir como
resultado de una actividad y la información necesaria para comenzarla.
Actualmente es imprescindible considerar los riesgos, aunque habitualmente las
empresas, no han sido concienciadas de los riesgos inherentes al procesamiento
de la información mediante ordenadores, a lo que han contribuido, a veces, los
propios responsables de informática, que no han sabido explicar con la
suficiente claridad las consecuencias de una política de seguridad insuficiente
o incluso inexistente.
Las
técnicas indican cómo debe ser realizada una actividad técnica determinada
identificada en la metodología. Combina el empleo de unos modelos o
representaciones gráficas junto con el empleo de unos procedimientos
detallados.
Metodologías
Para el desarrollo Ágil
Su
objetivo fue esbozar los valores y principios que deberían permitir a los
equipos desarrollar software rápidamente y respondiendo a los cambios que
puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a
los procesos de desarrollo de software tradicionales, caracterizados por ser
rígidos y dirigidos por la documentación que se genera en cada una de las
actividades desarrolladas.
XP
SCRUM
Crystal
Methodologies
Dynamic
Systems Development Method (DSDM)
Adaptive
Software Development(ASD)
Feature-Driven
Devolopment (FDD)
Lean
Development (LD)
Metodologías
Tradicionales
Estas
metodologías tradicionales imponen una disciplina de trabajo sobre el proceso
de desarrollo del software, con el fin de conseguir un software más eficiente.
Para ello, se hace énfasis en la planificación total de todo el trabajo a
realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del
producto software. Se centran especialmente en el control del proceso, mediante
una rigurosa definición de roles, actividades, artefactos, herramientas y
notaciones para el modelado y documentación detallada . Además, las
metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo
que no son métodos adecuados cuando se trabaja en un entorno, donde los
requisitos no pueden predecirse o bien pueden variar.
