ADS120131-02---Comenzando con SAD Scrum.pdf

UniversidadPeruanaUnión

Comenzando con SAD Scrum

©2013 Angel Sullon | @asullom

Curso: Análisis y Diseño IUnidad 1 - Entrenamiento en Gestión de Requisitos y Diseño de Sistemas

s u bm i tc o n s u l t i n g

mailto:@asullom


@asullom

Objetivos

• Entender el modelo SAD Scrum para laconstrucción de sistemas

mailto:@asullom


@asullom

Agenda

• Introducción• EL modelo SAD Scrum• Visión del producto• Historias de usuario• Requisitos suplementarios• Técnica de captura de requisitos• Herramientas de captura y análisis de

requisitos

mailto:@asullom


INTRODUCCIÓN


@asullom

Intro

• Nosotros, qué métodos o procesos desoftware vamos a usar en este curso?

Sad Scrum = Scrum + Algunos artefactos de RUP+ ATDD + Aspectos de Seguridad y de Calidad

• Sad Scrum (Secure Application Developmentwith Scrum)

mailto:@asullom


SAD SCRUM

ModeloRolesArtefactos (o entregables del proyecto)Eventos


@asullom

SAD SCRUM> Modelo

1. Planificación

2. Iteración óEjecución

3.Demostración-Retrospectiva

• Lista de obstáculos• Lista de nuevas vulnerabilidades

Lista deTareas conejemplos delusuario

Recursos de seguridad

Incrementoseguro

• Visión del producto• Historias de usuario

(con ejemplos ,incluido los deseguridad y calidad)

• Otros

Sad Scrum (Secure Application Development with Scrum)

Otros documentos:• Arquitectura tecnológica• Plan del proyecto-inicial• Estándares de desarrollo• Método de trabajo del equipo• Módulo de administración del

Backend de la aplicación.

• Diagramas de entidades, declases según patrónarquitectónico y las interfacesgráficas de usuario

© 2011 Angel Sullon

SADSCRUMMODEL

mailto:@asullom


@asullom

Sad Scrum> Estructura Scrum

• Roles– El Product Owner– El Scrum Master– El Team

• Artefactos– Product Backlog (Requerimientos funcionales y no funcionales)– Sprint Backlog– Burndown del Sprint– Burndown del Release o Producto– Backlog de impedimentos– Backlog de nuevas vulnerabilidades (new)

• Eventos (reuniones)– Sprint Planning Meeting (Parte 1 y Parte 2)– Daily Scrum Meeting– Sprint Review Meeting (Demo)– Sprint Retrospective meeting

• Principios– transparencia, inspección y adaptación.– Auto-organización

mailto:@asullom


@asullom

Sad Scrum>Artefactos preliminares

• Visión• Historias de usuario (con ejemplos , incluido los de

seguridad y calidad)• Arquitectura tecnológica (Especificaciones

suplementarias)• Plan del proyecto-inicial• Estándares de desarrollo• Método de trabajo del equipo (Configuración del

proyecto-ini)• Diagramas de entidades, de clases según patrón

arquitectónico y las interfaces gráficas de usuario• Módulo de administración del Backend de la aplicación.• Otros artefactos.

mailto:@asullom


DOCUMENTO DE VISIÓNFase1: Definición de la Visión del Producto


@asullom

Visión

• Este documento define la visión del productodesde la perspectiva del cliente, especificandolas necesidades o características del producto.

• Constituye una base de acuerdo en cuanto alos requisitos del sistema.

• El Product Owner usualmente compartirá suvisión del producto.

• Cada miembro del equipo debe escribir suversión de la visión hasta tener una únicavisión.

mailto:@asullom


@asullom

Visión>Tabla de contenidos según RUP

• Introducción– Título– Objetivos– Alcance– Referencias

• Posicionamiento– Descripción del problema– Beneficios del producto– Campos de acción

• Stakeholders y Usuarios• Características del producto (inicial)• Requerimientos suplementarios

– Requerimientos no funcionales– Restricciones– Reglas de negocio

mailto:@asullom


@asullom

Visión>Ejemplo

• Sistema de Control de Caja para la nubeagilcont®

• Plataforma educación en tiempo real ongen®

• http://prezi.com/8kte9uc0tcmv/real-time-webaplicacion-en-educacion/

• Ver plantilla: XXX---Vision v1.docx

mailto:@asullom

http://prezi.com/8kte9uc0tcmv/real-time-


@asullom

Ejemplos de características del producto

mailto:@asullom


@asullom

Ejemplos de características del producto…

mailto:@asullom


HISTORIAS DE USUARIO (CONEJEMPLOS , INCLUIDO LOS DESEGURIDAD Y CALIDAD)

Fase2: Creación del Product Backlog


@asullom

Historias de usuario

• Una Historias de usuario resume QUÉ es lo quehay que hacer para resolver el problema delcliente.

• Es decir, es el recordatorio de la conversación conel cliente.

• En ATDD cada historia de usuario contiene unalista de ejemplos que cuentan lo que el clientequiere, con total claridad y ninguna ambigüedad.

• Breves, concretas y algo estimables. Son elresultado de escuchar al cliente y ayudarle aresumir el requisito o característica en una solafrase.

mailto:@asullom


@asullom

Características de una Historia

• Independientes de otras historias. Deben sercompletos y consistentes entre sí (no debe haberconflictos o incompatibilidad entre historias)

• Negociable y negociada• Valoradas por el cliente (resuelven los problemas del

cliente)• Estimables entre 2 y 10 días• Pequeña descripción expresada de una manera

sencilla, clara y sin ambigüedades. Se expresan demanera cuantitativa (No diga que algo debe ser rápido;mejor diga qué tan rápido debe ser)

• Verificables mediante ejemplos de aceptación ymedibles (se implementó o no?)

mailto:@asullom


@asullom

Ejemplo de Historia de usuario

Una historia consta dedos + 1 partes:1. Enunciado2. Ejemplos de

aceptación3. +1: Ejemplos de

seguridad y calidad

mailto:@asullom


@asullom

Definición de Hecho!

• Definir el significado cuando el equipo diceque ha terminado con una historia.

mailto:@asullom


@asullom

Definición de Requisito>Volere

mailto:@asullom


@asullom

RUP>Definición de Requisito

mailto:@asullom


@asullom

RUP>Tabla de resumen de requerimiento

mailto:@asullom


@asullom

RUP>Casos de uso del sistema

mailto:@asullom


@asullom

RUP>y su respectiva descripción

mailto:@asullom


@asullom

RUP>Trazabilidad de los requisitos

mailto:@asullom


REQUISITOS DE SEGURIDAD

¿Qué son requisitos de seguridad y calidad?¿Cómo los obtengo?


@asullom

• Muchos de los requisitos de seguridad y decalidad son de tipo no funcional, pero queprefiere definir como requisito funcional.

• Ejemplos:– Ingresar al Sistema– Validar privilegio.– No se permite retirar dinero de su cuenta sin que

este se haya identificado.

mailto:@asullom


@asullom

Términos relativos a la seguridad

• El dominio de la seguridad se abarca en cincoaspectos más importantes: las personas, losdatos, las aplicaciones, la red y lainfraestructura física (IBM, 2011)

mailto:@asullom


@asullom

Seguridad de la información

• Seguridad de la información, es lapreservación de la confidencialidad, integridady disponibilidad de la información (ISO17799:2005)

• Una aproximación más completa del conceptode seguridad está dada por la combinación decuatro atributos principales: confidencialidad,integridad, disponibilidad y el no repudio.

• Ver OWASP Top 10• Ver Controles de seguridad ISO 27001:2005

mailto:@asullom


@asullom

Objetivos de Seguridad

• Declaración de la intención de contrarrestarlas amenazas identificadas y/o de cumplir laspolíticas y controles de seguridad identificadasde la organización.

• Especificación del grado de seguridad exigidoa un sistema de información como base pararealizar una evaluación.

mailto:@asullom


@asullom

Controles

• Controles (o contramedidas), son medios paramanejar el riesgo, incluyendo políticas,procedimientos, lineamientos, prácticas oestructuras organizacionales, las cualespueden ser administrativas, técnicas, degestión o de naturaleza legal (ISO 17799:2005)

• Ver ANEXO 1 – CONTROLES DE SEGURIDADISO 27001– A.12 ADQUISICIÓN, DESARROLLO Y

MANTENIMIENTO DE LOS SISTEMAS DEINFORMACIÓN

mailto:@asullom


@asullom

A.12 ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DELOS SISTEMAS DE INFORMACIÓN

• A.12.1 Requerimientos de seguridad de los sistemas• Objetivo: Asegurar que la seguridad sea una parte integral de los sistemas de información

• A.12.2 Procesamiento correcto en las aplicaciones• Objetivo: Evitar errores, pérdida, modificación no autorizada o mal uso de la información en las

aplicaciones

• A.12.3 Controles criptográficos• Objetivo: Proteger la confidencialidad, autenticidad o integridad de la información a través de

medios criptográficos

• A.12.4 Seguridad de los archivos del sistema• Objetivo: Garantizar la seguridad de los archivos del sistema

• A.12.5 Seguridad de los procesos de desarrollo y soporte• Objetivo: Mantener la seguridad del software e información del sistema de aplicación

• A.12.6 Gestión de vulnerabilidad técnica• Objetivo: Reducir los riesgos resultantes de la explotación de vulnerabilidades técnicas publicadas

mailto:@asullom


@asullom

• Aún no tienes claro los requisitos?

Modela el negocio

mailto:@asullom


ARQUITECTURA TECNOLÓGICA


@asullom

Arquitectura

• Indica el esquema de desarrollo del softwaree.g. El producto deberá ser desarrollado bajo elesquema MVC

– Modelo: ORM Django, Express– Vista: Entorno real time web y mobile– Controlador: Django, Express– Datos: MySQL 5.x y MongoDB 2.x

mailto:@asullom


@asullom

Alternativa: django x kumbia

mailto:@asullom


@asullom

Herramientas de desarrollo

• Riesgos• Método de trabajo del equipo• Comunicación• Se explica en Método de trabajo del equipo

mailto:@asullom


PLAN DE DESARROLLO DELSOFTWARE


@asullom

Plan de desarrollo del software

• Este documento provee una visión global delenfoque de desarrollo propuesto.

• El propósito del Plan de Desarrollo deSoftware es proporcionar la informaciónnecesaria para controlar el proyecto. En él sedescribe el enfoque de desarrollo delsoftware.

• Ver plantilla RUP

mailto:@asullom


@asullom

Plan de desarrollo del software>Plantilla

mailto:@asullom


MÉTODO DE TRABAJO DEL EQUIPO


@asullom

Método de trabajo del equipo

• https://t.co/dT8oVmZwV2

mailto:@asullom


@asullom


ESTÁNDARES DE DESARROLLO

mailto:@asullomUniversidad


@asullom

Estándares de desarrollo

• sda_py: https://t.co/Vhg0L6sQpq• sda_ph: https://t.co/n44sMbni28

mailto:@asullom


MÓDULO DE ADMINISTRACIÓN DELBACKEND DE LA APLICACIÓN.


@asullom

Módulo de administración del Backend de laaplicación.

mailto:@asullom


DIAGRAMAS

(Antes) Proceso de negocio, Requisitos y Diagrama de Casos de Uso (sist)EntidadesClases según patrón arquitectónicoInterfaces gráficas de usuario


@asullom

Ambiente de EA

• Usar plantilla ICONIX Project Model para EAclass Vista general del proyecto

Modelo de casos de uso

Entities

Data Access Layer

View Layer

Requisitos

Tablas,pantallas, etc.

Casos de uso(organizados enpaquetes).Diagramas de robustez yde secuencia(anidado dentro de loscasos de uso comodiagramas hijos)

Requisitosfuncionales y nofuncionales Clases conceptuales

que describen eldominio delproblema.

Clases desoftware

Aquí hay una organización recomendada del "esqueleto del proyecto" en paquetes. Modifíquela como seanecesario para su propio proyecto.

Modelo de datos

Tablas debase de datos

Procesos de negocio

Visite ICONIX en www.iconixsw.com

Los escenariosdel proceso denegocio dirigenla identificaciónde requisitos,casos de uso, yobjetos deldominio.

Entities Lite

Business LayerServ ice Layer«realize»

mailto:@asullom

www.iconixsw.comLos


@asullom

Requisitos>Ejemplo «Sistema de evaluación dedesempeño laboral de los directores UPeU»

pkg Requirements

Functional Requirements

+ El sistema debe permiitir crear y gerenciar procesos de evaluación al personal: directores, docentes, jefes, trabajadores por áreas para los 3 campus+ El sistema debe permitir consultar reportes y estadísticas con los parámetros difusos definidos+ El sistema debe permitir crear cuestionarios basado en lógica difusa+ El sistema debe permitir realizar la evaluación en línea bajo cierto tiempo de vigencia+ El sistema deberá permitir al responsable del proceso de evaluación ingresar los parámetro de entrada y salida del motor difuso+ Permitir confiurar los roles de los usuarios del sistema: Responsable del soporte del proceso de valuación, Evaluadores y Gerentes

Non-functional requirements

+ El sistema deberá se implementado en una plataforma WEB+ El sistema deberá ser desarrollado util izando el framework (OpenSda para php) propuesto por DIGESI

mailto:@asullom


@asullom

Paquete de casos de uso del sistemauc Use Cases

Registros Básicos

+ Trabajar con Alumnos/Clientes+ Trabajar con Áreas+ Trabajar con Campus+ Trabajar con Directores/Profesores/Empleados

Gerenciar Proceso de Ev aluación

+ Cambiar de Proceso Selectivo+ Consultar Estadísticas

Registro de Usuarios

+ Actualizar Roles+ Cambiar contraseña del usuario+ Realizar login en el sistema+ Registarse en el Sistema+ Trabajar con Usuarios+ Validar usuario existente

Fuzzy Logic - Workflow

+ PhFuzzinator+ Emitir resultados borrosos+ Mantener Inferencia borrosa+ Procesar Inferencia borrosa

Proceso de Ev aluación - Workflow

+ Actualizar estado del Proceso de Evaluación+ Asignar Areas al Proceso de Evaluación+ Asignar Cuestionario de Evaluación para el proceso a hablitar+ Asignar Cursos a los Alumnos+ Asignar docente al curso+ Asignar Jefes Evaluadores+ Asignar o habilitar Autoevaluación+ Emitir reportes varios (para controlar el Proceso de Evaluación)+ Realizar Autoevaluación+ Realizar Evaluación X Alumnos+ Realizar Evaluación X Jefes+ Trabajar con cuestionarios+ Trabajar con Cursos+ Trabajar con Procesos de Evaluación+ Trabajar con Tipos de Preguntas (plantil la)+ Vincular cuestionario con los datos de configuración del motor difuso

Actores

+ Administrator+ Interezado+ Responsable del soporte del Proceso de Evaluación+ User Evaluador

mailto:@asullom


@asullom

Diagrama de casos de uso>Ejemplo

uc Fuzzy Logic - Workflow

PhFuzzinator

Mantener Inferenciaborrosa

Procesar Inferenciaborrosa

Emitir resultadosborrosos

Responsable delsoporte delProceso deEv aluación

(from Actores)

«include»

mailto:@asullom


@asullom

Diagrama de casos de uso>Ejemplo clásico

uc Registro de Usuarios

User Ev aluador

(from Actores)

Trabajar conUsuarios

Actualizar Roles

Realizar login en elsistema

Validar usuarioexistente

Cambiar contraseñadel usuario

Interezado

(from Actores)

Registarse en elSistema

Responsable delsoporte delProceso deEv aluación

(from Actores)

«extend»

«extend»

«include»

«extend»

«extend»

mailto:@asullom


@asullom

• A continuación se presenta ejemplo de losdiagramas de clases de diseño según el patrónarquitectónico en capas para el sistema debiblioteca de la UPeU

• Presentación: Flex4 basado en MVP ó MVVM• Servicios: Spring3• Negocio: Spring3• Datos: Hibernate3

mailto:@asullom


@asullom

Ejemplo de Diagrama de Entidades

• También lo llaman modelo conceptual (de BD), Diseño lógico de BD, modelo de datos, modelo dedominio (del sistema o del problema)

• Un Modelo de Dominio consiste en un conjunto de diagramas de clases, sin definición deoperaciones.

• Los modelos de dominio no necesariamente deben mostrar clases de software

class config.Entities

Empresa

- razon_social: string- siglas: string- nit: string- dv: int- representante_legal: string- tipo_nuip_id: int- nuip: bigint- pagina_web: string- logo: string- registrado_at: datetime- modificado_in: datetime

Sucursal

- sucursal: string- sucursal_slug: string- direccion: string- telefono: string- fax: string- celular: string- registrado_at: datetime- modificado_in: datetime

params.Entities::TipoNuip

- tipo_nuip: string

params.Entities::Ciudad

- ciudad: string- registrado_at: datetime- modificado_in: datetime

«enumeratio...LocalTipo

Sin definir = 0Oficina = 1Almacen = 2Tienda = 3

0..*

+ciudad_id

10..*

+empresa_id

1

0..*

+tipo_nuip_id 1

0..*

+local_tipo 1

mailto:@asullom


@asullom

Data Access Layer>Diagrama de clases

class Common Data Access Layer

«interface»INaturalPersonData

+ getListByFilter(fi lter :String, birthDate :Datetime, gender :Gender, boolean :isAdventist) : List<NaturalPerson>+ getListByIdentityDoc(identityDoc :String) : List<NaturalPerson>+ getListByIdentityDocAndNameAndLastName(identityDoc :String, name :String, LastName :String) : List<NaturalPerson>+ getListByMaritalStatus(maritalStatus :MaritalStatus) : List<NaturalPerson>

IDataAccess

«interface»IMaritalStatusData

+ getListByCode(code :String) : List<MaritalStatus>+ getListByName(name :String) : List<MaritalStatus>+ getListByFilter(fi lteCodeOrName :String) : List<MaritalStatus>

mailto:@asullom


@asullom

Data Access Layer>Ejemplo completoclass Complete Example --- DAL

Test\opensda.training.common.data.hbcontexts

opensda.training.common.data.hbcontexts

opensda.training.common.data.contracts

opensda.training.common.data.entitiesopensda.training.common.data.entities

org.springframework.transaction.annotation org.springframework.stereotype

org.springframework.beans.factory.annotation

opensda.core.data

opensda.core.data.hibernateaccess

EntityGuidBase

- identity: long

+ getListNull() : List

«interface»IDataTransaction

+ beginTransaction() : void+ commitTransaction() : void+ rollbackTransaction() : void

«interface»IDataAccess

+ delete(entity :E) : void+ getById(id :Object) : E+ getListAll() : List<E>+ save(entity :E) : E+ detach(entity :E) : void

HibernateSession

- sessionFactory: SessionFactory- threadSession: ThreadLocal- threadTransaction: ThreadLocal- threadInterceptor: ThreadLocal

+ init() : void+ getDefaultSession() : Session+ closeSession() : void+ beginTransaction() : void+ commitTransaction() : void+ rollbackTransaction() : void

entity:E

DataAccess

- entityClass: Class<E>

+ delete(entity :E) : void+ getById(id :Object) : E+ getListAll() : List<E>+ save(entity :E) : E+ detach(entity :E) : void

«interface»Autowired

«interface»Transactional

«interface»Repository

Entities Common::MaritalStatus

- code: String- name: String

«interface»Data Access Layer::IMaritalStatusData


MaritalStatusDataTest

+ testSave() : void+ testDelete() : void+ testGetById() : void+ testGetListAll() : void+ testGetListByFilter() : void+ testGetListByCode() : void+ testGetListByName() : void

MaritalStatusData

+ getListByCode(code :String) : MaritalStatus+ getListByName(name :String) : MaritalStatus+ getListByFilter(fi lteCodeOrName :String) : MaritalStatus

-instance

mailto:@asullom


@asullom

Business Layer>Ejemplo

class Common Business Layer

NaturalPersonBusiness

+ delete(naturalPerson :NaturalPerson) : void+ getById(id :Object) : NaturalPerson+ getListByFilter(fi lter :String, birthDate :Datetime, gender :Gender, boolean :isAdventist) : List<NaturalPerson>+ save(naturalPerson :NaturalPerson) : NaturalPerson

MaritalStatusBusiness

+ delete(maritalStatus :MaritalStatus) : voidNo permitir borrar si está siendo usado por NaturalPerson

+ getById(id :Object) : MaritalStatus+ getListByFilter(fi lteCodeOrName :String) : MaritalStatus+ save(maritalStatus :MaritalStatus) : MaritalStatus

No permitir duplicar:- Code of Marital Status- Name of Marital Status

Complete Example --- BL

+ MaritalStatusBusinessTest+ MaritalStatusCannotBeNullException+ MaritalStatusCodeAlreadyInUseException+ MaritalStatusHasDependentException+ MaritalStatusNameAlreadyInUseException+ MaritalStatusNotFoundException+ MockFlexContext+ ServiceException+ SessionBusiness+ SessionContext+ SharedMethods+ Autowired+ FlexSession+ Service

IMPORTANTE:

Recuerde los fi ltros de acesso a datos baseado en SESSION;

1. EducationalEntity {Instancia Única - Definido en el momento de Login}2. Campus {Instancia Única - Definido en el momento de Login}3. AcademicLev el {Instancia Única - Definido en el momento de Login}4. Libraries {IDefinidos en el momento de Login}

NO SERÁ ESPECIFICADO ESTOS PARÂMETROS.

mailto:@asullom


@asullom

Business Layer>Ejemplo completoclass Complete Example --- BL

flex.messaging

Test\opensda.training.common.business

opensda.training.common.data.contracts

opensda.util.translator

opensda.training.common.business.exceptions

opensda.training.common.business

opensda.training.common.data.entities

EntityGuidBaseEntities Common::

MaritalStatus

- code: String- name: String

Business Layer::MaritalStatusBusiness




MaritalStatusCannotBeNullException

+ MaritalStatusCannotBeNullException()

Serv iceException

- key: String- parameters: List<String>

+ ServiceException(message :String, key :String)

MaritalStatusNotFoundException

+ MaritalStatusNotFoundException()

MaritalStatusHasDependentException

+ MaritalStatusHasDependentException(maritalStatusName :String)

MaritalStatusCodeAlreadyInUseException

+ MaritalStatusCodeAlreadyInUseException(maritalStatusCode :String)

MaritalStatusNameAlreadyInUseException

+ MaritalStatusNameAlreadyInUseException(maritalStatusName :String)

IDataAccess

«interface»Data Access Layer::IMaritalStatusData


«interface»Data Access Layer::INaturalPersonData

+ getListByFilter(fi lter :String, birthDate :Datetime, gender :Gender, boolean :isAdventist) : List<NaturalPerson>+ getListByIdentityDoc(identityDoc :String) : List<NaturalPerson>+ getListByIdentityDocAndNameAndLastName(identityDoc :String, name :String, LastName :String) : List<NaturalPerson>+ getListByMaritalStatus(maritalStatus :MaritalStatus) : List<NaturalPerson>

MaritalStatusBusinessTest

+ setUp() : void+ testSave() : void+ testSaveWhenMaritalStatusCannotBeNull() : void+ testSaveWhenMaritalStatusCodeAlreadyInUse() : void+ testSaveWhenMaritalStatusNameAlreadyInUse() : void+ testDelete() : void+ testDeleteWhenMaritalStatusCannotBeNull() : void+ testDeleteWhenMaritalStatusNotFound() : void+ testDeleteWhenMaritalStatusHasDependent() : void+ testGetById() : void+ testGetByIdWhenMaritalStatusCannotBeNull() : void+ testGetByIdWhenMaritalStatusNotFound() : void+ testGetListByFilter() : void



org.springframework.stereotype

«interface»Serv ice

SessionContext

SharedMethods

+ TestMethodStart(session :FlexSession, academicLevelId :String, userName :String, password :String) : void

MockFlexContext

+ getFlexSession() : FlexSession

SessionBusiness

«interface»FlexSession

-sessionContext

-maritalStatusData

-naturalPersonData

-sharedMethods

-flexContext

-sessionContext

-naturalPersonData

-maritalStatusData

-instance

mailto:@asullom


@asullom

Service Layer>Ejemplo

class Common Serv ice Layer: NaturalPerson

«interface»INaturalPersonServ ice

+ remove(naturalPerson :NaturalPerson) : void+ getById(id :Object) : NaturalPerson+ getListByFilter(fi lter :String, birthDate :Datetime, gender :Gender, boolean :isAdventist) : List<NaturalPerson>+ save(naturalPerson :NaturalPerson) : NaturalPerson

NaturalPersonServ ice

+ remove(naturalPerson :NaturalPerson) : void+ getById(id :Object) : NaturalPerson+ getListByFilter(fi lter :String, birthDate :Datetime, gender :Gender, boolean :isAdventist) : List<NaturalPerson>+ save(naturalPerson :NaturalPerson) : NaturalPerson+ getListMaritalStatus() : List<MaritalStatus> Business Layer::MaritalStatusBusiness




Business Layer::NaturalPersonBusiness

+ delete(naturalPerson :NaturalPerson) : void+ getById(id :Object) : NaturalPerson+ getListByFilter(fi lter :String, birthDate :Datetime, gender :Gender, boolean :isAdventist) : List<NaturalPerson>+ save(naturalPerson :NaturalPerson) : NaturalPerson

mailto:@asullom


@asullom

Service Layer>Ejemplo completo

class Complete Example --- SL

opensda.training.common.service.sfcontexts

opensda.training.common.service.contracts

opensda.training.common.business

org.springframework.flex.remoting

MaritalStatus::MaritalStatusServ ice

+ delete(MaritalStatus) : void+ getById(Object) : MaritalStatus+ getListByFilter(String) : MaritalStatus+ save(MaritalStatus) : MaritalStatus

Business Layer::MaritalStatusBusiness

+ delete(MaritalStatus) : voidNo permitir borrar si está siendo usado por NaturalPerson

+ getById(Object) : MaritalStatus+ getListByFilter(String) : MaritalStatus+ save(MaritalStatus) : MaritalStatus


«interface»MaritalStatus::IMaritalStatusServ ice

+ delete(MaritalStatus) : void+ getById(Object) : MaritalStatus+ getListByFilter(String) : MaritalStatus+ save(MaritalStatus) : MaritalStatus

org.springframework.stereotype

«interface»Serv ice

«interface»RemotingDestination

«interface»RemotingInclude



mailto:@asullom


@asullom

View Layer Model>Ejemplo completo

class Complete Example --- VL

opensda.flex.controls.forms.decorators

opensda.training.common.view.modmaritalstatus

opensda.training.common.view.services

opensda.training.common.view.entities

MaritalStatus::MaritalStatus

MaritalStatus::MaritalStatusServ ice

MaritalStatus::VwMaritalStatus

DataGridPaging

Sav eButton

SearchTextInput

NewButton Remov eButton EditButton CancelButton

mailto:@asullom


@asullom

View Layer>IGU Ejemplo

ui MaritalStatus

mailto:@asullom


@asullom

View Layer>IGU Ejemplo 2ui Employee

mailto:@asullom


@asullom

Conclusiones

• EL nivel de especificación de los requisitosdepende sobre todo de su complejidad.

mailto:@asullom


@asullom

Referencias

• http://www.genbetadev.com/metodologias-de-programacion/historias-de-usuario-una-forma-natural-de-analisis-funcional

• http://prezi.com/8kte9uc0tcmv/real-time-webaplicacion-en-educacion/

• http://www.taringa.net/posts/linux/15576096/Class-una-plataforma-de-educacion-en-tiempo-real.html

mailto:@asullom

http://www.genbetadev.com/metodologias-

http://prezi.com/8kte9uc0tcmv/real-time-

http://www.taringa.net/posts/linux/15576096

ADS120131-02---Comenzando con SAD Scrum.pdf

Documents

Transcript of ADS120131-02---Comenzando con SAD Scrum.pdf