desarrollo de software orientado a la web
TRANSCRIPT
FACULTAD DE SISTEMAS MERCANTILES
CARRERA DE INGENIERÍA EN SISTEMAS
DESARROLLO DE PROYECTOS INFORMATICOS
Nombre: Ángel Ortiz
Nivel: Sexto
Tutor: Ing. John Toasa
Fecha: 25 de Julio del 2012
INTRODUCCION
QUE ES EL DESARROLO DE SOFTWARE ORIENTADOA OBJETOS?
Es el enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y
mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de
la ingeniería al software
El proceso de desarrollo del software se muestra gráficamente en la parte de arriba, a
continuación desarrollara una breve explicación del mismo.
METODOLOGIAS PARA EL
La plataforma
Automatización de la Guía
Tomando en cuenta el modelo DMAIC de Seis Sigma se elaboró la Guía empleada en el presente proyecto.
FASES DE UN PROYECTO DE DESARROLLO DE SOFTWARE ORIENTADO A LA WEB.
Guía
Fases de Desarrollo
Iniciación del Proyecto
Análisis del Sistema
Diseño del Sistema
Construcción
Evaluación y Aseguramiento de Calidad
Implementación
Por cada fase la guía considerala siguiente estructura:• Objetivo(s) de la fase.• Listado de Actividades de la fase• Contenido de cada actividad:
• Tarea(s)• Entregable(s)• Consideraciones Seis Sigma• Formato(s)
Fase – Iniciación del Proyecto
Objetivos Actividades Tareas
• Definir con claridad el problema.
• Definir el alcance del proyecto.
• Proponer una solución.
• Determinar los costos y beneficios de la solución.
• Obtener la aprobación del proyecto.
Identificar el problema.• Elaborar un RFS (Requerimiento de Servicios IT), que será usado
como notificación inicial por parte del cliente sobre el sistemarequerido.
Conformar el equipo de desarrollo.
• Conformar el equipo de desarrollo de acuerdo a las característicasy particularidades de cada proyecto.
Identificar requerimientos preliminares.
• Iniciar el proceso de desarrollo a través del mapa de procesos.• Desarrollar un bosquejo inicial de proyecto.• Definir las metas del proyecto.• Identificar los clientes.• Identificar salidas claves.• Documentar los procesos actuales.• Definir los requerimientos de alto nivel.
Validar los requerimientos. • Validar los requerimientos de alto nivel previamente obtenidos.
Desarrollar un estudio de fiabilidad.
• Estructurar un estudio de fiabilidad para el proyecto.
Obtener la aprobación del proyecto.
• Obtener aprobación de todos los clientes, departamentos y/oentidades, que tengan relación directa o indirecta con el nuevosistema.
Fase – Análisis del Sistema
Objetivos Actividades Tareas
• Completar la identificación de los requerimientos que comenzó en la fase de Iniciación del Proyecto.
• Transformar los requerimientos de alto nivel en especificaciones detalladas del sistema.
• Crear un diseño conceptual del sistema a través del estudio de fiabilidad detallado.
Entender los procesos actuales.• Desarrollar una línea base con los procesos actuales que permitan justificar el
propósito de las mejoras a obtenerse con el sistema.
Identificar los requerimientos.• Definir requerimientos detallados del sistema.
• Desarrollar el Criterio de Evaluación de Requerimientos.
Priorizar los requerimientos. • Priorizar los requerimientos detallados conjuntamente con el cliente.
Identificar mejoras potenciales en los procesos.
• Identificar soluciones potenciales para los requerimientos detallados, catalogados
como prioritarios.
Determinar las mejoras que tendrán el mayor impacto sobre los requerimientos prioritarios.
• Determinar cuáles de los procesos de mejora propuestos, deberán ser implantados en
el sistema para asegurar el mayor impacto sobre los requerimientos prioritarios.
Crear un mapa de estado detallado.• Generar un mapa funcional de procesos detallado (de estados) sobre los
requerimientos prioritarios.
Evaluar el impacto y riesgos de las propuestas de mejora de los procesos.
• Evaluar el impacto y los riesgos sobre las mejoras de procesos propuestas, y su
repercusión en el sistema.
Completar el desarrollo del diseño conceptual del sistema.
• Completar el diseño conceptual del nuevo sistema.
Completar el documento de especificación de requerimientos.
• Agrupar la información obtenida en las tareas precedentes bajo una estructura
definida, para conformar el documento de referencia final de requerimientos del
proyecto.
Obtener aprobación• Presentar el documento de especificación de requerimientos elaborado al cliente
para obtener aprobación.
Fases de Desarrollo en base a ICONIX
Generar listado de
requerimientos
class Objetos de Domi...
Cliente
Peticion
PersonaDesarrollo
Proyecto
CaracteristicaPersona
Cargo
Meta
AnalisisMeta
RazonSolicitud
FartorCritico
ProcesoNegocio
Activ idad ResponsableActiv idad
Requerimiento
AsignacionPersonaDesarrollo
PosibleMejora
CriterioAceptacion
MetodoObtencion
Elaborar Modelo de Dominio inicial
Fases de Desarrollo en base a ICONIX
Crear Prototipos de interfaz de
usuario
uc Modelo de Casos de Uso Par...
Iniciar sesión
Cerrar sesión
Manejar cuenta de
usuario del sistema
Manejar Persona de
Desarrollo
Actualizar datos
adicionales al Proyecto
Conformar Equipo de
Desarrollo
Manejar datos iniciales
del Proyecto
Actualizar datos
adicionales al
Requerimiento
Identificar Responsable
por Activ idad
Manejar Activ idad
por Proceso
Manejar Responsable de
Activ idad
Establecer
Requerimiento del
Cliente
Mostrar información
actual del
Requerimiento
Manejar Criterio de
Aceptación
Priorizar los
Requerimientos
Identificar Posible
Mejora Potencial
Manejar Conflicto por
Resolv er
Cliente
Líder del Proyecto
Administrador
Realizar Análisis de
Metas del Proyecto
Manejar Proceso que
requiere el sistema
Analista
Realizar identificación
macro de Procesos
Manejar parámetros
generales del sistema
Asignar Personas de
Desarrollo al Proyecto
Asignar Responsables a
una Activ idad
Generar reporte
Manejar Anexo o
archiv o del Proyecto
«precedes»
«precedes»«invokes»
«invokes»
«precedes»
«precedes»
Realizar el Modelo de Casos de Uso
Fases de Desarrollo en base a ICONIX
Realizar el Diagrama de
PaquetesElaborar las
Especificaciones de Casos de uso
Fases de Desarrollo en base a ICONIX
Crear los Diagramas de Robustez Actualizar el Modelo de
Dominio inicial
analysis Dgrm. Robustez
Código: 01
Caso de Uso: Iniciar sesión
Flujo Básico:
El usuario da clic en el enlace
“Iniciar sesión” de la Página
Principal (ver Figura 3.2), y el
sistema muestra la Página de
Inicio de sesión (ver Figura 3.3).
El usuario ingresa su nombre de
usuario y contraseña y da clic en
la opción “Ingresar”.
El sistema verifica si existen los
datos ingresados en cuenta de
usuario. Si estos datos existen, el
sistema autentifica al usuario en
sesión y se direcciona a la
Página Principal mostrando un
mensaje de bienvenida, y el
nombre del usuario
autentificado. Además el sistema
cambia el enlace “Iniciar sesión”
por el enlace “Cerrar sesión”.
Flujos Alternativ os:
Datos inv álidos: El sistema se
direcciona a la misma Página de
Inicio de sesión mostrando un
mensaje que dice “Nombre de
usuario y/o contraseña son
incorrectos, inicio de sesión
falló”.
Usuario cancela inicio de
sesión: El usuario da clic en la
opción “Cancelar”, y el sistema
muestra la Página Principal.
Página PrincipalMostrar Página de
Inicio de sesión
Página de Inicio de
sesión
CuentaUsuario
Ingresar "nombre de
usuario" y "contraseña"
Existe cuenta?
Autentificar usuario en
sesiónDireccionar a la Página
Principal con un
mensaje de bienvenida
y nombre de usuario
Cambiar la etiqueta del
enlace "Iniciar sesión"
por "Cerrar sesión"
Mostrar Página de
Inicio de sesión con un
mensaje "Nombre de
usuario y/o contraseña
son incorrectos, inicio
de sesión falló"
Mostrar Página
Principal
Cancelar Inicio de
sesión
Usuario
(from Actores)
no
si
clic en la opción
"Ingresar"
clic en el enlace
"Iniciar sesión"
class Diagrama de Clases
Proyecto
- codigo: String
- costoTotal: float
- descripcion: String
- fechaEfectiva: Date
- fechaFinPreliminar: Date
- fechaFinReal: Date
- fechaInicio: Date
- fechaRecepcion: Date
- nombre: String
- nombreDirector: String
- nombreLider: String
PersonaDesarrollo
- apellido: String
- codigo: String
- nombre: String
Cargo
- codigo: String
- nombre: String
«enumeration»
Niv elSigma
NINGUNA
CAMPEON
MAESTRO_CINTURON_NEGRO
CINTURON_NEGRO
CINTURON_VERDE
«enumeration»
Caracteristica
COMPROMISO
SESGO_ACCION
FLEXIBILIDAD
INNOVACION
INFLUENCIA_PERSONAL
TRABAJO_EQUIPO
TIEMPO_DISPONIBLE
CaracteristicaPersona
- id: long
Cliente
- codigo: String
- nombre: String
- telefono: String
Peticion
- codigo: String
- descripcion: String
RazonSolicitud
- codigo: String
- descripcion: String
Requerimiento
- codigo: String
- prioridad: int
- descripcion: String
- fuente: String
- justificacion: String
- observacion: String
- rangoSatisfaccionActual: int
- rangoImportancia: int
FactorCritico
- codigo: String
- descripcion: String
«enumeration»
TipoFactor
EXITO
RIESGO
Meta
- codigo: String
- descripción: String
AnalisisMeta
- justificacion: String
«enumeration»
CaracteristicaMeta
ESPECIFICA
MESURABLE
ALCANZABLE
RELEVANTE
ProcesoNegocio
- alcance: String
- codigo: String
- descripcion: String
- nombre: String
Activ idad
- codigo: String
- descripcion: String
DetalleProceso
- codigo: String
- descripcion: String
AsignacionPersonaDesarrollo
- id: long
PosibleMejora
- codigo: String
- descripcion: String
«enumeration»
TipoRequerimiento
FUNCTIONAL
NO_FUNCTIONAL
«enumeration»
EstadoRequerimiento
PENDING
ACCEPTED
DENIED
ResponsableActiv idad
- codigo: String
- nombreCompleto: String
AsignacionResponsableActiv idad
- id: long
«enumeration»
EstadoProyecto
PENDING
IN_PROCESS
COMPLETED
CANCELLED
«enumeration»
TipoDetalleProceso
PROVIDER
INPUT
OUTPUT
CUSTOMER
«enumeration»
TipoResponsableActiv idad
INTERNO
EXTERNO
MetodoObtencion
- id: Long
«enumeration»
TipoMetodoObtencion
ENCUESTA
FOCUS_GROUP
ENTREVISTA_INDIVIDUAL
SITIO_VISITADO
QUEJA_CLIENTE
RETORNO
CriterioAceptacion
- codigo: String
- descripción: String
ConflictoResolv er
- codigo: String
- descripcion: String
«enumeration»
TipoCostoPosibleMejora
BAJO
MEDIO
ALTO
DESCONOCIDO
«enumeration»
TipoTiempoPosibleMejora
BAJO
MEDIO
ALTO
Anexo
- codigo: String
- descripcion: String
- nombreArchivo: String
- archivo: byte
«enumeration»
FaseProcesoDesarrollo
PROJECT_INITIATION
SYSTEM_ANALYSIS
Reescribir las Especificaciones de casos de uso
¿Cómo evaluar la calidad una aplicación web a medida?
Para evaluar la calidad de un software de ámbito web es necesario considerar sus:
Cualidades Externas (se refieren a factores esperables que son útiles o aprovechables por los
usuarios finales de un sistema)
Cualidades Internas (aquellas que permitirán una labor sencilla, productiva, ordenada, y eficiente,
a los desarrolladores del sistema, o a quienes deseen re-programarlo, mantenerlo, etc)
Hay 16 atributos básicos de valoración esperables en la calidad de las aplicaciones web a medida .
Es importante conocerlos y exigirlos como estándares que deben cumplir los programadores o
desarrolladores de aplicaciones a medida. A continuación un detalle de los mismos:
MEDIDA DE LA CALIDAD DE UN SOFTWARE PARA LA WEB
ATRIBUTOS BÁSICOS DE VALORACIÓN
ATRIBUTOS BÁSICOS DE VALORACIÓN
ATRIBUTOS BÁSICOS DE VALORACIÓN
ATRIBUTOS BÁSICOS DE VALORACIÓN
PRUEBA DEL CONTENIDO La prueba del contenido intenta descubrir errores tan triviales como errores tipográficos menores o tan significativos como información incorrecta, organización impropia o violación de las leyes de propiedad intelectual, combinando tanto revisiones, para descubrir errores semánticos como la generación de casos de prueba ejecutables para descubrir errores de contenido susceptibles de rastrear hacia contenido dinámicamente derivando que hayan suministrado los datos adquiridos de una o más bases.
LAS PRUEBAS DE CONFIGURACIÓN Intentan descubrir errores que son específicos respecto de un cliente o ambiente de servidor particulares. Las pruebas se encaminan a descubrir los errores asociados con cada posible configuración.La prueba de seguridad.- Incorpora una serie de pruebas diseñadas para explotar las vulnerabilidades en la WebApp y su ambiente.La prueba de desempeño.- Abarca una serie de pruebas diseñadas para valorar:Cómo afecta el tráfico de usuarios la respuesta en tiempo y confiabilidad de la WebCuáles componentes de la WebApp son responsables de la degradación del desempeño y qué características de uso provocan que ocurra la degradaciónCómo la degradación del desempeño impacta los objetivos globales de la WebApp.
PRUEBA DE LAS BASES DE DATOS
Las modernas aplicaciones Web hacen mucho más que presentar objetos decontenido estáticos. En muchos dominios de aplicación, la interfaz de lasWebApps con bases de datos sofisticados gestionan sistemas y construyenobjetos de contenido dinámicos que se crean en el tiempo real aprovechandodatos adquiridos de una base de datos.La prueba de la base de datos para lasWebApps es complicada por varios factores:Las pruebas deben diseñarse paratratar de desabrir los errores cometidos al traducir las solicitudes del usuario enuna forma que puedan procesar dichos DBMS.