UNIDAD I 1
Ejemplo de un sistema: Sistema respiratorio, sistema nervioso, sistema óseo, el sistema de frenos
de un vehículo, el sistema eléctrico de una casa, un sistema de riego, entre otros.
Entrad Salida
Proces
Retroalimentació
• Existe mucha incertidumbre debido a que se concilian diferentes ideas de lo que los
usuarios consideran debería hacer el sistema, con las alternativas existentes acerca del
ambiente de aplicación del nuevo sistema.
1. Diseño de Datos
2. Diseño Arquitectónico
3. Diseño de Interfaces
4. Diseño de componentes
Sin diseño, nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se
realicen pequeños cambios, un sistema que sea difícil de probar, un sistema cuya calidad no
pueda ser evaluada hasta más adelante, cuando quede poco tiempo y ya sea haya gastado mucho
dinero.
El diseño del sistema es un proceso mediante el que se traducen los requisitos en una
representación del software, que se acerca mucho al código fuente. Desde el punto de vista de la
gestión del proyecto, el diseño del software se realiza en dos etapas: el diseño preliminar y el
diseño detallado.
Además del diseño de datos, del diseño arquitectónico y del desarrollo procedimental, muchas
aplicaciones modernas requieren un diseño de la interfaz.
5
Diseño y calidad del software
A lo largo del proceso de diseño, la calidad del diseño se evalúa mediante una serie de revisiones
técnicas formales (RTF) que son una actividad de garantía del software cuyos objetivos son:
Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si está bien planificada,
controlada y atendida. A continuación, se listan una serie de criterios para determinar la calidad
del software.
Los procesos se descomponen hasta el nivel de tareas o actividades elementales, donde cada
tarea está identificada por un procedimiento que define la forma de llevarla a cabo. Para aplicar
un procedimiento se pueden usar una o más técnicas, pudiendo ser gráficos con textos.
Reglas predefinidas
Determinación de los pasos del ciclo de vida
Verificaciones en cada etapa
Planificación y control
Comunicación efectiva entre desarrolladores y usuarios.
De fácil comprensión
Soporte de herramientas automatizadas.
Qué permita definir mediciones que indiquen mejoras
Qué permita modificaciones
Qué soporte reusabilidad del software
Metodologías estructuradas
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación
Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el
diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de
Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan
para la implementación lenguajes de 3ra y 4ta generación.
Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías
tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en
cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a
aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
Metodologías ágiles
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de
software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento) [11].
Entre las metodologías ágiles identificadas en [11]:
XP - Extreme Programming .
Scrum
Familia de Metodologías Crystal.
Feature Driven Development
Proceso Unificado Rational, una configuración ágil
Dynamic Systems Development Method.
Debido a la complejidad y envergadura del trabajo requerido para analizar, diseñar e implantar
un sistema de informático se necesita para hacerlo con eficiencia se planifique, ejecute y controle
de acuerdo a ciertas reglas, leyes y principios que por un lado organicen el trabajo de forma
adecuada y por otro garanticen que el trabajo del análisis y diseño se apliquen principios
fundamentales de la teoría de sistemas.
El enfoque sistémico
El trabajo del diseñador es creativo en gran parte, pues son diseñados para objetivos específicos
y sin reglas rígidas, sin embargo es posible establecer una estructura que contenga ciertas normas
aplicables a los recursos, organización, técnicas, métodos y procesos durante los cuales el trabajo
de sistematización puede hacerse más eficiente, debiendo ser flexible para no impedir la
creatividad del sistematizador.
Independientemente del paradigma que se utilice, del área de aplicación, y del tamaño y la
complejidad del proyecto, el proceso de desarrollo de software contiene siempre una serie de
fases genéricas, existentes en todos los paradigmas. Estas fases son la definición, el desarrollo y
el mantenimiento.
1) Definición.
Aunque los pasos concretos dependen del modelo de ciclo de vida utilizado (cascada,
espiral, evolutivo e incremental), en general se realizarán cuatro tareas específicas:
Es la fase de diseño externo. Consiste en cuestionar al usuario sobre qué hace el sistema,
qué características extras él quiere en su nuevo sistema y qué restricciones debe satisfacer. La
salida del análisis debe incluir una especificación funcional y un análisis estructurado que
contiene los requerimientos para el nuevo sistema, los cuales el usuario debe leer, analizar y
señalar lo que él quiere
Durante esta etapa se lleva a cabo el análisis de riesgos, se definen los recursos necesarios
para desarrollar el software y se establecen las estimaciones de tiempo y costes. El propósito de
esta etapa de planificación es proporcionar una indicación preliminar de la viabilidad del
proyecto de acuerdo con el coste y con la agenda que se hayan establecido. Posteriormente, la
gestión del proyecto durante el desarrollo del mismo realiza y revisa el plan de proyecto de
software.
Identificar un número de soluciones que pueden satisfacer las necesidades del usuario
dentro de su esquema.
Desarrollar esquemas de cómo puede llevarse a cabo el proyecto teniendo una idea de los
recursos que se requieren.
2) Desarrollo.
Diseño.
Codificación.
Pruebas.
Una vez que tenemos implementado el software es preciso probarlo, para detectar errores
de codificación, de diseño o de especificación. Las pruebas son necesarias para encontrar el
mayor número posible de errores antes de entregar el programa al cliente.
Garantía de calidad.
Una vez terminada la fase de pruebas, el software está casi preparado para ser entregado
al cliente.
3) Mantenimiento.
12
DE SISTEMAS
Es una representación abstracta del sistema, que plantea una solución que será
implementada luego.
Se preocupa de la "forma" del sistema en todos sus aspectos, definiendo con todo el
detalle cómo se iría a obtener esa forma planteada. Para esto es necesario desarrollar
ciertas actividades como:
ABSTRACCIÓN: Generalizar un problema con el fín de asignar prioridades a su
solución y establecer una jerarquía.
OPERACIONALIDAD: Convertir la estructura generada en algo realizable y
funcional.
VERIFICACIÓN: Comprobar que se cumple con lo especificado en el análisis.
Es una etapa limitada por el ambiente tecnológico de hardware y software existente en la
organización.
Busca que la construcción del sistema se vuelva más rutinaria y elemental.
La estructura a diseñar debe ser modular, donde cada módulo exhiba características
funcionales independientes.
Un buen diseño debe ser :
COMPLETO : Debe abarcar todos los requerimientos planteados anteriormente.
CONSISTENTE : Se deben definir bien las interfaces con otros sistemas.
CLARO : Que sea fácil de traducir a un lenguaje de programación.
Participación requerida.
Es una etapa muy técnica que requiere gran participación del personal de sistemas y del usuario,
en lo que respecta a evaluaciones de prototipos y de diseño de pantallas (ventanas) del nuevo
sistema.
Analistas. Elaboran las especificaciones del diseño, con base en el análisis elaborado
anteriormente. El papel que desempeña en ésta etapa el analista de sistemas, es el de diseñador.
La habilidades de un buen diseñador difieren algo de las del analista. Veamos : Se debe enfocar a
la tecnología, sin olvidar los procesos definidos en el análisis, mientras el analista hace lo
contrario. Se enfrenta con la tarea de traducir los requerimientos del negocio a la tecnología
disponible en la organización.
Un buen diseñador es creativo, lleno de recursos e inteligente para evaluar opciones entre
Usuarios. Aprueban aspectos como operación del sistema, diseño de entradas y salidas, diseño de
archivos y funcionalidad del sistema (Interfase de usuario).
Pasos en el desarrollo del diseño.
Los siguientes son los pasos a seguir para lograr un desarrollo coherente y serio en el diseño de
un sistema de información. Cada una de estas tareas debe estar claramente documentada, en el
manual de desarrollo del sistema.
Esta técnica es la empleada para elaborar la estructura del sistema. Consiste en descomponer en
forma sucesiva un módulo en otros módulos de más baja jerarquía, hasta lograr el detalle
suficiente en la asignación de funciones a estos. Reglas para la descomposición:
15
Ejemplo:
16
Diseño conceptual
El diseño conceptual se hace independiente al sistema gestor de base de datos (DBMS) que
utilice el usuario para la implementación de esta.
Ver video: https://www.youtube.com/watch?v=THyQ-hhuOx4
Atributos: Las propiedades que califican y le dan vida a la entidad se denominan atributos.
Ejemplo: la entidad persona se puede describir por las siguientes propiedades: cédula, nombre,
dirección, sexo, peso, altura, color, tipo de sangre, salario.
19
20
21
Diccionario de datos
22
UNIDAD V
Ayuda a comprender el trabajo como un proceso y a identificar en qué parte del proceso está el
problema.
Es muy importante comprender que cada paso en el proceso crea relaciones o dependencias entre
unos y otros para lograr la realización del trabajo. Cada paso del proceso depende en uno o
varios proveedores de materiales o servicios y en algunos casos de información o recursos, los
cuales deben ser: confiables, libres de defectos, oportunos y completos.
En contraposición, aquellos que son los receptores del o de los productos del proceso deben
asentar claramente sus requerimientos y dar a conocer cuando no están recibiendo lo esperado.
Es también muy importante que el diagrama de flujo sobre el que se haga el análisis de cualquier
proceso se encuentre al día, ya que si no es así puede desvirtuar la identificación de problemas
reales. Cada proceso es un sistema y debe ser tratado de tal manera con todas las partes con las
que conecta. Si se cambia una de las partes del subsistema siempre se verá afectado el cómo
actúa el sistema en su totalidad.
¿Cómo se elabora?
Valide el diagrama de flujo y las medidas de desempeño del mismo con los propietarios o
los que llevan a cabo el proceso y con los usuarios del mismo. Antes de que un equipo
pueda mejorar algún proceso, necesitan entenderlo.
Las personas que pueden evaluarlo son las que participan en el proceso o reciben algún
producto, servicio o información de él.
Se puede llevar a cabo un proceso de chequeo bajo los siguientes considerandos: Se debe
Enliste todos los pasos del proceso como se están realizando. Mantenga tan simple como
sea posible su descripción.
24
•
,
INSTITUTO TECNOLÓGICO SUPERIOR
'
“JOSE OCHOA LEÓN” DISEÑO DE SISTEMAS
CONTRATISTA REGIS'fRO 1UNIOAO DIE CONTAATACIONI
RESPONSABLE
AAEA SECRETARÍA 25
3
Rla!gMrvde
---------- Enlriula
e
Reglslro ele
Sali(la
21
Resoluclones
OO.
'Unipersonales
24
----------+--------+-----e Noliliu1ciones ,
Pro,cese, de lns,cripción ,en el Registr,e d,e Licila,dores die una Administración Púb 1ica 1
Se hacen basados en el contenido de los flujos de datos de entrada del sistema, descritos en el
diccionario de datos. Se debe tener en cuenta :
En el encabezado del documento
Logotipo de la Organización.
Nombre de la Organización.
Nombre del departamento, sección o división.
Código del documento.
Número del documento.
En el cuerpo del documento :
Presentar un orden lógico de campos, de acuerdo con el orden de los datos que muestran
las pantallas.
Mostrar una descripción clara de cada campo a diligenciar.
Permitir suficiente espacio para diligenciar cada campo.
Manejar una presentación agradable y armónica.
Permitir un espacio para posibles observaciones.
Diseño de ventanas.
27
Las ventanas son la forma básica de comunicación con el usuario y la unidad de programación a
tener en cuenta en la construcción. Se deben diseñar, teniendo en cuenta los estándares antes
mencionados y el tipo de ventana (entrada de datos, consultas, de menú, etc.). Se debe tener en
cuenta:
Control del Usuario: Un buen diseño debe estar direccionado a soportar el hecho de que el 28
usuario es quien tiene el control en la GUI. El usuario tiene la libertad para moverse de ventana a
ventana y hacer cualquier cosa que desee. La tarea del diseñador es restringir a lugares donde no
puede ir el usuario, más que a los lugares donde puede acceder.
Una buena aplicación GUI debe tener facilidad para el uso del mouse o para el teclado,
indistintamente. Por ello se deben incluir aspectos como el orden de tabulación y teclas
aceleradoras (hot key) para que cualquier acción que se realce con el mouse, se pueda realizar
también con el teclado.
Personalización: Se debe permitir personalizar las diferentes ventanas del sistema, a los diversos
tipos de usuarios que las acceden, teniendo cuidado de modificar algunos aspectos como colores,
ocultamiento de columnas, etc.
Dirección: Se debe tener presente que la memorización de comandos no aplica bajo GUI.
Especialmente el hecho de ubicar un objeto en el sistema, debe ser tan intuitivo como señalarlo
con el mouse y realizar la operación deseada con el objeto. Algo así como “apunte y dispare”.
Se pueden usar para tal propósito iconos y barras de herramientas que aclaren la ubicación de los
diferentes objetos existentes.
Consistencia: El sistema deberá ser consistente con el mundo en que los usuarios viven y
trabajan diariamente. Para ello se debe usar el vocabulario que manejan los usuarios y tratar de
estandarizarlo a lo largo de todo el sistema, para que la GUI sea entendible por ellos.
Una clave aquí de estándares, es tratar de mantener los definidos en aplicaciones de uso general
como Word y Excel, que siempre tratan de mostrar la misma interface para el usuario.
Estética: La composición y disposición de una ventana debe ser visualmente agradable. Deberá
atraer la vista hacia la información que es más importante. El ojo humano ve primero la parte
izquierda superior del centro de la pantalla y hace un barrido en el sentido de las agujas del reloj.
Se debe tener especial cuidado con los colores a usar, el tipo de letra, el tamaño de la misma. No
se deben presentar ventanas muy atiborradas de objetos ; es mejor dividirlas en otras ventanas,
para evitar confusiones.
29
Tipos de Ventanas
30
Ventana Desplegable.
Conocida con el nombre de Pop Up.
Aparece por encima de la ventana que la llama.
Se abre desde una ventana existente, llamada Ventana Madre.
No puede ser traslapada por su madre.
Puede existir después de que se cierra la ventana madre.
Ventana Hija.
Es muy similar a una ventana desplegable, pero más restrictiva.
Se abre a partir de una ventana madre.
No puede ser traslapada por la ventana madre.
No puede ser arrastrada fuera del marco de la ventana madre.
No puede existir después de cerrar la ventana madre.
31
Ventana de Respuesta.
Es la más restrictiva de todas las ventanas.
No se libera sino hasta que se cierra.
No es minimizable ni redimensionable.
Se usa para forzar al usuario a través de una ruta particular.
32
DISEÑO DE REPORTES.
Se diferencian de los informes, por ser impresos y tener un límite de columnas para su
presentación. Se deben diseñar teniendo en cuenta el contenido de los flujos de datos de salida
definidos en el diccionario de datos. Se debe tener en cuenta:
En el encabezado de los reportes :
Presentar el nombre de la empresa.
Mostrar el nombre del sistema de Información.
Mostrar el Título del reporte.
La fecha de elaboración del reporte.
Paginar el reporte.
Presentar los nombres completos de los campos a listar.
Para reportes con totales, mostrar totales generales al finalizar el reporte.
Distribuir la información en una forma clara, ordenada y armónica.
Es la tarea clave en lo que respecta a la definición de la forma como van a interactuar el usuario
y el sistema, ya que se define, por parte de los analistas la navegación y comunicación entre las
dos partes. No debemos perder el objetivo de ésta tarea, tratando de mostrar el sistema
funcionando en éste punto. En algunos establecimientos, la creación de prototipos es una
“disculpa” para codificar algo rápidamente y ver si los usuarios lo aceptan. Busca que los
usuarios tengan una idea de cómo será el diálogo y la navegación a través del sistema y en
consecuencia se le debe aclarar al mismo el objetivo anteriormente expuesto.
Se debe construir un modelo sencillo que muestre cómo será la operación del sistema, con el fin
Una buena idea para construir prototipos es la elaboración de los mismos en papel, para dar una
mayor agilidad a la tarea, dado que ella es recursiva, pues se pretende mostrar y corregir, hasta
obtener un producto totalmente aceptado por los usuarios. Se debe tener en cuenta:
Los
diferentes módulos del sistema.
Algunas características propias del usuario:
Usuarios dedicados (Exigen poca documentación y capacitación).
Usuarios casual (Desean un sistema amistoso y detallado).
Grado de escolaridad.
Funciones que desarrolla en la organización.
Nivel de jerarquía.
No mostrar características que no se puedan luego implementar.
No se debe comenzar a construir el sistema, con la creación temprana de prototipos.
El del usuario, el del programador y el del diseñador (analogía de la construcción de una casa).
Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas
acerca de la misma, desarrollados a través de su experiencia.
El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones
adecuadas para modificar el mismo. Los modelos subyacen en la interacción con las
computadoras, de ahí su importancia.
Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que éste se
comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo, ya sea
realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una interfaz debe
facilitar el proceso de crear un modelo mental efectivo.
Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya conocido
por el usuario. Un ejemplo típico es la metáfora del escritorio, común a la mayoría de las
interfaces gráficas actuales.
Antes de abordar el proceso de diseño de interfaz del usuario se deben tratar algunas
consideraciones en el diseño que tienen que ser tomados en cuenta por los diseñadores de
interfaces de usuarios.
Interacción del usuario: Una interfaz coherente debe integrar la interacción del usuario y la
presentación de la información. Shneiderman (1998) clasifica la interacción en 5 estilos
primarios:
Manipulación directa: Interacción directa con los objetos de la pantalla, Rápida e intuitiva, Fácil
de aprender, Ejemplo: para borrar un archivo, el usuario lo arrastra al bote de basura. Videos de
juegos, Puede ser difícil de implementar, Sólo es adecuada donde hay una metáfora visual para
las tareas y objetos.
Selección de menús: El usuario selecciona un comando de una lista de posibilidades. Evita
errores del usuario, Se requiere teclear poco, Lenta para usuarios experimentados, Puede llegar a
ser complejo si existen muchas opciones en el menú, Ejemplo: muchos de los sistemas de
propósito general.
Lenguaje de comandos: Los usuarios emiten un comando especial y los parámetros asociados
Lenguaje Natural: El usuario emite comandos en lenguaje natural, Accesible a usuarios casuales,
Fácil de ampliar, Se requiere teclear más, Los sistemas de comprensión de lenguaje natural no
son fiables, Ejemplo: Sistemas de horarios, sistemas www de recuperación de la información.
María Alvarado
Sulimar Pastran
Los asistentes usados para instalar software son un ejemplo común de una interfaz de
pregunta y respuesta. El usuario responde a las preguntas acerca del proceso de instalación, tal
como dónde instalar el software o características. Otro ejemplo común es el uso del Asistente de
Office usado en los productos de Microsoft. Cuando el usuario necesita ayuda, el Asistente de
Office hace preguntas y reacciona a las respuestas con preguntas adicionales diseñadas para
limitar el alcance del problema. Los usuarios que no están familiarizados con aplicaciones
particulares o no están informados sobre un tema podrían encontrar interfaces de pregunta y
respuesta más cómodas, ganando rápidamente confianza a través de su éxito.
Menús
Una interfaz de menú proporciona al usuario una lista en pantalla de las selecciones
disponibles. En respuesta al menú, un usuario está limitado a las opciones desplegadas. El
usuario no necesita conocer el sistema pero tiene que saber qué tarea se debe realizar. Por
ejemplo, con un menú típico de procesamiento de texto, los usuarios pueden escoger opciones
para editar, copiar o imprimir. Sin embargo, para utilizar el mejor menú los usuarios deben saber
qué tarea desean desempeñar.
Los menús no dependen del hardware. Las variaciones abundan. Los menús se establecen
para usar el teclado, lápiz óptico o el ratón. Las selecciones se pueden identificar con un número,
carta o palabra clave. La consistencia es importante en el diseño de una interfaz de menú.
40
Los menús también se pueden ocultar hasta que el usuario quiera usarlos. La figura
muestra cómo se usa un menú desplegable. Los menús se pueden anidar dentro de otro para
llevar a un usuario a las opciones de un programa. Los menús anidados permiten a la pantalla
aparecer menos desordenada, la cual es consistente con el adecuado diseño.
También permiten a usuarios evitar ver opciones de menú en las que no están interesados.
Los menús anidados también pueden mover rápidamente a los usuarios a través del programa.
Los menús de GUI(interfaces graficas de usuario) se usan para controlar el software de PC
y tienen los siguientes lineamientos:
1. Siempre se despliega la barra de menú principal.
2. El menú principal usa palabras simples para los artículos del menú. Las opciones de
menú principales siempre despliegan menús desplegables secundarios.
3. El menú principal debe tener opciones secundarias agrupadas en grupos similares de
características.
43
BIBLIOGRAFÍA
Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by the NATO
Scienc, 1969.
Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software,
Addison Wesley 2000.
Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio, Pearson Educación,
2000.
Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods. Review and
Analysis, VTT, 2002.
Schwaber, K., Scrum Development Process. Workshop on Business Object Design and
Implementation, OOPSLA´95, 1995.
ANEXO 1
CASO PRÁCTICO
RESTAURANTE
• Presentación de menús a comensales: Los camareros utilizan Tablet PCs para presentar
en las mesas los menús (primeros platos, segundos, postres, bebidas...) que ofrece el
restaurante a los clientes. Con este dispositivo el camarero indica los nombres de los
primeros y segundos platos y sus precios; del postre se indica además si es frío o caliente
y de la bebida, en el caso de los vinos, el año. Cada camarero gestiona un grupo de mesas,
numeradas de 1 a n, y tiene un nombre.
45
El gerente puede realizar consultas para obtener una lista ordenada por mesas en la que se
indica el resumen de ventas en dicha mesa y los camareros asignados (apellidos y nombre)
en un determinado periodo de tiempo.
• Recepción de peticiones en las mesas: Utilizando este mismo dispositivo los camareros
anotan las peticiones de los clientes, y se calcula un presupuesto inicial que se le indica a
los comensales. En la petición el cliente indica su número de mesa. El sistema almacena
la hora de la petición.
• Entrega de platos: Los camareros consultan en su Tablet PC cuándo están los platos
terminados y los recogen en la cocina para llevárselos a los comensales. Los platos que
no requieren elaboración en cocina (bebidas, pan, algunos postres...) son recogidos
directamente por el camarero en el almacén de la cocina, que contiene frigoríficos y
cámaras con dichos platos.
• Facturación: Las facturas son emitidas directamente por los camareros desde sus Tablet
PCs utilizando una impresora común conectada “sin cables”. Las facturas se emiten
cuando los clientes piden la cuenta. El precio de los productos incluye el IVA, que tiene
que ser desglosado en la factura.
Como resultado el sistema elabora los pedidos concretos que se van a efectuar a cada
proveedor. Los proveedores siempre adjuntan la factura, que indica las cantidades de
alimentos que se han comprado.
Todos los dispositivos están conectados en red local mediante tecnología inalámbrica.
ANEXO 2
REQUERIMIENTOS DEL SOFTWARE
47
La Ingeniería de Requerimientos contempla todas las tareas específicas para satisfacer las
necesidades durante el proceso de creación o modificación de un software.
Medibles
Comprobables
Sin contradicciones
Sin Ambigüedades
Ejemplo de requerimientos.
¿Que entendemos por esto? La palabra rápido es variable, no es Medible. Para que el
requerimiento sea correcto debería poder entregar una razón que sea Medible y razonable.
Los requerimientos Funcionales: contemplan todo lo que el usuario desea que realice el sistema,
ejemplo; emisión de comprobante, impresión de facturas, etc. “Que debe hacer un sistema”
Los requerimientos no funcionales: contemplan todo lo que se necesita para que el sistema
funcione correctamente; por ejemplo Impresora para la impresión de la factura. “Como debe ser
un sistema”.
1) Identificar actores: representan entidades externas que interactúan con el sistema (rol). Se
Modelo en Cascada.
El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de modelos de
actividades de ingeniería con el fin de establecer algo de orden en el desarrollo de grandes
productos de software. Consiste en diferentes etapas, las cuales son procesadas en una manera
lineal. Comparado con otros modelos de desarrollo de software es más rígido y mejor
administrable. El modelo cascada es un modelo muy importante y ha sido la base de muchos
otros modelos, sin embargo, para muchos proyectos modernos, ha quedado un poco
desactualizado.
Estas son las etapas principales. También existen sub-etapas, dentro de cada etapa, pero éstas
difieren mucho de un proyecto a otro. También es posible que ciertos proyectos de software
requieran la incorporación de una etapa extra o la separación de una etapa en otras dos. Sin
embargo, todas estas variaciones al modelo cascada poseen el mismo concepto básico: la idea de
que una etapa provee salidas que serán usadas como las entradas de la siguiente etapa (un flujo
lineal entre las etapas). Por lo tanto, el progreso del proceso de desarrollo de un producto de
software, usando el modelo cascada, es simple de conocer y controlar.
Existen actividades que son llevadas a cabo en cada una de las etapas del desarrollo del software.
Éstas son documentación, verificación y administración. La documentación es intrínseca al
modelo cascada puesto que la mayoría de las salidas que arrojan las etapas son documentos.
Los proyectos raramente siguen el flujo secuencial que el modelo propone. La iteración
siempre es necesaria y está presente, creando problemas en la aplicación del modelo.
Cada uno de estos problemas es real. Sin embargo, el modelo clásico del ciclo de vida del
software tiene un lugar bien definido e importante en los trabajos de ingeniería del software.
Provee un patrón dentro del cual encajan métodos para el análisis, diseño, codificación y
mantenimiento.
Aplicación
El modelo cascada se aplica bien en situaciones en las que el software es simple y en las que
el dominio de requerimientos es bien conocido, la tecnología usada en el desarrollo es accesible
y los recursos están disponibles.
Modelo Prototipo.
Dos de las críticas que se hacían al modelo de ciclo de vida en cascada eran que es difícil
tener claros todos los requisitos del sistema al inicio del proyecto, y que no se dispone de una
versión operativa del programa hasta las fases finales del desarrollo, lo que dificulta la detección
de errores y deja también para el final el descubrimiento de los requisitos inadvertidos en las
fases de análisis. Para paliar estas deficiencias se ha propuesto un modelo de ciclo de vida
basado en la construcción de prototipos.
Obtención de
Diseño Global
Desarrollo GRUPO
USUARIO /
DISEÑADOR
Refinamiento
Sistema Terminado
También es conveniente construir prototipos para probar la eficiencia de los algoritmos que
se van a implementar, o para comprobar el rendimiento de un determinado componente del
sistema en condiciones similares a las que existirán durante la utilización del sistema. Es bastante
frecuente que el producto de ingeniería desarrollado presente un buen rendimiento durante la
fase de pruebas realizada por los ingenieros antes de entregarlo al cliente pero que sea muy
ineficiente, o incluso inviable, a la hora de almacenar o procesar el volumen real de información
que debe manejar el cliente. En estos casos, la construcción de un prototipo de parte del sistema
y la realización de pruebas de rendimiento, sirven para decidir, antes de empezar la fase de
diseño, cuál es el modelo más adecuado de entre la gama disponible para el soporte hardware o
cómo deben hacerse los accesos para obtener buenas respuestas en tiempo cuando la aplicación
esté ya en funcionamiento.
En otros casos, el prototipo servirá para modelar y poder mostrar al cliente cómo va a
realizarse la E/S de datos en la aplicación, de forma que éste pueda hacerse una idea de cómo va
a ser el sistema final, pudiendo entonces detectar deficiencias o errores en la especificación
aunque el modelo no sea más que una cáscara vacía.
Según esto un prototipo puede tener alguna de las tres formas siguientes:
Luego se procede a diseñar el prototipo. Se tratará de un diseño rápido, centrado sobre todo
en la arquitectura del sistema y la definición de la estructura de las interfaces más que en
aspectos de procedimiento de los programas: nos fijaremos más en la forma y en la apariencia
que en el contenido.
En cualquier caso, el objetivo es siempre que la codificación sea rápida, aunque sea en
detrimento de la calidad del software generado.
Una vez listo el prototipo, hay que presentarlo al cliente para que lo pruebe y sugiera
modificaciones. En este punto el cliente puede ver una implementación de los requisitos que ha
definido inicialmente y sugerir las modificaciones necesarias en las especificaciones para que
satisfagan mejor sus necesidades.
A partir de estos comentarios del cliente y los cambios que se muestren necesarios en los
requisitos, se procederá a construir un nuevo prototipo y así sucesivamente hasta que los
requisitos queden totalmente formalizados, y se pueda entonces empezar con el desarrollo del
producto final.
Por tanto, el prototipado es una técnica que sirve fundamentalmente para la fase de análisis
de requisitos, pero lleva consigo la obtención de una serie de subproductos que son útiles a lo
largo del desarrollo del proyecto:
Gran parte del trabajo realizado durante la fase de diseño rápido (especialmente la
definición de pantallas e informes) puede ser utilizada durante el diseño del producto
final. Además, tras realizar varias vueltas en el ciclo de construcción de prototipos, el
diseño del mismo se parece cada vez más al que tendrá el producto final.
Durante la fase de construcción de prototipos será necesario codificar algunos
componentes del software que también podrán ser reutilizados en la codificación del
producto final, aunque deban de ser optimizados en cuanto a corrección o velocidad de
procesamiento.
No obstante, hay que tener en cuenta que el prototipo no es el sistema final, puesto que
normalmente apenas es utilizable. Será demasiado lento, demasiado grande, inadecuado para el
volumen de datos necesario, contendrá errores (debido al diseño rápido), será demasiado general
(sin considerar casos particulares, que debe tener en cuenta el sistema final) o estará codificado
Hay que tener en cuenta que un análisis de requisitos incorrecto o incompleto, cuyos errores
y deficiencias se detecten a la hora de las pruebas o tras entregar el software al cliente, nos
obligará a repetir de nuevo las fases de análisis, diseño y codificación, que habíamos realizado
cuidadosamente, pensando que estábamos desarrollando el producto final. Al tener que repetir
estas fases, sí que estaremos desechando una gran cantidad de trabajo, normalmente muy
superior al esfuerzo de construir un prototipo basándose en un diseño rápido, en la reutilización
de trozos de software preexistentes y en herramientas de generación de código para informes y
manejo de ventanas.
El utilizar el prototipo en el producto final conduce a que éste contenga numerosos errores
latentes, sea ineficiente, poco fiable, incompleto o difícil de mantener. En definitiva a que tenga
poca calidad, y eso es precisamente lo que se quiere evitar aplicando la ingeniería del software.
Puede existir una mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden
confundir con el sistema terminado
Desarrollo Incremental
Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirir experiencia con el sistema. Es una combinación del Modelo de Cascada
y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las
decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,
dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un
buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.
Versión
#2 Versión ANÁLISIS DISEÑO CÓDIGO PRUEBAS
GRUP
O PRODUC ANÁLISIS DISEÑO CÓDIGO PRUEBAS
SISTE
57
Modelo en Espiral.
Básicamente, la idea es desarrollo incremental usando el modelo Cascada para cada paso,
ayudando a administrar los riesgos. No se define en detalle el sistema completo al principio; los
diseñadores deberían definir e implementar solamente los rasgos de mayor prioridad. Con el
conocimiento adquirido, podrían entonces volver atrás y definir e implementar más
características en trozos más pequeños.
Puntos fuertes
Puntos débiles
Aplicación
Proyectos complejos,
dinámicos, innovadores,
ambiciosos, llevados a
cabo por equipos internos
(no necesariamente de
software).
¿Cuál es el modelo de
proceso más adecuado?
Cada proyecto de software requiere de una forma de particular de abordar el problema. Las
propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada
iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios
(Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre
otros).
Funciona con
Permite Visión del
Modelo de requisitos y Produce software Gestión de
correcciones progreso por el
proceso arquitectura no altamente fiable riesgos
sobre la marcha Cliente y el Jefe
predefinidos
del proyecto
62
MODELO ENFOQUE VENTAJAS/DESVENTAJAS APLICABILIDAD
XP (Extreme Programming)
Pilares
Metáfora: lo más parecido a la arquitectura, cada proyecto tiene una convención de nombres a
recordar.
Semana laboral de 40 horas: si hay horas extra es señal de que está mal.
Scrum
Etapas:
1) Inicio:
a. Planeamiento: establecer la visión, presupuesto, financiamiento y backlog del
producto. Se establecen equipo de trabajo, herramientas y fecha de entrega
aproximada.
b. Arquitectura: conceptualización y análisis. Se hace un diseño de alto nivel
para actualizar modelos del dominio y reflejar el nuevo contexto del sistema.
Diseñadores y arquitectos dividen el proyecto basándose en los ítems del
backlog.
2) Desarrollo: Se divide en iteraciones (sprints), que es el proceso de adaptación a las
variables que cambian con el entorno. Un sprint puede durar de una semana a un mes,
y cada uno abarca las fases tradicionales del desarrollo del software (requerimientos,
Comparación Up – Xp –Scrum
Factibilidad operacional:
¿Existe apoyo suficiente para el proyecto por parte de la administración?, ¿Y por parte de
los usuarios?
Los métodos que actualmente se usan en la empresa, ¿son aceptados por los usuarios?
Factibilidad Técnica:
¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos requeridos
para usar el nuevo sistema?
¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin importar el
número y ubicación de los usuarios?
Un sistema puede ser factible desde el punto de vista técnico y operacional, pero sino es factible
económicamente para la organización no puede ser implantado. Las cuestiones económicas y
ANEXO 6
1. INTRODUCCIÓN
1.1. Antecedentes
1.1. Planteamiento del problema
1.2. Objetivos
1.2.1. Objetivo general
1.2.2. Objetivo específicos
1.3. Propuesta de solución
2. MARCO TEÓRICO
2.1. Requerimientos del software y hardware
2.1. Requerimiento de hardware.
2.2. Requerimiento de software
2.3. Cronograma de actividades
3. ANÁLISIS DEL SISTEMA
3.1. Identificación de requerimientos
3.1.1. Requerimientos funcionales
3.1.2. Requerimientos no funcionales
3.2. Roles del sistema
3.3. Módulos del sistema
3.4. Metodología de desarrollo
3.5. Casos de usos
3.6. Identificación de actores
3.7. Diagramas y descripción de los casos de usos
3.8. Diagrama de clases
3.9. Diagramas de secuencia
4. DISEÑO DEL SISTEMA
4.1. Arquitectura del sistema (grafica de cliente /servidor. # capaz, n capaz, red)
4.2. Descripción de los subsistemas de la aplicación
4.2.1. Diagramas de secuencia de ventanas.
4.3. Diseño de interfaces
4.3.1. Pantalla de inicio del sistema
4.3.2. Interfaces para el modulo
4.3.3. Interfaces para el modulo
ANEXO 7
El inglés Jonathan Ive, nombrado caballero del Imperio Británico
El responsable de diseño de los productos de Apple, el inglés Jonathan Ive, fue nombrado
caballero del Imperio británico por la princesa Ana en una ceremonia celebrada en el palacio de
Buckingham. Ahora podrá utilizar el título de 'Sir'.
Ive tomó el mando de la sección de diseño de Apple en 1996, por lo que está considerado el
responsable de algunos de los productos más emblemáticos de la marca como el iMac, el
MacBook, el iPod, el iPhone o el iPad.
Este legado y los servicios prestados tanto al mundo del diseño
como a la empresa son los que valoró la monarquía inglesa para
otorgarle este honor.
"Fue muy bonito y emocionante. Me siento especialmente
orgulloso", declaró Ive, de 45 años, que acudió al acto con su mujer
y sus dos hijos, con los que vive en San Francisco (EEUU), donde
se encuentra la sede de la compañía de la manzana.
El diseñador, nacido en Londres, intercambió algunas palabras con
Ive aseguró no obstante que mientras trabaja en el diseño de los productos no piensa en el
impacto que tendrán, sino en "hacer el mejor producto posible".
Jonathan Ive, que estudió en la Universidad Politécnica de Newcastle (nordeste de Inglaterra),
empezó a trabajar en Apple en 1992 y en 1996 se convirtió en el responsable de diseño de la
marca.
Su trabajo en la compañía de Steve Jobs, que lo definió como su "compañero espiritual", ha
revolucionado el mundo del diseño y de la informática y le valió en 2005 para ser nombrado ya
comandante del Imperio británico.
ANEXO 8
DESCRIPCIÓN DE LOS CASOS DE USOS
69
ANEXO 9
EJEMPLO DE CRONOGRAMA
70
ANEXO 10
DIAGRAMAS DE ESTADOS
Introducción
Un diagrama de estados muestra la secuencia de estados que pasa un objeto durante su vida
en respuesta a los estímulos recibidos, juntamente con sus respuestas. Definiremos tres
conceptos que nos ayudarán a entender los diagramas de estados:
71
El punto negro marca el estado inicial, y es por donde empieza a leerse el diagrama de estados.
Cada estado se representa con un globo y un nombre.
La flecha que une dos estados se llama transición.
Cada transición lleva asociado un nombre, que determina el acontecimiento que hace que se
produzca dicha transición.
Casos de uso:
o Para describir la
secuencia legal en la que
los acontecimientos se
pueden producir en el
mundo real.
APUNTES